Baru saja menyelesaikan lagi beberapa bagian alur kliring @BabylonLabs_io , lalu menyadari ada satu hal yang selama ini belum benar-benar kupahami: Kustodian itu sebenarnya skrip yang sudah ditandatangani lebih awal, yang tidak bisa diubah oleh siapa pun—lalu bagaimana ia “tahu” kapan harus meloloskan BTC?
Dulu pemahamanku adalah pasti ada semacam oracle yang mengawasi; lalu kirim sinyal dari luar rantai, di atas rantai langsung dieksekusi. Setelah kucermati, ternyata bukan begitu—cara TBV justru kebalikannya: bukan membuat Bitcoin secara aktif merasakan apa yang terjadi di chain inang, tetapi pihak yang ingin menggunakan BTC sendiri harus menerjemahkan peristiwa yang sudah terjadi di chain inang menjadi sebuah bukti kriptografis yang bisa diverifikasi oleh skrip Bitcoin, lalu mengirimkannya.
Skrip itu sendiri dari awal sampai akhir tidak memahami pinjam-meminjam, tidak memahami kliring, tidak memahami harga—ia hanya melakukan satu hal: memverifikasi apakah bukti itu memenuhi jalur pengeluaran yang telah didefinisikan sebelumnya.
Inilah juga alasan desain “mengklaim transaksi” dan “menantang transaksi” dalam whitepaper. Peminjam ingin mengambil kembali BTC, pertama mengirim claim; kalau tidak ada yang mempertanyakan, setelah timelock lewat langsung berhasil. Tapi jika pemberi pinjaman meragukan ada masalah, ia bisa mengajukan tantangan, memaksa peminjam untuk memamerkan bukti ZK yang ditandatangani pada saat itu—jika bukti valid, maka diloloskan; jika bukti tidak valid, rahasia akan diekstraksi dari rangkaian yang membaur, dan penarikan itu langsung dicegah. Seluruh proses ini tidak melibatkan pihak ketiga yang melakukan arbitrase di rantai Bitcoin; wewenang untuk memutus sudah ditulis dalam kondisi skrip, bukan diserahkan kepada manusia.
Dengan pemahaman ini, TBV sebenarnya tidak mengubah “apakah BTC ada”, melainkan membuat Bitcoin untuk pertama kalinya memiliki kemampuan merespons secara terverifikasi terhadap suatu peristiwa eksternal yang sama sekali tidak bisa dipahaminya sendiri—tidak perlu mempercayai perkataan siapa pun, cukup memverifikasi apakah bukti itu memenuhi syarat.
Untuk berapa lama jendela tantangannya dikunci waktunya, aku tidak menemukan angka yang seragam di dokumen; mungkin setiap aplikasi integrasinya menetapkan sendiri. Bagian itu sementara belum sempat kucek. Jika kamu yang harus mendesain durasi jendela tantangan ini, kamu cenderung menyimpannya lebih lama demi keamanan, atau lebih singkat demi pengalaman pengguna?#baby $BABY
Dulu pemahamanku adalah pasti ada semacam oracle yang mengawasi; lalu kirim sinyal dari luar rantai, di atas rantai langsung dieksekusi. Setelah kucermati, ternyata bukan begitu—cara TBV justru kebalikannya: bukan membuat Bitcoin secara aktif merasakan apa yang terjadi di chain inang, tetapi pihak yang ingin menggunakan BTC sendiri harus menerjemahkan peristiwa yang sudah terjadi di chain inang menjadi sebuah bukti kriptografis yang bisa diverifikasi oleh skrip Bitcoin, lalu mengirimkannya.
Skrip itu sendiri dari awal sampai akhir tidak memahami pinjam-meminjam, tidak memahami kliring, tidak memahami harga—ia hanya melakukan satu hal: memverifikasi apakah bukti itu memenuhi jalur pengeluaran yang telah didefinisikan sebelumnya.
Inilah juga alasan desain “mengklaim transaksi” dan “menantang transaksi” dalam whitepaper. Peminjam ingin mengambil kembali BTC, pertama mengirim claim; kalau tidak ada yang mempertanyakan, setelah timelock lewat langsung berhasil. Tapi jika pemberi pinjaman meragukan ada masalah, ia bisa mengajukan tantangan, memaksa peminjam untuk memamerkan bukti ZK yang ditandatangani pada saat itu—jika bukti valid, maka diloloskan; jika bukti tidak valid, rahasia akan diekstraksi dari rangkaian yang membaur, dan penarikan itu langsung dicegah. Seluruh proses ini tidak melibatkan pihak ketiga yang melakukan arbitrase di rantai Bitcoin; wewenang untuk memutus sudah ditulis dalam kondisi skrip, bukan diserahkan kepada manusia.
Dengan pemahaman ini, TBV sebenarnya tidak mengubah “apakah BTC ada”, melainkan membuat Bitcoin untuk pertama kalinya memiliki kemampuan merespons secara terverifikasi terhadap suatu peristiwa eksternal yang sama sekali tidak bisa dipahaminya sendiri—tidak perlu mempercayai perkataan siapa pun, cukup memverifikasi apakah bukti itu memenuhi syarat.
Untuk berapa lama jendela tantangannya dikunci waktunya, aku tidak menemukan angka yang seragam di dokumen; mungkin setiap aplikasi integrasinya menetapkan sendiri. Bagian itu sementara belum sempat kucek. Jika kamu yang harus mendesain durasi jendela tantangan ini, kamu cenderung menyimpannya lebih lama demi keamanan, atau lebih singkat demi pengalaman pengguna?#baby $BABY