Ikhtisar

dibandingkan dengan blockchain yang turing-lengkap seperti ethereum, scripting bitcoin dianggap sangat terbatas, hanya mampu melakukan operasi dasar, dan bahkan kurang mendukung perkalian dan pembagian. yang lebih penting, data blockchain sendiri hampir tidak dapat diakses oleh script, sehingga mengakibatkan kurangnya fleksibilitas dan kemampuan pemrograman yang signifikan. oleh karena itu, telah ada upaya yang berlangsung lama untuk memungkinkan skrip bitcoin mencapai introspeksi.

introspeksi merujuk pada kemampuan skrip bitcoin untuk memeriksa dan membatasi data transaksi. ini memungkinkan skrip untuk mengontrol penggunaan dana berdasarkan detail transaksi tertentu, memungkinkan fungsionalitas yang lebih kompleks. saat ini, sebagian besar opcode bitcoin baik mendorong data yang disediakan pengguna ke tumpukan atau memanipulasi data yang ada di tumpukan. opcode introspeksi, namun, dapat mendorong data dari transaksi saat ini (seperti penanda waktu, jumlah, txid, dll.) ke tumpukan, memungkinkan kontrol yang lebih detail terhadap pengeluaran utxo.

Saat ini, hanya ada tiga opcode utama dalam scripting bitcoin yang mendukung introspeksi: checklocktimeverify, checksequenceverify, dan checksig, bersama dengan variasi-variasi nya seperti checksigverify, checksigadd, checkmultisig, dan checkmultisigverify.

covenant, secara sederhana, mengacu pada pembatasan tentang bagaimana koin ditransfer, memungkinkan pengguna untuk menentukan bagaimana utxo didistribusikan. banyak perjanjian dilaksanakan melalui opcode introspeksi, dan diskusi tentang introspeksi sekarang telah dikategorikan dalam topik perjanjian pada Bitcoin optech.

saat ini bitcoin memiliki dua perjanjian, csv (checksequenceverify) dan cltv (checklocktimeverify), keduanya perjanjian berbasis waktu yang menjadi dasar bagi banyak solusi skala seperti jaringan petir. ini menggambarkan bagaimana solusi skala bitcoin sangat bergantung pada introspeksi dan perjanjian.

Bagaimana kita menambahkan kondisi pada transfer koin? Di dunia kripto, metode paling umum kami adalah melalui komitmen, sering kali diimplementasikan melalui hash. Untuk membuktikan bahwa persyaratan transfer terpenuhi, mekanisme tanda tangan juga diperlukan untuk verifikasi. Oleh karena itu, banyak penyesuaian pada hash dan tanda tangan ada dalam perjanjian.

di bawah ini, kami akan menjelaskan proposal opcode perjanjian yang banyak dibahas.

ctv (checktemplateverify) bip-119

ctv (checktemplateverify) adalah proposal upgrade bitcoin yang terdapat dalam bip-119 yang telah menarik perhatian komunitas yang signifikan. ctv memungkinkan script output untuk menentukan template untuk pengeluaran dana dalam sebuah transaksi, termasuk bidang-bidang seperti nversion, nlocktime, scriptsig hash, input count, sequences hash, output count, outputs hash, input index. pembatasan template ini dilaksanakan melalui komitmen hash, dan ketika dana tersebut dihabiskan, script memeriksa apakah nilai hash dari bidang-bidang yang ditentukan dalam transaksi pengeluaran cocok dengan nilai hash dalam script input. ini secara efektif membatasi waktu, metode, dan jumlah transaksi masa depan dari utxo tersebut.

Perlu diperhatikan, input txid dikecualikan dari hash ini. Pengecualian ini diperlukan, karena dalam transaksi warisan maupun segwit, txid bergantung pada nilai-nilai dalam scriptpubkey saat menggunakan jenis tanda tangan sighash_all default. Termasuk txid akan menyebabkan ketergantungan siklik dalam komitmen hash, sehingga tidak mungkin untuk membuatnya.

ctv menerapkan introspeksi dengan langsung menarik informasi transaksi yang ditentukan untuk di-hash dan membandingkannya dengan komitmen pada stack. metode introspeksi ini lebih sedikit menuntut ruang rantai blok tetapi kurang fleksibilitas.

Dasar dari solusi lapisan kedua Bitcoin seperti jaringan petir adalah transaksi yang ditandatangani sebelumnya. Pra-penandatanganan biasanya merujuk pada pembuatan dan penandatanganan transaksi di muka namun tidak menyiarkannya sampai kondisi tertentu terpenuhi. Pada dasarnya, ctv menerapkan bentuk pra-penandatanganan yang lebih ketat, dengan memposting komitmen pra-penandatanganan di rantai, terbatas pada template yang telah ditentukan.

ctv awalnya diusulkan untuk mengurangi kemacetan dalam bitcoin, yang juga dapat disebut sebagai kontrol kemacetan. selama masa kemacetan tinggi, ctv dapat melakukan komitmen untuk beberapa transaksi masa depan dalam satu transaksi, menghindari kebutuhan untuk menyiarkan beberapa transaksi pada saat-saat sibuk dan menyelesaikan transaksi sebenarnya setelah kemacetan mereda. ini dapat sangat membantu selama bank run pertukaran. selain itu, template juga dapat digunakan untuk mengimplementasikan vaults untuk melindungi dari serangan peretasan. karena arah dana sudah ditentukan, peretas tidak dapat mengarahkan utxos menggunakan skrip ctv ke alamat mereka sendiri.

ctv dapat secara signifikan meningkatkan jaringan lapisan-dua. misalnya, dalam jaringan lightning, ctv dapat memungkinkan pembuatan timeout tree dan channel factory dengan mengembangkan satu utxo menjadi pohon ctv, membuka banyak saluran status dengan hanya satu transaksi dan satu konfirmasi. selain itu, ctv juga mendukung perdagangan atomik dalam protokol ark melalui atlc.

apo (sighash_anyprevout) bip-118

bip-118 memperkenalkan jenis signature hash flag baru untuk tapscript, yang bertujuan untuk memudahkan logika pengeluaran yang lebih fleksibel yang dikenal sebagai sighash_anyprevout. apo dan ctv memiliki banyak kesamaan. ketika mengatasi masalah siklik antara scriptpubkeys dan txids, pendekatan apo adalah dengan mengesampingkan informasi input yang relevan dan hanya menandatangani output, memungkinkan transaksi untuk terikat secara dinamis ke utxo yang berbeda.

secara logis, operasi verifikasi tanda tangan op_checksig (dan variasinya) melakukan tiga fungsi:

1. merangkai bagian-bagian transaksi pengeluaran.
2. menghash mereka.
3. memverifikasi bahwa hash telah ditandatangani oleh kunci yang diberikan.

spesifik dari tanda tangan memiliki banyak fleksibilitas, dengan keputusan tentang bidang transaksi mana yang akan ditandatangani ditentukan oleh flag sighash. menurut definisi opcode tanda tangan dalam bip 342, flag sighash dibagi menjadi sighash_all, sighash_none, sighash_single, dan sighash_anyonecanpay. sighash_anyonecanpay mengontrol input, sementara yang lain mengontrol output.

sighash_all adalah bendera sighash default, menandatangani semua output; sighash_none tidak menandatangani output apa pun; sighash_single menandatangani output tertentu. sighash_anyonecanpay dapat diatur dengan tiga bendera sighash pertama. jika sighash_anyonecanpay diatur, hanya input yang ditentukan yang ditandatangani; jika tidak, semua input harus ditandatangani.

Jelas, tanda Sighash ini tidak menghilangkan pengaruh dari input, bahkan Sighash_AnyoneCanPay yang membutuhkan komitmen terhadap satu input.

Oleh karena itu, BIP 118 mengusulkan sighash_anyprevout. Tanda tangan apo tidak perlu mengikat ke utxo input yang dihabiskan (dikenal sebagai prevout) tetapi hanya perlu menandatangani output, memberikan fleksibilitas yang lebih besar dalam kontrol Bitcoin. Dengan membangun transaksi sebelumnya dan membuat tanda tangan dan kunci publik sekali pakai yang sesuai, aset yang dikirim ke alamat kunci publik tersebut harus dihabiskan melalui transaksi yang telah dibangun sebelumnya, sehingga mengimplementasikan suatu perjanjian. Fleksibilitas apo juga dapat digunakan untuk perbaikan transaksi; jika suatu transaksi terjebak di rantai karena biaya rendah, transaksi lain dapat dengan mudah dibuat untuk meningkatkan biaya tanpa perlu tanda tangan baru. Selain itu, untuk dompet multi-tanda tangan, tidak bergantung pada input yang dihabiskan membuat operasi lebih nyaman.

karena menghilangkan siklus antara scriptpubkeys dan input txids, apo dapat melakukan introspeksi dengan menambahkan data output di dalam saksi, meskipun ini masih memerlukan konsumsi ruang saksi tambahan.

untuk protokol di luar rantai seperti jaringan petir dan vaults, apo mengurangi kebutuhan untuk menyimpan status perantara, sangat mengurangi persyaratan penyimpanan dan kompleksitas. Kasus penggunaan langsung apo yang paling jelas adalah eltoo, yang menyederhanakan pabrik saluran, membangun penjaga ringan dan murah, serta memungkinkan keluarnya satu arah tanpa meninggalkan status yang salah, meningkatkan kinerja jaringan petir dalam banyak cara. apo juga dapat digunakan untuk mensimulasikan fungsi ctv, meskipun memerlukan individu untuk menyimpan tanda tangan dan transaksi yang sudah ditandatangani, yang lebih mahal dan kurang efisien daripada ctv.

Kritik utama apo berpusat pada kebutuhan versi kunci baru, yang tidak dapat diimplementasikan dengan hanya bersifat kompatibel mundur. Selain itu, tipe hash tanda tangan baru dapat memperkenalkan risiko potensial pengeluaran ganda. Setelah diskusi komunitas yang luas, apo menambahkan tanda tangan reguler di atas mekanisme penandatanganan asli untuk meredakan kekhawatiran keamanan, sehingga mendapatkan kode bip-118.

op_vault bip-345

bip-345 mengusulkan penambahan dua opcode baru, op_vault dan op_vault_recover, yang saat digabungkan dengan ctv, mengimplementasikan perjanjian khusus yang memungkinkan pengguna untuk menerapkan penundaan pengeluaran koin tertentu. selama penundaan ini, transaksi yang sebelumnya telah dilakukan dapat "dibalik" melalui jalur pemulihan.

pengguna dapat membuat sebuah brankas dengan membuat alamat taproot khusus yang harus mengandung setidaknya dua skrip dalam masternya: satu dengan opcode op_vault untuk memfasilitasi proses penarikan yang diharapkan, dan yang lain dengan opcode op_vault_recover untuk memastikan koin dapat dikembalikan kapan saja sebelum penyelesaian penarikan.

Bagaimana op_vault melaksanakan penarikan terkunci waktu yang dapat diinterupsi? op_vault mencapai ini dengan mengganti skrip op_vault yang sudah dihabiskan dengan skrip yang ditentukan, yang efektif mengupdate satu daun tunggal dari mast sambil meninggalkan sisa node daun taproot tidak berubah. desain ini mirip dengan tluv, kecuali bahwa op_vault tidak mendukung pembaruan kunci internal.

Dengan memperkenalkan template selama proses pembaruan skrip, dimungkinkan untuk membatasi pembayaran. Parameter time-lock ditentukan oleh op_vault, dan template opcode CTV membatasi kumpulan output yang dapat dihabiskan melalui jalur skrip ini.

bip-345 dirancang khusus untuk brankas, memanfaatkan op_vault dan op_vault_recover untuk memberikan pengguna metode kustodial yang aman yang menggunakan kunci yang sangat aman (seperti dompet kertas atau multisig terdistribusi) sebagai jalur pemulihan, sambil mengkonfigurasi penundaan tertentu untuk pembayaran reguler. perangkat pengguna terus memantau pengeluaran dari brankas, dan jika transfer yang tidak terduga terjadi, pengguna dapat memulai pemulihan.

Implementasi vault melalui bip-345 memerlukan pertimbangan masalah biaya, terutama untuk transaksi pemulihan. Solusi yang mungkin termasuk cpfp (child pays for parent), anchor sementara, dan penanda tanda tangan hash grup baru.

tluv (tapleafupdateverify)

Skema tluv dibangun seputar taproot dan bertujuan untuk secara efisien menangani masalah keluar dari shared utxos. Prinsip panduan adalah ketika output taproot dihabiskan, pembaruan parsial dapat dilakukan pada kunci internal dan mast (tapscript trie) melalui transformasi kriptografi dan struktur internal dari alamat taproot, seperti yang dijelaskan oleh skrip tluv. Hal ini memungkinkan implementasi fungsi perjanjian.

konsep skema tluv adalah untuk membuat alamat taproot baru berdasarkan input pengeluaran saat ini dengan memperkenalkan opcode baru, tapleaf_update_verify. ini dapat dicapai dengan melakukan satu atau lebih tindakan berikut:

1. perbarui kunci publik internal
2. memotong jalur Merkle
3. menghapus skrip yang sedang dieksekusi
4. tambahkan langkah baru di akhir jalur merkle

secara khusus, tluv menerima tiga input:

1. satu yang menentukan cara memperbarui kunci publik internal.
2. satu yang menentukan langkah baru untuk jalur merkle.
3. salah satu yang menentukan apakah akan menghapus skrip saat ini dan/atau berapa langkah dari jalur merkle yang akan dipangkas.

opcode tluv menghitung scriptpubkey yang diperbarui dan memverifikasi bahwa output yang sesuai dengan input saat ini dihabiskan untuk scriptpubkey ini.

tluv terinspirasi oleh konsep coinpool. saat ini, kolam bersama dapat dibuat hanya dengan menggunakan transaksi yang telah ditandatangani sebelumnya, tetapi jika keluaran tanpa izin ingin direalisasikan, itu akan memerlukan penciptaan jumlah tanda tangan yang berkembang secara eksponensial. Namun, tluv memungkinkan keluaran tanpa izin tanpa adanya tanda tangan sebelumnya. Sebagai contoh, sekelompok mitra dapat menggunakan taproot untuk membangun utxo bersama, mendanai dana mereka bersama. Mereka dapat memindahkan dana secara internal menggunakan kunci taproot atau menandatangani bersama untuk memulai pembayaran secara eksternal. Individu dapat keluar dari kolam dana bersama kapan saja, menghapus jalur pembayaran mereka, sementara orang lain masih dapat menyelesaikan pembayaran melalui jalur asli, dan keluarnya individu tidak mengekspos informasi tambahan tentang orang lain di dalamnya. Mode ini lebih efisien dan pribadi dibandingkan dengan transaksi tanpa kolam.

opcode tluv mencapai pembatasan pengeluaran parsial dengan memperbarui trie taproot asli, namun tidak mengimplementasikan introspeksi jumlah output. oleh karena itu, opcode baru, in_out_amount, juga diperlukan. opcode ini mendorong dua item ke tumpukan: jumlah utxo untuk input ini dan jumlah untuk output yang sesuai, kemudian pengguna tluv diharapkan menggunakan operator matematika untuk memverifikasi bahwa dana tetap dipertahankan secara tepat di dalam scriptpubkey yang diperbarui.

introspeksi jumlah output menambah kompleksitas karena jumlah dalam satoshi membutuhkan hingga 51 bit untuk mewakili, tetapi skrip hanya memungkinkan operasi matematika 32-bit. ini membutuhkan pengubahan perilaku opcode untuk meningkatkan operator dalam skrip atau menggunakan sighash_group untuk menggantikan in_out_amount.

tluv memiliki potensi sebagai solusi untuk kolam dana layer 2 terdesentralisasi, meskipun keandalan dalam menyesuaikan trie taproot masih perlu konfirmasi.

matt

matt (merkleize semua hal) bertujuan untuk mencapai tiga tujuan: merkleizing keadaan, merkleizing skrip, dan merkleizing eksekusi, sehingga memungkinkan kontrak pintar universal.

1. merkleizing the state: ini melibatkan pembangunan merkle trie, di mana setiap simpul daun mewakili hash dari sebuah state, dengan merkle root mewakili keseluruhan state dari kontrak.
2. merkleizing skrip: ini merujuk pada pembentukan mast menggunakan tapscript, di mana setiap simpul daun mewakili jalur transisi keadaan yang mungkin.
3. eksekusi merkleizing: eksekusi merkleized melalui komitmen kriptografi dan mekanisme tantangan penipuan. untuk setiap fungsi komputasi, peserta dapat menghitung off-chain dan kemudian menerbitkan 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.

merkleizing eksekusi

untuk mengimplementasikan matt, bahasa pemrograman bitcoin perlu memiliki fungsionalitas berikut:

1. memaksa hasil keluaran memiliki skrip tertentu (dan jumlahnya)
2. melampirkan sebuah data ke output
3. membaca data dari input saat ini (atau dari yang lain)

Titik kedua sangat penting: data dinamis berarti bahwa status dapat dihitung melalui data masukan yang diberikan oleh pengeluar, karena ini memungkinkan untuk mensimulasikan mesin status, yang mampu menentukan status berikutnya dan data tambahan. Skema matt mengimplementasikan ini melalui opcode op_checkcontractverify (op_ccv), penggabungan opcode op_checkoutputcontractverify dan op_checkinputcontractverify yang sebelumnya diusulkan, menggunakan parameter flags tambahan untuk menentukan target operasi.

Kontrol atas jumlah output: metode paling langsung adalah introspeksi langsung; namun, jumlah output adalah angka 64-bit, memerlukan aritmatika 64-bit, yang menyajikan kompleksitas yang signifikan dalam bitcoin scripting. Op_ccv mengadopsi pendekatan pengecekan tertunda, seperti op_vault, di mana semua input ke output yang sama dengan ccv memiliki jumlah input mereka dijumlahkan, berfungsi sebagai batas bawah untuk jumlah output tersebut. penundaan ini terjadi karena pemeriksaan ini terjadi selama proses transaksi daripada selama evaluasi skrip dari input.

mengingat universalitas bukti penipuan, varian tertentu dari kontrak matt harus mampu mengimplementasikan semua jenis kontrak pintar atau konstruksi lapisan 2, meskipun persyaratan tambahan (seperti penguncian modal dan penundaan periode tantangan) perlu dinilai dengan akurat; penelitian lebih lanjut diperlukan untuk mengevaluasi aplikasi mana yang dapat diterima untuk transaksi. misalnya, menggunakan komitmen kriptografi dan mekanisme tantangan penipuan untuk mensimulasikan fungsi op_zk_verify, mencapai rollups tanpa kepercayaan pada Bitcoin.

Secara praktis, hal-hal sudah terjadi. Johan Torås Halseth telah menggunakan opcode op_checkcontractverify dari proposal soft fork Matt untuk mengimplementasikan elftrace, yang memungkinkan program apa pun yang mendukung kompilasi RISC-V untuk diverifikasi di blockchain Bitcoin, memungkinkan pihak dalam protokol kontrak untuk mengakses dana melalui verifikasi kontrak, sehingga menjembatani verifikasi asli Bitcoin.

csfs (op_checksigfromstack)

Dari pengenalan opcode apo, kita telah belajar bahwa op_checksig (dan operasi terkaitnya) bertanggung jawab atas perakitan transaksi, penghash-an, dan verifikasi tanda tangan. Namun, pesan yang diverifikasi oleh operasi-operasi ini diperoleh dari serialisasi transaksi menggunakan opcode, dan tidak memungkinkan untuk menentukan pesan lain. Dalam istilah sederhana, op_checksig (dan operasi terkaitnya) berfungsi untuk memverifikasi melalui mekanisme tanda tangan apakah utxo yang digunakan sebagai input transaksi telah diotorisasi untuk dikeluarkan oleh pemegang tanda tangan, sehingga melindungi keamanan Bitcoin.

csfs, seperti namanya, memeriksa tanda tangan dari tumpukan. opcode csfs menerima tiga parameter dari tumpukan: tanda tangan, pesan, dan kunci publik, dan memverifikasi keabsahan tanda tangan. ini berarti bahwa orang dapat melewatkan pesan apa pun ke tumpukan melalui saksi dan memverifikasinya melalui csfs, memungkinkan beberapa inovasi pada Bitcoin.

Fleksibilitas CSF memungkinkannya untuk menerapkan mekanisme seperti tanda tangan pembayaran, delegasi otorisasi, kontrak Oracle, obligasi perlindungan pengeluaran ganda, dan yang lebih penting, introspeksi transaksi. Prinsip menggunakan CSF untuk introspeksi transaksi cukup 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 baik dengan op_csfs dan op_checksig, dan jika kedua verifikasi berhasil lolos, maka konten pesan arbitrer yang diteruskan ke op_csfs sama dengan transaksi pengeluaran serial (dan data lainnya) yang secara implisit digunakan oleh op_ tanda periksa. Kami kemudian memperoleh data transaksi terverifikasi pada tumpukan, yang dapat digunakan untuk menerapkan pembatasan untuk menghabiskan transaksi dengan opcode lain.

csfs sering muncul bersamaan dengan op_cat karena op_cat dapat menghubungkan bidang-bidang transaksi yang berbeda untuk melengkapi serialisasi, memungkinkan pemilihan bidang transaksi yang diperlukan untuk introspeksi yang lebih tepat. Tanpa op_cat, skrip tidak dapat menghitung ulang hash dari data yang dapat diperiksa secara terpisah, sehingga yang sebenarnya dapat dilakukan adalah memeriksa apakah hash tersebut sesuai dengan nilai tertentu, yang berarti bahwa koin hanya dapat dihabiskan melalui satu transaksi tertentu.

csfs dapat mengimplementasikan opcode seperti cltv, csv, ctv, apo, dll., menjadikannya opcode introspeksi yang serbaguna. Oleh karena itu, ini juga membantu dalam solusi skalabilitas untuk layer2 Bitcoin. Kekurangannya adalah itu memerlukan penambahan salinan lengkap transaksi yang ditandatangani pada tumpukan, yang dapat signifikan meningkatkan ukuran transaksi yang ditujukan untuk introspeksi menggunakan csfs. Sebaliknya, opcode introspeksi tunggal seperti cltv dan csv memiliki overhead minimal, tetapi penambahan setiap opcode introspeksi khusus baru memerlukan perubahan konsensus.

txhash (op_txhash)

op_txhash adalah opcode yang memungkinkan introspeksi langsung yang memungkinkan operator untuk memilih dan mendorong hash dari suatu bidang tertentu ke dalam tumpukan. Secara khusus, op_txhash menghapus sebuah flag txhash dari tumpukan dan menghitung sebuah txhash (berlabel) berdasarkan flag tersebut, kemudian mendorong hash yang dihasilkan kembali ke dalam tumpukan.

karena kesamaan antara txhash dan ctv, telah timbul sejumlah diskusi yang cukup besar di kalangan komunitas mengenai kedua hal tersebut.

Txhash dapat dianggap sebagai peningkatan universal CTV, menawarkan template transaksi yang lebih canggih yang memungkinkan pengguna untuk menentukan bagian dari transaksi pengeluaran secara eksplisit, mengatasi banyak masalah yang terkait dengan biaya transaksi. Tidak seperti opcode perjanjian lainnya, Txhash tidak memerlukan salinan data yang diperlukan dalam saksi, yang selanjutnya mengurangi persyaratan penyimpanan; Tidak seperti CTV, Txhash tidak kompatibel dengan NOP dan hanya dapat diimplementasikan di TapScript; Kombinasi Txhash dan CSF dapat berfungsi sebagai alternatif untuk CTV dan APO.

dari perspektif membangun perjanjian, txhash lebih memudahkan pembuatan “additive covenants,” di mana semua bagian dari data transaksi yang ingin Anda tetapkan didorong ke stack, di-hash bersama-sama, dan hasil hash-nya diverifikasi untuk mencocokkan nilai yang tetap; ctv lebih cocok untuk membuat “subtractive covenants,” di mana semua bagian dari data transaksi yang ingin Anda tetapkan bebas didorong ke stack. kemudian, menggunakan opcode sha256 bergulir, penghashan dimulai dari keadaan tengah yang tetap yang berkomitmen untuk sebuah awalan dari data hash transaksi. bagian yang bebas dihash ke keadaan tengah ini.

bidang txfieldselector yang didefinisikan dalam spesifikasi txhash diharapkan untuk diperluas ke opcode lain, seperti op_tx.

bip terkait txhash saat ini dalam status draf di github dan belum diberi nomor.

op_cat

op_cat adalah opcode yang dibalut dengan misteri, awalnya ditinggalkan oleh satoshi nakamoto karena kekhawatiran keamanan, baru-baru ini memicu diskusi intens di antara pengembang bitcoin inti dan bahkan memicu budaya meme di internet. pada akhirnya, op_cat disetujui di bawah bip-347 dan telah disebut sebagai proposal bip yang paling mungkin untuk lolos dalam waktu terakhir.

sebenarnya, perilaku op_cat sangat sederhana: itu menggabungkan dua elemen dari tumpukan. bagaimana cara kerjanya untuk mengaktifkan fungsionalitas perjanjian?

memang, kemampuan untuk menggabungkan dua elemen sesuai dengan struktur data kriptografis yang kuat: trie merkle. Untuk membangun trie merkle, hanya diperlukan operasi penggabungan dan penghash-an, dan fungsi penghash-an tersedia dalam skrip Bitcoin. Dengan demikian, dengan op_cat, secara teoritis kita dapat memverifikasi bukti merkle dalam skrip Bitcoin, yang merupakan salah satu metode verifikasi ringan yang paling umum dalam teknologi blockchain.

seperti yang disebutkan sebelumnya, csfs, dengan bantuan op_cat, dapat menerapkan skema perjanjian universal. sebenarnya, tanpa csfs, dengan memanfaatkan struktur tanda tangan schnorr, op_cat sendiri dapat mencapai inspeksi transaksi.

pada tanda tangan schnorr, pesan yang perlu ditandatangani terdiri dari bidang-bidang berikut:

bidang-bidang ini berisi elemen-elemen utama dari transaksi. dengan meletakkannya di dalam scriptpubkey atau saksi dan menggunakan op_cat yang digabungkan dengan op_sha256, kita dapat membangun tanda tangan schnorr dan memverifikasinya menggunakan op_checksig. jika verifikasi berhasil, tumpukan akan menyimpan data transaksi yang diverifikasi, mencapai introspeksi transaksi. ini memungkinkan kita untuk mengekstrak dan "memeriksa" berbagai bagian transaksi, seperti input, output, alamat target, atau jumlah bitcoin yang terlibat.

untuk prinsip-prinsip kriptografi khusus, seseorang dapat merujuk ke artikel andrew poelstra, "trik cat dan schnorr".

Secara ringkas, keandalan op_cat memungkinkannya meniru hampir semua opcode perjanjian. Sejumlah opcode perjanjian bergantung pada fungsionalitas op_cat, yang secara signifikan meningkatkan posisinya dalam daftar penggabungan. Secara teoritis, dengan hanya mengandalkan op_cat dan opcode Bitcoin yang ada, kami berharap dapat membangun BTC zk rollup yang terdesentralisasi. Starknet, chakra, dan mitra ekosistem lainnya dengan aktif mendorong hal ini terjadi.

kesimpulan

saat kita menjelajahi berbagai strategi untuk mengukur bitcoin dan meningkatkan kemampuannya dalam pemrograman, menjadi jelas bahwa jalur ke depan melibatkan kombinasi perbaikan asli, komputasi di luar rantai, dan kemampuan scripting yang canggih.

tanpa lapisan dasar yang fleksibel, tidak mungkin membangun lapisan kedua yang lebih fleksibel.

penyekalaan komputasi di luar rantai adalah masa depan, tetapi pemrograman bitcoin perlu melewati batasan ini untuk mendukung skalabilitas ini dengan lebih baik dan menjadi mata uang global yang sejati.

Namun, sifat komputasi pada bitcoin secara mendasar berbeda dengan ethereum. Bitcoin hanya mendukung "verifikasi" sebagai bentuk komputasi dan tidak dapat melakukan komputasi umum, sedangkan ethereum secara inheren komputasional, dengan verifikasi sebagai produk sampingan dari komputasi. Perbedaan ini terlihat dari satu poin: ethereum mengenakan biaya gas untuk transaksi yang gagal dieksekusi, sedangkan bitcoin tidak.

covenants mewakili bentuk kontrak pintar berdasarkan verifikasi daripada perhitungan. kecuali untuk beberapa fundamentalisme satoshi, nampaknya semua orang menganggap covenants sebagai pilihan yang baik untuk meningkatkan bitcoin. bagaimanapun, komunitas terus memperdebatkan dengan sengit tentang pendekatan mana yang harus digunakan untuk menerapkan covenants.

apo, op_vault, dan tluv cenderung menuju aplikasi langsung, dan memilih mereka dapat mencapai aplikasi tertentu secara lebih murah dan efisien. Para penggemar jaringan petir lebih suka apo untuk mencapai ln-simetri; mereka yang ingin menerapkan vault akan dilayani dengan baik oleh op_vault; untuk membangun coinpool, tluv menawarkan lebih banyak privasi dan efisiensi. op_cat dan txhash lebih serbaguna, dengan kemungkinan kecil kerentanan keamanan, dan dapat menerapkan lebih banyak kasus penggunaan ketika dikombinasikan dengan opcode lain, mungkin dengan biaya kompleksitas skrip. ctv dan csfs telah menyesuaikan pemrosesan blockchain, dengan ctv menerapkan output tertunda dan csfs menerapkan tanda tangan tertunda. matt menonjol dengan strategi eksekusi optimis dan bukti penipuan, memanfaatkan struktur trie merkle untuk menerapkan kontrak pintar universal, meskipun masih memerlukan opcode baru untuk kemampuan introspektif.

Kami melihat bahwa komunitas Bitcoin secara aktif mendiskusikan kemungkinan mendapatkan perjanjian melalui garpu lunak. Starknet telah secara resmi mengumumkan masuknya ke ekosistem Bitcoin, berencana untuk menerapkan penyelesaian di jaringan Bitcoin dalam waktu enam bulan setelah penggabungan op_cat. Chakra akan terus memantau perkembangan terbaru dalam ekosistem Bitcoin, mendorong penggabungan op_cat soft fork, dan memanfaatkan programabilitas yang dibawa oleh perjanjian untuk membangun lapisan penyelesaian Bitcoin yang lebih aman dan efisien.

disclaimer：

1. artikel ini diambil dari [ Cermin]. semua hak cipta milik penulis asli [chakra]. jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gerbang belajartim, dan mereka akan menanganinya dengan cepat.
2. penyangkalan tanggung jawab: pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim Gate.io Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.