Pembangun Ethereum baru-baru ini mengumumkan kemajuan dalam reka bentuk EIP-8141. Cadangan ini cuba menulis sebahagian fungsi transaksi sebagai panggilan kontrak boleh program, iaitu "frames", bukan mengubah format pembungkusan transaksi Ethereum setiap kali menambah kemampuan baru.
Fungsi perdagangan diubah kepada panggilan yang boleh diprogramkan
Fungsi yang dicakup oleh pendekatan ini termasuk tamatnya transaksi, tanda tangan teragregasi, akar Merkle yang berkaitan dengan kolam privasi, serta pemeriksaan pernyataan selepas pelaksanaan transaksi. Pembangun percaya bahawa jika antaramuka ini cukup generik, apabila Ethereum memperkenalkan cara pengesahan baharu pada masa depan, dompet, pelayar, peranti tanda tangan, dan Layer 2 tidak perlu menyesuaikan bungkus transaksi baharu setiap kali.
Draf EIP-8141 mentakrifkan satu Frame Transaction sebagai urutan panggilan kontrak. Frame yang berbeza boleh bertanggungjawab untuk mengesahkan syarat transaksi, mengesahkan pembayaran gas, atau melaksanakan tindakan pengguna.
Draf semasa menyenaraikan tiga mod: DEFAULT, VERIFY, dan SENDER. Frame VERIFY digunakan untuk memeriksa sama ada syarat tertentu dipenuhi, manakala frame SENDER mewakili tindakan yang dilakukan oleh penghantar transaksi. Beberapa frame juga boleh digabungkan menjadi pemprosesan atomik, di mana semua tindakan berjaya atau kesemuanya dikembalikan.
Kurangkan kos koordinasi dompet dan infrastruktur
Pandangan utama pembangun Derek Chiang ialah, fungsi baru masa depan tidak semestinya memerlukan reka bentuk bungkusan perdagangan yang baru. Dengan hanya menggunakan target frame dan pola panggilan baru, kemampuan boleh diperluaskan sambil mengekalkan kestabilan struktur asas.
Setiap perubahan pembungkusan transaksi Ethereum tidak hanya mempengaruhi klien pelaksanaan. Dompet, Layer 2, pelayan blok, peranti keras tanda tangan, pustaka perisian, dan penyedia infrastruktur pelbagai lain perlu memahami dan menyokong format baharu.
Chiang menyatakan bahawa pembaharuan Ethereum berlaku kira-kira setiap sembilan bulan, dan jika perubahan sering dibuat terhadap pembungkusan transaksi, kos koordinasi akan tinggi. Sebaliknya, jika format frame boleh menjadi antaramuka yang lebih stabil, kaedah pengesahan baru boleh lebih banyak ditangani oleh kontrak atau komponen protokol yang ditentukan.
Namun, ini tidak bermakna semua fungsi masa depan boleh mengelakkan pembaruan rangkaian. EIP-8141 sendiri masih akan mengubah peraturan konsensus Ethereum dan memerlukan pelaksanaan klien. Jika melibatkan opcode baru, kontrak pra-kompilasi, atau peraturan gas, mungkin masih memerlukan hard fork.
EIP-8130 dan arah pengesahan selari
Pembangun juga mengakui bahawa peningkatan abstraksi transaksi membuatkan dompet dan sorter lebih sukar untuk menganalisis transaksi sebelum pelaksanaan. Untuk tujuan ini, pasukan sedang menyelidiki cara EIP-8141 dan draf abstraksi akaun lain, EIP-8130, dapat bekerjasama.
EIP-8130 mengusulkan struktur keystore dalam rantai, membolehkan akaun mendaftar peserta dan kontrak pengesahan secara pra-tertib, serta menandakan kaedah pengesahan secara jelas dalam transaksi. Dengan cara ini, nod dapat menentukan proses pengesahan yang diperlukan sebelum menjalankan sebarang kod dompet. Bagi Layer 2, ini membantu membataskan kepada set kaedah pengesahan yang kosnya lebih boleh diramal.
Vitalik Buterin juga menjelaskan arah terkait dalam postingan lain. Beliau memecah transaksi menjadi dua bahagian: "tindakan" dan "syarat bergantung". Bahagian pertama bertanggungjawab untuk mengubah status Ethereum, manakala bahagian kedua termasuk syarat awal seperti tanda tangan, bukti Merkle, atau bukti pengetahuan sifar. Jika syarat-syarat bergantung ini saling bebas, di masa depan ia mungkin boleh diperiksa secara selari, yang akan mengurangkan kos pemprosesan sebahagian transaksi.
Telah disenaraikan di Hegotá, tetapi masa pengaktifan belum ditentukan
EIP Meta Hegotá rasmi telah menyenaraikan Frame Transactions sebagai salah satu peningkatan yang dirancang, yang bermakna statusnya telah bergerak lebih jauh berbanding sebelum ini. Namun, EIP-8141 masih merupakan draf utama, dan butiran teknikal belum ditetapkan.
Pekerjaan yang masih perlu dilanjutkan termasuk: memperbaharui spesifikasi, menyelesaikan implementasi klien pelaksana, membangun jaringan pembangunan, serta melakukan ujian interoperabiliti dengan dompet dan sistem Layer 2. Pengembang juga perlu menilai risiko serangan penolakan perkhidmatan pada memory pool, kerana pengesahan boleh diprogramkan mungkin meningkatkan kos pengiraan untuk menyaring transaksi tidak sah.
Sekarang, masa pengaktifan Hegotá di Sepolia, Hoodi, dan rangkaian utama masih kosong. EIP-8141 telah dimasukkan ke dalam pelan peningkatan, tetapi masih terdapat proses pelaksanaan dan pengujian sebelum ia dilaksanakan sepenuhnya.