Sai lầm quản lý khóa Web3 gây ra rủi ro bảo mật khổng lồ: Tại sao MPC-TSS là chìa khóa?

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

Sai lầm lớn nhất của các đội ngũ Web3 là tập trung vào mã hóa khóa thay vì loại bỏ điểm tập trung (single point of failure).

MPC-TSS (Threshold Signature Scheme) giải quyết vấn đề bằng cách chia nhỏ khóa thành các phần (shares) không bao giờ được tập hợp tại một điểm.

Sử dụng kỹ thuật CKD (Child Key Derivation) giúp quản lý ví cho hàng triệu người dùng mà không cần thực hiện hàng triệu quy trình DKG (Distributed Key Generation) phức tạp.

Vấn đề thực sự: Không phải mã hóa, mà là sự tập trung

Phần lớn các đội ngũ phát triển ví Web3 thường bắt đầu với một luồng lưu ký (custodial flow) tiềm ẩn rủi ro:

Tạo khóa riêng tư (private key) secp256k1.
Mã hóa bằng AES-256-GCM.
Lưu trữ blob đã mã hóa trong PostgreSQL.
Giải mã trên backend mỗi khi cần ký giao dịch.

Cách tiếp cận này chỉ bảo vệ bạn trước việc rò rỉ cơ sở dữ liệu thuần túy. Tuy nhiên, khi backend cần giải mã để hoạt động, bất kỳ kẻ tấn công nào chiếm được quyền điều khiển (RCE, lộ thông tin cloud, hoặc nội gián) đều có thể sử dụng đường dẫn ký của chính bạn. AES trở nên vô nghĩa vì máy chủ của bạn luôn thực hiện việc giải mã.

Bảng so sánh rủi ro: Truyền thống vs MPC-TSS

Kịch bản tấn công	Truyền thống (Khóa mã hóa)	MPC 2-of-3
Rò rỉ Database	An toàn (Ciphertext)	Không có dữ liệu hữu ích
Lộ khóa giải mã	Mất toàn bộ khóa	Không có dữ liệu hữu ích
RCE Backend	Mất toàn bộ khóa	Không có khóa để lấy
Mất 1 node MPC	Không áp dụng	Không đủ để ký

MPC-TSS thay đổi cuộc chơi như thế nào?

Trong MPC-TSS (Threshold Signature Scheme), khóa riêng tư không bao giờ tồn tại ở một nơi duy nhất. Khóa được chia thành các phần (shares) nằm trên các node độc lập. Một ngưỡng (threshold) các node sẽ phối hợp để tạo ra chữ ký mà không cần tập hợp khóa lại.

Sơ đồ quy trình ký MPC-TSS:

[Backend] ➔ [Hash dữ liệu] ➔ [Gửi 32-byte digest] ➔ [Node 1 + Node 2] ➔ [Chữ ký (r, s, v)]

Lựa chọn giao thức: Thực tế năm 2026

Việc chọn giao thức không chỉ dựa vào tên gọi mà phải xem xét phiên bản và bản vá CVE:

GG18/GG20: Phổ biến nhưng có lỗ hổng (BitForge, TSSHOCK). Chỉ nên dùng nếu đã vá lỗi và bạn kiểm soát tất cả các node.
CGGMP21: Đang tồn tại lỗ hổng giả mạo chữ ký (CVE-2025-66017). Không nên dùng.
CGGMP24: Lựa chọn an toàn hiện nay với các bản vá API đã được hoàn thiện.

Xây dựng hay sử dụng Server có sẵn?

Nếu bạn muốn tự vận hành (self-hosted), hãy cân nhắc:

Xây dựng từ thư viện: Sử dụng bnb-chain/tss-lib (Go) hoặc coinbase/cb-mpc (C++). Bạn có toàn quyền kiểm soát nhưng phải tự lo về networking, backup và DR (Disaster Recovery).
Sử dụng Server có sẵn: Mpcium là lựa chọn đáng cân nhắc với kiến trúc cluster hoàn chỉnh, giúp giảm đáng kể chi phí vận hành.

Quản lý ví cho hàng triệu người dùng với CKD

Thay vì thực hiện DKG cho mỗi người dùng, hãy áp dụng CKD (Child Key Derivation) theo tiêu chuẩn BIP-32:

Khởi tạo: Chạy DKG một lần duy nhất để tạo Master Wallet.
Mở rộng: Sử dụng toán học để dẫn xuất (derive) khóa con cho từng người dùng từ Master Public Key.
Lợi ích: Không cần ceremony cho mỗi user, backup đơn giản, khả năng mở rộng vô hạn.

Việc bảo mật hệ thống là một quá trình liên tục. Nếu bạn đang quan tâm đến việc tối ưu hóa hiệu suất hệ thống từ phía frontend để hỗ trợ các giao diện ví phức tạp, hãy tham khảo thêm về kỹ thuật dịch chuyển phần tử chuyên sâu để cải thiện trải nghiệm người dùng cuối.

Kết luận, MPC không phải là một giải pháp ma thuật, nó là một primitive bảo mật mạnh mẽ. Hãy đảm bảo bạn hiểu rõ threat model của mình và luôn cập nhật các bản vá bảo mật mới nhất.