Penulis: Chakra; Penyusun: 0xjs@金财经

Artikel ini merupakan Bagian III dari rangkaian artikel tentang skalabilitas Bitcoin yang diterbitkan oleh Chakra.

Untuk bagian pertama, silakan merujuk ke artikel Golden Finance sebelumnya “Review rencana ekspansi asli Bitcoin: SegWit dan Taproot”,

Untuk bagian kedua, silakan merujuk ke artikel Golden Finance sebelumnya “Skalabilitas Bitcoin: Analisis Solusi Layer2 dan Proyek Terkait”.

Bagian ketiga adalah artikel ini, sebagai berikut:

Ringkasan

Dibandingkan dengan blockchain lengkap Turing seperti Ethereum, skrip Bitcoin dianggap sangat membatasi dan hanya dapat melakukan operasi dasar dan bahkan tidak mendukung perkalian dan pembagian. Lebih penting lagi, data dari blockchain itu sendiri hampir tidak dapat diakses oleh skrip, sehingga mengakibatkan kurangnya fleksibilitas dan kemampuan program. Oleh karena itu, ada upaya untuk membuat skrip Bitcoin menjadi introspektif.

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

Saat ini, hanya tiga opcode utama yang mendukung introspeksi dalam Skrip Bitcoin: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, dan CHECKSIG, serta variannya CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG, dan CHECKMULTISIGVERIFY.

Perjanjian (juga diterjemahkan sebagai "pembatasan"), sederhananya, mengacu pada pembatasan metode transfer mata uang, yang memungkinkan pengguna untuk menentukan metode distribusi UTXO. Banyak kontrak diimplementasikan melalui opcode introspeksi, dan diskusi tentang introspeksi kini telah dialihkan ke topik Kontrak Bitcoin Optech.

Bitcoin saat ini memiliki dua kontrak, CSV (CheckSequenceVerify) dan CLTV (CheckLockTimeVerify). Kedua kontrak tersebut adalah kontrak berbasis waktu dan merupakan dasar dari banyak solusi ekspansi (seperti Lightning Network). Hal ini menggambarkan bahwa solusi penskalaan Bitcoin sangat bergantung pada introspeksi dan kontrak.

Bagaimana cara kami menambahkan ketentuan pada transfer token? Di dunia mata uang kripto, cara paling umum untuk melakukan hal ini adalah melalui janji, biasanya melalui hash. Untuk membuktikan terpenuhinya syarat pengalihan, diperlukan juga mekanisme tanda tangan untuk verifikasi. Oleh karena itu, banyak penyesuaian hash dan tanda tangan dalam kontrak.

Di bawah ini, kami menjelaskan proposal opcode Kovenan yang banyak dibahas.

CTV（PeriksaVerifikasi Templat）BIP-119

CTV (CheckTemplateVerify) adalah proposal peningkatan Bitcoin di BIP-119, yang telah menarik perhatian luas dari komunitas. CTV memungkinkan skrip keluaran untuk menentukan templat pencairan dana dalam transaksi, termasuk nVersion, nLockTime, hash scriptSig, jumlah masukan, hash urutan, jumlah keluaran, hash keluaran, indeks masukan, dan bidang lainnya. Pembatasan templat ini diterapkan melalui janji hash, dan ketika dana dibelanjakan, skrip memeriksa apakah hash bidang yang ditentukan dalam transaksi pembelanjaan cocok dengan hash di skrip input. Ini secara efektif membatasi waktu, metode, dan jumlah transaksi di masa depan untuk UTXO tersebut.

Perlu dicatat bahwa input TXID dikecualikan dari hash ini. Pengecualian ini diperlukan karena dalam transaksi tradisional dan SegWit, saat menggunakan tipe tanda tangan SIGHASH_ALL default, TXID bergantung pada nilai dalam scriptPubKey. Menyertakan TXID menyebabkan ketergantungan melingkar pada janji hash, sehingga tidak mungkin untuk dibuat.

Metode introspeksi CTV adalah dengan langsung menarik informasi transaksi yang ditentukan, melakukan hash, lalu membandingkannya dengan janji di tumpukan. Metode introspeksi ini memiliki persyaratan lebih rendah pada ruang rantai, namun kurang memiliki fleksibilitas tertentu.

Fondasi dari solusi lapis kedua Bitcoin, seperti Lightning Network, adalah transaksi yang telah ditandatangani sebelumnya. Pra-penandatanganan biasanya mengacu pada pembuatan dan penandatanganan transaksi terlebih dahulu tetapi tidak menyiarkannya sampai kondisi tertentu terpenuhi. Intinya, CTV menerapkan bentuk pra-penandatanganan yang lebih ketat, menerbitkan komitmen yang telah ditandatangani sebelumnya secara on-chain dan membatasinya pada templat yang telah ditentukan sebelumnya.

CTV awalnya diusulkan untuk mengurangi kemacetan Bitcoin, yang juga bisa disebut pengendalian kemacetan. Ketika kemacetan sangat parah, CTV dapat melakukan beberapa transaksi di masa depan dalam satu transaksi, menghindari penyiaran beberapa transaksi selama jam sibuk dan menyelesaikan transaksi sebenarnya ketika kemacetan mereda. Ini mungkin sangat berguna selama proses pertukaran. Selain itu, templat ini dapat digunakan untuk mengimplementasikan Vault guna melindungi dari serangan peretas. Karena aliran dana telah ditentukan sebelumnya, peretas tidak dapat menggunakan skrip CTV untuk mengarahkan UTXO ke alamat mereka sendiri.

CTV dapat meningkatkan jaringan Layer 2 secara signifikan. Misalnya, di Lightning Network, CTV dapat membuat pohon batas waktu dan pabrik saluran dengan memperluas satu UTXO ke dalam pohon CTV, sehingga memungkinkan beberapa saluran negara dibuka hanya dengan satu transaksi dan satu konfirmasi. Selain itu, CTV mendukung transaksi atom dalam protokol Ark melalui ATLC.

APO（SIGHASH_ANYPREVOUT）BIP-118

BIP-118 memperkenalkan tanda hash tanda tangan baru untuk tapscript yang dirancang untuk memfasilitasi logika pengeluaran yang lebih fleksibel, yang disebut SIGHASH_ANYPREVOUT. APO dan CTV memiliki banyak kesamaan. Pendekatan APO untuk memecahkan masalah loop antara scriptPubKeys dan TXID adalah dengan mengecualikan informasi masukan yang relevan dan hanya menandatangani keluaran, sehingga memungkinkan transaksi terikat secara dinamis ke UTXO yang berbeda.

Logikanya, operasi verifikasi tanda tangan OP_CHECKSIG (dan variannya) menjalankan tiga fungsi:

1. Kumpulkan berbagai bagian transaksi pengeluaran.

2. Hash mereka.

3. Verifikasi bahwa hash telah ditandatangani oleh kunci yang diberikan.

Ada banyak fleksibilitas dalam rincian spesifik tanda tangan, dengan tanda SIGHASH yang menentukan bidang transaksi mana yang ditandatangani. Menurut definisi opcode tanda tangan di BIP 342, flag SIGHASH dibagi menjadi SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE dan SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY mengontrol masukan, sementara yang lain mengontrol keluaran.

SIGHASH_ALL adalah tanda SIGHASH default, menandatangani semua keluaran; SIGHASH_NONE tidak menandatangani keluaran apa pun; SIGHASH_ANYONECANPAY dapat disetel bersama dengan tiga tanda SIGHASH pertama. Jika SIGHASH_ANYONECANPAY disetel, hanya masukan tertentu yang ditandatangani; jika tidak, semua masukan harus ditandatangani.

Jelasnya, tanda SIGHASH ini tidak menghilangkan dampak masukan, bahkan SIGHASH_ANYONECANPAY, yang memerlukan komitmen terhadap suatu masukan.

Oleh karena itu, BIP 118 mengusulkan SIGHASH_ANYPREVOUT. Tanda tangan APO tidak memerlukan input UTXO (disebut PREVOUT) yang dikeluarkan untuk dikomit, namun hanya output, sehingga memberikan fleksibilitas yang lebih besar untuk kontrol Bitcoin. Dengan melakukan pra-konstruksi transaksi dan membuat tanda tangan satu kali dan kunci publik yang sesuai, aset yang dikirim ke alamat kunci publik tersebut harus digunakan melalui transaksi yang telah dibuat sebelumnya, sehingga memenuhi kontrak. Fleksibilitas APO juga dapat digunakan untuk perbaikan transaksi; jika suatu transaksi terjebak dalam rantai karena biayanya terlalu rendah, transaksi lain dapat dengan mudah dibuat untuk meningkatkan biaya tanpa memerlukan tanda tangan baru. Selain itu, untuk dompet multi-tanda tangan, tidak bergantung pada input yang dihabiskan membuat pengoperasian menjadi lebih nyaman.

Karena perulangan antara scriptPubKeys dan masukan TXID dihilangkan, APO dapat melakukan introspeksi dengan menambahkan data keluaran di Witness, meskipun hal ini masih memerlukan konsumsi ruang Witness tambahan.

Untuk protokol off-chain seperti Lightning Network dan Vaults, APO mengurangi kebutuhan untuk menyimpan keadaan perantara, sehingga sangat mengurangi kebutuhan dan kompleksitas penyimpanan. Kasus penggunaan APO yang paling mendesak adalah Eltoo, yang meningkatkan kinerja Lightning Network dalam banyak hal dengan menyederhanakan pabrik saluran, membangun menara pengawas yang ringan dan murah, dan memungkinkan pintu keluar sepihak tanpa meninggalkan status kesalahan. APO juga dapat digunakan untuk meniru fungsi CTV, meskipun mengharuskan individu untuk menyimpan transaksi yang ditandatangani dan ditandatangani sebelumnya, yang lebih mahal dan kurang efisien dibandingkan CTV.

Kritik utama terhadap APO berpusat pada kenyataan bahwa ia memerlukan versi kunci baru, yang tidak dapat dicapai melalui kompatibilitas ke belakang yang sederhana. Selain itu, jenis hash tanda tangan baru dapat menimbulkan potensi risiko pembelanjaan ganda. Setelah diskusi komunitas yang ekstensif, APO memperoleh kode BIP-118 dengan menambahkan tanda tangan reguler di atas mekanisme tanda tangan asli untuk mengurangi masalah keamanan.

OP_VAULT BIP-345

BIP-345 mengusulkan penambahan dua opcode baru, OP_VAULT dan OP_VAULT_RECOVER, yang bila digabungkan dengan CTV, memungkinkan kontrak khusus yang memungkinkan pengguna memaksa penangguhan mata uang tertentu. Selama penundaan ini, transaksi yang dilakukan sebelumnya dapat "dibatalkan" melalui jalur pemulihan.

Pengguna dapat membuat Vault dengan membuat alamat Taproot tertentu, yang harus berisi setidaknya dua skrip di MAST-nya: satu dengan opcode OP_VAULT untuk memfasilitasi proses penarikan yang diharapkan, dan satu lagi dengan opcode OP_VAULT_RECOVER untuk memastikan bahwa Token penarikan dapat dipulihkan kapan saja sebelum pembayaran selesai.

OP_VAULT Bagaimana cara menerapkan penarikan terkunci dengan jangka waktu yang dapat diinterupsi? OP_VAULT melakukan hal ini dengan mengganti skrip OP_VAULT yang digunakan dengan skrip yang ditentukan, secara efektif memperbarui satu daun MAST sambil membiarkan sisa simpul daun Akar Tunggang tidak berubah. Desain ini mirip dengan TLUV, hanya saja OP_VAULT tidak mendukung pembaruan kunci internal.

Pembayaran dapat dibatasi dengan memperkenalkan template selama pembaruan skrip. Parameter kunci waktu ditentukan oleh OP_VAULT, dan templat untuk opcode CTV membatasi kumpulan keluaran yang dapat digunakan melalui jalur skrip ini.

BIP-345 dirancang khusus untuk Vault, memanfaatkan OP_VAULT dan OP_VAULT_RECOVER untuk menyediakan metode escrow yang aman kepada pengguna, menggunakan kunci yang sangat aman (seperti dompet kertas atau multi-tanda tangan yang didistribusikan) sebagai jalur pemulihan, sekaligus mengonfigurasi penundaan tertentu untuk pembayaran berulang. Perangkat pengguna terus memantau pengeluaran brankas, dan jika terjadi transfer yang tidak terduga, pengguna dapat memulai pemulihan.

Penerapan Vault melalui BIP-345 memiliki pertimbangan biaya, terutama untuk memulihkan transaksi. Solusi yang memungkinkan mencakup CPFP (anak membayar untuk orang tua), jangkar sementara, dan tanda hash bertanda SIGHASH_GROUP baru.

TLUV（Verifikasi Pembaruan Tapeleaf）

Solusi TLUV dibangun berdasarkan Taproot dan bertujuan untuk memecahkan masalah keluar UTXO bersama secara efektif. Pedomannya adalah ketika keluaran Taproot digunakan, kunci internal dan MAST (tapscript trie) dapat diperbarui sebagian melalui transformasi kriptografi dan struktur internal alamat Taproot, seperti yang dijelaskan dalam skrip TLUV. Hal ini memungkinkan implementasi fungsionalitas Covenant.

Konsep skema TLUV adalah membuat alamat Taproot baru berdasarkan masukan pengeluaran saat ini dengan memperkenalkan opcode baru TAPLEAF_UPDATE_VERIFY. Hal ini dapat dicapai dengan melakukan satu atau beberapa hal berikut:

  • Perbarui kunci publik internal

  • Pangkas jalur Merkle

  • Hapus skrip yang sedang dijalankan

  • Tambahkan langkah baru di akhir jalur Merkle

Secara khusus, TLUV menerima tiga masukan:

  • Menentukan cara memperbarui kunci publik internal.

  • Sebuah cara untuk menentukan langkah baru untuk jalur Merkle.

  • Menentukan apakah akan menghapus skrip saat ini dan/atau berapa banyak langkah jalur Merkle yang akan dipangkas.

Opcode TLUV menghitung scriptPubKey yang diperbarui dan memverifikasi apakah output yang sesuai dengan input saat ini digunakan untuk scriptPubKey ini.

TLUV terinspirasi oleh konsep CoinPool. Saat ini, kumpulan federasi dapat dibuat hanya dengan transaksi yang telah ditandatangani sebelumnya, namun jika ingin keluar tanpa izin, jumlah tanda tangan yang jauh lebih besar perlu dibuat. TLUV, di sisi lain, memungkinkan keluar tanpa izin tanpa penandatanganan terlebih dahulu. Misalnya, sekelompok mitra dapat mengumpulkan dana mereka menggunakan Taproot untuk membangun UTXO bersama. Mereka dapat menggunakan kunci Taproot untuk memindahkan dana secara internal atau menandatangani bersama untuk memulai pembayaran secara eksternal. Individu dapat menarik diri dari kumpulan dana bersama kapan saja, menghapus jalur pembayaran mereka, sementara yang lain masih dapat menyelesaikan pembayaran melalui jalur asli, dan penarikan individu tidak mengungkapkan informasi lain tentang orang lain di dalamnya. Model ini lebih efisien dan privat dibandingkan transaksi non-pooled.

Opcode TLUV menerapkan pembatasan pengeluaran parsial dengan memperbarui Taproot Trie asli, tetapi tidak menerapkan introspeksi terhadap jumlah keluaran. Oleh karena itu, opcode baru IN_OUT_AMOUNT juga diperlukan. Opcode ini mendorong dua item ke dalam tumpukan: jumlah UTXO dari masukan ini dan jumlah keluaran yang sesuai, lalu orang yang menggunakan TLUV perlu menggunakan operator matematika untuk memverifikasi bahwa dana disimpan dengan benar di scriptPubKey yang diperbarui.

Introspeksi jumlah keluaran menambah kompleksitas, karena jumlah dalam satoshi memerlukan hingga 51 bit untuk direpresentasikan, tetapi skrip hanya mengizinkan operasi matematika 32-bit. Hal ini memerlukan pendefinisian ulang perilaku opcode untuk meningkatkan operator dalam skrip atau mengganti IN_OUT_AMOUNT dengan SIGHASH_GROUP.

TLUV berpotensi menjadi solusi untuk kumpulan lapisan 2 yang terdesentralisasi, namun keandalannya dalam mengadaptasi Taproot Trie masih perlu dikonfirmasi.

MAT

MATT (Merkleize All The Things) bertujuan untuk mencapai tiga tujuan: Merkleisasi negara, Merkleisasi naskah, dan Merkleisasi pertunjukan, sehingga mewujudkan kontrak pintar universal.

  • Merkleisasi negara: Ini melibatkan pembuatan Merkle Trie, di mana setiap node daun mewakili hash negara, dan Merkle Root mewujudkan keadaan kontrak secara keseluruhan.

  • Merkleisasi skrip: Ini mengacu pada penggunaan Tapscript untuk membentuk MAST, di mana setiap simpul daun mewakili kemungkinan jalur transisi keadaan.

  • Merkleisasi kinerja: Merkleisasi kinerja melalui komitmen kriptografi dan mekanisme tantangan penipuan. Untuk fungsi komputasi apa pun, peserta dapat menghitungnya secara off-chain dan kemudian mengeluarkan komitmen f(x)=y. Jika peserta lain menemukan hasil yang salah f(x)=z, mereka dapat memulai tantangan. Arbitrase dilakukan melalui pencarian biner, mirip dengan prinsip Optimistic Rollup.

Implementasi Merkel

Untuk mengimplementasikan MATT, bahasa skrip Bitcoin harus memiliki kemampuan berikut:

  • Paksa keluaran untuk memiliki skrip tertentu (dan nomornya)

  • Tambahkan sepotong data ke output

  • Membaca data dari input saat ini (atau input lain)

Poin kedua sangat penting: data dinamis berarti bahwa keadaan dapat dihitung dari data masukan yang diberikan oleh konsumen, karena hal ini memungkinkan untuk mensimulasikan mesin keadaan, yang mampu menentukan keadaan berikutnya dan data tambahan. Skema MATT mencapai hal ini melalui opcode OP_CHECKCONTRACTVERIFY (OP_CCV), yang merupakan penggabungan opcode OP_CHECKOUTPUTCONTRACTVERIFY dan OP_CHECKINPUTCONTRACTVERIFY yang diusulkan sebelumnya, menggunakan parameter flag tambahan untuk menentukan target operasi.

Mengontrol jumlah keluaran: Metode paling mudah adalah dengan melakukan introspeksi secara langsung; namun, jumlah keluaran adalah angka 64-bit dan memerlukan aritmatika 64-bit, yang menimbulkan banyak kerumitan dalam skrip Bitcoin. OP_CCV menggunakan metode pemeriksaan tertunda seperti OP_VAULT, di mana jumlah masukan dari semua masukan untuk keluaran yang sama di CCV dijumlahkan sebagai batas bawah untuk jumlah keluaran tersebut. Penundaan ini karena pemeriksaan ini terjadi selama transaksi, bukan selama evaluasi input skrip.

Mengingat banyaknya bukti penipuan, beberapa varian kontrak MATT harus mampu menerapkan semua jenis kontrak pintar atau konstruksi lapisan 2, meskipun persyaratan tambahan (seperti penguncian dana dan penundaan periode tantangan) perlu dievaluasi secara akurat; diperlukan untuk mengevaluasi aplikasi mana yang dapat menerima transaksi. Misalnya, gunakan komitmen kriptografi dan mekanisme tantangan penipuan untuk meniru fungsi OP_ZK_VERIFY untuk menerapkan Rollup yang tidak dapat dipercaya pada Bitcoin.

Dalam praktiknya, hal ini sudah terjadi. Johan Torås Halseth menerapkan elftrace menggunakan opcode OP_CHECKCONTRACTVERIFY dalam proposal soft fork MATT, yang memungkinkan program apa pun yang dikompilasi dengan dukungan RISC-V untuk diverifikasi pada blockchain Bitcoin, memungkinkan satu pihak dalam perjanjian kontrak untuk melewati Verifikasi kontrak untuk mengakses dana, menjembatani verifikasi asli Bitcoin.

CSFS（OP_CHECKSIGFROMSTACK）

Dari pengenalan kode operasi APO, kita mengetahui bahwa OP_CHECKSIG (dan operasi terkaitnya) bertanggung jawab untuk menyusun transaksi, penghitungan hash, dan memverifikasi tanda tangan. Namun, pesan yang diverifikasi oleh operasi ini diserialkan melalui transaksi opcode dan tidak mengizinkan pesan lain untuk ditentukan. Sederhananya, peran OP_CHECKSIG (dan operasi terkaitnya) adalah menggunakan mekanisme tanda tangan untuk memverifikasi apakah UTXO yang digunakan sebagai input transaksi diizinkan untuk digunakan oleh pemegang tanda tangan, sehingga melindungi keamanan Bitcoin.

CSFS, seperti namanya, memeriksa Signature From Stack. Opcode CSFS menerima tiga parameter dari tumpukan: tanda tangan, pesan, dan kunci publik, dan memverifikasi validitas tanda tangan. Ini berarti bahwa orang dapat meneruskan pesan apa pun ke tumpukan melalui saksi dan memverifikasinya melalui CSFS, sehingga memungkinkan beberapa inovasi Bitcoin.

Fleksibilitas CSFS memungkinkannya menerapkan mekanisme seperti tanda tangan pembayaran, delegasi, kontrak oracle, jaminan perlindungan pembelanjaan ganda, dan yang lebih penting, introspeksi transaksi. Prinsip introspeksi transaksi menggunakan CSFS sangat sederhana: jika konten transaksi yang digunakan oleh OP_CHECKSIG didorong ke tumpukan melalui saksi, dan OP_CSFS dan OP_CHECKSIG diverifikasi menggunakan kunci publik dan tanda tangan yang sama, dan jika kedua verifikasi berhasil lolos, maka Isi pesan apa pun ke OP_CSFS sama dengan transaksi pengeluaran berseri (dan data lainnya) yang secara implisit digunakan oleh OP_CHECKSIG. Kami kemudian mendapatkan data transaksi terverifikasi di tumpukan yang dapat digunakan untuk membatasi pengeluaran transaksi menggunakan opcode lain.

CSFS sering terlihat bersama dengan OP_CAT karena OP_CAT dapat menggabungkan berbagai bidang transaksi untuk menyelesaikan serialisasi, memungkinkan pemilihan bidang transaksi yang lebih tepat yang diperlukan untuk introspeksi. Tanpa OP_CAT, skrip tidak dapat menghitung ulang hash dari data yang dapat diperiksa satu per satu, sehingga yang dapat dilakukan hanyalah memeriksa apakah hash sesuai dengan nilai tertentu, yang berarti token hanya dapat dibelanjakan melalui satu transaksi tertentu.

CSFS dapat mengimplementasikan opcode seperti CLTV, CSV, CTV, APO, dll., menjadikannya opcode introspeksi serbaguna. Oleh karena itu, ini juga berkontribusi pada solusi skalabilitas lapisan 2 Bitcoin. Kerugiannya adalah memerlukan penambahan salinan lengkap transaksi yang ditandatangani ke dalam tumpukan, yang dapat meningkatkan ukuran transaksi secara signifikan menggunakan introspeksi CSFS. Opcode introspeksi tujuan tunggal seperti CLTV dan CSV memiliki sedikit overhead jika dibandingkan, tetapi menambahkan setiap opcode introspeksi khusus baru memerlukan perubahan konsensus.

TXHASH (OP_TXHASH)

OP_TXHASH adalah opcode introspeksi sederhana yang memungkinkan operator memilih hash dari bidang tertentu dan memasukkannya ke dalam tumpukan. Secara khusus, OP_TXHASH memunculkan flag txhash dari tumpukan, menghitung txhash (yang diberi tag) berdasarkan flag tersebut, dan kemudian mendorong hash yang dihasilkan kembali ke tumpukan.

Karena kemiripan antara TXHASH dan CTV, banyak perbincangan mengenai keduanya di masyarakat.

TXHASH dapat dilihat sebagai peningkatan umum ke CTV, yang menyediakan templat transaksi yang lebih canggih dan memungkinkan pengguna untuk secara eksplisit menentukan berbagai bagian transaksi pengeluaran, memecahkan banyak masalah terkait biaya transaksi. Tidak seperti opcode Perjanjian lainnya, TXHASH tidak memerlukan salinan data yang diperlukan dalam kesaksian, sehingga mengurangi kebutuhan penyimpanan; tidak seperti CTV, TXHASH tidak kompatibel dengan NOP dan hanya dapat diimplementasikan dalam tapscript; sebagai alternatif CTV dan APO.

Dari perspektif pembuatan kontrak, TXHASH lebih kondusif untuk membuat "kontrak tambahan" di mana semua bagian data transaksi yang ingin Anda perbaiki dimasukkan ke dalam tumpukan, di-hash bersama-sama, dan diverifikasi bahwa hash yang dihasilkan cocok dengan nilai tetap. Cocok;CTV adalah lebih cocok untuk membuat "kontrak subtraktif" di mana semua bagian data transaksi yang ingin Anda simpan bebas dimasukkan ke dalam tumpukan. Kemudian, dengan menggunakan opcode SHA256 bergulir, pemrosesan hash dimulai dari keadaan perantara tetap yang dikomit ke awalan data hash transaksi. Bagian bebasnya di-hash ke keadaan peralihan ini.

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

BIP yang terkait dengan TXHASH saat ini dalam status Draf di GitHub dan belum diberi nomor.

OP_CAT

OP_CAT adalah opcode misterius yang awalnya ditinggalkan oleh Satoshi Nakamoto karena alasan keamanan, namun baru-baru ini memicu diskusi hangat di kalangan pengembang Bitcoin Core dan bahkan memicu budaya Meme di Internet. Pada akhirnya, OP_CAT disetujui berdasarkan BIP-347, dan disebut-sebut sebagai proposal BIP yang kemungkinan besar akan disahkan dalam waktu dekat.

Faktanya, perilaku OP_CAT sangat sederhana: ia menggabungkan dua elemen dari tumpukan. Bagaimana cara mengimplementasikan fungsionalitas Covenant?

Faktanya, kemampuan untuk menghubungkan dua elemen berhubungan dengan struktur data kriptografi yang kuat: Merkle Trie. Untuk membangun Merkle Trie, hanya diperlukan penggabungan dan hashing, dan fungsi hashing disediakan dalam Skrip Bitcoin. Oleh karena itu, dengan menggunakan OP_CAT, secara teoritis kami dapat memverifikasi bukti Merkle dalam skrip Bitcoin, yang merupakan salah satu metode verifikasi ringan paling umum dalam teknologi blockchain.

Seperti disebutkan sebelumnya, CSFS dapat mengimplementasikan solusi Kovenan umum dengan bantuan OP_CAT. Faktanya, OP_CAT sendiri dapat mengaktifkan introspeksi transaksi bahkan tanpa CSFS, dengan memanfaatkan struktur tanda tangan Schnorr.

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

Bidang-bidang ini berisi elemen utama transaksi. Dengan menempatkannya di scriptPubKey atau Witness, dan menggunakan OP_CAT bersama dengan OP_SHA256, kita dapat membuat tanda tangan Schnorr dan memverifikasinya menggunakan OP_CHECKSIG. Jika verifikasi berhasil, tumpukan akan menyimpan data transaksi terverifikasi, sehingga memungkinkan introspeksi transaksi. Hal ini memungkinkan kami mengekstrak dan “memeriksa” berbagai bagian transaksi, seperti masukan, keluaran, alamat tujuan, atau jumlah Bitcoin yang terlibat.

Untuk prinsip kriptografi spesifik, Anda dapat merujuk ke artikel Andrew Poelstra "Trik CAT dan Schnorr".

Secara keseluruhan, keserbagunaan OP_CAT memungkinkannya untuk mensimulasikan hampir semua opcode Perjanjian. Banyak opcode Perjanjian mengandalkan fungsionalitas OP_CAT, yang sangat meningkatkan posisinya dalam daftar gabungan. Secara teori, hanya mengandalkan OP_CAT dan opcode Bitcoin yang ada, kita dapat berharap untuk membangun BTC ZK Rollup yang diminimalkan kepercayaan. Starknet, Chakra, dan mitra ekosistem lainnya secara aktif mempromosikan tujuan ini.

Kesimpulannya

Saat kami mengeksplorasi berbagai strategi untuk menskalakan Bitcoin dan meningkatkan kemampuan programnya, jelas bahwa jalur ke depan melibatkan perpaduan perbaikan asli, komputasi off-chain, dan kemampuan skrip yang canggih.

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

Penskalaan komputasi off-chain adalah masa depan, namun kemampuan program Bitcoin memerlukan terobosan untuk lebih mendukung skalabilitas ini dan menjadi mata uang global yang sesungguhnya.

Namun, sifat komputasi pada Bitcoin pada dasarnya berbeda dengan sifat komputasi pada Ethereum. Bitcoin hanya mendukung "verifikasi" sebagai bentuk penghitungan dan tidak dapat melakukan penghitungan umum, sedangkan Ethereum bersifat komputasi, dan verifikasi adalah produk sampingan dari penghitungan. Perbedaan ini dapat dilihat dalam satu hal: Ethereum membebankan biaya bahan bakar untuk transaksi yang tidak dapat dieksekusi, sedangkan Bitcoin tidak membebankan biaya bahan bakar untuk transaksi yang tidak dapat dieksekusi.

Kontrak adalah bentuk kontrak pintar yang didasarkan pada verifikasi, bukan perhitungan. Dengan pengecualian segelintir fundamentalis Satoshi, semua orang tampaknya setuju bahwa kontrak adalah pilihan yang baik untuk meningkatkan Bitcoin. Namun, masyarakat masih memperdebatkan metode mana yang harus digunakan untuk melaksanakan kontrak tersebut.

APO, OP_VAULT, dan TLUV lebih memilih aplikasi langsung. Memilih ketiga metode ini dapat mewujudkan aplikasi tertentu dengan lebih murah dan efisien. Penggemar Lightning Network akan memilih APO untuk mengimplementasikan LN-Symmetry; pengguna yang ingin mengimplementasikan Vault sebaiknya menggunakan OP_VAULT; dan untuk membangun CoinPool, TLUV dapat memberikan privasi dan efisiensi yang lebih baik. OP_CAT dan TXHASH lebih kaya fitur, kecil kemungkinannya memiliki kerentanan keamanan, dan dapat digabungkan dengan opcode lain untuk mencapai lebih banyak kasus penggunaan, namun biayanya mungkin meningkatkan kompleksitas skrip. CTV dan CSFS menyesuaikan metode pemrosesan blockchain, CTV menerapkan keluaran tertunda, dan CSFS menerapkan tanda tangan tertunda. MATT menonjol karena eksekusinya yang optimis dan strategi anti penipuan, memanfaatkan struktur Merkle Trie untuk mengimplementasikan kontrak pintar tujuan umum, namun fungsi introspeksi masih memerlukan opcode baru.

Kami melihat komunitas Bitcoin secara aktif mendiskusikan kemungkinan memperoleh Perjanjian melalui soft fork. Starknet secara resmi mengumumkan akan bergabung dengan ekosistem Bitcoin dan berencana menerapkan penyelesaian pada jaringan Bitcoin dalam waktu enam bulan setelah merger OP_CAT. Chakra akan terus memperhatikan perkembangan terkini dalam ekosistem Bitcoin, mempromosikan penggabungan soft fork OP_CAT, dan menggunakan kemampuan program yang dibawa oleh Kovenan untuk membangun lapisan penyelesaian Bitcoin yang lebih aman dan efisien.