eoracle Blockchain & Aegis Protocol

eoracle's mission is to establish a decentralized oracle platform, that provides blockchain applications with the same programmability and security guarantees as native smart contracts.

The network architecture extends Ethereum's base layer security, offering a reliable real-world connection while upholding transparency, high throughput, low latency, security, and fast finality. This architecture marks the next evolution of oracle infrastructure, replacing traditional fragmented oracles with shared security through a secure extension of Ethereum's Proof of Stake.

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 IBFT consensus engine to seal blocks, provide specific network capabilities, and govern the network. eoracle Eigenlayer-integrated smart contracts on Ethereum work in tandem with the Tendermint-based 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 the 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 Tendermint), ensuring a faulty node cannot exert long-term influence over the chain.

Consensus Benefits

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 Tendermint, through a deterministic selection algorithm. Validators with more voting power get selected more frequently.

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 PolyBFT stack, 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.