The screenshot above, showing the transactions history of a Binance Coin (BNB) address may look like any other. However, it represents an historic moment. This address is not a regular BNB address controlled by a private key. In fact, this address, to the best of our knowledge, is the first ever BNB address controlled by a Threshold Signatures Scheme (TSS)!
Using TSS we remove the burden of having a single atomic private key and split the responsibility between multiple parties. In this case, four parties are controlling the address, where any group of three out of them is required to sign to spend the funds.
In this blog post we would like to share some details about this Proof-of-Concept (PoC) project, conducted by KZen’s blockchain research team.
Threshold Signature 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 these secrets are later used to distributively sign a transaction without revealing the secrets to the other parties. To learn more about TSS in high level please refer to our blog post.
For this Proof-of-Concept (PoC) project we used our open source implementation of the Genarro-Goldfeder paper that allows an efficient implementation of TSS for ECDSA (Elliptic Curve Digital Signing Algorithm): https://github.com/KZen-networks/multi-party-ecdsa
As seen in demo TSS happens in two stages:
- Generation: all the involved parties are connected and each computes its own secret share to distributively compute the public key
- Signing: to sign a sub-group of the parties, consisting of at least threshold + 1 parties (hence “Threshold”), can distributively sign a transaction without revealing the secrets to the other parties.
We had invested a lot of resources in implementing TSS and making it generic and reusable for different kinds of blockchains. The investment starts to pay off now, as we can rapidly onboard and add TSS support to new blockchains.
Why Binance Coin (BNB)?
In KZen we already implemented Threshold Signatures Scheme (TSS) support for Bitcoin (see https://github.com/KZen-networks/gotham-city ) and Ethereum and wanted to experiment with other coins.
We choose BNB for three main reasons:
Business Impact: Amidst the so-called “crypto-winter” when most other assets price is declining or stagnant, BNB stands out with a bullish trend
Technical Maturity: to implement a TSS wallet for a blockchain, we need a mature enough developer environment. Binance network had all the required ingredients in its testnet
- a faucetthat can give developers some free “test money” to experiment without worrying about the financial consequences
- a blockchain explorerto make sure our transactions are successfully recorded by the blockchain
- Access to testnet is provided via API and an Open source SDK, which is way more comfortable than setting up a full node
Lack of Native MultiSig Support: Although inferior to TSS, MultiSig can offer a way to split the responsibility between multiple parties. Bitcoin supports MultiSig through its scripting language, Ethereum supports MultiSig with smart contracts. However, it seems that BNB does not support this feature yet. Therefore, TSS support would make a great improvement.
The Proof of Concept (PoC)
Binance network might be innovative in many aspects: it’s built on the Cosmos infrastructure and Tendermint consensus for Proof-of-Stake, but the beauty of TSS is that it completely agnostic to the specifics of the blockchain. TSS only changes the client (wallet) to generate the transaction in a TSS manner. TSS does not need to know about the blockchain, and the blockchain does not need to know about TSS. That’s what allowed us to complete this PoC in one day with no need for “integration” on the Binance side.
Using the SDK we first made sure we can generate a normal transaction.
Then we refactored it by applying TSS Generation and Signing
Generation: we changed the code such that the public key will be generated by KZen TSS setup (see above) and exported to BNB client instead of being computed from a private key.
Of course, this part does not prove a lot, 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 a private key to be present and uses it in multiple functions. (reminder – there’s no private key). However, the main change was in the signing function, having it export the message to be signed to our TSS demo instead of signing it with a private key
Once we had verified that TSS works in BNB blockchain by getting success results from the API and checking the transactions in the explorer (see above), we had 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 and all it was a very rewarding experience for us to add TSS support to a relevant crypto asset in a matter of a few working hours by leveraging our previous investments in our generic TSS infrastructure.