Sharding được ca ngợi rộng rãi như một giải pháp cho khả năng mở rộng của Ethereum.
MỤC LỤC BÀI VIẾT
Vấn đề mở rộng Blockchain
Có hai cách để tăng thông lượng giao dịch của Blockchain:
- Cách thứ nhất, mở rộng theo chiều dọc – Vertical Scalability.
- Cách thứ hai, mở rộng theo chiều ngang – Horizontal Scalability.
Mở rộng theo chiều dọc (Vertical Scalability)
Cách thứ nhất, để đạt được thông lượng cao hơn thì Blockchain yêu cầu các Node trong mạng phải cực kỳ mạnh mẽ để có xử lý nhanh và nhiều giao dịch hơn. Nó đồng nghĩa với việc người dùng phải bỏ nhiều chi phí cho phần cứng và điều này không phù hợp với đại đa số người dùng phổ thông, nó thích hợp với các cá nhân & tổ chức có tài chính vững chắc và có nền tảng kỹ thuật vững vàng.
Solana và Internet Computer đã tiếp cận theo hướng này, trong cả hai Blockchain này, người dùng bình thường không thể xác thực Blockchain trên phần cứng bình thường.
Điều này không hẳn là xấu, các Public Blockchains được mở rộng theo chiều dọc có thể phù hợp với một số ứng dụng nhất định yêu cầu hiệu suất cao và trạng thái nhất quán. Nhưng nhược điểm của cách tiếp cận này là làm cho quá trình xác thực giao dịch kém phân quyền.
Mở rộng theo chiều ngang (Horizontal Scalability).
Ngược lại với cách tiếp cận trên, mở rộng theo chiều ngang là cách chia hệ thống thành nhiều phân đoạn (Shards). Mỗi phân đoạn chỉ thực hiện một tập hợp con của tổng số công việc trên Blockchain, và mỗi Validator chỉ cần xác thực phân đoạn đơn đó và một số phân đoạn khác.
Điều này cho phép nhiều người dùng hơn tham gia vào quá trình xác thực, do các yêu cầu thấp hơn cho mỗi phân đoạn. Tổng thể, cách tiếp cận này giữ cho việc xác thực giao dịch được phân quyền, trong khi vẫn mở rộng tổng thông lượng của hệ thống.
Tầm nhìn Ethereum 2.0 & Công nghệ Sharding là gì?
Vấn đề cốt lõi của Ethereum đặt ra để giải quyết là làm cách nào để có khả năng xử lý nhiều giao dịch hơn trên mỗi giây nhưng vẫn giữ được sự phân quyền và an toàn của mạng. Đây là một vấn đề vô cùng khó giải quyết và các nhà phát triển Ethereum đã suy nghĩ về nó trong nhiều năm.
Câu trả lời cho bài toán trên chính là mở rộng hệ thống theo chiều ngang, một nền tảng Smart Contract được phân mảnh tùy ý. Đây chính là tầm nhìn mà Ethereum 2.0 đã mô tả.
Ethereum 2.0 là một trong những cách tiếp cận rất phức tạp để mở rộng quy mô cho Ethereum network, nó đòi hỏi nhiều công sức để thiết kế và thực hiện. Tuy nhiên, nếu được thực hiện thành công, Ethereum 2.0 cũng sẽ là một trong những cách hiệu quả nhất, giúp tăng thông lượng của Ethereum theo cấp độ lớn.
Sharding, hay phân mảnh, là một trong những công nghệ cốt lõi của Ethereum 2.0. Ở Ethereum 1.0, mỗi Node lưu trữ một bản sao của toàn bộ Blockchain Ethereum. Bất kỳ khi nào nó được mở rộng, mỗi Node phải cập nhật, điều này sẽ tiêu tốn băng thông và bộ nhớ của hệ thống.
Với Sharding, Ethereum sẽ được chia thành nhiều mảnh. Mỗi mảnh (Shard) sẽ xử lý các giao dịch và hợp đồng của riêng chúng, nhưng tổng thể các mảnh vẫn có thể giao tiếp với các phân đoạn khác. Vì mọi mảnh xác thực độc lập nên chúng không cần phải lưu trữ dữ liệu từ các Shard khác.
Những thách thức và rủi ro tiềm ẩn của Sharding
Mặc dù là lời giải cho bài toán Scalability Trilemma, nhưng Sharding lại đem đến những bài toán khác cho Ethereum và cộng đồng nhà phát triển.
Một cách dễ hiểu, Sharding sẽ chia Ethereum thành rất nhiều mảnh. Mỗi mảnh có thể làm một việc riêng, các giao thức DeFi sẽ có xu hướng tập trung trên cùng một mảnh để hưởng lợi ích từ sự phối hợp. Điều này có thể dẫn đến sự gia tăng gas fee trên một số mảnh.
Vì các giao thức trên các mảnh khác nhau muốn giao tiếp với nhau thì sẽ phải sử dụng một số giao thức tương tác. Đương nhiên việc này sẽ phức tạp hơn việc tương tác giữa 2 giao thức trong cùng một mảnh.
Bên cạnh đó, Sharding cũng đem lại một số rủi ro tiềm ẩn cho mạng, nó cho phép Hacker phá hủy một hệ sinh thái đang phát triển mạnh mẽ bằng cách tấn công một mảnh bất kỳ trong mạng. Nếu một mảnh bị Hacker chiếm đoạt, nó có thể gây ra hiệu ứng Domino và gây ảnh hưởng tiêu cực đến giá Token, một lượng lớn người dùng và các Node trên mảnh đó.
