Quản trị DAO trên Argumentree: Từ Thảo luận Mở đến Phán quyết Được Ghi lại

Cuộc bỏ phiếu ngân khố mà không ai thực sự thảo luận.

Đề xuất yêu cầu một phần ý nghĩa từ kho bạc. Nó đã được thông qua. Sự tham gia chỉ chiếm một tỷ lệ phần trăm đơn chữ số của các token đủ điều kiện, ba người nắm giữ lớn cung cấp hầu hết trọng số, và cuộc thảo luận — như nó đã diễn ra — diễn ra trong một kênh trò chuyện với bốn trăm tin nhắn mỗi ngày, hai chủ đề diễn đàn, và một cuộc gọi thoại không có biên bản. Một tháng sau, khi đội ngũ được tài trợ bỏ lỡ cột mốc đầu tiên, một thành viên đã đặt ra câu hỏi hiển nhiên: chúng ta thực sự nghĩ rằng mình đang phê duyệt điều gì, và ai đã xem xét nó? Không ai có thể trả lời. Không phải vì không ai đã xem xét nó — hai thành viên đã nêu chính xác rủi ro đã xảy ra — mà vì những phản đối của họ là tin nhắn 214 và 380 trong một kênh mà không ai sẽ quay lại xem.

Đây là sự thất bại tiêu chuẩn của quản trị DAO, và đó không phải là vấn đề bỏ phiếu. Bỏ phiếu trên chuỗi hoạt động: nó minh bạch, không thể bị giả mạo và là cuối cùng. Những gì thất bại là mọi thứ trước khi bỏ phiếu — sự thảo luận rải rác trên các phương tiện không tích lũy, các lập luận mà cử tri trung bình không bao giờ gặp phải, và một hồ sơ lý luận biến mất ngay khi cuộc bỏ phiếu kết thúc. Phê bình của Vitalik Buterin về việc bỏ phiếu bằng coin chỉ ra một điểm sâu sắc hơn: cuộc bỏ phiếu tổng hợp sở thích, và khi bước hình thành sở thích bị hỏng, sự tổng hợp ghi lại một sự đồng thuận kém được hình thành.

Giải pháp là cấu trúc: thực hiện cuộc thảo luận như một cây lập luận — một địa điểm, một yêu cầu đang được xem xét, mọi lập luận đều có thể quy cho và thách thức, phán quyết của cộng đồng được hiển thị trước khi bất kỳ điều gì được đưa lên chuỗi, và toàn bộ hồ sơ là vĩnh viễn. Hướng dẫn này đi qua quy trình làm việc như nó đang hoạt động hôm nay (Phần 1), sau đó xem trước quy trình đề xuất tích hợp trong lộ trình (Phần 2). Để hiểu tại sao mô hình cây phù hợp với các cộng đồng được quản lý bằng token nói chung, trung tâm quản trị blockchain đưa ra lập luận đầy đủ; để biết các nguyên tắc quản trị vượt ra ngoài công cụ, xem các thực tiễn tốt nhất về quản trị DAO.

Thiết lập: trường hợp sử dụng Quản trị DAO

Một quyết định quan trọng trước bất kỳ điều gì khác: tạo người thuê với trường hợp sử dụng DAO Governance. Việc chọn trường hợp sử dụng diễn ra khi đăng ký, và DAO Governance là trường hợp sử dụng duy nhất có khả năng khác biệt một cách có ý nghĩa — đây là những tính năng cụ thể cho quản trị mà hướng dẫn này dựa vào. Một không gian làm việc được tạo ra như, chẳng hạn, Chiến lược Doanh nghiệp sẽ không hiển thị chúng bất kể cấp độ kế hoạch. Mỗi DAO có một người thuê riêng — một tên miền phụ riêng, quy tắc thành viên và quy tắc hiển thị — vì vậy các thiết lập đa cộng đồng được giữ tách biệt một cách rõ ràng.

• ✓Điểm kiểm tra: người thuê được tạo với DAO Governance được chọn là trường hợp sử dụng chính; các thành viên được mời trước khi chủ đề quản trị đầu tiên mở.

Phần 1 — quy trình thảo luận, trực tiếp hôm nay

Quy trình làm việc diễn ra từ câu hỏi đến phán quyết đã ghi lại trong sáu bước. Mọi thứ trong phần này hiện đang hoạt động, trên bất kỳ người dùng DAO nào:

1. 1Mở chủ đề quản trị như một yêu cầu gốc. Không phải là tiêu đề — một tuyên bố có thể quyết định: "DAO nên tài trợ cho khoản trợ cấp hạ tầng với số tiền đã yêu cầu trong hai quý." Một yêu cầu có thể được hỗ trợ, tấn công và cuối cùng được đánh giá là điều làm cho mọi bước tiếp theo hoạt động. Điểm kiểm tra: gốc là một tuyên bố mà ai đó có thể không đồng ý, không phải là nhãn chủ đề.
2. 2Xây dựng lập luận — bằng tay hoặc bằng cách trích xuất. Hai con đường, cùng một đích đến. Các thành viên tự viết các lập luận ủng hộ và phản đối trực tiếp, được phân loại theo danh mục, mỗi lập luận là một tuyên bố kèm theo bằng chứng của nó. Hoặc — thường nhanh hơn cho một cuộc tranh luận đã diễn ra — dán văn bản thảo luận hiện có và để trích xuất AI chuyển đổi nó thành một cây lập luận đề xuất, mà các thành viên xem xét và tinh chỉnh thay vì sao chép. Các tin nhắn 214 và 380 trở thành các nút hiển thị thay vì bị chôn vùi trong lịch sử trò chuyện. Điểm kiểm tra: mỗi điểm quan trọng từ cuộc thảo luận rải rác đều có một nút; các bản sao được hợp nhất.
3. 3Chạy kiểm tra AI. Kiểm tra xác thực AI đánh dấu các điểm yếu — các tuyên bố không được hỗ trợ, các lập luận trùng lặp, các điểm phản biện thiếu — trước khi các thành viên dành sự chú ý cho chúng. Hãy coi nó như một lần kiểm tra lỗi trong trường hợp, không phải là một thẩm phán: nó làm chặt chẽ cấu trúc; nó không quyết định gì cả. Điểm kiểm tra: các lập luận đã được đánh dấu được sửa chữa, hợp nhất hoặc giữ lại một cách có ý thức.
4. 4Đánh giá — và đọc phán quyết của nút gốc. Các thành viên đánh giá các lập luận; sự tổng hợp được cộng dồn lên nút gốc, mang lại cho cộng đồng một phán quyết rõ ràng về câu hỏi trước khi bất cứ điều gì được đưa lên chuỗi. Đây là bước đền bù của hướng dẫn: thay vì phát hiện cảm xúc thông qua chính lá phiếu, DAO thấy được vị trí của mình — và nơi nó bị chia rẽ — trong khi vẫn còn thời gian để thảo luận. Điểm kiểm tra: sự tham gia rộng rãi trong việc đánh giá, không chỉ những tiếng nói quen thuộc; các sự chia rẽ được xác định.
5. 5Thách thức, thương lượng, đánh giá — ba chuỗi. Một thành viên nghi ngờ một lập luận mở một chuỗi Hỏi & Đáp về nó: câu hỏi, câu trả lời của tác giả, theo dõi, câu trả lời — bốn lượt, hoàn chỉnh, có thể quy trách nhiệm. Hai phe ủng hộ các lập trường khác nhau điều hành một chuỗi Thỏa hiệp — một lập trường trung gian được đề xuất, được thương lượng trên hồ sơ, điều này hoặc tạo ra một lập trường đã sửa đổi hoặc ghi lại chính xác nơi mà sự chia rẽ tồn tại. Một đánh giá chính thức diễn ra như một chuỗi Đánh giá. Tất cả ba thay thế kênh bốn trăm tin nhắn bằng các cuộc đối thoại mà ai đó có thể thực sự đọc. Điểm kiểm tra: mỗi lập luận tranh chấp đều có một chuỗi hoàn chỉnh; không có phản đối nào còn sống chỉ tồn tại trong trò chuyện.
6. 6Ghi lại kết quả. Khi cuộc bỏ phiếu ràng buộc trên chuỗi của DAO kết thúc — bằng bất kỳ cơ chế nào mà DAO sử dụng — kết quả được ghi lại trên cây bên cạnh cuộc thảo luận đã tạo ra nó, và bảng điều khiển giữ chủ đề như một hồ sơ vĩnh viễn, có thể liên kết. Câu hỏi một tháng sau — chúng ta nghĩ rằng mình đang phê duyệt điều gì, và ai đã xem xét nó? — giờ đây có một URL. Điểm kiểm tra: kết quả đã được ghi lại; cây được liên kết từ bất kỳ đâu mà DAO công bố kết quả.

Phần 2 — quy trình đề xuất tích hợp (l roadmap)

Luồng công việc ở trên bắt đầu một cách thủ công: ai đó mở chủ đề, ai đó dán cuộc thảo luận. Luồng đề xuất tích hợp lấp đầy khoảng trống đó — một đề xuất được đưa vào hệ thống tự động, và toàn bộ vòng đời diễn ra ở một nơi:

1. 1Nhập khẩu — một đề xuất mới được tự động tiếp nhận và trở thành một chủ đề quản trị.
2. 2Trích xuất — văn bản đề xuất được chuyển đổi thành cây lập luận, sẵn sàng cho việc xem xét của các thành viên.
3. 3Thảo luận — Chuỗi hỏi đáp thách thức vụ việc; Chuỗi thỏa hiệp thương lượng các sửa đổi giữa các phe.
4. 4Bỏ phiếu — đề xuất đã được thảo luận sẽ được đưa ra bỏ phiếu trong quy trình.
5. 5Đánh giá — một chuỗi Đánh giá kết thúc đánh giá kết quả và quy trình, cung cấp thông tin cho lần lặp tiếp theo của DAO.

Cơ sở hạ tầng cụ thể cho từng chuỗi là nơi mà việc kết nối theo DAO diễn ra: các trang quản trị Ethereum, Arbitrum, Cardano và Polkadot đề cập đến hình thức thảo luận có cấu trúc trong bối cảnh mô hình quản trị của từng hệ sinh thái.

Giới hạn trung thực

• ✗Phiếu bầu quyết định không có ở đây. Xếp hạng và phán quyết gốc là những tín hiệu thảo luận; quyết định mà di chuyển quỹ kho bạc là cơ chế trên chuỗi của chính DAO, và quy trình làm việc này không thay đổi điều đó.
• ✗Cấu trúc không tự mình khắc phục tình trạng tham gia. Một cây thông tin dễ đọc giảm chi phí tham gia có thông tin — một cử tri có thể tiếp thu vấn đề trong vài phút thay vì phải cuộn lại hàng giờ — nhưng nó không thể khiến những người nắm giữ token quan tâm. Hãy kết hợp nó với các động lực tham gia của chính DAO.
• ✗Động lực trọng số token sống bên ngoài cây. Đánh giá lập luận là theo từng thành viên; chúng không mô hình hóa sức mạnh theo trọng số coin, và việc một cá voi bỏ phiếu vượt trội hơn cuộc thảo luận trên chuỗi vẫn có thể xảy ra. Những gì mà hồ sơ thay đổi là nó diễn ra một cách rõ ràng, chống lại một trường hợp đã được ghi chép.
• ✗Phần 2 là lộ trình. Nhập khẩu tự động và bỏ phiếu tích hợp yêu cầu kết nối theo từng DAO, theo từng chuỗi theo yêu cầu — không lên kế hoạch ra mắt xung quanh việc chúng có thể tự phục vụ.
• ✗Thảo luận quy mô lớn có những chế độ thất bại riêng — chuỗi phản ứng, nhóm đông, phân cực. Kỷ luật độc lập (đánh giá trước khi đọc phân phối) là điều quan trọng ở đây như ở mọi nơi; xem khi đám đông sai lầm.

Bài học thực hành

• ✓Trích xuất, đừng tranh cãi lại. Nếu cuộc tranh luận đã diễn ra trong trò chuyện, hãy dán nó vào — việc trích xuất biến hàng giờ cuộn lại thành một cây có thể xem lại trong vài phút, và các tác giả của cuộc thảo luận thấy quan điểm của họ được thể hiện thay vì bị khởi động lại.
• ✓Đặt liên kết cây vào thông báo bỏ phiếu. Thói quen có ảnh hưởng lớn nhất: mỗi cuộc bỏ phiếu trên chuỗi đều liên kết với hồ sơ thảo luận của nó, vì vậy một cử tri chỉ cần một cú nhấp chuột để xem toàn bộ trường hợp. Lý lẽ mà không ai có thể tìm thấy là lý lẽ không tồn tại.
• ✓Chạy chuỗi Thỏa hiệp trước khi bỏ phiếu, không phải sau khi phân nhánh. Một sự chia rẽ rõ ràng ở bước đánh giá là tín hiệu — thương lượng sửa đổi trong khi đề xuất vẫn có thể thay đổi.
• ✓Giữ một chủ đề cho mỗi câu hỏi có thể quyết định. Các đề xuất tổng hợp tạo ra các cây tổng hợp mà không ai có thể đánh giá; hãy tách chúng ra, và để mỗi gốc mang phán quyết riêng của nó.

Câu hỏi một tháng sau, đã được trả lời

Chạy lại đề xuất ngân khố qua quy trình làm việc. Cuộc tranh luận rải rác đã được dán và trích xuất vào ngày đầu tiên; hai ý kiến phản đối của các thành viên là các nút có xếp hạng, không phải là thông điệp 214 và 380. Một ý kiến phản đối đã sống sót qua chuỗi Q&A với những người đề xuất và đã thúc đẩy một chuỗi Thỏa hiệp thêm một cổng mốc vào đề xuất trước khi nó được đưa lên chuỗi. Phán quyết gốc cho thấy một cộng đồng chia rẽ — rõ ràng, trước khi bỏ phiếu, tại một liên kết mà mọi cử tri đều thấy trong thông báo. Và khi câu hỏi về cột mốc xuất hiện một tháng sau đó, câu trả lời là một URL: đây là những gì chúng tôi đã phê duyệt, đây là ai đã xem xét nó, đây là rủi ro mà chúng tôi đã thấy và cổng mà chúng tôi đã thêm vào vì điều đó. Cuộc bỏ phiếu luôn ở trên chuỗi. Bây giờ lý do cũng ở đâu đó.