Locality-Based Sharding Protocol for Permissioned Blockchains
"GeoChain is a focused sharding protocol designed for permissioned blockchains to enhance scalability. It uses a regional code to form shards based on participants' geographical positions, improving network efficiency and reliability. System models ensure reliable communication channels for crash and Byzantine failure models under a partially synchronous network setup."
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
GeoChain: A Locality-Based Sharding Protocol for Permissioned Blockchains Chunyu Mao and Wojciech Golab
GeoChain GeoChain is a locality-based full sharding protocol designed for permissioned blockchains
GeoChain GeoChain is a locality-based full sharding protocol designed for permissioned blockchains (they re trying to improve scalability of permissioned blockchains)
System Model partially synchronous network
System Model partially synchronous network assume reliable point-to-point communication channels
System Model partially synchronous network assume reliable point-to-point communication channels permissioned network
System Model partially synchronous network assume reliable point-to-point communication channels permissioned network at least 2f + 1 participants under the crash failure model and 3f + 1 under the Byzantine failure model
System Model partially synchronous network assume reliable point-to-point communication channels permissioned network at least 2f + 1 participants under the crash failure model and 3f + 1 under the Byzantine failure model each client coordinates its own transactions the transaction follows the UTXO model
How Full Sharding is Achieved each shard is formed based on a regional code (i.e., a cluster classifier) that indicates the geographical position of participants (e.g., IP address or peer-to- peer network latency)
How Full Sharding is Achieved each shard is formed based on a regional code (i.e., a cluster classifier) that indicates the geographical position of participants (e.g., IP address or peer-to- peer network latency) this is done by system administrators when participants establish their identity
How Full Sharding is Achieved each shard is formed based on a regional code (i.e., a cluster classifier) that indicates the geographical position of participants (e.g., IP address or peer-to- peer network latency) this is done by system administrators when participants establish their identity leveraging geographical properties in shard formation optimizes inter-shard performance
Transaction Data Structure transactions include not only UTXO inputs and outputs but, also, the shard information the transaction belongs to shard information is used to decide which shard handles the transaction
Transaction Data Structure transactions include not only UTXO inputs and outputs but, also, the shard information the transaction belongs to shard information is used to decide which shard handles the transaction incorporating locality in transaction data reduces ratio of cross-shard transactions
Cross-shard Transactions their protocol that deals with cross-shard transactions, inputs to output cross- shard commit (IOCC), is client driven
Cross-shard Transactions their protocol that deals with cross-shard transactions, inputs to output cross- shard commit (IOCC), is client driven they assume that the UTXOs have equal value across different shards and require each client to know where its transaction belongs
IOCC there are two main steps suppose a client who has UTXOs in Shard 1 and Shard 2 wants to make a transaction to Shard 3 Client Shard 1 Shard 2 Shard 3
IOCC: Step 1 client gathers inputs and proposes a transfer transaction for each input in Shard 1 and Shard 2 transfer transactions Client tx1 tx2 Shard 1 Shard 2 Shard 3
IOCC: Step 1. (continued) the client requires a proof from those Shard 1 and Shard 2: tx1 and tx2 , respectively a proof is a quorum certificate, a collection of transaction commitments from the participants of the input shard, which can be verified by the destination shard Client tx1 tx2 Shard 1 Shard 2 Shard 3
IOCC: Step 1. (continued) the client requires a proof from those Shard 1 and Shard 2: tx1 and tx2 , respectively a proof is a quorum certificate, a collection of transaction commitments from the participants of the input shard, which can be verified by the destination shard a proof has to have certificates from at least a majority of shard participants: f + 1 out of 2f + 1 under the crash failure model and 2f + 1 out of 3f + 1 under the Byzantine failure model Client tx1 tx2 Shard 1 Shard 2 Shard 3
IOCC: Step 1. (continued) the client requires a proof from those Shard 1 and Shard 2: tx1 and tx2 , respectively a proof is a quorum certificate, a collection of transaction commitments from the participants of the input shard, which can be verified by the destination shard a proof has to have certificates from at least a majority of shard participants: f + 1 out of 2f + 1 under the crash failure model and 2f + 1 out of 3f + 1 under the Byzantine failure model NOTE: once a valid proof is generated, the UTXO in the input shard is marked as transferred and cannot be rolled back Client tx1 tx2 Shard 1 Shard 2 Shard 3
IOCC: Step 2 client appends the proofs to the original inputs and forms a new transaction, tx1 + tx2 tx1 + tx2 is proposed to and processed by the destination shard, Shard 3 Client tx1 + tx2 Shard 1 Shard 2 Shard 3
IOCC: Step 2 client appends the proofs to the original inputs and forms a new transaction, tx1 + tx2 tx1 + tx2 is proposed to and processed by the destination shard, Shard 3 Shard 3 verifies the proofs w/o communicating to Shard 1 or Shard 2 and confirms the validity of the transaction Client tx1 + tx2 Shard 1 Shard 2 Shard 3
Performance Evaluation they implemented a prototype of GeoChain on top of Hyperledger Fabric v2.3 (permissioned blockchain) and evaluate the protocol on Amazon EC2
Performance Evaluation they implemented a prototype of GeoChain on top of Hyperledger Fabric v2.3 (permissioned blockchain) and evaluate the protocol on Amazon EC2 nodes are assigned into a shard according to their geographical property: datacenter each shard comprises a non-overlapping subset of peer nodes and orderer nodes
Performance Evaluation they implemented a prototype of GeoChain on top of Hyperledger Fabric v2.3 (permissioned blockchain) and evaluate the protocol on Amazon EC2 nodes are assigned into a shard according to their geographical property: datacenter each shard comprises a non-overlapping subset of peer nodes and orderer nodes each shard runs an independent ordering service that employs the RAFT consensus protocol
Performance Evaluation they implemented a prototype of GeoChain on top of Hyperledger Fabric v2.3 (permissioned blockchain) and evaluate the protocol on Amazon EC2 nodes are assigned into a shard according to their geographical property: datacenter each shard comprises a non-overlapping subset of peer nodes and orderer nodes each shard runs an independent ordering service that employs the RAFT consensus protocol each shard maintains a unique channel that builds a shard ledger channel-specific endorsement policy is defined as majority which means that at least (? + 1)/2 endorsers have to correctly endorse a transaction
Performance Evaluation they implemented a prototype of GeoChain on top of Hyperledger Fabric v2.3 (permissioned blockchain) and evaluate the protocol on Amazon EC2 nodes are assigned into a shard according to their geographical property: datacenter each shard comprises a non-overlapping subset of peer nodes and orderer nodes each shard runs an independent ordering service that employs the RAFT consensus protocol each shard maintains a unique channel that builds a shard ledger channel-specific endorsement policy is defined as majority which means that at least (? + 1)/2 endorsers have to correctly endorse a transaction they developed a chaincode that mimics a simplified UTXO transaction
Set Up transactions are uniformly distributed to each shard
Set Up transactions are uniformly distributed to each shard for each shard, there are 3 peers and 3 orderers, which is the minimum requirement to tolerate the failure of one peer and one orderer
Set Up transactions are uniformly distributed to each shard for each shard, there are 3 peers and 3 orderers, which is the minimum requirement to tolerate the failure of one peer and one orderer batching time to wait before creating a block is set to 100ms
Set Up transactions are uniformly distributed to each shard for each shard, there are 3 peers and 3 orderers, which is the minimum requirement to tolerate the failure of one peer and one orderer batching time to wait before creating a block is set to 100 ms a block can include up to 100 messages while the maximum number of bytes allowed for the messages in a block is 10MB
Experiment 1 ratio of cross-shard transactions in this experiment, they grouped the network across multiple AWS EC2 data centers located on different continents: United States East, South America East, and Central Europe
Experiment 2 ratio of cross-shard transactions
Performance Evaluation Summary their protocol maintains equal or higher throughput, even with a high ratio of cross- shard transactions, while minimizing the transaction latency
