Co rozwiązuje MPC — a czego nie
Multi-party computation może usunąć pojedynczą granicę raw private key przez rozdzielenie signing material/participation. Nie decyduje, czy transakcja powinna się odbyć, czy destination jest dozwolone, czy kwota przekracza limity ani czy product ledger powinien zostać zmieniony. To nadal odpowiedzialność aplikacji.
Granica integracji produkcyjnej
Solidna integracja MPC ma co najmniej cztery oddzielne warstwy: business authorization → signing request → blockchain execution → business posting. Poprawny podpis jest dowodem, że signing system zatwierdził operację kryptograficznie, a nie że proces biznesowy się zakończył.
Policy przed signingiem
Sprawdzaj actor, role, transaction intent, asset, network, amount, destination, velocity limits i approval. Treasury często potrzebuje multi-person approval albo policy engine providera; programmatic wallets mogą wymagać application-side policy przed wywołaniem API.
Idempotency i correlation
Każdy signing request powinien mieć stabilny business operation ID. Zapisuj provider request IDs, transaction hash i transition statuses. Retry po timeout nie może stworzyć drugiego withdrawal.
Recovery i key rotation
Zaprojektuj recovery dla user access, operator access, entity secrets, signer changes i provider migration. Recovery powinno być testowane, udokumentowane i oddzielone od normalnych transaction privileges.
Pytania przy wyborze providera
- Kto kontroluje każdy signing share lub credential?
- Czy signing może działać server-side?
- Jakie approval policies są natywne?
- Jak wygląda recovery?
- Jak eksportowane są audit events?
- Co dzieje się przy częściowym outage?
- Jak reprezentowane są EVM i non-EVM accounts?
- Czy możemy utrzymać provider-neutral wallet registry?
MPC nie zastępuje ledgera
Nawet idealna infrastruktura signing nie powie finansom, dlaczego wartość się przesunęła. Wallet execution references powinny być spięte z product-owned ledgerem i reconciliation timeline.
Wzorzec implementacji
Transaction Intent → Authorization Policy → Approval(s) → MPC/Signing API → Broadcast → Chain Observation → Finality → Ledger Posting → Reconciliation.
Taka kolejność daje jasne failure boundaries i pozwala operatorowi odpowiedzieć, na którym etapie zatrzymała się transakcja.