Masa Depan Ethereum yang Mungkin: The Surge

The Surge: Target Utama

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 (tidak mempercayai, terbuka, 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 yang Digenalisasi
5. Sistem bukti L2 yang matang
6. Peningkatan interoperabilitas L2
7. Memperluas eksekusi di L1

Paradoks Segitiga Skalabilitas

Paradoks segitiga skalabilitas adalah sebuah gagasan 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 menyertakan bukti matematis. Ini memang memberikan argumen matematis heuristik: jika sebuah node yang ramah terhadap desentralisasi (misalnya, laptop konsumsi) dapat memverifikasi N transaksi per detik, dan Anda memiliki 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 melakukan transaksi jahat, atau (ii) node Anda akan menjadi kuat, sementara rantai Anda tidak akan terdesentralisasi. Tujuan artikel ini bukanlah untuk membuktikan bahwa memecahkan paradoks segitiga adalah mustahil; sebaliknya, ini bertujuan untuk menunjukkan bahwa memecahkan paradoks tiga unsur adalah sulit, dan itu perlu melampaui kerangka berpikir yang diimplikasikan oleh argumen tersebut.

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

Namun, kombinasi pengambilan sampel ketersediaan data dengan SNARKs memang menyelesaikan paradoks segitiga: hal ini memungkinkan klien untuk memverifikasi sejumlah data yang tersedia dengan hanya mengunduh sejumlah kecil data dan melakukan sangat sedikit komputasi. 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, yaitu bahkan serangan 51% tidak dapat memaksa blok buruk diterima oleh jaringan.

Salah satu cara lain untuk mengatasi tiga tantangan adalah arsitektur Plasma, yang menggunakan teknologi canggih 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 satu-satunya cara untuk memperluas kemampuan komputasi, Plasma sangat terbatas dalam pelaksanaan yang aman, tetapi dengan munculnya SNARKs (bukti nol pengetahuan yang ringkas dan non-interaktif), arsitektur Plasma menjadi lebih layak untuk digunakan dalam berbagai skenario dibandingkan sebelumnya.

Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data

Apa masalah 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. Jika data transaksi diterbitkan langsung di rantai, maka transfer ERC20 sekitar 180 byte, sehingga maksimal TPS Rollup di Ethereum adalah: 375000 / 12 / 180 = 173.6 TPS

Jika kita menambahkan calldata Ethereum (nilai maksimum teoritis: setiap slot 30 juta Gas / per 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 masih belum cukup. Kami menginginkan lebih banyak skalabilitas. Tujuan menengah kami adalah setiap slot 16 MB, 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 Ethereum, setiap blob adalah polinomial derajat 4096 di atas bidang prima (prime field) 253 bit. 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 (berdasarkan parameter yang diajukan saat ini: 64 dari 128 sampel yang mungkin) dapat memulihkan blob.

Cara kerja PeerDAS adalah membuat setiap klien mendengarkan sejumlah subnet yang sedikit, di mana subnet ke-i menyiarkan sampel ke-i dari blob mana pun, dan meminta blob yang diperlukan dari subnet lain dengan menanyakan kepada para peer di jaringan p2p global (siapa yang akan mendengarkan subnet yang berbeda). Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa meminta tambahan dari lapisan peer. 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 memperbesar skala "1D sampling" cukup besar: jika kita meningkatkan jumlah maksimum blob menjadi 256 (target 128), maka 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 kami: ini mungkin dilakukan, tetapi ini berarti klien dengan bandwidth terbatas tidak dapat melakukan sampling. Kita dapat melakukan beberapa optimasi dengan mengurangi jumlah blob dan meningkatkan ukuran blob, tetapi ini akan meningkatkan biaya rekonstruksi.

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

Oleh karena itu, pada akhirnya kami ingin melangkah lebih jauh dengan melakukan sampling 2D, yang tidak hanya melakukan sampling acak di dalam blob, tetapi juga di antara blob. Sifat linier dari komitmen KZG digunakan untuk memperluas kumpulan blob dalam satu blok, yang berisi daftar blob virtual baru yang melakukan pengkodean redundan terhadap informasi yang sama.

Sangat penting untuk dicatat bahwa perluasan komitmen perhitungan 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 bergantung pada 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 ditambahkan, sambil mengamati jaringan dan meningkatkan perangkat lunak untuk memastikan keamanan, ini adalah proses yang bertahap. Sementara itu, kami berharap ada lebih banyak pekerjaan akademis untuk merumuskan PeerDAS dan versi DAS lainnya serta interaksinya 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 sifat keamanannya. Kami juga berharap dapat akhirnya beralih dari KZG ke alternatif yang aman secara kuantum dan tidak memerlukan pengaturan yang tepercaya. Saat ini, kami masih belum 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 masih tidak cukup untuk memenuhi kebutuhan, karena meskipun secara teknis, ukuran satu STARK adalah O(log(n) * log(log(n)) hash (menggunakan STIR), namun pada kenyataannya STARK hampir sebesar seluruh blob.

Saya percaya bahwa jalur realitas jangka panjang adalah:

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

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

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Jika kompresi data diterapkan, 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 teoritis ramah terhadap 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 menghabiskan banyak ruang data di on-chain: 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 bisa menyelesaikan masalah pembilang, tetapi juga masalah penyebut, bagaimana jika setiap transaksi dalam Rollup menggunakan lebih sedikit byte di blockchain?

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 lanjut, kami memanfaatkan atribut spesifik 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 keabsahan semua tanda tangan asli. Di lapisan L1, karena meskipun dilakukan agregasi, biaya komputasi verifikasi masih cukup tinggi, sehingga penggunaan tanda tangan BLS tidak dipertimbangkan. Namun, dalam lingkungan L2 yang kekurangan data seperti ini, penggunaan tanda tangan BLS adalah masuk akal. Fitur agregasi ERC-4337 menyediakan jalur untuk mewujudkan fungsi ini.

Ganti alamat dengan pointer: Jika sebelumnya telah menggunakan alamat tertentu, kita dapat mengganti alamat 20 byte dengan pointer 4 byte yang menunjuk ke suatu lokasi dalam riwayat.

Kustomisasi serialisasi nilai transaksi------Sebagian besar nilai transaksi memiliki sedikit digit, misalnya, 0,25 ETH dinyatakan sebagai 250.000.000.000.000.000 wei. Maksimum dasar tangan