Baru-baru ini, komunitas Bitcoin memicu diskusi tentang menghidupkan kembali opcode seperti OP_CAT. Taproot Wizard menarik perhatian banyak orang dengan meluncurkan Quantum Cats NFT dan mengklaim mendapatkan nomor BIP-420. Para pendukung menyatakan bahwa mengaktifkan OP_CAT dapat mewujudkan "ketentuan pembatas", sehingga memungkinkan kontrak pintar atau Programmabilitas Bitcoin.
Jika Anda memperhatikan istilah "ketentuan pembatasan" dan melakukan sedikit pencarian, Anda akan menemukan bahwa ini adalah lubang kelinci besar lainnya. Para pengembang telah mendiskusikannya selama bertahun-tahun, selain OP_CAT, ada juga OP_CTV, APO, OP_VAULT dan teknologi lainnya untuk menerapkan ketentuan pembatasan.
Jadi, apa sebenarnya "ketentuan pembatasan" dari Bitcoin? Mengapa hal ini dapat menarik begitu banyak perhatian dan diskusi dari para pengembang selama bertahun-tahun? Keterprogramabilitas apa yang dapat dicapai oleh Bitcoin? Apa prinsip desain di baliknya? Artikel ini mencoba memberikan gambaran dan diskusi.
Apa itu "ketentuan pembatasan"
Ketentuan Pembatasan ( Covenant ) adalah mekanisme yang dapat menetapkan syarat untuk transaksi Bitcoin di masa depan.
Saat ini, skrip Bitcoin juga mencakup kondisi yang membatasi, seperti harus memasukkan tanda tangan yang sah saat mengeluarkan, dan memasukkan skrip yang sesuai, dll. Namun, selama pengguna dapat membuka kunci, mereka dapat menggunakan UTXO tersebut ke mana pun mereka inginkan.
Dan ketentuan batasan adalah, di atas dasar batasan bagaimana cara membuka kunci ini, menetapkan lebih banyak batasan, seperti membatasi pengeluaran setelah UTXO, yaitu untuk mencapai efek mirip "dana khusus untuk tujuan khusus"; atau kondisi input lain yang dimasukkan dalam satu transaksi, dll.
Lebih tepatnya, skrip Bitcoin saat ini juga memiliki beberapa ketentuan pembatas, seperti kunci waktu berbasis opcode, yang diimplementasikan melalui bidang nLock atau nSequence dari transaksi introspeksi untuk membatasi waktu sebelum pengeluaran transaksi, tetapi juga pada dasarnya terbatas pada pembatasan waktu.
Jadi, mengapa pengembang dan peneliti harus merancang pemeriksaan batas ini? Karena ketentuan batas bukan hanya untuk membatasi, tetapi juga untuk menetapkan aturan pelaksanaan transaksi. Dengan cara ini, pengguna hanya dapat melaksanakan transaksi sesuai dengan aturan yang telah ditetapkan sebelumnya, sehingga menyelesaikan proses bisnis yang direncanakan.
Jadi agak kontra intuitif, ini bisa membuka lebih banyak skenario aplikasi.
Skenario Aplikasi
Pastikan hukuman Staking
Contoh paling intuitif dari ketentuan pembatasan adalah transaksi slash Babylon dalam proses staking Bitcoin.
Proses staking Bitcoin Babylon adalah pengguna mengirimkan aset BTC mereka ke dalam skrip khusus di mainnet, dengan syarat pengeluaran termasuk dua jenis:
Dalam keadaan normal: Setelah waktu tertentu, pengguna dapat membuka kunci dengan tanda tangannya sendiri, yaitu menyelesaikan proses unstake.
Situasi abnormal: Jika pengguna melakukan tindakan jahat seperti double signing di suatu blockchain PoS yang disewakan oleh Babylon, maka melalui EOTS(extractable one-time signatures, tanda tangan sekali pakai yang dapat diekstrak), bagian aset ini dapat dibuka, dan oleh peran eksekusi di jaringan, sebagian aset akan secara paksa dikirim ke alamat pembakaran(slash).
Perhatikan di sini "pengiriman paksa", ini berarti meskipun UTXO ini dapat dibuka kuncinya, tetapi aset tersebut tidak dapat dikirim sembarangan ke tempat lain, hanya dapat dibakar. Dengan cara ini, dapat dipastikan bahwa pengguna yang berbuat jahat tidak dapat lebih dulu menggunakan tanda tangan yang sudah mereka ketahui untuk mengalihkan aset kembali kepada diri mereka sendiri, untuk menghindari hukuman.
Fitur ini, jika diimplementasikan setelah syarat-syarat seperti OP_CTV, dapat menambahkan opcode seperti OP_CTV dalam cabang "situasi luar biasa" dari skrip staking untuk menerapkan batasan.
Namun, sebelum OP_CTV diaktifkan, Babylon perlu menggunakan metode alternatif yang dieksekusi bersama oleh pengguna + komite untuk mensimulasikan efek penegakan ketentuan batasan.
Pengendalian Kemacetan
Secara umum, kemacetan merujuk pada ketika tarif biaya transaksi di jaringan Bitcoin sangat tinggi, dan ada banyak transaksi yang terakumulasi di dalam kolam transaksi menunggu untuk dibundel. Jadi, jika pengguna ingin memastikan transaksi dengan cepat, mereka perlu meningkatkan biaya transaksi.
Dan pada saat ini, jika seorang pengguna harus mengirim beberapa transaksi ke beberapa penerima, ia harus meningkatkan biaya transaksi, menanggung biaya yang relatif tinggi. Pada saat yang sama, ini juga akan meningkatkan tingkat biaya transaksi di seluruh jaringan.
Jika ada syarat pembatasan, salah satu solusinya adalah pengirim dapat terlebih dahulu berkomitmen pada transaksi pengiriman massal. Komitmen ini dapat membuat semua penerima percaya bahwa transaksi akhir akan dilakukan, dan mereka dapat menunggu sampai tarif biaya rendah sebelum mengirimkan transaksi spesifik.
Ketika permintaan untuk ruang blok sangat tinggi, melakukan transaksi menjadi sangat mahal. Dengan menggunakan OP_CHECKTEMPLATEVERIFY, penyedia layanan pembayaran dalam jumlah besar dapat mengumpulkan semua pembayaran mereka ke dalam satu transaksi O(1) untuk konfirmasi. Kemudian, setelah beberapa waktu, ketika permintaan untuk ruang blok berkurang, pembayaran dapat diperluas dari UTXO tersebut.
Skenario ini adalah salah satu contoh aplikasi yang cukup khas dari ketentuan batasan OP_CTV.
Gudang
Vault ( adalah salah satu skenario aplikasi yang banyak dibicarakan dalam aplikasi Bitcoin, terutama dalam bidang syarat pembatasan. Karena operasi sehari-hari tidak bisa dihindari untuk menyeimbangkan antara pengelolaan dana dan kebutuhan penggunaan dana, orang berharap ada jenis aplikasi vault yang dapat menjamin keamanan dana, bahkan jika akun diretas ) dan kunci privat ( bocor, tetap dapat membatasi penggunaan dana.
Berdasarkan teknologi yang mewujudkan ketentuan pembatasan, aplikasi jenis penyimpanan dapat dibangun dengan cukup mudah.
Sebagai contoh dari desain OP_VAULT: saat menggunakan dana dalam vault, perlu mengirimkan transaksi ke blockchain terlebih dahulu. Transaksi ini menunjukkan niat untuk menggunakan vault, yaitu "trigger", dan menetapkan kondisi di dalamnya:
Jika semuanya berjalan dengan baik, maka transaksi kedua adalah transaksi penarikan akhir. Setelah menunggu N blok, dana dapat digunakan lebih lanjut ke mana saja.
Jika ditemukan bahwa transaksi ini adalah ) yang dicuri atau ( yang dipaksa melalui "serangan kunci inggris", sebelum transaksi penarikan di N blok dikirim, dapat segera dikirim ke alamat aman lainnya untuk penyimpanan yang lebih aman bagi pengguna ).
Perlu dicatat bahwa, tanpa ketentuan pembatas, aplikasi dompet dapat dibangun. Salah satu cara yang mungkin adalah dengan menyiapkan tanda tangan untuk pengeluaran di masa depan menggunakan kunci pribadi, dan kemudian menghancurkan kunci pribadi tersebut. Namun, masih ada banyak batasan, misalnya perlu memastikan bahwa kunci pribadi tersebut telah dihancurkan ( mirip dengan proses trusted setup dalam bukti nol pengetahuan ), jumlah dan biaya harus ditentukan sebelumnya ( karena perlu pra-tanda tangan ) sehingga kurang fleksibel, dan lain-lain.
( saluran status yang lebih kuat dan fleksibel
Umumnya dapat dianggap bahwa saluran status, termasuk jaringan Lightning, memiliki tingkat keamanan yang hampir setara dengan rantai utama ) selama node dapat mengamati status terbaru dan dapat mempublikasikan status terbaru secara normal ke rantai ###. Namun, setelah adanya ketentuan pembatas, beberapa ide desain saluran status baru dapat menjadi lebih kuat atau fleksibel di atas jaringan Lightning. Di antara yang lebih terkenal adalah Eltoo, Ark, dan lain-lain.
Eltoo ( juga dikenal sebagai LN-Symmetry) adalah salah satu contoh yang cukup khas. Solusi teknologi ini mengambil homofon dari "L2", menawarkan sebuah lapisan eksekusi untuk jaringan Lightning, yang memungkinkan status saluran yang lebih baru untuk menggantikan status sebelumnya tanpa memerlukan mekanisme hukuman, sehingga juga dapat menghindari kebutuhan untuk menyimpan beberapa status sebelumnya untuk mencegah penipuan oleh lawan, seperti pada node jaringan Lightning. Untuk mencapai efek di atas, Eltoo memperkenalkan metode tanda tangan SIGHASH_NOINPUT, yaitu APO(BIP-118).
Ark bertujuan untuk mengurangi kesulitan dalam likuiditas masuk jaringan Lightning dan manajemen saluran. Ini adalah protokol dalam bentuk joinpool, di mana beberapa pengguna dapat menerima satu penyedia layanan sebagai lawan transaksi dalam waktu tertentu, melakukan transaksi virtual UTXO(vUTXO) di luar rantai, tetapi berbagi satu UTXO di dalam rantai untuk mengurangi biaya. Mirip dengan vault, Ark juga dapat diimplementasikan di jaringan Bitcoin saat ini; tetapi setelah pengenalan ketentuan pembatasan, Ark dapat mengurangi jumlah interaksi yang diperlukan berdasarkan template transaksi, mewujudkan keluarnya sepihak yang lebih terdesentralisasi.
Ikhtisar Teknologi Syarat Pembatasan
Dari aplikasi di atas, dapat dilihat bahwa syarat pembatas lebih mirip dengan efek daripada suatu teknologi, oleh karena itu ada banyak cara teknis untuk mewujudkannya. Jika dilakukan pengelompokan, dapat mencakup:
Tipe: Umum, Khusus
Cara implementasi: berbasis Opcode, berbasis tanda tangan
Rekursif: rekursif, non-rekursif
Dan di antaranya, rekursi mengacu pada: adanya implementasi beberapa ketentuan pembatas, yang juga dapat membatasi keluaran berikutnya dengan membatasi keluaran yang lebih lanjut, dapat mewujudkan pembatasan yang ditambahkan dapat melampaui satu transaksi, mencapai kedalaman transaksi yang lebih tinggi.
Beberapa desain ketentuan batasan utama meliputi:
OP_CTV: Tipe Umum, berdasarkan Opcode, non-rekursif
OP_VAULT: jenis khusus, berdasarkan Opcode, non-rekursif
APO: Tipe umum, berbasis tanda tangan, non-rekursif
OP_CAT: Tipe Umum, berdasarkan Opcode, rekursif*
OP_CSFS: Tipe Umum, Berdasarkan Tanda Tangan, Rekursif
*jika menggabungkan OP_CAT
Desain Ketentuan Pembatasan
Dari penjelasan sebelumnya, dapat dilihat bahwa skrip Bitcoin saat ini terutama membatasi syarat untuk membuka kunci, tetapi tidak membatasi bagaimana UTXO ini dapat digunakan lebih lanjut. Untuk mewujudkan syarat pembatasan, kita perlu berpikir sebaliknya: mengapa skrip Bitcoin saat ini tidak dapat mewujudkan syarat pembatasan?
Alasan utamanya adalah bahwa saat ini skrip Bitcoin tidak dapat membaca konten transaksi itu sendiri, yaitu "introspeksi" (.
Jika kita dapat mewujudkan introspeksi transaksi—memeriksa apa pun dari transaksi ) termasuk output (, maka syarat pembatas dapat direalisasikan.
Oleh karena itu, pemikiran desain ketentuan pembatasan juga terutama berfokus pada bagaimana mewujudkan introspeksi.
Ide yang paling sederhana dan langsung adalah, menambahkan satu atau lebih kode operasi ( yaitu satu kode operasi + berbagai parameter, atau beberapa kode operasi ) dengan fungsi berbeda, langsung membaca isi transaksi. Ini juga merupakan pemikiran berbasis kode operasi.
Sementara itu, pemikiran lain adalah, tidak perlu membaca dan memeriksa isi transaksi itu sendiri secara langsung dalam skrip, tetapi dapat memanfaatkan hash dari isi transaksi—jika hash ini sudah ditandatangani, maka cukup dengan memodifikasi dalam skrip seperti OP_CHECKSIG dan lain-lain untuk melakukan pemeriksaan tanda tangan ini, sehingga dapat secara tidak langsung mewujudkan introspeksi transaksi dan membatasi ketentuan. Pemikiran ini didasarkan pada cara desain tanda tangan. Ini terutama mencakup APO dan OP_CSFS.
APO
SIGHASH_ANYPREVOUT(APO) adalah metode tanda tangan Bitcoin yang diusulkan. Cara paling sederhana untuk menandatangani adalah dengan berkomitmen pada semua input dan output transaksi, tetapi Bitcoin juga memiliki cara yang lebih fleksibel, yaitu SIGHASH, yang secara selektif berkomitmen pada input atau output dalam suatu transaksi.
dan SIGHASH APO hanya menandatangani output, bukan bagian input. Ini berarti bahwa transaksi yang ditandatangani dengan cara APO dapat dilakukan di
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Penjelasan tentang ketentuan pembatasan Bitcoin: Memulai era baru Programmabilitas
Penjelasan Ketentuan Pembatasan: Mewujudkan Programmabilitas Bitcoin
Baru-baru ini, komunitas Bitcoin memicu diskusi tentang menghidupkan kembali opcode seperti OP_CAT. Taproot Wizard menarik perhatian banyak orang dengan meluncurkan Quantum Cats NFT dan mengklaim mendapatkan nomor BIP-420. Para pendukung menyatakan bahwa mengaktifkan OP_CAT dapat mewujudkan "ketentuan pembatas", sehingga memungkinkan kontrak pintar atau Programmabilitas Bitcoin.
Jika Anda memperhatikan istilah "ketentuan pembatasan" dan melakukan sedikit pencarian, Anda akan menemukan bahwa ini adalah lubang kelinci besar lainnya. Para pengembang telah mendiskusikannya selama bertahun-tahun, selain OP_CAT, ada juga OP_CTV, APO, OP_VAULT dan teknologi lainnya untuk menerapkan ketentuan pembatasan.
Jadi, apa sebenarnya "ketentuan pembatasan" dari Bitcoin? Mengapa hal ini dapat menarik begitu banyak perhatian dan diskusi dari para pengembang selama bertahun-tahun? Keterprogramabilitas apa yang dapat dicapai oleh Bitcoin? Apa prinsip desain di baliknya? Artikel ini mencoba memberikan gambaran dan diskusi.
Apa itu "ketentuan pembatasan"
Ketentuan Pembatasan ( Covenant ) adalah mekanisme yang dapat menetapkan syarat untuk transaksi Bitcoin di masa depan.
Saat ini, skrip Bitcoin juga mencakup kondisi yang membatasi, seperti harus memasukkan tanda tangan yang sah saat mengeluarkan, dan memasukkan skrip yang sesuai, dll. Namun, selama pengguna dapat membuka kunci, mereka dapat menggunakan UTXO tersebut ke mana pun mereka inginkan.
Dan ketentuan batasan adalah, di atas dasar batasan bagaimana cara membuka kunci ini, menetapkan lebih banyak batasan, seperti membatasi pengeluaran setelah UTXO, yaitu untuk mencapai efek mirip "dana khusus untuk tujuan khusus"; atau kondisi input lain yang dimasukkan dalam satu transaksi, dll.
Lebih tepatnya, skrip Bitcoin saat ini juga memiliki beberapa ketentuan pembatas, seperti kunci waktu berbasis opcode, yang diimplementasikan melalui bidang nLock atau nSequence dari transaksi introspeksi untuk membatasi waktu sebelum pengeluaran transaksi, tetapi juga pada dasarnya terbatas pada pembatasan waktu.
Jadi, mengapa pengembang dan peneliti harus merancang pemeriksaan batas ini? Karena ketentuan batas bukan hanya untuk membatasi, tetapi juga untuk menetapkan aturan pelaksanaan transaksi. Dengan cara ini, pengguna hanya dapat melaksanakan transaksi sesuai dengan aturan yang telah ditetapkan sebelumnya, sehingga menyelesaikan proses bisnis yang direncanakan.
Jadi agak kontra intuitif, ini bisa membuka lebih banyak skenario aplikasi.
Skenario Aplikasi
Pastikan hukuman Staking
Contoh paling intuitif dari ketentuan pembatasan adalah transaksi slash Babylon dalam proses staking Bitcoin.
Proses staking Bitcoin Babylon adalah pengguna mengirimkan aset BTC mereka ke dalam skrip khusus di mainnet, dengan syarat pengeluaran termasuk dua jenis:
Perhatikan di sini "pengiriman paksa", ini berarti meskipun UTXO ini dapat dibuka kuncinya, tetapi aset tersebut tidak dapat dikirim sembarangan ke tempat lain, hanya dapat dibakar. Dengan cara ini, dapat dipastikan bahwa pengguna yang berbuat jahat tidak dapat lebih dulu menggunakan tanda tangan yang sudah mereka ketahui untuk mengalihkan aset kembali kepada diri mereka sendiri, untuk menghindari hukuman.
Fitur ini, jika diimplementasikan setelah syarat-syarat seperti OP_CTV, dapat menambahkan opcode seperti OP_CTV dalam cabang "situasi luar biasa" dari skrip staking untuk menerapkan batasan.
Namun, sebelum OP_CTV diaktifkan, Babylon perlu menggunakan metode alternatif yang dieksekusi bersama oleh pengguna + komite untuk mensimulasikan efek penegakan ketentuan batasan.
Pengendalian Kemacetan
Secara umum, kemacetan merujuk pada ketika tarif biaya transaksi di jaringan Bitcoin sangat tinggi, dan ada banyak transaksi yang terakumulasi di dalam kolam transaksi menunggu untuk dibundel. Jadi, jika pengguna ingin memastikan transaksi dengan cepat, mereka perlu meningkatkan biaya transaksi.
Dan pada saat ini, jika seorang pengguna harus mengirim beberapa transaksi ke beberapa penerima, ia harus meningkatkan biaya transaksi, menanggung biaya yang relatif tinggi. Pada saat yang sama, ini juga akan meningkatkan tingkat biaya transaksi di seluruh jaringan.
Jika ada syarat pembatasan, salah satu solusinya adalah pengirim dapat terlebih dahulu berkomitmen pada transaksi pengiriman massal. Komitmen ini dapat membuat semua penerima percaya bahwa transaksi akhir akan dilakukan, dan mereka dapat menunggu sampai tarif biaya rendah sebelum mengirimkan transaksi spesifik.
Ketika permintaan untuk ruang blok sangat tinggi, melakukan transaksi menjadi sangat mahal. Dengan menggunakan OP_CHECKTEMPLATEVERIFY, penyedia layanan pembayaran dalam jumlah besar dapat mengumpulkan semua pembayaran mereka ke dalam satu transaksi O(1) untuk konfirmasi. Kemudian, setelah beberapa waktu, ketika permintaan untuk ruang blok berkurang, pembayaran dapat diperluas dari UTXO tersebut.
Skenario ini adalah salah satu contoh aplikasi yang cukup khas dari ketentuan batasan OP_CTV.
Gudang
Vault ( adalah salah satu skenario aplikasi yang banyak dibicarakan dalam aplikasi Bitcoin, terutama dalam bidang syarat pembatasan. Karena operasi sehari-hari tidak bisa dihindari untuk menyeimbangkan antara pengelolaan dana dan kebutuhan penggunaan dana, orang berharap ada jenis aplikasi vault yang dapat menjamin keamanan dana, bahkan jika akun diretas ) dan kunci privat ( bocor, tetap dapat membatasi penggunaan dana.
Berdasarkan teknologi yang mewujudkan ketentuan pembatasan, aplikasi jenis penyimpanan dapat dibangun dengan cukup mudah.
Sebagai contoh dari desain OP_VAULT: saat menggunakan dana dalam vault, perlu mengirimkan transaksi ke blockchain terlebih dahulu. Transaksi ini menunjukkan niat untuk menggunakan vault, yaitu "trigger", dan menetapkan kondisi di dalamnya:
Perlu dicatat bahwa, tanpa ketentuan pembatas, aplikasi dompet dapat dibangun. Salah satu cara yang mungkin adalah dengan menyiapkan tanda tangan untuk pengeluaran di masa depan menggunakan kunci pribadi, dan kemudian menghancurkan kunci pribadi tersebut. Namun, masih ada banyak batasan, misalnya perlu memastikan bahwa kunci pribadi tersebut telah dihancurkan ( mirip dengan proses trusted setup dalam bukti nol pengetahuan ), jumlah dan biaya harus ditentukan sebelumnya ( karena perlu pra-tanda tangan ) sehingga kurang fleksibel, dan lain-lain.
( saluran status yang lebih kuat dan fleksibel
Umumnya dapat dianggap bahwa saluran status, termasuk jaringan Lightning, memiliki tingkat keamanan yang hampir setara dengan rantai utama ) selama node dapat mengamati status terbaru dan dapat mempublikasikan status terbaru secara normal ke rantai ###. Namun, setelah adanya ketentuan pembatas, beberapa ide desain saluran status baru dapat menjadi lebih kuat atau fleksibel di atas jaringan Lightning. Di antara yang lebih terkenal adalah Eltoo, Ark, dan lain-lain.
Eltoo ( juga dikenal sebagai LN-Symmetry) adalah salah satu contoh yang cukup khas. Solusi teknologi ini mengambil homofon dari "L2", menawarkan sebuah lapisan eksekusi untuk jaringan Lightning, yang memungkinkan status saluran yang lebih baru untuk menggantikan status sebelumnya tanpa memerlukan mekanisme hukuman, sehingga juga dapat menghindari kebutuhan untuk menyimpan beberapa status sebelumnya untuk mencegah penipuan oleh lawan, seperti pada node jaringan Lightning. Untuk mencapai efek di atas, Eltoo memperkenalkan metode tanda tangan SIGHASH_NOINPUT, yaitu APO(BIP-118).
Ark bertujuan untuk mengurangi kesulitan dalam likuiditas masuk jaringan Lightning dan manajemen saluran. Ini adalah protokol dalam bentuk joinpool, di mana beberapa pengguna dapat menerima satu penyedia layanan sebagai lawan transaksi dalam waktu tertentu, melakukan transaksi virtual UTXO(vUTXO) di luar rantai, tetapi berbagi satu UTXO di dalam rantai untuk mengurangi biaya. Mirip dengan vault, Ark juga dapat diimplementasikan di jaringan Bitcoin saat ini; tetapi setelah pengenalan ketentuan pembatasan, Ark dapat mengurangi jumlah interaksi yang diperlukan berdasarkan template transaksi, mewujudkan keluarnya sepihak yang lebih terdesentralisasi.
Ikhtisar Teknologi Syarat Pembatasan
Dari aplikasi di atas, dapat dilihat bahwa syarat pembatas lebih mirip dengan efek daripada suatu teknologi, oleh karena itu ada banyak cara teknis untuk mewujudkannya. Jika dilakukan pengelompokan, dapat mencakup:
Dan di antaranya, rekursi mengacu pada: adanya implementasi beberapa ketentuan pembatas, yang juga dapat membatasi keluaran berikutnya dengan membatasi keluaran yang lebih lanjut, dapat mewujudkan pembatasan yang ditambahkan dapat melampaui satu transaksi, mencapai kedalaman transaksi yang lebih tinggi.
Beberapa desain ketentuan batasan utama meliputi:
*jika menggabungkan OP_CAT
Desain Ketentuan Pembatasan
Dari penjelasan sebelumnya, dapat dilihat bahwa skrip Bitcoin saat ini terutama membatasi syarat untuk membuka kunci, tetapi tidak membatasi bagaimana UTXO ini dapat digunakan lebih lanjut. Untuk mewujudkan syarat pembatasan, kita perlu berpikir sebaliknya: mengapa skrip Bitcoin saat ini tidak dapat mewujudkan syarat pembatasan?
Alasan utamanya adalah bahwa saat ini skrip Bitcoin tidak dapat membaca konten transaksi itu sendiri, yaitu "introspeksi" (.
Jika kita dapat mewujudkan introspeksi transaksi—memeriksa apa pun dari transaksi ) termasuk output (, maka syarat pembatas dapat direalisasikan.
Oleh karena itu, pemikiran desain ketentuan pembatasan juga terutama berfokus pada bagaimana mewujudkan introspeksi.
![Penjelasan Covenants: Bagaimana Mewujudkan Programmabilitas Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-a077d9a30293ef68ccb8482bfc57aeea.webp(
) Berdasarkan opcode vs Berdasarkan tanda tangan
Ide yang paling sederhana dan langsung adalah, menambahkan satu atau lebih kode operasi ( yaitu satu kode operasi + berbagai parameter, atau beberapa kode operasi ) dengan fungsi berbeda, langsung membaca isi transaksi. Ini juga merupakan pemikiran berbasis kode operasi.
Sementara itu, pemikiran lain adalah, tidak perlu membaca dan memeriksa isi transaksi itu sendiri secara langsung dalam skrip, tetapi dapat memanfaatkan hash dari isi transaksi—jika hash ini sudah ditandatangani, maka cukup dengan memodifikasi dalam skrip seperti OP_CHECKSIG dan lain-lain untuk melakukan pemeriksaan tanda tangan ini, sehingga dapat secara tidak langsung mewujudkan introspeksi transaksi dan membatasi ketentuan. Pemikiran ini didasarkan pada cara desain tanda tangan. Ini terutama mencakup APO dan OP_CSFS.
APO
SIGHASH_ANYPREVOUT(APO) adalah metode tanda tangan Bitcoin yang diusulkan. Cara paling sederhana untuk menandatangani adalah dengan berkomitmen pada semua input dan output transaksi, tetapi Bitcoin juga memiliki cara yang lebih fleksibel, yaitu SIGHASH, yang secara selektif berkomitmen pada input atau output dalam suatu transaksi.
dan SIGHASH APO hanya menandatangani output, bukan bagian input. Ini berarti bahwa transaksi yang ditandatangani dengan cara APO dapat dilakukan di