Nâng cấp Pectra của Ethereum và EIP-7702: Một bước quan trọng trong việc làm mờ ranh giới giữa tài khoản EOA và tài khoản hợp đồng

Lời nói đầu

Ethereum sắp đón nhận bản nâng cấp Pectra, đây là một cập nhật có ý nghĩa quan trọng, nhiều đề xuất cải tiến Ethereum quan trọng sẽ được giới thiệu. Trong đó, EIP-7702 đã tiến hành 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 tiến quan trọng hướng tới trừu tượng tài khoản gốc 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 EIP-7702, khám phá những cơ hội và thách thức mà nó có thể mang lại, đồng thời 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ổng quan

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

EIP-7702 đã 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])

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 đều tuân theo nghĩa tương tự như EIP-4844. Trường này là loại danh sách, có thể chứa nhiều mục ủy quyền, mỗi mục ủy quyền bao gồm:

• chain_id: chuỗi mà ủy quyền này có hiệu lực
• địa chỉ: địa chỉ mục tiêu được ủy thác
• nonce: cần phải khớp với nonce của tài khoản được ủy quyền hiện tại
• y_parity, r, s: tài khoản được ủy quyền ký dữ liệu chữ ký được ủy quyền

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

thực hiện

Khi người ủy quyền ký dữ liệu ủy quyền, cần phải mã hóa RLP trước chain_id, address, nonce. Sau đó, thực hiện phép toán băm keccak256 trên dữ liệu đã được mã hóa cùng với số MAGIC, để có đượ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, thu được dữ liệu y_parity, r, s. MAGIC (0x05) được sử dụng làm dấu phân cách miền, đảm bảo rằng kết quả của các loại chữ ký khác nhau sẽ không xảy ra xung đột.

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 việc 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 với điều kiện nonce cũng phải khớp với ).

Sau 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 qua RPC. Trước khi giao dịch được thực hiện trong khối, Proposer sẽ thực hiện kiểm tra trước giao dịch, kiểm tra bắt buộc địa chỉ to để đảm bảo rằng giao dịch này không phải là giao dịch tạo hợp đồng, nghĩa 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 cùng một lúc, các giao dịch như vậy yêu cầu trường authorization_list 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.

Trong quá trình thực hiện giao dịch, nút sẽ đầu tiên tăng giá trị nonce của người khởi xướng giao dịch, sau đó thực hiện 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 xướng 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ị của nonce nên tăng thêm 1.

Khi 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, từ đó đảm bảo rằng trong các tình huống ủy quyền hàng loạt sẽ không xuất hiện rủi ro DoS.

Sau khi hoàn tất việc cấp quyền ứng dụng, trường code của địa chỉ người cấp quyền sẽ được thiết lập là 0xef0100 || address, trong đó 0xef0100 là định danh cố định, address là địa chỉ mục tiêu được ủy quyền. 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 loại định danh này chỉ có thể được triển khai thông qua giao dịch thuộc 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 quyền thành địa chỉ 0.

Thông qua loại giao dịch mới được giới thiệu bởi EIP-7702, người ủy quyền (EOA) có thể thực thi mã như một hợp đồng thông minh, đồng thời vẫn giữ khả năng khởi xướng giao dịch. So với EIP-4337, điều này mang lại cho người dùng trải nghiệm gần hơn với tài khoản trừu tượng 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 trường hợp ứng dụng mới cũng sẽ mang lại những rủi ro mới. Dưới đây là những khía cạnh mà các thành viên 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

Mặc dù EOA có thể sử dụng các biện pháp như phục hồi xã hội được tích hợp trong hợp đồng thông minh để giải quyết vấn đề mất mát tài sản do mất khóa riêng, nhưng vẫn không thể tránh khỏi rủi ro bị lộ khóa riêng của EOA. 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 nắm quyền kiểm soát cao nhất đối với tài khoản, việc nắm giữ khóa riêng cho phép tùy ý 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í, sau khi hoàn thành ủy quyền cho EOA, ngay cả khi hoàn toàn xóa khóa riêng lưu trữ trên máy tính cá nhân, 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 sau khi ủy thác, vẫn nên đặt việc bảo vệ khóa riêng lên hàng đầu, luôn chú ý: Not your keys, not your coins.

đa chuỗi phát lại

Người dùng có thể chọn chuỗi mà ủy quyền có thể có hiệu lực thông qua chainId khi ký ủy quyền. Họ cũng có thể chọn sử dụng chainId bằng 0 để ủy quyền, điều này cho phép ủy quyền có thể được phát lại có hiệu lực trên nhiều chuỗi, giúp người dùng chỉ cần ký một lần để ủ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 được ủy quyền 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 có hiệu lực ủ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 lưu ý rằng, địa chỉ hợp đồng giống nhau trên các chuỗi khác nhau, mã hợp đồng không phải lúc nào cũng giống nhau, nên cần hiểu rõ mục tiêu ủy thác trước.

không thể khởi tạo

Các ví hợp đồng thông minh phổ biến hiện nay chủ yếu áp dụng mô hình đại lý, ví đại lý trong quá trình triển khai sẽ gọi hàm khởi tạo của hợp đồng thông qua DELEGateCALL, để đạt được hoạt động khởi tạo ví và triển khai ví đại lý một cách nguyên tử, nhằm 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ó trường code của địa chỉ của họ được cập nhật, 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 cho EIP-7702 không thể gọi hàm khởi tạo 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 chú ý thực hiện kiểm tra quyền trong quá trình khởi tạo ví, chẳng hạn như thông qua ecrecover để khôi phục địa chỉ ký, nhằm tránh rủi ro bị chạy trước trong quá trình khởi tạo ví.

( Quản lý lưu trữ

Khi người dùng sử dụng chức năng ủy thác EIP-7702, có thể gặp phải việc cần ủy thác lại đến địa chỉ hợp đồng khác do thay đổi nhu cầu chức năng, nâng cấp ví, v.v. Tuy nhiên, 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 hợp đồng mới sẽ 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ả không mong muốn như khóa tài khoản, mất tiền.

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

Đối với các nhà phát triển, trong quá trình phát triển, nên tuân thủ Công thức Namespace được đưa ra bởi ERC-7201, phân bổ các biến vào vị trí lưu trữ độc lập được 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 cho việc ủy quyền lại đặc biệt cho EIP-7702: bao gồm việc sử dụng ERC-7201 để ngăn ngừa 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 tiền 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, do đó sàn giao dịch )CEX### có thể phải đối mặt với tình huống phổ biến hóa nạp tiền hợp đồng thông minh.

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

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

Sau khi thực hiện ủy thác 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ể bị gọi. Điều này có nghĩa là khi tài khoản gọi chính nó và thực hiện các 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 toàn chỉ cho phép EOA tham gia 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. Tương tự, việc kiểm tra msg.sender == tx.origin để phòng chống tấn công tái nhập cũng sẽ không còn hiệu quả.

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

) 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, hợp đồng mục tiêu mà người dùng ủy thác nên thực hiện các hàm callback tương ứng để đảm bảo có thể tương thích với các token 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 của 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, kẻ tấn công sẽ dễ dàng đánh cắp tiền.

Đối với nhà cung cấp dịch vụ ví, việc hỗ trợ nhanh chóng các 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 cho người dùng hợp đồng mục tiêu của ủy quyền, nhằm giảm thiểu rủi ro mà người dùng có thể bị tấn công lừa đảo.

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

Tóm tắt

Bài viết này xoay quanh đề xuất EIP-7702 trong bản nâng cấp Pectra sắp tới của Ethereum. EIP-7702 thông qua việc giới thiệu các loại giao dịch mới, giúp EOA có khả năng lập trình và kết hợp, làm mờ ranh giới giữa EOA và tài khoản hợp đồng. Hiện tại, vì 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 kiểm nghiệm thực tế, nên 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 về các thực tiễn tốt nhất mà bài viết trình bày không thể bao quát hết tất cả các rủi ro tiềm ẩn, nhưng vẫn đáng để các bên tham khảo và áp dụng trong quá trình thực hiện.