Sharding
Sharding은 네트워크를 shard라고 하는 더 작고 관리하기 쉬운 조각으로 나누어 블록체인의 확장성을 향상시키는 데 사용되는 데이터베이스 분할 기술입니다.
Sharding은 블록체인이 초당 더 많은 트랜잭션(TPS)을 처리할 수 있도록 하여 확장성 딜레마를 해결합니다. 모든 노드가 모든 트랜잭션을 검증하는 대신, 노드는 특정 shard에 할당되며, 각 shard는 네트워크 트랜잭션의 하위 집합을 처리합니다. 이 병렬 처리는 처리량을 크게 증가시킵니다. Sharding은 또한 개별 노드의 계산 부담을 줄여 새로운 참가자가 네트워크에 참여하기 쉽게 하고 분산화에 기여합니다. 노드를 shard에 할당하는 방식과 shard 간의 통신 및 보안을 보장하는 방식이 다른 다양한 sharding 구현이 존재합니다.
graph LR
Center["Sharding"]:::main
Rel_transaction_sharding["transaction-sharding"]:::related -.-> Center
click Rel_transaction_sharding "/terms/transaction-sharding"
Rel_eip_4844["eip-4844"]:::related -.-> Center
click Rel_eip_4844 "/terms/eip-4844"
Rel_stablecoin_scalability_solutions["stablecoin-scalability-solutions"]:::related -.-> Center
click Rel_stablecoin_scalability_solutions "/terms/stablecoin-scalability-solutions"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 지식 테스트
🧒 5살도 이해할 수 있게 설명
🍕 Imagine you have a giant 100-meter pizza and only one person to eat it. It would take weeks! Sharding is like cutting that pizza into 100 pieces and inviting 100 people to eat one piece each at the same time. The whole pizza is finished in minutes. In a computer, this means splitting a massive pile of data into smaller piles so many computers can handle it at once.
🤓 Expert Deep Dive
Sharding fundamentally alters the monolithic blockchain architecture by introducing state and transaction partitioning. Instead of a single global state and all full nodes processing every transaction, the network is divided into N shards, each maintaining its own subset of the total state and processing its own transactions.
State Sharding: The entire blockchain state (account balances, smart contract storage) is divided among shards. Each shard s is responsible for a contiguous or hashed portion of the state space, denoted as S_s. A node assigned to shard s only needs to store and process transactions related to its assigned state subset.
Transaction Sharding: Transactions are routed to the shard responsible for their originating account or the state they interact with. This allows for parallel transaction execution. For instance, if a transaction tx involves accounts A and B, and both A and B reside in shard s, then tx is processed exclusively by nodes within shard s.
Cross-Shard Communication: This is a critical challenge. Transactions or smart contract calls that involve state across multiple shards require a robust communication protocol. Common approaches include:
- Asynchronous Message Passing: Shards communicate via receipts or proofs. When shard
s1needs to interact with shards2, it generates a receipt containing relevant transaction data and proofs. Shards2can then process this receipt. This often involves Merkle proofs to verify the integrity of data from other shards. - Receipt Chains: A chain of receipts is maintained, linking cross-shard interactions and ensuring atomicity or eventual consistency.
Consensus Mechanisms: Each shard can employ its own consensus mechanism (e.g., PoS variations, BFT variants) for intra-shard finality. However, a coordinating layer or beacon chain is typically required to aggregate shard block headers, facilitate cross-shard communication verification, and provide overall network security and finality. The beacon chain might run a global consensus protocol that all shards attest to.
Node Assignment & Randomization: Nodes are typically assigned to shards through a randomization process (e.g., using Verifiable Random Functions - VRFs) to prevent single-shard collusion and ensure even distribution of the validator set across shards. This assignment is often dynamic, rotating validators periodically to enhance security.
Security Considerations:
Single-Shard Takeover (1% Attack): If k is the number of shards and V is the total validator set size, a malicious actor might only need to control V/k validators to compromise a single shard. Sharding protocols must implement mechanisms to mitigate this, such as validator randomization, cross-linking, and robust cross-shard verification.
Data Availability: Ensuring that all shard data is available is crucial. Techniques like data availability sampling are employed, where nodes randomly sample shard blocks to verify data availability without downloading the entire block.
Architecturally, sharding transforms a single, computationally bound blockchain into a network of smaller, more manageable blockchains that operate in parallel, significantly increasing the network's capacity and reducing transaction latency.