Research Project Proposals

Research Project Proposals

After reviewing a paper from Fernando Pedone, we came up with several proposals for interesting work:

Three proposals:

1. We would like it if someone were to evaluate the different kinds of databases to be used in (for example) state sync. This work should involve understanding the storage access patterns of the protocol, the tradeoffs each backend database introduces. The main motivation is that we plan to, in the long term, pick one database backend for Tendermint. Having data and insights here would be very helpful.

2. Currently Tendermint operates very often as just one layer of a very large stack: the SDK, Gaia, relayers, data processing pipelines etc. We currently don’t have tools or means to test the interaction of these layers and how changes in one layer impact the other. If we could design a tool where we could for example plug in a particular configuration (or developer branch) of one of the layers and then automatically run other tools on top of this. Something similar to k8s or docker where it’s easy to just provide a particular config and the rest of the execution setup is automated.

3. One-fifth Tendermint. There is a simpler version of the Tendermint algorithm, where values are not locked, and there is no Prevote phase. The tradeoff is that the algorithm is faster in terms of needed communication rounds on the “happy path” but it only supports up to 1/5th of byzantine nodes. Adapting the current consensus algorithm to one-fifth consensus would mostly be about “deleting code”, so quite straightforward. Nevertheless, an important outcome of the project would be how easy/hard/tedious it is to replace the current algorithm by a different one (a rough evaluation of CometBFT’s modularity). Finally, we could design benchmarks with an example app to see what the performance gains would be w.r.t. the classic Tendermint algorithm.

The 3 ideas below are features we would find very valuable. These 3 proposals have a better scoped engineering part, but the open-ended research element is not as clear:

1. Switching from consensus to a syncing protocol. Currently, nodes can fall behind in consensus, and they can use only consensus to catch up. ALso statesync is disabled for any node that has any local state.

2. There is an open issue about productionizing the state sync protocol of Tendermint. https://github.com/tendermint/tendermint/issues/9233 In addition to users still using quicksinc.io as a preferred way to sync, an interesting comment is peer discovery for statesync. In a large network, how to guarantee that a node discovers peers that have snapshots. For example we could have an algorithm where a peer that does not have a snapshot, forwards the snapshot request to its peers, if they do have a snapshot it returns the ID of the peer with the snapshot. The syncing node can then form a connection with this peer. Snapshot prioritization within the snapshot pool. Not sure if this applies to chunks. Take snapshots provided by most peers for example.