►
From YouTube: Firefly Architecture Series Episode 2: Tokens and Trades
Description
This is the second video of a six-video series about FireFly.
Learn more about the proposed architecture for tokens and trades on FireFly, including how to represent fungible and non-fungible tokens in FireFly, how token plugins and smart contracts can connect to the FireFly core, and how the on-chain and off-chain parts of a transaction can be coordinated.
What is FireFly?
FireFly is a Hyperledger Lab that provides a multi-party system for enterprise data flows, powered by blockchain. It solves the layers of complexity that sit between the low-level blockchain and high-level business processes and user interfaces. FireFly enables developers to build blockchain apps for enterprises radically faster by allowing them to focus on business logic instead of infrastructure.
Learn more about FireFly at Hyperledger Labs: https://wiki.hyperledger.org/display/labs/Firefly
----
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
A
Welcome
everybody
welcome
to
our
second
firefly
community
call
for
these
first
several
calls
we're
going
through
a
some
sort
of
technical
topic
in
each
call.
Today's
theme
is
tokens
and
I'll,
introduce
andrew
here
in
a
second
and
we'll
split
up
the
time
between
a
technical
topic
presented
by
one
of
the
project,
maintainers
and
also
a
time
of
open
discussion
and
or
q
a
so.
A
Today's
topic,
like
I
said,
is
tokens
and
andrew
richardson
will
be
presenting
on
that,
and
this
is
a
proposed
plan
for
how
tokens
will
work
in
firefly.
Andrew
will
take
us
through
that.
I
I
don't
think
so.
Last
time
we
split
the
call
50
50
between
you
know
30
minutes
of
presentation,
30
minutes
of
discussion.
A
I
don't
know
that
we'll
need
that
full
time
for
the
presentation,
but
if
you
can,
please
hold
questions
until
after
andrew
is
done,
and
then
I
will
open
it
up
for
discussion
either
on
the
tokens
topic
or
on
anything
that
folks
would
like
to
discuss
about
firefly.
This
is
a
public
call.
Anyone
is
welcome
to
join,
it
is
recorded
and
the
recording
will
be
posted
online.
B
All
right,
thank
you
nico
for
that
introduction.
As
he
said,
we
are
talking
a
little
bit
about
tokens
and
trades,
and
this
is
a
little
bit
unlike
the
last
architecture
series
which
was
more
of
a
presentation
of
how
the
current
firefly
code
works.
This
is
definitely
a
presentation
about
how
we
would
like
it
to
work.
B
B
B
Where
one
piece
happens
before
the
other
piece
right,
either
the
on-chain
token
gets
sent
first
or
the
off
chain.
Data
gets
sent
first,
and
you
can
choose
to
do
it
in
either
order
to
kind
of
give
some
protection
to
one
party.
But
it's
never
going
to
be
totally
atomic.
The
way
an
on-chain
transaction
would
be,
and
this
can
kind
of
spawn
a
whole
discussion
in
itself.
So
I
don't
want
to
get
too
deep
into
it
now,
but
happy
to
circle
back
on
it.
B
What
party
b
did
and
you
can
fall
back
to
having
third
parties
get
involved
if
you
need
to
sort
things
out
after
the
fact,
and
that's
often
good
enough
for
an
enterprise
flow.
So
this
is
actually
something
we
do
want
to
support
on
the
right
as
well,
and
I'm
going
to
talk
a
little
bit
about
how
we
support
both
of
these
or
how.
B
We
would
see
these
fitting
into
the
architecture
of
firefly,
but
just
wanted
to
kind
of
intro
that
there
are
two
distinct
buckets
and
we
want
to
make
sure
we
support
both
so
diving
into
what
we
would
see
this
looking
like
in
firefly.
Each
of
these
boxes,
with
a
bold
title,
is
a
logical
construct
in
firefly.
You
know
that
would
be
part
of
the
database
and
part
of
the
sort
of
logical
data
model.
B
The
main
item
is
a
token
pool
on
a
token
pool
again
we're
trying
to
keep
everything
agnostic
to
the
blockchain
and
to
the
underlying
contract.
On
that
blockchain.
I've
shown
that
this
could
be
mapped
in
the
case
of
ethereum,
which
is
sort
of
our
first
proof
of
concept
that
we've
been
working
on.
It
could
be
mapped
to
an
erc
1155,
which
is
sort
of
you
know
the
next
generation
token
contract
construct
that
it
allows
fungible
and
non-fungible
and
different
combinations.
It.
B
B
In
these
token
exchanges
is
going
to
be
mapped
to
a
token
account
they're
poor
per
pool,
so
a
pool
may
have
token
accounts
for
all
the
different
parties
that
may
be
involved
in
transactions.
On
that
pool.
A
token
account
is
mapped
directly
to
an
on-chain
identity,
which
is
again
the
exact
format
of
that
is
going
to
depend
on
which
chain
you're
using
it
may
be
an
ethereum
address,
or
some
other
identifier,
I'm
going
to
have
some
sort
of
roles
right.
Some
people
may
be
allowed
to
mint.
B
You'll
either
have
each
account
contain
a
balance
just
telling
how
many
of
the
fungible
tokens
they
have
out
of
this
pool
in
their
ownership
or
a
sort
of
mapping
of
if
it's
a
non-fungible
asset
class
which
of
the
non-fungible
tokens
are
currently
owned
by
this
account
now
apis
associated
with
this,
you
would
have
a
post
to
create
a
new
token
pool.
You
would
have
gets
to
list
the
token
pool
and
the
tokens
within
a
pool
and
gets
also
to
get
the
accounts
tied
to
a
particular
pool.
B
Then,
moving
on
and
building
kind
of
on
this,
the
the
simplest
thing
you
can
do
is
a
simple
one-way
transfer,
just
transfer
a
balance
of
one
token,
from
one
token
account
to
a
different
token
account,
and
of
course
this
is
going
to
result
in
some
things
at
the
firefly
layer.
Some
of
our
you
know,
database
constructs,
but
it's
also
going
to
be
directly
mapped
to
on-chain
transactions.
B
So
we
have
the
notion
of
a
token
transfer
that
is
going
to
contain
a
reference
to
a
from
account
a
reference
strip,
two
account,
depending
on
whether
you
are
transferring
a
amount
of
fungible
tokens.
There
may
be
an
amount
or
if
it's
non-functional
tokens,
maybe
a
listing
of
which
tokens
within
that
pool.
You
are
transferring
and
then
like
with
many
things
in
the
firefly
architecture.
There's
a
sort
of
free-form
data
item
here,
and
I
put
a
note
at
the
bottom
of
the
page
here.
B
The
data
is
opaque
to
firefly
core,
and
this
is
a
common
thread
that
we've
built
into
a
lot
of
what
we're
proposing
in
firefly
and
basically
saying
the
application
can
decide
what
goes
there.
One
suggestion
would
be
that
if
this
transfer
is
in
exchange
for
some
off-chain
data
right-
like
I
mentioned
this
bucket-
where
you
may
be
transferring
tokens
in
order
to
receive
some
off-chain
data,
maybe
this
is
a
reference
to
that
data
right.
B
It
could
be
a
reference
to
the
data
id
within
firefly
or
some
other
identifier,
but
it's
basically
up
to
the
application
to
decide
how
that
data
is
used
and
referenced.
And
then
you
have
a
token
plug-in
in
firefly,
similar
to
the
other
plugins
that
we
talked
about
last
week,
the
base
blockchain
plug-in
and
some
others.
You
have
a
token
plug-in.
That's
going
to
be
specific
to
the
contract
being
used.
B
You
know
so
maybe
there's
a
plug-in
that
talks
to
an
ethereum
erc
1155
contract
and
it
knows
how
to
create
token
pools
within
that
contract
and
knows
how
to
do
transfers
within
that
contract
and
the
token
plug-in
is
also
going
to
decide
what
happens
to
that
data.
That's
attached
to
the
transfer
again,
erc
1155
is
a
really
nice
fit
for
this,
because
it
kind
of
already
has
a
built-in
data
item
that
you
can
pin.
B
The
on
chain
for
off
chain
flow,
which
we
would
argue,
is
a
very
valuable
and
common
thing
for
enterprises
to
want
to
need
on
the
left
is
kind
of
a
sample
json
blob
again,
this
is
a
proposal,
and
this
is
not
a
thing
that
exists
in
firefly
yet,
so
this
is
more
of
a
sketch
rather
than
a
actual
spec,
but
you,
you
start
number
one
as
saying
that
they
want
to
send
a
payment
for
some
sort
of
data
off
chain.
They
make
a
post
to
this
transfer
api.
B
It's
some
thing
that
says
this
transfer
is
in
relation
to
this
piece
of
data
and
I'm
expecting
to
receive
this
piece
of
data
in
return
for
these
tokens
that
goes
through
the
blockchain
contract.
It
actually
does
the
transfer
so
that
these
are
transferred
from
the
identity
from
river
1
to
the
identity
for
member
2,
and
then
the
firefly
node
on
the
far
side
gets
the
event
and
then
member
2
would
be
expected
to
respond
with
a
private
message.
B
All
the
constructs
we
talked
about
last
time
in
the
first
architecture
series,
if
you
missed
all
that
peter
did
a
great
job
going
into
a
lot
of
detail
about
what
public
and
private
messages
look
like
in
firefly.
So
this
is
just
coming
back.
Sending
the
private
message
pinning
the
proof
on
chain
to
say
that
this
transfer
was
fulfilled
and
then
delivering
the
private
data
off
chain,
and
then
member
one
can
then
retrieve
that
data.
B
I
included
a
slide
here,
that's
more
of
a
prerequisite
again
just
kind
of
referencing
back
to
last
week.
Assuming
that
number
one
is
requesting
a
piece
of
data
you
would
have
had
to
advertise
that
the
data
was
there,
I'm
not
going
to
dive
too
much
into
this.
We
can
definitely
come
back
to
talk
about
it
again
later,
but
this
is
kind
of
the
prerequisite,
assuming
remember
to
put
some
data
into
the
system
they
advertise
to
number
one.
That
data
was
available.
B
Now,
a
trade
is
something
that's
very
plug
independent
in
this
case,
because
we
didn't
want
to
box
it
in
too
much
and
say
that
firefly,
you
know
is
built
on
hashtag,
lock,
contract
or
any
other
specific
blockchain
or
protocol
or
system.
It's
really
just
saying
that
a
trade
is
a
thing
that
happens
between
two
parties
has
a
number
of
steps,
and
it's
gonna
ultimately
result
in
some
transfer
of
tokens
right.
So
it's
a
very,
very
generic
construct,
as
we've
laid
it
out
here.
B
You
can
see
that
all
I've
put
in
the
trade
object
itself
is
a
generated
id
a
status
to
say
you
know,
is
it
initiated?
Is
it
in
progress?
Is
it
completed
and
then
this
opaque
data
blob,
so
the
trade
plug-in
could
put
lots
of
different
things
in
that
data
block
if
it
is
an
htlc
they're
going
to
put
a
secret
and
a
secret
hash,
you
know
and
those
will
get
shared
at
different
points
of
the
transaction,
so
one
member
may
have
the
secret
at
one
point.
B
They
may
not
have
it
immediately
on
the
other
side,
but
as
the
trade
moves
along,
you
know,
through
these
kind
of
well-defined
protocols,
this
data
block
will
be
built
up
with
the
data
about
the
trade
and
then
the
trade
steps
again,
not
a
lot
here.
They
have
a
link,
there's
going
to
be
a
many-to-one
relation
to
a
trade.
They
have
a
link
to
that
trade
id.
They
have
a
initiating
account
that
points
to
a
token
account,
and
then
they
have
some
data.
That's
attached
to
them.
B
So
in
the
case
of
something
like
an
htlc
there'll,
be
an
initiator
there'll
be
a
participate
from
the
other
side.
There'll,
be
you
know
the
secret
exchange
to
redeem
it
on
one
side
to
redeem
it.
On
the
other
side,
each
of
those
would
map
to
a
trade
step,
but
it's
generic
and
you
can
map
it
to
any
other
kind
of
two-party,
in-party
kind
of
atomic
trade
or
anything
else.
B
B
That
would
be,
of
course,
in
this
case,
if
we're
looking
at
this
atomic
swap
depositing
their
side
of
the
transaction
into
the
contract
that
generates
an
event
back
to
number
one,
and
everything
is
flowing
here
through
the
trade
plug-in
for
this
specific
type
of
swap
at
this
stage,
remember
one
would
be
able
to
claim
the
tokens
redeem
them
actually
receive
them.
That
implicitly
shares
the
secret
to
number
two
they're
able
to
claim
their
side
of
the
transaction,
so
you
can.