Adding Threshold Signature Scheme (TSS) to Zilliqa Coin (ZIL)

A Zilliqa transaction (source: Zilliqa explorer )

The Zilliqa Coin (ZIL) address in the transaction details above may look like any normal address. However, the address represents a historic accomplishment. This address is not a regular ZIL address controlled by a private key. In fact, this address, to the best of our knowledge, is the first ever ZIL address controlled by a Threshold Signatures Scheme (TSS), making it also the first coin address controlled by a TSS for Schnorr signatures.

If you have been following us closely, this probably doesn’t surprise you as we achieved the same with Binance Coin (BNB)

By using TSS, we remove the burden of a single atomic private key and split the responsibility between multiple parties. In this case, two parties control the address and both of them are required to sign the transaction.

With TSS there is no private key

In this blog post, we will share some details about this Proof-of-Concept (PoC) project, conducted by KZen’s (building ZenGo Wallet) 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: https://github.com/KZen-networks/multi-party-schnorr

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 (DSAs). 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, (https://github.com/KZen-networks/gotham-city ) Ethereum, and Binance and wanted to experiment with other coins.

We choose ZIL 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: Zilliqa recently launched their mainnet, which is naturally a key milestone for the Zilliqa coin.
Ziiliqa project timeline (https://zilliqa.com/)
  • Technical maturity: To implement a TSS wallet with a blockchain, we need a mature enough developer environment. Zilliqa network had all the required ingredients in its testnet:  
  • faucet so we could test everything without risking money
  • blockchain explorer so that we could confirm that our transactions were successfully recorded on the blockchain
  • Access to testnet was provided via API and an Open source SDK which was far more comfortable than setting up a full node)
  • Technical novelty: Our previous experiments of TSS with actual coins were limited to ECDSA signature. This is the first time we (or anyone else, to the best of our knowledge) had implemented TSS for a Schnorr signatures-based coin. Schnorr signatures offer many interesting capabilities and are widely considered crucial to the future of blockchains, including Bitcoin. To learn more about Schnorr signatures see our Hackernoon story.

TSS is needed even if Zilliqa Supports MultiSig

It’s worth noting that even though Zilliqa supports Schnorr Multi-Signatures (MultiSig) 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:

  • 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 parties required to sign are never exposed and therefore, adversaries cannot learn about the control structure, monitor changes to them, or target them with attacks.
  • Comprehensive control mechanisms: Using TSS, the user can create all kinds of comprehensive arbitrary control mechanisms (e.g. a few parties from one group and a few parties from another group)    
  • Currently, it seems that Zilliqa only uses 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

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 SDK, we first made sure that we can generate a normal transaction.

Then we needed to change it by applying TSS generation and signing.

  1. 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.
Generating an address from a public 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.

  1. 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.

We then verified that TSS works with the Zilliqa blockchain by getting success results from the API and checking the transactions in the explorer (see above). We then refactored the code to interact directly with our TSS setup instead of copy-pasting values manually. We plan to release the code as an open source project soon.

All in all, it took us only a few hours to add TSS support to this leading crypto asset. The experiment successfully demonstrated how easily blockchains can integrate our generic TSS infrastructure.