Content uploaded by Madhusanka Liyanage
Author content
All content in this area was uploaded by Madhusanka Liyanage on Dec 29, 2022
Content may be subject to copyright.
1
Proof-of-Monitoring (PoM): A Novel Consensus
Mechanism for Blockchain-based Secure Service
Level Agreement Management
Nisita Weerasinghe, Student Member, IEEE, Raaj Mishra Student Member, IEEE, Pawani Porambage Senior
Member, IEEE, Madhusanka Liyanage, Senior Member, IEEE, and Mika Ylianttila, Senior Member, IEEE
Abstract—In the current 5th Generation (5G) networking
paradigm, the enforcement of Service Level Agreements (SLAs)
is a non-trivial measure to assure the scope and the quality of ser-
vices and standards between tenants and service providers (SPs).
On top of this, Secure Service Level Agreements (SSLA) are
introduced to ensure whether SPs deliver the most critical and
required security-related standards defined in the contract, such
as integrity, confidentiality, availability, non-repudiation, and
privacy assurance. However, with the tendency for more dis-
tributed and multi-stakeholder networking architectures in next-
generation networks, the management process of such SSLAs will
be challenging due to the diversified security vulnerabilities and
complexity of underlying technologies. Although blockchain is
emerging as a platform to facilitate such distributed SSLA/SLA
management frameworks, its currently available consensus mech-
anisms are more generic and still exhibit some shortcomings
in terms of applying in multi-stakeholder networks. Therefore,
in this paper, we present a novel consensus mechanism called
Proof-of-Monitoring (PoM) for a blockchain-based novel SSLA
management framework. Moreover, we provide details about
the prototype implementation of our proposed consensus algo-
rithm and SSLA management framework. It is proven by the
comparison of our proposal with the other existing solutions
that our solution outperforms in many aspects such as energy
consumption, computation cost, and security features.
Index Terms—Blockchain, Secure Service Level Agreements,
Consensus Algorithm, Network monitoring, Smart Contracts
I. INTRODUCTION
A service Level Agreement (SLA) is a contractual finan-
cial agreement between a service provider and a customer.
In the telecommunication context, it defines as a form of
assurance that the Communication Service Providers (CSPs)
deliver the diversified communication service requirements
of Communication Service Customer (CSC), aligning with
service compliance standards (3GPP TS 28.530). Hence, it is
of utmost importance to any CSC. SLA violations potentially
degrade the quality of the expected service where the user
has to encounter unexpected experiences and consequences
Nisita Weerasinghe and Mika Ylianttila are with the Centre for
Wireless Communications, University of Oulu, Finland. e-mail: first-
name.lastname@oulu.fi
Raaj Mishra is with the Dell Technologies, India. e-mail:
raaj2045@gmail.com
Pawani Porambage is with VTT Technical Research Centre, Finland. e-mail:
pawani.porambage@vtt.fi
Madhusanka Liyanage is with the School of Computer Science, University
College Dublin (UCD), Ireland and the Centre for Wireless Communi-
cations, University of Oulu, Finland. e-mail:madhusanka@ucd.ie, madhu-
sanka.liyanage@oulu.fi
for the paid services, which eventually may negatively impact
the user experience. Traditionally, end customers must follow
manual and time-consuming procedures to prove the evidence
of these SLA violations. Hence, a fully automated SLA system
is required to support continuous monitoring and boost the
user satisfaction level. Additionally, a trustworthy guaranteeing
platform must monitor service deliveries and maintain fairness
between customer and SP. Furthermore, SLA includes mea-
surable metrics to ensure Quality of Service (QoS) [1], while
there is an urge for security assurance of the service delivery.
Hence, researchers are working on the upcoming concept
known as Secure Service Level Agreements (SSLAs). SSLA
specifies the security-oriented requirements required to assure
the expected level of security. Essentially, the security features
such as confidentiality in different dimensions, the integrity of
transaction records, and availability of the persistent services
are a few of the critical security requirements anticipated in
the SSLAs [2].
The limitations encountered in most of the state-of-art
solutions systems [3], [4] are SSLA monitoring party functions
as a centralized entity, which inherits default challenges such
as single point of failures and is prone to network attacks
(e.g., Distributed Denial of Service (DDoS)). Still, there are
not many research that has been carried out in the area of
SSLA. However, more research work has been done in the
area of SLA. Therefore, we examined SLA-based state-of-art
solutions.
To address the limitations encountered in conventional SLA
systems, one of the vital approaches commonly researched is
the adaptation of blockchain technology. It can be incorporated
to automate monitoring and improve trust across every 5G
service delivery. Blockchain has the ability to convert the
architecture from a centralized to a decentralized one and
to execute manual agreements via smart contracts. Every
transaction is recorded in the distributed ledger to ensure
non-repudiation [5]. Furthermore, miners process transaction
validation to guarantee immutability within blockchain records
and restrict non-authorized parties from tampering with the
data within the blockchain [6]. Therefore, we propose to
incorporate blockchain technology into our research.
However, state-of-the-art blockchain-based solutions [7], [8]
still have challenges such as high blockchain operational costs
and energy data silos. For the deployment of blockchain,
the tenant nodes should have the capability to perform ex-
tensive computations to reach a consensus result. However,
2
many resource-constrained devices will struggle to achieve
that, making it impossible to adopt blockchain technology
by such devices. Massive amounts of energy and time will
be wasted where comparable results can be obtained with
simpler consensus algorithms. In addition to that, the existing
consensus algorithms focus on achieving consensus as an
independent task, which is completely irrelevant to the ser-
vices obtained from the blockchain. Therefore, a customized
consensus protocol is advantageous for efficient blockchain
integration. Therefore still room is available to leverage the
concept and develop a blockchain-based system. In our pro-
posal, both the limitations of non-blockchain and blockchain-
based SLAs/SSLAs are expected to be rectified.
In particular, the key contributions of our work are as
follows:
•Propose blockchain-based SSLA management framework
•Propose novel cost and energy efficient consensus mech-
anism, called Proof-of-Monitoring (PoM), which is cus-
tomized for SSLA management applications
•Evaluate the performance of the proposed system in a
simulated environment and confirm the viability through
a prototype implementation
•Evaluate the correctness of the proposed consensus pro-
tocol by performing formal modeling and formal verifi-
cation
The rest of the paper outlines as follows: Section II provides
background knowledge on SLA/SSLA and different tech-
nologies used. III examines existing works while Section IV
introduces novel blockchain-based SSLA architecture. Section
V proposes novel consensus algorithm. Section VI carries
out numerical simulations to evaluate the performance of the
proposed consensus protocol and to compare it with existing
systems. Section VII presents the prototypical implementation
of the proposed consensus algorithm and SSLA management
system. Section VIII discusses the experimental results. Sec-
tion X compares the proposed model with existing systems and
discusses the limitations of the proposed approach. Section IX
defines the formal model of the proposed consensus protocol,
verify its properties and analyse its results. Finally, Section XI
concludes the paper.
II. BACKGROU ND
This section discusses the core concepts of SLA/SSLA,
the challenges of both blockchain and non-blockchain-based
SSLAs, and the related technologies used throughout our
study.
A. Fundamentals of SLA/SSLA
SLA is a legal agreement containing negotiated services
between consumers and service providers. Services define
based on multiple Service Level Objectives (SLOs). SLOs
represent quantifiable metrics with values. The primary expec-
tation of establishing a SLA is to ensure the defined SLOs are
met. Furthermore, SLA focuses more on leveraging the QoS
while SSLA concentrates on improving the expected level of
security.
The life cycle of the SLA [9] is generally divided into five
phases as follows: (1) Identification of capacities of SP and
definition of requirements of customer (2) SLA negotiation
between customers and SP (3) Resource provision and service
activation (4) SLA monitoring, validating, reporting and vio-
lation detecting (5) SLA assessment with SP(service quality,
key issues) and customer (service experience and management
of requirements). Our target is to advance the fourth phase of
the SLA’s lifecycle.
An example of a security SLO is the Packet Loss Ratio
(PLR), which is defined as the ratio of the number of data
packets lost to the total number of packets that a network
node should have forwarded. Packet losses could usually occur
due to channel errors or network congestion. This metric is
typically associated with QoS considerations, and the amount
of tolerable packet losses (e.g., 1% or 5%-10%) depends on
the type of data being sent. In the context of network security,
packet-dropping or blackhole is a type of denial-of-service
(DoS) attack where a network node drops packets that it should
not have. A DoS attack can happen at different layers, e.g.,
application layer or network layer. If a node is repeatedly
dropping packets, that indicates potential malicious behavior,
leading to communication unavailabilities for benign users.
Furthermore, the lower the PLR, the higher the reliability and
availability of the service against security threats.
B. Potential challenges of SLA/SSLA management systems
The most significant probable challenges related to
SLA/SSLA management are described below.
1) Single Point of Failure: The current systems are primar-
ily aligned with centralized deployment architecture, which
causes several limitations. For instance, being vulnerable to
DDoS attacks, which makes the service unavailable by at-
tacking the centralized services [10]. In addition, centralized
storage such as classical database systems can expose data to
malicious parties.
2) Transparency: There is a potential for resource providers
to violate pre-established SSLAs and raise discrepancies [11].
Hence, the lack of transparency in the current system makes
traceability harder. These problems make the service delivery
unsatisfactory to the customer, resulting in losses to the
service providers. Furthermore, the dispute resolution process
becomes exhaustive and will incur overheads for all parties.
3) Scalability: The number of tenants and operators con-
nected to the industrial ecosystems will expand with the com-
plexity of future telecommunication applications. Especially
the future industrial integration of IoT generates massive
demand for 5G service delivery with diversification [12].
Handling the exponential load is challenging with the state-
of-the-art centralized architecture in future scenarios.
4) Lack of Reliable Monitoring Data: Due to obvious
reasons, we cannot always be certain that a third-party moni-
toring solution always provides reliable data. Some reasons
are their tendency to suffer from a single point of failure
and the possibility to be compromised easily because of being
centralized.
3
5) No Automated Violation Detection: Traditional methods
do not support automated SSLA violation detection and com-
pensation methods. Customers must follow a manual and time-
consuming verification and resolution process to claim for a
violation (e.g., via e-mails).
C. Potential challenges of blockchain-based SLA/SSLA man-
agement systems
Existing blockchain-based SLA/SSLA suffers from high
latency, high cost, high computational overhead, and resource
wastage. Extra delays are caused by time consuming execution
of the mining process (e.g., Proof of Work (PoW)). Unneces-
sarily expensive for some, because of favoring the wealthier
participants (e.g., Proof of Stake(POS)). Excessive compu-
tational overhead, high energy consumption, and resource
wastage because miners have to perform a computationally
intensive mining task (e.g., PoW). Miners are required to
put a lot of effort into non-value-added tasks such as hash
calculation (e.g., PoW) or stake management (e.g., PoS).
Hence, it is evident that these consensus protocols suffer from
different challenges. Furthermore, although the adaptation of
private blockchain networks might favor in addressing these
issues, it is more centralized than public networks.
In a nutshell, the main task of the SLA/SSLA management
application is to ensure that obliged service standards are met
by the SP. To monitor whether the expected standards are met,
a fair, trustworthy and automated platform is required. For this,
numerous blockchain solutions are introduced already. But still
energy efficient and fully decentralized blockchain solutions
are yet to be introduced.
Hence, it is optimal to design a consensus protocol with
a mining task that complements its application’s primary
function to avoid aforementioned issues. As a result, the
energy and resources are not wasted for non-value-adding
tasks. Instead, they are utilized for the core service of the
application.
D. Pervasive Authentication Protocol and Key Establishment
(PAuthKey) scheme
PAuthkey protocol is a lightweight authentication, and key
Establishment mechanism proposed for resource-constrained
WSNs in IoT applications [13]. It mainly comprises two
phases: registration and authentication phase. In the registra-
tion phase, the sensor node must acquire a certificate from its
cluster head which they assume to be the Certificate Authority
(CA). Initially the sensor node generates a random number
ruϵ[1, ..., n −1] to compute Elliptic Curve (EC) point Ruas
given in equation 1 and send the value to CA along with
certificate request.
Ru=ruG(1)
Note that the EC domain parameters defined in this paper
follow the standard elliptic curve equation over the finite field
Fqis y2=x3+ax +b, where 4a3+ 27b2= 0, variables a
and bare coefficients, Gis the generator point, and integer n
is the order of the curve.
Upon receiving the certificate request. CA generate random
number rCAϵ[1, ..., n −1] and calculates implicit certificate
Certu, e, s respectively as follows, Let dCA be the private key
of CA.
Certu=Ru+rCAG(2)
e=H(Certu)(3)
s=erCA +dCA(modn)(4)
CA responds to the node by sending a message including
Certuand s. Then, the node is able to generate eusing the
equation and the same hashing function that CA has used.
Thereafter, the node has the capability to calculate its private
key duand public key Quas follows.
du=eru+s(modn)(5)
Qu=duG(6)
Further, [13] proves that Qucan also be calculated using
the below equation.
Qu=eCertu+QCA (7)
E. Shamir’s Secret Sharing (SSS) scheme
For the purpose of developing a novel consensus algorithm,
we intend to use the key sharing scheme proposed by Shamir
[14]. It is a process in which a secret key (S) is split into
n parts, known as shares. The combination of these shares
re-creates the original key. The minimum number of shares
required to restore the key is known as threshold k. Therefore,
SSS is defined as a (k, n)threshold scheme. This technique is
ideal in a trustless environment such as a blockchain where the
key can be distributed over many nodes. SSS is built based on
polynomial interpolation. Note that, Size of finite field pϵP:
p>S, such that ai< p ,a0=Swhere we select k−1
random elements, a1, ...ak-1 from a finite field of size p. The
polynomial is constructed as follows,
f(x) = a0+a1x+a2x2+.... +ak-1xk-1 (8)
Generate n points (i, f (i)) where i= 1, ...n, from f(x)
and distribute these points among nodes. A node who has
captured kof these points are able to rebuild the f(x). In our
scenario, we are focused only in finding the S which can be
identified as a0in the f(x). Hence, reconstruction of entire
polynomial is unnecessary to calculate a0. It can be generated
using following formula.
f(0) =
k−1
X
j=0
yj
k−1
Y
m=0,m=j
xm
xm−xj
(9)
4
III. REL ATED WO RK S
Up to date, various approaches are evolving to investigate
across different avenues to cater diversified requirements of the
SLA context at present. Out of the phases of the SLA lifecycle,
researchers have been most focused on the monitoring phase,
then the negotiation phase, and least concentrated on violation
management and reporting [15]. Philipp et al. [16] proposes
a SLA model to support negotiation phase by permitting
dynamic changes to multiple service levels during deployment
phase of an SLA. Sanjay et al. [17] proposes a trust model for
SLA monitoring to support the assessment phase. Eduardo et
al. [4] introduce an architecture comprising multiple software
agents to identify SLA breaches and a third-party auditor to
avoid conflict of interest between SP, contractor, and client.
The proposed approach permits gathering SLA metrics from
each stakeholder and analyzing the deviations and demand for
solutions. However, this proposal lacks transparency by relying
on external services from third parties.
Hiroki et al. [7] proposes a blockchain-based platform to
automate SLA contract enforcement.However, a system to
analyze the credibility of SLA breaches is absent. Ke et al.
[18] proposes a blockchain-based auditing scheme to preserve
the privacy of SLA of network slicing and execution of pun-
ishments based on auditing results. Rohit et al. [19] introduces
a blockchain-based approach to detect SLA breaches and
analyze its root causes in a multi-cloud ecosystem. Another
interesting piece of work has been done by Huan et al. [8] with
the introduction of a decentralized witness model to detect
SLA violations. Nevertheless, all these proposed solutions
expend high costs and computational overheads for mining
tasks which need to be minimized. This is due to the fact
that most of these state-of-art SLA blockchain-based solutions
suffer from lack of an application specific consensus.
Alemany et al. [3] presents a security SLA manager to
guarantee the security of end-to-end network slices. Its core
component is the SSLA Manager, which functions as a cen-
tralized entity. It tends to be compromised easily, leading to
the single point of failure, service unavailability. In addition
to that, it cannot guarantee the transparency of the service
delivery. However, this is the only state-of-art that has made
a significant contribution to the development of a Security
based SLA framework. Nevertheless, there are significant
modifications required to improve the entire system.
There are few works has been carried out to ensure correct-
ness of novel consensus protocols. For instance, Hamra et al.
[20], Wai Yan Maung Maung et al. [21] present formal models
built using CSP#and verified using PAT model checker.
While our formal model has been inspired by them, the
proposed consensus protocol is fundamentally different from
theirs.
Therefore, it can be concluded that there is a demand
for a proper blockchain-based SSLA management system
and, to complement that, a custom-built application-specific
consensus algorithm.
IV. PROPOSED BLOCKCHAIN-BAS ED SSLA
MANAGEMENT FRAMEWORK
The main objective of our proposal is to invent and execute
a zero-touch security-oriented SLA framework that guaran-
tees trustworthiness, accountability, and security in delivering
communication services at low cost and low energy. To devise
a sustainable security approach, we will require real-time
network data from trustworthy and authentic sources. For
that, our system uses a decentralized blockchain network
architecture where nodes can voluntarily deploy their network
sensors in the wireless channel that the client and SP com-
municate. Then blockchain nodes can capture the data and
feed it to the blockchain service layer. Our system introduces
a mechanism for blockchain nodes to earn revenue for their
resource investment and network monitoring. Further, our
approach proposes a method to maximize the profits of nodes
which provide correct data continuously and, at the same time,
reduce the dependency on nodes who report false information.
Moreover, the occurrence of a violation is considered based
on the majority vote of the monitoring nodes. Accordingly,
the trustworthiness and reliability of the monitoring data is
guaranteed. However, to achieve the vision of empowering
an economic model with less computational overhead, our
framework proposes a use case-oriented consensus algorithm
where the blockchain nodes do not have to perform extra work
to participate in the consensus. The high-level architecture of
the proposed blockchain-based SSLA management framework
integrated with a novel consensus algorithm is in the Fig.1
The performance features of the SP monitored and evaluated
precisely with the feedback from the deployed nodes in
the 5G core networks. Furthermore, the consumer end has
been enabled to report the performance feedbacks and the
service level compliance through the blockchain network. The
alignment of performance with the SSLA has been logged
in the blockchain to ensure non-repudiation. Then no party
could upload false data or tampered the data within blockchain
network.
The blockchain integration ideally facilitates the dynamic
and adaptable enforcement of service agreements through
smart contracts. The decentralized and dynamic nature of
smart contracts enforce dynamic deployment of contractual
agreements across the ecosystem. Essentially, blockchain is
decentralized and ensures the decentralized service opera-
tion with distributing the load between multiple collaborative
nodes. Therefore, it caters the diverse service requirements of
stakeholders with less delay.
Transparency of agreements is enabled by encoding SSLAs
in smart contracts. The transparency of smart contracts ensure
the terms and conditions of the contract are clear and under-
standable as well as not deviated from the pre-agreed terms
and conditions. Therefore, non-repudiation is guaranteed.
The decentralized ledger of blockchain incorporated with
interlinked cryptographic verification, avoids the possibility for
a data in the database to be tampered. Furthermore, it ensures
the execution of sequential events in the SSLA are compliant
and in order. Moreover, with the decentralized operational
capability of blockchain, eliminates the single point of failure
5
Fig. 1: High-level architecture of the proposed blockchain-based SSLA management framework
and tolerates the scaled up transaction volumes.
A. Key components of the proposed framework
We determined the main functional modules of the SSLA
framework and their primary services. Fig. 2 represents key
service modules of the proposed SSLA management frame-
work and its interaction with the stakeholders. The stake-
holders (client, SP) and monitoring nodes invoke back-end
(blockchain) services through an API. The primary services
of each functional module are discussed below.
Fig. 2: Key services of the proposed blockchain-based SSLA
management framework
User Authentication:This service is responsible for man-
aging accounts and keeping track of records of SPs, customers,
and monitoring nodes. Stakeholders register to the proposed
platform to become accountable for receiving services. Like-
wise, the monitoring nodes must register to the system before
initiating the network monitoring. Initially, participants enter
their credentials through the web application. The API passes
the data to the blockchain and invokes the User Authentication
service. It stores the credentials in the distributed ledger and
links the wallets of each user to their accounts. Furthermore,
this service module invokes whenever a registered stakeholder
requires to log into the system, and it will grant access per-
mission by retrieving the user information from the distributed
ledger.
Policy Manager:The client can select a SP from our
web application and send its desired security requirements to
the selected SP. Then, the SP generates a SSLA draft and
sends it to the client.The client has the chance to moderate
selected requirements and request reviews from the SP during
the negotiation period. SP can review and revise the SSLA.
This process will run recursively until the client is satisfied.
The client can approve the agreement by sending the service
charge to the blockchain. Then, the blockchain generates an
event to notify SP and invokes the Policy Manager service
module. Policy Manager translates high-level metrics into
measurable metrics. For example, if the high-level metric
is PLR, then translated measurable metrics are the number
of packets tranmitted and dropped over a period. It stores
measurable metrics along with other SSLA parameters in the
blockchain and sends a SSLA deployed notification to the
Lifecycle Manager. Moreover, it transfers the service charge
to the Compensation Calculator, where the fee will be held
6
until the SSLA termination stage.
SSLA agreement includes the following negotiated parame-
ters such as the address of SP, address of the customer, service
fee, validity period, monitoring period (= Period at which the
monitoring node reports monitored data to the blockchain),
SLO metrics, SLO values, allowable violation count per SLOs,
priority weightage of SLOs, blockchain fee weightage. Note
that the priority weightage is a percentage which can be set to
adjust the priority levels among SLOs of SSLA, and it depends
on the criticality level of the security metric in question.
The blockchain fee weightage is a percentage fee which is
distributed among blockchain nodes who correctly monitor the
network (e.g., 0.1 %).
Lifecycle Manager:This functional module handles both
SSLA initiation and termination processers. It always refers to
the contract period of the stored SSLAs. Whenever the starting
period of any SSLA reaches, the Lifecycle Manager invokes
Violation Monitoring Engine. When the contract period ex-
pires or discovers a SSLA policy infringement, the contract
termination triggers. In addition to that, it is responsible for
notifying the SSLA termination to Compensation Calculator
and Reputation Management modules.
Violation Monitoring Engine:The main task is to manage
network monitoring activities. Peer nodes in the blockchain
network monitor the packets transferring between each client
and service provider pair via the wireless communication
channel. Each node has the freedom to install a preferred
network sensor and monitor the measurable metrics of each
security metric in SSLAs, during the specified monitoring
period in SSLA. Next, they feed the monitored data to the
blockchain at the end of the monitoring period. Then, the
Violation Monitoring engine calculates the values for each
security metric of SSLAs and checks whether the SP meets the
SLOs. In our system, a violation is declared if more than 50%
of the active monitoring nodes input data, confirming a vio-
lation. Subsequently, the Violation Monitoring engine invokes
both Compensation Calculator and Reputation Management
modules. Additionally, It notifies the Lifecycle Manager to
terminate the SSLA when the number of violations conducted
by a specific SP exceeds a certain pre-defined threshold.
Compensation Calculator:This entity mainly performs
billing activities at the end of the monitoring period. It divides
the service fee among SP and blockchain nodes based on their
service delivery. Blockchain nodes refer to the winner miners
and violation reports (=blockchain nodes who have correctly
reported violations). A blockchain fee is a reward offered to
blockchain nodes for allocating their resources throughout the
monitoring period. Further, it calculates the losses incurred by
the user for service failures.
The client is liable to deposit the service fee at the estab-
lishment of SSLA. In the SSLA termination stage, percentages
of the service fee will be distributed among SP, winner miner,
and violation reports. Also, the customer will receive a portion
of it as compensation if and only if the violation count exceeds
the allowable number of violations.
Initially, a portion of the service fee is allocated to the
blockchain nodes at every Tmonitoring period, and the blockchain
fee Fblockchain can be calculated as follows. Let service fee be
Fservice and blockchain fee weightage be p.
Fblockchain =Fservice ×p×Tmonitoring
A certain amount of the blockchain fee collects as incentives
for winner miners. The rest divides among the violation reports
based on their reputation score. The one which has the highest
reputation score receives the highest revenue. Therefore, it is
evident that providing accurate data all the time will maximize
their profit.
Customer compensation relating to ith SLO, F(i)compensation
is calculated as follows, Let violation period relating to ith
SLO be Tviolation(i), priority weightage of SLO be qi, total
number of SLOs per SSLA be n.
Fcompensation(i)=(Fservice −Fblockchain)×Tviolation(i)
Tmonitoring
×q(i)
Note that Tviolation(i)is the total time within the monitoring
period during which a violation occurred corresponding to the
ith SLO.
The total compensation fee per monitoring period is com-
puted as below,
Fcompensation =
n
X
i=1
Fcompensation(i)
Subsequently, Fcompensation amount is transferred to the cus-
tomer’s wallet at the SSLA termination stage. The rest of the
funds is credited to SP, FSP
FSP = (Fservice −Fblockchain)−Fcompensation
Reputation Management:The primary function is to
compute rating scores for the blockchain nodes and SPs at
every monitoring period and agreement termination session,
respectively. The reputation score of each violation reporter
increments while the reputation scores of non-violation re-
porters decrements if the system confirms a violation. The
blockchain node is discarded from the network if its reputation
score exceeds a certain threshold. Furthermore, the updated
rating scores of every SP displays on the web application at
the stage where a customer is selecting a SP. Hence, it eases
the customer to choose an optimal SP.
B. Workflow of the proposed SSLA management process
The workflow presents a sequence of steps from the gen-
eration of a SSLA to the termination of a SSLA. Fig. 3, Fig.
4, Fig. 5 illustrates the flow of the initiation phase, monitor-
ing phase, and termination phase of the SSLA management
framework, respectively. The vital steps of the three phases
are explained below.
1) Initiation Phase: Initially, a client selects a SP based on
his/her needs and sends the security requirements to the SP.
SP is accountable for generating a SSLA draft considering
the user input. Then SP will send the created SSLA to the
customer for his/her approval. The customer has the privilege
to request modifications, and SP is obliged to review and revise
the defined terms in SSLA until he/she is fully satisfied. Hence,
7
the SSLA negotiation process follows a recursive process.
Once the client is pleased with a received SSLA version,
he/she can provide his/her consent by depositing the agreed
service charge defined in SSLA.
Fig. 3: SSLA initiation phase
2) Monitoring Phase: The Policy Manager converts the
SLOs into measurable metrics and stores them along with
other SSLA parameters in the blockchain. Then it sends
the SSLA deployment notification to the Lifecycle Manager.
When the starting period of the contract reaches, the Lifecycle
Manager triggers the SSLA initiation process by sending
a SSLA initiation notification to the Violation Monitoring
Engine. Then, Violation Monitoring Engine commences mon-
itoring the wireless channel, which the client and SP con-
nected, with respect to the measurable metrics. Subsequently,
it reports any infringements found to both Compensation Cal-
culator and Reputation management in every monitoring cycle.
Compensation Calculator module computes the compensation
for customer, penalty for SP and service fee blockchain
nodes. Reputation Management calculates reputation scores
for blockchain nodes. If the reputation score of a blockchain
node reaches a certain threshold, it will be eliminated from
the system.
3) Termination Phase: The termination phase mainly in-
cludes the termination of SSLA monitoring and settlement of
final payments.
SSLA termination happens if any of the following actions
are triggered, (1) the Lifecycle Manager receives the SSLA
termination request from the Violation Monitoring engine that
it has encountered that the SP has exceeded the maximum
allowable number of violations (2) the SSLA met the contract
expiration date. Subsequently, the Lifecycle Manager sends the
SSLA termination notification to Compensation Calculator and
Reputation Management modules. Compensation Calculator
transfers the service charges for both SP and blockchain nodes
if no violation has been detected. If not, it compensates
Fig. 4: SSLA monitoring Phase
the client by transferring the compensation fee (a portion
of the service charge). Finally, the Reputation Management
calculates and updates the reputation score of the SP based on
their violation status.
Fig. 5: SSLA termination phase
V. PROPOSED PRO OF -OF -MONITORING CONSENSUS
ALGORITHM
This section proposes a novel consensus algorithm named
Proof-of-Monitoring, which is customized to the SSLA man-
agement application. Its principal concept and the key phases
are explained explicitly in this section.
A. Principal concept
The consensus protocols of state-of-art blockchain solutions
pose intensive computational demands which require a large
amount of energy for each miner to maximize their chances
8
of becoming a winning miner. Hence, our system proposes
an innovative approach to remove this unnecessary overhead
from the system by designing a novel consensus specific to the
SSLA management system. The idea is to make the mining
task to be the same as the main work of the SSLA management
application, which is network monitoring.
The novel consensus algorithm is proposed utilizing both
PAuthkey protocol [13] and Shamir’s Secret Sharing scheme
[14] technologies. The main phases of the proposed approach
are depicted in Fig. 6 and explained explicitly with their
corresponding pseudo-codes.
B. Key phases of the PoM mechanism
1) Key Generation: For the development of the consensus
algorithm, we incorporate the basic operations introduced
for the authentication, and key establishment phases of the
Wireless Sensor Networks (WSNs) in the PAuthKey protocol
[13]. We program its computations in a black box of the miner
software without exposing them to any blockchain nodes.
The internal calculations include the generation of Elliptic
Curve (EC) Rupoint, implicit certificate Certuand the private
key du. The algorithm 1 shows the mathematical operations
performed to generate them. Note that EC domain parameters
such as generator point G, Private and Public key of certificate
authority dCA,QCA , Curve order nare predefined.
Algorithm 1 Key and Certificate Generation
Input: Generator point (G), Private and Public key of
certificate authority (dCA, QCA ), Curve order (n)
Output: Private key (du), Implicit certificate (Certu)
1: ru:= a random number between 1and n−1
2: Compute EC point Ru=ruG
3: rCA := a random number between 1and n−1
4: Generate Certu=Ru+rCAG
5: Integer e←Hash of Certu
6: Integer s=erCA +dCA(modn)
7: Generate du=eru+s(modn)
2) Key Distribution: The previously computed duand
Certuusing the PAuthKey protocol are concatenated. Let’s
called the combination of duand Certuas Secret(S).S
is divided into nshares using the Shamir Secret Sharing
approach. Next, the mining application reveals random key
shares to each node, and then nodes can broadcast the received
share to the wireless channel that SP and client connected, via
a known port that they have already declared when joining
the network. Note that the system shares the public key QCA
with all the blockchain nodes, which will be necessary for the
later calculations in the block generation phase. Algorithm
illustrates the pseudo-code related to the key distribution
phase.
3) Network Monitoring and Key Recovery: The designated
task for the miners is to calculate public key Quby recov-
ering duand Certu. To accomplish the task, nodes have to
attentively listen to the service ports, capture each key share,
and reconstruct the desired parameters. The system rewards the
one who completes the task with incentives, which encourages
Algorithm 2 Key Distribution
Input: Private key (du), Implicit certificate (Certu),Num-
ber of active nodes (m), Number of shares (n), Threshold (k)
Output: npieces of (du),npieces of (Certu)
1: S={du,Certu}
Require: Size of finite field pϵP:p > S, such that ai< p ,
a0=Swhere
2: Sample k−1random numbers {a1, a2...., a(k-1) }from a
finite field of size p
Require: n≥3
Ensure: n= 2k−1
3: for i= 1 to k−1do
4: ai
5: end for
6: Generate the polynomial f(x) = a0+a1x+a2x2+.... +
a(k-1)x(k-1)
7: Generate n points from f(x)and store in an array
{D0, D1...., D(n-1) }
8: for j= 1 to ndo
9: Dj-1 ←((j, f (j))modp)
10: Array Y[j]←Dj-1
11: end for
12: Generate a portion of Sin each active node
13: for q= 1 to mdo
14: rq←a random number between 1and n
15: Reveal n point Y[rq]
16: end for
17: Each active node broadcast the received portion of Sto
all other active nodes
18: Reveal G,QCA ▷Required for later computations
the blockchain nodes to find the solution by investing their
resources to the maximum. Miners can recover the key by
capturing its shares while monitoring the network for SSLA
violations. Algorithm 3 shows the pseudo-code related to the
key recovery stage.
Blockchain nodes can store the network monitoring data
locally in off-chain storage (InterPlanetary File System (IPFS)
and sends the pointer (the hash of the monitored data) to
the blockchain. When necessary, these data can be accessed
later at the blockchain by retrieving the data from the off-
chain database. This approach prevents the unnecessary ledger
growth [22].
4) Block Generation: Our consensus protocol declares the
node who discovers Qu,Certuand dufirst, as the winner
miner. The winner miner gets the chance to create the next
block of the blockchain. Fig. 7 depicts the block structure
that the winner miner has to create. Block header includes
the version, timestamp, hash of the previous block, hash of
the Merkle root, RESULT is the solution discovered from the
mining process. RESULT = ( Qudigitally signed by du) +
signature + Certu. The body of the block header contains
the data pointer to the network monitoring data, blockchain
service invocations, service fee payments. Later, the winner
miner broadcasts the generated block to the peer nodes for
verification.
9
Fig. 6: The workflow of the proposed PoM consensus protocol
Algorithm 3 Key Recovery
Input: kpieces of S{(x0, y0),(x1, y1)...., (xk, y k)}
Output: Recovered du,Certu, Computed Qu
Require: l= 1, f(0)
1: for j= 0 to k−1do
2: for m= 0 to k−1do
3: if m=jthen
4: l←l∗(xm)/(xm−xj)
5: end if
6: end for
7: f(0) ←f(0) + (l∗yk)
8: p= 1
9: end for
10: f(0) ←S={du,Certu}
11: Compute public key using du,Certu
12: Qu=duG
13: or Qu=e∗Certu+QCA
5) Block Verification: When the rest of the miners receive
the new block, they can find the RESULT solution containing
a digitally signed Qu, the signature, and Certuin it. Next, they
calculate the public key Quusing Certuto verify the signature
sent by the winner miner. If the verification is successful,
Fig. 7: Block structure of the proposed PoM
the verified block will be added to the blockchain, and the
winner miner will be rewarded with incentives. The funds
10
for the incentives are collected from the service charge itself
(refer IV-A). Algorithm 4 shows the pseudo-code of the key
verification approach.
Algorithm 4 Block Verification
Input: Digitally signed Qu, signature, Certu
Output: successful or unsuccessful
1: Calculate Quusing Certu
2: Qu=e∗Certu+QCA
3: ECDSA signature verification
4: Qu’←decoded message using Qu
5: if Qu’== Quthen
6: Verification is successful
7: else
8: Verification is unsuccessful
9: end if
In conclusion, our consensus protocol is a cost-effective
and energy-efficient approach since it does not includes a
computationally intensive task to solve to achieve consensus.
C. Mining difficulty of the PoM mechanism
Every work-based consensus algorithm consists of a mech-
anism to adjust the difficulty levels of its defined mining
task, allowing control of block creation time, transaction
throughput, and competition between miners. In our case, the
difficult aspect is mainly regulated based on cryptography,
blockchain, and network parameters. Table I lists an estimation
of how different factors affect the difficulty of the mining task.
TABLE I: Analysis of mining difficulty of the proposed PoM
Category Parameter Impact on
difficulty
Cryptography
Key length of EC key/certificate
•Depends curve size
–Order of curve(n’)
∗Curve co-factor (h)
∗Order of subgroup
(r)
–Finite field Fq (where q
is prime)
–Field size
Increase
Threshold (k) Increase
Number of shares (n) Decrease
Key sharing frequency Decrease
Number of miners (m) Decrease
Key revealing probability Decrease
Mining resources Computational power Negligibly
decrease
Network Network latency Increase
Network bandwidth Decrease
The difficulty of recovering the key depends mainly on the
key size, number of shares, threshold, key sharing frequency,
and number of nodes. Obviously, with the increase in key
size, the number of key shares to be captured increases.
Similarly, setting the threshold to a higher value still increases
the number of key shares a miner node has to capture to
reconstruct the key. However, more key shares will be available
in the network to recover by increasing the number of shares
(which determines the number that the key is divided into)
while keeping the key size and threshold fixed. Therefore,
the availability of many shares in the network lowers the
recovery difficulty, while key size and threshold increase the
difficulty. In addition, with a lower key sharing frequency
(the duration a blockchain node must wait to send its next
key share), the completion of mining task will be delayed.
Hence, the difficulty will be increased with the key sharing
frequency. Nevertheless, having a greater number of miner
nodes (=key distributors) grows the number of key shares in
the network, increasing the key recovery probability. Similarly,
by increasing the key revealing probability (willingness to
broadcast its own key share to other peer nodes), the difficulty
will be reduced. This fact is elaborated quantitatively in a later
section VI-C. Furthermore, the time taken to solve the mining
task will be minimal when the computational power of a miner
node increases. However, the effect of computational power
is negligible on the difficulty since the mining task is not
computationally intensive. Moreover, the increase in network
latency and decrease in network bandwidth interrupt and delay
the process of miners distributing their own keys and capturing
keys to become winner miners. As a result, the entire mining
task operation will get delayed. Therefore, high latency and
low bandwidth affect the difficulty aspect negatively.
VI. NUMERICAL ANA LYSIS
We carried out multiple numerical simulations to evaluate
the performance of the proposed consensus PoM. This section
discusses the simulation models developed to assess the inter-
nal performance factors of PoM and compare PoM with other
traditional consensus protocols. The simulation tool used for
all the tests discussed in this section is MATLAB [23].
Simulation model 1 represents a wireless blockchain net-
work with Nnumber of nodes. We evaluated the blockchain
performance metrics by varying Nfrom 1 to 1000. Simulation
model 2 illustrates an estimation of energy consumption for
different blockchain architectures. Simulation model 3 exem-
plifies a blockchain network connected with mnumber of
miner nodes at the key distribution phase of the PoM, where
miner nodes broadcast and capture key shares. We instantiate
different instances of this model when m= 4,10,20, and 50. It
analyzes key recovering probability by varying key revealing
probability from 0 to 1.
A. Simulation Model 1: Inter-parameter comparison between
PoM and other conventional consensus mechanisms [24]
This subsection presents a quantitative analysis of the
communication impacts on blockchain performance metrics
in a wireless blockchain ecosystem. We have compared our
proposed PoM consensus protocol with widely used consensus
algorithms in a SLA/SSLA ecosystem. Namely, PoW [25],
[26], [8], Raft [27], [28] and PBFT [29]. The comparison was
made with respect to several significant performance metrics
such as communication complexity [24], spectrum requirement
[24], security bound [24], and transaction throughput [24].
11
0 100 200 300 400 500 600 700 800 900 1000
Number of nodes N
100
101
102
103
104
105
106
107
Communication complexity
PBFT
Raft
PoW
PoM
Fig. 8: Comparison of the communication complexity of
different consensus mechanisms [24]
1) Communication Complexity: Communication complex-
ity defines the number of communications available between
transmitter and receiver [24]. Fig.8 exemplifies the commu-
nication complexity of commonly used consensus protocols
in a wireless network. It is clearly visible that PBFT re-
quires the highest degree of communication 2N+N2. It
is because all connected nodes must communicate among
others at their primary stages of prepare, prepare and commit.
On the other hand, Raft and PoW depict the same pattern
of requiring up to 2Ncommunications. In Raft, the com-
munication complexity is the summation of communications
happening between followers to the leader (uplink) and leader
to followers (downlink), which adds up to 2N. However, in
PoW and PoM, 2Nnumber of communications are required
in the process of broadcasting the client-transaction request
and winner miner’s solution to all other connected nodes. In
addition, PoM requires communications at the stage where
each node (i.e., N) broadcasts its key shares among peer
nodes. Hence, at that point, N2number of communications
are required. However, key re-transmission triggers if no
winner miners are found at a defined interval. Therefore, the
communication complexity of PoM is rN2+ 2N, where ris
the number of re-transmissions. However, at the ideal stage,
r= 1, which makes the communication complexity of PoM
equal to N2+ 2N. Note that ideal stages of each consensus
protocol have been considered throughout this comparison [24]
2) Spectrum Requirement: Required number of communi-
cation spectrum resources or the number of transmitter pro-
cesses in wireless blockchain network refers to the spectrum
requirement [24]. A comparison is made among consensus
algorithms with respect to this regard and demonstrated its
results in the Fig.9. PoW model requires two broadcast com-
munications to transmit the transaction request and the winner
miner’s result. Hence, the overall spectrum requirement of
PoW is only 2, which is a constant value and does not depend
on the number of nodes. Similarly, PoM protocol includes the
transaction broadcasting and broadcasting the winner node’s
result to all peer nodes at the verification stage (i.e., 2).
In addition, each node transmits its own key shares among
other nodes (i.e., N). Hence, the spectrum requirement of
PoM is N+ 2. Raft model requires broadcasting transmission
in downlink (i.e., 1), and each follower node conducts a
one-way communication to the leader (i.e., N). Therefore,
the spectrum requirement of Raft is equal to N+ 1. In
PBFT, spectrum resources are allocated for the purpose of
broadcasting transactions at pre-pare stage (i.e., 1) and for the
communication between nodes at prepare and commit stages
(i.e., 2N). Hence, the spectrum requirement of PBFT sums up
to 2N+ 1, which is the highest of all.
0 100 200 300 400 500 600 700 800 900 1000
Number of nodes N
100
101
102
103
104
Spectrum Requirements
PBFT
Raft
PoW
PoM
Fig. 9: Comparison of the spectrum requirement of different
consensus mechanisms [24]
3) Security Bound: It determines the maximum number of
faulty nodes (f), a consensus protocol can withstand [24]. For
PoW, the security bound is 2f+ 1 due to the possibility that
more than 50% of the computing power within the blockchain
network can be acquired by a user, then the whole blockchain
jeopardizes. In PoM, more than 50% nodes should verify the
winner miner’s solution to generate a valid block. Hence,
the security bound of PoM becomes 2f+ 1. In contrast, the
voting biased consensus protocols consider faulty nodes as
inactive or malicious nodes transmitting false data within the
blockchain network. PBFT permits 1/3of nodes to be faulty
nodes, making security bound to be 3f+ 1. While, Raft has
the capability to tolerate 50% faulty nodes, which results in
security bound to be 2f+ 1.
4) Transaction Throughput: Transactions per second metric
is used to measure the transaction throughput. Typically, proof-
based consensus algorithms such as PoW suffers a great
deal of low throughput compared to other typical consensus
protocols. Due to the time taken to conduct intensive com-
putations to achieve consensus is high. Although the mining
task of PoM instructs to carry out computations, it does not
require plenty of computational power to solve the puzzle.
However, in PoM, keys are transmitted at a given frequency,
which delays the mining process a bit. Therefore, we can
consider the security bound of PoM as medium. In contrast, the
12
transaction throughput of voting-based consensus algorithms
is excessively high [24].
B. Simulation Model 2: Comparison of per transaction energy
utilization [30]
Energy consumption per transaction of typical blockchain
architectures is roughly estimated in the paper [30]. To bring
PoM into this comparison, we estimated the value by mea-
suring the energy consumption for 100 transactions per block
and setting the difficulty level to 4 in our developed simple
blockchain network (refer VIII-B). Based on the experimental
results, we arrive at a magnitude of 18J per transaction. Fig. 10
illustrates a comparison between different architectures with
regard to energy consumption. It is apparent that the PoM can
operate transactions at a low energy consumption compared to
Public Blockchain systems. Furthermore, in PoM a portion of
the total consumption of Energy (18J) spends on monitoring
the network, which is the main functionality of our SSLA
management framework. To elaborate more on that, PoM con-
sensus can be achieved only by monitoring the network, which
is the main function of the proposed application. Therefore, it
is clear that 18J of Energy (total energy consumption of PoM
per transaction) is insignificant compared to other blockchain
networks, which consume Energy solely on the consensus.
In our case, achieving consensus is a byproduct of network
monitoring.
Simple server
Centralized system
Enterprise Blockchian
Proof-of-Monitoring
Public Blockchian Non-PoW
Public Blockchian PoW
10-4
10-2
100
102
104
106
108
1010
Approximation energy consumption per transaction (J)
Fig. 10: Comparison of the energy consumption per transaction
for different architectures [30]
C. Simulation 3: Intra-parameter comparison of PoM
We carried out an analysis to show the impact on key
recovery by varying one of the difficulty factors listed in Table
I, which is the key revealing probability. It is the probability
that the miner nodes willingly reveal their key shares with
other peer nodes by broadcasting the received key shares to
the network. In Fig. 11, we plot the key recovering probability
against the key revealing probability, varying the number of
miner nodes min the blockchain network while keeping the
threshold kconstant. We can formulate the probability of
successfully recovering the key [31] as follows. Note that P
is the probability of revealing a key share, and 1−Pis the
probability the key share is not revealed to others.
PKeyRecovery =
m−1
X
i=k
p(i+1)(1 −p)(m−(i+1)) (10)
Based on Fig.11, it is visible that with the increment of the
number of nodes, the potential to recover a key dramatically
increases. Since there will be many nodes to cooperate by
sharing their received key shares. Another key observation is
that when the key revealing probability rises with the number
of miner nodes, the key recovery rate escalates. This is because
of the existence of many nodes that are extremely willing to
distribute their own key share among others. Hence, every
node gets the privilege of receiving a large number of key
shares, which ultimately helps for the key reconstruction. As
a result, it lowers the difficulty of the mining task.
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Key revealing probability
0
0.2
0.4
0.6
0.8
1
1.2
Key recovering probability
m=4
m=10
m=20
m=50
Fig. 11: The impact of key share revealing probability on key
recovery probability
VII. PROTOTYPICAL IMPLEMENTATION
We developed prototypes separately for the two key modules
proposed in this paper. Namely, (1) consensus protocol and (2)
SSLA management framework. We have built our own fully
functional blockchain prototype from scratch and integrated
the proposed consensus protocol into it. Further, we have
executed the proposed SSLA management services on top of
Ethereum test network. These two main implementations are
discussed explicitly under this section.
A. PoM
The prototype of the proposed system consists of a newly
developed blockchain program using NodeJS, which is used
to simulate the behavior of the participating nodes. Fig. 12
shows the experimental setup of the blockchain system. The
program has RESTful APIs, which can be used to interact
13
with various blockchain operations by the node i.e, joining the
blockchain network, submitting transactions, fetching block
information, mining transactions, and submitting random key
and certificate shares in the network. The blockchain program
is run on different ports in the same system to simulate
multiple nodes. The nodes can join the common blockchain
network by sending an API request, which synchronizes the
blockchain among the participating nodes by broadcasting the
chain.
Fig. 12: Prototype setup for the PoM based blockchain system
A background job is scheduled when a new node is added to
the network, which gets triggered every 20 ms. The job ensures
that the private key duand the certificate Certuare generated
using the previous block timestamp and are divided into parts
using the @zippie/secrets.js package, which uses Shamir’s
threshold secret sharing scheme in JavaScript. During the job,
a random part of both generated duand Certuis broadcasted
by each node across the network using the broadcast API.
The remaining nodes receive the broadcasted shares in a
frequency of 10 seconds and store them locally. The difficulty
of the system is set by increasing the number of shares to
be generated and the minimum number of shares needed to
combine them to successfully recover the duand Certu. The
system’s difficulty can increase by increasing the threshold of
shares required by the miner to retrieve the random key and
certificate successfully.
During the mining process, a mining job has been created
that checks if the threshold is reached to combine the shares
every 200 milliseconds. The nodes keep listening for more
shares if the threshold has not been reached yet to combine
the shares. If the threshold is reached, then Certuand duare
calculated using the shares. The mining node then calculates
the Public Key Quand signs it using the private key duusing
the Elliptic Curve Digital Signature Algorithm (ECDSA). The
miner then creates a new block that contains the timestamp,
transactions, the signature, Quand Certuand broadcasts
information to all the other nodes for verification using the
receive-block API, and deletes the mining job. The nodes
receiving the block verify the signature using the public key Qu
and add the block to the existing blockchain. If the signature
has a mismatch, the block gets rejected.
B. SSLA management system
1) Prototype: We developed SSLA architecture on top of
a blockchain using Distributed Ledger Technology (DLT),
and we selected one of such open-source platforms like
Front-end Application
(Dapp)
WalletApplication
Https
Customer
Https
Service Provider
Injected Web3
Ethereum
node
Ethereum
node
Ethereum
node
Ethereum Blockchain Network
Fig. 13: Smart contract based SSLA framework prototype
implementation
Ethereum. We used the Rinkeby test network, an alternative
to the main blockchain, as the blockchain service in our
implementation. The functionalities of each module in the
blockchain layer of the proposed architecture (as shown in
Fig. 2) are programmed and executed via smart contracts.
Fig. 13 depicts the implemented proposed system model. Each
customer and SP is connected to a crypto wallet applica-
tion (In our implementation, we used Metamask) to perform
cryptocurrency transactions and interact with the Ethereum
blockchain network. The foundation for the client application
is an HTTP server deployed in the local host using Node.js.
Decentralized Applications (DApps) run on a web browser
configured with the MetaMask plugin, which uses Injected
web3. It essentially connects the client application and the
Ethereum blockchain ecosystem together [32]. All DApp and
the blockchain communications are performed over a Remote
Procedure Call (RPC) protocol. RPC transactions are made
possible by the Web3.js library, which translates smart contract
scripts to RPC protocol. The client application has access to
all the smart contracts deployed on the blockchain, thereby
allowing performing function calls needed to manage SSLA
management functionalities.
2) Deployment of smart contracts: The developed proto-
type is executed using Ethereum based smart contracts. The
solidity language was used to code the smart contracts. All the
Ethereum contracts were built and deployed through a browser
based compiler known as Remix IDE. The key functions of
each smart contract are summarized as follows:
•User Authentication Contract: Registers stakeholders and
monitoring nodes. Further, it validates the access permis-
sion requests sent by stakeholders.
•Policy Manager Contract: Deploys and stores SSLAs in
blockchain
•Violation Monitoring Engine Contract: Stores network
monitored data and decides whether a violation actually
happened
•Compensation Calculator Contract: Calculates the com-
pensation fee and the amount to be transferred for the
service provider and blockchain for their service deliver-
ies
•Reputation Management Contract: Calculates the reputa-
tion scores for service providers and blockchain nodes
14
VIII. EXP ER IM EN TAL RES ULT S
We evaluated the performance of the proposed PoM and
SSLA framework by conducting tests on the custom-built
blockchain and the Ethereum-based prototype, respectively. In
the custom-built blockchain, we ran tests to compare PoM
with PoW with respect to average block creation time and the
total energy consumption per block by varying the number
of transactions per block and the difficulty levels of the
consensus. In the Ethereum-based prototype, we carried out a
cost analysis and measured end-to-end latency of the system.
To obtain results for proof of work, the PoM consensus is
replaced by a locally developed proof of work algorithm,
which calculates the correct nonce to get the valid block
hash based on different difficulties. For the tests, the nodes
in the network are set to be 5, broadcasting the shares
randomly among each other. The maximum number of shares
that can be generated is set to be the difficultyf actor ×
numberof nodes, and the threshold to combine the shares is
maximumshares −(numberof nodes/2). One of the nodes
sends different sets of transactions ranging from 100 up to
10000, and one of them mines the transactions using RESTful
API calls and records the block creation time.
A. Block time evaluation
Fig. 14 depicts the comparison of PoW with PoM in terms
of the block creation time for various transactions ranging
from 100 to 10000, keeping the difficulty constant for both
the systems. In the case of PoM the block creation time is
high initially, but as the number of transactions increases, the
time decreases and stays almost the same. This behavior is
because when there are fewer transactions, they get processed
faster, and the miner still does not have the minimum shares
to mine the block. Therefore the miner waits for more shares.
As the number of transactions increases, by the time all the
transactions reach the transaction pool to get mined, the miner
already has the required shares with it. Hence the block
creation time is lesser and increases slowly based on the
increase of transactions. This increases the processing time.
For PoW, as the number of transactions increases, we see an
increase in the block creation time because generating the valid
hash becomes more difficult with it.
A further comparison of both the algorithms is made by
calculating the block creation time of 10000 transactions by
increasing the difficulty from 1to 6, as shown in Fig. 15. The
block creation time increases slowly as the threshold shares
needed by the miner increase with difficulty. The waiting
period for the miner to get the threshold amount of shares
contributes to the rise in time. As the broadcast frequency is
very low, the block creation time increases at a very slow pace.
B. Energy consumption evaluation
We carried out tests to compare the energy consumption
between PoM and PoW consensus algorithms. We referred to
the equation 11 for calculating the energy consumption. Let
Psystem be the power usage of the system, which is 0.55 kW
for all the tests, and Tblock be the block time which is derived
from previous tests.
0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000
Transaction Count
0
10
20
30
40
50
60
70
80
90
100
Block Creation Time (s)
PoM
PoW
Fig. 14: Average block time vs number of transactions per
block
1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6
Difficulty levels
0
200
400
600
800
1000
1200
1400
1600
1800
2000
Block Creation Time (s)
PoM
PoW
Fig. 15: Average block time under different difficulty levels
Energy =Psystem ×Tblock
1000 (11)
We plotted the energy consumption with respect to the
number of transactions per block in the Fig.16. It is clearly
evident that the energy consumption of PoW greatly increases
with the increase in the number of transactions. While PoM
shows very less energy consumption even with the variation in
the number of transactions per block. The energy consumption
for 1000 transactions for different difficulty levels are shown
in Fig. 17. The energy consumption of both the consensus
remains almost similar. It increases slowly till difficulty 4, after
which the energy increases exponentially in the case of PoW,
whereas it increases linearly for PoM. The reason is that until
a difficulty of 4, the valid hash gets calculated fairly easily by
the system, but when it is further increased, the calculation of
the valid hash takes a high amount of time, thus increasing
the energy consumption. In the case of the PoM, the difficulty
increase leads to an increase in the threshold shares, which
15
100 250 500 750 1000 5000 10000
Transaction Count
0
0.005
0.01
0.015
0.02
0.025
0.03
Energy consumption (kWh)
PoM
PoW
Fig. 16: Total energy consumption per block vs number of
transactions per block
123456
Difficulty levels
0
0.1
0.2
0.3
0.4
0.5
0.6
Energy consumption (kWh)
PoM
PoW
Fig. 17: Total energy consumption per block with respect to
different difficulty factors
keep getting broadcasted by nodes in fixed intervals. Hence the
waiting time for the miner to achieve the threshold increases
linearly, resulting in a linear increase in energy consumption.
C. End-to-end latency
We carried out a test to measure the time taken to execute
the main functionality of the proposed system. That is, the
combination of three main functionalities of the proposed ap-
proach: (1) blockchain nodes monitor the network and submit
sensed data to the proposed framework (2) Following that, the
system decides whether a violation occurred or not (3) finally,
imposing penalty (if any violations) on SP, compensating the
customer and transferring fee to violation reporters. We coded
each of these functionalities in Ethereum-based smart contracts
and deployed them in the Rinkeby network (refer VII-B). We
invoked each smart contract from the client application (DApp)
100 times, measured the end-to-end latency to run each of the
0 10 20 30 40 50 60 70 80 90 100
Test Number
160
180
200
220
240
260
280
300
320
340
Time (s)
End-to-end Latency
Average Latency
Upper Confidence
Lower Confidence
Fig. 18: End to end latency from violation reporting to
compensating a customer
three processes, and summed them together. Each measured
end-to-end delay consists of the average block creation time
of 15s [33], which is the block creation time of the Rinkeby
Testnet. We substituted it with the estimated block verification
time of PoM, which we derived by testing. Thereafter, we
plotted the previously calculated total end-to-end delay with a
95% confidence interval and demonstrated in Fig. 18. Based on
the plotted results, we measured the average end-to-end time
taken for the entire process, from data reporting to violation
detection and payment settlements, as approximately 4 minutes
(238s).
D. Cost analysis
This subsection analyse the costs incurred in smart contract
deployment and execution. In the implementation of smart
contracts, a payment of a gas fee is required in Ethereum
blockchain to conduct transactions. Estimation of the gas
consumption for the deployment of contracts and execution
of defined functions in the contract are listed in the TableII.
These estimated gas values were found from the Remix IDE
web browser. Based on the tabulated results, the total cost
incurred to deploy all the smart contracts is approximately 14
Euros, which is a one time payment. For the execution of all
other blockchain service functionalities, it costs around total
of 2 Euros. Based on the results, we can conclude that the
cost incurred to implement the whole system is considerable
when implemented on the Ethereum blockchain. However, this
can be significantly reduced by implementing the proposed
SSLA management framework on top of our novel blockchain
system. Most state-of-art-approaches have implemented their
SLA/SSLA services over the Ethereum platform, which means
that they have run their services on a PoW-based blockchain
platform. In our case, we will be utilizing proposed PoM-
based blockchain, which is custom built for the management
of SSLAs.
16
TABLE II: Gas consumption analysis on Ethereum based
smart contracts utilized in SSLA management services
Contract/Functions Cost
Gwei EURa
User Authentication Contract 713139 2.04
Create User Function 118619 0.334
User Verification Function 24613 0.07
Policy Manager Contract 1515118 4.335
Create SSLA Function 91533 0.026
Customer Approval Function 47703 0.136
Violation Monitoring Engine Contract 1310897 3.75
Security metric storage Function 25420 0.0727
Violation Decision Function 23789 0.068
Compensation Calculator Contract 931808 2.666
Stakeholder Compensation Function 23809 0.068
Reputation Management Contract 419667 1.2
Reputation Calculation Function 31117 0.089
1 Ether = 109Gwei,a1 ether = EUR 2861.21 on 20.04.2022
IX. SECURITY AND FORMAL ANA LYSIS
This section defines and evaluates the general and security
properties of the PoM-based blockchain system. Further, we
present a threat model with potential attacks and defense
strategies. In the end, we present the formal model and
formal verification of the PoM consensus protocol analyzing
its results.
A. Definitions
Definition 1: Chain Quality [34] Let µ∈(0,1] be the
chain quality coefficient. The chain quality QCQ expresses
that if l(l∈N)number of successive blocks of a chain C
acquired by an honest party, then a portion of µblocks mined
by attackers. Then the expected lower bound on the proportion
of honest blocks of chain Ccan be stated as QCQ = 1 −µ.
Definition 2: Chain Growth [34] Let τ∈(0,1] be the
chain speed coefficient. The chain growth QCG expresses that
if the chains C1,C2held by honest parties at rounds r1,r2
with chain lengths l1,l2respectively. r2is ahead of r1by
s(s∈N)number of rounds. Then, it satisfies the r2−r1≥τ.s
Definition 3: Fork Probability The fork probability QFP
expresses the potential for blockchain nodes to receive more
than one block at the same time.
Definition 4: Chain Consistency [35] The chain consis-
tency QCC assures that all honest parties will produce the same
order of blocks in round r, allowing only the last Tnumber
of blocks to be changed.
Definition 5: Blockchain Fork Blockchain fork may trigger
with the presence of many perspectives on the state of the
blockchain. That is when several nodes mine simultaneously
and may find conflicting blocks which split the main chain
into multiple chains.
B. Property Analysis of the PoM based Blockchain
This subsection presents the analysis of the primary
blockchain properties of the proposed consensus protocol.
Namely, fork probability, chain growth, chain consistency, and
chain quality. We developed different models to assess each of
the properties. We designed a probabilistic model to evaluate
fork probability and chain growth. Whilst a Markov model
to analyze chain consistency. In addition to that, we refer to
the simulation model discussed in Section VI-C to assess the
chain quality.
1) Fork Probability: Suppose secret Sis divided into n
number of unique key shares. For a successful reconstruction
of S(or finding the mining solution), at least k(< n)number
of unique key pieces must be recovered. Let us assume, as
an average, that a single node receives keys at a rate of γ
key shares per second. Therefore, the number of key pieces
received by the node after qseconds is γq. A node acquires
keys from itself and its neighboring nodes. Every received
key share is drawn from ntotal key shares. The same key
share can be received multiple times from other nodes even
though only unique key shares contribute to achieving the
consensus. Therefore, we assume receiving keys as events of
simple random sampling with replacement. Let the probability
of finding a mining solution at qseconds is Yq, which is
the same as the probability of having minimum kunique key
shares within γq(≥k)key shares. Let Ukbe the probability
of having at least kunique keys after qseconds, and Nbe the
number of unique key shares a node captured after qseconds,
Uk=P r(N≥k)(12)
It is obvious that, U1= 1. For U2, it can be derived from
U1with probability 1−1
γq , or from U2itself with probability
2
γq . This is because there are γq items in total. Hence, U2can
be deduced as follows,
U2= (1 −1
γq )∗U1+ ( 2
γq )∗U2(13)
Therefore, we can formulate the general equation as below,
Uk=[1 −k−1
γq ]∗Uk-1
[1 −k
γq ](14)
By solving the system of equations, we can obtain the
probability of having at least kunique key shares after q
seconds, which we denoted as Yq(= Uk).
Blockchain fork occurs due to the propagation delay in the
network. Let αbe the mean propagation delay. Then, the
probability of finding a solution during αperiod can be defined
as the fork probability QFP, which can be given as follows,
QFP =Y(q+α)−Y(q) (15)
2) Chain Growth: It is always desirable that consistent
chain growth is maintained throughout the evolution of the
blockchain. However, with the presence of adversary miners,
the chain growth can be negatively influenced to make the
chain stagnant. In our case, an optimal adversary strategy
would be to reduce the chain growth by not sharing their
key shares with neighboring nodes. Therefore, the expected
number of key shares received by a node per second (γ) drops
proportionally to the fraction of adversary nodes. Then the key
17
receiving rate with the presence of adversaries (γZ) can be
derived as shown in the equation 16,
Let the fraction of adversary nodes in the network be β,
then the fraction of honest nodes will be 1−β.
γZ= (1 −β)γ(16)
Therefore, the probability of finding a mining solution at
any given qsecond with the presence of adversaries (denoted
by Yq
′) can be deduced by substituting γwith γZin equation
14, which gives the following equation 17.
Yq
′=[1 −k−1
(1−β)γq ]∗Uk-1
[1 −k
(1−β)γq ](17)
3) Chain Consistency: We consider the Markov Chain
approach [35] in analyzing chain consistency. We rely on con-
vergence opportunities to construct the relationship between
the time a new block is mined and the time all nodes synced
with the new block. This is a three-step event, (1) No honest
player has mined in αrounds. Hence, by the end of αrounds,
all honest players learned about all the existing blocks, and
they all agreed on the length of the longest chain. (2) an honest
player finds the mining solution and mines a block, which will
be the last block of the longest chain. (3) Following another
αround where no honest player mines. Hence, every honest
player learns about the new block and agrees on the longest
chain. Note that we define a round as an attempt made to mine
a block when a node receives a new key.
Based on [35], in order to prove that PoM achieves con-
sistency, we first need to demonstrate the possibilities of how
an adversary can break aforementioned convergence opportu-
nities at any given time. Otherwise, honest players have the
opportunity of converging on the same chain. For the anal-
ysis, we need to count the expected number of convergence
opportunities at a given time and compare it with the expected
number of blocks that the adversary can mine, which is the
minimum amount of work that the adversary must commit to
prevent convergence of honest players. An adversary can break
convergence opportunities by inserting one of their blocks in
the quiet period of step (1) and step (3). Hence, there will
be multiple blocks at the same level, creating a fork for the
honest players to disagree on. The Markov model comes in
handy in counting events that occur at random intervals. In
our situation, blocks can be found close together and far apart
during a given time. Therefore we need to count precisely
how long these quiet periods are. The simple Markov chain
of convergence opportunity [35] corresponding to our PoM
protocol can be modeled as follows,
A B
α≥hit
α
hit, hit ≤α
hit +α
There are two states presented in the Markov model, state
A: honest mined blocks are found close together, where there
is no guarantee of convergence opportunity since the time
between the blocks is always less than α. With the existence
of αrounds where no player mines, then the transition to state
B occurs. At state B, a convergence opportunity can occur if
an honest block is created and a αperiod of silence follows
that. Otherwise, the system state changes back to state A if
two honest blocks are found together at less than αtime.
Let Pαbe the probability of αrounds being unsuccessful
(silent), Then we can state Pαas shown in the equation 18,
Pα= (1 −Yq)α(18)
Let eab be the edge from state A to state B. Hence, we can
compute the stationary distribution for states and edges of the
Markov model as follows,
P[e00] = P[e10 ]=1−Pα
P[e01] = P[e11 ] = Pα
π0=P[A] = (1 −Pα)π0+ (1 −Pα)π1
π1=P[B] = Pαπ1+Pαπ0
(19)
Based on the research work presented in [35], we can
derive that our model satisfies consistency if the number of
convergence opportunities that can occur in Trounds is greater
than or equal to the maximum number of blocks mined by the
adversary during the same Trounds. Hence, we can state the
equation 20. Note that lij is the expected time spent on each
edge, and δ(>0) is the tuning parameter.
T∗Pα2
Pi,j P[eij]πij lij
≥T∗(1 + δ)β(20)
4) Chain Quality: In our blockchain network, malicious
nodes may try to mine blocks selfishly without sharing or
revealing their portion of key shares to other nodes, which
reduces the chances of reconstructing the key during the
desired time interval. This type of scenario is simulated under
Section VI-C and based on its results (presented in Fig.11), we
can conclude that key reconstruction probability will be high
with the existence of a large number of nodes in the blockchain
network including both honest and malicious nodes. Hence,
such malicious behaviors hardly become a threat to the overall
mining activity.
C. Threat model
A malicious miner can model different threats to interfere
with the functionality of the consensus process. Blockchain
fork may be triggered with the presence of many perspectives
on the state of the blockchain. That is when several nodes mine
simultaneously and may find conflicting blocks, which splits
the main chain into multiple chains. In addition to that, there
is a potential to have multiple winner miners at the following
stages; Key revealing stage: at round r, if a majority of nodes
require only a few key shares to find the mining solution, then
at the next round r+ 1 there is a high probability of finding
the mining solution by more than one node. Key distribution
stage: If nodes are able to find the desired key when nodes
start distributing their key shares. To overcome this situation,
we have implemented effective tie-breaking criteria such as
longest chain and heaviest chain.
18
Malicious miners may try to mine blocks secretly without
sharing their portion of key pieces with other nodes while
receiving key pieces from others. To avoid this behaviour,
nodes continuously monitor the broadcasts of neighboring
nodes to identify nodes with poor sharing patterns. If an
uncooperative node is detected, using a tit-for-tat like method,
honest parties refrain from sharing key pieces with such nodes.
Furthermore, selfish mining is another potential malicious
behavior that can appear in the network, where selfish miners
disclose mined blocks to the public blockchain network when
they possess a longer chain. However, in our system, the
probability of introducing a new block to the network by doing
selfish mining is extremely low. This is because selfish miners
are not receiving keys from the majority of the network. This
results in extremely high block creation times. Therefore, the
length of the chain created by honest nodes will be very long
compared to that of selfish miners’ chain, making our model
tolerant of selfish mining.
D. Formal Analysis of PoM
We developed our proposed consensus protocol using CSP#
[36] in the Process Analysis Toolkit (PAT) [37] model checker.
CSP#is a sub-language of Communicating Sequential Pro-
cesses (CSP) and it also supports C#libraries to be imported
where we can define required custom data structures and
functions. Our model made use of this property substantially
to implement the fundamental features and functions of our
blockchain system. We ran the verification via PAT to validate
general and security properties of the designed formal model,
by defining several assertion rules. The complete CSP model
and the C#library for the PoM consensus is available in a
GitHub repository. 1
1) Formal Modeling: We modeled a blockchain network
with Nnumber of nodes, where each node is connected with
few other nodes. We allowed the inter node communication
to be happened through channels that we built between each
connected node. Each node runs a series of processes concur-
rently to achieve consensus. These processes are defined as
sequences of events and they represent basic functionalities
of the proposed consensus protocol that is required to find a
winning node to create the block. According to CSP#[36]
modelling language, our blockchain system can be denoted as
a sequence of key processes that complement key phases of
our PoM protocol as follows,
BlockChain() = I nitialize(); StartBroadcast();
StartBroadcast() = (||x:{1..N }@(Reveal(x);
(Send(x)||Receive(x)); IsMined())); StartBroadcast();
Note that P;Qdenotes a process Pfollowed by process Q
and P||Qdenotes when Pand Qprocesses run in parallel.
The initialize() process generates a master key Mwhich is
a random sequence of nnumber of keys. It assigns each node
with a master key by shuffling key shares of M.
The Reveal(x)process, when called, reveals node xa
key at a time and adds revealed keys to a list (called
Captured Keys). The Send(x)process distribute keys only
1https://github.com/nisitaw94/PoM.git
to their neighbour nodes through channels connecting neigh-
bour nodes. Receive(x)process captures keys distributed by
their neighbour nodes and adds to its Captured Keys list
if and only if the received key is not in its list of collected
keys. IsM ined(x)process inspects whether any node has
captured knumber of unique keys, where kis the threshold,
the number of keys required to find the winning solution. If
a wining miner has found, IsMined(x)process sets a flag to
indicate that, so that it can be verified by verification program.
StartBroadcast() process allows Nnumber nodes to execute
sequence of processes including Reveal(x),Receive(x)and
IsMined(x)in parallel, which is considered as one cycle. In-
clusion of StartBroadcast() at the end of StartBroadcast()
permits the algorithm to run continuously.
2) Formal Verification : We validated our formal model of
the proposed consensus protocol using the PAT model checker
by considering four aspects for verification . These four aspects
are simulated by varying the number of malicious nodes in the
system. Scenario 1 (S1): when none of the nodes are malicious,
Scenario 2 (S2): when one-third of total nodes are malicious,
Scenario 2 (S3): when half of total nodes are malicious and
Scenario 3 (S4): when two third of nodes are malicious. We
consider nodes are malicious when they do not co-operate
in distributing its own collected keys within the network.
We performed formal verification by setting following model
parameters in the designed formal model of the PoM: N=6
number of nodes, (n,k) = (20,18) number of keys. We validated
our system under the aforementioned scenarios against the
following set of properties and tabulated its results in the table
III,
•Deadlock-free (A1) assures that there does not exist
any interference continuing any process and none of the
nodes’ activities are halted unexpectedly and indefinitely.
•Consensus (A2) examines whether any node in the
network is successful in acquiring knumber of unique
keys, to become the winning miner. If a node manages to
become the winner, we consider our system has reached
consensus.
•No Blockchain Fork (A3) guarantees a network with
no more than one wining node within the same cycle.
Here, a fork can be created during key revealing or key
receiving stages.
TABLE III: Verification results against the properties of formal
model
Assertion Rules Deadlock
free
(A1)
Consensus
(A2)
No
Blockchain
Fork (A3)
#assert Blockchain() with no
malicious nodes (S1)
✓ ✓ ✓
#assert Blockchain() with mi-
nority malicious nodes (S2)
✓ ✓ ✓
#assert Blockchain() with half
malicious nodes (S3)
✓ ✓ ✓
#assert Blockchain() with ma-
jority malicious nodes (S4)
✓ ✓ ✓
3) Results Analysis: Based on table III, we can come to
the following conclusions with respect to each assertion rules,
19
•A1: We can deduce that, the system is deadlock free
despite the model variations.
•A2: We can observe that regardless of malicious activi-
ties present in the network, system achieves consensus.
However, in order for the time to achieve consensus to be
in a reasonable range, number of malicious nodes should
be as low as possible.
•A3: We can conclude that our model guarantees that no
blockchain fork occurs under all four scenarios, from the
start until the winner of the first block is found.
One of the drawbacks of PAT we experienced during our
study is that the time it takes to run a verification grows
exponentially when the number of nodes is increased. This is
due to the nature of the model checking technique PAT uses,
which allows for a state explosion to occur with increasing
complexity of the model [38]. Hence, we restricted our model
to six nodes.
X. DISCUSSION
A. Comparison with existing systems
TABLE IV: Feature comparison with related works
Features [3] [25] [26] [8] Ours
SLA/SSLA SSLA SLA SLA SLA SSLA
Blockchain-based ✗ ✓ ✓ ✓ ✓
Consensus Protocol -PoET PoW PoW PoM
SSLA oriented Consensus Pro-
tocol
-✗ ✗ ✗ ✓
Automated System ✓✓✓✓✓
Network Sensing ✓ ✗ ✗ ✗ ✓
Violation Detection ✓✓✓✓✓
Customer Compensation ✗ ✓ ✓ ✓ ✓
SP Penalty Scheme ✗✗✓✗✓
Reputation Management ✗ ✗ ✗ ✓ ✓
Off-chain storage ✗✗✗✗✓
Computational Complexity -Low High High Low
✓→Yes, ✗→No, -→Not Applicable
Table IV compares the proposed SSLA management sys-
tem with the existing state of work. There is still no
novel blockchain-based SSLA management system introduced.
However, there is plenty of research work on SLAs now run on
the blockchain. Hence, we compared our work with both SLA
and SSLA research studies. Blockchain systems are way better
than the non-blockchain system since it permits automating
the whole system by running services via smart contracts.
Nevertheless, there are still bottlenecks in Blockchain-based
systems, such as high energy consumption, high computational
complexity, and high cost. Our solution rectifies these chal-
lenges by introducing a SSLA application biased consensus
protocol.
B. Challenges
There are plenty of modular blockchains available that
claim to be fully customizable. However, it is inevitable that
the customized blockchain shares most of its fundamental
characteristics with that of its counterpart in most cases. As
a result, they are still not flexible enough to adapt to a
custom blockchain with a work-based consensus algorithm.
For example, the Stratis platform consists of PoW/PoS/ Proof-
of-Authority (PoA) consensus options, while Hyperledger sup-
ports KAFKA/SOLO. Even though they are customizable, in
order to be a feasible model, it is expected from adapters that
their new algorithms to inherit from the existing ones, which
essentially limits the customisation only up to a certain extent.
In contrast, we implemented our proposed consensus algorithm
in a local blockchain developed using NodeJS from scratch.
During development of the prototype few design challenges
were identified i.e, to generate the elliptic curve for key
computation, a random number had to be used to get the
generator point on the curve. However, in order for all miners
to generate the same master key, The generator point had to be
the same for all the miners. This is practically not achievable.
Hence, a combination of the last block’s timestamp and its
creators address was used in place of the random number. In
addition to that, during the block verification phase, the winner
miner was supposed to broadcast the message which consisted
of the public key Quby encrypting it with the private key du.
Since the block verification has to be done by every node in the
network while syncing their local blockchain, instead of using
an asymmetric cryptographic algorithm ECDSA, a symmetric
cryptographic algorithm was used. So that the broadcasting
miner can sign the winning message using the common key
Quand the nodes can verify the signature using their version
of Quand verify the message for a successfully mined block.
XI. CONCLUSION
In this research, we thoroughly evaluated the potential
challenges of conventional SLA/SSLA management systems,
and to mitigate them, we introduced an automated SSLA man-
agement framework with an accompanying custom blockchain.
Based on the experimental results of the implemented PoM
consensus, we concluded that the system consumes less time,
energy, and cost compared to PoW, the most commonly used
consensus algorithm in state-of-art blockchain-based SLA sys-
tems. The calculations indicate satisfactory end-to-end latency
levels even though such SLA management systems are not
time-critical. More importantly, the overall performance of
our solution in terms of available security features proves to
outperform most other platforms available. With the utilization
of off-chain databases to securely store monitoring data, we
prevented excessive growth of the ledger, thereby improving
the scalability and adaptability. As the very first blockchain-
based SSLA management framework, we identified potential
application scenarios for the given system in current and future
networking paradigms. In the future, we plan to further expand
the implementation of SSLA management services and the
proposed blockchain system by leveraging AI-based solutions
to predict SSLA violations beforehand.
ACKNOWLEDGMENT
This research has been supported by the Academy of
Finland, 6G Flagship program under Grant 346208 and the
Science Foundation Ireland under Connect Center (13 RC/
2077 P2). The research leading to these results partly received
20
funding from the European Union’s Horizon 2020 research
and innovation programme under grant agreement no 871808
(5G PPP project INSPIRE-5Gplus). The paper reflects only
the authors’ views. The Commission is not responsible for
any use that may be made of the information it contains.
REFERENCES
[1] E. Marilly, O. Martinot, S. Betge-Brezetz, and G. Delegue, “Require-
ments for service level agreement management,” in IEEE Workshop on
IP Operations and Management, 2002, pp. 57–62.
[2] C. Lee, K. M. Kavi, R. A. Paul, and M. Gomathisankaran, “Ontology
of Secure Service Level Agreement,” in 2015 IEEE 16th International
Symposium on High Assurance Systems Engineering, 2015, pp. 166–172.
[3] P. Alemany, D. Ayed, R. Vilalta, R. Mu˜
noz, P. Bisson, R. Casellas,
and R. Mart´
ınez, “Transport network slices with security service level
agreements,” in 2020 22nd International Conference on Transparent
Optical Networks (ICTON). IEEE, 2020, pp. 1–4.
[4] E. Viegas, A. Santin, J. Bachtold, D. Segalin, M. Stihler, A. Marcon,
and C. Maziero, “Enhancing service maintainability by monitoring and
auditing sla in cloud computing,” Cluster Computing, vol. 24, no. 3, pp.
1659–1674, 2021.
[5] H. Natarajan, S. Krause, and H. Gradstein, Distributed Ledger Technol-
ogy and Blockchain. World Bank, 2017.
[6] Z. Tian, M. Li, M. Qiu, Y. Sun, and S. Su, “Block-DEF: A Secure
Digital Evidence Framework Using Blockchain,” Information Sciences,
vol. 491, pp. 151–165, 2019.
[7] H. Nakashima and M. Aoyama, “An automation method of sla contract
of web apis and its platform based on blockchain concept,” in 2017 IEEE
International Conference on Cognitive Computing (ICCC). IEEE, 2017,
pp. 32–39.
[8] H. Zhou, X. Ouyang, Z. Ren, J. Su, C. de Laat, and Z. Zhao, “A
blockchain based witness model for trustworthy cloud service level
agreement enforcement,” in IEEE INFOCOM 2019-IEEE Conference
on Computer Communications. IEEE, 2019, pp. 1567–1575.
[9] E. Marilly, O. Martinot, S. Betge-Brezetz, and G. Delegue, “Require-
ments for service level agreement management,” in IEEE Workshop on
IP Operations and Management, 2002, pp. 57–62.
[10] J. S. Duela and P. U. Maheswari, “Mitigation of DDoS Threat to Service
Attainability in Cloud Premises,” International Journal of Reasoning-
based Intelligent Systems, vol. 10, no. 3-4, pp. 337–346, 2018.
[11] C. A. B. De Carvalho, R. M. de Castro Andrade, M. F. de Castro, E. F.
Coutinho, and N. Agoulmine, “State of the Art and Challenges of Secu-
rity SLA for Cloud Computing,” Computers & Electrical Engineering,
vol. 59, pp. 141–152, 2017.
[12] K. Shafique, B. A. Khawaja, F. Sabir, S. Qazi, and M. Mustaqim,
“Internet of Things (IoT) for Next-Generation Smart Systems: a Review
of Current Challenges, Future Trends and Prospects for Emerging 5G-
IoT Scenarios,” IEEE Access, vol. 8, pp. 23022–23 040, 2020.
[13] P. Porambage, C. Schmitt, P. Kumar, A. Gurtov, and M. Ylianttila,
“Pauthkey: A pervasive authentication protocol and key establishment
scheme for wireless sensor networks in distributed iot applications,”
International Journal of Distributed Sensor Networks, vol. 10, no. 7,
p. 357430, 2014.
[14] A. Shamir, “How to share a secret,” Communications of the ACM,
vol. 22, no. 11, pp. 612–613, 1979.
[15] F. Faniyi and R. Bahsoon, “A systematic review of service level
management in the cloud,” ACM Computing Surveys (CSUR), vol. 48,
no. 3, pp. 1–27, 2015.
[16] P. Grubitzsch, I. Braun, H. Fichtl, T. Springer, T. Hara, and A. Schill,
“Ml-sla: Multi-level service level agreements for highly flexible iot
services,” in 2017 IEEE International Congress on Internet of Things
(ICIOT), 2017, pp. 113–120.
[17] S. Hm and G. Prakash, “Trust modeling and service level agreement
monitoring in federated cloud,” 2021.
[18] K. Xiao, Z. Geng, Y. He, G. Xu, C. Wang, and Y. Tian, “A blockchain-
based privacy-preserving 5g network slicing service level agreement
audit scheme,” EURASIP Journal on Wireless Communications and
Networking, vol. 2021, no. 1, pp. 1–16, 2021.
[19] R. Ranchal and O. Choudhury, “Slam: A framework for sla management
in multicloud ecosystem using blockchain,” in 2020 IEEE Cloud Summit,
2020, pp. 33–38.
[20] H. Afzaal, M. Imran, M. U. Janjua, and S. P. Gochhayat, “Formal mod-
eling and verification of a blockchain-based crowdsourcing consensus
protocol,” IEEE Access, vol. 10, pp. 8163–8183, 2022.
[21] W. Y. M. M. Thin, N. Dong, G. Bai, and J. S. Dong, “Formal analysis
of a proof-of-stake blockchain,” in 2018 23rd International Conference
on Engineering of Complex Computer Systems (ICECCS). IEEE, 2018,
pp. 197–200.
[22] J. Rupasena, T. Rewa, K. T. Hemachandra, and M. Liyanage, “Scalable
storage scheme for blockchain-enabled iot equipped food supply chains,”
in 2021 Joint European Conference on Networks and Communications
& 6G Summit (EuCNC/6G Summit). IEEE, 2021, pp. 300–305.
[23] “MATLAB,” last accessed 15 April 2022. [Online]. Available:
https://www.mathworks.com
[24] L. Zhang, H. Xu, O. Onireti, M. A. Imran, and B. Cao, “How much com-
munication resource is needed to run a wireless blockchain network?”
arXiv preprint arXiv:2101.10852, 2021.
[25] R. B. Uriarte, H. Zhou, K. Kritikos, Z. Shi, Z. Zhao, and R. De Nicola,
“Distributed service-level agreement management with smart contracts
and blockchain,” Concurrency and Computation: Practice and Experi-
ence, vol. 33, no. 14, p. e5800, 2021.
[26] C. Schweizer, “Slamer: a blockchain-based sla management system,”
2019.
[27] P. Abhishek, A. Chobari, and D. Narayan, “Sla violation detection
in multi-cloud environment using hyperledger fabric blockchain,” in
2021 IEEE International Conference on Distributed Computing, VLSI,
Electrical Circuits and Robotics (DISCOVER). IEEE, 2021, pp. 107–
112.
[28] A. Alzubaidi, K. Mitra, P. Patel, and E. Solaiman, “A blockchain-based
approach for assessing compliance with sla-guaranteed iot services,”
in 2020 IEEE International Conference on Smart Internet of Things
(SmartIoT). IEEE, 2020, pp. 213–220.
[29] A. T. Wonjiga, S. Peisert, L. Rilling, and C. Morin, “Blockchain as a
trusted component in cloud sla verification,” in Proceedings of the 12th
IEEE/ACM International Conference on Utility and Cloud Computing
Companion, 2019, pp. 93–100.
[30] J. Sedlmeir, H. U. Buhl, G. Fridgen, and R. Keller, “The energy
consumption of blockchain technology: beyond myth,” Business &
Information Systems Engineering, vol. 62, no. 6, pp. 599–608, 2020.
[31] P. Porambage, Y. Miche, A. Kalliola, M. Liyanage, and M. Ylianttila,
“Secure keying scheme for network slicing in 5g architecture,” in 2019
IEEE Conference on Standards for Communications and Networking
(CSCN). IEEE, 2019, pp. 1–6.
[32] W.-M. Lee, “Using the Metamask Chrome Extension,” in Beginning
Ethereum Smart Contracts Programming. Springer, 2019, pp. 93–126.
[33] “Ethereum Testnet,” last accessed 22 April 2022. [Online]. Available:
https://www.rinkeby.io/
[34] A. Kiayias and G. Panagiotakos, “Speed-security tradeoffs in blockchain
protocols,” Cryptology ePrint Archive, 2015.
[35] L. Kiffer, R. Rajaraman, and A. Shelat, “A better method to analyze
blockchain consistency,” in Proceedings of the 2018 ACM SIGSAC
Conference on Computer and Communications Security, 2018, pp. 729–
744.
[36] J. Sun, Y. Liu, J. S. Dong, and C. Chen, “Integrating specification
and programs for system modeling and verification,” in 2009 Third
IEEE International Symposium on Theoretical Aspects of Software
Engineering. IEEE, 2009, pp. 127–135.
[37] J. Sun, Y. Liu, J. S. Dong, and J. Pang, “Pat: Towards flexible verifi-
cation under fairness,” in International conference on computer aided
verification. Springer, 2009, pp. 709–714.
[38] E. M. Clarke, W. Klieber, M. Nov´
aˇ
cek, and P. Zuliani, “Model checking
and the state explosion problem,” in LASER Summer School on Software
Engineering. Springer, 2011, pp. 1–30.
Nisita Weerasinghe is a Doctoral student of Net-
SEC (Network security, trust and privacy) re-
search group at Center for Wireless Communications
(CWC), University of Oulu, Finland. She received
her B.Sc degree in Electrical and Electronic En-
gineering from Sri Lanka Institute of Information
Technology (SLIIT), Malabe, Sri Lanka, in 2018
and Master of Science in Wireless Communications
Engineering from the University of Oulu, Finland, in
2020. She has over two-year research experience in
CWC, University of Oulu in the area of Blockchain,
Local 5G networks and Network Security. Her research interests include
Blockchain, 5G, Local 5G Operators, Network Security, Network Slicing.
21
Raaj Mishra is a software engineer at Dell Tech-
nologies, Bangalore, India. He finished his B.Tech
at the Department of Computer and Communication
Engineering, School of Computing and Informa-
tion Technology, Manipal University Jaipur, India in
2020. Raaj has experience in fullstack software and
blockchain-based decentralized application (DApp)
development. He has also worked on two Blockchain
based projects and has published papers at IEEE
CCNC 2020 and IEEE 5G World Forum 2020. He
also has conducted two workshops: ”Blockchain for
Cyber-Physical Systems and IoT” at ANTS 2019 and ”Blockchain Tech-
nology, Its Technical Challenges and Role of Formal Methods” at ETCI
2021. His research interests include blockchain, decentralized Applications,
microfrontends and network security.
Pawani Porambage is a senior researcher at VTT
Technical Research Centre of Finland and an Ad-
junct Professor at University of Oulu, Finland. She
was a researcher at the Centre for Wireless Commu-
nications, University of Oulu, Finland over ten years.
She obtained her B.Sc. Degree in Electronics and
Telecommunication Engineering from University of
Moratuwa, Sri Lanka in 2010, MSc. Degree in
Ubiquitous Networking and Computer Networking
from University of Nice Sophia-Anipolis, France in
2012, and Doctor of Technology in communication
engineering from University of Oulu, Finland in 2018. She has over nine
years of experience in network security domain and co-authored more than
50 publications. Her main research interests are network slicing, blockchain,
lightweight security protocols, security and privacy on IoT, and AI/ML for
security and privacy.
Madhusanka Liyanage (Senior Member, IEEE) is
an Assistant Professor/Ad Astra Fellow and Director
of Graduate Research at the School of Computer Sci-
ence, University College Dublin, Ireland. He is also
acting as a Docent/Adjunct Professor at University
of Oulu, Finland, University of Ruhuna, Sri Lanka
and University of Sri Jayawardenepura, Sri Lanka.
He received his Doctor of Technology degree in
communication engineering from the University of
Oulu, Oulu, Finland, in 2016. From 2011 to 2012, he
worked as a Research Scientist at the I3S Laboratory
and Inria, Sophia Antipolis, France. He was also a recipient of the prestigious
Marie Skłodowska-Curie Actions Individual Fellowship and Government of
Ireland Postdoctoral Fellowship during 2018-2020. During 2015-2018, he has
been a Visiting Research Fellow at the CSIRO, Australia, the Infolabs21, Lan-
caster University, U.K., Computer Science and Engineering, The University
of New South Wales, Australia, School of IT, University of Sydney, Australia,
LIP6, Sorbonne University, France and Computer Science and Engineering,
The University of Oxford, U.K. He is also a senior member of IEEE. In 2020,
he received the ”2020 IEEE ComSoc Outstanding Young Researcher” award
by IEEE ComSoc EMEA. In 2021, he was ranked among the World’s Top
2% Scientists (2020) in the List prepared by Elsevier BV, Stanford University,
USA. Also, he was awarded an Irish Research Council (IRC) Research Ally
Prize as part of the IRC Researcher of the Year 2021 awards for the positive
impact he has made as a supervisor. Dr. Liyanage’s research interests are
5G/6G, SDN, IoT, Blockchain, MEC, mobile, and virtual network security.
More info: www.madhusanka.com
Mika Ylianttila (M. Sc, Dr.Sc, eMBA) is a full-time
associate professor (tenure track) at the Centre for
Wireless Communications - Networks and Systems
research unit, at the Faculty of Information Technol-
ogy and Electrical Engineering (ITEE), University
of Oulu, Finland. He is the director of Communica-
tions Engineering Doctoral Degree Program and he
leads NSOFT (Network security and softwarization)
research group which studies and develops secure,
scalable and resource-efficient techniques for 5G and
beyond 5G and IoT systems. He has co-authored
more than 200 international peer-reviewed articles. He is a Senior Member
of IEEE and associate editor in IEEE Transactions on Information Forensics
and Security.
