Sign in Subscribe

Ares and Eidos, the first components of the Giga Upgrade, will go live in Sei 6.6

Ares and Eidos, the first components of the Giga Upgrade, will go live in Sei 6.6

TL;DR: the proposal for Sei 6.6 is live, and it will be the release where Sei Giga starts touching mainnet. 6.6 will introduce the first pieces of two of the three major Giga upgrades: Eidos, a new storage layer that will begin moving the chain’s history into its own database, and Ares, a rebuilt execution engine that will become the default path for running transactions.

What the two upgrades actually are

A blockchain has three key components. It agrees on the order of transactions (consensus), it runs them (execution), and it keeps a permanent record of everything it has ever done (storage). Sei 6.6 is where two of those three jobs will start becoming their Giga versions.

Eidos will upgrade Sei’s storage layer, and Ares will upgrade Sei’s execution client to the Giga executor. Both need to keep pace with the 200,000 TPS that Sei Giga is targeting.

These upgrades will begin in 6.6 and continue in future releases. Consensus, the third major part of the Giga Upgrade, will only go live later.

How Eidos changes storage

Eidos will begin moving the chain’s history out of a shared database and into one built for the job. In 6.6, the historical state migration will start.

Until now, Sei’s EVM history and Cosmos state have lived in the same database. That means history reads compete with live activity, and modules that have nothing to do with the EVM still pay write costs for EVM data.

Eidos will separate them. EVM history will move into its own dedicated database, so reading old history stops competing with the transactions happening right now, and non-EVM parts of the chain stop carrying the write cost of EVM data they never touch.

How Ares changes execution

Ares is a rebuilt execution client, and in 6.6 it will become the default execution path on mainnet. Every upgraded node will run it unless it opts out.

Ares is a different design from what came before. Where the old v2 engine used a Go-native path, Ares is built on an EVMC backend with evmone as the interpreter, and it runs its own state and cache stack.

The old engine will keep two roles.

First, it will act as a per-transaction fallback. When Ares hits something it can’t handle cleanly, that single transaction will rerun on the v2 engine instead of the new engine guessing at the result. Nothing gets dropped or approximated. The fallback catches the edge case and the block moves on.

Second, a full v2 node will run on every network as a live reference. It will process the same blocks as the new engine and compare results block by block. If the two ever disagree, it will page the on-call team. That means a mismatch between the old and new execution paths becomes an alert a human sees, not a silent divergence that surfaces later as a bug.

What comes next

6.6 will be the release where Giga stops being a roadmap and starts being something running on mainnet. Eidos will have begun moving history into storage built for scale, and Ares will be the default execution path. Both are only the first step, and both continue across the releases that follow.

6.6 is a massive release, with many fixes that are unrelated to Sei Giga. The full list is in the 6.6 proposal.

Sources