Threshold Signatures Explained

The Power of Cryptography

To understand Threshold Signature Scheme (TSS), we first need to establish a foundation in cryptography. Since the 1970s, an increasing number of Internet systems, such as TLS (Transport Layer Security) and PGP (Pretty Good Privacy), have employed asymmetric cryptography, also known as public key cryptography (PKC). This cryptographic approach makes use of two distinct keys: one public and one private. While the public key can be freely published and used by anyone without compromising security, the private key remains a closely guarded piece of secret information that represents the cornerstone of the system's security architecture.

Encryption and digital signatures are the two most fundamental applications of PKC. Both encryption and digital signature schemes rely on sets of three core algorithms. The first algorithm handles the generation of the private and public key pair, establishing the cryptographic relationship between them. The second algorithm is responsible for generating either a ciphertext (in encryption) or a signature (in digital signing). The third algorithm manages the process of decryption or verification, ensuring that the cryptographic operations can be validated by authorized parties.

In the context of digital signatures, the signing algorithm requires the private key, which is known exclusively to its owner, to produce a unique signature. This signature is mathematically attached to a given message in such a way that anyone holding the corresponding public key will be able to verify both its authenticity and correctness. This verification process ensures that the message has not been tampered with and that it truly originated from the holder of the private key, providing both integrity and non-repudiation in digital communications.

Blockchain Technology and Cryptographic Foundations

There is no doubt that blockchain technology represents a revolutionary advancement in distributed systems. It provides a robust consensus layer that organizes and records events in a transparent, immutable manner. Such an infrastructure gives users the potential power to build decentralized economies, governance systems, and financial applications that operate without centralized intermediaries. Surprisingly enough, the cryptography needed to run a basic blockchain can be based solely on digital signatures, making it one of the most elegant applications of public key cryptography.

In the context of blockchain systems, private keys represent unique identities or ownership rights, while a signature serves as a public statement or claim made by that identity. The blockchain network will order these statements chronologically and validate them according to a predetermined set of consensus rules. These rules ensure, among other critical properties, that signatures are cryptographically unforgeable and mathematically correct, providing the security guarantees necessary for trustless transactions.

In contrast to the more classical cryptography utilized in early blockchain implementations, the modern cryptographic toolbox includes numerous advanced techniques that seem almost magical in their capabilities. These include zero-knowledge proofs, which allow one party to prove knowledge of information without revealing the information itself; homomorphic encryption, which enables computation on encrypted data; and multi-party computation, which allows multiple parties to jointly compute a function while keeping their inputs private. Over the past decade, blockchain research has pushed applied cryptography forward tremendously, with recent breakthroughs in all of these areas and much more.

In this article, we focus on a single such breakthrough that has particular relevance for blockchain security and key management: efficient secure threshold signatures.

Multi-Party Computation and Threshold Signature Scheme

Multi-party computation (MPC) is a specialized branch of cryptography that originated with the seminal work of Andrew C. Yao nearly four decades ago. In MPC protocols, a set of parties that do not necessarily trust each other attempt to jointly compute a function over their private inputs while keeping those inputs confidential from one another. This allows collaborative computation without requiring any party to reveal their sensitive data.

As a practical example, consider a scenario where n employees of a company want to determine who receives the highest salary without revealing their actual salary figures to each other. In this case, the private inputs are the individual salaries, and the desired output is simply the name of the employee with the highest salary. By performing this computation using MPC techniques, we ensure that not even a single salary value is leaked during the entire computation process, preserving privacy while achieving the desired result.

The two fundamental properties that define MPC protocols are correctness and privacy:

• Correctness: The output produced by the algorithm is accurate and matches what would be expected if the computation were performed by a trusted third party with access to all inputs.
• Privacy: The secret input data that each party holds remains confidential and does not leak to the other participating parties during or after the computation.

We can apply MPC principles to compute digital signatures in a distributed manner, creating what we call a threshold signature scheme. Let's examine how these properties apply to the signature generation process. Recall that traditional digital signatures involve three distinct steps, each of which must be adapted for the distributed setting:

• Key Generation: This first step is also the most complex in the distributed setting. We need to generate a public key that will be used to verify future signatures, but we must do so without any single party having access to the complete private key. Instead, we generate an individual secret share for each participating party. In terms of correctness and privacy, the key generation function outputs the same public key to all parties, while providing a different secret share to each participant. The privacy property ensures that no secret share data is leaked between the parties during generation, and the correctness property guarantees that the public key is a proper function of all the secret shares combined.

• Signing: This step involves a distributed signature generation function. The input of each party consists of its secret share, which was created as output of the previous distributed key generation step. There is also a public input known to all parties, which is the message to be signed. The output of the protocol is a digital signature that appears identical to one that would be generated by a single party holding the complete private key. The privacy property ensures that no leakage of secret shares occurs during the signing computation, even if some parties attempt to learn information about other parties' shares.

• Verification: The verification algorithm remains unchanged from the classical single-key setting. To maintain compatibility with existing blockchain infrastructure, everyone with knowledge of the public key should be able to verify and validate the signatures using standard verification procedures. This is exactly what blockchain validating nodes do when they process transactions, and they cannot distinguish between signatures generated by TSS and those generated by traditional single-key methods.

Threshold Signature Scheme (TSS) is the name we give to this composition of distributed key generation and distributed signing protocols, creating a complete system for managing cryptographic keys in a distributed manner.

Combining TSS with Blockchain Systems

The natural way in which TSS can be integrated into blockchain infrastructure is by modifying the blockchain client software to generate keys and signatures using TSS protocols instead of traditional single-key methods. Here, we use the term "blockchain client" to refer to the complete set of commands and operations executed by a full node in the network. In practice, TSS technology allows us to replace all private key related operations with distributed computations that involve multiple parties.

To explain this integration in more detail, let's start by describing how new addresses are created in classical blockchain designs. In the traditional approach, we create a new address by first generating a private key using a cryptographically secure random number generator. We then compute the corresponding public key from the private key using elliptic curve multiplication or another appropriate mathematical operation. Finally, the blockchain address is derived from the public key through a series of hash functions and encoding steps.

Now, when using TSS, we modify this process significantly. Instead of a single party generating the private key, we have a set of n parties jointly computing the public key through a distributed protocol. Each party holds only a secret share of the private key, and these individual shares are never revealed to the other parties during the computation. From the jointly computed public key, we can derive the blockchain address in exactly the same way as in the traditional system, making the blockchain network completely agnostic to how the address was actually generated. The crucial advantage is that the private key is no longer a single point of failure, because each party holds only one part of it, and no single party can forge signatures alone.

The same distributed approach can be applied when signing transactions. Instead of a single party signing with their complete private key, we run a distributed signature generation protocol between multiple parties. Each party uses its secret share as input to the protocol, and together they produce a valid signature that can be verified using the public key. The signature appears identical to one generated by a single party, but it requires cooperation from a threshold number of parties to create. This means we have moved from local computation, which represents a single point of failure, to an interactive distributed computation that is much more resilient to attacks.

It is important to mention that the distributed key generation can be configured to support different types of access structures. The most common is the "t out of n" setting, where any t parties out of the total n parties can cooperate to generate a valid signature. This configuration can withstand up to t-1 arbitrary failures or compromises in private key related operations without compromising the overall security of the system. This flexibility allows organizations to tailor the security model to their specific needs and risk tolerance.

TSS vs. Multisig

Some blockchain platforms offer functionality similar to TSS as a built-in or programmable feature of their protocol. We commonly refer to this functionality as multisig or multi-signature. To better understand the differences between these approaches, we can conceptualize multisig as implementing TSS-like functionality at the application layer of the blockchain, rather than at the cryptographic layer.

Put differently, both multisig and TSS are essentially attempting to achieve similar security goals—requiring multiple parties to authorize a transaction—but they accomplish this through fundamentally different mechanisms. TSS uses cryptography off-chain to generate what appears to be a standard single signature, while multisig operates entirely on-chain by requiring the blockchain to validate multiple separate signatures.

This architectural difference has several important implications. The blockchain network needs a way to encode and process multisig transactions, which can harm privacy because the access structure, including the number of required signers and their identities, is exposed on the blockchain for anyone to analyze. Additionally, the cost of a multisig transaction is typically higher than a standard transaction because the information about all the different signers and their individual signatures must be communicated and stored on the blockchain.

In contrast, with TSS, all the details about the multiple signers are folded into what appears to be a regular single-signature transaction. This reduces both the transaction cost and the amount of information revealed on the blockchain, maintaining better privacy for the participants. On the other hand, multisig has the advantage of being non-interactive once the transaction is broadcast, which eliminates the need to run a complex communication layer between the different signers during the signing process.

The main point of difference is that multisig is blockchain-specific and needs to be separately implemented for every blockchain protocol. In some cases, particularly with older blockchain networks, multisig functionality is not supported at all, or only in limited forms. Conversely, TSS relies on pure cryptography that operates independently of the blockchain protocol, so support is theoretically always possible for any blockchain that uses standard digital signature schemes.

TSS vs. Shamir Secret Sharing Scheme

The Shamir Secret Sharing Scheme (SSSS) provides a different approach to distributing private key material. SSSS offers a way to store the private key in a distributed manner such that while the private key is at rest, it is split and stored in multiple locations. However, there are two critical differences between SSSS and TSS that make them suitable for different use cases:

• Key Generation: In SSSS, there is a single party called "the dealer" that is responsible for generating the complete private key and then splitting it into secret shares. This means that at the time of key generation, the complete private key exists at a single location and is then distributed by the dealer to the different storage locations. This creates a critical vulnerability during the key generation phase. In contrast, TSS eliminates the dealer role entirely by distributing the key generation process itself. The full private key is never constructed at any single location during its entire lifecycle, providing stronger security guarantees from the very beginning.

• Signing: In SSSS, when a signature is needed, the parties must first reconstruct the full private key by combining their secret shares. This reconstruction process creates a single point of failure each time a signature is generated, as the complete private key must exist somewhere, even if only temporarily in memory. In TSS, the signing operation is performed in a fully distributed manner without ever reconstructing the complete private key. Each party uses only its secret share as input to the signing protocol, and the parties interact to jointly produce a valid signature without any single party learning the complete key.

As we can see, in TSS the private key, which represents the ultimate security of the entire system, is never present at a single location throughout its entire lifetime—not during generation, not during signing, and not during any other operation. This represents a fundamental security improvement over SSSS for active cryptographic operations.

Threshold Wallets

A cryptocurrency wallet based on TSS technology operates quite differently from traditional wallet implementations. Typically, a conventional wallet generates a seed phrase (usually 12 or 24 words) and uses it to deterministically derive all the wallet's addresses and their corresponding private keys. The user can later use this hierarchical deterministic (HD) structure to accomplish two important tasks: first, to reach the private keys that correspond to the wallet addresses and sign transactions with them, and second, to recover all wallet keys using just the seed phrase if the wallet is lost or damaged.

In a threshold wallet, the architecture is considerably more complex. Although it is possible to generate an HD structure similar to traditional wallets, its generation must be computed in a distributed manner using another MPC protocol. The participating parties need to jointly decide on what is the next key to be derived in the sequence, following the HD derivation path. In other words, each party will maintain a seed phrase of its own, but these seed phrases are generated separately through a distributed process and are never combined. This ensures that no single party alone can derive the private keys from its seed, maintaining the distributed security property throughout the key derivation process.

TSS-based wallets also offer an additional security feature that is not available in traditional wallets: the ability to perform private key rotation without changing the corresponding public key and blockchain address. Private key rotation, also known as proactive secret sharing, is yet another MPC protocol that takes the existing secret shares as input and outputs a new set of secret shares. The old secret shares can be securely deleted and the new ones can be used in exactly the same way for signing operations, but with the public key and address remaining unchanged.

Such a structure adds a temporal dimension to the security model, which means an attacker must compromise multiple locations simultaneously to successfully attack a threshold wallet. Simply combining secret shares from before the rotation with shares obtained after the rotation will give the attacker no additional power to forge signatures. This makes the system resilient against attacks that unfold over time, where an attacker might compromise different parties at different moments.

A downside of this type of wallet is that the lack of a single master seed phrase makes it incompatible with traditional single-key wallet systems and recovery procedures. Users cannot simply write down 12 words and expect to recover their wallet on a different system. Therefore, it's important to carefully consider which parties will hold the secret shares and how backup and recovery will be managed.

There are several possible architectures for deploying threshold wallets:

• Outsourcing TSS: The user delegates the TSS computation to n independent servers that run the protocols on their behalf. This effectively outsources the key generation, management, and signing operations to service providers who are not the legal owners of the assets but provide a security layer in return for some incentive or fee. This model is similar to how many cloud-based services operate.

• Using Multiple Devices: The user runs the TSS protocols across multiple devices they personally own and control. For example, one party might be an IoT device in the user's home, another party their mobile phone, another their laptop, and so on. This gives the user complete control but requires coordination across devices.

• Hybrid Approach: TSS protocols are executed such that some parties are controlled by external service providers while other parties run on user-owned devices. This combines elements of both previous approaches.

The first method has the advantage of offloading the computationally heavy TSS operations from the user's client-side devices. However, there is a risk that the service providers could collude to steal the user's assets. While we assume that a sufficient number of providers will not be compromised simultaneously, in practice they might be subject to legal pressure or coordinated attacks.

The second method gives the user complete control over all parties and eliminates third-party risk, but it can be cumbersome to conduct transactions. The user needs multiple devices to be online simultaneously and to engage in the interactive TSS computation, which may not always be practical.

The third option is often considered the best of both worlds. It gives the user a convenient and fast way to conduct transactions while still maintaining a requirement for user authorization. Even if some service provider parties are compromised, the attacker cannot forge signatures without also compromising the user's personal devices.

TSS and Smart Contracts

Over the years, researchers have discovered many innovative uses for digital signatures, and some applications are surprisingly sophisticated and non-trivial. As mentioned, TSS is a cryptographic primitive that can greatly enhance security in blockchain systems. In the broader context of blockchain applications, we may observe that many functionalities traditionally implemented through smart contracts can potentially be replaced with TSS-based cryptographic protocols.

Decentralized applications, layer 2 scaling solutions, atomic swaps, mixing protocols, inheritance mechanisms, and much more can be built on top of a TSS framework. This would eventually allow expensive and potentially risky on-chain smart contract operations to be replaced by cheaper, more efficient, and more reliable off-chain cryptographic alternatives. By moving complex logic from the blockchain to cryptographic protocols, we can reduce transaction costs and improve privacy.

To provide some concrete examples of this approach: Multi-Hop Locks is a construction that makes use of two-party signatures in a clever way and can serve as an alternative to certain layer 2 payment channel networks. It offers a more secure and private payment channel network by reducing the amount of information that must be published on-chain. ShareLock is probably one of the most cost-effective on-chain mixing solutions for smart contract platforms, based on the verification of a single threshold signature rather than complex smart contract logic. These examples demonstrate how TSS can enable new designs that were not previously practical.

Risks and Limitations

In recent years, there has been a significant increase in the number and quality of TSS implementations. However, as a relatively new technology in the blockchain space, it still has some limitations and concerns that should be carefully considered. Compared to classical public key cryptography, which has been studied and battle-tested for decades, TSS protocols can be significantly more complex in their design and implementation.

The complexity of TSS protocols means they are yet to receive the same level of scrutiny and "battle-testing" that traditional cryptographic primitives have undergone. Usually, TSS protocols require additional, and sometimes weaker, cryptographic assumptions compared to simple digital signatures. For example, they might rely on the security of commitment schemes, zero-knowledge proofs, or other auxiliary cryptographic tools. As a result, new cryptographic attack vectors that did not exist in traditional single-key setups are continuously being discovered and addressed by researchers.

Implementation bugs are also a concern, as the distributed nature of TSS protocols creates more opportunities for subtle errors in the code. Security engineers and applied cryptographers with specific expertise in MPC and TSS should be consulted to assist in safely deploying TSS technology in production systems. Proper auditing and testing are essential.

On the positive side, the ecosystem of existing and new TSS implementations is becoming stronger and more mature. This improvement is driven by an increase in quality contributions from the research community, thorough peer reviews of protocols and implementations, professional security audits, and continuous algorithmic performance improvements. As the technology matures and more implementations are deployed and tested in real-world conditions, confidence in TSS security will continue to grow.

Despite these challenges, the potential benefits of TSS for blockchain security and key management make it a promising technology worth careful consideration and continued development.

Practical Considerations

When implementing TSS in blockchain systems, several practical considerations must be addressed. The communication overhead between parties can be significant, especially for protocols that require multiple rounds of interaction. Network latency and reliability become critical factors in the performance of TSS-based systems. Organizations must carefully design their network architecture to ensure that parties can communicate efficiently and reliably during key generation and signing operations.

Another important consideration is the handling of party failures and recovery. In a distributed system, it is inevitable that some parties may go offline or become unavailable. TSS protocols must be designed with robustness in mind, allowing the system to continue functioning even when some parties are temporarily unavailable, as long as the threshold requirement is met. Additionally, procedures for adding new parties or removing compromised parties must be carefully planned and implemented.

The choice of threshold parameters (t and n in a t-out-of-n scheme) is also crucial and depends on the specific security requirements and operational constraints of the system. A higher threshold provides more security but requires more parties to cooperate for each operation, which can impact availability and performance. Organizations must carefully balance security, availability, and operational efficiency when designing their TSS deployment.

Finally, user experience considerations are important for TSS-based wallets and applications. The distributed nature of TSS operations can introduce latency and complexity that users may find confusing or frustrating. Careful interface design and clear communication about the security benefits can help users understand and accept these trade-offs. As TSS technology matures and implementations become more efficient, many of these user experience challenges will likely be addressed, making TSS-based systems more accessible to mainstream users.

FAQ

What are Threshold Signatures (门槛签名)? How do they differ from ordinary digital signatures?

Threshold Signatures enable multiple participants to collectively generate a signature without any single party holding the complete private key. Unlike ordinary digital signatures, they enhance security and resilience by distributing signing authority across participants.

What are the practical applications of threshold signatures in blockchain and cryptocurrency?

Threshold signatures distribute signing authority among multiple participants, enabling joint authorization while enhancing security. They are widely used in multi-signature wallets, decentralized custody solutions, and distributed governance mechanisms to prevent single points of failure.

What is the difference and connection between Threshold Signatures and Multi-Sig Wallets?

Both require multiple signatures for transactions. Multi-Sig Wallets use smart contracts with multiple independent private keys, while Threshold Signatures employ cryptographic secret sharing to split keys. Threshold Signatures are more private and efficient, as signatures are generated off-chain without exposing individual key fragments.

How to achieve secure and decentralized key management through threshold signatures?

Threshold signatures require multiple parties to sign transactions collaboratively. Even if some keys are compromised, assets remain secure as long as the signing threshold is met. This approach enhances security and decentralized governance while protecting against single points of failure.

What security advantages do threshold signatures have compared to traditional key management methods?

Threshold signatures distribute key control across multiple parties, eliminating single points of failure. No individual holds complete signing authority, reducing compromise risks. They require quorum consensus for transactions, providing superior protection against key theft and unauthorized access compared to centralized key management.

What cryptographic foundations are needed to implement threshold signatures, such as Shamir Secret Sharing?

Threshold signatures require understanding Shamir Secret Sharing algorithm, multi-signature schemes, and distributed key management fundamentals to securely split and reconstruct cryptographic keys among multiple parties.