Ringkasan: Jembatan ZK menempatkan kontrak pintar di Rantai A untuk langsung menerima dan memverifikasi header blok dan bukti nol pengetahuan yang sesuai dari Rantai B, mengonfirmasi validitas pesan lintas-rantai. Ini adalah skema jembatan yang paling aman.

• Optimistic/OP Bridges menggunakan bukti penipuan untuk menantang pesan lintas-rantai yang tidak valid di rantai. Keberadaan hanya satu penantang yang dapat diandalkan dapat memastikan keamanan dana pool jembatan lintas-rantai.
• Karena keterbatasan teknis, mainnet Bitcoin tidak dapat langsung menerapkan jembatan ZK tetapi dapat mencapai jembatan optimis melalui BitVM dan bukti penipuan. Tim seperti Bitlayer dan Citrea telah mengadopsi skema jembatan BitVM, memperkenalkan pra-tanda tangan dan menggabungkan konsep saluran, memungkinkan pengguna untuk menentukan proses penanganan sebelum eksekusi deposit, mencegah jembatan lintas rantai mengalihkan deposit pengguna.
• Jembatan BitVM pada dasarnya beroperasi dengan model "pra-bayar-ganti rugi", dengan node Operator spesifik menyediakan dana kepada pengguna penarikan. Operator dapat secara berkala mengajukan penggantian biaya dari alamat deposit publik. Jika seorang Operator mengajukan aplikasi penggantian biaya palsu, hal tersebut dapat dilawan dan dipotong oleh siapa pun.
• Meskipun secara teori aman, jembatan BitVM memiliki isu dengan kelangsungan hidup/kemudahan penggunaan dan tidak memenuhi kebutuhan pengguna spesifik untuk kemandirian dana dan anti pencucian uang (karena pada dasarnya menggunakan model kolam dana). Bitlayer mengatasi hal ini dengan solusi jembatan OP-DLC. Solusi ini, mirip dengan DLC.link, memperkenalkan bukti kecurangan berdasarkan saluran dan DLC untuk mencegah penyalahgunaan oracle.
• Mengingat kesulitan dalam mengimplementasikan BitVM dan bukti penipuan, jembatan DLC akan diterapkan terlebih dahulu sebagai pengganti sementara. Selama risiko kepercayaan dari orakel teratasi dan orakel pihak ketiga yang lebih handal dan matang terintegrasi, jembatan DLC dapat menjadi skema verifikasi penarikan yang lebih aman daripada jembatan multi-tanda tangan pada tahap saat ini.

Pendahuluan:Sejak kegilaan prasasti tahun lalu, ekosistem Bitcoin telah memasuki periode pertumbuhan yang cepat. Hanya dalam setengah tahun, jumlah proyek di bawah bendera BTC Layer2 telah mencapai hampir 100.It hanya menjadi benua baru yang penuh kekacauan, di mana peluang dan penipuan hidup berdampingan. Tidak berlebihan untuk mengatakan bahwa ekosistem Bitcoin saat ini sudah menjadi "melting pot multi-etnis" dari Ethereum, Cosmos dan Celestia, CKB dan ekosistem asli Bitcoin. Ditambah dengan kurangnya suara otoritatif, ekosistem Bitcoin sama seperti abad ke-19. Seperti Amerika Serikat, itu telah menjadi dunia baru yang menarik kekuatan dari semua lapisan masyarakat. Meskipun ini membawa kemakmuran dan vitalitas ke seluruh narasi Web3, ini juga menimbulkan risiko besar.

Banyak proyek telah mulai menghipnotis tanpa merilis solusi teknis, menggunakan nama lapisan 2 asli, mengklaim bahwa mereka dapat sepenuhnya mewarisi keamanan jaringan utama Bitcoin; beberapa bahkan menggunakan teknik propaganda untuk menciptakan konsep, menciptakan sekelompok kata benda aneh dan istilah sebagai cara untuk mempromosikan superioritas diri sendiri. Meskipun menyombongkan diri sudah menjadi status saat ini dalam ekosistem Bitcoin, masih banyak KOL teratas yang telah membuat panggilan objektif.

Tidak lama yang lalu, Monanaut, pendiri peramban blockchain Mempool, secara terbuka mengkritik masalah-masalah saat ini dalam ekosistem Bitcoin. Dia dengan tajam menyoroti bahwa jika Layer 2 Bitcoin hanya menggunakan jembatan penarikan multi-tanda tangan dan tidak dapat memungkinkan pengguna menarik aset kapan saja dalam bentuk tanpa kepercayaan, proyek seperti itu bukanlah Layer 2 yang sebenarnya. Menariknya, Vitalik sebelumnya menunjukkan bahwa Layer 2 setidaknya harus lebih aman dalam hal keamanan daripada sistem yang hanya mengandalkan multi-tanda tangan.

Bisa dikatakan bahwa Monanaut dan Vitalik dengan tegas menunjukkan masalah teknis dari Bitcoin Layer 2: Banyak jembatan penarikan L2 pada dasarnya adalah jembatan multi-tanda tangan. Entah beberapa lembaga terkenal masing-masing memegang kunci, atau tanda tangan terdesentralisasi berdasarkan POS digunakan, tetapi dalam setiap kasus, model keamanannya didasarkan pada asumsi kejujuran mayoritas, yaitu, secara default mayoritas peserta multi-tanda tangan tidak bersekongkol untuk berbuat jahat.

Solusi jembatan penarikan semacam ini yang sangat mengandalkan jaminan kredit bukanlah solusi jangka panjang. Sejarah telah memberi tahu kita bahwa jembatan multi-tanda tangan akan mengalami berbagai masalah cepat atau lambat. Hanya kepercayaan yang diminimalkan atau penitipan aset cenderung benar-benar tanpa kepercayaan. Hanya dengan cara ini dapat bertahan dari ujian waktu dan peretas. Tetapi situasi saat ini dalam ekosistem Bitcoin adalah bahwa Banyak pihak proyek bahkan belum merilis peta jalan teknis untuk jembatan penarikan. Tidak ada ide desain yang mapan tentang bagaimana jembatan harus dipercayai atau diminimalkan.

Namun ini bukanlah semua dari ekosistem Bitcoin. Masih ada beberapa manajer proyek yang telah menyatakan pendapat mereka tentang ide-ide optimisasi jembatan penarikan. dalam teks, Kami akan secara singkat menganalisis Bitlayer dan jembatan BitVM Citrea, dan memperkenalkan jembatan OP-DLC yang diusulkan oleh Bitlayer untuk mengatasi kekurangan jembatan BitVM, sehingga lebih banyak orang dapat memahami risiko dan ide desain dari jembatan lintas rantai. Ini sangat penting bagi sebagian besar peserta ekosistem Bitcoin.

Jembatan Optimis: Skema verifikasi jembatan berdasarkan bukti penipuan

Sejatinya, esensi dari jembatan lintas-rantai sangat sederhana, yaitu membuktikan kepada rantai B bahwa sebuah kejadian tertentu memang terjadi di rantai A. Misalnya, jika Anda menyeberang aset dari ETH ke Polygon, Anda memerlukan jembatan lintas-rantai untuk membantu Anda membuktikan bahwa Anda memang telah mentransfer aset ke alamat tertentu di rantai ETH, dan kemudian Anda dapat menerima jumlah dana yang sama di rantai Polygon.

Jembatan lintas-rantai tradisional umumnya menggunakan tanda tangan multi-saksi. Mereka akan menunjuk beberapa saksi di bawah rantai. Para saksi akan menjalankan node dari setiap rantai publik dan memantau apakah ada yang telah mendepositkan dana ke alamat pembayaran jembatan lintas-rantai.

Model keamanan dari jenis jembatan lintas-rantai ini pada dasarnya sama dengan dompet multi-tanda tangan. Model kepercayaan harus ditentukan berdasarkan metode pengaturan multi-tanda tangan seperti M/N, tetapi pada akhirnya pada dasarnya mengikuti asumsi mayoritas jujur, yang berarti bahwa kebanyakan notaris secara default tidak jahat dan tingkat toleransi kesalahan relatif terbatas. Banyak kasus pencurian jembatan lintas-rantai berskala besar yang terjadi sebelumnya pada dasarnya semua terjadi pada jenis jembatan multi-tanda tangan ini, baik karena pencurian atau oleh peretas.

Sebaliknya, Jembatan “Optimistic” berdasarkan protokol bukti penipuan dan Jembatan “ZK” berdasarkan ZK jauh lebih aman. Mengambil contoh Jembatan ZK, akan membuat kontrak validator khusus di rantai target untuk langsung memverifikasi sertifikat penarikan di rantai, menghilangkan ketergantungan pada saksi di luar rantai.

Sebagai contoh, sebuah jembatan ZK yang meliputi ETH dan Polygon akan mendeploy kontrak verifier di Polygon, mari kita sebut Verifier untuk saat ini. Node Relayer dari ZK Bridge akan meneruskan header blok Ethereum terbaru dan Bukti ZK yang membuktikan kevalidan kepada Verifier, yang akan memverifikasinya. Ini setara dengan memiliki kontrak Verifier menyelaraskan pada rantai Polygon dan memverifikasi header blok Ethereum terbaru. Merkle root yang tercatat dalam header blok terkait dengan set transaksi yang terdapat dalam blok dan dapat digunakan untuk memverifikasi apakah suatu transaksi tertentu termasuk dalam blok tersebut.

Jika blok Ethereum dengan ketinggian blok 101 berisi 10 pernyataan transfer lintas-rantai dari ETH ke Polygon, Relayer akan menghasilkan Bukti Merkle terkait dengan 10 transaksi ini dan mengirimkan bukti ke kontrak Verifier di rantai Polygon:

Blok Ethereum No. 101 berisi 10 transaksi lintas-rantai dari ETH ke Polygon. Tentu saja, jembatan ZK dapat mengonversi Merkle Proof menjadi ZK dan langsung mengirimkan ZK Proof ke kontrak Verifier. Selama seluruh proses ini, pengguna hanya perlu percaya bahwa kontrak pintar jembatan lintas-rantai tidak memiliki celah, dan bahwa teknologi bukti tanpa pengetahuan itu sendiri aman dan dapat diandalkan. Tidak perlu memperkenalkan terlalu banyak asumsi kepercayaan seperti jembatan multi-tanda tangan tradisional.

Dan”Optimistic Bridge” sedikit berbeda. Beberapa jembatan optimis mempertahankan pengaturan yang mirip dengan saksi, tetapi memperkenalkan bukti penipuan dan jendela tantangan., setelah saksi menghasilkan tanda tangan ganda untuk pesan lintas-rantai, meskipun akan disampaikan ke rantai target, validitasnya tidak akan segera diakui. Itu harus melewati periode jendela dan tidak ada yang mempertanyakan sebelum dapat dianggap valid. Ini sebenarnya agak mirip dengan ide Optimistic Rollup. Tentu saja, Optimistic Bridge memiliki model produk lain, tetapi pada analisis akhirnya, keamanan dijamin oleh protokol bukti penipuan.

Asumsi kepercayaan jembatan multi-tanda tangan M/N adalah N-(M-1)/N. Anda harus berasumsi bahwa jumlah orang jahat dalam jaringan paling banyak M-1, dan jumlah orang jujur setidaknya N- (M-1). Asumsi kepercayaan jembatan ZK dapat diabaikan, sedangkan asumsi kepercayaan jembatan optimis berdasarkan bukti penipuan adalah 1 / N, Hanya satu dari saksi N yang perlu jujur dan bersedia untuk menantang pesan lintas rantai yang tidak valid yang dikirimkan ke rantai target untuk memastikan keamanan jembatan.

saat ini, karena keterbatasan teknis, hanya jembatan ZK dalam arah deposit Bitcoin ke Layer 2 yang dapat diimplementasikan. Jika arahnya dibalik dan penarikan dilakukan dari Layer 2 ke rantai Bitcoin, hanya jembatan multi-tanda tangan atau jembatan optimis, atau model mirip saluran yang didukung. (Jembatan OP-DLC yang akan dijelaskan di bawah ini lebih mirip saluran). Untuk menerapkan jembatan optimis pada rantai Bitcoin, bukti penipuan harus diperkenalkan, dan bitVM telah menciptakan kondisi yang baik untuk implementasi teknologi ini.

di artikel sebelumnya“Interpretasi Minimalis dari BitVM: Bagaimana Memverifikasi Bukti Kecurangan pada Rantai BTC”, kami telah secara singkat memperkenalkan,Essensi bukti penipuan BitVM adalah dengan memecah tugas perhitungan kompleks yang dilakukan di luar rantai menjadi sejumlah langkah sederhana, dan kemudian memilih langkah tertentu untuk diverifikasi langsung di rantai Bitcoin.. Ide ini mirip dengan rollups optimis Ethereum seperti Arbitrum dan Optimism.

(Dokumentasi BitVM2 menyebutkan bahwa tugas komputasi akan dibagi menjadi sejumlah langkah intermediate melalui tanda tangan Lamport, dan kemudian siapa pun dapat menantang langkah intermediate)

Tentu saja, pernyataan di atas masih agak kabur, tetapi saya percaya bahwa sebagian besar orang telah memahami arti sertifikat penipuan. Dalam artikel hari ini, karena keterbatasan ruang secara keseluruhan, kami tidak bermaksud menjelaskan detail implementasi teknis BitVM dan protokol bukti penipuan, karena hal ini melibatkan serangkaian proses interaksi kompleks.

Kami akan memperkenalkan singkat BitLayer, Citrea, BOB, dan bahkan jembatan BitVM asli yang dirancang secara resmi oleh BitVM dari sudut pandang desain produk dan mekanisme, dan bagaimana Bitlayer meredakan bottleneck dari jembatan BitVM melalui jembatan OP-DLC., untuk menunjukkan kepada Anda bagaimana merancang solusi jembatan penarikan yang unggul di rantai Bitcoin.

(Diagram skematis solusi jembatan Bitlayer)

Sebuah analisis singkat mengenai prinsip jembatan BitVM antara Bitlayer dan Citrea

di bawah, kami menggunakan solusi jembatan BitVM yang diumumkan oleh Bitlayer, Citrea, dan Bob sebagai materi untuk menggambarkan proses operasi umum dari jembatan BitVM.

Dalam dokumen resmi dan blog teknisnya, pihak proyek yang disebutkan di atas dengan jelas menjelaskan ide desain produk BitVM Withdrawal Bridge (saat ini berada dalam tahap teoritis). Pertama, ketika seorang pengguna menarik uang melalui jembatan BitVM, ia perlu menggunakan kontrak Jembatan di Layer 2 untuk menghasilkan pernyataan penarikan. Parameter-parameter kunci berikut ditentukan dalam pernyataan penarikan:

Jumlah BTC yang dipetakan yang harus dihancurkan oleh penarik dalam L2 (seperti 1 BTC);

Biaya penanganan lintas-rantai yang ingin dibayarkan oleh penarik ( diasumsikan 0,01 BTC );

Alamat penarikan dari penarik dalam L1: L1_receipt;

Jumlah penarikan penarik (yaitu 1 - 0,01 = 0,99BTC)

Setelah itu, Pernyataan penarikan di atas akan disertakan dalam blok Layer2. Jembatan BitVM Node Relayer akan menyinkronkan blok Layer2, memantau pernyataan penarikan yang terkandung di dalamnya, dan meneruskannya ke node Operator, yang akan membayar pengguna yang melakukan penarikan.

Yang perlu diperhatikan di sini adalah Operator pertama-tama membayar pengguna di rantai Bitcoin dari kantong sendiri, yaitu, "maju" dana untuk Jembatan BitVM, dan kemudian mengajukan kompensasi dari kolam dana Jembatan BitVM.

Saat mengajukan penggantian, Operator perlu memberikan bukti pembayaran di muka pada rantai Bitcoin (yaitu, untuk membuktikan bahwa ia telah mentransfer uang ke alamat yang ditentukan oleh pengguna penarikan di L1, dan harus mengekstrak catatan transfer spesifik yang terdapat dalam blok Bitcoin) . Pada saat yang sama, Operator juga harus mengeluarkan pernyataan penarikan yang dihasilkan oleh penarikan di L2 (melalui Bukti Merkle, terbukti bahwa pernyataan penarikan yang dikeluarkan berasal dari blok L2 dan tidak dibuat begitu saja). setelah, Operator perlu membuktikan hal-hal berikut:

Dana yang diberikan oleh Operator kepada pembayar atas nama Jembatan BitVM sama dengan jumlah yang diminta oleh pembayar dalam pernyataan;

Ketika Operator mengajukan penggantian, jumlah penggantian tidak boleh lebih dari jumlah BTC yang dipetakan yang dihancurkan oleh penarik dalam Layer 2;

Operator memang telah memproses semua pernyataan penarikan L2-L1 dalam jangka waktu tertentu, dan setiap pernyataan penarikan dapat dipasangkan dengan catatan transfer penarikan pada rantai Bitcoin;

Ini pada dasarnya adalah hukuman bagi Operator yang berbohong tentang jumlah muka atau menolak untuk memproses pernyataan penarikan (yang dapat memecahkan masalah tahan sensor jembatan penarikan). Operator perlu membandingkan dan memverifikasi bidang kunci sertifikat pembayaran muka dan pernyataan penarikan di luar rantai untuk membuktikan bahwa jumlah BTC yang terlibat dalam keduanya sama.

Jika Operator Jembatan Penarikan secara salah melaporkan jumlah uang muka, itu berarti bahwa Operator mengklaim bahwa bukti pembayaran di L1 sesuai dengan Pernyataan Penarikan yang dikeluarkan oleh penarik L2, tetapi situasi sebenarnya adalah bahwa keduanya tidak cocok.

Dengan cara ini, membuktikan bahwa ZKP dari Bukti Pembayaran = Pernyataan Penarikan harus salah. Selama ZKP ini dirilis, Challanger dapat menunjukkan langkah mana yang salah dan menantangnya melalui protokol bukti kecurangan BitVM2.

Yang perlu ditekankan adalah bahwa Bitlayer, Citrea, BOB, ZKBase, dll. semuanya telah mengadopsi rute BitVM2 terbaru, yaitu versi baru dari solusi BitVM. Solusi ini akan ZKize tugas komputasi off-chain, yaitu, menghasilkan ZK Proof untuk proses perhitungan off-chain, kemudian memverifikasi Proof, dan kemudian mengonversi proses memverifikasi ZKP ke Disesuaikan dengan bentuk BitVM untuk memudahkan tantangan selanjutnya.

Pada saat yang sama,Dengan menggunakan Lamport dan pra-penyignan, tantangan interaktif multi-putaran dari BitVM asli dapat dioptimalkan menjadi tantangan non-interaktif satu putaran, sangat mengurangi kesulitan dari tantangan.

Proses tantangan BitVM memerlukan penggunaan sesuatu yang disebut “komitmen”, yaitu, Komitmen. Mari kita jelaskan apa itu “komitmen”. Secara umum, seseorang yang menerbitkan “komitmen” di rantai Bitcoin akan mengklaim bahwa data tertentu yang disimpan di luar rantai/tugas komputasi yang terjadi di luar rantai adalah akurat, dan pernyataan terkait yang diterbitkan di rantai adalah “komitmen”.

Kami dapat memahami Keterikatan secara kasar sebagai hash dari sejumlah besar data di luar rantai.. Ukuran Keterikatan itu sendiri sering kali dikompres sangat kecil, tetapi dapat terikat pada sejumlah besar data di luar rantai melalui metode seperti Pohon Merkle, dan data di luar rantai yang terkait ini tidak perlu diunggah ke rantai.

Dalam solusi jembatan BitVM dari BitVM2 dan Citrea dan BitLayer, Jika seseorang menganggap ada masalah dengan komitmen yang diterbitkan oleh Operator Jembatan Penarikan di rantai, dan bahwa komitmen terkait dengan proses verifikasi ZKP yang tidak valid, dia dapat memulai sebuah tantangan, dan otoritas tantangan adalah Permissionless.. (Proses interaksi di dalamnya relatif rumit dan tidak akan dijelaskan di sini)

Karena Operator memajukan dana untuk kolam dana BitVM untuk membayar penarikan, dan kemudian mengajukan permohonan kepada kolam dana untuk penggantian, saat mengajukan, Operator harus mengeluarkan Komitmen untuk membuktikan bahwa uang yang ditransfernya ke penarikan di L1 sama dengan penarikan itu. Pembayar menyatakan pada L2 bahwa ia ingin menerima uang tersebut. Jika Komitmen telah melewati jendela bukti penipuan dan tidak ditantang, Operator dapat menarik jumlah penggantian yang dibutuhkan.

Di sini kami ingin menjelaskan bagaimana kolam dana publik dari jembatan BitVM dipelihara, dan ini adalah bagian paling kritis dari jembatan lintas rantai. Seperti yang kita semua tahu, dana yang dapat dibayarkan oleh jembatan lintas rantai kepada penerima berasal dari aset yang disumbangkan oleh penyimpan atau LP lainnya, dan uang yang diberikan oleh Operator pada akhirnya akan ditarik dari kolam dana publik, sehingga bergantung sepenuhnya pada dana. Akibat dari transfer, jumlah Deposit penyimpan yang diserap oleh jembatan BitVM seharusnya sama dengan jumlah Penarik yang ditarik. Jadi bagaimana cara menjaga dana Deposit adalah masalah yang sangat penting.

Dalam sebagian besar solusi jembatan Layer 2 Bitcoin, aset publik sering dikelola melalui multi-tanda tangan. Deposito pengguna dikumpulkan ke dalam rekening multi-tanda tangan. Ketika penarikan perlu dilakukan, rekening multi-tanda tangan ini bertanggung jawab untuk melakukan pembayaran. Tentu saja ada risiko kepercayaan yang besar dalam solusi ini.

Jembatan BitVM Bitlayer dan Citrea mengadopsi ide yang mirip dengan Jaringan Lightning dan saluran. Sebelum melakukan deposit, pengguna akan terlebih dahulu berkomunikasi dengan Aliansi BitVM dan meminta yang terakhir untuk melakukan tanda tangan awal untuk mencapai efek berikut:

Setelah pengguna mentransfer deposit ke alamat pengisian, uang akan langsung terkunci di alamat Taproot dan hanya dapat diklaim oleh Operator jembatan. Selain itu, Operator hanya dapat mengklaim dana dari alamat Taproot deposit di atas dengan mengajukan penggantian setelah mengirimkan dana penarikan kepada pengguna. Setelah periode tantangan berakhir, Operator dapat menarik sejumlah tertentu deposit pengguna.

Dalam solusi jembatan BitVM, ada Federasi BitVM (BitVM Federation) yang terbentuk oleh N anggota, yang menjadwalkan deposit pengguna. Namun, para anggota N ini tidak dapat menyalahgunakan deposit pengguna secara pribadi, karena pengguna akan memerlukan BitVM Alliance untuk menandatangani sebelum mentransfer uang ke alamat yang ditentukan untuk memastikan bahwa deposit tersebut hanya dapat diklaim secara sah oleh Operator.

Diagram solusi jembatan optimis BitVM2

Secara ringkas, BitVM Bridge mengadopsi ide-ide yang mirip dengan saluran dan jaringan petir, memungkinkan pengguna untuk “memverifikasi sendiri” dan mencegah Aliansi BitVM memanipulasi kolam deposit tanpa izin melalui pra-tanda tangan. Uang dalam kolam deposit hanya dapat digunakan untuk mengganti Operator. Jika seorang operator menyalahgunakan jumlah uang muka, siapa pun dapat mengeluarkan bukti penipuan dan menantangnya.

Jika solusi di atas dapat diimplementasikan, jembatan BitVM akan menjadi salah satu jembatan penarikan Bitcoin yang paling aman:Tidak ada masalah keamanan dengan jembatan ini, hanya masalah ketersediaan/kehidupan. Ketika pengguna mencoba mendepositkan dana ke BitVM, mereka mungkin disensor atau menolak untuk bekerja sama oleh Aliansi BitVM, yang mengakibatkan ketidakmampuan untuk berhasil mendepositkan dana. Namun, hal ini tidak ada hubungannya dengan keamanan tetapi merupakan masalah ketersediaan/kehidupan.

Namun, implementasi jembatan BitVM relatif sulit. Selain itu, jembatan ini tidak dapat memenuhi kebutuhan beberapa investor besar yang memiliki persyaratan transparansi dana yang relatif tinggi: orang-orang ini mungkin terlibat dalam masalah pencucian uang dan tidak ingin mencampur dana mereka sendiri dengan dana orang lain, namun jembatan BitVM akan secara seragam menerima uang deposito, dalam satu cara, ini adalah kolam di mana banyak uang dicampur.

Untuk menyelesaikan masalah aktivitas jembatan BitVM di atas dan menyediakan saluran masuk dan keluar dana yang independen dan bersih untuk orang-orang dengan kebutuhan khusus, tim BitLayer telah menambahkan solusi jembatan lintas rantai tambahan yang disebut OP-DLC. Selain jembatan optimis dari BitVM2, digunakan jembatan DLC yang mirip dengan DLC.link. Memberikan pengguna dua pintu masuk dan keluar, jembatan BitVM dan jembatan OP-DLC, untuk mengurangi ketergantungan pada jembatan BitVM dan bahkan Aliansi BitVM.

(skema diagram DLC)

DLC: Kontrak Log Cermat

DLC (Discreet Log Contracts) disebut kontrak log rahasia. Ini diusulkan oleh Digital Currency Initiative MIT. Teknologi ini pertama kali digunakan untuk mengimplementasikan kontrak pintar ringan pada Bitcoin. Ini tidak memerlukan konten kontrak diunggah ke rantai. Melalui metode seperti komunikasi interaktif di luar rantai dan pra-penandatanganan, fungsi kontrak pintar yang melindungi privasi diimplementasikan pada rantai Bitcoin. Di bawah ini kami menggunakan kasus perjudian untuk mengilustrasikan prinsip kerja DLC.

Misalkan Alice dan Bob ingin bertaruh pada hasil pertandingan antara Real Madrid dan Barcelona yang akan diselenggarakan tiga hari kemudian, dan masing-masing dari mereka membayar 1 btc. Jika Real Madrid menang, Alice bisa mendapatkan 1,5 BTC, dan Bob hanya bisa mendapatkan kembali 0,5 BTC, yang setara dengan Alice mendapatkan 0,5 BTC, dan Bob kehilangan 0,5 BTC; jika Barcelona menang, Alice hanya bisa mendapatkan kembali 0,5 BTC, dan Bob bisa membawa pulang 1,5 BTC. Jika terjadi seri, kedua pemain akan masing-masing mendapatkan kembali 1 BTC.

Jika kita ingin membuat proses perjudian di atas tanpa kepercayaan, kita harus menemukan cara untuk mencegah pihak manapun melakukan kecurangan. Jika kita hanya menggunakan multi-tanda tangan 2/2 atau multi-tanda tangan 2/3, jelas tidak cukup dapat dipercaya. DLC menyediakan solusi sendiri untuk masalah ini (mengandalkan orakel pihak ketiga). Seluruh alur kerja dapat dibagi secara kasar menjadi empat bagian.

Mengambil contoh Alice dan Bob sebelumnya, Pertama, kedua pihak membuat transaksi dana di luar rantai, yang dapat mengunci 1 BTC masing-masing di alamat multi-tanda-tangan 2/2., jika transaksi dana ini berlaku, 2 BTC di alamat multi-tanda-tangan perlu diotorisasi oleh kedua belah pihak sebelum dapat dihabiskan.

Tentu saja, transaksi Dana ini belum diunggah ke rantai, tetapi tetap lokal untuk klien Alice dan Bob di luar rantai. Mereka semua tahu apa konsekuensinya setelah transaksi ini berlaku. Saat ini, kedua belah pihak hanya melakukan deduksi teoritis dan kemudian mencapai serangkaian kesepakatan berdasarkan hasil deduksi.

Dalam tahap pertama pembuatan DLC, yang dapat kita tentukan adalah bahwa, Kedua pihak akan mengunci 1 BTC mereka ke alamat multi-tanda tangan di masa depan.

Pada langkah kedua, kedua pihak terus menduga kemungkinan peristiwa dan hasil masa depan yang mungkin: Misalnya, ketika hasil pertandingan sepak bola diumumkan, mungkin ada beberapa kemungkinan seperti Alice menang dan Bob kalah, Alice kalah dan Bob menang, hasil imbang, dll. Hal ini akan menghasilkan hasil distribusi yang berbeda dari Bitcoin di alamat multi-tanda tangan 2/2 yang disebutkan di atas.

Hasil yang berbeda perlu dipicu oleh instruksi perdagangan yang berbeda. Instruksi transaksi ini yang mungkin diunggah ke rantai di masa depan disebut CET, yaitu Transaksi Eksekusi Kontrak. Alice dan Bob harus mengurangi semua CET sebelumnya dan menghasilkan rangkaian data transaksi yang berisi semua CET.

Sebagai contoh, Berdasarkan hasil yang mungkin dari taruhan antara Alice dan Bob yang disebutkan di atas, Alice membuat CET berikut:

CET1: Alice dapat mengambil 1,5 BTC dari alamat multi-tanda tangan, dan Bob dapat mengambil 0,5 BTC;

CET2: Alice dapat 0.5 BTC dari alamat multi-tanda tangan, dan Bob dapat 1.5 BTC;

CET3: Kedua belah pihak dapat menerima 1 BTC masing-masing.

Mari kita ambil CET1 sebagai contoh (Alice mendapatkan 1.5 BTC, Bob mendapatkan 0.5 BTC):

Arti dari transaksi ini adalah mentransfer 1.5 BTC di alamat multi-tanda tangan ke alamat Taproot yang dipicu oleh hasil output dari Alice dan mesin orakel, dan mentransfer 0.5 BTC lainnya ke alamat Bob. Peristiwa yang sesuai pada saat ini adalah: Real Madrid menang, Alice menang 0.5 BTC, dan Bob kalah 0.5 BTC.

Tentu saja, Untuk menghabiskan 1,5 BTC ini, Alice harus mendapatkan tanda tangan hasil “Real Madrid wins” yang dikirim oleh orakel.. Dengan kata lain, hanya ketika orakel mengeluarkan pesan “Real Madrid wins” Alice dapat mentransfer 1,5 BTC tersebut. Mengenai isi CET2 dan CET3, kita dapat mendeduksinya dengan cara yang sama dan tidak akan masuk ke detail di sini.

Perlu dicatat bahwa CET pada dasarnya adalah transaksi yang perlu diunggah ke rantai untuk berlaku. Apa yang akan terjadi jika Alice menyiar CET1 terlebih dahulu, atau dalam kasus “Barcelona menang”, tetap memasang CET1 di rantai yang hanya berhasil dipicu setelah “Real Madrid menang”?

Dalam diagram sebelumnya, kami menyebutkan bahwa setelah CET1 dimasukkan ke dalam rantai, 2 BTC yang terkunci dalam alamat multi-tanda tangan asli akan dialihkan, 0,5 BTC akan dialihkan ke Bob, dan 1,5 BTC akan dialihkan ke alamat Taproot. Mesin orakel mengeluarkan "Hanya setelah Real Madrid menang" apakah Alice dapat membuka kunci BTC yang terkunci di alamat Taproot. Hasilnya seperti ditunjukkan di bawah ini.

Pada saat yang sama, Alamat Taproot ini tunduk pada kunci waktu. Jika Alice tidak berhasil menarik 1,5 BTC dalam jendela waktu yang ditentukan oleh kunci waktu, Bob berhak untuk mengambil uang tersebut secara langsung.

Oleh karena itu, selama oracle jujur, Alice tidak dapat mengambil 1,5 BTC. Ketika periode kunci waktu berakhir, Bob dapat mengambil 1,5 BTC. Selain 0,5 BTC yang ditransfer langsung ke Bob saat CET1 diunggah ke rantai, semua uang pada akhirnya akan menjadi milik Bob.

Bagi Alice, tidak peduli apakah dia menang atau kalah pada akhirnya, hal yang paling menguntungkan untuk dilakukan adalah menempatkan CET yang benar pada rantai. Menempatkan CET yang tidak valid pada rantai akan membuatnya kehilangan lebih banyak uang.

Sebenarnya, ketika CET yang disebutkan di atas dibangun, tanda tangan schnorr Taproot ditingkatkan, yang dapat dimengerti sebagai menggunakan kunci publik dari orakel + hasil acara untuk membangun alamat independen untuk hasil yang berbeda. Setelah itu, hanya ketika mesin orakel mengumumkan tanda tangan yang sesuai dengan hasil tertentu, BTC yang terkunci pada alamat yang sesuai dengan hasil dapat dihabiskan.

Tentu saja, ada kemungkinan tambahan di sini. Bagaimana jika Alice tahu bahwa dia kalah dan hanya tidak meletakkan CET1 yang dibuatnya di rantai? Ini mudah untuk diatasi karena Bob dapat membuat CET khusus untuk isu 'Alice kalah, Bob menang'. Efek yang dicapai oleh CET ini pada dasarnya sama dengan CET yang dibangun oleh Alice, tetapi detail-detail spesifiknya berbeda, namun hasilnya sama.

Apa yang dijelaskan di atas adalah proses konstruksi CET yang paling kritis. Langkah ketiga DLC adalah bagi Alice dan Bob untuk berkomunikasi, memeriksa transaksi CET yang dikonstruksi oleh pihak lain, dan membawa tanda tangan mereka sendiri pada CET. Setelah pemeriksaan benar, mereka dapat saling mempercayai, dan masing-masing menginvestasikan 1 BTC, mengunci alamat multi-tanda tangan 2/2 yang disebutkan awal dari Alice dan Bob, dan kemudian menunggu CET tertentu diunggah ke rantai untuk memicu proses lanjutan.

Akhirnya, setelah mesin oracle mengumumkan hasil dan mendapatkan tanda tangan mesin oracle pada hasil tersebut, salah satu pihak dapat menempatkan CET yang benar di rantai dan membiarkan 2 BTC yang terkunci di alamat multi-tanda tangan didistribusikan ulang. Jika yang kalah menempatkan CET yang salah di rantai terlebih dahulu, Jika Anda menempatkan CET yang benar di rantai, Anda akan kehilangan semua uang Anda. Jika Anda menempatkan CET yang benar di rantai, pihak yang kalah dapat mendapatkan kembali 0,5 BTC.

Seseorang mungkin bertanya, Bagaimana DLC berbeda dari tanda tangan multi 2/3 reguler? Pertama-tama, jika lebih dari 2/3 ditandatangani, dua pihak dapat berkolusi untuk mencuri semua aset, dan DLC memungkinkan lawan untuk membatasi semua skenario dengan membangun kumpulan CET sebelumnya. Bahkan jika orakel ikut dalam kolusi, Kerusakan yang disebabkan seringkali terbatas.

Kedua, tanda tangan multi memerlukan semua pihak untuk menandatangani transaksi tertentu agar dapat diunggah ke rantai, sementara dalam pengaturan DLC, oracle hanya perlu menandatangani hasil dari peristiwa tertentu. Oracle tidak perlu mengetahui konten CET/transaksi untuk diunggah ke rantai. Bahkan tidak perlu tahu bahwa ada dua orang, Alice dan Bob. Oracle hanya perlu bertindak seperti oracle biasa. Hanya berinteraksi dengan pengguna seperti mesin secara normal.

Kita dapat berpikir bahwa inti dari DLC adalah mengubah kepercayaan dalam peserta tanda tangan ganda menjadi kepercayaan pada orakel. Selama mesin orakel tidak ikut dalam perbuatan jahat, dapat dipastikan bahwa desain protokol DLC cukup dapat dipercaya. Secara teoritis, DLC dapat menggunakan orakel pihak ketiga yang relatif matang dan lengkap untuk menghindari melakukan kejahatan. DLC.link dan BitLayer memanfaatkan fitur DLC ini untuk memindahkan isu kepercayaan dari jembatan ke orakel pihak ketiga.

Selain itu, jembatan DLC Bitlayer juga mendukung node oracle yang dibangun sendiri, menambahkan lapisan bukti penipuan di atasnya. Ketika oracle yang dibangun sendiri menempatkan CET yang tidak valid di rantai, siapa pun dapat menantangnya. Mengenai prinsip jembatan OP-DLC-nya, kami akan menjelaskannya secara singkat di bawah ini.

Jembatan OP-DLC: Saluran DLC + Bukti Penipuan

Kami menjelaskan prinsip operasi jembatan OP-DLC dari seluruh proses deposit dan penarikan. Asumsikan bahwa Alice sekarang mendepositkan 1 BTC ke L2 melalui jembatan OP-DLC, Menurut mekanisme transaksi dua langkah, Mr. ALice menghasilkan transaksi pre-fund, Seperti yang ditunjukkan di bawah ini:

Sebenarnya, transfer 1 BTC ke alamat Taproot yang dikendalikan bersama oleh Alice dan anggota Aliansi BitVM, lalu mulai serangkaian proses untuk membuat CET. Jika anggota Aliansi Jembatan BitVM menolak untuk berkerjasama dengan permintaan deposit Alice, Alice dapat menarik uang tersebut segera setelah kunci waktu berakhir.

Jika anggota Aliansi BitVM bersedia bermitra dengan Alice, kedua belah pihak dapat menggunakan komunikasi di luar rantai untuk pertama-tama menghasilkan transaksi deposito Dana formal (belum di rantai), serta semua CET dalam skenario penarikan. Setelah pembuatan dan verifikasi CET selesai, kedua belah pihak dapat Mengirimkan transaksi Dana ke rantai.

Dalam data Witness/Signature transaksi Dana, Alice akan menentukan alamat pembayarannya di Layer2; Setelah transaksi Dana diunggah ke rantai, Alice dapat mengirimkan data transaksi dana di atas ke kontrak jembatan di Layer 2 untuk membuktikan bahwa dia telah menyelesaikan tindakan deposit di rantai Bitcoin dan berhak atas kontrak jembatan L2 untuk melepaskan Token ke alamat pembayaran yang ditentukan.

Setelah transaksi Dana dipicu, deposito sebenarnya terkunci di alamat multi-tanda tangan Taproot yang dikendalikan bersama oleh Alice dan anggota aliansi BitVM. Namun, perlu diperhatikan bahwa multi-tanda tangan hanya dapat membuka kunci BTC yang terkunci oleh alamat melalui CET, dan Aliansi BitVM tidak dapat mentransfer uang tanpa alasan.

Selanjutnya, mari kita analisis CET yang dibangun lebih awal oleh Alice dan Aliansi BitVM. CET ini digunakan untuk memenuhi skenario potensial untuk penarikan di masa depan. Sebagai contoh, Alice mungkin telah melakukan deposit 1 BTC, tetapi dia hanya menarik 0,3 BTC selama penarikan pertamanya, dan sisa 0,7 BTC diserahkan ke kolam dana publik dari Aliansi BitVM. Untuk mengendalikan, namun jika Anda ingin menarik uang, Anda hanya bisa melalui jembatan BitVM yang disebutkan di atas;

Atau cukup gunakan 0.7 BTC ini untuk memulai deposit pra-pembiayaan baru. Sebagai aset baru yang ditambahkan ke jembatan DLC, Anda dapat mengulangi proses transaksi dana dan konstruksi CET yang disebutkan di atas.

Proses di atas tidak sulit untuk dipahami. Sebenarnya, depositan Alice dan aliansi bitVM bertindak sebagai pihak yang saling berlawanan satu sama lain, menciptakan CET untuk acara penarikan dengan jumlah yang berbeda, dan kemudian membiarkan oracle membaca pernyataan penarikan yang diinisiasi oleh Alice di Layer 2 untuk menentukan transaksi mana yang ingin dipicu oleh Alice. Satu CET (berapa uang yang ingin Anda tarik).

Risikonya di sini adalah mesin oracle mungkin bersekongkol dengan Aliansi BitVM. Misalnya, Alice menyatakan bahwa dia ingin menarik 0,5 BTC, tetapi mesin oracle memalsukan pernyataan penarikan, yang akhirnya menyebabkan “Alice menarik 0,1 BTC dan Aliansi BitVM menerima 0,9 BTC.” Error CET di rantai.

Ada beberapa solusi untuk masalah ini. Yang pertama adalah menggunakan oracle pihak ketiga dengan desain yang relatif lengkap. Mencegah kolusi seperti itu (sangat sulit bagi Aliansi BitVM untuk berkolusi dengan oracle saat ini), atau membiarkan oracle melakukan staking. Oracle perlu secara teratur mempublikasikan Commitment di rantai Bitcoin, menyatakan bahwa telah menangani permintaan penarikan withdrawr dengan jujur. Siapa pun dapat menantang Commitment melalui protokol bukti kecurangan BitVM. Jika tantangan berhasil, oracle jahat akan dipotong.

Di bawah desain jembatan OP-DLC, pengguna selalu dapat "berpartisipasi" dalam aset mereka sendiri untuk mencegah aset disalahgunakan oleh Aliansi BitVM. Selain itu, desain mirip saluran ini memberikan lebih banyak otonomi kepada pengguna, dan juga Tidak perlu mencampur dana sendiri dengan dana orang lain. Lebih mirip solusi deposit dan penarikan sebaya P2P.

Selain itu, Mengingat bahwa akan memerlukan waktu bagi solusi BitVM untuk diimplementasikan, sebelum diimplementasikan, jembatan DLC akan menjadi model pemrosesan jembatan yang lebih dapat diandalkan dibandingkan dengan solusi tandatangan multi-sederhana. Solusi ini juga dapat digunakan sebagai dua pintu masuk deposit dan penarikan utama yang digunakan secara paralel dengan jembatan BitVM. Jika salah satunya gagal, pengguna dapat menggunakan pintu masuk lainnya, yang juga merupakan metode toleransi kesalahan yang baik.

Ringkasan

Solusi jembatan BitLayer dan BitVM dari Citrea pada dasarnya adalah model "pembayaran-mengembalikan uang" yang ada, ada node Operator yang didedikasikan untuk mentransfer uang kepada pengguna penarikan, dan Operator dapat secara teratur mengajukan pengembalian uang ke alamat deposit publik. Jika seorang operator membuat aplikasi pengembalian uang palsu, itu bisa dipertanyakan dan dipotong oleh siapa pun.

Solusi BitVM2 memperkenalkan prapenyataan dan menggabungkan ide dari saluran untuk memungkinkan pengguna membatasi proses penyetoran pos setelah sebelum melakukan deposit formal, dan tidak memberikan kesempatan kepada pejabat jembatan lintas rantai untuk menyalahgunakan deposit pengguna.

Secara teori, tidak ada masalah keamanan dengan jembatan ini, tetapi ada isu ketersediaan, dan tidak bisa memenuhi kebutuhan pengguna spesifik untuk kemandirian dana dan anti pencucian uang (ini pada dasarnya model kolam dana), dan juga sangat sulit untuk diimplementasikan.

Untuk tujuan ini, Bitlayer telah menambahkan solusi jembatan yang disebut OP-DLC, yang mirip dengan DLC.link dan memperkenalkan bukti penipuan berdasarkan saluran dan DLC untuk mencegah mesin orakel jembatan DLC itu berbuat jahat.

Namun karena BitVM terlalu sulit untuk diimplementasikan, jembatan DLC akan diimplementasikan terlebih dahulu dan menjadi pengganti sementara, selama risiko kepercayaan mesin oracle teratasi dan mesin oracle pihak ketiga yang lebih handal dan matang terintegrasi, jembatan DLC dapat menjadi solusi verifikasi penarikan yang lebih aman daripada jembatan multi-tanda tangan pada tahap ini.

Disclaimer：

1. Artikel ini diambil dari [web3 Geek]. Semua hak cipta adalah milik penulis asli [Faust & Nickqiao]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penolakan Tanggung Jawab Kewajiban: Pandangan dan opini yang terdapat dalam artikel ini semata-mata merupakan pandangan dari penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.