Nâng cấp Pectra Ethereum: Phân tích Độ sâu EIP-7702 và Hướng dẫn Thực hành Tốt nhất

Lời mở đầu

Ethereum sắp có bản nâng cấp Pectra, đây là một cập nhật mang ý nghĩa quan trọng, nhiều đề xuất cải tiến Ethereum quan trọng sẽ được giới thiệu. Trong số đó, EIP-7702 đã thực hiện một cải cách mang tính chuyển đổi đối với tài khoản bê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 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ớ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, 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ã giống như hợp đồng thông minh, đồng thời vẫn giữ khả năng khởi xướng giao dịch. Tính năng này mang lại cho EOA tính lập trình và khả năng kết hợp, người dùng nhờ đó có thể thực hiện các chức năng như khôi phục xã hội, quản lý quyền hạn, quản lý nhiều chữ ký, xác thực zk, thanh toán theo đăng ký, tài trợ giao dịch và xử lý giao dịch hàng loạt trong EOA. Đáng chú ý, 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, sự tích hợp liền mạch giữa hai cái này đã đơn giản hóa rất nhiều quy trình phát triển và ứng dụng của các tính năng mới.

Việc triển khai cụ thể của EIP-7702 là việc giới thiệu loại giao dịch SET_CODE_TX_TYPE (0x04), cấu trúc dữ liệu đượ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ừ trường authorization_list, các trường còn lại đều tuân theo 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 address biểu thị địa chỉ mục tiêu của ủy thác
• Trường nonce phải khớp với nonce của tài khoản được ủy quyền hiện tại.
• Trường y_parity, r, s là dữ liệu chữ ký được tài khoản ủy quyền ký.

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), tức là người khởi tạo 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

Người ủy quyền khi ký dữ liệu ủy quyền cần phải mã hóa RLP trước các giá trị chain_id, address, nonce. Sau đó, dữ liệu đã mã hóa sẽ được thực hiện phép toán băm keccak256 cùng với số MAGIC, từ đó thu đượ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 các giá trị y_parity, r, s. Trong đó, MAGIC (0x05) được sử dụng như một ký tự phân cách miền, mục đích là để đả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.

Cần lưu ý rằng, khi chain_id được ủy quyền bởi người ủy quyền là 0, thì đ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 ).

Khi người ủy quyền ký xong dữ liệu ủy quyền, người khởi tạo 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 thi trong khối, Proposer sẽ thực hiện kiểm tra trước giao dịch, trong đó có kiểm tra bắt buộc đối với đị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.

Đồng thời, 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 được ký bởi cùng một người ủy quyền, thì cuối cùng chỉ 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 xướng giao dịch trước, 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, rồi mới 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ị nonce nên được 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, nhằm đảm bảo rằng trong các tình huống ủy quyền hàng loạt sẽ không xảy ra rủi ro DoS.

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 thành 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 bằng 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 hoàn tất ủy quyền, 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.

Loại giao dịch mới được giới thiệu qua EIP-7702 cho phép người ủy quyền (EOA) vừa có thể thực thi mã như hợp đồng thông minh, vừa giữ lại khả năng khởi tạo 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 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 trường hợp ứ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 hệ sinh thái cần lưu ý 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 tiền do mất khóa riêng bằng cách sử dụng các biện 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 EOA bị lộ. Cần làm rõ rằng, sau khi thực hiện ủy quyền, khóa riêng EOA vẫn giữ 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 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í, sau khi hoàn thành ủy quyền cho EOA, ngay cả khi hoàn toàn xóa khóa riêng được lưu trữ trên máy tính, cũng không thể hoàn toàn loại trừ rủi ro lộ khóa riêng, đặc biệt 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, 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 chú ý: Not your keys, not your coins.

Đa chuỗi phát lại

Người dùng khi ký ủ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 để ủ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, để thuận tiện cho người dùng chỉ cần ký một lần là có thể ủy quyền trên nhiều chuỗi. Nhưng cần lưu ý rằng, trong cùng một địa chỉ hợp đồng ủy quyền trên nhiều chuỗi, cũng có thể tồn tại các mã triển khai khác nhau.

Đối với các 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ó tương ứng với mạng hiện tại hay 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 của chúng không phải lúc nào cũng giống nhau, nên tìm hiểu rõ về 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 sử dụng mô hình đại lý, khi triển khai ví đại lý sẽ gọi hàm khởi tạo của hợp đồng thông qua DELEGateCALL, nhằm đạt được hoạt động khởi tạo ví và triển khai ví đại lý một cách nguyên tử, 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ó thể cập nhật trường code của địa chỉ mà 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 để 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 quá trình khởi tạo ví, ví dụ như thông qua ecrecover để khôi phục địa chỉ ký để kiểm tra quyền, nhằm tránh rủi ro ví bị khởi tạo 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ể cần ủy thác lại đến địa chỉ hợp đồng khác vì các thay đổi về yêu cầu chức năng, nâng cấp ví, v.v. 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 được đề xuất bởi ERC-7201, phân bổ biến vào vị trí lưu trữ độc lập đã chỉ định, nhằm 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 dành riêng 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ữ.

( giả nạp tiền

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ẽ phải đối mặt với tình trạ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 ngăn ngừa rủi ro giả nạp từ hợp đồng thông minh.

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

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ể chuyển đổi tự do giữa EOA và SC, điều này cho phép tài khoản vừa có thể khởi tạo 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ả định rằng tx.origin luôn là EOA sẽ không còn khả thi. Tương tự, việc kiểm tra thông qua msg.sender == tx.origin để phòng ngừa tấn công tái nhập cũng sẽ không còn hiệu lực.

Các nhà phát triển trong quá trình phát triển nên giả định rằng các người tham gia 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 giao 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 gọi lại tương ứng để đảm bảo khả năng tương thích với các mã thông báo chính.

Kiểm tra câu cá

Sau khi thực hiện ủy thác 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 thác tài khoản của mình cho một hợp đồng độc hại, kẻ tấn công sẽ dễ dàng đánh cắp tiền.

Đối với các 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 đặc biệt hiển thị hợp đồng mục tiêu ủy quyền cho người dùng, 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, việc thực hiện phân tích tự động sâu hơn cho hợp đồng mục tiêu của ủy quyền tài khoản, kiểm tra mã nguồn, kiểm tra quyền và các yếu tố khác có thể giúp người dùng tránh được những rủi ro như vậy.

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 loại giao dịch mới, giúp 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. 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 kiểm 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 hành 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 khảo và áp dụng trong thực tế.