Memahami programabilitas suatu sistem mengharuskan kita untuk mengidentifikasi fitur struktural sistem. Eksplorasi pemrograman aplikasi berbasis Bitcoin Script membantu kita memahami struktur dasar CKB Cell dan paradigma pemrogramannya. Tidak hanya itu, tetapi juga memecah komponen pemrograman CKB menjadi bagian-bagian yang tepat dan membantu kita memahami keuntungan programabilitas yang dibawa oleh setiap bagian.
I. Pendahuluan
"Programabilitas" adalah dimensi yang sering diambil orang ketika membandingkan sistem blockchain. Namun, sering ada ketidaksepakatan tentang bagaimana programabilitas dijelaskan. Ungkapan umum adalah "XX blockchain mendukung bahasa pemrograman Turing-complete", atau, "XX blockchain mendukung pemrograman tujuan umum", yang dimaksudkan untuk menunjukkan bahwa "XX blockchain" di sini memiliki programabilitas yang kuat. Ada beberapa kebenaran implikasi dari pernyataan ini: sistem yang mendukung pemrograman Turing-complete umumnya lebih mudah diprogram daripada yang tidak. Namun, ada banyak aspek pada karakteristik struktural dari sistem kontrak pintar, dan pernyataan ini hanya menyentuh salah satunya, sehingga tidak cukup untuk dipahami secara cukup mendalam berdasarkan fakta bahwa pengembang tidak dipandu olehnya, dan pengguna biasa tidak dapat diandalkan untuk membedakan penipuan.
Fitur struktural dari sistem kontrak pintar meliputi:
Bentuk dasar ekspresi negara (kontrak) (akun vs. output perdagangan)
Apakah perhitungan sewenang-wenang diizinkan untuk diprogram (inilah istilah "Turing-complete")
Apakah proses eksekusi membuat data baru, atau apakah itu hanya pingsan boolean? (Komputasi vs. Validasi)
Apakah atau tidak untuk mengizinkan negara-negara tambahan untuk dicatat dalam kontrak
Apakah kontrak memiliki akses ke keadaan kontrak lain ketika dieksekusi
Oleh karena itu, selain "perhitungan sewenang-wenang yang dapat diprogram", setidaknya ada empat karakteristik yang memengaruhi kemampuan pemrograman sistem kontrak pintar. Bahkan dapat dikatakan bahwa fitur-fitur lain ini lebih penting, karena mereka menentukan pada tingkat yang lebih dalam apa yang mudah dicapai dan apa yang sulit dicapai; Apa implementasi yang lebih ekonomis dan apa implementasi yang kurang efisien.
Misalnya, Ethereum sering dikutip sebagai contoh programabilitas yang baik, tetapi bentuk dasar ekspresi negara pada Ethereum adalah akun, yang membuatnya sulit untuk memprogram kontrak peer-to-peer (misalnya, gateway pembayaran, kontrak taruhan satu-ke-satu) – tidak sepenuhnya mustahil, hanya tanpa pamrih. Bukan hal yang aneh bagi ekosistem Ethereum untuk mencoba menerapkan saluran pembayaran / saluran negara, dan ada banyak diskusi teoretis, tetapi proyek-proyek ini tampaknya tidak aktif lagi – dan ini jelas tidak dapat disalahkan pada kurangnya upaya dari pihak pengembang. Bukan kebetulan bahwa proyek yang aktif di Ethereum saat ini mengambil bentuk "kumpulan" daripada "kontrak peer-to-peer". Demikian pula, orang mungkin senang dengan programabilitas Ethereum, tetapi model akun secara inheren kurang dalam mencapai "abstraksi akun" (yang juga dapat dipahami sebagai generalisasi konsep dompet).
Dengan cara yang sama, mengeksplorasi programabilitas CKB juga mengharuskan kita untuk memahami karakteristik struktural sistem kontrak pintar CKB dalam aspek-aspek ini. Apa yang sudah kita ketahui adalah bahwa CKB memungkinkan perhitungan sewenang-wenang untuk diprogram, memungkinkan keadaan tambahan dicatat dalam kontrak, dan memungkinkan satu kontrak untuk mengakses keadaan kontrak lain ketika dieksekusi. Namun, bentuk kontrak adalah output dari transaksi (disebut "sel"), yang membuatnya secara fundamental berbeda dari Ethereum. Oleh karena itu, pemahaman tentang sistem kontrak pintar Ethereum dan contoh kontrak di dalamnya tidak membantu kami memahami bagaimana CKB mengimplementasikan fitur-fitur struktural ini, juga tidak membantu kami memahami programabilitas CKB.
Untungnya, kontrak pintar pada Bitcoin tampaknya memberikan dasar terbaik untuk memahami programabilitas CKB. Ini bukan hanya karena bentuk dasar representasi negara Bitcoin juga merupakan output dari transaksi (disebut "UTXO"), tetapi juga karena, dengan bantuan konsep yang diusulkan oleh komunitas Bitcoin yang disebut "perjanjian", kita dapat memahami mengapa CKB memiliki karakteristik struktural ini, dan secara tepat memecah efek akhir menjadi beberapa bagian, mengidentifikasi keuntungan programabilitas yang dibawa masing-masing.
II. CKB v.s. BTC: Terlebih Lagi?
(1) Struktur dasar
Sebagai bentuk dasar representasi negara Bitcoin, UTXO Bitcoin ("Unspent Transaction Output") memiliki dua bidang:
Jumlahnya, dalam Satoshi, menunjukkan nilai Bitcoin yang dimiliki oleh UTXO;
Kunci publik skrip, juga dikenal sebagai skrip kunci, mewakili kondisi yang harus dipenuhi untuk membelanjakan dana, yaitu program kontrak pintar yang menetapkan kondisi untuk membuka kunci dana.
Dibandingkan dengan sistem kontrak pintar yang datang kemudian, Bitcoin Script sangat terbatas:
Itu tidak memungkinkan pemrograman perhitungan sewenang-wenang; Hanya ada beberapa perhitungan praktis yang dapat digunakan untuk verifikasi (pemeriksaan tanda tangan, pemeriksaan pra-hash, pemeriksaan waktu)
Ini tidak memungkinkan negara tambahan untuk dicatat dalam kontrak; (Misalnya, Anda tidak dapat menggunakan skrip untuk membatasi jumlah proporsional/maksimum uang yang dihabiskan pada suatu waktu; Juga tidak ada cara untuk menyembunyikan token di dalamnya)
Ini juga tidak memungkinkan akses ke keadaan kontrak lain pada saat eksekusi (setiap skrip adalah alam semesta yang terpisah dan tidak saling bergantung satu sama lain).
Scripting semacam ini, meskipun terbatas, tidak kekurangan kemampuan untuk memprogram aplikasi yang luar biasa, dan ini adalah dasar dari eksplorasi kami tentang programabilitas CKB. Akan ada bagian nanti yang akan memperkenalkan dua contoh pemrograman Bitcoin Script.
Sebaliknya, unit status CKB disebut "sel" dan memiliki empat bidang:
Kapasitas, mirip dengan jumlah UTXO, menyatakan jumlah ruang yang dapat ditempati sel, diukur dalam byte.
Kunci, mirip dengan kunci publik skrip UTXO, mendefinisikan kepemilikan sel; Hanya ketika data yang disediakan dapat melewati kunci, sel dapat "diperbarui" (atau sel dapat dilepaskan dan kapasitasnya dapat digunakan untuk mencetak sel baru);
Data, data, data arbitrer, yang volumenya dibatasi oleh Kapasitas;
Jenis, skrip opsional yang menetapkan kondisi untuk memperbarui Data.
Selain itu, Kunci dan Tipe dapat diprogram untuk perhitungan sewenang-wenang. Anda dapat memprogram algoritma verifikasi tanda tangan apa pun, Anda dapat memprogram algoritme hash apa pun untuk pemeriksaan preimage, dan sebagainya.
Sangat mudah bagi pembaca untuk melihat bagaimana programabilitas Cell meningkat dibandingkan UTXOs:
Sel dapat diprogram dengan perhitungan sewenang-wenang, bukan hanya beberapa perhitungan tertentu; Verifikasi kepemilikannya akan lebih fleksibel;
Karena bidang Data dan Jenis, sel dapat merekam status tambahan; Hal ini memungkinkan sel untuk membawa apa yang dikenal sebagai "UDT" (token yang ditentukan pengguna).
Dikombinasikan dengan struktur "output transaksi" dari sel itu sendiri, manfaat dari kedua poin ini sendiri sangat, sangat signifikan, tetapi dari uraian di atas saja, kita tidak tahu bagaimana sel mencapai "satu kontrak mengakses keadaan kontrak lain saat runtime". Untuk melakukan ini, kita perlu menggambar konsep yang telah lama dibahas di komunitas Bitcoin: "perjanjian".
(2) Keterbatasan dan introspeksi
Tujuan awal dari klausul pembatasan adalah untuk membatasi di mana sejumlah uang dapat dibelanjakan. Pada Bitcoin saat ini (di mana tidak ada batasan yang diusulkan), sejumlah uang, setelah dibuka, dapat dihabiskan di mana saja (dapat dibayarkan ke kunci publik skrip arbitrer). Tetapi gagasan tentang klausa pembatasan adalah bahwa itu dapat dihabiskan dengan cara yang membatasinya ke tempat-tempat tertentu, misalnya, UTXO tertentu hanya akan dihabiskan oleh transaksi tertentu, sehingga bahkan jika seseorang dapat memberikan tanda tangan untuk UTXO, di mana itu dapat dibelanjakan telah ditentukan oleh transaksi itu. Ini mungkin tampak agak aneh, tetapi dapat menyebabkan beberapa aplikasi menarik, yang akan dibahas dalam bagian nanti. Yang penting, ini adalah kunci untuk pemahaman lebih lanjut kami tentang programabilitas CKB.
Rusty Russell dengan tepat menunjukkan bahwa pembatasan dapat dipahami sebagai kemampuan "introspeksi" untuk berdagang, yaitu, ketika UTXO A dihabiskan oleh transaksi B, operator skrip dapat membaca beberapa (atau semua) transaksi B dan kemudian memeriksa apakah mereka cocok dengan parameter yang diminta sebelumnya oleh skrip. Misalnya, apakah kunci publik skrip untuk output pertama transaksi A cocok dengan apa yang diperlukan oleh kunci publik skrip UTXO A (inilah yang awalnya dimaksud dengan pembatasan).
Pembaca yang cerdik akan menyadari bahwa dengan introspeksi penuh, input dari satu transaksi dapat membaca keadaan input lain dari transaksi yang sama, yang memungkinkan kemampuan satu kontrak untuk mengakses keadaan kontrak lain saat runtime. Faktanya, begitulah CKB Cell dirancang.
Berdasarkan ini, kita dapat membagi kapasitas introspektif lengkap ini menjadi empat skenario:
Kunci membaca kunci lain (input dan output)
Kunci membaca Jenis (serta Data) dari yang lain (input dan output)
Jenis membaca kunci lain (input dan output)
Tipe membaca Tipe (dan Data) dari yang lain (input dan output)
Hal ini memungkinkan kita untuk menganalisis peran kemampuan introspektif masing-masing bagian dalam kasus penggunaan yang berbeda di bawah asumsi tertentu (pembagian fungsi antara Kunci dan Jenis), yaitu, keuntungan programabilitas yang dibawa setiap bagian kepada kita.
Dalam dua bagian berikut, kita akan melihat pemrograman Bitcoin Script saat ini (dan belum diusulkan), dan kemungkinan fungsionalitas yang diharapkan dapat dicapai oleh pembatasan yang diusulkan, sehingga dapat memberikan pemahaman konkret tentang bagaimana CKB Cell dapat diprogram dan dilakukan dengan lebih baik.
III. Pemrograman Skrip Bitcoin
Di bagian ini, kita akan menggunakan "Lightning Channel / Lightning Network" dan "Caution Journal Contract (DLC)" sebagai contoh pemrograman aplikasi berdasarkan Bitcoin Script. Sebelum kita membahasnya, mari kita bahas dua hal ke dalamnya.
(1) OP_IF dan "Penawaran Komitmen"
Konsep pertama adalah flow control opcode di Bitcoin Script, seperti: OP_IF, OP_ELSE. Opcode ini tidak berbeda dengan IF dalam pemrograman komputer, dan tujuannya adalah untuk mengeksekusi pernyataan yang berbeda berdasarkan input yang berbeda. Dalam konteks Bitcoin Script, ini berarti kita dapat mengatur beberapa jalur membuka kunci untuk dana; Dikombinasikan dengan fitur timelock, ini berarti kita dapat menetapkan prioritas pada tindakan.
Ambil "Hash Timelock Contract (HTLC)" yang terkenal sebagai contoh, yang diterjemahkan ke dalam bahasa sehari-hari:
Atau, Bob bisa mengungkapkan preimage di balik hash H dan memberikan tanda tangannya sendiri, yang akan menghabiskan uang
Atau, Alice dapat menghabiskan uang dengan tanda tangannya sendiri setelah jangka waktu tertentu T
Ini "atau ... atau ..." Efeknya dicapai melalui opcode kontrol proses.
Keuntungan paling menonjol dari HTLC > adalah dapat menggabungkan beberapa operasi bersama-sama dan mengatomisasinya. Misalnya, jika Alice ingin menukar BTC dengan CKB dengan Bob, maka Bob dapat terlebih dahulu memberikan nilai hash dan membuat HTLC di Jaringan Nervos. Alice kemudian membuat HTLC pada Bitcoin yang menggunakan hash yang sama. Atau, Bob mengambil BTC yang dibayarkan oleh Alice di Bitcoin, sementara juga mengungkapkan preimage, memungkinkan Alice untuk menarik CKB di Jaringan Nervos. Either way, Bob tidak mengungkapkan gambar aslinya, kedua kontrak berakhir, dan Alice dan Bob bisa mendapatkan kembali uang yang mereka investasikan.
Setelah aktivasi garpu lunak Taproot, fitur jalur multi-buka kunci ini semakin ditingkatkan dengan pengenalan MAST (Merkle Abstract Syntax Tree): kita dapat mengubah jalur buka kunci menjadi daun di pohon Merkle, setiap daun independen, jadi tidak perlu lagi menggunakan opcode kontrol aliran seperti itu; Juga, karena satu jalur terungkap tanpa mengekspos yang lain, kita dapat menambahkan sejumlah besar jalur buka kunci ke output tanpa harus khawatir tentang ekonomi.
Konsep kedua adalah "perdagangan komitmen". Ide dari transaksi yang dilakukan adalah bahwa, dalam beberapa kasus, transaksi Bitcoin yang valid, bahkan jika tidak dikonfirmasi oleh blockchain, sama nyata dan mengikatnya.
Misalnya, Alice dan Bob berbagi UTXO yang mengharuskan keduanya ditandatangani untuk dibelanjakan. Pada titik ini, Alice membangun transaksi untuk membelanjakannya, mentransfer 60% nilainya ke Bob dan sisanya untuk dirinya sendiri; Alice memberikan tanda tangannya sendiri untuk transaksi, yang kemudian dikirim ke Bob. Nah, bagi Bob, itu tidak harus disiarkan ke jaringan Bitcoin, dan tidak harus dikonfirmasi oleh blockchain, dan efek pembayaran dari transaksi ini juga nyata dan kredibel. Karena Alice tidak dapat membelanjakan UTXO sendiri (dan karenanya tidak dapat membelanjakannya berulang kali), dan karena tanda tangan yang diberikan oleh Alice valid, Bob selalu dapat menambahkan tanda tangannya dan menyiarkan transaksi untuk menghormati pembayaran. Dengan kata lain, Alice memberi Bob "komitmen yang kredibel" melalui transaksi (off-chain) yang valid ini.
Transaksi berkomitmen adalah konsep inti dari pemrograman aplikasi Bitcoin. Seperti disebutkan sebelumnya, kontrak Bitcoin berbasis verifikasi, tanpa kewarganegaraan, dan tidak mengizinkan akses silang; Namun, jika kontrak tidak membawa negara, di mana negara-negara disimpan, dan bagaimana kontrak dapat dengan aman bergerak maju (mengubah negara)? Transaksi komitmen memberikan jawaban langsung: keadaan kontrak dapat dinyatakan dalam bentuk transaksi, sehingga peserta kontrak dapat menyelamatkan negara sendiri tanpa harus menampilkannya di blockchain; Masalah mengubah keadaan kontrak juga dapat diubah menjadi masalah bagaimana memperbarui transaksi yang dilakukan dengan aman; Selain itu, jika kita khawatir tentang bahaya memasuki kontrak (misalnya, memasukkan kontrak yang mengharuskan kedua belah pihak untuk menandatangani untuk membelanjakan, dan ada risiko bahwa pihak lain tidak akan merespons dan terjebak), maka hanya menghasilkan transaksi komitmen yang membebani kontrak di muka dan mendapatkan tanda tangan dapat mengurangi risiko dan menghilangkan kepercayaan pada peserta lain.
(2) Saluran petir dan jaringan petir
Saluran kilat adalah kontrak satu-ke-satu di mana dua pihak dapat saling membayar dalam jumlah tak terbatas tanpa satu pembayaran pun yang dikonfirmasi oleh blockchain. Seperti yang Anda duga, ia menggunakan perdagangan komitmen.
Di bagian yang menjelaskan "Transaksi yang Dilakukan", kami telah memperkenalkan saluran pembayaran. Namun, kontrak semacam ini, yang hanya memanfaatkan 2-dari-2 multisig, hanya dapat memungkinkan pembayaran satu arah. Artinya, Alice selalu membayar Bob, atau Bob selalu membayar Alice sampai dia menghabiskan saldonya dalam kontrak. Jika itu adalah pembayaran dua arah, itu berarti bahwa setelah pembaruan status, satu pihak mungkin memiliki saldo lebih sedikit dari sebelumnya, tetapi TA memiliki transaksi komitmen terakhir yang ditandatangani oleh pihak lain - apa yang dapat dilakukan untuk menghentikan TA dari menyiarkan janji lama dan TA hanya dari transaksi komitmen terbaru?
Solusi untuk masalah ini dengan saluran petir disebut "LN-Penalty". Sekarang, katakanlah Alice dan Bob masing-masing memiliki 5 BTC dalam satu saluran; Sekarang Alice ingin membayar Bob 1 BTC, jadi dia menandatangani transaksi yang dijanjikan dan mengirimkannya ke Bob:
Keluaran #1 , 4 BTC:
atau
Bob-Alice federated ephemeral public key #1 single-signature
atau
T 1 timelock, Alice single-signed
Triknya di sini terletak pada "kunci publik sementara bersama" ini, yang dihasilkan menggunakan salah satu kunci publiknya sendiri dan kunci publik yang disediakan oleh pihak lain, misalnya, kunci publik sementara bersama Alice-Bob, yang diperoleh Alice menggunakan salah satu kunci publiknya sendiri dan kunci publik yang disediakan oleh Bob, mengalikan masing-masing dengan nilai hash. Ketika kunci publik seperti itu dibuat, tidak ada yang tahu kunci pribadinya. Namun, jika Bob memberi tahu Alice kunci pribadi dari kunci publik yang dia berikan, Alice dapat menghitung kunci pribadi dari kunci publik sementara federasi. - Ini adalah kunci fakta bahwa Saluran Petir dapat "membatalkan" keadaan lama.
Lain kali kedua pihak ingin memperbarui status saluran (memulai pembayaran), kedua pihak bertukar kunci pribadi dari kunci publik sementara yang diberikan satu sama lain di babak sebelumnya. Dengan cara ini, peserta tidak lagi berani menyiarkan transaksi terakhir yang dijanjikan yang mereka terima: output dari transaksi yang dijanjikan ini memberikan nilai kepada pihak mereka sendiri memiliki dua jalur, dan kunci pribadi dari jalur kunci publik sementara sudah diketahui pihak lain; Jadi begitu transaksi komitmen lama disiarkan, pihak lain dapat segera menggunakan kunci pribadi sementara bersama ini untuk mengambil semua dana dalam output ini. - Inilah arti "LN-Penalty".
Secara khusus, urutan interaksi adalah sebagai berikut: pihak yang memulai pembayaran pertama-tama meminta kunci publik sementara baru dari pihak lain, dan kemudian membangun transaksi komitmen baru dan menyerahkannya kepada pihak lain; Pihak yang mendapat transaksi yang dijanjikan mengungkapkan kepada pihak lain kunci pribadi dari kunci publik sementara yang dia berikan di babak sebelumnya. Urutan interaksi ini memastikan bahwa peserta selalu mendapatkan transaksi komitmen baru sebelum membatalkan transaksi komitmen yang mereka terima di putaran sebelumnya, dan karenanya tidak dapat dipercaya.
Singkatnya, desain utama saluran petir adalah:
Kedua belah pihak selalu menggunakan transaksi komitmen untuk menyatakan keadaan dalam kontrak, dan perubahan jumlah untuk menyatakan pembayaran;
Transaksi komitmen selalu membutuhkan input yang sama (input yang mengharuskan kedua belah pihak untuk memberikan tanda tangan pada saat yang sama), sehingga semua transaksi komitmen bersaing satu sama lain, dan hanya satu yang dapat dikonfirmasi oleh blockchain.
Kedua peserta tidak menandatangani transaksi komitmen yang sama (meskipun dipasangkan); Dan apa yang mereka tandatangani selalu merupakan transaksi yang lebih menguntungkan bagi diri mereka sendiri, dengan kata lain, transaksi yang dijanjikan yang diterima peserta selalu tidak menguntungkan bagi diri mereka sendiri;
Kerugiannya adalah bahwa output yang memberikan nilai pada dirinya sendiri memiliki dua jalur membuka kunci: satu jalur dapat dibuka dengan tanda tangannya sendiri, tetapi perlu menunggu beberapa saat; Jalur lain menggunakan kunci publik pihak lain, yang dilindungi hanya jika salah satu kunci pribadi sementara tidak terbuka.
Dalam setiap pembayaran, kedua belah pihak menukar private key sementara yang digunakan oleh pihak lain pada putaran sebelumnya dengan transaksi komitmen baru, sehingga pihak yang menyerahkan private key sementara tidak lagi berani menyiarkan transaksi komitmen lama, sehingga "membatalkan" transaksi komitmen sebelumnya dan memperbarui status kontrak; (Sebenarnya transaksi yang dijanjikan ini semuanya adalah transaksi yang valid dan bisa disiarkan ke blockchain, namun pesertanya terpaksa dihukum dan tidak berani disiarkan lagi)
Salah satu pihak dapat menarik diri dari kontrak kapan saja dengan komitmen yang ditandatangani oleh pihak lain; Namun, jika kedua belah pihak bersedia bekerja sama, mereka dapat menandatangani kesepakatan baru sehingga kedua belah pihak dapat segera mendapatkan uang mereka kembali.
Akhirnya, karena HTLC juga dapat ditempatkan dalam transaksi yang berkomitmen, saluran Lightning juga dapat meneruskan pembayaran. Dengan asumsi bahwa Alice dapat menemukan jalur yang terdiri dari saluran petir yang menghubungkan sebelum dan sesudah untuk mencapai Daniel, maka pembayaran multi-hop tanpa kepercayaan dapat dicapai tanpa membuka saluran dengan Daniel. Ini adalah Jaringan Petir:
Alice -- HTLC --> Bob -- HTLC --> Carol -- HTLC --> Daniel
Alice < -- Preimage -- Bob < -- Preimage -- Carol < -- Preimage -- Daniel
Ketika Alice menemukan jalan seperti itu dan ingin membayar Daniel, dia meminta Daniel untuk hash untuk membangun HTLC untuk Bob, dan meminta Bob untuk meneruskan pesan ke Carol dan memberikan HTLC yang sama; Pesan tersebut meminta Carol untuk meneruskan pesan tersebut kepada Daniel dan memberikan HTLC yang sama. Ketika berita itu sampai ke Daniel, dia mengungkapkan preimage kepada Carol, yang memberinya nilai HTLC dan memperbarui keadaan kontrak. Carol melakukan hal yang sama, dibayar oleh Bob dan memperbarui status saluran; Akhirnya, Bob mengungkapkan preimage kepada Alice dan memperbarui statusnya. Karena sifat HTLC, rantai pembayaran ini berhasil atau gagal bersama, dan dengan demikian, tidak dapat dipercaya.
Jaringan Petir terdiri dari satu saluran demi saluran, yang masing-masing tidak bergantung satu sama lain. Ini berarti Alice hanya perlu mengetahui apa yang terjadi di salurannya dengan Bob, terlepas dari berapa banyak interaksi yang telah terjadi di saluran orang lain, mata uang apa yang digunakan interaksi tersebut, atau bahkan apakah mereka benar-benar menggunakan saluran tersebut.
Skalabilitas Jaringan Petir tidak hanya tercermin dalam kenyataan bahwa kecepatan pembayaran dalam Saluran Petir hanya dibatasi oleh investasi sumber daya perangkat keras oleh kedua belah pihak, tetapi juga karena penyimpanan negara yang terdesentralisasi, satu node dapat memanfaatkan leverage maksimum dengan biaya terendah.
(3) Hati-hati dengan kontrak jurnal
Cautionary Journaling Contract (DLC) menggunakan teknik kriptografi yang disebut "tanda tangan adaptor" yang memungkinkan Bitcoin Script memprogram kontrak keuangan yang bergantung pada peristiwa eksternal.
Tanda tangan adaptor memungkinkan tanda tangan menjadi tanda tangan yang valid hanya setelah kunci privat ditambahkan. Ambil contoh tanda tangan Schnorr, di mana bentuk standar tanda tangan Schnorr adalah (R, s), di mana:
R = r.G
Nilai nonce r yang digunakan untuk tanda tangan dikalikan dengan titik generasi kurva elips, yang juga dapat dikatakan sebagai kunci publik r
s = r + Hash(R || m || P) * p
p adalah kunci privat penandatanganan, dan P adalah kunci publik
验证签名即验证 s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK
Katakanlah saya memberikan sepasang data (R, s') di mana:
R = R 1 + R 2 = r 1.G + r 2.G
s' = r 1 + Hash(R || m || P) * p
Jelas, ini bukan tanda tangan Schnorr yang valid, dan tidak lulus rumus validasi, tetapi saya dapat membuktikan kepada verifikator bahwa itu bisa menjadi tanda tangan yang valid hanya dengan mengetahui kunci pribadi R 2, r 2:
s'. G + R 2 = R 1 + Hash (R || m || P) * P + R 2 = R + Hash (R || m || P) * P
Tanda tangan adaptor membuat validitas tanda tangan bergantung pada data rahasia dan dapat diverifikasi. Tapi apa hubungannya ini dengan kontrak keuangan?
Katakanlah Alice dan Bob ingin bertaruh pada hasil pertandingan bola. Alice dan Bob bertaruh pada Green Goblin dan Alina untuk menang, masing-masing, dengan taruhan 1 BTC. Selain itu, Carol, situs web ulasan sepak bola, berjanji untuk menggunakan nonce R_c untuk memposting hasil yang ditandatangani _c_i ketika hasil pertandingan diumumkan.
Seperti yang dapat dilihat, ada tiga kemungkinan hasil (jadi ada 3 kemungkinan untuk tanda tangan Carol):
Green Goblin menang, Alice memenangkan 1 BTC
Alina menang, dan Bob memenangkan 1 BTC
Tie, dana keduanya kembali dengan cara yang sama
Untuk melakukan ini, keduanya membuat kesepakatan komitmen untuk setiap hasil. Misalnya, transaksi komitmen yang mereka buat untuk hasil pertama akan terlihat seperti ini:
Namun, alih-alih (R, s), tanda tangan yang dibuat Alice dan Bob untuk transaksi ini adalah tanda tangan adaptor (R, s'); Dengan kata lain, tanda tangan yang diberikan satu sama lain oleh kedua belah pihak tidak dapat digunakan secara langsung untuk membuka kunci kontrak, tetapi harus mengungkapkan nilai rahasia. Nilai rahasia ini adalah preimage dari s_c_ 1.G, yang merupakan tanda tangan Carol! Karena nilai nonce tanda tangan Carol telah ditentukan (R_c), s_c_ 1.G dapat dibangun (s_c_ 1.G = R_c + Hash(R_c ||). 'Green Goblin menang' || PK_c) * PK_c)。
Ketika hasilnya terungkap, dengan asumsi bahwa Green Goblin menang, Carol akan mengeluarkan tanda tangan (R_c, s_c_ 1), sehingga Alice atau Bob dapat menyelesaikan tanda tangan adaptor lawan dan menambahkan tanda tangan mereka sendiri untuk membuat transaksi di atas menjadi transaksi yang valid, dan menyiarkannya ke jaringan untuk memicu efek penyelesaian. Tetapi jika Green Goblin tidak menang, Carol tidak akan memposting s_c_ 1, dan kesepakatan komitmen tidak akan menjadi kesepakatan yang valid.
Dan seterusnya, seperti juga dua perdagangan lainnya. Dengan cara ini, Alice dan Bob membuat pelaksanaan kontrak tergantung pada peristiwa eksternal (tepatnya, pada siaran mesin asertor dari peristiwa eksternal, dalam bentuk tanda tangan) tanpa harus mempercayai rekanan. Kontrak keuangan besar dan kecil, seperti futures dan opsi, dapat diimplementasikan dengan cara ini.
Dibandingkan dengan bentuk implementasi lainnya, fitur terpenting dari kontrak log yang berhati-hati adalah privasinya: (1) Alice dan Bob tidak perlu memberi tahu Carol bahwa mereka menggunakan data Carol, yang tidak mempengaruhi pelaksanaan kontrak sama sekali; (2) Pengamat on-chain (termasuk Carol) tidak akan dapat menentukan situs web mana yang mereka gunakan melalui eksekusi kontrak Alice dan Bob, atau bahkan bahwa kontrak mereka adalah kontrak taruhan (bukan saluran kilat).
IV. Pengantar Penerapan Pembatasan
(a) OP_CTV dan pengendalian kemacetan
Pengembang komunitas Bitcoin telah membuat sejumlah proposal yang dapat diklasifikasikan sebagai klausa pembatasan. Saat ini, salah satu proposal yang paling terkenal adalah OP \ _CHECKTEMPLATEVERIFY (OP \ _CTV), yang populer di kalangan komunitas Bitcoin karena kesederhanaannya tetapi fleksibilitas dengan konsepnya yang sederhana. Ide OP_CTV adalah untuk melakukan hash dalam skrip untuk membatasi bahwa dana hanya dapat dihabiskan oleh transaksi yang diwakili oleh hash ini; Hash ini menjanjikan output dari transaksi dan sebagian besar bidang, tetapi bukan input transaksi, hanya jumlah input.
"Kontrol Kemacetan" adalah contoh yang baik tentang bagaimana OP \ _CTV dapat ditunjukkan. Kasus penggunaan dasarnya adalah untuk membantu sejumlah besar pengguna keluar dari pertukaran (lingkungan yang membutuhkan kepercayaan) ke dalam kumpulan; Karena kumpulan ini menggunakan OP_CTV untuk merencanakan bagaimana pembelanjaannya di masa mendatang, ini menjamin bahwa pengguna dapat keluar dari kumpulan tanpa kepercayaan, tanpa bantuan siapa pun; Dan karena kumpulan ini hanya berperilaku sebagai UTXO, ia menghindari membayar banyak biaya ketika permintaan untuk transaksi on-chain tinggi (dari n output ke 1 output; juga dikurangi dari n transaksi menjadi 1 transaksi). Pengguna di pool dapat menunggu kesempatan untuk keluar dari pool.
Katakanlah Alice, Bob, dan Carol ingin menarik masing-masing 5 BTC, 3 BTC, dan 2 BTC dari bursa. Kemudian pertukaran dapat menghasilkan output 10 BTC dengan 3 OP \ _CTV cabang. Katakanlah Alice ingin menarik uang, dia dapat menggunakan cabang 1; Transaksi yang diwakili oleh nilai hash yang digunakan oleh OP_CTV cabang akan membentuk dua output, salah satunya adalah mengalokasikan 5 BTC ke Alice; Output lainnya, pada gilirannya, adalah kumpulan, yang juga menggunakan OP \ _CTV untuk berkomitmen pada transaksi, memungkinkan Bob untuk menarik hanya 3 BTC dan mengirim 2 BTC sisanya ke Carol.
Sama halnya jika Bob atau Carol ingin menarik uang. Saat menarik uang, mereka hanya akan dapat menggunakan transaksi yang dapat melewati cek OP_CTV yang sesuai, yaitu mereka hanya akan dapat membayar jumlah yang sesuai untuk diri mereka sendiri, dan tidak akan dapat menarik uang secara sewenang-wenang; Dana yang tersisa akan masuk ke pool dengan kunci OP_CTV, sehingga menjamin bahwa pengguna yang tersisa dapat ditempatkan di luar pool tanpa kepercayaan, terlepas dari urutan penarikannya.
Secara abstrak, peran OP \ _CTV di sini adalah untuk merencanakan jalan menuju akhir masa kontrak untuk kontrak, sehingga kontrak kumpulan di sini dapat mempertahankan atribut keluar tanpa kepercayaan tidak peduli jalan mana yang diambil atau negara mana yang dituju.
Ada juga penggunaan yang sangat menarik dari OP_CTV ini: "saluran pembayaran satu arah yang tersembunyi tetapi tidak terungkap". Misalkan Alice membentuk kumpulan dana seperti itu dan menjamin bahwa dana tersebut dapat ditarik tanpa kepercayaan ke dalam output dengan skrip berikut:
atau, Alice dan Bob menghabiskannya bersama
atau, setelah beberapa saat, Alice bisa menghabiskannya sendiri
Jika Alice tidak mengungkapkannya kepada Bob, Bob tidak akan tahu bahwa keluaran seperti itu ada; Setelah Alice mengungkapkannya kepada Bob, Bob dapat menggunakan output sebagai saluran pembayaran satu arah yang sensitif terhadap waktu yang dapat digunakan Alice untuk membayar Bob segera tanpa harus menunggu konfirmasi dari blockchain. Bob hanya meminta Alice untuk menempatkan transaksi komitmennya secara on-chain sebelum Alice dapat membelanjakannya sendiri.
(b) OP_Vault dan aman
OP_VAULT adalah proposal untuk klausa restriktif yang dirancang khusus untuk membangun "brankas".
Kontrak Vault dirancang untuk menjadi bentuk hak asuh mandiri yang lebih aman dan canggih. Meskipun kontrak multi-tanda tangan saat ini dapat menghindari satu titik kegagalan untuk satu kunci pribadi, jika penyerang mendapatkan jumlah ambang batas kunci pribadi, pemilik dompet tidak berdaya. Vault ingin memberlakukan batas pengeluaran tunggal untuk dana Anda; Pada saat yang sama, ketika menarik uang darinya menggunakan rute reguler, operasi penarikan akan memberlakukan masa tunggu; Dan selama masa tunggu, operasi penarikan dapat terganggu oleh operasi pemulihan darurat dompet. Bahkan jika kontrak semacam itu dilanggar, pemilik dompet dapat memulai operasi balasan (menggunakan cabang pemulihan darurat).
Secara teoritis, OP_CTV juga dapat memprogram kontrak semacam itu, tetapi ada banyak ketidaknyamanan, salah satunya adalah komisi: saat melakukan transaksi, ia juga menjanjikan biaya yang akan dibayar transaksi. Mengingat tujuan kontrak ini, interval waktu antara pengaturan kontrak dan penarikan uang harus sangat lama, sehingga hampir tidak mungkin untuk memprediksi komisi yang sesuai. Meskipun OP_CTV tidak membatasi input, sehingga biaya dapat ditingkatkan dengan meningkatkan input, input yang diberikan semuanya akan menjadi komisi, jadi tidak realistis; Cara lain adalah CPFP, yaitu memberikan komisi atas transaksi baru dengan membelanjakan dana yang ditarik. Selain itu, penggunaan OP_CTV berarti bahwa kontrak Vault semacam itu tidak dapat ditarik secara massal (dan tentu saja tidak dapat dipulihkan secara massal).
Proposal OP_VAULT mencoba untuk mengatasi masalah ini dengan mengusulkan opcode baru (OP_VAULT dan OP_UNVAULT). OP_UNVAULT dirancang untuk ketahanan batch, jadi kami tidak akan menyebutkannya untuk saat ini. OP_VAULT berperilaku seperti ini: ketika kita meletakkannya di cabang pohon skrip, itu dapat digunakan untuk berkomitmen pada opcode yang dapat digunakan (misalnya OP_CTV) tanpa parameter tertentu; Saat membelanjakan cabang ini, transaksi dapat diteruskan dalam parameter tertentu, tetapi tidak cabang lain. Akibatnya, tidak perlu menetapkan biaya yang telah ditetapkan, dan dapat diatur ketika cabang dibelanjakan; Dengan asumsi bahwa cabang juga memiliki timelock, maka itu akan memberlakukan timelock; Akhirnya, karena Anda hanya dapat mengubah cabang tempat Anda berada, dan tidak ada cabang lain dari pohon skrip baru (termasuk cabang pemulihan darurat) yang akan diubah, kami diizinkan untuk menghentikan penarikan tersebut.
Selain itu, dua poin layak disebutkan: (1) OP_VAULT opcode berperilaku serupa dengan proposal pembatasan lain: OP_TLUV; Jeremy Rubin dengan tepat menunjukkan bahwa ini telah memunculkan konsep "komputasi" sampai batas tertentu: OP_TLUV/OP_VAULT pertama-tama menjanjikan opcode untuk memungkinkan konsumen memperbarui seluruh daun pohon skrip dengan meneruskan parameter ke opcode dengan transaksi baru; Ini bukan lagi tentang "memvalidasi data yang masuk berdasarkan kriteria tertentu", ini tentang "menghasilkan data baru yang bermakna berdasarkan data yang masuk", meskipun perhitungan yang dapat diaktifkan terbatas.
(2) Proposal OP_VAULT lengkap juga memanfaatkan beberapa proposal tentang kebijakan mempool (misalnya, transaksi v3) untuk mencapai hasil yang lebih baik. Ini mengingatkan kita bahwa arti "pemrograman" bisa lebih luas dari yang kita pikirkan. (Contoh serupa adalah Transaksi Terbuka di Jaringan Nervos.) ）
V. Pengertian CKB
Dalam dua bagian di atas, kami menjelaskan bagaimana kami dapat membuat skrip aplikasi yang menarik pada struktur yang lebih terbatas (Bitcoin UTXO); Proposal untuk mencoba menambahkan introspeksi pada struktur seperti itu juga disajikan.
Meskipun UTXO memiliki kemampuan untuk memprogram aplikasi ini, mudah bagi pembaca untuk melihat kekurangan atau area mereka yang dapat dioptimalkan, seperti:
Dalam LN-Punishment, peserta saluran harus menyimpan setiap transaksi yang dilakukan di masa lalu dan nilai rahasia penalti yang sesuai untuk menangani penipuan lawan, yang merupakan beban penyimpanan. Jika ada mekanisme yang memastikan bahwa hanya transaksi komitmen terbaru yang akan berlaku, dan transaksi komitmen lama tidak, itu dapat menghilangkan beban ini, dan juga dapat menghilangkan masalah node yang secara tidak sengaja dihukum karena secara keliru menempatkan transaksi komitmen lama secara on-chain.
Dalam DLC, diasumsikan bahwa ada banyak kemungkinan hasil dari acara tersebut, dan ada banyak tanda tangan yang harus dihasilkan oleh kedua belah pihak dan diserahkan satu sama lain terlebih dahulu, yang juga merupakan beban besar; Selain itu, pendapatan kontrak DLC terikat langsung ke kunci publik, sehingga posisinya tidak mudah untuk ditransfer, apakah ada cara untuk mentransfer posisi kontrak?
Faktanya, komunitas Bitcoin telah menemukan jawaban atas pertanyaan-pertanyaan ini, pada dasarnya terkait dengan proposal Sighash (BIP-118 AnyPrevOut).
Namun, jika kita memprogram di CKB, BIP-118 akan tersedia sekarang (tag Sighash seperti itu dapat disimulasikan dengan kemampuan untuk memverifikasi tanda tangan secara introspektif dan sengaja).
Dengan belajar memprogram Bitcoin, kita tidak hanya tahu bagaimana mereka dapat diprogram dalam format "Output Transaksi" (apa yang dapat diprogram dalam CKB), tetapi juga bagaimana meningkatkan aplikasi ini (dan bagaimana kita dapat menggunakan kemampuan CKB untuk meningkatkannya jika kita memprogramnya di CKB). Bagi developer CKB, pemrograman berbasis Bitcoin Script dapat digunakan sebagai bahan pembelajaran, atau bahkan jalan pintas.
Di bawah ini, mari kita menganalisis programabilitas setiap modul pemrograman CKB satu per satu. Mari kita tidak mempertimbangkan introspeksi untuk saat ini.
(1) Kunci yang dapat dihitung secara sewenang-wenang yang dapat diprogram
Seperti disebutkan di atas, UTXO tidak dapat diprogram untuk menghitung secara sewenang-wenang. Lock, di sisi lain, berarti Lock dapat memprogram semuanya (sebelum penyebaran pembatasan) berdasarkan UTXO, termasuk tetapi tidak terbatas pada Lightning Channel dan DLC yang disebutkan di atas.
Selain itu, kemampuan untuk memverifikasi perhitungan sewenang-wenang ini juga membuat Lock lebih fleksibel daripada UTXO dalam hal metode otentikasi. Misalnya, kita dapat mengimplementasikan saluran petir pada CKB di mana satu pihak menandatangani ECDSA dan pihak lain menggunakan RSA.
Sebenarnya, ini adalah salah satu area pertama yang mulai dijelajahi orang di CKB: menggunakan kemampuan otentikasi fleksibel ini dalam hak asuh diri pengguna untuk memungkinkan apa yang dikenal sebagai "abstraksi akun" – otorisasi validitas transaksi dan pemulihan kontrol sangat fleksibel dan hampir tidak terbatas. Pada prinsipnya, ini adalah kombinasi dari "beberapa cabang pengeluaran" dan "metode otentikasi sewenang-wenang". Contoh implementasi adalah: joyid wallet, UniPass.
Selain itu, Lock dapat mengimplementasikan proposal eltoo, memungkinkan saluran kilat yang hanya perlu menyimpan transaksi komitmen terbaru (pada kenyataannya, eltoo dapat menyederhanakan semua kontrak peer-to-peer).
(2) Jenis yang dapat diprogram dihitung secara sewenang-wenang
Seperti disebutkan di atas, salah satu kegunaan besar Type adalah untuk memprogram UDT. Dikombinasikan dengan Lock, ini berarti kita dapat mengimplementasikan saluran petir berbasis UDT (dan jenis kontrak lainnya).
Faktanya, pemisahan antara Lock dan Type dapat dilihat sebagai peningkatan keamanan: Lock berfokus pada penerapan metode penahanan atau perjanjian kontrak, sementara Type berfokus pada mendefinisikan UDT.
Selain itu, kemampuan untuk memulai pemeriksaan berdasarkan definisi UDT juga memungkinkan UDT untuk berpartisipasi dalam kontrak dengan cara yang mirip dengan CKB (UDT adalah warga negara kelas satu).
Misalnya, penulis pernah mengusulkan protokol untuk menerapkan pinjaman yang didukung NFT tanpa kepercayaan pada Bitcoin. Kunci dari protokol semacam itu adalah transaksi berkomitmen di mana nilai input kurang dari nilai output (jadi ini belum merupakan transaksi yang valid), tetapi setelah input yang cukup dapat diberikan untuk transaksi, itu adalah transaksi yang valid: setelah pemberi pinjaman mampu membayar, pemberi pinjaman tidak dapat mengambil NFT yang dipertaruhkan untuk dirinya sendiri. Namun, ketidakpercayaan transaksi komitmen ini didasarkan pada transaksi yang memeriksa jumlah input dan output, sehingga pemberi pinjaman hanya dapat menggunakan Bitcoin untuk membayar kembali pinjaman - bahkan jika pemberi pinjaman dan pemberi pinjaman bersedia menerima mata uang lain (seperti USDT yang diterbitkan berdasarkan protokol RGB), transaksi komitmen Bitcoin tidak menjamin bahwa pemberi pinjaman akan mendapatkan NFT mereka kembali selama pemberi pinjaman mengembalikan jumlah penuh USDT, karena transaksi Bitcoin tidak tahu status USDT! (Revisi: Dengan kata lain, tidak mungkin untuk membangun transaksi yang dilakukan tergantung pada pembayaran USDT.) ）
Jika kami dapat memulai pemeriksaan berdasarkan definisi UDT, kami akan dapat meminta pemberi pinjaman untuk menandatangani transaksi berkomitmen lain yang akan memungkinkan pemberi pinjaman menggunakan USDT untuk membayar kembali pinjaman. Transaksi akan memeriksa jumlah USDT yang dimasukkan dan jumlah USDT yang keluar, memberi pengguna pembayaran tanpa kepercayaan dengan USDT.
Amandemen: Dengan asumsi bahwa NFT yang digunakan sebagai jaminan dan token yang digunakan untuk pembayaran dikeluarkan menggunakan protokol yang sama (seperti RGB), maka masalah di sini dapat diselesaikan, dan kita dapat membangun transaksi komitmen sesuai dengan protokol RGB, sehingga transisi status dan pembayaran NFT dapat terjadi secara bersamaan (dua transisi status terikat dengan transaksi dalam protokol RGB). Namun, karena transaksi RGB juga mengandalkan transaksi Bitcoin, pembangunan transaksi komitmen di sini akan terbilang sulit. Secara keseluruhan, meskipun masalahnya bisa diselesaikan, itu tidak bisa dilakukan Token adalah warga negara kelas satu.
Selanjutnya, mari kita pertimbangkan introspeksi.
(3) Kunci membaca kunci lain
Ini berarti berbagai kemungkinan pemrograman pada Bitcoin UTXO setelah pembatasan yang diusulkan diterapkan. Ini termasuk kontrak Vault yang disebutkan di atas, serta aplikasi berbasis OP _CTV (misalnya, kontrol kemacetan).
XueJie pernah menyebutkan contoh yang sangat menarik: Anda dapat menerapkan sel akun koleksi di CKB, ketika menggunakan sel semacam ini sebagai input transaksi, jika sel output (sel yang menggunakan kunci yang sama) memiliki kapasitas lebih, maka input tidak perlu memberikan tanda tangan dan tidak mempengaruhi validitas transaksi. Bahkan, sel semacam ini tidak akan mungkin terjadi tanpa kemampuan untuk introspeksi. Sel akun koleksi ini sangat ideal sebagai metode institusional untuk menerima uang karena mengumpulkan dana dan memiliki kelemahan karena tidak memiliki rasa privasi yang baik.
(4) Kunci membaca tipe lain (dan data)
Aplikasi menarik dari kemampuan ini adalah token taruhan. Lock akan memutuskan apakah dapat menggunakan kapasitasnya sendiri berdasarkan jumlah token di input lain, dan di mana ia dapat dihabiskan (membutuhkan kemampuan untuk introspeksi kunci).
(5) Tipe membaca kunci lain
Tidak yakin, tetapi dapat diasumsikan berguna. Misalnya, Anda dapat memeriksa Jenis bahwa Kunci input dan output transaksi tetap tidak berubah.
(6) Tipe Scirpt membaca tipe lain (dan data)
Kartu perdagangan? Kumpulkan n token dengan imbalan token yang lebih besar :)
VI. Kesimpulan
Dibandingkan dengan sistem kontrak pintar sebelumnya yang dapat diprogram dengan perhitungan sewenang-wenang, seperti Ethereum, Jaringan Nervos mengambil struktur yang berbeda; Akibatnya, seringkali sulit untuk memahami Jaringan Nervos berdasarkan pengetahuan tentang sistem kontrak pintar di masa lalu. Tulisan ini mengusulkan metode untuk memahami programabilitas CKB Cell, dimulai dari pemrograman aplikasi struktur yang lebih terbatas daripada CKB Cell, BTC UTXO. Dan, dengan menggunakan konsep "introspeksi" untuk memahami kemampuan "akses lintas-kontrak" sel, kita dapat membagi situasi di mana kemampuan introspektif digunakan dan menentukan penggunaan spesifiknya.
Recension:
Terlepas dari kemampuan akses silang Sel (yaitu, kemampuan introspeksi), kunci dapat dianggap sebagai Bitcoin dengan kemampuan status dan pemrograman yang telah mencapai ekstrem, sehingga semua aplikasi berbasis Bitcoin dapat diprogram atas dasar ini saja;
Terlepas dari kemampuan akses silang (yaitu, kemampuan introspeksi) sel, perbedaan antara kunci dan jenis dapat dianggap sebagai peningkatan keamanan: ini memisahkan definisi aset dan metode penahanan UDT; Selain itu, tipe s (dan data) dari negara yang dapat diekspos mencapai efek UDT adalah warga negara kelas satu.
Dua poin di atas berarti sesuatu dengan paradigma yang sama dengan "BTC + RGB" tetapi dengan lebih banyak kemampuan pemrograman;
Mempertimbangkan kemampuan introspektif Cell, Cell bisa mendapatkan kemampuan pemrograman yang lebih kuat daripada post-covenants BTC UTXO dan mengimplementasikan sesuatu yang sulit dicapai dengan BTC + RGB (karena BTC tidak dapat membaca keadaan RGB)
Tidak banyak contoh spesifik dari penggunaan ini, tetapi ini disebabkan oleh kurangnya pemahaman penulis tentang ekologi CKB. Seiring waktu, diyakini bahwa semakin banyak imajinasi akan diinvestasikan di dalamnya, dan aplikasi yang tidak terbayangkan saat ini akan disatukan.
Ucapan terima kasih
Terima kasih kepada Retric, Jan Xie dan Xue Jie atas umpan balik mereka selama penulisan artikel. Tentu saja, saya bertanggung jawab atas semua kesalahan dalam teks.
Referensi
Akun, Daftar Akses Ketat, dan UTXO
Pembatasan dalam Bitcoin: Taksonomi untuk ditinjau
Model Sel
Nervos CKB Singkatnya
Programabilitas Bitcoin
Abstraksi On Account (2022)
Apa itu Pohon Sintaks Abstrak Merkelized Bitcoin?
BIP 345: Proposal OP_VAULT
Pengantar opcode pembatasan TLUV
Komponen yang membangun kontrak ditingkatkan dengan Bitcoin
Eltoo menjelaskan
Kontrak Pinjaman Aman NFT Berdasarkan Transaksi yang Berkomitmen · btc-studi/OP_QUESTION · Diskusi #7
Link ke artikel asli
Lihat Asli
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.
Memahami programabilitas CKB dari pemrograman aplikasi Bitcoin
Penulis asli: Ajian
Ringkasan
Memahami programabilitas suatu sistem mengharuskan kita untuk mengidentifikasi fitur struktural sistem. Eksplorasi pemrograman aplikasi berbasis Bitcoin Script membantu kita memahami struktur dasar CKB Cell dan paradigma pemrogramannya. Tidak hanya itu, tetapi juga memecah komponen pemrograman CKB menjadi bagian-bagian yang tepat dan membantu kita memahami keuntungan programabilitas yang dibawa oleh setiap bagian.
I. Pendahuluan
"Programabilitas" adalah dimensi yang sering diambil orang ketika membandingkan sistem blockchain. Namun, sering ada ketidaksepakatan tentang bagaimana programabilitas dijelaskan. Ungkapan umum adalah "XX blockchain mendukung bahasa pemrograman Turing-complete", atau, "XX blockchain mendukung pemrograman tujuan umum", yang dimaksudkan untuk menunjukkan bahwa "XX blockchain" di sini memiliki programabilitas yang kuat. Ada beberapa kebenaran implikasi dari pernyataan ini: sistem yang mendukung pemrograman Turing-complete umumnya lebih mudah diprogram daripada yang tidak. Namun, ada banyak aspek pada karakteristik struktural dari sistem kontrak pintar, dan pernyataan ini hanya menyentuh salah satunya, sehingga tidak cukup untuk dipahami secara cukup mendalam berdasarkan fakta bahwa pengembang tidak dipandu olehnya, dan pengguna biasa tidak dapat diandalkan untuk membedakan penipuan.
Fitur struktural dari sistem kontrak pintar meliputi:
Oleh karena itu, selain "perhitungan sewenang-wenang yang dapat diprogram", setidaknya ada empat karakteristik yang memengaruhi kemampuan pemrograman sistem kontrak pintar. Bahkan dapat dikatakan bahwa fitur-fitur lain ini lebih penting, karena mereka menentukan pada tingkat yang lebih dalam apa yang mudah dicapai dan apa yang sulit dicapai; Apa implementasi yang lebih ekonomis dan apa implementasi yang kurang efisien.
Misalnya, Ethereum sering dikutip sebagai contoh programabilitas yang baik, tetapi bentuk dasar ekspresi negara pada Ethereum adalah akun, yang membuatnya sulit untuk memprogram kontrak peer-to-peer (misalnya, gateway pembayaran, kontrak taruhan satu-ke-satu) – tidak sepenuhnya mustahil, hanya tanpa pamrih. Bukan hal yang aneh bagi ekosistem Ethereum untuk mencoba menerapkan saluran pembayaran / saluran negara, dan ada banyak diskusi teoretis, tetapi proyek-proyek ini tampaknya tidak aktif lagi – dan ini jelas tidak dapat disalahkan pada kurangnya upaya dari pihak pengembang. Bukan kebetulan bahwa proyek yang aktif di Ethereum saat ini mengambil bentuk "kumpulan" daripada "kontrak peer-to-peer". Demikian pula, orang mungkin senang dengan programabilitas Ethereum, tetapi model akun secara inheren kurang dalam mencapai "abstraksi akun" (yang juga dapat dipahami sebagai generalisasi konsep dompet).
Dengan cara yang sama, mengeksplorasi programabilitas CKB juga mengharuskan kita untuk memahami karakteristik struktural sistem kontrak pintar CKB dalam aspek-aspek ini. Apa yang sudah kita ketahui adalah bahwa CKB memungkinkan perhitungan sewenang-wenang untuk diprogram, memungkinkan keadaan tambahan dicatat dalam kontrak, dan memungkinkan satu kontrak untuk mengakses keadaan kontrak lain ketika dieksekusi. Namun, bentuk kontrak adalah output dari transaksi (disebut "sel"), yang membuatnya secara fundamental berbeda dari Ethereum. Oleh karena itu, pemahaman tentang sistem kontrak pintar Ethereum dan contoh kontrak di dalamnya tidak membantu kami memahami bagaimana CKB mengimplementasikan fitur-fitur struktural ini, juga tidak membantu kami memahami programabilitas CKB.
Untungnya, kontrak pintar pada Bitcoin tampaknya memberikan dasar terbaik untuk memahami programabilitas CKB. Ini bukan hanya karena bentuk dasar representasi negara Bitcoin juga merupakan output dari transaksi (disebut "UTXO"), tetapi juga karena, dengan bantuan konsep yang diusulkan oleh komunitas Bitcoin yang disebut "perjanjian", kita dapat memahami mengapa CKB memiliki karakteristik struktural ini, dan secara tepat memecah efek akhir menjadi beberapa bagian, mengidentifikasi keuntungan programabilitas yang dibawa masing-masing.
II. CKB v.s. BTC: Terlebih Lagi?
(1) Struktur dasar
Sebagai bentuk dasar representasi negara Bitcoin, UTXO Bitcoin ("Unspent Transaction Output") memiliki dua bidang:
Dibandingkan dengan sistem kontrak pintar yang datang kemudian, Bitcoin Script sangat terbatas:
Scripting semacam ini, meskipun terbatas, tidak kekurangan kemampuan untuk memprogram aplikasi yang luar biasa, dan ini adalah dasar dari eksplorasi kami tentang programabilitas CKB. Akan ada bagian nanti yang akan memperkenalkan dua contoh pemrograman Bitcoin Script.
Sebaliknya, unit status CKB disebut "sel" dan memiliki empat bidang:
Selain itu, Kunci dan Tipe dapat diprogram untuk perhitungan sewenang-wenang. Anda dapat memprogram algoritma verifikasi tanda tangan apa pun, Anda dapat memprogram algoritme hash apa pun untuk pemeriksaan preimage, dan sebagainya.
Sangat mudah bagi pembaca untuk melihat bagaimana programabilitas Cell meningkat dibandingkan UTXOs:
Dikombinasikan dengan struktur "output transaksi" dari sel itu sendiri, manfaat dari kedua poin ini sendiri sangat, sangat signifikan, tetapi dari uraian di atas saja, kita tidak tahu bagaimana sel mencapai "satu kontrak mengakses keadaan kontrak lain saat runtime". Untuk melakukan ini, kita perlu menggambar konsep yang telah lama dibahas di komunitas Bitcoin: "perjanjian".
(2) Keterbatasan dan introspeksi
Tujuan awal dari klausul pembatasan adalah untuk membatasi di mana sejumlah uang dapat dibelanjakan. Pada Bitcoin saat ini (di mana tidak ada batasan yang diusulkan), sejumlah uang, setelah dibuka, dapat dihabiskan di mana saja (dapat dibayarkan ke kunci publik skrip arbitrer). Tetapi gagasan tentang klausa pembatasan adalah bahwa itu dapat dihabiskan dengan cara yang membatasinya ke tempat-tempat tertentu, misalnya, UTXO tertentu hanya akan dihabiskan oleh transaksi tertentu, sehingga bahkan jika seseorang dapat memberikan tanda tangan untuk UTXO, di mana itu dapat dibelanjakan telah ditentukan oleh transaksi itu. Ini mungkin tampak agak aneh, tetapi dapat menyebabkan beberapa aplikasi menarik, yang akan dibahas dalam bagian nanti. Yang penting, ini adalah kunci untuk pemahaman lebih lanjut kami tentang programabilitas CKB.
Rusty Russell dengan tepat menunjukkan bahwa pembatasan dapat dipahami sebagai kemampuan "introspeksi" untuk berdagang, yaitu, ketika UTXO A dihabiskan oleh transaksi B, operator skrip dapat membaca beberapa (atau semua) transaksi B dan kemudian memeriksa apakah mereka cocok dengan parameter yang diminta sebelumnya oleh skrip. Misalnya, apakah kunci publik skrip untuk output pertama transaksi A cocok dengan apa yang diperlukan oleh kunci publik skrip UTXO A (inilah yang awalnya dimaksud dengan pembatasan).
Pembaca yang cerdik akan menyadari bahwa dengan introspeksi penuh, input dari satu transaksi dapat membaca keadaan input lain dari transaksi yang sama, yang memungkinkan kemampuan satu kontrak untuk mengakses keadaan kontrak lain saat runtime. Faktanya, begitulah CKB Cell dirancang.
Berdasarkan ini, kita dapat membagi kapasitas introspektif lengkap ini menjadi empat skenario:
Hal ini memungkinkan kita untuk menganalisis peran kemampuan introspektif masing-masing bagian dalam kasus penggunaan yang berbeda di bawah asumsi tertentu (pembagian fungsi antara Kunci dan Jenis), yaitu, keuntungan programabilitas yang dibawa setiap bagian kepada kita.
Dalam dua bagian berikut, kita akan melihat pemrograman Bitcoin Script saat ini (dan belum diusulkan), dan kemungkinan fungsionalitas yang diharapkan dapat dicapai oleh pembatasan yang diusulkan, sehingga dapat memberikan pemahaman konkret tentang bagaimana CKB Cell dapat diprogram dan dilakukan dengan lebih baik.
III. Pemrograman Skrip Bitcoin
Di bagian ini, kita akan menggunakan "Lightning Channel / Lightning Network" dan "Caution Journal Contract (DLC)" sebagai contoh pemrograman aplikasi berdasarkan Bitcoin Script. Sebelum kita membahasnya, mari kita bahas dua hal ke dalamnya.
(1) OP_IF dan "Penawaran Komitmen"
Konsep pertama adalah flow control opcode di Bitcoin Script, seperti: OP_IF, OP_ELSE. Opcode ini tidak berbeda dengan IF dalam pemrograman komputer, dan tujuannya adalah untuk mengeksekusi pernyataan yang berbeda berdasarkan input yang berbeda. Dalam konteks Bitcoin Script, ini berarti kita dapat mengatur beberapa jalur membuka kunci untuk dana; Dikombinasikan dengan fitur timelock, ini berarti kita dapat menetapkan prioritas pada tindakan.
Ambil "Hash Timelock Contract (HTLC)" yang terkenal sebagai contoh, yang diterjemahkan ke dalam bahasa sehari-hari:
Ini "atau ... atau ..." Efeknya dicapai melalui opcode kontrol proses.
Keuntungan paling menonjol dari HTLC > adalah dapat menggabungkan beberapa operasi bersama-sama dan mengatomisasinya. Misalnya, jika Alice ingin menukar BTC dengan CKB dengan Bob, maka Bob dapat terlebih dahulu memberikan nilai hash dan membuat HTLC di Jaringan Nervos. Alice kemudian membuat HTLC pada Bitcoin yang menggunakan hash yang sama. Atau, Bob mengambil BTC yang dibayarkan oleh Alice di Bitcoin, sementara juga mengungkapkan preimage, memungkinkan Alice untuk menarik CKB di Jaringan Nervos. Either way, Bob tidak mengungkapkan gambar aslinya, kedua kontrak berakhir, dan Alice dan Bob bisa mendapatkan kembali uang yang mereka investasikan.
Setelah aktivasi garpu lunak Taproot, fitur jalur multi-buka kunci ini semakin ditingkatkan dengan pengenalan MAST (Merkle Abstract Syntax Tree): kita dapat mengubah jalur buka kunci menjadi daun di pohon Merkle, setiap daun independen, jadi tidak perlu lagi menggunakan opcode kontrol aliran seperti itu; Juga, karena satu jalur terungkap tanpa mengekspos yang lain, kita dapat menambahkan sejumlah besar jalur buka kunci ke output tanpa harus khawatir tentang ekonomi.
Konsep kedua adalah "perdagangan komitmen". Ide dari transaksi yang dilakukan adalah bahwa, dalam beberapa kasus, transaksi Bitcoin yang valid, bahkan jika tidak dikonfirmasi oleh blockchain, sama nyata dan mengikatnya.
Misalnya, Alice dan Bob berbagi UTXO yang mengharuskan keduanya ditandatangani untuk dibelanjakan. Pada titik ini, Alice membangun transaksi untuk membelanjakannya, mentransfer 60% nilainya ke Bob dan sisanya untuk dirinya sendiri; Alice memberikan tanda tangannya sendiri untuk transaksi, yang kemudian dikirim ke Bob. Nah, bagi Bob, itu tidak harus disiarkan ke jaringan Bitcoin, dan tidak harus dikonfirmasi oleh blockchain, dan efek pembayaran dari transaksi ini juga nyata dan kredibel. Karena Alice tidak dapat membelanjakan UTXO sendiri (dan karenanya tidak dapat membelanjakannya berulang kali), dan karena tanda tangan yang diberikan oleh Alice valid, Bob selalu dapat menambahkan tanda tangannya dan menyiarkan transaksi untuk menghormati pembayaran. Dengan kata lain, Alice memberi Bob "komitmen yang kredibel" melalui transaksi (off-chain) yang valid ini.
Transaksi berkomitmen adalah konsep inti dari pemrograman aplikasi Bitcoin. Seperti disebutkan sebelumnya, kontrak Bitcoin berbasis verifikasi, tanpa kewarganegaraan, dan tidak mengizinkan akses silang; Namun, jika kontrak tidak membawa negara, di mana negara-negara disimpan, dan bagaimana kontrak dapat dengan aman bergerak maju (mengubah negara)? Transaksi komitmen memberikan jawaban langsung: keadaan kontrak dapat dinyatakan dalam bentuk transaksi, sehingga peserta kontrak dapat menyelamatkan negara sendiri tanpa harus menampilkannya di blockchain; Masalah mengubah keadaan kontrak juga dapat diubah menjadi masalah bagaimana memperbarui transaksi yang dilakukan dengan aman; Selain itu, jika kita khawatir tentang bahaya memasuki kontrak (misalnya, memasukkan kontrak yang mengharuskan kedua belah pihak untuk menandatangani untuk membelanjakan, dan ada risiko bahwa pihak lain tidak akan merespons dan terjebak), maka hanya menghasilkan transaksi komitmen yang membebani kontrak di muka dan mendapatkan tanda tangan dapat mengurangi risiko dan menghilangkan kepercayaan pada peserta lain.
(2) Saluran petir dan jaringan petir
Saluran kilat adalah kontrak satu-ke-satu di mana dua pihak dapat saling membayar dalam jumlah tak terbatas tanpa satu pembayaran pun yang dikonfirmasi oleh blockchain. Seperti yang Anda duga, ia menggunakan perdagangan komitmen.
Di bagian yang menjelaskan "Transaksi yang Dilakukan", kami telah memperkenalkan saluran pembayaran. Namun, kontrak semacam ini, yang hanya memanfaatkan 2-dari-2 multisig, hanya dapat memungkinkan pembayaran satu arah. Artinya, Alice selalu membayar Bob, atau Bob selalu membayar Alice sampai dia menghabiskan saldonya dalam kontrak. Jika itu adalah pembayaran dua arah, itu berarti bahwa setelah pembaruan status, satu pihak mungkin memiliki saldo lebih sedikit dari sebelumnya, tetapi TA memiliki transaksi komitmen terakhir yang ditandatangani oleh pihak lain - apa yang dapat dilakukan untuk menghentikan TA dari menyiarkan janji lama dan TA hanya dari transaksi komitmen terbaru?
Solusi untuk masalah ini dengan saluran petir disebut "LN-Penalty". Sekarang, katakanlah Alice dan Bob masing-masing memiliki 5 BTC dalam satu saluran; Sekarang Alice ingin membayar Bob 1 BTC, jadi dia menandatangani transaksi yang dijanjikan dan mengirimkannya ke Bob:
Bob juga menandatangani komitmen (yang sesuai dengan transaksi di atas) dan mengirimkannya ke Alice:
Triknya di sini terletak pada "kunci publik sementara bersama" ini, yang dihasilkan menggunakan salah satu kunci publiknya sendiri dan kunci publik yang disediakan oleh pihak lain, misalnya, kunci publik sementara bersama Alice-Bob, yang diperoleh Alice menggunakan salah satu kunci publiknya sendiri dan kunci publik yang disediakan oleh Bob, mengalikan masing-masing dengan nilai hash. Ketika kunci publik seperti itu dibuat, tidak ada yang tahu kunci pribadinya. Namun, jika Bob memberi tahu Alice kunci pribadi dari kunci publik yang dia berikan, Alice dapat menghitung kunci pribadi dari kunci publik sementara federasi. - Ini adalah kunci fakta bahwa Saluran Petir dapat "membatalkan" keadaan lama.
Lain kali kedua pihak ingin memperbarui status saluran (memulai pembayaran), kedua pihak bertukar kunci pribadi dari kunci publik sementara yang diberikan satu sama lain di babak sebelumnya. Dengan cara ini, peserta tidak lagi berani menyiarkan transaksi terakhir yang dijanjikan yang mereka terima: output dari transaksi yang dijanjikan ini memberikan nilai kepada pihak mereka sendiri memiliki dua jalur, dan kunci pribadi dari jalur kunci publik sementara sudah diketahui pihak lain; Jadi begitu transaksi komitmen lama disiarkan, pihak lain dapat segera menggunakan kunci pribadi sementara bersama ini untuk mengambil semua dana dalam output ini. - Inilah arti "LN-Penalty".
Secara khusus, urutan interaksi adalah sebagai berikut: pihak yang memulai pembayaran pertama-tama meminta kunci publik sementara baru dari pihak lain, dan kemudian membangun transaksi komitmen baru dan menyerahkannya kepada pihak lain; Pihak yang mendapat transaksi yang dijanjikan mengungkapkan kepada pihak lain kunci pribadi dari kunci publik sementara yang dia berikan di babak sebelumnya. Urutan interaksi ini memastikan bahwa peserta selalu mendapatkan transaksi komitmen baru sebelum membatalkan transaksi komitmen yang mereka terima di putaran sebelumnya, dan karenanya tidak dapat dipercaya.
Singkatnya, desain utama saluran petir adalah:
Akhirnya, karena HTLC juga dapat ditempatkan dalam transaksi yang berkomitmen, saluran Lightning juga dapat meneruskan pembayaran. Dengan asumsi bahwa Alice dapat menemukan jalur yang terdiri dari saluran petir yang menghubungkan sebelum dan sesudah untuk mencapai Daniel, maka pembayaran multi-hop tanpa kepercayaan dapat dicapai tanpa membuka saluran dengan Daniel. Ini adalah Jaringan Petir:
Ketika Alice menemukan jalan seperti itu dan ingin membayar Daniel, dia meminta Daniel untuk hash untuk membangun HTLC untuk Bob, dan meminta Bob untuk meneruskan pesan ke Carol dan memberikan HTLC yang sama; Pesan tersebut meminta Carol untuk meneruskan pesan tersebut kepada Daniel dan memberikan HTLC yang sama. Ketika berita itu sampai ke Daniel, dia mengungkapkan preimage kepada Carol, yang memberinya nilai HTLC dan memperbarui keadaan kontrak. Carol melakukan hal yang sama, dibayar oleh Bob dan memperbarui status saluran; Akhirnya, Bob mengungkapkan preimage kepada Alice dan memperbarui statusnya. Karena sifat HTLC, rantai pembayaran ini berhasil atau gagal bersama, dan dengan demikian, tidak dapat dipercaya.
Jaringan Petir terdiri dari satu saluran demi saluran, yang masing-masing tidak bergantung satu sama lain. Ini berarti Alice hanya perlu mengetahui apa yang terjadi di salurannya dengan Bob, terlepas dari berapa banyak interaksi yang telah terjadi di saluran orang lain, mata uang apa yang digunakan interaksi tersebut, atau bahkan apakah mereka benar-benar menggunakan saluran tersebut.
Skalabilitas Jaringan Petir tidak hanya tercermin dalam kenyataan bahwa kecepatan pembayaran dalam Saluran Petir hanya dibatasi oleh investasi sumber daya perangkat keras oleh kedua belah pihak, tetapi juga karena penyimpanan negara yang terdesentralisasi, satu node dapat memanfaatkan leverage maksimum dengan biaya terendah.
(3) Hati-hati dengan kontrak jurnal
Cautionary Journaling Contract (DLC) menggunakan teknik kriptografi yang disebut "tanda tangan adaptor" yang memungkinkan Bitcoin Script memprogram kontrak keuangan yang bergantung pada peristiwa eksternal.
Tanda tangan adaptor memungkinkan tanda tangan menjadi tanda tangan yang valid hanya setelah kunci privat ditambahkan. Ambil contoh tanda tangan Schnorr, di mana bentuk standar tanda tangan Schnorr adalah (R, s), di mana:
Katakanlah saya memberikan sepasang data (R, s') di mana:
Jelas, ini bukan tanda tangan Schnorr yang valid, dan tidak lulus rumus validasi, tetapi saya dapat membuktikan kepada verifikator bahwa itu bisa menjadi tanda tangan yang valid hanya dengan mengetahui kunci pribadi R 2, r 2:
Tanda tangan adaptor membuat validitas tanda tangan bergantung pada data rahasia dan dapat diverifikasi. Tapi apa hubungannya ini dengan kontrak keuangan?
Katakanlah Alice dan Bob ingin bertaruh pada hasil pertandingan bola. Alice dan Bob bertaruh pada Green Goblin dan Alina untuk menang, masing-masing, dengan taruhan 1 BTC. Selain itu, Carol, situs web ulasan sepak bola, berjanji untuk menggunakan nonce R_c untuk memposting hasil yang ditandatangani _c_i ketika hasil pertandingan diumumkan.
Seperti yang dapat dilihat, ada tiga kemungkinan hasil (jadi ada 3 kemungkinan untuk tanda tangan Carol):
Green Goblin menang, Alice memenangkan 1 BTC
Alina menang, dan Bob memenangkan 1 BTC
Tie, dana keduanya kembali dengan cara yang sama
Untuk melakukan ini, keduanya membuat kesepakatan komitmen untuk setiap hasil. Misalnya, transaksi komitmen yang mereka buat untuk hasil pertama akan terlihat seperti ini:
Namun, alih-alih (R, s), tanda tangan yang dibuat Alice dan Bob untuk transaksi ini adalah tanda tangan adaptor (R, s'); Dengan kata lain, tanda tangan yang diberikan satu sama lain oleh kedua belah pihak tidak dapat digunakan secara langsung untuk membuka kunci kontrak, tetapi harus mengungkapkan nilai rahasia. Nilai rahasia ini adalah preimage dari s_c_ 1.G, yang merupakan tanda tangan Carol! Karena nilai nonce tanda tangan Carol telah ditentukan (R_c), s_c_ 1.G dapat dibangun (s_c_ 1.G = R_c + Hash(R_c ||). 'Green Goblin menang' || PK_c) * PK_c)。
Ketika hasilnya terungkap, dengan asumsi bahwa Green Goblin menang, Carol akan mengeluarkan tanda tangan (R_c, s_c_ 1), sehingga Alice atau Bob dapat menyelesaikan tanda tangan adaptor lawan dan menambahkan tanda tangan mereka sendiri untuk membuat transaksi di atas menjadi transaksi yang valid, dan menyiarkannya ke jaringan untuk memicu efek penyelesaian. Tetapi jika Green Goblin tidak menang, Carol tidak akan memposting s_c_ 1, dan kesepakatan komitmen tidak akan menjadi kesepakatan yang valid.
Dan seterusnya, seperti juga dua perdagangan lainnya. Dengan cara ini, Alice dan Bob membuat pelaksanaan kontrak tergantung pada peristiwa eksternal (tepatnya, pada siaran mesin asertor dari peristiwa eksternal, dalam bentuk tanda tangan) tanpa harus mempercayai rekanan. Kontrak keuangan besar dan kecil, seperti futures dan opsi, dapat diimplementasikan dengan cara ini.
Dibandingkan dengan bentuk implementasi lainnya, fitur terpenting dari kontrak log yang berhati-hati adalah privasinya: (1) Alice dan Bob tidak perlu memberi tahu Carol bahwa mereka menggunakan data Carol, yang tidak mempengaruhi pelaksanaan kontrak sama sekali; (2) Pengamat on-chain (termasuk Carol) tidak akan dapat menentukan situs web mana yang mereka gunakan melalui eksekusi kontrak Alice dan Bob, atau bahkan bahwa kontrak mereka adalah kontrak taruhan (bukan saluran kilat).
IV. Pengantar Penerapan Pembatasan
(a) OP_CTV dan pengendalian kemacetan
Pengembang komunitas Bitcoin telah membuat sejumlah proposal yang dapat diklasifikasikan sebagai klausa pembatasan. Saat ini, salah satu proposal yang paling terkenal adalah OP \ _CHECKTEMPLATEVERIFY (OP \ _CTV), yang populer di kalangan komunitas Bitcoin karena kesederhanaannya tetapi fleksibilitas dengan konsepnya yang sederhana. Ide OP_CTV adalah untuk melakukan hash dalam skrip untuk membatasi bahwa dana hanya dapat dihabiskan oleh transaksi yang diwakili oleh hash ini; Hash ini menjanjikan output dari transaksi dan sebagian besar bidang, tetapi bukan input transaksi, hanya jumlah input.
"Kontrol Kemacetan" adalah contoh yang baik tentang bagaimana OP \ _CTV dapat ditunjukkan. Kasus penggunaan dasarnya adalah untuk membantu sejumlah besar pengguna keluar dari pertukaran (lingkungan yang membutuhkan kepercayaan) ke dalam kumpulan; Karena kumpulan ini menggunakan OP_CTV untuk merencanakan bagaimana pembelanjaannya di masa mendatang, ini menjamin bahwa pengguna dapat keluar dari kumpulan tanpa kepercayaan, tanpa bantuan siapa pun; Dan karena kumpulan ini hanya berperilaku sebagai UTXO, ia menghindari membayar banyak biaya ketika permintaan untuk transaksi on-chain tinggi (dari n output ke 1 output; juga dikurangi dari n transaksi menjadi 1 transaksi). Pengguna di pool dapat menunggu kesempatan untuk keluar dari pool.
Katakanlah Alice, Bob, dan Carol ingin menarik masing-masing 5 BTC, 3 BTC, dan 2 BTC dari bursa. Kemudian pertukaran dapat menghasilkan output 10 BTC dengan 3 OP \ _CTV cabang. Katakanlah Alice ingin menarik uang, dia dapat menggunakan cabang 1; Transaksi yang diwakili oleh nilai hash yang digunakan oleh OP_CTV cabang akan membentuk dua output, salah satunya adalah mengalokasikan 5 BTC ke Alice; Output lainnya, pada gilirannya, adalah kumpulan, yang juga menggunakan OP \ _CTV untuk berkomitmen pada transaksi, memungkinkan Bob untuk menarik hanya 3 BTC dan mengirim 2 BTC sisanya ke Carol.
Sama halnya jika Bob atau Carol ingin menarik uang. Saat menarik uang, mereka hanya akan dapat menggunakan transaksi yang dapat melewati cek OP_CTV yang sesuai, yaitu mereka hanya akan dapat membayar jumlah yang sesuai untuk diri mereka sendiri, dan tidak akan dapat menarik uang secara sewenang-wenang; Dana yang tersisa akan masuk ke pool dengan kunci OP_CTV, sehingga menjamin bahwa pengguna yang tersisa dapat ditempatkan di luar pool tanpa kepercayaan, terlepas dari urutan penarikannya.
Secara abstrak, peran OP \ _CTV di sini adalah untuk merencanakan jalan menuju akhir masa kontrak untuk kontrak, sehingga kontrak kumpulan di sini dapat mempertahankan atribut keluar tanpa kepercayaan tidak peduli jalan mana yang diambil atau negara mana yang dituju.
Ada juga penggunaan yang sangat menarik dari OP_CTV ini: "saluran pembayaran satu arah yang tersembunyi tetapi tidak terungkap". Misalkan Alice membentuk kumpulan dana seperti itu dan menjamin bahwa dana tersebut dapat ditarik tanpa kepercayaan ke dalam output dengan skrip berikut:
Jika Alice tidak mengungkapkannya kepada Bob, Bob tidak akan tahu bahwa keluaran seperti itu ada; Setelah Alice mengungkapkannya kepada Bob, Bob dapat menggunakan output sebagai saluran pembayaran satu arah yang sensitif terhadap waktu yang dapat digunakan Alice untuk membayar Bob segera tanpa harus menunggu konfirmasi dari blockchain. Bob hanya meminta Alice untuk menempatkan transaksi komitmennya secara on-chain sebelum Alice dapat membelanjakannya sendiri.
(b) OP_Vault dan aman
OP_VAULT adalah proposal untuk klausa restriktif yang dirancang khusus untuk membangun "brankas".
Kontrak Vault dirancang untuk menjadi bentuk hak asuh mandiri yang lebih aman dan canggih. Meskipun kontrak multi-tanda tangan saat ini dapat menghindari satu titik kegagalan untuk satu kunci pribadi, jika penyerang mendapatkan jumlah ambang batas kunci pribadi, pemilik dompet tidak berdaya. Vault ingin memberlakukan batas pengeluaran tunggal untuk dana Anda; Pada saat yang sama, ketika menarik uang darinya menggunakan rute reguler, operasi penarikan akan memberlakukan masa tunggu; Dan selama masa tunggu, operasi penarikan dapat terganggu oleh operasi pemulihan darurat dompet. Bahkan jika kontrak semacam itu dilanggar, pemilik dompet dapat memulai operasi balasan (menggunakan cabang pemulihan darurat).
Secara teoritis, OP_CTV juga dapat memprogram kontrak semacam itu, tetapi ada banyak ketidaknyamanan, salah satunya adalah komisi: saat melakukan transaksi, ia juga menjanjikan biaya yang akan dibayar transaksi. Mengingat tujuan kontrak ini, interval waktu antara pengaturan kontrak dan penarikan uang harus sangat lama, sehingga hampir tidak mungkin untuk memprediksi komisi yang sesuai. Meskipun OP_CTV tidak membatasi input, sehingga biaya dapat ditingkatkan dengan meningkatkan input, input yang diberikan semuanya akan menjadi komisi, jadi tidak realistis; Cara lain adalah CPFP, yaitu memberikan komisi atas transaksi baru dengan membelanjakan dana yang ditarik. Selain itu, penggunaan OP_CTV berarti bahwa kontrak Vault semacam itu tidak dapat ditarik secara massal (dan tentu saja tidak dapat dipulihkan secara massal).
Proposal OP_VAULT mencoba untuk mengatasi masalah ini dengan mengusulkan opcode baru (OP_VAULT dan OP_UNVAULT). OP_UNVAULT dirancang untuk ketahanan batch, jadi kami tidak akan menyebutkannya untuk saat ini. OP_VAULT berperilaku seperti ini: ketika kita meletakkannya di cabang pohon skrip, itu dapat digunakan untuk berkomitmen pada opcode yang dapat digunakan (misalnya OP_CTV) tanpa parameter tertentu; Saat membelanjakan cabang ini, transaksi dapat diteruskan dalam parameter tertentu, tetapi tidak cabang lain. Akibatnya, tidak perlu menetapkan biaya yang telah ditetapkan, dan dapat diatur ketika cabang dibelanjakan; Dengan asumsi bahwa cabang juga memiliki timelock, maka itu akan memberlakukan timelock; Akhirnya, karena Anda hanya dapat mengubah cabang tempat Anda berada, dan tidak ada cabang lain dari pohon skrip baru (termasuk cabang pemulihan darurat) yang akan diubah, kami diizinkan untuk menghentikan penarikan tersebut.
Selain itu, dua poin layak disebutkan: (1) OP_VAULT opcode berperilaku serupa dengan proposal pembatasan lain: OP_TLUV; Jeremy Rubin dengan tepat menunjukkan bahwa ini telah memunculkan konsep "komputasi" sampai batas tertentu: OP_TLUV/OP_VAULT pertama-tama menjanjikan opcode untuk memungkinkan konsumen memperbarui seluruh daun pohon skrip dengan meneruskan parameter ke opcode dengan transaksi baru; Ini bukan lagi tentang "memvalidasi data yang masuk berdasarkan kriteria tertentu", ini tentang "menghasilkan data baru yang bermakna berdasarkan data yang masuk", meskipun perhitungan yang dapat diaktifkan terbatas.
(2) Proposal OP_VAULT lengkap juga memanfaatkan beberapa proposal tentang kebijakan mempool (misalnya, transaksi v3) untuk mencapai hasil yang lebih baik. Ini mengingatkan kita bahwa arti "pemrograman" bisa lebih luas dari yang kita pikirkan. (Contoh serupa adalah Transaksi Terbuka di Jaringan Nervos.) ）
V. Pengertian CKB
Dalam dua bagian di atas, kami menjelaskan bagaimana kami dapat membuat skrip aplikasi yang menarik pada struktur yang lebih terbatas (Bitcoin UTXO); Proposal untuk mencoba menambahkan introspeksi pada struktur seperti itu juga disajikan.
Meskipun UTXO memiliki kemampuan untuk memprogram aplikasi ini, mudah bagi pembaca untuk melihat kekurangan atau area mereka yang dapat dioptimalkan, seperti:
Faktanya, komunitas Bitcoin telah menemukan jawaban atas pertanyaan-pertanyaan ini, pada dasarnya terkait dengan proposal Sighash (BIP-118 AnyPrevOut).
Namun, jika kita memprogram di CKB, BIP-118 akan tersedia sekarang (tag Sighash seperti itu dapat disimulasikan dengan kemampuan untuk memverifikasi tanda tangan secara introspektif dan sengaja).
Dengan belajar memprogram Bitcoin, kita tidak hanya tahu bagaimana mereka dapat diprogram dalam format "Output Transaksi" (apa yang dapat diprogram dalam CKB), tetapi juga bagaimana meningkatkan aplikasi ini (dan bagaimana kita dapat menggunakan kemampuan CKB untuk meningkatkannya jika kita memprogramnya di CKB). Bagi developer CKB, pemrograman berbasis Bitcoin Script dapat digunakan sebagai bahan pembelajaran, atau bahkan jalan pintas.
Di bawah ini, mari kita menganalisis programabilitas setiap modul pemrograman CKB satu per satu. Mari kita tidak mempertimbangkan introspeksi untuk saat ini.
(1) Kunci yang dapat dihitung secara sewenang-wenang yang dapat diprogram
Seperti disebutkan di atas, UTXO tidak dapat diprogram untuk menghitung secara sewenang-wenang. Lock, di sisi lain, berarti Lock dapat memprogram semuanya (sebelum penyebaran pembatasan) berdasarkan UTXO, termasuk tetapi tidak terbatas pada Lightning Channel dan DLC yang disebutkan di atas.
Selain itu, kemampuan untuk memverifikasi perhitungan sewenang-wenang ini juga membuat Lock lebih fleksibel daripada UTXO dalam hal metode otentikasi. Misalnya, kita dapat mengimplementasikan saluran petir pada CKB di mana satu pihak menandatangani ECDSA dan pihak lain menggunakan RSA.
Sebenarnya, ini adalah salah satu area pertama yang mulai dijelajahi orang di CKB: menggunakan kemampuan otentikasi fleksibel ini dalam hak asuh diri pengguna untuk memungkinkan apa yang dikenal sebagai "abstraksi akun" – otorisasi validitas transaksi dan pemulihan kontrol sangat fleksibel dan hampir tidak terbatas. Pada prinsipnya, ini adalah kombinasi dari "beberapa cabang pengeluaran" dan "metode otentikasi sewenang-wenang". Contoh implementasi adalah: joyid wallet, UniPass.
Selain itu, Lock dapat mengimplementasikan proposal eltoo, memungkinkan saluran kilat yang hanya perlu menyimpan transaksi komitmen terbaru (pada kenyataannya, eltoo dapat menyederhanakan semua kontrak peer-to-peer).
(2) Jenis yang dapat diprogram dihitung secara sewenang-wenang
Seperti disebutkan di atas, salah satu kegunaan besar Type adalah untuk memprogram UDT. Dikombinasikan dengan Lock, ini berarti kita dapat mengimplementasikan saluran petir berbasis UDT (dan jenis kontrak lainnya).
Faktanya, pemisahan antara Lock dan Type dapat dilihat sebagai peningkatan keamanan: Lock berfokus pada penerapan metode penahanan atau perjanjian kontrak, sementara Type berfokus pada mendefinisikan UDT.
Selain itu, kemampuan untuk memulai pemeriksaan berdasarkan definisi UDT juga memungkinkan UDT untuk berpartisipasi dalam kontrak dengan cara yang mirip dengan CKB (UDT adalah warga negara kelas satu).
Misalnya, penulis pernah mengusulkan protokol untuk menerapkan pinjaman yang didukung NFT tanpa kepercayaan pada Bitcoin. Kunci dari protokol semacam itu adalah transaksi berkomitmen di mana nilai input kurang dari nilai output (jadi ini belum merupakan transaksi yang valid), tetapi setelah input yang cukup dapat diberikan untuk transaksi, itu adalah transaksi yang valid: setelah pemberi pinjaman mampu membayar, pemberi pinjaman tidak dapat mengambil NFT yang dipertaruhkan untuk dirinya sendiri. Namun, ketidakpercayaan transaksi komitmen ini didasarkan pada transaksi yang memeriksa jumlah input dan output, sehingga pemberi pinjaman hanya dapat menggunakan Bitcoin untuk membayar kembali pinjaman - bahkan jika pemberi pinjaman dan pemberi pinjaman bersedia menerima mata uang lain (seperti USDT yang diterbitkan berdasarkan protokol RGB), transaksi komitmen Bitcoin tidak menjamin bahwa pemberi pinjaman akan mendapatkan NFT mereka kembali selama pemberi pinjaman mengembalikan jumlah penuh USDT, karena transaksi Bitcoin tidak tahu status USDT! (Revisi: Dengan kata lain, tidak mungkin untuk membangun transaksi yang dilakukan tergantung pada pembayaran USDT.) ）
Jika kami dapat memulai pemeriksaan berdasarkan definisi UDT, kami akan dapat meminta pemberi pinjaman untuk menandatangani transaksi berkomitmen lain yang akan memungkinkan pemberi pinjaman menggunakan USDT untuk membayar kembali pinjaman. Transaksi akan memeriksa jumlah USDT yang dimasukkan dan jumlah USDT yang keluar, memberi pengguna pembayaran tanpa kepercayaan dengan USDT.
Selanjutnya, mari kita pertimbangkan introspeksi.
(3) Kunci membaca kunci lain
Ini berarti berbagai kemungkinan pemrograman pada Bitcoin UTXO setelah pembatasan yang diusulkan diterapkan. Ini termasuk kontrak Vault yang disebutkan di atas, serta aplikasi berbasis OP _CTV (misalnya, kontrol kemacetan).
XueJie pernah menyebutkan contoh yang sangat menarik: Anda dapat menerapkan sel akun koleksi di CKB, ketika menggunakan sel semacam ini sebagai input transaksi, jika sel output (sel yang menggunakan kunci yang sama) memiliki kapasitas lebih, maka input tidak perlu memberikan tanda tangan dan tidak mempengaruhi validitas transaksi. Bahkan, sel semacam ini tidak akan mungkin terjadi tanpa kemampuan untuk introspeksi. Sel akun koleksi ini sangat ideal sebagai metode institusional untuk menerima uang karena mengumpulkan dana dan memiliki kelemahan karena tidak memiliki rasa privasi yang baik.
(4) Kunci membaca tipe lain (dan data)
Aplikasi menarik dari kemampuan ini adalah token taruhan. Lock akan memutuskan apakah dapat menggunakan kapasitasnya sendiri berdasarkan jumlah token di input lain, dan di mana ia dapat dihabiskan (membutuhkan kemampuan untuk introspeksi kunci).
(5) Tipe membaca kunci lain
Tidak yakin, tetapi dapat diasumsikan berguna. Misalnya, Anda dapat memeriksa Jenis bahwa Kunci input dan output transaksi tetap tidak berubah.
(6) Tipe Scirpt membaca tipe lain (dan data)
Kartu perdagangan? Kumpulkan n token dengan imbalan token yang lebih besar :)
VI. Kesimpulan
Dibandingkan dengan sistem kontrak pintar sebelumnya yang dapat diprogram dengan perhitungan sewenang-wenang, seperti Ethereum, Jaringan Nervos mengambil struktur yang berbeda; Akibatnya, seringkali sulit untuk memahami Jaringan Nervos berdasarkan pengetahuan tentang sistem kontrak pintar di masa lalu. Tulisan ini mengusulkan metode untuk memahami programabilitas CKB Cell, dimulai dari pemrograman aplikasi struktur yang lebih terbatas daripada CKB Cell, BTC UTXO. Dan, dengan menggunakan konsep "introspeksi" untuk memahami kemampuan "akses lintas-kontrak" sel, kita dapat membagi situasi di mana kemampuan introspektif digunakan dan menentukan penggunaan spesifiknya.
Recension:
Dua poin di atas berarti sesuatu dengan paradigma yang sama dengan "BTC + RGB" tetapi dengan lebih banyak kemampuan pemrograman;
Tidak banyak contoh spesifik dari penggunaan ini, tetapi ini disebabkan oleh kurangnya pemahaman penulis tentang ekologi CKB. Seiring waktu, diyakini bahwa semakin banyak imajinasi akan diinvestasikan di dalamnya, dan aplikasi yang tidak terbayangkan saat ini akan disatukan.
Ucapan terima kasih
Terima kasih kepada Retric, Jan Xie dan Xue Jie atas umpan balik mereka selama penulisan artikel. Tentu saja, saya bertanggung jawab atas semua kesalahan dalam teks.
Referensi
Akun, Daftar Akses Ketat, dan UTXO
Pembatasan dalam Bitcoin: Taksonomi untuk ditinjau
Model Sel
Nervos CKB Singkatnya
Programabilitas Bitcoin
Abstraksi On Account (2022)
Apa itu Pohon Sintaks Abstrak Merkelized Bitcoin?
BIP 345: Proposal OP_VAULT
Pengantar opcode pembatasan TLUV
Komponen yang membangun kontrak ditingkatkan dengan Bitcoin
Eltoo menjelaskan
Kontrak Pinjaman Aman NFT Berdasarkan Transaksi yang Berkomitmen · btc-studi/OP_QUESTION · Diskusi #7
Link ke artikel asli