►
From YouTube: Sifchain + Agoric Seminar
Description
Jazear Brooks of Sifchain + Mark S. Miller of Agoric.
Original Crowdcast at https://www.crowdcast.io/e/sifchain--agoric-seminar with crowd chat comments.
A
Awesome
awesome
cool
all
right
so
for
a
quick
intro,
this
is
the
third,
I
believe
talk
that
we've.
Given
this
way,
I
think
we're
going
to
call
this
the
sift
chain
vision
series,
although
that's
not
yet
nailed,
but
the
point
is
like
this
is
just
a
talk
that
we've
had
with
a
couple
other
great
crypto
economic
thought
leaders.
A
We
had
one
with
michael
sargon
from
block
science
and
josh
tan
from
medigov,
and
the
point
is
just
to
have
good
conversations
mark
and
I
have
had
a
lot
of
great
offline
conversations
but
to
bring
that
offline
and
give
people
a
bit
more
of
a
taste
for
where
this
industry
is
going
from
the
vantage
point
of
people
who
like
to
be
a
little
bit
academic,
a
little
bit
philosophical
but
also
are
building
things
that
have
high
crypto
economic
value
so
mark
I'm
really
happy
to
have
you
on.
A
Cool,
so
I
I
want
to
do
a
bit
of
an
intro
for
you
and
then
you
can
kind
of
fill
out
any
gaps
that
I
I
miss
and
then
we'll
just
kind
of
riff
from
there
so
mark,
and
I
have
known
each
other
for
a
couple
of
years
when
he
was
working
on
earlier
versions
of
agorik.
A
Agorik
is
a
new
smart
contracting
platform,
that's
built
on
the
cosmos
sdk,
but
it
uses
object
capabilities
rather
than
access,
controls
and
I'll
mark.
Why
don't
you
kind
of
explain
a
little
bit
more
about
what
that
means.
B
Yeah,
so
it's
actually
just
being
very
pedantic
in
the
terminology,
it's
using
object
capabilities
rather
than
access
control
lists,
but
both
both
object,
capabilities
and
access
control
lists
are
forms
of
access
control.
The
the
the
better
classification
of
to
get
at
the
essential
idea
is
that
access
control
lists
are
identity-based
access,
control,
all
questions,
all
access,
questions
start
with.
Who
are
you
and
then
based
on
the
identity
of
the
thing?
Doing
the
accessing,
or
you
know
the
person
or
thing
doing
the
accessing,
then
the
access
is
loud
or
not.
B
Object.
Capabilities
are
instead
form
of
authorization
based
access
control,
where
all
all
permission
is
a
bearer
instrument.
It's
simply
something
that
you
have
and
by
virtue
of
having
the
permission
you
can
perform
the
access
and
the
example
that
I
really
like
that
we,
our
community,
always
uses
to
start
with
this.
It's
from
mark
steegler
is
the
car
key
is
a
bearer
instrument.
When
I
walk
up
to
the
car
with
my
car
key,
the
car
key
authorizes
me
to
drive
the
car.
The
car
recognizes
the
car
key
as
my
authorization.
B
If
you
imagine
that
my
car
worked
with
an
access
control
list,
then
if
I
wanted
you
to
let's
say
I
wanted
to
lend
you
my
car
so
that
you
could
do
me
some
favor,
I
would
have
to
tell
my
car
jazeer,
is
now
authorized
to
drive
you
and
then,
while
you're
doing
doing
me,
the
favor.
Let's
say
you
need
to
go
to
some
institution
where
there's
a
valet
that
would
park
your
car
and
now
you
give
need
to
give
the
valet
tell
your
car
that
la
can
drive
it.
B
Well,
you
can't
because
you're,
not
the
owner
of
the
car
and
the
to
make
the
analogy
with
blockchain
systems.
The
fundamental
access
control
element
in
ethereum
is
message.sender
in
ethereum.
The
starting
premise
is
that
anyone
or
anything
can
send
a
message
to
any
contract.
B
So
therefore,
every
contract,
when
it
receives
a
message,
has
to
engage
in
some
kind
of
check,
so
it
can
tell
whether
the
request,
whether
and
how
to
honor
the
request
that
this
message
represents
so
message.sender
says.
Well,
what
is
the
the
the
the
thing
making
the
request
and
then
based
on
the
identity
of
the
request,
or
the
request
is
allowed
or
not
so
by
checking
the
identity
of
the
requesting,
let's
say,
contract.
B
Similarly,
when
you
can't
update
the
the
access
control
list
of
the
car
to
enable
the
valet
to
park
it,
that's
a
failure
to
delegate
that's
a
failure
to
have
authorized
something
that
would
have
been
allowed.
So
let's
say
that
anticipating
this
problem,
instead
of
updating
the
access
list
to
let
my
car
know
that
you
can
drive
it
instead,
I
just
give
you
the
ability
to
impersonate
me.
I
give
you
my
driver's
license
or
my
passport
or
whatever
it
is
that
enables
you
to
claim
my
identity.
B
Well
now,
not
only
can
you
drive
the
car,
you
can
also
sell
the
car
or
you
can
empty.
My
bank
account-
or
you
can
do
all
sorts
of
things
that
you
could
do
if
you
were
me
well,
that
going
back
to
ethereum
is
like
transaction.owner
transaction.owner
avoids
the
failures
of
inability
to
design
to
delegate,
because
now,
as
one
contract
calls
another
calls
another,
they
all
have
the
same
originating
transaction
owner.
B
But
now
you
have
a
failure
of
excess
authorization
that
now
there's
too
many
things
that
the
receiver
can
do,
because
the
the
authority
that's
carried
is
too
broad.
So
the
car
key
is
a
brilliantly
simple
device
that
enables
you
to
do
exactly
what
it
enables
the
holder
to
do,
which
is
to
drive
the
car.
It
can
even
be
more
narrow,
like
with
the
the
the
valet
key,
that
it
doesn't
enable
you
to
open
the
trunk.
B
B
So
least,
authority
is
sort
of
the
the
fundamental
first
important
security
property
that
any
access
control
system
should
have,
which
is
the
principle
that,
on
making
a
request,
the
the
entity
that
the
request
is
made
of
the
the
should
be
given
approximately
the
least
authority
that
it
needs
to
carry
out
that
one
narrow
request,
and
by
giving
it
least
authority
if
it
goes
bad,
the
amount
of
authority
that
it
can
abuse
if
it's
malicious
or
if
it
has
a
flaw
enabling
it
to
be
subverted
by
someone
something
else.
That's
malicious.
A
Got
it
got
it?
That's
a
great
recap,
but
I
always
like
thinking
about
this
because
it's
it
is,
in
my
opinion,
a
more
elegant
way
of
managing
access
control.
That
said,
it's
not
that
common!
So
just
to
recap,
first
of
all,
the
idea
is
that,
with
object
capabilities,
you
actually
are
giving
a
literal
capability
as
an
object
to
any
entity
and
so
that
entity
can
then
you
know,
take
specific
actions
against
you
know
some
module
or
some
some.
You
know
sdk
or
something
like
that.
A
But,
as
you
mentioned,
should
that
actor
turn
out
to
be
malicious?
We
can
track
that
individual
entity
and
make
sure
that
it
only
had
a
relatively
low
amount
of
permissions
while
at
the
same
time
not
using
something
like
access
control
lists
which
would
lend
themselves
to
abuse
as
any
sort
of
sys
admin
can
tell
you.
So
I
think
this
is.
A
This
is
really
a
cool
paradigm
and,
as
I
recall,
you
have
been
working
on
this
for
quite
some
time
to
get
it
into
ecma
script
for
for
javascript,
and
then
you
also
ended
up
getting
this
deep
into
ibc.
Can
you
sort
of
tell
us
about
those
two
processes.
B
Yeah,
so
the
history
for
me
actually
starts
in
1987
when
eric
grexer
and
I
wrote
the
eugoric
open
systems
papers.
87
was
when
we
finished
them.
They
were
published
in
88,
and
those
were
really,
I
would
say,
can
really
be
looked
back
on
as
the
first
substantial
smart
contracting
papers,
the
first
papers
that
really
laid
out
a
vision
that
had
most
of
what
we
would
today
call
smart
contract,
and
I
say
most
of
because
the
full
paradigm
that
we
today
call
smart
contracting
was
not
completely
formed
at
that
time.
B
Nick
zabo,
who
coined
the
term,
also
had
some
fundamental
additional
insights
and
the
and
the
full
paradigm
really
comes
out
of
that
work
as
well,
but
and
nick,
and
I
had
a
lot
of
conversations
in
the
90s
and
really
worked
together
on
this,
including
at
my
earlier
startup
company
agorax
in
the
mid
90s.
That
nick
was
at
briefly,
so
we
were
doing
object
capability
based
smart
contracts
for
a
long
time,
including
previous
startup
companies
in
previous
languages.
B
Electric
communities
was
a
social
virtual,
graphical
social
virtual
reality
that
a
lot
of
these,
where
a
lot
of
these
ideas
came
together
very
well
and
my
e-language
came
out
of
electric
communities.
There
was
an
open
source
effort
through
the
late
90s
and
early
2000s
around
my
e-language,
which
is
a
distributed.
B
Persistent
pure
object,
capability,
programming,
language,
very
simple,
dynamically
typed
had
what
is
in
retrospect,
a
very
javascripty
flavor
to
it,
although
I
didn't
know
it
at
the
time,
because
I
didn't
had
never
heard
of
javascript
when
we
started
it.
B
The
in
2007,
I
joined
google
and
doug
crawford
who
had
worked
with
me
on
e,
who
had
actually
named
e
at
electric
communities.
He
was
at
yahoo.
He
was
involved
in
the
ecma
standardization
process
of
ecmascript
the
standards
name
for
javascript,
and
he
convinced
me
that
javascript
had
the
essence
of
a
good
object
capability
language
in
it,
as,
as
the
phrase
goes
struggling
to
get
out
so
I
joined
at
his
urging
I
joined
the
ecmascript
committee
in
my
case
representing
google,
and
he
and
I
and
alan
wurstbrock
and
per
top
lochman.
B
B
We
did
that,
while
the
ecmascript
committee
was
all
focused
on
ecmascript
4,
the
consensus
of
the
overall
committee,
except
for
us
rebels,
was
on
something
called
ecmascript
4,
which
was
really
this
horribly
complex
language
that
they
had
been
debating
and
working
on.
For
a
long
time,
doug
crockford
had
started
this
splinter
group
on
ecmascript
31,
which
really
consisted
mostly
of
the
four
of
us
doug,
and
I
wanted
to
turn
javascript
into
a
language
that
could
support
object,
capabilities.
B
Ecmascript
3-1
had
those
essential
enablers,
eventually,
ecmascript
4
failed
ecmascript
3-1
became
ecmascript
5..
I've
been
on
the
committee
ever
since
guiding
javascript
to
support
object,
capabilities
ever
better,
but
ecmascript
5
had
the
essential
enablers.
So,
with
the
first
version
of
ses,
secure
ecmascript
was
a
library
that
we
did
at
google
using
the
enablers
that
I
got
into
ecmascript
5.
B
We
published
a
paper
in
2013
called
distributed
electronic
rights
in
javascript,
where
we
really
lay
out
our
vision
of
how
object
how
javascript
with
those
enablers
can
be
turned
not
just
into
an
object
capability
language,
but
into
a
distributed.
Secure,
object,
capability,
language
capable
of
supporting
decentralized
smart
contracts.
2013
was
the
same
year
that
ethereum
started.
We
didn't
know
about
ethereum
when
we
did
this.
B
B
And
so
right
now,
ses
itself
is
also
a
standards
track.
There's
a
number
of
other
companies
that
are
involved
in
the
ecmascript
standardizations
process,
they're
pushing
it
and
most
excitingly
ses,
secure
ecmascript
has
become
the
standard,
the
javascript
standard,
underneath
the
ecmascript
tc
53
process.
Tc53
is
the
ecmascript
committee
for
javascript
for
embedded
devices,
so
javascript
for
embedded
devices
assumes
scs
secure
ecmascript
as
the
base
javascript
for
writing.
A
Cool
cool
a
lot
to
take
in
there.
I
think
that's
number
one,
it's
great,
that
you
had
the
foresight
to
work
on
object
capabilities,
getting
it
into
into
ecma.
A
You
know,
like
decades
sort
of
before
they
became
real
for
blockchain,
but
I'm
wondering-
and
I
guess
another
another
comment
I
have
before
I
ask
another
question
here-
is
that
it
would
be
pretty
useful
and
apps
to
the
the
example
that
you
gave
to
actually
have
a
secure
java,
scs
actually
used
for
iot
devices
right
because,
that's
almost
like
you
know,
an
actual
physical
device
like
a
physical
car
key
or
whatever,
but
I'm
I'm
wondering
in
particular,
if
you
can
compare
the
process
for
getting
object,
capabilities
into
versions
of
javascript
and
getting
it
into
ibc
the
inter
blockchain
communication
protocol,
where
it's
also,
actually
it
wasn't
originally
intended,
but
has
actually
been
adopted
as
like
a
relatively
core
part
of
the
protocol.
B
So
ibc
zucchimanyan
of
one
of
the
founders
of
the
cosmos
project
and
of
ibc.
B
The
important
thing
about
the
distributed
object
protocol
for
the
e-language,
which
was
cap
tp
on
top
of
vat
tp,
is
that
it
was
assuming
mutual
mistrust
between
machines
and
it
provided
a
security
property
that
I'd
like
to
summarize,
as
you
can
reason
about
all
suspicion,
as
if
you
are
suspicious
only
of
objects.
B
So
let
me
take
that
apart
a
little
bit.
This
is
by
the
way,
very
much,
in
contrast
to
things
like
the
sharding
or
the
side
chains
that
we're
seeing
for
scalability
in
the
ethereum
world,
where
there's
very
much
a
asymmetric,
truss
relationship,
there's
very
much
of
a
hierarchy
in
the
center.
B
B
It
could
also
invoke
an
object
on
another
machine,
even
though
the
other
machine
was
not
trusted,
so
the
other
machine
might
be
running
might
might
be
running
the
object
capability
language
correctly.
The
other
machine
itself
might
be
running
in
a
trustworthy
manner,
but
you're
just
invoking
an
object
that
you
don't
trust,
so
you
depend
on
the
object
capability
rules
to
protect
you
from
that
object
and
that
object
to
protect
itself
against
you.
B
On
the
other
hand,
the
other
machine
might
not
be
running
the
the
language
correctly
or
might
not
be
speaking
protocol
correctly,
and
the
idea
of
you
can
reason
about
all
trust
as
if
you
were
suspicious
only
of
objects.
The
idea
of
that
is
that
if
the
language
is
misbehaving,
the
language
implementation
is
misbehaving,
or
if
the
machine
is
misbehaving,
if
it's
speaking
the
protocol
incorrectly,
that
the
your
total
risk
to
it
is
no
greater
than
your
risk.
B
If,
if,
if
its
foundations
are
all
running
correctly
in
a
trustworthy
manner,
but
the
objects
you're
speaking
to
are
malicious
and
you're
and
you're
ignorant
of
what
the
particular
code
is,
if
the
particular
code
is
all
malicious
code
that
the
the
damage
that
it
can
do
is
limited
to
the
to
in
the
same
way
and
to
make
that
make
clear
why
that
is
just
in
terms
of
the
object
capability
concepts
we've
already
talked
about.
B
So
in
that
case,
if
I
give
a
capability
to
any
one
of
the
objects
on
that
machine,
then
it
might
share
it
with
all
the
other
objects
that
are
in
that
joint
conspiracy
and
then
abuse
those
capabilities.
Those
by
capability
here
we
mean
the
object
reference
mapping
of
the
car
key
into
objects.
Is
that
a
reference
to
an
object,
the
protected
pointer,
is
unforgivable
access.
The
unforgeable
permission
to
invoke
the
public
interface
of
that
object.
B
So
if
I
get
if
I
communicate
an
object
reference
to
some
object
on
this
in
this
conspiracy,
it
might
share
it
with
any
other
object
in
this
conspiracy.
All
those
capabilities
might
jointly
be
used
might
be
used
to
invoke
objects,
but
only
those
objects
that
have
been
given
to
any
of
the
objects
on
that
machine.
Now,
if
the
machine
is
operating
in
a
malicious
manner,
then
the
protocol,
the
rules
of
the
protocol,
must
enforce
the
same
constraint,
which
is
that.
B
B
What
you
would
expect
from
a
peer-to-peer
protocol
that
is
about
the
representation
and
passing
of
bearer
rights,
is
that
when
a
bearer
right
is
shared
that
the
entity
it's
shared
with,
can
now
now
has
the
right
and
can
use
it
and
any
right
that
has
not
been
given
to
it.
It
cannot
use,
and
the
result
is
that
so
the
ibc
protocol
very
much
stands
in
for
the
vat
tp
protocol's
role
in
the
old
e
world.
B
There
was
fundamental
new
invention
that
was
needed,
that
the
cosmos
folk,
the
you
know,
the
ibc
process
with
cosmos
token
agora.
Collaborating
really
did
some
great
new
invention
needed
to
do
that
kind
of
protocol
between
blockchains.
That
was
not
something
that
was
was
like
any
problem
that
had
previously
been
faced
before,
because
the
hard
constraint
to
blockchains
is
that
a
blockchain,
the
computation
running
on
a
blockchain
cannot
keep
a
secret.
B
B
A
And
I
think
it
was
pretty
clear:
there
are
two
things
that
come
to
mind
that
might
be
helpful
to
describe
further
one,
I
would
say,
is
the
organizational
political,
just
conversational
differences
between
getting
something
into
javascript
versus
something
in
ibc
or
really,
I
think
for
the
audience
and
me
in
particular.
Just
how
do
you
get
something
merged
into
say,
a
tendermint,
you
know
or
a
cosmos
sdk,
and
I
asked
that
question
for
a
couple
reasons.
A
So
for
one,
a
lot
of
the
sift
chain
protocol
intends
to
work
with
shared
security,
which
is
something
that's
like
very
deeply.
You
know
important
for
the
polkadot
ecosystem
and
it
could
be
very
important
for
the
cosmos
ecosystem
as
well.
It
kind
of
exists
in
ethereum
just
for
for
context.
A
Shared
security
is
basically
this
notion
that
one
very
large
blockchain
like
an
ethereum
or
like
a
polkadot
or
like
a
cosmos
hub,
can
actually
use
the
tokens
that
exist
in
that
blockchain
to
secure
the
transactions
that
exist
on
other
blockchains
and
so
for
sipchain.
A
This
is
incredibly
useful
because
our
peg
architecture
ultimately
relies
on
having
independent,
peg
blockchains
as
opposed
to
just
having
them
all
on
the
same
sip
chain
blockchain,
and
so
we
could
use
the
sipchain
blockchain
to
provide
crypto
economic
security
to
the
peg
zones
or
we
could
use
the
cosmos
hub
or
we
could
use
binance
chain
or
any
other
cosmos,
sdk
compatible
a
chain
to
provide
us
crypto
economic
security,
but
as
I've
been
having
conversations
with,
you
know
a
few
people
in
the
cosmos
ecosystem.
A
There
are
a
couple
of
different
proposals
that
are
floating
around
for
this.
It's
unclear
to
me,
suitor,
who
has
deep
ownership.
I
think
informal
has
a
repo
with
some
pretty
good
progress
on
it.
So
I'm
happy
to
see
that,
but
I'm
not
entirely
sure
how
it
releases
the
work
that
chris
goes
another
architect
in
the
cosmos
ecosystem
has
worked
on.
I
think
both
implementations
are
a
little
bit
more
complex
than
we
might
need,
and
so
we
have
had
some.
A
You
know
tepid,
but
I
think
strong
in
interest
from
people
like
sam
to
at
entertain
to
potentially
help
you
know
the
icf
move
forward
with
this
or
be
an
early
beta
test,
or
something
like
that,
and
I
think
I
think
the
cosmos
sdk
and
the
cosmos
ecosystem
is
one
of
the
most
ideally
open
source
projects
in
the
blockchain
ecosystem.
And
yet
it's
not
anywhere
near
as
far
as
something
like
a
javascript.
A
B
So
I
want
to
make
clear
that
the
history
here
with
regard
to
ibc
is
even
though
it
was
inspired
by
my
earlier
work.
It
was
largely
already
reinvented
before
we
became
aware
of
it.
B
Zucky
and
the
other
folks
at
cosmos
had
built,
and
you
know,
invented
ibc
had
carried
the
work
quite
a
long
ways
and
then
at
a
gorick,
the
early.
In
the
early
days
after
the
founding
of
gorick
facing
the
same
problem,
we
were
starting
to
reinvent
the
same
thing
and
then
we
came
across
cosmos
and
we
came
across
ibc
and
we
realized.
Oh,
this
is
what
we
need
this
is
they,
and
this
is
also
much
much
farther
along
and
that
started
our
collaboration,
so
agoric
and
the
cosmos
folk
collaborated
together
on
ibc.
B
The
current
ibc
standard
is
very
much
the
result
of
that
collaboration.
We're
now
actually
talking
with
some
people
at
ekma
about
the
possibility
of
even
forming
a
new
ekma
tc
technical
committee
to
standardize
ibc.
I
don't
know
if
that
will
happen
or
not,
but
it
looks
promising
and
but
the
ibc
has
really
done
a
very
good
job.
The
ibc
group
has
really
done
a
very
good
job
of
proceeding
forward.
A
Yeah,
I
think
that
makes
that
makes
a
lot
of
sense,
that's
kind
of
what
I'm
noticing
as
well.
Ultimately,
you
want
people
to
be
able
to
implement
in
ways
that,
like
address
their
needs
and
also
their
understanding
right,
no
one
understands
the
entirety
of
the
software,
but
as
much
as
possible.
You
want
them
implementing
a
protocol,
that's
interoperable
with
other
protocols,
even
if
it's
not
built
in
the
same
language
by
using
some
parts
of
the
same
framework
and
so
forth,
and
so
I
can.
A
I
can
appreciate
that
yeah,
I
think
just
for
for
people
in
the
audience
who
are
wondering
this
kind
of
process
is
relevant
not
just
for
building
shared
security,
which
would
be
a
critical
feature
for
the
cosmos
network,
but
also
interoperability
between
cosmos
and
polkadot.
Right
now,
there's
a
thread
I'm
in
with
with
a
few
people
from
both
sides.
You
know
discussing
all
potential
updates
that
we
can
make
to
a
tendermint
light
client
that
would
actually
enable
substrate
ivc
compatibility,
and
so
it's
it's
pretty
helpful.
A
I
think,
to
to
understand
this
sort
of
open
source
contribution
process.
I
mean
it's.
It's
also
nice
to
know
that
ibc
is
respected
enough
to
be
potentially
able
to
get
a
working
group
built
directly
with
with
the
echo
team.
So
I
am
super
happy
to
hear
this.
I
know
when
you-
and
I
were
talking
about
this.
B
A
And
and
just
given
the
fact
that
you
spent
so
much
time
working
on
agora,
it's
pretty
safe
to
say
that
you
feel
strongly
that
gork
has
a
spot
as
a
smart
contract
framework,
even
in
a
world
which
increasingly
seems
like
it's
dominated
by
by
ethereum
and
solidity.
So
can
you
tell
me
more
about
things
you
feel
like
a
gork
can
do,
uniquely
that
you
know
solidity
might
not
be
equipped
to.
B
So,
as
I
mentioned,
the
e-language
was
a
secure,
distributed,
object,
building
language
that
we
did
start
in
electric
communities,
but
then,
through
the
late
90s
and
early
2000s,
where
we
had
gathered
together
a
substantial
open
source
community
around
the
language,
including
discussions
on
the
on
the
list,
that's
all
still
publicly
available,
with
hal
finney
and
nick
zabo
and
other
you
know
crucial
historical
figures.
B
Even
though
e
was
a
general
purpose
distributed
secure
programming
language,
it
was
always
taking
smart
contract
and
decentralized
smart
contracting
as
its
motivating
use
case,
and
what
we
did
during
that
time
is.
We
wrote
smart
contracts
and
we
took
a
look
at
the
suitability
of
the
language
and
the
suitability
of
various
patterns
for
expressing
contracts,
and
we
really
came
to
a
lot
of
understanding
as
to
how
to
build
a
good
language-based
framework
and
patterns
for
expressing
smart
contracts.
Well,
and
what
I
mean
by
well
is
where
the
contracts
themselves
are
fairly
simple.
B
Where
programmer
writing
the
contract
can
have
a
lot
of
confidence
that
the
contract
means
what
they
think
it
means,
and
then
so,
having
done
all
that,
then,
when
ethereum
came
out
and
we
started
seeing
these
various
bugs
happening
on
ethereum,
where
hundreds
of
millions
of
dollars
would
disappear
overnight,
with
no
recourse
because
of
simple
bugs
in
contracts
that
were
constructed
by
experts
that
had
put
a
tremendous
amount
of
effort
into
trying
to
construct
reliable
contracts
and
nevertheless,
simple
bugs,
would
cause
massive
amounts
of
money
to
disappear,
and
we
saw
the
nature
of
those
simple
bugs
for
many
of
them,
not
for
all
of
them.
B
But
for
many
of
them.
The
reaction
of
both
myself
and
many
people
in
the
e-community
was
if
they
had
only
been
writing
the
contracts.
The
way
we
were
writing
the
contracts
in
the
old
days.
They
wouldn't
have
had
these
problems
and
in
fact,
brian
warner.
One
of
the
founders
of
agorik
was
on
the
security
review.
Team
of
ethereum
ethereum
had
had
contracted
with
lease
authority
to
do
a
security
review,
and
this
was
all
before
the
dow
bug
happened,
and
in
that
security
review.
B
Brian
and
the
least
authority
people
identify
the
vulnerability
that
turned
out
to
be
the
dow
bug
identified
it
before
the
dow
bug
happened,
cited
the
work
on
e
and
the
object
capability
community
as
how
to
avoid
those
kinds
of
problems,
and
if
ethereum
had
been
fixed
to
take
into
account
the
recommendations
from
that
security
review,
the
dow
bug
would
not
have
happened
now.
The
dell
bug
was
not
itself
something
fixed
by
object
capabilities
per
se.
B
It
was
fixed
by
asynchrony,
avoiding
a
reentrancy
bug,
but
oh
it
comes
out
of
the
same
overall
philosophy
and
comes
out
of
the
work
of
the
object
capability
community
to
do
that
kind
of
asynchrony
to
avoid
that
kind
of
re-answer
and
reentrancy
problem.
What
in
my
thesis,
I
refer
to
as
a
plan,
interference
problem,
so
I'm
sorry,
I
think
I
lost
the
well.
I
think
I
lost
the
threat
of
what
the
original
question
was.
I'm
sorry.
A
Yeah
I
mean
my
question
is
basically
what
can
you
do
in
a
gorick
that
you
can't
do
in
solidity?
It
sounds
like.
Obviously
there
there
were
a
number
of
security
issues
in
solidity
beyond
that.
It's
just
not
a
particularly
performant
language,
so
I
think
a
lot
of
the
security
problems
that
you
mentioned
between
the
dow
bug
and
then
other
things
that
are,
you
know
for
people
who
are
unaware,
like
that,
the
general
paradigm
for
developing
you
know.
Smart
contracts
in
solidity
is
actually
that
you
don't
build
from
scratch.
A
You
use
a
relatively
standardized
template
from
a
group
like
open
zeppelin,
and
you
know
you
know
you
use
relatively
standard
like
deployment
and
processing
scripts
and
things
like
a
truffle
and
that
ecosystem
is
starting
to
mature
a
bit
like
hard
hat
is
kind
of
replacing
truffle
and
there
a
lot
of
these.
You
know,
d5
protocols
are
becoming
a
little
bit
more
standardized
in
implementation,
and
a
lot
of
the
issues
are
composability
related
and
we're
seeing
a
lot
more
understanding
like
how
to
deal
with
composability
and
ethereum.
A
So
I
do
see
progress
happening
in
solidity
but,
as
you
know,
a
as
as
a
blockchain
enthusiast
who's
interested
in
figuring
out
what
is
the
smart
contracting
language
to
invest
in
you
know
what
is
the
the
claim
for
agoric
versus
solidity?
In
your
mind,.
B
B
So
one
of
the
things
that
you
want
to
do
in
constructing
a
good,
secure
architecture
is
to
figure
out
how
to
refactor
authority
hotspots,
so
there's
not
so
much
risk
all
together
in
one
place.
Let
me
give
you
the
beautiful
example
of
zoe
zoe
is
the
agoric
smart
contract
framework
architected
by
kate
sills
at
agorik,
and
it's
an
answer
to
the
following
standard
way
that
everybody
else
does
smart
contracts
and,
in
fact,
ever
all
the
ways
that
we
had
done
smart
contracts
before
the
founding
of
the
modern
agora.
B
So
all
of
my
historical
work
had
the
same
conundrum,
as
I'm
about
to
explain,
which
is
a
smart
contract,
is
something
that
manages
rights
of
the
participants.
All
of
the
rights
at
stake
in
the
contract
are
put
in
escrow
with
the
contract.
At
the
beginning,
the
contract
holds
those
rights
and
then
the
just
redistribution
of
rights
derived
from
those
rights
back
to
the
participants
only
happens
according
to
the
logic
of
the
contract.
B
So
that's
sort
of
a
universal
statement
over
all
smart
contracts,
but
the
way
everyone
had
done
this,
including
us
historically,
is
to
give
those
rights
to
the
contract
and
then
depend
on
the
contract
operating
correctly
in
managing
those
rights.
And
what
that
means
is
that
if
the
contract
goes
bad,
all
of
the
rights
and
trust
to
the
to
that
contract
can
be.
Are
those
all
of
those
rights
are
at
risk
at
a
gorick?
B
B
We
came
up
with
a
abstraction.
We
call
the
offer,
which
is
sort
of
the
basic
quid
pro
quo
notion.
That's
really
at
the
heart
of
any
notion
of
real
world
contracting,
which
is
that,
when
a
participant
in
a
contract
puts
rights
at
stake
in
the
contract,
they
do
it
in
the
context
of
an
offer,
saying
here's
what
I'm
willing.
Here's!
B
Each
participant
knows
that
the
rights
they
put
into
escrow
are
rights
that
they
will
only
lose
if
they
get
what
they
said
they
want
in
exchange,
otherwise
they'll
get
the
rights
back.
So
let
me
give
that
doesn't
mean
that
the
the
risk
to
the
misbehavior
of
the
contract
has
gone
away,
but
what
it
means
is
that
we've
limited
that
risk.
We've
we've
implemented
a
safety
property
such
that
there's
a
whole
class
of
bugs
that
are
now
off
the
table
and
then
their
residual
risk
is
something
that's
much
more
bounded.
B
Let's
say
it's
a
second
price
auction
in
a
normal
in
a
normal
auction
when
a
bidder
places
a
bid,
even
in
the
second
price
auction,
as
they
place
their
bid,
they
were
put
into
escrow
the
first
price,
the
full
amount
of
their
bid,
and
then
having
made
all
the
bids,
a
properly
functioning
auction
will
award
the
good
being
auctioned
to
whoever
bid
the
most
and
in
a
second
price
auction
will
charge
them
the
price
of
the
second
highest
bid
in
a
misbehaving
auction.
B
In
a
misbehaving
auction
running
on
zoe,
the
misbehaving
auction
might
award
the
good
to
someone
other
than
the
highest
bidder
might
charge
them
the
first
price,
rather
than
the
second
price,
might
give
to
the
seller.
The
one
auctioning,
the
good
might
give
them
no
more
than
their
reserve
price.
They
express
their
reserve
price
with
what
they
want
in
exchange
for
the
good,
because
that's
the
want
that
gets
enforced.
B
So,
there's
still
a
lot
of
significant
risk
to
a
misbehaving,
auctioneer
auditing,
the
the
auction
contract,
to
get
confidence
that
it's
that
it
means
what
you
want.
What
you?
What
you
think
it
means
is
still
an
important
issue,
but
everyone
that
did
not
get
the
good
is
guaranteed
to
get
a
full
refund
and
the
entity
that
did
get
the
good
is
guaranteed
that
they're
not
going
to
pay
more
than
the
first
price
more
than
the
price
that
they
bid.
B
So
there's
the
total
residual
risk
to
misbehavior
by
the
auctioneer
is
tremendously
bounded.
So
that's
the
philosophy
that
once
you've
got
this
bearer-based
leased
authority
architecture,
your
job
isn't
done
because
there
are
still
hot
spots
where
there's
a
tremendous
amount
of
concentrated
risk,
but
you've
gotten.
You
now
have
the
software
design
problem
that
you
can
now
address,
which
we
have
addressed,
of
how
to
refactor
things,
how
to
rethink
the
problem
so
so
as
to
break
up
those
hot
spots.
So
there's
not
so
much
concentrated
risk
in
any
one
place.
B
Now
on
the
composability.
B
The
kind
of
composability
that
you
see
in
ethereum
is
very
shallow.
It's
that
you
can,
let's
say
during
a
overall
transaction.
You
can
take
money
that
flowed
out
of
this
thing
and
feed
it
into
that
thing.
Take
money
that
flowed
out
of
that
thing,
feed
it
into
the
other
thing.
So
this
is
like
where
flash
loans
you
can
kind
of
create
this
set
of
transactions
that
together
compose
that
compose
together
to
pay
back
the
loan
during
the
flash
during
the
transaction
and
bring
about
some
other
overall
transfer.
B
It's
very
much
a
a
first
order.
Kind
of
composition-
it's
like
applying
in
programming
language
turns,
is
like
applying
a
function
to
data
producing
new
data.
Taking
the
data
that
comes
out
of
the
first
function,
feeding
it
into
a
second
function,
which
produces
data
that
you
feed
into
another
function
in
programming,
language
terms,
the
much
more
powerful
kind
of
composition
that
we
know
is
higher
order.
Composition
where
functions
can
not
only
operate
on
data
functions
can
operate
the
kinds
of
things
the
functions
can
operate
on.
B
Let's
call
them
values
itself
includes
functions,
and
then
a
parametric
function
can
operate
on
date
on
on
any
value.
Whether
the
value
is
a
is
data
or
a
function.
The
reason
we
call
this
higher
order
is
in
mathematics,
a
function
that
operates,
let's
say
on
numbers
would
be
a
first
order
function
and
then
a
function
that
operates
on
first
order
functions
would
be
a
second
order
function.
B
So
you
you
in
one
way
of
doing
foundational.
Mathematics,
you've
got
a
hierarchy
of
orders,
then,
in
a
programming
language,
when
we
have
higher
order,
functional
programming
functions
can
operate
on
other
functions
without
having
to
be
stratified
into
different
orders.
So
we
call
that
generically
higher
order.
Functional
programming
objects
likewise
can
operate
on
values
or
other
objects.
B
Now,
there's
yet
another
form
of
higher
order,
composition
that
that
that
arises
at
a
new
level
of
abstraction
where
we're
dealing
with
property
rights,
and
this
is
actually
a
way
to
to
view
what
is
so
powerful
in
the
way
real
world
economies
work.
B
So
to
take
just
the
the
starting
example.
Sort
of
the
canonical
example
we
keep
revisiting,
which
is
the
covered
call
option,
is
the
is
you
you
create?
If
you
let's
say
write
me
a
call
option,
then
let's
say
that
that
you
own
a
concert
ticket
and
you
find
out
that
you're
not
going
to
go
to
the
concert
so
you'd
like
to
sell
the
concert
ticket
to
someone
else
who
might
be
able
to
go
to
the
concert
that
day-
and
I
think
I
might
be
able
to.
B
But
I'm
not
sure
so
I
say
here's
five
dollars
if
you'll
hold
on
to
the
right
for
me
to
buy,
because
I'd
like
to
reserve
through
the
weekend
the
right
for
me
to
buy
the
concert
ticket
from
you.
B
So
you
say:
okay
for
five
dollars,
you've
I
you'll
reserve
for
me
the
right
to
buy
the
concert
ticket
and
then,
at
the
end
of
the
weekend
I
might
decide
whether
to
buy
the
concert
ticket
or
not
well
during
the
weekend,
I'm
now
in
a
valuable
position,
taking
the
covered,
call
option
and
being
able
to
sell
that
position
in
the
contract
to
somebody
else
so
that
they
so
that
they
can
now
take
my
reservation
and
use
it
to
buy
the
concert
ticket
from
you.
B
That
would
be
the
position
in
the
contract
being
treated
as
a
transferable
right,
and
this
sounds
kind
of
abstract,
but
we
see
this
kind
of
thing
all
the
time
in
actual
markets.
This
is
a
form
of
higher
order
composition,
because
now
the
kinds
of
rights
that
contracts
manipulate
are
now
also
the
kinds
of
rights
that
they
create
or
to
put
another
way,
the
derivative
rights
rights
as
derivative
instruments
are
now
just
property
rights
that
any
generic
rights
manipulating
contract
can
now
manipulate.
B
B
The
invitation
itself
is
a
transferable
property
right
that
can
be
manipulated
as
a
right
put
into
escrow
described
in
terms
of
wants
all
of
those
enablers
in
terms
of
zoe,
so
that
the
kinds
of
rights
that
a
zoe
contract
can
manipulate
is
also
the
kinds
of
rights
that
a
zoe
contract
creates,
and
this
creates
a
much
richer
form
of
hardware
composition
and
in
fact,
we've
been
exploring
a
lot
of
this
we've
had
now
in
beta
we've
had
hackathons,
we've
had
other
people
come
in,
write
contracts
for
our
systems
and
we've
really
corroborated.
B
We've
really
confirmed
with
this
experience
that
we're
able
to
teach
other
people
how
to
write
contracts
in
this
way,
they're
able
to
come
up
to
speak
quickly,
they're
able
to
write
con
contracts
in
a
fairly
confident
manner,
they're
able
to
explain
those
contracts
and
they're
able
to
do
it
in
a
programming
language.
That's
already
familiar
to
20
million
programmers,
and
I
think,
most
interestingly,
it's
not
just
that
the
language
is
familiar.
B
B
That
argument
enables
the
receiving
object
to
invoke
the
argument
object
and
that
all
of
our
practices
of
modularity,
of
trying
to
keep
systems
loosely,
coupled
as
to
not
have
a
lot
of
unnecessary
connectivity,
a
lot
of
unnecessary
access
in
good
object-oriented
programmers.
We
leverage
those
intuitions
in
the
way
we
think
about
security
so
that
it
becomes
a
much
shallower
learning
curve
starting
from
familiar
languages
with
the
distributed
programming,
be
an
extension
of
their
intuitions
about
how
they
do
local
programming,
where
you're
just
sending
messages
to
remote
objects.
B
The
way
you
send
messages
to
local
objects
except
asynchronously,
the
extension
of
the
object,
programming,
intuitions
you've
already
got
into
the
security
realm
and
the
bringing
of
higher
composition,
which,
if
all
you
knew,
was
first
order.
Composition
would
seem
very
fancy,
but
coming
from
modern
programming
practice,
it's
the
natural
form
of
composition
you're
drawn
to-
and
it
brings
you
much
closer
to
the
to
the
patterns
of
market
composition
that
we're
used
to
from
real
world
markets.
A
I
really
appreciate
that
I
learned
something
new
because
I
don't
think
we've
discussed
higher
order
compositions
before,
and
that
is
a
very
strong
draw
for
me.
The
the
draw
for
agoric
has
always
been
the
compatibility
with
javascript,
which
is
something
very.
A
A
lot
of
people
are
familiar
with
and
the
improved
security
benefits,
but
I
think
that
those
two
benefits
to
me
seemed
dubious
in
the
face
of
this
huge
onslaught
of
you
know,
people
trying
to
build
whatever
they
can
in
solidity,
just
because
ethereum
has
such
had
such
strong
market
performance,
but
this
new
argument
that
we
can
use
higher
order,
higher
order
compositions
and
with
agoric.
Actually
it
makes
me
feel
like
between
that
and
the
other
two
benefits
I
mentioned.
A
We
could
see
a
scenario
in
which
a
lot
of
new,
relatively
less
experienced
in
financial
contract
development
engineers
start
creating
a
bunch
of
contracts
that
are
used
for
their
own
local
purposes,
but
there's
a
lot
more
safety,
because
it's
more
secure
and
also
the
higher
order
compositions
make
it
so
that
their
little
small
economies
can
actually
be
relevant
for
larger
economies.
So
I've
often
thought
about
things
like
you
know.
A
A
If
you
had
high
order
compositions
plus
there's
the
a
concern
that
we
see
with
things
like
cascading
interest
rates
right,
so
the
the
really
awesome
interest
rates
that
are
available
to
some
large
institutions,
like
financial
institutions,
are
just
not
available
for
the
everyday
consumer
and
there's
a
function,
there's
a
kind
of
high
order,
composition
in
the
market,
but
it
takes
a
very
long
time
and
requires
like
actual
wet
ink
paper
in
many
of
these
cases,
because
these
guys
to
some
extent
use
technology
to
some
extent,
don't
it
requires
a
lot
of
very
slow
moving
institutions
to
like
bring
that
composability,
whereas
if
all
this
stuff
could
be
done,
algorithmically
and
any
one
of
the
privileged
actors
can
just
defect
and
say:
hey,
you
know
what
I'm
not
going
to
deal
with
any
sort
of
classism
and
you
know,
rent
seeking
I'm
just
going
to
sell
these
these
rights
to
the
highest
bidder.
A
You
can
very
much
more
easily
see
a
situation
in
which
central
banks
or
other
major
governing
economic
or
financial
regulators
could
actually
influence
retail
spending
behavior
more
more
directly.
So
this
is
really
cool
and
I'm
guessing.
This
is
stuff.
You've
thought
about,
I
see
the
big
grid
on
your
face,
so
it's
been
a
long
time
coming
for
you.
B
Yeah,
so
the
the
let
me
start
with
the
the
the
issue
you
started
with,
which
is
simply
the
ethereum
being
the
attractor
being
the
first
mover
being
the
place
where
there's
so
much
of
the
volume
of
contracting.
B
If
I
want
to
write
a
document
that
links
to
a
particular
set
of
other
documents,
there's
no
particular
need
for
me
to
host
that
document
on
the
same
web
server
as
those
other
documents,
because
the
fact
that
those
other
documents
on
a
particular
web
server
does
not
form
some
strong
attractor.
That
keeps
me
from
writing
a
document
that
runs
elsewhere
that
that
that
makes
links
to
those
documents.
B
A
Well,
it
was
just
a
more
of
a
comment
where
I
said
that
you
know
I've
been
concerned
that
the
entire
sort
of
programming
you
know,
class
of
of
2021
for
smart
contracts
is
going
to
be
heavily
focused
on
solidity
and
even
if
agoric
is
better
than
there's,
not
necessarily
a
reason
to
switch,
although
at
the
same
time
I
think
once
people
really
grow
off
this
idea
of
higher
or
higher
order
composibility,
they
may
end
up
realizing
that
there's
more
value
potentially
to
be
generated
through
correct
style
contracts.
A
B
Right
and
the
the
other
thing
that
you
have
been
saying
was
the
thing
about
the
inaccessibility
to
regular
people
of
a
lot
of
these
fancy
contractual
arrangements
as
they
have.
They
happen
in
the
economy
right
now
and
compared
to
how
the
kinds
of
contracts
that
aggoric
enables,
with
the
higher
composition,
really
brings
down
the
cr,
and
it
opens
up
the
benefits
of
contracting
in
a
very
casual
way
to
lots
and
lots
of
regular
activities.
B
Activities
that
aren't
not
necessarily
thought
of
as
financial,
but
just
cooperative
arrangements
between
people
makes
those
much
more
part
of
the
normal
fabric
of
life
that
we
can
support
without
having
to
turn
to
intermediary
institutions
without
having
to
turn
to
jurisdictional
legal
systems
without
having
to
turn
to
laws
and
courts
that
we're
really
able
to
create
a
richness
of
cooperative
frameworks
that
people
can
use
for
interacting
with
each
other
in
a
trustworthy
manner.
B
Just
yeah
you
using
these
kinds
of
of
the
kinds
of
code
that
that
millions
of
regular
programmers
can
put
together.
A
Yeah,
so
I
I
expect,
there's
a
lot
more
value
to
be
gleaned
from
agora
than
even
I
realized
prior
to
joining
the
call,
which
I
think
pretty
much
happens.
Every
time
you
talk,
let
me
take
a
quick
look
here.
It
looks
like
there's
a
question
around
you
know
connecting
to
learning
about
agoric.
A
I
I
would
say
you
know
there
there's
a
pretty
good
amount
of
content
on
the
website,
so
you
can
kind
of
just
check
out
the
website
if
you
want
more
detail
like
how
to
get
started,
but
there's
no
like
as
a
two-parter
question,
it's
just
what
do
what
kinds
of
smart
contracts
would
you
particularly
be
interested
in?
Seeing
to
you
know
it
from
the
igori
ecosystem.
B
Take
a
look
at
our
hackathons
when
we
do
the
hackathons,
we
we
put
out
some
challenges
and
we
also
ask
people
to
invent
new
contracts,
and
people
have
come
up
with
some
very
creative
stuff
and
take
a
look
in
particular
the
a
lot
of
the
prize
winners
from
our
earlier
hackathons.
B
We're
creating
a
you
know
the
the
wonderful
thing
about
creating
platforms
like
this
is
when
people
surprise
you
when
they
create
something
that
you
take
a
look
at
and
say:
oh,
I
never
would
have
thought
of
that,
but
that's
exactly
the
kind
of
thing
that
we
were
building
this
platform
in
order
to
enable,
and
I'm
so
glad
somebody
realized
that
so.
B
B
B
B
Are
outside
of
finance
now
there's
also
tremendous
ways
to
mix
concepts
of
finance
and
non-finance
that,
where
the
you
know,
the
category
difference
between
finance
and
non-finance
might
be
a
mental
barrier
preventing
people
from
seeing
ways
from
for
mixing
the
concepts.
So
I
would
encourage
a
lot
of
creativity
in
that
regard.
B
Governance,
I
think,
is
probably
one
of
the
most
important
things
for
people
to
experiment
with
innovations
and
governance.
Things
like
invention
of
democracy,
the
inventions
of
representative
government
separation
of
powers.
All
of
these
things
have
been
tremendous
advances
in
the
ability
of
human
society
to
operate
better
concepts
of
rule
of
law
that
that
are
tremendously
have
been
tremendous
assets.
Even
though
jurisdictional
governments
have
been
so
bad
at
it.
They've
been
good
enough
to
give
us
a
taste
of
the
advantages
we
can
get
much
much
better.
B
Approximation
of
rule
of
law,
rule
of
law,
like
systems
built
on
code
and
futarki,
is
a
great
example
of
the
kind
of
governance
experiment
that
I'm
eager
to
see.
People
try
things
like
alex
tabarak's
dominant
assurance
contracts
for
overcoming
various
kinds
of
free
rider
problem,
other
kinds
of
collective
action
problems.
The
thing
to
remember
about
these
kinds
of
governances
is
that
most
governance
experiments
will
go
wrong.
Most
governance
experiments
like
most
mutations
in
biology,
just
won't
work
out,
but
a
few,
but
you
know
in
biology.
B
Although
most
mutations
are
fatal,
all
progress
depends
on
the
few
mutations
that
are
not
fatal.
The
governance
experiments
that
do
work
out.
Some
of
them
will
work
out
brilliantly
and
if
few
really
brilliant
innovations
and
governance
can
make
our
civilization
a
vastly
more
pleasant
place
for
all
of
us,.
A
Yeah,
a
few
things
have
come
to
mind.
Actually
I
just
took
some
notes
to
comment
on
to
I
I
want
to
go
to
what
you
just
said,
but
to
kind
of
catch
up
on
a
larger
train
of
thought
that
I've
seen
throughout
the
conversation
number
one
this
idea
of
using
zoe
to
make
it
so
that,
rather
than
having
centralized
access
control
in
a
single
smart
contract,
you
actually
basically
give
the
smart
contract
certain
rights
temporarily,
but
based
on
meeting
certain
qualifications.
A
I've
seen
something
like
this
in
sort
of
futuristic,
ish,
blockchain
design.
So
you
know,
for
example,
I've
seen
peg
architecture
in
which,
rather
than
having
the
peg
control
all
of
the
assets
there
like
shards
of
pegs
controlling
different
sets
of
assets,
4chan
also
uses
this.
Actually,
where
you
know
it's
vaults
are
actually
distributed,
they're
actually
like
multiple
vaults,
and
so
if
one
of
them
has
hacked
their
craft,
for
whatever
reason,
it
has
a
relatively
limited
amount
of
funds
that
you
can
release,
and
I
do
think
that
makes
a
lot
of
sense.
A
There's
another
sort
of
kind
of
a
thing
that
I
wanted
to
mention,
which
is
that
I
believe,
when
we
were
talking
about
this
whole
first
mover
advantage,
potentially
for
ethereum
not
being
not
being
a
a
game
ender.
I
I'm.
Actually,
you
know
looking
at
the
charts
and
always
notice
a
finance
finance
chain
creeping
up
really
heavily
in
in
the
in
the
in
the
coin
market
cap
rankings.
A
Where
there's
a
you
know
for
for
the
most
part,
if
you
look
at
the
top
say,
10
coins
you've
got
bitcoin,
which
is
actually
where
most
of
the
assets
are
concentrated.
You've
got
ethereum,
which
is,
has
the
first
remover
advantage
for
bringing
any
kind,
a
smart
contract
ecosystem
of
any
kind
into
the
the
world,
and
then
you've
got
or
at
least
into
the
crypto
markets
in
a
way,
that's
like
very
heavily
traded
and
then
you've
got
a
huge
set
of
experiments.
A
You
know
below,
and
finance
chain
has
really
kind
of
laid
claim
to
being
like
the
solid,
like
number
three
and
just
in
terms
of
of
liquid
market
cap.
So
there's
this
this.
This
idea
that,
like
a
more
centralized,
I
wouldn't
say
entirely
centralized
but
more
centralized
institution
can
be
very
savvy
with
its
assets
and
use
them
to
generate
a
substantial
amount
of
value.
A
I
don't
know
to
what
extent
they'll
be
able
to
get
close
to
ethereum,
we'll
have
to
see,
but
that's
very
different
from
ethereum,
which
at
least
posits
itself
as
more
of
a
a
distributed
sort
of
public
good,
where
there
isn't
really
a
central
actor
kind
of
managing
the
assets
on
the
chain.
So
I'm
interested
to
see
how
that
plays
out
if
binance
smart
chain.
I
think
I
think
pretty
much
I
I
would
actually
say
it's
almost
proven
at
this
point
that
you
know
a
relatively
savvy
financial
actor.
A
That's
that's
somewhat!
Centralized
in
coordination
like
finance
can
accumulate.
You
know
tens
of
billions
of
values
for
its
chain,
which
means
that
a
a
chase
or
a
city
or
a
goldman
sachs-
I
don't
know
if
they
were
able
to
you-
know,
update
their
dna
accordingly,
could
build
a
similar
ecosystem.
A
So
there's
a
comment
that
I've
noted
and
then
the
third
bit
around
the
governance
thing.
I
I
I
don't
know
if
you
thought
about
this,
but
maybe
you
can
you
can
opine.
You
realize
that
you're
basically
saying
you
could
just
sell
your
vote
in
governance
right
like
I
could
you
know
I
have
this
this.
This
decision
I
can
make
and
I've
got
one
vote
for
for
a
particular
outcome.
If.
A
Great,
I
can
vote.
If
not,
then
I
just
sell
the
rights
that
vote,
which
may
be
a
market
clearing
outcome,
although
it
does
run
counter
to
some
of
our
our
intuitions
around
democracy.
So
those.
B
Yeah,
I
think
the
the
the
counterintuitiveness
of
that
is
a
good
read,
you
know,
is
a
red
flag
that
we
should
take
seriously.
B
It
might
be
that
for
the
kinds
of
things
we
think
of
as
democratic
like
that
adopting
voting
structures
where
you
can
sell
your
vote
might
in
fact
be
pathological,
and
we
need
some
other
way
to
to
approach
the
benefits
that
we
associate
with
democracy
or
not.
I,
this
is
once
again
an
area
where
it's
very
very
hard
to
think
through
things
from
first
principles.
B
B
Doesn't
you
know
in
the
20th
century
governance
experiments
that
went
wrong
killed
millions
of
people?
We
can
now
do
governance
experiments
and
have
them
go
wrong
with
much
much
less
risk.
You
know
and
and
the
issue
about
the
selling
the
vote,
an
example
where
we've
got
real
world
experience
with
something
like
voting.
B
B
The
idea
that
a
stockholder
voting
their
stock
when
they
sell
their
stock,
they
sell
their
voting
rights
or
they
could
even
sell
their
proxy
their
voting
rights
without
selling
their
stock.
None
of
that
seems
pathological
in
the
context
of
stock
equity,
leading
to
decisions
by
shareholders,
and
when
that
is
a
good
metaphor
for
something
that
should
apply
to
the
to
to
other
problems
in
the
world
and
when
it
shouldn't
is
open,
is
something
to
be
explored.
Another
example
where
selling
the
vote
does
not
seem
pathological
is
to
turkey
in
futaki.
B
What
you're
doing
is
betting
on
outcomes
is
trying
to
is
you're
you're
betting
on
predictions
of
things
and
selling.
The
vote
in
that
case
is
simply
selling
the
ability
to
place
a
prediction
effectively.
B
It's
not
really
a
good
way
to
characterize
it,
but
the
buying
and
selling
of
of
prediction
power
there
and
simply
not
making
a
prediction
allowing
the
predictions
of
others
to
carry
the
weight
of
the
prediction
is
also
something
that
would
not
be
seen
in
that
context
as
leading
to
a
pathology.
So
so
I
think
I
think
all
of
this-
I
don't
have
you
know
overall,
like
I
said,
governance
is
something
that
it's
very
hard
to
think
through
from
first
principles.
A
Yeah
makes
a
lot
of
sense
and,
yes,
we
will
see
some
pretty
interesting.
Things
come
out.
My
last
comment
and
then
I'll
just
turn
it
over
to
you
and
rat.
Is
that
I
think
that
you
know
I'm
reminded
of
biology.
Cernevasan's,
you
know
comments
around
the
the
next
type
of
states
being
network
states
right.
A
This
notion
that
you
know
we
will
have
these
democratic
or
democratic,
like
institutions
that
will
exist
on
cryptocurrency
networks,
but
they'll
be
primarily
focused
around
the
network
rather
than
the
nation
or
the
city,
and
I
think
that
a
an
expectation
would
be
that
you're
invested
in
an
asset
that
you're
expecting
to
go
up,
and
thus
the
entire
engagement
is
much
more
financial
in
nature,
and
so
deviations
from
you
know
the
the
things
that
are
considered
priceless,
like
identity
or
values.
Or
what
have
you
like?
A
A
I
think
you
know
I'm
very
interested
to
see
someone
actually
try
futarki,
but
my
intuition
is
that
we
have
a
lot
more
base
layer
infrastructure
around
of
making
betting
markets
before
that's
super
practical
and
also,
I
think
that
there
have
to
be
different,
say
derivatives
of
base
level
layer
footage
nor
from
the
work,
but
I
still
think
it's
cool,
but
yeah
I
mean
overall.
I
think
this
has
been
pretty
helpful,
we've
kind
of
got.
A
I
guess
both
of
us
to
get
back
to
work,
to
actually
make
sure
that
the
infrastructure
that
we
need
to
even
try
these
experiments
is
going
to
work.
But
I
I
really
appreciate
you
coming
on.
B
This
was
tremendous
amount
of
fun
and
let
me
also
just
make
one
more
point
about
the
the
point
you
make
about
a
few
turkey
owls
have
a
similar
skepticism
about
it,
and
one
of
the
things
that
really
occurs
to
me
is
that
when
we
imagine
few
turkeys
that
work,
what
the
implicit
assumption
behind
that
is
a
very
thick
market
that
there's
a
lot
of
money
and
a
lot
of
players
and
a
lot
of
hypotheses
hypotheses
and
the
pro
and
a
lot
of
our
thinking
in
general,
about
trying
to
reconstruct
on
crypto
a
lot
of
what
we
see
in
the
real
world
markets
when
we
think
through
it
from
first
principles.
A
Yeah
yeah,
I
agree,
I
think,
there's
a
there's
a
there's,
a
science
to
or
in
a
pre
there's
there's
so
much
more
much
more
of
an
appreciation
that
I
have
for
the
science
and
engineering
and
art
of
market
making,
both
literally
and
figuratively,
and
I
think
we
started
with
you-
know
the
tokens
themselves
and
then
we
kind
of
moved
to
d5
and
now
there's
nfts,
there's
social
network
tokens
and
or
social
tokens.
A
I
should
say
I
I
think,
there's
some
kind
of
there's
a
lot
to
the
notion
of
like
building
out
the
market.
So
you
can
get
the
retail
you
can
get
the
whales
you
get
different
kinds
of
whales
and
then
you
can
ultimately
get
people
making
taking
complex
nuanced
positions
that
reveal
their
perspective
about
the
market,
which
helps
the
market
become
more
overall
informed.
But
I
think
that
will
lead
us
to
having
a
more
overall
informed
society.
A
All
right
wow,
we
we,
we
definitely
did
a
good
job
on
this
one.
I
think
we
will
post
the
transcript
and
the
recording
online
mark
thanks
a
lot
for
for
joining.