📋 Tóm tắt — Đọc trong 60 giây
MPC Wallet: Key Không Bao Giờ Tồn Tại Đầy Đủ
MPC (Multi-Party Computation) là kỹ thuật mật mã cho phép nhiều bên cùng tính toán một kết quả mà không ai tiết lộ input của mình. Trong wallet context: private key được chia thành nhiều key shares, mỗi bên giữ một phần — để ký transaction, cần đủ số shares theo threshold quy định, nhưng key đầy đủ không bao giờ được ghép lại ở bất kỳ đâu.
TSS (Threshold Signature Scheme) là ứng dụng MPC vào chữ ký số: tạo ra chữ ký ECDSA hợp lệ thông qua giao thức phân tán giữa các parties, không cần reconstruct private key. Kết quả on-chain: một địa chỉ EOA thông thường, một chữ ký bình thường — không ai biết đây là MPC.
01 · Khái niệm
Key chia thành shares, không ai giữ full key, signing phân tán
02 · TSS
Threshold Signature: M-of-N parties cùng ký, không reconstruct key
03 · So sánh
Khác Multisig (on-chain) và Hardware Wallet (threat model khác)
04 · Use case
Institutional custody, CEX hot wallet, Web3 onboarding không seed
Multi-Party Computation (MPC) là một nhánh của mật mã học cho phép nhiều bên cùng nhau tính toán một hàm số trên các input riêng của từng người, mà không ai phải tiết lộ input của mình cho bất kỳ ai khác. Kết quả cuối cùng được tính đúng, nhưng privacy của từng party được bảo toàn.
Ví dụ kinh điển: Ba người muốn biết ai có mức lương cao nhất mà không ai muốn tiết lộ lương của mình. MPC cho phép tính toán kết quả "người X có lương cao nhất" mà không party nào biết số lương cụ thể của party khác.
Trong blockchain context, MPC được ứng dụng để giải quyết một vấn đề cốt lõi: single point of failure của private key. Private key truyền thống tồn tại trên một thiết bị/nơi lưu trữ duy nhất — ai kiểm soát được file đó là kiểm soát được toàn bộ tài sản. MPC phá vỡ mô hình này.
Tại sao single private key là vấn đề?
Private key là một con số 256-bit — không thể phân biệt bản copy từ bản gốc. Điều này có nghĩa:
- Một người giữ key = một điểm tấn công duy nhất: Hack, insider threat, hay mất thiết bị là mất toàn bộ.
- Không audit trail: Ai đã ký transaction? Không thể biết nếu key được share giữa nhiều người.
- Compliance impossible: Tổ chức tài chính không thể chấp nhận "một người có thể chuyển hết tiền mà không cần approval."
- Không key rotation: Thay đổi key đồng nghĩa với chuyển toàn bộ funds sang địa chỉ mới — tốn kém và rủi ro.
💡
Nguồn gốc học thuật
MPC được đề xuất bởi Andrew Yao trong paper "Protocols for Secure Computations" (1982) — bài toán "Millionaires' Problem". Sau đó được phát triển thêm bởi Goldreich, Micali, Wigderson (1987) với giao thức GMW tổng quát. Ứng dụng vào blockchain signing là bước phát triển từ 2018 trở đi với các paper của Lindell và các công trình từ Fireblocks, Zengo.
MPC wallet hoạt động theo nguyên tắc: private key không bao giờ được tạo ra như một whole — thay vào đó, quá trình key generation được thực hiện phân tán, mỗi party nhận được một key share ngay từ đầu. Sau đó, quá trình signing cũng phân tán — các parties interact với nhau theo giao thức MPC để tạo ra chữ ký hợp lệ mà không ai cần share input secret của mình.
MPC Wallet — Luồng Tổng Quan
KEY GENERATION (Distributed)
Party A ─── DKG Protocol ─── Party B ─── DKG Protocol ─── Party C
Share_A Share_B Share_C
↓ Full private key KHÔNG tồn tại ở bất kỳ đâu ↓
SIGNING (Threshold = 2-of-3)
Party A ── MPC Protocol ── Party B (Party C không tham gia)
↓ Interactive protocol: nhiều round communication
Valid ECDSA Signature (looks like normal EOA signature)
ON-CHAIN:
0x742d35... ← Regular address, regular signature
(Không ai biết đây là MPC)
Distributed Key Generation (DKG)
Giai đoạn đầu tiên là DKG — quá trình các parties tương tác với nhau theo giao thức mật mã để mỗi bên nhận về một share, sao cho tổng hợp đủ threshold shares có thể derive public key và sign message, nhưng không share nào đơn lẻ tiết lộ bất kỳ thông tin gì về key đầy đủ.
Giao thức DKG phổ biến nhất là Pedersen DKG (1991) và các biến thể của nó. Quá trình này dùng verifiable secret sharing để đảm bảo mỗi party có thể verify share của mình là hợp lệ mà không cần trust bên trung gian.
Signing Protocol
Khi cần ký một transaction, các parties tham gia giao thức signing tương tác: mỗi bên tính toán một partial signature dựa trên share của mình và các giá trị nonce ngẫu nhiên được đồng thuận, sau đó combine lại thành chữ ký ECDSA chuẩn. Điểm quan trọng: trong suốt quá trình, không party nào biết share của party khác.
⚠️
Multi-round communication
Giao thức MPC signing thường cần nhiều round trao đổi message giữa các parties (2–5 round tùy giao thức). Điều này có nghĩa: các parties cần online đồng thời và có network connectivity với nhau. Đây là trade-off so với hardware wallet hay EOA — signing không thể offline hoàn toàn.
Threshold Signature Scheme (TSS) là ứng dụng cụ thể của MPC vào việc tạo chữ ký số. TSS cho phép một nhóm M-of-N parties cùng tạo ra một chữ ký hợp lệ trên một message, với điều kiện:
- Ít nhất M (threshold) parties phải tham gia và đồng ý ký.
- Không parties nào (hay nhóm nhỏ hơn M parties) có thể ký một mình.
- Private key đầy đủ không cần được reconstruct tại bất kỳ thời điểm nào — kể cả khi signing.
Điểm cuối cùng là điểm phân biệt TSS với Shamir Secret Sharing (SSS). SSS chia key thành shares, nhưng để dùng phải reconstruct full key tại một máy — tạo ra điểm tấn công tạm thời. TSS không bao giờ reconstruct key.
ECDSA-TSS — Kỹ thuật phía sau
Ethereum và Bitcoin dùng ECDSA với đường cong secp256k1. Để implement TSS cho ECDSA, cần giải quyết thách thức kỹ thuật: ECDSA signing yêu cầu một nonce bí mật k, và nếu cùng k được dùng hai lần cho hai message khác nhau thì private key có thể bị tính ra. TSS cần đảm bảo k được generate phân tán và không ai biết k đầy đủ.
// Pseudocode: ECDSA-TSS Signing (simplified)
// Threshold: t-of-n parties
function tss_sign(message, parties[1..t]):
// Round 1: Each party generates partial nonce
for party_i in parties:
k_i = random_secret() // local nonce share
R_i = k_i * G // partial R point
commit(R_i) // broadcast commitment
// Round 2: Aggregate R point (no one knows full k)
R = sum(R_i for i in parties)
r = R.x mod n
// Round 3: Each party computes partial signature
for party_i in parties:
s_i = k_i_inv * (hash(msg) + r * x_i)
// x_i is party_i's key share
// Combine partial signatures
s = combine(s_i, lagrange_coefficients)
return (r, s) // Valid ECDSA signature — identical to EOA signature
🔬
Papers quan trọng
Hai giao thức TSS được dùng phổ biến nhất trong production:
GG18/GG20 (Gennaro & Goldfeder, 2018/2020) và
CGGMP21 (Canetti et al., 2021). CGGMP21 là phiên bản mới hơn với security proof chặt chẽ hơn và số round ít hơn. Fireblocks dùng một biến thể của GG18, trong khi nhiều protocol mới hơn đang chuyển sang CGGMP21.
Setup 2-of-3 là cấu hình phổ biến nhất cho cả individual users và tổ chức: cần 2 trong 3 key shares để thực hiện signing, chịu được mất 1 share mà không mất tài sản.
Ví dụ điển hình của MPC provider cho individual user (ví dụ ZenGo):
- Share 1 — Device: Lưu trên thiết bị của user (encrypted với biometric/PIN).
- Share 2 — Server: Lưu trên server của provider (trong HSM, không ai ở provider access được trực tiếp).
- Share 3 — Recovery: Encrypted backup, có thể lưu ở cloud hay hardware backup — dùng khi mất thiết bị.
Khi user ký transaction: device và server interact theo giao thức TSS → tạo signature hợp lệ. User mất điện thoại: dùng recovery share + xác thực danh tính để request signing với server. Server bị hack: không đủ threshold vì chỉ có 1 share.
2-of-3 MPC cho Institutional Custody (Fireblocks model)
- Share 1 — Client device: HSM hoặc TEE tại data center của tổ chức.
- Share 2 — Fireblocks server: Trong Fireblocks' infrastructure (HSM-backed).
- Share 3 — Cold backup: Offline backup, chỉ dùng trong recovery scenarios.
Mọi giao dịch cần cả client và Fireblocks server tham gia signing — Fireblocks có thể enforce policy (transaction limit, whitelist địa chỉ, multi-approver workflow) trước khi đồng ý tham gia signing protocol.
✅
Key Resharing — Rotation mà không move funds
Một tính năng quan trọng của MPC là
proactive key resharing: định kỳ (ví dụ mỗi 24h), các parties có thể chạy giao thức resharing để tạo ra bộ shares mới, vô hiệu hóa shares cũ — trong khi địa chỉ trên blockchain không đổi, không cần move funds. Điều này đảm bảo dù attacker đã steal 1 share trong quá khứ, share đó cũng không còn giá trị sau khi reshard.
MPC và Multisig đều giải quyết bài toán "cần nhiều bên đồng ý để thực hiện giao dịch", nhưng theo hai cách hoàn toàn khác nhau về mặt kỹ thuật và có những trade-off rất khác nhau.
| Tiêu chí |
MPC / TSS |
Multisig (Gnosis Safe) |
| On-chain footprint |
EOA thường — ẩn hoàn toàn |
Smart Contract — ai cũng đọc được |
| Gas cost |
Như EOA thông thường |
Tốn hơn (~50k gas overhead) |
| Chain compatibility |
Mọi EVM chain, Bitcoin, Solana |
Chỉ EVM chains có Smart Contract |
| Key rotation |
Resharing, không cần move funds |
Thay signer = on-chain transaction |
| Privacy |
Không ai biết là MPC |
Cấu hình M-of-N public trên chain |
| Setup phức tạp |
Phức tạp hơn (cần provider) |
Đơn giản (deploy contract) |
| Off-chain security |
Phụ thuộc vào MPC giao thức |
Phụ thuộc vào từng signer EOA |
| Auditability |
Cần provider logs |
Mọi approval visible on-chain |
| Trust model |
Tin vào cryptographic protocol |
Tin vào Smart Contract audit |
| Use case phù hợp |
Institutional custody, CEX hot wallet |
DAO treasury, team funds |
Một điểm thường bị hiểu nhầm: MPC không có nghĩa là "tốt hơn" Multisig — chúng phù hợp với các use case khác nhau. DAO treasury thường chọn Multisig vì on-chain transparency và auditability là điều họ muốn. Institutional custodian thường chọn MPC vì privacy, gas efficiency và cross-chain support.
Để hiểu sâu hơn về Multisig, xem bài Multisig Wallet Là Gì? Gnosis Safe và M-of-N Setup.
Hardware wallet và MPC wallet đều nhằm mục đích bảo vệ private key, nhưng chúng được thiết kế để chống lại các threat models hoàn toàn khác nhau. Không cái nào "tốt hơn" — chúng giải quyết những bài toán khác nhau.
| Threat / Tình huống |
Hardware Wallet |
MPC Wallet |
| Malware trên máy tính |
Bảo vệ tốt — key trong secure element |
Phụ thuộc setup — 1 share trên device có thể bị lấy |
| Mất/bị cướp thiết bị |
An toàn — cần PIN, seed backup |
An toàn — threshold không đủ |
| Insider threat |
Rủi ro — 1 người = full key |
Bảo vệ tốt — cần nhiều parties đồng ý |
| Provider/Custodian bị hack |
Không ảnh hưởng — self-custody |
Phụ thuộc — nếu provider giữ 1 share |
| Key rotation cần thiết |
Khó — phải move funds |
Dễ — resharing protocol |
| Blind signing risk |
Cao — xem bài Blind Signing |
Có thể mitigate — server-side policy |
| Phù hợp cho |
Individual, small team, long-term storage |
Institution, tổ chức, hot wallet scale lớn |
Hardware wallet có ưu thế khi threat chính là remote attack (malware, phishing) và bạn muốn self-custody hoàn toàn. MPC wallet có ưu thế khi threat chính là operational risk (insider, single point of failure) và bạn cần quản lý assets ở quy mô tổ chức.
Để hiểu thêm về hardware wallet, xem bài Hardware Wallet Là Gì? Ledger vs Trezor.
Institutional Custody — Fireblocks, BitGo, Copper
Đây là use case lớn nhất và trưởng thành nhất của MPC. Các custodian như Fireblocks quản lý hàng tỷ USD tài sản cho hedge fund, exchange, protocol — tất cả đều dùng MPC để đảm bảo không nhân viên nào (kể cả trong nội bộ Fireblocks) có thể đơn phương chuyển tài sản của khách hàng.
CEX Hot Wallet
Các sàn giao dịch như Binance, Coinbase cần hot wallet để xử lý withdrawal liên tục. MPC cho phép xây dựng hot wallet mà: (1) không có single key exposure, (2) có policy enforcement (withdrawal limit, IP whitelist), (3) rotation không cần move funds. Đây là lý do major exchange đã chuyển từ "one key per address" sang MPC từ khoảng 2019–2021.
Consumer Wallet — Loại bỏ Seed Phrase
ZenGo, Privy, và một số Web3 onboarding tools dùng MPC để tạo wallet không cần seed phrase cho end user. User đăng nhập bằng email/social, key share được lưu trên device và server. Đây là một trong những hướng giải quyết bài toán UX của crypto — người dùng mới không phải đối mặt với "ghi 12 từ xuống giấy."
Web3 Embedded Wallet
Privy, Turnkey, Dfns cung cấp "embedded MPC wallet" cho developer — tích hợp vào app với vài dòng code. User tạo wallet bằng email, wallet key được quản lý bằng MPC giữa server của provider và client. Developer không cần lo về key management, user không cần lo về seed phrase.
🏦
Tại sao Fireblocks trị giá $8 tỷ?
Fireblocks định giá cao phần lớn vì họ giải quyết được bài toán institutional key management mà trước đây không có giải pháp tốt. Trước MPC, institutional custody hoặc dùng hardware HSM đắt tiền hoặc dùng multisig cồng kềnh — cả hai đều không scale tốt. MPC + policy engine + workflow approval của Fireblocks là "infrastructure layer" cho institutional Web3.
MPC không phải silver bullet. Hiểu rõ giới hạn để không dùng sai context:
1. Phức tạp hơn — Nhiều surface attack hơn
Giao thức MPC phức tạp hơn nhiều so với single-key hay Multisig. Complexity = attack surface. Bugs trong MPC implementation có thể có hậu quả nghiêm trọng và khó phát hiện hơn. GG18 — giao thức được dùng rộng rãi — có một vulnerability được phát hiện năm 2021 (Biham et al.) cho phép một malicious party extract full key nếu giao thức signing bị abort đúng thời điểm. Giao thức GG20 và CGGMP21 đã vá lỗi này.
2. Liveness requirement
Để signing, đủ M parties cần online đồng thời và communicate với nhau. Với multisig on-chain: mỗi người ký riêng lẻ và submit lên chain, không cần cùng online. MPC cần real-time coordination — nếu server provider down, bạn không ký được dù bạn đang giữ đủ shares về mặt số học.
3. Phụ thuộc provider
Phần lớn MPC wallet consumer dùng setup 2-of-2 hoặc 2-of-3 với server của provider giữ 1 share. Nếu provider đóng cửa mà không có recovery mechanism, user có thể mất access. Vấn đề này được giải quyết bởi "recovery key" hay encrypted backup — nhưng phụ thuộc vào từng provider có implement đúng không.
4. Audit trail phụ thuộc off-chain logs
Multisig on-chain có audit trail hoàn hảo — mọi approval visible trên block explorer. MPC signing chỉ để lại một chữ ký EOA trên chain, không ai biết ai đã approve. Audit trail của MPC phụ thuộc vào logs của provider — nếu provider bị hack hay xóa logs, audit không thể hoàn chỉnh.
5. Chưa có chuẩn mở
Khác với HD Wallet có BIP-32/39/44 chuẩn hóa, MPC wallet chưa có chuẩn tương đương. Mỗi provider dùng giao thức và format shares khác nhau — key shares của Fireblocks không portable sang Copper. Điều này tạo vendor lock-in.
⚠️
Không có cái gọi là "zero trust" hoàn toàn
Nhiều MPC provider marketing sản phẩm là "zero trust" — nhưng điều này không hoàn toàn đúng. Bạn vẫn phải tin vào: (1) implementation của giao thức MPC không có bugs; (2) provider không collude với attacker (với 2-of-2 setup, provider vẫn giữ 1 share); (3) HSM/TEE của provider thực sự bảo vệ key shares. "Zero trust" trong context này có nghĩa là bạn không cần tin vào bất kỳ single party nào — không phải bạn không cần tin vào ai hết.
MPC wallet có on-chain footprint không?+
Không — đây là một trong những ưu điểm lớn nhất của MPC so với Multisig. Từ góc nhìn on-chain, MPC wallet trông giống hệt một EOA thông thường: chỉ một địa chỉ, một chữ ký duy nhất trong mỗi transaction. Không ai có thể biết rằng phía sau là một hệ thống multi-party signing phức tạp. Ngược lại, Multisig (Gnosis Safe) là một Smart Contract với on-chain logic rõ ràng, ai cũng đọc được cấu hình M-of-N.
Nếu 1 party trong MPC bị hack thì sao?+
Trong một setup MPC chuẩn (ví dụ 2-of-3), nếu 1 trong 3 party bị compromise, kẻ tấn công vẫn không thể thực hiện được giao dịch vì cần ít nhất 2 key shares để tạo chữ ký hợp lệ. Tuy nhiên, đây là tình huống khẩn cấp: cần lập tức rotate key — thực hiện key resharing để tạo ra bộ shares mới, vô hiệu hóa share bị compromise. Các hệ thống MPC production đều hỗ trợ proactive secret sharing để định kỳ rotation mà không cần move funds.
MPC wallet recover thế nào nếu mất 1 share?+
Recovery phụ thuộc vào threshold. Với 2-of-3: mất 1 share vẫn còn 2 share, đủ để sign một transaction chuyển funds ra hoặc thực hiện key resharing để tạo bộ 3 shares mới. Với 2-of-2: mất 1 share là mất toàn bộ — không recovery. Đây là lý do production MPC thường dùng cấu hình 2-of-3 hoặc 3-of-5 thay vì 2-of-2. Một số provider như Fireblocks và Coinbase còn backup encrypted shares ở hardware security module (HSM).
Coinbase Wallet có dùng MPC không?+
Coinbase dùng MPC cho Coinbase Prime (institutional custody) và một số sản phẩm wallet của họ. Coinbase Wallet (self-custody) ra mắt tính năng backup dùng MPC-based key splitting với iCloud/Google Drive — key được chia giữa device của user và cloud server, threshold 2-of-2. Đây là dạng "social MPC" khác với institutional MPC. Các sàn lớn như Binance Custody và BitGo cũng dùng MPC cho institutional holdings.
Tài liệu tham khảo
Tài liệu học thuật, paper giao thức và documentation từ các provider MPC hàng đầu.
- Yao, A. C. Protocols for Secure Computations. IEEE FOCS 1982. — Paper gốc định nghĩa MPC, "Millionaires' Problem".
- Gennaro, R. & Goldfeder, S. Fast Multiparty Threshold ECDSA with Fast Trustless Setup. ACM CCS 2018. eprint.iacr.org/2019/114. — GG18: Giao thức TSS được dùng rộng rãi nhất.
- Canetti, R., Gennaro, R., Goldfeder, S. et al. UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts. ACM CCS 2021. eprint.iacr.org/2021/060. — CGGMP21: Giao thức TSS thế hệ mới.
- Lindell, Y. Fast Secure Two-Party ECDSA Signing. CRYPTO 2017. eprint.iacr.org/2017/552. — Two-party ECDSA, nền tảng cho consumer MPC wallet.
- Biham, E. et al. Cryptanalysis of the GG18 Two-Party ECDSA Protocol. 2021. eprint.iacr.org/2021/1521. — Vulnerability phát hiện trong GG18 và cách khắc phục.
- ZenGo. How ZenGo's Keyless Security Works. zengo.com/security. — Consumer MPC wallet implementation.
- ZRO Research. Wallet Infrastructure & Key Management — TWT.VN Knowledge Base. twt.vn/. 2025–2026. — Bài tổng quan pillar page.
TWT.VN