
commit
E
EE
O
V
V
V
block verify
tx verify & vscc
statedb read
& mvcc
1
2
3
validator peerorderersendorsing peersclient
V
idle
idle
Tthreads
tx5
e5
b1
c5
c5
b1
tx5
ledger write
statedb write
historydb write
4
Fig. 1: Transaction flow in Hyperledger Fabric. txN = transaction N, eN =
endorsement for txN, bN = block N, and cN = confirmation for txN. E =
endorsement, O = ordering, and V = validation phases.
many diverse domains such as supply chain, banking/finance,
healthcare, etc. Figure 1 depicts how a transaction flows
through various nodes of a Fabric network (e.g., endorsing
peers, validator peers, etc. shown on the top).
A client invokes a transaction by sending it to endorsing
peers. Each endorsing peer will simulate the transaction by
computing its input and output (read and write sets) against the
locally stored state database1. Afterwards, the endorsing peer
will send the simulation results along with its digital signature
back to the client. Once the client has enough endorsements,
it will send the transaction along with the endorsements to the
orderer for inclusion into a block. The orderer will create a
new block and broadcast it to all the peers for validation and
subsequent commit to the ledger. Note that each transaction
contains the digital signature of the client that invoked it, while
each block contains the digital signature of the orderer that
created it. In Fabric, all digital signatures are based on Elliptic
Curve Digital Signature Algorithm (ECDSA) scheme.
The validation and commit phase itself consists of several
operations as shown on the right hand side of Figure 1. When
a validator peer receives a block, it will first check the syntax
of the block and verify the orderer’s signature on the block
(step 1). Then, the validator peer will check the syntax of
each transaction in the block and verify the client’s signature
on each transaction (tx verify in step 2). Afterwards, for each
transaction in the block, the signatures of endorsing peers from
the transaction’s endorsements will be verified and evaluated
against an endorsement policy2(validation system chaincode,
shortened as tx vscc in step 2). If the endorsement policy is
satisfied, then the transaction is marked as valid.
In step 3, multi-version concurrency control (shortened as
mvcc) checks are applied to mark a transaction as valid/invalid.
Once the entire block has been validated in steps 1–3, in
step 4, the validator peer will commit the block to its ledger,
1The state database contains the current snapshot of the ledger. For example,
for a banking application, it would contain the current value of each account.
2An endorsement policy is associated with a smart contract/chaincode, and
governs the business logic for approval of the transaction; e.g., policy of a
money transfer chaincode between two banks may require valid endorsements
from each bank, i.e., endorsements from Bank1 AND Bank2.
SERVER
FPGA Card
System Configuration
CMAC Subsystem
User Logic Box
@322 MHz
User Logic Box
@250 MHz
Packet Adapter
QDMA Subsystem
AXI-Lite 125MHz
AXI-Stream
322 MHz
Ethernet Port
CPU
PCIe
AXI-Stream
250 MHz
Fig. 2: Overview of OpenNIC shell. The Blockchain Machine hardware is
part of User Logic Box @ 250MHz.
and update its state database (by applying write sets of valid
transactions) and history database (for book keeping). Note
that validator peers only validate and commit incoming blocks,
while endorsing peers do the same in addition to endorsing
incoming transactions.
The vanilla Fabric validator peer incorporates many soft-
ware optimizations for improved throughput. For example, it
uses multiple threads to verify and validate multiple transac-
tions of a block in parallel (taking advantage of multi-core
servers), which is depicted as T threads in Figure 1. Another
software optimization is to use block cache which caches
unmarshaled contents of a block for subsequent accesses, and
has been reported to improve throughput significantly (2.33×
in [4] and 1.67×in [5]). However, block cache is not yet part
of the official Fabric codebase, so we implemented it ourselves
in Fabric v2.2 LTS to evaluate its energy efficiency.
B. Blockchain Machine
Javaid et al. [6] proposed a hardware accelerator called
Blockchain Machine (BMac) for improving validator peer’s
throughput, instead of relying on software optimizations. The
BMac peer is designed for a multi-core server with a network-
attached FPGA card (connected to the CPU via PCIe bus),
where the CPU runs modified Fabric software while FPGA
card is programmed with the hardware accelerator. Since this is
the only hardware accelerator proposed for Hyperledger Fabric
so far, we use it as the CPU+FPGA system in this paper.
Figure 2 provides a simplified overview of the open-
sourced OpenNIC shell [7], which is the basis for BMac
hardware. The OpenNIC shell is an FPGA based NIC shell for
AMD/Xilinx FPGA cards and provides network connectivity
through CMAC/Ethernet port interfacing and CPU connectiv-
ity through QDMA/PCIe interfacing. Consequently, a user-
defined accelerator can be implemented inside the user logic
box where it can access incoming data from the network
through CMAC/Ethernet port while the CPU can access the
output of hardware accelerator through PCIe/QDMA.
The BMac hardware is implemented as user logic box @
250MHz, as shown in Figure 3. The blocks are received in
FPGA card through the CMAC interface. The first module,
protocol processor, processes the incoming Ethernet packets
and extracts relevant data, such as block id, transaction ids,
ECDSA signatures, etc. The second module, block processor,
uses this data to validate the block and its transactions,
commits all valid transactions, and then writes the validation
results in a register map (for CPU access through QDMA).
2