Replies: 1 comment
-
So I guess there are two cases here.
In the first case, I think you basically need a different client spec for the connection where the chain does a look back to it's earlier tendermint header state. Because ABCI doesn't allow this, IBC uses the historical header module to the cosmos sdk to store old Tendermint headers which serve a different purpose in the normal IBC. For the second case, I expect that both the ORU and normal Tendermint chain will need IBC clients for the tendermint light client but the ORU connection will have a different proof structure to that will route from the Tendermint header into the off chain sequencer state. |
Beta Was this translation helpful? Give feedback.
-
Composability
Something we have not fully fledged out yet is how Optimistic Rollup (ORU) chains will "talk" to each other, or more nicely said, the composability of the whole system of LL and ORU chains.
IBC and ORU "zones"
As we are specifically looking at chains built with the Cosmos-SDK we need to understand the implications of using IBC in between these chains. They are kinda special as they do not really run any consensus themselves. If they were instead running tendermint, we could simply use the tendermint client:
https://github.com/cosmos/ibc/tree/master/spec/client/ics-007-tendermint-client
Something that almost looks like a chain without consensus is the solo-machine client:
https://github.com/cosmos/ibc/tree/master/spec/client/ics-006-solo-machine-client
Note that this seems to be "reputation-based". Meaning that you'd need to trust the signature of the solo machine. We are currently assuming that for a first version of the sdk-based ORU chains, they will certainly have to know the set of signers upfront. Which is also very similar to my understanding.
But we need to understand the tradeoffs the latter makes much better! My gut feeling is that what we need is in between tendermint and the solo machine client (although closer to the latter) and including a light-client of the LL main chain that additionally checks Data Availability proofs.
Fraud proofs & evidence
Another aspect we need to consider are state transition fraud-proofs. IBC, defines
ClientMisbehaviour
which contains any evidence and a handlerhandleClientMisbehaviour
to act upon that evidence: https://github.com/cosmos/ibc/blob/master/spec/core/ics-026-routing-module/README.md#client-lifecycle-managementIMO, this looks like we can fit in state transition fraud proofs in there too.
We haven't fully specified the data structures for state transition fraud proofs, nor how exactly the implementation of them will look like but it should really be straight-forward. For a formal definition, see "4.3 Proof of Invalid State Transition" in https://fc21.ifca.ai/papers/83.pdf
I'm opening this discussion to gather question, feedback, and ideas which will be turned into concrete issues containing action items shortly. Tagging a few people with deep knowledge on IBC: @fedekunze @cwgoes @ValarDragon @zamanian @ebuchman @ethanfrey
Beta Was this translation helpful? Give feedback.
All reactions