1 Pengantar

Untuk algoritma f, dua peserta yang saling tidak percaya, Alice dan Bob, dapat membangun kepercayaan dengan cara berikut:

1. Alice memasukkan x, menjalankan algoritma f, dan mendapatkan hasil y. Bob juga menjalankan algoritma f dengan input x yang sama, menghasilkan y′. Jika y = y′, maka Bob mengakui input x yang diberikan oleh Alice dan output y. Ini adalah mekanisme bukti validitas khusus yang umum digunakan dalam konsensus blockchain, di mana Alice adalah node yang mengemas blok dan Bob adalah node yang berpartisipasi dalam konsensus.
2. Alice memasukkan x, menjalankan program zk.prove pada algoritma f, dan mendapatkan hasil y dan bukti proof. Bob menjalankan program zk.verify berdasarkan f, y, dan proof. Jika hasilnya benar, maka Bob mengakui hasil y dari Alice; jika hasilnya salah, maka Bob tidak mengakui hasil y dari Alice. Ini adalah bukti validitas, di mana Bob dapat menjadi kontrak on-chain.
3. Alice memasukkan x, menjalankan algoritma f, dan mendapatkan hasil y. Bob juga menjalankan algoritma f dengan input x yang sama, menghasilkan y′. Jika y = y′, maka tidak ada yang dilakukan; jika y ≠ y′, maka Bob menantang Alice, dengan program yang ditantang adalah f. Jumlah interaksi antara Alice dan Bob dapat satu atau beberapa. Arbitrase dicapai melalui proses tantangan-respon. Ini adalah bukti penipuan, di mana Bob adalah penantang, mendengarkan di luar jaringan dan menantang di jaringan.
4. Alice memasukkan x, menjalankan program zk.prove pada algoritma f, dan mendapatkan hasil y dan bukti proof. Bob menjalankan program zk.verify berdasarkan f, y, dan proof. Jika hasilnya benar, maka tidak ada yang dilakukan; jika hasilnya salah, maka Bob menantang Alice, dengan program yang ditantang adalah zk.verify. Jumlah interaksi antara Alice dan Bob dapat menjadi satu atau beberapa. Arbitrase dicapai melalui proses tantangan-respons. Ini adalah bukti penipuan, di mana Bob adalah penantang, mendengarkan di luar rantai dan menantang di dalam rantai.

Untuk yang di atas 2, 3, dan 4, biarkan x menjadi transaksi Layer2 dan keadaan awal, f menjadi program konsensus Layer2, dan y menjadi keadaan akhir transaksi, sesuai dengan solusi skala Layer2 blockchain. Di antaranya:

• Bukti Validitas: Berdasarkan asumsi pesimis, harus dibuktikan valid sebelum diterima, dan berlaku segera. Dalam bukti validitas, bukti transisi keadaan L2 yang benar harus disediakan, mencerminkan pandangan pesimis terhadap dunia—hanya ketika suatu keadaan terbukti benar akan diterima.
• Bukti Penipuan: Berdasarkan asumsi optimis, bukti tersebut diterima secara default kecuali ada yang membuktikan bahwa itu salah. Ada jendela tantangan periode yang hanya efektif setelah jendela tantangan. Dalam bukti penipuan, harus disediakan bukti transisi status L2 yang salah, mencerminkan pandangan optimis dunia—transisi status dianggap benar kecuali dibuktikan sebaliknya.

Tabel 1: Cara Membangun Kepercayaan

Selain itu, penting untuk dicatat:

• Kunci untuk membedakan antara bukti penipuan dan bukti validitas bukanlah apakah sistem bukti ZK seperti SNARK/STARK digunakan. Sistem bukti ZK mengungkapkan metode bukti yang digunakan, sedangkan penipuan atau validitas mewakili konten yang dibuktikan. Inilah mengapa skenario 1 dalam Tabel 1 dikatakan mewakili bukti validitas.
• Bukti validitas memiliki ketepatan waktu yang lebih baik, tetapi kompleksitas verifikasi on-chain relatif tinggi; bukti penipuan memiliki kompleksitas verifikasi on-chain yang lebih rendah, tetapi ketepatannya relatif buruk.
• Untuk kasus 2 dan 4 di Tabel 1, dengan menggunakan teknik ZK rekursi dan kombinasi, beberapa f dapat dihitung dan dikompres, yang secara signifikan mengurangi biaya verifikasi komputasi di luar rantai di atas rantai.

Saat ini, berkat kontrak pintar yang berbasis Turing lengkap dari Solidity, teknologi bukti penipuan dan bukti validitas secara luas digunakan dalam skala Layer2 Ethereum. Namun, di bawah paradigma Bitcoin, terbatas oleh fungsionalitas opcode terbatas Bitcoin, 1000 elemen tumpukan, dan pembatasan lainnya, aplikasi teknologi ini masih dalam tahap eksplorasi. Artikel ini merangkum keterbatasan dan teknologi terobosan di bawah paradigma Bitcoin dalam konteks skala Layer2 Bitcoin, mempelajari teknologi bukti validitas dan bukti penipuan, dan menguraikan teknologi segmentasi skrip yang unik di bawah paradigma Bitcoin.

2 Batasan dan Terobosan di bawah Paradigma Bitcoin

Ada banyak keterbatasan dalam paradigma Bitcoin, namun berbagai metode atau teknik cerdik dapat digunakan untuk mengatasi keterbatasan tersebut. Misalnya, komitmen bit dapat menembus keterbatasan stateless UTXO, taproot dapat menembus keterbatasan ruang skrip, output konektor dapat menembus keterbatasan metode pengeluaran UTXO, dan kontrak dapat menembus keterbatasan prapenandatanganan.

Model UTXO 2.1 dan Batasan Skrip

Bitcoin mengadopsi model UTXO, di mana setiap UTXO terkunci dalam skrip penguncian yang menentukan kondisi yang harus dipenuhi untuk menghabiskan UTXO tersebut. Skrip Bitcoin memiliki batasan-batasan berikut:

1. Skrip Bitcoin tidak memiliki status;
2. Untuk jenis output P2TR, jumlah maksimum opcode yang bisa diakomodasi dalam satu transaksi adalah sekitar 4 juta, mengisi seluruh blok, sedangkan untuk jenis output lainnya, hanya ada 10.000 opcode;
3. Metode pengeluaran UTXO tunggal terbatas, kurang eksplorasi metode pengeluaran yang dikombinasikan;
4. Fungsi kontrak fleksibel tidak didukung;
5. Ukuran tumpukan dibatasi maksimum 1000 elemen (altstack + stack), dan ukuran maksimum dari satu elemen adalah 520 byte;
6. Operasi aritmatika (seperti penambahan dan pengurangan) terbatas pada elemen 4 byte. Mereka tidak dapat dimodifikasi menjadi elemen panjang, seperti 20 byte atau lebih besar, yang diperlukan untuk operasi kriptografis;
7. Opcodes seperti OPMUL dan OPCAT telah dinonaktifkan, dan mensimulasikannya dengan opcode yang ada menimbulkan biaya yang sangat tinggi, seperti mensimulasikan hash BLAKE3 satu putaran, dengan ukuran skrip sekitar 75K.

2.2 Komitmen Bit: Menembus Batasan UTXO Stateless

Saat ini, skrip Bitcoin benar-benar stateless. Saat mengeksekusi skrip Bitcoin, lingkungan eksekusinya diatur ulang setelah setiap skrip. Hal ini menyebabkan ketidakmampuan skrip Bitcoin untuk secara native mendukung skrip kendala 1 dan 2 yang memiliki nilai x yang sama. Namun, masalah ini dapat dielakkan melalui beberapa metode, dengan ide intinya adalah menandatangani nilai dengan cara tertentu. Jika tanda tangan dapat dibuat untuk suatu nilai, dimungkinkan untuk mencapai skrip Bitcoin stateful. Artinya, dengan memeriksa tanda tangan nilai x dalam skrip 1 dan 2, dapat ditegakkan bahwa nilai x yang sama digunakan di kedua skrip. Jika ada tanda tangan yang bertentangan, artinya dua nilai berbeda ditandatangani untuk variabel x yang sama, penalti dapat diterapkan. Solusi ini dikenal sebagai komitmen bit.

Prinsip komitmen bit relatif sederhana. Bit mengacu pada mengatur dua nilai hash yang berbeda, hash0 dan hash1, untuk setiap bit dalam pesan yang akan ditandatangani. Jika nilai bit yang akan ditandatangani adalah 0, preimage0 dari hash0 diungkapkan; jika nilai bit yang akan ditandatangani adalah 1, preimage1 dari hash1 diungkapkan.

Mengambil pesan bit tunggal m ∈{0,1} sebagai contoh, skrip kunci bukaan komitmen bit yang sesuai hanyalah beberapa preimage: jika nilai bit adalah 0, skrip bukaan kunci yang sesuai adalah preimage0 - “0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140”; jika nilai bit adalah 1, skrip bukaan kunci yang sesuai adalah preimage1 - “0x47c31e611a3bd2f3a7a42207613046703fa27496”. Oleh karena itu, dengan komitmen bit, dimungkinkan untuk menembus batasan tanpa keadaan UTXO dan mencapai skrip Bitcoin yang berkeadaan, sehingga memungkinkan berbagai fitur baru yang menarik.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Ini adalah hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Ini adalah hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// Sekarang nilai komitmen bit ada di tumpukan. Entah "0" atau "1".

Saat ini, ada 2 implementasi komitmen bit:

• Tanda Tangan Satu Kali Lamport: Prinsipnya relatif sederhana dan hanya membutuhkan penggunaan fungsi hash, sehingga ramah terhadap Bitcoin. Untuk setiap bit dalam pesan, dua nilai hash perlu dikomunikasikan, menghasilkan data tanda tangan yang relatif besar. Dengan kata lain, untuk pesan dengan panjang v bit, panjang kunci publik adalah 2v bit, dan panjang tanda tangan adalah v bit.
• Tanda Tangan Satu Kali Winternitz: Dibandingkan dengan tanda tangan Lamport, ini secara signifikan mengurangi panjang tanda tangan dan kunci publik tetapi meningkatkan kompleksitas tanda tangan dan verifikasi. Skema ini memungkinkan pengaturan yang fleksibel dari panjang rantai hash yang berbeda d, sehingga seimbang antara panjang dan kompleksitas. Misalnya, mengatur d = 15 menghasilkan panjang kunci publik dan panjang tanda tangan sekitar 4 kali lebih pendek, tetapi kompleksitas verifikasi akan meningkat 4 kali. Ini pada dasarnya adalah kompromi antara ruang stack dan ukuran skrip Bitcoin. Tanda tangan Lamport dapat dilihat sebagai kasus khusus dari tanda tangan Winternitz ketika d = 1.

Saat ini, perpustakaan BitVM2 mengimplementasikan tanda tangan Winternitz berdasarkan fungsi hash Blake3. Panjang tanda tangan yang sesuai dengan satu bit adalah sekitar 26 byte. Oleh karena itu, dapat terlihat bahwa memperkenalkan keadaan melalui komitmen bit membutuhkan biaya. Oleh karena itu, dalam implementasi BitVM2, pesan pertama kali di-hash untuk mendapatkan nilai hash 256 bit, dan kemudian komitmen bit dilakukan pada nilai hash untuk menghemat overhead, daripada melakukan komitmen pada setiap bit pesan asli yang lebih panjang secara langsung.

2.3 Taproot: Menembus Batasan Ruang Skrip

Peningkatan soft fork Bitcoin Taproot, diaktifkan pada November 2021, mencakup tiga proposal: tanda tangan Schnorr (BIP 340), Taproot (BIP 341), dan TapScript (BIP 342). Ini memperkenalkan jenis transaksi baru — transaksi Pay-to-Taproot (P2TR). Transaksi P2TR dapat menciptakan format transaksi yang lebih pribadi, fleksibel, dan terukur dengan menggabungkan keunggulan tanda tangan Taproot, MAST (Merkel Abstract Syntax Tree), dan Schnorr.

P2TR mendukung dua metode pengeluaran: pengeluaran sesuai dengan jalur kunci atau jalur skrip.

Menurut ketentuan dalam Taproot (BIP 341), saat menghabiskan melalui jalur skrip, jalur Merkle yang sesuai tidak boleh melebihi panjang maksimum 128. Ini berarti bahwa jumlah tapleaf dalam pohon tap tidak boleh melebihi 2^128. Sejak upgrade SegWit pada tahun 2017, jaringan Bitcoin mengukur ukuran blok dalam unit berat, dengan dukungan maksimum 4 juta unit berat (sekitar 4MB). Ketika output P2TR dihabiskan melalui jalur skrip, hanya perlu mengungkapkan satu skrip tapleaf, artinya blok dikemas dengan satu skrip tapleaf. Ini berarti bahwa untuk transaksi P2TR, ukuran skrip yang sesuai untuk setiap tapleaf bisa maksimal sekitar 4MB. Namun, dalam kebijakan default Bitcoin, banyak node hanya meneruskan transaksi yang lebih kecil dari 400K; transaksi yang lebih besar perlu bekerja sama dengan penambang untuk dikemas.

Kehadiran ruang skrip yang ditingkatkan oleh Taproot membuatnya lebih berharga untuk mensimulasikan operasi kriptografi seperti perkalian dan hashing menggunakan opcode yang sudah ada.

Saat membangun komputasi yang dapat diverifikasi berdasarkan P2TR, ukuran skrip yang sesuai tidak lagi terbatas pada batasan 4MB, tetapi dapat dibagi menjadi beberapa sub-fungsi yang didistribusikan di beberapa tapleaf, sehingga menembus batasan ruang skrip 4MB. Bahkan, algoritma verifier Groth16 yang diimplementasikan pada BitVM2 saat ini memiliki ukuran hingga 2GB. Namun, dapat dibagi dan didistribusikan di sekitar 1000 daun tunggang, dan dengan menggabungkannya dengan komitmen bit, konsistensi antara input dan output dari setiap sub-fungsi dapat dibatasi, memastikan integritas dan kebenaran seluruh perhitungan.

2.4 Output Konnektor: Menembus Batasan Metode Pengeluaran UTXO

Saat ini, Bitcoin menyediakan dua metode pengeluaran asli untuk satu UTXO: pengeluaran melalui skrip atau melalui kunci publik. Oleh karena itu, selama tanda tangan kunci publik atau kondisi skrip yang benar terpenuhi, UTXO dapat dikeluarkan. Dua UTXO dapat dikeluarkan secara independen, dan tidak ada batasan yang dapat ditambahkan untuk membatasi kedua UTXO, artinya kondisi tambahan harus dipenuhi agar mereka dapat dikeluarkan.

Namun, Burak, pendiri protokol Ark, dengan cerdik memanfaatkan bendera SIGHASH untuk mencapai keluaran penghubung. Secara khusus, Alice dapat membuat tanda tangan untuk mengirimkan BTC-nya ke Bob. Namun, karena tanda tangan dapat terikat ke beberapa input, Alice dapat mengatur tanda tangannya menjadi bersyarat: tanda tangan itu valid untuk transaksi Taketx jika dan hanya jika transaksi itu mengonsumsi input kedua. Input kedua disebut penghubung, menghubungkan UTXO A dan UTXO B. Dengan kata lain, transaksi Taketx valid jika dan hanya jika UTXO B belum dihabiskan oleh Challengetx. Oleh karena itu, dengan menghancurkan keluaran penghubung, efektivitas transaksi Taketx dapat diblokir.

Gambar 1: Ilustrasi Output Konektor

Dalam protokol BitVM2, output konektor bertindak sebagai... fungsi else. Setelah output konektor dibelanjakan oleh transaksi, itu tidak dapat dibelanjakan oleh transaksi lain untuk memastikan pengeluaran eksklusifnya. Dalam penyebaran praktis, untuk memungkinkan periode tantangan-respons, UTXO tambahan dengan timelock diperkenalkan. Selain itu, output konektor yang sesuai juga dapat diatur dengan strategi pengeluaran yang berbeda sesuai kebutuhan, seperti memungkinkan pihak mana pun untuk membelanjakan dalam kasus transaksi tantangan, sementara hanya mengizinkan operator untuk membelanjakan atau mengizinkan siapa pun untuk membelanjakan setelah batas waktu untuk transaksi respons.

2.5 Kontrak: Menembus Batasan Pra-Tanda Tangan

Saat ini, skrip Bitcoin terutama membatasi kondisi pembukaan, tanpa membatasi bagaimana UTXO dapat dikeluarkan lebih lanjut. Hal ini karena skrip Bitcoin tidak dapat membaca konten transaksi itu sendiri, yang berarti mereka tidak dapat mencapai introspeksi transaksi. Jika skrip Bitcoin dapat memeriksa konten transaksi apa pun (termasuk output), fungsionalitas kontrak dapat diwujudkan.

Implementasi kontrak saat ini dapat dibagi menjadi dua kategori:

• Pra-penandatanganan: Berdasarkan kemampuan skrip Bitcoin yang ada, kontrak pra-determinasi fungsionalitas terbatas dibangun melalui pra-penandatanganan. Ini berarti merancang dan menandatangani semua kemungkinan transaksi di masa depan sebelumnya, mengunci peserta ke kunci pribadi dan tarif biaya tertentu. Beberapa skema bahkan mengharuskan peserta untuk menghasilkan kunci pribadi jangka pendek untuk semua transaksi yang telah ditandatangani sebelumnya. Setelah pra-penandatanganan selesai, kunci pribadi jangka pendek ini dihapus dengan aman, mencegah penyerang mendapatkannya dan mencuri dana. Namun, setiap kali peserta baru ditambahkan atau operasi diperbarui, proses di atas perlu diulang, yang menyebabkan biaya pemeliharaan tinggi. Misalnya, Lightning Network mencapai kontrak dua pihak melalui pra-penandatanganan dan menggunakan teknologi Hash Time-Locked Contracts (HTLC) untuk mengimplementasikan fungsi perutean untuk beberapa kontrak dua pihak, sehingga mencapai strategi penskalaan yang diminimalkan kepercayaan. Namun, Jaringan Petir memerlukan beberapa transaksi pra-penandatanganan dan terbatas pada dua pihak, membuatnya agak rumit; di BitVM1, ratusan transaksi perlu ditandatangani sebelumnya pada setiap inisialisasi, sedangkan di BitVM2 yang dioptimalkan, jumlah transaksi yang perlu ditandatangani sebelumnya pada setiap inisialisasi juga mencapai lusinan. Di BitVM1 dan BitVM2, hanya operator yang berpartisipasi dalam pra-penandatanganan yang memenuhi syarat untuk penggantian. Jika n peserta terlibat dalam pra-penandatanganan, dan setiap peserta perlu melakukan pra-penandatanganan m transaksi, kompleksitas pra-penandatanganan untuk setiap peserta akan menjadi n * m.
• Memperkenalkan Contract Opcodes: Memperkenalkan opcode fungsi kontrak baru dapat signifikan mengurangi kompleksitas komunikasi dan biaya perawatan antara peserta kontrak, dengan demikian memperkenalkan metode implementasi kontrak yang lebih fleksibel untuk Bitcoin. Contohnya, OPCAT: digunakan untuk menggabungkan byte string. Meskipun fungsinya sangat sederhana, tetapi sangat kuat dan dapat signifikan mengurangi kompleksitas BitVM; OPTXHASH: memungkinkan kontrol aksi yang lebih granular di dalam kontrak. Jika digunakan di BitVM, dapat mendukung kumpulan operator yang lebih besar, sehingga secara signifikan meningkatkan asumsi keamanan BitVM dan meminimalkan kepercayaan. Selain itu, metode presigning secara inheren berarti bahwa operator di BitVM hanya dapat mengadopsi proses pengembalian biaya, mengarah pada efisiensi penggunaan modal yang lebih rendah; sedangkan melalui opcode kontrak baru, mungkin saja langsung membayar dari pool dana peg-in kepada pengguna output, yang lebih lanjut meningkatkan efisiensi modal. Oleh karena itu, model kontrak yang fleksibel akan efektif menembus batasan presigning tradisional.

3 Bitcoin Layer2 Scaling: Bukti Validitas dan Bukti Penipuan

Baik bukti validitas maupun bukti penipuan dapat digunakan untuk penskalaan Bitcoin L2, dengan perbedaan utama ditunjukkan dalam Tabel 2.

Tabel 2: Bukti Validitas vs. Bukti Penipuan

Berdasarkan komitmen bit, taproot, pra-penandatanganan, dan output penghubung, bukti penipuan berdasarkan Bitcoin dapat dikonstruksi. Berdasarkan taproot, bukti validitas berdasarkan Bitcoin juga dapat dikonstruksi dengan memperkenalkan opcode kontrak, seperti OP_CAT. Selain itu, tergantung pada apakah Bob memiliki sistem penerimaan, bukti penipuan dapat dibagi menjadi bukti penipuan berizin dan bukti penipuan tanpa izin. Dalam bukti penipuan berizin, hanya kelompok-kelompok tertentu yang dapat bertindak sebagai Bob untuk memulai tantangan, sedangkan dalam bukti penipuan tanpa izin, pihak ketiga manapun dapat bertindak sebagai Bob untuk memulai tantangan. Keamanan bukti penipuan tanpa izin lebih unggul daripada bukti penipuan berizin, mengurangi risiko kolusi di antara peserta yang diizinkan.

Berdasarkan jumlah interaksi tantangan-respons antara Alice dan Bob, bukti penipuan dapat dibagi menjadi bukti penipuan satu putaran dan bukti penipuan multi-putaran, seperti yang ditunjukkan pada Gambar 2.

Gambar 2: Bukti Penipuan Satu Putaran vs. Bukti Penipuan Multi-Putaran

Seperti yang terlihat pada Tabel 3, bukti penipuan dapat diimplementasikan melalui model interaksi yang berbeda, termasuk model interaksi satu putaran dan model interaksi multi-putaran.

Tabel 3: Interaksi Satu Putaran vs Interaksi Multi-Putaran

Dalam paradigma skala Layer 2 Bitcoin, BitVM1 mengadopsi mekanisme bukti penipuan multi-round, sementara BitVM2 menggunakan mekanisme bukti penipuan satu putaran, dan bitcoin-circle stark memanfaatkan bukti validitas. Di antara ini, BitVM1 dan BitVM2 dapat diimplementasikan tanpa membuat modifikasi apa pun pada protokol Bitcoin, sementara bitcoin-circle stark membutuhkan pengenalan opcode baru OP_CAT.

Untuk sebagian besar tugas komputasi, signet, testnet, dan mainnet Bitcoin tidak dapat sepenuhnya merepresentasikan skrip 4MB, sehingga diperlukan penggunaan teknologi pemisahan skrip - yaitu, membagi skrip komputasi lengkap menjadi bagian-bagian yang lebih kecil dari 4MB, yang didistribusikan di berbagai tapleaf.

3.1 Bukti Penipuan Multi-Round pada Bitcoin

Seperti yang ditunjukkan dalam Tabel 3, bukti penipuan multi-putaran cocok untuk skenario di mana ada keinginan untuk mengurangi perhitungan arbitrase on-chain dan/atau di mana tidak mungkin untuk menentukan segmen perhitungan bermasalah dalam satu langkah. Bukti penipuan multi-putaran, sesuai dengan namanya, membutuhkan beberapa putaran interaksi antara pembuktian dan verifikasi untuk menemukan segmen perhitungan yang bermasalah, diikuti dengan arbitrase berdasarkan segmen yang diidentifikasi.

White paper BitVM awal Robin Linus (biasa disebut BitVM1) menggunakan bukti penipuan multi-round. Dengan asumsi setiap periode tantangan berlangsung seminggu dan menggunakan metode pencarian biner untuk menemukan segmen komputasi bermasalah, periode tanggapan tantangan on-chain untuk Verifier Groth16 bisa berlangsung hingga 30 minggu, mengakibatkan ketepatan waktu yang buruk. Meskipun saat ini ada tim yang sedang meneliti metode pencarian n-ary yang lebih efisien daripada pencarian biner, ketepatan waktunya masih jauh lebih rendah dibandingkan dengan siklus 2 minggu dalam bukti penipuan satu putaran.

Saat ini, bukti penipuan multi-round dalam paradigma Bitcoin menggunakan tantangan berizin, sementara bukti penipuan satu putaran telah mencapai metode tantangan tanpa izin, mengurangi risiko kolusi di antara peserta dan dengan demikian meningkatkan keamanan. Untuk tujuan ini, Robin Linus sepenuhnya memanfaatkan keunggulan Taproot untuk mengoptimalkan BitVM1. Bukan hanya jumlah putaran interaksi yang berkurang menjadi satu, tetapi metode tantangan juga diperluas menjadi pendekatan tanpa izin, meskipun dengan biaya peningkatan komputasi arbitrase on-chain.

3.2 Bukti Penipuan Satu Putaran pada Bitcoin

Dalam model ini, verifikasi bukti penipuan dapat diselesaikan melalui satu interaksi antara pemberi bukti dan pemeriksa. Pemeriksa hanya perlu memulai satu tantangan, dan pemberi bukti hanya perlu merespons sekali. Dalam respons ini, pemberi bukti harus memberikan bukti yang menyatakan bahwa komputasi mereka benar. Jika pemeriksa dapat menemukan inkonsistensi dalam bukti tersebut, tantangannya berhasil; jika tidak, maka gagal. Karakteristik bukti penipuan interaktif satu putaran ditunjukkan dalam Tabel 3.

Gambar 3: Bukti Penipuan Satu Putaran

Pada 15 Agustus 2024, Robin Linus merilis white paper teknis BitVM2: Membangun Jembatan Bitcoin ke Layer Kedua, yang mengimplementasikan jembatan lintas rantai menggunakan metode bukti penipuan satu putaran yang mirip dengan yang ditunjukkan dalam Gambar 3.

3.3 Bukti Validitas pada Bitcoin dengan OP_CAT

OPCAT adalah bagian dari bahasa skrip asli ketika Bitcoin dirilis tetapi dinonaktifkan pada tahun 2010 karena kerentanan keamanan. Namun, komunitas Bitcoin telah mendiskusikan reaktivasi OPCAT selama bertahun-tahun. OPCAT sekarang telah diberi nomor 347 dan telah diaktifkan pada signet Bitcoin.

Fungsi utama OP_CAT adalah menggabungkan dua elemen dalam tumpukan dan mendorong hasil gabungan kembali ke tumpukan. Fungsionalitas ini membuka kemungkinan untuk kontrak dan Verifier STARK di Bitcoin:

• Kontrak: Andrew Poelstra mengusulkan CAT dan Schnorr Tricks I, menggunakan teknik OPCAT dan Schnorr untuk menerapkan kontrak di Bitcoin. Algoritma Schnorr adalah tanda tangan digital untuk jenis output P2TR; untuk jenis output lainnya, teknik ECDSA serupa dapat digunakan, seperti yang terlihat dalam Covenants dengan CAT dan ECDSA. Dengan bantuan kontrak OPCAT, algoritma Verifier STARK dapat dibagi menjadi beberapa transaksi, secara bertahap memverifikasi seluruh bukti STARK.
• STARK Verifier: STARK Verifier pada dasarnya menghubungkan data bersama dan menghash-nya. Berbeda dengan operasi aljabar, hashing adalah operasi skrip Bitcoin asli yang dapat menghemat sejumlah besar overhead. Sebagai contoh, OPSHA256 adalah sebuah opcode tunggal dalam bentuk aslinya, sedangkan versi simulasi membutuhkan ratusan opcode K. Operasi hashing utama dalam STARK melibatkan verifikasi jalur Merkle dan transformasi Fiat-Shamir. Oleh karena itu, OPCAT sangat ramah terhadap algoritma STARK Verifier.

3.4 Teknologi Pemisahan Skrip Bitcoin

Meskipun beban komputasi yang diperlukan untuk menjalankan algoritma verifier yang sesuai untuk memverifikasi bukti setelah bukti SNARK / STARK jauh lebih kecil daripada yang diperlukan untuk langsung menjalankan perhitungan asli f, jumlah skrip yang diperlukan saat mengonversinya untuk mengimplementasikan algoritma verifier dalam skrip Bitcoin masih sangat besar. Saat ini, berdasarkan opcode Bitcoin yang ada, ukuran skrip verifier Groth16 yang dioptimalkan dan ukuran skrip verifier Fflonk masih lebih besar dari 2GB. Namun, ukuran satu blok Bitcoin hanya 4MB, sehingga tidak mungkin untuk menjalankan seluruh skrip verifikator dalam satu blok. Namun, sejak upgrade Taproot, Bitcoin mendukung eksekusi skrip dengan tapleaf, memungkinkan skrip verifier dibagi menjadi beberapa bagian, dengan masing-masing potongan berfungsi sebagai tapleaf untuk membangun taptree. Konsistensi nilai antara potongan dapat dipastikan melalui komitmen bit.

Dengan adanya kontrak OP_CAT, STARK Verifier dapat dibagi menjadi beberapa transaksi standar yang lebih kecil dari 400KB, memungkinkan seluruh verifikasi bukti validitas STARK diselesaikan tanpa perlu berkolaborasi dengan penambang.

Bagian ini berfokus pada teknologi split yang relevan dari skrip Bitcoin dalam kondisi yang ada tanpa memperkenalkan atau mengaktifkan opcode baru.

Ketika melakukan pemisahan skrip, dimensi informasi berikut harus seimbang:

• Ukuran skrip potongan tunggal tidak boleh melebihi 4MB dan harus menyertakan skrip komitmen bit input, tanda tangan transaksi, dan ruang lainnya.
• Ukuran tumpukan maksimum dari satu potongan tidak boleh melebihi 1000. Oleh karena itu, tumpukan setiap potongan harus hanya menyimpan elemen-elemen yang diperlukan untuk menghemat ruang tumpukan yang cukup untuk optimalisasi ukuran skrip, karena biaya transaksi Bitcoin tidak bergantung pada ukuran tumpukan yang digunakan.
• Komiten Bit pada Bitcoin mahal. Oleh karena itu, jumlah bit pada input dan output antara dua blok yang berdekatan harus diminimalkan, karena saat ini, 1 bit setara dengan 26 byte.
• Untuk memudahkan audit, fungsionalitas setiap bagian harus sejelas mungkin.

Saat ini, metode pemisahan skrip dapat dibagi menjadi tiga kategori utama berikut:

• Pemisahan Otomatis: Metode ini mencari pendekatan pemisahan di mana ukuran script sekitar 3MB dan ukuran stack diminimalkan berdasarkan ukuran stack dan ukuran script. Keuntungan dari metode ini adalah itu independen dari algoritma verifier tertentu dan dapat diperluas untuk pemisahan script untuk komputasi apa pun. Kerugiannya adalah: (1) seluruh blok logis harus ditandai secara terpisah, seperti blok kode OP_IF yang tidak dapat dipisahkan; jika tidak, hasil eksekusi dari script yang terpisah akan salah; (2) hasil eksekusi dari sebuah chunk dapat sesuai dengan beberapa elemen di stack, memerlukan penandaan jumlah elemen stack yang perlu menerapkan komitmen bit berdasarkan logika komputasi aktual; (3) keberbacaan dari fungsionalitas logis yang diimplementasikan oleh setiap script chunk kurang baik, membuat audit sulit; (4) stack dapat berisi elemen yang tidak diperlukan untuk chunk berikutnya, membuang ruang stack.
• Pemisahan Fungsional: Metode ini membagi berdasarkan berbagai sub-fungsi fungsional dalam perhitungan, dengan nilai input dan output yang jelas untuk sub-fungsi. Saat memisahkan skrip, ia juga mengimplementasikan skrip komitmen bit yang diperlukan untuk setiap potongan, memastikan bahwa ukuran skrip total potongan akhir kurang dari 4MB dan ukuran tumpukan kurang dari 1000. Keuntungannya adalah: fungsionalitas yang jelas, logika yang jelas untuk setiap potongan, keterbacaan yang baik, dan kemudahan audit. Kerugiannya adalah: ekspresi logika komputasi asli mungkin tidak cocok dengan logika tingkat skrip, dan sub-fungsi komputasi asli mungkin optimal tetapi tidak mewakili optimalitas tingkat skrip.
• Pemisahan Manual: Dalam metode ini, titik-titik pemisahan tidak didasarkan pada sub-fungsi fungsional tetapi ditetapkan secara manual. Ini terutama cocok untuk kasus di mana ukuran sub-fungsi tunggal melebihi 4MB. Keuntungannya adalah: memungkinkan pemisahan manual dari sub-fungsi ukuran skrip yang berat, seperti yang terkait dengan perhitungan Fq12; logika yang jelas untuk setiap bagian, mudah dibaca, dan mudah diaudit. Kerugiannya adalah: terbatas oleh kemampuan penyetelan manual, ketika keseluruhan skrip telah dioptimalkan, titik-titik pemisahan manual yang sebelumnya ditetapkan mungkin tidak optimal dan perlu disesuaikan ulang.

Misalnya, setelah beberapa putaran pengoptimalan, ukuran skrip verifikator Groth16 berkurang dari sekitar 7GB menjadi sekitar 1,26GB. Selain optimasi komputasi keseluruhan ini, setiap potongan juga dapat dioptimalkan secara individual untuk memanfaatkan ruang tumpukan sepenuhnya. Misalnya, dengan memperkenalkan algoritma berbasis tabel pencarian yang lebih baik dan secara dinamis memuat dan membongkar tabel pencarian, ukuran skrip setiap potongan dapat dikurangi lebih lanjut.

Biaya komputasi dan lingkungan waktu eksekusi bahasa pemrograman web2 sangat berbeda dengan skrip Bitcoin, sehingga secara sederhana menerjemahkan implementasi yang ada untuk berbagai algoritma ke dalam skrip Bitcoin tidaklah memungkinkan. Oleh karena itu, optimasi yang khusus untuk skenario Bitcoin perlu dipertimbangkan:

• Cari algoritma yang mengoptimalkan kesatuan memori, meskipun dengan biaya beban komputasi tertentu, untuk mengurangi jumlah bit input/output antara blok, sehingga mengurangi jumlah data yang dibutuhkan untuk komitmen dalam desain transaksi assertTx dari BitVM2.
• Manfaatkan komutativitas dari operasi terkait (misalnya, operasi logis), seperti x&y = y&x, untuk menghemat hampir separuh dari tabel pencarian.
• Saat ini, ukuran skrip yang sesuai dengan operasi Fq12 besar; pertimbangkan untuk memanfaatkan skema komitmen Fiat-Shamir, Schwartz-Zipple, dan polinomial untuk secara signifikan mengurangi kompleksitas komputasi operasi ekstensi Fq12.

4 Ringkasan

Artikel ini pertama-tama memperkenalkan keterbatasan skrip Bitcoin dan membahas penggunaan komitmen Bitcoin untuk mengatasi keterbatasan stateless UTXO, menggunakan Taproot untuk melewati batasan ruang skrip, menggunakan keluaran konektor untuk menghindari pembatasan metode pengeluaran UTXO, dan menggunakan kontrak untuk mengatasi keterbatasan pra-tanda tangan. Kemudian memberikan gambaran dan ringkasan komprehensif tentang karakteristik bukti penipuan dan bukti validitas, fitur bukti penipuan berizin dan tanpa izin, perbedaan antara bukti penipuan satu putaran dan multi putaran, dan teknologi pemisahan skrip Bitcoin.

Disclaimer：

1. Artikel ini dicetak ulang dari [ aicoin]. Semua hak cipta adalah milik penulis asli [mutourend & lynndell, Bitlayer Labs]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penolakan Tanggung Jawab: Pandangan dan pendapat yang terdapat dalam artikel ini sepenuhnya merupakan milik penulis dan tidak membentuk saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau plagiarisme artikel yang diterjemahkan dilarang.