[DRAFT] Extend 02-client w/ Conditional Clients #939
Conversation
notbdu
requested review from
mpoke,
AdityaSripal,
cwgoes,
colin-axner and
angbrav
as code owners
notbdu
changed the title
| For example, we could have a different client for each of the following functional layers of the blockchain stack: | ||
| * Data availability | ||
| * Sequencing or transaction ordering | ||
| * Execution |
There was a problem hiding this comment.
For IBC, we only really care about execution. ie the app state of the blockchain.
In the modular world, in order to have a client following execution, do we need a client of the other layers?
There was a problem hiding this comment.
The issue from my POV is that to prove execution - you also need to prove sequencing (TO) & data availability (DA) etc.
For example, in the optimistic rollup (ORU) on Celestia case in the simple case you could have:
- A consensus proof from a Celestia client (TMLC) for proof of DA and TO
- A fraud proof from an ORU client (optimistic-LC) for proof of execution
- ORU client depends on Celestia client
- Accepts headers that and starts a fraud window only when the header block has been persisted to the Celestia network
Also, with new shared security primitives like babylon chain (checkpointing on BTC) - you can have dependencies on a babylon client for proof of security/checkpoint.
There was a problem hiding this comment.
in this specific case that you're talking about for ORUs on Celestia, by proving execution are you not also proving DA and TO? since if the data was not available and the txs were not ordered properly (which is verified on the client side), the rollup nodes would reject those txs anyway?
nevertheless, i think proving DA would be necessary since each Celestia rollup can in theory have their own fork choice rule (i.e. 'Sovereign rollups')
There was a problem hiding this comment.
If you don't prove DA before initiating the fraud window you can get the following:
- Accept header optimistically w/o ensuring data is available
- Start fraud window
- Data is withheld so no fraud prover can actually generate a fraud proof
- Invalid header gets accepted after fraud window period
| @@ -536,12 +583,13 @@ Calling `createClient` with the client type and initial consensus state creates | |||
| ```typescript | |||
| function createClient( | |||
There was a problem hiding this comment.
This function in general is out of date. Since we take in a ClientState now.
I think if we refactored this to follow what ibc-go is doing this can be achieved.
Since the clientDependencies will be fields on the ClientState
notbdu
changed the title
There was a problem hiding this comment.
This seems quite plausible to me. The main thing is that the client handler at the 02-layer will need to authorize access to the clientstore(s) that our client is dependent on. I think we would ideally only give read-only access? And in that case, I don't think any permissioning from the dependencies is required.
It would be helpful if there's a more concrete example/use to work off of here
|
Happy to see the changes are clean and minimal! |
There was a problem hiding this comment.
Thank you, @notbdu. I think it would be good to update your fork with the latest from main, since there have been some updates in ICS 02 since you opened the PR.
And just a naming suggestion: instead of conditional clients, what dependent clients?
| Client types MUST define methods to verify membership and non membership proofs. | ||
|
|
||
| ```typescript | ||
| type verifyMembership = ( | ||
| height: Height, | ||
| delayTimePeriod: uint64, | ||
| delayBlockPeriod: uint64, | ||
| proof: []byte, | ||
| path: []byte, | ||
| value: []byte, | ||
| ) => error | ||
|
|
||
| type verifyNonMembership = ( | ||
| height: Height, | ||
| delayTimePeriod: uint64, | ||
| delayBlockPeriod: uint64, | ||
| proof: []byte, | ||
| path: []byte, | ||
| ) => error | ||
| ``` | ||
|
|
||
| Client types MUST define methods to handle client messages for managing state. | ||
|
|
||
| ``` | ||
| type verifyClientMessage(clientMsg: ClientMessage) => error | ||
|
|
||
| type checkForMisbehaviour(clientMsg: ClientMessage) => bool | ||
|
|
||
| type updateStateOnMisbehaviour(clientMsg: ClientMessage) | ||
|
|
||
| type updateState(clientMsg: ClientMessage) => []Height | ||
| ``` |
There was a problem hiding this comment.
These functions are already defined elsewhere in this spec, should we still repeat them here?
| Client types MUST define methods to handle client messages for managing state. | ||
|
|
||
| ``` | ||
| type verifyClientMessage(clientMsg: ClientMessage) => error |
There was a problem hiding this comment.
This function should now also take an extra parameter (dependencies), right? Should we also explain how those dependencies might be used to verify the client message?
Modular blockchains break up a logical blockchain into many constituent parts. To accurately represent these chains and also to account for various types of shared security primitives that are coming up, we need to introduce dependencies between clients.
This is a DRAFT spec change. Opening for discussion.