celestiaorg
Spec out IBC light-client
Summary
We need to fully specify the light-client for cosmos-sdk based rollup chains.
Scope of the Specification
At its core this light-client is similar to any other light-client: it just follows the headers of the chain by downloading the first few bytes that comprise the header from the Data Availability layer (leveraging https://github.com/lazyledger/lazyledger-core/issues/221 like a full-node but only downloading the first few header-size bytes as headers should be of fixed size ideally).
But there are properties and questions around an ORU chain's light-client that need further clarifications:
- the light-client handle needs to handle state transition fraud-proofs
- how long should the client wait to accept a block as final (if there was no fraud proof)
- how do we handle the case the light-client receives a fraud-proof outside of that time-period?
- the relation of the ORU chain light-client to the Data Availability layer:
- presumably, the light-client would also follow the headers of the DA layer
- the possibility to run DA proofs
- handle state transition fraud proofs for the DA layer chain (LL)
The light-client could be configured locally to e.g. not run DA sampling. We need to clearly define the security properties gained by doing this vs. the implications of not doing this. What is the relation between handling state transition fraud proofs for the DA chain and additionally running DA proofs for the data behind the headers of that chain. Are both really required or wouldn't it be sufficiently secure to trust the validator set of the DA layer chain (LL)?
Execution Environment Agnostic Spec
IMO, we also should have a more general and rather execution-environment-agnostic specification of light-clients of rollup chains using LazyLedger as a DA layer in the lazyledger-specs as well. That specification should clearly articulate all requirements of such a client. This would clarify some of the questions around timing and security properties above, too. (cc @adlerjohn)
Then we can have multiple instantiations / more concrete specifications per execution environments we are targeting. IMO, they could also live in the specs repository but the best fit for this issue still seems to be this repository.
As per today's call, we will draft a general IBC rollup client and open a PR with an ICS against the IBC repo. This will help us understanding the impact on other parts of the IBC spec as well as with specifying a full (active) ORU chain light-client. I'm going to start a draft in the following days.
cc @milosevic @adlerjohn @musalbas
https://github.com/rollkit/rollkit/issues/1632#issuecomment-2408212822
