PaperlayerView exact revision on arXiv

Source-linked AI summary

Sprites and State Channels: Payment Networks that Go Faster than Lightning

Andrew Miller, Iddo Bentov, Ranjit Kumaresan, Christopher Cordi, Patrick McCorry

arXiv:1702.05812v2cs.CR

TL;DR

Cryptocurrency blockchains have limited scalability, motivating payment-channel networks that route payments without trusting intermediate hops. The paper introduces Sprites, a payment-channel design with constant-locktime mechanisms, formalized state channels, and network simulations. Sprites reduces worst-case collateral locktime and supports uninterrupted incremental deposits and withdrawals, while mitigating throughput reductions under petty attacks in the evaluated networks.

  • Problem

    Blockchain-based cryptocurrencies face limited scalability, while multi-hop payment channels incur collateral costs that grow with path-dependent locktimes.

  • Method

    Sprites combines constant-locktime linked payments with a formally defined state-channel abstraction and simulation-based payment-network evaluation.

  • Results

    Sprites reduces maximum collateral locktime to O(ℓ+∆) rounds and sustains 88.7% BA and 76.8% WS baseline throughput when half the network is petty.

  • Takeaways & Limitations

    Sprites supports partial deposits and withdrawals without interrupting payments and mitigates throughput-reducing petty attacks in the simulated networks.

  • Takeaways & Limitations

    The constant-locktime construction requires an Ethereum-style global contract mechanism and cannot, the authors conjecture, be emulated in Bitcoin without scripting changes.

Abstract

from arXiv · show

Bitcoin, Ethereum and other blockchain-based cryptocurrencies, as deployed today, cannot scale for wide-spread use. A leading approach for cryptocurrency scaling is a smart contract mechanism called a payment channel which enables two mutually distrustful parties to transact efficiently (and only requires a single transaction in the blockchain to set-up). Payment channels can be linked together to form a payment network, such that payments between any two parties can (usually) be routed through the network along a path that connects them. Crucially, both parties can transact without trusting hops along the route. In this paper, we propose a novel variant of payment channels, called Sprites, that reduces the worst-case "collateral cost" that each hop along the route may incur. The benefits of Sprites are two-fold. 1) In Lightning Network, a payment across a path of $\ell$ channels requires locking up collateral for $Θ(\ellΔ)$ time, where $Δ$ is the time to commit an on-chain transaction. Sprites reduces this cost to $O(\ell + Δ)$. 2) Unlike prior work, Sprites supports partial withdrawals and deposits, during which the channel can continue to operate without interruption. In evaluating Sprites we make several additional contributions. First, our simulation-based security model is the first formalism to model timing guarantees in payment channels. Our construction is also modular, making use of a generic abstraction from folklore, called the "state channel," which we are the first to formalize. We also provide a simulation framework for payment network protocols, which we use to confirm that the Sprites construction mitigates against throughput-reducing attacks.

I. INTRODUCTION

Blockchain replication provides security but limits cryptocurrency scalability, motivating off-chain payment channels and networks. Sprites targets the collateral and topology pressures of multi-hop payments while adding uninterrupted channel deposits and withdrawals.

  • Scaling motivation: Off-chain payment channels let parties transact rapidly while using the blockchain mainly for settlement, disputes, or withdrawals.Channels use on-chain collateral and off-chain messages, reducing the need for blockchain processing of individual payments.
  • Sprites contribution: Θ(ℓ^2X∆) collateral cost arises for a payment of size X across ℓ channels under Lightning’s Θ(ℓ∆) worst-case delay.Here, ∆ denotes the worst-case time for an on-chain transaction to confirm.
  • Sprites contribution: Sprites supports incremental deposits and withdrawals without interrupting channel payments, unlike constructions requiring channels to close and reopen.The earlier approach pauses pending payments, which harms throughput.
  • Formalization and evaluation: The construction formalizes state channels and uses simulation experiments to assess payment-network performance across multiple topologies.The state-channel abstraction represents an off-chain replicated state machine synchronized with the blockchain on demand or during disputes.
  • Scaling motivation: High collateral costs on long paths may economically favor centralized networks built around well-connected hubs.The introduction evaluates multiple topologies because long payment paths reserve more collateral and can affect network structure.
  • Formalization and evaluation: Sprites relies on Ethereum-style global contract events and therefore cannot, the authors conjecture, be implemented in Bitcoin.This limitation concerns the constant-locktime feature specifically.

B. Blockchain scaling

Blockchain scaling can use off-chain protocols that preserve rapid payments while limiting on-chain work. Linked conditional payments provide network connectivity, but their timeout structure creates path-length-dependent collateral costs that Sprites seeks to reduce.

  • Off-chain payment channels: Payment channels require an on-chain opening deposit, then support repeated rapid payments through exchanged signed messages.Closing the channel requires a final on-chain transaction that distributes balances according to the contract.
  • Payment-channel networks: Duplex channels alone do not scale network connectivity because directly connecting N parties requires O(N^2) on-chain opening transactions.Payment-channel networks instead route payments over sparse graphs of active channels.
  • Payment-channel networks: HTLC-linked payments synchronize channels with one shared hash condition, allowing a recipient to claim payment by revealing its preimage.Conditional payments can otherwise be canceled after their deadlines.
  • Payment-channel networks: Lightning’s deadlines increase by Θ(ℓ∆) across an ℓ-hop path, where ∆ is the on-chain confirmation bound.The linked-payment protocol must preserve no counterparty risk while ensuring incoming and outgoing conditional payments remain consistent.
  • Payment-channel networks: Sprites reduces each party’s maximum collateral locktime to O(ℓ+∆) rounds by using the recipient’s preimage and on-chain dispute handling.When parties are honest, the process completes after only ℓ+1 off-chain rounds.

E. Related Work

The paper situates Sprites among payment-channel and related off-chain designs, then outlines its construction using conditional payments, a PreimageManager, and globally consistent dispute handling. Its key mechanism uses a common expiry time and reduces collateral lock duration across linked payments.

  • Related approaches: Prior payment-channel research includes off-chain rebalancing, virtual channel overlays, privacy-oriented constructions, probabilistic micropayments, and federated sidechains.Revive is incorporated into the paper’s simulation; virtual channel overlays are described as complementary.
  • Sprites overview: Sprites focuses on linked-payment execution and improves on Lightning with constant locktimes and incremental withdrawals or deposits.The overview explicitly identifies these as the construction’s main improvements.
  • Conditional payments: Sprites links conditional payments across channels using a PreimageManager that records whether a preimage was published before a deadline.The construction extends duplex payment channels with conditional payments carrying a hash, expiry deadline, and amount.
  • Dispute handling: A global PreimageManager lets every disputed channel settle consistently, so all linked payments either complete or cancel together.This replaces separate local preimage decisions in Lightning and other prior constructions.
  • Constant locktime: Sprites uses one common expiry time and limits each party’s collateral lock to O(ℓ + ∆) rounds, compared with longer locktimes when each channel must receive the preimage separately.Optimistically, linked payments finish after ℓ + 1 off-chain rounds; the worst-case bound includes the on-chain round parameter ∆.

B. Supporting incremental deposits and withdrawals.

Sprites supports incremental deposits and withdrawals while keeping channels operational, using a general state-channel abstraction that synchronizes off-chain state with blockchain actions when needed.

  • B. Supporting incremental deposits and withdrawals.: Sprites permits either party to deposit or withdraw part of the channel balance without interrupting payments.Lightning instead requires closing and reopening the channel, settling pending conditions on-chain before payments resume.
  • B. Supporting incremental deposits and withdrawals.: Incremental deposits are represented in off-chain state by each party’s deposits recorded by the smart contract.Stale proposed views can trigger an on-chain dispute, whose handler reads the current contract state.
  • B. Supporting incremental deposits and withdrawals.: Incremental withdrawals use a jointly signed withdrawal value that the smart contract verifies through an update method rather than closing the channel.The supplied passage introduces this mechanism but ends before describing the complete update procedure.
  • B. Supporting incremental deposits and withdrawals.: A state channel maintains a consistent replicated state machine whose application-defined transition function processes party inputs in rounds.Signed state updates, dispute handling, and blockchain synchronization are abstracted behind the interface.
  • B. Supporting incremental deposits and withdrawals.: The abstraction supports blockchain side effects through external-contract inputs and outputs, including deposits and withdrawal-related disbursements.Its ideal functionality models bounded delays for contract messages and invokes the update function on accumulated inputs.
  • B. Supporting incremental deposits and withdrawals.: FState guarantees consistent sequential state delivery, bounded progress, and exactly-once application of transition side effects, but provides no input privacy.Adversarial inputs may depend on honest inputs because the functionality explicitly exposes inputs to the adversary.

B. Instantiating state channels

ΠState implements the state-channel abstraction with signed off-chain state updates and a smart-contract dispute handler. Disputes can resolve through newer off-chain evidence or on-chain input processing.

  • B. Instantiating state channels: ContractState provides the dispute protocol that underlies the state-channel implementation.The contract portion is the protocol centerpiece; local party behavior is described separately.
  • B. Instantiating state channels: ΠState advances off-chain state through signed messages containing the round, updated state, and resulting blockchain output.The state is computed from all parties’ inputs, with no output represented by ⊥.
  • B. Instantiating state channels: A party raises a dispute by submitting a checkpoint for the previously agreed round and invoking the dispute method.This occurs when required signatures for the current round are not received before the timeout.
  • B. Instantiating state channels: Newer signed evidence can clear a dispute and advance the contract to any later agreed round.This handles cases where a party disputes an earlier round that has already been settled off-chain.
  • B. Instantiating state channels: If newer evidence is unavailable, parties submit inputs on-chain and resolve applies the update function after the deadline.The transition therefore proceeds using on-chain inputs when off-chain dispute resolution cannot complete.
  • B. Instantiating state channels: Upon a dispute, parties pause the off-chain routine when they lack completed evidence, preventing late off-chain evidence from conflicting with on-chain processing.This avoids a concurrency hazard involving evidence arriving after the dispute deadline.
  • B. Instantiating state channels: Theorem 1 states that ΠState realizes FState assuming one-way functions exist.The accompanying simulation argument claims indistinguishability between real execution with ContractState and ideal execution with FState.

C. Modeling payment channels as an ideal functionality

The paper models a bidirectional off-chain payment channel as an ideal functionality and constructs it from the general-purpose FState abstraction. The construction supports payments, deposits, withdrawals, batching, and security realization in the FState-hybrid world.

  • FPay models rapid balance transfers after an on-chain deposit, using off-chain messages except during disputes or mutual agreement.
  • FPay provides no counterparty risk and bounded-time processing for withdrawals and payments.
  • The FPay construction combines an update function, an auxiliary deposit-and-withdrawal contract, and local party behavior.
  • The state records cumulative deposits and balance offsets because FState auxiliary inputs may be only loosely synchronized with state updates.
  • FPay batches payment and withdrawal inputs until the next FState round begins.
  • Theorem 2 states that ΠPay realizes the FPay functionality in the FState-hybrid world.

V. LINKED PAYMENTS FROM STATE CHANNELS

The linked-payment functionality coordinates conditional transfers across a path of payment channels while preserving atomicity and protecting honest parties. When balances suffice and parties are honest, a chained payment completes in O(ℓ) rounds and reaches a terminal state within O(ℓ + Δ) rounds.

  • FLinked coordinates multiple FPay instances to implement conditional payments consistently across a channel path.
  • If a channel lacks sufficient balance, the conditional payment is canceled; otherwise, FLinked reserves balances by moving channels from init to pending.
  • O(ℓ) rounds suffice for a chained payment to complete when all parties are honest and every channel has sufficient balance.
  • After O(ℓ + Δ) rounds, the payment either completes atomically for honest endpoints or fails with both endpoint balances unchanged.
  • The construction’s formal presentation uses an ideal chained-payment functionality and a modular state-channel implementation.
  • Individual FPay channels continue supporting unconditional payments, deposits, and withdrawals while a linked payment is in progress.

B. Instantiating linked payments

The instantiation implements linked payments by layering conditional-payment logic over state channels and synchronizing disputes through a global preimage manager. Simulations evaluate topology, routing, rebalancing, and petty attacks, finding substantial throughput benefits from incremental deposits and constant locktimes.

  • ULinked extends UPay with conditional-payment state, while auxiliary contracts and local behavior complete the protocol construction.
  • A linked payment propagates a hash-locked conditional payment along the path, and the recipient releases the preimage to complete the chain.
  • ContractPM makes disputed payments settle consistently: submitting the preimage before TExpiry completes every disputed conditional payment.
  • The security proof addresses inconsistent hashes, partial completion, and an optimistic execution in which ContractPM is never invoked.
  • Simulation setup: Simulations use BA and WS topologies, Flare or shortest-path routing, tick-based channel evolution, and modeled on-chain rebalancing.
  • Simulation results: Incremental deposits improve attainable throughput by over 3.2% in BA networks and over 11.5% in WS networks.
  • Simulation results: At PettyRate = 0.5, Sprites sustains 88.7% of BA baseline throughput and 76.8% of WS baseline, versus Lightning’s 60.9% and 22.7%.

VII. DISCUSSION AND CONCLUSION

Sprites improves payment-network throughput and worst-case collateral costs relative to Lightning, while supporting uninterrupted channel deposits and withdrawals. The paper also identifies Ethereum-style global contracts as a boundary for constant locktimes and leaves privacy and concurrent transfers as future-work areas.

  • Discussion and conclusion: Sprites improves achievable throughput and worst-case collateral costs compared to Lightning, with greater impact in decentralized topologies and routing algorithms.The authors argue that these improvements directly support a more decentralized payment channel network.
  • Future work: Constant locktimes rely on an Ethereum-style global contract mechanism that the authors conjecture cannot be emulated in Bitcoin without modifying its scripting system.The paper poses minimal Bitcoin-script modifications enabling constant locktimes as an open question.
  • Future work: Sprites’ constructions and security definitions do not aim to ensure transaction privacy because collateral cost is the primary performance objective.The authors describe privacy-focused work as complementary and suggest state channels as a building block for future privacy work.
  • Future work: The presented FLinked functionality expresses only a single conditional transfer, although the authors state that multiple concurrent payments would be straightforward to add.The proof-of-concept Ethereum implementation includes this extension.
  • Further questions: Supporting intermediary fees would require conditional payments to let each intermediary claim a fee after payment completion.Intermediaries contribute collateral and resources while the payment is in progress.
  • Further questions: Sprites can support fair exchange of a merchant’s signed invoice for a customer’s payment using conditional transfers.The proposed exchange uses an invoice containing h = H(x).

APPENDIX

The appendix formalizes Sprites using UC simulation, ideal functionalities, blockchain-aware hybrid worlds, and modular state-channel composition. It sketches deterministic simulations showing that the payment-channel protocol realizes its ideal functionality.

  • Security framework: The paper uses UC simulation-based security to model smart-contract protocols and prove that real executions realize ideal functionalities.The framework translates real-world adversaries into ideal-world simulators whose views are indistinguishable to the environment.
  • Blockchain model: The blockchain model treats the chain as a shared public database with transactions committed into a consistent ordered log visible to all parties.Views are only approximately synchronized, reflecting the model’s blockchain assumptions.
  • Smart-contract assumptions: Smart contracts execute correctly but provide no inherent privacy, while adversaries may reorder and front-run submitted inputs.The construction also assumes approximately synchronized block-number clocks and transferable built-in coins.
  • Modular composition: The simulation-based framework supports modular composition by allowing a protocol that realizes an intermediate functionality to be substituted into a higher-level construction.The composition theorem guarantees this substitution.
  • Hybrid-world formalism: The formalism models smart contracts and ideal functionalities together in a hybrid world, enabling ideal functionalities to read from and post messages to the blockchain.This captures blockchain side effects needed for composing smart-contract protocols.
  • ΠPay simulation: The deterministic simulator maintains a sandboxed execution of ΠPay in exact correspondence with FPay, making the hybrid and ideal-world views identical.The simulator schedules ideal-world payments within O(1) or O(∆) rounds to match observable events.
  • ΠPay security: Theorem 3 states that ΠPay in the FState-hybrid world realizes the FPay ideal functionality.The proof sketch handles honest inputs and contract inputs by relaying them through the sandboxed execution.

C. Details of the Linked Payments Construction

The linked-payment construction uses state channels and a blockchain preimage manager to coordinate conditional transfers across a path. Honest execution completes off-chain in O(ℓ) time, while disputes settle within O(ℓ + ∆) time and preserve endpoint consistency.

  • Construction security: ΠLinked realizes the FLinked functionality in the FState-hybrid world.The proof uses a simulator for the real-world adversary and shows that FLinked does not raise an exception.
  • Timing guarantees: O(ℓ + ∆) time bounds terminal flag states when parties may be corrupt, versus O(ℓ) when all parties are honest.Proposition 5 applies this bound to every linked state channel.
  • Honest execution: ℓ + 2 off-chain time steps suffice for completion when all parties are honest, placing every flag variable in the terminal complete state.The construction’s optimistic execution is entirely off-chain.
  • Consistency guarantees: O(ℓ + ∆) time ensures that adjacent honest parties do not have inconsistent cancel and complete flags.The stronger O(ℓ) bound applies when all parties are honest.
  • Endpoint guarantees: O(ℓ + ∆) time leaves honest endpoints in either the complete, complete or cancel, cancel state pair.With all parties honest, the corresponding bound is O(ℓ).

D. Local Protocol for the State Channel Construction

The state-channel protocol combines off-chain signed batching with on-chain dispute resolution. Its lemmas bound dispute outcomes and synchronize parties, while Theorem 11 establishes realization of FState assuming one-way functions.

  • Local protocol: The leader batches party inputs, gathers signatures on the batch, and multicasts a COMMIT message to reach off-chain agreement.This resembles the fast path of fault-tolerant consensus.
  • Dispute resolution: A dispute produces either EventOffchain(r) within T + ∆ or EventOnchain(r) within T + 2∆ for every party.This gives the state channel a bounded resolution path after EventDispute(r, T).
  • Dispute resolution: If an honest party sees a dispute but no timely COMMIT(r), no COMMIT(r + 1) can arrive before round r is settled on-chain or off-chain.This prevents the leader from advancing to the next round before the disputed round is resolved.
  • Off-chain confirmation: If COMMIT(r) arrives before the deadline, every party receives EventOffchain(r) by T + 2∆.The parties’ synchronized state and signatures allow the contract to confirm the off-chain outcome.
  • Security theorem: Theorem 11 states that ΠState realizes FState assuming one-way functions exist.The proof uses a sandboxed simulation of the local protocol and contract behavior.
  • Evaluation: The Ethereum test-network cost breakdown reports costs using 1 Ether = $90 and a gas price of 0.00000002 Ether.These conversion assumptions represent real-world costs in May 2017.
  • State tracking: The protocol maintains state and bestRound information to track on-chain progress and prevent replay attacks.Contract events may be delayed, but simulation applies the parameterized update function faithfully.

E. Proof of concept Implementation in Ethereum

The proof-of-concept implementation deploys Sprites as Solidity contracts on Ethereum, supporting deposits, cooperative updates, disputes, withdrawals, and conditional transfers. The implementation also emphasizes reusable contract code and reports the gas costs of core operations.

  • Functionality: The implementation is presented as supporting concurrent conditional transfers and invoice-for-payment exchange between merchants and customers.These capabilities are discussed as part of the proof-of-concept implementation of Sprites.
  • Implementation: Sprites comprises Solidity contracts for the Preimage Manager and the Sprites channel, implementing the paper’s specified functionalities.The Preimage Manager timestamps revealed pre-images for resolving disputed conditional transfers.
  • Implementation: 4,032,248 gas is required to create a Sprites contract, while reusable code can avoid incurring this creation cost repeatedly.The implementation uses DELEGATECALL so other contracts can call Sprites functionality while updating their own storage.
  • Channel operation: Each party can deposit coins at any time, and a cooperative state update requires no contract interaction.Deposits cost 42,705 gas when submitted to the contract.
  • Dispute handling: During disputes, the contract verifies a counterparty’s signature, applies the latest state, permits commands during a grace period, and then resolves the channel.Separate UpdateChannel and UpdateTransfers functions handle payment and withdrawal commands because of Solidity’s function-variable limit.

F. Reproduction of the Flare experiment [50]

The reproduced Flare experiment evaluates payment-routing success using neighborhood and beacon-based routing tables, queried routing information, and k-shortest-path selection. Results are compared with prior simulations across varying query and beacon parameters.

  • Routing design: Flare routing tables combine nearby nodes with paths to beacons that provide partial views of distant network regions.Nodes can query additional routing tables when their existing information does not yield a route.
  • Route selection: Flare first uses source and destination routing information, then queries nodes with small XOR distance to the destination and merges their tables.Route selection uses k-shortest paths to account for changing channel capacity.
  • Experiment: The reproduced evaluation uses Watts-Strogatz networks with 2,000 and 100,000 nodes, average degree 4, rewiring probability 0.3, neighborhood radius 2, query limit 10, and 0–12 beacons.The simulation selects 10 nodes and attempts routes from each to all other nodes, repeating the experiment 30 times.
  • Results: Figure 18 compares accessible-node percentages from prior Flare simulations in left F columns with the reproduction in right M columns.Accessible-node percentage y means that a node can route payments to y percent of other nodes on average.
  • Results: Differences between the reproduced and prior results decrease as the number of queries and beacons increases.The reproduction reports error bars spanning two standard deviations around the mean.
Loading 1702.05812v2…