Desain protokol Ethereum memiliki banyak "detail" yang sangat penting untuk keberhasilannya. Sekitar setengah isi berkaitan dengan berbagai jenis perbaikan EVM, sementara sisanya terdiri dari berbagai topik kecil, inilah yang dimaksud dengan "kemakmuran".
Kemakmuran: Tujuan Kunci
Mengubah EVM menjadi "status akhir" yang berkinerja tinggi dan stabil
Memperkenalkan abstraksi akun ke dalam protokol, memungkinkan semua pengguna menikmati akun yang lebih aman dan nyaman.
Mengoptimalkan ekonomi biaya transaksi, meningkatkan skalabilitas sambil mengurangi risiko
Menjelajahi kriptografi canggih untuk perbaikan signifikan Ethereum dalam jangka panjang
EVM perbaikan
Masalah apa yang diselesaikan?
Saat ini, EVM sulit untuk dianalisis secara statis, yang membuat sulit untuk membuat implementasi yang efisien, memverifikasi kode secara formal, dan memperluas lebih lanjut. Selain itu, efisiensi EVM yang rendah membuat sulit untuk menerapkan banyak kriptografi tingkat tinggi, kecuali dengan dukungan eksplisit melalui prapemrograman.
Apa itu, dan bagaimana cara kerjanya?
Langkah pertama dari peta jalan peningkatan EVM saat ini adalah format objek EVM (EOF), yang direncanakan akan 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 dibaca dari EVM. ) dengan data dapat dibaca, tetapi tidak dapat dieksekusi ( yang terpisah.
Larangan untuk lompat dinamis, hanya diizinkan untuk lompat statis
Kode EVM tidak dapat lagi mengamati informasi terkait bahan bakar
Menambahkan mekanisme sub-rutin eksplisit baru
Kontrak lama akan terus ada dan dapat dibuat, meskipun pada akhirnya mungkin akan secara bertahap ditinggalkan ) bahkan mungkin dipaksa untuk dikonversi menjadi kode EOF (. Kontrak baru akan mendapat manfaat dari peningkatan efisiensi yang dibawa oleh EOF—pertama dengan bytecode yang sedikit lebih kecil melalui fitur sub-rutin, dan kemudian dengan fungsi baru atau biaya gas yang berkurang yang spesifik untuk EOF.
Setelah memperkenalkan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini yang paling berkembang adalah perluasan aritmatika modul EVM ) EVM-MAX (. EVM-MAX menciptakan sekumpulan operasi baru yang khusus untuk operasi modulo, dan menempatkannya dalam ruang memori baru yang tidak dapat diakses melalui opcode lainnya, sehingga memungkinkan penggunaan optimasi seperti perkalian Montgomery.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Sebuah ide yang lebih baru adalah menggabungkan EVM-MAX dengan fitur Single Instruction Multiple Data )SIMD(, SIMD sebagai sebuah konsep dalam Ethereum telah ada selama waktu yang lama, pertama kali diusulkan oleh Greg Colvin dalam EIP-616. SIMD dapat digunakan untuk mempercepat banyak bentuk kriptografi, termasuk fungsi hash, 32-bit STARKs, dan kriptografi berbasis kisi, penggabungan EVM-MAX dan SIMD membuat kedua ekspansi yang berorientasi pada kinerja ini menjadi pasangan yang alami.
Dalam implementasi nyata, ini akan diproses secara paralel.
)# Pekerjaan yang tersisa dan pertimbangannya
Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu ada kemungkinan untuk menghapusnya di saat-saat terakhir — sebelumnya ada fungsi yang sementara dihapus dalam hard fork sebelumnya, tetapi melakukan hal itu akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap upgrade masa depan terhadap EVM harus dilakukan tanpa EOF, meskipun itu bisa dilakukan, tetapi mungkin akan lebih sulit.
Pertimbangan utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah sejumlah besar kode yang perlu ditambahkan ke implementasi EVM, dan pemeriksaan kode statis juga relatif kompleks. Namun, sebagai imbalan, kita dapat menyederhanakan bahasa tingkat tinggi, menyederhanakan implementasi EVM, dan manfaat lainnya. Dapat dikatakan bahwa prioritas untuk peta jalan perbaikan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.
Salah satu pekerjaan penting yang perlu dilakukan adalah mewujudkan fungsi serupa EVM-MAX ditambah SIMD, dan melakukan pengujian kinerja 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 secara sinkron, mungkin akan menyebabkan ketidakcocokan dan membawa dampak negatif. Selain itu, EVM-MAX dan SIMD dapat mengurangi biaya gas dari banyak sistem bukti, sehingga membuat L2 lebih efisien. Ini juga membuat lebih mudah untuk mengganti lebih banyak precompiled dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak akan mempengaruhi efisiensi secara signifikan.
![Vitalik tentang kemungkinan masa depan Ethereum (Enam): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
) abstraksi akun
Apa masalah yang diselesaikan?
Saat ini, transaksi hanya dapat divalidasi dengan satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun dirancang untuk melampaui hal ini, memungkinkan logika verifikasi akun untuk berupa kode EVM yang arbitrer. Ini dapat mengaktifkan serangkaian aplikasi:
Beralih ke kriptografi tahan kuantum
Mengganti kunci lama ### secara luas dianggap sebagai praktik keamanan yang disarankan (
Dompet multisig dan dompet pemulihan sosial
Gunakan satu kunci untuk operasi nilai rendah, gunakan kunci lain ) atau sekumpulan kunci ( untuk operasi nilai tinggi.
Memungkinkan protokol privasi berfungsi tanpa perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang penting.
Sejak pengenalan abstraksi akun pada tahun 2015, tujuannya juga diperluas untuk mencakup sejumlah "tujuan kenyamanan", misalnya, sebuah akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat menggunakan ERC20 untuk membayar gas.
MPC) komputasi multi pihak ( adalah teknologi yang telah ada selama 40 tahun, digunakan untuk membagi kunci menjadi beberapa bagian dan menyimpannya di beberapa perangkat, memanfaatkan teknik kriptografi untuk menghasilkan tanda tangan, tanpa perlu menggabungkan bagian-bagian kunci tersebut secara langsung.
EIP-7702 adalah proposal yang direncanakan untuk diperkenalkan dalam hard fork berikutnya, EIP-7702 merupakan hasil dari kesadaran yang semakin meningkat untuk menyediakan kenyamanan abstraksi akun yang menguntungkan semua pengguna ) termasuk pengguna EOA (, bertujuan untuk meningkatkan pengalaman semua pengguna dalam jangka pendek, dan menghindari terpecah menjadi dua ekosistem.
Pekerjaan ini dimulai dengan EIP-3074, dan akhirnya membentuk EIP-7702. EIP-7702 memberikan "fungsi kenyamanan" dari abstraksi akun kepada semua pengguna, termasuk EOA) yang dimiliki secara eksternal hari ini, yaitu akun yang dikendalikan oleh tanda tangan ECDSA(.
Meskipun beberapa tantangan ) terutama tantangan "kenyamanan" ( dapat diatasi melalui teknologi bertahap seperti komputasi multi pihak atau EIP-7702, tujuan keamanan utama dari proposal abstraksi akun yang awalnya diajukan hanya dapat dicapai dengan kembali dan menyelesaikan masalah asli: memungkinkan kode kontrak pintar untuk mengontrol verifikasi transaksi. Alasan mengapa ini belum terwujud hingga saat ini adalah implementasi yang aman, yang merupakan tantangan.
)# Apa itu, dan bagaimana cara kerjanya?
Inti dari abstraksi akun adalah sederhana: memungkinkan kontrak pintar untuk memulai transaksi, bukan hanya EOA. Seluruh kompleksitas berasal dari cara mewujudkan ini dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi dan mencegah serangan penolakan layanan.
Tantangan kunci yang khas adalah masalah kegagalan berganda:
Jika ada 1000 fungsi verifikasi akun yang bergantung pada satu nilai tunggal S, dan nilai S saat ini membuat transaksi dalam mempool semuanya valid, maka satu transaksi tunggal yang membalikkan 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 usaha, yang bertujuan untuk memperluas fungsionalitas sekaligus membatasi risiko penolakan layanan ###DoS(, akhirnya menghasilkan solusi untuk mencapai "abstraksi akun yang ideal": ERC-4337.
Cara kerja ERC-4337 membagi pemrosesan operasi pengguna menjadi dua tahap: verifikasi dan eksekusi. Semua verifikasi diproses terlebih dahulu, dan semua eksekusi diproses kemudian. Di dalam mempool, operasi pengguna hanya akan diterima jika tahap verifikasinya hanya melibatkan akunnya sendiri dan tidak membaca variabel lingkungan. Ini dapat mencegah serangan kegagalan ganda. Selain itu, batas gas yang ketat juga diterapkan pada langkah verifikasi.
![Vitalik tentang masa depan Ethereum yang mungkin (enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
ERC-4337 dirancang sebagai standar protokol tambahan )ERC(, karena pada saat itu pengembang klien Ethereum fokus pada penggabungan )Merge(, tidak ada energi tambahan untuk menangani fungsi lainnya. Inilah sebabnya mengapa ERC-4337 menggunakan objek yang disebut operasi pengguna, alih-alih transaksi biasa. Namun, baru-baru ini kami menyadari perlunya menulis setidaknya sebagian dari konten tersebut ke dalam protokol.
Dua alasan kunci adalah sebagai berikut:
EntryPoint sebagai inefisiensi inheren kontrak: setiap bundel memiliki biaya tetap sekitar 100.000 gas, ditambah ribuan gas tambahan untuk setiap operasi pengguna.
Memastikan kebutuhan atribut Ethereum: seperti daftar yang dibuat yang mencakup jaminan yang perlu dipindahkan ke pengguna abstrak akun.
Selain itu, ERC-4337 juga memperluas dua fungsi:
Pembayaran agen )Paymasters(: memungkinkan satu akun untuk membayar biaya atas nama akun lain, yang melanggar aturan bahwa hanya akun pengirim yang dapat diakses selama fase verifikasi, sehingga pengolahan khusus diperkenalkan untuk memastikan keamanan mekanisme agen pembayaran.
Aggregator ) Aggregators (: Mendukung fungsi penggabungan tanda tangan, seperti penggabungan BLS atau penggabungan berbasis SNARK. Ini diperlukan untuk mencapai efisiensi data tertinggi pada Rollup.
)# Pekerjaan yang tersisa dan pertimbangannya
Saat ini, masalah utama yang perlu dipecahkan adalah bagaimana mengimplementasikan abstraksi akun sepenuhnya ke dalam protokol. EIP yang baru-baru ini populer untuk abstraksi akun dalam protokol adalah EIP-7701, yang mengimplementasikan abstraksi akun di atas EOF. Sebuah akun dapat memiliki bagian kode terpisah untuk verifikasi; jika akun mengatur bagian kode tersebut, maka kode itu akan dieksekusi dalam langkah verifikasi transaksi yang berasal dari akun tersebut.
Daya tarik dari 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 untuk eksekusi kode EVM
Jika kita mulai dengan menetapkan batasan ketat pada kompleksitas kode yang dapat dieksekusi selama periode verifikasi—tidak diizinkan mengakses status eksternal, bahkan batas gas yang ditetapkan di awal juga terlalu rendah untuk aplikasi ketahanan kuantum atau perlindungan privasi—maka keamanan pendekatan ini menjadi sangat jelas: hanya mengganti verifikasi ECDSA dengan eksekusi kode EVM yang memerlukan waktu serupa.
Namun, seiring berjalannya waktu, kita perlu melonggarkan batasan-batasan ini, karena memungkinkan aplikasi perlindungan privasi bekerja tanpa relai, 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 minimal.
Tampaknya kompromi utama adalah "menulis solusi yang memuaskan lebih sedikit orang dengan cepat" versus "menunggu lebih lama, mungkin mendapatkan solusi yang lebih ideal", metode ideal mungkin adalah semacam pendekatan campuran. Salah satu pendekatan campuran adalah menulis beberapa kasus penggunaan lebih cepat, dan menyisihkan lebih banyak waktu untuk mengeksplorasi kasus penggunaan lainnya. Pendekatan lain adalah terlebih dahulu menerapkan versi abstraksi akun yang lebih ambisius di L2. Namun, tantangan yang dihadapi adalah tim L2 perlu memiliki kepercayaan penuh pada pekerjaan adopsi proposal tersebut supaya mau melaksanakannya, terutama untuk memastikan bahwa L1 dan/atau L2 lainnya di masa depan dapat mengadopsi solusi yang kompatibel.
![Vitalik tentang kemungkinan masa depan Ethereum (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
Satu aplikasi lain yang perlu kita pertimbangkan dengan jelas adalah akun penyimpanan kunci, di mana akun-akun ini menyimpan status terkait akun di L1 atau L2 khusus, tetapi dapat digunakan di L1 dan L2 yang kompatibel. Untuk melakukan ini secara efektif mungkin memerlukan L2 untuk mendukung opcode seperti L1SLOAD atau REMOTESTATICCALL, tetapi ini juga memerlukan implementasi abstraksi akun di L2 untuk mendukung operasi ini.
)# Bagaimana ia berinteraksi dengan bagian lain dari peta jalan?
Daftar inklusi perlu mendukung transaksi abstraksi akun, dalam praktiknya, kebutuhan daftar inklusi sangat mirip dengan kebutuhan memori pool terdesentralisasi, meskipun fleksibilitas untuk daftar inklusi sedikit lebih besar. Selain itu, implementasi abstraksi akun harus sedapat mungkin mencapai koordinasi antara L1 dan L2. Jika ke depan kita mengharapkan sebagian besar pengguna menggunakan penyimpanan kunci Rollup, desain abstraksi akun harus
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
11 Suka
Hadiah
11
7
Bagikan
Komentar
0/400
UnluckyMiner
· 1jam yang lalu
Masih saja evm bull ya
Lihat AsliBalas0
AirdropLicker
· 20jam yang lalu
Selamat tinggal, pump Gas datang
Lihat AsliBalas0
ChainWanderingPoet
· 08-05 23:23
Biaya harus dioptimalkan lagi, BTC saja tidak bisa diatasi.
Lihat AsliBalas0
LeverageAddict
· 08-03 22:13
shitcoin sudah lari ke evm, Ether machine masih macet
Proyeksi Masa Depan Protokol Ethereum: Upgrade EVM, Abstraksi Akun, dan Optimasi Pencucian Uang
Masa Depan Protokol Ethereum ( Enam ): Kemakmuran
Desain protokol Ethereum memiliki banyak "detail" yang sangat penting untuk keberhasilannya. Sekitar setengah isi berkaitan dengan berbagai jenis perbaikan EVM, sementara sisanya terdiri dari berbagai topik kecil, inilah yang dimaksud dengan "kemakmuran".
Kemakmuran: Tujuan Kunci
EVM perbaikan
Masalah apa yang diselesaikan?
Saat ini, EVM sulit untuk dianalisis secara statis, yang membuat sulit untuk membuat implementasi yang efisien, memverifikasi kode secara formal, dan memperluas lebih lanjut. Selain itu, efisiensi EVM yang rendah membuat sulit untuk menerapkan banyak kriptografi tingkat tinggi, kecuali dengan dukungan eksplisit melalui prapemrograman.
Apa itu, dan bagaimana cara kerjanya?
Langkah pertama dari peta jalan peningkatan EVM saat ini adalah format objek EVM (EOF), yang direncanakan akan dimasukkan dalam hard fork berikutnya. EOF adalah serangkaian EIP, yang menetapkan versi kode EVM baru, dengan banyak fitur unik, yang paling mencolok adalah:
Kontrak lama akan terus ada dan dapat dibuat, meskipun pada akhirnya mungkin akan secara bertahap ditinggalkan ) bahkan mungkin dipaksa untuk dikonversi menjadi kode EOF (. Kontrak baru akan mendapat manfaat dari peningkatan efisiensi yang dibawa oleh EOF—pertama dengan bytecode yang sedikit lebih kecil melalui fitur sub-rutin, dan kemudian dengan fungsi baru atau biaya gas yang berkurang yang spesifik untuk EOF.
Setelah memperkenalkan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini yang paling berkembang adalah perluasan aritmatika modul EVM ) EVM-MAX (. EVM-MAX menciptakan sekumpulan operasi baru yang khusus untuk operasi modulo, dan menempatkannya dalam ruang memori baru yang tidak dapat diakses melalui opcode lainnya, sehingga memungkinkan penggunaan optimasi seperti perkalian Montgomery.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Sebuah ide yang lebih baru adalah menggabungkan EVM-MAX dengan fitur Single Instruction Multiple Data )SIMD(, SIMD sebagai sebuah konsep dalam Ethereum telah ada selama waktu yang lama, pertama kali diusulkan oleh Greg Colvin dalam EIP-616. SIMD dapat digunakan untuk mempercepat banyak bentuk kriptografi, termasuk fungsi hash, 32-bit STARKs, dan kriptografi berbasis kisi, penggabungan EVM-MAX dan SIMD membuat kedua ekspansi yang berorientasi pada kinerja ini menjadi pasangan yang alami.
Dalam implementasi nyata, ini akan diproses secara paralel.
)# Pekerjaan yang tersisa dan pertimbangannya
Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu ada kemungkinan untuk menghapusnya di saat-saat terakhir — sebelumnya ada fungsi yang sementara dihapus dalam hard fork sebelumnya, tetapi melakukan hal itu akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap upgrade masa depan terhadap EVM harus dilakukan tanpa EOF, meskipun itu bisa dilakukan, tetapi mungkin akan lebih sulit.
Pertimbangan utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah sejumlah besar kode yang perlu ditambahkan ke implementasi EVM, dan pemeriksaan kode statis juga relatif kompleks. Namun, sebagai imbalan, kita dapat menyederhanakan bahasa tingkat tinggi, menyederhanakan implementasi EVM, dan manfaat lainnya. Dapat dikatakan bahwa prioritas untuk peta jalan perbaikan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.
Salah satu pekerjaan penting yang perlu dilakukan adalah mewujudkan fungsi serupa EVM-MAX ditambah SIMD, dan melakukan pengujian kinerja 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 secara sinkron, mungkin akan menyebabkan ketidakcocokan dan membawa dampak negatif. Selain itu, EVM-MAX dan SIMD dapat mengurangi biaya gas dari banyak sistem bukti, sehingga membuat L2 lebih efisien. Ini juga membuat lebih mudah untuk mengganti lebih banyak precompiled dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak akan mempengaruhi efisiensi secara signifikan.
![Vitalik tentang kemungkinan masa depan Ethereum (Enam): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
) abstraksi akun
Apa masalah yang diselesaikan?
Saat ini, transaksi hanya dapat divalidasi dengan satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun dirancang untuk melampaui hal ini, memungkinkan logika verifikasi akun untuk berupa kode EVM yang arbitrer. Ini dapat mengaktifkan serangkaian aplikasi:
Memungkinkan protokol privasi berfungsi tanpa perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang penting.
Sejak pengenalan abstraksi akun pada tahun 2015, tujuannya juga diperluas untuk mencakup sejumlah "tujuan kenyamanan", misalnya, sebuah akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat menggunakan ERC20 untuk membayar gas.
MPC) komputasi multi pihak ( adalah teknologi yang telah ada selama 40 tahun, digunakan untuk membagi kunci menjadi beberapa bagian dan menyimpannya di beberapa perangkat, memanfaatkan teknik kriptografi untuk menghasilkan tanda tangan, tanpa perlu menggabungkan bagian-bagian kunci tersebut secara langsung.
EIP-7702 adalah proposal yang direncanakan untuk diperkenalkan dalam hard fork berikutnya, EIP-7702 merupakan hasil dari kesadaran yang semakin meningkat untuk menyediakan kenyamanan abstraksi akun yang menguntungkan semua pengguna ) termasuk pengguna EOA (, bertujuan untuk meningkatkan pengalaman semua pengguna dalam jangka pendek, dan menghindari terpecah menjadi dua ekosistem.
Pekerjaan ini dimulai dengan EIP-3074, dan akhirnya membentuk EIP-7702. EIP-7702 memberikan "fungsi kenyamanan" dari abstraksi akun kepada semua pengguna, termasuk EOA) yang dimiliki secara eksternal hari ini, yaitu akun yang dikendalikan oleh tanda tangan ECDSA(.
Meskipun beberapa tantangan ) terutama tantangan "kenyamanan" ( dapat diatasi melalui teknologi bertahap seperti komputasi multi pihak atau EIP-7702, tujuan keamanan utama dari proposal abstraksi akun yang awalnya diajukan hanya dapat dicapai dengan kembali dan menyelesaikan masalah asli: memungkinkan kode kontrak pintar untuk mengontrol verifikasi transaksi. Alasan mengapa ini belum terwujud hingga saat ini adalah implementasi yang aman, yang merupakan tantangan.
)# Apa itu, dan bagaimana cara kerjanya?
Inti dari abstraksi akun adalah sederhana: memungkinkan kontrak pintar untuk memulai transaksi, bukan hanya EOA. Seluruh kompleksitas berasal dari cara mewujudkan ini dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi dan mencegah serangan penolakan layanan.
Tantangan kunci yang khas adalah masalah kegagalan berganda:
Jika ada 1000 fungsi verifikasi akun yang bergantung pada satu nilai tunggal S, dan nilai S saat ini membuat transaksi dalam mempool semuanya valid, maka satu transaksi tunggal yang membalikkan 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 usaha, yang bertujuan untuk memperluas fungsionalitas sekaligus membatasi risiko penolakan layanan ###DoS(, akhirnya menghasilkan solusi untuk mencapai "abstraksi akun yang ideal": ERC-4337.
Cara kerja ERC-4337 membagi pemrosesan operasi pengguna menjadi dua tahap: verifikasi dan eksekusi. Semua verifikasi diproses terlebih dahulu, dan semua eksekusi diproses kemudian. Di dalam mempool, operasi pengguna hanya akan diterima jika tahap verifikasinya hanya melibatkan akunnya sendiri dan tidak membaca variabel lingkungan. Ini dapat mencegah serangan kegagalan ganda. Selain itu, batas gas yang ketat juga diterapkan pada langkah verifikasi.
![Vitalik tentang masa depan Ethereum yang mungkin (enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
ERC-4337 dirancang sebagai standar protokol tambahan )ERC(, karena pada saat itu pengembang klien Ethereum fokus pada penggabungan )Merge(, tidak ada energi tambahan untuk menangani fungsi lainnya. Inilah sebabnya mengapa ERC-4337 menggunakan objek yang disebut operasi pengguna, alih-alih transaksi biasa. Namun, baru-baru ini kami menyadari perlunya menulis setidaknya sebagian dari konten tersebut ke dalam protokol.
Dua alasan kunci adalah sebagai berikut:
Selain itu, ERC-4337 juga memperluas dua fungsi:
)# Pekerjaan yang tersisa dan pertimbangannya
Saat ini, masalah utama yang perlu dipecahkan adalah bagaimana mengimplementasikan abstraksi akun sepenuhnya ke dalam protokol. EIP yang baru-baru ini populer untuk abstraksi akun dalam protokol adalah EIP-7701, yang mengimplementasikan abstraksi akun di atas EOF. Sebuah akun dapat memiliki bagian kode terpisah untuk verifikasi; jika akun mengatur bagian kode tersebut, maka kode itu akan dieksekusi dalam langkah verifikasi transaksi yang berasal dari akun tersebut.
Daya tarik dari metode ini terletak pada kenyataan bahwa ia dengan jelas menunjukkan dua perspektif setara dari abstraksi akun lokal:
Jika kita mulai dengan menetapkan batasan ketat pada kompleksitas kode yang dapat dieksekusi selama periode verifikasi—tidak diizinkan mengakses status eksternal, bahkan batas gas yang ditetapkan di awal juga terlalu rendah untuk aplikasi ketahanan kuantum atau perlindungan privasi—maka keamanan pendekatan ini menjadi sangat jelas: hanya mengganti verifikasi ECDSA dengan eksekusi kode EVM yang memerlukan waktu serupa.
Namun, seiring berjalannya waktu, kita perlu melonggarkan batasan-batasan ini, karena memungkinkan aplikasi perlindungan privasi bekerja tanpa relai, 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 minimal.
Tampaknya kompromi utama adalah "menulis solusi yang memuaskan lebih sedikit orang dengan cepat" versus "menunggu lebih lama, mungkin mendapatkan solusi yang lebih ideal", metode ideal mungkin adalah semacam pendekatan campuran. Salah satu pendekatan campuran adalah menulis beberapa kasus penggunaan lebih cepat, dan menyisihkan lebih banyak waktu untuk mengeksplorasi kasus penggunaan lainnya. Pendekatan lain adalah terlebih dahulu menerapkan versi abstraksi akun yang lebih ambisius di L2. Namun, tantangan yang dihadapi adalah tim L2 perlu memiliki kepercayaan penuh pada pekerjaan adopsi proposal tersebut supaya mau melaksanakannya, terutama untuk memastikan bahwa L1 dan/atau L2 lainnya di masa depan dapat mengadopsi solusi yang kompatibel.
![Vitalik tentang kemungkinan masa depan Ethereum (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
Satu aplikasi lain yang perlu kita pertimbangkan dengan jelas adalah akun penyimpanan kunci, di mana akun-akun ini menyimpan status terkait akun di L1 atau L2 khusus, tetapi dapat digunakan di L1 dan L2 yang kompatibel. Untuk melakukan ini secara efektif mungkin memerlukan L2 untuk mendukung opcode seperti L1SLOAD atau REMOTESTATICCALL, tetapi ini juga memerlukan implementasi abstraksi akun di L2 untuk mendukung operasi ini.
)# Bagaimana ia berinteraksi dengan bagian lain dari peta jalan?
Daftar inklusi perlu mendukung transaksi abstraksi akun, dalam praktiknya, kebutuhan daftar inklusi sangat mirip dengan kebutuhan memori pool terdesentralisasi, meskipun fleksibilitas untuk daftar inklusi sedikit lebih besar. Selain itu, implementasi abstraksi akun harus sedapat mungkin mencapai koordinasi antara L1 dan L2. Jika ke depan kita mengharapkan sebagian besar pengguna menggunakan penyimpanan kunci Rollup, desain abstraksi akun harus