PISA: Arbitration Outsourcing for State Channels
Patrick McCorry
�With the support of Surya Bakshi, Iddo Bentov, Sarah Meiklejohn, Andrew Miller and Chris Buckland
paddykcl
Off-chain (Layer-2) Eco-System Overview
Off-chain Channels
Battleship
Payments
Off-chain (Layer-2) Eco-System Overview
Off-chain Channels
Battleship
Payments
Non-Custodial Hubs
Off-chain (Layer-2) Eco-System Overview
Off-chain Channels
Battleship
Payments
Non-Custodial Hubs
Non-Custodial and SUPER-fast payment/application network!!!
Off-chain (Layer-2) Eco-System Overview
Watchers
Off-chain Channels
Battleship
Payments
Non-Custodial Hubs
Off-chain (Layer-2) Eco-System Overview
Watchers
Off-chain Channels
Battleship
Block 1
Block 2
Block 3
Payments
Non-Custodial Hubs
Settlement System and Root of Trust of all Layer 2
What is a state channel?
Every party collectively authorises a new state of an application locally amongst themselves.
�The blockchain acts as a root of trust to guarantee:
Safety: Each party gets the coins they deserve
Liveness: The application will always progress
paddykcl
Observation: Liveness is *not really* a problem for payment channels!
But what if one party doesn’t cooperate off-chain?
*reveals royal flush*
Yes! I won the game!
All the coins are mine!!!!
paddykcl
But what if one party doesn’t cooperate off-chain?
There is NO WAY I’m letting you win the game!
*refuses to sign new off-chain state*
paddykcl
Every state channel has a dispute process to
self-enforce the app’s correct execution
In other words, if one party is no longer cooperating, then the app can be finished via the blockchain.
… so Alice will *always* get her money for winning!
paddykcl
The Dispute Process (Kitsune) �
Step 1: One party triggers the dispute and there is a fixed time period for all parties to submit the latest agreed off-chain state.
Block 1
Initiate Dispute
Initiate Dispute
One party can initiate the dispute process.
Sets a fixed time period for all parties to respond.
The Dispute Process (Kitsune) �
Step 2: Any party can submit “the latest agreed state” to the blockchain
Submit State (Hash) + Version
All parties can hash of latest state (alongside counter)
Block 1
Block 2
Block ...
Block N-1
Initiate Dispute
hstate,
i
Block 3
hstate, i+1
The Dispute Process (Kitsune) �
Step 3: After the dispute period has expired, the blockchain decides the final state of the app and the dispute is “resolved”.
Block 1
Block 2
Block ...
Block N-1
Block N
Initiate Dispute
hstate,
i
Block 3
hstate, i+1
Resolve Dispute
Resolve Dispute
hstate, i+1 stored as the final commitment
After the dispute is resolved...
The application is re-deployed and
its execution simply continues via the blockchain.
Always Online Assumption (New Security Requirement)
Parties must remain online and look out for disputes to prevent execution forks.
Alice is asleep and offline!
I can broadcast an older state and pretend the game never happened!
Bawhahaha
ZZZZzzzzZzzzzzz
Always online assumption:
All parties must remain online to detect and defend against execution forks
Block 1
Initiate Dispute
Initiates Dispute
Bob prepares to perform execution fork
Always online assumption:
All parties must remain online to detect and defend against execution forks
Block 1
Initiate Dispute
Old Game State
Bob updates the blockchain with an older hstatei-1
σA,σB,hstatei-1 ,i-1
Block 2
Update State
Always online assumption:
All parties must remain online to detect and defend against execution forks
Block 1
Initiate Dispute
Block 2
Update State
Block 3
Always online assumption:
All parties must remain online to detect and defend against execution forks
Block 3
Block 2
Block 1
Initiate Dispute
Update State
Always online assumption:
All parties must remain online to detect and defend against execution forks
Block 3
Block 4
*tense*
Will Bob get away with it?
Will Alice wake up to stop it?
Find out in the next slide!!!
Block 2
Block 1
Initiate Dispute
Update State
Always online assumption:
All parties must remain online to detect and defend against execution forks
Block 3
Block 4
Block 2
Block 1
Initiate Dispute
Update State i-1
Update State i
Block 5
Latest Game State
Alice wakes up and updates the blockchain with the latest hstatei
σA,σB,hstatei ,i
Always online assumption:
All parties must remain online to detect and defend against execution forks
Block 3
Block 4
Block 2
Block 1
Initiate Dispute
Update State i-1
Update State i
Block 5
Execution Fork is Cancelled!
Alice keeps her winnings, but only because she remained online and responded at the right time!
Can we help alleviate this new security requirement?
paddykcl
Pisa: Hire an accountable third party!
State Privacy
Custodian should not learn about the state he is watching (unless there is a dispute on-chain!)
Fair Exchange
Custodian should be paid upon accepting appointment from customer
O(1) Storage
Custodian only has to store the latest job received from the customer!
Recourse as Financial Deterrent
There should be indisputable evidence that can be used to punish a malice Custodian
Application-Agnostic State Channel (Kitsune)
Pisa Contract
Only cares about state hashes, signatures and counters.
Compatible with any application designed for a state channel.
Stores large security deposit for Pisa.
Awaits evidence of cheating from customers to self-enforce deposit forfeiture.
Setting up Pisa
Setting up Pisa
Pisa Contract
Stores a large security deposit upon set up.
Deposit can only be withdrawn after a fixed period of time.
paddykcl
Setting up Pisa
Pisa Contract
Stores a large security deposit upon set up.
Deposit can only be withdrawn after a fixed period of time.
paddykcl
Setting up Pisa
Pisa Contract
Stores a large security deposit upon set up.
Deposit can only be withdrawn after a fixed period of time.
paddykcl
Setting up Pisa
Pisa Contract
Stores a large security deposit upon set up.
Deposit can only be withdrawn after a fixed period of time.
paddykcl
Achieving State Privacy
Achieving State Privacy
An Appointment to Pisa only contains:
A state hash, state version, and signature from all parties.
σA,σB,σC, H(statei+1,r), i+1
paddykcl
Fair Exchange of Appointment & Payment
In other words, how can we ensure the customer
gets a publicly verifiable signed receipt upon paying Pisa?
paddykcl
Payments can be sent off-chain to Pisa!
Some assumptions to simplify presentation:
Sending off-chain hire appointment
Step 1:
Customer sends the appointment/job to Pisa
New Appointment: σA,σB,σC,hi+1, i+1
Pisa checks appointment
New Appointment: σA,σB,σC,hi+1, i+1
Step 2:�
Pisa performs sanity checks (i.e. signatures, largest nonce so far, etc).
Pisa creates, signs and sends a receipt
New Appointment: σA,σB,σC,hi+1, i+1
Signed Receipt: <appointment>, hreceipt,σcustodian
Step 3:
Pisa creates receipt, computes hreceipt = H(s),
signs the receipt and sends to the customer.
Customer sets up conditional transfer to Pisa
New Appointment: σA,σB,σC,hi+1, i+1
Signed Receipt: <appointment>, hreceipt,σcustodian
Conditional Transfer: <coins>, hreceipt, Expiry_Time, σB
Step 4:
Customer checks custodian’s signature (and appointment information).
If happy, customer creates, signs and sends a conditional transfer.
Pisa reveals secret s and ratifies receipt
Final Step:
Pisa reveals secret “s” for hreceipt to customer before the expiry time. This ratifies receipt and allows custodian to claim transfer.
New Appointment: σA,σB,σC,hi+1, i+1
Signed Receipt: <appointment>, hreceipt,σcustodian
Conditional Transfer: <coins>, hreceipt, Expiry_Time, σB
Ratify Receipt: Reveal “s”
Complete transfer off-chain or resolve via blockchain
Receipt is only ratified if “s” is revealed.
Bob should update the channel to complete the transfer.
Of course - it can always be settled directly on the blockchain before the expiry time.
New Appointment: σA,σB,σC,hi+1, i+1
Signed Receipt: <appointment>, hreceipt,σcustodian
Conditional Transfer: <coins>, hreceipt, Expiry_Time, σB
Ratify Receipt: Reveal “s”
Bob and Pisa collude to cheat Alice?
Execution Fork: Bob triggers dispute
Bob triggers a dispute in the state channel..
… while Alice is offline!
Block 1
Initiate Dispute
Execution Fork: Bob sends old state
Bob broadcasts an older state…
let’s pretend it is state i-1
State Update
Block 2
Block 1
Initiate Dispute
Execution Fork: Pisa could step in!
State Update
Block 2
Block 3
Block 1
Initiate Dispute
Pisa *could* publish newer start and cancel the dispute…
.. but it doesn’t!! 😱😱😱😱
Execution Fork: Pisa could step in!
State Update
Block 2
Block 3
Block 1
Initiate Dispute
Block 4
Pisa *could* publish newer start and cancel the dispute…
.. but it doesn’t!!
Execution Fork: Bob is successful/withdraws lambo
State Update
Block 2
Block 3
Block N
Block 1
Initiate Dispute
Block 4
Resolve
Too late… execution fork occurs!
… but we assume a record of this dispute state i-1 is recorded on the blockchain!
Execution Fork: Alice is online… it is too late?
OH NO! Pisa cheated me!!!!
I’ve lost all my coins!
It isn’t too late…
she has evidence that Pisa cheated
Dispute Record*
State channel contract records all successful disputes
Ratified and signed receipt
Evidence Pisa promised to prevent execution fork
+
Evidence: Signed (and Ratified) Receipt + Dispute Record
Pisa Contract
State Channel Contract (Kitsune)
Signed (and Ratified) Receipt
Evidence: Signed (and Ratified) Receipt + Dispute Record
Pisa Contract
State Channel Contract (Kitsune)
Signed (and Ratified) Receipt
Request Disputes
Evidence: Signed (and Ratified) Receipt + Dispute Record
Pisa Contract
State Channel Contract (Kitsune)
Signed (and Ratified) Receipt
Request Disputes
List of disputes
Evidence: Signed (and Ratified) Receipt + Dispute Record
Pisa Contract
State Channel Contract (Kitsune)
Signed (and Ratified) Receipt
Request Disputes
List of disputes
*compares receipt + list of disputes*
Yup! Pisa could have saved the day.
Sorry, I must forfeit the entire security deposit.
Revenge is sweet
Pisa: Hire an Accountable Third Party
State Privacy
Custodian should not learn about the state he is watching (unless there is a dispute on-chain!)
Fair Exchange
Custodian should be paid upon accepting appointment from customer
O(1) Storage
Custodian only has to store the latest job received from the customer!
Recourse as Financial Deterrent
There should be indisputable evidence that can be used to punish a malice Custodian
| Privacy Preserving | Verifiable Job | Storage | Fair Exchange (Job + Reward) | Publicly Verifiable Warrant | Financial Deterrent (and Accountability) | Deployable Today |
Monitor | | | O(N) | | | | |
WatchTower | | | O(1) | | | | |
PISA | | | O(1) | | | | |
All good!
Not in original protocol,
but compatible
Nope
We are building it
Untrusted Co-ordinator & k-out-of-N watchers
Proving liabilities and assets watched over?
Why don’t you have a side-chain for hiring a bunch of watchers at the same time?
Two years later.
We are on the verge of practical and deployable state channels.
Magic unicorns need not apply.
Thanks for listening!
Follow us on twitter! https://twitter.com/PisaResearch
Our vision: https://goo.gl/tNi1ch