Ethereum sắp đón chào bản nâng cấp Pectra, đây là một cập nhật có ý nghĩa quan trọng, sẽ giới thiệu nhiều đề xuất cải tiến quan trọng. Trong đó, EIP-7702 đã thực hiện một cuộc cách mạng hóa đố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 hóa tài khoản bản địa 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 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 hành 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 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 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 hạn, quản lý đa chữ ký, xác minh 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, 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á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:
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 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 bao gồm:
chain_id biểu thị chuỗi mà ủy quyền này có hiệu lực
address biểu thị địa chỉ mục tiêu của ủy quyền
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), nghĩa 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.
thực hiện
Người ủy quyền khi ký dữ liệu ủy quyền, cần thực hiện mã hóa RLP cho chain_id, address, nonce trước. Sau đó, dữ liệu đã mã hóa sẽ được thực hiện hàm băm keccak256 cùng với số MAGIC, để thu đượ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 dấu phân cách miền, với mục đích đả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 đó có nghĩa là người ủy quyền cho phép lặp lại quyền hạ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 trùng 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 hiện trong khối, Proposer sẽ thực hiện kiểm tra trước giao dịch, trong đó kiểm tra địa chỉ to một cách bắt buộc để đả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, các giao dịch loại này sẽ yêu cầu trường authorization_list trong giao dịch phải ít nhất chứa 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 viê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, 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 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 phải bất kỳ lỗi nào, mục ủy quyền này sẽ bị bỏ qua, giao dịch cũng 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 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 ứ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 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 bởi giao dịch loại SET_CODE_TX_TYPE )0x04(.
Sau khi cấp quyền hoàn tất, nếu người cấp quyền muốn gỡ bỏ quyền, chỉ cần đặt địa chỉ mục tiêu ủy quyền thành địa chỉ 0.
Loại giao dịch mới được giới thiệu thông 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 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 gũi 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 của 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 tình huống ứ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 bên tham gia hệ sinh thái cần phải cảnh giác trong quá trình thực hiện:
) 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 thông qua các phương pháp phục hồi xã hội được 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 lộ khóa riêng EOA. Cần phải làm rõ rằng sau khi thực hiện ủy quyền, khóa riêng EOA vẫn có 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í sau khi hoàn tất ủy quyền cho EOA, ngay cả khi xóa hoàn toàn khóa riêng được lưu trữ tại địa phương, cũng không thể hoàn toàn loại trừ 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, 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ể lựa 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 và có hiệu lực trên nhiều chuỗi, để tiện lợi 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 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 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ó tương thích 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 không phải lúc nào cũng có mã hợp đồng giống nhau, nên cần tìm hiểu rõ về mục tiêu ủy thác.
không thể khởi tạo
Các ví hợp đồng thông minh hiện tại chủ yếu sử dụng mô hình đại lý, trong đó đại lý ví sẽ gọi hàm khởi tạo của hợp đồng thông qua DELEGateCALL khi triển khai, nhằm thực hiện việc khởi tạo ví và triển khai ví đại lý trong một thao tác 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ỉ đó, 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 proxy ERC-1967 thông thường để thực hiện khởi tạo ví.
Đố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í, chẳng hạn như thông qua ecrecover để phục hồi địa chỉ chữ ký nhằm thực hiện kiểm tra quyền, để 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ể vì nhu cầu chức năng thay đổi, nâng cấp ví, v.v., 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 ), trong trường hợp ủ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ũ, từ đó gây ra tình trạng khóa tài khoản, mất tiền và các hậu quả không mong muốn khác.
Đố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, 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 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 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 của ủ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 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, phòng ngừa rủi ro giả nạp tiền 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 gọi chính nó và thực hiện gọi từ 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ả đị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 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 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 thực hiện các hàm gọi lại tương ứng để đảm bảo có thể tương thích với các token chính.
Kiểm tra giả mạo
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, và 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, thì 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 sớm 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 chữ 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, nhằm giảm thiểu rủi ro mà người dùng có thể gặp phải khi 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 về hợp đồng mục tiêu ủy quyền của 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 được những rủi ro như vậy.
Tóm tắt
Bài viết này xoay quanh việc thảo luận về đề xuất EIP-7702 trong 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 khả 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 EIP-7702 đã được thử nghiệm thực tế, nên trong ứng dụng thực tế, 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, 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 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.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
6 thích
Phần thưởng
6
5
Chia sẻ
Bình luận
0/400
PermabullPete
· 19giờ trước
lên xe就卷 Sổ lệnh又得炸咯
Xem bản gốcTrả lời0
StablecoinEnjoyer
· 19giờ trước
Có vẻ hơi đi trước một bước, cảm giác như Vitalik Buterin lại đang làm việc lớn.
Xem bản gốcTrả lời0
Token_Sherpa
· 19giờ trước
meh... một đề xuất khác sẽ không giải quyết được những vấn đề thực sự của eth thật lòng mà nói
EIP-7702 Độ sâu解析：Ethereum Pectra nâng cấp sẽ làm mờ ranh giới giữa EOA và CA
Ethereum Pectra nâng cấp: EIP-7702 Độ sâu解析
Lời nói đầu
Ethereum sắp đón chào bản nâng cấp Pectra, đây là một cập nhật có ý nghĩa quan trọng, sẽ giới thiệu nhiều đề xuất cải tiến quan trọng. Trong đó, EIP-7702 đã thực hiện một cuộc cách mạng hóa đố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 hóa tài khoản bản địa 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 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 hành 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 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 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 hạn, quản lý đa chữ ký, xác minh 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, 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á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 đều 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 bao gồm:
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), nghĩa 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.
thực hiện
Người ủy quyền khi ký dữ liệu ủy quyền, cần thực hiện mã hóa RLP cho chain_id, address, nonce trước. Sau đó, dữ liệu đã mã hóa sẽ được thực hiện hàm băm keccak256 cùng với số MAGIC, để thu đượ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 dấu phân cách miền, với mục đích đả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 đó có nghĩa là người ủy quyền cho phép lặp lại quyền hạ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 trùng 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 hiện trong khối, Proposer sẽ thực hiện kiểm tra trước giao dịch, trong đó kiểm tra địa chỉ to một cách bắt buộc để đả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, các giao dịch loại này sẽ yêu cầu trường authorization_list trong giao dịch phải ít nhất chứa 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 viê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, 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 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 phải bất kỳ lỗi nào, mục ủy quyền này sẽ bị bỏ qua, giao dịch cũng 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 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 ứ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 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 bởi giao dịch loại SET_CODE_TX_TYPE )0x04(.
Sau khi cấp quyền hoàn tất, nếu người cấp quyền muốn gỡ bỏ quyền, chỉ cần đặt địa chỉ mục tiêu ủy quyền thành địa chỉ 0.
Loại giao dịch mới được giới thiệu thông 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 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 gũi 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 của 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 tình huống ứ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 bên tham gia hệ sinh thái cần phải cảnh giác trong quá trình thực hiện:
) 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 thông qua các phương pháp phục hồi xã hội được 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 lộ khóa riêng EOA. Cần phải làm rõ rằng sau khi thực hiện ủy quyền, khóa riêng EOA vẫn có 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í sau khi hoàn tất ủy quyền cho EOA, ngay cả khi xóa hoàn toàn khóa riêng được lưu trữ tại địa phương, cũng không thể hoàn toàn loại trừ 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, 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ể lựa 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 và có hiệu lực trên nhiều chuỗi, để tiện lợi 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 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 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ó tương thích 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 không phải lúc nào cũng có mã hợp đồng giống nhau, nên cần tìm hiểu rõ về mục tiêu ủy thác.
không thể khởi tạo
Các ví hợp đồng thông minh hiện tại chủ yếu sử dụng mô hình đại lý, trong đó đại lý ví sẽ gọi hàm khởi tạo của hợp đồng thông qua DELEGateCALL khi triển khai, nhằm thực hiện việc khởi tạo ví và triển khai ví đại lý trong một thao tác 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ỉ đó, 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 proxy ERC-1967 thông thường để thực hiện khởi tạo ví.
Đố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í, chẳng hạn như thông qua ecrecover để phục hồi địa chỉ chữ ký nhằm thực hiện kiểm tra quyền, để 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ể vì nhu cầu chức năng thay đổi, nâng cấp ví, v.v., 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 ), trong trường hợp ủ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ũ, từ đó gây ra tình trạng khóa tài khoản, mất tiền và các hậu quả không mong muốn khác.
Đố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, 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 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 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 của ủ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 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, phòng ngừa rủi ro giả nạp tiền 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 gọi chính nó và thực hiện gọi từ 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ả đị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 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 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 thực hiện các hàm gọi lại tương ứng để đảm bảo có thể tương thích với các token chính.
Kiểm tra giả mạo
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, và 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, thì 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 sớm 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 chữ 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, nhằm giảm thiểu rủi ro mà người dùng có thể gặp phải khi 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 về hợp đồng mục tiêu ủy quyền của 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 được những rủi ro như vậy.
Tóm tắt
Bài viết này xoay quanh việc thảo luận về đề xuất EIP-7702 trong 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 khả 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 EIP-7702 đã được thử nghiệm thực tế, nên trong ứng dụng thực tế, 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, 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 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.