Một cách diễn giải đơn giản cho hai thuật ngữ vô cùng khó hiểu về mở rộng quy mô cho Ethereum, đó là Sharding và Danksharding.
Giải thích về Sharding và Danksharding
Hôm nay là một ngày tồi tệ, vì máy chấm công lại tiếp tục ghi nhận bạn trễ làm mười phút. Tổng cộng trong tháng này, bạn đã trễ làm tổng cộng hai mươi ngày.
Lí do? Cả tòa nhà chỉ có độc nhất một chiếc thang máy, nhưng văn phòng của bạn lại nằm ở tầng thứ mười. Vì vậy việc xếp hàng, chờ đợi, và bị trễ giờ làm là một việc không thể tránh khỏi.
Một giải pháp được mọi người đồng loạt đưa ra để tiết kiệm thời gian hơn là chuyển sang một tòa nhà mới có nhiều thang máy hơn (vì không ai muốn phải dậy sớm hơn cả).
Blockchain Ethereum cũng đang gặp vấn đề tương tự vậy: quá nhiều giao dịch cần phải được xử lý (giống như hàng người đang xếp hàng đi vào thang máy), nhưng hạ tầng của mạng lưới thì lại có giới hạn (chỉ có duy nhất một chiếc thang máy), dẫn đến tình trạng giao dịch bị xử lý chậm và phí gas cần trả lại tăng lên quá cao (mọi người đều phải chờ đợi và mất thời gian để được vào thang máy).
Sharding là một giải pháp được đưa ra để giải quyết vấn đề này bằng cách phân chia khối lượng công việc trên blockchain chính (gọi là Beacon Chain) ra cho các chain nhỏ hơn, gọi là các “shard”.
Sharding là gì?
Trong giải pháp sharding gốc được đề xuất, các giao dịch sẽ được chia ra để xử lý bởi 64 shard, mỗi shard sẽ có một nhóm proposer và committee riêng:
- Proposer: có vai trò tổng hợp giao dịch rồi gửi cho notaries để xác thực chúng.
- Notaries: chịu trách nhiệm xác thực các giao dịch được gửi từ proposer.
- Committee: là “hội đồng” bao gồm các validator chịu trách nhiệm xác minh các block trong một shard thông qua việc biểu quyết (voting).
Lưu ý rằng proposer sẽ có vai trò giống như miner trong blockchain của Bitcoin vậy, nhưng notaries và committee có vai trò như nhau, nhưng notaries có trách nhiệm xác thực giao dịch để tổng hợp block vào shard chain, còn committee có vai trò xác thực các block trên shard chain để thêm vào Beacon Chain.
Các nhóm committee giống như những “thanh tra” vậy, và một đội thanh tra thì không nên chỉ làm việc với một công ty mãi được, vì như vậy sẽ phát sinh vấn đề tham nhũng. Tương tự vậy, các nhóm committee cũng luôn được luân phiên thay đổi để đảm bảo sự an toàn và minh bạch cho hệ thống.
Từng nhóm proposer và committee hoạt động riêng biệt để đảm bảo tính phi tập trung, nhưng như vậy cũng lại tạo thêm sự phức tạp cho hệ thống, làm kéo dài thời gian xác thực giao dịch. Theo như hình dưới đây, Beacon Block thứ hai cần lấy lại dữ liệu đã được xác thực trong Block trước đó từ các committee riêng biệt:
Xem thêm: Zil là gì?
Chào mừng đến với Danksharding
Để khắc phục sự phức tạp này, Dankrad Feist, một researcher ở Ethereum Foundation, đã cho ra đời một giải pháp sharding mới: Danksharding, được đặt theo tên của chính ông. Trong giải pháp này, các block trên Beacon Chain sẽ bao gồm luôn dữ liệu trên các shard để tạo thành một Block Lớn (vẫn được xem là Beacon Block), và các giao dịch sẽ chỉ cần tới một committee để được xử lý. Trong phương pháp này, dữ liệu sẽ được xử lý một cách đồng bộ hơn, từ đó tiết kiệm thời gian cho người dùng khi tương tác với blockchain của Ethereum. Theo như hình, chúng ta có thể thấy rằng Beacon Block thứ hai, thay vì phải kéo toàn bộ dữ liệu từ ba committee khác nhau, nó chỉ cần trỏ tới một committee duy nhất mà thôi:
Tuy nhiên, vấn đề lại nằm ở khâu tạo ra Block Lớn bên trên: theo mô hình truyền thống, proposer sẽ là người chịu trách nhiệm quy trình xác nhận và tổng hợp giao dịch vào các block này, nhưng sẽ ra sao nếu họ nhìn thấy tất cả các giao dịch của người dùng và quyết định bỏ qua chúng rồi front-run? Như vậy, thời gian giao dịch vẫn sẽ bị chậm đi với hầu hết người dùng, và việc áp dụng công nghệ sharding lại trở nên vô nghĩa.
Để khắc phục vấn đề này, một giải pháp mang tên Proposer-Builder Separation (PBS) đã được tạo ra nhằm tách bạch vai trò tổng hợp giao dịch và tổng hợp chúng vào một block: Builder sẽ là người tổng hợp các giao dịch, nhưng Proposer mới là người sắp xếp và quyết định thêm chúng vào Beacon block, thông qua sơ đồ sau đây:
Theo phương pháp này, proposer có quyền sắp xếp thứ tự của các giao dịch sao cho lợi nhuận thu về là nhiều nhất (dựa vào thông tin về phí gas được bid), nhưng cũng không thể front-run người dùng bởi họ không biết được toàn bộ thông tin về các giao dịch này. Sau khi proposer chọn ra các block headers có phí gas cao nhất, builder mới tiết lộ toàn bộ thông tin về các giao dịch này để xử lý chúng.
Mô hình này vẫn có một khuyết điểm: builder lại là những người nắm nhiều quyền lực hơn, vì họ có quyền chọn hoặc loại bỏ bất kì một giao dịch nào mà mình nhìn thấy. Vì thế, proposer sẽ chỉ định ra một danh sách các giao dịch (crList – Censor Resistance List) mà các builders bắt buộc phải tổng hợp vào.
Tổng kết
Giải pháp danksharding dù giải quyết được một số vấn đề của giải pháp sharding gốc nhưng lại đòi hỏi nhiều yêu cầu về mặt kỹ thuật hơn, đặc biệt là với những cá nhân đóng vai trò builder. Tuy nhiên, danksharding vẫn được xem là một viên gạch quan trọng, làm tiền đề cho những bước tiến tiếp theo trong việc hiện thực hóa công nghệ sharding lên blockchain của Ethereum.
Mai Phan
Có thể bạn quan tâm:
