(Sumber: companiesmarketcap)
Bitcoin, yang dibuat pada tahun 2008 oleh pengembang yang anonim, telah tumbuh menjadi aset besar, menempati peringkat ke-7 dalam kapitalisasi pasar di antara semua kelas aset. Saat ini, Bitcoin diakui tidak hanya oleh lembaga keuangan tetapi bahkan oleh Presiden AS. Saat ini, kapitalisasi pasar Bitcoin mirip dengan perak. Mengingat adopsi Bitcoin masih relatif rendah dan bahwa kapitalisasi pasarnya hanya sepersepuluh dari emas, potensi pertumbuhannya di masa depan tetap sangat menjanjikan.
Meskipun pertumbuhan Bitcoin sebagai aset sangat besar, masih ada kekurangan signifikan—tingkat penggunaannya. Aset tradisional seperti saham dan obligasi dapat digunakan dalam berbagai produk keuangan, tetapi aplikasi keuangan Bitcoin masih sangat terbatas, baik secara teknis maupun praktis. Seperti masa-masa perbatasan di Amerika Barat, Bitcoin mewakili tanah oportunis yang belum dimanfaatkan.
Dikarenakan kapitalisasi pasar yang sangat besar, banyak perusahaan dan protokol telah berupaya memanfaatkan Bitcoin untuk penciptaan kredit tambahan. Upaya utama untuk memanfaatkan BTC sejauh ini mencakup:
Menguji upaya-upaya untuk menggunakan BTC ini mengungkapkan sebuah tantangan umum—menggunakan Bitcoin secara langsung sangat sulit. Salah satu kelebihan terbesar Bitcoin adalah keamanannya, tetapi jika asumsi kepercayaan tambahan melemahkan keamanan ini, hal itu menciptakan hambatan masuk yang signifikan bagi pemegang BTC. Ini adalah alasan utama mengapa tingkat pemanfaatan Bitcoin relatif rendah.
Ini adalah tempat @babylonlabs_iomasuk ke dalam fokus. Babylon memungkinkan pemegang BTC untuk melakukan staking Bitcoin mereka secara alami pada jaringan Bitcoin dan berpartisipasi dalam memvalidasi protokol PoS lainnya, sehingga mendapatkan imbalan tambahan.
Berkat keunggulan menggunakan BTC tanpa asumsi kepercayaan tambahan, Babylon dengan cepat mencapai lebih dari $5 miliar dalam TVL. TVL bisa jadi lebih tinggi jika tidak ada batasan staking pada BTC.
Tunggu dulu, bahasa pemrograman Bitcoin tidak lengkap Turing, yang berarti tidak dapat dengan mudah mendukung kontrak pintar yang kompleks. Jadi, bagaimana Babylon berhasil mencapai fungsionalitas ini? Dalam artikel ini, kami akan menjelajahi mekanisme khusus di balik operasi Babylon.
Seperti membangun Menara Babel, apakah kita bisa mencapai penggunaan BTC asli yang sebenarnya?
Misi Babylon adalah memperluas Bitcoin untuk mengamankan dunia terdesentralisasi. Meskipun dikenal luas sebagai protokol staking BTC, Babylon juga menawarkan layanan penanda waktu Bitcoin, membentuk rangkaian protokol berbagi keamanan BTC.
Babylon terdiri dari dua protokol utama:
(Sumber: Babylon)
Arsitektur fundamental dari Babylon diilustrasikan dalam diagram di atas, dengan Babylon Chain, yang dibangun di atas Cosmos SDK, sebagai inti. Selain Babylon Chain, beberapa program perifer memfasilitasi staking BTC dan komunikasi dengan Bitcoin dan Zona Konsumen lainnya. Zona Konsumen mengacu pada rantai PoS yang mencatat titik kontrol pada jaringan Bitcoin melalui Babylon.
Rantai Babylon terdiri dari berbagai modul yang melakukan fungsi-fungsi penting dalam ekosistem, termasuk mengelola set validator, melacak header blok Bitcoin, mengirimkan checkpoint ke jaringan Bitcoin, dan mengelola set penyedia finalitas aktif yang terkait dengan penjatahan BTC. Untuk referensi, penyedia finalitas mirip dengan operator AVS dalam EigenLayer, yang berarti ia berpartisipasi dalam validasi protokol PoS lainnya.
Selain itu, Babylon telah mengimplementasikan beberapa program pendukung untuk memfasilitasi komunikasi lancar antara jaringan Bitcoin dan Babylon Chain:
Melalui ekosistem ini, Babylon memungkinkan industri kripto untuk memanfaatkan keamanan yang kuat dan likuiditas yang dalam dari Bitcoin. Sekarang, mari kita telusuri dua fitur inti dari Babylon secara lebih detail: Timestamping Bitcoin dan Staking Bitcoin.
Siapa pun yang telah melakukan staking token sebelumnya pasti tahu bahwa melepaskan staking biasanya memerlukan periode penantian selama 1 hingga 2 minggu. Selama periode ini, token tidak dapat digunakan atau menghasilkan bunga, menyebabkan ketidak efisienan. Tetapi mengapa melepaskan staking memerlukan periode penantian? Mengapa tidak memperbolehkan penarikan instan?
Alasan paling sederhana adalah keamanan jaringan. Jika pembatalan staking instan, sejumlah besar token dapat dibatalkan dalam menanggapi fluktuasi pasar, signifikan melemahkan keamanan jaringan. Namun, di luar keamanan, ada alasan fundamental lainnya: untuk mencegah serangan jarak jauh.
(Sumber: AP)
Serangan jarak jauh merujuk pada serangan di mana validator jahat membuat cabang baru yang dimulai dari blok-blok sebelumnya, mencoba untuk menggantikan rantai kanonikal saat ini. Jika rantai bercabang jahat menjadi sama panjang atau lebih panjang dari rantai kanonikal, node-node baru yang bergabung dalam jaringan mungkin menjadi bingung tentang rantai mana yang sah, menyebabkan masalah potensial. Tapi tunggu—apakah ini bahkan mungkin?
Dalam jaringan PoW, serangan jarak jauh hampir tidak mungkin. Untuk mengejar rantai kanonikal saat ini, penyerang perlu membuat ulang blok-blok baru dari masa lalu sambil melebihi kekuatan komputasi jaringan yang ada, yang dalam praktiknya tidak mungkin.
Demikian pula, dalam jaringan PoS yang berfungsi dengan baik, serangan ini juga tidak mungkin terjadi. Membuat fork baru akan memerlukan validator jahat untuk menandatangani beberapa blok yang bertentangan, yang dianggap sebagai tindakan double-signing—sebuah pelanggaran terhadap protokol yang mengakibatkan hukuman pemangkasan.
Namun, bagaimana jika pengambilan staking diizinkan segera?
Berbeda dengan jaringan PoW, jaringan PoS tidak memerlukan daya komputasi yang besar untuk menghasilkan blok. Ini berarti bahwa jika validator jahat menarik kembali aset mereka dari rantai yang ada dan kemudian membuat rantai bercabang baru dari blok masa lalu di mana kunci validator mereka masih valid, mereka berpotensi dapat mengejar rantai kanonikal saat ini. Dalam skenario ini, node-node yang bergabung baru dalam jaringan mungkin kesulitan menentukan rantai mana yang merupakan yang sah, menyebabkan kebingungan dan risiko keamanan potensial.
(Sumber: Babilon)
Jika serangan jarak jauh berhasil, validator jahat dapat mengeksploitasi mekanisme jembatan untuk mencuri dana. Sebagai contoh, misalkan seorang penyerang jahat bernama John mentransfer 1M token RUG dari rantai RugPull ke Osmosis dan menukarnya dengan token OSMO. Transfer ini terjadi melalui IBC, yang bekerja dengan mengunci token RUG asli pada rantai RugPull sambil membuat jumlah RUG yang setara pada rantai Osmosis.
(Sumber: Babylon)
Jika kita mengasumsikan bahwa John berhasil melakukan serangan jarak jauh pada rantai RugPull, dia dapat dengan jahat menghilangkan transaksi yang mengunci token RUG untuk mengirimnya ke rantai Osmosis dalam rantai yang di-fork baru. Sebagai hasilnya, John akan efektif memperoleh token OSMO secara gratis.
Untuk mencegah serangan jarak jauh, periode unbonding taruhan dengan durasi tertentu diperlukan. Pelaku jahat tidak dapat melakukan serangan jarak jauh selama periode unbonding (jika mereka mencoba, mereka akan menghadapi hukuman slashing). Selain itu, selama periode ini, peserta jaringan dapat mencapai konsensus sosial mengenai rantai mana yang merupakan rantai kanonikal. Sebagai hasilnya, bahkan jika serangan jarak jauh terjadi kemudian, rantai bercabang yang jahat kemungkinan besar tidak akan diterima oleh jaringan.
Periode unbonding taruhan adalah metode yang efektif untuk mencegah serangan jarak jauh, tetapi memiliki beberapa kekurangan.
Masalah pertama adalah bahwa ia bergantung pada konsensus sosial untuk melawan serangan. Sementara komunikasi di luar rantai di antara peserta dalam jangka waktu yang cukup lama dapat memainkan peran penting, ini bukanlah solusi yang 100% aman.
Isu kedua adalah bahwa, seperti yang disebutkan sebelumnya, periode penarikan yang lebih lama berdampak negatif pada pengalaman pengguna dan likuiditas.
Babylon memperkenalkan solusi yang disebut Bitcoin Timestamping, yang memungkinkan rantai PoS untuk secara signifikan mengurangi periode penarikan hanya dalam beberapa jam. Hal ini memungkinkan rantai PoS untuk mencatat data blok rantai kanonikal ke jaringan Bitcoin.
Dengan penanda waktu, bahkan jika validator jahat mencoba serangan jarak jauh dan mengklaim rantai bercabang mereka sebagai rantai kanonikal, serangan mereka tidak akan berhasil—karena data rantai kanonikal asli sudah tercatat secara aman di jaringan Bitcoin. Selama keamanan Bitcoin tetap utuh, serangan pasti akan gagal. Karena pendekatan ini menghilangkan kebutuhan akan konsensus sosial, ini memungkinkan pengurangan drastis dalam periode unbonding yang diperlukan.
(Sumber: Babylon)
Di sini, Bitcoin Timestamping dicatat menggunakan opcode OP_RETURN di jaringan Bitcoin. OP_RETURN adalah instruksi yang memungkinkan penyimpanan hingga 80 byte data sembarangan di jaringan Bitcoin. Berbeda dengan transaksi Bitcoin reguler, OP_RETURN tidak dapat digunakan untuk transfer dana dan tidak menghasilkan UTXO.
Salah satu pertimbangan utama adalah apakah semua rantai PoS dapat langsung membuat checkpoint pada jaringan Bitcoin. Blok Bitcoin berukuran kecil, memiliki waktu blok 10 menit, dan OP_RETURN hanya dapat menyimpan maksimal 80 byte data. Jika banyak rantai PoS mengirim transaksi checkpointing secara sering, jaringan Bitcoin tidak akan mampu menangani beban tersebut.
Untuk menyelesaikan masalah ini, Babylon memperkenalkan Babylon Chain, yang menggabungkan titik kontrol dari beberapa rantai PoS melalui IBC dan kemudian mengirimkan satu titik kontrol yang tergabung ke jaringan Bitcoin.
Komponen kunci dari proses ini adalah Vigilante Relayer, sebuah entitas yang bertanggung jawab untuk membaca checkpoint dari node Babylon, mengemasnya ke dalam transaksi OP_RETURN, dan kemudian mengirimkannya ke jaringan Bitcoin. Sistem ini memerlukan setidaknya satu Vigilante Relayer yang jujur dan aktif untuk berfungsi dengan baik.
(Sumber: Babylon)
Pencatat waktu BTC terjadi sebagai berikut: Rantai PoS mengirimkan checkpoint yang berisi informasi blok ke rantai Babylon. Rantai Babylon kemudian mengirimkan checkpoint blok Babylon ke jaringan Bitcoin pada blok terakhir setiap zaman.
(Sumber: Babilon)
Bahkan jika serangan jarak jauh terjadi, checkpoint rantai bercabang jahat akan selalu memiliki timestamp yang lebih lambat daripada checkpoint rantai kanonikal. Ini berarti peserta jaringan dapat dengan mudah memeriksa checkpoint jaringan Bitcoin untuk mengidentifikasi fork yang jahat. Karena pendekatan ini menghilangkan kebutuhan akan konsensus sosial, periode pemisahan taruhan dapat dikurangi dari beberapa minggu menjadi hanya beberapa jam.
Timestamp Bitcoin di Babylon tidak hanya meningkatkan UX dan efisiensi likuiditas dengan mengurangi periode unstaking rantai PoS, tetapi juga memberikan berbagai manfaat tambahan.
Dengan mengadopsi finalitas yang lambat melalui Babylon, rantai PoS dapat mencapai tingkat keamanan yang dapat dibandingkan dengan Bitcoin. Ketika blok PoS yang berisi transaksi spesifik ditandai waktu di jaringan Bitcoin dan dikonfirmasi oleh enam blok Bitcoin, transaksi tersebut menjadi tidak dapat dibalikkan—selama keamanan Bitcoin tetap utuh.
Mekanisme ini berguna untuk memproses transaksi bernilai tinggi, seperti pembelian real estat, di mana keamanan mutlak diperlukan. Selain itu, untuk zona Cosmos yang baru diluncurkan, yang mungkin memiliki keamanan yang lebih lemah, menerapkan finalitas lambat dapat memberikan lapisan perlindungan tambahan untuk pemrosesan transaksi yang aman.
Pencacatan Waktu Bitcoin juga dapat membantu mengembalikan kehidupan dalam kasus serangan sensorship pada rantai PoS. Untuk mengatasi hal ini, Babylon memperkenalkan konsep khusus yang disebut mode rollup.
Dalam rantai PoS tradisional, setidaknya dua pertiga (2/3) validator harus jujur untuk menjaga ketahanan sensor. Namun, dengan mode rollup Babylon, hanya setengah (1/2) validator perlu jujur untuk mencapai ketahanan sensor, secara signifikan meningkatkan ketahanan rantai terhadap serangan.
(Sumber: Babylon)
Jika seorang pengguna rantai PoS meyakini bahwa suatu transaksi tertentu sedang disensor, mereka dapat mengajukan keluhan sensor (bagian merah dalam diagram) ke rantai Babylon, memulai proses masuk ke mode rollup. Keluhan sensor berisi hash transaksi yang disensor.
Jika, setelah enam konfirmasi blok Bitcoin, transaksi yang dicurigai disensor masih belum disertakan dalam rantai PoS, validator jujur akan mengirimkan pandangan mereka tentang rantai PoS ke Babylon. Jika, setelah enam konfirmasi blok Bitcoin tambahan, tidak ada checkpoint terkait transaksi yang disensor yang terdeteksi di blok Bitcoin mana pun, validator dan pengguna jujur akan memasuki mode rollup.
Dalam mode rollup, validator mana pun dapat mengusulkan bundel transaksi PoS, dan jika validator yang memiliki setidaknya separuh (1/2) dari total staking menandatangani bundel tersebut, transaksi akan difinalisasi di jaringan Bitcoin, efektif mencegah sensorship.
Timestamp Bitcoin memungkinkan rantai PoS memanfaatkan keamanan Bitcoin untuk mengurangi periode pembatalan staking dan meningkatkan ketahanan sensor, tetapi ini hanya sebagian memanfaatkan keamanan Bitcoin.
Selain Penstempelan Timestamping Bitcoin, Babylon memperkenalkan Bitcoin Staking, yang mengimplementasikan staking BTC secara langsung menggunakan bahasa script Bitcoin. Hal ini memungkinkan protokol PoS lainnya mendapatkan manfaat dari keamanan kripto ekonomi BTC yang dipertaruhkan. Protokol staking dirancang sebagai plug-in modular, sehingga mudah disesuaikan untuk berbagai protokol konsensus PoS.
Bagi pemegang BTC, Penjatahan Bitcoin Babylon adalah peluang investasi yang menarik karena mereka dapat melakukan penjatahan BTC pada tingkat keamanan Bitcoin tanpa bergantung pada entitas eksternal, sambil juga mendapatkan imbalan dari protokol eksternal.
Mari tentukan beberapa istilah kunci:
Tapi tunggu—berbeda dengan Ethereum, jaringan Bitcoin tidak Turing lengkap, sehingga sulit untuk menerapkan kontrak staking yang kompleks. Lalu bagaimana Babylon mencapainya?
Mari kita jelajahi detail dengan contoh dari blog Babylon.
// Kontrak V0: menambahkan kondisi penguncian pada UTXO staking milik Alice
kondisi-1 (penguncian): time_lock = 1000 & kunci_publik_alice
Mari kita asumsikan bahwa Alice melakukan staking BTC dan juga bertindak sebagai Penyedia Finality. Untuk menerapkan staking BTC, diperlukan mekanisme untuk mengunci BTC. Hal ini dicapai dengan mengatur salah satu kondisi pengeluaran UTXO sehingga hanya Alice (pemilik BTC) yang dapat menarik dana setelah jangka waktu tertentu (time_lock = 1000) menggunakan kunci publik miliknya, alice_public_key.
// Kontrak V1: menambahkan pengurangan secara naif
kondisi-1 (penguncian): time_lock = 1000 & alice_public_key; ATAU
kondisi-2 (slashing): kunci_publik_alice_eots
Salah satu komponen penting yang harus diimplementasikan dalam staking adalah slashing. Jika tindakan jahat terjadi, mekanisme insentif dapat diberlakukan dengan membakar BTC yang dipertaruhkan. Untuk mencapai hal ini, kondisi pengeluaran UTXO kedua ditetapkan sehingga slashing dapat terjadi jika seseorang memegang kunci EOTS Alice.
Di sini, EOTS (Extractable One-Time Signature) adalah tanda tangan yang diimplementasikan menggunakan tanda tangan Schnorr, yang diperkenalkan setelah upgrade Taproot Bitcoin. Singkatnya, ini adalah algoritma yang memastikan bahwa jika pelaku jahat melakukan double-sign dua blok yang berbeda pada ketinggian yang sama menggunakan kunci yang sama, kunci rahasianya akan terungkap secara publik.
Jika dilihat lebih detail, tanda tangan Schnorr terdiri dari kunci privat x, kunci publik P=xG, dan nonce acak k. Prosedur penandatanganan adalah sebagai berikut: nonce acak k dihasilkan, dan nilai publik R=kG dihitung dari nonce tersebut. Kemudian, nilai hash e dihitung dari pesan M dan R, dan nilai tanda tangan s dihitung berdasarkan nonce dan e, di mana s = k + ex. Tanda tangan Schnorr akhir terdiri dari (s, R).
Ide inti dari EOTS adalah bahwa jika kunci yang sama digunakan dua kali untuk menandatangani, kunci pribadi terbuka. Jika Alice menandatangani dua pesan yang berbeda menggunakan nonce yang sama k, maka tanda tangan pertama adalah s1= k + e_1x dan tanda tangan kedua adalah s2= k + e_2x. Karena s1, s2, e1, e2 diketahui secara publik, siapa pun dapat menyelesaikan kunci pribadi x Alice menggunakan persamaan x=(s1 - s2)/(e1 - e2).
Dengan mekanisme ini, jika Alice dengan jahat menandatangani dua pesan yang berbeda menggunakan kunci EOTS yang sama selama proses validasi BSN, siapa pun yang mendeteksinya dapat mengekstrak kunci rahasia EOTS Alice. Begitu kunci rahasia EOTS terungkap, penyerang dapat mencuri BTC yang dipertaruhkan oleh Alice atau membakar BTC yang dipertaruhkan oleh Alice sebagai denda.
// Kontrak V2
kondisi-1 (penguncian): time_lock = 1000 & alice_public_key; ATAU
kondisi-2 (pemotongan): alice_eots_public_key & covenant_committee_quorum
// Transaksi pemangkasan V0
masukan:
keluaran:
0000...0000
// Pra-persetujuan V0: menerapkan pembakaran
Komite Perjanjian telah menandatangani pratinjau awal di atas pemotongan tx sebagai persetujuannya sebelumnya
Karena kita sebelumnya telah membahas kondisi di mana pemotongan terjadi, mari kita sekarang memeriksa bagaimana pemotongan benar-benar ditegakkan. Menegakkan pemotongan adalah sangat penting karena, jika Alice terlibat dalam perilaku jahat, dia mungkin mencoba untuk menarik kembali BTC-nya sebelum seseorang mendeteksi pelanggaran, mengekstrak kunci rahasia EOTS-nya, dan membakar BTC-nya.
Untuk mencegah hal ini, pemangkasan harus dilaksanakan dengan cara yang memaksa transfer BTC ke alamat pembakaran yang telah ditentukan sebelumnya (0000…0000). Untuk mencapai hal ini, kondisi pengeluaran UTXO kedua melibatkan Kuorum Komite Perjanjian. Komite Perjanjian bertanggung jawab untuk memverifikasi apakah pemangkasan tersebut sah. Dengan menggabungkan skema multi-tanda tangan (M-dari-N), sistem memastikan bahwa Alice tidak dapat menarik BTC-nya sendiri ke dompetnya sendiri sebelum pemangkasan dilaksanakan.
Keuntungan dari pendekatan ini adalah bahwa, selama Alice bersikap jujur, tanda tangan EOTS-nya tidak pernah terungkap, artinya Komite Perjanjian tidak dapat menyita dana-dananya. Oleh karena itu, Alice tidak perlu percaya pada Komite Perjanjian, karena mereka tidak dapat bertindak melawannya kecuali dia melakukan perilaku jahat.
// Kontrak V3: memungkinkan delegasi aman
kondisi-1 (penguncian): time_lock = 1000 & alice_public_key; ATAU
kondisi-2 (pemangkasan): kunci_publik_alice & kunci_publik_validator_eots & kuorum_komite_perjanjian
// Memotong transaksi V0
masukan:
keluaran:
0000...0000
// Pra-persetujuan V1
// Alice menandatangani tx pemotongan sebelumnya sebagai persetujuan awalnya.
// Komite Perjanjian memprediksi pemotongan tx saat pra-persetujuan.
Alice dapat langsung melakukan staking BTC dan berpartisipasi dalam memvalidasi protokol PoS lain sebagai penyedia finalitas. Namun, kebanyakan pengguna akan memilih untuk mendelagasikan staking BTC mereka.
Untuk melaksanakan hal ini, menambahkan kunci EOTS validator ke kondisi kedua memastikan bahwa jika validator terlibat dalam perilaku jahat, BTC Alice bisa dibakar. Namun, masalahnya di sini adalah jika validator berkolusi dengan komite perjanjian, mereka bisa mencuri BTC Alice, memaksa Alice untuk percaya pada validator.
Solusi sederhana untuk masalah ini adalah dengan juga menyertakan kunci publik Alice dalam kondisi kedua. Dengan cara ini, membakar BTC akan membutuhkan tanda tangan Alice juga, mencegah pencurian BTC yang tidak sah.
Untuk mencapai hal ini, Alice memprediksi transaksi yang menyatakan bahwa “jika terjadi pemotongan, BTC harus dikirim ke alamat pembakaran.” Dalam hal ini, jika validator bertindak dengan jahat dan kunci EOTS mereka terungkap, dan jika komite kontrak melaksanakan tanda tangan ganda, BTC akan dikirim ke alamat pembakaran, menerapkan proses pemotongan.
/ Kontrak V3
kondisi-1 (penguncian): time_lock = 1000 & kunci_publik_alice; OR
kondisi-2 (pemangkasan): kunci_publik_alice & kunci_publik_validator_eots & kuorum_komite_kovenan
Transaksi pemotongan V0
masukan:
outputs:
0000...0000
// Pra-persetujuan V2: menegakkan pemotongan atomik saat wakil
Pratindakan persetujuan pra-approval Alice adalah tanda tangan adaptor dari transaksi pemotongan
// dia dibuat menggunakan kunci publik EOTS validator.
// Komite perjanjian menandatangani pemotongan tx sebagai persetujuan awalnya.
Bagaimana jika validator jahat menargetkan hanya pemegang yang spesifik untuk dipangkas? Untuk mencegah hal ini, Babylon memperkenalkan Tanda Tangan Adaptor.
Alice mengenkripsi tanda tangannya menggunakan kunci publik EOTS validator sebagai tanda tangan adaptor. Jika validator mencoba mengurangi hanya Alice, mereka harus menggunakan kunci privat EOTS mereka. Karena sifat Tanda Tangan Adaptor, hal ini akan mengakibatkan paparan kunci privat EOTS validator, menghilangkan insentif bagi validator untuk terlibat dalam perilaku berbahaya.
// Kontrak V3
kondisi-1 (penguncian): time_lock = 1000 & alice_public_key; OR
kondisi-2 (pemotongan): kunci_publik_alice & kunci_publik_validator_eots & kuorum_komite_perjanjian
// Transaksi pemangkasan V1: memungkinkan pemangkasan sebagian
masukan:
outputs:
output-1: nilai = 0.09 Bitcoin, pemilik = 0000...0000
output-2: nilai = 0.9 Bitcoin,
kondisi:
// Pra-persetujuan V2
// Pratindakan prakualifikasi Alice adalah tanda tangan adaptor dari pengurangan tx
// dia dihasilkan menggunakan kunci publik EOTS validator.
Komite Perjanjian telah menandatangani pemotongan tx sebagai persetujuan awalnya.
Tapi apakah Anda tidak berpikir bahwa membakar semua Bitcoin dalam kejadian pemangkasan terlalu ekstrim? Untuk mengatasi hal ini, hanya sebagian Bitcoin (misalnya, membakar hanya 10% sambil mengembalikan 90% sisanya setelah jangka waktu tertentu) dapat dibakar. Ini dapat dilaksanakan dengan membagi output transaksi pemangkasan menjadi dua, seperti yang dijelaskan di atas.
// Kontrak V4: Mengaktifkan restaking
kondisi-1 (penguncian): time_lock = 1000 & alice_public_key; ATAU
kondisi-2 (pemangkasan): kunci_publik_alice & tanda_tangan apa pun dari daftar [kunci_publik_validator_eots] & kuorum_komite_perjanjian
BTC yang didelegasikan oleh Alice dapat berpartisipasi dalam validasi beberapa protokol PoS, bukan hanya satu. Jika validator berpartisipasi dalam validasi protokol PoS yang berbeda menggunakan kunci EOTS yang sama, kebocoran di satu tempat dapat memengaruhi sistem lainnya. Oleh karena itu, penyedia finalitas Babylon harus menggunakan kunci EOTS yang berbeda untuk sistem PoS yang berbeda, dan daftar kunci EOTS diperkenalkan dalam kondisi kedua.
Tidak seperti jaringan PoS seperti Ethereum atau Solana, jaringan Bitcoin beroperasi dengan PoW, sehingga konsep staking tidak ada secara inheren. Namun, Babylon telah menerapkan fitur penguncian BTC, pemotongan, dan delegasi yang diperlukan untuk staking melalui karakteristik UTXOs, bahasa scripting Bitcoin, dan berbagai algoritma tanda tangan. Ini memungkinkan pemegang BTC untuk mendapatkan keuntungan tambahan secara alami dengan memanfaatkan BTC, tanpa perlu jembatan atau layanan asuhan.
Selain Jaringan Lightning, tidak ada protokol lain yang sepenuhnya mewarisi keamanan jaringan Bitcoin. Namun, sama seperti jaringan Bitcoin, fungsionalitas Jaringan Lightning sangat terbatas, dan terlalu berharga untuk menyerah pada keamanan yang kuat dan likuiditas besar Bitcoin.
Babylon telah memungkinkan penggunaan keamanan Bitcoin dalam dua cara berbeda melalui Penanda Waktu Bitcoin dan Staking Bitcoin. Yang pertama menggunakan Bitcoin sebagai server penanda waktu untuk mencegah pembatalan transaksi atau fork jahat, sementara yang terakhir memanfaatkan likuiditas BTC yang kuat sebagai keamanan kripto-ekonomi, memungkinkan pemegang BTC untuk mendapatkan keuntungan tambahan dengan cara yang alami.
Saat ini, sekitar 55.000 BTC disimpan di Babylon, yang bahkan sebanding dengan batas deposit yang ditetapkan oleh Babylon. Sekitar 3,9% dari total pasokan ETH di-stake kembali di EigenLayer. Mengingat hal ini, meskipun pemegang BTC mungkin konservatif dalam memanfaatkan BTC, potensi pertumbuhan Babylon, dengan hanya sekitar 0,2% dari total pasokan BTC saat ini yang di-stake, layak dipertimbangkan.
(Sumber: companiesmarketcap)
Bitcoin, yang dibuat pada tahun 2008 oleh pengembang yang anonim, telah tumbuh menjadi aset besar, menempati peringkat ke-7 dalam kapitalisasi pasar di antara semua kelas aset. Saat ini, Bitcoin diakui tidak hanya oleh lembaga keuangan tetapi bahkan oleh Presiden AS. Saat ini, kapitalisasi pasar Bitcoin mirip dengan perak. Mengingat adopsi Bitcoin masih relatif rendah dan bahwa kapitalisasi pasarnya hanya sepersepuluh dari emas, potensi pertumbuhannya di masa depan tetap sangat menjanjikan.
Meskipun pertumbuhan Bitcoin sebagai aset sangat besar, masih ada kekurangan signifikan—tingkat penggunaannya. Aset tradisional seperti saham dan obligasi dapat digunakan dalam berbagai produk keuangan, tetapi aplikasi keuangan Bitcoin masih sangat terbatas, baik secara teknis maupun praktis. Seperti masa-masa perbatasan di Amerika Barat, Bitcoin mewakili tanah oportunis yang belum dimanfaatkan.
Dikarenakan kapitalisasi pasar yang sangat besar, banyak perusahaan dan protokol telah berupaya memanfaatkan Bitcoin untuk penciptaan kredit tambahan. Upaya utama untuk memanfaatkan BTC sejauh ini mencakup:
Menguji upaya-upaya untuk menggunakan BTC ini mengungkapkan sebuah tantangan umum—menggunakan Bitcoin secara langsung sangat sulit. Salah satu kelebihan terbesar Bitcoin adalah keamanannya, tetapi jika asumsi kepercayaan tambahan melemahkan keamanan ini, hal itu menciptakan hambatan masuk yang signifikan bagi pemegang BTC. Ini adalah alasan utama mengapa tingkat pemanfaatan Bitcoin relatif rendah.
Ini adalah tempat @babylonlabs_iomasuk ke dalam fokus. Babylon memungkinkan pemegang BTC untuk melakukan staking Bitcoin mereka secara alami pada jaringan Bitcoin dan berpartisipasi dalam memvalidasi protokol PoS lainnya, sehingga mendapatkan imbalan tambahan.
Berkat keunggulan menggunakan BTC tanpa asumsi kepercayaan tambahan, Babylon dengan cepat mencapai lebih dari $5 miliar dalam TVL. TVL bisa jadi lebih tinggi jika tidak ada batasan staking pada BTC.
Tunggu dulu, bahasa pemrograman Bitcoin tidak lengkap Turing, yang berarti tidak dapat dengan mudah mendukung kontrak pintar yang kompleks. Jadi, bagaimana Babylon berhasil mencapai fungsionalitas ini? Dalam artikel ini, kami akan menjelajahi mekanisme khusus di balik operasi Babylon.
Seperti membangun Menara Babel, apakah kita bisa mencapai penggunaan BTC asli yang sebenarnya?
Misi Babylon adalah memperluas Bitcoin untuk mengamankan dunia terdesentralisasi. Meskipun dikenal luas sebagai protokol staking BTC, Babylon juga menawarkan layanan penanda waktu Bitcoin, membentuk rangkaian protokol berbagi keamanan BTC.
Babylon terdiri dari dua protokol utama:
(Sumber: Babylon)
Arsitektur fundamental dari Babylon diilustrasikan dalam diagram di atas, dengan Babylon Chain, yang dibangun di atas Cosmos SDK, sebagai inti. Selain Babylon Chain, beberapa program perifer memfasilitasi staking BTC dan komunikasi dengan Bitcoin dan Zona Konsumen lainnya. Zona Konsumen mengacu pada rantai PoS yang mencatat titik kontrol pada jaringan Bitcoin melalui Babylon.
Rantai Babylon terdiri dari berbagai modul yang melakukan fungsi-fungsi penting dalam ekosistem, termasuk mengelola set validator, melacak header blok Bitcoin, mengirimkan checkpoint ke jaringan Bitcoin, dan mengelola set penyedia finalitas aktif yang terkait dengan penjatahan BTC. Untuk referensi, penyedia finalitas mirip dengan operator AVS dalam EigenLayer, yang berarti ia berpartisipasi dalam validasi protokol PoS lainnya.
Selain itu, Babylon telah mengimplementasikan beberapa program pendukung untuk memfasilitasi komunikasi lancar antara jaringan Bitcoin dan Babylon Chain:
Melalui ekosistem ini, Babylon memungkinkan industri kripto untuk memanfaatkan keamanan yang kuat dan likuiditas yang dalam dari Bitcoin. Sekarang, mari kita telusuri dua fitur inti dari Babylon secara lebih detail: Timestamping Bitcoin dan Staking Bitcoin.
Siapa pun yang telah melakukan staking token sebelumnya pasti tahu bahwa melepaskan staking biasanya memerlukan periode penantian selama 1 hingga 2 minggu. Selama periode ini, token tidak dapat digunakan atau menghasilkan bunga, menyebabkan ketidak efisienan. Tetapi mengapa melepaskan staking memerlukan periode penantian? Mengapa tidak memperbolehkan penarikan instan?
Alasan paling sederhana adalah keamanan jaringan. Jika pembatalan staking instan, sejumlah besar token dapat dibatalkan dalam menanggapi fluktuasi pasar, signifikan melemahkan keamanan jaringan. Namun, di luar keamanan, ada alasan fundamental lainnya: untuk mencegah serangan jarak jauh.
(Sumber: AP)
Serangan jarak jauh merujuk pada serangan di mana validator jahat membuat cabang baru yang dimulai dari blok-blok sebelumnya, mencoba untuk menggantikan rantai kanonikal saat ini. Jika rantai bercabang jahat menjadi sama panjang atau lebih panjang dari rantai kanonikal, node-node baru yang bergabung dalam jaringan mungkin menjadi bingung tentang rantai mana yang sah, menyebabkan masalah potensial. Tapi tunggu—apakah ini bahkan mungkin?
Dalam jaringan PoW, serangan jarak jauh hampir tidak mungkin. Untuk mengejar rantai kanonikal saat ini, penyerang perlu membuat ulang blok-blok baru dari masa lalu sambil melebihi kekuatan komputasi jaringan yang ada, yang dalam praktiknya tidak mungkin.
Demikian pula, dalam jaringan PoS yang berfungsi dengan baik, serangan ini juga tidak mungkin terjadi. Membuat fork baru akan memerlukan validator jahat untuk menandatangani beberapa blok yang bertentangan, yang dianggap sebagai tindakan double-signing—sebuah pelanggaran terhadap protokol yang mengakibatkan hukuman pemangkasan.
Namun, bagaimana jika pengambilan staking diizinkan segera?
Berbeda dengan jaringan PoW, jaringan PoS tidak memerlukan daya komputasi yang besar untuk menghasilkan blok. Ini berarti bahwa jika validator jahat menarik kembali aset mereka dari rantai yang ada dan kemudian membuat rantai bercabang baru dari blok masa lalu di mana kunci validator mereka masih valid, mereka berpotensi dapat mengejar rantai kanonikal saat ini. Dalam skenario ini, node-node yang bergabung baru dalam jaringan mungkin kesulitan menentukan rantai mana yang merupakan yang sah, menyebabkan kebingungan dan risiko keamanan potensial.
(Sumber: Babilon)
Jika serangan jarak jauh berhasil, validator jahat dapat mengeksploitasi mekanisme jembatan untuk mencuri dana. Sebagai contoh, misalkan seorang penyerang jahat bernama John mentransfer 1M token RUG dari rantai RugPull ke Osmosis dan menukarnya dengan token OSMO. Transfer ini terjadi melalui IBC, yang bekerja dengan mengunci token RUG asli pada rantai RugPull sambil membuat jumlah RUG yang setara pada rantai Osmosis.
(Sumber: Babylon)
Jika kita mengasumsikan bahwa John berhasil melakukan serangan jarak jauh pada rantai RugPull, dia dapat dengan jahat menghilangkan transaksi yang mengunci token RUG untuk mengirimnya ke rantai Osmosis dalam rantai yang di-fork baru. Sebagai hasilnya, John akan efektif memperoleh token OSMO secara gratis.
Untuk mencegah serangan jarak jauh, periode unbonding taruhan dengan durasi tertentu diperlukan. Pelaku jahat tidak dapat melakukan serangan jarak jauh selama periode unbonding (jika mereka mencoba, mereka akan menghadapi hukuman slashing). Selain itu, selama periode ini, peserta jaringan dapat mencapai konsensus sosial mengenai rantai mana yang merupakan rantai kanonikal. Sebagai hasilnya, bahkan jika serangan jarak jauh terjadi kemudian, rantai bercabang yang jahat kemungkinan besar tidak akan diterima oleh jaringan.
Periode unbonding taruhan adalah metode yang efektif untuk mencegah serangan jarak jauh, tetapi memiliki beberapa kekurangan.
Masalah pertama adalah bahwa ia bergantung pada konsensus sosial untuk melawan serangan. Sementara komunikasi di luar rantai di antara peserta dalam jangka waktu yang cukup lama dapat memainkan peran penting, ini bukanlah solusi yang 100% aman.
Isu kedua adalah bahwa, seperti yang disebutkan sebelumnya, periode penarikan yang lebih lama berdampak negatif pada pengalaman pengguna dan likuiditas.
Babylon memperkenalkan solusi yang disebut Bitcoin Timestamping, yang memungkinkan rantai PoS untuk secara signifikan mengurangi periode penarikan hanya dalam beberapa jam. Hal ini memungkinkan rantai PoS untuk mencatat data blok rantai kanonikal ke jaringan Bitcoin.
Dengan penanda waktu, bahkan jika validator jahat mencoba serangan jarak jauh dan mengklaim rantai bercabang mereka sebagai rantai kanonikal, serangan mereka tidak akan berhasil—karena data rantai kanonikal asli sudah tercatat secara aman di jaringan Bitcoin. Selama keamanan Bitcoin tetap utuh, serangan pasti akan gagal. Karena pendekatan ini menghilangkan kebutuhan akan konsensus sosial, ini memungkinkan pengurangan drastis dalam periode unbonding yang diperlukan.
(Sumber: Babylon)
Di sini, Bitcoin Timestamping dicatat menggunakan opcode OP_RETURN di jaringan Bitcoin. OP_RETURN adalah instruksi yang memungkinkan penyimpanan hingga 80 byte data sembarangan di jaringan Bitcoin. Berbeda dengan transaksi Bitcoin reguler, OP_RETURN tidak dapat digunakan untuk transfer dana dan tidak menghasilkan UTXO.
Salah satu pertimbangan utama adalah apakah semua rantai PoS dapat langsung membuat checkpoint pada jaringan Bitcoin. Blok Bitcoin berukuran kecil, memiliki waktu blok 10 menit, dan OP_RETURN hanya dapat menyimpan maksimal 80 byte data. Jika banyak rantai PoS mengirim transaksi checkpointing secara sering, jaringan Bitcoin tidak akan mampu menangani beban tersebut.
Untuk menyelesaikan masalah ini, Babylon memperkenalkan Babylon Chain, yang menggabungkan titik kontrol dari beberapa rantai PoS melalui IBC dan kemudian mengirimkan satu titik kontrol yang tergabung ke jaringan Bitcoin.
Komponen kunci dari proses ini adalah Vigilante Relayer, sebuah entitas yang bertanggung jawab untuk membaca checkpoint dari node Babylon, mengemasnya ke dalam transaksi OP_RETURN, dan kemudian mengirimkannya ke jaringan Bitcoin. Sistem ini memerlukan setidaknya satu Vigilante Relayer yang jujur dan aktif untuk berfungsi dengan baik.
(Sumber: Babylon)
Pencatat waktu BTC terjadi sebagai berikut: Rantai PoS mengirimkan checkpoint yang berisi informasi blok ke rantai Babylon. Rantai Babylon kemudian mengirimkan checkpoint blok Babylon ke jaringan Bitcoin pada blok terakhir setiap zaman.
(Sumber: Babilon)
Bahkan jika serangan jarak jauh terjadi, checkpoint rantai bercabang jahat akan selalu memiliki timestamp yang lebih lambat daripada checkpoint rantai kanonikal. Ini berarti peserta jaringan dapat dengan mudah memeriksa checkpoint jaringan Bitcoin untuk mengidentifikasi fork yang jahat. Karena pendekatan ini menghilangkan kebutuhan akan konsensus sosial, periode pemisahan taruhan dapat dikurangi dari beberapa minggu menjadi hanya beberapa jam.
Timestamp Bitcoin di Babylon tidak hanya meningkatkan UX dan efisiensi likuiditas dengan mengurangi periode unstaking rantai PoS, tetapi juga memberikan berbagai manfaat tambahan.
Dengan mengadopsi finalitas yang lambat melalui Babylon, rantai PoS dapat mencapai tingkat keamanan yang dapat dibandingkan dengan Bitcoin. Ketika blok PoS yang berisi transaksi spesifik ditandai waktu di jaringan Bitcoin dan dikonfirmasi oleh enam blok Bitcoin, transaksi tersebut menjadi tidak dapat dibalikkan—selama keamanan Bitcoin tetap utuh.
Mekanisme ini berguna untuk memproses transaksi bernilai tinggi, seperti pembelian real estat, di mana keamanan mutlak diperlukan. Selain itu, untuk zona Cosmos yang baru diluncurkan, yang mungkin memiliki keamanan yang lebih lemah, menerapkan finalitas lambat dapat memberikan lapisan perlindungan tambahan untuk pemrosesan transaksi yang aman.
Pencacatan Waktu Bitcoin juga dapat membantu mengembalikan kehidupan dalam kasus serangan sensorship pada rantai PoS. Untuk mengatasi hal ini, Babylon memperkenalkan konsep khusus yang disebut mode rollup.
Dalam rantai PoS tradisional, setidaknya dua pertiga (2/3) validator harus jujur untuk menjaga ketahanan sensor. Namun, dengan mode rollup Babylon, hanya setengah (1/2) validator perlu jujur untuk mencapai ketahanan sensor, secara signifikan meningkatkan ketahanan rantai terhadap serangan.
(Sumber: Babylon)
Jika seorang pengguna rantai PoS meyakini bahwa suatu transaksi tertentu sedang disensor, mereka dapat mengajukan keluhan sensor (bagian merah dalam diagram) ke rantai Babylon, memulai proses masuk ke mode rollup. Keluhan sensor berisi hash transaksi yang disensor.
Jika, setelah enam konfirmasi blok Bitcoin, transaksi yang dicurigai disensor masih belum disertakan dalam rantai PoS, validator jujur akan mengirimkan pandangan mereka tentang rantai PoS ke Babylon. Jika, setelah enam konfirmasi blok Bitcoin tambahan, tidak ada checkpoint terkait transaksi yang disensor yang terdeteksi di blok Bitcoin mana pun, validator dan pengguna jujur akan memasuki mode rollup.
Dalam mode rollup, validator mana pun dapat mengusulkan bundel transaksi PoS, dan jika validator yang memiliki setidaknya separuh (1/2) dari total staking menandatangani bundel tersebut, transaksi akan difinalisasi di jaringan Bitcoin, efektif mencegah sensorship.
Timestamp Bitcoin memungkinkan rantai PoS memanfaatkan keamanan Bitcoin untuk mengurangi periode pembatalan staking dan meningkatkan ketahanan sensor, tetapi ini hanya sebagian memanfaatkan keamanan Bitcoin.
Selain Penstempelan Timestamping Bitcoin, Babylon memperkenalkan Bitcoin Staking, yang mengimplementasikan staking BTC secara langsung menggunakan bahasa script Bitcoin. Hal ini memungkinkan protokol PoS lainnya mendapatkan manfaat dari keamanan kripto ekonomi BTC yang dipertaruhkan. Protokol staking dirancang sebagai plug-in modular, sehingga mudah disesuaikan untuk berbagai protokol konsensus PoS.
Bagi pemegang BTC, Penjatahan Bitcoin Babylon adalah peluang investasi yang menarik karena mereka dapat melakukan penjatahan BTC pada tingkat keamanan Bitcoin tanpa bergantung pada entitas eksternal, sambil juga mendapatkan imbalan dari protokol eksternal.
Mari tentukan beberapa istilah kunci:
Tapi tunggu—berbeda dengan Ethereum, jaringan Bitcoin tidak Turing lengkap, sehingga sulit untuk menerapkan kontrak staking yang kompleks. Lalu bagaimana Babylon mencapainya?
Mari kita jelajahi detail dengan contoh dari blog Babylon.
// Kontrak V0: menambahkan kondisi penguncian pada UTXO staking milik Alice
kondisi-1 (penguncian): time_lock = 1000 & kunci_publik_alice
Mari kita asumsikan bahwa Alice melakukan staking BTC dan juga bertindak sebagai Penyedia Finality. Untuk menerapkan staking BTC, diperlukan mekanisme untuk mengunci BTC. Hal ini dicapai dengan mengatur salah satu kondisi pengeluaran UTXO sehingga hanya Alice (pemilik BTC) yang dapat menarik dana setelah jangka waktu tertentu (time_lock = 1000) menggunakan kunci publik miliknya, alice_public_key.
// Kontrak V1: menambahkan pengurangan secara naif
kondisi-1 (penguncian): time_lock = 1000 & alice_public_key; ATAU
kondisi-2 (slashing): kunci_publik_alice_eots
Salah satu komponen penting yang harus diimplementasikan dalam staking adalah slashing. Jika tindakan jahat terjadi, mekanisme insentif dapat diberlakukan dengan membakar BTC yang dipertaruhkan. Untuk mencapai hal ini, kondisi pengeluaran UTXO kedua ditetapkan sehingga slashing dapat terjadi jika seseorang memegang kunci EOTS Alice.
Di sini, EOTS (Extractable One-Time Signature) adalah tanda tangan yang diimplementasikan menggunakan tanda tangan Schnorr, yang diperkenalkan setelah upgrade Taproot Bitcoin. Singkatnya, ini adalah algoritma yang memastikan bahwa jika pelaku jahat melakukan double-sign dua blok yang berbeda pada ketinggian yang sama menggunakan kunci yang sama, kunci rahasianya akan terungkap secara publik.
Jika dilihat lebih detail, tanda tangan Schnorr terdiri dari kunci privat x, kunci publik P=xG, dan nonce acak k. Prosedur penandatanganan adalah sebagai berikut: nonce acak k dihasilkan, dan nilai publik R=kG dihitung dari nonce tersebut. Kemudian, nilai hash e dihitung dari pesan M dan R, dan nilai tanda tangan s dihitung berdasarkan nonce dan e, di mana s = k + ex. Tanda tangan Schnorr akhir terdiri dari (s, R).
Ide inti dari EOTS adalah bahwa jika kunci yang sama digunakan dua kali untuk menandatangani, kunci pribadi terbuka. Jika Alice menandatangani dua pesan yang berbeda menggunakan nonce yang sama k, maka tanda tangan pertama adalah s1= k + e_1x dan tanda tangan kedua adalah s2= k + e_2x. Karena s1, s2, e1, e2 diketahui secara publik, siapa pun dapat menyelesaikan kunci pribadi x Alice menggunakan persamaan x=(s1 - s2)/(e1 - e2).
Dengan mekanisme ini, jika Alice dengan jahat menandatangani dua pesan yang berbeda menggunakan kunci EOTS yang sama selama proses validasi BSN, siapa pun yang mendeteksinya dapat mengekstrak kunci rahasia EOTS Alice. Begitu kunci rahasia EOTS terungkap, penyerang dapat mencuri BTC yang dipertaruhkan oleh Alice atau membakar BTC yang dipertaruhkan oleh Alice sebagai denda.
// Kontrak V2
kondisi-1 (penguncian): time_lock = 1000 & alice_public_key; ATAU
kondisi-2 (pemotongan): alice_eots_public_key & covenant_committee_quorum
// Transaksi pemangkasan V0
masukan:
keluaran:
0000...0000
// Pra-persetujuan V0: menerapkan pembakaran
Komite Perjanjian telah menandatangani pratinjau awal di atas pemotongan tx sebagai persetujuannya sebelumnya
Karena kita sebelumnya telah membahas kondisi di mana pemotongan terjadi, mari kita sekarang memeriksa bagaimana pemotongan benar-benar ditegakkan. Menegakkan pemotongan adalah sangat penting karena, jika Alice terlibat dalam perilaku jahat, dia mungkin mencoba untuk menarik kembali BTC-nya sebelum seseorang mendeteksi pelanggaran, mengekstrak kunci rahasia EOTS-nya, dan membakar BTC-nya.
Untuk mencegah hal ini, pemangkasan harus dilaksanakan dengan cara yang memaksa transfer BTC ke alamat pembakaran yang telah ditentukan sebelumnya (0000…0000). Untuk mencapai hal ini, kondisi pengeluaran UTXO kedua melibatkan Kuorum Komite Perjanjian. Komite Perjanjian bertanggung jawab untuk memverifikasi apakah pemangkasan tersebut sah. Dengan menggabungkan skema multi-tanda tangan (M-dari-N), sistem memastikan bahwa Alice tidak dapat menarik BTC-nya sendiri ke dompetnya sendiri sebelum pemangkasan dilaksanakan.
Keuntungan dari pendekatan ini adalah bahwa, selama Alice bersikap jujur, tanda tangan EOTS-nya tidak pernah terungkap, artinya Komite Perjanjian tidak dapat menyita dana-dananya. Oleh karena itu, Alice tidak perlu percaya pada Komite Perjanjian, karena mereka tidak dapat bertindak melawannya kecuali dia melakukan perilaku jahat.
// Kontrak V3: memungkinkan delegasi aman
kondisi-1 (penguncian): time_lock = 1000 & alice_public_key; ATAU
kondisi-2 (pemangkasan): kunci_publik_alice & kunci_publik_validator_eots & kuorum_komite_perjanjian
// Memotong transaksi V0
masukan:
keluaran:
0000...0000
// Pra-persetujuan V1
// Alice menandatangani tx pemotongan sebelumnya sebagai persetujuan awalnya.
// Komite Perjanjian memprediksi pemotongan tx saat pra-persetujuan.
Alice dapat langsung melakukan staking BTC dan berpartisipasi dalam memvalidasi protokol PoS lain sebagai penyedia finalitas. Namun, kebanyakan pengguna akan memilih untuk mendelagasikan staking BTC mereka.
Untuk melaksanakan hal ini, menambahkan kunci EOTS validator ke kondisi kedua memastikan bahwa jika validator terlibat dalam perilaku jahat, BTC Alice bisa dibakar. Namun, masalahnya di sini adalah jika validator berkolusi dengan komite perjanjian, mereka bisa mencuri BTC Alice, memaksa Alice untuk percaya pada validator.
Solusi sederhana untuk masalah ini adalah dengan juga menyertakan kunci publik Alice dalam kondisi kedua. Dengan cara ini, membakar BTC akan membutuhkan tanda tangan Alice juga, mencegah pencurian BTC yang tidak sah.
Untuk mencapai hal ini, Alice memprediksi transaksi yang menyatakan bahwa “jika terjadi pemotongan, BTC harus dikirim ke alamat pembakaran.” Dalam hal ini, jika validator bertindak dengan jahat dan kunci EOTS mereka terungkap, dan jika komite kontrak melaksanakan tanda tangan ganda, BTC akan dikirim ke alamat pembakaran, menerapkan proses pemotongan.
/ Kontrak V3
kondisi-1 (penguncian): time_lock = 1000 & kunci_publik_alice; OR
kondisi-2 (pemangkasan): kunci_publik_alice & kunci_publik_validator_eots & kuorum_komite_kovenan
Transaksi pemotongan V0
masukan:
outputs:
0000...0000
// Pra-persetujuan V2: menegakkan pemotongan atomik saat wakil
Pratindakan persetujuan pra-approval Alice adalah tanda tangan adaptor dari transaksi pemotongan
// dia dibuat menggunakan kunci publik EOTS validator.
// Komite perjanjian menandatangani pemotongan tx sebagai persetujuan awalnya.
Bagaimana jika validator jahat menargetkan hanya pemegang yang spesifik untuk dipangkas? Untuk mencegah hal ini, Babylon memperkenalkan Tanda Tangan Adaptor.
Alice mengenkripsi tanda tangannya menggunakan kunci publik EOTS validator sebagai tanda tangan adaptor. Jika validator mencoba mengurangi hanya Alice, mereka harus menggunakan kunci privat EOTS mereka. Karena sifat Tanda Tangan Adaptor, hal ini akan mengakibatkan paparan kunci privat EOTS validator, menghilangkan insentif bagi validator untuk terlibat dalam perilaku berbahaya.
// Kontrak V3
kondisi-1 (penguncian): time_lock = 1000 & alice_public_key; OR
kondisi-2 (pemotongan): kunci_publik_alice & kunci_publik_validator_eots & kuorum_komite_perjanjian
// Transaksi pemangkasan V1: memungkinkan pemangkasan sebagian
masukan:
outputs:
output-1: nilai = 0.09 Bitcoin, pemilik = 0000...0000
output-2: nilai = 0.9 Bitcoin,
kondisi:
// Pra-persetujuan V2
// Pratindakan prakualifikasi Alice adalah tanda tangan adaptor dari pengurangan tx
// dia dihasilkan menggunakan kunci publik EOTS validator.
Komite Perjanjian telah menandatangani pemotongan tx sebagai persetujuan awalnya.
Tapi apakah Anda tidak berpikir bahwa membakar semua Bitcoin dalam kejadian pemangkasan terlalu ekstrim? Untuk mengatasi hal ini, hanya sebagian Bitcoin (misalnya, membakar hanya 10% sambil mengembalikan 90% sisanya setelah jangka waktu tertentu) dapat dibakar. Ini dapat dilaksanakan dengan membagi output transaksi pemangkasan menjadi dua, seperti yang dijelaskan di atas.
// Kontrak V4: Mengaktifkan restaking
kondisi-1 (penguncian): time_lock = 1000 & alice_public_key; ATAU
kondisi-2 (pemangkasan): kunci_publik_alice & tanda_tangan apa pun dari daftar [kunci_publik_validator_eots] & kuorum_komite_perjanjian
BTC yang didelegasikan oleh Alice dapat berpartisipasi dalam validasi beberapa protokol PoS, bukan hanya satu. Jika validator berpartisipasi dalam validasi protokol PoS yang berbeda menggunakan kunci EOTS yang sama, kebocoran di satu tempat dapat memengaruhi sistem lainnya. Oleh karena itu, penyedia finalitas Babylon harus menggunakan kunci EOTS yang berbeda untuk sistem PoS yang berbeda, dan daftar kunci EOTS diperkenalkan dalam kondisi kedua.
Tidak seperti jaringan PoS seperti Ethereum atau Solana, jaringan Bitcoin beroperasi dengan PoW, sehingga konsep staking tidak ada secara inheren. Namun, Babylon telah menerapkan fitur penguncian BTC, pemotongan, dan delegasi yang diperlukan untuk staking melalui karakteristik UTXOs, bahasa scripting Bitcoin, dan berbagai algoritma tanda tangan. Ini memungkinkan pemegang BTC untuk mendapatkan keuntungan tambahan secara alami dengan memanfaatkan BTC, tanpa perlu jembatan atau layanan asuhan.
Selain Jaringan Lightning, tidak ada protokol lain yang sepenuhnya mewarisi keamanan jaringan Bitcoin. Namun, sama seperti jaringan Bitcoin, fungsionalitas Jaringan Lightning sangat terbatas, dan terlalu berharga untuk menyerah pada keamanan yang kuat dan likuiditas besar Bitcoin.
Babylon telah memungkinkan penggunaan keamanan Bitcoin dalam dua cara berbeda melalui Penanda Waktu Bitcoin dan Staking Bitcoin. Yang pertama menggunakan Bitcoin sebagai server penanda waktu untuk mencegah pembatalan transaksi atau fork jahat, sementara yang terakhir memanfaatkan likuiditas BTC yang kuat sebagai keamanan kripto-ekonomi, memungkinkan pemegang BTC untuk mendapatkan keuntungan tambahan dengan cara yang alami.
Saat ini, sekitar 55.000 BTC disimpan di Babylon, yang bahkan sebanding dengan batas deposit yang ditetapkan oleh Babylon. Sekitar 3,9% dari total pasokan ETH di-stake kembali di EigenLayer. Mengingat hal ini, meskipun pemegang BTC mungkin konservatif dalam memanfaatkan BTC, potensi pertumbuhan Babylon, dengan hanya sekitar 0,2% dari total pasokan BTC saat ini yang di-stake, layak dipertimbangkan.