Artikel baru dari Vitalik: Masa Depan yang Mungkin bagi Ethereum, The Surge

Terima kasih khusus kepada Justin Drake, Francesco, Hsiao-wei Wang, @antonttc, dan Georgios Konstantopoulos.

Awalnya, ada dua strategi penskalaan dalam peta jalan ETH. Satu (lihat makalah sebelumnya dari 2015) adalah “sharding”: setiap Node hanya perlu memvalidasi dan menyimpan sebagian kecil transaksi, daripada memvalidasi dan menyimpan semua transaksi dalam rantai. Jaringan peer-to-peer lainnya (misalnya BitTorrent) bekerja dengan cara ini, jadi kita pasti bisa membuat blockchain bekerja dengan cara yang sama. Yang lainnya adalah protokol Layer2: jaringan ini akan ditempatkan di atas kotak ETH, memungkinkan mereka untuk sepenuhnya mendapatkan keuntungan dari keamanan mereka sambil menjaga sebagian besar data dan perhitungan di luar mainchain. Layer2 protokol mengacu pada saluran negara pada tahun 2015, Plasma pada tahun 2017, dan kemudian Rollup pada tahun 2019. Rollup lebih kuat daripada saluran negara atau plasma, tetapi mereka membutuhkan banyak bandwidth data on-chain. Untungnya, pada tahun 2019, studi Sharding telah memecahkan masalah verifikasi “ketersediaan data” dalam skala besar. Hasilnya, kedua jalur bergabung, dan kami mendapatkan peta jalan Rollup-sentris yang masih menjadi strategi penskalaan ETHFANG saat ini.

The Surge, peta jalan 2023

Rencana jalan yang berpusat pada Rollup mengusulkan pembagian kerja yang sederhana: ETH blockchain L1 fokus pada menjadi lapisan dasar yang kuat dan desentralisasi, sementara L2 bertanggung jawab untuk membantu memperluas ekosistem. Pola ini umum terjadi di masyarakat: keberadaan sistem pengadilan (L1) bukanlah untuk mencari kecepatan dan efisiensi tinggi, tetapi untuk melindungi kontrak dan hak milik, sementara pengusaha (L2) harus membangun di atas lapisan dasar yang kokoh ini, membawa manusia menuju Mars, baik secara harfiah maupun dalam arti kiasan.

Pada tahun ini, roadmap berbasis Rollup mencapai hasil yang signifikan: dengan peluncuran EIP-4844 blobs, bandwidth data ETH L1 meningkat secara signifikan, beberapa Ethereum Virtual Machine (EVM) Rollup telah memasuki tahap pertama. Setiap L2 eksis sebagai ‘Sharding’ dengan aturan dan logika internalnya sendiri, diversitas dan pluralitas dalam implementasi Sharding kini menjadi kenyataan. Namun seperti yang kita lihat, ada tantangan unik dalam mengikuti jalur ini. Oleh karena itu, tugas kita sekarang adalah menyelesaikan roadmap berbasis Rollup ini dan menyelesaikan masalah-masalah tersebut, sambil tetap mempertahankan kestabilan dan desentralisasi yang khas dari ETH L1.

The Surge: Target Kunci

1. Di masa depan, Ethereum dapat mencapai lebih dari 100.000 TPS melalui L2;

2、Memastikan Desentralisasi dan ketahanan L1 tetap terjaga;

3. Setidaknya beberapa L2 sepenuhnya mewarisi properti inti Ethereum (Trustless, terbuka, tahan sensor) ;

4. Ethereum seharusnya terasa seperti satu ekosistem yang terpadu, bukan 34 rantai blok yang berbeda.

Konten Bab Ini

1. Paradoks Segitiga Skalabilitas

2. Kemajuan lebih lanjut dalam pengambilan sampel ketersediaan data

3. Kompresi Data

4. Generalized Plasma

5. Sistem bukti L2 yang matang

6. Peningkatan Interoperabilitas L2 Cross

7. Memperluas eksekusi di L1

Paradoks Segitiga Skalabilitas

Trilema skalabilitas adalah sebuah gagasan yang diusulkan pada tahun 2017, yang menyatakan bahwa ada kontradiksi di antara tiga karakteristik blockchain: Desentralisasi (secara khusus, biaya rendah untuk menjalankan Node), skalabilitas (banyak transaksi yang dapat diolah), dan keamanan (penyerang perlu merusak sebagian besar Node dalam jaringan untuk membuat satu transaksi gagal).

Perlu diperhatikan bahwa paradoks segitiga bukanlah sebuah teorema, dan posting yang menjelaskan paradoks segitiga tidak dilengkapi dengan bukti matematika. Ini memang memberikan argumen matematis heuristik: Jika sebuah Node yang ramah terhadap Desentralisasi (misalnya laptop konsumen) dapat memverifikasi N transaksi per detik, dan Anda memiliki rantai yang memproses k*N transaksi per detik, maka (i) setiap transaksi hanya dapat dilihat oleh 1/k Node, yang berarti penyerang hanya perlu merusak beberapa Node untuk melakukan transaksi jahat, atau (ii) Node Anda akan menjadi kuat, tetapi rantai Anda tidak akan Desentralisasi. Tujuan artikel ini bukanlah membuktikan bahwa memecahkan paradoks segitiga adalah tidak mungkin; sebaliknya, tujuannya adalah menunjukkan bahwa memecahkan paradoks ini sulit dan memerlukan keluar dari kerangka berpikir yang tersirat dalam argumen tersebut.

Selama bertahun-tahun, beberapa rantai kinerja tinggi sering mengklaim bahwa mereka telah menyelesaikan paradoks tiga elemen tanpa mengubah arsitektur secara mendasar, biasanya dengan mengoptimalkan Node melalui teknik rekayasa perangkat lunak. Ini selalu menyesatkan, karena menjalankan Node on-chain jauh lebih sulit daripada menjalankan Node di Etherum. Artikel ini akan membahas mengapa hal ini terjadi, dan mengapa hanya dengan rekayasa perangkat lunak klien L1 saja tidak dapat memperluas Etherum.

Namun, penggabungan sampel ketersediaan data dengan SNARKs memang mengatasi paradoks segitiga: itu memungkinkan klien untuk memverifikasi ketersediaan sejumlah data dan jumlah langkah komputasi yang benar dilakukan dengan hanya mengunduh sejumlah kecil data dan melakukan sejumlah kecil komputasi. SNARKs adalah tidak terpercaya. Sampel ketersediaan data memiliki model kepercayaan few-of-N yang halus, tetapi tetap mempertahankan fitur dasar dari rantai yang tidak dapat diperluas, yaitu bahkan serangan 51% pun tidak dapat memaksa blok yang buruk diterima oleh jaringan.

Salah satu cara lain untuk mengatasi kesulitan tiga adalah arsitektur Plasma, yang menggunakan teknologi canggih untuk mendorong tanggung jawab ketersediaan data pengawasan secara kompatibel ke pengguna. Pada tahun 2017-2019, ketika satu-satunya cara kami untuk memperluas kemampuan komputasi adalah dengan bukti penipuan, Plasma sangat terbatas dalam hal pelaksanaan yang aman, tetapi dengan semakin luasnya penggunaan SNARKs (Zero Knowledge Succinct Non-interactive Argument of Knowledge), arsitektur Plasma menjadi lebih layak untuk berbagai skenario penggunaan daripada sebelumnya.

Kemajuan Lebih Lanjut dalam Sampel Ketersediaan Data

Apa masalah yang sedang kami selesaikan?

Pada tanggal 13 Maret 2024, ketika Dencun ditingkatkan, ada sekitar 3 blob sekitar 125 kB dalam slot setiap 12 detik di blockchain Ether, atau bandwidth data sekitar 375 kB per slot. Jika data transaksi dipublikasikan secara langsung di on-chain, maka transfer ERC20 akan memakan sekitar 180 byte, sehingga TPS maksimum Rollup di Ether adalah: 375.000 / 12 / 180 = 173,6 TPS.

Jika kita menambahkan calldata Ethereum (nilai teoritis maksimum: 30 juta Gas per slot / 16 gas per byte = 1.875.000 byte per slot), maka akan menjadi 607 TPS. Dengan menggunakan PeerDAS, jumlah blob mungkin akan meningkat menjadi 8-16, yang akan memberikan 463-926 TPS untuk calldata.

Ini adalah peningkatan besar-besaran untuk Ethereum L1, tetapi masih belum mencukupi. Kami ingin lebih skalabilitas. Target menengah kami adalah setiap slot 16 MB, yang jika digabungkan dengan perbaikan kompresi data Rollup, akan menghasilkan ~58000 TPS.

Apa itu? Bagaimana cara kerjanya?

PeerDAS adalah implementasi yang relatif sederhana dari ‘sampling 1D’. Di dalam blok Ethereum, setiap blob adalah polinomial derajat 4096 di atas lapangan prima 253-bit. Kami menyebarkan bagian-bagian polinomial, di mana setiap bagian mencakup 16 nilai evaluasi dari 16 koordinat yang berdekatan dari total 8192 koordinat. Dari 8192 nilai evaluasi ini, setiap 4096 (sesuai dengan parameter yang diajukan saat ini: 64 dari 128 sampel yang mungkin) dapat memulihkan blob.

Prinsip kerja PeerDAS adalah dengan membiarkan setiap klien mendengarkan subnet dalam jumlah sedikit, di mana subnet ke-i menyiarkan sampel ke-i dari setiap blob, dan meminta blob di subnet lain yang dibutuhkan dengan mengajukan pertanyaan kepada mitra di jaringan P2P global (yang mendengarkan subnet yang berbeda). Versi yang lebih konservatif, SubnetDAS, hanya menggunakan mekanisme subnet tanpa lapisan pertanyaan tambahan. Proposal saat ini adalah untuk menggunakan SubnetDAS oleh Node yang berpartisipasi dalam Proof of Stake, sementara Node lainnya (yaitu klien) menggunakan PeerDAS.

Secara teori, kita dapat memperluas skala “1D sampling” menjadi sangat besar: jika kita meningkatkan jumlah blob maksimum menjadi 256 (dari target 128), maka kita dapat mencapai target 16MB, sementara ketersediaan data sampling setiap Node 16 sampel * 128 blob * setiap sampel blob 512 byte = bandwidth data 1 MB per slot. Ini hanya sebatas toleransi kita: ini memungkinkan, tetapi berarti klien dengan bandwidth terbatas tidak dapat melakukan sampling. Kita dapat melakukan optimasi dalam hal ini dengan mengurangi jumlah blob dan meningkatkan ukuran blob, tetapi itu akan meningkatkan biaya pembangunan kembali.

Oleh karena itu, pada akhirnya kami ingin melangkah lebih jauh dengan melakukan sampel 2D (2D sampling), di mana metode ini tidak hanya melakukan sampel acak di dalam blob, tetapi juga di antara blob. Dengan memanfaatkan sifat linearitas komitmen KZG, kami dapat memperluas kumpulan blob dalam sebuah Blok melalui serangkaian blob virtual baru yang redundan secara kodrat memperluas informasi yang sama.

Oleh karena itu, pada akhirnya kami ingin melanjutkan lebih lanjut dengan melakukan sampling 2D, yang tidak hanya dalam blob tetapi juga antara blob secara acak. Properti linear yang dijanjikan oleh KZG digunakan untuk memperluas kumpulan blob dalam satu Blok, yang mencakup daftar blob virtual baru yang mengkodekan informasi yang sama secara redundan.

2D sampling. Sumber data: a16z crypto

Penting untuk dicatat bahwa ekstensi komitmen perhitungan tidak memerlukan blok, sehingga solusi ini pada dasarnya ramah terhadap konstruksi Blok terdistribusi. Node Blok yang benar-benar dibangun hanya perlu memiliki komitmen blob KZG, dan mereka dapat bergantung pada sampel ketersediaan data (DAS) untuk memverifikasi ketersediaan blok data. Sampel ketersediaan data satu dimensi (1D DAS) juga pada dasarnya ramah terhadap konstruksi blok terdistribusi.

Apa keterkaitan dengan penelitian yang ada?

1. Memperkenalkan posting asli ketersediaan data (2018):

2. Kertas tindak lanjut:

3. Tentang artikel penjelasan DAS, paradigma:

4. Ketersediaan 2D dengan jaminan KZG:

5. PeerDAS di ethresear.ch: Dan paper:

6.EIP-7594:

7. SubnetDAS di ethresear.ch:

8.2D Perbedaan Halus dalam Kehandalan Sampel ulang:

Masih perlu apa lagi? Apa saja pertimbangannya?

Selanjutnya adalah menyelesaikan implementasi dan peluncuran PeerDAS. Setelah itu, terus meningkatkan jumlah blob di PeerDAS sambil memperhatikan jaringan dengan baik dan memperbaiki perangkat lunak untuk memastikan keamanan, ini adalah proses yang bertahap. Pada saat yang sama, kami berharap ada lebih banyak pekerjaan akademik untuk mengatur interaksi PeerDAS dan versi DAS lainnya serta masalah keamanan dengan aturan pemilihan fork.

Di masa depan yang lebih jauh, kami perlu melakukan lebih banyak pekerjaan untuk menentukan versi ideal 2D DAS dan membuktikan sifat keamanannya. Kami juga berharap akhirnya dapat beralih dari KZG ke solusi alternatif yang aman secara kuantum dan tidak memerlukan pengaturan terpercaya. Saat ini, kami belum yakin solusi calon mana yang ramah terhadap konstruksi Blok terdistribusi. Bahkan dengan menggunakan teknik ‘brute force’ yang mahal, yaitu menggunakan STARK rekursif untuk menghasilkan bukti validitas yang digunakan untuk merekonstruksi baris dan kolom, tidak cukup memenuhi kebutuhan, karena meskipun secara teknis ukuran STARK adalah O(log(n) * log(log(n)) nilai hash (menggunakan STIR), namun sebenarnya STARK hampir sama besarnya dengan seluruh blob).

Saya percaya jalur realitas jangka panjang adalah:

1. Menerapkan DAS 2D yang ideal;

2. Bertahan menggunakan 1D DAS, mengorbankan efisiensi bandwidth sampling, menerima batas data yang lebih rendah untuk kesederhanaan dan ketahanan yang lebih baik.

3.（Hard pivot）放弃 DA，完全接受 Plasma 作为我们ikuti的主要 Layer2 架构。

Harap dicatat bahwa pilihan untuk melakukan ekspansi langsung pada lapisan L1 masih ada. Hal ini disebabkan oleh fakta bahwa jika lapisan L1 harus menangani TPS yang besar, Blok L1 akan menjadi sangat besar, dan klien akan menginginkan cara yang efisien untuk memverifikasi kebenarannya, sehingga kita harus menggunakan teknologi yang sama dengan Rollup (seperti ZK-EVM dan DAS) di lapisan L1.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Jika implementasi kompresi data, permintaan untuk 2D DAS akan berkurang, atau setidaknya akan latensi, jika Plasma digunakan secara luas, permintaan akan semakin berkurang. DAS juga menantang konstruksi protokol dan mekanisme Blok terdistribusi: meskipun DAS secara teoritis ramah terhadap rekonstruksi terdistribusi, namun dalam praktiknya perlu dikombinasikan dengan proposal daftar inklusi paket dan mekanisme pemilihan fork di sekitarnya.

Kompresi Data

Apa masalah yang sedang kita selesaikan?

Setiap transaksi dalam Rollup akan menggunakan banyak ruang data on-chain: Transfer ERC20 membutuhkan sekitar 180 byte. Meskipun ada pengambilan sampel ketersediaan data yang ideal, ini membatasi skalabilitas Layer protokol. Dengan setiap slot berukuran 16 MB, kita mendapatkan:

16000000 / 12 / 180 = 7407 TPS

Jika kita tidak hanya dapat memecahkan masalah pembilang, tetapi juga dapat memecahkan masalah penyebut, sehingga setiap transaksi dalam Rollup menggunakan lebih sedikit byte di on-chain, apa yang akan terjadi?

Apa itu dan 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 menggunakan properti khusus transaksi:

Agregasi Tanda Tangan: Kami beralih dari tanda tangan ECDSA ke tanda tangan BLS, di mana fitur tanda tangan BLS memungkinkan beberapa tanda tangan digabungkan menjadi satu tanda tangan tunggal yang dapat membuktikan validitas semua tanda tangan asli. Di tingkat L1, karena biaya komputasi verifikasi tetap tinggi bahkan setelah agregasi, penggunaan tanda tangan BLS tidak dipertimbangkan. Namun, di lingkungan seperti L2 di mana data jarang, penggunaan tanda tangan BLS memiliki makna. Fitur agregasi ERC-4337 memberikan cara untuk mewujudkan fungsi ini.

Mengganti Alamat dengan pointers: Jika kita pernah menggunakan suatu Alamat sebelumnya, kita dapat menggantikan 20 byte Alamat dengan pointer 4 byte yang menunjuk ke lokasi tertentu dalam riwayat.

Serialisasi kustom dari nilai transaksi - Sebagian besar nilai transaksi memiliki jumlah digit yang sedikit, misalnya, 0,25 ETH direpresentasikan sebagai 250.000.000.000.000.000 wei. Biaya dasar maksimum dan biaya prioritas juga serupa. Oleh karena itu, kita dapat menggunakan format desimal floating point kustom untuk merepresentasikan sebagian besar nilai mata uang.

Apa keterkaitan dengan penelitian yang ada?

1. Jelajahi sequence.xyz:

2. Optimalisasi kontrak L2 Calldata:

3. Rollups berbasis bukti validitas (juga dikenal sebagai ZK rollups) membedakan status peluncuran bukan transaksi:

4. Dompet BLS - Menggabungkan BLS melalui ERC-4337:

Apa lagi yang perlu dilakukan dan ada pertimbangan apa saja?

Selanjutnya, yang utama adalah untuk mengimplementasikan rencana di atas. Pertimbangan utama termasuk:

1、Beralih ke tanda tangan BLS memerlukan usaha yang besar dan dapat menurunkan kompatibilitas dengan chip keras tepercaya yang dapat meningkatkan keamanan. Ini dapat digantikan dengan bungkus ZK-SNARK yang menggunakan skema tanda tangan lainnya.

2、Kompresi dinamis (misalnya, mengganti Alamat dengan pointers) akan membuat kode klien menjadi kompleks.

3. Mempublikasikan perbedaan status ke on-chain bukan transaksi akan mengurangi auditabilitas dan membuat banyak perangkat lunak (seperti blockchain explorer) tidak dapat berfungsi.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Mengadopsi ERC-4337, dan akhirnya memasukkan sebagian isinya ke dalam L2 EVM, dapat secara signifikan mempercepat implementasi teknologi agregasi. Menempatkan sebagian konten ERC-4337 di L1 dapat mempercepat implementasinya di L2.

Plasma Generalis

Apa masalah yang sedang kami selesaikan?

Meskipun menggunakan blob 16 MB dan kompresi data, 58.000 TPS mungkin tidak cukup untuk sepenuhnya memenuhi kebutuhan pembayaran konsumen, Desentralisasi sosial, atau bidang berkecepatan tinggi lainnya, terutama ketika kita mulai mempertimbangkan faktor privasi, yang dapat mengurangi skalabilitas hingga 3-8 kali. Untuk skenario aplikasi dengan volume tinggi dan nilai rendah, satu pilihan saat ini adalah menggunakan Validium, yang menyimpan data off-chain dan mengadopsi model keamanan menarik: operator tidak dapat mencuri dana pengguna, tetapi mereka mungkin sementara atau secara permanen membekukan semua dana pengguna. Namun, kita dapat melakukan yang lebih baik.

Apa itu, bagaimana cara kerjanya?

Plasma adalah solusi scaling yang melibatkan operator mengirimkan Blok ke off-chain, dan menempatkan akar Merkle dari Blok-blok tersebut ke on-chain (berbeda dengan Rollup, Rollup akan menempatkan seluruh Blok ke on-chain). Untuk setiap Blok, operator akan mengirimkan cabang Merkle ke setiap pengguna untuk membuktikan perubahan aset pengguna, atau bahwa tidak ada perubahan. Pengguna dapat menarik aset mereka dengan menyediakan cabang Merkle. Yang penting, cabang ini tidak perlu berakar pada status terbaru. Oleh karena itu, bahkan jika ketersediaan data bermasalah, pengguna masih dapat memulihkan aset mereka dengan menarik status terbaru yang tersedia. Jika pengguna mengirimkan cabang yang tidak valid (misalnya, menarik aset yang sudah mereka berikan kepada orang lain, atau operator menciptakan aset secara sembrono), maka validitas vesting aset dapat ditentukan melalui mekanisme tantangan on-chain.

Rantai Plasma Cash 图。交易花费硬币 i 被放置在树的第 i 位置。在此示例中，假设所有先前的树都有效，我们知道 Eve 当前拥有Token 1，David 拥有Token 4，George 拥有Token 6。

Versi Plasma awal hanya dapat menangani kasus pembayaran dan tidak dapat diperluas secara efektif. Namun, jika kita meminta setiap akar untuk diverifikasi dengan SNARK, maka Plasma akan menjadi jauh lebih kuat. Setiap permainan tantangan dapat disederhanakan secara signifikan karena sebagian besar kemungkinan kecurangan operator dapat dieliminasi. Pada saat yang sama, ini juga membuka jalan baru untuk memperluas Plasma ke kategori aset yang lebih luas. Akhirnya, dalam kasus operator tidak melakukan kecurangan, pengguna dapat segera menarik dana tanpa harus menunggu periode tantangan selama satu minggu.

Metode untuk membuat rantai EVM Plasma (bukan satu-satunya metode): Membangun pohon UTXO paralel dengan ZK-SNARK yang mencerminkan perubahan saldo yang dilakukan oleh EVM dan mendefinisikan pemetaan unik ‘Token yang sama’ pada titik waktu historis yang berbeda. Kemudian Plasma dapat dibangun di atasnya.

Satu wawasan kunci adalah bahwa sistem Plasma tidak perlu sempurna. Bahkan jika Anda hanya dapat melindungi subset aset (misalnya, Token yang tidak bergerak dalam seminggu terakhir), Anda telah secara signifikan meningkatkan status quo EVM super skalabel saat ini (yaitu Validium).

Jenis struktur lainnya adalah campuran Plasma/Rollup, seperti Intmax. Konstruksi ini akan menempatkan sejumlah kecil data dari setiap pengguna ke on-chain (misalnya, 5 byte), yang memungkinkan untuk mendapatkan beberapa fitur di antara Plasma dan Rollup: dalam kasus Intmax, Anda dapat mencapai skalabilitas dan privasi yang sangat tinggi, meskipun dalam teori juga terbatas sekitar 16,000,000 / 12 / 5 = 266,667 TPS bahkan dalam kapasitas 16 MB.

Apa saja tautan terkait dengan penelitian yang ada?

1. Kertas Plasma Asli:

2.Plasma Cash:

3. Aliran Kas Plasma Cash:

4.Intmax (2023):

Apa lagi yang perlu dilakukan? Apa saja pertimbangannya?

Tugas utama yang tersisa adalah mengimplementasikan sistem Plasma ke dalam aplikasi produksi nyata. Seperti yang telah disebutkan sebelumnya, Plasma dan Validium bukanlah pilihan yang mutlak: Setiap Validium dapat meningkatkan keamanannya setidaknya dalam beberapa hal dengan mengintegrasikan fitur Plasma ke dalam mekanisme keluar. Fokus penelitian adalah mendapatkan properti terbaik untuk EVM (dalam hal kebutuhan kepercayaan, biaya Gas L1 dalam skenario terburuk, dan kemampuan melawan serangan DoS), serta struktur aplikasi alternatif. Selain itu, rumitnya konsep Plasma dibandingkan dengan Rollup memerlukan penelitian dan konstruksi kerangka kerja umum yang lebih baik untuk penyelesaiannya secara langsung.

The main trade-offs designed with Plasma are that they rely more on operators and are more difficult to base, although the hybrid Plasma/Rollup design can often avoid this weakness.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Semakin efektif solusi Plasma, semakin sedikit tekanan pada ketersediaan data berkinerja tinggi L1. Memindahkan aktivitas ke L2 juga dapat mengurangi tekanan MEV di L1.

Sistem bukti L2 yang matang

Apa masalah yang sedang kami selesaikan?

Saat ini, sebagian besar Rollup sebenarnya belum Trustless. Ada sebuah komite keamanan yang memiliki kemampuan untuk menggantikan perilaku sistem bukti (optimis atau validitas). Dalam beberapa kasus, sistem bukti bahkan tidak berjalan sama sekali, atau jika berjalan, hanya memiliki fungsi ‘konsultasi’. Rollup yang paling canggih termasuk: (i) beberapa Rollup khusus aplikasi Trustless, seperti Fuel; (ii) Optimism dan Arbitrum pada saat penulisan artikel ini, adalah dua implementasi ‘Fase 1’ dari Rollup EVM penuh yang sebagian Trustless. Alasan kurangnya kemajuan dalam Rollup adalah kekhawatiran terhadap bug dalam kode. Kita membutuhkan Rollup yang Trustless, jadi masalah ini harus dihadapi dan dipecahkan.

Apa itu, bagaimana cara kerjanya?

Pertama-tama, mari kita tinjau sistem ‘stage’ yang diperkenalkan awalnya dalam teks ini.

Tahap 0: Pengguna harus dapat menjalankan Node dan menyinkronkan rantai. Jika verifikasi sepenuhnya dapat dipercaya / terpusat, itu juga tidak masalah.

Tahap 1: Harus ada sistem bukti (tanpa kepercayaan) yang memastikan hanya transaksi yang valid yang akan diterima. Diizinkan adanya dewan keamanan yang dapat membatalkan sistem bukti, tetapi harus ada ambang batas voting 75%. Selain itu, bagian quorum-blocking di dewan (yaitu 26%+) harus berada di luar perusahaan induk Rollup yang sedang dibangun. Mekanisme peningkatan yang lebih lemah (misalnya DAO) diizinkan, tetapi harus memiliki latensi yang cukup lama sehingga pengguna dapat menarik dananya sebelum dana mereka masuk jika ada peningkatan yang jahat disetujui.

Tahap 2: Harus ada sistem bukti (tanpa kepercayaan) yang memastikan hanya transaksi yang valid yang akan diterima. Dewan Keamanan hanya mengizinkan intervensi ketika ada kesalahan yang dapat dibuktikan dalam kode, misalnya. Jika dua sistem bukti yang redundan saling bertentangan, atau jika satu sistem bukti menerima dua post-state root yang berbeda dari Blok yang sama (atau tidak menerima apa pun untuk jangka waktu yang cukup lama, misalnya seminggu). Peningkatan mekanisme diizinkan, namun harus memiliki latensi yang sangat panjang.

Tujuan kami adalah mencapai Tahap 2. Tantangan utama dalam mencapai Tahap 2 adalah memperoleh cukup kepercayaan untuk membuktikan bahwa sistem ini benar-benar dapat dipercaya. Ada dua metode utama untuk melakukan hal ini:

1. Verifikasi Formal: Kami dapat menggunakan matematika modern dan teknologi komputasi untuk membuktikan (optimistic dan validity) sistem bukti hanya menerima Blok yang sesuai dengan spesifikasi EVM. Teknologi ini telah ada selama beberapa dekade, tetapi kemajuan terbaru (seperti Lean 4) membuatnya lebih praktis, dan kemajuan dalam bukti AI yang dibantu mungkin akan lebih mempercepat tren ini.

2. Multi-provers: Membuat beberapa sistem pembuktian dan mengalokasikan dana ke sistem-sistem pembuktian ini bersama dengan komite keamanan (atau alat kecil lainnya yang memiliki asumsi kepercayaan, seperti TEE). Jika sistem pembuktian setuju, komite keamanan tidak memiliki kekuasaan; jika mereka tidak setuju, komite keamanan hanya dapat memilih di antara salah satunya, mereka tidak dapat memaksakan jawaban mereka sendiri.

Grafik formal para pemilik banyak bukti validitas, menggabungkan sistem bukti optimis, sistem bukti validitas, dan komite keamanan.

Apa keterkaitan dengan penelitian yang ada?

1. Semantik K EVM (pekerjaan verifikasi formal dari tahun 2017):

2. Presentasi tentang gagasan beberapa bukti (2022):

3. Rencananya menggunakan bukti ganda:

Apa lagi yang perlu dilakukan? Apa saja pertimbangannya?

Untuk Verifikasi Formal, pekerjaannya sangat besar. Kami perlu membuat versi verifikasi formal dari SNARK yang mencakup seluruh Ethereum Virtual Machine (EVM). Ini adalah proyek yang sangat kompleks, meskipun kami telah memulainya. Ada trik yang dapat sangat menyederhanakan tugas ini: kami dapat membuat SNARK prover yang diformalkan untuk Virtual Machine yang terminimalisasi (misalnya RISC-V atau Cairo), lalu mengimplementasikan EVM di dalam Virtual Machine tersebut (dan membuktikan secara formal bahwa itu setara dengan spesifikasi Ethereum Virtual Machine lainnya).

Untuk multi-proof, masih ada dua bagian utama yang belum selesai. Pertama, kita perlu memiliki kepercayaan yang cukup terhadap setidaknya dua sistem bukti yang berbeda, untuk memastikan bahwa keduanya sama-sama aman dan bahwa jika ada masalah, masalah-masalah ini harus berbeda dan tidak terkait satu sama lain (sehingga mereka tidak akan muncul bersamaan). Kedua, kita perlu memiliki tingkat kepercayaan yang sangat tinggi terhadap logika dasar sistem bukti tergabung ini. Bagian kode ini harus lebih sedikit. Ada beberapa cara untuk membuatnya sangat kecil, dengan menyimpan dana dalam kontrak multi-tanda tangan yang aman yang berfungsi sebagai penandatangan dari masing-masing sistem bukti yang diwakili, tetapi ini akan meningkatkan biaya Gas on-chain. Kita perlu menemukan keseimbangan antara efisiensi dan keamanan.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Mengalihkan aktivitas ke L2 dapat Mengurangi Tekanan MEV di L1.

Peningkatan Interoperabilitas L2

Apa masalah yang sedang kami selesaikan?

Tantangan utama yang dihadapi oleh ekosistem L2 saat ini adalah sulitnya pengguna untuk menavigasi di dalamnya. Selain itu, cara yang paling mudah seringkali akan memperkenalkan asumsi kepercayaan kembali: Interaksi Cross-Chain yang terpusat, klien RPC, dan sebagainya. Kita perlu membuat pengalaman menggunakan ekosistem L2 terasa seperti menggunakan satu ekosistem Ethereum yang terpadu.

Apa itu? Bagaimana cara kerjanya?

Peningkatan interoperabilitas L2 lintas memiliki banyak jenis. Secara teoritis, pusat ETH rollup-terpusat dan pelaksanaan Sharding L1 adalah hal yang sama. Ekosistem L2 ETH saat ini masih memiliki kekurangan dari keadaan ideal dalam praktiknya:

1、Alamat khusus rantai: Alamat harus mencakup informasi rantai (L1, Optimism, Arbitrum……). Begitu ini tercapai, proses pengiriman lintas L2 dapat dicapai dengan mudah dengan memasukkan Alamat ke dalam bidang ‘Kirim’, saat itu Dompet dapat secara otomatis menangani bagaimana mengirimnya (termasuk menggunakan protokol Interaksi cross-chain).

2. Permintaan pembayaran pada rantai tertentu: Harus mampu dengan mudah dan standar membuat pesan yang berbentuk ‘Kirimkan X Y ke saya di rantai Z’. Ini memiliki dua aplikasi utama: (i) Pembayaran antar individu atau pembayaran kepada layanan pedagang; (ii) Permintaan dana dari DApp.

3、Interaksi cross-chain exchange dan pembayaran gas: harus ada protokol terbuka standar untuk mengungkapkan interaksi operasi cross-chain, seperti “saya akan mengirimkan 1 ether (di Optimism) kepada orang yang mengirimkan 0.9999 ether kepada saya di Arbitrum”, dan “saya akan mengirimkan 0.0001 ether (di Optimism) kepada orang yang memasukkan transaksi ini di Arbitrum”. ERC-7683 adalah upaya untuk yang pertama, sedangkan RIP-7755 adalah upaya untuk yang kedua, meskipun keduanya memiliki ruang lingkup aplikasi yang lebih luas daripada kasus penggunaan tertentu ini.

4、light client：Pengguna harus dapat memverifikasi secara nyata rantai yang mereka interaksikan, bukan hanya bergantung pada penyedia RPC. Helios a16z crypto dapat melakukan hal ini (untuk ETH sendiri), tetapi kita perlu memperluas sifat tidak terpercaya ini ke L2. ERC-3668 (CCIP-read) adalah salah satu strategi untuk mencapai tujuan ini.

Bagaimana cara light client memperbarui pandangan Ethereum header chain-nya. Setelah memiliki header chain, Anda dapat menggunakan bukti Merkle untuk memverifikasi setiap objek status. Begitu Anda memiliki objek status L1 yang benar, Anda dapat menggunakan bukti Merkle (jika Anda ingin memeriksa pra-konfirmasi, Anda juga dapat menggunakan tanda tangan) untuk memverifikasi setiap objek status di L2. Helios telah mencapai yang pertama. Memperluas ke yang terakhir adalah tantangan standarisasi.

1. Keystore Dompet: Sekarang, jika Anda ingin memperbarui Kunci Rahasia Dompet Anda yang mengendalikan Smart ContractDompet Anda, Anda harus memperbarui di semua rantai di mana Dompet tersebut ada. Keystore Dompet adalah teknologi yang memungkinkan Kunci Rahasia hanya ada di satu tempat (entah di L1 atau mungkin di L2 di masa depan), dan kemudian L2 mana pun yang memiliki salinan Dompet dapat membaca Kunci Rahasia dari sana. Ini berarti pembaruan hanya perlu dilakukan sekali. Untuk meningkatkan efisiensi, Keystore Dompet mengharuskan L2 memiliki cara standar untuk membaca informasi dari L1 tanpa biaya; ada dua proposal untuk ini, yaitu L1SLOAD dan REMOTESTATICCALL.

Prinsip Kerja Dompet Keystore

2、Konsep ‘jembatan Token berbagi’ yang lebih agresif: Bayangkan, di dunia di mana semua L2 adalah bukti validitas Rollup dan setiap slot mengirimkan ke blok ETH. Bahkan di dunia seperti itu, untuk mentransfer aset dari satu L2 ke L2 lainnya dalam keadaan asli, Anda masih perlu menarik dan menyimpannya, yang memerlukan pembayaran biaya Gas L1 yang besar. Salah satu cara untuk mengatasi masalah ini adalah dengan menciptakan Rollup bersama yang sangat sederhana, yang satu-satunya fungsinya adalah menjaga setiap jenis Token dimiliki oleh L2 mana dan seberapa banyak saldo yang dimilikinya, dan memungkinkan saldo ini diperbarui secara massal melalui serangkaian operasi transfer lintas L2 yang diluncurkan oleh setiap L2. Ini akan memungkinkan transfer lintas L2 tanpa perlu membayar biaya gas L1 setiap kali, dan tanpa perlu menggunakan teknologi berbasis Penyedia Likuiditas seperti ERC-7683.

3. Komposisi Sinkronisasi: Memungkinkan pemanggilan sinkronisasi antara L2 spesifik dan L1 atau antara beberapa L2. Ini membantu meningkatkan efisiensi keuangan Keuangan Desentralisasi protokol. Yang pertama dapat dicapai tanpa koordinasi lintas L2 apa pun; yang terakhir membutuhkan urutan yang dibagikan. Teknologi berbasis Rollup secara otomatis berlaku untuk semua teknologi ini.

Apa keterkaitan dengan penelitian yang ada?

1. Alamat khusus rantai: ERC-3770:

2.ERC-7683:

3.RIP-7755:

4. Gulir ke tata letak Dompet kunci：

5. Helios:

6.ERC-3668（kadang-kadang disebut sebagai CCIP Read）：

7. Usulan 'Pre-Commitment (Berbagi) ’ oleh Justin Drake:

8.L1SLOAD (RIP-7728):

9.REMOTESTATICCALL di Optimism:

10.AggLayer，其中包括共享代币桥的想法：

Apa lagi yang perlu dilakukan? Apa saja pertimbangannya?

Banyak contoh di atas menghadapi dilema kapan standarisasi harus dilakukan dan standarisasi pada lapisan mana. Jika standarisasi dilakukan terlalu dini, itu dapat mengakibatkan solusi yang kurang baik menjadi terakar. Jika standarisasi dilakukan terlambat, itu dapat mengakibatkan fragmentasi yang tidak perlu. Dalam beberapa kasus, ada solusi jangka pendek yang lebih lemah namun lebih mudah diimplementasikan, dan ada solusi jangka panjang yang ‘benar secara definitif’ namun memerlukan beberapa tahun untuk diimplementasikan.

Tugas-tugas ini bukan hanya masalah teknis, tetapi juga masalah sosial (bahkan mungkin utamanya), membutuhkan kerjasama L2 dan Dompet serta L1.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Sebagian besar proposal ini adalah struktur ‘tingkat lebih tinggi’, sehingga pengaruhnya terhadap pertimbangan tingkat L1 tidak begitu besar. Salah satu pengecualian adalah urutan bersama, yang memiliki dampak besar pada maximal extractable value (MEV).

Memperluas Eksekusi di L1

Apa masalah yang sedang kami selesaikan?

Jika L2 menjadi sangat skalabel dan berhasil, tetapi L1 masih hanya dapat mengolah volume yang sangat sedikit, maka Ethereum mungkin akan menghadapi banyak risiko:

1. Keadaan ekonomi aset ETH akan menjadi lebih tidak stabil, yang pada gilirannya akan mempengaruhi keamanan jangka panjang jaringan.

2. Banyak L2 mendapat manfaat dari keterhubungan yang erat dengan ekosistem keuangan yang sangat berkembang di L1. Jika ekosistem ini melemah secara signifikan, insentif menjadi L2 (bukan menjadi L1 terpisah) akan berkurang.

3, L2 membutuhkan waktu yang cukup lama untuk mencapai tingkat keamanan yang sama dengan L1.

4、Jika L2 gagal (misalnya, karena perilaku jahat atau menghilangnya operator), pengguna masih perlu memulihkan aset mereka melalui L1. Oleh karena itu, L1 perlu cukup kuat, setidaknya kadang-kadang dapat menangani pekerjaan penutupan L2 yang sangat kompleks dan kacau secara nyata.

Dengan alasan-alasan ini, memperluas sendiri L1 dan memastikan bahwa itu dapat terus menampung lebih banyak kasus penggunaan adalah sangat berharga.

Apa itu? Bagaimana cara kerjanya?

Cara perluasan yang paling sederhana adalah dengan langsung meningkatkan batas atas gas. Namun, hal ini mungkin membuat L1 cenderung terpusat, sehingga melemahkan satu fitur penting lainnya dari Ethereum L1 yang begitu kuat: kepercayaan sebagai lapisan dasar yang kokoh. Masih diperdebatkan sejauh mana peningkatan sederhana batas atas gas dapat berkelanjutan, dan ini juga akan bervariasi tergantung pada penerapan teknologi lain apa yang membuat validasi Blok yang lebih besar menjadi lebih mudah (misalnya, masa kedaluwarsa historis, tanpa status, bukti validitas EVM L1). Hal penting lain yang perlu terus ditingkatkan adalah efisiensi perangkat lunak klien Ethereum, yang saat ini jauh lebih efisien daripada lima tahun yang lalu. Strategi peningkatan batas atas gas L1 yang efektif akan melibatkan percepatan perkembangan teknologi validasi ini.

1.EOF: Sebuah format bytecode EVM baru, lebih ramah untuk analisis statis, dapat dicapai lebih cepat. Mengingat peningkatan efisiensi ini, bytecode EOF dapat memperoleh biaya gas yang lebih rendah.

2. Penetapan Harga Gas Multidimensi: Menetapkan biaya dasar dan batasan yang berbeda untuk komputasi, data, dan penyimpanan secara terpisah, yang dapat meningkatkan kapasitas rata-rata ETH L1 tanpa meningkatkan kapasitas maksimum (sehingga menghindari timbulnya risiko keamanan baru).

3. Menurunkan opcode tertentu dan biaya Gas yang sudah dipre-kompilasi - Secara historis, untuk menghindari serangan denial-of-service, kami telah beberapa kali meningkatkan biaya Gas dari beberapa opcode dengan penilaian yang terlalu rendah. Sesuatu yang bisa dilakukan adalah menurunkan biaya Gas dari opcode yang terlalu mahal. Misalnya, penambahan jauh lebih murah daripada perkalian, tetapi saat ini biaya opcode ADD dan MUL sama. Kita bisa menurunkan biaya ADD, bahkan membuat biaya opcode yang lebih sederhana seperti PUSH lebih rendah. EOF secara keseluruhan lebih dioptimalkan dalam hal ini.

4.EVM-MAX dan SIMD: EVM-MAX adalah sebuah proposal yang memungkinkan operasi matematika asli dengan angka besar yang lebih efisien sebagai modul terpisah dari EVM. Kecuali disengaja diekspor, nilai yang dihitung oleh EVM-MAX hanya dapat diakses oleh opcode EVM-MAX lainnya. Hal ini memungkinkan ruang yang lebih besar untuk mengoptimalkan penyimpanan nilai-nilai ini. SIMD (single instruction multiple data) adalah proposal yang memungkinkan eksekusi efisien dari instruksi yang sama terhadap array nilai. Kedua elemen ini dapat bersama-sama membuat prosesor kopro yang kuat di samping EVM, yang dapat digunakan untuk menerapkan operasi enkripsi dengan lebih efisien. Ini sangat bermanfaat untuk protokol privasi dan sistem perlindungan L2, sehingga akan membantu dalam ekspansi L1 dan L2.

Peningkatan ini akan dibahas secara lebih detail dalam artikel Splurge yang akan datang.

Terakhir, strategi ketiga adalah rollups asli (atau rollups diabadikan): Pada dasarnya, membuat banyak salinan EVM yang berjalan secara paralel, sehingga menghasilkan model yang setara dengan rollup yang dapat disediakan, tetapi lebih terintegrasi secara lebih asli ke dalam protokol.

Apa keterkaitan dengan penelitian yang ada?

Rencana pengembangan skala L1 ETH Polynya:

2. Penentuan harga Gas multi-dimensi:

3.EIP-7706:

4.EOF:

5.EVM-MAX:

6.SIMD:

7. rollups Native:

8.Max Resnick melakukan wawancara tentang nilai perluasan L1:

9. Justin Drake membahas penggunaan SNARK dan rollups asli untuk skalabilitas:

Apa lagi yang perlu dilakukan dan ada pertimbangan apa saja?

L1 ekstensi memiliki tiga strategi yang dapat dilakukan secara terpisah atau paralel:

1. Meningkatkan teknologi (seperti kode klien, klien tanpa status, masa kedaluwarsa sejarah) untuk membuat L1 lebih mudah diverifikasi, kemudian meningkatkan batasan gas.

2.Menurunkan biaya operasi khusus Drop, meningkatkan kapasitas rata-rata tanpa meningkatkan risiko kasus terburuk;

3. Rollups asli (yaitu, membuat N salinan paralel dari EVM).

Setelah memahami berbagai teknologi yang berbeda, kita akan menemukan bahwa masing-masing memiliki keuntungan dan kerugian yang berbeda. Misalnya, Rollups asli memiliki banyak kelemahan yang sama dengan Rollups biasa dalam hal komposisi: Anda tidak dapat mengirim satu transaksi tunggal untuk melakukan operasi sinkronisasi melintasi beberapa Rollup, seperti yang dapat Anda lakukan dalam kontrak yang sama di L1 (atau L2) yang sama. Meningkatkan batas atas Gas akan melemahkan manfaat lain yang dapat dicapai dengan memverifikasi L1 secara lebih sederhana, seperti meningkatkan proporsi pengguna verifikasi Node dan penambang solo yang meningkat. Bergantung pada cara implementasinya, membuat operasi tertentu dalam EVM (Ethereum Virtual Machine) lebih murah bisa meningkatkan kompleksitas keseluruhan EVM.

Salah satu pertanyaan besar yang perlu dijawab oleh rencana penskalaan L1 adalah: Apa visi akhir dari L1 dan L2 masing-masing? Jelas, tidaklah masuk akal untuk menempatkan semua konten di L1: skenario aplikasi potensial mungkin melibatkan puluhan ribu transaksi per detik, yang akan membuat L1 tidak dapat diverifikasi secara keseluruhan (kecuali kita menggunakan pendekatan Rollup asli). Namun, kita memang memerlukan beberapa panduan untuk memastikan kita tidak terjebak dalam situasi di mana kenaikan batas Gas 10 kali lipat secara serius merusak Desentralisasi Etherum pada L1.

Salah satu pandangan tentang pembagian kerja antara L1 dan L2

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Membawa lebih banyak pengguna ke L1 bukan hanya berarti meningkatkan skala, tetapi juga berarti memperbaiki aspek lain dari L1. Ini berarti lebih banyak MEV akan tetap di L1 (bukan hanya menjadi masalah L2), sehingga kebutuhan untuk menangani MEV dengan jelas akan menjadi lebih mendesak. Ini akan sangat meningkatkan nilai waktu slot cepat di L1. Pada saat yang sama, ini juga sangat bergantung pada kelancaran verifikasi L1 (the Verge).

Bacaan Terkait: “Vitalik Artikel Baru: Di mana lagi Ethereum PoS dapat ditingkatkan? Bagaimana cara melakukannya?”

Tautan Asli