Adding Threshold Signature Scheme (TSS) to Tezos

Tezos Transaction (source)

The Tezos 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 Tezos address controlled by a private key. In fact, this address, to the best of our knowledge, is the first ever Tezos address controlled by a Threshold Signatures Scheme (TSS), making it also the first coin address controlled by a TSS for EdDSA signatures.

If you have been following us closely, this probably doesn’t surprise. We’ve already achieved the same with Binance Coin (BNB) and Zilliqa (ZIL).

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 Tezos 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 EdDSA signatures. It’s worth noting that this project utilizes, for the first time, our generic MPC (secure Multi Party Computation) network layer. Currently, we only support the “N out of N” scenario, meaning all involved parties need to sign. In the future, we plan to support also the “T out of N” scenario in which only a sub-group of the parties needs to sign.

Two party EdDSA key generation and signing (source)

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 integrate TSS support with new blockchains.

Why Tezos?

At KZen, we have already implemented Threshold Signatures Scheme (TSS) support for Bitcoin, Ethereum, Binance, and Zilliqa and we wanted to experiment with other coins.

We choose Tezos for the following main reasons:

  • Tezos’ trust in our project: The Tezos Foundation recognized the importance of our work early-on and awarded us a grant to develop TSS support for their blockchain
  • Economic novelty: Tezos users are rewarded for actively participating in the consensus (“staking”) and thus, help to secure the network. Making money is always a welcomed feature for users.
  • Technical maturity: To implement a TSS wallet with a blockchain, we need a mature enough developer environment. Tezos network had all the required ingredients in its testnet:  
    • a faucet so we could test everything without risking real money
    • a blockchain explorer so that we could confirm that our transactions were successfully recorded on the blockchain
    • Access to the testnet which 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 and Schnorr signatures. This is the first time we (or anyone else, to the best of our knowledge) has implemented TSS for an EdDSA signatures-based coin.

TSS is needed even if Tezos Supports MultiSig

It’s worth noting that even though Tezos supports smart contracts which allow users to add multi-signature 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 executer. 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 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).

The fact that Tezos has funded the KZen research team demonstrates their interest in integrating TSS functionalities with Tezos.

The Proof of Concept

Tezos’ blockchain network is innovative, introducing concepts such as staking and baking to support Proof-of-Stake consensus. 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 Tezos side.

Using the SDK, we first made sure that we can generate a normal transaction.

Creating a normal transaction on Tezos (source)

1. Generation: We changed the code so that the public key is generated by KZen TSS setup and exported to the Tezos 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.

During this process, we learned that the first transaction for a newly created address requires some fees for storage.  

2. 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 process, we learned that for an address to send money, it must be “revealed,” which is just another message on the Tezos blockchain that we had to create and sign (Using TSS, naturally). As a by-product, this shows that we can create any Tezos messages, including the Origination and Delegation messages involved with the staking process.

We then verified that TSS works with the Tezos blockchain by getting successful results from the API and verifying the transactions in the explorer (see above).

Conclusions

We plan to refactor the code to interact directly with our TSS setup and release it as an open source project soon. We will include an interface to relevant features such as Origination and Delegation messages to support with the staking process.

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.