Peta jalan Ethereum awalnya mencakup dua strategi skalabilitas: sharding dan protokol Layer2. Sharding memungkinkan setiap node hanya perlu memverifikasi dan menyimpan sebagian transaksi, sedangkan Layer2 membangun jaringan di atas Ethereum, memanfaatkan keamanannya tetapi menjaga sebagian besar data dan perhitungan di luar rantai utama. Kedua metode ini akhirnya bergabung menjadi peta jalan yang berfokus pada Rollup, yang masih menjadi strategi skalabilitas Ethereum hingga 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 mengambil tugas untuk membantu ekosistem berkembang. Pola ini umum di masyarakat: sistem pengadilan (L1) ada untuk melindungi kontrak dan hak milik, sementara pengusaha (L2) membangun di atasnya, mendorong perkembangan manusia.
Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai kemajuan penting: peluncuran blob EIP-4844 secara signifikan meningkatkan bandwidth data Ethereum L1, dan beberapa Ethereum Virtual Machine (EVM) Rollup telah memasuki tahap pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika sendiri, dan keberagaman cara implementasi shard kini telah menjadi kenyataan. Namun, jalan ini juga menghadapi beberapa tantangan unik. Tugas kita sekarang adalah menyelesaikan peta jalan yang berfokus pada Rollup, mengatasi masalah ini, sambil menjaga ketahanan dan desentralisasi 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 sebagian L2 sepenuhnya mewarisi atribut inti Ethereum ( yang tidak mempercayai, terbuka, dan tahan sensor );
Ethereum harus terasa seperti ekosistem yang terintegrasi, bukan 34 blockchain yang berbeda.
Paradoks Segitiga Skalabilitas
Paradoks segitiga skalabilitas berpendapat bahwa ada kontradiksi antara tiga fitur blockchain: desentralisasi ( biaya node operasional yang rendah ), skalabilitas ( jumlah transaksi yang dapat diproses banyak ) dan keamanan ( penyerang perlu merusak sebagian besar node di jaringan agar transaksi tunggal gagal ).
Paradoks segitiga bukanlah sebuah teorema, dan posting yang memperkenalkannya juga tidak menyertakan 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 menghancurkan sejumlah kecil node untuk melewati sebuah transaksi berbahaya, atau (ii) node Anda akan menjadi kuat, sementara rantai Anda tidak akan terdesentralisasi. Artikel ini bertujuan untuk menunjukkan bahwa memecahkan paradoks triad itu sulit, dan perlu untuk keluar dari 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 mengoptimalkan node. Ini selalu menyesatkan, menjalankan node di rantai ini jauh lebih sulit daripada menjalankan node di Ethereum.
Namun, perpaduan antara sampling ketersediaan data dan SNARKs memang menyelesaikan paradoks segitiga: ini memungkinkan klien untuk memverifikasi bahwa sejumlah data tersedia dan sejumlah langkah perhitungan dilakukan dengan benar hanya dengan mengunduh sedikit 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 dari rantai yang tidak dapat diskalakan, yaitu bahkan serangan 51% tidak dapat memaksa blok buruk diterima oleh jaringan.
Cara 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. Sejak 2017-2019, ketika kami hanya memiliki bukti penipuan sebagai cara untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan yang aman, tetapi dengan penyebaran SNARKs, arsitektur Plasma menjadi lebih layak untuk lebih banyak skenario penggunaan daripada sebelumnya.
Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data
Apa masalah yang sedang kita selesaikan?
Pada 13 Maret 2024, ketika peningkatan Dencun diluncurkan, blockchain Ethereum akan memiliki 3 blob sekitar 125 kB setiap 12 detik slot, atau bandwidth data yang tersedia per slot sekitar 375 kB. Dengan asumsi data transaksi diterbitkan langsung di rantai, transfer ERC20 sekitar 180 byte, maka 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 / setiap byte 16 gas = setiap slot 1.875.000 byte ), maka menjadi 607 TPS. Menggunakan PeerDAS, jumlah blob mungkin meningkat menjadi 8-16, yang akan memberikan 463-926 TPS untuk calldata.
Ini adalah peningkatan signifikan untuk Ethereum L1, tetapi masih belum cukup. Kami ingin lebih banyak skalabilitas. Tujuan jangka menengah kami adalah 16 MB per slot, dan jika digabungkan dengan perbaikan kompresi data Rollup, itu akan menghasilkan ~58000 TPS.
Apa itu? Bagaimana cara kerjanya?
PeerDAS adalah implementasi yang relatif sederhana dari "1D sampling". Di Ethereum, setiap blob adalah polinomial 4096 derajat dalam bidang prima 253 bit (. Kami menyiarkan shares polinomial, di mana setiap shares berisi 16 nilai evaluasi dari 16 koordinat yang bersebelahan dari total 8192 koordinat. Dari 8192 nilai evaluasi ini, 4096 mana pun ) dapat memulihkan blob berdasarkan parameter yang diajukan saat ini: 64 dari 128 kemungkinan sampel mana pun (.
Cara kerja PeerDAS adalah membuat setiap klien mendengarkan sejumlah kecil subnet, 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 lain yang dibutuhkannya di subnet yang berbeda. Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa pertanyaan tambahan ke lapisan rekan. Proposal saat ini adalah untuk membiarkan node yang berpartisipasi dalam proof of stake menggunakan SubnetDAS, sementara node lain ) yaitu klien ( menggunakan PeerDAS.
Secara teori, kita bisa memperluas skala "1D sampling" cukup besar: jika kita meningkatkan jumlah maksimum blob menjadi 256) dengan target 128(, maka kita bisa 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 bisa melakukan optimasi tertentu 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 )2D sampling(, metode ini tidak hanya melakukan pengambilan sampel acak dalam blob, tetapi juga melakukan pengambilan sampel acak antar blob. Dengan memanfaatkan sifat linear dari komitmen KZG, melalui satu set blob virtual baru untuk memperluas kumpulan blob dalam satu blok, 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 redundansi informasi yang sama.
Sangat penting untuk dicatat bahwa perluasan komitmen perhitungan tidak memerlukan blob, sehingga skema ini secara fundamental ramah terhadap pembangunan blok terdistribusi. Node yang sebenarnya membangun blok hanya perlu memiliki komitmen KZG blob, dan mereka dapat mengandalkan pengambilan sampel ketersediaan data )DAS( untuk memverifikasi ketersediaan blok data. Pengambilan sampel ketersediaan data satu dimensi )1DDAS( pada dasarnya juga ramah terhadap pembangunan blok terdistribusi.
![Vitalik baru: Masa depan Ethereum yang mungkin, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
) Apa yang masih perlu dilakukan? Apa saja pertimbangannya?
Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, jumlah blob di PeerDAS akan terus ditingkatkan, sambil secara cermat memantau jaringan dan memperbaiki perangkat lunak untuk memastikan keamanan, ini adalah proses bertahap. Sementara itu, kami berharap akan ada lebih banyak pekerjaan akademis untuk mengatur PeerDAS dan versi DAS lainnya serta interaksinya dengan masalah keamanan seperti aturan pemilihan fork.
Dalam tahap 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 solusi 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 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), tetapi kenyataannya, STARK hampir sebesar seluruh blob.
Jalur realitas jangka panjang yang saya pikirkan 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, 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(.
![Vitalik baru: Masa depan Ethereum yang mungkin, The Surge])https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp(
) Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
Jika kompresi data direalisasikan, permintaan untuk DAS 2D akan berkurang, atau setidaknya akan tertunda, dan jika Plasma digunakan secara luas, permintaan akan berkurang lebih lanjut. DAS juga menantang protokol dan mekanisme pembangunan blockchain 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, kita mendapatkan:
16000000 / 12 / 180 = 7407 TPS
Jika kita tidak hanya dapat menyelesaikan masalah pembilang, tetapi juga masalah penyebut, sehingga setiap transaksi dalam Rollup menggunakan lebih sedikit byte di rantai, bagaimana jadinya?
( Apa itu, bagaimana cara kerjanya?
Menurut saya, penjelasan terbaik adalah gambar ini dari 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, karakteristik tanda tangan BLS adalah beberapa tanda tangan dapat digabungkan menjadi satu tanda tangan tunggal, tanda tangan ini dapat membuktikan semua yang asli.
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.
6 Suka
Hadiah
6
4
Bagikan
Komentar
0/400
FloorSweeper
· 22jam yang lalu
Jangan tanya kenapa, L2 itu keren.
Lihat AsliBalas0
RamenDeFiSurvivor
· 22jam yang lalu
Wala L2 benar-benar harum
Lihat AsliBalas0
ShadowStaker
· 22jam yang lalu
hmm efisiensi mev di l2 masih perlu diperbaiki sejujurnya... topologi jaringan belum sepenuhnya tepat
Lihat AsliBalas0
BearMarketBuyer
· 22jam yang lalu
Apakah lapisan 2 masih kosong? Kita hanya melihat.
Ethereum Scaling New Phase: Analisis Kedalaman Peta Jalan The Surge
Masa Depan Ethereum yang Mungkin: The Surge
Peta jalan Ethereum awalnya mencakup dua strategi skalabilitas: sharding dan protokol Layer2. Sharding memungkinkan setiap node hanya perlu memverifikasi dan menyimpan sebagian transaksi, sedangkan Layer2 membangun jaringan di atas Ethereum, memanfaatkan keamanannya tetapi menjaga sebagian besar data dan perhitungan di luar rantai utama. Kedua metode ini akhirnya bergabung menjadi peta jalan yang berfokus pada Rollup, yang masih menjadi strategi skalabilitas Ethereum hingga 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 mengambil tugas untuk membantu ekosistem berkembang. Pola ini umum di masyarakat: sistem pengadilan (L1) ada untuk melindungi kontrak dan hak milik, sementara pengusaha (L2) membangun di atasnya, mendorong perkembangan manusia.
Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai kemajuan penting: peluncuran blob EIP-4844 secara signifikan meningkatkan bandwidth data Ethereum L1, dan beberapa Ethereum Virtual Machine (EVM) Rollup telah memasuki tahap pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika sendiri, dan keberagaman cara implementasi shard kini telah menjadi kenyataan. Namun, jalan ini juga menghadapi beberapa tantangan unik. Tugas kita sekarang adalah menyelesaikan peta jalan yang berfokus pada Rollup, mengatasi masalah ini, sambil menjaga ketahanan dan desentralisasi Ethereum L1.
The Surge: Tujuan Kunci
Paradoks Segitiga Skalabilitas
Paradoks segitiga skalabilitas berpendapat bahwa ada kontradiksi antara tiga fitur blockchain: desentralisasi ( biaya node operasional yang rendah ), skalabilitas ( jumlah transaksi yang dapat diproses banyak ) dan keamanan ( penyerang perlu merusak sebagian besar node di jaringan agar transaksi tunggal gagal ).
Paradoks segitiga bukanlah sebuah teorema, dan posting yang memperkenalkannya juga tidak menyertakan 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 menghancurkan sejumlah kecil node untuk melewati sebuah transaksi berbahaya, atau (ii) node Anda akan menjadi kuat, sementara rantai Anda tidak akan terdesentralisasi. Artikel ini bertujuan untuk menunjukkan bahwa memecahkan paradoks triad itu sulit, dan perlu untuk keluar dari 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 mengoptimalkan node. Ini selalu menyesatkan, menjalankan node di rantai ini jauh lebih sulit daripada menjalankan node di Ethereum.
Namun, perpaduan antara sampling ketersediaan data dan SNARKs memang menyelesaikan paradoks segitiga: ini memungkinkan klien untuk memverifikasi bahwa sejumlah data tersedia dan sejumlah langkah perhitungan dilakukan dengan benar hanya dengan mengunduh sedikit 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 dari rantai yang tidak dapat diskalakan, yaitu bahkan serangan 51% tidak dapat memaksa blok buruk diterima oleh jaringan.
Cara 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. Sejak 2017-2019, ketika kami hanya memiliki bukti penipuan sebagai cara untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan yang aman, tetapi dengan penyebaran SNARKs, arsitektur Plasma menjadi lebih layak untuk lebih banyak skenario penggunaan daripada sebelumnya.
Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data
Apa masalah yang sedang kita selesaikan?
Pada 13 Maret 2024, ketika peningkatan Dencun diluncurkan, blockchain Ethereum akan memiliki 3 blob sekitar 125 kB setiap 12 detik slot, atau bandwidth data yang tersedia per slot sekitar 375 kB. Dengan asumsi data transaksi diterbitkan langsung di rantai, transfer ERC20 sekitar 180 byte, maka 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 / setiap byte 16 gas = setiap slot 1.875.000 byte ), maka menjadi 607 TPS. Menggunakan PeerDAS, jumlah blob mungkin meningkat menjadi 8-16, yang akan memberikan 463-926 TPS untuk calldata.
Ini adalah peningkatan signifikan untuk Ethereum L1, tetapi masih belum cukup. Kami ingin lebih banyak skalabilitas. Tujuan jangka menengah kami adalah 16 MB per slot, dan jika digabungkan dengan perbaikan kompresi data Rollup, itu akan menghasilkan ~58000 TPS.
Apa itu? Bagaimana cara kerjanya?
PeerDAS adalah implementasi yang relatif sederhana dari "1D sampling". Di Ethereum, setiap blob adalah polinomial 4096 derajat dalam bidang prima 253 bit (. Kami menyiarkan shares polinomial, di mana setiap shares berisi 16 nilai evaluasi dari 16 koordinat yang bersebelahan dari total 8192 koordinat. Dari 8192 nilai evaluasi ini, 4096 mana pun ) dapat memulihkan blob berdasarkan parameter yang diajukan saat ini: 64 dari 128 kemungkinan sampel mana pun (.
Cara kerja PeerDAS adalah membuat setiap klien mendengarkan sejumlah kecil subnet, 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 lain yang dibutuhkannya di subnet yang berbeda. Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa pertanyaan tambahan ke lapisan rekan. Proposal saat ini adalah untuk membiarkan node yang berpartisipasi dalam proof of stake menggunakan SubnetDAS, sementara node lain ) yaitu klien ( menggunakan PeerDAS.
Secara teori, kita bisa memperluas skala "1D sampling" cukup besar: jika kita meningkatkan jumlah maksimum blob menjadi 256) dengan target 128(, maka kita bisa 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 bisa melakukan optimasi tertentu 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 )2D sampling(, metode ini tidak hanya melakukan pengambilan sampel acak dalam blob, tetapi juga melakukan pengambilan sampel acak antar blob. Dengan memanfaatkan sifat linear dari komitmen KZG, melalui satu set blob virtual baru untuk memperluas kumpulan blob dalam satu blok, 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 redundansi informasi yang sama.
Sangat penting untuk dicatat bahwa perluasan komitmen perhitungan tidak memerlukan blob, sehingga skema ini secara fundamental ramah terhadap pembangunan blok terdistribusi. Node yang sebenarnya membangun blok hanya perlu memiliki komitmen KZG blob, dan mereka dapat mengandalkan pengambilan sampel ketersediaan data )DAS( untuk memverifikasi ketersediaan blok data. Pengambilan sampel ketersediaan data satu dimensi )1DDAS( pada dasarnya juga ramah terhadap pembangunan blok terdistribusi.
![Vitalik baru: Masa depan Ethereum yang mungkin, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
) Apa yang masih perlu dilakukan? Apa saja pertimbangannya?
Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, jumlah blob di PeerDAS akan terus ditingkatkan, sambil secara cermat memantau jaringan dan memperbaiki perangkat lunak untuk memastikan keamanan, ini adalah proses bertahap. Sementara itu, kami berharap akan ada lebih banyak pekerjaan akademis untuk mengatur PeerDAS dan versi DAS lainnya serta interaksinya dengan masalah keamanan seperti aturan pemilihan fork.
Dalam tahap 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 solusi 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 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), tetapi kenyataannya, STARK hampir sebesar seluruh blob.
Jalur realitas jangka panjang yang saya pikirkan 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(.
![Vitalik baru: Masa depan Ethereum yang mungkin, The Surge])https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp(
) Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
Jika kompresi data direalisasikan, permintaan untuk DAS 2D akan berkurang, atau setidaknya akan tertunda, dan jika Plasma digunakan secara luas, permintaan akan berkurang lebih lanjut. DAS juga menantang protokol dan mekanisme pembangunan blockchain 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, kita mendapatkan:
16000000 / 12 / 180 = 7407 TPS
Jika kita tidak hanya dapat menyelesaikan masalah pembilang, tetapi juga masalah penyebut, sehingga setiap transaksi dalam Rollup menggunakan lebih sedikit byte di rantai, bagaimana jadinya?
( Apa itu, bagaimana cara kerjanya?
Menurut saya, penjelasan terbaik adalah gambar ini dari dua tahun yang lalu:
![Vitalik新文：Ethereum可能的未来，The Surge])https://img-cdn.gateio.im/webp-social/moments-a04daca8af5d6af3c06b77a97aae477d.webp###
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, karakteristik tanda tangan BLS adalah beberapa tanda tangan dapat digabungkan menjadi satu tanda tangan tunggal, tanda tangan ini dapat membuktikan semua yang asli.