Vitalik Buterin ủng hộ Frame Transactions giữa tranh luận AA Ethereum

Cộng đồng phát triển Ethereum đang tranh luận cách triển khai account abstraction (AA) ở cấp giao thức, trong đó đề xuất EIP-8141 “Frame Transactions” nổi lên như một ứng viên tính năng chính cho hard fork Hegota.

Cuộc thảo luận tập trung vào việc thay đổi cách ủy quyền giao dịch và trả phí gas: đưa logic vào smart contract (Frame) hay nhúng tính năng trực tiếp vào định dạng giao dịch (Tempo). Vitalik Buterin cho rằng Frame Transactions có thể mở rộng các ca sử dụng về quyền riêng tư, chống kiểm duyệt và đơn giản hóa kiến trúc ví.

Tranh luận về native account abstraction đang tăng tốc trước hard fork Hegota

Native account abstraction đang được thúc đẩy mạnh trong cộng đồng Ethereum, với nhiều EIP xuất hiện gần đây và EIP-8141 nhận được sự chú ý như một hướng triển khai trọng tâm cho nâng cấp Hegota.

Trong những tuần gần đây, các đề xuất về AA ở cấp giao thức xuất hiện dồn dập khi nhà phát triển tìm cách cải thiện trải nghiệm ví và linh hoạt hóa cách xác thực giao dịch. EIP-8141, còn được gọi là “Frame Transactions”, được đưa ra như một lựa chọn có thể trở thành tính năng chính của hard fork.

Cuộc trao đổi diễn ra công khai trên mạng xã hội, bao gồm cả luồng thảo luận của Derek Chiang (ZeroDev), sau đó Vitalik Buterin phản hồi về tiềm năng của hướng “Frame” đối với quyền riêng tư và chống kiểm duyệt.

EIP-8141 định hình “Frame Transactions” bằng cách chuyển ủy quyền giao dịch sang smart contract

EIP-8141 đề xuất loại bỏ trường chữ ký nhúng trong giao dịch và thay vào đó truyền chữ ký, cùng logic ủy quyền, dưới dạng dữ liệu cho smart contract để hợp đồng xác thực và cho phép thực thi.

Khác với định dạng giao dịch truyền thống, Frame Transactions không coi chữ ký là một trường cố định trong payload. Thay vào đó, phần “ai được phép làm gì” được mã hóa thành logic có thể lập trình trong hợp đồng, giúp cơ chế xác thực và thanh toán phí trở nên linh hoạt hơn.

Đề xuất cũng đưa vào một opcode mới tên APPROVE, nhằm cho phép smart contract ủy quyền việc gửi giao dịch, thanh toán gas, hoặc cả hai. Theo mô tả trong đề xuất, cấu trúc này có thể hỗ trợ hệ chữ ký thay thế, tài trợ gas có điều kiện, và cơ chế giao dịch ưu tiên quyền riêng tư.

Một ví dụ được nêu là tài trợ gas có thể tổ chức thông qua hợp đồng trả phí mạng để đổi lấy chuyển token, trong khi logic ủy quyền có thể dùng multisig hoặc các lược đồ mật mã khác. Điều này mở rộng cách thiết kế ví và trải nghiệm onboard người dùng mà không buộc họ nắm giữ ETH để trả gas ngay từ đầu.

Tuy nhiên, việc cho phép thực thi mã smart contract trong giai đoạn xác thực giao dịch cũng tạo ra thách thức vận hành. Client Ethereum có thể cần thêm lớp bảo vệ trước rủi ro tấn công từ chối dịch vụ (DoS) xuất phát từ mempool, do chi phí xử lý và bề mặt tấn công trong khâu validation có thể tăng.

Tempo Transactions nhúng các tính năng AA trực tiếp vào định dạng giao dịch

Tempo Transactions đại diện cho hướng “đóng gói tính năng” bằng cách đưa các khả năng AA phổ biến vào giao thức, giúp tích hợp đơn giản và tối ưu trải nghiệm người dùng nhưng có thể kém linh hoạt khi cần mở rộng.

Theo mô hình này, các tính năng thường được nhắc tới gồm: gas abstraction, gộp nhiều thao tác theo kiểu atomic batching, lên lịch thực thi, và phí giao dịch được tài trợ. Tất cả được tổ chức ngay trong cấu trúc giao dịch thông qua các trường dữ liệu được tiêu chuẩn hóa.

Cụ thể, các trường dạng mảng lệnh gọi có thể phục vụ atomic batching, tham số timestamp hỗ trợ giao dịch theo lịch, và một trường chữ ký bổ sung cho phép bên thứ ba đồng ký để trả gas. Người ủng hộ cho rằng cách làm này “cắm sẵn” tính năng sẽ dễ triển khai, giảm phức tạp ở tầng ứng dụng.

Điểm đánh đổi là mức độ mở rộng: khi muốn bổ sung tính năng mới, hướng Tempo có thể cần nâng cấp giao thức. Điều này làm tăng phụ thuộc vào chu kỳ hard fork và đồng thuận cộng đồng, thay vì cho phép nhà phát triển tự do “lắp ghép” cơ chế mới ở tầng hợp đồng.

Frame Transactions ưu tiên nguyên thủy tổng quát để tùy biến chữ ký, quyền hạn và trả gas

Frame Transactions chọn cách cung cấp nguyên thủy tổng quát, để logic chữ ký, phân quyền và trả gas được triển khai bằng smart contract, từ đó linh hoạt hơn khi xây hệ thống tùy biến.

Thay vì đưa sẵn từng tính năng vào format, hướng Frame tạo điều kiện để nhà phát triển tự thiết kế cơ chế xác thực và quyền hạn theo nhu cầu, ví dụ: chữ ký thay thế, quy tắc phê duyệt có điều kiện, hoặc mô hình sponsor gas gắn với các hành vi cụ thể.

Trọng tâm của tranh luận vì vậy không chỉ là “tính năng nào tốt hơn”, mà là triết lý thiết kế: ưu tiên sự thuận tiện tích hợp ngay (Tempo) hay ưu tiên nền tảng mở để sáng tạo và mở rộng ở tầng hợp đồng (Frame).

Vitalik Buterin nhấn mạnh lợi ích về quyền riêng tư và chống kiểm duyệt của Frame Transactions

Vitalik Buterin cho rằng Frame Transactions có thể hỗ trợ “đuôi dài” các ca sử dụng về quyền riêng tư và chống kiểm duyệt, bao gồm khả năng vận hành mà không cần trung gian phát tán giao dịch công khai.

Trong phản hồi công khai, Vitalik đề cập rằng cơ chế này có thể giúp các hệ thống quyền riêng tư như Railgun và các giao thức khác tương tác trực tiếp với chức năng mạng như FOCIL, đồng thời vẫn giữ được tính chống kiểm duyệt. Tâm điểm là giảm phụ thuộc vào “public broadcaster intermediaries”, vốn có thể trở thành điểm nghẽn hoặc điểm bị kiểm soát.

“Đây là một bài viết hay… Frame txs cũng nhằm bao phủ một ‘đuôi dài’ các trường hợp sử dụng về quyền riêng tư và chống kiểm duyệt. Chúng cho phép Railgun, PP, v.v. hoạt động mà không cần các bên trung gian phát tán công khai…”
– Vitalik Buterin, bài đăng trên X (9/3/2026)

Thiết kế ví có thể đơn giản hơn nếu EIP-8141 được áp dụng

Vitalik Buterin nhận định EIP-8141 có thể giúp ví trở nên gọn hơn, chuyển nhiều chức năng hiện nằm trong smart contract ví ra ngoài, nhờ cấu trúc ủy quyền mới dựa trên Frame Transactions.

Ông cũng nêu rằng khái niệm “mỗi ví là một smart contract” đã được triển khai thành công ở hệ sinh thái khác, đồng thời nhắc đến thiết kế ví multisignature của Bitcoin như một ví dụ về cách tiếp cận có thể đơn giản và đáng tin cậy.

Theo quan điểm của Vitalik, ví xây theo EIP-8141 có thể tương đối tối giản và chỉ thực hiện một số thao tác, tương tự cách script của Bitcoin hoạt động. Một số tính năng hiện thường được nhét vào hợp đồng ví lớn, như batching giao dịch và tính toán signature hash, có thể được “đẩy ra ngoài” để giảm độ phức tạp và bề mặt lỗi.

Những câu hỏi thường gặp

EIP-8141 (Frame Transactions) khác gì giao dịch Ethereum truyền thống?

Khác biệt chính là giao dịch không còn chứa trường chữ ký cố định; thay vào đó, chữ ký và logic ủy quyền được truyền như dữ liệu để smart contract xác thực. Điều này giúp tùy biến cơ chế ký và phân quyền linh hoạt hơn.

APPROVE opcode trong EIP-8141 dùng để làm gì?

APPROVE được đề xuất để smart contract có thể ủy quyền việc gửi giao dịch, trả gas, hoặc cả hai. Mục tiêu là chuyển quy tắc phê duyệt và thanh toán từ “trường cố định” sang logic lập trình được.

Tempo Transactions và Frame Transactions đại diện cho hai hướng nào?

Tempo nhúng sẵn các tính năng AA phổ biến vào định dạng giao dịch để dễ tích hợp và tối ưu UX. Frame cung cấp các nguyên thủy tổng quát, để nhà phát triển tự triển khai chữ ký, quyền hạn và trả gas bằng smart contract nhằm tăng khả năng tùy biến.

Vì sao Frame Transactions được cho là có ích cho quyền riêng tư và chống kiểm duyệt?

Vitalik cho rằng Frame Transactions có thể giúp các ứng dụng quyền riêng tư hoạt động mà không cần trung gian phát tán giao dịch công khai, đồng thời hỗ trợ tương tác trực tiếp với các chức năng mạng như FOCIL mà vẫn giữ tính chống kiểm duyệt.

Rủi ro kỹ thuật nào có thể phát sinh khi xác thực giao dịch chạy logic smart contract?

Do có khả năng thực thi mã trong giai đoạn xác thực, client Ethereum có thể cần cơ chế phòng vệ bổ sung trước rủi ro DoS từ mempool, vì kẻ tấn công có thể tạo tải tính toán bất lợi trong quá trình validation.