►
Description
Hyperledger Member, Digital Asset will take you on a journey to learn about UTXO and Account models, what they are, how they work, and how we’re leveraging UTXOs with the smart contract language DAML to provide reliable, resilient, and cost-effective distributed applications. The first half of the talk will be a high level walkthrough of the UTXO and account-based models where anyone with an interest in blockchain-based applications can follow along. After that we’ll dive into some more of the technical considerations and how crucial of a design choice these two options are. You’ll walk away with a deeper understanding of design considerations, why you might want to use UTXOs, and how to choose between the two.
Link to view presentations slides: https://drive.google.com/file/d/1iYJ8k6QBp1l0KdQdOMp9h2R7VoIRBAxA/view?usp=sharing
New to DAML? https://discuss.daml.com/t/new-to-daml-check-these-links/1738
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #HyperledgerProjectWebinars #Blockchain
B
B
B
A
A
B
A
A
A
I'm
really
curious
actually
because
looking
for
at
names,
I'm
wondering
how
many
of
you
are
from
the
us
versus
europe,
because
we
always
thought
that
this
hour
is
best
for
for
people
from
the
us.
But
then
I
see
some
friends
from
from
europe.
So
if
you
want
to
pop
into
the
chat
or
speak
up
where
you're
yeah
so
fast,
nice.
A
A
If
the
slide
would
change,
as
with
many
of
you
who
are
familiar
in
our
community
at
hyperledger,
we
follow
an
antitrust
policy
and
have
an
anti-trust
policy
notice
that
you
can
look
at
on
our
website
or
you
can
take
a
look
at
the
qr
code
on
the
screen
that
you're
looking
at
right.
Now,
this
session
is
being
recorded.
It
will
be
available
on
our
website
on
the
webinar
page.
A
There's
a
couple
ways
you
can
do
that
you
can
raise
your
hand
via
the
emotion
signals
that
you
have
in
your
zoom
menu
bar.
You
can
also
come
off
mute
or
type
into
the
chat.
Any
questions
you
have
or
comments
you
want
to
make
will
be
monitoring
all
of
those
and
giving
you
that
opportunity
to
jump
in
when,
when
you
can
ask
any
questions,
don't
be
shy
and-
and
we're
here
to
this
is
a
learning
session.
A
A
We
do
have
a
regular
series
of
these,
so
our
next
couple
ones
are
the
next
one
is
with
consensus
on
march
17th,
and
then
we
have
the
valid
network
presenting
on
march
31st,
and
these
are
also
similar
format
very
engaging
here
for
you
to
learn
and
ask
questions
so,
if
you're
interested
in
either
one
of
those
topics
or
companies,
please
sign
up
for
those
as
well
and
of
course,
there's
many
different
ways
you
can
get
involved
in
hyperledger.
You
can
check
out
the
community
page.
A
A
B
A
B
A
B
So,
in
the
first
half
of
this,
we're
really
going
to
focus
on
general
designs
themselves
before
we
get
into
the
nitty-gritty
of
what
an
actual
utxo
or
account
model
implementation
looks
like
really
to
describe
even
a
single.
One
of
these
would
require
more
much
more
time
than
an
hour
to
really
understand
how
the
implementations
work.
Even
in
real
life,
there
are
a
lot
of
very
hybridy
models
or
other
things
going
on
that
don't
perfectly
fit
in
these
boxes,
so
there's
always
an
exception
to
everything.
B
So
really
what
I
want
to
talk
about
is
how
these
systems
generally
behave
by
default
and
with
the
least
complexity
in
their
designs
as
possible
least
complexity
helps
us
not
only
understand,
you
know
what
it
is
we're
talking
about
and
what
we're
looking
at,
but
also
the
least
complexity
possible
tends
to
have
the
least
bugs,
or
at
least
issues,
or
at
least
things
that
you,
as
somebody
designing
an
application
or
using
a
utx
or
account
based
network
need
to
really
worry
about.
So
that's
always
good
in
general
and
yeah.
B
A
B
Yeah,
okay,
those
are
actually
great
examples.
Yes,
so
santiago
is
correct.
Ut
excel
stands
for
unspent
transaction
output
and
that
and
a
series
of
those
outputs
could
represent
anyone's
balance
on
a
ledger
or
it
could
represent
a
variety
of
other
things.
Ken
is
also
correct
in
the
real
world.
Ut
excels
are
like
paper,
money
bills
and
ht
yeah.
That's
a
that's!
B
What
I
mean
by
accounts
of
this,
since
it
might
be
a
bit
confusing-
and
I
I
could
totally
see
that
is
an
account-
is
kind
of
like
this
kind
of
gives
away.
One
of
my
my
examples
later,
like
a
bank
account
where
you
may
receive
money
and
send
money
and
so
forth,
and
ultimately,
though,
all
that
money,
all
those
transactions
all
represent,
just
increasing
or
decreasing
the
value
on
your
account
balance,
for
example,
within
the
context
of
you,
know,
blockchain
and
distributed
ledgers.
B
These
things
are
a
bit
more
complicated
because
they
don't
only
hold
just
things
about
money,
but
things
about
all
sorts
of
parts
of
the
world,
and
so
that's
that's
the
general
just
to
them
where
utxos
are
like
a
consistent
ledger
of
debit
and
credits.
This
change
this
didn't
this
changed
here.
This
change
at
this
time
is
a
utxo
model
and
account
model.
B
A
B
This
little
bit
of
information
precludes
somebody
from
like.
If
I
were
to
send
santiago
a
transaction
on
ethereum,
I
wouldn't
want
him
to
send
that
same
transaction
again
and
that's
kind
of
how
you
prevent
double
spends
in
that
way.
If
I'm
understanding
the
question
correctly
so
yeah,
we
perfect,
so
we've
had
some
some
explanations
of
account
models
and
here's.
Some
of
my
ideas
on
real
life
models
and
really
all
of
these
models
are
very
ancient.
B
We
have,
on
the
ut
excel
side,
the
real
life
examples
being
cash
and
coin
money;
coin
money
in
particular,
being
one
of
the
earliest
examples
of
what
you
could
consider
a
utxo.
They
are
things
that
you
know
you
send
them
to
from
one
person
to
another.
If
you
were
to
split
one
in
half
and
and
give
the
two
pieces
to
two
different
people
other
than
them
coming
together
and
figuring
out
that
that
was
from
the
same
half
of
the
coin,
that's
pretty
much
it
there's!
No
other
tie
between
them.
B
So
if
one
of
those
heads
got
given
to
another
person,
that
person
would
have
no
link
between
that
half
of
the
coin
and
another
one,
for
example,
and
on
the
account
side,
you
know
we
have
banks
like
has
been
mentioned,
and
we
have
credit
cards
which
do
the
same
type
of
thing.
They
keep
track
back
up
a
list
of
debits
and
then
every
month
you
settle
up,
and
then
we
even
have
we
have
very
old
examples.
B
B
But
one
interesting
example
are
these
bullet
tokens
that
essentially
are
an
account
and
also
are
somewhat
of
a
utxo
they're
really
interesting
in
that
the
outside
of
them
demonstrates
what
is
owed
and
the
inside
of
them
is
the
identical
of
what
is
what
has
been
received
and
kind
of
that
happens
by
they
basically
press
all
these
little
bones
that
represent
different
things
into
the
tokens
or
these
different
stones,
and
then
they
seal
the
stones
inside
this
ball.
That
has
those
impressions
on
it.
B
So
when
you
want
to
go
and
redeem
your
debts,
you
can
actually
have
somebody
will
break
it
open
and
see
that
nothing
had
been
changed.
It's
really
interesting
because
you
could
pick
it
up
and
take
it
around
with
you
and
then
go
back
later
to
whoever
owed
you
something
or
whoever
it
would
you
and
redeem
them
that
way,
and
those
are
a
whole
bunch
of
different
real
life.
Examples
of
utx
on
account
models.
B
So
now-
and
I
really
haven't
actually
thought
this
question
through
much
so
I
would
love
it
if
people
had
some
ideas
but
for
these
models
in
the
real
world
kind
of
between
utxos
and
accounts.
What
are
some
of
the
good
things
about
them,
and
maybe
what
are
some
of
the
bad
things
about
them
like?
What
are
the
trade-offs
from
choosing
these.
B
B
Yeah
santiago
actually
has
a
really
good
point
there.
Data
storage
is
definitely
within
blockchains
themselves,
a
a
consideration
when
you're
going
through
between
utxos
and
accounts
that
will
actually
get
into
in
a
little
bit
and
that's
basically
an
answer
to
another
question
that
I
have,
but
in
the
real
world
like
what
are
the
examples
of
having
dollars
or
coins
versus
having
you
know,
bank
accounts
or
credit.
B
Yeah
that
that's
definitely
a
negative
of
ut
excels
there
that
that
they
could
require
a
lot
of
aggregations.
You
kind
of
have
change
to
deal
with
also,
like
you
just
mentioned,
in
the
chat
and
yeah
on
the
account
side.
One
of
the
the
negatives
is
that
you
have
to
have
a
nonce
and
manage
it
and
we'll
actually
see
that
that
nonce
has
some
other
negatives
too.
A
little
bit
later
in
this
alfred
also
has
a
really
good
point.
B
That
privacy
is
I'm
assuming
you're
talking
about
utxo's
privacy
is
a
bit
better
in
utxos.
That's
also
something
we're
going
to
talk
about.
So
that's
really
awesome
and
yeah.
Santiago
also
brings
up
that
utxos
one
of
the
advantages
they
have
and
it
kind
of
ties
into
what
fergal
said
is
that
they're
divisible,
and
so
they
have
a
really
nice
property
where
they
get
divided
and
split
around
where
and
accounts
have
a
really
nice
property
where
they
have.
B
You
get
basically
a
real
time
update
to
to
an
account
and
you
get
to
see
the
balance
for
the
account
without
having
to
compute
it
out
all
yourself
in
blockchains,
obviously,
in
both
of
them.
These
are
abstractions
on
top
of
how
these
things
actually
work
under
the
hood,
so
in
both
you
actually
do
have
to
do
all
that
computation.
B
But
when
you're
reasoning
about
these
things,
actually,
as
a
user
of
them,
then
these
that's
when
these
things
come
into
play
and
are
very
interesting
and
yeah.
Andre
also
says
that
you
know
you
get
bigger
control
of
funds
with
utxos,
which
is
true.
You
get
to
pick
which
of
your
bills
or
coins
you're.
Actually,
spending
and
yeah
alfred
also
has
a
really
great
point
there
that
you
know
smart
contracts.
B
B
B
In
all
cases,
they
kind
of
translate
to
the
blockchain
digitized
versions
pretty
well
in
that
they
are
at
least
90
by
whatever
loose
qualitative
metric,
I'm
using
there
are
very
equivalent,
and
so
I
spent
a
while
thinking
about
this-
and
you
know:
we've
we've
kind
of
gone
over
that.
So,
let's
go
on
to
the
and
on
the
technical
side
too.
I
think
that
people
have
really
dived
into
that.
In
that
you
know
they're.
These
are
the
same
types
of
things.
B
B
So,
like
I
said
before,
if
you
have
two
different
utxos
and
you
spend
one
here
and
one
in
another
place,
those
two
utxos
could
be
on
completely
different
networks,
because
it
doesn't
matter
to
the
person
receiving
them
what
their
relation
are
to
each
other.
All
each
utxo
has
a
history
both
behind
it
and
eventually
in
front
of
it,
and
that
history
is
completely
isolated
from
any
adjacent
history
of
other
utxos,
even
if
they're
coming
from
the
same
person
from
the
same
person
with
the
same
account
and
wow.
These
are.
B
A
B
Yeah,
of
course,
yes,
there
are
positives
and
negatives
to
both
like
you
mentioned
karen,
so
we
could
talk
about
the
bad
side.
We've
talked
a
lot
about
the
positive
side.
Maybe
we'll
touch
on
some
of
the
other
positives,
that
there
are
other
things
to
mention
there,
and
so
one
of
the
bads
of
your
utxo
model,
when
you're
using
them
in
a
blockchain
distributed
ledger
setting
is
that
you
always
have
to
worry
about
contention
and
manage
it.
B
B
Are
the
valid
one
that
should
be
included
as
part
of
the
history
and
which
one
should
be
rejected
because
it's
been
spent
already,
and
you
can
imagine
that
different
participants
on
the
network
might
see
these
transactions
at
different
at
slightly
different
times?
It
might
see
one
first
in
one
case
and
the
other
first
in
another
case,
and
then
you
would
have
you
know
essentially
two
different
nodes
that
disagree
about
which
transaction
is
valid
and
which
one
is
an
attempt
at
a
double
spend
that
should
be
thrown
out.
B
So
I
won't
go
into
all
the
ways
that
gets
handled
it
does
get
handled,
but
it
is
something
that,
when
you're
programming
applications
and
when
you're
reasoning
about
them,
you
do
have
to
consider.
How
is
my
network
going
to
handle
this,
and
when
I
do
encounter
this,
what
do
I
do?
Do
I
have
to
tell
the
other
party
that
this
utxo
has
been
spent
already?
Do
I
have
to
wait
a
while
in
order
to
see
if
this
one
is
valid?
B
There
are
a
variety
of
ways
to
to
deal
with
it,
but
it
is
something
to
consider
another
bad
about.
The
utxo
model
is
that
it
requires
really
learning
a
new
way
to
reason
about
and
structure
your
programs,
so
we've
become
very
used
to
and
accustomed
to
within,
a
lot
of
programming
paradigms
of
always
having
access
to
state.
B
It
particularly
requires
lots
of
new
reasoning
about
how
your
programs
get
structured
and
I'll
actually
show
that
in
an
example
later-
and
as
mentioned
before,
you
know,
you
often
do
get
larger
transaction
sizes.
This
isn't
always
true.
There
are
ways
to
navigate
around
it,
but
in
the
very
basic
general
sense,
as
we're
trying
to
stick
to
with
these
models.
That
is
a
concern
on
the
account
model
side.
Some
of
the
bads
are
that
they're
less
amenable
to
staping.
B
So
someone
had
mentioned
that
earlier,
where
in
utxos
once
you've
used
one,
you
can
mostly
forget
about
it.
Unless
you're
a
new
member
to
the
network,
then
you
need
all
the
old
history,
but
if
you've
been
on
the
network
for
a
while,
you
actually
don't
need
that
history
anymore.
You
figured
out
what
the
current
state
is,
but
with
accounts
they
all
depend
on
each
other
in
a
much
more
intertwined
way.
They
all
modify
each
other
a
lot
more.
B
B
You
can
only
use
that
once
and
it
only
depends
on
the
state
of
itself.
Basically,
it
is
all
of
the
state
that
you're
concerned
about,
but
when
you
do
this
in
the
account
model,
it
could
affect
the
state
of
anything
else
on
the
network
as
long
as
it's
a
current
piece
of
state
on
the
network,
so
we'll
actually
see
that
too.
In
that
how
that
can
create
some
opportunities
for
bugs.
B
You
also
have
reordering
bugs
like
we
touched
on
and
that
you
would
use
a
nonce
to
try
to
alleviate
they're
a
bit
less
private,
because
when
you
take
your
account
or,
for
example,
your
debit
card
and
you
use
it
in
the
real
world,
one
nice
thing
is
that
the
bank
knows
all
of
your
states
everywhere.
You've
spent
money,
but
the
rest
of
the
world
doesn't
within
accounts.
B
B
You
even
see
this
on
bitcoin
a
lot
where
people
reuse
the
same
addresses,
but
the
utxo
model
in
that
case
is
trying
to
encourage
you
not
to
do
that,
but
in
general
that
makes
these
things
less
private,
because
people
can
go
on
and
actually
see
these
transactions
and
then
in
the
private
space.
You
do
have
a
variety
of
other
methods.
B
You
know
such
as
channels
and
I
think
other
things
called
channels
that
actually
help
to
keep
this
privacy.
But
again
we
we're
trying
to
think
about
account
models
in
a
very
general
sense,
so
in
general,
they're,
less
private,
but
there
are
ways
to
work
around
it.
As
with
most
of
these
negatives
and
sorry
did
somebody
have
a
question.
B
B
Then
you
can
only
have
single
threaded
operations,
so,
if
you're
send,
if
I'm
doing
a
transaction
you're
doing
a
transaction
and
yours
goes
and
happens
first,
then
my
transaction
cannot
happen
until
your
transaction
has
resolved.
Basically,
there's
a
whole
lot
on
all
the
state
out
there,
even
if
our
two
transactions
don't
interact.
A
B
B
B
B
Oh
I'm
sorry,
santiago
said
that
the
non's
history,
I
believe
you
may
be
meant
to
say,
can't
be
traced
in
utxos,
so
yeah
in
ut
exo's,
there's
no
nonsense.
Yeah,
okay,
but
in
account
models
there
are
nonces,
and
what
we'll
see
is
that
that
kind
of
enables
a
certain
bad
behavior
that
I'll
talk
about
on
the
next
slide,
so
that
that's
great,
I'm
really
happy
that
you
got
everybody
can
see
all
of
this
from
the
model
and
and
really
are
grasping
it,
because
that
that's
awesome.
B
B
B
Two
and
three,
both
of
these
by
the
way,
are
very
over
simplifications
of
the
actual
implementations
and
how
they
would
work,
but
just
for
the
purposes
of
demonstration
and
then
from
there
you
can.
You
can
get
a
graph
of
where
this
transaction
has
gone
and
it's
gone
to
carol's
account,
and
what
you
can
see
here
too,
is
that
this
transaction
here
goes
back
to
you,
or
rather
it
really
and
thus
goes
back
to
your
account.
So
you
get
a
bit
more
of
a
transaction
history.
A
B
B
A
B
Yeah,
that's
a
great
question
and
it
actually
leads
me
into
my
next
slide,
which
is
a
problem
that
susan
and
santiago-
and
I
believe
a
couple
other
people
have
been
touching
on-
is
that
this
leads
to
essentially
what
we
could
call
side
channel
attacks,
which
is
a
very
general
form
of
attack.
So
we
could
say
the
following
happens
with
the
model
we
just
looked
at
number
one
carol
and
bob
are
competitors
in
the
space
you
work
in
they're,
aware
of
each
other,
and
they
compete
with
each
other
number.
B
You
intentionally
haven't
told
bob
that
you're
working
with
carol.
You
also
happen
to
be
working
with
bob
and
bob
has
actually
been
working
with
carol
on
another
project,
and
bob
in
particular,
is
a
less
than
moral
person
and
is
really
willing
to
bend
the
rules
of
your
network
to
see
what
data
he
can
pull
out
to
get
more
quote-unquote
competitive
intelligence
on
your
operations,
and
so
what
we
can
now
do
is-
and
this
has
already
been
touched
on
so
I'll
just
start
stepping
through
it
is.
B
B
What
you're
going
to
actually
encounter
are
thousands
upon
thousands
of
transactions
between
the
same
parties
over
and
over
again,
and
so,
if
bob
can
figure
this
out
with
one
bit
of
data,
imagine
the
types
of
things
that
bob
could
figure
out
with
a
variety
of
data.
You
can.
You
can
just
start
figuring
out
more
and
more
things
about
the
network
that
you
weren't
supposed
to
know
and
so
hd's
asking.
Will
you
share
info
on
how
he
can
implement
this
in
hyperlodger
fabric?
B
I
mean
utxo
and
account
model
yes,
so
fabric
in
and
of
itself
uses
an
account
model
and
they
also
use
something
called
channels
which
actually
mitigate
a
lot
of
these
concerns.
As
as
I
said,
this
is
an
example
and
then
the
other
way,
if
you
wanted
to
try
your
hands
at
actually
using
utxos,
you
can
try
out
demo,
which
runs
on
top
of
fabric
and
that
you
can
go
to
the
link
that
I
have
in
the
bottom
left
at
bit.lee.
B
Slash,
try
demo,
I
recommend
everybody,
you
know
just
go
there
and
check
it
out.
It
runs
on
fabric
networks,
it
doesn't
interact
with
existing
contracts,
but
it
is
a
very
interesting
way
to
program
on
fabric
networks
and
gives
you
a
lot
of
very
nice
things
for
free,
and
we
even
have
you
know
interoperability,
layers
and
all
sorts
of
other
things.
We're
working
on
where
disparate
networks,
like
a
fabric
network
and
a
sawtooth
network,
will
eventually
be
able
to
talk
to
each
other
and
have
very
interesting
bigger
networks.
B
You
know
as
the
space
expands
and
that's
basically
my
pitch
on
demo,
but
yeah
try
it
out.
So
what
we
can
do
is
step
through
this
problem,
so
we're
going
to
say
that
bob
goes
home
studies,
your
ledger
and
figures
out
some
some
things
about
it.
We're
also
gonna
have
two
parallel
universes
we're
gonna,
have
the
utxo
on
account
universes
and
we're
going
to
also
have
one
thing.
B
That
bob
knows
is
that,
in
order
for
any
project
to
start
with
your
workflow
for
your
business,
there
has
to
be
a
transaction
from
you
to
bond
and
there
has
to
be
another
related
transaction
from
bob
to
you.
That
happened
around
the
same
time,
and
so
what
we're
gonna
first
do
is
we're
going
to
restrict
this
model
to
the
things
that
bob
only
knows
about
and
remove
the
other
other
parts
of
the
network.
So
all
these
things
in
purple
are
going
away
because
bob
can't
actually
see
these
in
any
real
life
functioning
network.
Hopefully.
B
Sure
so
what
bob
decides?
What
bob
does
is?
He
starts
another
project
with
you
and
he
goes
and
gets
a
transaction
from
you
to
him,
and
then
he
starts
another
project
with
carol
and
goes
and
gets
a
transaction
from
carroll
to
him
and
bob
figures
hey.
If
I
could
tie
these
two
bits
of
data
together,
I
can
know
maybe,
if
carol
has
been
working
with
you,
because
maybe
these
utxos
are
related
and
if
they
are
in
any
sort
of
way
there
might
be
some
data
between
them,
which
would
reveal
this
other
transaction.
B
That
may
have
happened.
Would
it
reveal
necessarily
the
data
about
it,
but
just
the
fact
that
it
probably
exists
to
some
some
degree
of
certainty,
but
bob
quickly
finds
out
that
these
two
utxos
have
no
relation
to
each
other,
and
this
is
something
that
people
touched
on
before.
In
the
account
model,
we
can
go
and
do
the
same
thing.
B
Bob
says:
oh
look
at
this:
let's
transaction
from
you
to
me
was
transaction
two
and
now
the
transaction
from
you
to
me
is
transaction
four
where's
transaction
three,
and
this
is
even
more
interesting.
You
know
on
the
capital
side:
oh
carol's,
last
transaction
to
me
was
number
88,
and
now
it's
number
90.
where's
89
from
there
bob
can
deduce
that
carol
has
very
possibly
but
not
certainly
had
some
sort
of
business
interaction
with
you
and
you
know.
A
B
Okay,
so
here
we're
going
to
get
more
specific
and
we're
going
to
look
at
an
actual
network
and
we're
going
to
look
at
ethereum
first
and
then
we'll
look
at
it
in
demo.
Just
so,
we
can
compare
networks
that
both
do
sm,
not
really
a
network,
but
we
could
compare
smart
contracts
written
within
both
types
of
these
models.
B
What
we
did
is
we
made
sure
that
bob
wouldn't
be
able
to
see
the
parts
of
the
transaction
graph
in
both
accounts
and
utxo
models
that
bob
wasn't
supposed
to
see.
So
that's
why,
when
you're
just
the
person,
if
on
like
a
public
network,
yes,
you
can
see
the
full
transaction
graph,
no
matter
who
you
are,
but
on
more
private
networks,
you
generally
can't,
and
that
would
be
just
a
very
basic
part
of
the
implementation.
B
For
most
cases,
though
not
all,
and
so
that's
what
we're
doing
here,
we're
giving
both
of
these
models
their
best
shot
at
staying
private
before
we
are
able
to
figure
out
other
things
about
them,
and
so
I
hope
that
answers
your
question.
But
now
we'll
look
at
the
theorem
specifically,
and
so
you
can
take
a
moment
to
look
at
this
slide
and
if
you
have
any
questions,
feel
free
to
ask.
We
actually
already
are
fairly
close
to
the
end
of
the
hour,
and
I
really
do
want
to
get
through
to
all
of
this.
B
So
todd
asks
a
very
good
question.
How
does
bob
know
there's
a
missing
transaction?
The
answer
is
bob,
doesn't
truly,
the
answer
is
bob
knows
there
are
missing
transactions.
Bob
doesn't
truly
know
whether
they
involve
you
and
carol,
for
example,
in
this,
in
this
example,
but
bob
can
take
an
educated
guess.
So
what
you
can
see
over
here
is
bob
had
a
previous
transaction
too,
with
you
and
a
transaction
88
with
carol,
and
what
happened
is
bob?
B
B
B
So
we
can
go
ahead
and
increase
my
beerus
ode
by
alice
to
one
plus
one
we're
going
to
go
ahead
and
call
vr
accepted
again
such
that
we
both
know
that
this
has
happened,
and
then
your
proposals
for
alice
are
also
going
to
be
decremented
by
one,
and
this
beer's
oat
state
here
is
going
to
change
from
a
zero
to
a
one.
This
is
going
to
change
down
to
zero
and
so
on,
yeah.
So.
B
B
And
the
overarching
point
here
is
that
the
specific
bug
we're
going
to
look
at,
which
is
called
a
reentrancy
attack,
can
occur
because
you
have
to
think
very
carefully
about
each
and
every
possibility
in
each
and
every
line
of
code
and
how
it
affects
this.
The
underlying
state-
and
this
can
actually
be
a
pitfall
that
affects
even
very
seasoned
programmers,
sometimes
because
you
can
end
up
with
a
bug.
B
That's
very
non-obvious,
and
very
interestingly
here
too
bob
because
bob
needs
to
be
able
to
mad,
because
bob
is
also
you
could
actually
ignore
this.
This
is
actually
an
error
on
my
slide.
Bob
doesn't
necessarily
need
to
know
about
beerus
elements,
so
we
can
ignore
that
rob
asked
for
multiple
current
transactions,
which
model
should
we
choose
which
can
have
high
throughput.
Both
of
these
models
can
have
high
throughput.
B
I
would
say,
though,
that,
when,
in
terms
to
concurrent
transactions,
like
you
specified,
utxos
tend
to
have
much
higher
throughput,
because
you
don't
need
to
worry
about
accounts
interacting
with
multiple
accounts.
At
the
same
time
like
like,
you
would
in
an
account
model
and
you
a
utxo
model,
you
don't
have
to
really
worry
too
much
about
utxos,
interacting
with
other
unknown
parts
of
the
history
as
as
much
so
in
general,
utxos.
B
B
Is
you
get
these
kinds
of
multiple
concurrent
transactions,
essentially
where
a
lot
of
these
accept
fears
are
happening
before
the
proposal
has
been
decremented
and,
as
you
can
see
earlier,
we
had
a
check
on
these
beer
proposals
to
make
sure
that
they
were
larger
than
zero,
but
we
can
actually
push
through
transactions
where
many
of
those
transactions
go
through
before
this
check
ever
happens,
and
so
what
happens?
There
is
bob
essentially
manipulates
the
state
to
make
alice.
B
Oh
bob,
ten
beers,
instead
of
just
the
one
alice,
had
intended,
and
then
that
is
kind
of
avoided
in
a
utxo
model
where
you
don't
have
have
this
pi
and
this
this
constant
state
that
you're
keeping
track
between
the
two
models
once
a
utxo
is
used.
It's
it's
gonna
done
and
gone,
and
so
there
you
see
here
that
one
of
these
goes
through
and
alice.
B
Stills,
oh
still
owes
bob
the
beer,
but
all
the
other
attempts
that
that
bob
tried
in
replaying
that
veteran
in
re
and
re-entering
that
transaction
ended
up,
failing
and
so
yeah,
that's,
basically
the
presentation
and
how
they
differ
in
practice.
As
always,
you
know
go
check
out
demo
if
you're
interested
in
learning
a
bit
more
about
the
utxo
model
at
bitly,
slash,
tridemo
and
yeah.
B
If
you
have
any
other
questions,
you
can
always
ask
on
our
forum
and
I'd
be
more
than
happy
to
answer
that
link
actually
in
the
bottom
left-hand
corner
will
take
you
to
the
forum
and
yeah.
Thank
you
very
much
to
karen
and
martha
for
having
me
and
for
making
this
a
really
and
thank
you
to
everybody
who
asked
all
these
wonderful
questions.
You
made
this
a
really
great
session
and
I'm
actually
really
happy
with
how
well
it
went
so.
Thank
you
all.
A
A
A
We
have
this
whole
chat,
channel
messaging
service
that
you
can
engage
directly
with
those
that
are
working
on
these
projects
and
find
question
friend
answers
to
your
questions
there
and
then.
Finally,
thank
you
so
much
for
joining
us
and
if
you
did
have
any
burning
questions
that
you
still
are
lingering
feel
free
to
email
us
at
membership,
hyperledger.org
and
we'll
make
sure
anthony
gets
them
have
a
wonderful
day.
Thank
you.
Everybody.