-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICS 2: Consensus Verification #20
Conversation
The first part of this could be a protocol specification, perhaps - #25. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should probably omit connections and channels from the scope of this ICS, and focus only on consensus requirements, notably:
- More formally specifying the four properties in terms of the sets of accepted headers (the properties themselves seem accurate to me)
- Rename "block" to "header" or something (there's not necessarily a need for headers to correspond to blocks)
- Provide examples of "headers" for Tendermint-esque blockchains, "headers" for trivial IBC sources (just a signing key), their verification algorithms
|
||
### Example Implementation | ||
|
||
An example blockchain `B` is run by a single operator. If a block is signed by the operator, then it is valid. `B` contains `KVStore`, which is a mapping from `[byte]` to `[byte]`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good example - I find the pseudocode a bit confusing though, can we make it a bit more like the ICS 1 example?
Co-Authored-By: mossid <torecursedivine@gmail.com>
Co-Authored-By: mossid <torecursedivine@gmail.com>
function freezeClient(id, header1, header2) | ||
assert(!get(freezekey(id))) | ||
stored = get(storekey(id)) | ||
// TODO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is "TODO"? We just need to mark the client as frozen.
I think we should actually specify the keys being used. |
This also still needs to be reformatted per #84. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see unaddressed comments (look at the diff view).
|
||
This standard specifies the properties that consensus algorithms of chains implementing IBC are | ||
expected to satisfy. The properties are needed for efficient and safe verification in the higher | ||
level protocol abstractions. The algorithm which uses these properties to verify substates of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^ should be defined
### Motivation | ||
|
||
Light clients are the verification method of IBC protocol. One chain can track another chain's | ||
updating state with a light client pointing to that chain. This standard formalises the common |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still needs to be addressed
##### Preliminaries | ||
|
||
`newID` is a function which generates a new `Identifier` for a `LightClient`, which MAY depending | ||
on the `Header`. The behaviour of `newID` is implementation specific. Possible implementations are: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still needs to be addressed
##### Update | ||
|
||
Updating `LightClient` is done by submitting a new `Header`. The `Identifier` is used to point the | ||
stored `LightClient` that the logic will update. When the new `Header` is verifiable with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still needs to be addressed
Co-Authored-By: Christopher Goes <cwgoes@pluranimity.org> Co-Authored-By: gamarin2 <gautier@tendermint.com>
… joon/ics-3-ibc-semantics
Please fix You can ignore |
Merge master and then |
I think there needs to be some more work on unification with ICS 3 / 4 / 25, but that can happen in a follow-up PR. |
Closes: #25