LogoLogo
GitHub
  • Quickstart
    • What is eOracle?
    • eOracle Vision
    • Use eOracle
  • Build on eOracle
    • Introduction to eOracle Stack
    • What is an OVS
    • eOracle Features
    • eOracle Data Processing Flow
    • Builders Workflow
      • Set-up
      • Off-chain Computation
      • On-chain Components
      • Target Chains Publishing
    • Smart Contracts Overview
      • eOracle Chain contracts
      • Target Contracts
    • Aggregation Library
      • Median
      • Clustering
      • TWAP
      • Robust Aggregation 101
    • eOracle Cryptographic Broadcaster
    • Incentives Management
      • 🥢On-chain-Subjective Slashing Framework
    • Active Specialized Blockchain Oracles
      • EtherOracle - Peg Securing Oracle by Etherfi
      • Pulse - Risk Oracle By Bitpulse
      • ECHO - Social Media Oracle
      • Borsa - Intent Optimisation
  • ePRICE
    • Introduction to ePRICE
    • Integration Guide
    • Risk Management and Market Integrity
    • Feed Addresses
      • Arbitrum
      • Arbitrum Sepolia
      • Base
      • Base Sepolia Testnet
      • Berachain
      • Blast
      • BNB Smart Chain
      • BOB
      • B Squared
      • B Squared Testnet
      • Hemi
      • Ink Sepolia
      • Ink Mainnet
      • Linea
      • Linea Sepolia
      • Manta
      • Manta Sepolia Tesnet
      • Mode
      • Mode Testnet
      • Monad Testnet
      • Morph
      • Morph Holesky
      • Polygon zkEVM
      • Polygon zkEVM Cardona Testnet
      • Plume
      • Plume Testnet
      • Scroll
      • Soneium
      • Sonic
      • Soneium Testnet
      • TAC Turin Testnet
      • Taiko Mainnet
      • Unichain
      • Unichain Sepolia
      • Zircuit
      • Zircuit Testnet
      • zkLink Nova Mainnet
    • API Reference
      • đź§©Examples
      • đź§©Off-chain Examples
    • Advanced
      • 🤖Automating eOracle consumption
      • đź’±Getting a different currency pair
  • EO Token
    • The EO Token
    • Ecosystem Participants
    • EO Token Utility
    • EO Token Flywheel
    • Security and Enforcement
    • A New Chapter in Oracle Design
  • Understand eOracle
    • eOracle Trust Model
    • Architecture Overview
    • Data Processing
    • Security
      • Cryptoeconomic Security
      • Aegis - Validator Set Configuration
  • Operators
    • Installation
    • Registration
    • Running the Client
    • Monitoring
  • 🔍Concepts
    • EigenLayer
    • Data Validators
    • Chain Validators
    • eBFT
    • OVS
    • eOracle Chain
Powered by GitBook
On this page
Export as PDF
  1. 🔍Concepts

eBFT

PreviousChain ValidatorsNextOVS

Last updated 10 months ago

eOracle Byzantine Fault Tolerance (eBFT)

eBFT is a secure and novel network employed by eOracle. It consists of a consensus engine (IBFT) and External Validator Set Configuration Protocol (Aegis). eBFT utilizes the to seal blocks, provide specific network capabilities, and govern the network. eOracle EigenLayer-integrated smart contracts on Ethereum work in tandem with the consensus engine, fully implementing the Aegis Protocol.

eBFT's External Validator Set Configuration Protocol (Aegis) is implemented through a set of core smart contracts adhering to the Aegis protocol's specification. These contracts integrate restaking functionality, configure the validator set, and record commitments of the eOracle state.

  • Immediate block finality: At every chain height, only one block is proposed, and so forking and uncle blocks are avoided. This also mitigates transactions being reverted once on-chain later.

  • Reduced time between blocks: The construction, validation, and execution time of block forming is efficiently managed, increasing the chain's blockrate.

  • High data integrity and fault tolerance: IBFT 2.0's Aegis configured Validator Set, part of the Ethereum Validator set, proposes each block. ~66% of these validators must verify the block before addition, making malicious block approval very infeasible. The proposer of the block rotates over time (based on ), ensuring a faulty node cannot exert long-term influence over the chain.

State transitions

IBFT 2.0 defines a sequence of state transitions that determine chain-wide consensus on the state. A validator proposes a block to be added, which specifies operations updating the blockchain's state.

Validators of the Ethereum Validator Set accept valid proposed blocks. Each validator's voting allocated stake determines their voting weight, and a supermajority of validators must verify a block for it to be accepted.

When a validator proposes a new block, other validators verify it and vote on whether to accept it, and this can be repeated if needed. During each round of repetition, a threshold number of validators must verify and sign the block for it to be added to the blockchain. If the threshold isn't reached, the next round will begin. Another validator will then propose a block and repeat the process.

If the proposed block is verified and signed by the threshold number of validators, it's accepted and reflected in the new state of the blockchain.

The proposer is chosen to construct a block at the block rate. The proposer selection mechanism is based on , through a deterministic selection algorithm. Validators with more voting power get selected more frequently.

Consensus Benefits

A validator's voting power is proportional to the amount staked. This means that validators with more stake will have more voting power and, therefore, more influence over the decision-making process on the network. This also provides an economic incentive for validators to behave honestly and act in the network's best interest.

EBFT is using the , leveraging its external staking design and cross-chain features. The Aegis protocol completes and secures the network through integration with Ethereum native validators through EigenLayer.

IBFT consensus engine
Tendermint
-based
Tendermint
Tendermint
PolyBFT stack