►
Description
Brian Warner, Engineering Lead at Agoric, will walk you through reentrancy hazards and how to protect yourself against them. He will also walk through access control mechanisms, comms layer, and c-lists.
Get started with Agoric: https://agoric.com/documentation/getting-started/
ABOUT
Build Fast, Earn Fast - Agoric enables developers to rapidly deploy dapps and DeFi markets on-chain using composable JavaScript smart contracts. Safely get your project from vision to global market.
LINKS
https://agoric.com
https://agoric.com/twitter
https://agoric.com/discord
https://agoric.com/telegram
https://agoric.com/newsletter
Click the 'SUBSCRIBE' button to follow our Youtube channel!
A
Hey
so
my
name
is
brian
warner,
I'm
an
engineer
at
agoric,
I'm
going
to
be
talking
about
a
couple
of
different
features
of
our
platform,
I'm
going
to
go
into
reentrancy
hazards
and
how
to
protect
against
them.
I'll
talk
about
access
control
mechanisms
and
I'll
go
into
the
comms
layer.
The
c
list
that
we
use
to
have
the
different
machines
in
our
system
talk
to
each
other.
So
let's
dive
right
in
so
we
have
good
kate.
A
Stills
has
a
good
medium
post
on
this
from
about
two
years
ago
now
in
which
she
is
describing
how
to
protect
reentrancy
attacks
in
ethereum
in
particular.
So
imagine
that
you
have
some
simple
little
program
that
lets
somebody
buy
a
painting
and
you
check
you
know
by
painting
for
100
bucks
you
buy.
You
check
their
balance,
you
call
a
customer
provided
function
to
deliver
the
painting
to
them,
and
then
you
deduct
the
balance.
If
you've
done
programming
in
ethereum,
you
can
already
see
the
danger
here.
A
You
know
the
kind
of
time
of
check
to
time
of
use
sorts
of
problems.
What
we
expect
the
user's
delivery
method
to
do
looks
something
like
this.
In
this
kind
of
visual
language
here
this
is
supposed
to
represent
the
stack
frames
and
the
control
flow.
So
control
starts
by
entering
into
the
by
painting
function.
It
is
going
to
do
the
balance
check
internally
and
then
it's
calling
out
to
this
user
provided
delivery
function,
which
may
have
some
subroutines.
A
It
may
do
some
other
stuff,
and
then
we
expect
that
that's
just
going
to
return
normally
and
then
we
can
deduct
the
balance.
So
this
is
the
kind
of
happy
path
and,
if
you're,
if
you're
being,
if
you're
under
pressure,
you
might
only
think
about
the
happy
path
to
make
your
stuff
work,
but
the
surprising
path.
You
know
the
most
obvious
thing
that
that
the
delivery
function
could
do.
That
would
be
surprising,
is
to
throw
an
exception,
and
that
would
bypass
the
extra
work
you're
doing
afterwards.
A
A
A
Somebody
can
add
a
subscriber
to
the
set
they
can
remove
a
subscriber
from
the
set
and
they
can
publish
a
message
to
everybody
in
this
set,
and
what's
supposed
to
happen,
is
that
every
time
somebody
publishes
a
message,
every
subscriber
should
get
one
copy
of
it
in
the
order
that
got
published.
I
love
this
example,
because
there's
maybe
four
lines
of
actual
code
here
and
there's
at
least
four
ways
in
which
you
can
just
explode.
It's
simple:
it's
easy
to
read
and
it's
horribly
horribly
flawed.
A
It
kind
of
captures
everything
if
the
user
provided
update
function
were
to
throw
an
exception.
Then
that
would
break
this
loop
and
only
half
your
subscribers
would
get
the
message.
The
other
half
wouldn't
see
anything
because
we'd
have
jumped
we'd
have
broken
out
of
the
loop.
If
that
update
function
were
to
add
a
new
subscriber,
then
does
the
new
subscriber
get
the
current
message?
A
Do
they
not
get
the
current
message
you're
mutating
in
and
a
set
that
you're
actively
iterating
over
and
the
behavior
of
that
depends
upon
the
language
you're
using
something
like
java
is
going
to
throw
an
exception.
It
doesn't
let
you
mutate
something
while
you're
walking
through
it.
Other
languages
may
do
something
completely.
A
A
So
this
code,
there
are
ways
to
work
around
this.
There
are
ways
to
protect
yourself
against
this.
You
might
put
a
make
a
copy
of
the
subscriber
set
before
you
iterate
over
it
to
protect
against
mutation.
You
might
put
a
try
catch
around
the
update,
call
to
protect
against
exceptions
that
take
place
there
or
you
might.
A
In
addition
to
those
things,
you
might
add
a
flag
to
say
whether
we're
in
the
middle
of
doing
a
publish
and
if
somebody
tries
to
publish
while
we're
in
the
middle
of
publish
you
queue
their
update,
and
then
you,
you
service
the
queue
after
you
come
back
from
the
whole
thing,
and
so
you
can.
You
can
mitigate
these
hazards,
but
it
would
make
this
code
at
least
three
times
as
long
as
it
is.
A
It
wouldn't
fit
on
a
slide
anymore
and
and
really
this
code
is
kind
of
perfect
as
it
stands,
except
for
this
fatal
horrible
flaw.
This
code
ought
to
work,
but
there's
hope
with
just
one
character.
This
code
can
be
saved,
adding
that
little
tilde
in
there
changes
that
immediate,
send
immediate
call
to
the
update
into
an
eventual
send,
and
that
makes
this
thing
safe.
A
Now
this
this
syntax
is
kind
of
new
this,
this
till
dot,
syntax,
tilde
dot.
Syntax,
is
something
that
we
proposed
to
the
ecmascript
committee
to
provide
this
eventual
send
operator
in
standard
javascript
in
a
gorick
codebase,
because
the
till
dot
syntax
is
not
known
by
ides.
Editors
would
would
highlight
this
as
a
as
a
as
a
typo
in
a
lot
of
agora
code.
You'll
see
this
other
form
with
the
e
function,
and
this
expands
to
the
same
thing
both
of
these
are
are
roughly
equivalent
to
the
last
line.
A
This
is
another
neat
thing
here
is
that
the
eventual
send
operator
returns
a
promise
for
the
result
of
whatever
the
update
returned.
So
if
you
want
to
chain
methods,
you
know
you
send,
you
send
one
message
and
it
gives
you
back
a
value,
and
you
want
to
send
another
message
to
that
second
value.
Then
you
can
chain
these
things
together,
so
because
eventual
send
returns
a
new
promise.
For
that
result,
you,
if
you
don't
need
the
intermediate
result.
You
can
chain
these
things
together
in
a
very
concise,
elegant,
syntax.
A
This
also
enables
a
thing
called
promise.
Pipelining
that
michael
alluded
to
in
the
last
talk
where
you
can
batch
all
of
the
messages
going
to
a
remote
machine
together
into
a
single
bundle,
rather
than
waiting
for
a
round
trip
each
time.
If
you
don't
need
to
wait
for
results
to
here,
then
you
can
send
them
the
more
message
early.
You
can
say
I'm
going
to
send
you
update
and
whatever
that
returns,
please
send
a
second
one
to
it.
A
So,
to
contrast,
the
two
different
kinds
of
invocation,
the
immediate
call
here
would
look
like
this:
that
the
publish
method
does
some
setup
work,
maybe
call
it
begin.
It's
expected
to
do
some
stuff
at
the
end,
and
then
it
calls
each
of
these
customer.
You
know
user
provided
attacker
provided
update,
functions,
synchronously
inline.
A
The
hazard,
of
course,
is
that
any
one
of
these
update
functions
might
throw
an
exception
or
might
call
back,
and
the
publisher
might
do
something
else.
That
surprises
you
in
the
eventual
send
flow.
It
merely
cues
calls
to
this,
and
it
pushes
it
onto
the
run,
queue
onto
that
microtask
queue,
and
so
later
after
we've
returned,
then
it
finally
goes
and
calls
those
update
functions,
and
so
nothing
that
update
does
can
surprise
us
because
we're
not
even
running
anymore.
So
the
arc
platform
has
a
more
generalized
mechanism
here.
A
This
run
queue
that
that
pushes
all
kinds
of
messages
onto
the
queue,
and
this
turns
out
to
be
a
pretty
distinctive
feature.
If
you,
if
you're
familiar
with
the
way
that
ethereum
works,
then
every
message
every
every
activity
on
the
chain
starts
with
a
signed
message
signed
transaction
that
is
broadcast
to
all
of
the
miners,
that
the
contract
that
that
message
is
delivered
to
has
some
internal
subroutines.
It
can
do
some
work
there
and
with
the
call
opcode,
it
can
call
out
to
a
different
contract,
but
all
of
those
other
contracts
are
invoked.
A
A
There
is
no
synchronous
calling
from
one
contract
to
an
unrelated
one.
In
addition,
the
message
that
triggers
execution
might
not
come
from
some
solo
machine
sending
something
with
it
with
a
public
key.
So
there
are
a
variety
of
events
that
can
trigger
this
thing
and
and
all
of
the
wiring
from
one
step
to
the
next
happens
through
promises
so
in
in
this
example,
here
the
contract
tells
contract
one
tells
contract
two
to
do
something,
and
by
putting
a
then
on
that
call
to
start
that
eventual
send
call
to
start
contract,
one
will
get
control
again.
A
Once
contract
two
is
finished.
With
its
start
in
contract,
two,
it's
going
to
subcontract
out
to
contract
three
and
do
some
more
work.
When
that
comes
back
and
because
start
is
returning,
the
contract
start
is
returning
that
promise.
It
means
that
contract
one
can
wait
for
it.
So
all
of
these
events
are
are
lined
up.
They're
all
happening
on
separate
turns
so
they're
all
safe
against
each
other,
doing
surprising
things,
and-
and
this
is
how
a
lot
of
our
our
platform
is
built.
A
A
It
doesn't
need
to
do
anything.
This
is
this
is
going
to
ignore
it.
So
so
the
contract
just
returns,
nothing
special
happens
and
then,
even
later,
the
timer
fires
and
the
the
timer
notifies
the
contract.
That
time
has
passed.
The
contract
says:
oh
hey.
That
means
that
I
have
to
expire
now.
Whatever
we
were
going
to
do
didn't
happen
within
the
the
expected
time
period,
so
we're
going
to
close
out
now
it
might
notify
the
escrow
property.
It
should
settle
some
stuff
when
that
finishes.
A
A
I'll
wrap
up
this
part
with
a
warning
in
2017
about
three
years
after
promises
were
added
to
javascript
the
language
acquired,
the
async
await
syntax.
This
is
a
mechanism
by
which
you
can
mark
a
function
as
always
returning
a
promise
and
from
within
that
function
you
can
wait
for
other
promises.
You
can
block
effectively
block
execution
until
that
is
fired.
This
makes
a
lot
of
operations
very
easy
to
read,
but
it
can
reintroduce
this
this
reentry
hazard.
A
So
in
this
example,
you
know
suppose
that
we're
logging,
this
message
after
we
send
the
delivery,
the
the
to
deliver
the
painting-
and
we
don't
know
that
that
is
we
know
it's
not
gotten
there
yet.
So
the
message
is
delivery
sent
it's
not
delivery.
Complete.
Now.
Imagine
that
your
product
manager
comes
along
and
says
you
know
this
message
is
kind
of
wishy-washy,
I'd
really
like
it.
If
it
were,
we
could
tell
somebody
that
the
delivery
had
actually
succeeded
and
not
merely
that
it
was
scheduled
for
the
future.
A
So
somebody
comes
along
and
says:
oh
hey.
I
know
about
this
await
thing.
We
will
just
not
emit
the
log
message
until
we've
finished
doing
this
delivery
and
an
async
await.
Is
a
nice
elegant,
readable
way
of
doing
this,
but
this
brings
back
this
resurrects,
the
reentrancy
hazard,
because
none
of
the
code
beyond
this
point
is
going
to
execute
until
after
the
user
provided
deliver
function
has
run
and
as
we
saw
before,
that
can
do
whatever
it
wants
and
can
do
something
really
surprising.
The
async
here
is
fine,
that's
not
causing
any
problems.
A
It's
this
await
call
that's
specifically
causing
the
hazard.
So
if
you
choose
to
use
a
weight,
the
best
way
to
think
about
it
is
that
your
function
is
split
into
multiple
pieces
at
each
weight.
You
know
if
you
have
one
or
weight
in
your
call.
It's
like
you
have
two
separate
functions.
The
part
before
the
part
after
and
the
second
piece
lives
in
this
totally
different
world
than
the
first.
A
It
gets
to
see
the
same
variables
you
know
can
close
over
stuff
from
from
earlier
in
the
function,
but
it
can't
rely
upon
any
of
the
invariants
any
of
the
status
checks.
Any
of
the
balance
checks
that
took
place
there.
It's
it's
a
little
bit
like
you
know,
you're
sleepy
you're,
you
you're
not
going
to
fall
asleep.
No,
no
you're
just
going
to
close
your
eyes
just
for
just
for
a
minute,
and
then
you
open
your
eyes
again
and
you
realize
that
you've
completely
fallen
asleep.
You
don't
know
what
time
it
is.
A
You
don't
know
what
you've
missed.
You
know
you
that
thing
you
put
over
there.
Maybe
it's
some
somebody
moved
it.
You've
got
you're
in
a
different
world.
So
so,
if
you
use
a
weight,
then
kind
of
every
time
that
you
come
back
from
the
weight
you
need
to
re-establish
whatever
conditions
you
thought
were
present,
because
you
were
not
in
control
the
entire
time.
If
you
don't
have
a
weight,
then
and
you're
only
using
eventual
send,
then
you
know
that
you
have
not
lost
control
at
any
point
during
that
function.
A
In
if
you
you
have
a
service,
the
service
receives
requests.
Whoever
designed
the
service
has
some
idea
about
what
requests
are
legitimate,
which
ones
are
attacks
or
somebody
trying
to
access
stuff
that
they're
not
supposed
to
so
in
access
control
in
general,
entirely
comes
down
to
should
this
request
be
honored
and
one
of
the
the
very
traditional
methods
of
doing
this
is
called
the
access
control
list
or
the
acl.
A
We
call
it
an
ackl,
and
this
is
usually
expressed
as
a
table.
You've
got
a
set
of
principles
which
are
are
parties
that
can
do
a
thing.
You
have
a
table
of
permissions,
which
are
things
that
could
be
done
and
at
the
intersection
at
every
cell
of
this
table,
there's
a
boolean
that
says
is:
is
x
allowed
to
do
y,
yes,
or
no
we're
not
really
big
fans
of
of
acls,
and
even
in
the
best
of
times
there
we
don't
like
them,
but
we
think
this
pattern
is
particularly
bad
for
smart
contract
systems.
A
The
columns
the
permissions
you
can
use
here
are
pretty
static
because
they
refer
to
a
fairly
small
number
of
fixed
kernel.
Apis,
it's
not
very
dynamic,
and
this
is
a
problem
in
smart
contract
systems,
because
we
want
to
keep
innovating
on
new
programs
and
new
features
that
are
there
and
we
want
these
features
to
be
usable
by
others
without
prior
arrangement.
We
don't
want
to
have
to
go
to
some
central
administrator
to
say:
hey,
I
built
a
new
thing.
Could
you
please
please
allow
people
to
use
it?
A
Acl
systems
also
tend
to
assume
that
the
principles
are
humans
based
on
where
they
came
from.
You
know
kind
of
unix
file
system,
sorts
of
things,
and
that
would
really
limit
composability,
because
in
our
ideal
system
a
program
should
be
able
to
do
anything
that
a
human
can
do.
Any
human
should
be
able
to
delegate
some
of
their
power
to
an
automated
agent.
That
will
do
it
for
them
in
acl
systems.
Delegation
generally
requires
fairly
special
action
by
the
administrator
you're
you're,
creating
a
new
principle
you're,
adding
something
to
this
table.
A
Delegation
is
super.
Easy
alice
can
give
carol
the
ability
to
access
file
x
by
just
sending
a
message
to
carol
and
including
that
filex
object.
As
an
argument
in
that
message,
it's
also
really
clear
that
alice
can't
give
carol
anything
that
she
didn't
already
have.
Access
to
alice
doesn't
have
access
to
file
y.
She
can't
give
it
to
carol
unless
somebody
else
gives
it
to
alice
first,
and
this
is
also
super
useful
for
reducing
authority.
So
sometimes
you
want
to
delegate
authority
to
a
smaller
portion
of
yourself.
A
Each
wrapper
that
we
write
reduces
the
scope
of
that
authority
and
it's
going
to
lead
to
safer
code.
So
imagine
that
you,
you
have
a
program
that
is
doing
some
sort
of
insurance
contract,
so
you've
got.
The
idea
is
that
every
day
a
weather
report
comes
in,
I
I'm
a
farmer.
I've
purchased
a
security,
an
insurance
contract,
that's
supposed
to
pay
out.
If
the
weather
report
indicates
freezing
temperatures
and
and
the
crops
get
killed.
A
This
this
analyze
weather
report
thing,
if
so
so.
The
rules
here
are
that
if
the
weather
report
indicates
this
particular
condition,
then
the
client
gets
a
payout
and
it
gets
a
particular
amount
and
it
only
ever
happens
once
once
per
season
once
per
per
insurance
contract.
Something
like
that.
So
this
code's
kind
of
you
know
straightforward.
This
is
how
you
would
imagine
doing
this
kind
of
thing.
A
There's
a
test,
there's
a
flag
to
say
whether
we've
done
this
once
or
not,
and
and
let's
imagine
that
this
analysis
section
is
large
and
complex-
it's
got
actuarial
tables.
It's
got
models
about
crop
failures,
all
sorts
of
business
logic.
If
you're
doing
it
right,
that's
should
be
like
90
of
your
program,
because
everything
else
is
just
you
know,
boilerplate
and
glue
logic.
A
So
you
send
this
to
your
engineers,
and
you
know
you
say,
make
this
better
and
of
course
the
first
thing
they
do
is
refactor
right.
What
comes,
naturally
is
to
move
that
complex
logic
out
into
a
separate
subroutine
that
has
minimal
inputs
and
minimal
outputs.
This
function
has
one
job:
it's
supposed
to
analyze
the
weather
report
and
return
a
boolean
that
says
whether
it
meets
these
payout
claims
or
not.
This
code
has
no
business
touching
any
money.
A
Then
you
make
a
second
function:
a
utility
function
to
make
sure
the
payout
can
only
happen
once
it's
going
to
have
a
flag.
It
has
the
same
kind
of
test
it
did
before.
This
is
the
one
that
takes
ownership
of
the
purse.
This
is
the
one
that
knows
what
the
claim
amount
is
supposed
to
be.
That
is
going
to
knows
who
the
client
is.
A
The
original
purse
is
a
fairly
large
authority.
If,
if
somebody
has
access
to
the
purse,
then
they
can
pay
out
as
much
as
they
want
to
as
many
parties
as
they
want
as
many
times
as
they
want.
If
you
give
them
this
thing,
instead,
this
payout,
once
this
object
with
the
payout
once
function,
method
on
it,
then
they're
limited
to
only
paying
a
particular
client
only
paying
a
particular
claim
amount,
and
only
ever
doing
it
once
so.
A
You've
just
taken
this
big
authority
and
reduced
it
down
to
the
minimal
one
that
this
particular
application
needs.
So
the
phrase
here
is
the
principle
of
least
authority.
The
idea
is
that
every
component
of
your
system
should
only
have
the
barest
minimum
of
power.
The
various
minimum
authority
that
it
needs
to
do
is
job
and
no
more,
and
so,
when
you've,
when
you've
built
those
two
utility
functions,
your
top
level
code
shrinks
down
to
this
kind
of
wiring.
A
This
is
this
is
just
wiring
things
up
and
if
you
present
this
to
an
auditor,
it's
really
obvious
what
it's
going
to
do.
You
know
there's
a
weather
report.
Every
time
it
comes
in
you
analyze
it
you
may
be
payout
done.
The
the
payout
may
pay
out
once
is
such
a
common
pattern.
That'll
live
in
a
well
audited
library,
so
you're,
probably
not
even
going
to
write
that
the
analyze
weather
thing
is
specialized
code
for
your
particular
application
and
that's
where
the
bulk
of
the
logic
is,
but
it
has
minimal
authority.
A
The
worst
it
can
do
is
lie
about
or
be
incorrect
about,
the
claim
payout.
It
does
not
have
the
ability
to
pay
out
things
multiple
times.
This
is
exactly
the
same
kind
of
pattern
that
our
offer
enforcement
layer,
our
offer
safety
layer,
uses
to
make
sure
that
a
contract
can't
do
the
wrong
thing
and
can't
cause
the
money
to
to
be
lost
entirely.
The
contracts
are
limited
to
choosing
the
the
layout
the
arrangement
of
the
assets
at
the
end.
A
The
fact
that
the
analyze
weather
function
wasn't
giving
any
purses
to
spend
from
means
it
can't
directly
spend
anything
okay,
so
everything
I've
shown
you
here
is
up
at
the
language
level,
they're
they're,
all
of
the
the
user
code,
you're
writing
all
of
the
contract
code.
You're
writing
gets
to
use
all
of
the
features
that
I've
just
described
to
you,
but
if
you're
familiar
with
ethereum,
if
you're
familiar
with
kind
of
lower
level
programming
in
these
these
traditional
blockchain
environments,
you
might
be
wondering
where
are
the
accounts?
A
Now,
behind
the
scenes
what's
really
happening
here
is
that
b
has
access
doesn't
have
access
to
the
object
on
on
the
per
the
purse
on
the
chain?
Obviously,
that's
a
different
computer
entirely,
but
it
has
access
to
the
special
proxy
that
we
call
a
presence
and,
when
b,
sends
a
message
to
this
proxy.
The
target
is
looked
up
in
a
table
called
the
c
list.
A
The
capability
list,
all
the
details
of
this
message,
are
going
to
be
serialized,
we're
going
to
keep
track
of
who
the
target
is
what
the
method
name
is
that
we're
sending?
What
are
the
arguments
and
it
gets
bundled
into
this
data
structure.
Now,
there's
nothing
in
this
data
structure
that
says
which
object
made.
A
A
So
the
the
proxies
enforce
the
access
control
to
make
sure
that
b
can't
access,
something
that
that
b
was
not
supposed
to
and
won't
let
the
messages
go
to
the
wrong
place
so
that
those
messages
are
bundled
up
with
any
other
messages
being
sent
to
the
same
machine
and
it's
serialized
into
a
bunch
of
bytes
and
those
bytes
now
need
to
be
sent
to
this
machine
in
an
approval
way
and
this
hands
it
off.
So
so
this
layer
was
called
cap
tp
the
capability
transport
protocol.
A
Once
we
have
these
bytes
we
hand
it
off
to
a
different
layer
called
that
tp
and
and
in
the
system.
These
are
different
vats
and
we're
sending
messages
from
one
vat
to
another.
So
this
layer
doesn't
know
what
the
bytes
mean.
It
just
knows
that
they
have
to
get
to
that
other
machine,
and
we
have
to
be
able
to
prove
to
that
other
machine
that
they
came
from
this
machine.
A
So
this
is
entirely
about
transport.
It's
about
provable
sourcing
of
these
things
and
the
way
that
this
works
depends
upon
the
kinds
of
machines
at
either
end
in.
In
this
example,
the
wallet
is
a
solo
machine.
It's
running
on
your
local
computer,
it's
running
on
just
one
one
cpu,
it's
not
a
consensus
mechanism,
there's
no
voting,
there's
no
blockchain
there,
but
it's
sending
to
a
blockchain
it's
sending
to
something
like
cosmos
sdk,
which
is
what
our
platform
is
based
upon.
A
When
a
solo
machine
sends
a
message
to
a
blockchain,
it
needs
to
be
delivered
as
a
signed
transaction.
It's
going
to
be
signed
by
a
key
that
is
held
by
the
wallet
machine
as
a
whole.
It's
not
any
individual
object
on
here.
It's
the
machine
talking
to
another
machine,
and
this
is
a
different
layer
of
abstraction
than
the
objects.
A
A
The
the
miners,
the
validators
on
the
chain,
will
receive
that
they'll
check
the
signature,
they'll
deliver
it
to
the
the
vatip
and
the
cap,
tp
layer
on
that
receiving
machine
and
they'll
say
this
came
from
a
machine
called
wallet
that
authorizes
it
to
use
this
c
list,
and
so,
when
the
wallet
machine
said,
I
want
to
send
a
message
to
object.
4
the
chain
side
machine
can
say:
oh
when,
when
the
wallet
machine
says
it
wants
to
talk
to
object,
four.
That
really
means
this
particular
purse
and
the
wallet
machine.
A
No
messages
from
the
wallet
machine
are
allowed
to
access
anything.
That's
not
inside
this
c
list.
So
so
this
is
now
enforcing
the
fact
that
the
machine
as
a
whole
can
talk
to
this
set
of
objects
and,
within
that
machine,
some
other
mechanism
decided
it
wanted
to
send
something
from
to
a
particular
object.
A
So
this
whole
mechanism
is
known
as
the
comms
layer,
and
this
is
completely
transparent
to
contract
code
contract
level
code
doesn't
have
a
way
to
specify
or
even
learn
what
these
object
ids
are.
This
is
entirely
a
way
of
bridging
two
different
machines
to
talk
to
each
other
and
to
allow
the
receiving
machine
to
figure
out
okay.
If
the
message
came
from
this
wallet,
it
used
this
c
list.
If
it
came
from
that
other
machine,
it
uses
this
different
c
list
that
gives
it
access
to
a
different
set
of
objects.
A
This
mechanism
is
not
specific
to
blockchains.
This
is
this
is
a
really
generic
mechanism
and
we
use
it
to
get
messages
from
any
any
swing
set
based
vm,
which
is
inside
any
kind
of
machine
to
any
other
one.
If
the
solo
machine
is
sending
a
message
into
a
chain,
it's
going
to
use
a
signed
transaction
like
I
just
showed.
A
If
one
chain
sends
a
message
to
another
chain,
it's
going
to
use
ibc
the
inner
blockchain
protocol
to
emit
a
message
that
one
chain
will
recognize
as
being
valid
as
being
sent
from
another
chain
when
a
chain
wants
to
send
a
message
down
to
a
solo
machine.
It's
going
to
emit
a
log
entry
that
a
light
client
on
the
solo
machine
can
read
and
verify,
and
it
can
tell
oh
yep
that
really
did
come
from
the
that
particular
machine.
A
I'm
willing
to
accept
it,
I'm
willing
to
let
it
use
things
from
the
c
list
and
then,
when
two
solo
machines
talk
to
each
other
because
they
can,
they
don't
have
to
have
a
consensus
mechanism.
They
can
just
use
regular.
You
know
tls
connections,
they
can
use
some
kind
of
encrypted
signed
transport
protocol
and-
and
so
all
four
of
these
mechanisms
appear
the
same
way
to
captive
captivity.
Just
says:
hey
vat
ap,
please
send
this
to
machine
x
and
that
tp
figures
out.
Oh
right,
you're,
a
solo
they're
a
chain.
A
I
need
to
do
this,
this
transaction
thing.
So
all
of
this
mechanism,
like
I
said,
is
transparent
to
the
upper
layers.
This
is
all
about
the
mechanics
of
how
systems
work,
but
it
means
that
all
of
your
contract
level
code
can
work
in
terms
of
objects,
can
in
terms
of
object,
references
and
it
doesn't
doesn't
need
to
in
most
cases,
doesn't
even
have
access
to
things
like
keys,
public
key
identifiers
contractors.
Things
like
that.
A
So
that
was
a
lot
of
material.
Sorry,
I
had
to
kind
of
rush
through
a
lot
of
it,
but
there's
a
lot
of
stuff
there,
but
the
summary
is
by
using
eventual
sends
you
can
avoid
reentrancy
attacks
by
taking
advantage
of
the
run
queue
and
by
using
object
capabilities
you
can
reduce
the
amount
of
authority
in
any
particular
object,
and
all
of
that
leads
to
a
safer
system.
So
thank
you
all
for
watching
and
I'm
really
looking
forward
to
seeing
everything
you
do
with
a
hackathon
thanks
brian.