When Lightning STARKs
TL;DR: StarkPay, a payment scalability engine based on STARK technology, addresses many of the drawbacks of Lightning, the Layer-2 payment solution.
StarkWare’s first application of STARK technology is Layer-2 scalability engines. We’ve recently announced StarkDEX, a scalability engine for DEXes (with some exciting early results).
Our scalability engine can be used for cryptocurrency payments — we call this StarkPay. The advent of stablecoins satisfies a necessary condition for cryptocurrencies to be used as a medium of exchange. The ecosystem is still missing a scalable payment system. We believe StarkPay can answer this need.
This post will compare StarkPay to Lightning, the most prominent scalability solution for bitcoin payments. We’ll start with a review of the advantages and disadvantages of Lightning, as we understand them. We will then describe the basic architecture of StarkPay, and its UX. Finally, we will list StarkPay’s advantages, its disadvantages, and possible mitigations via some promising ideas that we see down the road.
This post will not discuss privacy features which may be added to both solutions.
Lightning
Lightning, a Layer-2 scalable payment protocol, has garnered plenty of excitement since its white paper, published by Poon and Dryja in 2016. There are currently over 3,000 Lightning nodes, with over $2M in total locked value. The Lightning Torch is worth over $100, and it is being passed around by titans of hi-tech such as Jack Dorsey & Reid Hoffman, and financial behemoths like Fidelity.
Lightning aims to scale Bitcoin. Lightning was one of the first Layer-2 solutions, ingeniously proposing to take transactions off-chain, while continuing to rely on the security of the blockchain. It promises to not only scale payments, but to do so with low latency, and minimal fees.
Lightning also has several disadvantages. Let’s review some of them:
Liveness Requirement: A Payer must be online to make a payment — nothing surprising about that. But in Lightning — unlike Bitcoin — the Payee must also be online, in order to sign the transaction with their private key (more on the operations security considerations later). Worse still, from this point on, the Payee must monitor the blockchain to ensure that the Payer does not submit an outdated state of their balance, and close the channel. Routing nodes also have to be online between the timeouts of the upstream and downstream channels, in order to participate in the protocol (i.e. forward the preimage), before the upstream HTLC expires.
Lightning attempts to solve this last burden, of monitoring the blockchain, by introducing watchtowers, a service to which users can delegate, for a fee, the responsibility of monitoring the network.
Capital Inefficiency: Generally, in exchange for convenience, Payers are willing to lock up capital — think of debit cards, for example. But in Lightning, capital needs to be locked up per channel, and not merely per Payer.
Worse still, if the payment is not sent directly from Payer to Payee, but rather it hops via other routing nodes, these nodes also need to lock up at least the amount being paid.
In the ideal case — from a capital efficiency perspective — of a single central node in a star-topology network, the upper bound on the liquidity of the network is that amount of capital which the central node is willing to lock up; unintuitively, the amount locked up by the Payers contributes nothing to the network’s liquidity. In other words, routing nodes need to bring liquidity to the network, which is a somewhat surprising and undesirable trait.
What if we wish to avoid such centralized networks? The more hops there are, the higher the cost of capital — as it is capital locked up, instead of generating interest elsewhere. For example, if Alice wants to send Bob 1 coin via 5 routing nodes, this would require 5 coins to be locked up in the Lightning network. This cost (and the added cost of griefing attacks where routing nodes become uncooperative) will have to translate to fees borne by the transactors; the absence of such fees today might be explained by the altruistic conduct of Lightning’s early adopters.
The motivation to reduce capital inefficiency is a centralization force in the Lightning ecosystem. The degree to which Lightning is centralized is obviously a topic of interest.
Operations Security Challenge: A critique often heard of centralized exchanges is that they create honey pots of cryptocurrencies, which attract hackers. At scale, routing nodes in Lightning networks will create a much more tempting honey pot. Think of the exposure of having a private key in a hot wallet: centralized exchanges need to be exposed only briefly, at a time of their choosing. Routing nodes, on the other hand, need to provide a near-instant service, and so will be exposed at all times. And in order to be of utility, they need to keep sufficient capital (per channel!). This has the makings of an ideal honeypot: plenty of capital, and a private key nearby. Protecting this honey pot will result in an expense most likely covered by fees.
Completion Rate Diminishes with Payment Value: Given that every channel in a multi-hop payment needs to have capital locked up exceeding the amount of the payment, higher value payments have a lower probability of completion, as they will simply have fewer routes to choose from in the network. The restricted supply may also translate to higher fees with increasing payment value. Ideally, one would of course want the completion rate to be independent of the value transacted.
Completion Rate Diminishes with Directionality: Much like the negative impact of increasing payment value, when many Payers pay a single Payee — a very natural use case of customers paying merchants in the real world — they will all compete for a limited supply of routing nodes capacity, en route to their Payee. Note that the Lightning Torch circumvents this use-case.
In a broad sense, it would seem that Lightning’s resource consumption scales with the total value transacted, and not merely with the number of participants, or with the number of payments made. This is obviously not a desired property in a payment scaling solution.
[Note: for the sake of simplicity, we assume here that Lightning’s routing is solved to perfection, free of charge. There are of course those who think it’s a hard problem]
And now, for something completely different (M. Python)
StarkPay
StarkPay aims to offer a scalable capital-efficient non-custodial payment solution, with no liveness requirements.
Building Blocks
StarkPay includes off-chain and on-chain building blocks.
Off-Chain
- A Payment Processor, which interacts with Payers and Payees.
- Payers’ balances tree: these are updated by the Prover, and their availability is ensured (see further discussion below).
- Prover, which generates STARK proofs attesting to the validity of batches of payments provided by the Payment Processor, and to the validity of the update to the Payers’ balances.
On-Chain
- A payment contract, which is the on-ramp/off-ramp for StarkPay, and also stores a commitment to the updated Payers’ balances (stored off-chain, as mentioned above).
- A verifier contract, which verifies proofs generated by the Prover, and communicates with the payment contract.
Let’s review some basic scenarios:
Deposit (“On-Ramping”)
the Payer deposits cryptocurrency into the payment contract. Funds are transferred, using proofs, from the payment contract into the off-chain balances tree. This is analogous to setting up a Lightning channel, with the important distinction that it is not limited to a single recipient.
Withdrawal (“Off-Ramping”)
Funds are transferred from the off-chain balances tree to the payment contract — once again, using proofs — and from there the Payer can transfer them elsewhere. This is analogous to closing a Lightning channel.
Alice pays Bob
- Alice signs (she never gave up custody!) her payment to Bob and sends it to the Payment Processor.
- The Payment Processor sends a batch of payments, including Alice’s payment, to the Prover.
- The Prover generates a STARK proof attesting to the validity of the payments in the batch and to the validity of the update to the balances: it checks digital signatures, and verifies that the Payer has sufficient funds, and then updates the balances commitment (e.g. a Merkle root).
- The Prover sends the proof, and the new commitment to the verifier contract on-chain. Once the proof is verified, the verifier sends the payment contract the new commitment, which it keeps in on-chain storage (as stated above).
There is no trust assumption with respect to the prover — a malicious or negligent Prover will not be able to convince the verifier contract that an invalid proof is in fact valid.
Advantages
We believe this system architecture provides the intended advantages:
Scalability: The computational resources StarkPay consumes scale with the number of Payers, and the number of payments made. Importantly, they do not scale with the total value transacted. We are already within reach of interesting scale: StarkPay will be able to support over 10,000 payments in a single block, per Ethereum’s current gas constraints.
Remarkably, STARKs consume the exceedingly scarce on-chain computational resources with moderation: these grow logarithmically with the size of the off-chain computation. To give a numerical example: in order to grow StarkPay 10X, on-chain computational resource consumption will grow by less than 50%.
Note that when observing a potentially interesting concept such as value/second, and not only transactions/second, StarkPay is effectively unbounded.
Capital-efficiency: Just like in the debit card metaphor, no additional capital needs to be locked up beyond the funds that each Payer wishes to pay. In particular, the Payment Processor and the Prover have no liquidity requirements.
Liveness-free: An update to a Payee’s balance does not require it to be online. In all scenarios (deposit, withdraw and payment) the transaction can be made offline and then sent to the blockchain\Payment Processor.
Non-Custodial: Payers do not provide custody of the cryptocurrency to StarkPay. The Payer’s signature is required for all actions, and they can withdraw funds at any time directly from the Payment contract, even if the Prover becomes malicious or uncooperative (more on this escape hatch in a future blog post).
In this respect, StarkPay matches Lightning’s property, as there too, the user maintains custody of the cryptocurrency.
Disadvantages
StarkPay has some notable disadvantages:
Data Availability: To truly benefit from the on-chain logarithmic scaling of STARKs, data is best stored off-chain, which presents a data availability challenge. Data availability is a challenge that Plasma-based solutions must resolve, in order to remain trust-free and yet manage to break the scalability ceiling.
Mitigation:
- Record payments on-chain: We believe that StarkPay in this mode can easily reach several hundred payments/second.
- One possible future direction for off-chaining data: form a federation of data availability witnesses who sign that for a given proof presented to the on-chain verifier, data was available off-chain. The on-chain verifier will not accept proofs that lack this attestation. It is important to note that the federation is not entrusted with guaranteeing the validity of the state of the system — they cannot steal money, nor can they transition the system to an invalid state.
This federation will later be phased out in favor of a more decentralized solution.
Centralization: Provers will initially be operated by StarkWare. This presents the risk of centralization, and as a byproduct, of censorship.
Mitigation:
- Centralization: other market participants, including other Payment Processors, may naturally provide their own Provers. In the longer term, Provers can rely on a consensus protocol to compete for the business of proof generation in their own network. Note that since state is changed only via validity proofs, the Prover cannot attack the network by transitioning to an invalid state, and in this sense is reminiscent of how Layer-1 consensus is maintained.
- Censorship: STARKs can be used to also provide privacy on top of StarkPay. In particular, Payers could shield their payments even with respect to the Prover itself! The computational statement proven by the Prover would then be that it verified a batch of proofs of individual payments received from Payers.
Latency: Unlike the instant settlement guaranteed in a peer-to-peer Lightning channel, the time required to generate proofs for large batches is currently on the order of minutes.
Mitigation:
- the Prover can provide a commitment to the payment contract, immediately upon checking a batch of payments received, while generating the proof. The risk that the Payee takes — once again, a risk which lasts for several minutes — is that the Prover will withhold the proof indefinitely. This risk can be compensated for by having the Prover stake funds, for example. Worth noting: the latency achieved will be that of the main chain, and not the near-instant latency of Lightning.
As always, latency should not be equated with throughput: StarkPay can provide higher throughput by scaling up the Prover’s computational resources, which all reside off-chain.
No Bitcoin solution: Bitcoin in its current form cannot support an efficient STARK verifier running on-chain.
Mitigation: Do let us know if you have one. Till then, we’ll focus on blockchains which efficiently support an on-chain STARK verifier.
In this post we presented StarkPay, a STARK-based scalability engine for cryptocurrency payments. We started out by analyzing Lightning, a popular scalability solution for Bitcoin, and compared it to StarkPay. We concluded that StarkPay offers a compelling alternative, which improves on Lightning in several noteworthy dimensions.
Thanks to Vitalik Buterin, Patrick McCorry, Jim Posen, and Dan Robinson for comments on drafts of this post.
Tom Brand, Uri Kolodny, and Avihu Levy
