Ethereum Pectra nâng cấp: Những biến đổi và thách thức từ EIP-7702

Lời mở đầ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 đã thực hiện một cải cách mang tính cách mạng đối với tài khoản bên ngoài của 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 hóa 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 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 của 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 những lời khuyê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 hiện 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 khả năng lập trình và khả năng kết hợp cho EOA, người dùng có thể hiện thực hóa các chức năng như phục hồi xã hội, kiểm soát quyền, quản lý đa chữ ký, xác thực zk, thanh toán theo kiểu đăng ký, tài trợ giao dịch và xử lý giao dịch theo lô trong EOA. Đáng chú ý là 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 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ủ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, có thể chứa nhiều mục ủy quyền, mỗi mục ủy quyền trong đó:

• chain_id biểu thị chuỗi mà ủy quyền này có hiệu lực
• address đại diện cho đị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ý.

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, nhằm thực hiện hoạt động ủy quyền cho người ủy quyền để thanh toán gas.

thực hiện

Khi người ủy quyền ký dữ liệu ủy quyền, trước tiên cần thực hiện mã hóa RLP cho chain_id, address, nonce. Sau đó, dữ liệu đã được 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 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 bị 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 này có nghĩa là người ủy quyền cho phép tái phát 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 khớp).

Sau 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 hiện trong khối, Proposer sẽ tiến hành kiểm tra trước giao dịch, trong đó 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.

Đồng thời, loại 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 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ỉ 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ẽ tăng giá trị nonce của người khởi tạo 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, 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 đó và gặp bất kỳ lỗi nào, mục ủy quyền đó 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 không có rủi ro DoS xảy ra trong các tình huống ủy quyền hàng loạt.

Sau khi hoàn tất việc ủy quyền ứng dụng, trường code của địa chỉ người ủ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 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ỏ quyền ủy quyền, chỉ cần đặt địa chỉ mục tiêu ủy thác thành địa chỉ 0.

Bằng cách giới thiệu loại giao dịch mới qua EIP-7702, người ủy quyền (EOA) có thể thực thi mã như 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 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 những ứ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 cảnh giác trong quá trình thực hành:

lưu trữ khóa bí mật

Dù EOA có thể sử dụng các phương pháp khôi phục xã hội 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 sau khi ủy quyền, nhưng vẫn không thể tránh khỏi rủi ro khóa riêng của EOA bị rò rỉ. Cần 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, việc nắm giữ khóa riêng cho phép 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ữ tại địa phương, cũng không thể hoàn toàn loại bỏ rủi ro khóa riêng bị rò rỉ, đặc biệt là 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, 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ý kết ủy quyền có thể chọn chuỗi mà ủy quyền có hiệu lực thông qua chainId, cũng có thể chọn sử dụng chainId là 0 để ủy quyền, cho phép ủy quyền có thể được phát lại và 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 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 ủ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 các nhà cung cấp dịch vụ ví, khi người dùng thực hiện ủy quyền, cần kiểm tra xem chuỗi ủy quyền có tương thích với mạng hiện tại đ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 lưu ý rằng, trên các chuỗi khác nhau, địa chỉ hợp đồng giống 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 quyền trước.

không thể khởi tạo

Hiện tại, hầu hết các ví thông minh chính thống đều sử dụng mô hình đại lý. Khi triển khai, đại lý ví sẽ gọi hàm khởi tạo của hợp đồng thông qua DELEGateCALL để thực hiện thao tác khởi tạo ví và triển khai ví đại lý trong một giao dị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ó trường code của địa chỉ của họ được cập nhật, 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 giống như 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 thực hiện kiểm tra quyền trong quá trình khởi tạo ví (ví dụ như kiểm tra quyền 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ể do sự thay đổi nhu cầu chức năng, nâng cấp ví, v.v., họ 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, 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 gây ra việc hợp đồng mới vô tình sử dụng dữ liệu của hợp đồng cũ, từ đó dẫn đến việc tài khoản bị khóa, mất mát tài sản và các hậu quả tiêu cực khác.

Đối với người dùng, cần xử lý cẩn thận 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, nên tuân theo Công thức Namespace được đề xuất bởi ERC-7201, phân bổ các biến vào các 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 ủy quyền lại dành cho EIP-7702: bao gồm việc sử dụng ERC-7201 để ngăn ngừa xung đột lưu trữ, xác thực tính tương thích lưu trữ trước khi ủy quyền lại, và 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

Sau khi người dùng thực hiện ủ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 một số sàn giao dịch có thể sẽ phải đố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.

Sàn giao dịch 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 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ể bị gọi. Điều này có nghĩa là khi tài khoản tự 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ỉ cho phép EOA tham gia vào các 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 nữa. Tương tự, việc kiểm tra thông qua 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 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 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 do người dùng ủy thác nên triển khai các hàm callback tương ứng để đảm bảo khả năng 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 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 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 các nhà cung cấp dịch vụ ví, việc hỗ trợ các giao dịch loại EIP-7702 càng sớm càng tốt là đặc biệt quan trọng, và khi người dùng thực hiện chữ ký ủy quyền, cần nhấn mạnh cho người dùng thấy hợp đồng mục tiêu của ủy quyền để giảm thiểu rủi ro mà người dùng có thể gặp phải trong 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 về hợp đồng mục tiêu ủy thác tài khoản (kiểm tra mã nguồn, kiểm tra quyền truy cập, 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 việc thảo luận về đề 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à 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ế, 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, sàn giao dịch, 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 đượ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 quá trình thực hiện.