Repositories structuring

[musalbas]

In building LazyLedger, we would like to use Tendermint for two purposes, that are somewhat independent from each other, that requires a different set of modifications:

1. Optimistic rollups. A version of Tendermint that allows developers to deploy chains that can be used as optimistic rollup sidechains. In order to achieve this, the block header for Tendermint needs to be modified so that there is only one Merkle root that represents the state of the chain, so that state transition fraud proofs can be generated from this root. That means any other root that is derived from the state of the chain, such as the validator set root, must be folded in to this root. Additionally, the state root needs to be structured in such a way so that it can support fraud proofs, which would involve adding intermediate state roots to transactions.
2. LazyLedger layer 1. We also want to use Tendermint to drive the core LazyLedger protocol. This means we need to modify the block header to support data availability proofs, as well as creating a storage node library, etc. However, the LazyLedger layer 1 will also have a consensus-critical execution environment that drives the LazyLedger token and the proof-of-stake protocol. This execution environment will be an optimistic rollup-style environment that supports state transition fraud proofs too, so it will need to adapt the block header modifications from the optimistic rollup version of Tendermint we create.

The Tendermint features we need in (1) are a subset of the ones we need in (2). We need to think about what would be the best way to structure these repositories, and if we want to have one or two forks of Tendermint.

The two options are:

• Have one version of Tendermint both for LazyLedger core, that also allows people to build optimistic rollup chains on Tendermint. Would this get too messy though, and what would the developer experience look like? And could we make it so that people can build optimistic rollup chains via Tendermint without LazyLedger?
• Have a separate version of Tendermint for optimistic rollup chains, that could be a general-purpose optimistic rollup implementation, that could eventually get merged back upstream. The benefit of this could be that it could be the Tendermint community de-facto codebase Tendermint chains that support fraud proofs.

[musalbas]

CC'ing @gakonst - what modifications are you planning to make to Cosmos/Tendermint in order to enable state transition fraud proofs?

[liamsi]

I wish tendemint would allow devs to plug in their own Header definitions and the header used inside of tendermint (for everything besides encoding and other places you'd need to deal with the concrete impl) would just be an interface (or trait). Similar to what we did in the Rust implementation of the light client: https://github.com/informalsystems/tendermint-rs/blob/471542d60d542a8049c81286dff13ffa467300fc/tendermint/src/lite/types.rs#L19-L31
But with additional methods like is_valid (and a few others) to be able to define your own block validity rule(s). This would allow tendermint to be used in a much more flexible manner. Similar this would mean, devs can also define their own way to merkelize transactions (instead of currently via SimpleHashFromByteSlices).

Would the tendermint team like to integrate changes in this direction? @tessr @marbar3778

[melekes]

I can't speak for the tendermint team, but I'd like to see Tendermint more flexible to allow experiments / modifications like ^ without too much pain 👍

[tac0turtle]

I wish tendemint would allow devs to plug in their own Header definitions and the header used inside of tendermint

This is the goal for Tendermint. I hope with the move to protobuf Tendermint can better facilitate this modularity.

[liamsi]

Thanks for your feedback @melekes and @marbar3778. And cool, would be great if we could help tendermint to reach that goal even further :-)

---

Making tendermint as flexible as mentioned above will take some time. So just summarizing what we've discussed as possible options for the meantime:

@adlerjohn suggested we can use the AppHash via Commit in the (tendermint/abci) app for the state root mentioned in 1. (optimistic rollups). The state root could be structured in any desired way (it's completely up to the app; e.g. the cosmos hub uses an iavl tree; well actually several such trees via a MultiStore).

@musalbas raised concerns about this approach as it is actually necessary that there is only one and only one data/state root that includes all consensus critical data. The reason for this is that otherwise we can't guarantee that the data behind the other roots is actually available. A good alternative seems to be to do all modifications in one fork and make the changes needed for 2. configurable somehow. But as 2. involves changes to the header (add the erasure coded merkle tree data availability scheme), this only makes sense if the header is modular/pluggable in some sense (which kinda brings us back to #1 (comment)).

[liamsi]

There are still open questions or todos around this issue right?

We didn't fully settle on this?

And could we make it so that people can build optimistic rollup chains via Tendermint without LazyLedger?

Although I'm not sure if most that code would't live as a cosmos-sdk module outside of tendermint anyways.

And merging all other roots into a single state root:

That means any other root that is derived from the state of the chain, such as the validator set root, must be folded in to this root.

I mean it is also the job of the app to include all state in AppHash. No modifications in tendermint needed here. Obviously deleting the validator-roots requires changes in tendermint. So I'm still not sure what would be best. I think we should leave this issue open and proceed with tendermint-core and a cosmos-sdk app until we have more clarity around this.

[liamsi]

OK, we actually concluded: one repo for now. This can be closed.