Repositories structuring about celestia-core

[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]

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

[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

[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.