Strategi skalabilitas Ethereum awalnya memiliki dua jenis: sharding dan Layer2. Sharding memungkinkan setiap node hanya perlu memverifikasi dan menyimpan sebagian kecil transaksi, sementara Layer2 mengalihkan sebagian besar data dan komputasi di luar rantai utama. Kedua jalur ini akhirnya bergabung, membentuk peta jalan yang berfokus pada Rollup, yang hingga saat ini masih merupakan strategi perluasan 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 bertanggung jawab untuk membantu ekosistem berkembang. Pola ini umum di masyarakat: sistem pengadilan (L1) ada untuk melindungi kontrak dan hak milik, sementara pengusaha (L2) membangun di atas dasar ini, mendorong perkembangan manusia.
Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai hasil penting: peluncuran EIP-4844 blobs secara signifikan meningkatkan bandwidth data Ethereum L1, dan beberapa EVM Rollup telah memasuki fase pertama. Setiap L2 ada sebagai "shard" yang memiliki aturan dan logika internal, dengan keragaman cara implementasi shard kini menjadi kenyataan. Namun, jalan ini juga menghadapi beberapa tantangan unik. Tugas kita sekarang adalah menyelesaikan peta jalan ini dan mengatasi masalah-masalah ini, sambil mempertahankan ketahanan dan desentralisasi Ethereum L1.
The Surge: Tujuan Kunci
Di masa depan, Ethereum dapat mencapai lebih dari 100.000 TPS melalui L2
Menjaga desentralisasi dan ketahanan L1
Setidaknya beberapa L2 sepenuhnya mewarisi atribut inti Ethereum ( untuk kepercayaan, terbuka, tahan sensor )
Ethereum seharusnya terasa seperti ekosistem yang terintegrasi, bukan 34 blockchain yang berbeda.
Isi Bab Ini
Paradoks Segitiga Skalabilitas
Kemajuan lebih lanjut dalam sampling ketersediaan data
Kompresi Data
Plasma Generalisasi
Sistem bukti L2 yang matang
Peningkatan Interoperabilitas L2
Eksekusi perluasan di L1
Paradoks Segitiga Skalabilitas
Paradoks segitiga skalabilitas berpendapat bahwa terdapat kontradiksi antara tiga karakteristik blockchain yaitu desentralisasi, skalabilitas, dan keamanan. Ini bukanlah sebuah teorema, melainkan memberikan sebuah argumen heuristik: jika sebuah node yang ramah desentralisasi dapat memverifikasi N transaksi per detik, dan Anda memiliki sebuah rantai yang dapat memproses k*N transaksi per detik, maka setiap transaksi hanya dapat dilihat oleh 1/k node, atau node Anda akan menjadi kuat, dan rantai tidak akan terdesentralisasi.
Beberapa rantai berkinerja tinggi mengklaim telah menyelesaikan paradoks trinitas, biasanya dengan mengoptimalkan perangkat lunak node. Namun, ini sering menyesatkan, menjalankan node di rantai ini lebih sulit dibandingkan di Ethereum. Hanya dengan rekayasa perangkat lunak klien L1 saja tidak cukup untuk menskalakan Ethereum.
Namun, kombinasi pengambilan sampel ketersediaan data dan SNARKs benar-benar menyelesaikan paradoks segitiga: itu memungkinkan klien untuk memverifikasi ketersediaan sejumlah besar data dan eksekusi langkah-langkah perhitungan dengan hanya mengunduh sejumlah kecil data dan melakukan sedikit perhitungan. 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.
Arsitektur Plasma adalah solusi lain yang mendelegasikan tanggung jawab untuk memantau ketersediaan data kepada pengguna. Dengan meningkatnya popularitas SNARKs, Plasma menjadi layak untuk berbagai skenario yang lebih luas.
Kemajuan lebih lanjut dalam sampling ketersediaan data
Masalah apa yang sedang kita selesaikan?
Setelah upgrade Dencun pada 13 Maret 2024, Ethereum memiliki 3 blob sekitar 125kB setiap slot 12 detik, dengan bandwidth data yang tersedia sekitar 375kB/slot. Jika data transaksi diterbitkan langsung di blockchain, transfer ERC20 sekitar 180 byte, maka maksimum TPS Rollup di Ethereum adalah 173,6.
Dengan menambahkan calldata, bisa mencapai 607 TPS. Menggunakan PeerDAS, jumlah blob bisa meningkat menjadi 8-16, memberikan 463-926 TPS untuk calldata.
Ini adalah peningkatan signifikan untuk L1, tetapi masih belum cukup. Tujuan jangka menengah kami adalah setiap slot 16MB, yang dikombinasikan dengan kompresi data Rollup, akan membawa ~58000 TPS.
Apa itu? Bagaimana cara kerjanya?
PeerDAS adalah implementasi sederhana dari "1D sampling". Di Ethereum, setiap blob adalah polinomial derajat 4096 di atas bidang bilangan prima 253. 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 di antaranya dapat digunakan untuk memulihkan blob.
PeerDAS memungkinkan setiap klien untuk mendengarkan sejumlah subnet, subnet ke-i menyiarkan sampel ke-i dari blob mana pun, dan meminta blob di subnet lain dengan menanyakan kepada rekan-rekan di jaringan p2p global. SubnetDAS hanya menggunakan mekanisme subnet tanpa tambahan pertanyaan ke lapisan rekan. Proposal saat ini memungkinkan node yang berpartisipasi dalam proof of stake untuk menggunakan SubnetDAS, sementara node lainnya menggunakan PeerDAS.
Secara teori, kita dapat memperluas skala "1D sampling" menjadi sangat besar: jika jumlah maksimum blob ditingkatkan menjadi 256, kita dapat mencapai target 16MB, dengan setiap node memerlukan bandwidth data 1MB per slot. Ini hampir bisa dilakukan, tetapi klien yang terbatas bandwidthnya tidak dapat melakukan sampling. Kita dapat mengoptimalkan dengan mengurangi jumlah blob dan meningkatkan ukuran blob, tetapi ini akan meningkatkan biaya rekonstruksi.
Oleh karena itu, kami akhirnya ingin melakukan sampling 2D, tidak hanya di dalam blob, tetapi juga melakukan sampling acak di antara blob. Dengan memanfaatkan sifat linier dari komitmen KZG, kami memperluas kumpulan blob dalam satu blok melalui blob virtual baru, di mana blob virtual ini secara redundan mengkodekan informasi yang sama.
Sampling 2D ramah untuk pembangunan blok terdistribusi. Node yang sebenarnya membangun blok hanya perlu komitmen KZG blob, dan dapat bergantung pada DAS untuk memverifikasi ketersediaan. DAS 1D pada dasarnya juga ramah untuk pembangunan blok terdistribusi.
Apa saja tautan dengan penelitian yang ada?
Memperkenalkan pos asli tentang ketersediaan data (2018)
Kertas tindak lanjut
Artikel penjelasan tentang DAS
Ketersediaan 2D dengan komitmen KZG
PeerDAS dan makalah di ethresear.ch
EIP-7594
SubnetDAS di ethresear.ch
Nuansa pemulihan dalam sampling 2D
Apa yang perlu dilakukan? Apa saja pertimbangannya?
Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, terus meningkatkan jumlah blob di PeerDAS, sambil memperhatikan jaringan dan memperbaiki perangkat lunak untuk memastikan keamanan. Kami berharap ada lebih banyak pekerjaan akademis untuk mengatur PeerDAS dan interaksinya dengan masalah keamanan seperti aturan pemilihan fork.
Ke depan, perlu untuk menentukan versi ideal dari 2D DAS dan membuktikan atribut keamanannya. Kami berharap pada akhirnya dapat beralih dari KZG ke solusi alternatif yang aman secara kuantum dan tidak memerlukan pengaturan terpercaya. Saat ini, tidak jelas solusi kandidat mana yang bersahabat dengan pembangunan blok terdistribusi.
Jalur kenyataan jangka panjang yang saya pikirkan 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
Bahkan jika kita memutuskan untuk memperluas eksekusi langsung di lapisan L1, pilihan ini tetap ada. Karena jika L1 harus menangani sejumlah besar TPS, blok L1 akan menjadi sangat besar, klien akan memerlukan metode verifikasi yang efisien, oleh karena itu kita harus menggunakan teknologi yang sama dengan Rollup di lapisan L1.
Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
Jika kompresi data diimplementasikan, permintaan untuk 2D DAS akan berkurang atau tertunda, dan jika Plasma digunakan secara luas, permintaan akan berkurang lebih lanjut. DAS juga menantang protokol dan mekanisme pembangunan blockchain terdistribusi: meskipun DAS secara teori ramah untuk rekonstruksi terdistribusi, dalam praktiknya perlu dikombinasikan dengan proposal daftar inklusi paket dan mekanisme pemilihan fork di sekitarnya.
Kompresi Data
Apa masalah yang sedang kita selesaikan?
Dalam Rollup, setiap transaksi menggunakan banyak ruang data on-chain: transfer ERC20 memerlukan sekitar 180 byte. Bahkan dengan pengambilan data yang ideal, ini membatasi skalabilitas protokol Layer. Setiap slot 16MB, kita mendapatkan:
16000000 / 12 / 180 = 7407 TPS
Apa yang akan terjadi jika kita bisa membuat transaksi di Rollup menggunakan lebih sedikit byte di blockchain?
Apa itu, bagaimana cara kerjanya?
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: beralih dari ECDSA ke tanda tangan BLS, beberapa tanda tangan dapat digabungkan menjadi satu tanda tangan tunggal, membuktikan keabsahan semua tanda tangan asli. Di L1, karena biaya perhitungan verifikasi yang tinggi, BLS tidak dipertimbangkan untuk digunakan, tetapi di L2, di mana data langka, penggunaan BLS menjadi masuk akal. Fitur agregasi ERC-4337 menyediakan cara untuk mewujudkan fungsi ini.
Ganti alamat dengan pointer: Jika alamat tertentu pernah digunakan sebelumnya, kita dapat mengganti alamat 20 byte dengan pointer 4 byte yang menunjuk ke posisi tertentu dalam riwayat.
Serialisasi kustom nilai transaksi: Sebagian besar jumlah nilai transaksi memiliki sedikit digit, seperti 0,25 ETH yang dinyatakan sebagai 250.000.000.000.000.000 wei. Biaya dasar maksimum dan biaya prioritas juga serupa. Oleh karena itu, kita dapat menggunakan format floating point desimal kustom untuk menyatakan sebagian besar nilai mata uang.
Apa saja tautan dengan penelitian yang ada?
Jelajahi sequence.xyz
Optimisasi Kontrak L2 Calldata
Perbedaan status rilis Rollups berdasarkan bukti keefektifan daripada transaksi
Dompet BLS - Mewujudkan agregasi BLS melalui ERC-4337
apa yang perlu dilakukan, apa saja pertimbangannya?
Selanjutnya, fokus utama adalah implementasi nyata dari rencana di atas. Pertimbangan utama termasuk:
Beralih ke tanda tangan BLS memerlukan usaha besar, dan akan mengurangi kompatibilitas dengan chip perangkat keras tepercaya. Paket ZK-SNARK dengan skema tanda tangan lainnya dapat digunakan sebagai pengganti.
Kompresi dinamis ( jika menggantikan alamat dengan pointers ) akan membuat kode klien menjadi lebih kompleks.
Menerbitkan perbedaan status ke dalam rantai daripada transaksi, akan mengurangi auditabilitas, membuat banyak perangkat lunak ( seperti penjelajah blok ) tidak dapat berfungsi.
Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
Menggunakan ERC-4337 dan akhirnya mengintegrasikan sebagian ke dalam L2 EVM dapat mempercepat penerapan teknologi agregasi secara signifikan. Menempatkan sebagian ERC-4337 di L1 dapat mempercepat penerapannya di L2.
Plasma Generalisasi
Masalah apa yang sedang kita selesaikan?
Bahkan dengan penggunaan blob 16MB dan kompresi data, 58.000 TPS mungkin tidak sepenuhnya memenuhi kebutuhan di bidang berkapasitas tinggi seperti pembayaran konsumen dan media sosial terdesentralisasi, terutama mengingat faktor privasi yang dapat mengurangi skalabilitas hingga 3-8 kali lipat. Saat ini, pilihan untuk skenario volume transaksi tinggi dan nilai rendah adalah Validium, yang menyimpan data di luar rantai, menggunakan model keamanan: operator tidak dapat mencuri dana pengguna, tetapi mungkin dapat membekukan semua dana pengguna sementara atau permanen. Namun, kita bisa melakukan yang lebih baik.
Apa itu, bagaimana cara kerjanya?
Plasma adalah solusi skalabilitas, di mana operator menerbitkan blok di luar rantai dan hanya menempatkan akar Merkle dari blok-blok tersebut di dalam rantai. Untuk setiap blok, operator mengirimkan cabang Merkle kepada setiap pengguna untuk membuktikan perubahan atau ketidakberubahan aset pengguna tersebut. Pengguna dapat menarik aset dengan menyediakan cabang Merkle. Penting untuk dicatat bahwa cabang ini tidak harus memiliki status terbaru sebagai akar. Oleh karena itu, bahkan jika ada masalah dengan ketersediaan data, pengguna masih dapat memulihkan aset dengan menarik status terbaru yang tersedia. Jika pengguna mengirimkan cabang yang tidak valid, kepemilikan aset dapat ditentukan melalui mekanisme tantangan di dalam rantai.
Versi awal Plasma hanya dapat menangani kasus pembayaran, tidak dapat dipromosikan secara efektif. Namun
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.
Ethereum The Surge: Tantangan dan Target Skalabilitas 100.000 TPS melalui L2
Masa Depan Ethereum yang Mungkin: The Surge
Strategi skalabilitas Ethereum awalnya memiliki dua jenis: sharding dan Layer2. Sharding memungkinkan setiap node hanya perlu memverifikasi dan menyimpan sebagian kecil transaksi, sementara Layer2 mengalihkan sebagian besar data dan komputasi di luar rantai utama. Kedua jalur ini akhirnya bergabung, membentuk peta jalan yang berfokus pada Rollup, yang hingga saat ini masih merupakan strategi perluasan 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 bertanggung jawab untuk membantu ekosistem berkembang. Pola ini umum di masyarakat: sistem pengadilan (L1) ada untuk melindungi kontrak dan hak milik, sementara pengusaha (L2) membangun di atas dasar ini, mendorong perkembangan manusia.
Tahun ini, peta jalan yang berfokus pada Rollup telah mencapai hasil penting: peluncuran EIP-4844 blobs secara signifikan meningkatkan bandwidth data Ethereum L1, dan beberapa EVM Rollup telah memasuki fase pertama. Setiap L2 ada sebagai "shard" yang memiliki aturan dan logika internal, dengan keragaman cara implementasi shard kini menjadi kenyataan. Namun, jalan ini juga menghadapi beberapa tantangan unik. Tugas kita sekarang adalah menyelesaikan peta jalan ini dan mengatasi masalah-masalah ini, sambil mempertahankan ketahanan dan desentralisasi Ethereum L1.
The Surge: Tujuan Kunci
Isi Bab Ini
Paradoks Segitiga Skalabilitas
Paradoks segitiga skalabilitas berpendapat bahwa terdapat kontradiksi antara tiga karakteristik blockchain yaitu desentralisasi, skalabilitas, dan keamanan. Ini bukanlah sebuah teorema, melainkan memberikan sebuah argumen heuristik: jika sebuah node yang ramah desentralisasi dapat memverifikasi N transaksi per detik, dan Anda memiliki sebuah rantai yang dapat memproses k*N transaksi per detik, maka setiap transaksi hanya dapat dilihat oleh 1/k node, atau node Anda akan menjadi kuat, dan rantai tidak akan terdesentralisasi.
Beberapa rantai berkinerja tinggi mengklaim telah menyelesaikan paradoks trinitas, biasanya dengan mengoptimalkan perangkat lunak node. Namun, ini sering menyesatkan, menjalankan node di rantai ini lebih sulit dibandingkan di Ethereum. Hanya dengan rekayasa perangkat lunak klien L1 saja tidak cukup untuk menskalakan Ethereum.
Namun, kombinasi pengambilan sampel ketersediaan data dan SNARKs benar-benar menyelesaikan paradoks segitiga: itu memungkinkan klien untuk memverifikasi ketersediaan sejumlah besar data dan eksekusi langkah-langkah perhitungan dengan hanya mengunduh sejumlah kecil data dan melakukan sedikit perhitungan. 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.
Arsitektur Plasma adalah solusi lain yang mendelegasikan tanggung jawab untuk memantau ketersediaan data kepada pengguna. Dengan meningkatnya popularitas SNARKs, Plasma menjadi layak untuk berbagai skenario yang lebih luas.
Kemajuan lebih lanjut dalam sampling ketersediaan data
Masalah apa yang sedang kita selesaikan?
Setelah upgrade Dencun pada 13 Maret 2024, Ethereum memiliki 3 blob sekitar 125kB setiap slot 12 detik, dengan bandwidth data yang tersedia sekitar 375kB/slot. Jika data transaksi diterbitkan langsung di blockchain, transfer ERC20 sekitar 180 byte, maka maksimum TPS Rollup di Ethereum adalah 173,6.
Dengan menambahkan calldata, bisa mencapai 607 TPS. Menggunakan PeerDAS, jumlah blob bisa meningkat menjadi 8-16, memberikan 463-926 TPS untuk calldata.
Ini adalah peningkatan signifikan untuk L1, tetapi masih belum cukup. Tujuan jangka menengah kami adalah setiap slot 16MB, yang dikombinasikan dengan kompresi data Rollup, akan membawa ~58000 TPS.
Apa itu? Bagaimana cara kerjanya?
PeerDAS adalah implementasi sederhana dari "1D sampling". Di Ethereum, setiap blob adalah polinomial derajat 4096 di atas bidang bilangan prima 253. 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 di antaranya dapat digunakan untuk memulihkan blob.
PeerDAS memungkinkan setiap klien untuk mendengarkan sejumlah subnet, subnet ke-i menyiarkan sampel ke-i dari blob mana pun, dan meminta blob di subnet lain dengan menanyakan kepada rekan-rekan di jaringan p2p global. SubnetDAS hanya menggunakan mekanisme subnet tanpa tambahan pertanyaan ke lapisan rekan. Proposal saat ini memungkinkan node yang berpartisipasi dalam proof of stake untuk menggunakan SubnetDAS, sementara node lainnya menggunakan PeerDAS.
Secara teori, kita dapat memperluas skala "1D sampling" menjadi sangat besar: jika jumlah maksimum blob ditingkatkan menjadi 256, kita dapat mencapai target 16MB, dengan setiap node memerlukan bandwidth data 1MB per slot. Ini hampir bisa dilakukan, tetapi klien yang terbatas bandwidthnya tidak dapat melakukan sampling. Kita dapat mengoptimalkan dengan mengurangi jumlah blob dan meningkatkan ukuran blob, tetapi ini akan meningkatkan biaya rekonstruksi.
Oleh karena itu, kami akhirnya ingin melakukan sampling 2D, tidak hanya di dalam blob, tetapi juga melakukan sampling acak di antara blob. Dengan memanfaatkan sifat linier dari komitmen KZG, kami memperluas kumpulan blob dalam satu blok melalui blob virtual baru, di mana blob virtual ini secara redundan mengkodekan informasi yang sama.
Sampling 2D ramah untuk pembangunan blok terdistribusi. Node yang sebenarnya membangun blok hanya perlu komitmen KZG blob, dan dapat bergantung pada DAS untuk memverifikasi ketersediaan. DAS 1D pada dasarnya juga ramah untuk pembangunan blok terdistribusi.
Apa saja tautan dengan penelitian yang ada?
Apa yang perlu dilakukan? Apa saja pertimbangannya?
Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, terus meningkatkan jumlah blob di PeerDAS, sambil memperhatikan jaringan dan memperbaiki perangkat lunak untuk memastikan keamanan. Kami berharap ada lebih banyak pekerjaan akademis untuk mengatur PeerDAS dan interaksinya dengan masalah keamanan seperti aturan pemilihan fork.
Ke depan, perlu untuk menentukan versi ideal dari 2D DAS dan membuktikan atribut keamanannya. Kami berharap pada akhirnya dapat beralih dari KZG ke solusi alternatif yang aman secara kuantum dan tidak memerlukan pengaturan terpercaya. Saat ini, tidak jelas solusi kandidat mana yang bersahabat dengan pembangunan blok terdistribusi.
Jalur kenyataan jangka panjang yang saya pikirkan adalah:
Bahkan jika kita memutuskan untuk memperluas eksekusi langsung di lapisan L1, pilihan ini tetap ada. Karena jika L1 harus menangani sejumlah besar TPS, blok L1 akan menjadi sangat besar, klien akan memerlukan metode verifikasi yang efisien, oleh karena itu kita harus menggunakan teknologi yang sama dengan Rollup di lapisan L1.
Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
Jika kompresi data diimplementasikan, permintaan untuk 2D DAS akan berkurang atau tertunda, dan jika Plasma digunakan secara luas, permintaan akan berkurang lebih lanjut. DAS juga menantang protokol dan mekanisme pembangunan blockchain terdistribusi: meskipun DAS secara teori ramah untuk rekonstruksi terdistribusi, dalam praktiknya perlu dikombinasikan dengan proposal daftar inklusi paket dan mekanisme pemilihan fork di sekitarnya.
Kompresi Data
Apa masalah yang sedang kita selesaikan?
Dalam Rollup, setiap transaksi menggunakan banyak ruang data on-chain: transfer ERC20 memerlukan sekitar 180 byte. Bahkan dengan pengambilan data yang ideal, ini membatasi skalabilitas protokol Layer. Setiap slot 16MB, kita mendapatkan:
16000000 / 12 / 180 = 7407 TPS
Apa yang akan terjadi jika kita bisa membuat transaksi di Rollup menggunakan lebih sedikit byte di blockchain?
Apa itu, bagaimana cara kerjanya?
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: beralih dari ECDSA ke tanda tangan BLS, beberapa tanda tangan dapat digabungkan menjadi satu tanda tangan tunggal, membuktikan keabsahan semua tanda tangan asli. Di L1, karena biaya perhitungan verifikasi yang tinggi, BLS tidak dipertimbangkan untuk digunakan, tetapi di L2, di mana data langka, penggunaan BLS menjadi masuk akal. Fitur agregasi ERC-4337 menyediakan cara untuk mewujudkan fungsi ini.
Ganti alamat dengan pointer: Jika alamat tertentu pernah digunakan sebelumnya, kita dapat mengganti alamat 20 byte dengan pointer 4 byte yang menunjuk ke posisi tertentu dalam riwayat.
Serialisasi kustom nilai transaksi: Sebagian besar jumlah nilai transaksi memiliki sedikit digit, seperti 0,25 ETH yang dinyatakan sebagai 250.000.000.000.000.000 wei. Biaya dasar maksimum dan biaya prioritas juga serupa. Oleh karena itu, kita dapat menggunakan format floating point desimal kustom untuk menyatakan sebagian besar nilai mata uang.
Apa saja tautan dengan penelitian yang ada?
apa yang perlu dilakukan, apa saja pertimbangannya?
Selanjutnya, fokus utama adalah implementasi nyata dari rencana di atas. Pertimbangan utama termasuk:
Beralih ke tanda tangan BLS memerlukan usaha besar, dan akan mengurangi kompatibilitas dengan chip perangkat keras tepercaya. Paket ZK-SNARK dengan skema tanda tangan lainnya dapat digunakan sebagai pengganti.
Kompresi dinamis ( jika menggantikan alamat dengan pointers ) akan membuat kode klien menjadi lebih kompleks.
Menerbitkan perbedaan status ke dalam rantai daripada transaksi, akan mengurangi auditabilitas, membuat banyak perangkat lunak ( seperti penjelajah blok ) tidak dapat berfungsi.
Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
Menggunakan ERC-4337 dan akhirnya mengintegrasikan sebagian ke dalam L2 EVM dapat mempercepat penerapan teknologi agregasi secara signifikan. Menempatkan sebagian ERC-4337 di L1 dapat mempercepat penerapannya di L2.
Plasma Generalisasi
Masalah apa yang sedang kita selesaikan?
Bahkan dengan penggunaan blob 16MB dan kompresi data, 58.000 TPS mungkin tidak sepenuhnya memenuhi kebutuhan di bidang berkapasitas tinggi seperti pembayaran konsumen dan media sosial terdesentralisasi, terutama mengingat faktor privasi yang dapat mengurangi skalabilitas hingga 3-8 kali lipat. Saat ini, pilihan untuk skenario volume transaksi tinggi dan nilai rendah adalah Validium, yang menyimpan data di luar rantai, menggunakan model keamanan: operator tidak dapat mencuri dana pengguna, tetapi mungkin dapat membekukan semua dana pengguna sementara atau permanen. Namun, kita bisa melakukan yang lebih baik.
Apa itu, bagaimana cara kerjanya?
Plasma adalah solusi skalabilitas, di mana operator menerbitkan blok di luar rantai dan hanya menempatkan akar Merkle dari blok-blok tersebut di dalam rantai. Untuk setiap blok, operator mengirimkan cabang Merkle kepada setiap pengguna untuk membuktikan perubahan atau ketidakberubahan aset pengguna tersebut. Pengguna dapat menarik aset dengan menyediakan cabang Merkle. Penting untuk dicatat bahwa cabang ini tidak harus memiliki status terbaru sebagai akar. Oleh karena itu, bahkan jika ada masalah dengan ketersediaan data, pengguna masih dapat memulihkan aset dengan menarik status terbaru yang tersedia. Jika pengguna mengirimkan cabang yang tidak valid, kepemilikan aset dapat ditentukan melalui mekanisme tantangan di dalam rantai.
Versi awal Plasma hanya dapat menangani kasus pembayaran, tidak dapat dipromosikan secara efektif. Namun