PharmaLedger – Blockchain platform research

This project has received funding from the Innovative Medicines Initiative 2 Joint Undertaking under grant agreement No 853992. This Joint Undertaking receives
support from the European Union’s Horizon 2020 research and innovation programme and EFPIA.
Copyright © PharmaLedger Consortium 2020 – 2023 PharmaLedger: www.pharmaledger.eu IMI: www.imi.europa.eu
D3.3 Blockchain platform research
Deliverable No D3.3
Work package No. and Title WP3 Architecture and Reference Implementation
Version - Status V1.0 - Final
Date of Issue January 2021
Dissemination Level Public
Filename D3.3 Blockchain platform research
Ref. Ares(2021)2766629 - 26/04/2021

PharmaLedger – 853992 | Deliverable D3.3. v1.0 |PUBLIC 2/92
DOCUMENT INFO
Authors
Authors Organization
Zeev Pritzker (editor) AVO
Nikolaos Liappas UPM
Miah Raihan Mahmud A. TVS
Christos Patsonakis CERTH
Luís Miguel Campos PDM
Contributors Organization
Sinica Alboaie RMS
Marco Cuomo NVS
Andreas Wegner BAY
Anastasia Theodouli CERTH
Flora Nanda Pfizer
Bogdan Mastahac RMS
Michael Sammeth UKW
José G. Teriús UPM
Victor G. Dominguez UPM
Cecilia Vera UPM
Espen Kon EKN
Carlos Marques PDM
Tiago Venceslau PDM
João Luís PDM
Lino Estêvão PDM
Luís Landeiro Ribeiro PDM
Miguel Coelho PDM
Nuno Pedrosa PDM
Nuno Costa PDM

Document History
Date Version Change Status
April 2020 r02 Initial draft
April 2020 r05 Partner contributions
October 2020 r09 Initial research results incorporated
November 2020 r13 Final research results incorporated
November 2020 r16 Comparison, conclusions and recommendations
December 2020 r17 Final version
January 2021 V1.0 Final version - reviewed
Acronyms
ASIC Application-specific integrated circuit
BFT Byzantine fault tolerance
CFT Crash fault tolerance
DLT Distributed Ledger Technology
DoS Denial of Service
DPOS Delegated proof of stake
HL Hyperledger
HLF Hyperledger Fabric
IDE Integrated development environment
JVM Java Virtual Machine
PoS Proof of Stake
PoW Proof of work
TEE Trusted Execution Environment
TPS Transactions per second
UTXO Unspent transaction outputs
Disclaimer: Any information on this deliverable solely reflects the author’s view and neither IMI nor the European
Union or EFPIA are responsible for any use that may be made of the information contained herein.

Executive Summary
Ethereum, Quorum, Hyperledger Fabric and Corda blockchains were studied based on a broad survey of
literature, while focusing on major parameters that may affect their choice as building blocks in
PharmaLedger’s hierarchical multi-blockchain architecture. Among other things, such parameters include
governance, network and data structures, consensus protocol, transaction rate/throughput, security,
modularity, ease of deployment, software engineering, costs and industrial adoption.
The results were put into a useful perspective for the PharmaLedger project by referencing and
incorporating results achieved in the parallel Use Cases, Governance and Architecture research efforts.
The reported research is followed by a comprehensive comparative assessment of the blockchain
technologies in this complex multi-parameter space. The comparison, along with the raw research data, is
followed by conclusions and recommendations as to the potential use of the surveyed DLT technologies in
the implementation of blockchain-based functionalities of PharmaLedger, to assist the designers of
PharmaLedger platform and use cases in architectural and implementation decisions.

Table of Content
Executive Summary ...........................................................................................................................4
1. Overview and relation to other work in PharmaLedger project....................................................6
2. Blockchain platform characteristics ............................................................................................6
2.1 Membership and governance.........................................................................................................6
2.2 Network and data structures..........................................................................................................7
2.3 Consensus protocol and performance............................................................................................7
2.4 Security, privacy and confidentiality.............................................................................................11
2.5 Software engineering....................................................................................................................15
2.5.1 Development.........................................................................................................................15
2.5.2 Deployment and monitoring.................................................................................................16
2.6 Commercial and business aspects ................................................................................................16
2.7 Industrial adoption and use cases ................................................................................................17
3. Comparative assessment..........................................................................................................17
4. Conclusions and recommendations...........................................................................................23
Appendices: Blockchain platform assessment studies.......................................................................24
A1. Ethereum.................................................................................................................................24
A2. Quorum ...................................................................................................................................41
A3. Hyperledger Fabric...................................................................................................................56
A4. Corda.......................................................................................................................................85

1. Overview and relation to other work in PharmaLedger project
The purpose of this study and report is to review some of the main existing blockchain technologies in
order to assist in the design of architecture of PharmaLedger - an open blockchain platform for healthcare
industry. PharmaLedger’s flexible, technology-neutral architecture supports a hierarchical multi-
blockchain structure as described in the PharmaLedger Framework Architecture document1
. Among other
things, the architecture allows each use case to be implemented on a separate, independent blockchain,
with different use cases using different blockchain technologies. Moreover, a fundamental design principle
of PharmaLedger is that applications are blockchain-agnostic, allowing for switching each use case to a
different blockchain technology in the future, without modifying the application code1
.
The blockchain research work reported in this document was performed in the first 12 months of the
PharmaLedger project. The document provides insights into characteristics of three distributed ledger
technologies: Ethereum/Quorum, HyperLedger Fabric and Corda – with a view to assist PharmaLedger
application designers to assess the potential use of these blockchains in implementation of applications
and use cases. Moreover, since in PharmaLedger every blockchain except the root blockchain has a parent
on which its data is anchored, this document will also assist the designers to select the DLT technology for
the “anchoring” blockchains and the root blockchain.
As such, this document will serve as an input to Work Package 1 (Requirements & Business Use Cases), and
in particular to the definition of technical requirements of the PharmaLedger use cases2
, which should take
the capabilities of existing blockchains into account.
The structure of this document is as follows. Section 1 contains this overview and the description of relation
to other work performed in the PharmaLedger project. Section 2 describes the key aspects and parameters
of the researched DLT technologies and their meaning and importance to PharmaLedger. Section 3
provides the results of comparative assessment of the researched blockchains, based on dedicated studies
of each of them that are attached in Appendices 1~4. Section 4 provides conclusions and
recommendations to PharmaLedger designers.
2. Blockchain platform characteristics
2.1 Membership and governance
Business blockchains often serve as collaboration platforms for business networks. A business network is
an association of business entities that collaborate to achieve their strategic goals. Such collaboration can
be tight or loose, depending on the purposes of the business network. Typically, business networks – and
the underlying enabling blockchain networks – are permissioned, which means that access to them and to
the services that they provide must be granted by a body that governs the blockchain.
The permissioned nature of business blockchains implies the existence of a governing entity which - among
other things – vets the potential members and grants them access to the blockchain. This requires a set of
rules and criteria based on which membership in/access to the blockchain is granted. Moreover, several
membership levels are possible. For example, some members may be granted the right to certain services
provided by the blockchain network, without participating in network governance, while other members
are granted rights to participate in the governance.
1
Deliverable D3.1 – PharmaLedger Framework Architecture, PharmaLedger project (work in progress)
2
Deliverable D1.3 – Definition of technical requirements, PharmaLedger project

The various PharmaLedger governance model options are described in deliverable D4.13
. The
recommendations for the governance model to be adopted by PharmaLedger are work in progress and will
be described in the upcoming deliverable D4.24
.
Ethereum and Quorum are similar networks in technical terms as Quorum has been forked by the public
Ethereum network. However, both networks can operate as private permissioned networks.
Hyperledger Fabric on the other side was designed specifically as a private and/or permissioned blockchain
system. It offers versioned smart contracts (through the “chaincode”) and does not offer on-chain
governance features (although they are available in other HL projects). As an open-source project, the
technical decisions are being made by a specific group of community elected people (similar upgrade
techniques apply to the Ethereum projects with the improvement proposals).
Corda blockchain is a permissioned network that operates with an open governance model which
represents the users’ choices of how to manage and update the parameters of the network, agree on rules
for the issuance of identity certificates and set common standards for notary consensus pools.
2.2 Network and data structures
When adopting a blockchain based network, the following parameters architecture need to be considered:
• Blockchain structure (multi-blockchain/side/child chains, sharding, single chain etc.)
• Modularity/plug-ins (such as consensus alg., identity system etc.)
• Support of connection of off-chain storage systems and databases (IPFS, swarm etc.)
• Transaction storage structures (UTXO, key-value, account-based etc.)
• Global state storage structures
Ethereum and Quorum have similar network and data structures. Both of them use and account/balance
model which offers simplicity in the smart contracts as opposed to the UTXO models, and operate as a
single blockchain. Two types of accounts exist: user accounts and smart contract accounts. In both
blockchains Merkle Patricia Tries are used for storage (key, value) of all bindings on the network.
Hyperledger Fabric exploits a multi-blockchain model that does not provide sidechaining nor token support
for child ledgers. In regard to modularity and plugins, Fabric has an open smart contract model (flexibility
to implement and plug any model: account/balance model, UTXO model, structured data, etc.) and flexible
data isolation using channels. Fabric is capable of Swarm distribution model but does not support IPFS or
BigchainDB. In Fabric, each node maintains its own copy of the ledger consisting of two parts: world state
and the blockchain itself.
Corda also uses a multi-blockchain approach. It has support of different plugins and off-chain solutions.
Corda is designed from the ground up to support a global network of smaller business networks, with
transactions communicated peer-to-peer. Design of complex data structures is possible using Java (or any
other JVM compatible language).
2.3 Consensus protocol and performance
The type of consensus protocol will dramatically affect the performance of the blockchain network and
the level of trust between users. The following performance parameters need to be considered when
choosing a blockchain network:
● Type of consensus
● Rate of transactions per second (TPS)
3
Deliverable D4.1 - Report of the governance options, PharmaLedger project
4
Deliverable D4.2 - Recommendation report for PharmaLedger governance, PharmaLedger project (work in progress)

● Resilience to faulty network conditions
● Time to finality of transaction
● Scalability (how the number of nodes affects TPS)
● Storage scalability (how the number of data items stored could degrade performance to
unacceptable levels)
Ethereum currently operates with a PoW consensus (Ethash algorithm5
, evolved to be ASIC-resistant with
memory hardness6
) while Quorum has consensus options that are more appropriate for private business
networks, such Raft7
and Istanbul BFT8
. The consensus parameters can affect the performance of
blockchains.
Ethereum and Ethereum-based private networks demonstrate a high variance of TPS in different setups of
the network. Transaction rates as high as 284 TPS and as low as 0.2 TPS have been reported. The TPS rates
are affected by parameters setup such as block frequency, block size, network size, etc. A typical Ethereum
private network with 10 nodes can achieve an average of 124.1 TPS with the following parameters:
The authors of the above experiment9
conclude that a higher number of nodes does not take full advantage
of available resources. There is a match 90-100% for small network sizes but in the larger setups the
numbers vary. This is a scalability-limiting factor for the current Ethereum PoW algorithm. The network is
considered safe, resilient and decentralized enough to keep the miners running at an acceptable level of
trust. Time to finality is considered to be adequate for private networks and also depends on setup
parameters (average time can be 1 minute). Furthermore, increasing the number of nodes will not provide
a higher TPS as the PoW consensus limits scalability.
Quorum as a fork of Ethereum has similar network constraints and is resilient to faulty network conditions.
However, its consensus protocol can achieve faster block times and is scalable for enterprise networks. It
provides an average of 100 TPS transaction rate. The main difference between Ethereum and Quorum is
the consensus algorithm. Quorum has better choices of consensus algorithms for enterprise networks and
5
https://eth.wiki/en/concepts/ethash/ethash
6
Rudlang, Marit (Jun 2017). Comparative Analysis of Bitcoin and Ethereum (PDF). Norway: NTNU: Norwegian
University of Science and Technology. pp. 52–53
7
“Raft - GoQuorum,” docs.goQuorum.consensys.net. [Online]. Available:
http://docs.goQuorum.com/en/latest/Consensus/raft/raft/
8
“IBFT - GoQuorum,” docs.goQuorum.consensys.net. [Online]. Available:
http://docs.goQuorum.com/en/latest/Consensus/ibft/ibft/
9
Schäffer, M., Di Angelo, M. and Salzer, G., 2019, September. Performance and scalability of private Ethereum
blockchains. In International Conference on Business Process Management (pp. 103-118). Springer, Cham.
Table 1 Performance of Ethereum-based blockchains

the network is more scalable. Ethereum requires onerous fine-tuning to find the optimal conditions for
each network setup. The following figure presents the bottleneck hierarchy in the Ethereum network.
When operating a network at its limits, the bottom parameters (e.g., block size) reduce performance even
before the reduction at a network level (e.g., more nodes do not increase performance significantly). This
is a design flaw in the current version of Ethereum.
Hyperledger Fabric demonstrates better TPS performance than Ethereum and Quorum. In a study10
, the
authors provide an elaborate analysis that provides a breakdown of latency and throughput based on
transaction arrival rate (submission rate essentially) in a network composed of 8 peers and 1 orderer11
:
Hyperledger Fabric might not be a good candidate when network conditions are not very well handled. HLF
is a permissioned blockchain network whose transaction/block finality guarantees are much stronger than
the ones provided by public, permissionless blockchains, such as Bitcoin and Ethereum. More specifically,
when a new block is created by HLF's ordering service, it is considered final. This is in contrast with
blockchains where several (typically 6) blocks need to be mined on top of the current block for it to be
considered final with a high probability. HLF has two parameters that affect transaction/block finality. First,
10
Thakkar, Parth, Senthil Nathan, and Balaji Viswanathan. "Performance benchmarking and optimizing Hyperledger
Fabric blockchain platform." 2018 IEEE 26th International Symposium on Modeling, Analysis, and Simulation of
Computer and Telecommunication Systems (MASCOTS). IEEE, 2018.
11
https://hyperledger-Fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html
Figure 1 Ethereum's performance bottleneck hierarchy
Figure 2 Latency and throughput of Hyperledger Fabric

batchTimeout, a temporal parameter (default value is 2s) based on whose value orderers wait before
assembling all the transactions that they have accumulated into a new block and, subsequently, initiating
the consensus protocol. Second, batchSize, which, as its name implies, defines for how many transactions
orderers should wait before producing a new block. The effect of batchSize on transaction throughput (and
as an extension to their finality), is presented in the following table:
In HLF, the message complexity of consensus algorithms is quadratic to the number of nodes, hence, as the
number of peer nodes increases, the throughput of the consensus algorithm degrades. In this study12
, the
authors perform similar experiments, albeit on multiple blockchain platforms. The results of their
experiments are presented below:
Corda blockchain operates at transaction rates between 15 and 1680 TPS, depending on transaction
definition. Enterprise version is required for higher performance, enabled by multi-core usage. The
following figure provides examples of TPS dependence on the number of CPU cores:
12 Nasir, Qassim, et al. "Performance analysis of Hyperledger Fabric platforms." Security and
Communication Networks 2018 (2018).
Table 2 Effect of Orderer BatchSize on Hyperledger Fabric’s transaction throughput
Figure 3 Effect of number of nodes on transaction rate

Corda is highly resilient to faulty network conditions. A typical time to finality for Corda is less than 5
seconds. Transactions are processed peer-to-peer, so the number of nodes has no significant effect on TPS.
The network TPS will improve as the number of nodes grows, since more nodes can be involved in different
transactions, peer-to-peer. Database table space usage is around 10KB per state with an additional 10KB
per transaction. So, a transaction with 3 output states would use 10KB + (3 x 10KB) = 40KB of storage. It is
important to note that while Corda has a good scalability, the open-source version is limited in performance
and only the enterprise version can enhance scalability by using multiple CPU cores.
2.4 Security, privacy and confidentiality
Security, privacy, and confidentiality are important factors to consider when choosing a blockchain for a
business network. The following factors should be considered:
• Fault tolerance of the consensus protocol
• Privacy (transaction-level – hiding transactions from all but the involved parties)
• Pseudonymity – reader of the blockchain cannot determine the identity of transacting parties
• Masking of specific transaction fields
• Centralized points of potential security failure, such as web access gateway to the blockchain]
• Censorship resistance (preventing attackers from causing the network to function correctly)
• Vulnerability to other attacks and dependence on vendor-specific hardware extensions.
PoW, PoS and DPoS belong to the probabilistic finality protocols (which means that a possible attack is
feasible when someone holds over 50% of the computation power in PoW or more than 50% of the stake
in PoS-powered networks). This attack would give the attacker access to create a longer chain and perform
a double-spend attack.
Figure 4 Dependence of Corda transaction rate on number of CPU cores at the nodes

Ethereum that currently uses PoW requires 50% of the computational power of the network to perform a
double-spend attack. All Ethereum data is public. Transactions and smart contracts can be viewed by
anyone as Ethereum does not support private transactions or private smart contracts. However, there exist
unofficial techniques such as mixing contracts13 14
, which have similar properties to Monero’s ring
signatures mixes and can hide transactions. Ethereum enterprise supports private transactions through
modified clients such as Hyperledger Besu15
or using additional components such as Orion16
.
Quorum uses either Raft-based consensus17
, which belongs to the Crash Fault Tolerance category of
algorithms, or Istanbul BFT18
which is a Byzantine Fault Tolerance algorithm. A Quorum Raft network can
tolerate f faulty nodes where n=2f+1 is the number of network nodes, while an IBFT network can tolerate
f faulty nodes in n=3f+1, where n is the total number of nodes. Quorum uses a technique called
‘constellation’, a peer-to-peer encrypted message exchange, for transferring private data between
network participants. It supports both private transactions and private contracts. In addition, it supports
node/peer permissions using smart contracts which helps to ensure that only known parties join the
network. Private transactions are possible in Quorum and they are hidden from the other users. Quorum
allows private transactions between network participants privately, with transaction seen only by a group
of participants - this feature is called field masking. A point-to-point peer to peer communication for this
purpose that allows sending data from node to node, called/provided by Constellation. The data is verified
on the blockchain using its hash.
Ethereum and Quorum do not have any significant centralized points of failure and they are censorship
resilient when they operate with a considerable number of nodes (a prior analysis is required to find the
optimal parameters for the network to be considered safe, decentralized and resilient). Ethereum
architecture can be divided into four layers: the network layer where the node discovery and propagation
are happening, the consensus layer, the data layer where the transactions and blocks are created, and the
application layer consisting of the Ethereum Virtual Machine, accounts and smart contracts. Studies reveal
that vulnerabilities exist on all levels of this architecture, including flaws in smart contract programming,
the Solidity framework and the overall Ethereum design based on PoW consensus. In the following figure,
the authors19
provide a classification of the possible vulnerabilities someone can encounter in the
ecosystem.
13
https://libsubmarine.org/
14
https://github.com/blackyblack/laundromat
15
https://www.hyperledger.org/use/Besu
16
https://github.com/PegaSysEng/orion
17
“Quorum,” Chainstack documentation. [Online]. Available: https://docs.chainstack.com/blockchains/Quorum.
[Accessed: 31-Aug-2020]
18
“Quorum,” Chainstack documentation. [Online]. Available: https://docs.chainstack.com/blockchains/Quorum.
[Accessed: 31-Aug-2020].
19
Chen, H., Pendleton, M., Njilla, L. and Xu, S., 2020. A Survey on Ethereum Systems Security: Vulnerabilities, Attacks,
and Defences. ACM Computing Surveys (CSUR), 53(3), pp.1-43.

The filled black box indicates that the vulnerability is already fixed, the empty box indicates that it is not
yet resolved and the half box indicates that this vulnerability can be avoided. Furthermore, this research
provided a relation between vulnerabilities, attacks and the consequences of them. The following picture
shows the taxonomy of these vulnerabilities:
Figure 5 Classification of vulnerabilities of the four layers of Ethereum-based blockchains

These taxonomies can be used to find and classify vulnerabilities in other blockchains that derive from
Ethereum such as Quorum and Hyperledger Besu. Finally, Ethereum and Quorum do not rely on specific
hardware Trusted Execution Environments (TEE). Approaches of blockchain utilizing TEEs are working
better when consensus decisions are final and not probabilistic (e.g., Hyperledger Fabric).
Unlike the Ethereum-based blockchains, Hyperledger Fabric has an ordering service that decouples
consensus on the order of transactions from execution of transactions and ledger updates. This service is
handled by a modular component which can use different consensus protocols depending on the trust
assumptions of each particular deployment20
. Such protocols allow for crash fault-tolerance (e.g., based on
the Raft protocol21
), or Byzantine fault tolerant ordering. HLF supports private transactions by adopting a
channel architecture in which participants of the network form subnetworks whose members only have
access to particular sets of transactions. For anonymity and unlinkability purposes, HLF uses Identity Mixer
(Idemix), a cryptographic protocol suite that provides strong authentication along with privacy-preserving
features such as anonymity and unlinkability. Current limitations of Idemix are that organisations cannot
endorse chaincode, there is a fixed set of attributes, revocation is not supported, and peers do not use
Idemix for endorsement. Furthermore, to support field masking, there are packages (e.g., bccsp) that
20
HLF Introduction: https://hyperledger-Fabric.readthedocs.io/en/release-2.2/whatis.html
21
Ongaro, Diego, and John Ousterhout. "In search of an understandable consensus algorithm (extended version)."
Retrieved July 20 (2016): 2018.
Figure 6 Taxonomy of vulnerabilities of Ethereum-based blockchains

enable encryption of values stored in the state22
. Fabric can have a centralized point of failure but this is a
moot point in the community. There is a debate on whether the ordering service of HLF is centralized and
whether many organisations can run ordering nodes within an HLF network.
An analysis of vulnerability of HLF to specific attacks and of possible mitigation strategies was performed23
.
Since the identity of an endorser is known to all the members of a channel, a DoS attack may be performed
on the endorser with an aim to either block transactions or degrade network efficiency. Moreover, HLF is
prone to wormhole attack, i.e., compromising a member in a channel leads to leakage of ledger information
for all the members to everyone outside of the channel. For the former vulnerability, the authors propose
a random verifiable function to randomize endorsers, or pseudonyms to anonymize endorsers. For the
latter vulnerability, they used anonymization of the sender and receiver identity within the channel. For
sender identity, they proposed a group signature approach, while for the receiver identity they used a zero-
knowledge approach. Finally, Fabric can execute chaincode in Intel SGX as a hardware specific environment
but this is not a prerequisite for the network to operate.
Corda has a highly fault tolerant consensus protocol. Assets stored in the Corda ledger are tagged with the
consensus service that will governs them. A high value asset might be tagged by a multi-part Byzantine
fault-tolerant consensus pool. Updates to an ephemeral document managed by several firms who trust
each other might be confirmed by a crash-fault tolerant cluster operated by the firms themselves. The
transactions are visible only to the interested participants. However, validity can be evaluated by different
parties with limited access to transaction data. Transaction participants can see everyone involved. Corda
offers field masking modules and has no centralized points of failure. All the transactions are peer-to-peer
which provides a high resilience to attacks. In addition, Corda was designed to send data (and be visible)
only where it is needed. A limitation of the Corda blockchain is that extra steps are required to publicly
validate the entire transaction history.
2.5 Software engineering
A comprehensive software engineering environment and toolsets for developing blockchain applications
is of paramount importance. The following sections list the key issues to be considered.
2.5.1 Development
Both by Ethereum and Quorum support use of Solidity. In addition, Ethereum supports the Vyper language,
while HLF uses its own smart contract technology, chaincode. In Hyperledger Fabric, contracts can be
written in node.js, Java and Go. Corda supports any language that targets Java virtual machine (Java, kotlin,
etc.).
All of the above software frameworks are frequently updated. The four blockchain technologies are Turing
complete (except Vyper in Quorum). While Ethereum, Quorum and Fabric allow limited data model
flexibility, Corda maintains custom assets that can aggregate written data.
A wide variety of libraries exist, notably:
• for Ethereum: web3.js and OpenZeppelin
• for Quorum: web3.js and Quorum.js
• for Hyperledger Fabric: Fabric chaincode go (Shim for Go), Fabric protos go (Peer for Go), Fabric-
shim (npm package for Node.js) and Fabric chaincode contract (package for Java)
22
How to Build an End-to-End encryption in Hyperledger Fabric: https://www.skcript.com/svr/end-to-end-
encryption-hyperledger-Fabric/
23
Andola, N., Gogoi, M., Venkatesan, S., & Verma, S. (2019), vulnerabilities on Hyperledger Fabric. Pervasive and
Mobile Computing, 59, 101050.

• for Corda: any libraries available for JVM (namely, Java libraries and derivatives).
A large number of IDEs exist for the above. For details, please see the Appendices.
The above technologies are mature and are constantly evolving, especially Ethereum that has been in
operation since 2015 and is currently moving to a Proof of Stake consensus protocol and is supported by
several major communities. Quorum also has dedicated communities.
Hyperledger Fabric contains documentation is maintained by Hyperledger Fabric Team, including a GitHub
repository for sample network deployment or smart contract development and deployment, as well as
community initiatives where users can express their individual perspective. IBM provides support to
facilitate smart contract development and debugging as well as paid Hyperledger Fabric Developer /
Administrator courses.
The documentation presented on all these technologies is extensive and detailed.
2.5.2 Deployment and monitoring
Ethereum, Quorum and Corda are user-friendly in terms of deployment and monitoring, including support
by many tools, documentation and large communities. Ethereum tools to monitor health and status of the
network include both integrated tools (eth-netstats, eth-net-intelligence-api) and llibraries (Alethio, Scout,
neofund, etc). Dedicated blockchain explorers exist for Besu, Quorum and Ethereum.
On the other hand, there is no easy way to deploy a Hyperledger Fabric network as deploying a production
grade network requires intimate knowledge of a variety of technologies (Kubernetes, Docker, Linux to
name a few). We are not aware of tools to monitor network status for Corda.
2.6 Commercial and business aspects
The following key business and commercial aspects of blockchains should be considered:
● Licensing model
● Vendor lock-in
● Costs of use
● Developer costs
● Administrative costs
● Transaction fees
● Support of tokens
● Support of on-chain governance
Ethereum is open source and free software and there are no requirements for copyright. Since it is
community-maintained, there are no additional costs to developers. Extensive token standards exist:
ERC20, ERC721, ERC223, ERC777 and ERC-820. Quorum has similar properties and is licensed under GPL /
LGPL 3.0.
HLF is open-source free software available under Apache 2.0 license. Developers might incur
maintenance/support and network management costs. HLF supports tokens and more specifically the
FabToken introduced in Fabric 2.0.
Corda is open-source software with an enterprise edition available. There are no developer costs but the
network operates with transaction fees of $0.01 per transaction with yearly plans available. It supports
tokens as well. The annual fee for a segregated network in both Pre-Production and Production is $10,000
per year. This includes running a network map and a certificate issuance service. One must run its own
notary in a segregated network.

2.7 Industrial adoption and use cases
Adoption of specific blockchain technologies by existing business networks is an important criterion in
selecting a blockchain for the implementation of a use case. The three main points to be considered are:
● Adoption by major players in the industry. This significantly reduces the technological, financial
and take-up risks.
● Proven production deployments. Production deployments will indicate maturity of the use of
blockchain technology as an open standard and ability to empower companiesovercome practical
implementation hurdles.
● Features optimized for specific industries and use cases, such as banking and supply chain
management.
Ethereum serves as a platform for multiple private blockchain networks in the industry, with the support
of Enterprise Ethereum Alliance24
.
Quorum is currently used in different industries such as Banking and Finance, Insurance, Supply Chain
Media and Entertainment, Oil and Automotive.
Hyperledger Fabric was adopted by prominent companies including IBM, Walmart, Intel and Cisco. It has
been adopted in applications and sectors such as Supply Chain Management, Distribution, Shipping and
Logistics, Legal, Healthcare, Retail, Financial Services.
Major banking companies are in advanced stages of conducting trials with Corda.
3. Comparative assessment
We have researched all the parameters and characteristics listed in section 2 for four existing DLT
frameworks. The research reports are contained by the following appendices:
• Appendix A1: Ethereum (p. 24)
• Appendix A2: Quorum (p. 41)
• Appendix A3: Hyperledger Fabric (p. 56)
• Appendix A4: Corda (p. 85)
Table 3 contains a preliminary comparison of the above blockchain frameworks according to the above
criteria and characteristics.
24
https://entethalliance.org/

Table 3 DLT comparison summary
Feature/characteristic Ethereum Quorum Hyperledger Fabric Corda
Membership Public/permissionless Private/permissioned Private/permissioned Public but, for business
networks formed over Corda,
permissioned
Technology governance Open source/community Open source/community Open source/community Open source/community
Business network
governance
none Business network driven Business network driven Representative Corda
governance body managing
the global network
parameters, identities and
standards for notary
consensus pools
Advantages extensive community support
extensive toolset
proven, mature (5 years in
production)
frequently upgraded
Enterprise Ethereum Alliance
Transaction privacy
Extensive toolset inherited
from Ethereum
Strong privacy, facilitates
implementing enterprise rules
Pluggable consensus
Well suited for forming
business networks that
operate under common
agreements; privacy within a
transacting group of entities;
global standards for
communication and
transactions between parties
belonging to different
business networks; high
scalability
Limitations Scalability issues, high
computational cost of POW
consensus
Channel-based privacy
approach limits scalability for
complex use cases
Prone to wormhole and DoS
attacks on endorser nodes
Idemix anonymization
protocol has a number of
limitations
The open-source version is
limited in performance, since
only the enterprise version
can use multiple cores.

Type Single blockchain + smart
contracts
Single blockchain + smart
contracts
Multi-blockchain (with
channels)
Single blockchain with app-
defined business networks
that are distinct but may
overlap
Consensus PoW, awaiting transition to
PoS. Private Ethereum
(Hyperledger Besu has Clique
Proof-of-Authority)
Raft (with crash fault
tolerance), Istanbul BFT,
Clique proof of authority
BFT, CFT (SOLO, Apache Kafka,
Raft)
Permissioned/voting based
Separate endorsement,
ordering, validation consensus
Pluggable consensus on
uniqueness/ordering of
transactions by validator pools
Finality ~5-60 min, probabilistic in the
public ledger. Private
networks should achieve a
much shorter time to finality.
Immediate finality with 1
second block time
Less than 5 sec time to finality
Transaction rate (TPS) 0.2 < TPS < 284 700-800 ~1000 Depends on
architecture/notary pools and
transaction definition. Can be
very low, and up to 1680.
Modularity/plugins Extensive Highly modular Highly modular (pluggable
consensus; channels)
Modular, plugins
Connection to offchain
storage and DBs
IPFS, Swarm, INfura, 3Box
storage
IPFS, Swarm, INfura, 3Box
storage
Dedicated store at each node
Swarm distribution possible
Transaction storage
structures
Account based Account based Flexible: account, UTXO,
structured, unstructured etc.
“states” consumed and output
by transactions. States refer to
state of agreements/smart
contracts

Global state storage
structures and update
procedures
Merkle Patricia Tries Modified Merkle Patricia
Tries
Ledger consists of global state
and blockchain
CouchDB and LevelDB
supported for state store
“states” consumed and output
by transactions. States refer to
state of agreements/smart
contracts
Resilience to attacks high High No clear indication High
On-chain storage
capabilities
none None Dedicated store at each node Nodes store the relevant
states
Network bandwidth 250 GB/month (public). Not
available data for private
setups
N/A In the highest throughput
scenarios between 500 and
600Mbit/s outbound network
traffic at a node
Consensus protocol fault
tolerance
50% comp. power for PoW,
>50% for PoS
Number f of faulty nodes that
can be tolerated (n – number
of network nodes):
f=(n-1)/2 (Raft)
f=(n-1)/3 (Istanbul BFT)
Raft, BFT A high value asset might be
tagged with a multi-node
byzantine fault-tolerant
consensus pool. Updates to a
document being managed by
several firms who trust each
other might be confirmed by a
crash-fault tolerant cluster
operated by firms themselves.
Transaction privacy No Peer-to-peer encrypted
message exchange. Private
transactions and private
contracts for groups of users.
Private channels/
subnetworks, data can only be
accessed by chaincodes
deployed in the subnetworks
High. Transactions visible only
to parties involved in them.
Anonymity/confidentiality Pseudonymity only Identity management service. Idemix protocol There are some anonymity
features but in essence the
network operates with known
participants.

Field masking none none Yes Yes
Centralized points of
failure
Possibly the access gateways
(only)
N/A Possibly ordering service
(moot point) in case there is
only one ordering organization
Notaries if a single notary is
used rather than a pool;
central certification authority
if used.
Censorship resistance 50% of the processing power
needs to be compromised for
attacks
N/A High High
Vulnerability to other
attacks
Faults in SC programming and
Solidity framework + other
(see Ethereum Appendix
below)
All the attacks inherited from
Ethereum
DoS on endorser, wormhole
Dependence on vendor-
specific HW extensions
none none none Remotely attested secure
enclaves are an option
Languages Solidity, Vyper Solidity, Vyper Go, Node.js, Java Any JVM bytecode compatible
Flexibility in data models Limited in Solidity Limited in Solidity Very flexible, limited only by
the language in which
chaincode is written
Very high
Wallets many MetaMask and other
Ethereum wallets
Libraries with wallet
functionalities
N/A
Installation, setup,
monitoring and toolset
User friendly, extensive
toolset
User friendly, extensive
toolset
No easy way to deploy.
Requires Kubernetes.
Any IDE supporting Go,
Node.js or Java, can be used.
Community driven explorer
tools. Combination of tools
required for monitoring.
Docker support and plenty of
tutorials to get started.
Possible to run local setups
using Docker images.
Blockchain explorer tools
exist.

Vendor lock-in, cost of use Open source - free Open source - free
Enterprise edition - paid
Open source - free
Paid support optional (IBM)
Open source - free
Paid enterprise version
Industrial adoption, proven
deployments
Extensive Extensive, in several specific
industries
Adopted by several dominant
vertical players
Adopted mainly by banks

4. Conclusions and recommendations
This document reported a study of Ethereum, Quorum, Hyperledger Fabric and Corda blockchains based
on a broad survey of literature, while focusing on major parameters that may affect their choice as building
blocks in the PharmaLedger hierarchical multi-blockchain architecture. Among other things, the
parameters include governance, network and data structures, consensus protocol, transaction
rate/throughput, security, modularity, ease of deployment and software engineering, costs and industrial
adoption.
A comparative assessment of these blockchain technologies was attempted in this complex multi-
parameter space. In the PharmaLedger project, blockchains are used for the following key purposes:
1. As a root blockchain in the PharmaLedger blockchain hierarchy
2. As leaf blockchains for anchoring DSUs for the implementation of use cases
3. As leaf blockchains for standard smart contract-based implementation of use cases (in case such
implementations do not use DSUs)
The following table summarizes the recommended use of the four surveyed blockchains based on the
results of the research reported in this document. For each of the blockchains surveyed (1st
column), we
provide recommendations of potential use in the context of PharmaLedger, linking it with the numbered
list presented above; as well as their advantages and limitations that were identified during our research.
Blockchain/DLT system Potential use in
PharmaLedger
Advantages Limitations
Ethereum 1,2 Security, maturity Lack of privacy,
low throughput
Quorum 1, 2, 3 Security, maturity,
privacy, industry
adoption
Low throughput
HyperLedger Fabric 3 Privacy, maturity,
industry adoption,
enterprise orientation
Complexity
Corda 3 Security, flexibility,
performance, privacy
Enterprise version – paid
Banking transactions oriented
The above mapping should be considered only as an initial reference point when making decisions about
use of specific blockchains in architecting and implementing PharmaLedger use cases. For each particular
use case, a range of additional parameters should be considered, as detailed in the Appendices. These
include but are not limited to resilience to attacks, governance, transaction rates, ability to integrate with
off-chain storage and more.

Appendices: Blockchain platform assessment studies
A1. Ethereum
A1.1 Ethereum: Membership and governance
Membership (public/private/permissioned/permissionless) Ethereum is a public permissionless ledger in which everyone can participate, mine and access all of its
features such as the smart contracts. Many companies exploit the Ethereum platform and they
implement their own private implementations according to their needs. As such, in the research
community and in enterprise environments it is common to exploit the Ethereum in order to implement
private and even permissioned networks.
Online governance features Currently, Ethereum does not offer online governance features by design.
Advantages and limitations Ethereum network is a public ledger. They do exist private implementations that are configured
according to the requirements of each use case they aim. General observations for the Ethereum
ecosystem:
• Advantages: extensive community support and research behind Ethereum
• Limitations: it is lacking fast TPS as opposed to other enterprise solutions; it is PoW based which
requires big computational power. However, private implementation can scale better with
more TPS and in the near future is moving to a PoS model. Thus, these limitations can be
bypassed with private deployments.
Ethereum enterprise solutions:
● Advantages: connection with the public ledger provides fast upgrades and improvements in the
source code; has a unified single ledger which provides more flexibility in terms of scalability
updates and privacy (other DLTs such as Fabric are multi-ledgers and thus become more
complex); easy to set up the network; proven working product over five years in production; is
based on the current standards such as human readable naming (ENS) and Swarm for
decentralized storage; Enterprise Ethereum Alliance (EEA) with most of the companies
participating in order to improve the private implementations;

● Limitations: The PoW consensus is a limitation, which can be bypassed with implementing IBFT
algorithms to improve block time, interoperability and support of features such as private
contracts;
A1.2 Ethereum: Architecture and data structures
Type (multi-blockchain/side/child chains, sharding, single
chain etc.)
Ethereum is a single blockchain with a single ledger and support of smart contracts. This applies to both
private ledgers and the public one.
Type of consensus (finality, probabilistic, etc.) The consensus algorithm is called Ethash25
and belongs to the PoW family of algorithms. This is the
version of Ethereum 1.0. Ethash is a hash function coming from the Keccak family (SHA-3 functions) but
is not considered as an SHA-3 function. Ethash has been designed and evolved to be ASIC-resistant with
memory-hardness26
. The main reason for this new algorithm was to avoid mining centralization. Hence,
ASIC cards cannot compete with the typical consumer graphic cards. The average time to finality in
Ethereum is 60 minutes (at least 25 confirmations, as for the public ledger). PoW algorithms belong to
probabilistic-finality consensus protocols27
. Ethereum is transiting to a PoS algorithm consensus and will
be renamed to Ethereum 2.0. This will tackle the issues with scalability and aid faster blockchain time
to finality.
Modularity/plug-ins (such as consensus alg., identity system
etc.)
The community behind Ethereum is considerably advanced in terms of tools, plugins, frameworks and
documentation. As such, it supports plugins in various domains such as identities. uPort for example, is
a decentralized identity system28
. Other plugins include: Whisper29
, a communication protocol for
DApps targeted for Web3 stack; Provable30
, an oracle service backed by authenticity proofs for smart
contracts, it provides off-chain actions and data-fetching; IPFS Mahuta31
, a decentralized storage and
25 https://eth.wiki/en/concepts/ethash/ethash
26
Rudlang, Marit (Jun 2017). Comparative Analysis of Bitcoin and Ethereum (PDF). Norway: NTNU: Norwegian University of Science and Technology. pp. 52–53. Retrieved 29
September 2018.
27
Zhang, S. and Lee, J.H., 2019. Analysis of the main consensus protocols of blockchain. ICT Express.
28
https://github.com/Ethereum
29
https://github.com/Ethereum/wiki/wiki/Whisper
30
https://github.com/provable-things/Ethereum-api
31
https://github.com/ConsenSys/Mahuta

file referencing solution; An extensive list can be found here: https://github.com/ConsenSys/Ethereum-
developer-tools-list
Supported/how easy to connect to off-chain storage systems
and databases (IPFS, swarm etc.)
As mentioned previously, the collection of tools in the Ethereum platform is extensive. Many use cases
require off-chain data storage, due to the high cost of the Ethereum gas and for practical reasons. A
famous protocol for distributed file storage is the IPFS protocol32
, which allows you to store files locally
and use the hash of the contract in the main chain when retrieving the data. In addition, Swarm33
has
been utilized and exploited as a storage and communication protocol for the Web3 stack. Other
database plugins include: Infura34
, and 3Box Storage35
. These tools offer easy to setup desktop
instructions for your own node without complex command line tools.
Transaction storage structures (UTXO, key-value, account-
based etc.)
In the Ethereum ecosystem they exist 2 types of accounts: the user accounts and the smart contract
accounts. The smart contracts are designed to be Turing complete in order to be easily programmable
and to solve complex problems. Hence, Ethereum is using an Account/Balance model which offers
simplicity in the smart contracts, as opposed to a UTXO model. The accounts have balance, storage and
code-space for interacting with other addresses. With the Account/Balance model a transaction is valid
only if the sending account has balance, while the receiving account can credit the account, change the
storage or call other accounts for further interactions.
Global state storage structures and update procedures Merkle Patricia Tries are being used for all the storage (key, value) of all bindings on Ethereum network.
Each block header has three roots for three tries that represent state, transactions and receipts3637
Advantages and limitations Ethereum is operating in a single ledger blockchain with various plugins available to be deployed on.
The major advantage is the extensive list of tools and plugins that can support the developers in many
use cases and simplify the procedures while keeping simplicity. A limitation, as stated before is the PoW
algorithm which involves computational costs.
32
https://ipfs.io/
33
https://ethersphere.github.io/swarm-home/
34
https://infura.io/
35
https://docs.3box.io/api/storage
36
https://github.com/Ethereum/wiki/wiki/Patricia-Tree
37
Vujičić, D., Jagodić, D. and Ranđić, S., 2018, March. Blockchain technology, bitcoin, and Ethereum: A brief overview. In 2018 17th international symposium
infoteh-jahorina (infoteh) (pp. 1-6). IEEE.

A1.3 Ethereum: Performance
Supported transaction rate (TPS) The public ledger operates capped around 15TP/S38. In the private networks Ethereum behaves very
differently and is highly dependent on the parameters given as an input such as: block frequency, block
size, network size etc. The TPS reported in the literature can reach as high as 284 TPS39
and as minimum
as 0.2TPS40
. In a network size of 10 nodes the throughput is 124.1TPS41
. Results on the current PoW
algorithm indicate that the optimal parameters have to be studied beforehand implementing a private
Ethereum network. Lastly, scaling is limited due to the current design of Ethereum consensus algorithm.
Resilience to faulty network conditions In regards to network faulty conditions the network is considered safe, resilient and decentralized
enough to keep the miners running in an acceptable level of trust.
Time to finality of transaction For the public ledger the average time to finality is 2-6 mins. In the private Ethereum networks time to
finality depends heavily on the network configuration such as block frequency, block size, number of
nodes, etc. It is considered much faster time to finality in the private implementations.
Scalability (how the number of nodes affects TPS) Experiments demonstrate that more nodes can yield more TPS but this is questionable. The following
table demonstrates an experiment with different setups.
38
https://eth.wiki/sharding/Sharding-FAQs
39
Dinh, T.T.A., Wang, J., Chen, G., Liu, R., Ooi, B.C. and Tan, K.L., 2017, May. Blockbench: A framework for analyzing private blockchains. In Proceedings of the 2017 ACM
International Conference on Management of Data (pp. 1085-1100)
40
Chen, S., Zhang, J., Shi, R., Yan, J. and Ke, Q., 2018, July. A comparative testing on performance of blockchain and relational database: Foundation for applying smart technology
into current business systems. In International Conference on Distributed, Ambient, and Pervasive Interactions (pp. 21-34). Springer, Cham
41
Schäffer, M., Di Angelo, M. and Salzer, G., 2019, September. Performance and scalability of private Ethereum blockchains. In International Conference on Business Process
Management (pp. 103-118). Springer, Cham.

The authors of this experiment42
conclude that a higher number of nodes does not take full advantage
of their available resources. There is a match 90-100% for small network sizes but in the larger setups
the numbers drift apart. This is a scalability limiting factor for the current Ethereum PoW algorithm.
Storage scalability (the number of data items stored on the
blockchain that would degrade performance to unacceptable
levels)
Ethereum does not offer on-chain storage solutions. As mentioned before, off-chain solutions exist
such as IPSF and Swarm. In regards to the transactions storage, there is no problem with scalability
issues to degrade the performance of the network (Merkle Patricia Tries are being used).
Network bandwidth (from/to a node) The public ledger operates at around 250GB / month. For the private networks it is considered to be
much less.
Open issues (that could not be assessed in desktop research) Researchers demonstrates43
that the different parameters are very correlated and can be used to
optimize the performance. However, due to the current design of Ethereum there is a scaling upper
limit which cannot be bypassed. The following figure presents the bottleneck of the parameters as
identified in the experiment.
42
Management (pp. 103-118). Springer, Cham.
43
Management (pp. 103-118). Springer, Cham

The network size is at the top of the bottleneck hierarchy. This indicates that when operating a network
at its limits, the bottom parameters (e.g., block size) reduce performance even before the reduction is
done at a network level (e.g., more nodes do not increase significantly the performance). This is a design
flaw in the current design of Ethereum.
Advantages and limitations • Advantages: the network is decentralized and resilient to network faults;
• Limitations: As mentioned previously, the consensus PoW algorithm poses scalability
limitations that can be bypassed with implementing another consensus algorithm;

A1.4 Ethereum: Security, privacy and confidentiality
Fault tolerance of consensus protocol (what kind of failures
can be tolerated: crashes, byzantine)
PoW, PoS and DPoS belong to the probabilistic-finality family protocols which indicates that a possible
attack is feasible when someone holds over 50% of the computation power in PoW or more than 50%
of the stake in PoS. This attack would give him access to create a different longer chain and perform a
double-spend attack. Ethereum as for now with PoW requires 50% of the computation power to
perform a double-spend attack44
Transaction privacy - parties cannot see transactions
processed
Transactions are visible to everyone who has the public address of an account (user account or smart
contract account).
Anonymity / Confidentiality - parties cannot see who is
sending transactions
Everything is public and visible in the ledger as long as someone has the public addresses.
Field masking - specific transaction fields can be masked Transacting in Ethereum ledgers is public. However, there are unofficial techniques such as mixing
contracts4546
which have similar properties to Monero’s ring signatures mixes and can hide transactions.
Ethereum enterprise supports private transactions through modified clients such as Hyperledger Besu47
or through additional components such as Orion48
.
Centralized points of potential security failure Currently there are no significant centralized points of failure in the ecosystem of Ethereum.
Censorship resistance (to ability of an attacker to prevent the
network from functioning correctly for a period of time)
Ethereum is inherently censorship resilient as it is operating totally decentralized. An attacker would
require over 50% of resources to harm the network.
Vulnerability to other attacks Ethereum architecture can be divided in four layers: the network layer where the node discovery and
propagation are happening, the consensus layer, the data layer where the transactions and blocks are
created and the application layer where the Ethereum Virtual Machine with accounts and smart
contracts are being utilized. Studies reveal that vulnerabilities exist on all levels of its architecture such
as flaws in the smart contract programming, the Solidity framework and the Ethereum overall design
44
Zhang, S. and Lee, J.H., 2019. Analysis of the main consensus protocols of blockchain. ICT Express.
45
https://github.com/blackyblack/laundromat
46
https://libsubmarine.org/
47
https://www.hyperledger.org/use/Besu
48
https://github.com/PegaSysEng/orion

with its PoW consensus. Hereby in the following figure, the authors49
provide a classification on all
possible vulnerabilities someone can encounter in the ecosystem.
49
Chen, H., Pendleton, M., Njilla, L. and Xu, S., 2020. A Survey on Ethereum Systems Security: Vulnerabilities, Attacks, and Defenses. ACM Computing Surveys (CSUR), 53(3),
pp.1-43.

The filled black box indicates that the vulnerability is already fixed, the empty box indicates that it is
not yet resolved and the half box indicates that this vulnerability can be avoided. Furthermore, this
research provided a relation between vulnerabilities, attacks and the consequences of them. The
taxonomy of this mapping can be found below:

It can be seen that, if someone wishes to explore in depth the Ethereum ecosystem he should pay
attention to possible consequences that arise from all the vulnerabilities exploited. These taxonomies
are not strictly defined for Ethereum and they can be used as an overview to find vulnerabilities in other
systems that derive from Ethereum such as Quorum and Hyperledger Besu.
Dependence on vendor-specific hardware extensions (such as
trusted execution environment)
Ethereum does not rely on specific hardware Trusted Execution Environments. Approaches of
blockchain utilizing TEEs are working better when consensus decisions are final and not probabilistic
(e.g. Hyperledger Fabric).
Other confidentiality constraints or features N/A
Advantages and limitations • Advantages: there are no generic centralized points of failure and the network is censorship

• Limitations: all the information is public when transacting and using the smart contracts.
However, third party implementations such as Hyperledger Besu and Orion can work privately.
A1.5 Ethereum: Software engineering
Development
Smart contracts The most popular languages for implementing smart contracts in Ethereum are Solidity and Vyper.
Engine Ethereum Virtual Machine: taken from the yellow Ethereum paper "Basics. The EVM is a simple stack-
based architecture. The word size of the machine (and thus size of stack items) is 256-bit. This was
chosen to facilitate the Keccak256 hash scheme and elliptic-curve computations. The memory model is
a simple word-addressed byte array. The stack has a maximum size of 1024. The machine also has an
independent storage model; this is similar in concept to the memory but rather than a byte array, it is
a word addressable word array. Unlike memory, which is volatile, storage is nonvolatile and is
maintained as part of the system state. All locations in both storage and memory are well-defined
initially as zero.
Languages The most popular languages for writing smart contracts on Ethereum are Solidity50
(is the most popular
programming language that is used to program smart contracts on the Ethereum platform) and Vyper51
(is a contract-oriented, pythonic programming language that targets the Ethereum Virtual Machine).
Lifecycle and upgrades The platform is frequently upgraded. The improvements and upgrades in the platform are achieved
through off-chain proposals which are called Ethereum Improvement Proposals (EIPs). These proposals
are not recorded in the blockchain and are proposed through GitHub with some official methods for
further discussion, coordination and approval.
Turing completeness Ethereum is a Turing-complete system. It offers an extensive programming language interpreter (full
Turing), allowing to add much more complex logic within the blockchain.
Flexibility in the data models that can be employed for
representing data (e.g., Solidity is limited)
Limited as it is based on Solidity.
Libraries There are several libraries for different purposes for Ethereum for example:
50
https://Ethereum.org/en/developers/#:~:text=Smart%20Contract%20Languages,C%2B%2B%2C%20Python%20and%20JavaScript.
51
https://vyper.readthedocs.io/en/stable/

• web3.js52
: web3.js is a collection of libraries that allow you to interact with a local or remote
Ethereum node using HTTP, IPC or WebSocket.
• OpenZeppelin53
:OpenZeppelin provides tools to write, deploy and operate decentralized
applications.
Sample implementations Sample implementations do exist; for example, refer to: https://Ethereum.org/en/build/
Tools / IDE / debugging environment There is a diverse variety of tools and IDEs for Ethereum54
, including:
• Visual Studio Code: Professional cross-platform IDE with official Ethereum support.
• Remix: Web-based IDE with built in static analysis, and a test blockchain virtual machine.
• EthFiddle: Web-based IDE that lets you write, compile, and debug your smart contract.
• Ethereum Studio: Web-based IDE ideal for new developers looking to experiment with smart
contracts. Ethereum Studio features multiple templates, MetaMask integration, transaction
logger, and a built in-browser Ethereum Virtual Machine (EVM) to help you get started building
on Ethereum as fast as possible.
Maturity The Ethereum ecosystem is mature, being online since 2015 it has been researched and developed
extensively. However, the technology is moving to PoS and new tools will come into existence.
Developer ecosystem and community They exist various communities such as:
• official Ethereum community: https://Ethereum.org/en/community/
• Ethereum community fund: https://ecf.network/
• dev community: https://dev.to/t/Ethereum
• ethglobal: https://ethglobal.co/
• other slack and reddit communities
Documentation (extensiveness, quality) Extensive, considerable documentation exists online from the official sources and from third-parties.
For example:
52
https://web3js.readthedocs.io/en/v1.2.11/
53
https://openzeppelin.com/
54
https://Ethereum.org/en/developers/

• https://Ethereum.org/en/developers/
Wallets and wallet SDKs Wallets to interact with decentralized applications and hold the keys built specifically for Ethereum
exist many:
• MetaMask55
: browser extension and mobile wallet for iOS and Android
• MyCrypto56
: web-based wallet
• TrustWallet57
: mobile wallet for iOS and Android
• MyEtherWallet58
: client-side wallet
• Argent59
: mobile wallet for iOS and Android, optimized for DeFi
• Coinbase60
: Wallet mobile wallet for iOS and Android
• Gnosis Safe61
: security oriented multi-signature wallet
• Other wallet SDKs exist and they provide OAuth single sign in to DApps62
Learning resources The official Ethereum site, presents Ethereum.org/en/learn, which is a set of resources to help you
learn more about Ethereum. This page includes articles and guides, plus technical and non-technical
resources. Hereby, find more useful resources:
• https://Ethereum.org/en/learn/
• https://github.com/Ethereum/wiki/wiki/White-Paper
• https://cryptozombies.io/
• https://www.trufflesuite.com/
Advantages and limitations • Advantages: the strongest point of the Ethereum ecosystem is the big community of developers
and the availability of the tools for all the technical levels of knowledge: from completely
55
https://metamask.io/
56
https://mycrypto.com/account
57
https://trustwallet.com/
58
https://www.myetherwallet.com/
59
https://www.argent.xyz/
60
https://wallet.coinbase.com/
61
https://gnosis-safe.io/
62
https://github.com/torusresearch/torus-embed

beginners (with gamification intuitive and interactive techniques such as cryptozombies) to
experts.
• Limitations: there are no significant limitations regarding the software development part of the
ecosystem.
Deployment and monitoring
User friendly installation Ethereum is user friendly with plenty of tools and documentation and community to support the
implementation of Ethereum. The most used tool is Go Ethereum63
.
Infrastructure setup
Local
Testnet
Permissioned network setup
Mainnet deployment
The public ledger64
has official testnets such as:
• Ropsten
• Kovan
• Rinkeby
• Görli
The ecosystem can be installed as a private permissioned network and operate completely in private
settings independent of the Mainnet by the users.
Permissioned versions of Ethereum are the forks of Quorum and Hyperledger Besu.
Blockchain explorer tools Various blockchain explorers exist and some are:
• Public network: ethscan, ethplorer, etherchain, blockchain etc.
• Private networks: tools such as Epirus65
, etherchain light66
, blockscout67
Tools for monitoring network health Tools for monitoring health and status are:
63
https://geth.Ethereum.org/docs/install-and-build/installing-geth
64
https://docs.ethhub.io/using-Ethereum/test-networks/
65
https://github.com/blk-io/epirus-free
66
https://modex.tech/developers/BlockchainExplorerTeam/Lightweight-Ethereum
67
https://github.com/blockscout/docs

• Integrated tool: eth-netstats, eth-net-intelligence-api
• Libraries: Alethio, Scout, neofund, etc.
Advantages and limitations • Advantages: an important aspect to consider Ethereum implementation is the enormous
availability of tools and the user-friendly setup for beginners.
• Limitations: there are no significant limitations regarding the deployment part of the
ecosystem.
A1.6 Ethereum: Commercial and business aspects
Licensing model It is open source and free software (FLOSS68
definition). There is no special requirement for copyright.
Vendor lock-in N/A
Costs of use There is no associated cost of use other than the cost of the hardware equipment and the electricity
requirements.
Developer costs Open-source contribution by the community with the form of EIPs.
Administrative costs N/A
Transaction fees • Public ledger: To enable the network to operate and transact with the ledger (write) it requires
fees expressed in a form called gas and divided in units called gwei. Depending on the
congestion of the network it can be: Average 0.1-2$ per transaction. On peak network
congestion it can reach 10 dollars or more.
• Private networks: in the private Ethereum networks the gas exists but is not priced in. Hence
everyone can be given for free. In other implementations such as Quorum the gas has been
excluded.
Support of tokens The official token standards are: ERC20, ERC721, ERC223, ERC777 and ERC-820.
The ecosystem supports the issuance of tokens through the above-mentioned standards.
Other N/A
A1.7 Ethereum: Industrial adoption and use cases
Adoption by major players in the industry Yes, many industries implement private Ethereum networks. In addition, the companies are members
of the Enterprise Ethereum Alliance an organization whose objective is to drive the use of Ethereum
blockchain technology as an open-standard to empower enterprises. ( https://entethalliance.org/ ).
68
https://www.fsf.org/

• Finance Industry: Banco Santander, BBVA, ING Bank N.V, JP Morgan
• Technology Industry: Intel, LG CNC, Microsoft, Amazon Web Services
• Energy Industry: BP, Shell, Chevron Pacific Gas & Electric Company,
(https://consensys.net/blockchain-use-cases/energy-and-sustainability/#midstream)
Proven production deployments Finance Industry:
• Banco Santander: https://www.santander.com/en/press-room/press-releases/santander-
launches-the-first-end-to-end-blockchain-bond%C2%A0
• BBVA: https://www.coindesk.com/bbva-puts-150-million-syndicated-loan-on-Ethereum-
blockchain
• ING Bank: https://www.ingwb.com/themes/distributed-ledger-technology-articles/ing-
launches-major-addition-to-blockchain-technology
Technology industry:
• Intel: https://www.intel.es/content/www/es/es/products/docs/servers/Ethereum-
blockchain-white-paper.html
• LG CNC:
https://www.ledgerinsights.com/lg-blockchain/
https://www.ledgerinsights.com/lg-cns-kakao-public-private-blockchains/
• Microsoft, Amazon Web Services: https://coinrivet.com/3-huge-names-using-Ethereum-
platform/
Energy Industry:
• BP, Shell, Chevron
https://www.ledgerinsights.com/vakt-oil-post-trade-blockchain-goes-live/
Features that optimize operation for/focus on specific
industries
Finance Industry:
• ING Zero-Knowledge Range Proof (ZKRP): improving confidentiality in a public ledger.
• Banco Santander (Corporate and investment banking): reduced the number of intermediaries
required in the process, making the transaction faster, more efficient and simpler
• BBVA: reduce loan negotiation time.
Technology Industry:

• Intel Transparent supply chain: record each step of the product’s manufacturing and
distribution process
• AWS, Microsoft: Include blockchain as part of their cloud services to clients.
Energy Industry:
• Improve the trading process of the sector. Post-trade commodities processing suffers from
slow, complicated paper-based processes that are subject to loss, delay and error. The use of
Blockchain brings security, immutability and privacy.
Other N/A

A2. Quorum
A2.1 Quorum: Membership and governance
Membership (public/private/permissioned/permissionless) Private/Permissioned blockchain powered using Ethereum network69
Online governance features Quorum is a fork of the Ethereum codebase targeting enterprise-based blockchain, which offers a private
blockchain infrastructure. Quorum claims to address the privacy of both transaction and contract data,
permission and governance. Privacy is achievable by setting the recipient's public key as a transaction
parameter. In this way, the transaction is encrypted and read-only by the owner of the private key.
Permission and governance can be reached by each node in the network that has a whitelist specifying
the remote nodes that are allowed for both inbound and outbound connections70
. However, there are no
online governance features yet.
Advantages and limitations Advantages:
● Provides transaction privacy: Quorum implemented zero-knowledge security layer (ZSL) feature.
This feature aims to use shielded transactions without revealing any information about the
sender, recipient or the assets that are being transferred.
● Work with the existing tools e.g.: Truffle, MetaMask, Remix, OpenZeppelin, and more.
Disadvantages:
● When use cases become more complex, Quorum’s channel-based approach to privacy presents
challenges for privacy and scalability.
69
ConsenSys, “ConsenSys/Quorum-docs,” GitHub, 2020. [Online]. Available: https://github.com/jpmorganchase/Quorum-
docs/blob/master/Quorum%20Whitepaper%20v0.2.pdf. [Accessed: 18-Jul-2020].
70
“Permission and Privacy for Blockchain Networks under Ethereum and Quorum | Hacker Noon,” hackernoon.com. [Online]. Available:
https://hackernoon.com/permission-and-privacy-for-blockchain-networks-under-Ethereum-and-Quorum-4s1ab2dau. [Accessed: 31-Aug-2020].

A2.2 Quorum: Architecture and data structures
chain etc.)
Generic blockchain platform based in Ethereum
Single Blockchain architecture
Type of consensus (finality, probabilistic, etc.) With no need for POW/POS in a permissioned network, Quorum instead offers multiple consensus
mechanisms that are more appropriate for consortium chains:
Raft-based Consensus71
: Raft is a consensus algorithm with Crash Fault Tolerance (CFT). It helps perform
transactions faster as the block minting process is 50ms. It helps save storage space by mining only the
proper blocks and not the empty blocks. Its other significant features are transaction finality and on-
demand block creation.
Istanbul BFT72
: This is a consensus algorithm which is based on Byzantine Fault Tolerance. It helps
protect the blockchain. It provides protection for the blocks generated in the blockchain.
Clique POA Consensus73
: a default proof-of-authority (POA) consensus algorithm bundled with Go
Ethereum (implementation is ongoing)
Modularity/plug-ins (such as consensus alg., identity
system etc.)
Yes, the Quorum client is a modified geth client, and this allows you to add additional features as
plugins to the geth kernel, providing extensibility, flexibility, and isolation distinct from Quorum
features74
.
71
“Raft - GoQuorum,” docs.goQuorum.consensys.net. [Online]. Available: http://docs.goQuorum.com/en/latest/Consensus/raft/raft/. [Accessed: 20-Jul-2020].
72
“IBFT - GoQuorum,” docs.goQuorum.consensys.net. [Online]. Available: http://docs.goQuorum.com/en/latest/Consensus/ibft/ibft/. [Accessed: 20-Jul-2020].
73
“Clique PoA protocol & Rinkeby PoA testnet · Issue #225 · Ethereum/EIPs,” GitHub. [Online]. Available: https://github.com/Ethereum/EIPs/issues/225.
[Accessed: 31-Aug-2020].
74
“ConsenSys/Quorum.js,” GitHub, 25-Aug-2020. [Online]. Available: https://github.com/ConsenSys/Quorum.js. [Accessed: 31-Aug-2020].

Supported/how easy to connect to off-chain storage
systems and databases (IPFS, swarm etc.)
Yes, Quorum is then capable to use smart contracts as the main Ethereum protocol and so also use IPFS
/ Swarm as decentralized storage
Reference- “Audita: A Blockchain-based Auditing Framework for Off-chain Storage
“usage of storage nodes beside the “blockchain nodes”75
based etc.)
Account-based76
Global state storage structures and update procedures N/A
Advantages and limitations N/A
75 D. Francati et al., “Audita: A Blockchain-based Auditing Framework for Off-chain Storage,” 2019.
76 T. T. A. Dinh, R. Liu, M. Zhang, G. Chen, B. C. Ooi, and J. Wang, “Untangling Blockchain: A Data Processing View of Blockchain Systems,” IEEE Transactions on
Knowledge and Data Engineering, pp. 1366–1385, Jul. 2018.

A2.3 Quorum: Performance
Supported transaction rate (TPS) Quorum offers significantly higher performance than public geth (Ethereum) as it is more robust and has
the capability to process more than 100 transactions per second which is much more than that of Bitcoin
and Ethereum.
“Establishing traceability in global supply chains is a complicated problem. Current solutions for achieving
traceability are expensive or imperfect, and give rise to organizational and trust-related issues.
Blockchain could present itself as a solution to many of these issues. This thesis aims to build a
blockchain-based traceability system. Based on the event characteristics in IKEA Supply Chain, our
analysis show that, for timely processing, the capacity of a traceability system should be 10 593 events
per second. Additionally, 14 requirements were identified and included in the system design. A system
was designed that consists of six components, a client application, a controller, a smart contract pool,
IPFS and Quorum. In order to reduce the potential load on the system, certain optimization measures
were taken. The system design resulted in a load requirement of 14 975 transactions for a delay bound of
one minute. The resulting performance of the developed system revealed itself to be a throughput of 159
transactions per second and a convergence time of 4.71 seconds, which is not enough to reach the
requirement. However, a solution is proposed to divide the network into many smaller networks that
together can produce the necessary throughput.” 77
77
C. Lööf and T. Sund, “Performance Evaluation of a Blockchain-based Traceability System -A Case Study at IKEA Prestandautvärdering av ett blockkedje-
baserat spårbarhetssys- tem.” [Online]. Available: liu.diva-portal.org/smash/get/diva2:1307991/FULLTEXT01.pdf.

Latency and throughput78
78
A. Baliga, I. Subhod, P. Kamat, and S. Chatterjee, “Performance Evaluation of the Quorum Blockchain Platform,” arXiv:1809.03421 [cs], Jul. 2018.

Other studies claim support that Quorum operates well with 600-800 TPS depending on the block
time79 80
Resilience to faulty network conditions Yes
Time to finality of transaction Raft consensus mechanism is useful for closed-membership/consortium settings where byzantine fault
tolerance is not a requirement, and there is a desire for faster block times (on the order of milliseconds
instead of seconds) and transaction finality (the absence of forking.) This consensus mechanism does not
“unnecessarily” create empty blocks, and effectively creates blocks “on-demand.” A Quorum Raft
network reaches transaction finality on a per-block basis. 81 82
Scalability (how the number of nodes affects TPS) Highly scalable “Performance Evaluation of the Quorum Blockchain Platform” 83
Storage scalability (the number of data items stored on the
blockchain that would degrade performance to
unacceptable levels)
N/A
Network bandwidth (from/to a node) N/A
Open issues (that could not be assessed in desktop
research)
N/A
79
Baliga, Arati, I. Subhod, Pandurang Kamat, and Siddhartha Chatterjee. "Performance evaluation of the Quorum blockchain platform." arXiv preprint
arXiv:1809.03421 (2018).
81
“Raft - GoQuorum,” docs.goQuorum.consensys.net. [Online]. Available: http://docs.goQuorum.com/en/latest/Consensus/raft/raft/. [Accessed: 20-Jul-2020].
82
“Quorum,” Chainstack documentation. [Online]. Available: https://docs.chainstack.com/blockchains/Quorum. [Accessed: 31-Aug-2020].
83
A. Baliga, I. Subhod, P. Kamat, and S. Chatterjee, “Performance Evaluation of the Quorum Blockchain Platform,” arXiv:1809.03421 [cs], Jul. 2018.

A2.4 Quorum: Security, privacy and confidentiality
Fault tolerance of consensus protocol (what kind of failures
can be tolerated: crashes, byzantine)
Raft-based Consensus 84
: Is a consensus algorithm with Crash Fault Tolerance (CFT). The Raft consensus
algorithm has the following key characteristics:
● Crash fault tolerance
● Transaction finality
● On-demand block creation
● Consensus nodes flexibility
A Quorum Raft network can tolerate an f number of faulty nodes in n=2f+1. For example:
● A Raft network with 3 nodes can tolerate 1 node failure. The majority of nodes in a 3-node
network is 2; 3=2(1) +1.
network is 3.
network is 3; 5=2(2) +1.
network is 4.
Istanbul BFT 85
: Is a consensus algorithm which is based on Byzantine Fault Tolerance. Quorum IBFT
network can tolerate an f number of faulty nodes in n=3f+1, where n is the total number of nodes.
For example, with f is 3:
● Total nodes in the network: 10
84
85

● Maximum number of faulty nodes can be tolerated: 3
● The network reaches consensus with the number of non-faulty nodes: 7
● The minimum recommended number of nodes in an IBFT network is 4.
Transaction privacy - parties cannot see transactions
processed
It uses ‘constellation’, a peer-to-peer encrypted message exchange for transferring private data to
network participants. It supports both private transactions and private contracts.
It allows for node/peer permissions using smart contracts which helps ensure that only known parties
join the network.
Anonymity / Confidentiality - parties cannot see who is
sending transactions
Identity management service. Private transactions between participants are hidden from all others.
Field masking - specific transaction fields can be masked Yes, Quorum allows transactions between network participants privately, that is, it allows a transaction
to only be seen among a sub-group of participants.
The data of private transactions never reach the nodes that do not participate, since to send this data,
blockchain communication is not used, but instead a point-to-point network is used that works together
with the blockchain and allows sending data from node to node, called / provided by Constellation. This
data is verified on the blockchain through its hashes, but the data is never sent over the "open"
network.
Centralized points of potential security failure N/A
Censorship resistance (to ability of an attacker to prevent the
network from functioning correctly for a period of time)
N/A
Vulnerability to other attacks N/A
Dependence on vendor-specific hardware extensions (such
as trusted execution environment)
N/A
Other confidentiality constraints or features N/A

A2.5 Quorum: Software engineering
Development
Smart contracts Smart contract code (Solidity), legally binding
○ Engine Ethereum virtual machine
○ Languages Solidity, Vyper
○ Lifecycle and upgrades Frequently
○ Turing completeness Solidity is Turing complete, but Vyper is not Turing complete 86
Flexibility in the data models that can be employed for
representing data (e.g., Solidity is limited)
Limited
Libraries
web3.js - Ethereum JavaScript API 87
Quorum.js: is an extension for web3.js which adds support for APIs specific to Quorum 88
Sample implementations GoQuorum Projects 89
86
N. S. on, “Turing Completeness and the Ethereum Blockchain | Hacker Noon,” hackernoon.com. [Online]. Available: https://hackernoon.com/turing-
completeness-and-the-Ethereum-blockchain-c5a93b865c1a. [Accessed: 31-Aug-2020].
87
“web3.js - Ethereum JavaScript API — web3.js 1.0.0 documentation,” web3js.readthedocs.io. [Online]. Available: https://web3js.readthedocs.io. [Accessed:
28-Aug-2020].
88
“Overview - GoQuorum,” docs.goQuorum.consensys.net. [Online]. Available: https://docs.goQuorum.com/en/latest/Quorum.js/Overview. [Accessed: 20-Jul-
2020].
89
“GoQuorum projects - GoQuorum,” docs.goQuorum.consensys.net. [Online]. Available:
https://docs.goQuorum.consensys.net/en/latest/Reference/GoQuorum-Projects/. [Accessed: 31-Aug-2020].

Tools / IDE / debugging environment Cakeshop: provides tools for managing a blockchain node, setting up clusters, exploring the state of the
chain, and working with contracts.
Quorum Plugin for Remix: The Quorum plugin for Ethereum’s Remix IDE adds support for creating and
interacting with private contracts on a Quorum network.
TRUFFLE: A popular development, testing framework and asset pipeline for blockchains using the
Ethereum Virtual Machine (EVM), aiming to make developer’s life easier. Truffle provides:
● Smart contract life cycle management
● Automated contract testing
● Scriptable deployment and migrations
● Simple network management
● Powerful interactive console
● External script runner
Remix IDE: Remix is a browser-based compiler and IDE that enables users to build Ethereum contracts
with Solidity language and to debug transactions.
Quorum Maker: is a tool that allows users to create and manage Quorum network.
Maturity Continuous scalability
Developer ecosystem and community Yes, it has channels on twitter, slack, GitHub, etc.90
Documentation (extensiveness, quality) Extensive documentation
Wallets and wallet SDKs MetaMask: A crypto wallet & gateway to blockchain apps.
Learning resources
90
“ConsenSys Quorum Contact,” ConsenSys. [Online]. Available: https://www.goQuorum.com/#contact. [Accessed: 31-Aug-2020].

https://docs.goQuorum.consensys.net/en/latest
https://docs.Quorumplugins.consensys.net
https://docs.orchestrate.consensys.net
https://docs.tessera.consensys.net
https://docs.ethsigner.consensys.net
https://docs.orion.consensys.net
Advantages and limitations Since Quorum is a fork of the go-Ethereum (Geth) codebase, it works with known tools for example:
Web3.js, Remix IDE, OpenZeppelin, Truffle, MetaMask and many more.
A2.6 Quorum: Deployment and monitoring
User friendly installation Yes. For example
Quorum Wizard: is a command line tool that allows users to set up a development Quorum network on
their local machine in less than 2 minutes.
Kubernetes: Deploy Quorum on Kubernetes.
Quorum-cloud: Tools to help deploy Quorum network in a cloud provider of choice.
Infrastructure setup
○ Local
○ Testnet
○ Permissioned network setup
○ Mainnet deployment
Permissioned network

Blockchain explorer tools Yes, Blockchain Explorer for Besu, Quorum and Ethereum91
Tools for monitoring network health Yes, Quorum-Profiling is a custom toolset used to benchmark transaction throughput and network
statistics on any existing Quorum network92
.
Advantages and limitations Quorum has extensive documentations and examples on how to setup a network in both local and cloud
environments, which is good for blockchain developers to start the development quickly.
A2.7 Quorum: Commercial and business aspects
Licensing model The license used by Quorum is GPL / LGPL 3.0, which is similar to Ethereum93
Vendor lock-in no
Costs of use no
Developer costs nothing
Administrative costs no
Transaction fees Quorum eliminated the concept of adding cost to a transaction
using gas. Therefore, Quorum does not have any
cryptocurrency costs associated with running transactions on the Quorum network.94
Support of tokens yes
Other N/A
91
“Blockchain Explorer for Besu, Quorum and Ethereum,” GitHub, 20-Aug-2020. [Online]. Available: https://github.com/blk-io/epirus-free. [Accessed: 31-Aug-
2020].
92
“ConsenSys/Quorum-profiling,” GitHub. [Online]. Available: https://github.com/ConsenSys/Quorum-profiling. [Accessed: 28-Aug-2020].
93
https://github.com/jpmorganchase/Quorum/blob/master/COPYING.LESSER
94
https://arxiv.org/pdf/1809.03421.pdf

A2.8 Quorum: Industrial adoption and use cases
Adoption by major players in the industry Quorum Blockchain technology it is currently use different industries such as:
(1) Banking & finance: Deutsche Bank (Germany), OCBD Bank (Singapore)
(2) Insurance: State Farm (USA)
(3) Supply chain / Inventory: LVMH (France), Starbucks, Chase Auto.
(4) Media & entertainment: Microsoft Xbox, Bloomen.
(5) Oil: BP, Shell.
(6) Automotive: BMW (Europe, Mexico, USA)
Proven production deployments (1) Banking & finance:
(a) Deutsche Bank (Germany): https://cointelegraph.com/news/germanys-largest-bank-
joins-jpmorgans-blockchain-network
(b) OCBC Bank (Singapore): https://www.coindesk.com/first-singapore-bank-joins-
jpmorgans-blockchain-payments-initiative
(2) Insurance:
(a) State Farm and USAA:
https://www.forbes.com/sites/benjaminpirus/2019/07/18/state-farm-and-usaa-see-
stark-increase-in-efficiency-when-testing-blockchain-subrogation/#370857e755c3
(3) Supply chain / Inventory:
(a) LVMH (Louis Vuitton): https://www.coindesk.com/louis-vuitton-owner-lvmh-is-
launching-a-blockchain-to-track-luxury-goods
(b) Starbucks: https://www.forbes.com/sites/darrynpollock/2019/05/07/starbucks-teams-
up-with-microsoft-to-boost-its-bean-to-cup-blockchain/#613068cd3b5d

(c) Chase Auto: https://www.coindesk.com/jpmorgan-tests-private-blockchain-to-track-
auto-dealer-inventory
(4) Media & entertainment
(a) Xbox: https://www.ey.com/en_gl/news/2018/06/ey-and-microsoft-launch-blockchain-
solution-for-content-rights
(b) Bloomen: http://bloomen.io/
(5) Oil:
(a) BP, Shell: https://www.vakt.com/#1
(6) Automotive:
(a) BMW: https://www.press.bmwgroup.com/global/article/detail/T0307164EN/bmw-
group-uses-blockchain-to-drive-supply-chain-transparency?language=en
Features that optimize operation for/focus on specific
industries
(1) Banking & finance: enables the parties to share information in a permissioned way. Everyone
can view the status of the transaction and address queries seamlessly. Insurance:
(2) Supply chain:
(a) LMVH: provide proof of authenticity of luxury items and trace their origins from raw
materials to point of sale and beyond to used-goods markets.
(b) Starbucks: tracking the coffee production in Costa Rica, Colombia and Rwanda.
(3) Chase auto: Track of the automobile inventory that finance for car dealers and avoid from
pledging the same car for different loans
(4) Media & entertainment
(a) Xbox: reduce processing time and faster tracking of video games royalties (Expected to
loans Media extend this solution to other use cases of the entertainment industry)

(b) Bloomen: improve the copyright protection and rights management. Have a fairer,
more dynamic and transparent payments.
(5) Oil:
(a) BP, Shell: Improve the trading process of the sector. Post-trade commodities
processing suffers from slow, complicated paper-based processes that are subject to
loss, delay and error. The use of Blockchain brings security, immutability and privacy.
(6) Automotive: Improve the process of tracking materials, components and parts across its supply
chain.

A3. Hyperledger Fabric
A3.1 Hyperledger Fabric: Membership and governance
Membership (public/private/permissioned/permissionless) members of HLF enroll through one or more trusted Membership Service Provider(s) (MSPs): private and
permissioned blockchain system
Online governance features (Built-in Governance Features) • (open source / open governance: technical decisions—such as which features to add, how to add
them, and when to add them—are made by a group of community-elected developers drawn
from a pool of active participants.)
• versioned smart contracts (“chaincode”) are possible in HLF
• on-chain governance features only in other HL projects (e.g., HL Sawtooth can upgrade consensus
and other business rules over the life of the network
• changing policy is managed through an own policy (mod policy)
• adding nodes (orderer or org) is preformed through channel update (Note: Kafka instead of solo
may be required)
• private and permissioned blockchain system does not require protocols like “proof of work” to
validate transactions and secure the network, like in permissionless public systems
• assuming that the traffic peak in a blockchain is caused by |members| x |transactions|, a
controlled number of members reduces the crowd as well as the number (increased speed) and
costs of transactions, saves network resources/operation cots, increases efficiency and stability
of the blockchain
• enables full privacy, facilitates implementing enterprise regulations,
• though private blockchain, it is built in the broad community, with open governance creating
trust
Limitations:
• because of limited access also the number of nodes is limited in comparison to public networks;
a priori decisions of the private network prevent many nodes from participating in the consensus
• immutability, security, and decentralization are achieved only partial, since only in public
networks everyone can participate in the consensus
• not fully anonymous, not user- (but rather enterprise-/entity-) based

A3.2 Hyperledger Fabric: Architecture and data structures
chain etc.)
• Multi-blockchain (not a single chain): HLF provides channels, which act as separate ledgers with
an own blockchain of which the transactions are only visible/received by peers of the channel
(specified in the constructor of the channel’s genesis block)
• Sidechaining is any mechanism that allows tokens from one blockchain (“main chain”) to be
securely used within a completely separate blockchain (“child chain”). Since HLF provides
neither a native token concept nor the concept of "child" ledgers, channels are not equivalent
to side or child chains.
Type of consensus (finality, probabilistic, etc.) • (permissioned) voting-based consensus, broken down in three phases/nodes (endorsement,
ordering, validation)
• require nodes to transfer messages, trade-off between scalability and speed
• BFT (byzantine fault-tolerant) or CFT (crash fault-tolerant; SOLO and Apache Kafka) ordering; examples
for latter in HLF are Apache Kafka (distributed ordering service) consensus mechanisms
Modularity/plug-ins (such as consensus alg., identity
system etc.)
Highly modular architecture:
• pluggable consensus
• flexible data isolation using ‘channels’
• open smart contract model
• asymmetric version support
Supported/how easy to connect to off-chain storage
systems and databases (IPFS, swarm etc.)
• with the HLF architecture, blocks are distributed at the node layer, and each node maintains its
own dedicated data store.
• swarm distribution possible
• but no IPFS and BigchainDB, where data is distributed across the data store itself.
• connection through cryptographic hashes
based etc.)
• HLF provides an open smart contract model with the flexibility to implement any desired
solution: account model, UTXO model, structured data, unstructured data, etc.
Global state storage structures and update procedures • each peer node is keeping its own copy of the ledger
• ledger consists of two parts: world state and the blockchain
• currently supported CouchDB (a JSON document store) and LevelDB (default key/value state
database) for the StateDB

• update process: endorsing policy requires response on transactions from all peers before
further processing; subsequently propagated and queries are identical
• pluggable consensus enables performance at scale
• voting-based algorithms are advantageous in that they provide low-latency of finality/confirmation
Limitations
• no concept of tokens, no sidechaining
A3.3 Hyperledger Fabric: Performance
Supported transaction rate (TPS) In [95], the authors evaluate the throughput of HLF by conducting experiments on an Amazon AWS EC2
(c4.2xlarge instance) with Intel E5-1650 8 core CPU, 15GB RAM and 128GB SSD hard drives. In these
experiments, the authors only run 1 blockchain node, thus the overhead of consensus is essentially
negligible. The evaluation workload is based on a simple cash transfer smart contract that allows the
creation of accounts, the issuance and the transfer of tokens. The following figure shows the log-log plot
of average throughput for transactions that transfer tokens.
95
Pongnumkul, Suporn, Chaiyaphum Siripanpornchana, and Suttipong Thajchayapong. "Performance analysis of private blockchain platforms in varying
workloads." 2017 26th International Conference on Computer Communication and Networks (ICCCN). IEEE, 2017.

In [96], the authors perform their own sets of experiments to evaluate the transaction throughput of HLF
by also varying the workloads that are submitted to the network. The network is comprised by a total of
4 peers and 1 orderer. Their results are depicted in the following figure:
96
Baliga, Arati, et al. "Performance characterization of Hyperledger Fabric." 2018 Crypto Valley conference on blockchain technology (CVCBT). IEEE, 2018.

PharmaLedger – Blockchain platform research

PharmaLedger – Blockchain platform research

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to PharmaLedger – Blockchain platform research

Similar to PharmaLedger – Blockchain platform research (20)

More from PharmaLedger

More from PharmaLedger (20)

Recently uploaded

Recently uploaded (20)

PharmaLedger – Blockchain platform research