Artikel baru dari Vitalik: Masa Depan yang Mungkin bagi Ethereum, The Surge

Penulis asli: Vitalik Buterin

Terjemahan asli: Karen, Foresight News

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

Pada awalnya, roadmap ETH memiliki dua strategi scaling. Salah satu (lihat makalah awal tahun 2015) adalah ‘Sharding’: setiap Node hanya perlu memvalidasi dan menyimpan sebagian kecil transaksi, bukan memvalidasi dan menyimpan semua transaksi di dalam chain. Setiap jaringan peer-to-peer lainnya (seperti BitTorrent) juga bekerja seperti ini, jadi tentu saja kita bisa membuat blockchain bekerja dengan cara yang sama. Yang lainnya adalah protokol Layer 2: jaringan ini akan berada di atas ETH, memungkinkannya untuk sepenuhnya memanfaatkan keamanannya sambil menjaga sebagian besar data dan komputasi di luar mainchain. Protokol Layer 2 mengacu pada saluran keadaan tahun 2015, Plasma tahun 2017, dan kemudian Rollup tahun 2019. Rollup lebih kuat dari saluran keadaan atau Plasma, tetapi membutuhkan bandwidth data on-chain yang besar. Untungnya, pada tahun 2019, penelitian Sharding telah memecahkan masalah ‘ketersediaan data’ verifikasi besar skala. Akibatnya, dua jalur digabungkan menjadi satu, dan kami mendapatkan roadmap yang berpusat pada Rollup, yang masih menjadi strategi skala ETH yang digunakan sekarang.

The Surge, versi peta jalan 2023

Rencana jalan yang berpusat pada Rollup menawarkan pembagian kerja yang sederhana: ETH L1 berfokus pada menjadi lapisan dasar yang kuat dan Desentralisasi, sementara L2 bertanggung jawab untuk membantu ekosistem berkembang. Pola ini umum di masyarakat: keberadaan sistem pengadilan (L1) bukan untuk mencari kecepatan dan efisiensi tinggi, melainkan untuk melindungi kontrak dan hak properti, sementara pengusaha (L2) harus membangun di atas lapisan dasar yang kokoh ini, membawa umat manusia ke (baik secara harfiah maupun secara metaforis) Mars.

Tahun ini, roadmap yang berpusat pada Rollup telah mencapai pencapaian penting: dengan peluncuran blob EIP-4844, bandwidth data ETH L1 telah meningkat secara signifikan, dan beberapa ETH Virtual Machine (EVM) Rollup telah memasuki tahap pertama. Setiap L2 ada sebagai entitas ‘Sharding’ dengan aturan dan logika internalnya sendiri, dan keberagaman serta keragaman pendekatan implementasi Sharding kini menjadi kenyataan. Namun, seperti yang kita lihat, langkah ini juga menghadapi beberapa tantangan unik. Oleh karena itu, tugas kita sekarang adalah menyelesaikan roadmap yang berpusat pada Rollup, menangani masalah ini, sambil tetap mempertahankan ketahanan dan desentralisasi khas ETH L1.

Serangan: Target Utama

1. Di masa depan, Ethereum dapat mencapai lebih dari 100.000 TPS melalui L2;

2、Menjaga Desentralisasi dan ketahanan L1;

3、Setidaknya beberapa L2 sepenuhnya mewarisi sifat inti Ethereum (Trustless, terbuka, tahan sensor);

4, Ethereum seharusnya terasa sebagai ekosistem yang terpadu, bukan 34 rantai blok yang berbeda.

Isi Bab

• Paradoks Segitiga Skalabilitas
• Kemajuan lebih lanjut dalam sampel ketersediaan data
• Kompresi Data
• Plasma yang Dalam Umum
• Sistem Bukti L2 yang Matang
• Peningkatan Interoperabilitas L2
• Eksekusi Ekspansi di L1

Paradoks Segitiga Skalabilitas

Paradoks Segitiga Skalabilitas adalah ide yang diusulkan pada tahun 2017 yang menganggap bahwa terdapat kontradiksi antara tiga karakteristik dari blockchain: Desentralisasi (lebih khususnya: biaya rendah untuk menjalankan Node), skalabilitas (mampu memproses sejumlah besar transaksi), dan keamanan (penyerang harus menghancurkan sebagian besar Node di jaringan untuk membuat satu transaksi gagal).

Perlu diperhatikan bahwa paradoks segitiga bukanlah sebuah teorema, dan posting yang memperkenalkan paradoks segitiga tidak dilengkapi dengan bukti matematis. Itu memang memberikan argumen matematis yang bersifat heuristik: jika sebuah 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 1/k Node, yang berarti penyerang hanya perlu merusak sedikit Node untuk berhasil melakukan transaksi jahat, atau (ii) Node Anda akan menjadi kuat, sementara rantai Anda tidak akan Desentralisasi. Tujuan dari artikel ini bukanlah untuk membuktikan bahwa paradoks segitiga tidak mungkin dilanggar; sebaliknya, tujuannya adalah untuk menunjukkan bahwa melanggar paradoks segitiga sulit, dan memerlukan keluar dari kerangka berpikir yang tersirat dalam argumen tersebut.

Selama bertahun-tahun, beberapa blockchain berkinerja tinggi sering mengklaim bahwa mereka berhasil mengatasi paradoks tiga elemen tanpa mengubah arsitektur fundamental, biasanya dengan mengoptimalkan Node menggunakan teknik rekayasa perangkat lunak. Ini selalu menyesatkan, karena menjalankan Node on-chain jauh lebih sulit daripada menjalankan Node di Ethereum. Artikel ini akan membahas mengapa hal ini terjadi, dan mengapa perangkat lunak klien L1 sendiri tidak dapat memperluas Ethereum?

Namun, kombinasi dari sampel ketersediaan data dengan SNARKs memang mengatasi paradoks trikotomi: itu memungkinkan klien untuk memverifikasi ketersediaan sejumlah data dan kebenaran sejumlah langkah komputasi dengan hanya mengunduh sedikit data dan melakukan sedikit komputasi. SNARKs tidak memerlukan kepercayaan. Sampel ketersediaan data memiliki model kepercayaan few-of-N yang halus, namun tetap mempertahankan sifat dasar dari rantai yang tidak dapat diperluas, yaitu bahkan serangan 51% pun tidak dapat memaksa jaringan menerima blok yang buruk.

Salah satu cara lain untuk mengatasi situasi sulit adalah dengan menggunakan arsitektur Plasma, yang menggunakan teknologi canggih untuk mendorong tanggung jawab pemantauan ketersediaan data kepada pengguna secara kompatibel. Pada tahun 2017-2019, ketika kita hanya memiliki bukti penipuan sebagai satu-satunya cara untuk memperluas kemampuan komputasi, Plasma sangat terbatas dalam pelaksanaan keamanan, tetapi dengan berkembangnya SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge), arsitektur Plasma menjadi lebih layak untuk digunakan dalam berbagai skenario daripada sebelumnya.

Kemajuan Lebih Lanjut dalam Sampel Ketersediaan Data

Apa masalah yang sedang kami selesaikan?

Pada tanggal 13 Maret 2024, ketika Dencun upgrade online, slot blok Ethereum blockchain setiap 12 detik memiliki sekitar 3 blob sebesar 125 kB, atau bandwidth data sekitar 375 kB per slot. Jika data transaksi diterbitkan secara langsung on-chain, maka transfer ERC 20 sekitar 180 byte, sehingga TPS maksimum Rollup di ETH blockchain adalah: 375000 / 12 / 180 = 173.6 TPS

Jika kita menambahkan calldata Ethereum (teorinya maksimum: 30 juta Gas per slot / 16 gas per byte = 1.875.000 byte per slot), maka akan menjadi 607 TPS. Dengan menggunakan PeerDAS, jumlah blob mungkin meningkat menjadi 8-16, yang akan memberikan 463-926 TPS untuk calldata.

Ini adalah peningkatan besar-besaran untuk Ether L1, tetapi masih belum cukup. Kami ingin lebih skalabilitas. Tujuan menengah kami adalah setiap slot 16 MB, dan jika dikombinasikan dengan peningkatan kompresi data Rollup, akan membawa ~ 58000 TPS.

Apa itu? Bagaimana cara kerjanya?

PeerDAS adalah implementasi yang relatif sederhana dari ‘1 D sampling’. Di dalam blok ETH, setiap blob adalah polinomial pangkat 4096 di atas lapangan bilangan prima 253-bit. Kami menyiarkan shares polinomial, di mana setiap shares berisi 16 nilai evaluasi dari 16 koordinat yang bersebelahan dari total 8192 koordinat. Dari 8192 nilai evaluasi ini, setiap 4096 (tergantung pada parameter yang diajukan saat ini: 64 dari 128 sampel yang mungkin) dapat memulihkan blob.

Prinsip kerja PeerDAS adalah membuat setiap klien mendengarkan sejumlah kecil subnet, di mana subnet ke-i menyiarkan contoh ke-i dari blob apa pun, dan dengan meminta dari rekan-rekan dalam jaringan p2p global (yang akan mendengarkan subnet yang berbeda) untuk blob di subnet lain yang dibutuhkannya. Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa pertanyaan tambahan ke lapisan rekan. Proposal saat ini adalah untuk membuat Node yang berpartisipasi dalam Proof of Stake menggunakan SubnetDAS, sementara Node lain (yaitu klien) menggunakan PeerDAS.

Secara teori, kita dapat memperluas skala sampling 1 D hingga cukup besar: jika kita meningkatkan jumlah maksimum blob menjadi 256 (dari target 128), maka kita dapat mencapai target 16 MB, sementara setiap Node dalam sampling ketersediaan data memiliki 16 sampel * 128 blob * setiap blob setiap sampel 512 byte = bandwidth data 1 MB per slot. Ini hanya sebatas dalam toleransi kita: ini bisa dilakukan, tetapi ini berarti klien dengan bandwidth terbatas tidak dapat melakukan sampling. Kita dapat melakukan optimisasi sampai batas tertentu dengan mengurangi jumlah blob dan meningkatkan ukuran blob, tetapi hal ini akan meningkatkan biaya pembangunan ulang.

Oleh karena itu, kami akhirnya ingin melangkah lebih jauh dengan melakukan 2D sampling, metode ini tidak hanya melakukan sampling acak di dalam blob, tetapi juga di antara blob. Dengan menggunakan properti linear dari komitmen KZG, kita dapat memperluas kumpulan blob dalam sebuah Blok melalui sekelompok blob virtual baru yang secara redundan mengkodekan informasi yang sama.

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

Sampel 2D. Sumber data: a16z crypto

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 mereka dapat bergantung pada sampel ketersediaan data (DAS) untuk memverifikasi ketersediaan blok data. Sampel ketersediaan data satu dimensi (1 D DAS) juga pada dasarnya ramah terhadap konstruksi blok terdistribusi.

Apa saja tautan dengan penelitian yang ada?

• Postingan asli yang memperkenalkan ketersediaan data (2018):
• Makalah tindak lanjut:
• Artikel penjelasan tentang DAS, paradigma:
• Ketersediaan 2D dengan jaminan KZG:
• PeerDAS di ethresear.ch: dan makalah:
• EIP-7594:
• SubnetDAS di ethresear.ch:
• Perbedaan halus yang dapat dipulihkan dalam sampel 2D:

Apa lagi yang perlu dilakukan? Apa pertimbangan lainnya?

Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, terus meningkatkan jumlah blob di PeerDAS sambil memantau jaringan dengan cermat dan meningkatkan perangkat lunak untuk memastikan keamanan, ini adalah proses bertahap. Sementara itu, pada saat yang sama, kami berharap ada lebih banyak karya akademis untuk mengatur interaksi PeerDAS dan versi lain dari DAS serta masalah keamanan fork choice rule.

Pada tahap yang lebih jauh di masa depan, kami perlu melakukan lebih banyak pekerjaan untuk menentukan versi ideal 2D DAS dan membuktikan sifat keamanannya. Kami juga berharap akhirnya dapat beralih dari KZG ke solusi alternatif yang aman kuantum dan tidak memerlukan pengaturan tepercaya. Saat ini, kami belum yakin solusi mana yang ramah terhadap konstruksi Blok terdistribusi. Bahkan dengan menggunakan teknik ‘brute force’ yang mahal, yaitu menggunakan STARK rekursif untuk menghasilkan bukti validitas yang digunakan untuk membangun kembali baris dan kolom, tidak cukup memenuhi kebutuhan, karena meskipun secara teknis, ukuran STARK adalah O(log(n) * log(log(n)) nilai hash (menggunakan STIR), namun secara praktis STARK hampir sama besarnya dengan seluruh blob.

Jalur realitas jangka panjang yang saya yakini adalah:

1. Menerapkan DAS 2D yang ideal;
2. Berpegang teguh pada penggunaan 1 D DAS, mengorbankan efisiensi lebar pita sampel untuk kesederhanaan dan kekokohan dengan menerima batas data yang lebih rendah
3. （Hard pivot）放弃 DA，完全接受 Plasma 作为我们ikuti的主要 Layer 2 架构。

Harap dicatat bahwa, meskipun kami memutuskan untuk melakukan perluasan langsung di tingkat L1, pilihan ini tetap ada. Hal ini karena jika tingkat L1 harus menangani sejumlah besar TPS, L1 Blok akan menjadi sangat besar, klien akan berharap ada cara yang efisien untuk memverifikasi kebenaran mereka, sehingga kami akan harus menggunakan teknologi yang sama dengan Rollup (seperti ZK-EVM dan DAS) di tingkat L1.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Jika implementasi kompresi data, permintaan untuk 2D DAS akan berkurang, atau setidaknya akan latensi, jika Plasma digunakan secara luas, permintaan akan lebih lanjut berkurang. DAS juga menantang protokol dan mekanisme konstruksi Blok terdistribusi: meskipun DAS secara teoritis ramah untuk rekonstruksi terdistribusi, namun ini memerlukan kombinasi dengan proposal daftar inklusi paket dan mekanisme pilihan fork di sekitarnya dalam praktek.

Kompresi Data

Apa masalah yang sedang kita selesaikan?

Setiap transaksi di Rollup akan menggunakan sejumlah besar ruang data on-chain: transfer ERC 20 memerlukan sekitar 180 byte. Bahkan dengan sampel ketersediaan data yang ideal, ini juga membatasi skalabilitas Layer protokol. Dengan setiap slot 16 MB, kita mendapatkan:

16000000 / 12 / 180 = 7407 TPS

Jika kita tidak hanya bisa mengatasi masalah pembilang, tetapi juga masalah penyebut, dan membuat setiap transaksi dalam Rollup menggunakan lebih sedikit byte di on-chain, bagaimana itu akan terjadi?

Apa itu, bagaimana cara kerjanya?

Menurut pendapat saya, penjelasan terbaik adalah gambar ini dua tahun yang lalu:

Dalam kompresi byte nol, setiap urutan byte nol yang panjang digantikan dengan dua byte untuk menunjukkan jumlah byte nol yang ada. Lebih lanjut lagi, kami memanfaatkan properti transaksi yang spesifik:

Aggregasi Tanda Tangan: Kami beralih dari tanda tangan ECDSA ke tanda tangan BLS, yang memiliki fitur di mana beberapa tanda tangan dapat digabungkan menjadi satu tanda tangan tunggal yang dapat membuktikan validitas semua tanda tangan asli. Di lapisan L1, karena biaya komputasi verifikasi yang tinggi bahkan setelah agregasi, penggunaan tanda tangan BLS tidak dipertimbangkan. Namun, di lingkungan seperti L2 di mana data jarang, penggunaan tanda tangan BLS memiliki makna. Fitur agregasi ERC-4337 menyediakan cara untuk mengimplementasikan fungsi ini.

Mengganti Alamat dengan pointer: Jika sebelumnya menggunakan Alamat tertentu, kita dapat mengganti Alamat 20 byte dengan pointer 4 byte yang menunjuk ke posisi tertentu dalam catatan sejarah.

Serialisasi kustom untuk nilai transaksi - Sebagian besar nilai transaksi memiliki sedikit digit, misalnya, 0,25 ETH direpresentasikan sebagai 250.000.000.000.000.000 wei. Biaya dasar maksimum dan biaya prioritas juga serupa. Oleh karena itu, kita dapat menggunakan format float desimal kustom untuk merepresentasikan sebagian besar nilai mata uang.

Apa saja tautan dengan penelitian yang ada?

• Menjelajahi sequence.xyz:
• Kontrak Optimalisasi L2 Calldata:
• Berdasarkan rollups bukti validitas (juga dikenal sebagai ZK rollups) perbedaan status rilis daripada transaksi:
• Dompet BLS - Menggabungkan BLS melalui ERC-4337:

Apa yang perlu dilakukan, apa pertimbangannya?

Selanjutnya, yang utama adalah mengimplementasikan rencana di atas. Pertimbangan utama termasuk:

1. Beralih ke tanda tangan BLS membutuhkan upaya yang besar dan dapat mengurangi kompatibilitas dengan chip perangkat keras tepercaya yang dapat meningkatkan keamanan. Anda dapat menggunakan bungkus ZK-SNARK dengan skema tanda tangan lain sebagai penggantinya.

2. Kompresi dinamis (misalnya, mengganti Alamat dengan pointers) akan membuat kode klien menjadi kompleks.

3、Menerbitkan perbedaan status ke on-chain alih-alih transaksi, akan menurunkan auditabilitas, dan membuat banyak perangkat lunak (misalnya blockchain explorer) tidak dapat berfungsi.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Menggunakan ERC-4337, dan pada akhirnya beberapa kontennya dimasukkan ke dalam L2 EVM, dapat secara signifikan mempercepat implementasi teknologi agregasi. Menempatkan sebagian konten ERC-4337 di L1 dapat mempercepat implementasinya di L2.

Plasma Generalis

Apa masalah yang sedang kami selesaikan?

Meskipun menggunakan blob 16 MB dan kompresi data, 58.000 TPS mungkin tidak cukup untuk sepenuhnya memenuhi kebutuhan pembayaran konsumen, Desentralisasi sosial, atau bidang berkecepatan tinggi lainnya, terutama ketika kami mulai mempertimbangkan faktor privasi, ini dapat mengurangi kapasitas 3-8 kali lipat. Untuk skenario aplikasi volume tinggi dan nilai rendah, salah satu pilihan saat ini adalah menggunakan Validium, yang menyimpan data di luar rantai (off-chain) dan mengadopsi model keamanan yang menarik: operator tidak dapat mencuri dana pengguna, tetapi mereka mungkin membekukan dana semua pengguna secara sementara atau permanen. Namun, kita bisa melakukan yang lebih baik.

Apa itu, bagaimana cara kerjanya?

Plasma adalah solusi scaling yang melibatkan operator mengirimkan Blok off-chain dan menempatkan akar Merkle dari Blok-blok tersebut di on-chain (berbeda dengan Rollup yang menempatkan Blok lengkap di on-chain). Untuk setiap Blok, operator mengirimkan cabang Merkle ke setiap pengguna untuk membuktikan perubahan aset pengguna atau ketiadaan perubahan. Pengguna dapat mengambil aset mereka dengan menyediakan cabang Merkle. Yang penting, cabang ini tidak perlu berdasarkan pada status terbaru. Oleh karena itu, meskipun ketersediaan data bermasalah, pengguna masih dapat memulihkan aset mereka dengan mengambil status terbaru yang tersedia. Jika pengguna mengirimkan cabang yang tidak valid (misalnya, mengambil aset yang telah mereka kirimkan ke orang lain, atau operator menciptakan aset secara sembarangan), maka dapat ditentukan keabsahan aset melalui mekanisme tantangan on-chain.

Rantai Plasma Cash 图。 Transaksi pengeluaran koin i ditempatkan di posisi ke-i dalam pohon. Dalam contoh ini, dengan asumsi semua pohon sebelumnya valid, kita tahu bahwa Eve saat ini memiliki Token 1, David memiliki Token 4, George memiliki Token 6.

Versi Plasma awal hanya dapat menangani kasus pembayaran dan tidak dapat diperluas dengan efektif. Namun, jika kita meminta setiap root untuk diverifikasi menggunakan SNARK, maka Plasma akan menjadi jauh lebih kuat. Setiap game challenge dapat disederhanakan secara signifikan karena sebagian besar kemungkinan kecurangan operator telah dieliminasi. Pada saat yang sama, ini juga membuka jalan baru untuk memperluas Plasma ke kategori aset yang lebih luas. Akhirnya, dalam kasus operator tidak melakukan kecurangan, pengguna dapat segera menarik dana tanpa harus menunggu periode challenge selama seminggu.

Metode pembuatan rantai EVM Plasma (bukan satu-satunya metode): menggunakan ZK-SNARK untuk membangun sebuah pohon UTXO paralel yang mencerminkan perubahan saldo yang dilakukan oleh EVM, dan mendefinisikan pemetaan unik dari ‘Token yang sama’ pada titik waktu berbeda dalam sejarah. Kemudian dapat membangun struktur Plasma di atasnya.

Satu wawasan kunci adalah bahwa sistem Plasma tidak perlu sempurna. Bahkan jika Anda hanya dapat melindungi subset aset (misalnya, Token yang tidak bergerak dalam seminggu terakhir), Anda telah secara signifikan meningkatkan status quo EVM super skalabel saat ini (yaitu Validium).

Jenis struktur lainnya adalah Plasma/Rollup campuran, seperti Intmax. Struktur ini menempatkan sedikit data setiap pengguna ke on-chain (misalnya, 5 byte), yang dapat memberikan beberapa fitur di antara Plasma dan Rollup: dalam kasus Intmax, Anda dapat mencapai skalabilitas dan privasi yang sangat tinggi, meskipun pada kapasitas 16 MB teoretisnya terbatas pada sekitar 266.667 TPS (16.000.000 / 12 / 5).

Apa saja tautan terkait dengan penelitian yang ada?

• Dokumen Plasma asli:
• Plasma Cash:
• Plasma Cashflow:
• Intmax ( 2023):

Masih perlu melakukan apa? Apa pertimbangannya?

Tugas utama yang tersisa adalah menerapkan sistem Plasma ke dalam aplikasi produksi nyata. Seperti yang telah disebutkan sebelumnya, Plasma dan Validium tidaklah pilihan yang harus dipilih satu atau yang lain: Setiap Validium dapat meningkatkan keamanannya setidaknya sejauh tertentu dengan menggabungkan fitur Plasma dalam mekanisme penarikannya. Fokus penelitian adalah untuk mencapai properti terbaik bagi EVM (dari kebutuhan kepercayaan, biaya L1 Gas dalam skenario terburuk, dan kemampuan melawan serangan DoS), serta struktur aplikasi alternatif. Selain itu, Plasma lebih kompleks secara konseptual dibandingkan dengan Rollup, yang memerlukan penelitian dan pembangunan kerangka umum yang lebih baik untuk menyelesaikannya secara langsung.

Perdagangan utama yang dirancang menggunakan Plasma adalah lebih bergantung pada operator dan lebih sulit untuk didasarkan, meskipun desain campuran Plasma/Rollup biasanya dapat menghindari kelemahan ini.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

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

Sistem Bukti L2 yang Matang

Apa masalah yang sedang kami selesaikan?

Saat ini, sebagian besar Rollup sebenarnya belum Trustless. Ada sebuah komite keamanan yang memiliki kemampuan untuk menggantikan perilaku sistem bukti (optimistik atau validitas). Dalam beberapa kasus, sistem bukti bahkan tidak berjalan sama sekali, atau jika berjalan, hanya memiliki fungsi “konsultasi”. Rollup paling canggih termasuk: (i) beberapa Rollup khusus aplikasi Trustless seperti Fuel; (ii) Optimism dan Arbitrum, dua Rollup EVM penuh yang mengimplementasikan beberapa tonggak fase pertama tanpa kepercayaan pada saat artikel ini ditulis. Alasan Rollup belum mencapai kemajuan lebih lanjut adalah karena khawatir ada bug dalam kode. Kita membutuhkan Rollup tanpa kepercayaan, sehingga masalah ini harus dihadapi dan dipecahkan.

Apa itu, bagaimana cara kerjanya?

Pertama, mari kita tinjau sistem ‘stage’ yang diperkenalkan dalam teks ini.

Tahap 0: Pengguna harus dapat menjalankan Node dan menyinkronkan rantai. Jika verifikasi sepenuhnya dapat dipercaya / terpusat, itu juga tidak masalah.

Tahap 1: Harus ada sistem bukti (tanpa kepercayaan) yang memastikan hanya transaksi yang valid yang diterima. Sebuah komite keamanan yang dapat membatalkan sistem bukti diperbolehkan, tetapi harus ada ambang batas suara 75%. Selain itu, sebagian quorum-blocking (yaitu 26% +) dari komite harus berada di luar perusahaan induk yang membangun Rollup. Mekanisme upgrade yang lebih lemah (misalnya DAO) diperbolehkan, tetapi harus memiliki latensi yang cukup lama sehingga pengguna dapat menarik dana mereka sebelum dana tersebut diaktifkan jika ada upgrade berbahaya yang disetujui.

Tahap 2: Harus ada sistem bukti (tanpa kepercayaan) yang memastikan hanya transaksi yang valid yang akan diterima. Komite Keamanan hanya diizinkan untuk melakukan intervensi ketika ada kesalahan yang dapat dibuktikan dalam kode, misalnya. Jika dua sistem bukti yang redundan saling tidak konsisten, atau jika satu sistem bukti menerima dua akar post-state yang berbeda dari Blok yang sama (atau tidak menerima apa pun selama periode waktu yang cukup lama, misalnya seminggu). Peningkatan mekanisme diizinkan, tetapi harus memiliki latensi yang sangat lama.

Tujuan kami adalah mencapai Tahap 2. Tantangan utama dalam mencapai Tahap 2 adalah memperoleh kepercayaan yang cukup untuk membuktikan bahwa sistem benar-benar layak dipercaya. Ada dua metode utama yang dapat dilakukan untuk mencapai tujuan ini:

• Verifikasi Formal: Kita dapat menggunakan matematika modern dan teknologi komputasi untuk membuktikan (optimistik dan keabsahan) sistem bukti hanya menerima Blok yang sesuai dengan spesifikasi EVM. Teknologi ini telah ada selama beberapa dekade, tetapi kemajuan terbaru (seperti Lean 4) membuatnya lebih praktis, sementara kemajuan verifikasi yang dibantu AI mungkin akan lebih mempercepat tren ini.
• Multi-prover: Membuat beberapa sistem bukti dan memasukkan dana ke dalam sistem-sistem bukti ini bersama dengan komite keamanan (atau alat kecil lainnya dengan asumsi kepercayaan, seperti TEE). Jika sistem bukti setuju, komite keamanan tidak memiliki kekuasaan; jika mereka tidak setuju, komite keamanan hanya bisa memilih di antara mereka, dan tidak dapat memaksakan jawabannya sendiri.

Grafik program multipleksitas yang menggabungkan sistem bukti optimis, sistem bukti validitas, dan komite keamanan.

Apa saja tautan dengan penelitian yang ada?

• EVM K Semantik (pekerjaan verifikasi formal sejak 2017):
• Pidato tentang Konsep Multi-Proof (2022):
• Proyek Taiko akan menggunakan bukti ganda:

Masih perlu melakukan apa? Apa pertimbangannya?

Untuk Verifikasi Formal, pekerjaannya sangat besar. Kami perlu membuat versi verifikasi formal dari seluruh SNARK prover di EVM. Ini adalah proyek yang sangat kompleks meskipun kami telah mulai melakukannya. Ada trik untuk sangat mempermudah tugas ini: kami dapat membuat SNARK prover yang diformalisasikan untuk Virtual Machine yang sangat minimalis (misalnya RISC-V atau Cairo), dan kemudian mengimplementasikan EVM di dalam Virtual Machine yang minimalis tersebut (dan membuktikan secara formal kesetaraannya dengan spesifikasi ETH blockchain Virtual Machine yang lain).

Untuk multi-proof, masih ada dua bagian utama yang belum selesai. Pertama, kita perlu memiliki keyakinan yang cukup pada setidaknya dua sistem bukti yang berbeda, memastikan bahwa masing-masing aman dan jika terjadi masalah, maka masalah tersebut harus berbeda dan tidak terkait (sehingga mereka tidak akan menghadapi masalah secara bersamaan). Kedua, kita perlu memiliki tingkat kepercayaan yang sangat tinggi pada logika dasar sistem gabungan bukti. Kode bagian ini harus jauh lebih sedikit. Ada beberapa cara untuk membuatnya sangat kecil, hanya dengan menyimpan dana dalam kontrak multisig yang aman dengan kontrak yang mewakili setiap sistem bukti sebagai penandatangan, tetapi ini akan meningkatkan biaya Gas on-chain. Kami perlu menemukan keseimbangan antara efisiensi dan keamanan.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Menggeser aktivitas ke L2 bisa menurunkan tekanan MEV di L1.

Peningkatan Interoperabilitas L2

Apa masalah yang sedang kami selesaikan?

Tantangan utama yang dihadapi oleh ekosistem L2 saat ini adalah sulitnya pengguna menavigasi di dalamnya. Selain itu, metode paling mudah seringkali memperkenalkan asumsi kepercayaan kembali: seperti Interaksi Cross-Chain terpusat, klien RPC, dan lainnya. Kita perlu membuat pengalaman pengguna dalam menggunakan ekosistem L2 terasa seperti menggunakan ekosistem Ethereum yang terpadu.

Apa itu? Bagaimana cara kerjanya?

Ada beberapa jenis perbaikan interoperabilitas L2 lintas-jaringan. Secara teoritis, Ethereum berbasis Rollup dan Sharding L1 adalah hal yang sama. Namun, ekosistem L2 Ethereum saat ini masih memiliki beberapa kekurangan dibandingkan dengan keadaan ideal:

1、Alamat khusus dari chain: Alamat harus mencakup informasi chain (L1, Optimism, Arbitrum……). Setelah mencapai ini, proses pengiriman cross L2 dapat dicapai dengan mudah dengan memasukkan Alamat ke dalam bidang ‘kirim’, pada saat ini Dompet dapat mengurus sendiri bagaimana melakukan pengiriman (termasuk menggunakan protokol cross-chain Interaksi).

2. Permintaan pembayaran untuk rantai tertentu: Harus dapat dengan mudah dan standar membuat pesan yang berbentuk ‘Kirimkan X Y ke saya di rantai Z’. Ini memiliki dua aplikasi utama: (i) pembayaran antar orang atau pembayaran kepada layanan pedagang; (ii) Permintaan dana DApp.

3、Interaksi cross-chain exchange dan pembayaran gas: harus ada protokol terbuka standar untuk mengekspresikan operasi interaksi cross-chain, seperti ‘Saya akan mengirimkan 1 ether (di Optimism) kepada orang yang mengirimkan 0.9999 ether kepada saya di Arbitrum’, dan ‘Saya akan mengirimkan 0.0001 ether kepada orang yang melakukan transaksi ini di Arbitrum (di Optimism)’. ERC-7683 adalah upaya untuk yang pertama, sementara RIP-7755 adalah upaya untuk yang kedua, meskipun keduanya memiliki ruang lingkup aplikasi yang lebih luas daripada kasus penggunaan khusus ini.

4. light client: Pengguna harus dapat memverifikasi secara aktual rantai yang mereka interaksikan, bukan hanya bergantung pada penyedia RPC. Helios a16z crypto dapat mencapai ini (untuk ETH blockchain itu sendiri), tetapi kita perlu memperluas kepercayaan ini ke L2. ERC-3668 (CCIP-read) adalah strategi untuk mencapai tujuan ini.

Bagaimana light client memperbarui tampilan rangkaian header Ethereum-nya. Setelah memiliki rangkaian header, objek status apapun dapat diverifikasi menggunakan bukti Merkle. Setelah Anda memiliki objek status L1 yang benar, Anda dapat menggunakan bukti Merkle (jika Anda ingin memeriksa pra-konfirmasi, Anda juga dapat menggunakan tanda tangan) untuk memverifikasi objek status apa pun di L2. Helios telah mencapai yang pertama. Memperluas ke yang terakhir adalah tantangan standarisasi.

1、Keystore Dompet：Saat ini, jika Anda ingin memperbarui kontrol Kunci Rahasia Smart ContractDompet Anda, Anda harus memperbarui di semua rantai N di mana Dompet tersebut ada. Keystore Dompet adalah teknologi yang memungkinkan Kunci Rahasia hanya ada di satu tempat (entah di L1 atau mungkin di L2 di masa depan), dan kemudian semua L2 yang memiliki salinan Dompet dapat membaca Kunci Rahasia dari sana. Ini berarti pembaruan hanya perlu dilakukan sekali. Untuk efisiensi, Keystore Dompet membutuhkan L2 memiliki cara standar untuk membaca informasi dari L1 tanpa biaya; ada dua proposal untuk ini, yaitu L1S LOAD dan REMOTESTATICCALL.

Prinsip Kerja Dompet Keystore

2. Konsep ‘Jembatan Token Berbagi’ yang lebih agresif: Bayangkan di dunia di mana semua L2 adalah bukti validitas Rollup dan setiap slot mengirimkan komitmen ke jaringan Ether. Bahkan di dunia seperti itu, untuk mentransfer aset dari satu L2 ke L2 lainnya dalam keadaan asli masih memerlukan penarikan dan deposit, yang memerlukan pembayaran biaya gas L1 yang besar. Salah satu cara untuk mengatasi masalah ini adalah dengan membuat Rollup bersama yang sangat sederhana, yang satu-satunya fungsinya adalah memelihara kepemilikan dan saldo Token dari setiap jenis oleh L2 mana, dan memungkinkan saldo ini diperbarui secara massal melalui serangkaian operasi pengiriman lintas L2 yang dilakukan oleh semua L2. Ini akan memungkinkan transfer lintas L2 tanpa perlu membayar biaya gas L1 setiap kali, dan tanpa perlu menggunakan teknologi berbasis Likuiditas penyedia seperti ERC-7683.

3、Komposisi Sinkronisasi: Memungkinkan panggilan sinkronisasi terjadi antara L2 khusus dan L1 atau antara beberapa L2. Ini membantu meningkatkan efisiensi keuangan desentralisasi protokol. Yang pertama dapat dicapai tanpa koordinasi lintas L2 apa pun; yang terakhir memerlukan pembagian urutan. Teknologi berbasis Rollup secara otomatis berlaku untuk semua teknologi ini.

Apa saja tautan dengan penelitian yang ada?

Alamat khusus rantai：

ERC-3770 :

ERC-7683:

RIP-7755:

Desain tampilan Scroll keystore Dompet:

Helios:

ERC-3668 （kadang-kadang disebut sebagai CCIP baca）：

Usulan ‘dibangun pada (konfirmasi bersama) pra-konfirmasi’ yang diajukan oleh Justin Drake:

L1S LOAD (RIP-7728): load-precompile/20388

REMOTESTATICCALL dalam Optimism:

AggLayer, termasuk gagasan jembatan token bersama:

Masih perlu melakukan apa? Apa pertimbangannya?

Banyak contoh di atas menghadapi dilema standar kapan harus membakukan dan lapisan mana yang harus distandarisasi. Jika Anda membakukan terlalu dini, Anda dapat menghasilkan solusi yang buruk. Jika Anda terlambat membakukan, Anda dapat membuat fragmentasi yang tidak perlu. Dalam beberapa kasus, ada solusi jangka pendek dengan atribut lemah yang lebih mudah diterapkan, dan solusi jangka panjang yang “pada akhirnya benar” tetapi membutuhkan waktu bertahun-tahun untuk mencapainya.

Tugas-tugas ini bukan hanya masalah teknis, tetapi juga (bahkan mungkin terutama) masalah sosial, memerlukan kerja sama L2 dan Dompet serta L1.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Sebagian besar proposal dalam ini adalah struktur ‘lebih tinggi’, sehingga tidak terlalu mempengaruhi pertimbangan pada level L1. Satu pengecualian adalah urutan berbagi, yang memiliki dampak signifikan pada nilai ekstraksi maksimal (MEV).

Memperluas Eksekusi di L1

Apa masalah yang sedang kami selesaikan?

Jika L2 menjadi sangat scalable dan sukses, tetapi L1 masih hanya dapat menangani volume yang sangat sedikit, maka Ethereum mungkin akan menghadapi banyak risiko:

1. Keadaan ekonomi aset ETH akan menjadi lebih tidak stabil, yang pada gilirannya akan mempengaruhi keamanan jangka panjang jaringan.

2. Banyak L2 diuntungkan dari keterhubungan erat dengan ekosistem keuangan yang sangat berkembang di L1. Jika ekosistem ini melemah secara signifikan, insentif untuk menjadi L2 (daripada menjadi L1 yang independen) akan berkurang.

3. L2 akan membutuhkan waktu yang lama untuk mencapai tingkat keamanan yang sama dengan L1.

4. Jika L2 gagal (misalnya, karena perilaku jahat atau hilangnya operator), pengguna masih perlu memulihkan aset mereka melalui L1. Oleh karena itu, L1 perlu cukup kuat untuk secara sporadis menangani pekerjaan akhir yang sangat kompleks dan berantakan dari L2.

Dalam rangka alasan-alasan ini, memperluas L1 itu sendiri dan memastikan bahwa ia dapat terus menampung lebih banyak kasus penggunaan adalah sangat berharga.

Apa itu? Bagaimana cara kerjanya?

Cara perluasan paling sederhana adalah dengan langsung meningkatkan Batas Gas. Namun, hal ini mungkin akan membuat L1 cenderung terpusat, yang dapat melemahkan kepercayaan Ethereum L1 sebagai lapisan dasar yang andal dan kuat. Masih diperdebatkan sejauh mana peningkatan Batas Gas yang sederhana dapat berkelanjutan, dan ini juga akan berbeda tergantung pada teknologi lain yang diterapkan untuk membuat verifikasi Blok yang lebih besar menjadi lebih mudah (misalnya, kadaluwarsa historis, tanpa status, bukti validitas L1 EVM). Hal penting lain yang perlu terus ditingkatkan adalah efisiensi perangkat lunak klien Ethereum, yang saat ini jauh lebih efisien daripada lima tahun yang lalu. Strategi peningkatan Batas Gas L1 yang efektif akan melibatkan percepatan pengembangan teknologi verifikasi ini.

• EOF: Sebuah format bytecode EVM baru yang lebih ramah untuk analisis statis, dapat diimplementasikan dengan lebih cepat. Dengan mempertimbangkan peningkatan efisiensi ini, bytecode EOF dapat memperoleh biaya gas yang lebih rendah.
• Penilaian Harga Gas Multidimensi: Menetapkan biaya dan batasan dasar yang berbeda untuk komputasi, data, dan penyimpanan secara terpisah, dapat meningkatkan kapasitas rata-rata ETH L1 tanpa meningkatkan kapasitas maksimum (sehingga menghindari terjadinya risiko keamanan baru).
• Menurunkan biaya Gas untuk opcode khusus dan pra-kompilasi - Secara historis, untuk menghindari serangan penolakan layanan, kami telah beberapa kali meningkatkan biaya Gas untuk beberapa operasi yang terlalu murah. Sesuatu yang bisa dilakukan lebih lanjut adalah menurunkan biaya Gas untuk operasi dengan harga terlalu tinggi. Misalnya, penambahan jauh lebih murah daripada perkalian, namun saat ini biaya opcode ADD dan MUL sama. Kami bisa menurunkan biaya ADD, bahkan membuat biaya operasi yang lebih sederhana seperti PUSH lebih rendah. EOF secara keseluruhan lebih dioptimalkan dalam hal ini.
• EVM-MAX dan SIMD: EVM-MAX adalah proposal yang memungkinkan operasi matematika modulus besar asli yang lebih efisien sebagai modul mandiri EVM. Kecuali disengaja diekspos, nilai yang dihitung oleh EVM-MAX hanya dapat diakses oleh opcode EVM-MAX lain. Ini memungkinkan ruang yang lebih besar untuk mengoptimalkan penyimpanan nilai-nilai ini. SIMD (single instruction multiple data) adalah proposal yang memungkinkan eksekusi efisien instruksi yang sama terhadap array nilai. Keduanya bersama-sama dapat menciptakan koprocesor yang kuat di samping EVM, yang dapat digunakan untuk menerapkan operasi enkripsi lebih efisien. Ini sangat berguna untuk protokol enkripsi dan sistem perlindungan L2, dan akan membantu dalam perluasan L1 dan L2.

Peningkatan ini akan dibahas lebih detail dalam artikel Splurge di masa depan.

Terakhir, strategi ketiga adalah Rollups asli (atau rollups diabadikan): Pada dasarnya, menciptakan banyak salinan EVM yang berjalan secara paralel, menghasilkan model yang setara dengan yang Rollup dapat sediakan, tetapi lebih terintegrasi secara asli ke dalam protokol.

Apa saja tautan dengan penelitian yang ada?

• Rencana Jalan Pengembangan L1 Polynya untuk Ethereum (ETH)
• Harga Gas Multidimensi:
• EIP-7706:
• EOF:
• EVM-MAX:
• SIMD:
• Native rollups:
• Nilai Perluasan L1 dalam Wawancara Max Resnick:
• Justin Drake membahas penggunaan SNARK dan Rollups asli untuk skala yang lebih besar:

Apa yang perlu dilakukan, apa pertimbangannya?

Ada tiga strategi untuk penskalaan L1, yang dapat dilakukan secara individual atau paralel:

• Memperbaiki teknologi (seperti kode klien, klien berkeadaan tanpa status, dan masa kedaluwarsa historis) untuk membuat L1 lebih mudah diverifikasi, dan kemudian meningkatkan batas Gas.
• Menurunkan biaya operasi tertentu, meningkatkan rata-rata kapasitas tanpa meningkatkan risiko skenario terburuk;
• Rollups asli (yaitu, membuat N salinan paralel dari EVM).

Setelah memahami berbagai teknologi ini, kita akan menemukan bahwa masing-masing memiliki pertimbangan yang berbeda. Misalnya, Rollups asli memiliki banyak kelemahan yang sama dengan Rollups biasa dalam hal komposisi: Anda tidak dapat mengirim satu transaksi tunggal untuk melakukan operasi lintas Rollup seperti yang Anda lakukan dalam kontrak L1 (atau L2) yang sama. Meningkatkan batas Gas akan melemahkan manfaat lain yang dapat dicapai melalui verifikasi L1 yang disederhanakan, seperti meningkatkan proporsi pengguna Node verifikasi dan meningkatkan jumlah pemegang solo. Bergantung pada implementasinya, membuat operasi tertentu dalam EVM (Ether Virtual Machine) lebih murah dapat meningkatkan kompleksitas keseluruhan EVM.

Salah satu pertanyaan penting yang perlu dijawab oleh setiap roadmap skalabilitas L1 adalah: apa visi akhir dari L1 dan L2 masing-masing? Jelas, sangat tidak masuk akal untuk meletakkan semua konten di L1: potensi skenario aplikasi mungkin melibatkan ratusan ribu transaksi per detik, yang akan membuat L1 tidak dapat diverifikasi (kecuali jika kita menggunakan metode Rollup asli). Namun, kita memang membutuhkan beberapa prinsip panduan untuk memastikan kita tidak terjebak dalam situasi seperti ini: meningkatkan batas atas Gas 10 kali, yang akan merusak Desentralisasi Ethereum L1 yang parah.

Pandangan tentang pembagian kerja antara L1 dan L2

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Membawa lebih banyak pengguna ke L1 tidak hanya berarti meningkatkan skala, tetapi juga berarti meningkatkan aspek lain dari L1. Ini berarti lebih banyak MEV akan tetap di L1 (bukan hanya masalah L2), sehingga kebutuhan untuk menangani MEV dengan jelas akan menjadi lebih mendesak. Ini akan sangat meningkatkan nilai waktu slot yang cepat di L1. Pada saat yang sama, ini juga sangat bergantung pada kelancaran verifikasi L1 (the Verge).