PaperlayerView exact revision on arXiv

Source-linked AI summary

Teechain: A Secure Payment Network with Asynchronous Blockchain Access

Joshua Lind, Oded Naor, Ittay Eyal, Florian Kelbert, Peter Pietzuch, Emin Gun Sirer

arXiv:1707.05454v4cs.CR

TL;DR

Existing payment networks improve blockchain performance through off-chain channels but require bounded blockchain access to detect misbehavior, exposing funds to delay attacks and preventing use during disconnection. Teechain uses TEE-protected treasuries, dynamic deposits, and replicated committee chains to provide asynchronous blockchain access. It achieves 33×–145× more payment transactions than Lightning and reports orders-of-magnitude performance gains overall.

  • Problem

    Existing payment networks require bounded blockchain access to detect stale settlements, creating exposure to delayed reads or writes and limiting use when parties are disconnected.

  • Method

    Teechain uses TEE-protected treasuries for off-chain payment execution, supports dynamic deposit assignment, and replicates treasury state with committee chains.

  • Results

    33×–145× more payment transactions are handled than by Lightning, depending on committee-chain size.

  • Takeaways & Limitations

    Teechain provides asynchronous blockchain access while maintaining secure off-chain payments on existing blockchains.

  • Takeaways & Limitations

    Existing payment networks face practical limits because blockchain queues, censorship, ordering control, and network partitioning can violate synchronous access assumptions.

Abstract

from arXiv · show

Blockchains such as Bitcoin and Ethereum execute payment transactions securely, but their performance is limited by the need for global consensus. Payment networks overcome this limitation through off-chain transactions. Instead of writing to the blockchain for each transaction, they only settle the final payment balances with the underlying blockchain. When executing off-chain transactions in current payment networks, parties must access the blockchain within bounded time to detect misbehaving parties that deviate from the protocol. This opens a window for attacks in which a malicious party can steal funds by deliberately delaying other parties' blockchain access and prevents parties from using payment networks when disconnected from the blockchain. We present Teechain, the first layer-two payment network that executes off-chain transactions asynchronously with respect to the underlying blockchain. To prevent parties from misbehaving, Teechain uses treasuries, protected by hardware trusted execution environments (TEEs), to establish off-chain payment channels between parties. Treasuries maintain collateral funds and can exchange transactions efficiently and securely, without interacting with the underlying blockchain. To mitigate against treasury failures and to avoid having to trust all TEEs, Teechain replicates the state of treasuries using committee chains, a new variant of chain replication with threshold secret sharing. Teechain achieves at least a 33x higher transaction throughput than the state-of-the-art Lightning payment network. A 30-machine Teechain deployment can handle over 1 million Bitcoin transactions per second.

1 Introduction

Blockchains provide secure payments but global consensus limits throughput and latency, while existing payment networks require bounded blockchain access to prevent stale settlements. Teechain replaces that dependency with TEE-protected treasuries and replicated committee state, enabling asynchronous access, dynamic deposits, and substantially higher throughput.

  • Motivation: Global consensus limits blockchain throughput, processing speed, and the need to store transaction history.The paper describes global throughput as capped at a handful of transactions per second and processing as taking minutes to hours.
  • Motivation: Existing payment networks exchange transactions off-chain but require parties to monitor the blockchain and react within a bounded time Δ.This requirement detects stale settlements before they can steal funds.
  • Design: Teechain uses TEE-protected treasuries as an independent root of trust and replicates treasury state across committee chains.Committee approval is required for off-chain transactions or channel settlement, reducing dependence on individual TEEs.
  • Contributions: Teechain supports dynamic deposits by assigning deposits to channels through treasuries and moving them in or out at runtime without blockchain access.This enables new payment channels to be established within seconds.
  • Contributions: Teechain supports asynchronous settlement because treasuries atomically update duplicated balances and generate only one settlement transaction per channel.Settlement transactions may be written to the blockchain in unbounded time.
  • Results: 33×–145× more payment transactions are handled than by Lightning, depending on committee-chain size.Channel establishment takes seconds rather than minutes or hours, and blockchain storage is reduced by at least 25% compared with Lightning.

2 Secure Payment Networks for Blockchains

Blockchains provide secure, replicated ledgers but incur consensus-related throughput, latency, and storage costs. Payment networks improve performance through off-chain channels, yet stale-settlement defenses require synchronous blockchain access that is vulnerable to delay and disconnection.

  • Blockchain foundations: Blockchains maintain an append-only transaction history through replicated state machines and consensus.Bitcoin uses a UTXO model, while signatures validate transactions and prevent unauthorized spending.
  • Blockchain limitations: Consensus limits Bitcoin to 7 transactions per second, creates high storage costs, and can delay transaction inclusion arbitrarily.The paper describes the blockchain as hundreds of gigabytes in total size.
  • Payment networks: Payment networks exchange funds directly through point-to-point channels and record only final balances on the blockchain.This yields higher throughput, lower latency, and fewer stored blockchain transactions than on-chain payments.
  • Payment networks: Multi-hop payments concatenate channels to connect parties without direct payment channels.This supports payments between parties lacking long-lived financial relationships.
  • Security limitations: A stale channel settlement can enable rollback theft, such as allowing B to steal $50 from A.Existing protocols counter this by writing the latest settlement transaction within a bounded reaction time Δ.
  • Security limitations: Synchronous blockchain access assumes parties can read and write within fixed Δ, but queues, censorship, ordering control, and network partitioning can violate that assumption.A shorter Δ speeds settlement but makes these attacks easier, while disconnection can prevent payment-channel use entirely.

3 Teechain Design

Teechain separates treasury-managed deposits and payment channels from blockchain timing, using TEEs to enforce protocol execution and committee replication to tolerate compromised or failed TEEs. Its design supports direct and multi-hop payments while preserving balance security under asynchronous blockchain access.

  • Design overview: Teechain replaces the blockchain root of trust for payment execution with TEEs that enforce faithful protocol behavior.The protocol requires blockchain reads and writes to complete eventually rather than within a fixed upper bound.
  • Security goal: Balance security means each party can eventually receive its perceived balance on the blockchain despite arbitrary blockchain access delays.Perceived balance equals initial blockchain balance plus received payments minus made payments.
  • Threat model: Teechain assumes rational, potentially colluding parties, message manipulation, and arbitrary compromise of a subset of TEEs.Parties may be disconnected from or prevented from accessing the blockchain for an unbounded time.
  • System architecture: Each Teechain node exposes an API, blockchain interface, and TEE-protected treasury that stores and manages funds.Treasuries execute channels and payments autonomously without interacting with the blockchain during off-chain operation.
  • Committee chains: Committee treasuries jointly manage deposits, requiring approval from a subset of members for off-chain transactions and settlement.This avoids relying on individual TEEs for security.
  • Payment operation: Teechain forms channels between connected nodes, updates balances through treasury communication, and supports multi-hop paths.Its API covers deposits, payment channels, and committee construction; treasuries hold deposit keys inside TEE memory.
  • Failure handling: Force-freeze replication breaks and freezes the chain when a member fails or refuses to update, preventing rollback attacks.All channels must then be settled and unused deposits released.

4 Payment Protocol

Teechain’s payment protocol uses TEE-protected treasuries to support dynamically assigned deposits, off-chain channel payments, and multi-hop transfers without bounded-time blockchain access. Its security argument shows that parties can recover their perceived balances despite asynchronous access and certain failures or attacks.

  • Deposit allocation: Teechain creates deposits through treasury committees and allows approved deposits to be associated with or dissociated from channels dynamically.Deposits are initially sent to treasury-controlled multi-signature addresses, while channel assignment occurs separately.
  • Payment channels: Payment channels are created between treasuries without blockchain interaction and maintain balances backed by associated deposits.Treasuries establish authenticated secure communication, initialize balances, and track the relationship between deposits and channel balances.
  • Payment execution: A single integrity-protected message exchange atomically decrements the sender treasury’s balance and increments the recipient treasury’s balance.The treasury can later generate a settlement transaction containing the final channel balance.
  • Settlement: Channels with neutral balances can terminate off-chain, while non-neutral channels settle by writing final balances to the blockchain.Parties may settle at any time; the treasury generates the blockchain transaction when on-chain settlement is required.
  • Multi-hop payments: Multi-hop payments require all channels on the path to update atomically so intermediaries preserve their total funds.Teechain’s protocol locks the path channels and coordinates the multi-hop payment through treasury messages.
  • Security: Teechain achieves balance security under asynchronous blockchain access, allowing parties to recover funds regardless of access times or other parties’ actions.The security proof also shows that multi-hop participants can unilaterally reclaim their perceived balances without funds being lost or created.

5 Committee Chains

Teechain replicates treasury state with force-freeze committee chains, combining strong consistency with threshold signatures to tolerate selected failures and compromises. Committee parameters determine the security, availability, and transaction-size trade-offs, while persistent storage adds crash recovery subject to hardware limits.

  • Force-freeze replication: Force-freeze replication propagates each update along a treasury chain and waits for acknowledgements before executing it.If a node or successor fails to update, the chain freezes rather than continuing with divergent state.
  • Failure handling: Freezing a committee chain forces its channels to settle and releases unused deposits, preventing rollback and state-forking attacks.Teechain uses financial incentives because a committee member that forces a freeze loses accumulated participation fees.
  • Committee security: For an n-member committee, at least m treasuries must sign a deposit’s blockchain transaction; balance security can fail after m compromises or (n −m) + 1 failures.The threshold controls how many compromised or unavailable treasuries the system can withstand.
  • Committee configuration: Increasing m adds signatures to transactions and increases their size, creating a security-versus-overhead trade-off.A 1-out-of-n committee tolerates crashes but not compromises, while larger thresholds improve compromise tolerance.
  • Committee configuration: Parties choose committee sizes and thresholds according to deposit value, ranging from 1-out-of-1 for small deposits to 2-out-of-3 or larger committees for higher-value deposits.Parties select committee treasuries themselves and may consider reputation, vendors, implementations, blacklists, and hardware heterogeneity.
  • Persistent storage: Secure persistent storage can let failed treasuries reload state and settle channels, but hardware monotonic-counter limits constrain performance and eventually force settlement.Current Intel SGX counters allow tens of increments per second and approximately 1 million writes.

6 Evaluation

The evaluation measures Teechain’s channel, multi-hop, network, and blockchain-cost performance against Lightning and related designs. Results show substantial throughput gains, with costs depending on committee replication, topology, and channel-management choices.

  • Evaluation scope: The evaluation covers payment channels, multi-hop payments, complete and hub-and-spoke networks, and blockchain storage costs.Experiments compare Teechain with Lightning and other payment-channel designs using throughput, latency, topology, and transaction-cost measures.
  • Payment channels: 34× higher throughput than LN is achieved by Teechain with n=2 committee members and similar latencies.With n=1, Teechain reaches two orders of magnitude higher throughput than LN at 86 ms latency; adding committee members increases latency while throughput remains unchanged.
  • Multi-hop payments: 16–26× higher throughput than LN is achieved for Teechain multi-hop payments across 2 to 11 hops.With n=3 committee chains, Teechain reaches 14,062 tx/sec for 2 hops and 3,649 tx/sec for 11 hops, versus 862 and 139 tx/sec for LN.
  • Payment networks: 2.2 million tx/sec is reached by a 30-machine complete-graph deployment with n=1 committee chains, while n > 1 achieves 1 million tx/sec.Throughput scales linearly with node number, and n=2 versus n=3 differs by only 9% because state replication becomes the bottleneck.
  • Payment networks: Several orders of magnitude lower throughput occurs in hub-and-spoke networks than in complete topologies, although dynamic channels alleviate contention.With G=1 and n=3, throughput is around 210 tx/sec; increasing G produces near-linear gains before tier 3 congestion causes diminishing returns.
  • Limitations: A detailed Teechain–LN comparison requires controlling routing, batching intervals, dynamic-channel counts, and contention avoidance algorithms.The evaluation defers these additional experiments to future work because single- and multi-hop performance differs across the systems.
  • Blockchain cost: 25%–75% fewer blockchain transactions than LN are required by Teechain, with up to 58% greater bilateral-termination efficiency.Under the stated 2-out-of-3 multisignature assumption, Teechain also uses 50% fewer transactions and 37% less blockchain data than DMC for bilateral closures.

7 Related Work

Existing payment-network proposals improve blockchain performance through off-chain channels but generally retain synchronous blockchain-access assumptions. Teechain instead executes payments without the blockchain and scales through concurrent committees.

  • Payment channels and networks: Existing payment networks move deposits into point-to-point channels, exchange payments off-chain, and settle final balances on-chain.This design provides higher throughput and lower latency than blockchains.
  • Asynchronous access: All surveyed payment-channel proposals assume synchronous blockchain access, whereas Teechain avoids that assumption.Users can choose whether to use Teechain with a blockchain.
  • Blockchain layer scaling: Teechain scales throughput through multiple concurrent, independent committees rather than reaching consensus for every payment transaction.Deposit and settlement transactions still use the blockchain as in other second-layer systems.
  • Trusted hardware and blockchains: Earlier trusted-hardware payment systems do not integrate asynchronously with blockchains and assume hardware is uncompromised.These systems use dedicated hardware to enforce double-spending protection.
  • Trusted hardware and blockchains: CCF uses TEEs in a permissioned blockchain, unlike Teechain’s operation on an existing permissionless blockchain.CCF assumes all consortium-member identities are known.
  • Trusted hardware and blockchains: TEEChan provides single-hop channels with limited lifetimes but requires synchronous access, lacks multi-hop payments, and cannot dynamically assign deposits.Teechain addresses these limitations with asynchronous access and dynamic deposits.

8 Conclusion

Teechain combines asynchronous blockchain access and dynamic deposits with committee-chain replication to mitigate TEE compromises. Evaluation on Bitcoin using Intel SGX reports orders-of-magnitude performance gains over the state of the art.

  • Conclusion: Teechain is the first payment network to support both asynchronous blockchain access and dynamic deposits.These features remove the synchronous-access assumption and allow deposits to be assigned dynamically.
  • Conclusion: Teechain mitigates TEE compromises through force-freeze replication and m-out-of-n signatures organized into committee chains.The committee chains combine replication with threshold signatures.
  • Conclusion: Evaluation using Intel SGX on Bitcoin shows orders-of-magnitude performance gains compared with the state of the art.

A Teechain Protocol Correctness

The correctness analysis defines a proof framework for Teechain’s security guarantees and formally proves them for payment channels and multi-hop payments.

  • Correctness framework: The paper first defines the desired payment-network security guarantees and introduces the framework used for its proofs.
  • Correctness proofs: Teechain’s security properties are formally proved for payment channels.
  • Correctness proofs: The paper also formally proves the desired security properties for multi-hop payments.

A.1 Security Guarantees

Teechain’s security goal is that well-behaved participants can reclaim balances and deposits correctly despite other participants’ actions. The formal definition requires recovery to complete in finite time and preserve the participant’s perceived balance.

  • Security guarantees: Balance security requires that funds cannot be stolen or double spent despite other participants’ behavior.The guarantee applies to all participants in the network.
  • Security guarantees: A well-behaved user may unilaterally reclaim channel balances and unassociated deposits on the blockchain, correctly reflecting all payments.The user must be able to do so despite other participants’ actions.
  • Formal definition: Formally, balance security requires finite-time recovery after any execution prefix with eventual on-chain balance at least equal to perceived balance.Perceived balance equals initial balance plus received payments minus paid payments.

A.2 Ideal Functionalities and Simulation Based Security

The paper models Teechain using ideal functionalities for TEEs and the ledger within the UC framework. It defines the protocol API, system state, adversarial model, and security-property framework used for formal analysis.

  • Model: The UC framework models executions with an environment, honest parties, and an adaptive Byzantine adversary that may corrupt users.Security guarantees are defined for honest users that follow the protocol.
  • Security framework: UC security is established by showing real- and ideal-world executions indistinguishable to the environment, then proving the desired property in the ideal world.The real-world model uses FTEE and FB as idealized representations of TEEs and the blockchain.
  • Ideal functionalities: FTEE models a TEE as a trusted enclave that provides confidentiality, integrity, authenticity, attestation, program installation, and program resumption.The functionality abstracts an enclave running the Teechain protocol and signs messages for verification by users or other TEEs.
  • Ideal functionalities: FB models the underlying blockchain as a ledger of public-key balances supporting signed transfers and balance queries.Ledger entries contain a public key and its current balance, and edits require the corresponding private-key signature.
  • Ideal functionalities: FTeechain captures Teechain’s protocol through internal variables and an API for deposits, channels, payments, settlements, and ledger interaction.Its state includes ledger balances, open channels, deposits, and pending operations.

A.3 Indistinguishability of the real-world and ideal-world

The proof replaces the real execution with a sequence of indistinguishable hybrids until reaching the ideal FTeechain execution. The simulator emulates adversarial interactions with TEEs and the ledger while mapping protocol calls to ideal functionality calls.

  • Conclusion: Lemma 1 concludes that the Teechain channel protocol in the hybrid model UC-realizes FTeechain.This follows because no environment can distinguish interaction with the real protocol from interaction with the simulator and ideal functionality.
  • Hybrid proof: The proof starts from the real-world execution in the (FTEE, FB) hybrid model and proceeds through hybrid steps toward the ideal world.Each step is shown indistinguishable from the preceding execution.
  • Hybrid proof: H1 and H2 simulate the signing service and ledger interactions, preserving the adversary’s view of the real execution.The simulator generates signing keys and faithfully emulates FTEE and FB for adversarial users.
  • Hybrid proof: H3 and H4 reject incorrectly signed messages, with indistinguishability relying on the unforgeability of the signature scheme.Correctly signed outputs are recorded and delivered, while invalid signatures cause the simulator to abort.
  • Ideal-world mapping: H5 maps simulated real-world calls to FTeechain operations for deposits, payments, settlements, and ledger acceptance.The simulator translates calls such as release_deposit, associate_deposit, approve_deposit, pay_channel, paid, and settle_channel.

A.4 Balance security in the Ideal-World

The ideal-world analysis defines balance security as eventual recovery of a user’s perceived balance despite other parties’ failures or corruption. It proves that Teechain’s operations let users recover deposits, channel balances, and pending ledger payments.

  • Definition: Balance security requires that an honest user can eventually receive her perceived balance on the ledger even if another party is corrupt or crashes.The user may perform a finite sequence of operations without another user affecting the outcome.
  • State and balance: The execution model tracks ledger balances, channels, deposits, payments, and pending ledger operations across event prefixes.These state variables support the definition of perceived balance and the recovery algorithm.
  • State and balance: The perceived balance combines the initial ledger balance with received payments, less sent payments, while accounting for deposits and channel capacity.The analysis maintains this quantity across protocol transitions.
  • Security result: The proof concludes that the ideal functionality achieves balance security and that Teechain inherits it because the real and ideal executions are indistinguishable.Users can recover their inner balance, which equals their perceived balance, without changing other users’ perceived balances.

A.5 Multi-hop payments

The multi-hop protocol preserves balance security across intermediate nodes by allowing participants to settle consistently in either the pre-payment or post-payment state during transitions. After unlocking, settlement uses the post-payment state.

  • Protocol stages: A multi-hop payment progresses through idle, lock, sign, prepayment, update, postUpdate, and unlock stages.The proof analyzes which settlement state is available to each node at each stage.
  • Perceived balances: Before completion, endpoint perceived balances may reflect either pre-payment or post-payment, while intermediate nodes’ perceived balances remain unchanged.The acceptable endpoint state depends on the protocol times t1 through t4.
  • Settlement states: During the lock stage, all nodes can settle only at the pre-payment state, preventing inconsistent partial settlement.The same pre-payment restriction applies while nodes progress through the signing stage unless the protocol advances together.
  • Settlement states: Between prepayment and postUpdate, nodes may settle in either state, but the protocol ensures that all channels settle consistently.Once nodes reach update or postUpdate, available settlement transactions constrain the outcome across the route.
  • Security result: At unlock, all participants can reclaim their perceived balances, and the multi-hop protocol satisfies balance security.The proof concludes that both channel and multi-hop payments guarantee balance security.
Loading 1707.05454v4…