Architecture
Last updated
Last updated
The Entangle Interoperable Blockchain consists of 3 Layers:
Application Layer
Modules Layer
Tendermint Consensus Layer
The Application Layer decodes, validates, and redirects messages to designated Modules, enabling the development of smart contracts, dApps, and other software on the blockchain network. It serves as the user interface, allowing direct interaction between consumer devices and the blockchain.
This layer includes scripts, APIs, user interfaces, frameworks, smart contracts, and dApps. It is divided into execution and application layers:
The execution layer handles smart contracts, foundational rules, and chaincode, validating and executing transactions initiated at the application layer.
The application layer delivers blockchain-based applications to end-users, offering functionalities such as wallets, lending, and staking. At its core, the smart contract dictates state transitions, with user interactions mediated through Web3 applications or APIs.
See the list of modules and their description in the table below.
| Module name | Description |
|---|---|
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. |
Entangle Interoperable Blockchains employs a Byzantine Fault Tolerant (BFT) consensus mechanism, capable of withstanding up to one-third of faulty nodes within the network. The algorithm facilitates P2P Connections between Validators reaching consensus on new blocks.
Validators: Validators propose and vote on transaction blocks, allocated via round-robin scheduling based on their stake proportion.
Delegators: Delegators, who hold tokens but do not act as validators, delegate their stake to validators. Validators then charge a commission on the earnings from these delegated stakes.
The consensus within Tendermint involves several steps: Propose, Pre-vote, Pre-commit, Commit, and NewHeight.
In this phase, a designated validator compiles transactions into a block proposal, subsequently broadcasting this to peers.
Each validator makes a decision at the beginning of the Prevote step:
If locked on a previous block, it signs and broadcasts a prevote for that block.
If it received a valid proposal for the current round, it signs and broadcasts a prevote for the proposed block.
If no valid proposal was received, it signs a nil prevote.
All nodes gossip prevotes to their neighboring peers.
At the start of the Precommit step, each validator decides:
If it received more than 2/3 of prevotes for an acceptable block:
Signs and broadcasts a precommit for that block.
Locks onto that block, releasing any prior locks.
If it did not receive more than 2/3 of prevotes for any block, it does not sign or lock anything.
All nodes share precommits with neighboring peers.
For commitment, two parallel conditions must be satisfied before finalizing the round:
The node must receive and sign the block committed by the network, then broadcast a commit.
The node must wait to receive at least 2/3 of commits for the precommitted block.
Once both conditions are met, the node sets its CommitTime to the current time and transitions to the NewHeight step.
After a block has been committed by the network, the NewHeight step allows nodes to gather additional commitments for the previously committed block from the preceding height. Nodes remain in this step until a fixed duration of time has passed since the CommitTime of the last block. This process enables block proposals to include more than the minimum 2/3 of commits, thus allowing the commits of slower validators to be included in the subsequent blockchain.
Locks are pivotal during the voting stages to ensure consistency and prevent equivocation. This mechanism refers to the action taken by a validator to commit to a specific block during a particular round. When a validator is locked on a block, it means they have chosen to support that block and its position in the blockchain. A lock prevents a validator from quickly changing its support to another block in the same round.
New rounds are necessitated under circumstances such as proposal failures, invalid blocks, untimely propagation, or inadequate pre-vote/pre-commit consensus. Each scenario underscores the robustness of the Tendermint consensus in maintaining network integrity amidst challenges.
Validators can incur penalties for insufficient or malicious activity:
Double signing blocks
Validators will have a percentage of their tokens slashed.
Signing less than 50 of the last 100 blocks.
A percentage of staked tokens are slashed. Validators are temporarily put in "jail" for a set period of time.
