Menerbitkan aset berdasarkan BTC selalu menjadi topik hangat. Dari kemunculan Koin Berwarna paling awal pada tahun 2011 hingga Protokol Ordinal yang populer baru-baru ini, komunitas BTC selalu mampu melahirkan pemain dan konsensus baru. Namun hanya sedikit yang mampu bertahan dalam ujian waktu. Dengan Lightling Labs yang ambisius mengumumkan rencana mereka untuk membangun Stable Coin di atas Taproot Assets, dan Tether mendeklarasikan pilihan RGB untuk mencetak USDT pada lapisan pertama Bitcoin, jelas bahwa OmniLayer (Mastercoin) yang dulu terkenal bukan lagi yang terbesar. pemain di ekosistem BTC. Protokol aset Validasi Sisi Klien (CSV) mulai mendapat perhatian, berbeda dari protokol aset BTC tradisional dengan juga memasukkan fitur untuk skalabilitas Bitcoin. Namun ketika dihadapkan dengan begitu banyak protokol aset di ekosistem BTC, kita harus bertanya: apa perbedaannya? Dan bagaimana kita harus memilih dan menemukan peluang kita sendiri di antara banyak protokol aset ini?

Artikel ini bertujuan untuk memandu pembaca dalam meninjau berbagai protokol aset yang muncul dalam sejarah Bitcoin, menggali potensi lintasan protokol aset berbasis Bitcoin di masa mendatang.

Koin Berwarna

Ide Koin Berwarna pertama kali dikemukakan oleh Yoni Assia, CEO eToro saat ini, dalam sebuah artikel yang ditulis pada 27 Maret 2012, berjudul “bitcoin 2.X (alias Bitcoin berwarna).” Artikel tersebut mengemukakan bahwa Bitcoin, sebagai teknologi yang mendasarinya, adalah sempurna, sama seperti HTTP yang menjadi fondasi internet. Oleh karena itu, atas dasar penggunaan kembali BTC, protokol token Koin Berwarna dirancang.

Yoni Assia bertujuan untuk menciptakan ekonomi BTC 2.0 melalui metode ini - komunitas mana pun dapat menciptakan berbagai mata uang dengan cara ini. Pendekatan menggunakan Bitcoin sebagai teknologi dasar untuk menyelesaikan transaksi dan menghindari pembelanjaan ganda tidak diragukan lagi merupakan ide yang sangat berani pada saat itu.

Sebagai protokol untuk menerbitkan aset berdasarkan Bitcoin, metode Koin Berwarna adalah dengan “mewarnai” sejumlah Bitcoin untuk mewakili aset tersebut. Bitcoin yang ditandai ini secara fungsional tetap menjadi Bitcoin, namun mereka juga mewakili aset atau nilai lain. Tapi bagaimana ide ini bisa diterapkan pada Bitcoin?

Pada tanggal 3 Juli 2014, ChromaWay mengembangkan protokol Koin Berwarna (EPOBC) berbasis Enhanced Pay-to-Script-Hash (P2SH), yang menyederhanakan proses bagi pengembang untuk membuat koin berwarna. Ini adalah protokol paling awal yang mengadopsi fungsionalitas OP_RETURN Bitcoin Script.

Implementasi akhir ditunjukkan pada gambar berikut:

)

Implementasi ini sangat ringkas, namun juga menimbulkan banyak masalah:

Token yang Dihomogenisasi dan Nilai Pengikatan Minimum

Dalam transaksi genesis, jika sebuah koin berwarna diikat dengan 1000 sat, maka unit pecahan terkecil dari koin berwarna tersebut adalah 1 sat. Artinya aset atau token tersebut dapat dibagi atau dialokasikan menjadi maksimal 1000 bagian (namun hal ini hanya bersifat teoritis saja, untuk mencegah serangan debu, misalnya dulu satnya diset pada 546 SAT, dan nanti ke ordinal yang lebih tinggi. ).

Masalah Verifikasi

Untuk memastikan keaslian dan kepemilikan koin berwarna, perlu dilakukan penelusuran dan verifikasi mulai dari transaksi asal usul aset hingga UTXO saat ini. Oleh karena itu, penting untuk mengembangkan dompet khusus dan node lengkap yang menyertainya, dan bahkan browser.

Potensi Risiko Sensor Penambang

Karena karakteristik berbeda dari ColoredTransaction, yang melibatkan penulisan informasi metadata ke dalam output, ada kemungkinan sensor penambang.

Koin berwarna pada dasarnya adalah sistem pelacakan aset, memanfaatkan aturan verifikasi Bitcoin untuk melacak transfer aset. Namun, untuk membuktikan bahwa setiap keluaran tertentu (txout) mewakili aset tertentu, diperlukan seluruh rantai transfer dari asal aset hingga saat ini. Artinya, memverifikasi keabsahan suatu transaksi mungkin memerlukan rangkaian pembuktian yang panjang. Untuk mengatasi masalah ini, ada usulan agar OP_CHECKCOLORVERIFY membantu memverifikasi langsung kebenaran transaksi Koin Berwarna di BTC, namun usulan ini tidak disetujui.

ICO Pertama di Industri Cryptocurrency: Mastercoin

Konsep awal Mastercoin dikemukakan oleh JR Willett. Pada tahun 2012, ia menerbitkan whitepaper berjudul “The Second Bitcoin Whitepaper,” yang menggambarkan konsep pembuatan aset atau token baru pada blockchain Bitcoin yang sudah ada, yang kemudian dikenal sebagai “MasterCoin.” Itu kemudian berganti nama menjadi Omni Layer.

Proyek Mastercoin melakukan penjualan token awal (yang sekarang kita sebut ICO atau Initial Coin Offering) pada tahun 2013, dan berhasil mengumpulkan jutaan dolar. Ini dianggap sebagai ICO pertama dalam sejarah. Aplikasi Mastercoin yang paling menonjol adalah Tether (USDT), stablecoin fiat paling terkenal, yang awalnya diterbitkan di Omni Layer.

Faktanya, konsep Mastercoin sudah ada sebelum Koin Berwarna. Alasan mengapa hal ini dibahas kedua di sini adalah, dibandingkan dengan Koin Berwarna, Mastercoin adalah solusi yang relatif lebih kompleks. Mastercoin membentuk lapisan node yang lengkap, sehingga menawarkan fungsionalitas yang lebih kompleks (seperti kontrak pintar), sementara Koin Berwarna lebih sederhana dan lebih langsung, dengan fokus utama pada “pewarnaan” atau penandaan Bitcoin UTXO untuk mewakili aset lainnya.

Perbedaan utama dari Koin Berwarna adalah Mastercoin hanya mempublikasikan berbagai jenis perilaku transaksi pada rantai, tanpa mencatat informasi aset terkait. Di node Mastercoin, database model negara dikelola dengan memindai blok Bitcoin di node off-chain.

Dibandingkan dengan Koin Berwarna, Mastercoin dapat menjalankan logika yang lebih kompleks. Dan karena tidak mencatat keadaan dan melakukan validasi pada rantai, maka transaksinya tidak memerlukan kesinambungan (pewarnaan terus menerus).

Namun, untuk mengimplementasikan logika kompleks Mastercoin, pengguna perlu memercayai status di database off-chain node atau menjalankan node Omni Layer mereka sendiri untuk verifikasi.

Kesimpulan:

Perbedaan utama antara Mastercoin dan Koin Berwarna adalah Mastercoin memilih untuk tidak menyimpan semua data yang diperlukan untuk protokol on-chain. Sebaliknya, mereka secara parasit menggunakan sistem konsensus BTC untuk mengimplementasikan publikasi dan pemesanan transaksinya sendiri, sambil mempertahankan status dalam database off-chain.

Menurut informasi yang diberikan oleh OmniBolt: Omni Layer mengusulkan protokol aset UBA (UTXO Based Asset) baru ke Tether, yang akan memanfaatkan peningkatan Taproot untuk menyandikan informasi aset ke dalam tapleaf, memungkinkan fungsionalitas seperti pembayaran bersyarat. Sementara itu, OmniBolt memperkenalkan Stark ke dalam infrastruktur Lightning Network OmniLayer.

Konsep Validasi Sisi Klien

Untuk memahami konsep validasi sisi klien, kita perlu kembali ke tahun setelah kemunculan Colored Coins dan Mastercoin, yaitu tahun 2013. Pada tahun itu, Peter Todd menerbitkan sebuah artikel: “Menguraikan Penambangan Kripto-Koin: Stempel Waktu, Bukti Publikasi, dan Validasi.” Meskipun judul artikel tampaknya tidak berhubungan langsung dengan validasi sisi klien, pembacaan yang cermat mengungkapkan bahwa artikel tersebut berisi pemikiran pencerahan paling awal tentang validasi sisi klien.

Peter Todd, peneliti awal Bitcoin dan kriptografi, selalu mencari metode untuk membuat pengoperasian Bitcoin lebih efisien. Dia mengembangkan konsep validasi sisi klien yang lebih kompleks berdasarkan konsep stempel waktu. Selain itu, ia memperkenalkan konsep “segel sekali pakai”, yang akan disebutkan nanti.

Mengikuti pemikiran Peter Todd, pertama-tama mari kita pahami masalah yang sebenarnya dipecahkan oleh BTC (Bitcoin). Dalam pandangan Peter Todd, BTC memecahkan tiga masalah:

Bukti Publikasi

Inti dari bukti publikasi adalah untuk memecahkan masalah pembelanjaan ganda. Misalnya, Alice memiliki beberapa bitcoin yang ingin dia transfer ke Bob. Meskipun dia menandatangani transaksi untuk ditransfer ke Bob, Bob mungkin tidak mengetahui secara fisik keberadaan transaksi tersebut. Oleh karena itu, perlu ada tempat umum untuk mempublikasikan transaksi, sehingga setiap orang dapat menanyakannya.

Konsensus Pesanan

Dalam sistem komputer, waktu fisik yang biasanya kita rasakan tidak ada. Dalam sistem terdistribusi, waktu sering kali diwakili oleh stempel waktu Lamport, yang tidak mengukur waktu fisik kita tetapi mengatur transaksi kita.

Validasi (Opsional)

Validasi BTC mengacu pada verifikasi tanda tangan dan jumlah transfer BTC. Namun, di sini, Peter Todd percaya bahwa validasi ini tidak diperlukan untuk membangun sistem token di atas BTC, melainkan opsi pengoptimalan.

Pada titik ini, Anda mungkin memikirkan Ominilayer yang disebutkan sebelumnya. Ominilayer sendiri tidak mendelegasikan penghitungan dan verifikasi status ke BTC namun tetap menggunakan kembali keamanan BTC. Koin Berwarna, di sisi lain, mendelegasikan pelacakan negara ke BTC. Keberadaan keduanya menunjukkan bahwa validasi tidak harus dilakukan secara on-chain.

Jadi, bagaimana validasi sisi klien memvalidasi transaksi secara efektif?

Mari kita lihat dulu apa yang perlu divalidasi:

Status (validasi logika transaksi)
Masukkan validitas TxIn (untuk mencegah pembelanjaan ganda)

Jelas bahwa untuk aset yang diterbitkan dalam BTC, setiap transaksi memerlukan verifikasi seluruh riwayat transaksi terkait untuk memastikan bahwa input yang direferensikan belum dibelanjakan dan statusnya benar. Hal ini sangat tidak efisien. Jadi, bagaimana cara memperbaikinya?

Peter Todd yakin bahwa kita dapat menyederhanakan proses ini dengan mengubah fokus validasi. Alih-alih mengonfirmasi bahwa suatu keluaran belum dibelanjakan ganda, metode ini berfokus pada mengonfirmasi bahwa masukan transaksi telah dipublikasikan dan tidak bertentangan dengan masukan lainnya. Dengan mengurutkan masukan di setiap blok dan menggunakan pohon Merkle, jenis validasi ini dapat dilakukan dengan lebih efisien, karena setiap validasi hanya memerlukan sebagian kecil data, bukan seluruh riwayat rantai masukan tersebut.

Peter Todd mengusulkan struktur pohon komitmen sebagai berikut:

CTxIn -> CTxOut -> <merkle path> -> CTransaksi -> <merkle path> -> CTxIn

Namun bagaimana kita menyimpan pohon komitmen dalam rantai? Hal ini membawa kita pada konsep segel sekali pakai.

Segel Sekali Pakai

Segel sekali pakai adalah salah satu konsep inti untuk memahami validasi sisi klien, mirip dengan segel fisik sekali pakai yang digunakan untuk melindungi kontainer pengiriman kargo di dunia nyata. Segel sekali pakai adalah objek unik yang dapat menutup pesan satu kali dengan tepat. Singkatnya, segel sekali pakai adalah mekanisme abstrak yang digunakan untuk mencegah pembelanjaan ganda.

Untuk SealProtocol, ada tiga elemen dan dua tindakan.

Elemen dasar:

l： segel, yaitu segel
m： pesan, pesan
Di：saksi, saksi

Operasi dasar: Ada dua operasi dasar:

Tutup(l,m) → w: di segel penutup messagemupper, buatlah WitnessIn。
Verifikasi(l,w,m) → bool: Verifikasi seallApakah Anda ada di berita?salah ditutup.

Penerapan segel sekali pakai dalam hal keamananDua pesan berbeda tidak dapat ditemukan oleh penyerangm1andm2, dan menyebabkan fungsi Verifikasi mengembalikan segelbenar yang sama.

Pertama-tama, Single-Use Seal adalah sebuah konsep yang memastikan bahwa suatu aset atau data tertentu hanya digunakan atau dikunci satu kali. Dalam konteks Bitcoin, ini biasanya berarti bahwa UTXO (output transaksi yang belum terpakai) hanya dapat dibelanjakan satu kali. Oleh karena itu, keluaran dari transaksi Bitcoin dapat dianggap sebagai segel satu kali, dan ketika keluaran ini digunakan sebagai masukan untuk transaksi lain, segel tersebut “rusak” atau “digunakan”.

Untuk aset CSV di BTC, Bitcoin sendiri bertindak sebagai “saksi” yang disegel satu kali. Hal ini karena, untuk memvalidasi transaksi Bitcoin, sebuah node harus memeriksa bahwa setiap input ke transaksi merujuk pada UTXO yang valid dan tidak terpakai. Jika suatu transaksi mencoba membelanjakan dua kali lipat UTXO yang telah dibelanjakan, aturan konsensus Bitcoin dan node jujur di seluruh jaringan akan menolak transaksi tersebut.

Bisakah ini lebih sederhana?

segel sekali pakai Artinya, setiap blockchain dianggap sebagai database. Kami menyimpan janji pesan tertentu dalam database ini dengan cara tertentu, dan mempertahankan status dikonsumsi atau akan dikonsumsi untuk pesan tersebut.

Ya, sesederhana itu.

Singkatnya, aset yang diverifikasi klien memiliki karakteristik berikut:

Penyimpanan data di luar rantai: Sebagian besar riwayat transaksi, kepemilikan, dan data terkait lainnya dari aset yang diverifikasi klien disimpan di luar rantai. Hal ini sangat mengurangi kebutuhan penyimpanan data on-chain dan membantu meningkatkan privasi.
Mekanisme komitmen: Meskipun data aset disimpan secara off-chain, perubahan atau transfer data ini akan dicatat secara on-chain melalui komitmen. Komitmen ini memungkinkan transaksi on-chain untuk mereferensikan status off-chain, sehingga memastikan integritas dan data off-chain yang tidak dapat dirusak.
Saksi on-chain (tidak harus BTC): Meskipun sebagian besar data dan verifikasi dilakukan di luar rantai, aset yang diverifikasi klien masih dapat memanfaatkan keamanan rantai yang mendasarinya (penerbitan bukti, pemesanan transaksi) melalui komitmen yang tertanam pada -rantai.
Verifikasi dilakukan di sisi klien: Sebagian besar pekerjaan verifikasi dilakukan pada perangkat pengguna. Artinya seluruh node jaringan tidak perlu ikut memverifikasi setiap transaksi, hanya peserta yang terlibat saja yang perlu memverifikasi keabsahan transaksi.

Bagi mereka yang menggunakan verifikasi aset sisi klien, ada hal lain yang perlu diperhatikan:

Saat melakukan perdagangan off-chain dan memverifikasi aset yang diverifikasi oleh klien, Anda tidak hanya harus menunjukkan kunci pribadi yang menyimpan aset tersebut, tetapi juga menunjukkan bukti jalur merkel lengkap dari aset terkait.

Pelopor dalam Validasi Sisi Klien (CSV): RGB

Konsep RGB dikemukakan oleh Giacomo Zucco, salah satu tokoh terkenal di masyarakat, setelah tahun 2015. Karena kebangkitan Ethereum dan menjamurnya ICO, dan sebelum ICO, banyak orang mencoba melakukan hal-hal di luar Bitcoin, seperti proyek Mastercoin dan Koin Berwarna. .

Giacomo Zucco mengungkapkan kekecewaannya. Dia percaya bahwa proyek-proyek ini lebih rendah daripada Bitcoin, dan dia percaya bahwa cara-cara penerapan token pada Bitcoin sebelumnya tidak tepat. Dalam prosesnya, dia bertemu Peter Todd dan menjadi terpesona dengan gagasan Peter Todd tentang Validasi Sisi Klien. Kemudian dia mulai mengajukan ideRGB .

Perbedaan terbesar antara RGB dan protokol aset sebelumnya adalah selain fitur verifikasi aset sisi klien yang disebutkan sebelumnya, RGB juga menambahkan VM eksekusi untuk mengimplementasikan mesin eksekusi kontrak lengkap Turing. Selain itu, untuk menjamin keamanan data kontrak, dirancang juga Skema dan Antarmuka. Skema mirip dengan Ethereum, mendeklarasikan konten dan fungsi kontrak, sedangkan Antarmuka bertanggung jawab atas implementasi fungsi tertentu, seperti antarmuka dalam bahasa pemrograman.

Skema kontrak ini bertanggung jawab untuk membatasi perilaku yang tidak melebihi perilaku yang diharapkan ketika vm dijalankan, seperti RGB20 dan RGB21, yang masing-masing bertanggung jawab atas beberapa pembatasan pada transaksi token yang dapat dipertukarkan dan token yang tidak dapat dipertukarkan.

Mekanisme Komitmen RGB: Pedersen Hash

Dalam hal mekanisme komitmen, RGB mengadopsi Pedersen Hash. Keuntungannya terletak pada kemampuan untuk berkomitmen pada suatu nilai tanpa mengungkapkannya. Menggunakan Pedersen Hash untuk membuat pohon Merkle berarti Anda dapat membuat pohon Merkle yang dilindungi privasi dan menyembunyikan nilai-nilai di dalamnya. Struktur ini dapat digunakan dalam protokol perlindungan privasi spesifik tertentu, seperti beberapa proyek mata uang kripto anonim. Namun, ini mungkin tidak cocok untuk aset CSV, yang akan disebutkan nanti dalam perbandingan dengan Aset Akar Tunggang.

Desain Mesin Virtual RGB: Dari Kesederhanaan hingga AluVM

RGB bertujuan tidak hanya untuk mengimplementasikan protokol aset yang divalidasi klien tetapi juga untuk memperluas eksekusi mesin virtual dan pemrograman kontrak Turing yang lengkap. Pada awal perancangan RGB, diklaim menggunakan bahasa pemrograman bernama Simplicity. Bahasa ini dicirikan dengan menghasilkan bukti eksekusi saat mengeksekusi ekspresi, sehingga lebih mudah untuk memverifikasi kontrak secara formal yang tertulis di dalamnya (untuk menghindari bug). Namun perkembangan bahasa ini tidak ideal dan akhirnya menemui kesulitan. Hal ini secara langsung menyebabkan sulitnya lahirnya protokol RGB pada tahun itu. Pada akhirnya, RGB mulai menggunakan AluVM, yang dikembangkan oleh Maxim, dengan tujuan menghindari perilaku tidak terdefinisi, mirip dengan Simplicity awal. AluVM baru dikatakan akan digantikan di masa depan dengan bahasa pemrograman yang disebut Contractum, yang saat ini menggunakan Rust.

Arah Ekspansi Lapisan 2 RGB: Lightning Network atau Sidechain?

Aset yang divalidasi klien tidak dapat melakukan transaksi berkelanjutan secara off-chain dengan aman. Karena aset yang divalidasi klien masih mengandalkan L1 untuk publikasi dan pengurutan transaksi, kecepatan transaksinya dibatasi oleh kecepatan pembuatan blok dari saksi L1 mereka. Artinya, jika transaksi RGB dilakukan langsung pada Bitcoin, dengan persyaratan keamanan yang ketat, waktu antara dua transaksi terkait harus setidaknya sepuluh menit (waktu blok BTC). Tidak diragukan lagi, kecepatan transaksi seperti itu tidak dapat diterima dalam banyak kasus.

RGB dan Jaringan Lightning

Sederhananya, prinsip Lightning Network adalah kedua pihak yang terlibat dalam suatu transaksi menandatangani sekumpulan kontrak (transaksi komitmen) secara off-chain. Hal ini memastikan bahwa jika ada pihak yang melanggar kontrak, pihak yang dirugikan dapat menyerahkan kontrak (transaksi komitmen) ke BTC untuk diselesaikan, mengambil dana mereka, dan memberikan sanksi kepada pihak lain. Dengan kata lain, Lightning Network memastikan keamanan transaksi off-chain melalui desain protokol dan teori permainan.

RGB dapat membangun infrastruktur Lightning Network sendiri dengan merancang aturan kontrak saluran pembayaran yang sesuai untuk dirinya sendiri, namun kompleksitas Lightning Network sangat tinggi, dan membangun sistem ini bukanlah tugas yang mudah. Namun, sebaliknya, Lightnling Labs telah mengembangkan bidang ini selama bertahun-tahun, dan LND memiliki lebih dari 90% pangsa pasar.

Rantai Samping RGB: Perdana

LNP-BP, saat ini mempertahankan protokol RGB, dengan Maxim merilis proposal yang disebut Prime pada bulan Juni 2023, skema perluasan aset yang divalidasi klien. Di dalamnya, dia mengkritik skema ekspansi sidechain dan Lightning Network yang ada karena terlalu rumit dalam pengembangan. Maxim mengindikasikan bahwa dia yakin bahwa selain Prime, metode ekspansi lainnya mencakup saluran Lightning multi-node NUCLEUS dan pabrik saluran Ark/Enigma, yang keduanya memerlukan pengembangan lebih dari dua tahun. Namun Prime bisa selesai hanya dalam waktu satu tahun.

Prime bukanlah desain blockchain tradisional tetapi lapisan publikasi bukti modular yang dirancang untuk validasi klien, yang terdiri dari empat bagian:

Layanan Stempel Waktu: Menentukan urutan transaksi secepat 10 detik.
Bukti: Disimpan dalam format PMT, diproduksi, dan diterbitkan bersama dengan header blok.
Segel Satu Kali: Protokol segel satu kali yang abstrak, memastikan perlindungan pembelanjaan ganda. Jika diimplementasikan pada Bitcoin, maka dapat diikat ke UTXO, serupa dengan desain RGB saat ini.
Protokol Kontrak Cerdas: Kontrak yang Dapat Dipecahkan - RGB (dapat diganti).

Untuk mengatasi masalah waktu konfirmasi transaksi RGB, Prime menggunakan layanan stempel waktu untuk mengonfirmasi transaksi off-chain dengan cepat dan merangkum transaksi dan ID ke dalam blok. Pada saat yang sama, bukti transaksi di Prime dapat digabungkan lebih lanjut melalui PMT dan kemudian ditautkan ke BTC dengan cara yang mirip dengan pos pemeriksaan.

Protokol Aset CSV Berbasis Akar Tunggang: Aset Akar Tunggang

Taproot Assets adalah protokol aset CSV berdasarkan Taproot, yang digunakan untuk menerbitkan aset yang divalidasi klien pada blockchain Bitcoin. Aset ini dapat diperdagangkan secara instan, dalam volume besar, dan dengan biaya rendah melalui Lightning Network. Inti dari Taproot Assets terletak pada pemanfaatan keamanan dan stabilitas jaringan Bitcoin serta kecepatan, skalabilitas, dan biaya rendah dari Lightning Network. Protokol ini dirancang dan dikembangkan oleh roasbeef CTO Lightnling Labs, yang mungkin merupakan satu-satunya orang di planet ini yang secara pribadi memimpin pengembangan klien Bitcoin (BTCD) dan klien Lightning Network (LND), dan memiliki pemahaman yang mendalam. dari BTC.

Transaksi akar tunggang hanya membawa hash akar dari skrip aset, sehingga menyulitkan pengamat eksternal untuk mengidentifikasi apakah transaksi tersebut melibatkan Aset Akar Tunggang, karena hash itu sendiri bersifat umum dan dapat mewakili data apa pun. Dengan peningkatan Taproot, Bitcoin memperoleh kemampuan kontrak pintar (TapScript). Berdasarkan hal ini, pengkodean aset Taproot Assets mirip dengan membuat definisi token yang mirip dengan ERC20 atau ERC721. Dengan demikian, Bitcoin tidak hanya memiliki fungsi definisi aset tetapi juga kemampuan untuk menulis kontrak pintar, yang meletakkan dasar bagi infrastruktur kontrak pintar token pada Bitcoin.

Struktur pengkodean Aset Akar Tunggang adalah sebagai berikut: [Deskripsi berakhir di sini, yang menunjukkan bahwa bagian selanjutnya dari artikel ini kemungkinan akan menggali rincian teknis dari struktur pengkodean Aset Akar Tunggang.]

Gambar melalui daging sapi panggang CTO Lightning Labs

Sebagai protokol aset CSV (CoinSwap), Aset Taproot dirancang agar lebih efisien dibandingkan dengan RGB. Mereka memaksimalkan penggunaan kemajuan terkini dalam ekosistem BTC, seperti peningkatan Taproot dan PSBT (Transaksi Bitcoin yang Ditandatangani Sebagian). Perbedaan paling signifikan antara Taproot Assets dan RGB dalam hal ekstensibilitas aplikasi terletak pada eksekusi VM (Virtual Machine). Aset Taproot menggunakan TaprootScriptVM, yang sama dengan VM asli yang digunakan oleh BTC. Dalam beberapa tahun terakhir, banyak studi infrastruktur untuk BTC didasarkan pada TapScript. Namun, karena lambatnya peningkatan BTC, studi ini belum dilaksanakan dengan cepat, sehingga Aset Akar Tunggang berpotensi menjadi tempat pengujian untuk ide-ide baru ini.

Apa perbedaan antara Aset Akar Tunggang dan RGB?

Validasi Transaksi dan Keramahan Light Node

Karena penerapan pohon penjumlahan, Aset Akar Tunggang memiliki efisiensi dan keamanan verifikasi yang tinggi (verifikasi dan transaksi dapat dilakukan hanya dengan bukti kepemilikan, tanpa melintasi seluruh riwayat transaksi). Sebaliknya, penggunaan komitmen Pedersen oleh RGB menghambat validasi input yang efektif, sehingga mengharuskan RGB untuk menelusuri kembali riwayat transaksi, yang menjadi beban signifikan seiring berjalannya waktu. Desain pohon penjumlahan Merkel juga memfasilitasi verifikasi node ringan di Aset Akar Tunggang, sebuah fitur yang tidak ada dalam protokol aset sebelumnya yang dibangun di atas BTC.

VM eksekusi

Aset Akar Tunggang muncul setelah peningkatan Akar Tunggang. Mereka menggunakan TaprootScriptVM, mesin eksekusi skrip yang melekat pada peningkatan Bitcoin pasca-Taproot, dan vPSBT, varian dari PSBT BTC. Setelah mekanisme saluran petir dari Aset Taproot selesai, ia dapat segera menggunakan kembali semua infrastruktur LND saat ini dan produk Lightning Labs sebelumnya (LND saat ini mendominasi lebih dari 90% jaringan petir). Proposal BitVM terbaru, juga berdasarkan TaprootScript, secara teoritis mendukung Aset Taproot. Namun, VM dan aturan validasi (SCHEMA) RGB bersifat mandiri, sehingga membentuk ekosistem yang relatif tertutup. Perkembangan RGB sebagian besar terbatas pada ekosistemnya, dan integrasinya dengan ekosistem Bitcoin tidak sedekat yang dibayangkan. Misalnya, satu-satunya hubungan RGB dengan pemutakhiran Taproot adalah pengkodean data komitmen rantai ke dalam TapLeaf milik Saksi.

Kontrak Cerdas

Dalam implementasi RGB saat ini, kontrak dan VM sangat ditekankan. Namun, kontrak pintar belum muncul di Taproot Assets. Saat ini, RGB tidak menjelaskan bagaimana modifikasi pada Negara Global disinkronkan dengan pecahan kontrak individu (UTXO), atau bagaimana komitmen Pedersen, yang hanya menjamin kuantitas total aset, mendeteksi gangguan pada negara bagian lain. Sebaliknya, Aset Taproot, dengan desainnya yang lebih sederhana, saat ini hanya menyimpan saldo aset dan tidak memiliki penyimpanan negara yang luas, sehingga membuat diskusi kontrak pintar menjadi terlalu dini. Namun, Lightning Labs telah mengindikasikan bahwa Taproot Assets akan fokus pada desain kontrak pintar tahun depan.

Pusat Sinkronisasi

Sebagaimana dipahami dari prinsip dasar verifikasi aset sisi klien, memegang Bukti sama pentingnya dengan memegang kunci pribadi. Namun bagaimana jika Buktinya hilang di sisi klien pengguna? Di Aset Akar Tunggang, masalah ini dapat diatasi melalui 'alam semesta'. Semesta adalah pohon Merkle yang jarang dan dapat diaudit secara publik, yang mencakup satu atau lebih aset. Berbeda dengan pohon aset Akar Tunggang konvensional, Alam Semesta tidak menampung aset Akar Tunggang. Sebaliknya, ia berkomitmen pada subkumpulan satu atau lebih riwayat aset. Dalam RGB, peran ini dimainkan oleh Storm, yang menyinkronkan data bukti off-chain melalui P2P. Namun, karena alasan historis tim pengembangan RGB, format bukti ini saat ini tidak kompatibel. Tim ekosistem RGB, DIBA, dilaporkan sedang mengembangkan 'carbonado' untuk mengatasi masalah ini, meskipun kemajuannya masih belum jelas.

Implementasi Rekayasa

Semua perpustakaan yang digunakan oleh Taproot Assets telah teruji oleh waktu, karena Lightning Labs memiliki klien Bitcoin (BTCD), klien jaringan Lightning (LND), dan banyak implementasi lib dompetnya sendiri. Sebaliknya, sebagian besar perpustakaan yang digunakan dalam RGB dapat didefinisikan sendiri, dan dari sudut pandang standar industri, implementasi RGB masih dalam tahap percobaan.”

Diskusi Singkat tentang Masa Depan Ekspansi BTC

Seiring berjalannya diskusi, menjadi jelas bahwa validasi protokol aset sisi klien telah melampaui bidang spesifikasi protokol dan sedang bergerak menuju perluasan komputasi.

Banyak orang percaya bahwa Bitcoin akan ada sebagai emas digital di masa depan, dengan rantai lain yang menciptakan ekosistem aplikasi. Namun, saya punya pendapat berbeda. Seperti yang terlihat dalam banyak diskusi di forum BTC, diskusi tersebut sering kali berkisar pada berbagai altcoin dan keberadaannya yang berumur pendek. Hancurnya altcoin-altcoin ini dengan cepat mengubah modal dan upaya yang mengelilinginya menjadi gelembung. Dengan landasan konsensus Bitcoin yang kuat, tidak perlu membangun L1 baru untuk protokol aplikasi. Apa yang perlu kita lakukan adalah memanfaatkan infrastruktur Bitcoin yang kuat ini untuk membangun dunia yang terdesentralisasi dalam jangka panjang.

Lebih sedikit komputasi on-chain, lebih banyak validasi on-chain

Dari perspektif desain, Bitcoin sejak awal memilih untuk tidak fokus pada komputasi on-chain melainkan pada filosofi yang berpusat pada validasi (Turing kelengkapan dan status untuk kontrak pintar). Blockchain pada dasarnya adalah mesin negara yang direplikasi. Jika konsensus suatu rantai didasarkan pada komputasi on-chain, sulit untuk membenarkan alasan dan skalabilitas jika semua node di jaringan mengulangi komputasi ini. Jika kita fokus pada validasi, maka memvalidasi efektivitas transaksi off-chain mungkin merupakan strategi ekspansi yang paling cocok untuk BTC.

Dimana validasi dilakukan? Ini penting

Bagi pengembang protokol selain Bitcoin, cara menggunakan Bitcoin untuk validasi penting, atau bahkan menempatkan validasi di luar rantai, dan cara merancang skema keamanan, adalah urusan perancang protokol itu sendiri. Hal ini tidak boleh dan tidak perlu dikaitkan dengan rantai itu sendiri. Oleh karena itu, cara validasi diterapkan akan menghasilkan strategi ekspansi BTC yang berbeda.

Berdasarkan perspektif implementasi validasi, kami memiliki tiga arah perluasan:

1.Validasi on-chain (OP-ZKP)
Jika OP-ZKP diimplementasikan langsung di TaprootScriptVM, itu berarti mengintegrasikan kemampuan validasi ZKP ke dalam BTC itu sendiri, ditambah dengan beberapa desain Kovenan untuk protokol penyelesaian, menciptakan rencana perluasan Zk-Rollup yang mewarisi keamanan BTC. Namun, tidak seperti menerapkan kontrak validasi pada Ethereum, proses peningkatan BTC yang lambat, ditambah dengan op-code yang terspesialisasi dan berpotensi memerlukan peningkatan, menjadikannya tantangan.
2.Validasi semi-on-chain (BitVM)
Desain BitVM tidak dimaksudkan untuk melayani logika transaksi reguler. Robin Linus juga mengindikasikan bahwa masa depan BitVM terletak pada penciptaan pasar lintas rantai gratis untuk berbagai SideChain. Pendekatan BitVM dianggap semi-on-chain karena sebagian besar perhitungan validasi ini tidak terjadi secara on-chain, melainkan off-chain. Namun, alasan penting untuk merancang Taproot BTC adalah untuk memanfaatkan TapScriptVM untuk validasi komputasi bila diperlukan, yang secara teoritis mewarisi keamanan BTC. Proses ini juga menghasilkan rantai kepercayaan validasi. Misalnya, cukup jika salah satu validator 'n' jujur, seperti Optimistic Rollup.
Biaya on-chain BitVM tinggi, tetapi bisakah BitVM menggunakan bukti penipuan ZK untuk meningkatkan efisiensi? Jawabannya tidak, karena penerapan bukti penipuan ZK didasarkan pada kemampuan melakukan validasi ZKP secara on-chain, yang membawa kita kembali ke dilema skema OP-ZKP.
3.Validasi off-chain (Validasi Sisi Klien, Jaringan Lightning)
Dengan validasi yang terjadi sepenuhnya secara off-chain, kita kembali ke protokol aset CSV dan Jaringan Lightning yang telah dibahas sebelumnya. Dalam diskusi sebelumnya, disebutkan bahwa dalam desain CSV, kita tidak dapat sepenuhnya mencegah gangguan kolusi. Apa yang bisa kita lakukan adalah menggunakan kriptografi dan desain protokol untuk menjaga kerusakan kolusi jahat dalam rentang yang terkendali, sehingga membuat perilaku seperti itu tidak menguntungkan.
Pro dan kontra dari validasi off-chain sudah jelas. Keuntungannya adalah penggunaan sumber daya on-chain yang minimal, dengan potensi ekspansi yang sangat besar. Kelemahannya adalah hampir tidak mungkin untuk sepenuhnya memanfaatkan keamanan BTC, sehingga sangat membatasi jenis dan metode transaksi off-chain. Selain itu, validasi off-chain juga berarti bahwa data disimpan di luar rantai, dikelola oleh pengguna, yang menuntut persyaratan lebih tinggi untuk keamanan lingkungan eksekusi perangkat lunak dan stabilitas perangkat lunak.

Tren Evolusi Ekspansi

Saat ini, Layer2 yang populer di Ethereum, pada dasarnya, menggunakan Layer1 untuk memvalidasi efektivitas komputasi Layer2. Artinya, perhitungan keadaan didorong ke Layer2, namun validasi tetap di Layer1. Di masa depan, kami juga dapat menekan komputasi validasi secara off-chain, sehingga semakin meningkatkan kinerja infrastruktur blockchain saat ini.

Penafian:

Artikel ini dicetak ulang dari [mirror]. Semua hak cipta milik penulis asli [Ben77]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.

Empieza ahora

¡Regístrate y recibe un bono de

$100

Crea tu cuenta

Transfer Off-Chain: Jalur Evolusi Protokol Aset Bitcoin