Cập nhật Ethereum Pectra: Phân tích sâu EIP-7702 và hướng dẫn thực hành tốt nhất

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. Trong đó, EIP-7702 đã có những cải cách mang tính cách mạng đố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 hướng tới trừu tượng hóa tài khoản gốc, 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 và 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óm tắt

EIP-7702 đã giới thiệu một loại giao dịch mới, cho phép EOA chỉ định đị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 thi mã như một hợp đồng thông minh, trong khi vẫn giữ 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à khả năng 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, quản lý ký nhiều, 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 do EIP-4337 thực hiện, đơn giản hóa quá trình phát triển và ứng dụng các tính 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 đị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. authorization_list là kiểu danh sách, có thể chứa nhiều mục ủy quyền. Trong mỗi mục ủy quyền:

• chain_id biểu thị chuỗi mà ủy quyền có hiệu lực
• address biểu thị địa chỉ mục tiêu của ủ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 là dữ liệu chữ ký được tài khoản ủy quyền ký.

Danh sách ủy quyền của một giao dịch có thể chứa nhiều tài khoản ủy quyền khác nhau. Các mục ủy quyền do ( EOA ký, thực hiện việc thanh toán gas cho các thao tác ủ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 chain_id, address, nonce trước. Sau đó, dữ liệu đã mã hóa sẽ được sử dụng cùng với MAGIC để thực hiện phép toán băm keccak256, nhận được dữ liệu chờ 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 như một ký tự 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 bị xung đột.

Khi chain_id được ủy quyền 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 (với điều kiện là nonce cũng phải khớp).

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 thực hiện giao dịch, Proposer sẽ thực hiện kiểm tra trước, đảm bảo rằng 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.

Giao dịch nà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 nhiều mục ủy quyền được ký bởi cùng một ủy quyền, cuối cùng chỉ mục ủy quyền cuối cùng có hiệu lực.

Khi thực hiện giao dịch, nút sẽ tăng giá trị nonce của người phát độ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, sau đó tăng nonce của người ủy quyền. Điều này có nghĩa là nếu người phát độ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 áp dụng mục ủy quyền cho nút, nếu gặp bất kỳ lỗi nào, mục đó 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 tránh rủi ro DoS trong kịch bản ủy quyền hàng loạt.

Sau khi ứng dụng được ủy quyền, 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 thác. Hạn chế của EIP-3541 đả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 thiết lập đị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, người ủy quyền )EOA( có thể thực thi mã như hợp đồng thông minh và vẫn giữ 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.

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

EIP-7702 đã mang lại sức sống mới cho hệ sinh thái Ethereum, đồng thời, các ứng dụng mới cũng 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 lưu ý trong quá trình thực hành:

) Lưu trữ khóa riêng

Mặc dù sau khi ủy thác EOA có thể giải quyết vấn đề mất tiền do mất khóa riêng bằng các phương pháp như phục hồi xã hội tích hợp trong hợp đồng thông minh, nhưng vẫn không thể tránh khỏi rủi ro khóa riêng EOA bị rò rỉ. Sau khi thực hiện ủy thác, khóa riêng EOA vẫn nắm giữ quyền kiểm soát cao nhất đối với tài khoản, việc sở hữu khóa riêng có thể dễ dàng 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 thác cho EOA, ngay cả khi hoàn toàn xóa khóa riêng được lưu trữ trên thiết bị cục bộ, cũng không thể hoàn toàn loại bỏ rủi ro rò rỉ khóa riêng, đặc biệt trong các tình huống có rủi ro 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

Khi người dùng ký ủy quyền, họ có thể chọn chuỗi mà ủy quyền có hiệu lực thông qua chainId, hoặc có thể chọn chainId là 0 để ủy quyền, giúp ủy quyền 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 để ủ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 trên nhiều chuỗi, có thể tồn tại mã thực hiện khác nhau.

Các nhà cung cấp dịch vụ ví khi người dùng thực hiện ủy quyền, nên kiểm tra xem chuỗi hiệu lực ủy quyền có phù hợp với mạng đang kết nố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 quyền có chainId là 0.

Người dùng cũng nên chú ý rằng, địa chỉ hợp đồng giống nhau 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 trước.

không thể khởi tạo

Các ví hợp đồng thông minh chính thống hiện nay thường sử dụng mô hình đại lý, trong đó đại lý ví khi triển khai sẽ gọi hàm khởi tạo của hợp đồng thông qua DELEGateCALL, đạt được thao tác nguyên tử giữa việc khởi tạo ví và triển khai ví đại lý, tránh được 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 giống như các hợp đồng đại lý ERC-1967 thông thường.

Khi các nhà phát triển kết hợp EIP-7702 với ví EIP-4337 hiện có, họ nên thực hiện kiểm tra quyền truy cập trong quá trình khởi tạo ví (chẳng hạn như kiểm tra quyền truy cập bằng cách khôi phục địa chỉ chữ ký thông qua ecrecover) để tránh rủi ro ví bị khởi tạo trước.

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ể vì thay đổi nhu cầu chức năng, nâng cấp ví và các lý do khác, cần ủy thác lại đến địa chỉ hợp đồng khác. 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), việc ủy thác lại có thể 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ũ, gây ra khóa tài khoản, mất tiền và các hậu quả xấu khác.

Người dùng nên xử lý cẩn thận các trường hợp ủy thác lại.

Các nhà phát triển trong quá trình phát triển nên tuân theo Công thức Namespace được đề xuất trong ERC-7201, 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ũng cung cấp quy trình tiêu chuẩn cho việc ủy quyền lại dành riêng 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 của 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, do đó sàn giao dịch tập trung ###CEX( có thể đố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 từng giao dịch nạp tiền thông qua trace, nhằm phòng ngừa rủi ro giả nạp liên quan đến 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 người dùng có thể chuyển đổi tự do giữa EOA và SC, tài khoản có thể khởi xướng giao dịch và cũng 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 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ỉ dành cho EOA tham gia vào dự án.

Các nhà phát triển hợp đồng không nên giả định rằng tx.origin luôn là EOA. Tương tự, việc kiểm tra 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 quả.

Các nhà phát triển nên giả định rằng những 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 khoản 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.

Các nhà phát triển nên đảm bảo rằng hợp đồng mục tiêu được người dùng ủy thác thực hiện các hàm gọi lại tương ứng để đảm bảo tính 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 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.

Các nhà cung cấp dịch vụ ví nên nhanh chóng hỗ trợ loại giao dịch EIP-7702, và khi người dùng thực hiện chữ ký ủy quyền, cần nhấn mạnh hiển thị hợp đồng mục tiêu mà người dùng ủy quyền, nhằm 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 đối với hợp đồng mục tiêu ủy thác 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ố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 loại giao dịch mới, giúp EOA có khả năng lập trình và tính 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ó 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ế, nên trong ứng dụng thực tiễn, các bên tham gia 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ề thực tiễn tốt nhất mà bài viết này trình bày không thể bao quát tất cả các rủi ro tiềm ẩn, nhưng vẫn rất đáng để các bên tham khảo áp dụng trong thực tế.