Based on a talk Introduction to State Channels & Payment Channels

1. State Channels
An Introduction
By
Priyab Satoshi
(@twitmyreview)

2. Agenda
• What is Payment Channels?
• What is State Channels?
• State Channels & Start Contracts
• Challenges & Positives
• Use cases
• Related Projects

3. Distributed Networks
Radical implication: every
node is a peer who can
provide services to other
peers

4. P2P Network Nodes provide
services
• Nodes deliver services to others,
for a small fee
• Transaction ledger hosting
(~10,000 Bitcoind nodes)
• Transaction confirmation and
logging (mining)
• News services (“decentralized
Reddit”: Steemit, Yours)
• Banking services (payment
channels (netting offsets))

5. What is Payment Channels?
• Off-chain transactions seem to be the best option for
Bitcoin & Ethereum scaling.
• Payment channels are based on the idea of transaction
replacement to update the state of an unconfirmed
transaction before broadcasting it to the network. This
concept is older than most people think, indeed Satoshi
himself implemented something similar in the first
Bitcoin release (however his goal at the time was not to
improve scalability but to enable high-frequency trades
between a set of parties).
• By replacing transactions before broadcasting,
numerous trades can occur without using the expensive
and slow blockchain. Off-chain payment channels can
be divided in three groups:
• Mono-directional payments channels
• Time-based bi-directional payment channels
• Punishment-based bi-directional payment
channels

6. Payment Channels:
Basic Idea
• Network is a graph (vertices, edges)
• Payment, credit, transaction graph
• Net clearing
• Contracts-for-difference (CFD); (without the 10x
options-style leverage of the financial instrument)
• Spread betting
• Net settlement (vs Gross settlement)
• Central banks clear amongst themselves with RTGS
(real-time gross settlement) systems (as does Ripple)
• Industry consortia, interbank daily settlements are
tabulated on a net basis
• “Have an account,” “run-a-tab” economy

7. Payment Channels:
How it works
• 3-step financial contract executed over time
• One party opens a payment channel with
another party and posts a pre-payment escrow
balance
• The party consumes against this credit over the
given time period (activity is tracked)
• At the end of the period, cumulative activity is
booked in one net transaction to close the
contract

8. Mono-directional
payment channels
• Mono-directional payment channels have seen the first
implementation back in 2013, when Matt Corallo and
Mike Hearn added support on BitcoinJ, but they were
quite limited use-cases since they only let you move
money from A to B but not the other way around.
• Alice sends 1 BTC to a 2-of-2 multisig contract between
Alice and Bob.
• To send 0.1 BTC to Bob, Alice creates and signs a
transaction that gives 0.9 BTC to herself and 0.1 BTC to
Bob and sends it Bob.
• To send other 0.2 BTC in a second moment Alice updates
the state of the channels creating another transaction
that send 0.7 BTC to herself and 0.3 to Bob.
• Alice cannot broadcast to the network and have included
on the blockchain any of those transactions, since she
does not have the required signature of Bob (remember
that the funds are locked in a multisig contract).
• Bob is always incentivised to broadcast only the last state
of the channel, since it represents the outcome where he
receives more bitcoins.
• To protect Alice from the risk that Bob is unresponsive
and does not cooperate to broadcast any state of the
channel (blocking also Alice’s funds), a time-locked
transaction that refunds Alice of one BTC is created at the
opening of the multisig contract. The time-lock is needed
to make sure that Alice can use this transaction only in the
case Bob is unresponsive.
• Before the end of the time-lock period, Bob will broadcast
the last state of the channel in order to avoid the risk of
Alice broadcasting the time-locked transaction.
• However the time-lock transaction is not an ideal solution,
since it is vulnerable to malleability attacks. To mitigate
this, in 2015 a protocol upgrade introduced CLTV (check
lock-time verify), which allows to include the time-lock in
the script of the contract itself, instead of creating a
specific transaction, avoiding the malleability problem.

9. Punishment-based payment channels (Lightning
Network)
• A different approach to create channels with no expiry date is to base the security on the punishment of a
malevolent counterparty rather than on time.
• The idea is still to lock funds in a multisig contract between the two parties involved in the channel, but to guarantee
that the right behavior is respected both parties sign transactions that spend to a more complex smart contract
design to make transaction replacement secure.
• Such payment channel design is what is used for Lighting Network implementations.
• To set up the channel, first Alice and Bob have to generate a secret (i.e. a random number) and exchange the hash.
The two parties create a funding transaction and deposit some coins on a 2-of-2 multisig contract, let’s say they put
0.5 BTC each, but before broadcasting it to the network they both create a subsequent transaction of the funding
transaction, the so called commitment transaction. In the commitment transaction Alice sends 0.5 BTC to herself
and 0.5 BTC to a contract where the coins can be spent either by Bob after a predetermined amount of time (e.g.
one week after the transaction goes on the blockchain) or by Alice including in the transaction the secret that Bob
generated.
• Similarly to what we have already seen with time-based channels, off-chain payments are achieved through
transaction replacement, but this time old transactions will be invalidated using the secrets instead of time-locks.
• When Bob wants to pay 0.1 BTC to Alice, first they both need to generate a new secret and share the corresponding
hashes, which will be used to build a new commitment transaction with the same structure of the previous one, but
instead of sending 0.5 BTC to Alice and 0.5 to himself, he now sends 0.6 BTC to Alice and 0.4 BTC to himself.
• Now two different, but both valid, commitment transactions exist. Since Bob could try to broadcast on the
blockchain the old transaction (which gives to him 0.1 extra BTC) it is important to invalidate it and enable secure
transaction replacement. To do so, both parties can now share the secret they generated for the previous
transaction. In this way if Bob tries to broadcast the old transaction, Alice has a full week to spend the funds locked
in the contract providing Bob’s secret before Bob can move any BTC out of it. Now Bob is strongly dis-incentivized to
attempt an old transaction broadcasting as he would lose all the money he put on the channel.
• The described process enables secure transaction replacement allowing the channel to stay open indefinitely, with
no increasing settlement costs after many transactions occurred (making it superior to time-based channels), but
still requiring some blockchain monitoring to ensure security.

10. Payment Channels – Time-based
bi-directional payment channels
• In a bi-directional channel the flow of fund can go in both ways
• A time-based channel achieves security by time-locking transactions in so that the last state of the
channel has always the lowest time-lock, meaning it is the first one that can be broadcast on the
blockchain. Every new transaction having a lower time-lock invalidates all the previous ones, updating the
state of the channel .
• To make such system really trust-less, it is necessary to create the first transaction that sends back the
funds to both parties before any bitcoin is moved to the multisig, just in case one of the two parties
becomes unresponsive.
• However, creating a transaction that spends an unconfirmed transaction exposes the parties to the risk of
malleability attacks, meaning that only SegWit transactions can be used in this process since, unlike
normal transactions, they are immune to malleability problems.
• The security of the channel is guaranteed only until the first time-lock expires, after which it has to be
closed (i.e. sending the funds to the two parties), giving the channel a predetermined limited life time.
• To overcome this problem a slightly different design can be implemented using relative time-locks instead
of the previously seen absolute time-locks.
• While this design greatly improves the lifetime of a payment channel, there is still a huge limitation: you
quickly run out of time if you do many transactions
• Luckily there is a trick to extend the life of the channel even further: when the time-lock of the
transactions is becoming too low, instead of sending money to the two parties, you send again bitcoins to
the multisig, creating another kick-off transaction for a new series of time-locked transactions. This
procedure can be repeated as many time as necessary to keep the channel alive, but the trade-off is that
to unilaterally close the channel more transactions have to be broadcast, with potentially very high fees.

11. Payment Channels – Key
Drivers
• Motivation
• Improve scalability through contractually-obligated relationships booked as periodic net activity
• Micropayments mechanism for video bandwidth/live auction consumption where piecemeal transactions do
not make sense
• Bigger implication
• Might develop into a digitized payment system for resource consumption that settles based on net payments
instead of gross transfers, and enables peer-to-peer banking services
• Sophisticated functionality
• Concatenated payment channels, time/signature lock parameters (CheckLockTimeVerify,
CheckSequenceVerify)
• Implications
• An economy based on net clearings rather than gross transfers could mean more activity and less debt
• Streaming money (Antonopoulos) could be disgorged in much smaller chunks that are more closely tied to
costs and repayment possibilities
• Challenge: how to construct net rather than gross obligations for home mortgage, student loan, public works
projects, bond offerings?
• Rethink modes of consumption: pre-pay vs post-pay
• Pre-paid consumption (a small part of current overall economic activity) against the much larger portion of
activity that is post-paid and based on credit and terms
• Two-thirds of the economy tied up in supply chain finance
• Incentive is to play the float; instead, incentive to net out
• Digitized streaming money and payment channels could be techniques to quicken the 30-60-90 day terms an
uncollectible debt problem in supply chain finance, and facilitate a just-in-time economy for money

12. State Channels
• State channels are a very broad and simple way to think about
blockchain interactions which could occur on the blockchain,
but instead get conducted off of the blockchain, without
significantly increasing the risk of any participant.
• The most well known example of this strategy is the idea
of payment channels in Bitcoin, which allow for instant fee-less
payments to be sent directly between two parties.
• State channels are the general form of payment channels,
applying the same idea to any kind of state-altering operation
normally performed on a blockchain.
• The insight behind this layer 2 solution is that we can use this
core kernel of certainty as an anchor— a fixed point to which
we attach additional economic mechanisms.
• This second layer of economic mechanisms can extend the
utility of public blockchains outwards, letting us have
interactions off of the blockchain that can still reliably
refer back to that core kernel if necessary.
• These layers built “on top” of ethereum won’t always have the
same guarantee as on-chain operations. But they can still
be sufficiently final and secure to be very useful — especially
when that slight decrease in finality lets us perform operations
much faster or with lower overhead costs.

13. State Channels – With Smart Contracts
• As a new paradigm participants open the channel by setting up a "judge" smart contract Sign promises to
each other which the judge can enforce and adjudicate if necessary, and then close the channel by
agreeing amongst themselves so that the judge's adjudication isn't needed.
• As long as the "judge" mechanism can be assumed to be reliable, these promises can be counted as instant
transfers, with the judge only appealed to in exceptional circumstances, such as when one party disappears.
• State channels can apply to any smart contract which deals with frequent updates between a defined set of
participants. You can anticipate seeing this approach in many (if not most) distributed applications going
forward.
• We distinguish between payment and state channels. Payment channels are used as a simple setup where
small quantities of cryptocurrency are exchanged incrementally and there is no conflict resolution. True state
channels can run smart contracts and resolve conflicts on the blockchain.
• State channels exchange smart contract code and state with each message in the channel. All messages are
signed by both parties and both parties can verify that the state is correct by executing the smart contract
included in the message. A set of fingerprints of all contracts that can be exchanged in the channel is included
in the channel opening transaction.
• In case of conflict, either party can post the latest cosigned state and contract code to the blockchain and the
blockchain will verify correctness of the state by executing the smart contract. The blockchain can verify that
the contract is valid by checking its fingerprints against those supplied by the users the channel was opened.
• Each channel message carries an optional “timelock” that expires after a given number of blocks in the future.
Assuming that one of the parties has decided to unilaterally close the channel and post a state to the
blockchain as the latest, the timelock gives the other party time to post a co-signed state with a higher counter
value. This is important, for example, in the case where one of the parties lost internet connectivity.
• Each channel established between two parties (peer-to-peer) holds its own separate state. It’s often beneficial
to establish a many-to-one channel, e.g. with many buyers connecting to a single seller. We enable this
scenario by allowing opening of state channels to off-blockchain applications. These applications can be written
in any language but still need to connect to a local blockchain node to listen for and reply to state channel
events.

14. State Channels – Basic Components
• The basic components of State Channel is given below:
• Part of the blockchain state is locked via multisignature or
some sort of smart contract, so that a specific set of
participants must completely agree with each other to
update it.
• Participants update the state amongst themselves by
constructing and signing transactions that could be
submitted to the blockchain, but instead are merely held
onto for now. Each new update "trumps" previous updates.
• Finally, participants submit the state back to the
blockchain, which closes the state channel and unlocks the
state again (usually in a different configuration than it
started with).
• In step 2 an unlimited number of updates can be rapidly made
without the need to involve the blockchain at all--and this is
where the power of state channels comes into play, because only
steps 1 and 3 need to be published to the network, pay fees, or
wait for confirmations.
• With careful planning and design, state channels can remain open
almost indefinitely, and be used as part of larger hub and spoke
systems to power an entire economy or ecosystem.

15. State Channel – Key benefits
• State channels have instant finality, meaning that as soon as both
parties sign a state update, it can be considered final. Both parties
have a very high guarantee that, if necessary, they can “enforce”
that state on-chain.
• State channels are best used for applications with a defined set of
participants. This is because the Judge contract must always know
the entities (i.e. addresses) that are part of a given channel. We
can add and remove people, but it requires a change to the
contract each time.
• They’re particularly useful where participants are going to be
exchanging many state updates over a long period of time. This is
because there is an initial cost to creating a channel in deploying
the Judge contract. But once it is deployed, the cost per state
update inside that channel is extremely low.
• State Cannels have strong privacy properties, because everything
is happening “inside” a channel between participants, rather than
broadcast publicly and recorded on-chain. Only the opening and
closing transactions must be public.

16. State Channels – Key
Challenges
• State/payment channels have generally been perceived as quite complicated
• In order for state channels to work, participants have to be assured that
they could publish the current state of the channel to the blockchain at any time.
Hence someone has to stay online to protect each individual party's interests
until the channel is closed.
• To make this part of the state channel work, the locking and unlocking
mechanisms have to be properly designed so that old state updates submitted to
the blockchain have a chance to be corrected by the newer state updates which
replaced them.
• The timer/penalty process may introduce extra fees, delays, or other
inconveniences; given that forcing someone into the mechanism can't give you
any advantage anyways, parties to a state channel will probably just close the
channel out by mutually agreeing on a final channel state.
• The final close-out operation will happen so that participants will only sign a final
close-out transaction once for each portion of the state locked within a
particular channel.

17. Example –
Prediction Market
• Alice and Bob wants to bet against each other.
• For the bet they Lock money
• First transaction: Alice bets on Hillary, Bob on
Sanders (could sign the transaction or just the
resulting state)
• Second transaction: Alice makes another bet on
Hillary
• 3:Sanders wins.
• If they cooperate they can just update the
off-chain state to:
• If Alice does not cooperate Bob can settle
state 2 (submit it to the blockchain)
• Alice could try to cheat and settle state 0 or
1 - > Bob can challenge this by submitting
state 2 during the challenge period

18. Example: HASHLOCK - TRANSITIVE
TRANSACTIONS
• Alice wants to send Charly 10 ETH but hasn't locked money with
him.
• Solution - Alices sends 10 ETH to Bob in channel 1 and Bob sends
10 to Charly in channel 2
• Problem - Who makes the first transaction? -> Hashlock
• Alice can publish the HASH-LOCK
• What if
• a) Alice creates the transaction to Bob but Bob does not
create the transaction to Charly -> than Alice does not
reveal the Secret
• b) Alice reveals the secret of the transaction only to Charly?
-> as soon as Charly puts the secrete on the Blockchain Bob
knows it as well
• c) What if Alices does not reveal the secret at all? -> there
needs to be an expiry date where funds are freed anyway

19. Other Use cases
• Promise of cryptocurrencies as “programmable money” in implementation
• A contingent three-part financial contract over time is a new instrument
• Financial contract feature sets:
• Prepayment risk
• European/American-style option execution
• Fractional reserves
• Accounting: deferred payment, installment sale. Revenue recognition, liability.
• Legal: assignments of claims, forward looking IOUs
• Formalized into a multi-party payment contract netting salary against expenses, any
remainder to Schwab investment account
• Implication: settling net basis frees capital
• Consider business entities on a net basis
• Blockchains: only sub-registers of the cash account (Alice, Bob, HSBC, etc.), not a full
suite of general ledger accounts
• Property registries use cash-acct ledger structure
• Property registries where UTXOs are assets
• Birth/death registry: one credit tx, one debit tx
• Supply chain finance: for supply chain net settling, need integrated account ledgers
• Single set of books with multiple views: by supply chain (new) + by entity
(existing)
• Revenue (WMT); COGS (Deere, Adidas)
• Farther-future possibility of auto-instantiating self-driving cars and other smart
network resources
• Smart network instantiates banking services directly (sensing network demand, auto-
instantiates, provides services, retires when necessary)
• Network node does not need to be human-backed (technically)
• Historically-vested grounding of roles, responsibilities, taxation in legal personhood

20. Projects
• The Lightning Network is a "second layer" payment protocol that operates on top of a blockchain. It enables instant
transactions between participating nodes and has been touted as a solution to the bitcoin scalability problem.
• The Raiden Network is a well-known implementation of a lightning-style network on Ethereum. Its Solidity code is
significantly more complicated; it uses ERC20 tokens instead of ether, has a different settlement mechanism, and
uses some assembly for performance optimization.
• Counterfactual: a framework for generalized state channels on ethereum. Our general purpose, modular
implementation will let developers use state channels in their application without needing to be state channel
experts themselves.
• Funfair has built state channels (which they call “Fate channels”) for their decentralized gambling platform
• Spankchain has built one-way payment channels for adult performers (they also used a state channel for their ICO)
• Horizon Games is using state channels in their first ethereum-based game.
• Machinomy: Node.js library for micropayments in Ether and ERC20 tokens over HTTP

21. Thank You & QA