-
Notifications
You must be signed in to change notification settings - Fork 374
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
Conversation
Signed-off-by: Lovesh <[email protected]>
docs/main.md
Outdated
@@ -1,3 +1,18 @@ | |||
Outline of the system | |||
# TODO | |||
#Overview of the system |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicated maintains
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 ....
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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:
- BLS signatures
- timestamps (set by Primary)
- batches of requests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Signed-off-by: Lovesh <[email protected]>
Signed-off-by: Lovesh [email protected]