Dua pagi, Chen tua melemparkan sebuah tautan: “Babylon, pakai Bitcoin untuk jadi satpam bagi rantai PoS, coba lihat.”
Aku membuka dokumennya, lama sekali menatap bagian “Bitcoin-secured PoS”. “Babylon enables native bitcoin staking directly on the Bitcoin blockchain without intermediaries.” Dengan memanfaatkan keamanan finansial Bitcoin sebagai lapisan pertahanan eksternal, agar rantai PoS berbagi finalitas BTC—ide itu memang indah. Siapa pun yang pernah menulis protokol konsensus pasti mengakui, desain ini adalah upaya keamanan paling agresif di jalur tersebut saat ini.
Tapi saat aku membongkar komponen di bawahnya dengan cara menyusuri light client, punggungku mulai meremang.
Jaringan Babylon hanya menjalankan light node BTC, tidak melakukan sinkronasi penuh buku besar Bitcoin; ia hanya mengandalkan header blok dan validasi skrip UTXO. Laporan audit Zellic secara tegas menyebutkan: jika jaringan Babylon mengalami panic lalu crash, setelah restart, btclightclient tetap akan menganggap ketinggian saat crash sebagai status terbaru. Dalam jendela waktu yang kosong itu, attacker—misalnya mining pool jahat—bisa lebih dulu mengirim header blok dari chain bercabang; light client untuk sementara akan menganggap fork tersebut sebagai main chain. Akibatnya, transaksi staking bisa dikonfirmasi pada fork yang salah. Dan ketika jaringan Bitcoin mengalami orphan block, reorg, atau rollback blok dalam, light client tidak punya kemampuan untuk mendeteksinya.
Yang membuat punggungku makin meremang adalah EOTS. Ini adalah inovasi inti Babylon: tanda tangan sekali-pakai yang dapat diekstraksi, digunakan untuk bukti penalti lintas rantai—“if an FP signs two different blocks at the same height, the private key is exposed, leading to automatic slashing”. Kedengarannya sangat bagus, namun audit Zellic menemukan bahwa fungsi GenerateRandomness pada eotsmanager saat memakai SetByteSlice tidak memeriksa nilai baliknya—ketika terjadi overflow pada orde grup Secp256k1, nonce menjadi distribusi yang tidak seragam. Walau peluangnya rendah, jika overflow terjadi, sampel yang dihasilkan dapat dipadukan dengan algoritma Hidden Number Problem untuk memulihkan private key EOTS. Lebih mematikan lagi adalah GHSA-7mm3-vfg8-7rg6: modul x/finality tidak memiliki domain separation, sehingga penyerang dapat melakukan replay tanda tangan PoP menjadi MsgCommitPubRandList, lalu menyuntikkan komitmen PubRand yang tidak valid.
Dengan menjadikan finalitas Bitcoin sebagai benteng, namun light client tak bisa melihat fork Bitcoin—untuk penalti, mereka membuat kriptografi sendiri; pada EOTS, pembangkitan randomness sampai overflow pun tak dicek. Kamu percaya pada rantai Bitcoin, atau pada potongan kode ini?
#baby $BABY @BabylonLabs_io
Aku membuka dokumennya, lama sekali menatap bagian “Bitcoin-secured PoS”. “Babylon enables native bitcoin staking directly on the Bitcoin blockchain without intermediaries.” Dengan memanfaatkan keamanan finansial Bitcoin sebagai lapisan pertahanan eksternal, agar rantai PoS berbagi finalitas BTC—ide itu memang indah. Siapa pun yang pernah menulis protokol konsensus pasti mengakui, desain ini adalah upaya keamanan paling agresif di jalur tersebut saat ini.
Tapi saat aku membongkar komponen di bawahnya dengan cara menyusuri light client, punggungku mulai meremang.
Jaringan Babylon hanya menjalankan light node BTC, tidak melakukan sinkronasi penuh buku besar Bitcoin; ia hanya mengandalkan header blok dan validasi skrip UTXO. Laporan audit Zellic secara tegas menyebutkan: jika jaringan Babylon mengalami panic lalu crash, setelah restart, btclightclient tetap akan menganggap ketinggian saat crash sebagai status terbaru. Dalam jendela waktu yang kosong itu, attacker—misalnya mining pool jahat—bisa lebih dulu mengirim header blok dari chain bercabang; light client untuk sementara akan menganggap fork tersebut sebagai main chain. Akibatnya, transaksi staking bisa dikonfirmasi pada fork yang salah. Dan ketika jaringan Bitcoin mengalami orphan block, reorg, atau rollback blok dalam, light client tidak punya kemampuan untuk mendeteksinya.
Yang membuat punggungku makin meremang adalah EOTS. Ini adalah inovasi inti Babylon: tanda tangan sekali-pakai yang dapat diekstraksi, digunakan untuk bukti penalti lintas rantai—“if an FP signs two different blocks at the same height, the private key is exposed, leading to automatic slashing”. Kedengarannya sangat bagus, namun audit Zellic menemukan bahwa fungsi GenerateRandomness pada eotsmanager saat memakai SetByteSlice tidak memeriksa nilai baliknya—ketika terjadi overflow pada orde grup Secp256k1, nonce menjadi distribusi yang tidak seragam. Walau peluangnya rendah, jika overflow terjadi, sampel yang dihasilkan dapat dipadukan dengan algoritma Hidden Number Problem untuk memulihkan private key EOTS. Lebih mematikan lagi adalah GHSA-7mm3-vfg8-7rg6: modul x/finality tidak memiliki domain separation, sehingga penyerang dapat melakukan replay tanda tangan PoP menjadi MsgCommitPubRandList, lalu menyuntikkan komitmen PubRand yang tidak valid.
Dengan menjadikan finalitas Bitcoin sebagai benteng, namun light client tak bisa melihat fork Bitcoin—untuk penalti, mereka membuat kriptografi sendiri; pada EOTS, pembangkitan randomness sampai overflow pun tak dicek. Kamu percaya pada rantai Bitcoin, atau pada potongan kode ini?
#baby $BABY @BabylonLabs_io