Bitcoin Magazine: Apa Kendala yang Dihadapi oleh Rollup?

robot
Pembuatan abstrak sedang berlangsung

Sumber: Bitcoin Magazine; Diterjemahkan oleh: Wuzhu, Jinse Keuangan

Rollups telah menjadi fokus skalabilitas BTC baru-baru ini, menjadi hal pertama yang benar-benar mencuri sorotan dari Jaringan Lighting dan mendapat perhatian yang lebih luas. Rollups bertujuan untuk menjadi lapisan kedua off-chain yang tidak terikat atau dibatasi oleh pembatasan Likuiditas inti dari Jaringan Lighting, di mana pengguna akhir perlu memiliki dana yang dialokasikan (atau ‘dipinjam’) terlebih dahulu untuk menerima pembayaran, atau saluran Node perantara membutuhkan saldo saluran untuk memfasilitasi aliran pembayaran dari pengirim ke penerima selama seluruh perjalanan.

Sistem-sistem ini awalnya dijalankan di Ethereum dan sistem Turing Complete lainnya, namun baru-baru ini fokus telah beralih ke porting mereka ke blockchain berbasis UTXO (mis., BTC). Artikel ini tidak bermaksud untuk membahas keadaan saat ini yang diimplementasikan pada BTC, tetapi membahas fitur idealisasi Rollup yang telah lama dicari oleh orang-orang, yang bergantung pada kemampuan BTC saat ini yang tidak didukung, yaitu kemampuan untuk memverifikasi langsung bukti nol pengetahuan (ZKP) di atas BTC.

Arahan Roll adalah seperti berikut: satu akun tunggal (UTXO di BTC) menyimpan baki semua pengguna dalam Rollup. UTXO ini mengandungi komitmen, yang wujud dalam bentuk akar Merkle dari pokok Merkle, yang mewakili semua baki semasa semua akun dalam Rollup. Semua akun ini dilakukan dengan Kunci Publik/Kunci Pribadi, oleh itu untuk membuat perbelanjaan off-chain, pengguna masih perlu menandatangani sesuatu dengan Kunci Rahasia. Bahagian struktur ini membolehkan pengguna keluar pada bila-bila masa tanpa kebenaran, hanya dengan membuktikan transaksi yang menunjukkan bahawa akun mereka merupakan sebahagian dari pokok Merkle, mereka boleh keluar dari Rollup secara sepihak tanpa kebenaran operator.

Operator Rollup harus menyertakan ZKP dalam transaksi untuk memperbarui root merkle saldo akun on-chain selama proses transaksi off-chain, jika tidak, transaksi akan menjadi tidak valid dan tidak dapat dimasukkan ke dalam blokchain. Bukti ini memungkinkan orang untuk memverifikasi apakah semua perubahan saldo akun off-chain telah mendapatkan otorisasi yang tepat dari pemilik akun, dan apakah operator tidak dengan jahat memperbarui saldo untuk mencuri dana pengguna atau secara tidak jujur mengalokasikannya kembali ke pengguna lain.

Masalahnya adalah, jika hanya akar pohon merkle yang dipublikasikan di on-chain, bagaimana pengguna dapat menempatkan cabang mereka di dalam pohon sehingga mereka dapat keluar kapan pun mereka mau tanpa perlu izin?

Rollup yang Sesuai

Dalam Rollup yang sesuai, setiap kali transaksi off-chain baru dikonfirmasi dan status Rollup akun berubah, informasi akan langsung dimasukkan ke dalam blockchain. Bukan seluruh pohon, itu terlalu absurd, tetapi informasi yang diperlukan untuk membangun kembali pohon tersebut. Dalam implementasi sederhana, ringkasan dari semua akun yang ada dalam Rollup akan mencakup saldo, dan akun hanya ditambahkan dalam transaksi pembaruan Rollup.

Dalam implementasi yang lebih canggih, menggunakan perbedaan saldo akun. Pada dasarnya ini adalah ringkasan tentang akun mana yang menambah atau mengurangi dana selama proses pembaruan. Ini memungkinkan setiap pembaruan Rollup hanya mengandung perubahan saldo akun yang terjadi. Kemudian, pengguna dapat dengan mudah memindai rantai dan ‘menghitung’ dari awal Rollup untuk mendapatkan status saldo akun saat ini, yang memungkinkan mereka membangun kembali pohon Merkle dari saldo saat ini.

Dengan cara ini, pengguna dapat menghemat banyak biaya dan ruang Blok (sehingga menghemat dana), sambil tetap memungkinkan pengguna untuk memastikan informasi yang dibutuhkan untuk keluar dari sisi satu arah. Aturan rollup mengharuskan data-data ini dimasukkan ke dalam rollup resmi yang disediakan oleh Blokchain kepada pengguna, yaitu transaksi yang tidak mencakup ringkasan akun atau perbedaan akun dianggap sebagai transaksi yang tidak valid.

Masa Berlaku

Salah satu cara lain untuk menangani masalah ketersediaan data penarikan pengguna adalah dengan meletakkan data di tempat lain di luar Blok. Ini memperkenalkan masalah yang rumit karena rollup masih perlu memastikan data tersedia di tempat lain. Secara tradisional, Blok lain digunakan untuk tujuan ini, dirancang khusus sebagai lapisan ketersediaan data untuk sistem rollup dan sejenisnya.

Hal ini menyebabkan dilema keamanan yang sama kuatnya. Ketika data langsung dipublikasikan ke BTCBlok Chain, aturan Konsensus dapat memastikan kebenarannya mutlak. Namun, ketika data tersebut dipublikasikan ke sistem eksternal, yang terbaik yang dapat dilakukan adalah memverifikasi bukti SPV, yaitu data telah dipublikasikan ke sistem lain.

Ini memerlukan verifikasi data ada di bukti on-chain lain, akhirnya ini adalah sebuah masalah Mesin Oracle. Rantai Blok BTC tidak dapat sepenuhnya memverifikasi apa pun yang terjadi di luar transaksi on-chain sendiri, yang terbaik yang dapat dilakukan adalah memverifikasi ZKP. Namun, ZKP tidak dapat memverifikasi apakah data rollup dari Blok yang dihasilkan benar-benar disiarkan secara terbuka. Ini tidak dapat memverifikasi apakah informasi eksternal benar-benar tersedia untuk semua orang.

Ini membuka pintu bagi serangan retensi data, yaitu membuat janji untuk data yang dipublikasikan dan menggunakan rollup untuk mendorong, tetapi data yang sebenarnya tidak tersedia. Ini menyebabkan pengguna tidak dapat menarik dana. Satu-satunya solusi nyata adalah bergantung sepenuhnya pada nilai dan struktur insentif sistem di luar BTC.

Terjepit di antara dua pilihan

Ini menghadirkan dilema bagi rollup. Ketika menghadapi masalah ketersediaan data, ada dua pilihan biner, yaitu mempublikasikan data ke blockchain BTC atau tempat lain. Pilihan ini memiliki dampak besar pada keamanan, kedaulatan, dan skalabilitas rollup.

Di satu sisi, menggunakan BTCBlok Blok sebagai lapisan ketersediaan data akan memberikan batas maksimal pada skalabilitas rollup. Ruang Blok terbatas, yang membatasi jumlah rollup yang dapat ada dalam satu waktu dan jumlah total transaksi yang dapat diproses secara off-chain untuk semua rollup. Setiap pembaruan rollup membutuhkan ruang Blok yang sebanding dengan jumlah akun yang mengalami perubahan saldo sejak pembaruan sebelumnya. Teori informasi hanya memungkinkan data dikompresi sampai batas tertentu, dan pada titik ini, tidak ada potensi skalabilitas yang lebih lanjut.

Di sisi lain, menggunakan lapisan yang berbeda untuk mencapai ketersediaan data akan menghilangkan batasan keras dari manfaat skalabilitas, tetapi juga membawa masalah keamanan dan kedaulatan baru. Dalam Rollup yang menggunakan BTC untuk mencapai ketersediaan data, jika data yang ingin diekstraksi oleh pengguna tidak secara otomatis dipublikasikan ke blockchain, maka status Rollup tidak akan berubah. Dengan menggunakan Validiums, jaminan ini sepenuhnya bergantung pada kemampuan sistem eksternal yang digunakan untuk melawan penipuan dan menyembunyikan data.

Sekarang, produsen Blok apa pun di sistem ketersediaan data eksternal dapat mengambil alih dana pengguna BTCRollup dengan menghasilkan Blok tanpa harus siaran Blok yang sebenarnya, sehingga membuat data menjadi tersedia.

Jadi, jika kita benar-benar berhasil menerapkan Rollup yang ideal di BTC, dan berhasil mewujudkan penarikan satu arah pengguna, bagaimana itu akan terjadi?

BTC-0.06%
ETH0.02%
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
  • Hadiah
  • Komentar
  • Posting ulang
  • Bagikan
Komentar
0/400
Tidak ada komentar
  • Sematkan
Perdagangkan Kripto Di Mana Saja Kapan Saja
qrCode
Pindai untuk mengunduh aplikasi Gate
Komunitas
Bahasa Indonesia
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)