HeLa Network’s Modular Design for Enhanced Scalability and Security

To solve the blockchain trilemma, three sectors are taken into consideration: decentralization, scalability, and security.

The HeLa network as a blockchain protocol uses proof-of-stake consensus and Byzantine Fault tolerance to secure its network. With this consensus mechanism, decentralization is not given off due to cheap maintenance and the possibility of anyone being able to run a node.

Security on the other hand is not given off as the BFT mechanism ensures all nodes are functional to share transactional data. To make the network scalable without giving off any other two sectors, HeLa’s ecosystem operates on a modular architecture.

For an overview, the architectural design of every blockchain is dependent on four basic components likewise Hela

These components include:

1. Execution
2. Settlement 
3. Consensus and;
4. Data Availablity.

Execution

This is the processing of transactions into the network. Before a transaction can be executed into the network, it must be validated by nodes before a block can be added to the network. These transactions can include sending cryptocurrency, signing a transaction, or deploying a contract provided that it changes the state of a blockchain.

Settlement

This is a critical component for every blockchain as it deals with the tendency of a blockchain to achieve finality and immutability to transactions made to the network. 

Consensus

 Transactions added to the mempool of a blockchain for execution are validated by the blockchain nodes to settle disputes and issues such as double spending which can be done by blockchain users. The consensus of any blockchain is a process where there is a shared agreement for the validity of a transaction. Some of these agreements may be proof-of-stake – HeLa, proof-of-work – Bitcoin, etc. 

Data Availability

This is the process where data of every transaction is made available to nodes ensuring integrity within the peer-to-peer network.

A blockchain cannot be functional without building its desired architecture on these four components. These four components set a barrier for most blockchain protocols. Barriers include low throughput, uncertainty of finality, low scalability, and possible data fragmentation.

Also read : Solving Gas Fee Volatility with Stablecoins

To break the barriers, protocols may choose to exist as monolithic, polylithic, semi-modular, and Modular blockchains.

In a monolithic blockchain, the settlement, consensus, execution, and data availability are all carried out on one single codebase. Hence the nodes carry out consensus, share data, execute transactions, and ensure settlement. This is a critical constraint for monolithic blockchains regarding scalability and throughput as transactions processed per unit time is low compared to modular blockchains. Users are likely to spend high gas fees when processing transactions due to network congestion.

Modular blockchains on the other hand have different compartments to carry out each of these core components separately and this is how HeLa labs operate to attain security of the protocol, achieve consensus, execute smart contracts and transactions, and bring interoperability.

Let’s take an example for a better understanding of the difference between modular and monolithic chains. In a city A,  one wide road exists for transportation. Cars, trucks, bicycles, pedestrians, motorcycles, and animals all make use of this road, and imagine a different city where there are different roads for all of these different road users. 

In city B, there is a different road where cars drive, a different road for pedestrians and the rest. These two roads in two different cities can be viewed as two different blockchains.

In city A, arrival upon destination would be difficult as road traffic will take place (this is analogous to network congestion). In City B, arrival upon destination will be faster (analogous to a blockchain’s throughput) as different individuals and specific vehicles use different roads.

For a broader understanding, these four components are shared into layers on the HeLa Network and they communicate directly with each other ensuring integrity and achieving the primary function of a blockchain.

How do the Layers in the HeLa Network Communicate?

HeLa network as a modular blockchain carries out the four basic components on different layers and not one. Hence, its different layers work together to achieve consensus, execution, settlement, and ensure data availability. These layers include:

1. Execution layer
2. Consensus layer
3. Storage layer
4. Integration layer

Execution Layer

On the HeLa network, this is the layer responsible for the processing of specific transactions into the network. When a transaction is sent, there is a set of compute nodes responsible for executing the transaction. Once execution has been carried out by this set of nodes, it packages the transaction and sends it to the network through the consensus layer.

The Execution layer has its general environment where developers can create different runtimes for a specific functionality that is dependent on a specific use case. Every runtime created within the execution layer is customized by these developers and maintained by a set of compute nodes and is responsible for executing and processing smart contracts.

Transactions are not sent to HeLa’s official runtime as it has its specific use case which is mainly for flexibility such as management of Hela’s Decentralized Identity (DID), and stable coin transactions. Transactions are sent from a specific runtime and packaged to the consensus layer.
In this architecture, it can be viewed that each runtime has its path for the arrival of proposed blocks.

Consensus Layer

This layer is responsible for the validation of transactions before transactions can be added to the network. It receives specific transactions from the nodes on the execution layer confirming the transaction, execution information, and the state transitions before being added to the blocks.

On the Consensus layer, two parties operate on this layer. The Validators and the delegators. Since HeLa consensus is based on proof-of-stake, the validators are responsible for the adding and verifying of blocks sent from the execution layer and the delegators stake their tokens to desired validators and get rewards or operate a node for a validator and share the rewards.

HeLa network uses two tokens in its ecosystem: the HELA token and the HLUSD. A native token for staking and HLUSD, a fiat-backed native token mainly for gas fees. On the consensus layer, when delegation and staking take place, there transactions are only processed on the Consensus layer and there is no interaction with the execution layer.

Storage Layer

 This is a layer responsible for storing transactional data in the network. In contrast to a modular blockchain like HeLa, in a monolithic blockchain, all the nodes store and download transactional data so that when a block is proposed, they can confirm the integrity of the block.

The more blocks are proposed, to more storage is taken on the nodes, and hence throughput and scalability are reduced. However, to achieve scalability, decentralization is given off.

This is the condition for monolithic blockchains.

HeLa as a modular blockchain achieves scalability and decentralization by creating this layer for the storage of data making it possible for nodes to have more storage and speed. For communication, the storage layer acts as a relay between the execution layer and the consensus layer not for the enhancement of one to work with the other but for flexibility.

Also read : Zero-Knowledge Proofs in Blockchain: A Developer’s Guide

When a node executes transactions, there is a communication between the execution layer and the storage layer where the storage layer keeps the data for every transaction executed and when the execution layer packages and submits blocks to the consensus layer. The validators in the consensus layer verify this block from the storage layer to confirm the integrity of the nodes. 

Integration Layer

On the execution layer where various runtimes can be built and customized for specific use cases these runtimes in most cases will need to communicate with one another. To enhance the flexibility in which these runtimes will be able to communicate, the integration layer acts as a bridge for these different runtimes.

To avoid data segmentation, the integration layer is mainly responsible for the integration of assets across runtimes operating within the execution layer and runtimes outside the HeLa network layers.

During a cross-runtime transfer of assets, there is no crossing of assets instead the integration layer defines a set of cross-communication protocols between these two different runtimes by sending message calls and virtual assets until finality is reached. 

Conclusion

The HeLa architecture has a larger landscape compared to the structure described through the different layers and the image attached above. The full architecture of the HeLa network is designed to operate with various sub-products to achieve high confidentiality, privacy, and security.

These sub-products include HeLa’s decentralized identity (DID) for user privacy, the credential issuer, and the user-friendly DID wallet for the storage of user-decentralized identities. These products covering the HeLa ecosystem will introduce a better user experience opening up new ways to use the blockchain technology.