THORChain publish TSS Whitepapers
The THORChain TSS white paper, as well as an associated benchmarking paper, are available for review.
Summary
THORChain is able to achieve its vision of a chain-agnostic decentralised liquidity network with the breakthrough that is Fast multi-party Threshold ECDSA with Fast Trustless Setup, known as the Genarro-Goldfeder-2018 routine. Instead of linking to other chains with multi-signatures (which are highly opinionated in implementation and membership) THORChain elects to use a threshold-signature scheme that only requires a pre-set threshold of members.
In addition to this, THORChain’s state machine aggressively churns TSS committee membership so that keys never stagnate and nodes are driven to having extremely high uptime.
The team have completed the first draft of the THORChain TSS white paper, which explains the overall mechanism and some key additions to make it robust and suitable for THORChain’s needs.
TSS Whitepaper:
https://github.com/thorchain/Resources/blob/master/Whitepapers/THORChain-TSS-Paper-June2020.pdf
Benchmarking Paper
https://github.com/thorchain/Resources/blob/master/Whitepapers/THORChain-TSS-Benchmark-July2020.pdf
THORChain TSS
THORChain TSS is an implementation of the GG18 protocol written in Golang. It is a sub-service in a THORNode and is called on a restful API by the main thord daemon. THORChain TSS is stateless in the sense that it is told what to sign and when, and it returns the signed message on conclusion.
THORChain TSS has a single private key that is hashed into different public keys for different curves, and then encoded into different addresses for different chains. This key is used to sign main TSS vault communication rounds.
THORChain TSS is a practical distributed threshold signature protocol which is based on the the scheme proposed by Genarro-Goldfeder in 2018. It allows a number of parties to collaborate together to generate a public key that can be used to verify the correctness of a given signature. The feature of leader-less is achieved by avoiding any of the parties involved in the keygen knowing the private key to the generated public key. It is a robust protocol which allows a threshold of parties to participate in signature generation thus avoids the issue of single point of failure. End-to-End encryption ensures the security of the communication. Reliable broadcast reduces the risk of single point of failure. The blame scheme is introduced to punish the nodes who do not comply with the protocol. The attacker has a low motivation to attack the network as they face a high risk of losing their bond.
THORChain adds new features such as parallel and batch signing for faster throughput, as well has having an ability to identify a malicious node and blaming them. If all nodes agree on who to blame, the blamed node will be slashed and lose funds.
Thus nodes are economically driven to being honest and reliable.
The network separates out different aspects to its architecture to ensure separation of concerns and modularity.
Overview Of Process
When a keysign request is sent to THORChain TSS, local node firstly checks whether it has enough peers to run the keysign. If this node is an active participant, it runs the join party scheme and waits for other peers to show up within a given time. If any party fail to join the party within a given time, others blames that party and quits the keysign process. If all peers are shown up in a given time, the keysign process is kicked off. It digests the shares received from other peers within a given time otherwise, blame the party who fail to offer the share. Finally, the keysign process is done, and it waits for the notifications sent from the peers which indicating all the peers finish the keysign. Before it quits the keysign process, it broadcasts the generated signature to all the parties who are involved in the same keygen process.
THORChain TSS has been audited by Kudelski.
THORChain TSS Benchmarking
Since THORChain TSS adds several other mechanisms to ensure safety to its routine, the team have benchmarked it the distributed setting. The team deployed THORChain TSS nodes from 3 nodes up to 30 nodes in Digital Ocean data centre and Amazon Web Service(AWS), all virtual machines with 1G memory and 1 CPU.
To deploy the benchmark environment, 10 virtual machines were deployed on AWS and 22 virtual machines in Digital Ocean machines. To make it fair, 22 Digital Ocean virtual machines were across 4 regions. For each benchmark, the protocol randomly picked nodes to form the THORChain TSS party and ran the test for 5 times to get the average running time.
It can be observed in Fig 6 that the time spend on keygen/keysign increases quadratically with the increase of the nodes involved in the THORChain TSS. In general, keygen operation consumes much more time compared with keysign operation. The time spent on keygen is predicted by the equation y = 67.672x2 + 916.8x + 11572 with R2 = 0.9562 where x is the number of the nodes involved in the THORChain TSS. The time spent on keysign is predicted by the equation y = 50.252x2 − 373.93x + 6198.1 with R2 = 0.8958 where x is the number of the nodes involved in the THORChain TSS.
According to Table 3, for 6 nodes THORChain TSS, it takes about 18 seconds to run the keygen and it takes about 15 seconds to run the keysign. For the 30 nodes keygen, it needs about 109 seconds to run the keygen and it needs about 47 seconds to run the keysign.
Through the benchmarking, it can be concluded for a small number of nodes, the crypto-graphic computation dominates the time spent on THORChain TSS processing, while with the growth of the number of the nodes in the network, the time spent on sending/receiving the data from the peers overwhelms the time spent on calculating the THORChain TSS intermediate results. According to the result of the benchmark, the time growth of THORChain TSS pro- cessing is quadratic. THORChain TSS is viable for key-generating and key-signing committees up to 30 nodes.
Asynchronous Liquidity Delegation
Note: Asgard TSS transactions are only used for processing unstakes, bond redemptions transactions, as well as topping up the small Yggdrasil vaults and Ragnaröking. All swaps are sent from Yggdrasil vaults which can redeem in less than a second — which the team call Asynchronous Liquidity Delegation. Yggdrasil vaults are currently 1/1 (but may become 2/3 vaults) so speed is not an issue.
Thus having a key-signing ceremony take 18 seconds for a 22/33 committee size is well within expectations for redeeming against vaults.
Scaling to 99+ nodes
This sets the basis for the team’s plan for Native RUNE and sharded Asgard Vaults. Since Native RUNE can be secured in the THORChain state machine, which requires 66/99 tendermint consensus, it does not need to be held in a single large Asgard Vault. Instead, the external funds (Bitcoin, Ethereum etc) can be split up into smaller 22/33 vaults, and the nodes participating in each vault are held at ransom with their native RUNE bond. This now makes the consensus bottleneck the underlying tendermint infrastructure, and no longer the TSS committee size.
GG20
The latest update to GG18 is called Genarro-Goldfeder 2020, and the team have already completed integration of it into THORChain. It promises faster signing and more robust identifiable aborts.
The team will re-run the benchmarking of GG20 once it is finalised and it will likely be in place for Multi-chain Chaosnet.
Community
To keep up to date, please monitor community channels, particularly Telegram and Twitter:
- Twitter: https://twitter.com/thorchain_org
- Telegram Community: https://t.me/thorchain_org
- Telegram Announcements: https://t.me/thorchain
- Reddit: https://reddit.com/r/thorchain
- Github: https://github.com/thorchain
- Medium: https://medium.com/thorchain
