MPC stands for “multi-party computation”, meaning that different people need to work together to accomplish something unique, typically without revealing anything secret to each other.
A widely used example is with hospitals and researchers. The hospitals have sensitive medical records. Researchers could use the records to invent new technologies. By using some MPC algorithm, hospitals could safely work with researchers without divulging sensitive information.
Why is everyone using MPC in their blockchain wallets then? People in crypto actually use threshold signing schemes (TSS); a pretty narrow type of MPC. Multiple parties hold different key shares, and by working together, they can produce valid signatures over blockchain transactions.
People like MPC/TSS a lot more than storing a “full” key in a single place. Because in the MPC case, if a single party gets compromised, the funds are still safe. Only by compromising all parties (or some threshold), can a bad actor steal the “full” key and take all of the money.
There are a lot of situations where you want to use MPC to distribute trust. If you’re a company taking custody of funds, you want to be really sure you don’t lose them. It’s not something that you want to delegate to just one employee. What happens if the employee leaves? What if they copied the key or took it home? What if they lose the wallet?
If you use MPC, you can start to make the situation better. Multiple teams can custody separate key shares. Vendors can even host some minority shares of key shares. So if someone leaves, or even goes “rogue,” you can be sure that key material doesn’t get compromised.
The problem is, if you stop here, a lot of this is arguably security theater.
Most blockchain and cryptocurrency hacks don’t actually involve stealing private keys. Rather, many of them focus on getting people to unwittingly sign malicious transactions.
This is very similar to phishing - send someone a convincing (but fraudulent) email, and get them to click on a malicious link.
Unfortunately MPC doesn’t solve this. Doesn’t matter how many key shares you have, if the end user accidentally sends the whole treasury to a bad actor.
Well, you need policies! Imagine your business takes custody and only ever has two counterparties: Kevin and Karen.
Some days you send money to Kevin, and other days you send to Karen. If you send to an address that’s neither of those, then you are breaking policy.
Every key-shareholder should then enforce this policy. If it passes for a participant, then they should participate in MPC signing. If not, they should stop, lest risk losing money!
One might be tempted to “hardcode” policies into each MPC participant. But in reality, policies change over time for businesses. Maybe Karen goes away. Maybe there’s a new counterparty, Bill. How you update & change your policies is in of itself an important part of policy.
One also might be tempted to store policies in a SQL database. Many existing MPC SaaS vendors do this with their customer policies (beware!). However, an SQL database will not have a way to respect your core MPC security threshold. There are many actors that can single handedly tamper data in a database, no matter how much you use MPC.
If you truly want some MPC threshold of security, you need to ensure all participants are independently following policies. Ensuring that policies are correct and securely updated in a reliable way is a hard problem.
Integrating MPC with replicated policy engines has been core to Cordial Treasury from day one. This is what our logo means – multiple disjoint key-shareholders, all bound by the same policy.
Every participant, in addition to running MPC for key-shares, runs a policy engine. This engine runs a byzantine fault tolerant (BFT) consensus algorithm with all other participants.
What is a BFT consensus algorithm? It’s like another MPC algorithm, but it doesn’t need to keep anything secret. Instead, it needs to ensure all parties can agree on something cryptographically. By proving a consensus, we can be sure there is no single actor or minority that is trying to break the policy.
By combining two kinds of MPC algorithms (TSS and BFT consensus), Cordial Treasury is able to securely enforce complex & dynamic policies at every participant in an extremely reliable way.
We actually use some of the same technology powering some of the largest public blockchains.
We’re proud to be very transparent in how policies are enforced in tandem with MPC. Be very wary of solutions that focus solely on MPC!
Who exactly are these MPC participants? How do they get deployed? Well, it depends!
Cordial Treasury is 100% designed to be self-hosted, low footprint, and low maintenance. This makes it incredibly easy to support a variety of secure setups.
SELF HOSTED. You can host everything yourself and isolate Treasury appliances from each other. Treasury can run in the cloud, on AMD SEV, or bare metal.
HYBRID. You can host one (or more) appliances and we can partner you with a secure operating partner to run the other appliances in a non-custodial fashion.
HOSTED. You rely on the secure, distributed infrastructure run by us or a partner.
