Introduction
ETHx architecture
ETHx has a multipool architecture. Based on the onboarding process, there can be 2 types of node operators onboarded on ETHx:
- Permissioned Operators: These node operators will need to go through the Stader DAO to be allowed to operate as part of the permissioned set of operators. These operators will need to meet some pre-agreed criteria for selection before they are allowed to operate, like having a track record of good performance, minimum prior experience running nodes, etc. Permissioned validators will not be required to deposit a 4 ETH bond as a collateral against poor performance on account of the prior selection procedure.
- Permissionless Operators: These node operators can begin running nodes for Stader permissionlessly by depositing 4 ETH as collateral. There is no need for any KYC, prior track record or filtering criteria to become a permissionless node operator with Stader
In the context of EL rewards (MEV and priority fees), the following fee recipient address values are possible:
-
Permissioned operators will need to set the fee_recipient address to a pre-designated permissioned socializing pool address. There is no other option available.
-
Permissionless operators have 2 options on how they choose to share EL rewards, with two separate address options:
-
Opt-In to the permissionless socializing pool: Where EL rewards are shared between all permissionless operators who have opted in and ETHx users. The corresponding fee_recipient address will therefore be the permissionless socializing pool address.
-
Do not opt-in to the socializing pool: Where EL rewards are shared with ETHx users only. The corresponding address will be a unique reward address at an operator level, that allows for distribution of rewards between the permissionless operator and ETHx users. The Operator’s EL reward vault address will be generated by VaultFactory.sol contract and is stored in permissionlessNodeRegistry.sol contract. The address will remain the same till the Operator is exited.
-
Proposal
Stader to engage oracle services provided by Rated, in order to monitor changes to the fee recipient address. Rated will provide two inputs to Stader:
-
On-chain list of validators who violate the fee_recipient policy
-
Rated will need to maintain a history of all violations of the fee_recipient policy in an array format
-
This data will be used to effect penalties to validators that hide MEV from the protocol, to be deducted from the 4 ETH bond that these validators have posted.
-
Temporary list of ETHx validators that are currently either (i) in a non-final state, or (ii) in a dispute process via the DVM; this is so that these validators are prevented from exiting the ETHx active set before a penalty is implemented, if their disputed violation is found to have been valid.
Integration Summary
This document aims to capture all the parameters that govern the integration between Stader Labs’ ETHx liquid staking protocol and Rated’s Oracle. The oracle will be tasked with monitoring for deviations from the expected fee recipient address of validators that belong to the ETHx active set, posting those results on-chain and updating a list that will maintain an ongoing history of violations.
The ROPU at a high level
The Rated Oracle powered by UMA (ROPU), is a fault tolerant mechanism that allows high fidelity data transfers from the Beacon Chain to the Ethereum Execution Layer. The Rated Oracle is leveraging the UMA Optimistic Oracle mechanism to improve the security and fault-tolerance profile of the data transfer. At a very high level, the Optimistic Oracle is a mechanism that allows for (i) a dispute window to be effected as the data comes on-chain, (ii) a bond that proxies the level of security and data integrity required of the data producer/proposer, and (iii) a dispute resolution mechanism when inquests to the integrity of the data are raised. You can learn more about it via docs.rated.network/oracle
Requirements
The requirement on the ETHx side is the ability to be able to read from a list that maintains the full record of violations of the fee recipient policy, by validator identifier (e.g. pubkey), in the following format:
|validator_id | epoch_number | new_fr|penalty_type
validator_id | epoch_number | new_fr|penalty_type
validator_id | epoch_number | new_fr|penalty_type
…
Where:
- validator_id:
- Hash of the public key:
sha256(abi.encodePacked(_pubkey, bytes16(0)))or - Penalty.sol: getPubkeyRoot(bytes calldata _pubkey) function.
- Hash of the public key:
- epoch_number: the epoch in which the violation actually took place
- new_fr:
- penalty_type: an identifier that points to what class of violation this was according to ETHx rules
This will be a permanent list. Once an entry is added to this list, it cannot be removed. The ROPU mechanism provides very high guarantees of tolerance against false reports, via the optimistic delay and the dispute resolution mechanism; these ensure that false reports are scrutinized and disputed before they leave the escrow state and are appended to the list.
The reports will be happening on predetermined 24h intervals.
The array must support the Stader facing function in the form:
function getViolatedEpochForValidator(identifier _validatorIdentifier) public returns (uint256 violatedEpoch) {}
Temp list
The scope also includes a temporary list, that will at all times maintain an up to date record of all the ETHx validators that are currently either (i) in a non-final state, or (ii) in a dispute process via the DVM; this is so that these validators are prevented from exiting the ETHx active set before a penalty is implemented, if their disputed violation is found to have been valid. The desired functionality is for ETHx to be able to query for whether a given validator_id is either in dispute or pending and to get a correct answer back.
The list must support the Stader facing function form as:
function isValidatorInDispute(identifier _validatorIdentifier) public returns (bool _isInUnfinishedDispute) {}
Description of the ROPU mechanism at a high level
For the purpose of the integration, Rated is approaching the design of the mechanism as “ROPU+”; this means that the fundamental data transfer & fault tolerance mechanism of the ROPU remains unchanged from its initial design. However, in order to accommodate ETHx’s requirements, Rated will be adding an appendage to the mechanism, in the form of the two lists outlined above.
Stader will be able to collect data via two different functions. The first one, returning a boolean value for a given validator stating if yes or no it is impacted by non-final or disputed reports. The second one, returning the list of violations found for a given validator
At a high level, the mechanism works as such:
- Rated maps out the ETHx validator active set registry in the RatedDB
- Rated develops filter for fee recipient violations, depending on the class of validator (permissioned vs permissionless pool etc)
- Rated runs checks for violations on the various criteria of the fee recipient policy on cadence of 24h intervals. The source of data for running these checks will be the finalized blocks on the beacon chain.
- The ROPU calls the Rated API for the report on a cadence of predetermined 24h intervals
- The ROPU fetches the data blob and stores it in escrow (data available but not gettable); the dispute window starts
- If the dispute window (set at ~24h) expires without a dispute mounted, the data is considered finalised and the data blob is released from escrow. The contents of the report are then added to the violations list (nothing is added if the report was “empty”)
- If a dispute is raised during the dispute window then the DVM process is used to determine whether or not it is correct. This process takes between 48 and 96 hours to complete, while it is in process, the data is not appended to the finalized set and validators impacted by disputed reports are marked as such. When the DVM reaches a conclusion, if the disputer was wrong and the initial data brought on chain was correct, it is added to the finalized set. If it is determined as incorrect, the data is discarded and ROPU is expected to bring a new report for the affected day.
What constitutes a fee recipient policy violation
Below are the scenarios for permissionless operators and the corresponding acceptable fee_recipient address.
Case 1: Permissionless operators that never join the Socializing Pool
If the permissionless operator never joined the Socializing Pool, they can have the following acceptable fee recipients:
- The Socializing Pool contract address
- The Operator’s EL reward vault address
If the validator proposes a block with a fee recipient other than the above addresses, the validator will be issued a penalty.
Case 2: Permissionless operators that have opted-in to the Socializing Pool
If the permissionless operator is opted into the Socializing Pool at the time of the block proposal, they can have the following acceptable fee recipient:
- The Socializing Pool contract address
If the validator proposes a block with any fee recipient other than the Socializing Pool address, the validator will be issued a penalty.
Case 3: Permissionless operators that recently opted out of the Socializing Pool
If a permissionless operator was previously opted into the Socializing Pool and opts out, their fee recipient must remain as the Socializing Pool address until the Epoch after they opted out has been finalized. Once the opted out epoch has been finalized, the acceptable fee recipient can be:
- The Socializing Pool contract address
- The Operator’s EL reward vault address
Operator Type Condition Acceptable Address Penalty Type
Permissionless Never opted in to Socializing Pool The Permissionless Socializing pool contract address Operator’s EL reward vault address 1
Permissionless Has opted in to Socializing Pool at the time of block proposal The Permissionless Socializing pool contract address 2
Permissionless Opt-out epoch is yet to be finalized.* The Permissionless Socializing pool contract address 3
Permissionless Opt-out epoch is finalized.* The Permissionless Socializing pool contract address Operator’s EL reward vault address 4
Permissioned In all cases The Permissioned Socializing Pool contract address 5
*Meaning of “finalized epoch”:
- If > 2/3rds of validators vote correctly on the chain head during an epoch, it is termed as the last epoch justified
- If two epochs in a row are justified, the current_epoch - 2 is considered finalized
Below are the details from where the above conditions can be obtained from:
- Getting ETHx validators:
In both pool node registries - IPermissionlessNodeRegistry.sol, IPermissionedNodeRegistry.sol
function getAllActiveValidators(uint256_pageNumber, uint256_pageSize) external view returns(Validator memory)
- Getting optIn/out state: (only valid for permissionless)
IPermissionlessNodeRegistry.sol function operatorStructById(uint256 _operatorId) external view return (Operator)
It includes the bool optedForSocializingPool variable;
- Getting the optIn/out state block:
IPermissionlessNodeRegistry.sol function socializingPoolStateChangeBlock(uint256 _operatorId) external view returns (uint256)
- Getting the socializing pool address:
IPoolUtils.sol function getSocializingPoolAddress(uint8 _poolId) public view returns (address)
- Getting the operator EL reward vault address: (only valid for permissionless)
IPermissionlessNodeRegistry.sol function nodeELRewardVaultByOperatorId(uint256 _operatorId) external view returns (address);
The dispute resolution mechanism (UMA DVM)
The ROPU leverages the DVM module from UMA to effect disputes and push them towards resolution. Here is an description of the mechanism of the DVM: DVM overview
FAQ
1. How do disputes get raised?
Dispute can be raised directly on the UMA optimistic oracle on chain, in a permissionless fashion. Alternatively, the UMA Dapp (https://oracle.umaproject.org/) tracks all proposals that are being made on the optimistic oracle, and their progress (proposed, disputed, settled). Users can go through this front-end to raise disputes.
2. Who has the ability to raise disputes?
Any entity (Permission-less) can raise a dispute on the Smart-Contract during the duration of the dispute window. The disputer has to commit a bond of the same size as the original proposer did. Whoever wins the claim (proposer or disputer), gets the other’s party bond, minus fees from UMA’s Data Verification Module.
3. What is the mechanism through which disputes get resolved?
In case there is a dispute, UMA token holders vote to determine if the data was correct or not. This process can take up to 48 hours. After the vote, if the proposer is given reason, the data is finalized, if not, the data is discarded. Whoever is right gets the other’s bond. See DVM overview for more details on the mechanism.
4. What happens if invalid data gets posted on-chain?
When the data first lands, it is in “escrow” state (i.e. not usable). From that point onwards any entity can permissionlessly dispute the data that Rated posted during the whole challenge window. A vote is casted to determine if the proposer was correct or if the data was indeed compromised.
5. How does Rated ensure the integrity of the data posted on-chain?
Rated adopts both pre-flight and post-flight tests that ensure the integrity of the data. In the damaging scenario where erroneous data makes it on-chain, any third party will dispute it in order to win Rated’s bond. The mechanism is designed so that no bad data makes it on-chain
6. What is the right 24h window to select in terms of reporting?
- We propose UTC noon on day t to UTC noon day t+1.
- In practice this means reporting every 225 epochs, a bit after noon UTC every day.
7. What happens if the Rated API or the ROPU are not available at the predetermined time?
Given all the alerting and monitoring infrastructure that we have in place, the probability that this happens without us noticing prior to the predetermined time is very low. If it so happens, the Rated team gets alerted post-hoc and goes into P0 troubleshooting mode. The report gets pushed on-chain as soon as the ROPU is back online.
Manual Process to identify errors
Stader or the community will also run checks on the on-chain data as provided by Rated to identify and raise cases of “errors” in the data. When the report is shared, Stader will run an off-chain job to check the accuracy of the data. Stader will work with Rated to agree on the existence of any error in the data as reported on-chain by Rated.
Subscription fee & economics
In this section we discuss the proposed economic parameters that govern the integration.
Monthly subscription
Given that the ROPU is yet to be tested in a live production environment, we have agreed on a “beta pricing” monthly fee 3,025 USD inclusive of gas. This has been benchmarked on an expectation of the report cycle costing approx. 400k gas units and 56.5gwei per gas.
The fees should be payable to the relevant Rated address/bank account, on the 10th day of every month, benchmarked on the date that the mechanism goes live on Mainnet. The subscription payments will take place in arrears (at the beginning of each month), with the first payment to become due on Mainnet launch date.
Past the n+7th day, if the subscription fee is not fulfilled, Rated reserves the right to stop producing reports. The subscription will run for at least 9 months, with a discussion on revision of economics to be had at the 9 month mark, post Mainnet launch.
Please note: As mentioned above, the price point quoted here is in the “beta pricing” category, and should not be indexed as a reference point.
Bond level
Rated will be setting the available bond to be applied on each data proposal on the ROPU, at UMAbasefee + RatedBond. The UMAbasefee is the minimum requirement bond to incentivize the DVM to be engaged in a dispute resolution process. This is currently set at 500 USDC, but is subject to change. The RatedBond will be initially set at 100 USDC.
Rated reserves the right to revise the RatedBond value upwards.
Right to terminate
Stader will have the right to terminate the engagement at any time if the average error rate is greater than 1% for a rolling 30-day window. Error rate here is calculated as the number of instances where a false positive or false negative of fee recipient was detected divided by number of instances of ETHx block proposer slots in the last 30 days
ROPU smart contract audit
The ROPU smart contract has been audited by Sigma Prime, with respect to the mechanism of posting off-chain data on-chain from the ROPU and until the point of updating the array that the ETHx suite of contracts reads from.
The cost of the audit has been split 50-50 between Rated Labs and Stader Labs.
Timelines
The targeted go-live on uncapped mainnet launch is benchmarked at some point in the first half of June.
