Visi The Surge Ethereum: Jalan dan Tantangan untuk Ekspansi 100.000 TPS

Masa Depan Ethereum yang Mungkin: The Surge

Peta jalan Ethereum awalnya mencakup dua strategi penskalaan: sharding dan protokol Layer2. Sharding memungkinkan setiap node hanya perlu memverifikasi dan menyimpan sebagian kecil transaksi, sementara protokol Layer2 membangun jaringan di atas Ethereum, memanfaatkan keamanan yang dimilikinya sambil menjaga sebagian besar data dan komputasi di luar rantai utama. Seiring dengan pendalaman penelitian, kedua jalur ini akhirnya bergabung, membentuk peta jalan yang berfokus pada Rollup, yang hingga kini tetap menjadi strategi penskalaan Ethereum.

Peta jalan yang berfokus pada Rollup mengusulkan pembagian tugas yang sederhana: Ethereum L1 berfokus untuk menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 bertugas membantu memperluas ekosistem. Pola ini ada di mana-mana dalam masyarakat: keberadaan sistem pengadilan (L1) bukan untuk mengejar kecepatan super dan efisiensi tinggi, tetapi untuk melindungi kontrak dan hak milik, sedangkan para wirausahawan (L2) harus membangun di atas lapisan dasar yang stabil ini, mendorong kemajuan manusia.

Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai hasil penting: dengan peluncuran blob EIP-4844, bandwidth data Ethereum L1 meningkat secara signifikan, beberapa Ethereum Virtual Machine (EVM) Rollup telah memasuki tahap pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika internalnya sendiri, keberagaman dan variasi dalam cara implementasi shard kini telah menjadi kenyataan. Namun, jalan ini juga menghadapi beberapa tantangan unik. Oleh karena itu, tugas kita sekarang adalah menyelesaikan peta jalan yang berfokus pada Rollup dan mengatasi masalah ini, sambil mempertahankan kekokohan dan desentralisasi yang khas dari Ethereum L1.

Vitalik baru: Masa depan Ethereum yang mungkin, The Surge

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 dapat dipercaya, terbuka, dan 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 sampling ketersediaan data
  3. Kompresi Data
  4. Plasma Tergeneral
  5. Sistem Pembuktian 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 menyatakan bahwa terdapat kontradiksi di antara tiga karakteristik blockchain: desentralisasi ( lebih tepatnya: biaya menjalankan node yang rendah ), skalabilitas ( jumlah transaksi yang diproses banyak ) dan keamanan ( penyerang perlu menghancurkan sebagian besar node dalam jaringan agar dapat membuat satu transaksi gagal ).

Vitalik baru: Masa depan Ethereum yang mungkin, The Surge

Perlu dicatat bahwa nasib segitiga bukanlah sebuah teorema, dan pos yang memperkenalkan nasib segitiga juga tidak disertai dengan bukti matematis. Ini memang memberikan argumen matematis heuristik: jika sebuah node yang ramah desentralisasi (, misalnya, laptop konsumen ) dapat memverifikasi N transaksi per detik, dan Anda memiliki sebuah 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 beberapa 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 nasib segitiga tidak mungkin; sebaliknya, itu bertujuan untuk menunjukkan bahwa memecahkan paradoks tiga adalah sulit, dan itu membutuhkan untuk melampaui kerangka berpikir yang diimplikasikan oleh argumen tersebut.

Selama bertahun-tahun, beberapa rantai berkinerja tinggi sering mengklaim bahwa mereka telah menyelesaikan 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 daripada menjalankan node di Ethereum. Artikel ini akan membahas mengapa demikian, dan mengapa hanya dengan rekayasa perangkat lunak klien L1 tidak cukup untuk menskalakan Ethereum?

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

Salah satu cara lain untuk mengatasi dilema tiga sulit adalah arsitektur Plasma, yang menggunakan teknologi cerdas untuk mendorong tanggung jawab atas ketersediaan data pemantauan kepada pengguna dengan cara yang kompatibel dengan insentif. Sejak tahun 2017-2019, ketika kami hanya memiliki bukti penipuan sebagai alat untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan keamanan, tetapi dengan munculnya SNARKs( bukti nol pengetahuan yang ringkas dan non-interaktif), arsitektur Plasma menjadi lebih layak untuk berbagai skenario penggunaan yang lebih luas dibandingkan sebelumnya.

Kemajuan lebih lanjut dari sampling ketersediaan data

Masalah apa yang sedang kami selesaikan?

Pada 13 Maret 2024, ketika peningkatan 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 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 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 jangka menengah kami adalah 16 MB per slot, dan jika digabungkan dengan perbaikan kompresi data Rollup, akan membawa ~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 bit (. 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 yang diajukan saat ini: sembarang 64 dari 128 kemungkinan sampel (.

![Vitalik baru: Masa depan Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(

Cara kerja PeerDAS adalah membuat setiap klien mendengarkan sejumlah subnet 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 dibutuhkannya. Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa menanyakan lapisan rekan tambahan. Proposal saat ini adalah agar node yang berpartisipasi dalam bukti kepemilikan menggunakan SubnetDAS, sementara node lainnya ) yaitu klien ( menggunakan PeerDAS.

Secara teoritis, kita dapat memperluas 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 dapat dilakukan, tetapi ini berarti klien yang dibatasi bandwidth tidak dapat melakukan sampling. Kita dapat mengoptimalkan ini 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 antar blob. Dengan memanfaatkan sifat linier dari komitmen KZG, untuk memperluas kumpulan blob dalam sebuah blok dengan satu set blob virtual baru, blob virtual ini 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 sebuah blok, yang mencakup daftar blob virtual baru dengan pengkodean redundansi terhadap informasi yang sama.

Yang penting, 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 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 yang masih perlu dilakukan? Apa saja pertimbangannya?

Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, secara bertahap meningkatkan jumlah blob di PeerDAS, 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 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 yang dapat dipercaya. Saat ini, kami masih belum jelas tentang kandidat mana yang ramah untuk pembangunan blok terdistribusi. Bahkan dengan menggunakan teknik "brute force" yang mahal, yaitu dengan menggunakan STARK rekursif untuk menghasilkan bukti validitas untuk membangun kembali baris dan kolom, itu masih belum cukup untuk memenuhi kebutuhan, karena meskipun secara teknis, ukuran satu STARK adalah O(log)n### * log(log(n)( nilai hash ( menggunakan STIR), tetapi kenyataannya STARK hampir sebesar seluruh blob.

Saya pikir jalur realitas jangka panjang adalah:

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

Silakan diperhatikan, 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, klien akan menginginkan cara yang efisien untuk memverifikasi keakuratannya, 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 data kompresi 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 teori bersahabat dengan rekonstruksi terdistribusi, dalam praktiknya ini perlu dipadukan dengan proposal daftar inklusi paket dan mekanisme pemilihan fork di sekitarnya.

( kompresi data

)# Apa masalah yang sedang kita selesaikan?

Setiap transaksi dalam Rollup akan memakan banyak ruang data di rantai: 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 molekul, tetapi juga menyelesaikan masalah penyebut, sehingga setiap transaksi dalam Rollup memakan lebih sedikit byte di blockchain, bagaimana jadinya?

Apa itu, bagaimana cara kerjanya?

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

![Vitalik artikel baru: Masa Depan Ethereum yang Mungkin, The Surge]###https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.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 atribut spesifik dari transaksi:

Agregasi Tanda Tangan: Kami beralih dari tanda tangan ECDSA ke tanda tangan BLS

Lihat Asli
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Hadiah
  • 5
  • Bagikan
Komentar
0/400
Rekt_Recoveryvip
· 13jam yang lalu
Biaya Layer2 terlalu tinggi
Lihat AsliBalas0
StablecoinAnxietyvip
· 07-12 15:41
Keyakinan Surge terus berlanjut
Lihat AsliBalas0
OnchainSnipervip
· 07-10 09:07
Mendukung skema penskalaan bertingkat
Lihat AsliBalas0
GhostInTheChainvip
· 07-10 08:57
Layer2 telah menjadi tren utama
Lihat AsliBalas0
LeekCuttervip
· 07-10 08:51
L2 adalah masa depan
Lihat AsliBalas0
  • Sematkan
Perdagangkan Kripto Di Mana Saja Kapan Saja
qrCode
Pindai untuk mengunduh aplikasi Gate
Komunitas
Bahasa Indonesia
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)