Sự tiến hóa của trừu tượng hóa tài khoản Ethereum: từ EIP-4337 đến những thay đổi đột phá của EIP-7702

2025-08-04 17:32:10

Phân tích sâu về sự tiến hóa và tương lai của trừu tượng hóa tài khoản Ethereum

Lời mở đầu

Bài viết được chia thành hai phần lớn:

Phần đầu tiên bắt đầu từ đề xuất trừu tượng hóa tài khoản đầu tiên vào năm 2015, hệ thống đã tổng hợp nội dung các đề xuất EIP chính đến nay, xem xét sự tiến hóa lịch sử của các giải pháp trừu tượng hóa tài khoản, và đánh giá ưu nhược điểm của từng giải pháp.

Phần thứ hai tập trung so sánh tình hình phản ứng lạnh nhạt của thị trường sau khi EIP4337 được giới thiệu, đồng thời phân tích sâu về EIP7702 sẽ được đưa vào bản nâng cấp phiên bản tiếp theo của Ethereum. Đề xuất này một khi được hợp nhất, sẽ thay đổi cơ bản hình thái của các ứng dụng trên chuỗi.

EIP-7702 như một cuộc cải cách mang tính bước ngoặt, hãy cùng chúng ta khám phá nội dung của nó.

1. Nền tảng của trừu tượng hóa tài khoản

1.1 Định vị trừu tượng hóa tài khoản

Nhà sáng lập Ethereum Vitalik đã cập nhật lại lộ trình phát triển ETH vào cuối năm 2023, nhưng thiết lập về trừu tượng hóa tài khoản không có thay đổi. Hiện tại, con đường phát triển chính là từ EIP-4337 vào giai đoạn tiếp theo của việc chuyển đổi EOA tự nguyện (Voluntary EOA Conversion).

1.2 Thị trường hiện tại của trừu tượng hóa tài khoản

Sau một năm rưỡi phát triển, tổng số địa chỉ EIP4337 trên các chuỗi chính chỉ có 12 triệu, trong đó số địa chỉ hoạt động trên mạng chính Ethereum chỉ có 6,764, chênh lệch xa với số lượng địa chỉ EOA và CA. Số địa chỉ độc lập trên mạng chính Ethereum đã đạt 270 triệu, có thể nói rằng EIP4337 gần như không có sự phát triển thực chất trên mạng chính.

Tuy nhiên, điều này không ảnh hưởng đến giá trị cốt lõi của AA. Thiết kế ban đầu của EIP4337 là để giải quyết vấn đề tương thích ngược của mạng chính, do đó đã đạt được sự tăng trưởng bùng nổ trên các chuỗi L2 hỗ trợ AA một cách tự nhiên. Ví dụ, số người dùng hoạt động hàng tháng của chuỗi Base và Polygon vào tháng 7 lần lượt đạt 1 triệu và 3 triệu, thể hiện hiệu suất không tệ.

Do đó, thiết kế của EIP4337 không phải là sai, nó có nhiều ưu điểm. Tình hình hiện tại chủ yếu do sự khác biệt giữa mạng chính và L2 gây ra, chúng cần áp dụng các giải pháp phù hợp với từng bên.

2. Tài khoản trừu tượng là gì?

Trừu tượng hóa tài khoản về bản chất là giải quyết vấn đề tách biệt quyền sở hữu.

Trong kiến trúc máy ảo Ethereum(EVM) có hai loại tài khoản: tài khoản bên ngoài(EOA) và tài khoản hợp đồng(Contract Account). Trong tài khoản bên ngoài, quyền sở hữu và quyền ký thực tế được giữ bởi cùng một thực thể. Người sở hữu chìa khóa riêng không chỉ sở hữu "quyền sở hữu" của tài khoản, mà còn có quyền "ký chuyển nhượng tất cả tài sản".

Đây là do cấu trúc giao dịch của tài khoản Ethereum quyết định. Từ cấu trúc giao dịch có thể thấy, giao dịch tiêu chuẩn của Ethereum thực sự không có trường From. Vậy cách nào để xác định địa chỉ chi tiêu của một giao dịch chuyển tiền? Thực tế, điều này được suy diễn ngược từ địa chỉ From thông qua tham số VRS (, tức là chữ ký của người dùng ).

Điều này liên quan đến các khái niệm như mã hóa không đối xứng ECDSA và hàm ngưỡng một chiều, mà không cần mở rộng ở đây. Tóm lại, cơ chế này đảm bảo tính an toàn thông qua mật mã, nhưng cũng dẫn đến tình trạng khó khăn trong việc hợp nhất quyền sở hữu địa chỉ EOA hiện tại.

Và vai trò cốt lõi của EIP4337 là thêm Địa chỉ Gửi vào trường giao dịch, từ đó thực hiện việc tách biệt khóa riêng và địa chỉ được thao tác.

Nguyên nhân tại sao việc phân chia quyền sở hữu lại quan trọng như vậy là do thiết kế của tài khoản bên ngoài (EOA) sẽ phát sinh nhiều vấn đề hơn:

Khó bảo vệ khóa riêng: Người dùng mất khóa riêng (, bị hacker tấn công, hoặc bị giải mã mật mã ) có nghĩa là mất tất cả tài sản.
Thuật toán ký duy nhất: Giao thức gốc chỉ có thể sử dụng thuật toán ký và xác thực ECDSA khi xác minh giao dịch.
Quyền ký quá cao: không hỗ trợ ký nhiều gốc ( ký nhiều chỉ có thể được thực hiện thông qua hợp đồng thông minh ), một chữ ký có thể thực hiện bất kỳ thao tác nào.
Phí giao dịch chỉ có thể thanh toán bằng ETH, không hỗ trợ giao dịch hàng loạt.
Rò rỉ quyền riêng tư giao dịch: Giao dịch một đối một dễ dàng làm lộ thông tin riêng tư của người sở hữu tài khoản.

Những hạn chế này khiến người dùng bình thường khó sử dụng Ethereum:

Đầu tiên, để sử dụng bất kỳ ứng dụng nào trên Ethereum, người dùng phải nắm giữ Ether ( và chịu rủi ro biến động giá của nó ).

Thứ hai, người dùng cần xử lý logic phí phức tạp, giá Gas, giới hạn Gas, tắc nghẽn giao dịch ( thứ tự Nonce ) và các khái niệm này quá phức tạp đối với người dùng.

Cuối cùng, mặc dù nhiều ví hoặc ứng dụng blockchain cố gắng nâng cao trải nghiệm người dùng thông qua tối ưu hóa sản phẩm, nhưng hiệu quả vẫn hạn chế.

Do đó, giải pháp nằm ở việc thực hiện trừu tượng hóa tài khoản, tách rời quyền sở hữu (Owner) và quyền ký (Signer), từ đó từng bước giải quyết các vấn đề nêu trên.

Trong lịch sử, đã có nhiều phương án được đề xuất, cuối cùng được tổng hợp thành hai hướng chính.

3. Sắp xếp bối cảnh các đề xuất lịch sử AA

Giải pháp cho vấn đề dường như có nhiều đề xuất EIP, nhưng cuối cùng chỉ có hai hướng đi cốt lõi. Mỗi vấn đề được xem xét bởi các EIP chưa được thông qua đều tập trung thành điểm đột phá của giải pháp hiện có.

( 3.1 Đường đi đầu tiên: Chuyển đổi địa chỉ EOA thành địa chỉ CA

Vào ngày 15 tháng 11 năm 2015, xung quanh EIP-101, Vitalik đã đề xuất một cấu trúc mới với hợp đồng như một tài khoản. Những thay đổi chính bao gồm:

Chuyển địa chỉ thành chỉ có mã và không gian lưu trữ
Thay đổi hỗ trợ phí giao dịch, cho phép thanh toán bằng token ERC20
Chuyển đổi token gốc thành token kiểu ERC20 thông qua hợp đồng được biên dịch trước, có chức năng ủy quyền khấu trừ và các chức năng khác.
Rút gọn các trường giao dịch thành to, startgas, data và code

Giải pháp này có thể nói là một cuộc cách mạng, sẽ thay đổi đáng kể thiết kế cơ bản, khiến mỗi địa chỉ tài khoản đều có "logic" "mã" riêng của mình ) đây chính là hiệu ứng mà EIP-7702 hiện tại muốn đạt được ###.

Nó còn có thể phát sinh các chức năng khác, chẳng hạn như:

Cho phép giao dịch sử dụng nhiều thuật toán mã hóa hơn, có thể được chỉ định phương pháp xác thực và ký xác nhận bởi mã nội bộ của từng địa chỉ.
Có đặc tính chống tấn công lượng tử, vì mã có thể được nâng cấp.
Để Ether có được các tính năng chức năng tương tự như hợp đồng ERC20, hiệu ứng cốt lõi là thực hiện ủy quyền tự động, không cần tiêu tốn đồng tiền gốc.
Nâng cao không gian tùy chỉnh của tài khoản, tương thích với phục hồi xã hội, hỗ trợ SBT, tìm lại khóa và các chức năng khác.

Lý do mà kế hoạch này không được tiếp tục thực hiện rất đơn giản: bước đi quá lớn. Do không xem xét kỹ các vấn đề xung đột hash giao dịch và rủi ro an ninh vào thời điểm đó, nên nó đã bị gác lại. Tuy nhiên, mỗi ý tưởng về lợi ích trong đó đã trở thành một trong những chức năng cốt lõi của EIP4337 và EIP7702 sau này.

Sau đó còn có một loạt các EIP cố gắng hoàn thiện logic này:

EIP-859: trừu tượng hóa tài khoản chuỗi chính (2018-01-30)

Cố gắng giải quyết vấn đề triển khai mã Code. Chức năng chính là: nếu hợp đồng của bên giao dịch chưa được triển khai, thì sử dụng tham số code kèm theo giao dịch để thực hiện triển khai ví hợp đồng. Ngoài ra, còn đề xuất mã opcode PAYGAS mới, ngoài việc thanh toán gas, cũng trở thành dấu phân cách giữa phần xác thực và phần thực thi trong tham số giao dịch.

Mặc dù không thể thực hiện vào thời điểm đó, nhưng điều này cũng đã trở thành một trong những logic cốt lõi của EIP7702 hiện tại. Mỗi giao dịch của EIP7702 kết hợp với cấu trúc giao dịch đặc biệt, có thể kèm theo một mã nhất định, từ đó cho phép địa chỉ EOA có khả năng hợp đồng trong giao dịch này.

EIP-7702: thiết lập mã tài khoản EOA (2024-05-07)

Đây cũng là EIP cốt lõi mà bài viết này sẽ thảo luận trong phần sau, được Vitalik công bố, như một giải pháp thay thế cho EIP-3074. Do đó, EIP-3074 đã bị loại bỏ, EIP-7702 đã được xác định sẽ được đưa vào trong hard fork sắp tới của ETH Prague/Electra(Pectra), nội dung cụ thể sẽ được trình bày ở phần dưới.

( 3.2 Lộ trình thứ hai: Để địa chỉ EOA điều khiển địa chỉ CA

EIP-3074: Thêm mã thao tác AUTH và AUTHCALL )2020-10-15###

Thêm hai mã thao tác mới AUTH và AUTHCALL vào EVM, cho phép EOA ủy quyền cho hợp đồng thay thế danh tính của EOA để gọi các hợp đồng khác thông qua hai mã thao tác này.

Nói ngắn gọn, một EOA có thể gửi một tin nhắn đã ký ( giao dịch ) đến một hợp đồng mà nó tin tưởng gọi là Invoker (, hợp đồng Invoker này có thể sử dụng mã lệnh AUTH và AUTHCALL để thay thế EOA này gửi giao dịch.

EIP-4337: Thực hiện trừu tượng hóa tài khoản bằng bộ nhớ giao dịch )2021-09-29(

Đề xuất này được thiết kế dựa trên cảm hứng từ MEV, giá trị cốt lõi của nó là hoàn toàn tránh thay đổi giao thức lớp đồng thuận.

EIP4337 đã đề xuất một đối tượng giao dịch mới là UserOperation, người dùng gửi đối tượng này vào pool bộ nhớ, và các bundlers từ góc độ thợ mỏ sẽ đóng gói hàng loạt và giao cho việc thực hiện giao dịch hợp đồng, về bản chất là kéo các giao dịch cơ sở và hoạt động tài khoản lên tầng hợp đồng để thực hiện.

EIP-5189: Thao tác tài khoản trừu tượng qua người bảo đảm )2022-06-29(

Điều này có thể được coi là một tối ưu hóa cho logic EIP4337, thông qua việc thiết lập cơ chế đảm bảo phạt tiền để ngăn chặn các cuộc tấn công DoS từ Bundler độc hại.

) 3.3 Các đề xuất khác để hỗ trợ trừu tượng hóa tài khoản

EIP-2718: bao bì loại giao dịch mới (2020-06-13)

Đây là một đề xuất đã được xác định cuối cùng, nó định nghĩa một loại giao dịch mới, như là một phong bì cho các loại giao dịch mới trong tương lai.

Hiệu ứng cuối cùng là, khi giới thiệu loại giao dịch mới, thông qua mã hóa cụ thể để phân biệt các giao dịch khác nhau, khiến nó chỉ cần có khả năng tương thích ngược, mà không cần tương thích tiến. Ví dụ phổ biến nhất là EIP1559, nó phân biệt phí giao dịch, sử dụng mã hóa loại giao dịch mới, nhưng không ảnh hưởng đến loại giao dịch legacy ban đầu.

EIP-3607: cấm địa chỉ EOA triển khai hợp đồng (2021-06-10)

Đây là giải pháp bổ sung trên đường dẫn AA, nhằm ngăn chặn vấn đề xung đột giữa địa chỉ triển khai hợp đồng và địa chỉ EOA. Nó sẽ kiểm soát phương pháp tạo ra hợp đồng, không cho phép hệ thống triển khai mã lên những địa chỉ đã là địa chỉ EOA. Rủi ro này thực sự rất nhỏ, vì địa chỉ Ethereum dài 160 bit, mặc dù có phương pháp va chạm khóa riêng để tạo ra khóa riêng cho địa chỉ hợp đồng đã chỉ định, nhưng theo ước tính sức mạnh tính toán toàn mạng Bitcoin, cũng cần khoảng một năm.

3.4 Làm thế nào để hiểu quá trình phát triển của trừu tượng hóa tài khoản?

Trước tiên, cần hiểu giá trị sau khi chuyển đổi thành CA.

Cơ bản cũng chỉ là hiệu ứng thực tế của EIP-4337, nó có thể đạt được:

Khôi phục xã hội
Giao dịch không cần gas
Giao dịch hàng loạt
Quy tắc dựa trên thời gian
Chữ ký đa
Thanh toán dựa trên quy tắc

Tuy nhiên, nhược điểm cốt lõi của EIP-4337 là vi phạm nguyên tắc động cơ con người.

Nó có vẻ tốt hơn, nhưng rơi vào một vòng lặp chết trong sự phát triển của thị trường: nhiều Dapp vẫn chưa tương thích, dẫn đến việc người dùng không muốn sử dụng địa chỉ CA. Thậm chí việc sử dụng CA sẽ phát sinh chi phí giao dịch cao hơn ( trong các tình huống chuyển khoản thông thường, phí giao dịch có thể gấp đôi ), cũng quá phụ thuộc vào khả năng tương thích của chính Dapp.

Do đó, cho đến nay vẫn chưa được phổ biến trên mạng chính của Ethereum.

Chi phí là tiêu chí quan trọng nhất của người dùng, cần phải giảm chi phí.

Nhưng để thực sự giảm GAS, cần phải thực hiện nâng cấp phân nhánh mềm trên chính Ethereum, điều chỉnh tính toán GAS hoặc tiêu thụ GAS của mã hoạt động và các mô-đun khác. Nếu đã phải phân nhánh mềm, tại sao không xem xét trực tiếp EIP-7702 nhỉ?

4. Phân tích toàn diện EIP-7702

4.1 EIP-7702 là gì

Nó phân biệt bằng cách sử dụng loại giao dịch mới, cho phép EOA tạm thời có chức năng của hợp đồng thông minh trong một giao dịch duy nhất, từ đó hỗ trợ giao dịch hàng loạt, giao dịch không Gas và quản lý quyền tùy chỉnh trong kinh doanh mà không cần phải giới thiệu mã vận hành EVM mới ( ảnh hưởng đến khả năng tương thích ngược ).

Nó cho phép người dùng có được hầu hết khả năng của AA mà không cần triển khai hợp đồng thông minh, thậm chí có thể cung cấp khả năng cho bên thứ ba thực hiện giao dịch thay cho người dùng mà không cần người dùng cung cấp khóa riêng, chỉ cần ký thông tin ủy quyền.

( 4.2 cấu trúc dữ liệu

Nó định nghĩa loại giao dịch mới 0x04, Payload Giao dịch của loại giao dịch này là kết quả tuần tự hóa RLP của nội dung sau:

rlp)[ chain_id, // ID chuỗi, dùng để ngăn chặn tấn công phát lại nonce, // bộ đếm giao dịch, đảm bảo tính duy nhất của giao dịch max_priority_fee_per_gas, // phí giao dịch 1559 max_fee_per_gas, // phí giao dịch 1559 gas_limit, đích đến, // địa chỉ giao dịch mục tiêu giá trị, dữ liệu, access_list, // danh sách truy cập, sử dụng để tối ưu hóa Gas trong EIP-2929 danh sách ủy quyền, signature_y_parity, // 3 tham số chữ ký, dùng để xác minh chữ ký giao dịch chữ ký_r, chữ ký_s ]###

Điều quan trọng là trong đó đã thêm đối tượng authorization_list, lưu trữ mã mà người ký muốn thực hiện trong EOA của mình. Người dùng ký giao dịch đồng thời cũng ký mã hợp đồng sẽ được thực hiện, nó tồn tại dưới dạng danh sách hai chiều, chỉ ra có thể

ETH1.7%

Xem bản gốc

Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.

16 thích