Ethereum Lightning Network and Beyond

This post is about building payment channels (like the Bitcoin Lightning Network) on Ethereum. I cover some motivations for payment channels, a brief non-technical description of the Bitcoin Lightning Network, and the massive benefits and potential of building payment channels on Ethereum. This post is more for the general reader, it is not a technical deep dive.

Bitcoin Payment Channels

Initial Motivation

To send bitcoin to someone you create a transaction, cryptographically sign it (proving you created it) and broadcast the transaction to the Bitcoin network. Nodes on the network called ‘miners’ confirm your transaction, putting it into a block, and they broadcast that block to the rest of the Bitcoin network, thus confirming and securing your transaction. In exchange for this work miners get paid in bitcoin. Part of that payment comes from small transaction fees that you include when you build your transaction. This, along with the block reward, is the economic incentive that keeps the network running and secure.

As Bitcoin adoption grows the number of transactions that occur on the blockchain increase. Currently a block can hold up to 1MB of transactions and so under perfectly contrived conditions Bitcoin could support around 10 transactions per second. A more realistic limit is 5 to 7 transactions per second, and currently the network has been averaging around 1 to 3 transactions per second (the limits are actually averages as well since block creation is probabilistic and follows more of a Poisson distribution than a rigid 10 minute interval, depending on the time interval selected Bitcoin can look to be supporting higher numbers).

The transactions per second limit will increase if the blocksize is increased (either through changes to Bitcoin Core or through support for XT) but this change only gets us so far. Visa peaked at 47,000 transactions per second in 2013. That is 4 orders of magnitude higher than Bitcoin. Visa is able to achieve that because it is a centralized system. Decentralization may be one of the properties that gives Bitcoin its strength and revolutionary potential, but it also makes it difficult to scale.

Along with the scaling problem there is the problem of micropayments. Making small digital payments has not been possible due to the cost of transactions. This is one reason there is usually a minimum purchase amount required to use a credit card. You can’t use Visa to send a penny to someone, let alone fractions of a penny. But there is great potential in micropayments and many feel Bitcoin can enable that. The problem is that at current prices a Bitcoin transaction costs around 2 to 3 cents, which is far cheaper than the fees for the existing financial system but still not cheap enough to enable micropayments (Bitcoin transaction fees are based on the size of the transaction, not the value it carries, which is fundamentally different from the existing fincancial system).

A final problem facing Bitcoin is the 0conf (or instant payment) problem. Bitcoin transactions are relayed to the entire worldwide network in seconds, but they are not confirmed until they are included in a block. Due to the random nature of block creation and the economic decisions of miners this process can sometimes take an hour or so (but usually averages around 10 minutes).

The 0conf problem is not essential to solve, since chargebacks can occur with credit cards months after a payment was made and payment processors have ways to detect the extremely rare double spend attempts quickly. While not crucial, solving 0conf would still bring value. Micropayments are also not a problem that has to be solved, as no other system has been able to make micropayments a reality so there isn’t any competition here. Enabling micropayments would open up many new markets and create value, so again it would be beneficial to solve. The scaling issue is a problem that must absolutely be solved. If Bitcoin cannot scale, then it will fail to be useful.

Overview of Bitcoin and Payment Channels

Payment channels is a proposed approach to solving the Bitcoin scalability, micropayment, and 0conf problems. The idea is to have transactions occur directly between participants rather than sending transactions on the blockchain, using cryptography to secure messages and using the blockchain only as a settlement mechanism if needed. There have been a handful of payment channel ideas put forward but the most well known in the Bitcoin community is the Lightning Network.

The Bitcoin Lightning Network is motivated in part by how the current electronic financial system works. The goal is to take all the lessons learned there, and apply what makes sense to Bitcoin. While this is not a technical post, in order to understand the benefits of building payment channels on Ethereum we have to cover at least a high level description of the Bitcoin Lightning Network.

Current Payment Authorization Process

credit-card-payment-authorization

A Bitcoin transaction is made up of a few components, we’ll simplify them for this discussion:

  1. A pointer to a previous transaction where someone had sent bitcoin to you (to an address you have the private key for)
  2. The address you are sending bitcoin to (actually a locking script)
  3. A cryptographic signature proving you ‘own’ the bitcoin to be spent and that you created the transaction

transaction-anatomy

Sending this signed transaction directly to the recipient rather than broadcasting it is almost as good as the payment itself. The only problem is that as long as the transaction isn’t in the blockchain you could choose to send those bitcoin to someone else.

Bitcoin transactions are extremely flexible. Two people can decide to each put some bitcoin into a single transaction that can only be spent if they create a new transaction that both of them cryptographically sign. This is called multisig or pay-to-script-hash, and this is what payment channels build on.

If Alice and Bob wish to create a payment channel between them, one or both of them would put bitcoin into a special multisig transaction and broadcast that to the network. They then create and sign a new transaction that sends the original amounts back to them, but which can’t be used until a later date (say 30 days into the future). When they need to send money to each other, they create new transactions which change the amount of bitcoin sent to them, and shorten the time the transactions can be spent (29 days, 28 days, etc…) so the most up-to-date changes can be broadcast to the network first.

Payment Channel Creation and Progression

channel-payments

Since these messages are just passing between Alice and Bob, they shrink the number of transactions on the blockchain, allowing it to scale. They also work as instant payment, solving the 0conf problem and since there is no fee they can be any denomination thus allowing micropayments. The only time transactions actually need to be broadcast to the network is when Alice and Bob wish to close out the channel or if one of them stops cooperating (at which point the other would wait until the most up to date transaction could be spent and broadcast it, sending the proper amount of bitcoin to both of them).

But this is only between two actors. What makes payment channels truly useful for Bitcoin is chaining them together. If Alice and Bob have a channel, and Bob and Carol have a channel, then Alice can pay Carol through Bob. Bob may take a small fee, but that can be much smaller than the blockchain fee. We won’t go into the details here, but this can all be done without having to trust Bob, by adding some more rules to the transactions. These new rules don’t exist in Bitcoin yet, but they may someday.

Sending Payments by Chaining Channels

chaining-channels

If some actors become ‘hubs’ that have channels open with many others (think Visa, Banks, Financial Institutions) then we begin to see the buildup of a full payment network allowing someone to send a payment to anyone through this network rather than having to broadcast a transaction or open a new channel with them.

Chaining Channels Creates Payment Networks

payment-network

Blockchain as Settlement or Programmed Adjudication

This system turns the Bitcoin blockchain into a mechanism for designing the rules of a financial relationship and then acting as programmed adjudication or final settlement, reducing the need to appeal to human institutions. The blockchain starts to become a programmable social contract which enables trust and financial interaction between parties at a very low cost.

Payment channels don’t make sense for everything. For large, one-time transactions such as buying a house or car, normal Bitcoin transactions should be used. But for entities that shift money back and forth frequently, such as banks and financial firms, payments channels make sense. When you allow payments to ripple through multiple channels, you enable a system where consumers have payment channels with banks, rather than bank accounts, and payments to merchants flow through many parties through direct message passing, much like our financial system today. Existing financial systems rely on trust so they have to be heavily regulated to ensure consumers are not completely abused (our system is pretty bad today, so just imagine how bad it would be without such regulation). But with payment channels on Bitcoin the duties of regulation can be shifted to the blockchain, a more perfect and transparent adjudication and fraud protection system.

Presentation by Joseph Poon and Thaddeus Dryja on the Bitcoin Lightning Network

Payment Channels on Ethereum

The Bitcoin Lightning Network is very promising, but it can’t be built on Bitcoin today. There are some difficult problems that need to be resolved (such as transaction malleability) and some additional functionality that must be added to the protocol. Ethereum is a next generation cryptocurrency which uses accounts with balances instead of transactions as the foundational objects and also includes smart contracts as first order objects (rather than having to be built up through chained transactions). Not only does this mean Lightning Network style payment channels could be built on Ethereum today, it also means more powerful features can be built with them.

With Ethereum you would build the Lightning Network and its rules in a smart contract. If Alice and Bob wish to create a payment channel between them, one would create the channel and the rules, and the other would ‘join’ it. Messages which contain updates to the states of this channel would be created, signed, and passed directly between them. If Alice needed to close out the channel, she would call a function on the smart contract with a signed state message. This would initiate a settlement period where Bob could either confirm the state, send a more up-to-date signed state message, or wait for the settlement period to end. Then the channel is closed out and their funds are released to them.

In the Bitcoin Lightning Network, when payments are sent through multiple channels those messages actually hold up the advancement of the channel until all actors have done their parts. This is not ideal for the hubs in the center of a payment network. Visa processes tens of thousands of transactions a second, so if these payments take even a fraction of a second, that is far too long. The big players could mitigate that by opening up multiple channels between each other, but that starts to become extremely complex and increases the number of initiating transactions that have to hit the blockchain.

On Ethereum payments going through multiple channels can be managed with special encumbrance messages that are not updates to the channel state messages but exist along side them. These encumbrance messages can be written as deltas of the channel state. This means a channel could be updating while sitting on many encumbrance messages waiting to be resolved. When an encumbrance message gets resolved, it can be included in the next state updating message, along with proof it was used. When a channel gets closed out, any outstanding encumbrance messages which haven’t been included can be added during the settlement phase. There are some dangers with this approach, as accounts can go negative if the actors allow it, but that turns out to be a feature rather than a bug (see below).

The Bitcoin Lightning Network would exist on top of the Bitcoin network, not within it. This means that it requires its own infrastructure and protocols. In order to pay someone you don’t have a direct payment channel with, there would have to be a way for detecting hubs and their connections, much like the routing protocols already in use on the Internet. Hardware going offline would be an ever present concern. With Ethereum the discovery process could exist entirely within Ethereum. A contract could list existing hubs and channels as well as their connections and fees. This may not end up being the best way to do it, but it is a faster way to bootstrap what will be incredibly complex in Bitcoin. Such a contract could also just be a list of hubs and a pointer to a resource hosted elsewhere (on IPFS, AWS, or your home server or crypto node) that details the hubs offerings. There is a lot of work to get this kind of routing to function effectively, so reducing that complexity with Ethereum is a huge advantage.

Bonus Features on Ethereum

Adding Funds to an Existing Channel

When we look at what would be the edges of the Bitcoin Lightning Network, we see something that looks similar to a bank account today. So instead of Alice and Bob let’s use Alice and Bank. Alice and Bank can create a payment channel where only Alice puts money in, and then she uses offchain messages to ‘send’ her bitcoin to Bank, which routes the payments through more channels to Credit Union and eventually to Department Store where Alice just purchased something.

This works well as long as Alice can get ‘paid’ through her Bank, but only if she ever gets paid less than what her Bank is holding on its ‘side’ of the channel. Also, if she ever gets bitcoin through some other entity, she can’t deposit it without creating a new channel. With Ethereum Alice can. It still takes a transaction but Alice could send funds directly to her ‘side’ of the channel, increasing the total funds in the channel. She would include this in the next signed message and the Bank can check the smart contract to confirm her added funds really are there.

Pulling funds out while a channel is open is still problematic but I think if it was really important there may be a few ways to allow for that kind of functionality. But I think the safest approach would always be to close out the channel and open a new one rather than allowing such functionality.

Deposit vs Credit Channels

Ethereum allows us to make the deposit style channel between Alice and Bank more like a traditional bank account by allowing Alice (or the Bank) to add funds to the channel while it is still open. But most of us in the developed world also have credit cards which allow us to spend money that we don’t ‘deposit’ until later. And banks can allow people to withdraw more money than they have (usually applying a horrendous fee in the process).

Ethereum payment channels would allow for balances in one direction to go negative, if both parties agree to it. This way a payment channel could mimic more of a credit card relationship than a banking relationship. This wouldn’t create funds, no more than what existed in the channel would exist, but it would be a way of tracking payments made through the payment network on Alice’s behalf (to be paid later). If Alice vanished before getting her balance to 0, the Bank would be out whatever they sent on her behalf to other actors in the network. Entities like Bank could treat these payment channels like a hybrid bank account/credit card. When Alice has a positive balance, Bank may send interest payments her way. When Alice has a negative balance, the Bank may charge her interest.

Subcurrency Inclusion

Ethereum makes it very easy to build your own cryptocurrencies (subcurrencies) on top of it. This is also done using smart contracts. The benefit is that subcurrencies get security from the entire Ethereum network rather than having to run their own blockchain, nodes, and miners. While a Lightning Network could be created for ether (Ethereum’s native token) it could also just be included in the smart contract that creates any subcurrency. Payment channel networks can be ‘baked in’ just in case they are ever needed.

Multiparty Channels

So far we’ve just talked of channels as existing between two actors, but it is possible to create channels with three or more actors as well. This could be doable in Bitcoin as well, so it isn’t a feature that will be unique to Ethereum, but it would be much easier to do in Ethereum. These multiparty channels could be set up so that all actors have to sign each change to the underlying state, or they could be initiated such that a subset of actors (m of n) are needed to sign to have a valid new state.

What could be done with multiparty channels? Blockstream recently announced the release of Liquid, their first production sidechain. Liquid is a private blockchain that participants (currently only major Bitcoin exchanges) can use to send bitcoin instantly to each other, thus solving the 0conf problem for them. However sidechains are an extremely complicated and untested solution, and the Bitcoin protocol still needs more changes before Blockstream’s full two-way pegged sidechains can exist. Large financial institutions are exploring private blockchain technology to tackle similar issues. A multiparty channel could offer much of the functionality as the Liquid private sidechain, and do so with much less complexity and would be secured by the native blockchain.

Jumping outside of finance it would be interesting to run a game on a smart contract, but even Ethereum’s short block time is far too long for game progression. It would also be prohibitively expensive to have to pay tiny amounts of currency for each move. But with a multiparty channel this becomes feasible. Initial game state information could be recorded in the smart contract and then game progression would occur by the participants passing messages directly between themselves. Having to check message contents against expectations and continuously cryptographically sign them would be a cpu intensive act, but with good game design the time to do so could be low enough to allow for consensus gameplay.

This opens up a plethora of uses for payment channels. In fact it may not be proper to call them payment channels anymore. The Ethereum whitepaper discussed Bitcoin as a state transition system and explained Ethereum with this view in mind. What we see here is that payment channels on Ethereum can also be seen as state transitions, so it might be more accurate to call them something like ‘multiparty offchain state networks’.

multiparty

Multiple Asset Channels

Nasdaq is working on using blockchain technology for things like trading assets, and t0 is a blockchain based equities trading platform. Not only could payment channels (or ‘multiparty offchain state networks’) work for any digital asset represented in a smart contract they could work for contracts which hold multiple digital assets. In other words, one smart contract could hold currency (ether or a subcurrency) as well as digital tokens representing shares in a company. Having channels or networks with multiple assets is the makings of an entire financial exchange on smart contracts.

Blockchains are awesome technology for any domain where you have many participants who need a shared trusted database, but a big hurdle to adoption has been the speed and variability of transaction inclusion (or block creation, called ‘mining’). Multiparty offchain state networks provide a solution to this problem and could open the doors for greater blockchain adoption.

Caveats

There are still plenty of hurdles to tackle for both the Lightning Network on Bitcoin and anything similar on Ethereum. For the Bitcoin Lightning Network, actors in a channel incrementally shorten the time a transaction can be placed on the blockchain when they update their balances. This ensures that older transactions can’t be broadcast before the more up-to-date ones. But funds can be lost if an actor is not able to close out the channel by broadcasting the latest transaction in time. This could be for technical reasons on their end, or it could be for blockchain related issues such as a backlog of transactions waiting to be included (which occurs when blocks are full or when there is a surge in transactions).

The same problem could occur on Ethereum during the settlement period, although the settlement period solution is more robust as there is a window that is set by the channel rather than a hard deadline. A malicious actor could initiate a settlement period, using an outdated message that is heavily in their favor, and spam the Ethereum network in the hope of preventing the other actor from submitting a more up-to-date message. This threat can be mitigated by having a sufficiently long settlement period (which can be set by those creating the channel).

While payment channels have been proposed as a way of finally enabling micropayments, and I think they are the best approach so far outside of centralized services, I am skeptical about whether they will actually be able to accomplish this. Transferring value ultimately costs something, it isn’t free. With a physical good like gold the cost is proportional to the amount being transferred, but with digital representations of value the cost is more or less fixed per transfer, regardless of the amount. This means there is probably a lower limit to how much a transaction can cost, but I have no idea how close we are to that limit. Centralized services seem to be able to get very close to 0 cost, but at the expense of being a service that must be trusted. In order to make payments to anyone with the Bitcoin Lightning Network you have to go through ‘hubs’ that may exist purely because they can charge fees. How much cheaper will those fees be than the Bitcoin transaction fee?

This begs the question: what really is a micropayment after all? Is it sending subdollar amounts? Is sending 25 cents a micropayment? Sending a penny? Or does it have to be fractions of a penny? And what percentage does the fee have to be in order for us to consider it feasible? Everyone seems to have different answers to these questions. But whatever the answers, my feeling is that we won’t be able to get transactions much cheaper than a few cents, even with payment channels. Another suggestion proffered is that hubs may exist to gather and monetize user data. If this works out then perhaps micropayments may become feasible after all.

State of Development

ConsenSys is an Ethereum powerhouse that seems to be developing every product imaginable, so it should come as no shock that they seem to be working on offchain transactions as well. I don’t want to read too much into such a short post, but they are working along similar ideas of having more than two actors in a channel and they seem to have converged on the same settlement idea (they call it a challenge period) as a better solution to the Lightning Network’s OP_CHECKLOCKTIMEVERIFY and OP_RELATIVECHECKLOCKTIMEVERIFY or OP_DEPTHLESSTHANVERIFY approach. An interesting idea they also mention is a punishment in the form of losing a deposit for any actor that submits a state only to have someone else submit a more up-to-date one during the challenge period. Since ConsenSys is well funded and can devote full time development I would expect them to have something ready relatively soon. I have seen a few other people mention working on similar ideas as well.

There is a big difference between payment channel ideas on Bitcoin and Ethereum, as this post should have made clear. With Bitcoin, payment channel solutions will all be essentially competing with each other as their only purpose is to assist in the transfer of bitcoin. While it could be the case that multiple payment channel solutions for transferring ether as a currency could exist and compete with each other, that is a minor benefit of payment channels on Ethereum. Multiparty offchain state networks will have their greatest impact by being incorporated in individual smart contracts for subcurrencies, games, financials networks, and so on. On Ethereum these networks could become a standard part of the technology offered in Dapps built on smart contracts. The properties of each implementation will be specific to the needs of that smart contract. In this sense there won’t be a market ‘winner’ for competing payment channels, but instead there may be a vibrant community of development contributing to extending the use and functionality of multiparty offchain state networks.

Conclusions

While payment channel solutions like Lightning Network were proposed mainly to solve the scalability problem with Bitcoin, that may end up being a very minor part of what they enable. The idea of payment channels can be extended to what I’m calling ‘multiparty offchain state networks’ (or the less cumbersome ‘offchain state networks’) if built on the smart contract technology of Ethereum. This generalization greatly expands the domain they can be useful in, and we may see them become standard components of Dapps and services ranging from subcurrencies and games to financial systems.


References

Lightning Network Whitepaper
Strawpay Whitepaper
Bitcoin Wiki – Max Transaction Rate
Visa Blog – Transaction Stress Test
Blockstream Blog – Liquid Private Sidechain
Sidechains Whitepaper
American Banker – Blockchain Startup Gains Backing from 13 Big Banks
New York Times – Bitcoin Technology Piques Interest on Wall Street
Bloomberg – Blythe Masters Tells Banks the Blockchain Changes Everything
Financial News – Nasdaq: Our Plans for the Blockchain
Ethereum Whitepaper
First Data – Payments 101: Credit and Debit Card Payments – Whitepaper

Payment Channel Proposals and Implementations

Lightning Network
Elements Project LN
Strawpay
Bitcoinj
Thunder Network