Off-Chain Systems
This page will give a brief overview of the responsibilities of each off-chain system. We suggest referring to the source code (GitHub) directly to learn more.
Overview
As the protocol requires moving funds between the Consensus Layer and Execution Layer, off-chain components are required for the protocol to function.
We have divided up the components by their function in order to make the system more efficient and maintainable overall. The main components are:
Oracle - Responsible for reporting Consensus Layer data to the contracts.
Initiator - Creates validators with Node Operators and deposits ETH.
Allocator - Manages the unstake queue and allocation of pending funds.
Guardian - Monitors the rest of the system.
Note that each backend system only has the capabilities to perform the actions that it is supposed to, enforced by "roles" in the smart contracts. The off-chain systems never have control of any funds, nor the ability to remove funds from the protocol.
Design Principles
Each of these off-chain systems is designed with specific principles in mind for safety and stability.
Minimal responsibility - Each service can only operate on the specific parts of the system it is supposed to. The services do not have the ability to remove money from the protocol at any point. See Roles for more information.
Stateless and recoverable - The services do not keep any state (e.g., write records to a database). All state is kept on-chain where needed. This ensures that the services cannot enter a "bad state" that needs recovery from an admin. This design adds a lot of complexity to the code, but allows for maximum recoverability in outage scenarios (e.g. data center problems). This is also crucial for future decentralization efforts.
Only chain data - Each service needs to use data from the Ethereum Network to perform its job. Much of this data is complex and requires a lot of computation. The services are explicitly designed to not rely on any third party APIs to reduce risk of supply-chain attacks or external outages affecting the system. For example, the services do not use any Node Provider's APIs for analyzing rewards, but they are computed by reading every slot/block from the chain.
Systems Descriptions
Oracle
Reports Ethereum Consensus Layer data to the contracts.
Rather than have the Oracle simply report the exchange rate, we have opted for a slightly more complex but more robust design where the Oracle reports raw data on the state of the system, such as:
The amount of ETH in validators
The current number of validators with ETH
The number of validators deposited and withdrawn
The rewards and principals received
From this data, the Oracle contracts can run many "sanity checks" that ensure that the reported data points match the contract's expectations. If the report falls outside of the bounds of the checks, then the protocol is paused.
The Oracle service is designed in such a way that each report must be agreed upon by multiple Oracles to be accepted. See Smart Contracts for more details.
Initiator
Creates new deposits on the Consensus Layer.
Monitors the amount of ETH allocated for staking in the contracts, then requests new validators from Node Operator partners. Once the validators are created, it tells the Staking contract to fund the validators through the Beacon deposit contract.
Validators details sent by the Initiator service are verified on-chain by the Staking contract, so the service cannot create deposits for incorrect validators.
Has built in protection for certain negative scenarios, such as deposit front-running or validator re-use. This reduces trust in any Node Operator and therefore reduces the risk of supply-chain attacks.
Allocator
Moves ETH around the protocol predefined smart contracts.
Optimizes for maximizing protocol yield, and fulfilling unstake requests:
Each Oracle record contains information on the amount of ETH received from the Consensus Layer (both rewards and principals). The Allocator "processes" each Oracle record by reading it and moving the ETH back to the staking contract (note that this is an on-chain operator).
Once the Oracle records are processed, the Allocator will check the unstake queue and compute the deficit (i.e., the sum total of the unfilled unstake requests). It will then allocate ETH from the "pending" pool to the queue to fill requests, and any surplus will be moved to the "staking" pool to be staked by the initiator.
If there is a larger deficit in the queue than there is money in the pool, the Allocator will initiate validator exits from the Consensus Layer, causing ETH to be returned to our withdrawal address for later processing.
Note that the Allocator is also optimized to minimize the number of validators that need to exit (which maximizes protocol yield) by predicting the incoming withdrawals and rewards.
Guardian
Consistently runs checks against on-chain data to ensure that the protocol is functioning smoothly. It is important to note that the protocol is built to be defensive already — the guardian simply checks that things are working as expected.
In the early stages of the protocol, the guardian provides extra safety, and will pause the protocol if there is suspicion that there could be an issue. For example, the guardian can help detect cases of possible Oracle bad behavior, or discrepancies in data from RPC providers.
Last updated