Masa Depan Ethereum yang Mungkin: The Surge

Peta jalan Ethereum awalnya memiliki dua strategi skalabilitas: sharding dan protokol Layer 2. Seiring dengan perkembangan penelitian, kedua jalur ini bergabung menjadi peta jalan yang berpusat pada Rollup, yang masih menjadi strategi ekspansi Ethereum saat ini.

Peta jalan yang berfokus pada Rollup mengusulkan pembagian kerja yang sederhana: Ethereum L1 berfokus pada menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 bertugas membantu ekosistem berkembang. Pola ini umum dalam masyarakat: keberadaan sistem pengadilan (L1) bukan untuk mengejar efisiensi, tetapi untuk melindungi kontrak dan hak milik, sementara para pengusaha (L2) membangun di atas dasar yang kokoh ini, mendorong perkembangan manusia.

Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai kemajuan penting: Peluncuran blob EIP-4844 secara signifikan meningkatkan bandwidth data Ethereum L1, dan beberapa EVM Rollup telah memasuki tahap pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika sendiri, dan keragaman implementasi shard kini telah menjadi kenyataan. Namun, jalan ini juga menghadapi beberapa tantangan unik. Tugas kami sekarang adalah menyelesaikan peta jalan yang berfokus pada Rollup, mengatasi masalah ini, sekaligus menjaga ketahanan dan desentralisasi khas Ethereum L1.

The Surge: Tujuan Kunci

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

Paradoks Segitiga Skalabilitas

Tritangga skala yang dapat diperluas berpendapat bahwa ada kontradiksi antara tiga karakteristik desentralisasi, skalabilitas, dan keamanan blockchain. Ini bukanlah sebuah teorema, melainkan sebuah pandangan heuristik. Selama bertahun-tahun, beberapa rantai berkinerja tinggi mengklaim telah menyelesaikan paradoks tiga sisi, tetapi ini sering kali menyesatkan.

Namun, kombinasi pengambilan sampel ketersediaan data dan SNARKs memang menyelesaikan paradoks segitiga: ini memungkinkan klien untuk memverifikasi sejumlah data yang tersedia dengan hanya mengunduh sejumlah kecil data dan melakukan sedikit perhitungan.

Salah satu cara untuk mengatasi tiga tantangan tersebut adalah dengan arsitektur Plasma, yang dengan cara yang kompatibel dengan insentif menyerahkan tanggung jawab untuk memantau ketersediaan data kepada pengguna. Dengan semakin populernya SNARKs, arsitektur Plasma menjadi lebih layak untuk digunakan dalam berbagai skenario.

Kemajuan lebih lanjut dalam sampling ketersediaan data

Apa masalah yang sedang kita selesaikan?

Setelah peningkatan Dencun diluncurkan pada 13 Maret 2024, Ethereum memiliki 3 blob sekitar 125 kB setiap slot 12 detik, atau bandwidth data yang tersedia per slot sekitar 375 kB. Jika data transaksi diterbitkan langsung di rantai, transfer ERC20 sekitar 180 byte, maka maksimum TPS Rollup di Ethereum adalah 173,6 TPS.

Dengan menambahkan calldata Ethereum, maka menjadi 607 TPS. Menggunakan PeerDAS, jumlah blob mungkin akan meningkat menjadi 8-16, yang akan memberikan 463-926 TPS untuk calldata.

Ini adalah peningkatan signifikan untuk Ethereum L1, tetapi masih belum cukup. Tujuan jangka menengah kami adalah setiap slot 16 MB, dan jika digabungkan 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 derajat 4096 di atas bidang bilangan prima 253. Kami menyiarkan shares polinomial, di mana setiap share berisi 16 nilai evaluasi dari 16 koordinat yang berdekatan dari total 8192 koordinat. Dari 8192 nilai evaluasi ini, 4096 mana pun dapat digunakan untuk memulihkan blob.

Cara kerja PeerDAS adalah memungkinkan setiap klien untuk mendengarkan sejumlah kecil subnet, di mana subnet ke-i menyiarkan sampel ke-i dari setiap blob, dan meminta blob yang dibutuhkan dari subnet lain dengan menanyakan peer dalam jaringan p2p global. Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa tambahan pertanyaan ke lapisan peer. Proposal saat ini adalah untuk membiarkan node yang berpartisipasi dalam proof of stake menggunakan SubnetDAS, sementara node lainnya menggunakan PeerDAS.

Secara teori, kita dapat meningkatkan skala "1D sampling" cukup besar: jika jumlah maksimum blob ditingkatkan menjadi 256, maka kita dapat mencapai target 16MB, sementara dalam sampling ketersediaan data, setiap node hanya memerlukan bandwidth data sebesar 1 MB per slot. Ini hanya hampir dalam batas toleransi kami: ini memungkinkan, tetapi ini berarti klien dengan bandwidth terbatas tidak dapat melakukan sampling. Kita dapat melakukan optimasi dengan mengurangi jumlah blob dan meningkatkan ukuran blob, tetapi ini akan membuat biaya rekonstruksi lebih tinggi.

Oleh karena itu, kami akhirnya ingin melangkah lebih jauh, melakukan sampling 2D, yang tidak hanya melakukan sampling acak di dalam blob, tetapi juga di antara blob. Dengan memanfaatkan sifat linier dari komitmen KZG, kami memperluas kumpulan blob dalam satu blok melalui sekelompok blob virtual baru, yang secara redundan mengkodekan informasi yang sama.

Sangat penting untuk dicatat bahwa perpanjangan komitmen tidak memerlukan blob, sehingga skema ini pada dasarnya bersahabat dengan pembangunan blok terdistribusi. Node yang benar-benar membangun blok hanya perlu memiliki komitmen KZG blob, dan mereka dapat mengandalkan sampling ketersediaan data (DAS) untuk memverifikasi ketersediaan blok data. Sampling ketersediaan data satu dimensi (1D DAS) pada dasarnya juga bersahabat dengan pembangunan blok terdistribusi.

Apa lagi yang perlu dilakukan? Apa saja pertimbangannya?

Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, jumlah blob di PeerDAS akan terus meningkat, sambil secara cermat 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 menstandarkan PeerDAS dan versi DAS lainnya serta interaksinya dengan masalah keamanan seperti aturan pemilihan fork.

Di 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 dapat akhirnya beralih dari KZG ke alternatif yang aman kuantum dan tidak memerlukan pengaturan yang tepercaya. Saat ini, kami juga tidak jelas tentang kandidat mana yang ramah terhadap pembangunan blok terdistribusi.

Jalur realitas jangka panjang yang saya pikirkan adalah:

1. Menerapkan DAS 2D yang ideal;
2. Terus menggunakan 1D DAS, mengorbankan efisiensi bandwidth sampling, demi kesederhanaan dan ketahanan menerima batas data yang lebih rendah.
3. Meninggalkan DA, sepenuhnya menerima Plasma sebagai arsitektur Layer2 utama yang menjadi fokus 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 sejumlah besar TPS, blok L1 akan menjadi sangat besar, klien akan menginginkan cara yang efisien untuk memverifikasi keakuratan mereka, 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 diterapkan, permintaan untuk 2D DAS akan berkurang, atau setidaknya akan tertunda. Jika Plasma digunakan secara luas, permintaan akan berkurang lebih lanjut. DAS juga menghadapi tantangan terhadap 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

Masalah apa yang kita selesaikan?

Setiap transaksi dalam Rollup akan menggunakan banyak ruang data di on-chain: transfer ERC20 memerlukan sekitar 180 byte. Bahkan dengan sampel ketersediaan data yang ideal, ini membatasi skalabilitas protokol Layer. Setiap slot 16 MB, kita mendapatkan:

16000000 / 12 / 180 = 7407 TPS

Jika kita tidak hanya dapat menyelesaikan masalah pembilang, tetapi juga masalah penyebut, dan membuat setiap transaksi dalam Rollup menggunakan lebih sedikit byte di blockchain, bagaimana jadinya?

Apa itu dan bagaimana cara kerjanya?

Dalam kompresi byte nol, dua byte digunakan untuk menggantikan setiap urutan byte nol yang panjang, menunjukkan berapa banyak byte nol. Lebih lanjut, kami memanfaatkan atribut khusus dari transaksi:

Agregasi tanda tangan: Kami beralih dari tanda tangan ECDSA ke tanda tangan BLS. Ciri 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 agregasi dilakukan, biaya komputasi verifikasi masih tinggi, maka penggunaan tanda tangan BLS tidak dipertimbangkan. Namun, di L2, di mana data langka, penggunaan tanda tangan BLS adalah masuk akal. Fitur agregasi ERC-4337 memberikan jalan untuk mewujudkan fungsi ini.

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

Serialisasi kustom nilai transaksi: Sebagian besar digit nilai transaksi sangat sedikit, 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 lagi yang perlu dilakukan, apa saja pertimbangannya?

Langkah selanjutnya yang harus dilakukan adalah menerapkan rencana di atas. Pertimbangan utama termasuk:

1. Beralih ke tanda tangan BLS memerlukan usaha yang besar, dan akan mengurangi kompatibilitas dengan chip perangkat keras tepercaya yang dapat meningkatkan keamanan. Solusi ZK-SNARK yang menggunakan skema tanda tangan lain dapat digunakan sebagai penggantinya.

2. Kompresi dinamis ( Misalnya, mengganti alamat ) dengan pointers akan membuat kode klien menjadi rumit.

3. Mempublikasikan perbedaan status ke dalam rantai alih-alih transaksi, akan mengurangi kemampuan audit, dan membuat banyak perangkat lunak ( seperti penjelajah blok ) tidak dapat berfungsi.

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

Dengan mengadopsi ERC-4337 dan akhirnya mengintegrasikan sebagian kontennya ke dalam L2 EVM, dapat secara signifikan mempercepat penerapan teknologi agregasi. Menempatkan sebagian konten ERC-4337 di L1 dapat mempercepat penerapannya di L2.

Plasma Tergeneral

Apa masalah yang sedang kita selesaikan?

Bahkan dengan menggunakan blob 16 MB dan kompresi data, 58.000 TPS mungkin tidak cukup untuk sepenuhnya memenuhi kebutuhan pembayaran konsumen, sosial terdesentralisasi, atau bidang bandwidth tinggi lainnya, terutama ketika kita mulai mempertimbangkan faktor privasi, yang dapat mengurangi skalabilitas hingga 3-8 kali. Untuk skenario aplikasi dengan volume transaksi tinggi dan nilai rendah, saat ini