Bên trong kiến trúc trừu tượng hóa tài khoản của SSP
SSP là một ví tự lưu ký được xây dựng quanh multisig 2-trên-2. Một khóa nằm trong tiện ích mở rộng trình duyệt SSP Wallet, khóa thứ hai nằm trong ứng dụng di động SSP Key, và không giao dịch nào được hoàn tất trừ khi cả hai thiết bị phê duyệt nó. Trên các chuỗi EVM, SSP thực hiện đảm bảo đó bằng account abstraction của ERC-4337: ví là một smart account mà logic xác thực của nó chấp nhận một chữ ký Schnorr tổng hợp duy nhất được dựng từ hai khóa. Bài viết này đi qua kiến trúc đó từ đầu đến cuối — từng thành phần, luồng ký chính xác, và thuộc tính bảo mật mà nó tạo ra.
Nếu account abstraction còn mới với bạn, hãy bắt đầu với Trừu tượng hóa tài khoản từ các nguyên lý đầu tiên và phần giải thích tập trung về ERC-4337. Ở đây chúng ta giả định bạn đã biết đại khái smart account và UserOperation là gì, và tập trung vào cách SSP nối chúng lại với nhau.
Các mảnh ghép mà SSP dựa vào
Trước khi lần theo luồng, gọi tên các thành phần và việc mà mỗi thành phần làm sẽ hữu ích:
- smart account. Trên các chuỗi EVM, ví SSP của bạn không phải là một EOA do một khóa duy nhất kiểm soát. Nó là một smart account ERC-4337 — một hợp đồng giữ tiền của bạn và chứa logic xác thực riêng. Logic đó là trái tim của thiết kế: nó chỉ chấp nhận một giao dịch khi chữ ký được cung cấp khớp với khóa tổng hợp kỳ vọng của ví.
- Hai thiết bị. Khóa 1 nằm trong tiện ích mở rộng trình duyệt SSP Wallet. Khóa 2 nằm trong ứng dụng di động SSP Key. Mỗi thiết bị giữ một phần và tạo ra một chữ ký một phần. Không phần nào có thể tự nó cho phép bất cứ điều gì.
UserOperation. Thay vì một giao dịch thông thường, tiện ích mở rộng biểu đạt ý định của bạn dưới dạng mộtUserOperation— một đối tượng có cấu trúc mô tả account nên làm gì và chữ ký nào cho phép điều đó.- bundler. Một bundler lấy
UserOperationra khỏi mempool chuyên dụng, đóng gói nó thành một giao dịch on-chain thực sự và trả gas của lớp nền để gửi nó đi. - EntryPoint. Một hợp đồng EntryPoint duy nhất đã được kiểm toán là cổng vào on-chain cho mọi thao tác ERC-4337. Nó gọi vào smart account của bạn để chạy logic xác thực của chính account đó, rồi kích hoạt việc thực thi nếu xác thực vượt qua.
Một paymaster có thể tùy chọn gánh gas cho một UserOperation; đó là một chủ đề riêng, được trình bày trong Tài trợ gas và paymaster được giải thích.
Luồng ký chính xác
Đây là những gì xảy ra, từng bước, khi bạn gửi một giao dịch từ SSP trên một chuỗi EVM:
SSP Wallet extension (key 1) SSP Key mobile app (key 2)
| |
| 1. initiate tx |
| 2. build UserOperation |
| 3. partial Schnorr sig --- push -->| 4. approve
| | 5. partial Schnorr sig
| |
| 6. aggregate (MuSig2 / secp256k1)
| v
| ONE Schnorr signature
| |
v v
7. UserOperation --> 8. bundler --> 9. EntryPoint --> smart account
|
validate aggregate sig
|
valid? --> execute call
Đọc dưới dạng văn xuôi:
- Bạn khởi tạo một giao dịch trong tiện ích mở rộng trình duyệt SSP Wallet, nơi giữ khóa 1.
- Tiện ích mở rộng dựng một
UserOperationERC-4337 mô tả hành động. - Khóa 1 tạo ra một chữ ký Schnorr một phần trên thao tác đó.
- Yêu cầu được đẩy tới ứng dụng di động SSP Key (khóa 2) để phê duyệt.
- Khóa 2 tạo ra chữ ký một phần của chính nó.
- Hai chữ ký một phần được tổng hợp, theo kiểu MuSig2 trên secp256k1, thành một chữ ký Schnorr.
UserOperation, giờ mang chữ ký tổng hợp duy nhất đó, đã sẵn sàng để gửi.- Nó đi tới một bundler, bên này đóng gói nó thành một giao dịch và trả gas.
- bundler gửi nó tới hợp đồng EntryPoint, hợp đồng này gọi smart account của SSP. account xác thực chữ ký tổng hợp duy nhất so với khóa tổng hợp kỳ vọng của ví và, nếu hợp lệ, thực thi lời gọi.
Cả hai thiết bị đều cần để tới được bước 6, và đó chính là điều khiến đây là một 2-trên-2 thực thụ. Bỏ đi bất kỳ chữ ký một phần nào và việc tổng hợp sẽ không thể tạo ra một chữ ký mà hợp đồng chấp nhận.
Vì sao chuỗi chỉ thấy một chữ ký
Chi tiết khiến thiết kế của SSP trở nên thanh lịch là việc tổng hợp ở bước 6. Tiện ích mở rộng và điện thoại không gắn mỗi bên một chữ ký riêng vào thao tác. Hai chữ ký Schnorr một phần của chúng kết hợp — theo kiểu MuSig2, trên cùng đường cong secp256k1 mà Ethereum đã dùng — thành một chữ ký Schnorr. smart account kiểm tra một chữ ký đó so với một khóa tổng hợp kỳ vọng duy nhất.
Điều này có hai hệ quả đáng dừng lại để xem xét:
- Dấu chân on-chain vẫn nhỏ.
UserOperationmang một chữ ký, không phải hai. Không có danh sách người ký để lưu trữ hay duyệt qua, không có vòng lặp xác minh cho từng người ký. Hợp đồng làm cùng lượng công việc xác thực như nó sẽ làm cho một người ký duy nhất. - Chuỗi không thể biết đó là multisig. Thứ đến được EntryPoint trông như một thao tác đã ký thông thường. Việc thực thi 2-trên-2 nằm ở cách chữ ký được tạo ra — qua hai thiết bị — chứ không nằm trong một cấu trúc đa bên nào nhìn thấy được trên chuỗi. Với một người quan sát bên ngoài, ví hành xử như bất kỳ smart account nào khác.
Đó là sự khác biệt giữa cách tiếp cận của SSP và một multisig ngây thơ đăng N chữ ký riêng rẽ và xác minh từng cái. Cơ chế làm multisig theo cách này trên EVM được đào sâu thêm trong Multisig EVM theo lối trừu tượng hóa tài khoản.
Mỗi thiết bị thực sự bảo vệ điều gì
Đáng để chính xác về thuộc tính bảo mật, bởi nó là toàn bộ mục đích của kiến trúc.
- Không khóa nào một mình có thể di chuyển tiền. Khóa 1 trong tiện ích mở rộng có thể dựng một
UserOperationvà ký nửa phần của nó, nhưng một nửa chữ ký tổng hợp ra thứ mà hợp đồng sẽ không chấp nhận. Khóa 2 trên điện thoại có thể phê duyệt và ký nửa phần của nó, nhưng không thể tự mình khởi tạo hay hoàn tất một lần chuyển. - Xâm phạm một thiết bị là chưa đủ. Một kẻ tấn công kiểm soát hoàn toàn tiện ích mở rộng trình duyệt của bạn vẫn không thể chi tiêu, vì nó không thể tạo ra chữ ký một phần của khóa 2 nếu không có điện thoại. Điều ngược lại cũng đúng. Mô hình đe dọa mà một EOA khóa đơn không thể sống sót — một khóa bị lộ, mất sạch — không áp dụng ở đây.
- Việc phê duyệt là tường minh và trên màn hình thứ hai. Vì bước 4 đẩy yêu cầu tới ứng dụng SSP Key, bạn nhìn thấy và phê duyệt thao tác trên một thiết bị tách biệt về mặt vật lý trước khi nó có thể được tổng hợp và gửi đi.
Đây chính là thuộc tính 2-trên-2 được mô tả trong Multisig 2-trên-2 là gì?, hiện thực hóa trên các chuỗi EVM thông qua trừu tượng hóa tài khoản thay vì một opcode multisig gốc.
Tóm lại các lợi ích
Gom các sợi chỉ lại, kiến trúc mang lại cho người dùng SSP một tổ hợp cụ thể khó có được bằng cách khác:
- Bảo mật multisig trên mọi chuỗi EVM được hỗ trợ. Cùng một thiết kế 2-trên-2 chạy trên Ethereum, Polygon, Base, BNB Smart Chain và Avalanche, bởi ERC-4337 là một tiêu chuẩn ở cấp hợp đồng chứ không phải một tính năng riêng của từng chuỗi.
- Dấu chân on-chain nhỏ. Một chữ ký tổng hợp duy nhất nghĩa là smart account xác thực như một người ký duy nhất, giữ cho việc xác minh gọn nhẹ.
- UX giống như một người ký duy nhất. Về phía bạn, nó giống việc phê duyệt một giao dịch trên hai thiết bị, chứ không phải lập một ủy ban. Không có địa chỉ đồng ký để quản lý và không có hợp đồng multisig riêng phải cấu hình cho mỗi lần chuyển.
- Không cần thay đổi giao thức. Vì mọi thứ chạy trên ERC-4337, SSP có được tất cả những điều này mà không phải chờ trừu tượng hóa tài khoản ở lớp nền được phát hành.
Một ghi chú về kiểm toán
Một kiến trúc bảo mật chỉ đáng tin tới mức nó được rà soát. Các smart contracts của SSP đã được Halborn kiểm toán vào năm 2025. Một cuộc kiểm toán bên ngoài không làm cho bất kỳ hệ thống nào trở nên hoàn hảo, nhưng nó là một tín hiệu tin cậy có ý nghĩa cho logic hợp đồng thực thi quy tắc 2-trên-2 được mô tả ở trên.
Đi đâu tiếp theo
Bài viết này đã lần theo trừu tượng hóa tài khoản của SSP từ đầu đến cuối. Để đi sâu hơn vào tiêu chuẩn và các khái niệm xung quanh:
- Trừu tượng hóa tài khoản từ các nguyên lý đầu tiên — vì sao EOA mang tính hạn chế và trừu tượng hóa tài khoản nghĩa là gì.
- Trừu tượng hóa tài khoản (ERC-4337) là gì? — tiêu chuẩn xét riêng lẻ, gồm vai trò của
UserOperation, bundler và EntryPoint. - Tài trợ gas và paymaster được giải thích — cách một
paymastercó thể gánh gas cho mộtUserOperation. - Multisig EVM theo lối trừu tượng hóa tài khoản — cơ chế multisig trên EVM chi tiết hơn.
Về đặc tả chính thức, xem EIP-4337; về nỗ lực rộng hơn, lộ trình trừu tượng hóa tài khoản của Ethereum theo dõi hướng đi của nó. Điểm mấu chốt: SSP biến lời hứa trừu tượng về một account khả lập trình thành một ví 2-trên-2 cụ thể, nơi hai thiết bị tạo ra một chữ ký và chuỗi chỉ đơn giản thấy một thao tác hợp lệ.
