Nghiên cứu mới nhất của Vitalik: Các giao thức LSDFi và thanh khoản cần thay đổi như thế nào để nâng cao tính phi tập trung và giảm quá tải đồng thuận?

Bài viết này sẽ tập trung chủ yếu vào hai vấn đề lớn hiện nay của các giao thức LSDFi và các pool thanh khoản: rủi ro tập trung hóa của các nhà vận hành node và gánh nặng đồng thuận không cần thiết.

Tác giả:Vitalik Buterin

Biên dịch: bayemon.eth, ChainCatcher

Tình hình phát triển hiện tại của Ethereum có thể nói là bao gồm rất nhiều hình thức staking hai tầng (two-tiered staking), trong đó hai tầng staking này đề cập đến mô hình staking với hai loại người tham gia.

• Nhà vận hành node (Node Operator): Vận hành node và đặt cược một lượng vốn tự có nhất định dựa trên uy tín của mình
• Đại lý (Delegator): Các đại lý staking một lượng Ethereum nhất định, không có mức tối thiểu, và không có hạn chế bổ sung nào đối với các hình thức tham gia ngoài tài sản thế chấp

Hình thức staking hai tầng mới nổi này được tạo ra thông qua các pool staking cung cấp token staking thanh khoản (LST) với sự tham gia đông đảo. (Rocket Pool và Lido đều áp dụng mô hình này).

Tuy nhiên, hình thức staking hai tầng hiện tại tồn tại hai nhược điểm:

• Rủi ro tập trung hóa của nhà vận hành node: Cơ chế lựa chọn nhà vận hành node trong tất cả các pool staking hiện nay vẫn quá tập trung hóa
• Gánh nặng đồng thuận không cần thiết: Ethereum L1 phải xác thực khoảng 800.000 chữ ký mỗi Epoch, đây là một gánh nặng rất lớn cho mỗi slot. Ngoài ra, do các pool staking thanh khoản yêu cầu nhiều vốn, trong khi mạng lưới lại không thực sự hưởng lợi từ gánh nặng này. Do đó, nếu mạng lưới Ethereum có thể đạt được sự phân tán và bảo mật hợp lý mà không cần mỗi người staking phải ký theo từng thời gian, cộng đồng có thể áp dụng các giải pháp như vậy để giảm đáng kể số lượng chữ ký mỗi slot.

Bài viết này sẽ mô tả các giải pháp cho hai vấn đề trên, trước tiên giả định rằng phần lớn vốn nằm trong tay những người không muốn tự mình quản lý node staking theo hình thức hiện tại, ký thông tin ở mỗi slot, khóa tiền gửi và phân phối lại cho những người bị cắt giảm vốn, vậy trong trường hợp này, họ có thể đóng vai trò gì để vẫn đóng góp ý nghĩa cho sự phi tập trung và bảo mật của mạng lưới?

Staking hai tầng hiện tại vận hành như thế nào?

Hiện nay, hai pool staking phổ biến nhất là Lido và RocketPool, đối với Lido, hai bên tham gia là:

• Nhà vận hành node: Được bầu chọn bởi Lido DAO, nghĩa là thực tế do các holder LDO lựa chọn. Khi ai đó gửi ETH vào hệ thống hợp đồng thông minh của Lido, stETH sẽ được tạo ra, nhà vận hành node có thể đưa nó vào pool staking (nhưng do chứng nhận rút tiền gắn với địa chỉ hợp đồng thông minh, nhà vận hành không thể tự ý rút tiền)
• Đại lý: Khi ai đó gửi ETH vào hệ thống hợp đồng thông minh của Lido, stETH sẽ được tạo ra, nhà vận hành node có thể dùng nó để staking (nhưng do chứng nhận rút tiền gắn với địa chỉ hợp đồng thông minh, nhà vận hành không thể tự ý rút tiền)

Đối với Rocket Pool, hai bên là:

• Nhà vận hành node: Bất kỳ ai cũng có thể trở thành nhà vận hành node, chỉ cần nạp 8 ETH và một lượng token RPL nhất định.
• Đại lý: Khi ai đó gửi ETH vào hệ thống hợp đồng thông minh của Rocket Pool, rETH sẽ được tạo ra, nhà vận hành node có thể dùng nó để staking (tương tự, do chứng nhận rút tiền gắn với địa chỉ hợp đồng thông minh, nhà vận hành không thể tự ý rút tiền).

Vai trò của đại 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 then chốt cần đặt ra là: Từ góc độ giao thức, ý nghĩa của việc thiết lập đại lý là gì?

Để hiểu sâu sắc vấn đề này, trước tiên chúng ta hãy suy nghĩ về các thay đổi giao thức được đề cập trong bài, tức là giới hạn hình phạt cắt giảm ở mức 2ETH, Rocket Pool cũng sẽ giảm số tiền staking của nhà vận hành node xuống còn 2ETH, và thị phần của Rocket Pool sẽ tăng lên 100%/(đối với người staking và holder ETH, khi rETH trở nên không có rủi ro, gần như tất cả holder ETH sẽ trở thành holder rETH hoặc nhà vận hành node).

Giả sử tỷ suất lợi nhuận của holder rETH là 3% (bao gồm phần thưởng trong giao thức và phí ưu tiên + MEV), tỷ suất lợi nhuận của nhà vận hành node là 4%. Chúng ta cũng giả định tổng cung ETH là 100 millions.

Kết quả tính toán như sau. Để tránh tính lãi kép, chúng ta sẽ tính lợi nhuận theo ngày:

Bây giờ, giả sử Rocket Pool không tồn tại, mỗi người staking có thể nạp tối thiểu 2 ETH, tổng lượng thanh khoản tối đa là 6.25 millions ETH, đồng thời tỷ suất lợi nhuận của nhà vận hành node giảm xuống còn 1%. Hãy tính lại:

Xét về chi phí tấn công trong hai trường hợp này. Trong trường hợp đầu tiên, kẻ tấn công sẽ không đăng ký làm đại lý, vì về bản chất đại lý không có quyền rút tiền, nên không có ý nghĩa. Do đó, họ sẽ dùng toàn bộ ETH để staking và trở thành nhà vận hành node. Để đạt được 1/3 tổng lượng staking, họ cần đầu tư 2.08 millions ETH (công bằng mà nói, đây vẫn là một con số khá lớn). Trong trường hợp thứ hai, kẻ tấn công chỉ cần đầu tư vốn, để đạt được 1/3 tổng lượng pool staking, họ vẫn cần đầu tư 2.08 millions ETH.

Xét về kinh tế staking và chi phí tấn công, kết quả cuối cùng của hai trường hợp là hoàn toàn giống nhau. Tỷ lệ tổng cung ETH do nhà vận hành node nắm giữ tăng 0.00256% mỗi ngày, tỷ lệ tổng cung ETH do người không vận hành node nắm giữ giảm 0.00017% mỗi ngày. Chi phí tấn công là 2.08 millions ETH. Do đó, trong mô hình này, đại lý dường như trở thành một cỗ máy Rube Goldberg vô nghĩa, cộng đồng lý trí thậm chí có xu hướng loại bỏ trung gian, giảm mạnh phần thưởng staking và giới hạn tổng lượng ETH staking ở mức 6.25 millions.

Tất nhiên, bài viết này không đề xuất giảm phần thưởng staking xuống 4 lần, đồng thời giới hạn tổng lượng staking ở mức 6.25 millions. Ngược lại, quan điểm của bài viết là một hệ thống staking vận hành tốt nên có một thuộc tính then chốt, đó là đại lý phải đảm nhận trách nhiệm quan trọng trong toàn bộ hệ thống. Ngoài ra, nếu đại lý phần lớn bị thúc đẩy bởi áp lực cộng đồng và chủ nghĩa vị tha để hành động đúng đắn, điều đó cũng không sao; rốt cuộc, đây mới là động lực chính thúc đẩy mọi người triển khai các giải pháp staking phi tập trung, bảo mật cao ngày nay.

Trách nhiệm của đại lý

Nếu đại lý có thể đóng vai trò ý nghĩa trong hệ thống staking, thì vai trò đó có thể là gì?

Tôi cho rằng có hai loại câu trả lời:

• Lựa chọn đại lý: Đại lý có thể lựa chọn ủy quyền lợi ích của mình cho nhà vận hành node nào. Trọng số của nhà vận hành node trong cơ chế đồng thuận tỷ lệ thuận với tổng lượng staking được ủy quyền cho họ. Hiện nay, cơ chế lựa chọn đại lý vẫn còn hạn chế, tức là holder rETH hoặc stETH có thể rút ETH và chuyển sang pool khác, nhưng tính khả dụng thực tế của việc lựa chọn đại lý có thể được nâng cao rất nhiều.
• Tham gia cơ chế đồng thuận: Người ủy quyền có thể lựa chọn đóng vai trò nhất định trong cơ chế đồng thuận, trách nhiệm nhẹ hơn so với việc vận hành node staking đầy đủ, không có thời gian thoát lâu và rủi ro bị cắt giảm, nhưng vẫn có thể kiểm soát nhà vận hành node.

Tăng cường quyền lựa chọn đại lý

Có ba cách để tăng cường quyền lựa chọn đại lý:

• Cải thiện công cụ bỏ phiếu trong pool
• Tăng cường cạnh tranh giữa các pool
• Cố định quyền đại diện

Hiện nay, việc bỏ phiếu trong pool thực tế không khả thi: Trong Rocket Pool, bất kỳ ai cũng có thể trở thành nhà vận hành node, trong Lido, việc bỏ phiếu do holder LDO quyết định chứ không phải holder ETH. Lido đã đề xuất một đề xuất quản trị kép LDO + stETH, họ có thể kích hoạt một cơ chế bảo vệ để ngăn chặn bỏ phiếu mới, từ đó ngăn việc thêm hoặc loại bỏ nhà vận hành node, điều này phần nào cho phép holder stETH có tiếng nói. Tuy nhiên, quyền lực này vẫn còn hạn chế và có thể mạnh mẽ hơn.

Cạnh tranh giữa các pool hiện nay đã tồn tại nhưng còn yếu. Thách thức chính là token staking của các pool nhỏ có tính thanh khoản thấp, khó xây dựng niềm tin và ít được các ứng dụng hỗ trợ.

Chúng ta có thể cải thiện hai vấn đề đầu tiên bằng cách giới hạn số tiền phạt ở mức nhỏ, ví dụ 2 hoặc 4 ETH. Sau đó, phần ETH còn lại có thể được gửi và rút ngay một cách an toàn, giúp việc trao đổi hai chiều vẫn khả thi cho các pool nhỏ. Chúng ta có thể cải thiện vấn đề thứ ba bằng cách tạo một hợp đồng phát hành tổng để quản lý LST (tương tự như ERC-4337 và ERC-6900 cho ví), đảm bảo bất kỳ token staking nào phát hành qua hợp đồng này đều an toàn.

Hiện tại, trong giao thức vẫn chưa có quyền đại diện cố định, nhưng loại tình huống này dường như cũng có thể xuất hiện trong tương lai. Nó sẽ liên quan đến logic tương tự như các ý tưởng trên, nhưng được thực hiện ở cấp độ giao thức. Để biết thêm về ưu nhược điểm của việc cố định, hãy xem bài viết này.

Những ý tưởng này đều là cải tiến so với hiện trạng, nhưng lợi ích mà chúng mang lại đều có giới hạn. Quản trị bỏ phiếu bằng token có vấn đề, cuối cùng bất kỳ hình thức lựa chọn đại lý không có động lực nào cũng chỉ là một dạng bỏ phiếu bằng token; đây luôn là điều tôi không hài lòng nhất về Proof of Stake ủy quyền. Do đó, việc cân nhắc thực hiện các hình thức tham gia đồng thuận mạnh mẽ hơn cũng rất đáng giá.

Tham gia đồng thuận

Ngay cả khi không xét đến các vấn đề hiện tại của staking thanh khoản, phương pháp staking độc lập hiện nay cũng có những hạn chế. Giả sử sử dụng single-slot finality, trong trạng thái lý tưởng mỗi slot có thể xử lý khoảng 100.000 đến 1.000.000 chữ ký BLS. Ngay cả khi chúng ta sử dụng recursive SNARKs để tổng hợp chữ ký, để đảm bảo khả năng truy vết chữ ký, cần gán cho mỗi chữ ký một trường bit của người tham gia. Nếu Ethereum trở thành một mạng lưới toàn cầu, thì việc lưu trữ trường bit hoàn toàn phi tập trung cũng không đủ: mỗi slot 16 MB chỉ hỗ trợ khoảng 64 triệu người staking.

Từ góc độ này, việc chia staking thành lớp có độ phức tạp cao có thể bị cắt giảm và lớp có độ phức tạp thấp là có giá trị, lớp phức tạp cao sẽ có hiệu lực ở mỗi slot nhưng có thể chỉ có 10.000 người tham gia, còn lớp phức tạp thấp chỉ thỉnh thoảng được gọi để tham gia. Lớp phức tạp thấp có thể hoàn toàn không bị cắt giảm, hoặc có thể ngẫu nhiên trao cơ hội cho người tham gia, trong vài slot sẽ gửi tiền và trở thành đối tượng bị cắt giảm.

Trên thực tế, điều này có thể được thực hiện bằng cách tăng giới hạn số dư của validator, sau đó tăng ngưỡng số dư (ví dụ, 2048 ETH) để xác định validator nào thuộc lớp phức tạp cao hoặc thấp.

Dưới đây là một số gợi ý về cách các vai trò staking nhỏ này vận hành:

• Mỗi slot, sẽ chọn ngẫu nhiên 10.000 người staking nhỏ, họ có thể ký vào nội dung mà họ cho là đại diện cho slot đó. Sử dụng người staking nhỏ làm đầu vào để chạy quy tắc chọn fork LMD GHOST. Nếu lựa chọn fork do người staking nhỏ điều khiển và lựa chọn fork do nhà vận hành node điều khiển có sự khác biệt nhất định, client của người dùng sẽ không chấp nhận bất kỳ block nào là xác nhận cuối cùng và hiển thị lỗi. Điều này buộc cộng đồng phải can thiệp để giải quyết tình huống.
• Đại lý có thể gửi giao dịch, thông báo cho mạng lưới rằng họ đang online và sẵn sàng đảm nhận vai trò staking nhỏ trong giờ tiếp theo. Thông điệp do node gửi (block hoặc bằng chứng) cần được ký bởi cả node và một đại lý được chọn ngẫu nhiên để xác nhận node đó.
• Đại lý có thể gửi giao dịch, thông báo cho mạng lưới rằng họ đang online và sẵn sàng đảm nhận vai trò staking nhỏ trong giờ tiếp theo. Mỗi epoch, sẽ chọn ngẫu nhiên 10 đại lý làm inclusion list provider, và chọn thêm 10.000 đại lý làm voter. Những người này được chọn trước k-slot và có một cửa sổ k slot để đăng thông báo xác nhận họ đang online lên chuỗi. Mỗi inclusion list provider được chọn đã xác nhận có thể đăng inclusion list, trừ khi với mỗi inclusion list, hoặc là bao gồm giao dịch trong inclusion list đó, hoặc là có đủ phiếu bầu của voter cho thấy inclusion list không khả dụng, nếu không block sẽ bị coi là không hợp lệ.

Điểm chung của các node staking nhỏ này là họ không cần tham gia tích cực ở mỗi slot, thậm chí chỉ cần light node cũng có thể hoàn thành toàn bộ công việc. Do đó, việc triển khai node chỉ cần xác thực lớp đồng thuận, nhà vận hành node có thể thực hiện thông qua ứng dụng hoặc plugin trình duyệt, hầu hết các ứng dụng hoặc plugin này đều bị động, yêu cầu về tính toán, phần cứng hoặc kỹ năng công nghệ đều rất thấp, thậm chí không cần các công nghệ tiên tiến như ZK-EVM.

Những "vai trò nhỏ" này cũng có một mục tiêu chung: ngăn chặn 51% nhà vận hành node đa số kiểm duyệt giao dịch. Phương án thứ nhất và thứ hai còn có thể ngăn chặn đa số tham gia đảo ngược tính cuối cùng. Phương án thứ ba thì tập trung trực tiếp hơn vào kiểm duyệt, nhưng dễ bị ảnh hưởng bởi lựa chọn của đa số nhà vận hành node.

Những ý tưởng này được viết từ góc độ triển khai giải pháp staking hai tầng trong giao thức, nhưng chúng cũng có thể được triển khai như một chức năng của pool staking. Dưới đây là một số ý tưởng triển khai cụ thể:

1. Ở góc độ giao thức, mỗi validator có thể thiết lập hai khóa staking: một khóa staking liên tục P, cùng với địa chỉ Ethereum liên kết có thể được gọi, và xuất ra một khóa staking nhanh Q. Node theo dõi thông tin ký chọn fork bằng P, ký thông tin bằng Q, nếu kết quả lưu trữ PQ không nhất quán thì không chấp nhận bất kỳ block nào là xác nhận cuối cùng, pool thanh khoản chịu trách nhiệm chọn đại diện ngẫu nhiên
2. Giao thức về cơ bản có thể giữ nguyên, nhưng public key của validator trong epoch đó sẽ được đặt là P+Q. Lưu ý rằng đối với việc cắt giảm, hai thông điệp có thể bị cắt giảm có thể có khóa Q khác nhau, nhưng sẽ có cùng khóa P; thiết kế cắt giảm cần xử lý trường hợp này.
3. Khóa Q chỉ có thể được sử dụng trong giao thức để ký và xác thực inclusion list trong block. Trong trường hợp này, Q có thể là một hợp đồng thông minh thay vì một khóa đơn lẻ, do đó pool staking có thể sử dụng nó để thực hiện logic bỏ phiếu phức tạp hơn, chấp nhận inclusion list từ các provider được chọn ngẫu nhiên hoặc đủ phiếu cho thấy inclusion list không khả dụng.

Kết luận

Nếu được triển khai đúng cách, việc tinh chỉnh thiết kế Proof of Stake có thể giải quyết đồng thời hai vấn đề:

• Cung cấp cơ hội cho những người hiện nay không có nguồn lực hoặc khả năng để thực hiện staking độc lập, giúp họ có thể tham gia staking và giữ lại nhiều quyền lực hơn trong tay họ: bao gồm (i) quyền lựa chọn ủng hộ node nào và (ii) tham gia tích cực vào đồng thuận theo cách nhẹ nhàng hơn nhưng vẫn ý nghĩa so với việc vận hành node staking đầy đủ. Không phải tất cả người tham gia đều chọn một hoặc cả hai lựa chọn này, nhưng bất kỳ ai chọn một hoặc cả hai đều sẽ có cải thiện đáng kể so với hiện trạng.
• Giảm số lượng chữ ký mà lớp đồng thuận Ethereum cần xử lý ở mỗi slot, ngay cả trong chế độ single slot finality, cũng giảm xuống khoảng 10.000 chữ ký nhỏ hơn. Điều này cũng sẽ giúp phi tập trung hóa, giúp mọi người dễ dàng vận hành node xác thực hơn.

Đối với các giải pháp này, có thể tìm ra cách giải quyết vấn đề ở các tầng trừu tượng khác nhau: quyền hạn được cấp cho người dùng trong giao thức Proof of Stake, lựa chọn của người dùng giữa các giao thức Proof of Stake và việc thiết lập trong giao thức. Cần cân nhắc cẩn thận lựa chọn này, và thông thường nên chọn thiết lập khả thi tối thiểu để giảm tối đa độ phức tạp của giao thức và mức độ thay đổi kinh tế giao thức, đồng thời vẫn đạt được mục tiêu mong muốn.

Đặc biệt cảm ơn Mike Neuder, Justin Drake và những người khác đã phản hồi và rà soát. Xem thêm: các bài viết trước đây của Mike Neuder, Dankrad Feist và arixon.eth về chủ đề tương tự.