Bitcoin pembatasan ketentuan: arah baru untuk mencapai Programmabilitas

Komunitas Bitcoin baru-baru ini mengadakan diskusi hangat tentang reaktivasi opcode seperti OP_CAT. Taproot Wizard menarik banyak perhatian dengan meluncurkan Quantum Cats NFT dan mengklaim mendapatkan nomor BIP-420. Para pendukung mengatakan bahwa mengaktifkan OP_CAT dapat mewujudkan "syarat pembatas", sehingga membawa kontrak pintar dan Programmabilitas ke dalam Bitcoin.

"Ketentuan Pembatasan"(covenants) konsep ini telah memicu diskusi selama bertahun-tahun di kalangan pengembang. Selain OP_CAT, ada juga OP_CTV, APO, OP_VAULT, dan berbagai solusi teknis lainnya untuk menerapkan ketentuan pembatasan. Jadi, apa itu "ketentuan pembatasan" dalam Bitcoin? Mengapa hal ini dapat menarik perhatian yang begitu luas dan bertahan lama? Apa yang dapat dibawa oleh hal ini untuk koin Bitcoin dalam hal programmabilitas? Apa prinsip desain di baliknya? Artikel ini akan memberikan pengantar dan diskusi secara umum tentang pertanyaan-pertanyaan ini.

Apa itu "ketentuan pembatasan"

"Ketentuan Pembatasan" ( covenant ) adalah mekanisme yang dapat menetapkan syarat untuk transaksi Bitcoin di masa depan. Skrip Bitcoin saat ini telah mencakup beberapa syarat pembatasan, seperti memerlukan tanda tangan yang sah, menyediakan skrip yang sesuai, dan lain-lain. Namun, selama pengguna dapat membuka kunci, mereka dapat membelanjakan UTXO ke mana saja.

Syarat pembatasan telah menambahkan lebih banyak batasan di atas dasar ini, seperti membatasi tujuan pengeluaran UTXO selanjutnya, untuk mencapai efek "dana khusus untuk tujuan khusus"; atau membatasi syarat input lain dalam satu transaksi, dan sebagainya.

Lebih tepatnya, skrip Bitcoin saat ini juga memiliki fungsi pembatasan tertentu, seperti penguncian waktu berbasis opcode. Dengan memeriksa bidang nLock atau nSequence dari transaksi, batasan waktu sebelum pengeluaran transaksi dapat diterapkan. Namun saat ini, batasan tersebut terutama terbatas pada aspek waktu.

Tujuan pengembang merancang pemeriksaan batasan ini bukan hanya untuk membatasi, tetapi juga untuk menetapkan aturan pelaksanaan transaksi. Pengguna hanya dapat melakukan transaksi sesuai dengan aturan yang telah ditetapkan sebelumnya, sehingga menyelesaikan proses bisnis yang direncanakan.

Oleh karena itu, ketentuan pembatas secara tidak langsung dapat membuka lebih banyak skenario aplikasi.

Skenario Aplikasi

Pastikan hukuman Staking

Contoh intuitif dari klausul pembatasan adalah transaksi slash di staking Bitcoin oleh Babylon.

Proses staking Bitcoin di Babylon adalah pengguna mengirimkan aset BTC ke dalam skrip khusus di main chain, dengan syarat pengeluaran yang mencakup dua jenis:

1. Selesai secara normal: Setelah waktu tertentu, pengguna dapat membuka kunci dengan tanda tangan mereka sendiri, menyelesaikan proses unstake.

2. Hukuman selesai: Jika pengguna melakukan tindakan jahat seperti double signing di rantai PoS keamanan Babylon, maka melalui EOTS( dapat menarik tanda tangan sekali pakai ) untuk membuka kunci aset, dan peran eksekusi dalam jaringan akan memaksa mengirim sebagian aset ke alamat pembakaran (slash).

"Pengiriman paksa" di sini berarti bahwa meskipun UTXO dapat dibuka kuncinya, aset tersebut tidak dapat dikirim ke tempat lain dengan sembarangan, hanya dapat dibakar. Ini memastikan bahwa pengguna yang berbuat jahat tidak dapat dengan cepat menggunakan tanda tangan yang diketahui untuk mengembalikan aset kepada diri mereka sendiri dan menghindari hukuman.

Setelah penerapan klausul pembatasan seperti OP_CTV, kode operasi terkait dapat ditambahkan ke cabang "akhir hukuman" dari skrip staking untuk menerapkan pembatasan.

Sebelum OP_CTV diaktifkan, Babylon perlu mensimulasikan efek penegakan ketentuan pembatasan melalui metode akal yang dilaksanakan bersama oleh pengguna dan komite.

Pengendalian Kemacetan

Saat jaringan macet, banyak transaksi yang menunggu untuk diproses terakumulasi di dalam pool transaksi, pengguna perlu meningkatkan biaya untuk mendapatkan konfirmasi yang cepat. Jika pengguna harus mengirim beberapa transaksi kepada beberapa penerima, mereka harus menanggung biaya yang lebih tinggi, sementara itu juga meningkatkan tarif biaya seluruh jaringan.

Dengan adanya ketentuan pembatasan, pengirim dapat terlebih dahulu berkomitmen untuk mengirimkan transaksi dalam jumlah besar. Komitmen ini membuat semua penerima percaya bahwa transaksi akhir akan dilaksanakan, dan mereka dapat menunggu hingga tarif biaya transaksi menurun sebelum mengirimkan transaksi spesifik.

Ketika permintaan ruang blok sangat tinggi, transaksi menjadi mahal. Dengan menggunakan OP_CHECKTEMPLATEVERIFY, penyedia pemrosesan pembayaran dalam jumlah besar dapat mengagregasi semua pembayaran ke dalam satu transaksi O(1) untuk dikonfirmasi. Setelah itu, ketika permintaan ruang blok berkurang, pembayaran dapat diperluas dari UTXO tersebut.

Ini adalah salah satu contoh aplikasi khas dari ketentuan pembatas OP_CTV.

Gudang

Vault ( adalah skenario yang banyak dibahas dalam aplikasi Bitcoin, terutama di bidang ketentuan pembatasan. Operasi sehari-hari memerlukan keseimbangan antara penyimpanan dana dan kebutuhan penggunaan, orang-orang berharap ada jenis aplikasi brankas yang dapat menjamin keamanan dana, bahkan jika akun diretas ) dan kunci pribadi bocor (, tetap dapat membatasi penggunaan dana.

Berdasarkan teknologi ketentuan pembatas, aplikasi jenis penyimpanan dapat dibangun dengan relatif mudah.

Sebagai contoh skema OP_VAULT: Saat menggunakan dana vault, perlu terlebih dahulu mengirimkan satu transaksi ke blockchain untuk menyatakan niat )"trigger"(, dan menetapkan kondisi:

• Dalam keadaan normal: transaksi kedua adalah transaksi penarikan akhir. Setelah menunggu N blok, dana dapat digunakan lebih lanjut ke alamat mana pun.

• Situasi tidak normal: Jika ditemukan sebagai transaksi yang dicuri ) atau dipaksa (, sebelum transaksi penarikan dalam N blok dikirim, dana dapat segera dikirim ke alamat yang lebih aman.

Perlu dicatat bahwa meskipun tidak ada ketentuan pembatasan, aplikasi penyimpanan dapat dibangun. Salah satu caranya adalah dengan menyiapkan tanda tangan untuk pengeluaran di masa depan menggunakan kunci privat, kemudian menghancurkan kunci privat tersebut. Namun cara ini masih memiliki batasan, seperti perlu memastikan kunci privat telah dihancurkan, jumlah dan biaya transaksi harus ditentukan sebelumnya, dan kurangnya fleksibilitas.

![Penjelasan Covenants: Bagaimana Mewujudkan Programmabilitas Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(

) saluran status yang lebih kuat dan fleksibel

Saluran status ### termasuk jaringan Lightning ( di mana node dapat mengamati status terbaru dan dapat menerbitkan status terbaru ke blockchain secara normal, dapat dianggap memiliki keamanan yang hampir sama dengan main chain. Dengan adanya ketentuan pembatas, beberapa desain saluran status baru dapat menjadi lebih kuat atau fleksibel berdasarkan jaringan Lightning, yang cukup terkenal termasuk Eltoo, Ark, dan lain-lain.

Eltoo) juga dikenal sebagai LN-Symmetry( adalah contoh tipikal. Ini mengusulkan sebuah lapisan eksekusi untuk jaringan Lightning, memungkinkan setiap status saluran yang kemudian untuk menggantikan status sebelumnya, tanpa mekanisme hukuman, sehingga dapat menghindari node jaringan Lightning harus menyimpan beberapa status sebelumnya untuk mencegah lawan berbuat jahat. Eltoo mengusulkan metode tanda tangan SIGHASH_NOINPUT, yaitu APO)BIP-118( untuk mencapai efek ini.

Ark bertujuan untuk mengurangi kesulitan dalam likuiditas masuk dan manajemen saluran di jaringan Lightning. Ini adalah protokol dalam bentuk joinpool, di mana beberapa pengguna dapat menerima satu penyedia layanan sebagai lawan transaksi dalam jangka waktu tertentu, melakukan transaksi virtual UTXO)vUTXO( di luar rantai, tetapi berbagi satu UTXO di dalam rantai untuk mengurangi biaya. Mirip dengan penyimpanan, Ark juga dapat diimplementasikan di jaringan Bitcoin saat ini; tetapi setelah memperkenalkan ketentuan pembatasan, Ark dapat mengurangi jumlah interaksi yang diperlukan berdasarkan template transaksi, mewujudkan keluarnya satu sisi yang lebih terdesentralisasi.

![Rincian Covenants: Bagaimana Mewujudkan Programmabilitas Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(

Tinjauan Teknologi Ketentuan Pembatasan

Dari aplikasi di atas, dapat dilihat bahwa klausul pembatasan lebih mirip dengan suatu efek daripada teknik tertentu, oleh karena itu ada berbagai cara untuk mengimplementasikannya. Ini dapat diklasifikasikan dari beberapa dimensi berikut:

• Tipe: Umum, Khusus
• Metode implementasi: berdasarkan opcode, berdasarkan tanda tangan
• Rekursif: rekursi, non-rekursi

Dalam hal ini, rekursi mengacu pada implementasi beberapa syarat yang dapat membatasi keluaran berikutnya untuk membatasi keluaran yang selanjutnya, sehingga menerapkan batasan yang melintasi beberapa transaksi.

Desain ketentuan pembatasan arus utama termasuk:

• OP_CTV: Tipe umum, berbasis opcode, tidak rekursif
• APO: Tipe umum, berbasis tanda tangan, non-rekursif
• OP_VAULT: Tipe khusus, berbasis opcode, non-rekursif
• OP_CAT: Tipe Umum, berdasarkan opcode, rekursif ) jika digabungkan dengan OP_CAT (

![Penjelasan Covenants: Bagaimana Mewujudkan Programmabilitas Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-a077d9a30293ef68ccb8482bfc57aeea.webp(

Desain Ketentuan Pembatasan

Saat ini, skrip Bitcoin terutama membatasi kondisi pembukaan, tanpa membatasi bagaimana UTXO dapat dibelanjakan lebih lanjut. Untuk menerapkan ketentuan pembatasan, perlu merenungkan mengapa skrip saat ini tidak dapat merealisasikan fungsi ini.

Alasan utamanya adalah bahwa saat ini skrip Bitcoin tidak dapat membaca konten transaksi itu sendiri, yaitu "introspection" ).

Jika dapat mewujudkan introspeksi transaksi - memeriksa apa pun dalam transaksi ( termasuk output ), maka ketentuan pembatasan dapat dicapai.

Oleh karena itu, desain ketentuan pembatasan terutama berfokus pada bagaimana mewujudkan introspeksi.

( berbasis opcode vs berbasis tanda tangan

Pemikiran paling langsung adalah menambahkan satu atau lebih opcode ) satu opcode + berbagai parameter, atau beberapa opcode dengan fungsi berbeda ###, untuk membaca konten transaksi secara langsung. Ini adalah pemikiran berbasis opcode.

Satu pemikiran alternatif adalah tidak membaca dan memeriksa konten transaksi secara langsung dalam skrip, tetapi menggunakan hash dari konten transaksi—jika hash ini telah ditandatangani, maka cukup dengan memodifikasi seperti OP_CHECKSIG dalam skrip untuk memeriksa tanda tangan ini, kita dapat secara tidak langsung merealisasikan introspeksi transaksi dan batasan ketentuan. Ini adalah cara desain yang berbasis tanda tangan, yang 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 memungkinkan untuk secara selektif berkomitmen pada input atau output dalam transaksi.

SIGHASH APO hanya menandatangani output, tidak menandatangani bagian input. Ini berarti transaksi yang ditandatangani dengan cara APO dapat ditambahkan ke UTXO apa pun yang memenuhi syarat.

Fleksibilitas ini adalah dasar teoretis untuk implementasi ketentuan pembatasan APO:

• Anda dapat membuat satu atau lebih transaksi sebelumnya.
• Membangun sebuah kunci publik yang hanya dapat menghasilkan satu tanda tangan dari informasi transaksi ini
• Dengan cara ini, semua aset yang dikirim ke alamat kunci publik tersebut hanya dapat digunakan melalui transaksi yang telah dibuat sebelumnya.

Perlu dicatat bahwa, karena kunci publik ini tidak memiliki kunci privat yang sesuai, maka dapat dipastikan bahwa aset-aset ini hanya dapat dibelanjakan melalui transaksi yang telah dibuat sebelumnya. Kita dapat menentukan arah aset dalam transaksi yang telah dibuat sebelumnya ini, sehingga dapat mencapai syarat pembatasan.

Kita bisa memahami melalui perbandingan kontrak pintar Ethereum: melalui kontrak pintar, kita juga dapat mencapai bahwa hanya melalui kondisi tertentu, kita dapat menarik uang dari alamat kontrak, dan bukan hanya berdasarkan tanda tangan EOA untuk menghabiskan sesuka hati. Dari sudut pandang ini, Bitcoin dapat mencapai efek ini melalui perbaikan mekanisme tanda tangan.

Namun masalah dalam proses di atas adalah adanya ketergantungan siklik dalam perhitungan, karena perlu mengetahui konten input untuk melakukan pra-tanda tangan dan membuat transaksi.

Makna implementasi metode tanda tangan ini dengan APO dan SIGHASH_NOINPUT adalah untuk menyelesaikan masalah ketergantungan siklik ini, pada saat perhitungan hanya perlu mengetahui seluruh output transaksi yang ditentukan oleh (.

![Penjelasan Covenants: Bagaimana Mewujudkan Programmabilitas Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-302ac02874352e52cf0e80c7ddb193ec.webp(

) OP_CTV

OP_CHECKTEMPLATEVERIFY(CTV), yaitu BIP-119, menggunakan opcode yang ditingkatkan