Makan malam bersama semalam, Pak Zhou yang mengurus audit keamanan menyelipkan sepotong sayur dan berkata, “Babylon light client itu menarik juga. Finalitas Bitcoin akhirnya bisa jadi parit pertahanan, tapi light client-nya bahkan tak bisa melihat fork.”
Pulang ke rumah, aku buka dokumen dan menatap lama bagian “Bitcoin-secured PoS”. Mengandalkan keamanan ekonomi Bitcoin untuk membuat garis pertahanan eksternal bagi rantai PoS—idenya memang terlihat indah. Siapa pun yang pernah menulis protokol konsensus akan mengakui bahwa desain ini adalah upaya keamanan paling agresif di jalurnya.
Tapi saat menguraikan light client lebih lanjut, punggungku mulai merinding.
Rantai Babylon hanya menjalankan light node BTC, dan hanya bergantung pada verifikasi header blok serta skrip UTXO. Ketika Bitcoin mengalami orphan block, reorganisasi, atau deep rollback, light client sama sekali tidak bisa mengenalinya. Laporan audit Zellic lebih gamblang: jika rantai Babylon panic dan crash, setelah restart, light client tetap menganggap ketinggian sebelum crash sebagai yang terbaru. Dalam periode kosong, pool penambang yang berniat jahat menggali fork chain, mengirim lebih dulu header blok fork tersebut; light client akan sementara menganggap fork sebagai main chain—transaksi staking bisa saja terkonfirmasi pada fork yang salah.
Yang lebih membuat punggungku merinding adalah EOTS. Inovasi inti Babylon adalah “tanda tangan one-time yang dapat diekstrak”, digunakan untuk bukti penalti lintas-chain—“if an FP signs two different blocks at the same height, the private key is exposed”. Alurnya sudah saling menutup.
Namun, audit Zellic menemukan bahwa fungsi GenerateRandomness di eotsmanager memakai SetByteSlice tanpa memeriksa return value—ketika terjadi overflow pada orde grup Secp256k1, nonce menjadi distribusi yang tidak merata. Begitu ada sampel overflow, dikombinasikan dengan algoritma HNP, kunci privat EOTS bisa dipulihkan.
Yang lebih mematikan lagi: GHSA-7mm3-vfg8-7rg6. Modul x/finality kurang domain separation; penyerang dapat me-replay PoP signature menjadi MsgCommitPubRandList, lalu menyuntikkan komitmen yang tidak valid.
Memakai finalitas Bitcoin sebagai parit pertahanan, tetapi light client tak bisa melihat fork. Membuat penalti dengan kriptografi buatan sendiri, tetapi pengecekan terhadap overflow pada bilangan acak pun tidak ada.
Bagaimana menurutmu, Pak Zhou?
Catatan: di atas hanyalah pendapat pribadi dan bukan nasihat investasi. Apakah kamu punya pandangan berbeda? Selamat berdiskusi di kolom komentar.
#baby $BABY @BabylonLabs_io
Pulang ke rumah, aku buka dokumen dan menatap lama bagian “Bitcoin-secured PoS”. Mengandalkan keamanan ekonomi Bitcoin untuk membuat garis pertahanan eksternal bagi rantai PoS—idenya memang terlihat indah. Siapa pun yang pernah menulis protokol konsensus akan mengakui bahwa desain ini adalah upaya keamanan paling agresif di jalurnya.
Tapi saat menguraikan light client lebih lanjut, punggungku mulai merinding.
Rantai Babylon hanya menjalankan light node BTC, dan hanya bergantung pada verifikasi header blok serta skrip UTXO. Ketika Bitcoin mengalami orphan block, reorganisasi, atau deep rollback, light client sama sekali tidak bisa mengenalinya. Laporan audit Zellic lebih gamblang: jika rantai Babylon panic dan crash, setelah restart, light client tetap menganggap ketinggian sebelum crash sebagai yang terbaru. Dalam periode kosong, pool penambang yang berniat jahat menggali fork chain, mengirim lebih dulu header blok fork tersebut; light client akan sementara menganggap fork sebagai main chain—transaksi staking bisa saja terkonfirmasi pada fork yang salah.
Yang lebih membuat punggungku merinding adalah EOTS. Inovasi inti Babylon adalah “tanda tangan one-time yang dapat diekstrak”, digunakan untuk bukti penalti lintas-chain—“if an FP signs two different blocks at the same height, the private key is exposed”. Alurnya sudah saling menutup.
Namun, audit Zellic menemukan bahwa fungsi GenerateRandomness di eotsmanager memakai SetByteSlice tanpa memeriksa return value—ketika terjadi overflow pada orde grup Secp256k1, nonce menjadi distribusi yang tidak merata. Begitu ada sampel overflow, dikombinasikan dengan algoritma HNP, kunci privat EOTS bisa dipulihkan.
Yang lebih mematikan lagi: GHSA-7mm3-vfg8-7rg6. Modul x/finality kurang domain separation; penyerang dapat me-replay PoP signature menjadi MsgCommitPubRandList, lalu menyuntikkan komitmen yang tidak valid.
Memakai finalitas Bitcoin sebagai parit pertahanan, tetapi light client tak bisa melihat fork. Membuat penalti dengan kriptografi buatan sendiri, tetapi pengecekan terhadap overflow pada bilangan acak pun tidak ada.
Bagaimana menurutmu, Pak Zhou?
Catatan: di atas hanyalah pendapat pribadi dan bukan nasihat investasi. Apakah kamu punya pandangan berbeda? Selamat berdiskusi di kolom komentar.
#baby $BABY @BabylonLabs_io