Technical Whitepaper
Technical details of the Libre CrossLink bridge implementation using MPC-TSS
Architecture Overview
The Libre CrossLink bridge is built on a layered architecture that integrates with both the Bitcoin and Libre blockchains through a network of decentralized nodes. The system consists of three main components:
Smart Contract Layer: The Libre smart contract maintains the canonical state of all bridge operations, eliminating inconsistencies that could arise from distributed state management.
Node Network: A distributed network of bridge nodes that collectively manage the bridge operations through MPC.
MPC Protocol Layer: Implements threshold signature schemes to collectively generate and manage cryptographic keys.
This architecture offers several key advantages:
Single Source of Truth: The Libre smart contract maintains the canonical state of all bridge operations, eliminating inconsistencies that could arise from distributed state management.
Decentralized Control: No single entity has control over user funds or bridge operations.
Enhanced Security: MPC-TSS provides institutional-grade security without institutional intermediaries.
Transparency: All operations are recorded on-chain and can be audited.
MPC-TSS Implementation
The CrossLink bridge uses threshold signature schemes for collectively managing cryptographic keys. For a system with $n$ participants, a $(t,n)$-threshold signature scheme allows any subset of at least $t$ participants to collaboratively compute a valid signature, while ensuring that:
No participant learns the complete private key $d$
Any subset of at least $t$ participants can collaboratively compute a valid signature
Any subset of fewer than $t$ participants cannot derive the private key or generate valid signatures
The security of this approach is established in threshold cryptography, where the probability of an adversary $\mathcal{A}$ recovering the private key $d$ with fewer than $t$ shares is negligible:
Where $\epsilon$ is a negligibly small value and ${d_1, d_2, ..., d_{t-1}}$ represents the compromised key shares.
Key Generation Protocol
The key generation protocol (Keygen) allows participants to jointly generate a public/private key pair without any single party having access to the complete private key. The protocol consists of three main stages:
Initialization: Each party generates their own random secret and commits to it.
Secret Sharing: Parties exchange encrypted shares of their secrets using Verifiable Secret Sharing (VSS).
Key Derivation: Parties collectively compute the public key and their respective shares of the private key.
Signing Protocol
For ECDSA signatures, the system uses a more complex MPC protocol to calculate:
r = g^k \mod p$$$$s = k^{-1}(z + rd) \mod q
Where:
$g$ is the generator point
$k$ is a random nonce
$z$ is the message hash
$d$ is the private key
$p$ and $q$ are prime numbers specific to the ECDSA parameters
Transaction Flows
Peg-in (BTC to Libre)
User initiates a peg-in by sending BTC to a bridge address on the Bitcoin blockchain.
Bridge nodes detect the transaction and verify its validity.
Once the transaction receives sufficient confirmations, nodes sign a transaction to mint equivalent tokens on Libre.
The transaction $T_{BTC}(deposit)$ on Bitcoin with amount $A$ results in a transaction $T_{Libre}(mint)$ on Libre:
Where $fee$ is calculated based on the current fee rate:
Peg-out (Libre to BTC)
User initiates a peg-out by sending LBTC tokens to the bridge contract on Libre with the destination Bitcoin address in the memo field.
Bridge contract locks the tokens and creates a pending peg-out record.
Nodes detect the peg-out request and initiate the signing process.
Once sufficient nodes have participated in the signing, the signed Bitcoin transaction is broadcast to the Bitcoin network.
After sufficient confirmations, the peg-out is marked as complete on the Libre contract.
Security Considerations
Threat Model
The security design of Libre CrossLink considers several threat vectors:
Node Compromise: The system remains secure as long as fewer than $t$ nodes are compromised.
Network Partitioning: The bridge can withstand temporary network partitioning.
Blockchain Reorganizations: The bridge handles potential chain reorganizations on both networks.
Front-running Attacks: Transaction ordering is protected through the Libre contract.
Denial of Service: The bridge implements rate limiting and other protections.
Protection Mechanisms
Threshold Security: Requires $t$ out of $n$ nodes to cooperate for any action.
Validation Checks: Multiple validation steps for transactions on both blockchains.
Confirmation Requirements: Enforces minimum confirmation requirements for Bitcoin transactions.
Rate Limiting: Prevents excessive transaction volume that could strain the system.
Transaction Batching: Optimizes cost efficiency by batching multiple transactions.
Segregated Key Management: Maintains separate key shares for each user vault, ensuring that compromise of one vault doesn't affect others.
The probability that a transaction is irreversible after $k$ confirmations on the Bitcoin blockchain can be approximated by:
Where:
$q$ is the attacker's hash power
$p$ is the honest network's hash power
$p + q = 1$ (total network hash power)
For a security parameter $\sigma$ and an attacker controlling fraction $q$ of the hash power, the required confirmations $k$ to achieve security is:
Advanced Security Properties
The CrossLink bridge implements several advanced security measures:
Proactive Security: Periodic key resharing to mitigate the risk of gradual key share leakage
Verifiable Computation: All nodes can verify the correctness of partial signatures
Accountability: All actions are recorded on-chain, providing accountability
Asynchronous Operation: The system can progress even when some nodes are temporarily unavailable
These measures ensure that the bridge maintains its security properties even in adversarial conditions.
Last updated
Was this helpful?