►
From YouTube: The Duality of Smart Contracts and Electronic Rights by Dean Tribble at Web3 Summit 2018
Description
Dean Tribble, CEO of Agoric, presents his work with smart contracts at Web3 Summit
This video was recorded at Web3 Summit 2018 in Berlin.
A
A
We
are
a
small
startup
company
that
has
been
working
on
smart
contract
technology
since
before
there
were
block
chains
for
at
least
some
of
the
the
founders
of
it
but
and
our
goal
the
entire
time
has
been
to
bring
the
entire
world's
economy
all
the
ways
that
people
cooperate,
the
diverse
kinds
of
market
behavior
they
have
and
enable
bringing
that
online
safely,
and
so
smart
contracts
are
the
technology
with
which
we
want
to
do
that.
Now
we're
nothing
if
not
ambitious,
but
we
can't
do
that
ourselves.
A
We
can't
do
that
with
even
the
help
of
everyone
in
this
room
or
everyone
at
this
conference
to
achieve
that,
it's
just
too
big.
We
need
the
millions
of
developers
out
there
in
the
world
that,
when
they
get
up
when
they
wake
up
to
solve
some
problem
that
they
have,
they
can
do
so
in
a
way
that
makes
it
a
decentralized
solution.
They
can
take
our
technology
and
they
can
use
it
safely
to
solve
the
problems
that
they
have
and
there's
some
obstacles
to
doing
that
right.
A
There's
some
challenges
who
here
remembers
when
web
interfaces
were
fill
out,
a
form
and
click
a
submit
button
right.
Remember
that
yeah
few
people-
oh
my
gosh,
so
then
JavaScript
came
out
and
we
can
add
event
handlers
and
now
he
can
suddenly
increase
the
expressiveness
of
our
programs.
But
it
was
still
something
that
that
it
took
experts
to
get
right.
It
was
fragile.
A
There
were
security,
holes,
etc,
but
now
tens
of
millions
of
developers
every
day
are
building
slick,
professional,
secure,
responsive
internationalized
applications
with
a
Polish
that
we
couldn't
have
imagined
15
years
ago,
when
JavaScript
first
came
out
and
they're
doing
it,
because,
instead
of
building
with
these
very
low
level
tools,
they
have
a
framework
right
and
that
framework
is
crucial
for
enabling
them
to
succeed
at
solving
these
problems.
That's
how
we
were
able
to
antutu
empower
tens
of
millions
of
people
to
solve
problems
without
talking
to
each
and
every
expert
around
them.
A
And
then
the
other
thing,
that's
a
big
obstacle
to
millions
of
developers
being
able
to
build
our
online
economy,
for
us
is
the
security
model
right
now
in
the
various
smart
contracting
systems
that
are
available,
even
experts
can't
get
the
security
right,
and
so
we
end
up
losing
tens
of
millions
of
dollars
in
minutes
with
essentially
no
recourse
and
to
bring
all
these
developers
forward.
It's
got
to
be
safer
than
that.
It's
got
to
be
easier
for
them
to
do
safe
composition.
A
A
So
by
that
phrase
indeed,
Bitcoin
is
a
smart
contract,
but
aetherium
and
the
other
smart
contracting
frameworks
gave
us
the
ability
to
express
much
rich
or
smart
contracts
where
we
enabled
programmers
to
build
their
own
use
cases
to
solve
their
own
problems,
and
that's
that
that
that's
an
environment
that
lets
us
do
more
in
a
decentralized
fashion,
but
there
are
limitations
in
some
sense.
You
know
the
the
etherium
gave
us
the
opportunity
opportunity
to
do
all
of
this,
but
they
inherited
some
of
the
legacy
that
we
have
from
traditional
systems.
A
So
the
main
one
and
I
mentioned
it
before
is
the
security
infrastructure
right
in
Windows
and
Mac
and
Linux.
We
have
this
interface
from
human
to
computers,
where
it
has
what's
called
the
identity,
based
access,
control,
model
right
and
I,
go
to
a
company.
I
get
a
few
rights,
maybe
a
year
later
or
if
for
good
six
months
later,
you
get
promoted
and
they
get
a
few
more
rights
right,
but
it
doesn't
change
very
much
and
it's
pretty
well
understood
that
the
access
control
list
model,
the
identity
based
access
control
model
doesn't
handle
dynamically.
A
Changing
permissions
very
well
right.
So
you
know
the
moral
equivalent
of
I've
got
a
car
I
want
to
lend
you
my
car
I,
give
you
my
key.
You
go
to
the
hotel,
you
hand
it
to
the
valet.
You
go
in.
You
come
back
out,
it's
a
different
valet.
The
first
one
went
off
duty,
you
get
the
key,
you
come
home
right
and
if
it
was
identity
based
access
control,
instead,
I
lend
you
my
car.
A
By
taking
your
name
and
telling
my
car
that
you
know
Joe
is
allowed
to
drive
and
Joe,
goes
to
the
hotel
and
asks
the
valet
for
the
valets
name
and
then
realizes
that
Joe
is
not
in
fact
an
administrator
on
the
car
and
he's
stuck
and
now.
My
two
choices
are:
leave
Joe
Haines
or
make
him
administrator
on
my
car.
So
not
only
can
he
park
it,
but
he
could
also
sell
it
right.
A
Given
you
access
to
this
ticket,
you
of
all
the
people
in
the
world
trying
to
redeem
this
ticket
are
the
one
that's
able
to
do
so
successfully.
But
you
can't
go
to
the
concert.
Well,
you
are
unable
to
sell
it.
You
can't
even
give
it
to
your
best
friend,
because
you
don't
have
authority
to
change
the
ID.
The
the
address
that's
buried
inside
of
that
contract.
A
So
what
we
need
is
a
security
model
that
makes
that
easy
that
matches
that
behavioural
pattern
instead
of
the
GI
get
promoted
in
a
year
if
I'm
lucky,
so
the
identity
based
access
control
model
it
bakes
in
that
notion
of
owner,
which
is
hard,
it
impedes
transfer,
it
impedes
cooperation
or
composition.
It
prevents
that
dynamic
change
of
rights
and
the
complexity
that
people
need
the
epicycles.
You
end
up
adding
onto
these
smart
contract
systems
in
order
to
be
able
to
recover
some
of
that
dynamism.
All
this
complexity
that
ends
up
being
a
source
of
bugs.
A
So
there
is
a
solution.
There's
a
solution
approach.
This
comes
out
of
a
history
of
secure
operating
systems,
originally
the
Kiko's
operating
system,
the
midori
operating
system
in
Microsoft.
Now,
arguably,
the
most
secure
operating
system
on
the
planet
sel
for
is
in
this
object,
capability
model
or
o
cap
model
and
formally
allow
me
to
introduce
to
you.
A
You
know
a
transferable
unforgeable
authorization
to
use
the
object
it
designates,
and
you
need
to
understand
that
if
you're
building
an
object
capability
system
out
of
crypto
behavior,
if
you're
building
the
operating
system,
details
with
memory,
mapping
and
all
that
sort
of
stuff,
but
when
it
surfaces
in
a
programming
language,
which
is
where,
when
we're
building
smart
contracts,
you
will
primarily
be
encountering
this.
It's
just
an
object
reference
and
so
object.
A
Capabilities
at
the
programming
language
level
is
the
kind
of
thing
you've
experienced
in
Java
in
c-sharp
and
in
JavaScript,
where
you
have
an
object
reference
and
then
we
build
patterns
of
using
just
simple,
straightforward
object,
programming
to
recover
security,
behavior
to
implement
security
policies
or,
in
our
case,
to
implement
market
policies
and
market
behavior.
So
we'll
give
some
that-
and
you
know,
if
you
think
about
it,
going
back
to
that
car
example.
A
My
having
the
key
to
the
car
is
like
an
object
reference
to
the
car
and
I
hand
it
to
you
and
now
you
can
drive
the
car
right.
So
let's
talk
about
a
simple
example,
so
on
the
Left
I've
got
a
entry
and
exit
counter
right.
Remember
I
was
doing
this
concert.
This
is
a
very
simple
example
done
in
JavaScript,
where
I
want
to
be
able
to
I've
got
a
clicker
when
people
come
in
the
gate.
I
got
a
clicker
when
people
leave
the
gate
and
I
want
to
keep
count
on
the
right.
A
I
create
one
of
those
and
then
I'm.
Just
calling
the
entry
guard
and
saying
hey.
Here's
your
clicker
now
for
people
not
familiar
with
JavaScript
that
pattern
of
counter
count:
entry
on
the
right,
that's
just
taking
the
method
and
pulling
it
out
as
an
object.
So
that's
you
know,
don't
be
confused
about
that.
It's
just
I'm
passing
an
object
to
the
entry
guard
and
that's
the
clicker
that
he
can
use
same
with
the
exit
guard.
A
I
passed
them
the
exit
guard
and
the
important
thing
here
is
in
a
fairly
natural
way
in
an
expression
in
the
language.
Not
only
have
I
provided
the
entry
guard
with
the
clicker,
but
I've
provided
only
the
entry
guard,
so
I
have
I.
I
have
provisioned
and
I
have
done
a
secure
transfer
than
knowing
in
can
intervene
in
and
that
daintree
guard
when
he
goes
off
duty.
Can
hand
it
to
Jane
the
next
entry
guard
and
now
Jane
can
do
the
clicker
as
more
people
come
into
the
concert.
So
that's
very
simplified.
A
You
know,
and
it
looks
sequential
in
fact,
the
way
we
do
systems
it's
primarily
around
doing
asynchronous
messaging
is
I'll
talk
about
in
just
a
moment,
but
we'll
stick
through
examples
for
this
more
simplified
approach.
Just
so,
you
can
see
the
concept
of
the
duality
that
I
was
that
the
title
talks
about
of
contracts
and
rights.
So
what
are
we
building?
Okay
originally,
when
we
were
doing
smart
contracts
and
smart
contract
systems,
it
was
between
individual
machines.
A
This
was
before
blockchain,
so
its
cryptographic
protocols,
cryptographic
messaging
between
machines,
where
two
parties
wanting
to
engage
in
commerce
could
find
a
mutually
a
source.
They
can
be
truly
rely
on
deploy
a
contract
there
executed
in
order
to
engage
in
an
escrow
exchange
of
money
for
tickets,
or
what
have
you
and
blockchains
end
up,
enable
creating
new
machines
out
of
agreement
rather
than
out
of
silicon?
So
you
can
think
of
aetherium
as
as
a
machine
with
the
compute
power
of
a
cell
phone,
but
with
vastly
higher
integrity
and
assurance
of
correctness.
A
Right
I
mean
so
we
have
several
different
machines.
Solo
machines
would
be
you
know
the
wallet
on
my
cell
phone,
small
quorums
would
be
permission,
chains,
hyper,
ledger,
etc
in
public
chains
would,
of
course,
be
everything
from
Bitcoin
to
aetherium,
to
polka,
dot,
etc.
Okay
and
before
I
go
on
from
here,
a
goreck
will
be
using
this
technology,
but
a
lot
of
people
have
already
innovated
there.
A
Our
primary
value
add
is
above
it,
and
so
we
will
be
using
something
we're
using
substrate
to
implement
our
chain
and
expect
to
deploy
as
a
pair
of
chain
on
polka
dot,
because
you
know
problem
solved
already.
Why
not
use
that?
Okay
and
then,
above
that
we
have
a
runtime
layer
where
we
have
vats.
That's
just
our
notion
of
like
a
virtual
machine
for
an
object
system,
so
those
are
islands
of
sequential
programming
in
a
sea
of
asynchronous
messaging,
and
on
top
of
that
we
build
our
object
system.
A
We
have
an
object
system
with
the
familiar
approximately
transactional
model
that
JavaScript
programmers
are
familiar
with
of
you.
If
you've
used,
browsers
or
programmed
in
node
there's
an
event.
Loop
message
comes
in,
you
know,
action
happens.
You
go
to
the
next
event
in
the
contract
model
in
vats.
We
enhance
that.
Where
message
comes
in,
they
bid
on
this
auction.
It
computes
from
contract
State
expressed
in
simple
JavaScript
objects.
A
It
computes
a
new
state
and
set
of
messages
out
like
okay
transfer,
the
money
to
my
bank
account
and
that's
a
transaction,
and
so
these
vats
are
transactional
units
inside
of
which
are
objects.
Those
outbound
messages
are
delivered
asynchronously
to
other
of
other
vats.
Other
contracts
running
concurrently
with
this,
but
all
of
the
programming
model,
just
like
in
the
browser,
looks
approximately
synchronous
and
again
I'm
gonna.
Stick
with
that.
A
For
my
examples,
and
then
above
this,
oh
and
then
first
messages
are
delivered
a
single
yes
and
above
this
we
have
the
contract
framework
with
smart
contracts
and
electronic
rights
building
each
other.
Oh
and
I'll
talk
more
about
that,
but
that's
what
enables
us
to
have
a
rich
ecosystem
or
ecosystem
and,
as
I
spelled
here,
rich
ecosystem
of
contract
components
and
that's
what
I'm
gonna
focus
the
rest
of
my
talk
on
okay.
A
So
here's
a
simple
example-
and
this
is
all
stuff-
that's
done
in
JavaScript
I-
should
point
out,
I,
say:
JavaScript.
It's
done
in
a
secure
subset
of
JavaScript,
which
is
much
of
what
we've
been
building
and
and
I'll
mention
later,
the
proof
of
concept
of
those
intermediate
layers.
But
I'm
gonna
stick
at
the
at
the
contract
layer
here,
okay,
so
we
have
a
mint
which
is
essentially
a
way
to
make
a
new
currency.
A
The
the
ledger
is
represented
as
purses
with
some
of
the
currency
and
the
operations
you
can
do
on
a
purse
are
get
a
balance
or
deposit
a
purse
from
that
same
currency
into
your
person
that
currency
right.
So
if
I've
got
I,
don't
want
to
be
able
to
deposit
apples
into
oranges,
I
can
only
deposit
oranges
into
oranges,
so
on
the
right,
we've
got
a
use
of
it
where
I'm
giving
this
concert
so
I
just
make
a
new
currency,
which
is
concert,
tickets
and
I'll
get
to
the
issuer.
In
a
moment.
A
Let's
say:
I've
got
a
received
ticket
method
that
I'm
supposed
to
invoke
on
on
caryl
to
pass
with
a
ticket.
I
can
make
a
ticket
and
I
could
just
pass
it
as
an
argument.
Now
you
know
remember:
I
mentioned
that
here
looks
synchronous
in
our
system.
It's
actually
asynchronous
and
Carol
might
be
in
the
same
blockchain.
She
might
be
in
a
different
blockchain
that
I'm
linked
to
asynchronously.
She
might
be
on
a
wallet
on
a
single
machine
or
on
a
permission
chain.
It's
all
the
same
from
the
point
of
view
of
here.
A
A
The
problem,
let
me
go
back
for
a
moment.
The
problem
is
they're,
just
JavaScript
objects.
I've
got
a
pointer
if
I've
got
a
pointer
to
a
ticket
and
I
pass
the
pointer
to
you.
Now
we
both
have
a
pointer
to
the
ticket.
You
haven't
you,
you
don't
necessarily
have
it.
I
could
go
and
use
it
before
you
do.
So.
How
do
we
deal
with
that?
Well,
we
deal
with
that
with
patterns
of
objects
right,
so
we
don't
need
to
add
new
magic,
there's
a
pattern
of
object
and
that's
where
the
issuer
comes
in.
A
A
So
in
the
previous
slide,
I
had
the
concert
issuer,
which
would
that
which
you
know
if
I'm
creating
the
concert
I
would
then
post
in
the
venue.
Here's
the
concert
issuer.
Here's
the
thing
by
which
you
can
verify
that
you
have
an
honest
to
gosh
ticket.
Instead
of
some
random
forgery,
so
Carol
receives
your
ticket.
I
could
have
sent
her
anything.
It
might
be
a
ticket
to
a
concert.
It
might
be.
You
know
a
cookie
I.
Don't
know,
and
so
what
the
get
exclusive
operation
on
the
issuer
does
is
it
does
two
things
simultaneously?
A
It
creates
it
takes
a
purse
in
the
issuer's
currency
and
creates
a
brand-new
purse.
Transferring
all
of
the
rights
were
in
the
original
purse
to
the
new
purse,
and
that
only
succeeds
if
the
original
purse
was
actually
in
that
currency.
If
I've
got
an
issuer
for
apples
and
I
pass
through
a
purse
of
oranges,
it
fails
right
and
what
that
means
is,
if
it
succeeds.
Not
only
do
I
know
that
I,
in
fact,
in
this
case,
got
a
concert
ticket,
but
I
also
know
that
I
now
have
exclusive
access
to
that
concert
ticket.
A
Nobody
else
has
access
to
that
concert.
Ticket
and
so
I
have
now
gone
from
just
passing
a
reference
in
an
object
or
gramming
language
to
actually
transferring
the
right
to
that
concert
ticket
right.
So
it
is
that
so
it
is
a
transfer
and
I
have
received
it.
So
in
this
case,
Carol
received
it
verified
that
she
has
it,
given
that
she
has,
she
returns
the
payments
to
me,
and
so
my
coat
down
below
was
my
I'm
into
the
ticket.
A
I
sent
it
to
Carol
I
got
the
payment
back
I
deposit,
the
payment
and,
in
my
account
right,
and
so
that
would
now
be
the
conclusion
of
a
sales
transaction,
of
course,
I'm
an
idiot
here,
because
she
might
not
pay
me
and
she's
got
the
ticket
and
now
she's
off,
and
she
goes
to
the
concert
and
I
never
get
my
money
right
or
she
gives
me
less
than
I'm
supposed
to
have
or
whatever
right
so
open
coding
low-level
stuff.
Again,
it's
a
lot
like
event
handlers.
A
You
know
wired
in
at
the
very
early
days
of
JavaScript.
You
can
do
it,
but
but
but
it's
it's
programming
without
a
rope
right
and
it's
this
is
where
frameworks
start
to
come
in.
So
what
do
we
have
as
a
framework
for
that?
We
have
what's
called
an
escrow
contract?
Most
people
have
heard
of
escrow
I've
got
a
ticket.
You've
got
the
money.
I
put
my
ticket
in
escrow.
A
Okay,
so
here
that's
exactly
what
I'm
doing
I
create
the
escrow
contract
I
send
to
Carol
her
side
of
the
escrow,
so
she
can
post
the
money
for
the
ticket
and
then
I
say
I'm
willing
to
exchange
my
newly
created
ticket
for
money,
in
my
account
equal
to
the
ticket
price,
and
if
she
provides
money
equal
to
the
syke
price,
then
she'll
get
the
ticket
right
and
then
what
Carol
does
is
the
opposite
side
of
that
she's
delivered
the
ticket
facet
or
a
ball
of
mud.
Whatever
I
sent
her?
How
would
she
know?
A
Well,
she
knows
because
that
very
same
get
exclusive
works
for
the
works
for
escrow
agents
right
so
now
she
knows
that
that
she
has
exclusive
access
to
the
outside
of
the
escrow
on
which
one
pays.
So
she
doesn't
have
to
worry
about
paying,
and
then
someone
steals
the
ticket
right.
She
has
exclusive
access
and
then
she
says
but
I'm
willing
to
give
you
this
person
money.
As
long
as
you
give
me
my
to
one
ticket
and
if
that
works,
then
she
succeeds.
A
The
closes
both
sides
get
what
they
want,
and
neither
side
was
at
risk
right.
So
now,
I've
got
this
escrow
agent
contract
that
I
used
in
order
to
complete
a
sale
and
it
provided
me
what
we
call
a
market
safety
property
where
you
know,
if
you
think
of
software
engineering
as
a
history
of
safety,
properties,
type
safety,
memory,
safety,
concurrency
safety
and
now
market
safety.
Where
you
know
in
the
frameworks,
we
provide
developers
to
be
able
to
build
user
interfaces.
A
You
know
nowadays
they're
really
not
worrying
about
dangling
pointers
in
C,
they're,
whipping
together
components
quickly
and
reactor
angular
and
that
set
of
bugs
that
might
be
a
dangling
pointer,
yeah.
That's
just
off
the
table
right,
that's
not
something
they
have
to
worry
about
accidentally
expressing
concurrency
bugs
are
the
same
way
right.
Reentered
C
is
an
issue
that
resulted
in
the
DAO
bug
you'd,
like
a
system
that
it's
not
that
you
have
to
be
smarter,
because
20
million
people
aren't
gonna
be
smarter
than
the
people
who
built
this
stuff.
A
A
So
that's
where
the
duality
comes
in
is
is
I,
showed
you
I
talked
about
a
couple
of
contracts
right:
smart
contract,
where
I
created
a
brand-new
right
out
of
whole
cloth,
which
was
the
ability
to
come
to
my
concert
right,
so
contracts
create
rights.
If
I
created
a
new
auction
contract,
the
seat
at
the
auction
to
be
able
to
bid
is
a
brand-new
right
that
I
created
right
and
then
some
contracts
manipulate
rights
or
exchange
rights
or
trade
rights,
and
so
that
extra
exchange
that
I
showed
you
it's.
A
Similarly,
you
know
I've
got
escrow
exchange
if
I
wrote
a
small
smart
contract
to
take
my
ticket,
which
remember,
is
now
this
first
class
right
that
can
participate
in
any
of
these
activities.
I
can
write
a
smart
contract
that
that,
if
you
call
exercise,
will
transfer
the
contract
trance
the
ticket
to
you
for
a
fixed
price
until
the
end
of
the
month.
Right
so
for
the
unto
the
end
of
the
month,
you
could
say,
exercise
and
pay
a
fixed
price.
A
That's
effectively
what
what's
a
covered
call
option
if
people
are
familiar
with
that
from
stock
markets
or
what
have
you,
but
I
can
do
that
as
a
fairly
small
contract.
The
way
we
do
that
in
our
system
is,
of
course
you
hit
exercise,
it
figures
out
the
price
and
then
I've
already
got
an
exchange
mechanism,
I'll
just
instantiate,
a
new
escrow
agent
in
order
to
engage
in
the
trade
that
happens
and
so
the
actual
delivery
of
the
underlying
good.
A
But
in
a
system
where
it's
just
an
object,
it's
a
first-class
participant
in
the
economy,
so
I
can
take
that
covered.
Call
and
I
can
turn
around
and
sell
the
covered
call
using
another
ester
exchange
or
using
an
auction
or
a
marketplace
and
I
can
sell
that
to
you
or
sell
that
to
someone
and
that's
the
duality
where
contracts
make
rights
and
contracts
participates
in
the
rights
that
they
make.
A
So
that's
where
we
get
those
reusable
components,
and
similarly
you
know
if,
when
we
build
an
auctioneer
in
our
system
again,
you
know
in
the
in
some
of
the
simple
examples
of
G
of
auctioneers.
You
know
they
have
all
the
money
handling
code
to
return
the
money
to
the
losing
bidders
in
our
system.
New
bidder
comes
in
I,
just
instantiate,
a
brand
new
escrow
agent.
A
Their
bid
goes
in
there
now,
if
they're,
the
winner,
I
give
them
the
good
in
the
escrow
agent
delivers
it,
but
I
can't
give
a
good
to
anyone
any
of
the
other
bidders
that
weren't
the
winners.
That
means
that,
even
if
I
have
a
bug,
I
can't
steal
their
money
right.
So
we've
got
the
that
means
I
get
to
use
this
same
escrow
agent
in
a
wide
variety
of
circumstances,
to
be
able
to
rapidly
compose
interesting
business
relationships
and
and
and
new
contracts.
That
I
can
then
further
use
to
build
other
businesses.
A
So
these
are
some
of
the
key
ingredients
that
we
will
need
so
that
the
millions
of
developers
out
there
are
able
to
build
interesting
contracts
in
the
same
way
that
they
can
build
interesting,
new
eyes
right
now,
so
we're
at
AG
work,
you
can
come
look.
You
could
tweet
at
us.
We
report
our
progress
weekly
on
proof-of-work
newsletter.
If
people
are
familiar
with
that,
we
have
a
proof
of
concept.
A
B
B
A
B
Well,
the
first
questions
like
why
not
use
something
like
typescript
because,
like
JavaScript,
doesn't
have
like
memory
safety
issues,
but
it
has
like
other
issues
of
like
you
know
that
modern
languages
honestly
have
like
just
new
new
references
where,
if
you
something
like
typescript
and
you
can
like
enforce,
you
know,
no
other
types
and
yeah
like
type
systems
can
be
like
very
helpful
for
developers
in
general
like
assure
safety
and
correctness
and
which
assume
was
yeah.
Okay,
the
goal
here
so.
A
I
think
the
the
language
you
said
is
why
not
use
something
like
typescript,
yeah,
okay
right
so,
first
off
we
may
write
the
important
thing
is
in
a
distributed
system.
You
can't
guarantee
what
the
other
guy
is
running
anyway.
So
you
must
dynamically
check
all
of
your
types,
so
architectural
a
typescript
is
useful
for
developers
and
we
totally
value
it
a
lot,
but
the
underlying.
What
actually
is
your
security
model
even
for
typescript,
its
JavaScript?
Now
we
actually
have
for
our
contracts.
A
We
have
a
subset
which
is
also
on
our
github
site,
called
Jesse,
a
subset
of
JavaScript.
You
know,
so
we
have
a
secure
subset
of
JavaScript
called
secure,
ACMA
script
that
we've
been
in
the
standards
body,
the
JavaScript
standards
body
for
ten
years,
driving
all
the
elements
that
go
into
that
and
and
then
we
have
a
much
much
tighter
subset
called
Jesse
that
our
formal
methods
partners
think
we
can
actually
do
a
sound
type
system
for
and
then
we
would
do
something
types
of
AB
like
so
I.
A
Don't
have
any
problem
with
types,
but
you
know
fundamentally,
typescript
is
not
a
sound
type
system.
You
cannot
rely
on
it
for
security
and
correctness.
You
can
rely
on
it
for
helping
development
process
and
it's
great,
but
but
but
it's
not
enough
for
first
mutt
contracts,
and
so
we
need
a
model
and
the
other
thing
is
the
language
is
way
less
important
than
the
security
model
right,
so
replacing
the
surface
syntax.
You
know
even
going
from
solidity
to
you.
Azzam
the
security
model
is
the
EVM
model.
A
That's
the
important
model
for
aetherium
in
in
this
thing,
the
important
model
is
the
objects
and
figuring
out
what
operations
they
do.
The
operations
don't
matter.
If
you
can
trivially
prove
that
that
guy
cannot
get
access
to
my
bank
account
I,
don't
care
what
his
code
does.
He
can't
touch
my
bank
account
and
I'm
done
right,
and
so
you
end
up
having
much
simpler
ability
to
reason
about
the
reference
crap
graph
rather
than
the
type
graph,
and
so
that's
enough
more
powerful
that
that's
our
primary
focus.
A
More
questions
I'll
teach
you
up
here
by
the
way
behind
there
is
they
kept
talking
about
the
escrow
agent?
So
that's
the
code.
You
know
from
from
from
at
least
some
version
of
our
of
our
implementation,
proof
of
concept,
20
lines
of
JavaScript
that
implement
of
secure
JavaScript
that
implement
an
escrow
agent
that
works
across
all
kinds
of
resources.
B
A
It
is
an
accident
of
history
in
the
way
the
standards
of
JavaScript
came
in,
partly
that
there's
sort
of
a
user
mode
system
mode
separation
in
JavaScript
like
in
operating
system,
so
the
JavaScript
Standards
Committee
doesn't
get
to
talk
about
the
document
and
Windows
you
get
from
HTML.
That's
often
wc3.
It
just
has
a
model
of
JavaScript
where
you
know
it's
running
in
a
host
environment
and
there's
some
privileged
object
that
gets
handed
in,
which
is
the
document
of
the
window.
A
So
in
the
smart
contract
world
we
don't
have
that
document
in
window,
so
in
JavaScript,
without
our
security
kernel,
as
we
call
it
one
JavaScript
program
loads.
Another
the
loaded
JavaScript
program
can
crawl
around
and
steal
all
the
secrets
and
change
everything
in
the
JavaScript
environment
that
loaded,
it
we've
been
working
overtime
to
add,
features
to
JavaScript
proxies
promises
week.
Maps
a
bunch
of
these
other
features
to
be
able
to
produce
a
security
kernel.
A
A
B
A
So
it
will
all
be
open-source.
Eventually
there
will
be
some
pieces
that
we
will
open
source
when
we're
very
close
to
deploying
our
chain.
So
we
get
to
capture
some
of
the
network
effect
but
yeah,
absolutely
it's
all
open
source
so,
for
example,
that
security
kernel
we
open
sourced.
Very
you
know
in
the
very
first
two
months
of
our
operation
in
order
to
get
it
out
there,
so
people
can
use
it
to
secure
the
web
right.
B
A
The
answer
to
the
latter,
one
is
all
in
reverse
order.
The
answer
is
yes,
there
is
a
network
or
there
will
be
so
the
relation.
So
we've
done
a
lot
of
innovation,
a
lot
of
different
levels,
but
there's
people
who've
been
working
on
blockchain
consensus
mechanisms
for
a
really
long
time
and
have
a
lot
of
great
ideas
there
and
you
know
polka
dot
is
a
big
one.
A
We
started
looking
at
substrate
when
we
were
first
working
on
building
our
own
chain
and
looking
at
substrate
as
an
implementation
vehicle
for
building
our
own
chain
and
we're
looking
it's
like.
Oh
there's,
a
bunch
of
great
ideas,
they're,
you
know
they're
complementary
to
our
ideas.
They
support
ideas.
We
can
integrate
well
and
so
my
goal.
Our
goal
is
to
get
the
contract
model
out
there
as
soon
as
possible
as
widely
as
possible,
so
people.
A
Now,
when
I
said
yes
because
originally
and
architectural
II,
we
are,
we
do
secure
messaging
between
machines
that
chain
that
pair
of
chain
is
a
machine
and
it
can
perfectly
well
extend
our
uniform
fabric
over
to
other
permission,
networks
running
our
model,
other
pair
of
chains
running
our
model
or
a
layer.
One
chain
running
our
model.
So
you
know
we're
gonna
start
there,
we're
really
looking
forward
to
it.
We're
very
excited
about
the
polka
dot
ecosystem.
But
but
you
know
we
don't
intend
to
stop
there.
A
We
intend
to
work
with
it
with
with
a
lot
more
partners
to
enable
that
same
model
to
spot,
to
be
able
to
bridge
across
multiple
chains
and
that's
you
know:
polka
dots
been
all
about
bridging
across
multiple
chains
for
a
long
time
as
well,
so
that's
entirely
compatible
not
just
with
their
technology
but
also
with
their
ideals,
and
so
so
you
know
and
and
they've
helped
us
articulate
some
of
those
too.
So
so
it's
a
good
partnership.
B
Hi
I'm,
just
over
here,
yeah
thing.
Thanks
for
the
talk,
a
crate
approach,
love
it
great
work.
What
what
I'm
asking
or
about
I'm
asking
myself
is
since
polka
dot
is
really
trying
to
give
this
very
generic
approach
to
to
build
up
and
and
deploy
blockchains.
Have
you
yet
identified
some
restrictions
or
some
prerequisites
that
would
come
for
us
to
be
able
to
like
integrate
agaric
on
top
of
some
polka
dot
network
and
pair
of
chains?
So.
A
We
do
have
restrictions,
some
of
which
we
need,
some
of
which
we
like
I,
guess
I
mean
we,
so
finality
helps
a
lot
right.
You
know,
and
so
so
so
finality
is
important.
It's
not
crucial,
but
the
thing
is:
when
I
send
a
message
when
I
send
money,
you
know,
and
it's
probabilistic,
okay
I
know
my
outside
risk.
A
When
I
send
a
message,
you
know
that
then
has
some
action
in
the
real
world
ship,
the
medicine
right
now
having
a
probabilistic
reversion,
it's
like
crap,
now,
I,
don't
know
where
the
medicine
is
even
worse,
ship,
the
samples
or
you
know
whatever.
It
is,
that's
bad,
so
you
really
want
finality
if
you're
doing,
if
you're,
in
a
system
where
the
results
can
cause
action
in
the
real
world
as
opposed
to
just
money
transfer.
The
other
thing
is
that
we
prefer
an
account
model
rather
than
a
you
TXO
model,
because
it
means
you
know.