Peta jalan Ethereum awalnya mencakup dua strategi skalabilitas: sharding dan protokol Layer 2. Kedua jalur ini akhirnya bergabung, membentuk peta jalan yang berfokus pada Rollup, yang tetap menjadi strategi skalabilitas Ethereum saat ini.
Peta jalan yang berfokus pada Rollup mengusulkan pembagian tugas yang sederhana: Ethereum L1 berfokus pada menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 bertugas membantu ekosistem berkembang. Pola ini ada di mana-mana dalam masyarakat: keberadaan sistem pengadilan (L1) bukanlah untuk mengejar kecepatan super dan efisiensi tinggi, melainkan untuk melindungi kontrak dan hak milik, sementara para pengusaha (L2) harus membangun di atas lapisan dasar yang kokoh ini, memimpin umat manusia menuju Mars.
Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai hasil penting: dengan peluncuran blob EIP-4844, bandwidth data Ethereum L1 meningkat secara signifikan, dan beberapa mesin virtual Ethereum (EVM)Rollup telah memasuki fase pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika internalnya sendiri, keragaman dan variasi dalam cara implementasi shard kini telah menjadi kenyataan. Namun, seperti yang kita lihat, mengikuti jalur 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 ketahanan dan desentralisasi yang khas dari Ethereum L1.
The Surge: Tujuan Kunci
Di masa depan, Ethereum dapat mencapai lebih dari 100.000 TPS melalui L2;
Mempertahankan desentralisasi dan ketahanan L1;
Setidaknya beberapa L2 sepenuhnya mewarisi atribut inti Ethereum ( yang tidak mempercayai, terbuka, dan tahan sensor );
Ethereum seharusnya terasa seperti ekosistem yang terintegrasi, bukan 34 blockchain yang berbeda.
Isi Bab Ini
Paradoks Segitiga Skalabilitas
Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data
Kompresi data
Plasma Tergeneralisasi
Sistem bukti L2 yang matang
Peningkatan interoperabilitas L2
Mengembangkan eksekusi di L1
Paradoks Segitiga Skalabilitas
Paradoks segitiga skalabilitas adalah ide yang diusulkan pada tahun 2017, yang berpendapat bahwa ada kontradiksi antara tiga fitur blockchain: desentralisasi ( lebih khusus: biaya menjalankan node 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 pos yang memperkenalkan paradoks segitiga juga tidak disertai dengan bukti matematis. Ini memang memberikan argumen matematis heuristik: jika satu node yang ramah terdesentralisasi ( 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 melewati satu transaksi jahat, atau (ii) node Anda akan menjadi kuat, sementara rantai Anda tidak akan terdesentralisasi. Tujuan artikel ini bukan untuk membuktikan bahwa memecahkan paradoks segitiga tidak mungkin; sebaliknya, ini bertujuan untuk menunjukkan bahwa memecahkan paradoks tiga unsur itu sulit, dan perlu melampaui kerangka pemikiran yang tersirat dalam 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, karena menjalankan node di rantai ini jauh lebih sulit dibandingkan menjalankan node di Ethereum. Artikel ini akan membahas mengapa hal ini terjadi, dan mengapa hanya dengan rekayasa perangkat lunak klien L1 saja tidak dapat menskalakan Ethereum?
Namun, kombinasi pengambilan sampel 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 sangat sedikit perhitungan, serta sejumlah langkah perhitungan dieksekusi dengan benar. SNARKs adalah tanpa kepercayaan. Pengambilan sampel ketersediaan data memiliki model kepercayaan few-of-N yang halus, tetapi ia 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 untuk mengatasi tiga tantangan adalah arsitektur Plasma, yang menggunakan teknologi cerdas untuk mendorong tanggung jawab ketersediaan data pengawasan kepada pengguna dengan cara yang kompatibel dengan insentif. Pada tahun 2017-2019, ketika kita hanya memiliki bukti penipuan sebagai satu-satunya cara untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan keamanan, tetapi dengan meningkatnya popularitas SNARKs( bukti nol-pengetahuan yang ringkas dan non-interaktif), arsitektur Plasma menjadi lebih layak untuk digunakan dalam lebih banyak skenario dibandingkan sebelumnya.
Kemajuan lebih lanjut dalam sampling ketersediaan data
Kami sedang menyelesaikan masalah apa?
Pada 13 Maret 2024, ketika pembaruan Dencun diluncurkan, blockchain Ethereum akan memiliki 3 blob sekitar 125 kB setiap slot 12 detik, atau bandwidth data yang tersedia per slot sekitar 375 kB. Dengan asumsi data transaksi dipublikasikan langsung di rantai, maka transfer ERC20 sekitar 180 byte, sehingga maksimum TPS untuk Rollup di Ethereum adalah: 375000 / 12 / 180 = 173,6 TPS.
Jika kita menambahkan nilai maksimum teoritis dari calldata Ethereum (: setiap slot 30 juta Gas / per byte 16 gas = setiap slot 1.875.000 byte ), maka menjadi 607 TPS. Dengan menggunakan PeerDAS, jumlah blob mungkin akan 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 menengah kami adalah 16 MB per slot, dan jika dikombinasikan dengan perbaikan kompresi data Rollup, ini akan membawa ~58000 TPS.
Apa itu? Bagaimana cara kerjanya?
PeerDAS adalah implementasi yang relatif sederhana dari "1D sampling". Di Ethereum, setiap blob adalah polinomial 4096 derajat di bidang prima 253 bit (. Kami menyiarkan shares polinomial, di mana setiap shares berisi 16 nilai evaluasi dari 16 koordinat bertetangga 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 yang mungkin, The Surge])lab.com/yijian/2024/10/17/images/5be9d7b18dd5154d181bd4c34ad8a3c4.jpg(
Cara kerja PeerDAS adalah membiarkan setiap klien mendengarkan sejumlah subnet kecil, di mana subnet ke-i menyiarkan sampel ke-i dari setiap blob, dan dengan menanyakan kepada peer di jaringan p2p global ) siapa yang akan mendengarkan subnet yang berbeda ( untuk meminta blob lain yang dibutuhkannya dari subnet lain. Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa menanyakan lapisan peer tambahan. Proposal saat ini adalah agar node yang berpartisipasi dalam proof of stake 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 mungkin, tetapi berarti klien yang dibatasi bandwidth tidak dapat melakukan sampling. Kita dapat mengoptimalkan ini sampai 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, melakukan 2D sampling)2D sampling(, metode ini tidak hanya melakukan sampling acak dalam blob, tetapi juga melakukan sampling acak antar blob. Dengan memanfaatkan sifat linier dari komitmen KZG, memperluas kumpulan blob dalam satu blok dengan serangkaian blob virtual baru, di mana blob virtual ini secara redundan mengkodekan informasi yang sama.
Oleh karena itu, pada akhirnya kami ingin melangkah lebih jauh, 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 mengkodekan informasi yang sama secara redundan.
Sangat penting untuk dicatat bahwa perluasan komitmen perhitungan tidak memerlukan blob, sehingga skema ini secara fundamental bersahabat dengan pembangunan blok terdistribusi. Node yang sebenarnya 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 yang perlu dilakukan? Apa saja pertimbangannya?
Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, jumlah blob di PeerDAS akan terus ditambahkan, sambil mengawasi jaringan dan memperbaiki perangkat lunak untuk memastikan keamanan, ini adalah proses yang bertahap. Sementara itu, kami berharap ada lebih banyak pekerjaan akademis untuk menstandarkan PeerDAS dan versi DAS lainnya serta interaksinya dengan masalah keamanan seperti peraturan 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 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 terhadap pembangunan blok terdistribusi. Bahkan dengan menggunakan teknologi "brute force" yang mahal, yaitu dengan menggunakan STARK rekursif untuk menghasilkan bukti validitas untuk membangun baris dan kolom, itu pun 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.
Saya percaya bahwa jalur realitas jangka panjang adalah:
Melaksanakan DAS 2D yang ideal;
Tetap menggunakan 1D DAS, mengorbankan efisiensi bandwidth sampling, demi kesederhanaan dan ketahanan menerima batas data yang lebih rendah.
Melepaskan DA dan sepenuhnya menerima Plasma sebagai arsitektur Layer2 utama yang menjadi fokus kami.
Harap dicatat, 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 di lapisan L1 seperti Rollup) seperti ZK-EVM dan DAS(.
) Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
Jika kompresi data terwujud, permintaan untuk 2D DAS akan berkurang, atau setidaknya tertunda. Jika Plasma digunakan secara luas, permintaan akan berkurang lebih lanjut. DAS juga menghadapi tantangan terhadap protokol dan mekanisme pembangunan blok terdistribusi: meskipun DAS secara teori ramah terhadap rekonstruksi terdistribusi, dalam praktiknya ini perlu dipadukan 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 sampel ketersediaan data yang ideal, ini membatasi skalabilitas protokol Layer. Setiap slot 16 MB, kita mendapatkan:
16000000 / 12 / 180 = 7407 TPS
Bagaimana jika kita tidak hanya dapat menyelesaikan masalah molekul, tetapi juga dapat menyelesaikan masalah penyebut, sehingga setiap transaksi dalam Rollup memerlukan lebih sedikit byte di blockchain?
Apa itu, 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])
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
12 Suka
Hadiah
12
6
Bagikan
Komentar
0/400
DeFiVeteran
· 20jam yang lalu
L2赛道进入 lakukan dorongan yang kuat期了
Lihat AsliBalas0
SquidTeacher
· 08-02 08:18
Pekerjaan L2 masih banyak ya...
Lihat AsliBalas0
DevChive
· 08-02 08:12
Tidak bisa mendapatkan keuntungan, membayar untuk kelangsungan hidup
Ethereum The Surge: 100.000 TPS, L2 mewarisi atribut inti, visi ekosistem yang terintegrasi
Masa Depan Ethereum: The Surge
Peta jalan Ethereum awalnya mencakup dua strategi skalabilitas: sharding dan protokol Layer 2. Kedua jalur ini akhirnya bergabung, membentuk peta jalan yang berfokus pada Rollup, yang tetap menjadi strategi skalabilitas Ethereum saat ini.
Peta jalan yang berfokus pada Rollup mengusulkan pembagian tugas yang sederhana: Ethereum L1 berfokus pada menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 bertugas membantu ekosistem berkembang. Pola ini ada di mana-mana dalam masyarakat: keberadaan sistem pengadilan (L1) bukanlah untuk mengejar kecepatan super dan efisiensi tinggi, melainkan untuk melindungi kontrak dan hak milik, sementara para pengusaha (L2) harus membangun di atas lapisan dasar yang kokoh ini, memimpin umat manusia menuju Mars.
Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai hasil penting: dengan peluncuran blob EIP-4844, bandwidth data Ethereum L1 meningkat secara signifikan, dan beberapa mesin virtual Ethereum (EVM)Rollup telah memasuki fase pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika internalnya sendiri, keragaman dan variasi dalam cara implementasi shard kini telah menjadi kenyataan. Namun, seperti yang kita lihat, mengikuti jalur 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 ketahanan dan desentralisasi yang khas dari Ethereum L1.
The Surge: Tujuan Kunci
Di masa depan, Ethereum dapat mencapai lebih dari 100.000 TPS melalui L2;
Mempertahankan desentralisasi dan ketahanan L1;
Setidaknya beberapa L2 sepenuhnya mewarisi atribut inti Ethereum ( yang tidak mempercayai, terbuka, dan tahan sensor );
Ethereum seharusnya terasa seperti ekosistem yang terintegrasi, bukan 34 blockchain yang berbeda.
Isi Bab Ini
Paradoks Segitiga Skalabilitas
Paradoks segitiga skalabilitas adalah ide yang diusulkan pada tahun 2017, yang berpendapat bahwa ada kontradiksi antara tiga fitur blockchain: desentralisasi ( lebih khusus: biaya menjalankan node 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 pos yang memperkenalkan paradoks segitiga juga tidak disertai dengan bukti matematis. Ini memang memberikan argumen matematis heuristik: jika satu node yang ramah terdesentralisasi ( 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 melewati satu transaksi jahat, atau (ii) node Anda akan menjadi kuat, sementara rantai Anda tidak akan terdesentralisasi. Tujuan artikel ini bukan untuk membuktikan bahwa memecahkan paradoks segitiga tidak mungkin; sebaliknya, ini bertujuan untuk menunjukkan bahwa memecahkan paradoks tiga unsur itu sulit, dan perlu melampaui kerangka pemikiran yang tersirat dalam 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, karena menjalankan node di rantai ini jauh lebih sulit dibandingkan menjalankan node di Ethereum. Artikel ini akan membahas mengapa hal ini terjadi, dan mengapa hanya dengan rekayasa perangkat lunak klien L1 saja tidak dapat menskalakan Ethereum?
Namun, kombinasi pengambilan sampel 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 sangat sedikit perhitungan, serta sejumlah langkah perhitungan dieksekusi dengan benar. SNARKs adalah tanpa kepercayaan. Pengambilan sampel ketersediaan data memiliki model kepercayaan few-of-N yang halus, tetapi ia 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 untuk mengatasi tiga tantangan adalah arsitektur Plasma, yang menggunakan teknologi cerdas untuk mendorong tanggung jawab ketersediaan data pengawasan kepada pengguna dengan cara yang kompatibel dengan insentif. Pada tahun 2017-2019, ketika kita hanya memiliki bukti penipuan sebagai satu-satunya cara untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan keamanan, tetapi dengan meningkatnya popularitas SNARKs( bukti nol-pengetahuan yang ringkas dan non-interaktif), arsitektur Plasma menjadi lebih layak untuk digunakan dalam lebih banyak skenario dibandingkan sebelumnya.
Kemajuan lebih lanjut dalam sampling ketersediaan data
Kami sedang menyelesaikan masalah apa?
Pada 13 Maret 2024, ketika pembaruan Dencun diluncurkan, blockchain Ethereum akan memiliki 3 blob sekitar 125 kB setiap slot 12 detik, atau bandwidth data yang tersedia per slot sekitar 375 kB. Dengan asumsi data transaksi dipublikasikan langsung di rantai, maka transfer ERC20 sekitar 180 byte, sehingga maksimum TPS untuk Rollup di Ethereum adalah: 375000 / 12 / 180 = 173,6 TPS.
Jika kita menambahkan nilai maksimum teoritis dari calldata Ethereum (: setiap slot 30 juta Gas / per byte 16 gas = setiap slot 1.875.000 byte ), maka menjadi 607 TPS. Dengan menggunakan PeerDAS, jumlah blob mungkin akan 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 menengah kami adalah 16 MB per slot, dan jika dikombinasikan dengan perbaikan kompresi data Rollup, ini akan membawa ~58000 TPS.
Apa itu? Bagaimana cara kerjanya?
PeerDAS adalah implementasi yang relatif sederhana dari "1D sampling". Di Ethereum, setiap blob adalah polinomial 4096 derajat di bidang prima 253 bit (. Kami menyiarkan shares polinomial, di mana setiap shares berisi 16 nilai evaluasi dari 16 koordinat bertetangga 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 yang mungkin, The Surge])lab.com/yijian/2024/10/17/images/5be9d7b18dd5154d181bd4c34ad8a3c4.jpg(
Cara kerja PeerDAS adalah membiarkan setiap klien mendengarkan sejumlah subnet kecil, di mana subnet ke-i menyiarkan sampel ke-i dari setiap blob, dan dengan menanyakan kepada peer di jaringan p2p global ) siapa yang akan mendengarkan subnet yang berbeda ( untuk meminta blob lain yang dibutuhkannya dari subnet lain. Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa menanyakan lapisan peer tambahan. Proposal saat ini adalah agar node yang berpartisipasi dalam proof of stake 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 mungkin, tetapi berarti klien yang dibatasi bandwidth tidak dapat melakukan sampling. Kita dapat mengoptimalkan ini sampai 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, melakukan 2D sampling)2D sampling(, metode ini tidak hanya melakukan sampling acak dalam blob, tetapi juga melakukan sampling acak antar blob. Dengan memanfaatkan sifat linier dari komitmen KZG, memperluas kumpulan blob dalam satu blok dengan serangkaian blob virtual baru, di mana blob virtual ini secara redundan mengkodekan informasi yang sama.
Oleh karena itu, pada akhirnya kami ingin melangkah lebih jauh, 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 mengkodekan informasi yang sama secara redundan.
Sangat penting untuk dicatat bahwa perluasan komitmen perhitungan tidak memerlukan blob, sehingga skema ini secara fundamental bersahabat dengan pembangunan blok terdistribusi. Node yang sebenarnya 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 yang perlu dilakukan? Apa saja pertimbangannya?
Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, jumlah blob di PeerDAS akan terus ditambahkan, sambil mengawasi jaringan dan memperbaiki perangkat lunak untuk memastikan keamanan, ini adalah proses yang bertahap. Sementara itu, kami berharap ada lebih banyak pekerjaan akademis untuk menstandarkan PeerDAS dan versi DAS lainnya serta interaksinya dengan masalah keamanan seperti peraturan 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 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 terhadap pembangunan blok terdistribusi. Bahkan dengan menggunakan teknologi "brute force" yang mahal, yaitu dengan menggunakan STARK rekursif untuk menghasilkan bukti validitas untuk membangun baris dan kolom, itu pun 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.
Saya percaya bahwa jalur realitas jangka panjang adalah:
Harap dicatat, 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 di lapisan L1 seperti Rollup) seperti ZK-EVM dan DAS(.
) Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
Jika kompresi data terwujud, permintaan untuk 2D DAS akan berkurang, atau setidaknya tertunda. Jika Plasma digunakan secara luas, permintaan akan berkurang lebih lanjut. DAS juga menghadapi tantangan terhadap protokol dan mekanisme pembangunan blok terdistribusi: meskipun DAS secara teori ramah terhadap rekonstruksi terdistribusi, dalam praktiknya ini perlu dipadukan 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 sampel ketersediaan data yang ideal, ini membatasi skalabilitas protokol Layer. Setiap slot 16 MB, kita mendapatkan:
16000000 / 12 / 180 = 7407 TPS
Bagaimana jika kita tidak hanya dapat menyelesaikan masalah molekul, tetapi juga dapat menyelesaikan masalah penyebut, sehingga setiap transaksi dalam Rollup memerlukan lebih sedikit byte di blockchain?
Apa itu, 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])