# Wormhole Advanced Guardian Set Management with Schnorr Signature Aggregation

## 1. Objective & Executive Summary

This proposal presents a novel two-phase approach to Wormhole's signature scheme, clearly separating guardian set management from the actual signing process. By decoupling these concerns, we achieve greater security, flexibility, and efficiency in cross-chain message verification.

The first phase employs an innovative ZKP-based consensus mechanism for guardian set selection and updates, using a deterministic key sharing scheme that ensures threshold security. The second phase leverages Schnorr signature aggregation for efficient message signing, dramatically reducing gas costs and latency.

This approach significantly improves upon the current GG18-based implementation by simplifying the overall architecture, enhancing security guarantees, and optimizing resource usage throughout the Wormhole ecosystem.

## 2. Method Overview: Two-Phase Architecture

Our method clearly separates concerns into two distinct phases:

1. **Guardian Set Selection Phase**: Manages the validator set membership with a novel ZKP-based consensus mechanism and deterministic key distribution scheme
2. **Signing Phase**: Uses Schnorr signature aggregation for efficient message signing, dramatically reducing gas costs and latency

This separation provides several advantages:
- Simplified reasoning about security properties
- Reduced complexity in the critical signing path
- Independent optimization of each phase
- Clearer upgrade paths for future improvements

## 3. Phase 1: Guardian Set Selection with ZKP Consensus

### Threshold Security Design

In a network of n guardians where at least k must be honest (k-of-n threshold security):

- Each guardian must hold multiple private keys
- Keys are distributed such that any subset of k-1 guardians cannot sign messages
- To achieve this property, we need at least $\binom{n}{k-1}$ distinct private keys in the system
- Each guardian holds $\binom{n}{k-1} / n$ private keys

### Key Distribution Protocol

The key distribution protocol operates as follows:

1. **Initial Public Key Commitment**
- Each guardian generates $\binom{n}{k-1} / n$ key pairs
- Guardians construct a Merkle tree with their public keys as leaves and commit the Merkle root on-chain
- Guardians provide ZK-proofs validating the Merkle root using the private keys of these public keys, ensuring they possess all private keys
- These commitments and proofs are recorded on-chain for verification

2. **Deterministic Group Assignment**
- Public keys are deterministically sorted
- For each combination of n-(k-1) guardians, a group is formed
- Each group is responsible for generating and maintaining a shared private key

3. **Secure Key Sharing Session**
- Within each group, guardians establish secure channels using Diffie-Hellman key exchange
- Guardians use their published public keys for authentication
- The group collectively generates a shared private key using a deterministic consensus rule (e.g., selecting the largest value)
- Each node in the group uses the public key that connected them to that group to provide an off-chain proof of the public key derived from the shared secret key (shared_secret * G)
- This ensures all participants know and can verify the public key corresponding to the shared secret without revealing the secret itself
- In addition to the shared secret key, each group also selects a dedicated nonce generator secret \(r)
- Guardians commit to this nonce generator by providing off-chain proofs of the public key derived from it (r * G)
- This nonce generator will be combined with an incremental counter (total signed messages of Wormhole) to deterministically generate nonces during the signing phase
- All participants commit to both the shared secret key and nonce generator using zero-knowledge proofs
- Commitments to the derived public keys are stored for later use in challenge computations during signature aggregation

4. **ZKP Validation**
- Zero-knowledge proofs verify that:
- Guardians possess their claimed private keys
- The key generation process followed the protocol
- Shared keys are properly constructed
- These proofs enable verification without revealing sensitive information

5. **Selective Disclosure**
- When needed, guardians can prove ownership of specific public keys by providing:
- The public key
- The Merkle proof (authentication path to the committed root)
- A ZK-proof of private key possession
- This enables efficient verification with logarithmic complexity without compromising security

### Final Aggregation Commitment

After all key sharing sessions are completed, guardians perform a final commitment step to establish the aggregated signature parameter:

1. **Parameter Aggregation**
- Each guardian calculates the sum of all shared secret keys: $S = S_1 + S_2 + ... + S_\binom{n}{k-1}$
- This aggregated value S will be used as the Schnorr signature aggregation parameter

2. **On-Chain Commitment**
- Each guardian commits to this aggregated value S by signing it with their main private key
- These commitments are published on-chain as the final step in the guardian set selection phase
- The collective agreement on S serves as cryptographic proof that the guardian set is properly established

3. **Validation Completion**
- Once all guardians have submitted their on-chain commitments to the aggregated S parameter
- The system verifies that all commitments match, confirming consensus on the aggregated parameter
- When validation is complete, the guardian set is fully operational and ready for the signing phase

This final commitment step ensures that all guardians agree on the collective signature parameter, establishing the foundation for the subsequent Schnorr signature aggregation process.

### Guardian Set Updates

When the guardian set needs to be updated (adding/removing guardians):

1. **Proposal & Consensus**
- Changes to the guardian set are proposed and approved through a consensus mechanism
- Current guardians vote on proposed changes

2. **Key Redistribution**
- New key assignments are deterministically calculated based on the updated guardian set
- New guardians generate and commit to their key pairs
- Existing shared keys are redistributed as needed

3. **Validation Period**
- A transition period allows verification that the new guardian set is properly established
- Both old and new guardian sets can produce valid signatures during this period
- Once validated, the new guardian set becomes authoritative

### Security Properties

This guardian set selection mechanism provides several critical security properties:

1. **Threshold Security**: The system remains secure as long as at least k guardians are honest
2. **Forward Security**: Compromise of the current guardian set doesn't compromise future sets
3. **Provable Correctness**: ZKPs ensure that the protocol is followed correctly
4. **Transparent Transitions**: Guardian set updates are verifiable and auditable

## 4. Mathematical Introduction to Schnorr Signature Aggregation

Before delving into the implementation details of our second phase, it's important to understand the mathematical foundations of Schnorr signatures and their aggregation properties, which make them an ideal choice for Wormhole's cross-chain messaging infrastructure.

### Elliptic Curve Cryptography Fundamentals

Schnorr signatures operate on an elliptic curve group with the following properties:
- Let $G$ be a generator point of the elliptic curve group with prime order $n$
- For any scalar $x \in \mathbb{Z}_n$, the point $P = x \cdot G$ is another point on the curve
- The discrete logarithm problem (finding $x$ given $P = x \cdot G$) is computationally infeasible
- The group operation (point addition) is efficient to compute

### Standard Schnorr Signature Scheme

For a single signer with private key $x$ and corresponding public key $P = x \cdot G$:

1. **Key Generation**:
- Select random private key $x \in \mathbb{Z}_n$
- Compute public key $P = x \cdot G$

2. **Signature Generation** for message $m$:
- Select a random nonce $k \in \mathbb{Z}_n$
- Compute commitment $R = k \cdot G$
- Compute challenge $e = H(R \| P \| m)$ where $H$ is a cryptographic hash function
- Compute response $s = k + e \cdot x \mod n$
- The signature is the pair $(R, s)$

3. **Signature Verification**:
- Compute challenge $e = H(R \| P \| m)$
- Verify that $s \cdot G = R + e \cdot P$

The verification works because:
$s \cdot G = (k + e \cdot x) \cdot G = k \cdot G + e \cdot x \cdot G = R + e \cdot P$

### Multi-Signature Aggregation

The key property that makes Schnorr signatures perfect for our use case is their linearity, which enables efficient aggregation:

#### Naive Aggregation (Vulnerable to Rogue-Key Attacks)

For signers with private keys $x_1, x_2, ..., x_t$ and public keys $P_1, P_2, ..., P_t$:

1. Each signer independently selects nonce $k_i$ and computes $R_i = k_i \cdot G$
2. All signers share their $R_i$ values
3. Compute $R = R_1 + R_2 + ... + R_t$
4. Each signer computes challenge $e = H(R \| P_1 + P_2 + ... + P_t \| m)$
5. Each signer computes their signature share $s_i = k_i + e \cdot x_i \mod n$
6. Compute aggregated signature $(R, s)$ where $s = s_1 + s_2 + ... + s_t \mod n$

#### Secure Aggregation with Distinct Messages

To prevent rogue-key attacks, several approaches exist. For our system where all signers sign the same message, we use a secure aggregation scheme:

1. **Key and Nonce Commitment**:
- Signers commit to their public keys and prove knowledge of the private key
- Nonces are generated deterministically or through a secure multi-party computation

2. **Challenge Calculation**:
- $e = H(R_1 \| R_2 \| ... \| R_t \| P_1 \| P_2 \| ... \| P_t \| m)$
- This binding prevents key cancellation attacks

3. **Signature Aggregation**:
- $R = R_1 + R_2 + ... + R_t$
- $s = s_1 + s_2 + ... + s_t \mod n$

4. **Verification**:
- Compute $P_{agg} = P_1 + P_2 + ... + P_t$
- Verify $s \cdot G = R + e \cdot P_{agg}$

### Mathematical Properties of Aggregation

The security and efficiency of Schnorr signature aggregation stem from several key mathematical properties:

1. **Linearity**: If $(R_i, s_i)$ is a valid signature with public key $P_i$, then the sum of signatures is valid for the sum of public keys:
- For signatures $(R_1, s_1), (R_2, s_2), ..., (R_t, s_t)$ with corresponding public keys $P_1, P_2, ..., P_t$
- The aggregate signature $(R, s) = (R_1 + R_2 + ... + R_t, s_1 + s_2 + ... + s_t)$ is valid under the aggregate public key $P_{agg} = P_1 + P_2 + ... + P_t$

2. **Batch Verification**: Multiple signatures can be verified simultaneously in a batch, reducing computational overhead:
- Instead of verifying each signature individually, which requires multiple scalar multiplications
- Batch verification combines the equations and requires fewer total operations

3. **Constant Size**: Regardless of the number of signers, the aggregated signature remains a fixed size (one curve point $R$ and one scalar $s$)

4. **Provable Security**: Schnorr signatures provide security under the random oracle model, assuming the hardness of the discrete logarithm problem

These mathematical properties directly translate to practical benefits for Wormhole's cross-chain messaging, including reduced gas costs, lower bandwidth requirements, and simpler verification logic.

## 5. Phase 2: Schnorr Signature Aggregation

Once the guardian set is established, the actual signing process uses Schnorr signature aggregation for efficiency.

### Schnorr Signature Fundamentals

Schnorr signatures provide powerful aggregation properties that make them ideal for this application:

1. **Linearity**: Multiple signatures can be combined into a single signature
2. **Efficiency**: Verification is computationally inexpensive compared to ECDSA
3. **Simplicity**: The mathematical foundation is clean and well-understood
4. **Provable Security**: Strong security guarantees under the random oracle model

### Signature Generation Process

1. **Message Reception**
- A message requiring validation is received by guardians
- The message digest is computed deterministically

2. **Individual Signing**
- Each guardian retrieves the group's shared nonce generator (r) established during the key distribution phase
- The nonce for the current signature is deterministically derived by combining:
- The group's nonce generator (r)
- A global incremental counter representing the total number of messages signed by Wormhole so far
- These are fed as seed into a deterministic random number generator to produce the actual nonce (k)
- The deterministic nature of this nonce generation prevents reuse while ensuring coordination without communication
- Each guardian can verify the correct derivation using the previously committed public nonce generator
- Guardians then sign the message using their Schnorr private keys and the derived nonce
- No complex multi-round protocol is needed (unlike GG18)
- Signatures are generated independently with guaranteed nonce consistency

3. **Signature Aggregation**
- Individual signatures are collected and aggregated into a single signature
- Aggregation is a simple mathematical operation (addition in the appropriate group)
- The resulting signature is compact and efficient to verify

4. **Publication & Verification**
- The aggregated signature is published along with the message
- Verifiers check the signature against the guardian set's aggregate public key
- Verification costs are dramatically lower than with multiple signature checks

### Key Benefits

This streamlined signing phase offers significant advantages:

1. **Reduced Gas Costs**: Single signature verification instead of multiple checks
2. **Lower Latency**: No multi-round communication protocol needed
3. **Simplified Implementation**: Less complex code means fewer potential bugs
4. **Higher Throughput**: Independent signing enables better parallelization

## 6. Technical Implementation
### ZKP-Based Guardian Consensus

The ZKP system for guardian set consensus provides several critical guarantees:

1. **Proof of Key Possession**: Guardians prove they hold the private keys corresponding to their public keys
2. **Proof of Protocol Compliance**: Guardians prove they've followed the key generation protocol
3. **Proof of Set Validity**: The collective guardian set proves it meets the threshold security requirements
4. **Merkle Root Correctness**: Guardians prove their Merkle root accurately represents their public key set

The ZKP implementation uses modern, efficient proof systems:

// Example pseudocode for guardian ZKP generation
function GenerateGuardianKeyProof(privateKeys, publicKeys, guardianIndex):
    // Construct circuit proving knowledge of private keys
    for i in range(len(privateKeys)):
        assert publicKeys[i] == G * privateKeys[i]
    
    // Prove adherence to key distribution protocol
    assert CountOwnedKeys(guardianIndex) == BinomialCoeff(n, k-1) / n
    
    // Generate and return the proof
    return GenerateZKProof(circuit, privateKeys, publicKeys)

### Merkle Root ZK-Proof Implementation

The Merkle root commitment system is implemented with the following components:

// Pseudocode for Merkle root generation and ZK-proof
function GenerateMerkleRootWithProof(privateKeys):
    // Generate public keys
    publicKeys = []
    for privKey in privateKeys:
        publicKeys.append(G * privKey)
    
    // Construct Merkle tree
    merkleTree = MerkleTree(publicKeys)
    merkleRoot = merkleTree.getRoot()
    
    // Generate ZK circuit
    circuit = createCircuit()
    
    // Add constraints proving possession of all private keys
    for i in range(len(privateKeys)):
        circuit.addConstraint(publicKeys[i] == G * privateKeys[i])
    
    // Add constraints proving correct Merkle tree construction
    for level in merkleTree.levels:
        for nodeIdx in range(len(level) - 1):
            circuit.addConstraint(
                level[nodeIdx//2] == Hash(level[nodeIdx], level[nodeIdx+1])
            )
    
    // Add constraint proving the final root
    circuit.addConstraint(merkleRoot == merkleTree.getRoot())
    
    // Generate the proof
    zkProof = GenerateZKProof(circuit, {
        'privateKeys': privateKeys,
        'publicKeys': publicKeys,
        'merkleTree': merkleTree
    })
    
    return {
        'merkleRoot': merkleRoot,
        'zkProof': zkProof
    }

For selective disclosure and verification:

// Pseudocode for selective disclosure verification
function VerifyKeyInMerkleTree(publicKey, merkleProof, guardianMerkleRoot, zkProof):
    // Verify the Merkle path
    isValidPath = VerifyMerklePath(publicKey, merkleProof, guardianMerkleRoot)
    
    // Verify the ZK-proof that prover knows the private key
    isValidProof = VerifyZKProof(zkProof, {
        'publicKey': publicKey,
        'merkleRoot': guardianMerkleRoot
    })
    
    return isValidPath && isValidProof

### Final Aggregation Commitment Implementation

The final aggregation commitment process is implemented as follows:

// Pseudocode for aggregation parameter commitment
function GenerateAggregationCommitment(sharedSecrets, mainPrivateKey):
    // Calculate the sum of all shared secrets
    aggregatedParameter = 0
    for secret in sharedSecrets:
        aggregatedParameter += secret
    
    // Generate a commitment to this parameter
    commitmentMessage = "GUARDIAN_SET_AGGREGATION_" + HashToString(aggregatedParameter)
    signature = SignWithECDSA(commitmentMessage, mainPrivateKey)
    
    // Return the commitment for on-chain publication
    return {
        'guardian': GetGuardianAddress(mainPrivateKey),
        'aggregatedParameterHash': Hash(aggregatedParameter),
        'signature': signature
    }

The system validates these commitments to ensure consensus:

// Pseudocode for validating guardian set commitments
function ValidateAggregationCommitments(commitments):
    // Ensure all guardians have submitted commitments
    if len(commitments) < requiredGuardians:
        return False
    
    // Verify all guardians agree on the aggregated parameter
    expectedHash = commitments[0].aggregatedParameterHash
    for commitment in commitments:
        // Verify signature validity
        if !VerifySignature(commitment.signature, commitment.guardian):
            return False
        
        // Verify parameter hash matches across all guardians
        if commitment.aggregatedParameterHash != expectedHash:
            return False
    
    // All commitments are valid and consistent
    return True

Once validated, the guardian set is ready for signature operations.

### Schnorr Signature Implementation

The Schnorr signature aggregation is implemented efficiently using standard cryptographic libraries:

// Pseudocode for Schnorr signature aggregation
function AggregateSignatures(signatures, publicKeys, message):
    // Initialize aggregate signature components
    R_aggregate = Point.Identity
    s_aggregate = 0
    
    // Add all signature components
    for (R_i, s_i) in signatures:
        R_aggregate += R_i
        s_aggregate += s_i
    
    // Final signature is (R_aggregate, s_aggregate)
    return (R_aggregate, s_aggregate)

Verification is similarly streamlined:

// Pseudocode for aggregated signature verification
function VerifyAggregatedSignature(message, signature, aggregatePublicKey):
    // Parse signature components
    (R, s) = signature
    
    // Compute challenge
    c = Hash(R || aggregatePublicKey || message)
    
    // Verify signature equation
    return s*G == R + c*aggregatePublicKey

## 7. Advantages Over Current Method

Our two-phase approach addresses critical limitations in the GG18-based ECDSA implementation currently used in Wormhole:

### Availability Improvements

| Aspect | GG18 ECDSA | Our Two-Phase Approach | Improvement |
|--------|------------|------------------------|-------------|
| Communication Dependencies | Requires all participants through 9 communication rounds | Single-round signature aggregation | Dramatically reduced coordination requirements |
| Disruption Vulnerability | Vulnerable to non-participation, network latency, or malicious node behaviors | Independent signing operations with minimal interdependencies | Significantly improved resilience to network issues |
| Failure Recovery | Complete protocol restart needed if any phase fails | Isolated phase failures with clear recovery paths | Higher overall system availability |

### Dual-Path Reliability

The current GG18 implementation requires maintaining the traditional multi-signature method as a fallback due to its availability limitations. Our approach significantly reduces this dependency through:

1. **Improved First-Time Success Rate**: By eliminating multi-round protocols, our approach dramatically increases the likelihood of successful signature generation on the first attempt

2. **Reduced Coordination Requirements**: Participants can generate their signature shares independently, removing tight synchronization dependencies

3. **Clearer Failure Attribution**: When failures occur, the source can be more easily identified due to the separated phases and simpler protocol

4. **Simplified State Management**: With fewer interactive rounds, the protocol state remains simpler and more predictable

## 8. Conclusion

The proposed two-phase approach with ZKP-based guardian set consensus and Schnorr signature aggregation represents a significant advancement for Wormhole's cross-chain messaging infrastructure. By clearly separating concerns and leveraging the strengths of each component, we create a system that is more secure, efficient, and maintainable than the current implementation.

The deterministic key distribution scheme ensures threshold security with mathematical guarantees, while the simplified signature aggregation process dramatically reduces costs and latency for users. Together, these improvements position Wormhole to scale its operations while maintaining the highest security standards.