Update requirements.md #58
Conversation
docs/requirements.md
Outdated
| @@ -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. | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
I do not understand the "Validity" requirement above :-(
There was a problem hiding this comment.
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().
There was a problem hiding this comment.
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"
|
I have updated the requirements, please review. |
docs/requirements.md
Outdated
| @@ -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 (no two processes decide different blocks). | |||
There was a problem hiding this comment.
I suggest changing it with:
Any two honest processes MUST decide the same block (no two honest processes decide different blocks)
docs/requirements.md
Outdated
| @@ -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 (no two processes decide different blocks). | |||
| - Validity — If a process decides on a block, then that block must have been proposed by some process. Secondly the proposal itself must be a valid block. | |||
There was a problem hiding this comment.
If an honest process ...
docs/requirements.md
Outdated
| * The consensus algorithm MUST support the following safety and liveness properties | ||
| - Agreement — Two different processes MUST decide the same block (no two processes decide different blocks). | ||
| - Validity — If a process decides on a block, then that block must have been proposed by some process. Secondly the proposal itself must be a valid block. | ||
| - Integrity — A process MUST only decide for a block at most once (in a round) |
There was a problem hiding this comment.
An honest process ...
docs/requirements.md
Outdated
| - Agreement — Two different processes MUST decide the same block (no two processes decide different blocks). | ||
| - Validity — If a process decides on a block, then that block must have been proposed by some process. Secondly the proposal itself must be a valid block. | ||
| - Integrity — A process MUST only decide for a block at most once (in a round) | ||
| - Termination — Each honest process MUST eventualy decide (ensuring progress) |
There was a problem hiding this comment.
Any honest process ...
Proposing the safety and liveness properties of the consensus algorithm