# HeLa Architecture

Hela is a modular blockchain protocol composed of **four primary layers**:

1. **Consensus Layer** – Secures the network and finalizes transactions.
2. **Execution Layer** – Processes user transactions and applications.
3. **Integration Layer** – Enables cross-runtime and cross-chain interoperability.
4. **Storage Layer** – Guarantees data availability and integrity.

This layered design separates concerns, ensuring scalability, security, and flexibility for future upgrades.

### 1. Consensus Layer

The Consensus Layer ensures **agreement on the canonical state** of the blockchain. Hela currently leverages the **Tendermint Byzantine Fault Tolerant (BFT) consensus protocol**, providing fast finality and resilience against malicious behavior.

#### Responsibilities

* Finalize transactions into canonical blocks.
* Enforce validator participation rules and slashing conditions.
* Maintain liveness and safety of the network even in adversarial settings.

#### Key Properties

* **Instant Finality**: Transactions are finalized in one block (no need for multiple confirmations).
* **Fault Tolerance**: Secure against up to **1/3 malicious or faulty validators**.
* **Slashing**: Validators engaging in double-signing, downtime, or other misbehavior are penalized.
* **Delegated Proof of Stake (DPoS)**: Non-validator token holders (delegators) can delegate stake to validators and earn rewards, ensuring power is not concentrated.

#### Security Considerations

Validators act as referees of the system. Misbehavior is disincentivized through slashing and possible removal from the validator set.

### 2. Execution Layer

The Execution Layer is responsible for **processing transactions and executing application logic**. It is modular and runtime-based, allowing different types of applications to run in isolated environments.

#### Responsibilities

* Execute smart contracts and application logic.
* Maintain runtime-specific state machines.
* Support confidential and public applications.

#### Structure

* **Runtimes (ParaTimes)**: Independent execution environments (mini blockchains) on top of consensus.
  * Each runtime has:
    * Its own **state machine** (rules and logic).
    * **Compute nodes** (to process transactions).
    * Isolated application environments.

#### Execution Flow

1. User submits a transaction to a runtime.
2. Compute nodes process the transaction and update local state.
3. Results + new state are bundled into a block.
4. Block is submitted to the **Consensus Layer**.
5. Consensus finalizes and stores the block in the canonical chain.

#### Security Considerations

* Compute nodes must **stake HeLa tokens** to participate.
* Malicious or incorrect execution leads to **slashing**.
* Separation of consensus and execution layers allows independent upgrades.

### 3. Integration Layer

The Integration Layer provides **secure interoperability** between runtimes and external chains. Unlike traditional “bridges,” Hela avoids moving assets physically; instead, it uses **message passing and abstraction of ownership**.

#### Responsibilities

* Enable **cross-runtime asset management**.
* Provide **cross-runtime communication protocols**.
* Support integration with external chains.
* Offer privacy, identity, and other services “as-a-service” to external ecosystems.

#### Key Innovations

* **Abstracted Assets**: Tokens remain anchored in one place; ownership is virtually represented across runtimes.
* **Cross-Runtime Protocols**: Enables interactions like “execute contract in runtime A, trigger action in runtime B.”
* **Atomic Multi-Runtime Operations**: Supports cross-runtime flash loans, atomic swaps, and multi-contract workflows.

#### As-a-Service Layer

Other blockchains can leverage Hela’s integration layer for:

* **Privacy-as-a-Service**
* **Decentralized Identity (DID)-as-a-Service**
* **Cross-chain execution logic**

#### Security Considerations

* Integration relies on the **Consensus Layer** for safety.
* If consensus security is compromised, interoperability guarantees are weakened.

### 4. Storage Layer

The Storage Layer ensures **data availability, redundancy, and integrity** across the network. It provides verifiable guarantees that all necessary data is stored, retrievable, and tamper-proof.

#### Responsibilities

* Store the full blockchain ledger and runtime states.
* Ensure **data availability** for all participants.
* Detect and prevent tampering or withholding attacks.

#### Techniques Used

* **Data Availability Sampling**
  * Nodes check random subsets of data to probabilistically ensure full availability.
* **Erasure Coding**
  * Data is split and redundantly distributed, ensuring recoverability even if parts are lost.
* **Merkle Trees**
  * Cryptographic structure for verifying data integrity. Even a single altered transaction can be detected.

#### Security Considerations

* Protects against **withholding attacks** where data is selectively hidden.
* Ensures historical immutability and tamper resistance.

### Please Note : 

> At present, HeLa Chain does not maintain a dedicated integration layer as a separate architectural component. Instead, certain elements of the integration layer are embedded within the storage layer, functioning collectively as a unified system.
>
> While this design provides stability and efficiency in the current phase, our long-term roadmap includes the development of a fully independent integration layer. This planned separation will allow HeLa Chain to deliver advanced functionalities, improve modularity, and enable smoother interoperability across external ecosystems.
>
> By evolving towards a distinct integration layer, HeLa Chain aims to enhance scalability, streamline system operations, and unlock broader use cases for developers and applications building on the network.