Masa Depan Ethereum yang Mungkin: The Surge

The Surge: Sasaran 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 (tanpa kepercayaan, terbuka, anti-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 Umum
5. Sistem Bukti L2 yang Matang
6. Peningkatan Interoperabilitas L2
7. Memperluas eksekusi di L1

Paradoks Segitiga Skalabilitas

Paradoks segitiga skalabilitas adalah sebuah ide yang diajukan pada tahun 2017, yang berpendapat bahwa terdapat kontradiksi antara tiga karakteristik blockchain: desentralisasi (lebih spesifik: biaya menjalankan node yang rendah), skalabilitas (jumlah transaksi yang dapat diproses banyak), dan keamanan (penyerang perlu merusak sebagian besar node dalam jaringan agar satu transaksi gagal).

Perlu dicatat bahwa paradoks segitiga bukanlah sebuah teorema, dan pos yang memperkenalkan paradoks segitiga juga tidak disertai dengan bukti matematis. Ini memang memberikan argumen matematis heuristik: jika sebuah node yang ramah terhadap desentralisasi (misalnya laptop kelas konsumen) 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 merusak sejumlah kecil node untuk memanipulasi sebuah transaksi yang berbahaya, 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 itu tidak mungkin; sebaliknya, ini bertujuan untuk menunjukkan bahwa memecahkan paradoks tiga arah itu sulit, dan perlu semacam pemikiran di luar kerangka argumen yang tersirat.

Selama bertahun-tahun, beberapa rantai berkinerja tinggi sering mengklaim bahwa mereka telah menyelesaikan trilema tanpa mengubah arsitektur secara mendasar, biasanya dengan menerapkan teknik rekayasa perangkat lunak untuk mengoptimalkan node. Ini selalu menyesatkan, karena menjalankan node di rantai ini jauh lebih sulit daripada menjalankan node di Ethereum. Artikel ini akan mengeksplorasi mengapa hal ini demikian, dan mengapa hanya dengan rekayasa perangkat lunak klien L1 saja tidak dapat memperluas Ethereum?

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

Metode lain untuk menyelesaikan tiga dilema 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 kita hanya memiliki bukti penipuan sebagai cara untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan yang aman, tetapi dengan berkembangnya SNARKs (bukti nol pengetahuan yang ringkas dan non-interaktif), arsitektur Plasma menjadi lebih layak untuk digunakan dalam skenario yang lebih luas daripada sebelumnya.

Kemajuan lebih lanjut dalam Sampling Ketersediaan Data

Masalah apa yang sedang kita selesaikan?

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

Jika kita tambahkan calldata (nilai maksimum teoritis: setiap slot 30 juta Gas / per 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 L1, tetapi masih belum cukup. Kami menginginkan lebih banyak skalabilitas. Tujuan jangka menengah kami adalah 16 MB per slot, yang jika dikombinasikan dengan perbaikan kompresi data Rollup, akan menghasilkan ~58000 TPS.

Apa itu? Bagaimana cara kerjanya?

PeerDAS adalah implementasi yang relatif sederhana dari "1D sampling". Di dalamnya, setiap blob adalah polinomial 4096 derajat di atas bidang prima 253 bit. Kami menyiarkan bagian-bagian polinomial, di mana setiap bagian berisi 16 nilai evaluasi dari 16 koordinat yang berdekatan di antara total 8192 koordinat. Dari 8192 nilai evaluasi ini, 4096 mana pun (berdasarkan parameter yang diajukan saat ini: 64 dari 128 kemungkinan sampel) dapat memulihkan blob.

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

Secara teori, kita dapat menskalakan "1D sampling" cukup besar: jika kita meningkatkan jumlah maksimum blob menjadi 256 (target 128), maka kita dapat mencapai target 16MB, di mana setiap node dalam sampling ketersediaan data 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 berarti klien dengan bandwidth terbatas tidak dapat melakukan sampling. Kita dapat mengoptimalkan ini hingga tingkat 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 dengan melakukan pengambilan sampel 2D (2D sampling), metode ini tidak hanya melakukan pengambilan sampel secara acak di dalam blob, tetapi juga di antara blob. Dengan memanfaatkan sifat linier dari komitmen KZG, kami memperluas kumpulan blob dalam sebuah blok dengan sekelompok 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 melakukan pengambilan sampel acak di dalam blob, tetapi juga antara blob. Sifat linier dari komitmen KZG digunakan untuk memperluas kumpulan blob dalam satu blok, yang berisi daftar blob virtual baru yang melakukan pengodean redundansi pada informasi yang sama.

Yang sangat penting adalah bahwa perhitungan komitmen perluasan tidak memerlukan blob, sehingga skema ini secara fundamental ramah terhadap pembangunan blok terdistribusi. Node yang benar-benar membangun blok hanya perlu memiliki komitmen blob KZG, 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 ramah terhadap 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 ditambahkan, 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 pekerjaan akademis untuk mengatur PeerDAS dan versi lain dari DAS serta interaksinya dengan masalah keamanan seperti aturan pemilihan fork.

Dalam tahap yang lebih jauh di masa depan, kita perlu melakukan lebih banyak pekerjaan untuk menentukan versi ideal dari 2D DAS dan membuktikan sifat keamanannya. Kami juga berharap akhirnya dapat beralih dari KZG ke alternatif yang aman secara kuantum dan tidak memerlukan pengaturan yang dapat dipercaya. 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 untuk membangun kembali baris dan kolom, itu pun masih belum cukup 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.

Saya percaya jalur realitas jangka panjang adalah:

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

Harap dicatat bahwa 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 menginginkan cara yang efisien untuk memverifikasi keabsahannya, sehingga kami akan terpaksa 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 blok terdistribusi: meskipun DAS secara teori ramah terhadap rekonstruksi terdistribusi, ini dalam praktiknya memerlukan penggabungan dengan proposal daftar inklusi paket dan mekanisme pemilihan fork di sekitarnya.

Kompresi Data

Apa masalah yang 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 numerator, tetapi juga masalah denominator, bagaimana jika setiap transaksi di dalam Rollup menggunakan lebih sedikit byte di blockchain?

Apa itu, dan bagaimana cara kerjanya?

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

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

Agregasi tanda tangan: Kami beralih dari tanda tangan ECDSA ke tanda tangan BLS, yang memiliki karakteristik bahwa beberapa tanda tangan dapat digabungkan menjadi satu tanda tangan tunggal yang dapat membuktikan kevalidan semua tanda tangan asli. Di lapisan L1, meskipun agregasi dilakukan, biaya komputasi verifikasi tetap cukup tinggi, sehingga 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 memberikan jalan untuk mewujudkan fungsi ini.