Ethereum Pectra nâng cấp EIP-7702: Cách mạng lớn cho EOA

Lời nói đầu

Ethereum sắp chào đón nâng cấp Pectra, đây là một bản cập nhật có ý nghĩa lớn. Trong đó, EIP-7702 đã có những cải cách mang tính cách mạng đối với tài khoản ngoài Ethereum (EOA). Đề xuất này đã làm mờ ranh giới giữa EOA và tài khoản hợp đồng CA, là một bước quan trọng tiến tới trừu tượng tài khoản nguyên bản sau EIP-4337, mang đến một mô hình tương tác hoàn toàn mới cho hệ sinh thái Ethereum.

Pectra đã hoàn thành việc triển khai trên mạng thử nghiệm, dự kiến sẽ sớm ra mắt trên mạng chính. Bài viết này sẽ phân tích sâu về cơ chế thực hiện của EIP-7702, thảo luận về những cơ hội và thách thức mà nó có thể mang lại, và cung cấp hướng dẫn thực tế cho các bên tham gia khác nhau.

Phân tích giao thức

Tóm tắt

EIP-7702 đã giới thiệu một loại giao dịch hoàn toàn mới, cho phép EOA chỉ định một địa chỉ hợp đồng thông minh, từ đó thiết lập mã cho nó. Như vậy, EOA có thể thực thi mã như một hợp đồng thông minh, đồng thời vẫn giữ được khả năng khởi xướng giao dịch. Tính năng này mang lại cho EOA khả năng lập trình và kết hợp, người dùng có thể thực hiện các chức năng như phục hồi xã hội, kiểm soát quyền hạn, quản lý ký quỹ đa chữ ký, xác thực zk, thanh toán theo hình thức đăng ký, tài trợ giao dịch và xử lý giao dịch theo lô. Đáng chú ý, EIP-7702 có khả năng tương thích hoàn hảo với ví hợp đồng thông minh được thực hiện bởi EIP-4337, sự tích hợp liền mạch giữa hai bên đã đơn giản hóa đáng kể quá trình phát triển và ứng dụng của các tính năng mới.

Cụ thể việc thực hiện EIP-7702 là việc giới thiệu loại giao dịch là SET_CODE_TX_TYPE (0x04), cấu trúc dữ liệu của nó được định nghĩa như sau:

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])

Trong đó, trường authorization_list được định nghĩa là:

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

Trong cấu trúc giao dịch mới, ngoài trường authorization_list, các trường còn lại tuân theo ngữ nghĩa giống như EIP-4844. Trường này là loại danh sách, trong danh sách có thể chứa nhiều mục ủy quyền, trong mỗi mục ủy quyền:

• Trường chain_id cho biết chuỗi mà ủy quyền này có hiệu lực.
• trường địa chỉ biểu thị địa chỉ mục tiêu được ủy quyền
• trường nonce cần phải khớp với nonce của tài khoản được ủy quyền hiện tại
• Các trường y_parity, r, s là dữ liệu chữ ký được ký bởi tài khoản được ủy quyền.

Trong trường hợp giao dịch, trường authorization_list có thể chứa nhiều mục ủy quyền khác nhau được ký bởi các tài khoản ủy quyền khác nhau (EOA), tức là người khởi xướng giao dịch có thể khác với người ủy quyền, nhằm thực hiện việc thanh toán gas cho các hoạt động ủy quyền.

hiện thực hóa

Người ủy quyền khi ký dữ liệu ủy quyền cần phải mã hóa RLP trước chain_id, address, nonce. Sau đó, dữ liệu đã mã hóa sẽ được kết hợp với MAGIC để thực hiện phép toán băm keccak256, từ đó nhận được dữ liệu cần ký. Cuối cùng, sử dụng khóa riêng của người ủy quyền để ký dữ liệu đã băm, từ đó thu được dữ liệu y_parity, r, s. Trong đó, MAGIC (0x05) được sử dụng như một dấu phân cách miền, với mục đích đảm bảo rằng kết quả của những chữ ký khác nhau sẽ không xung đột.

Cần lưu ý rằng, khi chain_id mà người ủy quyền cấp phép là 0, điều đó có nghĩa là người ủy quyền cho phép phát lại ủy quyền trên tất cả các chuỗi tương thích EVM hỗ trợ EIP-7702 (miễn là nonce cũng trùng khớp).

Khi người ủy quyền ký xong dữ liệu ủy quyền, người khởi xướng giao dịch sẽ tập hợp chúng trong trường authorization_list để ký và phát sóng giao dịch thông qua RPC. Trước khi giao dịch được thực hiện trong khối, Proposer sẽ tiến hành kiểm tra trước giao dịch, trong đó có việc kiểm tra bắt buộc địa chỉ to để đảm bảo giao dịch này không phải là giao dịch tạo hợp đồng, tức là khi gửi giao dịch loại EIP-7702, địa chỉ to của giao dịch không được để trống.

Trong khi đó, loại giao dịch này sẽ yêu cầu trường authorization_list trong giao dịch phải chứa ít nhất một mục ủy quyền, nếu có nhiều mục ủy quyền đều được ký bởi cùng một ủy quyền, thì cuối cùng chỉ có mục ủy quyền cuối cùng có hiệu lực.

Sau đó, trong quá trình thực hiện giao dịch, nút sẽ tăng giá trị nonce của người khởi tạo giao dịch trước, rồi tiến hành thao tác applyAuthorization cho từng mục ủy quyền trong authorization_list. Trong thao tác applyAuthorization, nút sẽ kiểm tra nonce của người ủy quyền trước, sau đó tăng nonce của người ủy quyền. Điều này có nghĩa là nếu người khởi tạo giao dịch và người ủy quyền là cùng một người dùng (EOA), thì khi ký giao dịch ủy quyền, giá trị nonce nên được tăng thêm 1.

Khi một nút áp dụng một mục ủy quyền nào đó, nếu gặp bất kỳ lỗi nào, mục ủy quyền này sẽ bị bỏ qua, giao dịch sẽ không thất bại, các mục ủy quyền khác sẽ tiếp tục được áp dụng, nhằm đảm bảo không xảy ra rủi ro DoS trong các tình huống ủy quyền hàng loạt.

Sau khi ứng dụng được ủy quyền hoàn tất, trường code của địa chỉ ủy quyền sẽ được thiết lập là 0xef0100 || address, trong đó 0xef0100 là định danh cố định, và address là địa chỉ mục tiêu được ủy thác. Do hạn chế của EIP-3541, người dùng không thể triển khai mã hợp đồng bắt đầu bằng byte 0xef theo cách thông thường, điều này đảm bảo rằng các định danh như vậy chỉ có thể được triển khai bởi giao dịch loại SET_CODE_TX_TYPE (0x04).

Sau khi ủy quyền hoàn tất, nếu người ủy quyền muốn gỡ bỏ ủy quyền, chỉ cần đặt địa chỉ mục tiêu ủy thác thành địa chỉ 0.

Thông qua loại giao dịch mới được giới thiệu bởi EIP-7702, cho phép người ủy quyền (EOA) vừa có thể thực thi mã như một hợp đồng thông minh, đồng thời vẫn duy trì khả năng khởi xướng giao dịch. So với EIP-4337, điều này mang đến cho người dùng trải nghiệm gần gũi hơn với trừu tượng tài khoản gốc (Native AA), giảm đáng kể rào cản sử dụng cho người dùng.

Thực hành tốt nhất

Mặc dù EIP-7702 đã mang lại sức sống mới cho hệ sinh thái Ethereum, nhưng các ứng dụng mới cũng sẽ mang đến những rủi ro mới. Dưới đây là những khía cạnh mà các bên tham gia trong hệ sinh thái cần cảnh giác trong quá trình thực hành:

lưu trữ khóa riêng

Dù EOA có thể giải quyết vấn đề mất mát tài sản do mất khóa riêng bằng các phương pháp phục hồi xã hội tích hợp trong hợp đồng thông minh sau khi ủy quyền, nhưng nó vẫn không thể tránh khỏi rủi ro khóa riêng của EOA bị lộ. Cần phải làm rõ rằng, sau khi thực hiện ủy quyền, khóa riêng của EOA vẫn giữ quyền kiểm soát cao nhất đối với tài khoản, người nắm giữ khóa riêng có thể tự do xử lý tài sản trong tài khoản. Người dùng hoặc nhà cung cấp dịch vụ ví, ngay cả khi đã hoàn toàn xóa khóa riêng lưu trữ tại địa phương sau khi hoàn thành ủy quyền cho EOA, cũng không thể hoàn toàn loại bỏ rủi ro lộ khóa riêng, đặc biệt là trong các tình huống có nguy cơ tấn công chuỗi cung ứng.

Đối với người dùng, khi sử dụng tài khoản đã ủy thác, người dùng vẫn nên đặt việc bảo vệ khóa riêng lên hàng đầu, luôn nhớ: Not your keys, not your coins.

Đa chuỗi phát lại

Người dùng khi ký kết ủy quyền có thể chọn chuỗi mà ủy quyền có thể có hiệu lực thông qua chainId, tất nhiên người dùng cũng có thể chọn sử dụng chainId là 0 để thực hiện ủy quyền, điều này cho phép ủy quyền có thể được phát lại hiệu lực trên nhiều chuỗi, nhằm thuận tiện cho người dùng chỉ cần một chữ ký là có thể ủy quyền trên nhiều chuỗi. Tuy nhiên, cần lưu ý rằng, trong cùng một địa chỉ hợp đồng trên nhiều chuỗi, cũng có thể tồn tại các mã thực hiện khác nhau.

Đối với nhà cung cấp dịch vụ ví, khi người dùng thực hiện ủy thác, cần kiểm tra xem chuỗi ủy thác có phù hợp với mạng hiện tại không, và nhắc nhở người dùng về những rủi ro có thể xảy ra khi ký ủy thác có chainId là 0.

Người dùng cũng nên chú ý rằng, địa chỉ hợp đồng tương tự trên các chuỗi khác nhau không phải lúc nào cũng có mã hợp đồng giống nhau, nên cần hiểu rõ mục tiêu ủy thác.

không thể khởi tạo

Các ví thông minh chủ yếu hiện nay hầu hết đều áp dụng mô hình đại lý, khi triển khai ví đại lý, nó sẽ gọi hàm khởi tạo của hợp đồng thông qua DELEGateCALL, từ đó đạt được thao tác nguyên tử hóa giữa việc khởi tạo ví và triển khai ví đại lý, tránh vấn đề bị khởi tạo trước. Tuy nhiên, khi người dùng sử dụng EIP-7702 để ủy quyền, chỉ cập nhật trường code của địa chỉ đó, không thể khởi tạo thông qua việc gọi địa chỉ ủy quyền. Điều này khiến EIP-7702 không thể gọi hàm khởi tạo để khởi tạo ví trong giao dịch triển khai hợp đồng như các hợp đồng đại lý ERC-1967 thông thường.

Đối với các nhà phát triển, khi kết hợp EIP-7702 với ví EIP-4337 hiện có, cần lưu ý thực hiện kiểm tra quyền trong các thao tác khởi tạo ví (chẳng hạn như kiểm tra quyền thông qua việc phục hồi địa chỉ ký bằng ecrecover) để tránh rủi ro thao tác khởi tạo ví bị chạy trước.

Quản lý lưu trữ

Người dùng khi sử dụng chức năng ủy thác EIP-7702, có thể vì sự thay đổi nhu cầu chức năng, nâng cấp ví mà cần ủy thác lại đến địa chỉ hợp đồng khác. Nhưng cấu trúc lưu trữ của các hợp đồng khác nhau có thể có sự khác biệt (chẳng hạn như slot0 của các hợp đồng khác nhau có thể đại diện cho các loại dữ liệu khác nhau), trong trường hợp ủy thác lại, có khả năng dẫn đến việc hợp đồng mới vô tình tái sử dụng dữ liệu của hợp đồng cũ, từ đó gây ra các hậu quả xấu như khóa tài khoản, mất tiền.

Đối với người dùng, nên cẩn thận xử lý tình huống ủy thác lại.

Đối với các nhà phát triển, trong quá trình phát triển, cần tuân theo Công thức Namespace do ERC-7201 đề xuất, phân bổ các biến vào vị trí lưu trữ độc lập đã chỉ định, để giảm thiểu rủi ro xung đột lưu trữ. Ngoài ra, ERC-7779 (draft) còn cung cấp quy trình tiêu chuẩn ủy quyền lại cho EIP-7702: bao gồm việc sử dụng ERC-7201 để ngăn chặn xung đột lưu trữ, và xác minh tính tương thích lưu trữ trước khi ủy quyền lại, cũng như gọi giao diện ủy quyền cũ để dọn dẹp dữ liệu cũ trong lưu trữ.

nạp giả

Người dùng sau khi ủy thác, EOA cũng sẽ có thể được sử dụng như một hợp đồng thông minh, vì vậy sàn giao dịch tập trung (CEX) có thể sẽ đối mặt với tình huống phổ biến hóa việc nạp tiền bằng hợp đồng thông minh.

CEX nên kiểm tra trạng thái của mỗi giao dịch nạp tiền thông qua trace, nhằm phòng ngừa rủi ro nạp tiền giả từ hợp đồng thông minh.

chuyển đổi tài khoản

Sau khi thực hiện ủy quyền EIP-7702, loại tài khoản của người dùng có thể tự do chuyển đổi giữa EOA và SC, điều này cho phép tài khoản vừa có thể khởi xướng giao dịch, vừa có thể được gọi. Điều này có nghĩa là khi tài khoản tự gọi và thực hiện một cuộc gọi bên ngoài, msg.sender của nó cũng sẽ là tx.origin, điều này sẽ phá vỡ một số giả định an ninh chỉ cho phép EOA tham gia vào dự án.

Đối với các nhà phát triển hợp đồng, giả sử tx.origin luôn là EOA sẽ không còn khả thi nữa. Tương tự, kiểm tra bằng msg.sender == tx.origin để phòng chống tấn công tái nhập cũng sẽ không hiệu quả.

Các nhà phát triển trong quá trình phát triển nên giả định rằng các tham gia viên trong tương lai có thể đều là hợp đồng thông minh.

Tính tương thích hợp đồng

Các token ERC-721 và ERC-777 hiện có đều có chức năng Hook khi thực hiện chuyển nhượng hợp đồng, điều này có nghĩa là người nhận phải triển khai hàm callback tương ứng để nhận token thành công.

Đối với các nhà phát triển, các hợp đồng mục tiêu được ủy quyền bởi người dùng nên thực hiện các hàm gọi lại tương ứng, để đảm bảo khả năng tương thích với các đồng tiền chính.

Kiểm tra câu cá

Sau khi thực hiện ủy quyền EIP-7702, tài sản trong tài khoản người dùng có thể sẽ được kiểm soát bởi hợp đồng thông minh, một khi người dùng ủy quyền tài khoản của mình cho hợp đồng độc hại, thì kẻ tấn công sẽ dễ dàng đánh cắp tài sản.

Đối với nhà cung cấp dịch vụ ví, việc nhanh chóng hỗ trợ giao dịch loại EIP-7702 là vô cùng quan trọng, và khi người dùng thực hiện ký ủy quyền, nên nhấn mạnh hiển thị hợp đồng mục tiêu ủy quyền cho người dùng, để giảm thiểu rủi ro mà người dùng có thể gặp phải từ các cuộc tấn công lừa đảo.

Ngoài ra, việc phân tích tự động sâu hơn các hợp đồng mục tiêu được ủy quyền cho tài khoản (kiểm tra mã nguồn mở, kiểm tra quyền hạn, v.v.) có thể giúp người dùng tránh được những rủi ro như vậy.

Tóm tắt

EIP-7702 thông qua việc giới thiệu loại giao dịch mới, làm cho EOA có khả năng lập trình và khả năng kết hợp, làm mờ ranh giới giữa EOA và tài khoản hợp đồng. Do hiện tại chưa có một tiêu chuẩn hợp đồng thông minh tương thích với loại EIP-7702 đã được thử nghiệm thực tế, do đó trong ứng dụng thực tế, các bên tham gia trong hệ sinh thái khác nhau, như người dùng, nhà cung cấp dịch vụ ví, nhà phát triển, CEX, v.v., đều phải đối mặt với nhiều thách thức và cơ hội. Nội dung thực tiễn tốt nhất được trình bày trong bài viết này không thể bao quát tất cả các rủi ro tiềm ẩn, nhưng vẫn đáng để các bên tham gia tham khảo và áp dụng trong thực tế.