# Architecture of Smart Certificates for Web3 Applications Against
Cyberthreats in Financial Industry

1st Stefan Kambiz Behfar  Department of Information Systems, Geneva School of
Business Administration, Geneva, Switzerland
Department of Computer Science and Technology, University of Cambridge,
Cambridge, United Kingdom
<EMAIL_ADDRESS>2nd Jon Crowcroft  Department of Computer
Science and Technology, University of Cambridge, Cambridge, United Kingdom
Alan Turing Institute, London, United Kingdom
<EMAIL_ADDRESS>
###### Abstract

This study addresses the security challenges associated with the current
internet transformations, specifically focusing on emerging technologies such
as blockchain and decentralized storage. It also investigates the role of Web3
applications in shaping the future of the internet. The primary objective is
to propose a novel design for ’smart certificates,’ which are digital
certificates that can be programmatically enforced. Utilizing such
certificates, an enterprise can better protect itself from cyberattacks and
ensure the security of its data and systems. Web3 recent security solutions by
companies and projects like Certik, Forta, Slither, and Securify are the
equivalent of code scanning tool that were originally developed for Web1 and
Web2 applications, and definitely not like certificates to help enterprises
feel safe against cyberthreats. We aim to improve the resilience of
enterprises’ digital infrastructure by building on top of Web3 application and
put methodologies in place for vulnerability analysis and attack correlation,
focusing on architecture of different layers, Wallet/Client, Application and
Smart Contract, where specific components are provided to identify and predict
threats and risks. Furthermore, Certificate Transparency is used for enhancing
the security, trustworthiness and decentralized management of the
certificates, and detecting misuses, compromises, and malfeasances.

##  1 INTRODUCTION

Blockchain Technology (BT) has come into existence with a number of promising
potential applications. After the emergence of Bitcoin, BT triggered
fundamental debates in multiple areas, mostly related to the possibility to
design smart contracts (self-enforcing contracts) and to apply them to a range
of activities, including capital formation (Initial Coin Offerings and their
transformations), digital securities, and Central Bank Digital Currencies
(CBDCs). All this led to the establishment of new paradigms, including the
crypto-economy and so-called Decentralized Finance (DeFi). Not surprisingly,
many companies invested and established consortia in BT, channeling
increasingly ingest amounts, reaching an all-time record of 26.8 billion
dollar in 2022 (CBInsights [1]), despite one of the most difficult years in
terms of financial losses. The cryptocurrency market created by BT has reached
a total market capitalization of more than 143 billion dollar (CoinMarketCap,
2019 [2]). Moreover, Chowdhury et al. (2018) [3] have shown that BT has been
applied to many sectors including the public and academic institutes. Also,
governments have applied the use of blockchain in the public sector
(Berryhill, 2018 [4]).
BT implements a structural decentralization, promising the establishment of a
radically new way of conducting business transactions, especially among
untrusted entities. Cryptography, transparency, and decentralized smart
contracts and smart ledgers are the key elements supporting verification,
identification, authentication, integrity, and immutability. BT provides the
exchange of transactions in a vast network of untrusted entities as well as
chronologically linked and duplicated digital ledgers in a decentralized
database. Furthermore, it eliminates the need to rely on a centralized
authority by offering independent verification guarantees. Additionally,
because there are no centralized authorities, blockchain services can apply
immutability to prevent abuse even in the case of a hostile insider, which
increases security properties for distributed systems (Maleh et al., 2020
[5]).
Given that BT is a cutting-edge technology with a lot of potential, there are
doubts about how reliable it is (Natarajan et al, 2019 [6]). If a system had
such authority, then its most potent actors may collude to alter the
blockchain or stop its contents from being broadcast. There have been numerous
documented cyberattacks, and blockchain implementations have several
cybersecurity flaws (Luu et al., 2016 [7], Taylor et al., 2019 [8]). By
transferring tiny quantities of ”dust coins” to the personal wallets of the
target victims, hackers were able to compromise the privacy and anonymity of
Bitcoin (BTC) users, as evidenced by the attack on the Litecoin blockchain
network in 2019. By undertaking a combined analysis of the addresses, hackers
could discover the owner of each wallet and follow its international activity
(Omelchenko, 2019 [9]).
Financial institutions are impacted by the growth of Blockchain-based
financial services in a big way. Blockchain technology and smart contracts,
for instance, can remove intermediaries, centralized administration, fraud,
and theft, making it simpler for the transparency mechanism to reduce
financial services liability (Chang et al., 2020 [10]). In the financial
industry, decentralized Blockchain networks eliminate financial intermediaries
by allowing each financial partner to contribute to the network via a P2P
network so that direct money transfers can be made. In addition, each
financial organization maintains a distributed ledger with a finite volume of
financial transactions per block. In conventional banking systems, the
intermediary bank was entirely responsible for coordinating all transactions
between multiple organizations. Blockchain technology removes the
intermediary, enabling the majority of network nodes to confirm the legitimacy
of a transaction. Due to the possibility of stored transactions leaking
”sensitive and trading information,” integrating public Blockchain and
distributed ledgers would be extremely difficult (see Hameed et al. 2022
[11]). In order to address the integration challenges of distributed ledgers
with Blockchain technology, Wang and Kogan (2018) [12] suggested a Blockchain-
based privacy preservation technique to safeguard users’ financial
information. A private Blockchain network’s financial transactions are
protected by homomorphic encryption and zero-knowledge proof. The majority of
Blockchain systems designed for financial transactions have ”high transaction
costs,” ”propagation delays,” and ”latency”. Zhong et al. (2019) [13]
presented a safe and simple payment method to effectively use Blockchain-based
financial system services and to ensure system security and robustness.
Web3 refers to the next generation of the World Wide Web, which is
characterized by decentralized technologies and applications built on
blockchain and other distributed ledger technologies. The scope of this paper
covers Web3 which differs from Web 2.0, emphasizing the decentralized,
trustless, and blockchain-based nature of Web3 which is conceptualized as a
third-generation technology, mainly characterized by the semantics of
decentralized intelligence (Behfar, 2023 [14-15]). In a paper, Su et al (2021)
[16] claimed to present the first study that analyzes and measures real-world
attacks on Ethereum Dapps based upon the forensic evidence recorded on the
blockchain. Chen et al (2023) [17] also presented an empirical study that
uncovers unfair trades on popular DEX services on Ethereum and Binance Smart
Chain. By joining and analyzing 60 million transactions, they found 671, 400
unfair trades on all six measured DEXes, including Uniswap, Balancer, and
Curve.
The success of Web3 links to innovation in new security challenges created by
different application architectures. A blockchain, network nodes, and smart
contracts are used to handle logic and state in Web3 applications which are
built in a decentralized fashion without relying on the traditional
application logic and database layers that exist in Web2. Users can still
update data by publishing new content or making purchases through a frontend
that links to those nodes. Users are required to sign transactions using their
private keys, which are commonly managed in wallets. This architecture is
meant to protect user privacy and control and allow for complete transparency,
open access, and immutability of transactions.
The design has security trade-offs, just like any other system. As opposed to
Web2, the blockchain does not rely on actors to be trustworthy, and is more
difficult to update the system to fix security issues. Although users retain
identity control, there are no middlemen to offer remedies in the event of
attacks or major compromises. Because wallets are still software, which will
never be completely reliable, they can still leak private data like an
Ethereum address (see Dang, 2022 [18]). Due to all the above-mentioned Web3
security flaws, we propose an architecture to improve the capacity building in
its digital infrastructure security. Ultimately we provide design of smart
certificates (digital certificates that can be programmatically enforced)
composed of various components with different layers suitable for deployment
in any target domain against cyberattacks. Using such smart certificates, Web3
applications can implement best practices for secure data exchange, such as
encryption and authentication, and ensure that all participants in the network
are adhering to these practices. In section 2 we will discuss the research
design including the research questions, and in section 3 we will provide the
solution including the architecture of vulnerability detection and monitoring,
usecases, and smart certificates, we will discuss the implementation in
detail, and finally investigate the certificate transparency and its
integration into the smart certificates.

##  2 RESEARCH DESIGN

###  2.1 Related Work

The rise of Web3 applications has ushered in a new era of decentralized
internet, bringing forth various architectural solutions aimed at ensuring
security, scalability, and user experience. This section delves into notable
solutions in the domain and highlights the distinctiveness of our approach.

####  2.1.1 Traditional Web3 Security Measures

  * •

Description: Traditional security measures for Web3 applications often rely on
code audits, manual testing, and basic encryption mechanisms to safeguard
against vulnerabilities.

  * •

Limitations: These methods can be time-consuming, error-prone, and may not
capture all potential security threats, especially those that evolve over
time.

####  2.1.2 Decentralized Identity Solutions

  * •

Description: Solutions like uPort or Sovrin provide decentralized identity
systems for Web3, ensuring user privacy and data ownership.

  * •

Limitations: While they enhance user privacy, they don’t necessarily address
broader application vulnerabilities or compliance needs.

####  2.1.3 Smart Contract Scanning Tools

  * •

Description: Tools like Mythril, Slither, and Securify offer automated
scanning of smart contracts to detect vulnerabilities.

  * •

Limitations: They focus solely on smart contract code and may overlook broader
application or network-level vulnerabilities.

####  2.1.4 Decentralized Access Control Systems

  * •

Description: Solutions such as Ocean Protocol implement decentralized access
control for data sharing in Web3 applications.

  * •

Limitations: These systems primarily focus on data access and may not address
other types of vulnerabilities or threats.

Our Approach:  Our proposed architecture introduces smart certificates to
enhance the security of Web3 applications:

  * •

Comprehensive Security: Unlike traditional measures that focus on specific
aspects of security, our smart certificates provide a holistic security
solution, addressing both application-level and network-level vulnerabilities.

  * •

AI-Driven Threat Detection: Our architecture integrates AI to predict and
counteract threats in real-time, offering a proactive approach to security
that goes beyond static code analysis.

  * •

Regulatory Compliance: Extended version of our smart certificate ensures that
Web3 applications not only remain secure but also complies with relevant
regulations, bridging the gap between decentralized technologies and
regulatory standards.

  * •

User-Centric Design: Our architecture prioritizes end-users, offering them
intuitive interfaces, real-time alerts, and the confidence that the Web3
applications they interact with adhere to the highest security standards.

###  2.2 Research Questions

This project targets to achieve protection against cyberattacks mainly from
social media (but not necessarily) into Web3 apps. To realize this ambition
first requires investigating different layers to which Web3 applications span.
The project will develop a user-stimulating cyber security reference
architecture, as seen in Figure 1; the enduser could be human or IoT devices.
Nevertheless, a smart certificate is aimed to intervene in their communication
with the Web3 app.

Figure 1: Certification and validation of web apps.

User profiling will be used to tailor the solution, as different types of
users may desire different levels of privacy and security. A lead user will be
able to define initial profiles, which can then be regularly updated with the
support of data analytics associated with the certification. Let us explore
some relevant research questions such as:

RQ1: What are different layers to which Web3 applications span, provide
detailed research on attacks that exist for Web3 apps?

RQ2: How user profiling will be used to tailor the solution, as different
types of users may desire different levels of security?

The proposed cyber security inspection framework will encapsulate components,
such as detectors of behavior and network anomalies, that will allow it to act
as a risk assessment tool by controlling data being sent by the access point
and blocking whenever it is needed. This will build and refine device-centric
and user-centric data profiles according to the real-time event processing and
network data analysis that will enable the system to act unobtrusively. The
application vulnerability detection mechanism and toolkit and the AI engine
will build upon blockchain technology and is benefiting from this concept by
integrating the adaptation of the blockchain architecture to repel and
counteract the most modern attacks by decentralizing its core risk assessment
and AI engine. With the use of blockchain, each node on the network replicates
the decision rules (smart contracts) for all nodes, making the whole system
more dynamic and reliable by putting up in front the true benefits of the
decentralization approach. But,

RQ3: How can one design and implement components that monitor/secure Web3 apps
in each layer?

The proposed certificate is supposed to improve the resilience of digital
infrastructure by building on top of the Web3 app smart certificates against
cyberattacks, for attack detection, identification, and mitigation. This Web-
Blockchain encompasses different layers, Media, Wallet/Client, where for each
layer specific components will be provided for identifying and predicting
cybersecurity/privacy threats and risks. The certification should be designed
based on smart contract vulnerability detection and real-time web cyberattack
detection, and attack correlation and integrity monitoring. In this project,
the end-user is at its core, and special emphasis is given to informing and
educating the user on these. Overall, end-users will be given the desired
level of cyber control over security and privacy protection, while the engine
will regularly review the security behavior and recommend improvements.

RQ4: How can one generate and update certificates for Web3 apps to
substantially reduce vulnerabilities induced by the human factor?

To keep up with cybersecurity issues and threats, we need to prioritize types
of threats according to the likelihood of exposure and severity of
consequences and study how already identified best practices can be applied.
On top of this, the anomaly detection tool will function as an extra security
control point for unknown threats. The tool will detect deviations from the
normal behavior of different entities (including IoT devices and end-users) by
correlating new findings with known patterns of attacks. All the above will be
tailored to the usable security needs that different types of Web3 app users
may have, by co-defining appropriate policies.

RQ5: How can one provide an effective response to multiple cybersecurity
threats on Web3 apps tailored to the end-user needs?

##  3 SOLUTION

Due to the increased scope of the nature of possible attacks more
sophisticated methods to understand the consequences and implications are
needed. Representation of different layers that these attacks could target is
a key factor in the wide-scale adaptation. The typical structure of the layers
in the Web3 application is presented on Figure 2.

###  3.1 Architecture of vulnerability detection and monitoring

The smart contracts approach will be employed in order for the nodes to be
able to cooperate in a way more elaborate than simple message exchanging.
Nodes will take part in the execution of smart contracts in a distributed and
integrity-preserving manner. The attack correlator is based on Web3-Blockchain
attacks to different layers as indicated in Figure 2. We use Convolutional
Neural Network (CNN) to detect various vulnerabilities in the application
layer and smart contracts; where one could use use artificial intelligence to
detect new vulnerabilities and even predict cyberattacks. In fact, BT threats
and vulnerabilities are classified into the following five categories:

  * •

Clients vulnerabilities

  * •

Consensus mechanism vulnerabilities

  * •

Mining pool vulnerabilities

  * •

Network vulnerabilities

  * •

Smart contract vulnerabilities

We aim to build certification on top of the Web3 technologies, for attack
detection, identification and mitigation. It focuses on specific layers,
Media, Wallet/Client, Application, and Smart Contract, where for each layer
specific components will be provided to ensure robust evidence capturing,
which thereafter is processed for identifying and predicting
cybersecurity/privacy threats and risks. The resulting information then
further goes through the cybersecurity decision tool-chain for automated
mitigation and awareness strategies. see Figure 3 for an illustration of
monitoring activity and attack detection, and attacks correlation subsystem
inputted by the vulnerabilities’ repository, where the user spans the media
and wallet layers.

Figure 2: Web3-blockchain attacks to different layers, and attacks correlator.

With the traditional App architecture design, every application has to set up
its own compatible servers for their own code execution. Additionally, such an
approach is also implying a possibility for a single point of failure in the
system. With the use of blockchain, each node (server, device etc.) on the
network replicates the necessary data for all nodes, making a whole system
more dynamic and reliable by putting up in front the true benefits of the
decentralization approach. We are benefiting from this concept by integrating
the adaptation of the blockchain architecture in order to maximize the data
security and integrity aspects of the proposed cybersecurity solution. Not
only it provides the novel cyber security tool, but also will have an
integrated secure mechanism to detect the most modern attacks by
decentralizing its core decision making engine.

Figure 3: Monitoring activity and detection of attacks.

In order to generate smart certificates for securing the Web3 apps against
cyberattacks, the vulnerability scanning tool (as shown in Figure 3) for
securing the chain component will be integrated into our solution. The
resulting framework’s supplementary component will be efficient and resilient
to attacks or malfunctions. The attack correlation component integrates 1)
(social) media monitoring, 2) wallet monitoring, and 3) attacks’ prediction
which is based on vulnerabilities’ repository inputted from application and
smart contract layer. The architecture described in Figure 3 offers a
comprehensive solution for monitoring and detecting cyberattacks on Web3
applications. By integrating various monitoring tools, utilizing AI for
enhanced threat prediction, and leveraging the benefits of blockchain, the
system provides a robust and user-friendly approach to cybersecurity, which
contains:

1\. Vulnerability Scanning Tool:  This tool is integrated into the solution to
secure the chain component. Its primary function is to scan for potential
vulnerabilities within the Web3 applications. By identifying these
vulnerabilities, the system can take proactive measures to address them before
they are exploited.

2\. Attack Correlation Component:  This component is central to the
architecture and integrates several monitoring mechanisms:

  * •

Social Media Monitoring: This monitors (social) media connected components for
potential threats related to vulnerabilities that might affect the Web3
applications.

  * •

Wallet Monitoring: Given the decentralized nature of blockchain, wallet
transactions and activities are monitored to detect any unusual patterns or
security breaches.

  * •

Attacks’ Prediction: This is based on a repository of known vulnerabilities
from the application and smart contract layer. By analyzing past
vulnerabilities and current system states, the system can predict potential
future attacks.

3\. Data Flow:  The vulnerability scanning tool feeds its findings into the
attack correlation component. The data from social media monitoring, wallet
monitoring, and the vulnerabilities’ repository are all processed to predict
potential attacks.

4\. AI Integration:  The system employs artificial intelligence to enhance its
prediction capabilities. By analyzing the data from various sources, the AI
can determine patterns and relationships that might not be immediately
apparent. This allows for a more accurate prediction of potential threats.

5\. Real-time Detection:  One of the primary objectives of the architecture is
to detect threats in real-time. By continuously monitoring various data
sources and using AI to analyze this data, the system can quickly identify and
respond to threats as they emerge.

6\. Blockchain Integration:  The decentralized nature of blockchain is
leveraged to enhance the security of the system. By distributing the decision
rules (smart contracts) across all nodes in the network, the system becomes
more dynamic and resilient. This decentralization ensures that even if one
node is compromised, the overall system remains secure.

7\. User-Centric Approach:  The enduser, whether human or IoT device, is at
the core of the proposed solution. The system is designed to be unobtrusive,
only intervening when necessary. This ensures that the user experience is not
disrupted while still maintaining a high level of security.

###  3.2 Usecases

Here are some hypothetical use cases that demonstrate the practicality and
applicability of the architecture:

Usecase 1: Social Media Threat Detection
Scenario:  An employee on the browser with a running Web3 application is
connected to a social media platform with a discovered vulnerability. This is
picked up by the Social Media Monitoring component.
How the Architecture Responds:  The system’s AI analyzes and determines the
severity of the threat. The vulnerability scanning tool checks if the Web3
application in question is vulnerable to the discovered vulnerability. If a
potential threat is detected, the system alerts the application’s security via
the smart certificate and recommends mitigation steps.

Usecase 2: Suspicious Wallet Activity
Scenario:  A user’s wallet starts making multiple transactions to unknown
addresses within a short period, which is unusual for this user.
How the Architecture Responds:  The Wallet Monitoring component detects this
unusual pattern. The AI analyzes past transactions from this wallet and
confirms that this behavior is out of ordinary. The smart certificate then
temporarily freezes the wallet’s transactions and sends an alert to the user,
asking them to verify the transactions.

Usecase 3: Predictive Attack Prevention
Scenario:  The Attacks’ Prediction component, using data from the
vulnerabilities’ repository and current system states, predicts a potential
DDoS attack on a Web3 application.
How the Architecture Responds:  The system proactively scales up its resources
to handle the increased traffic. It could also deploy additional security
measures, such as rate limiting and IP filtering, to mitigate the effects of
the attack. When the attack occurs, the system is prepared and can handle the
increased load without significant disruption.

Usecase 4: Real-time Smart Contract Breach
Scenario:  A smart contract on a decentralized application is executing
transactions that are draining funds from user accounts.
How the Architecture Responds:  The real-time detection component identifies
the unusual smart contract behavior. The AI analyzes the smart contract’s code
and identifies a potential vulnerability being exploited. The smart
certificate then halts the smart contract’s operations and alerts the
developers with details about the breach and the suspected vulnerability.

Usecase 5: Regulatory Compliance Check
Scenario:  A financial institution using a Web3 application needs to ensure
that all its transactions are compliant with GDPR.
How the Architecture Responds:  The blockchain integration component, with its
decentralized decision rules, ensures that all transactions are GDPR
compliant. If a non-compliant transaction is detected, it’s flagged, and the
institution is alerted. The system also provides detailed logs and reports
that the institution can use during regulatory audits.

###  3.3 Why smart certificates ?

Smart certificates can embed programmable logic, allowing them to
automatically execute or validate certain conditions without manual
intervention. This can be particularly useful for automating security and
compliance checks. Web3 Application (User Interface) provides a user interface
that allows users to interact with the smart certificate system. Users can
issue, verify, and manage certificates using this interface.

Figure 4: Architecture of smart certificates for Web3 application.

In this architecture, Figure 4, when an issuer issues a smart certificate
through Smart Contract 1, the certificate metadata (e.g., recipient’s name,
issuer’s name, date of issuance) and the cryptographic hash of the certificate
document are recorded on the blockchain. Recipients or third parties can then
verify the certificate’s authenticity by checking the hash on Smart Contract
2. If a certificate needs to be revoked, Smart Contract 3 handles the
revocation process. Overall, this architecture enables a secure, transparent,
and decentralized approach to certificate management, leveraging the benefits
of blockchain technology and smart contract for Web3 applications.

The full mathematical formulas for smart certificates in Web3 applications
involve various cryptographic operations and algorithms. Here, we’ll outline
the main formulas used in the issuance, verification, and revocation of smart
certificates:

1\. Certificate Issuance: Smart Contract 1 (Certificate Issuance): This smart
contract handles the process of issuing smart certificates. Issuers interact
with this contract to provide the necessary information and credentials for
certificate issuance.

  * •

Define the smart certificate data structure:

$\displaystyle\text{Certificate}:$ $\displaystyle\\{\text{ID, Recipient's
Name, Issuer's}$ (1) $\displaystyle\text{Name, Metadata, ...}\\}$

  * •

Generate a digital signature using the issuer’s private key (SKi) for the
certificate document (d) hash:

$\text{Signature}:\text{Sigi}=\text{Sign}(\text{SKi},\text{Hash}(d))$ (2)

  * •

Store the certificate metadata and digital signature on the blockchain:

$\displaystyle\text{Certificate On-Chain Data}:\\{\text{ID, Recipient's}$ (3)
$\displaystyle\text{Name, Issuer's Name, Metadata, Signature}\\}$

2\. Certificate verification: Smart Contract 2 (Certificate Verification):
This smart contract is responsible for verifying the authenticity and validity
of a smart certificate. Recipients or third parties can interact with this
contract to check the cryptographic hash of the certificate stored on the
blockchain for verification.

  * •

Retrieve the certificate from the blockchain with its on-chain data.

  * •

Verify the digital signature using the issuer’s public key (PKi) and the
certificate document (d) hash:

$\text{Verification}:\text{Verify}(\text{PKi},\text{Hash}(d),\text{Sigi})$ (4)

3\. Certificate revocation: Smart Contract 3 (Certificate Revocation): This
smart contract manages the revocation mechanism for smart certificates. If a
certificate needs to be invalidated (e.g., due to fraud or expiration), the
revocation information is recorded on the blockchain using this contract.

  * •

Define a revocation status (Revoked/Valid) for each certificate.

  * •

If a certificate needs to be revoked, update its status to ’Revoked’ on the
blockchain.

4\. Merkle Tree Implementation (optional):

  * •

Construct a Merkle tree with the hashes of multiple certificate documents
($\texttt{H}(d_{1})$, $\texttt{H}(d_{2})$, …, $\texttt{H}(d_{n})$).

  * •

Calculate the Merkle root (MRoot) from the parent nodes’ hashes
($\texttt{H}(P_{1})$, $\texttt{H}(P_{2})$, …, $\texttt{H}(P_{n-1})$).

5\. Zero-Knowledge Proofs:

  * •

Implement zero-knowledge proofs for scenarios where certain information needs
to be proven without revealing the actual information. For example, proving
possession of the private key without revealing the key itself.

6\. Blockchain Transactions:

  * •

Represent transactions as signed data packets that include the certificate
data and issuer’s digital signature:

$\text{Transaction}:\\{\text{Certificate, Signature}\\}$ (5)

By applying these concepts, Web3 applications can leverage smart certificates
for secure, tamper-proof certificate management. The use of cryptographic
operations ensures the authenticity of certificates, while the decentralized
nature of the blockchain ensures transparency and trust in the certificate
issuance and verification process. Additional techniques like Merkle trees and
zero-knowledge proofs can enhance efficiency and privacy, respectively, in the
handling of smart certificates on the blockchain.

###  3.4 Implementation of smart certificates for Web3

Implementing smart certificates for Web3 applications involves a combination
of blockchain development, smart contract programming, and cryptographic
operations. Here’s a high-level overview of the steps in the implementation:

  * •

Blockchain Platform: Select a suitable blockchain platform that supports smart
contract functionality. Ethereum is a popular choice for Web3 applications due
to its robustness and support for smart contracts.

  * •

Smart Certificate Data Structure: Determine the data structure of the smart
certificate, including fields such as certificate ID, recipient’s name,
issuer’s name, certificate metadata, and other relevant information.

  * •

Smart Contract Development: Write smart contracts to handle the issuance,
verification, and revocation of smart certificates. Create separate contracts
for each functionality, such as a certificate issuance contract, a
verification contract, and a revocation contract.

  * •

Test the smart contracts and user interface to ensure their correctness and
security. Deploy the smart contracts to the chosen blockchain network, make
them accessible to users. Monitor the system for any potential issues or
vulnerabilities. Regularly update and improve the smart contract code and user
interface as needed. It is essential to follow best practices and conduct
thorough testing to ensure the security and reliability of the smart
certificate system.

Let’s create a step-by-step example of implementing a smart certificate for a
financial decentralized application (DApp). In this example, we’ll create a
simple ”Certificate of Deposit” smart certificate using the Ethereum
blockchain.

Step 1: Set Up the Environment

Before we begin, we make sure to have the following:

  * •

Ethereum wallet (e.g., MetaMask) for interacting with the DApp.

  * •

Ethereum development environment (e.g., Truffle and Ganache) for smart
contract deployment.

  * •

A code editor for writing Solidity and web application code (e.g., Visual
Studio Code).

Step 2: Define the Smart Contract, Compile and Deploy it

Write a Solidity smart contract to define the Certificate of Deposit in
decentralized exchange (DEX), see Listing 1. This contract will include
functions for issuance, verification, and revocation of certificates. The
algorithm is given in Algorithm 1.

In a DEX context, this CD smart contract can be integrated to offer users the
ability to issue, verify, and potentially trade CD tokens representing
ownership of certificates. Here’s how it can be used:

Users can interact with the DEX interface to issue new CD certificates by
specifying the deposit amount and maturity date. The DEX can provide a
verification feature that allows users to check the validity of CD
certificates before trading them. Users can enter a certificate ID to verify
its authenticity. CD tokens can be represented as fungible tokens (e.g.,
ERC-20 tokens) that users can trade on the DEX. These tokens can represent
ownership of CD certificates. Certificate owners can revoke their certificates
if needed. This feature ensures that owners maintain control over their
certificates’ validity. The DEX can integrate this smart contract into its
user interface, enabling users to issue, verify, and manage CD certificates
seamlessly.

To enhance the security of the smart certificate for use in Web3 applications
like a decentralized exchange (DEX), one can implement vulnerability and
anomaly detection functions, as shown in Figure 2 and Figure 3. These
functions can help identify and respond to potential security threats or
unusual activities.

Listing 1: Smart contract to define the Certificate of Deposit (CD).
---
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract CertificateOfDeposit {
struct Certificate {
uint256 id;
address owner;
uint256 depositAmount;
uint256 maturityDate;
bool isRevoked;
}
Certificate[] public certificates;
uint256 public nextCertificateId;
event CertificateIssued(uint256 indexed id, address indexed owner, uint256
depositAmount, uint256 maturityDate);
event CertificateRevoked(uint256 indexed id); }
function issueCertificate(uint256 depositAmount, uint256 maturityDate)
external {
require(maturityDate > block.timestamp, ”Maturity date must be in the
future.”);
require(depositAmount > 0, ”Deposit amount must be greater than 0.”);
certificates.push(Certificate(nextCertificateId, msg.sender, depositAmount,
maturityDate, false));
nextCertificateId++;
emit CertificateIssued(nextCertificateId - 1, msg.sender, depositAmount,
maturityDate);
}
function verifyCertificate(uint256 certificateId) external view returns (bool)
{
require(certificateId < certificates.length, ”Certificate does not exist.”);
Certificate storage certificate = certificates[certificateId];
return !certificate.isRevoked && certificate.maturityDate ¡= block.timestamp;
function revokeCertificate(uint256 certificateId) external {
require(certificateId ¡ certificates.length, ”Certificate does not exist.”);
Certificate storage certificate = certificates[certificateId];
require(certificate.owner == msg.sender, ”Only the owner can revoke the
certificate.”);
require(!certificate.isRevoked, ”Certificate is already revoked.”);
certificate.isRevoked = true;
emit CertificateRevoked(certificateId);
}
}

For an extended version of the smart contract that includes anomaly detection,
see Listing 2. Keep in mind that integrating machine learning with smart
contracts involves additional complexities, such as securing the communication
between the contract and the model server and managing off-chain data. In this
example:

  * •

We assume that an external machine learning model is deployed and accessible
at the mlModelServer address.

  * •

The detectAnomaly function sends a request to the machine learning model’s
$/detect_{a}nomaly$ endpoint with the description and certificateId as inputs.

  * •

If the machine learning model responds with ”Anomaly,” the certificate is
marked as an anomaly, and an event is emitted.

  * •

Note that this example uses an external HTTP client library (HttpClient) to
make requests to the machine learning model.

Listing 2: Smart contract to detect vulnerability and anomaly.
---
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
// Import an Ethereum-compatible HTTP library
import<EMAIL_ADDRESS>
contract CertificateOfDeposit {
using HttpClient for HttpClient.Request;
using HttpClient for HttpClient.Response;
struct Certificate {
uint256 id;
address owner;
uint256 depositAmount;
uint256 maturityDate;
bool isRevoked;
bool isAnomaly; // Flag to detect anomalies
}
// Address of the external machine learning model server
address public mlModelServer;
// Event to log anomaly detection
event AnomalyDetected(uint256 indexed certificateId, string description);
constructor(address _mlModelServer) {
mlModelServer = _mlModelServer;
}
function detectAnomaly(uint256 certificateId, string memory description)
external {
require(certificateId ¡ certificates.length, ”Certificate does not exist.”);
Certificate storage certificate = certificates[certificateId];
require(certificate.owner == msg.sender, ”Only the owner can detect
anomalies.”);
require(!certificate.isRevoked, ”Certificate is revoked and cannot have
anomalies.”);
// Make an external request to the machine learning model for anomaly
detection
string memory mlEndpoint = ”/detect_anomaly”;
string memory requestBody = string (abi.encodePacked(description, ”,”,
uintToString (certificateId)));
HttpClient.Request memory request = HttpClient.createRequest(”POST”,
mlModelServer, mlEndpoint, requestBody);
HttpClient.Response memory response = HttpClient.send(request);
// Check the response from the machine learning model
require(response.statusCode == 200, ”Machine learning model error”);
require(response.body.equals(”Anomaly”), ”Not detected as an anomaly”);
// Mark the certificate as an anomaly
certificate.isAnomaly = true;
// Emit an event to log the detection of the anomaly
emit AnomalyDetected(certificateId, description);
}
// Utility function to convert uint to string
function uintToString(uint256 value) internal pure returns (string memory) {
}
}

Anomaly Detection Functions: This contract is integrated into the smart
certificate “CertificateOfDeposit” to provide security features.
The field isAnomaly is added to the Certificate struct to mark certificates
that have anomalies.
We introduce an AnomalyDetected event to log anomalies detected in
certificates. This event can provide a description of the anomaly.
detectAnomaly Function allows certificate owners to detect anomalies and mark
their certificates accordingly. It requires a certificate ID and a description
of the anomaly.
These anomaly detection features enhance the security of the smart certificate
system and allow users to take action in response to potential security
threats or unusual activities in their certificates. The contract marks the
certificate with the isAnomaly flag, preventing further verification of that
certificate. The AnomalyDetected event logs the anomaly’s details for auditing
and investigation.

###  3.5 Certificate transparency

Certificate Transparency (CT), see reference [19], is crucial for enhancing
the security and trustworthiness of the Internet’s Public Key Infrastructure
(PKI). It aids in detecting misissued certificates, whether due to errors,
compromises, or malfeasance by Certificate Authorities (CAs). CT helps prevent
Man-in-the-Middle (MITM) attacks by making it difficult for fraudulent
certificates to go unnoticed, thereby increasing the accountability of CAs and
enhancing user trust in web communications. The public logging of certificates
allows for rapid response to security incidents and democratizes the oversight
of certificate issuance. Researchers, security professionals, and the general
public can monitor and audit certificate issuance, maintaining the integrity
of the web’s security infrastructure. This broad oversight is essential in
safeguarding against cyber threats and ensuring the reliability of secure
internet communications, making CT a critical component in the modern web
ecosystem.
Integration of Certificate Transparency (CT) into the architecture of smart
certificates can be approached by focusing on the secure, transparent, and
decentralized management of certificates. The architecture overview includes:
Smart Contract 1, dedicated to Certificate Issuance, handles the process of
issuing smart certificates, where issuers are required to provide necessary
information and credentials. Smart Contract 2 focuses on Certificate
Verification, ensuring the authenticity and validity of smart certificates by
enabling recipients or third parties to check the cryptographic hash of the
certificate stored on the blockchain. Smart Contract 3 deals with Certificate
Revocation, managing the invalidation of certificates due to reasons such as
fraud or expiration, with all revocation information being recorded on the
blockchain. The Blockchain Network acts as the backbone of this system,
functioning as a distributed ledger that records all certificate-related
transactions and data, thereby guaranteeing transparency, immutability, and
decentralization in the certificate management system. Complementing these
components is the Web3 Application, which serves as a user interface, allowing
users to issue, verify, and manage their certificates seamlessly.
In Algorithm 1, we aim to explain in a graph structure the CT integration into
our smart certificate architecture.

Algorithm 1: Graph Structure for Certificate Transparency Integration.
---
Nodes:
\- Smart Certificate Issuance: Starting point for issuing a smart certificate.
\- Certificate Metadata & Hash Generation: Compiling metadata and generating
cryptographic hash.
\- Submission to CT Log: Submitting hash and metadata to a CT log.
\- Merkle Tree in CT Log: Storing certificate hashes in the log’s Merkle tree.
\- SCT Acquisition: Issuing a Signed Certificate Timestamp by the CT log.
\- Smart Contract Verification: Verifying the SCT and certificate’s presence
in the CT log.
\- Smart Contract Revocation: Managing updates and revocations of
certificates.
\- CT Monitors & Auditing: Continuous monitoring and auditing of CT logs.
\- User Agent & Browser Integration: Enforcing CT in browsers and user agents.
Edges:
1\. Smart Certificate Issuance $\rightarrow$ Certificate Metadata & Hash
Generation.
2\. Certificate Metadata & Hash Generation $\rightarrow$ Submission to CT Log.
3\. Submission to CT Log $\rightarrow$ Merkle Tree in CT Log and SCT
Acquisition.
4\. SCT Acquisition $\rightarrow$ Smart Contract Verification.
5\. Smart Contract Verification $\rightarrow$ Smart Contract Revocation.
6\. Merkle Tree in CT Log $\leftrightarrow$ CT Monitors & Auditing
(bidirectional).
7\. SCT Acquisition $\rightarrow$ User Agent & Browser Integration.

##  4 APPLICATION, POSSIBILITIES AND CHALLENGES

###  4.1 Possibilities of Smart Certificates for Web3 Applications

There is currently a lack of a common set of security standards that let Web3
app users rely on the common knowledge to detect malicious behavior; in
addition, entreprises do not feel safe when using Web3 applications possibly
facing with cyberattacks/intrusions also government audits. As an example, the
current browsers most people use today are not built to handle the complexity
of Web3. A fundamental yet unanswered question is how to assess the overall
safety of a given decentralized application (DApp); as we provide certificates
for the risks associated with enterprises using DApps. This includes checking
whether the DApps contain suspicious code. This check will help users to
assess whether DApp has been compromised or is connected to risky components.
In the context of decentralized financial paradigms, specific entities and
instruments are especially relevant, including:

  * •

Decentralized exchanges (DEXs): Allow users to trade cryptocurrencies directly
with each other, bypassing centralized intermediaries.

  * •

Lending and borrowing platforms: Enable users to earn interest on their crypto
assets or borrow funds using their crypto assets as collateral.

  * •

Stablecoins: Cryptocurrencies pegged to the value of a fiat currency or other
stable asset.

  * •

Tokenized securities: Digital tokens representing ownership in traditional
financial assets, such as stocks or bonds.

  * •

Insurance protocols: Decentralized insurance platforms that allow users to
purchase insurance coverage against various risks.

But, how Web3 security certificates are different from Web1 and Web2 ?

####  4.1.1 Web3 versus security certificates in Web1 and Web2:

Building the certificates includes bringing an extra layer of protection and
making sure to use proper encryption protocols. Developing secure blockchain-
based applications guidelines is a critical challenge that usually requires an
appropriate relationship between the architectural components of the
underlying domain and the Blockchain features in order to achieve optimal
usability at various levels, the security and privacy regulations to ensure
adequate user and industry partner compliance. Based on a decentralized
concept the security levels should be considered for the following
architectural principles (Hameed, 2022):

  * •

Fully Decentralized: Fully decentralized networks allow anyone to join as a
node and send transactions to other nodes without a trusted third party.

  * •

Partially Decentralized: In a partially decentralized network, some nodes are
allocated to monitor and administer network operations, while others may
participate like in a completely decentralized network. An example of a
partially decentralized network is a consortium blockchain.

  * •

Distributed Storage: Distributed storage is a requirement for any
decentralized architecture that emphasizes equality between P2P nodes to
validate and verify transactions stored in the database.

Considering the parallels to Web1 and Web2, the initial versions of SSL/TLS
had critical vulnerabilities. Security companies like Certik, Forta, Slither,
and Securify also provide code scanning and application security testing tools
that were originally developed for Web1 and Web2 applications. However, a
significant portion of the Web2 security model deals with response, and
mechanisms must be included to confirm transactions, which should take place
in the first place in Web3, since transactions cannot be modified after they
have been executed (see Dang 2022 [18]). Security must be extraordinarily
adept at prevention, which is why we are not just producing smart certificates
but also attack monitoring tools/components. In order to prevent new attack
vectors that target anything from cryptographic primitives to smart contract
flaws, we use vulnerability detection via the vulnerabilities database in the
application layer, wallet monitoring, and attack correlation.

####  4.1.2 Creation of smart certificates for enterprises:

To create smart certificates for enterprises, one would need to follow a
comprehensive process to ensure the certificates meet the highest security
standards. Here is an overview of the steps:

  * •

Develop a security plan: Based on the risk assessment, develop a comprehensive
security plan that outlines the security measures needed to protect the
enterprise from cyberthreats. The security plan should include vulnerability
detection procedures, regulatory policies’ procedures, and possibly the
incident response.

  * •

Decide on the information to include: outline all the output of attack
detection and correlation, and decide what to include in the smart contract in
order to build the digital smart certificates which are programmatically
enforced.

  * •

Use a digital certificate platform: To create smart certificates, we need to
use a digital certificate platform that allows us to create, issue, and manage
certificates.

  * •

Implement certificates: Once certificates are created, they should be
implemented across the enterprise’s network and systems. This may involve
installing certificates on servers, endpoints, and other devices to ensure
safety and control.

  * •

Monitor and update certificates: Cyberthreats and regulatory policies are
continually evolving, so it’s crucial to monitor and update certificates
regularly. This may involve reissuing certificates, revoking compromised
certificates, or updating certificates to address emerging threats.

###  4.2 Challenges of Smart Certificates for Web3 Applications

To realize the full potential of smart certificates for Web3 applications,
addressing these challenges is essential. Advancements in blockchain
scalability, user experience, privacy-preserving techniques, and
standardization efforts will play a significant role in making smart
certificates a transformative solution for certificate management in various
industries.

  * •

User Adoption: Educating and encouraging users to adopt blockchain-based smart
certificates might be challenging due to the unfamiliarity with Web3
applications and the need to manage private keys securely.

  * •

Scalability: The throughput and scalability limitations of certain blockchain
networks may hinder the smooth handling of a large number of certificate
transactions.

  * •

Interoperability with Traditional Systems: Integrating blockchain-based smart
certificates with existing centralized systems might require standardization
efforts and adjustments.

  * •

Key Management: Ensuring secure and user-friendly key management is crucial to
avoid loss of access to certificates or compromise of private keys.

  * •

Regulatory Compliance: Compliance with data protection and privacy
regulations, such as GDPR, may present challenges when dealing with personal
data on the blockchain.

There are also some specific concerns that we are working on to address in our
future study:
Question:  How are false positives of the models addressed?
Response:  False positives are a common concern in threat detection models. To
address this, one can employ a multi-tier validation system. Initially,
potential threats identified by the model undergo a secondary validation
process, which involves heuristic checks and pattern analysis. Additionally,
one needs to continuously train and fine-tune the models using feedback loops,
ensuring that the rate of false positives decreases over time. Regular audits
and manual reviews also play a crucial role in refining the model’s accuracy.
Question:  How is response time optimized with increased work of evidence
capturing and threat prediction time?
Response:  One needs to employ parallel processing and distributed computing
techniques to optimize response time. By processing evidence capturing and
threat prediction simultaneously across multiple nodes, one could ensure swift
response times. Additionally, by utilizing edge computing principles,
processing data closer to the data source further reduces latency.
Questions:  How is the centralized repo of vulnerabilities secured? How can
one address concerns about it being a potential giveaway to hackers?
Response:  The centralized repo could be secured using state-of-the-art
encryption techniques, multi-factor authentication, and strict access
controls. Additionally, the repo does not store explicit vulnerabilities but
rather signatures of vulnerabilities. This ensures that the data remains
unintelligible and unusable to potential hackers.
Question:  What could be a realistic collaboration method for forming the
centralized repo with many stakeholders in a decentralized network?
Response:  Collaboration could be facilitated through a consensus-driven
approach. Stakeholders can propose additions or modifications to the repo.
These proposals undergo a validation process where multiple nodes in the
network verify the authenticity and relevance of the proposed data. Once a
consensus is reached, the data is added to the repo. This method ensures
transparency, accuracy, and collective decision-making.
Question:  How could we address the implementation complexity in real-time,
especially considering layer-wise security?
Response: While layer-wise security does introduce complexity, the proposed
architecture is designed with modularity in mind. Each layer operates both
independently and in conjunction with other layers. By employing microservices
architecture and containerization, one could ensure that each component can be
updated, scaled, or modified without affecting the entire system. This modular
approach simplifies real-time implementation and allows for seamless
integration of security measures across layers.

##  5 CONCLUSION

A significant aspect of Web3 security relies on the ability of blockchains,
that are software-controlled distributed networks, to be resilient to human
intervention. Here, the space of humans could involve network defenders in the
form of builders, security teams, and Web3 application endusers. In order to
boost Web3 security, one must first categorize and profile different
cyberattack types particular to Web3 application environments. This profiling
task will drive the design of enterprise tools and frameworks to secure
digital infrastructures and applications built on top of Web3 technology.
The desired outcome of this study is a usability-friendly cybersecurity smart
certificate for Web3 applications. Such a certificate needs to incorporate
security by design features identifying major cyberthreats affecting Web3
security alongside their causes. The sources of these causes often reflect
security by design features that should necessarily be integral to technical
and managerial solution suites boosting Web3 application security. This
article focused on specific layers, Media, Wallet/Client, Application and
Smart Contract, where for each layer specific components are provided to
ensure robust evidence capturing, which thereafter is processed for
identifying and predicting cybersecurity threats and risks. According to Dang
(2022) [18], there are at least four bases that would advance preventative
Web3 security:

  * •

Source for vulnerabilities: There needs to be a source for known Web3
vulnerabilities such as National Vulnerability Database (NVD). In fact, Web3
needs a decentralized equivalent. For now, scattered information lives across
places such as SWC Registry, Rekt, Smart Contract Attack Vectors, and DeFi
Threat Matrix. Bug bounty programs such as those run by Immunefi.

  * •

Security decision-making standards: The decision-making model for critical
security design and individual incidents in Web3 is currently undefined. How
Decentralized Autonomous Organizations (DAOs), security professionals, and
service providers like Alchemy and Infura work together to tackle emerging
security challenges needs to be made clearer. There are useful lessons from
how huge open-source communities built processes and formed the OpenSSF and
CNCF advisory committees to address security issues.

  * •

Authentication: The majority of DApps, including the most well-known ones, do
not yet authenticate or sign their API responses. This means that there is a
gap in confirming that the response is coming from the intended app and that
the data hasn’t been altered in any way when a user’s wallet gets data from
these apps. Users must assess an app’s security trustworthiness in a world
where apps do not follow fundamental security best practices.

  * •

Easier key management: The Web3 paradigm’s user ability to transact is
supported by cryptographic keys. These keys are also hard to manage properly;
entire businesses continue to be built around managing keys. The complexity
involved with managing private keys is the primary consideration that drives
users to choose hosted wallets rather than non-custodial ones. Ideally,
further security innovation will provide users with better usability and
protections for such scenarios.

## References

  * [1] CBInsights. 2023. State of Blockchain 2022 Report. https://www.cbinsights.com/research/report/blockchain-trends-2022/
  * [2] CoinMarketCap. 2019. “Cryptocurrency market capitalizations—Coinmarketcap.” https://coinmarketcap.com/
  * [3] Chowdhury, M.J.M., Colman, A., Kabir, M.A., Han, J., Sarda, P. 2018. “Blockchain as a notarization service for data sharing with personal data store,” In: Trust-Com/BigDataSE IEEE, pp. 1330–1335.
  * [4] Berryhill, J. 2019. “New opsi guide to blockchain in the public sector—Observatory of public sector innovation observatory of public sector innovation.” https://oecd-opsi.org/new-opsi-guide-to-blockchain-in-the-public-sector
  * [5] Maleh, Y., Shojafar, M., Alazab M., and Romdhani, I. 2020. Blockchain for Cybersecurity and Privacy. First edition published by CRC Press.
  * [6] Natarajan, H., Krause, S.K., Gradstein, H.L. 2019. ”Distributed ledger technology (dlt) and blockchain.” https://documents.worldbank.org/curated/en/177911513714062215/distributed-ledger-technology-dlt-and-blockchain
  * [7] Luu, L., Chu, D.H., Olickel, H., Saxena, P., Hobor, A. 2016. “Making smart contracts smarter,” In: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. CCS’16, pp. 254–269.
  * [8] Taylor, P.J., Dargahi, T., Dehghantanha, A., Parizi, R.M., Choo, K.K.R. 2019. “A systematic literature review of blockchain cyber security,” Digital Communications and Networks.
  * [9] Omelchenko, D. 2019. “Litecoin experiencing dusting attack.” https://ihodl.com/topnews/2019-08-10/litecoin-experiencing-dusting-attack
  * [10] Chang, V., Baudier, P., Zhang, H., Xu, Q., Zhang, J., and Arami, M. 2020. “How Blockchain can impact financial services–The overview, challenges and recommendations from expert interviewees,” Technol. Forecast. Soc. Change (158), 120166.
  * [11] Hameed, K., Barika, M., Garg, S., Amin, M.B., Kang, B. 2022. “A taxonomy study on securing Blockchain-based Industrial applications: An overview, application perspectives, requirements, attacks, countermeasures, and open issues.”
  * [12] Wang, Y. and Kogan, A. 2018. “Designing confidentiality-preserving blockchain-based transaction processing systems,” Int. J. Account. Inf. Syst. (30), pp. 1–18.
  * [13] Zhong, L., Wu, Q, Xie, J., Li, J., and Qin, B. “A secure versatile light payment system based on blockchain,” Future Gener. Comput. Syst. (93), pp. 327–337.
  * [14] Behfar, S.K., ”Decentralized intelligence and bigdata analytics reciprocal relationship,” Proceeding of IEEE International Conference on Blockchain Computing and Applications (BCCA Kuwait 2023).
  * [15] Behfar, S.K., Théodoloz, F., Schranz, C, and Hosseinpour, M., ”Blockchain-based data sharing platform customization with on/off-chain data balancing,” Proceeding of IEEE International Conference on Blockchain Computing and Applications (BCCA Kuwait 2023).
  * [16] Su, L., Shen, X., Du, X., Liao, X., Wang, X., Xing, L., and Liu, B., ”Evil Under the Sun: Understanding and Discovering Attacks on Ethereum Decentralized Applications”, Published in USENIX Security Symposium 2021.
  * [17] Chen, J., Wang, Y., Zhou. Y., Ding, W., Tang, Y., Wang, X., and Li, K., ”Understanding the Security Risks of Decentralized Exchanges by Uncovering Unfair Trades in the Wild”, IEEE European Symposium on Security and Privacy (EuroS&P) 2023.
  * [18] Dang, W.L. 2022. “Securing Web3”. https://www.unusual.vc/post/securing-Web3.
  * [19] ”Certificate Transparency”. https://certificate.transparency.dev/howctworks/.


# Rate-Splitting Random Access Mechanism for Massive Machine Type
Communications in 5G Cellular Internet-of-Things

Yeduri Sreenivasa Reddy1, Garima Chopra2, Ankit Dubey3, Abhinav Kumar2,
Trilochan Panigrahi1,
and Linga Reddy Cenkeramaddi4 1Department of ECE, National Institute of
Technology Goa, Ponda, Goa 403401, India
2Department of EE, Indian Institute of Technology Hyderabad, Kandi,
Sangareddy, Telangana 502285, India
3Department of EE, Indian Institute of Technology Jammu, Jammu & Kashmir
181221, India
4Department of ICT, University of Agder, Grimstad-4879, Norway
Email<EMAIL_ADDRESS><EMAIL_ADDRESS>
<EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract

The cellular Internet-of-Things has resulted in the deployment of millions of
machine-type communication (MTC) devices. These massive number of devices must
communicate with a single gNodeB (gNB) via the random access channel (RACH)
mechanism. However, existing RACH mechanisms are inefficient when dealing with
such large number of devices. To address this issue, we propose the rate-
splitting random access (RSRA) mechanism, which uses rate splitting and
decoding in rate-splitting multiple access (RSMA) to improve RACH success
rates. The proposed mechanism divides the message into common and private
messages and enhances the decoding performance. We demonstrate, using
extensive simulations, that the proposed RSRA mechanism significantly improves
the success rate of MTC in cellular IoT networks. We also evaluate the
performance of the proposed mechanism with increasing number of devices and
received power difference.

Keywords– Cellular Internet-of-Things, gNodeB, machine type communications
(MTC), random access channel, rate-splitting multiple access, received power.

##  I INTRODUCTION

The cellular Internet-of-Things (C-IoT) has transformed wireless
communications from human-centric to human-independent. According to an IHS
Markit report [1], this will result in the deployment of approximately 125
billion smart devices by 2030. Human-centric communication is also called as
human-to-human communication, and it is primarily intended for voice or video
calls, web browsing etc. [2]. Machine type communications (MTC), on the other
hand, which is human independent communication, is designed to support
millions of devices, energy efficiency, and so on [3].

Since the MTC devices have to be energy efficient, each device wakes up to
transmit the collected data and then returns to sleep. However, in order for
information to be exchanged, the device must be connected to a gNodeB (gNB). A
random access channel (RACH) mechanism is the mechanism by which a device
transitions from a radio resource control (RRC)-idle state to an RRC-connected
state. 3rd generation partnership project (3GPP) has proposed an long-term
evolution (LTE) RACH mechanism based on four message exchanges [4]. To reduce
the latency and control-signaling overhead of LTE RACH, 3GPP has proposed a
new RACH mechanism for 5G known as early data transmission (EDT), in which
there is only two message exchange between each device and gNB, as shown in
Fig. 1 [5].

Figure 1: RACH message exchange for 5G.

In EDT, similar to the LTE RACH, the gNB broadcasts system information block
(SIB)-2 message to all the devices under its coverage. All the devices with a
packet to transmit reads the SIB-2. Here, SIB-2 indicates the preamble group
to be used and configuration of preamble to resources for msg-3. After
successful decoding of SIB-2, the device starts the RACH mechanism by
transmitting message (msg)-A, which is a combination of preamble msg-1 and RRC
connection request (data or device identity) msg-3 to the gNB. After
successful reception of msg-A, gNB responds with msg-B, which is the
combination of RA message msg-2 and RRC Contention resolution msg-4. The
messages from msg-1 to msg-4 are same as defined for LTE RACH. There are three
types of responses possible from the gNB to an MTC device based on the type of
message received. The first one is no response due to the failure in receiving
msg-A. In this case, the device takes a backoff and starts either two message
exchange or falls back to four message exchange of LTE. The second one is the
successful reception of msg-1 but, failure to decode msg-3. In this case, the
gNB responds with msg-2 (RA response) of four message exchange to indicate the
PUSCH for retransmission of msg-3 of msg-A. Then, the gNB responds with msg-4
of msg-B. The third one is the successful reception of both the messages of
msg-A. In this case, the gNB responds with msg-B (msg-2+msg-4) that indicates
the contention resolution ID. Successful reception of msg-B indicates
successful RACH [5].

The two-phase cluster-based group paging scheme was proposed in [6] to handle
massive MTCs simultaneous channel access and overcome the limitations of the
3GPP. As a result of the large number of connection requests, congestion is a
major limiting factor. Extended access barring (EAB) has been proposed as a
connection control mechanism in 3GPP specifications. The EAB has been studied
in [7] and two improved EAB schemes have been proposed. Similarly, [8] has
proposed a distribution method based on non-orthogonal multiple access (NOMA)
and Q-learning to dynamically allocate random access slots and handle massive
MTC networks. The orthogonal sequences generated from both Gaussian
distribution and the Zadoff-Chu (ZC) have been studied and analyzed for
asymptotic behavior for success probabilities using NOMA, and the closed-form
expression has been derived in [9]. A Markov chain-based access barring
(M-ACB) to reduce congestion of both delay-tolerant devices and delay-
sensitive devices to properly utilize network resources has been studied in
[10]. A distributive approach has been proposed in [11] to estimate the
optimal back-off parameters according to precise interpretations of the
observed statistics. With such a large number of MTC devices, resource
allocation complicates the concern even more. To manage resources among MTC
devices, a scheme has been proposed in [12] to dynamically prioritise the MTC
devices.

In [13], the authors have proposed a non-orthogonal random access (NORA)
mechanism that utilizes intra-slot SIC to decode the msg-3 of collided
devices. In this mechanism, the gNB can successfully decode the msg-3 of two
collided devices if the time in their msg-3 arrival is greater than a
threshold. A successive interference cancellation (SIC)-based RACH mechanism
has been proposed in [14] that utilizes repetition at the device side and
inter-slot SIC at the gNB. Moreover, a SIC-NORA mechanism has been proposed in
[15] that utilizes both intra-slot and inter-slot SIC at gNB to further
enhance the number of successful devices. However, the mechanisms in [14, 15]
increases the network congestion and energy consumption due to the repetitions
of msg-3.

Recently, RSMA has gained a lot of attention due to its robust transmission
and general framework in comparison to NOMA and space division multiple access
(SDMA). It has been shown in [16] that RSMA significantly improves the
achievable data rate in comparison to NOMA and SDMA. Several existing works
focus on downlink and uplink transmission [16, 17, 18, 19, 20, 21]. However,
RSMA can improve the quality of service and spectral efficiency for downlink
transmission under the perfect channel state information of transmitter (CSIT)
[20, 22] or imperfect CSIT. In RSMA, each user’s message to be transmitted is
split into two sub-messages such as the common and private message. The sub-
messages of different users are then super positioned and transmitted to the
receiver. Further, the receiver decodes the respective sub-messages by
applying SIC. However, RSMA faces few challenges during implementation [22].
Firstly, the decoding order of sub-messages needs to be carefully designed.
Secondly, resource management for transmission of messages. Several works
study the downlink RSMA. However, only a few existing works concentrate on
uplink RSMA for performance improvement [21]. Further, the RACH mechanism has
not been studied with RSMA. Motivated by this, we propose rate-splitting
random access (RSRA) mechanism in this work. In the proposed mechanism, the
MTC devices with the same preamble use the same resource for msg-3
transmission. On the other hand, the gNB decodes the preamble first, and then
it applies SIC to decode the rest of sub-messages from msg-3 of each device
based on the received power. This will enhance the number of devices that are
getting success in each time slot. The key contributions of this work are as
follows:

  * •

We propose a novel RSMA based RACH mechanism named as the RSRA mechanism for
MTC in 5G.

  * •

We present numerical results to obtain the number of contending devices and
the corresponding successful devices in each time slot.

  * •

We discuss the effect of increasing number of MTC devices on the performance
of the proposed mechanism.

  * •

We present simulation results that demonstrate the impact of the received
power difference between the msg-3 of collided devices on the performance of
the proposed RSRA mechanism.

  * •

We present numerical results comparing the proposed mechanism’s performance to
that of state-of-the-art RACH mechanisms.

The remainder of the paper is framed as follows: In Section II, we discuss the
system model and the proposed RSRA mechanism. Through extensive simulation
results, the performance of the proposed mechanism is evaluated in Section
III. Finally, Section IV provides the conclusion along with possible future
work.

Figure 2: System model.

##  II SYSTEM MODEL

We consider a C-IoT scenario wherein, $M$ devices namely $J_{i}$ $\forall$
$i\in\\{1,2,\cdots,M\\}$ deployed randomly under the coverage of a single gNB
$b$. These MTC devices are in either of the four states as shown in Fig. 2
[14]. Devices with no data to transmit remain in the sleep state. The device
with a packet to transmit wake up and competes for radio frame for the
initiation of RACH mechanism. The device in the radio frame competes for RACH
success. All MTC devices that have successfully completed RACH transmit data
using a hybrid automatic repeat request.

1

Input: $P$

Output: RACH success

2 if  _There is data_ then

3 Uniformly generate a number $n$ from $[0,1]$ ;

4 if  _$n <P$_ then

5 Select a time slot from the set $\\{1,2,\cdots,T\\}$ uniformly at random ;

6 Wait for the transmission slot ;

7 Select a preamble from the set $\\{0,1,\cdots,K\\}$ uniformly;

8 Start RACH mechanism by transmitting the preamble followed by msg-3;

9

10 if  _RACH success_ then

11 Go to Step 1;

12

13 else if  _There is a collision in msg-3_ then

14 Sort the $P_{R}$ of msg-3 of all the collided devices in descending order;

15 while  _The difference in $P_{R}$ of two devices in the descending order
set is greater than $\Delta P$_ do

16 RACH success with SIC;

17 Go to Step 1;

18

19 end while

20

21 else

22 Wait for the current radio frame to finish and go to Step 1;

23

24 end if

25

26 else

27 Wait for the current radio frame to finish and go to Step 1;

28

29 end if

30

31else

32 Wait for the current radio frame to finish and go to Step 1;

33

34 end if

35

Algorithm 1 Proposed RSRA algorithm.

###  II-A RSRA coding and decoding operation

The proposed RSRA coding and decoding operation is described in Fig. 2. Each
MTC device transmits the encoded msg-A consisting of a preamble and an RRC
connection request as signals $s_{k}^{c}$ and $s_{k}^{p}$, respectively. In
particular, $s_{k}^{c}$ and $s_{k}^{p}$ represent the common signal and
private signal of the $k$th device. On the other end, the gNB responds with
msg-B, which is the random access response message followed by contention
resolution message, after successfully decoding the msg-A. In case only one
device selects a given preamble, the gNB can successfully decodes msg-A and
responds with msg-B to all such devices. If more than one device select a
given preamble, they use the same resource to transmit msg-3 that leads to
collision in msg-3. To all such messages, the gNB applies the RSRA decoding
mechanism to successfully decode msg-3. The decoding operation is performed in
a series of steps. The RSRA decoding order for two users $J_{m}$ and $J_{n}$
is shown in Fig. 2. Because both devices have selected and transmitted the
same preamble, first part of the msg-A ($s_{k}^{c}$) can be decoded at gNB.
Thereafter, gNB sequentially decodes, the second part of the msg-A
($s_{K}^{p}$) based on their received powers for $k=m$ and $k=n$. This
procedure is repeated until all collided devices’ msg-3 have been successfully
decoded.

###  II-B Proposed RSRA Mechanism

Similar to 3GPP EAB mechanism, in the proposed mechanism, the gNB broadcasts
SIB-2 message that indicates the configuration information of preamble and
msg-3 and access barring parameter $P$ as given in Algo. 1.

Each MTC device generates $n$ uniformly from $[0,1]$ upon successful reception
of SIB-2. An MTC device with $n<P$ enters into a radio frame by selecting a
time slot uniformly from $\\{1,2,\cdots,T\\}$. A device that has selected a
time slot $t$, waits for $t-1$ time slots and transmits its msg-A, which is
concatenation of a preamble followed by msg-3 after a guard band. Here,
preambles are chosen from the set $\\{1,2,\cdots,K\\}$. As stated earlier, the
preamble and the msg-3 are transmitted using signals $s_{k}^{c}$ and
$s_{k}^{p}$, respectively, each with a transmit power of $P_{T}$.

On the other end, gNB can decode the msg-3 of a device in case it alone
chooses a given preamble. Since the resources for msg-3 transmission are
configured to each preamble, the device alone transmits the msg-3. In case a
given preamble is chosen by two or more devices, they get the same resource
for msg-3 transmission. This leads to a collision. However, with RSRA
mechanism, the gNB may decode the msg-3 of such collided devices using SIC as
given in Algo. 1. The gNB starts the decoding of msg-3 based on the difference
in the powers of to msg-3s. In case the difference of a msg-3 of a device with
highest received power and the msg-3 of another device with second highest
received power is more than $\Delta P$, the gNB can successfully decode msg-3
of the device with highest received power [21]. This process repeats until
either all devices are decoded or till the difference in power levels is
greater than $\Delta P$ as given in Algo. 1. The derivation of the expression
for $P_{R}$ is discussed in the following section.

###  II-C Received Power Calculation

The expression of received power, $P_{R}$, (in dB) is given as [23]

$\displaystyle P_{R}=P_{T}-PL\,,$ (1)

where, $P_{T}$ (in dB) denotes the transmitted power at device and $PL$ (in
dB) denotes the propagation/path loss. Propagation loss is defined as the
amount of power loss in the channel for transmission. For the calculation of
pathloss, we consider Okumura-Hata model in this paper [24]. The expression
for pathloss in an urban environment is obtained as

$\displaystyle PL(dB)=A_{1}+A_{2}\log_{10}(r),$ (2)

where, $r$ denote the distance of the device from the gNB. The expressions for
$A_{1}$ and $A_{2}$ are obtained as

$\displaystyle A_{1}=$ $\displaystyle
69.55+26.16\log_{10}(f_{M})-13.82\log_{10}(h_{g})$
$\displaystyle-(1.1\log_{10}(f_{M})-0.7)h_{d}\,,$ (3) $\displaystyle A_{2}=$
$\displaystyle 44.9-6.55\log_{10}(h_{g}),$ (4)

where, $h_{g}$ and $h_{d}$ denote the gNB height and device height in m,
respectively, and $f_{M}$ is the operating frequency in MHz.

(a)

(b)

Figure 3: The performance comparison of the proposed mechanism with the
existing mechanisms in terms of (a) average number of contending devices and
(b) average number of successful devices in a time slot for $T=1482$, $K=54$,
$P=0.9$, and $\Delta P=7$ dB.

##  III NUMERICAL RESULTS

We present the simulation results to compare the performance of the proposed
mechanism with the state-of-the-art mechanisms in this section. Further, we
compare the performance with increasing number of RACH accesses. Finally, we
evaluate the effect of $\Delta P$.

We consider a scenario of C-IoT with $M=2\times 10^{5}$ MTC devices uniformly
deployed in a circular area of $2$ KM radius. As per the 3GPP standards, we
consider $T=1482$, $K=54$ , $P_{T}=24$ dBm, $f_{M}=1500$ MHz, $h_{g}=30$ m,
and $h_{d}=1.5$ m [4, 24].

Figs. 3a and 3b show the number of contending devices and the corresponding
successful devices in a time slot for all the mechanisms considered in this
paper. From Fig. 3, it is observed that there is an average of $69$ devices
contends in a time slot which then results in an average of $26$ successes
with NORA mechanism. Further, there are an average of $61$ contending devices
in a time slot which then results on an average of $33$ successes with the
SIC-based RACH mechanism. Moreover, the SIC-NORA mechanism allows an average
of $92$ contending devices and result in an average of $43$ successful
devices. Finally, we observe that the proposed mechanism allows an average of
$87$ contending devices which results in an average of $43$ successes. Even
though the maximum number of RACH successes with the proposed mechanism is
same as SIC-NORA mechanism, the proposed mechanism reduces the network
congestion and energy consumption in comparison to SIC-NORA mechanism due to
single transmission.

Fig. 4 shows the number of successful devices with increasing value of $\Delta
P$ for the proposed RSRA mechanism with $1.45\times 10^{5}$ contending
devices. Here, we varied $\Delta P$ from $0$ dB to $50$ dB. From Fig. 4, it is
observed that the proposed RSRA mechanism can decode all the devices in a
perfect ideal scenario, i.e. $\Delta P=0$ dB. However, it is not possible in
practice. We consider the ideal case for a fair analysis of the degradation of
success rate with increasing $\Delta P$. It is observed that the number of
successful devices reduces exponentially with increasing value of $\Delta P$.
Thus, we conclude that the receiver design place a crucial role in enhancing
the number of successful devices.

Figure 4: Number of RACH successes in a radio frame vs $\Delta P$ (in dB) for
the proposed RSRA mechanism with $P=1$, $T=1482$, and $k=54$. Figure 5:
Average number of successful devices in a radio frame with $T=1482$, $k=54$,
$P=1$, and $\Delta P=7$ dB.

Fig. 5 shows the variation of number of RACH successes with increasing number
of contending devices for all the mechanisms considered in this work. It is
observed from Fig. 5 that there is a maximum of $5.19\times 10^{4}$ successes
with the proposed mechanism. Further, it is observed that NORA mechanism, SIC-
based RACH mechanism, and SIC-NORA mechanism results in a maximum of
$3.82\times 10^{4}$, $4.19\times 10^{4}$, and $5\times 10^{4}$ successes,
respectively. Thus, it is concluded that the proposed RSRA mechanism
outperform other mechanisms in terms of number of successful devices. Even
though the performance of the proposed mechanism is comparable to SIC-NORA
mechanism, the energy consumption of the proposed mechanism is less as there
is no repetition rate.

##  IV CONCLUSION

A rate-splitting random access mechanism has been proposed in this paper to
improve the number of successful devices for cellular Internet-of-Things. The
MTC devices can transmit msg-A in a randomly selected time slot under the
proposed mechanism. Following that, the gNB can decode the msg-3 of multiple
collided devices with RSRA in a time slot based on their received power
differences. In addition, we have evaluated the performance of the proposed
mechanism with varying difference in received powers and number of contending
devices. In comparison to state-of-the-art mechanisms, the proposed mechanism
can support more number of devices. Furthermore, as the value of difference in
received powers increases, the success rate decreases exponentially. This is
due to the fact that the gNB cannot decode the devices if the received power
difference is less than the threshold. Thus, we conclude that the receiver
design is critical in improving the RACH success rate. We will derive the
analytical expression for the average number of successful devices in the
future for the proposed mechanism.

## References

  * [1] https://cdn.ihs.com/www/pdf/IHS-Markit-Smart-Home-EBook.pdf
  * [2] T. Taleb and A. Kunz, “Machine type communications in 3GPP networks: Potential, challenges, and solutions,” IEEE Communications Magazine, vol. 50, no. 3, pp. 178–184, Mar. 2012.
  * [3] 3GPP TS 22.368 v11.2.0., “Service requirements for machine-type communications,” Tech. Rep. 22.368, v16.0.0, pp. 1–32, Jul. 2020.
  * [4] 3GPP, “E-UTRA–Medium access control (MAC) protocol specification,” Tech. Rep. 36.321, v14.3.0, pp. 1–17, Jun. 2017.
  * [5] 3GPP, “E-UTRA–Medium access control (MAC) protocol specification,” Tech. Rep. 36.321, v16.4.0, pp. 1–17, Mar. 2021.
  * [6] Q. Pan, X. Wen, Z. Lu, W. Jing, and L. Li, “Cluster-based group paging for massive machine type communications under 5G networks,” IEEE Access, vol. 6, pp. 64891–64904, Oct. 2018.
  * [7] J.R. Vidal, L. Tello-Oquendo, V. Pla, and L. Guijarro, “Performance study and enhancement of access barring for massive machine-type communications,” IEEE Access, vol. 7, pp. 63745–63759, May 2019.
  * [8] M.V. da Silva, R.D. Souza, H. Alves, and T. Abrão,“A NOMA-based Q-learning random access method for machine type communications,” IEEE Wireless Communications Letters, vol. 9, no. 10, pp. 1720–1724, Jun. 2020.
  * [9] J. Ding, D. Qu, and J. Choi, “Analysis of non-orthogonal sequences for grant-free RA with massive MIMO,” IEEE Transactions on Communications, vol. 68, no. 1, pp. 150–160, Oct. 2019.
  * [10] J. Liu and L. Song, “A novel congestion reduction scheme for massive machine-to-machine communication,” IEEE Access, vol. 5, pp. 18765–18777, Sep. 2017.
  * [11] C. Zhang, X. Sun, J. Zhang, X. Wang, S. Jin, and H. Zhu, “Distributive throughput optimization for massive random access of M2M communications in LTE networks,” IEEE Transactions on Vehicular Technology, vol. 69, no. 10, pp. 11828–11840, Oct. 2020.
  * [12] W. U. Rehman, T. Salam, A. Almogren, K. Haseeb, I. Ud Din, and S. H. Bouk, “Improved resource allocation in 5G MTC networks,” IEEE Access, vol. 8, pp. 49187–49197, Feb. 2020.
  * [13] Y. Liang, X. Li, J. Zhang, and Z. Ding, “Non-orthogonal random access for 5G networks,” IEEE Transactions on Wireless Communications, vol. 16, no. 7, pp. 4817–4831, Jul. 2017.
  * [14] Y. S. Reddy, A. Dubey, A. Kumar, and T. Panigrahi, “A probabilistic approach to model SIC based RACH mechanism for machine type communications in cellular networks,” IEEE Transactions on Vehicular Technology, vol. 70, no. 2, pp. 1878–1893, Feb. 2021.
  * [15] Y. S. Reddy, A. Dubey, A. Kumar, and T. Panigrahi, “A successive interference cancellation based random access channel mechanism for machine-to-machine communications in cellular Internet-of-Things,” IEEE Access, vol. 9, pp. 8367–8380, Jan. 2021.
  * [16] Y. Mao, B. Clerckx, and V. O. K. Li, “Rate-splitting multiple access for downlink communication systems: bridging, generalizing, and outperforming SDMA and NOMA,” EURASIP Journal on Wireless Communications and Networking, vol. 133, May 2018.
  * [17] J. Cao and E. M. Yeh, “Asymptotically optimal multiple-access communication via distributed rate splitting,” IEEE Trans. Inf. Theory, vol. 53, no. 1, pp. 304–319, Jan 2007.
  * [18] M. Dai, B. Clerckx, D. Gesbert, and G. Caire, “A rate splitting strategy for massive MIMO with imperfect CSIT,” IEEE Transactions on Wireless Communications, vol. 15, no. 7, pp. 4611–4624, July 2016.
  * [19] Y. Mao, B. Clerckx, and V. O. Li, “Rate-splitting for multi-user multi-antenna wireless information and power transfer,” in Proc. IEEE Int. Workshop Signal Process. Advances Wireless Commun. Cannes, France: IEEE, 2019, pp. 1–5.
  * [20] B. Clerckx, Y. Mao, R. Schober, and H. V. Poor, “Rate-splitting unifying sdma, oma, noma, and multicasting in miso broadcast channel: A simple two-user rate analysis,” IEEE Wireless Communications Letters, vol. 9, no. 3, pp. 349–-353, Nov. 2020.
  * [21] Y. Zhu, X. Wang, Z. Zhang, X. Chen, and Y. Chen, “A rate-splitting non-orthogonal multiple access scheme for uplink transmission,” in Proc. International Conference on Wireless Communications and Signal Processing (WCSP), Nanjing, China, Oct. 2017, pp. 1–6.
  * [22] B. Clerckx, H. Joudeh, C. Hao, M. Dai, and B. Rassouli, “Rate splitting for MIMO wireless networks: A promising PHY-layer strategy for LTE evolution,” IEEE Communications Magazine, vol. 54, no. 5, pp. 98–-105, May 2016.
  * [23] L. Klozar and J. Prokopec, “Propagation path loss models for mobile communication,” in Proc. International Conference Radioelektronika, Brno, Czech Republic, Apr. 2011, pp. 1-4.
  * [24] H.Holma and A.Toskala, “WCDMA for UMTS: HSPA evolution and LTE,” 5th edition, John Wiley & Sons, 2010.