Pengembang Ethereum baru-baru ini mengungkapkan kemajuan dalam desain EIP-8141. Proposal ini mencoba menuliskan sebagian fungsi transaksi sebagai panggilan kontrak yang dapat diprogram, yang disebut "frames", daripada mengubah format pembungkus transaksi Ethereum setiap kali menambahkan fitur baru.
Fungsi perdagangan diubah menjadi dapat dipanggil secara terprogram
Fitur yang dicakup oleh pendekatan ini meliputi kedaluwarsa transaksi, tanda tangan agregasi, akar Merkle terkait kolam privasi, serta pemeriksaan asersi setelah eksekusi transaksi. Para pengembang percaya bahwa jika antarmuka ini cukup umum, ketika Ethereum memperkenalkan metode validasi baru di masa depan, dompet, browser, perangkat tanda tangan, dan Layer 2 tidak perlu menyesuaikan wadah transaksi baru setiap kali.
Draf EIP-8141 mendefinisikan satu Frame Transaction sebagai serangkaian pemanggilan kontrak. Frame yang berbeda dapat bertanggung jawab untuk memverifikasi kondisi transaksi, menyetujui pembayaran gas, atau mengeksekusi operasi pengguna.
Draft saat ini mencantumkan tiga mode: DEFAULT, VERIFY, dan SENDER. Frame VERIFY digunakan untuk memeriksa apakah suatu kondisi terpenuhi, sedangkan frame SENDER mewakili tindakan yang dilakukan oleh pengirim transaksi. Beberapa frame juga dapat membentuk batch atomik, yang berarti semuanya berhasil atau seluruhnya dibatalkan.
Kurangi biaya koordinasi dompet dan infrastruktur
Pandangan inti pengembang Derek Chiang adalah bahwa fitur baru di masa depan tidak perlu selalu merancang satu set pengepakan perdagangan baru. Dengan hanya menyatakan melalui target frame dan pola pemanggilan baru, kemampuan dapat diperluas sambil menjaga stabilitas struktur dasar.
Setiap perubahan pada pembungkusan transaksi Ethereum tidak hanya berdampak pada klien eksekusi. Dompet, Layer 2, browser blok, perangkat keras tanda tangan, perpustakaan perangkat lunak, dan berbagai penyedia infrastruktur lainnya harus memahami dan mendukung format baru.
Chiang menyatakan bahwa pembaruan Ethereum berlangsung sekitar setiap sembilan bulan, dan jika sering mengubah pengemasan transaksi, biaya koordinasi akan sangat tinggi. Sebaliknya, jika format frame dapat menjadi antarmuka yang lebih stabil, metode verifikasi baru dapat lebih banyak ditangani oleh kontrak atau komponen protokol yang ditentukan.
Namun, ini tidak berarti semua fitur masa depan dapat menghindari pembaruan jaringan. EIP-8141 sendiri tetap akan memodifikasi aturan konsensus Ethereum dan memerlukan implementasi klien. Jika melibatkan opcode baru, kontrak precompile, atau aturan gas, masih mungkin memerlukan hard fork.
EIP-8130 dan arah verifikasi paralel
Para pengembang juga mengakui bahwa peningkatan tingkat abstraksi transaksi membuat analisis transaksi oleh dompet dan sequencer sebelum eksekusi menjadi lebih sulit. Untuk ini, tim sedang meneliti cara menggabungkan EIP-8141 dengan draf abstraksi akun lainnya, EIP-8130.
EIP-8130 mengusulkan struktur keystore on-chain yang memungkinkan akun mendaftarkan peserta dan kontrak otentikasi secara pra-terdaftar, serta secara jelas menandai metode otentikasi dalam transaksi. Dengan demikian, node dapat menentukan proses verifikasi apa yang diperlukan oleh transaksi sebelum menjalankan kode dompet apa pun. Bagi Layer 2, ini membantu membatasi metode otentikasi menjadi sekelompok opsi yang biayanya lebih dapat diprediksi.
Vitalik Buterin juga menjelaskan arah terkait dalam postingan lainnya. Ia membagi transaksi menjadi dua bagian: "tindakan" dan "kondisi ketergantungan". Yang pertama bertanggung jawab atas perubahan status Ethereum, sementara yang kedua mencakup prasyarat seperti tanda tangan, bukti Merkle, atau bukti zero-knowledge. Jika ketergantungan ini saling independen, di masa depan mereka mungkin dapat diperiksa secara paralel, sehingga mengurangi biaya pemrosesan sebagian transaksi.
Telah dimasukkan ke Hegotá, tetapi waktu aktivasi belum ditentukan
EIP Meta Hegotá resmi mencantumkan Frame Transactions sebagai salah satu peningkatan yang direncanakan, yang berarti statusnya telah maju lebih jauh dibanding sebelumnya. Namun, EIP-8141 saat ini masih merupakan draf inti, dan detail teknisnya belum final.
Pekerjaan yang masih perlu dilanjutkan meliputi: memperbarui spesifikasi, menyelesaikan implementasi klien eksekusi, membangun jaringan pengembangan, serta melakukan pengujian interoperabilitas dengan dompet dan sistem Layer 2. Pengembang juga perlu mengevaluasi risiko penolakan layanan mempool, karena verifikasi yang dapat diprogram dapat meningkatkan biaya komputasi untuk menyaring transaksi tidak valid.
Saat ini, waktu aktivasi Hegotá di Sepolia, Hoodi, dan jaringan utama masih kosong. EIP-8141 telah masuk ke dalam rencana peningkatan, tetapi masih ada proses implementasi dan pengujian sebelum peluncuran akhir.