right so I'm gonna be talking about
counterfactual it's an open source
initiative to make secure off key nap
occasions easy to build in aetherium so
you just saw two talks about building a
payment channel network and about
building like a production application
specific state channel casino game kind
of application we want to try and make
those types of things as easy as
possible to build for the developers
that build it so Jeremy for example from
funfair is our target kind of developer
that we want to like help make their
life easier and the whole funfair team
in front of me so first of all who am i
my name is liam horn i am the co-founder
or one of the cofounders of l4 we're a
company that tried to do a lot in this
industry basically promoting kind of the
web 3 vision we helped build this
project we helped build eath global and
a handful of other initiatives but I'm
also an engineer in the counterfactual
project the distinction for which has
not yet been so clear but I'm gonna try
to articulate in this talk so what am I
talking about I'm gonna kill foo go
through four things basically what are
generalized eight channels you just saw
use cases of payment channels and you
saw use case of what I'm gonna kind of
show is an application-specific state
channel I want to show what generalized
state channels are kind of a layer to
solution for the that uses this
technique in general for blockchain
transactions what counterfactual the
project is and explain how we've
approached engineering a framework for
this stuff and then how you can to so
basic basic agenda background
generalized a channels the engineering
and counterfactual so let's jump in
initially when I kind of first came into
this space I asked the question of like
why is it not the case that this stuff
is being used by everyday people yet and
the answer I got was basically that
scalability is important and this was
about a year and a half ago and there
were a handful of problems team that
needed to be worked on you know
including sharding
and one of them was state channels and I
basically was wondering why is it not
the case that anyone's really tackling
this not necessarily as an app specific
technique you can do to make your app go
faster but as a general - general
solution for scaling on aetherium why is
it not the case that anyone that wants
to build an application can take
advantage of this technique to make
their application just by default be
really fast
I stumbled upon this post got introduced
to the guy the rota Geoff Coleman and
realized a lot of the ideas were there
for how you could build state channels
into a layer to skin of scaling
technique but not a lot of the
implementation had been there yet and
kind of wondered why after lots of like
thought and and research we basically
realized that you know this is an
opportunity to try and build something
great and so what we did is we tackle it
very much with the mindset of like I
mentioned how do you build a layer to
scalability solution using this
technique generalize enough to allow for
arbitrary applications with maximum off
chain interactions without necessarily
having to build it as a one-off kind of
implementation technique for your
particular application so we started off
by writing this paper which is basically
the the formal version of the the post
that Jeff had put on it goes in a ton of
depth of how you can do this what are
the security models need to be thinking
about what are the general parameters
you want to be aiming for how can you
maximally have oft interactions using
state channels for any application a
very abstract kind of notion but one
that if you can get right enables an
enormous leap our full tech need to be
used and I'll show you how it's how it's
useful so there's a long paper but it
basically summarizes into some very
simple a very simple idea and so I'm
gonna go through it very very briefly so
you already know what payment channels
are but I'm just to set up you you're
pretty familiar with this technique you
have a blockchain you put some money
into a channel a balance be balanced you
wait some time off chain Alice and Bob
move basically over some communication
protocol they update some balances
between them you know from version 0 all
the way up to 2 n basically and then
whenever they're done they go back to
the chain they put that latest date on
and the balances would get paid out
we're familiar with that here and so
that's a payment channel so what's an
app specific stage Jim what's fun for
doing it's a very similar but what
they're doing is that they have
arbitrary state they have different
state for application whether it's
roulette or blackjack or whatever they
might be playing and they have this
added thing on the chain which is they
have the application logic to
you handle disputes essentially or cases
where someone's deviating from the
protocol and they need to figure out who
won the game actually that's how they
get the approvable fairness it was very
similar in the payment channel so that's
what you can do with application state
but what's then that what is the
generalized state channel and as I
mentioned you have the application logic
but what is the generalized a channel
and general I say channel you have the
same set up blockchain contract you put
some deposit in there and again EEOC xx
whatever it is you want to be a using
off chain but you do this interesting
thing as time goes on you actually
create for yourself
you're kind of signed transactions that
purport to allocating some subset of
that state a sub deposit into what we
can call an off chain application and
you do this and very much the same way
in the application specific state
channel but that's because you can push
it down to the application agnostic to
what's on chain you can do it multiple
times so but key benefit is that you can
now install an update and uninstall
applications arbitrary applications that
you would say you know a rule a came at
a plateau you know blackjack payment
channel whatever you want in the same on
chain State Channel and this with the
same single contract on chain you can do
multiple applications that's the key
insight of generalized state channels
it's very cool if you do it this way
then it becomes less of a quick
technique for one app it becomes a
generalized scalability solution it's
very powerful and then disputes actually
or deviations from the protocol are very
similar to the application specific case
you just take one of the one of those
states whichever one is the one that's
being you need to kind of ensure the
fairness of and adjudicate on chain you
put that on chain but the key idea is
that off chain you're installing in
unsealing applications with zero fees
no on chain transactions and and that's
great so two FA cues that I always get
asked one how do you ensure all this sub
deposits add up isn't this really
complicated
yes it's complicated and that's what
warrants Jeremy rightly mentioned a
protocol to be defined you need a
protocol for participants of a state
channel to speak to each other to say
how do you install an application
how do we uninstall it what are we what
are we saying to each other what are the
specific commitments and that gets a
little bit complicated so you need a
well specified protocol which I will get
into and the second thing is and it's
been a bit of misinterpretation if
you've seen the paper is this notion
don't you need to deploy the contract
every time and isn't it absurdly
expensive the answer is no very similar
to Jeremy and in practice of course you
deploy a contract on chain that it has
the rules that find in the game ahead of
time but that's a one-time thing for
application we have introduced in the
paper a notion of this term is called
counterfactual Sanchi ation which maybe
you've heard which allows you to do this
off chain but it's a useful technique
for performance and upgrade ability but
it's not necessarily a must-have so it's
very very performant in much the same
way as an app specific state channel
might be so great so very quickly what
is counterfactual and what are we doing
about all this why is this something
we're talking about basically the most
important thing is that we are an open
source project our goal our vision is
that these types of applications like
I've mentioned should be as easy as
possible to build in the future it
should be the case that the developer
goes to a like a hackathon and says I
want to write an application and I want
to be really fast and they should be
able to build a great user experience in
36 hours it should be as simple as
possible for that to be the case and so
our vision is to get to that mission in
terms of what the project's goals are is
to build that framework we want to make
it as easy as possible for this entire
community to benefit from this technique
get it described and so we're not a
company we're not any particular
business with any kind of business model
behind this we're an open-source project
trying our best to give something to the
community and so that that's that's the
key takeaway the project so what is
encompassed within that it's three core
pieces of infrastructure that basically
needed to be implemented and need to be
available for people to build using this
technique and they are a minimalist
contracts layer the absolute most
bare-bones simple to read simple to
deploy small ends of code set of
contracts that need to be there on top
of which you can design a protocol that
does kind of what I described a protocol
for state channels you need something
that defines how you install
applications how you want to stall them
how you update them
and an application library something
that allows developers to interface
using this protocol so you can think
very similarly this kind of looks like
the web 3 stack in the sense that you
have the underlying blockchain you have
the protocol layer following of a theory
I mean you have an application library
like web 3 we're trying to emulate a
similar developer experience for layer 2
so let's dive into some of the details
of how we've approached it and what it
looks like first of all the on chain
library at your actual contracts layer
consists of a very basic on in library
for conditional transactions you may
have heard the term conditional payments
or immediately it transfers it basically
the idea here is that you put is little
the most minimal component for unanimous
consent as possible in the Shane a multi
signature wallet achieves an event
consensus and then what we have in
addition to that is a very basic way to
use that Multi signature wallet to sign
and conditional transactions and using
kind of the best-in-class research from
a lot of the people that you're gonna
hear I think after me and I've already
spoken about how you can adjudicate a
state channel in a very optimal kind of
way and so we've taken a lot of the best
research from all those things and built
a simple component to enable this to be
to work on chain and we've already
released all of this the great thing is
it's built to support all of this stuff
unidirectional payment channels
bi-directional payment channels end
party hub-and-spoke plasma/ether c 2021
you name it the main idea is that we're
not assuming any particular type of
transaction besides the most primitive
unit of transaction on aetherium to
value data that's all that we're
assuming which means as time goes on
this framework is agnostic to protocol
updates as long as you don't change the
idea of a transaction aetherium the
protocol will still run and we can we
can incrementally improve this protocol
as aetherium develops over time without
necessarily having to have massive
upgrades per e IP for example what we've
done separately to the the generic on
chain components we've created a very
basic state machine based library and
you can see and like from from first
presentation this is kind of what
they've landed on to in terms of what's
the optimal way of describing
applications
state action new state this is the type
of
way in which we're assuming someone can
design their application and we support
this out of the box and we've also added
three very simple methods to enable your
blotch and application to kind of
benefit from from its base basically be
easy to define using this framework so a
resolver something that can take your
state and the pre-commitment the sub
deposit pre cream that you've made and
figure out what transactions need to be
made a is terminal clause something that
says is this game over and I'll show you
how all these are relevant in a second
and kind of a turn-taking mechanism
which can define is it a valid update or
not the key point here for very simple
functions that you can implement for
arbitrary applications if you implement
them the frame framework supports
out-of-the-box
so very simple high-level example a
bi-directional payment channel for
example basically here it's the most
basic possible state machine you have
one state and people can just update the
version of where you're at with that in
this case it's n party state channel and
in the cases is two in the array all you
do is update it most basic case so what
if you want to jump in like more
complicated for which there's all kinds
of different separate bespoke
applications like eating a directional
payment channel well we just write as a
machine looks like this you start in an
open state send in bat and as a bit of a
context a unidirectional payment channel
is one of the kind where only one the
payments can only be sent in one
direction so a and B a can send to be B
can't send a and the idea is that B is
the recipient and if they want to just
leave they can instantly leave so how
can you define that you can define a
machine where in the open state the
sender can send and that's a valid
action and you can get to the point
where you are done in a terminal state
which is what I would represent with
this orange ring where if you are the
receiver and you call the close action
you can instantly exit so you define
your state machine in this way and you
get all of the properties of
unidirectional payment channels without
having to implement anything different
from the generalized framework
tic-tac-toe a bit more complicated but
it's the same general idea right you
define what is your state machine
it's an extern is it O's turn
execute place annex and he can win or X
can place an X and it can be a draw you
get the idea and again you're defining
your state in this very simple way so in
designing that framework in addition to
making it very generic and possible to
build all kinds of state channel
applications using it we've also spent a
significant amount of time in the
engineering side to make this as easy as
possible for developers to build on top
of and you can see this in kind of the
implementation details of some example
applications so I'll show you very quick
of some code from a counter application
one where basically you have a counter
you can increment it you can decrement
it the basic kind of example app and
basically it looks just like this it's a
stateless contract and there's three
slides here I'll go through there's a
state lift contract you just define what
is the structure of your state and kind
of like Jimmy mentioned it's as simple
as this we actually actually had a we
actually have a hacky solution to get
around the necessity for a B ID code and
the code base right now but when it
comes out that'll be great too and you
just define your state as a struct I
need to find the actions that you can
use to modify it and again this function
signature allows you to mimic what a
state machine does you have a simple
function apply action like I mentioned
you take state you take the action you
decide what to do about it is a very
simple control flow and then there's
just very basic implementation so this
is literally the entire contract for a
very basic counter app so the great
thing about this again is certainly
rightly mentioned is that state machines
encompass arbitrary things that you can
run on the EVM that are basically pure
and constant functions there is an
aspect of time dimension here which I
think probably one of the future
speakers will talk about they add some
complexity but for things that you can
run that are EVM based this encompasses
everything which is great and so that's
the minimalist contracts layer on top of
that we've had the devise of a protocol
for this whole generalized state channel
concept and without going into too much
detail we've essentially done that this
is basically a generic software for that
clients can run and as all possible
embed messages you can receive using
channels and it's designed to be as
portable as possible so this is not
like a full note software that we've
developed this is just a basic very very
basic implementation of a protocol that
says you know the different types of
messages that someone can send to
another to use they're on chain state
deposit to install applications and
install applications and so on and so
forth and it's it's a very practical
we've we've tried to make it be the case
that there's no unnecessary Network
overhead it's it's a sense to be they
get a response back for all of the
protocols in the entire construction and
so it's practical and can be deployed
today if you want to look at the
specifications of the protocol we have a
whole spec spec stock on the website
well on github and you can you can dive
into there this is kind of the
beginnings of what we hope will become a
very good standard for what is the best
that you can get for state channels on
aetherium and eventually it would be
nice if if we can build on top of this
common standard and hopefully a lot of
the research can end up here that that's
our goal at least so finally an
application library and this is
basically the thing I mentioned
analogous to web 3 it's an application
library the developer pulls in to their
to their adapt they simply interact not
with their wallet in a way that is kind
of through the web 3 interface but with
kind of this counterfactual interface
for this layer 2 interface you do things
like update state to your wallet and the
wallet with the implementation of the
protocol figures that how to interact
with this counterparties and again this
is a little bit abstract but it's it
it's it's this entire full stack suite
that proves that the use case is
possible and all of this has been
designed in mind to be as easy as
possible for a developer and like I
mentioned earlier we actually run
hackathons and so we we spend enormous
amounts of time with developer to
understand what is it that what kind of
get people caught up so why why is it
that we're doing any of these things and
what are the kind of values that our
lineups for this as mentioned earlier
kind of factors open source project
there's multiple contributors and I'll
get into who they are but we think this
is just plain old open source we really
just want to be able to work with the
etherium ecosystem the people that are
hearing people that are at Def Con and
try to just take a lot of the great
research that we've talked about over
the years and then a you know III search
posts about May
concrete arrive at standards arrive at
things that we can agree you're kind of
best-in-class research and build on top
of that all right there's no one that's
a server you go no necessary lock-in
it's just a matter of how do we build
open standards that are helpful for
everybody and we want to do that as just
plain old open source we don't think
there's any necessity for a business or
or token we think that there's just just
plain old open source and developer
focused mention is a handful of times
and you can see through the like way
that we've designed this this is meant
to be something as easy as possible for
developers to use and we want to drive
your compatibility we want to make it be
the case that if theorem can have the
end of the best-in-class state channels
protocol before any other chain and that
we can do this basically together and be
interoperable with each other software
great so who's involved in this I
mentioned it's an open source project I
do want to give kudos to a bunch of
people this is right now mostly been a
collaboration between l4 and and I'm
prototype ol handful of people from each
of the teams and a bunch of independent
contributors we recently even had a
whole bunch in the past few weeks that
are just ramping up now all sharing the
same general vision of like let's take
all these ideas have a common place that
we can write them down and make
something that people can use so really
thanks to everyone that's contributed
over the year and we're also working
with some of the best we've over the
past year we spent a bunch of time with
a lot of great people in this space met
at mass we've been recent spending a ton
of time with trying to figure out
practically how are we going to get this
implemented in Webb Wallace today
cellular network and we spent a ton of
time with Moses pesha Lee looking at the
actual underlying research of how you
build generalized state channels we're
hoping we can arrive at common
interfaces over the next little while
Pisa which has done a phenomenal job and
they're speaking later about how to do
really optimal watchtowers with say
channels we're also going to try and
fold that in and magma as well a
phenomenal kind of state channels
engineering team with through which a
lot of the state channel our state
machine based designs have been kind of
inspired by so yeah if you want to get
involved we have a bunch of code on
github we just released a whole bunch
recently as well the whole everything I
just mentioned is a full implementations
of and then we have running we don't
have a big demo environment yet
it's one of our major kind of next goal
but we do have it running locally and
you can test it out and we're actively
developing this very fast pace if you
want to chat with us who are available
all the time you can go to our chat
group counterfactual comm slash chat
we're very friendly
we really just we want to like try to
help out the community as much as
possible so you're gonna come in
whatever you want to talk about and if
you want to just learn more about the
the product in general check it out
counterfactual calm and yeah that's it
thanks so much I do have a minute 20
seconds left so if there's a question I
can take one or or I can kind of
awkwardly walk onstage yeah
what's the like 30 second different
explanation between a state channel and
a plasma chain is yeah I had that in the
slice there's a first of all there's a
really great talk by the guy who just
gave you the microphone Josh stark
yesterday called making sense of layer
two which gives like the thirty second
basic difference the way I like to
describe it is that from technical
standpoint and state channels a fixed
group of people foot state into a non
chain contract and then they agree
unanimously off chain and at some point
they all go back off take call I stay
put it back on the chain or their or
they stay off chain with Platt and it's
all I've seen the whole time with plasma
a bunch of people but state into a
contract and there's two types of people
there's an operator and then there's the
users and the operator periodically puts
a merkel proof on the chain that lets
the users have finality so every time
the merkel proof is put on chain that is
the notion of this is now the final
state so there's this periodic check
pointing kind of mechanism so the main
difference is that state channels it's
instant finality all the time plasma you
have a bit of a delay because it's a
check point and then to technically
they're implemented differently but
they're both very useful scalability
solutions i recommend watching josh's
talk though great all right thanks