Penelitian terbaru Vitalik: Bagaimana protokol LSDFi dan likuiditas perlu berubah untuk meningkatkan desentralisasi dan mengurangi beban konsensus?

Artikel ini akan berfokus pada dua masalah utama yang saat ini dihadapi oleh protokol LSDFi dan pool likuiditas, yaitu risiko sentralisasi operator node dan beban konsensus yang tidak perlu.

Penulis:Vitalik Buterin

Penerjemah: bayemon.eth, ChainCatcher

Perkembangan Ethereum saat ini dapat dikatakan melibatkan banyak staking dua tingkat (two-tiered staking), di mana staking dua tingkat ini mengacu pada model staking dengan dua jenis partisipan.

• Operator Node: Mengoperasikan node dan menjaminkan sejumlah modal sendiri dengan reputasinya sebagai jaminan
• Delegator: Delegator melakukan staking sejumlah Ethereum tanpa batas minimum, dan tidak ada batasan tambahan pada bentuk partisipasi selain jaminan

Staking dua tingkat yang baru ini muncul melalui banyaknya partisipasi dalam pool staking yang menyediakan token staking likuid (LST). (Rocket Pool dan Lido adalah contoh model ini).

Namun, staking dua tingkat saat ini memiliki dua kekurangan:

• Risiko sentralisasi operator node: Mekanisme pemilihan operator node di semua pool staking saat ini masih terlalu terpusat
• Beban konsensus yang tidak perlu: Ethereum L1 harus memverifikasi sekitar 800.000 tanda tangan setiap Epoch, yang merupakan beban besar untuk satu slot. Selain itu, karena pool staking likuid memerlukan dana yang besar, namun jaringan itu sendiri tidak mendapatkan manfaat penuh dari beban ini. Oleh karena itu, jika jaringan Ethereum dapat mencapai desentralisasi dan keamanan yang wajar tanpa memerlukan setiap staker untuk menandatangani setiap slot, maka komunitas dapat mengadopsi solusi seperti ini untuk secara efektif mengurangi jumlah tanda tangan per slot.

Artikel ini akan mendeskripsikan solusi untuk dua masalah di atas, dengan asumsi bahwa sebagian besar modal dikuasai oleh mereka yang tidak ingin secara langsung mengelola node staking dalam bentuk saat ini, menandatangani informasi pada setiap slot, mengunci deposit dan mendistribusikan kembali dana kepada mereka yang terkena pemotongan, lalu dalam situasi seperti ini, peran apa yang masih dapat dimainkan oleh mereka sehingga tetap memberikan kontribusi bermakna bagi desentralisasi dan keamanan jaringan?

Bagaimana staking dua tingkat saat ini bekerja?

Saat ini, dua pool staking paling populer adalah Lido dan RocketPool. Untuk Lido, dua pihak yang terlibat adalah:

• Operator Node: Dipilih melalui voting oleh Lido DAO, yang berarti sebenarnya dipilih oleh pemegang LDO. Ketika seseorang menyetor ETH ke sistem smart contract Lido, stETH akan dibuat, dan operator node dapat menggunakannya untuk staking (namun karena kredensial penarikan terikat dengan alamat smart contract, operator tidak dapat menarik secara sembarangan)
• Delegator: Ketika seseorang menyetor ETH ke sistem smart contract Lido, stETH akan dihasilkan, operator node dapat menggunakannya untuk staking (namun karena kredensial penarikan terikat dengan alamat smart contract, operator tidak dapat menarik secara sembarangan)

Untuk Rocket Pool, pembagiannya adalah:

• Operator Node: Siapa pun dapat menjadi operator node, hanya perlu menyetor 8 ETH dan sejumlah token RPL.
• Delegator: Ketika seseorang menyetor ETH ke sistem smart contract Rocket Pool, rETH akan dihasilkan, operator node dapat menggunakannya untuk staking (juga karena kredensial penarikan terikat dengan alamat smart contract, operator tidak dapat menarik secara sembarangan).

Peran Delegator

Dalam sistem ini (atau sistem baru yang diaktifkan oleh perubahan protokol potensial di masa depan), pertanyaan kunci yang perlu diajukan adalah: Dari sudut pandang protokol, apa arti dari adanya delegator?

Untuk memahami makna mendalam dari pertanyaan ini, pertama-tama kita pikirkan, untuk perubahan protokol yang disebutkan dalam artikel ini, yaitu membatasi penalti pemotongan menjadi 2ETH, Rocket Pool juga akan menurunkan jumlah staking operator node menjadi 2ETH, dan pangsa pasar Rocket Pool akan meningkat menjadi 100%/(bagi staker dan pemegang ETH, seiring rETH menjadi tanpa risiko, hampir semua pemegang ETH akan menjadi pemegang rETH atau operator node).

Misalkan tingkat pengembalian pemegang rETH adalah 3% (termasuk reward dalam protokol dan biaya prioritas + MEV), tingkat pengembalian operator node adalah 4%. Kita juga asumsikan total suplai ETH adalah 100 juta.

Hasil perhitungannya sebagai berikut. Untuk menghindari perhitungan bunga majemuk, kita hitung pengembalian per hari:

Sekarang, misalkan Rocket Pool tidak ada, maka deposit minimum setiap staker turun menjadi 2 ETH, total likuiditas maksimum adalah 6,25 juta ETH, sementara tingkat pengembalian operator node turun menjadi 1%. Mari kita hitung lagi:

Dari sudut pandang biaya serangan, mari kita bandingkan kedua situasi ini. Dalam kasus pertama, penyerang tidak akan mendaftar sebagai delegator, karena delegator pada dasarnya tidak memiliki hak penarikan, jadi tidak ada gunanya. Oleh karena itu, mereka akan menggunakan semua ETH mereka untuk staking dan menjadi operator node. Untuk mencapai 1/3 dari total staking, mereka perlu menyetor 2,08 juta Ethereum (secara adil, ini masih angka yang cukup besar). Dalam kasus kedua, penyerang hanya perlu menyetor dana, untuk mencapai 1/3 dari total pool staking, mereka tetap perlu menyetor 2,08 juta Ethereum.

Dari sudut pandang ekonomi staking dan biaya serangan, hasil akhir kedua situasi sama persis. Pangsa suplai ETH yang dimiliki operator node meningkat 0,00256% per hari, sementara pangsa suplai ETH yang dimiliki non-operator node menurun 0,00017% per hari. Biaya serangan adalah 2,08 juta ETH. Oleh karena itu, dalam model ini, delegator tampaknya menjadi mesin Rube Goldberg yang tidak berarti, komunitas rasional bahkan cenderung menghilangkan perantara, secara drastis mengurangi reward staking, dan membatasi total ETH yang di-stake pada 6,25 juta.

Tentu saja, artikel ini tidak menyarankan untuk mengurangi reward staking 4 kali lipat, sekaligus membatasi total staking pada 6,25 juta. Sebaliknya, pendapat artikel ini adalah bahwa sistem staking yang berfungsi dengan baik seharusnya memiliki satu atribut kunci, yaitu delegator harus memikul tanggung jawab penting dalam seluruh sistem. Selain itu, jika delegator sebagian besar didorong oleh tekanan komunitas dan altruism untuk bertindak benar, itu juga tidak masalah; bagaimanapun, inilah kekuatan utama yang mendorong solusi staking yang terdesentralisasi dan sangat aman saat ini.

Tanggung Jawab Delegator

Jika delegator dapat memainkan peran bermakna dalam sistem staking, maka peran seperti apa yang mungkin mereka mainkan?

Saya pikir ada dua jenis jawaban:

• Pilihan delegator: Delegator dapat memilih untuk mendelegasikan kepentingannya kepada operator node mana. Bobot operator node dalam mekanisme konsensus sebanding dengan total staking yang didelegasikan kepada mereka. Saat ini, mekanisme pemilihan delegator masih terbatas, yaitu pemegang rETH atau stETH dapat menarik ETH mereka dan beralih ke pool lain, tetapi ketersediaan nyata dari pilihan delegator dapat sangat ditingkatkan.
• Partisipasi dalam mekanisme konsensus: Delegator dapat memilih untuk memainkan peran tertentu dalam mekanisme konsensus, dengan tanggung jawab yang lebih ringan daripada menjadi validator penuh, tidak ada periode keluar yang panjang dan risiko pemotongan, tetapi tetap dapat menjadi penyeimbang bagi operator node.

Meningkatkan Hak Pilih Delegator

Ada tiga cara untuk meningkatkan kekuatan pilihan delegator:

• Meningkatkan alat voting dalam pool
• Menambah kompetisi antar pool
• Menetapkan hak delegasi secara permanen

Saat ini, voting dalam pool pada dasarnya tidak praktis: di Rocket Pool, siapa pun dapat menjadi operator node, di Lido, voting diputuskan oleh pemegang LDO, bukan pemegang ETH. Lido mengajukan proposal tentang tata kelola ganda LDO + stETH, mereka dapat mengaktifkan mekanisme perlindungan untuk menghentikan voting baru, sehingga mencegah operator node ditambah atau dihapus, ini sedikit memberi pemegang stETH suara. Meski begitu, kekuatan ini masih terbatas dan bisa lebih kuat.

Kompetisi antar pool sudah ada hari ini, tetapi masih relatif lemah. Tantangan utamanya adalah token staking dari pool kecil memiliki likuiditas rendah, sulit mendapatkan kepercayaan, dan kurang didukung oleh aplikasi.

Kita dapat memperbaiki dua masalah pertama dengan membatasi jumlah penalti pada angka kecil, misalnya 2 atau 4 ETH. Kemudian, sisa ETH dapat disimpan dan ditarik dengan aman secara instan, sehingga pertukaran dua arah tetap berlaku untuk pool staking kecil. Kita dapat memperbaiki masalah ketiga dengan membuat kontrak penerbitan total, yaitu untuk mengelola LST (mirip dengan ERC-4337 dan ERC-6900 untuk dompet), sehingga kita dapat memastikan bahwa setiap token staking yang diterbitkan melalui kontrak ini aman.

Saat ini, belum ada kekuatan delegasi permanen dalam protokol, tetapi situasi seperti ini tampaknya juga mungkin ada di masa depan. Ini akan melibatkan logika serupa dengan ide-ide di atas, tetapi diimplementasikan di tingkat protokol. Untuk kelebihan dan kekurangan permanensi, silakan lihat artikel ini.

Ide-ide ini semua merupakan perbaikan dari status quo, tetapi keunggulan yang dapat mereka tawarkan terbatas. Tata kelola voting token memiliki masalah, pada akhirnya segala bentuk pilihan delegator non-incentive hanyalah bentuk voting token; ini selalu menjadi keluhan utama saya terhadap delegated proof of stake. Oleh karena itu, mempertimbangkan implementasi partisipasi konsensus yang lebih kuat juga berharga.

Partisipasi Konsensus

Bahkan tanpa mempertimbangkan masalah staking likuid saat ini, metode staking independen saat ini juga memiliki keterbatasan. Misalkan menggunakan single-slot finality, dalam kondisi ideal setiap slot mungkin memproses sekitar 100.000 hingga 1.000.000 tanda tangan BLS. Bahkan jika kita menggunakan recursive SNARKs untuk mengagregasi tanda tangan, demi keterlacakan tanda tangan, setiap tanda tangan perlu diberikan bitfield partisipan. Jika Ethereum menjadi jaringan berskala global, maka penyimpanan bitfield yang sepenuhnya terdesentralisasi juga tidak cukup: 16 MB per slot hanya dapat mendukung sekitar 64 juta staker.

Dari sudut pandang ini, membagi staking menjadi lapisan yang lebih kompleks dan dapat dipotong serta lapisan yang kurang kompleks adalah berharga, lapisan kompleks berlaku pada setiap slot, tetapi mungkin hanya ada 10.000 partisipan, sedangkan lapisan kurang kompleks hanya dipanggil sesekali untuk berpartisipasi. Lapisan kurang kompleks dapat sepenuhnya bebas dari pemotongan, atau dapat secara acak memberikan kesempatan kepada partisipan untuk menyetor dan menjadi objek pemotongan dalam beberapa slot.

Pada kenyataannya, ini dapat dilakukan dengan meningkatkan batas saldo validator, kemudian meningkatkan ambang saldo (misalnya, 2048 ETH) untuk menentukan validator mana yang masuk ke lapisan kompleks atau kurang kompleks.

Berikut adalah beberapa saran tentang bagaimana peran staking kecil ini dapat berfungsi:

• Pada setiap slot, 10.000 staker kecil dipilih secara acak, mereka dapat menandatangani apa yang mereka anggap sebagai isi slot tersebut. Gunakan staker kecil sebagai input untuk menjalankan aturan pemilihan fork LMD GHOST. Jika terdapat perbedaan antara pemilihan fork yang didorong oleh staker kecil dan operator node, klien pengguna tidak akan menerima blok apa pun sebagai final dan akan menampilkan kesalahan. Ini memaksa komunitas untuk turun tangan menyelesaikan situasi.
• Delegator dapat mengirim transaksi untuk mengumumkan ke jaringan bahwa mereka online dan bersedia menjadi staker kecil dalam satu jam ke depan. Pesan yang dikirim node (blok atau bukti) perlu ditandatangani oleh node dan satu delegator yang dipilih secara acak untuk mengonfirmasi node tersebut.
• Delegator dapat mengirim transaksi untuk mengumumkan ke jaringan bahwa mereka online dan bersedia menjadi staker kecil dalam satu jam ke depan. Setiap periode, 10 delegator acak dipilih sebagai inclusion list provider, dan 10.000 delegator lagi dipilih sebagai pemilih. Ini dipilih sebelum k-slot, dan diberikan jendela k slot untuk mengirim pesan konfirmasi online di chain. Setiap inclusion list provider yang terpilih dan dikonfirmasi dapat mempublikasikan inclusion list, kecuali untuk setiap inclusion list, baik inclusion list tersebut dimasukkan transaksinya, atau terdapat voting dari pemilih yang menunjukkan inclusion list tidak tersedia, jika tidak, blok dianggap tidak valid.

Node staking kecil ini memiliki kesamaan: mereka tidak perlu berpartisipasi aktif di setiap slot, bahkan hanya perlu light node untuk melakukan semua pekerjaan. Oleh karena itu, deployment node hanya perlu memverifikasi layer konsensus, operator node dapat menggunakan aplikasi atau plugin browser, yang sebagian besar pasif, dengan kebutuhan komputasi, perangkat keras, atau keahlian teknis yang sangat rendah, bahkan tidak memerlukan teknologi canggih seperti ZK-EVM.

Peran "kecil" ini juga memiliki tujuan bersama: mencegah 51% mayoritas operator node melakukan sensor transaksi. Cara pertama dan kedua juga dapat mencegah mayoritas melakukan reorg finalitas. Cara ketiga lebih langsung berfokus pada sensor, tetapi lebih mudah dipengaruhi oleh mayoritas pilihan operator node.

Ide-ide ini ditulis dari sudut pandang implementasi solusi staking dua tingkat dalam protokol, tetapi juga dapat diimplementasikan sebagai fitur pool staking. Berikut beberapa ide implementasi konkret:

1. Dari sudut pandang protokol, setiap validator dapat mengatur dua kunci staking: satu kunci staking permanen P, serta alamat Ethereum yang dapat dipanggil dan mengeluarkan kunci staking cepat Q. Node melacak informasi penandatanganan pemilihan fork menggunakan P, dan informasi penandatanganan menggunakan Q. Jika hasil penyimpanan PQ tidak konsisten, maka tidak ada blok yang diterima sebagai final, dan pool likuiditas bertanggung jawab memilih delegator secara acak.
2. Protokol secara umum dapat tetap sama, tetapi public key validator pada periode tersebut akan diatur sebagai P+Q. Perhatikan bahwa untuk pemotongan, dua pesan yang dapat dipotong mungkin memiliki kunci Q yang berbeda, tetapi akan memiliki kunci P yang sama; desain pemotongan perlu menangani situasi ini.
3. Kunci Q hanya dapat digunakan dalam protokol untuk menandatangani dan memverifikasi inclusion list dalam blok. Dalam kasus ini, Q dapat berupa smart contract, bukan satu kunci saja, sehingga pool staking dapat menggunakannya untuk menerapkan logika voting yang lebih kompleks, menerima inclusion list dari provider terpilih secara acak atau cukup banyak voting yang menyatakan inclusion list tidak tersedia.

Kesimpulan

Jika diterapkan dengan benar, penyesuaian desain proof of stake dapat menyelesaikan dua masalah sekaligus:

• Memberikan kesempatan kepada mereka yang saat ini tidak memiliki sumber daya atau kemampuan untuk melakukan proof of stake independen, sehingga mereka dapat berpartisipasi dalam proof of stake dan mempertahankan lebih banyak kekuatan di tangan mereka: termasuk (i) kekuatan memilih node mana yang didukung dan (ii) berpartisipasi aktif dalam konsensus dengan cara yang lebih ringan namun tetap bermakna dibandingkan menjalankan node proof of stake penuh. Tidak semua partisipan akan memilih satu atau dua opsi ini, tetapi siapa pun yang memilih salah satu atau keduanya akan mengalami peningkatan signifikan dibandingkan status quo.
• Mengurangi jumlah tanda tangan yang perlu diproses oleh layer konsensus Ethereum di setiap slot, bahkan dalam sistem single slot finality, menguranginya menjadi sekitar 10.000 tanda tangan saja. Ini juga akan membantu desentralisasi, membuat setiap orang lebih mudah menjalankan node validator.

Untuk solusi ini, dapat ditemukan cara menyelesaikan masalah pada berbagai tingkat abstraksi: hak yang diberikan kepada pengguna dalam protokol proof of stake, pilihan pengguna antar protokol proof of stake, serta pengaturan dalam protokol. Pilihan ini harus dipertimbangkan dengan hati-hati, dan biasanya lebih baik memilih pengaturan minimum yang layak, untuk meminimalkan kompleksitas protokol dan perubahan pada ekonomi protokol, sambil tetap mencapai tujuan yang diinginkan.

Terima kasih khusus kepada Mike Neuder, Justin Drake, dan lainnya atas masukan dan peninjauannya. Lihat juga: artikel sebelumnya oleh Mike Neuder, Dankrad Feist, dan arixon.eth tentang topik serupa.