Masa Depan Ethereum yang Mungkin: The Surge

Peta jalan Ethereum awalnya mencakup dua strategi skalabilitas: sharding dan protokol Layer 2. Kedua jalur ini akhirnya bergabung menjadi peta jalan yang berfokus pada Rollup, yang masih menjadi strategi perluasan Ethereum saat ini.

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

Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai kemajuan penting: dengan peluncuran blob EIP-4844, bandwidth data Ethereum L1 meningkat drastis, dan beberapa Rollup mesin virtual Ethereum telah memasuki fase pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika sendiri, keberagaman dan multikulturalisme 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, 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. Menjaga desentralisasi dan ketahanan L1;

3. Setidaknya beberapa L2 sepenuhnya mewarisi atribut inti Ethereum ( yang dapat dipercaya, terbuka, dan tahan sensor );

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

Isi Bab Ini

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

Paradoks Segitiga Skalabilitas

Paradoks segitiga skala menganggap ada kontradiksi antara tiga karakteristik blockchain: desentralisasi ( biaya node operasional yang rendah ) skalabilitas ( jumlah transaksi yang dapat diproses banyak ) dan keamanan ( penyerang perlu menghancurkan sebagian besar node dalam jaringan untuk membuat transaksi tunggal 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 sejumlah kecil node untuk melewati transaksi jahat, atau (ii) node Anda akan menjadi kuat, sementara rantai Anda tidak akan terdesentralisasi. Tujuan artikel ini sama sekali bukan untuk membuktikan bahwa merobohkan paradoks segitiga tidak mungkin; sebaliknya, tujuannya adalah untuk menunjukkan bahwa merobohkan paradoks tiga adalah sulit, dan itu memerlukan untuk melampaui kerangka pemikiran yang diimplikasikan oleh argumen tersebut.

Selama bertahun-tahun, beberapa rantai berkinerja tinggi sering mengklaim bahwa mereka telah memecahkan 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 dibandingkan dengan menjalankan node di Ethereum.

Namun, penggabungan sampling ketersediaan data dengan SNARKs benar-benar menyelesaikan paradoks segitiga: ini memungkinkan klien untuk memverifikasi sejumlah data dapat diakses dengan hanya mengunduh sedikit 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 yang buruk diterima oleh jaringan.

Metode lain untuk mengatasi tiga tantangan adalah arsitektur Plasma, yang menggunakan teknologi cerdas untuk mendorong tanggung jawab data ketersediaan pengawasan kepada pengguna dengan cara yang kompatibel dengan insentif. Sejak 2017-2019, ketika kami hanya memiliki bukti penipuan sebagai satu-satunya cara untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan keamanan, tetapi dengan penyebaran SNARKs, arsitektur Plasma menjadi lebih layak untuk berbagai skenario penggunaan daripada sebelumnya.

Kemajuan lebih lanjut dalam sampling ketersediaan data

Masalah apa yang sedang kita selesaikan?

Pada 13 Maret 2024, ketika pembaruan Dencun diluncurkan, blockchain Ethereum memiliki 3 blob sekitar 125 kB setiap slot 12 detik, atau bandwidth data yang tersedia per slot sekitar 375 kB. Asumsikan data transaksi diterbitkan langsung di blockchain, 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. Dengan menggunakan PeerDAS, jumlah blob dapat meningkat menjadi 8-16, yang akan memberikan 463-926 TPS untuk calldata.

Ini adalah peningkatan besar untuk Ethereum L1, tetapi masih belum cukup. Kami menginginkan lebih banyak skalabilitas. Tujuan jangka menengah kami adalah 16 MB per slot, dan jika dikombinasikan dengan perbaikan kompresi data Rollup, ini 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 prima 253-bit. Kami menyiarkan shares polinomial, di mana setiap share berisi 16 nilai evaluasi dari 16 koordinat bersebelahan dari total 8192 koordinat. Dari 8192 nilai evaluasi ini, 4096 mana pun dari ( berdasarkan parameter yang diajukan saat ini: 64 dari 128 kemungkinan sampel mana pun dari ) dapat memulihkan blob.

Cara kerja PeerDAS adalah membuat 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 lain. Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa pertanyaan tambahan kepada lapisan rekan. Proposal saat ini adalah agar node yang berpartisipasi dalam proof of stake menggunakan SubnetDAS, sementara node lain ( yaitu klien ) menggunakan PeerDAS.

Secara teoritis, kita dapat memperluas skala "1D sampling" cukup besar: jika kita meningkatkan jumlah maksimum blob menjadi 256( dengan target 128), maka kita bisa 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 berada di batas toleransi kita: ini mungkin, tetapi itu berarti klien dengan bandwidth terbatas tidak dapat melakukan sampling. Kita bisa melakukan beberapa 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 dengan melakukan pengambilan sampel 2D, metode ini tidak hanya melakukan pengambilan sampel acak di dalam blob, tetapi juga di antara blob. Dengan memanfaatkan sifat linier dari komitmen KZG, kami memperluas kumpulan blob dalam satu blok dengan satu set blob virtual baru, yang secara redundan mengkodekan informasi yang sama.

Oleh karena itu, akhirnya kami ingin melangkah lebih jauh, melakukan pengambilan sampel 2D, yang tidak hanya dilakukan di dalam blob, tetapi juga melakukan pengambilan sampel acak di antara blob. Sifat linier dari komitmen KZG digunakan untuk memperluas kumpulan blob dalam sebuah blok, yang mencakup daftar blob virtual baru yang menyandi redundansi terhadap informasi yang sama.

Penting untuk dicatat bahwa perpanjangan komitmen kalkulasi tidak memerlukan blob, sehingga skema ini pada dasarnya ramah terhadap konstruksi 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 ramah terhadap konstruksi blok terdistribusi.

Apa yang perlu dilakukan lagi? Apa saja pertimbangannya?

Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, jumlah blob di PeerDAS akan terus ditambahkan, sembari mengamati jaringan dengan cermat dan memperbaiki perangkat lunak untuk memastikan keamanan, ini adalah proses yang bertahap. Sementara itu, kami berharap ada lebih banyak penelitian akademis untuk mengatur PeerDAS dan versi DAS lainnya serta interaksinya dengan masalah keamanan seperti aturan pemilihan fork.

Pada tahap yang lebih jauh di masa depan, kami perlu melakukan lebih banyak pekerjaan untuk menentukan versi ideal dari 2D DAS dan membuktikan sifat keamanannya. Kami juga berharap dapat akhirnya beralih dari KZG ke alternatif yang aman secara kuantum dan tidak memerlukan pengaturan yang dapat dipercaya. Saat ini, kami masih tidak 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 untuk membangun kembali baris dan kolom, itu masih tidak cukup untuk memenuhi kebutuhan, karena meskipun secara teknis ukuran satu STARK adalah O(log(n) * log(log(n)) nilai hash ( menggunakan STIR), tetapi pada kenyataannya STARK hampir sebesar seluruh blob.

Jalur realitas jangka panjang yang saya anggap adalah:

1. Menerapkan DAS 2D yang ideal;
2. Terus menggunakan 1D DAS,牺牲采样带宽效率, menerima batas data yang lebih rendah demi kesederhanaan dan ketahanan.
3. Melepaskan DA dan sepenuhnya menerima Plasma sebagai arsitektur Layer2 utama yang kami perhatikan.

Harap dicatat, meskipun 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, dan klien akan ingin memiliki cara yang efisien untuk memverifikasi kebenarannya, sehingga 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, dan jika Plasma digunakan secara luas, permintaan akan berkurang lebih lanjut. DAS juga menantang protokol dan mekanisme pembangunan blockchain terdistribusi: meskipun DAS secara teoritis ramah terhadap rekonstruksi terdistribusi, ini dalam praktiknya perlu dipadukan dengan proposal daftar inklusi paket dan mekanisme pemilihan fork di sekitarnya.

Kompresi Data

Apa masalah yang sedang kita selesaikan?

Setiap transaksi dalam Rollup akan memakan 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, 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, bagaimana cara kerjanya?

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

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

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

gunakan po