Architecture

The Entangle Interoperable Blockchain consists of 3 Layers:

• Application Layer

• Modules Layer

• Tendermint Consensus Layer

Application 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.

Modules Layer

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.

Tendermint Consensus Layer

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.

Participants in Tendermint

• 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.

Consensus Process

The consensus within Tendermint involves several steps: Propose, Pre-vote, Pre-commit, Commit, and NewHeight.

Propose

In this phase, a designated validator compiles transactions into a block proposal, subsequently broadcasting this to peers.

Pre-Vote

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.

Pre-Commit

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.

Commit

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.

NewHeight

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.

Locking Mechanisms in Voting

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.

Initiating New Rounds

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.

Slashing

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.