Peta jalan Ethereum awalnya mencakup dua strategi penskalaan: sharding dan protokol Layer 2. Seiring dengan penelitian yang lebih mendalam, kedua jalur ini bergabung menjadi peta jalan yang berpusat pada Rollup, yang masih menjadi strategi perluasan Ethereum saat ini.
Peta jalan yang berfokus pada Rollup mengusulkan pembagian kerja yang sederhana: Ethereum L1 fokus pada menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 bertanggung jawab untuk membantu ekosistem berkembang. Pola ini umum dalam masyarakat: keberadaan sistem pengadilan (L1) bukan untuk mengejar kecepatan dan efisiensi super, tetapi untuk melindungi kontrak dan hak milik, sementara para wirausaha (L2) harus membangun di atas lapisan dasar yang kokoh ini, mendorong perkembangan 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, dan beberapa Ethereum Virtual Machine (EVM) Rollup telah memasuki fase pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika internalnya sendiri, keberagaman 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 memerlukan kepercayaan, terbuka, dan tahan sensor );
Ethereum harus terasa seperti sebuah ekosistem yang terpadu, bukan 34 blockchain yang berbeda.
Isi Bab Ini
Paradox segitiga skalabilitas
Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data
Kompresi Data
Plasma Generalisasi
Sistem bukti L2 yang matang
Peningkatan interoperabilitas antar L2
Memperluas eksekusi di L1
Paradoks Segitiga Skalabilitas
Paradoks segitiga skalabilitas adalah sebuah ide yang diajukan pada tahun 2017, yang menyatakan bahwa ada kontradiksi antara tiga karakteristik blockchain: desentralisasi ( lebih spesifik: 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 dilengkapi dengan bukti matematis. Namun, ia memang memberikan argumen matematis yang bersifat heuristik: jika sebuah node yang ramah terhadap desentralisasi (, misalnya, laptop kelas konsumsi ) 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 sejumlah kecil node untuk melewati 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 itu tidak mungkin; sebaliknya, ia bertujuan untuk menunjukkan bahwa memecahkan paradoks tiga arah itu sulit, dan perlu untuk keluar dari kerangka pemikiran yang diimplikasikan oleh argumen tersebut.
Selama bertahun-tahun, beberapa rantai berkinerja tinggi sering mengklaim bahwa mereka telah menyelesaikan trilema blockchain 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 demikian, dan mengapa hanya dengan rekayasa perangkat lunak klien L1 saja tidak cukup untuk menskalakan Ethereum?
Namun, penggabungan sampling ketersediaan data dengan SNARKs memang menyelesaikan paradoks segitiga: ini memungkinkan klien untuk memverifikasi sejumlah data tersedia hanya dengan mengunduh sejumlah kecil data dan melakukan sangat sedikit perhitungan. SNARKs adalah tanpa kepercayaan. Sampling ketersediaan data memiliki model kepercayaan few-of-N yang halus, tetapi itu mempertahankan karakteristik dasar dari rantai yang tidak dapat diskalakan, yaitu bahkan serangan 51% tidak dapat memaksa blok yang buruk diterima oleh jaringan.
Salah satu cara lain untuk mengatasi tiga kesulitan adalah arsitektur Plasma, yang menggunakan teknologi cerdas untuk secara kompatibel mendorong tanggung jawab pemantauan ketersediaan data kepada pengguna. Sejak 2017-2019, ketika kita hanya memiliki bukti penipuan sebagai cara untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan yang aman, tetapi dengan munculnya SNARKs( bukti nol pengetahuan yang ringkas dan non-interaktif), arsitektur Plasma menjadi lebih layak untuk skenario penggunaan yang lebih luas daripada sebelumnya.
Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data
Apa masalah yang sedang kami selesaikan?
Pada tanggal 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. Jika data transaksi diterbitkan langsung di rantai, maka transfer ERC20 adalah 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. Menggunakan PeerDAS, jumlah blob dapat 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 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 derajat 4096 di atas bidang prima 253 (prime field). Kami menyiarkan shares polinomial, di mana setiap share berisi 16 nilai evaluasi dari 16 koordinat bertetangga di antara 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 ).
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 mereka butuhkan. Versi yang lebih konservatif SubnetDAS hanya menggunakan mekanisme subnet, tanpa menanyakan lapisan rekan tambahan. 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, di mana sampling ketersediaan data pada 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 dengan bandwidth terbatas tidak dapat melakukan sampling. Kita dapat melakukan optimasi 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 pengambilan sampel acak di dalam blob, tetapi juga melakukan pengambilan sampel acak antar blob. Dengan memanfaatkan sifat linier dari komitmen KZG, memperluas kumpulan blob dalam satu blok melalui satu set 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 pengambilan sampel 2D, yang tidak hanya melakukan pengambilan sampel 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 menyandikan informasi yang sama secara redundan.
Sangat penting untuk dicatat bahwa perpanjangan komitmen tidak memerlukan blob, sehingga skema ini pada dasarnya ramah terhadap pembangunan blok terdistribusi. Node yang benar-benar membangun blok hanya perlu memiliki komitmen blob KZG, dan mereka dapat bergantung pada 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, terus meningkatkan jumlah blob di PeerDAS, sambil mengamati jaringan dengan seksama dan memperbaiki perangkat lunak untuk memastikan keamanan, ini adalah proses bertahap. Pada saat yang sama, kami berharap ada lebih banyak pekerjaan akademis untuk menstandarkan 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 sifat keamanannya. Kami juga berharap pada akhirnya dapat beralih dari KZG ke solusi alternatif yang aman secara kuantum dan tidak memerlukan pengaturan yang dapat dipercaya. 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 STARK adalah O)log###n( * log(log)n(( hash ) menggunakan STIR), tetapi secara praktis STARK hampir sebesar seluruh blob.
Saya pikir jalur realitas jangka panjang adalah:
Melaksanakan DAS 2D yang ideal;
Terus gunakan 1D DAS,牺牲采样带宽效率, demi kesederhanaan dan ketahanan menerima batas data yang lebih rendah
Mengabaikan DA, sepenuhnya menerima Plasma sebagai arsitektur Layer2 utama yang menjadi fokus perhatian 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 banyak TPS, blok L1 akan menjadi sangat besar, klien akan menginginkan cara yang efisien untuk memverifikasi keakuratan mereka, 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 diimplementasikan, permintaan untuk 2D DAS akan berkurang, atau setidaknya akan tertunda, jika Plasma digunakan secara luas, maka permintaan akan berkurang lebih jauh. DAS juga menantang protokol dan mekanisme pembangunan blok terdistribusi: meskipun DAS secara teori ramah terhadap rekonstruksi terdistribusi, ini dalam praktiknya perlu dikombinasikan dengan proposal daftar inklusi paket dan mekanisme pemilihan fork di sekitarnya.
![Vitalik baru: Masa depan Ethereum yang mungkin, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
Kompresi Data
( Apa masalah yang kita selesaikan?
Setiap transaksi dalam Rollup akan memakan banyak ruang data di on-chain: transfer ERC20 memerlukan 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
Bagaimana jika kita tidak hanya dapat menyelesaikan masalah numerator, tetapi juga menyelesaikan masalah denominator, sehingga setiap transaksi dalam Rollup memakan lebih sedikit byte di rantai?
Apa itu, bagaimana cara kerjanya?
Menurut saya, penjelasan terbaik adalah gambar ini dua tahun yang lalu:
Dalam kompresi byte nol, setiap urutan byte nol yang panjang diganti dengan dua byte untuk menunjukkan berapa banyak byte nol. Lebih lanjut, kami memanfaatkan sifat khusus dari transaksi:
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.
11 Suka
Hadiah
11
3
Bagikan
Komentar
0/400
RuntimeError
· 07-14 20:38
Kerja bagus eth
Lihat AsliBalas0
ChainMelonWatcher
· 07-14 20:34
Lari cukup bisa diandalkan~
Lihat AsliBalas0
DegenWhisperer
· 07-14 20:27
Bermain dengan arsitektur berlapis di sini, menjelaskan dengan baik.
Ethereum The Surge: Dari 100.000 TPS hingga jalan perluasan ekosistem yang terintegrasi
Masa Depan Ethereum: The Surge
Peta jalan Ethereum awalnya mencakup dua strategi penskalaan: sharding dan protokol Layer 2. Seiring dengan penelitian yang lebih mendalam, kedua jalur ini bergabung menjadi peta jalan yang berpusat pada Rollup, yang masih menjadi strategi perluasan Ethereum saat ini.
Peta jalan yang berfokus pada Rollup mengusulkan pembagian kerja yang sederhana: Ethereum L1 fokus pada menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 bertanggung jawab untuk membantu ekosistem berkembang. Pola ini umum dalam masyarakat: keberadaan sistem pengadilan (L1) bukan untuk mengejar kecepatan dan efisiensi super, tetapi untuk melindungi kontrak dan hak milik, sementara para wirausaha (L2) harus membangun di atas lapisan dasar yang kokoh ini, mendorong perkembangan 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, dan beberapa Ethereum Virtual Machine (EVM) Rollup telah memasuki fase pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika internalnya sendiri, keberagaman 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 memerlukan kepercayaan, terbuka, dan tahan sensor );
Ethereum harus terasa seperti sebuah ekosistem yang terpadu, bukan 34 blockchain yang berbeda.
Isi Bab Ini
Paradoks Segitiga Skalabilitas
Paradoks segitiga skalabilitas adalah sebuah ide yang diajukan pada tahun 2017, yang menyatakan bahwa ada kontradiksi antara tiga karakteristik blockchain: desentralisasi ( lebih spesifik: 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 dilengkapi dengan bukti matematis. Namun, ia memang memberikan argumen matematis yang bersifat heuristik: jika sebuah node yang ramah terhadap desentralisasi (, misalnya, laptop kelas konsumsi ) 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 sejumlah kecil node untuk melewati 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 itu tidak mungkin; sebaliknya, ia bertujuan untuk menunjukkan bahwa memecahkan paradoks tiga arah itu sulit, dan perlu untuk keluar dari kerangka pemikiran yang diimplikasikan oleh argumen tersebut.
Selama bertahun-tahun, beberapa rantai berkinerja tinggi sering mengklaim bahwa mereka telah menyelesaikan trilema blockchain 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 demikian, dan mengapa hanya dengan rekayasa perangkat lunak klien L1 saja tidak cukup untuk menskalakan Ethereum?
Namun, penggabungan sampling ketersediaan data dengan SNARKs memang menyelesaikan paradoks segitiga: ini memungkinkan klien untuk memverifikasi sejumlah data tersedia hanya dengan mengunduh sejumlah kecil data dan melakukan sangat sedikit perhitungan. SNARKs adalah tanpa kepercayaan. Sampling ketersediaan data memiliki model kepercayaan few-of-N yang halus, tetapi itu mempertahankan karakteristik dasar dari rantai yang tidak dapat diskalakan, yaitu bahkan serangan 51% tidak dapat memaksa blok yang buruk diterima oleh jaringan.
Salah satu cara lain untuk mengatasi tiga kesulitan adalah arsitektur Plasma, yang menggunakan teknologi cerdas untuk secara kompatibel mendorong tanggung jawab pemantauan ketersediaan data kepada pengguna. Sejak 2017-2019, ketika kita hanya memiliki bukti penipuan sebagai cara untuk memperluas kapasitas komputasi, Plasma sangat terbatas dalam pelaksanaan yang aman, tetapi dengan munculnya SNARKs( bukti nol pengetahuan yang ringkas dan non-interaktif), arsitektur Plasma menjadi lebih layak untuk skenario penggunaan yang lebih luas daripada sebelumnya.
Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data
Apa masalah yang sedang kami selesaikan?
Pada tanggal 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. Jika data transaksi diterbitkan langsung di rantai, maka transfer ERC20 adalah 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. Menggunakan PeerDAS, jumlah blob dapat 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 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 derajat 4096 di atas bidang prima 253 (prime field). Kami menyiarkan shares polinomial, di mana setiap share berisi 16 nilai evaluasi dari 16 koordinat bertetangga di antara 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 ).
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 mereka butuhkan. Versi yang lebih konservatif SubnetDAS hanya menggunakan mekanisme subnet, tanpa menanyakan lapisan rekan tambahan. 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, di mana sampling ketersediaan data pada 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 dengan bandwidth terbatas tidak dapat melakukan sampling. Kita dapat melakukan optimasi 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 pengambilan sampel acak di dalam blob, tetapi juga melakukan pengambilan sampel acak antar blob. Dengan memanfaatkan sifat linier dari komitmen KZG, memperluas kumpulan blob dalam satu blok melalui satu set 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 pengambilan sampel 2D, yang tidak hanya melakukan pengambilan sampel 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 menyandikan informasi yang sama secara redundan.
Sangat penting untuk dicatat bahwa perpanjangan komitmen tidak memerlukan blob, sehingga skema ini pada dasarnya ramah terhadap pembangunan blok terdistribusi. Node yang benar-benar membangun blok hanya perlu memiliki komitmen blob KZG, dan mereka dapat bergantung pada 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, terus meningkatkan jumlah blob di PeerDAS, sambil mengamati jaringan dengan seksama dan memperbaiki perangkat lunak untuk memastikan keamanan, ini adalah proses bertahap. Pada saat yang sama, kami berharap ada lebih banyak pekerjaan akademis untuk menstandarkan 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 sifat keamanannya. Kami juga berharap pada akhirnya dapat beralih dari KZG ke solusi alternatif yang aman secara kuantum dan tidak memerlukan pengaturan yang dapat dipercaya. 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 STARK adalah O)log###n( * log(log)n(( hash ) menggunakan STIR), tetapi secara praktis STARK hampir sebesar seluruh blob.
Saya pikir 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 banyak TPS, blok L1 akan menjadi sangat besar, klien akan menginginkan cara yang efisien untuk memverifikasi keakuratan mereka, 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 diimplementasikan, permintaan untuk 2D DAS akan berkurang, atau setidaknya akan tertunda, jika Plasma digunakan secara luas, maka permintaan akan berkurang lebih jauh. DAS juga menantang protokol dan mekanisme pembangunan blok terdistribusi: meskipun DAS secara teori ramah terhadap rekonstruksi terdistribusi, ini dalam praktiknya perlu dikombinasikan dengan proposal daftar inklusi paket dan mekanisme pemilihan fork di sekitarnya.
![Vitalik baru: Masa depan Ethereum yang mungkin, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
Kompresi Data
( Apa masalah yang kita selesaikan?
Setiap transaksi dalam Rollup akan memakan banyak ruang data di on-chain: transfer ERC20 memerlukan 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
Bagaimana jika kita tidak hanya dapat menyelesaikan masalah numerator, tetapi juga menyelesaikan masalah denominator, sehingga setiap transaksi dalam Rollup memakan lebih sedikit byte di rantai?
Apa itu, bagaimana cara kerjanya?
Menurut saya, penjelasan terbaik adalah gambar ini dua tahun yang lalu:
Dalam kompresi byte nol, setiap urutan byte nol yang panjang diganti dengan dua byte untuk menunjukkan berapa banyak byte nol. Lebih lanjut, kami memanfaatkan sifat khusus dari transaksi:
Agregasi Tanda Tangan: Kami dari