Getting Off The Chain: Are Second-Layer Solutions The Key To Blockchain Privacy and Scalability?
It has long been accepted that its capacity for trustless financial transactions is just the beginning for blockchain. As the technology has developed and older research papers have been supplanted by newer protocols and systems, the focus has shifted to expanding the capabilities of blockchain and its reach in society. However, while blockchain is gaining more traction, basic issues of privacy, confidentiality and scalability continue to limit the usefulness of its applications.
Second-layer, or off-chain, scaling solutions are often billed as the remedy to the scalability issues faced by blockchains. In the most basic terms, off-chain protocols allow two users to perform private transactions off the chain with only the last updated state of transaction added to the blockchain.
This should greatly reduce the load on the network and allow for faster and cheaper transactions. However, as noted by Christian Decker, “Building on the blockchain, we inherit the inherent problems of the blockchain and build additional complexity on top.” While these solutions have the potential to genuinely extend blockchain’s capabilities, there are still trade-offs that need to be considered.
Fast as Lightning
While much of the work currently being undertaken in the blockchain space involves second-layer solutions to some degree, the question of whether off-chain solutions are genuinely useful still persists.
It would be remiss to discuss off-chain solutions without mentioning the Lightning Network. In the paper ‘Eltoo: A Simple Layer2 Protocol for Bitcoin’, Blockstream presents ‘eltoo’ – an improvement to the off-chain update mechanism that enables payment-channel networks, specifically the Lightning Network. The original version of this mechanism uses penalties to discourage malicious actors from enforcing a false or old state by taking away their funds. However, this process is rather cumbersome.
As it stands, the negotiation of a state change involves repeatedly invalidating the prior states. However, this leaves participants with a long list of update transactions. As a result, in order to settle the transaction that you want to be broadcasted on-chain, you need to replay the entire chain of updates. This defeats the purpose of performing the protocol off-chain.
“[Eltoo] proposes a generic and penalty-less workaround of the limitations of the Lightning Networks settlement system by rebinding the final update transaction to the initial setup transaction. This means that only the last settlement transaction can be confirmed on the blockchain.”
The eltoo paper, co-authored by Christian Decker, Rusty Russell, and Olaoluwa Osuntokun, proposes a generic and penalty-less workaround of the limitations of the Lightning Networks settlement system.
Eltoo allows for the intermediary states (i.e. the chain of updates) to be skipped by rebinding the final update transaction to the initial setup transaction. This means that only the last settlement transaction can be confirmed on the blockchain. This is made possible by the fact that the inputs and outputs have matching scripts, and involves the addition of a ‘SIGHASH_NOINPUT’ flag for signatures. Essentially, this is a change to the Bitcoin core protocol which can only be included by a soft fork.
This is a particularly interesting development, because the Lightning Network was viewed by Bitcoin proponents as a solution to scalability without having to make changes to the blockchain itself (i.e. increasing block size). However, when it comes down to it, off-chain protocols are based on on-chain features. This forces us to consider, if anything, what should be added to the Bitcoin script or blockchain structure to create more efficient off-chain protocols?
Introducing Channel Virtualization
The argument could be made that we are not fully aware of the underlying capabilities of Bitcoin yet. Ultimately, the reduced script language and functionality means that there is the potential for a lot more to be done off the chain without any changes, at least in terms of payments.
State channels are an extension of payments networks for cryptocurrencies. They allow for the execution of arbitrarily complex smart contracts, while payment channels only support off-chain payments between users.
“[Perun] introduces the concept of ‘channel virtualization’ payments are routed through one intermediary payment hub that has direct channels with several parties. This overcomes the disadvantages of performing cheap micropayments in cryptocurrencies, reducing trust, latency and costs.”
Perun is a solution that has been billed as “a protocol system for building virtual payment and state channel networks”. A paper entitled ‘Perun: Virtual Payment Hub over Cryptocurrencies’ was written by Lisa Eckey, Stefan Dziembowski, Sebastian Faust and Daniel Malinowski.
It introduces the concept of ‘channel virtualization’, which negates the need for each individual payment to be routed through an intermediary. Instead, payments are routed through one intermediary who can be viewed as a payment hub that has direct channels with several parties. This overcomes the disadvantages of performing cheap micropayments in cryptocurrencies, reducing trust, latency and costs.
The ability for two actors to play a contract in the blockchain without a direct state contract has exciting implications for the scalability and wider implementation of blockchain technology. However, it’s clear that off-chain protocols have a use beyond scaling. They enable experimentation that doesn’t get pushed lower down the stack, affecting the main chain. This allows for incremental improvement to the network, when necessary.
Twitter for Your Bank Account?
While many off-chain solutions, for the most part, address scalability and latency issues, they tend not to sufficiently address the problem of privacy and confidentiality.
As one of the co-founders of Zcash, Ian Miers has done extensive work on privacy preservation in blockchain; in his view, blockchain is like “Twitter for your bank account”. In a paper co-authored with Matthew Green, ‘Bolt: Anonymous Payment Channels for Decentralized Currencies’, he presents BOLT (blind off-chain lightweight transactions) – ‘a fast private payment channel protocol inspired by the Lightning Network’.
As Miers explains, in payment-channel networks, users are essentially exchanging blockchain-enforced IOUs, and these IOUs are created and then destroyed until someone wants to cash out.
The privacy problem lies in the fact that, when a payment channel is created, the opening and closure of the channel is recorded. From this, it is possible to identify the customer and merchant, as well as the initial and final split of funds. This lack of privacy can have negative consequences and is therefore not a feasible system for payments.
“BOLT promises privacy and payment confidentiality by breaking the link between both the entry and exit point of a payment-channel network when used in conjunction with Zcash, which offers private payment only on-chain, it is possible to open a channel using shielded transactions which anonymize the connection to the network.”
BOLT promises privacy and payment confidentiality by breaking the link between both the entry and exit point of a payment-channel network. The only requirement is that the channels must be supplied with private funds. For this reason, when used in conjunction with Zcash, which offers private payment only on-chain, it is possible to open a channel using shielded transactions which anonymize the connection to the network.
Referring back to Miers’ initial analogy, in this system, the IOUs are private even to the merchant. This is achieved by the use of blind signature and commitments. The commitments allow parties to hide the value of the IOUs, and the blind signature convinces the merchant that the IOU is authentic. This is because he has already signed it. Nevertheless, it ensures he doesn’t recognise the signature or the IOU of any that he has already signed.
Depending on the Oracle
Another novel solution currently being explored and tested is Discreet Log Contracts (DLCs). MIT DCI software developer, Gert-Jaap Glasbergen, describes them as invisible conditional payments, i.e. smart contracts on the Bitcoin blockchain.
Considered invisible or ‘discreet’ because the existence of these transactions is not detailed on the public ledger, DLCs appear no different to multi-signature outputs. However, like many smart contracts, they require an external party or so-called ‘oracle’ to verify real-world occurrences from outside the blockchain and make a decision in cases of conflict.
“‘Discreet’ Log Contracts (DLCs) [are]smart contracts on the Bitcoin blockchain the existence of these transactions is not detailed on the public ledger [but] require an external party or so-called ‘oracle’ to verify real-world occurrences from outside the blockchain and make a decision in cases of conflict.”
This dependence on the oracle to provide accurate information poses a potential threat; however, oracles in DLCs are not aware of specific contracts using the data and are, therefore, unable to decide the outcome of a specific contract. The oracle independently publishes the correct signature thus enforcing the correct state. To further mitigate the risks surrounding oracles, Glasbergen proposed the use of multiple oracles and combining their signature points.
In a wider context, we may find that oracles will play an important role in the decentralized world promised by blockchain, so, while DLCs may have its challenges, its potential is undeniable.
A Pointless Pursuit?
The general consensus is that off-chain protocols are, in fact, useful not just in terms of privacy and scalability, but in what they mean for the capacity of blockchain technology and its application in industries outside of finance.
“An intriguing commercial use case for state channels is the use of automation to make policies and their definitions more accessible this would allow participants to automatically negotiate their interactions with contracts.”
An intriguing commercial use case for state channels – beyond gaming, secure file transmission and energy consumption – is the use of automation to make policies and their definitions more accessible.
This was put forward by Jeff Coleman at the Master Workshop held by the Research Institute and Binary District. In theory, this would allow participants to automatically negotiate their interactions with contracts, such as the terms of service on a website, by matching that policy to their own preset conditions.
When we consider the discussions currently being had regarding data protection and internet privacy, developments in this area could have some really interesting implications. However, while the ultimate aim of commercial blockchain implementation is the simplification of existing processes, it is itself quite inaccessible to the average person.
Many of these proposals, as technically innovative as they are, quickly become redundant if they can’t actually be used and implemented by those outside of the blockchain-savvy minority.
This also gives rise to the questions that plague all new technologies: How do you strike a balance between research and making things accessible? Should we be using what we already have or continue research? For example, provable security. Yes, it is imperative that proofs are researched and that solutions are checked for bugs before they are made public; however, user feedback is also critical to development.
“To develop deployable solutions and applications, we need to build an all-encompassing ecosystem with collaboration at each level to promote more intuitive research.”
To develop deployable solutions and applications, we need to build an all-encompassing ecosystem with collaboration at each level to promote more intuitive research. While we are seeing more meaningful collaboration with businesses and industries actually implementing solutions, ‘productive interaction’ is still missing. Even if second-layer solutions are revealed to be the panacea to all of blockchain’s ills, the mainstream use of the technology relies on a responsive and interactive relationship between scientists and society.
Lightning Network’s potential applications and reach has made it an area of high interest, but another sidechain protocol is gathering momentum too. Liquid has been dubbed a ‘federated sidechain’ for Bitcoin, in that its governance is restricted to a small number of institutional elites who engage in dedicated trade.
Liquid differs from Lightning in that it is a more specialised second-layer solution, and much more centralised. At its core, liquid is designed to cut costs and increase efficiency by taking things off-chain, aiming to provide transaction confirmations within the 2-minute mark.
The concentrated nature of power in the Liquid solution promises increased efficiency, but it is unclear as of yet how the concept will translate to the various subsets of the Bitcoin user base.
This article has been created by Lola Dabota from The Research Institute.
Illustrations by Kseniya Forbender
To contact the editor responsible for this story:
Margarita Khartanovich at [email protected]