#baby $BABY Bagaimana cara melakukan slashing terhadap seorang validator di Bitcoin ketika Bitcoin tidak memiliki logika slashing bawaan?
Saya butuh waktu lebih lama dari yang saya kira untuk benar-benar memahami hal ini, karena jawabannya bukan smart contract—melainkan skema tanda tangan yang melakukan sesuatu yang cerdik dengan matematika, bukan kode.
@BabylonLabs_io menggunakan yang disebut Extractable One-Time Signature (EOTS), yang dibangun di atas tanda tangan Schnorr asli Bitcoin. Inti idenya begini: penyedia finalitas membuat pasangan kunci unik untuk setiap tinggi blok yang mereka pilih. Selama mereka hanya pernah menandatangani satu blok per tinggi, tanda tangannya tetap benar-benar aman dan tidak ada yang bocor. Tapi jika mereka menandatangani dua blok yang saling bertentangan pada tinggi yang sama, maka matematikanya runtuh. Menggunakan kunci per-tinggi itu untuk menandatangani dua pesan berbeda mengekspos kunci privat mereka secara langsung, karena cara kerja matematika tanda tangan Schnorr ketika nonce digunakan ulang.
Ronde finalitas sendiri membutuhkan tanda tangan dari lebih dari dua pertiga bobot BTC yang dipertaruhkan agar sebuah blok benar-benar bisa final—artinya, setiap pelanggaran keamanan, secara definisi, menuntut lebih dari sepertiga stake untuk melakukan double-signed. Itulah yang membuat jaminan "fully slashable" benar-benar dipaksakan secara matematis, bukan sekadar janji kebijakan: setelah kunci bocor, siapa pun bisa—bukan hanya Babylon, bukan hanya validator—untuk menyusun dan menyiarkan transaksi slashing. Tidak perlu pemungutan suara komite pada tahap itu, tidak ada proses banding, hanya matematika yang terbuka.
Hal yang belum saya lihat jawabannya dengan jelas: apakah pembuatan kunci untuk setiap tinggi blok menimbulkan beban operasional yang berarti bagi penyedia finalitas yang menjalankan banyak BSN secara bersamaan, dan bisakah beban itu sendiri menjadi permukaan serangan—misalnya jika sebuah penyedia, saat kewalahan, secara tidak sengaja menggunakan ulang randomness bukan karena niat jahat?
Apakah keamanan EOTS murni jaminan matematika, atau diam-diam bergantung juga pada penyedia finalitas memiliki infrastruktur manajemen kunci yang solid?
$BABY
Saya butuh waktu lebih lama dari yang saya kira untuk benar-benar memahami hal ini, karena jawabannya bukan smart contract—melainkan skema tanda tangan yang melakukan sesuatu yang cerdik dengan matematika, bukan kode.
@BabylonLabs_io menggunakan yang disebut Extractable One-Time Signature (EOTS), yang dibangun di atas tanda tangan Schnorr asli Bitcoin. Inti idenya begini: penyedia finalitas membuat pasangan kunci unik untuk setiap tinggi blok yang mereka pilih. Selama mereka hanya pernah menandatangani satu blok per tinggi, tanda tangannya tetap benar-benar aman dan tidak ada yang bocor. Tapi jika mereka menandatangani dua blok yang saling bertentangan pada tinggi yang sama, maka matematikanya runtuh. Menggunakan kunci per-tinggi itu untuk menandatangani dua pesan berbeda mengekspos kunci privat mereka secara langsung, karena cara kerja matematika tanda tangan Schnorr ketika nonce digunakan ulang.
Ronde finalitas sendiri membutuhkan tanda tangan dari lebih dari dua pertiga bobot BTC yang dipertaruhkan agar sebuah blok benar-benar bisa final—artinya, setiap pelanggaran keamanan, secara definisi, menuntut lebih dari sepertiga stake untuk melakukan double-signed. Itulah yang membuat jaminan "fully slashable" benar-benar dipaksakan secara matematis, bukan sekadar janji kebijakan: setelah kunci bocor, siapa pun bisa—bukan hanya Babylon, bukan hanya validator—untuk menyusun dan menyiarkan transaksi slashing. Tidak perlu pemungutan suara komite pada tahap itu, tidak ada proses banding, hanya matematika yang terbuka.
Hal yang belum saya lihat jawabannya dengan jelas: apakah pembuatan kunci untuk setiap tinggi blok menimbulkan beban operasional yang berarti bagi penyedia finalitas yang menjalankan banyak BSN secara bersamaan, dan bisakah beban itu sendiri menjadi permukaan serangan—misalnya jika sebuah penyedia, saat kewalahan, secara tidak sengaja menggunakan ulang randomness bukan karena niat jahat?
Apakah keamanan EOTS murni jaminan matematika, atau diam-diam bergantung juga pada penyedia finalitas memiliki infrastruktur manajemen kunci yang solid?
$BABY