Artikel terbaru dari Vitalik: Kemungkinan Masa Depan Ethereum, The Surge

Penulis: Vitalik Buterin

Disusun oleh Karen, Foresight News

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

Pada awalnya, dalam peta jalan Ethereum (ETH) terdapat dua strategi penskalaan. Salah satunya (lihat makalah awal tahun 2015) adalah ‘Sharding’: setiap Node hanya perlu memverifikasi dan menyimpan sebagian kecil transaksi, bukan semua transaksi dalam rantai. Jaringan peer-to-peer lainnya (seperti BitTorrent) juga bekerja seperti ini, jadi tentu saja kita dapat membuat blockchain berfungsi dengan cara yang sama. Yang lainnya adalah protokol Layer2: jaringan ini akan berada di atas ETH, memungkinkannya untuk sepenuhnya memanfaatkan keamanannya, sambil menjaga sebagian besar data dan komputasi di luar mainchain. Protokol Layer2 merujuk pada saluran state tahun 2015, Plasma tahun 2017, dan kemudian Rollup tahun 2019. Rollup lebih kuat daripada saluran state atau Plasma, tetapi memerlukan bandwidth data on-chain yang besar. Untungnya, pada tahun 2019, penelitian Sharding telah menyelesaikan masalah ‘ketersediaan data’ yang diverifikasi secara besar-besaran. Akibatnya, kedua jalur bergabung, dan kami mendapatkan peta jalan yang berpusat pada Rollup, yang masih menjadi strategi perluasan ETH pada hari ini.

The Surge, versi peta jalan 2023

Roadmap yang berpusat pada Rollup mengusulkan pembagian tugas yang sederhana: Ethereum (ETH) L1 fokus pada menjadi lapisan dasar yang kuat dan desentralisasi, sementara L2 bertanggung jawab dalam membantu ekosistem berkembang. Pola ini hadir di mana-mana dalam masyarakat: keberadaan sistem pengadilan (L1) bukanlah untuk mengejar kecepatan dan efisiensi yang sangat tinggi, melainkan untuk melindungi kontrak dan hak atas properti, sedangkan pengusaha (L2) harus membangun di atas lapisan dasar yang kuat ini dan memimpin manusia menuju Mars (baik secara harfiah maupun secara metaforis).

Tahun ini, roadmap yang berpusat pada Rollup telah mencapai hasil yang signifikan: dengan diluncurkannya blob EIP-4844, bandwidth data ETH L1 meningkat secara signifikan, beberapa Rollup EVM ETH lainnya telah memasuki tahap pertama. Setiap L2 ada sebagai ‘Sharding’ dengan aturan dan logika internalnya sendiri, keberagaman dan keragaman implementasi Sharding sekarang menjadi kenyataan. Namun seperti yang kita lihat, ada beberapa tantangan unik dalam mengikuti jalur ini. Oleh karena itu, tugas kita sekarang adalah menyelesaikan roadmap yang berpusat pada Rollup dan menyelesaikan masalah ini, sambil tetap mempertahankan kestabilan dan desentralisasi yang khas dari ETH L1.

The Surge: Target Utama

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

2. Menjaga Desentralisasi dan ketangguhan L1;

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

4, Ethereum seharusnya terasa seperti sebuah ekosistem yang terintegrasi, bukan 34 blockchain yang berbeda.

Isi Bab Ini

1. Trilema Skalabilitas
2. Kemajuan lebih lanjut dalam sampel ketersediaan data
3. Kompresi Data
4. Plasma Umum
5. Sistem Bukti L2 yang Matang
6. Peningkatan Interoperabilitas L2 Cross
7. Eksekusi Ekspansi pada L1

Paradox Segitiga Skalabilitas

Trilema skalabilitas adalah gagasan yang diajukan pada tahun 2017 yang berpendapat bahwa ada kontradiksi antara tiga karakteristik blockchain: Desentralisasi (lebih spesifiknya: biaya rendah untuk menjalankan Node), skalabilitas (mampu menghandle banyak transaksi), dan keamanan (penyerang perlu merusak sebagian besar Node dalam jaringan untuk membuat satu transaksi gagal).

Perlu diperhatikan bahwa paradoks segitiga bukanlah sebuah teorema, dan posting yang memperkenalkan paradoks segitiga tidak dilengkapi dengan bukti matematika. Ia benar-benar memberikan argumen matematika 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 sejumlah kecil Node untuk berhasil melakukan transaksi jahat, atau (ii) Node Anda akan menjadi kuat, sementara rantai Anda tidak akan Desentralisasi. Tujuan artikel ini bukanlah untuk membuktikan bahwa memecahkan paradoks segitiga tidak mungkin; sebaliknya, tujuannya adalah untuk menunjukkan bahwa memecahkan paradoks segitiga sulit, dan memerlukan keluar dari kerangka berpikir yang tersirat dalam argumen tersebut.

Selama bertahun-tahun, beberapa rantai kinerja tinggi sering mengklaim bahwa mereka telah memecahkan paradoks tiga elemen tanpa mengubah arsitektur secara mendasar, biasanya dengan mengoptimalkan Node melalui teknik rekayasa perangkat lunak. Ini selalu menyesatkan, karena menjalankan Node di atas rantai ini jauh lebih sulit daripada menjalankannya di atas Ethereum. Artikel ini akan membahas mengapa hal ini terjadi dan mengapa hanya dengan perangkat lunak klien L1 itu sendiri, Ethereum tidak dapat diperluas.

Namun, kombinasi sampel ketersediaan data dengan SNARKs memang mengatasi paradoks segitiga: ini memungkinkan klien untuk memverifikasi bahwa sejumlah data tersedia dan sejumlah langkah perhitungan dilakukan dengan benar hanya dengan mengunduh sedikit data dan melakukan sedikit perhitungan. SNARKs adalah tanpa kepercayaan. Sampel ketersediaan data memiliki model kepercayaan sedikit-dari-N yang halus, tetapi tetap mempertahankan fitur dasar dari rantai yang tidak dapat diperluas, yaitu bahkan serangan 51% tidak dapat memaksa blok yang buruk diterima oleh jaringan.

Salah satu cara lain untuk mengatasi kesulitan tiga adalah dengan menggunakan arsitektur Plasma, yang menggunakan teknologi yang cerdik untuk mendorong tanggung jawab ketersediaan data pemantauan ke pengguna secara kompatibel. Pada tahun 2017-2019, saat satu-satunya cara untuk memperluas kemampuan komputasi adalah dengan bukti penipuan, Plasma sangat terbatas dalam pelaksanaan keamanan, tetapi dengan penyebaran SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge), arsitektur Plasma menjadi lebih layak untuk digunakan dalam berbagai skenario dibanding sebelumnya.

Kemajuan Lebih Lanjut dalam Sampel Ketersediaan Data

Apa masalah yang sedang kami selesaikan?

Pada 13 Maret 2024, ketika Dencun upgrade diluncurkan, slot blockchain blok ETH memiliki sekitar 3 blob sebesar 125 kB setiap 12 detik, atau bandwidth data sekitar 375 kB per slot. Dengan asumsi data transaksi langsung dipublikasikan on-chain, transfer ERC20 sekitar 180 byte, sehingga maksimum TPS Rollup di ETH blok adalah: 375.000 / 12 / 180 = 173,6 TPS

Jika kita menambahkan calldata persegi ETH (maksimum teoretis: 30 juta gas per slot / 16 gas per byte = 1.875.000 byte per slot), ini menjadi 607 TPS. Dengan PeerDAS, jumlah blob mungkin meningkat menjadi 8-16, yang akan menyediakan 463-926 TPS untuk calldata.

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

Apa itu? Bagaimana cara kerjanya?

PeerDAS adalah implementasi yang relatif sederhana dari ‘1D sampling’. Di dalam Ethereum, setiap blob adalah polinomial 4096 kali di atas medan prima 253-bit. Kami menyiar shares dari polinomial, di mana setiap shares berisi 16 nilai evaluasi dari 16 koordinat yang berdekatan di antara total 8192 koordinat. Dari 8192 nilai evaluasi ini, setiap 4096 (berdasarkan parameter yang diajukan saat ini: 64 dari 128 sampel yang mungkin) dapat memulihkan blob.

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

Secara teori, kita dapat memperluas skala “1D sampling” hingga sangat besar: jika kita meningkatkan jumlah blob maksimum menjadi 256 (dengan target 128), maka kita dapat mencapai target 16MB, sementara ketersediaan data sampling menggunakan 16 sampel setiap Node * 128 blob * setiap blob setiap sampel 512 byte = bandwidth data 1 MB per slot. Ini hanya masuk akal dalam toleransi kami: ini memungkinkan, tetapi itu berarti klien dengan bandwidth terbatas tidak dapat melakukan sampling. Kita dapat memperbaikinya dengan cara mengurangi jumlah blob dan meningkatkan ukuran blob, tetapi ini akan meningkatkan biaya rebuild.

Oleh karena itu, akhirnya kami ingin melangkah lebih jauh dengan melakukan sampel 2D (2D sampling), di mana metode ini tidak hanya melakukan sampel acak di dalam blob, tetapi juga di antara blob. Dengan memanfaatkan sifat linear dari komitmen KZG, kami memperluas kumpulan blob dalam Blok dengan seperangkat blob virtual baru yang secara redundan mengkodekan informasi yang sama.

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

2D sampling. Sumber data: a16z crypto

Hal yang sangat penting, ekstensi komitmen komputasi tidak memerlukan blob, 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 (1D DAS) juga pada dasarnya ramah terhadap konstruksi blok terdistribusi.

Apa hubungan antara penelitian yang ada?

1. Kiriman Asli yang Memperkenalkan Ketersediaan Data (2018):
2. Kertas tindak lanjut:
3. Artikel penjelasan tentang DAS, paradigma:
4. Ketersediaan 2D dengan komitmen KZG:
5. PeerDAS di ethresear.ch: dan makalah:
6. EIP-7594:
7. SubnetDAS di ethresear.ch:
8. 2D sampling memiliki perbedaan halus yang dapat dipulihkan:

**Apa yang perlu dilakukan? Apa pertimbangannya?

Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, terus meningkatkan jumlah blob di PeerDAS sambil memantau jaringan dengan cermat dan memperbaiki 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.

Lebih jauh ke depan, kita perlu melakukan lebih banyak pekerjaan untuk menentukan versi ideal DAS 2D dan membuktikan sifat keamanannya. Kami juga berharap untuk akhirnya beralih dari KZG ke alternatif kuantum-aman yang tidak memerlukan pengaturan tepercaya. Saat ini, kami tidak tahu kandidat mana yang ramah dengan bangunan blok yang didistribusikan. Bahkan penggunaan teknik “brute force” yang mahal, yaitu, penggunaan STARK rekursif untuk menghasilkan bukti validitas untuk merekonstruksi baris dan kolom, tidak cukup, karena sementara STARK secara teknis adalah O(log(n) * log(log(n)) hash (menggunakan STIR), pada kenyataannya STARK hampir sebesar seluruh gumpalan.

Saya percaya jalur realitas jangka panjang adalah:

1. Menerapkan 2D DAS yang ideal;
2. Mempertahankan penggunaan 1D DAS, mengorbankan efisiensi bandwidth sampling, menerima batas data yang lebih rendah untuk kesederhanaan dan kekokohan.
3. Menyerahkan DA, sepenuhnya menerima Plasma sebagai arsitektur Layer2 utama yang kami ikuti.

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

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Jika kompresi data diimplementasikan, permintaan untuk 2D DAS akan berkurang, atau setidaknya akan latensi, jika Plasma digunakan secara luas, permintaan akan semakin berkurang. DAS juga menantang konstruksi protokol dan mekanisme Blok terdistribusi: meskipun secara teoritis DAS ramah rekonstruksi terdistribusi, namun dalam praktiknya perlu dikombinasikan dengan proposal daftar inklusi paket dan mekanisme pemilihan fork di sekitarnya.

Kompresi Data

Apa masalah yang sedang kita selesaikan?

Setiap transaksi dalam Rollup akan mengambil ruang data on-chain yang besar: transfer ERC20 membutuhkan sekitar 180 byte. Bahkan dengan pengambilan sampel ketersediaan data yang ideal, ini juga membatasi skalabilitas Layer protokol. Dengan setiap slot sebesar 16 MB, kita mendapatkan:

16000000 / 12 / 180 = 7407 TPS

Jika kita tidak hanya dapat memecahkan masalah pembilang, tetapi juga dapat memecahkan masalah penyebut, sehingga setiap transaksi dalam Rollup mengambil lebih sedikit byte di on-chain, apa yang akan terjadi?

Apa itu, bagaimana cara kerjanya?

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

Dalam kompresi nol byte, setiap urutan nol byte panjang diganti dengan dua byte untuk menunjukkan berapa banyak nol byte yang ada. Lebih lanjut, kami menggunakan properti khusus dari transaksi:

Agregasi Tanda Tangan: Kami beralih dari tanda tangan ECDSA ke tanda tangan BLS, yang memiliki fitur bahwa beberapa tanda tangan dapat digabungkan menjadi satu tanda tangan tunggal yang dapat membuktikan validitas semua tanda tangan asli. Pada tingkat L1, karena biaya komputasi verifikasi yang tinggi bahkan setelah agregasi, penggunaan tanda tangan BLS tidak dipertimbangkan. Namun, dalam lingkungan L2 yang jarang data, penggunaan tanda tangan BLS memiliki arti. Fitur agregasi ERC-4337 memberikan jalan untuk mengimplementasikan fungsi ini.

Ganti Alamat dengan pointer: Jika kita pernah menggunakan Alamat sebelumnya, kita dapat mengganti Alamat 20-byte dengan pointer 4-byte yang menunjuk ke lokasi dalam riwayat.

Serialisasi kustom dari nilai transaksi - Sebagian besar nilai transaksi memiliki jumlah digit yang sedikit, misalnya, 0.25 ETH diwakili sebagai 250,000,000,000,000,000 wei. Biaya dasar maksimum dan biaya prioritas juga serupa. Oleh karena itu, kita dapat menggunakan format desimal floating point kustom untuk mewakili sebagian besar nilai mata uang.

Apa hubungan antara penelitian yang ada?

1. Jelajahi sequence.xyz:
2. Optimalisasi Kontrak Calldata L2:
3. Rollups berbasis bukti validitas (juga dikenal sebagai ZK rollups) membedakan status pengiriman bukan transaksi:
4. Dompet BLS - Implementasi agregat BLS melalui ERC-4337:

Apa yang masih perlu dilakukan dan pertimbangan apa yang ada?

Selanjutnya, yang utama adalah untuk benar-benar menerapkan rencana di atas. Pertimbangan utama meliputi:

1. Beralih ke tanda tangan BLS membutuhkan usaha yang besar dan dapat menurunkan kompatibilitas dengan chip keras tepercaya yang dapat meningkatkan keamanan. ZK-SNARK bungkus yang menggunakan skema tanda tangan lain dapat digunakan sebagai pengganti.

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

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

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Mengadopsi ERC-4337 dan pada akhirnya akan memasukkan sebagian isinya ke dalam L2 EVM, dapat sangat mempercepat implementasi teknologi agregasi. Menempatkan sebagian isi 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 area berkecepatan tinggi lainnya, terutama ketika kita mulai mempertimbangkan faktor privasi, ini bisa membuat volume Drop 3-8 kali lipat. Untuk skenario aplikasi tinggi volume, rendah nilai, saat ini salah satu pilihan 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 sementara atau secara permanen membekukan semua dana pengguna. Tapi kita bisa melakukan lebih baik.

Apa itu dan bagaimana cara kerjanya?

Plasma adalah solusi scaling yang melibatkan operator untuk menerbitkan Blok ke off-chain dan menempatkan Merkle root dari Blok-blok tersebut di on-chain (berbeda dengan Rollup yang menempatkan Blok-blok lengkap di on-chain). Untuk setiap Blok, operator akan mengirimkan cabang Merkle ke setiap pengguna untuk membuktikan perubahan aset pengguna atau tidak ada perubahan sama sekali. Pengguna dapat menarik aset mereka dengan memberikan cabang Merkle. Penting untuk dicatat bahwa cabang tersebut tidak perlu berdasarkan root status terbaru. Oleh karena itu, bahkan jika ketersediaan data bermasalah, pengguna masih dapat memulihkan aset mereka dengan menarik status terbaru yang tersedia. Jika pengguna mengirimkan cabang yang tidak valid (misalnya, menarik aset yang telah mereka kirimkan ke orang lain, atau operator menciptakan aset palsu), vesting aset dapat ditentukan 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 secara efektif. Namun, jika kita meminta setiap root untuk diverifikasi menggunakan SNARK, maka Plasma akan menjadi jauh lebih kuat. Setiap permainan tantangan dapat disederhanakan secara signifikan karena kita menghilangkan sebagian besar kemungkinan kecurangan operator. Pada saat yang sama, juga membuka jalan baru untuk memperluas Plasma ke kategori aset yang lebih luas. Akhirnya, dalam situasi di mana operator tidak melakukan kecurangan, pengguna dapat segera menarik dana tanpa harus menunggu periode tantangan selama seminggu.

Metode pembuatan 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 pemetaan unik ‘Token yang sama’ pada waktu yang berbeda dalam sejarah. Kemudian Plasma dapat dibangun di atasnya.

Sebuah wawasan kunci adalah bahwa sistem Plasma tidak perlu sempurna. Bahkan jika Anda hanya dapat melindungi subset aset (misalnya, Token yang tidak bergerak hanya dalam seminggu terakhir), Anda telah secara signifikan meningkatkan kondisi saat ini dari EVM yang sangat scalable (yaitu Validium).

Jenis struktur lainnya adalah Plasma/Rollup hybrid, seperti Intmax. Konstruksi ini menempatkan sejumlah kecil data dari setiap pengguna di on-chain (misalnya, 5 byte), yang memungkinkan beberapa fitur di antara Plasma dan Rollup: Dalam kasus Intmax, Anda dapat mencapai skalabilitas dan privasi yang sangat tinggi, meskipun secara teori terbatas pada sekitar 266.667 TPS di dalam kapasitas 16 MB.

Apa saja tautan yang terkait dengan penelitian yang ada?

1. Kertas Asli Plasma:
2. Plasma Cash:
3. Aliran Kas Plasma Cashflow:
4. Intmax (2023):

Apa yang masih perlu dilakukan? Apa saja pertimbangannya?

Tugas utama yang tersisa adalah menerapkan sistem Plasma ke aplikasi produksi nyata. Seperti yang disebutkan sebelumnya, Plasma dan Validium bukanlah pilihan yang harus dipilih: setiap Validium dapat meningkatkan keamanannya setidaknya dalam beberapa hal dengan menyatukan fitur Plasma ke dalam mekanisme keluarnya. Penelitian difokuskan pada mendapatkan sifat terbaik untuk EVM (dari kebutuhan kepercayaan, biaya Gas L1 terburuk, hingga kemampuan untuk melawan serangan DoS), serta struktur aplikasi alternatif. Selain itu, Plasma memiliki kompleksitas konseptual yang lebih tinggi daripada Rollup, yang memerlukan penelitian dan pengembangan kerangka kerja umum yang lebih baik untuk menyelesaikannya secara langsung.

Salah satu pertimbangan utama dalam menggunakan desain Plasma adalah lebih bergantung pada operator dan lebih sulit didasarkan, meskipun desain Plasma/Rollup campuran 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 berkinerja 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 mengesampingkan perilaku sistem pembuktian (optimistic atau validity). Dalam beberapa kasus, sistem pembuktian bahkan tidak berjalan sama sekali, atau jika berjalan, hanya memiliki fungsi ‘konsultasi’. Rollup yang paling canggih termasuk: (i) beberapa aplikasi khusus Rollup yang Trustless, seperti Fuel; (ii) Optimism dan Arbitrum, yang pada saat penulisan artikel ini, adalah dua implementasi dari fase pertama dari Rollup EVM yang sebagian Trustless. Alasan Rollup belum mencapai kemajuan yang lebih besar adalah karena kekhawatiran akan adanya bug dalam kode. Kita membutuhkan Rollup yang Trustless, sehingga masalah ini harus dihadapi dan dipecahkan.

Apa itu dan bagaimana cara kerjanya?

Pertama, mari kita ulas kembali sistem ‘stage’ yang diperkenalkan di awal artikel ini.

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

Tahap 1: Harus ada sistem bukti (tanpa kepercayaan) yang memastikan hanya transaksi yang valid yang akan diterima. Memungkinkan adanya komite keamanan yang dapat membatalkan sistem bukti, tetapi harus ada ambang batas suara 75%. Selain itu, bagian quorum-blocking (yaitu 26%+) dari komite harus berada di luar perusahaan utama yang membangun Rollup. Memungkinkan penggunaan mekanisme upgrade yang lebih lemah (misalnya DAO), tetapi harus memiliki latensi yang cukup lama, sehingga jika ada upgrade jahat yang disetujui, pengguna dapat menarik dana mereka sebelum dana tersebut masuk ke dalam sistem.

Tahap 2: Harus ada sistem bukti (yang tidak perlu dipercayai) untuk memastikan bahwa hanya transaksi yang valid yang akan diterima. Dewan Keamanan hanya mengizinkan intervensi ketika kesalahan yang dapat dibuktikan ada dalam kode, misalnya jika dua sistem bukti yang redundan saling bertentangan, atau jika satu sistem bukti menerima dua post-state root Blok yang berbeda (atau tidak menerima apa pun untuk jangka waktu yang cukup lama, misalnya seminggu). Pembaruan mekanisme diizinkan, tetapi harus memiliki latensi yang sangat panjang.

Tujuan kami adalah mencapai Tahap 2. Tantangan utama dalam mencapai Tahap 2 adalah mendapatkan cukup kepercayaan diri dan membuktikan bahwa sistem ini benar-benar dapat dipercaya. Ada dua metode utama untuk melakukannya:

1. Verifikasi Formal: Kami dapat menggunakan matematika modern dan teknologi komputasi untuk membuktikan (optimis dan validitas) bahwa sistem verifikasi 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 dalam verifikasi yang dibantu AI mungkin dapat lebih mempercepat tren ini.
2. Multi-provers: Membuat beberapa sistem bukti dan menginvestasikan dana ke dalam sistem-sistem bukti ini bersama dengan komite keamanan (atau alat kecil lain yang memiliki asumsi kepercayaan, seperti TEE). Jika sistem-sistem bukti setuju, komite keamanan tidak memiliki wewenang; jika mereka tidak setuju, komite keamanan hanya bisa memilih di antara mereka, dan tidak bisa memaksakan jawabannya sendiri.

Grafik multi-pemilik yang terprogram menggabungkan sistem bukti optimis, sistem bukti validitas, dan komite keamanan.

Apa hubungan antara penelitian yang ada?

1. Semantik EVM K (pekerjaan verifikasi formal dari tahun 2017):
2. Tentang Pidato Konsep Bukti Ganda (2022):
3. Proyek Taiko akan menggunakan bukti ganda:

Apa yang masih perlu dilakukan? Apa saja pertimbangannya?

Bagi Verifikasi Formal, kerjanya sangat besar. Kami perlu membuat versi verifikasi formal penuh SNARK prover EVM. Ini adalah proyek yang sangat kompleks meskipun kami sudah mulai melakukannya. Ada trik yang dapat sangat menyederhanakan tugas ini: kami dapat membuat SNARK prover yang diformalkan untuk Virtual Machine yang minimal (misalnya RISC-V atau Cairo), kemudian mengimplementasikan EVM di dalam Virtual Machine minimal tersebut (dan membuktikan secara formal kesetaraannya dengan spesifikasi Ethereum Virtual Machine yang lain).

Bagi proyek multi-proof, masih ada dua bagian utama yang belum selesai. Pertama, kita perlu memiliki kepercayaan yang cukup pada setidaknya dua sistem bukti yang berbeda, untuk memastikan keamanan masing-masing dan memastikan bahwa jika ada masalah, masalah tersebut tidak terkait (sehingga tidak muncul bersamaan). Kedua, kita perlu memiliki tingkat kepercayaan yang sangat tinggi pada logika dasar dari sistem bukti gabungan. Kode bagian ini harus jauh lebih sedikit. Ada beberapa cara untuk membuatnya sangat kecil, cukup dengan menyimpan dana dalam kontrak multi-tanda tangan aman yang memiliki penandatangan yang mewakili setiap sistem bukti, namun ini akan meningkatkan biaya Gas on-chain. Kita perlu menemukan keseimbangan antara efisiensi dan keamanan.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Memindahkan aktivitas ke L2 dapat mengurangi tekanan MEV pada L1.

Peningkatan Interoperabilitas L2 Cross

Apa masalah yang sedang kami selesaikan?

Salah satu tantangan utama yang dihadapi oleh ekosistem L2 saat ini adalah sulitnya pengguna untuk menavigasinya. Selain itu, cara yang paling sederhana sering kali memperkenalkan asumsi kepercayaan kembali: pusat Interaksi Cross-Chain terpusat, klien RPC, dan sebagainya. Kita perlu membuat pengalaman menggunakan ekosistem L2 terasa seperti menggunakan ekosistem Ethereum yang terintegrasi dengan baik.

Apa itu? Bagaimana cara kerjanya?

Peningkatan interoperabilitas L2 lintas berbagai jenis. Secara teoritis, Ethereum berbasis Rollup dan pelaksanaan Sharding L1 adalah hal yang sama. Ekosistem L2 Ethereum saat ini masih memiliki beberapa kekurangan dalam praktiknya dari keadaan ideal:

1、Alamat khusus L1, Optimism, Arbitrum, dll.：Alamat harus mencakup informasi tentang rantai (L1、Optimism、Arbitrum……). Begitu ini tercapai, proses pengiriman lintas L2 dapat dilakukan dengan mudah dengan memasukkan Alamat ke dalam kolom ‘Kirim’, dan Dompet dapat mengatur secara otomatis bagaimana pengiriman dilakukan di latar belakang (termasuk menggunakan protokol cross-chain Interaksi).

2. Permintaan pembayaran untuk rantai tertentu: Harus dapat dengan mudah dan standar membuat pesan dalam format ‘Kirimkan X token jenis Y ke saya di rantai Z’. Ini memiliki dua aplikasi utama: (i) Pembayaran antar individu atau antara individu dan layanan pedagang; (ii) Permintaan dana dari DApp.

3、Interaksi cross-chain exchange dan pembayaran gas: Harus ada protokol terbuka yang terstandarisasi untuk mengekspresikan interaksi operasi cross-chain, seperti ‘Saya akan mengirimkan 1 ether kepada orang yang mengirimkan 0.9999 ether kepada saya di Arbitrum (di Optimism)’, 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 kedua aplikasi ini lebih luas daripada kasus penggunaan khusus ini.

4. light client: Pengguna harus dapat memverifikasi secara nyata rantai yang mereka interaksinya, bukan hanya bergantung pada penyedia RPC. Helios dari a16z crypto dapat mencapai hal ini (untuk ETH blockchain itu sendiri), tetapi kita perlu memperluasnya ke L2 agar bisa dipercaya. ERC-3668 (CCIP-read) adalah strategi untuk mencapai tujuan ini.

Bagaimana light client memperbarui tampilan rantai header Ethereum. Setelah memiliki rantai header, Anda dapat menggunakan bukti Merkle untuk memverifikasi setiap objek status. Begitu 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 setiap objek status di L2. Helios sudah melakukannya untuk yang pertama. Memperluas ke yang terakhir adalah tantangan standarisasi.

1、Keystore Dompet：Sekarang, jika Anda ingin memperbarui Kunci RahasiaDompet Smart Contract Anda, Anda harus memperbarui di semua N rantai di mana Dompet 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 setiap L2 yang memiliki salinan Dompet dapat membaca Kunci Rahasia dari sana. Ini berarti pembaruan hanya perlu dilakukan sekali. Untuk meningkatkan efisiensi, Keystore Dompet mengharuskan L2 memiliki cara yang terstandarisasi untuk membaca informasi dari L1 tanpa biaya; ada dua proposal untuk ini, yaitu L1SLOAD dan REMOTESTATICCALL.

Prinsip Kerja Keystore Dompet

2、Konsep ‘jembatan Token bersama’ yang lebih agresif: Bayangkan di dunia di mana semua L2 adalah bukti validitas Rollup dan setiap slot mengirimkan ke Ethereum. Meskipun demikian, untuk mentransfer aset dari satu L2 ke L2 lain dalam keadaan asli, masih diperlukan 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 token dari setiap jenis yang dimiliki oleh L2 tertentu dan jumlah saldo masing-masing, dan memungkinkan saldo ini diperbarui secara massal melalui serangkaian operasi pengiriman lintas L2 yang diluncurkan dari L2 mana pun. Ini akan memungkinkan transfer lintas L2 tanpa perlu membayar biaya gas L1 setiap kali mentransfer, dan tanpa perlu menggunakan teknologi berbasis Likuiditas seperti ERC-7683.

3. Kombinasi Sinkron: Memungkinkan pemanggilan sinkronisasi antara L2 dan L1 tertentu atau antara beberapa L2. Ini membantu meningkatkan efisiensi keuangan protokol Desentralisasi. Yang pertama dapat dicapai tanpa koordinasi lintas L2 apa pun; yang terakhir memerlukan berbagi urutan. Teknologi berbasis Rollup secara otomatis berlaku untuk semua teknologi ini.

Apa hubungan antara penelitian yang ada?

**Alamat Khusus Rantai: ERC-3770:

**ERC-7683:

**RIP-7755:

**Scroll keystore Dompet设计式样：

**Helios:

**ERC-3668 (kadang-kadang disebut pembacaan CCIP):

Proposal ‘Pre-Committed (Shared) Based’ oleh Justin Drake:

**L1SLOAD (RIP-7728):

**REMOTESTATICCALL di Optimism:

**AggLayer, termasuk dalamnya adalah gagasan jembatan token berbagi:

Apa yang masih perlu dilakukan? Apa saja pertimbangannya?

Banyak contoh di atas menghadapi dilema standarisasi kapan dan standarisasi lapisan mana. Jika standarisasi dilakukan terlalu dini, dapat menyebabkan solusi yang lebih buruk menjadi permanen. Jika standarisasi terlambat, dapat menyebabkan fragmentasi yang tidak perlu. Dalam beberapa kasus, ada solusi jangka pendek dengan atribut yang lebih lemah namun lebih mudah diimplementasikan, serta solusi jangka panjang yang ‘benar akhir’ namun membutuhkan waktu bertahun-tahun untuk diwujudkan.

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

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Sebagian besar proposal ini adalah struktur ‘tingkat lebih tinggi’, sehingga tidak terlalu mempengaruhi pertimbangan pada tingkat L1. Salah satu pengecualian adalah urutan bersama, yang memiliki dampak signifikan pada maximal extractable value (MEV).

Memperluas Eksekusi di L1

Apa masalah yang sedang kami selesaikan?

Jika L2 menjadi sangat scalable dan sukses, tetapi L1 masih hanya bisa menangani volume yang sangat sedikit, maka Ethereum mungkin 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 mendapat manfaat dari keterhubungan yang erat dengan ekosistem keuangan yang sangat maju di L1. Jika ekosistem ini melemah secara signifikan, maka insentif untuk menjadi L2 (daripada menjadi L1 independen) akan berkurang.

3. Butuh waktu lama bagi L2 untuk mencapai keamanan yang persis sama dengan L1.

4、Jika L2 gagal (misalnya, karena perilaku jahat atau menghilangnya operator), pengguna masih perlu memulihkan aset mereka melalui L1. Oleh karena itu, L1 perlu cukup kuat, setidaknya kadang-kadang dapat menangani pekerjaan penutupan L2 yang sangat kompleks dan kacau secara praktis.

Dengan alasan ini, melanjutkan perluasan L1 itu sendiri dan memastikan bahwa itu dapat terus menampung lebih banyak kasus penggunaan sangat bernilai.

Apa itu? Bagaimana cara kerjanya?

Cara perluasan paling sederhana adalah dengan langsung meningkatkan batas Gas. Namun, ini mungkin membuat L1 cenderung terpusat, sehingga melemahkan salah satu fitur penting lainnya dari Ethereum L1 yang begitu kuat: kepercayaan sebagai lapisan dasar yang stabil. Masih terdapat kontroversi tentang sejauh mana peningkatan batas Gas yang sederhana dapat berkelanjutan, dan ini juga akan bervariasi tergantung pada penerapan teknologi lain untuk membuat validasi Blok yang lebih besar lebih mudah (misalnya, lewat masa lalu, tanpa status, bukti validitas EVM L1). 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 perkembangan teknologi validasi ini.

1. EOF: Sebuah format bytecode EVM baru, lebih ramah untuk analisis statis, dapat diimplementasikan dengan lebih cepat. Mengingat peningkatan efisiensi ini, bytecode EOF dapat memperoleh biaya gas yang lebih rendah.
2. Penetapan harga Gas multi-dimensi: menetapkan biaya dan batasan dasar yang berbeda untuk komputasi, data, dan penyimpanan, dapat meningkatkan kapasitas rata-rata ETH L1 tanpa meningkatkan kapasitas maksimum (sehingga menghindari terjadinya risiko keamanan baru).
3. Menurunkan opcode tertentu dan biaya Gas pra-kompilasi - Dalam sejarahnya, untuk menghindari serangan denial-of-service, kami telah beberapa kali meningkatkan biaya Gas untuk beberapa opcode yang dinilai terlalu rendah. Ada lebih banyak yang bisa dilakukan dengan menurunkan biaya opcode yang dinilai terlalu tinggi. Misalnya, operasi ADD jauh lebih murah daripada operasi MUL, tetapi saat ini biaya opcode ADD dan MUL sama. Kami dapat menurunkan biaya opcode ADD, bahkan membuat biaya opcode yang lebih sederhana seperti PUSH menjadi lebih rendah. EOF secara keseluruhan lebih dioptimalkan dalam hal ini.
4. EVM-MAX dan SIMD: EVM-MAX adalah proposal yang memungkinkan operasi matematika modulo bilangan besar asli yang lebih efisien sebagai modul independen dari EVM. Kecuali disengaja diekspor, nilai perhitungan EVM-MAX hanya dapat diakses oleh opcode EVM-MAX lainnya. Hal ini memungkinkan ruang yang lebih besar untuk mengoptimalkan penyimpanan format nilai-nilai ini. SIMD (single instruction multiple data) adalah proposal yang memungkinkan eksekusi efisien dari instruksi yang sama terhadap array nilai. Bersama-sama, keduanya dapat menciptakan coprocessor yang kuat di samping EVM, yang dapat digunakan untuk mengimplementasikan operasi enkripsi dengan lebih efisien. Hal ini sangat berguna untuk protokol privasi dan sistem perlindungan L2, sehingga akan membantu dalam perluasan L1 dan L2.

Perbaikan ini akan dibahas lebih detail dalam artikel Splurge di masa mendatang.

Terakhir, strategi ketiga adalah Rollups asli (atau rollups berhak istimewa): Pada dasarnya, menciptakan banyak salinan EVM yang berjalan paralel untuk menghasilkan model yang setara dengan yang dapat disediakan oleh Rollup, tetapi lebih terintegrasi dengan protokol yang asli.

Apa hubungan antara penelitian yang ada?

1. Polynya’s Ethereum L1 expansion roadmap:
2. Harga Gas multi-dimensi:
3. EIP-7706:
4. EOF:
5. EVM-MAX:
6. SIMD:
7. rollups asli:
8. Wawancara Max Resnick tentang nilai dari perluasan L1:
9. Justin Drake berbicara tentang penggunaan SNARK dan Rollups asli untuk skala.

Apa yang masih perlu dilakukan dan pertimbangan apa yang ada?

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

1. Memperbaiki teknologi (seperti kode klien, klien tanpa status, kadaluwarsa historis) untuk membuat L1 lebih mudah diverifikasi, lalu meningkatkan batasan gas.
2. Menurunkan biaya operasi khusus, meningkatkan kapasitas rata-rata tanpa meningkatkan risiko dalam situasi terburuk;
3. 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 sinkronisasi melintasi beberapa Rollup, seperti yang dapat Anda lakukan dalam kontrak di L1 (atau L2) yang sama. Meningkatkan batas Gas akan melemahkan manfaat lain yang dapat dicapai melalui verifikasi L1 yang disederhanakan, seperti meningkatkan proporsi pengguna yang menjalankan Node verifikasi dan meningkatkan jumlah penjamin solo. Bergantung pada cara implementasinya, membuat operasi tertentu dalam EVM (Ethereum Virtual Machine) menjadi lebih murah dapat meningkatkan kompleksitas keseluruhan EVM.

Satu pertanyaan penting yang perlu dijawab oleh setiap rencana skala L1 adalah: apa visi akhir dari L1 dan L2 masing-masing? Jelas, adalah absurd untuk menempatkan semua konten di L1: potensial kasus penggunaan mungkin melibatkan ratusan ribu transaksi per detik, yang akan membuat L1 tidak dapat diverifikasi (kecuali jika kita menggunakan Rollup asli). Tetapi kita membutuhkan beberapa panduan untuk memastikan kita tidak terjebak dalam situasi di mana batas gas meningkat 10 kali, yang merusak desentralisasi dari L1 Ethereum.

Sebuah pandangan tentang pembagian kerja antara L1 dan L2

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

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

Rekomendasi Membaca: “Vitalik New Article: Masa Depan Mungkin ETH, the Merge”