An Enterprise Architecture Approach

to Semantic Blockchain Interoperability

Sebasti

ao Sotto-Mayor

, Rafael Belchior

1,2

, Miguel Correia

and Andr

e Vasconcelos

INESC-ID, Instituto Superior T

ecnico, Universidade de Lisboa, Portugal

Blockdaemon Ltd., Dublin, Ireland

Keywords:

Enterprise Architecture, Blockchain Interoperability, Ontology.

Abstract:

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 ﬁrst 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 signiﬁcant step in proving that distributed ledger technologies can beneﬁt from enterprise architecture

techniques to improve their interoperability.

1 INTRODUCTION

Distributed ledger technology (DLT) refers to net-

works of computers that store databases in a dis-

tributed way, distinguishing them from traditional

databases conﬁned 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 speciﬁc 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-

ﬁcation (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 conﬁ-

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 speciﬁc 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-

ﬁciently, 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 speciﬁcally 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

614

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

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 signiﬁcance, the semantic layer will play

a key role in increasing interchain communication ef-

ﬁciency (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

other.

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 ﬂexible

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-

turely.

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

systems.

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.

2 PRELIMINARIES

This section presents important knowledge concern-

ing the proposed solution. Speciﬁcally, 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

interoperability.

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

615

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-

speciﬁc reasons irrelevant to the study. A data trans-

fer is the process of copying information from one

DLT to another, and it involves speciﬁc 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 ﬂow 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.

3 ONTOLOGICALLY-GUIDED

INTEROPERABILITY

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 speciﬁc 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 signiﬁcantly as the knowledge

grows. Furthermore, the European Interoperability

Reference Architecture (EIRA) (Commission, 2015)

should guide the design to ensure regulatory compli-

ance.

Figure 3 depicts the three layers of the supply

chain-speciﬁc EA created for the use case that was

deﬁned 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

transactions.

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

616

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 ﬁle in XML and con-

vert it into an RDF ontology. A third-party tool de-

signed speciﬁcally 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 deﬁned in the

ontology. This process helps identify redundancies

and missing information within the ontology.

HermiT can also check for the satisﬁability and

consistency of the ontology. Satisﬁability determines

if all the deﬁned 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.

<NamedIndividual

rdf:about="urn:uuid:id-6d7fc1370fcb48959daae518ea90b265">

<rdf:type

rdf:resource="http://bp4mc2.org/def/archimate#BusinessRole"/>

<archimate:association

rdf:resource="urn:uuid:id-67ccb819d7284462a8b9045f23e437d0"/>

<archimate:triggering

rdf:resource="urn:uuid:id-00f2f859356543cb8c0b8212e2731e1c"/>

<archimate:writeAccess

rdf:resource="urn:uuid:id-a5e7d160476c449ca342489c9b3f3d9f"/>

<rdfs:label xml:lang="en">Manufacturer</rdfs:label>

</NamedIndividual>

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-

ﬁned, 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-

deﬁned 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

617

utilizing an open-source library called rdﬂib.js (Tael-

man et al., 2018).

The ﬁrst step is to create an rdﬂib.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 ﬁle and populates itself with the existing

triples in the ontology.

SPARQL, a standard query language for RDF

data, is used to query the store. rdﬂib.js provides a

convenient API to execute queries on the store. A

SPARQL query can specify conditions to ﬁlter enti-

ties based on speciﬁc criteria, such as their properties

or relationships with other entities. For example, one

can query for all entities of a speciﬁc type or entities

that possess a particular property value.

3.2.2 Transaction Validation

The transaction validation process consists of two

steps. The ﬁrst 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)

ﬁeldsToCompare ←

getFieldsContainingWord(ontologyRoleObj, ”Format”);

for i ← 0 to length of ﬁeldsToCompare do

formatFieldName ← ﬁeldsToCompare[i];

ﬁeldName ← remove ”Format” from

formatFieldName;

if ﬁeldName not in ontologyRoleObj then

continue;

end

ﬁeldValue ← ontologyRoleObj[ﬁeldName];

formatValue ← ontologyRoleObj[formatFieldName];

if formatValue is not a regular expression then

return false;

end

if ﬁeldValue does not match the format speciﬁed in

formatFieldName then

return false;

end

return true;

end

Data validation refers to checking whether the

properties of the object are valid. Speciﬁcally, 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 speciﬁc ﬁelds

containing the word Format. For each of these ﬁelds,

it ensures a corresponding non-format ﬁeld exists. If

not, it moves to the next ﬁeld. The code validates

the format ﬁeld as a regular expression; if invalid, it

returns false. It then checks if the non-format ﬁeld

matches the speciﬁed 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 ﬁelds.

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;

end

processObj ← RDFQuerier.fetchDetailsByLabel(process);

if processObj is null then

return false;

end

foreach funcUri in

processObj.get(’archimate#composition’) do

funcName ← RDFQuerier.fetchLabelByUri(funcUri);

func ← ﬁnd function in this.businessFunctions where

func.entity equals funcName;

if func.triggeredBy equals sourceRole then

sourceFunction ← func;

end

if func.triggeredBy equals targetRole then

targetFunction ← func;

end

add func to funcs;

end

return (sourceFunction ≠ null) ∧ ((targetFunction ≠ null ∧

areAdjacent(sourceFunction, targetFunction, funcs)) ∨

¬targetRole);

end

State validation refers to assuring that the trans-

action is legal. In other words, a transition from or

to speciﬁc 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 ﬁrst 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 speciﬁed process using an RDF

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

618

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 conﬁrms the

adjacency of sourceFunction and targetFunction, or

if targetRole is empty.

4 EVALUATION

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 fulﬁlls its intended objectives and operates

correctly, laying the foundation for a thorough evalu-

ation.

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 speciﬁc smart con-

tract.

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 identiﬁed 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.

Speciﬁcally, 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 ﬁelds

conform to the speciﬁed format.

In the ﬁrst 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

619

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 proﬁles characterized as ”low,” ”normal,” and

”high,” corresponding to a rate of 10, 50, and 100

simultaneous transactions. These three proﬁles 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 proﬁle execution was repeated 100

times and their mean time was calculated. While per-

forming the ﬁrst transactions, the systems may not

have reached their processing potential, so the ﬁrst

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

1,000

2,000

3,000

4,000

5,000

6,000

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 identiﬁes valid and invalid transac-

tions among systems with 100% accuracy. The bene-

ﬁts of this outcome are immense, as the interoperation

process becomes transparent and efﬁcient.

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

concern.

In other words, it is acceptable to sacriﬁce 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.

5 CONCLUSIONS

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

620

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 indeﬁnite

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 ﬁelds 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.

ACKNOWLEDGEMENTS

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, ﬁnanced by European

Funds, namely “Recovery and Resilience Plan - Com-

ponent 5: Agendas Mobilizadoras para a Inovac¸

Empresarial”, included in the NextGenerationEU

funding program.

REFERENCES

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–

37.

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

speciﬁcation. 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

whitepaper.

Peck, M. E. (2017). Blockchains: How they work and why

they’ll change the world. IEEE Spectrum, 54(10):26–

35.

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

621