An Enterprise Architecture Approach
to Semantic Blockchain Interoperability
ao Sotto-Mayor
, Rafael Belchior
, Miguel Correia
and Andr
e Vasconcelos
INESC-ID, Instituto Superior T
ecnico, Universidade de Lisboa, Portugal
Blockdaemon Ltd., Dublin, Ireland
Enterprise Architecture, Blockchain Interoperability, Ontology.
Blockchain technology has revolutionized the way data is stored and accessed in a decentralized manner.
However, the lack of interoperability between such systems is an ongoing challenge hindering their wider
adoption. This document proposes a two-part solution composed of activities that aim to enhance semantic
interoperability between homogeneous and heterogeneous blockchain systems. The first part are the design-
time activities that consist of constructing an Archimate model, extracting its Resource Description Framework
(RDF) ontology, and assessing its correctness utilizing a semantic reasoner. The second part are the runtime
activities that involve leveraging the resulting ontology in a supply chain management application to validate
transactions among participants in a network of systems. The evaluation results are promising, demonstrating
that a shared ontology can support a transparent and accurate transaction validation approach. Thus, this work
is a significant step in proving that distributed ledger technologies can benefit from enterprise architecture
techniques to improve their interoperability.
Distributed ledger technology (DLT) refers to net-
works of computers that store databases in a dis-
tributed way, distinguishing them from traditional
databases confined to a single server. This decen-
tralized structure enhances security by making data
tampering more challenging for malicious entities.
Blockchains store data in a chain of blocks and are
a specific type of DLT. Each block contains multiple
transaction records, and once appended to the chain,
a block becomes immutable. This mechanism estab-
lishes a permanent and transparent ledger of all trans-
actions conducted in a network. In addition to be-
ing used to record and track monetary transactions,
blockchain technology can potentially support appli-
cations in several other domains, including supply
chain management, voting systems, and identity veri-
fication (Peck, 2017).
Private or permissioned blockchains are dis-
tributed ledger systems where access to the network
and validation of transactions is limited to an exclu-
sive group of entities. These blockchains provide
enterprises with several advantages in comparison
with permissionless blockchains. Firstly, data confi-
dentiality is enhanced since sensitive information is
shared only among trusted participants. Secondly,
they are highly scalable due to reduced network con-
gestion and faster transaction processing since the
number of participants is reduced compared to pub-
lic blockchains. Additionally, private blockchains of-
fer increased control and governance, enabling busi-
nesses to set rules and consensus mechanisms that
align with their specific requirements. Furthermore,
their usage enhances compliance, which makes them
a valuable asset for various use cases in industries
with high regulation (Underwood, 2016).
Interoperability, which refers to the ability of dif-
ferent systems and components to work together ef-
ficiently, is a quality attribute that has four layers:
the technical (further subdivided into functional and
structural), the semantic (including interpreting infor-
mation format and its meaning), the organizational,
and the legal (Kalogirou and Charalabidis, 2019). Re-
garding specifically the semantic layer of interoper-
ability, on the one hand information format pertains
to the structure and representation of data exchanged
between systems. This includes data types, encod-
ing methods, and communication protocols. On the
other hand, understanding the meaning embedded in
the information involves interpreting the data con-
text, semantics, and relationships, ensuring that the
Sotto-Mayor, S., Belchior, R., Correia, M. and Vasconcelos, A.
An Enterprise Architecture Approach to Semantic Blockchain Interoperability.
DOI: 10.5220/0012418500003690
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 26th International Conference on Enterprise Information Systems (ICEIS 2024) - Volume 2, pages 614-621
ISBN: 978-989-758-692-7; ISSN: 2184-4992
Proceedings Copyright © 2024 by SCITEPRESS Science and Technology Publications, Lda.
exchanged information is correctly understood by the
systems consuming it.
Over the last few years, there have been many at-
tempts to introduce a solution that will mitigate the in-
teroperability issues of blockchain systems (Belchior
et al., 2021; Belchior et al., 2023b). However, few
solutions focus on the semantic layer. While each
layer has its significance, the semantic layer will play
a key role in increasing interchain communication ef-
ficiency (Hardjono et al., 2019). By building systems
on a common ground of understanding, actions con-
ducted among systems with a high volume of cross-
chain transactions become faster, as there is less fric-
tion to translate concepts from one blockchain to the
The objective of this work is to explore enterprise
architecture (EA) mechanisms to produce an ontol-
ogy (Antunes et al., 2013) that individual systems can
leverage to build plugins, which are small and flexible
components executing their business logic on top of a
base architecture that includes the necessary elements
to achieve interoperability. EA offers standardizable
methods in the form of models that can facilitate the
intercommunication of distributed ledger technology
systems in the semantic layer by reducing ambiguity
in valuable processes such as interchain transactions.
A proof-of-concept (POC) presents the practical
aspects of this approach. Its scope is a network of per-
missioned blockchains owned by organizations with
interoperation needs with fellow members of a supply
chain consortium. The decision to restrict the POC to
private blockchains comes from the fact that systems
involving public blockchains operate with some in-
herently different concerns and requirements as men-
tioned above. Therefore, designing an EA model
targeting both would complicate the solution prema-
The results extracted from the conducted experi-
ments are encouraging, showing that the integrity of
the transaction validation process is enhanced when
following the proposed approach.
In summary, this paper introduces an EA that sup-
ports semantic interoperability between blockchain
systems and implements a POC that will leverage the
ontology extracted from its model. By proving the ap-
plicability and effectiveness of the proposed solution,
the aim is to show that EA techniques can be valu-
able for solving interoperability issues in blockchain
This paper is structured as follows. Section 2
gives an overview of the architecture and use case that
support the POC, followed by Section 3, which de-
scribes the proposed solution in detail. Next, Section
4 provides the evaluation strategy and its outcome.
Lastly, in Section 5, the authors discuss the conclu-
sions drawn from this study and outline future work.
This section presents important knowledge concern-
ing the proposed solution. Specifically, it provides an
in-depth analysis of Hyperledger Cacti (Montgomery
et al., 2020), as it forms the basis of the architec-
ture that supports business logic plugins (BLPs) used
for the interoperation of supply chain-related enti-
ties. Additionally, it describes the use case that will
demonstrate the capabilities of the proposed solution
along the remainder of the paper.
2.1 Hyperledger Cacti
Blockchain gateways are intermediary systems
that facilitate interoperability between different
blockchain networks. They act as bridges, enabling
data transfer across disparate blockchain platforms,
allowing them to exchange information and assets.
One example of a middleware framework that adopts
the concept of blockchain gateways is Hyperledger
Cacti. Built on the Hermes model (Belchior et al.,
2022), Cacti is an open-source solution that provides a
fault-tolerant middleware layer supporting blockchain
By implementing the protocols and mechanisms
introduced by Hermes, Cacti enables secure and reli-
able communication between diverse blockchain net-
works, opening up opportunities for cross-chain trans-
actions and the execution of smart contracts, which
are self-executing contracts with the terms of the
agreement written in a programming language like
Solidity (Dannen, 2017). These contracts automati-
cally execute and enforce themselves when predeter-
mined conditions are met, without the need for inter-
mediaries or third parties.
Figure 1: UML sequence diagram of an architecture sup-
ported by Hyperledger Cacti.
Figure 1 depicts the high-level interactions of
components utilizing Cacti. The client communicates
with multiple BLPs via Representational State Trans-
fer (REST) APIs. The BLPs then send the data to
Cacti Core, which serves as the central component re-
An Enterprise Architecture Approach to Semantic Blockchain Interoperability
sponsible for coordinating the exchange of data be-
tween the plugins and the connectors via connector
APIs. Lastly, each connector is responsible for inter-
facing with the respective blockchain.
2.2 Supply Chain Use Case
The use case chosen for the POC focuses on the sup-
ply chain domain. This choice comes from the fact
that this business sector inherently utilizes ambigu-
ous terms to describe processes, making it adequate
for demonstrating the value of the proposed solution.
The use case consists of three sequential data
transfers among three entities, where each entity
leverages a different type of blockchain for business-
specific reasons irrelevant to the study. A data trans-
fer is the process of copying information from one
DLT to another, and it involves specific data (e.g.,
manufacturer information) in most cases. This op-
eration can involve multiple steps, including an op-
tional intermediate processing step that may manipu-
late or analyze the data before sending it to the tar-
get chain. Data transfers are vital for ensuring the in-
teroperability and exchange of valuable information
across blockchains (Belchior et al., 2023a).
The data model comprises a business role, func-
tion, item, and process. That is, a Supplier may Sup-
ply a Bamboo Harvest to a Manufacturer in the con-
text of a Product Sale and so on. There is an obvi-
ous concern for preserving privacy through the en-
tire interoperation process among the three entities, as
in most cases, the transferred data includes sensitive
business information.
Figure 2: Supply chain use case BPMN diagram.
Figure 2 depicts a sample flow of transactions tak-
ing place among the three entities of the use case as
a Business Process Model and Notation (BPMN) di-
agram (White, 2004). To achieve interoperability be-
tween the three entities, Cacti is used. When an event
occurs in one system, a smart contract is invoked. The
Cacti Core then interacts with the appropriate Con-
nector (Fabric, Besu, or Quorum) to update the re-
spective blockchain.
This section presents a solution for achieving interop-
erability between two or more blockchain systems by
leveraging a common ontology that derives from an
EA model. The approach is divided into design-time
and runtime activities of the interoperation process to
ensure standardization. The former are the activities
that take place before the interoperation process has
begun. The latter are the activities that take place dur-
ing the interoperation process.
3.1 Design-Time Activities
At design time, a model is created using Archimate, a
modelling language for EA (Josey et al., 2016). This
model is the foundation for producing a shared vo-
cabulary as an RDF/XML ontology which represents
the structural and conceptual aspects of the Archimate
model in a machine-readable format (Decker et al.,
2000). Lastly, the HermiT reasoner is used to assess
the correctness of the extracted ontology (Bansal and
Chawla, 2014).
3.1.1 Enterprise Architecture Model Design
Ideally, this process is conducted by consortium
stakeholders to ensure alignment among participat-
ing entities. As they possess rich insights about the
meaning of terms and the specific format of messages
of each business area, close inter-collaboration de-
termines the scope and contents of the EA model.
Therefore, this should be an iterative process, and
the model may change significantly as the knowledge
grows. Furthermore, the European Interoperability
Reference Architecture (EIRA) (Commission, 2015)
should guide the design to ensure regulatory compli-
Figure 3 depicts the three layers of the supply
chain-specific EA created for the use case that was
defined in Subsection 2.2. The upper layer portrays
the Business layer with the relations between the key
business entities. Those are the business roles, func-
tions, processes, and items that will serve as the main
study of this paper. The middle layer represents
the Application layer with the software applications
that support the business layer. It includes compo-
nents such as application services and blockchain in-
terfaces. Finally, the bottom layer illustrates the Tech-
nology layer with the technological infrastructure that
supports the application layer. Its elements are the
infrastructure and networks that enable blockchain
ICEIS 2024 - 26th International Conference on Enterprise Information Systems
Figure 3: Supply chain blockchain interoperability EA
model in Archimate.
It is worth mentioning that only the upper layer
supports the runtime activities described in Subsec-
tion 3.2 and that the middle and lower layers were in-
cluded in the EA to illustrate the relations among the
components of the supply chain ecosystem.
3.1.2 Ontology Extraction and Assessment
After designing the Archimate model, the next step is
to extract its model exchange file in XML and con-
vert it into an RDF ontology. A third-party tool de-
signed specifically for converting Archimate models
into RDF format handles this.
An RDF ontology is favored for managing data
from multiple sources because unlike alternative on-
tology technologies, it accommodates various data
types, ensuring seamless integration among diverse
systems. Moreover, its semantic richness enables it
to capture nuanced meanings and contextual relation-
ships within the information.
Once the RDF ontology is ready, the assessment
process using HermiT can proceed. HermiT is a rea-
soner that can analyze ontologies and infer additional
knowledge based on the logical rules defined in the
ontology. This process helps identify redundancies
and missing information within the ontology.
HermiT can also check for the satisfiability and
consistency of the ontology. Satisfiability determines
if all the defined classes of the ontology have at least
one instance, while consistency checks if there are
no logical contradictions within the ontology. These
checks are essential to ensure the ontology accurately
represents the intended knowledge.
By using HermiT to assess the RDF ontology de-
rived from the Archimate model, one gains valuable
insights into the quality and correctness of the ontol-
ogy. This analysis can help uncover potential issues
or improvements in the design of the initial model,
ensuring that the resulting ontology aligns with the
intended architectural knowledge.
Listing 1, displays the format of a sample business
entity in the ontology.
<rdfs:label xml:lang="en">Manufacturer</rdfs:label>
Listing 1: Sample Manufacturer business role entity.
3.2 Runtime Activities
At runtime, the integration process unfolds through
a series of steps. First, the transaction context is de-
fined, which consists of stating the target business role
and the business process in which the transaction oc-
curs. Afterwards, the source system sends the data
to the shared Cacti BLP middleware. There, the data
is mapped and converted to conform to the ontology.
Finally, the BLP validates the data against the pre-
defined constraints and rules. If the data is deemed
valid, it is delivered to the target system and subse-
quently updated in the target blockchain.
3.2.1 Entity Mapping and Conversion
Mapping refers to retrieving the name of a relevant
entity from the ontology. It can be either the same en-
tity or a semantically similar one. Conversion refers
to building the corresponding ontology role object
based on the source role object by extracting all the
available data. Both mapping and conversion pro-
cesses involve querying the ontology in SPARQL by
An Enterprise Architecture Approach to Semantic Blockchain Interoperability
utilizing an open-source library called rdflib.js (Tael-
man et al., 2018).
The first step is to create an rdflib.js store object
that holds the ontology data. This store acts as a con-
tainer for RDF triples, where each triple consists of
a subject, predicate, and object. The store then reads
the ontology file and populates itself with the existing
triples in the ontology.
SPARQL, a standard query language for RDF
data, is used to query the store. rdflib.js provides a
convenient API to execute queries on the store. A
SPARQL query can specify conditions to filter enti-
ties based on specific criteria, such as their properties
or relationships with other entities. For example, one
can query for all entities of a specific type or entities
that possess a particular property value.
3.2.2 Transaction Validation
The transaction validation process consists of two
steps. The first is data validation, and the second is
state validation. Successful completion of both steps
ensures a valid transaction. If either step is unsuccess-
ful, the transaction cannot occur, and the remaining
process should abort.
Algorithm 1: Data Validation Algorithm.
Input: ontologyRoleObj: Object
Output: isValid: Boolean
Function validateData(ontologyRoleObj)
getFieldsContainingWord(ontologyRoleObj, ”Format”);
for i 0 to length of fieldsToCompare do
formatFieldName fieldsToCompare[i];
fieldName remove ”Format” from
if fieldName not in ontologyRoleObj then
fieldValue ontologyRoleObj[fieldName];
formatValue ontologyRoleObj[formatFieldName];
if formatValue is not a regular expression then
return false;
if fieldValue does not match the format specified in
formatFieldName then
return false;
return true;
Data validation refers to checking whether the
properties of the object are valid. Specifically, it en-
sures that the values are within the expected bound-
aries stipulated in the EA model. This step is depicted
in Algorithm 1. This algorithm validates data in the
ontology role input object by checking specific fields
containing the word Format. For each of these fields,
it ensures a corresponding non-format field exists. If
not, it moves to the next field. The code validates
the format field as a regular expression; if invalid, it
returns false. It then checks if the non-format field
matches the specified pattern. If not, it also returns
false. If all checks pass, it returns true.
A concrete example of the above would be the
sample transaction data in Listing 2:
nameFormat: "ˆ[a-zA-Z0-9\\-,. ]+$",
name: "ABC suppliers"
Listing 2: Sample format and non-format fields.
Algorithm 2: State Validation Algorithm.
Input: sourceRole: String, targetRole: String, process: String
Output: isValid: Boolean
Function validateState(sourceRole, targetRole, process):
if sourceRole is empty then
return false;
processObj RDFQuerier.fetchDetailsByLabel(process);
if processObj is null then
return false;
foreach funcUri in
processObj.get(’archimate#composition’) do
funcName RDFQuerier.fetchLabelByUri(funcUri);
func find function in this.businessFunctions where
func.entity equals funcName;
if func.triggeredBy equals sourceRole then
sourceFunction func;
if func.triggeredBy equals targetRole then
targetFunction func;
add func to funcs;
return (sourceFunction null) ((targetFunction null
areAdjacent(sourceFunction, targetFunction, funcs))
State validation refers to assuring that the trans-
action is legal. In other words, a transition from or
to specific business functions can occur in the cur-
rent business process according to the EA model.
This step is depicted in Algorithm 2. This algorithm
performs a validation check on the input parameters
sourceRole, targetRole, and process. It first ensures
that sourceRole is not empty; if it is, the method re-
turns false. Then, it attempts to fetch a list of func-
tions related to the specified process using an RDF
ICEIS 2024 - 26th International Conference on Enterprise Information Systems
query and returns false if no functions are found.
The method then iterates through the list of functions,
checking if any of them are triggered by the given
sourceRole or targetRole. The method returns true if
sourceFunction is not null and either targetFunction
is not null and the areAdjacent method confirms the
adjacency of sourceFunction and targetFunction, or
if targetRole is empty.
It is essential to obtain a comprehensive understand-
ing of the advantages and limitations of a novel ap-
proach. Conducting both accuracy and performance
analyses allows for a rigorous assessment of its capa-
bilities across various dimensions.
Accuracy analysis scrutinizes the reliability of the
system irrespective of its operational load. This ex-
amination serves the purpose of discerning the inher-
ent capabilities of the system under controlled con-
ditions. It is also pivotal in ensuring that the system
effectively fulfills its intended objectives and operates
correctly, laying the foundation for a thorough evalu-
Conversely, performance analysis explores the
system’s behavior under diverse load conditions, sim-
ulating real-world scenarios of varying demand and
stress levels. This data enables the assessment of scal-
ability, resilience, and the system’s ability to perform
consistently in a production environment.
Integrating accuracy and performance analyses is
crucial for a holistic evaluation. This method mini-
mizes the risk of oversight and mitigates potential bi-
ases. Furthermore, it supports the principle of con-
tinuous improvement. As the system evolves, peri-
odic reevaluation through these lenses can assist in
addressing emerging challenges.
4.1 Experimental Setup
The experimental infrastructure consisted of three test
ledgers (one for each supply chain entity) interoperat-
ing with Cacti. The three test ledgers were Besu (Fan
et al., 2022), Quorum (Hounsom, 2018), and Fabric
(Androulaki et al., 2018). These ledgers simulated
different blockchain networks and enabled the de-
ployment and interaction with smart contracts. Each
component ran on a separate application container on
a single machine equipped with an AMD Ryzen 7
3750H processor and 16GB of RAM.
The deployment of smart contracts was a critical
aspect of the experimental setup, as each of them han-
dled different supply chain aspects. The BambooHar-
vestRepository.sol and BookshelfRepository.sol con-
tracts were written in Solidity and the former man-
aged bamboo harvest records, while the latter han-
dled bookshelf records. The Shipment.ts script writ-
ten in Go represented a smart contract for managing
shipments. The bamboo harvest and bookshelf smart
contracts were deployed in the Besu and Quorum
blockchains respectively while the shipment smart
contract was deployed on the Fabric ledger.
The setup process also involved creating test ac-
counts, generating contract addresses, and storing
contract artifacts in the keychain plugin to manage
cryptographic keys securely. It also included specify-
ing the target organizations, channel, and policy that
determines which members of each organization can
approve a transaction involving a specific smart con-
The purpose of the above setup was to provide
a self-contained and local environment that allowed
for assessing the effectiveness of the proposed solu-
tion by evaluating the POC that puts it into practice.
Thus, it provided the necessary functionality for the
experiments without requiring a complex and time-
consuming process.
4.2 Accuracy Analysis
The chosen metric for the accuracy analysis was the
error rate of the POC when validating transactions
(Tx) among blockchain systems. Therefore, the ap-
proach followed was to conduct experiments with
valid and invalid transactions to ascertain if the so-
lution correctly identified each case.
Each validation process scrutinizes two main ele-
ments. Those are the transaction context and the ob-
ject that initiates the transaction. If either of them is
invalid, the transaction should not complete.
Specifically, a context is valid when its target role
and business process entities are present in the ontol-
ogy. Similarly, an object is in a legal state when its
source role entity exists in the ontology and its fields
conform to the specified format.
In the first experiment, both the context and the
object were valid. Here the transaction was deemed
successful as expected because all steps passed.
The second experiment had an invalid context and
valid object. This time, despite the mapping step exe-
cuting successfully, the validation step failed because
of its invalid context.
The third experiment involved a context that was
valid and an invalid object. Here, the mapping step
was unsuccessful, so the validation failed as it did not
even get a chance to execute.
In the fourth experiment, both the context and the
An Enterprise Architecture Approach to Semantic Blockchain Interoperability
object were invalid. Again, the mapping failed, so the
transaction validation was deemed unsuccessful.
The experiment results are summarized in Table 1.
Table 1: Experiment results.
# Context Object Valid Tx Expected
1 Valid Valid Yes
2 Invalid Valid × Yes
3 Valid Invalid × Yes
4 Invalid Invalid × Yes
4.3 Performance Analysis
The metric used for the performance analysis was the
processing time to complete a transaction among two
separate blockchain systems in the POC.
Given that the proposed solution is supported by
the infrastructure of Hyperledger Cacti, it is worth
noting that the evaluation of the performance of the
former is framed to that of the latter.
Experiments were conducted for three distinct
load profiles characterized as ”low, ”normal, and
”high, corresponding to a rate of 10, 50, and 100
simultaneous transactions. These three profiles rep-
resent typical loads in enterprise ecosystems with a
scope similar to the one presented in this paper.
To extract objective and unbiased results, each
transaction load profile execution was repeated 100
times and their mean time was calculated. While per-
forming the first transactions, the systems may not
have reached their processing potential, so the first
iterations can be considered a warm-up phase. Fur-
thermore, worker threads were utilized to permit the
parallel execution of the transactions.
Figure 4 depicts the impact on processing time as
the rate of simultaneous transactions increases before
and after integrating the proposed solution. One may
interpret the graph as the processing overhead im-
posed on the participating systems when leveraging
the approach presented in this work.
0 20 40
80 100 120
Simultaneous transactions [ Tx #]
Processing time [ms]
Tx completion (with solution)
Tx completion (w/o solution)
Figure 4: Overhead of proposed solution.
4.4 Result Discussion
The experiments show that the POC leveraging the
proposed solution identifies valid and invalid transac-
tions among systems with 100% accuracy. The bene-
fits of this outcome are immense, as the interoperation
process becomes transparent and efficient.
The increase in the processing overhead while uti-
lizing the proposed solution indicates possible scal-
ability issues. Nevertheless, the overhead is consid-
ered negligible for enterprise standards until a certain
point. Thus, it is suitable for private ecosystem us-
age where simultaneous transactions typically do not
exceed this threshold, and data quality is of foremost
In other words, it is acceptable to sacrifice sys-
tem performance for reliability. As a result, the capa-
bilities of the individual blockchain systems get en-
hanced by reducing duplication of effort, improving
data integrity and consistency, and enabling new de-
centralized applications and services to be built on top
of them securely.
Another observation is the low cost and ease of
extensibility of the solution. While the design and
consequent change management of modifying the EA
model involve resources, the possibility of automation
of the remaining processes implies that spending does
not increase for those.
The applicability of the proposed solution is am-
ple. Every network that involves complex transac-
tions among participating systems would gain from
this solution. Thus, this approach could poten-
tially impact many industries that actively leverage
blockchains and, perhaps, encourage others to mi-
grate their current infrastructure to DLT.
There are a plethora of solutions related to achiev-
ing interoperability in blockchain systems. Neverthe-
less, most of them do not focus on the semantic layer
of interoperability. This paper explored this gap by
implementing a solution that enhances interoperation
among systems owned by members of a supply chain
consortium, as those usually entail operations among
different business domains, demonstrating the poten-
tial of this mechanism. The novel approach leverages
EA modeling to provide a common ground for sys-
tems to achieve interoperability in the semantic layer.
It consists of an ontologically guided business logic
plugin that validates cross-chain transactions. The
outcome of the evaluation is satisfactory, proving the
added value of this approach. Although the POC is
ICEIS 2024 - 26th International Conference on Enterprise Information Systems
limited to a network of permissioned ledgers owned
by a business consortium, the paradigm can be ex-
tended for a set of blockchain systems of indefinite
size. Thus, this paper supports that EA techniques
can aid in solving open issues in blockchain interop-
erability and, in this way, encourage further research
in this area.
This work needs to be generalized for ease of ex-
tensibility to other use cases. For instance, applying
this mechanism to enhance public blockchain inter-
operability in fields other than that of supply chain
management would be noteworthy. Another interest-
ing future research path is to extend the Hermes fault-
tolerant middleware that was described in the prelim-
inary section of this document. The goal would be
to increase the robustness of this tool by leveraging
the transaction validation capabilities offered by the
proposed solution.
We thank the reviewers of this paper for their very in-
sightful and constructive feedback. We put forward
our gratitude to the Hyperledger Cacti community,
which idealized the use case we explore in this paper.
This work was supported by national funds
through FCT, Fundac¸
ao para a Ci
encia e a Tecnologia,
under project DOI:10.54499/UIDB/50021/2020 and
in the scope of the project nr. 51 “BLOCKCHAIN.PT
- Agenda Descentralizar Portugal com Blockchain”
refª C632734434-00467077, financed by European
Funds, namely “Recovery and Resilience Plan - Com-
ponent 5: Agendas Mobilizadoras para a Inovac¸
Empresarial”, included in the NextGenerationEU
funding program.
Androulaki, E., Barger, A., Bortnikov, V., Cachin, C.,
Christidis, K., De Caro, A., Enyeart, D., Ferris, C.,
Laventman, G., Manevich, Y., et al. (2018). Hyper-
ledger fabric: a distributed operating system for per-
missioned blockchains. In Proceedings of the thir-
teenth EuroSys conference, pages 1–15.
Antunes, G., Caetano, A., Bakhshandeh, M., Mayer, R., and
Borbinha, J. (2013). Using ontologies for enterprise
architecture model alignment. In Proceedings of the
4th Workshop on Business and IT Alignment (BITA
2013). Poznan, Poland.
Bansal, R. and Chawla, S. (2014). An approach for seman-
tic information retrieval from ontology in computer
science domain. International Journal of Engineering
and Advanced Technology (IJEAT), 4(2):58–65.
Belchior, R., Riley, L., Hardjono, T., Vasconcelos, A., and
Correia, M. (2023a). Do you need a distributed ledger
technology interoperability solution? Distributed
Ledger Technologies: Research and Practice, 2(1):1–
Belchior, R., S
ußenguth, J., Feng, Q., Hardjono, T., Vascon-
celos, A., and Correia, M. (2023b). A brief history of
blockchain interoperability.
Belchior, R., Vasconcelos, A., Correia, M., and Hardjono,
T. (2022). Hermes: Fault-tolerant middleware for
blockchain interoperability. Future Generation Com-
puter Systems, 129:236–251.
Belchior, R., Vasconcelos, A., Guerreiro, S., and Correia,
M. (2021). A survey on blockchain interoperability:
Past, present, and future trends. ACM Computing Sur-
veys (CSUR), 54(8):1–41.
Commission, E. (2015). Eira support series - how eira sup-
ports interoperability v1.0.0.
Dannen, C. (2017). Introducing Ethereum and solidity, vol-
ume 1. Springer.
Decker, S., Melnik, S., Van Harmelen, F., Fensel, D., Klein,
M., Broekstra, J., Erdmann, M., and Horrocks, I.
(2000). The semantic web: The roles of xml and rdf.
IEEE Internet computing, 4(5):63–73.
Fan, C., Lin, C., Khazaei, H., and Musilek, P. (2022).
Performance analysis of hyperledger besu in private
blockchain. In 2022 IEEE International Confer-
ence on Decentralized Applications and Infrastruc-
tures (DAPPS), pages 64–73. IEEE.
Hardjono, T., Lipton, A., and Pentland, A. (2019). To-
ward an interoperability architecture for blockchain
autonomous systems. IEEE Transactions on Engi-
neering Management, 67(4):1298–1309.
Hounsom, C. (2018). Quorum whitepaper v0.2.
Josey, A., Lankhorst, M., Band, I., Jonkers, H., and Quar-
tel, D. (2016). An introduction to the archimate® 3.0
specification. White Paper from The Open Group.
Kalogirou, V. and Charalabidis, Y. (2019). The european
union landscape on interoperability standardisation:
status of european and national interoperability frame-
works. In Enterprise Interoperability VIII: Smart Ser-
vices and Business Impact of Enterprise Interoper-
ability, pages 359–368. Springer.
Montgomery, H., Borne-Pons, H., Hamilton, J., Bowman,
M., Somogyvari, P., Fujimoto, S., Takeuchi, T., Kuhrt,
T., and Belchior, R. (2020). Hyperledger cactus
Peck, M. E. (2017). Blockchains: How they work and why
they’ll change the world. IEEE Spectrum, 54(10):26–
Taelman, R., Van Herwegen, J., Vander Sande, M., and Ver-
borgh, R. (2018). Comunica: a modular sparql query
engine for the web. In The Semantic Web–ISWC 2018:
17th International Semantic Web Conference, Mon-
terey, CA, USA, October 8–12, 2018, Proceedings,
Part II 17, pages 239–255. Springer.
Underwood, S. (2016). Blockchain beyond Bitcoin. Com-
munications of the ACM, 59(11):15–17.
White, S. A. (2004). Introduction to bpmn. Ibm Coopera-
tion, 2(0):0.
An Enterprise Architecture Approach to Semantic Blockchain Interoperability