On the Formal Verification of Smart Contracts

Abstract—In recent years, Blockchain-based systems have First, we show an example of an Ethereum Blockchain
experienced rapid growth. Although these systems are in Smart Contract implemented in Solidity [7].
production, they are not exempt from presenting defects in
The example shown in Figure 1 shows some basic func-
the design of their elements such as Smart Contracts. Design
defects in Smart Contracts lead to inconsistencies and conse- tions for an Ethereum Wallet (Ethereum electronic wallet).
quently to incorrect operation, which generates problematic The Smart Contract is composed of a constructor that
situations during and after the execution of the system. In this establishes the owner who can receive payments based on
paper, we describe an overview of main current approaches to messages, and a couple of functions to withdraw funds from
formally verify Smart Contracts. Moreover, it is proposed to
the wallet or to obtain information regarding the current
use Descriptive Logics to verify the consistency of functionality
in the designs of Smart Con- tracts. The balance between status of the amounts that the wallet owns. But, suppose
expressiveness and computational complexity of Descriptive that during the design of the Smart Contract, the withdraw
Logics, allow to model in an unified framework elusive Smart function presents inconsistencies such as handling negative
Contract properties, such as temporal and spatial ones. Fur- amounts or transferring amounts to wrong accounts. These
thermore, it will allow reliable and efficient verification of these
inconsistencies can compromise the operation of the Smart
properties.
Contract at some point in the execution and therefore not
Keywords-Formal Verification; Blockchain Systems; Smart meet the objectives set in its design.
Contracts; Description Logics.
We now present another example of an Algorand
Blockchain Smart Contract implemented in Python using
I. I NTRODUCTION PyTeal [8].
The example shown in Figure 2 presents a Smart Contract
Smart Contracts are immutable programs implemented on that has the function of donating an amount to a specific
a Blockchain that allow managing important assets. Then, it benefactor defined, with a procedure for signing the process.
is vitally important to verify it and thus guarantee its correct If it presents inconsistencies in its design, such as making
design, implementation and execution. Some authors (e.g., the transaction to an entity that is not a correct beneficiary, or
[1]–[4]) agree that it is advisable to carry out this verification that the signature does not have the necessary parameters, it
process before implementation, that is, during the design of can compromise its operation at some point in the execution
said Smart Contracts. Blockchain-based application devel- and again not meet the objectives set out in his design.
opers generally rely on a combination of tools and expertise Therefore, despite the fact that Smart Contracts have a
during the creation of Smart Contracts, but still are unable defined operation in any Blockchain, they are not exempt
to identify consistency issues in Smart Contract functions from presenting defects in their design that lead to in-
prior to implementation and execution, which can cause consistencies in their operation. The foregoing motivates
significant losses [5]. Based on the above, in this proposal, proposing to develop a model that allows verifying the
we consider to use formal verification methods based on consistency of operation in the designs of Smart Contracts,
Descriptive Logics [6] to build an automated verification before implementing and executing them, that is, when they
model making it possible to find consistency in the functions are designed.
defined within a Smart Contract.
Blockchain immutability represents a major difference
II. P RELIMINARIES
from other software systems. It is not possible to modify
a Smart Contract once it is executed on the Blockchain. Most of current systems and applications function in a
This increases security and transparency, but also avoids centralized manner, where an administrator or a group of
correcting defects in Smart Contracts once they have been administrators have access to the information to process, or-
validated and are on the Blockchain. Furthermore, if a ganize, or distribute it based on the objectives of the system
transaction is recorded as a consequence of the execution or dependency that uses it. So, centralized access can lead to
of a Smart Contract, it cannot be reversed. malicious acts such as collusion to favor particular interests,
Said immutability at the time of the execution of the these events increase the mistrust of users regarding the
Smart Contracts, is not exempt from presenting defects in services offered by systems or applications, motivating them
their design. To illustrate this, some examples are presented to seek more reliable, transparent and secure mechanisms
below. [9].
 Figure 2. Smart Contract in PyTeal: Donation.
Figure 1. Smart Contract in Solidity: Wallet.

Blockchains are Bitcoin [12], Ethereum [7], Algorand [8]

On the other hand, systems based on Blockchain have had and Solana [13].
a considerable growth in recent years [10], since they allow On the other hand, Permissioned Blockchains are those
many public or private procedures to strengthen characteris- where users who wish to publish blocks on it must have
tics such as decentralization, trust, integrity and transparency the permission of some authority (which can be centralized
in the information that it is processed and recorded as blocks or decentralized). As only authenticated users are given
on the Blockchain. access, it is possible to control block reading and registration
permissions, as well as knowing the identity of participating
A. Blockchain users. Although, as in Permissionless Blockchains, there
The term Blockchain refers to a chain of distributed are types of failures for block registration, mainly node
and decentralized records linked together that include the crashes, to reduce or mitigate these failures, Permissioned
digital signature of its creator, said records are stored in a Blockchains usually use consensus protocols whose oper-
distributed database and cannot be altered, neither in content ation requires some kind of mechanism. vote so that the
nor in form. order. In other words, Blockchain is defined as validation of the block is approved and can be published
an aggregation-only, immutable record [11]. [11]. The best known examples of Blockchain Permissioned
In this way, the systems that make use of Blockchain are Hyperledger [14] or Corda [14].
are decentralized and through the use of cryptographic tech- B. Smart Contracts
niques such as hash functions, they also make it difficult for Smart Contracts [11] are programs that are executed when
unauthorized modification of the information they process. certain criteria are validated and are hosted on a Blockchain.
Therefore, it is possible to send information between the Among its most common functions are:
participating nodes with a high degree of reliability, since
• Report the execution of a consensus process to the
there is no dependence on administrators or intermediaries
stakeholders so that they can be sure of what was
to validate the information, but rather it is validated by the
validated within the contract.
participating nodes in the Blockchain through a distributed
• Automate the workload, when some conditions are met,
system [9].
the following steps are carried out in the process of
Blockchain is categorized based on its type of permission,
operating the system that makes use of the contract.
that is, based on who publishes blocks. If anyone can post
a new block, then it’s a Permissionless network. On the For Smart Contracts to work, certain conditions are re-
other hand, if only private users can post blocks, then it quired to be met and validated, operations are performed
is a Permissioned network. within a type of Blockchain. Among the most common
Permissionless Blockchains make use of decentralized operations are:
databases (or also known as ledger) open so that anyone • Transfer of funds.
can publish blocks, without the need to have any permission • Registration of an asset.
from any authority. Most of these Blockchains are Open • Sending alerts.
Source platforms, thus ensuring free access for users. How- • Issuance of tickets.
ever, free access opens up possibilities for acts such as fraud, The Blockchain is updated when the operations of a
collusion, or injustice on the part of users. To reduce or transaction have been validated. This makes Smart Contracts
mitigate these acts, Permissionless Blockchains usually use immutable and the results are only accessible to those who
consensus protocols whose operating mechanism requires participate in the Blockchain.
some kind of proof for the block to be validated and pub- Smart Contracts can be created using high-level program-
lished [11]. The most popular examples of Permissionless ming languages, the examples in the Figures 1 & 2 highlight
 Figure 3. Knowledge Base: Genealogical Tree. Figure 4. KR System General Architecture bases on DLs.

the following programming languages: is valid. This technique can be used to implement
automatic verification of rules on a system [17].
• Solidity. Is a statically typed, object-oriented program-
• Model Checking. Is a method for automatically con-
ming language created to enable the build of Smart
firming the correctness of finite-state systems. It refers
Contracts [7].
to the algorithms for fully and automatically evaluating
• PyTeal. PyTeal is a Python-based language binding for
the state space of a transition system to verify whether
Algorand Smart Contracts [8].
a particular system model satisfies a given specification
Smart Contracts, despite the fact that they are immutable, [2].
can present the following inconsistencies in their operation • Stochastic Model Checking. Is a method for calculating
[15]: the likelihood of the occurrence of certain events during
• Integer issues. When handling arithmetic values they the execution of a system [1].
result in output that exceeds an allocated size, or when
D. Descriptive Logics - DL
they result in values less than zero.
• Access control. It is linked to actions by unauthorized They are a family of formal knowledge representation
participants that violate system access rules and busi- languages. Many DLs are more expressive than propositional
ness logic, such as token minting, money withdrawal, logic but less expressive than first-order logic. In contrast
asset retention, stopping and updating contracts, prop- to the latter, the core reasoning problems for DLs are
erty transfer, auction bidding, votes etc. (usually) decidable, and efficient decision procedures have
been designed and implemented for these problems. There
C. Formal verification are general, spatial, temporal, spatio-temporal, and fuzzy
description logics, and each description logic presents a
The above concepts and examples (Figures 1 & 2) lead to different balance between expressive power and reasoning
the introduction of the concept of Formal Verification, which complexity by supporting different sets of [6] mathematical
is defined as the act of proving or disproving the correct constructors.
operation of the algorithms that are the basis of a system For example, Figure 3 represents the knowledge base of
with respect to a specific specification or formal property, a family tree of people, parents, children, etc. The structure
testing is performed using automated validation tools [16]. of the figure is also known as terminology and, in fact, it
Formal verification can be useful to prove the correct is intended to represent the generality or specificity of the
operation of systems built with, for example, cryptographic concepts involved. For example, the link between Mother
protocols, combinational circuits, digital circuits, or software and Father says that ”mothers are fathers”; this is sometimes
expressed as source code [5]. called an ”IS-A” [6] relationship.
There are different types of formal methods, of which we Description logics have been introduced with the aim of
highlight the following: providing a formal reconstruction of framework systems and
• Satisfiability Modulo Theories. Is is a verification tech- semantic networks. Initially, the research has focused on the
nique to prove correctness of system’s properties. Prop- inclusion of conceptual expressions. However, for certain
erties are expressed in a formal language and when all applications it turns out that it is necessary to represent
given properties are satisfied, it is said that the system knowledge by means of inclusion axioms [6].
 Figure 5. Verification in Coq: Invalid transfers.

A knowledge base system based on Descriptive Logics

provides facilities to set up knowledge bases, to reason
about their content, and to manipulate them. The Figure 4
Figure 6. SMC model: Attacker behavior.
generally illustrates the architecture of such a system.
A knowledge base (KB) comprises two components, the
TBox and the ABox. The TBox introduces the terminology,
Regarding verification in Smart Contracts, this can be
i.e., the vocabulary of an application domain, while the
done at the program level or at the design level. The
ABox contains assertions about named individuals in terms
following proposals explore both techniques, of which the
of this vocabulary [6].
following works stand out:
The vocabulary consists of concepts, which denotes sets
In [2] Y. Murray et. to the. They show an overview
of individuals, and roles, which denotes binary relationships
regarding the formal verification of Smart Contracts, where
between individuals. In addition to atomic concepts and roles
it is highlighted that a standard has not been established or
(concept and role names), all DL systems allow their users
the best way to formalize this element of Blockchain.
to build complex descriptions of concepts and roles.
In [4] T. Sun et. to the. present a formal verification
Regarding reasoning tools [6], there are currently some
method for security problems of Smart Contracts at the
high-level ones that work with Web Ontology Language
program level, particularly for vulnerabilities found through
(OWL) such as:
the use of a well-known tool such as Coq proof assistant.
• FaCT++ is a free (GPL/LGPL) open source C++-based Inside the work, we found an example of verification of
reasoner for SROIQ with simple data types (ie for OWL one of the functions of a Smart Contract, using the Coq tool
2). (see Figure 5) stands out.
• HermiT is a free (under LGPL license) Java reasoner The example shows a function within a Smart Contract,
for OWL 2/SROIQ with support for OWL 2 data types where the owner of an account cannot transfer coins to some
and support for description graphs. arbitrary account, which is verified for functionality using
• TrOWL is a free (for non-commercial use) open source the Coq tool.
tractable reasoning framework for OWL 2. In [1] T. Abdellatif et. to the. propose a verification model
at the design level, regarding the behavior of users in Smart
III. R ELATED WORK
Contracts through the use of a protocol at the time of their
In recent years, various formal verification proposals have execution, through the use of Statistical Model Checking -
emerged in some Blockchain elements. During the search SMC (Statistical Verification Models in Spanish) to reduce
for related works, it was found that the verification proposals vulnerabilities in the execution of Smart Contracts.
mainly focus on Smart Contracts, highlighting that until now The following example of SMC (see Figure 6), presents
there is no proposal based on Descriptive Logics. a case of execution of a Smart Contract with behaviors that
First, the following formal verification work is highlighted an attacker can have.
regarding a proposed system based on Blockchain: In the example, a series of scenarios is proposed between
In [18] R. Dávila et. al. they propose the use of Sat- what happens in the execution of the Smart Contract in the
isfiability Modulo Theories [17], to verify the offers of Blockchain and the attacker.
the participants in a bidding process in systems based on Finally, an example of verification using Descriptive Log-
Permissioned Blockchain. An important result of the work ics is presented:
to highlight is the proposed theorem for bidding processes, In [20] R. Van Der Straeten et. to the. present an extended
which says ”Given a set of bidding rules and an offer UML model verified by the DL Loom tool, where they
from a participant, the expression in First Order Logic show as a result the feasibility of maintaining consistency
T R(b) ∧ BO(b) is satisfied if and only if the offer meets during the evolution of UML models. From this work a code
all the bidding rules.”. The verification method, based on example of the Loom tool is presented (see Figure 7).
this theorem, was implemented with the tool Z3 [19]. This example detects that there are objects in an evolved
 Related Work Verification Method Results
Formal Verification of Blockchain Satisfiability Modulo Theories Bidding rules were verified automatically using the Z3 tool [19], in a
Based Systems [18] permissioned blockchain-based system.
A formal verification framework Model Checking They propose to use the Model Checking Coq tool [10] to verify
for security issues of blockchain security properties that present some vulnerabilities within Smart
smart contracts [4] Contracts.
Formal verification of smart Stochastic Model Checking The behavior of users in search of vulnerabilities in the acts of users
contracts based on users and that may compromise a system based on Blockchain is modeled,
blockchain behaviors models [1] making use of the BIP (Behavior Interaction Priorities) framework,
which is based on Stochastic Model Checking.
Towards verifying ethereum smart Theorem Proving They structured bytecode sequences generated by the Ethereum Virtual
contract bytecode in Isabelle/HOL Machine (EVM) [7] into blocks of code lines, and designed a reasoner
[21] built on Isabelle/HOL to verify the generated sequences.
Formal Verification of Smart Con- Satisfiability Modulo Theories They present preliminary results of verifying the correctness of the
tracts: Short Paper [22] Solidity compiler [7], through the use of the F* verification tool, which
is an SMT-Solver.
Validation of Decentralised Smart Game Theory & Temporal They propose a framework where they combine elements of game
Contracts Through Game Theory Logics theory and formal methods based on temporal logic, their combined
and Formal Methods [23] analysis formally and quantitatively clarifies the intended behavior
of the protocol, which relies on a deposit scheme to enforce trust.
Their analysis explores the details of the system under the uncertainty
introduced when the deposit enforcing trust assumption is weakened.
Table I
R ELATED W ORK C OMPARISON .

Figure 7. Verification in Loom: consistency in the evolution of UML

models.

Figure 8. Ethereum SC properties.

sequence diagram that are instances of classes that do not
belong to any class diagram, that is, it looks for incon-
sistencies in a UML model. As we can see, there are executed, it is difficult to verify their specific operation, i. e.,
tools that allow interaction with high-level elements, such they may present inconsistencies in their properties during
as UML models. Likewise, there are reasoners and high- the execution of the contract. Based on the above, in this
level languages, which represents an advantage to bring section a classification of properties that can be found in a
the verification process closer to the designers of Smart Smart Contract is carried out, in order to be able to associate
Contracts. some type of Descriptive Logic for future verification.
Finally to close this section, the Table I summarizes • Addresses. It contains information of the accounts
in a comparative way the related works that we present, associated with the users or groups (space property),
highlighting the verification method and the verification to carry out transactions during the execution of the
results. system (time property).
Each related work proposed to model problems present • Numerical values. Values with or without sign, which
in Smart Contracts at the design and code level, however, represent the cost of some asset, or the cost of a
consistency in Smart Contracts is an issue worth analyzing. transaction, or fee to validate a transaction.
So, the works previously presented motivated to propose a • Transaction signature. Establishes types of relationship
verification mechanism to validate properties that strengthen is-a (knowledge base property) between functions that
the consistency of operation in Smart Contracts. are made in the contract with a signature that validates
the function performed.
IV. C ONSISTENCY PROPERTIES IN S MART C ONTRACTS The previously described properties are found in most
We imagine many types of design-level properties that can Smart Contracts [11]. As we saw in the Figures 8 & 9 in
protect the security of a Smart Contract against unintentional both cases these properties are found.
errors and reassure users that it will work without issues. In the Figure 8, the following design errors can occur:
However, as previously mentioned, once the contracts are • Use of signed integers, which can generate incon-
 For example, to define the knowledge base of a property
of a transaction signature, it can be expressed with the terms
defined in Section II-D.
The declaration in a TBox can be defined in the following
expression:

Signature ≡ Address ⊓ T ransaction (1)

Such a declaration is usually interpreted as a logical
equivalence, which amounts to providing both sufficient and
Figure 9. PyTeal SC properties.
necessary conditions for classifying a property in the Smart
Contract [6].
The ABox contains extensional knowledge about the
domain of interest, that is, assertions about the properties in
sistencies that negative numbers are being used, in
the Smart Contracts. Continuing with the example presented
transactions it is not consistent that amounts less than
for the TBox,
zero are handled.
• Use of invalid addresses, this can generate the incon-
sistency of sending transactions to accounts that are not U ser ⊓ Address(U CODE) (2)
active in the system, or accounts that do not have to be states that the UCODE is a code that corresponds to the
receiving assets. address of a user. Given the above definition of address, one
In the Figure 9, the following design errors can occur: can derive from this assertion that UCODE is an instance of
• Use of signed integers, which can generate incon- the concept Address. Similarly,
sistencies that negative numbers are being used, in
transactions it is not consistent that donations less than hasT ransaction(U CODE, HASH) (3)
zero are handled. specifies that certain UCODE has HASH as a result of
• Use of invalid addresses, this can generate the incon- a transaction. Assertions of the first kind are also called
sistency of sending transactions to accounts that are not concept assertions, while assertions of the second kind are
active in the system, or accounts that do not have to be also called role assertions [6].
receiving donations.
• Using signatures from other accounts, the inconsistency VI. C ONCLUSIONS
occurs when an account that is not authorized to carry In conclusion, the success of applying DLs in different
out the donation process signs the transaction and it is domains, notably in the Semantic Web, motivates propos-
validated. ing DLs as a formality to verify Smart Contracts. The
These properties in Smart Contracts are considered the expressiveness of the DLs [6] allows to model properties in
most basic, because they are present in most contracts, the functions of the Smart Contracts of different domains,
however, the number of properties that have some business such as spatial, temporal or numerical properties. And the
logic such as real estate, bidding procedures or auctions, existence of efficient reasoning tools in DLs may allow the
can increase, showing that there is an extensive and variable development and implementation of a verification method
amount of expressions. Although, as seen in the example of applicable to real cases of Smart Contracts, such as those of
Figure 7, it is possible to apply Descriptive Logics to verify Algorand [8].
consistency in contexts that require handling a high degree This proposal aims to develop a formal verification model
of expressions. based on descriptive logic that guarantees consistency of
functionality in the design of Smart Contracts.
V. D ESCRIPTION L OGIC V ERIFICATION To achieve the objective, modeling and implementation
activities will be carried out as future work, which are
In the case of the property analysis carried out in the described below.
Section IV, the concepts and roles of numerical properties, A specific study of Smart Contracts will be made, the
access control (time and space) and other types of properties focus will be to review business logics where it may be
can be described in a preliminary way. feasible to develop and apply a model based on Descrip-
Then, for the consistency properties in Smart Contracts tive Logics for property verification, particularly on Smart
presented in the section IV, numerical, space-time and Contracts built for the Algorand Blockchain [8].
knowledge base properties were mainly highlighted through The dissemination of Smart Contracts in terms of DLs
quantities to be transferred, addresses and digital signatures. will be completed in order to develop the theoretical model
with greater precision, based on examples such as the one [14] M. Valenta and P. Sandner, “Comparison of ethereum, hyper-
presented in the Section V. ledger fabric and corda,” Frankfurt School Blockchain Center,
After having defined a theoretical model, an implementa- vol. 8, pp. 1–8, 2017.
tion of the proposed model will be developed with logical [15] M. Krichen, M. Lahami, and Q. A. Al–Haija, “Formal meth-
tools that work with OWL, such as FaCT, HermiT and ods for the verification of smart contracts: A review,” in 2022
TrOWL [6]. 15th International Conference on Security of Information and
Finally, the Smart Contracts designs created in Blockchain Networks (SIN), 2022, pp. 01–08.
Systems, such as Algorand [8] that are in production, will
[16] J. Harrison, “Formal verification at intel,” in 18th Annual
be tested to verify their functionality consistency. IEEE Symposium of Logic in Computer Science, 2003. Pro-
ceedings., 2003, pp. 45–54.
R EFERENCES
[17] C. Barrett, R. Sebastiani, and S. C. Tinelli, Handbook of
[1] T. Abdellatif and K.-L. Brousmiche, “Formal verification of Satisfiability, 2009, vol. 185.
smart contracts based on users and blockchain behaviors
models,” in 2018 9th IFIP International Conference on New [18] R. Dávila, R. Aldeco-Pérez, and E. Bárcenas, “Formal ver-
Technologies, Mobility and Security (NTMS), 2018, pp. 1–5. ification of blockchain based tender systems,” Programming
and Computer Software, vol. 48, no. 8, pp. 566–582, 2022.
[2] Y. Murray and D. A. Anisi, “Survey of formal verification
methods for smart contracts on blockchain,” in 2019 10th [19] (2022, Feb.) Programming z3. [Online]. Available:
IFIP International Conference on New Technologies, Mobility http://theory.stanford.edu/nikolaj/programmingz3.html#sec-
and Security (NTMS), 2019, pp. 1–6. logical-interface
[3] W. Nam and H. Kil, “Formal verification of blockchain smart [20] R. Van Der Straeten, T. Mens, J. Simmonds, and V. Jonckers,
contracts via atl model checking,” IEEE Access, vol. 10, pp. “Using description logic to maintain consistency between
8151–8162, 2022. uml models,” in UML 2003-The Unified Modeling Language.
Modeling Languages and Applications: 6th International
[4] T. Sun and W. Yu, “A formal verification framework Conference, San Francisco, CA, USA, October 20-24, 2003.
for security issues of blockchain smart contracts,” Proceedings 6. Springer, 2003, pp. 326–340.
Electronics, vol. 9, no. 2, 2020. [Online]. Available:
https://www.mdpi.com/2079-9292/9/2/255 [21] S. Amani, M. Bégel, M. Bortin, and M. Staples,
“Towards verifying ethereum smart contract bytecode
[5] M. Almakhour, L. Sliman, A. E. Samhat, and in isabelle/hol,” in Proceedings of the 7th ACM SIGPLAN
A. Mellouk, “Verification of smart contracts: International Conference on Certified Programs and Proofs,
A survey,” Pervasive and Mobile Computing, ser. CPP 2018. New York, NY, USA: Association for
vol. 67, p. 101227, 2020. [Online]. Available: Computing Machinery, 2018, p. 66–77. [Online]. Available:
https://www.sciencedirect.com/science/article/pii/S1574119220300821 https://doi.org/10.1145/3167084

[6] The Description Logic Handbook: Theory, Implementation [22] K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi,
and Applications, 2nd ed. Cambridge University Press, 2007. G. Gonthier, N. Kobeissi, N. Kulatova, A. Rastogi, T. Sibut-
Pinote, N. Swamy, and S. Zanella-Béguelin, “Formal
[7] V. Buterin, “A next-generation smart contract and decentral- verification of smart contracts: Short paper,” in Proceedings
ized application platform—white paper,” Ethereum Project, of the 2016 ACM Workshop on Programming Languages
2014. and Analysis for Security, ser. PLAS ’16. New York, NY,
USA: Association for Computing Machinery, 2016, p. 91–96.
[8] J. Chen and S. Micali, “Algorand,” 2017. [Online]. Available: https://doi.org/10.1145/2993600.2993611

[9] T. T. Huynh, T. D. Nguyen, and H. Tan, “A survey on security [23] G. Bigi, A. Bracciali, G. Meacci, and E. Tuosto,
and privacy issues of blockchain technology,” 2019. Validation of Decentralised Smart Contracts Through
Game Theory and Formal Methods. Cham: Springer
[10] S. Verma, D. Yadav, and G. Chandra, “Introduction of formal International Publishing, 2015, pp. 142–161. [Online].
methods in blockchain consensus mechanism and its asso- Available: https://doi.org/10.1007/978-3-319-25527-91 1
ciated protocols,” IEEE Access, vol. 10, pp. 66 611–66 624,
2022.

[11] D. Yaga, P. Mell, N. Roby, and K. Scarfone, “Blockchain

technology overview,” arXiv, 2019.

[12] S. Nakamoto, “A. the bitcoin whitepaper by satoshi nakamoto

- mastering bitcoin, 2nd edition [book],” 2018.

[13] A. Yakovenko, “Solana: A new architecture for a high per-

formance blockchain v0. 8.13,” Whitepaper, 2018.