Đặc biệt cảm ơn Mike Neuder, Justin Drake và những người khác đã phản hồi và đánh giá. Xem thêm: các bài đăng trước đây về các chủ đề tương tự của<a href="https://notes.ethereum.org/ @mikeneuder /goldilocks">Mike Neuder, Dankrad Feist và arixon.eth .
Hiện trạng Ethereum có thể được mô tả là bao gồm một phần lớn đặt cược hai tầng mới nổi. Bằng cách đặt cược hai tầng, ý tôi ở đây là một mô hình đặt cược trong đó có hai loại người tham gia:
Việc đặt cược hai tầng mới nổi này phát sinh thông qua hành động của một phần lớn người đặt cược tham gia vào nhóm đặt cược cung cấp mã thông báo đặt cược thanh khoản (LST), ví dụ: Bể bơi tên lửa và Lido.
Hiện trạng có hai nhược điểm chính:
Bài đăng này sẽ mô tả các giải pháp khả thi cho cả hai vấn đề này. Nó sẽ đặc biệt ở góc độ sau: giả sử rằng chúng ta coi như chắc chắn rằng hầu hết vốn được nắm giữ bởi những người không sẵn sàng tự mình chạy các nút đặt cược ở dạng hiện tại, ký tin nhắn vào mọi vị trí và khóa tiền gửi của họ và buộc họ phải cắt giảm . Họ có thể có vai trò gì khác để đóng góp một cách có ý nghĩa vào quá trình phân cấp và bảo mật của mạng?
Hai nhóm đặt cược phi tập trung phổ biến nhất hiện nay, Lido và RocketPool, đều đang tạo ra hệ sinh thái đặt cược hai tầng mới nổi. Trong trường hợp của Lido, các cấp độ là:
Trong trường hợp của Rocket Pool, các cấp độ là:
Trong các hệ thống này (hoặc các hệ thống mới được kích hoạt bởi các thay đổi giao thức tiềm năng trong tương lai), một câu hỏi quan trọng cần đặt ra là: từ góc độ của giao thức, mục đích của việc có người ủy quyền là gì?
Để biết tại sao câu hỏi này lại có ý nghĩa, chúng ta hãy xem xét thế giới sau đây. Thay đổi giao thức được đề xuất trong bài đăng gần đây này nhằm giới hạn hình phạt giảm xuống còn 2 ETH đã được triển khai. Rocket Pool giảm khoản tiền gửi của nhà điều hành nút xuống còn 2 ETH để đáp lại. Thị phần của Rocket Pool tăng lên 100% (không chỉ giữa những người đặt cược mà còn giữa những người nắm giữ ETH: khi rETH trở nên không có rủi ro, hầu hết tất cả những người nắm giữ ETH đều trở thành người nắm giữ rETH hoặc nhà điều hành nút).
Giả sử rằng chủ sở hữu rETH nhận được lợi nhuận là 3% (bao gồm cả phần thưởng trong giao thức và phí ưu tiên + MEV) và người vận hành nút nhận được lợi nhuận là 4%. Giả sử tổng nguồn cung ETH là 100 triệu.
Đây là cách toán học diễn ra. Để tránh phải xử lý lãi kép, chúng ta sẽ xem xét lợi nhuận hàng ngày thay vì hàng năm, sao cho số hạng bậc hai trở nên đủ nhỏ để có thể bỏ qua:
Bây giờ chúng ta hãy xem xét một thế giới khác. Rocket Pool không tồn tại. Khoản tiền gửi tối thiểu của mỗi người đặt cược giảm xuống còn 2 ETH và tổng số ETH đặt cược được giới hạn ở mức 6,25 triệu. Ngoài ra, lợi nhuận của toán tử nút giảm xuống 1%. Hãy làm phép tính:
Bây giờ, chúng ta hãy xem xét hai tình huống từ góc độ chi phí tấn công. Trong trường hợp đầu tiên, những kẻ tấn công sẽ không đăng ký với tư cách là người ủy quyền: người được ủy quyền không có quyền lực nên không có ích gì. Do đó, họ sẽ dồn toàn bộ ETH của mình vào việc đăng ký làm nhà khai thác nút. Để có được 1/3 tổng số tiền đặt cược, họ sẽ cần phải bỏ vào 2,08 triệu ETH (công bằng mà nói thì vẫn còn khá nhiều! ví dụ: xem<a href="https://notes.ethereum.org/ @vbuterin /single_slot_finality#Idea-1-super-committees">cái này thảo luận về các siêu ủy ban, một đề xuất mở rộng quy mô đặt cược cũng sẽ giảm chi phí tấn công xuống một giá trị tương tự). Trong trường hợp thứ hai, những kẻ tấn công sẽ chỉ đặt cược và để nhận được 1/3 tổng số tiền đặt cược, chúng cần phải bỏ vào… 2,08 triệu ETH.
Từ cả góc độ kinh tế đặt cược và góc độ chi phí tấn công, kết quả cuối cùng trong cả hai trường hợp đều hoàn toàn giống nhau. Tỷ lệ trong tổng nguồn cung ETH do nhà điều hành nút nắm giữ tăng 0,00256% mỗi ngày và tỷ lệ trong tổng nguồn cung ETH do nhà điều hành không phải nút nắm giữ giảm 0,00017% mỗi ngày. Chi phí tấn công là 2,08 triệu ETH. Do đó, có cảm giác như trong mô hình này, việc ủy quyền trở thành một cỗ máy Rube Goldberg vô nghĩa: chúng tôi cũng có thể loại bỏ người trung gian và giảm đáng kể phần thưởng đặt cược cũng như tổng giới hạn ETH đặt cược xuống còn 6,25 triệu.
Mục đích của lập luận này không phải là ủng hộ việc giảm phần thưởng đặt cược xuống 4 lần và giới hạn tổng số ETH đặt cược xuống còn 6,25 triệu. Đúng hơn, nó chỉ ra một đặc tính quan trọng mà một hệ thống đặt cược hoạt động tốt nên có: cụ thể là, những người được ủy quyền nên làm điều gì đó thực sự quan trọng. Hơn nữa, sẽ không sao nếu người được ủy quyền được thúc đẩy hành động đúng đắn ở mức độ lớn bởi áp lực và lòng vị tha của cộng đồng; xét cho cùng, đó là động lực chính thúc đẩy mọi người tham gia theo những cách tăng cường bảo mật phi tập trung (nhưng nỗ lực cao hơn) thay vì những cách đe dọa an ninh tập trung (nhưng tốn ít nỗ lực hơn) ngày nay.
Tôi thấy hai loại câu trả lời:
Có ba cách để mở rộng quyền lựa chọn đại biểu:
Việc bỏ phiếu trong các nhóm ngày nay không thực sự tồn tại: trong Rocket Pool, bất kỳ ai cũng có thể trở thành nhà điều hành nút và ở Lido, chính những người nắm giữ LDO sẽ bỏ phiếu chứ không phải những người nắm giữ ETH. Lido có một đề xuất về quản trị kép LDO + stETH, điều này sẽ giúp những người nắm giữ stETH có tiếng nói theo nghĩa là họ có thể kích hoạt một tiện ích chặn các phiếu bầu mới và do đó ngăn chặn việc thêm hoặc xóa các nhà khai thác nút. Điều đó nói lên rằng, điều này còn hạn chế và có thể mạnh hơn nhiều.
Sự cạnh tranh giữa các nhóm tồn tại ngày nay, nhưng còn yếu. Thách thức chính là mã thông báo đặt cược của nhóm đặt cược nhỏ hơn (i) kém thanh khoản hơn, (ii) khó tin cậy hơn và (iii) ít được ứng dụng hỗ trợ hơn.
Chúng ta có thể cải thiện hai vấn đề đầu tiên bằng cách giới hạn các hình phạt chém ở mức nhỏ hơn, chẳng hạn như. 2 hoặc 4 ETH. Số ETH còn lại (không thể chia nhỏ) sau đó có thể được gửi và rút một cách an toàn ngay lập tức, tạo LST dựa trên chuyển đổi hai chiều ETH đó với ETH ngay cả đối với các nhóm nhỏ nhất. Chúng tôi có thể cải thiện vấn đề thứ ba bằng cách tạo hợp đồng phát hành trung tâm cho LST - hơi giống với ERC-4337 và ERC-6900 cho ví, để chúng tôi có thể đảm bảo rằng mọi mã thông báo đặt cược được phát hành thông qua hợp đồng đó đều an toàn. Các ứng dụng (ví dụ: phiên bản RAI hỗ trợ ETH đặt cược) có thể được khuyến khích mạnh mẽ để hỗ trợ tất cả các mã thông báo đặt cược được phát hành thông qua cơ quan đăng ký này.
Ủy quyền được quy định hiện không tồn tại trong giao thức nhưng có khả năng có thể được giới thiệu. Nó sẽ liên quan đến logic tương tự như các ý tưởng ở trên, nhưng được triển khai ở cấp độ giao thức. Xem bài đăng này để biết những ưu và nhược điểm của việc cất giữ mọi thứ.
Tất cả những ý tưởng này đều là sự cải tiến so với hiện trạng, nhưng có giới hạn về mức độ lợi ích mà chúng có thể mang lại. Việc quản lý bỏ phiếu bằng mã thông báo thật tệ hại và cuối cùng thì bất kỳ hình thức lựa chọn đại biểu không được khuyến khích nào cũng chỉ là một loại bỏ phiếu bằng mã thông báo; đây là nguyên nhân chính khiến tôi khó chịu với bằng chứng cổ phần được ủy quyền kể từ đầu. Do đó, việc nghĩ đến việc tạo điều kiện cho các hình thức tham gia đồng thuận mạnh mẽ hơn có vẻ cũng có giá trị.
Có những giới hạn đối với cách tiếp cận hiện tại đối với việc đặt cược một mình, ngay cả khi không tính đến các vấn đề hiện tại xung quanh việc đặt cược thanh khoản. Giả sử tính hữu hạn của một vị trí, các ước tính tốt nhất của chúng tôi đề xuất giới hạn ~ 100k - 1M chữ ký BLS có thể được xử lý trên mỗi vị trí và điều đó giả định thời gian của vị trí tăng đáng kể. Ngay cả khi chúng tôi sử dụng SNARK đệ quy để tổng hợp chữ ký, trách nhiệm ký kết (cho mục đích cắt giảm) yêu cầu phải có một trường bit về những người đã tham gia cho mỗi chữ ký. Nếu Ethereum trở thành một mạng quy mô toàn cầu, thì thậm chí bằng cách nào đó sử dụng toàn bộ danksharding để lưu trữ các bitfield cũng sẽ không đủ: 16 MB mỗi khe sẽ chỉ hỗ trợ ~64 triệu người đặt cọc.
Ở đây, từ góc độ đó, cũng có giá trị trong việc chia đặt cược thành một cấp có thể cắt nhỏ có độ phức tạp cao hơn, hoạt động ở mọi vị trí nhưng có lẽ chỉ có 10.000 người tham gia và một cấp có độ phức tạp thấp hơn đôi khi chỉ được gọi để tham gia. Cấp độ phức tạp thấp hơn có thể được miễn hoàn toàn việc cắt giảm hoặc có thể ngẫu nhiên cung cấp cho những người tham gia cơ hội tạm thời (tức là. đối với một vài vị trí) gửi tiền và có thể bị cắt giảm.
Trong thực tế, điều này có thể được thực hiện bằng cách<a href="https://notes.ethereum.org/ @mikeneuder /eip-7251-faq">gây quỹ giới hạn số dư của trình xác thực và sau đó triển khai ngưỡng số dư (ví dụ: 2048 ETH) để xác định trình xác nhận hiện tại nào có cấp độ phức tạp cao hơn và thấp hơn.
Dưới đây là một số ý tưởng về cách hoạt động của những vai trò đặt cược nhỏ này:
Các vai trò đặt cược nhỏ này đều có điểm chung là chúng không liên quan đến việc tham gia tích cực vào từng vị trí, không thể bị cắt (và do đó có rủi ro quản lý khóa rất thấp) và rất “nhẹ nhàng” theo nghĩa là chúng thậm chí không yêu cầu nút đầy đủ để chạy. Chỉ xác minh lớp đồng thuận là đủ. Do đó, chúng có thể được triển khai thông qua các ứng dụng hoặc plugin trình duyệt chủ yếu là thụ động và có chi phí tính toán rất thấp, yêu cầu phần cứng hoặc yêu cầu bí quyết kỹ thuật, thậm chí không cần giả định những tiến bộ kỹ thuật như ZK-EVM.
Tất cả các vai trò đặt cược nhỏ này đều có một mục tiêu chung: chúng ngăn chặn phần lớn 51% các nhà khai thác nút tham gia kiểm duyệt giao dịch. Điều thứ nhất và thứ hai cũng ngăn cản đa số tham gia vào việc đảo ngược mục đích cuối cùng. Phần thứ ba tập trung trực tiếp hơn vào kiểm duyệt, mặc dù nó dễ bị tổn thương hơn trước khả năng đa số nhà điều hành nút cũng sẽ chọn kiểm duyệt các thông báo xác nhận của nhà cung cấp danh sách đưa vào.
Những ý tưởng này được viết từ góc độ của một giải pháp đặt cược hai tầng được quy định cụ thể được triển khai trong giao thức, nhưng chúng cũng có thể được triển khai dưới dạng các tính năng của nhóm đặt cược. Dưới đây là một số ý tưởng triển khai cụ thể:
Nếu thực hiện đúng, việc điều chỉnh thiết kế đặt cược có thể giải quyết hai con chim bằng một hòn đá:
Đối với nhiều giải pháp trong số này, có nhiều lớp trừu tượng khác nhau nơi giải pháp cho vấn đề có thể tồn tại: quyền được cấp cho người dùng trong giao thức nhóm đặt cược, lựa chọn của người dùng giữa các giao thức nhóm đặt cược và lưu trữ trong giao thức. Lựa chọn này cần được xem xét cẩn thận và việc lưu giữ khả thi ở mức tối thiểu, giảm thiểu cả độ phức tạp của giao thức và mức độ thay đổi đối với tính kinh tế của giao thức trong khi vẫn đạt được mục tiêu mong muốn, nói chung là tốt nhất.
Đặc biệt cảm ơn Mike Neuder, Justin Drake và những người khác đã phản hồi và đánh giá. Xem thêm: các bài đăng trước đây về các chủ đề tương tự của<a href="https://notes.ethereum.org/ @mikeneuder /goldilocks">Mike Neuder, Dankrad Feist và arixon.eth .
Hiện trạng Ethereum có thể được mô tả là bao gồm một phần lớn đặt cược hai tầng mới nổi. Bằng cách đặt cược hai tầng, ý tôi ở đây là một mô hình đặt cược trong đó có hai loại người tham gia:
Việc đặt cược hai tầng mới nổi này phát sinh thông qua hành động của một phần lớn người đặt cược tham gia vào nhóm đặt cược cung cấp mã thông báo đặt cược thanh khoản (LST), ví dụ: Bể bơi tên lửa và Lido.
Hiện trạng có hai nhược điểm chính:
Bài đăng này sẽ mô tả các giải pháp khả thi cho cả hai vấn đề này. Nó sẽ đặc biệt ở góc độ sau: giả sử rằng chúng ta coi như chắc chắn rằng hầu hết vốn được nắm giữ bởi những người không sẵn sàng tự mình chạy các nút đặt cược ở dạng hiện tại, ký tin nhắn vào mọi vị trí và khóa tiền gửi của họ và buộc họ phải cắt giảm . Họ có thể có vai trò gì khác để đóng góp một cách có ý nghĩa vào quá trình phân cấp và bảo mật của mạng?
Hai nhóm đặt cược phi tập trung phổ biến nhất hiện nay, Lido và RocketPool, đều đang tạo ra hệ sinh thái đặt cược hai tầng mới nổi. Trong trường hợp của Lido, các cấp độ là:
Trong trường hợp của Rocket Pool, các cấp độ là:
Trong các hệ thống này (hoặc các hệ thống mới được kích hoạt bởi các thay đổi giao thức tiềm năng trong tương lai), một câu hỏi quan trọng cần đặt ra là: từ góc độ của giao thức, mục đích của việc có người ủy quyền là gì?
Để biết tại sao câu hỏi này lại có ý nghĩa, chúng ta hãy xem xét thế giới sau đây. Thay đổi giao thức được đề xuất trong bài đăng gần đây này nhằm giới hạn hình phạt giảm xuống còn 2 ETH đã được triển khai. Rocket Pool giảm khoản tiền gửi của nhà điều hành nút xuống còn 2 ETH để đáp lại. Thị phần của Rocket Pool tăng lên 100% (không chỉ giữa những người đặt cược mà còn giữa những người nắm giữ ETH: khi rETH trở nên không có rủi ro, hầu hết tất cả những người nắm giữ ETH đều trở thành người nắm giữ rETH hoặc nhà điều hành nút).
Giả sử rằng chủ sở hữu rETH nhận được lợi nhuận là 3% (bao gồm cả phần thưởng trong giao thức và phí ưu tiên + MEV) và người vận hành nút nhận được lợi nhuận là 4%. Giả sử tổng nguồn cung ETH là 100 triệu.
Đây là cách toán học diễn ra. Để tránh phải xử lý lãi kép, chúng ta sẽ xem xét lợi nhuận hàng ngày thay vì hàng năm, sao cho số hạng bậc hai trở nên đủ nhỏ để có thể bỏ qua:
Bây giờ chúng ta hãy xem xét một thế giới khác. Rocket Pool không tồn tại. Khoản tiền gửi tối thiểu của mỗi người đặt cược giảm xuống còn 2 ETH và tổng số ETH đặt cược được giới hạn ở mức 6,25 triệu. Ngoài ra, lợi nhuận của toán tử nút giảm xuống 1%. Hãy làm phép tính:
Bây giờ, chúng ta hãy xem xét hai tình huống từ góc độ chi phí tấn công. Trong trường hợp đầu tiên, những kẻ tấn công sẽ không đăng ký với tư cách là người ủy quyền: người được ủy quyền không có quyền lực nên không có ích gì. Do đó, họ sẽ dồn toàn bộ ETH của mình vào việc đăng ký làm nhà khai thác nút. Để có được 1/3 tổng số tiền đặt cược, họ sẽ cần phải bỏ vào 2,08 triệu ETH (công bằng mà nói thì vẫn còn khá nhiều! ví dụ: xem<a href="https://notes.ethereum.org/ @vbuterin /single_slot_finality#Idea-1-super-committees">cái này thảo luận về các siêu ủy ban, một đề xuất mở rộng quy mô đặt cược cũng sẽ giảm chi phí tấn công xuống một giá trị tương tự). Trong trường hợp thứ hai, những kẻ tấn công sẽ chỉ đặt cược và để nhận được 1/3 tổng số tiền đặt cược, chúng cần phải bỏ vào… 2,08 triệu ETH.
Từ cả góc độ kinh tế đặt cược và góc độ chi phí tấn công, kết quả cuối cùng trong cả hai trường hợp đều hoàn toàn giống nhau. Tỷ lệ trong tổng nguồn cung ETH do nhà điều hành nút nắm giữ tăng 0,00256% mỗi ngày và tỷ lệ trong tổng nguồn cung ETH do nhà điều hành không phải nút nắm giữ giảm 0,00017% mỗi ngày. Chi phí tấn công là 2,08 triệu ETH. Do đó, có cảm giác như trong mô hình này, việc ủy quyền trở thành một cỗ máy Rube Goldberg vô nghĩa: chúng tôi cũng có thể loại bỏ người trung gian và giảm đáng kể phần thưởng đặt cược cũng như tổng giới hạn ETH đặt cược xuống còn 6,25 triệu.
Mục đích của lập luận này không phải là ủng hộ việc giảm phần thưởng đặt cược xuống 4 lần và giới hạn tổng số ETH đặt cược xuống còn 6,25 triệu. Đúng hơn, nó chỉ ra một đặc tính quan trọng mà một hệ thống đặt cược hoạt động tốt nên có: cụ thể là, những người được ủy quyền nên làm điều gì đó thực sự quan trọng. Hơn nữa, sẽ không sao nếu người được ủy quyền được thúc đẩy hành động đúng đắn ở mức độ lớn bởi áp lực và lòng vị tha của cộng đồng; xét cho cùng, đó là động lực chính thúc đẩy mọi người tham gia theo những cách tăng cường bảo mật phi tập trung (nhưng nỗ lực cao hơn) thay vì những cách đe dọa an ninh tập trung (nhưng tốn ít nỗ lực hơn) ngày nay.
Tôi thấy hai loại câu trả lời:
Có ba cách để mở rộng quyền lựa chọn đại biểu:
Việc bỏ phiếu trong các nhóm ngày nay không thực sự tồn tại: trong Rocket Pool, bất kỳ ai cũng có thể trở thành nhà điều hành nút và ở Lido, chính những người nắm giữ LDO sẽ bỏ phiếu chứ không phải những người nắm giữ ETH. Lido có một đề xuất về quản trị kép LDO + stETH, điều này sẽ giúp những người nắm giữ stETH có tiếng nói theo nghĩa là họ có thể kích hoạt một tiện ích chặn các phiếu bầu mới và do đó ngăn chặn việc thêm hoặc xóa các nhà khai thác nút. Điều đó nói lên rằng, điều này còn hạn chế và có thể mạnh hơn nhiều.
Sự cạnh tranh giữa các nhóm tồn tại ngày nay, nhưng còn yếu. Thách thức chính là mã thông báo đặt cược của nhóm đặt cược nhỏ hơn (i) kém thanh khoản hơn, (ii) khó tin cậy hơn và (iii) ít được ứng dụng hỗ trợ hơn.
Chúng ta có thể cải thiện hai vấn đề đầu tiên bằng cách giới hạn các hình phạt chém ở mức nhỏ hơn, chẳng hạn như. 2 hoặc 4 ETH. Số ETH còn lại (không thể chia nhỏ) sau đó có thể được gửi và rút một cách an toàn ngay lập tức, tạo LST dựa trên chuyển đổi hai chiều ETH đó với ETH ngay cả đối với các nhóm nhỏ nhất. Chúng tôi có thể cải thiện vấn đề thứ ba bằng cách tạo hợp đồng phát hành trung tâm cho LST - hơi giống với ERC-4337 và ERC-6900 cho ví, để chúng tôi có thể đảm bảo rằng mọi mã thông báo đặt cược được phát hành thông qua hợp đồng đó đều an toàn. Các ứng dụng (ví dụ: phiên bản RAI hỗ trợ ETH đặt cược) có thể được khuyến khích mạnh mẽ để hỗ trợ tất cả các mã thông báo đặt cược được phát hành thông qua cơ quan đăng ký này.
Ủy quyền được quy định hiện không tồn tại trong giao thức nhưng có khả năng có thể được giới thiệu. Nó sẽ liên quan đến logic tương tự như các ý tưởng ở trên, nhưng được triển khai ở cấp độ giao thức. Xem bài đăng này để biết những ưu và nhược điểm của việc cất giữ mọi thứ.
Tất cả những ý tưởng này đều là sự cải tiến so với hiện trạng, nhưng có giới hạn về mức độ lợi ích mà chúng có thể mang lại. Việc quản lý bỏ phiếu bằng mã thông báo thật tệ hại và cuối cùng thì bất kỳ hình thức lựa chọn đại biểu không được khuyến khích nào cũng chỉ là một loại bỏ phiếu bằng mã thông báo; đây là nguyên nhân chính khiến tôi khó chịu với bằng chứng cổ phần được ủy quyền kể từ đầu. Do đó, việc nghĩ đến việc tạo điều kiện cho các hình thức tham gia đồng thuận mạnh mẽ hơn có vẻ cũng có giá trị.
Có những giới hạn đối với cách tiếp cận hiện tại đối với việc đặt cược một mình, ngay cả khi không tính đến các vấn đề hiện tại xung quanh việc đặt cược thanh khoản. Giả sử tính hữu hạn của một vị trí, các ước tính tốt nhất của chúng tôi đề xuất giới hạn ~ 100k - 1M chữ ký BLS có thể được xử lý trên mỗi vị trí và điều đó giả định thời gian của vị trí tăng đáng kể. Ngay cả khi chúng tôi sử dụng SNARK đệ quy để tổng hợp chữ ký, trách nhiệm ký kết (cho mục đích cắt giảm) yêu cầu phải có một trường bit về những người đã tham gia cho mỗi chữ ký. Nếu Ethereum trở thành một mạng quy mô toàn cầu, thì thậm chí bằng cách nào đó sử dụng toàn bộ danksharding để lưu trữ các bitfield cũng sẽ không đủ: 16 MB mỗi khe sẽ chỉ hỗ trợ ~64 triệu người đặt cọc.
Ở đây, từ góc độ đó, cũng có giá trị trong việc chia đặt cược thành một cấp có thể cắt nhỏ có độ phức tạp cao hơn, hoạt động ở mọi vị trí nhưng có lẽ chỉ có 10.000 người tham gia và một cấp có độ phức tạp thấp hơn đôi khi chỉ được gọi để tham gia. Cấp độ phức tạp thấp hơn có thể được miễn hoàn toàn việc cắt giảm hoặc có thể ngẫu nhiên cung cấp cho những người tham gia cơ hội tạm thời (tức là. đối với một vài vị trí) gửi tiền và có thể bị cắt giảm.
Trong thực tế, điều này có thể được thực hiện bằng cách<a href="https://notes.ethereum.org/ @mikeneuder /eip-7251-faq">gây quỹ giới hạn số dư của trình xác thực và sau đó triển khai ngưỡng số dư (ví dụ: 2048 ETH) để xác định trình xác nhận hiện tại nào có cấp độ phức tạp cao hơn và thấp hơn.
Dưới đây là một số ý tưởng về cách hoạt động của những vai trò đặt cược nhỏ này:
Các vai trò đặt cược nhỏ này đều có điểm chung là chúng không liên quan đến việc tham gia tích cực vào từng vị trí, không thể bị cắt (và do đó có rủi ro quản lý khóa rất thấp) và rất “nhẹ nhàng” theo nghĩa là chúng thậm chí không yêu cầu nút đầy đủ để chạy. Chỉ xác minh lớp đồng thuận là đủ. Do đó, chúng có thể được triển khai thông qua các ứng dụng hoặc plugin trình duyệt chủ yếu là thụ động và có chi phí tính toán rất thấp, yêu cầu phần cứng hoặc yêu cầu bí quyết kỹ thuật, thậm chí không cần giả định những tiến bộ kỹ thuật như ZK-EVM.
Tất cả các vai trò đặt cược nhỏ này đều có một mục tiêu chung: chúng ngăn chặn phần lớn 51% các nhà khai thác nút tham gia kiểm duyệt giao dịch. Điều thứ nhất và thứ hai cũng ngăn cản đa số tham gia vào việc đảo ngược mục đích cuối cùng. Phần thứ ba tập trung trực tiếp hơn vào kiểm duyệt, mặc dù nó dễ bị tổn thương hơn trước khả năng đa số nhà điều hành nút cũng sẽ chọn kiểm duyệt các thông báo xác nhận của nhà cung cấp danh sách đưa vào.
Những ý tưởng này được viết từ góc độ của một giải pháp đặt cược hai tầng được quy định cụ thể được triển khai trong giao thức, nhưng chúng cũng có thể được triển khai dưới dạng các tính năng của nhóm đặt cược. Dưới đây là một số ý tưởng triển khai cụ thể:
Nếu thực hiện đúng, việc điều chỉnh thiết kế đặt cược có thể giải quyết hai con chim bằng một hòn đá:
Đối với nhiều giải pháp trong số này, có nhiều lớp trừu tượng khác nhau nơi giải pháp cho vấn đề có thể tồn tại: quyền được cấp cho người dùng trong giao thức nhóm đặt cược, lựa chọn của người dùng giữa các giao thức nhóm đặt cược và lưu trữ trong giao thức. Lựa chọn này cần được xem xét cẩn thận và việc lưu giữ khả thi ở mức tối thiểu, giảm thiểu cả độ phức tạp của giao thức và mức độ thay đổi đối với tính kinh tế của giao thức trong khi vẫn đạt được mục tiêu mong muốn, nói chung là tốt nhất.