# 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.helalabs.com/build-on-hela/hela-architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.