Ủy quyền EIP-7702 là gì? Giải thích về tài khoản thông minh EOA

Việc ủy quyền EIP-7702 cho phép một tài khoản sở hữu bên ngoài (EOA) chuyển logic thực thi của mình cho một hợp đồng khác mà không thay đổi địa chỉ hoặc từ bỏ khóa riêng. Trường mã được đặt thành 0xef0100 cộng với địa chỉ đại diện, và các lệnh gọi sau đó sẽ chạy mã này trong ngữ cảnh riêng của EOA, trong khi số dư, nonce và dữ liệu lưu trữ vẫn thuộc về tài khoản đó.

Nội dung này phù hợp với những người đã hiểu về ví tự lưu ký và mô hình tài khoản EVM. Ethereum từ lâu đã có hai loại tài khoản: EOA được kiểm soát bằng khóa và tài khoản hợp đồng có mã, trong đó chỉ loại thứ hai có thể chứa logic xác thực tùy chỉnh, nhưng phải dùng một địa chỉ mới. Tính năng này được triển khai cùng bản nâng cấp Pectra và chuyển việc xác thực tùy chỉnh từ mở một tài khoản mới sang ghi mã vào một địa chỉ đang được sử dụng.

Một bộ giá trị ủy quyền chứa sáu trường, còn mã chỉ định ủy quyền chiếm 23 byte: tiền tố ba byte cộng với địa chỉ 20 byte. Đường ghi, giới hạn của các khả năng mới, sự khác biệt với ERC-4337 và mức độ đáng tin cậy của đại diện sẽ quyết định tài khoản giữ lại được bao nhiêu quyền kiểm soát sau chữ ký đó.

Những điểm chính

• Việc ủy quyền EIP-7702 giữ nguyên địa chỉ, khóa riêng, số dư và nonce, đồng thời chỉ trỏ trường mã đến một hợp đồng đại diện.

• Giao dịch loại 0x04 ghi ủy quyền thông qua một bộ giá trị ủy quyền; thông điệp đã ký không chứa trường phí và người gửi không nhất thiết phải là chủ sở hữu.

• Việc ủy quyền không có ngày hết hạn; việc thu hồi sẽ xóa mã nhưng không xóa dữ liệu lưu trữ, quyền phê duyệt token hoặc chữ ký Permit.

• Một đại diện không có receive() hoặc fallback() sẽ khiến các giao dịch chuyển ETH thông thường bị hoàn tác, và tx.origin không còn ngụ ý rằng tài khoản không có mã.

• ERC-4337 xây dựng một hệ thống tài khoản riêng, trong khi EIP-7702 thêm mã vào các EOA hiện có, do đó hai cơ chế này có thể kết hợp với nhau.

Việc ủy quyền EIP-7702 thay đổi điều gì đối với tài khoản sở hữu bên ngoài?

Ethereum có hai loại tài khoản: tài khoản sở hữu bên ngoài, được kiểm soát bằng khóa riêng, và tài khoản hợp đồng, chứa mã.

Với EIP-7702, yếu tố thay đổi là trường mã, không phải danh tính của tài khoản, bởi vì EOA có thể tạm thời trỏ đến mã hợp đồng mà không thay đổi địa chỉ. Địa chỉ, khóa riêng, số dư và nonce vẫn giữ nguyên; điểm khác biệt là địa chỉ hiện có mã thực thi được lấy từ một hợp đồng khác đã triển khai.

Trường này chứa mã chỉ định ủy quyền 23 byte: tiền tố 0xef0100 cộng với địa chỉ 20 byte. Khi một lệnh gọi nhắm đến EOA đó, EVM sẽ đọc mã chỉ định và tải mã của đại diện, nhờ đó tài khoản có thể hoạt động như tài khoản thông minh trong khi khóa riêng vẫn kiểm soát tài khoản, còn người gửi, số dư và dữ liệu lưu trữ đều được đọc theo EOA.

Đại diện không thể truy cập trạng thái của chính nó; logic thực thi được tải từ hợp đồng đích, trong khi dữ liệu lưu trữ và ngữ cảnh người gửi vẫn là của EOA, đồng thời các thao tác ghi tuân theo cùng logic để ghi vào dữ liệu lưu trữ mà EOA chưa từng sử dụng.

Chữ ký vẫn đến từ khóa riêng ban đầu, nên tài khoản không trở thành ví đa chữ ký, và thiết kế này là một bước hướng tới trừu tượng hóa tài khoản, bao gồm cả biến thể gốc, thay vì thay đổi loại tài khoản.

Loại 0x04 và bộ giá trị ủy quyền: Cách việc ủy quyền tiếp cận mã hợp đồng

Thao tác ghi cần một loại giao dịch mới, 0x04, với phần nội dung chứa danh sách ủy quyền; mỗi bộ giá trị được chủ tài khoản ký, trong khi bản thân giao dịch có thể được gửi và thanh toán bởi bất kỳ địa chỉ nào, còn nội dung ủy quyền xác định mã nào mà tài khoản cho phép chạy.

Bộ giá trị là [chain_id, address, nonce, y_parity, r, s], và thông điệp đã ký là keccak(0x05 || rlp([chain_id, address, nonce])); đặc tả EIP-7702 sử dụng tiền tố 0x05 để tách chữ ký ủy quyền khỏi chữ ký giao dịch thông thường, và thông điệp không chứa trường gas hoặc phí.

Nội dung được ký là địa chỉ mà mã cần trỏ đến, không phải một giao dịch cụ thể, vì vậy một số hệ thống sẽ ghép nội dung ủy quyền với một ý định thay thế. Tài khoản cũng có thể ký một lần khi ngoại tuyến trong khi nhà tài trợ trả trước phí gas.

Quá trình xác thực nút chạy qua sáu bước, trong đó ràng buộc nonce khiến một nội dung ủy quyền chỉ có thể sử dụng một lần, tại nonce tương ứng.

Danh sách ủy quyền nằm trong phần nội dung giao dịch giống như cách danh sách truy cập mở rộng định dạng giao dịch: chain ID bằng 0 hoặc khớp với chuỗi cục bộ, trong đó 0 nghĩa là hợp lệ trên mọi chuỗi; nonce nhỏ hơn 2^64-1; ecrecover xác minh chữ ký; mã tài khoản trống hoặc đã được ủy quyền; nonce khớp với giá trị hiện tại; và mã được ghi thành 0xef0100 || address cùng với việc tăng nonce.

Việc thu hồi đi theo cùng quy trình với trường địa chỉ được đặt thành 0, thao tác này xóa hàm băm mã mà không tạo ra thay đổi trạng thái vĩnh viễn đối với EOA cơ sở.

Những thuộc tính tài khoản nào không thay đổi?

Bốn thuộc tính vẫn giữ nguyên và chỉ mã cùng dữ liệu lưu trữ thay đổi: mã chuyển từ 0x sang mã chỉ định, các ô dữ liệu lưu trữ chưa sử dụng bắt đầu nhận dữ liệu ghi và những giá trị đó vẫn tồn tại sau khi thu hồi. Đặc tả cũng liệt kê riêng ba bất biến on-chain không còn được duy trì, liên quan đến số dư, nonce và danh tính người gọi; phần rủi ro sẽ đề cập đến các nội dung này.

1. Địa chỉ: không thay đổi, do đó lịch sử, quyền phê duyệt token và bản ghi tên vẫn tiếp tục trỏ đến cùng một địa chỉ.

2. Khóa riêng: không thay đổi và dùng để ký giao dịch thông thường cũng như nội dung ủy quyền mới nhằm ghi đè hoặc thu hồi việc ủy quyền.

3. Số dư: không thay đổi, vì việc ủy quyền không di chuyển tài sản và tài khoản vẫn trực tiếp nắm giữ tài sản đó.

4. Nonce: tiếp tục tăng, vì nội dung ủy quyền tiêu thụ một nonce, điều này ngăn việc phát lại cùng một chữ ký.

Tài khoản đã được ủy quyền có còn nhận ETH bình thường không?

Không phải theo mặc định. Khi tài khoản chứa mã, một giao dịch chuyển ETH thông thường sẽ đi vào đường thực thi mã; nếu đại diện không triển khai receive() lẫn fallback(), giao dịch chuyển sẽ bị hoàn tác và tiền được trả lại cho người gửi.

Vấn đề này có thể xảy ra trong các luồng thanh toán phổ biến như rút tiền từ sàn giao dịch, trả lương và airdrop. Phần mềm ví thường chỉ báo lỗi, thay vì cho biết nguyên nhân là do đại diện. Trước khi ký, hãy xác nhận mục tiêu có triển khai hàm receive, hoặc định tuyến các khoản thanh toán đến qua một lệnh gọi mang calldata; phần mềm ví cũng nên hiển thị rõ nguyên nhân này hơn cho người dùng.

Hình 1. Đường ghi EIP-7702: EOA ký bộ giá trị ủy quyền, một giao dịch loại 0x04 đặt mã thành 0xef0100 cộng với địa chỉ đại diện và các lệnh gọi sau đó thực thi mã này trong ngữ cảnh của EOA.

Tài khoản đã được ủy quyền có thể làm gì? Gộp giao dịch, tài trợ gas và khôi phục

Việc ủy quyền biến EOA từ một tài khoản chỉ có thể ký giao dịch thành tài khoản hoạt động như tài khoản thông minh cho người dùng hằng ngày, với các lợi ích rõ ràng nhất ở khả năng gộp giao dịch, tài trợ gas và khôi phục dựa trên quy tắc.

Gộp giao dịch là lợi ích cụ thể nhất: việc phê duyệt và hoán đổi có thể diễn ra trong một giao dịch duy nhất; nhà tài trợ cũng có thể hỗ trợ quá trình bắt đầu sử dụng hoặc gộp giao dịch bằng cách giúp hoàn tất nhiều bước ở chế độ nền vào đúng thời điểm, nhờ đó một chữ ký duy nhất hoàn tất một lần và không có quyền phê duyệt nào bị bỏ không ở giữa.

Tài trợ gas xuất phát từ việc tách chữ ký khỏi người gửi: bên thứ ba thanh toán, tài khoản không cần ETH từ đầu và với paymaster ERC-4337, ứng dụng có thể chịu chi phí. Điều này cũng có nghĩa là một số ứng dụng có thể chi trả gas hoặc hỗ trợ quá trình bắt đầu sử dụng bằng cách xử lý ở chế độ nền, nhưng nhà phát triển nên tránh yêu cầu ủy quyền vào thời điểm người dùng chỉ đang yêu cầu một tính năng khác.

Khôi phục và khóa phiên dựa vào việc đại diện tự xác minh chữ ký, ví dụ bằng passkey, một nhóm người giám hộ hoặc hạn mức chi tiêu thay cho một khóa. Đại diện cũng có thể thực thi các chức năng dạng chính sách liên quan đến chuyển tiền hoặc sử dụng người ký.

Giới hạn ở đây rất rõ ràng: bất kỳ ai nắm giữ khóa riêng đều có thể ký một nội dung ủy quyền mới để ghi đè việc ủy quyền, do đó cơ chế khôi phục này yếu hơn tài khoản thông minh gốc và chỉ làm giảm thiệt hại do mất khóa.

Việc ủy quyền không có ngày hết hạn. Nó duy trì hiệu lực cho đến khi một nội dung ủy quyền mới ghi đè hoặc một địa chỉ 0 thu hồi nó, vì vậy quyền này tồn tại lâu dài và cần được quản lý chủ động; xét từ góc độ bảo mật, hãy xem xét phạm vi mà mã được ủy quyền có thể truy cập và kiểm soát.

Việc ủy quyền EIP-7702 khác ERC-4337 và trừu tượng hóa tài khoản như thế nào?

EIP-7702 thêm mã vào EOA hiện có, trong khi ERC-4337 xây dựng một hệ thống tài khoản riêng; với tư cách là các phương pháp bổ trợ cho trừu tượng hóa tài khoản, hai cơ chế này có thể kết hợp thay vì thay thế lẫn nhau.

ERC-4337 bắt đầu từ một hợp đồng mới triển khai, do đó tài sản và quyền phê duyệt phải được chuyển sang; 7702 bắt đầu từ địa chỉ ban đầu và thêm mã, tránh việc di chuyển bằng cách cho phép các tài khoản hiện có sử dụng hành vi của hợp đồng thông minh mà không cần triển khai một ví riêng trước.

Kết hợp với nhau, chúng cho phép một tài khoản 7702 hoạt động như một triển khai tài khoản cho ERC-4337 và nhà phát triển có thể xây dựng các luồng tương thích 4337 trên tài khoản đã được ủy quyền theo 7702. Điều này tạo lại một cuộc đua khởi tạo: trong khoảng thời gian từ khi việc ủy quyền được ghi nhận đến khi quá trình khởi tạo hoàn tất, bất kỳ ai cũng có thể gọi hàm khởi tạo và đặt chính họ làm chủ sở hữu.

Có hai cách khắc phục: initWithSig, liên kết chữ ký với các đối số khởi tạo, hoặc giới hạn việc khởi tạo cho EntryPoint.

Đại diện có đáng tin cậy không? Cách xác minh tính bất biến

Chỉ nên ủy quyền cho các hợp đồng bất biến được triển khai từ initcode CREATE2 tiêu chuẩn; cơ chế xác minh nên ưu tiên các mục tiêu không có đường nâng cấp, vì hợp đồng proxy, hợp đồng có thể nâng cấp và hợp đồng có đường self-destruct đều là các mục tiêu không phù hợp.

Việc ủy quyền trao quyền thực thi cho mã đó và chủ sở hữu không nhận được thông báo khi có thay đổi. Một mục tiêu có thể nâng cấp đồng nghĩa với việc người có quyền nâng cấp nắm quyền thực thi đối với mọi tài khoản ủy quyền cho mục tiêu đó; trong khi đó, một mục tiêu bất biến ít nhất sẽ cố định bề mặt tấn công từ trước để có thể được kiểm toán. Mức độ phơi nhiễm bảo mật tăng lên nếu mã được ủy quyền có thể thay đổi sau khi được ủy quyền.

Ba tiêu chí, gồm mã bất biến, không có proxy và triển khai có thể tái tạo, tạo thành bốn bước kiểm tra trên trình khám phá blockchain mà ví và nhà phát triển nên xác minh trước khi cấp quyền ủy quyền:

1. Đọc các ô triển khai và quản trị: một ô EIP-1967 khác 0 bắt đầu bằng 0x360894 cho thấy có proxy hoặc đường nâng cấp.

2. So sánh bytecode on-chain với mã nguồn đã xác minh, xác nhận đối số hàm khởi tạo và bytecode đã triển khai khớp nhau.

3. Tìm kiếm selfdestruct và delegatecall, xác nhận không có nhánh nào có thể xóa mã hoặc chuyển tiếp việc thực thi sang nơi khác.

4. Tính lại địa chỉ CREATE2 từ initcode và salt, xác nhận bên triển khai không thể thay thế bằng một hợp đồng khác tại địa chỉ khác.

Rủi ro của việc ủy quyền EIP-7702 là gì?

Rủi ro nằm ở ba nơi: lỗi trong đại diện, ngữ nghĩa tài khoản bị thay đổi bởi việc ủy quyền và tính không thể đảo ngược của chữ ký một lần, đây vừa là đánh đổi về bảo mật vừa là nâng cấp về chức năng; mối quan ngại chính là phạm vi rộng của mã có thể kiểm soát tài khoản sau khi quyền ủy quyền được cấp.

Hàng tx.origin có phạm vi ảnh hưởng rộng nhất. Một tài khoản được ủy quyền có thể thực thi mã trong ngăn xếp lệnh gọi, vì vậy msg.sender == tx.origin không còn đồng nghĩa người gọi không có mã, và các cơ chế bảo vệ dựa trên phép so sánh này sẽ không còn hiệu quả; các khóa nonReentrant hoặc khóa dữ liệu lưu trữ tạm thời không phụ thuộc vào danh tính người gọi.

Trên thực tế, nếu ví không hiển thị rõ chi tiết ủy quyền, người dùng có thể phê duyệt quyền truy cập mà họ không chủ định xem xét. Hướng dẫn EIP-7702 trong tài liệu Pectra liệt kê nội dung này riêng biệt.

chain_id bằng 0 mở rộng nhóm rủi ro thứ ba: cùng một chữ ký hợp lệ trên các chuỗi EVM khác, do đó một tài khoản có thể được gán mã trên một chuỗi mà người nắm giữ chưa từng cân nhắc. Thiết bị ký thường bỏ qua chain ID, đây là điểm đánh đổi của việc kích hoạt ủy quyền trên ví lạnh.

Cách kiểm tra và thu hồi một việc ủy quyền

Việc kiểm tra chỉ cần một lần đọc mã: eth_getCode trả về 0x nghĩa là không có ủy quyền, 23 byte bắt đầu bằng 0xef0100 nghĩa là tài khoản đó là tài khoản sở hữu bên ngoài đã được ủy quyền, còn bất kỳ bytecode nào khác nghĩa là đó là tài khoản hợp đồng.

Việc ủy quyền là trạng thái ở cấp độ chuỗi, do đó một địa chỉ có thể được ủy quyền trên một chuỗi nhưng không thay đổi trên chuỗi khác, và mỗi chuỗi đều cần được kiểm tra riêng; 20 byte cuối là đại diện, còn ví hoặc nền tảng có thể tự động hóa các bước kiểm tra này trên nhiều chuỗi trong khi lưu nhật ký kiểm tra hoặc thay đổi trạng thái để kiểm toán và giám sát.

Để xem xét thủ công nhanh chóng, hướng dẫn kiểm tra và thu hồi việc ủy quyền trình bày quy trình này.

Việc thu hồi diễn ra trong ví: ký một nội dung ủy quyền mới với trường địa chỉ được đặt thành 0 và nút sẽ xóa hàm băm mã, đưa tài khoản trở lại EOA thông thường; trong khi đó, các dApp bên ngoài thường không thể thực hiện thao tác này thay cho người nắm giữ, và nếu đội ngũ ví hỗ trợ quy trình thu hồi, mọi yêu cầu hành động thay mặt người nắm giữ vẫn phải cần sự phê duyệt của chính người nắm giữ.

Việc thu hồi xóa mã được ủy quyền nhưng không xóa các quyền phê duyệt hợp đồng thông minh trước đó hoặc quyền truy cập khác đã cấp cho ứng dụng, và ghi chú về ủy quyền EOA của OpenZeppelin làm rõ ranh giới này.

Tóm tắt

EIP-7702 mang lại khả năng lập trình cho EOA chỉ với một chữ ký: địa chỉ và khóa không thay đổi, trường mã trỏ đến một đại diện và quá trình thực thi chạy trong ngữ cảnh riêng của tài khoản.

Đổi lại là ngữ nghĩa thay đổi và quyền tồn tại lâu dài: các khoản thanh toán thông thường chuyển vào có thể thất bại, tx.origin không còn là EOA, chữ ký có chain_id bằng 0 có thể được sử dụng trên nhiều chuỗi và việc thu hồi chỉ xóa mã.

Câu hỏi thường gặp

EIP-7702 có biến ví của tôi thành ví đa chữ ký không?

Không. Việc ủy quyền chỉ thay đổi trường mã và chữ ký vẫn đến từ khóa riêng ban đầu, do đó người nắm giữ một khóa vẫn có thể giao dịch độc lập và có thể ghi đè việc ủy quyền bằng một nội dung ủy quyền mới. Một đại diện yêu cầu nhiều chữ ký cũng có thể bị khóa đó bỏ qua.

Làm thế nào để kiểm tra ví của tôi có được ủy quyền theo EIP-7702 không?

Gọi eth_getCode trên địa chỉ. Giá trị trả về 0x nghĩa là không có ủy quyền; 23 byte bắt đầu bằng 0xef0100 nghĩa là địa chỉ đã được ủy quyền, trong đó 20 byte cuối xác định đại diện; bytecode khác nghĩa là tài khoản hợp đồng.

Việc ủy quyền được ghi nhận theo từng chuỗi, vì vậy hãy kiểm tra từng chuỗi; ví hoặc hệ thống quản trị cũng có thể lưu nhật ký các lần kiểm tra này để xem xét. Tóm lại, câu trả lời có thể chỉ khác nhau ở chi tiết giao diện giữa các ví, nhưng việc kiểm tra mã cơ bản là như nhau.

Làm thế nào để thu hồi việc ủy quyền EIP-7702?

Ký một nội dung ủy quyền mới với trường địa chỉ được đặt thành 0 từ bên trong ví; nút sẽ xóa hàm băm mã sau khi xác thực thành công. Chỉ người nắm giữ tài khoản mới có thể ký nội dung này và các dApp bên ngoài thường không thể hành động thay mặt họ.

Việc ủy quyền có hết hạn không và các quyền phê duyệt token trước đó có còn sau khi thu hồi không?

Việc ủy quyền không có ngày hết hạn và duy trì hiệu lực cho đến khi bị ghi đè hoặc thu hồi. Việc thu hồi chỉ xóa mã, trong khi dữ liệu lưu trữ, quyền phê duyệt ERC-20 và chữ ký Permit vẫn không thay đổi.

Khóa của tôi chưa từng bị lộ, vậy một nội dung ủy quyền EIP-7702 độc hại vẫn có thể rút hết tài khoản không?

Có. Chữ ký là sự chuyển giao thẩm quyền: với chữ ký này, kẻ tấn công có thể ghi một ủy quyền trỏ đến hợp đồng độc hại và giành quyền truy cập rộng vào tài khoản, di chuyển tài sản mà không cần chạm vào khóa riêng.

Hãy kiểm tra chain ID và địa chỉ mục tiêu trong bộ giá trị, đồng thời chỉ ký cho các hợp đồng bất biến; đội ngũ ví cũng nên xác minh vai trò của người ký trước khi cấp các phê duyệt nội bộ liên quan đến việc ủy quyền thay mặt một tổ chức.