EIP-8141: Tại sao Account Abstraction bản địa không phải là tính năng nổi bật trong bản nâng cấp Hegota của ethereum

Bài viết bởi imToken

Tuần trước, tại hội nghị các nhà phát triển lõi Ethereum, đề xuất EIP-8141 đã được thảo luận chính thức về việc đưa vào bản nâng cấp Hegota, kết quả gây bất ngờ khi đề xuất do Vitalik trực tiếp ủng hộ không được xếp vào danh mục "tính năng nổi bật" của Hegota, mà chỉ nhận trạng thái "đang xem xét đưa vào" (CFI).

Tuần này, nhóm Google Quantum AI đã công bố bản trắng mới, cho biết trong các giả định phần cứng đã cho, ước tính số lượng qubit vật lý cần thiết để phá vỡ ECDLP-256 đã giảm đáng kể 20 lần so với trước đây. Mặc dù điều này không có nghĩa là các cuộc tấn công lượng tử đang ở ngay trước mắt, nhưng nó thực sự nhắc nhở chúng ta rằng nếu hệ thống tài khoản trong tương lai không thể linh hoạt thay đổi logic xác thực, thì nhiều cuộc thảo luận hiện nay về trải nghiệm ví cuối cùng có thể trở thành các vấn đề bảo mật.

Mặc dù xét từ góc độ thực tế của việc thúc đẩy giao thức, EIP-8141 hiện vẫn còn quá nặng nề, đặc biệt là về việc triển khai client, an toàn của transaction pool và độ phức tạp của xác minh, chưa tạo được sự đồng thuận đủ vững chắc.

Nhưng ở thời điểm hiện tại, những điểm đáng để thảo luận và xem xét kỹ lưỡng về EIP-8141 dường như ngày càng nhiều hơn.

EIP-8141 do Vitalik Buterin và các đóng góp viên cốt lõi như timbeiko thúc đẩy, có tên chính thức là Frame Transactions.

Nói một cách dễ hiểu hơn, mục tiêu của nó không phải là chỉ thêm một tính năng ví cụ thể, mà là cố gắng ở cấp độ giao thức để bất kỳ tài khoản nào cũng không còn bị ràng buộc bởi một đường dẫn ký ECDSA duy nhất, mà có thể sở hữu logic xác thực và thực thi linh hoạt hơn.

Điều này cũng có nghĩa rằng, đa chữ ký, tài trợ gas, xoay vòng khóa, phục hồi xã hội, thậm chí cả việc tích hợp các giải pháp chữ ký chống lượng tử trong tương lai, đều không còn chỉ là các tính năng bên ngoài được gắn thêm vào ví, mà có cơ hội trở thành những “thành viên nguyên bản” trong hệ thống tài khoản của Ethereum.

Nếu chỉ nhìn bề ngoài, EIP-8141 thảo luận về một tập hợp các khả năng trông rất cụ thể: thanh toán Gas bằng stablecoin, gộp nhiều thao tác thành một giao dịch, hỗ trợ các phương thức ký linh hoạt hơn, thậm chí dành không gian cho các chữ ký chống lượng tử trong tương lai. Có thể nói, trong nhiều năm qua, từ ERC-4337 đến EIP-7702, nhiều cải tiến xung quanh trải nghiệm ví về cơ bản đều nhằm biến tài khoản không còn chỉ là một khóa riêng, mà trở thành một cổng vào có thể tùy chỉnh quy tắc.

Vấn đề nằm ở chỗ, những cải tiến này thực sự khiến ví ngày càng giống tài khoản thông minh, nhưng vẫn chưa thực sự chạm đến mô hình tài khoản mặc định cơ bản nhất của Ethereum.

Theo thông lệ, trong hệ thống hiện tại, tài khoản Ethereum được chia thành hai loại chính. Một loại là tài khoản do bên ngoài sở hữu, tức là EOA mà mọi người quen thuộc nhất, được kiểm soát bởi khóa riêng và có thể chủ động khởi tạo giao dịch, nhưng thiếu khả năng lập trình; loại còn lại là tài khoản hợp đồng, tức là chính các hợp đồng thông minh, có thể thực thi logic phức tạp nhưng không thể tự chủ động khởi tạo giao dịch.

Điều này khiến khả năng khởi tạo giao dịch bị ràng buộc lâu dài với chữ ký của một khóa riêng duy nhất; miễn là tiền đề này không thay đổi, nhiều khả năng mà người dùng hiện nay cho là hiển nhiên nên có — như linh hoạt thay đổi quy tắc chữ ký, cho phép người khác trả Gas, khôi phục quyền kiểm soát tài khoản sau khi mất khóa riêng, hoặc chuyển đổi mượt mà sang hệ thống mật mã mới trong tương lai — đều khó trở thành tính năng mặc định của tài khoản.

Nếu bạn từng sử dụng imToken hoặc các ví Web3 khác, bạn rất có thể đã gặp phải những điểm đau này, ví dụ: trong ví có rất nhiều USDC nhưng không có ETH nên không thể gửi giao dịch (vì Gas chỉ có thể thanh toán bằng ETH); mất từ khôi phục thì tiền bị mất vĩnh viễn và không thể khôi phục; một thao tác “phê duyệt + trao đổi” cần ký và xác nhận hai lần, v.v.

Những vấn đề này không phải do sản phẩm ví "không đủ tốt", mà là kết quả của thiết kế mô hình tài khoản Ethereum.

Từ góc độ này, sự phát triển trong hai năm qua thực sự đã rất rõ ràng: ERC-4337 đã triển khai tài khoản trừu tượng trên lớp ứng dụng mà không cần sửa đổi giao thức; EIP-7702 tiếp tục chứng minh rằng EOA hoàn toàn không phải là không thể mở rộng, ít nhất có thể tạm thời đạt được một số khả năng tương tự tài khoản thông minh.

Nói cách khác, Ethereum không phải là không muốn thực hiện trừu tượng tài khoản, mà đang dần tiếp cận vấn đề này theo cách nhẹ nhàng và bảo thủ hơn. Sự xuất hiện của EIP-8141 đánh dấu một bước ngoặt mới trên con đường này. Thay vì chỉ thêm một lớp khả năng tài khoản thông minh bên ngoài hệ thống hiện tại, nó cố gắng tích hợp trực tiếp trừu tượng tài khoản vào chính mô hình giao dịch, giúp tài khoản có sẵn logic xác thực và thực thi có thể lập trình ngay từ cấp độ giao thức.

Đây cũng là lý do tại sao EIP-8141 lại được quan tâm trở lại hôm nay. Một mặt, trải nghiệm ví cấp cao đã ngày càng gần với tài khoản trừu tượng bản địa, và tầng giao thức cuối cùng cũng cần phải bắt kịp; mặt khác, áp lực lâu dài từ máy tính lượng tử đang khiến câu hỏi “liệu tài khoản có thể linh hoạt thay đổi cách ký tên” chuyển từ một vấn đề kỹ thuật xa vời thành một vấn đề thực tế cần được xem xét nghiêm túc.

Cuối cùng, EIP-8141 giới thiệu một loại giao dịch hoàn toàn mới — giao dịch khung (Frame Transaction), với mã loại giao dịch là 0x06.

Nếu logic cơ bản của giao dịch Ethereum truyền thống là một giao dịch tương ứng với một lần gọi, thì EIP-8141 nhằm mục đích tách một giao dịch thành một nhóm các “khung” có thể được thực thi theo thứ tự quy định, từ đó tách riêng ba việc vốn bị ràng buộc cùng nhau: xác minh, thanh toán và thực thi.

Mỗi «khung» có ba chế độ thực thi:

• VERIFY (xác thực khung): chịu trách nhiệm xác minh giao dịch có hợp lệ hay không, nó sẽ chạy logic xác thực tùy chỉnh của tài khoản; nếu thành công, nó sẽ gọi mã thao tác APPROVE mới được giới thiệu để cấp quyền thực thi và chỉ định giới hạn Gas.
• SENDER (gửi khung): Thực hiện các thao tác thực tế như chuyển tiền, gọi hợp đồng, v.v. Địa chỉ người gọi là chính người gửi giao dịch.
• DEFAULT (khung đầu vào): Sử dụng địa chỉ đầu vào hệ thống làm người gọi, dùng cho các tình huống như triển khai hợp đồng, xác minh Paymaster;

Ý nghĩa của cơ chế này không phải là làm cho giao dịch trở nên phức tạp hơn, mà là lần đầu tiên tách riêng ba việc “xác minh, thanh toán, thực thi” ra khỏi các hành động tài khoản và giao cho giao thức điều phối bản địa.

Trong quá khứ, việc xác minh giao dịch, thanh toán Gas và thực hiện các thao tác thực tế đều bị ràng buộc trong cùng một hành động tài khoản; nhưng trong thiết kế của EIP-8141, những việc này có thể được tách thành các khung khác nhau và được giao thức thực hiện theo thứ tự rõ ràng. Chính vì vậy, tài khoản không còn chỉ phụ thuộc vào một khóa riêng duy nhất để “ký toàn bộ”, mà bắt đầu mang hình thái gần giống với một thực thể thực thi có thể lập trình.

Một ví dụ cụ thể: Giả sử bạn muốn sử dụng USDC để thanh toán phí Gas nhằm thực hiện một giao dịch Swap, trong khuôn khổ EIP-8141, quy trình này về lý thuyết có thể được tổ chức thành một chuỗi khung hoàn chỉnh: trước tiên, tài khoản xác minh chữ ký và quyền thực thi, sau đó bên thanh toán hoặc Paymaster xác minh điều kiện sẵn sàng chịu chi phí, tiếp theo là thanh toán phí cho tài sản tương ứng, và cuối cùng mới thực hiện thao tác Swap thực sự.

Như vậy, phí Gas và giao dịch chính có thể được đưa vào cùng một quy trình nguyên tử, hoặc cả hai thành công, hoặc cả hai bị hoàn lại.

Đối với người dùng, sự thay đổi trực quan nhất là nhiều thao tác trước đây buộc phải chia thành hai hoặc ba bước, với rủi ro thất bại ở giữa, trong tương lai sẽ hoạt động giống như một hành động hoàn chỉnh. Do đó, tính nguyên tử này cũng là một trong những yếu tố then chốt mà EIP-8141 nhằm giải quyết vấn đề trải nghiệm người dùng bị phân mảnh.

Điều đó có nghĩa gì đối với người dùng ví? Về mặt kết quả, những thay đổi trực quan nhất ít nhất có bốn cấp độ:

• Phí gas được trừu tượng hóa: Việc bạn có stablecoin trong ví không còn nghĩa là bạn phải chuẩn bị thêm một chút ETH để thực hiện thao tác; trong tương lai, việc DApp, Paymaster hoặc các bên tài trợ khác trả phí gas sẽ trở nên tự nhiên hơn;
• Các thao tác nhiều bước đã được gộp lại: các quy trình thường yêu cầu nhiều lần ký tên như “phê duyệt + Swap” hoặc “phê duyệt + stakes” hiện nay có thể được đóng gói thành một thao tác hoàn chỉnh hơn;
• Các quy tắc bảo mật tài khoản đã được kích hoạt: đa chữ ký, khôi phục xã hội, hạn mức hàng ngày, khóa thời gian và thay đổi khóa, những tính năng này không còn chỉ là các tính năng nâng cao bổ sung của một sản phẩm ví, mà bắt đầu có cơ hội được xây dựng trên logic tài khoản gốc hơn;
• Hệ thống chữ ký không còn bị khóa chặt trên một con đường duy nhất là ECDSA: điều này lần đầu tiên mang lại khả năng về mặt giao thức để chuyển đổi tài khoản sang các hệ thống mật mã khác, bao gồm cả các sơ đồ chữ ký sau lượng tử;

Một điểm rất dễ bị bỏ qua nhưng cực kỳ quan trọng đối với người dùng ví là: ngay cả khi EIP-8141 cuối cùng được triển khai, hệ thống tài khoản hiện tại cũng sẽ không bị thay thế hoàn toàn.

Ngay cả khi bạn đang sử dụng ví Web3 hiện có như imToken, bạn cũng không cần phải di chuyển, vì nó tương thích ngược, các địa chỉ EOA hiện có vẫn có thể tiếp tục sử dụng, chỉ cần chọn “nâng cấp” logic xác thực tài khoản vào thời điểm phù hợp.

Tuy nhiên, nhìn ngược lại, chính vì sự thay đổi này quá sâu sắc, nên nó đã không trở thành tính năng hàng đầu trong cuộc thảo luận mới nhất của Hegotá. Tuy nhiên, theo quy trình EIP champion năm 2026, ý nghĩa của CFI (Considered for Inclusion) không phải là bị từ chối, mà là đã bước vào giai đoạn xem xét nghiêm túc, nhưng vẫn chưa đến lúc quyết định cuối cùng để triển khai.

Nói cách khác, các nhà phát triển cốt lõi không phủ nhận hướng đi của EIP-8141, mà khi công nhận giá trị của nó, họ cũng cho rằng hiện tại nó vẫn còn quá “nặng”.

Vì tài khoản nguyên sinh không giống ERC-4337 có thể được thúc đẩy dần dần bởi một số ví, cơ sở hạ tầng và ứng dụng, mà khi nó được đưa vào lớp giao thức, điều đó có nghĩa là tất cả các client lớp thực thi đều phải triển khai, kiểm thử và phối hợp nghiêm túc, điều này tự nhiên làm tăng rào cản triển khai và khiến các nhà phát triển cốt lõi có xu hướng lựa chọn phương án an toàn hơn khi lập kế hoạch phân nhánh.

Vậy thì điều gì sẽ xảy ra tiếp theo? Có thể chia thành hai hướng để xem xét:

• EIP-8141 hiện đang ở trạng thái CFI, điều này cho thấy nó vẫn đang được đánh giá liên tục; tác giả đề xuất sẽ tiếp tục bổ sung các chi tiết quan trọng liên quan đến bảo mật hồ sơ giao dịch, quy tắc xác thực và triển khai client, và các cuộc họp ACD trong tương lai cũng sẽ xem xét lại xem liệu nó có đủ điều kiện để tiếp tục tiến triển hay không;
• Nếu những sự không chắc chắn này có thể được nén liên tục, chúng sẽ có cơ hội tiến vào giai đoạn tích hợp thực chất hơn trong các bản nâng cấp tiếp theo; nếu không, chúng cũng hoàn toàn có thể bị hoãn đến chu kỳ nâng cấp muộn hơn;

Một cách thực tế, EIP-8141 không phải là đề xuất trừu tượng tài khoản bản địa duy nhất, cũng không phải là một giải pháp chữ ký hậu lượng tử sẵn có để trực tiếp giải quyết vấn đề máy tính lượng tử, nhưng tầm quan trọng của nó nằm ở chỗ, đây là lần đầu tiên cung cấp một lối thoát ở cấp độ giao thức để tài khoản thoát khỏi con đường đơn lẻ của ECDSA.

Từ góc độ này, giá trị thực sự của EIP-8141 không nằm ở việc nó có phải là câu trả lời duy nhất đúng đắn hay không, mà ở chỗ nó lần đầu tiên trình bày một cách đầy đủ câu hỏi “cuối cùng của tài khoản trừu tượng bản địa nên trông như thế nào” lên bàn thảo luận của giao thức Ethereum.

Đó không phải là giải pháp duy nhất, nhưng nó thực sự là một trong những giải pháp đầy tham vọng nhất và gần với giới hạn tưởng tượng của “AA thuần túy hoàn chỉnh” hiện nay.

Dù EIP-8141 cuối cùng có kịp bắt kịp Hegotá hay không, cuộc thảo luận này ít nhất đã cho thấy một điều:

Ethereum không ngồi yên chờ vấn đề phát triển, mà đang từng bước kiên trì xây dựng nền tảng cho hệ thống tài khoản thế hệ tiếp theo.