Mendalami Masa Lalu dan Masa Depan Jalur Abstraksi Akun Ethereum

Pendahuluan

Artikel ini dibagi menjadi dua modul besar:

Bagian atas dimulai dari proposal AA pertama pada tahun 2015, sistem ini merangkum konten proposal EIP utama sampai saat ini, meninjau sejarah proposal AA, dan melakukan evaluasi komprehensif terhadap kelebihan dan kekurangan masing-masing skema.

Bagian bawah menekankan perbandingan antara umpan balik pasar yang buruk setelah peluncuran EIP4337, serta analisis mendalam tentang EIP7702 yang akan dimasukkan dalam pembaruan versi berikutnya dari Ethereum. Proposal ini, setelah digabungkan, akan mengubah bentuk aplikasi di blockchain secara menyeluruh.

EIP-7702 memiliki makna yang sangat penting, mari kita bahas lebih dalam.

1. Latar Belakang Akun Abstrak

1.1 Penempatan makna dari account abstraction

Pendiri Ethereum, Vitalik, kembali memperbarui peta jalan pengembangan ETH pada akhir tahun 2023, tetapi pengaturan untuk abstraksi akun tidak berubah. Saat ini, model utama sedang beralih dari EIP-4337 menuju fase berikutnya, yaitu VoluntaryEOA Conversion(, yang merupakan transisi ke akun EOA secara sukarela).

1.2 Status pasar dari account abstraction

Setelah satu setengah tahun pengembangan, jumlah akun EIP4337 di rantai utama hanya 12 juta, di mana jumlah alamat aktif di jaringan utama Ethereum hanya 6.764, yang merupakan selisih besar dibandingkan dengan jumlah alamat EOA dan CA. Jumlah alamat independen di jaringan utama Ethereum telah mencapai 270 juta, yang menunjukkan bahwa EIP4337 hampir tidak memiliki perkembangan substansial di jaringan utama.

Namun, ini tidak mempengaruhi nilai dasar dari AA. Sejak awal desain EIP4337 sudah ditakdirkan sulit untuk menyelesaikan masalah kompatibilitas mainnet, tetapi telah diterapkan secara luas di berbagai L2 layer chain. Di antaranya, jumlah pengguna aktif bulanan di chain Base dan Polygon masing-masing mencapai 1 juta dan 3 juta pada bulan Juli, menunjukkan kinerja yang baik.

Oleh karena itu, desain EIP4337 itu sendiri tidak ada masalah, situasi saat ini disebabkan oleh perbedaan antara mainnet dan L2, yang membutuhkan penerapan solusi yang berbeda.

2. Apa itu account abstraction?

account abstraction pada dasarnya menyelesaikan masalah pemisahan hak milik.

Dalam arsitektur EVM terdapat dua jenis akun: akun eksternal ( EOA ) dan akun kontrak ( Contract Account ). Kepemilikan dan hak tanda tangan EOA sebenarnya dimiliki oleh entitas yang sama. Orang yang memiliki kunci pribadi tidak hanya memiliki "kepemilikan akun", tetapi juga dapat "menandatangani untuk mentransfer semua aset".

Ini ditentukan oleh struktur transaksi akun Ethereum. Dalam struktur transaksi standar tidak ada bidang From, transfer dana dilakukan melalui parameter VRS ( yang ditandatangani pengguna ) untuk mengurai alamat From.

Efek inti dari EIP4337 adalah menambahkan Alamat Pengirim dalam bidang transaksi, sehingga mewujudkan pemisahan antara kunci pribadi dan alamat yang dioperasikan.

Alasan mengapa pemisahan kepemilikan sangat penting adalah bahwa desain EOA akan menimbulkan banyak masalah:

1. Kunci pribadi sulit dilindungi: kehilangan kunci pribadi berarti kehilangan semua aset.

2. Algoritma tanda tangan tunggal: Protokol asli hanya dapat menggunakan algoritma ECDSA untuk memverifikasi transaksi.

3. Izin tanda tangan terlalu tinggi: tidak ada tanda tangan ganda asli, tanda tangan tunggal dapat melakukan operasi apa pun.

4. Biaya transaksi hanya dapat dibayar dengan ETH, tidak mendukung transaksi massal.

5. Kebocoran privasi transaksi: transaksi satu lawan satu mudah untuk menganalisis informasi pemilik akun.

Pembatasan ini membuat pengguna biasa sulit untuk menggunakan Ethereum:

Pertama, menggunakan aplikasi Ethereum harus memiliki ETH dan menanggung risiko fluktuasi harga.

Kedua, pengguna perlu menangani logika biaya yang kompleks, seperti harga Gas, batas Gas, dan konsep pemblokiran transaksi.

Akhirnya, meskipun banyak dompet blockchain mencoba meningkatkan pengalaman pengguna melalui optimasi produk, hasilnya terbatas.

Oleh karena itu, terobosan terletak pada mewujudkan account abstraction, memisahkan kepemilikan (Owner) dan hak tanda tangan (Signer), sehingga secara bertahap menyelesaikan masalah yang disebutkan di atas.

Dalam sejarah terdapat berbagai rencana, yang akhirnya disimpulkan menjadi dua jalur.

3. Penelusuran Latar Belakang Proposal AA

Sepertinya ada banyak proposal EIP untuk solusi masalah, tetapi pada akhirnya hanya ada dua pemikiran inti. Setiap masalah yang dipertimbangkan oleh EIP yang tidak disetujui telah berkumpul menjadi titik terobosan dari solusi saat ini.

3.1 Rute pertama: Mengubah alamat EOA menjadi alamat CA

Pada 15 November 2015, Vitalik telah mengusulkan struktur baru untuk akun sebagai kontrak dalam EIP-101. Mengubah alamat menjadi hanya kode dan ruang penyimpanan, mendukung pembayaran biaya menggunakan ERC20, melalui kontrak pra-kompilasi mengubah token asli menjadi saldo mirip ERC20, dan menyederhanakan bidang transaksi menjadi to, startgas, data, dan code.

Rencana ini dapat menghasilkan beberapa fungsi:

1. Transaksi dapat menggunakan lebih banyak algoritma kripto, yang ditentukan oleh metode verifikasi yang ditentukan dalam kode internal alamat.

2. Memiliki karakteristik tahan serangan kuantum, karena kode dapat ditingkatkan

3. Membuat ETH memiliki fungsi yang sama dengan kontrak ERC20, seperti otorisasi pemotongan.

4. Meningkatkan ruang kustomisasi akun, mendukung pemulihan sosial, dukungan SBT, pemulihan kunci, dll.

Alasan untuk tidak dapat melanjutkan sangat sederhana, langkah yang diambil terlalu besar, dan ada kurangnya pertimbangan terhadap masalah konflik hash transaksi saat ini dan potensi risiko keamanan. Namun, setiap konsep keunggulan menjadi salah satu fungsi inti dari EIP4337 dan EIP7702 yang akan datang.

Selanjutnya ada serangkaian EIP yang mencoba menyempurnakan logika ini:

EIP-859: abstraksi akun rantai utama (2018-01-30)

Mencoba menyelesaikan masalah penyebaran kode, inti dari ini adalah jika kontrak pihak transaksi belum disebarkan, maka gunakan parameter kode yang menyertai transaksi untuk melakukan penyebaran. Juga diusulkan opcode PAYGAS baru sebagai pemisah antara bagian verifikasi dan bagian eksekusi dalam parameter transaksi.

Meskipun pada saat itu berakhir tanpa hasil, tetapi menjadi salah satu logika inti dari EIP7702. Setiap transaksi EIP7702 dapat menggabungkan struktur transaksi khusus yang menyertakan kode, memungkinkan alamat EOA memiliki kemampuan kontrak dalam transaksi ini.

EIP-7702: mengatur kode akun EOA (2024-05-07)

Ini adalah EIP inti yang akan dibahas lebih lanjut dalam artikel ini, yang diajukan oleh Vitalik sebagai alternatif untuk EIP-3074. EIP-3074 telah ditinggalkan, dan EIP-7702 dipastikan akan dimasukkan dalam hard fork ETH Prague/Electra yang akan datang.

3.2 Rute kedua: membiarkan alamat EOA menggerakkan alamat CA

EIP-3074: menambahkan opcode AUTH dan AUTHCALL (2020-10-15)

Menambahkan dua opcode baru AUTH dan AUTHCALL ke dalam EVM, sehingga EOA dapat memberi wewenang kepada kontrak untuk memanggil kontrak lain atas nama identitas EOA melalui dua opcode ini.

EOA dapat mengirimkan pesan yang telah ditandatangani ( transaksi ) ke kontrak tepercaya ( yang disebut Invoker ), kontrak Invoker ini dapat menggunakan opcode AUTH dan AUTHCALL sebagai pengganti EOA untuk mengirimkan transaksi.

EIP-4337: Mengimplementasikan abstraksi akun melalui mempool transaksi (2021-09-29)

Dirancang dengan inspirasi dari MEV, nilai inti adalah sepenuhnya menghindari perubahan pada protokol lapisan konsensus.

Mengajukan objek transaksi baru UserOperation, pengguna mengirimkan objek ini ke mempool, yang kemudian dibundel oleh bundlers dari perspektif penambang untuk mengemas dan mengirimkan transaksi eksekusi kontrak secara massal, pada dasarnya mengangkat transaksi dasar dan operasi akun ke tingkat kontrak untuk dieksekusi.

EIP-5189: melalui operator penjamin mengoperasikan akun abstrak (2022-06-29)

Optimalkan logika EIP4337, dengan membangun mekanisme dukungan penalti dana untuk mencegah serangan blokir DoS.

3.3 Proposal lain yang mendukung akun abstraksi

EIP-2718: pembungkus jenis transaksi baru (2020-06-13)

Proposal yang sudah Final, mendefinisikan jenis transaksi baru sebagai amplop untuk jenis transaksi yang akan ditambahkan di masa depan.

Saat memperkenalkan jenis transaksi baru, dibedakan melalui pengkodean tertentu, hanya perlu kompatibel ke belakang tanpa perlu kompatibel ke depan. Contoh yang paling umum adalah EIP1559, yang membedakan biaya transaksi, menggunakan pengkodean jenis transaksi baru, tidak mempengaruhi jenis transaksi legacy yang awal.

EIP-3607: membatasi alamat EOA dalam penerapan kontrak (2021-06-10)

Rencana tambahan di jalur AA, untuk mencegah konflik antara alamat penyebaran kontrak dan alamat EOA. Mengontrol metode pembuatan kontrak, tidak mengizinkan penyebaran kode ke alamat yang sudah merupakan EOA. Risiko ini sangat kecil, alamat Ethereum sepanjang 160 bit, meskipun ada metode untuk menemukan kunci pribadi yang menghasilkan alamat kontrak tertentu, namun diperkirakan juga memerlukan waktu satu tahun dengan seluruh daya komputasi Bitcoin.

3.4 Bagaimana memahami perkembangan akuntabilitas abstrak?

Pertama-tama perlu memahami nilai setelah diubah menjadi CA, pada dasarnya ini adalah efek nyata dari EIP-4337:

Namun, kekurangan utama EIP-4337 adalah bertentangan dengan prinsip motivasi manusia.

Terlihat lebih baik, namun terjebak dalam siklus kematian perkembangan pasar. Banyak Dapp tidak kompatibel, pengguna enggan menggunakan alamat CA, menggunakan CA bahkan memiliki biaya transaksi yang lebih tinggi. Terlalu bergantung pada kompatibilitas Dapp itu sendiri.

Oleh karena itu, hingga saat ini belum ada adopsi di jaringan utama Ethereum.

Biaya adalah standar pengukuran terpenting bagi pengguna, harus menurunkan biaya.

Untuk benar-benar mengurangi Gas, Ethereum itu sendiri harus melakukan upgrade soft fork, mengubah perhitungan Gas atau modul konsumsi Gas opcode. Jika ingin melakukan soft fork, mengapa tidak langsung mempertimbangkan EIP-7702?

4. Analisis Komprehensif EIP-7702

4.1 Apa itu EIP-7702

Dengan membedakan jenis transaksi baru, memungkinkan EOA untuk secara sementara memiliki fungsi kontrak pintar dalam satu transaksi, mendukung transaksi massal, transaksi tanpa Gas, dan manajemen hak akses kustom, serta tidak perlu memperkenalkan opCode EVM baru.

Pengguna tidak perlu mengdeploy kontrak pintar untuk mendapatkan sebagian besar kemampuan AA, bahkan dapat menyediakan kemampuan untuk pihak ketiga untuk memulai transaksi atas nama pengguna, cukup dengan menandatangani informasi otorisasi alih-alih memberikan kunci pribadi.

4.2 Struktur Data

Mendefinisikan jenis transaksi baru 0x04, TransactionPayload adalah hasil serialisasi RLP dari konten berikut:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Menambahkan objek authorization_list, menyimpan kode yang ingin dieksekusi oleh penandatangan di EOA. Pengguna menandatangani transaksi sambil menandatangani kode kontrak yang akan dieksekusi, disimpan sebagai daftar dua dimensi, dapat menyimpan beberapa informasi operasi secara massal.

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

4.3 siklus hidup transaksi

4.3.1 tahap verifikasi

Saat transaksi dimulai, untuk setiap tuple [chain_id, address, nonce, y_parity, r, s] dari authorization_list:

1. Menggunakan tanda tangan r, s untuk memulihkan alamat penandatangan dengan ecrecover.

2. Verifikasi Chain ID ( untuk mencegah pemutaran ulang rantai fork ).

3. Verifikasi apakah kode penandatangan authority kosong atau telah didelegasikan.

4. Verifikasi nonce authority signer ( untuk mencegah pengulangan tanda tangan authority ).

5. Atur kode penandatangan authority menjadi 0xef0100 || alamat.

6. Menambah nonce penandatangan authority( untuk mencegah replay tanda tangan lokal).

7. Tambahkan akun penanda tangan authority ke daftar alamat yang telah diakses.

4.3.2 tahap eksekusi operasi

"Versi " baru hanya mengubah perilaku penyebaran kode.

Tidak lagi mengatur kode akun sebagai contract_code, melainkan mengambil kode dari kolom address di authorization_list dan mengaturnya sebagai kode akun.

Saat mengeksekusi kode otorisasi, muat kode dari alamat yang ditentukan dalam authorization_list dan eksekusi dalam konteks akun penandatangan.

Kode kontrak pengguna disimpan di alamat tertentu di blockchain, tidak langsung termasuk dalam transaksi.

Perintah operasi dan parameter terkait disimpan dalam bidang data muatan transaksi.

4.4 Nilai EIP-7702

Ada perubahan pada seluruh jalur Web3 wallet, pengalaman pengguna mengalami perubahan besar. EOA yang memulai transaksi biasa dapat menjalankan berbagai logika seperti eksekusi kontrak, seperti transfer massal. Ini mempengaruhi identifikasi transaksi di skenario CeFi, serta biaya pengisian dan penarikan.

Memecahkan berbagai pola pikir yang ada:

1. Saldo akun dapat berkurang karena transaksi yang tidak berasal dari akun tersebut.

2. Setelah eksekusi transaksi dimulai, nonce EOA mungkin meningkat beberapa kali.

3. Memecahkan logika perlindungan perbandingan tx.origin dan msg.sender, banyak kontrak yang ada memiliki risiko.

4. EOA itu sendiri dapat mengeluarkan event, mempengaruhi beberapa pengenalan event di rantai.

5. Alamat EOA menerima aset ERC20, 721, 1155, dll mungkin gagal ( karena mekanisme callback ).

4.5 Perbandingan EIP-7702 dan EIP-4337

1. Keuntungan EIP-7702

• Gas lebih rendah, tidak perlu melalui modul entrypoint, mengurangi operasi di blockchain.
• Biaya migrasi pengguna lebih rendah, tidak perlu mengimplementasikan kontrak di blockchain sebelumnya.
• Sama seperti EIP4337, ada pelaksanaan kode yang didelegasikan, dengan dua cara:

Penyerahan Penuh(Full Delegation)

• Melakukan suatu operasi