Saya ingin tahu apa yang terjadi pada jeda antara saat real backing penyedia finalitas berubah dan ketika protokol mengakui bahwa perubahan itu sudah terjadi. Jadi saya menelusuri bagaimana modul x/epoching di Babylon benar-benar memproses delegasi baru.

Pesan staking dan unstaking tidak dieksekusi seketika. Mereka mengantri selama panjang satu epoch penuh, lalu diproses dalam satu batch di batasnya. Sampai batas itu tercapai, kekuatan voting finalitas rantai masih mencerminkan snapshot lama, bukan yang terbaru. Penyedia finalitas bisa saja kehilangan delegasi secara real time, bisa secara ekonomis mengosongkan diri di tengah epoch, namun tetap melakukan voting dengan bobot yang dimilikinya sebelum siapa pun menarik.

Ini bukan bug. Ini adalah tradeoff untuk membatch ribuan delegasi yang didukung BTC menjadi satu penyelesaian alih-alih memproses semuanya secara individual. Tetapi artinya dukungan keamanan kripto-ekonomis untuk sebuah blok tertentu bukanlah keamanan yang ada saat ini. Itu adalah keamanan yang ada pada checkpoint terakhir, dibawa ke depan atas dasar kepercayaan bahwa tidak ada perubahan material di antaranya.

Saya terus membandingkannya dengan cara kerja jalur kredit. Limit Anda tidak langsung berubah saat penghasilan Anda berubah. Limit itu diperbarui pada satu siklus, dan di antaranya, bank memperpanjang kepercayaan berdasarkan angka yang sudah sedikit tidak tepat. Babylon melakukan hal yang sama dengan bobot Bitcoin, hanya saja dengan kriptografi yang lebih baik yang melapisi ketidakakuratan itu.

Saya tidak berpikir ini merusak model. Fast unbonding, kurang lebih dua hari, membuat jendela tersebut tetap pendek dibandingkan rantai PoS pada umumnya. Tapi pendek itu tidak nol, dan bagian yang perlu diawasi bukanlah harga token. Yang perlu diperhatikan adalah seberapa lebar jendela epoch itu ketika set validator terus bertambah ukurannya.

$BABY @BabylonLabs_io #baby $ON $BTC