Sea Shield: A Blockchain Technology Consensus to Improve Proof-of-Stake-Based Consensus Blockchain Safety

Abstract

In a blockchain network, a rule set called consensus mechanism is used to create and finalize a block. In a proof-of-stake (PoS), consensus-based blockchain network, nodes become validators, minters, or stakeholders’ nodes to complete the consensus mechanism. In these networks, when a node becomes a validator node, its details need to be saved because the details of the validators are used in the network for many important decisions, such as selecting block proposers for the consensus process. In this paper, we present Sea Shield, which uses a validator chain to save a node’s information when it becomes a validator or leaves its responsibility as a validator in the PoS-based blockchain network. The validator chain is a blockchain that can run with the main chain of a PoS-based blockchain. The internal features of the validator chain are similar to those of the blockchain. We designed and simulated a consensus mechanism to create and finalize the block for the validator chain with no forks. We present a process by which a node may join or unjoin as a validator in a PoS-based blockchain network to improve the overall security of the main chain-consensus process.

1. Introduction

Digital ledgers have been stored in databases for many years. The method for keeping a ledger in a database has changed over time. To cope with the limitations of traditional database systems, new technologies have emerged. Blockchain is a new technology that saves data in a decentralized manner. Blockchain technology plays a significant role in improving many systems such as cryptocurrency [1], supply chain [2], e-voting [3], Metallurgical and Machine-building tasks [4], autonomous decentralized online social networks [5], health care [6], and Privacy-preserving decentralized learning [7]. The core feature of this technology is to save data by creating timestamp blocks in peer-to-peer networks. There is no central authority in the blockchain network to create blocks because blockchain technology works in a decentralized network, that is why every blockchain network uses a consensus algorithm to create blocks in the network, such as delegated proof of work (DPoW) [8], proof of stake (PoS) [9], practical Byzantine fault tolerance (PBFT) [10], and tendermint [11]. Many consensus algorithms are available in the literature. Currently, the most appropriate consensus algorithm is determined and adopted by a system according to its requirements and network type. There are four different types of blockchain networks available: (1) public permissionless such as Ethereum [12], (2) public permissioned, for example, Corda [13], (3) private permissionless like an LTO network [14], and (4) private permissioned such as Hyperledger Fabric [15].

With time, blockchain consensus algorithms have been customized and evolved according to application requirements. Satoshi Nakamoto was the first to use the proof-of-work (PoW) algorithm in Bitcoin cryptocurrency [16]. The major benefit of this algorithm is its high immutability, temper resistance, and high security; however, the algorithm consumes very high energy to complete its computation. Because of these limitations, many other consensus algorithms have been proposed to cope with the problems of PoW, such as PoV [17]. This consensus method involves a decentralized voting settlement between consortium members to reach an agreement. In comparison to the fully decentralized PoW consensus, this consensus employs a separate voting and supervisory principle to decrease transaction verification time and to enhance reliability and security. The participants allocated four security identities to take part in the voting procedure. Unlike PoW, using the proof-of-vote consensus removes the necessity for third-party mediators in the submission or validation of generated blocks. The other presented solution is the proof-of-stake (PoS) algorithm in the literature. The PoS algorithm does not consume high energy, but it has drawbacks; therefore, many different PoS-based consensus mechanisms have been proposed in the literature. According to the PoS algorithms presented in the literature, Xiao et al. [18] classified four different classes of PoS-based algorithms: chain-based PoS [9], committee-based PoS [19], BFT-based PoS [11], and delegated PoS [20].

In PoS, blockchain network nodes are required to become validator nodes because the validator nodes are those who complete the consensus process in the network. To be a validator node, all PoS-based consensus algorithms use any amount or token-stacking system in the network. The nodes become validators after the coin/token stacking in the network. Later, the network and other nodes of the network use the staking information of the validators, such as the amount, staking time, or any extra information (as per consensus) during the consensus process, for example, to select the next block proposer using staking value and age. Moreover, staking information is also required if forgery is found in the block and the system needs to punish the validator because some of the PoS-based blockchains are using slashing mechanisms [21] to prevent forgery and to improve security.

Validators are a very important part of the PoS-based blockchain because their information cannot be modified, changed, or deleted, and should be accessible to all after they become validators in the system. Traditional database systems do not offer all of the required features, but the blockchain technology itself provides the required features. The key features of this technology are trust, transparency, and immutability [22]. Therefore, we propose a Sea Shield that uses a validator chain based on blockchain technology, with a consensus mechanism to save validator information. The purpose of the validator chain is to save the information of the nodes when they become validators in the network and when they leave the validators’ responsibility in the network. We designed a consensus by using the concept of practical byzantine fault tolerance (PBFT) to improve the proof-of-stake (PoS), algorithm-based blockchain safety.

Our major contributions to this paper are as follows:

• The nodes’ information, when join and unjoin in the network as a validator, is the critical aspect of PoS-based blockchain network, and we have not found any solution in the literature that saved the PoS-based blockchain network’s nodes information securely. Therefore, we introduce Sea Shield, a blockchain technology consensus that uses a validator chain. The internal features of the validator chain are similar to those of any other blockchain.
• If the staking information is not saved securely, the whole PoS blockchain network safety would be at risk. So, the presented consensus mechanism creates and finalizes blocks for the validator chain with no forks [23] in a decentralized public-permissioned blockchain network.
• We discuss the block structure of the validator chain for both the join and unjoined mechanisms of the validator.
• We evaluate the performance of the Sea Shield through simulation. The results show that the validator chain operates securely with fork control in a malicious environment.

The rest of the paper is organized as follows: Section 2 provides a short review of the blockchain internal structure, forking problem, consensus algorithms related to this paper, and significance of the study; Section 3 describes the complete mechanism of the proposed Sea Shield when join/unjoin is a validator; Section 4 presents the algorithm with an explanation of the complete process flow of the Sea Shield; Section 5 shows the experiment and evaluation details of the simulation work; and Section 6 discusses the performance of the presented Sea Shield through a comparative analysis of the inside consensus characteristics. Finally, Section 7 concludes the study and discusses the limitations, and future work.

2. Preliminaries

2.1. General Blockchain Internal Structure

A blockchain consists of interconnected timestamp blocks in a peer-to-peer network. The blocks hold information according to the type of blockchain network. Blockchain is a digital ledger that can hold any type of data. Every block in a blockchain is a timestamp that is attached in chronological order. A timestamp is generally present in the header of the block. The first block is called the genesis block, and its block number in the chain is zero. The interconnected block mechanism, also called chaining in the blockchain, and is obtained using the cryptographic hash function [24]. Figure 1 shows the general chaining of the blocks in the blockchain. Every block has its previous block hash in the header, such that it creates a digital chain structure. Every node in the blockchain maintains a copy of its ledger. When a new block is created, it is broadcast to the entire network and every node updates its ledger by adding new blocks.

2.2. Fork

A fork occurs when a linear blockchain ledger is split into two or more chains. In blockchain networks, forks occur for many reasons, such as adding new functionality, changing rule sets, addressing security risks, and resolving disagreements within the community on two blocks of the same height as Bitcoin and Ethereum [25,26]. This also occurs because of the blockchain consensus mechanism, such as in Bitcoin, when two valid blocks are pointing to a similar, previous block and are created and broadcasted simultaneously to the network, and then a fork appears in the blockchain network. Figure 2 illustrates the forking issue in the blockchain network.

The next block is created after the fork resolves the issue because it will point to one of the two blocks as the previous block in its block, such that block D points to block C. Most of the blockchains follow the longest chain rule [27] in the network. The longest chain is the one that has maximum details of the events that occur in the network. Here, +++A, C, D, E++ are considered the valid chain or the longest chain in the network. Block B is called the orphan block in the Bitcoin blockchain and the resources invested in the block are wasted. The transactions in the block also become stuck in the block because they are no longer part of the blockchain anymore.

2.3. Consensus Mechanism

Due to the unavailability of a central authority or third-party validation, the blockchain used a consensus mechanism to create and finalize the block in the network. We have many different consensuses in the literature, here we are going to discuss a few consensuses relevant to this paper. The proposed consensus uses the concept of BFT and PoS algorithms.

2.3.1. Practical Byzantine Fault Tolerance (Pbft)

Castro et al. presented an algorithm that solved the old Byzantine fault problem [10]. The algorithm works effectively under one-third of the malicious nodes’ environment. The algorithm is designed to tolerate one-third of the faulty nodes in a network. There are five steps in the algorithm for completing a request. The proposed algorithm follows the master/server concept. By some rules, one becomes a master and others become servers. In the first step, called the request step, the master server receives a transaction from any client and timestamps the transaction. In step two, called the pre-prepare step, the master server generates the order number and sends it to the other server nodes. In the third step, called the prepare step, if the master server receives accept messages from 2f + 1 nodes, the transaction is entered into the commit step. In the commit step, if the master receives commit messages from more than 2f + 1 server nodes, then the master considers the transaction accepted by other server nodes. The reply is the last step, in which the master responds to all server nodes to confirm the transaction. The Steller consensus [28] is an example of the PBFT consensus algorithm. The PBFT concept is used by many others in their own ways, such as Ant share. [29] used PBFT and proposed a consensus-delegated Byzantine fault tolerance [30].

2.3.2. Proof of Stake (Pos)

Many PoS consensus algorithms have been proposed in the literature. We describe the PoS algorithms, that is, how they work, and use staking in the consensus process.

Chain-Based Pos

Chain-based PoS is an alternative consensus to PoW. King et al. first proposed this consensus to reduce energy usage [31]. First, they were the Bitcoin developers. It operates under the Nakamoto consensus [16] framework. The longest chain rule, block validation rule set, gossip protocol [32] for message broadcasting, and probabilistic finality are used. In a chain-based PoS, there is a minter who solves the hashing puzzle [33] only once for a clock tick because the difficulty [34] decreases, according to the minter’s stake value. If the minter has a high stake value, then the difficulty of the hashing puzzle is considerably reduced for it and the expected number of hashing attempts to solve the puzzle would also be less. The consensus achieved a good reduction in energy consumption. Peercoin [31] and Nxt [35] are good examples of this type of PoS. Despite all of the good parameters, it also has some disadvantages, such as only the rich have the power to become a block proposer again and again, which leads to centralization issues in the network. There is also a security threat because only money is required to invest in a system to take control of a network whereas in PoW, money, hardware, electricity, and expertise are all required to interrupt the system.

Committee-Based Pos

A committee-based PoS does not depend on hashing puzzles such as chain-based PoS. This mechanism generates a committee of stakeholders, based on their stake values to create blocks. In this type of consensus mechanism, a multiparty computation (MPC) [36] scheme is generally used to create committees. The MPC takes stake values from the network as input and releases a list as the output of stakeholders through random selection. The stakeholders generate the blocks according to the MPC release list. The longest chain rule and probabilistic finality are perceived in this type of PoS consensus mechanism. Many consensuses use this type of PoS, such as snow-white [37] and chain of activity [19]. Kiayias et al. presented the protocol Ouroboros [38], in which they used time slots to produce blocks. They elected a leader for every slot to produce blocks. To improve security, every block producer considers the last three blocks of the chain as transient. This consensus improves decentralization, but it has its drawbacks. The block producer is susceptible to intentional attackers; this problem was solved by Ouroboros Praos [39].

Bft-Based Pos

Like other PoS-based consensus’, in BFT-based PoS consensus, the coin or token stacking mechanism has been used as a block producer in the network. The Byzantine fault tolerance (BFT)-based PoS uses many types of block-proposing mechanisms such as round robin [40] and committee election to produce blocks in the network. The check-pointing mechanism [41] replaces the longest chain rule in the BFT-based PoS to stabilize the main chain. The BFT-based PoS uses an additional layer for block finality. Consensus does not use the longest chain rule for probabilistic block finality. The BFT-based consensus has a fast and deterministic block finality. The BFT layer improves the liveness of the network, and the consensus can tolerate malicious nodes in the network. Many consensus mechanisms use BFT-based PoS concepts such as Tendermint [42], Algorand [43], and Casper FFG [44]. However, there are also disadvantages to using Bft-based PoS, such as an algorithm proposed by Kwon et al., that used a coin staking system to become a block producer in the system [11]. Because of the many block producers, consensus used the round robin algorithm to select a block proposer for the current round. They used Bft layers for block finalization because the extra layer of Bft in consensus, throughput has decreased. It increases block creation time and the communication message overhead of the consensus as well.

Delegated Pos (Dpos)

Delegated PoS is a partial member of a committee-based PoS because the committee is selected by the stakeholders to complete the consensus in the network through the voting process. In the DPoS, consensus members are called delegates. The election process is used to select delegates from among all stakeholders. The selected delegates proposed blocks in the network. Commonly used cases of DPoS are Bitshare [45], STEEM [46], LISK [47], and EOS.IO [48]. The DPoS is designed to reduce the number of consensus members so that messaging overhead can be controlled during the consensus. However, DPoS has many limitations as well. There are many works presented in the literature that try to improve DPoS, such as Yinghui et al., who presented an election mechanism to improve Dpos [49]. The algorithm used two election processes, one to elect the representative and the second to select the final winner and to reach a consensus. The algorithm is designed to improve the decentralization of the DPoS-based blockchain network. Qian et al. presented reputation-DPoS to improve the security of the DPoS consensus mechanism [50]. In the proposed model, nodes are divided according to their trust states. The algorithm only selects high-quality nodes to participate in the consensus algorithm. The selected consensus improves the security and efficiency of the algorithm. They introduced an improved incentive method by using reputation and tokens to attract voters. By using this algorithm, fair nodes will be selected. Nodes received votes and rewards on behalf of their behavior in the consensus.

2.4. Significance of the Study

The staking details of validators are very important. In a majority of PoS-based blockchain networks, block producers are the core part of the consensus. At some point, blockchain network security relies on their hand. They produce blocks and verify transactions in the network. The selection of block producers is mostly held by using their stake details. These details are a very critical part of the complete consensus process. We have seen that coin/amount staking plays a very important role in all PoS-based consensus mechanisms, such as in

Table 1. The use of staking amount information in the PoS-Based blockchain network.

PoS Algorithm	Coin/Amount Staking Role	Example
Chain-based	stake value is used to decrease the difficulty	Peercoin [31]
Committee-based	stake values were used to generate a list of block producers	Ouroboros [38]
BFT-based	stake values are used to choose the next block proposer in the system	Tendermint [42]
Delegated	stakeholders vote to select the delegates group of the network	Bitshare [45]

, which describes the staking amount requirements in the system. Therefore, the stacking details should not be tempered, altered, or deleted from the network. The details should also be available to all required ones. Hence, we present Sea Shield as a blockchain use case that uses a validator chain with a consensus mechanism. The proposed consensus mechanism saves the node’s information with all of the staking details when joining/unjoining as a validator in the network by a process flow. The join and unjoin process of the nodes as validators in the Sea Shield is completely transparent and the details are known by all of the nodes in the network. Normal computing environment infrastructure emphasizes confidentiality and integrity whereas blockchain is designed to offer integrity and availability on a decentralized distributed system. We used blockchain technology to save records because security in the blockchain is based on ensuring that data are protected from alteration. To restrict the data from modification, the technology copies the data to as many locations as possible so that the modification of all copies becomes infeasible. The validator chain works similarly to other blockchains. This is mainly the use case of blockchain technology. Figure 3 shows the chain of blocks for the validator blockchain.

3. Proposed Consensus

The proposed consensus has two parts:

1.

The Joining mechanism

This part contains the process of a node becoming a validator and the block structure joining as a validator in the validator blockchain.

2.

The unjoin mechanism

This section illustrates the unjoin process of the validator from the network as well as the block structure for unjoin as a validator.

3.1. The Joining Mechanism

We designed the process for the PoS-based public permission blockchain system, in which anyone can join the network and create transactions; however, to participate in the block creation and finalization process, the node first needs to become a validator node. We presented a mechanism by which a node can become a validator node. When a node wants to become a validator node in the network, it must follow the joining mechanism. Figure 4 shows the process flow of the joining mechanism of a node to become a validator in the network.

The node first generates a join message request 1 and sends it to the network host to start the joining mechanism. We use the term network host to refer to any person, software, or moderator running the blockchain network. All requests received by the host are saved in the queue maintained by the host. When the host is free, it responds to a request. The host generates and broadcasts the following parameters for the requested node:

1.

Validator Number

An ID is assigned to the node by the host node. If the node is new and was never a validator node, the network host assigns a unique ID to the node as a validator number. If the node completes the join process as a validator and becomes a validator in the network, the validator ID assigned by the network host to the node would be sealed from the network. The network will not assign this ID to any other node, insofar as the node leaves the validator’s responsibility with an unjoin mechanism. If the existing validator leaves its validator’s responsibility, it becomes a normal node by unjoining. Subsequently, the same node returns to become a validator node in the network, and the network assigns a similar validator ID to the node that was first assigned to it.

2.

Date Time (h)

This is the date and time when the network host generates a block number for the node.

3.

Hash (n − 1): (Previous block hash)

It is the hash [24] of the latest block of the validator chain that the network host releases to the node so that the node may use it as the previous block hash in the block.

4.

Total Validators Count

It is the total validator of the network immediately before the node’s request is received by the network host.

5.

Block Number (n)

It is a serial number assigned by the network host to the node’s block as per the chain of the validator. The network host generates this node’s block number by increasing the last validator’s chain block number by one.

After releasing the parameters to the node and broadcasting them in the network, the hosts wait time has started. The host does not release any parameters to any requests until the request being processed has finished its joining process or the join-as-validator time duration allocated to this request has ended. Every network has a specified set of pre-defined time durations for the joining mechanism called join-as-validator time. The join-as-validator time starts after the node receives parameters from the host. The node must finish its joining mechanism within the join-as-validator time, otherwise after the join-as-validator time the network host discards the node’s request and releases all generated parameters, except the Date Time (h), to the next node’s request in the queue.

The next requested node receives a similar Validator Number, Block Number (n), Total Validators, and Hash (n − 1) but the recent Date Time (h). The Date Time (h) is always the time when the network host releases the parameters to the node.

After receiving the required parameters from the host, the node actively creates a validator block for the validator chain to join as a validator in the network. Two parameters are required to create a validator block i.e., a bond transaction and extra bonding time commitment.

3.1.1. Bond Transaction

A node must conduct a bond transaction and broadcast it on the network. The node can use any amount greater than the minimum amount set by the network for bond transactions. The network decides the minimum transaction amount that a node can perform to be a validator. This is a special bond transaction, and the amount used in the bond transaction cannot be used further by the node, as long as the node remains a validator node in the network. When a node wants to use its bonded stakes, it must first leave its validator responsibility in the network and become a normal node, then it may use its bonded stake.

3.1.2. Extra Bonding Time

Extra bonding time is the time duration that is committed by a node and is broadcasted with the transaction. When a validator wants to leave the validator’s responsibility in the network, the validator must pass an extra bonding time duration plus the network default bonding time duration to leave the validator’s responsibility. The network default bonding time duration is the time duration that the network sets for every validator in the network. The significant extra bonding time duration commitment makes a validator more trustworthy by other validators because if the validator performed any forgery during the consensus process, it could easily be punished by the network. The network imposes a penalty on the validator. Due to the penalty, the validator can completely lose its stake or be deducted, depending on the forgery size and network rule.

After completing the bond transaction, the validator can create a validator block. The validator block contains the following parameters:

1.

Header

Block Number (n), Block Hash (n), Block Status, Hash (n − 1), Date Time (b).

2.

Validator details

Node Identity, Validator Number, Date Time (h), Validator Status, Reactivation Number, Total Validators.

3.

Requirement

Extra Bonding Time(m), Transaction, Date Time (t), Stake Value, Wallet Proof.

Where the Block Number, Hash (n − 1), Validator Number, Date Time (h), and Total Validators Count are issued by the host. Block Hash (n) contains the hash of the current block. Block Status shows the block is created for “join as validator”. Date Time (b) is the date and time when a node creates a block, and Node Identity is the identity of the node in the network, such as its wallet address [51] or any other address. Wallets are used to store the user’s credentials and all of the account-related information of the user. In the blockchain, the wallets keep track of all assets of the user. It also holds the private [52] and public [53] user keys. Validator Status shows the validator’s current status; the block is for the joining mechanism whose status is active. Extra Bonding Time (m) is the extra time duration (in minutes) committed by a node in the block. A Transaction is a bond transaction from node. Date Time (t) is the date time of the bond transaction performed by a node to become a validator. Stake Value is a bond transaction amount, and Wallet Proof is proof of the transaction from the node’s wallet. The reactivation number is for the validators that were once validators but left their validators responsibility by performing the unjoin mechanism. If that node creates a block for the join mechanism as the validator, it inserts its total number of unjoins as validator counts in the reactivation number in the block. For a new node that first creates a block for the join mechanism as a validator, its reactivation number would be zero. If the old validator wants to rejoin the validator’s responsibility, it must fulfill the complete joining mechanism again to become a validator in the network, except for the validator number. The node uses its old validator number to create a new block for the join mechanism. Figure 5 presents the block structure in which the node is used to create the new join block for the validator’s chain to become a validator in the network.

After creating a validator block, the validator digitally signs [54] the block by itself and broadcasts the block to all validators/nodes of the network. The validators of the network, after receiving the block, send an acceptance message with a digital signature to the node if the transaction and other information are valid. When a node has received acceptance messages from two-thirds of the total network validators, the node immediately informs the network host by sending join message request 2, The join message request 2 is a combination of a join block and proof of a two-thirds acceptance message for its block for the validator chain. After receiving the valid proof of a two-thirds acceptance message for the valid node block within the join as validator time, the network host attaches the node’s validator block to the validator chain and shares the validator chain ledger with the node.

After the join block is added to the validator chain by the network host, the joining mechanism of a node to become a validator node in the network ends. The node has now become a validator node in the network and can participate in the network as a validator such as in the consensus mechanism for the block creation process of the main chain. The network host generates new parameters for the next node’s parameters request after the completion of the joining mechanism of the current node’s request, which seals the parameters released to this node and updates the total validator count by increments of one in the network for the next nodes.

3.2. The Unjoin Mechanism

When a node wants to leave the validator’s responsibility in the network, it must follow the unjoin mechanism. To start the unjoin mechanism, the validator creates an unjoin message request 1 and sends it to the host and all validators/nodes of the network. The validator may send the unjoin request 1 at any time to the host but the host will only respond to the request after every 20 block creation cycles in the network until all requests are waiting in the unjoin_queue. A network may set any time duration to respond to unjoin requests; in our work, we set a 20-block creation cycle as the time duration. The validator may cancel its request before the host responds because the request becomes permanent after the host’s acknowledgment. The host collects all unjoin requests received from the validators during the last 20 block creation cycles. Before the start of the 21st block creation cycle or after every 20th block creation cycle of the network, the host acknowledges all of the requested validators that sent an unjoin request so that they can start their unjoin process. Once the host has sent an acknowledgment to the unjoin request, the validator cannot participate in any network process as a validator. The network host restricts the validators from participating in the consensus process as block producers or in the election process that had already requested to unjoin, by removing their IDs from the total validators list of the network at the time of sending an acknowledgment of their unjoin request.

After receiving an acknowledgment from the network host, the validators begin completing the first requirement of the unjoin mechanism, which is passed the bonding time duration in the network. The passing of the bonding time of a validator in the network starts with the receiving time of its acknowledgment from the network host. Bonding time is a combination of two types of time: the default time duration for unjoining as a validator from the network and extra bonding time duration that is committed by every validator at the time of becoming a validator in a join as a validator block. The validators must pass the default time duration plus extra bonding time duration in the network to leave their responsibilities as validators. The system has set the default, pre-specified time duration for validators to pass before unjoining the network as validators because the extra bonding time is committed by the validators themselves, so it can be more or less; however, the network requires that the validator remains in the network for longer after the unjoin request so that if they committed any forgery, the network could punish them. Therefore, the default unjoin time of the network should be greater than a 20-block creation cycle time.

Default Unjoin time ≥ 20 block creation cycle

After passing the bonding time in the network, the validator creates an unjoin message request 2 and sends it to the host and other validators to inform them of the completion of their bonding time. Unjoin message request 2 comprises (Bonding time start + total bonding time duration + Bonding time end). If the host is free, it responds to the validator’s request at the same time; otherwise, it maintains the queue to respond to the validator’s request. The host entertains each validator’s request by the receiving time either joining as a validator or unjoining as a validator, the host maintains the queue in FIFO (first in first out) fashion and responds with respect to the message arrival time of the requests. Figure 6 shows the process flow of requests received by the host during the join and unjoin mechanisms.

When receiving an unjoin message request 2, the host checks the validity of the unjoin message request 2. If the message is worthy, the host generates and releases the unjoin block parameters to the validators that completed their bonding time in the network and also broadcasts it to the network. After the releasing parameters were released, the host wait time began. During the host wait time, the host does not release the join/unjoin block parameter to anyone else. The host wait time will be over with the completion of the unjoin-as-validator time or the completion of this unjoin-request process. The parameters for the unjoined block from the host to the validators are as follows:

1.

Block Number (n)

It is the block number issued by the host to the validator to create an unjoined validator block.

2.

Date Time (h)

It is the date and time when the host creates the block number.

3.

Hash (n − 1)

It is the hash of the last block in the validator chain. The final block can be any joined or unjoined validator block. This hash is used as the previous block hash in the next block creation.

4.

Total Validators Count

It is the total validator number of the network.

5.

Bonding Date Time Start

It is the date and time when the host sent an acknowledgment of unjoin message request 1 to the validator to begin passing its bonding time in the network.

6.

Date Time (r2)

This is the received date and time of an unjoin message request 2 to the host from the validator.

7.

Penalty

Penalty contains the total penalty imposed on the validators from the network during their time in the network as validators.

The pre-specified amount of time, called the unjoin-as-validator, has been allocated to the validator that receives parameters from the network to complete an unjoin block creation and obtain two-thirds of the accepted messages for its block from the validators of the network. The unjoin-as-validator time began after the validator received the parameters from the network host. After receiving the parameters from the host, the validator performs the transaction to release its bonded stake from the network and broadcasts it in the network. This is a special transaction because in normal transactions the sender performs the transaction, but in this case the receiver (validator) creates the transaction on behalf of the network host. In this transaction, only dummy values are shown because the network will only release the stake value to the validator after the successful completion of the unjoin mechanism. The special transaction is designed to control forgery in unjoin block creation and improve security. After the transaction, the validator creates an unjoined block. The unjoined block contains the following parameters:

1.

Header

Block Number (n), Block Hash (n), Block Status, Hash (n − 1), Date Time (b).

2.

Validator details

Node Identity, Validator Number, Date Time (h), Validator Status, Closing Number, Penalty, Total Validators Count.

3.

Requirement

Bonding Date Time Start, Default Time Duration for Unjoining, Extra Bonding Time(m), Date Time (r2), Stake Release Transaction, Date Time (t), Stake Value, Wallet Proof.

Where Block Number (n), Date Time (h), Hash (n − 1), Total Validators Count, Bonding Date Time Start, Date Time (r1), Date Time (r2), and Penalty Detail are released by the host to the validator. Block Hash (n) contains the hash of the current block, Block Status shows the block is created for a “unjoin as validator” purpose. Date Time (b) is the date time of unjoin block creation, Node Identity is the wallet identity of the node in the network, Validator Number is the same validator number issued from the host at the time of creating the join validator block, and Validator Status is “inactive” because it is unjoined as a validator block. The Closing Number holds the “total number of unjoin” in the network of this validator, the Default Time Duration for unjoining is set by the network for every unjoin validator, Extra Bonding Time (m) is the committed time in minutes from the validator in the join block, and Stake Release Transaction is the transaction that causes the validator to release its stake from the network. Date Time (t) is the time of the stake release transaction, Stake Value is the bonded stake amount from the validator when it becomes a validator, and Wallet Proof is the proof of the stake release transaction from a node. Figure 7 shows the block structure for the unjoin mechanism that uses the validator to create the unjoin block.

After creating the unjoined block, the validator broadcasts this block to the network. If the block is valid, the other validators/nodes send the accepted messages to the sender validators. When the validator receives two-thirds of the accepted messages from the other validators, it informs the host by sending an unjoin message request 3. Unjoin message request 3 comprises (unjoin block and proof of two-thirds of the accepted messages for unjoin block). If the host receives an unjoin message request 3 within the unjoin-as-validator time and unjoin message request 3 (the unjoin block and two-thirds of the accepted messages) is also valid, then the host unjoins the validator from the network and releases its stake value. The host updates the total validator count in the network and uses this block as the previous block for the creation of the next block in the network. The network seals the parameters issued to the validator, which were used to create an unjoined block. The network will not use these parameters again for any other validators in the network. If the specified time has ended and the validator does not complete the unjoin mechanism for any reason, the host discards the validator’s request and releases the parameters to the next validator’s request in the queue.

If the host discards the validator’s request due to a time out, the validator will have to complete the whole process again. The validator may restart the unjoin mechanism by creating a new unjoin message request 1 to the network. Figure 8 shows the complete unjoining mechanism of a validator that leaves the network or becomes a common node in the network.

The network host should work with honesty because the network host plays an important role in the join and unjoin mechanism of the validator, and validators are the main part of the block creation process of the PoS blockchain network, which is why their join and unjoin process is also very important. The network host maintains all of the received join and unjoin requests from the validators to create a log. The request log contains join message requests 1 and 2 and unjoin message requests 1, 2, and 3 of the validators during the last 20-block creation cycle. The network host creates and releases the request log to the entire network after every 20-block creation cycle. The request log is released to the whole nodes of the network. The request log allows the network’s validators to observe the network host’s working process. If any node in the network has any complaint, it can also raise its complaint against the host. If the node has found discrimination from the host for any reason, for example, a node wants to become a validator node and requests the host for the release of parameters for the join block and the node does not receive the acknowledgment of time from the host, the node would see the log of the details showing that the host is not occupied and that its request is also present in the log, it may raise its voice against the host by showing proof of its request. If the node sees the log and the host is occupied by a long queue or its request is missing from the log for any reason, then the node may send its request again to the host.

4. The Proposed System Algorithm

The proposed algorithm is written in the form of an event. To describe an event, an upon rule set is used. An upon rule set works when messages arrive and the associated conditions with upon become true. The algorithm shows the basic process flow of the proposed join and unjoin mechanism for implementation. The events are written based on node-initiated messages. We discussed the algorithm concisely because it has already been briefly discussed in the above sections.

4.1. Explanation

Algorithm 1 represents the complete Sea Shield mechanism. We used this algorithm for the implementation. Algorithm 1 calls the function the join/unjoin mechanism, which is discussed later.

Algorithm 1 Sea Shield complete mechanism

Initialization

1.   phasec ∈ {joinRequest1, joinRequest2, unjoinRequest1, unjoinRequest2, unjoinRequest3} 2.   JoinAsValidatorTime := Time duration 3.   UnJoinAsValidatorTime := Time duration 4.   DefaultBondingTimeDuration := Time duration 5.   Node_List[] := list 6.   Wallet[] := list 7.   ValidatorsNodeIDList[] := nil 8.   CurrentValidatorsList[] := nil 9.   Penalty := Amount 10. upon start do StartMechanism(): 11.   Generate Node_List, Wallet 12.   Make Network_Connections 13.   FOR i = 1 TO NumberJoinMechanism 14.     Function JoinMechansim (Node_List) 15.   NEXT 16.   Function unJoinMechansim (ValidatorsNodeIDList, NumberUnJoinMechanism) 17. Reset parameters

4.1.1. Initialization

The starting nine lines are for the algorithm initialization. We have only provided the required initialization to explain the process flow. Phasec represents all of the join/unjoined phases. Node_list shows the list of nodes in the network. The wallet presents all transaction details of all nodes. ValidatorsNodeIDList shows the details of all the active or inactive validator IDs with their corresponding node IDs in the network. CurrentValidatorsList only has active validators of the network. We provide the join_as_validator time, unjoin_as _validator time, default bonding time, and penalty amount to the algorithm because these are the network inputs.

4.1.2. Start Mechanism

Lines 10 to 17 were written for the startup of the process. To start the mechanism, we generate the node list and the wallet list in line 11 and create connections for the network nodes in line 12. Lines 13 to 15 were written to run the join mechanism multiple times. Line 16 executes the unjoin mechanism, and Line 17 resets all parameters for the network.

4.2. Join Mechanism

We divided the join mechanism into three algorithms for better understanding. Algorithm 2 presents the complete join request 1 phase of the join mechanism, Algorithm 3 presents the entire join request 2 phase of the join mechanism, and Algorithm 3 presents the functions used by both of the join mechanism algorithms. Because it is one function, JoinMechansim, we discuss its entirety below; however, we distribute the explanation of Algorithms 2 and 3 for a better understanding. Lines 18 to 83 explain the join mechanism of the node, which is called in line 14. The joint mechanism is expressed in the form of functions. Three functions are written to execute the mechanism: JoinMechansim, CreateJoinBlock, and Discard request. JoinMechansim calls for the other two functions.

Algorithm 2 Join mechanism (phase ← Join Request 1)

18. Function JoinMechansim (Node_List): 19.   phasec ← joinRequest1 20.   Join_request_node ← NodeList [randomIndex] 21.   broadcast (JOINREQUEST1, host, JoinMessageRequest1) 22. upon (JOINREQUEST1, host, JoinMessageRequest1) from Join_request_node while phasec = joinRequest1 do 23.   logbook.append (JOINREQUEST1) 24.   Queue.append (JOINREQUEST1)       /* if the host is free*/ 25.   If Queue [0] = JOINREQUEST1 then 26.    if ValidatorsNodeIDList.Contain(Join_request_node) then 27.      ValidatorNumber ← ValidatorsNodeIDList [Join_request_node] 28.    else 29.    ValidatorNumber ← ValidatorNumber + 1 30.    PreviousBlockHash ← Hash (Last block of ValidatorChain) 31.    BlockNumber ← BlockNumber + 1 32.    joinParameters ← [ValidatorNumber, CurrentTime    PreviousBlockHash, TotalValidator, BlockNumber] 33.   broadcast (PARAMETERS, Join_request_node, JoinParameters, JoinTimeStart) 34.   Queue.remove(JOINREQUEST1) 35.  upon (PARAMETERS, Join_request_node, JoinParameters, JoinTimeStart) from host while phasec = join Request 1 do 36.    bondTransaction ← Join_request_node, StakeValue, DateTimebondTransaction 37.    Wallet Proof ← Join_request_node, Total amount before transaction, Remaining amount 38.    broadcast (TRANSACTION, All_node & host, bondTransaction, Wallet Proof) 39.    signedBlock ← Function CreateJoinBlock (Join_request_node, JoinParameters, bondTransaction,    Wallet Proof) 40.    broadcast (BLOCK, All_node & host, signedBlock) 41.  upon (BLOCK, node, signedBlock) from Join_request_node while phasec = joinRequest1 do 42.    if valid(signedBlock) then 43.    SignedAcceptMessage ← Accepted + Asymmetric Encryption by key [Hash(Accepted)] 44.    broadcast (MESSAGE, sender_node, Join_request_node, SignedAcceptMessage) 45.  upon (MESSAGE, sender_node, Join_request_node, SignedAcceptMessage) from other_node while phasec = joinRequest1 do 46.    ProofSignedMessage.append (ProofSignedMessage)   /*after receiving 2/3 accept messages from others*/ 47.   broadcast (JOINREQUEST2, host, ProofSignedMessage, signedBlock, JoinTimeStart, CurrentTime) 48.   phasec ← joinRequest2

1.

Algorithm 2 Explanation

In lines 19–21, any random node from the network broadcasts join request 1 to the host. In lines 22 to 34, upon receiving a request from the node and if the host is free, the host broadcasts the parameters to the join request node. In lines 35 to 40, upon receiving the parameters from the host, the join mechanism broadcasts the parameters to the join request node. In lines 35 to 40, upon receiving parameters from the host, the join request node first creates a bond transaction and broadcasts it to the whole network. Second, it creates a block by calling the function CreateJoinBlock, and broadcasts it to the network. In lines 41 to 44, upon receiving a valid transaction and block, the network nodes broadcast an accept message to the join request node. In lines 45 to 48, if the join request nodes receive two-thirds of the accept messages, they will send join request 2 to the host.

Algorithm 3 Join mechanism (phase ← Join Request 2)

49. upon (JOINREQUEST2, host, ProofSignedMessage, signedBlock, JoinTimeStart, CurrentTime) from Join_request_node while phasec = joinRequest2 do 50.   logbook.append (JOINREQUEST2) 51.   if (CurrentTime − JoinTimeStart) < JoinAsValidatorTime then 52.    if ProofSignedMessage (count) ≥ 2/3 nodes 53.     if valid(signedBlock ∧ ProofSignedMessage) then 54.       ValidatorChain.append (signedBlock) 55.       TotalValidator ← TotalValidator + 1 56.       if ValidatorsNodeIDList.Contain(Join_request_node) = False then 57.       ValidatorsNodeIDList.append([Join_request_node, ValidatorNumber]) 58.    broadcast (VALIDATORCHAIN, Join_request_node, ValidatorNumber, ValidatorChain) 59.    ClosingNumber[ValidatorNumber] ← 0 60.   CurrentValidatorsList.append(ValidatorNumber) 61.    Else 62.    Function DiscardRequest() 63.   else 64.   Function DiscardRequest() 65. else 66. Function DiscardRequest() 67. upon (JOINREQUEST2, host, nil) while (CurrentTime –JoinTimeStart) > JoinAsValidatorTime do 68. schedule DiscardRequest() implemented after JoinAsValidatorTimeDuration

2.

Algorithm 3 Explanation

In lines 49–66, upon receiving join request 2 to the host, the host accepts the block if the received request is valid and also reaches within join as its validator time, otherwise the host discards the request by calling the function DiscardRequest. In lines 67 and 68, the host discards the join request and frees itself, and it will only execute if the current process time exceeds the join as the validator time.

3.

Algorithm 4 Explanation

Algorithm 4 contains the body of function CreateJoinBlock, and function DiscardRequest that is used by Algorithms 2 and 3 respectively. In lines 69–79 the join block is created with the digital signature. In lines 80–83 the function discard the request.

Algorithm 4 Sea Shield join mechanism (functions)

69. Function CreateJoinBlock(Join_request_node, JoinParameters, bondTransaction, WalletProof): 70.   If ClosingNumber.Contain(Join_request_node) then 71.     ReactivationNumber ← 1+ ClosingNumber [Join_request_node] 72.    else 73.    ReactivationNumber ← 0 74.    ExtraBondingTimeDuration ← Time Duration 75.    ValidatorDetail ← Join_request_node + ValidatorNumber + CurrentTime_h + “Active” +    ReactivationNumber + TotalValidator 76.    Requirement ← ExtraBondingTimeDuration + bondTransaction + WalletProof 77.    Block ← ValidatorDetail + Requirement 78.    Header ← BlockNumber + Hash(Block) + “join as validator” + PreviousBlockHash+CurrentTime_b 79.   RETURN signedBlock ← (Header + Block) + Asymmetric Encryption by key [Hash (Header + Block)] 80. Function DiscardRequest(): 81.   BlockNumber ← BlockNumber − 1 82.   if ValidatorsNodeIDList.Contain(Join_request_node) = False then 83. ValidatorNumber ← nil

4.3. Unjoin Mechanism

We split the unjoined mechanism into four algorithms to clearly understand its functionality. Algorithm 5 presents the thorough unjoin request 1 phase of the unjoin mechanism, Algorithm 6 describes the complete unjoin request 2 phase of the unjoin mechanism, Algorithm 7 shows the complete process of unjoin request 3 of the unjoin mechanism, and Algorithm 8 describes the functions used by other algorithms of the unjoin mechanism. We describe the function unJoinMechansim sequentially because it is a function. For a clearer understanding, we present the explanation of Algorithms 5, 6, and 7 separately. We have not described Algorithm 8 separately because it contains functions that are called by other unjoin algorithms, and their explanations are already present there.

Algorithm 5 Unjoin mechanism (phase ← Unjoin Request 1)

84. Function unJoinMechansim(ValidatorsNodeIDList, NumberUnJoinmechanism): 85.   phasec ← unjoinRequest1 86.   FOR j = 1 TO NumberUnJoinmechanism 87.     unjoin_request_validator ← CurrentValidatorsList [randomIndex] 88.     broadcast (UNJOINREQUEST1, host, unJoinMessageRequest1) 89.   NEXT 90. upon (UNJOINREQUEST1, host, unJoinMessageRequest1) from unjoin_request_validator while phasec = unjoinRequest1 do 91.   unjoinQueue.append (UNJOINREQUEST1) 92.   logbook.append (UNJOINREQUEST1)     /* after every 20-block creation cycle */ 93.   broadcast (Acknowledgment, all unjoin_request_validator in UnjoinQueue, DefaultUnjoinTime,   BondingTimeStart) 94.   unjoinQueue ← nil 95.   broadcast (LOGBOOK, to all network, logBook) 96.  upon (ACKNOWLEDGMENT, unjoin_request_validator, DefaultUnjoinTime, BondingTimeStart) from host while phasec = unjoinRequest1 do /* Validator that completed bonding time (ExtraBondingTimeDuration + default bonding time) send request2 */ 97.   unJoinMessageRequest2 ← [BondingTimeStart, Total Bonding time, BondingTimeEnd] 98.   broadcast (UNJOINREQUEST2, host, unJoinMessageRequest2) 99.   phasec ← unjoinRequest2

1.

Algorithm 5 Explanation

Lines 84–153 present the unjoin mechanism, which is called in line 16. The unjoin mechanism also has three functions: unjoinMechansim, createUnjoinBlock, and DiscardUnjoinRequest. The unjoinMechansim function calls the other two functions in it. In lines 85 to 89, multiple validators send an unjoin request 1 to the network and host. In lines 90–95, the host receives an unjoin request 1 and saves it in the unjoin queue. If the block creation reaches 20, the host releases an acknowledgment to all unjoin request validators and broadcasts the logbook to all networks. In lines 96–99, upon receiving an acknowledgment, the nodes begin passing their bonding time. After completion of the bonding time, the validator sends an unjoin request 2 to the host.

Algorithm 6 Unjoin mechanism (phase ← Unjoin Request 2)

100. upon (UNJOINREQUEST2, host, unJoinMessageRequest2) from unjoin_request_validator while phasec = unjoinRequest2 do 101.   logbook.append (UNJOINREQUEST2) 102.   If valid(UNJOINREQUEST2) then 103.   Queue.append (UNJOINREQUEST2)             * if host is free*/ 104.   If Queue [0] = UNJOINREQUEST2 then 105.     PreviousBlockHash ← Hash(Last block of ValidatorChain) 106.     BlockNumber ← BlockNumber + 1 107.     penalty ← Penalty[unjoin_request_validator] 108.     unJoinTimeStart ← CurrentTime 109.     UnjoinRequest2ReceiveTime ← Received time 110.     unJoinParameters ← [BlockNumber, CurrentTime, PreviousBlockHash, TotalValidator,                 penalty, unJoinTimeStart, UnjoinRequest2ReceiveTime] 111.   broadcast (UNJOINPARAMETERS, unjoin_request_validator, unJoinParameters) 112.   Queue.remove([Queue[0]) 113. upon (UNJOINPARAMETERS, unjoin_request_validator, unJoinParameters) from host while phasec = unjoinRequest2 do 114.   unbondTransaction ← Transaction to unbond stake 115.   DateTimeunbondTransaction ← unbond Transaction Time 116.   StakeValue ← unBond Transaction Amount Value 117.   unbondTransactionDetails ← DateTimeunbondTransaction + StakeValue 118.   broadcast (TRANSACTION, unjoin_request_validator, unbondTransaction,                     unbondTransactionDetails) 119.   signedBlock ← Function CreateUnJoinBlock (unjoin_request_validator, unJoinParameters,                 unbondTransaction, unbondTransactionDetails) 120.   broadcast (BLOCK, All_node, signedBlock, unJoinTimeStart) 121. upon (BLOCK, signedBlock, unJoinTimeStart) from unjoin_request_validator while phasec =                               unjoinRequest2 do 122.   if valid(signedBlock) then 123.   SignedAcceptMessage ← Accepted + Asymmetric Encryption by key [Hash(Accepted)] 124.  broadcast (MESSAGE, Sender_node, unjoin_request_validator, SignedAcceptMessage,                             unJoinTimeStart) 125.  upon (MESSAGE, Sender_node, unjoin_request_validator, SignedAcceptMessage, unJoinTimeStart)                         from other_nodes while phasec = unjoinRequest2 do 126.   ProofSignedMessage.append (ProofSignedMessage)         /*after receiving 2/3 accept messages from others */ 127.   unJoinMessageRequest3 ← [signedBlock, ProofSignedMessage, unJoinTimeStart] 128.   broadcast(UNJOINREQUEST3, host, unJoinMessageRequest3) 129.   phasec ← unjoinRequest3

2.

Algorithm 6 Explanation

In lines 100 to 112, if the host is free, the host releases the unjoin parameters to the first received unjoin request 2. In lines 113–120, having received unjoin parameters from the host, the validator first creates and broadcasts an unjoin bond transaction. Second, the validator creates an unjoin block by calling the function CreateUnJoinBlock from algorithm 8 lines 144 to 150 and broadcasts it to the network. In lines 121 to 129, upon receiving a valid unjoin block and bond transaction, the network nodes send an accept message to the unjoin validator, and if the validator receives a two-thirds accept message, the validator generates an unjoin request 3 to the host.

Algorithm 7 Unjoin mechanism (phase← Unjoin Request 3)

130. upon (UNJOINREQUEST3, host, unJoinMessageRequest3, unJoinTimeStart) from unjoin_request_validator while phasec = unjoinRequest3 do 131.   logbook.append (UNJOINREQUEST3) 132.   if (CurrentTime − unJoinTimeStart) < UnJoinAsValidatorTime then 133.     if valid(signedBlock ∧ ProofSignedMessage) then 134.       ValidatorChain.append (signedBlock) 135.       TotalValidator ← TotalValidator − 1 136.       Wallet[NodeNumber].append (unBond Transaction) 137.       CurrentValidatorsList.remove(ValidatorNumber) 138.     else 139.     Function DiscardUnjoinRequest() 140.   else 141.   Function DiscardUnjoinRequest() 142. upon (UNJOINREQUEST3, host, unJoinMessageRequest3, unJoinTimeStart, nil) while (CurrentTime − unJoinTimeStart) > UnJoinAsValidatorTime do 143.  schedule DiscardUnjoinRequest() implemented after UnJoinAsValidatorTime

3.

Algorithm 7 Explanation

In lines 130–141, the unjoin block is accepted by the host if the host receives a valid message request 3 within the unjoin as the validator time; otherwise, the host discards the unjoin process by calling the function DiscardUnjoinRequest from Algorithm 8 lines 151 to 153. In lines 142 and 143, if the host does not receive unjoin request 3 and unjoin as the validator time exceeds, the host discards the unjoin request process and frees itself.

Algorithm 8 Sea Shield unjoin mechanism (functions)

144. Function CreateUnJoinBlock (unjoin_request_validator, unJoinParameters,                   unbondTransaction, unbondTransactionDetails): 145.   ClosingNumber ← 1 + ClosingNumber [unjoin_request_validator] 146.   ValidatorDetail ← NodeNumber + unjoin_request_validator + CurrentTime_h + “Inactive” +                     ClosingNumber + Penalty + TotalValidator 147.   Requirement ← unJoinBondTimeStart + DefaultUnjoinTime + ExtraBondingTimeDuration+               TimeMessage2 + DateTime_t + StakeValue + WalletProof 148.   Block ← ValidatorDetail + Requirement 149.   Header ← BlockNumber + Hash(Block) + “unjoin as validator” + PreviousBlockHash +                         CurrentTime_b 150.   RETURN signedBlock ← (Header + Block) + Asymmetric Encryp. By key [Hash(Header + Block)] 151. Function DiscardUnjoinRequest(): 152.   unJoiningRequest3 ← nil 153.   BlockNumber ← BlockNumber − 1

5. Experiment and Evaluation

As per the literature, we have three generations of blockchains. The first generation includes Bitcoin [16], LiteCoin [55], and others; however, it has its limitations. To cope with first-generation blockchain limitations, the second generation has evolved. It includes Ethereum [12], Tezos [56], EOS [48], and other blockchain platforms. The second generation uses pre-written programmed logic to create and manage their data. The second generation works well; however, when users or transactions increase, a critical performance drop is observed. That is why the third blockchain generation is initiated.

The third generation is called heterogeneous blockchains. The third-generation platforms contain constructors that allow users to create and run their blockchains with expanded options. Heterogeneous networks, such as Cosmos [21], Polkadot [57], and Avalanche [58], create a global network that is more efficient in terms of throughput than previous generations. The platform allows the communication of a specialized blockchain with multiple other blockchain networks as required. The validator chain may support a POS-based consensus.

1.

Implementation

We designed an asynchronous heterogeneous network model [59] for implementation. Asynchronous means that there is no assumption of timing. Any node can generate a join or unjoin request message at any time in the network. The system is based on Byzantine fault tolerance; the network may live under malicious nodes. To evaluate the mechanism, we implemented a prototype on C#. All cryptographic functions are generated using standard cryptography algorithms, such as (RSA [60] used to create digital signatures, encryption, decryption, and key generation) and the SHA-256 algorithm [24], for entirely hashing operations, where every single node is connected to two other nodes in the system for message propagation.

We use exponential distribution [61] to calculate the propagation delay in our broadcast. Algorithm 9 presents the function ExponentialDis for calculating the propagation delay. We input a maximum value of 1.5 and a minimum value of 0 to the function to obtain a new value for a delay during each broadcasting. We used 100 samples to calculate the average mean propagation delay. The average mean propagation delay used in broadcasting was 0.2 milliseconds. We set (join and unjoin as validator) time as (total_number_of_node + 200) seconds for the test runs.

Algorithm 9 Calculation for propagation delay

FUNCTION ExponentialDis (MaxVal, MinVal)   MaxVal ← 1.5   MinVal ← 0   lambda ← 1.0   result ← MaxVal   DO    u ← sample taken from uniform distribution on unit interval (0,1)    t ← −log(u)/lambda    increment ← MaxVal − MinVal/6.0    result ← MinVal + (t * increment)   Until result ≥ MaxVal Return result

1.1.

System Configuration

Sea shield is based on a PoS-Pbft design that does not require heavy machinery to run.

Table 2. System configuration used for simulator implementation.

System Configuration	Detail
OS Name	Microsoft Windows 10
System Type	x64-based PC
Processor	Intel(R) Core(TM) i7-7700 CPU @ 3.60 GHz,
	3600 Mhz, 4 Core(s), 8 Logical Processor(s)
Installed Physical Memory (RAM)	16.0 GB
Available Physical Memory	7.30 GB

shows the system configuration of the machine that is used to execute the simulation environment.

1.2.

Network Size

Network size generally refers to the number of nodes attached in the system. We used a number of nodes in the range of 0 to 150 for the test run of the simulator for collecting results.

1.3.

Minimum Node Requirement

Our simulation operates at a minimum of five nodes. The network must have five or more nodes in the system to execute the block creation process because to finalize the block, the join/unjoin request sender node requires two-thirds of the total nodes’ accepted messages.

1.4.

Number of Transaction

The block will contain only one transaction, either join or unjoin. The network may set the block size as per their requirement. We generated random transactions for our simulation.

1.5.

Node Behavior

We evaluated and noted the behavior of our simulator with normal nodes under normal conditions and with malicious node activity under different conditions.

2.

Evaluation

The simulator operates under 35 different conditions to analyze the join and unjoin mechanisms and their security. Below, we discuss the conditions in summary (join/unjoined together):

1.

All nodes of the network do not receive join/unjoin parameters from the network or the host does not send join/unjoin parameters to all nodes.

Result: The node that did not receive the join/unjoin parameters from the host discards the block received from the node. To accept a block, a node must receive parameters from the host before receiving the block from the node. The node matches the parameters sent by the host to the network from block parameters. Therefore, the node cannot manipulate the block parameters.

2.

The nodes receive a forged transaction stake value in the transaction with the correct wallet proof in the network. Alternatively, we forged stake values with the wrong wallet proof.

Result: Every node verifies the transaction from its wallet by using a zero-knowledge proof [62]. If the transaction is not valid, the node will reject the transaction.

3.

Transaction received with backdate or time; change bond transaction creation time.

Result: Every node checks whether the bond creation time is backdated/time or when the node rejects the transaction.

4.

The node submitted a late join request 2 or unjoin request 3 to the network/administrator/host.

Result: The host rejects the request of the node if the allocated “join/unjoin as validator time” exceeds.

5.

Nodes received a bond stake value that is different in the block from a transaction.

Result: The bond stake value in the transaction and block should be similar; nodes that find different values will reject the block.

6.

The host received join request 2 or unjoin request 3 from a node with all the required proof within the allocated “join/unjoin as validator time”, although the host does not receive a block or transaction from the node during block creation.

Result: The host validates the block, and if everything is correct, the host updates the ledger.

7.

Only the host received the correct block, and all nodes received a forged block, a block having manipulated the bond stake value.

Result: The host validates and accepts the block, but all other nodes reject the block, and the block creator does not obtain a two-thirds accepted message for the block. The node will not provide an accepted message proof to the host. After allocating the join/unjoin time as the validator, the host rejects the request and releases similar parameters for the next request.

8.

Nodes received a block with changed extra bond time.

Result: Nodes received an extra bond time with a transaction message as well, and they compared the extra bond time of transactions and blocks. If the block does not contain a similar time commitment, it is rejected by the node. The node validates the block by comparing the digital signature with the block hash. If the block matches the digital signature, it is considered unforged and created by the block creator. Under this condition, if nodes find different extra bonding times in the block from a verified transaction, the node may report a forgery complaint against the block creator to create a forged block.

9.

A transaction with extra bonding time is not received by all nodes of the network for any reason.

Result: Nodes that do not receive transactions reject the block, if two-thirds of the nodes receive the transaction and give an accepted message to this block, then the block is accepted. In this condition, the nodes that reject the block will ask the host to send the last block if they remove the block from their ledger, because the ledger is sequential, and the next block they receive from the network contains a block number (n + 2).

10.

The host does not receive two-thirds proof or less than two-thirds proof in join message request 2 or in unjoin message request 3 from the nodes.

Result: If the received join request 2 or unjoin request 3 from the node does not contain two-thirds proof, the host will reject the request and will release similar parameters to the next join/unjoin request.

11.

The request logbook is not sent to all nodes, or all nodes do not receive a request logbook from the host.

Result: After every 20-block creation cycle, the host releases an acknowledgment of all unjoin request and then releases a request logbook in the network that contains all received requests between the last 20-block creation cycle. If the node does not receive the request logbook from the host, it can request the host to send the request logbook. The request logbook for nodes is very important because it is needed for the verification of unjoin transactions and blocks. When a node receives an unjoined transaction from a validator, it first verifies its ID in the request log from the host because before an unjoin transaction the validator must be acknowledged by the host on request 1. The transaction will only be accepted when a recent logbook from the host contains an unjoin request 1 from the validator to the host.

12.

The validator sends an unjoin message request 2 to the host without completing the bonding time.

Result: If the host receives an unjoin message request 2 from the validator, it must verify the request before accepting it. The host accepts the unjoin message request 2 if the committed bonding time from the node has been completed in the network after receiving the acknowledgment from the host on request 1. If the validator has passed that time in the network, then unjoin request 2 is accepted and proceeded by the host; otherwise, the request is rejected and discarded by the host and the validator needs to restart from request 1 if it still wants to leave the validator responsibility in the network.

13.

Validator sends cancellation request of its unjoin message 1 to the host.

Result: The host cancels the unjoin message request 1 if the acknowledgment has not been sent by the host. Once the host releases acknowledgment on unjoin message request 1, the unjoin request cannot be reverted or canceled.

14.

Block received with manipulated closing number, penalty amount, bonding time, unjoin request 1 date time or unjoin request 2 date time.

Result: The node verifies all of these details in the block from the unjoined parameters received from the host. The node may also confirm the closing number and bonding time from the validator chain and unjoin request1 date time from the request log. If the data do not match, the block is rejected by the node. The node verifies the block creator by verifying the digital signature of the block. If the block hash and digital signature match the node, this may raise complaints against the block creator to create a forged block; otherwise, it is considered a network attack, and the block creator is not responsible for the manipulated data in the block.

15.

Node sends an unjoin transaction or block without completing its bonding time.

Result: When the node receives an unjoined transaction or block from the validator, it first verifies its completion of the bonding time. The start of bonding time is presented in the request log by subtracting the current time. If the required bonding time is not completed, the node rejects the block or transaction.

16.

Ultimately block rejection.

There are two reasons:

Result: If the node receives a block that contains the transaction and for any reason, the transaction is already rejected by the node, the received block will also be rejected by the node.

Result: Every node that receives the block first verifies the correctness of the block by comparing the block hash with a digital signature. If the block hash does not match the digital signature the block is rejected.

6. Discussion

6.1. Comparative Analysis of the Inside Characteristics of the Consensus

The comparative analysis of consensus with other blockchains is a good source for understanding the internal features of a consensus. Therefore, we performed a comparative analysis using a blockchain trilemma to review the internal characteristics of the Sea Shield. The blockchain trilemma is a tradeoff between three properties: security, scalability, and decentralization of blockchain technology. In the literature, subcategories are available for the blockchain trilemma. Stefanoz et al. [63] presented the presto framework in relation to the blockchain trilemma through which consensus can be compared and understood. This framework is based on optimality, stability, efficiency, robustness, and persistence. Figure 9 shows the framework in relation to blockchain trilemma and its subcategories for Sea Shield comparison. We chose the sub-categories of the presto framework related to our consensus. We described (1) Optimality as Liveness and Safety, (2) Robustness as Fault Tolerance and Resilience to Attack, (3) Stability as Block Proposer, Transaction Pool, Incentive, Fairness, and Decentralization, (4) Persistence as Fork Control and Governance, and (5) Efficiency as Communication Message Overhead, and Throughput.

1.

OPTIMALITY

• Liveness:

Some consensus mechanisms such as PBFT [10] use the concept of Byzantine fault tolerance (BFT) to achieve liveness. Similarly, we also use the concept of Byzantine fault tolerance to create join and unjoin blocks, because the design ensures the liveness of the network. In this design, the network node reaches a consensus even in the presence of malicious actors. The consensus requires a minimum of five nodes to run. Because to create a block, the node requires two-thirds of the total network nodes’ response. The Sea- Shield also uses the host concept. To maintain the liveness of the network, the host must be responsive and perform adequately. Otherwise, the liveness of the network may come in a risky state.

• Safety:

We have applied blockchain technology to keep a record of the validator’s information secure; however, security issues are present in both traditional computing environments and blockchain. The same attack is possible in both environments but in a different manner. A few attacks are discussed below:

1. Denial of service: In a traditional computing environment when a system cannot respond to the user due to received requests higher than the target or its capacity, this is called a denial of service attack. In the blockchain, when more transactions are produced and submitted by users to crash the blockchain network, this is considered a denial of service (DoS) attack. In Sea Shield, this attack is not possible because a transaction is performed after receiving the host parameters, and the host does not release multiple parameters at similar times. Even now, if the user or multiple users create an excessive transaction it would be of no use because the only one that uses this transaction in the block is itself and if multiple forged blocks are created without host parameters it can slow down the process; however, later the system can recover from it because every block has its digital signature and nodes to verify every block by its signature and host parameters, so if such situations happen, the network nodes will reject all forged blocks and a penalty will be applied on those nodes.

2. Intentional Misuse: Both traditional and blockchain environments encounter this type of attack. In traditional networks, internal users or clients attack the system intentionally to obtain benefits. In blockchain, this type of attack occurs as in Bitcoin [16]. If more than 50% of the network processing power is controlled by one entity or a single group, it can weaken the network by creating and obtaining incentives for their block from the network. This attack can also weaken the Sea Shield if more than two-thirds of nodes of the network become faulty and accept blocks with forged transactions. However, if any of the nodes or host finds forgery, the block can be rejected because the transaction has a wallet proof, and the wallet proof can be verified by anyone through zero-knowledge proof in the network.

3. Endpoint Security: Traditional infrastructure and blockchain environments are quite different, but both face endpoint security issues. In traditional infrastructure, endpoint security is the process of securing all the points that are connected to the network, such as user devices, servers, tablets, and virtual environments, from malware, spyware, and computer viruses in many ways, such as using antivirus or more. In a blockchain environment, nodes are considered endpoints because they interact with the blockchain environment to input data such as creating transactions and achieving consensus. Like other blockchains, the Sea Shield also reduces security issues by using public key cryptography and decentralization. Nodes use keys to digitally sign transactions and blocks, which is why the security of the keys should be high. Keys can be stolen and used to perform malicious activities in the network; therefore, keys should not be in emails, computers, or inside files. We suppose that cloud protection is a good solution for securing keys. There are many cloud security services available in the web market for eliminating endpoint security risks, such as CASB products [64].

2.

ROBUSTNESS

• Fault Tolerance:

There are many blockchains in the literature, but all cannot achieve consensus in the presence of malicious nodes. To work with faulty nodes, the BFT design is considered the best, which is why several algorithms use the BFT design to obtain block finalization, such as Algorand [43] and PBFT [10]. The Sea Shield is based on the BFT design. In the BFT design, positive response of two-thirds of the nodes can lead to achieving consensus in the network. In the Sea Shield, to confirm the join and unjoin blocks, the node needs to receive two-thirds acceptance from the other nodes of the network, if the remaining one-third of the nodes have become faulty and do not respond, even so a block will be created. The total fault tolerance of the Sea Shield is 33%. The network may work under one-third of faulty nodes.

• Resilience to Attack:

In this mechanism, there is the concept of a penalty for nodes that are found guilty by the network. If forgery is reported against the node for creating a forged join block and the network finds it guilty, then the network can punish the node by imposing a penalty on it or removing it from the network. If the validator creates a forged unjoin block and the network finds it, then the host can impose a penalty, which can be deducted from the stake amount of the validator. Attacking the Sea Shield blockchain is difficult because, like other blockchains like Bitcoin [16], it also uses different types of cryptography, such as public-key cryptography, zero-knowledge proof, and hash functions. The wallet proof is also cryptographically hashed; we used a zero-knowledge proof to verify the transaction.

3.

STABILITY

• Block Proposer:

PBFT or other blockchain algorithms such as Tendermint [11] require a block proposer to create a block for the blockchain. Sea Shield does not require an additional block proposer selection algorithm or round to select a block proposer for the validator chain. The nodes or validators of the network itself create a block according to their requirements. In other blockchains, the finalization of transactions is pending, which is why continuous block production is necessary for the stability of the network. However, the Sea Shield is a special purpose blockchain and it does not require continuous block production because there are no extra transactions.

• Transaction Pool:

Sea Shield does not require a transaction pool like other Cosmos [21] because there are no additional transactions in the block; the only transaction that is present in the block is created by the block creator itself.

• Incentive Mechanism:

1. Transaction Fees: In other blockchains, such as Bitcoin [16], anyone generates a transaction and attaches fees to the transaction to make it more attractive to the block creator. Mostly, the block creator takes transactions into their blocks according to the fees attached to them. In Sea Shield, there is no transaction fee because the block creators are the ones that generate transactions and create a block with its transaction.

2. Block Proposer Reward: To maintain the stability of the network, almost every blockchain provides incentives to block proposers to obtain attention of nodes toward the consensus process. Sea Shield does not need to incentivize block proposers because if nodes want to obtain a block proposer incentive of the main blockchain, they have to become validators first, and to become a validator they need to create a join block, or if they are required to take their stake back, they have to create an unjoin block for itself.

3. Block Validation Reward: To further stabilize the network, the Sea shield blockchain network provides an incentive to the first two-third nodes that validate the join/unjoin block and send an accept message to the block creator. To customize similarly to other blockchains DPoS [20], the Sea Shield validator may share its block reward for creating a block in the main blockchain with the nodes that give it an accept message to its join block. The Sea Shield incentive mechanism can be customized according to the needs of the main chain.

• Fairness:

To achieve fairness, we broadcast the request logbook of the host so that all nodes know about the operation of the host. Join blocks, unjoin blocks, and accept messages are digitally signed by creators using public-key cryptography. The digital signature provides authentication, integrity, and nonrepudiation of the received blocks and messages. The nodes have an open right to accept or reject the created block for the validator chain, as in other blockchains like Bitcoin [16]. Unjoin request 1, join parameters, and unjoin parameters are broadcast to the entire network so that every node knows the status of the validator’s node. Sea Shield observes complete transparency; data stored in the blockchain can be accessible to all and its integrity can be verified.

• Decentralization:

The Sea Shield design is ideal for a public permission blockchain network. This type of network is typically developed mostly within one industry or between several companies that have mutually agreed upon it, such as Quorum [65]. In Sea Shield, every node is equally privileged; we have a concept of the host in the mechanism, any node or software or moderator can be the host and fulfill the responsibility. Host work is open to everyone in the network. The host activity is monitored by nodes and if the host does any forgery network, its members may change it. The host is only responsible for releasing join/unjoin parameters, but the decision of the new block is taken by the nodes of the network.

4.

PERSISTENCE

• Fork Control:

The validator chain retains all the staking information of a validator, and we have already discussed the importance of this data in the blockchain network in Section 2. Sea Shield does not allow a fork in the validator chain as in other blockchains like Bitcoin [16] because we cannot lose any validator’s information due to the fork. The forking issue has already been discussed in other blockchain networks in Section 2. Every accepted validator’s information as a block must be part of everyone in the validator chain. The replicated ledger should be similar to a network. To control for the forking issue, we compromise on time because it is not a main chain. We prioritize linearity and security over high throughput for this chain. We slowed down the consensus process by introducing a wait time for the host. We also do not want a quick process for the join/unjoin validator mechanism because of security issues. Our main focus is to keep our blockchain ledger linear and secure for everyone. Below are the two situations that may appear in the network and how the validator chain deals with these conditions:

Condition 1: If the validators of the network receive multiple blocks with a similar block number for the validator chain, the validators will discard all similar blocks and only keep a block that has the latest Date Time (h) in between all similar blocks for the validator chain. The latest Date Time (h) shows that the host released the parameters to the next request and discarded the previously released request. Therefore, the block created based on the previously dated time (h) parameters should also be discarded.

Reason: This occurs when the network host releases parameters to the node or validators upon its request to create a block for the validator chain. By using these parameters, nodes or validators create the block and broadcast it to the network but the node/validator cannot receive a two-thirds acceptance message for the block or, for any reason, cannot complete the join/unjoin mechanism within the join/unjoin as the validator time. In this condition, the network host discards the node’s request and re-issues these parameters, except the Date Time (h), to the next request in the queue. The next requested node/validator creates a block using these parameters and broadcasts it to the network.

Condition 2: If a validator directly receives, for example, block (4) after block (2), as shown in Figure 10, this means that block (3) is missing, and the validator does not receive block (3) for the validator chain. The validator must ask block (3) from the network to maintain its validator chain ledger.

Reason: The blocks are created using a sequential block number from the network host. The network host does not generate block number four without creating block number three. As discussed above, the network host repeatedly releases similar parameters to the nodes until any node creates and finalizes a block with the network’s host-released parameters.

• Governance:

We suppose that open governance or off-chain governance would be suitable for the Sea Shield. There are several governance models in the literature [66]. In open governance, network members choose the team by mutual concern, and the team sets the rules for the network. In off-chain governance, decisions are not made in a traditional formal format. The stakeholders use many ways to communicate, such as social media, conferences, and events, to decide on the new rule set. The Sea Shield implementer may need to set rules for join as validator time, unjoin as validator time, default bonding time, penalty amount, and incentive amount.

5.

EFFICIENCY

• Communication Message Overhead:

1. Join Mechanism: Sea Shield used the concept of PBFT for block creation and finalization. The communication overhead of the PBFT algorithm is discussed in Section 2. The PBFT consensus algorithm has quadratic message complexity. The message complexity of the Sea Shield join mechanism is O(N2). In terms of the joining node, the total required communication message in the join mechanism sent and received by the node is ((5 + 2N) + 2N), where N represents the message broadcast to all networks in which 5 + 2N is required and 2N represents extra layers for security. A total of four messages are received from others while ((3 + 1N) + (1N)) is sent by the join node, in which (3 + 1N) is required and 1N is an extra layer for security. There are two required overall network broadcasting messages, one from the join request node to all network nodes, and one from all network nodes to the join request node to complete the joining mechanism. Figure 11 shows two extra layers for security, and the join mechanism can be completed without broadcasting these two messages. We apply these two broadcasts to improve the overall consensus mechanism security. The host sends join parameters to all network nodes because the network nodes compare the received join parameters from the host to the join block. Except for the date parameter, all join parameters are also available in the last block of the validator chain, and the nodes also need to be verified. The join request node broadcasts bond transactions to all network nodes, although a similar transaction is present in the join block. We applied these layers to reduce the security risks. The nodes verify the transaction from the wallet proof and then verify the block transaction to its already received verified transaction. It is also possible that the join request node directly sends a block with the transaction, and all network nodes verify the transaction from the wallet proof. This is a customizable use case, and both extra layers can be removed according to the network requirements. This is mostly dependent on the data sensitivity of the main chain.

2. Unjoin Mechanism: The message complexity of the Sea shield unjoin mechanism is O(N2). In relation to the unjoin validator node, the required total communication message in the unjoin mechanism is ((7 + 3N) + 3N), where N represents the total message broadcast, in which (7 + 3N) is required and +3N is an extra layer to increase security. A total of four messages are received from others to unjoin the validator, while ((4 + 1N) + 2N) is sent by the unjoin request validator, in which (4 + 1N) is required and 2N is an extra layer for to increase safety. There are three required messages that should be broadcast to the whole network, such as request logbook from the host, block from unjoin request validator, and accept messages from all network nodes. In Figure 12, there are three extra layers for security shown. These layers were applied to improve the security of the unjoined mechanism. The purpose of the unjoin parameters from the host and unjoin transaction from the unjoin request validator broadcasted to the whole network is the same as the join mechanism, and we have already discussed this. The unjoin request node broadcasts unjoin request 1 to all network nodes so that everyone in the network knows that it will soon leave the network. The network node requires these details to verify the unjoin transaction because unjoin request 1 must be received before receiving the unjoin transaction. This broadcasting can be omitted because an unjoin request 1 of the node is also present in the host request logbook, and the host already releases this request book to the entire network after acknowledging the unjoin received requests. We discussed five extra layers of communication messages overhead in the Sea Shield. The Sea Shield user may remove these extra layers, according to the required safety level. We applied these layers to ensure the security of the Sea Shield because the main chain can improve itself in terms of throughput by using its secure mechanism.

• Throughput:

We have already discussed the block creation process of the join and unjoin mechanisms. Based on our simulation results, the average join block creation time is 3.4 s when the number of nodes is five; likewise, the average block creation time of an unjoin block is 12.1 s when the number of nodes is 20. We tested unjoin block creation with a minimum of 20 nodes because we discussed that a validator can unjoin itself after a 20-block creation cycle in the network. The time of block creation gradually increased with an increase in the number of nodes in the network. Figure 13 and Figure 14 show the block creation times of the joined and unjoined block, respectively.

We calculated the confidence level considering an alpha value of 95%. Considering the confidence interval values, the results are ensuring that the 95% of samples are in the range from 3.43571127 ± 0.215138962 for join block creation when the number of nodes is five to 12.1953388 ± 0.326131099 for unjoin block creation when the number of nodes is twenty and so on. Figure 15 and Figure 16 show the block creation time with the error bar of the joined and unjoined block, respectively.

The average block creation time of the Sea Shield is 11.7 s on 20 nodes. Figure 17 shows a comparative analysis between the average join block creation time, average unjoin block creation time, and average block creation time. We observed that the average block creation time increases with an increase in the number of nodes in the network.

We did not control the node number/validator number in our consensus because of security and decentralization; who is becoming a validator and leaving its responsibility as a validator in the network should be known by everyone in the network, which is why they all respond to block creation. Blockchain technology is used by different industries according to their needs, if they want to reduce or fix the block creation time, they can modify the mechanism according to their data sensitivity. The network can reduce or fix the total node number using the aging technique to control the time increment of block creation due to increasing node numbers. A group of two-thirds of the most senior nodes in the network will respond to the join and unjoin blocks, which will reduce the communication overhead and block creation time of the mechanism, and the final created block will be broadcasted to the entire network. The network determines the time duration for the node to become a senior node in the network.

We discussed an extra layer of security in the communication message overhead. We analyzed the effect of the extra broadcasting layer on block creation time. In join block creation, the host broadcasts the join parameters to all nodes, and the join request node broadcasts bond transactions to all nodes. We removed these extra layers and noted their effect on the join block creation time.

We observed a decrease of 0.00432474 s time duration in the join block creation time without broadcasting join parameters by the host to all when the system has five nodes and a decrease of 0.00088374 s time duration in the join block creation time without broadcasting bond transactions by joining the request node to all five nodes.

Figure 18 shows a comparison between the average join block creation time when the host does not send join parameters to all and when the join request node does not send bond transactions to all with the average join block creation time. We removed the extra layers of security and observed a decrease in time; the total decrease in time was 0.00520848 s in the average join block creation on five nodes. Figure 19 shows a comparison between the average join block creation time and the join block creation time without broadcasting both extra layers of security. Similarly, we observed the unjoined block creation time without an extra layer for security. We have removed the broadcasting unjoin parameters by the host to all in unjoin block creation, and a decrease of 0.09326934 s was observed while the number of nodes in the system was 30. We also removed broadcasting of unjoin bond transactions to all by a node in unjoin block creation and a decrease of 0.07465962 s was observed while the number of nodes in the system was 30. We also removed the broadcasting of unjoin bond transactions to all by a node in unjoin block creation, and a decrease of 0.07465962 s was observed, while the number of nodes was 30.

Figure 20 shows the comparison between three unjoin block creation times, unjoin block creation time without broadcasting unjoin request 1, unjoin block creation time without broadcasting unjoin bond transactions, and broadcasting unjoin parameters by the host. After removing all extra layers of broadcasting in unjoin block creation, we observed the total time taken for average unjoin block creation was 17.13 s on 30 nodes. Figure 21 shows a comparison between the average unjoined block creation time and the unjoined block creation time without any extra broadcasting layers.

The Sea Shield block creation was based on the BFT concept. We compared the Sea Shield block creation time (with all security layers) with the PBFT-based consensus using a simulation. The block creation time of other PBFT-based consensus on simulation was affected by the number of transactions in the block; Figure 22 shows that PBFT consensus block creation time increases with the increment of transactions in the block. However, the Sea Shield block creation time was not affected by the number of transactions in the block because the Sea Shield does not contain extra transaction numbers in the block.

We developed a simulation environment for the Sea Shield with two numbers of connections, where every node is connected to two or more nodes to send or receive messages. We also observed that the number of connections affects the total block creation time of PBFT consensus during simulation. We compared the PBFT-based consensus with two connections and the PBFT-based consensus with connected to all other nodes. Figure 23 shows the block creation time of PBFT-based consensus with a different number of connections. The Sea Shield took 11.70170633 s to create an average block on 20 nodes with two connections while other PBFT-based consensus took 0.302378774 s with two connections and 3.014170098 s when connected to all on 20 nodes. The Sea Shield took a little more time in seconds than the other PBFT-based consensus.

6.2. Comparative Analysis with Another PBft-Based Consensus

We have discussed the internal characteristics of Sea Shield in terms of security, decentralization, and scalability.

Table 3. Comparative analysis of Sea Shield with another Pbft-based consensus.

SECURITY
	ID Management	Longest Chain Rule	Fault Tolerance	Modern Hardware
Sea Shield	Permissioned	No	33%	No
PBFT Based	Permissioned	No	33%/token wealth	No
DECENTRALIZATION
	Incentive Mechanism	Block Propagation	Block Validation	Transaction Finality
Sea Shield	Block verification	Broadcast	Proposer eligibility	Deterministic
	reward for nodes		check/transaction verification
PBFT Based	Block reward for proposer	Broadcast	Proposer eligilibity check	Deterministic
SCALABILITY
	Energy Usage	Scalability	Transaction	Block
		Per Nodes	Verification Speed	Validation Speed a
Sea Shield	Very low	Weak	<2 s	3–5 s
PBFT Based	Very low	Weak	<10 s/high	4–26 s

^a Block validation speed increases with the increment of the number of nodes.

presents the comparative analysis of the Sea Shield with another PBFT-based consensus. The internal characteristics are almost the same as those of the PBFT-based consensus, except for the transaction verification speed, block creation speed, and incentive mechanism.

• Impact on another blockchain network upon using Sea Shield:

Storage: Every network uses some traditional storage for saving the nodes staking information. We introduced Sea Shield, which used blockchain technology rather than using a traditional computing environment to store information. There is no additional storage required for using Sea Shield in the network.

Incentive Mechanism: Every blockchain needs an incentive mechanism to stabilize the network. We have seen in the incentive mechanism that there is no need for a block reward in the Sea Shield. There will be no additional pressure on the network to use Sea Shield in terms of an incentive mechanism.

Computation: The design of the Sea Shield is based on PoS and PBFT. There is no need for additional computation and heavy machinery to run Sea Shield. However, network latency may be affected due to using an additional validator chain.

7. Conclusions

We present Sea Shield, a special purpose consensus to save the node’s information in a validator chain, without forking, when a node becomes a validator/stakeholder and when the validator leaves its responsibility in a PoS-based blockchain network. The design of the consensus is to ensure the security of the overall blockchain. The Sea Shield can be customized and aligned with any current PoS-based blockchain. We compromise on time over security for the Sea Shield because we want a validator to go through a long procedure to join and unjoin itself so that the main blockchain security will not be compromised.

7.1. Limitations

Sea Shield can handle any number of users; however, the design of Sea Shield is ideal when the number of users is finite because it uses the concept of host wait. Therefore, if the number of requests becomes very high, it can collude the system. To maintain the liveness of the system, the host must be active and responsive.

7.2. Future Work

The presented work can be improved in the future in terms of scalability. In the future, we will develop an improved blockchain consensus for the main chain to create and finalize blocks and use Sea Shield to improve its overall security.