Chọn cách tiếp cận của bạn

Bây giờ bạn đã hiểu bốn kiến trúc mật mã cơ bản của ví nhúng: chữ ký ngưỡng MPC, lưu trữ khóa TEE/HSM, ví thông minh gốc passkey và hệ thống người ký mô-đun. Bài học này cung cấp một khung để lựa chọn giữa chúng dựa trên yêu cầu cụ thể của bạn, không phải các tuyên bố chỉ có giá trị tiếp thị.

Khung quyết định

Chọn kiến trúc ví nhúng không phải là tìm "tùy chọn tốt nhất". Mà là cái phù hợp các thuộc tính kỹ thuật và nhu cầu người dùng. Bắt đầu với những câu hỏi sau:

Ai là người dùng của bạn?

Người dùng am hiểu crypto có ví hiện có, hiểu các cụm từ khôi phục, và có thể không tin tưởng quản lý khóa bên thứ ba. Họ muốn có nhiều lựa chọn, không phải đơn giản hóa.

Người dùng phổ thông không biết hoặc không quan tâm đến blockchain. Họ muốn các ứng dụng "chỉ hoạt động". Bất kỳ sự khó khăn nào vượt quá xác thực ứng dụng tiêu chuẩn đều không chấp nhận được.

Người dùng doanh nghiệp cần các bản ghi được kiểm toán, tuân thủ tài liệu và khả năng tích hợp với các hệ thống nhận dạng hiện có.

Tần suất ký như thế nào?

Ký hiếm (ví dụ: đăng ký hàng tháng, mua hàng thỉnh thoảng): Ví ngoài qua MWA có thể đủ. Kiến trúc đơn giản hơn, ít phụ thuộc nhà cung cấp hơn.

Ký thường xuyên (ví dụ: trò chơi, tương tác xã hội): Ví nhúng cải thiện đáng kể trải nghiệm người dùng. Mỗi lời nhắc ví ngoài là một sự bất tiện.

Ký liên tục (ví dụ: giao dịch tự động, bot): Khóa phiên hoặc ví xác thực API. Không thể yêu cầu phê duyệt của con người cho mọi hành động.

Yêu cầu khôi phục của bạn là gì?

Chấp nhận mất mát (ví dụ: số dư nhỏ, tài sản trò chơi): Khôi phục đơn giản hoặc thậm chí không cần khôi phục có thể ổn. Người dùng có thể tạo ví mới.

Khôi phục quan trọng (ví dụ: tài khoản tài chính chính): Cần nhiều cách khôi phục. Sao lưu phần cứng, khôi phục từ xã hội hoặc khôi phục được hỗ trợ bởi nhà cung cấp.

Khôi phục được quản lý (ví dụ: dịch vụ tài chính): Có thể yêu cầu các thỏa thuận giám sát hoặc bán giám sát với các quy trình khôi phục được tài liệu hóa.

So sánh kiến trúc

MPC với TEE/HSM

Chọn MPC khi:

• Tin cậy phi tập trung là quan trọng

• Bạn muốn nhiều tùy chọn sao lưu

• Có thể cần xuất khóa

Chọn TEE/HSM khi:

• Kiến trúc đơn giản hơn được ưu tiên

• Tin cậy nhà cung cấp được chấp nhận

• Tốc độ ký quan trọng

MPC với Passkey-Native

Chọn MPC khi:

• Người dùng cần nhiều phương thức xác thực

• Khôi phục được hỗ trợ bởi nhà cung cấp là quan trọng

• Khả năng di động khóa quan trọng

Chọn Passkey-Native khi:

• Giả định tin cậy tối thiểu là cần thiết

• Người dùng có thiết bị hỗ trợ passkey

• Cơ sở hạ tầng nhà cung cấp không nên nằm trong lộ trình quan trọng

Tác nhân ký đơn với mô-đun

Chọn tác nhân ký đơn khi:

• Phương thức xác thực của bạn cố định và đã biết

• Đơn giản là ưu tiên hàng đầu

• Phạm vi kiểm toán bảo mật nên tối thiểu

Chọn tác nhân ký mô-đun khi:

• Người dùng khác nhau cần các phương thức xác thực khác nhau

• Người dùng có thể nâng cấp xác thực theo thời gian

• Yêu cầu kinh doanh có thể phát triển

Lựa chọn nhà cung cấp

Một khi bạn đã xác định được nhu cầu kiến trúc của mình, các nhà cung cấp cụ thể sẽ trở nên phù hợp.

Để tối đa hóa sự linh hoạt

Privy cung cấp các tùy chọn xác thực đa dạng nhất (email, điện thoại, xã hội, passkey, ví bên ngoài) với SDK di động được hoàn thiện. Mô hình lai của họ phục vụ cả ví nhúng và ví kết nối MWA.

Phù hợp nhất cho: Ứng dụng phục vụ đa dạng đối tượng, áp dụng Web3 dần dần, người dùng lai giữa quen thuộc với tiền điện tử và truyền thống.

Khóa có thể di động

Dynamic cung cấp xuất khóa đầy đủ và sao lưu Google Drive. Người dùng có thể trích xuất khóa riêng hoàn chỉnh nếu họ chọn tự quản lý.

Phù hợp nhất cho: Người dùng có thể muốn chuyển sang tự quản lý, ứng dụng nơi quyền sở hữu khóa có ý nghĩa triết lý.

Để kiểm soát hạ tầng

Turnkey tách biệt hạ tầng khóa khỏi xác thực. Bạn cung cấp lớp định danh của riêng mình; Turnkey cung cấp HSM và ký an toàn.

Phù hợp nhất cho: Các nhóm có hệ thống xác thực hiện có, ứng dụng yêu cầu luồng định danh tùy chỉnh, linh hoạt tích hợp tối đa.

Thuần passkey

LazorKit là thuần passkey với không có nhà cung cấp trong đường dẫn ký. Ví thông minh là một PDA được điều khiển trực tiếp bởi các chữ ký passkey được xác minh trên chuỗi.

Phù hợp nhất cho: Tối đa phân quyền, ứng dụng nơi người dùng có thiết bị hiện đại, khi không thể chấp nhận tin cậy nhà cung cấp.

Đa chuỗi

Para (trước đây là Capsule) cung cấp ví MPC hỗ trợ Solana, chuỗi EVM và Cosmos từ xác thực hợp nhất.

Phù hợp nhất cho: Ứng dụng đa chuỗi, danh mục đầu tư trải dài nhiều hệ sinh thái, định danh đa chuỗi hợp nhất.

Linh hoạt mô-đun

Crossmint cung cấp ví thông minh với nhiều loại tác nhân ký có thể gắn vào cùng một ví. Bắt đầu đơn giản, thêm bảo mật khi cần.

Phù hợp nhất cho: Yêu cầu bảo mật phát triển, đa dạng người dùng, ứng dụng trải dài từ lưu ký đến tự quản lý.

Tin cậy thuần Solana

Phantom Connect tạo ví nhúng qua OAuth (Google/Apple) với lưu trữ TEE/HSM. Người dùng được tích hợp mô phỏng giao dịch và bảo vệ spam của Phantom.

Phù hợp nhất cho: Ứng dụng tập trung vào Solana nơi người dùng đã tin tưởng Phantom, ứng dụng tiêu dùng ưu tiên thương hiệu quen thuộc.

Đơn giản không mật khẩu

Magic Link sử dụng liên kết ma thuật email hoặc mã SMS với vùng bảo mật Fortanix SGX. Quy trình xác thực cực kỳ đơn giản cho người dùng không chuyên.

Phù hợp nhất cho: Ứng dụng nơi email là định danh người dùng chính, tham gia lần đầu đơn giản với ít quyết định.

Tùy chỉnh mở rộng

Web3Auth (MetaMask Embedded) cung cấp triển khai MPC tùy chỉnh nhất với hàng chục nhà cung cấp đăng nhập xã hội, xác thực tùy chỉnh và tích hợp trừu tượng hóa tài khoản.

Phù hợp nhất cho: Ứng dụng yêu cầu nhà cung cấp xác thực cụ thể, tích hợp doanh nghiệp, các trường hợp sử dụng trừu tượng hóa tài khoản.

Cân nhắc chi phí

Các ví nhúng có các chi phí khác ngoài kết nối ví truyền thống:

Chi phí trực tiếp

Phí trên mỗi người dùng: Hầu hết các nhà cung cấp tính phí người dùng hoạt động hàng tháng (MAU) sau các mức miễn phí.

Phí giao dịch: Nếu sử dụng paymasters, bạn phải trả gas. Điều này tăng lên với khối lượng giao dịch cao.

Phí hạ tầng: Cuộc gọi API, tích hợp webhook, hỗ trợ cao cấp.

Chi phí gián tiếp

Độ phức tạp tích hợp: Hệ thống tinh vi hơn đòi hỏi nhiều thời gian phát triển hơn.

Yêu cầu kiểm thử: Kiểm thử trên thiết bị thực là bắt buộc. Trình giả lập không có vùng bảo mật.

Khóa nhà cung cấp: Chuyển đổi nhà cung cấp yêu cầu di chuyển cả người dùng, điều này có thể đồng nghĩa với địa chỉ ví mới.

Ước tính chi phí của bạn

Xem xét các biến số sau:

• Số lượng MAU dự kiến trong năm 1, năm 2, năm 3

• Số giao dịch trung bình mỗi người dùng mỗi tháng

• Bạn có tài trợ gas (chi phí paymaster) không

• Cấp độ hỗ trợ cần thiết

Các mức miễn phí thường bao phủ việc tạo mẫu và người dùng đầu tiên. Dự trù ngân sách cho bản chính thức từ đầu.

Đánh giá bảo mật

Khi đánh giá nhà cung cấp, hãy nhìn xa hơn sự tiếp thị:

Câu hỏi chính

Tạo khóa: Nó có được phân phối (DKG) hay một bên tạo và chia sẻ?

Threshold scheme: T-of-n là gì? Ai giữ các phần được chia sẻ? Điều gì xảy ra nếu nhà cung cấp bị xâm phạm?

Bảo mật phần cứng: Có sử dụng HSM không? Cấp độ chứng nhận là gì? Ai vận hành chúng?

Lịch sử kiểm toán: Các công ty bảo mật đã kiểm toán triển khai mã nguồn chưa? Khi nào? Báo cáo có công khai không?

Phản ứng sự cố: Hồ sơ theo dõi của nhà cung cấp ra sao? Họ xử lý các vấn đề như thế nào?

Cảnh báo đỏ

• Không có kiểm toán bảo mật công khai

• Mô tả mơ hồ về kiến trúc mật mã

• Quảng cáo "mã hóa cấp quân sự" mà không có chi tiết cụ thể

• Không có quy trình phản ứng sự cố rõ ràng

• Điểm thất bại đơn lẻ trong quản lý khóa

Thẩm định

Yêu cầu:

• Tài liệu kiến trúc

• Báo cáo kiểm toán (hoặc lịch kiểm toán)

• Tình trạng tuân thủ SOC 2

• Tài liệu trao khóa cho các nhà cung cấp MPC

• Quy trình khôi phục thảm họa

Đối với các ứng dụng xử lý giá trị đáng kể, việc thẩm định này là rất cần thiết.

Chiến lược triển khai

Bắt đầu từ đơn giản

Đừng triển khai tất cả các nhà cung cấp cùng một lúc. Chọn một nhà cung cấp phù hợp với trường hợp sử dụng chính của bạn. Đảm bảo nó hoạt động từ đầu đến cuối trước khi xem xét các lựa chọn thay thế.

Trừu tượng hóa giao diện

Thiết kế ứng dụng của bạn để làm việc với một giao diện, không phải một nhà cung cấp cụ thể:

interface EmbeddedWallet {
  connect(): Promise<string>;  // Returns public key
  signTransaction(tx: Transaction): Promise<Transaction>;
  signMessage(msg: Uint8Array): Promise<Uint8Array>;
  disconnect(): Promise<void>;
}

Các triển khai cụ thể của nhà cung cấp tuân thủ giao diện này. Nếu bạn cần chuyển đổi nhà cung cấp, chỉ có phần triển khai thay đổi.

Lập kế hoạch cho việc di chuyển

Người dùng có thể cần di chuyển giữa các nhà cung cấp. Thiết kế cho điều này:

• Lưu trữ ID người dùng trong backend của bạn, không chỉ địa chỉ ví

• Giữ địa chỉ ví trong hồ sơ người dùng để tham khảo

• Xem xét các luồng "thêm ví mới" liên kết địa chỉ mới với tài khoản hiện có

Kiểm tra trên thiết bị thực tế

Điều này không thể nhấn mạnh đủ: chức năng passkey yêu cầu thiết bị vật lý. Trình giả lập không có vùng bảo mật. Dự trù thời gian để kiểm tra trên thiết bị thực trong quy trình phát triển của bạn.

Khi nào không sử dụng ví nhúng

Các ví nhúng không phải lúc nào cũng là lựa chọn tốt nhất. Xem xét các tình huống sau:

Người dùng quen thuộc với tiền điện tử

Người dùng có kinh nghiệm thường thích sử dụng ví hiện có của họ. Họ đã giải quyết vấn đề khôi phục (cụm từ hạt giống, ví phần cứng). Ép họ sử dụng ví nhúng chỉ làm tăng tính bất tiện, không giảm.

Lựa chọn thay thế: Hỗ trợ kết nối MWA cùng với các tùy chọn ví nhúng.

Ứng dụng của bạn chủ yếu đọc dữ liệu

Nếu người dùng chủ yếu xem dữ liệu và hiếm khi ký giao dịch, độ phức tạp của ví nhúng có thể không được biện minh.

Lựa chọn thay thế: Yêu cầu địa chỉ ví để truy cập đọc, liên kết sâu đến ví bên ngoài cho các chữ ký thỉnh thoảng mới dùng.

Tối đa hóa sự phi tập trung là yêu cầu

Các nhà cung cấp MPC là các phụ thuộc tin cậy. Nếu luận điểm của ứng dụng bạn yêu cầu không có sự tham gia của bên thứ ba, tự quản lý hoàn toàn (ví bên ngoài) có thể là câu trả lời duy nhất chấp nhận được.

Lựa chọn thay thế: Chỉ hỗ trợ kết nối ví bên ngoài qua MWA hoặc Wallet Standard.

Ngân sách bị hạn chế

Các nhà cung cấp ví nhúng tính phí theo người dùng. Nếu mô hình kinh doanh của bạn không thể hỗ trợ phí trên mỗi người dùng và bạn chưa sẵn sàng tài trợ gas, ví bên ngoài không có chi phí biên.

Lựa chọn thay thế: Bắt đầu với MWA, thêm ví nhúng khi kinh tế đơn vị hỗ trợ.

Sẵn sàng cho xuất bản ứng dụng

Trước khi ra mắt với ví nhúng, hãy xác nhận lại:

Chứng thực

• Tất cả các phương thức xác thực đã được kiểm tra trên thiết bị thực (iOS và Android)

• Duy trì phiên làm việc khi khởi động lại ứng dụng

• Đăng xuất xóa đúng dữ liệu nhạy cảm

• Liên kết sâu được cấu hình cho các luồng OAuth và passkey

Các giao dịch

• Xử lý lỗi cho các sự cố mạng, hủy bởi người dùng, thiếu hụt quỹ

• Mô phỏng giao dịch trước khi gửi

• Phản hồi xác nhận rõ ràng

• Hiển thị phí (nếu người dùng trả) hoặc cấu hình tài trợ (nếu bạn trả)

Bảo mật

• Khóa API không được nhúng trong các gói client (hoặc được giới hạn đúng cách)

• Tất cả các giao tiếp với nhà cung cấp qua HTTPS

• Xác thực đầu vào trên địa chỉ và số lượng

• Giới hạn tần suất trên các thao tác nhạy cảm

Khôi phục

• Quy trình khôi phục đã được kiểm tra và tài liệu hóa

• Người dùng hiểu các tùy chọn khôi phục của họ

• Quy trình hỗ trợ cho người dùng bị khóa

Sự tuân thủ

• Điều khoản dịch vụ yêu cầu trước khi tạo ví

• Chính sách quyền riêng tư đề cập đến quản lý khóa

• Yêu cầu pháp lý cho khu vực pháp lý của bạn được đáp ứng

Tóm tắt khái niệm

Việc chọn một cách tiếp cận ví nhúng đòi hỏi phù hợp kiến trúc với các yêu cầu:

Cho người dùng phổ thông + linh hoạt tối đa: Các nhà cung cấp MPC (Privy, Dynamic, Para, Web3Auth) với nhiều tùy chọn xác thực

Cho sự đơn giản dựa trên phần cứng: Các nhà cung cấp TEE (Phantom Connect, Magic Link, Turnkey) với lưu trữ khóa cô lập

Cho sự tin cậy tối thiểu + phi tập trung tối đa: Passkey-native (LazorKit) với khóa ràng buộc phần cứng

Cho các yêu cầu phát triển + người dùng đa dạng: Modular signers (Crossmint) với bảo mật có thể nâng cấp

Cho kiểm soát hạ tầng: Turnkey với xác thực vốn có của bạn

Cho các ứng dụng đa chuỗi: Para với danh tính đa chuỗi thống nhất

Lựa chọn đúng phụ thuộc vào:

• Trình độ kỹ thuật người dùng của bạn

• Tần suất ký trong ứng dụng của bạn

• Yêu cầu khôi phục

• Giả định về sự tin cậy mà bạn sẵn sàng chấp nhận

• Ngân sách cho chi phí trên mỗi người dùng

Ví nhúng thay đổi quá trình gia nhập ban đầu bằng cách loại bỏ cụm từ khôi phục và phụ thuộc vào ví bên ngoài. Nhưng chúng cũng bị ràng buộc mối quan hệ với nhà cung cấp, cấu trúc chi phí mới, và các quyết định kiến trúc ảnh hưởng đến mô hình tin cậy của ứng dụng bạn.

Hãy chọn dựa trên sự hiểu biết, không phải marketing. Các nền tảng mật mã bạn đã học trong khóa học này cung cấp cho bạn cách thức để đặt câu hỏi đúng và đánh giá câu trả lời một cách nghiêm túc.

Hãy xây dựng một cái gì đó. Đưa nó đến người dùng. Tìm hiểu những gì người dùng cụ thể của bạn thực sự cần. Kiến trúc tốt nhất là kiến trúc phục vụ người dùng của bạn trong khi đáp ứng các yêu cầu về bảo mật và kinh doanh của bạn.