Sharding là gì?

01 Sharding là gì?

Vấn đề cơ bản của blockchain scalability: mọi node đều phải download, verify và lưu trữ mọi transaction. Khi network lớn lên, yêu cầu phần cứng của node tăng vô hạn — đây là bottleneck không thể giải quyết bằng cách chỉ nâng cấp hardware.

Sharding giải quyết bằng cách chia nhỏ blockchain thành nhiều shard (phân mảnh). Mỗi node chỉ cần xử lý và lưu trữ một phần nhỏ của toàn bộ data. Các shard chạy song song → throughput tổng thể tăng gần tuyến tính theo số shard.

Sharding là một trong ba hướng scaling L1 chính, bên cạnh tăng block size (Bitcoin vs BCH debate) và giảm block time (có giới hạn bởi network latency). Và là hướng phức tạp nhất về mặt kỹ thuật.

02 Database Sharding — Gốc Rễ Khái Niệm

Sharding không phải khái niệm mới của blockchain — nó đến từ distributed database engineering, nơi các công ty như Google, Amazon, Facebook đã dùng từ những năm 2000.

Horizontal vs Vertical Partitioning

• Vertical partitioning (Column sharding): Tách các cột khác nhau ra database riêng. Ví dụ: user profile DB và user transaction DB riêng biệt.
• Horizontal partitioning (Row sharding): Tách các row theo key (ví dụ: user_id % N) ra N database riêng. Đây là sharding theo nghĩa phổ biến nhất.

Sharding Key

Quyết định quan trọng nhất: dùng key nào để shard? Một key tốt phải phân bổ data đều, tránh "hot shard" (một shard nhận quá nhiều request). Blockchain thường dùng account address hoặc transaction hash làm sharding key.

Cross-shard Queries — Vấn đề muôn thuở

Trong database sharding, truy vấn cần data từ nhiều shard phải thực hiện distributed join — tốn kém và phức tạp. Đây cũng là vấn đề tương tự trong blockchain sharding: cross-shard transaction phức tạp hơn in-shard transaction nhiều lần.

03 Blockchain Sharding — Các Thách Thức Đặc Trưng

Blockchain sharding khó hơn database sharding nhiều vì có thêm các ràng buộc về security và decentralization:

1. Security per Shard

Nếu blockchain có 100 validator và chia thành 10 shard, mỗi shard chỉ có ~10 validator. Kẻ tấn công chỉ cần kiểm soát 5/10 validator của một shard để tấn công shard đó. Bảo mật giảm đáng kể so với chain không sharding.

Giải pháp: random validator assignment — validator được assign ngẫu nhiên vào shard mỗi epoch, ngăn kẻ tấn công tập trung vào một shard cụ thể. Nhưng cần validator set đủ lớn để statistical security vẫn đảm bảo.

2. Cross-shard Communication

Trong DeFi, một giao dịch phức tạp có thể cần tương tác với nhiều contract trên nhiều shard. Nếu A gọi B và B gọi C (mỗi cái trên shard khác), đây là vấn đề distributed transaction với atomicity cực kỳ khó đảm bảo.

3. State Availability

Ai đảm bảo data của một shard không bị withhold? Nếu validator một shard giữ data lại (data withholding attack), các shard khác không thể verify giao dịch cross-shard. Đây là lý do Data Availability Sampling (DAS) quan trọng.

4. Shard Takeover Attack

Kẻ tấn công tập trung tài nguyên vào một shard nhỏ để kiểm soát hoàn toàn — sau đó tạo invalid state và bridge token giả sang shard khác. Cần cơ chế fraud proof cross-shard hoặc validity proof để ngăn chặn.

04 Execution Sharding vs Data Availability Sharding

Có hai loại sharding hoàn toàn khác nhau về mục đích và độ phức tạp:

Execution Sharding

Chia nhỏ computation — mỗi shard chạy EVM (hay VM tương đương) độc lập, xử lý transaction riêng. Giải quyết bottleneck computation. Nhưng phức tạp cực kỳ: cross-shard call, atomic transaction, shared state consistency đều là vấn đề open research.

Data Availability Sharding

Chỉ shard bandwidth lưu trữ data — không chia nhỏ computation. Mỗi node chỉ download và lưu một phần data, nhưng có thể verify toàn bộ chain nhờ Data Availability Sampling (DAS) và Erasure Coding.

Đây là hướng Ethereum đang theo đuổi (Danksharding): tăng DA bandwidth cho Rollup, không cần execution sharding phức tạp vì Rollup đã xử lý execution.

05 Ethereum Sharding History — Hành Trình Từ Bỏ Execution Sharding

Câu chuyện sharding của Ethereum là bài học kinh điển về sự thay đổi chiến lược kỹ thuật:

2015–2018: The Original Vision

Ethereum whitepaper và các post của Vitalik phác thảo hệ thống 100 shard, mỗi shard chạy EVM riêng, cross-shard communication qua receipt mechanism. Đây là "Phase 2" trong Ethereum roadmap ban đầu.

2019–2020: Complexity Acknowledged

Nhóm nghiên cứu Ethereum nhận ra execution sharding cực kỳ khó: cross-shard composability phá vỡ DeFi use case (không thể atomic swap cross-shard), shard security thấp hơn, developer experience tệ. Đề xuất shard count giảm từ 1024 → 64.

2020: The Pivot — Rollup-Centric Roadmap

Vitalik công bố "A Rollup-Centric Ethereum Roadmap" — thay đổi chiến lược hoàn toàn: không làm execution sharding, thay vào đó dùng Rollup làm execution layer và Ethereum L1 tập trung vào DA + consensus. Sharding chỉ áp dụng cho DA (blob storage) — đơn giản hơn nhiều.

2024: EIP-4844 — Bước Đầu

EIP-4844 (Proto-Danksharding) launch tháng 3/2024: 3–6 blob mỗi block (~0.375 MB extra DA). Giảm phí L2 80–90%. Đây là bước đầu tiên của DA sharding, không phải execution sharding.

06 Danksharding — Tương Lai DA của Ethereum

Danksharding (đặt theo Dankrad Feist, researcher tại Ethereum Foundation) là phiên bản đầy đủ của DA sharding cho Ethereum.

Mục tiêu

Tăng DA bandwidth từ 3–6 blob (EIP-4844) lên 64–256 blob mỗi block — khoảng 1–4 MB blob data mỗi 12 giây. Đủ để support hàng trăm Rollup với throughput cao mà không cần mỗi node download toàn bộ blob data.

Hai thành phần kỹ thuật cốt lõi

• Data Availability Sampling (DAS): Light node sample ngẫu nhiên một số nhỏ chunk của blob. Nếu sample thành công với xác suất cao → blob data available. Không cần download toàn bộ.
• KZG Polynomial Commitments: Mỗi blob được commit bằng KZG polynomial — cho phép verify bất kỳ chunk nào mà không cần toàn bộ data. Tương tự ZK proof cho DA.

Proposer-Builder Separation (PBS) tích hợp

Danksharding full yêu cầu PBS (tách block proposer và builder) để quản lý bandwidth lớn hiệu quả. Builder chịu trách nhiệm aggregate và distribute blob data; proposer chỉ cần verify DA sampling. Xem thêm PBS là gì.

07 NEAR Nightshade — Execution Sharding Thực Chiến

NEAR Protocol là một trong số ít blockchain đã triển khai execution sharding thực tế, dùng kiến trúc gọi là Nightshade.

Cách Nightshade hoạt động

NEAR chia account space thành 4 shard (có thể tăng). Mỗi account thuộc một shard nhất định dựa trên account ID. Validator được assign ngẫu nhiên vào shard mỗi epoch.

Điểm đặc biệt: từ góc nhìn của block producers, blockchain vẫn là một chain duy nhất — mỗi block chứa "chunk" của mỗi shard. Block producers collect chunks từ shard validators và merge thành một block.

Cross-shard Transaction

Khi contract trên Shard A gọi contract trên Shard B, NEAR dùng async receipt mechanism: Shard A tạo receipt, Shard B xử lý receipt ở block tiếp theo (delay 1 block per hop). Đây là eventual consistency — không atomic nhưng đơn giản hơn 2-phase commit.

Kết quả thực tế

NEAR đã scale lên hàng triệu user trong các sự kiện như HOT Wallet (2024) mà không bị tắc nghẽn như Ethereum mainnet. Throughput đạt ~100,000 TPS lý thuyết với sharding đầy đủ, thực tế vài nghìn TPS sustained.

08 Sharding và Security Trade-offs

Sharding không free — nó tạo ra các trade-off bảo mật quan trọng cần hiểu:

The 1% Attack Problem

Nếu chain có 1,000 validator và 100 shard, mỗi shard có ~10 validator. Attacker chỉ cần 6/10 validator (~60% của 1 shard) để kiểm soát shard đó. Với chain không sharding, attacker cần 600/1,000 (60% tổng). Số tuyệt đối giống nhau nhưng attacker có thể tập trung tấn công 1 shard thay vì toàn chain.

Random Assignment — Giải pháp và Giới hạn

Random validator assignment mỗi epoch giải quyết bằng thống kê: nếu validator assign ngẫu nhiên, xác suất attacker kiểm soát 51% một shard trong nhiều epoch liên tiếp rất thấp — nếu tổng validator đủ lớn và % attacker thấp đủ.

Ethereum dùng committees (~512 validator/committee) với random assignment từ RANDAO + VDF — đủ bảo mật cho DA sampling, không cần execution sharding vốn có security assumption cao hơn.

Adaptive Adversary

Với adversary đủ kiên nhẫn, họ có thể tích lũy validators vào shard target theo thời gian dù có random assignment. Đây là nghiên cứu mở về "adaptive adversary" trong sharding security model.

09 Sharding vs Rollup — Hai Con Đường Scaling

Hai hướng scaling blockchain L1 phổ biến nhất, với những đánh đổi hoàn toàn khác nhau:

Ethereum chọn Rollup path vì độ phức tạp thấp hơn và có thể triển khai sớm hơn. NEAR, Zilliqa chọn native sharding vì muốn unified state trên L1. Cả hai hướng đều hợp lý — phụ thuộc vào priority của team.

Kết hợp tốt nhất hiện tại: Rollup xử lý execution + Danksharding cung cấp DA rẻ → throughput cao, bảo mật L1, không cần execution sharding phức tạp. Đây là cược chiến lược của Ethereum.

10 Câu hỏi thường gặp (FAQ)