Cawan Suci Jaringan Lapisan 2 Bitcoin: Introspeksi dan Perjanjian

Dibandingkan dengan blockchain yang menggunakan Turing-complete seperti Ethereum, bahasa skrip Bitcoin dianggap sangat terbatas, hanya mampu melakukan operasi dasar, dan bahkan tidak memiliki fungsi perkalian dan pembagian. Lebih penting lagi, data blockchain sendiri hampir tidak dapat diakses oleh skrip, yang menyebabkan keterbatasan yang parah dalam fleksibilitas dan kemampuan pemrograman. Oleh karena itu, orang-orang telah lama mencari cara untuk memungkinkan introspeksi skrip Bitcoin.

Introspeksi mengacu pada kemampuan Bitcoin skrip untuk memeriksa dan membatasi data transaksi. Hal ini memungkinkan skrip untuk mengontrol penggunaan dana berdasarkan detail transaksi tertentu, sehingga memungkinkan fungsi yang lebih kompleks. Saat ini, sebagian besar opcode Bitcoin mendorong data yang disediakan pengguna ke dalam stack atau memanipulasi data yang sudah ada di dalam stack. Akan tetapi, opcode introspeksi dapat mendorong data transaksi saat ini (seperti stempel waktu, jumlah, dan ID transaksi) ke dalam stack, sehingga memungkinkan kontrol yang lebih terperinci atas pengeluaran UTXO.

Saat ini hanya ada tiga opcode utama dalam skrip Bitcoin yang mendukung introspeksi: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, dan CHECKSIG. CHECKSIG memiliki beberapa varian, termasuk CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG, dan CHECKMULTISIGVERIFY.

Perjanjian adalah pembatasan tentang bagaimana token dapat ditransfer. Pengguna dapat menentukan bagaimana UTXO didistribusikan melalui perjanjian, yang banyak di antaranya diimplementasikan menggunakan opcode introspeksi. Saat ini, Bitcoin Optech mengkategorikan introspeksi di bawah entri perjanjian.

Bitcoin saat ini memiliki dua perjanjian: CSV (CheckSequenceVerify) dan CLTV (CheckLockTimeVerify), yang keduanya merupakan perjanjian berbasis waktu dan menjadi fondasi bagi banyak solusi penskalaan, seperti Lightning Network. Hal ini mengindikasikan bahwa solusi penskalaan Bitcoin sangat bergantung pada introspeksi dan perjanjian.

Cara Menambahkan Ketentuan ke Transfer Token

Dalam dunia kripto, metode yang paling umum adalah melalui komitmen, yang sering diimplementasikan menggunakan hash. Untuk membuktikan bahwa kondisi transfer terpenuhi, mekanisme tanda tangan digunakan untuk verifikasi. Oleh karena itu, perjanjian melibatkan banyak penyesuaian pada hash dan tanda tangan.

Berikut ini adalah proposal covenant opcode yang dibahas secara luas:

CTV (Periksa TemplateVerifikasi) BIP-119

CTV (CheckTemplateVerify), yang termasuk dalam BIP-119, merupakan peningkatan Bitcoin yang masih menjadi perdebatan. CTV memungkinkan skrip keluaran untuk menentukan template untuk transaksi pengeluaran, termasuk bidang-bidang seperti nVersion, nLockTime, hash scriptSig, jumlah input, hash urutan, jumlah output, hash output, dan indeks input. Pembatasan template ini diimplementasikan melalui komitmen hash, dan skrip pengeluaran di masa mendatang akan memeriksa apakah nilai hash dari bidang tertentu dalam transaksi pengeluaran sesuai dengan yang ada di skrip input. Templat ini pada dasarnya menentukan waktu, metode, dan jumlah transaksi UTXO di masa mendatang.

Khususnya, TXID masukan dikecualikan dari komitmen hash. Pengecualian ini diperlukan karena, baik dalam transaksi Legacy atau Segwit, TXID bergantung pada nilai scriptPubKey ketika menggunakan tipe tanda tangan default SIGHASH_ALL. Memasukkan TXID akan membuat ketergantungan melingkar, membuat komitmen hash tidak mungkin dibuat.

CTV mencapai introspeksi dengan secara langsung mendapatkan informasi transaksi tertentu melalui opcode baru, melakukan hashing, dan membandingkannya dengan komitmen pada stack. Metode ini menggunakan lebih sedikit ruang on-chain tetapi tidak memiliki fleksibilitas.

Fondasi dari solusi lapisan kedua seperti Lightning Network adalah transaksi yang telah ditandatangani sebelumnya. Pra-penandatanganan biasanya berarti membuat dan menandatangani transaksi terlebih dahulu tetapi tidak menyiarkannya sampai kondisi tertentu terpenuhi. Pada dasarnya, CTV mengimplementasikan fungsi pra-penandatanganan yang lebih ketat, menerbitkan komitmen yang telah ditandatangani sebelumnya secara langsung secara on-chain, yang memungkinkan transaksi hanya sesuai dengan templat yang telah ditentukan sebelumnya.

CTV pada awalnya diusulkan untuk mengurangi kemacetan Bitcoin dan juga dapat disebut sebagai kontrol kemacetan. Selama periode kemacetan yang tinggi, CTV dapat melakukan beberapa transaksi di masa depan melalui satu transaksi, menghindari kebutuhan untuk menyiarkan beberapa transaksi selama kemacetan dan menyelesaikan transaksi aktual setelah kemacetan berkurang. Hal ini dapat membantu secara signifikan selama proses pertukaran berlangsung. Selain itu, template dapat digunakan untuk mengimplementasikan vault, mencegah serangan peretas karena tujuan dana sudah ditentukan sebelumnya, sehingga tidak mungkin bagi peretas untuk mengirimkan UTXO menggunakan skrip CTV ke alamat mereka.

CTV dapat secara signifikan meningkatkan jaringan lapisan kedua. Sebagai contoh, di Lightning Network, mengimplementasikan Timeout Trees dan Channel Factories menggunakan CTV memungkinkan satu UTXO untuk berkembang menjadi pohon CTV, membuka beberapa state channel dengan hanya satu transaksi dan konfirmasi on-chain. Selain itu, CTV mendukung transaksi atomik (ATLC) dalam protokol Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 mengusulkan tanda tangan hash flag baru untuk tapscript, yang disebut SIGHASH_ANYPREVOUT, untuk memfasilitasi penulisan logika pengeluaran yang lebih fleksibel. APO dan CTV memiliki banyak kesamaan. Untuk mengatasi ketergantungan melingkar antara scriptPubKeys dan TXID, solusi APO adalah mengecualikan informasi input yang relevan dan hanya menandatangani output, yang memungkinkan transaksi secara dinamis mengikat ke UTXO yang berbeda.

Secara logis, operasi verifikasi OP_CHECKSIG (dan opcode terkait) memiliki tiga fungsi:

1. Mengumpulkan bagian-bagian dari transaksi pembelanjaan.
2. Hancurkan bagian-bagian ini.
3. Verifikasi apakah hash ditandatangani oleh kunci yang diberikan.

Konten spesifik tanda tangan dapat disesuaikan secara signifikan, dan bidang transaksi mana yang ditandatangani ditentukan oleh flag SIGHASH. Menurut definisi opcode tanda tangan BIP 342, flag SIGHASH antara lain adalah SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, dan SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY mengontrol input, sementara yang lainnya mengontrol output.

SIGHASH_ALL adalah flag SIGHASH default, yang menandakan semua output. SIGHASH_NONE menandakan tidak ada output, dan SIGHASH_SINGLE hanya menandakan output tertentu. SIGHASH_ANYONECANPAY dapat diatur dengan tiga flag lainnya, dan jika diatur, flag ini hanya menandakan input yang ditentukan; jika tidak, semua input harus ditandatangani.

Tidak satu pun dari flag SIGHASH ini yang dapat menghilangkan dampak dari masukan. Bahkan SIGHASH_ANYONECANPAY membutuhkan komitmen untuk satu masukan.

Oleh karena itu, BIP 118 memperkenalkan SIGHASH_ANYPREVOUT. Tanda tangan APO tidak perlu berkomitmen pada input UTXO yang dibelanjakan (disebut PREVOUT), hanya menandatangani output, memberikan fleksibilitas yang lebih tinggi dalam kontrol Bitcoin. Dengan melakukan pra-konstruksi transaksi dan membuat tanda tangan sekali pakai dan kunci publik yang sesuai, aset yang dikirim ke alamat kunci publik tersebut harus dibelanjakan melalui transaksi yang telah dibuat sebelumnya, untuk mencapai perjanjian.

Fleksibilitas APO juga dapat digunakan untuk perbaikan transaksi. Jika sebuah transaksi macet secara on-chain karena biaya yang rendah, transaksi lain dapat dengan mudah dibuat untuk meningkatkan biaya tanpa memerlukan tanda tangan baru. Selain itu, untuk dompet multi-tanda tangan, tanda tangan yang tidak bergantung pada input yang dibelanjakan membuat operasi menjadi lebih sederhana.

Dengan menghilangkan ketergantungan melingkar antara scriptPubKeys dan TXID input, APO dapat mencapai introspeksi dengan menambahkan data output dalam saksi, meskipun ini masih membutuhkan ruang data saksi tambahan.

Untuk protokol off-chain seperti Lightning Network dan brankas, APO mengurangi kebutuhan penyimpanan status perantara, sehingga secara signifikan menurunkan kebutuhan dan kompleksitas penyimpanan. Kasus penggunaan paling langsung untuk APO adalah Eltoo, menyederhanakan pabrik saluran, membangun menara pengawas yang ringan dan murah, dan memungkinkan jalan keluar sepihak tanpa meninggalkan status yang salah, meningkatkan kinerja Jaringan Petir. APO dapat mensimulasikan fungsionalitas CTV, meskipun memerlukan penyimpanan tanda tangan dan transaksi yang telah ditandatangani sebelumnya, sehingga lebih mahal dan kurang efisien daripada CTV.

Kritik utama APO adalah kebutuhan akan versi kunci yang baru, membuatnya tidak kompatibel dengan sistem yang sudah ada. Selain itu, jenis hash tanda tangan yang baru dapat menimbulkan potensi risiko pembelanjaan ganda. Setelah diskusi komunitas yang ekstensif, APO sekarang membutuhkan tanda tangan biasa sebagai tambahan untuk tanda tangan asli, mengurangi masalah keamanan dan mendapatkan nomor BIP-118.

OP_VAULT BIP-345

BIP-345 mengusulkan dua opcode baru, OP_VAULT dan OP_VAULT_RECOVER, untuk bekerja dengan CTV dan mengimplementasikan perjanjian khusus yang memberlakukan periode penundaan untuk membelanjakan token yang ditentukan, di mana pembelanjaan tersebut dapat “dicabut” melalui jalur pemulihan.

Pengguna dapat membuat vault dengan mengatur alamat Taproot tertentu, termasuk setidaknya dua skrip di MAST: skrip OP_VAULT untuk memfasilitasi proses penarikan yang diharapkan dan skrip OP_VAULT_RECOVER untuk memastikan pemulihan koin sebelum penarikan selesai.

Bagaimana cara OP_VAULT mencapai penarikan yang tidak dapat diinterupsi?

Secara sederhana, opcode OP_VAULT menggantikan skrip OP_VAULT yang telah digunakan dengan skrip yang ditentukan, memperbarui satu simpul daun di MAST sambil menjaga agar simpul daun yang lain tidak berubah. Ini mirip dengan TLUV tetapi tanpa mendukung pembaruan kunci internal.

Memperkenalkan template selama pembaruan skrip dapat membatasi efek pembayaran. Parameter kunci waktu ditentukan oleh OP_VAULT, sementara template yang dibawa oleh opcode CTV membatasi serangkaian output yang dikeluarkan melalui jalur skrip tersebut.

BIP-345 dirancang untuk brankas, memungkinkan pengguna untuk memiliki jalur pemulihan yang sangat aman (dompet kertas, multi-tanda tangan terdistribusi) sambil mengonfigurasi penundaan pengeluaran untuk pembayaran rutin. Perangkat pengguna secara terus menerus memonitor pengeluaran brankas, memungkinkan pemulihan jika terjadi transfer yang tidak sah.

Menerapkan brankas dengan BIP-345 perlu mempertimbangkan masalah biaya, terutama untuk transaksi pemulihan. Solusi yang mungkin termasuk CPFP (Child Pays for Parent), jangkar sementara, dan tanda tangan hash baru seperti SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Skema TLUV dibangun di sekitar Taproot dan bertujuan untuk memecahkan masalah keluar secara efisien dari UTXO yang digunakan bersama. Prinsip panduannya adalah ketika output Taproot digunakan, kita dapat menggunakan struktur internal alamat Taproot dan transformasi kriptografi untuk memperbarui sebagian kunci internal dan MAST sesuai dengan langkah-langkah pembaruan yang dijelaskan oleh skrip TLUV, sehingga mencapai fungsionalitas kontrak.

Ide dari skema TLUV adalah untuk membuat alamat Taproot baru berdasarkan input pengeluaran saat ini melalui opcode baru TAPLEAF_UPDATE_VERIFY, yang dapat melakukan satu atau beberapa operasi berikut:

• Memperbarui kunci publik internal
• Pangkas jalur Merkle
• Hapus simpul daun yang sedang dieksekusi
• Tambahkan simpul daun baru ke ujung jalur Merkle

Secara khusus, TLUV mengambil tiga masukan:

1. Spesifikasi tentang cara memperbarui kunci publik internal
2. Simpul daun baru untuk jalur Merkle
3. Spesifikasi tentang apakah akan menghapus simpul daun saat ini dan/atau berapa banyak simpul daun jalur Merkle yang akan dihapus

Opcode TLUV menghitung scriptPubKey yang diperbarui dan memverifikasi apakah output yang sesuai dengan input saat ini dikeluarkan ke scriptPubKey tersebut.

Inspirasi untuk TLUV adalah kumpulan koin. Saat ini, pool bersama dapat dibuat menggunakan transaksi yang sudah ditandatangani sebelumnya, tetapi jika Anda ingin mencapai exit tanpa izin, Anda harus membuat jumlah tanda tangan yang terus bertambah secara eksponensial. TLUV memungkinkan keluar tanpa izin tanpa transaksi yang telah ditandatangani sebelumnya. Sebagai contoh, sekelompok mitra menggunakan Taproot untuk membangun UTXO bersama, mengumpulkan dana mereka. Mereka dapat memindahkan dana secara internal menggunakan kunci Taproot atau bersama-sama menandatangani untuk melakukan pembayaran eksternal. Individu dapat keluar dari pool bersama kapan saja, menghapus jalur pembayaran mereka, sementara yang lain dapat terus menyelesaikan pembayaran melalui jalur asli tanpa mengekspos informasi tambahan tentang anggota yang tersisa. Metode ini lebih efisien dan privat dibandingkan dengan transaksi yang tidak digabungkan.

Opcode TLUV mencapai pembatasan pengeluaran parsial dengan memperbarui MAST asli. Namun, ini tidak mencapai introspeksi jumlah keluaran. Oleh karena itu, diperlukan opcode baru IN_OUT_AMOUNT, yang mendorong dua buah data ke dalam stack: jumlah UTXO dari input ini dan jumlah output yang sesuai. Orang yang menggunakan TLUV kemudian diharapkan untuk menggunakan operator matematika untuk memverifikasi apakah dana disimpan dengan benar dalam scriptPubKey yang diperbarui.

Pemeriksaan jumlah keluaran menambah kerumitan lain karena jumlah Bitcoin direpresentasikan dalam satoshi dan membutuhkan hingga 51 bit, tetapi skrip hanya mengizinkan operasi matematika 32-bit. Hal ini membutuhkan peningkatan operator dalam skrip dengan mendefinisikan ulang perilaku opcode atau menggunakan SIGHASH_GROUP untuk menggantikan IN_OUT_AMOUNT.

TLUV diharapkan dapat memberikan solusi untuk kumpulan koin Layer 2 yang terdesentralisasi, meskipun keandalan dalam hal mengubah kunci publik Taproot membutuhkan konfirmasi lebih lanjut.

MATT

MATT (Merkleize All The Things) bertujuan untuk mencapai tiga tujuan: Merkleizing state, Merkleizing script, dan Merkleizing eksekusi, sehingga mencapai kontrak pintar secara umum.

• Negara Bagian Merkleizing: Membangun sebuah Merkle Trie di mana setiap simpul daun adalah sebuah hash dari state, dan Akar Merkle merepresentasikan seluruh state kontrak.
• Skrip Merkleizing: Sebuah MAST yang dibangun dari Tapscript di mana setiap simpul daun adalah jalur transisi keadaan yang mungkin.
• Eksekusi Merkleizing: Dicapai melalui komitmen kriptografi dan mekanisme tantangan penipuan. Untuk fungsi komputasi apa pun, peserta dapat menghitung secara off-chain dan mempublikasikan komitmen, f(x)=y. Jika peserta lain menemukan hasil f(x)=z, mereka dapat menantangnya, dan arbitrase dilakukan melalui pencarian biner, mirip dengan prinsip Optimistic Rollup.

Untuk mencapai MATT, skrip pemrograman Bitcoin harus memiliki fungsi-fungsi berikut:

1. Menerapkan skrip tertentu pada output (dan jumlahnya)
2. Melampirkan data ke output
3. Membaca data dari input saat ini (atau input lainnya)

Poin kedua sangat penting karena data dinamis memungkinkan komputasi status melalui data input yang disediakan oleh pemberi kerja, mensimulasikan mesin status dan memutuskan status berikutnya dan data yang dilampirkan. MATT mengusulkan opcode OP_CHECKCONTRACTVERIFY (OP_CCV), kombinasi dari opcode OP_CHECKOUTPUTCONTRACTVERIFY dan opcode OP_CHECKINPUTCONTRACTVERIFY yang telah diajukan sebelumnya, dengan parameter flag tambahan untuk menentukan target operasi.

Kontrol Jumlah Keluaran: Cara yang paling langsung adalah melalui introspeksi langsung. Akan tetapi, jumlah keluaran merupakan angka 64-bit yang membutuhkan operasi 64-bit, yang menambah kerumitan pada implementasi skrip Bitcoin. CCV mengadopsi pemeriksaan tertunda yang mirip dengan OP_VAULT, menjumlahkan jumlah input untuk semua input ke output yang sama dengan CCV sebagai batas bawah dari jumlah output tersebut. Pengecekan ini ditunda pada proses transaksi, bukan pada saat evaluasi skrip input.

Mengingat keumuman bukti-bukti penipuan, beberapa varian kontrak MATT seharusnya dapat mencapai semua jenis kontrak pintar atau konstruksi Layer 2, meskipun persyaratan tambahan (seperti penguncian modal dan penundaan periode tantangan) membutuhkan evaluasi yang akurat. Penelitian lebih lanjut diperlukan untuk mengevaluasi aplikasi mana yang merupakan transaksi yang dapat diterima. Sebagai contoh, menggunakan komitmen kriptografi dan mekanisme tantangan penipuan untuk mensimulasikan fungsi OP_ZK_VERIFY, untuk mencapai Rollup tanpa kepercayaan pada Bitcoin.

Pada praktiknya, hal ini sudah terjadi. Johan Torås Halseth mengimplementasikan elftrace menggunakan opcode OP_CHECKCONTRACTVERIFY dari proposal soft fork MATT, yang memungkinkan semua program yang didukung oleh kompilasi RISC-V diverifikasi di rantai Bitcoin, sehingga memungkinkan jembatan verifikasi Bitcoin asli untuk protokol kontrak.

CSFS (OP_CHECKSIGFROMSTACK)

Dari pengenalan opcode APO, kita tahu bahwa OP_CHECKSIG (dan operasi terkait) bertanggung jawab untuk mengumpulkan transaksi, hashing, dan verifikasi tanda tangan. Akan tetapi, pesan yang diverifikasi berasal dari serialisasi transaksi yang menggunakan opcode ini, tidak memungkinkan untuk menentukan pesan lain. Secara sederhana, OP_CHECKSIG (dan operasi-operasi terkait) berfungsi untuk memverifikasi bahwa UTXO sebagai input transaksi telah diotorisasi untuk dibelanjakan oleh pemegang tanda tangan, sehingga melindungi keamanan Bitcoin.

CSFS, seperti namanya, memeriksa tanda tangan dari tumpukan. Opcode CSFS mengambil tiga parameter dari tumpukan: tanda tangan, pesan, dan kunci publik, dan memverifikasi keabsahan tanda tangan. Ini berarti bahwa pesan apa pun dapat diteruskan ke stack melalui data saksi dan diverifikasi oleh CSFS, sehingga memungkinkan beberapa inovasi pada Bitcoin.

Fleksibilitas CSFS memungkinkannya untuk mengimplementasikan berbagai mekanisme seperti tanda tangan pembayaran, pendelegasian wewenang, kontrak oracle, dan obligasi perlindungan pembelanjaan ganda, dan yang lebih penting lagi, introspeksi transaksi. Prinsip introspeksi transaksi menggunakan CSFS sangat sederhana. Jika konten transaksi yang digunakan oleh OP_CHECKSIG didorong ke tumpukan melalui saksi dan kunci publik dan tanda tangan yang sama digunakan untuk memverifikasi dengan CSFS dan OP_CHECKSIG, jika keduanya lolos, maka konten pesan apa pun yang diteruskan ke CSFS sama dengan transaksi pengeluaran berseri (dan data lain) yang secara implisit digunakan oleh OP_CHECKSIG. Kami kemudian mendapatkan data transaksi terverifikasi pada stack, yang dapat digunakan untuk menerapkan pembatasan pada transaksi pengeluaran dengan opcode lain.

CSFS sering muncul dengan OP_CAT karena OP_CAT dapat menggabungkan bidang transaksi yang berbeda untuk menyelesaikan serialisasi, memungkinkan pemilihan bidang transaksi yang lebih tepat untuk pemeriksaan. Tanpa OP_CAT, skrip tidak dapat menghitung ulang hash dari data yang dapat diperiksa satu per satu, sehingga hanya dapat memeriksa apakah hash cocok dengan nilai tertentu, yang berarti koin hanya dapat dibelanjakan melalui satu transaksi tertentu.

CSFS dapat mencapai opcode seperti CLTV, CSV, CTV, APO, dan merupakan opcode introspeksi umum, sehingga juga membantu solusi penskalaan Layer 2 untuk Bitcoin. Kekurangannya adalah ia membutuhkan penambahan salinan lengkap dari transaksi yang ditandatangani ke dalam stack, yang secara signifikan dapat meningkatkan ukuran transaksi yang ingin menggunakan CSFS untuk introspeksi. Sebaliknya, opcode introspeksi tujuan tunggal seperti CLTV dan CSV memiliki overhead yang paling kecil, tetapi menambahkan setiap opcode introspeksi khusus membutuhkan perubahan konsensus.

TXHASH (OP_TXHASH)

OP_TXHASH adalah opcode introspeksi yang sangat mudah yang memungkinkan operator untuk memilih hash field dan mendorongnya ke stack. Secara khusus, OP_TXHASH memunculkan flag txhash dari stack, menghitung txhash (yang ditandai) berdasarkan flag, dan mendorong hash yang dihasilkan ke stack.

Karena kemiripan antara TXHASH dan CTV, telah ada diskusi yang luas di komunitas tentang keduanya.

TXHASH dapat dilihat sebagai sebuah peningkatan umum terhadap CTV, menyediakan sebuah template transaksi yang lebih canggih yang memungkinkan pengguna untuk menentukan bagian dari transaksi pengeluaran, menyelesaikan banyak masalah yang berkaitan dengan biaya transaksi. Tidak seperti opcode kontrak lainnya, TXHASH tidak memerlukan penyediaan salinan data yang diperlukan dalam saksi, sehingga mengurangi kebutuhan penyimpanan. Tidak seperti CTV, TXHASH tidak kompatibel dengan NOP dan hanya dapat diimplementasikan dalam tapscript. Kombinasi TXHASH dan CSFS dapat dianggap sebagai alternatif untuk CTV dan APO.

Dalam hal membangun kontrak, TXHASH lebih mudah untuk mencapai “kontrak aditif” dengan mendorong semua bagian dari data transaksi yang ingin Anda perbaiki ke dalam stack, melakukan hashing bersama-sama, dan memverifikasi apakah hasilnya cocok dengan nilai yang telah ditetapkan. CTV lebih mudah untuk mencapai “kontrak subtraktif” dengan mendorong semua bagian dari data transaksi yang ingin Anda jaga agar tetap bebas ke dalam stack. Kemudian, dengan menggunakan rolling OP_SHA256, dimulai dari status perantara yang tetap, status perantara tersebut melakukan awalan data hash transaksi. Bagian yang bebas di-hash ke dalam status perantara tersebut.

Bidang TxFieldSelector yang didefinisikan dalam spesifikasi TXHASH diharapkan dapat diperluas ke opcode lain, seperti OP_TX.

BIP yang terkait dengan TXHASH saat ini masih dalam status draf di Github dan belum diberi nomor.

OP_CAT

OP_CAT adalah sebuah opcode misterius yang tidak digunakan lagi oleh Satoshi Nakamoto karena masalah keamanan. Namun, baru-baru ini opcode ini memicu diskusi yang luas di antara para pengembang inti Bitcoin, bahkan menjadi meme di komunitas online. Pada akhirnya, OP_CAT disetujui sebagai BIP-347, dengan banyak orang menyebutnya sebagai proposal BIP yang paling mungkin lolos dalam waktu dekat.

Pada kenyataannya, perilaku OP_CAT sangat sederhana: menggabungkan dua elemen pada tumpukan menjadi satu. Namun, bagaimana cara mengaktifkan fungsionalitas kontrak?

Fungsi penggabungan dua elemen sesuai dengan struktur data kriptografi yang kuat yang dikenal sebagai Merkle Trie. Pembangunan Merkle Trie hanya membutuhkan operasi penggabungan dan hashing, yang mana keduanya tersedia dalam skrip Bitcoin. Oleh karena itu, dengan OP_CAT, secara teoritis kita dapat memverifikasi Merkle Proofs dalam skrip Bitcoin, yang merupakan metode verifikasi ringan yang paling umum dalam blockchain.

Seperti yang telah disebutkan sebelumnya, CSFS dapat menggunakan OP_CAT untuk mencapai skema kontrak umum. Bahkan, bahkan tanpa CSFS, struktur tanda tangan Schnorr memungkinkan OP_CAT sendiri untuk mencapai introspeksi transaksi.

Dalam tanda tangan Schnorr, pesan yang akan ditandatangani terdiri dari bidang-bidang berikut:

• Versi
• Waktu penguncian
• Jumlah masukan
• Jumlah keluaran
• Daftar input (masing-masing termasuk hash transaksi sebelumnya, indeks, panjang skrip, skrip, urutan)
• Daftar output (masing-masing termasuk nilai, panjang naskah, naskah)

Field-field ini berisi elemen-elemen utama dari sebuah transaksi. Dengan menempatkannya di scriptPubKey atau witness, dan menggunakan OP_CAT dan OP_SHA256, kita dapat membuat tanda tangan Schnorr dan memverifikasinya dengan OP_CHECKSIG. Jika verifikasi berhasil, stack akan menyimpan data transaksi yang telah diverifikasi, sehingga memungkinkan pemeriksaan transaksi. Hal ini memungkinkan kita untuk mengekstrak dan “memeriksa” berbagai bagian dari transaksi, seperti input, output, alamat tujuan, atau jumlah Bitcoin yang terlibat.

Untuk prinsip-prinsip kriptografi yang lebih rinci, lihat artikel Andrew Poelstra “Trik CAT dan Schnorr.”

Singkatnya, fleksibilitas OP_CAT membuatnya mampu meniru hampir semua opcode kontrak, dan banyak opcode kontrak bergantung pada fungsinya. Hal ini secara signifikan meningkatkan posisinya dalam daftar penggabungan. Secara teoritis, hanya dengan OP_CAT dan opcode Bitcoin yang sudah ada, kita dapat membuat BTC ZK Rollup yang minim kepercayaan. Starknet, Chakra, dan mitra ekosistem lainnya secara aktif bekerja untuk mewujudkannya.

Kesimpulan

Ketika kami mengeksplorasi berbagai strategi untuk mengembangkan Bitcoin dan meningkatkan kemampuan pemrogramannya, menjadi jelas bahwa jalan ke depan melibatkan kombinasi peningkatan asli, komputasi off-chain, dan fungsi skrip yang kompleks.

Tanpa lapisan dasar yang fleksibel, mustahil untuk membangun lapisan kedua yang lebih fleksibel.

Skalabilitas komputasi off-chain adalah masa depan, tetapi programabilitas Bitcoin harus menerobos untuk mendukung penskalaan yang lebih baik dan menjadi mata uang dunia yang sebenarnya.

Akan tetapi, komputasi Bitcoin pada dasarnya berbeda dengan komputasi Ethereum. Bitcoin hanya mendukung “verifikasi” sebagai bentuk komputasi, sedangkan Ethereum pada dasarnya adalah komputasi, dengan verifikasi sebagai produk sampingan. Perbedaan ini terlihat dari fakta bahwa Ethereum membebankan biaya gas untuk transaksi yang gagal, sedangkan Bitcoin tidak.

Kontrak mencapai bentuk kontrak pintar berdasarkan verifikasi daripada perhitungan. Mengenai kontrak, selain beberapa fundamentalis Satoshi yang ketat, sebagian besar orang percaya bahwa kontrak adalah pilihan yang baik untuk meningkatkan Bitcoin. Namun, komunitas terus memperdebatkan skema mana yang akan digunakan untuk mengimplementasikan kontrak.

APO, OP_VAULT, dan TLUV condong ke arah aplikasi langsung. Memilih mereka dapat mengimplementasikan aplikasi spesifik dengan lebih murah dan efisien. Para penggemar Lightning Network lebih memilih APO karena dapat mencapai LN-Simetri; jika Anda ingin membuat vault, yang terbaik adalah menggunakan OP_VAULT; untuk membangun CoinPool, TLUV lebih privat dan efisien. OP_CAT dan TXHASH lebih umum, dengan kerentanan keamanan yang lebih sedikit, dan dapat mencapai lebih banyak kasus penggunaan melalui kombinasi dengan opcode lain, meskipun berpotensi mengorbankan kerumitan skrip. CTV dan CSFS telah menyesuaikan pendekatan pemrosesan blockchain: CTV mengimplementasikan output yang tertunda, dan CSFS mengimplementasikan tanda tangan yang tertunda. MATT relatif unik, menggunakan eksekusi yang optimis dan bukti-bukti penipuan, dan bergantung pada struktur Merkle Trie untuk mencapai kontrak pintar secara umum, meskipun masih membutuhkan opcode baru untuk menyediakan kemampuan introspeksi.

Kami melihat bahwa komunitas Bitcoin sudah secara intens mendiskusikan kemungkinan untuk memperkenalkan kontrak melalui soft fork. Starknet secara resmi telah mengumumkan masuknya ke dalam ekosistem Bitcoin, berencana untuk mengimplementasikan penyelesaian di jaringan Bitcoin dalam waktu enam bulan setelah penggabungan OP_CAT. Chakra akan terus memantau perkembangan terbaru dalam ekosistem Bitcoin, mempromosikan penggabungan soft fork OP_CAT, dan menggunakan programabilitas yang dibawa oleh introspeksi dan kontrak untuk membangun lapisan penyelesaian Bitcoin yang lebih aman dan efisien.