Pada awalnya, Ethereum memiliki dua strategi penskalaan dalam roadmap-nya. Salah satunya (misalnya lihat kertas ini Dari 2015) adalah "sharding": alih-alih memverifikasi dan menyimpan semua transaksi dalam rantai, setiap node hanya perlu memverifikasi dan menyimpan sebagian kecil dari transaksi. Ini adalah bagaimana jaringan peer-to-peer lainnya (mis. BitTorrent) juga berfungsi, jadi pasti kita bisa membuat blockchain bekerja dengan cara yang sama. Yang lainnya adalah protokol lapisan 2: jaringan yang akan duduk di atas Ethereum dengan cara yang memungkinkan mereka untuk sepenuhnya mendapatkan keuntungan dari keamanannya, sambil menjaga sebagian besar data dan perhitungan dari rantai utama. "Protokol Layer 2" berarti saluran negarapada tahun 2015, Plasmapada tahun 2017, dan kemudianrollupsPada tahun 2019, Rollups lebih kuat daripada saluran status atau Plasma, tetapi mereka memerlukan jumlah bandwidth data on-chain yang besar. Untungnya, pada tahun 2019 penelitian sharding telah menyelesaikan Masalah verifikasi "ketersediaan data" dalam skala besarSebagai hasilnya, kedua jalur tersebut berpotongan, dan kita mendapat rencana jalan lintasan rollupyang tetap menjadi strategi penskalaan Ethereum hari ini.

The Surge, edisi peta jalan 2023.

Peta jalan yang berpusat pada rollup mengusulkan pembagian kerja yang sederhana: Ethereum L1 berfokus untuk menjadi lapisan dasar yang tangguh dan terdesentralisasi, sementara L2 mengambil tugas untuk membantu ekosistem berkembang. Ini adalah pola yang berulang di mana-mana dalam masyarakat: sistem pengadilan (L1) tidak hadir untuk menjadi ultra-cepat dan efisien, tetapi hadir untuk melindungi kontrak dan hak milik, dan terserah para wirausahawan (L2) untuk membangun di atasnya.kokohbasislapisandan membawa umat manusia ke Mars (secara metaforis dan harfiah).

Tahun ini, peta jalan yang berpusat pada rollup telah melihat kesuksesan penting: lebar pita data Ethereum L1 telah meningkat secara signifikan denganblob EIP-4844, dan sekarang ada beberapa EVM rollups pada tahap 1. Sebuah sangat implementasi penggandaan dan pluralistik dari sharding, di mana setiap L2 bertindak sebagai "pecahan" dengan aturan dan logika internalnya sendiri, sekarang menjadi kenyataan. Tetapi seperti yang telah kita lihat, mengambil jalan ini memiliki beberapa tantangan unik tersendiri. Jadi sekarang tugas kita adalah menyelesaikan peta jalan rollup-centric, dan menyelesaikan masalah ini, sambil mempertahankan ketahanan dan desentralisasi yang membuat Ethereum L1 istimewa.

The Surge: tujuan kunci

• 100.000+ TPS pada L1+L2
• Pertahankan desentralisasi dan ketangguhan L1
• Setidaknya beberapa L2 sepenuhnya mewarisi properti inti Ethereum (tanpa kepercayaan, terbuka, tahan sensor)
• Interoperabilitas maksimum antara L2s. Ethereum seharusnya terasa seperti satu ekosistem, bukan 34 blockchain yang berbeda.

Dalam bab ini

• Selain itu: trilema skalabilitas
• Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data
• Kompresi data
• Plasma Umum
• Sistem bukti L2 yang matang
• Interoperabilitas Cross-L2 dan peningkatan UX
• Skala eksekusi di L1

Selain itu: trilema skalabilitas

Trilema skalabilitas adalah sebuah ide diperkenalkan pada tahun 2017, yang berpendapat bahwa ada ketegangan antara tiga properti dari blockchain: desentralisasi (lebih spesifik: biaya rendah untuk menjalankan node), skalabilitas (lebih spesifik: jumlah transaksi yang diproses tinggi), dan keamanan (lebih spesifik: seorang penyerang perlu merusak sebagian besar node dalam jaringan keseluruhan untuk membuat bahkan satu transaksi gagal).

Perlu dicatat, trilema bukanlah sebuah teorema, dan posting yang memperkenalkan trilema tidak disertai dengan bukti matematis. Namun, posting tersebut memberikan argumen matematis heuristik: jika sebuah node yang ramah terhadap desentralisasi (misalnya laptop konsumen) dapat memverifikasi N transaksi per detik, dan Anda memiliki sebuah rantai yang memproses k*N transaksi per detik, maka entah (i) setiap transaksi hanya terlihat oleh 1/k dari node, yang menyiratkan bahwa seorang penyerang hanya perlu merusak beberapa node untuk mendorong transaksi buruk, atau (ii) node Anda akan menjadi kuat dan rantai Anda tidak terdesentralisasi. Tujuan dari posting tersebut bukanlah untuk menunjukkan bahwa memecah trilema adalah tidak mungkin; sebaliknya, tujuannya adalah untuk menunjukkan bahwa memecah trilema sulit - itu memerlukan cara berpikir di luar kotak yang disiratkan oleh argumen tersebut.

Selama bertahun-tahun, sudah umum bagi beberapa rantai kinerja tinggi untuk mengklaim bahwa mereka memecahkan trilema tanpa melakukan hal cerdas pada tingkat arsitektur fundamental, biasanya dengan menggunakan trik rekayasa perangkat lunak untuk mengoptimalkan simpul. Ini selalu menyesatkan, dan menjalankan simpul dalam rantai-rantai tersebut selalu berakhir jauh lebih sulit daripada di Ethereum.Posting inimasuk ke beberapa subtleties mengapa hal ini terjadi (dan oleh karena itu, mengapa rekayasa perangkat lunak klien L1 sendiri tidak dapat meningkatkan Ethereum itu sendiri).

Namun, kombinasi pengambilan sampel ketersediaan data dan SNARK memecahkan trilema: hal ini memungkinkan klien untuk memverifikasi bahwa sejumlah data tersedia, dan sejumlah langkah komputasi dilakukan dengan benar, sambil hanya mengunduh sebagian kecil data itu dan menjalankan jumlah komputasi yang jauh lebih kecil. SNARK adalah tanpa kepercayaan. Pengambilan sampel ketersediaan data memiliki nuansamodel kepercayaan few-of-N, namun itu tetap mempertahankan sifat fundamental yang dimiliki oleh rantai yang tidak dapat diskalakan, yaitu bahwa bahkan serangan 51% pun tidak dapat memaksa blok buruk diterima oleh jaringan.

Salah satu cara untuk menyelesaikan trilema adalah arsitektur Plasma, yang menggunakan teknik cerdas untuk mendorong tanggung jawab memantau ketersediaan data kepada pengguna dengan cara yang sesuai insentif. Kembali pada tahun 2017-2019, ketika yang kita miliki untuk meningkatkan komputasi hanyalah bukti penipuan, Plasma sangat terbatas dalam hal apa yang dapat dilakukannya dengan aman, tetapi penggunaan SNARK secara umum membuat arsitektur Plasma jauh lebih layakuntuk berbagai kasus penggunaan yang lebih luas dari sebelumnya.

Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data

Masalah apa yang sedang kita selesaikan?

Pada 13 Maret 2024, ketika Upgrade Dencun Ditayangkan, blockchain Ethereum memiliki tiga ~ 125 kB "gumpalan" per slot 12 detik, atau ~ 375 kB per slot bandwidth ketersediaan data. Dengan asumsi data transaksi dipublikasikan secara onchain secara langsung, transfer ERC20 adalah ~ 180 byte, sehingga TPS maksimum rollup di Ethereum adalah:

375000 / 12 / 180 = 173.6 TPS

Jika kita menambahkan calldata Ethereum (maksimum teoretis: 30 juta gas per slot / 16 gas per byte = 1.875.000 byte per slot), ini menjadi 607 TPS. Dengan PeerDAS, rencananya adalah untuk meningkatkan target hitungan blob menjadi 8-16, yang akan memberikan kita 463-926 TPS dalam calldata.

Ini adalah peningkatan besar dari Ethereum L1, tetapi belum cukup. Kami menginginkan skalabilitas yang jauh lebih besar. Target menengah kami adalah 16 MB per slot, yang jika dikombinasikan dengan peningkatan dalam kompresi data rollup akan memberikan kami ~58.000 TPS.

Apa itu dan bagaimana cara kerjanya?

PeerDAS adalah implementasi yang relatif sederhana dari “1D sampling”. Setiap blob di Ethereum adalah polinomial derajat-4096 di atas lapangan prima 253-bit. Kami menyiarkan “bagian” dari polinomial, di mana setiap bagian terdiri dari 16 evaluasi pada 16 koordinat bersebelahan yang diambil dari total 8192 koordinat. Sebanyak 4096 dari 8192 evaluasi (dengan parameter yang diusulkan saat ini: 64 dari 128 sampel yang mungkin) dapat memulihkan blob tersebut.

PeerDAS bekerja dengan membuat setiap klien mendengarkan sejumlah kecil subnet, di mana subnet ke-i menyiarkan sampel ke-i dari setiap blob, dan juga meminta blob pada subnet lain yang diperlukan dengan cara meminta rekan-rekannya dalam jaringan p2p global (yang akan mendengarkan subnet yang berbeda). Versi yang lebih konservatif, SubnetDAS, menggunakan hanya mekanisme subnet, tanpa lapisan tambahan bertanya kepada rekan sebaya. Proposal saat ini adalah agar node-node yang berpartisipasi dalam bukti kepemilikan menggunakan SubnetDAS, dan node-node lain (yaitu “klien-klien”) menggunakan PeerDAS.

Secara teori, kita bisa memperluas sampel 1D cukup jauh: jika kita meningkatkan jumlah blob maksimum menjadi 256 (jadi, target menjadi 128), maka kita akan mencapai target 16 MB sementara sampel ketersediaan data hanya akan biaya setiap node 16 sampel128 blob512 byte per sampel per blob = 1 MB bandwidth data per slot. Ini hanya cukup dalam jangkauan toleransi kami: bisa dilakukan, tetapi akan berarti klien yang terbatas bandwidth tidak dapat melakukan sampel. Kami bisa mengoptimalkan ini sedikit dengan mengurangi jumlah blob dan menambah ukuran blob, tetapi ini akan membuat rekonstruksi lebih mahal.

Dan akhirnya kami ingin pergi lebih jauh, dan melakukan2D sampling, yang berfungsi dengan pengambilan sampel acak bukan hanya di dalam blog, tetapi juga di antara blog. Properti linear dari komitmen KZG digunakan untuk “memperluas” kumpulan blog dalam blok dengan daftar “blog virtual” baru yang secara berlebihan mengkodekan informasi yang sama.

Pengambilan sampel 2D. Sumber: a16z crypto

Pentingnya, menghitung perpanjangan dari komitmen tidak memerlukan adanya blob, sehingga skema ini pada dasarnya ramah terhadap konstruksi blok terdistribusi. Node yang sebenarnya membangun blok hanya perlu memiliki komitmen blob KZG, dan dapat mengandalkan DAS untuk memverifikasi ketersediaan blob tersebut. 1D DAS juga secara inheren ramah terhadap konstruksi blok yang terdistribusi.

Apa beberapa tautan ke penelitian yang ada?

• Pos asli memperkenalkan ketersediaan data (2018): https://github.com/ethereum/research/wiki/Catatan-tentang-ketersediaan-data-dan-pengkodean-penghapusan
• Tugas lanjutan: https://arxiv.org/abs/1809.09044
• Pos penjelasan tentang DAS, paradigma: https://www.paradigm.xyz/2022/08/das
• Ketersediaan 2D dengan komitmen KZG: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
• PeerDAS di ethresear.ch: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 , dan kertas: https://eprint.iacr.org/2024/1362
• Presentasi tentang PeerDAS oleh Francesco: https://www.youtube.com/watch?v=WOdpO1tH_Us
• EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
• SubnetDAS di ethresear.ch: https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169
• Nuansa dari pemulihan dalam pengambilan sampel 2D: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256

Apa yang tersisa untuk dilakukan, dan apa pengorbanannya?

Langkah selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Dari sana, langkah berikutnya adalah secara progresif meningkatkan jumlah blob di PeerDAS sambil dengan cermat memantau jaringan dan meningkatkan perangkat lunak untuk memastikan keamanan. Pada saat yang sama, kami menginginkan lebih banyak karya akademis dalam memformalkan PeerDAS dan versi lain dari DAS serta interaksinya dengan isu-isu seperti keamanan aturan pemilihan fork.

Lebih jauh ke masa depan, kita membutuhkan lebih banyak pekerjaan untuk mencari tahu versi ideal DAS 2D dan membuktikan sifat keamanannya. Kami juga ingin akhirnya bermigrasi dari KZG ke alternatif bebas pengaturan yang tahan kuantum dan tepercaya. Saat ini, kami tidak tahu kandidat yang ramah terhadap bangunan blok yang didistribusikan. Bahkan teknik "brute force" yang mahal dalam menggunakan STARK rekursif untuk menghasilkan bukti validitas untuk merekonstruksi baris dan kolom tidak cukup, karena sementara secara teknis STARK adalah O(log(n) * log(log(n)) hash dalam ukuran (dengan STIR), dalam praktiknya STARK hampir sebesar satu blob keseluruhan.

Jalur realistis yang saya lihat untuk jangka panjang adalah:

• Melaksanakan ideal 2D DAS
• Tetaplah dengan 1D DAS, mengorbankan efisiensi bandwidth sampling dan menerima batas data yang lebih rendah demi kesederhanaan dan kekokohan
• (Pivot keras) meninggalkan DA, dan sepenuhnya merangkul Plasma sebagai arsitektur lapisan 2 utama yang sedang kita fokuskan

Kita dapat melihat ini sepanjang spektrum tradeoff:

Perhatikan bahwa pilihan ini tetap ada bahkan jika kita memutuskan untuk melakukan skala eksekusi langsung di L1. Hal ini karena jika L1 harus memproses banyak TPS, blok L1 akan menjadi sangat besar, dan klien akan menginginkan cara yang efisien untuk memverifikasi bahwa mereka benar, sehingga kita harus menggunakan teknologi yang sama yang menggerakkan rollups (ZK-EVM dan DAS) di L1.

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

Kebutuhan akan 2D DAS agak berkurang, atau setidaknya ditunda, jika kompresi data (lihat di bawah) diimplementasikan, dan ini lebih berkurang jika Plasma digunakan secara luas. DAS juga menimbulkan tantangan bagi protokol dan mekanisme pembangunan blok terdistribusi: sementara DAS secara teoritis ramah terhadap rekonstruksi terdistribusi, ini perlu digabungkan dalam praktik dengandaftar inklusiproposals dan mekanisme pemilihan fork di sekitarnya.

Kompresi data

Masalah apa yang sedang kita selesaikan?

Setiap transaksi dalam rollup membutuhkan sejumlah besar ruang data onchain: transfer ERC20 membutuhkan sekitar 180 byte. Bahkan dengan pengambilan sampel ketersediaan data yang ideal, ini membatasi skalabilitas protokol lapisan 2. Dengan 16 MB per slot, kita mendapatkan:

16000000 / 12 / 180 = 7407 TPS

Bagaimana jika selain menangani pembilang, kita juga bisa menangani penyebut, dan membuat setiap transaksi dalam rollup mengambil lebih sedikit byte onchain?

Apa itu dan bagaimana cara kerjanya?

Penjelasan terbaik menurut pendapat saya adalah diagram inidari dua tahun yang lalu:

Kenaikan paling sederhana hanyalah kompresi byte nol: mengganti setiap urutan panjang byte nol dengan dua byte yang mewakili berapa banyak byte nol yang ada. Untuk lebih jauh, kita memanfaatkan properti khusus dari transaksi:

• Agregasi tanda tangan - kita beralih dari tanda tangan ECDSA ke tanda tangan BLS, yang memiliki sifat bahwa banyak tanda tangan dapat digabungkan menjadi satu tanda tangan yang menegaskan validitas semua tanda tangan asli. Ini tidak dipertimbangkan untuk L1 karena biaya komputasi verifikasi, bahkan dengan agregasi, lebih tinggi, tetapi dalam lingkungan yang kacau data seperti L2s, mereka bisa dibilang masuk akal. Fitur agregasi dari ERC-4337menyajikan satu jalan untuk mengimplementasikan ini.
• Mengganti alamat dengan pointer - jika alamat digunakan sebelumnya, kita dapat mengganti alamat 20-byte dengan pointer 4-byte ke lokasi dalam sejarah. Ini diperlukan untuk mencapai keuntungan terbesar, meskipun dibutuhkan upaya untuk menerapkannya, karena membutuhkan (setidaknya sebagian dari) sejarah blockchain untuk secara efektif menjadi bagian dari negara.
• Serialisasi khusus untuk nilai transaksi - sebagian besar nilai transaksi memiliki sangat sedikit digit, mis. 0,25 ETH direpresentasikan sebagai 250.000.000.000.000.000.000 wei. Biaya dasar maks gas dan biaya prioritas bekerja dengan cara yang sama. Dengan demikian kita dapat mewakili sebagian besar nilai mata uang dengan sangat kompak dengan format floating point desimal khusus, atau bahkan kamus nilai yang sangat umum.

Apa beberapa tautan ke penelitian yang ada?

• Eksplorasi dari sequence.xyz: https://sequence.xyz/blog/memampatkan-calldata
• Kontrak yang dioptimalkan untuk panggilan data untuk L2s, dari ScopeLift: https://github.com/ScopeLift/l2-optimizoooors
• Sebuah strategi alternatif - rollups berbasis bukti validitas (juga dikenal sebagai ZK rollups) memposting perbedaan status daripada transaksi: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
• Dompet BLS - sebuah implementasi dari agregasi BLS melalui ERC-4337: https://github.com/getwax/bls-wallet

Apa yang tersisa untuk dilakukan, dan apa saja tradeoffnya?

Hal utama yang harus dilakukan adalah benar-benar menerapkan skema di atas. Kompromi utama adalah:

• Beralih ke tanda tangan BLS memerlukan upaya yang signifikan, dan mengurangi kompatibilitas dengan chip perangkat keras terpercaya yang dapat meningkatkan keamanan. Sebuah pembungkus ZK-SNARK di sekitar skema tanda tangan lain dapat digunakan untuk menggantikan ini.
• Kompresi dinamis (misalnya, mengganti alamat dengan pointer) mempersulit kode klien.
• Mengirim perbedaan status ke rantai alih-alih transaksi mengurangi auditabilitas, dan membuat banyak perangkat lunak (misalnya, penjelajah blok) tidak berfungsi.

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

Adopsi ERC-4337, dan akhirnya pengakuan bagi sebagian dari itu di L2 EVMs, dapat sangat mempercepat implementasi teknik agregasi. Pengakuan bagi sebagian dari ERC-4337 di L1 dapat mempercepat implementasinya di L2.

Generalized Plasma

Masalah apa yang sedang kita selesaikan?

Bahkan dengan blok 16 MB dan kompresi data, 58.000 TPS belum tentu cukup untuk sepenuhnya mengambil alih pembayaran konsumen, sosial terdesentralisasi, atau sektor berbandwidth tinggi lainnya, dan hal ini menjadi benar-benar terutama jika kita mulai mempertimbangkan privasi, yang bisa menurunkan skalabilitas hingga 3-8x. Untuk aplikasi dengan volume tinggi dan nilai rendah, salah satu pilihan saat ini adalah validium, yang menyimpan data di luar rantai dan memiliki model keamanan yang menarik di mana operator tidak dapat mencuri dana pengguna, tetapi mereka bisa menghilang dan sementara atau secara permanen membekukan semua dana pengguna. Tetapi kita bisa melakukan lebih baik.

Apa itu dan bagaimana cara kerjanya?

Plasma adalah solusi penskalaan yang melibatkan operator menerbitkan blok secara offchain, dan menempatkan akar Merkle dari blok-blok tersebut onchain (berbeda dengan rollups, di mana blok lengkap ditempatkan onchain). Untuk setiap blok, operator mengirimkan ke setiap pengguna sebuah cabang Merkle yang membuktikan apa yang terjadi, atau tidak terjadi, pada aset pengguna itu. Pengguna dapat menarik aset mereka dengan memberikan cabang Merkle. Yang penting, cabang ini tidak harus berakar dalam keadaan terbaru - karena alasan ini, bahkan jika ketersediaan data gagal, pengguna masih dapat memulihkan aset mereka dengan menarik keadaan terbaru yang tersedia. Jika seorang pengguna mengirimkan cabang yang tidak valid (misalnya keluar dari aset yang sudah dikirimkan kepada orang lain, atau operator sendiri menciptakan aset dari udara), mekanisme tantangan onchain dapat menyelesaikan siapa yang berhak memiliki aset tersebut.

Sebuah diagram dari rantai Plasma Cash. Transaksi yang menghabiskan koin i ditempatkan ke posisi ke-i dalam pohon. Dalam contoh ini, dengan asumsi semua pohon sebelumnya valid, kita tahu bahwa Eve saat ini memiliki koin 1, David memiliki koin 4, dan George memiliki koin 6.

Versi awal Plasma hanya mampu menangani kasus penggunaan pembayaran, dan tidak dapat secara efektif menggeneralisasi lebih lanjut. Namun, jika kita mengharuskan setiap root diverifikasi dengan SNARK, Plasma menjadi jauh lebih kuat. Setiap permainan tantangan dapat disederhanakan secara signifikan, karena kami mengambil jalur yang paling mungkin bagi operator untuk menipu. Jalur baru juga terbuka untuk memungkinkan teknik Plasma diperluas ke kelas aset yang jauh lebih umum. Akhirnya, dalam kasus di mana operator tidak curang, pengguna dapat menarik dana mereka secara instan, tanpa perlu menunggu periode tantangan satu minggu.

Salah satu cara (bukan satu-satunya cara) untuk membuat rantai plasma EVM: gunakan ZK-SNARK untuk membangun pohon UTXO paralel yang mencerminkan perubahan saldo yang dilakukan oleh EVM, dan mendefinisikan pemetaan unik dari apa yang merupakan "koin yang sama" pada titik-titik berbeda dalam sejarah. Konstruksi Plasma kemudian dapat dibangun di atasnya.

Satu wawasan kunci adalah bahwa sistem Plasma tidak perlu sempurna. Bahkan jika Anda hanya bisa melindungi sebagian aset (misalnya, bahkan hanya koin yang tidak bergerak dalam seminggu terakhir), Anda telah sangat meningkatkan pada status quo ultra-scalable EVM, yang merupakan validium yang valid.

Kelas konstruksi lainnya adalah plasma hibrid/gulungan, seperti Intmax. Konstruksi-konstruksi ini menempatkan jumlah data yang sangat kecil per pengguna di onchain (misalnya 5 byte), dan dengan melakukan hal tersebut, Anda mendapatkan properti yang berada di suatu tempat di antara plasma dan rollups: dalam kasus Intmax, Anda mendapatkan tingkat skalabilitas dan privasi yang sangat tinggi, meskipun bahkan dalam dunia 16 MB kapasitasnya secara teoritis dibatasi sekitar 16.000.000 / 12 / 5 = 266.667 TPS.

Apa beberapa tautan ke penelitian yang sudah ada?

• Kertas Plasma asli: https://plasma.io/plasma-deprecated.pdf
• Plasma Cash: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
• Plasma Cashflow: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#🚪-Exit
• Intmax (2023): https://eprint.iacr.org/2023/1082

Apa yang tersisa untuk dilakukan, dan apa saja tradeoffs yang harus dilakukan?

Tugas utama yang tersisa adalah untuk membawa sistem Plasma ke tahap produksi. Seperti yang disebutkan di atas, “plasma vs validium” bukanlah binary: setiap validium dapat meningkatkan sedikit saja sifat keamanannya dengan menambahkan fitur Plasma ke dalam mekanisme keluar. Bagian penelitian adalah tentang mendapatkan sifat optimal (dalam hal persyaratan kepercayaan, biaya gas L1 dalam kasus terburuk, dan rentan terhadap DoS) untuk sebuah EVM, serta konstruksi aplikasi khusus alternatif. Selain itu, kompleksitas konseptual yang lebih besar dari Plasma dibandingkan dengan rollups perlu ditangani secara langsung, baik melalui penelitian maupun melalui konstruksi kerangka kerja umum yang lebih baik.

Kompromi utama dalam menggunakan desain Plasma adalah bahwa mereka lebih bergantung pada operator dan lebih sulit untuk dibuatberbasisMeskipun desain plasma/rollup hibrida seringkali dapat menghindari kelemahan ini.

Bagaimana cara interaksi dengan bagian lain dari peta jalan?

Semakin efektif solusi Plasma, semakin sedikit tekanan yang ada bagi L1 untuk memiliki fungsionalitas ketersediaan data berkinerja tinggi. Memindahkan aktivitas ke L2 juga mengurangi tekanan MEV pada L1.

Sistem bukti L2 yang matang

Masalah apa yang sedang kita selesaikan?

Saat ini, sebagian besar rollups sebenarnya belum sepenuhnya tidak dapat dipercaya; ada dewan keamanan yang memiliki kemampuan untuk mengesampingkan perilaku dari (optimis atau validitas)sistem buktiDalam beberapa kasus, sistem bukti bahkan tidak sepenuhnya aktif, atau jika memang aktif, hanya memiliki fungsi 'penasihat'. Yang paling maju adalah (i) beberapa rollup khusus aplikasi, seperti Fuel, yang tidak memerlukan kepercayaan, dan (ii) pada saat penulisan ini, Optimism dan Arbitrum, dua rollup penuh-EVM yang telah mencapai tonggak sebagian-kepercayaan yang dikenal sebagai 'tahap 1'. Alasan mengapa rollup tidak berkembang lebih jauh adalah kekhawatiran tentang bug dalam kode. Kita memerlukan rollup tanpa kepercayaan, oleh karena itu kita perlu menangani masalah ini secara langsung.

Apa itu dan bagaimana cara kerjanya?

Pertama, mari kita mengulang sistem “stage”, yang awalnya diperkenalkan diposting iniAda persyaratan lebih rinci, tetapi ringkasannya adalah:

• Tahap 0: pengguna harus dapat menjalankan node dan menyinkronkan rantai. Tidak masalah jika validasi sepenuhnya dipercayai/dipusatkan.
• Tahap 1: harus ada sistem bukti (tanpa kepercayaan) yang memastikan bahwa hanya transaksi valid yang diterima. Diperbolehkan adanya dewan keamanan yang dapat mengesampingkan sistem bukti, tetapi hanya dengan suara ambang batas 75%. Selain itu, bagian dewan yang memblokir kuorum (misalnya, 26%+) harus berada di luar gedung utama perusahaan yang membangun rollup. Mekanisme upgrade dengan fitur yang lebih lemah (misalnya, DAO) diperbolehkan, tetapi harus memiliki penundaan yang cukup lama sehingga jika disetujui upgrade jahat, pengguna dapat menarik dana mereka sebelumnya sebelum tersambung.
• Tahap 2: harus ada sistem bukti (tanpa kepercayaan) yang memastikan bahwa hanya transaksi valid yang diterima. Dewan keamanan hanya diizinkan untuk turun tangan dalam kasus bug yang bisa dibuktikan dalam kode, misalnya jika dua sistem bukti yang redundan tidak setuju satu sama lain atau jika satu sistem bukti menerima dua root keadaan yang berbeda untuk blok yang sama (atau tidak menerima apa pun untuk jangka waktu yang cukup lama misalnya seminggu). Mekanisme upgrade diizinkan, tetapi harus memiliki penundaan yang sangat lama.

Tujuannya adalah mencapai Tahap 2. Tantangan utama dalam mencapai tahap 2 adalah mendapatkan cukup keyakinan bahwa sistem bukti tersebut benar-benar cukup dapat dipercaya. Ada dua cara utama untuk melakukannya:

• Verifikasi formal: kita dapat menggunakan teknik matematika dan komputasi modern untuk membuktikan bahwa sistem bukti (optimis atau validitas) hanya menerima blok yang lulus spesifikasi EVM. Teknik-teknik ini telah ada selama beberapa dekade, tetapi kemajuan baru-baru ini seperti Lean 4telah membuatnya jauh lebih praktis, dan kemajuan dalam pembuktian yang dibantu AI bisa mempercepat tren ini lebih lanjut.
• Multi-pemberi bukti: membuat beberapa sistem bukti, dan menempatkan dana ke dalam multisig 2-dari-3 (atau lebih) antara sistem bukti tersebut dan dewan keamanan (dan/atau perangkat lain dengan asumsi kepercayaan, misalnya TEEs). Jika sistem bukti setuju, dewan keamanan tidak memiliki kekuatan; jika mereka tidak setuju, dewan keamanan hanya dapat memilih salah satunya, ia tidak dapat sepihak menerapkan jawaban sendiri.

Diagram bergaya multi-prover, menggabungkan satu sistem bukti optimis, satu sistem bukti validitas dan dewan keamanan.

Apa beberapa tautan ke penelitian yang sudah ada?

• Semantik K EVM (kerja verifikasi formal dari tahun 2017): https://github.com/runtimeverification/evm-semantics
• Presentasi tentang gagasan multi-pembuktian (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI
• Taiko berencana untuk menggunakan multi-bukti: https://docs.taiko.xyz/core-concepts/multi-proofs/

Apa yang tersisa untuk dilakukan, dan apa saja kompromi yang harus dibuat?

Untuk verifikasi formal, banyak. Kita perlu membuat versi yang diverifikasi secara formal dari seluruh prover SNARK dari EVM. Ini adalah proyek yang sangat kompleks, meskipun itu adalah salah satu yang kami sudah mulai. Ada satu trik yang secara signifikan menyederhanakan tugas: kita dapat membuat prover SNARK yang diverifikasi secara formal dari VM minimal, misalnya. RISC-VatauKairo, dan kemudian menulis implementasi EVM dalam VM minimal tersebut (dan membuktikan secara formal kesetaraannya dengan beberapa spesifikasi EVM lain).

Untuk multi-pemberi bukti, ada dua bagian utama yang tersisa. Pertama, kita perlu mendapatkan cukup keyakinan dalam setidaknya dua sistem bukti yang berbeda, baik bahwa mereka cukup aman secara individu dan bahwa jika mereka rusak, mereka akan rusak karena alasan yang berbeda dan tidak terkait (dan sehingga mereka tidak akan rusak pada saat yang sama). Kedua, kita perlu mendapatkan tingkat keyakinan yang sangat tinggi dalam logika dasar yang menggabungkan sistem bukti. Ini adalah bagian kode yang jauh lebih kecil. Ada cara untuk membuatnya sangat kecil - cukup simpan dana dalam sebuahKontrak multisig amanyang penandatangannya adalah kontrak yang mewakili sistem bukti individu - tetapi ini memiliki keseimbangan biaya gas onchain yang tinggi. Sejumlah keseimbangan antara efisiensi dan keamanan perlu ditemukan.

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

Mengalihkan aktivitas ke L2 mengurangi tekanan MEV pada L1.

Perbaikan interoperabilitas lintas-L2

Masalah apa yang sedang kita selesaikan?

Salah satu tantangan utama dengan ekosistem L2 saat ini adalah sulit bagi pengguna untuk menavigasinya. Selain itu, cara paling mudah untuk melakukannya seringkali memperkenalkan asumsi kepercayaan kembali: jembatan terpusat, klien RPC, dan sebagainya. Jika kita serius tentang gagasan bahwa L2 adalah bagian dari Ethereum, kita perlu membuat penggunaan ekosistem L2 terasa seperti menggunakan ekosistem Ethereum yang terpadu.

Contoh penggunaan lintasan yang sangat buruk (dan bahkan berbahaya: saya pribadi kehilangan $100 akibat kesalahan pemilihan rantai di sini) pada UX lintas-L2 - meskipun ini bukan kesalahan Polymarket, interoperabilitas lintas-L2 seharusnya menjadi tanggung jawab dompet dan komunitas standar Ethereum (ERC). Dalam ekosistem Ethereum yang berfungsi dengan baik, mengirim koin dari L1 ke L2, atau dari satu L2 ke yang lain, seharusnya terasa sama seperti mengirim koin dalam L1 yang sama.

Apa itu dan bagaimana cara kerjanya?

Ada banyak kategori perbaikan interoperabilitas lintas-L2. Secara umum, cara untuk menghasilkan ini adalah dengan memperhatikan bahwa dalam teori, Sebuah Ethereum yang berpusat pada rollup adalah hal yang sama dengan sharding eksekusi L1, dan kemudian bertanya di mana dunia Ethereum L2 saat ini kurang dalam praktiknya. Berikut adalah beberapa:

• Alamat khusus rantai: rantai (L1, Optimism, Arbitrum ...) harus menjadi bagian dari alamat. Setelah ini diimplementasikan, aliran pengiriman lintas-L2 dapat diimplementasikan dengan hanya menempatkan alamat ke dalam kolom 'kirim', pada saat itu dompet dapat menentukan cara melakukan pengiriman (termasuk menggunakan protokol jembatan) di latar belakang.
• Permintaan pembayaran khusus rantai: harus mudah dan berstandar untuk membuat pesan berupa 'kirimkan saya X token jenis Y di rantai Z'. Ini memiliki dua kasus penggunaan utama: (i) pembayaran, baik dari orang ke orang atau dari orang ke layanan pedagang, dan (ii) dapps yang meminta dana, misalnya contoh Polymarket di atas.
• Pertukaran lintas-rantai dan pembayaran gas: seharusnya ada protokol terbuka standar untuk mengekspresikan operasi lintas-rantai seperti “Saya mengirimkan 1 ETH di Optimism kepada siapa pun yang mengirimkan saya 0.9999 ETH di Arbitrum”, dan “Saya mengirimkan 0.0001 ETH di Optimism kepada siapa pun yang memasukkan transaksi ini di Arbitrum”. ERC-7683adalah salah satu upaya pada yang pertama, danRIP-7755adalah satu upaya pada yang terakhir, meskipun keduanya juga lebih umum daripada hanya kasus penggunaan khusus ini.
• Klien ringan: pengguna harus dapat benar-benar memverifikasi rantai yang mereka interaksikan, dan tidak hanya mempercayai penyedia RPC. A16z crypto’sHeliosmelakukan hal ini untuk Ethereum itu sendiri, tetapi kita perlu memperluas ketidakpercayaan ini ke L2s.ERC-3668 (CCIP-read)adalah satu strategi untuk melakukan ini.

Bagaimana klien ringan dapat memperbarui tampilannya dari rantai header Ethereum. Begitu Anda memiliki rantai header, Anda dapat menggunakan bukti Merkle untuk memvalidasi objek status apa pun. Dan begitu Anda memiliki objek status L1 yang tepat, Anda dapat menggunakan bukti Merkle (dan mungkin tanda tangan, jika Anda ingin memeriksa pra-konfirmasi) untuk memvalidasi objek status apa pun di L2. Helios sudah melakukan yang pertama. Memperluas ke yang terakhir adalah tantangan standarisasi.

• Dompet keystore: saat ini, jika Anda ingin memperbarui kunci yang mengontrol dompet kontrak pintar Anda, Anda harus melakukannya di semua rantai N di mana dompet tersebut ada. Dompet keystore adalah teknik yang memungkinkan kunci-kunci berada di satu tempat (baik di L1, atau kemudian mungkin di L2), dan kemudian dibaca dari setiap L2 yang memiliki salinan dompet. Ini berarti bahwa pembaruan hanya perlu dilakukan sekali. Agar efisien, dompet keystore memerlukan L2 memiliki cara standar untuk membaca L1 tanpa biaya; dua proposal untuk ini adalah L1SLOADdanREMOTESTATICCALL.

Sebuah diagram bergaya tentang bagaimana dompet keystore bekerja.

• Ide "jembatan token bersama" yang lebih radikal: bayangkan sebuah dunia di mana semua L2 adalah rollup bukti validitas, yang berkomitmen untuk Ethereum setiap slot. Bahkan di dunia ini, memindahkan aset dari satu L2 ke L2 lain "secara asli" akan membutuhkan penarikan dan penyetoran, yang membutuhkan pembayaran sejumlah besar gas L1. Salah satu cara untuk mengatasi ini adalah dengan membuat rollup minimal bersama, yang fungsinya hanya untuk menjaga saldo berapa banyak token dari jenis mana yang dimiliki oleh L2 mana, dan memungkinkan saldo tersebut diperbarui secara massal oleh serangkaian operasi pengiriman lintas-L2 yang diprakarsai oleh salah satu L2. Ini akan memungkinkan transfer lintas-L2 terjadi tanpa perlu membayar gas L1 per transfer, dan tanpa memerlukan teknik berbasis penyedia likuiditas seperti ERC-7683.
• Komposabilitas sinkron: memungkinkan panggilan sinkron terjadi baik antara spesifik L2 dan L1, atau antara beberapa L2. Hal ini dapat membantu meningkatkan efisiensi keuangan protokol defi. Yang pertama dapat dilakukan tanpa koordinasi lintas L2; yang terakhir akan memerlukanurutan berbagi. Berbasis rollupssecara otomatis ramah terhadap semua teknik ini.

Apa beberapa tautan ke penelitian yang sudah ada?

• Alamat khusus rantai: ERC-3770: https://eips.ethereum.org/EIPS/eip-3770
• ERC-7683: https://eips.ethereum.org/EIPS/eip-7683
• RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md
• Desain dompet keystore Scroll: @haichen/keystore"">https://hackmd.io/@haichen/keystore
• Helios: https://github.com/a16z/helios
• ERC-3668 (kadang disebut CCIP-read): https://eips.ethereum.org/EIPS/eip-3668
• Usulan untuk “konfirmasi pra bersama” oleh Justin Drake: https://ethresear.ch/t/based-preconfirmations/17353
• L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388
• REMOTESTATICCALL di Optimism: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
• AggLayer, yang mencakup ide jembatan token bersama: https://github.com/AggLayer

Apa yang harus dilakukan, dan apa saja tradeoffs-nya?

Banyak contoh di atas menghadapi dilema standar kapan harus membakukan dan lapisan apa yang harus distandarisasi. Jika Anda membakukan terlalu dini, Anda berisiko memperkuat solusi yang lebih rendah. Jika Anda terlambat membakukan, Anda berisiko menciptakan fragmentasi yang tidak perlu. Dalam beberapa kasus, ada solusi jangka pendek yang memiliki sifat lebih lemah tetapi lebih mudah diterapkan, dan solusi jangka panjang yang "pada akhirnya benar" tetapi akan memakan waktu beberapa tahun untuk sampai ke sana.

Salah satu hal yang membuat bagian ini unik adalah bahwa tugas-tugas ini bukan hanya masalah teknis: mereka juga (bahkan mungkin terutama!) masalah sosial. Mereka memerlukan L2s dan dompet dan L1 untuk bekerja sama. Kemampuan kita untuk menangani masalah ini dengan sukses adalah ujian kemampuan kita untuk bertahan bersama sebagai komunitas.

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

Sebagian besar proposal ini adalah konstruksi "lapisan tinggi", sehingga tidak terlalu mempengaruhi pertimbangan L1. Satu pengecualian adalah pengurutan bersama, yang berdampak besar pada MEV.

Skala eksekusi di L1

Masalah apa yang sedang kita selesaikan?

Jika L2 menjadi sangat scalable dan sukses tetapi L1 tetap mampu hanya memproses volume transaksi yang sangat rendah, ada banyak risiko bagi Ethereum yang mungkin muncul:

1. Situasi ekonomi ETH aset menjadi lebih berisiko, yang pada gilirannya mempengaruhi keamanan jaringan jangka panjang.
2. Banyak L2 mendapat manfaat dari keterikatan yang erat dengan ekosistem keuangan yang sangat berkembang di L1, dan jika ekosistem ini melemah secara signifikan, insentif untuk menjadi L2 (daripada menjadi L1 independen) juga melemah
3. Akan memakan waktu lama sebelum L2 memiliki jaminan keamanan yang sama persis dengan L1.
4. Jika sebuah L2 gagal (misalnya karena operator jahat atau menghilang), pengguna masih perlu melalui L1 untuk memulihkan aset mereka. Oleh karena itu, L1 perlu cukup kuat untuk setidaknya sesekali benar-benar menangani penurunan yang sangat kompleks dan kacau dari L2.

Untuk alasan-alasan ini, penting untuk terus memperluas L1 itu sendiri, dan memastikan bahwa itu dapat terus menampung jumlah pengguna yang semakin meningkat.

Apa itu dan bagaimana cara kerjanya?

Cara termudah untuk menskalakan adalah dengan hanya meningkatkan batas gas. Namun, ini berisiko memusatkan L1, dan dengan demikian melemahkan properti penting lainnya yang membuat Ethereum L1 begitu kuat: kredibilitasnya sebagai lapisan dasar yang kuat. Ada perdebatan yang sedang berlangsung tentang tingkat kenaikan batas gas sederhana yang berkelanjutan, dan ini juga berubah berdasarkan teknologi lain yang diimplementasikan untuk membuat blok yang lebih besar lebih mudah diverifikasi (misalnya kedaluwarsa sejarah, statelessness, bukti validitas L1 EVM). Hal penting lainnya untuk terus ditingkatkan adalah efisiensi perangkat lunak klien Ethereum, yang jauh lebih optimal hari ini daripada lima tahun yang lalu. Strategi peningkatan batas gas L1 yang efektif akan melibatkan percepatan teknologi verifikasi ini.

Strategi penskalaan lain melibatkan mengidentifikasi fitur-fitur khusus dan jenis komputasi yang dapat dibuat lebih murah tanpa merusak desentralisasi jaringan atau properti keamanannya. Contoh-contoh ini termasuk:

• EOF- format bytecode EVM baru yang lebih ramah untuk analisis statis, memungkinkan implementasi yang lebih cepat. Bytecode EOF bisa diberikan biaya gas yang lebih rendah untuk memperhitungkan efisiensi ini.
• Penghitungan harga gas multidimensional- menetapkan basefee dan batasan yang terpisah untuk komputasi, data, dan penyimpanan dapat meningkatkan kapasitas rata-rata Ethereum L1 tanpa meningkatkan kapasitas maksimumnya (dan dengan demikian menciptakan risiko keamanan baru).
• Mengurangi biaya gas dari opcode dan precompiles tertentu - secara historis, kita memilikibeberapa putarandarimeningkatgasbiayauntuk operasi tertentu yang dihargai rendah untuk menghindari serangan layanan penolakan. Yang kurang kita miliki, dan bisa dilakukan lebih banyak, adalah mengurangi biaya gas untuk operasi yang dihargai tinggi. Sebagai contoh, penambahan jauh lebih murah daripada perkalian, tetapi biaya opcode ADD dan MUL saat ini sama. Kita bisa membuat ADD lebih murah, dan opcode yang lebih sederhana seperti PUSH bahkan lebih murah.
• EVM-MAXdanSIMD: EVM-MAX ("perluasan aritmetika modular") adalah proposal untuk memungkinkan matematika modular nomor besar asli yang lebih efisien sebagai modul terpisah dari EVM. Nilai yang dihitung oleh komputasi EVM-MAX hanya akan dapat diakses oleh opcode EVM-MAX lainnya, kecuali diekspor secara sengaja; ini memungkinkan ruang yang lebih besar untuk menyimpan nilai-nilai ini diformat yang dioptimalkan. SIMD ("single instruction multiple data") adalah proposal untuk memungkinkan secara efisien mengeksekusi instruksi yang sama pada array nilai. Keduanya bersama-sama dapat menciptakan yang kuat koprosesorbersama-sama dengan EVM yang dapat digunakan untuk mengimplementasikan operasi kriptografis dengan lebih efisien. Ini akan sangat berguna untuk protokol privasi, dan untuk sistem bukti L2, sehingga akan membantu skalabilitas baik L1 maupun L2.

Peningkatan ini akan dibahas lebih detail dalam pos yang akan datang di Splurge.

Akhirnya, strategi ketiga adalah rollups asli (atau “rollups diabadikan”): pada dasarnya, membuat banyak salinan dari EVM yang berjalan secara paralel, mengarah pada model yang setara dengan apa yang rollups dapat berikan, tetapi jauh lebih terintegrasi secara asli ke dalam protokol.

Apa beberapa tautan ke penelitian yang sudah ada?

• Rencana pengembangan skala Ethereum L1 Polynya: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ
• Pricing gas multidimensional:https://vitalik.eth.limo/general/2024/05/09/multidim.html
• EIP-7706: https://eips.ethereum.org/EIPS/eip-7706
• EOF: https://evmobjectformat.org/
• EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
• SIMD: https://eips.ethereum.org/EIPS/eip-616
• rollup asli: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
• Wawancara dengan Max Resnick tentang nilai penskalaan L1: https://x.com/BanklessHQ/status/1831319419739361321
• Justin Drake tentang penggunaan SNARKs dan native rollups untuk penskalaan: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

Apa yang tersisa untuk dilakukan, dan apa yang menjadi tradeoff-nya?

Ada tiga strategi untuk penskalaan L1, yang dapat dikejar secara individu atau secara paralel:

• Meningkatkan teknologi (misalnya kode klien, klien stateless, riwayat kedaluwarsa) untuk membuat L1 lebih mudah diverifikasi, dan kemudian menaikkan batas gas
• Membuat operasi tertentu lebih murah, meningkatkan kapasitas rata-rata tanpa meningkatkan risiko kasus terburuk
• Gulungan asli (yaitu "membuat N salinan paralel dari EVM", meskipun secara potensial memberikan fleksibilitas yang besar kepada pengembang dalam parameter-parameter salinan yang mereka implementasikan)

Sangat penting untuk memahami bahwa ini adalah teknik yang berbeda yang memiliki tradeoff yang berbeda. Sebagai contoh, rollup asli memiliki banyak kelemahan yang sama dalam komposabilitas seperti rollup reguler: Anda tidak dapat mengirimkan transaksi tunggal yang secara sinkron melakukan operasi di banyak rollup, seperti yang dapat Anda lakukan dengan kontrak pada L1 (atau L2) yang sama. Meningkatkan batas gas mengurangi manfaat lain yang dapat dicapai dengan membuat L1 lebih mudah diverifikasi, seperti meningkatkan bagian dari pengguna yang menjalankan node verifikasi, dan meningkatkan solo stakers. Membuat operasi tertentu dalam EVM lebih murah, tergantung pada cara melakukannya, dapat meningkatkan kompleksitas total EVM.

Pertanyaan besar yang perlu dijawab oleh peta jalan penskalaan L1 adalah: apa visi akhir untuk apa yang termasuk dalam L1 dan apa yang termasuk dalam L2? Jelas, tidak masuk akal untuk semuanya berjalan di L1: kasus penggunaan potensial masuk ke ratusan ribu transaksi per detik, dan itu akan membuat L1 benar-benar tidak layak untuk diverifikasi (kecuali kita pergi rute rollup asli). Tetapi kita memang membutuhkan beberapa prinsip panduan, sehingga kita dapat memastikan bahwa kita tidak menciptakan situasi di mana kita meningkatkan batas gas 10x, sangat merusak desentralisasi Ethereum L1, dan menemukan bahwa kita hanya sampai ke dunia di mana alih-alih 99% aktivitas berada di L2, 90% aktivitas ada di L2, dan hasilnya sebaliknya terlihat hampir sama, kecuali untuk kerugian ireversibel dari banyak hal yang membuat Ethereum L1 istimewa.

Satu pandangan yang diusulkan tentang "pembagian kerja" antara L1 dan L2, sumber.

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

Membawa lebih banyak pengguna ke L1 mengimplikasikan peningkatan bukan hanya dalam skala, tetapi juga aspek lain dari L1. Ini berarti bahwa lebih banyak MEV akan tetap berada di L1 (daripada menjadi masalah hanya untuk L2), dan dengan demikian akan menjadi kebutuhan yang lebih mendesak untuk menanganinya secara eksplisit. Ini sangat meningkatkan nilai memiliki waktu slot yang cepat di L1. Dan ini juga sangat bergantung pada verifikasi L1 ("the Verge") yang berjalan lancar.

Penafian：

1. Artikel ini diambil dari [ Vitalik ButerinSemua hak cipta milik penulis asliVitalik Buterin]. Jika ada keberatan terkait pencetakan ulang ini, silakan hubungi Belajar Gatetim, dan mereka akan menanganinya dengan segera.
2. Penyangkalan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.