Catatan: Artikel ini adalah bagian kedua dari rangkaian artikel "Kemungkinan masa depan untuk protokol Ethereum, bagian 2: The Surge" yang baru-baru ini diterbitkan oleh Vitalik, pendiri ETH Place. Disusun oleh Deng Tong dari Golden Finance, berikut ini adalah teks lengkap dari bagian kedua:

Pada awalnya, Ethereum memiliki dua strategi ekspansi dalam peta jalan mereka.

Salah satunya adalah “Sharding”: setiap Node hanya perlu memverifikasi dan menyimpan sebagian kecil transaksi, bukan semua transaksi dalam rantai. Ini juga cara kerja jaringan peer-to-peer lainnya (seperti BitTorrent), sehingga tentu saja kita dapat membuat blockchain bekerja dengan cara yang sama.

Salah satunya adalah protokol lapisan 2: Jaringan akan berada di atas Ethereum, memungkinkan mereka untuk sepenuhnya memanfaatkan keamanannya, sambil menjauhkan sebagian besar data dan komputasi dari mainchain. "Protokol lapisan 2" mengacu pada State Channels tahun 2015, Plasma tahun 2017, dan Rollups tahun 2019. Rollup lebih kuat daripada State Channels atau Plasma, namun memerlukan lebar pita data on-chain yang besar.

Untungnya, pada tahun 2019, studi Sharding telah memecahkan masalah verifikasi "ketersediaan data" dalam skala besar. Akibatnya, kedua jalur bergabung, dan kami berakhir dengan peta jalan Rollup-sentris yang masih merupakan strategi penskalaan Ethereum saat ini.

The Surge, versi peta jalan 2023.

Rencana jalan yang berpusat pada Rollup mengusulkan pembagian kerja yang sederhana: ETHereum L1 fokus untuk menjadi lapisan dasar yang kuat dan Desentralisasi, sedangkan L2 bertanggung jawab untuk membantu ekosistem berkembang. Ini adalah pola yang muncul berulang kali di masyarakat: sistem pengadilan (L1) tidak dirancang untuk kecepatan super tinggi dan efisiensi, tetapi untuk melindungi kontrak dan hak properti, sedangkan pengusaha (L2) perlu membangun lapisan dasar yang kokoh di atasnya dan membawa manusia ke (secara kiasan dan harfiah) planet Mars.

Tahun ini, peta jalan berbasis Rollup mencapai kesuksesan penting: lebar pita data ETH L1 meningkat secara signifikan melalui EIP-4844 blob, dan beberapa EVM Rollup sekarang berada di tahap pertama. Implementasi Sharding yang sangat heterogen dan beragam, di mana setiap L2 berperan sebagai 'shard' dengan aturan dan logika internalnya sendiri, sekarang menjadi kenyataan. Namun seperti yang kita lihat, menempuh jalur ini memiliki beberapa tantangan unik. Oleh karena itu, tugas kita sekarang adalah menyelesaikan peta jalan berbasis Rollup ini, menangani masalah ini, sambil mempertahankan kekokohan dan desentralisasi yang membuat ETH L1 berbeda dari yang lain.

Surge: Target Utama

L1+L2 di atas 100.000+ TPS

Menjaga Desentralisasi dan kestabilan L1

Setidaknya beberapa L2 sepenuhnya mewarisi sifat inti Ethereum (Trustless, Terbuka, Anti Sensor)

Keteroperasian maksimum antar L2. Ethereum seharusnya terasa seperti sebuah ekosistem, bukan 34 rantai blok yang berbeda.

Trilema Ketidakmampuan Skalabilitas

Skalabilitas The Impossible Triangle adalah gagasan yang diajukan pada tahun 2017 yang menyatakan bahwa ada ketegangan antara tiga atribut blockchain: Desentralisasi (lebih tepatnya: biaya rendah untuk menjalankan Node), skalabilitas (lebih tepatnya: memproses jumlah transaksi yang besar), dan keamanan (lebih tepatnya: penyerang harus menghancurkan sebagian besar Node dalam jaringan untuk membuat satu transaksi gagal).

Perlu diperhatikan bahwa dilema tiga sulit bukanlah teorema, dan posting yang mengenalkan dilema tiga sulit tidak dilengkapi dengan bukti matematis. Ini memberikan argumen matematika yang bersifat heuristik: jika Node yang ramah Desentralisasi (misalnya, laptop konsumen) dapat memverifikasi N transaksi per detik, dan Anda memiliki rantai yang memproses k*N transaksi per detik, maka (i) setiap transaksi hanya dapat dilihat oleh Node 1/k, yang berarti penyerang hanya perlu merusak beberapa Node untuk mendorong transaksi buruk, atau (ii) Node Anda akan menjadi kuat dan rantai Anda tidak bersifat Desentralisasi. Tujuan artikel ini bukanlah untuk menunjukkan bahwa memecahkan dilema tiga sulit tidak mungkin; sebaliknya, tujuannya adalah untuk menunjukkan bahwa memecahkan dilema tiga sulit sulit - itu memerlukan pemikiran di luar kotak yang diisyaratkan oleh argumen.

Selama bertahun-tahun, beberapa rantai kinerja tinggi sering mengklaim bahwa mereka telah menyelesaikan tiga kesulitan tanpa mengambil tindakan canggih apa pun pada tingkat infrastruktur, biasanya dengan mengoptimalkan Node melalui teknik rekayasa perangkat lunak. Ini selalu menyesatkan, dan menjalankan Node pada rantai seperti ini selalu jauh lebih sulit daripada di Ethereum. Artikel ini membahas banyak nuansa mengapa hal ini terjadi (dan mengapa teknik rekayasa perangkat lunak klien L1 tidak dapat meluas secara independen atas ETH itu sendiri).

Namun, kombinasi Data Availability Sampling (DAS) dan SNARK memang menyelesaikan tiga masalah sulit: ini memungkinkan klien memverifikasi ketersediaan sejumlah data, serta apakah sejumlah langkah komputasi dilakukan dengan benar, sambil hanya mengunduh sebagian kecil dari data tersebut dan menjalankan hitungan yang jauh lebih kecil. SNARK tidak dapat dipercaya. Data Availability Sampling memiliki model kepercayaan minoritas N yang halus, tetapi mempertahankan sifat dasar rantai yang tidak dapat diperluas, bahkan serangan 51% tidak dapat memaksa jaringan menerima blok yang buruk.

Salah satu cara lain untuk mengatasi dilema tiga sulit adalah dengan menggunakan arsitektur Plasma, yang menggunakan teknologi yang cerdik untuk mendorong tanggung jawab pemantauan ketersediaan data kepada pengguna dengan cara yang kompatibel. Pada tahun 2017-2019, ketika yang dibutuhkan untuk memperluas komputasi hanyalah bukti penipuan, fitur keamanan Plasma sangat terbatas, tetapi kepopuleran SNARK membuat arsitektur Plasma lebih cocok untuk kasus penggunaan yang lebih luas daripada sebelumnya.

Kemajuan Lanjutan DAS

Apa masalah yang ingin kita selesaikan?

Pada 13 Maret 2024, ketika Dencun diperbarui dan diluncurkan, blok rantai ETH memiliki sekitar 3 buah 'blob' dengan ukuran sekitar 125 kB setiap 12 detik, atau bandwidth data sekitar 375 kB per periode. Diasumsikan data transaksi dipublikasikan langsung ke rantai, transfer ERC20 sekitar 180 byte, sehingga TPS maksimum rollups di ETH adalah:

375000 / 12 / 180 = 173,6 TPS

Jika kita menambahkan calldata Ethereum (maksimum teoritis: 30 juta Gas per slot / 16 Gas per byte = 1.875.000 byte per slot), ini akan menjadi 607 TPS. Untuk PeerDAS, rencananya adalah meningkatkan target penghitungan blob menjadi 8-16, yang akan memberikan calldata sebesar 463-926 TPS.

Ini adalah peningkatan besar dibandingkan dengan L1 Ethereum, tetapi itu belum cukup. Kami ingin lebih banyak skalabilitas. Tujuan jangka menengah kami adalah 16 MB setiap slot, yang jika dikombinasikan dengan perbaikan kompresi data, akan memberikan kami sekitar 58.000 TPS.

Apa itu PeerDAS dan bagaimana cara kerjanya?

PeerDAS adalah implementasi yang relatif sederhana dari 'sampling satu dimensi'. Setiap blob di Ethereum adalah polinomial derajat 4096 di atas medan bilangan prima 253 bit. Kami menyebarkan 'bagian' dari polinomial tersebut, di mana setiap bagian terdiri dari 16 evaluasi di 16 koordinat yang berdekatan yang diambil dari total 8192 set koordinat. Setiap 4096 evaluasi dari 8192 evaluasi ini (menggunakan parameter yang disarankan saat ini: 64 acak dari 128 sampel yang mungkin) dapat memulihkan blob tersebut.

Prinsip kerja PeerDAS adalah dengan membiarkan setiap klien mendengarkan subnet dalam jumlah kecil, di mana subnet ke-i menyiarakan sampel ke-i dari setiap Blob, dan juga mengirim permintaan ke peserta di jaringan p2p global untuk mengambil Blob yang diperlukan dari subnet lain (siapa yang mendengarkan subnet yang berbeda). Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa lapisan permintaan tambahan.** Rekomendasi saat ini adalah Node yang berpartisipasi dalam Proof of Stake menggunakan SubnetDAS, sementara Node lainnya (yaitu 'klien') menggunakan PeerDAS.**

Secara teori, kita dapat memperluas sampel 1D dengan cukup jauh: jika kita meningkatkan jumlah blob maksimum menjadi 256 (sehingga targetnya adalah 128), maka kita akan mencapai target 16 MB, sementara sampel ketersediaan data hanya membutuhkan biaya 16 sampel * 128 blob * 512 byte per blob per sampel = lebar pita data 1 MB per slot. Ini masih dalam toleransi kami: ini layak dilakukan, tetapi berarti klien dengan bandwidth terbatas tidak dapat melakukan sampel. Kami dapat mengoptimalkannya dengan mengurangi jumlah blob dan meningkatkan ukuran blob, tetapi ini akan membuat pemulihan menjadi lebih mahal.

Oleh karena itu, akhirnya kami ingin melangkah lebih jauh dengan melakukan pengambilan sampel 2D, yang tidak hanya dilakukan dengan pengambilan sampel acak di dalam blob, tetapi juga di antara blob secara acak. Properti linear yang dijanjikan oleh KZG digunakan untuk 'memperluas' kumpulan blob di dalam Blok melalui daftar 'blob virtual' baru yang mengkodekan redundansi informasi yang sama.

Sumber: a16z

Yang penting, ekstensi komitmen komputasi tidak memerlukan blok, sehingga solusi ini pada dasarnya ramah terhadap konstruksi blok terdistribusi. Node Blok yang sebenarnya hanya perlu memiliki komitmen Blob KZG, dan dapat bergantung pada DAS untuk memverifikasi ketersediaan Blob itu sendiri. 1D DAS pada dasarnya juga ramah terhadap konstruksi Blok terdistribusi.

Apa hubungannya dengan penelitian yang ada?

Artikel asli tentang ketersediaan data (2018):

Makalah Lanjutan:

Postingan Penjelasan DAS, Paradigma:

KZG menjanjikan ketersediaan 2D:

PeerDAS di ethresear.ch: dan makalah:

EIP-7594：

SubnetDAS di ethresear.ch:

Perbedaan Halus yang Dapat Dipulihkan dalam Sampling 2D:

Apa yang masih perlu dilakukan, apa yang perlu dipertimbangkan?

Langkah selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Mulai dari saat itu, peningkatan terus-menerus pada hitungan blob di PeerDAS adalah pekerjaan yang berkelanjutan, sambil memantau jaringan dengan cermat dan meningkatkan perangkat lunak untuk memastikan keamanan. Sementara itu, kami berharap untuk melakukan lebih banyak kerja akademis yang berinteraksi dengan PeerDAS dan versi DAS lainnya sehubungan dengan keamanan fork choice rule dan isu-isu formalitas.

Ke depan, kita perlu melakukan lebih banyak pekerjaan untuk mengetahui versi ideal DAS 2D dan membuktikan fitur keamanannya. Kami juga ingin akhirnya bermigrasi dari KZG ke alternatif yang tahan kuantum dan bebas kepercayaan. Saat ini, kami tidak tahu ada kandidat yang ramah untuk mendistribusikan bangunan Blok. Bahkan teknik "kasar" yang mahal menggunakan STARK rekursif untuk menghasilkan bukti validitas yang merekonstruksi baris dan kolom tidak cukup, karena ukuran hash STARK secara teknis adalah O(log(n) * log(log(n)) (dengan STIR), padahal sebenarnya STARK hampir sebesar seluruh gumpalan.

Dalam jangka panjang, saya berpikir jalur realitas adalah:

• Alat 2D DAS yang ideal;
• Tetap menggunakan 1D DAS, mengorbankan efisiensi bandwidth sampel untuk kesederhanaan dan kekokohan dan menerima batas data yang lebih rendah;
• (Hard Pivot) Mengabaikan DA dan sepenuhnya mengadopsi Plasma sebagai arsitektur Layer 2 utama kami yang diikuti.

Kita dapat melihat ini melalui pertimbangan ruang lingkup:

Harap dicatat, bahkan jika kami memutuskan untuk memperluas eksekusi langsung di L1, pilihan ini masih ada. Hal ini karena jika L1 harus menangani TPS dalam jumlah besar, blok L1 akan menjadi sangat besar, pelanggan akan memerlukan cara yang efektif untuk memverifikasi apakah mereka benar, sehingga kami harus menggunakan teknologi yang mendukung Rollup (ZK-EVM dan DAS) yang sama dan L1.

Bagaimana interaksinya dengan bagian lain dari peta jalan?

Jika kompresi data (lihat teks berikut) diterapkan, permintaan untuk 2D DAS akan berkurang, atau setidaknya akan mengalami latensi, jika Plasma digunakan secara luas, permintaan untuk 2D DAS akan semakin berkurang. DAS juga menantang pembangunan protokol dan mekanisme Blok yang terdistribusi: meskipun DAS secara teoritis bersahabat dengan rekonstruksi terdistribusi, tetapi dalam praktiknya perlu digabungkan dengan mekanisme pemilihan fork yang melibatkan proposal daftar inklusi dan lingkungannya.

Kompresi Data (Data compression)

Apa masalah yang ingin kita selesaikan?

Setiap transaksi dalam Rollup akan menggunakan ruang data on-chain yang besar: transfer ERC20 membutuhkan sekitar 180 byte. Meskipun menggunakan sampel ketersediaan data yang ideal, ini akan membatasi skalabilitas protokol lapisan 2. Setiap slot memiliki kapasitas 16 MB, sehingga kita mendapatkan:

16000000 / 12 / 180 = 7407 TPS

Jika kita bisa menyelesaikan tidak hanya pembilang, tetapi juga penyebut, dan membuat setiap transaksi dalam Rollup menggunakan lebih sedikit byte di on-chain, apa yang harus kita lakukan?

Apa itu dan bagaimana cara kerjanya?

Saya pikir penjelasan terbaik adalah gambar ini dua tahun yang lalu:

Keuntungan termudah adalah kompresi nol byte: ganti setiap urutan byte nol yang panjang dengan dua byte yang mewakili jumlah byte nol. Lebih lanjut, kami memanfaatkan atribut khusus transaksi:

• Agregasi Tanda Tangan - Kami beralih dari tanda tangan ECDSA ke tanda tangan BLS, yang memiliki sifat dapat menggabungkan banyak tanda tangan menjadi satu tanda tangan tunggal yang dapat membuktikan validitas semua tanda tangan asli. L1 tidak mempertimbangkan hal ini karena biaya komputasi verifikasi (bahkan dengan penggabungan) lebih tinggi, tetapi dalam lingkungan data yang langka seperti L2, mereka dapat dikatakan bermakna. Fungsi agregasi ERC-4337 menyediakan cara untuk mencapai tujuan ini.
• Ganti Alamat dengan Pointer - Jika sebelumnya menggunakan Alamat, kita dapat menggantinya dengan pointer 4 byte yang menunjuk ke posisi sejarah. Ini diperlukan untuk mencapai keuntungan maksimum, meskipun perlu upaya untuk mewujudkannya karena memerlukan sejarah blockchain (setidaknya sebagian) agar efektif menjadi bagian dari negara. ** Serialisasi kustom nilai transaksi ** - Sebagian besar nilai transaksi hanya memiliki beberapa angka, misalnya. 0,25 ETH direpresentasikan sebagai 250.000.000.000.000.000.000.000 wei. Biaya dasar maks gas dan biaya prioritas bekerja dengan cara yang sama. Akibatnya, kita dapat menggunakan format floating-point desimal khusus, atau bahkan kamus nilai yang sangat umum, untuk mewakili sebagian besar nilai moneter dengan sangat kompak.

Apa hubungannya dengan penelitian yang ada?

Eksplorasi dari sequence.xyz:

Untuk mengoptimalkan kontrak Calldata L2 dari ScopeLift:

Strategi lain - Rollup berbasis bukti validitas (juga dikenal sebagai ZKRollup) memposting perbedaan status bukan transaksi: jejak data di l2

Dompet BLS - Menggabungkan BLS melalui ERC-4337:

Apa yang masih perlu dilakukan, apa yang perlu dipertimbangkan?

Tugas utama yang tersisa adalah menerapkan rencana di atas ke dalam tindakan. Pertimbangan utamanya adalah:

• Beralih ke tanda tangan BLS memerlukan upaya besar dan dapat menurunkan kompatibilitas dengan chip keras tepercaya yang dapat meningkatkan keamanan. Pengemas ZK-SNARK yang menggunakan skema tanda tangan lain dapat digunakan sebagai pengganti.
• Kompresi dinamis (misalnya dengan mengganti Alamat dengan pointer) membuat kode klien menjadi rumit.
• Mengirim perbedaan status ke blok alih-alih transaksi akan menurunkan auditabilitas, dan membuat banyak perangkat lunak (misalnya blockchain explorer) tidak dapat berfungsi.

Bagaimana interaksinya dengan bagian lain dari peta jalan?

Pengadopsian ERC-4337, serta akhirnya menggabungkan sebagian isinya ke dalam L2 EVM, dapat secara signifikan mempercepat penyebaran teknologi agregasi. Menyertakan sebagian isi ERC-4337 ke dalam L1 dapat mempercepat penyebarannya di L2.

Plasma umum

Apa masalah yang ingin kita selesaikan?

Bahkan dengan blob 16 MB dan kompresi data, 58.000 TPS belum tentu cukup untuk sepenuhnya mengambil alih pembayaran konsumen, Desentralisasi sosial, atau area bandwidth tinggi lainnya, dan ini terutama benar jika kita mulai berpikir tentang privasi, yang dapat mengurangi skalabilitas sebesar 3 -8x. Untuk aplikasi bervolume tinggi dan bernilai rendah, salah satu opsi saat ini adalah validium, yang menyimpan data dalam keadaan off-chain dan memiliki model keamanan yang menarik di mana operator tidak dapat mencuri dana pengguna, tetapi mereka dapat menghilang dan membekukan sementara atau permanen semua dana pengguna. Tapi kita bisa melakukan yang lebih baik.

Apa itu dan bagaimana cara kerjanya?

Plasma adalah solusi penskalaan yang melibatkan operator mengirimkan Blok di luar rantai dan menempatkan akar Merkle dari Blok-blok tersebut di on-chain (berbeda dengan rollups, rollups menempatkan seluruh Blok di on-chain). Untuk setiap Blok, operator mengirimkan cabang Merkle ke setiap pengguna untuk membuktikan apa yang terjadi atau tidak terjadi pada aset pengguna. Pengguna dapat menarik aset mereka dengan menyediakan cabang Merkle. Pentingnya, cabang tersebut tidak perlu berakar pada status terbaru - oleh karena itu, bahkan jika ketersediaan data gagal, pengguna masih dapat memulihkan aset mereka dengan menarik status terbaru yang tersedia. Jika pengguna mengirimkan cabang yang tidak valid (misalnya, menarik aset yang sudah mereka kirimkan ke orang lain, atau operator menciptakan aset secara tidak benar), mekanisme tantangan on-chain dapat menentukan siapa yang benar-benar memiliki aset tersebut.

Plasma Cash grafik rantai. Transaksi pengeluaran koin i ditempatkan di posisi ke-i dalam pohon. Dalam contoh ini, jika semua pohon sebelumnya valid, kita tahu bahwa sekarang Eve memiliki koin keras 1, David memiliki koin keras 4, George memiliki koin keras 6.

Versi awal Plasma hanya dapat menangani kasus pembayaran dan tidak dapat diperluas dengan efektif. Namun, jika kita meminta setiap root untuk diverifikasi dengan SNARK, maka Plasma akan menjadi lebih kuat. Setiap permainan tantangan dapat disederhanakan secara signifikan karena kita menghilangkan sebagian besar jalur kemungkinan operator curang. Jalur baru juga terbuka, memungkinkan teknologi Plasma untuk diperluas ke berbagai kategori aset. Akhirnya, dalam kasus operator tidak curang, pengguna dapat segera menarik dana tanpa harus menunggu periode tantangan selama seminggu.

Salah satu metode untuk membuat rantai EVM Plasma (bukan satu-satunya metode): menggunakan ZK-SNARK untuk membangun pohon UTXO paralel yang mencerminkan perubahan saldo yang dilakukan oleh EVM, dan mendefinisikan perbedaan poin mapping unik dari 'mata uang yang sama' dalam sejarah. Kemudian, struktur Plasma dapat dibangun di atas dasar ini.

Salah satu wawasan penting adalah sistem Plasma tidak perlu sempurna. Bahkan jika Anda hanya dapat melindungi sebagian kecil aset (misalnya, bahkan hanya token yang tidak bergerak dalam seminggu terakhir), Anda sudah sangat meningkatkan situasi EVM yang sangat scalable, ini adalah suatu validasi.

Jenis struktur lainnya adalah struktur Plasma/rollups campuran, seperti Intmax. Struktur ini menempatkan data yang sangat sedikit dari setiap pengguna di on-chain (misalnya 5 byte), dengan cara ini, Anda dapat memperoleh atribut yang berada di antara Plasma dan Rollup: dalam kasus Intmax, Anda dapat memperoleh skalabilitas dan privasi yang sangat tinggi, bahkan di dunia dengan kapasitas 16 MB, batasan kapasitas teoritisnya sekitar 16,000,000 / 12 / 5 = 266,667 TPS.

Apa hubungannya dengan penelitian yang ada?

Kertas Kerja Plasma Asli:

Plasma Cash:

Arus kas Plasma:

Intmax（2023）：

Apa yang masih perlu dilakukan, apa yang perlu dipertimbangkan?

Tugas utama yang tersisa adalah menerapkan sistem Plasma ke dalam produksi. Seperti yang telah disebutkan sebelumnya, 'plasma vs validium' bukanlah pertentangan biner: setiap validium dapat meningkatkan sedikit keamanan dengan menambahkan fitur Plasma ke dalam mekanisme keluar. Bagian penelitian ini dilakukan untuk mendapatkan atribut terbaik dari EVM (dalam hal kebutuhan kepercayaan, biaya gas L1 dalam skenario terburuk, dan kerentanan DoS) serta struktur aplikasi alternatif yang spesifik. Selain itu, kompleksitas konsep Plasma lebih tinggi dibandingkan dengan rollups, sehingga membutuhkan penelitian dan pembangunan kerangka umum yang lebih baik untuk penyelesaian langsung.

Kelemahan utama penggunaan desain Plasma adalah mereka lebih bergantung pada operator dan lebih sulit 'didirikan', meskipun desain Plasma/rollup campuran biasanya dapat menghindari kelemahan ini.

Bagaimana interaksinya dengan bagian lain dari peta jalan?

Semakin efektif solusi Plasma, semakin sedikit tekanan yang dimiliki L1 terhadap ketersediaan data kinerja tinggi. Memindahkan aktivitas ke L2 juga dapat mengurangi tekanan MEV di L1.

Sistem Bukti L2 yang Matang

Apa masalah yang ingin kita selesaikan?

Saat ini, sebagian besar rollup sebenarnya belum dapat dipercaya; Ada Dewan Keamanan yang memiliki kemampuan untuk membatalkan (optimis atau efektif) tindakan sistem yang terbukti. Dalam beberapa kasus, sistem pengesahan bahkan tidak ada sama sekali, atau bahkan jika ya, ia hanya memiliki fungsi "konsultasi". Yang paling canggih adalah (i) beberapa rollup khusus aplikasi, seperti Fuel, yang Trustless, dan (ii) pada saat penulisan, Optimism dan Arbitrum, dua Rollup EVM penuh yang telah mencapai tonggak Trustless parsial yang disebut "Fase 1". Alasan Rollups tidak melangkah lebih jauh adalah karena takut bug dalam kode. Kami membutuhkan Rollups Tanpa Kepercayaan, jadi kami perlu mengatasi ini secara langsung.

Apa itu dan bagaimana cara kerjanya?

Pertama-tama, mari kita tinjau sistem 'stage' yang diperkenalkan pada awal artikel ini. Ada persyaratan lebih rinci, tetapi ringkasannya adalah sebagai berikut:

• Tahap 0: Pengguna harus dapat menjalankan Node dan menyinkronkan rantai. Jika verifikasi sepenuhnya dapat dipercaya/dipusatkan, itu sudah cukup.
• Tahap Pertama: Harus ada sistem bukti (Trustless) yang memastikan hanya transaksi yang valid yang diterima. Komite keamanan yang dapat melawan sistem bukti diperbolehkan, tetapi dengan ambang batas suara 75%. Selain itu, jumlah anggota dewan yang ditentukan oleh undang-undang mencegah sebagian besar (yaitu lebih dari 26%) harus berasal dari perusahaan utama yang membangun Rollup. Mekanisme peningkatan yang lebih lemah (misalnya DAO) diperbolehkan, tetapi harus memiliki latensi yang cukup panjang sehingga pengguna dapat menarik dana mereka sebelum peningkatan jahat disetujui sebelum diluncurkan.
• Fase kedua: Harus ada sistem bukti (yang tidak dapat dipercaya) untuk memastikan hanya transaksi yang valid yang diterima. Dewan Keamanan hanya diizinkan untuk melakukan intervensi jika ada kesalahan yang dapat dibuktikan dalam kode, misalnya jika dua sistem bukti redundan saling tidak konsisten, atau jika satu sistem bukti menerima dua keadaan akhir yang berbeda dari blok yang sama (atau tidak menerima apa pun untuk jangka waktu yang cukup lama, misalnya seminggu). Mekanisme pembaruan diizinkan, tetapi harus ada latensi yang cukup lama.

Tujuan kami adalah mencapai tahap kedua. Tantangan utama dalam mencapai tahap kedua adalah mendapatkan cukup kepercayaan, membuktikan bahwa sistem benar-benar layak dipercayai. Ada dua metode utama yang dapat mencapai hal ini:

• Verifikasi Bentuk: Kita dapat menggunakan matematika modern dan teknologi komputasi untuk membuktikan (optimis atau efektivitas) bahwa sistem hanya menerima Blok yang sesuai dengan spesifikasi EVM. Teknologi-teknologi ini telah ada selama puluhan tahun, tetapi kemajuan terbaru (misalnya, Lean 4) membuatnya lebih praktis, dan kemajuan dalam verifikasi yang dibantu kecerdasan buatan mungkin akan lebih mempercepat tren ini.
• Multitandatangan: Membuat sistem multitandatangan, dan menginvestasikan dana ke dalam sistem tersebut dan Komite Keamanan (dan/atau alat kecil lain yang memiliki asumsi kepercayaan, seperti TEE) antara Multi-tanda-tangan 2-dari-3 (atau lebih besar). Jika sistem tanda-tangan setuju, maka Dewan Keamanan tidak memiliki kekuasaan. Jika mereka tidak setuju, Dewan Keamanan hanya dapat memilih salah satunya, bukan memaksakan jawabannya sendiri secara sepihak.

Grafik formalisasi multi-proofer, yang menggabungkan sistem proof of stake, sistem bukti validitas, dan komite keamanan.

Apa hubungannya dengan penelitian yang ada?

Semantik EVM K (mulai diverifikasi secara resmi pada tahun 2017):

Presentasi tentang Konsep Proof of Stake (2022):

Rencana Taiko menggunakan bukti ganda:

Apa yang masih perlu dilakukan, apa yang perlu dipertimbangkan?

Untuk verifikasi formal, ada banyak. Kami perlu membuat versi verifikasi formal dari SNARK Prover keseluruhan EVM. Ini adalah proyek yang sangat kompleks meskipun kami sudah mulai. Ada trik yang dapat secara signifikan menyederhanakan tugas: kita dapat membuat pembuktian SNARK formal untuk Mesin Virtual Minimum, misalnya. RISC-V atau Cairo, lalu menulis implementasi EVM di dalam VM minimum tersebut (dan secara formal membuktikan kesetaraannya dengan beberapa spesifikasi EVM lainnya).

Bagi para penandatangan ganda, masih ada dua bagian utama yang tersisa. Pertama, kita perlu memiliki keyakinan yang cukup terhadap setidaknya dua sistem kepercayaan yang berbeda, masing-masing aman secara relatif, dan jika salah satunya mengalami kegagalan, itu akan terjadi karena alasan yang berbeda dan tidak terkait (sehingga mereka tidak akan gagal secara bersamaan). Kedua, kita perlu mendapatkan tingkat jaminan yang sangat tinggi dalam logika dasar dari penggabungan sistem kepercayaan. Ini adalah potongan kode kecil. Ada beberapa cara untuk membuatnya sangat kecil - cukup menyimpan dana dalam kontrak Multi-signature yang aman, dengan penandatangan yang mewakili sistem kepercayaan individu - tetapi ini akan datang dengan biaya on-chainGas yang tinggi. Perlu menemukan keseimbangan antara efisiensi dan keamanan.

Bagaimana interaksinya dengan bagian lain dari peta jalan?

Memindahkan kegiatan ke L2 dapat mengurangi tekanan MEV di L1.

Peningkatan Interoperabilitas L2 Cross

Apa masalah yang ingin kita selesaikan?

Tantangan utama dari ekosistem L2 saat ini adalah sulitnya pengguna dalam mengoperasikannya. Selain itu, cara paling sederhana sering kali memperkenalkan asumsi kepercayaan baru: jembatan terpusat, klien RPC, dan sebagainya. Jika kita serius dalam memperlakukan L2 sebagai bagian dari Ethereum, kita perlu membuat ekosistem penggunaan L2 terasa seperti menggunakan ekosistem Ethereum yang terpadu.

Sebuah contoh yang sangat buruk (bahkan berbahaya: saya kehilangan 100 dolar karena kesalahan pemilihan rantai di sini) lintas L2 UX - meskipun ini bukan kesalahan Polymarket, tetapi interoperabilitas lintas L2 seharusnya menjadi tanggung jawab standar Dompet dan Ethereum (ERC) komunitas. Dalam ekosistem Ethereum yang berjalan lancar, mengirim Token dari L1 ke L2 atau dari satu L2 ke L2 harus sama seperti mengirim Token di dalam L1 yang sama.

Apa itu dan bagaimana cara kerjanya?

Peningkatan interoperabilitas L2 lintas-lintas memiliki banyak jenis. Secara umum, pendekatan untuk mengajukan pertanyaan ini adalah dengan memperhatikan bahwa secara teoritis, fokus Rollup pada Ethereum sama dengan pelaksanaan Sharding L1, lalu bertanya-tanya dalam praktiknya di mana perbedaan versi L2 Ethereum saat ini dengan yang ideal. Berikut adalah beberapa:

Alamat-specific Chain: Chains (L1, Optimism, Arbitrum...) ) harus menjadi bagian dari Alamat. Setelah diimplementasikan, alur kirim lintas-L2 dapat diimplementasikan hanya dengan meletakkan Alamat ke bidang "Kirim", di mana Dompet dapat mengetahui cara mengirim di latar belakang (termasuk menggunakan bridgeprotokol).

• Permintaan Pembayaran Khusus Rantai: Pembuatan pesan dalam format "Kirimkan saya Z on-chain Token X jenis Y" harus sederhana dan terstandarisasi. Ini memiliki dua kasus penggunaan utama: (i) pembayaran, baik itu antar individu maupun layanan individu ke pedagang, dan (ii) aplikasi terdesentralisasi yang meminta dana, misalnya contoh Polymarket di atas.
• **Interaksi Cross-Chain交换和 Gas 支付：**Harus ada protokol terbuka standar untuk mengekspresikan interaksi operasi Cross-Chain, misalnya "Saya mengirim 1 ETH di Optimism ke seseorang yang mengirim 0.9999 ETH di Arbitrum", dan "Saya mengirim 0.0001 ETH di Optimism, siapa pun yang termasuk transaksi ini di Arbitrum". ERC-7683 adalah upaya untuk yang pertama, sedangkan RIP-7755 adalah upaya untuk yang kedua, meskipun keduanya lebih umum daripada penggunaan kasus khusus ini.
• **light client: **Pengguna harus dapat memverifikasi secara nyata rantai yang mereka interaksi dengan, bukan hanya mempercayai penyedia RPC. Helios Mata Uang Kripto A16z telah mencapai ini untuk Ethereum itu sendiri, tetapi kita perlu memperluas kepercayaan ini ke L2. ERC-3668 (CCIP-baca) adalah strategi untuk mencapai tujuan ini.

Bagaimana cara light client memperbarui tampilan rantai Ether-nya. Setelah ada rantai header, Anda dapat menggunakan bukti Merkle untuk memverifikasi objek status apa pun. Setelah Anda memiliki objek status L1 yang benar, Anda dapat menggunakan bukti Merkle (dan tanda tangan jika Anda ingin memeriksa konfirmasi sebelumnya) untuk memverifikasi objek status apa pun di L2. Helios telah berhasil melakukan yang pertama. Memperluas ke yang terakhir adalah tantangan standar.

• Dompet Kunci Rahasia: Saat ini, jika Anda ingin memperbarui Kunci Rahasia yang mengendalikan Smart ContractDompet, Anda harus melakukannya di semua N on-chain di mana Dompet tersebut berada. Dompet Kunci Rahasia adalah teknologi yang memungkinkan Kunci Rahasia ada di satu lokasi (baik itu di L1 atau mungkin di L2 nanti) dan kemudian dibaca dari L2 mana pun yang memiliki salinan Dompet. Ini berarti pembaruan hanya perlu terjadi sekali. Untuk efisiensi, Dompet Kunci Rahasia mengharuskan L2 memiliki cara standar untuk membaca L1 tanpa biaya; dua saran untuk ini adalah L1SLOAD dan REMOTESTATICCALL.

Diagram pemrograman tentang bagaimana Dompet Kunci Rahasia bekerja.

• Ide 'Jembatan Token Berbagi' yang lebih progresif: Bayangkan dunia di mana semua L2 adalah bukti validitas Rollup, setiap slot berkomitmen untuk blok Ether. Bahkan di dunia ini, mengirim aset 'lokal' dari satu L2 ke L2 lain memerlukan penarikan dan deposit, yang membutuhkan pembayaran gas L1 yang besar. Salah satu cara untuk mengatasi masalah ini adalah dengan membuat sebuah Rollup minimal yang bersama-sama menjaga saldo Token jenis apa yang dimiliki oleh L2 mana, dan memungkinkan pembaruan kolektif dari saldo-saldo ini melalui serangkaian lintas. Operasi pengiriman L2 yang diinisiasi oleh L2 apa saja. Ini akan memungkinkan transfer lintas L2 terjadi tanpa perlu membayar gas L1 setiap kali transfer, dan tanpa perlu teknologi dari Penyedia Likuiditas (seperti ERC-7683).
• Kesesuaian Sinkronisasi: Memungkinkan pemanggilan sinkronisasi antara L2 tertentu dan L1 atau antara beberapa L2. Ini mungkin membantu meningkatkan efisiensi keuangan protokol defi. Yang pertama dapat diselesaikan tanpa koordinasi lintas L2 apa pun; yang terakhir memerlukan urutan bersama. Berbasis Rollup secara otomatis ramah terhadap semua teknologi ini.

Apa hubungannya dengan penelitian yang ada?

Alamat khusus rantai: ERC-3770:

ERC-7683:

RIP-7755：

Desain Dompet Kunci Bergulir:

Helios:

ERC-3668 (kadang-kadang disebut CCIP-read):

Proposal 'Pre-confirmation (based) on (shared)' yang diajukan oleh Justin Drake:

L1SLOAD (RIP-7728):

Remote calls in optimism:

AggLayer, termasuk konsep jembatan token bersama:

Apa yang masih perlu dilakukan, apa yang perlu dipertimbangkan?

Banyak contoh di atas menghadapi dilema kapan untuk melakukan standarisasi dan standarisasi tingkat mana yang harus di standarkan. Jika standarisasi dilakukan terlalu cepat, Anda mungkin menghadapi risiko solusi yang buruk. Jika standarisasi dilakukan terlalu lambat, bisa menyebabkan fragmentasi yang tidak perlu. Dalam beberapa kasus, ada solusi jangka pendek dengan kinerja yang lemah namun lebih mudah diimplementasikan, dan ada juga solusi jangka panjang yang "benar secara akhir" namun membutuhkan waktu yang cukup lama untuk diimplementasikan.

Keunikan dari bagian ini adalah bahwa tugas-tugas ini bukan hanya masalah teknis: mereka juga (mungkin terutama!) masalah sosial. Mereka membutuhkan kerjasama antara L2 dan Dompet serta L1. Kemampuan kita untuk mengatasi masalah ini adalah ujian bagi kemampuan kita sebagai komunitas untuk bersatu.

Bagaimana interaksinya dengan bagian lain dari peta jalan?

Sebagian besar saran dalam struktur yang lebih tinggi dan tidak akan memiliki dampak besar pada pertimbangan L1. Satu pengecualian adalah urutan berbagi, yang memiliki dampak besar pada MEV.

Eksekusi pada L1 yang Diperluas

Apa masalah yang ingin kita selesaikan?

Jika L2 menjadi sangat scalable dan berhasil, tetapi L1 masih hanya mampu menangani sedikit transaksi, maka Ethereum mungkin akan menghadapi banyak risiko:

• Kondisi ekonomi aset ETH menjadi lebih berbahaya, yang pada gilirannya memengaruhi keamanan jangka panjang jaringan.
• Banyak L2 mengambil manfaat dari keterkaitan yang erat dengan ekosistem keuangan yang sangat berkembang di L1, jika ekosistem ini melemah secara signifikan, dorongan bagi L2 untuk menjadi independen dari L1 akan berkurang.
• L2 membutuhkan waktu yang lama untuk memiliki jaminan keamanan yang sama dengan L1.
• Jika L2 mengalami kegagalan (misalnya karena tindakan jahat atau menghilangnya operator), pengguna masih perlu menggunakan L1 untuk memulihkan asetnya. Oleh karena itu, L1 perlu cukup kuat, setidaknya kadang-kadang benar-benar dapat menangani akhir yang sangat kompleks dan kacau dari L2.

Dengan alasan-alasan ini, memperluas L1 itu sendiri dan memastikan bahwa itu bisa terus beradaptasi dengan lebih banyak kegunaan adalah sangat berharga.

Apa itu dan bagaimana cara kerjanya?

Metode perluasan yang paling sederhana adalah dengan menambahkan batasan Gas secara sederhana. Namun, ini membawa risiko sentralisasi L1, yang melemahkan atribut penting lain yang membuat ETH Blok L1 begitu kuat: kepercayaannya sebagai lapisan dasar yang kuat. Ada perdebatan tentang seberapa besar peningkatan batas Gas yang sederhana dapat dilakukan secara berkelanjutan, dan ini juga akan berubah tergantung pada implementasi teknologi lain untuk membuat blok yang lebih besar lebih mudah diverifikasi (misalnya, masa kedaluwarsa historis, non-stateful, bukti validitas L1 EVM). Hal penting lain yang perlu terus ditingkatkan adalah efisiensi perangkat lunak klien ETH Blok, yang lebih dioptimalkan hari ini daripada lima tahun yang lalu. Strategi peningkatan batasan Gas L1 yang efektif akan melibatkan percepatan teknologi verifikasi ini.

Strategi penskalaan lain melibatkan identifikasi fungsi spesifik dan jenis komputasi yang dapat menjadi lebih murah tanpa mengorbankan desentralisasi jaringan atau atribut keamanannya. Contohnya termasuk:

• EOF - Sebuah format bytecode EVM baru yang lebih ramah analisis statis dan dapat memberikan implementasi yang lebih cepat. Mengingat efisiensi ini, bytecode EOF dapat diberikan biaya Gas yang lebih rendah.
• Penentuan harga Gas multidiimensi - Membangun biaya dasar yang terpisah serta batasan perhitungan, data, dan penyimpanan dapat meningkatkan kapasitas rata-rata ETH L1, tanpa meningkatkan kapasitas maksimumnya (sehingga memunculkan risiko keamanan baru).
• Menurunkan Biaya Gas Kode Operasi dan Pra-kompilasi Spesifik - Dalam sejarah, kami telah meningkatkan biaya Gas untuk beberapa operasi yang dihargai terlalu rendah untuk menghindari serangan penolakan layanan. Kami telah melakukannya lebih sedikit tetapi masih bisa melakukan lebih banyak, yaitu menurunkan biaya Gas untuk operasi yang dihargai terlalu tinggi. Misalnya, penjumlahan jauh lebih murah daripada perkalian, tetapi biaya kode operasi ADD dan MUL saat ini sama. Kami bisa membuat ADD lebih murah, dan bahkan kode operasi yang lebih sederhana seperti PUSH menjadi lebih murah. EOF secara keseluruhan lebih banyak.
• EVM-MAX dan SIMD: EVM-MAX (Modul Aritmatika Modular) adalah proposal yang memungkinkan matematika modular bilangan besar yang lebih efisien sebagai modul terpisah dari EVM. Nilai yang dihitung oleh EVM-MAX hanya dapat diakses oleh opcode EVM-MAX lainnya kecuali jika disengaja diekspor; ini memungkinkan ruang yang lebih besar untuk menyimpan nilai-nilai ini dalam format yang dioptimalkan. SIMD (Single Instruction Multiple Data) adalah proposal yang memungkinkan eksekusi instruksi yang sama secara efisien pada array nilai. Keduanya bersama-sama dapat menciptakan koproesor yang kuat dengan EVM yang dapat digunakan untuk mengimplementasikan enkripsi dengan lebih efisien. Ini sangat berguna untuk protokol privasi dan sistem bukti L2, sehingga akan membantu dalam skala L1 dan L2.

Peningkatan ini akan dibahas secara lebih rinci dalam artikel selanjutnya tentang Splurge.

Terakhir, strategi ketiga adalah Rollup asli (atau "Rollup bawaan, diabadikan rollups"): Pada dasarnya, membuat banyak salinan EVM yang berjalan paralel, sehingga membentuk model yang setara dengan model yang dapat disediakan oleh Rollup, tetapi lebih terintegrasi secara alami ke dalam protokol.

Apa hubungannya dengan penelitian yang ada?

Rencana peningkatan kapasitas L1 Polynya untuk Ethereum (ETH) :

Penentuan Harga Gas Multidimensi:

EIP-7706:

EOF:

EVM-MAX:

SIMD:

Rollup Asli:

Wawancara dengan Max Resnick tentang Nilai Perluasan L1:

Justin Drake tentang penggunaan SNARK dan Rollup asli untuk skalabilitas:

Apa yang masih perlu dilakukan, apa yang perlu dipertimbangkan?

Ekstensi L1 memiliki tiga strategi yang dapat dilakukan secara terpisah atau paralel:

• Meningkatkan teknologi (misalnya kode klien, klien tanpa status, kadaluarsa historis) membuat L1 lebih mudah diverifikasi, kemudian meningkatkan batasan gas
• Menurunkan biaya operasi tertentu, meningkatkan kapasitas rata-rata tanpa meningkatkan risiko dalam situasi terburuk
• Rollup asli (yaitu 'membuat N salinan paralel EVM', meskipun mungkin memberikan fleksibilitas yang besar bagi pengembang dalam hal parameter penyebaran salinan)

Perlu dipahami bahwa ini adalah teknologi yang berbeda dengan pertimbangan yang berbeda. Misalnya, Rollup asli memiliki banyak kelemahan yang sama dengan Rollup biasa dalam hal komposabilitas: Anda tidak dapat mengirim transaksi tunggal untuk melakukan operasi sinkronisasi melintasi beberapa transaksi seperti yang dapat Anda lakukan dalam pemrosesan kontrak di L1 (atau L2) yang sama. Meningkatkan batas Gas akan menanggalkan manfaat lain yang bisa dicapai dengan membuat L1 lebih mudah diverifikasi, seperti meningkatkan persentase pengguna Node verifikasi dan meningkatkan jumlah penjamin terpisah. Membuat operasi tertentu di EVM lebih murah (tergantung pada cara operasinya) dapat meningkatkan kompleksitas keseluruhan EVM.

Satu pertanyaan besar yang harus dijawab oleh setiap rencana perluasan L1 adalah: Apa visi akhir dari L1 dan L2? Jelas bahwa semua hal dilakukan di L1 adalah tidak masuk akal: potensi kasus penggunaan memiliki ribuan transaksi per detik, yang akan membuat L1 tidak dapat diverifikasi (kecuali kita mengadopsi jalur Rollup asli). Namun, kita membutuhkan beberapa prinsip panduan sehingga kita dapat memastikan bahwa kita tidak menghasilkan situasi seperti ini: kita meningkatkan batas Gas 10 kali, merusak Desentralisasi ETH di L1, dan menemukan bahwa kita hanya masuk ke dunia di mana hanya 1% aktivitas berada di L1 dan 90% aktivitas berada di L2, sehingga hasil akhirnya hampir sama kecuali untuk kerugian besar sebagian besar khususitas ETH L1 yang tidak dapat dibalikkan.

Sebuah pandangan proposal tentang 'pembagian kerja' antara L1 dan L2

Bagaimana interaksinya dengan bagian lain dari peta jalan?

Membawa lebih banyak pengguna ke L1 tidak hanya berarti meningkatkan skala, tetapi juga memperbaiki aspek lain dari L1. Ini berarti lebih banyak MEV akan tetap ada di L1 (bukan hanya menjadi masalah L2), sehingga perlu diatasi dengan jelas. Ini sangat meningkatkan nilai waktu slot cepat di L1. Ini juga sangat bergantung pada apakah validasi dari L1 ('The Verge') berjalan lancar.

Terima kasih khususnya kepada Justin Drake, Francesco, Hsiao-wei Wang, @antonttc dan Georgios Konstantopoulos