The Omni architecture is similar to Ethereum PoS in that it consists of two chains: an execution chain and a consensus chain.
The execution chain is implemented by running the latest version of geth . Note that Omni doesn’t fork geth, we use the stock standard version, just with a custom Omni execution genesis.
The consensus chain is implemented by running halo which is a CosmosSDK application chain. Halo connects to geth via the EngineAPI.
Running a Omni full node therefore consists of running both halo and geth.
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 run halo and geth using docker compose. It also calls geth init with the Omni execution genesis file.
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 and omniops/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 via geth 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 for finalized confirmation level.
The validator does maximum 4 queries per block; once for the block header, once for xmsg event logs, once for xreceipt event logs plus some additional polling.
So RPC request rate primarily depends on the block period per chain:
holesky : 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.