►
Description
A virtual meetup hosted by Hyperledger Sydney focused on performance improvements for Hyperledger Fabric.
The blockchain research group at Xilinx, the leading FPGA vendor, has been studying different methods to improve the performance of Hyperledger Fabric, and other blockchains. Historically, FPGA chips have been used to accelerate PoW mining for Bitcoin and Ethereum in the early days of the cryptocurrencies. They are also being used for several alt-coins.
In this event, Blockchain researcher Dr. Haris Javaid from Xilinx will share his current focus on identifying specific areas of HLF that can benefit from hardware acceleration, and showcase work identifying these bottlenecks. Dr. Haris Javaid will describe how Xilinx have improved the performance for block validation in HLF by an order of magnitude. A short demo of proof-of-concept work will be followed by discussion.
More about the event is at: https://www.meetup.com/Hyperledger-Sydney/events/273899207/
----
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 #HyperledgerMeetups #Blockchain
A
Let's
say
every
second,
which
measures
how
much
electricity
or
energy
a
client
is
using,
and
this
transaction
is
then
recorded
on
a
blockchain
and
afterwards
the
blockchain
data
could
be
analyzed
for
fine-grained,
tracking
fine-grained
usage
and
billing,
as
well
as,
if,
let's
say
some,
clients
have
solar
panels
or
other
forms
of
renewable
energies,
and
they
are
pumping
energy
into
the
grid.
That
can
also
be
tracked
and
measured
through
these
transactions,
and
then
they
can
get
rebates
for
their
for
their
electricity
bills.
A
So
we
want
to
look
at
this
example
from
performance
and
scalability
point
of
view
so
consider
here
at
the
bottom.
If
we
looked
at
some
articles
published
online
about
a
year
ago
and
different
companies
which
are
trying
to
work
on
this
as
a
test
project
and
the
data
we
could
gather
from,
there
was
if
there
is
a
single
supplier
and
then
a
few
major
consumers
or
clients
for
the
supplier.
A
We
might
look
at
about
some
30
000
transactions
being
generated
per
hour.
But
if
you
want
to
take
this
small
test
project
and
scale
it
out
into
some
kind
of
a
let's
say,
a
grade
for
a
big
city
or
a
national
grid
for
an
entire
country,
we
would
be
looking
at
billions
of
transactions
being
generated
per
hour.
And,
of
course,
if
the
systems
which
are
backing
up
and
which
are
being
used
to
create
these
transactions
cannot
process
these
transactions.
A
In
real
time,
then
the
whole
idea
of
using
blockchain
for
fine-grained
real
tracking
goes
away.
So
we
did
some
more
analysis
on
top
of
that,
and
what
we
figured
out
was
if
we
take
the
current
blockchain
systems,
which
are
mostly
software
only
and
we
assume
we
can
improve
them
by
a
magnitude
of
order
like
by
10x.
A
Even
then,
we
would
only
be
able
to
support
about
a
thousand
million
transactions
or
one
billion
transactions
per
hour.
So
if
you're
looking
at
a
national
grade,
that's
far
more
more
than
what
the
current
software
systems
with
additional
improvement
can
achieve,
and
that's
how
we
at
xilinx
came
to
look
at
this
blockchain
scalability
and
performance
issues
area
to
see
whether
we
can
use
hardware
to
accelerate
and
go
beyond
the
software
only
valve,
which
is
the
limitation
of
current
systems.
A
So
keeping
that
example
in
mind
here
on
the
left.
I
have
some
of
the
performance
or
scalability
metrics,
for
example.
I
want
to
increase
the
transaction
per
second
rate.
What's
the
benefit
of
that,
I
can
do
better
finding
when
tracking
of
the
energy
usage
as
well
as
I
can
support
more
participants
in
the
system.
But
what
does
it
mean
to
scale
that
out
in
terms
of
the
infrastructure
which
is
going
to
this
kind
of
a
blocking
system
in
terms
of
compute?
A
We
need
faster
execution
of
transactions
in
terms
of
networking,
because
there
are
multiple
nodes
and
peers
in
the
system
which
talk
to
each
other.
We
need
better
networking,
faster
networking
to
process
the
transactions
and
move
them
around
from
nodes
to
different
nodes
in
the
system
and
likewise,
in
terms
of
storage,
the
storage
will
grow
very
fast.
So
we
need
you
know
more
and
more
storage,
but
also
we
need
higher
access
rates
for
that
storage
because
we
have
many
more
transactions
coming
in
on
a
per
second
a
day
on
a
per
second
time
frame.
A
Okay,
now
I'm
switching
gears
to
what
zoiling
says
and
what
we
do.
Some
of
the
folks
might
know,
but
I
get
this
question
a
lot
because
primarily
hyperledger
projects
were
created
from
people
who,
almost
in
the
software
domain,
so
just
a
quick
overview
of
styling.
So
xylinx
is
the
inventor
of
fpga
which
stands
for
field
programmable
gate
arrays.
You
can
think
of
this
as
a
chip,
hardware,
chip
which
can
be
programmed
again
and
again
so,
just
like
you
can
upgrade
a
software
after
you
have
shipped.
A
You
know
one
of
your
products
just
like
that.
You
can
reprogram
your
hardware
and
fix
some
bugs
in
your
hardware,
so
it
gives
you
the
flexibility
that
typically
software
systems
have
and
as
of
now,
the
links
produces
different
kind
of
fpga
chips,
boards
and
some
development
kits
as
well
as
it
also
provides
acceleration
libraries
or
software
libraries,
which
kind
of
provides
seamless
integration
to
other
software
applications
if
they
want
to
benefit
from
the
hardware
acceleration
and
recently,
xilinx
has
also
been
producing
acceleration
cards
which
are
just
like
other.
A
A
Have
these
acceleration
cards
available
in
their
servers
and
you
can
rent
them
and
use
them
if
you
want
to
I'll
skip
the
rest
of
the
info,
which
is
just
some
numbers
and
then
give
you
a
bit
of
more
idea
of
what
a
programmable
acceleration
platform
from
looks
like.
So
here
is
a
typical
chip,
which
has
a
few
different
type
of
components.
A
The
first
one
here
on
the
left
hand,
side
are
called
scalar
engines.
They
are
basically
processors
like
arm
processors,
where
you
can
run
your
software
applications
here.
On
the
right
hand,
side
you
have
some
intelligent
engines.
These
are
basically
specialized
custom
designed
hardware
accelerators,
for
example,
maps
engines
for
machine
learning,
inference
some
signal,
processing
engines
for
signal
processing
applications
and
then,
in
the
middle
here
we
have
the
adaptable
hardware,
which
is
basically
the
fpga.
A
So
this
is
the
part
where
you
can
take
your
hardware,
design
and
program
it,
and
then
you
can
change
it
over
time
as
well.
If
you
want
to-
and
then
here
at
the
bottom,
there
are
some
hardened
eyepiece
which
let
you
connect
this
compute,
this
extensive
type
of
compute
engines
to
different
type
of
other
systems.
A
For
example,
there
is
the
pcie
ip
here,
there's
ddr4
for
memory
connections.
There
are
ethernet
cores
here
and
so
on,
and
these
tips
are
now
available
as
part
of
as
part
of
these
acceleration
cards.
One
of
them
is
shown
here
called
lbo,
which
you
can
just
buy
off
the
shelf,
and
you
can
basically
plug
them
into
your
server.
And
then
you
can
use
them
for
acceleration.
A
So
before
I
go
into
the
work
which
I
want
to
demonstrate
today,
just
want
to
give
you
a
bit
of
background
of
our
group.
We
started
looking
at
blockchain
about
one
and
a
half
to
two
years
ago,
and
initially
we
started
with
the
public
blockchains.
So
those
of
those
who
don't
know
are
blockchains
are
either
public
or
private,
slash
permissioned
in
public
blockchains.
A
The
very
famous
example
is
bitcoin
and
then
in
private,
if
there
are
a
lot
of
different
options,
but
hydrator
fabric
from
ibm,
which
started
from
ibm,
is
one
of
the
most
popular
one.
So
with
public
blockchain,
there's
a
company
called
bitmain
and
that's
one
of
the
largest
providers
of
mining
tools
in
the
world,
and
we
collaborated
with
them.
They
had
a
system
which
is
shown
here
on
the
right
hand
side.
A
So
this
is
a
tool
from
bitmain
and
then
they
would
use
a
proxy
which
would
take
a
job
from
the
school.
Job
basically
represents
creation
of
a
new
block
on
the
blockchain
and
the
faster
a
pool
can
create
a
new
block
and
it
has
a
higher
chance
of
adding
it
onto
the
blockchain
and
that's
how
this
bitcoin
and
public
blockchains
are
designed.
A
So
it's
very
important
that
you
are
able
to
take
this
job
or
this
new
block,
which
the
pool
is
proposing
and
be
able
to
distribute
it
to
the
end
miners
which
are
going
to
do
the
actual
work.
So
latency
networking
latency
matters
a
lot.
So
we
worked
with
them
on
accelerating
this
part
of
the
system
where
we
took
their
strata
mining
proxy
and
implemented
it
on
an
fpga
system
using
the
zinc
chip
from
xarlinx,
and
we
were
able
to
show
many
orders
of
magnitude
of
improvement
in
latency
and
they
were
able
to
excuse
me.
A
They
were
able
to
test
it
in
their
own
production
system,
and
then
we
published
it
at
the
crypto
valley
conference.
Then
we
moved
on
to
the
private
blockchains.
We
looked
at
hyperledger,
we
started
with
profiling
and
benchmarking
hyperledger
fabric,
and
we
came
to
figure
out
that
there
are
a
lot
of
areas
where
software
is
not
very
fast.
At
the
moment.
There
are
a
lot
of
bottlenecks
which
are
very
suitable
for
hardware
acceleration,
especially
fpgas.
A
A
A
We
have
endorsing
peers
which
basically
take
the
transactions
and
process
them.
There
is
something
called
ordering
service
which
would
create
blocks,
and
then
there
are
some
other
nodes
which
are
non-endorsing
which
only
take
blocks,
and
the
process
does
so.
A
typical
flow
of
how
a
transaction
flows
through
a
fabric
blockchain
network
is
that
a
client
will
generate
a
transaction,
send
it
to
a
number
of
endorsing
peers
and
wait
for
the
endorsements
from
those
peers.
A
So
that
is
kind
of
the
generic
flow
of
our
transaction
goes
to
a
fabric
network
and
in
many
other
permissioned
or
private
blockchains.
The
flow
is
more
or
less
the
same
with
you
know,
minor,
like
minor
changes
here,
and
there
that's
kind
of
the
idea
of
permissioned
networks.
So
there
is
no
proof
of
work
kind
of
algorithms
which
are
typically
used
in
bitcoin
or
proof
of
stake.
Algorithms
are
typically
used
in
public
blocks
and
systems.
A
Okay,
so
let
me
come
to
why
we
did
blockchain
machine
so
when
we
started
looking
at
fabric-
and
we
did
a
lot
of
performance
benchmarking
on
fabric
and
looked
at
a
lot
of
previous
work,
which
was
done
on
it,
which
is
mentioned
here
at
the
one
of
our
papers,
is
also
here.
We
figured
out
that
validation
phase
is
one
of
the
major
bottlenecks
for
the
fabric
blockchain,
and
the
primary
reason
for
that
could
be
broken
down
into
three
parts.
Here.
A
A
The
second
is
that
a
lot
of
block
and
transaction
data
involves
unmarching
of
protocol
buffers.
The
protocol
buffer
is
is
a
serialization
and
a
decentralization
protocol
from
google,
where
you
can
take
some
data
and
then
serialize
it
and
send
it
out
to
any
other
machine
which
can
understand
protocol
buffers
and
they
can
and
the
other
machine
can
then
or
the
other
application
can
then
deserialize
it.
So
that
involved
that
took
a
lot
of
compute
in
the
validation
phase.
A
B
A
Building
hardware
accelerators,
which
are
fpga
based
for
hyperledger
fabric,
and
we
wanted
to
improve
certain
performance
metrics
like
transaction,
throughput
or
block,
and
we
implemented
the
validation,
only
fear,
which
is
slightly
different
from
an
endorsing
period.
In
that
it
only
performs
the
validation
phase.
A
So
there
is
no
need
for
this
data
to
go
all
the
way
to
the
cpu
and
get
processed
in
the
software
and
then
get
sent
back
to
the
to
the
fpga
for
processing.
So
we
bypass
all
that,
and
instead
we
introduced
our
own
custom
protocol
and
we
were
able
to
retrieve
this
data
directly
from
the
interface
of
the
fpga
card.
A
So
the
current
status
is,
we
have
a
proof
of
concept
where
we
have
a
server
with
a
standard
network
interface
card
and
xilinx
lvo
based
network
interface
card.
We
generate
the
blockchain
machine
hardware
using
our
predefined
number
of
transaction
validators.
So
you
can
think
of
this
as
the
number
of
transaction
validators
is
configurable
in
our
system.
So
based
on
the
application,
you
want
to
run
or
multiple
applications.
A
You
want
to
run,
you
can
have
four
transaction
validators
or
eight
and,
and
you
can
have
better
throughput
and
likewise
the
hardware
is
generated
using
a
predefined
set
of
chain
codes.
So
chain
code
is
basically
the
code
which
is
part
of
the
transaction
which
is
executed
during
the
during
the
endorsement
phase,
and
then
it's
checked
back
again
during
the
validation
phase.
A
So
if
you
have
multiple
applications,
they
can
have
different
chain
codes
or
different
business
logic
which
they
are
implementing
through
chain
codes.
And
finally,
we
integrated
this
whole
setup
with
hyperledger
caliper,
which
is
another
project
from
hyperledger.
It's
a
benchmarking
tool.
This
is
a
standard
way
of
benchmarking,
different
hyperledger
projects,
so
we
integrated
our
work
with
that,
so
that
we
can
benchmark
it
in
all
the
experiments,
all
the
testing
we
have
done
so
far.
A
A
A
We
modified
caliper
with
some
of
our
own
internal
with
some
of
our
own
improvements,
and
we
have
written
some
other
scripts
and
automation
tools
around
caliper
to
enable
all
this,
and
for
this
particular
demo,
we
ran
small
bank
benchmark.
This
is
an
application
which
mimics,
which
mimics
banking
application
banking
operations.
For
example.
I
can
create
an
account
I
can
transfer
some
dollars
from
account,
a
to
account
b
and
so
on
and
then
in
the
fabric
network.
A
The
first
peer
is
an
endorsing
peer,
so
it
can
accept
transactions.
It
can
endorse
those
transactions
as
well
as
it
can
validate
blocks
later
after
the
blocks
are
sent
from
the
ordering
service.
The
other
pier
was
only
a
non-endorsing
fear.
It
does
not
do
any
endorsement
of
the
transactions,
but
only
validates
the
whole
block.
So
this
is
how
we
do
the
apple
to
apple
comparison.
So
we
look
at
this
non-endorsing
software
only
clear
and
then
compare
it
with
our
blockchain
machine.
A
Okay,
moving
on
to
the
demo
setup
for
the
blockchain
machine,
we
used
zharling's
lva
u250
board
it's
available
off
the
shelf.
Anybody
can
get
that
blog.
I
can
get
it
board
and
and
then
can
use
it
with
our
solution
and
getting
into
a
little
bit
of
more
details
for
caliper.
This
is
not
really
that
needed
here,
but
just
wanted
to
give
an
idea
that
we
created
six
different
virtual
machines
on
multiple
servers
and
one
of
the
machine.
A
A
A
A
B
A
A
Okay,
so
now
I'm
switching
back
to
the
other
command
line,
where
I
was
running
the
benchmark
from
within
a
virtual
machine,
so
you
can
see
a
lot
of
transactions
being
sent
and
some
of
these
transactions
have
errors.
This
is
this
is
deliberate
because
the
benchmark
is
designed
in
a
way
that
it
would
create
both
good
and
bad
transactions,
and
so
that
you
can
test
the
system
that
works.
A
A
A
A
B
Achieve
about
2
700
2700
transactions
per
second,
the
blockchain
industry
in
organization,
one
was
able
to
achieve
about
46
000
transactions
per
second,
so
this
is
about
15x
and
if
you're
wondering
why
some
of
the
block
latencies
here
are
a
bit
lower
than
these
block
latencies.
So
these
two
pairs
here
on
the
left
hand
side
are
these
are
the
endorsing
tiers
so
recall
they
do
both
on
those
kind
of
incoming
transactions
as
well
as
validation
of
the
entire
block.
But
these
three
pairs
here
are
the
non-endorsing
fears.
B
B
Okay,
so
with
that,
I
am
going
to
sum
up
my
talk
and
give
you
a
bit
of
a
high
level
overview
of
what
our
vision
of
this
blockchain
machine
project
is
so
consider
that
we
have
accelerator
cards
available
from
xilinx
or
any
other
fpga
render.
So
those
cards
are
plugged
into
servers
and
they
form
the
lowest
layer
here
for
the
for
the
hardware,
accent,
reference
cards,
and
then
here
at
the
top,
we
have
different
blockchain
projects
under
hydrolyzer
umbrella.
B
What
it
actually
means
to
work
on
is
that
we
can
look
at
the
transaction
flow
in
every
generic
way,
that
transaction
is
created
and
then
it
gets
executed
and
then
validated
then
gets
found
into
a
blog
and
then
the
blog
gets
validated
and
added
onto
the
ledger
or
the
blockchain,
and
each
of
these
steps
involves
one
or
more
of
either
compute
storage
or
not
working.
So,
for
example,
the
demo
which
I
just
demonstrated
falls
under
this
step.
Four
here.
B
We
definitely
want
to
look
at
other
blockchain
systems,
as
I
mentioned,
hyperledger
base
2,
which
is
based
on
ethereum
without
proof
of
work
or
hyperledger
sawtooth,
which
is
based
on
intel's
sdx
technology.
So
we
would
like
to
look
at
these
other
blocks
and
systems
profile
them
understand
them
better
and
see
if
there
are
any
acceleration
opportunities
in
those
blocks
and
platforms
as
well
and
then.
Finally,
last
but
not
least,
we
are
always
looking
for
collaboration
opportunities
with
other
companies
and
and
other
researchers
from
universities.
B
B
B
B
B
So
that
just
was
a
question
popping
into
my
mind,
but
I
understand
now
it's
just
an
example
for
what
you
were
showing
at
the
beginning,
but
it
wasn't
what
the
presentation
was
about.
My
question
actually
yeah.
My
question
actually
is
about
predefined
chain
chain
code,
but
you
so
you
have
the
accelerator
hardware.
B
It's
actually
can
change
daily.
So
we
define
chain
code
here
is
like
deployed
once
and
installed
on
the
network
or
it
can
on
the
runtime.
I
can
change
the
chain
code
and
then
accelerate
it
on
the
acceleration
hardware
right.
So
that's
a
very
good
question
and
it's
one
of
the
areas
we
are
currently
working
on.
So
yes,.
A
B
B
A
B
B
B
You
can
have
multiple
threads
to
do
that
which
can
process
these
transactions
in
parallel.
So
within
this
single
peer
node
on
a
single
lga
board,
we
have
just
like
that,
multiple
validators
and,
of
course,
if
we
use
more
validators,
we
can
get
better
performance.
We
use
less
number
of
validator
nodes.
We
get
less.
B
B
Architecture
was
deliberately
left
out
of
the
talk
because
it's
company
work,
so
we
are
going
to
first.
You
know
patent
it
of
course,
but
yeah.
We
are
also
going
to
make
it
open
source
in
future.
As
I
said
under
the
hyper,
the
last
project,
but
I
can
give
a
little
bit
of
more
detail
about
about
that.
So
at
this
point
we
do
not
have
any
interaction
with
the
harvest.
The
data
is
is
all
in
memory,
so
it's
an
all
memory
database
right
on
the
fpga
cortical.
B
Yes,
it
is
still,
of
course,
one
of
the
bottlenecks,
even
in
our
system,
but
still
it's
much
much
much
better
and
faster
than
the
cpu
using
the
database
from
its
memory
as
well
as
hardness.
So
you
know
there
are
some.
There
is
a
very
famous
paper
called
flash
fabric
where
they
just
used
where
they
just
assumed
that
the
whole
database
is
residing
inside
the
memory
of
the
cpu
so
and
in
that
case
they
were
able
to
show
that
they
can
scale
fabric
to
about
20
000
transactions
per
second.
B
But
in
our
case,
since
we
can
even
further
optimize
that
even
at
the
clock
cycle
level,
because
I
know
how
many
cycles
it
would
take
to
read
or
write
into
my
databases,
all
of
the
fpga,
so
I
can
even
do
a
bit
of
better
optimization
here.
So
that's
we
have
a
bit
of.
We
have
a
better
improvement
from
that.
The
second
improvement
comes
from
the
fact.
So
in
this
validation
phase,
yes,
database
accesses
are
slow,
but
still
the
major
bottleneck
is
the
cryptographic
operations.
B
The
verifying
signatures
takes
a
long
time
and
on
the
cpu
side,
if,
let's
say
you're
using
intel
silver
xeon
or
the
xeon
gold,
they
have
a
few
number
of
hard
wired
blocks
in
their
cpus,
which
can
do
some
of
the
cryptographic
operations.
But
of
course
you
cannot
scale
that
right
on
top
of
that,
it's
multi-threading.
A
B
I
can
tune
it
much
better
and
I
can
program
it
according
to
whichever
application
I
am
looking
for
on
top
of
it.
So
that's
the
other
part
where
we
gain
much
more
improvement,
because
we
do
both
parallel
and
pipelined
evaluation
of
the
signatures
and
that's
where
most
of
the
improvement
comes
from
and
then
the
database
accesses.
B
B
B
B
A
B
What
we
faced
is
that
the
networking
latency
when
you
distribute
these
kind
of
components
of
the
fabric
is
massive.
So
now
so,
we've
tried
running
the
whole
thing
on
a
single
laptop
running
them
across
the
same
cloud
provider.
Different
cloud
providers,
hybrid
scenarios-
and
you
see
there
like
the
the
the
latency-
is
massive.
So
my.
B
Here
is
that
so,
first
of
all,
so
these
six
vms
that
you
mentioned
now,
where
are
they
located
as
in
if
there
are
kind
of
all
everything
is
happening
on
your
board
or
is
there
any
other
machine?
That's
that's
involved
like.
I
would
like
to
know
a
little
bit
more
about
that.
Thanks
great
question,
yeah.
I
totally
agree
with
you
the
the
moment
you
try
to
go.
Let's
say
you
take
your
vms
and
you
want
to
divide
them
across
wider.
B
But
in
this
particular
case,
because
we
were
focused
on
looking
at
the
validation
phase,
so
we
try
to
avoid
those
issues
with
network
latency
would
be
a
problem
because
otherwise
the
performance
benchmarking
we
are
doing
would
be
diluted
or
would
not
be
representative
of
the
actual
system,
so
our
vms
were
located
in
our
own
private.
I
would
say
cloud,
but
we
have
a
small
setup
of
a
few
different
servers
which
are
connected
to
a
local
area
network
and
our
xilinx
board.
Our
boards
are
also
connected
to
the
same
locality
network.
B
B
B
Right
right,
yeah,
so
so
that's
that's
actually
the
whole
idea
here.
So
even
for
the
blocks
and
machine
shell,
we
have
implemented
most
of
the
core
functionality,
which
is,
let's
say
needed
for
hypothetical
fabric.
But
let's
say
in
future
we
look
at
hyperledger,
they
sue
or
some
other
blockchain
platform
and
figure
out.
Oh,
there
is
something
else
which
could
also
be
a
core
component
and
has
to
be
in
the
machine
shell.
B
Validate
the
and
you
validate
the
transaction
based
on
some
kind
of
a
policy.
So
if
you
remember,
I
mentioned
something
about
two
of
two
endorsement
policy
that
if
this
transaction
has
an
endorsement
from
bank
a
and
bank
b,
then
it's
a
valid
transaction
and
should
be
added
to
the
ledger.
So
that's
one
of
the
plugins.
B
We
would
add
there
that
I'm
implementing
a
two
of
two
understand
policy,
which
would
mean
that
okay,
I
have
a
small,
either
hardware
circuit
there,
or
maybe
a
small
microcoded
engine
there,
which
would
look
at
these
signatures
on
this
particular
transaction
and
then
see
whether
it
satisfies
this
boolean
policy
or
not.
So
that's
one
of
the
examples
that
would
go
into
the
configurability
with
system
accelerator
plugins.
So
that's
an
example
of
that.
The
second
is,
let's
say
the
database
itself.
B
B
And
then
with
the
second
layer,
which
is
like
programmability
with
user
chain
code,
so
user
chain
code
is
like
the
smart
contracts,
the
business
logic
and
for
our
case,
that
was
small
bank.
But
then
again,
ethereum
has
its
own
ethereum
virtual
machine,
which
could
also
be
implemented
in
hardware,
and
then
you
will.
And
then
you
write
your
program
in
a
very
high.
B
B
B
B
B
Doesn't
make
sense
here,
because
this
whole
sequence
has
to
be
done
in
a
single
machine
and
has
to
be
done,
sequentially?
Yes,
you
can
put
10
of
them.
You
know
that
you
will
be
moving
data
around
into
play,
so
most
probably
whatever
benefits
you're
going
to
get,
you
will
lose
them
and
the
second
part
this
is
again,
has
to
be
sequential
or
unless
you
do
some
smart
pipelining
of
this
whole.
B
But
there
are
some
other
parts
where
you
can
put
more
machines
and
then
the
hardware
acceleration
doesn't
make
sense,
for
example,
this
endorsement
here
there
has
been
one
paper
recently
as
well,
and
we
also
believe
the
same
thing
that
we
started
with
both
endorsement
and
validation
for
acceleration
candidates,
but
then
we
looked
at
endorsements.
So
what
happens
in
an
endorsement?
Is
that
you
send
a
transaction
to
appear.
B
B
B
B
And
after
that,
what
is
okay?
So
if
you
look
at
soft,
so
we
don't
know
of
any
inspiration
work
on
hydraulic
fabric
as
of
today,
but
there
are
some
software
optimization
last
year,
so
the
best
numbers
we
have
seen
so
far
is
about
20
000
transactions
per
second
from
state
of
the
art.
So
if
you
compare
that
it's
46
000,
which
we
have
with
minimal
hardware,
so
that
still
would
be
better
than
what
we
have
seen
in
the
software.
B
Of
course.
In
future
we
might
be
doing
some
more
optimization.
This
is
a
product
of
building
the
basic
system
and
in
terms
of
the
second
question,
what
are
the
other
bottlenecks?
So
I
believe
that
once
we
improve
the
publication
phase,
significantly
like
we
have
now
for
and
then,
if
you
test
the
system,
please,
let's
say
sending
in
20
30
000
transactions
per
second,
I
think
the
ordering.