E IP-7702 cho phép ví Ethereum đơn giản (EOA) được nâng cấp thành ví hợp đồng thông minh, cung cấp bảo mật cao hơn, chức năng nâng cao, cơ hội tài trợ Gas và các lợi ích khác. Lịch sử , ví thông minh phải được xây dựng từ đầu, nhưng với sự nhìn lên của EIP-7702, ví truyền thống có thể được nâng cấp và giữ nguyên tất cả tài sản và lịch sử trên Chuỗi , trong khi vẫn giữ nguyên địa chỉ ví. Giống như chuyển từ điện thoại cố định sang điện thoại thông minh mà không cần số mới.
EOA được nâng cấp bằng cách thiết lập "chỉ định ủy quyền", chỉ báo đến hợp đồng thông minh ủy quyền, sau đó ủy quyền logic của hợp đồng thông minh để quản lý EOA. Do đó, EOA nâng cấp có thể có các chức năng, thiết lập lưu trữ, phát sự kiện và thực hiện tất cả các hoạt động khác mà hợp đồng thông minh có thể thực hiện. EOA có thể thay đổi hoặc xóa ủy quyền này bất kỳ lúc nào thông qua ủy quyền EIP-7702 mới, đã ký. Mặc dù điều này mở ra nhiều khả năng mới, nhưng tính năng mạnh mẽ này cũng đưa ra những thách thức bảo mật mới đòi hỏi phải cân nhắc cẩn thận và các giải pháp sáng tạo.
Để cho phép EOA hoạt động như một ví hợp đồng thông minh, chúng tôi đã phát triển EIP7702Proxy, một hợp đồng proxy ERC-1967 nhẹ được thiết kế để sử dụng làm đại biểu EIP-7702 cho EOA. Ngoài việc chuyển tiếp logic cơ bản do proxy thực hiện, EIP7702Proxy còn chứa các tính năng và lựa chọn thiết kế khác giải quyết một số thách thức riêng đối với tài khoản đại biểu EIP-7702. Một mục tiêu của việc thiết kế EIP7702Proxy là duy trì tính ngang bằng càng nhiều càng tốt giữa Ví thông minh Coinbase "triển khai tiêu chuẩn" và Ví thông minh Coinbase được ủy quyền EIP-7702, nghĩa là trừu tượng hóa độ phức tạp bổ sung mà cơ chế EIP-7702 yêu cầu thành một proxy chuyên dụng và tiếp tục dựa vào triển khai ban đầu của CoinbaseSmartWallet. Giải pháp cho thách thức này có thể được áp dụng hiệu quả cho bất kỳ logic triển khai nào, không chỉ triển khai CoinbaseSmartWallet, đồng thời giúp EOA duy trì tính bảo mật trong hoàn cảnh hỗ trợ 7702.
Dưới đây chúng tôi mô tả những thách thức cụ thể và các giải pháp thiết kế tương ứng cho phép chúng tôi điều chỉnh an toàn bất kỳ triển khai ví hợp đồng thông minh hiện có nào để sử dụng với nâng cấp EIP-7702.
Thách thức #1: Thực thi khởi tạo an toàn
Rào cản lớn đầu tiên đối với việc triển khai EIP-7702 xuất phát từ những hạn chế về khởi tạo của nó. Các ví hợp đồng thông minh truyền thống (bao gồm CoinbaseSmartWallet) thường xử lý khởi tạo an toàn (thiết lập quyền sở hữu tài khoản) một cách nguyên tử trong quá trình triển khai thông qua một hợp đồng nhà máy riêng biệt. Tính nguyên tử này có nghĩa là nhiều triển khai như vậy có các hàm khởi tạo không được bảo vệ mà chỉ có thể được gọi một lần. Tuy nhiên, thiết kế của EIP-7702 không cho phép thực hiện calldata khởi tạo trong quá trình chuyển giao mã (bước tương đương với "triển khai"), do đó không thể thực hiện điều này một cách nguyên tử.
Sự tách biệt các bước này tạo ra một cửa sổ lỗ hổng quan trọng. Khi hợp đồng triển khai được "triển khai" tới EOA thông qua EIP-7702, không có gì đảm bảo rằng nâng cấp 7702 này và giao dịch EVM chuẩn khởi tạo ví sẽ thực thi nguyên tử. Về mặt kỹ thuật, mã thiết lập quyền có thể được áp dụng độc lập với giao dịch khởi tạo ngay cả khi được gửi cùng lúc, điều này có thể cho phép kẻ tấn công thực hiện trước giao dịch khởi tạo và tuyên bố quyền sở hữu tài khoản thông minh.
Giải pháp: Yêu cầu chữ ký EOA để thiết lập nguyên tử việc triển khai và khởi tạo
Lưu ý rằng Coinbase Smart Wallet hiện tại được triển khai đằng sau proxy ERC-1967 với triển khai UUPSUpgradeable (logic CoinbaseSmartWallet thực tế). Mã trong địa chỉ tài khoản thực tế là proxy sử dụng các vị trí lưu trữ thông thường được xác định bởi ERC-1967 để lưu trữ chỉ báo đến logic triển khai của nó. Giải pháp của chúng tôi cho lỗ hổng khởi tạo trong bối cảnh của 7702 liên quan đến việc nhận ra rằng bất kỳ logic triển khai nào cũng chỉ trở nên hoạt động (và do đó nguy hiểm) khi proxy thực sự thiết lập kết nối với nó. Do đó, nếu chúng tôi không thể thực thi triển khai và khởi tạo nguyên tử, chúng tôi có thể thực thi thiết lập và khởi tạo triển khai nguyên tử.
Kiến trúc hợp đồng EIP-7702CoinbaseSmartWallet và quy trình ủy quyền hợp lý
Trong bối cảnh của EIP-7702, bản thân EOA là quyền ban đầu để thực hiện bất kỳ thay đổi nào đối với tài khoản của nó và phải cung cấp chữ ký để cho phép bất kỳ chủ sở hữu nào khởi tạo và tạo tài khoản thông minh mới. Hợp đồng EIP7702Proxy của chúng tôi triển khai hàm setImplementation để thiết lập nguyên tử một triển khai logic mới và khởi tạo tài khoản. Hàm setImplementation:
Xác minh chữ ký từ EOA, trong đó gồm thông tin chính như địa chỉ của hợp đồng triển khai mới, dữ liệu cuộc gọi khởi tạo, địa chỉ của hợp đồng xác thực sẽ đánh giá tính an toàn của trạng thái tài khoản cuối cùng và các biện pháp bảo vệ phát lại chữ ký cơ bản như nonce và thời gian hết hạn.
Đặt giá trị của chỉ báo ERC-1967 thành triển khai mới và thực thi calldata được cung cấp theo triển khai logic mới.
Gọi hàm validateAccountState, hàm này phải được trình xác thực có trong chữ ký triển khai.
Trình xác thực là hợp đồng cụ thể về triển khai trong đó chứa logic để đánh giá xem nó cho rằng trạng thái tài khoản cuối cùng là an toàn hay không. Ví dụ, đối với CoinbaseSmartWallet, CoinbaseSmartWalletValidator sẽ kiểm tra xem trạng thái sở hữu của tài khoản có phải là không null hay không và do đó không còn dễ bị khởi tạo tùy ý nữa.
Thách thức #2: Lưu trữ được chia sẻ giữa các phái đoàn EIP-7702
Có lẽ thách thức phức tạp nhất của EIP-7702 liên quan đến quản lý lưu trữ. EOA có thể tự do chuyển giao lại logic của mình cho các hợp đồng khác nhau bất kỳ lúc nào hoặc xóa hoàn toàn việc chuyển giao. Tất cả các chuyển giao đều chia sẻ cùng một không gian lưu trữ tại địa chỉ EOA. Theo thời gian, nhiều hợp đồng chia sẻ quyền truy cập vào cùng một kho lưu trữ có thể dẫn đến các vấn đề "xung đột lưu trữ". Xung đột lưu trữ xảy ra khi hai hợp đồng thực hiện các thay đổi khác nhau hoặc đưa ra các giả định khác nhau về cùng một vị trí lưu trữ, điều này có thể gây ra các lỗi không thể đoán trước.
Quản lý xung đột lưu trữ vốn đã là một vấn đề quen thuộc trong thế giới thiết kế proxy, nơi logic triển khai có thể thay đổi được sử dụng để quản lý lưu trữ được chia sẻ. Mặc dù proxy có nâng cấp có thể thay đổi triển khai, nhưng bản thân mã proxy (đối với các địa chỉ không phải 7702) không thể thay đổi. Điều này mang lại tính quyết định và đảm bảo cho quy trình nâng cấp. Việc ủy quyền lại 7702 giới thiệu một lớp có thể thay đổi hoàn toàn khác cho logic cơ bản có thể quản lý lưu trữ được chia sẻ này. Về cơ bản, điều này loại bỏ mọi đảm bảo xung quanh các tác động mà các ủy quyền tùy ý có thể có đối với lưu trữ. Ví dụ: nếu EOA ủy quyền từ đại biểu A cho B và quay lại A một lần nữa, đại biểu được trả về không thể đưa ra giả định về trạng thái lưu trữ của mình và đại biểu B có thể đã xóa hoặc thao túng nó thành trạng thái không thể đạt được chỉ thông qua logic của đại biểu A. Điều này đúng với bất kỳ ủy quyền 7702 nào, bất kể chế độ ủy quyền nào, vì đại biểu trước đó có thể đã lưu trữ hoặc xóa bất kỳ thứ gì tại bất kỳ vị trí lưu trữ nào.
Ví dụ về trạng thái không hợp lệ của đại biểu A do mô hình ủy quyền A → B → A
Giải pháp: Ngoại hóa các giá trị được lưu trữ quan trọng về an toàn
Việc ủy quyền EOA có thể tùy ý ảnh hưởng đến trạng thái tài khoản. Nếu một EOA được ủy quyền cho một hợp đồng độc hại hoặc phá hoại, không có đại biểu đương nhiệm nào có thể bảo vệ chống lại điều này. Cũng giống như việc ký một giao dịch rút tiền, việc ủy quyền cho một đại biểu độc hại7702 có thể gây ra hậu quả thảm khốc và việc bảo vệ chống lại những kết quả này nằm ngoài phạm vi thiết kế của chúng tôi.
Chúng tôi thiết kế EIP7702Proxy để tự bảo vệ trước các vấn đề có thể lường trước được trong hệ sinh thái đa ví, hỗ trợ 7702 của các tác nhân có thiện chí nhưng có khả năng gây hỗn loạn. Nó không thể bảo vệ EOA cho phép các ủy quyền thực sự độc hại hoặc có lỗi.
Một vấn đề có thể lường trước liên quan đến chữ ký của lệnh gọi setImplementation và rủi ro do trạng thái tài khoản có thể thay đổi gây ra. EIP7702Proxy dựa vào chữ ký EOA để thiết lập logic triển khai và khởi tạo thành trạng thái an toàn. Nếu các chữ ký này có thể được phát lại, chúng có thể trở thành một khoản nợ phải trả. Ví dụ: nếu chữ ký ủy quyền cho chủ sở hữu ban đầu sau đó bị xâm phạm và xóa, chữ ký có thể phát lại có thể thiết lập lại chủ sở hữu bị xâm phạm hoặc buộc hạ cấp triển khai.
Một biện pháp bảo vệ phổ biến chống lại việc phát lại chữ ký là sử dụng nonce trong thông báo ký và đánh dấu là đã sử dụng sau khi xác minh. Rủi ro đối với tài khoản 7702: Các ủy quyền khác có thể làm hỏng bộ lưu trữ theo dõi nonce này. Nếu việc sử dụng nonce theo dõi bộ lưu trữ bị xóa, chữ ký setImplementation của EOA (có sẵn công khai trong mempool) có thể được áp dụng lại khi ủy quyền lại cho EIP7702Proxy.
Để đảm bảo rằng chữ ký không thể được phát lại, chúng tôi đã triển khai một singleton NonceTracker riêng biệt duy trì trạng thái nonce trong một vị trí hợp đồng bất biến bên ngoài bộ lưu trữ tài khoản. Chỉ EOA mới có thể ảnh hưởng đến nonce của nó (chỉ tăng dần), ngăn chặn các đại biểu khác thao túng các giá trị quan trọng về bảo mật này. NonceTracker đảm bảo rằng mỗi chữ ký setImplementation chỉ hoạt động một lần, bất kể bất kỳ thay đổi nào đối với bộ lưu trữ tài khoản.
Thách thức số 3: Tăng rủi ro chia sẻ các địa điểm lưu trữ truyền thống
Các khe lưu trữ chuẩn như khe được định nghĩa bởi ERC-1967 đặc biệt dễ bị xung đột lưu trữ tiềm ẩn vì chúng là các vị trí thông thường mà nhiều triển khai đại biểu có thể sử dụng. Khe triển khai ERC-1967 là vị trí lưu trữ chuẩn duy nhất được sử dụng trong EIP7702Proxy và nó lưu trữ địa chỉ của triển khai logic mà proxy trỏ đến. Thiết kế của chúng tôi đảm bảo rằng bất kể giá trị của vị trí lưu trữ này (xác định hầu hết logic có sẵn trong tài khoản), EIP7702Proxy sẽ luôn có thể thiết lập thành công logic triển khai của nó thành hợp đồng mà EOA mong đợi.
Để minh họa rõ hơn vấn đề đang được giải quyết, hãy lưu ý rằng khi một tài khoản chuyển đổi giữa các ủy quyền khác nhau (A→B→A) trong đó cả hai ủy quyền đều triển khai mẫu proxy ERC-1967, ủy quyền B sẽ tự nhiên sử dụng cùng một khe lưu trữ mà ủy quyền A sử dụng để lưu trữ địa chỉ triển khai của mình. Trong thời hạn của mình, ủy quyền B có thể sửa đổi hoặc ghi đè khe này, cố ý hoặc như một phần bình thường của các hoạt động proxy của riêng mình. Trong mẫu proxy UUPSUpgradeable, logic để nâng cấp triển khai được xác định trên chính hợp đồng triển khai. Nếu triển khai mà ủy quyền B đặt ở vị trí chỉ báo này không chứa giao diện upgradeToAndCall dự kiến trên triển khai, thì khi quay lại ủy quyền A, cơ chế để thay đổi triển khai của nó có thể không tồn tại trong logic hiện có.
Ví dụ về việc ủy quyền mới ghi đè lên vị trí lưu trữ truyền thống được chia sẻ
Giải pháp: Cơ chế nâng cấp có sẵn trên EIP7702Proxy
EIP7702Proxy của chúng tôi giải quyết vấn đề này thông qua hàm setImplementation, hàm này cung cấp cơ chế nâng cấp độc lập với triển khai trực tiếp trên chính proxy. Điều này đảm bảo rằng ngay cả khi một đại biểu trung gian đã trỏ triển khai ERC-1967 đến một triển khai không hợp lệ (hoặc xóa hoàn toàn), sau khi ủy quyền trở lại EIP7702Proxy, EOA ban đầu vẫn giữ nguyên khả năng cấu hình lại chỉ báo ERC-1967 của proxy để trỏ đến triển khai hợp lý mà họ lựa chọn.
Thách thức #4: Khả năng tương thích ngược với hành vi EOA tiêu chuẩn
Một trong những mục tiêu thiết kế của EIP7702Proxy là duy trì khả năng tương thích ngược với chức năng EOA của tài khoản ngoài chức năng hợp đồng thông minh mới. Sự có mặt hoặc không có mã trên một địa chỉ ảnh hưởng đến luồng thực thi của các giao thức tương tác với địa chỉ đó, vì chúng sử dụng tính năng này để phân biệt giữa EOA và hợp đồng thông minh. Có hai hành vi chính cần xem xét: xác minh chữ ký và hành vi nhận token.
Xác minh chữ ký
Tiêu chuẩn xác minh chữ ký cho hợp đồng thông minh khác với tiêu chuẩn cho EOA. Hợp đồng thông minh triển khai giao diện isValidSignature được định nghĩa bởi ERC-1271 và được tự do định nghĩa logic tùy ý để xác định xem hợp đồng có cho rằng chữ ký là hợp lệ hay không. Đối với EOA tiêu chuẩn, chữ ký được xác minh thông qua kiểm tra ecrecover tiêu chuẩn, đảm bảo rằng người ký quay lại địa chỉ EOA mong đợi.
Để đảm bảo rằng các chữ ký EOA hiện tại hoặc tương lai sẽ tiếp tục được nhận dạng trên EOA sau khi nâng cấp 7702, EIP7702Proxy triển khai phiên bản isValidSignature, phiên bản này trước tiên sẽ chuyển giao xác minh chữ ký cho hàm isValidSignature cần được định nghĩa trên triển khai logic, nhưng nếu xác minh không thành công, một kiểm tra ecrecover cuối cùng sẽ được thực hiện. Nếu kiểm tra này vượt qua, chữ ký được cho rằng hợp lệ. Theo cách này, các EOA sử dụng EIP7702Proxy có thể đảm bảo rằng các chữ ký EOA đơn giản sẽ luôn được nhận dạng trên địa chỉ của chúng bất kể triển khai isValidSignature của ví hợp đồng thông minh của chúng.
Nhận Token
Một số tiêu chuẩn token(đặc biệt là ERC-1155 và ERC-721) cố gắng ngăn chặn token bị kẹt trong các hợp đồng thông minh có thể không quản lý được chúng. Token này yêu cầu bất kỳ hợp đồng thông minh nào sẽ nhận được token như vậy phải quảng cáo khả năng này bằng cách triển khai các giao diện người nhận mã token tiêu chuẩn, được gọi bởi các hợp đồng mã token trong quá trình chuyển token. Điều quan trọng nữa là logic trên EOA nâng cấp phải chứa một chức năng nhận tiêu chuẩn hoặc phương án dự phòng phải trả để có thể nhận được Token gốc. Không nên để tài khoản ở trạng thái không thể nhận ETH hoặc token khác, ngay cả trong một khoảng thời gian ngắn.
Vì proxy của chúng tôi thiếu triển khai ban đầu, chúng tôi bao gồm triển khai DefaultReceiver bất biến làm logic mặc định cho EIP7702Proxy khi không có chỉ báo ERC-1967. Bộ thu này triển khai hàm nhận và móc bộ thu cho các tiêu chuẩn mã token chung này, đảm bảo rằng các tài khoản có thể chấp nhận chuyển token trước khi thiết lập rõ ràng triển khai mới.
kết luận
Thiết kế EIP7702Proxy cho phép chúng tôi duy trì sự liên kết chặt chẽ với CoinbaseSmartWallet được triển khai tiêu chuẩn và tiếp tục sử dụng triển khai CoinbaseSmartWallet hiện có trong khi giải quyết các thách thức bảo mật độc đáo phát sinh trong bối cảnh của EIP-7702. Bằng cách cân nhắc cẩn thận về bảo mật khởi tạo, tác động của tính tạm thời và sự can thiệp của bộ lưu trữ, nhu cầu xử lý token không bị gián đoạn và khả năng tương thích ngược với xác minh chữ ký EOA tiêu chuẩn, chúng tôi đã xây dựng một proxy để ủy quyền và quản lý an toàn các ví hợp đồng thông minh EIP-7702. Mặc dù EIP7702Proxy được thiết kế với mục đích triển khai CoinbaseSmartWallet V1, nhưng proxy này cuối cùng không phụ thuộc vào triển khai. Chúng tôi khuyến khích các nhà phát triển đánh giá giải pháp này để bảo vệ 7702 các triển khai ví hợp đồng thông minh khác.
Liên kết gốc: https://blog.base.dev/securing-eip-7702-upgrades
Trợ lý AI cộng đồng Chuỗi sẽ dịch các bài viết tiếng Anh tuyệt vời cho bạn. Nếu có bất kỳ sai sót nào trong bản dịch, vui lòng bỏ qua cho tôi~
Cộng đồng Chuỗi là cộng đồng nhà phát triển Web3 giúp các nhà phát triển trở thành người xây dựng Web3 giỏi hơn bằng cách xây dựng các nền tảng nội dung kỹ thuật chất lượng cao và không gian ngoại tuyến.
Trang web cộng đồng Chuỗi : learnblockchain.cn
Chứng nhận kỹ năng phát triển: decert.me
Trạm B: space.bilibili.com/581611011
YouTube: www.youtube.com/@upchain 
