RGB++ dan pengikatan isomorfik: Bagaimana CKB, Cardano, dan Fuel memberdayakan ekosistem Bitcoin

Penulis: Tunjukkan, geek web3

Editor: Faust, geek web3

**Abstrak:****·**Protokol aset RGB++ yang diusulkan oleh tim CKB mengusulkan gagasan **“pengikatan isomorfik”. Intinya adalah menggabungkan CKB dengan Cardano, Fuel, dan blockchain lain berdasarkan UTXO model pemrograman.Sebagai lapisan perluasan fungsi yang membawa “wadah” aset RGB. **Pengikatan isomorfik ini juga berlaku untuk protokol aset ekologi Bitcoin dengan karakteristik UTXO seperti Atomical dan Runes, sehingga memudahkan pembuatan lapisan kontrak pintar off-chain untuk Bitcoin.

**·**Dalam protokol RGB++, pengguna tidak perlu menjalankan klien untuk memverifikasi data transaksi secara pribadi. Mereka dapat menyerahkan pekerjaan verifikasi validitas aset dan penyimpanan data ke rantai UTXO seperti CKB dan Cardanao. Selama Anda “optimis” dan yakin bahwa keamanan rantai publik di atas relatif dapat diandalkan, Anda tidak perlu memverifikasinya sendiri;

**·**Protokol RGB++ mendukung pengguna untuk beralih kembali ke mode verifikasi klien. Saat ini, Anda masih dapat menggunakan CKB sebagai lapisan penyimpan data/DA tanpa harus menyimpan data sendiri. Protokol RGB++ tidak memerlukan aset lintas rantai, dan dapat mengoperasikan aset pada rantai CKB melalui akun Bitcoin, dan dapat mengurangi frekuensi penerbitan Komitmen pada rantai Bitcoin, yang juga kondusif untuk mendukung skenario Defi;

**·**Jika berada di bawah sistem kontrak EVM, banyak fitur RGB++ yang tidak mudah didukung. Secara keseluruhan, lapisan ekspansi rantai publik/fungsi yang cocok untuk mewujudkan pengikatan isomorfik harus memiliki karakteristik berikut:

**1.**Gunakan model UTXO atau skema penyimpanan negara serupa;

2. Ia memiliki kemampuan program UTXO yang cukup besar, memungkinkan pengembang untuk menulis skrip pembuka kunci;

3. Terdapat ruang status terkait UTXO yang dapat menyimpan status aset;

4. Dapat mendukung pengoperasian light node Bitcoin melalui kontrak pintar atau cara lain;

**·****Selain CKB, Cardano dan Fuel juga dapat mendukung pengikatan isomorfik. **Namun, dua yang terakhir mungkin memiliki beberapa kelebihan dalam hal bahasa kontrak cerdas dan detail desain kontrak. Saat ini, CKB lebih rendah daripada CKB Keduanya lebih cocok sebagai lapisan perluasan fungsi dari protokol aset Bitcoin yang terikat secara isomorfik.

Teks: Dalam RGB++Protocol LightPaper, salah satu pendiri Nervos CKB, Cipher, mengusulkan ide produk pengikatan isomorfik untuk pertama kalinya. Dibandingkan dengan solusi Bitcoin Layer 2 lainnya, pengikatan isomorfik lebih kompatibel dengan protokol aset seperti RGB, Runes, dan Atomical, dan dapat menghindari faktor-faktor seperti aset lintas rantai yang membawa beban keamanan tambahan.

Sederhananya, pengikatan isomorfik menggunakan UTXO pada rantai CKB dan Cardano sebagai “wadah” untuk mengekspresikan aset UTXO seperti RGB, sehingga menambah kemampuan program dan skenario yang lebih kompleks. Sebelumnya, Geek web3 telah merangkum serangkaian blockchain yang mendukung UTXO yang dapat diprogram dalam “Dari BTC ke Sui, ADA dan Nervos: Model UTXO dan Ekstensi Terkait”. Artikel ini akan mengeksplorasi lebih lanjut apakah blockchain ini dapat beradaptasi dengan skema pengikatan Struktur yang sama.

RGB++ dan pengikatan isomorfik

Sebelum menganalisis kompatibilitas rantai UTXO yang berbeda dengan pengikatan isomorfik, pertama-tama kita harus memperkenalkan prinsip pengikatan isomorfik. Pengikatan isomorfik adalah konsep yang diusulkan oleh tim CKB dalam protokol RGB++, jadi di sini kami menggunakan alur kerja RGB++ untuk memperkenalkan apa itu pengikatan isomorfik berbasis CKB.

Sebelum memperkenalkan protokol RGB++, mari kita pahami secara singkat protokol RGB. RGB adalah protokol aset/jaringan P2P yang berjalan di bawah rantai Bitcoin, mirip dengan Lightning Network. Selain itu, RGB juga merupakan protokol aset parasit berdasarkan Bitcoin UTXO. Yang disebut parasitisme berarti bahwa klien RGB akan mendeklarasikan di bawah rantai Bitcoin yang mana UTXO pada rantai Bitcoin terikat dengan aset RGB tertentu. Anda memiliki UTXO ini, the Aset RGB yang terikat padanya juga siap membantu Anda.

Protokol RGB dan protokol aset seperti ERC-20 beroperasi dengan cara yang sangat berbeda. Kontrak ERC-20 di Ethereum mencatat status aset semua pengguna, dan klien node Ethereum akan menyinkronkan dan memverifikasi semua informasi transfer, dan mencatat pembaruan status setelah transfer dalam kontrak aset. Hal ini sebenarnya sudah diketahui orang sejak lama, dan tidak lebih dari mengandalkan proses konsensus Ethereum untuk memastikan perubahan status aset berjalan lancar. Karena konsensus node Ethereum sangat andal, pengguna dapat menggunakan platform penyimpanan aset berdasarkan kontrak ERC-20 secara default sebagai “tidak ada masalah” bahkan jika mereka tidak menjalankan klien.

Namun protokol RGB sangat aneh, untuk meningkatkan privasi, ia hanya menghapus konsensus node/klien, yang merupakan hal konvensional di dunia blockchain. Pengguna harus menjalankan klien RGB sendiri dan hanya menerima dan menyimpan “data aset yang terkait dengan diri mereka sendiri”. Mereka tidak dapat melihat apa yang telah dilakukan orang lain. Tidak seperti Ethereum dan ERC-20, semua catatan transfer terlihat di rantai.

Dalam hal ini, jika seseorang mentransfer sejumlah aset RGB kepada Anda, Anda tidak mengetahui sebelumnya bagaimana uang itu diciptakan dan dari siapa uang itu berpindah tangan. Jika orang di sisi lain mendeklarasikan suatu aset secara tiba-tiba dan kemudian mentransfer sebagian darinya kepada Anda, bagaimana Anda menghadapi skenario jahat pemalsuan mata uang ini?

Protokol RGB mengadopsi ide ini: sebelum setiap transfer berlaku, penerima terlebih dahulu meminta pengirim untuk menunjukkan seluruh riwayat aset, seperti siapa yang menerbitkan aset tersebut dari tahap pembuatan hingga saat ini, dan siapa yang melewatinya di tengah. , apakah setiap pengalihan aset yang terjadi antara orang-orang tersebut tidak melanggar standar akuntansi (satu orang menambah, satu orang mengurangi).

Dengan cara ini, Anda dapat mengetahui apakah pihak lain memberi Anda “uang yang dipertanyakan”, jadi inti dari RGB adalah membiarkan pihak-pihak yang bertransaksi menjalankan klien untuk verifikasi.Berdasarkan mode verifikasi klien, ini sesuai dengan orang yang rasional hipotesis permainan Selama pihak-pihak yang terlibat rasional dan tidak ada masalah dengan perangkat lunak klien, maka dapat dijamin bahwa pengalihan aset yang dimaksud tidak akan berlaku atau dikenali oleh orang lain.

Perlu dicatat bahwa protokol RGB akan memampatkan data transaksi di bawah rantai Bitcoin menjadi Komitmen (pada dasarnya akar merekle) dan mengunggahnya ke rantai Bitcoin. Hal ini akan memungkinkan catatan transfer di bawah rantai tersebut terhubung langsung ke Bitcoin. jaringan utama Buat sambungan.

Karena tidak ada konsensus di antara klien RGB, pelepasan kontrak aset RGB tidak dapat disebarkan “sangat andal” ke semua node. Penerbit kontrak dan pengguna cukup mempelajari detail kontrak aset RGB secara spontan melalui formulir apa pun seperti email atau Twitter. , bentuknya sangat kasual.

Gambar di bawah menunjukkan skenario transfer aset RGB yang berbahaya. Sebagai pengguna RGB, kita perlu menyimpan kontrak pintar yang sesuai dengan aset RGB secara lokal di klien kita. Ketika orang lain mentransfer uang kepada kami, kami dapat mengetahui apakah transfer saat ini melanggar aturan yang ditentukan dalam kontrak berdasarkan konten kontrak aset yang disimpan secara lokal. Berdasarkan informasi sumber aset (catatan sejarah) yang diberikan oleh pihak lain, Anda dapat memastikan apakah ada masalah dengan sumber aset pihak lain (apakah dinyatakan begitu saja).

Meninjau proses di atas, tidak sulit untuk melihat bahwa data yang diterima dan disimpan oleh klien RGB yang berbeda seringkali bersifat independen, dan Anda sering tidak mengetahui aset apa yang dimiliki orang lain dan berapa jumlahnya. Pada gilirannya, orang lain pada dasarnya tidak mengetahui status aset Anda.

Ini adalah pulau data yang khas, yaitu data yang disimpan oleh setiap orang tidak konsisten. Meskipun secara teoritis dapat meningkatkan privasi, hal ini juga membawa banyak masalah. Anda harus menyimpan data aset RGB secara lokal di klien Anda. Jika data ini hilang, akan menimbulkan konsekuensi serius (aset tidak akan tersedia). Namun faktanya, selama Anda menjaga data lokal dengan baik, protokol RGB dapat memberi Anda keamanan yang pada dasarnya setara dengan mainnet Bitcoin.

Selain itu, protokol Bifrost yang digunakan untuk komunikasi antar klien RGB akan membantu pengguna dalam komunikasi p2p dengan klien lain.Mereka dapat mengenkripsi data aset mereka dan menyebarkannya ke node lain, dan meminta pihak lain untuk membantu menyimpannya (perhatikan bahwa itu dienkripsi data, sebaliknya Tidak tahu teks jelasnya). Selama Anda tidak kehilangan kuncinya, ketika data lokal hilang, Anda dapat memulihkan data aset yang semula Anda miliki melalui node lain di jaringan.

Namun kekurangan dari protokol RGB asli masih terlihat jelas. Pertama, setiap transaksi memerlukan banyak komunikasi antara kedua pihak. Pihak penerima harus terlebih dahulu memverifikasi sumber aset pengirim, kemudian mengirimkan tanda terima untuk menyetujui permintaan transfer pengirim. Selama proses ini, setidaknya tiga pesan harus disampaikan antara kedua pihak. “Transfer interaktif” semacam ini sangat tidak sesuai dengan “transfer non-interaktif” yang biasa dilakukan kebanyakan orang. Bayangkan jika seseorang ingin mentransfer uang kepada Anda, mereka harus mengirimkan data transaksi kepada Anda untuk diperiksa dan diterima. kwitansi anda Apakah proses transfer hanya dapat diselesaikan setelah menerima pesan? (Diagram alirnya dapat dilihat pada artikel sebelumnya)

Kedua, sebagian besar skenario Defi memerlukan kontrak pintar dengan data transparan dan status yang dapat diverifikasi, namun protokol RGB secara inheren tidak mendukung skenario seperti itu, sehingga sangat tidak bersahabat dengan Defi; selain itu, pengguna dalam protokol RGB harus menjalankan klien Untuk verifikasi mandiri , jika Anda secara tidak sengaja menerima aset yang berpindah tangan puluhan ribu orang, Anda bahkan perlu memverifikasi catatan puluhan ribu kali aset tersebut berpindah tangan. Jelas sekali, membiarkan pengguna menyelesaikan semuanya sendiri tidak kondusif bagi promosi dan adopsi produk itu sendiri.

Untuk permasalahan di atas, solusi dari RGB++ adalah dengan memberikan kebebasan kepada pengguna untuk beralih antara mode verifikasi mandiri klien dan mode hosting pihak ketiga. Pengguna dapat menyerahkan beban verifikasi dan penyimpanan data, hosting kontrak cerdas, dll kepada CKB. Tentu saja, Pengguna harus optimis dan percaya bahwa rantai publik POW CKB dapat diandalkan; jika beberapa orang lebih mengutamakan keamanan dan privasi, seperti investor besar dengan aset dalam jumlah besar, mereka juga dapat kembali ke mode RGB asli. Yang harus ditekankan di sini adalah bahwa RGB++ dan protokol RGB asli secara teori kompatibel satu sama lain, dan tidak saling eksklusif.

Pada artikel sebelumnya “Dari RGB ke RGB++: Bagaimana CKB memberdayakan Protokol Aset Ekologis Bitcoin”, kami secara singkat mempopulerkan “pengikatan isomorfik” dari RGB++. Di sini kami akan mengulas secara singkat:

CKB memiliki UTXO tambahannya sendiri yang disebut Cell, yang lebih dapat diprogram daripada UTXO pada rantai BTC. “Pengikatan isomorfik” adalah menggunakan Sel pada rantai CKB sebagai “wadah” untuk data aset RGB, dan menulis parameter kunci aset RGB ke dalam Sel.

Karena terdapat hubungan yang mengikat antara aset RGB dan Bitcoin UTXO, bentuk logis dari aset tersebut memiliki karakteristik UTXO. Sel yang juga memiliki karakteristik UTXO tentu saja cocok sebagai “wadah” aset RGB. Setiap kali transaksi aset RGB terjadi, wadah Sel yang sesuai juga dapat menunjukkan karakteristik serupa, seperti hubungan antara entitas dan bayangan.Ini adalah inti dari “pengikatan isomorfik”.

Misalnya, jika Alice memiliki 100 token RGB dan UTXO A di rantai Bitcoin, dan memiliki Sel di rantai CKB, Sel ini ditandai dengan “Saldo Token RGB: 100”, dan kondisi pembukaan kunci terkait dengan UTXO A. .

Jika Alice ingin mengirim 30 token ke Bob, dia dapat membuat Komitmen terlebih dahulu. Pernyataan yang sesuai adalah: transfer 30 token RGB yang terkait dengan UTXO A ke Bob, dan transfer 70 ke UTXO lain yang dia kendalikan.

Setelah itu, Alice menghabiskan UTXO A pada rantai Bitcoin, menerbitkan pernyataan di atas, dan kemudian memulai transaksi pada rantai CKB untuk menggunakan wadah Sel yang membawa 100 token RGB dan menghasilkan dua wadah baru, satu menampung 30 token (ke Bob), satu memegang 70 token (dikendalikan oleh Alice). Dalam proses ini, tugas verifikasi validitas aset Alice dan validitas pernyataan transaksi diselesaikan oleh node jaringan CKB melalui konsensus, tanpa campur tangan Bob. CKB sekarang bertindak sebagai lapisan verifikasi dan lapisan DA di bawah rantai Bitcoin.

Hal ini mirip dengan fakta bahwa setiap kali status kontrak Ethereum ERC-20 berubah, pengguna tidak diharuskan menjalankan verifikasi klien. Prinsipnya serupa. Protokol konsensus dan jaringan node menggantikan verifikasi klien. Selain itu, data aset RGB setiap orang disimpan di rantai CKB, yang dapat diverifikasi secara global, sehingga kondusif untuk penerapan skenario Defi, seperti kumpulan likuiditas dan protokol jaminan aset.

Hal ini sebenarnya memperkenalkan asumsi kepercayaan yang penting: pengguna cenderung optimis bahwa rantai CKB, atau platform jaringan yang terdiri dari sejumlah besar node yang mengandalkan protokol konsensus, dapat diandalkan dan bebas kesalahan. Jika Anda tidak mempercayai CKB, Anda juga dapat mengikuti proses komunikasi interaktif dan verifikasi dalam protokol RGB asli dan menjalankan klien sendiri.

Tentu saja, jika seseorang ingin menjalankan sendiri klien RGB++ dan memverifikasi sumber historis aset orang lain, ia dapat langsung memverifikasi riwayat terkait Cell container aset RGB di rantai CKB. Selama Anda menjalankan light node CKB dan menerima header blok Merkle Proof dan CKB, Anda dapat yakin bahwa data historis yang Anda terima belum dirusak oleh penyerang jahat di jaringan. Dapat dikatakan bahwa CKB berperan sebagai lapisan penyimpanan data historis di sini.

Sederhananya, pengikatan isomorfik tidak hanya berlaku untuk RGB, tetapi juga untuk berbagai protokol aset dengan karakteristik UTXO seperti Runes dan Atomic. Ini menyimpan status aset, data historis, dan kontrak pintar terkait secara lokal di klien pengguna. Semua ditransfer ke rantai publik UTXO seperti CKB atau Cardano untuk penyimpanan dan hosting. Protokol aset tipe UTXO yang disebutkan di atas dapat menggunakan model UTXO dari CKB atau Cardano sebagai “wadah” untuk menampilkan bentuk dan status aset melalui wadah tersebut, yang berguna untuk mencocokkan kontrak pintar dan skenario lainnya.

Selain itu, di bawah protokol pengikatan isomorfik, pengguna dapat langsung menggunakan akun Bitcoin untuk mengoperasikan wadah aset RGB mereka sendiri pada rantai UTXO seperti CKB tanpa rantai silang.Mereka hanya perlu menggunakan karakteristik UTXO Sel untuk mengatur kondisi pembukaan kunci Sel container. Itu hanya perlu dikaitkan dengan alamat Bitcoin/Bitcoin UTXO tertentu. Karena kami telah menjelaskan karakteristik Sel dalam artikel sains populer RGB++ Geekweb3 sebelumnya, kami tidak akan membahas detailnya di sini.

Jika kedua belah pihak dalam transaksi aset RGB mempercayai keamanan CKB, mereka bahkan tidak perlu sering mempublikasikan Komitmen pada rantai Bitcoin. Mereka dapat mengirimkan Komitmen ke rantai Bitcoin setelah banyak transfer RGB dilakukan. Ini disebut "transaksi lipat Fungsi " ” dapat mengurangi biaya penggunaan.

Namun, perlu dicatat bahwa “wadah” yang digunakan dalam pengikatan isomorfik sering kali memerlukan rantai publik yang mendukung model UTXO, atau infra dengan karakteristik serupa dalam penyimpanan negara, dan rantai EVM jelas tidak cocok, dan akan ada masalah teknis. masalah implementasi Mengalami banyak kendala. Pertama-tama, seperti disebutkan sebelumnya, RGB++ “dapat mengoperasikan kontainer aset pada rantai CKB tanpa lintas rantai”, yang pada dasarnya tidak mungkin diterapkan pada rantai EVM; bahkan jika diterapkan secara paksa, biayanya mungkin sangat tinggi;

Selain itu, dalam protokol RGB++, banyak orang tidak perlu menjalankan klien atau menyimpan data aset secara lokal. Jika metode ERC-20 digunakan untuk mencatat saldo aset setiap orang dalam kontrak ini, jika seseorang ingin kembali ke mode verifikasi mandiri klien dan mengusulkan untuk memeriksa sumber aset seseorang, saat ini dia mungkin harus Memindai semua transaksi catatan yang berinteraksi dengan kontrak aset akan membawa tekanan besar.

Terus terang, kontrak aset seperti ERC-20 berpasangan dan menyimpan status aset semua orang. Jika Anda ingin memeriksa riwayat perubahan aset salah satunya secara individual, itu akan menjadi sulit, seperti di ruang obrolan publik, jika Anda ingin tahu siapa yang mengirim pesan ke Wang Gang, Anda harus menelusuri catatan pesan di seluruh ruang obrolan. UTXO seperti saluran obrolan pribadi satu lawan satu, dan mudah untuk memeriksa riwayatnya.

Secara keseluruhan, lapisan ekspansi rantai publik/fungsi yang cocok untuk mewujudkan pengikatan isomorfik harus memiliki karakteristik berikut:

1. Gunakan model UTXO atau solusi penyimpanan negara serupa;
2. Ia memiliki kemampuan program UTXO yang cukup besar, memungkinkan pengembang untuk menulis skrip pembuka kunci;
3. Terdapat ruang negara terkait UTXO yang dapat menyimpan status aset;
4. Ada jembatan atau light node yang berhubungan dengan Bitcoin;

Tentunya kami juga berharap rantai publik yang digunakan untuk pengikatan isomorfik memiliki keamanan yang kuat.Di sisi lain, kami juga berharap kondisi pembukaan kunci UTXO pada rantai publik harus dapat diprogram, sehingga pengguna dapat langsung menggunakan skema tanda tangan BTC untuk membuka kunci. UTXO Anda terikat secara isomorfik pada rantai publik lain tanpa mengubah algoritma tanda tangan.

Saat ini, skrip penguncian UTXO di CKB dapat diprogram, dan pejabat tersebut juga kompatibel dengan skema tanda tangan dari rantai publik yang berbeda.Untuk pengikatan isomorfik, **jaringan CKB pada dasarnya memenuhi karakteristik di atas, dan berbasis UTXO lainnya. rantai? Kami telah melakukan pemeriksaan awal terhadap Fuel dan Cardano dan yakin bahwa keduanya secara teoritis dapat mendukung pengikatan isomorfik. **

Bahan Bakar: Ethereum OP Rollup berdasarkan UTXO

Fuel adalah Ethereum OP Rollup berdasarkan UTXO, dan merupakan pionir dalam memperkenalkan konsep bukti penipuan ke dalam ekosistem Ethereum Layer 2. Untuk dukungan fungsi UTXO normal, Bahan Bakar pada dasarnya konsisten dengan BTC.

Bahan bakar membagi UTXO internalnya ke dalam tiga kategori berikut:

**Input Coin: **UTXO standar, digunakan untuk mewakili aset pengguna, memiliki kunci waktu asli, dan memungkinkan pengguna untuk menulis predikat skrip pembuka kunci;

Kontrak Masukan: UTXO digunakan untuk panggilan kontrak, yang berisi data seperti akar status kontrak dan aset kontrak;

Pesan Masukan: UTXO digunakan untuk mengirimkan informasi, terutama mencakup bidang seperti penerima informasi;

Saat pengguna membelanjakan UTXO, output berikut akan dihasilkan:

Koin Keluaran: Digunakan untuk transfer aset standar;

Kontrak Keluaran: Output yang dihasilkan oleh interaksi kontrak, yang berisi akar status setelah interaksi kontrak;

Kontrak Keluaran yang Dibuat: Jenis UTXO khusus, yang merupakan keluaran yang dihasilkan saat membuat kontrak. Ini berisi ID dan akar status kontrak;

Berbeda dengan Sel CKB, yang memuat semua status kontrak secara internal, UTXO Bahan Bakar sebenarnya tidak memuat semua status kontrak terkait transaksi. Bahan bakar hanya membawa akar status kontrak Stateroot di UTXO, yang merupakan akar pohon negara. Status kontrak yang lengkap disimpan di dalam perpustakaan negara bagian Fuel dan dimiliki oleh kontrak pintar.

**Perlu disebutkan bahwa mengenai pemrosesan status kontrak pintar, kontrak Bahan Bakar dan kontrak soliditas secara ideologis konsisten dan bahkan relatif dekat dalam bentuk pemrograman. **Gambar di bawah menunjukkan kontrak penghitung yang ditulis dalam bahasa Sway Fuel. Kontrak berisi penghitung. Saat pengguna memanggil fungsi incremen_counter, penghitung yang disimpan dalam kontrak akan bertambah 1.

Kita dapat melihat bahwa logika penulisan kontrak Sway mirip dengan kontrak Soliditas pada umumnya. Pertama-tama kita berikan ABI kontraknya, lalu variabel status kontraknya, dan kemudian implementasi spesifik kontraknya. Semua proses penulisan kode tidak melibatkan sistem UTXO Fuel.

Oleh karena itu, pengalaman pemrograman kontrak Fuel berbeda dengan bahasa pemrograman UTXO seperti CKB dan Cardanao, Fuel memberikan pengalaman yang lebih dekat dengan pemrograman dan pengembangan kontrak pintar EVM. Pengembang juga dapat menggunakan bahasa Sway untuk membuat skrip pembuka kunci guna menerapkan logika verifikasi algoritma tanda tangan khusus atau logika pembukaan kunci multi-tanda tangan yang kompleks.

Pada dasarnya penerapan pengikatan isomorfik pada Bahan Bakar dapat dilakukan, namun masih terdapat permasalahan berikut:

Bahasa pengaruh yang digunakan oleh Fuel lebih mirip dengan rantai EVM dalam hal desain kontrak pintar dibandingkan dengan BTC atau CKB dan Cardano. Penerbit aset UTXO seperti RGB dan Atomics perlu secara khusus membuat kontrak cerdas pada Bahan Bakar. CKB dan rantai lainnya menggunakan satu lagi, yang cukup rumit.

Cardano: rantai publik eUTXO berdasarkan POS

Cardaon adalah blockchain lain yang menggunakan model UTXO, tetapi tidak seperti Fuel, ini adalah rantai publik Lapisan 1. Cardano menggunakan eUTXO (extracted UTXO) untuk merujuk pada model pemrograman UTXO dalam sistemnya. Dibandingkan dengan CKB, eUTXO di Cardano berisi struktur berikut:

**:**Kontrak pintar, digunakan untuk memverifikasi apakah UTXO dapat dibuka dan melakukan transisi status;

Penebus: Data yang disediakan oleh pengguna untuk membuka kunci UTXO, biasanya data tanda tangan, mirip dengan Saksi Bitcoin;

Datum: Ruang status kontrak pintar, yang dapat menyimpan data seperti status aset;

Konteks Transaksi: Data konteks transaksi UTXO, seperti parameter input dan hasil transaksi (proses penghitungan transaksi rantai UTXO dilakukan langsung di luar rantai, dan hasil penghitungan diserahkan ke rantai untuk verifikasi. Jika lolos verifikasi maka hasil transaksi diupload ke chain.chain)

Pengembang dapat menggunakan bahasa PlutusCore untuk memprogram UTXO pada rantai Cardano. Mirip dengan CKB, pengembang dapat menulis skrip pembuka kunci dan beberapa fungsi untuk pembaruan status.

Kami memperkenalkan model pemrograman UTXO Cardano dengan proses lelang berbasis UTXO. Misalkan kita perlu menerapkan DAPP lelang aset yang mengharuskan pengguna memberikan tawaran sebelum lelang berakhir. Secara khusus, pengguna menggunakan UTXO miliknya, mengontrak UTXO dengan lelang ini, lalu membuat UTXO lelang baru. Ketika seseorang memberikan tawaran yang lebih tinggi, selain menghasilkan UTXO kontrak lelang baru, pengembalian dana UTXO untuk orang sebelumnya juga akan dihasilkan. Proses spesifiknya adalah sebagai berikut:

Untuk melaksanakan proses lelang di atas, beberapa negara bagian perlu menyimpan UTXO kontrak pintar lelang, seperti harga tertinggi lelang saat ini dan orang yang mengajukan penawaran. Gambar di bawah menunjukkan pernyataan status di dalam PlutusCore. Kita dapat melihat bahwa bBidder dan bAmount menampilkan tawaran lelang dan alamat dompet yang memberikan penawaran. Param Lelang berisi informasi dasar lelang.

Saat pengguna membelanjakan UTXO ini, kami dapat memperbarui status dalam kontrak. Gambar di bawah menunjukkan beberapa pembaruan status spesifik dan logika bisnis dalam kontrak lelang. Misalnya logika memverifikasi tawaran pengguna dan memverifikasi apakah lelang saat ini masih berlangsung. Tentu saja, karena PlutusCore adalah bahasa pemrograman Haskell, yang merupakan bahasa pemrograman yang berfungsi murni, sebagian besar pengembang mungkin tidak dapat memahami maknanya secara langsung. **

Adalah layak untuk membuat pengikatan isomorfik di Cardano. Kita dapat menggunakan Datum untuk menyimpan status aset dan menulis skrip tertentu agar kompatibel dengan algoritme tanda tangan terkait Bitcoin. Tetapi masalah seriusnya adalah sebagian besar pemrogram mungkin tidak dapat beradaptasi menggunakan PlutusCore untuk pemrograman kontrak, dan lingkungan pemrogramannya sulit diatur serta tidak ramah terhadap pengembang.

Ringkaslah

Pengikatan isomorfik mengharuskan rantai memiliki properti berikut:

1. Gunakan model UTXO
2. Memiliki kemampuan program UTXO yang cukup besar, memungkinkan pengembang untuk menulis skrip pembuka kunci
3. Terdapat state space terkait UTXO yang dapat menyimpan status aset
4. Mendukung pengoperasian light node Bitcoin melalui kontrak pintar atau cara lain.

Karena kekhasan ide pemrograman kontrak cerdasnya, Fuel kompatibel dengan pengikatan isomorfik, namun tetap membawa beberapa beban; sementara Cardaon menggunakan bahasa pemrograman Haskell untuk pemrograman kontrak, sehingga menyulitkan sebagian besar pengembang untuk memulai dengan cepat. Berdasarkan alasan di atas, CKB, yang mengadopsi set instruksi RISC-V dan karakteristik pemrograman UTXO yang lebih seimbang, mungkin merupakan lapisan perluasan fungsi yang lebih cocok untuk pengikatan isomorfik.