►
Description
Part 4: Writing Composable Smart Contracts
The Agoric stack is designed to support one main goal: to make it easy to write smart contracts that are more reliable, more understandable, and, especially, more composable. We introduce the Agoric contract layer as a distinct layer of abstraction that makes defining and exchanging digital assets (erights) as simple as standard programming.
A
So
we
built
all
of
this
mechanism
up
so
that
we
can
write
reliable,
composable,
smart
contracts,
here's
where
we
get
to
the
payoff.
This
last
section
is
kind
of
the
punchline
of
the
whole
talk.
So
how
do
we
use
all
of
this
infrastructure
to
write
smart
contracts
that
are
more
reliable,
more
understandable
and
especially
more
composable.
A
So
the
smart
contract
layer,
this
layer
of
electronic,
writes
and
smart
contracts
is
really
a
distinct
level
of
abstraction
than
the
object
layer.
In
order
to
understand
this
distinction
of
layers,
we
need
to
see
how
to
build
an
electronic
write
out
of
objects
and
the
best
example
for
showing
that
is
money.
A
The
code
on
the
right
implements
money
out
of
objects,
and
it
does
so
following
the
pattern
you
already
saw
in
the
counter
example
on
the
outside:
there's
a
make
mint
function
and
every
time
the
make
mint
function
is
called.
It
creates
this
triple
of
a
new
ledger,
a
new
issuer
and
they
new
mint
and
that
triple
represents
a
distinct
currency.
So
every
time
we
call
make
mint,
we
get
a
new,
distinct
currency
and
each
of
these
currencies
are
isolated
from
each
other.
A
Where
do
new
units
of
currency
come
from
the
mint?
Has
a
method
called
make
purse
that
creates
a
purse
object
and
registers.
The
purse
object
in
the
ledger
associated
with
its
initial
balance.
Now
this
ledger
is
not
the
normal
blockchain
ledger.
This
is
an
object
table.
This
is
a
table
indexed
by
object,
identities,
there's
no
public
keys
here
at
this
level
of
abstraction.
We
don't
see
any
cryptography.
We
just
see
symbolic
object
computation.
A
A
A
A
The
point
of
an
object
is
mostly
to
invoke
it
to
cause
behavior
to
do
something
with
it,
whereas
mall
money
is
purely
symbolic,
you
can't
do
anything
with
it.
Other
than
traded
further
objects
are
opaque.
What
is
it
that
Bob
received
when
he
received
this
object?
He
has
no
idea.
It's
just
some
object
that
he
got
from
someone
who
could
send
him
a
message,
whereas
he's
not
paid
until
he
knows
how
many
units
he's
gotten
of
what
currency.
A
A
So
to
turn
the
object
that
bob
has
gotten
into
getting
paid
Bob
sends
a
deposit
message
to
his
main
purse
with
the
payment
purse.
As
an
argument,
the
main
purse
looks
up
the
payment
purse
in
the
ledger
and
if
the
payment
purse
is
in
the
ledger-
and
only
then
is
it
actually
a
legitimate
purse
of
this
currency.
A
So
from
this
contrast,
it
might
seem
that
objects
are
about
the
column
on
the
left
and
ear.
I'ts
are
about
the
column
on
the
right.
While
objects
are
about
the
column
on
the
left,
however,
bayi
writes
we
mean
the
entire
taxonomy
opened
up
by
this
contrast.
All
of
these
dimensions
of
variations
and
several
others
we
want
to
describe
through
the
e,
writes
interfaces
so
that
we
can
write
generic
contracts
that
can
manipulate
any
write
that
can
be
described
with
those
interfaces
and
that
fits
in
this
taxonomy.
A
There's
another
way
in
which
objects
differ
from
the
world
of
smart
contracts,
which
is
the
basic
transaction
object
system.
Is
the
message
send,
which
is
a
one-way
transfer
of
rights,
whereas
for
smart
contract,
the
core
operation
is
an
all-or-nothing
exchange
of
rights
where
either
both
rights
have
been
exchanged
or
it's
as
if
nothing
happened.
A
An
example
of
an
exchange
oriented
contract
is,
what's
called,
the
covered
call
option
say
that
Bob
has
bought
an
expensive
concert
ticket
and
now
Bob
realizes
he'll
be
out
of
town
during
the
concert,
and
he
mentions
this
to
Alice
and
Alice
says.
If
I
give
you
10
bucks,
can
you
hold
the
concert
ticket
for
me
through
the
weekend
so
that
I
can
find
out
whether
I
can
attend,
in
which
case
I'll
buy
the
concert
ticket
firm
from
you,
so
that
arrangement
is
what's
known
as
a
covered
call
option.
A
To
express
a
covered
call
option,
the
important
lines
are
these,
where
the
covered
call
option
first
obtains
from
Bob
into
escrow
the
concert
ticket
that
he
would
be
offering,
and
only
once
those
rights
are
safely
in
escrow.
Does
the
contract
create
the
ability
for
Alice
to
participate?
In
some
sense,
the
contract
doesn't
really
exist
as
a
contract,
until
it
has
confirmed
that
Bob's
rights
are
in
escrow
and
Bob's
rights
are
in
escrow
until
the
deadline
expires.
A
This
line
arranges
that,
once
the
deadline
expires,
Bob
can
get
his
concert
ticket
back,
but
not
until
then,
so
this
contract
sits
between
four
other
parties.
The
two
issuers
of
the
two
rights
at
stake
and
Alice
and
Bob,
and
the
contracting
framework,
creates
these
two
chairs,
representing
Alice's
ability
to
participate
made
in
the
contract
and
Bob's
ability
to
participate
in
the
contract.
A
Now
any
contract
that
unfolds
over
time
creates
a
valuable
situation
that
Alice
by
being
able
to
participate
in
this
contract
by
having
this
role
in
the
contract
until
the
weekend
is
over.
Alice
is
in
a
valuable
position
and
we
would
like
to
take
these
derived
values
and
turn
them
into
derived
credible
rights.
A
So
the
same
contract
framework
that
creates
this
chair
around
the
cover
call
option,
creates
it
as
a
chair
issuer
that
can
act
as
in
the
role
of
issuer
to
get
other
contracts,
so
in
this
example,
alice
might
be
negotiating
with
Fred
to
sell
Fred.
The
covered
call
option,
and
the
important
thing
to
understand
here
is
that
these
contracts
are
generic.
The
escrow
exchange
being
used
by
Alice
to
negotiate
with
Fred
has
no
idea.
A
It's
point
is
to
exercise.
Bob
is
interested
so
that
he
has
the
ability
to
exercise
the
option
and
actually
get
the
concert
ticket
like
money.
It
needs
to
be
a
saleable
so
that,
even
though
the
escrow
exchange
doesn't
know
what
a
covered
call
is
Bob
can
explain
to
the
escrow
exchange
can
describe
to
the
escrow
exchange.
What
right
it
is
that
he
wants.
So
he
knows
what
he's
bargaining
for,
so
that,
if
you
get
it,
he
can
know
that
what
he
gotten
is
what
he
bargained
for
and
like
an
object.
A
A
So
how
did
we
do
on
the
challenges
we
set
out
to
solve?
We
addressed
the
hazardous
nasai,
creating
a
computational
paradigm
for
doing
secure,
distributed
programming
that
can
be
used
more
reliably
and,
more
understandably,
by
introducing
object
capabilities
by
identifying
this
discipline
subset
of
JavaScript
Jessie
by
the
bang
here
I
mean
the
asynchronous
communication
model
for
sending
asynchronous
messages
and
most
of
all,
the
ability
to
write
contracts
as
patterns
of
objects,
staying
purely
within
the
symbolic
realm
of
objects
not
having
to
go
back
to
cryptographic,
concepts
which
are
notoriously
hazardous
to
get
right.
A
We
addressed
the
unfamiliar
languages
by
enabling
our
users
to
write
their
code
in
JavaScript
itself.
We
address
these
the
non
composability
by
this
duality
of
a
rights
and
contracts
that
contracts
manipulate
a
rights
and
by
manipulating
them
they
create
derived
rights
where
those
derived
rights
are
the
kinds
of
rights
that
these
contracts
themselves
can
manipulate.
This
is
higher-order
composability,
allowing
us
to
build
deep
networks
of
highly
reusable
contact,
contract
components
and,
most
of
or
most
of
all,
we're
very
aggressively
cross-platform,
avoiding
any
kind
of
single
chain
lock
in.
B
A
The
premise
of
every
block
chain
is
that
there
will
be
valuable
assets
on
that
block
chain
and
for
the
block
chain.
Supporting
general-purpose
computation
are
the
premises
further,
that
there
will
be
contracts
running
on
that
block
chain,
manipulating
assets
if
each
of
those
is
a
separate
island.
If
you
can't
write
contracts
that
interact
with
other
contracts
and
interact
with
that
are
elsewhere
and
interact
with
assets
that
are
elsewhere,
then
you
have
a
world
of
separate
villages
rather
than
anything
like
a
global
marketplace.
A
B
A
So
our
focus
is
creating
the
level
of
symbolic
object,
programming
that
is
independent
of
the
location
of
the
objects
that
it's
interacting
with
the
layering
on
top
of
cap
DP
on
top
of
IBC,
is
in
order
to
enable
that
independence
and
then
able
the
rich
connection
between
computations
that
have
been
located
in
different
places.
Different
share.
The
reason
there
are
so
many
chains
is
there's
a
lot
of
different
hypotheses.
A
People
are
pursuing
about
what
the
right
way
to
build
a
chain
is,
and
it's
not
that
one
of
those
will
be
the
winner
that
one
of
those
has
the
right
hypothesis
and
the
other
wrong.
There
are
many
different
trade-offs.
These
trains
are
addressing
different
points
in
the
trade-off.
Space
they'll
continue
to
coexist
and
we
want
a
fabric
that
spans
over
that
coexistence.
So
the
ibc
fabric
that
we
we
found
out
when
we
came
across
IBC
from
cosmos.
A
C
A
If
you'll
require
recall
the
swingset
diagram
in
which
one
of
the
vats
was
a
wasn't,
that
that
was
in
VAT
could
be
a
wasm
that
running
rust,
compiled
to
Azzam.
As
long
as
it
can
speak.
The
interval
excuse
me
the
interface
to
the
swingset
kernel.
It
can
participate
as
a
full-fledged
citizen
in
that
world.
A
We
have
not
actually
done
that,
but
we're
architecting
the
system
so
that
we
have
that
ability
all
together
we're
building
the
systems
in
a
very,
very
modular
fashion,
because
we
want
to
get
as
much
buying
as
possible
for
the
individual
components
from
people
that
don't
buy
into
the
rest
of
the
architecture.
So
that's
why,
for
example,
collaborating
with
Salesforce
on
creating
the
SES
mechanism
that
they're
using
in
the
Lightning
platform
they're
using
SES
in
the
absence
of
the
other
technologies.
A
Javascript
I've
been
very
clear
about
all
the
downsides
of
JavaScript.
All
the
liabilities
of
the
language
that
we
started
from
javascript
also
has
some
incredible
asset
which
are
absent
from
other
industrial
languages.
So
in
terms
of
getting
adoption,
let's
consider
only
the
candidates
which
are
languages
used
commercially,
not
academic
languages
among
such
languages
JavaScript
because
of
an
historical
accident
has
a
beautiful
separation
between
the
computational
ability
of
the
language
per
se
versus
the
I/o
abilities
provided
by
the
host.
A
The
historical
accident
is
that
the
JavaScript,
the
language
was
being
standardized
under
ECMO,
while
the
browser
API
was
being
standardized
under
the
w3c
and
even
though
JavaScript
started
as
a
language
only
for
programming
the
browser
that
organizational
split
kept
browser
concepts
mostly
out
of
JavaScript
and
in
particular,
kept
browser,
IO
concepts
completely
out
of
JavaScript,
and
that's
a
real
miracle.
When
the
browser
was
the
only
host
we've
done
a
similar
exercise,
securing
Java
where
Java
you
would
expect
to
be
a
much
more
suitable
language
for
creating
an
object
capability
version.
A
We
created
an
object
capability
version
called
Joe
II,
but
Java
mixed
io
and
computation
willy-nilly
through
the
API
s
in
the
standard
library.
So
by
the
time
we
succeeded
in
making
a
separation,
the
libraries
were
so
different
that
essentially
no
old
Java
code
right
javis
Java
code
ran
in
Joey
that
separation
in
JavaScript
is
really
beautiful.
Another
thing
is
I
mentioned
that
part
of
the
rule
and
object
capabilities
is
that
an
object
can
only
cause
effects
by
using
references.
That's
been
the
case
with
JavaScript
the
the
downsides
of
javascript
from
security.
A
Point
of
view
had
to
do
with
what
effects
it
can
call
and
what
references
it
can
obtain
for
causing
those
effects.
But
all
of
the
references
that
enable
it
to
affect
the
outside
world
are
looked
up
first
by
looking
up
a
global
variable
name
in
the
global
environment
and
therefore,
if
you
can
intervene
in
that
look
up,
you
can
virtualize
everything
the
way
you
can
build
a
virtual
machine
out
of
a
machine
that
has
a
clean
system,
mode
user
mode
architecture
in
a
similar
way.
A
Javascript
is
neither
better
or
worse
than
wasm
they're
at
different
levels
of
abstraction.
Wasm
is
an
instruction
set
architecture.
It's
an
instruction
set
architecture
that
has
the
security
properties
of
a
process
with
an
address
space
where
it's
a
flat
address
space
and
we've
seen,
for
example,
with
the
recent
exploit
on
0x
or
actually
the
the
vulnerability
that
0x
discovered
before
it
was
exploited.
Fortunately,
but
that
was
a
mismatch
between
the
solidity
level
of
abstraction
and
the
EVM
level
of
abstraction.
A
Azzam
is
good
at
enforcing
a
security
boundary
there,
but
as
far
as
the
code
running
in
the
wasm,
you
still
have
all
of
the
problems
of
programming
language
design
that
you
have
to
solve,
because
the
programmer
is
thinking
in
terms
of
separate
objects
with
memory,
safe
pointers
to
each
other,
and
you
need
to
live
up
to
that
expectation.
If
the
security
properties
of
the
platform
you're
delivering
meet
the
expectations
that
are
implicit
in
the
assumptions
the
programmers
make
when
they
write
their
their
program
and
I.
Think
I.
B
Just
want
to
add
one
one
thing
to
that:
it's
important
these
levels
of
abstraction
that
javascript
is
a
programming
language,
a
lot
of
people.
You
know,
oh,
we
can
replace
solidity
with
wasm.
That's
not
an
answer.
Azzam
is
not
a
programming
language
except
to
a
very
few
low-level
hackers
right
and
and
they're
the
ones
that
will
that
will
be
in
the
best
position
to
compromise
it.
But
it's
not
a
programming
language.
So
it's
not
a
substitute
for
a
real
answer.
There.
A
C
Could
you
speak
to
the
libraries
that
you
expect
to
be
built
with
these
smart
contracts?
Do
you
expect
a
strong
standard
library
to
be
built
by
you
or
a
small
group
and
then
a
lot
of
other
kind
of
long
tail
of
contracts?
Or
do
you
actually
expect
the
standard
library
to
be
pre,
rich
and
robust,
maybe
similar
to
how
known
an
NPM
kind
of
built
a
very
rich
and
robust
library
of
code
from
the
community,
meaning
there's
a
huge
variety
of
contracts
to
make
here?
C
Maybe
some
of
them
which
can
be
built
out
of
smaller
primitives
and
then
make
richer
and
richer
layers,
but
I'm
curious
about
this
kind
of
stuff,
because
those
adoption
patterns
and
the
actual
what's
available
in
that
toolkit
and
how
easy
it
is
to
add
to
that
toolkit
at
the
ends
of
being
a
very
significant
reason
for
adopting
or
not
adopting
it.
I'm.
A
Very
glad
to
get
this
question
because
it
gives
me
the
opportunity
to
emphasize
something
that
I
hadn't
really
emphasized,
which
is
at
the
smart
contracting
layer
we're
building
a
rich
framework,
we're
trying
to
create
a
rich
framework
for
the
purpose
of
supporting
smart
contracts
in
very
much
the
same
way
that
people
build
rich
user
interface
frameworks
like
react
or
rich
server-side
frameworks.
We
want
to
populate
that
framework
with
highly
reusable
smart
contract
components
like
the
escrow
exchange
that
you
saw
and
in
particular
Java.
A
One
of
the
another
interesting
virtue
of
JavaScript
is
the
dynamic
range
of
programmers.
Skill
that
JavaScript
accommodates
is
really
quite
large.
It's
probably
a
larger,
useful
dynamic
range
than
is
experienced
by
other
industrial
languages.
So
people
constructing
frameworks
put
a
lot
of
care
into
constructing
the
framework
and
constructing
the
composable
components
and
then
with
high
end
and
the
key
thing
there
is
that
the
components
by
being
highly
reusable
components
can
be
deeply
vetted
by
experts,
creating
those
components
and
then
other
people
composing
such
components.
C
So
I
know
that
azzam
ABI
Zoar
there
are
actually
some
compatibility
issues
there
and
so,
like
Watson
compiled
from
jazz
versus
rust,
might
not
actually
be
quite
as
compatible
as
you,
as
you
think
so
do
the
swing
set.
Then
in
the
swing
sets
and
the
general
message-passing
architecture
kind
of
update,
there's
problems.
A
A
That
polkadot
writes
that's
compiled
also
through
LLVM
to
wasm,
compiles
to
Azzam
in
such
a
way
that
it's
not
easy
to
figure
out
how
to
link
them
together
and
that
turned
out
to
be
a
show-stopping
problem
for
us.
At
the
time
we've
talked
to
Frederick
at
a
polka
dot
about
this
problem,
he's
aware
of
it,
they
they're
they
know,
were
blocked
on
it
and
they're
working
on
it,
and
once
we've
surmounted
this
problem,
then
we
intend
to
revisit
building
on
top
of
a
polka
dot
as
a
pair
of
chain.