Operator FAQ
Does Omni provide official docker images?
- Yes, see omniops/halovisor and ethereum/client-go
- Note that the
omni operator init-nodes
CLI command generates all the required config files, genesis files, keys and a docker compose file required to runhalo
andgeth
using docker compose. It also callsgeth init
with the Omni execution genesis file.
What is the difference between the omniops/halovisor and omniops/halo docker containers?
- The
omniops/halovisor
container combines cosmovisor with all halo binaries required for network upgrades. - The
omniops/halo
container only contains a specific halo binary. - It is strongly advised to run the latest
omniops/halovisor
version since this ensures your validator will automatically perform required network upgrades if and when they occur. The omni team will also communicate details of any planned network upgrades. - Cosmos network upgrades require switching binary versions at the specific chain heights that network upgrades occur. The
halovisor
container handles this automatically. - Both
omniops/halovisor:latest
andomniops/halo:latest
point to the latest stable omni release as per the Omni monorepo Github release page.
Can raw binaries be used instead of docker containers?
- Yes, the halo and geth binaries are available on their respective Github release pages.
- Note that setting up cosmovisor is strongly advised to support smooth network upgrades. See our halovisor build scripts for inspiration.
- Note that before starting geth, it must first be initialised with the Omni Omega
execution-genesis.json
file viageth init
.
What is the XChain RPC request rate per validator?
- Each validator needs to attest to each source chain block twice, once for
latest
confirmation level, and once forfinalized
confirmation level. - The validator does maximum 4 queries per block; once for the
block header
, once forxmsg
event logs, once forxreceipt
event logs plus some additional polling. - So RPC request rate primarily depends on the block period per chain:
arb_sepolia
: 4 blocks/s * 4 req/vote * 2 votes/block ~= 32 req/sop_sepolia
: 0.5 blocks/s * … ~= 4 req/sbase_sepolia
: 0.5 blocks/s * … ~= 4 req/sholesky
: 0.08 blocks/s ~= 1 req/s (due to additional polling of slow chains)
- Note that the above are average rates. Bursts of much higher rates must be supported since chains finalize blocks in large batches instead of continuously, e.g. +-2000 blocks every 8mins for
arb_sepolia
. The whole batch of finalized blocks need to be voted on as fast as possible, this results in very high query bursts (up to 200 req/s). - Rate limiting of XChain RPC requests should therefore not be applied for best xchain validator performance.
How to “unjail” a validator?
-
The Cosmos staking module can “jail” a validator for inactivity which removes it from the active validator set. See more details here.
-
Note that Omni validators have two types of duties to perform:
- CometBFT consensus blocks (can be jailed for inactivity)
- XChain votes (cannot be jailed for inactivity yet).
-
To “unjail” a validator, submit the following
unjail
transaction from the operator address to the Omni execution chain by using theomni
CLI similar tocreate-validator
above :❯ omni operator unjail \
--network=omega \
--private-key-file=./operator-private-key-0x6e9C5F0Ad4739C746f4398faAf773A3503476b90
What is the difference between L and F on the dashboard?
- Each validator votes for each support chain twice: once for latest blocks (L) and once for finalized blocks (F). This allows users of our xchain protocol to decide if they want to wait for chain finalization (strong security and exactly once guarantees) or if they want fast xchain messages with latest (strong security but no delivery guarantees due to risk of reorg).
What are the validation duties of a validator?
- Omni validators have two duty types to perform:
- Normal cosmos/cometBFT consensus : UptimeC on dashboard
- XChain votes and attestations: UptimeX on dashboard
When and how is a "rollback" performed?
CosmosSDK chains, including halo
supports the rollback
command that rolls back the CosmosSDK and CometBFT state by one height.
A state rollback is performed to recover from an incorrect application state transition, when CometBFT has persisted an incorrect app hash and is thus unable to make progress. Rollback overwrites a state at height n
with the state at height n - 1
. Halo
application state also rolls back to height n - 1
. No blocks are removed, so upon restarting the transactions in block n
will be re-executed against the application.
Assuming that the halo
is deploying with docker-compose and runs inside the omniops/halovisor
container:
docker compose down
docker compose run halo run rollback
docker compose up -d
Note pure halo
command is just rollback
. But when running via halovisor
one needs to specify run rollback
, with the run
being the Cosmovisor command to execute halo binary commands.
How do validators vote?
- Validators vote in the Omni consensus chain, using a new feature of CosmosSDK/CometBFT called “vote extensions”
When will ETH delegation be available?
$ETH delegation counting for validator power is not available initially on Mainnet and will only be enabled after a staking upgrade. The full Eigenlayer integration is pending $ETH slashing being available as a feature in Eigenlayer (if $ETH isn't slashable, it can't count for economic security yet).
Operators can still register with Omni's Eigenlayer AVS contract following Eigenlayer's instructions here to register operator key with their contracts and then run the following command to register within the Omni AVS contract:
omni operator register --config-file ~/path/to/operator.yaml
Which tokens can be staked?
Validators must stake native $OMNI. Validators can also opt into receiving $ETH delegations once the Eigenlayer integration is complete.
What is the validator whitelist?
Omni currently has a validator whitelist. The whitelist applies to both native $OMNI staking and $ETH staking via the Omni AVS. A future network upgrade will enable permissionless validator registration.
What are the planned staking upgrades?
There will be several network upgrades to enable various validator / staking features. Some of these features include:
- Withdrawals: similar to the Beacon Chain launch, validators will not initially be able to withdrawal their $OMNI stake.
- Delegations: validators can receive $OMNI delegations.
- X-chain rewards and penalties
- $ETH Restaking: validators can opt into receiving restaked $ETH delegations, pending Eigenlayer slashing.
- Permissionless validator registration: anyone can register, and collect delegations to be included in the active set.