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

Consensus Engine API #4

Merged
merged 8 commits into from Nov 2, 2018

Conversation

@aludvik
Contributor

aludvik commented Mar 15, 2018

Signed-off-by: Adam Ludvik ludvik@bitwise.io

Consensus Engine API
Signed-off-by: Adam Ludvik <ludvik@bitwise.io>
[summary]: #summary
This RFC describes a new Consensus API for supporting both the existing
_Nakamoto-style_ consensus algorithms as _elected leader_ algorithms such as

This comment has been minimized.

@dcmiddle

dcmiddle Mar 15, 2018

typo?
:s/as/as well as

This RFC describes a new Consensus API for supporting both the existing
_Nakamoto-style_ consensus algorithms as _elected leader_ algorithms such as
rBFT.

This comment has been minimized.

@dcmiddle

dcmiddle Mar 15, 2018

PBFT is the general case. rBFT is probably the first PBFT-like consensus we'll add.

These observations led to the creation of the _Consensus Engine_ abstraction,
which can be used to implement any consensus algorithm that is either an
_elected leader_ algorithm or a _Nakamoto-style_ algorithm.

This comment has been minimized.

@dcmiddle

dcmiddle Mar 15, 2018

The hyperledger architecture paper on consensus breaks these methods into lottery (PoET, POW, etc) and voting (PBFT, RBFT, RAFT, etc) based elections. The use of elected leader could be misunderstood. (see https://www.hyperledger.org/wp-content/uploads/2017/08/Hyperledger_Arch_WG_Paper_1_Consensus.pdf)

@askmish askmish self-requested a review Mar 17, 2018

aludvik added some commits Mar 21, 2018

Fix typo
Signed-off-by: Adam Ludvik <ludvik@bitwise.io>
Update consensus language to use voting/lottery
This is to be consistent with the Hyperledger Language

Signed-off-by: Adam Ludvik <ludvik@bitwise.io>
@aludvik

This comment has been minimized.

Contributor

aludvik commented Mar 21, 2018

Pushed some commits to address @dcmiddle comments

The Consensus Engine interface and implementations of the interface should be
reusable in other applications. Specifically, the interface should support
non-blockchain applications.

This comment has been minimized.

@dcmiddle

dcmiddle Apr 6, 2018

This is too vague for me. Can you give an example of why and what non-blockchain app needs this?

This comment has been minimized.

@vaporos

vaporos Apr 21, 2018

Member

For example, it would be nice if we can re-use consensus engines to implement a distributed oracle.

This comment has been minimized.

@aludvik

aludvik Sep 21, 2018

Contributor

Addressed

| Method | Description |
| --- | --- |
| GetSetting(setting) -> data | Read the current value of the setting. Supports R4. |

This comment has been minimized.

@dcmiddle

dcmiddle Apr 6, 2018

Is this a convenience method wrapping GetState(address) or does it imply settings outside of global state?

This comment has been minimized.

@aludvik

aludvik Sep 21, 2018

Contributor

yes

| Method | Description |
| --- | --- |
| OnMessageReceived(message) | Called when a new consensus message is received |
| OnNewBlockReceived(block) | Called when a new block is received and validated |

This comment has been minimized.

@dcmiddle

dcmiddle Apr 6, 2018

Does "and validated" imply that validator will validate transactions before consensus considers whether the block is valid or has precedence?

This comment has been minimized.

@aludvik

aludvik Sep 21, 2018

Contributor

That was what the original design called for. The API was changed to include a CheckBlocks() method which signals to the validator that it should "check that the block can be committed" which allows the validator to send blocks to consensus before they are validated. At this time however, blocks are still validated prior to sending them to consensus. The alternative requires two new feautres: 1. the ability to process all consensus-specific transactions separately from regular transactions and 2. the ability to read, write, and verify state sub-trees.

| Method | Description |
| --- | --- |
| OnMessageReceived(message) | Called when a new consensus message is received |
| OnNewBlockReceived(block) | Called when a new block is received and validated |

This comment has been minimized.

@dcmiddle

dcmiddle Apr 6, 2018

Do you envision sending the entire block or just the block header?

This comment has been minimized.

@aludvik

aludvik Sep 21, 2018

Contributor

In the end, everything but batches are sent.

| --- | --- |
| GetSetting(setting) -> data | Read the current value of the setting. Supports R4. |
| GetState(address) -> data | This is needed to read values from arbitrary addresses used by consensus (eg., validator registry). Supports R5. |
| GetBlock(block_id) -> block | Retrieve consensus-related information about a block. |

This comment has been minimized.

@dcmiddle

dcmiddle Apr 6, 2018

Will this return the entire block or just the block header?

This comment has been minimized.

@aludvik

aludvik Sep 21, 2018

Contributor

In the end, everything but batches are sent.

The Block Publisher handles the creation of blocks. It is directed by the
Consensus Engine on when to do this. When a block is finalized, it is forwarded
to the Block Validator.

This comment has been minimized.

@dcmiddle

dcmiddle Apr 6, 2018

Block Store and Block Cache from the diagram are not defined here. No need for unnecessary work if the definitions remain the same as here: https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture/journal.html.

This comment has been minimized.

@aludvik

aludvik Sep 21, 2018

Contributor

These are not very relevant to the discussion and are superseded by the block manager.

Fix typos
Signed-off-by: Adam Ludvik <ludvik@bitwise.io>
| --- | --- |
| Startup() | Startup and synchronize with any peers if necessary. |
| Shutdown() | Shutdown and notify peers if necessary. |

This comment has been minimized.

@kulkarniamol

kulkarniamol May 13, 2018

How does one register a consensus engine with the validator?

This comment has been minimized.

@aludvik

aludvik Sep 21, 2018

Contributor

This is more detail than I think belongs in the RFC and I will include it in the documentation.

@vaporos

This comment has been minimized.

Member

vaporos commented Sep 18, 2018

This RFC should be updated to match the implementation prior to FCP.

Reflect API changes during implementation
Signed-off-by: Adam Ludvik <ludvik@bitwise.io>

@aludvik aludvik requested review from dcmiddle and vaporos Sep 21, 2018

@danintel

2 comments
1 apparent error (read vs. read/write)

of the fork-resolution logic.
Examples of _lottery_ consensus algorithms include Proof-of-Work (PoW)
and Proof-of-Elapsed-Time (PoET).

This comment has been minimized.

@danintel

danintel Sep 21, 2018

Member

Just a suggestion--I would add "Also known as Nakamoto-style consensus"

coordinate consensus.
Examples of _voting_ algorithms include PBFT, rBFT, Tendermint, and
Raft.

This comment has been minimized.

@danintel

danintel Sep 21, 2018

Member

Just a suggestion--I would add "Also known as classical consensus"

**R5 - Read/Write Access to Global State**
PoET depends on tracking authorized block publishers in global state and
therefore requires read access to a PoET specific namespace.

This comment has been minimized.

@danintel

danintel Sep 21, 2018

Member

Where does the "Write" (from "Read/Write Access") come in here. I think you mean "read/write" access on line 128.

This comment has been minimized.

@aludvik

aludvik Oct 3, 2018

Contributor

This should just say Read

This design borrows some ideas from the [Tendermint ABCI][tendermint] and the
[Parity Consensus Engine][parity] interface.
[tendermint]: https://tendermint.readthedocs.io/en/master/app-development.html#abci-design)

This comment has been minimized.

@kirkwood

aludvik added some commits Oct 3, 2018

Remove Write typo from API
This is not intended to be part of the API.

Signed-off-by: Adam Ludvik <ludvik@bitwise.io>
Fix dead tendermint link
Signed-off-by: Adam Ludvik <ludvik@bitwise.io>
@aludvik

This comment has been minimized.

Contributor

aludvik commented Oct 3, 2018

@danintel @kirkwood addressed your comments.

Add alternative names for consensus types
Signed-off-by: Adam Ludvik <ludvik@bitwise.io>

@dcmiddle dcmiddle requested review from agunde406 and jsmitchell Oct 16, 2018

@dcmiddle

This comment has been minimized.

dcmiddle commented Oct 17, 2018

I move that this RFC enter Final Comment Period with a disposition to merge.

@dcmiddle

This comment has been minimized.

dcmiddle commented Oct 25, 2018

Checkboxes for core team:

@aludvik aludvik merged commit 7822584 into hyperledger:master Nov 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment