RapidChain
RapidChain
Claims
•
Improves the scalability and security.
•
Adaptive Byzantine tolerance of 1/3.
Assumptions
•
All committees are less than ½ corrupt the entire time.
•
Synchronous communication
Bootstrap Phase
•
This phase is only ran once.
•
In this phase the nodes elect their root committee via subgroup
elections.
•
The root group then selects the reference committee.
•
Finally, the reference committee randomly sorts the other nodes into
committees which are less than ½ corrupt.
Consensus phase
•
A transaction is submitted to some nodes who route the transaction
to the output committee.
•
The output committee verifies the transactions for a block and
appends it to their chain when they all agree using a gossip protocol.
•
The gossip protocol breaks the block into pieces for speed.
•
This limits a committee to be less than ½ corrupt.
Consensus Details
•
At each iteration each committee picks a leader randomly
•
An iteration consists of 4 synchronous rounds
•
1. The leader gossips a message
•
2. The nodes gossip again with an echo tag
•
3. If leader sent different messages to nodes, nodes tag as pending
and gossip again
•
4. If a node received over ½ good gossips with a single header it
accepts and gossips it again with proof
Consensus Details Continued
•
Nodes remember temporary and permanent votes for blocks through
iterations.
•
Temporary votes are the last echoed block, a permanent vote is a
node’s acceptance of a block
•
Cross-Shard Transactions are performed as follows: a transaction has
two inputs A, B and one output O. If A and B belong to committees
other than the output committee the leader of Cout creates three
new transactions the first two move A and B to Cout and the third
performs the original transaction.
Reconfiguration Phase
•
When an Epoch ends the reference committee must:
•
reorganize the committees with a new randomization,
•
and check proof of works of any node who wishes to participate in
the new epoch.
•
These proof of works take roughly 10 minutes and establish a nodes
identity preventing Sybil attacks (adversary with many identities)
Experiment
•
We simulate networks of up to 4,000 nodes by oversubscribing a set of 32
machines each running up to 125 RapidChain instances. Each machine has a 64-
core Intel Xeon Phi 7210 @ 1.3GHz processor and a 10-Gbps communication link
•
During consensus epochs, nodes communicate through much smaller P2P
overlays created within every committee, where each node accepts up to 16
outgoing connections and up to 125 incoming connections.
•
The leader gossips two different messages in the same iteration with probability
0.49. Also, in our inter-committee routing protocol, 49% of the nodes do not
participate in the gossip protocol (i.e., remain silent).
•
we set ∆ (see Section 3 for the definition) conservatively to 600 ms based on the
maximum time to gossip an 80-byte digest to all nodes in a P2P network of 250
nodes
•
We assume each block of transaction consist of 4,096 transactions, where each
transaction consists of 512 bytes resulting in a block size of 2 MB.
Issues
•
The 1/3-1/2 assumption. They never discuss why 1/3 is chosen or
where it comes from.
•
The network has no means of creating new committees. Their sizes
will grow as new nodes join the network but the number of
committees will always stay the same limiting their throughput
unnecessarily.
1/3 and 1/2 comments
•
“In RapidChain, we use a variant of the synchronous consensus
protocol of Ren et al. [60] to achieve optimal resiliency of f < 1/2 in
committees and hence, allow smaller committee sizes with higher
total resiliency of 1/3 (than previous work [47, 42]).”
•
1/3 is chosen to decrease committee sizes. It seems to be relatively
arbitrary. Most likely the number was chosen, then using the
probability a committee is majority corrupt, a committee size was
chosen that provides a low failure rate.
RapidChain is a protocol designed to enhance scalability and security through adaptive Byzantine tolerance. It employs committees to verify transactions and maintain consensus, with a focus on preventing corruption and enabling cross-shard transactions. The protocol goes through phases like Bootstrap, Consensus, and Reconfiguration to ensure smooth operation and prevent attacks. Experimentation involves simulating networks with thousands of nodes to test the protocol's efficiency and robustness.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Claims Improves the scalability and security. Adaptive Byzantine tolerance of 1/3.
Assumptions All committees are less than corrupt the entire time. Synchronous communication
Bootstrap Phase This phase is only ran once. In this phase the nodes elect their root committee via subgroup elections. The root group then selects the reference committee. Finally, the reference committee randomly sorts the other nodes into committees which are less than corrupt.
Consensus phase A transaction is submitted to some nodes who route the transaction to the output committee. The output committee verifies the transactions for a block and appends it to their chain when they all agree using a gossip protocol. The gossip protocol breaks the block into pieces for speed. This limits a committee to be less than corrupt.
Consensus Details At each iteration each committee picks a leader randomly An iteration consists of 4 synchronous rounds 1. The leader gossips a message 2. The nodes gossip again with an echo tag 3. If leader sent different messages to nodes, nodes tag as pending and gossip again 4. If a node received over good gossips with a single header it accepts and gossips it again with proof
Consensus Details Continued Nodes remember temporary and permanent votes for blocks through iterations. Temporary votes are the last echoed block, a permanent vote is a node s acceptance of a block Cross-Shard Transactions are performed as follows: a transaction has two inputs A, B and one output O. If A and B belong to committees other than the output committee the leader of Cout creates three new transactions the first two move A and B to Cout and the third performs the original transaction.
Reconfiguration Phase When an Epoch ends the reference committee must: reorganize the committees with a new randomization, and check proof of works of any node who wishes to participate in the new epoch. These proof of works take roughly 10 minutes and establish a nodes identity preventing Sybil attacks (adversary with many identities)
Experiment We simulate networks of up to 4,000 nodes by oversubscribing a set of 32 machines each running up to 125 RapidChain instances. Each machine has a 64- core Intel Xeon Phi 7210 @ 1.3GHz processor and a 10-Gbps communication link During consensus epochs, nodes communicate through much smaller P2P overlays created within every committee, where each node accepts up to 16 outgoing connections and up to 125 incoming connections. The leader gossips two different messages in the same iteration with probability 0.49. Also, in our inter-committee routing protocol, 49% of the nodes do not participate in the gossip protocol (i.e., remain silent). we set (see Section 3 for the definition) conservatively to 600 ms based on the maximum time to gossip an 80-byte digest to all nodes in a P2P network of 250 nodes We assume each block of transaction consist of 4,096 transactions, where each transaction consists of 512 bytes resulting in a block size of 2 MB.
Issues The 1/3-1/2 assumption. They never discuss why 1/3 is chosen or where it comes from. The network has no means of creating new committees. Their sizes will grow as new nodes join the network but the number of committees will always stay the same limiting their throughput unnecessarily.
1/3 and 1/2 comments In RapidChain, we use a variant of the synchronous consensus protocol of Ren et al. [60] to achieve optimal resiliency of f < 1/2 in committees and hence, allow smaller committee sizes with higher total resiliency of 1/3 (than previous work [47, 42]). 1/3 is chosen to decrease committee sizes. It seems to be relatively arbitrary. Most likely the number was chosen, then using the probability a committee is majority corrupt, a committee size was chosen that provides a low failure rate.
