Giới thiệu

EIP-7702 cho phép các ví Ethereum đơn giản (EOAs) nâng cấp thành các ví hợp đồng thông minh, cung cấp bảo mật cải tiế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ử, các ví thông minh đã phải được tạo ra từ đầu, nhưng với sự ra mắt của EIP-7702, các ví truyền thống, với tất cả tài sản và lịch sử trên chuỗi của chúng, có thể nâng cấp và giữ nguyên địa chỉ ví. Nó giống như việc chuyển từ điện thoại cố định sang điện thoại thông minh mà không cần phải có số mới.

EOA nâng cấp bằng cách thiết lập một "chỉ định ủy quyền", một con trỏ tới một hợp đồng thông minh deleGate, mà logic của nó sau đó điều khiển EOA. Do đó, EOA được nâng cấp có thể có các chức năng, thiết lập lưu trữ, phát ra sự kiện và làm mọi thứ khác mà một hợp đồng thông minh có thể làm. EOA có thể thay đổi hoặc xóa sự ủy quyền này bất cứ lúc nào với một ủy quyền EIP-7702 mới, đã ký. Trong khi điều này mở ra nhiều khả năng mới, tính năng mạnh mẽ này cũng giới thiệu những thách thức an ninh mới đòi hỏi sự xem xét cẩn thận và các giải pháp sáng tạo.

Để cho phép EOAs hoạt động như ví tiền hợp đồng thông minh, chúng tôi đã phát triển EIP7702Proxy, một giải pháp nhẹ.Proxy ERC-1967 hợp đồng được thiết kế để phục vụ như một deleGate EIP-7702 cho một EOA. Ngoài việc thực hiện chuyển tiếp logic cơ bản được thực hiện bởi một proxy, EIP7702Proxy chứa các tính năng bổ sung và lựa chọn thiết kế giải quyết một số thách thức độc đáo cho các tài khoản được ủy quyền EIP-7702. Một mục tiêu trong việc thiết kế EIP7702Proxy là để cho phép sự tương đương gần nhất có thể giữa các Ví tiền Coinbase Smart Wallet "chuẩn triển khai" và các Ví tiền Coinbase Smart Wallet được ủy quyền EIP-7702, điều này có nghĩa là trừu tượng hóa độ phức tạp bổ sung mà cơ chế của EIP-7702 yêu cầu vào proxy chuyên dụng và tiếp tục dựa vào việc 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 một cách hữu ích cho bất kỳ logic triển khai nào, không chỉ riêng việc triển khai CoinbaseSmartWallet, trong khi giúp các EOA giữ an toàn trong một môi trường được kích hoạt 7702.

Chúng tôi mô tả dưới đây những thách thức cụ thể và 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í tiền hợp đồng thông minh nào hiện có để được sử dụng cho các 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 trong việc triển khai EIP-7702 xuất phát từ các ràng buộc khởi tạo của nó. Các ví tiền thông minh truyền thống, bao gồm CoinbaseSmartWallet, thường xử lý việc 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 của chúng 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 chức năng khởi tạo không được bảo vệ có thể được gọi chính xác một lần. Tuy nhiên, thiết kế của EIP-7702 không cho phép thực hiện dữ liệu khởi tạo trong quá trình ủy quyền mã (bước tương đương với "triển khai") và do đó không thể thực hiện một cách nguyên tử.

Việc tách biệt các bước này tạo ra một khoảng thời gian dễ bị tổn thương quan trọng. Khi một hợp đồng triển khai được "triển khai" tới một EOA thông qua EIP-7702, không có đảm bảo rằng bản nâng cấp 7702 này và giao dịch EVM tiêu chuẩn khởi tạo ví sẽ được thực hiện đồng thời. Mã thiết lập ủy quyền có thể được áp dụng một cách độc lập với giao dịch khởi tạo, ngay cả khi chúng được gửi đồng thời, và điều này có thể cho phép một kẻ tấn công thực hiện trước giao dịch khởi tạo với payload của riêng họ 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 đồng thời triển khai và khởi tạo

Lưu ý rằng các ví tiền thông minh Coinbase hiện có được triển khai ở phía sau một ERC-1967 proxy với một UUPSUpgradeableviệc triển khai (logic của CoinbaseSmartWallet thực tế). Mã tại địa chỉ tài khoản thực tế là một proxy, và proxy sử dụng một vị trí lưu trữ thông thường được định nghĩa bởi ERC-1967 để lưu giữ một con trỏ đế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 ngữ cảnh 7702 liên quan đến việc nhận ra rằng bất kỳ logic triển khai nào chỉ trở nên hoạt động (và do đó nguy hiểm) khi proxy thực sự thiết lập một kết nối với nó. Do đó, nếu chúng tôi không thể thực thi việc triển khai nguyên tử với khởi tạo, chúng tôi có thể thay vào đó thực thi việc thiết lập triển khai nguyên tử với khởi tạo.

Cấu trúc hợp đồng CoinbaseSmartWallet EIP-7702 và luồng ủy quyền logic

Trong bối cảnh của EIP-7702, EOA chính là quyền hạn ban đầu đối với bất kỳ thay đổi nào đối với tài khoản của nó, và phải cung cấp một chữ ký để ủy quyền cho việc khởi tạo và thiết lập bất kỳ chủ sở hữu nào của tài khoản thông minh mới. Hợp đồng EIP7702Proxy của chúng tôi triển khai một hàm setImplementation có thể thiết lập nguyên tử việc thực hiện logic mới và khởi tạo tài khoản. Hàm setImplementation:

1. Xác thực chữ ký từ EOA qua các dữ liệu chính như địa chỉ của hợp đồng triển khai mới, calldata khởi tạo, địa chỉ của hợp đồng xác thực sẽ đánh giá độ an toàn của trạng thái tài khoản kết quả, và các biện pháp bảo vệ lặp lại chữ ký cơ bản như nonce và thời hạn
2. Đặt giá trị của con trỏ ERC-1967 thành triển khai mới và thực thi calldata được cung cấp trên triển khai logic mới.
3. Gọi hàm validateAccountState mà phải được triển khai bởi trình xác thực được bao gồm trong chữ ký.

Validator là một hợp đồng cụ thể cho từng triển khai chứa logic để đánh giá xem nó có coi trạng thái tài khoản kết quả là an toàn hay không. Ví dụ, trong trường hợp của 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 rỗng hay không, và do đó không còn dễ bị khởi tạo tùy ý.

Thử thách #2: Lưu trữ chia sẻ giữa các deleGates 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 ủy quyền lại logic của nó cho các hợp đồng khác nhau, hoặc hoàn toàn xóa bỏ ủy quyền bất cứ lúc nào. Tất cả các ủy quyền chia sẻ cùng một không gian lưu trữ tại địa chỉ EOA. Nhiều hợp đồng chia sẻ quyền truy cập vào cùng một lưu trữ theo thời gian có thể dẫn đến vấn đề "va chạm lưu trữ". Va chạm lưu trữ xảy ra khi hai hợp đồng thực hiện những thay đổi khác nhau hoặc có những giả định khác nhau về cùng một vị trí lưu trữ, có thể dẫn đến các lỗi không thể đoán trước.

Quản lý các va chạm lưu trữ đã là một vấn đề quen thuộc trong không gian thiết kế proxy, nơi mà logic thực hiện có thể thay đổi được sử dụng để quản lý lưu trữ chia sẻ. Mặc dù các proxy có thể nâng cấp có thể thay đổi các thực hiện, nhưng mã proxy tự nó (đối với các địa chỉ không phải 7702) không thể thay đổi. Điều này mang lại sự chắc chắn và đảm bảo cho quá trình nâng cấp. Việc ủy quyền lại 7702 giới thiệu một lớp tính khả biến tổng thể khác cho logic tiềm năng có thể quản lý lưu trữ chia sẻ này. Điều này về cơ bản loại bỏ bất kỳ đảm bảo nào về hiệu ứng mà một deleGate tùy ý có thể có trên lưu trữ. Ví dụ, nếu một EOA ủy quyền từ deleGate A sang B và quay trở lại A thì deleGate quay trở lại không thể đưa ra giả định nào về trạng thái của lưu trữ của nó, mà có thể đã bị xóa hoặc thao tác bởi deleGate B thành một trạng thái mà sẽ là không thể đạt được chỉ qua logic của deleGate A. Điều này đúng với bất kỳ deleGate 7702 nào, bất kể mẫu ủy quyền, vì một deleGate trước đó có thể đã lưu trữ hoặc xóa bất cứ điều gì ở bất kỳ vị trí lưu trữ nào.

Ví dụ về một trạng thái không hợp lệ cho DeleGate A do mô hình ủy quyền A → B → A gây ra

Giải pháp: Ngoại hóa các giá trị lưu trữ quan trọng về bảo mật

Việc ủy quyền EOA có thể ảnh hưởng tùy ý đến trạng thái tài khoản. Nếu một EOA ủy quyền cho một hợp đồng độc hại hoặc phá hoại, không có ủy quyền hiện tại nào có thể bảo vệ chống lại điều này. Giống như việc ký một giao dịch rút tiền, việc ủy quyền cho các ủy quyền độc hại 7702 có thể gây hại, 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ệ chống lại những vấn đề có thể dự đoán trong một hệ sinh thái đa ví, được kích hoạt 7702, với các tác nhân có ý định tốt nhưng có thể gây ra hỗn loạn. Nó không thể bảo vệ các EOA mà ủy quyền cho các deleGates thực sự độc hại hoặc có lỗi.

Một vấn đề có thể dự đoán được liên quan đến chữ ký cho các cuộc gọi setImplementation và những rủi ro do trạng thái tài khoản có thể thay đổi gây ra. EIP7702Proxy phụ thuộc vào chữ ký EOA để thiết lập logic triển khai và khởi tạo về một trạng thái an toàn. Những chữ ký này có thể trở thành gánh nặng nếu chúng có thể bị phát lại. Ví dụ, nếu một chữ ký ủy quyền cho một chủ sở hữu ban đầu sau đó bị xâm phạm và bị loại bỏ, một chữ ký có thể phát lại có thể khôi phục chủ sở hữu bị xâm phạm hoặc buộc phải hạ cấp triển khai.

Biện pháp bảo vệ phổ biến chống lại việc phát lại chữ ký sử dụng nonces trong các thông điệp đã ký, được đánh dấu là đã sử dụng khi được xác minh. Rủi ro cho các tài khoản 7702: các deleGates khác có thể làm tổn hại đến bộ nhớ theo dõi nonce này. Nếu bộ nhớ theo dõi việc sử dụng nonce 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 quay lại EIP7702Proxy.

Để đảm bảo tính không thể phát lại của chữ ký, chúng tôi đã triển khai một singleton NonceTracker riêng biệt, giữ trạng thái nonce ở một vị trí hợp đồng không thay đổi bên ngoài bộ nhớ của tài khoản. Chỉ có EOA mới có thể ảnh hưởng đến các nonce của họ (chỉ tăng dần), ngăn chặn các deleGates khác thao tác với các giá trị quan trọng về mặt 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ể sự thay đổi nào trong bộ nhớ tài khoản.

Thách thức #3: Tăng cường rủi ro từ các vị trí lưu trữ thông thường được chia sẻ

Các khe lưu trữ chuẩn hóa như những khe được định nghĩa bởi ERC-1967có thể đặc biệt dễ bị tổn thương trước các va chạm lưu trữ tiềm năng do là những vị trí thông thường có khả năng được sử dụng bởi nhiều triển khai deleGate. Khe lưu trữ triển khai ERC-1967 là vị trí lưu trữ tiêu chuẩn duy nhất được sử dụng trong EIP7702Proxy và nó giữ địa chỉ của triển khai logic được chỉ định bởi proxy. Thiết kế của chúng tôi đảm bảo rằng bất kể giá trị tại vị trí lưu trữ này (điều này xác định nhiều logic có sẵn tại tài khoản), EIP7702Proxy sẽ luôn có khả năng thành công trong việc đặt logic triển khai của nó thành một hợp đồng mà EOA mong muốn.

Để minh họa rõ ràng hơn về 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 deleGate khác nhau (A→B→A) nơi cả hai deleGate đều triển khai các mẫu proxy ERC-1967, deleGate B sẽ tự nhiên sử dụng cùng một ô lưu trữ mà deleGate A đã sử dụng để lưu trữ địa chỉ triển khai của nó. Trong thời gian của mình, deleGate B có thể sửa đổi hoặc ghi đè ô này, có thể là cố ý hoặc như một phần bình thường trong các hoạt động proxy của chính nó. Trong một mẫu proxy UUPSUpgradeable, logic để nâng cấp một triển khai được xác định trên hợp đồng triển khai chính nó. Nếu triển khai được đưa vào vị trí con trỏ này bởi deleGate B không chứa giao diện upgradeToAndCall mà một triển khai mong đợi, thì khi trở lại deleGate A, cơ chế để thay đổi triển khai của nó có thể không tồn tại trên logic hiện có.

Ví dụ về việc ghi đè vị trí lưu trữ thông thường chia sẻ bằng deleGate mới

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 chức năng setImplementation, 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 deleGate can thiệp đã chỉ định triển khai ERC-1967 vào một triển khai không hợp lệ (hoặc loại bỏ hoàn toàn), EOA ban đầu, sau khi ủy quyền trở lại EIP7702Proxy, vẫn duy trì khả năng cấu hình lại con trỏ ERC-1967 của proxy đến triển khai logic mà họ đã chọn.

Thách thức #4: Tính tương thích ngược với hành vi EOA tiêu chuẩn

Một 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 bên cạnh chức năng hợp đồng thông minh mới. Sự hiện diện hoặc vắng mặt của mã tại một địa chỉ có thể ả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 dựa vào đặc điểm này để phân biệt giữa EOAs và hợp đồng thông minh. Điều này yêu cầu phải xem xét hai hành vi chính: xác minh chữ ký và hành vi nhận token.

Xác minh chữ ký

Hợp đồng thông minh có một tiêu chuẩn khác cho việc xác thực chữ ký so với các EOA tiêu chuẩn. Hợp đồng thông minh triển khai giao diện isValidSignature được định nghĩa bởi ERC-1271 và có quyền tự do xác định logic tùy ý để xác định xem hợp đồng có coi một chữ ký là hợp lệ hay không. Đối với các EOA tiêu chuẩn, một chữ ký được xác thực bằng kiểm tra ecrecover tiêu chuẩn đảm bảo người ký phục hồi đến địa chỉ EOA mong đợi.

Để đảm bảo rằng các chữ ký EOA hiện có hoặc tương lai sẽ tiếp tục được tôn trọng tại EOA sau khi nâng cấp 7702, EIP7702Proxy triển khai một phiên bản của isValidSignature mà đầu tiên ủy quyền xác thực chữ ký cho hàm isValidSignature mà nên được định nghĩa trên việc triển khai logic, nhưng theo sau một lần xác thực không thành công với một kiểm tra ecrecover cuối cùng. Nếu điều này thành công, chữ ký được coi là 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 tôn trọng tại địa chỉ của họ bất kể việc triển khai isValidSignature của ví hợp đồng thông minh của họ.

Biên nhận token

Một số tiêu chuẩn token (cụ thể là ERC-1155 và ERC-721) cố gắng bảo vệ chống lại việc token bị mắc kẹt trong các hợp đồng thông minh mà có thể không có khả năng quản lý chúng. Những token này yêu cầu bất kỳ hợp đồng thông minh nào sẽ nhận những token như vậy phải tuyên bố khả năng này bằng cách triển khai các giao diện nhận token tiêu chuẩn mà được gọi bởi hợp đồng token trong quá trình gửi token. Cũng cần thiết rằng logic tại EOA đã được nâng cấp chứa một hàm nhận tiêu chuẩn hoặc fallback có thể nhận token gốc. Một tài khoản không bao giờ nên ở trong trạng thái khiến nó không thể nhận ETH hoặc các token khác, dù chỉ trong thời gian ngắn.

Vì proxy của chúng tôi thiếu một triển khai ban đầu, chúng tôi bao gồm một triển khai DefaultReceiver không thay đổi như là logic mặc định cho EIP7702Proxy trong trường hợp không có con trỏ ERC-1967. Bộ nhận này triển khai một chức năng nhận và các móc nhận cho các tiêu chuẩn token phổ biến này, đảm bảo rằng tài khoản có thể chấp nhận chuyển token trước khi thiết lập một triển khai mới một cách rõ ràng.

Kết luận

Thiết kế EIP7702Proxy cho phép chúng tôi duy trì sự tương đồng gần gũi với các Ví tiền CoinbaseSmartWallet được triển khai tiêu chuẩn và tiếp tục sử dụng việc thực hiện 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 EIP-7702. Bằng cách xem xét cẩn thận bảo mật khởi tạo, những hệ quả của sự không ổn định trong lưu trữ và can thiệp, 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 việc xác minh chữ ký EOA tiêu chuẩn, chúng tôi đã tạo ra một proxy để ủy quyền và quản lý các Ví tiền hợp đồng thông minh EIP-7702 một cách an toàn. Trong khi EIP7702Proxy được thiết kế với việc thực hiện CoinbaseSmartWallet V1 trong tâm trí, proxy này cuối cùng là không phụ thuộc vào việc thực hiện. Chúng tôi khuyến khích các nhà phát triển đánh giá giải pháp này để tăng cường bảo mật cho các thực hiện Ví tiền hợp đồng thông minh khác.

Tuyên bố miễn trừ trách nhiệm:

1. Bài viết này được đăng lại từ [Blog Kỹ Thuật Cơ Sở]. Tất cả bản quyền thuộc về tác giả gốc [Amie Corso]. Nếu có ý kiến phản đối đối với việc in lại này, vui lòng liên hệ với Gate Learnđội ngũ, và họ sẽ xử lý nó một cách nhanh chóng.
2. Tuyên bố miễn trách nhiệm: Quan điểm và ý kiến ​​được bày tỏ trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi đội ngũ Gate Learn. Trừ khi có đề cập, việc sao chép, phân phối hoặc ăn cắp nội dung của các bài viết đã dịch là bị cấm.