Oracles
Last updated
Last updated
A blockchain can access information that any entity has recorded on the blockchain. However, much of the data in the real world exists outside the blockchain. For instance, the current temperature in London, UK is neither inherently available nor computable onchain. For such external data to be used on the blockchain, a third-party entity, called an “Oracle,’’ sources the information and feeds it into the blockchain. The information the Oracle provides may not be verifiable onchain but is considered reliable enough to be used by blockchain applications.
Ethereum started as a proof-of-work blockchain and, in recent years, transitioned into a proof-of-stake blockchain. At its core, the two blockchains, Execution Layer and Consensus Layer, form the Ethereum network. The execution layer holds the contract data, and the consensus layer holds staking information (regarding validators). ETHx smart contracts make decisions based on the data from the consensus layer. Hence, Oracles are needed to bridge this gap by fetching validator data from the Consensus Layer and supplying it to the Execution Layer.
Although contentious, Oracles are widely used across many DeFi protocols, particularly in lending markets, liquid staking protocols, and CDP agreements.
Running an Oracle client is computationally intensive, technically challenging, and expensive. Only registered Oracle operators can provide data to ETHx smart contracts. To be an eligible Oracle operator, one must follow the process outlined below.
Complete KYC/KYB of the individual or entity
Demonstrate proficiency with prior history
Provide security collateral determined by Stader DAO
Pass a governance vote for approval of Stader DAO
Each Oracle client operator is encouraged to maintain dedicated infrastructure, including an archive node, to protect against common, widespread infrastructure failures (cloud or rpc providers, etc). Oracle operators receive compensation for gas fees and operational costs from Stader treasury.
Currently, ETHx has a 3-member Oracle Node Operators (ONOs) Committee comprising:
1 permissioned node operators
1 prominent ETH community member
1 Stader team member
The committee and its members believe in the shared values of decentralization, neutrality, censorship resistance, openness, data ownership, and near-unbreakable security, which form the bedrock of the Ethereum ecosystem and Stader.
The ONO committee members are:
Stakely: A trusted player in the DeFi world, Stakely is present on multiple networks and excels in providing Oracle solutions for both Ethereum Virtual Machine (EVM) chains and non-EVM chains. By integrating powerful on-chain tools, Stakely serves as an accessible gateway for newcomers, enabling them to experience the power of DeFi firsthand.
Mark Zeller: Mark is a veteran member of the ETH node operator community with over 8 years of experience running nodes. As a distinguished representative of the Aave DAO and the Founder of the Aave Chain Initiative, Mark has contributed extensively to the effective governance of Aave. A vocal advocate for diversification and healthy competition in the LST space, Mark is an extremely valued addition to the ETHx genesis ONO.
Stader: Stader is a multi-chain liquid staking platform with proven expertise across 6 EVM and non-EVM blockchains.
ETHx utilizes various consensus mechanisms across Oracle data feeds to determine agreed-upon values from multiple independent Oracle node operators. Some of the consensus methods employed include: 1. Majority consensus In this consensus mechanism, more than half of the Oracle providers are expected to report the same value for the same reporting block.
2. Median consensus For some data feeds, where Oracle operators cannot feasibly report identical values, ETHx uses a two-thirds threshold. Once two-thirds of operators have reported for a block, the data is stored after sorting & median of all reported values becomes the consensus.
3. Deviation Threshold Consensus\ Multiple Oracle operators reporting data separately on Ethereum require gas fees for each. Decentralized oracle networks like Chainlink’s compute data off-chain, updating the on-chain contract only when the new value deviates from the previous report by a minimum threshold.\ The subsequent upgrades for ETHx contracts will incorporate these efficient consensus mechanisms.
Exchange rate
The exchange rate of ETHx to ETH determines the conversion when users stake ETH to mint ETHx or burn ETHx to withdraw ETH. Computing the exchange rate requires the following three conditions:
a. Amount of ETHx tokens in circulation b. Amount of ETH tokens that are staked or in the process of being staked. c. Ensuring that the above two conditions are reported for the same block number. The exchange rate of ETHx to ETH is defined as the total ETHx supply divided by the total ETH that is staked + in the process of being staked at any point. Stader Oracle contract sets the frequency of updating the exchange rate data. The Oracle client operators report the exchange rate through the majority consensus mechanism for appropriate blocks. Between Oracle consensus updates, the exchange rate is constant and assumed to be non-changing. An exchange rate update that meets the consensus threshold is accepted if it’s within a specific range of the old exchange rate. Inspection mode is enabled when the new exchange rate deviates significantly from the old one. In inspection mode, the Stader manager is expected to verify the validity of the new exchange rate. Anyone can also turn off the inspection mode after the verification period for the inspection mode ends. The latter ensures that anyone can continue exchange rate updates except during short bursts for verification purposes. Stader has partnered with Chainlink to provide Proof of Reserve data feeds for both ETHx and ETH supply to act as an alternative to the above. In the subsequent protocol upgrades, we expect to integrate and transition to Chainlink’s Decentralized Oracle Network (DON).
Withdrawn validators
Once a validator’s exit message is broadcasted, the validator joins the exit queue, slowly making their way across the withdraw queue. Eventually, the validator’s entire staked balance accumulates in the validator withdrawal vault contract deployed during their onboarding.
The ETH in the withdrawal vault is a mixture of:
a. The validator’s original ETH collateral b. User ETH lent to the validator by Stader c. Consensus rewards and commissions earned by the validator d. Any applicable slashing penalties that are due for deduction
On a validator exit, it becomes essential to promptly distribute the above ETH to various stakeholders. Furthermore, this helps facilitate quicker withdrawal requests for Stakers and Node Operators.
Stader Oracle client operators read all validators registered with ETHx smart contracts and list all validators exited from the beacon chain. This list is submitted and arrived at a consensus, after which the distribution, as mentioned earlier, happens. The exited validators are also marked as exited on the smart contracts.
Missed attestations
Node Operators are offered flexibility on Ethereum staking, as missing a few attestations leads to a minor penalty. When Node Operators are offline for an extended time, they do not generate rewards on the consensus or execution layer. ETHx contracts prioritize Staker rewards over Node Operator security collateral to avoid these situations. In extenuating circumstances, Oracle client operators can vote to penalize validators proportional to their historical cumulative count of missed attestations.
A governance vote will decide the final parameters for the historical count of missed attestations at which a specified penalty needs to be applied. Stader will open a discussion around recommended values to gather community feedback before a vote.
Validator statistics
Exit time for a validator on the Beacon chain is non-deterministic as it depends on the network state, the number of validators in the exit queue, etc.
The computation entity must be aware of the following to compute the number of validators that need to be exited to meet the demand of withdrawal requests:
a. ETH balances of slashed validators b. ETH balance of validators in the exit queue c. ETH balance of validators withdrawn since the last Oracle report
Oracle client operators are expected to report this data infrequently for the exit validator list to be computed to initiate validator exits on time. The Stader DAO will decide the validator selection mechanism for exits and its enforcement through a governance vote.
Operator reward merkle root
The permissionless pool allows operators to participate in the socializing reward contract for execution layer rewards. On the other hand, for the permissioned pool, all operators are expected to participate in the socializing reward contract.
In every reward cycle, the ETH reward in both these socializing contracts is distributed to operators participating in the pools based on the following factors:
a. The number of validators run by the node operator\ b. The number of attestations performed by each validator in the reward cycle.
SD token rewards are also distributed to the same set of node operators based on the following factors:
c. The number of validators run by the node operator d. The number of attestations performed by each validator in the reward cycle. e. Amount of SD token bonded on average per validator per day.
Oracle client providers must provide the computed Merkle root hash to contracts to initiate ETH and SD reward withdrawal by node operators for past reward cycles. Node Operators are neither rewarded SD for collateralization ratio below the minimum threshold (0.4 ETH worth of SD per active validator) nor are extra rewarded for collateralization above the maximum threshold (8 ETH worth of SD tokens per validator).
SD price
Every permissionless node operator provides SD tokens as a secondary security collateral to run an ETH validator. Hence, it is crucial to get an accurate value of SD price to ETH at all times. Oracle client operators must update the ETHx contracts with SD price periodically. A time-weighted average price (TWAP) of 24 hours is mandated to avoid SD price manipulation concerns.
Given the diversity of data sources, onchain and offchain, a consensus by the majority is an impractical choice. For this Oracle feed, the SD price is considered the median value after two-thirds of Oracle client operators have reported the SD price. As with other Oracles, the SD price remains constant between consecutive price updates.
MEV misappropriation
Node Operators can choose the execution layer reward fee recipient on every block. If a Node Operator were to guide the execution layer rewards (MEV and Priority fees) away from the ETHx contracts, Stakers would lose the yield that is appropriately owed to them. MEV misappropriation allows Node Operators to unfairly pocket all the rewards instead of just the commissions.
A node operator could commit this infraction in one or more ways:
a. Changing execution layer reward fee-recipient shortly before block proposal b. Choose a block order that profits a specific transaction to a third party with which the node operator may have an offchain association. This leads to a suboptimal extracted reward value for ETHx’s Stakers. c. Not operating an MEV relay.
Recognizing MEV misappropriation is a reactive process that limits actions that can be taken to remedy the situation. With ETHx, every permissionless node operator provides 4 ETH security collateral and 0.4 ETH (or more) worth of SD tokens. Effectively, 4.4 ETH is available for compensation as a counter to MEV misappropriation.
Stader is partnering with Rated Network to track Node Operators’ performance and inform of any instances of MEV misappropriation. For more details, read here.
