►
Description
Learn how FireFly makes it possible to design apps in an event driven manner, the advantages of this over other models, and how it's a natural fit for enterprise multi-party systems.
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
#Hyperledger #HyperledgerFireFly #Blockchain
A
Welcome
everybody
to
the
weekly
firefly
community
call
thank
you
for
joining.
I
I
don't
have
many
announcements
for.
Actually
I
don't
have
any
announcements
for
the
beginning
of
the
call
today,
but
for
today's
topic,
for
the
first
part
of
the
meeting,
peter
broadhurst
will
be
speaking
on
event,
driven
programming,
design
or
event
driven
application
design,
and
how
this
is
you
know:
firefly
is
built
with
this
design
in
mind
and
things
just
work
great
when
applications
are
also
built
in
this.
A
B
So
we
we
thought
it
would
be
really
good
to
do
a
session
on
event
driven
programming
because
there's
a
sort
of
assumption
in
in
every
every
piece
of
how
far
firefly
has
evolved
that
the
the
wave
at
the
system,
the
way
that
the
multi-party
system
will
be
built
is
in
an
event
driven
way
and
it's
a
particular
type
of
programming.
It's
definitely
not
a
new
type
of
programming,
but
it
is
a
particular
pattern
and
it's
not
a
pattern
that
everybody's
come
across.
B
So
I
I
want
to
talk
through
that
pattern
from
ground
the
ground
up
really
in
this
session
and
build
up
to
talking
about
how
event
driven
pro
driven
programming
is
different
in
a
multi-party
system
compared
to
all
the
other
types
of
event-driven
programming
that
you've
done
in
the
past
and
then
talk
about
how
it
actually
works
practically
in
firefly.
So
that's
the
that's.
B
You
can
either
use
a
request
to
apply
approach
which
is
synchronous,
but
I'm
going
to
try
and
not
use
synchronous
and
asynchronous,
because
there's
so
many
ways
that
those
could
be
used,
request,
reply
approach,
which
is
like
a
telephone
system.
One
wants
to
talk
to
system
two,
so
it
makes
a
call
to
system
two
and
waits
waits
for
that
call
to
complete.
This
is
the
way
you
know
a
rest.
Api
to
the
internet
works.
It's
the
fundamental
way
that
http
works,
although
you
can
layer
stuff
on
top
of
http.
B
So
I
it's
just
like
a
telephone
conversation.
You
get
put
on
hold
until
they're,
ready
if
they're
behind
they're
going
to
be
slow
in
responding
to
your
your
request,
and
you
only
know
that
they've
done
the
thing
that
you're
that
you're
going
that
you've
asked
them
to
do.
If
you
sit
there
and
you
wait
for
them
to
do
all
of
that
thing
and
come
back
with
an
answer,
so
the
outcomes
are
either
a
success.
You
know
a
http
200,
okay,
a
failure.
B
I've
got
a
500
or
an
hour
or
some
kind
of
explicit
error
and
most
of
the
time
with
hours,
you
kind
of
know,
what's
happened
or
equally
likely,
just
nothing
at
all.
It
just
sort
of
a
deadline.
You
know,
we've
all
been
on
hold
to
the
you
know,
to
the
to
the
wireless
telephone
provider
and
you
get
put
on
hold
and
it's
silent
and
it's
like.
Are
they
still
there
have?
I
been
lost,
what's
happened
and
you
just
sort
of
eventually
give
up
and
put
the
phone
down?
B
How
do
you
find
out
if
it's
worked
or
it
hasn't
when
you're
kind
of
going
to
retry
make
another
phone
phone
call?
Well,
it's
about.
Let's
request,
reply,
approach
to
building
applications
and
and
there's
two
there's
there's
two
things
I
talked
about.
One
of
them
is
that
both
sides
have
to
be
available
and
ready
to
talk
to
each
other.
The
other
is
it
it's
really
just
a
one-to-one
thing.
You
know
you
you've
got.
B
I
can
expect
that
I'm
going
to
get
a
response
pretty
quickly,
but
I'm
not
like
beholden
to
having
a
response
really
quickly.
I
can
go
on
get
on
with
my
life.
I
can
as
an
application,
I
can
move
on
and
do
other
things
and
whenever
the
other
party's
ready
and
it's
got
through
the
I
know,
a
thousand
things
I've
put
people
have
put
in
front
of
it
before
that-
gets
to
that
that
particular
email
in
their
inbox.
That
particular
text
message.
B
That's
come
to
them
that
whenever
they're
ready
and
they
respond,
you
process
that
response,
and
this
is
a
very
flexible
pattern,
because
you
can
have
lots
of
different
failure,
handling
strategies.
You
know
you
can
send
things
multiple
times
and
and
we
process
them,
which
is
kind
of
the
only
way
that
you
can
do
it
for
request
reply
messaging,
but
you
can
also
have
things
like
compensation.
Logic
talk
about
sagas
later
and
you
can
also
just
choose
to
ignore
things
that
you
can't
you
can't
process
and
maybe
say
no.
B
I
can't
process
it
or
or
just
just
ignore
it,
because
you
know
it's
a
duplicate
or
you
know.
You
know
that,
there's
a
reason
why
it's
safe
to
ignore
it.
So
it's
a
very
flexible
way
of
programming
and,
as
I
said
before,
firefly
and
and
these
are
some
of
nico's
charts
and
nika
did
a
great
great
introduction
to
firefly
in
a
community
session.
B
We
had
two
three
weeks
ago,
which
is
recorded,
so
you
can
go
and
listen
through
the
fundamentals
here,
but
but
firefly
supports
both
patterns
fully
and
one
is
built
on
top
of
the
other,
and
this
is
quite
common
in
enterprise
systems.
The
request
for
ply
capability
is
just
a
special
type
of
events,
use
of
events,
you're
just
sending
one
event
and
you're
expecting
exactly
one
reply
and
we're
going
to
talk
a
little
bit
more
later
about
the
actual
interfaces
here
and
how
you
build
applications
on
top
of
firefly.
B
For
this.
So
we'll
come
we'll
come
back
to
this.
I
promise,
but
I'm
gonna,
I'm
gonna
take
a
bit
of
a
bit
of
a
roundabout
route
here
and
talk
a
little
bit
about
the
history
of
events,
because
it's
a
topic
to
my
heart,
where
I
I've
lived
it
since
the
very
very,
very
first
day
of
my
my
career
in
in
in
enterprise
I.t.
I
I
worked
on
on
the
core
of
on
the
messaging
technologies
in
ibm
called
thank
you
series
and
the
year.
Why
started
this?
B
This
book
was
was
published
and
it's
a
pretty
famous
book
in
the
enterprise
space
and
the
the
hop
and
wolf
enterprise
integration
patterns
and
and
the
the
website's
still
there.
So
you
can
go,
read
about
them
and
they're
still
super
applicable
patterns
and
back
back.
Then
you
know
to
to
in
a
bit.
You
know
this
has
evolved
over
about
three
decades,
so
this
is
kind
of
like
the
end
of
the
first
decade
of
of
the
evolution
here.
B
You
know
famously
companies
like,
like
tibco,
really
really
focused
on
that
for
the
whole
of
their
existence,
you
know
and
that
that
approach
allowed
resilient
resilient
systems
inc
in
the
core
of
organizations.
You
know
the
payment
rails
of
of
banks,
but
you
know
the
the
core
transaction
processing
systems
of
insurance
companies
and
supply
chains
and
healthcare
right.
B
Sorry
request
for
ploy
base
based
approach
after
this,
and
then
there
was
another
wave.
There
was
another
wave
in
the
sort
of
mid
mid-2010s
of
a
resurgence
of
the
understanding
of
why
event-driven
programming
at
its
core
is
just
this
fantastic
way
of
of
being
being
really
sure,
you're
going
to
get
the
right
outcome
out
of
the
end
of
something
and
and
this
time
the
focus
wasn't
on
multiple
systems
all
connected
together
and
services
organizations.
B
This
is
a
really
great
great,
like
five
minute
wait
to
to
really
understand
how
event
driven
programming,
even
inside
of
an
application
like
inside
of
one
process,
can
allow
resilient
engineering.
So
don't
think
of
this
picture
here
as
multiple
multiple
players
in
a
network.
Think
of
this,
as
just
I've
got
bits
of
logic
I
can,
instead
of
connecting
them
together
by
having
them
all
call
each
other
and
wait
for
each
other.
B
The
business
logic,
if
you
can
start
to
think
about
it
as
the
set
of
state
changes
in
that
in
a
state
machine
and
and
you
can
break
all
of
those
state
changes
back
into
being
a
set
of
inputs,
a
function
that
runs
on
them,
deterministic
or
non-deterministic.
That's
fine
doesn't
matter
function
that
runs
on
them
and
then
it
triggers
one
or
more
other
items
of
processing.
B
Now,
microservices,
then
came
came
along
one
of
the
most
exciting
things
to
happen,
to
the
way
that
we
build
applications
over
certain
whole
of
my
my
career
and
we
stopped
building
these
monoliths.
We
stopped
building
these
massive
java
application
server.
Applications
that
just
like
were
all
in
a
box
and
we
started.
B
We
started
writing
things
that
the
application
itself
needed
to
be
decoupled
and
connected
together
and
like
some
of
it's
written
in
java
and
some
of
it's
written
in
node.js
and
some
of
it's
written
in
go,
and
maybe
some
of
it's
written
in
a
language
scholar.
But
all
of
these
bits
are
running
independently
and
scaled
independently
and
a
whole
new
generation
of
programmers
came
and
performed.
B
Now,
instead
of
one
application,
because
it
split
into
lots
of
different
runtimes
had
to
worry
about.
How
do
you
do
a
sequence
of
events
with
a
reliable
outcome?
And
if
you,
if
you
follow
this,
this
link
you'll
hear
about
the
saga
pattern,
which
is
kind
of
multiple
services.
Had
events
from
the
beginning,
they
thought
about
events
from
the
beginning
saga
was
kind
of
like
the
latest
generation
of
how
people
think
about
I've
got
a
bit
of
logic.
It
needs
to
call
another
bit
of
logic.
B
What
how
do
I
cope
when
that
follow-on
piece
of
logic
doesn't
doesn't
complete?
What
what
does
compensation
look
like
in
the
modern
in
the
modern
world?
What
if
I've
got
a
history
of
events?
This
is
the
critical
thing.
If
I've
got
a
history
of
events
and
something
fails,
I
can
look
back
at
what
happened
and
decide
what
to
do,
but
I
can
only
do
that
and
that's
why
it's
called
a
saga.
B
If
I've
got
this
history,
like
it's
an
evolving
story,
that's
got
a
you
know
a
story
arc
that
goes
from
from
photo
in
hobbiton
all
the
way
through
to
photo
coming
coming.
Coming
back,
having
jesus
smog
like
that,
all
of
the
the
the
all
of
those
hundreds
of
pages
of
story
up
right,
that's
what
your
transaction
looks
like
and
if
you've
not
got
all
of
the
pages
in
the
book
marked
out
in
a
way
that
you
can
look
back
at
them.
It's
really
hard
to
know
what
to
do
when
something
goes
wrong.
B
So
if
you
think
about
it
as
this
sort
of
evolving
saga,
with
information
about
everything
that
happens,
you
can
kind
of
cope
with
anything
which
is
which
is
beautiful.
It's
it's.
It
sort
of
feels
like
utopia
from
a
programming
perspective,
but
it
does
have
some
challenges
which,
and
you
do
have
to
think
in
a
slightly
different
way.
B
So
here
we
are
in
in
the
2020s
and
we're
on
the
edge
of
a
new
wave
right.
This
multi-party
system
thing
that's
evolving,
that
that
firefly
is
trying
to
accelerate
it,
and
that
is
you
know
the
thing
that
is
enabled
by
enterprise
blockchain
and
by
these
fantastic
technologies
like
zero
knowledge,
proofs
and
and
peer
file
sharing
technologies
like
ipfs
and
trusted
compute
engines
right
this
multi-party
systems
revolution.
This
next
step
in
the
journey
is
really
exciting,
because
some
things
haven't
changed,
but
really
important
things
have.
So
let
me
talk
about
that
right.
B
B
Right
we're
connecting
people
together
and
previously
we
might
have
been
using
best
interfaces
that
aren't
so
event
driven.
We
might
have
been
using
event
driven
integration
patterns
between
people
in
the
between
organizations
in
the
past
and
and
there.
Obviously,
everything
was
private,
because
there
was
no
shared
state,
but
even
in
a
multi-party
system.
You
have
to
just
bear
in
mind
that
most
of
what
the
business
cares
about
in
terms
of
their
processing,
their
human
decision
making
their
business
processes
even
special.
B
B
If
it
wasn't
perfect
and
sensitive,
there
wouldn't
be
an
interesting
problem
to
solve
like
so
those
things
have
not
changed,
but
some
stuff
has
changed
and
the
stuff
that's
changed
to
me.
It's
the
reason
why
I
got
into
blockchain
it's
the
reason
why
I
went
on
the
jet
the
virginia
and
we
found
a
colloidal
way
is
suddenly
you
can
do
this
stuff
in
a
fundamentally
different
way,
because
a
few
things
have
changed.
B
So
some
logic,
some
logic
can
be
executed.
Deterministically.
We
can
execute
it
in
a
way
that
no
one
can
argue
on
the
outcome,
because
every
you
know
enough
people
executed
it
or
they
executed
it
with
a
proof.
You
know
there's
a
consensus
or
trusted
compute
proof
or
zero
knowledge.
Proof
that
says.
Look
there's
no
arguing
about
the
fact
that
this
particular
business
posting
happens.
That's
fantastic.
B
It
enables
tokens
it
enables
it
enables
like
critical
sort
of
decision
making
processes
that
are
at
the
heart
of
the
most
sophisticated
transactions
where
it
it
allows
those
to
be
executed
dependently
across
the
organizations
and
that's
fantastic
and
that's
never
been
possible
before
and-
and
it
also
allows
you
to
store
some
data
in
a
way
that
everybody
has
it
and
that's
really
cool
and
it's
kind
of
been
possible
but
before.
But
but
you
know
it's
really
embraced
in
in.
B
If
you
use
technologies
like
blockchain
or
ipfs,
you
can
have
references
all
the
data
itself
stored
in
a
in
a
place
that
everybody
has
got
a
copy
of
that
data
and
that
that's
fantastic
but
again
bear
in
mind.
That's
not
going
to
be
all
of
your
data
because
there's
challenges
without
an
enterprise,
okay,
bam
case,
and
then
the
thing
that
this
all
builds
upon,
particularly
all
of
this,
this
determinant
execution
logic
is,
is
the
thing
for
this
presentation
in
particular:
that's
transformative
revolutionary
over
every
previous
generation
of
this
deck.
B
B
The
transformative
to
how
event-driven
systems
can
work,
because
suddenly
now
that
sequence
of
events
can
be
multi-party
systems
of
events
that
wasn't
true
in
the
inventory
of
an
integration
age
that
wasn't
true
in
the
west
web
services
soap
age
for
an
soa
for
connecting
together
organizations,
microservices
proved
how
powerful
it
was
to
have
that
inside
of
an
application.
But
microservices
are
you
know
that's
about
building
one
application
inside
of
an
individual
organization.
B
Now
we
can
do
this
in
a
way
that
just
can't
be
argued
right.
It's
not
worth
arguing
that
blockchain's
wrong
right
that
you
you're
not
gonna.
Have
this
where's,
my
what
sequence
of
things
happening,
where's
my
message,
kind
of
challenge
that
we've
always
had
in
that
in
the
past,
so
it's
transformative
and
what
that
means
from
a
solution.
Development
perspective
is
that
you
can
now.
B
You
can
now
build
these
multi-party
business
processes
and
get
some
maybe
most,
but
some
still
massive
of
the
benefits
that
you
that
you
could
just
the
things
you
could
rely
on
when
you
were
just
building
a
system
inside
of
your
organization
like
you're
building,
you
know
maybe
previous
generation,
business
process,
management,
you're,
modeling,
a
business
process,
maybe
you're,
building
micro
services,
you're
building
a
solution
that
that
you
know
has
a
user
interface
has
apis.
Connects
to
your
core
systems
that
implements
a
business
process,
gets
a
transaction
done
end
to
end
right.
B
We
could
do
that
inside
of
an
organization.
We
can
now
do
the
same
thing
cross
organization
and
that's
really
where
firefly
is
trying
to
make
the
job
simpler.
You
connect
together
the
super
on
chain
logic,
the
tokens,
the
you
know,
simple
pinning
as
well,
but
the
custom
on
chain
logic.
You
connect
that,
together
with
the
off
chain
integration
to
the
core
systems
across
multiple
parties
and
we've
got
the
shared
sequence
of
events,
so
we
can
actually
like
do
the
same
kind
of
application
and
business
process
that
you
could
do
with
microservices
architecture
in
one
organization.
B
But
there
is
a
couple
of
gotchas
a
couple
of
things
that,
just
like
the
laws
of
physics
are
a
little
bit
different
in
this
environment
too.
They
were
in
in
just
like
a
microservices,
isolated
environment
to
one
organization
and
one
difference
to
having
seen
lots
of
developers
building
this
pattern
as
because
you
know
we've
been
doing
this
for
quite
a
while
in
the
evolution
of
of
a
far
flame
before
it
came
to
hyperledger
one
of
the
things
that's
a
little
bit
like
the
sort
of
squint.
B
How
did
that
happen
is
the
event
bus
when
it's
a
blockchain,
backed
event
bus
when
it's
an
event,
that's
significant
enough
to
sequence.
It
across
organizations.
You
can't
just
assume
when
you
send
the
event
that
you
know
where
it
slots
into
the
sequence
on
the
sending
side.
Now
that
has
not
ever
been
true
really
in
in
in
messaging
systems,
right
I've
got
I've,
got
a
kafka
queue
or
or
an
mq,
or
a
typical
sb,
or
an
active
mq
between
me.
B
You
know
my
my
system,
like
I
don't
know
what
you
say:
payments
and
reconciliation
where
I've
got
my
payment
system,
it's
only
reconciliation
system.
I
said
message
one
two:
three,
I
just
sort
of
know
that
one
two
three
is
going
to
arrive
on
the
other
side
and
they're
gonna
process
message,
one
two,
three
right!
That's
just
true!
B
Well
it's
a
little
bit
different
here,
because
the
you're
not
the
only
one
submitting
the
the
the
the
apps
you
can't
just
like,
even
if
you
do
you're
doing
horizontal
scale
in
microservices,
you
can
still
often
like
know
that
you're,
the
only
one
that's
sending
these
events,
the
events
are
being
sent
from
the
other
sides
as
well.
There's
like
five
parties
involved,
they're
all
sending
these
events.
B
B
Your
own
logic,
you
have
to
sort
of
say,
look,
I
think
the
first
well,
the
first
one
isn't
so
interesting.
I
think
the
second
step
like
is,
is,
I
don't
know
it's
a
bidding
system.
It's
like
right.
I
wanna
I
wanna.
I
I've
received
a
request
for
attendance,
I'm
gonna
I'm
gonna
submit
but
like
the
first
five
submissions
win,
I
think
that
I've
I'm
going
to
submit
and
my
submission's
going
to
be
number
four
and
I
submit
it
because
I
looked
and
there
was
only
three
submissions
before
I
submitted
it.
B
Well,
that's
not
good
enough
to
know
that
you
were
number
four.
You
can't
trigger
the
bit
of
your
logic
that
says
to
your
users.
I've
submitted
it
and
you're
number
four.
At
that
point,
you
can't
show
that
state
yet
to
your
users.
You
can't
have
that
in
your
core
systems,
because
until
it's
been
ordered,
and
then
you
process
it
and
at
the
point
that
you're
processing
it-
you
look
at
the
current
state
and
you
say:
I'm
still
number
four
number.
You
know
another
number
four
didn't
come
in
before
me.
B
You
can't
rely
on
it
being
true,
so
just
because
you
sent
it
doesn't
make
you
special.
You
have
to
process,
you
have
to
think
of
your
own
events
being
ordered
along
with
everybody
else's.
So
that's
really
like
it
sounds
subtle,
but
that
really
does
just
create
an
extra
level
of
thoughts
in
your
applications.
B
This
is
not
changing
the
fact
that
this
is
an
asynchronous
event
that
I'm
sending
we
can
make
it
so
that
it
will
block
until
you've
got
the
confirmation
from
the
blockchain
and
that
event's
being
confirmed,
so
you
don't
have
to
you
know
if
you
want
to
just
sort
of
wait
and
have
a
spinner.
If
you
want
that,
then
you
can
do
that
and
that
that
there's
just
a
few
places
where
it's
like,
particularly
early
on
in
development.
It's
super
super
easy
to
do
that.
So
we're
going
to
add,
add
that
about
into
five
life.
B
So
there's
now
another
difference
and
I'm
conscious
on
time
and
I've
been
waffling
a
bit,
but
but
there's
another
there's
another
difference
here
and-
and
I
think
this
one's
really
significant
personally
blockchains,
if
you
squint
of
a
messaging
technology,
if
you
squint,
but
there
were
very,
very
different,
shaped
messaging
technology
to
traditional
message,
queuing
and
streams.
So
if
you've
used,
if
you've
used
one,
you
know
one
of
those
mq
technologies
or
you've
used
them.
You
know
the
latest
generation
of
things
like
kafka
streaming.
B
You
know
that
they're
super
reliable
right.
They
they
they
they
look.
After
your
messages,
they
get
them
to
you
really
from
a
to
b,
really
really
quickly.
They
batch
they
optimize,
they
have
durability
or
persistence
is
often
called
they.
You
know
they
cope
with
periods
of
down
time,
they'll
buffer
things
they'll
like
that
they're
awesome.
Those
technologies
should
still
be
used
in
these
sort
of
modern
systems,
but
but
they're
not
like
a
complete
history
of
time.
B
It's
it,
I
believe,
without
exception,
and
and
I'm
happy
to
be
proof
wrong
on
it
that,
but
I
believe
without
exception,
they
they
say
it's
a
really
big
anti-pattern,
even
if
they
support
like
turning
up
the
size
of
your
q
depth.
You
know
or
transaction
ledger
to
infinity
they're,
not
designed
to
be
a
replayable
complete
history
of
time,
they're
designed
to
be
a
buffer
from
a
and
b
to
be
a
mailbox.
B
Your
mail
goes
into
it.
You
know
the
postman
can
fill
it
up
to
the
top.
They
can
stick
stuff
on
top
of
it,
maybe
a
bit
they
can
stick
stuff
underneath,
but
eventually
it
becomes
full
and
when
you
want
to
read
stuff,
you
take
it
out
of
the
mailbox
and
you
open
it.
It's
no
longer
in
the
mailbox
anymore.
That's
different
to
the
way
a
blockchain
ledger
works.
Blockchain
ledger
is
designed
to
allow
you
to
look
back
in
history
and
see
the
complete
history
of
time
and
that's
super
fantastic.
B
B
You
can
see
the
the
complete
history
now
and
you
can
build
applications
that
can
have
that
that
history
in
an
immutable
way
that
that's,
if
you've,
if
you've
read
about
the
utxo
model,
the
the
the
unspent
transaction
output,
a
model
of
the
way
that
blockchains
like
bitcoin
work
that
that's
what
they're
built
on
like
that.
That
concept
that
you
know
for
sure
right
now,
you
can
trust
them
right
now,
but
also
you
know
you
can
prove
them
right
now
by
looking
back
in
time
to
the
beginning
of
beginning
of
time.