Lompat ke konten
Financial Context Wiki

Antrean keluar dan penarikan validator

Permintaan keluar validator, antrean kapasitas keluar, penundaan akuntabilitas, penarikan sweep atau klaim, dan penebusan penyedia adalah tahap yang berbeda. Bangun kembali mesin status protokol, otoritas, throughput, kemampuandihukum, dan jalur aset yang tepat sebelum memperkirakan kapan dana dapat digunakan.

Diperbarui

Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Antrian keluar validator membatasi seberapa cepat bobot konsensus dapat meninggalkan set validator aktif. Ini tidak selalu merupakan mekanisme yang sama dengan antrian permintaan penarikan, penundaan pelepasan atau akuntabilitas, pembersihan otomatis saldo yang memenuhi syarat, klaim yang dilakukan pengguna, atau antrian penebusan penyedia staking. Pertanyaan yang berguna bukanlah “berapa lama antriannya?” tetapi “status apa yang dimiliki posisi ini, transisi apa yang berikutnya, dan kondisi apa yang membuat aset dapat digunakan oleh pemiliknya?”

Pisahkan tahapan dan klaim ini:

  • Penerimaan permintaan: sebuah pesan yang ditandatangani, transaksi, panggilan kontrak, atau instruksi penyedia secara sah disertakan dan diatribusikan kepada validator, akun, atau posisi yang benar.
  • Kapasitas keluar atau penonaktifan: adalah protokol yang membatasi seberapa banyak jumlah validator atau bobot efektif dapat berhenti berpartisipasi per epoch, sesi, atau interval lainnya.
  • Tanggung jawab atau penundaan pelepasan: posisi yang telah keluar atau belum didelegasikan tetap terkunci, dan mungkin tetap terkena hukuman atas perilaku sebelumnya yang dapat ditanggung.
  • Proses penarikan: Saldo yang memenuhi syarat didorong oleh sapuan protokol, ditarik oleh transaksi klaim, dilepaskan dari akun stake, atau ditransfer ketika antrean jatuh tempo diproses.
  • Penebusan penyedia: seorang kustodian, pool, token liquid-staking, atau kontrak restaking menerapkan batching, likuiditas, biaya, kurs, izin, dan penundaan sendiri di sekitar protokol dasar.

Ethereum menjelaskan mengapa perbedaan itu penting. Keluar validator penuh dapat dimulai dengan kunci tanda tangan validator atau, menurut aturan saat ini, dari lapisan eksekusi oleh otoritas penarikan. Setelah penjadwalan keluar dan status dapat ditarik kemudian, penarikan penuh yang memenuhi syarat dengan kredensial penarikan eksekusi disapu secara otomatis. Validator Type 1 versi lama dan validator Type 2 yang menggabungkan memiliki perilaku penarikan sebagian yang berbeda. Oleh karena itu, transaksi permintaan, keluar konsensus, epoch yang dapat ditarik, dan penyapuan adalah pengamatan yang terpisah.

Label Ethereum itu tidak universal. Dalam rantai Cosmos SDK, pembatalan delegasi oleh delegator akan membuat entri unbonding dengan waktu penyelesaian yang dikonfigurasi oleh rantai, dan modul eksternal dapat menunda unbonding. Dalam Solana, otoritas akun stake menonaktifkan delegasi, stake mendingin melintasi batas epoch, dan otoritas penarikan dapat menarik stake yang tidak aktif dengan syarat adanya penguncian. Kontrak restaking dapat menambahkan antrian penarikan lain dan jendela yang dapat dikenai slash. Selalu periksa jaringan, versi, modul, kontrak, dan ketentuan layanan secara tepat.

Cara menganalisis waktu keluar dan penarikan

1. Tentukan posisi dan aturan

Catat network, chain ID, fork atau runtime yang aktif, blok atau epoch, versi klien/spesifikasi, modul staking atau kontrak, dan ketentuan layanan. Identifikasi apakah objek tersebut adalah identitas validator, self-stake, saham yang didelegasikan, akun stake, klaim gabungan, token liquid-staking, atau alokasi yang di-stake ulang. Jangan terapkan aturan keluar validator pada penebusan delegator atau kewajiban off-chain penyedia.

2. Verifikasi otoritas dan minta persetujuan

Petakan kunci penandatangan validator, kredensial atau otoritas penarikan, otoritas stake, pemilik akun, pemanggil kontrak, penerima manfaat, dan pembayar biaya. Salin kembali bidang pesan yang diperlukan, domain tanda tangan, indeks atau kunci publik validator, jumlah, nonce, tujuan, dan biaya. Konfirmasikan inklusi yang telah difinalisasi dan kondisi yang dihasilkan; file yang ditandatangani secara lokal, transaksi yang dikirim, tiket penyedia, atau simulasi yang sukses bukanlah bukti bahwa protokol menerima permintaan.

3. Rekonstruksi mesin status

Tuliskan setiap status dan transisi daripada satu tanggal perkiraan. Jalur validator ilustratif adalah active -> exit_requested -> exit_scheduled -> exited -> withdrawable -> withdrawal_processed -> wallet_credited. Seorang delegator mungkin sebaliknya bergerak melalui bonded -> unbonding -> matured -> transferred, sementara akun stake mungkin active -> deactivating -> inactive -> withdrawn. Catat transisi mana yang otomatis dan mana yang memerlukan transaksi atau tindakan layanan lain.

4. Kuantifikasi setiap hambatan

Pisahkan batas request-ingress, pergantian keluar validator, penundaan tetap, kapasitas penarikan-sapu, antrean kontrak, pengelompokan penyedia, dan finalitas atau konfirmasi. Tentukan apakah kapasitas diukur berdasarkan catatan validator, stake efektif, saldo, permintaan, gas, atau waktu yang telah berlalu. Kuak queue_ahead, capacity_per_interval, ukuran set-aktif atau saldo, dan batasan apa pun pada titik pengamatan yang sama yang telah final. Estimasi sederhana ceil((work_ahead + own_work) / capacity) hanya berlaku ketika asumsi urutan dan kapasitas terpenuhi.

5. Temukan tugas, hadiah, dan kemungkinan terkena pemotongan

Temukan epoch, ketinggian, atau status tepat ketika tugas proposal dan voting berakhir, ketika hadiah biasa berhenti, ketika penalti masih dapat diterapkan, dan ketika saldo berhenti dapat dikenai slash. Waktu-waktu ini tidak harus bertepatan. Jaga validator tetap online dan dikonfigurasi dengan benar sampai status protokol mengatakan tugasnya telah berakhir; permintaan keluar yang disiarkan atau status antarmuka depan tidak cukup sebagai wewenang untuk mematikannya.

6. Lacak aset dan lapisan klaim

Ikuti unit asli dari akuntansi terikat atau aktif melalui menunggu, melepaskan ikatan, dapat ditarik, escrow kontrak, kustodi penyedia, dan akun tujuan. Nilai secara terpisah saham, token tanda terima, atau token staking likuid menggunakan nilai tukar dan harga pasar mereka. Rekonsiliasikan hadiah protokol, hukuman, pemotongan, komisi, biaya penebusan, gas, biaya jembatan, dan pembulatan. Menjual klaim memindahkan risiko likuiditas ke pembeli; itu tidak mempercepat transisi protokol dasar.

7. Verifikasi penyelesaian dan rencanakan likuiditas

Gunakan status final, peristiwa protokol, catatan antrean, objek penarikan, saldo akun tujuan, dan kewajiban penyedia untuk membuktikan setiap transisi. Simpan identifikasi permintaan dan cuplikan parameter yang digunakan untuk perkiraan. Buat rencana kas dengan rentang dan cadangan kontingensi daripada satu tanggal saja, dan tentukan eskalasi untuk sweep yang hilang, kontrak yang dihentikan sementara, kredensial yang salah, kebangkrutan penyedia, atau saldo yang berbeda dari rekonsiliasi yang diharapkan.

Contoh yang dikerjakan

Perhitungan waktu multi-tahap

Pertimbangkan sebuah protokol ilustratif dengan block_time = 12 seconds dan epoch = 30 blocks = 6 minutes. Sebuah permintaan memerlukan 4 blocks untuk mencapai titik konfirmasi yang dipilih, menunggu 72 epochs untuk kapasitas keluar, kemudian memiliki penundaan akuntabilitas 8 epochs dan 12 blocks yang diharapkan hingga pemrosesan transfer:

4 * 12 = 48 seconds.

72 * 6 = 432 minutes.

8 * 6 = 48 minutes.

12 * 12 = 144 seconds = 2.4 minutes.

Total waktu ilustratif adalah 48 seconds + 432 minutes + 48 minutes + 2.4 minutes = 483.2 minutes = 8.0533 hours. Tahap-tahapnya bertambah karena bersifat berurutan. Ini bukan perkiraan Ethereum: aturan nyata dapat menggunakan interval yang berbeda, churn tergantung pada keadaan, penundaan minimum, algoritma sapuan, dan asumsi finalitas.

Antrian berbasis berat dengan kapasitas yang berubah

Misalkan unit efektif work_ahead = 50,000, keluaran ini mewakili own_work = 320, dan capacity_per_epoch = 640 awal. Dengan kapasitas konstan:

ceil((50,000 + 320) / 640) = ceil(78.625) = 79 epochs.

Pada 6 minutes per epoch, yaitu 79 * 6 = 474 minutes = 7.9 hours. Tetapi anggap kapasitas turun menjadi 512 setelah epoch 30. Epoch pertama 30 memproses 30 * 640 = 19,200, menyisakan 50,320 - 19,200 = 31,120. Sisanya memerlukan ceil(31,120 / 512) = 61 epochs, jadi total yang direvisi adalah 30 + 61 = 91 epochs = 9.1 hours. Perkiraan secara langsung harus menghitung ulang kapasitas dan urutan alih-alih membekukan satu laju dashboard.

Rekonsiliasi saldo melalui keluar

Seorang validator ilustratif dimulai dengan unit 32, memperoleh 0.40 sebelum tugas berakhir, menanggung 0.05 dari sanksi biasa, dan kemudian menerima pemotongan 1.20 yang dapat diatribusikan sesuai dengan jendela eksposur protokol. Jumlah yang tersedia sebelum biaya penyedia atau pajak adalah:

32 + 0.40 - 0.05 - 1.20 = 31.15 units.

Permintaan tersebut tidak mengunci pembayaran unit 32. Perubahan saldo protokol, akuntansi penyedia, dan perubahan harga pasar adalah buku besar yang terpisah. Jika tujuan menerima 31.15, itu menyeimbangkan jalur unit asli tetapi tidak mengatakan apa-apa tentang nilai fiat atau hak penggantian.

Klaim likuid versus penebusan antrean

Misalkan token liquid-staking 100 dapat dijual sekarang dengan masing-masing 0.965 unit asli, menghasilkan:

100 * 0.965 = 96.5 units.

Seorang penyedia sebaliknya mengutip penebusan sebesar satu unit asli per token setelah antrian dengan biaya 0.2%, atau 100 * (1 - 0.002) = 99.8 units. Perbedaannya adalah 99.8 - 96.5 = 3.3 units, dan diskon penjualan segera relatif terhadap hasil antrian yang dikutip adalah 3.3 / 99.8 = 3.3066%. Selisih unit 3.3 mengkompensasi waktu, ketidakpastian, dan likuiditas hanya pada cuplikan ini; pemotongan, perubahan nilai tukar, kerugian kontrak, atau antrian yang ditangguhkan dapat mengubah hasil di kemudian hari.

Risiko dan kegagalan tinjauan

  • Antrean yang salah: Antrean keluar validator, penerimaan permintaan penarikan, unbonding, sweep, kontrak, dan penebusan penyedia memiliki status dan kapasitas berbeda.
  • Aturan yang salah: Chain, fork, runtime, versi modul, testnet, atau penyebaran kontrak yang berbeda dapat memakai transisi berbeda.
  • Parameter kedaluwarsa: Laju keluar, penundaan tetap, batas sweep, biaya, lockup, dan ketentuan penyedia dapat berubah setelah perkiraan dibuat.
  • Permintaan belum diterima: Menandatangani, menyiarkan, menyimulasikan, atau membuka tiket tidak membuktikan penerimaan final oleh protokol.
  • Kebingungan otoritas: Kunci validator, penarikan, stake, pemilik, kustodian, dan admin kontrak dapat mengotorisasi tindakan berbeda.
  • Kesalahan kredensial atau tujuan: Konversi kredensial yang tidak dapat dibatalkan atau alamat penarikan yang salah dapat memindahkan kendali secara permanen.
  • Penghentian dini: Menghentikan tugas sebelum status keluar tercatat dapat menghilangkan hadiah atau menimbulkan penalti.
  • Kesalahan waktu penghentian hadiah: Permintaan, keluar terjadwal, keluar aktual, kelayakan penarikan, dan transfer dapat mengikuti aturan akrual berbeda.
  • Risiko slashing residual: Dana yang telah keluar, sedang unbonding, atau mengantre dapat tetap terpapar pelanggaran sebelumnya yang dapat diatribusikan.
  • Ketidaksesuaian jumlah dan bobot: Antrean dalam jumlah validator mungkin tidak mencerminkan kapasitas yang dibatasi berdasarkan saldo efektif atau saham.
  • Kesalahan antrean dinamis: Perubahan parameter atau set aktif berikutnya dapat mengubah throughput meskipun permintaan baru tidak dapat mendahului permintaan lama.
  • Kebingungan sweep dan klaim: Setelah memenuhi syarat, dana dapat dikirim otomatis, memerlukan klaim, atau masih menunggu sweep berkala.
  • Kebingungan parsial dan penuh: Penarikan saldo berlebih, undelegation parsial, dan keluar validator sepenuhnya tidak setara.
  • Lockup dan penahanan: Penguncian akun, kontrol tata kelola, jeda keamanan, atau penahanan modul eksternal dapat melampaui jatuh tempo nominal.
  • Ketidaksesuaian penyedia: Layanan dapat menunda, mengelompokkan, membatasi, melakukan netting, atau menolak penebusan meski protokol dasar selesai.
  • Tumpang tindih restaking: Keluar dari chain dasar mungkin tidak melepaskan stake yang dialokasikan ke layanan lain atau mengakhiri jendela penalti layanan tersebut.
  • Risiko basis klaim likuid: Token liquid staking dapat diperdagangkan di bawah nilai klaimnya atau kehilangan konvertibilitas saat kondisi tertekan.
  • Biaya dan kerugian pembulatan: Gas, biaya permintaan dinamis, komisi, konversi saham, biaya bridge, dan perubahan desimal memengaruhi jumlah yang diterima.
  • Kegagalan kustodian atau kontrak: Kunci yang disusupi, insolvensi, otoritas upgrade, bug, atau kegagalan bridge dapat memblokir atau mengalihkan aset.
  • Kesalahan observabilitas dan finalitas: Dasbor dapat tertinggal, mengabaikan entri yang ditahan, mencampur status perkiraan dengan final, atau menampilkan peristiwa yang kemudian terkena reorg.

Kesalahpahaman umum

Apakah mengajukan keluar berarti tugas validator langsung berhenti?

Tidak. Permintaan inklusi, penjadwalan keluar, dan status di mana tugas berakhir adalah terpisah. Teruslah beroperasi sesuai protokol sampai status final mengonfirmasi bahwa validator tidak lagi diperlukan untuk berpartisipasi.

Apakah ‘withdrawable’ berarti dompet tujuan telah dikreditkan?

Tidak. withdrawable biasanya menjelaskan kelayakan. Protokol mungkin masih perlu menyapu validator, seorang pengguna mungkin perlu melakukan klaim, sebuah akun mungkin perlu penarikan eksplisit, atau penyedia mungkin perlu melepaskan tanggung jawabnya. Verifikasikan saldo tujuan.

Apakah panjang antrean dibagi dengan tarif hari ini dapat memberikan tanggal yang tepat?

Tidak. Layar mungkin menghitung unit yang salah, kapasitas bisa bergantung pada kondisi, penundaan tetap dan waktu penyapuan mungkin terjadi, dan tahap penyedia bisa dihilangkan. Nyatakan semua asumsi dan hitung rentang.

Apakah menjual token liquid-staking melewati antrean keluar?

Ini memberikan likuiditas pasar segera kepada penjual jika ada pembeli. Saham dasar atau klaim penebusan pemegang lain tetap mengikuti protokol dan aturan penyedia, sementara penjual menerima harga pasar dan biaya perdagangan.

Apakah periode unbonding atau penarikan yang diiklankan merupakan batas maksimum yang dijamin?

Tidak. Itu mungkin merupakan penundaan minimum atau yang diharapkan yang tidak termasuk pencantuman permintaan, kemacetan, finalitas, pembersihan, penahanan, jeda kontrak, pengelompokan penyedia, atau respons insiden. Hanya aturan aktif dan kondisi yang diamati yang menentukan penyelesaian.

Topik terkait

Sumber

Navigasi

Cari di wiki...