Journal of Systems Architecture 153 (2024) 103177

Contents lists available at ScienceDirect

Journal of Systems Architecture

journal homepage: www.elsevier.com/locate/sysarc

VelogCPS: A safe blockchain network for cyber–physical systems leveraging

block verifiers
Marisol García-Valls ∗, Alejandro M. Chirivella-Ciruelos
Departamento de Comunicaciones, Universitat Politècnica de València, Valencia, Spain

ARTICLE INFO ABSTRACT

Keywords: Non-functional requirements related to safety, security, and timeliness have made cyber–physical systems
Cyber physical system (CPS) initially reluctant to their integration with blockchain technology. Despite the multiple advantages of
IoT blockchain like improved data security and traceability, the main reasons that have slowed down its adoption
Blockchain
in CPS still remain. Examples of these are the inherent overhead of accessing the distributed ledger and the
Verification
security incidents that a number of blockchain networks have suffered since its inception. This paper presents
Block verifier
Smart contract
VelogCPS, a novel middleware that guarantees that logic and data managed by blockchain networks of cyber–
Authenticity physical systems are verified and generated by legitimate sources. Thus, VelogCPS avoids a kind of security
Security incidents that impact the authenticity and integrity of the logic and data managed in blockchain networks.
Safety By authenticity we refer to provenance authenticity of the involved smart contracts, i.e., the perfect matching
Real-time between the advertised source-code and the version deployed to the network. Our framework provides a safe
Time sensitive system blockchain network as it ensures that the entities that participate to a CPS use solely authentic logic. We do
Middleware this by leveraging block verifier services and enforcing them through the operation workflow. As a result, the
middleware guarantees that the participating entities use and share authentic logic. The proposed framework
is validated through its implementation on a real blockchain network, employing actual smart contract verifier
logic, and through the exhaustive analysis of the temporal behaviour and overhead of the major operations;
the obtained results ensure its utility for time-sensitive sytems like CPS and IoT.

1. Introduction soon captured the attention of the scientific and engineering commu-
nity for a broad range of application domains, e.g., government [1],
Constant improvement of hardware and software technology has IoT ecosystems [2], eHealth [3,4], voting [5], or industry [6]. Such
enabled the development of increasingly complex applications that complex systems have proven to benefit from the emerging software
span across heterogeneous execution substrates and distinct domains. developments that support the realization of trusted, though decentral-
Cyber–Physical Systems (CPS) are a kind of such complex systems. CPS ized, processes that are intensive in data access and sharing. This is also
are abundant in the use of sensing and actuating equipment, comprising the case of CPS and IoT.
highly heterogeneous hardware nodes running diverse logic, and they Though it has some amazing inherent benefits, blockchain technol-
may conform to complex software computational paradigms. ogy is not perfect. In deed, a number of attacks have successfully hit
Cyber–physical systems merge the physical and cyber (computa- some blockchain networks in the recent past. This has caused great
tional) domains. This mixture gives birth to new applications that economic losses and trust erosion especially to those users belonging
express also new economic models arising in the emerging global to most critical domains. This is the case of the DAO (Distributed
markets. This is the case of virtual marketplaces, distributed and global Autonomous Organization) incident [7]; over three and a half million
supply chains, connected global eHealth, and demand-driven markets, Ether (the currency used in Ethereum [8]) were drained by a cyber-
just to name a few. These new trends often imply a global cost and attacker by exploiting a vulnerability of the system. Another paradig-
revenue model over the basis of a cost-effective business structure. matic incident happened in 2017 with the Parity Wallet hack [9] that
As a realization of distributed ledger technology (DLT), blockchain was attacked in Ethereum, causing around 30 million USD loss.
enables trust and decentralization in collaborative business models. These incidents have occurred because a number of factors may turn
Though initially created for cryptocurrency transactions, blockchain smart contracts (their underlying software concept and building block)

∗ Corresponding author.
E-mail addresses: [email protected] (M. García-Valls), [email protected] (A.M. Chirivella-Ciruelos).

https://doi.org/10.1016/j.sysarc.2024.103177
Received 23 June 2023; Received in revised form 14 April 2024; Accepted 13 May 2024
Available online 18 May 2024
1383-7621/© 2024 The Author(s). Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-
nc-nd/4.0/).
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

into vulnerable programs. A part from the potential vulnerabilities that the one hand, the dashboard could be attacked causing a modification
execution platforms such as EVM (Ethereum Virtual Machine) contain, of the advertised code. On the other hand, the executable version may
programming the source code of a smart contract in a clean, error-free be modified resulting in a different executable file being uploaded to
manner is a hard task. This job requires extensive training in the target the distributed ledger. As a consequence of a successful attack, a user
programming language. Introducing a single bug in the source code cannot trust that the running version of a smart contract is exactly the
may result in losses worth millions USD. Additionally, a blockchain same as the advertised source-code version.
network does not guarantee smart contract authenticity per se. In fact,
cyberattackers may employ different techniques to break the one-to-one 1.2. Contribution
association between an advertised smart contract and its corresponding
bytecode that runs in the blockchain network. Our work contributes to ensuring that only authentic logic is used
The global ledger of a blockchain network stores a number of over the global operation space of the cells of a cyber–physical system.
running smart contracts, ready to receive invocations from users. Users For this, the involved pathways to ensuring authenticity in smart
can benefit from the functionality of the running smart contracts by contracts are analysed. The first one is related to the deployment of
invoking their available functions. To be reachable by network par- bytecode to the network; and the second one relates to the process of
ticipants (i.e., users), smart contracts are advertised in some network verifying the contract. For this, we design and develop a middleware
dashboard. By looking up in the dashboard, participants can find smart named VelogCPS that embeds verification of logic (i.e., the smart con-
contracts of interest and request the functionality that they provide. tracts) hosted in CPS cells, achieving a solution that ensures that any
The functionality of a smart contract is requested by invoking the execution of a smart contract function is performed only if the running
available functions that it contains. Nevertheless, if a successful attack logic is found to be authentic. The middleware leverages on block
has occurred in the network, the running version of the involved smart verifiers for performing the verification tasks.
contract and its corresponding advertised source code may not be the Providing trust to the cells in this way avoids using third party
same. If both items (i.e., source code and running code) fully coincide, regulatory agencies that would break the trust model of the blockchain.
then the smart contract is considered authentic. VelogCPS middleware is designed as a modular intermediation point
In essence, smart contract authenticity [10] refers to the accredita- that transparently grants access to legitimate logic. It does so without
tion as truthful and being a true reflection of the characteristics and altering the mechanisms of the blockchain substrate like block mining,
requirements that are advertised in the network dashboard. As a result, block validation, and network consensus.
verifying the authenticity of a smart contract is the process of checking This work does not address the verification of the correctness
that a smart contract source code and the corresponding version that of smart contracts for which formal verification techniques, source
runs on the global ledger are the same. code verification methods, and software analysis are employed. Such
As a result, to achieve 100% certainty about the correctness of a techniques and methods have been long studied in the past, yielding
smart contract, it must be checked in a number of orthogonal plains. a large number of contributions on formal methods, model checking,
On the one hand, they should be checked for errors in order to ensure theorem proving, or run-time verification, that are out of the scope of
their correctness, that their execution is secure, and that their safety this paper.
properties (if any is required) are met. On the other hand, it is of
paramount importance that the authenticity of a running smart contract 1.3. Paper organization
is ensured in order for potential users to be safe when using it. As
mentioned before, we employ the term authenticity as explained in [10]: The document is organized as follows. Section 2 describes the
Authenticity involves certainty about the smart contract provenance. context and related work. Section 3 describes the requirements for
This implies that there must be a one to one relation between the the framework and the attack model. Section 4 provides a theoret-
running version of the smart contract and the advertised source code. ical and practical description of the framework that provides a safe
As cyber–physical systems must comply to stringent safety and blockchain network for cyber-physical systems; VelogCPS middleware
security requirements, smart contract authenticity is an essential char- is presented, describing its design, functionality, and programming
acteristic in them. We address the complexity of cyber–physical systems interface Section 5 validates the contribution through its implemen-
considering that they are conformed by a set of interconnected sub- tation over an actual blockchain network, the design of a set of
systems or participant entities/nodes, namely cells. Consequently, all experiments and their realization that shows the temporal behaviour
cells may require certainty about the authenticity of the data and logic of the middleware, and the cost–benefit relation of the authenticity
hosted in the distributed ledger prior to using them. assurance strategy. Eventually, Section 6 concludes by reviewing the
benefits of our approach.
1.1. Attack model
2. Background
We assume potential presence of malicious actors with the objec-
tive of intentionally altering the functionality offered by smart con- The introduction of the concept of smart contract has boosted the
tracts. Attackers may attempt to modify the executable version of a power of DLT and blockchain as a technology to implement decentral-
smart contract that, when successful, appears transparent to the system ized applications (dApps). A smart contract is a program that runs in
participants. Following, we explain how this may happen. the blockchain network and describes the terms of an agreement. A
A smart contract is written in some high level programming lan- smart contract stored in the distributed ledger runs automatically when
guage. Examples of most commonly used languages for this purpose the terms are met, being capable of changing the state of the contract
are Solidity (the most popular one), Vyper, Yul, Cairo, or Rust. This itself and, therefore, of the global ledger. Once stored in the ledger,
source code must eventually be compiled into bytecode, becoming an the program logic is immutable.
executable program. Once the source code has been transformed into A potential user of a smart contract has no means to know whether
an executable version, it can be deployed to the blockchain, and run a given running smart contract truthfully implements the source code
on some execution run-time environment like the Ethereum Virtual that the user has consulted. In an ideal network, this would have no
Machine (EVM) [8] or Hyperledger Fabric [11]. negative consequences. However, in a real context where attacks may
As a result, there is a transformation of the original source code occur, this model needs to improve its security. As a consequence, the
version of a smart contract to an executable version. A successful attack blockchain technology community has realized the importance of smart
on the authenticity property of a smart contract yields two situations. On contract verification as a way to build trust between smart contract users

2
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

and developers. In fact, it is the corner stone to build trust on advertised 2.2. Smart contract verification services
smart contracts.
The use of the term verification connects the minds of the general This section presents the set of contributions most related to our
audience to formal verification techniques and software analysis. This work that use 4 same meaning for smart contract verification [10] as
effect happens also when referring to verification in the context of the one used in our approach. After surveying the research landscape,
smart contracts. The reason is the still relative novelty of blockchain the scarce research works that have been found are limited to block
technology and the scarce number of works on provenance verification verifiers (a.k.a verification services) and a few others to analysing their
of smart contracts in blockchain networks. behaviour and vulnerabilities.
However, formal verification and software analysis is orthogonal Block verifiers should not be confused with block validators. The
to the domain of our work. Our work does not address source code latter are mandatory participants in a network because they are in
verification nor model checking techniques. The present work targets a charge of validating the correctness of the block mining process.
novel way of looking into the needs of cyber–physical systems that rely However, block verifiers are a later add-on that is optional to a
on blockchain substrates and on the logic that is stored in them. Only blockchain network. Block verifiers have appeared given the progres-
few works have been produced so far, including the development of sive growth of the number of available smart contracts on the public
block verifiers that are later indicated in this section. Our contribution networks. A running smart contract can be used by anyone in a public
leverages on these verifiers that are remote services offered to smart network, but using it is (in the end) a matter of trust since its bytecode
contract developers to build trust on the provided functionality and cannot be read. A block verifier is a service that answers the question
logic. of whether the source code of an executable version of a smart contract
The existing block verifiers are nowadays still limited to offering matches exactly a given (other) source code. Provenance authenticity
off-line smart contract verification that takes place at the initial phase is a real challenge in cyber–physical systems because the trustability of
of the programming and advertising. the logic contributed by all cells must be guaranteed. As a consequence,
In this section, we survey both aspects: formal verification and soft- we believe that the process of block verification (or smart contract
ware analysis together with smart contract verification. Additionally, verification) has to be present in a complex cell-based system.
and to better draw the overall context, we describe other areas of cre- Currently, only some external platforms exist for verification of
dential management and also works on construction of global operation smart contracts like Tenderly [19], Sourcify [20], Blocksout [21],
spaces. We anticipate a scarce number of works and technologies that or Etherscan [22], among others. These platforms provide an own
constitute the reduced background of our work, as explained above in dashboard containing the set of smart contracts that have obtained a
relation to its novelty. verification seal. However, this process is decoupled from the usage of
the particular blockchain that might have been configured.
2.1. Blockchain-based global operation spaces The design and development of solutions to improve the block
verification schemes opens a wide research space. As indicated in [23],
In the recent years, a number of works have been released that the community is just starting to learn about a few types of vulner-
address the integration of blockchain technology with IoT applica- abilities that affect some smart contract verification services which
tions [2] in some form. These are applied to a number of domains like can break the verification; this results into spreading malicious smart
eHealth [3,4], agriculture [12], or electronic voting applications [5], contracts. The work of [23] is the most relevant on the literature about
among many others. the vulnerabilities of block verifiers. They propose a set of security
On the usage of the blockchain as a global space, we find CoTwin properties to be satisfied by block verifiers and identify the types
[13] that develops a global operation space for improving digital twin of potential vulnerabilities that can break the verification when the
models based on deep learning over a blockchain substrate; or [14] that security properties are violated. The difference with respect to our
describes a model for document verification for government systems to present contribution is that the work is a security analysis of Ethereum
achieve decentralized sharing of authenticated government documents smart contract services, precisely for Etherscan [22], Sourcify [20], and
across private bodies and organizations. A complementary approach is Blockscout [21]. Our contribution does not focus on the identification
presented in [15] that describes an automated credential verification of security issues inside block verifiers. We leverage on block verifiers
system based on the blockchain to handle academic certificates; the to provide a framework that transparently ensures cells that they are
system consists of a web app having a front-end for registering and using authentic logic. For this, we assume that the verification process
requesting verification, and a backend part with two functionalities like of the block verifier entities is not broken.
an OCR module to collect certificate details and a blockchain module In a previous work [24], we have used block verifiers through the
to send and verify data that is located in the blockchain. instrumentation of the Hardhat [25] plain scripting facilities to deploy
Targeting the construction of a global operation space, we find [16] smart contracts on public blockchain networks. We had engineered a
that describes a solution for document sharing; here, documents have scheme to automate smart contract verification tries and assess the
a unique hash key used to validate its authenticity. interaction with some of the major block verifiers. To the best of our
In the area of control for cyber–physical systems and of autonomous knowledge, this has been among the first published works on the initial
robotic devices, [17] describes a model to support verification of crit- determination of the temporal characteristics of block verifiers and
ical data shared and exchanged by nodes; it is architected through their usability for smart contract verification. We extended this work
the configuration of discrete multiple-valued logic to provide data in [10] where we designed a middleware to automate the deployment
protection against illegitimate modification attempts. of smart contracts on real networks. However, that work focused solely
In the field of manufacturing and production, [18] conceptualizes on the assessment of the temporal behaviour of the verification process.
the interaction in the supply chain among partners, defining validation In the present contribution, we substantially improve our previous
rules for transactions and providing trust. works by designing a middleware framework targeted at cells that
Though still far, the above have been found to be the closest to our work cooperatively against a shared space based on blockchain tech-
target system in the sense that they attempt to provide a global opera- nology. With the knowledge gained in [10], we design a framework
tion space where the managed data objects are trusted. To the best of that transparently checks the logic requested by cells and ensures that
our knowledge, there is no contribution that provides a means to ensure it is authentic. When a cell wishes to use a given logic, it does so
that the logic deployed to, and executed from, a blockchain-enabled through our framework VelogCPS. The framework performs the needed
global space is authentic at all times. To illustrate this statement, most operations to determine whether the logic has been previously verified.
related works have been identified as representatives of this kind. It only allows the cell to use a logic if it has been verified or if

3
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

VelogCPS can verify it on-the-fly without detecting any authenticity 2.5. Summary and missing gap
breach during the process. This is a large step forward because if a
cell ecosystem within a cyber–physical system uses VelogCPS, it will As derived from the above arguments, and to the best of our
be guaranteed that the logic used in this ecosystem is authentic. This knowledge, there is a lack of contributions on ensuring smart contract
means that the logic provenance is the expected one, i.e., it comes from authenticity for complex systems like CPS. In this paper, we contribute
a legitimate source. to a complementary yet different direction to the existing areas. We
target the need of distributed CPS cells to construct an efficient global
execution space that is trusted by all participants. For this, our solution
2.3. Software analysis leverages block verifiers, global operation spaces for CPS and focuses
on the actual integration of mechanisms and strategies that improve
the security of the global system operation, where participants have
From a software analysis perspective, verification refers to checking
the guarantee that they are using purely authentic logic.
the correctness of a smart contract; this consists of determining whether
For this, we design VelogCPS framework that offers remote cells a
the programmed logic adheres to the initial specifications. Also, it
blockchain-based global operation space with built-in assurance about
implies the determination of whether the possible executions of the
the authenticity of the logic that is hosted and executed on the network.
contract produce the expected behaviour and outcome. This results in the overall security being improved. To meet the time-
There are two main ways to achieve the needed certainty level. On sensitive expectations of cyber–physical systems, the resulting scheme
the one hand, formal verification techniques (that are based on math- is validated over a real deployment, showing that the framework has a
ematical methods) enable the determination of predefined properties timely behaviour and a controlled execution overhead.
of the model. For example, a given output value is one from the
expected set of valid values. On the other hand, source code verification 3. System model
techniques ensure that the programmed code is correct; e.g., absence
of attempts to access undefined memory positions, or absence of race 3.1. Overview and requirements
conditions, among others.
The target scenario is that of a complex cyber–physical system that
A considerable number of vulnerabilities in smart contracts are
interconnects distributed cells, namely CPS cells, as illustrated in Fig. 1.
caused by lack of coding proficiency that results in the introduction
A cell is a full fledged system. Examples are a manufacturing premises,
of code bugs. In a blockchain network, it is not possible to modify a
i.e., a manufacturing cell within a globally connected system for a given
smart contract after it has been deployed. A new logic can be deployed brand manufacturer; a railway station within a connected regional
to overcome such a situation, but the former will stay immutably in railway system; or a hospital department of a larger hospital facilities,
the global ledger. Fighting bug coding can be done by investigation among others.
of methods to detect vulnerabilities for improving the security; these All cells participate equally to the global system. They are inter-
methods typically consist of analysing the code against a list of pre- connected and able to share data and operation logic. The operation
defined well-known vulnerability patterns. In this respect, different logic is the set of procedures that dictate how the system functions
techniques have appeared These are well summarized in [26] that sur- to achieve its goals. For the sake of realization, the global operation
veys smart contract code verification contributions. Other approaches logic is broken down into a set of smaller, highly focused logic pieces.
like [27] present the landscape of verification for blockchain applica- Each piece is named logic. For example, the global operation logic may
tions but, once more, solely focused on software analysis techniques to be the management of the logistics of a car manufacturer across all
study the correctness of smart contract code. Nevertheless, such works its sites around some geographical area. In this example, logic pieces
focus solely on formal analysis of source code, which is out of the scope are the processes or algorithms to detect shortage of raw material, the
of our work. process to annotate that a new car or asset has been produced, or the
algorithm to determine the total amount to be paid to a given cell in
charge of supplying a particular asset to other cells. In summary,
2.4. Credential management and authentication cells are interconnected and participate in the system operation. Cells
can read and update the global space and the logic contained in it.
In cyber–physical systems, the execution time of their constituent
Our contribution does not address credential verification involv-
processes, operations, and functions is considered a key parameter. In
ing identity management, password authentication mechanisms (e.g.,
fact, the execution time of its functionality or processes determines
through smart card usage, etc.), or two-factor authentication schemes,
the correctness the system. Also, the security requirements over the
among others. global space must be fulfilled. For this reason, the global operation
There is a long list of challenges in designing multi-factor authen- space must be a safe area and its content must be authentic. When
tication schemes. Among these, [28] addresses real-time aspects of accessing the global operation space, cells will use solely authentic
cyber–physical systems by targeting wireless sensor networks for real- logic, i.e., smart contracts that have been developed and deployed by
time data access. It uses the imbalanced computational nature of the a legitimate participant and whose integrity has not been breached.
RSA cryptosystem, and it is targeted to scenarios where sensor nodes The logic hosted in the blockchain must be from a legitimate source,
are energy bottlenecks. i.e., from a participant cell.
Other authentication schemes like [29] develop quantum-attack To summarize, it follows the list of requirements:
resistant approaches to smart-card password authentication schemes. Req1. The solution must target the complex and distributed nature of
cyber–physical systems, supporting individual cells with equal partici-
Also, privacy-preserving authentication schemes based on
pation opportunities.
blockchain technology have been developed like [30]. That work relies
Req2. All cells are interconnected and share the global system’s opera-
on an elliptic curve to develop proper signature schemes; whereas the
tion logic. Cells may dynamically produce information as well as logic
blockchain is used to provide a more reliable service. However, the that can be contributed to the global space. All cells may be able to
overall scheme is proven in a fully simulated environment. access the information and logic produced by other cells.
These are orthogonal domains with a substantial mass of prior Req3. The solution must be a secure and fraud-preventive infrastruc-
works. All of them concentrate on solving a particular and different ture. It must be possible to trace the hosted logic pieces to know which
problem. cell (if any) has produced each piece.

4
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

Fig. 1. Cyber-physical system overview, containing distributed cells.

Table 1 Smart contract deployment. Let us imagine that a given logic 𝑙 is to

Initial notation.
be uploaded to the blockchain network. Any logic 𝑙 is instantiated by
Symbol Description
a particular source code 𝑐. The source code is, in turn, implemented
𝑙 A logic or smart contract stored in the distributed ledger in some high-level language like Solidity. The source code has a cor-
𝑐 Source code of logic 𝑙
𝑏 Bytecode produced by the compilation of 𝑐
responding bytecode version 𝑏 that is its executable version running in
𝑓 𝑐𝑜 Compilation function that generates a bytecode from a source code the blockchain network. This association is expressed as 𝑙 = (𝑐, 𝑏).
𝑑 Deployment address of a given bytecode In a blockchain network such as Ethereum, when a smart contract
𝑟 Request from a user willing to run a deployed logic or smart contract
code 𝑐 has to be deployed to the network, it should be first compiled.
𝑝 Request parameters to run a smart contract
Then, its corresponding bytecode 𝑏 is generated by a compilation
functionality, expressed here as 𝑏 = 𝑓 𝑐𝑜 (𝑐), being 𝑓 𝑐𝑜 the compilation
function. The logic of a smart contract can then be deployed in
Req4. The framework must provide a higher security scenario and the network (what is truly deployed is its associated bytecode 𝑏).
network that ensures that the logic contained in it is authentic. For this, Precisely, deploying a smart contract 𝑐 to the network results in that
the deployment of logic to the global space, and execution of logic in the blockchain infrastructure deploys its corresponding bytecode 𝑏 at
the global space, can only be done over authentic logic. Otherwise the a given address 𝑑. As a result, any given source code is, by this
user cell should be notified of a security breach and will be prevented construction, univocally associated to a given deployment address 𝑑
from using it. where its associated bytecode 𝑏 is running. For this, we need to
Req5. This requirement relates to the real-time characteristics of cyber– enhance the logic specification as 𝑙 = (𝑐, 𝑏, 𝑑).
physical systems; these are time-sensitive systems, such that their re- Attack scenario. It is now clear that a deployed contract source-code
sponse time affects their correct operation. It should be possible that 𝑐 has a 1-to-1 relation to its derived bytecode 𝑏, and to its deployment
cells trade-off the security level of the network for the execution address 𝑑.
overhead of utilizing the network. Consequently, any cell can decide
In this context, when a cell node 𝑘 wishes to execute a given logic,
to obtain faster execution rates at the cost of less security in the
it submits an invocation request 𝑟 containing, among other arguments,
environment or viceversa. For this reason, the framework must be
the deployment address and the corresponding invocation parameters
flexible to support a partial downgrading to a less secure network level
𝑝, such that 𝑟 = (𝑑, 𝑝).
when requested by cells. In our framework, higher security levels imply
In this situation, a cyber criminal may have successfully attacked the
additional overhead; whereas lower security levels are implemented by
system by either manipulating the content of the smart contract address
faster framework operations.
in the advertisement dashboard; by uploading a malicious bytecode 𝑏′
such that 𝑏′ ≠ 𝑓 𝑐𝑜 (𝑐); or by manipulating the advertised source code of
3.2. Sample attack on deployed logic the smart contract, among other possibilities. As result of a successful
attack, the code running on the blockchain network does not anymore
The blockchain paradigm has revolutioned the way in which trusted correspond to the expected contract bytecode 𝑏.
transactions take place. Precisely, it allows developers to automate the
execution of agreements without the intervention of intermediaries. All
nodes of the network can have immediate certainty about the outcome 4. VelogCPS approach
of the transaction.
Smart contracts are the key concept lying at the heart of this tech- This section describes the design of VelogCPS middleware frame-
nology. They are programs stored in the blockchain network (i.e., in work. The middleware manages the requests of the participant cell
its global ledger) and run when certain specified conditions hold. The nodes in order to ensure that these operate in a secure environment
global ledger is inmutable and contains the terms of the agreements. in what concerns the authenticity of the logic and data hosted in the
Nevertheless, a number of attacks have been successfully performed blockchain network (i.e., in the global operation space). To clarify
on this technology as exemplified in what follows. For the sake of our approach, the way in which smart contract verification works
clarity, Table 1 advances part of the notation that will be introduced is described first. Then, the system model and the used notation are
in the following section. presented. Lastly, the software design of the middleware is presented.

5
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

Fig. 2. Logic verification process in the blockchain: Verified SC vs non-verified.

4.1. Smart contract verification Table 2

Notation.
Symbol Description
Smart contract verification is the process that checks whether two
pieces of code are, in deed, the same code. Since a source code 𝑐 has its 𝑙𝑖,𝑗 𝑗 𝑡ℎ logic (or smart contract) produced by cell 𝑖
𝐿𝑖 Set of logic pieces developed by cell 𝑖
equivalent compiled executable 𝑏, it must be checked that 𝑐 corresponds
𝑐𝑖,𝑗 Source code corresponding to 𝑙𝑖,𝑗
exactly to 𝑏 when compiled; or viceversa, checking that 𝑏 generates 𝑐 𝑏𝑖,𝑗 Bytecode corresponding to 𝑙𝑖,𝑗
when decompiled. 𝑝𝑖,𝑗 Set of feasible invocation parameters for logic 𝑙𝑖,𝑗
Fig. 2 shows the verification process of smart contracts. The top part 𝑢𝑖,𝑗 Indication of whether it is a verified contract
of the figure presents the steps to deployment of a non-verified smart 𝑓 𝑐𝑜 Compilation function to generate 𝑏𝑖,𝑗 from 𝑐𝑖,𝑗
𝑁𝑖 Main node of cell 𝑖 that is a participant of the global system
contract, starting from its source code 𝑐; whereas the bottom part shows
the verification process of a given smart contract source-code 𝑐 ′ .
Let us imagine that a cell node 𝑘 found source code 𝑐 ′ and wants
to use it; 𝑐 ′ is deployed in the network at address 𝑑 in the form of expressed with the following components 𝑙𝑖,𝑗 = (𝑐𝑖,𝑗 , 𝑏𝑖,𝑗 , 𝑑𝑖,𝑗 , 𝑢𝑖,𝑗 ) such
executable 𝑏. If node 𝑘 needs assurance about the authenticity of 𝑐 ′ , that 𝑐𝑖,𝑗 is the source code; 𝑏𝑖,𝑗 is the executable code or bytecode;
then it should be checked that 𝑐 ′ is, in deed, the source code that 𝑑𝑖,𝑗 is the address associated to 𝑏𝑖,𝑗 upon its deployment; and 𝑢𝑖,𝑗 is
generated the bytecode that is running in the blockchain network, a boolean value expressing whether the logic is verified or not. If the
namely 𝑏. logic is verified, it means that the code has been compiled, deployed to
According to [31], smart contract verification is the process that the blockchain, and it has undergone a successful verification process
guarantees that the blockchain bytecode corresponds to a given high- afterwards that guarantees its legitimate provenance.
level language source code. It implies compiling the source code and Any cell 𝑘 can utilize and/or access any logic 𝑙𝑖,𝑗 . For this, the
checking whether it matches the bytecode stored in the blockchain node elaborates a request containing the deployment address 𝑑𝑖,𝑗 of the
network; or decompiling the bytecode and checking whether it is desired bytecode. Optionally, the request may also include additional
exactly the same as the advertised source code. In essence, and as invocation parameters 𝑝𝑟 such that 𝑝𝑟 ∈ 𝑝𝑖,𝑗 . Thus, a request or
described in Fig. 2, the verification process obtains the bytecode at invocation to execute a given logic 𝑙𝑖,𝑗 in the blockchain is described
the specified deployment address; then, it decompiles the bytecode; as (𝑑𝑖,𝑗 , 𝑝𝑟 , 𝑣) where 𝑝𝑟 is the parameter (sub)set of the 𝑟𝑡ℎ invocation
and lastly, it checks if it is exactly the same as 𝑐 ′ . If both match, the triggered by cell 𝑘. Parameter 𝑣 is a boolean value, expressing whether
verification is successful and it is guaranteed that 𝑐 = 𝑐 ′ . Then, node the logic should be a verified one or not. E.g., if 𝑣 is true, then the code
𝑘 can rest assured that the smart contract is authentic: its origin and running at address 𝑑𝑖,𝑗 will only be executed if such code is verified.
provenance are legitimate ones and it has not been modified in any It is possible that a node 𝑘 elaborates requests with different authen-
sense. ticity requirements with respect to the logic 𝑙𝑖,𝑗 that it wants to use.
The verification mechanism requires that some particular informa- For this, node 𝑘 indicates the verification requirements of each request
tion are provided to identically replicate the compilation process. Such by setting parameter 𝑣 to a proper value. A value true indicates that
information is, among other, the version of the compiler and optimizer the invocation has a high authenticity assurance requirement, so that
(if the latter was also used), and constructor parameters, if needed. the invocation will only take place if the logic is previously successfully
verified. A false value for parameter 𝑣 indicates that there is no need
4.2. Model and notation to check the authenticity of the logic.
Once a logic has been deployed as a verified contract, the middle-
The notation used in the description of the system model is shown ware stores it in its internal Sealed DB. This data base contains all logic
in Table 2, that enhances the initial one provided in Table 1. pieces deployed to the blockchain that have been previously verified.
A cyber–physical system can have multiple (𝑛) cells. Each cell 𝑖 has This system model is enabled through VelogCPS middleware (see
a main server or gateway 𝑁𝑖 that contains the functionality that allows Fig. 3), that follows a component-based software design and the prin-
its integration with the rest of cells that take part in the global system. ciples of separation of concerns. VelogCPS supports the creation of
Each cell 𝑖 may develop a given number (𝑚𝑖 ) of logic pieces. The set the global operation space as well as its controlled execution flow to
of all logic pieces of the cell is 𝐿𝑖 , such that 𝐿𝑖 = (𝑙𝑖,1 , 𝑙𝑖,2 , … , 𝑙𝑖,𝑚𝑖 ). As guarantee the usage of a secure environment in what concerns smart
a result, 𝑙𝑖,𝑗 is the 𝑗 𝑡ℎ logic developed by cell 𝑖. Each cell 𝑖 can deploy contract authenticity. The middleware interconnects the cells of the
a logic 𝑙𝑖,𝑗 that it previously developed to the global operation space cyber–physical system to the global space, allowing them to verify
enabled. logic, deploy it, invoke the execution of deployed logic, and filter its
In the blockchain, the logic pieces are realized by means of smart execution depending on its authenticity assurance parameters (i.e., of
contracts. The specification of a logic piece 𝑙𝑖,𝑗 is now enhanced and its required network security level).

6
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

Fig. 4. Overview of interactions across the middleware components.

Fig. 3. Design of VelogCPS.

• Deployer. This component contains the needed functionality to
carry out the deployment of bytecode-form logic to the blockchain
network.
The main components of the middleware framework are described
• Dashboard. The middleware uses this component to make visible
below:
the available logic pieces to participating cells. A cell interested
• ICell. This component (Interface to Cells) intercepts the requests in using some logic will look into the Dashboard so that the cell
from cell nodes, providing them with the following interfac- can analyse the code and determine if the functionality provided
ing functions: verify_auth, deploy_ver, deploy, exec, by the logic is of interest. If so, it will be able to use it by invoking
exec_ver, and look_up. They are described later in detail. the functions that such logic offers.
This component performs the initial check on the request format
and accompanying parameters provided by the nodes. 4.3. Middleware functionality
• Pacer. This is the core component responsible for controlling
the operation flow within the middleware processes. Upon in- The innerworkings of the middleware are explained here through
terception of a request by the ICell component, it forwards the the needed algorithms that illustrate its rationale and procedures. Fig. 4
request parameters to the Pacer. After analysing the request type, shows the overall behaviour.
the appropriate workflow is initiated. Deployment requests are Let us imagine the initial situation in which a generic cell node
eventually handed over to the Deployer component (and Verifier, 𝑘 comes across some logic 𝑙𝑖,𝑗 that is advertised in the global space.
if needed). The execution of a logic is eventually passed to the
Finding a given logic is facilitated by the middleware through the
Executor component; and verification requests are passed to the
look_up function provided by the ICell component; this function
Verifier component. When the components finish their operation,
triggers a read in the system dashboard where logic is advertised. An
they provide the response back to the Pacer that prepares a re-
example of logic may be a mechanism to reassign resources among its
sponse to the cell node reflecting the final outcome of its request.
local nodes or a discount strategy for asset negotiation. The cell node
The answer is circulated back to the user cell through the ICell
component. checks the source code 𝑐𝑖,𝑗 that corresponds to such a logic, analyses
its functionality, and decides that it wants to use it.
• Deployer. This component is responsible for deploying smart con-
tract logic to the blockchain network. It accesses the distributed Algorithm 1 shows the process to verify any given logic. This func-
ledger and generates a transaction that ends with the logic being tionality is provided by the middleware as function verify_auth.
sent and stored in the global ledger. The algorithm is executed upon a request with parameters (𝑐𝑖,𝑗 , 𝑝𝑟 ). The
• Sealed DB Interface. The middleware has a database (namely middleware intercepts this invocation request in its ICell component,
Sealed DB) that stores the smart contracts that have already been and starts the process to ensure that this logic is authentic. First, it
successfully verified in the system. is important to remcall an inherent characteristic of smart contract
• Verifier. The functionality of the Verifier component is shown verification: For a logic to be verified, it should have been first deployed
in Fig. 2. This component receives a verification request over a to the network at a given address 𝑑𝑖,𝑗 (its deployment address).
particular smart contract source code to be compared against a After an initial check over the validity of the provided parameters
running logic. It compiles the code to generate a bytecode and 𝑝𝑖,𝑗 , it is necessary to determine: (a) if the smart contract 𝑐𝑖,𝑗 has already
compares it to the running code with decompilation. The Verifier been deployed to the blockchain network (i.e., it is already running
makes use of the Sealed DB to store a logic when it is verified. in some nodes); and (b) if such logic has a verification seal (i.e., it is
Additionally, this could be interfaced to an external global block stored in the Sealed DB). Algorithm 1 will result in an attempt to verify
verification engine. source code 𝑐𝑖,𝑗 if it has not already been verified nor deployed. If 𝑐𝑖,𝑗
• Executor. This component receives requests to execute a given is successfully verified, then the algorithm will return a success code
logic. It performs the actual invocation to the running bytecode as boolean value true. If the smart contract cannot be verified, then
on the blockchain. an authenticity problem is detected and a boolean value false will be

7
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

Algorithm 1 Verify authenticity of a logic 𝑐𝑖,𝑗 : function verify_auth contract is stored in the array of verified logic 𝑐𝑣𝑠𝑡𝑜𝑟𝑒 that maps
Require: ICell receives request 𝑟 = (𝑐𝑖,𝑗 , 𝑝𝑟 ) the content of the Sealed DB component. In this case, function
1: if 𝑝𝑟 ∉ 𝑝𝑖,𝑗 then return error ⊳ Request format problem deploy_ver returns true as an indication that source code 𝑐𝑖,𝑗
2: else deployed at address 𝑏𝑖,𝑗 is authentic, meaning that it is a verified
3: 𝑖←0 smart contract. However, if function match would return value
4: 𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑑 ← false false, then it means that a problem was detected such that 𝑐𝑖,𝑗
5: 𝑑𝑖,𝑗 ← get_deploy_addr(𝑐𝑖,𝑗 ) ⊳ If logic not deployed, cannot deployed at address 𝑏𝑖,𝑗 could not pass the verification. As a result,
check the smart contract is not a verified one.
6: if 𝑑𝑖,𝑗 == null then ⊳ Not yet deployed; deploy & check • The logic is already deployed. In this situation (starting at line 20),
7: 𝑏𝑖,𝑗 ← compile(𝑐𝑖,𝑗 , 𝑝𝑟 ) the logic is checked to see if it was also previously verified by find-
8: 𝑑𝑖,𝑗 ← deploy(𝑏𝑖,𝑗 , 𝑝𝑟 ) ing it in the Sealed DB component of the middleware. Algorithm
9: 𝑏′𝑖,𝑗 ← get_bcode(𝑑𝑖,𝑗 ) 1 illustrates this search as an iteration on the verified contracts
10: 𝑐𝑑 ← decompile(𝑏′𝑖,𝑗 , 𝑝𝑟 ) 𝑐𝑣𝑠𝑡𝑜𝑟𝑒 that corresponds to the sealed data base component.
11: 𝑟𝑒𝑠𝑝 ← match(𝑐𝑖,𝑗 , 𝑐𝑑) If the logic is not in the Sealed DB, it means that it is not verified
12: if 𝑟𝑒𝑠𝑝 == true then ⊳ Verification success, store in DB although it is already deployed. Then, the logic undergoes a
13: 𝑞 ←length(cvstore) verification process as illustrated in lines 27 through 38.
14: cvstore[𝑞] ← 𝑑𝑖,𝑗
15: 𝑢𝑖,𝑗 ← true Algorithm 2 shows how the middleware handles the request from a
16: return 𝑟𝑒𝑠𝑝 ⊳ Return OK: deployed & verified generic node 𝑘 to run a piece of logic. The source code of logic pieces
17: else is visible to the cell nodes; and this also includes their internal coding,
18: return error ⊳ Authenticity problem detected function declarations, and function code. Then, any cell node can
19: end if decide which function (and with what parameters) it wants to invoke.
20: else ⊳ If logic is deployed, look first in sealed DB In this context, when a cell node 𝑘 finds an advertised logic 𝑐𝑖,𝑗 that
21: while 𝑖 <length(𝑐𝑣𝑠𝑡𝑜𝑟𝑒) and 𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑑 == 𝑓 𝑎𝑙𝑠𝑒 do it wants to use, the node may trigger a request to execute it. This
22: if 𝑐𝑣𝑠𝑡𝑜𝑟𝑒[𝑖] == 𝑑𝑖,𝑗 then implies that node 𝑘 can invoke the execution of any of the externally
23: 𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑑 ← true visible functions.
24: end if In the request, node 𝑘 may include not only the function reference
25: 𝑖←𝑖+1 but also any other invocation parameters as expressed in 𝑝𝑟 . Then, the
26: end while request of node 𝑘 has the form 𝑟 = (𝑑𝑖,𝑗 , 𝑐𝑖,𝑗 , 𝑝𝑟 , 𝑣) that contains the logic
27: if 𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑑 == false then ⊳ Deployed but not in DB, verify address, the invocation parameters, and a boolean value 𝑣. Parameter
28: 𝑏𝑖,𝑗 ← get_bcode(𝑑𝑖,𝑗 ) 𝑣 expresses whether the logic should be a verified one or not. That is, if
29: 𝑐𝑑 ← decompile(𝑏𝑖,𝑗 , 𝑝𝑟 ) 𝑣 is true, then the code running at address 𝑑𝑖,𝑗 will only be executed if
30: 𝑟𝑒𝑠𝑝 ← match(𝑐𝑖,𝑗 , 𝑐𝑑)
it has been verified, i.e., if it has a verification seal. By the same token,
31: if 𝑟𝑒𝑠𝑝 == true then ⊳ Verification success, store in DB
if 𝑣 is false, the logic can be executed in a straightforward manner,
32: 𝑞 ←length(cvstore)
i.e., without checking a priori if the logic running at 𝑑𝑖,𝑗 is a verified
33: cvstore[𝑞] ← 𝑑𝑖,𝑗
one or not.
34: 𝑢𝑖,𝑗 ← true
It should be noted that to verify the authenticity of a given contract,
35: return 𝑟𝑒𝑠𝑝 ⊳ Return OK: verified
the source code should be passed together with the deployment address.
36: else
37: return error ⊳ Authenticity problem detected Verification will check that there is no attack that has changed the
38: end if running executable nor the advertised source code. This is done by
39: else function verify_auth explained in Algorithm 1.
40: return true ⊳ Return OK: deployed & verified Algorithm 3 illustrates the deployment process carried out by
41: end if the middleware when triggered by the reception of an invocation to
42: end if function deploy_ver. The middleware supports functions deploy
43: end if and deploy_ver. The only difference between them is their verifi-
cation awareness. Function deploy deploys any bytecode logic to the
blockchain; whereas deploy_ver deploys with authenticity aware-
ness. The latter checks if the logic has not been previously verified. If
returned. Function get_deploy_addr(𝑐𝑖,𝑗 ) (shown in line 5) is used
not verified yet, it is first verified inside deploy_ver function.
that returns the deployment address of the running bytecode or null if
Precisely, Algorithm 3 shows the verification-aware process, as in-
it has not yet been deployed.
dicated by the boolean parameter 𝑣. The algorithm receives parameters
From this moment on, one of the following situations may be
𝑐𝑖,𝑗 that is the logic source-code to be deployed; and 𝑝𝑟 or set of
encountered:
parameters for the deployment operation.
• The logic is not yet deployed. In this case, the logic is first compiled In this process, the compilation of 𝑐𝑖,𝑗 is performed with the com-
(function compile) to obtain the corresponding bytecode. After, pile function. The compilation parameters are passed in 𝑝𝑟 . Then, the
it is deployed to the infrastructure ( with function deploy). Once process checks for the verification requirement 𝑣. If the deployment
deployed, the logic can be verified. For this, the bytecode of the needs to be done for a verified logic, then function verify_auth
running logic is again retrieved with function get_bcode of line is invoked. The latter continues the process as indicated in Algorithm
9. Then, the decompilation is done ( with function decompile) 1. If verify_auth returns an error, it means that an authenticity
using the same compilation parameters 𝑝𝑟 , e.g., compiler and problem was encountered, so the deployment does not proceed further
optimizer versions should be used. The running code is authentic and propagates this notification to the requesting cell node.
if the original source code and the source code coming from the In case that the deployment does not require to work with verified
decompilation of the running code are the same. The latter is logic (𝑣 is false), then this function downgrades to a less strict security
checked with function match. Once matched, the verified smart level by performing a simple deployment using function deploy.

8
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

Algorithm 2 Execute logic: function exec_ver operation added to the heavy operations of the blockchain such as
the consensus protocol; the time required to deploy logic to the global
Require: 𝑁𝑘 requests to run 𝑙𝑖,𝑗 with request 𝑟 ← (𝑑𝑖,𝑗 , 𝑐𝑖,𝑗 , 𝑝𝑟 , 𝑣)
space; and the time taken to execute a logic in the distributed ledger
1: 𝑟 ← (𝑑𝑖,𝑗 , 𝑝𝑟 , 𝑣)
triggered by a requesting cell node.
2: if 𝑣 == false then
3: execute(𝑟) ⊳ Run standard logic
5.1. Experimental setting
4: else
5: 𝑖←0
The experimental setting reproduces a global system at a reduced
6: 𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑑 ← false
scale containing cell nodes and an actual implementation of VelogCPS
7: while 𝑖 <length(𝑐𝑣𝑠𝑡𝑜𝑟𝑒) and 𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑑 == 𝑓 𝑎𝑙𝑠𝑒 do
with its constituent components. The cells run on actual hardware
8: if 𝑐𝑣𝑠𝑡𝑜𝑟𝑒[𝑖] == 𝑑𝑖,𝑗 then
equipment to collect realistic measurements. Experiments are carried
9: 𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑑 ← true
out with cell node logic running on Intel i9 13900, with 36MB LGA, 24
10: end if
cores, 32 logical cores, 32 GB RAM, and running at 2 GHz. Acceleration
11: 𝑖←𝑖+1
is achieved with NVIDIA GeForce GTX 1650 with 896 cores in CUDA.
12: end while
Cell nodes are connected to a blockchain network with Polygon [32]
13: if 𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑑 == 𝑡𝑟𝑢𝑒 then
technology. Each cell node runs a blockchain client that is geth version
14: execute(𝑟) ⊳ Logic is verified: run it
1.11.5-stable-a38f4108 virtual machine software. Logic is implemented
15: else ⊳ Logic is not verified: verify before running
solely in Solidity with compiler version 0.8.18+commit.87f61d96 in
16: 𝑏𝑖,𝑗 ← get_bcode(𝑑𝑖,𝑗 )
the Deployer component.
17: 𝑐𝑑 ← decompile(𝑏𝑖,𝑗 , 𝑝𝑟 )
18: 𝑟𝑒𝑠𝑝 ← match(𝑐𝑖,𝑗 , 𝑐𝑑)
5.2. Results
19: if 𝑟𝑒𝑠𝑝 == true then ⊳ Logic is verified: store and run
20: 𝑞 ←length(cvstore)
A set of exhaustive experiments have been performed to validate our
21: cvstore[𝑞] ← 𝑑𝑖,𝑗
solution on the basis of an actual implementation of the middleware
22: 𝑢𝑖,𝑗 ← true ⊳ Just verified
framework. We provide a feasibility validation and a determination
23: execute(𝑟)
of the framework overhead that proves its applicability in the context
24: else
of time-sensitive systems. The obtained temporal cost show s the
25: return error ⊳ Authenticity problem detected
overhead of the process of providing a safe execution environment
26: end if
in the global operation space.
27: end if
Determination of the logic deployment overhead. The first ex-
28: end if
periments present the overhead of the authenticity assurance support
offered by the middleware. Precisely, Fig. 5 compiles the time taken
Algorithm 3 Deployment of logic: function deploy_ver to deploy logic pieces to the global space for the relevant situations.
The first situation concerns exclusively the bare deployment of a logic.
Require: Node 𝑖 issues deployment request 𝑟 ← (𝑐𝑖,𝑗 , 𝑝𝑟 , 𝑣)
Second situation corresponds to a full deployment of a logic. Lastly, the
1: if 𝑣 ==true then
third situation concerns the full deployment of verified logic. To ease
2: if verify_auth(𝑐𝑖,𝑗 , 𝑝𝑟 ) == true then
their comparison, the temporal profiling for each situation is provided
3: return true ⊳ Verified deployment OK
in one column. Table 6 summarizes the temporal results for this set of
4: else
experiments.
5: return error ⊳ Authenticity problem detected
Fig. 5(a) illustrates the first situation and plots the delay experi-
6: end if
enced by requesting nodes upon logic deployment. The experiment
7: else
measures the time taken by the communication from the cell node to
8: 𝑏𝑖,𝑗 ←deploy(𝑐𝑖,𝑗 , 𝑝𝑟 )
the blockchain where it deploys a given logic. This is the base situation
9: if 𝑏𝑖,𝑗 == null then
corresponding to the bare deployment time of logic without waiting for
10: return error ⊳ Deployment error
the completion of the consensus protocol. At such a point in time, there
11: else
is not a full assurance over the eventual annotation of the logic in the
12: return true ⊳ Deployment OK
distributed global ledger. We instrumented the experiments to collect
13: end if
the bare deployment time. This serves as a comparison basis because
14: end if
we are not sure that the block containing the logic has been validated
yet by the peer nodes. As a result, the logic cannot be accounted as a
full deployment since, in some situation, it could happen that the peer
5. Validation nodes do not validate the corresponding deployment transaction.
The temporal overhead of full deployment of the logic is presented
This section describes the validation of VelogCPS framework. The in Fig. 5(b). The temporal measurements include the time taken by
validation is based on the possibility of its realization and on the deter- the blockchain infrastructure to reach consensus. Consensus is reached
mination of the actual overhead as being appropriate for time-sensitive when receiving the acknowledgement of peer nodes confirming the
domains. Precisely, the questions answered in the validation are the correctness of the mined block that stores the deployed logic. As a
following. Firstly, is it feasible to realize an intermediation framework result, this figure shows the overhead of the full deployment of logic
in practice that provides a global operation space with assurance over to the global space because it includes the confirmation from peer
the authenticity of the hosted logic? Secondly, is it possible to provide nodes that the logic has been properly deployed and propagated in the
such an assurance to the participant cell nodes in an online manner and network. On the one hand, it is observed the high cost of consensus in
transparently? In the third place, is the framework suitable for time- public networks reaching 1000𝑥 with respect to the bare deployment.
sensitive domains? For the latter, we determine its temporal behaviour This measure can be reduced in private and hybrid networks; although
and incurred overhead. In the validation, the temporal overhead is these do not constitute a worst-case scenario. On the other hand, it is
analysed for different situations and middleware operations: commu- observed that the mean time of full deployment is 24.307 s. This time is
nication from the cell nodes to public blockchain; the middleware below the minute range which is appropriate for time-sensitive systems

9
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

Fig. 5. Deployment overhead — scenario with unverified logic (execution time in s).

with soft real-time requirements and quality of service management. Table 3

Overhead of deployment of verified logic (in seconds): Summary of Fig. 5.
This is the case of many types of cyber–physical systems present in,
Value Bare deploy. Full deploy. Highest assurance
e.g., smart cities.
Mean 2.483 24.307 27.133
Fig. 5(c) shows the deployment cost with verification, i.e., the
Median 2.461 23.233 27.929
verification-aware deployment. In this case, after the deployment has Max 3.482 39.372 36.715
been fully finished (which includes the completion of the consensus), Min 2.261 19.236 0.656
the logic is guaranteed to be verified. The middleware verifier uses
Polygonscan functionality. As this is the highest assurance level offered
by the middleware, it exhibits a higher overhead than for the previous
Determination of the overhead of the access to verified logic.
scenarios. The middleware uses a Polygon network with a PoS [33] con-
Fig. 6 shows the execution time of the for the case of logic that is
sensus protocol. This consensus mechanism yields a reduced temporal
already verified. It can be observed that the cost–benefit of using
cost and more efficient resource consumption to perform exhaustive
transaction execution in the blockchain network. Still, the authenticity VelogCPS to access verified logic is excellent after the first deployment
guarantee has a cost for the first verification of the logic. Nevertheless, and verification of such a logic. In this situation, the cell requests
as verification of a given logic is a one hop process, this cost pays off to access a given logic are managed by middleware by consulting
in a short utilization term in favour of a guarantee over attacks to the the Sealed DB component. This component has been developed with
logic authenticity. Table 3 summarizes the execution time overhead of MongoDB technology. The temporal overhead is reduced to an average
the different analysed deployment types. value of 39 ms with a median of 17 ms (see Table 4).

10
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

Fig. 6. Deployment overhead — scenario with verified logic (execution time in s).

Fig. 7. Verification process overhead (execution time in s).

11
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

Fig. 8. Overhead of logic execution (time in s).

Table 4 Table 5
Overhead summary (in seconds) for deployment Overhead summary of verification process of Fig. 7.
results of Fig. 6. Column Unverified logic Verified logic
Value Time
Mean 5.896 0.038
Mean 0.039 Median 6.606 0.016
Median 0.017 Max 9.718 0.671
Max 0.672 Min 3.352 0.012
Min 0.013

already deployed and verified. In the first case, the verification is

Determination of the overhead of the verification process. The performed directly by the Verifier component that has a built-in bridge
performance of the verification process is shown in Fig. 7 for the
to the blockchain network verifier. The advantage of using VelogCPS
relevant scenarios. It is also summarized in Table 5. Fig. 7(a) shows the
in the second scenario is evidenced because it translates to a read
cost of verification over logic that is already deployed in the network
operation or query over the Sealed DB component. The latter shows very
but not previously verified. In this scenario, the logic has to be verified
so it is needed to make a service request to the network block verifier fast response times in the order of 0.645% in average with respect to
and a wait for its response. It is observed that an overhead of 5.896 s the previous scenarios.
is obtained which is appropriate for a wide range of time-sensitive Determination of the overhead of executing logic in the global
systems. Fig. 7(b) presents the cost of verification for logic that is space. The last set of experiments analyse the performance of the

12
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

Table 6 Declaration of competing interest

Summary for logic execution process shown in Fig. 8.
Column No verif. Verification Verification The authors declare that they have no known competing finan-
(unverified logic) (verified logic)
cial interests or personal relationships that could have appeared to
Mean 0.331 7.880 0.387
influence the work reported in this paper.
Median 0.331 7.028 0.363
Max 0.364 16.474 1.076
Min 0.309 3.784 0.347 Data availability

The authors do not have permission to share data.

process of executing of a given logic in the global operation space. Acknowledgements

In this case, VelogCPS intermediates the invocation of cells to execute
functions of smart contract logic that is running in the blockchain This research was funded by project ‘‘Design of services for resilient
network. Fig. 8 shows the obtained results for different relevant and real-time execution of social dispersed computing applications in cy-
scenarios. Firstly, for the case when the logic is already deployed ber–physical domains’’ funded by Generalitat Valenciana (Conselleria de
shown in Fig. 8(a). Secondly, for when the logic is deployed but not Innovación, Universidades, Ciencia 𝑦 Sociedad Digital), Spain, under
verified that is shown in Fig. 8(b). In the third place, it shows the Grant No. AICO/2021/138; and by project ‘‘Evolution of the radio access
overhead of the framework in situations when the logic is deployed network towards 6G for massive and low-latency services’’ funded by
and verified as shown in 8(c). ERDF A way of making Europe and Ministerio de Ciencia, Innovación
In the first scenario, only the execution time of the logic in the y Universidades of Spain MCIN/AEI/10.13039/501100011033 under
blockchain is measured. We see that the temporal cost is quite efficient Grant no. PID2021-123168NB-I00.
compared to the rest of values, with a mean of 331 ms, with a reduction
of 23× as compared to the less favourable scenario. References
Fig. 8(b) shows that the verification cost is in the order of a few
seconds around a mean value of 7 s. Nevertheless, this overhead comes [1] S. Ølnes, J. Ubacht, M. Janssen, Blockchain in government: Benefits and
at the benefit of providing the highest assurance and certainty about implications of distributed ledger technology for information sharing, Gov. Inf.
the authenticity of the logic after its verification. Q. 34 (3) (2017) 355–364.
[2] L. Tseng, X. Yao, S. Otoum, M. Aloqaily, Y. Jararweh, Blockchain-based database
In the third scenario presented in Fig. 8(c), it can be observed that
in an IoT environment: Challenges, opportunities, and analysis, 23, 2020, pp.
the benefit of using VelogCPS that is highest after the first verification 2151–2165.
of the logic has been performed. After this initial invocation, the [3] T. Hyla, J. Pejaś, eHealth integrity model based on permissioned blockchain,
overhead of the execution becomes comparable to that of executing an Future Internet 11 (3) (2019) 76.
[4] V. Merlo, G. Pio, F. Giusto, M. Bilancia, On the exploitation of the blockchain
unverified logic. As a matter of fact, times are kept near to constant
technology in the healthcare sector: A systematic review, Expert Syst. Appl. 213
around the average value of 387 ms, with a mean value of 363 ms, that (2023) 118897.
proves the stability in the middleware operation. [5] H.R. Rewatkar, D. Agarwal, A. Khandelwal, S. Upadhyay, Decentralized voting
application using blockchain, in: 2021 10th IEEE International Conference on
6. Conclusions Communication Systems and Network Technologies, CSNT, 2021, pp. 735–739.
[6] M. von Rosing, S. White, F. Cummins, H. de Man, Business Process Model
and notation—BPMN, in: M. von Rosing, A.-W. Scheer, H. von Scheel (Eds.),
This paper has presented the design of a framework to support The Complete Business Process Handbook, Morgan Kaufmann, Boston, 2015, pp.
the safe interaction of connected cells in cyber–physical systems. The 433–457.
solution relies on a model of shared logic, enabled by blockchain [7] M. Gómez Gélvez, Explaining the DAO exploit for beginners in Solidity, 2016,
Last accessed June 2023.
technology and managed by a middleware. The intermediation of the
[8] Worldcoin, What’s Ethereum 2.0. A complete guide, 2023.
middleware guarantees cells to use solely authentic logic in the global [9] S. Palladino, The Parity Wallet Hack explained, 2017, Last accessed June 2023.
operation space. This is done by including the usage of on-the-fly [10] M. García-Valls, A.M. Chirivella-Ciruelos, Provenance verification of smart con-
verification supported by block verifier services. tracts: Analysing the cost of ensuring authenticity over the logic hosted in
The solution offers the possibility of exchanging performance and blockchain networks, Information 15 (1) (2024).
[11] Hyperledger fabric, 2023, Last accessed May 2023.
service cost by the security over the authenticity of the used logic. [12] Q. Lin, H. Wang, X. Pei, J. Wang, Food safety traceability system based on
This has been shown empirically in the validation. It has been proved blockchain and EPCISd, IEEE Access 7 (2019) 20698–20707.
that the middleware is suitable to provide a safe execution scenario for [13] M. García-Valls, A.M. Chirivella-Ciruelos, CoTwin: Collaborative improvement of
connected cells, guaranteeing that the logic in such a space is verified digital twins enabled by blockchain, Future Gener. Comput. Syst. 157 (2024)
408–421.
or reporting the authenticity risk to the user cells. It has been evidenced
[14] G. Malik, K. Parasrampuria, S.P. Reddy, S. Shah, Blockchain based identity ver-
that the highest cost is achieved for the highest assurance levels when ification model, in: 2019 International Conference on Vision Towards Emerging
deploying logic. Also, it has been shown that this high cost is mostly Trends in Communication and Networking, ViTECoN, 2019, pp. 1–6.
influenced by the consensus mechanisms of the blockchain network. [15] H. Gaikwad, N. D’Souza, R. Gupta, A.K. Tripathy, A blockchain-based verification
The verification of the logic lies in the range of few seconds (in the system for academic certificates, in: 2021 International Conference on System,
Computation, Automation and Networking, ICSCAN, 2021, pp. 1–6.
order of 7 for the worst case scenarios). This has been shown to pay
[16] R.S. Lamkoti, D. Maji, H. Shetty, B. Gondhalekar, Certificate verification using
off as it is associated to the initial verification, creating right after an blockchain and generation of transcript, Int. J. Eng. Res. Technol. 10 (2021).
efficient execution scenario where authentic logic is guaranteed to be [17] A.Y. Bykovsky, N.A. Vasiliev, Data verification in the agent, combining
used. blockchain and quantum keys by means of multiple-valued logic, Appl. Syst.
Innov. 6 (2) (2023).
[18] T.K. Agrawal, V. Kumar, R. Pal, L. Wang, Y. Chen, Blockchain-based framework
CRediT authorship contribution statement for supply chain traceability: A case example of textile and clothing industry,
Comput. Ind. Eng. 154 (2021) 107130.
Marisol García-Valls: Writing – review & editing, Writing – orig- [19] Tenderly, 2023, Last accessed on June 2023.
inal draft, Validation, Supervision, Software, Resources, Project ad- [20] Sourcify.eth, 2023, Last accessed on June 2023.
[21] Verifying a smart contract, 2024, Last accessed on January 2024.
ministration, Methodology, Investigation, Funding acquisition, Formal [22] Etherscan, 2023, Last accessed on June 2023.
analysis, Conceptualization. Alejandro M. Chirivella-Ciruelos: Vali- [23] P. Ma, N. He, Y. Huang, H. Wang, X. Luo, Abusing the Ethereum smart contract
dation, Software, Methodology, Data curation. verification services for fun and profit, 2023, CoRR, abs/2307.00549.

13
M. García-Valls and A.M. Chirivella-Ciruelos Journal of Systems Architecture 153 (2024) 103177

[24] A.M. Chirivella-Ciruelos, M. García-Valls, Automating the verification of smart [29] Q. Wang, D. Wang, C. Cheng, D. He, Quantum2FA: Efficient quantum-resistant
contracts in blockchain networks for improving security, in: 2023 49th Euromicro two-factor authentication scheme for mobile devices, IEEE Trans. Dependable
Conference on Software Engineering and Advanced Applications, SEAA, 2023. Secure Comput. 20 (1) (2023) 193–208.
[25] H. network, Ethereum Development Environment for professionals, 2023, Last [30] Q. Mei, H. Xiong, Y.-C. Chen, C.-M. Chen, Blockchain-enabled privacy-preserving
accessed on June 2023. authentication mechanism for transportation CPS with cloud-edge computing,
[26] M. Almakhour, L. Sliman, A.E. Samhat, A. Mellouk, Verification of smart IEEE Trans. Eng. Manage. (2022) 1–12.
contracts: A survey, Pervasive Mob. Comput. 67 (2020) 101227. [31] S. Marx, Verifying contract source code, 2018, Last accessed June 2023.
[27] D. Marijan, C. Lal, Blockchain verification and validation: Techniques, challenges, [32] Matic RPC – Polygonscan Mumbai, 2023, Last accessed June 2023.
and research directions, Comp. Sci. Rev. 45 (2022) 100492. [33] H. Dou, L. Yin, Y. Lu, J. Xu, A probabilistic Proof-of-Stake protocol with fast
[28] D. Wang, P. Wang, C. Wang, Efficient multi-factor user authentication protocol confirmation, J. Inf. Secur. Appl. 68 (2022) 103268.
with forward secrecy for real-time data access in WSNs, ACM Trans. Cyber-Phys.
Syst. 4 (3) (2020).

14