
Đối với người mới bắt đầu khi tiếp cận khái niệm “Giao dịch Frame (khung)” trong các cuộc thảo luận về Ethereum và Hegotá, mô hình tư duy đơn giản nhất là một giao dịch được cấu thành từ nhiều bước phối hợp. Một frame có thể xác minh người gửi, frame khác phê duyệt thanh toán, và các frame tiếp theo sẽ thực thi hành động của người dùng. Bài viết này tập trung vào cấu trúc cơ bản đó thay vì phạm vi rộng hơn của đề xuất EIP-8141.
EIP-8141 định nghĩa một loại Giao dịch Frame mới, hiện được gán loại giao dịch 0x06.
Một giao dịch duy nhất có thể chứa tối đa 64 frame, mỗi frame có chế độ thực thi và giới hạn gas riêng biệt.
Các frame tách biệt xác thực giao dịch, thanh toán gas và thực thi của người dùng.
Opcode APPROVE cho phép phê duyệt riêng biệt việc thực thi, thanh toán hoặc cả hai.
Khái niệm frame giúp kích hoạt abstraction tài khoản gốc, batch nguyên tử, tài trợ gas và xác minh chữ ký có thể lập trình.
Đặc tả Giao dịch Frame EIP-8141 chính thức mô tả một loại giao dịch mới, trong đó tính hợp lệ và thanh toán gas có thể được định nghĩa ở mức trừu tượng. Đặc tả EIP-8141
Payload của giao dịch này chứa địa chỉ người gửi, chữ ký, phí và danh sách các frame. Mỗi frame xác định chế độ, cờ, mục tiêu, giới hạn thực thi và gas trạng thái, giá trị và dữ liệu riêng biệt. Đặc tả hiện tại đặt MAX_FRAMES là 64 và FRAME_TX_TYPE là 0x06.
Nói đơn giản, một giao dịch truyền thống tuân theo cấu trúc cố định người gửi ký và người gửi trả phí. Abstraction frame biến cấu trúc cố định đó thành một chuỗi có thể lập trình.
Mỗi frame EIP-8141 có một trong ba chế độ thực thi:
| Chế độ | Mục đích cơ bản |
|---|---|
| VERIFY | Xác định frame là xác thực giao dịch |
| SENDER | Thực thi với người gửi giao dịch làm caller |
| DEFAULT | Thực thi với danh tính ENTRY_POINT do giao thức xác định |
Chế độ thực thi quyết định bối cảnh của việc thực thi frame. Frame VERIFY có thể chạy logic xác minh trước khi các frame sender thực thi, còn chế độ SENDER cho phép các thao tác được ủy quyền thực thi như thể được gọi từ địa chỉ người gửi. Chế độ DEFAULT cung cấp danh tính thực thi ở cấp giao thức trung lập.
Cấu trúc mô-đun này là trung tâm của abstraction tài khoản gốc vì xác thực không còn phải mã hóa cứng quanh một khóa riêng hay một cơ chế chữ ký duy nhất.
EIP-8141 bổ sung opcode APPROVE để cập nhật bối cảnh phê duyệt của giao dịch.
Logic xác thực có thể sử dụng các phạm vi phê duyệt khác nhau:
APPROVE_PAYMENT cho phép thanh toán gas.
APPROVE_EXECUTION cho phép các frame sender tiếp theo thực thi.
APPROVE_EXECUTION_AND_PAYMENT cho phép cả hai.
Mục tiêu của frame phải là caller của APPROVE, giới hạn quyền cấp phép phê duyệt. Khi thực thi được phê duyệt, các frame SENDER tiếp theo có thể thực thi với bối cảnh người gửi.
Sự tách biệt này cũng cho phép hợp đồng tài trợ hoặc paymaster phê duyệt chi phí gas tối đa, trong khi logic xác thực của người dùng chỉ phê duyệt thực thi riêng biệt.
Đặc tả hiện tại chứa bảy lệnh mới liên quan đến frame:
| Opcode | Chức năng |
|---|---|
| APPROVE | Phê duyệt thanh toán và/hoặc thực thi |
| TXPARAM | Đọc tham số giao dịch |
| FRAMEDATALOAD | Tải dữ liệu từ frame chỉ định |
| FRAMEDATACOPY | Sao chép dữ liệu đầu vào của frame vào bộ nhớ |
| FRAMEPARAM | Đọc tham số và trạng thái thực thi của frame |
| SIGPARAM | Đọc siêu dữ liệu chữ ký |
| SIGDATACOPY | Sao chép dữ liệu chữ ký được hỗ trợ |
Ví dụ, TXPARAM có thể cung cấp thông tin phạm vi giao dịch như người gửi, phí tối đa, hash chữ ký và số lượng frame. FRAMEPARAM cung cấp chi tiết ở cấp frame như chế độ thực thi, cờ, gas sử dụng và trạng thái flag batch nguyên tử. Các thao tác tra cứu cơ bản này có chi phí gas là 2.
Giao dịch Frame tách biệt thanh toán gas khỏi người gửi. Frame VERIFY có thể phê duyệt tài khoản khác hoặc hợp đồng tài trợ để trả phí, tạo cơ chế tài trợ gas gốc.
Ví dụ, người dùng có thể giữ stablecoin, trong khi tài khoản khác đóng vai trò người trả phí gas. Giao dịch Frame có thể chuyển token ERC-20 để bù cho tài trợ, trong khi chi phí giao dịch cơ bản của Ethereum được thanh toán qua người trả phí chỉ định.
Mỗi frame cũng nhận được giới hạn gas thực thi và gas trạng thái. Gas không dùng đến sẽ giảm số tiền cuối cùng bị tính cho người trả phí, thay vì trở thành dung lượng thực thi bổ sung cho các frame còn lại.
Batch nguyên tử liên kết nhiều frame thực thi để chúng thành công hoặc revert cùng lúc.
Ví dụ, một thao tác phê duyệt ERC-20 tiếp theo là hoán đổi. Khi bật cờ batch nguyên tử, nếu frame hoán đổi revert, thao tác phê duyệt trước đó cũng revert. Điều này ngăn việc token allowance không mong muốn còn lại sau khi giao dịch bị thất bại.
Đây là lý do thực tế giúp Giao dịch Frame đơn giản hóa các tương tác hợp đồng thông minh nhiều bước.
Framework abstraction tài khoản ERC-4337 của Ethereum sử dụng smart account, bundler, UserOperations (giữ nguyên nếu là tên riêng trong Ethereum, hoặc thêm chú thích nếu cần) và paymaster (giữ nguyên nếu là thuật ngữ đặc thù, nhưng nên nhất quán và có chú thích ở lần xuất hiện đầu tiên, ví dụ: "paymaster (người tài trợ phí)") để cung cấp hành vi ví có thể lập trình. Giao dịch Frame đưa nhiều tính linh hoạt này trực tiếp lên lớp giao thức.
Việc xác thực có thể lập trình của EIP-8141 cũng hỗ trợ nhiều cơ chế chữ ký, quay vòng khóa, tập hợp chữ ký trong tương lai và hướng tới khả năng chống lượng tử. Code mặc định cho phép các tài khoản không triển khai mã hợp đồng vẫn tham gia, trong khi frame deploy có thể triển khai tài khoản trước khi xác minh.
Sự linh hoạt này tạo ra các điểm đánh đổi. Logic xác thực tùy ý có thể gây ra rủi ro denial-of-service cho pool giao dịch hoặc làm vô hiệu hóa hàng loạt, vì vậy quy tắc "mempool" công khai giới hạn prefix xác thực và cách xử lý các giao dịch Frame đang chờ.
Giao dịch Frame trên Ethereum về cơ bản là một giao dịch gồm nhiều frame có thể lập trình. Thay vì gắn cứng xác thực, thanh toán gas và thực thi vào cùng một vai trò giao dịch, EIP-8141 cho phép các frame khác nhau thực hiện từng nhiệm vụ.
Định nghĩa này là điểm phân biệt quan trọng: EIP-8141 là đề xuất giao thức; Giao dịch Frame là định dạng giao dịch mới nó giới thiệu. Cấu trúc mô-đun chính là yếu tố giúp tài trợ gas, batch nguyên tử, xác thực có thể lập trình, chữ ký linh hoạt và abstraction tài khoản gốc mà không phải biến từng tính năng thành một hệ thống giao dịch riêng biệt.
Đúng. Chế độ VERIFY được dùng cho xác thực giao dịch và thiết kế để hoạt động mà không tạo thay đổi trạng thái lâu dài. Điều này giúp node mô phỏng xác thực an toàn hơn trước khi quyết định xem một Giao dịch Frame đang chờ có nên vào hoặc ở lại "mempool" công khai.
Không phải lúc nào cũng được. Trong EIP-8141, người trả phí có thể được chọn qua logic xác thực có thể lập trình, vì vậy không thể xác định người trả phí chỉ dựa vào dữ liệu giao dịch. Phê duyệt thanh toán được thiết lập trong quá trình xác thực giao dịch.
Quyền của người gửi được xác lập trước, sau đó phê duyệt thanh toán được xác nhận cho tài khoản hoặc paymaster chịu chi phí gas. Sự tách biệt này cho phép một bên phê duyệt thực thi trong khi tài khoản khác phê duyệt thanh toán gas.
Không. Kế toán gas của Giao dịch Frame ngăn không cho một frame vay gas chưa dùng từ frame khác. Mỗi frame có giới hạn gas thực thi và gas trạng thái xác định, trong khi tổng giới hạn gas của giao dịch bao gồm gas nội tại cộng với giới hạn thực thi của các frame liên quan.
Paymaster canonical tuân theo triển khai định nghĩa bởi giao thức mà mã hợp đồng phải khớp với đặc tả mong đợi. Node có thể theo dõi cam kết gas đang chờ của nó dễ dự đoán hơn. Paymaster non-canonical có các hạn chế mempool nghiêm ngặt hơn, bao gồm giới hạn một giao dịch đang chờ, nhằm giảm rủi ro vô hiệu hóa hàng loạt và denial-of-service.
Nội dung này chỉ dùng cho mục đích giáo dục. EIP-8141 vẫn là một phần của lộ trình giao thức Ethereum, và các chi tiết đặc tả có thể thay đổi trước khi kích hoạt mainnet.











