Ontology News

Homepage

Ontology News

Homepage

Ontology MainNet v3.1.2: Four Ethereum Opcodes Arrive on the Ontology EVM

10 mins0

The next Ontology MainNet upgrade, to v3.1.2, is scheduled for block height 20,800,000. The release focuses on security optimisations and brings four widely adopted Ethereum Improvement Proposals to the Ontology EVM: PUSH0, BASEFEE, MCOPY, and transient storage. For builders, the practical result is smaller contracts, cheaper temporary state, and less friction when porting existing Ethereum code across. For node operators, it means one job: upgrade to v3.1.2 before block height 20,800,000 is reached.

Why opcode parity matters

The Ethereum opcode set is not static. It has expanded steadily through successive network upgrades: BASEFEE arrived with London in August 2021, PUSH0 with Shanghai in April 2023, and both MCOPY and transient storage with Cancun-Deneb in March 2024 (Ethereum upgrade history).

Compiler defaults moved with them. Solidity now targets a recent EVM version by default, which means a team compiling a contract today with no special flags produces bytecode that assumes these instructions exist. An EVM chain that has not adopted them forces developers into a workaround: pin an older target EVM version, accept larger and more expensive bytecode, and maintain a separate build configuration for that chain alone.

That is a small tax, but it is paid on every deployment, and it accumulates. v3.1.2 removes it for the four instructions below.

What the Ontology MainNet upgrade includes

PUSH0 (EIP-3855)

PUSH0 places the value zero directly onto the stack. Before it existed, contracts pushed zero using PUSH1 0x00, which occupies two bytes of bytecode and costs 3 gas at runtime. PUSH0 occupies one byte and costs 2 gas.

The saving per instruction is small; the aggregate is not. The EIP notes that roughly 11.5 percent of all PUSH instructions executed on Ethereum MainNet push the value zero. Every one of those is a byte of contract size and a unit of gas, on a chain where deployment is charged per byte of code.

BASEFEE (EIP-3198)

BASEFEE lets a contract read the current block’s base fee directly on-chain, at a cost of 2 gas. Previously a contract that needed to reason about network fee conditions had to be handed that value by an off-chain source, which introduces a trust assumption and a point of failure.

Reading it from the chain itself removes both. It is a prerequisite for gas-aware contract logic: dynamic bounties that scale with network conditions, fee-sensitive automation, and layer-2 constructions that need to verify fee data without relying on an oracle.

MCOPY (EIP-5656)

MCOPY copies a region of memory in a single instruction, including where the source and destination regions overlap. Before it, copying memory meant a loop of loads and stores.

The efficiency gain is substantial. Copying 256 bytes cost at least 96 gas using the conventional approach; MCOPY does it for 27 gas. That matters most for the operations that move data around constantly: ABI encoding and decoding, string and byte-array handling, and cryptographic routines.

Transient storage, TSTORE and TLOAD (EIP-1153)

Transient storage introduces a state area that behaves like storage but is discarded when the transaction ends. TSTORE writes to it and TLOAD reads from it, each at 100 gas.

The canonical use case is reentrancy protection. A reentrancy guard needs a flag that survives across calls within one transaction and is meaningless afterwards, which is exactly what transient storage provides. Implementing that with persistent storage means writing a value to disk-backed state and then clearing it again, with the gas refund mechanics that go with it. Transient storage makes the same pattern cheap and simple, and the same applies to any temporary state a transaction needs to carry: locks, accumulators, and intermediate values passed between calls.

What this changes for builders

Contracts that already compile for Ethereum are closer to running unmodified on Ontology. Common libraries and tooling that assume these instructions no longer need chain-specific handling, and the bytecode a modern compiler emits is smaller than the bytecode it was previously forced to emit.

One practical note: v3.1.2 adds these four instructions specifically, not the complete opcode set of any single Ethereum upgrade. Set your target EVM version explicitly in your build configuration rather than relying on the compiler default, and test deployments against the upgraded network before committing to production.

Node operators: what you need to do

Every Ontology MainNet upgrade depends on the node network moving with it. All Ontology node operators, including consensus nodes, candidate nodes, and sync nodes, should complete the upgrade to v3.1.2 as soon as possible, and before block height 20,800,000 is reached.

The release is available on GitHub: ontology v3.1.2.

Timely upgrades across the node network keep MainNet operating stably through the transition and ensure compatibility with the improvements above. Nodes that have not upgraded by the time the block height is reached will fall out of consensus with the rest of the network.

The infrastructure underneath

Ontology’s strategy is built on verified human data: identity people own, data given with consent, and a record that holds up to scrutiny. That strategy asks people to contribute data and asks projects to verify it, which means it depends on a network where transactions are fast, inexpensive, and predictable enough that contributing is not a cost decision.

That is what a release like v3.1.2 is for. It is not the headline; it is the reason the headline is possible. Keeping the Ontology EVM current with the standards the rest of the ecosystem builds against is how the trust layer stays usable at scale.

The wider strategy is set out in full here: Verified Human Data: Ontology’s AI-Era Vision at Eight.

Resources

Thank you to all node operators and community members for your continued support of the Ontology ecosystem.

Ontology Network

Geoff R