Pengantar:

Adegan Bitcoin Layer2 saat ini ramai dengan beragam solusi teknologi yang menyatu dalam panci peleburan ekosistem BTC. Mengingat laju iterasi yang cepat di bidang blockchain, di mana kosakata dan standar profesional terus berkembang melalui penelitian, inovasi, dan implementasi teknik, banyak proyek menggunakan "penciptaan konsep" atau "tumpangan konsep" untuk diferensiasi dan perhatian, menjadi aturan tak terucapkan dalam industri. Misalnya, beberapa proyek blockchain modular yang awalnya aktif dalam ekosistem Ethereum / Celestia telah melompat pada kereta musik "Bitcoin Layer2", menjuluki diri mereka sebagai "Rollups," meskipun solusi teknis mereka sering tidak memenuhi standar Rollup. Namun, istilah "Rollup" membawa pengakuan yang signifikan, sehingga menguntungkan untuk tujuan promosi. Banyak operator proyek dengan paksa melabeli diri mereka sebagai Rollup atau memotong konsep Rollup arus utama dengan kualifikasi yang tidak jelas, seperti "Sovereign Rollup." Mengupas kembali lapisan "XX Rollups" ini, banyak proyek pada dasarnya didasarkan pada "validasi sisi klien" atau "sidechains," hanya menggunakan slogan "XX Rollup" untuk kenyamanan. Meskipun strategi promosi ini umum, itu cenderung menyesatkan, menyebabkan lebih banyak kerugian daripada kebaikan bagi mereka yang mencari kebenaran.

(Pendekatan ini, yang dirangkum oleh Menteri Propaganda Nazi Goebbels sebagai "propaganda berbasis kebohongan," sering diamati di antara operator proyek.) Bagaimana kita dapat membedakan perilaku "hitchhiking konsep Rollup" tersebut? Mungkin, mulai dari prinsip-prinsip pertama, mendefinisikan berbagai kategori proyek Layer2 dan tingkat keamanan dan fungsionalitas berdasarkan standar yang widely accepted di Barat dan di seluruh industri, bisa memberikan kejelasan. Ini tidak selalu tentang solusi yang dipilih; intinya terletak pada apakah desain mekanisme proyek memastikan keamanan dan keandalan jaringan Layer2 dan benar-benar memberdayakan BTC mainnet.

Artikel ini akan menggunakan Chainway, proyek Bitcoin Layer2, sebagai studi kasus untuk membedah sifat "validasi sisi klien" yang tersembunyi di balik slogan "Rollup" beberapa proyek. Kami bertujuan untuk membedakan dengan jelas antara "Sovereign Rollup" dan "validasi sisi klien," dan perbedaan signifikan dari ZKRollups atau OPRollups standar industri yang mengandalkan kontrak pintar. Ini bukan untuk mengatakan bahwa Sovereign Rollups atau validasi sisi klien lebih rendah daripada ZK Rollups dalam hal keamanan dan keandalan; Itu semua tergantung pada detail implementasi spesifik mereka. Chainway, biasanya validasi sisi klien Layer2, telah mengusulkan skema transaksi anti-sensor yang dipicu pada BTC dengan validasi off-chain, menggunakan Bukti ZK rekursif yang serupa dengan yang digunakan oleh rantai publik MINA, memposisikannya di depan banyak proyek Bitcoin Layer2. Kami percaya bahwa meneliti teknologi Chainway sangat berharga, menawarkan wawasan yang signifikan bagi pengamat Bitcoin Layer2. (Gambar promosi Chainway mencapnya sebagai ZK Rollup, tetapi solusi lamanya adalah validasi sisi klien, dengan ZKR menjadi proyek lain mereka. Saat ini, belum mencapai konsensus klien off-chain atau pertukaran pesan yang andal.)

Teks Utama: Chainway adalah proyek Bitcoin Layer2 yang terkenal di komunitas Barat, sering disebut sebagai “ZK Rollup” oleh banyak KOL, sementara dokumentasi teknisnya mengarahkannya sebagai “Sovereign Rollup.” Baru-baru ini, Chainway juga mengumumkan proyek baru, Citrea, mengklaimnya sebagai ZK Rollup berbasis BitVM. Namun, karena Citrea belum menguraikan solusi verifikasi ZK-nya berdasarkan BitVM, artikel ini akan berfokus pada interpretasi teknis solusi sebelumnya dari Chainway. Secara ringkas, solusi teknis yang diungkapkan secara publik oleh Chainway melibatkan penerbitan data DA melalui protokol Ordinals, menggunakan BTC sebagai lapisan DA-nya, dan menerbitkan detail perubahan status (State diff) + ZK Proof yang memverifikasi kebenaran perubahan status di Layer1, setara dengan menerbitkan data transaksi yang lengkap dan dapat diverifikasi. Namun, karena Layer1 tidak secara langsung memverifikasi ZK Proofs, dengan verifikasi dilakukan oleh klien/node independen di luar rantai, dan basis kode saat ini dari Chainway belum mencapai konsensus di antara klien di luar rantai, juga tidak mengklaim telah memecahkan isu ini di media sosial, solusi teknis yang diungkapkan secara publik oleh Chainway pada dasarnya termasuk dalam kategori “validasi sisi klien,” bahkan menyerupai protokol yang diindeks secara kriptografis yang mendukung penyeberangan aset. Bagian-bagian berikut akan memperkenalkan implementasi teknis spesifik Chainway dan menganalisis model keamanannya.

Apa itu Sovereign Rollup: Data Availability (DA) Layer Publishing + Verifikasi Off-chain

Dalam dokumentasi teknis Chainway, konsep Sovereign Rollup dari Celestia digunakan. Sovereign Rollup secara mendasar berbeda dari konsep Rollup mainstream dalam komunitas Ethereum dan industri lebih luas (smart contract Rollup). Jadi, apa sebenarnya struktur dari Sovereign Rollup?

Pada dasarnya, Sovereign Rollup berbasis Bitcoin agak mirip dengan 'kelompok klien di luar rantai/sidechain yang mempublikasikan data DA pada blockchain BTC.' Karakteristik utamanya adalah tidak memerlukan kontrak pintar pada Layer 1 untuk memverifikasi transisi status/tindakan lintas-rantai untuk Layer 2. Pada dasarnya, hal ini menggunakan BTC sebagai lapisan DA, dan model keamanannya sebagian besar mirip dengan 'validasi sisi klien.' Tentu saja, beberapa solusi Sovereign Rollup yang lebih aman bergantung pada lapisan penyelesaian pihak ketiga di luar rantai Bitcoin (mirip dengan sidechain) untuk melakukan verifikasi transisi status. Selain itu, di antara klien/node penuh independen yang berbeda, terdapat tingkat konsensus atau pertukaran pesan yang dapat diandalkan untuk mencapai 'kesepakatan' mengenai tindakan yang kontroversial. Namun, beberapa proyek Sovereign Rollup berdasarkan 'validasi sisi klien,' tanpa adanya pertukaran pesan yang dapat diandalkan antara klien/node independen.

Untuk lebih memahami konsep unik dari “Sovereign Rollup,” berguna untuk membandingkannya dengan lawan terberatnya, yaitu smart contract Rollup. Di Ethereum, solusi Layer 2 secara dominan adalah smart contract Rollups, seperti Arbitrum dan StarkNet. Struktur dari smart contract Rollup dapat divisualisasikan dalam diagram berikut:

(Bayangkan sebuah diagram di sini)

Dalam diagram, kita dapat melihat beberapa istilah terkait narasi blockchain modular, dijelaskan sebagai berikut:

• Lapisan Pelaksanaan: Melaksanakan transaksi pengguna, memperbarui status blockchain, dan mengirimkan data ke lapisan DA dan lapisan penyelesaian.

• Lapisan Penyelesaian: Memverifikasi transisi negara dari lapisan eksekusi, menyelesaikan sengketa (seperti bukti penipuan), dan menyediakan modul jembatan untuk menangani aset penyeberangan L1-L2.

• Lapisan Ketersediaan Data (DA): Bertindak seperti papan buletin besar, menerima data transisi negara yang dikirimkan oleh lapisan eksekusi dan menyediakan data ini secara tidak dapat dipercaya kepada siapa pun.

• Lapisan Konsensus: Memastikan finalitas urutan transaksi. Fungsinya nampaknya agak mirip dengan lapisan DA (pendekatan komunitas Ethereum terhadap lapisan modular blockchain tidak termasuk lapisan konsensus).
  
  Dari arsitektur smart contract Rollups, kita melihat bahwa Ethereum mengasumsikan peran dari tiga lapisan terakhir, selain lapisan eksekusi. Diagram lain bisa memberikan pandangan yang lebih detail tentang peran-peran Ethereum dalam smart contract Rollups.
  
  Sebaliknya, Sovereign Rollups berbeda secara signifikan karena mereka mendesentralisasikan beberapa tanggung jawab ini dari blockchain monolitik seperti Ethereum. Secara khusus, mereka tidak bergantung pada kontrak pintar pada lapisan dasar (Lapisan 1) untuk memverifikasi transisi negara atau menangani perselisihan. Sebaliknya, tugas-tugas ini dikelola oleh klien off-chain atau melalui lapisan penyelesaian pihak ketiga, menekankan pendekatan yang berbeda untuk mencapai skalabilitas dan keamanan dalam sistem blockchain.

Kontrak Rollup di Ethereum menerima bukti validitas atau bukti penipuan untuk memverifikasi validitas transisi status Layer 2. Layak disebutkan bahwa kontrak pintar Rollup bertindak sebagai entitas lapisan penyelesaian dalam arsitektur blockchain modular. Kontrak lapisan penyelesaian sering kali mencakup modul pemancar untuk menangani aset yang dipancarkan dari Ethereum ke Layer 2. Untuk Ketersediaan Data (DA), kontrak lapisan penyelesaian dapat memerintahkan Pengurut untuk memposting detail data/perubahan status transaksi terbaru di rantai. Tanpa memposting DA di rantai, tidak mungkin untuk berhasil memperbarui status L2 yang tercatat dalam kontrak Rollup.

(ZK Rollup atau Optimistic Rollup dapat memaksa data DA diposting di-chain; tanpanya, status yang tercatat di lapisan penyelesaian tidak dapat diperbarui.) Dari menganalisis model keamanan dan indikator risiko dari solusi Layer 2 Bitcoin/Ethereum dengan teori barel, jelas bahwa Rollup kontrak pintar sangat bergantung pada Kontrak pintar Layer 1. Untuk Layer 1 seperti BTC, yang kesulitan mendukung logika bisnis kompleks, membangun Layer 2 yang sejalan dengan Rollup Ethereum pada dasarnya tidak mungkin. Solusi Sovereign Rollup, di sisi lain, tidak memerlukan kontrak di Layer 1 untuk verifikasi status/pemutaran. Arsitektur mereka adalah sebagai berikut: (Di sini, deskripsi arsitektur hilang, menyiratkan bahwa ilustrasi atau detail lebih lanjut dimaksudkan untuk disertakan tetapi tidak disediakan dalam teks.)

Dalam Sovereign Rollups, node di luar lapisan Data Availability (DA) berfungsi sebagai entitas untuk eksekusi transaksi dan operasi penyelesaian, menawarkan tingkat kebebasan yang lebih tinggi. Alur kerjanya adalah sebagai berikut:

Node di lapisan eksekusi Rollup berdaulat mengirim data transaksi / detail perubahan status ke lapisan DA, sementara lapisan penyelesaian / klien berusaha untuk mendapatkan dan memverifikasi data. Penting untuk dicatat bahwa karena modul lapisan penyelesaian tidak terletak pada Layer 1, sovereign Rollups, secara teori, tidak dapat mencapai jembatan dengan keamanan yang setara dengan Layer 1. Mereka sering mengandalkan jembatan notaris atau solusi bridging pihak ketiga. Saat ini, implementasi skema verifikasi sovereign Rollup/klien relatif sederhana, hanya membutuhkan publikasi data pada rantai Bitcoin (BTC) menggunakan protokol yang mirip dengan Ordinals. Adapun verifikasi dan konsensus off-chain, ada banyak fleksibilitas. Faktanya, banyak sidechains hanya mempublikasikan data DA pada rantai BTC, pada dasarnya menjadi "Rollup berdaulat berbasis BTC," meskipun keamanan spesifiknya dipertanyakan. Namun, masalahnya adalah throughput data Bitcoin sangat rendah, dengan maksimum 4MB per blok dan waktu blok rata-rata 10 menit, diterjemahkan menjadi throughput data hanya 6KB / s. Solusi Layer 2 yang mengklaim sebagai Sovereign Rollups mungkin tidak dapat mempublikasikan semua data DA pada rantai BTC, oleh karena itu mereka dapat memilih metode alternatif, seperti menerbitkan data DA off-chain dan menyimpan datahash pada rantai BTC sebagai bentuk "komitmen," atau menemukan cara untuk sangat memampatkan data DA (misalnya, menggunakan State diff + ZK Proof seperti yang diklaim oleh Chainway). Jelas, mode ini tidak sesuai dengan definisi "sovereign Rollup" atau Rollup yang tepat, mewakili varian yang keamanannya dipertanyakan. Kami memperkirakan bahwa sebagian besar proyek Layer 2 dengan spanduk "Rollup" pada akhirnya tidak akan mempublikasikan semua data DA pada rantai BTC, sehingga solusi praktis mereka kemungkinan tidak akan cocok dengan klaim "ZK Rollup" atau "OP Rollup" yang dibuat dalam whitepaper mereka.

Akhirnya, mari kita ringkas perbedaan antara Sovereign Rollups dan Smart Contract Rollups secara singkat:

1. Kemampuan untuk di-upgrade:Iterasi pembaruan Rollups kontrak pintar melibatkan pembaruan kontrak pintar, yang memerlukan tim pengembangan untuk menggunakan kontrak yang dapat ditingkatkan. Jenis otoritas pembaruan kontrak pintar ini umumnya dikendalikan oleh tim pengembangan Rollup melalui multi-tanda tangan. Sebaliknya, aturan pembaruan untuk Rollups kedaulatan mirip dengan fork soft dan hard blockchain konvensional, di mana node dapat memilih untuk memperbarui versi secara independen, dan klien yang berbeda dapat memilih apakah menerima pembaruan tersebut. Dari sudut pandang ini, Rollups kedaulatan lebih unggul daripada Rollups kontrak pintar dalam hal kemampuan untuk ditingkatkan.

2. Jembatan:Dalam kondisi ideal, jembatan untuk Rollups kontrak pintar sesuai dengan kepercayaan minimal, tetapi keupgradablean kontrak dapat memengaruhi keamanan mereka. Di bawah skema Sovereign Rollup, pengembang perlu membangun komponen-komponen bridging di bawah chain Layer 1 sendiri, dan jembatan yang dibangun kemungkinan lebih sedikit kepercayaannya dibandingkan dengan jembatan kontrak pintar.

Struktur DA BTC

Dalam teks di atas, kami menyebutkan bahwa untuk menerapkan Rollup berdaulat berbasis BTC, intinya terletak pada menggunakan protokol Ordinals untuk membuat BTC berfungsi sebagai lapisan Ketersediaan Data (DA). Chainway telah mengadopsi solusi ini.

Kami dapat memeriksa pengiriman data DA dari pengurutan Chainway, dengan hash transaksi:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, diilustrasikan sebagai berikut:

Skrip transaksi ini meminjam dari pendekatan Protokol Ordinals dalam menggunakan OP_0 OP_IF untuk penulisan data guna menulis data DA (Ketersediaan Data) Rollup ke rantai BTC. Ini melibatkan publikasi perubahan status dan Bukti ZK, yang setara dalam keamanan dengan mempublikasikan data transaksi asli tetapi memungkinkan pengurangan ukuran data yang signifikan. Selain data DA, sequencer juga menulis beberapa data otentikasi ke dalam transaksi, yang paling penting adalah sequencer Rollup menandatangani data DA dengan kunci privatnya untuk memastikan pengajuan berasal dari sequencer. Penting untuk dicatat bahwa setiap transaksi yang melibatkan pengajuan data DA memiliki 16 nol biner di akhir hash transaksi (yaitu, dua byte berturut-turut adalah nol). Pembatasan ini dapat dilihat dalam kode:

Dalam contoh grafik transaksi yang disebutkan sebelumnya, angka acak "b715" digunakan untuk menyesuaikan nilai hash transaksi sehingga ekornya membawa 16 nol tertentu. Prinsip ini mirip dengan penambangan Bitcoin, di mana angka acak nonce ditambahkan untuk membuat hash memimpin N bit semua nol, memenuhi kondisi kendala tertentu. Desain ini bertujuan untuk mempermudah kesulitan mendapatkan data DA (Data Availability). Ketika node Layer2 ingin mengakses data DA, ia hanya perlu memindai blok BTC (Bitcoin) untuk semua transaksi yang diatur untuk diakhiri dengan 16 nol, secara efektif membedakan transaksi yang diprakarsai oleh penyortir Chainway ketika mengirimkan data dari transaksi lain di blockchain Bitcoin. Dalam teks berikut, transaksi yang berisi data DA dan memenuhi persyaratan untuk diakhiri dengan 16 nol disebut sebagai "transaksi standar Chainway." Fokus artikel ini adalah bagaimana Chainway mencapai ketahanan sensor. Karena penyortir Layer2 mungkin dengan sengaja menolak permintaan transaksi dari pengguna tertentu, skema khusus harus digunakan untuk memungkinkan pengguna memulai transaksi yang menolak sensor. Menanggapi masalah ini, Chainway memungkinkan pengguna untuk meluncurkan "Transaksi Paksa." Setelah pengguna mengirimkan deklarasi transaksi ini dalam blok BTC, penyortir Chainway harus memproses permintaan transaksi ini pada Layer2; Jika tidak, itu tidak akan dapat menghasilkan blok secara normal, atau blok yang dihasilkan tidak akan dikenali oleh klien off-chain. Struktur parameter transaksi paksa adalah sebagai berikut:

Transaksi ini akan disampaikan ke blockchain Bitcoin sebagai "Transaksi Spesifikasi Chainway," dengan hash transaksi yang berakhir dengan 16 nol. Pemilah ChainWay, saat menghasilkan blok L2, harus menyertakan "Transaksi Spesifikasi Layer2" yang telah diungkapkan di blockchain BTC tetapi belum dicatat dalam buku besar L2, dan menggabungkannya ke dalam Pohon Merkle, menuliskan akar Merkle-nya ke dalam header blok L2. Begitu pengguna memulai transaksi yang memaksa langsung di blockchain BTC, pemilah harus memprosesnya; jika tidak, ia tidak dapat menghasilkan blok valid berikutnya. Klien Chainway di luar rantai BTC dapat memverifikasi bukti ZK terlebih dahulu untuk menentukan kevalidan blok L2 yang disampaikan oleh pemilah, memeriksa akar Merkle dari header blok L2, dan menilai apakah pemilah telah benar-benar menyertakan permintaan transaksi paksa. Alur kerja dapat dirujuk ke diagram alur berikut. Perhatikan bahwa, karena keterbatasan ruang, diagram di bawah ini kehilangan penilaian kondisi dalam verify_relevant_tx_list:

Secara ringkas, klien/node Chainway disinkronkan dengan blok BTC mainnet dan memindai untuk menemukan data “DA” yang diterbitkan oleh penyortir Chainway dari blok tersebut. Ini memverifikasi bahwa data-data ini diterbitkan oleh penyortir yang ditunjuk dan memang mengandung semua “transaksi standar Chainway” yang dikirimkan ke rantai BTC. Jelas bahwa selama pengguna dapat membuat transaksi yang memenuhi kriteria tertentu sebagai transaksi “standar” dan mengirimkannya ke rantai BTC, transaksi ini akhirnya akan disertakan dalam ledger L2 lokal klien Chainway. Sebaliknya, blok L2 yang dirilis oleh penyortir Chainway akan ditolak oleh klien. Jika dikombinasikan dengan transmisi pesan konsensus/peringatan off-chain yang dapat diandalkan, skema transaksi anti-sensorship Chainway mendekati metode anti-censorship ideal dari Sovereign Rollups. Sebagai contoh, beberapa solusi Sovereign Rollup secara eksplisit menyatakan bahwa dalam kasus blok yang tidak valid, pesan peringatan Alert akan disiarkan di antara klien off-chain untuk meningkatkan keamanan, terutama memberi tahu klien ringan yang tidak dapat menyinkronkan data DA lengkap tentang anomali jaringan. Jika blok tidak benar-benar memasukkan “transaksi wajib,” maka jelas akan memicu siaran peringatan off-chain. Namun, Chainway belum menerapkan aspek ini (setidaknya materi yang saat ini dipublikasikan dan repositori kode menunjukkan bahwa belum ada pelaksanaan teknis dari bagian ini).

Bahan referensi: Peneliti Celestia menganalisis 6 jenis varian Rollup: Sequencer = Aggregator + Header Generator. Bahkan dengan konsensus yang dicapai antara klien/node off-chain, efektivitas anti-sensor dari "transaksi paksa" Chainway tidak sekuat Rollup kontrak pintar seperti Arbitrum, karena Arbitrum One pada akhirnya akan memastikan "transaksi paksa" dimasukkan dalam buku besar Layer2 melalui kontrak pada Layer1, sepenuhnya mewarisi properti anti-sensor Layer1. Sovereign Rollups jelas tidak dapat menandingi Rollup kontrak pintar dalam aspek ini, karena efektivitas anti-sensornya pada akhirnya bergantung pada komponen off-chain. Ini juga menentukan bahwa pendekatan skema "Sovereign Rollups" dan "verifikasi klien" pada dasarnya tidak dapat mewarisi properti anti-sensor Layer1 secara penuh, seperti Arbitrum One, Loopring, dydx, dan Degate, karena apakah transaksi paksa dapat dengan lancar dimasukkan dalam buku besar Layer2 tergantung pada keputusan entitas off-chain Layer2, tidak terkait dengan Layer1 itu sendiri. Jelas, pendekatan Chainway, yang semata-mata bergantung pada kebijaksanaan klien off-chain, hanya mewarisi keandalan DA dari Layer1, bukan properti anti-sensor penuhnya. Mirip dengan bukti ZK rekursif MINA.

Dalam bagian ini, kami akan lebih lanjut memperkenalkan komponen-komponen lain dari Chainway, yang, selain menggunakan BTC sebagai lapisan DA, juga menerapkan bukti ZK rekursif yang mirip dengan MINA. Struktur keseluruhannya diilustrasikan dalam diagram berikut:

Penyortir di jaringan Chainway, setelah memproses transaksi pengguna, menghasilkan bukti ZK (Zero-Knowledge) akhir bersama dengan rincian perubahan status (state diff) untuk akun yang berbeda dan menerbitkannya di blockchain Bitcoin (BTC). Full node akan menyinkronkan semua data historis Chainway yang dipublikasikan di blockchain BTC. Setiap bukti ZK tidak hanya harus membuktikan proses transisi keadaan dari blok saat ini tetapi juga memastikan validitas bukti ZK dari blok sebelumnya. Berdasarkan skema ini, kita dapat melihat bahwa setiap kali bukti baru dihasilkan, pada dasarnya menegaskan bukti sebelumnya secara rekursif, dan bukti ZK terbaru dapat menjamin validitas semua bukti ZK mulai dari blok genesis. Desain ini mirip dengan MINA. Ketika "klien ringan" yang hanya menyinkronkan header blok, juga dikenal sebagai simpul cahaya, bergabung dengan jaringan, ia hanya perlu memverifikasi validitas Bukti ZK terbaru yang diungkapkan pada blockchain BTC untuk mengonfirmasi bahwa seluruh data historis rantai dan semua transisi status valid. Jika penyortir bertindak jahat, dengan sengaja menolak untuk menerima transaksi wajib atau gagal menggunakan bukti ZK sebelumnya untuk pembuktian rekursif, maka bukti ZK yang baru dihasilkan tidak dapat diterima oleh klien (bahkan jika dihasilkan, itu tidak dikenali), seperti yang ditunjukkan pada diagram di bawah ini:

Ringkasan

Seperti yang dirangkum di awal artikel ini, Chainway pada dasarnya adalah skema verifikasi klien Rollup/sovereign yang menggunakan BTC sebagai lapisan Data Availability (DA) nya. Untuk meningkatkan ketahanan sensor dari Rollup, Chainway memperkenalkan konsep transaksi paksa. Di sisi lain, Chainway menggunakan teknologi bukti ZK rekursif, memungkinkan node-node baru untuk mempercayai output sequencer lebih banyak dan memverifikasi akurasi data historis rantai keseluruhan kapan saja. Isu saat ini dengan Chainway terletak pada mekanisme kepercayaan jembatan lintas rantai-nya. Karena mengadopsi pendekatan sovereign Rollup tanpa rincian bagaimana cara mengatasi spesifik teknis dalam solusi jembatan lintas rantai-nya, sulit untuk menilai keamanan akhirnya.

Hari ini, dengan menyelami solusi teknis Chainway, kami menemukan bahwa tipe teknologi yang dipromosikan oleh komunitas proyek bukanlah Rollup dalam arti umum. Mengingat bahwa sudah ada puluhan proyek Bitcoin Layer2 (yang bisa mencapai ratusan dalam setengah tahun), untuk mengurangi biaya kognitif dari terminologi teknis, kami akan terus melakukan penelitian mendalam tentang klasifikasi solusi Layer2 dan standar keamanan, kelengkapan fungsionalitas, dan evaluasi. Tetap terhubung!

Penafian:

1. Artikel ini dicetak ulang dari [ 极客 Web3]. Semua hak cipta milik penulis asli [Shew & Faust, web3 geeks]. Jika ada keberatan terhadap penerbitan ulang ini, harap hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penafian Kewajiban: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata milik penulis dan bukan merupakan saran investasi.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.