Quản trị trên Namada được xây dựng dựa trên triết lý về tính linh hoạt. Trong bài viết này, chúng tôi khám phá các tính năng mà Namada cung cấp và thúc đẩy chúng liên quan đến triết lý này. Chúng ta sẽ cùng nhau khám phá PGF Stewards , đề xuất PGF, đề xuất cầu nối ETH và hơn thế nữa
chúng ta (nên) sống trong một xã hội (lấy cảm hứng từ https://www.eff.org/cyberspace-independence)
Động lực
“Chính phủ có được quyền lực công bằng từ sự đồng ý của người được cai trị” – nguồn: https://www.eff.org/cyberspace-independence
Brian Goetz từng nói ‘Các đối tượng không thay đổi là đơn giản.’ Tuy nhiên, Quản trị không đơn giản và theo nguyên tắc suy luận logic, nó không thể không thay đổi. Bởi vì Namada được tạo ra để tồn tại và phát triển trong nhiều năm với mục tiêu hỗ trợ, tạo điều kiện cho những thế hệ người dùng tiếp theo, nên nó chỉ có ý nghĩa khi nó thay đổi theo sự thay đổi của người dùng.
Vì lý do này, Namada sử dụng một hình thức Quản trị linh hoạt, cho phép người tham gia quản trị gần như hoàn toàn linh hoạt trong việc thay đổi cái gì đó. Bài viết này cố gắng giải thích khả năng của Quản trị trên Namada.
Quản trị trên Namada được xây dựng với nguyên tắc rằng nó nên linh hoạt đủ để hỗ trợ các thay đổi trong giao thức mà không cần hard-fork, nhưng cũng phải có các phương tiện đủ để cho người tham gia có thể biểu đạt sự tán thành hoặc không tán thành với hard-fork được đề xuất.
Cuối cùng, Quản trị xã hội – về phần mềm mà mọi người chọn sử dụng – là tầng cuối cùng và quan trọng nhất trong việc điều phối. Vì lý do này, Namada hỗ trợ việc bỏ phiếu tín hiệu ngoài chuỗi (off-chain) để cho người dùng có khả năng đưa lịch sử những quyết định đó lên chuỗi
Mục đích của bài viết
Bài viết này nhằm mục đích phác thảo các tính năng quản trị ở Namada mang lại cho nó sự linh hoạt.
Chúng tôi bắt đầu bằng cách mô tả ai là người quản trị. Sau đó, chúng tôi mô tả cơ chế bỏ phiếu cho những người tham gia quản trị và kết thúc bằng cách mô tả những loại đề xuất mà quản trị có thể bỏ phiếu.
Ai là người quản trị?
Tất cả chúng ta đều có trách nhiệm
Governance trên Namada bao gồm 2 người tham gia riêng biệt:
- Người ủy quyền (Delegators): Những người gửi stake token nhưng ủy quyền quyền bỏ phiếu cho một địa chỉ khác.
- Người đại diện (Delegates): Những người bỏ phiếu cho các đề xuất Quản trị thay mặt cho người ủy quyền.
Tham gia vào việc quản trị được xác định thông qua việc phân bổ token NAM đã đặt cọc cố định. Việc đặt cọc NAM cho phép người tham gia Quản trị có quyền bỏ phiếu tỷ lệ với số lượng NAM họ đã đặt cọc.
Khi một địa chỉ không phải là validator đặt cọc token, họ thực hiện việc này đến một địa chỉ validator. Validator này sau đó chịu trách nhiệm bỏ phiếu cho các khối thay mặt cho người dùng này.
Mặc định, validator mà người dùng đã ủy quyền token sẽ trở thành người đại diện của tài khoản đó. Sự ủy quyền này ngụ ý rằng validator cũng có thể bỏ phiếu cho các đề xuất Quản trị thay mặt cho người dùng (người bị ủy quyền).
Tuy nhiên, phiếu bầu của người ủy quyền luôn được ưu tiên hơn phiếu bầu của người đại diện.
Ví dụ: giả sử người ủy quyền Bob (quyền bỏ phiếu = 1) đã ủy quyền quyền bỏ phiếu cho người đại diện Alice (quyền bỏ phiếu = 3 bao gồm cả ủy quyền của Bob).
Sau đó, nếu Alice bỏ phiếu “đồng ý” cho Đề xuất A và sau đó Bob bỏ phiếu “không đồng ý” cho Đề xuất A, tổng số phiếu “đồng ý” chỉ là 2. Đề xuất cũng sẽ có 1 phiếu “không đồng ý”
Sự chậm trễ trong việc bỏ phiếu
Để đảm bảo người ủy quyền luôn có khả năng ghi đè phiếu bầu của người đại diện, người đại diện cần phải bỏ phiếu cho các đề xuất trong 2/3 thời kỳ bỏ phiếu ban đầu.
Nếu quy định này không có, một người đại diện độc hại sẽ có động cơ bỏ phiếu (hoặc thay đổi phiếu) vào cuối cùng của bất kỳ đề xuất nào, phản lại lợi ích của người ủy quyền
Đồng thuận hay quản trị
Voting-power có hai ứng dụng chính.
Trong Proof of Stake, voting-power ảnh hưởng đến khả năng được chọn làm người đề xuất khối cũng như trọng lượng của chữ ký của một validator so với các chữ ký của những validator khác khi ký một khối hợp lệ. Khi một tài khoản không phải validator liên kết token NAM với 1 validator, voting-power của validator được tăng lên theo tỷ lệ với số lượng token đang liên kết.
Khi một người ủy quyền “ủy quyền” token NAM đã liên kết cho một người đại diện, voting-power của người đại diện được tăng lên theo tỷ lệ với số lượng token được ủy quyền.
Gửi một đề xuất
Các ‘đề xuất’ được tạo ra để định nghĩa các đối tượng mà người tham gia quản trị sẽ bỏ phiếu và ‘đề xuất’ một thay đổi cụ thể đối với sự đồng thuận xã hội. Thay đổi này thường là việc thay đổi trạng thái của một phần nào đó trong giao thức Namada.
Ví dụ bao gồm việc thay đổi các tham số giao thức như tỷ lệ phát hành tiền, tỷ lệ thưởng PoS, việc cho phép các tài sản khác nhau vào danh sách trắng, v.v. Tất cả những thay đổi này đều được xử lý dễ dàng bởi sổ cái và có thể được đề xuất cùng với một ‘tải trọng’ (payload) thay đổi các tham số này trong bộ lưu trữ và có tác động ngay lập tức sau khi thay đổi.
Các ví dụ khác có thể bao gồm việc sửa lỗi cơ bản trong mã nguồn, thêm một số chức năng yêu cầu thay đổi kiến trúc hoặc nâng cấp một phần nào đó trong công nghệ của ngăn xếp Namada. Điều này có thể đòi hỏi một hard-fork và cài đặt một ‘phiên bản’ mới của Namada.
Đối với tất cả các người tham gia vào mạng thử nghiệm công cộng của chúng tôi, điều này nên được thực hành thường xuyên 😉
Bỏ phiếu cho các đề xuất
Khi một đề xuất được đưa ra, tất cả những người tham gia quản trị đều có thể bỏ phiếu cho đề xuất đó bằng cách gửi phiếu bầu Yay hoặc Nay thông qua giao dịch biểu quyết.
Ví dụ về Đề Xuất: Bầu cử PGF Stewards
Một ví dụ giúpđể hiểu rõ hơn về các đề xuất quản trị Namada là nghiên cứu Đề xuất Bầu cử PGF Stewards của Namada. Đề xuất này đề xuất thêm hoặc loại bỏ một PGF Steward khỏi danh sách các Steward trên Namada.
Bất kỳ người dùng nào cũng có thể gửi đề xuất, miễn là họ có đủ tiền để làm điều đó. Số tiền cần để gửi một đề xuất quản trị là một tham số quản trị (khá “meta”). Tiền được giữ trong tài khoản giữ tiền đặc trưng cho đến khi đề xuất được giải quyết.
Khi đề xuất đã được tạo, người tham gia quản trị (có thể là validators hoặc delegators có một lượng cổ phần được gắn kết) có thể bỏ phiếu cho đề xuất.
Để chấp thuận đề xuất, cần phải có ít nhất một phiếu bầu “Chấp nhận”, trong khi phiếu “Từ chối” cho thấy sự không tán thành với đề xuất.
Nếu ít nhất 2/3 tổng quyền lực bỏ phiếu cho đề xuất này và hơn 50% số người bỏ phiếu ủng hộ đề xuất (tức là đã bỏ phiếu Chấp nhận), thì đề xuất đã “được thông qua” và thay đổi Steward sẽ được thực hiện.
Có hai kịch bản: 1/ Đề xuất bị từ chối 2/ Đề xuất được chấp nhận
Trong trường hợp đề xuất bị từ chối, số tiền trong tài khoản giữ tiền sẽ bị “phạt”. Nếu đề xuất được chấp nhận, thì số tiền sẽ được trả lại cho người đề xuất và thay đổi trạng thái sẽ được thực hiện (trong trường hợp này, PGF Steward mới sẽ được bầu hoặc loại bỏ) vào cuối chu kỳ
Kinh tế của các đề xuất
Tại sao lại có phí cho các đề xuất?
Vì những lí do giống như việc chúng ta trả phí gas cho nên chúng ta cũng trả thêm chi phí cho các đề xuất. Khi người dùng đề xuất một thay đổi, đề xuất của họ cần phải cạnh tranh không chỉ về không gian trên block mà còn về sự chú ý từ người tham gia trong cộng đồng. Việc này được xem như một khoản phí, giúp đảm bảo rằng cộng đồng quản trị sẽ chú ý đến các đề xuất quan trọng và hữu ích. Nếu đề xuất được chấp nhận và mang lại lợi ích cho cộng đồng, cộng đồng sẽ hoàn trả phí này cho người đề xuất, thể hiện sự công bằng đối với những nỗ lực mà họ đã bỏ ra
Các loại đề xuất khác nhau trên Namada
Có 3 (và một nửa) loại đề xuất quản trị trên Namada.
Đề xuất mặc định
Đề xuất mặc định là loại đề xuất quản trị chung nhất trên Namada. Có hai dạng của đề xuất mặc định:
- Có chứa wasm payload
- Không chứa wasm payload
Các đề xuất mặc định không chứa wasm payload tồn tại để tạo ra sự phối hợp xung quanh một sự đồng thuận cụ thể. Điều này có thể là dạng của một hard-fork, nhưng cũng có thể chỉ là các dạng khác của đồng thuận xã hội, như việc đổi tên các khái niệm khác nhau, đề xuất tập trung vào Namada grants/bug-bounties, việc thỏa thuận xây dựng cầu nối, vv.
Khi các đề xuất mặc định có wasm payload được chấp nhận, họ sẽ thực thi mã wasm để thực hiện một thay đổi trạng thái trên chuỗi. Điều này được thiết kế để thay đổi các tham số quản trị. Ví dụ, bộ tài sản được khuyến khích trong shielded pool và/hoặc kích thước của trợ cấp là các tham số có thể được thay đổi thông qua loại đề xuất quản trị này.
Bất kỳ người dùng Namada nào đều có thể đề xuất một đề xuất mặc định và phải đặt cọc NAM để làm điều này. Bất kỳ người tham gia quản trị nào cũng có thể bỏ phiếu cho đề xuất này.
Để được thông qua, ít nhất 2/3 sức mạnh bỏ phiếu của Namada phải bỏ phiếu cho đề xuất và hơn nữa, hơn một nửa số phiếu này phải ủng hộ cho đề xuất.
Đề xuất tùy chỉnh
Các đề xuất quản trị không mặc định trên Namada được gọi là “Đề xuất tùy chỉnh”.
Khi viết, có ba loại đề xuất tùy chỉnh:
- Đề xuất ETH
- Đề xuất PGF
- Đề xuất Steward
-Đề xuất ETH-
Đề xuất quản trị này là một dạng đặc biệt của đề xuất quản trị, vì nó liên quan đến mã code mà nó sẽ thực hiện các cuộc gọi đến các chức năng trên hợp đồng thông minh Ethereum dùng để quản lý cầu nối ETH-Namada.
Theo lời của kỹ sư ETH-bridge của chúng ta, Fraccaman, việc truyền tải thông tin của các đề xuất ETHBridge là “rất tuyệt vời”. Khi đề xuất được thông qua, các validators phải truyền tải một giao dịch giao thức ký tương ứng với các byte được chỉ định trong đề xuất. Ở mức kỹ thuật, các byte này đại diện cho cuộc gọi chức năng được mã hóa ABI đến chức năng hợp đồng thông minh Ethereum. Khi đủ chữ ký đã được thu thập, bất kỳ người dùng nào cũng có thể nộp bộ chữ ký đó và gọi chức năng của hợp đồng thông minh được chỉ định trong đề xuất. Hợp đồng thông minh bao gồm logic để đảm bảo các chữ ký là hợp lệ và đủ điều kiện. Khi những điều kiện này được đáp ứng, chức năng của hợp đồng thông minh được thực thi.
Bất kỳ người dùng Namada nào đều có thể đề xuất một đề xuất ETH và phải đặt cọc NAM để thực hiện điều này. Tuy nhiên, chỉ các validators mới có thể bỏ phiếu cho các đề xuất này.
Để được thông qua, ít nhất 2/3 sức mạnh bỏ phiếu của Namada phải bỏ phiếu cho đề xuất và hơn một nửa số phiếu này phải ủng hộ cho đề xuất
-Đề xuất PGF-
Các đề xuất PGF là những đề xuất quản trị chỉ có thể được đề xuất bởi bộ PGF Stewards hiện tại đã được bầu cử. Đây là một dạng đặc biệt của đề xuất, thực hiện thanh toán cho hàng hóa công cộng (RPGF) theo hình thức trả tiền công cộng liên tục (CPGF).
Các đề xuất PGF mặc định được thông qua, trừ khi bị người tham gia quản trị chặn lại.
Người tham gia quản trị có thể chặn các đề xuất này chỉ khi:
Ít nhất 1/3 tổng số quyền bỏ phiếu tham gia vào đề xuất và hơn một nửa số phiếu bỏ phiếu phải là Nay. Ngoài ra, nếu ít nhất 2/3 tổng số quyền bỏ phiếu đã bỏ phiếu Nay cho đề xuất (điều này biểu thị sự phản đối đáng kể), PGF Steward sẽ bị loại khỏi bộ PGF Stewards
-Đề xuất Steward-
Đề xuất Steward tồn tại để bầu chọn (hoặc loại bỏ) một Steward Quỹ hàng hóa công cộng mới (hoặc cũ).
Những đề xuất này có thể được đề xuất bởi bất kỳ người dùng nào và được bỏ phiếu bởi người tham gia quản trị. Đề xuất chỉ định địa chỉ của Steward sẽ được bầu chọn/loại bỏ. Mô tả đề xuất cần bao gồm lý do tại sao Steward nên được bầu chọn/loại bỏ.
PGF Steward được bầu chọn nếu và chỉ nếu: Ít nhất 1/3 quyền bỏ phiếu của Namada phải tham gia vào đề xuất và hơn một nửa số phiếu bỏ phiếu phải ủng hộ đề xuất.
Cơ chế đề xuất ngoại tuyến
Mọi thứ đều tốt khi mạng Namada hoạt động đúng và như mong đợi. Nhưng khi mạng bị dừng lại hoặc gặp sự cố, chúng ta phải làm thế nào để đạt được sự đồng thuận?
Các tính năng quản trị trên Namada bao gồm một số thay đổi độc đáo so với các mô hình quản trị khác.
Ngoài việc giới thiệu “phí chú ý” cho các đề xuất quản trị, Namada cho phép các đề xuất được nộp cả ngoại tuyến và trực tuyến. Các đề xuất quản trị ngoại tuyến tồn tại để cấp linh hoạt lớn hơn cho những người tham gia quản trị trên Namada.
Công cụ này đặc biệt hữu ích trong những lúc cần thực hiện một hard-fork để giải quyết một vấn đề nào đó. Một trường hợp ví dụ là khi mạng bị dừng lại, có thể xảy ra do tấn công Byzantine hoặc lỗi tương tự.
Trong trường hợp này, có cơ chế để gửi phiếu bầu đến một trung tâm tập trung nào đó, như một dịch vụ truyền thông (nên là phiên bản phi tập trung) đã được thống nhất. Người dùng và nhà xác nhận sau đó có thể xác minh những phiếu bầu và chữ ký này giống như họ có thể làm trên chuỗi.
Gửi đề xuất ngoại tuyến
Các đề xuất được thực hiện ngoại tuyến sau đó sẽ được gửi trên chuỗi dưới dạng chữ ký trên hàm băm của JSON đại diện cho cấu trúc:
{
content: Base64<Vec<u8>>,
author: Address,
votingStart: TimeStamp,
votingEnd: TimeStamp,
signature: Base64<Vec<u8>>
}Gửi phiếu bầu ngoại tuyến
Tương tự, phiếu bầu được gửi dưới dạng chữ ký trên hàm băm của cấu trúc json:
{
content: Base64<Vec<u8>>,
author: Address,
votingStart: TimeStamp,
votingEnd: TimeStamp,
signature: Base64<Vec<u8>>
}Kết luận
Hệ thống quản trị của Namada rất linh hoạt. Nó nhằm mục đích đáp ứng hầu hết các thay đổi thông qua các đề xuất trên chuỗi và có thể sử dụng tải trọng wasm và ABI để thực hiện điều đó. Nó cũng nhận ra sự cần thiết của hard-fork và điều chỉnh các cơ chế phối hợp để thực hiện điều này. Quản trị được thiết lập theo cách giúp người dùng sở hữu giao thức nhiều nhất có thể, điều này chỉ có ý nghĩa vì họ là những người tạo nên nó.