Blockchain technology, while promising, is nowhere near powerful enough to support the volume of activity required to support a mass-adoption scenario.
The Second Layer
Many of the blockchain scaling solutions that researchers and developers are pursuing take place in the so-called "second layer." This term is used to denote the auxiliary platforms and protocols that, in one way or another, help reduce activity on the base layer blockchain (the fundamental blockchain around which a blockchain network is organized) or reduce the amount of data required to describe that activity.
The idea is to free up space in base layer blocks so that more data can be recorded to them, which allows a greater number of transactions and other state changes to be processed. (A state change is literally any change to the condition of any assets and/or accounts in a blockchain network. This includes but is not limited to transactions.)
State Channels and Execution Forks
One possible solution to this problem is the state channel.
State channels are essentially multi-signature wallets or contracts that only certain parties can access. When these parties agree to a state change, that change takes place within the channel but is not recorded to the base layer. In other words, a state change inside the channel does not affect the rest of the network, and in fact remains invisible to network nodes that lack access to the channel. It is only when the parties with access to a channel agree to write its current state to the blockchain, to add or remove funds, or to close out the channel, that the internal state changes are reported to the base layer and become a matter of public record.
Incidentally, a payment channel is a specialized kind of state channel, one in which cryptocurrency transfers are the only type of state change that can be made. Other kinds of state channels can be used for a variety of purposes, including "auctions, boardroom voting, [and] gaming."
In their current implementations, state channels (and payment channels) have a major vulnerability: the impractical requirement that users remain online (i.e., synchronized with the base layer blockchain) at all times. If some parties in a state channel go offline, another party in the channel can perform what's called an "execution fork," which reverts the channel's state to the version of that state that was most recently recorded to the base layer.
Such an attack might be perpetrated in the following way: User A and User B establish a state channel, with User A depositing 10 Ether and User B depositing nothing. User A sends the 10 Ether to User B in exchange for some type of good, which User B provides. All the funds in the channel now ostensibly belong to User B, but when user B goes offline, User A performs an execution fork, effectively reclaiming those 10 Ether while hanging onto the good that they received from User B.
On May 22, a team of researchers published a paper (and a less technical explainer document to accompany it) proposing Pisa, "a protocol to allow a customer to hire a third party agent called the Custodian to watch state (and payment) channels" on the customer's behalf.
By providing users with a form of recourse in the event of an execution fork, this custodian would effectively eliminate the requirement that its customers remain perpetually online.
The paper, co-authored by Patrick McCorry, Sarah Meiklejohn, Surya Bakshi, Iddo Bentov, and Andrew Miller, explains that Pisa customers receive a "signed receipt from the custodian" when they contract that custodian's services. This receipt acts as "publicly verifiable cryptographic evidence" that the custodian has agreed to "defend the channel," evidence that "can be used to penalise" custodians that fail to prevent execution forks, either out of negligence or through active collusion with other parties in the channel.
In the authors' vision, custodians would have to stake a certain amount of funds in order to accept a job and would forfeit those tokens if they fail to live up to their end of the agreement. To dissuade custodians from colluding with non-customer parties in a channel, the staked tokens should be worth more than any reward a custodian might receive for engaging in malicious behavior.
A custodian would not get to see a channel's state itself, but rather a hash of that state. In effect, this means that they would have no idea what is actually happening inside the channel, but they would be able to verify whether or not all parties in the channel have agreed to a given state change.
Pisa in Practice
No implementations of the protocol have been deployed yet, but according to the paper's authors, a Pisa solution could be quite versatile: "Pisa is application-neutral, and can be used with any state channel program, since the custodian only receives a hash of the channel's state rather than the state itself."
Earlier this month, the Ethereum Foundation awarded "Patrick McCorry et al." a $250,000 grant to continue their work on the proposed protocol.