How it works

Some Background: The distributed key algorithm used by Multichain was derived from the ground breaking work of Steven Goldfeder (Offchain Labs, Cornell Tech) and Rosario Gennero (City College, CUNY). Their paper of 2019, referred to as GG20, has been implemented in new code by Multichain and continuously improved. We dive deep here to see how Multichain's core functions use distributed key algorithm.

The use of a single signature to send assets, or interact with smart contracts cross-chain, results in a single point of failure. This Externally Owned Address can be compromised with poor key custody. One approach has been to use Multi Signature Wallets, so that several signatures are required to make a transaction. The problems here are :-

(a) These keys are still Externally Owned Addresses,

(b) The signers have to be pre-defined and this is inflexible,

(c) The signing addresses are public, so that the access structure is known to everyone,

(d) The data for signing is large, possibly requiring many keys.

The solution is to use Threshold Signature Schemes (TSS), splitting the key up. From n possible signatories, a minimum of any t (n/2+1≤ t ≤ n) signatories can sign a transaction. Only at least t colluding players can forge the signature. This has these advantages:-

(a) It is private so that no one knows which t signers were used,

(b) If there are many possible signatories, then well performing ones can be chosen,

(c) It is efficient since only a single signature goes on the chain, looking like a regular signature.

Multichain's SMPC Network

At the heart of Multichain is its Secure Multi Party Computation (SMPC) Multichain network of nodes, which implements with the TSS Distributed Key Generation algorithm. This code has been completely and freshly written by Multichain's engineers and is optimised for multichain applications. Each node in a set, selected from the network, works independently from the others to generate part of the private key responsible for signing transactions. They collectively sign transactions, but crucially they cannot individually do so and the key is not reconstructed when signing. The complete key is never assembled and so it cannot be intercepted.

This is accomplished by several rounds of communication between the t+1 nodes. If one sends a bad message, then it is important that this node can be recognised, otherwise there is the possibility of a Dedicated Denial of Service Attack. GG20 solves this using an elegant property of the ECDSA algorithm, so that R, the part of the signature from a node can be used to query whether it was at fault (the 'bad actor'). Other features present in GG20 that increase efficiency are the ability to have Asynchronous Approval, where a large number of signatures can be pre-computed, calculating the R factor in the ECDSA signatures, before they are needed. This encompasses most of the computation and communication, with only the final round of communication necessary to actually sign the message, with all t nodes online at this stage. This means that for the bulk of the work, there is no longer the need for all nodes to be online simultaneously, with the implication that some network latency can be accommodated.

The SMPC network is responsible for signing transactions on each supported blockchain to perform a multitude of tasks comprising the management of asset accounts and smart contracts. A Threshold, will be needed to sign the transaction. This Threshold Signature (TSS) is denoted as (t, n), such as (9,15), (15,21), (21,31) etc., where t is the number of nodes needed to sign, and n is the total number of nodes in the set.

The nodes are run by different organisations, institutions and individuals, which independently run Multichain's protocol. The end result is a decentralized and trustless service. Multichains's code is completely open source, which is a pre-requisite of any system that describes itself as being decentralized. There is an inevitable trade-off between security and performance as the total number nodes and the threshold are changed. For the security of the system to be broken, t TSS nodes would have to collude to assemble the private key, but as t increases, this eventuality becomes vanishingly rare and this has not happened despite the length of time the network has been running and the huge TVL and daily volume that exists today on Multichain's network. Another possible security flaw rests on each blockchain itself. It is necessary to wait for a sufficient number of confirmations before finality can be agreed upon and so that any short lived forks cannot result in a double spend. These are the issues that ultimately limit the potential speed of cross-chain transactions.