►
Description
This is the fourth video of a six-video series about FireFly.
Learn more about how FireFly orders events coming from both the blockchain and off-chain sources, including how to make a connector so that fabric-based blockchains will work with FireFly. Explore plans for integrating Hyperledger Fabric into FireFly and how they will work together.
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
to
our
weekly
firefly
community
call.
I'm
excited
to
welcome
jim
zhang
this
week
to
talk
about
plans
for
integrating
fabric
into
firefly
and
how
that
will
work
together
and
there's
a
little
bit
of
code.
That's
been
written
on
that
and
so
yeah
happy
for
jim
to
share
for
the
first
part
of
today's
community
call
and
then,
like
we've,
been
doing
in
the
past,
we'll
open
it
up
in
the
second
half
for
questions
comments,
discussion
either
on
fabric
or
on
any
other
topic
related
to
firefly.
That
people
would
like
to
discuss
so
welcome.
B
As
you
know,
firefly
historically
started
with
the
support
for
ethereum
and
and
of
course,
we
always
had
fabric
in
the
on
the
horizon,
and
this
is
when
we're
kicking
off
that
effort.
So
in
the
past
few
weeks
on
and
off,
I've
been
thinking
about
what
it
takes
to
build
a
quality
connector
that
will
serve
the
purpose
of
firefly,
and
this
is
really
built
on
top
of
the
the
framework
that
one
of
my
co-founders
for
collido,
peter
broadhurst
has
created
for
ethereum
side.
B
Even
ethereum
fabric
are
very
different
kind
of
chains.
The
majority
of
the
the
work
that
peter
did
for
ethereum
and
he
was
getting
help
from
one
of
our
political
engineering
leads.
We
know
mali,
so
both
of
them
have
created
this
awesome
piece
of
work.
That's
inside
the
firefly
dash
east
connect
repository
and
a
lot
of
this
can
be
borrowed
over
to
support
fabric.
So
today's
session
is
sort
of
half
reviewing
the
framework
that
was
done
there
and
then
have
how
to
plug
in
the
fabric.
B
B
If
you
have
written
any
programs
against
fabric,
you
probably
have
come
across
one
of
the
sdks,
so
there's
no
gs
based
sdk
there's
go
sdk
and
there's
even
the
java
sdk
they're
awesome.
So
they
allow
you
to
to
package
up
application
data
into
transactions,
send
them
to
peers
and
then
send
them
to
to
order.
B
So
they
can
get
mind
into
a
blog,
that's
great,
but
it's
also
a
very
programming
heavy
kind
of
experience
for
a
developer
that
just
want
to
talk
to
a
favorite
network,
so
their
business
data
can
get
into
a
block.
It's
a
it's
a
kind
of
a
very
large
threshold
of
learning
that
you
have
to
go
through
to
even
know
what
you're
doing
you
know
beyond.
B
You
know,
spending
a
lot
of
time,
understanding
the
fabric
design
itself
more
often
than
not,
when
a
enterprise
developer
approaches
a
enterprise
application,
in
this
case
a
blockchain-based
enterprise
application
when
they
think
of
back-end
they
think
of
apis
right.
But
now
we're
saying:
well,
you
have
to
learn
this
sdk.
You
have
to
learn
all
these
calls
that
you
need
to
make
to
to
different
pieces
of
a
favorite
network.
To
do
your
stuff,
so
what
if
we
give
them?
B
Instead
a
restful
api,
you
know
with
clear
endpoints
and
json
payloads,
so
they
can
do
all
that
much
easier,
much
more
easily.
So
that's
what
this
is
for
is,
first
and
foremost,
a
rest
api
that
stands
in
front
of
a
fabric
network.
So
you
will
want
to
just
deploy
this
in
front
of
your
own
peers
and
orders,
so
your
applications
can
talk
to
fabric
through
rest,
but
it's
much
much
more
than
just
a
rest
server,
because
with
enterprise
comms,
a
lot
of
additional
requirements
in
terms
of
key
management.
B
B
B
So
even
if
the
node,
for
whatever
reason,
goes
away
before
it
comes
back,
all
the
transactions
can
continue
to
be
submitted
into
the
system
and
they
would
just
stay
on
the
queue
and
waiting
to
be
to
be
submitted
to
the
to
the
blockchain
so,
and
then
you
also
want
to.
Since
this
is
now
sort
of
a
async
experience,
you
want
to
provide
a
storage
of
of
receipts.
You
know
basically
saving
the
transaction
result
so
that
they
can
be
queried
asynchronously.
B
So
that's
what
this
diagram
is
trying
to
show.
On
the
left
hand,
side,
we
have
sort
of
high
level
api
capabilities.
We've
got
to
be
able
to
manage
identities,
so
users
can
call
a
post
on
the
identities
to
create
signing
identities
so
that,
under
the
cover
we
generate,
the
client,
msp
crypto
materials
get
those
to
be
registered
and
enrolled
with
fabric
ca
so
that
they
can
be
used
later
on
to
summary
transactions.
B
B
My
application
doesn't
really
have
a
lot
of
transactions
going
through
every
day,
so
I'm
okay,
just
sending
one
at
a
time,
wait
for
the
whole
thing
to
be
completed,
and
then
I
I
get
on
the
response.
The
execution
results.
So
that's
that's
just
risk
request
and
wait
and
for
response,
so
that's
sort
of
the
synchronous
api
that
we've
got
to
provide.
B
But
if
your
application
is
going
to
have
many
more
transactions
on
a
single
second
to
be
submitted,
and
you
want
to
submit
those
and
then
wait
for
the
result,
you
don't
want
to
be
held,
you
don't
want
the
the
thread
to
be
held
open.
So
you
want
a
asynchronous
experience,
so
we
want
to
just
acknowledge
the
submission
and
then
track
the
completion
of
the
transaction
asynchronously
and
then
store
the
result
in
some
sort
of
database
so
that
they
can
be
query.
B
Couchdb
based
state
store,
which
provides
excellent
query
capability,
but
creating
on
the
state
database
itself
directly
can
be
less
efficient
because
the
state
has
absolutely
everything
that
the
node
catches,
so
query
performance
may
be
hindered.
If
you
know
all
you
need
is
one
piece
of
information,
but
you
have
to
sort
through.
You
know
thousands
of
other
pieces
that
you
know
that
are
happening
in
channels
not
related
to
you
and
also
given
the
the
design
of
the
schema.
B
B
So
you
want
a
a
stream
of
events
coming
out
of
the
a
pipe
leading
from
the
fabric
mode
going
into
a
sink,
and
then
you
can
take
that
and
store
it
in
your
own
database.
That's
dedicated
to
your
your
applications
and
you
can
query
you
can
set
up
the
schema.
According
to
the
application's
needs
and
that'll,
be
the
the
most
favorable
way
to
cache
transaction
results,
so
it
would
be
very
useful
for
this
connector
to
provide
event
streaming
and
not
just
catching
the
latest
blocks,
but
you
can
tell
this
event
streaming
management.
B
B
So
that's
the
kind
of
event
streaming
capabilities
that
we're
looking
for
here
and
then.
Finally,
in
terms
of
delivering
that
to
the
client,
we
want
both
a
websocket-based
streaming
channels,
but
maybe
for
certain
scenarios,
a
a
webhook
based
delivery
of
events
might
be
useful.
Maybe
the
the
client
is
deployed
in
the
zone
that
you
know
because
of
the
networking
conditions,
websocket
kind
of
long
living
connections
may
not
be
optimal.
B
A
web
hook
based
endpoint
delivery
events
might
be
necessary
there,
so
we
want
to
kind
of
provide
both
so
I've
covered
sort
of
the
high
level
things
now.
Kafka
is
going
to
be
the
cue.
That's
that's
going
to
be
used
to
to
implement
this
queue
so
that
you
know
for
the
async
kind
of
submissions.
We
want
the
all
the
messages
to
be
sent
to
a
kafka
cube.
B
We
want
to
use
one
at
least
one
topic.
It
turns
out
that
we
should
have
at
least
two
topics
that
we'll
cover
in
the
net
one
of
the
next
diagrams,
but
a
a
kafka
topic
on
the
per
node
basis
should
be
created
and
then
based
on
how
many
channels
you
may
have,
we
can
have
different
partitions
dedicated
to
different
channels,
because
kafka
only
guarantees
a
sequence
or
ordering
on
the
partition
per
partition
basis.
B
A
I
actually
have
a
quick
question,
jim
sure,
so
you
start
off
saying
you
know,
sharing
a
lot
of
similarities
and
at
least
thinking
and
design
from
firefly
youth
connect
with
with
firefly
ethnic.
It
is
possible
to
run
with,
or
without
kafka
in
this
design
does
fab
connect
require.
Is
it
a
requirement
or
is
there
another
mode?
You
can
run
it
without
kafka
as
well.
B
Yeah,
that's
a
great
question
so
that
sort
of
segues
into
our
next
diagram
cool.
So
there
are,
unless
there
are
other
questions
on
the
previous
diagram.
We'll
just
continue
here
sounds
like
no
okay,
so
there
are
three
ways
for
a
transaction
to
go
through
the
system
and
each
sort
of
life
cycle
requires
its
own
components.
B
So
to
directly
answer
your
question:
no
kafka
is
not
absolutely
required.
You
can.
You
can
configure
the
system
to
only
do
synchronous
only
do
asynchronous
or
do
both
synchronous
and
asynchronous
and
on
the
asynchronous
side
we
have
also
two
kinds
of
asynchronous
tracking
of
a
transaction
life
cycle.
We
call
it
direct
handler
or
kafka
based
handler,
we'll
talk
about
the
details.
You
know
why
they're
different,
why
do
we
need
both?
B
B
You
know
with
the
json
payload
to
this
endpoint,
specifying
my
chain
code,
my
parameters
and
my
channel,
and
then
I'm
just
gonna
wait
so
that
when
the
response
finally
comes
back,
I
expect
to
see
the
transaction
results
after
the
transaction
has
been
mined
into
a
block
so
to
support
this
kind
of
life
cycle.
We
want
to
build
a
synchronous
dispatcher,
so
correspondingly
there
should
be
a
asynchronous
dispatcher,
so
synchronous
dispatcher
will,
you
know
directly
call
this
sort
of
the
heart
of
the
the
connector.
B
We
call
a
transaction
processor,
so
it's
able
to
translate
a
json
payload
and
then
understand
what
you're
trying
to
do.
What's
the
channel?
What's
the
chain
code
method
and
what
are
the
parameters
and
then
package
that
into
a
payload
that
fabric
nodes
will
understand
and
then
go
through
the
sdk
to
submit
that
into
into
the
network.
B
Wrong
yeah,
I
think
it's
rhonda
has
done
from
a
secure
key.
So
with
the
fabric,
sdk
go
so
yeah.
This
transaction
processor
will
take
the
message
and
then
change
it
into
a
transaction
object
and
then
submit
that
into
the
client
and
call
execute
method
on
the
client,
so
that'll
submit
the
transaction
into
into
a
fabric
network.
You
know
first
contacting
the
peers
and
then
collecting
all
the
endorsement
and
send
it
to
the
order,
eventually
getting
the
event
to
signal
that
the
transaction
has
been
mining
to
a
block.
B
B
B
We
can
do
that
for
you
and
acknowledge
back
here's
the
id
you
can
use
to
keep
track
of
this
transaction
to
see
where
it's
at
on
this
journey
to
the
blockchain
and
back
so
a
unique
id
will
be
generated
to
the
client
in
the
response
acknowledgement,
so
that
this
will
represent
this
unique
message
throughout
the
journey
and
next
we
want
something
that'll
be
responsible
for
keeping
track
of
the
whole
life
cycle
of
this
transaction.
So,
first
we'll
talk
about
a
direct
handler.
B
You
know,
based
on
your
expected
transaction
load,
you
can
dial
it
up
or
down
and
based
on
you
know
how
big
your
peer
node
is:
what's
the
likely
sort
of
submission
rate
onto
the
node
you
can
you
can
support,
you
can
configure
the
number
of
transactions
that
should
be
in
flight
and
then
this
will
then
again
go
through
the
transaction
processor
and
then
send
it
to
to
the
chain.
Then
listen
for
events,
so
all
that
is
is
still
the
same.
B
B
So
that's
all
in
memory.
Obviously,
it's
got
no
thought
tolerance.
If
you
know
the
the
the
if
the
connector
node
goes
away.
You
know
we
have
you
know
in
the
cloud
era.
We
always
need
to
design
our
software
to
be,
as
you
know,
as
much
thought
tolerant
as
possible,
so
we
want
to
also
have
a
kafka
based
option.
Obviously
this
will
be
more
expensive
to
configure
to
deploy
and
to
operate,
but
you
know
has
to
be
there
for
the
enterprise
kind
of
usages.
B
So
what
this
is
is
it's
gonna
be
a
queue
that'll,
you
know
cash
all
the
transactions
and
then,
on
the
other
hand,
the
consumers
will
take
them
off
of
the
queue
submit
it
to
the
to
the
transaction
processor
again,
go
through
that
lifecycle,
tracking
and
eventually,
when
it
comes
back.
The
event
will
also
be
through
back
onto
the
queue
into
a
different
topic.
B
So
we
want
two
topics:
one
topic,
one
kafka
topic
responsible
for
handling
all
the
requests.
So
that's
on
the
way
in
this.
This
is
all
the
requests
that
are
taken
from
the
submission
and
then
the
consumer
of
this
topic
we'll
then
submit
those
to
the
transaction
processors
which
submits
to
the
peer
and
when,
eventually
the
event
is
emitted
by
the
peer,
we
want
to
put
the
event
onto
a
different
topic.
B
A
B
Yeah
I
understand
jrpc
is
more
efficient,
given
you
know
its
binary
payload
and
is
faster
and
also
has
a
full.
You
know
for
duplex
kind
of
connections,
but
I
think
res
is
just
sort
of
the
expected
norm
for
application
development.
You
know
it's
very
likely.
When
you
talk
to
a
enterprise
solution,
developer
application
developer.
B
C
Just
just
conscious
there
was
a
second
part
of
that
was
this
idea
of
grpc
already
handles
the
streaming.
I
think
it's
worth
noting.
Kafka
in
this
architecture
isn't
being
used
for
streaming
as
such,
it's
being
used
as
a
reliable
fault,
tolerant,
persistent
buffer,
so
the
application
can
sort
of
say,
set
and
be
done
right
and,
and
it
will
reliably
become
set.
It's
not
just
put
it
into
a
grpc
buffer,
and
if
it
falls
over,
it
has
to
recover.
It
has
to
use
its
own
state
to
work
out
where
it's
gone.
C
It's
got
it
as
far
as
kafka,
at
least
once
delivery
means
it's
going
to
get
into
the
grcc
buffer
of
of
fabric.
So
the
intention
here
is
taking
away
all
of
the
significant
complexity
that
having
a
grpc
buffer
on
the
other
end
of
something
places
on
an
application
developer
right.
It's
about
taking
that
complexity
away!
It's
not
about
saying
it's
not
valuable!
C
It's
valuable!
It's
just
it's
just
this!
This
kind
of
app
like
basically
everyone
has
to
build
this.
You
want
to
do
reliable,
reliable
streaming
of
transactions
in
the
fabrics
you
you
need
one
of
these,
so
I
mean
we
know,
projects
that
are
built
it
on
on
fabric
jim.
Don't
we
so
so
like
it's
just
it's
just
again.
It's
about
just
sort
of
saying
you
don't
need
to
build
this.
B
B
Yeah
thanks
for
the
additional
input
peter,
so
that's
peter
brothers
himself
there
and
I
guess
just
spending
another
minute
on
the
possible
relay
question
to
kafka.
Why
do
we
even
need
kafka
if
fabric
itself
is
a
fault
tolerant,
kind
of
design
already
well?
This
is
mainly
accounting
for
ingestion
rate.
So
fabric
is
super
fast
right.
It
can
get
up
to
a
thousand
per
second,
but
you
can
totally
have
a
system
that
can
still
overrun
fabric.
B
Even
in
that
scenario-
and
I
think
kafka
is
is
great-
for
that
you
know-
can
easily
catch
a
million
transactions
per
second
plus.
It's
also
a
enterprise
friendly
kind
of
components.
A
lot
of
enterprises
have
like
direct
hooks
into
kafka
to
to
do
that,
and-
and
the
other
aspect
with
this
is
at
least
as
of
now
2.3
you
would
have
to
contact.
B
You
know
a
whole
bunch
of
vibrant
notes,
first
collect
the
information
and
then
submit
the
the
result
to
the
to
the
fabric
order.
So
there
are
many
steps
involved
for
transaction
to
finally
get
into
fabric,
so
all
that
is
now
taking
care
of
behind
the
kafka
consumer.
So
the
applications
don't
have
to
manage
that.
So
I
understand
2.4
is
expected
to
have
the
submitting
here.
So
that's
complexity,
sort
of
is
taken
taken
care
of,
but
still
because
of
the
thought.
A
B
B
B
B
So
that's
one
scenario
you
know
I'd
like
to
be
given
all
this
all
the
events
that
has
happened
in
the
past
plus
listening
to
ongoing
events.
So
that's
one
scenario:
the
other
is
again
what
I
mentioned.
I
like
to
hook
sort
of
a
pipe
leaning
out
the
out
of
the
fabric
node
into
my
own
database,
so
I
can
build
my
own
query
schema
to
to
serve
my
applications
needs.
B
So
what
we
need
to
do
here
is
first
of
all,
we
need
a
subscription
manager.
We
need
to
ask
the
client
what
kind
of
events
are
you
interested
in?
Is
it
all
events
block
events,
transaction
events
or
transaction
events
named
in
certain
patterns,
so
I
can
create
a
subscription
so
that
whenever
any
events
that's
matching,
this
pattern
comes
through.
I'd
like
to
be
notified,
and
I
want
to
see
the
details
of
the
event
and
in
terms
of
getting
delivered
the
event
details.
B
B
B
Will
you
know
poll
from
the
blockchain
either
from
the
latest
blog
or
from
the
the
blog
zero
or
from
certain
blog
that
you
specify
and
replay
all
the
events
since
then,
whenever
every
each
event
is
delivered,
it'll
look
through
the
manager
and
see
which
client
are
interested
in
this
event,
based
on
the
subscription
find
the
configured
way
to
deliver
the
event
to
that
particular
client
and
then
send
it
there.
So
that's
basically
what
what
event
stream
capability
does
here.
B
B
A
B
B
The
response
says
sorry,
I
didn't
take
your
transaction.
Try
again
more
tricky
is
when
something
went
wrong
along
the
journey
after
it's
been
submitted.
So
let's
say
the
the
fabric
node
itself
is
is
beyond
reach
at
the
moment,
so
that
this
this
execute
call
failed
right.
So
the
the
transaction
processor
will
have.
You
know
the
go
routine.
B
That's
fired
off
to
to
keep
track
of
that
particular
transaction
will
have
retry
logic
so
that
if
it's
a
either
404
503,
that
shows
that
the
end
point
is
not
available
at
the
point
at
the
moment.
You'll
just
retry,
so
there's
going
to
be
some
exponential
backup
kind
of
logic
to
to
make
sure
everybody
don't
retry
all
at
once,
and
then
it
can
also
fail
because
the
transaction
itself
is
is
invalid,
but
that's
that
doesn't
really
change
the
the
flow
at
all.
B
So
the
transaction
will
still
come
through
and
there's
an
event
of
the
transaction
fading
and
it
will
be
recorded
in
the
receipt
store
as
a
failed
transaction.
So
the
application
will
query
for
that.
So,
instead
of
seeing
a
successful
transaction,
we'll
see,
a
failed
transaction
and
fabric
is
great
in
telling
exactly
how
it
failed.
I
think
it's
got
like
30
or
40
different
status
code.
That
tells
you
why
the
transaction
failed
and
the
application
can,
you
know,
can
take
care
of
that
by
inspecting
the
the
error
code.
B
B
B
So
I
guess
again,
all
questions
really
to
fireflies
is
fair
game
here
doesn't
have
to
be
fabric.
Specific
okay,
young
has
another
question
when
a
task
backlog
will
be
created
and
where?
How
can
I?
Oh,
oh,
okay,
good
question
if
you
want
to
contribute
we're
still
in
the
early
days
of
coding
things
up,
I'm
hoping
the
first
coat
drop
will
happen
in
the
next
couple
days.
B
A
Yeah
and
github
issues
will
be
the
place
to
find
all
of
those
we're
trying
to
use
github
as
much
as
we
can.
Some
of
the
projects
that
have
been
up
there
for
a
little
bit
longer
have
a
healthy
backlog
going
now,
but
obviously
this
one
is
brand
new,
so
it
will
take
a
little
bit
of
time
to
fill
that
out,
but
that's
that's
where
they
will
be.
B
B
A
C
It's
it
says,
look
I'm
gonna,
developer,
you're,
gonna
say:
please
send
this
transaction
and
I'm
gonna
give
you
an
identifier
right,
I'm
going
to
give
you
a
placeholder
for
submission
of
that.
I'm
going
to
give
you
that
straight
away,
and
I
promise
eventually
to
either
give
you
a
yes.
I've
sent
that
transaction
event
or
I
promise
to
give
you
five
fails
for
that
for
that
event.
C
But
I
don't
promise
that
if
you've
done
something
wrong,
which
is
where
you
need
to
have
attitude
right,
which
is,
if
you've
done
something
wrong,
I'm
going
to
try
to
like
stop
the
world
to
not
process
anything
after
that.
So,
if
you,
if
you
as
a
as
a
submitter
of
transactions
to
fabric,
if
you
have
a
requirement
that
this
transaction
must
be
mined
before
this
transaction,
otherwise,
like
I've,
broken
I've
broken
my
my
unchained
state.
C
If
I,
if
I
try
to
submit
transaction
number
two
before
transaction
number
one
is
submitted,
then
you
need
to
wait
for
it
to
go
all
the
way
through
and
come
come
back
as
notifications,
the
the
system
would
will
will
attempt
and
your
sort
of
dead
letter
cue
processing,
you
would
normally
have
done
the
messaging,
it's
it.
It
tries
to
appear
in
the
time
it
tries.
There's
lots
of
error,
handling
and
etc.
C
It's
still
all
done
for
evarium
and
still
on
the
plate
for
fabric
around
well.
Okay,
I
need
to
I
don't
know.
I
need
to
get
I've
looked
at
the
the
policy
for
this
channel
and
I
need
five
signatures
to
get.
I
need
five
signatures
because
there's
ten
parties
and
only
fifty
percent,
so
I'm
gonna
gonna,
try
and
find
five
parties
and
I'm
gonna
try
and
get
signatures.
C
There
should
be
in
the
configuration
and
probably
lots
of
configuration
policies
on
like
how
long
am
I
going
to
try
for
what,
if
nobody's
available,
what,
if
I
can
only
get
to
four?
How
long
do
I
wait
for
the
fifth
and-
and
it
should
be
that
the
policy
isn't
I'm
just
going
to
wait
forever
right,
because
maybe
this
channel
is
just
broken
at
the
moment.
It
can't
there's,
there's
actually
only
four,
no
full
loads
up,
there's,
not
five.
No
time
the
system
should
reliably
try
for
a
period
of
time.
C
C
The
the
approach
so
far
has
been
to
say
what
you'll
get
a
failure
and
then
the
firefly
core
side.
The
transaction
objects,
then
gets
updated
as
a
failure
and
there's
also
associated
with
the
transaction
objects
which,
with
sorry
associated
with
like,
if
you're
trying
to
send
a
message
or
you're
doing
a
token
transfer
or
whatever
there's
a
concept
of
an
operation
which
is
is
like
this
bit
went
well.
I
couldn't
submit
the
on-chain
transaction
as
part
of
the
token
transfer,
but
maybe
I
sent
the
message.
C
C
So
sorry
that
was
a
bit
of
a
long
long
description
but
like
the
model
is
not
stop
the
world,
which
is
where
you
need
their
vertices.
The
model
is,
I'm
gonna
do
my
best.
I'm
gonna
do
like
not
like.
You
could
have
written
the
thousand
lines
of
reliably
trying
to
get
transactions
into
fabric
code
yourself,
but
here's
a
community
that's
within
the
best
job
that
they
can
do
it
do
for
you
with
reliability,
threshold
tolerance,
all
the
like.
C
B
Yep,
thanks
be
to
definitely
not
the
expert
on
enterprise,
cues
and
messaging
here
so
yeah,
if
you
guys
have
any
other
questions
of
fantastic
questions
so
far,
we're
always
available
on
rocket
chat.
I
just
pasted
the
link
there.
The
the
channel
is
called
dash
lab,
so
always
welcome
any
questions
from
that.
C
Do
you
think
this
is
a
really
exciting
piece
of
work
and
this
component,
maybe
just
one
last
thing:
this
component,
like
once,
we've
got
two
legs
of
the
stool
right
corners
a
little
bit
further
behind
it
and
go
ahead
and
look
at
the
chord
connectors,
there's
loads
of
code.
There
there's
some
architectural
challenges
still
to
solve,
but,
like
we've
got
ethereum
and
fabric
at
this
layer.
The
intention,
then,
is
that
we
can
prove
the
layer
on
top
and
firefly
that
isn't
just
like
simple
transactions
and
token
transactions.
It's
it's
any
transaction
like
make.
C
Just
you
know
you
can
have
custom
transactions
and
that
layer
in
the
firefly
call
can
exist,
and
I
know
there's
been
lots
of
questions
since
firefly.
We
started
talking
about
it
on
tsc
calls
and
the
like
of
what
about
what
about
my
custom,
on-chain
logic,
and
we
didn't
want
to
declare
success
on
that
at
the
core
layer,
just
because
we've
got
it
at
the
ethereum
layer,
because
until
you've
proven
something
with
two
blockchain
technologies
and
jim's
been
making
the
point
to
me
a
lot
like
you
can't
prove
an
orchestration
layer.