Apa potensi nyata dari protokol penerbitan aset BTC RGB?

Penulis**|**A Jian

Tautan asli:

Artikel ini mencoba untuk memberikan deskripsi singkat tentang RGB, protokol distribusi aset di BTC (yang juga dapat dipahami sebagai sistem kontrak pintar off-chain), dan menunjukkan perbedaannya dari protokol lain yang bertujuan untuk mencapai fungsi yang sama atau serupa, yang membuat protokol RGB jauh lebih terukur daripada mereka, dan menyisakan lebih banyak ruang untuk pemrograman. Selain memperkenalkan desain RGB yang sudah selesai, kami juga akan mengeksplorasi kemungkinan pemrograman ini.

Apa itu protokol RGB?

Ide menerbitkan aset di BTC sudah ada sejak lama. Namun protokol BTC memiliki karakteristiknya sendiri: statusnya dinyatakan oleh dan hanya oleh BTC UTXO (“output transaksi yang tidak terpakai”), UTXO hanya membawa dua bagian data: denominasinya sendiri (nilai BTC), dan “kunci publik skrip” (juga dikenal sebagai “skrip kunci”) yang digunakan untuk memprogram kondisi di mana dana dibelanjakan, seperti memberikan tanda tangan untuk kunci publik, dan opcode yang memungkinkan skrip penguncian diprogram disediakan oleh aturan konsensus BTC, yang tidak dapat digunakan untuk menerapkan aturan keamanan sewenang-wenang. Akibatnya, tidak mungkin membuat aset lain di dalam UTXO — skrip BTC tidak dapat memprogram pemeriksaan keamanan untuk aset tersebut. Ini berarti bahwa semua ide untuk menerbitkan aset di BTC pada dasarnya adalah penggunaan kreatif ruang blok BTC. Ini berarti bahwa kita perlu merancang sistem kontrak pintar off-chain dan mengharuskan informasi tentang langkah-langkah yang mengubah keadaan kontrak - misalnya, kontrak A mengubah parameter, B mentransfer sejumlah aset ke C - diunggah ke blockchain, sehingga keadaan terbaru dari sistem kontrak pintar dapat diperoleh dengan mengumpulkan informasi ini.

Ide desain kasar adalah mengunggah informasi langkah-langkah yang mengubah status kontrak ke blockchain BTC secara utuh. Tentu saja, ini dapat berhasil, namun akan menghadapi beberapa masalah: (1) karena pengunggahan informasi lengkap, itu dapat menghabiskan lebih banyak ruang blok, dan ketika pengguna perlu mengubah status kontrak (seperti transfer), mereka juga perlu membayar lebih banyak biaya on-chain. Secara khusus, ketika kita ingin sistem kontrak off-chain seperti itu memiliki programabilitas yang lebih baik daripada BTC, peningkatan programabilitas mungkin datang dengan biaya mengkonsumsi lebih banyak ruang blok: (2) informasi hampir di mana saja di blok memiliki potensi untuk mengubah kontrak pintar off-chain, sehingga pengguna harus mendapatkan semua data blok BTC untuk mendapatkan keadaan terbaru dari sistem kontrak off-chain, yaitu, lebih mahal untuk diverifikasi, (3) tergantung pada desain sistem kontrak pintar off-chain, itu mungkin hanya mendapatkan privasi yang sama atau bahkan lebih buruk seperti yang BTC, dan jika dapat memberikan lebih banyak privasi, mungkin perlu mengkonsumsi lebih banyak ruang blok。

Di masa lalu, protokol yang banyak digunakan yang disebut “Omni” tidak mengunggah informasi lengkap dari transaksi kontrak off-chain, hanya hash transaksi. Pendekatan ini memecahkan masalah 1 di atas dengan memisahkan kompleksitas transaksi kontrak off-chain dari biaya ekonomisnya, tetapi pengguna masih perlu mendapatkan jumlah penuh data blok BTC untuk mendapatkan status terbaru dari protokol Omni, dan itu tidak secara khusus meningkatkan privasi.

RGB, di sisi lain, menggunakan paradigma baru yang disebut “segel sekali pakai”. Cara kerjanya sederhana: RGB mensyaratkan bahwa setiap status dari setiap kontrak harus dilampirkan ke UTXO BTC, dan begitu status itu diubah, UTXO harus dibelanjakan sehingga transaksi yang menghabiskannya dikonfirmasi oleh blockchain, dan transaksi BTC yang menghabiskannya juga harus menyediakan hash transisi status untuk menunjukkan UTXO tempat status yang diubah dilampirkan.

Di mata pengembang RGB, desain ini mirip dengan segel plastik bernomor: mudah untuk mengetahui apakah sudah dilepas, dan setelah dilepas, itu tidak lagi dapat digunakan. Namun, cara lain untuk melihatnya adalah dengan menggunakan UTXO yang dimiliki sebagai wadah atau celengan keramik di negara bagian ini - untuk mengeluarkan uang dari celengan, Anda harus memecahkan celengan dan memasukkan uang ke dalam yang baru.

Desain ini sangat kontras dengan protokol sebelumnya yang memperlakukan seluruh blok sebagai papan surat besar: menggunakan UTXO sebagai wadah berarti bahwa transaksi yang tidak menghabiskan UTXO ini tidak dapat berpengaruh pada keadaan kontrak dalam wadah, jadi untuk memverifikasi keadaan kontrak tertentu, kita tidak perlu mendapatkan semua data blok, yang kita butuhkan hanyalah serangkaian transaksi BTC, bukti bahwa transaksi BTC ini ada dalam satu blok, dan RGB ini BTC komitmen pertukaran Transisi status (berpasangan dengan transaksi BTC terkait). Data ini, yang dapat digabungkan ke dalam rantai, harus memungkinkan kita untuk melacak kembali ke keadaan awal kontrak, memungkinkan kita untuk mengidentifikasi esensi dari keadaan ini.

Bagi pembaca yang akrab dengan sistem kontrak pintar on-chain (seperti ETH Fang), salah satu hal yang sulit dipahami tentang proses ini adalah jika tidak bergantung pada konsensus blockchain (yang berarti bahwa keadaan awal kontrak dan setiap perubahan keadaan akan diverifikasi oleh setiap node), bagaimana memastikan bahwa keamanan sistem kontrak pintar ini dijamin, bagaimana memastikan bahwa aset yang Anda terima adalah jenis yang Anda inginkan, dan bagaimana memastikan bahwa aset tersebut tidak diterbitkan secara ilegal?

Jawabannya sederhana, ini disebut “validasi sisi klien” – Anda memverifikasinya sendiri. Dalam sistem kontrak on-chain, node memverifikasi setiap operasi transisi status dan menolak operasi yang tidak valid sesuai dengan aturan transisi status publik, sehingga dapat menghitung status terbaru sesuai dengan status awal. Namun, selama aturan transisi negara dan keadaan awal dapat diketahui, verifikasi melalui konsensus on-chain bukan satu-satunya cara, dan pengguna dapat memverifikasi bahwa setiap langkah transisi negara mengikuti aturan transisi keadaan yang ditentukan semula berdasarkan informasi yang diberikan oleh pembayar. Dengan cara ini, pihak verifikasi (mungkin penerima aset) juga dapat mendeteksi transisi negara ilegal dan menolak untuk menerimanya.

Akhirnya, mari kita gunakan contoh untuk menggambarkan karakteristik protokol RGB:

Sekarang, Alice memiliki UTXO A ', yang memegang aset Y dari unit X yang dikeluarkan di bawah lisensi RGB, dan dia ingin mentransfer unit Z dari Y ke Bob. Butuh total 5 pemilik sebelumnya (termasuk penerbit) aset untuk mencapai Alice. Oleh karena itu, Alice ingin memberi Bob bukti dari 4 transisi negara bagian ini (3 yang pertama diberikan kepada Alice oleh pemilik sebelumnya), termasuk keadaan awal kontrak dan aturan transisi negara, transaksi BTC yang digunakan untuk setiap transfer, setiap transaksi RGB yang dilakukan BTC pertukaran, dan bukti bahwa transaksi BTC ini telah dikonfirmasi oleh blok, dan mengirimkannya ke Bob, yang akan memverifikasi 4 ini sesuai dengan aturan transisi negara bagian kontrak Transfer tanpa melanggar aturan, dan kemudian putuskan apakah akan menerimanya atau tidak. Ketika Alice membangun transaksi RGB, karena Z kurang dari X, dia juga mengatur UTXO untuk dirinya sendiri untuk menerima sisanya. Akhirnya, Alice menyematkan hash transaksi RGB ke dalam transaksi BTC yang membebani UTXO A 'untuk menyelesaikan pembayaran.

Akhirnya, berkat penggunaan kontainer UTXO, status terbaru dari kontrak RGB dapat direpresentasikan sebagai titik pada grafik asiklik terarah yang belum memiliki keturunan (setiap titik mewakili status yang disimpan di dalam kontainer UTXO). Dan, untuk pemilik P dalam diagram di bawah ini, dia hanya akan mengetahui proses dari keadaan awal G kontrak kepadanya, yang merupakan proses yang dilingkari merah, dan tidak akan tahu apa-apa tentang titik abu-abu:

Keuntungan RGB

Status Keren yang Dapat Diverifikasi

Seperti disebutkan di atas, RGB secara signifikan mengurangi biaya validasi (keadaan kontrak tertentu) dibandingkan dengan protokol penerbitan aset (sistem kontrak off-chain) yang sebelumnya telah muncul di BTC. Pada saat transaksi, penerima tidak perlu lagi mengulangi semua blok untuk mengumpulkan informasi tentang perubahan keadaan kontrak, tetapi hanya perlu mendapatkan serangkaian transaksi BTC, serta transaksi RGB yang dijanjikan oleh pertukaran ini, dan blok yang berisi bukti transaksi BTC ini (sesuai dengan bukti Merkle dari header blok), untuk yakin bahwa pembayar benar-benar memiliki sejumlah aset tertentu.

Pengurangan biaya verifikasi ini juga sangat mengurangi ketergantungan (kepercayaan) pengguna pada penyedia infrastruktur besar. Dalam protokol sebelumnya, karena tingginya biaya verifikasi, sulit bagi pengguna untuk menghitung sendiri status kontrak terbaru, sehingga pengguna harus mempercayai beberapa vendor (seperti penyedia status kontrak yang digunakan oleh dompet mereka), dan pada saat yang sama, karena ada lebih sedikit pemasok yang dapat menanggung biaya komputasi seperti itu, yang juga berarti bahwa vendor terpusat. Namun, dalam RGB, pengguna hanya perlu menggunakan klien ringan BTC untuk memeriksa bagian dari transaksi dengan BTC, dan menggunakan protokol RGB untuk memeriksa bagian dari transaksi RGB, dan mereka mampu membelinya.

Dibandingkan dengan beberapa sistem kontrak on-chain, RGB juga lebih ringan. Ini tercermin dalam fakta bahwa RGB dapat secara khusus memverifikasi keadaan kontrak tertentu, sementara pada sistem yang tidak didasarkan pada UTXO, karena kurangnya mekanisme untuk mengontrol akses seperti UTXO, transaksi apa pun dapat mengubah keadaan apa pun, sehingga hampir tidak mungkin untuk memverifikasi keadaan tertentu dengan cara yang ditargetkan, tetapi hanya dapat menentukan keadaan tertentu sambil menghitung semua keadaan terbaru - dalam pengertian ini, fitur yang dinyatakan sebagai “keadaan global” sebenarnya harus disebut " uniform state", meskipun menyediakan akses silang antar kontrak, itu juga menentukan bahwa akan lebih mahal untuk diverifikasi dan lebih sulit untuk mendapatkan bebas kepercayaan.

Optimalisasi yang signifikan pada protokol kontrak on-chain ini adalah persyaratan untuk header blok untuk berkomitmen ke status terbaru (“root state”), memungkinkan klien ringan untuk memvalidasi status kontrak tertentu dari node penuh terhadap komitmen ini. Ini adalah cara untuk menggunakan kembali perhitungan yang telah terjadi (perhitungan yang telah dijalankan oleh node penuh), dan itu juga sangat efisien, sehingga dapat dianggap lebih efisien daripada RGB jika ketidakpercayaan tidak diperhitungkan. Namun, itu berarti bahwa node ringan bergantung pada node penuh untuk verifikasi basis transaksi dan perhitungan status kontrak. Dalam dompet RGB yang menggunakan klien ringan BTC, itu bergantung pada asumsi kepercayaan bahwa transaksi itu relevan BTC transaksi valid, dan bagian yang terkait dengan keadaan kontrak diverifikasi oleh klien sendiri, sehingga ketidakpercayaan lebih baik. Kerugiannya adalah penundaan verifikasi lebih lama dan lebih banyak data yang perlu disimpan.

Skalabilitas

Skalabilitas RGB ada dua:

1. Hanya satu hash yang tertanam dalam transaksi BTC, yang berarti bahwa tidak ada batasan ukuran transaksi RGB (selain aturan yang disesuaikan oleh kontrak) - bahkan jika Anda membagi satu aset RGB menjadi 100 (transaksi RGB itu sendiri akan sangat besar), hanya ada satu hash yang perlu disematkan dalam transaksi BTC. Seperti dicatat dalam Catatan 6, ada dua cara untuk menanamkan hash seperti itu: baik dengan menggunakan output OP_RETURN, yang berarti bahwa ia mengkonsumsi satu hash ruang on-chain, atau dengan menyembunyikannya di pohon skrip yang dijanjikan oleh kunci publik skrip dari output Taproot - yang tidak mengkonsumsi ruang on-chain. Ini juga berarti bahwa pengguna tidak perlu mengorbankan ekonomi untuk programabilitas – hanya biaya on-chain.

2. Keadaan terbaru dari kontrak RGB adalah titik independen pada grafik asiklik terarah tanpa keturunan - ini berarti bahwa negara-negara ini dapat diubah secara independen tanpa mempengaruhi satu sama lain, yaitu, konkurensi diperbolehkan. Ini sebenarnya adalah fitur yang diwarisi dari UTXO juga. Ini juga berarti bahwa perubahan yang tidak valid (transaksi tidak valid) yang terjadi pada satu cabang tidak akan mempengaruhi cabang lainnya, apalagi menyebabkan seluruh kontrak membeku, sehingga juga dapat dianggap sebagai manfaat keamanan.

RGB telah dikritik karena skalabilitasnya: dengan setiap transfer, penerima perlu memverifikasi semua transaksi yang terlibat dari keadaan awal ke keadaan pembayar - karena jumlah transfer aset meningkat, beban verifikasi pada penerima berikutnya meningkat. Kritik ini benar. Mengoptimalkannya berarti menemukan cara untuk menggunakan kembali perhitungan yang telah terjadi. Teknologi sistem bukti, seperti SNARKs, diharapkan dapat memberikan solusi semacam itu.

Diferensiasi definisi aset dan mekanisme deklarasi pabean

Manfaat terakhir masih terkait dengan UTXO, tergantung pada bagaimana kita memahami mekanisme skrip penguncian UTXO.

Skrip penguncian dapat digunakan untuk memprogram kondisi di mana dana akan dibuka, sehingga dapat menerapkan aturan kustodian. Misalnya, jika skrip penguncian hanya berisi satu kunci publik, itu berarti hanya pemilik kunci pribadi terkait yang dapat mengontrolnya. Namun, aturan kustodian semacam itu juga merupakan dasar untuk pemrograman protokol kontrak BTC. Misalnya, UTXO yang menggunakan skrip penguncian multi-tanda tangan 2-dari-2 bisa menjadi saluran kilat, dan selama operasi saluran, dua pihak dapat saling membayar hampir tak terbatas kali tanpa perubahan dalam bentuk on-chain dana. Dengan kata lain, pada titik ini, skrip penguncian multi-tanda tangan 2-dari-2 merupakan mekanisme transfer nilai yang memungkinkan kedua belah pihak untuk mentransfer nilai tanpa mengubah bentuk dana on-chain.

Mekanisme semacam itu dapat digunakan untuk nilai BTC yang dibawa oleh UTXO dan, tentu saja, untuk aset RGB yang dibawanya. Kami dapat menerbitkan aset RGB dan melampirkannya ke UTXO multi-tanda tangan 2-dari-2, menggunakan mekanisme saluran kilat untuk saling membayar dalam jumlah yang tidak terbatas. Demikian pula, aset RGB juga dapat digunakan dalam kontrak berbasis skrip BTC lainnya.

Di sini, skrip UTXO dan protokol RGB membentuk diferensiasi fungsional: yang pertama berfokus pada penerapan aturan penyimpanan nilai dan transfer nilai, sedangkan yang kedua berfokus pada definisi aset. Dengan demikian, hak asuh aset dan definisi aset dapat dipisahkan. Ini adalah peningkatan keamanan yang penting, dan salah satu yang dicari orang di beberapa sistem kontrak on-chain lainnya.

RGB telah dirancang

Fitur di atas berlaku untuk hampir semua protokol berdasarkan penyegelan satu kali UTXO dan verifikasi sisi klien. Namun di atas itu, protokol RGB telah dirancang lebih lanjut.

Dalam perkembangan protokol RGB saat ini, pengembang sangat memperhatikan privasi protokol, sehingga RGB memperkuat privasi dengan dua cara:

• UTXO buta. Dalam transaksi RGB, penerima hanya perlu menggunakan pengidentifikasi UTXO yang dikaburkan untuk menerima aset, tanpa mengekspos karakteristik UTXO yang benar-benar menerima aset. Ini sama sekali tidak membahayakan kemampuan penerima untuk memberikan bukti kepada pemilik berikutnya, sementara pada saat yang sama memungkinkan penerima aset berikutnya untuk membela diri terhadap mata-mata pemilik aset sebelumnya. *Antipeluru. Ini dapat digunakan untuk menyembunyikan jumlah yang tepat dalam setiap transaksi. Namun, pemilik aset berikutnya masih dapat memverifikasi bahwa belum ada penerbitan tambahan sebelumnya.

Ruang yang Dapat Dieksplorasi

Pada bagian ini, saya akan berbicara tentang area di mana protokol RGB dapat terus dieksplorasi, terutama terkait dengan programabilitas.

Saat ini, template kontrak RGB yang diusulkan (skema) difokuskan pada penerbitan aset. Namun, karena RGB menggunakan paradigma “validasi sisi klien”, pada kenyataannya, kita dapat menambahkan apa pun ke dalamnya yang dapat dipastikan dengan verifikasi sisi klien - hanya dibatasi oleh struktur UTXO.

Pembatasan

Di atas UTXO, sebuah konsep yang memperluas programabilitas disebut “perjanjian”. Tujuan awal dari klausul pembatasan adalah untuk membatasi tujuan di mana sejumlah uang dapat ditransfer. Dengan kemampuan ini, kita dapat memprogram banyak aplikasi menarik, seperti:

• Kolam dana untuk penarikan non-interaktif. Kami dapat mengumpulkan dana banyak orang di UTXO yang sama dan menggunakan batasan untuk menjamin bahwa tidak ada dari mereka yang dapat menarik dana mereka sendiri tanpa bantuan orang lain. Ini dapat berfungsi untuk membantu orang keluar dari tempat-tempat berisiko tinggi dengan biaya rendah ketika permintaan untuk ruang blok tinggi.
• Kontrak vault. Buat dana harus pergi ke suatu tempat, melewati timelock sebelum Anda dapat membelanjakannya dengan bebas, dan selama timelock, pemilik brankas dapat mengganggu proses dengan kunci darurat dan segera memindahkan dana ke tempat lain. Perangkat semacam itu bisa sangat membantu untuk penyimpanan sendiri.

Skrip BTC saat ini tidak memiliki kemampuan ini, sehingga mengaktifkan pembatasan pada skrip BTC memerlukan garpu lunak.

Namun, selama kita bersedia mengorbankan beberapa manfaat dari “definisi aset dan diferensiasi tahanan”, kita dapat bereksperimen dengan fitur seperti itu pada aset RGB, dan kita dapat menerapkan fungsi ini pada tingkat kontrak RGB - meskipun hanya dapat bekerja untuk aset RGB yang menggunakannya (dan bukan BTC), tetapi tidak diragukan lagi akan membuka ruang yang menarik.

Studi tentang pembatasan yang ada telah menunjukkan bahwa ia memperluas ruang pemrograman untuk transaksi berbasis UTXO, menawarkan sejumlah fitur. Tetapi studi ini pada dasarnya didasarkan pada BTC, dan kami akan sedikit lebih konservatif pada protokol BTC seperti ini. Pada RGB, kita dapat dengan berani menggeneralisasi kemampuan inti dari klausa pembatasan – kemampuan untuk membaca transaksi yang merugikan dirinya sendiri pada tingkat skrip – untuk memberikan programabilitas yang lebih fleksibel: kemampuan untuk kontrak akses silang.

Akses Silang

Klausa pembatasan minimal berarti bahwa ketika UTXO dibelanjakan, skripnya dapat membaca output dari transaksi pengeluaran. Tetapi pembatasan yang sepenuhnya digeneralisasi berarti dapat membaca semua bagian dari transaksi yang dikenakan biaya. Ini berarti bahwa ia juga dapat membaca input lain dari transaksi, dan jika kita tidak membatasi input lain ke kontrak yang sama, itu berarti ia dapat membaca keadaan kontrak lainnya.

Dalam RGB, kita default bahwa setiap kontrak adalah alam semesta independen dengan grafik asiklik terarah sendiri. Namun, masih mungkin bagi satu pengguna untuk memegang dua kontrak berbeda secara bersamaan. Jika transaksi RGB memungkinkan aset dari kedua kontrak untuk dibelanjakan pada saat yang sama, kemampuan akses silang tersebut mungkin memiliki kasus penggunaan (meskipun dapat dibayangkan bahwa hal itu akan mempersulit verifikasi transaksi).

Bahkan, sudah ada sistem kontrak on-chain berdasarkan struktur seperti UTXO (misalnya, Nervos Network) yang menggunakan ini untuk mencapai kemampuan akses silang untuk kontrak11. Ini adalah bidang yang sangat baru, membuka ke daerah-daerah yang jarang tersentuh oleh studi BTC sebelumnya, dan mungkin ada beberapa kejutan yang terkubur di dalamnya.

Kesimpulan

Dalam artikel ini, pembaca akan melihat bahwa ada satu konsep yang sering disebutkan selama proses penalaran dan fantasi: “UTXO”. Itulah yang saya maksudkan. Jika Anda tidak memahami UTXO, Anda tidak dapat memahami titik awal desain protokol seperti RGB, keuntungan dari desain protokol RGB, dan cara orang dapat menggunakannya. Sifat protokol RGB sebagian besar dibentuk oleh UTXO-nya, suatu bentuk segel satu kali. Sejalan dengan itu, penelitian tentang UTXO yang terakumulasi dalam bidang penelitian BTC juga dapat diterapkan pada penelitian RGB.

Ini juga menjelaskan mengapa orang yang tidak mengerti BTC, akan mengalami kesulitan memahami RGB. Dan mereka yang menyukai BTC akan mengenali desain yang telah dibuat RGB.