Mendekati BTC: Penjelasan Pengetahuan Latar Belakang yang Diperlukan untuk BitVM

Penulis: Nickqiao & Faust & Shew Wang, web3 geek

Konsultan: Tim Riset Bitlayer

Ringkasan:

Baru-baru ini, Delphi Digital merilis laporan riset teknologi terkait lapisan kedua Bitcoin yang berjudul “The Dawn of Bitcoin Programmability: Paving the Way for Rollups”, yang secara sistematis merangkum konsep inti terkait Rollup Bitcoin, seperti BitVM, OP_CAT dan Klausul Pembatas Covenant, lapisan DA dalam ekosistem Bitcoin, jembatan, serta empat lapisan kedua Bitcoin lainnya yang menggunakan BitVM, yaitu Bitlayer, Citrea, Yona, dan Bob.

Meskipun laporan penelitian ini secara umum menampilkan gambaran kasar tentang teknologi layer kedua Bitcoin, namun keseluruhan terlalu abstrak dan kurang mendeskripsikan detailnya, membuat orang merasa tidak begitu paham. Geeks web3 melakukan eksplorasi mendalam yang diperluas berdasarkan laporan Delphi, mencoba membuat lebih banyak orang memahami teknologi seperti BitVM secara sistematis.

Kami akan bekerja sama dengan tim penelitian Bitlayer dan komunitas BitVM Tionghoa untuk meluncurkan serangkaian kolom khusus yang disebut “Mendekati BTC”, yang akan berfokus pada topik utama seperti BitVM, OP_CAT, dan jembatan lintas rantai Bitcoin untuk jangka panjang, berkomitmen untuk menjelaskan teknologi terkait lapisan kedua Bitcoin kepada lebih banyak orang dan membantu penggemar lainnya memahami dengan lebih baik.

Teks utama:

Beberapa bulan yang lalu, pendiri ZeroSync, Robin Linus, merilis artikel berjudul “BitVM: Hitung Apapun di Bitcoin”, secara resmi mengusulkan konsep BitVM, mendorong kemajuan teknologi lapis kedua Bitcoin. Dapat dikatakan bahwa ini adalah salah satu inovasi paling revolusioner dalam ekosistem Bitcoin, yang menciptakan ledakan dalam ekosistem lapis kedua Bitcoin secara keseluruhan, menarik partisipasi proyek-proyek bintang seperti Bitlayer, Citrea, BOB, dan memberikan kehidupan baru bagi seluruh pasar.

Setelah itu, lebih banyak peneliti terlibat dalam perbaikan BitVM, secara berturut-turut merilis berbagai versi iterasi seperti BitVM1, BitVM2, BitVMX, BitSNARK, dan lainnya. Secara umum, situasinya seperti yang terlihat di bawah ini:

1. White Paper implementasi BitVM yang pertama kali diusulkan oleh Robin Linus tahun lalu, adalah solusi implementasi BitVM berbasis rangkaian gerbang logika yang fiktif, yang disebut BitVM0;
2. Dalam beberapa pidato dan wawancara terbarunya, Robin Linus secara informal memperkenalkan solusi BitVM berbasis CPU fiktif (disebut BitVM1), yang mirip dengan sistem bukti penipuan Cannon dari Optimism, yang dapat mensimulasikan efek CPU umum secara off-chain menggunakan skrip Bitcoin.
3. Robin Linus juga mengusulkan BitVM2, sebuah protokol bukti penipuan satu-langkah yang tidak bergantung pada izin interaktif.
4. Anggota Rootstock Labs dan Fairgate Labs menerbitkan White Paper BitVMX, mirip dengan BitVM1, mereka berharap dapat mensimulasikan efek CPU umum melalui skrip Bitcoin (off-chain).

Pembangunan ekosistem pengembang terkait BitVM semakin jelas, dan peningkatan alat-alat sekitarnya juga sudah terlihat secara nyata. Dibandingkan dengan tahun lalu, ekosistem BitVM sekarang sudah tidak lagi seperti ‘castle in the air’, dan semakin menarik bagi para pengembang dan VC untuk memasuki ekosistem Bitcoin.

Namun, bagi kebanyakan orang, memahami istilah teknis yang terkait dengan BitVM dan lapisan kedua Bitcoin bukanlah hal yang mudah, karena Anda harus memiliki pemahaman yang sistematis tentang pengetahuan dasar di sekitarnya, terutama skrip Bitcoin dan latar belakang Taproot. Saat ini, referensi online yang tersedia entah terlalu panjang dan berbelit-belit, atau penjelasannya tidak cukup mendalam sehingga sulit dipahami. Kami berkomitmen untuk memecahkan masalah tersebut dengan menggunakan bahasa yang sejelas mungkin untuk membantu lebih banyak orang memahami pengetahuan seputar lapisan kedua Bitcoin dan membangun pemahaman yang sistematis tentang sistem BitVM.

MATT dan Janji: Dasar-dasar BitVM

Pertama-tama, kami ingin menekankan bahwa gagasan dasar BitVM adalah MATT, yang berarti Merkleize Semua Hal, yang secara utama mengacu pada proses eksekusi program yang kompleks melalui struktur penyimpanan data berbentuk pohon Merkle Tree, berupaya untuk memungkinkan pembuktian penipuan verifikasi Native Bitcoin.

Meskipun MATT dapat mengungkapkan jejak program kompleks dan pengolahan data, data ini tidak akan dipublikasikan langsung di blockchain BTC karena ukuran keseluruhan data tersebut sangat besar. Solusi MATT menggunakan penyimpanan data di luar blockchain dalam Merkle Tree, hanya merilis ringkasan teratas Merkle Tree (Merkle Root) ke blockchain. Merkle Tree ini terutama berisi tiga konten inti:

• Kode Skrip Kontrak Pintar
• Data yang diperlukan oleh kontrak
• Jejak yang Ditinggalkan oleh Eksekusi Kontrak (Catatan Perubahan Memori, CPU Register yang Dihasilkan oleh Kontrak Pintar saat Beroperasi di Mesin Virtual Seperti EVM)

Di bawah skema MATT, hanya Merkle Root dengan ukuran sangat kecil yang disimpan di atas rantai, Merkle Tree yang berisi kumpulan data lengkap disimpan di luar rantai, ini melibatkan pendekatan yang disebut sebagai ‘Commitment’. Di sini dijelaskan apa itu ‘Commitment’ (Komitmen).

Komitmen mirip dengan pernyataan ringkas, yang dapat dipahami sebagai “sidik jari” dari sejumlah besar data terkompresi. Secara umum, orang yang mempublikasikan “janji” di on-chain akan mengklaim bahwa beberapa data yang disimpan off-chain akurat, dan bahwa data off-chain ini sesuai dengan pernyataan singkat, yang disebut “komitmen”.

Terkadang, hash data dapat digunakan sebagai “komitmen” terhadap data itu sendiri, dengan skema komitmen lain seperti komitmen KZG atau Merkle Tree. Dalam protokol bukti penipuan yang umum digunakan di Layer2, pengirim data akan mempublikasikan dataset lengkap di luar rantai dan mengirimkan komitmen dataset di atas rantai. Jika seseorang menemukan data yang tidak valid dalam dataset di luar rantai, mereka dapat menantang komitmen data di atas rantai.

Melalui komitmen (Commitment), lapisan kedua dapat melakukan kompresi data dalam jumlah besar, hanya mengunggah ‘komitmen’ nya ke dalam rantai Bitcoin. Tentu saja, juga harus memastikan bahwa kumpulan data lengkap yang diunggah ke luar rantai dapat diamati oleh pihak eksternal.

Saat ini, beberapa solusi BitVM utama seperti BitVM0, BitVM1, BitVM2, dan BitVMX semuanya menggunakan struktur abstrak yang serupa:

1. Decompiling and commitment: First, decompose complex programs into a large number of basic opcodes (compiling), then record the traces generated during the specific execution of these opcodes (which is essentially the state changes when a program runs in the CPU and memory, known as Trace). Afterwards, we organize all the data including Trace and opcodes into a dataset, and then generate a commitment for this dataset.

Ada beberapa bentuk rencana komitmen yang khusus, seperti: pohon Merkle, PIOPs (berbagai algoritma ZK), fungsi hash

2. Staking aset dan pra-tanda tangan: Penerbit data dan validator perlu mengunci sejumlah aset pada rantai dengan bentuk pra-tanda tangan, dan akan ada kondisi pembatasan. Kondisi-kondisi tersebut akan diaktifkan secara khusus untuk situasi yang mungkin terjadi di masa depan. Jika penerbit data berbuat jahat, validator dapat mengajukan bukti untuk mengambil aset penerbit data.

3. Publikasi Data dan Komitmen: Penerbit data mempublikasikan komitmen di atas rantai, dan menerbitkan kumpulan data lengkap di luar rantai. Validator mengambil kumpulan data dan memeriksa apakah ada kesalahan. Setiap bagian dalam kumpulan data di luar rantai terkait dengan komitmen di atas rantai.

4. Tantangan dan hukuman: Setelah validator menemukan bahwa data yang diberikan oleh penerbit data salah, validator akan membawa bagian data ini ke on-chain untuk verifikasi langsung (untuk memotong bagian data ini dengan sangat halus terlebih dahulu), yang merupakan logika bukti penipuan. Jika hasil verifikasi menunjukkan bahwa penerbit data memang memberikan data yang tidak valid off-chain, asetnya akan diambil oleh validator yang menantangnya.

Intinya, pembuat data Alice secara terbuka di lapisan kedua di luar rantai, menghasilkan semua jejak pelaksanaan transaksi, dan menerbitkan komitmen yang sesuai ke rantai. Jika Anda perlu membuktikan bahwa sebagian data tersebut tidak benar, pertama-tama buktikan ke node Bitcoin bahwa data tersebut terkait dengan komitmen di rantai, yaitu buktikan bahwa data tersebut secara terbuka oleh Alice, dan kemudian biarkan node Bitcoin menentukan bahwa data tersebut salah.

Sekarang kita memiliki pemahaman kasar tentang konsep umum BitVM, dan hampir semua variasi BitVM tidak lepas dari paradigma di atas. Jadi, selanjutnya, mari kita mulai belajar dan memahami beberapa teknologi penting yang digunakan dalam proses di atas, mulai dari skrip Bitcoin yang paling dasar, Taproot, dan pra-tanda tangan.

Apa itu skrip Bitcoin

Pengetahuan terkait Bitcoin jauh lebih sulit untuk dipahami daripada Ethereum, bahkan tindakan transfer paling dasar melibatkan serangkaian konsep, termasuk UTXO (Unspent Transaction Output), skrip kunci (juga dikenal sebagai PubKey), dan skrip pembuka kunci (juga dikenal sebagai Sig). Mari kita jelaskan konsep-konsep utama ini terlebih dahulu.

(Contoh kode skrip Bitcoin yang terdiri dari opcode yang lebih rendah tingkat daripada bahasa tingkat tinggi)

Cara menyatakan aset Ethereum lebih mirip Alipay atau WeChat, di mana setiap kali transfer hanya dilakukan dengan melakukan penjumlahan atau pengurangan saldo pada akun yang berbeda. Metode ini berpusat pada akun, dan saldo aset hanyalah angka di bawah nama akun. Sedangkan, cara menyatakan aset Bitcoin lebih mirip emas, di mana setiap blok emas (UTXO) akan menandakan pemiliknya. Transfer sebenarnya adalah menghancurkan UTXO lama dan menghasilkan UTXO baru (pemilik akan berubah).

UTXO Bitcoin mengandung dua bidang kunci:

Jumlah, diukur dalam satuan ‘Satoshi’ (satu miliar Satoshi sama dengan satu BTC);

Skrip terkunci, juga dikenal sebagai “kunci publik skrip (PubKey)”, akan mendefinisikan kondisi penguncian UTXO.

Perlu diingat bahwa kepemilikan UTXO Bitcoin diungkapkan melalui skrip kunci, jika Anda ingin mentransfer UTXO Anda ke Sam, Anda dapat memulai transaksi yang menghancurkan beberapa UTXO Anda, menulis kondisi membuka kunci untuk UTXO baru yang dibuat sebagai ‘Hanya Sam yang dapat membukanya’.

Kemudian, jika Sam ingin menggunakan Bitcoin ini, dia perlu mengirimkan sebuah skrip pelucutan (Sig), di mana Sam harus menunjukkan tanda tangan digitalnya sendiri untuk membuktikan bahwa dia adalah dirinya sendiri. Jika skrip pelucutan cocok dengan skrip penguncian sebelumnya, Sam dapat membuka kunci dan mentransfer Bitcoin ini ke orang lain lagi.

（Kunci skrip harus cocok dengan skrip kunci）

Dari segi bentuknya, setiap transaksi Bitcoin on-chain secara visual memiliki banyak Input dan Output, di mana setiap Input harus menyatakan UTXO tertentu yang ingin di-unlock, dan mengirimkan skrip unlock, yang kemudian akan menghancurkan UTXO tersebut; Output akan menampilkan informasi UTXO yang baru dibuat, serta menunjukkan konten skrip kunci publik.

Misalnya, dalam Input transaksi, Anda membuktikan diri Anda sebagai Sam, membuka kunci beberapa UTXO yang diberikan orang lain kepada Anda, menghancurkannya secara bersamaan, kemudian menghasilkan beberapa UTXO baru dan menyatakan untuk mengizinkan xxx membuka kunci di masa depan.

Secara khusus, dalam data Input transaksi, Anda perlu menyatakan UTXO mana yang ingin Anda buka kunci dan menunjukkan ‘lokasi penyimpanan’ data UTXO tersebut. Di sini perlu diperhatikan bahwa Bitcoin dan Ethereum sangat berbeda. Ethereum menyediakan dua jenis akun, yaitu akun kontrak dan akun EOA untuk menyimpan data. Saldo aset, dalam bentuk angka, dicatat di bawah nama akun kontrak atau akun EOA, yang secara bersamaan disimpan dalam database yang disebut ‘status dunia’. Saat mentransfer, perubahan langsung dilakukan pada akun tertentu dari ‘status dunia’, sehingga memudahkan untuk menemukan lokasi penyimpanan data.

Bitcoin tidak dirancang memiliki status dunia, data aset disimpan secara terdesentralisasi di dalam blok masa lalu (yaitu data UTXO yang belum dihabiskan, disimpan secara terpisah di setiap Output transaksi).

Jika Anda ingin membuka kunci UTXO tertentu, Anda harus menunjukkan bahwa informasi UTXO tersebut ada di Output transaksi mana di masa lalu, menunjukkan ID transaksi (yaitu hash)-nya, dan membiarkan node Bitcoin mencari dalam catatan sejarah. Jika ingin menanyakan saldo Bitcoin dari alamat tertentu, perlu dilakukan pencarian dari awal blok untuk menemukan UTXO yang terkait dengan alamat xx yang belum dibuka kunci.

Saat menggunakan Dompet Bitcoin, Anda dapat dengan cepat memeriksa saldo Bitcoin yang dimiliki oleh suatu alamat. Sering kali ini karena layanan Dompet telah memindai Blok dan membuat indeks untuk semua alamat, sehingga memudahkan kita dalam melakukan pencarian cepat.

(Saat Anda menghasilkan pernyataan transaksi untuk mengirimkan UTXO Anda kepada orang lain, tandai posisi UTXO tersebut dalam catatan sejarah Bitcoin berdasarkan hash/ID transaksi yang dimilikinya)

Menariknya, hasil transaksi Bitcoin dihitung off-chain, dan ketika pengguna menghasilkan transaksi di perangkat lokal, mereka harus langsung membuat semua Input dan Output, yang setara dengan menghitung output transaksi. Transaksi disiarkan ke jaringan Bitcoin dan diverifikasi oleh Node sebelum on-chain. Model “perhitungan off-chain - verifikasi on-chain” ini benar-benar berbeda dari Ethereum, dalam Ethereum, Anda hanya perlu memberikan parameter input transaksi, dan hasil transaksi dihitung dan dikeluarkan oleh Ethereum Node.

Selain itu, skrip kunci UTXO (Locking) dapat disesuaikan, Anda dapat menetapkan UTXO sebagai ‘dapat di-unlock oleh pemilik alamat Bitcoin tertentu’, pemilik alamat tersebut perlu menyediakan tanda tangan digital dan kunci publik (P2PKH). Sedangkan dalam jenis transaksi Pay-to-Hash (P2SH), Anda dapat menambahkan Hash dalam skrip kunci UTXO, siapa pun yang dapat mengirimkan pre-image skrip yang sesuai dengan Hash ini dan memenuhi kondisi yang ditetapkan dalam pre-image skrip tersebut, dapat membuka kunci UTXO. Skrip Taproot yang dibutuhkan oleh BitVM menggunakan fitur yang mirip dengan P2SH.

Bagaimana Skrip Bitcoin Dipicu

Di sini kita akan menggunakan P2PKH sebagai contoh untuk menjelaskan cara memicu skrip Bitcoin, hanya dengan memahami cara memicunya, kita dapat memahami Taproot dan BitVM yang lebih kompleks. P2PKH adalah singkatan dari “Pay to Public Key Hash”, dalam skema ini, skrip kunci penguncian UTXO akan mengatur hash kunci publik, saat membuka kunci, kita perlu menyampaikan kunci publik yang sesuai dengan hash tersebut, ini mirip dengan pendekatan transfer Bitcoin konvensional.

Pada saat ini, node Bitcoin harus memastikan bahwa kunci publik dalam skrip pembuka terkunci dan hash kunci publik yang ditentukan dalam skrip kunci terkunci cocok, dengan kata lain, harus memastikan bahwa “kunci” yang diajukan oleh orang yang membuka terkunci dan “kunci” yang ditetapkan oleh UTXO cocok satu sama lain.

Selanjutnya, dalam skema P2PKH, setelah menerima transaksi, node Bitcoin akan menggabungkan skrip tanda tangan yang diberikan oleh pengguna dengan skrip kunci publik yang mengunci UTXO yang ingin dibuka, kemudian menjalankannya dalam lingkungan eksekusi skrip BTC. Gambar di bawah ini menunjukkan hasil penggabungan sebelum dieksekusi:

Mungkin pembaca tidak memahami lingkungan eksekusi skrip BTC, jadi kami akan memberikan pengantar singkat di sini. Pertama, skrip BTC terdiri dari dua elemen:

Data dan opcode. Data dan opcode ini akan didorong ke dalam tumpukan dan dieksekusi sesuai dengan urutan dari kiri ke kanan sesuai dengan logika yang ditentukan, untuk mendapatkan hasil akhir (mengenai apa itu tumpukan, ini tidak akan dijelaskan di sini, pembaca dapat mencari sendiri Chatgpt).

Dalam contoh di atas, sisi kiri adalah Skrip Pembukaan yang diunggah oleh seseorang, yang mencakup tanda tangan digitalnya dan kunci publiknya, sedangkan di sisi kanan adalah Skrip Penguncian Pubkey yang mencakup kode operasi dan data yang ditetapkan oleh pencipta UTXO saat menciptakan UTXO tersebut (di sini, kita tidak perlu memahami arti dari setiap kode operasi, hanya memahami secara umum sudah cukup)

Operasi kode DUP, HASH160, EQUALVERIFY, dan lainnya dalam skrip kunci terkunci di sebelah kanan gambar di atas bertanggung jawab untuk mengambil hash kunci publik yang dibawa oleh skrip kunci terbuka di sebelah kiri dan membandingkannya dengan hash kunci publik yang telah ditentukan dalam skrip kunci terkunci. Jika keduanya sama, itu berarti kunci publik yang diunggah dalam skrip kunci terbuka cocok dengan hash kunci publik yang ditentukan dalam skrip kunci terkunci, dan ini melewati verifikasi pertama.

Namun, ada masalah, konten skrip kunci UTXO sebenarnya terbuka di atas rantai, siapa pun dapat mengamati hash kunci publik yang terkandung di dalamnya, siapa pun dapat mengunggah kunci publik yang sesuai, dan mengklaim diri mereka sebagai orang yang ‘ditunjuk’. Oleh karena itu, setelah memverifikasi kunci publik dan hash kunci publik, kita juga perlu memverifikasi apakah pengirim transaksi benar-benar pemegang kontrol dari kunci publik tersebut, ini melibatkan verifikasi tanda tangan digital. OPCODE CHECKSIG dalam skrip kunci UTXO bertanggung jawab untuk memverifikasi tanda tangan digital.

Secara singkat, dalam skema P2PKH, skrip unlock yang diajukan oleh pengirim transaksi berisi kunci publik dan tanda tangan digital. Kunci publik ini harus sesuai dengan hash kunci publik yang ditentukan dalam skrip kunci gembok, dan tanda tangan digital transaksi harus benar, agar dapat membuka UTXO dengan lancar.

（Gambar ini bersifat dinamis: Diagram ilustrasi skrip pembukaan Bitcoin di bawah skema P2PKH

Sumber:** )

Tentu saja, dalam jaringan Bitcoin, ada berbagai jenis transaksi yang didukung, bukan hanya Pay to public key / public key hash, tetapi juga P2SH (Pay to hash), tergantung pada bagaimana skrip kunci ganda yang ditentukan saat UTXO dibuat.

Hal yang perlu diperhatikan di sini, dalam skema P2SH, script penguncian dapat memiliki Hash yang telah ditetapkan sebelumnya, sementara script pembukaan harus mengirimkan konten script yang sesuai dengan Hash secara lengkap. Node Bitcoin dapat menjalankan script ini, jika script ini mendefinisikan logika verifikasi multi-tanda tangan, maka efek dompet multi-tanda tangan dapat diimplementasikan pada rantai Bitcoin.

Tentu saja, di bawah skema P2SH, pencipta UTXO harus memastikan bahwa orang yang akan membuka kunci UTXO di masa depan sudah tahu konten skrip yang sesuai dengan Hash, asalkan kedua belah pihak mengetahui konten ini, kita dapat menerapkan logika bisnis yang lebih kompleks daripada multi-tanda tangan.

Di sini perlu ditekankan bahwa Bitcoin on-chain (Blok) tidak langsung mencatat UTXO mana yang terkait dengan alamat mana, ia hanya mencatat UTXO yang dapat di-unlock oleh hash kunci publik / hash skrip mana, tetapi kita dapat dengan cepat menghitung alamat yang sesuai berdasarkan hash kunci publik / hash skrip (yang ditampilkan sebagai teks acak di antarmuka dompet).

Alasan kita bisa melihat jumlah Bitcoin di alamat xx di browser blok dan antarmuka dompet adalah karena pihak proyek browser blok dan dompet membantu Anda menganalisis data tersebut, akan memindai semua blok dan menghitung “alamat” yang sesuai berdasarkan hash kunci publik / hash skrip yang dinyatakan dalam skrip kunci, dan kemudian menunjukkan berapa banyak Bitcoin yang dimiliki oleh alamat xx.

Segregated Witness dan Witness

Setelah kita memahami konsep P2SH, kita menjadi lebih dekat dengan Taproot yang digunakan oleh BitVM. Namun sebelum itu, kita perlu memahami konsep penting lainnya: Witness dan Segregated Witness.

Ketika kita mereview skrip unlock dan skrip kunci yang disebutkan sebelumnya, serta proses unlock UTXO, kita akan menemukan satu masalah: tanda tangan transaksi termasuk dalam skrip unlock, dan saat menghasilkan tanda tangan, tidak mungkin untuk menyisipkan skrip unlock (parameter yang digunakan untuk menghasilkan tanda tangan tidak boleh mencakup tanda tangan itu sendiri), sehingga tanda tangan hanya bisa menyisipkan bagian di luar skrip unlock, yaitu hanya bisa terhubung dengan bagian utama data transaksi, tidak bisa sepenuhnya menyisipkan data transaksi.

Dengan demikian, bahkan jika skrip pembukaan transaksi dimodifikasi oleh perantara, itu tidak akan memengaruhi hasil verifikasi. Misalnya, node Bitcoin atau Pool Penambangan dapat menyisipkan data lain ke dalam skrip pembukaan transaksi, sehingga data transaksi mengalami perubahan kecil tanpa memengaruhi verifikasi dan hasil transaksi, yang akhirnya akan mengubah hash transaksi/ID transaksi yang dihitung. Ini dikenal sebagai masalah ekstensibilitas transaksi.

Kerugiannya adalah, jika Anda berencana untuk melakukan beberapa transaksi secara berurutan dan memiliki ketergantungan urutan (misalnya, transaksi 3 merujuk pada output transaksi 2, transaksi 2 merujuk pada output transaksi 1), maka transaksi yang berada di belakang pasti harus merujuk pada ID (hash) transaksi sebelumnya, pool penambangan atau node Bitcoin, atau pihak ketiga apa pun dapat memodifikasi konten dalam skrip pembukaan kunci, sehingga hash dari transaksi yang diunggah ke rantai tidak sesuai dengan yang Anda harapkan, sehingga banyak transaksi yang Anda buat sebelumnya yang saling terkait akan menjadi tidak valid.

Sebenarnya, dalam skema jembatan DLC dan BitVM2, transaksi yang berurutan secara massal akan dibangun, jadi skenario yang disebutkan sebelumnya tidak jarang terjadi.

Secara sederhana, masalah ekspansi transaksi disebabkan oleh fakta bahwa ID/hash transaksi menghitung data skrip penguncian, dan mediator seperti node Bitcoin dapat menyesuaikan konten skrip penguncian, yang menyebabkan ID transaksi tidak sesuai dengan yang diharapkan oleh pengguna. Sebenarnya, ini adalah beban sejarah yang ditinggalkan oleh Bitcoin pada saat desain awalnya kurang matang.

Upgrade SegWit yang diperkenalkan kemudian sebenarnya adalah memisahkan sepenuhnya ID transaksi dan skrip pembuka kunci, sehingga saat menghitung hash transaksi tidak perlu menyertakan data skrip pembuka kunci. Skrip kunci terkunci UTXO yang mengikuti upgrade SegWit akan secara default menetapkan opcode bernama “OP_0” di posisi pertama sebagai tanda; sedangkan skrip pembuka kunci yang sesuai telah diubah namanya menjadi Witness (saksi).

Setelah mengikuti aturan Segregated Witness, masalah keterluasan transaksi akan diatasi dengan baik. Anda tidak perlu khawatir bahwa data transaksi yang dikirim ke node Bitcoin akan dimodifikasi. Tentu saja, kita tidak perlu mempersulit hal-hal, fungsi P2WSH sama dengan P2SH yang telah dibahas sebelumnya. Anda dapat menetapkan hash skrip di dalam skrip kunci penguncian UTXO, dan saat pengirim skrip membuka kunci dan mengirimkan konten skrip yang sesuai dengan hash ke jaringan dan mengeksekusinya.

Namun jika Anda ingin menerapkan konten skrip yang sangat besar, mengandung banyak kode, tidak mungkin untuk mengirimkan skrip lengkap ke dalam rantai Bitcoin dengan metode konvensional (setiap blok memiliki batasan ukuran). Apa yang harus dilakukan? Ini memerlukan bantuan Taproot, untuk menyederhanakan konten skrip yang akan dipasang, dan BitVM adalah solusi kompleks yang dibangun berdasarkan Taproot.