Masa Depan Ethereum yang Mungkin: The Surge

Peta jalan Ethereum awalnya mencakup dua strategi skalabilitas: sharding dan protokol Layer 2. Seiring dengan penelitian yang lebih mendalam, kedua jalur ini bergabung, membentuk peta jalan yang berfokus pada Rollup, yang masih merupakan strategi perluasan Ethereum saat ini.

Peta jalan yang berpusat pada Rollup mengusulkan pembagian kerja yang sederhana: Ethereum L1 berfokus untuk menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 mengambil tugas membantu ekosistem untuk berkembang. Pola ini ada di mana-mana dalam masyarakat: keberadaan sistem pengadilan (L1) bukan untuk mengejar kecepatan super dan efisiensi tinggi, melainkan untuk melindungi kontrak dan hak milik, sementara para pengusaha (L2) membangun di atas lapisan dasar yang kokoh ini, mendorong kemajuan manusia.

Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai hasil penting: dengan peluncuran blob EIP-4844, bandwidth data Ethereum L1 meningkat secara signifikan, dan beberapa Ethereum Virtual Machine (EVM) Rollup telah memasuki fase pertama. Setiap L2 ada sebagai "shard" yang memiliki aturan dan logika internalnya sendiri, dan keberagaman serta diversifikasi cara implementasi shard kini telah menjadi kenyataan. Namun, jalan ini juga menghadapi beberapa tantangan unik. Tugas kita sekarang adalah menyelesaikan peta jalan yang berfokus pada Rollup, dan mengatasi masalah ini, sambil mempertahankan ketahanan dan desentralisasi yang khas dari Ethereum L1.

The Surge: Tujuan Kunci

1. Di masa depan, Ethereum melalui L2 dapat mencapai lebih dari 100.000 TPS;
2. Mempertahankan desentralisasi dan ketahanan L1;
3. Setidaknya beberapa L2 sepenuhnya mewarisi atribut inti Ethereum ( yang tidak memerlukan kepercayaan, terbuka, dan tahan sensor );
4. Ethereum seharusnya terasa seperti ekosistem yang terintegrasi, bukan 34 blockchain yang berbeda.

Isi Artikel Ini

1. Paradoks Segitiga Skalabilitas
2. Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data
3. Kompresi Data
4. Plasma Generalisasi
5. Sistem pembuktian L2 yang matang
6. Peningkatan interoperabilitas L2
7. Memperluas eksekusi di L1

Paradoks Segitiga Skalabilitas

Paradoks segitiga skalabilitas berpendapat bahwa ada kontradiksi antara tiga karakteristik blockchain: desentralisasi ( biaya rendah untuk menjalankan node ), skalabilitas ( jumlah transaksi yang dapat diproses banyak ) dan keamanan ( penyerang perlu menghancurkan sebagian besar node di jaringan agar satu transaksi gagal ).

Paradoks segitiga bukanlah sebuah teorema, melainkan memberikan suatu argumen matematis heuristik: jika sebuah node yang ramah terhadap desentralisasi dapat memverifikasi N transaksi per detik, dan Anda memiliki sebuah rantai yang memproses k*N transaksi per detik, maka (i) setiap transaksi hanya dapat dilihat oleh 1/k node, yang berarti penyerang hanya perlu menghancurkan sebagian kecil node untuk melewati sebuah transaksi jahat, atau (ii) node Anda akan menjadi kuat, sementara rantai Anda tidak akan terdesentralisasi.

Selama bertahun-tahun, beberapa rantai berkinerja tinggi sering mengklaim bahwa mereka telah menyelesaikan paradoks trilema tanpa mengubah arsitektur secara fundamental, biasanya dengan menerapkan teknik rekayasa perangkat lunak untuk mengoptimalkan node. Ini selalu menyesatkan, menjalankan node di rantai ini jauh lebih sulit daripada menjalankan node di Ethereum.

Namun, kombinasi sampling ketersediaan data dengan SNARKs memang menyelesaikan paradoks segitiga: ini memungkinkan klien untuk memverifikasi sejumlah data yang tersedia dengan hanya mengunduh sejumlah kecil data dan melakukan sangat sedikit perhitungan, serta memastikan sejumlah langkah perhitungan telah dieksekusi dengan benar. SNARKs tidak memerlukan kepercayaan. Sampling ketersediaan data memiliki model kepercayaan few-of-N yang halus, tetapi mempertahankan karakteristik dasar dari rantai yang tidak dapat diskalakan, yaitu bahkan serangan 51% tidak dapat memaksa blok buruk untuk diterima oleh jaringan.

Salah satu cara lain untuk mengatasi tiga tantangan adalah arsitektur Plasma, yang menggunakan teknologi cerdas untuk mendorong tanggung jawab pemantauan ketersediaan data kepada pengguna dengan cara yang kompatibel dengan insentif. Pada tahun 2017-2019, ketika kami hanya memiliki bukti penipuan sebagai cara untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan yang aman, tetapi dengan munculnya SNARKs( bukti non-interaktif yang ringkas dan zero-knowledge), arsitektur Plasma menjadi lebih layak untuk skenario penggunaan yang lebih luas daripada sebelumnya.

Kemajuan lebih lanjut dalam sampling ketersediaan data

Apa masalah yang sedang kita selesaikan?

Pada 13 Maret 2024, ketika peningkatan Dencun diluncurkan, blockchain Ethereum memiliki 3 blob sekitar 125 kB setiap slot 12 detik, atau bandwidth data yang tersedia sekitar 375 kB per slot. Jika data transaksi diterbitkan langsung di rantai, maka transfer ERC20 sekitar 180 byte, sehingga maksimum TPS Rollup di Ethereum adalah: 375000 / 12 / 180 = 173.6 TPS.

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

Ini adalah peningkatan besar untuk Ethereum L1, tetapi belum cukup. Kami menginginkan lebih banyak skalabilitas. Tujuan jangka menengah kami adalah 16 MB per slot, dan 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 Ethereum, setiap blob adalah polinomial 4096 derajat di bidang bilangan prima (. Kami menyiarkan shares polinomial, di mana setiap shares berisi 16 nilai evaluasi dari 16 koordinat bersebelahan dari total 8192 koordinat. Dari 8192 nilai evaluasi ini, sembarang 4096 ) dapat memulihkan blob berdasarkan parameter yang diajukan saat ini: salah satu 64 dari 128 kemungkinan sampel (.

Cara kerja PeerDAS adalah agar setiap klien mendengarkan sejumlah kecil sub-jaringan, di mana sub-jaringan ke-i menyiarkan sampel ke-i dari setiap blob, dan dengan menanyakan kepada pihak-pihak sejawat di jaringan p2p global ) siapa yang akan mendengarkan sub-jaringan yang berbeda ( untuk meminta blob yang dibutuhkan di sub-jaringan lain. Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme sub-jaringan tanpa meminta tambahan dari lapisan sejawat. Proposal saat ini adalah agar node yang berpartisipasi dalam bukti kepemilikan menggunakan SubnetDAS, sementara node lainnya ) yaitu klien ( menggunakan PeerDAS.

Secara teori, kita dapat memperbesar skala "1D sampling" cukup besar: jika kita meningkatkan jumlah maksimum blob menjadi 256) dengan target 128(, maka kita dapat mencapai target 16MB, dan dengan sampling ketersediaan data, setiap node memiliki 16 sampel * 128 blob * setiap blob setiap sampel 512 byte = bandwidth data 1 MB per slot. Ini hanya sedikit berada dalam rentang toleransi kami: ini mungkin, tetapi ini berarti klien dengan bandwidth terbatas tidak dapat melakukan sampling. Kita dapat mengoptimalkan ini sampai batas tertentu dengan mengurangi jumlah blob dan meningkatkan ukuran blob, tetapi ini akan meningkatkan biaya rekonstruksi.

Oleh karena itu, kami akhirnya ingin melangkah lebih jauh, melakukan 2D sampling )2D sampling(, metode ini tidak hanya melakukan pengambilan sampel acak di dalam blob, tetapi juga melakukan pengambilan sampel acak antar blob. Dengan memanfaatkan atribut linear dari komitmen KZG, memperluas kumpulan blob dalam satu blok melalui satu set blob virtual baru, di mana blob virtual ini secara redundan mengkodekan informasi yang sama.

Penting untuk dicatat bahwa perhitungan komitmen yang diperluas tidak memerlukan blob, sehingga skema ini secara fundamental bersahabat dengan pembangunan blok terdistribusi. Nod yang benar-benar membangun blok hanya perlu memiliki komitmen KZG blob, dan mereka dapat mengandalkan pengambilan sampel ketersediaan data )DAS( untuk memverifikasi ketersediaan blok data. Pengambilan sampel ketersediaan data satu dimensi )1D DAS( pada dasarnya juga bersahabat dengan pembangunan blok terdistribusi.

![Vitalik baru: Masa depan Ethereum yang mungkin, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(

) Apa yang perlu dilakukan lagi? Apa saja pertimbangannya?

Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, secara bertahap meningkatkan jumlah blob di PeerDAS, sambil dengan hati-hati mengamati jaringan dan memperbaiki perangkat lunak untuk memastikan keamanan, ini adalah proses yang bertahap. Pada saat yang sama, kami berharap ada lebih banyak pekerjaan akademis untuk merumuskan PeerDAS dan versi DAS lainnya serta interaksi mereka dengan keamanan aturan pemilihan fork dan masalah lainnya.

Pada tahap yang lebih jauh di masa depan, kita perlu melakukan lebih banyak pekerjaan untuk menentukan versi ideal dari 2D DAS dan membuktikan atribut keamanannya. Kami juga berharap akhirnya dapat beralih dari KZG ke alternatif yang aman secara kuantum dan tidak memerlukan pengaturan tepercaya. Saat ini, kami belum jelas opsi mana yang ramah terhadap pembangunan blok terdistribusi. Bahkan dengan menggunakan teknologi "brute force" yang mahal, yaitu menggunakan STARK rekursif untuk menghasilkan bukti validitas yang digunakan untuk membangun ulang baris dan kolom, itu masih tidak cukup untuk memenuhi kebutuhan, karena meskipun secara teknis, ukuran satu STARK adalah O(log)n### * log(log(n)( hash ( menggunakan STIR), tetapi pada kenyataannya STARK hampir sebesar seluruh blob.

Saya pikir jalur realitas jangka panjang adalah:

1. Menerapkan DAS 2D yang ideal;
2. Tetap menggunakan 1D DAS, mengorbankan efisiensi bandwidth sampling, demi kesederhanaan dan ketahanan dengan menerima batas data yang lebih rendah.
3. Meninggalkan DA, sepenuhnya menerima Plasma sebagai arsitektur Layer2 utama yang menjadi perhatian kami.

Harap dicatat, bahkan jika kami memutuskan untuk memperluas eksekusi langsung di lapisan L1, pilihan ini tetap ada. Ini karena jika lapisan L1 harus menangani jumlah TPS yang besar, blok L1 akan menjadi sangat besar, dan klien akan menginginkan cara yang efisien untuk memverifikasi kebenarannya, oleh karena itu kami harus menggunakan teknologi yang sama di lapisan L1 seperti Rollup) seperti ZK-EVM dan DAS(.

) Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

Jika kompresi data diimplementasikan, permintaan untuk 2D DAS akan berkurang, atau setidaknya tertunda, dan jika Plasma digunakan secara luas, permintaan akan berkurang lebih lanjut. DAS juga menantang protokol dan mekanisme pembangunan blok terdistribusi: meskipun DAS secara teoritis ramah terhadap rekonstruksi terdistribusi, dalam praktiknya ini perlu dikombinasikan dengan proposal daftar inklusi paket dan mekanisme pemilihan fork di sekitarnya.

Kompresi Data

Apa masalah yang kita selesaikan?

Setiap transaksi dalam Rollup akan menggunakan banyak ruang data di blockchain: transfer ERC20 membutuhkan sekitar 180 byte. Bahkan dengan sampling ketersediaan data yang ideal, ini membatasi skalabilitas protokol Layer. Setiap slot 16 MB, kami mendapatkan:

16000000 / 12 / 180 = 7407 TPS

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

( Apa itu, bagaimana cara kerjanya?

Dalam kompresi byte nol, setiap rangkaian byte nol yang panjang digantikan dengan dua byte yang menunjukkan berapa banyak byte nol. Lebih jauh lagi, kami memanfaatkan atribut spesifik dari transaksi:

Agregasi Tanda Tangan: Kami beralih dari tanda tangan ECDSA ke tanda tangan BLS. Ciri khas tanda tangan BLS adalah beberapa tanda tangan dapat digabungkan menjadi satu tanda tangan tunggal, yang dapat membuktikan keabsahan semua tanda tangan asli. Di lapisan L1, karena meskipun dilakukan penggabungan, biaya komputasi verifikasi tetap tinggi, maka penggunaan tanda tangan BLS tidak dipertimbangkan. Namun, dalam lingkungan L2 yang kekurangan data seperti ini, penggunaan tanda tangan BLS menjadi masuk akal. Fitur agregasi ERC-4337 menyediakan jalur untuk mewujudkan fungsi ini.

Ganti alamat dengan pointers: Jika sebelumnya telah menggunakan alamat tertentu, kita bisa mengganti alamat 20-byte dengan pointer 4-byte yang mengarah ke posisi tertentu dalam riwayat.

Serialisasi Kustom Nilai Transaksi ------ Sebagian besar jumlah nilai transaksi memiliki sedikit digit, misalnya, 0,25 ETH dinyatakan 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 merepresentasikan sebagian besar nilai mata uang.

) Apa yang perlu dilakukan, apa saja pertimbangannya?

Langkah selanjutnya adalah mengimplementasikan rencana di atas. Pertimbangan utama termasuk:

1. Beralih ke tanda tangan BLS memerlukan upaya yang sangat besar, dan akan mengurangi kemampuan untuk meningkatkan keamanan.