Ethereum Pectra nâng cấp: EIP-7702 mang đến sự cải cách cách mạng cho EOA
Lời mở đầu
Ethereum sắp đón chào nâng cấp Pectra, đây là một bản cập nhật có ý nghĩa lớn, nhiều đề xuất cải tiến quan trọng sẽ được giới thiệu. Trong đó, EIP-7702 đã thực hiện một cuộc 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 tiến tới trừu tượng hóa tài khoản gốc sau EIP-4337, mang lại một mô hình tương tác hoàn toàn mới cho hệ sinh thái Ethereum.
Pectra đã hoàn tất 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 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 để 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, trong khi vẫn giữ khả năng phát độ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ể triển khai các chức năng như 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 kiểu đăng ký, tài trợ giao dịch và xử lý giao dịch hàng loạt trong EOA. Đáng chú ý, EIP-7702 tương thích hoàn hảo 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 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ủa nó đượ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 tuân theo cùng một ngữ nghĩa với 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 thể hiện chuỗi mà ủy quyền này có hiệu lực.
address biểu thị đị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 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 xướng giao dịch có thể khác với người ủy quyền, nhằm thực hiện việc trả phí 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 đó, dữ liệu đã mã hóa sẽ được thực hiện hàm băm keccak256 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 đã được băm, thu được dữ liệu y_parity, r, s. MAGIC (0x05) được sử dụng làm ký tự phân cách miền, với mục đích đảm bảo rằng kết quả của các chữ ký loại khác nhau sẽ không xảy ra xung đột.
Cần lưu ý, khi chain_id mà người ủy quyền cấp phép là 0, có nghĩa là người ủy quyền cho phép lặp 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 ).
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 thi trong khối, Proposer sẽ thực hiện kiểm tra trước giao dịch, trong đó có việc kiểm tra bắt buộc đị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, các giao dịch như vậy bắt buộc yêu cầu trường authorization_list ít nhất phải chứa 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, cuối cùng chỉ 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ẽ trước tiên tăng giá trị nonce của người khởi tạo 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 tạo giao dịch và người ủy quyền là cùng một người dùng (EOA), khi ký giao dịch ủy quyền, giá trị của nonce nên được tăng thêm 1.
Khi nút gặp lỗi trong việc áp dụng một mục cấp phép nào đó, mục cấp phép đó sẽ bị bỏ qua, giao dịch sẽ không thất bại, các mục cấp phép khác sẽ tiếp tục được áp dụng, nhằm đảm bảo không xảy ra rủi ro DoS trong tình huống cấp phép hàng loạt.
Sau khi hoàn thành ứng dụng ủy quyền, trường code của địa chỉ ủy quyền sẽ được đặt thành 0xef0100 || address, trong đó 0xef0100 là một đị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 xóa ủy 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 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ẽ đem 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 lưu ý trong quá trình thực hiện:
lưu trữ khóa riêng
Dù EOA có thể sử dụng các phương pháp phục hồi 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 thác, nhưng vẫn không thể tránh khỏi rủi ro khóa riêng của EOA bị lộ. Cần phải làm rõ rằng, sau khi thực hiện ủy thác, khóa riêng của EOA vẫn có 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í thực hiện ủy thác 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 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
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, 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 trên nhiều chuỗi, giúp người dùng chỉ cần ký một lần để thực hiệ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 trên nhiều chuỗi, 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 ủy thác có phù hợp 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 phải 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 hiện tại chủ yếu sử dụng mô hình đại diện, trong đó ví đại diện khi triển khai sẽ gọi hàm khởi tạo của hợp đồng thông qua DELEGateCALL, nhằm thực hiện thao tác khởi tạo ví và triển khai ví đại diện 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ó trường code của địa chỉ đó được cập nhật, và không thể khởi tạo bằng cách gọi địa chỉ ủy quyền. Điều này khiến EIP-7702 không thể gọi hàm khởi tạo để thực hiện khởi tạo ví trong giao dịch triển khai hợp đồng giống như các hợp đồng đại diện 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 thao tác khởi tạo ví, chẳng hạn như thông qua ecrecover để khôi phục địa chỉ chữ ký, nhằm 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 tính năng ủy quyền EIP-7702, có thể do sự thay đổi nhu cầu chức năng, nâng cấp ví, v.v., cần phải ủy quyền 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 quyền lại, điều này 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 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, cầ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 được 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 về ủy quyền lại dành 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 quyền, 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 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 qua trace, phòng 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 triển khai ủ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ể được 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 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 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 bằng 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 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 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, các 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 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 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 hỗ trợ các giao dịch loại EIP-7702 càng sớm càng tốt là vô cùng quan trọng, và khi người dùng thực hiện chữ ký ủy quyền, cần phải 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 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 đối với hợp đồng mục tiêu được ủy quyền của tài khoản, kiểm tra mã nguồn, kiểm tra quyền hạn và các yếu tố khác có thể giúp người dùng tránh được các 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à khả năng 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 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 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 tàng, nhưng vẫn đáng để các bên tham khảo và áp dụng trong thực tế.
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.
17 thích
Phần thưởng
17
9
Đăng lại
Chia sẻ
Bình luận
0/400
notSatoshi1971
· 07-26 08:08
Cuộc thị trường trước khi bắt đầu phải nằm phục kích trước, 7702 chắc chắn To da moon
Xem bản gốcTrả lời0
0xSunnyDay
· 07-24 10:37
Cái nâng cấp này quá mạnh mẽ 8 đã lao vào
Xem bản gốcTrả lời0
BasementAlchemist
· 07-23 13:37
Lại thêm một đợt cải cách tài khoản hợp đồng? Thật là vô lý.
Xem bản gốcTrả lời0
MEVHunterX
· 07-23 13:21
Lại là câu chuyện tiếp theo của 4337 ~ Thơm quá, cứ lao vào một phen!
Xem bản gốcTrả lời0
PanicSeller69
· 07-23 13:20
Một khi nhìn thấy là phải bơm rồi. Khi nào bắt đầu mua đáy v thần?
Xem bản gốcTrả lời0
FastLeaver
· 07-23 13:14
Lại là nâng cấp?? Rug Pull cảnh báo
Xem bản gốcTrả lời0
PerennialLeek
· 07-23 13:12
Tăng lên vài đợt, ai hiểu thì sẽ hiểu.
Xem bản gốcTrả lời0
WinterWarmthCat
· 07-23 13:12
Máy rút tiền đã nói chuyện! Có bản nâng cấp mới? Chúng ta sẽ nói về việc rút tiền sau.
Xem bản gốcTrả lời0
Web3ExplorerLin
· 07-23 13:07
thú vị... eip-7702 có thể chính là bước nhảy vọt mà eth cần ngay bây giờ
Ethereum Pectra nâng cấp: EIP-7702 làm mờ ranh giới giữa EOA và CA, mở ra kỷ nguyên mới của trừu tượng hóa tài khoản.
Ethereum Pectra nâng cấp: EIP-7702 mang đến sự cải cách cách mạng cho EOA
Lời mở đầu
Ethereum sắp đón chào nâng cấp Pectra, đây là một bản cập nhật có ý nghĩa lớn, nhiều đề xuất cải tiến quan trọng sẽ được giới thiệu. Trong đó, EIP-7702 đã thực hiện một cuộc 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 tiến tới trừu tượng hóa tài khoản gốc sau EIP-4337, mang lại một mô hình tương tác hoàn toàn mới cho hệ sinh thái Ethereum.
Pectra đã hoàn tất 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 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 để 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, trong khi vẫn giữ khả năng phát độ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ể triển khai các chức năng như 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 kiểu đăng ký, tài trợ giao dịch và xử lý giao dịch hàng loạt trong EOA. Đáng chú ý, EIP-7702 tương thích hoàn hảo 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 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ủ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 cùng một ngữ nghĩa với 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), tức 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 trả phí 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 đó, dữ liệu đã mã hóa sẽ được thực hiện hàm băm keccak256 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 đã được băm, thu được dữ liệu y_parity, r, s. MAGIC (0x05) được sử dụng làm ký tự phân cách miền, với mục đích đảm bảo rằng kết quả của các chữ ký loại khác nhau sẽ không xảy ra xung đột.
Cần lưu ý, khi chain_id mà người ủy quyền cấp phép là 0, có nghĩa là người ủy quyền cho phép lặp 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 ).
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 thi trong khối, Proposer sẽ thực hiện kiểm tra trước giao dịch, trong đó có việc kiểm tra bắt buộc đị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, các giao dịch như vậy bắt buộc yêu cầu trường authorization_list ít nhất phải chứa 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, cuối cùng chỉ 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ẽ trước tiên tăng giá trị nonce của người khởi tạo 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 tạo giao dịch và người ủy quyền là cùng một người dùng (EOA), khi ký giao dịch ủy quyền, giá trị của nonce nên được tăng thêm 1.
Khi nút gặp lỗi trong việc áp dụng một mục cấp phép nào đó, mục cấp phép đó sẽ bị bỏ qua, giao dịch sẽ không thất bại, các mục cấp phép khác sẽ tiếp tục được áp dụng, nhằm đảm bảo không xảy ra rủi ro DoS trong tình huống cấp phép hàng loạt.
Sau khi hoàn thành ứng dụng ủy quyền, trường code của địa chỉ ủy quyền sẽ được đặt thành 0xef0100 || address, trong đó 0xef0100 là một đị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 xóa ủy 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 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ẽ đem 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 lưu ý trong quá trình thực hiện:
lưu trữ khóa riêng
Dù EOA có thể sử dụng các phương pháp phục hồi 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 thác, nhưng vẫn không thể tránh khỏi rủi ro khóa riêng của EOA bị lộ. Cần phải làm rõ rằng, sau khi thực hiện ủy thác, khóa riêng của EOA vẫn có 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í thực hiện ủy thác 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 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
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, 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 trên nhiều chuỗi, giúp người dùng chỉ cần ký một lần để thực hiệ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 trên nhiều chuỗi, 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 ủy thác có phù hợp 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 phải 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 hiện tại chủ yếu sử dụng mô hình đại diện, trong đó ví đại diện khi triển khai sẽ gọi hàm khởi tạo của hợp đồng thông qua DELEGateCALL, nhằm thực hiện thao tác khởi tạo ví và triển khai ví đại diện 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ó trường code của địa chỉ đó được cập nhật, và không thể khởi tạo bằng cách gọi địa chỉ ủy quyền. Điều này khiến EIP-7702 không thể gọi hàm khởi tạo để thực hiện khởi tạo ví trong giao dịch triển khai hợp đồng giống như các hợp đồng đại diện 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 thao tác khởi tạo ví, chẳng hạn như thông qua ecrecover để khôi phục địa chỉ chữ ký, nhằm 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 tính năng ủy quyền EIP-7702, có thể do sự thay đổi nhu cầu chức năng, nâng cấp ví, v.v., cần phải ủy quyền 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 quyền lại, điều này 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 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, cầ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 được 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 về ủy quyền lại dành 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 quyền, 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 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 qua trace, phòng 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 triển khai ủ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ể được 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 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 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 bằng 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 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 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, các 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 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 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 hỗ trợ các giao dịch loại EIP-7702 càng sớm càng tốt là vô cùng quan trọng, và khi người dùng thực hiện chữ ký ủy quyền, cần phải 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 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 đối với hợp đồng mục tiêu được ủy quyền của tài khoản, kiểm tra mã nguồn, kiểm tra quyền hạn và các yếu tố khác có thể giúp người dùng tránh được các 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à khả năng 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 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 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 tàng, nhưng vẫn đáng để các bên tham khảo và áp dụng trong thực tế.