Masa Depan Ethereum: The Surge

Paradox Segitiga Skalabilitas

Paradoks segitiga skalabilitas menganggap bahwa terdapat kontradiksi antara tiga karakteristik blockchain: desentralisasi, skalabilitas, dan keamanan. Ini bukanlah teorema yang ketat, melainkan mengajukan argumen matematis heuristik: jika sebuah node yang ramah desentralisasi dapat memverifikasi N transaksi per detik, dan Anda memiliki sebuah rantai yang dapat memproses k*N transaksi per detik, maka setiap transaksi hanya dapat dilihat oleh 1/k node, yang berarti penyerang hanya perlu merusak beberapa node untuk berhasil melakukan transaksi jahat; atau node Anda akan menjadi kuat, dan rantai Anda tidak akan terdesentralisasi.

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, menjalankan node di rantai ini jauh lebih sulit daripada menjalankan node di Ethereum.

Namun, kombinasi sampling ketersediaan data dengan SNARKs benar-benar menyelesaikan paradoks segitiga: ini memungkinkan klien untuk memverifikasi sejumlah data tersedia 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 jahat diterima oleh jaringan.

Metode lain untuk mengatasi tiga tantangan adalah arsitektur Plasma, yang menggunakan teknologi cerdas untuk mendorong tanggung jawab pemantauan ketersediaan data kepada pengguna dengan cara yang kompatibel dengan insentif. Dengan meningkatnya popularitas SNARKs, arsitektur Plasma menjadi lebih layak untuk berbagai skenario penggunaan dibandingkan sebelumnya.

Kemajuan lebih lanjut dari sampling ketersediaan data

Masalah apa yang sedang kita selesaikan?

Pada tanggal 13 Maret 2024, saat upgrade 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 dipublikasikan langsung di rantai, maka transfer ERC20 sekitar 180 byte, sehingga maksimum TPS Rollup di Ethereum adalah: 375000 / 12 / 180 = 173,6 TPS.

Jika kita menambahkan calldata Ethereum, 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 ingin lebih banyak skalabilitas. Tujuan 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 di antara total 8192 koordinat. Dari 8192 nilai evaluasi ini, sembarang 4096 dapat memulihkan blob.

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

Secara teoritis, kita dapat memperluas skala "1D sampling" cukup besar: jika kita meningkatkan jumlah maksimum blob menjadi 256, maka kita dapat mencapai target 16MB, sementara di setiap node dalam sampling ketersediaan data terdapat 16 sampel * 128 blob * setiap blob setiap sampel 512 byte = bandwidth data 1 MB per slot. Ini hanya sedikit di dalam batas toleransi kita: ini memungkinkan, 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 membuat biaya rekonstruksi lebih tinggi.

Oleh karena itu, kami akhirnya ingin melangkah lebih jauh dengan melakukan sampling 2D, metode ini tidak hanya melakukan sampling acak di dalam blob, tetapi juga melakukan sampling acak antar 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.

Yang terpenting, perhitungan komitmen ekspansi tidak memerlukan blob, sehingga skema ini pada dasarnya ramah terhadap pembangunan blok terdistribusi. Node yang benar-benar membangun blok hanya perlu memiliki komitmen KZG blob, dan mereka dapat mengandalkan sampling ketersediaan data untuk memverifikasi ketersediaan blok 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, jumlah blob di PeerDAS akan terus meningkat, sambil dengan cermat mengamati jaringan 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 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 atribut keamanannya. Kami juga berharap pada akhirnya dapat beralih dari KZG ke solusi alternatif yang aman terhadap kuantum dan tidak memerlukan pengaturan yang dapat dipercaya. Saat ini, kami masih tidak jelas opsi mana yang ramah untuk 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 juga tidak cukup untuk memenuhi kebutuhan, karena meskipun secara teknis, ukuran STARK adalah O(log(n) * log(log(n)) hash, tetapi pada kenyataannya STARK hampir sebesar seluruh blob.

Menurut saya, jalur realitas jangka panjang adalah:

1. Menerapkan DAS 2D yang ideal;
2. Terus menggunakan 1D DAS,牺牲采样带宽效率,为了简单性和鲁棒性而接受较低的数据上限
3. Mengabaikan DA, sepenuhnya menerima Plasma sebagai arsitektur Layer2 utama yang kami perhatikan.

Harap diperhatikan, bahkan jika 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 kebenarannya, sehingga kami harus menggunakan teknologi yang sama dengan Rollup 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 ini perlu digabungkan 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 blockchain: Transaksi ERC20 membutuhkan sekitar 180 byte. Bahkan dengan pengambilan 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, dan membuat setiap transaksi di setiap Rollup menggunakan lebih sedikit byte di blockchain, bagaimana hasilnya?

Apa itu, bagaimana cara kerjanya?

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

Dalam kompresi byte nol, setiap deretan byte nol yang panjang digantikan dengan dua byte yang menunjukkan berapa banyak byte nol yang ada. Lebih lanjut, kami memanfaatkan sifat spesifik dari 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 tunggal, dan tanda tangan ini dapat membuktikan keabsahan semua tanda tangan asli. Di lapisan L1, karena bahkan dengan agregasi, biaya komputasi untuk verifikasi tetap tinggi, maka penggunaan tanda tangan BLS tidak dipertimbangkan. Namun, dalam lingkungan L2 yang memiliki kekurangan data, penggunaan tanda tangan BLS adalah masuk akal. Fitur agregasi ERC-4337 menyediakan cara 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 posisi tertentu dalam riwayat.

Serialisasi kustom nilai transaksi------Sebagian besar nilai transaksi memiliki sedikit digit, misalnya, 0,25 ETH 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 kustom untuk mewakili sebagian besar nilai mata uang.

Apa yang perlu dilakukan lagi, apa saja pertimbangannya?

Langkah selanjutnya adalah mengimplementasikan rencana di atas. Pertimbangan utama termasuk:

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

2、kompresi dinamis ( misalnya, mengganti alamat ) dengan pointers akan membuat kode klien menjadi kompleks.

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

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

Menggunakan ERC-4337 dan akhirnya mengintegrasikan sebagian kontennya ke dalam L2 EVM dapat secara signifikan mempercepat penerapan teknologi agregasi. Menempatkan sebagian konten ERC-4337 di L1 dapat mempercepat penerapannya di L2.

Plasma Umum

Masalah apa yang sedang kita selesaikan?

Bahkan dengan penggunaan blob 16 MB dan kompresi data, 58.000 TPS mungkin tidak cukup untuk sepenuhnya memenuhi kebutuhan pembayaran konsumen, media sosial terdesentralisasi, atau bidang bandwidth tinggi lainnya, terutama ketika kita mulai mempertimbangkan faktor privasi, yang dapat mengurangi skalabilitas 3-8 kali lipat. Untuk skenario aplikasi dengan volume transaksi tinggi dan nilai rendah, salah satu pilihan saat ini adalah menggunakan Validium, yang menyimpan data di luar rantai, dan menerapkan model keamanan yang menarik: operator tidak dapat mencuri dana pengguna, tetapi mereka mungkin dapat membekukan semua dana pengguna sementara atau secara permanen. Namun, kita bisa melakukan yang lebih baik.

Apa itu, bagaimana cara kerjanya?

Plasma adalah solusi skalabilitas yang melibatkan operator yang menerbitkan blok di luar rantai dan menempatkan akar Merkle dari blok tersebut di dalam rantai. Untuk setiap blok, operator akan mengirimkan cabang Merkle ke setiap pengguna untuk membuktikan apa yang telah terjadi pada aset pengguna, atau tidak terjadi apa-apa. Pengguna dapat menarik aset mereka dengan memberikan cabang Merkle. Penting untuk dicatat bahwa cabang ini tidak harus memiliki status terbaru sebagai akar. Oleh karena itu, bahkan jika ada masalah ketersediaan data, pengguna masih dapat memulihkan aset mereka dengan menarik status terbaru yang tersedia. Jika pengguna mengajukan cabang yang tidak valid, kepemilikan aset dapat ditentukan melalui mekanisme tantangan di dalam rantai.

Versi awal Plasma hanya dapat menangani kasus pembayaran, tidak dapat diperluas secara efektif. Namun, jika kita meminta setiap akar untuk diverifikasi dengan SNARK, maka Plasma akan menjadi jauh lebih kuat. Setiap permainan tantangan dapat sangat disederhanakan,