Kemarin malam membaca whitepaper TBV BabylonLabs, sampai pada bagian verifikasi bukti pengetahuan nol untuk withdrawal, saya berhenti sejenak. Saya menggambar ulang jalur verifikasinya, barulah saya sadar sebelumnya saya menganggap masalahnya terlalu sederhana.@BabylonLabs_io
Saya terus bingung: mengapa tidak membiarkan mainchain Bitcoin memahami perubahan status dari protokol eksternal secara langsung? Jawabannya ada pada batas verifikasi. Desain script Bitcoin sejak awal tidak dibuat untuk menangani status eksternal; memaksanya justru akan mengubah logika verifikasi yang asli. Jadi TBV menempuh jalur yang lebih terukur. Hasil dari protokol eksternal diubah menjadi kondisi pengeluaran yang bisa diverifikasi secara mandiri oleh Bitcoin melalui mekanisme pembuktian; Bitcoin hanya perlu memeriksa apakah kondisi yang dikirimkan memenuhi aturan.
Di whitepaper resmi, kata “Translation” diulang-ulang; dari pemahaman saya, itu berarti menerjemahkan status eksternal menjadi kondisi kepercayaan yang dapat diverifikasi oleh Bitcoin. Hasil komputasi protokol eksternal yang dibatasi oleh bukti diverifikasi oleh Bitcoin; keduanya terhubung dengan bukti kriptografis, dan sejak awal sampai akhir tidak berbagi sumber kepercayaan yang sama. Inilah logika desain paling inti dari TBV.
Namun, meminimalkan kepercayaan tidak berarti tanpa risiko. Light client Babylon hanya menyinkronkan header blok dan memverifikasi bukti Merkle. Jika jaringan Bitcoin mengalami reorganisasi, transaksi penyimpanan di blok-blok terisolasi bisa di-rollback, sementara aset yang sudah dicetak di atas chain kontrak mungkin sudah terlanjur dibuat. Lembaga audit keamanan pernah mensimulasikan skenario: setelah chain Babylon mogok lalu restart, light client masih menganggap tinggi blok yang lama benar; pool penambang jahat mengirimkan chain fork palsu untuk lolos verifikasi. Ini adalah keterbatasan yang bersifat fisik pada mode light client, bukan celah pada level kode. Untuk mengatasinya, ada tata kelola $BABY : pemegang koin memilih jumlah blok untuk dikonfirmasi. Pada dasarnya, itu adalah pilihan preferensi risiko, bukan hard-coding teknis.
Intinya, daya tarik utama TBV bukan pada berapa banyak skenario yang disambungkan, melainkan pada kemampuannya membuat BTC terlibat dalam logika keuangan yang lebih kompleks tanpa mengubah model keamanan Bitcoin. Hal yang patut diperhatikan pada BABY mungkin bukan karena ia terhubung ke berapa banyak aplikasi, melainkan karena cara kolaborasi antara aturan verifikasi dan komputasi eksternal—apakah kita benar-benar bisa mengeksplorasi kemungkinan-kemungkinan baru.#baby
Saya terus bingung: mengapa tidak membiarkan mainchain Bitcoin memahami perubahan status dari protokol eksternal secara langsung? Jawabannya ada pada batas verifikasi. Desain script Bitcoin sejak awal tidak dibuat untuk menangani status eksternal; memaksanya justru akan mengubah logika verifikasi yang asli. Jadi TBV menempuh jalur yang lebih terukur. Hasil dari protokol eksternal diubah menjadi kondisi pengeluaran yang bisa diverifikasi secara mandiri oleh Bitcoin melalui mekanisme pembuktian; Bitcoin hanya perlu memeriksa apakah kondisi yang dikirimkan memenuhi aturan.
Di whitepaper resmi, kata “Translation” diulang-ulang; dari pemahaman saya, itu berarti menerjemahkan status eksternal menjadi kondisi kepercayaan yang dapat diverifikasi oleh Bitcoin. Hasil komputasi protokol eksternal yang dibatasi oleh bukti diverifikasi oleh Bitcoin; keduanya terhubung dengan bukti kriptografis, dan sejak awal sampai akhir tidak berbagi sumber kepercayaan yang sama. Inilah logika desain paling inti dari TBV.
Namun, meminimalkan kepercayaan tidak berarti tanpa risiko. Light client Babylon hanya menyinkronkan header blok dan memverifikasi bukti Merkle. Jika jaringan Bitcoin mengalami reorganisasi, transaksi penyimpanan di blok-blok terisolasi bisa di-rollback, sementara aset yang sudah dicetak di atas chain kontrak mungkin sudah terlanjur dibuat. Lembaga audit keamanan pernah mensimulasikan skenario: setelah chain Babylon mogok lalu restart, light client masih menganggap tinggi blok yang lama benar; pool penambang jahat mengirimkan chain fork palsu untuk lolos verifikasi. Ini adalah keterbatasan yang bersifat fisik pada mode light client, bukan celah pada level kode. Untuk mengatasinya, ada tata kelola $BABY : pemegang koin memilih jumlah blok untuk dikonfirmasi. Pada dasarnya, itu adalah pilihan preferensi risiko, bukan hard-coding teknis.
Intinya, daya tarik utama TBV bukan pada berapa banyak skenario yang disambungkan, melainkan pada kemampuannya membuat BTC terlibat dalam logika keuangan yang lebih kompleks tanpa mengubah model keamanan Bitcoin. Hal yang patut diperhatikan pada BABY mungkin bukan karena ia terhubung ke berapa banyak aplikasi, melainkan karena cara kolaborasi antara aturan verifikasi dan komputasi eksternal—apakah kita benar-benar bisa mengeksplorasi kemungkinan-kemungkinan baru.#baby