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.

Sign up for GitHub

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

Update requirements.md #58

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Update requirements.md #58

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
9635268
Update requirements.md
drequinox Oct 16, 2019
d5e9934
Update requirements.md
drequinox Nov 18, 2019
0ea9dd2
Update requirements.md
drequinox Nov 18, 2019
7fad19f
Update requirements.md
drequinox Nov 29, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions docs/requirements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,3 +5,8 @@ The goal of this work is to agree on an interoperable consensus protocol that me
* MUST guarantee timely finality;
* MUST guarantee all of the requirements listed here when operating in eventually synchronous network
* SHOULD have a specification sufficient to enable implemetation without having to refer to someone else's code;
* The consensus algorithm MUST support the following safety and liveness properties
- Agreement — Two different processes MUST decide the same block (agree on the same block).
- Validity — An honest validator MUST have proposed the decided block, and the proposal itself must be a valid block.
Copy link
Contributor

Choose a reason for hiding this comment

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

There exists no consensus protocol that can discriminate whether a block has been proposed by an honest validator or it has been proposed by a Byzantine validator that is acting correctly.
We can only discriminate whether it is a valid block.

Copy link
Contributor

Choose a reason for hiding this comment

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

I suggest changing validity to

  • Validity — The decided block MUST be a valid block.

And adding the following property, which I do not mind how it is called

  • From any point in time, a block proposed by an honest validator will be eventually added to the chain

Copy link
Contributor

Choose a reason for hiding this comment

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

I do not understand the "Validity" requirement above :-(

Copy link
Author

Choose a reason for hiding this comment

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

validity means that the proposed block must have been proposed by a node on the network and must be a valid block. in other words, the finally decided block must have come from a valid node (no out of band message should be accepted). Validity conditions are the same as standard Ethereum, however, consensus algorithm can add its own additional elements in the data structure which can be listed separately. Simply it really means checks under isValidBlock().

Copy link
Author

Choose a reason for hiding this comment

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

I suggest changing validity to

  • Validity — The decided block MUST be a valid block.

And adding the following property, which I do not mind how it is called

  • From any point in time, a block proposed by an honest validator will be eventually added to the chain

I agree with the first one partially, but second part of defintion is more of a liveness / progress realted property. Validity doesnt have to do anything with eventuality of the system. perhaps we can say "Proposed block must have been proposed by a node on the network and must be a valid block"

- Integrity — A process MUST only decide for a block at most once (in a round)
Copy link
Contributor

Choose a reason for hiding this comment

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

An honest process ...

Copy link
Author

Choose a reason for hiding this comment

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

agreed

- Termination — Each honest process MUST eventualy decide (ensuring progress)
Copy link
Contributor

Choose a reason for hiding this comment

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

Any honest process ...

Copy link
Author

Choose a reason for hiding this comment

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

agreed