Originally posted on Sygma blog

Interoperability solutions have shown great promise in unlocking the potential of decentralized applications in our emerging multi-chain ecosystem. However, due to the high volumes of digital assets and critical data flowing across them, blockchain bridges are amongst the most targeted protocols in the web3 space. This leaves researchers hunting for more advanced security designs.

Multi-Party Computation (MPC) is one of the most interesting potential solutions. Secure MPC represents a powerful next step in digital asset security because it eliminates the risks of a single point of compromise.

Instead of relying on Multisig and other (older) ways of key management that either expose relayer identities or introduce exploitable single-points-of-failure, relayers would run a secure MPC ceremony each time a user wishes to bridge funds or transfer arbitrary data.

In this way, MPC enables multiple parties to carry out a distributed computation on their secret inputs without revealing anything but the output.

This concept has been studied by academia for decades. Still, it’s only due to recent technological advancements that it has become viable for real-world applications like Sygma, the interoperability layer for building cross-chain applications.

Let’s unpack how MPC works, what makes it unique, and why we choose to adopt it.

Threshold cryptography

Threshold Signature Schemes (TSS) is an area of MPC that we will focus on today. It’s particularly useful for crypto as it facilitates the distribution of a private key to multiple parties, introducing redundancy into asset management security.

In other words, it enables a set of parties to perform certain cryptographic operations, like signing transactions, while none of them holds a full private key. Instead, the key is split across the parties and can only be used when a subset of them — the size of which is larger than a certain threshold — combines their key shares.

Thanks to the homomorphic properties of the underlying scheme, a fully formed private key doesn’t ever need to exist. “Homomorphism” is just a fancy mathematical way to say the operations you can perform on the unencrypted (plaintext) values, like addition or multiplication, will behave identically on the encrypted (ciphertext) ones.

You can imagine the benefits of this for privacy.

For example, a user sends encrypted financial data to the server, and it responds with an encrypted credit score that only they would be able to decrypt. If that sounds interesting, see this article for more details and this library if you want to tinker with it.

An example

Imagine you have a secret key sk and a special algorithm that can divide this key into n pieces such that $[sk_i]$ = share_key($pk, n, t$). Imagine now you want to sign a transaction m, so you apply a similar algorithm to get partial signatures $[s_i]$ = sign($m, [sk_i]$). Now, to reconstruct a valid signature, you would simply sum all partial signatures together $s = s_0 + s_1 + … + s_i$ and call it a day.

You might’ve also noticed a third argument t when we shared our key. Although the key is shared between n parties, we only need a threshold number of them to actually sign something. This is akin to a multisig scheme, which interestingly is just an emulation of threshold signatures using a high-level smart contract language like Solidity.

Of course, multisigs come with a cost where one would pay miners to process each call to the multisig contract. Conversely, threshold signatures are processed off-chain, and only a single compact ECDSA signature needs to be transacted on-chain once. Furthermore, such a signature won’t leak anything about its signers, which secures them from targeted attacks and is great for privacy.

When discussing security, MPC algorithms generally provide guarantees based on the threshold number of corrupted parties a system can tolerate. This places TSS in a unique position, as such schemes present the control of their robustness directly in the developer’s hands. Furthermore, this allows it to withstand even the dishonest majority — an extreme state where adversaries can corrupt all but one participant.

You may already know about the blockchain’s Scalability Trilemma and the Interoperability Trilemma of the cross-chain ecosystem. Let’s introduce a third one for the MPC domain — the Threshold Trilemma. Below are the three properties that MPC protocols try to maximize but can only have two of at the same time:

• Risk minimization (robustness): the higher the threshold value set, the harder it is for parties to collude against the system, e.g., forge a signature.
• Fault tolerance (liveness): the lesser the threshold value compared to the total number of parties, the more unforeseen failures such a system can tolerate, e.g., a peer accidentally going offline.
• Performance (latency): the more parties the system employs, the more decentralized, secure, and reliable it would be, but at the expense of increasing performance overhead due to MPC’s high communication complexity.

Generally, protocol engineers prefer to minimize risk first and then balance liveness and performance based on the chosen threshold. However, it’s essential to base the threshold calculation on concrete metrics, such as the number of collateral nodes would have to stake or the amount of computation work needed for participation.

One last trick that can present an even greater degree of confidence in threshold cryptosystems is their unique “Key Reshare” mechanism — which allows parties from the old set to rotate key shares with new participants without changing the underlying public key. This is useful to onboard new members into the signing committee, but more importantly, it prevents hackers from corrupting parties one after another, potentially in the course of many sessions (known as proactive adversaries).

Applications of TSS in blockchains

There are many ways TSS is used today. Keyless wallets like ZenGo or Torus are making a more convenient and secure alternative — no more paper-written mnemonics or cloud-backed keys are needed. Instead, the wallet provider’s server/nodes would actively cooperate with the user to sign transactions.

The folks at Chainlink are using thresh-sigs to efficiently and verifiably aggregate data for their oracle network. Even some rollups like Skale Network are flirting with this technology, although instead of ECDSA, they use BLS signatures that require less MPC-intensive setup due to their elliptic curve pairing properties.

Probably the biggest beneficiaries of the TSS are a new generation of custodian services led by Fireblocks and Entropy. These companies aim to disrupt the way big institutions and foundations operate their escrows and treasuries.

Finally, threshold cryptography has great promise for various cross-chain applications. While designing Sygma, a new vision of cross-chain interoperability, we became convinced that having MPC for relayer communication will not only strengthen the overall security but also significantly reduce fees making the user experience much smoother.