Account Abstraction (AA) là một hướng quan trọng của việc khám phá dài hạn trong hệ sinh thái Ethereum, nhằm phá vỡ ranh giới giữa tài khoản bên ngoài (EOA) và tài khoản hợp đồng, để ví có khả năng lập trình, bảo mật và khả năng nâng cấp mạnh mẽ hơn. EIP-4337, là giải pháp triển khai AA chính thống nhất, đã được sử dụng rộng rãi trong một số ví hợp đồng thông minh dựa trên EntryPoint (chẳng hạn như Safe, Stacks và Argent). Tuy nhiên, EIP-4337 vẫn có những hạn chế nhất định về tính gốc trên chuỗi, độ phức tạp hoạt động và khả năng tương thích sinh thái do giới thiệu một nhóm giao dịch độc lập và cơ chế hợp đồng trên đường dốc.
Để giảm thêm rào cản sử dụng trừu tượng tài khoản và tăng cường hỗ trợ nguyên bản của nó, Vitalik đã đề xuất EIP-7702 vào năm 2024 và đưa ra đề xuất này trong bản nâng cấp Pectra. Ý tưởng cốt lõi của EIP-7702 là: cho phép một EOA ban đầu khi khởi xướng giao dịch, cho phép thực thi mã hợp đồng (contract_code) của địa chỉ chỉ định, qua đó định nghĩa logic thực thi của giao dịch đó.
EIP-7702 giới thiệu một cơ chế mới của "chèn mã cấp giao dịch", cho phép tài khoản người dùng tự động chỉ định logic thực thi trong mỗi giao dịch, thay vì dựa vào mã hợp đồng được triển khai trước. Điều này phá vỡ mô hình quyền dựa trên mã tĩnh truyền thống, mang lại sự linh hoạt cao hơn và đưa ra những thách thức bảo mật mới: các hợp đồng dựa trên logic phán đoán như isContract và extcodehash có thể trở nên không hợp lệ và một số hệ thống giả định rằng người gọi là EOA thuần túy có thể bị bỏ qua. Đối với kiểm toán viên, điều quan trọng không chỉ là xác minh tính bảo mật của chính mã được chèn mà còn đánh giá tác động tiềm ẩn của nó đối với các hệ thống hợp đồng khác trong bối cảnh động.
Bài viết này, đội ngũ an ninh Beosin sẽ hệ thống hóa các rủi ro an ninh có thể gặp phải trong quá trình kiểm toán của ví AA được xây dựng dựa trên nguyên lý thiết kế và các đặc điểm chính của EIP-7702, đồng thời đề xuất quy trình và khuyến nghị kiểm toán từ góc nhìn thực chiến, giúp các nhà nghiên cứu an ninh đối phó tốt hơn với các thách thức kỹ thuật trong một mô hình hoàn toàn mới.
Một, Giới thiệu EIP-7702
Tóm tắt kỹ thuật EIP-7702
EIP-7702 đã giới thiệu một loại giao dịch mới 0x04 (SetCode), cho phép EOA ủy quyền mã hợp đồng cần thực hiện thông qua giao dịch này, cấu trúc giao dịch như sau:
Trong đó, authorization_list bao gồm nhiều danh sách ủy quyền, cũng có thể bao gồm hành vi ủy quyền của những người không phải là người khởi xướng giao dịch, cấu trúc bên trong là:
trong đó chain_id đại diện cho chuỗi trong đó ủy quyền của người dùng có hiệu lực và giá trị của nó phải bằng ID chuỗi của chuỗi thực thi hoặc là 0. Khi chain_id là 0, ủy quyền có hiệu lực trên tất cả các chuỗi EVM hỗ trợ EIP-7702, nhưng chỉ khi các tham số khác (chẳng hạn như nonce) khớp. địa chỉ cho biết địa chỉ hợp đồng mục tiêu được người dùng ủy quyền.
Sau khi ủy quyền hoàn tất, hệ thống sẽ sửa đổi trường code của người dùng được ủy quyền thành 0xef0100 || địa chỉ, trong đó địa chỉ chính là địa chỉ hợp đồng được ủy quyền. Nếu muốn hủy ủy quyền, chỉ cần thực hiện một giao dịch SetCode để đặt địa chỉ thành địa chỉ 0.
Ưu điểm của EIP7702
(1) Linh hoạt và tùy chỉnh
Tài khoản trừu tượng có thể tùy chỉnh linh hoạt các chức năng theo nhu cầu bằng cách viết logic tài khoản vào hợp đồng thông minh. Ví dụ, người dùng có thể cấu hình chữ ký đa chữ ký, khôi phục xã hội, kiểm soát hạn mức, v.v., đáp ứng nhu cầu của cá nhân hoặc doanh nghiệp trong các tình huống khác nhau. Thiết kế này nâng cao đáng kể khả năng mở rộng chức năng của tài khoản, vượt qua giới hạn của tài khoản bên ngoài truyền thống (EOA).
(2) Tăng cường an ninh
Tài khoản trừu tượng cung cấp nhiều cơ chế bảo mật, bao gồm xác thực đa yếu tố, giới hạn giao dịch và khôi phục xã hội. Ngay cả khi người dùng mất khóa riêng, họ vẫn có thể khôi phục tài khoản thông qua người liên hệ tin cậy hoặc xác thực đa yếu tố, tránh được việc mất tài sản vĩnh viễn do mất khóa riêng trong các tài khoản truyền thống. Đồng thời, các chức năng như kiểm soát giới hạn cũng có thể ngăn chặn việc rút tiền lớn một cách ác ý.
(3) Gas tối ưu hóa
Tài khoản trừu tượng hỗ trợ cơ chế trừu tượng Gas linh hoạt, cho phép người dùng thanh toán Gas qua bên thứ ba, thậm chí trực tiếp sử dụng các token khác để thanh toán phí giao dịch. Cơ chế này không chỉ giảm chi phí hoạt động của người dùng mà còn đơn giản hóa quy trình sử dụng blockchain, đặc biệt phù hợp với người mới bắt đầu hoặc các tình huống giao dịch nhiều bước phức tạp.
( Thúc đẩy sự phổ biến của Web3
Bằng cách tối ưu hóa trải nghiệm và tính bảo mật, tài khoản trừu tượng ẩn đi sự phức tạp của blockchain ở những nơi người dùng không nhìn thấy, cung cấp các thao tác tiện lợi gần gũi hơn với Web2. Thiết kế này giảm chi phí học tập cho người dùng bình thường, cho phép nhiều người tham gia vào các ứng dụng Web3 mà không gặp trở ngại, thúc đẩy sự phổ biến của công nghệ phi tập trung.
Hai, Phân tích rủi ro an ninh trong thực tiễn của EIP-7702
Mặc dù EIP-7702 đã mang lại động lực mới cho hệ sinh thái Ethereum và mở rộng các tình huống ứng dụng phong phú, nhưng đồng thời, nó cũng không thể tránh khỏi việc mang lại một số rủi ro an ninh mới:
Tấn công tái phát quyền
Dưới mô hình EIP-7702, nếu người dùng đặt trường chain_id trong ủy quyền thành 0, điều đó có nghĩa là ủy quyền này có thể có hiệu lực trên nhiều chuỗi. Thiết kế "ủy quyền đa chuỗi" này mặc dù nâng cao tính linh hoạt trong một số tình huống, nhưng đồng thời cũng mang lại những rủi ro an ninh rõ rệt.
Cần lưu ý rằng, ngay cả khi cùng một địa chỉ có cùng định danh tài khoản trên các chuỗi khác nhau, việc thực hiện hợp đồng đứng sau có thể hoàn toàn khác nhau. Điều này có nghĩa là, kẻ tấn công có thể triển khai một phiên bản hợp đồng độc hại trên một chuỗi khác, lợi dụng hành vi ủy quyền của cùng một địa chỉ trên chuỗi để thực hiện các thao tác không mong muốn, từ đó gây ra rủi ro cho tài sản của người dùng.
Do đó, đối với các nhà cung cấp dịch vụ ví hoặc nền tảng tương tác front-end, khi người dùng thực hiện các thao tác ủy quyền như vậy, họ cần xác minh rõ ràng liệu chainId được khai báo trong ủy quyền của người dùng có phù hợp với mạng kết nối hiện tại hay không; Nếu người dùng được phát hiện đặt chainId thành 0, cần đưa ra cảnh báo rủi ro rõ ràng để nhắc nhở người dùng rằng ủy quyền sẽ có hiệu lực trên tất cả các chuỗi tương thích với EVM và có thể bị lạm dụng bởi các hợp đồng độc hại.
Ngoài ra, bên cung cấp dịch vụ cũng nên đánh giá xem có nên mặc định giới hạn hoặc cấm chainId là 0 trong tầng UI hay không, để giảm thiểu rủi ro do thao tác sai hoặc tấn công lừa đảo.
Vấn đề tương thích hợp đồng
)1( Tính tương thích callback hợp đồng
Các hợp đồng token hiện có như ERC-721, ERC-777, ERC1155 khi chuyển tiền đến địa chỉ hợp đồng sẽ gọi các giao diện callback tiêu chuẩn (như onERC721Received, tokensReceived) để hoàn tất thao tác chuyển tiền. Nếu địa chỉ nhận không thực thi giao diện tương ứng, việc chuyển tiền sẽ thất bại thậm chí dẫn đến việc tài sản bị khóa.
Trong EIP-7702, địa chỉ người dùng có thể được gán mã hợp đồng thông qua thao tác "set_code", từ đó chuyển đổi thành tài khoản hợp đồng. Lúc này:
Địa chỉ người dùng sẽ được coi là hợp đồng;
Nếu hợp đồng không thực hiện các giao diện callback cần thiết, sẽ dẫn đến việc chuyển token thất bại;
Người dùng có thể không nhận được các đồng tiền chính thống mà không biết.
Do đó, các nhà phát triển nên đảm bảo rằng các hợp đồng mục tiêu mà người dùng ủy quyền thực hiện các giao diện callback liên quan để đảm bảo tính tương thích với các token chính.
)2( Kiểm tra "tx.origin" không còn hiệu lực
Trong hợp đồng truyền thống, "tx.origin" thường được sử dụng để xác định xem giao dịch có phải do người dùng khởi xướng trực tiếp hay không, nhằm ngăn chặn việc gọi hợp đồng và các kiểm soát an toàn khác.
Nhưng trong bối cảnh EIP-7702:
Người dùng ký kết giao dịch ủy quyền, thực tế được phát sóng bởi bộ trung gian hoặc dịch vụ gói (bundler); khi giao dịch được thực hiện, "tx.origin" là địa chỉ của bộ trung gian, không phải địa chỉ của người dùng.
「msg.sender」 là hợp đồng ví đại diện cho danh tính người dùng.
Do đó, việc xác thực quyền dựa trên "tx.origin == msg.sender" sẽ dẫn đến việc từ chối thao tác của người dùng hợp pháp, mất đi tính đáng tin cậy, tương tự như việc sử dụng các giới hạn gọi hợp đồng như "tx.origin == user" cũng sẽ không còn hiệu lực. Đề nghị bỏ sử dụng "tx.origin" làm cơ sở đánh giá an toàn, thay vào đó sử dụng xác thực chữ ký hoặc cơ chế ủy quyền.
)3( "isContract" phán đoán sai
Nhiều hợp đồng sử dụng 「isContract )address(」 (kiểm tra độ dài mã địa chỉ) để ngăn chặn tài khoản hợp đồng tham gia vào một số hoạt động nhất định, chẳng hạn như airdrop, mua sắm chớp nhoáng, v.v:
Dưới cơ chế EIP-7702, địa chỉ người dùng có thể trở thành tài khoản hợp đồng thông qua giao dịch "set_code", "isContract" trả về true, hợp đồng sẽ nhầm lẫn người dùng hợp pháp thành tài khoản hợp đồng, từ chối họ tham gia hoạt động, dẫn đến việc người dùng không thể sử dụng một số dịch vụ, trải nghiệm bị cản trở.
Với việc ví hợp đồng ngày càng phổ biến, thiết kế dựa vào "isContract" để xác định "có phải là người dùng hay không" đã không còn an toàn, khuyên nên sử dụng các phương thức nhận diện người dùng chính xác hơn như xác minh chữ ký.
Tấn công lừa đảo
Sau khi triển khai cơ chế ủy thác EIP-7702, tài sản trong tài khoản người dùng sẽ hoàn toàn nằm dưới sự kiểm soát của hợp đồng thông minh được ủy thác. Một khi người dùng ủy quyền cho hợp đồng độc hại, kẻ tấn công có thể lợi dụng điều này để có quyền kiểm soát hoàn toàn tài sản trong tài khoản, dẫn đến việc tiền có thể bị chuyển nhanh chóng hoặc đánh cắp, rủi ro an ninh rất cao.
Do đó, điều quan trọng là các nhà cung cấp dịch vụ ví phải hỗ trợ cơ chế giải quyết giao dịch và xác định rủi ro EIP-7702 càng sớm càng tốt. Khi người dùng ký giao dịch ủy thác, giao diện người dùng nên hiển thị rõ ràng và nổi bật địa chỉ hợp đồng mục tiêu, đồng thời kết hợp các thông tin hỗ trợ như nguồn hợp đồng và thông tin triển khai để giúp người dùng xác định các hành vi lừa đảo hoặc gian lận tiềm ẩn, từ đó giảm nguy cơ ký sai. Hơn nữa, dịch vụ ví nên tích hợp các khả năng phân tích bảo mật tự động cho hợp đồng mục tiêu, chẳng hạn như kiểm tra trạng thái mã nguồn mở mã hợp đồng, phân tích mô hình quyền và xác định hoạt động nguy hiểm tiềm ẩn, để giúp người dùng đưa ra phán đoán an toàn hơn trước khi ủy quyền.
Cần đặc biệt lưu ý rằng định dạng chữ ký ủy quyền được giới thiệu bởi EIP-7702 không tương thích với các tiêu chuẩn chữ ký hiện có EIP-191 và EIP-712. Chữ ký này rất dễ vượt qua cảnh báo chữ ký và nhắc nhở tương tác ban đầu của ví, làm tăng thêm nguy cơ người dùng bị lừa ký vào các hoạt động độc hại. Do đó, việc giới thiệu cơ chế nhận diện và xử lý cấu trúc chữ ký này trong việc thực hiện ví sẽ là một khía cạnh quan trọng để bảo đảm an toàn cho người dùng.
Rủi ro hợp đồng ví
)1( Quản lý quyền hợp đồng ví
Nhiều hợp đồng ví EIP-7702 áp dụng kiến trúc đại lý ) hoặc quyền quản lý tích hợp ( để hỗ trợ nâng cấp logic. Tuy nhiên, điều này cũng mang lại rủi ro quản lý quyền cao hơn. Nếu quyền nâng cấp không được hạn chế nghiêm ngặt, kẻ tấn công có thể thay thế hợp đồng thực hiện và tiêm mã độc, dẫn đến tài khoản người dùng bị sửa đổi hoặc tiền bị đánh cắp.
Lời khuyên an toàn:
Sử dụng chữ ký đa dạng, xác thực nhiều yếu tố hoặc cơ chế khóa thời gian để kiểm soát quyền nâng cấp.
Mọi thay đổi về mã và quyền phải trải qua kiểm toán nghiêm ngặt và xác thực an toàn.
Quy trình nâng cấp công khai minh bạch, đảm bảo quyền biết và quyền tham gia của người dùng.
)2( Rủi ro xung đột lưu trữ và cách ly dữ liệu
Các phiên bản hợp đồng ví hoặc các nhà cung cấp ví khác nhau có thể sử dụng lại cùng một vùng lưu trữ. Nếu người dùng thay đổi nhà cung cấp dịch vụ ví hoặc nâng cấp logic ví, việc sử dụng lại khe lưu trữ sẽ khiến biến trạng thái xung đột và sẽ có các vấn đề như ghi đè dữ liệu và đọc ngoại lệ. Điều này không chỉ có thể làm gián đoạn hoạt động bình thường của ví mà còn có thể dẫn đến mất tiền hoặc các quyền bất thường.
Lời khuyên an toàn:
Sử dụng giải pháp tách biệt lưu trữ chuyên dụng (như tiêu chuẩn EIP-1967) hoặc tận dụng không gian tên duy nhất để quản lý các khe lưu trữ.
Khi nâng cấp hợp đồng, hãy đảm bảo bố cục lưu trữ tương thích để tránh sự chồng chéo của các biến.
Kiểm tra tính hợp lý của trạng thái lưu trữ trong quy trình nâng cấp nghiêm ngặt.
)3( Quản lý nonce bên trong ví
Hợp đồng ví thường được thiết lập nonce bên trong và tự quản lý để đảm bảo thứ tự thực hiện của các thao tác của người dùng và ngăn chặn tấn công phát lại. Nếu nonce được sử dụng không đúng cách, sẽ dẫn đến việc thao tác của người dùng không thể được thực hiện bình thường.
Lời khuyên an toàn:
nonce phải được kiểm tra giá trị bằng (hoặc tăng dần), không được bỏ qua.
Cấm hàm trực tiếp sửa đổi nonce, chỉ có thể được cập nhật nonce khi người dùng thực hiện thao tác.
Thiết kế cơ chế chịu lỗi và phục hồi cho các tình huống bất thường nonce, tránh tình trạng deadlock nonce.
)4( Kiểm tra quyền gọi hàm
Để đảm bảo an toàn, hợp đồng ví phải đảm bảo rằng người gọi các hàm quan trọng là tài khoản sở hữu ví. Hai cách phổ biến bao gồm:
ủy quyền ký ngoài chuỗi
Người dùng ký một tập hợp các thao tác bằng khóa riêng, hợp đồng ví xác minh tính hợp lệ của chữ ký trên chuỗi, kiểm tra xem chữ ký có hết hạn hay không, và có đáp ứng nonce tương ứng hay không. Cách này áp dụng cho mô hình giao dịch trung gian mà EIP-7702 khuyến nghị (người dùng ký ngoại tuyến + trung gian phát giao dịch).
Gọi ràng buộc (msg.sender == địa chỉ )this()
Hàm thao tác của người dùng chỉ cho phép được gọi bởi chính hợp đồng, về bản chất là một cơ chế kiểm soát đường dẫn gọi, đảm bảo rằng người khởi xướng bên ngoài phải là chính tài khoản đó. Điều này thực sự tương đương với việc yêu cầu người gọi phải là EOA gốc, vì lúc này địa chỉ hợp đồng chính là địa chỉ EOA.
Ba, Triển vọng: EIP-7702 và tiêu chuẩn ví AA trong tương lai
Việc đề xuất EIP-7702 không chỉ là một cuộc cách mạng đối với mô hình tài khoản truyền thống, mà còn là một bước thúc đẩy lớn cho hệ sinh thái trừu tượng tài khoản (Account Abstraction). Khả năng mà nó đưa ra cho người dùng để tải mã hợp đồng đã mở ra không gian khám phá rộng lớn cho thiết kế ví và hệ thống hợp đồng trong tương lai, đồng thời cũng đặt ra những yêu cầu mới đối với tiêu chuẩn kiểm toán an toàn.
Sự tiến hóa phối hợp với EIP-4337: Hướng tới tính tương thích kép
Mặc dù EIP-7702 và EIP-4337 có mục tiêu thiết kế khác nhau, cái trước tái cấu trúc cơ chế tải mã tài khoản, cái sau xây dựng một cổng giao dịch hoàn chỉnh và hệ sinh thái đóng gói. Nhưng hai cái này không mâu thuẫn, mà ngược lại, có tính bổ trợ rất mạnh.
EIP-4337 cung cấp "Kênh giao dịch chung" và "Giao diện thực thi tài khoản trừu tượng";
EIP-7702 cho phép tài khoản người dùng cấp khả năng logic hợp đồng một cách linh hoạt mà không cần thay đổi địa chỉ.
Do đó, ví trong tương lai có thể áp dụng "kiến trúc hỗ trợ kép": sử dụng EIP-7702 như một phương án thay thế nhẹ nhàng trên các chuỗi không hỗ trợ EIP-4337, trong khi tiếp tục dựa vào ngăn xếp giao thức đầy đủ của EIP-4337 trong các tình huống cần đóng gói ngoài chuỗi và tập hợp nhiều người dùng.
Cơ chế hai chế độ này cũng sẽ thúc đẩy ví hỗ trợ mô hình quyền hạn tài khoản linh hoạt hơn, cơ chế hạ cấp và kế hoạch quay lại ở cấp lõi.
Hỗ trợ và cảm hứng từ logic ví mới như MPC, ZK
Cơ chế hợp đồng hóa tài khoản được EIP-7702 đề xuất có tiềm năng tích hợp tự nhiên với các kiến trúc mới như ví MPC, ví ZK, ví mô-đun đang phổ biến hiện nay:
Trong mô hình MPC, hành vi chữ ký không còn dựa vào một khóa riêng duy nhất mà là một quyết định hợp tác được đưa ra bởi nhiều bên. Chữ ký được tạo ra thông qua sự hội tụ của EIP-7702 và MPC kiểm soát logic hợp đồng được tải động, cho phép các chiến lược thực hiện linh hoạt hơn.
Ví ZK xác minh danh tính hoặc quyền truy cập của người dùng thông qua chứng minh không kiến thức mà không cần tiết lộ thông tin khóa cá nhân. Kết hợp với EIP-7702, ví ZK có thể tạm thời tiêm hợp đồng logic cụ thể sau khi xác minh hoàn tất, từ đó thực hiện việc triển khai hành vi cá nhân hóa sau khi tính toán riêng tư, chẳng hạn như tự động thực hiện một logic nào đó chỉ khi đáp ứng một số điều kiện riêng tư nhất định.
Ví mô-đun (Modular Wallets) có thể sử dụng EIP-7702 để tách biệt logic tài khoản thành nhiều mô-đun, được tải động khi cần.
Do đó, EIP-7702 cung cấp một "container thực thi" gốc hơn cho ví tiên tiến nêu trên: địa chỉ người dùng không thay đổi có thể tiêm logic hợp đồng khác nhau, tránh vấn đề phụ thuộc vào địa chỉ trong quá trình triển khai hợp đồng truyền thống, và cũng không cần phải triển khai trước, từ đó nâng cao đáng kể tính linh hoạt và khả năng kết hợp của hành vi tài khoản.
Những gợi ý cho các nhà phát triển hợp đồng và kiểm toán viên
EIP-7702 sẽ thúc đẩy một sự thay đổi sâu sắc trong mô hình phát triển. Các nhà phát triển hợp đồng không còn đơn giản coi người gọi như một EOA truyền thống hoặc một tài khoản hợp đồng cố định, mà phải thích ứng với một cơ chế mới: danh tính của người gọi có thể được chuyển đổi động giữa EOA và trạng thái hợp đồng trong quá trình giao dịch và logic hành vi tài khoản không còn được củng cố tĩnh mà có thể được thay đổi linh hoạt theo nhu cầu. Điều này yêu cầu các nhà phát triển và kiểm toán viên:
Giới thiệu logic xác thực caller và đánh giá quyền nghiêm ngặt hơn;
Kiểm tra xem đường gọi có bị ảnh hưởng bởi logic hợp đồng động hay không;
Nhận diện các điểm yếu tiềm ẩn của hành vi như msg.sender.code.length == 0, isContract )(;
Rõ ràng về logic hợp đồng "phụ thuộc vào ngữ cảnh", chẳng hạn như kiểm soát biên giới của cuộc gọi tĩnh, deleGatecall;
Hỗ trợ mô phỏng và phân tích khôi phục các tình huống setCode ở cấp độ chuỗi công cụ.
Nói cách khác, tính bảo mật của mã không còn chỉ là "vấn đề trước khi triển khai", mà đã trở thành "quá trình động cần phải xác minh trong khi gọi và giao dịch".
Bốn, tóm tắt
EIP-7702 giới thiệu việc triển khai Trừu tượng hóa tài khoản (AA) nhẹ hơn, gốc và linh hoạt, cho phép EOA thông thường mang logic hợp đồng và thực hiện nó trong một giao dịch duy nhất. Cơ chế này phá vỡ các giả định tĩnh truyền thống về hành vi tài khoản và các nhà phát triển không còn có thể chỉ đơn giản dựa vào trạng thái mã của địa chỉ tài khoản để đánh giá mô hình hành vi của nó, mà cần xây dựng lại sự hiểu biết về ranh giới danh tính và thẩm quyền của người gọi. Cùng với đó là sự thay đổi mô hình trong phân tích bảo mật. Trọng tâm của kiểm toán không còn giới hạn ở "liệu một địa chỉ có quyền hay không", mà chuyển sang "những gì logic hợp đồng được thực hiện trong giao dịch có thể làm trong bối cảnh hiện tại". Mỗi giao dịch có thể mang một định nghĩa độc lập về hành vi, điều này mang lại cho tài khoản chức năng lớn hơn và đưa ra các yêu cầu cao hơn đối với kiểm tra bảo mật.
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Beosin: Phân tích an ninh kiểm toán ví tiền AA thế hệ tiếp theo EIP-7702
Tác giả: Beosin
Account Abstraction (AA) là một hướng quan trọng của việc khám phá dài hạn trong hệ sinh thái Ethereum, nhằm phá vỡ ranh giới giữa tài khoản bên ngoài (EOA) và tài khoản hợp đồng, để ví có khả năng lập trình, bảo mật và khả năng nâng cấp mạnh mẽ hơn. EIP-4337, là giải pháp triển khai AA chính thống nhất, đã được sử dụng rộng rãi trong một số ví hợp đồng thông minh dựa trên EntryPoint (chẳng hạn như Safe, Stacks và Argent). Tuy nhiên, EIP-4337 vẫn có những hạn chế nhất định về tính gốc trên chuỗi, độ phức tạp hoạt động và khả năng tương thích sinh thái do giới thiệu một nhóm giao dịch độc lập và cơ chế hợp đồng trên đường dốc.
Để giảm thêm rào cản sử dụng trừu tượng tài khoản và tăng cường hỗ trợ nguyên bản của nó, Vitalik đã đề xuất EIP-7702 vào năm 2024 và đưa ra đề xuất này trong bản nâng cấp Pectra. Ý tưởng cốt lõi của EIP-7702 là: cho phép một EOA ban đầu khi khởi xướng giao dịch, cho phép thực thi mã hợp đồng (contract_code) của địa chỉ chỉ định, qua đó định nghĩa logic thực thi của giao dịch đó.
EIP-7702 giới thiệu một cơ chế mới của "chèn mã cấp giao dịch", cho phép tài khoản người dùng tự động chỉ định logic thực thi trong mỗi giao dịch, thay vì dựa vào mã hợp đồng được triển khai trước. Điều này phá vỡ mô hình quyền dựa trên mã tĩnh truyền thống, mang lại sự linh hoạt cao hơn và đưa ra những thách thức bảo mật mới: các hợp đồng dựa trên logic phán đoán như isContract và extcodehash có thể trở nên không hợp lệ và một số hệ thống giả định rằng người gọi là EOA thuần túy có thể bị bỏ qua. Đối với kiểm toán viên, điều quan trọng không chỉ là xác minh tính bảo mật của chính mã được chèn mà còn đánh giá tác động tiềm ẩn của nó đối với các hệ thống hợp đồng khác trong bối cảnh động.
Bài viết này, đội ngũ an ninh Beosin sẽ hệ thống hóa các rủi ro an ninh có thể gặp phải trong quá trình kiểm toán của ví AA được xây dựng dựa trên nguyên lý thiết kế và các đặc điểm chính của EIP-7702, đồng thời đề xuất quy trình và khuyến nghị kiểm toán từ góc nhìn thực chiến, giúp các nhà nghiên cứu an ninh đối phó tốt hơn với các thách thức kỹ thuật trong một mô hình hoàn toàn mới.
Một, Giới thiệu EIP-7702
EIP-7702 đã giới thiệu một loại giao dịch mới 0x04 (SetCode), cho phép EOA ủy quyền mã hợp đồng cần thực hiện thông qua giao dịch này, cấu trúc giao dịch như sau:
Trong đó, authorization_list bao gồm nhiều danh sách ủy quyền, cũng có thể bao gồm hành vi ủy quyền của những người không phải là người khởi xướng giao dịch, cấu trúc bên trong là:
trong đó chain_id đại diện cho chuỗi trong đó ủy quyền của người dùng có hiệu lực và giá trị của nó phải bằng ID chuỗi của chuỗi thực thi hoặc là 0. Khi chain_id là 0, ủy quyền có hiệu lực trên tất cả các chuỗi EVM hỗ trợ EIP-7702, nhưng chỉ khi các tham số khác (chẳng hạn như nonce) khớp. địa chỉ cho biết địa chỉ hợp đồng mục tiêu được người dùng ủy quyền.
Sau khi ủy quyền hoàn tất, hệ thống sẽ sửa đổi trường code của người dùng được ủy quyền thành 0xef0100 || địa chỉ, trong đó địa chỉ chính là địa chỉ hợp đồng được ủy quyền. Nếu muốn hủy ủy quyền, chỉ cần thực hiện một giao dịch SetCode để đặt địa chỉ thành địa chỉ 0.
(1) Linh hoạt và tùy chỉnh
Tài khoản trừu tượng có thể tùy chỉnh linh hoạt các chức năng theo nhu cầu bằng cách viết logic tài khoản vào hợp đồng thông minh. Ví dụ, người dùng có thể cấu hình chữ ký đa chữ ký, khôi phục xã hội, kiểm soát hạn mức, v.v., đáp ứng nhu cầu của cá nhân hoặc doanh nghiệp trong các tình huống khác nhau. Thiết kế này nâng cao đáng kể khả năng mở rộng chức năng của tài khoản, vượt qua giới hạn của tài khoản bên ngoài truyền thống (EOA).
(2) Tăng cường an ninh
Tài khoản trừu tượng cung cấp nhiều cơ chế bảo mật, bao gồm xác thực đa yếu tố, giới hạn giao dịch và khôi phục xã hội. Ngay cả khi người dùng mất khóa riêng, họ vẫn có thể khôi phục tài khoản thông qua người liên hệ tin cậy hoặc xác thực đa yếu tố, tránh được việc mất tài sản vĩnh viễn do mất khóa riêng trong các tài khoản truyền thống. Đồng thời, các chức năng như kiểm soát giới hạn cũng có thể ngăn chặn việc rút tiền lớn một cách ác ý.
(3) Gas tối ưu hóa
Tài khoản trừu tượng hỗ trợ cơ chế trừu tượng Gas linh hoạt, cho phép người dùng thanh toán Gas qua bên thứ ba, thậm chí trực tiếp sử dụng các token khác để thanh toán phí giao dịch. Cơ chế này không chỉ giảm chi phí hoạt động của người dùng mà còn đơn giản hóa quy trình sử dụng blockchain, đặc biệt phù hợp với người mới bắt đầu hoặc các tình huống giao dịch nhiều bước phức tạp.
( Thúc đẩy sự phổ biến của Web3
Bằng cách tối ưu hóa trải nghiệm và tính bảo mật, tài khoản trừu tượng ẩn đi sự phức tạp của blockchain ở những nơi người dùng không nhìn thấy, cung cấp các thao tác tiện lợi gần gũi hơn với Web2. Thiết kế này giảm chi phí học tập cho người dùng bình thường, cho phép nhiều người tham gia vào các ứng dụng Web3 mà không gặp trở ngại, thúc đẩy sự phổ biến của công nghệ phi tập trung.
Hai, Phân tích rủi ro an ninh trong thực tiễn của EIP-7702
Mặc dù EIP-7702 đã mang lại động lực mới cho hệ sinh thái Ethereum và mở rộng các tình huống ứng dụng phong phú, nhưng đồng thời, nó cũng không thể tránh khỏi việc mang lại một số rủi ro an ninh mới:
Dưới mô hình EIP-7702, nếu người dùng đặt trường chain_id trong ủy quyền thành 0, điều đó có nghĩa là ủy quyền này có thể có hiệu lực trên nhiều chuỗi. Thiết kế "ủy quyền đa chuỗi" này mặc dù nâng cao tính linh hoạt trong một số tình huống, nhưng đồng thời cũng mang lại những rủi ro an ninh rõ rệt.
Cần lưu ý rằng, ngay cả khi cùng một địa chỉ có cùng định danh tài khoản trên các chuỗi khác nhau, việc thực hiện hợp đồng đứng sau có thể hoàn toàn khác nhau. Điều này có nghĩa là, kẻ tấn công có thể triển khai một phiên bản hợp đồng độc hại trên một chuỗi khác, lợi dụng hành vi ủy quyền của cùng một địa chỉ trên chuỗi để thực hiện các thao tác không mong muốn, từ đó gây ra rủi ro cho tài sản của người dùng.
Do đó, đối với các nhà cung cấp dịch vụ ví hoặc nền tảng tương tác front-end, khi người dùng thực hiện các thao tác ủy quyền như vậy, họ cần xác minh rõ ràng liệu chainId được khai báo trong ủy quyền của người dùng có phù hợp với mạng kết nối hiện tại hay không; Nếu người dùng được phát hiện đặt chainId thành 0, cần đưa ra cảnh báo rủi ro rõ ràng để nhắc nhở người dùng rằng ủy quyền sẽ có hiệu lực trên tất cả các chuỗi tương thích với EVM và có thể bị lạm dụng bởi các hợp đồng độc hại.
Ngoài ra, bên cung cấp dịch vụ cũng nên đánh giá xem có nên mặc định giới hạn hoặc cấm chainId là 0 trong tầng UI hay không, để giảm thiểu rủi ro do thao tác sai hoặc tấn công lừa đảo.
)1( Tính tương thích callback hợp đồng
Các hợp đồng token hiện có như ERC-721, ERC-777, ERC1155 khi chuyển tiền đến địa chỉ hợp đồng sẽ gọi các giao diện callback tiêu chuẩn (như onERC721Received, tokensReceived) để hoàn tất thao tác chuyển tiền. Nếu địa chỉ nhận không thực thi giao diện tương ứng, việc chuyển tiền sẽ thất bại thậm chí dẫn đến việc tài sản bị khóa.
Trong EIP-7702, địa chỉ người dùng có thể được gán mã hợp đồng thông qua thao tác "set_code", từ đó chuyển đổi thành tài khoản hợp đồng. Lúc này:
Địa chỉ người dùng sẽ được coi là hợp đồng;
Nếu hợp đồng không thực hiện các giao diện callback cần thiết, sẽ dẫn đến việc chuyển token thất bại;
Người dùng có thể không nhận được các đồng tiền chính thống mà không biết.
Do đó, các nhà phát triển nên đảm bảo rằng các hợp đồng mục tiêu mà người dùng ủy quyền thực hiện các giao diện callback liên quan để đảm bảo tính tương thích với các token chính.
)2( Kiểm tra "tx.origin" không còn hiệu lực
Trong hợp đồng truyền thống, "tx.origin" thường được sử dụng để xác định xem giao dịch có phải do người dùng khởi xướng trực tiếp hay không, nhằm ngăn chặn việc gọi hợp đồng và các kiểm soát an toàn khác. Nhưng trong bối cảnh EIP-7702:
Người dùng ký kết giao dịch ủy quyền, thực tế được phát sóng bởi bộ trung gian hoặc dịch vụ gói (bundler); khi giao dịch được thực hiện, "tx.origin" là địa chỉ của bộ trung gian, không phải địa chỉ của người dùng.
「msg.sender」 là hợp đồng ví đại diện cho danh tính người dùng.
Do đó, việc xác thực quyền dựa trên "tx.origin == msg.sender" sẽ dẫn đến việc từ chối thao tác của người dùng hợp pháp, mất đi tính đáng tin cậy, tương tự như việc sử dụng các giới hạn gọi hợp đồng như "tx.origin == user" cũng sẽ không còn hiệu lực. Đề nghị bỏ sử dụng "tx.origin" làm cơ sở đánh giá an toàn, thay vào đó sử dụng xác thực chữ ký hoặc cơ chế ủy quyền.
)3( "isContract" phán đoán sai
Nhiều hợp đồng sử dụng 「isContract )address(」 (kiểm tra độ dài mã địa chỉ) để ngăn chặn tài khoản hợp đồng tham gia vào một số hoạt động nhất định, chẳng hạn như airdrop, mua sắm chớp nhoáng, v.v:
Dưới cơ chế EIP-7702, địa chỉ người dùng có thể trở thành tài khoản hợp đồng thông qua giao dịch "set_code", "isContract" trả về true, hợp đồng sẽ nhầm lẫn người dùng hợp pháp thành tài khoản hợp đồng, từ chối họ tham gia hoạt động, dẫn đến việc người dùng không thể sử dụng một số dịch vụ, trải nghiệm bị cản trở. Với việc ví hợp đồng ngày càng phổ biến, thiết kế dựa vào "isContract" để xác định "có phải là người dùng hay không" đã không còn an toàn, khuyên nên sử dụng các phương thức nhận diện người dùng chính xác hơn như xác minh chữ ký.
Sau khi triển khai cơ chế ủy thác EIP-7702, tài sản trong tài khoản người dùng sẽ hoàn toàn nằm dưới sự kiểm soát của hợp đồng thông minh được ủy thác. Một khi người dùng ủy quyền cho hợp đồng độc hại, kẻ tấn công có thể lợi dụng điều này để có quyền kiểm soát hoàn toàn tài sản trong tài khoản, dẫn đến việc tiền có thể bị chuyển nhanh chóng hoặc đánh cắp, rủi ro an ninh rất cao.
Do đó, điều quan trọng là các nhà cung cấp dịch vụ ví phải hỗ trợ cơ chế giải quyết giao dịch và xác định rủi ro EIP-7702 càng sớm càng tốt. Khi người dùng ký giao dịch ủy thác, giao diện người dùng nên hiển thị rõ ràng và nổi bật địa chỉ hợp đồng mục tiêu, đồng thời kết hợp các thông tin hỗ trợ như nguồn hợp đồng và thông tin triển khai để giúp người dùng xác định các hành vi lừa đảo hoặc gian lận tiềm ẩn, từ đó giảm nguy cơ ký sai. Hơn nữa, dịch vụ ví nên tích hợp các khả năng phân tích bảo mật tự động cho hợp đồng mục tiêu, chẳng hạn như kiểm tra trạng thái mã nguồn mở mã hợp đồng, phân tích mô hình quyền và xác định hoạt động nguy hiểm tiềm ẩn, để giúp người dùng đưa ra phán đoán an toàn hơn trước khi ủy quyền.
Cần đặc biệt lưu ý rằng định dạng chữ ký ủy quyền được giới thiệu bởi EIP-7702 không tương thích với các tiêu chuẩn chữ ký hiện có EIP-191 và EIP-712. Chữ ký này rất dễ vượt qua cảnh báo chữ ký và nhắc nhở tương tác ban đầu của ví, làm tăng thêm nguy cơ người dùng bị lừa ký vào các hoạt động độc hại. Do đó, việc giới thiệu cơ chế nhận diện và xử lý cấu trúc chữ ký này trong việc thực hiện ví sẽ là một khía cạnh quan trọng để bảo đảm an toàn cho người dùng.
)1( Quản lý quyền hợp đồng ví
Nhiều hợp đồng ví EIP-7702 áp dụng kiến trúc đại lý ) hoặc quyền quản lý tích hợp ( để hỗ trợ nâng cấp logic. Tuy nhiên, điều này cũng mang lại rủi ro quản lý quyền cao hơn. Nếu quyền nâng cấp không được hạn chế nghiêm ngặt, kẻ tấn công có thể thay thế hợp đồng thực hiện và tiêm mã độc, dẫn đến tài khoản người dùng bị sửa đổi hoặc tiền bị đánh cắp.
Lời khuyên an toàn:
Sử dụng chữ ký đa dạng, xác thực nhiều yếu tố hoặc cơ chế khóa thời gian để kiểm soát quyền nâng cấp.
Mọi thay đổi về mã và quyền phải trải qua kiểm toán nghiêm ngặt và xác thực an toàn.
Quy trình nâng cấp công khai minh bạch, đảm bảo quyền biết và quyền tham gia của người dùng.
)2( Rủi ro xung đột lưu trữ và cách ly dữ liệu
Các phiên bản hợp đồng ví hoặc các nhà cung cấp ví khác nhau có thể sử dụng lại cùng một vùng lưu trữ. Nếu người dùng thay đổi nhà cung cấp dịch vụ ví hoặc nâng cấp logic ví, việc sử dụng lại khe lưu trữ sẽ khiến biến trạng thái xung đột và sẽ có các vấn đề như ghi đè dữ liệu và đọc ngoại lệ. Điều này không chỉ có thể làm gián đoạn hoạt động bình thường của ví mà còn có thể dẫn đến mất tiền hoặc các quyền bất thường.
Lời khuyên an toàn:
Sử dụng giải pháp tách biệt lưu trữ chuyên dụng (như tiêu chuẩn EIP-1967) hoặc tận dụng không gian tên duy nhất để quản lý các khe lưu trữ.
Khi nâng cấp hợp đồng, hãy đảm bảo bố cục lưu trữ tương thích để tránh sự chồng chéo của các biến.
Kiểm tra tính hợp lý của trạng thái lưu trữ trong quy trình nâng cấp nghiêm ngặt.
)3( Quản lý nonce bên trong ví
Hợp đồng ví thường được thiết lập nonce bên trong và tự quản lý để đảm bảo thứ tự thực hiện của các thao tác của người dùng và ngăn chặn tấn công phát lại. Nếu nonce được sử dụng không đúng cách, sẽ dẫn đến việc thao tác của người dùng không thể được thực hiện bình thường.
Lời khuyên an toàn:
nonce phải được kiểm tra giá trị bằng (hoặc tăng dần), không được bỏ qua.
Cấm hàm trực tiếp sửa đổi nonce, chỉ có thể được cập nhật nonce khi người dùng thực hiện thao tác.
Thiết kế cơ chế chịu lỗi và phục hồi cho các tình huống bất thường nonce, tránh tình trạng deadlock nonce.
)4( Kiểm tra quyền gọi hàm
Để đảm bảo an toàn, hợp đồng ví phải đảm bảo rằng người gọi các hàm quan trọng là tài khoản sở hữu ví. Hai cách phổ biến bao gồm:
ủy quyền ký ngoài chuỗi
Người dùng ký một tập hợp các thao tác bằng khóa riêng, hợp đồng ví xác minh tính hợp lệ của chữ ký trên chuỗi, kiểm tra xem chữ ký có hết hạn hay không, và có đáp ứng nonce tương ứng hay không. Cách này áp dụng cho mô hình giao dịch trung gian mà EIP-7702 khuyến nghị (người dùng ký ngoại tuyến + trung gian phát giao dịch).
Gọi ràng buộc (msg.sender == địa chỉ )this()
Hàm thao tác của người dùng chỉ cho phép được gọi bởi chính hợp đồng, về bản chất là một cơ chế kiểm soát đường dẫn gọi, đảm bảo rằng người khởi xướng bên ngoài phải là chính tài khoản đó. Điều này thực sự tương đương với việc yêu cầu người gọi phải là EOA gốc, vì lúc này địa chỉ hợp đồng chính là địa chỉ EOA.
Ba, Triển vọng: EIP-7702 và tiêu chuẩn ví AA trong tương lai
Việc đề xuất EIP-7702 không chỉ là một cuộc cách mạng đối với mô hình tài khoản truyền thống, mà còn là một bước thúc đẩy lớn cho hệ sinh thái trừu tượng tài khoản (Account Abstraction). Khả năng mà nó đưa ra cho người dùng để tải mã hợp đồng đã mở ra không gian khám phá rộng lớn cho thiết kế ví và hệ thống hợp đồng trong tương lai, đồng thời cũng đặt ra những yêu cầu mới đối với tiêu chuẩn kiểm toán an toàn.
Mặc dù EIP-7702 và EIP-4337 có mục tiêu thiết kế khác nhau, cái trước tái cấu trúc cơ chế tải mã tài khoản, cái sau xây dựng một cổng giao dịch hoàn chỉnh và hệ sinh thái đóng gói. Nhưng hai cái này không mâu thuẫn, mà ngược lại, có tính bổ trợ rất mạnh.
EIP-4337 cung cấp "Kênh giao dịch chung" và "Giao diện thực thi tài khoản trừu tượng";
EIP-7702 cho phép tài khoản người dùng cấp khả năng logic hợp đồng một cách linh hoạt mà không cần thay đổi địa chỉ.
Do đó, ví trong tương lai có thể áp dụng "kiến trúc hỗ trợ kép": sử dụng EIP-7702 như một phương án thay thế nhẹ nhàng trên các chuỗi không hỗ trợ EIP-4337, trong khi tiếp tục dựa vào ngăn xếp giao thức đầy đủ của EIP-4337 trong các tình huống cần đóng gói ngoài chuỗi và tập hợp nhiều người dùng.
Cơ chế hai chế độ này cũng sẽ thúc đẩy ví hỗ trợ mô hình quyền hạn tài khoản linh hoạt hơn, cơ chế hạ cấp và kế hoạch quay lại ở cấp lõi.
Cơ chế hợp đồng hóa tài khoản được EIP-7702 đề xuất có tiềm năng tích hợp tự nhiên với các kiến trúc mới như ví MPC, ví ZK, ví mô-đun đang phổ biến hiện nay:
Trong mô hình MPC, hành vi chữ ký không còn dựa vào một khóa riêng duy nhất mà là một quyết định hợp tác được đưa ra bởi nhiều bên. Chữ ký được tạo ra thông qua sự hội tụ của EIP-7702 và MPC kiểm soát logic hợp đồng được tải động, cho phép các chiến lược thực hiện linh hoạt hơn.
Ví ZK xác minh danh tính hoặc quyền truy cập của người dùng thông qua chứng minh không kiến thức mà không cần tiết lộ thông tin khóa cá nhân. Kết hợp với EIP-7702, ví ZK có thể tạm thời tiêm hợp đồng logic cụ thể sau khi xác minh hoàn tất, từ đó thực hiện việc triển khai hành vi cá nhân hóa sau khi tính toán riêng tư, chẳng hạn như tự động thực hiện một logic nào đó chỉ khi đáp ứng một số điều kiện riêng tư nhất định.
Ví mô-đun (Modular Wallets) có thể sử dụng EIP-7702 để tách biệt logic tài khoản thành nhiều mô-đun, được tải động khi cần.
Do đó, EIP-7702 cung cấp một "container thực thi" gốc hơn cho ví tiên tiến nêu trên: địa chỉ người dùng không thay đổi có thể tiêm logic hợp đồng khác nhau, tránh vấn đề phụ thuộc vào địa chỉ trong quá trình triển khai hợp đồng truyền thống, và cũng không cần phải triển khai trước, từ đó nâng cao đáng kể tính linh hoạt và khả năng kết hợp của hành vi tài khoản.
EIP-7702 sẽ thúc đẩy một sự thay đổi sâu sắc trong mô hình phát triển. Các nhà phát triển hợp đồng không còn đơn giản coi người gọi như một EOA truyền thống hoặc một tài khoản hợp đồng cố định, mà phải thích ứng với một cơ chế mới: danh tính của người gọi có thể được chuyển đổi động giữa EOA và trạng thái hợp đồng trong quá trình giao dịch và logic hành vi tài khoản không còn được củng cố tĩnh mà có thể được thay đổi linh hoạt theo nhu cầu. Điều này yêu cầu các nhà phát triển và kiểm toán viên:
Giới thiệu logic xác thực caller và đánh giá quyền nghiêm ngặt hơn;
Kiểm tra xem đường gọi có bị ảnh hưởng bởi logic hợp đồng động hay không;
Nhận diện các điểm yếu tiềm ẩn của hành vi như msg.sender.code.length == 0, isContract )(;
Rõ ràng về logic hợp đồng "phụ thuộc vào ngữ cảnh", chẳng hạn như kiểm soát biên giới của cuộc gọi tĩnh, deleGatecall;
Hỗ trợ mô phỏng và phân tích khôi phục các tình huống setCode ở cấp độ chuỗi công cụ.
Nói cách khác, tính bảo mật của mã không còn chỉ là "vấn đề trước khi triển khai", mà đã trở thành "quá trình động cần phải xác minh trong khi gọi và giao dịch".
Bốn, tóm tắt
EIP-7702 giới thiệu việc triển khai Trừu tượng hóa tài khoản (AA) nhẹ hơn, gốc và linh hoạt, cho phép EOA thông thường mang logic hợp đồng và thực hiện nó trong một giao dịch duy nhất. Cơ chế này phá vỡ các giả định tĩnh truyền thống về hành vi tài khoản và các nhà phát triển không còn có thể chỉ đơn giản dựa vào trạng thái mã của địa chỉ tài khoản để đánh giá mô hình hành vi của nó, mà cần xây dựng lại sự hiểu biết về ranh giới danh tính và thẩm quyền của người gọi. Cùng với đó là sự thay đổi mô hình trong phân tích bảo mật. Trọng tâm của kiểm toán không còn giới hạn ở "liệu một địa chỉ có quyền hay không", mà chuyển sang "những gì logic hợp đồng được thực hiện trong giao dịch có thể làm trong bối cảnh hiện tại". Mỗi giao dịch có thể mang một định nghĩa độc lập về hành vi, điều này mang lại cho tài khoản chức năng lớn hơn và đưa ra các yêu cầu cao hơn đối với kiểm tra bảo mật.