The Surge: Masa Depan Skalabilitas Ethereum

Dalam peta jalan Ethereum, awalnya ada dua strategi skalabilitas: sharding dan protokol Layer 2. Kedua strategi ini akhirnya bergabung, membentuk peta jalan yang berfokus pada Rollup, yang hingga saat ini masih merupakan strategi perluasan Ethereum.

Peta jalan yang berpusat pada Rollup mengusulkan pembagian kerja yang sederhana: Ethereum L1 fokus pada menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 mengambil tugas untuk membantu ekosistem berkembang. Pola ini ada di mana-mana dalam masyarakat: keberadaan sistem pengadilan (L1) adalah untuk melindungi kontrak dan hak milik, sementara para pengusaha (L2) membangun di atas dasar ini, mendorong umat manusia maju.

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 EVM Rollup telah memasuki fase pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika sendiri, dan keragaman serta variasi cara implementasi shard kini telah menjadi kenyataan. Namun, mengikuti jalur ini juga menghadapi beberapa tantangan unik. Oleh karena itu, tugas kami sekarang adalah menyelesaikan peta jalan yang berfokus pada Rollup, menyelesaikan masalah ini, sambil menjaga ketahanan dan desentralisasi 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 memerlukan kepercayaan, terbuka, tahan sensor );
4. Ethereum harus terasa seperti ekosistem yang terpadu, bukan 34 blockchain yang berbeda.

Isi Bab Ini

1. Paradoks Segitiga Skalabilitas
2. Kemajuan lebih lanjut dalam sampling ketersediaan data
3. Kompresi data
4. Plasma Generalisasi
5. Sistem Bukti L2 yang Matang
6. Peningkatan Interoperabilitas L2
7. Memperluas eksekusi di L1

Paradoks Segitiga Skalabilitas

Paradoks segitiga skalabilitas berpendapat bahwa terdapat kontradiksi antara tiga karakteristik blockchain: desentralisasi ( biaya node yang berjalan rendah ), skalabilitas ( jumlah transaksi yang diproses banyak ) dan keamanan ( penyerang perlu merusak sebagian besar node di jaringan untuk membuat satu transaksi gagal ).

Perlu dicatat bahwa paradoks segitiga bukanlah sebuah teorema, dan pos yang memperkenalkan paradoks segitiga juga tidak disertai dengan bukti matematis. Ini memberikan argumen matematis heuristik: jika sebuah node yang ramah terhadap desentralisasi dapat memverifikasi N transaksi per detik, dan Anda memiliki sebuah rantai yang dapat memproses k*N transaksi per detik, maka (i) setiap transaksi hanya dapat dilihat oleh 1/k node, yang berarti penyerang hanya perlu merusak sedikit node untuk melakukan transaksi jahat, atau (ii) node Anda akan menjadi kuat, sementara rantai Anda tidak akan terdesentralisasi. Tujuan artikel ini sama sekali bukan untuk membuktikan bahwa memecahkan paradoks segitiga adalah tidak mungkin; sebaliknya, ini bertujuan untuk menunjukkan bahwa memecahkan paradoks tiga arah itu sulit, dan membutuhkan untuk melampaui kerangka pemikiran yang terkandung dalam argumen tersebut.

Selama bertahun-tahun, beberapa rantai berkinerja tinggi sering mengklaim bahwa mereka telah menyelesaikan 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. Artikel ini akan membahas mengapa hal ini terjadi, dan mengapa hanya dengan rekayasa perangkat lunak klien L1 saja tidak dapat memperluas Ethereum?

Namun, kombinasi sampling ketersediaan data dan SNARKs memang menyelesaikan paradoks segitiga: ini memungkinkan klien untuk memverifikasi sejumlah data tersedia dengan hanya mengunduh sejumlah kecil data dan melakukan sedikit perhitungan. 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 diterima oleh jaringan.

Cara lain untuk mengatasi tiga tantangan adalah arsitektur Plasma, yang menggunakan teknologi cerdas untuk mendorong tanggung jawab ketersediaan data pemantauan kepada pengguna dengan cara yang kompatibel dengan insentif. Sejak tahun 2017-2019, ketika kami hanya memiliki bukti penipuan sebagai cara untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan yang aman. Namun, dengan meningkatnya popularitas SNARKs, arsitektur Plasma menjadi lebih layak untuk digunakan dalam lebih banyak skenario 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 akan memiliki 3 blob sekitar 125 kB setiap slot 12 detik, atau bandwidth data yang tersedia untuk setiap slot sekitar 375 kB. Jika data transaksi diterbitkan langsung di blockchain, transfer ERC20 sekitar 180 byte, maka 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 dapat meningkat menjadi 8-16, yang akan memberikan 463-926 TPS untuk calldata.

Ini adalah peningkatan signifikan untuk Ethereum L1, tetapi belum cukup. Kami menginginkan lebih banyak skalabilitas. Tujuan jangka menengah kami adalah 16 MB per slot, dan jika digabungkan dengan perbaikan kompresi data Rollup, akan menghasilkan ~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, sembarang 4096 dari ( berdasarkan parameter yang diajukan saat ini: sembarang 64 dari 128 kemungkinan sampel ) dapat memulihkan blob.

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

Secara teori, kami dapat memperluas skala "1D sampling" cukup besar: jika kami meningkatkan jumlah maksimum blob menjadi 256( dengan target 128), maka kami dapat mencapai target 16MB, dan dalam 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 batas toleransi kami: ini mungkin, tetapi berarti klien dengan bandwidth terbatas tidak dapat melakukan sampling. Kami dapat mengoptimalkan ini sampai batas tertentu 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 untuk melakukan sampling 2D, metode ini tidak hanya melakukan sampling acak di dalam blob, tetapi juga melakukan sampling acak di antara blob. Dengan memanfaatkan sifat linier dari komitmen KZG, sebuah set blob baru yang virtual diperluas di dalam satu blok, di mana blob virtual ini redundan mengkodekan informasi yang sama.

Sangat penting bahwa perhitungan komitmen untuk perluasan 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 pengambilan sampel ketersediaan data untuk memverifikasi ketersediaan blok data. Pengambilan sampel ketersediaan data satu dimensi 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 mengamati jaringan dengan cermat dan memperbaiki perangkat lunak untuk memastikan keamanan, ini adalah proses yang bertahap. Pada saat yang sama, kami berharap ada lebih banyak penelitian akademis untuk mengatur PeerDAS dan versi DAS lainnya serta interaksi mereka dengan masalah keamanan seperti aturan pemilihan fork.

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 masih tidak jelas tentang kandidat 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 kembali baris dan kolom, itu tidak cukup untuk memenuhi kebutuhan, karena meskipun secara teknis, ukuran satu STARK adalah O(log(n) * log(log(n)) hash ( menggunakan STIR), tetapi sebenarnya STARK hampir sebesar seluruh blob.

Jalan realitas jangka panjang yang saya pikirkan adalah:

1. Melaksanakan DAS 2D yang ideal;
2. Tetap gunakan 1D DAS,牺牲采样带宽效率, menerima batas atas data yang lebih rendah demi kesederhanaan dan ketahanan.
3. Melepaskan 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 banyak TPS, blok L1 akan menjadi sangat besar, 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 akan tertunda. Jika Plasma digunakan secara luas, permintaan akan semakin berkurang. DAS juga menantang protokol dan mekanisme pembangunan blok terdistribusi: meskipun DAS secara teoritis bersahabat dengan 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 chain: 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, dan membuat setiap transaksi dalam Rollup menggunakan lebih sedikit byte di blockchain, bagaimana jadinya?

Apa itu, bagaimana cara kerjanya?

Dalam kompresi byte nol, setiap urutan byte nol panjang diganti dengan dua byte yang menunjukkan berapa banyak byte nol. Lebih lanjut, kami memanfaatkan atribut spesifik dari transaksi:

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

Ganti alamat dengan pointer: Jika Anda pernah menggunakan alamat tertentu, kita dapat mengganti alamat 20 byte dengan pointer 4 byte yang mengarah ke lokasi tertentu dalam riwayat.

Serialisasi kustom nilai transaksi ------ Sebagian besar nilai transaksi memiliki sedikit digit, misalnya, 0,25 ETH diwakili sebagai 250