HeLa Architecture
Hela is a modular blockchain protocol composed of four primary layers:
Consensus Layer – Secures the network and finalizes transactions.
Execution Layer – Processes user transactions and applications.
Integration Layer – Enables cross-runtime and cross-chain interoperability.
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
User submits a transaction to a runtime.
Compute nodes process the transaction and update local state.
Results + new state are bundled into a block.
Block is submitted to the Consensus Layer.
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.
Last updated