Trừu tượng hóa tài khoản từ những nguyên lý đầu tiên

Nếu bạn từng dùng một ví tự lưu ký trên Ethereum, bạn đã dùng một tài khoản sở hữu bên ngoài — một EOA — dù bạn có biết hay không. Câu chuyện về trừu tượng hóa tài khoản bắt đầu từ việc hiểu EOA là gì, vì sao thiết kế của nó ràng buộc mọi thứ bạn có thể làm on-chain, và làm thế nào trừu tượng hóa tài khoản ERC-4337 vòng qua những ràng buộc đó mà không động đến giao thức nền. Bài viết này là điểm vào của một loạt bài đưa bạn đi từ các ràng buộc ban đầu cho đến cách SSP dùng trừu tượng hóa tài khoản để vận hành multisig 2-trên-2 của mình trên các chuỗi EVM.

Đây là bài nền tảng, mang tính khái niệm. Để có một phần đi sâu tập trung vào chính chuẩn ERC-4337, hãy đọc Trừu tượng hóa tài khoản (ERC-4337) là gì? kèm với bài này; ở đây chúng ta xây dựng trực giác về vì sao chuẩn này tồn tại.

Tài khoản mà Ethereum trao cho bạn

Ethereum có hai loại tài khoản. Tài khoản hợp đồng được quản trị bằng mã. EOA — những ví thông thường mà phần lớn mọi người dùng — được quản trị bằng một khóa riêng duy nhất. Ai nắm khóa đó có thể ủy quyền bất kỳ giao dịch nào từ tài khoản, và giao thức xác thực đúng một điều: rằng giao dịch mang một chữ ký ECDSA hợp lệ trên đường cong secp256k1, do khóa kiểm soát địa chỉ tạo ra.

Quy tắc duy nhất đó thanh lịch, và nó cũng là nguồn gốc của mọi ràng buộc bàn đến bên dưới. Tính hợp lệ của một giao dịch được nối cứng vào giao thức. Bạn, chủ tài khoản, không được quyết định "hợp lệ" nghĩa là gì. Giao thức quyết định, và nó chỉ biết kiểm tra một sơ đồ chữ ký của một khóa.

Điều mà thiết kế đó cài cắm tận gốc

Bốn ràng buộc nảy sinh trực tiếp từ mô hình một khóa, một chữ ký:

• Một khóa là một điểm hỏng đơn lẻ. Mất khóa thì tiền biến mất. Lộ khóa thì kẻ tấn công có tất cả. Ở cấp giao thức không có yếu tố thứ hai, không có người đồng ký, không có chính sách nào có thể chặn vụ trộm.
• Không có logic xác thực tùy chỉnh. Một EOA không thể nói "yêu cầu hai chữ ký", cũng không thể nói "tự động cho phép khoản thanh toán nhỏ này nhưng yêu cầu phê duyệt thêm khi vượt ngưỡng", cũng không thể nói "chỉ cho khóa này chi tiêu vào ngày thường". Tài khoản không có logic. Nó có một bước kiểm tra chữ ký.
• Người gửi phải giữ ETH để trả gas. Mỗi giao dịch EOA trả gas của chính nó bằng ETH. Một người dùng mới chỉ giữ một token ERC-20 mà không có ETH thì không thể di chuyển token đó, vì họ không trả được phí. Người trả phí và người gửi giao dịch buộc phải là cùng một tài khoản.
• Trải nghiệm cụm từ khôi phục (seed phrase) không khoan nhượng. Vì khóa chính là tài khoản, việc bắt đầu nghĩa là ghi lại một cụm từ khôi phục và bảo vệ nó mãi mãi. Không có lối khôi phục nào không dính đến cụm từ đó, và một sai lầm là vĩnh viễn.

Đây không phải lỗi. Đây là hệ quả của việc xác thực ngụ ở giao thức thay vì ở tài khoản.

Ý tưởng cốt lõi: làm cho tài khoản có thể lập trình

Trừu tượng hóa tài khoản là ý tưởng đưa logic xác thực đó ra khỏi giao thức và đặt vào chính tài khoản. Thay vì mạng nối cứng "một giao dịch hợp lệ nếu nó có một chữ ký ECDSA đúng", một smart account — một hợp đồng giữ tiền của bạn — tự nó quyết định cái gì được tính là giao dịch hợp lệ.

Một khi tài khoản là một hợp đồng có thể lập trình, bốn ràng buộc tan ra thành các lựa chọn thiết kế:

• Nó có thể yêu cầu hai chữ ký thay vì một, đó chính xác là cách multisig trở nên khả thi mà không cần hỗ trợ gốc của giao thức.
• Nó có thể triển khai quy tắc khôi phục, để một khóa thất lạc không còn là dấu chấm hết cho câu chuyện.
• Nó có thể để người khác trả gas, tách người trả phí khỏi người gửi.
• Nó có thể gộp vài hành động — chẳng hạn phê duyệt và hoán đổi — thành một thao tác nguyên tử duy nhất.

Tài khoản thôi là một cặp khóa thụ động và trở thành logic có thể lập trình mà bạn kiểm soát.

ERC-4337 mang lại điều này mà không cần hard fork ra sao

Phần khó là việc thay đổi cách Ethereum xác thực giao dịch thường có nghĩa là thay đổi giao thức nền — một bản nâng cấp chậm chạp, gây tranh cãi, trên toàn mạng. ERC-4337 vòng qua điều đó hoàn toàn. Nó giới thiệu trừu tượng hóa tài khoản như một lớp bên trên mạng hiện có, không cần bất kỳ thay đổi đồng thuận nào.

Cơ chế dựa trên vài bộ phận:

• UserOperations. Thay vì gửi một giao dịch thông thường, một smart account diễn đạt ý định dưới dạng một UserOperation — một đối tượng có cấu trúc mô tả tài khoản muốn làm gì và phải được xác thực ra sao.
• Một mempool thay thế. Các UserOperations sống trong mempool riêng của chúng, tách khỏi các giao dịch thông thường.
• Bundlers. Một bundler thu thập các UserOperations từ mempool đó, đóng gói chúng lại và nộp lên chuỗi như một giao dịch thực sự, trả gas của lớp nền.
• Hợp đồng EntryPoint. Một hợp đồng EntryPoint duy nhất đã qua kiểm toán là điểm thắt cổ chai on-chain. Nó gọi vào từng smart account để chạy logic xác thực riêng của tài khoản đó, rồi thực thi thao tác nếu xác thực qua được.
• Paymasters. Một hợp đồng paymaster tùy chọn có thể đồng ý gánh gas cho một UserOperation, đó là điều làm cho các luồng không-gas và trả-bằng-token trở nên khả thi.

Ghép lại, điều này cho phép bất kỳ hợp đồng nào hành xử như một tài khoản hoàn toàn có thể lập trình, được xác thực theo quy tắc riêng của nó, trong khi giao thức Ethereum nền tảng vẫn y nguyên như cũ. Chuẩn được đặc tả trong EIP-4337, và lộ trình trừu tượng hóa tài khoản của chính Ethereum theo dõi nỗ lực rộng lớn hơn đang đi về đâu.

Vì sao điều này quan trọng với người dùng tự lưu ký

Với người tự giữ khóa của mình, trừu tượng hóa tài khoản không phải là một chi tiết giao thức trừu tượng — nó thay đổi những gì một ví có thể làm một cách an toàn:

• Multisig không cần hỗ trợ gốc. Một smart account có thể đòi nhiều hơn một chữ ký, nên một ví có thể yêu cầu hai thiết bị độc lập phê duyệt mỗi lần chuyển. Đó là viên gạch mà SSP dựa vào, được giải thích kỹ hơn trong EVM Multisig theo lối trừu tượng hóa tài khoản.
• Tùy chọn khôi phục. Xác thực có thể lập trình mở cánh cửa cho các luồng khôi phục không sụp đổ về một cụm từ khôi phục mong manh duy nhất.
• Tài trợ gas. Paymasters nghĩa là phí có thể tách rời khỏi người gửi, làm dịu nốt ma sát tệ nhất khi bắt đầu.
• Gộp lệnh. Nhiều bước có thể tất toán như một thao tác duy nhất, giảm cả số lần nhấp lẫn rủi ro hỏng giữa chừng.

Khác biệt thực tế giữa một EOA một khóa và một smart account có thể lập trình đủ lớn để xứng đáng có phần riêng — xem EOA so với smart account: những khác biệt quan trọng.

SSP nằm ở đâu

SSP là một ví tự lưu ký được xây quanh multisig 2-trên-2. Một khóa sống trong tiện ích trình duyệt SSP Wallet; khóa thứ hai sống trong ứng dụng di động SSP Key. Mọi giao dịch được dựng trong tiện ích và đồng ký trên điện thoại, nên không thiết bị nào một mình có thể di chuyển tiền.

Trên các chuỗi EVM, SSP mang lại 2-trên-2 đó bằng ERC-4337. Ví là một smart account ERC-4337 mà logic xác thực đòi cả hai khóa, và hai chữ ký một phần kết hợp lại — theo lối MuSig2 trên secp256k1 — thành một chữ ký tổng hợp Schnorr duy nhất mà hợp đồng xác minh on-chain. Các smart contracts của SSP đã được Halborn kiểm toán vào năm 2025. Thiết kế đầy đủ là chủ đề của Kiến trúc trừu tượng hóa tài khoản của SSP.

Nói cách khác, năng lực trừu tượng mô tả ở trên — một tài khoản tự thực thi quy tắc đa chữ ký của riêng nó — chính là điều SSP biến thành một ví hoạt động trên Ethereum, Polygon, Base và các chuỗi EVM được hỗ trợ khác.

Phần còn lại của loạt bài này

Bài này đã dựng nên vấn đề và ý tưởng cốt lõi. Loạt bài xây tiếp từ đây:

1. Trừu tượng hóa tài khoản từ những nguyên lý đầu tiên — bài này: vì sao EOA gây hạn chế và trừu tượng hóa tài khoản nghĩa là gì.
2. EOA so với smart account: những khác biệt quan trọng — một so sánh trực tiếp hai mô hình tài khoản.
3. Kiến trúc trừu tượng hóa tài khoản của SSP — cách SSP đấu nối ERC-4337 vào một ví 2-trên-2.
4. Tài trợ gas và paymasters được giải thích — cách paymasters tách người trả khỏi người gửi.
5. Trừu tượng hóa tài khoản trên các chuỗi không phải Ethereum — cách cùng một ý tưởng đi xa hơn Ethereum.

Hãy bắt đầu với phần giải thích ERC-4337 nếu bạn muốn chuẩn này một cách tách biệt, rồi quay lại đây để có bức tranh lớn hơn. Từ đó, tài khoản thôi là một ràng buộc và bắt đầu trở thành thứ bạn có thể lập trình xoay quanh.