a16z: Cara Menghindari Serangan Tata Kelola DAO

Oleh Pranav Garimidi, Scott Duke Kominers, Tim Roughgarden

Sumber: a16z

Banyak proyek web3 menggunakan token asli yang sepadan dan dapat diperdagangkan untuk pemungutan suara tanpa izin. Pemungutan suara tanpa izin memiliki banyak manfaat, mulai dari hambatan masuk yang lebih rendah hingga persaingan yang meningkat. Pemegang token dapat menggunakan token mereka untuk memberikan suara pada berbagai masalah, mulai dari penyesuaian parameter sederhana hingga perombakan proses tata kelola itu sendiri. Namun, pemungutan suara tanpa izin rentan terhadap serangan tata kelola, di mana penyerang memperoleh hak pilih melalui cara legal (seperti membeli token di pasar terbuka) dan menggunakan hak pilih tersebut untuk memanipulasi protokol demi keuntungan penyerang sendiri. Serangan ini murni serangan "intra-protokol", artinya tidak dapat diselesaikan secara kriptografis. Sebaliknya, mencegah serangan ini membutuhkan desain mekanisme yang bijaksana. Untuk tujuan ini, kami merancang kerangka kerja untuk membantu DAO menilai ancaman dan merespons potensi serangan tata kelola.

Serangan terhadap Pemerintahan dalam Praktek

Masalah dengan serangan tata kelola bukan hanya teoretis. Hal itu tidak hanya dapat terjadi di dunia nyata, tetapi hal itu telah dan akan terus terjadi.

Mari kita lihat contoh nyata ini . Steemit adalah startup yang membangun jejaring sosial terdesentralisasi di blockchain Steem-nya, dengan sistem tata kelola on-chain yang dikendalikan oleh 20 saksi. Pemilih menggunakan token STEEM mereka (token asli platform) untuk memilih saksi. Ketika Steemit dan Steem menjadi semakin menarik, Justin Sun membuat rencana untuk menggabungkan Steem menjadi Tron. Tron adalah protokol blockchain yang ia dirikan pada tahun 2018. Untuk mendapatkan hak suara, Sun mendekati salah satu pendiri Steem dan membeli token setara dengan 30 persen dari total pasokan. Ketika saksi Steem menemukan transaksinya, mereka segera membekukan token Sun. Yang terjadi selanjutnya adalah bolak-balik publik antara Sun dan Steem untuk mendapatkan kendali atas token yang cukup untuk memungkinkan dirinya memilih 20 saksi teratas yang dia inginkan. Setelah mengambil bagian dalam kesepakatan besar dan menghabiskan ratusan ribu dolar untuk token, Justin Sun akhirnya muncul sebagai pemenang dan secara efektif memiliki kendali bebas atas jaringan.

Lihatlah contoh Pohon Kacang lagi. Beanstalk, protokol stablecoin, ternyata rentan terhadap serangan tata kelola Flashloan. Para penyerang mengambil pinjaman untuk mendapatkan token tata kelola Beanstalk yang cukup untuk segera mengeluarkan proposal jahat yang akan memungkinkan mereka untuk kehilangan cadangan Beanstalk sebesar $182 juta. Berbeda dengan serangan terhadap Steem, yang satu ini terjadi dalam skala satu blok, artinya sudah berakhir dan belum ada yang punya waktu untuk bereaksi.

Sementara kedua serangan ini terjadi secara terbuka dan di depan publik, serangan terhadap pemerintahan juga dapat dilakukan secara rahasia untuk waktu yang lama. Penyerang dapat membuat sejumlah besar akun anonim dan secara perlahan mengumpulkan token tata kelola sambil berperilaku normal seperti pemegang lainnya untuk menghindari pemberian. Faktanya, mengingat tingkat partisipasi pemilih yang sering rendah di banyak DAO, akun ini dapat tetap tidak aktif untuk jangka waktu yang lama tanpa menimbulkan kecurigaan. Dari perspektif DAO, akun anonim penyerang mungkin membantu menunjukkan tingkat kekuatan pemungutan suara terdesentralisasi yang sehat. Namun, penyerang pada akhirnya dapat mencapai ambang di mana dompet Sybil ini memiliki kekuatan untuk mengontrol tata kelola secara sepihak tanpa dapat ditanggapi oleh komunitas. Demikian pula, ketika jumlah pemilih cukup rendah, pelaku jahat dapat memperoleh kekuatan suara yang cukup untuk mengendalikan tata kelola dan kemudian mencoba untuk memberikan proposal jahat ketika banyak pemegang token lainnya tidak aktif.

Meskipun kita mungkin menganggap semua tindakan tata kelola hanya sebagai hasil dari kekuatan pasar yang bekerja, dalam praktiknya tata kelola terkadang dapat menghasilkan hasil yang tidak efisien karena kegagalan insentif atau celah lain dalam desain protokol. Sama seperti pembuatan kebijakan pemerintah yang dapat dipengaruhi oleh kelompok kepentingan atau kelambanan sederhana, tata kelola DAO dapat menyebabkan hasil yang buruk jika tidak terstruktur dengan baik.

Jadi, bagaimana kita menghadapi serangan semacam ini melalui desain mekanisme?

Tantangan Mendasar: Tidak dapat dibedakan

Mekanisme pasar untuk distribusi token gagal membedakan antara pengguna yang ingin memberikan kontribusi berharga untuk proyek dan penyerang yang ingin mengontrol proyek dengan mengganggu atau sebaliknya. Di dunia di mana token dapat dibeli dan dijual di pasar publik, tidak ada kelompok yang berperilaku tidak dapat dibedakan dari perspektif pasar: keduanya bersedia membeli token dalam jumlah besar dengan harga yang semakin tinggi.

Masalah ketidakterbedaan ini berarti bahwa tata kelola yang terdesentralisasi ada harganya. Alih-alih, perancang protokol perlu melakukan trade-off mendasar antara tata kelola desentralisasi terbuka dan melindungi sistem mereka dari serangan yang berupaya mengeksploitasi mekanisme tata kelola. Semakin banyak kebebasan yang dimiliki anggota komunitas untuk mendapatkan kekuatan tata kelola dan memengaruhi protokol, semakin mudah bagi penyerang untuk menggunakan mekanisme yang sama untuk membuat perubahan berbahaya.

Masalah ketidakterbedaan ini biasa terjadi dalam desain jaringan blockchain proof-of-stake. Selain itu, pasar token yang sangat likuid memudahkan penyerang mendapatkan saham yang cukup untuk membahayakan keamanan jaringan. Meskipun demikian, kombinasi insentif token dan desain likuiditas memungkinkan jaringan proof-of-stake. Strategi serupa dapat membantu mengamankan protokol DAO.

Kerangka Kerja untuk Menilai dan Mengatasi Kerentanan

Untuk menganalisis kerentanan yang dihadapi oleh berbagai proyek, kami menggunakan kerangka kerja yang diambil dengan rumus berikut:

Untuk memastikan bahwa protokol kebal terhadap serangan tata kelola, itu harus membuat keuntungan penyerang menjadi negatif. Saat merancang aturan tata kelola untuk suatu proyek, rumus ini dapat digunakan untuk memandu evaluasi dampak dari pilihan desain yang berbeda. Untuk mengurangi insentif untuk mengeksploitasi protokol, persamaan tersebut mengimplikasikan tiga pilihan yang jelas: mengurangi nilai serangan, meningkatkan biaya untuk mendapatkan hak suara, dan meningkatkan biaya untuk melakukan serangan.

Kurangi nilai serangan

Membatasi nilai serangan bisa jadi sulit karena semakin sukses proyeknya, semakin berharga serangannya. Jelas, sebuah proyek tidak boleh dengan sengaja menyabot kesuksesannya sendiri untuk mengurangi nilai serangan.

Meskipun demikian, desainer dapat membatasi nilai serangan dengan membatasi ruang lingkup tata kelola. Jika tata kelola hanya menyertakan kekuatan untuk mengubah parameter tertentu dalam proyek (misalnya, suku bunga perjanjian pinjaman), cakupan serangan potensial jauh lebih sempit daripada saat tata kelola memungkinkan kontrol penuh atas kontrak pintar.

Lingkup tata kelola dapat menjadi fungsi dari fase proyek. Pada masa awal, ketika sebuah proyek menemukan pijakannya, ia mungkin memiliki tata kelola yang lebih luas, tetapi dalam praktiknya, tata kelola dapat dikontrol dengan ketat oleh tim pendiri dan komunitas. Saat proyek matang dan kontrol terdesentralisasi, mungkin positif untuk memperkenalkan beberapa tingkat gesekan dalam tata kelola - setidaknya kuorum besar diperlukan untuk membuat keputusan yang paling penting.

Menaikkan biaya untuk memperoleh hak suara

Proyek juga dapat mengambil langkah-langkah untuk mempersulit penyerang mendapatkan hak suara yang diperlukan untuk serangan. Semakin likuid suatu token, semakin mudah untuk mengklaim hak suara - jadi hampir secara paradoks, proyek mungkin ingin mengurangi likuiditas untuk melindungi tata kelola. Kami dapat secara langsung mencoba mengurangi tradabilitas token jangka pendek, tetapi ini mungkin tidak layak secara teknis.

Untuk secara tidak langsung mengurangi likuiditas, proyek dapat memberikan insentif untuk membuat pemegang token individu cenderung tidak menjual token. Ini dapat dilakukan dengan memberi insentif pada staking atau dengan memberikan token nilai yang terlepas dari tata kelola murni. Semakin banyak nilai yang diterima pemegang token, semakin selaras mereka dengan keberhasilan proyek.

Manfaat token mandiri dapat mencakup partisipasi dalam acara tatap muka atau pengalaman sosial. Yang terpenting, manfaat seperti itu bernilai tinggi bagi individu yang selaras dengan proyek, tetapi tidak berguna bagi penyerang. Memberikan manfaat seperti itu meningkatkan harga efektif yang dihadapi penyerang dalam memperoleh token: pemegang saat ini kurang bersedia untuk menjual karena manfaat kemandirian meningkatkan harga pasar; namun, sementara penyerang harus membayar harga yang lebih tinggi, mandiri Keberadaan manfaat tidak meningkat nilai yang dapat diperoleh penyerang setelah mendapatkan token.

Meningkatkan biaya melakukan serangan

Selain menaikkan biaya hak pilih, gesekan dapat terjadi yang mempersulit penyerang untuk menggunakan hak pilih, bahkan jika mereka telah mendapatkan token. Misalnya, seorang desainer dapat meminta semacam autentikasi pengguna untuk memilih, seperti verifikasi KYC atau ambang skor reputasi. Bahkan dimungkinkan untuk membatasi kemampuan peserta yang tidak diautentikasi untuk mendapatkan token pemungutan suara sejak awal, mungkin mengharuskan beberapa validator yang ada untuk memverifikasi keabsahan peserta baru.

Dalam arti tertentu, ini persis berapa banyak proyek yang mendistribusikan token awal mereka, memastikan pihak tepercaya mengontrol sebagian besar kekuatan voting. (Banyak solusi proof-of-stake menggunakan teknik serupa untuk mengamankan diri mereka sendiri — dengan ketat mengontrol siapa yang mendapat saham awal, dan secara bertahap terdesentralisasi dari sana.)

Alternatifnya, proyek dapat melakukannya sehingga meskipun penyerang mengontrol sejumlah besar hak suara, mereka masih menghadapi kesulitan dalam menyampaikan proposal jahat. Misalnya, beberapa proyek memiliki timelock, sehingga token tidak dapat digunakan untuk pemungutan suara selama jangka waktu tertentu setelah penukaran. Akibatnya, penyerang yang mencoba membeli atau meminjam token dalam jumlah besar menghadapi biaya tambahan menunggu untuk memilih — dan risiko potensi serangan mereka diketahui dan diblokir oleh anggota pemungutan suara untuk sementara waktu. Delegasi juga dapat membantu dalam hal ini. Dengan memberikan hak suara kepada peserta yang aktif tetapi tidak jahat, individu yang tidak ingin berperan aktif dalam pemerintahan masih dapat menggunakan suaranya untuk melindungi sistem.

Beberapa proyek menggunakan veto, memungkinkan pemungutan suara ditunda untuk jangka waktu tertentu untuk memperingatkan pemilih yang tidak aktif terhadap proposal yang berpotensi berbahaya. Menurut skema ini, meskipun penyerang membuat proposal jahat, pemilih memiliki kemampuan untuk merespons dan menutupnya. Gagasan di balik desain ini dan yang serupa adalah untuk mencegah penyerang menyelinap melalui proposal jahat dan memberikan waktu kepada komunitas proyek untuk merespons. Dalam dunia yang ideal, proposal yang jelas untuk kepentingan kesepakatan tidak harus menghadapi rintangan ini.

Misalnya, dalam DAO Kata Benda, hak veto berada di tangan Yayasan Kata Benda sampai DAO itu sendiri siap menerapkan model tata kelola alternatif. Seperti yang mereka tulis di situs web mereka, "The Nouns Foundation akan memveto proposal yang menimbulkan risiko hukum atau eksistensial yang signifikan terhadap DAO Nouns atau Yayasan Nouns."

Proyek harus mencapai keseimbangan yang memungkinkan tingkat keterbukaan (yang terkadang tidak diinginkan) terhadap perubahan komunitas, sementara tidak membiarkan celah proposal yang berbahaya. Biasanya hanya dibutuhkan proposal jahat untuk membatalkan protokol, jadi sangat penting untuk memiliki pemahaman yang jelas tentang risiko pengorbanan menerima dan menolak proposal. Tentu saja, ada trade-off yang tinggi antara mengamankan tata kelola dan memungkinkan tata kelola - mekanisme apa pun yang menimbulkan gesekan untuk mencegah penyerang potensial tentu saja juga akan membuat proses tata kelola menjadi lebih menantang.

Solusi yang kami uraikan di sini adalah antara tata kelola yang sepenuhnya terdesentralisasi dan mengorbankan sebagian desentralisasi yang diinginkan untuk kesehatan protokol secara keseluruhan. Kerangka kerja kami menyoroti jalur berbeda yang dapat diambil proyek, mencoba memastikan bahwa serangan tata kelola tidak menguntungkan. Kami berharap komunitas akan mulai menggunakan kerangka kerja ini dan mengembangkan lebih lanjut mekanisme ini melalui eksperimen mereka sendiri untuk membuat DAO lebih aman di masa mendatang.