89 lines
3.2 KiB
Markdown
89 lines
3.2 KiB
Markdown
# AIP-12: The Virtual Machine: Extend the EVM, not a New VM
|
|
|
|
## Preamble
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| AIP | 12 |
|
|
| Title | The Virtual Machine: Extend the EVM, not a New VM |
|
|
| Author | Aere Network Foundation |
|
|
| Type | Informational |
|
|
| Category | (none) |
|
|
| Status | Final |
|
|
| Created | 2026-07-19 |
|
|
| Requires | None |
|
|
| Supersedes | None |
|
|
| Superseded-By | None |
|
|
| Ratification | Foundation-ratified (pre-decentralization) |
|
|
|
|
## Abstract
|
|
|
|
This AIP records the decision to keep the EVM unchanged and to add Aere's
|
|
differentiating capability as precompiles and client-fork rules at reserved
|
|
addresses, rather than designing a new virtual machine. It backfills a decision
|
|
already live on chain 2800.
|
|
|
|
## Motivation
|
|
|
|
Aere differentiates on post-quantum verification, parallel execution, and
|
|
extended block-hash lookback. It must add these without taxing the developer
|
|
surface it depends on for adoption.
|
|
|
|
## Specification
|
|
|
|
Solidity, EVM bytecode, JSON-RPC, and the developer tooling are unchanged.
|
|
Differentiation is added as:
|
|
|
|
- precompiles at otherwise-empty reserved addresses (the `0x0AE1`..`0x0AE5` band,
|
|
live from block 9,189,161, AIP-7), and
|
|
- client-fork rules activated in the same manner Ethereum activates its own hard
|
|
forks.
|
|
|
|
No new instruction set, no new language, no nonstandard account model, and no
|
|
nonstandard RPC.
|
|
|
|
## Rationale
|
|
|
|
A mature VM has years of implementation hardening, a known cost model, and an
|
|
operational history; a new VM starts that clock at zero, maximizing both
|
|
technical and adoption risk. The EVM is the single largest smart-contract
|
|
developer surface in existence, and every deviation (a nonstandard opcode,
|
|
account model, or RPC) is a tax on every developer and every tool. Aere's thesis
|
|
is settlement, not a novel programming model, so the design keeps the tested
|
|
execution environment intact and adds differentiation only at the EVM's standard
|
|
extension points. Nothing about Aere's account, passkey, or post-quantum surface
|
|
depends on a nonstandard EVM.
|
|
|
|
**Alternatives rejected.** Designing a new, purpose-built VM (a new bytecode,
|
|
language, or non-EVM environment) optimized around Aere's differentiators.
|
|
|
|
## Backwards Compatibility
|
|
|
|
Full EVM compatibility is the point of the decision. Precompiles at previously
|
|
empty addresses are additive: before activation those addresses were empty
|
|
accounts, so a call to one returned empty rather than reverting. AIP-7 covers the
|
|
activation-boundary consequences.
|
|
|
|
## Security Considerations
|
|
|
|
Some ambitions (base-layer parallel execution, an EVM-in-a-zkVM) must be reached
|
|
inside the existing model rather than designed in from scratch. Those remain
|
|
roadmap and are labeled as such wherever they appear. Adding capability at
|
|
reserved addresses means the address band must be treated as consensus-critical:
|
|
activating a precompile at an address that historical transactions already called
|
|
would change their re-execution result, which is why AIP-16 forward-dates its
|
|
milestone rather than folding into a crossed one.
|
|
|
|
## Reference Implementation and On-Chain Deployment
|
|
|
|
Chain ID 2800. Live precompiles and their activation block are specified in
|
|
AIP-7.
|
|
|
|
## Errata
|
|
|
|
None.
|
|
|
|
## Copyright
|
|
|
|
Released to the public domain (CC0). No rights reserved.
|