A Manifesto for Micropayments
Author: George Knee
Consensys Mesh’s State Channels R&D team is working on improvements to Filecoin Protocol. Filecoin adds decentralized data storage and retrieval to the web3 landscape. It is a network which could disrupt the cloud object storage and content delivery network industries, with markets projected to be worth tens of billions of dollars over the coming years [Emergen, PRN].
Web3 is the name for the next iteration of the web, where things are becoming decentralized through the adoption of a new breed of protocols. Web3 protocols tend to remove or greatly reduce the need to trust any particular external party (such as a platform controlled by a single corporation), as well as allowing anyone with the knowledge and (hopefully modest) resources to participate.
The problem of fair exchange encapsulates many of the advantages brought by web3. A famous theorem [PGA99] states the impossibility (with a caveat) of a protocol to achieve the following: to swap items x and y, held respectively by parties A and B, so that in the end A has y and B has x. Such a protocol would allow for the swap to be aborted, but importantly would guarantee that neither A nor B could ever have both x and y. In the lingo, the swap should be “atomic” (or unbreakable).
The caveat to the theorem is that the problem becomes tractable if we assume the existence of a trusted third party. A blockchain such as Ethereum can be considered a decentralized trustworthy third party which can hold various kinds of crypto-assets. Decentralized exchanges such as Uniswap have been built on this idea, and allow the atomic exchange of many different types of token (at transparent exchange rates) which are escrowed into a special-purpose smart contract on the blockchain.
But what if we didn’t constrain ourselves to think of x and y as amounts of one cryptocurrency or another? What if one or both were, in fact, units of service provision? Can we use a blockchain as a trusted third party to help fairly exchange money in return for advice, entertainment, or even cloud computation and storage?
It is tempting to think about how a blockchain could be used to escrow something like “service provision.” Depending on the application, this is actually possible to an extent. Let’s take a contrived example to make the point. Let A be a service provider who offers to factor large semiprime numbers. They invite B to make a request to find the two prime factors of a given number – 15, for example. B can make this request, and escrow their payment ‘y’ into a special-purpose smart contract. This contract is programmed to unlock the payment and release it to A if A can provide the two prime factors. (It is possible to efficiently verify a solution to the problem — the smart contract can compute 3 x 5 = 15 at very low cost). There should be a timeout so that B can get their money back if A does not provide the correct solution after some appropriate duration.
So in this way, similarly to the uniswap example, A and B may atomically swap some money with the answer to a computational problem that is easy to verify but difficult to compute. The fact that the problem is difficult to compute incentivises B to outsource the problem to A. As we increase the semiprime number from 15 to something larger, the problem quickly becomes more difficult.. Providing a solution to the problem therefore constitutes a kind of proof of work.
Let’s take a look at another example. Let’s imagine B sends A a large file to store, and retains only a fingerprint of that file in the form of a cryptographic hash. At some later time, B wants to retrieve the file from A, and again places the payment for this retrieval service into a smart contract, locked up with the hash. This time, the smart contract is programmed to accept the raw bytes of the file itself, recomputes the hash to verify those bytes, and then releases the payment to A if the hash matches. Once again, it is practically impossible for A to unlock the payment without providing proof of delivery of the service, in this case by making the original data of the file available.
There are problems with trying to generalize such a scheme, however. First, not all service provision can be verified by a smart contract. A second problem is that even if the service provision can be verified, it is not always feasible to do so on a blockchain. Secure, decentralized blockchain computation is expensive, and it would not make sense to compute the hash of a 1 GB file on the chain - on Ethereum mainnet, this would cost thousands of dollars at today’s prices and even exceed the block gas limit.
This is where micropayments come in.
Micropayments work by having B lock up their payment in a smart contract as before. But instead of having a blockchain smart contract (the trusted third party) verify the service provision, B verifies it themselves in a piecewise manner.
For example, if they want to pay for some service provision which is verifiable on a blockchain, but not at sufficient scale — this could be the file retrieval case discussed above or some other application involving, say, a proof of knowledge or proof of work. There may be a long running relationship between service provider and consumer, requiring hundreds or thousands of payments per relationship every day. High scale verifiable service provision requires an off chain payment system that can handle both massive throughput and small amounts.
And things get really interesting when we consider the extension to non-publicly-verifiable service provision.
For example, if they want to pay to fuel their car, they will hold back the first 1% of the payment until the first 1% of the fuel has been delivered into their tank. And so on for the next 1%, until the transaction has been completed. Correspondingly, A will hold back the fuel until they have enough payment. One of the parties must send an unconditional amount of money or provide some unconditional service to get the process started. If either party reneges on their side of the deal, the transaction can halt at any time. If that happens, the “optimistic” party will be out of pocket, but only to the tune of a small amount. That amount may be made almost arbitrarily tiny by adjusting the “graininess” or resolution or the payments. Instead of conditioning on the first 1% of the service, they can condition on the first one thousandth or one millionth.
This works particularly well for service provisions which are infinitely divisible, such as delivering raw materials, electricity, or internet bandwidth. It is even better if that service provision can be verified by the service consumer in real time or on the fly. For example, verifying whether or not the lights are still on in your home. It is not necessary for the provider to publicly prove they have delivered the service — they need only convince the consumer. Things like currency exchange also work well in this model [Dan Robinson / Interledger], provided that the parties are reasonably content if the swap stops part way through. (I wanted to swap 1 USD for 2 EUR, but in the end I only swapped 0.5 USD for 1 EUR — at the same exchange rate.)
In situations where x or y have no value unless delivered in full, micropayments or “gradual exchange” protocols do not really help. As stated in [PGA99], one party can then obtain full advantage over the other by withholding the last piece of x when they have received all of y. File retrieval may seem like a situation of this type, but the risk can be addressed by having multiple retrieval providers on hand to provide the missing piece(s).
It is also possible to have dynamic exchange rates and dynamic chunk sizes. There’s the possibility to combine some on-chain verification, micropayments, and repetitional trust elements to get a hybrid model of low-trust incentivised service provision.
Micropayments can be implemented through a system called payment channels. A payment channel is a private ledger between a payer and a payee, which has funds reserved for it on a blockchain. Those funds are redistributed — in other words, micropayments are made — by the use of cryptographic signatures generated by the payer and delivered directly to the payee. We at statechannels.org built a POC around this idea called web3Torrent, where peers can stream money in exchange for pieces of a file in a torrent swarm.
Our team is actively working on applying this concept once more to the Retrieval Markets, a critical piece of the Filecoin protocol. It is a component which complements, but has not yet seen the same level of adoption as the Filecoin Storage Market. The Storage Market is built around network rewards associated with publicly verifiable Proof of Storage. It is the central mechanism providing incentives for Storage Providers and economic guarantees for Storage Clients. There is no direct counterpart for Proof of Retrieval, however. It is not feasible to prove — in a publicly verifiable way — that a retrieval has been served. By integrating our high-performance payments system, we can provide incentives for Storage Providers to also be Retrieval Providers, and lean on the gradual exchange protocol above to reduce the amount of mutual trust placed by Providers and Clients. Micropayments are released conditional on real-time “soft” verification by the consumer rather than a “hard” cryptographic proof provided by the service provider. Similarly, the service provision is released on private verification of the client’s digital signatures as discussed above.
Our system, called Nitro protocol, features virtual payment channels (invented by the Perun team [D+19]). Virtual channels are payment channels which are constructed by escrowing money — not on the blockchain itself, but in those very private ledgers constituted by existing payment channels’ connected peers in a payment network. Those channels form a link along a multi-hop path of mutually connected intermediaries who are all involved in the escrow part of the protocol, but crucially not in the payment part. This fact preserves the one-to-one communication properties of ordinary micropayment channels (namely, extremely low latency), without requiring every new pair of payer/payees to wait and pay for blockchain transactions to set things up.
Such latency is degraded in other multi hop payment channel systems such as Bitcoin lightning, where micropayments seem far less feasible. In lightning, if B wants to stream money to A via a multi-hop connection of channels, a payment requires a blocking protocol where each channel in the connection must wait for the all channels closer to B to update before they can safely do so. The payment latency will therefore scale linearly with the number of hops. With virtual channels, the payment latency is independent of the number of hops.
Looking beyond web3Torrent and Filecoin, virtual channels could be the only scalable technology that provides seamless billing for the decentralized public cloud. As the payment tech matures, it offers a chance to break down the financially centralized systems we have today.
References:
[PGA99} Pagnia, Henning, and Felix C. Gärtner. On the impossibility of fair exchange without a trusted third party. Technical Report TUD-BS-1999-02, Darmstadt University of Technology, Department of Computer Science, Darmstadt, Germany, 1999.
[D+19] Dziembowski, Stefan, et al. "Perun: Virtual payment hubs over cryptocurrencies." 2019 IEEE Symposium on Security and Privacy (SP). IEEE, 2019.
https://www.youtube.com/watch?v=qUAyW4pdooA HTLCs considered harmful, Dan Robinson 2021 (Interledger)
