Jump Crypto: Làm cách nào để dùng mã nguồn đảm bảo tính độc lập trong quản trị ủy quyền token?
Tuyển chọn TechFlowTuyển chọn TechFlow
Jump Crypto: Làm cách nào để dùng mã nguồn đảm bảo tính độc lập trong quản trị ủy quyền token?
Người sở hữu có thể tự do cấp phép, người đại diện có thể bỏ phiếu độc lập.
Chuyên sâu báo cáo Web3
Tác giả: Nihar Shah, Joe Howarth
Dịch: aididiaojp.eth, Foresight News
TÓM TẮT
-
Mặc dù các chương trình ủy quyền token có thể tạo ra quản trị vững chắc, nhưng tính độc lập của việc ủy quyền bị hạn chế do người nắm giữ token có thể thu hồi quyền ủy nhiệm bất cứ lúc nào.
-
Đối với những người nắm giữ token yêu cầu tính độc lập, ví dụ như các tổ chức, chúng tôi đề xuất hợp đồng ủy quyền token nên tích hợp thời gian khóa rõ ràng.
-
Chúng tôi minh họa thông qua hợp đồng Maker, đồng thời bổ sung các chức năng khác, ví dụ như nếu quyết định là hai chiều, hoặc người nắm giữ token kích hoạt kênh khẩn cấp, quản trị có thể bỏ qua thời gian khóa.
Giới thiệu
Trong hai năm qua, khái niệm ủy quyền token ngày càng trở nên phổ biến. Ủy quyền token là việc người nắm giữ token chuyển quyền biểu quyết trên chuỗi của họ cho người khác, và các giao thức lớn như Maker, Compound và Uniswap đều đang sử dụng hình thức này để quản trị cộng đồng. Việc ủy quyền giúp nâng cao hiệu quả quản trị và thúc đẩy sự phát triển của cộng đồng, bao gồm các nhóm sinh viên, tổ chức phi lợi nhuận và các nhà lãnh đạo cộng đồng.
Ủy quyền token mang lại hai lợi ích đặc biệt. Lợi ích trực tiếp nhất là làm cho quản trị hiệu quả hơn. Nếu không có chương trình ủy quyền, một số thành viên cộng đồng có lợi ích nhỏ hoặc không đủ thời gian sẽ phải tự mình đọc hàng chục đề xuất, tìm hiểu các kế hoạch quản trị phức tạp để tham gia bỏ phiếu. Thông qua chương trình ủy quyền, các chuyên gia có thể đưa ra quyết định sáng suốt, nhất quán và quan trọng hơn. Trong nhiều trường hợp, nền dân chủ đại diện có ưu điểm hơn so với dân chủ trực tiếp, và thị trường tiền mã hóa cũng không ngoại lệ.
Kể từ năm ngoái, lợi ích thứ hai của việc ủy quyền token bắt đầu nổi bật: tính trung lập. Ví dụ, một số người nắm giữ token sở hữu lượng lớn và có thể nắm giữ token trong các giao thức đối thủ cạnh tranh; những người này có thể mong muốn xây dựng một cộng đồng phi tập trung và công bằng, và việc ủy quyền quyền biểu quyết là một cách đảm bảo họ được xem là trung lập.
Lợi ích thứ hai này không chỉ dựa vào chương trình ủy quyền token để đảm bảo — nó cần điều kiện đặc biệt rằng đại diện phải độc lập với người nắm giữ token. Ví dụ, Jeff Amico của a16z trong bài viết của ông đã nêu rõ nguyên tắc ủy quyền token, nhấn mạnh đặc biệt tầm quan trọng của việc «cho phép mỗi đại diện bỏ phiếu một cách độc lập với người nắm giữ token theo bất kỳ cách nào mà họ cho là phù hợp». Tuy nhiên, phần lớn các giao thức ủy quyền hiện tại không thực thi tính độc lập này, và trong một số trường hợp, tính độc lập này có thể bị cố ý phá vỡ trước các đề xuất quản trị quan trọng.
Bài viết này cung cấp một giải pháp đơn giản dựa trên mã: bằng cách thêm chức năng thời gian khóa vào giao thức, người nắm giữ token không thể thu hồi quyền quản trị của người được ủy thác trong thời gian khóa. Ngoài ra, chúng tôi đã xây dựng một ví dụ tham khảo cho khái niệm này, cùng với một số chức năng tùy chọn tương thích với giao thức Maker, bao gồm chức năng bỏ qua thời gian khóa hai chiều không khẩn cấp và một chiều khẩn cấp.
Thiên đường mất mát: Thu hồi ủy quyền
Dù được coi là tiềm năng cao, việc ủy quyền token cũng không tránh khỏi bị chỉ trích. Cả về lý thuyết lẫn thực tiễn, các chương trình ủy quyền token dễ dàng bỏ qua các quy tắc liên quan đến việc ủy quyền, làm suy yếu mong muốn xây dựng một hệ thống quản trị vững chắc.
Ví dụ, Chris Blec từ DeFi Watch luôn tích cực yêu cầu a16z làm rõ lựa chọn và tương tác trong chương trình ủy quyền của họ. Blec chỉ ra rằng nếu đề xuất quản trị hoàn toàn được phê duyệt bởi một hoặc hai đại diện nắm giữ, điều này sẽ dấy lên nghi ngờ về mối quan hệ giữa đại diện bầu cử và người nắm giữ token.
Những rủi ro này là có thật, ví dụ ngoài Maker's Poll 819, còn được biết đến rộng rãi hơn với tên gọi LOVE vote. Cuộc bỏ phiếu này xoay quanh việc lựa chọn cơ quan giám sát cho vay và cuộc thảo luận rộng rãi trong cộng đồng về việc phân quyền và hiệu quả quản trị. Đề xuất này gây tranh cãi lớn và rất căng thẳng (nó lập kỷ lục tham gia bỏ phiếu của Maker, và đến thời điểm viết bài này vẫn giữ kỷ lục). Luca Prosperi đã ghi chép chi tiết quá trình bỏ phiếu rộng lớn hơn, nhưng chủ yếu tập trung vào các chi tiết liên quan đến việc ủy quyền token.
Điều này cho thấy rằng trong các đề xuất quản trị quan trọng, chương trình ủy quyền có thể bị bỏ qua. Ví dụ, Rune Christensen, người sáng lập Maker, đã thay đổi việc ủy quyền đề xuất trong thời gian ủy quyền, ảnh hưởng đến kết quả bỏ phiếu. Mặc dù Christensen công khai phản đối đề xuất này, nhưng gần như tất cả các token MKR của ông đều đã được ủy quyền. Tuy nhiên, trong khoảng thời gian bỏ phiếu kéo dài hai tuần, ông đã thu hồi quyền ủy nhiệm từ các đại diện đã bỏ phiếu thuận hoặc trắng tay, và chuyển các token này sang ủy quyền cho các đại diện khác chưa bỏ phiếu. Việc tái phân bổ này dường như chỉ là một chiến thuật nhằm che giấu sự bất đồng căn bản giữa Christensen và các đại diện bỏ phiếu thuận. Trong vòng ba ngày sau khi kết thúc bỏ phiếu, Christensen lại chuyển quyền ủy nhiệm trở lại cho các đại diện đã bỏ phiếu thuận trong cuộc bầu cử trước đó. Mô hình này được mô tả trong hình dưới đây:
Giải pháp pháp lý
Các chương trình ủy quyền token cần được hoàn thiện hơn. Một giải pháp là sử dụng hợp đồng pháp lý để đảm bảo tính độc lập và thực thi ủy quyền, ví dụ như trong chương trình ủy quyền của a16z, cam kết rằng đại diện sẽ giữ quyền quản trị trong thời gian tối thiểu [N] tháng. Nếu đại diện bỏ phiếu trái với lợi ích, điều này có thể giảm nguy cơ người nắm giữ token thu hồi quyền quản trị. Tổng quát hơn, nó giới hạn áp lực mà người nắm giữ token có thể gây ra lên đại diện của họ.
Nguyên tắc này được thực thi thông qua hợp đồng pháp lý đặt trong kho lưu trữ Github công khai. Điểm then chốt nằm ở Điều 6, quy định: «Để ngăn ngừa khả năng đại diện không thực hiện đúng trách nhiệm quản trị theo thỏa thuận, thời hạn ban đầu của thỏa thuận này là [N] tháng kể từ ngày có hiệu lực, và người nắm giữ token chỉ có thể chấm dứt thỏa thuận này sau khi hết thời hạn».
Tuy nhiên, cơ chế pháp lý là lựa chọn kém ưu việt hơn. Chúng tôi không nghi ngờ a16z, nhưng những người đi theo họ có thể không cao thượng như vậy. Việc thực thi hợp đồng pháp lý tốn kém và gắn liền với sự phân bố quyền lực bất đối xứng, bao gồm cả đàm phán thiếu minh bạch. Trong tay những người nắm giữ token ít quan tâm, hợp đồng pháp lý hầu như không tạo ra kiểm tra ý nghĩa nào.
Do đó, do phụ thuộc quá nhiều vào các giả định về minh bạch và khả năng thực thi, hợp đồng pháp lý có thể là cơ chế sai lầm để mở rộng và tăng cường các chương trình ủy quyền token.
Đề xuất: Dùng mã, không dùng pháp luật
Bài viết này đề xuất một giải pháp đơn giản: dùng hợp đồng thông minh thay vì hợp đồng pháp lý. Nói cách khác, bảo vệ tính độc lập của đại diện bằng cách nhúng thời gian khóa trực tiếp vào hợp đồng thông minh. Điều này minh bạch cao trước sự việc, dễ thực thi sau sự việc, và quan trọng nhất, thường là một triển khai kỹ thuật đơn giản.
Chúng tôi minh họa bằng hợp đồng Maker. Hầu hết logic ủy quyền chính nằm trong hợp đồng VoteDelegate.sol, đặc biệt chú ý đến các hàm lock và free, vốn hoàn toàn đáp ứng yêu cầu. Người nắm giữ token dùng hàm lock để gán token và phân bổ quyền quản trị, và dùng hàm free để thu hồi lại các token và quyền quản trị liên quan.
Cũng có thể thực hiện một vài sửa đổi đơn giản. Thứ nhất, khi gọi hàm khởi tạo hợp đồng, chúng tôi định nghĩa một biến gọi là _lockupPeriod; thứ hai, người nắm giữ token gọi hàm initialUnlock để kích hoạt bộ đếm ngược mở khóa; thứ ba, để kiểm tra việc tuân thủ thời gian khóa, cần sửa đổi nhẹ hàm free.
Bằng cách nhúng thời gian khóa, chương trình ủy quyền token trở nên minh bạch và đáng tin cậy hơn, với tính độc lập của đại diện được đảm bảo bởi mã chứ không phải pháp luật.
Chức năng bỏ qua khẩn cấp
Tất nhiên, thời gian khóa không phải lúc nào cũng mong muốn, và chúng ta có thể điều chỉnh hợp đồng thông minh tương ứng.
Thứ nhất, người được ủy thác và người nắm giữ token có thể đồng ý chấm dứt mối quan hệ ủy quyền. Trong trường hợp này, có thể cung cấp chức năng bỏ qua, điều này có thể thực hiện thông qua một hàm đơn giản delegatorBypassLockup, cho phép người được ủy quyền từ bỏ quyền quản trị mà không bị trì hoãn. (Lưu ý rằng tham số isDelegatorBypassEnabled có thể được kích hoạt khi khởi động hợp đồng.)
Thứ hai, cũng có thể xảy ra tình huống khẩn cấp mà người nắm giữ token đơn phương bỏ qua thời gian khóa, ví dụ như đại diện hành xử một cách cực kỳ thiếu trách nhiệm hoặc thù địch, tất nhiên điều này sẽ không xảy ra thường xuyên.
Một giải pháp tốt là cho phép người nắm giữ token bỏ qua thời gian khóa bằng cách hủy bỏ vĩnh viễn token của họ, điều này dễ dàng thực hiện. Khi khởi tạo hợp đồng, chủ sở hữu token thiết lập một giá trị EmergencyUnlockBurnPercent (có thể lên tới 100%). Sau đó, sửa đổi hàm free để kiểm tra xem người nắm giữ token có chọn đường khẩn cấp hay không. Nếu có, nó chỉ trả lại phần token chưa bị đốt và đốt phần còn lại. Chúng tôi trình bày một phần logic này ở đây:
Kho mã đầy đủ
Yêu cầu hàm chứa tất cả các chức năng và sửa đổi được thảo luận trong bài viết này có thể được tìm thấy trong kho Github công khai sau, nơi cũng bao gồm tất cả các thay đổi cần thiết cho kiến trúc Maker. Chúng tôi hoan nghênh mọi ý kiến và đề xuất, và tin rằng hợp đồng này đã sẵn sàng để triển khai vào sản xuất.
Tầm nhìn tương lai: Khả năng kết hợp
Các chương trình ủy quyền token có thể trở nên phong phú hơn, và chúng tôi tin rằng tính khả năng kết hợp của hợp đồng ủy quyền token sẽ mở ra làn sóng đổi mới tiếp theo, ví dụ như nếu đại diện có thể ủy quyền quyền biểu quyết của họ cho các đại diện khác thì sao?
Mối quan hệ này có thể làm cho người được ủy quyền độc lập hơn. Ví dụ, người nắm giữ token có thể ủy quyền token của họ cho một nhóm sinh viên. Nhóm sinh viên này có thể tiếp tục ủy quyền các quyền này cho các thành viên cá nhân trong danh sách quản trị, mà không cần tiết lộ danh tính cụ thể cho người nắm giữ token. Do đó, nếu người nắm giữ token muốn gây áp lực mềm, họ thậm chí không biết phải nhắm vào ai, hoặc ai đã bỏ phiếu ủng hộ hoặc phản đối lợi ích của họ.
Khả năng kết hợp cũng có thể kết hợp với các hợp đồng phong phú hơn để cho phép tương tác sáng tạo hơn giữa người nắm giữ token và đại diện. Ví dụ, người nắm giữ token có thể được phép rút token từ người được ủy quyền một cách đơn phương, nhưng chỉ nhận được token sau khi thời gian khóa tối thiểu kết thúc. Các hợp đồng kết hợp sẽ là một cách để thực hiện điều này.
Kết luận
Việc khóa không phù hợp với tất cả mọi người, ví dụ những người bị thu hút bởi lợi thế hiệu quả ban đầu của chương trình ủy quyền token sẽ thấy việc khóa là không cần thiết. Tuy nhiên, việc khóa rất hữu ích đối với những người nắm giữ token cụ thể quan tâm đến việc duy trì tính trung lập (ví dụ như người sáng lập, tổ chức nắm giữ, v.v.).
Quan trọng là, chúng tôi muốn minh bạch: một số người nắm giữ token muốn trao cho đại diện của họ mức độ độc lập lớn, trong khi những người khác muốn thiết lập mối quan hệ giám sát chặt chẽ hơn. Tình trạng hiện tại buộc tất cả những người này vào cùng một hợp đồng thông minh và khiến họ phải thể hiện ý định thực sự thông qua các tuyên bố công khai và tài liệu pháp lý rời rạc. Hợp đồng này cho phép mỗi người nắm giữ token chọn khung phù hợp nhất với họ, bao gồm thời gian khóa mong muốn, chức năng bỏ qua lẫn nhau và tham số hủy khẩn cấp. Toàn bộ quá trình diễn ra trên chuỗi, mọi người đều có thể thấy, không ai cần giám sát.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
