Nâng cấp Ethereum Pectra: Phân tích sâu EIP-7702 và các thực tiễn tốt nhất
Lời nói đầu
Ethereum sắp chào đó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 số đó, EIP-7702 đã thực hiện 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 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ẽ 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 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ổng quan
EIP-7702 giới thiệu một loại giao dịch mới, cho phép EOA chỉ định một địa chỉ hợp đồng thông minh để thiết lập mã. Điều này cho phép EOA thực thi mã như một hợp đồng thông minh, đồng thời giữ lại khả năng khởi tạo giao dịch. Tính năng này mang lại cho EOA khả năng lập trình và tính khả thi, 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ý nhiều chữ ký, xác thực zk, thanh toán theo hình thức đăng ký, tài trợ giao dịch và xử lý lô giao dịch trong EOA. Cần lưu ý rằng, 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 bên đã đơn giản hóa đáng kể 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:
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 có kiểu 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 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 EOA ( ký, 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 thanh toán 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 RLP mã hóa 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, để 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 làm 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.
Khi chain_id được ủy quyền bởi người ủy quyền là 0, 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 trùng khớp với (.
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 đó 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 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 phát động giao dịch trước, sau đó thực hiện thao tác applyAuthorization cho từng mục ủy quyền trong danh sách authorization_list. Trong thao tác applyAuthorization, nút sẽ kiểm tra nonce của người ủy quyền trước, sau đó mới 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ị của nonce nên được tăng thêm 1.
Khi nút ứng 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 đó 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, từ đó đảm bảo không xuất hiện rủi ro DoS trong các kịch bản ủy quyền hàng loạt.
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 || địa chỉ, trong đó 0xef0100 là định danh cố định, địa chỉ là địa chỉ mục tiêu được ủy thác. 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 hoàn tất việc ủ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 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 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 đã thổi luồng sinh khí mới vào hệ sinh thái Ethereum, nhưng các trường hợp ứ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 cảnh giác trong quá trình thực hành:
) lưu trữ khóa riêng
Ngay cả khi 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 tiền do mất khóa riêng sau khi ủy thác, nhưng nó vẫn không thể tránh khỏi rủi ro khóa riêng EOA bị rò rỉ. Cần phải làm rõ rằng, sau khi thực hiện ủy thác, 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ùy ý 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ữ tại địa phương, cũng không thể hoàn toàn loại trừ rủi ro rò rỉ khóa riêng, đặ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 quyền, 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ý kết ủ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 trên nhiều chuỗi, giúp 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ã 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 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 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õ mục tiêu ủy thác trước.
không thể khởi tạo
Các ví thông minh chính hiện nay hầu hết đều sử dụng mô hình ủy quyền, khi triển khai, ví ủy quyền sẽ gọi hàm khởi tạo hợp đồng thông qua DELEGateCALL, từ đó thực hiện thao tác khởi tạo ví và triển khai ví ủy quyề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, 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 ủy quyền ERC-1967 phổ biến.
Đố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 chú ý 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 để phục hồi địa chỉ chữ ký và thực hiện kiểm tra quyền, nhằm tránh rủi ro ví bị chạy mất trong quá trình khởi tạo.
Quản lý lưu trữ
Người dùng khi sử dụng chức năng ủy quyền EIP-7702, có thể vì nhu cầu chức năng thay đổi, nâng cấp ví, v.v., cần ủ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, 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ả không mong muốn như khóa tài khoản, mất mát tài sản, v.v.
Đố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 cầ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ữ. Hơn nữa, 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 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 ủ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, do đó sàn giao dịch tập trung (CEX) có thể sẽ phải đối mặt với tình huống hợp đồng thông minh nạp tiền trở nên phổ biến.
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, để ngăn 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 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 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 nữa. Tương tự, việc kiểm tra 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 trong quá trình phát triển nên giả định rằng các tham gia viên 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 quyền 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 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, việc kẻ tấn công đánh cắp tiền sẽ trở nên dễ dàng.
Đối với các nhà cung cấp dịch vụ ví, việc hỗ trợ nhanh chóng các giao dịch loại EIP-7702 là rất quan trọng, và khi người dùng thực hiện chữ 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ể gặp phải khi bị tấn công lừa đảo.
Ngoài ra, việc phân tích tự động sâu hơn các hợp đồng mục tiêu được ủy thác cho tài khoản ### kiểm tra mã nguồn, kiểm tra quyền hạn, 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 đề 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ó thể 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 kiểm chứng 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 về các 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 đá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.
11 thích
Phần thưởng
11
5
Chia sẻ
Bình luận
0/400
ser_ngmi
· 16giờ trước
Chép bài tập chép mệt rồi, chẳng phải chỉ muốn có một eoa và ca sao?
Xem bản gốcTrả lời0
ParanoiaKing
· 07-20 23:50
Một đống nâng cấp khó hiểu nữa, thật không biết nói gì.
Xem bản gốcTrả lời0
YieldHunter
· 07-20 23:49
nói một cách kỹ thuật, eip này trông có vẻ nghi ngờ... có dữ liệu nào về chi phí tx trên testnet không?
Xem bản gốcTrả lời0
EyeOfTheTokenStorm
· 07-20 23:26
Một cơ hội để bố trí trước nữa? Dựa vào dữ liệu lịch sử, sau khi nâng cấp tương tự eth thường sẽ bơm lớn, nhưng thị trường có chút bong bóng.
Xem bản gốcTrả lời0
SchrodingerPrivateKey
· 07-20 23:23
Lại có EIP mới, tài khoản hợp đồng phiên bản gầy đã đến.
EIP-7702 phân tích: nâng cấp Pectra Ethereum làm thế nào để trao quyền cho EOA khả năng lập trình
Nâng cấp Ethereum Pectra: Phân tích sâu EIP-7702 và các thực tiễn tốt nhất
Lời nói đầu
Ethereum sắp chào đó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 số đó, EIP-7702 đã thực hiện 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 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ẽ 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 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ổng quan
EIP-7702 giới thiệu một loại giao dịch mới, cho phép EOA chỉ định một địa chỉ hợp đồng thông minh để thiết lập mã. Điều này cho phép EOA thực thi mã như một hợp đồng thông minh, đồng thời giữ lại khả năng khởi tạo giao dịch. Tính năng này mang lại cho EOA khả năng lập trình và tính khả thi, 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ý nhiều chữ ký, xác thực zk, thanh toán theo hình thức đăng ký, tài trợ giao dịch và xử lý lô giao dịch trong EOA. Cần lưu ý rằng, 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 bên đã đơn giản hóa đáng kể 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 có kiểu danh sách, có thể chứa nhiều mục ủy quyền, mỗi mục ủy quyền trong đó:
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 EOA ( ký, 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 thanh toán 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 RLP mã hóa 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, để 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 làm 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.
Khi chain_id được ủy quyền bởi người ủy quyền là 0, 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 trùng khớp với (.
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 đó 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 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 phát động giao dịch trước, sau đó thực hiện thao tác applyAuthorization cho từng mục ủy quyền trong danh sách authorization_list. Trong thao tác applyAuthorization, nút sẽ kiểm tra nonce của người ủy quyền trước, sau đó mới 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ị của nonce nên được tăng thêm 1.
Khi nút ứng 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 đó 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, từ đó đảm bảo không xuất hiện rủi ro DoS trong các kịch bản ủy quyền hàng loạt.
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 || địa chỉ, trong đó 0xef0100 là định danh cố định, địa chỉ là địa chỉ mục tiêu được ủy thác. 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 hoàn tất việc ủ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 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 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 đã thổi luồng sinh khí mới vào hệ sinh thái Ethereum, nhưng các trường hợp ứ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 cảnh giác trong quá trình thực hành:
) lưu trữ khóa riêng
Ngay cả khi 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 tiền do mất khóa riêng sau khi ủy thác, nhưng nó vẫn không thể tránh khỏi rủi ro khóa riêng EOA bị rò rỉ. Cần phải làm rõ rằng, sau khi thực hiện ủy thác, 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ùy ý 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ữ tại địa phương, cũng không thể hoàn toàn loại trừ rủi ro rò rỉ khóa riêng, đặ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 quyền, 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ý kết ủ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 trên nhiều chuỗi, giúp 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ã 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 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 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õ mục tiêu ủy thác trước.
không thể khởi tạo
Các ví thông minh chính hiện nay hầu hết đều sử dụng mô hình ủy quyền, khi triển khai, ví ủy quyền sẽ gọi hàm khởi tạo hợp đồng thông qua DELEGateCALL, từ đó thực hiện thao tác khởi tạo ví và triển khai ví ủy quyề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, 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 ủy quyền ERC-1967 phổ biến.
Đố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 chú ý 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 để phục hồi địa chỉ chữ ký và thực hiện kiểm tra quyền, nhằm tránh rủi ro ví bị chạy mất trong quá trình khởi tạo.
Quản lý lưu trữ
Người dùng khi sử dụng chức năng ủy quyền EIP-7702, có thể vì nhu cầu chức năng thay đổi, nâng cấp ví, v.v., cần ủ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, 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ả không mong muốn như khóa tài khoản, mất mát tài sản, v.v.
Đố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 cầ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ữ. Hơn nữa, 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 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 ủ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, do đó sàn giao dịch tập trung (CEX) có thể sẽ phải đối mặt với tình huống hợp đồng thông minh nạp tiền trở nên phổ biến.
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, để ngăn 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 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 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 nữa. Tương tự, việc kiểm tra 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 trong quá trình phát triển nên giả định rằng các tham gia viên 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 quyền 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 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, việc kẻ tấn công đánh cắp tiền sẽ trở nên dễ dàng.
Đối với các nhà cung cấp dịch vụ ví, việc hỗ trợ nhanh chóng các giao dịch loại EIP-7702 là rất quan trọng, và khi người dùng thực hiện chữ 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ể gặp phải khi bị tấn công lừa đảo.
Ngoài ra, việc phân tích tự động sâu hơn các hợp đồng mục tiêu được ủy thác cho tài khoản ### kiểm tra mã nguồn, kiểm tra quyền hạn, 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 đề 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ó thể 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 kiểm chứng 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 về các 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 đáng để các bên tham khảo và áp dụng trong quá trình thực hiện.