►
Description
Every few weeks, the Retrieval Market Builders get together to share progress in their projects in a demo format. We want to sincerely thank all of our collaborators for demoing their developments and helping to improve the FIL Retrieval Markets one demo at a time.
B
Just
trying
to
get
my
monitors
and
notes
and
zoom
and
everything
organized
so
can
you
see
the
slides?
Is
that
right,
yep,
okay,
good
all
right,
thanks,
Patrick
I'm
George
from
Team,
Magma
and
I'm
here
to
talk
about
the
work
we've
been
doing
productizing
our
software
go
Nitro
over
the
past
six
months,
so
this
work
was
part
of
an
open
Grant
proposal,
that's
funded
by
the
firecoin
foundation,
which
we're
very
grateful
for
and
yeah
just
happy
to
share
our
progress.
B
So
I'll,
just
dive
straight
in
outline
of
today's
talk
is
give
you
a
quick
recap
about
our
team.
My
micropayments,
which
is
the
kind
of
core
proposition
of
what
we're
offering
are
so
important
and
I'll,
also
go
over
what
our
software
offers
Beyond
built-in
payment
channels,
which
is
the
mechanism
you'll,
find
in
the
farcoin
specification.
That's
there
to
incentivize,
retrieval
and
yeah.
Our
our
whole
thing
is
trying
to
improve
on
that
mechanism.
B
So
with
Team
Magma,
we
work
on
layer,
T
scaling,
but
State
channels
in
particular,
and
payment
Charles.
We've
got
lots
of
different
outposts
outputs
like
documentation,
pocs
white
papers
blogs,
but
today
I'm
going
to
focus
on
grow
Nitro,
which
is
a
software
package.
We've
been
working
on
for
quite
some
time
now
and
the
the
title
of
the
presentation
should
give
you
a
clue.
We're
trying
to
turn
this
into
a
very
mature
product,
fully
featured
robust,
so
micro
payments.
B
Let's
take
a
step
back
they're,
a
really
important
mechanism
that
are
enabled
by
state
channels
and
how
they
work
and
how
they
help
to
Turbo
Charge
things
like
retrieval,
but
many
other
use
cases
is
really
interesting.
So
how
do
they
work?
You've
got
a
player
on
the
right
and
a
payee
on
the
left.
The
pay
is
providing
something
to
the
payer,
so
it
could
be
files.
B
It
could
be
some
other
kind
of
entertainment
service
provision
of
some
kind
and
what
you
do
in
micropayments
is
you
split
up
both
the
service
that's
being
provided
and
the
payments
that
are
going
across
in
the
other
direction,
and
you
just
swap
a
little
bit
of
one
for
a
little
bit
of
the
other,
relying
on
like
what
you
might
call
Micro
trust.
So
you
don't
trust
the
other
party
much,
but
you
do
trust
them
with
tiny
bits.
You
might
send
them
one
cent
and
they
send
you
one
kilobyte
or
something
like
that,
and.
B
Well,
you
can
keep
doing
that
and
you
don't
have
to
put
much
trust
in
the
other
party
at
all,
because
if
they
stop
paying
you
stop
providing
the
service.
If
you
stop
running
the
service,
they
stop
paying
and
you'll
find
this
in
the
existing
farcoin
spec
and
it's
a
really
General
method
to
minimize
Trust.
B
But
the
existing
Solutions
out
there
often
do
still
result
in
a
lot
of
latency
and
cost
in
setting
up
these
micropayments
and
that's
where
go
Nitro
can
come
in.
So
how
might
you
do
micropayments?
Here's
one
way
that
you
wouldn't
do
it.
You've
got
the
payee
the
payer
and
the
blockchain
here
is
different
actors
and
in
the
context,
for
example,
of
one
retrieval
deal
in
farcoin.
You
could
try
and
do
micropayments
on
the
blockchain.
B
So
every
time
you
wanted
to
send
a
cent
you
craft,
a
blockchain
transaction
sign,
it
pay
the
gas
fees
broadcast
it
and
so
on.
But
that's
really
awful,
because
the
cost
of
doing
the
payments
is
so
high
that
it's
probably
dwarfing
the
cost
of
a
service
and
even
worse,
it's
just
really
really
slow,
because
each
payment
is
massively
slowed
down
by
the
blockchain
by
the
block
time
latency,
which
might
be
something
like
30
seconds
on
farcoin.
So
that
really
doesn't
work
at
all.
B
If
you
have
some
vanilla
payment
channels,
things
are
looking
a
lot
better.
So,
within
the
context
of
one
retrieval
deal,
for
example,
the
payer
makes
a
deposit
on
the
blockchain,
that's
still
expensive
and
slow,
and
at
the
end
of
the
process,
the
payee
is
going
to
deal
with
blockchain
transaction
to
claim
those
funds
based
on
payments
which
are
sent
directly
from
the
payer
to
the
payee
off
chain
and
those
purple
payments
are
great
because
they're,
essentially
zero
cost
and
they're,
essentially
zero
latency.
B
All
those
numbers
are
extremely
low,
so
that
that's
fantastic
and
if
you
look
at
Falcon
existing
farpoint
payment
channels,
they're
even
slightly
better
than
this,
because
you
can
set
up
a
relationship
between
a
payer
and
a
payee,
and
you
can
do
many.
Many
retrieval
deals
using
just
one
deposit
and
one
withdrawal,
but
generally
you
still
have
a
bit
of
a
problem.
If
you're
connecting
to
someone
new,
you
still
have
those
red
transactions
up
there
which
are
expensive
and
slow.
B
So
that's
where
virtual
channels,
which
is
what
go
Nitro,
is
built
to
execute,
come
into
the
picture
and
the
way
they
work
is
you
still
have
these
red
expensive,
slow
transactions,
but
they
happen
even
less
frequently
in
the
typical
flow.
So
you've
got
the
same
players
up
here
and
you've
got
the
blockchain.
A
B
You
can't
really
see
that
in
this
picture,
but
they're
entering
by
making
those
deposits
and
the
intermediary
is
essentially
guaranteeing
some
of
the
payments
from
the
payer
to
the
payee,
and
these
two
parties
do
not
share
any
pre-existing
connection,
but
because
they're
connected
through
the
intermediary
they're
able
to
transact
in
the
end
off
chain,
which
is
a
really
powerful
thing.
So
now,
in
the
context
of
a
single
retrieval
deal,
you
just
have
to
execute
this
virtual
fund
protocol
in
the
green
box
between
all
three
parties
and
I
can
explain
more
about
what
that
is.
B
It's
a
completely
open
protocol,
I
haven't
put
it
in
a
box
to
try
and
hide
anything
I'm,
just
simplifying
and
once
that's
been
executed.
The
player
can
pay
the
pay
just
like
before
directly
off
chain,
very
low,
latency,
very
low
cost
and
the
main
advantage
over
what
I
showed
in
the
previous
slide.
Is
these
parties,
as
I
said,
do
not
need
to
have
any
shared
deposit
on
chain?
They
just
enter
the
state
Channel
network
once
this
could
happen
once
a
month.
B
It
could
happen
once
a
year
and
once
it's
happened,
retrieval
deals
can
be
started,
executed,
closed
and
the
payments
all
go
through
entirely
off
chain.
So
that's
a
really
great
user
experience.
It
means
you
can
start
doing
this
Market
payment
relationship
very,
very
quickly
and
very
very
cheaply,
and
that's
you
know
what
we're
really
excited
about
and
go
Nitro
is
the
software
we
wrote
to
execute
everything
in
this
box.
B
Well,
everything
on
this
page
really,
but
the
complicated
bit
is
the
virtual
font
protocol
in
the
green
box
and
that's
a
kind
of
key
thing
that
we
work
on
so
six
months
ago,
we're
already
completed
monogram
we've
implemented
our
off-chain
protocols
and
built
an
off-chain
client,
and
what
that
means
is
that
virtual
fund
protocol
here
we
developed
it
in
a
sort
of
sandboxed
way.
If
you
like,
we
could
we
could
test
it.
B
B
It
could
not
yet
send
messages
outside
of
its
own
process
and
you
can
actually
send
any
payments.
We
didn't
even
have
an
API
for
that
and
the
final
thing
we
didn't
really
know
if
our
system
would
be
fast
enough
to
power,
something
like
a
CVM
like
a
Content
delivery
Network,
where
you
need
to
have
very,
very
low
latencies
for
a
good
user
experience,
so
that
was
a
complete
unknown
to
us
six
months
ago.
B
You
know
since
then
I'm
pleased
to
say
we
picked
one
of
these
boxes,
so
we've
deployed
our
contracts
to
various
blockchains,
including
the
wallaby
test
net.
We've
built
a
proper
messaging
system
using
a
live
PTP.
We
now
have
a
payments
API,
which
we
tested
end
to
end
and
we've
got
a
benchmarking
environment.
We've
deployed
and
we've
done
lots
of
performance.
Optimizations
sorry
was
that
a
raised
hand,
Patrick
Roy.
B
B
So
I've
got
two
important
pull
requests
up
here
on
the
left.
It's
an
upgrade.
We
made
to
our
main
adjudicator
asset
holding
contract
and
this
upgrade
is
called
reclaim.
That's
not
important
what
it's
called,
but
what
it
does
is.
It
allows
for
State
Channel
applications
to
be
funded
virtually
in
a
way
I
described,
so
it
enables
that
virtual
fund
protocol
to
be
backed
by
something
on
chain
and
that
ensures
that
money
plagued
by
intermediaries
to
guarantee
payments
can
be
safely
recovered.
B
B
We
chose
to
reuse
a
concept
from
file
coin
payment
channels
called
vouchers,
which
is
a
very
simple
way
of
sending
a
payment,
and
we
use
the
same
data
structure
and
what
we're
doing
so,
it
makes
it
somewhat
compatible
and
the
rules
are
kind
of
really
nice,
because
if
I
go
back
to
the
sequence
diagram
here,
they
require
all
three
parties
or
in
general,
it's
it's
kind
of
n
plus
two
parties.
So
you
have
any
number
of
intermediaries
you
like
it
could
be
a
a
one-hop
single
hot
payment
Channel.
B
It
could
be
hopping
over
10
different
intermediaries
and
you
have
the
pay
on
the
pay.
This
virtual
fund
protocol
requires
them
all
parties
to
participate,
to
set
the
thing
up
and
also
to
tear
it
down
at
the
end.
But
once
that
channel
is
created,
it
can
be
executed,
Just
Between,
the
payer
and
the
payee.
B
So
yes,
these
two
solidity
changes
were
really
important
and
the
kind
of
common
thing
to
both
of
them
is
that
the
code
only
really
gets
one
in
the
unhappy
path.
So
we've
got
to
have
it
there,
but
we
hope
that
it
doesn't
really
get
executed.
Much.
So
that's
just
to
recap,
code
that
guarantees
funds
from
intermediaries
and
codes
that
defines
how
payments
go
through
now.
Why
doesn't
that
happen
in
the
happy
path,
because
the
messages
happen
off
chain?
B
As
I
said
to
girly,
you
can
see
the
ETA
scan,
link
there
and
also
the
wallaby
test
net,
which
is
amazing.
The
girly
deployment
kind
of
worked
out
of
the
box,
which
we
expected
because
we've
written
this
all
in
solidity,
but
the
wannabe
stuff
had
a
few
more
teasing
problems
which
we
kind
of
helped
the
fvm
PowerPoint
virtual
machine
team
work
through
and
most
of
those
issues
have
been
tidied
up
now.
So
deploying
is
generally
not
an
issue
at
all.
B
Some
of
the
end-to-end
testing
we've
done
has
required
some
of
the
like
more
advanced
features
like
events
that
took
the
team
a
little
bit
longer
to
get
those
working,
but
essentially
all
works
now,
which
is
absolutely
fantastic
and
really
down
to
the
hard
work
of
the
fem
team.
More
than
more
than
anything
on
our
side,
really,
we
were
just
able
to
raise
a
few
bug
reports
and
have
those
fixed,
so
that
was
great
next
slide.
Yes,.
B
Here's
another
thing
that
I
mentioned
not
a
huge
match
to
say
here:
I'm,
just
showing
really
the
API
that
we
put
into
go
Nitro.
So
we
had
a
few
unknowns
in
the
design
and
the
architecture
of
how
to
do
payments.
We
weren't
sure
whether
we
would
have
consuming
code,
that
is
to
say,
applications
written
by
Third
parties,
actually
sending
the
payments
and
handling
that
in
the
end
we
decided
to
bring
it
almost
entirely
all
in-house.
B
So
we
just
have
a
pay
function
that
people
can
call
and
they
pass
in,
who
they're
paying?
How
much
and
go
Nitro
will
craft
the
payment
sign
it
send
it
to
the
counterparty
and
they
will
receive
a
notification
on
this
channel
here,
a
kind
of
event
stream
saying
you
have
been
paid
and
that
stream
is
something
that
they
could
hook
into
to
get
that
micropayment
relationship
set
up.
So
they
could.
B
The
next
thing
I
want
to
talk
about
is
the
test
ground
system
that
we've
set
up
so
test
ground
is
a
protocol
Labs
project
that
we
really
love
and
Alex
who's.
Also
on.
This
call
has
kind
of
been
working
closely
with
that
team
and
using
this
tool
to
the
max
really.
So
it's
something
we
use
to
throw
correctness
and
performance
of
our
code
and
it's
something
we
can
use
to
show
off
our
progress
quite
nicely
actually
and
we've
integrated
it
into
our
development
cycle.
Quite
personally
so
you'll
see
here
on
the
left.
B
When
anyone
pushes
the
change
to
our
repository,
we'll
get
a
test
run
kicked
off.
So
what
happens
there?
Well,
we've
got
a
cloud
VM,
that's
running
test,
ground
environment
and
what
happens
is
it
will
pull
the
code
from
our
repository
and
it
will
spin
up
lots
of
go
Nitro
nodes.
Some
of
those
will
be
players,
some
of
them
will
be
pays
and
some
of
them
will
be
intermediaries.
Sometimes
we
call
them
hubs
and
it
will
then
have
each
of
those
nodes
form
certain
actions
to
set
up
a
little
State
Channel
network.
B
So
they'll
all
get
a
connection
to
the
hub,
which
we
call
a
ledger,
Channel
and
then
they'll
use
that
to
spin
up
these
virtual
channels
running
that
virtual
fund
protocol
and
then
they'll
send
lots
and
lots
of
payments
through
those
virtual
channels.
Close
them
open
some
more,
and
we
run
that
for
60
seconds
and
this
kind
of
shows
off
lots
of
things.
Lots
of
functionality
of
our
system
that
we've
put
in
over
the
course
of
this
grant.
So
we
have,
as
I
mentioned
the
payments
apis
there.
B
A
A
B
So
what
we
wanted
was
something
running
the
ethereum
Json
RPC
interface,
because
that's
what
the
fvm
Mark,
like
roadmap,
ended
up
targeting.
So
we
chose
hard
hat,
which
is
like
a
really
popular
development
environment
for
evm
chains
and
Mike
from
our
team,
put
some
work
in
putting
that
inside
a
Docker
container
and
that
was
able
to
kind
of
seamlessly
well
not
entirely
seamlessly
but
quite
easily
it'd
be
absorbed
into
our
test
ground
environment.
B
We
had
to
submit
some
work
into
the
test,
ground
repo
itself,
building
on
some
stuff
that
Hannah
Howard
had
built,
and
we
just
kind
of
got
that
over
the
line
and
were
able
to
get
hard
hat
in
the
environment
too.
So
all
of
our
go
Nitro
nodes.
Actually
send
transactions
to
hard
hat
inside
test
ground.
B
So
that's
where
all
the
deposits
and
withdrawals
happened
and
that's
great
because
it's
exactly
the
same
interface,
it
means
once
we
have
it
running
successfully.
It
gets
hard
hat.
It's
basically
no
work
at
all
to
plug
it
into
something
like
wallaby
and
we've
actually
done
that.
So
we
can
run
this
quite
extensive
integration
test
against
a
real
blockchain
like
wallaby,
and
you
know
very
soon
in
the
next
couple
of
months
we're
going
to
be
running
that
against
PowerPoint
the
main
net.
So
that's
really
exciting.
B
So
not
only
do
we
have
runs
that
go
on
every
commit,
but
we
also
have
a
nightly
run,
so
we
can
kind
of
track
changes
over
time
and
each
run
that
gets
executed.
We
have
a
bunch
of
metadata
about
it
as
well
as
a
bunch
of
Statistics
that
we
gather
so
this
one
here
you've
got
a
run
ID,
which
essentially
matches
a
commit
in
our
Repository
and
various
parameters
that
we
set.
Like
the
duration,
the
number
of
actors.
B
We
also
have
some
traffic
shaping,
which
is
a
something
built
into
test
ground.
It's
really
easy
to
use.
So
we
have
the
messages
delayed
with
these
two
parameters
here,
so
there's
a
kind
of
10
millisecond
latency
and
a
one
millisecond
Jitter,
which
is
kind
of
Representative
of
a
reasonably
healthy
but
realistic,
Network
I.
Suppose
you
might
say,
we've
had
a
lot
of
fun,
making
it
a
lot
worse
and
we
can
investigate
what
happens.
You
know
in
the
really
optimistic
case
where
there's
zero
latency.
B
Those
things
are
interesting,
but
we
picked
something
we
thought
was
reasonably
realistic
to
to
gather
some
numbers
and
the
big
yellow
number.
There
is
ttfp
time
to
first
payment,
so
that's
essentially
measuring
the
time
it
takes
to
run
the
virtual
fund
protocol.
This
is
an
important
number
because
it's
the
delay
between
finding
someone,
if
you
like,
with
your
file
in
the
retrieval
market
and
starting
that
relationship
to
when
you
can
send
them
money
to.
A
B
So
the
first
change
is
the
intermediaries
can
exit
the
virtual
fund
protocol
early.
So
we
had
a
look
with
pen
and
paper
if
you
like
our
virtual
fund
protocol
and
we
try
to
trim
some
of
the
fat
out
of
it.
We
try
to
think
what's
really
necessary
and
what's
just
like
feels
right,
so
we
just
do
it
without
thinking
and
one
of
the
things
we
identified
is
that
there's
a
certain
step
where
Alice
and
Bob
need
to
wait.
B
B
B
So
you
you
kind
of
wait
a
bit
longer,
but
if
you're,
neither
of
those
parties,
you
could
be
the
single
intermediary
or
you
could
be
one
of
the
100
intermediaries
and
100
hot
payment.
You
get
to
finish
a
little
bit
early,
so
you
get
to
quit
the
protocol
and
go
ahead
and
do
some
more
work
on
maybe
a
different
virtual
fund
for
protocol
participants.
So
that's
one
little
change
we
made
and
the
second
one
we
decided.
B
A
B
It
good
green
and
everyone
has
green,
is
good
right,
so
yeah
we
were
kind
of
happy
with
that,
and
that
shows
a
really
nice
Improvement
in
the
performance
with
the
same
network
traffic
shaping
so
yeah
I,
just
rearranged.
Everything
I
just
said
into
a
slightly
different
kind
of
lists
to
make
it
a
bit
easier
to
stream
through
compared
to
our
grant.
So
we
upgraded
our
GTP
to
contract
and
we
deployed
it
to
an
evm
chain
and
we
also
deployed
and
benchmarked
a
test
Network
which
included
production,
messaging
and
dashboards.
B
A
B
So
that's
pretty
much
my
my
presentation
done.
I
just
thought:
I'd
give
a
little
bit
of
a
hint
about
what
we've
got
coming
up
next,
some
of
the
things
we're
looking
at
doing
in
the
next
six
months.
We
haven't
completely
settled
on
our
roadmap,
but
here's
just
a
flavor,
so
we're
going
to
have
our
contracts
on
farpoint
mainnet.
B
Everything
would
just
slow
down
to
a
halt,
so
we're
going
to
build
the
module
that
handles
that
situation
similar
to
this
we're
also
going
to
cope
with
a
loss
of
power
or
crushing
so
one
day.
You'll
be
sending
payments
using
our
protocol
from
your
smartphone
and
if
you
run
out
of
battery,
we
don't
need
to
lose
money
or
we
don't
need
to
have
to
go
to
the
blockchain.
I
necessarily
want
you
to
be
able
to
charge
up
your
phone,
restart
it
and
just
pick
up
where
you
left
off.
B
B
You
know
on
the
order
of
five
or
ten
notes
and
test
ground
can
take
us
far
beyond
that
to
thousands
or
tens
of
thousands
of
notes.
So
that's
something
we
are
really
interested
in
trying
out
and
it's
also,
as
I
said
before,
just
a
really
good
way
of
showing
off
some
of
those
other
things
so
we'll
be
able
to
run
test
ground
instances
and
then
start
killing
off
nodes
and
checking
that
everyone
else
recovers.
B
And
lastly,
we're
looking
into
doing
an
RP
Center
RPC
interface
around
our
software,
so
that
you
can
access
it
from
more
different
environments
in
more
different
languages,
including
in
the
browser
and
not
not
just
constraining
people
to
writing
applications.
You
can
go
so
yeah.
That's
the
end
of
my
presentation.
I've
got
this
final
little
slide
about
where
micro
payments
fit
in
the
retrieval
market.
So
talking
about
integrating
with
lotus
that's
kind
of
in
this
in
this
situation,
so
Patrick
you'll
recognize
this
diagram.
B
B
These
two
Saturn
nodes
are
kind
of
sitting
on
top
as
a
secondary
Market,
and
this
relationship
here
is
a
bit
tricky
for
us
to
put
micropayments
into
because
Saturn
L1
nodes
are
sort
of
being
paid
by
content
Publishers,
but
the
data
is
going
somewhere
else
directly
to
the
users.
So
we
don't
have
those
like
crossed
arrows
relationship
or
micropayments
make
the
most
sense.
So
we're
going
to
concentrate
more
on
the
relationship
between
the
kind
of
lower
levels
of
the
the
Saturn
Network
and
the
actual
sort
of
source
of
Truth
big
database.
B
That
has
everything
which
is
the
Lotus.
You
know
the
far
coin,
Network
itself
and
also
between
Quarry,
which
is
an
interesting
project
which
we
think
micro
payments
will
be
a
good
fit
for,
or
you've
got
like
clients
running
in
the
browser
who
need
to
get
blockchain
data
from
from
Lotus
nodes
and
are
willing
to
pay
for
that.
A
Yeah,
thank
you
so
much
great
presentation,
as
always
this
stuff
that
always
looked
beautiful
from
the
Magma
Team,
just
really
really
easy
to
understand
and
simple,
and
just
going
through
it
step
by
step.
So
thank
you
very
much
on
this
diagram
makes
complete
sense.
I
think
that
yeah,
that's
exactly!
A
You
identified
the
kind
of
assassin
floating
content
Publishers
to
the
to
the
users
that
that's
kind
of
covered,
a
space
by
the
Assassin
payment
mechanism,
but
as
we
go
a
little
bit
further
down
the
levels,
the
market
payments
become
much
more
of
a
good
fit
and
then
Quarry,
as
that
starts
to
gather
momentum.
That's
yeah!
That's
definitely
a
good
fit
as
well,
because
it's
going
to
be
much
more
in
this
sort
of
yeah,
just
completely
completely
trustless
model,
where
the
micropayments
are
yeah.
A
Much
a
much
better
fit,
really
super
exciting
to
see
that
the
works.
The
work
like
all
the
work
you
guys
have
done
with
the
fem
team
and
how
we're
going
to
be
getting
smart
contracts
out
pretty
quickly
after
launch
and
I,
think
that
that
just
shows
as
well
that
it's
almost
it
almost
puts
this
whole
project
into
the
position.
Where
well
kind
of
I.
Guess
higher
level
teams
can
use
it
as
a
building
block
and
say
hey.
We.
A
B
Yeah,
that's
right
we're
actually
thinking
of
yeah
there's
the
space
for
hackathon
going
on
this
week
and
next
and
we
were
going
to
try
and
do
a
workshop
where
we
can
encourage
people
to
you
know
build
on
top
of
nitro
for
whatever
application
they
might
be
thinking
and
building.
So
yeah
that
lines
up
what
you
said.
A
Yeah,
that's
a
great
point
and
in
these
in
these
hackathons
build-a-thon
site,
I
think
they
do
have
a
kind
of
toolbox,
part
of
it
where
they
say
like.
Oh,
these
are
the
tools
that
you
can
hack
around
with.
So
if,
if
we
can
get
that
this
into
that
list,
then
people
are
going
to
start
understanding
what
it
is
hacking
around
with
it
and
we'll
just
start
to
see
it
appearing
as
a
dependency
in
in
more
depths
I
guess.
A
B
Really
really
exciting:
that's
what
we're
aiming
for.
We
actually
have
some
kind
of
material
already
that
Colin
produced
for
a
project
called
Speed,
Run,
ethereum
I'm,
not
sure
if
you've
heard
of
it,
but
it's
effectively
like
a
a
kind
of
tutorial
system
that
you
can
do
on
ethereum
and
once
you
get
a
long
way
through
and
you're
like
a
seasoned
or
you're
like
a
beginner
salinity
developer,
you
get
onto
the
state
channels
Challenge,
and
you
have
to
build
a
little
peer-to-peer
stage,
Channel
system
and
call
and.
B
Yes,
we
we
have
brought
a
bit
further
with
that
and
I.
Don't
think.
We've
got
the
final
answer,
but
we
we
spent
some
time
thinking
about
how
they
could
extract
fees
from
this
system,
and
we
want
a
few
things
from
that
mechanism.
I
suppose
we
want
it
to
be
a
kind
of
open
protocol
if
you
like,
so
intermediaries
should
be
able
to
set
the
fees
that
they
want
in
in
the
free
mechanisms.
So
they
may,
they
may
charge
some
kind
of
flat
rate
for
opening
a
virtual
Channel.
They
might
charge
per
payment.
B
B
But
then,
on
the
flip
side,
we
want
to
make
it
impossible
for
people
to
lose
money,
for
example
by
by
doing
things
incorrectly,
and
we
also
want
to
take
account
of
you
know:
what
are
the
opportunity
costs
for
intermediaries,
how
how
they
expect
to
be
compensated
for
what
they're
doing?
So,
if
you
think
about
what
intermediaries
do
they
lock
up
capital
for
a
certain
amount
of
time?
So
you
ideally
you'd
want
intermediaries
to
be
compensated
per
unit
time,
but
that's
a
bit
tricky
with
State
Charles
and
it
if
you're,
not
careful.
B
You
introduce
new
incentives
for
for
Bad
actors
who
may
wish
to
like
keep
a
channel
open
for
longer
than
is
really
necessary,
or
maybe
they
want
to
open
the
channel
close
it
immediately,
because
that
would
enable
them
to
earn
more
money.
So
there's
a
few,
a
few
Corner
cases
and
and
things
like
that
to
work
out,
but
we
think
we're
close
to
a
mechanism
where,
where
intermediaries
basically
get
paid
a
percentage
of
the
money
that
they
they
stake
on
these
on
these
virtual
channels.
So
that's
coming
soon.