On-Chain Governance: The Tech Stack Explained

Governance ได้รับการพูดถึงราวกับว่าเป็นกระบวนการทางการเมือง แต่กลไกที่อยู่เบื้องหลังนั้นเป็นวิศวกรรมซอฟต์แวร์แท้: smart contracts การนับ token และกฎ consensus ที่ตัดสินว่าใครได้เปลี่ยนแปลงระบบและวิธีการอย่างไร หากคุณกำลังประเมิน DAO หรือเส้นทางการอัปเกรด protocol การเข้าใจ tech stack มีความสำคัญมากกว่าการอ่านประกาศเจตนา

The core components

ระบบ governance บน on-chain ส่วนใหญ่สร้างจากชุดส่วนประกอบขนาดเล็ก:

• Voting contracts — ติดตามข้อเสนอ นับคะแนนเสียง และบังคับใช้เกณฑ์ quorum
• Token or reputation weighting — กำหนดว่าคะแนนเสียงของ address ที่กำหนดนั้นนับได้เท่าไร (token-weighted quadratic หรือ delegated)
• Timelock contracts — หน่วงเวลาการดำเนินการของข้อเสนอที่ผ่านมา โดยปกติ 24-72 ชั่วโมง เพื่อให้ผู้ใช้สามารถตอบสนองก่อนที่การเปลี่ยนแปลงจะเกิดขึ้น
• Execution modules — เส้นทางโค้ดที่เรียกใช้ contract ที่ได้รับผลกระทบจริง ๆ เมื่อการลงคะแนนเสียงผ่าน

Compound's Governor Bravo และ OpenZeppelin's Governor contracts เป็นการนำไปใช้อ้างอิงที่โปรเจกต์ใหม่ส่วนใหญ่แยกสาขา (fork) หรือขยาย หากคุณอ่าน codebase หนึ่งเพื่อเข้าใจแพทเทิร์น ให้อ่าน Governor.sol จาก OpenZeppelin — มีความเห็นชอบดีและแสดงวงจรข้อเสนอทั้งหมด: propose vote queue execute

How a proposal actually moves through the system

ข้อเสนอไม่ใช่แค่โพสต์บนฟอรัมที่ได้รับการลงคะแนนเสียงอย่างไม่เป็นทางการ บน on-chain มันคือ calldata: ที่อยู่ contract เป้าหมาย selector ของฟังก์ชัน และพารามิเตอร์ที่เข้ารหัส เมื่อใครบางคนส่งข้อเสนอ governance พวกเขาส่งธุรกรรมที่แน่นอนที่จะทำงานหากการลงคะแนนเสียงผ่าน

การไหลนั้นมักจะมีลักษณะดังนี้:

1. Proposer ส่ง calldata พร้อมคำอธิบาย มักต้องมี token balance ขั้นต่ำเพื่อป้องกัน spam
2. Voting delay (โดยทั่วไป 1 block ถึงสองสามวัน) ให้เวลาผู้ถือ token เพื่อทบทวนก่อนที่การลงคะแนนเสียงเปิด
3. Voting period ทำงาน (Compound ใช้ประมาณ 3 วันตามค่าเริ่มต้น แม้ว่า forks หลายตัวกำหนดค่าหน้าต่างที่ยาวขึ้น)
4. หากตรงตามเกณฑ์ quorum และ approval thresholds ข้อเสนอจะเข้า timelock
5. หลังจาก timelock delay หมดลง ใครก็ได้สามารถเรียก execute เพื่อรันธุรกรรม

ช่องว่างระหว่างการปิดการลงคะแนนเสียงและการดำเนินการคือ security backstop นั่นคือหน้าต่างที่ชุมชนสามารถสังเกตเห็นข้อเสนอที่เป็นอันตรายหรือมีข้อบกพร่องได้ และในกรณีสุดขั้ว ประสานงานการตอบสนองฉุกเฉินได้ — สมมติว่า protocol มี emergency guardian role หรือ multisig override ซึ่งหลายตัวมีในช่วง governance ในช่วงเริ่มต้น

Where the weighting logic gets complicated

การลงคะแนนเสียงแบบ token-weighted อย่างง่ายมีปัญหาที่รู้จัก: ใครก็ตามที่ถืออ้ยฮื่อ token ส่วนใหญ่ควบคุมผลลัพธ์ และการลงคะแนนเสียงของผู้ลงคะแนนมักจะต่ำ ฟอรัม governance บางแห่งรายงานการหันเหในเปอร์เซ็นต์ตัวเลขเดี่ยวของอุปทานหมุนเวียนสำหรับข้อเสนอประจำ

โปรเจกต์ได้พยายามแก้ไขหลายประการ:

• Delegation — token holders มอบอำนาจการลงคะแนนเสียงให้ delegate โดยไม่โอนย้าย token ซึ่งเป็นวิธีที่ Compound และ Uniswap จัดการการลงคะแนนเสียงแบบเป็นตัวแทน
• Quadratic voting — ค่าใช้จ่ายของคะแนนเสียงเพิ่มเติมเพิ่มขึ้นอย่างกำลังสอง เพื่อลดความเหนือกว่าของวาฬ แม้ว่า Sybil resistance (คนหนึ่งสร้างที่อยู่หลายแห่ง) ยังคงเป็นปัญหาเปิด
• Conviction voting — ใช้โดย Gitcoin-adjacent tooling บางตัว โดยที่อำนาจการลงคะแนนเสียงสะสมยิ่งนานเท่าใด token ยังคงตั้งมั่นอยู่กับตำแหน่งนั้น โดยโปรดปรานความต้องการที่ยั่งยืนมากกว่า snapshot votes

ไม่มีตัวใดเหล่านี้ที่แก้ปัญหา low-turnout dynamics ของ token voting ที่เอื้อต่อ plutocracy ได้อย่างสมบูรณ์ พวกเขาเป็นการบรรเทา ไม่ใช่การแก้ไข และการที่ glossary entry ใด ๆ อ้างว่าตรงกันข้ามนั้นเป็นการเสนอราคาเกินขีดสำหรับเทคโนโลยี

Off-chain signaling versus on-chain execution

หลายสิ่งที่เรียกว่า