Arah Pengembangan Masa Depan Protokol Ethereum: Bab Kemakmuran
Desain protokol Ethereum memiliki banyak "detail" penting yang krusial untuk keberhasilannya. Sekitar setengah dari kontennya berkaitan dengan berbagai jenis peningkatan EVM, sedangkan sisanya terdiri dari berbagai tema niche, itulah arti dari "kemakmuran".
Kemakmuran: Tujuan Kunci
Mengubah EVM menjadi "status akhir" yang berkinerja tinggi dan stabil
Memperkenalkan abstraksi akun ke dalam protokol, memungkinkan semua pengguna untuk menikmati akun yang lebih aman dan nyaman.
Mengoptimalkan biaya transaksi ekonomis, meningkatkan skalabilitas sambil mengurangi risiko
Menjelajahi kriptografi canggih, sehingga Ethereum dapat meningkat secara signifikan dalam jangka panjang
Perbaikan EVM
Masalah apa yang diselesaikan?
Saat ini EVM sulit untuk dianalisis secara statis, yang membuat penciptaan implementasi yang efisien, verifikasi formal kode, dan perluasan lebih lanjut menjadi sulit. Selain itu, efisiensi EVM yang rendah menyulitkan penerapan banyak bentuk kriptografi tingkat tinggi, kecuali didukung secara eksplisit melalui prekompilasi.
Apa itu, dan bagaimana cara kerjanya?
Langkah pertama dari peta jalan perbaikan EVM saat ini adalah format objek EVM (EOF), yang direncanakan untuk dimasukkan dalam hard fork berikutnya. EOF adalah serangkaian EIP, yang menetapkan versi kode EVM baru, dengan banyak fitur unik, yang paling mencolok adalah:
Kode ( dapat dieksekusi, tetapi tidak dapat membaca ) dari EVM dan data ( dapat dibaca, tetapi tidak dapat dieksekusi antara pemisahan )
Dilarang melakukan lompat dinamis, hanya lompat statis yang diizinkan
Kode EVM tidak dapat lagi mengamati informasi yang terkait dengan bahan bakar.
Menambahkan mekanisme subrutin eksplisit baru
Struktur kode EOF terdiri dari segmen kode, segmen data, dan segmen informasi tipe.
Setelah memperkenalkan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini yang paling berkembang adalah perluasan aritmetika modul EVM ( EVM-MAX ). EVM-MAX menciptakan serangkaian operasi baru yang khusus untuk operasi modulo, dan menempatkannya di ruang memori baru yang tidak dapat diakses melalui opcode lain, yang memungkinkan penggunaan optimasi seperti perkalian Montgomery.
Sebuah ide yang lebih baru adalah menggabungkan EVM-MAX dengan fitur SIMD (Single Instruction Multiple Data) (. SIMD dapat digunakan untuk mempercepat banyak bentuk kriptografi, termasuk fungsi hash, STARKs 32-bit, dan kriptografi berbasis kisi. Kombinasi EVM-MAX dan SIMD membuat kedua skala yang berorientasi pada kinerja ini menjadi pasangan yang alami.
) Tautan penelitian yang ada
EOF:
EVM-MAX:
SIMD:
Sisa pekerjaan dan pertimbangan
Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu mungkin untuk menghapusnya pada saat-saat terakhir, melakukan hal itu akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap pembaruan EVM di masa depan harus dilakukan tanpa EOF, meskipun itu mungkin, tetapi bisa lebih sulit.
Pertimbangan utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah banyak kode yang perlu ditambahkan ke dalam implementasi EVM, dan pemeriksaan kode statis juga relatif kompleks. Namun, sebagai gantinya, kita dapat menyederhanakan bahasa tingkat tinggi, menyederhanakan implementasi EVM, dan manfaat lainnya. Dapat dikatakan bahwa peta jalan yang memprioritaskan perbaikan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.
Pekerjaan penting yang perlu dilakukan adalah mewujudkan fungsi serupa EVM-MAX ditambah SIMD, dan melakukan pengujian benchmark terhadap konsumsi gas dari berbagai operasi kriptografi.
Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
L1 menyesuaikan EVM-nya sehingga L2 juga dapat melakukan penyesuaian yang sesuai dengan lebih mudah, jika keduanya tidak melakukan penyesuaian sinkron, mungkin akan menyebabkan ketidakcocokan yang berdampak negatif. Selain itu, EVM-MAX dan SIMD dapat mengurangi biaya gas dari banyak sistem pembuktian, sehingga L2 menjadi lebih efisien. Ini juga membuat lebih mudah untuk menggantikan lebih banyak precompiled dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak akan berdampak besar pada efisiensi.
![Vitalik tentang masa depan Ethereum yang mungkin (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Abstraksi Akun
) Apa masalah yang diselesaikan?
Saat ini, transaksi hanya dapat diverifikasi melalui satu cara: tanda tangan ECDSA. Pada awalnya, abstraksi akun ditujukan untuk melampaui hal ini, memungkinkan logika verifikasi akun untuk menjadi kode EVM yang sembarang. Ini dapat mengaktifkan serangkaian aplikasi:
Beralih ke kriptografi pasca-kuantum
Mengganti kunci lama ### secara luas dianggap sebagai praktik keamanan yang disarankan (
Dompet multisig dan dompet pemulihan sosial
Menggunakan satu kunci untuk operasi nilai rendah, menggunakan kunci lain ) atau sekelompok kunci ( untuk operasi nilai tinggi
Memungkinkan protokol privasi berfungsi tanpa perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang kunci.
Sejak pengenalan abstraksi akun pada tahun 2015, tujuannya juga telah berkembang untuk mencakup banyak "tujuan kemudahan", seperti, akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat membayar gas dengan ERC20.
![Vitalik tentang kemungkinan masa depan Ethereum (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) Apa itu, dan bagaimana cara kerjanya?
Inti dari abstraksi akun adalah sederhana: memungkinkan kontrak pintar untuk memulai transaksi, dan bukan hanya EOA. Seluruh kompleksitas berasal dari cara mewujudkannya dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi, dan mencegah serangan penolakan layanan.
Salah satu tantangan utama adalah masalah kegagalan ganda: jika ada 1000 fungsi validasi akun yang bergantung pada suatu nilai tunggal S, dan nilai S saat ini membuat transaksi dalam mempool semuanya valid, maka satu transaksi yang membalik nilai S dapat membuat semua transaksi lain dalam mempool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke mempool dengan biaya yang sangat rendah, sehingga menyumbat sumber daya node jaringan.
Setelah bertahun-tahun berusaha, yang bertujuan untuk memperluas fungsionalitas sambil membatasi risiko penolakan layanan ###DoS(, akhirnya menghasilkan solusi untuk mencapai "abstraksi akun ideal": ERC-4337.
Cara kerja ERC-4337 adalah membagi pemrosesan operasi pengguna menjadi dua tahap: validasi dan eksekusi. Semua validasi diproses terlebih dahulu, dan semua eksekusi diproses kemudian. Di dalam mempool, operasi pengguna hanya akan diterima jika tahap validasinya hanya melibatkan akun itu sendiri dan tidak membaca variabel lingkungan. Ini dapat mencegah serangan kegagalan ganda. Selain itu, batas gas yang ketat juga diberlakukan pada langkah validasi.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Tautan penelitian yang ada
Tentang sejarah abstraksi akun:
ERC-4337:
EIP-7702:
Kode BLSWallet ### menggunakan fungsi agregasi (:
EIP-7562) menulis protokol akun abstrak (:
EIP-7701) Akun abstraksi protokol penulisan berbasis EOF (:
) pekerjaan yang tersisa dan pertimbangan
Saat ini, yang perlu diselesaikan adalah bagaimana sepenuhnya mengintegrasikan abstraksi akun ke dalam protokol. EIP yang baru-baru ini populer untuk menulis protokol abstraksi akun adalah EIP-7701, yang menerapkan abstraksi akun di atas EOF. Sebuah akun dapat memiliki bagian kode terpisah untuk verifikasi. Jika akun telah mengatur bagian kode tersebut, maka kode itu akan dieksekusi pada langkah verifikasi dari transaksi yang berasal dari akun tersebut.
Daya tarik metode ini terletak pada kenyataan bahwa ia dengan jelas menunjukkan dua perspektif setara dari abstraksi akun lokal:
Menjadikan EIP-4337 sebagai bagian dari protokol
Jenis EOA baru, di mana algoritma tanda tangan adalah eksekusi kode EVM
Jika kita mulai dengan menetapkan batasan yang ketat pada kompleksitas kode yang dapat dieksekusi selama periode verifikasi, maka keamanan metode ini sangat jelas: hanya mengganti verifikasi ECDSA dengan eksekusi kode EVM yang memerlukan waktu yang serupa.
Namun, seiring berjalannya waktu, kita perlu melonggarkan batasan ini, karena memungkinkan aplikasi perlindungan privasi berfungsi tanpa perantara, serta ketahanan kuantum sangat penting. Untuk itu, kita perlu menemukan cara yang lebih fleksibel untuk menangani risiko penolakan layanan ###DoS(, tanpa mengharuskan langkah verifikasi harus sangat sederhana.
Tampaknya kompromi utama adalah "menulis solusi yang memuaskan lebih sedikit orang dengan cepat" versus "menunggu lebih lama, mungkin mendapatkan solusi yang lebih ideal", dan pendekatan ideal mungkin adalah semacam metode campuran. Salah satu metode campuran adalah menulis beberapa kasus penggunaan dengan lebih cepat dan menyisihkan lebih banyak waktu untuk mengeksplorasi kasus penggunaan lainnya. Metode lain adalah terlebih dahulu menerapkan versi abstraksi akun yang lebih ambisius di L2. Namun, tantangan yang dihadapi adalah tim L2 perlu memiliki keyakinan penuh terhadap pekerjaan proposal adopsi, agar bersedia untuk melaksanakannya, terutama untuk memastikan bahwa L1 dan/atau L2 lainnya di masa depan dapat mengadopsi solusi yang kompatibel.
Satu aplikasi lain yang perlu kita pertimbangkan adalah akun penyimpanan kunci, yang menyimpan status terkait akun di L1 atau L2 khusus, tetapi dapat digunakan di L1 dan L2 yang kompatibel. Melakukan ini secara efektif mungkin memerlukan dukungan opcode seperti L1SLOAD atau REMOTESTATICCALL di L2, tetapi ini juga memerlukan dukungan implementasi abstraksi akun di L2 untuk operasi ini.
) Bagaimana ia berinteraksi dengan bagian lain dari peta jalan?
Daftar yang termasuk harus mendukung transaksi abstraksi akun, dalam praktiknya, kebutuhan daftar yang termasuk sangat mirip dengan kebutuhan mempool terdesentralisasi, meskipun fleksibilitas untuk daftar yang termasuk sedikit lebih besar. Selain itu, implementasi abstraksi akun harus berkoordinasi antara L1 dan L2 sebisa mungkin. Jika di masa depan kita mengharapkan sebagian besar pengguna menggunakan penyimpanan kunci Rollup, desain abstraksi akun harus didasarkan pada hal ini.
![Vitalik tentang kemungkinan masa depan Ethereum (Enam): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Perbaikan EIP-1559
) Apa masalah yang dipecahkan?
EIP-1559 diaktifkan di Ethereum pada tahun 2021, secara signifikan memperbaiki rata-rata waktu pencarian blok. Namun, implementasi EIP-1559 saat ini tidak sempurna dalam beberapa aspek:
Rumus sedikit cacat: itu tidak menargetkan 50% blok, melainkan sekitar 50-53% blok penuh, tergantung pada varians ### ini berkaitan dengan apa yang disebut matematikawan sebagai "ketidaksetaraan rata-rata aritmatika-geometri" (.
Penyesuaian tidak cukup cepat dalam situasi ekstrem.
Rumus untuk blobs di belakang )EIP-4844( dirancang khusus untuk mengatasi masalah pertama dan secara keseluruhan lebih sederhana. Namun, EIP-1559 itu sendiri dan EIP-4844 tidak pernah mencoba untuk menyelesaikan masalah kedua. Oleh karena itu, situasinya adalah keadaan tengah yang kacau, melibatkan dua mekanisme yang berbeda, dan ada pandangan bahwa seiring berjalannya waktu, keduanya perlu diperbaiki.
Selain itu, ada kelemahan lain dalam penetapan harga sumber daya Ethereum yang tidak terkait dengan EIP-1559, tetapi dapat diselesaikan melalui penyesuaian terhadap EIP-1559. Salah satu masalah utama adalah perbedaan antara kondisi rata-rata dan kondisi terburuk: harga sumber daya dalam Ethereum harus ditetapkan untuk menangani kondisi terburuk, yaitu seluruh konsumsi gas dalam satu blok mengambil satu sumber daya, tetapi penggunaan rata-rata yang sebenarnya jauh di bawah ini, yang mengakibatkan ketidakefisienan.
![Vitalik tentang masa depan Ethereum yang mungkin (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
) Apa itu Multi-Dimensional Gas, dan bagaimana cara kerjanya?
Solusi untuk masalah ketidakefisienan ini adalah Multi-Dimensional Gas: menetapkan harga dan batasan yang berbeda untuk berbagai sumber daya. Konsep ini secara teknis independen dari EIP-1559, tetapi EIP-1
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.
14 Suka
Hadiah
14
7
Bagikan
Komentar
0/400
MissedAirdropBro
· 07-26 03:16
Mengapa lagi-lagi akun abstraksi!
Lihat AsliBalas0
BrokenDAO
· 07-25 06:25
Satu lagi peta jalan yang ambisius, kemungkinan besar akan mengulangi nasib Casper.
Lihat AsliBalas0
GasGuru
· 07-24 20:52
Kedengarannya sangat dapat dipercaya ya.
Lihat AsliBalas0
SigmaBrain
· 07-24 20:51
Apa ini, versi ini ternyata perlu diubah?
Lihat AsliBalas0
OPsychology
· 07-24 20:45
Kapan upgrade ini diluncurkan?
Lihat AsliBalas0
WalletWhisperer
· 07-24 20:31
pola perilaku menunjukkan evm2.0 akan memicu migrasi dompet massal... secara statistik tak terhindarkan
Lihat AsliBalas0
Whale_Whisperer
· 07-24 20:29
Upgrade EVM seharusnya sudah diajukan, biaya gas ini benar-benar tidak tahan.
Masa depan peta jalan protokol Ethereum: peningkatan EVM, abstraksi akun, dan optimasi biaya
Arah Pengembangan Masa Depan Protokol Ethereum: Bab Kemakmuran
Desain protokol Ethereum memiliki banyak "detail" penting yang krusial untuk keberhasilannya. Sekitar setengah dari kontennya berkaitan dengan berbagai jenis peningkatan EVM, sedangkan sisanya terdiri dari berbagai tema niche, itulah arti dari "kemakmuran".
Kemakmuran: Tujuan Kunci
Perbaikan EVM
Masalah apa yang diselesaikan?
Saat ini EVM sulit untuk dianalisis secara statis, yang membuat penciptaan implementasi yang efisien, verifikasi formal kode, dan perluasan lebih lanjut menjadi sulit. Selain itu, efisiensi EVM yang rendah menyulitkan penerapan banyak bentuk kriptografi tingkat tinggi, kecuali didukung secara eksplisit melalui prekompilasi.
Apa itu, dan bagaimana cara kerjanya?
Langkah pertama dari peta jalan perbaikan EVM saat ini adalah format objek EVM (EOF), yang direncanakan untuk dimasukkan dalam hard fork berikutnya. EOF adalah serangkaian EIP, yang menetapkan versi kode EVM baru, dengan banyak fitur unik, yang paling mencolok adalah:
Struktur kode EOF terdiri dari segmen kode, segmen data, dan segmen informasi tipe.
Setelah memperkenalkan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini yang paling berkembang adalah perluasan aritmetika modul EVM ( EVM-MAX ). EVM-MAX menciptakan serangkaian operasi baru yang khusus untuk operasi modulo, dan menempatkannya di ruang memori baru yang tidak dapat diakses melalui opcode lain, yang memungkinkan penggunaan optimasi seperti perkalian Montgomery.
Sebuah ide yang lebih baru adalah menggabungkan EVM-MAX dengan fitur SIMD (Single Instruction Multiple Data) (. SIMD dapat digunakan untuk mempercepat banyak bentuk kriptografi, termasuk fungsi hash, STARKs 32-bit, dan kriptografi berbasis kisi. Kombinasi EVM-MAX dan SIMD membuat kedua skala yang berorientasi pada kinerja ini menjadi pasangan yang alami.
) Tautan penelitian yang ada
Sisa pekerjaan dan pertimbangan
Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu mungkin untuk menghapusnya pada saat-saat terakhir, melakukan hal itu akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap pembaruan EVM di masa depan harus dilakukan tanpa EOF, meskipun itu mungkin, tetapi bisa lebih sulit.
Pertimbangan utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah banyak kode yang perlu ditambahkan ke dalam implementasi EVM, dan pemeriksaan kode statis juga relatif kompleks. Namun, sebagai gantinya, kita dapat menyederhanakan bahasa tingkat tinggi, menyederhanakan implementasi EVM, dan manfaat lainnya. Dapat dikatakan bahwa peta jalan yang memprioritaskan perbaikan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.
Pekerjaan penting yang perlu dilakukan adalah mewujudkan fungsi serupa EVM-MAX ditambah SIMD, dan melakukan pengujian benchmark terhadap konsumsi gas dari berbagai operasi kriptografi.
Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
L1 menyesuaikan EVM-nya sehingga L2 juga dapat melakukan penyesuaian yang sesuai dengan lebih mudah, jika keduanya tidak melakukan penyesuaian sinkron, mungkin akan menyebabkan ketidakcocokan yang berdampak negatif. Selain itu, EVM-MAX dan SIMD dapat mengurangi biaya gas dari banyak sistem pembuktian, sehingga L2 menjadi lebih efisien. Ini juga membuat lebih mudah untuk menggantikan lebih banyak precompiled dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak akan berdampak besar pada efisiensi.
![Vitalik tentang masa depan Ethereum yang mungkin (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Abstraksi Akun
) Apa masalah yang diselesaikan?
Saat ini, transaksi hanya dapat diverifikasi melalui satu cara: tanda tangan ECDSA. Pada awalnya, abstraksi akun ditujukan untuk melampaui hal ini, memungkinkan logika verifikasi akun untuk menjadi kode EVM yang sembarang. Ini dapat mengaktifkan serangkaian aplikasi:
Memungkinkan protokol privasi berfungsi tanpa perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang kunci.
Sejak pengenalan abstraksi akun pada tahun 2015, tujuannya juga telah berkembang untuk mencakup banyak "tujuan kemudahan", seperti, akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat membayar gas dengan ERC20.
![Vitalik tentang kemungkinan masa depan Ethereum (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) Apa itu, dan bagaimana cara kerjanya?
Inti dari abstraksi akun adalah sederhana: memungkinkan kontrak pintar untuk memulai transaksi, dan bukan hanya EOA. Seluruh kompleksitas berasal dari cara mewujudkannya dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi, dan mencegah serangan penolakan layanan.
Salah satu tantangan utama adalah masalah kegagalan ganda: jika ada 1000 fungsi validasi akun yang bergantung pada suatu nilai tunggal S, dan nilai S saat ini membuat transaksi dalam mempool semuanya valid, maka satu transaksi yang membalik nilai S dapat membuat semua transaksi lain dalam mempool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke mempool dengan biaya yang sangat rendah, sehingga menyumbat sumber daya node jaringan.
Setelah bertahun-tahun berusaha, yang bertujuan untuk memperluas fungsionalitas sambil membatasi risiko penolakan layanan ###DoS(, akhirnya menghasilkan solusi untuk mencapai "abstraksi akun ideal": ERC-4337.
Cara kerja ERC-4337 adalah membagi pemrosesan operasi pengguna menjadi dua tahap: validasi dan eksekusi. Semua validasi diproses terlebih dahulu, dan semua eksekusi diproses kemudian. Di dalam mempool, operasi pengguna hanya akan diterima jika tahap validasinya hanya melibatkan akun itu sendiri dan tidak membaca variabel lingkungan. Ini dapat mencegah serangan kegagalan ganda. Selain itu, batas gas yang ketat juga diberlakukan pada langkah validasi.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Tautan penelitian yang ada
) pekerjaan yang tersisa dan pertimbangan
Saat ini, yang perlu diselesaikan adalah bagaimana sepenuhnya mengintegrasikan abstraksi akun ke dalam protokol. EIP yang baru-baru ini populer untuk menulis protokol abstraksi akun adalah EIP-7701, yang menerapkan abstraksi akun di atas EOF. Sebuah akun dapat memiliki bagian kode terpisah untuk verifikasi. Jika akun telah mengatur bagian kode tersebut, maka kode itu akan dieksekusi pada langkah verifikasi dari transaksi yang berasal dari akun tersebut.
Daya tarik metode ini terletak pada kenyataan bahwa ia dengan jelas menunjukkan dua perspektif setara dari abstraksi akun lokal:
Jika kita mulai dengan menetapkan batasan yang ketat pada kompleksitas kode yang dapat dieksekusi selama periode verifikasi, maka keamanan metode ini sangat jelas: hanya mengganti verifikasi ECDSA dengan eksekusi kode EVM yang memerlukan waktu yang serupa.
Namun, seiring berjalannya waktu, kita perlu melonggarkan batasan ini, karena memungkinkan aplikasi perlindungan privasi berfungsi tanpa perantara, serta ketahanan kuantum sangat penting. Untuk itu, kita perlu menemukan cara yang lebih fleksibel untuk menangani risiko penolakan layanan ###DoS(, tanpa mengharuskan langkah verifikasi harus sangat sederhana.
Tampaknya kompromi utama adalah "menulis solusi yang memuaskan lebih sedikit orang dengan cepat" versus "menunggu lebih lama, mungkin mendapatkan solusi yang lebih ideal", dan pendekatan ideal mungkin adalah semacam metode campuran. Salah satu metode campuran adalah menulis beberapa kasus penggunaan dengan lebih cepat dan menyisihkan lebih banyak waktu untuk mengeksplorasi kasus penggunaan lainnya. Metode lain adalah terlebih dahulu menerapkan versi abstraksi akun yang lebih ambisius di L2. Namun, tantangan yang dihadapi adalah tim L2 perlu memiliki keyakinan penuh terhadap pekerjaan proposal adopsi, agar bersedia untuk melaksanakannya, terutama untuk memastikan bahwa L1 dan/atau L2 lainnya di masa depan dapat mengadopsi solusi yang kompatibel.
Satu aplikasi lain yang perlu kita pertimbangkan adalah akun penyimpanan kunci, yang menyimpan status terkait akun di L1 atau L2 khusus, tetapi dapat digunakan di L1 dan L2 yang kompatibel. Melakukan ini secara efektif mungkin memerlukan dukungan opcode seperti L1SLOAD atau REMOTESTATICCALL di L2, tetapi ini juga memerlukan dukungan implementasi abstraksi akun di L2 untuk operasi ini.
) Bagaimana ia berinteraksi dengan bagian lain dari peta jalan?
Daftar yang termasuk harus mendukung transaksi abstraksi akun, dalam praktiknya, kebutuhan daftar yang termasuk sangat mirip dengan kebutuhan mempool terdesentralisasi, meskipun fleksibilitas untuk daftar yang termasuk sedikit lebih besar. Selain itu, implementasi abstraksi akun harus berkoordinasi antara L1 dan L2 sebisa mungkin. Jika di masa depan kita mengharapkan sebagian besar pengguna menggunakan penyimpanan kunci Rollup, desain abstraksi akun harus didasarkan pada hal ini.
![Vitalik tentang kemungkinan masa depan Ethereum (Enam): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Perbaikan EIP-1559
) Apa masalah yang dipecahkan?
EIP-1559 diaktifkan di Ethereum pada tahun 2021, secara signifikan memperbaiki rata-rata waktu pencarian blok. Namun, implementasi EIP-1559 saat ini tidak sempurna dalam beberapa aspek:
Rumus untuk blobs di belakang )EIP-4844( dirancang khusus untuk mengatasi masalah pertama dan secara keseluruhan lebih sederhana. Namun, EIP-1559 itu sendiri dan EIP-4844 tidak pernah mencoba untuk menyelesaikan masalah kedua. Oleh karena itu, situasinya adalah keadaan tengah yang kacau, melibatkan dua mekanisme yang berbeda, dan ada pandangan bahwa seiring berjalannya waktu, keduanya perlu diperbaiki.
Selain itu, ada kelemahan lain dalam penetapan harga sumber daya Ethereum yang tidak terkait dengan EIP-1559, tetapi dapat diselesaikan melalui penyesuaian terhadap EIP-1559. Salah satu masalah utama adalah perbedaan antara kondisi rata-rata dan kondisi terburuk: harga sumber daya dalam Ethereum harus ditetapkan untuk menangani kondisi terburuk, yaitu seluruh konsumsi gas dalam satu blok mengambil satu sumber daya, tetapi penggunaan rata-rata yang sebenarnya jauh di bawah ini, yang mengakibatkan ketidakefisienan.
![Vitalik tentang masa depan Ethereum yang mungkin (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
) Apa itu Multi-Dimensional Gas, dan bagaimana cara kerjanya?
Solusi untuk masalah ketidakefisienan ini adalah Multi-Dimensional Gas: menetapkan harga dan batasan yang berbeda untuk berbagai sumber daya. Konsep ini secara teknis independen dari EIP-1559, tetapi EIP-1