Architecture
Last updated
Was this helpful?
Last updated
Was this helpful?
The Entangle Interoperable Blockchain consists of 3 Layers:
Application Layer
Modules Layer
Tendermint Consensus Layer
The Application Layer is the user-facing component of EIB, bridging consumer devices and the blockchain. It validates, decodes, and routes messages to enable smart contracts, dApps, and other blockchain-based applications, ensuring seamless user interaction and efficient execution.
Sub-Layers
Execution Layer: Validates and executes smart contracts, chaincode, and foundational rules, ensuring accurate transaction processing.
Application Sub-Layer: Provides end-user services like wallets, lending, and staking. Interfaces such as Web3 applications or APIs facilitate user interactions with blockchain-based services.
This comprises a variety of modules that provide specialized functions to the blockchain. These modules are responsible for handling core operations such as asset management, governance, and network security.
See the list of modules and their description in the table below.
Delegated Proof of Stake (DPoS)
Facilitates staking for Validators and Delegators.
Banking
Sending and receiving assets on Entangle Blockchain.
GOV Module
Changes to blockchain parameters, addition of new Validators, Distributors or Agents.
Auth Module
Allows authorized entities to launch smart contracts on Entangle Blockchain.
IBC Module
Facilitates communication with Cosmos-based Chains.
Distributor Module
A database of authorized Distributors added through the GOV Module.
EVM Module
Hosts smart contracts deployed on Entangle Blockchain such as the Controller. Provides composability between Entangle Blockchain and EVM Infrastructure such as Metamask, Hardhat, and Truffle.
Vesting Module
Facilitates vesting of $NGL Tokens.
EIB ensures reliability and security with a Byzantine Fault Tolerant (BFT) consensus mechanism, allowing the network to function even if up to one-third of nodes are faulty or compromised. This ensures consistent validation of cross-chain transactions and prevents disruptions from malicious actors.
Participants:
Validators: Propose and vote on transaction blocks, using round-robin scheduling based on their stake proportion.
Delegators: Delegate their tokens to validators, who in turn earn a commission from the delegated stake.
The consensus process in Tendermint involves several key steps to ensure secure and consistent block creation:
Propose: A designated validator compiles transactions into a block and broadcasts it to peers. This ensures that all validators have a common starting point for considering new transactions.
Pre-Vote: Each validator decides whether to support the proposed block. If a validator is already locked on a previous block, or if it receives a valid new proposal, it broadcasts its prevote for that block. If no valid proposal is received, it signs a nil prevote. This step is crucial to gauge initial support for the block, ensuring that validators are aligned before moving forward.
Pre-Commit: Validators broadcast a precommit if they receive more than two-thirds of prevotes for a proposed block, effectively locking onto that block. Locking onto a block prevents validators from equivocating, which is essential for ensuring consensus consistency and security.
Commit: During the commit step, validators wait to receive at least two-thirds of commits for a block. Once this condition is satisfied, the validator sets the CommitTime and moves to the next phase. This step finalizes the block and adds it to the blockchain, ensuring that all validators have reached agreement.
NewHeight: After a block has been committed, the NewHeight step allows the network to gather additional commitments for the committed block from validators that may have been delayed. This step helps to maintain overall network integrity by ensuring that slower validators are included, promoting fairness and cohesion across the network.
Locks play a crucial role in maintaining consistency during voting stages by preventing validators from changing their support within the same round. Once a validator locks onto a block, they remain committed to it until consensus is achieved. This mechanism ensures that validators do not equivocate, thereby maintaining the reliability of the consensus process.
New rounds may be initiated in cases such as proposal failures, invalid blocks, untimely propagation, or insufficient pre-vote or pre-commit consensus. These new rounds are essential to the robustness of the Tendermint consensus process, allowing the network to overcome temporary challenges and maintain consistent block production. This flexibility is key to maintaining the integrity of the network even when disruptions occur.
