Quản trị kép LDO+stETH (tiếp theo)

Trung cấp12/27/2023, 9:21:07 AM
Bài viết này giới thiệu bản cập nhật mô hình quản trị của dự án Lido, giải thích PAP và các vấn đề liên quan, đồng thời phân tích cách vượt xa việc bỏ phiếu bằng mã thông báo quản trị đơn thuần.

Đây là phần tiếp theo của chủ đề ban đầu về quản trị kép 18. Chuỗi được liên kết chứa một ngữ cảnh quan trọng vì vậy vui lòng đọc nó nếu bạn có thời gian.

Kể từ khi phiên bản thiết kế cơ chế cuối cùng được đề xuất trong bài đăng 5 này, những người đóng góp giao thức làm việc trên DG đã thực hiện một số lần lặp lại để kết hợp phản hồi nhận được và làm cho cơ chế trở nên đơn giản hơn, ít mong manh hơn và hiệu quả hơn.

Trước khi trình bày phiên bản cập nhật, hãy để tôi phác thảo vấn đề mà chúng tôi đang cố gắng giải quyết và theo dõi ngắn gọn chuỗi lý do đã dẫn chúng tôi đến giải pháp được đề xuất.

Vấn đề

Hiện tại, mã giao thức Lido và các tham số của nó được Lido DAO kiểm soát thông qua biểu quyết mã thông báo LDO. Giao thức thu phí 5% từ phần thưởng đặt cược và chuyển nó vào kho bạc DAO (5% khác được phân phối cho các nhà khai thác nút tham gia giao thức).

Mặc dù những người nắm giữ LDO thường có động lực để duy trì sự tốt đẹp của giao thức vì nó được phản ánh trong giá mã thông báo LDO, nhưng điều đó không nhất thiết có nghĩa là những người nắm giữ LDO đại diện một cách hiệu quả cho người dùng giao thức. Ví dụ: hãy tưởng tượng rằng những người nắm giữ LDO cùng nhau quyết định tăng phí giao thức: mặc dù điều này có thể có tác động tích cực đến phúc lợi tức thời của những người nắm giữ LDO nhưng rõ ràng nó đi ngược lại lợi ích của ít nhất một bộ phận người dùng giao thức.

Điều này có thể được khái quát hóa như một vấn đề chính-tác nhân (PAP) giữa DAO (tác nhân) và người dùng giao thức (hiệu trưởng). Vấn đề tồn tại vì những người nắm giữ LDO không có được những ưu đãi giống hệt như người dùng.

Hơn nữa, như Vitalik nhấn mạnh trong bài tiểu luận Vượt ra ngoài việc bỏ phiếu bằng tiền xu số 9 , PAP càng trở nên trầm trọng hơn bởi thực tế là lợi ích kinh tế đối với doanh thu của giao thức có thể bị tách khỏi quyền lực quản trị: người ta có thể làm sai lệch các ưu đãi của chủ sở hữu mã thông báo DAO bằng cách hối lộ họ hoặc mượn mã thông báo biểu quyết DAO trên thị trường mở để cố gắng có đủ quyền biểu quyết nhằm thúc đẩy một thay đổi đi ngược lại lợi ích của cả DAO và người dùng giao thức.

Sự hiện diện của PAP không lớn nhưng người ta có thể lập luận rằng, nếu người dùng nhận ra rằng tác nhân hiện tại không đại diện đủ tốt cho họ, họ luôn có thể rời khỏi giao thức và chọn một tác nhân khác phù hợp hơn với lợi ích của họ hoặc thậm chí quyết định loại bỏ đại lý hoàn toàn thông qua đặt cược solo.

Đây là một cơ chế rất quan trọng thường được gọi là bỏ phiếu bằng chân. Về lý thuyết, nó sẽ bảo vệ người dùng khỏi những tác động tiêu cực của bất kỳ động cơ sai lệch nào giữa họ và DAO hoặc bất kỳ cuộc tấn công nào vào DAO. Tuy nhiên, trong thực tế và trong trường hợp cụ thể của việc đặt cược chất lỏng Ethereum, hiệu quả của việc bỏ phiếu bằng chân bị hạn chế do một số yếu tố ảnh hưởng.

Yếu tố đầu tiên là chi tiết cụ thể về cách thức hoạt động của Ethereum PoS. Để hủy đặt cược ETH khỏi trình xác thực, người ta phải đợi cho đến khi trình xác thực thoát hoàn toàn và tất cả các lần thoát của trình xác thực Ethereum đều được xử lý thông qua một hàng đợi với thông lượng hạn chế. Điều này có nghĩa là thời gian cần thiết để rời khỏi giao thức phụ thuộc vào các yếu tố ngoài giao thức bên ngoài và có thể thay đổi theo mức độ lớn. Ngược lại, điều này ngụ ý rằng việc áp đặt khóa thời gian tĩnh cho các quyết định DAO không thể đảm bảo rằng bất kỳ người dùng nào cũng có đủ thời gian để rời khỏi giao thức trước khi DAO áp dụng một thay đổi không có lợi cho người dùng.

Yếu tố thứ hai là một bộ phận đáng kể người dùng chọn đặt cược thanh khoản vì họ muốn triển khai lại vốn đặt cược sang các hình thức hoạt động kinh tế khác, dẫn đến việc token đặt cược thanh khoản (LST) được sử dụng rộng rãi trong DeFi, bao gồm cả các giao thức yêu cầu thêm thời gian để rút tiền (ví dụ: thị trường cho vay). Điều này bổ sung thêm một phần phụ thuộc bên ngoài có thể ngăn người dùng rời khỏi giao thức trong khung thời gian được xác định trước.

Yếu tố thứ ba bắt nguồn từ sự bất cân xứng thông tin giữa đa số thụ động và thiểu số người dùng được đào tạo tích cực: đánh giá chính xác tất cả rủi ro liên quan đến một quyết định quản trị cụ thể, bao gồm cả rủi ro đuôi, đòi hỏi kiến thức mà hầu hết người dùng không có. Việc truyền đạt các tác động bất lợi tiềm ẩn của một quyết định DAO thông qua lớp xã hội cần thêm thời gian, giảm khả năng đa số thụ động rời khỏi giao thức trước khi quyết định có thể thực thi được.

Lido DAO đã thiết lập một số giao thức quản trị để giảm sự bất cân xứng thông tin (ví dụ: khung GOOSE, Nhóm quản trị phụ nhà điều hành nút, khung LIP, cam kết về số lần kiểm tra tối thiểu đối với bất kỳ thay đổi mã mạng chính nào) nhưng tất cả đều là các thỏa thuận tầng xã hội giữa những người nắm giữ LDO hiện tại và do đó không thể bảo vệ khỏi cuộc tấn công từ bên ngoài vào DAO.

Hướng tới giải pháp

Giải pháp cuối cùng cho vấn đề này là giảm thiểu quản trị và cuối cùng là hợp nhất mã và tham số giao thức. Không có rủi ro quản trị nếu không có gì được quản lý.

Giảm dần phạm vi quản trị là điều mà những người đóng góp giao thức coi là cần thiết trong những năm tới. Tuy nhiên, cho đến khi đặc tả Ethereum được hoàn thiện, khả năng nâng cấp mã chỉ có thể bị giảm ở một mức độ nhất định (ví dụ: xem EIP-7002 5, EIP-7251 6). Ngoài ra, bất kỳ mã bất biến nào đều phải được xác minh chính thức ở cấp mã byte để loại trừ khả năng lỗi trình biên dịch tạo ra lỗ hổng không thể sửa được.

Ngoài ra còn có lớp có khả năng thay thế của giao thức đóng vai trò là công cụ đánh giá rủi ro/phần thưởng và phân phối ETH giữa các tập hợp con trình xác thực khác nhau theo cách cân bằng lợi nhuận và rủi ro của bộ trình xác thực kết quả. Rủi ro ở đây bao gồm rủi ro đuôi mà bộ trình xác thực tạo ra cho mạng Ethereum, ví dụ: khả năng kiểm duyệt và rủi ro cắt giảm tương quan. Đang có nghiên cứu đang diễn ra (xem báo cáo 6 này để biết phiên bản mới nhất) về việc liệu giao thức có thể ước tính những rủi ro này với sự trợ giúp của một tiện ích oracle không đáng tin cậy mang lại thông tin cần thiết trên chuỗi hay không nhưng đó là một nỗ lực lâu dài và vẫn chưa rõ bằng cách nào kết quả mong muốn có thể được thực hiện một cách thực tế. Cho đến khi giao thức được triển khai cơ chế không cần sự tin cậy như vậy thì cần phải có một số biện pháp quản trị ở lớp có thể thay thế được.

Một lĩnh vực nghiên cứu tiềm năng nữa là tìm cách giới thiệu tùy chọn tham gia rõ ràng cho các phiên bản bộ tham số và mã mới dành cho chủ sở hữu và tích hợp stETH. Vẫn chưa rõ liệu nó có thể được thực hiện mà không phá vỡ khả năng thay thế LST và dẫn đến sự phân mảnh thanh khoản, do tính thanh khoản là một trong những yếu tố chính thúc đẩy người dùng đến LST, sẽ phá hủy khả năng cạnh tranh của giao thức so với các nhà cung cấp dịch vụ đặt cược thanh khoản phi tập trung và tập trung khác. Tuy nhiên, đây là một hướng nghiên cứu thú vị.

Bây giờ chúng tôi đã xác định rằng giao thức sẽ phải tuân theo một số hình thức quản trị ít nhất là trong trung hạn, hãy xem cách chúng tôi có thể giảm thiểu <a href="https://notes.ethereum.org/@mikeneuder/magnitude -và-hướng"> rủi ro mà việc quản trị này tạo ra 1 .

Quản trị kép

Như đã nêu rõ trong phần đầu tiên, vấn đề chung có thể được chia thành 1) sự hiện diện của PAP và 2) hiệu quả hạn chế của việc bỏ phiếu bằng chân. Vì vậy, lý tưởng nhất là chúng tôi muốn giới thiệu một số cơ chế giúp cải thiện cả sự liên kết giữa DAO và người dùng giao thức cũng như hiệu quả của việc bỏ phiếu bằng chân.

Đó là nơi chúng tôi đi đến thiết kế quản trị kép được đề xuất. Nó nhằm mục đích cải tiến sau:

  1. Cung cấp cho những người đặt cược một cách để báo hiệu một cách đáng tin cậy sự bất đồng của họ với DAO và cam kết rời khỏi giao thức nếu DAO không hợp tác để giải quyết xung đột về động cơ khuyến khích.
  2. Cung cấp một thiết bị đàm phán giữa các bên đặt cược và DAO.
  3. Giới thiệu khóa thời gian động mở rộng cho các quyết định DAO có thể được kích hoạt bởi một số ít người đặt cược tích cực và kéo dài khi có nhiều người đặt cược tham gia hơn.
  4. Cải thiện hiệu quả bỏ phiếu bằng chân bằng cách cho phép người đặt cược thoát khỏi giao thức mà không phải tuân theo các quyết định DAO mới và đang chờ xử lý.

Bạn có thể tìm thấy thông tin tổng quan về thiết kế cơ chế được đề xuất và một số ý tưởng cho nghiên cứu trong tương lai về giảm thiểu rủi ro quản trị trong ghi chú này: <a href="https://hackmd.io/ @skozin /r17mlW2la"">https://hackmd. io/@skozin/r17mlW2la 37 .

Cần lưu ý rằng người đặt cược không phải là đối tượng duy nhất sử dụng giao thức; cũng có các nhà khai thác nút. Một hướng nghiên cứu tiềm năng trong tương lai là tìm cách cải thiện hiệu quả bỏ phiếu bằng chân của các nhà khai thác nút, ví dụ: cho phép một tập hợp con gồm những người đặt cược và người vận hành nút phối hợp một giao thức và phân nhánh DAO bằng cách trỏ lại thông tin xác thực rút tiền của người xác thực vào một hợp đồng mới (hiện không được lớp đồng thuận hỗ trợ).

Một hướng nghiên cứu khác trong tương lai là khám phá quản trị không dùng token và quản trị kết hợp 2.

Bước tiếp theo

Từ đây, một số điều phải xảy ra trước khi thiết kế được hoàn thiện, dẫn đến Đề xuất cải tiến Lido (LIP) chính thức hơn sẽ được gửi để bỏ phiếu DAO và tài liệu Bản ghi quyết định kiến trúc (ADR) liên quan:

  1. Đánh giá tính mạnh mẽ của cơ chế đề xuất thông qua mô hình tấn công và kịch bản.
  2. Đánh giá tính thực tiễn của cơ chế thông qua việc tạo nguyên mẫu mã.
  3. Thu thập phản hồi của cộng đồng.

Chủ đề này nhằm mục đích hoàn thành 3 trong khi những người đóng góp giao thức làm việc trên 1 và 2 (cả hai đều đang được tiến hành) nên mọi phản hồi đều được đánh giá cao!

Điều quan trọng cần nhấn mạnh là, mặc dù quản trị kép (theo ý kiến của tôi) là một bước quan trọng trong việc giảm rủi ro quản trị của giao thức, nhưng đó không phải là bước cuối cùng. Bạn có thể tìm thấy một số ý tưởng để cải tiến hơn nữa trong tài liệu thiết kế cơ chế được liên kết ở trên và tôi mời mọi người quan tâm thảo luận về những ý tưởng đó cũng như bất kỳ cải tiến tiềm năng nào khác bằng cách đăng chủ đề trên diễn đàn này.

Tuyên bố từ chối trách nhiệm:

  1. Bài viết này được in lại từ [lido]. Mọi bản quyền đều thuộc về tác giả gốc [skozin]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
  2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
  3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.

Quản trị kép LDO+stETH (tiếp theo)

Trung cấp12/27/2023, 9:21:07 AM
Bài viết này giới thiệu bản cập nhật mô hình quản trị của dự án Lido, giải thích PAP và các vấn đề liên quan, đồng thời phân tích cách vượt xa việc bỏ phiếu bằng mã thông báo quản trị đơn thuần.

Đây là phần tiếp theo của chủ đề ban đầu về quản trị kép 18. Chuỗi được liên kết chứa một ngữ cảnh quan trọng vì vậy vui lòng đọc nó nếu bạn có thời gian.

Kể từ khi phiên bản thiết kế cơ chế cuối cùng được đề xuất trong bài đăng 5 này, những người đóng góp giao thức làm việc trên DG đã thực hiện một số lần lặp lại để kết hợp phản hồi nhận được và làm cho cơ chế trở nên đơn giản hơn, ít mong manh hơn và hiệu quả hơn.

Trước khi trình bày phiên bản cập nhật, hãy để tôi phác thảo vấn đề mà chúng tôi đang cố gắng giải quyết và theo dõi ngắn gọn chuỗi lý do đã dẫn chúng tôi đến giải pháp được đề xuất.

Vấn đề

Hiện tại, mã giao thức Lido và các tham số của nó được Lido DAO kiểm soát thông qua biểu quyết mã thông báo LDO. Giao thức thu phí 5% từ phần thưởng đặt cược và chuyển nó vào kho bạc DAO (5% khác được phân phối cho các nhà khai thác nút tham gia giao thức).

Mặc dù những người nắm giữ LDO thường có động lực để duy trì sự tốt đẹp của giao thức vì nó được phản ánh trong giá mã thông báo LDO, nhưng điều đó không nhất thiết có nghĩa là những người nắm giữ LDO đại diện một cách hiệu quả cho người dùng giao thức. Ví dụ: hãy tưởng tượng rằng những người nắm giữ LDO cùng nhau quyết định tăng phí giao thức: mặc dù điều này có thể có tác động tích cực đến phúc lợi tức thời của những người nắm giữ LDO nhưng rõ ràng nó đi ngược lại lợi ích của ít nhất một bộ phận người dùng giao thức.

Điều này có thể được khái quát hóa như một vấn đề chính-tác nhân (PAP) giữa DAO (tác nhân) và người dùng giao thức (hiệu trưởng). Vấn đề tồn tại vì những người nắm giữ LDO không có được những ưu đãi giống hệt như người dùng.

Hơn nữa, như Vitalik nhấn mạnh trong bài tiểu luận Vượt ra ngoài việc bỏ phiếu bằng tiền xu số 9 , PAP càng trở nên trầm trọng hơn bởi thực tế là lợi ích kinh tế đối với doanh thu của giao thức có thể bị tách khỏi quyền lực quản trị: người ta có thể làm sai lệch các ưu đãi của chủ sở hữu mã thông báo DAO bằng cách hối lộ họ hoặc mượn mã thông báo biểu quyết DAO trên thị trường mở để cố gắng có đủ quyền biểu quyết nhằm thúc đẩy một thay đổi đi ngược lại lợi ích của cả DAO và người dùng giao thức.

Sự hiện diện của PAP không lớn nhưng người ta có thể lập luận rằng, nếu người dùng nhận ra rằng tác nhân hiện tại không đại diện đủ tốt cho họ, họ luôn có thể rời khỏi giao thức và chọn một tác nhân khác phù hợp hơn với lợi ích của họ hoặc thậm chí quyết định loại bỏ đại lý hoàn toàn thông qua đặt cược solo.

Đây là một cơ chế rất quan trọng thường được gọi là bỏ phiếu bằng chân. Về lý thuyết, nó sẽ bảo vệ người dùng khỏi những tác động tiêu cực của bất kỳ động cơ sai lệch nào giữa họ và DAO hoặc bất kỳ cuộc tấn công nào vào DAO. Tuy nhiên, trong thực tế và trong trường hợp cụ thể của việc đặt cược chất lỏng Ethereum, hiệu quả của việc bỏ phiếu bằng chân bị hạn chế do một số yếu tố ảnh hưởng.

Yếu tố đầu tiên là chi tiết cụ thể về cách thức hoạt động của Ethereum PoS. Để hủy đặt cược ETH khỏi trình xác thực, người ta phải đợi cho đến khi trình xác thực thoát hoàn toàn và tất cả các lần thoát của trình xác thực Ethereum đều được xử lý thông qua một hàng đợi với thông lượng hạn chế. Điều này có nghĩa là thời gian cần thiết để rời khỏi giao thức phụ thuộc vào các yếu tố ngoài giao thức bên ngoài và có thể thay đổi theo mức độ lớn. Ngược lại, điều này ngụ ý rằng việc áp đặt khóa thời gian tĩnh cho các quyết định DAO không thể đảm bảo rằng bất kỳ người dùng nào cũng có đủ thời gian để rời khỏi giao thức trước khi DAO áp dụng một thay đổi không có lợi cho người dùng.

Yếu tố thứ hai là một bộ phận đáng kể người dùng chọn đặt cược thanh khoản vì họ muốn triển khai lại vốn đặt cược sang các hình thức hoạt động kinh tế khác, dẫn đến việc token đặt cược thanh khoản (LST) được sử dụng rộng rãi trong DeFi, bao gồm cả các giao thức yêu cầu thêm thời gian để rút tiền (ví dụ: thị trường cho vay). Điều này bổ sung thêm một phần phụ thuộc bên ngoài có thể ngăn người dùng rời khỏi giao thức trong khung thời gian được xác định trước.

Yếu tố thứ ba bắt nguồn từ sự bất cân xứng thông tin giữa đa số thụ động và thiểu số người dùng được đào tạo tích cực: đánh giá chính xác tất cả rủi ro liên quan đến một quyết định quản trị cụ thể, bao gồm cả rủi ro đuôi, đòi hỏi kiến thức mà hầu hết người dùng không có. Việc truyền đạt các tác động bất lợi tiềm ẩn của một quyết định DAO thông qua lớp xã hội cần thêm thời gian, giảm khả năng đa số thụ động rời khỏi giao thức trước khi quyết định có thể thực thi được.

Lido DAO đã thiết lập một số giao thức quản trị để giảm sự bất cân xứng thông tin (ví dụ: khung GOOSE, Nhóm quản trị phụ nhà điều hành nút, khung LIP, cam kết về số lần kiểm tra tối thiểu đối với bất kỳ thay đổi mã mạng chính nào) nhưng tất cả đều là các thỏa thuận tầng xã hội giữa những người nắm giữ LDO hiện tại và do đó không thể bảo vệ khỏi cuộc tấn công từ bên ngoài vào DAO.

Hướng tới giải pháp

Giải pháp cuối cùng cho vấn đề này là giảm thiểu quản trị và cuối cùng là hợp nhất mã và tham số giao thức. Không có rủi ro quản trị nếu không có gì được quản lý.

Giảm dần phạm vi quản trị là điều mà những người đóng góp giao thức coi là cần thiết trong những năm tới. Tuy nhiên, cho đến khi đặc tả Ethereum được hoàn thiện, khả năng nâng cấp mã chỉ có thể bị giảm ở một mức độ nhất định (ví dụ: xem EIP-7002 5, EIP-7251 6). Ngoài ra, bất kỳ mã bất biến nào đều phải được xác minh chính thức ở cấp mã byte để loại trừ khả năng lỗi trình biên dịch tạo ra lỗ hổng không thể sửa được.

Ngoài ra còn có lớp có khả năng thay thế của giao thức đóng vai trò là công cụ đánh giá rủi ro/phần thưởng và phân phối ETH giữa các tập hợp con trình xác thực khác nhau theo cách cân bằng lợi nhuận và rủi ro của bộ trình xác thực kết quả. Rủi ro ở đây bao gồm rủi ro đuôi mà bộ trình xác thực tạo ra cho mạng Ethereum, ví dụ: khả năng kiểm duyệt và rủi ro cắt giảm tương quan. Đang có nghiên cứu đang diễn ra (xem báo cáo 6 này để biết phiên bản mới nhất) về việc liệu giao thức có thể ước tính những rủi ro này với sự trợ giúp của một tiện ích oracle không đáng tin cậy mang lại thông tin cần thiết trên chuỗi hay không nhưng đó là một nỗ lực lâu dài và vẫn chưa rõ bằng cách nào kết quả mong muốn có thể được thực hiện một cách thực tế. Cho đến khi giao thức được triển khai cơ chế không cần sự tin cậy như vậy thì cần phải có một số biện pháp quản trị ở lớp có thể thay thế được.

Một lĩnh vực nghiên cứu tiềm năng nữa là tìm cách giới thiệu tùy chọn tham gia rõ ràng cho các phiên bản bộ tham số và mã mới dành cho chủ sở hữu và tích hợp stETH. Vẫn chưa rõ liệu nó có thể được thực hiện mà không phá vỡ khả năng thay thế LST và dẫn đến sự phân mảnh thanh khoản, do tính thanh khoản là một trong những yếu tố chính thúc đẩy người dùng đến LST, sẽ phá hủy khả năng cạnh tranh của giao thức so với các nhà cung cấp dịch vụ đặt cược thanh khoản phi tập trung và tập trung khác. Tuy nhiên, đây là một hướng nghiên cứu thú vị.

Bây giờ chúng tôi đã xác định rằng giao thức sẽ phải tuân theo một số hình thức quản trị ít nhất là trong trung hạn, hãy xem cách chúng tôi có thể giảm thiểu <a href="https://notes.ethereum.org/@mikeneuder/magnitude -và-hướng"> rủi ro mà việc quản trị này tạo ra 1 .

Quản trị kép

Như đã nêu rõ trong phần đầu tiên, vấn đề chung có thể được chia thành 1) sự hiện diện của PAP và 2) hiệu quả hạn chế của việc bỏ phiếu bằng chân. Vì vậy, lý tưởng nhất là chúng tôi muốn giới thiệu một số cơ chế giúp cải thiện cả sự liên kết giữa DAO và người dùng giao thức cũng như hiệu quả của việc bỏ phiếu bằng chân.

Đó là nơi chúng tôi đi đến thiết kế quản trị kép được đề xuất. Nó nhằm mục đích cải tiến sau:

  1. Cung cấp cho những người đặt cược một cách để báo hiệu một cách đáng tin cậy sự bất đồng của họ với DAO và cam kết rời khỏi giao thức nếu DAO không hợp tác để giải quyết xung đột về động cơ khuyến khích.
  2. Cung cấp một thiết bị đàm phán giữa các bên đặt cược và DAO.
  3. Giới thiệu khóa thời gian động mở rộng cho các quyết định DAO có thể được kích hoạt bởi một số ít người đặt cược tích cực và kéo dài khi có nhiều người đặt cược tham gia hơn.
  4. Cải thiện hiệu quả bỏ phiếu bằng chân bằng cách cho phép người đặt cược thoát khỏi giao thức mà không phải tuân theo các quyết định DAO mới và đang chờ xử lý.

Bạn có thể tìm thấy thông tin tổng quan về thiết kế cơ chế được đề xuất và một số ý tưởng cho nghiên cứu trong tương lai về giảm thiểu rủi ro quản trị trong ghi chú này: <a href="https://hackmd.io/ @skozin /r17mlW2la"">https://hackmd. io/@skozin/r17mlW2la 37 .

Cần lưu ý rằng người đặt cược không phải là đối tượng duy nhất sử dụng giao thức; cũng có các nhà khai thác nút. Một hướng nghiên cứu tiềm năng trong tương lai là tìm cách cải thiện hiệu quả bỏ phiếu bằng chân của các nhà khai thác nút, ví dụ: cho phép một tập hợp con gồm những người đặt cược và người vận hành nút phối hợp một giao thức và phân nhánh DAO bằng cách trỏ lại thông tin xác thực rút tiền của người xác thực vào một hợp đồng mới (hiện không được lớp đồng thuận hỗ trợ).

Một hướng nghiên cứu khác trong tương lai là khám phá quản trị không dùng token và quản trị kết hợp 2.

Bước tiếp theo

Từ đây, một số điều phải xảy ra trước khi thiết kế được hoàn thiện, dẫn đến Đề xuất cải tiến Lido (LIP) chính thức hơn sẽ được gửi để bỏ phiếu DAO và tài liệu Bản ghi quyết định kiến trúc (ADR) liên quan:

  1. Đánh giá tính mạnh mẽ của cơ chế đề xuất thông qua mô hình tấn công và kịch bản.
  2. Đánh giá tính thực tiễn của cơ chế thông qua việc tạo nguyên mẫu mã.
  3. Thu thập phản hồi của cộng đồng.

Chủ đề này nhằm mục đích hoàn thành 3 trong khi những người đóng góp giao thức làm việc trên 1 và 2 (cả hai đều đang được tiến hành) nên mọi phản hồi đều được đánh giá cao!

Điều quan trọng cần nhấn mạnh là, mặc dù quản trị kép (theo ý kiến của tôi) là một bước quan trọng trong việc giảm rủi ro quản trị của giao thức, nhưng đó không phải là bước cuối cùng. Bạn có thể tìm thấy một số ý tưởng để cải tiến hơn nữa trong tài liệu thiết kế cơ chế được liên kết ở trên và tôi mời mọi người quan tâm thảo luận về những ý tưởng đó cũng như bất kỳ cải tiến tiềm năng nào khác bằng cách đăng chủ đề trên diễn đàn này.

Tuyên bố từ chối trách nhiệm:

  1. Bài viết này được in lại từ [lido]. Mọi bản quyền đều thuộc về tác giả gốc [skozin]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
  2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
  3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.
Nu Starten
Meld Je Aan En Ontvang
$100
Voucher!