Tại sao mô hình tương tác mới của ERC-8211 đáng để chú ý?

Tác giả：imToken

Bắt đầu từ năm 2025, nhiều người có thể dần quen với một phương thức tương tác mới: nói với GPT hoặc Gemini một câu như “Hãy giúp tôi lên kế hoạch chuyến đi Hong Kong tuần tới và đề xuất vé máy bay khách sạn phù hợp”, thì hệ thống sẽ âm thầm thực hiện tìm kiếm thông tin, lọc điều kiện, chọn tuyến đường, so sánh giá cả, v.v., cuối cùng chỉ đưa kết quả để bạn xác nhận.

Chỉ có điều, mang kỳ vọng tương tự đó lên chuỗi, câu chuyện lại hoàn toàn khác.

Ví dụ, bạn ra lệnh cho một DeFi Agent: “Chuyển ETH trong ví sang USDC, chuyển qua chuỗi Base, rồi gửi toàn bộ vào Aave”, khách quan mà nói, từ “hiểu nhu cầu” và “lập kế hoạch đường đi” thì ngày nay Agent có thể làm được, nhưng thực sự có khoảng cách lớn nằm ở bước thực thi:

Bạn vẫn rất có khả năng phải từng bước hoàn tất ký tên, cấp phép, đổi token, chuyển chuỗi và gửi tiền, và mỗi bước đều đối mặt với rủi ro biến động slippage, dao động Gas, trễ bridge, thay đổi trạng thái trên chuỗi, điều này có nghĩa là chỉ cần một bước lệch khỏi dự kiến, các thao tác trước đó có thể không thể thu hồi, các thao tác sau cũng không thể thực hiện tiếp, cuối cùng chỉ còn lại một đoạn quy trình chưa hoàn thành trên chuỗi.

Vấn đề không phải là AI không đủ thông minh, mà là ở tầng thực thi trên chuỗi vẫn thiếu một cách biểu đạt thực sự phù hợp với Agent.

Chính vì vậy, vào tháng 4 năm 2026, Biconomy cùng Quỹ Ethereum đã cùng phát hành ERC-8211, nhằm giải quyết vấn đề “giới hạn tĩnh” trong thực thi hợp đồng thông minh hiện tại, cung cấp một tầng thực thi có khả năng thể hiện tốt hơn cho các AI Agent và các luồng công việc DeFi phức tạp, cố gắng bổ sung phần thiếu hụt này.

1. AI Agent và “đoạn cuối cùng” của việc kết nối trên chuỗi

Trong một đến hai năm qua, sự chú ý của ngành công nghiệp tiền mã hóa đang chuyển từ mở rộng quy mô Layer 2, thanh khoản RWA, rõ ràng sang câu hỏi gây tranh cãi: Làm thế nào để AI Agent thực sự tiếp quản các thao tác trên chuỗi.

Khách quan mà nói, từ “dùng ngôn ngữ tự nhiên ra lệnh cho chiến lược DeFi nhiều bước” đến “để Agent tự chủ quản lý toàn bộ danh mục đầu tư chéo chuỗi”, gần đây chúng ta đã thấy nhiều thực tiễn, phần lớn các ý tưởng đã trưởng thành ở mức demo, bất kể là sinh chiến lược DeFi nhiều bước bằng ngôn ngữ tự nhiên, tự thực thi cân bằng lại, tự động di chuyển lợi nhuận, điều chỉnh vị thế chéo chuỗi, thậm chí quản lý các tổ hợp phức tạp hơn.

Từ góc độ suy luận và phối hợp, khả năng của AI đã tiến rất nhanh, nhưng khi đưa vào môi trường sản xuất, điểm yếu trong thực thi ngày càng rõ ràng.

Thật ra, trong môi trường sản xuất, điểm yếu này có thể tóm gọn trong một câu: DeFi là động, nhưng phần lớn batch (xử lý theo lô) ngày nay vẫn là tĩnh.

Trang chủ và các bài thảo luận của ERC-8211 đều nói rõ vấn đề này, tức là các tiêu chuẩn ERC-4337 và EIP-5792 hiện tại đã đưa mô hình “một lần ký tương ứng một lần gọi” cũ lên giai đoạn mới “một lần ký có thể đóng gói nhiều lần gọi”, nhưng các tham số trong các cuộc gọi này về bản chất vẫn chủ yếu bị cố định tại thời điểm ký.

Nói cách khác, các giá trị như số tiền, mục tiêu, kết quả mong đợi mà người dùng điền khi ký, khi thực thi thực tế, sẽ không tự động điều chỉnh theo thay đổi trạng thái trên chuỗi.

Trong khi đó, chính DeFi lại đầy rẫy sự không chắc chắn. Kết quả thực tế của một lần Swap phụ thuộc vào slippage và thanh khoản trong khối thực thi; thời gian và số tiền nhận được cuối cùng của một lần Bridge phụ thuộc vào cơ chế và phí của cầu nối; tỷ lệ share-to-asset của các hợp đồng vay hoặc Vault cũng liên tục biến đổi.

Dù sao, các giá trị mà người dùng hoặc Agent thấy khi ký thường chỉ là ước lượng tại thời điểm đó, chứ không phải kết quả thực tế khi thực thi.

Để hiểu ERC-8211 đã giải quyết được gì, hãy xem một ví dụ điển hình nhất, giả sử Agent muốn làm một việc rất đơn giản — đổi ETH trong ví thành USDC, rồi gửi toàn bộ vào Spark để kiếm lãi.

Trong mô hình batch tĩnh hiện tại, Agent phải dự đoán trước khi ký rằng sau khi Swap sẽ nhận được bao nhiêu USDC, thường buộc phải cố định số tiền đầu vào của bước thứ hai khi ký, và nếu dự đoán quá cao, số thực nhận không đủ, toàn bộ batch sẽ bị rollback; còn nếu dự đoán quá thấp, sẽ để lại một phần vốn trong ví mà không thể sử dụng.

Nói cách khác, rơi vào tình huống tiến thoái lưỡng nan: hoặc chấp nhận rủi ro thất bại, hoặc bỏ lỡ cơ hội. Đó là lý do tại sao, nhiều quy trình trên chuỗi trông có vẻ không phức tạp, nhưng khi bước dài tới 5, 8 bước, thậm chí qua hai chuỗi, lại dễ trở nên mong manh, không phải vì chiến lược quá phức tạp để mô tả, mà vì cách thực thi hiện tại quá phụ thuộc vào các tham số cố định trước.

Nói tóm lại, giới hạn của khả năng batch tĩnh chính là giới hạn an toàn thực thi của Agent.

Từ góc độ này, ERC-8211 không phải để giải quyết cách AI Agent ra quyết định, mà là sau khi Agent đã ra quyết định, liệu có tồn tại một cách biểu đạt tự nhiên, ổn định, an toàn hơn để thực thi trên chuỗi hay không. Để lần đầu tiên, thực thi trên chuỗi có một dạng biểu đạt được thiết kế đặc biệt cho AI Agent.

2. ERC-8211 đã thay đổi những gì?

Điểm đột phá cốt lõi của ERC-8211 không phải là thêm nhiều bước vào một lần ký, mà là nâng cấp xử lý batch từ một chuỗi giao dịch cố định thành một đoạn “tham số được tính toán động tại thời điểm thực thi”.

Nghe có vẻ trừu tượng, nhưng không khó hiểu, nhà phát hành đã dùng một câu để mô tả: From transactions to programs.

Điều này có nghĩa là ERC-8211 không còn xem batch như một danh sách các hành động thực thi theo thứ tự, mà là một đoạn chương trình thực thi có thể tính toán tại thời điểm chạy, kèm theo các điều kiện an toàn. Cụ thể, nó thực hiện điều này qua ba nguyên tắc cơ bản có thể kết hợp:

• Fetchers (lấy giá trị): xác định nguồn lấy giá trị cho tham số, có thể là truy vấn số dư hiện tại của một địa chỉ, giúp tham số không còn là snapshot tại thời điểm ký, mà là giá trị đọc được theo thời gian thực từ trạng thái chuỗi;

• Constraints (ràng buộc): sau khi tham số được lấy ra, còn phải kiểm tra các ràng buộc nội tuyến — ví dụ “USDC nhận được ít nhất ≥ 2500”, hoặc “slippage không quá 0.5%”, các ràng buộc này được kiểm tra trước khi giá trị được chuyển sang bước gọi tiếp theo, bất kỳ ràng buộc nào không đạt sẽ khiến toàn bộ batch bị rollback ngay lập tức;

• Predicates (điều kiện kích hoạt): hiểu đơn giản là các “người gác cổng” giữa các bước, không tạo ra giá trị, mà chỉ quyết định có tiếp tục thực thi hay không, ví dụ trong cảnh chuyển chéo chuỗi, ở phía Ethereum, batch có thể bị giữ lại bởi predicate dựa trên điều kiện “WETH đã đến tài khoản” — trước khi điều đó xảy ra, không tiến hành gửi.

Trong thiết kế này, mỗi tham số đều phải trả lời hai câu hỏi: Thứ nhất, giá trị này khi thực thi đến từ đâu; thứ hai, cần thỏa mãn điều kiện gì trước khi dùng vào gọi tiếp theo. Khi kết hợp lại, một batch không còn chỉ là danh sách các giao dịch, mà là một đoạn chương trình có kiểm tra an toàn tích hợp.

Nói cách khác, mô hình tư duy của batch tĩnh là một danh sách — thực thi A, rồi B, rồi C theo thứ tự; còn mô hình của ERC-8211 là một chương trình có điều kiện — sau khi A thực thi, lấy ra kết quả thực của A làm đầu vào cho B; B phải thỏa mãn ràng buộc mới được thực thi C; bất kỳ bước nào không như mong đợi, toàn bộ sẽ rollback.

Chúng ta có thể hiểu đơn giản như một cơ chế “xử lý theo lô thông minh” dành riêng cho AI Agent và các thao tác DeFi phức tạp, vì trong các thao tác truyền thống trên chuỗi, để hoàn thành một chiến lược DeFi phức tạp thường cần nhiều giao dịch riêng biệt: rút vốn từ vay, đổi token, gửi vào hợp đồng khác (xem thêm “Toàn cảnh giao thức AI mã hóa: Từ chiến trường Ethereum, xây dựng hệ điều hành mới cho AI Agent?”).

Mỗi bước đều cần ký và xác nhận riêng, đã rất phiền phức cho người dùng, còn đối với AI Agent cần thao tác tần suất cao, lại là một giới hạn. ERC-8211 cho phép các thao tác trên nhiều chuỗi được gộp trong một giao dịch, khi thực thi sẽ phân tích giá trị thực động, và chỉ tiếp tục bước tiếp khi điều kiện đã thỏa mãn.

Ví dụ, một Agent có thể hoàn tất trong một giao dịch ký duy nhất: rút vốn từ Aave → đổi số tiền nhận được trên Uniswap → gửi kết quả đổi vào Compound — tất cả đều nguyên tử, không cần viết hợp đồng thông minh mới.

3. Tại sao nói nó liên quan nhiều đến ví, đặc biệt là ví thông minh

ERC-8211 đáng chú ý vì không chỉ phù hợp cho Agent, mà còn sẽ định hình lại vị trí của ví trong chuỗi tương tác.

Trước đây, ví giống như một thiết bị ký an toàn, nhiệm vụ là giữ khóa riêng, hiển thị giao dịch, để người dùng xác nhận, rồi gửi ký. Vai trò này đã đủ quan trọng trong thời đại EOA, và vẫn tiếp tục trong thời đại account abstraction, nhưng nếu về sau, nhiều thao tác trên chuỗi do Agent thực hiện, thì vai trò của ví sẽ càng trung tâm và nặng nề hơn.

Lý do rất đơn giản, khi người dùng không còn thao tác từng bước trên chuỗi nữa, mà bắt đầu cấp phép cho Agent thực hiện toàn bộ mục tiêu, ví phải có khả năng tiếp nhận dạng tương tác cao hơn này. Nó không chỉ hiển thị một địa chỉ hợp đồng và calldata, mà còn là một đoạn “ý định — lấy giá trị — kiểm tra điều kiện — kết quả cuối cùng” của chương trình thực thi.

Vì vậy, ví trong tương lai cần hiểu không chỉ là giao dịch, mà còn là chương trình. ERC-8211 chính là cung cấp một khung biểu đạt rõ ràng hơn cho ví, vì nó ghi rõ các ý nghĩa thực thi này trong cấu trúc mã, bao gồm nguồn gốc tham số, điều kiện cần thỏa mãn, thời điểm tiếp tục hay rollback, tất cả đều không còn là “hộp đen” phía sau, mà có thể được ví giải thích, mô phỏng và hiển thị.

Từ góc nhìn của ví, cơ chế này cuối cùng hướng tới một điều: Người dùng không còn ký một chuỗi các lệnh gọi mà họ khó đọc hiểu hết, mà ký một chương trình thực thi rõ ràng, có giới hạn, có thể xác minh điều kiện:

• AI Agent có thể hiểu ý định của người dùng, tạo ra lộ trình;

• Ví sẽ trình bày rõ ràng lộ trình này để người dùng xác nhận;

• Relayer chỉ thực hiện gửi khi điều kiện đúng, không có quyền sửa đổi kết quả.

Điều này chính là lý do tại sao thực thi không tin cậy (trustless execution) dựa trên Agentic DeFi lại được xem là tiền đề, vì AI có thể tham gia, nhưng chủ quyền, ràng buộc và kết quả cuối cùng vẫn nằm trên chuỗi. Đây cũng chính là điểm phù hợp giữa ERC-8211 và ví thông minh, khi nó đưa “biểu đạt an toàn các ý định phức tạp” vào tiêu chuẩn giao thức.

Đáng chú ý, ERC-8211 hoàn toàn tương thích với các tiêu chuẩn account abstraction như ERC-4337, EIP-7702, ERC-7579, không thay thế account abstraction, mà bổ sung thêm một tầng biểu đạt thực thi theo chương trình cho Agent.

Nếu ERC-4337 giải quyết “ai có thể đại diện tôi gửi giao dịch”, EIP-7702 giải quyết “EOA tạm thời có thể sở hữu hợp đồng thông minh”, thì ERC-8211 giải quyết “khi Agent bắt đầu thay tôi thao tác, liệu trong một lần ký có thể hoàn tất toàn bộ chuỗi quyết định hay không”.

Nhìn lại quá trình phát triển của các mô hình tương tác trên chuỗi Ethereum trong 10 năm qua:

• Giai đoạn 1: Một lần ký = một lần gọi hàm (thời đại EOA)

• Giai đoạn 2: Một lần ký = một chuỗi gọi tĩnh (ERC-4337, EIP-5792)

• Giai đoạn 3: Một lần ký = một chương trình ý định tính toán động (ERC-8211)

Mỗi bước nhảy đều cho phép người dùng (hoặc Agent đại diện) thể hiện mục tiêu phức tạp hơn với ít ma sát hơn.

Dù ERC-8211 vẫn còn trong giai đoạn dự thảo, các thảo luận kỹ thuật vẫn đang diễn ra, và tích hợp quy mô lớn còn cần thời gian, nhưng hướng đi đã rõ ràng: khi AI Agent bắt đầu thay con người ra quyết định trên chuỗi, thì cần có một cú pháp thực thi phù hợp, nguyên bản.