A Secure and Efficient Blockchain Sharding Scheme via.pptx

blockchain

1. A Secure and Efficient Blockchain Sharding Scheme via Hybrid Consensus and Dynamic Management IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 19, 2024

2. Introduction What is blockchain? Blockchain is a shared, immutable ledger that facilitates the process of recording transactions and tracking assets in a business network.  What Is Sharding? In blockchain, sharding refers to a technique that divides the network into smaller partitions, called shards, to improve scalability and increase transaction speed.

3. Introduction Existing Problems: Shrinking Size of Consensus Groups: Issue : Sharding reduces the size of consensus groups within each shard, making them more vulnerable to attacks and compromising consensus security. Current Solutions : Periodic shuffle mechanisms are commonly used to mix validators between shards to mitigate this vulnerability. Limitations : These mechanisms rely on stronger security assumptions and can only provide a probabilistic guarantee of consensus security.

4. Introduction Isolation of Shards: Issue : The isolation of shards makes it difficult to process transactions that involve multiple shards. Current Solutions : Two-Phase Commit (2PC) : A protocol used to ensure atomicity in distributed transactions. Relay Transaction Mechanisms : Transactions are relayed between shards to ensure they are processed across different shards. Limitations : These approaches are vulnerable to double cross-shard attacks, where malicious shards can manipulate transactions. They also fail to achieve immediate atomicity (transaction completion gets delayed).

5. Related Works To handle the consensus shrinkage problem, the existing sharding mechanisms Elastico , Omniledger , and Rapidchain periodically replace nodes of each shard to resist an adversary’s concentrated corruption attacks on a certain shard. Researchers propose mechanisms, such as two-phase commit (2PC) ,relay transactions etc. to handle cross-shard transactions.

6. Proposed Approaches: Hybrid Consensus Mechanism: Solution : Introduces a lightweight global consensus that operates alongside parallel intra-shard consensus processes. 2. Benefits : Cross-Shard Transaction Instant Atomicity : The global consensus allows all consensus nodes to process cross-shard transactions simultaneously, ensuring that all related operations either complete together or not at all. Enhanced Security : By embedding a global consensus, the system can better defend against attacks and ensure consistent and secure processing of transactions.

7. Proposed Approaches: 2. Shard Snapshots and Auditing: Solution : The global consensus records shard snapshots, which are used to facilitate shard auditing. Benefits : This auditing mechanism helps detect and prevent malicious behavior by shards, particularly in the case of double-spending attacks.

8. Proposed Approaches: 3. Dynamic Shard Management Mechanism: Solution : A mechanism to dynamically adjust the number of shards based on the system’s state, reducing transaction congestion. Benefits : This approach maintains an appropriate number of shards to balance transaction throughput and system security, enhancing overall performance.

9. System Model

10. System Model There are two kinds of entities in the system, namely users and validators. Users and validators are divided into multiple shards. The number of shards in the system is represented by the variable K. Users trade with each other and generate transactions both intra-shard and cross-shard. Validators verify the transactions and keep a ledger to record them. A group of validators is randomly selected to form a managing committee (MC)

11. Protocol Design Protocol Overview The protocol operates in fixed time periods called epochs . Epochs: Fixed time periods during which specific tasks are performed. During an Epoch: Validators and new users join the network by solving a hash-based puzzle. Validators create random values using verifiable random functions (VRF) to ensure fairness.

12. Protocol Design(contd.) 2. Managing Committee (MC): Formation: A random group of validators is chosen based on epoch randomness. Responsibilities: The MC manages the shards, adjusts user and validator assignments based on current system status. 3. Two Phases: Transaction Processing Phase: Handles user transactions. Shards Managing Phase: Audits and adjusts shard assignments.

13. Overview Transaction Processing Phase Transaction Pool: Users generate transactions, which are divided into intra-shard and cross-shard transactions. Intra-Shard Transactions: These are verified by shard-specific validators and recorded in intra-shard blocks during the intra-shard consensus process. Cross-Shard Transactions: These require verification by all validators across the system and are recorded in the global block, along with the Block Hashes of all relevant intra-shard blocks, enabling shard auditing. Consensus Process: Validators broadcast global messages with Block Hashes and cross-shard transaction verification results. These messages are then used to determine the legal cross-shard transaction list and execute a hybrid sharding consensus.

14. 2. Shard Managing Phase Shard Adjustment: The managing committee (MC) periodically adjusts shards based on their status. Congested shards are split to improve transaction processing, while underloaded shards are merged to enhance utilization. User Reallocation: A graph partition algorithm is used to strategically transfer users between shards, reducing cross-shard transactions and optimizing shard performance. Shard Auditing: During idle periods, Managing Committee can propose shard audits to detect and punish malicious behaviors like cross-shard double-spending. Validators from other shards verify intra-shard transactions using global block snapshots to prevent tampering. Key Functions: The shard managing phase focuses on dynamic shard adjustment and security auditing to maintain system efficiency and integrity.

15. B. Cross-Shard Transaction Processing Cross-Shard Transaction: A transaction involving multiple shards, where inputs are consumed from one shard and outputs are generated in another, requiring both to verify its validity. Partial Verification : Each related shard checks the local legality of the transaction within its domain (i.e., verifying unspent inputs and valid outputs). Outcome of Partial Verification: Each related shard independently verifies its part of the transaction. If any shard finds an issue (e.g., the UTXO was already spent, or the sum of inputs and outputs doesn't match), it will mark its part of the transaction as invalid in its partial verification result. Final Verification: Validators collect and assess the partial verification results from all related shards. If any part is invalid, the transaction is discarded; otherwise, it's considered valid. Outcome of Final Verification: The cross-shard transaction is either fully accepted or fully rejected based on the combined partial verification results. This ensures that a cross-shard transaction cannot partially succeed in one shard while failing in another—it's all or nothing.

16. C. Hybrid Sharding Consensus Epochs and Slots: The system's time is divided into epochs, each containing multiple slots, where each slot corresponds to a consensus round. Intra-Shard Consensus: - Block Generation: The leader of a shard creates a raw block from valid transactions and broadcasts it. -Block Verification: Validators check the block and send their signatures to the leader. - Block Commit: The leader aggregates signatures, generates the final block with confirmation proof, and broadcasts it. Global Consensus: Handles cross-shard transactions and records shard snapshots. Each shard leader sends a global message containing the cross-shard transaction list and shard snapshot. - Validators then calculate and verify the global block based on these messages. Error Handling: If any issues arises, an error-handling mechanism corrects the global block. Once the majority of nodes sign the global block, it is committed.

17. Intra-Shard Block Generation Verification: The leader of shard A, L A verifies the intra-shard transactions in the transaction pool. Block Creation: L A packs valid transactions into a list, creates a raw intra-shard block RawInB 1 , and computes the block hash BlockHash i Block Structure: The block header includes the hash of the parent block and the Merkle tree root of the block body. RawInB 1 :=⟨ header,IntraShard-txList1​⟩. Broadcast: L A sends the raw intra-shard block RawInB 1 to the other validators in shard A for further processing.

18. 2. Global Block Generation Global Block Generation: - The shard leader L A verifies related cross-shard transactions in the transaction pool. - Valid transactions are packaged into the cross-shard transaction list crTxL 1 . - L A generates the global message ( m 1 = [crTxL 1 || BlockHash 1 ] ) and broadcasts it. - Validators collect global messages ( {m 1 , m 2 } ) to calculate the raw global block, which includes snapshots of two shards and valid cross-shard transactions. Intra-shard Block Verification: - Validators in shard A verify RawInB 1 and respond to L A with their signatures Sig( RawInB 1 ) if valid. Global Block Verification: - Validators in shard A verify m 1 and reply with signatures Sig( RawInB 1 ) and Sig(m 1 ). - Upon receiving more than half of Sig(m 1 ) , L A generates a collective signature CoSi (m 1 ) and broadcasts it. - Validators collect CoSi (m 1 ), CoSi (m 2 ) to confirm the raw global block RawGlB .

19. Contd. Intra-shard Block Commit: - L A collects more than half of Sig( RawInB 1 ) , generates a collective signature, and sends it to validators to finalize and get the final valid intra-shard block InB 1 Global Block Commit: - The global shard leader L G generates a collective signature CoSi ( RawGl B ) after receiving more than half of the signatures and broadcasts it. - Validators finalize the global block Gl B . Error Handling Mechanism: - If a shard leader L i fails to broadcast m i or confirm it before the timeout, validators calculate the global block using the confirmed messages. - The shard snapshot for S i is set to null, and related cross-shard transactions are not processed in that round.

20. D. Shard Auditing Purpose: - To prevent and detect malicious shards attempting cross-shard double-spending attacks. When It Occurs: - Initiated during system idle periods, when transaction activity is low. Process: - Validator Deposit: Validators must submit a deposit before joining the system, which may be penalized if they are found guilty of malicious behavior. - Block Synchronization: Validators synchronize and verify all intra-shard and global blocks from the previous transaction phase. - Verification: Confirm that intra-shard blocks match shard snapshots recorded in global blocks, ensuring no tampering has occurred.

21. D. Shard Auditing (contd.) -Check for cross-shard double-spending by ensuring no duplicate inputs are used in different shards. Detection & Punishment: - Malicious validators involved in double-spending are expelled and fined. Part of their deposit is transferred to the victims, and the remaining validators are reassigned to other shards. - Global Consensus: Validators reach a consensus on the audit results, including the identification and punishment of malicious actors. Cost Analysis: - The auditing process temporarily merges all shards into a single chain, which incurs costs similar to a non-sharded blockchain. - The system benefits most when sharding is used during peak periods, and auditing occurs during low trading periods.

22. E. Dynamic Shard Management The input of the current shards’ composition, including validator and user lists for each shard, the unprocessed transactions within the transaction pool, and system parameters. It outputs an adjusted shards composition. First, it checks whether each shard is a congested shard, which is defined as a shard whose number of unprocessed transactions, including intra-shard and related cross-shard transactions, is higher than the threshold number n c . Subsequently, it splits each congested shard into several smaller shards and keeps the shards with more than s validators. Then it checks for underloaded shard, whose number of unprocessed transactions is less than r · nc . For all underloaded shards, it sorts them according to the transaction queue size, merges the first and last shards, and loops.

23. Results Comparison of transaction throughput of non-sharding scheme, hybrid sharding scheme, the standard Sharding scheme and hybrid sharding scheme with dynamic shard management.