►
From YouTube: Retrieval Market Builders Demo Day - Magmo & Retrieval Markets Lab - November 23, 2022
Description
Every other week, 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.
In this video, you can find quick demos from -
• Magmo on future directions for State Channels
• RM Lab introducing Quarry
A
Welcome
to
this
edition
of
the
retrieval
markets
demo
day,
today's
date
is
Wednesday,
the
23rd
of
November
2022.
Happy
Thanksgiving.
Tomorrow
to
our
American
colleagues.
Today,
we've
got
two
very
exciting
talks.
We've
got
Colin
Kennedy
from
magmo
speaking
about
some
ideas,
he's
had
for
the
go,
Nitro
magma
work,
and
then
we
have
Alex
Camuto
protocol
Labs
talking
about
quarry
a
new
data
availability
tool
over
to
you,
Colin.
B
All
right,
thank
you,
see
if
I
can
share
a
screen.
B
How,
how
is
that
I'm,
seeing
a
presentation,
looks.
A
B
Okay
yeah
so
I
mentioned
I'm
Colin,
Kennedy
team,
magmo
and
I'm,
presenting
some
it's
kind
of
slightly
contrary
to
the
spirit
of
a
demo
Dave.
This
is
the
opposite
of
a
demo.
These
are
slightly
far-flung
ideas,
but
their
their
ideas
that
that
are
applicable
to
the
Toshiba
Market
working
group,
I
think
so
yeah
possible
futures
for
State
Channel
Networks,
and
this
is
very
much
an
Outsourcing
presentation.
B
B
Most
of
the
people
present
right
now
are
pretty
familiar,
but
just
kind
of
due
diligence
for
anyone
who
who
stumbles
across
this
and
then
I
will
talk
about
three
research
questions
which
we'll
get
more
speculative
as
we
go,
and
with
respect
to
the
preliminaries
I'll
point
out
that
two
of
my
teammates
recently
gave
very
good
talks
at
the
retrieval
Market
Summit
in
Lisbon.
These
talks
are
now
available
on
YouTube.
There
are
links
in
the
filecoin
slack
Channel,
retrieval
markets,
but
I.
B
Think
if
you
just
search
for
these
titles,
you
should
find
them
on
on
YouTube
and
they
will
give
a
good
overview
of
what
we're
building
and
recent
recent
progress,
and
all
of
that
so
diagrams
in
this
presentation
will
have
basically
four
elements.
There's
a
blockchain,
a
contract
which
is
as
rounded
corners
channels
are
circles
and
arrows
are
funny
commitments
and
a
funding.
Commitment
basically
means
that
the
thing
being
pointed
from
has
funds
that
are
specifically
addressed
to
the
thing
being
pointed
to
so
yeah.
B
What
what
is
the
channel
say,
Alice
and
Irene
want
a
high-speed
low-cost
transactions.
They
would
like
to
make
a
channel
they
they
use
a
channel
to
do
that.
They
perform
a
handshake
to
spin
up
a
unique
address.
B
B
Now
they
can
interact
inside
of
this
channel
totally
off
chain
and
eventually
come
back
and
settle
it
when,
when
they're
done,
what
is
a
Channel
network?
Well,
we
just
kind
of
grow.
This
situation
say
Irene
and
Bob
have
a
channel
via
the
same
means
above,
but
now
imagine
that
Alice
and
Bob
want
to
transact.
They
have
better
options
now
than
funding
Unchained.
They
can
use
their
existing
channels
and
their
their
relationship
with
the
common
intermediary
Irene,
and
this
is
now
100
off
chain
operation.
B
B
So
that's
it
for
preliminaries
you're
you're,
basically
caught
up
on
State
Central
networks
as
at
the
state
of
the
art.
B
So
the
first
idea
that
we're
going
to
talk
about
today
is
optimistic
seed
funding
for
for
virtual
channels,
and
this
is
really
something
that
is
focused
on
user
experience
for
clients
in
a
retrieval
Market
setting
So.
Currently,
clients
make
unchain
deposits
with
hubs,
so
apologies
I'm,
going
to
use
like
Hub
and
intermediary
somewhat
interchangeably.
Irene
in
this
diagram
is
a
hub
for
the
network.
Alice
has
a
Channel
with
Irene
on
chain.
B
Bob
has
a
Channel
with
Irene
on
chain
and
the
Alice
Bob
virtual
Channel,
which
is
kind
of
like
the
the
business
channel
of
a
retrieval
Market
that
gets
created
on
demand.
But
what
could
be
done
instead
is
that
these
channels
could
be
created
proactively,
and
you
would
do
this
to
to
drive
down
average
time
to
first
payment.
So
with
the
existing
file
coin
payment
channels,
the
time
to
first
payment
is,
is
quite
slow.
It's
on
the
order
of
the
file
Coin
Block
time
with
on-demand
virtual
channels.
B
The
time
to
first
payment
is
hovering
around
100
milliseconds
right
now.
Alex's,
talk
in
particular
goes
into
detail
about
how
we
are
measuring
and
benchmarking
that
number,
but
with
an
optimistic
seating
Network.
The
average
time
to
first
payment
could
look
something
like
10
milliseconds
and
that
10
10
millisecond
average
is
populated
by
a
whole
bunch
of
zeros
and
the
occasional
100
millisecond
of
the
on-demand
virtual
Channel.
B
So
how
do
we
do?
This
is
kind
of
made
possible
by
expected
Market
forces
and
and
the
power
law
that
applies
to
networked
services
on
the
internet
in
general,
so
in
a
mature,
retrieval
Market,
we
expect
popular
content
to
be
densely
served
everywhere.
B
How
we
localized
content
should
be
densely
served
in
its
little
in
their
local
markets,
and
the
power
law
says
that
most
of
your
retrieved
content
will
actually
come
from
a
small
number
of
providers
and
in
particular,
like
the
providers
who
are
closest
to
you,
are
aiming
to
serve
you
most
of
your
content.
B
So
if,
with
some
made
up
numbers,
if
90
of
your
retrievals
come
from
fewer
than
100
specific
providers,
then
optimistic
seed,
funding
of
channels
like
keeping
a
channel
warm
for
those
providers
provides
a
very
good
trade-off
and
you
get
very
fast
service,
fast
trustless
service
from
those
retrieval
providers.
B
The
reason
why
you
don't
want
to
do
this
kind
of
the
opposite
side
of
this
trade-off
space
is
that
when
you
have
a
whole
lot
of
channels,
there
are
limits
to
how
much
data
can
be
crammed
into
one
channel
so
to
get
around
those
limits.
You
have
to
use
recursion
in
your
your
Ledger
funding.
B
You're
sort
of
your
channel
that
is
funded
on
chain
has
to
fund
a
bunch
of
other
channels
which
fund
a
bunch
of
other
channels,
and
this
is
bad
enough
for,
for
a
retrieval
client
around
the
provider
side
we
sort
of
are
building
for
a
future
where
there
are
many,
many
many
many
retrieval
clients.
You
know
talking
like
devices
on
the
internet.
B
The
number
of
of
of
channels
that
you're
expecting
to
manage
here
could
grow
to
a
size
that,
like
you,
can't
actually
store
store
the
data
in
memory
or
on
device.
So
this
is
yeah.
This
is
the
trade-off,
so
initiative
number
two
is
kind
of
a
multi-root
or
a
cross
chain,
State
Channel
network.
B
So
what
is
that
currently,
our
intermediary
Irene
brokerage
transactions,
that
is
that
are
anchored
by
a
Singleton
smart
contract,
but
she
could
potentially
instead
broker
transactions
that
are
anchored
by
multiple
smart
contracts
on
multiple
blockchains
and
we'll
kind
of
zoom
into
the
security
Model
A
little
bit
to
commit
to
explain
how
that
works.
B
So
currently
Alice
and
Bob
open
up
the
virtual
Channel,
and
it's
it's
taken
for
granted
that
there's
a
there's
a
publicly
viewable
route
to
all
of
this
funding,
and
it's
the
the
blockchain,
but
really
I
mean
it's.
It's
specifically
in
a
our
Nitro
adjudicator
smart
contract
that
lives
on
chain.
Nitro
is
the
name
of
our
protocol.
If
I
haven't
said
so,
and
it
is,
it
has
custody
of
these
funds,
but
really
inside
of
the
inside
of
that
contract.
B
It
it
indexes
all
of
these
funds
for
specific
channels
and
we've.
You
know:
we've
made
a
lot
of
effort
over
the
years
to
to
build
a
lot
of
confidence
that
this
Alice
Bob
virtual
channel
is
secure
for
all
participants,
but
the
security
path
for
each
participant
is
actually
unique.
B
So
imagine
that
Alice
and
barber
in
this
Channel
and
then
Bob
Bob's
computer
catches,
fire
and
Alice-
wants
to
recover
some
sizable
amount
of
funds
that
are
in
the
channel,
but
she
can't
do
it
collaboratively
with
Bob.
The
way
this
works
is
that
Alice
takes
statements
from
from
the
Alice
Bob
virtual
Channel.
She
takes
statements
from
her
Ledger
Channel
brings
both
of
these
back
to
the
blockchain,
the
adjudicator
contract
and
says:
hey
I.
B
Have
these
running
channels
IMO
this
much
the
adjudicator
reads
these
statements
and
pays
out
in
a
way
that
is
fair
according
to
those
statements
and
in
particular,
Fair
fair
to
Alice.
B
So
this
is
a
Alice's
security
path
on
the
channel
and
Bob
has
a
similar
security
path,
but
it
goes
back
through
through
his
channel
notable
is
that
Alice
does
not
care.
She
does
not
have
a
vested
interest
in
the
funds
that
are
allocated
to
channel
ABC
here
in
the
Bob
Ledger
Channel.
B
She
she
cares
so
little
about
it
that
those
funds
could
be
somewhere
else
entirely
say
in
a
different
adjudicator
contract.
We
have
adjudicators
one
and
two
and
those
different
adjudicators
can
live
on
different
chains
or
they
can
live
on
different
subnets
in
the
style
of
file
coins
hierarchical
consensus
roadmap.
B
B
We
have
had
this
idea
release
the
seat
of
this
idea
for
at
least
a
year
According
to
some
old
notion
documents,
but
it
sort
of
came
back
to
the
front
burner
when
we
were
in
Lisbon
and
learned
about
that
the
hierarchical
consensus
roadmap,
so
the
key
protocol
modification
that
makes
all
this
possible
is
adding
a
little
more
detail
in
in
the
accounting
of
of
Channel
balances.
B
Previously,
the
accounting
essentially
labels
assets
and
declares
where
those
assets
are
pointed
to
who
who
has
who
has
what
ballots?
B
But
now
we
add
a
full
qualification
for
those
assets
not
only
where
those
balances
are
owed,
but
where
we
expect
those
balances
to
be
coming
from,
and
this
lets
us
label
assets
that
should
live
at
different
funding
routes
for
the
network.
B
This
lets
us
set
up
an
exchange
of
asset
channel,
so
here
in
this
channel
between
Alice
and
Bob,
Alice
can
pay
in
in
Heath
or
whatever
erc20
she
has
used
to
fund
the
Alice
Irene
Channel
Bob
is
paid
in
infill
or
whatever
fem,
to
erc20
ish
coin,
that
that
exists
in
the
fbm
future,
and
this
is
really
abstracted
away
for
each
participant.
B
The
security
in
the
in
the
Alice
Bob
Channel
is
denominated
in
their
native
asset
for
each
participant.
So
if
things
go
wrong,
Alice
still
takes
that
same
bat
path.
She
takes
it
back
to
the
ethereum
blockchain.
If
things
go
wrong
for
Bob,
he
takes
his
security
path
back
to
the
file
coin
chain.
Neither
participant
particularly
cares
about
what
asset
the
other
person
is
denominated
with.
I
mean
at
a
certain
level.
There
are
Nitro
client
software
knows,
but
they
don't
know
or
care.
An
exchange
rate
is
kind
of
determined
at
runtime.
B
When
you
spin
up
the
channel,
you
set
an
exchange
rate
between
the
assets
and
Irene
services.
This
exchange
very
much
the
same
way
that
she
Services
existing
virtual
channels,
so
consequence
here
is
that
these
channels
can
exist
on
any
number
of
evm
compatible
runtimes,
including
like
arbitrary
theater.
That
is
a
roll-up
on
top
of
ethereum,
but
there's
no
reason
it
couldn't
have
an
adjudicator
that
is
managing
funds
and
Alice
Bob,
Carroll
and
Dave.
B
Here
all
have
Channels
with
Irene,
and
any
pairwise
couple
from
from
that
set
can
spin
up
a
virtual
Channel
Through
Irene,
where
they
pay
in
their
preferred
asset
and
are
paid
in
their
preferred
asset
and
kind
of
similar
like
the
intermediary
to
Services.
The
Exchange
sees
an
increase
in
one
asset
and
a
decrease
in
the
other
in
a
way
that
is
deemed
fair
at
runtime.
B
So
our
kind
of
research
focuses
on
the
establishment
of
channelized
applications
with
like
this
high
throughput,
but
it's
also
notable
that
you
know
Nitro
can
also
do
just
like
a
vanilla
payment,
so
this
sort
of
network
would
also
serve
as
as
a
background
for
like
Universal
cross
chain,
L2
payments,
point
of
sale
payments.
There's.
No
reason
why
your
coffee
shop,
who
wants
to
get
paid
in
I,
don't
know
on
arbitrum,
can't
present
you
with
a
QR
code
that
lets
you
in
network
create
a
payment
for
them
with.
B
You
know
fast
settlement
like
three
seconds
serviced
by
by
these
intermediaries
in
the
network,
so
yeah
I
mean
that's,
that's
that
and
the
last
idea
is
around
activating
the
latent
collateral
in
a
network.
So
this
is
really
about
Capital
efficiency
and
the
I
guess
the
macro
economic
picture
in
a
network.
B
This
is
sort
of
the
maybe
the
most
exciting
in
the
bunch,
but
it's
also
the
most
subtle
and
Abstract,
so
apologies,
but
describing
the
background
for
the
problem
or
or
like
this
issue,
talk
about
two
problems
inside
of
State
Central
networks,
as
as
currently
conceived
and
problems
may
be
too
strong.
A
word
it's
just
sort
of
like
these
are
things
that
happen
as
a
result
like
in
the
trade-off
space
for
getting
the
nice
things
about
State
Channel
Networks.
B
The
security
guarantees
in
these
networks
are
capital.
Intense
we've
talked
about
it
already.
Each
participant
in
the
virtual
Channel
needs
a
path
back
to
to
an
adjudicator
which
is
fully
funded
when
Bob
ghosts.
Here.
Alice
takes
her
path
back
if
Alice
ghosts,
then
Bob
needs
to
take
his
path
back,
but
essentially
that
means
that
the
channel
itself
is
doubly
funded
and
that's
in
the
best
case
scenario,
if
you're
going
across
multiple
immediate
intermediaries
that
funding
multiplier
increases.
B
So
that's
problem
number
one
Capital,
intense
security,
Capital
two
is
dormant
Capital
inside
of
Ledger
channels,
so
say
that
you
are
a
a
client
in
a
retrieval
market
and
you
deposit,
fifty
dollars
to
to
consume
content,
but
you
spend
about
a
dollar
a
day.
You've
got
this
substantial
balance
sitting
there.
That
is
mostly
idle,
and
you
know
in
in
the
cryptocurrency
space
in
general,
we
don't
love
idle
balances.
B
We,
like
our
our
networked
Capital
to
be
to
be
active
and
if
you
look
at
both
of
these
problems
at
the
same
time,
you
know
the
network
takes
too
much
capital
for
security,
and
the
network
has
too
much
Capital
lying
around.
It
screams
opportunity
if
Alice's
deposit
here
can
be
used
in
a
secure
way
to
provide
for
the
capital
requirements
of
the
security
guarantees
that
Alice
would
have
a
chance
to
participate
in
the
earnings
of
the
network.
B
B
So
the
sort
of
the
approach
to
this
is
to
to
notice
that
the
capital
in
Ledger
channels
is
is
doing
at
least
two
things,
but
I
think
it's
doing
these
two
things
which
are
slightly
distinct.
B
It
is
providing
runtime
security
for
virtual
channels
and
runtime
security
here
means
like
being
there
on
that
challenge
path.
If
something
goes
wrong
in
Alice
Bob,
then
Alice
and
Bob
can
use
their
Ledger
channels
to
recover
those
funds
at
runtime,
but
the
other
thing
that
the
ledgers
channels
do
is
that
they
do
the
accounting
for
all
of
Alice's
total
spend
in
the
network,
and
they
do
the
accounting
for
all
of
Bob's
total
earnings
in
the
network.
B
So
it's
doing
both
of
those
things
at
the
same
time,
if
these
responsibilities
can
be
separated,
then
I
think
there
are,
there
are
gains
and
maybe
they
can
be
separated.
The
important
idea
is
to
make
assumptions
about
about
different
participants
being
either
Spenders
or
earners
in
the
network
and.
B
B
So,
let's
build
out
this
network
spender
Alice
deposits
into
the
network,
and
then
she
uses
some
of
her
dormant
cattle
collateral
to
virtually
find
a
ledger
channel
for
some
earner.
Bob
now
Bob
is
going
to
use
this
channel
as
he
as
he
normally
would,
for
example,
to
fund
a
Channel
with
Carol.
B
But
what
about
these
two
jobs
of
Ledger
capital,
so
runtime
security
is
unchanged
for
Carol.
She
takes
the
same
path
back
to
chain,
and
it's
really
no
different.
It's
slightly
modified
but
still
present
for
Bob
is
not
a
lot
of
difference.
The
rules
of
the
Alison
Ledger
channel
would
have
to
be
modified,
such
that
that
Bob
has
some
challenging
rights,
but
this
is
not
very
difficult
and
the
other
job
of
earnings,
accounting
in
the
status
quo,
go
Nitro.
B
Network
closing
the
Bob
Carroll
virtual
Channel
causes
those
balances
to
Bubble
Up
to
the
two
channels
that
funded
it.
That
works
the
same
here
for
Carol
the
closure
of
Bob
Carroll
bubbles
up
and
causes
an
adjustment
in
the
Carol
Irene
Hunter
Channel,
but
nabab
Irene
virtual
Ledger
channel.
It's
important
to
notice
to
note
that,
like
neither
Bob
nor
Irene
actually
own
that
money,
that
is,
that
is
Alice's
money.
B
So,
instead
of
having
that
balance
bubble
up
to
the
channel,
Bob
collects
vouchers
which
are
payable
by
Irene
at
the
closure
of
Bob
Carroll
and
I.
Read
Irene's
debts
here
that
she's
accruing
to
to
Bob.
They
are
offset
by
her
earnings
in
on
the
other
side
in
the
Carol
Irene
channel,
so
she's
happy
to
participate.
B
So
this
is
a
rough
sketch.
This
is
like
kind
of
like
early
stages
for
this
idea
and
work
as
I'm
going
to
make
it
sort
of
robust
and
zero
trust
to
somewhere
between
trust,
minimized
and
zero
trust,
with
well-defined
time
to
cash
out
for
for
earners
in
the
network.
B
Previously,
only
the
hubs
who
are
servicing
this
Capital
would
earn
earn
interest
and
client
client
money
would
sit,
sit
idle
with
active
collateral
clients
depositing
into
the
network
to
consume
services
would
would
earn
interest
on
their
on
their
deposits,
and
it
also
really
drastically
lowers
the
capital
requirements
for
hubs
to
to
participate
in
the
network
because
they
aren't
they.
C
B
The
money
for
for
all
of
the
transactions,
the
money
comes
from
consumers,
so
wrapping
up
talked
about
three
initiatives:
there's
optimistic
seed
funding,
which
will
definitely
work,
but
the
impacts
are
really
hard
to
estimate
based
on
like
how
much
of
your
content
is
coming
from
a
small
number
of
providers,
so
the
impact
is,
is
really
hard
to
guess.
The
impact
could
be
really
really
poor
under
certain
Network
topologies,
but
it'll
work.
The
cross
chain
chain,
Nitro.
B
That
we've
talked
about
this
in
in
some
detail
like
no
and
we're
pretty
sure
that
it's
that
it's
workable
potential
impact
is
that
service
providers
have
access
to
a
bigger
variety
of
capital
networks
that
could
join
the
network
and
pay
for
stuff
and
as
a
potential
like
a
universal
across
cross-chain
payment
L2
for
for
evm,
compatible,
blockchains
and
active
collateral.
This
is
still
kind
of
speculative
there
are
there
are
holes
in
in
this
idea
still,
but
it
it
should
as
an
impact.
B
It
should
definitely
lower
the
overall
Network
fees,
but
I
would
you
know
very
rough
guess,
but
at
least
30
percent
and
the
bigger
impact
is
that
the
sort
of
macroeconomic
picture
of
the
network
is
that
end
users
share
in
the
network.
Profits
which
is
a
pretty
happy
happy
place
to
be
for
a
decentralized
service
network
and.
C
B
It
so
thanks
happy
happy
to
have
questions,
but
you
can
check
out
us
at
magma.com,
email,
research,
magma.com
or
otherwise
talk
with
people
in
the
retrieval
Market.
A
Awesome
thanks
Colin
that
was
super
interesting.
Any
quick
questions.
E
A
My
question
was
a
bit
of
a
joke
because
I
just
did
I
thought
she
wouldn't
want
to
give
up
a
lovely,
far
coin
for
for
ethereum.
But
but
you
know,
I
think
that's
really
interesting.
The
idea
that
it
becomes
sort
of
like
a
a
market
of-
and
you
can
yeah
you
can
just
have
the
exchange
between
those
assets
happen.
Yeah.
B
B
A
comment
on
that
is
that,
like
the
exchange
rate,
all
those
assets
is
determined
at
runtime
at
each
each
Channel
creation,
but
the
person
servicing
the
exchange
isn't
trying
to
make
money
from
you
on
the
exchange
itself,
because
they
are
the
the
they
are.
The
people
who
actually
swap
assets
right,
like
Irene
gains
gains
Heath
on
one
side
and
loses
fill
on
the
other
side.
B
So,
like
the
intermediaries
in
that
network,
aren't
looking
to
make
money
on
the
the
actual
exchange,
the
exchange
rate
because,
like
they
are
the
bearers
of
the
exchange
rate,
so
yeah.
That's.
B
You
hates
changing
one
thing
for
another
thing,
then
then
she
can
just
like
slope.
The
exchange
rates
in
that
direction.
A
Gotcha,
okay,
Walker
had
a
question
Walker.
Do
you
want
to
do
you
want
to
say
it
out
loud.
C
Hey
I
think
George
answered
it.
I
was
just
Thinking
Out
Loud
that
these
channels
might
be
somewhat
short-lived.
Such
that
Irene
has
the
chance
to
rebalance
if
necessary,
and
the
exchange
rate
would
be
set
up
such
a
way
that
yeah,
it's
not
she's,
not
exposed
to
the
the
risk.
So
much
of
of
differences
between
the
assets.
B
Yeah
so
I
mean
anytime,
you
I,
guess,
set
an
exchange
rate
and
then
commit
to
it.
You
have
like
a
a
slippage
risk
right.
If
you
find
one
of
these
channels
and
then
like
there's,
a
video
of
metallic
strangling
a
puppy
then
like
eth
could
drop
off
a
cliff,
but
no
I
mean
in
the
retrieval
Market
in
particular.
B
Like
a
lot
of
these
channels,
I
don't
expect
to
be
pretty
short-lived,
so
I
think
that
insulates
you,
but
that's
that's
a
a
calculation
that
people
would
have
to
to
do
for
themselves.
I
guess
like
how
much
how
much
Capital
over
what
sort
of
time
frame
are
you
willing
to
commit
to
at
a
certain
exchange
rate
at?
B
But
the
other
thing
is
that
this
risk
isn't
actually
borne
by
the
intermediary.
Is
it
yeah?
It
is
it's
born
by
that
risk
is
borne
by
by
all
parties
in
the
channel,
I
think
yeah.
So
generally,
like
those
virtual
channels,
we
expect
them
to
to
mostly
be
fairly
short-lived
I.
Think
it's
the
the
main
answer
to
that
question.
A
Nice,
okay!
Well!
Thank
you
very
much
and
I
think
we'll
move
yeah,
we'll
move
on
now,
just
the
interest
of
time
to
Alex
he's
going
to
talk
about
Quarry.
D
And
everybody
see
that
right,
I'm
gonna
assume
you
can
so
I
am
going
to
be
introducing
Corey,
which
is
the
project
Tomah
and
I
have
started
working
on
since
we
joined
protocol
Labs
after
being
a
mile.
So
for
those
of
you
who
don't
know,
we've
been
working
on
the
retrieval
markets
problem
for
quite
a
long
time,
almost
two
years
and
it's
a
pretty
particularly
thorny
problem.
D
If
you
are
trying
to
design
a
broad-based
retrieval
market
for
all
kinds
of
data
and
there's
a
whole
host
of
reasons
for
why
that
is.
But
after
two
years
we
decided
to
really
go
back
to
basics
and
ask
the
question
as
to
what
data
is
most
in
demand
within.
You
know
the
decentralized
web
or
within
blockchains,
but
it
is
somewhat
difficult
to
access
for
clients
that
want
to
fetch
this
content,
and
the
answer
we
came
to
was,
you
know
a
block
chain
state,
so
the
global
state.
D
D
You
know
it
might
be
the
percentage
of
yield
you're
getting
on
some
D5
smart
contract,
and
you
want
to
be
able
to
to
know
what
that
yield
is
before
you
make
a
decision
as
to
whether
you
want
to
put
your
money
in
a
liquidity
pool
so
who
currently
sort
of
ingests
that
state
you
know
browser
clients
or
browser
wallets
like
metamask
need
that
state
or
you
know
certain.
D
What
applications
like
dapps
are
currently
need
to
view
that
state
to
users
mobile
wallets,
need
that
state
to
be
able
to
issue
transactions
correctly
or
interact
with
apps
as
well,
but
also
other
chains
and
smart
contracts
on
other
chains
might
want
to
know
the
state
of
a
of
another
chain
like,
for
example,
if
you're
building
a
bridge
between
two
chains,
one
smart
contract,
you
might
need
to
know
the
state
of
a
smart
contract
on
another
chain,
so
they
can
Bridge
assets
correctly,
and
so
the
the
the
commonalities
between
these
consumers
of
state
is
that
they're
typically
really
resource
constrained.
D
If
you're
a
secret
contract,
you
know
you're
an
extremely
resource
constrained.
Environment
operations
are
very
expensive,
and
this
is
sort
of
similar
to
this
also
applies
to
browsers
and
and
mobile
wallets.
So
you
can't
really
sync
the
full
chain
to
be
able
to
get
an
up-to-date
and
trustless
view
of
the
state
that
you
want
to
ingest
and
you're
sort
of
siled
from
the
blockchain
network
as
well,
because
you
might
not
have
you
know
the
networking
protocols
that
full
nodes
run,
and
so
what
are
the
current
solutions
to
this
problem?
D
As
I'm
sure
you
know,
you
know,
most
of
us
interact
with
adapts
using
centralized
service
providers,
so
in
Cura
or
other
hosted
services
will
run
a
fall
node
for
you
and
your
node
or
sorry.
Your
wallet
will
connect
via
HTTP
or
RPC
to
that
node
to
get
the
latest
State
and
you're
sort
of
trusting
that
that
service
provider
is
delivering
you.
You
know
the
latest
and
greatest
date
that
you
should
be
acting
on
and
in
terms
of
communications
between
chains.
D
You
know
we
have
centralized
Bridges
using
multi-cigs
or
or
hdb
oracles
that
are
sort
of
relaying
date
between
the
between
two
chains.
So
what
are
the
problems
with
these
sorts
of
approaches?
Well,
the
issue
primarily
in
the
case
of
the
posted
poll
notes
is
that,
if
inferior,
for
example,
goes
down,
you're
not
going
to
be
able
to
interact
with
most
of
the
applications
that
you
know
and
love.
Metamask
has
famously
had
issues
as
soon
as
empira
has
gone
down:
you're,
not
able
to
dispatch
transactions
or
issue
or
access
your
funds.
D
And
similarly
we
there
have
been
a
whole
host
of
issues.
You
know
in
centralized
bridge
architectures
I
mean
we've
lost
1.3
billion
dollars
to
hacks
this
year,
sometimes
because
there's
only
one
or
two
oracles
that
are
surveilling,
you
know
for
the
state
between
the
bridges
and
relaying
it
sometimes
because
you
know
the.
C
D
So
really,
what
we're
trying
to
do
with
this
with
Corey
is
we're
trying
to
design
a
effectively
a
retrieval
protocol
which
enables
like
clients,
whether
they're
in
the
browser
or
they're,
in
a
smart
contract
to
Simply
sync
Falcon
block
headers
and
to
trustlessly
retrieve
the
state
associated
with
that
block
header,
and
so
what
are
some
of
the
design
constraints
we've
given
ourselves?
D
So
we
want
like
clients
to
be
able
to
succinctly
verify
the
Integrity
of
filecoin
block
headers.
We
want
them
to
also
be
able
to
determine
that
the
state
they're
retrieving
matches
that
pointed
to
by
the
latest
header
they've
just
received
in
the
case
of
browsers.
We
want
them
to
be
able
to
broadcast
new
transactions
to
the
network
without
a
hosted
intermediary.
D
Clients
should
be
able
to
receive
all
of
this
directly
from
what
we're
calling
Corey,
retrieval
notes
and
query.
Nodes
and
Taran
should
be
compensated
for
delivering
these
block
headers
and
for
delivering
this
state,
and
we
don't
want
to
place
an
undue
burden
on
query
nodes,
for
example,
to
to
have
authority
issued
certificates
or
to
have
public,
IPS
and
so
I
guess.
The
broader
question
is:
how
is
this
a
retrieval
Market?
D
Well,
if
you,
if
you
think
about
the
the
design
of
the
problem
and
the
constraints
of
it,
it's
really
just
a
retrieval
Market,
where
we're
very
opinionated
as
to
the
data
that
the
nodes
are
delivering
and
serving
so
it's
one
where
the
market
and
where
the
data
is
blockchain
State.
D
D
Our
network
is
going
to
be
built
on
browser
to
browser
or
browser
to
server
peer-to-peer
transports
much
in
the
same
way,
it's
still
going
to
require
peer
Discovery
in
a
decentralized
fashion
and
we're
still
going
to
need
to
design
incentive
mechanisms
to
to
compensate
query
nodes
for
delivering
content.
So
it's
very
similar
to
the
retrieval
Market
setup,
we're
just
reducing
the
problem
to
a
one
where
the
the
data
that
we're
serving
is
one
that
we
know
is
currently
high
in
demand.
D
Currently,
we're
focused
on
the
alpha,
which
is
just
a
browser
client
that
can
directly
fetch
state
from
filecoin
Full
nodes.
They
can
also
issue
messages
directly
to
this
whole
notes
and
get
this
included
in
the
message
pool
for
the
beta
we're
going
to
be
working
on
a
succinct
verification
protocol
so
that
clients,
whether
they
are
in
the
browser
or
they're
a
smart
contract,
can
subsequently
verify
block
Integrity
or
a
state
that
they
receive
the
next
version.
D
We're
going
to
be
focusing
on
the
design
of
incentives
to
reward
query
nodes
for
providing
the
service
and,
finally,
we're
going
to
be
looking
to
integrate
into
compatible
browsers
like
Brave
or
directly
into
into
browsers
that
support
wallets,
like
metamask
as
part
of
our
our
first
release
and
preview
concept.
So
it's
still
early
days.
But
if
you
want
to
check
out
the
project,
we
have
a
GitHub
repo,
where
we've
got
some
preliminary
Explorations
towards
delivering
this.
D
So
if
you
want
to
take
a
look
check
it
out
or
if
you
want
to
contribute,
also
feel
free
to
reach
out
I'm
sure,
there's
going
to
be
some
more
talks.
Where
I'll
have
the
opportunity
to
dive
into
like
the
design
of
this.
A
bit
more.
But
I
just
wanted
to
provide
sort
of
like
a
high
level
overview
of
the
the
project
and
some
of
the
motivations
that
independent
and
that's
it
really.
A
Nice
thanks
Alex
any
questions.
A
I
might
just
ask
you
quickly
just
to
clarify:
could
you
just
explain
why
it's
called
Dash
Quarry.
D
Well,
okay,
so
the
the
problem
is
very
related
to
data
availability,
sampling,
which
is
sort
of
adjacent
problem
of
making
blockchain
State
widely
available
or
blockchain
headers
widely
available
to
nodes,
and
that's
why
the
project
is
called
Das
query.
This
is.
A
A
I
yeah
did
I
hear
someone
else
with
a
question.
I.
D
E
It's
super,
exciting,
yeah,
I.
Think
it's
great
I
don't
have
any
questions.
C
A
A
All
right
thanks,
everyone
for
joining
I
will
upload
onto
YouTube
and
let
you
know
when
I
do
and
have
a
great
rest
of
your
day.