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

documentation, change log message and method names #524

Merged
merged 2 commits into from
Feb 8, 2018

Conversation

lovesh
Copy link
Contributor

@lovesh lovesh commented Feb 7, 2018

Signed-off-by: Lovesh [email protected]

docs/main.md Outdated
@@ -1,3 +1,18 @@
Outline of the system
# TODO
#Overview of the system
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing space between # and Overview

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

docs/main.md Outdated

- The system maintains maintains a replicated ordered log of transactions called the ledger.
Copy link
Contributor

Choose a reason for hiding this comment

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

Duplicated maintains

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

docs/main.md Outdated
- The system maintains maintains a replicated ordered log of transactions called the ledger.
- Participants of the system which maintain this log are called the nodes. The nodes run a consensus protocol ([RBFT](http://lig-membres.imag.fr/aublin/rbft/report.pdf)) to agree on the order of transactions. For simplicity it can be assumed that one of the node is the leader (primary) which determines the order of transactions and communicates it to the rest of the nodes (followers).
- Each run (3 phase commit) of the consensus protocol orders a batch (collection) of transactions.
- Nodes maintain several ledgers, each for a distinct purpose, it has a pool ledger for node membership transactions like addition of new node, suspension of a node, change of IP/port or keys of a node, a ledger for identity transactions, etc
Copy link
Contributor

Choose a reason for hiding this comment

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

It's better to end the sentence after distinct purpose.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

docs/main.md Outdated
- Nodes maintain several ledgers, each for a distinct purpose, it has a pool ledger for node membership transactions like addition of new node, suspension of a node, change of IP/port or keys of a node, a ledger for identity transactions, etc
- Apart for the ledger, nodes maintain state (for each ledger) which is [Merkle Patricia Trie](https://github.com/ethereum/wiki/wiki/Patricia-Tree). It might maintain several other projections of the ledger. For more on storage, refer the [storage document](storage.md).
- Clients with appropriate permissions can send write requests (transactions) to the nodes but any client can send read requests to the nodes.
- Communicate between nodes and clients and node-to-node happens on [CurveZMQ](http://curvezmq.org/). The codebase has an abstraction called `Stack` that manages communication. It has several variants which offer different features.
Copy link
Contributor

Choose a reason for hiding this comment

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

It's better to say Client-to-node and node-to-node communication happens on ....

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

docs/main.md Outdated
Here the nodes communicate their state and learn other node's states and then if the nodes realise that they are behind, they run a protocol to get the missing transactions. More on this in the [catchup document](catchup.md)
- The nodes can request various protocol-specific messages from other nodes by a `MESSAGE_REQUEST` message.
- When the primary node crashes (or becomes non functional in any way), or it misbehaves by sending bad messages or it slows down then the follower nodes initiate a protocol to change the leader, this protocol is called view change.
View change involves selecting a new leader, which is done in a round robin fashion and communication (and catchup if needed) of state so before the new leader starts, every node has the same state.
Copy link
Contributor

Choose a reason for hiding this comment

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

Please add three more paragraphs explicitly describing how our consensus protocol differs from RBFT one:

  1. BLS signatures
  2. timestamps (set by Primary)
  3. batches of requests

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@ashcherbakov ashcherbakov merged commit da8df8d into master Feb 8, 2018
@lovesh lovesh deleted the overview-doc branch February 13, 2018 21:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants