Imbal hasil staking Ethereum telah menyempit sedemikian rupa sehingga desain kustodi menjadi pembeda yang lebih praktis daripada selisih imbal hasil kecil yang diiklankan. Dengan imbalan dasar protokol berada di sekitar 2,6%, pertanyaan bagi pemegang ETH kini semakin mengarah pada apakah pengaturan staking dapat mempertahankan kemampuan mereka untuk memulihkan pokok dan imbalan jika operator validator menghilang, gagal, atau menolak bekerja sama.
Arsitektur validator Ethereum memisahkan masalah tersebut menjadi dua izin kriptografis: kunci penandatanganan yang digunakan untuk mengoperasikan validator, dan kredensial penarikan yang mengatur ke mana ETH yang di-staking dapat dibayarkan. Pemisahan ini memungkinkan penyedia khusus menjalankan infrastruktur validator tanpa secara otomatis memperoleh wewenang atas ETH yang disetorkan ke dalam protokol.
Perbedaan ini menjadi semakin penting seiring meningkatnya partisipasi staking. Semakin banyak ETH yang dikomitmenkan untuk staking umumnya membagi imbalan protokol di antara lebih banyak validator, sehingga mengurangi imbal hasil dasar yang tersedia untuk setiap unit staking. Dengan demikian, imbal hasil yang dikutip lebih tinggi dapat mencerminkan risiko tambahan, biaya, leverage, insentif token, atau model kustodi yang berbeda, bukan versi imbal hasil staking bawaan Ethereum yang lebih unggul.
Kredensial penarikan menentukan siapa yang dapat memulihkan ETH
Kunci penandatanganan validator harus tetap tersedia secara daring. Kunci ini menandatangani atestasi dan, ketika terpilih, usulan blok. Jika validator luring, validator tersebut dapat kehilangan imbalan dan dikenai penalti tidak aktif; jika melakukan pelanggaran protokol tertentu, validator tersebut dapat dikenai slashing.
Kunci penandatanganan tidak dapat menarik setoran validator sebesar 32 ETH atau imbalan yang telah terkumpul. Wewenang tersebut berada pada kredensial penarikan, yang ditetapkan saat validator dibuat dan dicatat di beacon chain Ethereum.
Dalam pengaturan staking non-kustodial, pemegang ETH mempertahankan kredensial tersebut, biasanya di dompet yang dikendalikan secara luring atau dalam sistem manajemen kunci. Penyedia layanan node menerima kunci penandatanganan dan mengoperasikan validator atas nama pemegangnya. Penyedia tersebut dapat memengaruhi kinerja melalui waktu aktif, pemeliharaan perangkat lunak, dan keamanan operasional, tetapi tidak dapat mengalihkan saldo validator ke dompetnya sendiri.
Struktur ini tidak menghilangkan semua risiko. Validator yang dikelola dengan buruk dapat berkinerja di bawah ekspektasi, dan peristiwa yang dapat dikenai slashing dapat mengurangi saldo validator. Namun, struktur ini membatasi kendali penyedia atas sisa stake. Perbedaan ini sangat relevan bagi pengguna yang membandingkan layanan yang menyebut dirinya “non-kustodial”, karena label tersebut hanya memiliki nilai praktis ketika pelanggan—bukan penyedia—memegang wewenang penarikan.
EIP-7002 menambahkan jalur keluar dari execution layer
EIP-7002 Ethereum telah mengurangi ketergantungan operasional lain bagi validator yang menggunakan kredensial penarikan dari execution layer. Peningkatan ini memungkinkan pemegang kredensial penarikan 0x01 atau 0x02 memicu keluarnya validator melalui execution layer, alih-alih hanya mengandalkan operator validator untuk mengirimkan pesan keluar.
Mekanisme tersebut memberi pemegang kredensial jalur langsung untuk mulai meninggalkan kumpulan validator jika penyedia layanan mereka tidak dapat diakses. Mekanisme ini tidak membuat ETH langsung likuid. Validator tetap tunduk pada antrean keluar Ethereum, aturan pemrosesan penarikan, dan batas jaringan mengenai seberapa cepat validator dapat keluar.
Perubahan ini menempatkan kendali atas keputusan keluar lebih dekat kepada pihak yang mengendalikan penarikan. Operator mungkin tetap diperlukan agar validator bekerja secara efisien selama masih aktif, tetapi peran operator menjadi kurang sentral ketika pemegang memutuskan untuk berhenti melakukan staking.
Pengguna juga harus membedakan antara keluar dan penarikan. Keluar menghapus validator dari tugas aktifnya. ETH baru dapat ditarik setelah validator melewati proses protokol yang berlaku dan penarikan diproses ke alamat yang ditentukan dalam kredensialnya.
Pectra memperluas opsi validator compounding
Peningkatan Pectra Ethereum memperkenalkan format validator compounding 0x02, yang memungkinkan saldo efektif validator meningkat melampaui batas tradisional 32 ETH, hingga 2.048 ETH. Dalam model lama, reward di atas 32 ETH umumnya dikirim ke alamat penarikan, alih-alih tetap berada dalam saldo aktif validator.
Validator compounding dapat mempertahankan reward dalam saldo validator, sehingga operator atau pemegang dapat mengonsolidasikan stake yang jika tidak demikian akan tersebar di banyak validator 32 ETH. Hal ini dapat mengurangi beban operasional terkait pengelolaan instans validator terpisah, termasuk koordinasi infrastruktur dan administrasi kunci.
Batas saldo yang lebih besar tidak menghapus batasan protokol Ethereum. Aktivasi, keluar, penalti, penarikan sebagian, dan penarikan akhir tetap diatur oleh aturan konsensus. Validator yang lebih besar juga memusatkan lebih banyak ETH dalam satu pengaturan operasional, sehingga keandalan teknis penyedia dan keamanan kredensial pemilik menjadi lebih penting.
Pemilik validator yang sudah ada dan mempertimbangkan konversi harus berfokus pada kompromi praktis: apakah penggabungan imbal hasil sesuai dengan kebutuhan likuiditas mereka, apakah kredensial penarikan berada di bawah kendali mereka sendiri, dan apakah operator mereka dapat mendukung format validator terkait dengan aman.
Liquid staking mengikuti model kendali yang berbeda
Liquid staking menawarkan kompromi yang berbeda. Alih-alih mengoperasikan validator yang terhubung langsung ke kredensial penarikan satu pengguna, protokol liquid staking mengumpulkan ETH dan menerbitkan token tanda terima yang dapat ditransfer, seperti stETH. Token tersebut dapat ditransfer, diperdagangkan, atau digunakan dalam keuangan terdesentralisasi, sementara ETH yang mendasarinya tetap dialokasikan ke berbagai validator yang dioperasikan dalam sistem protokol.
Fleksibilitas ini hadir dengan jalur kendali yang berbeda. Kredensial penarikan untuk validator yang dikumpulkan umumnya dikendalikan pada tingkat protokol, bukan oleh setiap pemegang token tanda terima secara individual. Klaim pengguna direpresentasikan oleh token likuid dan proses penebusan protokol, bukan melalui kepemilikan langsung atas kredensial penarikan validator tertentu.
Dalam model stETH yang dijelaskan dalam materi yang disediakan, permintaan penebusan masuk ke antrean penarikan dan menghasilkan NFT yang mewakili klaim pengguna hingga ETH tersedia untuk diambil. Proses ini dapat mempertahankan pasar likuid untuk eksposur staking, tetapi memperkenalkan pertimbangan terkait tata kelola protokol, smart contract, antrean, dan pasar token yang tidak berlaku dengan cara yang sama pada validator native yang dikendalikan secara langsung.
Staking non-kustodial bergaya native memerlukan setidaknya 32 ETH per validator, atau akses ke pengaturan yang dibangun berdasarkan persyaratan tersebut, serta menawarkan likuiditas harian yang lebih rendah. Daya tariknya terletak pada pemisahan yang lebih jelas antara operasi yang dialihdayakan dan kepemilikan: penyedia dapat menjalankan infrastrukturnya, sementara pemilik ETH tetap memegang kredensial yang menentukan ke mana dana tersebut pada akhirnya dikirim.
Ingin mendapatkan imbal hasil sambil tetap mengendalikan kripto Anda? Jelajahi opsi non-kustodial bersama panduan staking Toobit Earn hari ini.
Penafian: Konten di halaman ini disediakan hanya untuk tujuan informasi umum dan tidak mewakili pandangan atau nasihat keuangan dari Toobit. Kami tidak memberikan jaminan apa pun terkait keakuratan atau kelengkapan informasi ini dan tidak bertanggung jawab atas kesalahan, kelalaian, atau hasil apa pun yang timbul dari penggunaannya. Investasi dalam aset digital mengandung risiko; pengguna harus mengevaluasi secara mandiri kondisi keuangan mereka dan risiko yang terlibat. Untuk informasi lebih lanjut, silakan lihat Ketentuan Layanan kami Ketentuan Layanan dan Pengungkapan Risiko.
