Transaction Signing Deep Dive

io.vault uses threshold signing to sign transactions. Let's dive into the process of signing a transaction in io.vault and broadcasting it to the blockchain, and cover some of the more technical details. With that said, our core cryptography code is open source and has been audited by several well-known independent security firms.

Signing with Threshold Signatures

io.vault achieves its high level of security for managing digital assets through the careful implementation of threshold signature schemes. These schemes eliminate single points of failure by distributing the ownership and control of private keys. Here's what happens when a user of io.vault uses their key share to sign a transaction:

Transaction Request: A user initiates a transaction from the io.vault web dashboard or API, specifying the necessary details (asset, amount, recipient, etc.).
Signer Notification: io.vault securely notifies the designated signers for the vault about the pending transaction request. Each human signer receives the request on their registered device. Automated signers (Virtual Signers) evaluate the transaction against their configured policies via API or Smart Contracts.
Distributed Signature Generation (MPC): Once a quorum of signers approves, they engage in a secure multi-party computation (MPC) protocol specific to the required signature scheme (ECDSA, EdDSA, or others). Critically, no signer ever possesses or reveals their complete private key share during this process.
- For Threshold ECDSA:
  - Signers engage in an interactive protocol known as CGGMP.
  - They collectively generate shares of a secret nonce (k) without reconstructing the nonce itself.
  - Using advanced cryptographic techniques, they securely compute the signature's r value (derived from k*G, where G is the curve's base point) and individual signature shares (s_i). This distributed calculation ensures that the signature s can be computed without any party learning k or the private key x.
- For Threshold EdDSA, also known as Threshold Schnorr:
  - Signers engage in an interactive protocol for a threshold Schnorr structure.
  - Unlike standard EdDSA's deterministic nonce, this protocol uses a randomized approach compatible with EdDSA verification. Signers collectively generate a shared random nonce r and the corresponding curve point R. Each signer contributes randomness (r_i) such that r = Σ r_i.
  - They compute the hash challenge e = H(R, A, M) (where A is the public key, M is the message).
  - Each signer then computes their signature share s_i.
Signature Aggregation: Once the required threshold (t+1) of signers has successfully computed their shares, io.vault's app securely aggregates these shares to produce the final signature.
- For Threshold ECDSA:
  - The final signature (r, s) is reconstructed. The r value was determined collectively during the generation phase.
  - The final s value is typically calculated by combining the individual shares: s = Σ s_i mod q. The resulting (r, s) pair is a standard ECDSA signature, verifiable by anyone on the blockchain.
- For Threshold EdDSA:
  - The final signature (R, S) is formed. The R point was computed collectively during generation.
  - The final S component is reconstructed by summing the individual shares: S = Σ s_i mod q. The resulting (R, S) pair is a standard EdDSA signature, verifiable on-chain.
Transaction Broadcast: Participating signers assemble the valid, aggregated signature with the original transaction data and broadcast it to the blockchain node network.
Blockchain Confirmation: Nodes on the blockchain network independently verify the transaction's signature using the standard ECDSA or EdDSA verification algorithm and the vault's public key. If valid, the transaction is included in a block, mined, and eventually confirmed.

Cryptography Techniques

Making such sophisticated protocols work requires several core cryptographic techniques, also known as primitives. The following list details these fundamental tools – from secret sharing methods to zero-knowledge proofs and elliptic curve mathematics – which io.vault combines to construct its secure and resilient signing algorithms.

Primitives for Threshold EdDSA/Schnorr

Shamir Secret Sharing (SSS): Divides a secret (like a key or nonce share) into multiple pieces for distribution.
Lagrange Interpolation: Reconstructs the original secret from a sufficient number of shared pieces.
Feldman Verifiable Secret Sharing (VSS): Allows participants to verify the consistency of their secret shares during distribution using public commitments.
Schnorr Signature Algorithm (Core Logic): Provides the fundamental mathematical structure for generating and verifying the signatures.
Schnorr Zero-Knowledge Proof of Knowledge of Discrete Logarithm: Enables participants to prove they know their secret shares without revealing them.
Hash Functions (e.g., SHA-256, SHA-512): Creates unique fingerprints of data for commitments, signature challenges, and proofs.
Hash-Based Commitment Schemes: Allows participants to commit to a value publicly while keeping it hidden until a later reveal phase.
Elliptic Curve Group Operations: Performs the core mathematical operations (point addition, scalar multiplication) on the chosen curve.
Modular Arithmetic: Defines the rules for calculations involving integers within a specific range (modulo the group order q).

Primitives for Threshold ECDSA (e.g., CGGMP family of protocols)

Shamir Secret Sharing (SSS) / Pedersen Verifiable Secret Sharing (VSS): Divides the private key into multiple verifiable pieces for distribution among participants.
Paillier Homomorphic Encryption (Additively Homomorphic Encryption): Allows computation on encrypted secret shares (like adding them) without decrypting them first.
Zero-Knowledge Proofs: Enables participants to prove they are following the protocol rules correctly without revealing their secret inputs.
Elliptic Curve Group Operations: Performs the core mathematical operations (point addition, scalar multiplication) on the secp256k1 curve.
Modular Arithmetic: Defines the rules for calculations involving integers within a specific range (modulo the group order n).
Hash Functions (e.g., SHA-256): Creates a unique fingerprint of the message to be signed as part of the ECDSA formula.
Lagrange Interpolation: Used implicitly or explicitly to reconstruct values (like the final signature component) from shares.

How Signatures Are Verified

When a system (like a blockchain node) receives a digitally signed message or transaction, it needs to confirm that the signature is authentic and actually came from the owner of the claimed public key. This verification uses the public key, the message itself, and the signature. The exact steps differ slightly between common methods like ECDSA and EdDSA.

Verification using ECDSA (Common in Bitcoin, Ethereum, and EVM forks)

First, the system checks if the two numbers that make up the ECDSA signature (r and s) look valid (e.g., they are within an expected range).
It calculates a unique digital fingerprint (hash) of the message.
Using the signature numbers (r, s) and the message's fingerprint, the system performs some specific mathematical steps. Think of this like using parts of the signature as instructions.
These calculations involve combining the results with both a standard starting point on the elliptic curve (known as the base point G) and the sender's public key. This produces a final point on the curve.
The system takes a specific part of this calculated final point (its x-coordinate) and compares it to the r value from the original signature. If they match perfectly, the signature is valid!

Verification using EdDSA (Common in newer systems like Solana, Polkadot, Cardano)

Similar to ECDSA, the system first checks if the two parts of the EdDSA signature (R and S) and the public key look like valid components for the system.
It takes one part of the signature (R), the sender's public key, and the original message, bundles them together, and calculates a digital fingerprint (hash) of this bundle.
EdDSA verification boils down to checking if a specific mathematical equation balances correctly. This equation involves:
- The second part of the signature (S).
- A standard starting point on the curve (B).
- The first part of the signature (R).
- The fingerprint calculated in the previous step (h).
- The sender's public key (A).
- Essentially, it checks if (S * B) equals (R + h * A) using the special math of elliptic curves.
If the two sides of the equation are equal, the signature is valid.

Why Does This Matter?

If the signature passes these checks, the system knows that the message was indeed signed by someone who possesses the corresponding private key, without ever seeing the private key itself. This confirms the message's authenticity and integrity, allowing a blockchain node, for example, to confidently accept the transaction.

Security Considerations in Threshold Signing

Distributed Key Generation: Key shares are generated in a secure ceremony where no single party ever knows the complete private key.
Communication Security: All communications between signers are encrypted and authenticated to prevent attacks.
Nonce Management: Proper nonce generation is critical to security, especially for ECDSA where reusing or predicting nonces could leak the private key.
Fault Tolerance: The threshold scheme ensures that the system can continue to operate even if some signers are unavailable, up to the predetermined threshold.

By leveraging threshold ECDSA and EdDSA schemes, io.vault ensures that transactions maintain the security properties of these signature algorithms while adding the benefits of distributed trust and fault tolerance. The resulting signature is indistinguishable from a signature generated with a single private key, maintaining compatibility with existing blockchain verification mechanisms while eliminating single points of failure.