PharmaLedger – Blockchain platform modifications and interoperability

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.4 Blockchain platform modifications and
interoperability
Deliverable No D3.4
Work package No. and Title WP3 PharmaLedger Architecture and Reference Implementation
Version - Status v1.0
Date of Issue 28/06/2021
Dissemination Level Confidential (CO)
Filename
D3.4 Blockchain platform modifications and interoperability -1st
Iteration_v1.0
Ref. Ares(2021)6148639 - 08/10/2021

PharmaLedger – 853992 | Deliverable D3.4 v1.0 | CONFIDENTIAL 2/25
DOCUMENT INFO
Authors
Author Organisation
Sînică Alboaie RomSoft (RMS)
Ana Balan RomSoft (RMS)
Espen Kon EKON Modeling Software Systems Ltd (EKN)
Document History
Date Version Editor Change Status
1/01/2021 0.1 Sînică Alboaie Table of contents and Initial content Draft
24/06/2021 0.2
Sînică Alboaie
Ana Balan
Cosmin Ursache
Continuous input in sections Draft
25/06/2021 0.3 Ana Balan Review, editing and formatting Draft
28/06/2021 0.4 Espen Kon
Separate executive summary and
add an introduction.
Review, editing and structure
formatting
Draft
29/06/2021 0.5 Ana Balan Review and formatting Final
29/07/2021 1.0 M.E Beltran Final review, formatting Final
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.

TABLE OF CONTENT
EXECUTIVE SUMMARY................................................................................................................................. 4
Introduction......................................................................................................................................... 5
R&D regarding the Platform modifications and interoperability ........................................................ 7
Improve the OpenDSU SDK open-source code............................................................................ 7
Improvements the OpenDSU APIHub.......................................................................................... 8
Implementation of the Interchain Layer (BDNS) ......................................................................... 9
Optimistic Execution Proposal................................................................................................... 10
Blockchain platform modifications.................................................................................................... 10
Short introduction of the main OpenDSU Concepts.................................................................. 10
3.1.1 DSUS as data and code referenced by KeySSIs.................................................................. 11
3.1.2 Bricking DSUs in Brick Storages.......................................................................................... 12
3.1.3 KeySSIs............................................................................................................................... 13
3.1.4 BricksLedger component ................................................................................................... 15
3.1.5 Smart Contracts in OpenDSU............................................................................................. 15
Challenges discovered while implementing PharmaLedger Platform............................................... 17
Innovations regarding smart contracts execution............................................................................. 18
Changes regarding deployment of the blockchain platform ............................................................. 20
CONCLUSION ............................................................................................................................................. 21
Annex 1: Abbreviation....................................................................................................................... 22
BIBLIOGRAPHY................................................................................................................................... 23
LIST OF FIGURES
Figure 1 Blockchain layers (logical view) ..................................................................................................... 5
Figure 2 Blockchain layers (a view on types of software artefacts)............................................................. 5
Figure 3 Near-Chain/Off-chain .................................................................................................................... 6
Figure 4 OpenDSU Core concepts.............................................................................................................. 11
Figure 5 A BrickMap .................................................................................................................................. 12
Figure 6 DSU Anchoring............................................................................................................................. 13
Figure 7 Syntax of KeySSI Identifiers.......................................................................................................... 13
Figure 8 BricksLedger................................................................................................................................. 15
Figure 9 APIHub Web Endpoints and Smart Contracts.............................................................................. 16
Figure 10 Optimistic Execution in BricksLedger......................................................................................... 18
Figure 11 HTTPS communication between APIHub and blockchain node................................................. 20

EXECUTIVE SUMMARY
The purpose of this deliverable, D3.4 Blockchain platform modifications and interoperability, is to describe
the change performed in the platform to meet the challenges in the PharmaLedger project, with its
interoperability needs. It includes all the activities required to modify and improve the prerequisite
blockchain technologies used to build the PharmaLedger platform.
This deliverable is related to concepts and technologies explained deliverables:
• D3.1: PharmaLedger Framework Architecture for Healthcare Industry -1st Iteration [1]
• D3.3: Blockchain platform research [2]
• D3.10: First Reference Implementation of PharmaLedger platform [3]
Based on research and the use case implementations, this deliverable improved the prerequisite
blockchain technologies used by the PharmaLedger platform.
We structure this deliverable as follows:
• Introduction to blockchain layers and the OpenDSU APIHub components
• Describe the Platform modifications and interoperability
• Describe the OpenDSU modifications
• Describe the new emerged requirements while implementing PharmaLedger Platform
• Architecture improvements related to smart contracts
• Describe the deployment of the blockchain platform
We concluded this deliverable by elaborating on the next steps of the blockchain platform development.

Introduction
To understand better the blockchain platform architecture, we should first understand the layering view
of the blockchain platform, containing three (3) main layers.
Figure 1 Blockchain layers (logical view) visualises the blockchain platform structured layers.
• Layer 0 – Network: the networking layer and provides the interconnectivity between the nodes
(replicas) of a blockchain domain.
• Layer 1 – Consensus: the consensus layer includes the consensus-building method and is usually
called the "on-chain" layer.
• Layer 2 – DSUs: the DSUs layer includes off-chain processing.
Figure 1 Blockchain layers (logical view)
We designed the DSUs as off-chain storage capabilities to ensure scalability and confidentiality
constraints. In addition, we interpreted the OpenDSU as "near-chain" to differentiate it from other types
of "off-chain". The DSU concept explained in the D3.1 deliverable PharmaLedger Framework Architecture
for Healthcare Industry [1].
We use the term MAH (Manufacturers) to align definitions with the pharma companies.
APIHub is a backend provided by OpenDSU. It is essential to notice the APIHUb roles in Network layer 0
and Consensus layer 1 in the blockchain network.
The most prominent software components of the PharmaLedger platform, as visualised in Figure 2
Blockchain layers (a view on types of software artefacts) include OpenDSU APIHub on the Network Layer
0, a blockchain technology that achieves consensus and OpenDSU SDK in DSU Layer 2.
Figure 2 Blockchain layers (a view on types of software artefacts)

The OpenDSU APIHub component serves as the main "backend" component for all the PharmaLedger use
cases and typically will be instantiated separately for each use case. For security reasons (to get the
trustless aspect promised by the blockchain technologies), we expected that each MAH deploys and
control a separate APIHub.
The Consensus Layer 1 consists of the deployments of blockchain networks doing consensus. In OpenDSU
we have support for anchoring in Ethereum blockchains (Quorum) [4], [5], [6], Hyperledger Fabric
(experimental) [7] [8] [9] [10] [11] [12] [6] and using the OpenDSU BricksLedger [13] [14] [15] [16].
The DSU Layer 2 consists mainly of the OpenDSU SDK library [17] created by the PrivateSky project [18]
and got improvements from PharmaLedger [19] and other research and commercial projects.
Figure 3 Near-Chain/Off-chain
The main purpose of OpenDSU [20] is to orchestrate the process by obtaining a widely accepted standard
for near-chain data storage. Near-chain data storage refers to data that is not stored on a ledger (e.g.,
blockchain) but is rather anchored [21] in a ledger for integrity, security, and efficiency purposes.
In OpenDSU [20], the near-chain concept is subsumed by the off-chain concept [22] [23] [24]. We identify
as far-chain everything else that is off-chain but not near-chain as far-chain.
There is no clear differentiation in the off-chain concept between what data closely connected with a
blockchain and what is indirectly connected (or not at all). Therefore, we distinguish between near-chain
and far-chain. The near-chain data storages aim to get properties similar to the on-chain data without
losing privacy and performance.
In this document, we explain PharmaLedger contribution to the OpenDSU open-source project with
proposals, use case validation and code.
The main contribution of this activity to the PharmaLedger project and the OpenDSU is the discovery of
the opportunity to improve an OpenDSU standard component called BricksLedger [16] to optimise the
performance of DSUs anchoring using what we call "optimistic execution of the smart contracts". The
"optimistic execution" is described in this deliverable and contains unpublished research results that will
be further developed and refined.

R&D regarding the Platform modifications and interoperability
Improve the OpenDSU SDK open-source code
Req. ID #BL001
Req. Short Title Improve the OpenDSU SDK open-source code
Descriptions
(User Stories)
Implement collaboration with the external teams contributing to the
OpenDSU open-source code various OpenDSU SDK improvements required
by the PharmaLedger use cases.
Stakeholders Pharmaledger organisation members, Operation IT, use case developers
Status This activity is performed in Task T3.6 and documented in the D3.10
deliverable [3]
OpenDSU SDK APIs
[17]
Contribution
anchoring Multi-domain for the same DSU required by ePI use cases (and possibly
others)
cache PharmaLedger required optimisations of Self Sovereign Application [25]
loading time
contracts Feedback to the BricksLedger concept. The opportunity for the optimistic
execution happened because of the interaction between PrivateSky [18]
team with PharmaLedger [19]
crypto Contributed with ECIES encryption [26] [27] [28]documented in D3.8 [29]
db Feedback to the OpenDSU DB concept. Plans to help OpenDSU Open-
Source project with new features/components that will facilitate the
integrations
dt Contributed with new features in D3.10 [3].
error Feedback to the OpenDSU error handling concept. Plans to help
OpenDSU Open-Source project with better error handling
http Feedback to the OpenDSU JWT authentication [30] [31]. Plans to help the
OpenDSU Open-Source project with new features.
keyssi Plans to help OpenDSU Open-Source project with new types of KeySSIs

OpenDSU SDK APIs
[17]
Contribution
ledger Feedback to the OpenDSU ledger and tokens based on anchors. Plans to
help the OpenDSU open-source project with new features in the thesis
area.
sc Feedback to the OpenDSU security context concept. Plans to help the
OpenDSU open-source project with new features.
system Plans to help OpenDSU open-source project with better documentation
tests PharmaLedger contributed with unit testing and integration testing.
validationStrategies These contributions are part of task T3.4 and T3.5 and will be reported in
their corresponding deliverables.
w3cdid These contributions are part of task T3.4 and T3.5 and will be reported in
their corresponding deliverables.
workers Help the OpenDSU open-source project with feedback from the
performance tests we are creating.
Improvements the OpenDSU APIHub
Req. ID #BL002
Req. Short Title Improve the OpenDSU APIHub
Descriptions
(User Stories)
Implement in collaboration with the external teams contributing to the
OpenDSU open-source code various APIHub improvements required by the
PharmaLedger use cases.
Status This activity overlaps with activities performed in Task T3.6 and documented
in the D3.10 deliverable [3].
In this deliverable, we insist on documenting research activities
corresponding with the BricksLedger OpenDSu component.
Req. ID #BL002
Req. Short Title OpenDSU Anchoring for Ethereum [32]

Descriptions
(User Stories) Implement anchoring for Ethereum
Status in M18 PharmaLedger contributed to the OpenDSU open-source code with
Ethereum (Quorum) [4] [5] anchoring. The APIs developed for this activity
described in the D3.10 deliverables [3].
Plan for M36 Depending on the decision of the use cases, this implementation could be
improved by the PharmaLedger consortium. Currently ePI use cases decided
to use Quorum based anchoring.
Req. ID #BL003
Req. Short Title OpenDSU Anchoring for Hyperledger Fabric [9] [10] [11]
Descriptions
(User Stories) Implement anchoring for Hyperledger Fabric [9] [10] [11]
Status in M18 PharmaLedger contributed to the OpenDSU open-source code with a draft
version of the Hyperledger Fabric. This is currently a prototype and as we do
not recommend Hyperledger Fabric for the use cases, we did not document
in details these results.
Plan for M36 Depending on the decision of the use cases, if they decide to use Hyperledger
Fabric for anchoring, this implementation could be improved by the
PharmaLedger consortium.
This activity is reflected partially by the D3.10 deliverable [3]. In the following more deliverable D3.5,
Blockchain platform modifications and interoperability – Final Iteration, we plan to document the
PharmaLedger contributions to the OpenDSU code corresponding to the blockchain platform.
Implementation of the Interchain Layer (BDNS)
Req. ID #BL004
Req. Short Title Implementation of the Interchain Layer (BDNS)
Descriptions
(User Stories)
BDNS as an Interchain Layer offered by OpenDSU
Interchain Anchoring

Status in M18 Initial research suggests the implementation will be based on the
BricksLedger concept from OpenDSU.
Plan for M36 Should be ready
This activity is reflected partially by the D3.10 deliverable [23]. In the following more deliverable D3.5,
Blockchain platform modifications and interoperability – Final Iteration, we plan to document the
PharmaLedger contributions to the OpenDSU code corresponding to the blockchain platform.
Optimistic Execution Proposal
Req. ID #BL005
Req. Short Title Integrate Optimistic smart contracts [33] [34] [35] execution in
PharmaLedger
Descriptions
(User Stories)
Document and implement in collaboration with the external teams
contributing to the OpenDSU open-source code Bricks Ledger
improvements required by the PharmaLedger use cases.
Status in M18 The current proposal for the optimistic smart contracts' execution is
evaluated and discussed with the OpenDSU team (they have the most
knowledge to start an implementation). Depending on their results,
PharmaLedger could allocate resources to help this development.
Currently, PharmaLedger contributed only to the initial proposal as this
deliverable documents it.
Plan for M36 The PharmaLedger use cases could use this research result after scientific
and security evaluation. As described in the next chapter, we plan to publish
a scientific article.
Blockchain platform modifications
Short introduction of the main OpenDSU Concepts
The detailed elaboration of the OpenDSU described in the OpenDSU Blue Paper [13].
This chapter briefly introduces the fundamental concepts to enhance the readability of this document.
To learn more about the OpenDSU, please refer to the whole Blue Paper [13] and the public
documentation site for OpenDSU [20].

3.1.1 DSUS as data and code referenced by KeySSIs
Figure 4 OpenDSU Core concepts
From the perspective of OpenDSU [20], a DSU is an entity that exists temporarily in an execution
environment [36] (Usually in a sandboxed container). Logically, a DSU can be understood as a micro file
system that contains data and code, which booted in a sandboxed environment. A DSU offers service via
DSU APIs [3] (Presented in deliverable D3.10 [3]). I can think of the DSU as a key/value micro-database
(each path to a file being the key, and the value is the file's contents).
Physically, the DSUs are stored as "bricks" in a "brick storage" and encrypted using symmetric encryption.
The bricks can be stored locally, remotely, in the cloud, and on just about any storage media. An essential
key for decrypting bricks is a secret key that we will temporarily refer to as KeySSIs. Each Brick is encrypted
with a different key. However, there are special bricks we call BrickMaps (or BarMaps in the PrivateSky
reference implementation of OpenDSU). The BrickMaps also store the encryption keys for the Bricks they
are referencing, while remaining constant and referential by their hash. However, DSUs are flexible and
most times do not remain constant and can be deleted. In such cases, multiple BrickMaps will exist in the
history of each DSU. Anchors store the association between DSU identity, with the list of their hashes, for
BrickMap bricks. In the following chapters, we elaborate thoroughly on the details of anchors.
The Execution Environment will interact with a DSU in three (3) significant ways:
● Read/write files from the file system
● Read/write keys
● Call the DSU APIs
Each of the three (3) ways of interacting with DSUs are useful and should be decided accordingly with the
specific use case. It is important to note that any write operation to a DSU will be observable by other
Execution Environments only after the new version is successfully anchored.

3.1.2 Bricking DSUs in Brick Storages
Figure 5 A BrickMap
DSUs are anchored in the blockchain. With the anchoring feature [19], we can digitally sign data and code
in the initial version and all subsequent versions/updates. We will introduce DSU concepts in the following
sections (see also [15])
The Brick Storages represent the core element of the OpenDSU. Brick Storages are essentially simple web
services capable of storing and retrieving a brick for clients that know the Brick hash. The basic
implementation of Brick Storages is straightforward and offers a tool that works well in an open,
permissionless network. Supplementary sophistications are required when we have to implement access
revocation to the shared data or implement an expiration date for access to data as requested by a third
party.
If needed in the use case, the DSU anchoring could be provided by a centralised system. For example, a
use case in which anchoring is needed only to support enhanced internal audit. This is perfectly fine as it
could be later decentralised if needed or required.
OpenDSU facilitates blockchain platforms that support multiple blockchains and eventually even support
heterogeneous blockchains (blockchains with different capabilities and different security models). For
OpenDSU, the primary purpose of those blockchains is to work as notarization mechanisms for DSUs. DSU
anchoring can be used by countless use cases or even support hierarchically [37] organised ledgers by
offering a naming system/index for the content stored in the ledger's hierarchy. In the following chapters,
we will explore the solutions proposed by OpenDSU for anchoring DSUs to the ledger(s). While researching
the problem of anchoring data to the blockchain for integrity and traceability, we realised the need for at
least two types of anchors, currently: implicit and explicit anchors. Explicit anchors are further divided
into heavy and light anchors, detailed in the next subchapters.

Figure 6 DSU Anchoring
3.1.3 KeySSIs
The purpose of the KeySSI concept is to provide blockchain-anchored identities for companies and
individuals and resources and processes. The idea of KeySSI is more general than the concept proposed
by the W3C DID web standard [38]. DIDs and KeySSIs are two different methods of creating SSIs (Self
Sovereign Identifiers).
Also, an important innovation proposed by KeySSI is the capability to use as secret symmetrical
encryption/decryption keys for DSUs (or for parts of the DSUs).
A KeySSI is always accompanied by other KeySSIs derived from it or from which it itself was derived; hence
KeySSIs travel together. One can view derivation as a form of access delegation: someone who holds a
KeySSI with a higher access level delegates accesses to lower levels. Typically (but not always), KeySSIs are
anchored in ledgers for integrity and traceability using a special KeySSI called Zero Access SSI (zaSSIs).
Having a zaSSI gives you access only to a list of hashes (the versions of the anchored DSU) but nothing
else. Without an upper-level KeySSI, the zaSSI has no practical value except providing insight into the
number of versions of a DSU.
In the following diagram, we provide the general intuition of the KeySSI Syntax.
Figure 7 Syntax of KeySSI Identifiers
Examples:
ssi:seed:ePI.pharma:RANDOMSEEDKEY:HASHRANDOMKEY
ssi:za:ePI.pharma:HASHSERIALISATION:HASHPUBLICKEY

The syntax of KeySSI is inspired by the W3C DID [38] and is similar but has several key differences, such
as:
"ssi": it starts with the "ssi" string and allows a user to define additional attributes as; types, ledger
domains, etc. Equivalent to the DID method string, SSI also consists of types (or subtypes). The purpose
of types is to add different types of KeySSIs and not introduce incompatible W3C DIDs. The different
KeySSIs types are designed to be compatible, which allows for a standard KeySSI resolver to implement
all the standard types. Another unique aspect of the SSI syntax compared with the W3C DIDs is that the
3rd group in the identifier represents a ledger/blockchain domain. OpenDSUs are based on the objective
that KeySSI supports multiple, hierarchical ledgers/blockchains. The actual definition of the blockchain
domain and the proposed implementation on resolving these domains are part of the OpenDSU
specification and may be found in the BDNS chapters [39].
"Type-Specific Substrings": contains strings that typically should contain enough random bits for good
security.
"Control Substring": part of the KeySSI is used by the anchoring services to validate the requests for a
new version of the anchored DSU. The algorithm used for verification is type-specific.
"vn": field is a string reflecting the version number of the type. The vn should not be confused with DSU
versions: vn refers to the version number of the KeySSI type. The "vn" field is optional and defaults to
"v0". The OpenDSU standardisation body should approve each new version. Each version has an
associated configuration that specifies the cryptographic primitives and conventions detailed in a
separate Open DSU RFC [20]. For example, these RFCs will determine what hash functions and methods
should be used by the anchoring service [21].
"hint": part is optional and subtype-specific. Typically, it hints at some optional information for the KeySSI
resolver, for example, the favourite server proposed by the owner of the KeySSI. This part could also be
called "tag" as it is a way of tagging KeySSIs for specific purposes. For example, tagging a DSU containing
sensitive information to help indicate that it will require additional data protection mechanisms in place.
This Hint (or Tag) is a way of extending the KeySSI for countless purposes that could not be imagined
initially.

3.1.4 BricksLedger component
Figure 8 BricksLedger
PrivateSky created the concept of BricksLedger as an approach to transform any database or blockchain
into a ledger appropriate for OpenDSU anchoring [21]. In this way, we mitigate the concerns about the
performance (speed and throughput) and the confidentiality of the on-chain transactions. OpenDSU starts
from the idea that no size fits all and, therefore, hierarchical blockchain [37] in a technology-agnostic
approach. With BricksLedger, it is possible to get a blockchain level audit as for standard databases. The
central concept is based on adding between the clients (or consumers of the database data) an
intermediate layer that is a "command" design pattern [40]. The implementation also resembles the
"event sourcing" concept [41] [42]. These commands are executed and update the world state cache. The
commands are registered inside blocks stored as bricks in the APIHub Bricking services to gain a good level
of audibility.
3.1.5 Smart Contracts in OpenDSU
In OpenDSU we differentiate between normal on-chain smart contracts and the near-chain smart
contracts. Smart contracts implemented at the level of the DSUs called "secret smart contracts" often
renamed "confidential smart contracts" by the OpenDSU team. In the following chapters, we will propose
a concept called "optimistic smart contract execution" [34] [33] that refers to online smart contracts.
In the following deliverables, we will also document the secret smart contracts. Still, the use cases at this
stage avoided much of the complexity by not sharing SeedSSIs keys between partners (only ReadSSI that
gave access in reading mode are now required).

As the PharmaLedger use cases advances, it is possible that special techniques of implementing "secret"
or "confidential" smart contracts will become relevant and will be addressed accordingly.
OpenDSU Support for smart contracts assumes that any blockchain domain offers support for at least four
smart contracts: Anchoring [43], Governance, BDNS [39] and Metadata.
In the next table we explain the role of these smart contracts.
Smart Contracts Description
Anchoring Implements Blockchain Anchoring for OpenDSU
Governance Implements the ability to control the enrolment of new members in a blockchain
network. Controls the access control for the anchoring smart contract.
BDNS Implements the ability to have hierarchical Blockchain Domains. [37]
Metadata Implements constraints and parameters of the blockchain domain or of the brick's
ledger. For example, policies regarding the automated deletion of bricks (for data
GDPR specific minimisation [44]) Could be implemented using the Metadata Smart
Contract. This is an active research area for PharmaLedger use cases and will be
documented in the next deliverables regarding T3.3, T3.4 and T3.5.
Other Contracts A blockchain domain can deploy various other smart contracts.
Currently, only the Anchoring smart contract is fully utilised by the PharmaLedger but future
developments in interchain anchoring and governance will require customisation for the standard
OpenDSU smart contracts regarding BDNS [39], Governance and Metadata. In the following deliverables
regarding T3.3, we will document all the relevant developments and innovations.
.
Figure 9 APIHub Web Endpoints and Smart Contracts
The above diagram shows the significant endpoints (better documents in T3.6 deliverables) and the
corresponding smart contracts.

Challenges discovered while implementing PharmaLedger Platform
During the ePI use case implementation, we experimented with integrating the APIHub with the Quorum
blockchain [4]. In the following table, we document the major challenges that stay at the base of the
improvement ideas for the Brick Ledger component from PrivateSky.
# Challenge Description
#1 Transaction's
confirmation time
(speed)
Any call in the Quorum blockchain [5] takes a few seconds to be
answered. The business logic required a sequence of 2-3 calls, and
that made for a poor user experience (a user expecting between 5
and 10 seconds for an operation)
#2 Throughput The scalability of the Quorum blockchain [5] is limited to a few
hundreds of transactions per second (see also our research from
T3.2)
#3 Corporate Policies
regarding security and
deployment
The custom protocols of the blockchains replica communication
(DevP2P [45]) has created the tendency of pharma companies to
push for a weaker security model.
In particular, discussions tended to use a single cloud provider and
a virtual network offered by this single provider to host all
blockchain nodes.
The WP3 Architecture leaders are against taking this shortcut, and
we are actively working to create better solutions regarding the
deployment and even the blockchain technologies themselves.
The BricksLedger can be adjusted in ways that can remove the risks
associated with bad deployments of the Blockchain network.
We will continue to research this area during the evolution of the
PharmaLedger use cases.

Innovations regarding smart contracts execution
To mitigate challenge #1 (and partially #2 and #3 in an operational environment), we proposed
improvements of the BricksLedger architecture, as presented below:
Figure 10 Optimistic Execution in BricksLedger
Compared with Figure 8 BricksLedgerFigure 8 BricksLedger, with Figure 10 Optimistic Execution in
BricksLedger, we can observe that the world state got splitter into different databases called optimistic
world state and validated world state.
Similarly, the execution of commands takes place in two ways: an optimistic execution and a validated
one.
The components for creating blocks, transmitting blocks to the other nodes (Broadcaster) and the
consensus component are better highlighted but play the same apparent roles.
The most important change is given by the insight that there are situations in which smart contract
methods can be executed in an "optimistic" way, i.e., a way that is not validated by the consensus
algorithm.
This insight comes from the fact that anchoring commands can be implemented in a "self-consistent" way
because they do not require protection against "replay attacks". The anchoring command implicitly
implements a "nonce based mechanism". Each anchoring operation contains a signature that binds to the
request with the last anchor variant (that is believed to be correct by the signer). This mechanism is useful
for preventing "replay attacks" which in this case would only lead to network difficulties (creation of
redundant anchors) or the fake restoration of old versions of the DSUs. Without these prevention
mechanisms, a more sophisticated off-chain validation mechanism would be required. By implementing
the anchoring to contain the last valid hash link we avoid "replay attacks".
Additionally, we have observed in PharmaLedger use cases that most of the anchors are controlled by a
single actor. The other typical blockchain is called "double spending" attacks. This attack could happen for
technical reasons (e.g., network partitions) or because of malicious intentions. In the case of anchoring,
DSUs controlled by a single actor, there are few benefits from malicious "replay attacks". By design, in

most cases, the optimistic execution is planned to happen in nodes controlled by the owner of the
anchors; therefore, the partitioning of the network is not a real issue.
In any case, implementing a validated execution (an execution that updates the validated world state as
in the usual blockchain) will correct any issue very fast. The advantages of the optimistic execution that
we proposed for BricksLedger is that we can answer the clients' requests very fast because the chances
of consensus invalidating the commands are zero in most cases. Additionally, the overall performance and
scalability of the blockchain will be improved by using this approach for anchoring.
Currently, the Quorum anchoring is implementing the anchoring in a Solidity smart contract [46] [47] but
by implementing this optimistic execution, we foresee the ability to take the world state from Quorum
and put it in an external database. Basically, the Quorum (or other blockchains) consensus could be made
only with the hash links of the blocks proposed by validators (called PBlock from Proposed Blocks) and
substantially reducing the pressure on on-chain computation. A PBlock could contain thousands of
commands (transactions) that will not be visible to the blockchain but will benefit from the blockchain
consensus. Therefore, the bottleneck on scalability will be the CPU power of the validators (that now can
be much easier to be parallelised), and then any blockchain could be transformed into a "distributed
orderer" for BricksLedger to provide consensus but not the actual execution of the commands. The
blockchain's throughput (a few hundreds of transactions per second) could be amplified thousands of
times.
The OpenDSU SDK APIs should be modified to detect both types of execution (optimistic and validated)
and thereby offer the tools for programmers.
Automated detections of inconsistencies between the optimistic and validated execution are possible,
and an audit log will be created automatically. This research will continue, and we believe that it will be
finalised in the next few months.
We are confident that this approach could be very beneficial for many PharmaLedger Use Cases and solve
any scalability issues.

Changes regarding deployment of the blockchain platform
Because of challenge #3, we were forced to depart from the initial plans documented in the deliverables
on task T3.10. Therefore, it became essential to separate the deployment for APIHub from the blockchain
node.
Figure 11 HTTPS communication between APIHub and blockchain node
In the diagram above, the clusters for the deployment of APIHub in the internal network of companies
(MAH = Marketing Authorization Holder) and clusters for the blockchain network are highlighted.
Communication between the two clusters is done via HTTPS to eliminate concerns about non-compliance
with companies' security policies.

CONCLUSION
In this deliverable, we documented the development research achievements regarding the PharmaLedger
blockchain platform and all the activities required to modify and improve the prerequisite blockchain
technologies used to build the PharmaLedger platform. During this task, while implementing the platform,
a series of challenges were identified and documented. In addition, innovations regarding smart contracts
execution and changes regarding deployment of the blockchain platform were proposed. We believe that
the implementation of use cases will generate further suggestions for improvements.
These developments research will continue and provide further inputs for the prerequisite blockchain
technologies used to build the PharmaLedger platform documented in the following deliverables.

Annex 1: Abbreviation
Abbreviations /
Acronym
Description
DSU Data Sharing Unit
MAH Manufacture
API Application Programming Interface
SDK software development kit
ePI Electronic Product Information
ECIES Elliptic Curve Integrated Encryption Scheme
db database
JWT JSON Web Token
KeySSI Key Self Sovereign Identifier
IT Information Technology
BDNS Blockchain Domain Naming Service
RFC Request for Comments
W3C World Wide Web Consortium
DID Decentralised Identifier
SSIs Self-Sovereign Identifiers
vn Version number
GDPR General Data Protection Regulation
DevP2P Development peer to peer
WP3 Work Package 3
PBlock Proposed Block
CPU Central Processing Unit
HTTPs Hypertext Transfer Protocol Secure

BIBLIOGRAPHY
[1] P. Consortium, „D3.1 PharmaLedger framework architecture,” 2020.
[2] P. Consortium, „D3.3 Blockchain platform research,” 2020.
[3] P. Consortium, „D3.10 First Reference Implementation of PharmaLedger
platform,” 2021.
[4] Kaleido, „Quorum,” [Interactiv]. Available: https://www.kaleido.io/blockchain-
platform/quorum.
[5] ConsenSys, „Build on Quorum, the complete open source blockchain platform for
business,” [Interactiv]. Available: https://consensys.net/quorum/.
[6] B. F. Organisation, Beyond Theory: Getting Practical With Blockchain,
bostonfed.org, 2019.
[7] H. Organisation, „HyperLedger Fabric,” [Interactiv]. Available:
https://www.hyperledger.org/use/fabric.
[8] H. Organisation, „Open, Proven, Enterprise-grade DLT,” [Interactiv]. Available:
https://www.hyperledger.org/wp-
content/uploads/2020/03/hyperledger_fabric_whitepaper.pdf.
[9] HyperLedger, „Hyperledger Fabric Model,” 2020. [Interactiv]. Available:
https://hyperledger-fabric.readthedocs.io/en/release-2.2/fabric_model.html.
[10] HyperLedger, „What’s new in Hyperledger Fabric v2.x,” 2020. [Interactiv].
Available: https://hyperledger-fabric.readthedocs.io/en/release-
2.2/whatsnew.html.
[11] IBM, „What is Hyperledger Fabric?,” [Interactiv]. Available:
https://www.ibm.com/topics/hyperledger.
[12] Investopedia, „HyperLedger Fabric,” [Interactiv]. Available:
https://www.investopedia.com/terms/h/hyperledger-fabric.asp.
[13] S. Alboaie, M. Cuomo, C. N. Ursache, D. Sava, A. Gheorghiu, A. Shah și L. Alboaie,
OpenDSU Bluepaper (Draft 2.0), opendsu.com, 2020.
[14] M. Cuomo și S. Alboaie, OpenDSU White Paper (Draft 0.9), opendsu.com, 2020.
[15] S. Alboiae și V. Gerard, „DSU (Data Sharing Units) Introduction,” [Interactiv].
Available: https://opendsu.com/?openDSU/rfc001.html.
[16] A. Sinica, „Brick storages,” [Interactiv]. Available:
https://opendsu.com/?openDSU/rfc003.html.
[17] „Dev documentation SDK,” [Interactiv]. Available: https://opendsu.com/?dev-
doc/rfc060.html.
[18] „PrivateSky,” [Interactiv]. Available: https://profs.info.uaic.ro/~ads/PrivateSkyEn/.
[19] „PharmaLedger,” [Interactiv]. Available: https://pharmaledger.eu/.
[20] „OpenDSU,” [Interactiv]. Available: https://opendsu.com/?home.
[21] S. Alboaie și B. Mastahac, „Anchoring,” [Interactiv]. Available:
https://opendsu.com/?openDSU/rfc004.html.

[22] IBM, „Why new off-chain storage is required for blockchains,” 2015. [Interactiv].
Available: https://www.ibm.com/downloads/cas/RXOVXAPM.
[23] Investopedia, „Off-Chain Transactions (Cryptocurrency),” 2021. [Interactiv].
Available: https://www.investopedia.com/terms/o/offchain-transactions-
cryptocurrency.asp.
[24] Etorox, „What is the difference between on-chain and off-chain transactions?,”
[Interactiv]. Available: https://etorox.com/blockchain-academy/what-is-the-
difference-between-on-chain-and-off-chain-transactions/.
[25] S. Alboaie, N.-C. Ursache și L. Alboaie, „Self-Sovereign Applications: return control
of data back to people,” Procedia Computer Science, vol. 176, nr.
https://doi.org/10.1016/j.procs.2020.09.164, pp. 1531-1539, 2020.
[26] V. Shoup, A Proposal for an ISO Standard for Public Key Encryption (version 2.1).
[27] V. Gayoso Martínez, L. Hernández Encinas și C. Sánchez Ávila, „A Survey of the
Elliptic Curve Integrated Encryption Scheme,” JOURNAL OF COMPUTER SCIENCE
AND ENGINEERING, vol. 2, nr. 2, pp. 7 -13, 2010.
[28] N. P. Smart, „The Exact Security of ECIES in the Generic Group Model,” în
Cryptography and Coding, IMA International Conference on Cryptography and
Coding, Springer, 2001, pp. 73-84.
[29] P. Consortium, „D3.8 Reference implementation of advanced confidentiality
methods,” 2021.
[30] „Introduction to JSON Web Tokens,” [Interactiv]. Available:
https://jwt.io/introduction.
[31] J. M., C. B. și M. C., JSON Web Token (JWT) Profile for OAuth 2.0 Client
Authentication and Authorization Grants, PROPOSED STANDARD: rfc 7523, 2015.
[32] G. WOOD, „Ethereum: A secure decentralised generalised transaction ledger,”
yellow paper, file:///C:/Users/A/Downloads/Paper.pdf, 2014.
[33] P. S. Anjana, S. Kumari, S. Peri, S. Rathor și A. Somani, „Contracts, OptSmart: A
Space Efficient Optimistic Concurrent Execution of Smart,” în arXiv:2102.04875
[cs.DC], 2021.
[34] P. S. Anjana, S. Kumari, S. Peri, S. Rathor și A. Somani, „An Efficient Framework for
Optimistic Concurrent Execution of Smart Contracts,” în 2019 27th Euromicro
International Conference on Parallel, Distributed and Network-Based Processing
(PDP), Pavia, Italy, 10.1109/EMPDP.2019.8671637, 2019.
[35] Q. Nguyen, A. Cronj și M. K. , „OV: Validity-based Optimistic Smart Contracts,” în
Distributed, Parallel, and Cluster Computing (cs.DC), arXiv:2004.04338 [cs.DC],
2020.
[36] M. Sabt, M. Achemlal și A. Bouabdallah, „Trusted Execution Environment: What It
is, and What It is Not,” în 2015 IEEE Trustcom/BigDataSE/ISPA,
10.1109/Trustcom.2015.357, Helsinki, Finland, 2015.
[37] A. Sinica, A. Lenuta, P. Zeev și I. Adrian, „Secret Smart Contracts in Hierarchical
Blockchains,” în Information Systems Development (ISD) , 2019.

[38] W. Standard, „Decentralized Identifiers (DIDs) v1.0 Core architecture, data model,
and representations,” https://www.w3.org/TR/2021/CRD-did-core-20210616/,
2021.
[39] S. Alboaie, N. C. Ursache, D. Sava și V. Gerard, „BDNS RFC 067 - OpenDSU SDK,”
2021. [Interactiv]. Available: https://opendsu.com/?dev-doc/sdk-
advanced/rfc067.html.
[40] J. E. McDonough, „Command Design Pattern,” în Object-Oriented Design with
ABAP , SpringerLink, 2017, pp. 255-264.
[41] A. Ryszewski, Comparative analysis of selected aspects of the standard
implementation of the Event Sourcing pattern and its proprietary implementation
in the Blockchain technology, Master diploma, 2021.
[42] M. Overeem, M. Spoor și S. Jansen, „The dark side of event sourcing: Managing data
conversion,” în 2017 IEEE 24th International Conference on Software Analysis,
Evolution and Reengineering (SANER), Klagenfurt, Austria, 2017.
[43] S. Alboaie, C. N. Ursache, D. Sava și V. Gerard, „Anchoring,” [Interactiv]. Available:
https://opendsu.com/?dev-doc/sdk-advanced/rfc069.html.
[44] S. Pinisetty, T. Antignac, D. Sands și G. Schneider, „Monitoring Data Minimisation,”
în Logic in Computer Science (cs.LO); Cryptography and Security (cs.CR); Formal
Languages and Automata Theory (cs.FL), arXiv:1801.02484 [cs.LO], 2018.
[45] E. P.-t.-p. networking, „ethereum/devp2p,” [Interactiv]. Available:
https://github.com/ethereum/devp2p.
[46] S. Bragagnolo, H. Rocha, M. Denker și S. Ducasse, „SmartInspect: solidity smart
contract inspector,” în 2018 International Workshop on Blockchain Oriented
Software Engineering (IWBOSE), 2018.
[47] C. Danner, Introducing Ethereum and Solidity, Foundations of Cryptocurrency and
Blockchain Programming for Beginners: Library of Congress Control Number:
2017936045, 2017.

PharmaLedger – Blockchain platform modifications and interoperability

More Related Content

What's hot

Similar to PharmaLedger – Blockchain platform modifications and interoperability

More from PharmaLedger

Recently uploaded

PharmaLedger – Blockchain platform modifications and interoperability