A Review on SLA Monitoring Based on Blockchain

Full text

A review on SLA monitoring based on blockchain
1st Ranim Sghaier
University of Sousse, ISITCOM H.Sousse,
4011, H.Sousse, Tunisia
ranim.sghaier.99@gmail.com
2nd Chiraz El Hog
University of Sousse, ISSAT Sousse, Tunisia
Department of computer science, College of sciences and arts Unaizah,
Qassim university, Buraydah 52571 Saudi Arabia
c.elhog@qu.edu.sa
3rdRaoudha Ben Djemaa
University of Sousse, ISITCOM H.Sousse,
4011, H.Sousse, Tunisia
University of Sfax, MIRACL Laboratory, 3031, Sfax, Tunisia
raoudhaham@yahoo.fr
4th Layth Sliman
Engineering School of Information and Digital Technologies,
EFREI Paris Pantheon-Assas University,
Villejuif,94800, France
layth.sliman@efrei.fr
Abstract—An SLA is an agreement between a service provider
and a consumer who is going to use the service. An SLA contains
the details and service requirements that must be negotiated and
defined. One of the problems related to SLA management is
the violation of the specified quality of service during service
execution. Recent researches have shown that blockchain tech-
nology and smart contracts (SC) are an effective solution to solve
this problem. In fact, blockchain technology plays an important
role in SLA management especially in SLA monitoring. In this
case, when the customer and provider agree on the details of
the SLA, the latest is transformed into a SC that guides service
provisioning and guarantees better quality of service (QoS). This
paper examines various researches over the period of (2018-
2023) looking at SLA monitoring using blockchain and SCs to
detect violations and enforce compensation. These works present
different monitoring solutions in different domains such as cloud
computing, IOT, 6G network etc. While these solutions helped
to improve SLA monitoring, they also present several challenges.
So, in this paper we explain the different solutions proposed and
their challenges and we provide a comparative study of these
works to draw some conclusions.
Index Terms—Blockchain · Smart contracts · SLA monitoring
· QoS
I. INTRODUCTION
Service Level Agreements (SLAs) are legal contracts be-
tween Service Providers (SPs) and customers. In these SLAs,
service requirements such as expected performance and quality
of service details (e.g. price and validity of service) are
negotiated and defined [1]. In fact, an SLA document includes
a list of SLOs, which represent the measurable elements that
specify the service levels requested by the customer and to be
provided by the provider. Until recently, the process of SLA
management involved a series of manual steps which led to
problems such as wasted of time and errors. To solve this
problem, blockchain and SC technology could be a possible
solution. Blockchain technology found its first real use with
the launch of Bitcoin in 2009. Since then, entrepreneurs from
a variety of sectors have begun to explore the technology’s
potential. The ability of the Ethereum platform and other
blockchains to store and execute computer code has multiplied
the number of use cases for this innovative technology. In
addition, the emergence of blockchain-based smart contracts
has also facilitated the secure execution of transactions. In fact,
the latter inherits several distinctive features from blockchain.
The use of these contracts is experiencing important growth,
particularly in the insurance, banking, government, and other
sectors with similar needs. Like any contractual method, an
SLA is vulnerable to violations. Guaranteeing QoS while the
service is running presents a real challenge. QoS monitoring
is still under study, and various solutions have been proposed.
The aim of this paper is to give an overview of recent research
into blockchain-based QoS monitoring. To fully understand
the SLA monitoring, we analysed, compared and discussed
the different solutions proposed in recent research and their
results. We try to answer the following questions: What are
the proposed monitoring tools?In which domains are these
solutions developed? What are the blockchain technologies
used? What are the limitations of these works? This pa-
per is organized as follows: Section.2 provides background
information about blockchain, smarts contracts and SLAs.
Section.3 focuses on exposing recent researches. Section.4
presents a comparison of the existing works. Section.5 presents
the discussion of the work and Section.6 concludes the paper.
II. BACKGROU ND
In this section we provide background information, which
is necessary for better comprehension of the other sections.
We define the concepts of blockchain, SC, and SLA.
A. Blockchain and Smart Contracts
The blockchain was introduced with the creation of Bit-
coin in 2009. A blockchain is a distributed ledger managed
by a peer-to peer network, in which records are stored as
transactions in a block[1]. These blocks are cryptographically
chained together forming the blockchain. The first block in
the chain, called the genesis block. To modify the infor-
mation in a block, all following blocks hashes would have
to be recalculated. This operation requires an exponential
computation, so data can be stored in the blockchain but not
deleted or altered. Unlike traditional systems which require
users to trust third parties for its operation, the blockchain
enables an environment, without trusted third-party. In fact,

blockchain technology uses a consensus mechanism where
all participating nodes in the blockchain network adhere to.
The most prominent consensus mechanism widely adopted is
the proof-of-work algorithm PoW[2]. One of the concepts of
blockchain is the smart contract. Smart contracts (SCs) are
decentralized shared codes deployed on the blockchain. It
introduces a set of procedural rules and Scenario Response
logic. Parties signing a contract must agree on contractual
details, breach of contract conditions, liability in the event of
breach of contract. In order to automate contract execution, it
is deployed on the blockchain in the form of a smart contract
[3]. The characteristics of a SC include autonomy, secure
exchanges and the elimination of trusted third parties.
B. Service Level Agreements
Service Level Agreements (SLAs) are documents that
specify what Service Providers (SPs) supply to customers.
They contain precise information about the service, such as
availability and response time, as well as penalties for SLA
violations. Precise penalties are essential, because if the SP
fails to achieve what is specified, the customer must be
compensated.
The life cycle of an SLA is divided into six stages:discover
the service provider, define the SLA, establish an agreement,
monitor SLA violations, terminate and apply penalties for SLA
violations[4].
SLA monitoring is a very important step in the SLA lifecycle.
In the following section, we analyse the various solutions
proposed for SLA monitoring.
III. RELATED WORKS
Recently several authors have addressed the issue of
SLA management using blockchain technology. The work[4]
presents a literature review of works related to ”blockchain
and SLA management” this research was realised over the
period 2018-2020 and the authors focus on all the SLA
management life cycle. In our work we will focus on an
important step in the life cycle of an SLA management which
is SLA monitoring. We will try to better understand the
tools proposed for monitoring, the different techniques used,
and the limitations of these solutions. Our research will be
carried out over the period 2018-2023. The Fig.1 shows the
article collection process, we search in the DPLP and Scopus
databases works related to keywords ”blockchain and SLA
monitoring”. We have chosen the most recent works (between
2018 and 2023), the most cited and the works that appear as
references in the selected articles.
Table I exposes the selected papers features.
This section focuses on research related blockchain-based
SLA monitoring solutions.
In the work presented in [1], a prototype of an SLA man-
agement system based on the Etherum blockchain, called
SLAMer, is designed and developed. In this system a mon-
itoring solution is deployed to enforce penalties. Once the
customer and the SP agree on all the details, the SLA is
converted into a SC and deployed on the Etherum blockchain.
Fig. 1. Papers selection process.
TABLE I
EXP OSE S TH E SEL ECT ED PAP ER S FEAT URE S.
Ref Publication
date
Number
of
citations
Cited by
[1] 2019 2 [17]
[2] 2020 6 [14]
[5] 2018 24 [7][14][18]
[6] 2018 31 [1][9][14][15][18]
[7] 2019 51 [1][8][9][12][13]
[14] [18]
[8] 2020 21 [14][15][17][18]
[9] 2020 4
[10] 2019 71 [9][12][14][17]
[11] 2018 16 [14]
[12] 2020 33
[13] 2021 3 [17][13]
[14] 2021 13
[15] 2022 8
[16] 2022 2
[17] 2023 0
[18] 2023 0
[19] 2023 0
[20] 2023 0
To activate the SC and start monitoring, the customer must
enter Ether in the smart contract. The monitoring service starts
measuring the SLOs defined in the SLA. These values are sent
to the SLAMer API. The SLAMer retrieves the correct SC
address, calls the correct verification functions according to
the SLO type and sends the measured value with the SLO ID.
This function can only be executed by the monitoring solution.
If the SLA is valid (i.e., the SLA is between the start and
end date, and the number of violations has not reached the
violation threshold), SLO are periodically checked to ensure
that all performance levels are being met. Thus, when the
SLA becomes invalid, Smart Contract will terminate the SLA.
If the SLA has never been violated, the full amount will be
transferred to the Service Provider. Else, a compensation value
is calculated and deducted from the SLA price and returned
to the Customer. This approach uses an external monitoring
solution, so both the SC and the customer must ensure
that the monitoring service measures the SLOs correctly and
constantly. What’s more, if the monitoring service is down,
no measurements can be sent to the SC, leaving the SLA
unverifiable. Given these two limits, the monitoring service
remains a Trusted-Third-Party (TTP) in the system.

The approach proposed in [2] enables the customer(s) to vali-
date the CSP(s)’(cloud service provider) compliance with the
services contracted in the service level agreements (SLAs) and
to ”autonomously” compensate customers in case of security
breaches. At the same time, the proposed approach prevents
customers from making false claims for profit. The authors
have used The Ethereum blockchain on which a smart contract
is executed in a decentralized manner. The SC includes the
security Service Level Agreement (sec-SLAs) contacted and
the measurement techniques for each SLO. In addition, the SC
is responsible for interacting with various oracles (customer
data oracles, log recovery data oracles and cancellation ora-
cles), aggregating monitoring logs using defined measurement
techniques, autonomous compensation in the event of secSLA
violation, and allows termination based on time and user
request. CSP and customer exchange Ethereum addresses. The
CSP deploys the smart contract with an ether deposit value
equal to the customer’s subscription value and includes the
customer’s address. Then, shares the smart contract address
with the corresponding Cloud client. The client initiates a
validation session by sending a validation request to its data
oracle which interacts with the SC by sending the total number
of batches and its oracle ID. The SC continues to receive
log batches, and once the number of batches received equals
the number of batches contracted, it begins to aggregate the
batches and then validate them against its corresponding SLO.
If the aggregated result does not comply with the contracted
SLO, the customer is compensated. If the SC receives a request
from the CSP/customer to cancel the contract, it returns
the deposit to the CSP (or the remainder), then definitively
deactivates the smart contract.
A prototype using blockchain-based SC was implemented in
[5]. It enables the monitoring of service level agreements, as
well as billing services in the cloud, in a decentralized and
transparent way. For monitoring the authors use an oracle
that periodically sends information on service availability to
the blockchain. If a service is un available, the SC will send
coins for the customer concerned. These coins are then used as
evidence by the billing SC to compensate the customer in the
event of an SLA breach. To document customer and supplier
actions in optimum time, tokens are exchanged between the
various parties involved (supplier, customer, and external SLA
monitoring tool). In this work, no evaluation has been carried
out.
In [6] the authors propose a framework for managing SLAs
on the blockchain by transforming them into smart contracts.
This framework consists of the side-chain for specifying and
negotiating SLAs and the blockchain network on which the
SLA is executed as a SC. For SLA monitoring, the authors
have proposed a solution based on participants (acting as au-
ditors). These auditors monitor service execution and achieve
consensus on the real measurements derived by a predefined
consensus protocol. These results are then sent via an oracle
to the smart contract. The SC evaluates the monitoring data
and the conditions of the agreement and takes any necessary
action. the proposed framework was not evaluated.
In [7] the authors have designed and implemented a
blockchain-based SC prototype that replaces the TTP(Trusted
Third Party) to meet the terms of the SLA. The SC insures to
both customer and provider that the contract will be enforced
and guarantees a transparent and immutable SLA. This work
enables dynamic interaction between customer and provider.
It automates the dynamic compensation of the SLA by the
SC in the event of an SLA violation, and the payment of
service charges by the customer in the other case. To enable
dynamic compensation to the customer and automatic payment
of the subscription without the need for a TTP(Trusted Third
Party), it is envisaged that the customer sends the subscription
fee before the service begins, and this fee is blocked in the
SC until the SLA is terminated. a monitoring mechanism
is used to perform measurements and call the SC to verify
SLA execution. This work allows Dependency of billing
handling removed and the monitoring solution only reports
SC violations.
In the work presented in [8], the authors have proposed a
decentralized blockchain-based approach for assessing SLA
compliance and enforcing consequences in cloud-based Inter-
net of Things (IoT) applications. The cloud provider offers
Message Queuing Telemetry Transport (MQTT) servers as a
service required by IoT applications. The authors described
the scenario of an IoT healthcare application that uses MQTT
for data exchange. The proposed blockchain-based approach
enables remote patient monitoring and emergency response.
Cloud providers guarantee the quality of MQTT servers using
the concept of SLA. For this article, the GCP (Google Cloud
Platform) SLA was used to model the approach that guarantees
consumer compensation when a set of valid MQTT requests
results in accidental device connections. Monitoring agents
have been developed to help smart contracts decide on the
compliance level of obligated providers. These agents should
collect metrics related to MQTT server performance. Once the
monitoring agent detects an availability problem, it informs
the smart contract. The SC registers incidents as well as valid
MQTT requests and will continue to accumulate incidents until
the error rate reaches 10.
This solution is based on hyperledger fabric. It used Multi-
Version Concurrency Control (MVCC) to avoid the problem
of double spending. This mechanism (MVCC) resulted in
transaction failures for all test scenarios due to a conflict in the
MVCC read/write sets. This conflict is triggered because HLF
has encountered consecutive incidents of transaction reporting
to the smart contract. So, it causes a problem of monitoring
dependability at high monitoring agent throughput.
The authors in [9] have proposed an SC-based solution aimed
at automating the monitoring of SLA compliance levels. A
proof of concept was designed, implemented, and deployed
in a cloud infrastructure used by Point of Presence Espirito
Santo (PoP-ES) and network providers. Two dApps have been
created, with the aim of verifying SLA compliance concerning
link availability. One dApp will be used by PoP-ES to record
downtime events and their timestamps. The other dApp will
be used by the network provider (link operator) to schedule

maintenance windows. A Viaipe monitoring tool was used
to collect data on the loss of consumer connections. This
data is sent to the blockchain via a data analysis platform.
For each unavailability period (down and up events) inserted
in the dApp, the unavailability (time between down and up
events) is stored in the blockchain for further verification. In
the smart contract implementation there are two arrays, one
to store downtime events and the other to store up events.
For each i-th up event, its timestamp is subtracted from
the corresponding i-th downtime timestamp, and the counter
variable is incremented with this unavailability period. After
that, the Availability is calculated. In this approach, Smart
contract does not allow for automatic compensation in the case
of violation.
The work presented in [10] used the blockchain technique as a
platform for the automatic enforcement of cloud SLAs. They
proposed a witness model that enables automatic detection
of SLA violations. In this model, independent and anonymous
witnesses are randomly selected from a group of decentralized
witnesses to detect and report cloud service violations. The
authors analysed cookie reliability using game theory (Nash
equilibrium). The proposed system consists of two types of
smart contracts: One for the witness pool enables witness
management, generation of specific SLA contracts and sorting
of the witness committee. The other is the smart contract of
a specific SLA, which is used for the SLA enforcement. This
model has been carefully designed to force the witness to
be honest. But this witness model is a long and complicate
process because for each witness there is a specially designed
payoff function.
The approach proposed in[11] is a proof of concept in the
context of network functions virtualization (NFV). This ap-
proach describes the SLA management process between an
NFV SP (resources) and a subscriber. A subscriber can request
the desired resources from a SP and specify the SLAs that
must be met. The SP, in turn, must deploy a SC in the
blockchain that contains the SLAs translated into code, details
of the resources requested, and the duration and price of the
services. trusted monitoring agents are used to continuously
monitor for SLA violations. If a violation is detected, they
send this information to the SC and the subscriber can receive
the defined compensation; if no violation is detected and the
contract has not expired, they continue monitoring. Otherwise,
if the contract has expired, the SP can receive the funds stored
in the SC. In this work no evaluation has been carried out.
Also, in [12], the authors introduced a new approach that
uses an SC-based architecture for SLA management for Edge-
toCloud federated computing environments. It enables the QoS
requirements defined in the SLA to be monitored. A monitor-
ing solution is implemented, that continuously collects QoS
data from deployment options recorded on the blockchain.
In addition, the monitoring system contains an alarm trigger,
which is a rule-based entity that continuously checks incoming
monitoring data. Once a violation is detected, it triggers
the decisionmaking mechanism to reassess the probability of
achieving high quality of service. This approach uses a Markov
Decision Process (MDP) system to automate decision-making.
It ensures that any SLA violations are dealt timely. Transaction
fees depend on the amount of traffic on the blockchain and
the execution time required for each operation.
The authors of [13] use the Hyperledger blockchain platform
to detect service level violations and maintain the transparency
of the entire process, ensuring that the cloud service provider
complies with the signed SLA agreement. Each cloud service
provider has its own SLA, which the customer must sign
depending on the subscription they have taken out. Blockchain
monitors all activities using blockchain code, which is re-
sponsible for detecting violations of the SLA and informing
both the customer and the cloud service provider. Three
algorithms have been designed: the first enables detection of
SLA violations: the signed SLA acts as a blockchain code
that will continuously monitor the cloud service provider’s
logs, then check the logs against various SLA parameters for
a given user and verify whether there is a violation. The second
enables log storage: once SLA violations have been detected,
transactions will be added to the blockchain ledger to make
them accessible to both customer and administrator. And the
final algorithm enables the customer to work with multiple
cloud service providers and access each of their resources.
The authors in [14] present a distributed infrastructure based
on a private blockchain system that exploits the fundamental
properties of blockchain to achieve immutable SLA monitor-
ing and automatic enforcement of SLA conditions, precisely
the response time of web applications, agreed between ap-
plication owners and cloud providers. The overall monitoring
architecture consists of one or more customers, a cloud service
provider, and a monitoring authority. The customer process is
activated when the endpoints (services) receive their data and
register their accounts on the blockchain via their respective
wallet addresses. Then, the customer and his service provider
define the SLOs (Service Level Objectives). The SLA is
then provided to the monitoring service to evaluate terminal
performance and maintain its immutable copies of records on
the blockchainbased distributed ledger via its decentralized
private network. These records enable continuous monitoring
of performance and SLA application. During the recording of
terminal response times, the monitoring service also checks
Internet quality every time. This approach misses the decision
in the case of a breach.
The work presented in [15] uses smart contracts and
blockchain technology to manage, execute and monitor SLAs
for fog environments. The architecture of the proposed frame-
work comprises 7 layers: (1) client layer, (2) application layer
(3) service layer, (4) oracle,(5) SLA service layer ,(6) data
layer (7)and fog infrastructure. The SLA service layer (5)
is responsible for monitoring, verifying, and enforcing SLAs
in the fog computing environment. The SLA monitor tracks
application status which includes information details of fog
providers, participating users, and device resource usage. This
information is received from the resource manager to the
SLA monitor via Blockchain oracles. All fog device resource
usage information and application status are collected by the

SLA monitor and sent to the SLA executor. If the application
status execution is complete, the SLA executor will enforce
the SLAs by making payments. In this system, transaction
costs increase as the number of devices increases, because
SC’s communication overheads for collecting data from the
fog equipment via the oracle will be higher.
The authors in [16] present a conceptual framework for
improving SLA management and ensuring QoS in 6G use
cases such as inter-provider agreements. This article consid-
ers a use case of an inter-provider agreement based on an
intelligent contract. The authors use new solutions such as
IOTA Tangle to perform transactions, IPFS to store the hash
of use case data files and chainlink to access off-chain data
streams for SLA monitoring. When the service provided run,
the SLA monitoring phase starts. First, the SC sends a request
to Chainlink Oracle (CLO) for the data streams. Next, the
Chainlink Oracle (CLO) obtains the SLA data streams from
Kafka, accessible via an API. Then, these data streams are sent
to an intelligent contract, where they are compared to verify
SLA compliance. In case of violation no decision-making.
The article [17] presents a new consensus mechanism called
Proof-of-Monitoring (PoM) for a new SSLA(Secure Service
Level Agreements) management framework in blockchain-
based 5G networks. The authors have proposed a monitor-
ing engine to manage network monitoring activities. SLOs
are converted into measurable metrics. Peer nodes in the
blockchain network monitor packets transferred between a
customer and its provider via a wireless communication chan-
nel and according to the security metrics in SSLA. Each
period they transmit the monitored data to the blockchain.
The violation monitoring engine calculates the values for each
SSLA security metric and checks whether the SP complies
with the SLO (a violation is declared if more than 50the
active monitoring nodes enter data, confirming a violation).
Every period, the monitoring engine sends a report to the
Compensation Calculator (calculates the compensation for
the customer, the penalty for SP and the blockchain nodes
of the service fee.) and Reputation management (calculates
the reputation scores for blockchain nodes. If a blockchain
node’s reputation score reaches a certain threshold, it will be
eliminated from the system). The proposed consensus protocol
was developed using Communication Service Providers (CSP)
in the Process Analysis Toolkit (PAT) model checker. The use
of PAT has limited the number of nodes in the model, as the
time required to run a check increases exponentially as the
number of nodes increases.
The work [18] presents a new blockchain-based SLA compli-
ance monitoring framework in the IoT context. The monitoring
side presented is responsible for collecting metrics related to
the quality requirements set out in the SLA. It also contin-
uously observes the availability of edge and server IT units.
Whenever the monitoring manager encounters an incident that
requires attention, it alerts the smart contract by submitting
a transaction consisting of a set of collected metricsM. The
proposed monitoring and alerting architecture are based on
a well-established open-source project, namely Prometheus.
Using Prometheus, this study instruments a set of pertinent
metrics for each component (edge, cloud, application). It ex-
poses these metrics via REST APIs. The Monitoring Manager
collects the exposed metrics and stores them in a database.
An Alert Manager is used to define thresholds that activate
smart contracts using a query language (PromQL). To facilitate
communication between Prometheus (the monitoring/alerting
system) and the smart contracts on the blockchain side, a
component called Fabric REST is used. While the proposed
system design strategies have proven effective for centralized
applications, the authors indicate that the same cannot be
safely assumed in the context of distributed blockchain ap-
plications.
In [19] the authors present a use case of intervendor
agreements based on smart contracts and service level
agreements(SLA) in the 6G network domain.They proposed
5Growth-DApps as a marketplace where ADs(administrative
domain) can act as providers or consumers and sell or lease
resources and creating several innovative contractual agree-
ments. These contracts will be stored on the blockchain.
The interaction of the 5Growth platform with blockchain has
been divided into two phases: 1- setting up inter-provider
agreements and 2-monitoring SLA. In the monitoring phase,
once the agreements are created, the SLArelated data jour-
nals need to be monitored. In the monitoring SLA logs
step two approaches are proposed. The first approach uses
IPFS: Pertinent internal journal messages received from the
5GrVoMS message queue are created and stored on IPFS . As
a result, a hash is obtained which is stored in the blockchain
and shared with the consumer AD. To store all pertinent
details concerning the SLA a smart contract, calledSLA.sol,
is created. So, to ensure that the KPIs have been met, the
consumer can access to the logs using the hash. The second
approach uses Chainlink in a case where only selected KPIs
or filtered logs are required by the consumer AD. The 5Gr
API subscribes to the relevant internal log messages received.
The consumer AD sends a specific request and filters the data
to perform real-time SLA monitoring. Experience shows that
the first approach leads to an overall reduction in costs and
latency. The second approach is a more appropriate solution
for filtered logs and continuous flow of SLA data.
The approach proposed in [20] presents a solution for evalu-
ating resource performance in cloud computing. The authors
used blockchain to store the visible logs of the cloud SLA.
Each cloud consumer has a unique identifier, and logs relating
to this identifier are monitored. To monitor SLA violations
and the compensation procedure, a web application with a
blockchain as back-end is used. Logs are uploaded to the web
application where the hash is generated from IPFS. It takes
the breached logs, and stores them in the cloud. Once the hash
of the log file has been uploaded to the blockchain network,
consumers can view the log files and audit themselves. To
begin with, a customized OpenStack cloud environment is
configured. In order to record the details of the VM’s down-
time,a load is applied to it, causing it to occupy its network.
Downtime logs and timestamps are updated in the log files.

Two algorithms have been designed, the first to generate a log
file for OpenStack virtual machine (VM) downtime. Once a
connection has been established, monitoring starts. Every time
the system fails, the log file is updated. The second is designed
to generate log files for each pod generated or destroyed. For
large logs, the authors have used IPFS, which gives a fixed-
length hash for the file depending on its content. As file size
increases, so processing time increases.
IV. COMPARATIVE STUDY
In this section, we present a comparative study of related
work (see Table 1). In the table, we compare the proposed
approaches according to the following criteria: Domain:
The domain in which the authors worked. Platforms: The
blockchain platform used. QoS criteria: Monitored QoS
parameters. Monitoring tools: The proposed monitoring
tool. Communication onchain/offchain: The method used
for communication between the onchain and offchain parts.
Decision in case of violation: The decision taken by the
monitoring tool in the event of an SLA violation. SLA type:
A static SLAs monitoring, define a single, non-modifiable
service level.
As shown in table II, works presented in [1] and [11] were
pure blockchain while the rest of the works address the issue
of SLA monitoring using SC in other domains such as the
6G network domain [16]and [19], 5G network [17] and the
rest of the works were in cloud computing and IOT.
Most of the proposed approaches have been implemented
on the Ethereum platform, except for works presented in
[8],[13] and [18], which used Hyperledger Fabric, and
approach discussed in [14], which uses a private blockchain.
The choice of Ethereum is due to its ability to run
Turningcomplete SC. In Ethereum, Turing Complete means
using conditional instructions and loops to program smart
contracts. In fact, non-Turingcomplete SC languages don’t
support dynamic compensation, which requires complicated
computation.
Different QoS parameters were monitored on these works.
In [8] the authors are interested in transaction success/failure
rate and latency. In [11] the authors focused on throughput. In
[12], the authors are only interested in calculating the number
of packets per second. The work in [14] and [16] concentrated
on response time. In [13],[17],[18]and[19] the authors focused
on Sla parameters. The rest of the existing works focused on
availability.
SLA monitoring presents a major challenge, different monitor-
ing tools were used in this work. The authors in [8] and [11]
used monitoring agents. The work [5] presented a monitoring
system based on External SLA monitoring. The authors in [6]
used a Classical auditor. In work [9], a Monitoring Via ipe
Tool was used. For the work presented in [10], the authors
proposed a witness committee model as a service monitoring
solution. This model was carefully designed to oblige the
witness to behave honestly to increase his profit. In [17], the
authors proposed a consensus mechanism. The rest of the
works mentioned using a monitoring system without giving
any detail about the techniques used.
Smart contracts can only access and write information stored
on the blockchain, which is a closed network. Oracles bridge
the gap between the blockchain and the real world by provid-
ing data from outside the blockchain to smart contracts [9].
In the works [2],[6],[10] the authors have indicated the use of
an oracle. The works [5]and [15] use the blockchain oracle
”oraclize”, the works [12],[16] and[19] use ”chainlink”.The
authors in [18] mentioned that they used a Fabric REST Server.
The rest have not indicated the use of oracles.
In this survey, all the presented works focused on the concept
of compensating customers for SLA violations. In fact, if
one or more agreed conditions are not met, the customer
should receive compensation according to the penalties already
defined in the SLA. In works [9],[14],[16], the authors did not
address this concept. Works [1],[2],[7],[11],[15]and [17] allow
for automatic customer compensation. In work [5], tokens are
sent to the client. The solution proposed in [12] terminates
the SC and compensates the consumer. The solution proposed
in [13] just Informs the provider and the customer. Other
approaches [6],[8],[10]and [18], wait until the end of the SC or
until the number of violations reaches a predefined threshold.
These approaches define the standard terms for static SLAs. In
fact, the languages used allow a single, non-modifiable service
level to be defined. However, [2],[6],[17],[18] and [19] are the
only projects to cover the dynamic aspect in their solutions. In
fact, a new language called SLAC is proposed in [4], which
provides a new mechanism using rules to cover the dynamic
aspect of SLA monitoring.
V. DISCUSSION
As shown in Fig.2, most of the works has used the Ethereum
platform. In fact, users can’t expect immediate confirmation
of the deployed smart contracts. They must wait for the blocks
containing their transactions to be confirmed by the network,
which can take several minutes. In addition, the scalability
of Ethereum-based systems is theoretically limited by the
constraints of the Ethereum blockchain, such as the size of
the SC and the maximum gas used.
Fig. 2. Employed blockchain technologies.
Also, Fig.3 depicts that most of these solutions offer meth-
ods for static SLAs monitoring, which define a single, non-
modifiable service level.
Moreover, despite the diversity of QoS, each of these works
covers only a few QoS parameters. Fig.4 shows that most of
the works focused on availability. Adding to that, as shown

TABLE II
ACO MPAR ATIVE S TU DY BET WE EN SLA MONITORING SOLUTION USING BLOCKCHAIN BASED SC
Ref Domain Platform QoS criteria Monitoring tools Communication
on-chain /off-
chain
Decision in case of violation SLA type
[1] Blockchain Ethereum Availability ,Re-
sponse Time
Monitoring system - automatic compensation Static
[2] Blockchain
+ Cloud
Ethereum Availability Monitoring system Oracle automatic compensation dynamic
[5] Blockchain
+ cloud
Ethereum Availability External SLA monitoring Oraclize Send coins to customer Static
[6] Blockchain
+ cloud
Ethereum Availability Classical auditor Oracle Enforce compensation dynamic
[7] Blockchain
+ cloud
Ethereum Availability Monitoring system - automatic compensation Static
[8] Blockchain
+ Cloud +
IoT
Hyperledger
Fabric
Availability Monitoring Agent - Enforce consequences Static
[9] Blockchain
+ Cloud
Ethereum Availability Monitoring Via ipe Tool - - Static
[10] Blockchain
+ Cloud
Ethereum Availability Witness committee Oracle Enforce compensation Static
[11] Blockchain Ethereum Throughput Monitoring Agent - automatic compensation Static
[12] Blockchain
+ Edge to
Cloud
Ethereum X Packets Per
Second
Monitoring system Chainlink Termination of SC Static
[13] Blockchain
+ Cloud
Hyperledger
Fabric
SLA parameters Monitoring system - Inform provider and customer Static
[14] Blockchain
+cloud
Multichain Response Time Monitoring system - - Static
[15] Blockchain
+fog
computing
Ethereum Availability Monitoring system Oraclize automatic compensation Static
[16] Blockchain
+ r´
eseau 6G
Ethereum Response Time Monitoring system Chainlink - Static
[17] Blockchain
+ r´
eseau 5G
Ethereum SLA parameters Consensus Mechanism - automatic compensation Dynamic
[18] Blockchain
+IOT
Hyperledger
Fabric
SLA parameters Monitoring system Fabric REST
Server
Enforce consequences Dynamic
[19] Blockchain
+ 6G
network
Ethereum
Polygon
Sla parameters Monitoring system Chainlink IPFS - Dynamic
[20] Blockchain
+ cloud
computing
Etherum Availability Monitoring system - - Static
Fig. 3. SLA types.
Fig. 4. The QoS parameters used .
in Fig.5, we note that there are works in which the authors
have not specified how the on-chain part communicates with
the off-chain part.
Fig. 5. Communication on-chain/off-chain.
While the potential of blockchain technology has been
exploited in various domains, Fig.6 depicts that the SLA moni-
toring solutions propounded by this work were in blockchain,
5G/6G network, cloud computing and IOT. Finally, the im-
plementation of most of monitoring solutions was not well
detailed. Works presented in this paper have contributed to

Fig. 6. Domains.
the development of one of the main stages in the lifecycle
of an SLA, which is SLA monitoring, especially in the
cloud domain. But these solutions remain limited in terms
of domains. In fact, SLAs are used in several domains. In
addition, many other computer technologies (ontologies, deep
learning etc.) can be exploited to improve monitoring tools.
Moreover, several blockchain platforms have been designed
recently, so we can try to exploit them.
VI. CONCLUSION
In this paper, we presented an overview of proposed so-
lutions for SLA monitoring via blockchain-based SCs. The
approaches studied have designed and implemented different
frameworks for SLA management in which monitoring so-
lutions are put forward with the aim of collecting different
events and information. And based on this information, the
appropriate decision is taken by the SC. Solutions presented
have improved SLA monitoring, but these solutions remain
limited especially in terms of domains(5G/6G network, cloud
computing and IOT), and blockchain technologies(Etherum,
hyperledger fabric). This motivates us to exploit other tech-
nologies to develop monitoring solutions in pure blockchain.
REFERENCES
[1] Schweizer, C. (2019). SLAMer: a blockchain-based SLA Management
System.
[2] Taha, A., Zakaria, A., Kim, D., & Suri, N. (2020, April). Decentralized
runtime monitoring approach relying on the ethereum blockchain infras-
tructure. In 2020 IEEE International Conference on Cloud Engineering
(IC2E) (pp. 134-143). IEEE.
[3] Wang, S., Yuan, Y., Wang, X., Li, J., Qin, R., & Wang, F. Y. (2018,
June). An overview of smart contract: architecture, applications, and
future trends. In 2018 IEEE Intelligent Vehicles Symposium (IV) (pp.
108-113). IEEE.
[4] Hamdi, N., El Hog, C., Ben Djemaa, R.,& Sliman, L. (2021, December).
A Survey on SLA Management Using Blockchain Based Smart Con-
tracts. In International Conference on Intelligent Systems Design and
Applications (pp. 1425-1433). Cham: Springer International Publishing.
[5] Neidhardt, N., K¨
ohler, C., & N¨
uttgens, M. (2018). Cloud Service Billing
and Service Level Agreement Monitoring based on Blockchain. In
EMISA Forum: Vol. 38, No. 1. De Gruyter.
[6] Uriarte, R. B., De Nicola, R., & Kritikos, K. (2018, December). Towards
distributed sla management with smart contracts and blockchain. In 2018
IEEE International Conference on Cloud Computing Technology and
Science (CloudCom) (pp. 266-271). IEEE.
[7] Scheid, E. J., Rodrigues, B. B., Granville, L. Z., & Stiller, B. (2019,
April). Enabling dynamic SLA compensation using blockchain-based
smart contracts. In 2019 IFIP/IEEE Symposium on Integrated Network
and Service Management (IM) (pp. 53-61). IEEE.
[8] Alzubaidi, A., Mitra, K., Patel, P., & Solaiman, E. (2020, August). A
blockchain-based approach for assessing compliance with sla-guaranteed
iot services. In 2020 IEEE International Conference on Smart Internet
of Things (SmartIoT) (pp. 213-220). IEEE.
[9] de Brito Gonc¸alves, J. P., Gomes, R. L., da Silva Villaca, R., Municio, E.,
& Marquez-Barja, J. (2020, November). A quality of service compliance
system empowered by smart contracts and oracles. In 2020 IEEE
International Conference on Blockchain (Blockchain) (pp. 532-538).
IEEE.
[10] Zhou, H., Ouyang, X., Ren, Z., Su, J., de Laat, C., & Zhao, Z.
(2019, April). A blockchain based witness model for trustworthy cloud
service level agreement enforcement. In IEEE INFOCOM 2019-IEEE
conference on computer Communications (pp. 1567-1575). IEEE.
[11] Scheid, E. J., & Stiller, B. (2018). Automatic sla compensation based
on smart contracts. University of Zurich, Department of Informatics,
Switzerland, 4.
[12] Kochovski, P., Stankovski, V., Gec, S., Faticanti, F., Savi, M., Siracusa,
D., & Kum, S. (2020). Smart contracts for service-level agreements in
edge-to-cloud computing. Journal of Grid Computing, 18, 673-690.
[13] Abhishek, P., Chobari, A., & Narayan, D.G. (2021). SLA Viola-
tion Detection in Multi-Cloud Environment using Hyperledger Fabric
Blockchain. 2021 IEEE International Conference on Distributed Com-
puting, VLSI, Electrical Circuits and Robotics (DISCOVER), 107-112.
[14] Khan, K. M., Arshad, J., Iqbal, W., Abdullah, S.,& Zaib, H. (2022).
Blockchain-enabled real-time SLA monitoring for cloud-hosted services.
Cluster Computing, 1-23.
[15] Battula, S. K., Garg, S., Naha, R., Amin, M. B., Kang, B., & Aghasian,
E. (2022). A blockchain-based framework for automatic SLA manage-
ment in fog computing environments. The Journal of Supercomputing,
78(15), 16647-16677.
[16] Javed, F.,& Mangues-Bafalluy, J. (2022, November). Blockchain-based
SLA Management for Inter-Provider Agreements. In 2022 IEEE Con-
ference on Network Function Virtualization and Software Defined Net-
works (NFV-SDN) (pp. 155-161). IEEE.
[17] Weerasinghe, N., Mishra, R., Porambage, P., Liyanage, M., & Ylianttila,
M. (2023). Proof-of-Monitoring (PoM): A Novel Consensus Mechanism
for Blockchain-based Secure Service Level Agreement Management.
IEEE Transactions on Network and Service Management.
[18] Alzubaidi, A., Mitra, K., & Solaiman, E. (2023). A blockchain-based
SLA monitoring and compliance assessment for IoT ecosystems. Journal
of Cloud Computing, 12(1), 1-22.
[19] Javed, F., Mangues-Bafalluy, J., & Zeydan, E. (2023, May). Blockchain-
based SLA monitoring for 6G: Inter-Provider Agreements as a Use Case.
In 2023 IEEE International Conference on Blockchain and Cryptocur-
rency (ICBC) (pp. 1-3). IEEE.
[20] Neeraj, N. K., Nellikeri, A., Varun, P., Reddy, S., Shanbhag, M.,
Narayan, D., & Husain, A. (2023, April). Service Level Agree-
ment Violation Detection in Multi-cloud Environment using Ethereum
Blockchain. In 2023 International Conference on Networking and Com-
munications (ICNWC) (pp. 1-7). IEEE.