4a0b48588c
Aere Network public source. Everything here can be checked against the live chain (chain id 2800, https://rpc.aere.network). Scope note, stated up front rather than buried: consensus on chain 2800 is classical secp256k1 ECDSA QBFT. The post-quantum work in this repository is at the signature, precompile, account and transport layers. Nothing here makes the consensus post-quantum, and no document in it should be read as claiming so.
67 lines
2.3 KiB
Markdown
67 lines
2.3 KiB
Markdown
# AIP-N: Title in Title Case
|
|
|
|
## Preamble
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| AIP | N |
|
|
| Title | Short descriptive title |
|
|
| Author | Name or handle |
|
|
| Type | Standards Track / Meta / Informational |
|
|
| Category | Core / Networking / Interface / ARC / (omit for Meta and Informational) |
|
|
| Status | Draft / Review / Last Call / Final / Living / Withdrawn / Stagnant |
|
|
| Created | YYYY-MM-DD |
|
|
| Requires | Comma-separated AIP numbers, or None |
|
|
| Ratification | Foundation-ratified (pre-decentralization), or the governance basis in force |
|
|
|
|
## Abstract
|
|
|
|
Two to four sentences. State what the AIP does in plain language. A reader should
|
|
understand the whole change from this paragraph alone.
|
|
|
|
## Motivation
|
|
|
|
Why this change is worth making. What problem it solves, who it helps, and what
|
|
goes wrong without it. Be concrete. If the change is already live, say what
|
|
prompted it.
|
|
|
|
## Specification
|
|
|
|
The exact, unambiguous mechanism. This is the normative section. For a contract
|
|
change, describe the interface, the state, the invariants, and the parameters
|
|
with their values. For a consensus change, give the exact configuration keys and
|
|
values and the activation point. Use MUST / SHOULD / MAY where a requirement is
|
|
binding on implementers.
|
|
|
|
For anything that touches gas or size, cite only numbers that are measured
|
|
on-chain or sourced from a repo fixture. Label any unmeasured number as
|
|
"to be measured".
|
|
|
|
## Rationale
|
|
|
|
Why the design is the way it is. Alternatives considered and why they were
|
|
rejected. Trade-offs accepted.
|
|
|
|
## Backwards Compatibility
|
|
|
|
What breaks, what does not, and how integrators migrate. "None" if nothing
|
|
breaks.
|
|
|
|
## Security Considerations
|
|
|
|
Attack surface, trust assumptions, and known weaknesses. This section is required
|
|
and must be honest. If the change depends on a trusted operator, a small
|
|
validator set, or an unaudited contract, say so here.
|
|
|
|
## Reference Implementation and On-Chain Deployment
|
|
|
|
For a live change: the contract source path(s) in this repo, the canonical
|
|
address(es) copied verbatim from `sdk-js/src/addresses.ts`, and the proving
|
|
transaction hashes and block numbers where available. For a not-yet-live change:
|
|
the branch or spec that implements it and the plan to ship.
|
|
|
|
## Copyright
|
|
|
|
Released to the public domain (CC0). No rights reserved.
|
|
</content>
|