ERC-7683 đang thay đổi, và nhiều giải thích vẫn mô tả phiên bản cũ hơn của tiêu chuẩn này. Bản nháp hiện tại của ERC-7683 mang tính tập trung vào resolver hơn. Thay vì buộc mọi giao thức ý định xuyên chuỗi vào một hợp đồng ký quỹ chung, một hệ thống đấu giá, một cơ chế thanh toán, một mô hình ủy quyền hoặc một hàm điền đích duy nhất, các giao thức có thể giữ nguyên kiến trúc thực thi riêng của mình trong khi vẫn công khai các lệnh cho các solver thông qua một lớp giải quyết chung. Sự khác biệt này rất quan trọng. Một lệnh ERC-7683 về cơ bản là một lời đề nghị thanh toán đổi lấy việc đáp ứng một tập hợp các yêu cầu đã xác định. Các solver, còn được gọi là fillers, đánh giá các yêu cầu đó, xác định hành động thực thi cần thiết, cam kết vốn hoặc gas, và kỳ vọng nhận thanh toán nếu họ thực hiện lệnh chính xác. Thiết kế hiện tại cho phép một giao thức công khai một payload đặc thù của giao thức cùng với một hợp đồng resolver. Resolver này chuyển đổi payload thành một biểu diễn chung bao gồm: • các bước thực thi • các biến • các khoản thanh toán • các giả định rõ ràng Điều này cung cấp cho các solver có khả năng lập trình một cách chuẩn hóa để hiểu rõ một lệnh thực sự yêu cầu gì, mà không cần mỗi solver phải triển khai logic hoàn toàn riêng biệt cho từng giao thức ý định. Mô hình thực thi đã được giải quyết có thể phơi bày các yêu cầu về chi tiêu token, yêu cầu gas, ràng buộc thời gian, phụ thuộc và hành vi revert. Các biến có thể đại diện cho địa chỉ thanh toán solver, chuỗi thanh toán, đầu ra thực thi, người gọi bước, nhân chứng ngoài chuỗi, truy vấn hợp đồng và truy vấn sự kiện. ERC-7683 cũng tích hợp các biểu diễn địa chỉ tương tác thông qua ERC-7930, gắn bối cảnh chuỗi với địa chỉ thay vì chỉ dựa vào địa chỉ EVM 20-byte thông thường. Tuy nhiên, có một ranh giới bảo mật quan trọng. Việc chuẩn hóa ERC-7683 không tự động làm cho giao thức ý định nền tảng trở nên an toàn. Các hợp đồng thanh toán, cầu nối, hệ thống truyền tin, token, cơ chế đấu giá, dịch vụ ngoài chuỗi, oracle, khóa tài nguyên, bảo vệ replay, logic hủy bỏ, hành vi hoàn tiền và điền từng phần vẫn là những rủi ro đặc thù của giao thức, trừ khi chúng được biểu diễn rõ ràng thông qua các yêu cầu hoặc giả định đã được giải quyết. Bảo mật resolver do đó là cực kỳ quan trọng. Một resolver phải xác thực chính xác payload đặc thù của giao thức và công khai một biểu diễn cho phép solver hoạt động đúng cách hiểu rõ điều gì phải xảy ra và dưới những giả định nào thì thanh toán sẽ khả dụng. Một resolver chính xác không thể làm cho một hệ thống thanh toán không an toàn trở nên an toàn. Và một định dạng lệnh tuân thủ không loại bỏ rủi ro của solver. Một filler trở nên bị phơi bày về mặt kinh tế kể từ thời điểm họ cam kết phê duyệt, gas, vốn hoặc giao dịch cho đến khi khoản thanh toán dự kiến trở nên cuối cùng và có thể chi tiêu được. Đối với người dùng, các điểm xác minh chính vẫn là thực tế: • chuỗi nguồn • tài sản đầu vào • chuỗi đích • người nhận • đầu ra dự kiến • hạn chót • phạm vi ủy quyền • giao dịch hoặc dữ liệu có kiểu đang được ký ERC-7683 cũng phù hợp tự nhiên trong các hệ thống ý định rộng lớn hơn như Open Intents Framework, nhưng hai hệ thống này không thể thay thế lẫn nhau. ERC-7683 chủ yếu là một lớp chuẩn hóa để giải quyết lệnh dành cho solver. OIF là một khung hạ tầng rộng hơn bao gồm nguồn gốc ý định, giải quyết, thực hiện, thanh toán, tổng hợp và các thành phần liên quan. Nghiên cứu mới nhất của TokenToolHub phân tích chi tiết thiết kế hiện tại của ERC-7683, cách nó khác với các bản nháp trước đó, vòng đời lệnh, các filler, bảo mật resolver, các bước thực thi, thanh toán, giả định, địa chỉ tương tác và các rủi ro solver vẫn nằm ngoài phạm vi tiêu chuẩn. Phân tích đầy đủ: https://t.co/VK5Yb4wvJ3