Pisa: Arbitration Outsourcing for State Channels

Generic State Channels

The premise of a channel is simple, a small group of distrustful parties want to jointly execute a program which relies on information recorded on-chain (and ultimately may influence the state of other on-chain programs) amongst themselves and not directly on the global blockchain. This requires all parties to collectively sign every new state of the program and invalidate the previously authorised state. If all parties cooperate, then every new state is locally kept amongst themselves (i.e. off-chain), but if a single party aborts, then the "disputed" state transition must be executed on-chain. In a way, this allows parties to run a local consensus protocol and rely on the global blockchain as a root of trust to enforce the liveness (and correctness) of a program's execution.

In the best case, all parties can avoid the global network's latency (i.e. confirmation on the blockchain) and the network's transaction fees. On the other hand, state channels introduce a new assumption that each party remains online and synchronised with the global blockchain.

The "always online" assumption

If one party is offline for an extended period of time, then all other parties can collude and perform an execution fork via the global blockchain. As the name suggests, this irreversibly forks the smart contract's execution and effectively invalidates any execution that was authorised locally amongst every party. In the worst case, the colluding parties can steal all coins in the channel. This is problematic for real-world use as it is likely parties will want long-lived channels (perhaps on embedded devices) and cannot remain online at all times.

Leaning tower to the rescue (Pisa)

To help alleviate this new assumption, we introduce Pisa, a protocol to allow a customer to hire a third party agent called the Custodian to watch state (and payment) channels on their behalf. Unlike previous solutions [1][2], Pisa is designed for generic state channels and not just payments. Pisa has the following properties:

State privacy. The Custodian only receives a hash of the state and not the state itself. They may only learn they were hired for a particular state if it is later revealed on the global blockchain via a dispute.

O(1) storage. The Custodian is required to only store the latest appointment job they have received from the customer. As previously mentioned, this is a hash of the state and a signature from every party in the channel.

Public verifiable appointments. We propose fair exchange protocol that ratifies a signed receipt of appointment for the customer upon paying the custodian. This provides cryptographic evidence that the custodian has agreed to watch a channel on the customer's behalf and they have been paid to do it!

Fair (and real-time) reward. The custodian is paid every time the customer hires them to watch a new state on their behalf. If their service is not required (i.e. there is no dispute), the custodian is still paid..

Customer recourse (and holding the Custodian to account). The Custodian may simply not do their job when the customer is offline. In Pisa, we rely on a financial deterrent such that if the customer can prove the custodian's wrongdoing (using the signed receipt), then the custodian's pre-arranged security deposit is automatically forfeited / burnt.

Together, the above properties are necessary for any Custodian protocol to be deployed in practice. The customer has evidence of an appointment, the custodian is rewarded in real-time for their service, and there is cryptographic evidence if the custodian cheats.

Why is this work important? and what comes next?

Our paper presents a generic state channel construction (originally from Sprites) which can be used to build any application. As a bonus point, the custodian can watch any application that is built using this construction too!

Thanks to the Ethereum Foundation, we have received $250k~ to help bring Pisa from research to practical use. We'll be hiring one or two developers to help us out so please get in touch if you are interested! Our first summer project is to build an application within the generic state channel and empirically evaluate the practical difficulties involved in this scaling solution. Of course, the funding's primary goal is to implement the custodian to support the wider ecosystem.

Want to learn more about state channels? Come to our off-chain event in Berlin too!

To the moon 🚀

Acknowledgements. We’d like to thank Lefteris Karapetsas (Raiden) for bringing the monitoring problem to our attention at Devcon3 and the wider Raiden team for their feedback during the development of Pisa.

[1] WatchTower - https://scalingbitcoin.org/transcript/milan2016/unlinkable-outsourced-channel-monitoring

[2] Monitor - https://scalingbitcoin.org/transcript/milan2016/unlinkable-outsourced-channel-monitoring