Blockchains: Where are we now?
We are seeing an exponential increase in value for market prices.
Around 20,000 USD (16,280 2017/12/27), was around 2500 USD in 2017/1/1
Now around 700 USD, was just over 8 USD in 2017/1/1
So it’s obvious that there is a lot of interest in blockchain technology.
Crypto-currencies are popular in the markets but not yet popular for everyday use – why not?
This article will explore some of the technical barriers preventing widespread use.
Problem #1 Scalability
Perhaps the most obvious bottleneck is scalability, by which I mean throughput. This determines how many users can use the system simultaneously.
Consider the real-world payment system VISA. It currently handles on average around 2,000 transactions per second (tps). It has a peak capacity of around 56,000 tps. So VISA is clearly not ready.
Compare this to Bitcoin’s throughput of less than 10 tps and Ethereum’s throughput of less than 25 tps. Neither of these currencies are anywhere near a real-world payment system such as VISA.
Taking our comparison further, imagine a quarter of the world’s population of 7.6 billion (1.9 billion) uses an imaginary blockchain. If we imagine 1.9 billion make one transaction at randomly throughout the day we get about 223,148 transactions per second. Our imaginary blockchain will need to support over 223,148 tps to account for peak fluctuations, say 2,000,000 tps. This is five or six orders of magnitude over Bitcoin and Ethereum’s current capacity!
Problem #2 Latency (confirmation time)
When using your favorite crypto-currency to buy an everyday item such as a cup of coffee, confirmation time needs to around 1 second for a smooth user experience.
Since for Bitcoin it is recommended to wait 6 blocks to be sure of transaction finality in the blockchain, and there is a new block created every 10 minutes. This gives us a best case around 1 hour. Ethereum is a little better (for an equivalent level of confidence we need 12 blocks) at around 3 minutes (12 blocks * 15 seconds).
However both of the top currencies best case times are orders of magnitude more than the 1 second required for a smooth user experience.
But these are ideal times. After a user broadcasts a transaction it enters into a pending state, waiting to be included into a block. During highly congested periods time spent in the pending state can stretch to multiple hours.
This “pending” time needs to be added to the ideal time above to get the real confirmation time. This can result in confirmation times of multiple hours, clearly unsatisfactory for a smooth user experience when buying a cup of coffee.
Problem #3 Cost of transactions
Transactions on the Bitcoin and Ethereum blockchains are not free. User’s pay a fee which goes to the miner of the block the transaction is included into. This rewards miners for processing transactions. Users can pay as much as they like to ensure their transaction gets processed by a miner in a timely fashion.
In order to support small transactions such a buying a cup of coffee we want transactions costing a few cents or less. A user is not going to pay $10 USD for his coffee transaction, given that the coffee only costs $6 USD. For micro-transactions supporting IoT for example, we need transactions to be small fractions of a cent.
Currently for Bitcoin transaction fees are over 20 USD (bitcoin-fees-are-skyrocketing)
For Ethereum we see transfer fees at around 4 cents, but much more for transactions involving Ethereum’s flagship, smart contract processing, and writing data on the Ethereum blockchain is expensive, currently around $0.076/KB or $76,000/GB (what-is-the-cost-to-store-1kb-10kb-100kb-worth-of-data-into-the-ethereum-block)
Problem #4 Enviromental Cost
Bitcoin uses about 14.54 TWh per year, and Ethereum uses 4.2 Terrawatt-hours of electricity per year (bitcoin-ethereum-mining-use-significant-electrical-power).
Bitcoin’s annual electricity use is between Serbia and Denmark, Ethereum’s is between Cyprus and Brunei.
These figures should perhaps be taken with a pinch of salt since they are based on figures published at http://digiconomist.net, recently questioned by Jonathan Koomey, a Stanford University lecturer. But even if the energy consumption is an order of magnitude less, it is still environmentally significant.
Why are Blockchain Transactions so Costly?
– Blockchains are based on consensus and consensus is expensive, especially Proof of Work. Consensus requires the cooperation of the majority of nodes in the network. Consensus takes place on creation of a new block about once every 10 minutes for Bitcoin and once every 15 seconds for Ethereum.
– Every full node in the network processes every transaction (as part of verification) and keeps a full copy of the blockchain forever.
– Gas and transaction fees are boosted by many urgent high value transactions. Since the miners keep the fees, miners choose transactions with higher fees first and they get processed quicker. So Congestion in the pending queues will push the transactions fees upwards.
– Blockchain transactions are expensive, we need a cheaper way to make payments
What are the basic parts of a blockchain transaction? Can Alice make payments to Bob without broadcasting to the blockchain?
– Looking at Satoshi Nakamoto’s original white-paper we see the white-paper is divided up into 2 main parts: describing how individual transactions themselves might work, then how to ensure transactions are correct within the context of all transactions.
And looking at Satoshi’s original diagram for a coin flowing through 3 owners we can feel reasonably confident that individual transactions can implemented without a blockchain.
Payment Channels (State Channels)
Payment Channels are a method for off chain payment: they are a way for Alice to make individual payments to Bob without using the blockchain.
Payment Channels are a way to connect a Sender and Receiver (Alice and Bob) and generally follow the stages below:
- A channel is opened and an initial deposit is made into a Channel Contract (on chain)
- Two parties exchange signed balances on the deposit (off chain)
- The Channel Contract is asked to close the channel using the latest signed balance (on chain)
In the case of a one-way channel between Alice and Bob:
First, Alice set’s up the payment channel: she deposits into a smart contract representing the Channel. This takes place on the blockchain.
Secondly, the Alice makes as many payments to Bob as desired by digitally signing a proof of balance dividing the initial deposit appropriately between Alice and Bob. All of these “payments” take place off the blockchain and incur no blockchain related cost. The main costs incurred are the processing cost for the digital signature and the sending of the payment across the network. Both of these costs are negligible and this is the key point for the scalability of payment channels.
Thirdly, Either Alice or Bob initiates closing of the channel by calling a method on the Channel Contract holding the deposit and passing the latest signed proof of balance. The Channel Contract divides the deposit as set in the proof of balance between Alice and Bob.
So, in summary we have 2 on-chain transactions and countless off-chain transactions. Thus the on-chain transactions can be shared across the many off-chain transactions. We want a high number of off-chain transactions to minimize individual transaction costs.
Payment Channels can be one way or two way.
They are sometimes called Layer Two solutions.
Payment Channel implementations
Payment Channel implementations are in the late development phase. 2018 will probably see the first use-cases appear in the wild. The first widely known payment channel implementation was Bitcoin’s Lighting Network. This is 2-way and many to many, meaning that Alice may be connected to Bob and others and everyone may send and receive.
Following Lightning the Ethereum community quickly implemented the Raiden Network, based on Lighting, it’s also 2-way and many to many.
Both of these networks are intended to allow large numbers of users connect to any other user on the network via ad-hoc routes made across existing payment channels.
For example imagine that Alice has a channel opened with Bob and Bob has a channel with Charlie.
Alice can pay Charlie if Bob takes Alice’s payment and relays it to Charlie.
This is an ad-hoc route from Alice to Charlie through Bob.
Both Lighting and Raiden use Hashed Time-Locked Contracts (HTLC) to allow payments across multiple hops (eg. From Alice to Bob to Charlie), without the risk of intermediaries stealing the payment in transit. Very simply put, this means that in the above example Bob can receive payment from Alice, only after first paying Charlie. Intermediary nodes such as Bob are incentivized to by micro-payments for their services.
– µRaiden is one way: payments are from `Sender` to `Receiver`.
`µRaiden is an off-chain, cheap, scalable and low-latency micropayment solution`
– Inspired by same ideas as the Raiden network. The Raiden network will use µRaiden to pay intermediate nodes for their routing services.
– µRaiden is a many-to-one state channel solution
– µRaiden will be used in the Raiden Network for incentive fee payment to intermediate nodes.
– Payments are one way, from Sender (user) to Receiver (Service Provider)
– Payments are a `proof of balance`, signed by the Sender and given to the Receiver
– The Receiver verifies the Sender address and checks the new balance is correct
Closing a channel
wikipaydia Paywall Demo
You may use the wikipaydia.py example provided to implement your own paywall protected site.
For example I used this file as a basis to create a test paywall around this blogsite:
Other Changes to wikipaydia
This blogsite contains absolute links to the individual blogs. If these links are clicked they will lead out of the paywall directly to the blogsite, bypassing payment. So I needed to substitute relative URLS for absolute URLs. This stops users from escaping the proxy, but takes time to process, slowing page display slightly.
Progress as of December 2017
Currently µRaiden contracts are on the Ethereum mainnet
Raiden Network Roadmap
Bitcoin’s Lightning has the necessary changes to bitcoin itself in place, but seems to be at least a year away before release to the general public.
State Channel Drawbacks
- Participants need to be online at all times to monitor settlement periods etc. We may see hubs as services taking on this responsibility on behalf of users.
- For payment channel networks, can only pay as much as exists in the minimum balance channel. Lightning Network has a maximum allowable payment
- Signing each transaction manually is OK for a demo but incurs a per transaction mental cost
- State channels are protocols for off-chain transactions.
- They consolidate multiple off-chain transactions into 2 on-chain transactions, helping with throughput, latency, cost, environmental impact
- They facilitate micro-payments
- µRaiden is an implementation of a one way, many to one state channel
- µRaiden enables creation of paywalls for services