87 lines
3.2 KiB
Markdown
87 lines
3.2 KiB
Markdown
# AIP-11: Interoperability: Hyperlane-Compatible Messaging plus zk Light Clients, not IBC
|
|
|
|
## Preamble
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| AIP | 11 |
|
|
| Title | Interoperability: Hyperlane-Compatible Messaging plus zk Light Clients, not IBC |
|
|
| 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 build cross-chain interoperability as an
|
|
EVM-native, Hyperlane-compatible messaging layer plus zero-knowledge light
|
|
clients, rather than adopting IBC natively. It backfills a decision already made
|
|
and partly deployed.
|
|
|
|
## Motivation
|
|
|
|
Aere's value proposition is that it is an ordinary EVM chain. Cross-chain interop
|
|
must serve permissionless, EVM-familiar builders while also offering
|
|
trust-minimized verification of a counterparty's finality, and those two goals
|
|
pull in different directions.
|
|
|
|
## Specification
|
|
|
|
- An EVM-native, Hyperlane-compatible messaging layer: a Mailbox-compatible
|
|
`AereMessenger` and an interchain gas paymaster `AereIGP`.
|
|
- An ERC-7683 intent layer and an Across-v3-compatible spoke pool.
|
|
- A zero-knowledge interop path: on-chain zk light clients verifying a
|
|
counterparty's consensus finality from inside a contract (inbound Ethereum
|
|
sync-committee finality, outbound Aere QBFT finality) via SP1 Groth16 proofs.
|
|
|
|
## Rationale
|
|
|
|
IBC's design philosophy, verifying the counterparty's consensus rather than
|
|
trusting a bridge committee, is the right one, and Aere adopts the philosophy
|
|
directly. Aere splits the problem: for permissionless, developer-familiar interop
|
|
it uses the Hyperlane-compatible interfaces the EVM tooling ecosystem already
|
|
speaks; for the trust-minimization that is IBC's real contribution it built the
|
|
zk light clients, which capture "verify the counterparty's consensus, do not
|
|
trust a relayer" without leaving the EVM world.
|
|
|
|
**Alternatives rejected.** IBC as a protocol: it is built around Tendermint-style
|
|
light clients and a non-EVM connection, channel, and packet model. Adopting it
|
|
natively would import a substantial non-EVM stack and its tooling into a chain
|
|
whose entire premise is that it is an ordinary EVM.
|
|
|
|
## Backwards Compatibility
|
|
|
|
None.
|
|
|
|
## Security Considerations
|
|
|
|
The Hyperlane-compatible endpoints are interface-faithful and deployed, but a
|
|
live decentralized relayer and interchain-security-module network is **not** yet
|
|
stood up: the current bridge path runs through a single Foundation signer with a
|
|
relayer pending. Until that changes, the messaging layer's trust assumption is
|
|
the Foundation, not a validator set.
|
|
|
|
The zk light clients are trust-minimized, not trustless, and **not quantum-safe**:
|
|
their committed seals are classical secp256k1 and the proof wrap is Groth16 over
|
|
BN254, which is Shor-breakable. A post-quantum-sound replacement is recorded in
|
|
AIP-16 and is not live.
|
|
|
|
## Reference Implementation and On-Chain Deployment
|
|
|
|
Deployed messaging and intent interfaces are listed in `sdk-js/src/addresses.ts`.
|
|
The zk light-client and verifier-gateway work is under `aere-contracts` and
|
|
the zk work trees.
|
|
|
|
## Errata
|
|
|
|
None.
|
|
|
|
## Copyright
|
|
|
|
Released to the public domain (CC0). No rights reserved.
|