TL;DR: ZetaChain is pioneering the use of Threshold BLS (tBLS) signatures to unlock orders of magnitude of speedup and scalability in cross-chain transaction throughput. This approach replaces complex, low-throughput threshold ECDSA with a faster, simpler, and non-interactive alternative — making cross-chain apps vastly more efficient. Dive deeper into this ZetaChain improvement proposal (ZIP) for Threshold BLS.

Blockchain interoperability has become ever more important, enabling decentralized networks like ZetaChain to securely control assets across prominent chains such as Ethereum and EVM L1/L2 chains, Solana, SUI, and TON. Currently, ZetaChain, an L1 blockchain, primarily employs Threshold ECDSA (GG18/GG20) for authenticating externally owned accounts (EOAs) and smart contracts. However, this approach exhibits notable performance and complexity limitations, motivating the exploration of alternative threshold cryptographic schemes.

Why Threshold Signatures?

Threshold signatures scheme (TSS) enable a distributed group of validators (Signers) to collaboratively authorize transactions without entrusting the secret key to any single entity. This greatly enhances security by ensuring no single point of failure and increasing resilience against malicious activities. Threshold signatures provide fault tolerance (transactions can still be signed if some validators are compromised) and flexibility (signatures can be verified by any subset above a predefined threshold).

In ZetaChain TSS is used for access control and asset control on external chains, authenticating messages that come from the ZetaChain validators.

Current Approaches for Asset Control

ZetaChain currently relies exclusively on Threshold ECDSA (GG18/GG20) which, despite its compatibility with many chains and low verification cost, faces critical challenges:

• High computational complexity and low throughput

• Significant synchrony overhead, requiring all validators to coordinate simultaneously.

• Difficulty in attributing signing failures, complicating incentive alignment and fault detection.

Survey of Threshold Signature Schemes

Threshold ECDSA (GG18/GG20/CMPGG21)

• Pros: Native compatibility (Ethereum, Bitcoin, and others), low on-chain verification costs.

• Cons: Complex multi-round signing ceremonies, synchronization requirements, limited throughput.

Threshold BLS Signatures

• Pros: Non-interactive signing, simpler cryptographic operations, high throughput.

• Cons: Requires contract-based verification, higher verification cost compared to native ECDSA.

Contract Multisig (Gnosis Safe as an example)

• Pros: Simple setup, broad existing chain support, non-interactive.

• Cons: On-chain complexity and costs scale linearly with the number of signers.

Introducing Threshold BLS Signatures

Threshold BLS (Boneh-Lynn-Shacham) signatures emerge as a compelling alternative. This method significantly simplifies multi-party computation, offering:

• Non-interactive signing: No synchronization required among Signers.

• Higher performance: Potentially exceeding 100 signatures per second.

• Straightforward failure attribution and signer management.

BLS signature scheme is a cryptographic signature scheme that allows anyone to verify the authenticity of a signer, like the common digital signature scheme such as ECDSA (Bitcoin, Ethereum, and numerous other blockchains). BLS has a few appealing benefits such as simplicity, powerful and flexible signature aggregation, to name just a few, but for ZetaChain’s use cases, the most important property is that BLS signatures admit very simple and robust multiparty computation (MPC) threshold signature scheme.

The BLS signature scheme depends on pairing on elliptic curves such as BN254 (also called, confusingly, bn_alt128, BN128, and BN256!), or more recent BLS12–381. Those pairings and curves are the bedrock for the most deployed zero-knowledge proof (ZKP) systems such as Groth16 which prompts many blockchains to add or improve efficiency in supporting those primitives. The support is wide enough and efficient enough nowadays (see for example upcoming Ethereum Pectra upgrade which includes BLS12–381 precompile support EIP) that ZetaChain can utilize a single TSS technology that are supported almost everywhere efficiently.

In the next few months, ZetaChain will develop, validate, and gradually deploy threshold BLS (tBLS) on external chains one by one. The technology is maturing (Filecoin relies on threshold BLS for verifiable random function for picking block proposers, drand relies on the same threshold BLS as verifiable random function which involves thousands of dynamic sets of nodes/signers), but its application as blockchain digital signature appears not to be widespread. ZetaChain would be pioneering this prospect in the context of cross-chain interoperability to reap orders of magnitudes of speedup and scaling of cross-chain transaction throughput.

Key Generation and Signing Process

Key Generation (DKG)

• One-round, asynchronous process.

• Utilizes distributed Verified Secret Sharing (VSS).

• Communication facilitated by ZetaChain’s state machine as a reliable broadcast channel.

Signature Generation (KeySign)

• Signers independently produce partial signatures and broadcast them.

• Any signer can reconstruct the complete signature from threshold shares without requiring synchronization.

Resharing

When changing the Signers’ composition, resharing maintains the collective secret key, preserving the public key and external account addresses, reducing migration risks.

Curve and Compatibility Considerations

Two prominent curves for BLS:

• BN254 (alt_bn128): Widely supported, particularly efficient on EVM chains and Solana.

• BLS12–381: Higher security (128-bit) and native support on Ethereum (upcoming Pectra upgrade), SUI, and TON.

Hash-to-Curve Methods

• BN254: Keccak256-based hashing with retry mechanism to find suitable curve points. The original hash to point/curve from the paper.

• BLS12–381: RFC 9380 standard hash-to-curve with native and precompiled support.

Signature Scheme Selection

• Signature on G1, Public Key on G2: Preferred due to smaller signature size, beneficial for storage and verification efficiency.

Implementation on Supported Chains

Ethereum and EVM Chains

• BLS signature verification via precompiles.

• Contract-based nonce management necessary to prevent replay attacks.

Solana and SUI

• Gateway contracts updated to handle BLS signature verification.

• Straightforward transition due to existing nonce management.

TON

• Native support for BLS12–381 simplifies verification significantly.

Performance and Cost Comparisons

Metric Threshold ECDSA (GG20) Threshold BLS Throughput <1 sig/s >100 sig/s Signer Synchronization Required Not required Complexity High Low Gas cost (EVM) 3,000 ~113,000 Compatibility Native EOA widely supported Contract-based

Threshold BLS vs. Gnosis Safe Multisig

Threshold BLS relies on cryptographic simplicity off-chain, whereas Gnosis Safe implements threshold logic directly in contracts:

Aspect Gnosis Safe Threshold BLS Verification Gas Cost Increases linearly Constant Key Sign Interaction Non-interactive Non-interactive Set Change Complexity High (multiple txs) Low (single resharing) On-chain Footprint Large Minimal

Strategic Recommendations

• Ethereum & Bitcoin: Maintain Threshold ECDSA for cost and native compatibility.

• EVM Chains (fast/cheap): Shift towards Threshold BLS.

• Solana & SUI: Adopt Threshold BLS due to efficient native support.

• TON: Utilize native BLS verification to leverage performance.

Impact and Benefits

Adopting Threshold BLS can:

• Significantly increase transaction throughput and reduce latency.

• Enhance reliability by eliminating complex signer synchronization.

• Simplify and robustify signer set migration.

Looking Forward

Threshold BLS signatures represent a leap forward for decentralized blockchain interoperability. By strategically adopting Threshold BLS, ZetaChain can achieve greater scalability, lower latency, and improved resilience in managing cross-chain asset control.

Developments and Integration in ZetaChain

The tBLS feature has been specified in a more technical and detailed ZetaChain improvement proposal (ZIP):

As of date, the internal modular proof of concept and validation are finished, while we are doing proof of concept integration in the ZetaChain node software https://github.com/zeta-chain/node.

To track progress:

• Threshold BLS Cryptography library: https://github.com/zeta-chain/kyber/tree/dkg-dual-curve

• Solidity library for verifying BN254 tBLS signature: https://github.com/brewmaster012/bls-solidity

• PoC contract BLS signature verification on SUI, Solana, TON

Our cryptographic library is based on the kyber library, expanding its support to both BN254 and BLS12–381 curves, and rework and simplify the workflow of distributed threshold BLS operations. We chose kyber library for its language compatibility with Go, flexibility to integrate both elliptic curves and specific workflows in ZetaChain KeyGen and KeySign.

References

1. https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signature-05.html IRTF RFC on BLS Signature

2. Short Signatures from Weil Pairings, Dan Boneh, Ben Lynn & Hovav Shacham, Journal of Crypotology, 2004

3. Blog post:https://www.jcraige.com/threshold-bls-signatures

4. MPTS 2023: NIST Workshop on Multi-Party Threshold Schemes 2023

5. Cryptography library with reference implementation of threshod BLS: https://github.com/dedis/kyber

6. Drand: Internet Protocol for Randomness. https://github.com/drand/drand

7. Blog post: BLS Signatures in Solidity. https://hackmd.io/@liangcc/bls-solidity

Categories