Dari pemrograman aplikasi Bitcoin, penjelasan detil tentang keberlanjutan pemrograman CKB.

Berikut ini adalah konten yang diambil dari forum Nervos Talk, ditulis oleh Ajian (editor utama platform konten Bitcoin, BTC Study).

Ringkasan

Pemahaman tentang kebolehprograman suatu sistem membutuhkan identifikasi ciri struktural sistem tersebut. Penjelajahan pemrograman aplikasi berbasis skrip Bitcoin dapat membantu kita memahami struktur dasar CKB Cell dan paradigma pemrogramannya. Selain itu, hal ini juga dapat memecah komponen pemrograman CKB menjadi bagian yang tepat dan membantu kita memahami peningkatan kebolehprograman yang diberikan oleh setiap bagian.

1. Pengantar

“Kemampuan diprogram” adalah satu dimensi yang sering digunakan oleh masyarakat untuk membandingkan sistem blockchain. Namun, terdapat perbedaan pendapat dalam cara mendeskripsikan kemampuan diprogram ini. Salah satu cara yang umum adalah dengan mengatakan, "Blockchain XX mendukung bahasa pemrograman yang Turing Complete," atau, "Blockchain XX mendukung pemrograman umum," yang bermaksud bahwa "Blockchain XX" memiliki kemampuan diprogram yang kuat. Namun, implikasi dari pernyataan-pernyataan ini memiliki beberapa kebenaran: sistem yang mendukung pemrograman yang Turing Complete umumnya lebih mudah diprogram daripada yang tidak. Namun, fitur struktural dari sistem smart contract memiliki beberapa aspek, dan pernyataan ini hanya menyinggung salah satunya, sehingga tidak cukup untuk memperoleh pemahaman yang mendalam: pengembang tidak mendapatkan petunjuk darinya, dan pengguna biasa juga tidak dapat membedakan penipuan berdasarkan hal ini.

Sistem smart contract memiliki fitur struktural yang mencakup:

• Bentuk dasar ekspresi status (kontrak) (akun vs output transaksi)
• Apakah memungkinkan untuk melakukan perhitungan sembarang (disebut sebagai "Turing Complete" dalam konteks ini)
• 进程执行是否会产生新数据，还是只返回布尔值？（计算 vs. 验证）
• Apakah memungkinkan untuk mencatat status tambahan di dalam kontrak
• Apakah sebuah kontrak dapat mengakses status kontrak lain saat dieksekusi?

Jadi, di luar "kemampuan untuk memprogram perhitungan sembarang", setidaknya ada empat aspek lain yang akan memengaruhi keprograman sistem kontrak pintar. Bahkan dapat dikatakan bahwa aspek-aspek lain ini lebih penting, karena mereka lebih dalam menentukan apa yang mudah diimplementasikan, apa yang sulit diimplementasikan; apa yang merupakan implementasi yang lebih ekonomis, dan apa yang merupakan implementasi yang kurang efisien.

Contoh yang sering digunakan adalah Ethereum sebagai contoh yang baik dari kebolehprograman, tetapi bentuk dasar ekspresi status Ethereum adalah akun, yang sulit untuk diprogram kontrak titik ke titik (misalnya, saluran pembayaran, kontrak taruhan satu lawan satu) - bukan berarti tidak mungkin dilakukan, tetapi sulit dicapai. Ekosistem Ethereum sebenarnya pernah mencoba menerapkan proyek pembayaran saluran / saluran status, dan ada banyak pembahasan teoritis, tetapi hingga saat ini proyek-proyek ini tampaknya tidak aktif - ini jelas bukan karena kurangnya upaya dari para pengembang. Saat ini, proyek yang aktif di Ethereum mengadopsi bentuk "kolam dana", bukan bentuk "kontrak titik ke titik", dan ini bukan kebetulan. Demikian pula, saat ini mungkin ada kepuasan yang tinggi terhadap kebolehprograman Ethereum, tetapi jika ingin menerapkan "abstraksi akun" (juga dapat dipahami sebagai konsepsi dompet yang lebih umum), model akun dapat dikatakan memiliki kekurangan bawaan.

Demikian pula, untuk memahami kegunaan CKB, kita perlu memahami fitur struktural sistem kontrak pintar CKB dalam hal ini. Yang kita ketahui adalah CKB memungkinkan pemrograman perhitungan apa pun, memungkinkan pencatatan status tambahan di dalam kontrak, dan memungkinkan kontrak satu mengakses status kontrak lain saat dieksekusi. Namun, bentuk kontraknya adalah output transaksi (disebut "Cell"), yang merupakan perbedaan mendasar dengan Ethereum. Oleh karena itu, pemahaman tentang sistem kontrak pintar Ethereum dan contoh kontrak di dalamnya tidak akan membantu kita memahami bagaimana CKB menerapkan fitur-fitur struktural ini atau mengenal kegunaan CKB.

Untungnya, smart contract di Bitcoin nampaknya memberikan dasar terbaik bagi pemahaman kita tentang pemrograman CKB. Hal ini tidak hanya karena bentuk dasar dari ekspresi keadaan Bitcoin juga merupakan output transaksi (disebut "UTXO"), tetapi juga karena dengan konsep yang diajukan oleh komunitas Bitcoin "covenants", kita dapat memahami alasan mengapa CKB memiliki struktur tersebut, dan dengan tepat memecah hasil akhir menjadi beberapa bagian, secara bertahap mengidentifikasi peningkatan pemrograman yang mereka bawa.

二. CKB v.s. BTC: Apa yang ditambahkan?

Struktur Dasar

Sebagai bentuk dasar dari status Bitcoin, UTXO (Unspent Transaction Output) Bitcoin memiliki dua bidang:

• Jumlah, dalam satuan Satoshi, menunjukkan nilai Bitcoin yang dimiliki UTXO tersebut;
• Kunci skrip, juga dikenal sebagai skrip kunci, mencerminkan kondisi yang harus dipenuhi untuk mengeluarkan dana ini, yaitu program kontrak pintar yang menetapkan kondisi untuk membuka kunci dana ini.

Dibandingkan dengan sistem smart contract yang muncul kemudian, skrip Bitcoin cukup terbatas:

• Ini tidak memungkinkan untuk melakukan perhitungan sembarangan; hanya ada beberapa jenis perhitungan yang lebih praktis yang dapat digunakan untuk verifikasi (pemeriksaan tanda tangan, pemeriksaan gambar hash, pemeriksaan waktu)
• Ini tidak memungkinkan untuk mencatat status tambahan di dalam kontrak; (misalnya, Anda tidak dapat menggunakan skrip untuk membatasi batas proporsi/pembayaran satu kali; juga tidak dapat menyembunyikan token di dalamnya)
• Ia juga tidak memungkinkan untuk mengakses status kontrak lain saat dieksekusi (setiap skrip adalah alam semesta yang independen, saling tidak bergantung).

Ini adalah teks dalam bahasa Indonesia: "Meskipun skrip ini terbatas, namun tidak kekurangan kemampuan untuk menghasilkan aplikasi yang menakjubkan, dan juga menjadi dasar eksplorasi CKB yang dapat diprogram. Bagian berikutnya akan menjelaskan dua contoh pemrograman skrip Bitcoin."

Dalam hal ini, unit status CKB disebut "Cell", dengan empat bidang:

• Capacity, seperti jumlah UTXO, mengekspresikan ukuran ruang yang dapat diisi oleh Sel tersebut, dalam satuan byte (Bytes);
• Lock ，mirip dengan kunci skrip UTXO, mendefinisikan kepemilikan dari Sel ini; hanya ketika data yang diberikan dapat melewati Lock, maka Sel ini dapat "diperbarui" (atau dilepaskan dan menggunakan Kapasitas ini untuk mencetak Sel baru);
• Data, 01928374656574839201, 01928374656574839201, 01928374656574839201, 01928374656574839201.
• Jenis ，opsional skrip, digunakan untuk mengatur kondisi pembaruan Data.

Selain itu, Lock dan Type juga dapat diprogram untuk melakukan perhitungan yang bebas. Anda dapat memprogram algoritma verifikasi tanda tangan apa pun, atau memprogram pemeriksaan gambaranan dari algoritma hash apa pun, dan sebagainya.

Pembaca dengan mudah dapat melihat bahwa Cell meningkatkan kegunaan dalam hal pemrograman jika dibandingkan dengan UTXO.

• Cell dapat diprogram untuk perhitungan apa pun, bukan hanya untuk beberapa jenis perhitungan tertentu; verifikasi kepemilikan akan menjadi lebih fleksibel;
• Karena bidang Data dan Type, Cell dapat mencatat status tambahan; ini memungkinkan Cell membawa apa yang disebut "Token Kustom Pengguna (UDT)".

Dalam kombinasi dengan struktur "output transaksi" Cell itu sendiri, manfaat yang dapat diberikan oleh kedua hal tersebut sangatlah besar. Namun, dari penjelasan di atas, kita masih belum tahu bagaimana Cell mengimplementasikan "akses status kontrak lain saat runtime". Untuk itu, kita perlu mengacu pada konsep yang telah lama diperdebatkan dalam komunitas Bitcoin: "klausula pembatasan (covenants)".

Ketentuan Pembatasan dan Introspeksi

Pembatasan dalam istilah ini adalah membatasi di mana suatu uang dapat digunakan. Pada saat ini, Bitcoin (yang belum mengimplementasikan proposal pembatasan) memungkinkan uang yang telah terkunci dapat digunakan di mana saja (dapat dibayarkan ke kunci publik skrip apa pun). Namun, gagasan dari pembatasan ini adalah dapat membatasi penggunaan uang hanya ke beberapa tempat tertentu, misalnya, sebuah UTXO hanya dapat dihabiskan oleh satu transaksi, jadi meskipun ada yang dapat memberikan tanda tangan untuk UTXO ini, tempat penggunaan uangnya sudah ditentukan oleh transaksi itu. Fitur ini terlihat agak aneh, tetapi dapat menghasilkan beberapa aplikasi menarik, yang akan dijelaskan secara khusus dalam bagian selanjutnya. Yang penting, ini adalah kunci untuk lebih memahami programabilitas CKB.

Rusty Russell dengan tepat menunjukkan bahwa klausa pembatasan dapat dipahami sebagai kemampuan "introspeksi" terhadap transaksi, yaitu, ketika UTXO A dihabiskan oleh transaksi B, program operasi skrip dapat membaca bagian (atau semua) dari transaksi B, lalu memeriksanya apakah sesuai dengan parameter yang diminta oleh skrip sebelumnya. Misalnya, apakah kunci publik skrip output pertama dari transaksi A sesuai dengan yang diminta oleh kunci publik skrip UTXO A (ini adalah arti awal dari klausa pembatasan).

Membaca dengan cermat, pembaca yang terampil akan menyadari bahwa jika memiliki kemampuan introspeksi yang lengkap, maka input dari suatu transaksi dapat membaca status input lainnya dari transaksi yang sama, ini mewujudkan kemampuan "kontrak mengakses status kontrak lainnya saat berjalan" yang telah kita sebutkan sebelumnya. Faktanya, CKB Cell dirancang secara demikian.

Berdasarkan ini, kita dapat membagi kemampuan introspeksi yang lengkap ini menjadi empat situasi:

• Lock Membaca Lock lainnya (input dan output)
• Membaca Tipe (dan Data) input dan output dari Kunci 01928374656574839201
• Ketik Baca Kunci lainnya (input dan output)
• Ketik 01928374656574839201读取其它（输入和输出）的 Type （以及 Data）

Ini memungkinkan kita untuk menganalisis peran kemampuan introspeksi setiap bagian dalam berbagai skenario aplikasi dengan asumsi tertentu (pemisahan fungsi Lock dan Type), yaitu menganalisis keuntungan pemrograman yang diberikan oleh setiap bagian kepada kita.

Pada dua bab berikut, kami akan mempelajari pemrograman skrip Bitcoin saat ini (yang belum mencakup proposal persyaratan terbatas) dan harapan untuk mengimplementasikan fitur proposal persyaratan terbatas, untuk memahami secara konkret bagaimana CKB Cell diprogram dan ditingkatkan.

3. Pemrograman Skrip Bitcoin

本节将使用 "Jaringan Lighting" dan "Kontrak Logis yang Berhati-hati (DLC)" sebagai contoh pemrograman aplikasi berbasis skrip Bitcoin. Sebelum melanjutkan, kita perlu memahami dua konsep ini.

OP_IF dan "Transaksi Komitmen"

Pertama, konsep dalam kode operasi kontrol alur dalam skrip Bitcoin, seperti: OP_IF, OP_ELSE. Kode operasi ini tidak jauh berbeda dengan IF dalam pemrograman komputer, fungsinya adalah untuk menjalankan pernyataan yang berbeda berdasarkan input yang berbeda. Dalam konteks skrip Bitcoin, ini berarti kita dapat menetapkan beberapa jalur penguncian dana; dengan fitur kunci waktu, ini berarti kita dapat mengatur prioritas tindakan.

Sebagai contoh, kontrak "Hashed TimeLock Contract (HTLC)" yang terkenal ini, skrip ini diterjemahkan ke dalam bahasa yang lebih mudah dimengerti sebagai:

要么，Bob dapat mengungkapkan gambaran di balik nilai hash H, kemudian memberikan tanda tangannya sendiri, untuk menghabiskan dana tersebut;

要么，Alice 可以在一段时间 T 过后，凭借自己的签名花费这笔资金。 -> Atau, Alice dapat menghabiskan dana ini setelah waktu T dengan tanda tangannya sendiri.

Efek "enten ... enten ..." ini dicapai melalui kode operasi kontrol aliran.

HTLC memiliki keunggulan yang paling mencolok yaitu dapat menggabungkan beberapa operasi menjadi satu dan mencapai atomisitas. Misalnya, Alice ingin menukar CKB dengan Bob menggunakan BTC, maka Bob dapat memberikan nilai hash terlebih dahulu dan membuat HTLC di Nervos Network; kemudian Alice membuat HTLC di Bitcoin menggunakan nilai hash yang sama. Atau, Bob mengambil BTC yang dibayarkan oleh Alice di Bitcoin dan juga mengungkapkan gambar asli, sehingga memungkinkan Alice untuk mengambil CKB di Nervos Network. Atau, Bob tidak mengungkapkan gambar asli, kedua kontrak tersebut kedaluwarsa, dan Alice dan Bob dapat mengambil kembali dana yang telah mereka investasikan.

Setelah aktivasi fork lunak Taproot, fitur jalur penguncian ganda ini diperkuat lebih lanjut dengan pengenalan MAST (Merkelized Abstract Syntax Tree): kita dapat mengubah satu jalur penguncian menjadi satu daun dalam pohon Merkle, setiap daun adalah independen, sehingga tidak perlu lagi menggunakan opcode kontrol alur seperti ini; Selain itu, karena tidak perlu lagi mengungkapkan jalur lain saat mengungkapkan satu jalur, kita dapat menambahkan lebih banyak jalur penguncian ke suatu output tanpa perlu khawatir tentang masalah ekonomi.

第 konsep kedua adalah "transaksi komitmen". Ide dari transaksi komitmen adalah bahwa dalam beberapa kasus, transaksi Bitcoin yang valid tetaplah nyata dan mengikat, meskipun tidak dikonfirmasi oleh blockchain.

Misalkan, Alice dan Bob memiliki UTXO bersama yang memerlukan tanda tangan keduanya untuk dapat digunakan. Pada saat ini, Alice membuat transaksi untuk menggunakannya dengan mentransfer 60% nilainya kepada Bob dan sisanya kepada dirinya sendiri. Alice memberikan tanda tangan pada transaksi ini, lalu mengirimkannya kepada Bob. Bagi Bob, tidak perlu menyebarkan transaksi ini ke jaringan Bitcoin, juga tidak perlu menunggu konfirmasi dari blockchain. Efek pembayaran transaksi ini tetap nyata dan dapat dipercaya. Hal ini karena Alice tidak dapat menghabiskan UTXO ini sendirian (sehingga tidak bisa melakukan pengeluaran ganda) dan tanda tangan yang diberikan oleh Alice valid. Bob dapat menambahkan tanda tangannya sendiri kapan saja dan menyebarkan transaksi tersebut untuk menebus pembayaran ini. Dengan kata lain, Alice memberikan "janji yang dapat dipercaya" kepada Bob melalui transaksi ini yang valid (tanpa dimasukkan ke dalam rantai blok).

Pertukaran janji adalah konsep inti dalam pemrograman aplikasi Bitcoin. Seperti yang telah disebutkan sebelumnya, kontrak Bitcoin adalah berbasis verifikasi, tanpa status, dan tidak memperbolehkan akses silang; tetapi jika kontrak tidak mengandung status, di mana status ini disimpan, dan bagaimana kontrak memajukan keamanan (mengubah status)? Pertukaran janji memberikan jawaban yang jelas: status kontrak dapat diungkapkan dalam bentuk transaksi, sehingga peserta kontrak dapat menyimpan status mereka sendiri tanpa harus menampilkannya di blockchain; masalah perubahan status kontrak juga dapat diubah menjadi masalah bagaimana mengupdate pertukaran janji dengan aman; selain itu, jika kita khawatir tentang masuk ke dalam kontrak yang berbahaya (misalnya, masuk ke dalam kontrak yang membutuhkan tanda tangan dari kedua pihak untuk melakukan pengeluaran, yang dapat menghadapi risiko terjebak jika pihak lain tidak merespons), maka cukuplah untuk sebelumnya menghasilkan pertukaran janji untuk menghabiskan kontrak tersebut dan mendapatkan tanda tangan, sehingga dapat mengurangi risiko, menghilangkan kepercayaan pada pihak lain.

Saluran Kilat dan Jaringan Lighting

闪电通道是一种一对一的合约，在这种合约中，双方可以无限次地相互支付，而不必让任何一次支付获得区块链的确认。如你所料，它用到了承诺交易。

Dalam bagian menjelaskan "transaksi janji", kami telah memperkenalkan saluran pembayaran tertentu. Namun, kontrak yang hanya menggunakan multisig 2-of-2 hanya dapat mengimplementasikan pembayaran satu arah. Artinya, entah Alice terus membayar ke Bob atau sebaliknya, sampai saldo mereka dalam kontrak habis. Jika pembayaran dua arah, itu berarti setelah pembaruan status tertentu, saldo satu pihak dapat menjadi lebih sedikit dari sebelumnya, tetapi pihak tersebut masih memiliki transaksi janji sebelumnya yang sudah ditandatangani oleh pihak lain - bagaimana cara mencegah pihak tersebut menyiarkan transaksi janji lama tersebut dan memaksa mereka hanya dapat menyiarkan transaksi janji terbaru?

闪电通道解决这个问题的办法叫做 “LN-Penalty”. Sekarang, misalkan Alice dan Bob masing-masing memiliki 5 BTC dalam saluran. Sekarang, Alice ingin membayar 1 BTC kepada Bob, jadi dia menandatangani transaksi janji seperti ini dan mengirimkannya ke Bob:

Masukkan #0, 10 BTC: Alie-Bob 2-of-2 output multisig (yaitu kontrak saluran)

Output #0, 4 BTC: Alice single signature.

Output #1, 6 BTC: Either Alice-Bob joint temporary public key #1 single signature or T1 time lock, Bob single signature

Bob juga menandatangani transaksi komitmen (yang sesuai dengan transaksi yang disebutkan di atas) dan mengirimkannya ke Alice:

Masukkan #0, 10 BTC: Alie-Bob 2-of-2 output multisig (yaitu kontrak saluran)

Output #0, 6 BTC: Tunggal Tanda Tangan Bob

Output #1, 4 BTC: Either Bob-Alice menggunakan kunci publik sementara gabungan #1 untuk tanda tangan tunggal atau kunci waktu T1, Alice tanda tangan tunggal

Ini adalah "kunci publik gabungan" yang penting, dibuat dengan menggunakan kunci publik kita dan kunci publik yang diberikan oleh pihak lain. Sebagai contoh, kunci publik gabungan Alice-Bob adalah hasil perkalian kunci publik Alice dengan kunci publik Bob, kemudian ditambahkan dengan nilai hash. Saat kunci publik ini dibuat, tidak ada yang mengetahui kunci privatnya. Namun, jika Bob memberitahu Alice kunci privat dari kunci publik yang dia berikan, Alice dapat menghitung kunci privat dari kunci publik gabungan ini. Inilah kunci untuk "membatalkan" status lama dalam saluran kilat.

在下一次双方要更新通道状态（发起支付）时，双方就交换上一轮中交给对方的临时公钥的私钥。如此一来，参与者就再也不敢广播自己得到的上一笔承诺交易：这笔承诺交易为己方分配价值的输出有两个路径，而临时公钥路径的私钥已被对方知道；所以一旦广播旧的承诺交易，对方就可以立即动用这个联合临时私钥，从而将这个输出中的资金全部拿走。—— 这就是 “LN-Penalty” 的含义。

Secara khusus, urutan interaksi adalah sebagai berikut: pihak yang melakukan pembayaran pertama-tama meminta kunci publik sementara baru kepada pihak lain, kemudian membuat transaksi komitmen baru dan memberikannya kepada pihak lain; pihak yang menerima transaksi komitmen tersebut mengungkapkan kunci pribadi yang sesuai dengan kunci publik sementara yang diberikannya dalam putaran sebelumnya. Urutan interaksi ini memastikan bahwa peserta selalu mendapatkan transaksi komitmen baru terlebih dahulu sebelum membatalkan transaksi komitmen yang diterimanya dalam putaran sebelumnya, sehingga tidak memerlukan kepercayaan.

综上，闪电通道的关键设计有：

Pihak-pihak selalu menggunakan transaksi janji untuk mengungkapkan status internal kontrak dan menggunakan perubahan jumlah untuk mewakili pembayaran.

Transaksi janji selalu menghabiskan input yang sama (input yang memerlukan tanda tangan dari kedua belah pihak), sehingga semua transaksi janji bersaing satu sama lain, dan akhirnya hanya satu transaksi yang dapat dikonfirmasi oleh blockchain.

Dua tanda tangan peserta bukan untuk transaksi janji yang sama (meskipun mereka berpasangan); tetapi yang mereka tandatangani selalu transaksi yang lebih menguntungkan bagi diri mereka sendiri, dengan kata lain, transaksi janji yang diterima peserta selalu merugikan mereka sendiri;

Ini tercermin dalam keuntungan yang diberikan oleh output yang mengalokasikan nilai kepada dirinya sendiri dengan dua jalur pembebasan: satu jalur memungkinkan untuk membuka dengan tanda tangan sendiri, tetapi membutuhkan waktu tertentu; sementara jalur lainnya menggunakan kunci publik lawan, hanya dilindungi jika kunci privat sementara tidak terungkap.

Dalam setiap pembayaran, kedua belah pihak menukar kunci privat sementara yang digunakan dalam putaran sebelumnya dengan transaksi komitmen baru, sehingga pihak yang memberikan kunci privat sementara tidak lagi berani menyiarkan transaksi komitmen sebelumnya, dengan demikian, "membatalkan" transaksi komitmen sebelumnya dan memperbarui status kontrak; (sebenarnya, transaksi komitmen ini adalah transaksi yang valid dan dapat disiarkan ke dalam blockchain, tetapi peserta tidak berani melakukannya karena takut akan hukuman).

任何一方随时都可以拿对方签过名的承诺交易退出合约；但是，如果双方愿意合作，他们可以签名一笔新的交易，让双方都可以立即拿回属于自己的钱。

Akhirnya, karena transaksi janji juga dapat memasukkan HTLC, maka saluran petir juga dapat meneruskan pembayaran. Anggaplah Alice dapat menemukan jalur yang terdiri dari saluran petir yang saling terhubung dari depan ke belakang, dan mencapai Daniel, maka pembayaran melalui beberapa langkah tanpa kepercayaan kepada Daniel dapat dilakukan tanpa perlu membuka saluran dengan Daniel. Inilah jaringan Lighting.

Alice -- HTLC --\u003e Bob -- HTLC --\u003e Carol -- HTLC --\u003e Daniel

Alice \u003c-- original image -- Bob \u003c-- original image -- Carol \u003c-- original image -- Daniel

Ketika Alice menemukan jalur seperti itu dan ingin membayar kepada Daniel, dia meminta nilai hash dari Daniel untuk membangun HTLC kepada Bob, dan meminta Bob untuk meneruskan pesan kepada Carol dan memberikan HTLC yang sama; pesan tersebut meminta Carol untuk meneruskan pesan kepada Daniel dan memberikan HTLC yang sama. Ketika pesan sampai ke tangan Daniel, dia mengungkapkan nilai asli kepada Carol untuk mendapatkan nilai HTLC, memperbarui status kontrak; Carol juga melakukan hal yang sama, mendapatkan pembayaran dari Bob dan memperbarui status saluran; akhirnya, Bob mengungkapkan nilai asli kepada Alice, memperbarui status. Karena sifat HTLC, pembayaran beruntun ini berhasil atau gagal bersama-sama, sehingga tidak memerlukan kepercayaan.

闪电网络 terdiri dari serangkaian saluran yang saling terhubung, setiap saluran (kontrak) adalah independen satu sama lain. Ini berarti bahwa Alice hanya perlu mengetahui apa yang terjadi di saluran antara dirinya dan Bob, tanpa perlu memperhatikan berapa kali interaksi terjadi di saluran orang lain, atau bahkan harus tahu mata uang apa yang digunakan dalam interaksi tersebut, atau bahkan apakah mereka benar-benar menggunakan saluran atau tidak).

Jaringan Lighting memiliki skalabilitas tidak hanya terbatas pada kecepatan pembayaran di dalam saluran Lighting Network yang hanya tergantung pada sumber daya keras dari kedua belah pihak, tetapi juga karena penyimpanan status yang terdesentralisasi, sebuah node tunggal dapat memanfaatkan leverage maksimum dengan biaya minimal.

Kontrak Catatan Hatihati

DLC (Discreet Log Contract) menggunakan teknik kriptografi yang disebut "tanda tangan adaptor" untuk memungkinkan skrip Bitcoin memprogram kontrak keuangan yang bergantung pada peristiwa eksternal.

适配器签名可以让一个签名仅在加入一个Kunci Pribadi之后，才会变成有效的签名。以 Schnorr 签名为例，Schnorr 签名的标准形式是(R, s)，其中：

R = r.G # Kunci Publik nonce yang digunakan untuk tanda tangan r dikalikan dengan titik yang dihasilkan oleh kurva eliptik, juga dapat dikatakan sebagai kunci publik r

s = r + Hash(R || m || P) * p # p adalah Kunci Pribadi tanda tangan, P adalah Kunci Publik

验证签名即验证 s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK

假设我给出了一对数据(R, s')，其中：

R = R1 + R2 = r1.G + r2.G

s' = r1 + Hash(R || m || P) * p

Tentu saja, ini bukanlah tanda tangan Schnorr yang valid dan tidak dapat lulus rumus verifikasi. Namun, saya dapat membuktikan kepada validator bahwa dengan hanya mengetahui kunci pribadi r2 dari R2, saya dapat membuatnya menjadi tanda tangan yang valid.

s'.G + R2 = R1 + Hash(R || m || P) \* P + R2 = R + Hash(R || m || P) \* P

Adapter signature makes the validity of a signature dependent on a secret data and is verifiable. But, what does this have to do with financial contracts?

假设 Alice dan Bob ingin bertaruh pada hasil pertandingan bola. Alice dan Bob masing-masing bertaruh bahwa tim Green Monsters dan team Alinna akan menang, dengan taruhan 1 BTC. Selain itu, situs web penilaian bola Carol berjanji akan mengumumkan tanda tangan s_c_i terhadap hasil pertandingan menggunakan nonce R_c saat hasil pertandingan diumumkan.

Dapat dilihat bahwa ada tiga kemungkinan hasil (oleh karena itu, ada tiga kemungkinan tanda tangan Carol):

• Setan Hijau menang, Alice memenangkan 1 BTC
• Alina wins, Bob wins 1 BTC
• Imbang, dana dua orang dikembalikan ke asalnya.

为此，两人为每一种结果创建一笔承诺交易。例如，他们为第一种结果创建的承诺交易是这样的：

Masukkan #0, 2 BTC: Alie-Bob 2-of-2 output multisig (kontrak taruhan)

输出 #0，2 BTC： Alice tanda tangan tunggal

Namun, tanda tangan yang dibuat oleh Alice dan Bob untuk transaksi ini bukanlah (R, s), melainkan tanda tangan adapter (R, s'). Dengan kata lain, tanda tangan yang diberikan oleh kedua pihak tidak bisa langsung digunakan untuk membuka kontrak ini, melainkan harus mengungkapkan nilai rahasia tertentu. Nilai rahasia ini adalah inversi gambaran s_c_1.G, yaitu tanda tangan Carol! Karena nilai nonce dari tanda tangan Carol sudah ditentukan (adalah R_c), maka s_c_1.G dapat dibangun (s_c_1.G = R_c + Hash(R_c || '绿魔胜出' || PK_c) * PK_c).

Ketika hasilnya diumumkan, misalnya Kelpie menang, Carol akan mengirimkan tanda tangan (R_c, s_c_1), sehingga baik Alice maupun Bob dapat melengkapi tanda tangan adapter lawan, menambahkan tanda tangan mereka sendiri, sehingga transaksi tersebut menjadi transaksi yang sah dan disiarkan ke jaringan untuk memicu efek pembayaran. Tetapi jika Kelpie kalah, Carol tidak akan mengirimkan s_c_1, sehingga transaksi janji tersebut tidak akan menjadi transaksi yang sah.

以此类推，另外两笔交易也是如此。就这样，Alice 和 Bob 让这个合约的执行依赖于外部事件（准确来说是依赖于断言机对外部事件的播报，其形式是个签名），而且不需要信任对手方。大大小小的金融合约，比如期货、Opsi，都可以用这种方式来实现。

Dibandingkan dengan implementasi lainnya, fitur utama dari kontrak log yang berhati-hati adalah privasinya: (1) Alice dan Bob tidak perlu memberi tahu Carol bahwa mereka menggunakan data Carol, ini tidak mempengaruhi eksekusi kontrak; (2) pengamat di rantai (termasuk Carol) tidak dapat menentukan layanan situs web mana yang digunakan oleh Alice dan Bob melalui transaksi kontrak mereka, bahkan tidak dapat memastikan apakah kontrak mereka adalah kontrak taruhan (bukan saluran kilat).

Empat. Pengantar Aplikasi Ketentuan Pembatasan

OP_CTV dan Pengendalian Kemacetan

Komunitas pengembang Bitcoin pernah mengajukan berbagai proposal yang dapat diklasifikasikan sebagai ketentuan pembatasan. Saat ini, proposal paling terkenal adalah OP_CHECKTEMPLATEVERIFY (OP_CTV), yang konsepnya sederhana namun mempertahankan fleksibilitas yang cukup besar, sehingga disambut baik oleh komunitas Bitcoin yang menghargai kesederhanaan. Ide dari OP_CTV adalah untuk berjanji pada sebuah nilai hash dalam skrip, untuk membatasi dana tersebut hanya bisa dihabiskan oleh transaksi yang diwakili oleh nilai hash tersebut; nilai hash tersebut berjanji pada output transaksi dan sebagian besar bidang lainnya, namun tidak berjanji pada input transaksi, hanya pada jumlah inputnya.

“Kendali Kemacetan” adalah contoh bagus yang mencerminkan fitur OP_CTV. Skenario aplikasi dasarnya adalah membantu sejumlah besar pengguna keluar dari pertukaran (lingkungan yang memerlukan kepercayaan) ke kolam dana; karena kolam dana ini menggunakan OP_CTV untuk merencanakan cara pengeluaran di masa depan, maka dapat menjamin pengguna untuk keluar dari kolam dana ini tanpa perlu kepercayaan, tanpa bantuan siapapun; dan karena kolam dana ini hanya mewakili UTXO, ini menghindari pembayaran biaya transaksi yang tinggi saat permintaan transaksi on-chain meningkat (dari n output menjadi 1 output; juga dari n transaksi menjadi 1 transaksi). Pengguna dalam kolam dapat mencoba untuk keluar dari kolam lagi.

Katakanlah Alice, Bob, Carol ingin menarik masing-masing 5 BTC, 3 BTC, dan 2 BTC dari bursa. Kemudian pertukaran dapat membuat output 10 BTC dengan 3 OP_CTV cabang. Misalkan Alice ingin menarik uang, dia dapat menggunakan cabang 1, dan transaksi yang diwakili oleh nilai hash yang digunakan oleh OP_CTV cabang itu akan membentuk dua output, salah satunya adalah mengalokasikan 5 BTC kepada Alice; Output lainnya, pada gilirannya, adalah kumpulan, yang juga menggunakan OP_CTV untuk berkomitmen pada transaksi, memungkinkan Bob untuk mengambil hanya 3 BTC dan mengirim 2 BTC sisanya ke Carol.

Bob atau Carol ingin menarik dana, prinsipnya sama. Saat mereka menarik dana, mereka hanya dapat menggunakan transaksi yang dapat lulus pemeriksaan OP_CTV yang sesuai, artinya mereka hanya dapat membayar diri mereka sendiri jumlah yang sesuai, dan tidak dapat menarik dana sembarangan; sisa dana akan kembali ke kolam dana yang terkunci menggunakan OP_CTV, sehingga memastikan bahwa tidak peduli urutan penarikan dana pengguna, pengguna lain yang tersisa dapat keluar dari kolam dana tanpa kepercayaan.

Secara abstrak, peran OP_CTV di sini adalah merencanakan jalur kehidupan kontrak ke arah akhir kontrak, sehingga kontrak kolam dana di sini dapat tetap mempertahankan sifat keluar tanpa kepercayaan, tidak peduli jalur mana yang diambil atau mencapai status apa.

OP_CTV ini memiliki satu penggunaan menarik lainnya: "saluran pembayaran satu arah yang tersembunyi". Misalkan Alice membentuk kolam dana semacam itu dan memastikan dana dapat ditarik tanpa kepercayaan ke output dengan skrip berikut:

要么，Alice dan Bob menghabiskannya bersama, atau setelah beberapa waktu, Alice dapat menghabiskannya sendirian.

Jika Alice tidak mengungkapkannya kepada Bob, Bob tidak akan menyadari bahwa output ini ada; begitu Alice mengungkapkannya kepada Bob, Bob dapat menggunakan output ini sebagai saluran pembayaran satu arah yang bersifat temporal, di mana Alice dapat segera membayar Bob dengan dana di dalamnya tanpa harus menunggu konfirmasi rantai blok. Bob hanya perlu memasukkan transaksi janji yang diberikan oleh Alice ke rantai sebelum Alice dapat menghabiskannya sendiri.

OP_Vault dan Lemari

OP_VAULT adalah proposal klausul pembatas yang dirancang khusus untuk membangun "kontrak brankas (vaults)".

保险柜合约 bertujuan untuk menjadi bentuk penyimpanan sendiri yang lebih aman dan canggih. Meskipun kontrak tanda tangan ganda saat ini dapat menghindari kegagalan titik tunggal dari satu kunci pribadi, namun jika penyerang benar-benar memperoleh jumlah kunci pribadi ambang batas, pemilik dompet tidak dapat melakukan apa-apa. Safe juga bertujuan untuk memberlakukan batasan pengeluaran satu kali pada dana; selama penarikan menggunakan rute konvensional, operasi penarikan akan memaksa penerapan periode penundaan; dan selama periode penundaan, operasi penarikan dapat dihentikan oleh operasi pemulihan darurat dompet. Dengan kontrak seperti ini, bahkan jika diretas, pemilik dompet masih dapat meluncurkan operasi kontra (menggunakan cabang pemulihan darurat).

Secara teoritis, OP_CTV juga dapat diprogramkan untuk kontrak semacam ini, tetapi ada banyak ketidaknyamanan, salah satunya adalah biaya transaksi: pada saat transaksi dijanjikan, biaya transaksi yang akan dibayarkan juga dijanjikan. Mengingat penggunaan kontrak ini, interval waktu antara penyetelan kontrak dan penarikan pasti akan sangat lama, sehingga hampir tidak mungkin memprediksi biaya transaksi yang tepat. Meskipun OP_CTV tidak membatasi input, sehingga biaya transaksi dapat ditingkatkan dengan menambahkan input, namun semua input yang diberikan akan menjadi biaya transaksi, sehingga tidak realistis; cara lain adalah CPFP, yaitu dengan mengeluarkan dana yang diambil, menyediakan biaya transaksi dalam transaksi baru. Selain itu, penggunaan OP_CTV juga berarti kontrak brankas semacam ini tidak dapat menarik secara massal (tentu saja juga tidak dapat memulihkan secara massal).

OP_VAULT proposal mencoba menyelesaikan masalah ini dengan mengajukan opcode baru (OP_VAULT dan OP_UNVAULT). OP_UNVAULT dirancang khusus untuk pemulihan massal, yang saat ini tidak kita usulkan. Tindakan OP_VAULT adalah seperti ini: ketika kita menempatkannya di cabang pohon skrip, ia dapat digunakan untuk berkomitmen pada opcode yang dapat digunakan (misalnya OP_CTV) tanpa menentukan parameter khusus; ketika menghabiskan cabang ini, transaksi dapat memasukkan parameter spesifik, tetapi tidak dapat mengubah cabang lain. Dengan demikian, tidak perlu menetapkan biaya transaksi di muka, biaya transaksi dapat ditetapkan saat menghabiskan cabang ini; jika cabang ini juga memiliki kunci waktu, maka akan memaksa menerapkan kunci waktu; akhirnya, karena hanya dapat mengubah cabang tempat ia berada, cabang baru pada pohon skrip (termasuk cabang pemulihan darurat) tidak akan berubah, sehingga memungkinkan kami menghentikan operasi penarikan dana seperti itu.

此外, ada dua hal yang perlu dicatat: (1) Tindakan kode operasi OP_VAULT mirip dengan proposal ketentuan pembatasan lainnya: OP_TLUV; Jeremy Rubin dengan tepat menunjukkan bahwa ini telah menciptakan konsep "komputasi" hingga tingkat tertentu: OP_TLUV/OP_VAULT berkomitmen untuk kode operasi tertentu yang memungkinkan pengguna untuk memasukkan parameter melalui transaksi baru untuk memperbarui seluruh daun pohon skrip; ini bukan lagi tentang "memvalidasi data yang masuk berdasarkan kondisi tertentu", melainkan "menghasilkan data baru yang berarti berdasarkan data yang masuk", meskipun komputasi yang dapat diaktifkan ini terbatas.

完整nya proposal OP_VAULT juga menggunakan beberapa proposal kebijakan mempool (misalnya format transaksi v3) untuk mencapai hasil yang lebih baik. Ini mengingatkan kita bahwa makna "pemrograman" dapat lebih luas daripada yang kita bayangkan. (Contoh serupa adalah Transaksi Terbuka di Jaringan Nervos.)

Lima. Memahami CKB

Dalam dua bab di atas, kami memperkenalkan cara kami menggunakan pemrograman skrip untuk membuat aplikasi menarik di atas struktur yang lebih terbatas (Bitcoin UTXO); kami juga memperkenalkan proposal untuk menambahkan kemampuan introspeksi ke struktur ini.

UTXO meskipun memiliki kemampuan untuk menghasilkan aplikasi-aplikasi ini, pembaca juga mudah menyadari kekurangannya, atau dengan kata lain, area yang bisa dioptimalkan, seperti:

• Dalam LN-Penalty, para peserta saluran harus menyimpan setiap transaksi janji masa lalu dan nilai rahasia hukuman yang sesuai untuk mengatasi penipuan lawan, ini merupakan beban penyimpanan. Jika ada mekanisme yang dapat memastikan hanya transaksi janji terbaru yang akan berlaku, sementara transaksi janji lama tidak akan berlaku, maka beban ini dapat dihilangkan, dan juga dapat menghilangkan masalah node yang secara tidak sengaja memasukkan transaksi janji yang lebih lama karena kegagalan, dan akibatnya dikenai hukuman.
• Dalam DLC, asumsi bahwa ada banyak hasil yang mungkin dari acara tersebut, ada banyak tanda tangan yang harus dibuat dan diserahkan kepada pihak lain sebelumnya, ini juga merupakan beban yang besar; Selain itu, keuntungan kontrak DLC terikat langsung pada kunci publik, sehingga posisinya sulit untuk dipindahkan, apakah ada cara untuk mentransfer posisi kontrak?

实inya, komunitas Bitcoin sebenarnya telah menemukan jawaban untuk masalah-masalah ini, yang pada dasarnya terkait dengan proposal Sighash (BIP-118 AnyPrevOut).

Namun, jika kita memprogram di CKB, BIP-118 akan tersedia sekarang (kemampuan untuk mensimulasikan label Sighash ini dengan introspeksi dan verifikasi tanda tangan yang ditargetkan).

Melalui pembelajaran pemrograman Bitcoin, kita tidak hanya mengetahui bagaimana memprogram dalam format "output transaksi" (apa yang dapat diprogram oleh CKB), tetapi juga mengetahui metode perbaikan aplikasi-aplikasi ini (bagaimana kita dapat menggunakan kemampuan CKB untuk memperbaikinya jika kita memprogram aplikasi-aplikasi ini di CKB). Bagi pengembang CKB, pemrograman berbasis skrip Bitcoin bisa dianggap sebagai materi pembelajaran, bahkan jalan pintas.

Di bawah ini, kita akan menganalisis kemampuan pemrograman dari setiap modul dalam pemrograman CKB. Kita akan mengabaikan kemampuan introspeksi terlebih dahulu.

Programmabilitas Lock untuk Komputasi Sembarang

UTXO seperti yang disebutkan di atas tidak dapat diprogram untuk perhitungan sembarangan. Namun Lock dapat melakukannya, yang berarti Lock dapat memprogram segala sesuatu yang berkaitan dengan UTXO (sebelum penerapan klausa pembatasan), termasuk namun tidak terbatas pada saluran kilat dan DLC yang disebutkan sebelumnya.

Selain itu, kemampuan untuk menghitung yang dapat diverifikasi ini juga membuat Lock memiliki lebih banyak metode verifikasi identitas yang dapat digunakan daripada UTXO, dan lebih fleksibel. Misalnya, kita dapat mengimplementasikan saluran kilat di CKB di mana satu pihak menggunakan tanda tangan ECDSA dan pihak lainnya menggunakan tanda tangan RSA.

Sebenarnya, ini adalah salah satu area yang pertama kali dijelajahi oleh orang-orang di CKB: menggunakan kemampuan otentikasi identitas yang fleksibel ini dalam pengamanan yang mandiri oleh pengguna, untuk mencapai apa yang disebut sebagai "abstraksi akun" - otorisasi transaksi dan pemulihan kontrol yang sangat fleksibel, hampir tanpa batasan. Secara prinsip, ini menggabungkan "cabang pengeluaran yang beragam" dan "metode otentikasi identitas yang bebas". Beberapa contoh implementasinya adalah: JoyID Wallet, UniPass.

Selain itu, Lock juga dapat mengimplementasikan proposal eltoo, sehingga hanya perlu menyimpan transaksi janji pembayaran terbaru dalam saluran kilat (sebenarnya, eltoo dapat menyederhanakan semua kontrak peer-to-peer).

**Tipe **Programmabilitas komputasi sembarang

Sebagaimana yang disebutkan di atas, salah satu penggunaan utama dari Type adalah untuk memprogram UDT. Dengan menggunakan Lock, ini berarti kita dapat mengimplementasikan saluran kilat yang memiliki UDT sebagai subjek (dan kontrak jenis lainnya).

Sebenarnya, pemisahan Lock dan Type dapat dianggap sebagai peningkatan keamanan: Lock berfokus pada implementasi metode penyimpanan atau protokol kontrak, sedangkan Type berfokus pada definisi UDT.

此外，基于 UDT 的定义启动检查的能力，还使得 UDT 能够以跟 CKB 类似的方式参与合约（UDT is first-class citizen）。

Contoh: Saya pernah mengusulkan protokol jaminan pinjaman NFT tanpa kepercayaan yang diimplementasikan di Bitcoin. Kunci dari protokol ini adalah transaksi janji, di mana nilai input lebih kecil dari nilai output (sehingga transaksi ini tidak efektif), namun begitu transaksi ini memiliki cukup input, maka transaksi tersebut menjadi efektif: ketika peminjam dapat melunasi pinjaman, pemberi pinjaman tidak dapat mengklaim NFT yang dijaminkan. Namun, kepercayaan bebas dalam transaksi janji ini bergantung pada pemeriksaan jumlah input dan output, sehingga peminjam hanya dapat menggunakan Bitcoin untuk melunasi pinjaman - bahkan jika peminjam dan pemberi pinjaman setuju untuk menerima mata uang lain (seperti USDT yang diterbitkan dengan protokol RGB), transaksi janji Bitcoin tidak dapat menjamin bahwa NFT dapat dikembalikan hanya dengan melunasi USDT yang cukup, karena transaksi Bitcoin sama sekali tidak mengetahui status USDT! (Revisi: Dengan kata lain, tidak mungkin untuk membuat transaksi janji yang bergantung pada pembayaran dengan USDT.)

Jika kami dapat melakukan pemeriksaan berdasarkan definisi UDT, peminjam dapat menandatangani transaksi komitmen lain yang memungkinkan peminjam menggunakan USDT untuk pembayaran. Transaksi akan memeriksa jumlah USDT yang dimasukkan dan jumlah USDT yang dikeluarkan, memberikan pemulihan pembayaran menggunakan USDT ke pengguna secara tidak dapat dipercaya.

修订：Menyatakan bahwa jika NFT yang digunakan sebagai jaminan dan token yang digunakan untuk pembayaran dikonfigurasi menggunakan protokol yang sama (misalnya RGB), maka masalah di sini dapat diselesaikan. Kita dapat membuat transaksi komitmen berdasarkan protokol RGB untuk mengatur transisi status NFT dan pembayaran secara bersamaan (mengikat dua transisi status dalam protokol RGB). Namun, karena transaksi RGB juga bergantung pada transaksi Bitcoin, konstruksi transaksi komitmen di sini akan memiliki tingkat kesulitan tertentu. Secara keseluruhan, meskipun masalah dapat diselesaikan, tidak memungkinkan untuk membuat token sebagai warga kelas satu.

Selanjutnya, mari kita pertimbangkan kemampuan introspeksi.

Lock membaca Lock lainnya.

这 berarti setelah implementasi proposal pembatasan syarat, semua potensi pemrograman pada UTXO Bitcoin akan terbatas. Ini termasuk kontrak brankas yang disebutkan sebelumnya, serta aplikasi berbasis OP_CTV (seperti kontrol kemacetan).

XueJie pernah memberikan contoh yang sangat menarik: Anda dapat mengimplementasikan sebuah Cell akun penerimaan di CKB, ketika menggunakan Cell ini sebagai input transaksi, jika Cell output (yang menggunakan Lock yang sama) memiliki kapasitas yang lebih besar, maka input ini tidak perlu menyediakan tanda tangan dan tidak akan mempengaruhi kevalidan transaksi. Sebenarnya, tanpa kemampuan introspeksi, jenis Cell ini tidak dapat diimplementasikan. Cell akun penerimaan ini sangat cocok sebagai metode penerimaan lembaga, karena dapat mengumpulkan dana, namun kelemahannya adalah privasinya rendah.

Membaca Type s lainnya (dan Data)

Kemampuan yang menarik dari ini adalah aplikasi Token Ekuitas. Lock akan menentukan apakah dia dapat menggunakan Kapasitas sendiri dan di mana Kapasitas tersebut dapat digunakan berdasarkan jumlah Token dalam input lainnya (memerlukan kemampuan introversi Lock).

Type 01928374656574839201 Lock s

不 pasti, tetapi bisa diasumsikan bermanfaat. Misalnya, Anda dapat memeriksa kunci input dan output transaksi dalam Type untuk memastikan Lock s tetap tidak berubah.

Membaca Type s Lain (dan Data) dalam Type Scirpt

Kartu tukar? Mengumpulkan n token dapat ditukar dengan token yang lebih besar :)

Kesimpulan

Dibandingkan dengan sistem kontrak pintar yang dapat diprogram sebelumnya (seperti Ethereum), Nervos Network mengadopsi struktur yang berbeda; oleh karena itu, pemahaman terhadap sistem kontrak pintar sebelumnya seringkali sulit menjadi dasar pemahaman Nervos Network. Artikel ini dimulai dengan pemrograman aplikasi dari struktur yang lebih terbatas daripada CKB Cell - BTC UTXO - dan menyajikan metode pemahaman tentang kemampuan pemrograman CKB Cell. Dengan menggunakan konsep "introspeksi" untuk memahami kemampuan "akses lintas kontrak" dari Cell, kita dapat mengidentifikasi situasi di mana kemampuan introspeksi dapat digunakan dan menentukan penggunaan yang spesifik untuknya.

Revisi:

1. Tanpa mempertimbangkan kemampuan akses silang dari Cell (yaitu kemampuan introspeksi), lock s dapat dianggap sebagai Bitcoin dengan status dan kemampuan pemrograman yang sangat canggih, oleh karena itu hanya dengan ini saja dapat melakukan pemrograman untuk semua aplikasi yang berbasis Bitcoin.

2. Tidak mempertimbangkan kemampuan akses silang dari sel (yaitu kemampuan introspeksi), pemisahan antara kunci s dan tipe s dapat dianggap sebagai peningkatan keamanan: ini memisahkan definisi aset UDT dan metode pengawetannya; Selain itu, implementasi tipe s yang dapat mengungkapkan status (serta Data) mencapai efek UDT adalah warga negara kelas satu.

Artinya, ada sesuatu yang memiliki paradigma yang sama dengan "BTC + RGB" tetapi dengan kemampuan pemrograman yang lebih kuat.

3. Mengingat kemampuan introspeksi Cell, Cell dapat memiliki kemampuan pemrograman yang lebih kuat daripada post-covenants BTC UTXO dan mencapai beberapa hal yang sulit dicapai oleh BTC + RGB (karena BTC tidak dapat membaca status RGB).

Tentang penggunaan ini, artikel ini tidak dapat menyajikan banyak contoh spesifik, tetapi hal ini disebabkan oleh kurangnya pemahaman penulis terhadap ekosistem CKB. Seiring berjalannya waktu, saya yakin orang-orang akan semakin banyak menginvestasikan imajinasi mereka di dalamnya, menciptakan aplikasi yang sulit dibayangkan saat ini.

Terima kasih

Terima kasih kepada Retric, Jan Xie, dan Xue Jie atas umpan balik yang diberikan selama proses penulisan artikel. Tentu saja, semua kesalahan dalam tulisan ini adalah tanggung jawab saya sendiri.

Referensi:

5._07_05_pengenalan_model_validasi_programming_ckb/

6. (二) Kontrak Log Hatihati (DLC)

13.\_PERTANYAAN/perbincangan/7