Ethereum Watch

This article, the last in a series of three, provides a brief overview of some of the off-chain instruments that developers are building in order to scale blockchains. Be sure to go back and read part one and part two.

Currently, the leading blockchain networks (in terms of number of users) process information too slowly to service a mainstream user base in the billions, or even in the tens of millions. While cryptocurrency has captured the public’s attention, many of the entities interacting directly with blockchain networks are still hobbyists, ideologues, and technologists. As Ethereum founder Vitalik Buterin himself recently noted, the Ethereum network is currently too “unscalable” to support, say, a widely-used ridesharing mobile application.

In other words, blockchains may eventually become an integral part of our infrastructure, but they will only get the chance to play that role after scaling up to become many times more powerful than they are today.

State Channels

Readers who remember part one of this series will recall the concept of payment channels, which are multi-signature wallets or contracts that allow users to send funds back and forth (within parameters) without needing to settle those transactions on the main chain. Even the most cursory survey of second layer solutions would be incomplete without a mention of state channels, the umbrella category under which payment channels fall.

While a payment channel only allows for the transfer of funds, users of a state channel can also make non-monetary changes to the state of a ledger without needing to individually record each change to the base layer. These channels, in other words, can support both financial and non-financial applications of blockchain technology.

Ledger Labs founder Jeff Coleman, who is credited as the first to theorize the mechanism, envisions a “judge” contract that would adjudicate on the actual state of a channel before that state is recorded to the main chain in the event of a disagreement. He appears to anticipate that conflicts over a channel’s state will not arise often, however, meaning that the adjudicating contract would only be called in exceptional cases.

Atomic Multi-Path Payments (On the Lightning Network)

Now back to payment channels: In part one, I discussed how webs of interconnected payment channels can form Lightning-like networks (I use this term because there are several Lightning networks) that allow users to send funds across multiple payment channels to recipients with whom they do not have a channel open directly.

In a February email, Lightning Labs‘ chief technology officer and co-founder, Olaoluwa Osuntokun, and head of Cryptographic Engineering, Conner Fromknecht, suggested a novel use for Lightning networks: the atomic multi-path payment.

This scheme allows a payment to be automatically broken into pieces and prevents delivered payment fragments from being withdrawn until the entire amount is available to the recipient. By doing away with the need to send funds in a lump sum, it eliminates the requirement that a payment path be made up entirely of high-capacity channels.

Large transfers tend to make payment channels less useful because they leave the funds in those channels skewed toward one party. When this happens to too many payment channels, more channels must be opened and/or funds must be deposited into existing channels to keep the network functional. Atomic multi-path payments could reduce the frequency with which channels need to be opened or topped up to compensate for channel imbalance. This would mean less funding being spent on main chain transaction fees in the name of maintaining network utility, and therefore lead to a reduction in costs associated with using the Lightning Network.

The scheme would also enhance user privacy by keeping intermediary senders (those simply forwarding along a payment) from identifying the ultimate sender, the ultimate receiver, and the total amount of funds transferred between those two parties.

And, the authors relate, it “can be used to pay a receiver in multiple currencies,” which, they point out, “is pretty cool.”

Plasma Cash

Part two of this series covered Plasma. Around the time that article was published, Ethereum creator Vitalik Buterin spoke at the Ethereum Community Conference in Paris where he discussed a derivative scaling solution, which he referred to as “Plasma Cash.”

Plasma Cash builds on the basic tree-like structure of Plasma but incorporates several other features as well. The most notable of these is a mechanism in the main chain EDCCs (aka smart contracts) that establish the rules that will govern the set of Plasma blockchains. Whereas the Plasma systems proposed in the past would create an “arbitrary unit of Plasma Ether” when users deposit Ether tokens into a Plasma contract, Plasma Cash contracts would create tokens within the Plasma network that are linked to unique strings of characters, which act as IDs.

Without getting too deep in the weeds, it’s important to note that in the Ethereum network, some data relating to transactions are compiled into a data structure known as a Merkle tree. In a Plasma Cash system, a transaction that spends a coin with a certain ID cannot be arbitrarily included “anywhere in the [Plasma] Merkle tree;” instead, it must be specifically recorded in the position corresponding to that coin’s ID.

The primary benefit of this feature is that it dramatically reduces the amount of data that clients are required to store. Earlier Plasma proposals required that every user of a given Plasma blockchain download every one of that chain’s Plasma blocks. Plasma Cash users, on the other hand, would need to verify the “availability and correctness of the Plasma chain” only at the positions in the Merkle tree that correspond to “any coins that they own and any coins that they care about.”

To send funds using such a blockchain, one must also send “proof data” of those tokens’ histories to prove ownership over them. Periodically “checkpointing” the state of a Plasma chain on the main chain would allow the reports of these histories to be abbreviated, so that only proof data that has been generated since the last checkpointing exercise needs to be included for a transaction to be processed.

Buterin named several benefits of adopting such a system, including the fact that malicious actors in earlier Plasma proposals could theoretically steal from the pool of tokens deposited to the Plasma contracts. Hackers in a Plasma Cash world would have to steal specific tokens from specific entities, which is much harder to do, considering that each coin’s history is recorded individually. Also, a cryptocurrency exchange built atop Plasma Cash could provide order matching services without taking custody of users’ tokens, which could drastically reduce the risk of large-scale thefts by leaving customers in constant possession of their own funds.

Thanks for Reading

Like so many other features of the blockchain space, these second layer solutions are works in progress, powerful ideas whose potential has, for the most part, been only partially realized. But the work to advance these solutions continues every day, and while there are plenty of skeptics who doubt that any of these technologies will pan out, a great many people remain optimistic about the blockchain’s promise.

If this technology ever does get off the ground in earnest, it may very well be thanks to several second layer solutions, rather than to any single one. And of course, by the time that happens, the descriptions offered in this series may be outdated.

It is my hope that these articles have given readers not only a better understanding of a handful of specific second layer protocols, but also a broader sense of the progress that will be required to bring blockchain technology fully into the mainstream.

Adam Reese is a Los Angeles-based writer interested in technology, domestic and international politics, social issues, infrastructure and the arts. Adam is a full-time staff writer for ETHNews and holds value in Ether, Bitcoin, and Monero.

ETHNews is committed to its Editorial Policy

Like what you read? Follow us on Twitter @ETHNews_ to receive the latest second layer, blockchain or other Ethereum technology news.