Artikel Baru Vitalik: 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, sementara Layer2 membangun jaringan di atas Ethereum, memanfaatkan keamanannya sambil menjaga sebagian besar data dan perhitungan di luar rantai utama. Seiring dengan penelitian yang mendalam, kedua jalur ini bergabung, membentuk peta jalan yang berpusat pada Rollup, yang hingga kini masih merupakan strategi skalabilitas Ethereum.
Peta jalan yang berfokus pada Rollup mengusulkan pembagian kerja yang sederhana: Ethereum L1 fokus untuk menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 mengambil tugas membantu ekosistem untuk berkembang. Pola ini ada di mana-mana dalam masyarakat: keberadaan sistem pengadilan (L1) bukan untuk mengejar kecepatan dan efisiensi yang sangat tinggi, tetapi 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 Ethereum Virtual Machine (EVM) Rollup telah memasuki tahap pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika internalnya sendiri, dan keragaman serta 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 saat ini 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 perlu dipercaya, terbuka, dan tahan sensor );
Ethereum seharusnya terasa seperti sebuah ekosistem yang terintegrasi, bukan 34 blockchain yang berbeda.
Isi Bab Ini
Paradox segitiga skalabilitas
Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data
Kompresi Data
Plasma Tergeneralisasi
Sistem bukti L2 yang matang
Peningkatan Interoperabilitas L2
Eksekusi perluasan di L1
Paradoks Segitiga Skalabilitas
Paradoks trinitas skalabilitas adalah ide yang diajukan pada tahun 2017, yang berpendapat bahwa ada kontradiksi antara tiga karakteristik blockchain: desentralisasi ( lebih spesifiknya: biaya menjalankan node yang rendah ), skalabilitas ( jumlah transaksi yang diproses lebih 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 menyertakan bukti matematis. Itu memang memberikan argumen matematis heuristik: jika sebuah node yang ramah terdesentralisasi ( misalnya sebuah 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 sejumlah kecil node untuk melewati satu transaksi yang jahat, atau (ii) node Anda akan menjadi kuat, sementara rantai Anda tidak akan terdesentralisasi. Tujuan artikel ini bukan untuk membuktikan bahwa memecahkan paradoks segitiga itu tidak mungkin; sebaliknya, ini bertujuan untuk menunjukkan bahwa memecahkan paradoks tiga adalah sulit, dan itu memerlukan untuk 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 mendasar, 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 hal ini terjadi dan mengapa hanya dengan rekayasa perangkat lunak klien L1 saja tidak dapat menskalakan Ethereum?
Namun, penggabungan pengambilan sampel ketersediaan data dan SNARKs memang menyelesaikan paradoks segitiga: ini memungkinkan klien untuk memverifikasi sejumlah data yang tersedia dengan hanya mengunduh sedikit data dan melakukan sangat sedikit komputasi, serta memastikan sejumlah langkah komputasi dijalankan dengan benar. SNARKs tidak memerlukan kepercayaan. Pengambilan sampel ketersediaan data memiliki model kepercayaan few-of-N yang halus, tetapi 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 menyelesaikan dilema tiga arah adalah arsitektur Plasma, yang menggunakan teknik cerdas untuk mendorong tanggung jawab atas 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 pelaksanaan keamanan. Namun, dengan meningkatnya popularitas SNARKs( bukti non-interaktif yang ringkas dan tanpa pengetahuan), arsitektur Plasma menjadi lebih layak untuk berbagai skenario penggunaan yang lebih luas dibandingkan sebelumnya.
Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data
Apa masalah yang sedang kita 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 sekitar 375 kB per slot. Dengan asumsi data transaksi dipublikasikan langsung di blockchain, transfer ERC20 sekitar 180 byte, maka 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 / per 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 signifikan untuk Ethereum L1, tetapi belum cukup. Kami menginginkan lebih banyak skalabilitas. Target menengah kami adalah 16 MB per slot, dan jika digabungkan dengan perbaikan kompresi data Rollup, akan memberikan ~58000 TPS.
Apa itu? Bagaimana cara kerjanya?
PeerDAS adalah implementasi yang relatif sederhana dari "1D sampling". Di Ethereum, setiap blob adalah polinomial 4096 dalam bidang prima 253 bit (. 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 mana pun ) dapat memulihkan blob berdasarkan parameter yang diajukan saat ini: 64 dari 128 kemungkinan sampel (.
Cara kerja PeerDAS adalah untuk membuat setiap klien mendengarkan sejumlah subnet yang kecil, di mana subnet ke-i menyiarkan sampel ke-i dari blob mana pun, dan dengan menanyakan pihak-pihak di jaringan p2p global ) siapa yang akan mendengarkan subnet yang berbeda ( untuk meminta blob yang dibutuhkannya di subnet lain. Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa pertanyaan tambahan terhadap lapisan peer. Proposal saat ini adalah untuk membiarkan 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, di mana 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 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 antara blob. Dengan memanfaatkan sifat linier dari komitmen KZG, kami 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, 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.
Penting untuk dicatat bahwa perpanjangan komitmen tidak memerlukan blob, sehingga skema ini pada dasarnya bersahabat dengan pembangunan blok terdistribusi. Node yang benar-benar membangun blok hanya perlu memiliki komitmen KZG blob, dan mereka dapat mengandalkan pengambilan ketersediaan data )DAS( untuk memverifikasi ketersediaan blok data. Pengambilan ketersediaan data satu dimensi )1D DAS( pada dasarnya juga bersahabat dengan pembangunan blok terdistribusi.
) Apa yang masih perlu dilakukan? Apa saja pertimbangannya?
Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, terus meningkatkan jumlah blob di PeerDAS, sambil mengamati jaringan dengan cermat dan meningkatkan perangkat lunak untuk memastikan keamanan, ini adalah proses bertahap. Sementara itu, kami berharap ada lebih banyak kerja akademis untuk mengatur 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 atribut keamanannya. Kami juga berharap pada akhirnya dapat beralih dari KZG ke alternatif yang aman secara kuantum dan tidak memerlukan pengaturan tepercaya. Saat ini, kami masih belum jelas tentang solusi kandidat mana yang ramah terhadap pembangunan blok terdistribusi. Bahkan dengan penggunaan teknologi "brute force" yang mahal, yaitu menggunakan STARK rekursif untuk menghasilkan bukti validitas yang digunakan untuk membangun kembali baris dan kolom, itu tidak cukup untuk memenuhi kebutuhan, karena meskipun secara teknis, ukuran satu STARK adalah O(log)n### * log(log(n)( hash ( menggunakan STIR), tetapi secara praktis STARK hampir sebesar seluruh blob.
Jalur realitas jangka panjang yang saya maksud adalah:
Menerapkan DAS 2D yang ideal;
Tetap menggunakan 1D DAS, mengorbankan efisiensi bandwidth sampling, untuk kesederhanaan dan ketahanan menerima batas data yang lebih rendah.
Menyerahkan DA, sepenuhnya menerima Plasma sebagai arsitektur Layer2 utama yang menjadi 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 jumlah TPS yang besar, blok L1 akan menjadi sangat besar, klien akan ingin memiliki 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 kompresi data diterapkan, 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 teoritis ramah terhadap rekonstruksi terdistribusi, dalam praktiknya hal ini perlu dikombinasikan 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 chain: 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 dapat menyelesaikan masalah penyebut, sehingga setiap transaksi dalam Rollup memakan lebih sedikit byte di blockchain, bagaimana itu?
Apa itu, bagaimana cara kerjanya?
Menurut saya, penjelasan terbaik adalah gambar ini dari dua tahun lalu:
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:
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.
15 Suka
Hadiah
15
4
Bagikan
Komentar
0/400
CryptoTarotReader
· 07-22 16:59
Ini L2 akan To da moon ah
Lihat AsliBalas0
NightAirdropper
· 07-22 05:24
Gandi V Tuhan mulai menggambar BTC lagi
Lihat AsliBalas0
LayerZeroHero
· 07-19 20:54
Data tidak dapat berjalan, strategi pembagian kerja pasti akan menuju rollup
Lihat AsliBalas0
SilentObserver
· 07-19 20:50
Berbicara tanpa latihan, apa yang bisa diubah oleh V?
Vitalik Menafsirkan Masa Depan Ethereum: Terobosan Strategi The Surge dan Tiga Tantangan Skalabilitas
Artikel Baru Vitalik: 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, sementara Layer2 membangun jaringan di atas Ethereum, memanfaatkan keamanannya sambil menjaga sebagian besar data dan perhitungan di luar rantai utama. Seiring dengan penelitian yang mendalam, kedua jalur ini bergabung, membentuk peta jalan yang berpusat pada Rollup, yang hingga kini masih merupakan strategi skalabilitas Ethereum.
Peta jalan yang berfokus pada Rollup mengusulkan pembagian kerja yang sederhana: Ethereum L1 fokus untuk menjadi lapisan dasar yang kuat dan terdesentralisasi, sementara L2 mengambil tugas membantu ekosistem untuk berkembang. Pola ini ada di mana-mana dalam masyarakat: keberadaan sistem pengadilan (L1) bukan untuk mengejar kecepatan dan efisiensi yang sangat tinggi, tetapi 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 Ethereum Virtual Machine (EVM) Rollup telah memasuki tahap pertama. Setiap L2 ada sebagai "shard" dengan aturan dan logika internalnya sendiri, dan keragaman serta 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 saat ini 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 perlu dipercaya, terbuka, dan tahan sensor );
Ethereum seharusnya terasa seperti sebuah ekosistem yang terintegrasi, bukan 34 blockchain yang berbeda.
Isi Bab Ini
Paradoks Segitiga Skalabilitas
Paradoks trinitas skalabilitas adalah ide yang diajukan pada tahun 2017, yang berpendapat bahwa ada kontradiksi antara tiga karakteristik blockchain: desentralisasi ( lebih spesifiknya: biaya menjalankan node yang rendah ), skalabilitas ( jumlah transaksi yang diproses lebih 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 menyertakan bukti matematis. Itu memang memberikan argumen matematis heuristik: jika sebuah node yang ramah terdesentralisasi ( misalnya sebuah 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 sejumlah kecil node untuk melewati satu transaksi yang jahat, atau (ii) node Anda akan menjadi kuat, sementara rantai Anda tidak akan terdesentralisasi. Tujuan artikel ini bukan untuk membuktikan bahwa memecahkan paradoks segitiga itu tidak mungkin; sebaliknya, ini bertujuan untuk menunjukkan bahwa memecahkan paradoks tiga adalah sulit, dan itu memerlukan untuk 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 mendasar, 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 hal ini terjadi dan mengapa hanya dengan rekayasa perangkat lunak klien L1 saja tidak dapat menskalakan Ethereum?
Namun, penggabungan pengambilan sampel ketersediaan data dan SNARKs memang menyelesaikan paradoks segitiga: ini memungkinkan klien untuk memverifikasi sejumlah data yang tersedia dengan hanya mengunduh sedikit data dan melakukan sangat sedikit komputasi, serta memastikan sejumlah langkah komputasi dijalankan dengan benar. SNARKs tidak memerlukan kepercayaan. Pengambilan sampel ketersediaan data memiliki model kepercayaan few-of-N yang halus, tetapi 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 menyelesaikan dilema tiga arah adalah arsitektur Plasma, yang menggunakan teknik cerdas untuk mendorong tanggung jawab atas 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 pelaksanaan keamanan. Namun, dengan meningkatnya popularitas SNARKs( bukti non-interaktif yang ringkas dan tanpa pengetahuan), arsitektur Plasma menjadi lebih layak untuk berbagai skenario penggunaan yang lebih luas dibandingkan sebelumnya.
Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data
Apa masalah yang sedang kita 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 sekitar 375 kB per slot. Dengan asumsi data transaksi dipublikasikan langsung di blockchain, transfer ERC20 sekitar 180 byte, maka 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 / per 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 signifikan untuk Ethereum L1, tetapi belum cukup. Kami menginginkan lebih banyak skalabilitas. Target menengah kami adalah 16 MB per slot, dan jika digabungkan dengan perbaikan kompresi data Rollup, akan memberikan ~58000 TPS.
Apa itu? Bagaimana cara kerjanya?
PeerDAS adalah implementasi yang relatif sederhana dari "1D sampling". Di Ethereum, setiap blob adalah polinomial 4096 dalam bidang prima 253 bit (. 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 mana pun ) dapat memulihkan blob berdasarkan parameter yang diajukan saat ini: 64 dari 128 kemungkinan sampel (.
Cara kerja PeerDAS adalah untuk membuat setiap klien mendengarkan sejumlah subnet yang kecil, di mana subnet ke-i menyiarkan sampel ke-i dari blob mana pun, dan dengan menanyakan pihak-pihak di jaringan p2p global ) siapa yang akan mendengarkan subnet yang berbeda ( untuk meminta blob yang dibutuhkannya di subnet lain. Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa pertanyaan tambahan terhadap lapisan peer. Proposal saat ini adalah untuk membiarkan 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, di mana 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 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 antara blob. Dengan memanfaatkan sifat linier dari komitmen KZG, kami 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, 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.
Penting untuk dicatat bahwa perpanjangan komitmen tidak memerlukan blob, sehingga skema ini pada dasarnya bersahabat dengan pembangunan blok terdistribusi. Node yang benar-benar membangun blok hanya perlu memiliki komitmen KZG blob, dan mereka dapat mengandalkan pengambilan ketersediaan data )DAS( untuk memverifikasi ketersediaan blok data. Pengambilan ketersediaan data satu dimensi )1D DAS( pada dasarnya juga bersahabat dengan pembangunan blok terdistribusi.
) Apa yang masih perlu dilakukan? Apa saja pertimbangannya?
Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, terus meningkatkan jumlah blob di PeerDAS, sambil mengamati jaringan dengan cermat dan meningkatkan perangkat lunak untuk memastikan keamanan, ini adalah proses bertahap. Sementara itu, kami berharap ada lebih banyak kerja akademis untuk mengatur 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 atribut keamanannya. Kami juga berharap pada akhirnya dapat beralih dari KZG ke alternatif yang aman secara kuantum dan tidak memerlukan pengaturan tepercaya. Saat ini, kami masih belum jelas tentang solusi kandidat mana yang ramah terhadap pembangunan blok terdistribusi. Bahkan dengan penggunaan teknologi "brute force" yang mahal, yaitu menggunakan STARK rekursif untuk menghasilkan bukti validitas yang digunakan untuk membangun kembali baris dan kolom, itu tidak cukup untuk memenuhi kebutuhan, karena meskipun secara teknis, ukuran satu STARK adalah O(log)n### * log(log(n)( hash ( menggunakan STIR), tetapi secara praktis STARK hampir sebesar seluruh blob.
Jalur realitas jangka panjang yang saya maksud 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 jumlah TPS yang besar, blok L1 akan menjadi sangat besar, klien akan ingin memiliki 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 kompresi data diterapkan, 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 teoritis ramah terhadap rekonstruksi terdistribusi, dalam praktiknya hal ini perlu dikombinasikan 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 chain: 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 dapat menyelesaikan masalah penyebut, sehingga setiap transaksi dalam Rollup memakan lebih sedikit byte di blockchain, bagaimana itu?
Apa itu, bagaimana cara kerjanya?
Menurut saya, penjelasan terbaik adalah gambar ini dari dua tahun lalu:
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:
Penggabungan tanda tangan: Kami dari ECD