- Topik
77k Popularitas
33k Popularitas
10k Popularitas
4k Popularitas
4k Popularitas
29k Popularitas
16k Popularitas
22k Popularitas
13k Popularitas
3k Popularitas
- Sematkan
77k Popularitas
33k Popularitas
10k Popularitas
4k Popularitas
4k Popularitas
29k Popularitas
16k Popularitas
22k Popularitas
13k Popularitas
3k Popularitas
Babak baru dalam skalabilitas Ethereum: Analisis Kedalaman peta jalan The Surge
Masa Depan Ethereum yang Mungkin: The Surge
Peta jalan Ethereum awalnya mencakup dua strategi penskalaan: sharding dan protokol Layer 2. Kedua metode ini akhirnya bergabung, membentuk 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 fokus pada menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 mengambil tugas untuk membantu ekosistem berkembang. Pola ini umum di masyarakat: keberadaan sistem pengadilan (L1) adalah untuk melindungi kontrak dan hak milik, sementara para pengusaha (L2) membangun di atas dasar ini, mendorong perkembangan manusia.
Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai kemajuan penting: dengan peluncuran blob EIP-4844, bandwidth data Ethereum L1 meningkat secara signifikan, dan beberapa Ethereum Virtual Machines (EVM) Rollup telah memasuki tahap pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika internalnya sendiri, dan keberagaman serta variasi dalam cara implementasi shard kini menjadi kenyataan. Namun, jalan ini juga menghadapi beberapa tantangan unik. Oleh karena itu, tugas kami sekarang adalah menyelesaikan peta jalan yang berfokus pada Rollup dan menyelesaikan masalah-masalah ini, sambil mempertahankan ketahanan dan desentralisasi yang khas dari Ethereum L1.
The Surge: Tujuan Kunci
Di masa depan, Ethereum melalui L2 dapat mencapai lebih dari 100.000 TPS;
Menjaga desentralisasi dan ketahanan L1;
Setidaknya beberapa L2 sepenuhnya mewarisi atribut inti Ethereum ( yang tanpa kepercayaan, terbuka, dan tahan sensor );
Ethereum seharusnya terasa seperti ekosistem yang terpadu, bukan 34 blockchain yang berbeda.
Isi Bab Ini
Paradoks Segitiga Skalabilitas
Paradoks segitiga skalabilitas berpendapat bahwa terdapat kontradiksi antara tiga karakteristik blockchain: desentralisasi ( biaya node operasi yang rendah ) skalabilitas ( jumlah transaksi yang dapat diproses banyak ) dan keamanan ( penyerang perlu merusak sebagian besar node dalam jaringan untuk membuat satu transaksi gagal ).
Perlu dicatat bahwa paradoks segitiga bukanlah sebuah teorema, dan tidak ada 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 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 sebuah transaksi jahat, 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 adalah tidak mungkin; sebaliknya, ini bertujuan untuk menunjukkan bahwa memecahkan paradoks tiga entitas itu sulit, dan perlu untuk melangkah keluar dari kerangka pemikiran yang tersirat dalam argumen tersebut.
Selama bertahun-tahun, beberapa rantai berkinerja tinggi sering mengklaim bahwa mereka telah menyelesaikan paradoks 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 menjalankan node di Ethereum. Artikel ini akan membahas mengapa hal ini terjadi, serta 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 sejumlah kecil data dan melakukan sedikit perhitungan. SNARKs tidak memerlukan kepercayaan. Sampling ketersediaan data memiliki model kepercayaan few-of-N yang halus, tetapi tetap mempertahankan karakteristik dasar yang dimiliki oleh 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 tersebut adalah arsitektur Plasma, yang menggunakan teknologi cerdas untuk mendorong tanggung jawab ketersediaan data pemantauan kepada pengguna dengan cara yang kompatibel dengan insentif. Pada tahun 2017-2019, ketika kami hanya memiliki bukti penipuan sebagai cara untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam eksekusi yang aman, tetapi dengan berkembangnya SNARKs( bukti non-interaktif yang ringkas dan pengetahuan nol), arsitektur Plasma menjadi lebih layak untuk berbagai skenario penggunaan dibandingkan sebelumnya.
Kemajuan lebih lanjut dalam sampling ketersediaan data
Apa masalah yang sedang kita selesaikan?
Pada tanggal 13 Maret 2024, ketika peningkatan Dencun diluncurkan, blockchain Ethereum memiliki 3 blob sekitar 125 kB setiap 12 detik slot, atau bandwidth data yang tersedia per slot sekitar 375 kB. Jika 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 bisa 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 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 pada bidang prima 253 (prime field). 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, 4096 ( berdasarkan parameter yang diajukan saat ini: 64 dari 128 kemungkinan sampel ) dapat memulihkan blob.
Prinsip kerja PeerDAS adalah membuat setiap klien mendengarkan sejumlah subnet yang kecil, di mana subnet ke-i menyiarkan sampel ke-i dari setiap blob, dan dengan menanyakan kepada rekan-rekan di jaringan p2p global ( siapa yang akan mendengarkan subnet yang berbeda ) untuk meminta blob dari subnet lain yang mereka butuhkan. 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 memperbesar skala "1D sampling" cukup besar: jika kita meningkatkan jumlah maksimum blob menjadi 256( dengan target 128), maka kita dapat 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 sedikit berada dalam batas toleransi kita: ini mungkin, tetapi ini berarti klien dengan bandwidth terbatas tidak dapat melakukan sampling. Kita dapat mengoptimalkannya sampai batas 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, melakukan 2D sampling (2D sampling), metode ini tidak hanya melakukan sampling acak di dalam blob, tetapi juga melakukan sampling acak di antara blob. Dengan memanfaatkan sifat linier dari komitmen KZG, kami memperluas kumpulan blob dalam satu blok melalui sekumpulan blob virtual baru, di mana blob virtual ini secara redundan mengkodekan informasi yang sama.
Oleh karena itu, akhirnya kami ingin melangkah lebih jauh, melakukan pengambilan sampel 2D, yang tidak hanya mengambil sampel secara acak di dalam blob, tetapi juga di antara blob. Sifat linear dari komitmen KZG digunakan untuk memperluas kumpulan blob dalam satu blok, yang berisi daftar blob virtual baru yang mengenkripsi informasi yang sama.
Penting untuk dicatat bahwa perpanjangan komitmen tidak memerlukan blob, sehingga skema ini pada dasarnya ramah terhadap pembangunan blok terdistribusi. Node yang membangun blok sebenarnya 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 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 meningkat, sambil dengan hati-hati mengamati jaringan dan meningkatkan 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.
Di 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 akhirnya dapat beralih dari KZG ke alternatif yang aman secara kuantum dan tidak memerlukan pengaturan tepercaya. 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 yang digunakan 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), tetapi sebenarnya STARK hampir sebesar seluruh blob.
Jalur realitas jangka panjang yang saya pikirkan adalah:
Harap dicatat, meskipun kami memutuskan untuk langsung memperluas eksekusi 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 di lapisan L1 seperti Rollup( seperti ZK-EVM dan DAS).
( Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
Jika kompresi data berhasil dilakukan, permintaan untuk 2D DAS akan berkurang, atau setidaknya akan tertunda. Jika Plasma digunakan secara luas, maka 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: Transfer 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 pembilang, tetapi juga masalah penyebut, dan membuat setiap transaksi dalam Rollup menggunakan lebih sedikit byte di rantai, bagaimana jadinya?
Apa itu, dan bagaimana cara kerjanya?
Menurut saya, penjelasan terbaik adalah gambar ini dari dua tahun yang lalu:
![Vitalik artikel baru: Masa Depan Ethereum yang Mungkin, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
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. Ciri dari tanda tangan BLS adalah 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 untuk verifikasi tetap tinggi, maka tidak mempertimbangkan penggunaan tanda tangan BLS.