Skip to content
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

Merged
merged 53 commits into from
May 22, 2019
Merged

ICS 2: Consensus Verification #20

merged 53 commits into from
May 22, 2019

Conversation

mossid
Copy link

@mossid mossid commented Feb 26, 2019

Closes: #25

@mossid mossid added tao Transport, authentication, & ordering layer. wip Issues or pull requests which are in progress. labels Feb 26, 2019
@mossid mossid changed the title WIP: IBC Connection Semantics WIP: Connection Semantics Feb 27, 2019
@cwgoes
Copy link
Contributor

cwgoes commented Mar 4, 2019

Thanks @mossid - this looks more like an implementation spec than a protocol spec, let's see if we can separate concerns (or decide which this will be). Further discussion here: #23.

@cwgoes
Copy link
Contributor

cwgoes commented Mar 5, 2019

The first part of this could be a protocol specification, perhaps - #25.

@cwgoes
Copy link
Contributor

cwgoes commented Mar 5, 2019

Per discussion with @mossid - to be split up into #25 and an implementation spec.

@mossid mossid changed the title WIP: Connection Semantics WIP: Consensus Requirements Mar 5, 2019
@mossid mossid changed the title WIP: Consensus Requirements WIP: ICS 2: Consensus Requirements Mar 5, 2019
@mossid mossid changed the title WIP: ICS 2: Consensus Requirements R4R: ICS 2: Consensus Requirements Mar 6, 2019
@mossid mossid added ready-for-review Pull requests which are ready for review. and removed wip Issues or pull requests which are in progress. labels Mar 6, 2019
@mossid mossid marked this pull request as ready for review March 6, 2019 12:42
Copy link
Contributor

@cwgoes cwgoes left a 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

spec/ics-2-consensus-requirements/README.md Outdated Show resolved Hide resolved
spec/ics-2-consensus-requirements/README.md Outdated Show resolved Hide resolved
spec/ics-2-consensus-requirements/README.md Outdated Show resolved Hide resolved

### 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]`.
Copy link
Contributor

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?

spec/ics-2-consensus-requirements/README.md Outdated Show resolved Hide resolved
spec/ics-2-consensus-requirements/README.md Outdated Show resolved Hide resolved
cwgoes and others added 3 commits March 14, 2019 04:18
Co-Authored-By: mossid <torecursedivine@gmail.com>
Co-Authored-By: mossid <torecursedivine@gmail.com>
@mossid mossid added the wip Issues or pull requests which are in progress. label May 20, 2019
function freezeClient(id, header1, header2)
assert(!get(freezekey(id)))
stored = get(storekey(id))
// TODO
Copy link
Contributor

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.

@cwgoes
Copy link
Contributor

cwgoes commented May 21, 2019

I think we should actually specify the keys being used.

@cwgoes
Copy link
Contributor

cwgoes commented May 21, 2019

This also still needs to be reformatted per #84.

@cwgoes cwgoes added ready-for-review Pull requests which are ready for review. and removed wip Issues or pull requests which are in progress. labels May 21, 2019
Copy link
Contributor

@cwgoes cwgoes left a 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^ should be defined

spec/ics-2-consensus-verification/README.md Outdated Show resolved Hide resolved
### 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
Copy link
Contributor

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

spec/ics-2-consensus-verification/README.md Outdated Show resolved Hide resolved
spec/ics-2-consensus-verification/README.md Outdated Show resolved Hide resolved
##### 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:
Copy link
Contributor

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

spec/ics-2-consensus-verification/README.md Show resolved Hide resolved
spec/ics-2-consensus-verification/README.md Show resolved Hide resolved
spec/ics-2-consensus-verification/README.md Show resolved Hide resolved
##### 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
Copy link
Contributor

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

@cwgoes
Copy link
Contributor

cwgoes commented May 22, 2019

Please fix check_dependencies and check_sections CI failures (ref #84).

You can ignore check_syntax and check_links for now.

@cwgoes
Copy link
Contributor

cwgoes commented May 22, 2019

Merge master and then check_links should also pass now (you might need to fix a few links).

@cwgoes
Copy link
Contributor

cwgoes commented May 22, 2019

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.

@cwgoes cwgoes merged commit e099425 into master May 22, 2019
@cwgoes cwgoes deleted the joon/ics-3-ibc-semantics branch May 22, 2019 19:25
@cwgoes cwgoes mentioned this pull request May 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-for-review Pull requests which are ready for review. tao Transport, authentication, & ordering layer.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICS 2: IBC consensus verification requirements