Masa Depan Ethereum yang Mungkin: The Surge

Strategi skalabilitas Ethereum awalnya memiliki dua jenis: sharding dan protokol Layer2. Sharding memungkinkan setiap node hanya perlu memverifikasi dan menyimpan sebagian transaksi, sedangkan Layer2 membangun jaringan di atas Ethereum. Kedua strategi ini akhirnya bergabung, membentuk peta jalan yang berfokus pada Rollup, yang hingga kini masih menjadi strategi perluasan Ethereum.

Peta jalan yang berfokus pada Rollup mengusulkan pembagian kerja yang sederhana: Ethereum L1 berkonsentrasi menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 bertanggung jawab untuk membantu ekosistem berkembang. Pola ini umum ditemukan dalam masyarakat, seperti sistem pengadilan (L1) yang melindungi kontrak dan hak atas properti, para wirausahawan (L2) yang membangun di atas dasar ini.

Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai hasil penting: EIP-4844 blobs secara signifikan meningkatkan bandwidth data Ethereum L1, dan beberapa Ethereum Virtual Machine Rollup telah memasuki tahap pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika sendiri, dan keberagaman serta variasi cara implementasi shard 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. Mempertahankan desentralisasi dan ketahanan L1;
3. Setidaknya beberapa L2 sepenuhnya mewarisi atribut inti Ethereum ( yang tidak mempercayai, terbuka, dan tahan sensor );
4. Ethereum seharusnya terasa seperti ekosistem yang bersatu, bukan 34 blockchain yang berbeda.

Ringkasan Konten

1. Paradoks Segitiga Skalabilitas
2. Kemajuan lebih lanjut tentang pengambilan sampel ketersediaan data
3. Kompresi Data
4. Plasma Tergeneralisasi
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 rendah ), skalabilitas ( untuk memproses banyak transaksi ), dan keamanan ( di mana penyerang harus merusak proporsi node yang sangat besar agar sebuah transaksi tunggal gagal ).

Paradoks segitiga bukanlah teorema, dan posting yang memperkenalkannya juga tidak menyertakan bukti matematika. Ini memberikan argumen heuristik: jika node ramah yang terdesentralisasi dapat memverifikasi N transaksi per detik, Anda memiliki rantai yang memproses k*N transaksi per detik, maka: (i) setiap transaksi hanya dapat dilihat oleh 1/k node, penyerang hanya perlu merusak beberapa node untuk melakukan transaksi jahat, atau (ii) node Anda akan menjadi kuat, rantai tidak akan terdesentralisasi. Artikel ini tidak bertujuan untuk membuktikan bahwa memecahkan paradoks segitiga itu tidak mungkin, melainkan menunjukkan bahwa itu sulit, perlu keluar dari kerangka berpikir yang tersirat dalam argumen tersebut.

Selama bertahun-tahun, beberapa rantai berkinerja tinggi mengklaim telah menyelesaikan paradoks trilema tanpa mengubah arsitektur secara fundamental, biasanya dengan mengoptimalkan node melalui teknik rekayasa perangkat lunak. Ini selalu menyesatkan, menjalankan node di rantai ini lebih sulit daripada di Ethereum. Artikel ini akan membahas mengapa demikian, dan mengapa hanya bergantung pada rekayasa perangkat lunak klien L1 tidak dapat memperluas Ethereum.

Namun, pengambilan sampel ketersediaan data yang dikombinasikan dengan SNARKs memang menyelesaikan paradoks segitiga: ini memungkinkan klien hanya mengunduh sejumlah kecil data dan melakukan sedikit perhitungan untuk memverifikasi bahwa sejumlah data tersedia dan bahwa langkah-langkah perhitungan tertentu dieksekusi dengan benar. SNARKs tidak memerlukan kepercayaan. Pengambilan sampel ketersediaan data memiliki model kepercayaan few-of-N yang halus, tetapi mempertahankan karakteristik dasar dari rantai yang tidak dapat diskalakan, bahkan serangan 51% tidak dapat memaksa blok jahat diterima oleh jaringan.

Metode lain untuk mengatasi tiga tantangan tersebut adalah arsitektur Plasma, yang dengan cerdik mengalihkan tanggung jawab untuk memantau ketersediaan data kepada pengguna. Dari tahun 2017 hingga 2019, ketika kami hanya memiliki bukti penipuan untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan yang aman, tetapi dengan penyebaran SNARKs, arsitektur Plasma menjadi lebih layak untuk berbagai skenario penggunaan.

Kemajuan lebih lanjut dalam sampling ketersediaan data

Apa masalah yang sedang kita selesaikan?

Pada tanggal 13 Maret 2024, ketika upgrade Dencun diluncurkan, blockchain Ethereum memiliki 3 blob sekitar 125 kB setiap slot 12 detik, yaitu bandwidth data yang tersedia per 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

Ditambah dengan 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 menyediakan 463-926 TPS untuk calldata.

Ini adalah peningkatan besar untuk Ethereum L1, tetapi masih belum cukup. Kami menginginkan lebih banyak skalabilitas. Target jangka menengah adalah 16 MB per slot, yang dikombinasikan dengan perbaikan kompresi data Rollup, akan membawa ~58000 TPS.

Apa itu? Bagaimana cara kerjanya?

PeerDAS adalah implementasi relatif sederhana dari "1D sampling". Di Ethereum, setiap blob adalah polinomial dari 4096 dalam bidang bilangan prima 253. Kami menyiarkan shares polinomial, di mana setiap shares berisi 16 nilai evaluasi dari 16 koordinat yang berdekatan dari total 8192 koordinat. Dari 8192 nilai evaluasi ini, sembarang 4096 ( dapat memulihkan blob berdasarkan parameter proposal saat ini: 64 dari 128 kemungkinan sampel ).

Prinsip kerja PeerDAS adalah membuat setiap klien mendengarkan sejumlah kecil subnet, subnet ke-i mengumumkan sampel ke-i dari blob mana pun, dan dengan menanyakan kepada peer di jaringan p2p global ( siapa yang akan mendengarkan subnet yang berbeda ) untuk meminta blob lainnya yang dibutuhkannya di subnet lain. Versi yang lebih konservatif SubnetDAS hanya menggunakan mekanisme subnet, tanpa menanyakan lapisan peer tambahan. Proposal saat ini memungkinkan node yang berpartisipasi dalam proof of stake untuk menggunakan SubnetDAS, sementara node lainnya ( yaitu klien ) menggunakan PeerDAS.

Secara teori, kita dapat memperluas skala "1D sampling" dengan sangat besar: jika kita meningkatkan jumlah maksimum blob menjadi 256( dengan target 128), kita dapat mencapai target 16MB, sementara 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: mungkin, tetapi berarti klien yang dibatasi bandwidth tidak dapat melakukan sampling. Kita dapat mengoptimalkan 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, yang tidak hanya mengambil sampel secara acak di dalam blob, tetapi juga di antara blob. Dengan memanfaatkan atribut linier dari komitmen KZG, kami memperluas kumpulan blob dalam satu blok melalui kumpulan blob virtual baru, di mana blob virtual ini mengkodekan informasi yang sama secara redundan.

Penting untuk dicatat bahwa perpanjangan komitmen perhitungan tidak memerlukan blob, sehingga solusi ini secara fundamental ramah terhadap pembangunan blok terdistribusi. Node yang sebenarnya membangun blok hanya perlu memiliki komitmen KZG blob, yang dapat mereka andalkan untuk verifikasi ketersediaan data blok melalui sampling ketersediaan data. Sampling ketersediaan data satu dimensi pada dasarnya juga ramah terhadap pembangunan blok terdistribusi.

Apa yang perlu dilakukan lagi? Apa saja pertimbangannya?

Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, terus meningkatkan jumlah blob di PeerDAS, sambil memantau jaringan dengan cermat dan memperbaiki perangkat lunak untuk memastikan keamanan, ini adalah proses bertahap. Pada saat yang sama, kami berharap ada lebih banyak penelitian akademis untuk menstandarisasi PeerDAS dan versi DAS lainnya serta interaksinya dengan masalah keamanan seperti aturan pemilihan fork.

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

Saya pikir jalur realitas jangka panjang adalah:

1. Melaksanakan DAS 2D yang ideal;
2. Terus gunakan 1D DAS,牺牲 efisiensi bandwidth sampling, menerima batas data yang lebih rendah untuk kesederhanaan dan ketahanan.
3. Melepaskan DA, sepenuhnya menerima Plasma sebagai arsitektur Layer2 utama yang menjadi perhatian kami.

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

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 berkurang lebih lanjut. DAS juga menantang protokol dan mekanisme pembangunan blok terdistribusi: meskipun DAS secara teoritis ramah terhadap rekonstruksi terdistribusi, dalam praktiknya hal 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 menggunakan banyak ruang data di blockchain: Transaksi 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 molekul, tetapi juga menyelesaikan 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 panjang diganti dengan dua byte yang menunjukkan berapa banyak byte nol. Lebih lanjut, kami memanfaatkan atribut spesifik 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, yang dapat membuktikan validitas semua tanda tangan asli. Di lapisan L1, karena bahkan dengan agregasi, biaya komputasi 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.

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

Serialisasi nilai transaksi yang dapat disesuaikan: Sebagian besar nilai transaksi memiliki sedikit digit, misalnya, 0,25 Ether dinyatakan sebagai 250.000.000.000.000.000 wei. Biaya dasar maksimum dan biaya prioritas juga serupa. Oleh karena itu, kita dapat menggunakan format floating-point desimal yang disesuaikan untuk mewakili sebagian besar nilai mata uang.

Apa lagi yang perlu dilakukan, apa saja pertimbangannya?

Langkah selanjutnya adalah untuk benar-benar mengimplementasikan rencana yang disebutkan di atas. Pertimbangan utama termasuk:

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

2. Kompresi Dinamis ( Misalnya, mengganti alamat ) dengan pointer akan membuat kode klien menjadi lebih kompleks.

3. Menerbitkan perbedaan status di blockchain daripada transaksi, akan mengurangi kemampuan audit, sehingga banyak perangkat lunak ( seperti penjelajah blok ) tidak dapat berfungsi.

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

Menggunakan ERC-4337, dan akhirnya mengadopsi sebagian isinya