A few weeks ago, we shared a blog post about the first ever Zilliqa Threshold Signatures Scheme (TSS) transaction. Today, we are open-sourcing the code to the community so that everyone can create such TSS transactions.
A great leap forward! $ZIL is now one of the first coins that can be controlled via Treshold Signature Scheme (TSS) for #Schnorr signatures. Huge congratulations to the @Zengo for making this happen! #noprivatekey #blockchain #security Read more here: https://t.co/ZmT4GIUFnH pic.twitter.com/1TL8wa8z4S
— Zilliqa (No airdrops or ETH giveaways) (@zilliqa) April 9, 2019
By using TSS, we remove the burden of having a single atomic private key and split the responsibility between multiple parties.
In this blog post, we at Zengo would like to share some details about this project executed by our blockchain research team.
Threshold Signatures Scheme (TSS)
Threshold Signatures Scheme (TSS) removes the burden of the single atomic private key and splits the responsibility between multiple parties.
Each of the parties generates its own secret and uses this secret to distributively sign a transaction without revealing the secret to the other parties.( For a high-level overview of TSS, please refer to our blog post)
For this Proof-of-Concept (PoC) project we used our open source implementation of TSS for Schnorr signatures
We have invested a lot of resources in implementing TSS and making it compatible and reusable for different kinds of blockchains and Digital Signatures Algorithms . This compatibility allows us to rapidly onboard and add TSS support to new blockchains.
Why Zilliqa Coin?
At KZen, we have already implemented Threshold Signatures Scheme (TSS) support for Bitcoin, Ethereum, and Binance and wanted to experiment with other coins.
We choose ZIL mainly for the following main reasons:
- Zilliqa’s trust in our project: Zilliqa recognized the importance of our work early-on and awarded us a grant to develop a TSS wallet for their token.
- Relevance: Earlier this year, Zilliqa had launched their mainnet, which is naturally a key milestone for the Zilliqa coin. Zilliqa also announced smart contracts support just a few days ago.
Ziiliqa project timeline (https://zilliqa.com/)
- Technical maturity: To implement a TSS wallet with a blockchain, we need a mature enough developer environment. The Zilliqa Network had all the required ingredients in its testnet:
- a faucet so we could test everything without risking money
- a blockchain explorer so that we could confirm that our transactions were successfully recorded on the blockchain
- Access to the testnet was provided via API and an Open source SDK which was far more comfortable than needing to setup a full node
- Technical novelty: Our previous experiments of TSS with actual coins were limited to those based on ECDSA signatures. This is the first time we (or anyone else, to the best of our knowledge) has implemented TSS for a Schnorr signatures-based coin. Schnorr signatures offer many interesting capabilities and are widely considered as crucial to the future of blockchains, including Bitcoin. To learn more about Schnorr signatures read our Hackernoon story.
TSS is needed even if Zilliqa Supports MultiSig
It’s worth noting that even though Zilliqa supports Schnorr Multi-Signatures (MultiSig) and smart contracts which allow users to add multi-party security, there are still distinct advantages to using TSS. One main advantage is that TSS transactions look exactly the same as regular transactions. Unlike with MultiSig transactions, the TSS “magic” is applied in the mathematical layer and not in the application layer:
- If MultiSig is realized through smart contracts it may incur additional fees for the smart contract execution. Additionally, MultiSig smart contract functionality might be difficult to verify, as shown by the multiple incidents suffered by some Ethereum-based MultiSig smart contracts.
- The message size does not expand: With TSS, there is no overhead of added data structures within the transaction to manage the additional parties.
- The control mechanism is not exposed to the world: With TSS, the signing parties are never exposed and therefore, adversaries cannot learn about the various parties or their control structure, nor can they monitor changes to them.
- Comprehensive control mechanisms: Using TSS, the user can create all kinds of comprehensive arbitrary control mechanisms (e.g. combine a few parties from one group and a few parties from another group)
- Currently, it seems that Zilliqa only uses Schnorr MultiSig for their internal consensus mechanism. The current Zilliqa API does not allow end users to make use of the MultiSig function. TSS provides multi-party capabilities directly to Zilliqa’s end users.
The fact that Zilliqa has funded the KZen research team demonstrates their interest in integrating TSS functionalities with Zilliqa.
The Proof of Concept and Beyond
The Zilliqa blockchain network is innovative, introducing concepts such as sharding to support transactions and smart contracts at scale. However, because TSS is blockchain agnostic, it is able to easily integrate with this unique architecture. This compatibility is what allowed us to complete this PoC in one day with no need for “integration” on the Zilliqa side. Using the aforementioned SDK, we first made sure we could generate a normal transaction. Next, we modified the SDK in a crude manual manner to provide Proof-of-Concept for sending TSS transactions. Lastly, we forked and modified the original SDK to properly integrate it with our TSS Schnorr library and to enable a polished way to generate a TSS key and sign a transaction. This is what we are announcing today.
Applying TSS key generation and signing to Zilliqa’s SDK
- Generation: We changed the code so that the public key is generated by KZen TSS setup and exported to the ZIL client instead of being computed from a private key.
Of course, this part does not prove anything as any random string can be successfully converted into an address. The real challenge now is to sign a transaction from this address.
- Signing: This part was a bit more complicated from an engineering point of view, as the existing code assumes that there is a private key and uses it in multiple functions (reminder – there’s no private key). However, the main change was in the signing function; we changed how the message was exported so that it was signed by our TSS demo instead of a private key.
During this part, we identified that Zilliqa uses a slightly different variant of the Schnorr signatures (compared to Bitcoin’s BIP-Schnorr ) and we updated our Schnorr TSS library accordingly to accommodate this variation.
Using the code
We use a client and server architecture. The server acts solely as the co-signer in the two-party protocol and holds no logic specific to Zilliqa.
You can play with the SDK using the command-line, as shown in the demo below.
Naturally, you can interact with the SDK via your code.
launching the server:
TSS server launch
Using the client (API is almost identical to original Zilliqa JS library):
Conclusions and Future plans
All in all, it was very rewarding for us to add TSS support to a relevant crypto asset. It only took us several working hours to create the initial PoC and a few more working days to make it developer-ready by leveraging our previous experience with generic TSS infrastructure.
Our work with TSS is not done. We plan to continue to extend this project in the future. We will also continue to bring TSS to other chains and coins.
