Micropayment take place in pay-as-you-go software service models, micro donations, and the Internet of Things (IoT). In these contexts payments for values which are usually under the smallest unit of fiat money (e.g. $0.001) are needed. Prepaid cards can solve this problem. Another approach uses cryptocurrencies in the blockchain, having the advantage of allowing exact real-time billing. Our focus in this post is on cryptocurrencies. We refer the interested reader to this survey for a general panorama of micropayment schemes.
Difficulties with low-value payments are that processing and transaction fees might be higher than the actual transaction amount. You wouldn’t send a payment of US$ 0.01 for a fee of US$ 0.5. The same applies to the blockchain world where transactions usually require a fee. In Ethereum the current minimum fee of a transaction is today about US$ 0.00851 which is almost the same amount as a US$ 0.01 payment. Micropayment solutions help lower the fees and make blockchain a viable payment medium for the services we mentioned above.
In this blog post we review existing micropayment solutions. We will continue the series with follow-up posts including in-depth studies of selected projects and a high-level micropayment comparison using metrics such as actual transaction fees, functionalities, etc.. This should serve as a “Guide” to answer the question: Which is the adequate micropayment system for my use case? There are many micropayment projects which are getting more and more mature these days! It is important to stay up to date.
Micropayment Solutions
Most micropayment systems share the idea of transacting many payments between two peers outside the blockchain while guaranteeing a secure way to claim the latest account balances onchain. That is the reason why offchain payments allow real-time payments with low values, since the possibility to claim final settlement gives real value to the cost-free transactions outside the blockchain. There are several ways to achieve this, and each approach has its own Pros & Cons. Another approach consists in condensing many small payments between many users into a single batched payment (this will be detailed in the second part of the post).
We will discuss the main micropayment concepts looking through the following simplified model:
Actors:
- Sender: User who transfers money – the source of a transaction.
- Receiver: User who is getting paid – the destination of a transaction.
Actions:
- Setup: Everything which is necessary before sending a transaction.
- Transaction: The process to realize a transaction between sender and receiver.
- Withdrawal: The cash out of the micropayment account balance to the user’s address
We present the concepts from a high-level Ethereum-blockchain perspective, though the logic can be realized in different ways on different blockchain technologies.
Payment Channels
Payment channels are one of the most popular micropayment solutions. The Lightning Network for Bitcoin, or its equivalent Raiden for the Ethereum network, are certainly well-known projects. These networks allow peers to send payments through offchain communication channels where the blockchain is only needed to deposit funds and withdraw account balances when the payment cycle is closed or disputes between sender and receiver must be solved.
The Payment Channel Model:
Setup: This model requires an Ethereum smart contract where the sender (and optionally also the receiver) deposits her fund. The addresses of both, sender and receiver are stored in the contract, and if there is a penalty escrow, the receiver also needs to deposit funds. The smart contract regulates the rules to close a channel.
Transaction: Sender and receiver sign mutually with their digital signature updates (labeled by a nonce) of their account balances through off-chain communication channels.
Withdrawal: To unlock the funds, either party is able to close the channel by sending the latest mutually signed update to the smart contract which distributes the funds accordingly. In a short time window, the withdrawal can be challenged by sending a more recent update.
There are two lines of research in the field of payment channels: what can be done/executed within a channel and how its nodes can be interconnected into a network. The lower end of this range are simple payment channels between two peers, while at the other end of the spectrum we “dream” of contract creation and execution within channels composed to networks via intermediaries (Generalized State Channels). There are many team working on this topic, e.g. Blockstream, Celer, Connext, Magmo, Perun, Raiden, Sprites, and more. Counterfactual just released its first MVP. There is research making use of Trusted Execution Environments (TEE) in order to replace the need to be online during challenge periods in the payment channel approach. While the payment channel is open, the TEEs maintain channel states internally, free from tampering due to the guarantees of trusted execution. Prominent examples are Teechain and Teechan.
Probabilistic Payment Channels
The origin of probabilistic payment schemes goes back to Rivest and the Peppercoin project (Rivest & Micali). Since that system still must assume trusted third parties to run the protocol, blockchain is a promising candidate to overcome this trust assumption. Payments are implemented on the basis of expected value of probabilistic payments, and micropayments are paid out by running an appropriately biased lottery for a larger payment. I.e., instead of paying each second US$ 0.01, a payment of US$ 1.2 goes through every minute with probability ½, so that in the long-run the expected amount is paid.
Probabilistic Payment Model:
Setup: This approach requires an Ethereum smart contract where the sender deposits tokens. This contract has an associated “puzzle”, and anyone having a solution to this puzzle can withdraw the deposit.
Transaction: The sender sends “lottery tickets” periodically to the receiver using verifiable random functions which are impossible to tamper.
Withdrawal: The recipient can send the valid ticket to the Ethereum smart contract in order to retrieve the corresponding amount.
Early work on this approach is due to R. Pass and A. Shelat (see this article, which gives at the same time a good introduction to the topic). Probabilistic Lightning, the Orchid Protocol, and Sergio Lerner´s Native On-chain Probabilistic Payment are other proposals in this field. If we compare these approaches against payment channels, probabilistic payments can go even beyond the unit “Gwei” and are more efficient than payment channels in the sense that there is no mutual signing nor a challenge period required. On the other hand, to be practical, the service provided must be continuous and granular enough for the probabilistic variance to become negligible.
Sidechain & Plasma Chain
In the sidechain approach, the parent blockchain is pegged to a secondary blockchain – the sidechain (see this article). A two-way peg enables interchangeability of assets at a predetermined fixed rate. Sidechain technology primarily helps to increase performance by outsourcing, but not necessarily to lower fees. BlockStream Liquid and RSK are examples of the use of sidechain technology. Plasma Chain is a special kind of sidechain technique that allows micropayments and also scalable smart contracting. A smart contract anchored to the Ethereum parent blockchain takes care to settle the off-chain transactions occurring in the Plasma child chain.
Plasma Chain Model (Layer-2):
Setup: This model needs to create the Plasma smart contract on the parent chain and a running sidechain – the Plasma chain. Operators or gateway oracles are necessary to redeem tokens in the Plasma chain, and vice versa. Checkpoints containing minimal information about the Plasma chain (Merkle roots) have to be sent to the parent chain which are used to challenge exit requests.
Transaction: After depositing tokens on the parent chain, senders receive the corresponding amount of tokens on the Plasma chain. The sender sends a transaction to the receiver on the Plasma chain and waits for the confirmation of the consensus in the Plasma chain.
Withdrawal: The Receiver makes an exit call, and the gateway prepares the redemption of tokens on the parent chain. If the request goes through the challenge period, the amount is transferred to the user’s account.
The Plasma chain approach was proposed in this article. Based on that, many teams dedicated their time to make these ideas into an easy to use and scalable solution for applications. Prominent examples are Loom Network with DelegateCall as a working example. There are OmiseGo, Plasma Cash, Minimal Viable Plasma, Plasma Debit, Plasma Snapp, Plasma Nano, Mono Plasma, Bankex or SKALE, just to name a few. See also State-of-the-Art of Ethereum Layer-2.
Batched Payments / Pooled Payments
Batched payments are useful in situations such as dividend or reward payments, that are in reality one-to-many payments. Receivers might accumulate their funds and withdraw them when they need or it makes sense to withdraw the amount.
Setup: The sender and receiver IDs need to be registered in an Ethereum smart contract containing Ids. Depending on the system, there might be operators and monitors processing and observing the protocol.
Transaction: The sender deposits tokens in the smart contract which includes at the same time the list of receiver Ids with its corresponding amounts.
Withdrawal: The receivers collect many transactions by providing a proof of payment or just by calling an operator to process the withdrawal. In the latter case, a challenge period is required to allow starting the verification game.
The advantage of batched payments is that the setup costs are low so that already for non-recurrent payments, the protocol can be profitable. Proposals are mentioned in Pooled Payments, Scalable Payment Pools, Merkle Air Drops, How to send ether to 11.440 people, but most are missing yet a secure implementation of these proposals – at least as far as we understand. Another interesting example is Lumino from RSK using delta compression.
Offchain Payments Using Relayers and Crypto Proofs
This category is similar to batched payments, but makes use of cryptographic tools which allow to verify the correct computation. The only assumption in this context is the availability of operators or relayers who process the transactions, but cryptography gives guarantees that no wrong information can enter the blockchain.
Setup: This approach might require a ceremony to setup the zk-SNARK cryptographic tool, make use of other protocols like zk-STARKs or any other convenient Verifiable Computation (VC) protocol. Senders and receivers register their addresses and balance accounts (plus a nonce for updates) in an Ethereum smart contract. Relayers are needed to batch transactions and send updates to the blockchain. The sender has to send a transaction to the smart contract in order to have a positive account balance.
Transaction: A sender broadcasts a transaction and a relayer gathers many of them and produces a zk-SNARK proof that transactions are valid (e.g. transaction amount is smaller than balance account, etc.), together with a proof of a correct update of account balances.
Withdrawal: The receiver can call the Ethereum smart contract in order to withdraw from its account providing a proof of account balance (Merkle proof).
Vitalik’s zk-SNARK approach uses two Merkle trees to store account balances and account ids in a contract, and users receive the Merkle branch to deposit and withdraw from their accounts. A very recent proposal in this line of thought is reported in this post using zk-snarks and rollups. Liquidity Network is working on an implementation of the NOCUST protocol – a commit-chain using zk-SNARKs for regular checkpoints. Beyond that, there are ideas of SNARK based sidechain for ERC20 tokens and PlasmaSnark which replace the Merkle proof by SNARKs.
Thinking outside of the Bitcoin or Ethereum world, blockchains like EOS which runs a different consensus mechanism, can offer lower fees. Scalable blockchains are solutions, but there are security assumptions to be considered.
