Apakah OP_CAT terjadi? Usulan perjanjian baru saja diberi nomor BIP #347. Namun sebelum kita menggali lebih dalam, mari kita telusuri apa itu perjanjian dan mengapa para Bitcoiner menginginkannya.
Apakah Bitcoin merupakan bentuk uang elektronik digital yang ideal atau apakah kita menginginkan lebih banyak dari koin on-chain kita?
Menggaruk Permukaan: Keterbatasan Skrip Bitcoin
Untuk memahami proposal perjanjian seperti OP_CAT, sangat penting untuk memahami keterbatasan mendasar dari Bitcoin Script seperti saat ini. Bitcoin memungkinkan pembuatan kontrak pintar dasar melalui kode yang menentukan aturan untuk mengunci dan membuka kunci dana. Namun, Bitcoin Script, sebagai bahasa pemrograman, terbatas pada logika dasar yang hanya berlaku saat memindahkan koin dalam transaksi baru.
Di Bitcoin saat ini, tidak ada cara untuk melakukan pra-konfigurasi atau menentukan jalur transaksi koin Anda, atau seberapa cepat koin dapat bergerak pada saat dikunci (selain alur kerja yang diretas menggunakan PSBT, transaksi bitcoin yang ditandatangani sebagian, yang tidak dapat dilakukan dengan benar. termasuk biaya transaksi, membuktikan penghapusan jika tidak digunakan, atau mencegah penyiaran di kemudian hari).
Kesederhanaan ini, meskipun merupakan inti dari model keamanan Bitcoin, menimbulkan keterbatasan signifikan dalam kemampuan bahasa skrip untuk mendukung kontrak pintar dasar sekalipun.
Model Eksekusi Linier
Salah satu batasan Bitcoin Script adalah model operasionalnya di mana opcode dieksekusi secara berurutan tanpa loop.
Dari contoh transaksi P2PKH ini, Anda dapat melihat bagaimana skrip dijalankan secara linier: menggandakan kunci publik, melakukan hashing ke suatu alamat, memverifikasi hash terhadap skrip kunci, dan terakhir memeriksa tanda tangan terhadap kunci publik.
Tidak adanya perulangan berarti bahwa skrip Turing tidak lengkap dan dijamin akan berakhir, sehingga mencegah masalah seperti perulangan tak terbatas yang berpotensi menghentikan atau memperlambat jaringan secara signifikan. Meskipun pilihan desain ini memungkinkan penggunaan sumber daya dibatasi secara statis, hal ini juga membatasi kemampuan Script untuk mengelola alur kerja yang kompleks.
Kurangnya Aritmatika Dasar
Bitcoin Script hanya memiliki kurang dari 100 opcode nontrivial, dan yang mengejutkan, tidak ada kemampuan untuk mengalikan, membagi, atau menggabungkan objek di tumpukan. Seperti yang diketahui oleh banyak pengguna yang tertarik dengan OP_CAT, Satoshi menonaktifkan beberapa opcode di Bitcoin pada tahun 2010, termasuk antara lain OP_OR, OP_MUL (multiply), OP_DIV (divide), dan OP_CAT (concatenate). Opcode yang dinonaktifkan telah dihapus karena implementasi aslinya memiliki kerentanan yang dapat dieksploitasi yang dapat membahayakan keamanan jaringan. Namun ketiadaan opcode ini menyulitkan penghitungan dasar, yang mungkin berguna dalam skenario sederhana seperti menghitung biaya transaksi dalam kontrak.
Kurangnya Visibilitas Data Transaksi
Secara dangkal, saya pikir kebanyakan orang berasumsi bahwa kontrak pintar Bitcoin dapat melihat jumlah nilai dan bagian lain dari data transaksi, karena informasi ini sudah dapat dilihat secara publik di blockchain. Namun bertentangan dengan asumsi ini, kontrak pada Bitcoin tidak dapat menetapkan kondisi pembelanjaan berdasarkan data transaksi, karena Bitcoin Script memiliki kemampuan yang sangat terbatas untuk melihat data transaksi sama sekali.
Jika skrip memiliki kemampuan untuk menafsirkan lebih banyak detail dalam data transaksi, kita dapat membuat kontrak yang jauh lebih kuat yang dapat melakukan semua hal menyenangkan seperti menerapkan ketentuan pengeluaran tertentu, membuat transaksi multi-tahap, dan mengaktifkan fitur keamanan yang lebih canggih seperti brankas.
Apa yang kita lakukan tentang hal itu?
Kami tahu Bitcoin memiliki keterbatasan ini, dan selama bertahun-tahun banyak proposal berbeda yang telah dibahas untuk memperkenalkan (atau dalam beberapa kasus memperkenalkan kembali) fungsi ini. Eksperimen yang lebih luas dengan Bitcoin Script, seperti Simplicity dan lainnya, bertujuan untuk memberikan alternatif terhadap batasan berbasis tumpukan. Opcode seperti OP_MULTISHA256, OP_LESS, dan OP_LE32TOLE64 bertujuan untuk meningkatkan kemampuan aritmatika Bitcoin. Proposal seperti OP_CTV dan OP_CAT yang berhubungan dengan opcode introspeksi dikelompokkan dalam istilah perjanjian.
Jadi apa sebenarnya perbedaan antara kontrak pintar dan perjanjian berjangka baru?
Kontrak Cerdas vs. Perjanjian
Kontrak pintar adalah transaksi yang dijalankan sendiri yang mentransfer dana tanpa perantara. Di Bitcoin saat ini, kontrak pintar terbatas pada tindakan mengunci dan membuka kunci bitcoin dengan Bitcoin Script. Perjanjian bertujuan untuk meningkatkan fungsionalitas kontrak pintar Bitcoin dengan memungkinkan pengguna mengontrol bagaimana dana mereka dibelanjakan dalam transaksi di masa depan.
Dengan mengaktifkan Script untuk menafsirkan data transaksi, kami secara efektif menciptakan cara agar data tersebut digunakan dalam logika kontrak.
Ini hanyalah beberapa opcode introspeksi yang lebih menarik untuk fungsionalitas perjanjian:
OP_TXHASH: Menyediakan hash dari input (atau output) transaksi, dan memberi Script kemampuan untuk memverifikasi dan menerapkan kondisi berdasarkan data transaksi.
OP_CSFS + OP_CAT: Keduanya memungkinkan skrip untuk memeriksa tanda tangan terhadap data apa pun, bukan hanya transaksi itu sendiri. Ini berarti Script dapat memverifikasi kondisi berdasarkan data transaksi atau informasi eksternal, memperluas kemungkinan validasi dalam skrip Bitcoin.
Kedua opcode ini sengaja dibuat luas, memungkinkan proses validasi yang kompleks dan kemampuan introspeksi. Perjanjian lainnya memiliki cakupan yang lebih sempit dan dirancang sebagai bentuk perjanjian yang lebih terbatas.
OP_CHECKTEMPLATEVERIFY (CTV): Memungkinkan output transaksi untuk menyematkan template transaksi pembelanjaan di masa depan, memungkinkan perjanjian dengan cara yang lebih terbatas.
OP_VAULT: Mengaktifkan bentuk perjanjian khusus yang digunakan untuk “vaulting”, yang memungkinkan pengguna menentukan tujuan transaksi tetapi tidak benar-benar memindahkan koin kecuali setelah penundaan.
Lalu ada OP_CAT sendiri, yang bukan merupakan opcode introspeksi secara langsung…
OP_CAT: Memungkinkan Script untuk menggabungkan dua elemen pada tumpukan, yang berguna untuk menggabungkan potongan informasi yang berbeda dalam sebuah skrip.
OP_CAT sepertinya tidak memiliki kemampuan introspeksi, jadi apa yang terjadi di sini?
OP_CAT: Mengungkap Semua Kemungkinan
Introspeksi Transaksi
Pada tahun 2021, Andrew Poelstra menulis tentang trik introspeksi OP_CAT dalam postingan blognya. Dia memberikan contoh spesifik namun menganggap pembaca memiliki pengetahuan sebelumnya tentang teknik serupa. Di sini, saya akan menyederhanakan penjelasan itu untuk pemahaman yang lebih baik.
Dalam Bitcoin Script, hanya ada tiga opcode utama yang memungkinkan Anda melakukan introspeksi data transaksi: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, dan CHECKSIG. Selain itu, ada varian seperti CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG, dan CHECKMULTISIGVERIFY, yang pada dasarnya merupakan variasi kecil dari CHECKSIG. Dua yang pertama hanya memungkinkan Anda melihat apakah pemeriksaan telah diverifikasi, memberikan fungsionalitas yang cukup sempit. CHECKSIG serupa, tetapi perbedaannya di sini adalah memungkinkan Anda mengambil tanda tangan dan kunci publik di tumpukan. Menarik.
Secara tradisional, kita menganggap penggabungan sebagai fungsi yang menggabungkan dua item, namun kita juga dapat menggunakannya untuk memisahkan atau membagi suatu item, dalam hal ini—tanda tangan menjadi pasangan (r, s).
Bagaimana cara kita memperoleh fungsionalitas OP_SPLIT dari OP_CAT?
“Jika Anda memiliki benda besar, Anda dapat membaginya menjadi dua dengan meminta pengguna meluangkan waktu untuk menyediakan kedua benda tersebut. Anda CAT mereka bersama-sama dan pada dasarnya memeriksa kesetaraan. Anda selalu dapat membalikkan setiap operasi dengan cara ini. Dengan CAT saja Anda dapat memecah tanda tangan.” — Andrew Poelstra, TABConf 2021
Apa yang terjadi disini?
Dengan mengharuskan pengguna untuk memberikan tanda tangan, kunci publik, dan transaksi, Anda dapat membagi tanda tangan menjadi beberapa bagian komponennya, kemudian memeriksa setiap bagian secara independen terhadap data transaksi. Teknik ini dapat dilihat sebagai bentuk pemisahan atau penggabungan, karena teknik ini memvalidasi bahwa tanda tangan dan kunci publik memang merupakan komponen dari transaksi yang valid.
Bagaimana semua ini membuat kita introspeksi?
“Di Taproot di mana kami memiliki tanda tangan Schnorr menggunakan OP_CAT dan opcode verifikasi tanda tangan Schnorr, ternyata dimungkinkan untuk mendapatkan bentuk perjanjian non-rekursif di mana Anda benar-benar mendapatkan hash transaksi. Bahkan tidak seperti hash transaksi lucu yang rusak, tetapi hash SHA2 literal dari semua data transaksi ke dalam tumpukan.” — Andrew Poelstra, TABConf 2021
Poelstra selanjutnya mendemonstrasikan bagaimana Anda bisa mendapatkan hash SHA2 untuk input atau output transaksi yang tersisa di tumpukan. Kita akan melewatkan perhitungan bulan di sini, namun implikasinya adalah dengan OP_CAT kita dapat membatasi bagian transaksi sebagai persyaratan skrip pembuka kunci. Kita dapat membatasi alamat pengiriman atau nilai yang dikirim dari transaksi tersebut, dimana hash transaksi berfungsi sebagai kunci untuk membukanya.
brankas
Menggunakan teknik yang sama memberi kita introspeksi transaksi dan dengan cepat memberi kita versi dasar brankas. Mengikuti logika yang diuraikan dalam blog Poelstra, seorang pengembang bernama Rijndael membuktikan bahwa kita dapat melakukan ini hanya dengan OP_CAT dalam implementasi Purrfect Vaults.
“Membangun kembali TXID di tumpukan untuk mengintrospeksi transaksi sebelumnya sebenarnya lebih mudah dari yang saya harapkan.” — Rijndael
Dengan brankas, pengguna menentukan alamat berikutnya yang harus dituju oleh dana mereka, menyediakan mekanisme pemulihan dana jika terjadi kebocoran kunci, dan mengurangi insentif untuk pencurian kunci pribadi.
Pohon Merkle untuk Naskah
Di Bitcoin saat ini, Merkle Trees adalah struktur data yang digunakan untuk verifikasi data, sinkronisasi, dan kurang lebih 'merangkai' transaksi dan blok blockchain menjadi satu. Opcode OP_CAT, yang memungkinkan penggabungan dua variabel tumpukan, bila digunakan bersama hash kunci publik SHA256, memfasilitasi proses verifikasi pohon Merkle yang mudah untuk skrip. Pendekatan ini, yang awalnya diusulkan oleh Pieter Wuille pada tahun 2015, berhasil diterapkan di jaringan Liquid.
Bayangkan sebuah struktur pohon yang penuh dengan berbagai kondisi pengeluaran, seperti hash preimages, timelocks, dan public key, yang dikenal sebagai tanda tangan pohon.
Tanda Tangan Pohon
OP_CAT memungkinkan pembuatan Tanda Tangan Pohon yang:
“…Menyediakan skrip multitanda tangan yang ukurannya dapat berupa logaritmik jumlah kunci publik dan dapat mengkodekan kondisi pembelanjaan melebihi n-of-m. Misalnya, transaksi berukuran kurang dari 1 KB dapat mendukung tanda tangan pohon dengan seribu kunci publik. Hal ini juga memungkinkan kondisi pembelanjaan logis yang umum.” — Penulis BIP Ethan Heilman, di milis bitcoin-dev
Hal ini akan memungkinkan validasi konten apa pun yang di-hash di dalam pohon, menjaga integritas dan kepercayaan data tanpa menambahkan jumlah besar atau pembengkakan yang tidak perlu ke blockchain.
Apa yang menarik dari semua ini?
Perjanjian Rekursif
Jika Anda memiliki kemampuan untuk memeriksa suatu transaksi dan menerapkan batasan pada bagian tertentu dari transaksi tersebut, Anda dapat mengatur kondisi yang terbawa melalui beberapa transaksi, yang secara efektif menciptakan rantai pembatasan yang berkelanjutan. Konsep ini disebut perjanjian rekursif. OP_CAT adalah proposal unik karena memberikan kita begitu banyak kekuatan hanya untuk 10 baris kode baru. Ia memiliki kemampuan untuk mengatasi ketiga keterbatasan awal yang kami bahas di awal postingan: visibilitas data transaksi, fungsionalitas matematika yang lebih baik, dan model eksekusi liniernya.
Meskipun OP_CAT mungkin tampak mudah pada awalnya, hal ini akan membuka potensi yang signifikan jika dimanfaatkan secara kreatif. Ini berfungsi sebagai landasan untuk lebih banyak fungsi yang melampaui cakupan diskusi ini, seperti Post-Quantum Lamport Signatures.
Apakah Ini Aman?
Sebelum OP_CAT awalnya dihapus, ketika dikombinasikan dengan OP_DUP (duplikat), dan digunakan berulang-ulang untuk menduplikasi nilai awalnya 1-byte pada tumpukan, penggunaan memori dapat meledak. Ini bisa saja digunakan sebagai serangan penolakan layanan (DoS) sebagai akibat dari peningkatan konsumsi memori. Proposal baru ini dengan mudah mencegah serangan ini dengan menerapkan batas 520 byte pada elemen tumpukan.
Apakah ada bahaya kontrak berjalan selamanya?
Jika yang kami maksud adalah, apakah OP_CAT mengubah model eksekusi Skrip sehingga tidak lagi membatasi penggunaan sumber dayanya secara statis (sebagai fungsi linier dari ukuran Skrip)? TIDAK.
Akankah perjanjian menciptakan pasar untuk koin lain selain Bitcoin?
Jika Anda memiliki perjanjian rekursif, ya, Anda secara teknis dapat membangun aplikasi lapisan-2 yang kompleks, termasuk NFT, pertukaran terdesentralisasi, dan kucing kuantum. Namun, melakukan hal tersebut bukanlah hal yang sepele. Sulit melihat pasar yang serius melakukan hal tersebut.
Bisakah Anda “menodai” koin secara permanen dengan menggunakan CAT?
Dalam kasus koin berwarna dan NFT, dengan mengeluarkan aset ini, pengguna secara efektif 'membakar' satoshi, menandainya dengan cara yang menandakan kepemilikan aset 'lapisan-2'. Proses ini dikenal sebagai koin ‘pencemaran’. Namun hanya pemilik koin yang dapat menandai koinnya, dan dompet Bitcoin tidak akan mengenalinya lagi (kecuali pembuatnya secara eksplisit menambahkan kode untuk mengaktifkannya). Koin yang dihasilkan tidak akan diterima oleh dompet bitcoin. Mungkin mereka akan diterima oleh dompet cryptocat atau semacamnya, tapi ini tidak relevan bagi sebagian besar pengguna bitcoin.
Apakah ini akan menimbulkan masalah MEV pada Bitcoin?
Perbedaan utama antara Bitcoin dan Ethereum adalah visibilitas transaksi. Tidak seperti Ethereum, tidak semua aspek kontrak bersifat transparan, artinya penambang Bitcoin tidak memiliki kemampuan yang sama untuk melihat status kontrak internal dan menjalankannya di awal.
Kekhawatiran utama OP_CAT oleh para Bitcoiner yang berpikiran ekonomis adalah potensi Miner Extractable Value (MEV). Seperti yang telah dibahas lebih luas pada postingan saya sebelumnya tentang subjek ini. Banyak pengguna khawatir bahwa jika kita membuat kontrak lapisan-2 secara teknis memungkinkan, MEV tidak dapat dihindari. Tapi apakah ini benar? Secara khusus, apakah kelayakan teknis koin lapisan-2 pada Bitcoin menyiratkan penciptaan dan adopsi yang tidak bisa dihindari?
Anda dapat membayangkan membuat kontrak swap sederhana atau NFT yang relatif tidak efisien, tetapi membangun sesuatu yang rumit seperti DEX dengan pembuat pasar otomatis tampaknya sangat tidak mungkin dan belum pernah kita lihat di Liquid meskipun terdapat 'kemungkinan teknis' untuk hal tersebut.
Jadi apakah OP_CAT benar-benar sempurna?
Hampir tidak, jauh dari itu. Beberapa orang ingin melihat perjanjian rekursif, sementara yang lain tidak ingin melihat Bitcoin berubah sama sekali.
Sebuah faksi Bitcoiner, “ossificationists”, menganjurkan untuk melestarikan Bitcoin dalam kondisi saat ini dan memandang setiap peningkatan protokol dengan skeptis. Mereka khususnya khawatir bahwa perubahan signifikan, seperti pemberlakuan perjanjian, dapat melemahkan desentralisasi jaringan. Argumen mereka bertumpu pada keyakinan bahwa yang terbaik adalah tetap berpegang pada visi awal Bitcoin. Ironisnya, OP_CAT pada awalnya merupakan bagian dari Bitcoin, memicu argumen tandingan. Beberapa orang percaya bahwa mengembalikan OP_CAT sebenarnya dapat menyelaraskan kembali Bitcoin dengan visi awal Satoshi.
Jika Anda ingin melihat beberapa fitur keamanan yang dimungkinkan oleh perjanjian rekursif, OP_CAT akan bagus, tapi jelas tidak sebagus bahasa skrip Lisp-esque yang lengkap. Masalahnya adalah ini akan menjadi perubahan besar pada Bitcoin, dan kemungkinan besar hal ini tidak akan terjadi dalam waktu dekat.
Atau mungkin, Anda berada di sisi lain, dan Anda lebih menyukai kesederhanaan non-rekursif seperti OP_CTV atau OP_VAULT. Perjanjian non-rekursif lebih sederhana dan mudah untuk dipertimbangkan, tanpa risiko menciptakan rantai kendala yang tidak terkendali.
Bagaimana jika beberapa versi perjanjian rekursif tidak bisa dihindari?
Selama bertahun-tahun, pengembang telah memperhatikan bahwa hampir semua perluasan logika validasi transaksi dapat digunakan untuk meniru fungsionalitas OP_CAT.
Di alam semesta Script, ada dua ranah, berdasarkan ukuran elemen tumpukan. Untuk elemen tumpukan yang lebih besar dari 4 byte, Anda dapat membandingkan kesetaraan, menafsirkannya sebagai kunci sebagai tanda tangan, atau melakukan hash. Untuk elemen tumpukan yang kurang dari atau sama dengan 4 byte, Anda dapat memperlakukannya sebagai objek untuk melakukan aritmatika atau percabangan. Dengan prosesor RISC-V yang berjalan pada BitVM, Anda dapat melakukan apa saja. Apa pun yang memungkinkan Anda meniru OP_CAT, memecah elemen tumpukan, atau menggabungkannya akan menyatukan kedua bidang ini, sehingga Anda dapat 'melakukan apa saja' dengan Script.
Peneliti seperti Andrew Poelstra berharap kita dapat melakukan perjanjian rekursif dengan hampir semua opcode baru. Jika benar, maka hal tersebut akan menjadi pembenaran untuk mengupayakan cara untuk melakukannya dengan baik.
Apakah OP_CAT merupakan jalur maju bagi perjanjian?
Jika perjanjian tidak hanya menarik, tetapi juga tidak dapat dihindari, bagaimana kita memastikan perjanjian tersebut diterapkan sedemikian rupa sehingga membuat lebih banyak pengguna Bitcoin mengirim tanpa kepercayaan seperti yang awalnya dibayangkan Satoshi? Walaupun penganut paham osifikasi masih terpecah, OP_CAT tetap menjadi pesaing kuat dalam perdebatan perjanjian.
OP_CAT bukanlah pahat yang paling elegan, namun merupakan pahat dengan rasio kekuatan terhadap kompleksitas terbaik, yang memungkinkan pengembang membuat beberapa fitur baru yang menakjubkan.
Ini adalah postingan tamu oleh Kiara Bickers. Pendapat yang dikemukakan sepenuhnya merupakan pendapat mereka sendiri dan tidak mencerminkan pendapat BTC Inc atau Majalah Bitcoin.
Sumber: Majalah Bitcoin
Pos OP_CAT: Solusi Sempurna untuk Perjanjian? muncul pertama kali di Crypto Breaking News.
