Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA An update to #2080, which is still open as a draft. It adds two more commits. They change the spec text and two tests; the contract, the interface, the storage layout, the EIP-712 domain and 0x94f0ee34 are all unchanged.
The continuity check was ambiguous
Under Wrapped Name Lifecycle, coordinators were told to treat an attestation as expiring at the end of the grace period in force when it was set, “unless the name was renewed before that grace period ended”.
Read literally, a single renewal within grace lifts the bound permanently. On a mainnet fork, G→X→M2 still passed that reading after X was renewed once, lapsed, and was registered by someone else.
This was a gap in the guidance, not in the contract: verifyPath behaved as specified throughout.
The replacement rule is a registration boundary
An attestation becomes ineligible once the BaseRegistrar emits NameRegistered for a .eth second-level name it involves, as trustor or trustee, after the attestation’s TrustSet.
NameRenewed never moves the boundary, however many renewals there are.
Events are ordered by block, transaction index and log index. The coordinator checks the label against the node.
A coordinator that can’t establish the label or the events doesn’t rely on the attestation.
The rule is about registration, not control. A sale within one registration doesn’t trigger it; the existing guidance on monitoring control changes covers that case.
It also covers any name on the path below a .eth second-level name, which counts as registered again whenever that ancestor is, because the ancestor’s next registrant can reassign it.
The coordinator checks the TrustSet of the record the path actually uses after scope fallback, not the latest record for the pair in any scope.
One deliberate cost: a holder who lets a name lapse and then registers it again has to be endorsed again by every trustor that endorsed it, not only reissue its own endorsements. Trustors should watch their trustees’ registrations.
Testing and evidence
I tested the rule against a non-normative coordinator-side reference, both locally and on a mainnet fork against the deployed registrar controller and BaseRegistrar.
The fork cases were:
One renewal, then a re-registration.
Several renewals, then a re-registration.
Several renewals with no re-registration.
Re-registration by the same holder.
A registration and an endorsement in the same block.
A transfer within a registration.
Wrapped names and the ENSv2 Graveyard haven’t been run yet.
The Rationale also no longer claims that recording a name’s registrar expiry would reveal an earlier registration on-chain. It wouldn’t, because a renewal and a new registration both leave a later expiry.
Independent verification
Spap reran G→T→M2 with their own implementation of the coordinator check as merged in #2077 (ENS forum).
Every re-registered path was rejected, nothing was rejected wrongly at issuance or after a renewal, and the liveness read caught a wrapped name renewed by the current controller.
Those cases don’t include a renewal before re-registration, so they don’t reach the gap above.
I’ve asked for that case against this rule, and I’m treating the rule as provisional until it runs. #2080 stays in draft until then.
Smaller corrections in the same update
These address places where the text claimed more than the standard guarantees:
Gate verdicts are point-in-time. A participant admitted at acceptance stays admitted unless the coordinator checks again. Coordinators whose execution depends on it SHOULD re-evaluate the gate in the executing transaction, for example in executeCoordination with the paths in executionData. That re-check reads registry state only. It can’t see the registrar events the continuity check needs, so that check stays off-chain, as close to execution as possible. Denial now “rejects in every evaluation after the denial”, not “at once”.
Upgradeable proxies. For a registry behind one, the address plus a one-time source check isn’t enough: consumers track the implementation and whoever can upgrade it.
Gate Constraints. The text now names the one configuration setIdentityGate rejects, rather than implying it rejects every gate that can never pass.
ENS Name Transfer. Stored attestations survive a change of controller. Signed but unsubmitted ones verify only against the current controller.
Comments welcome, especially on the boundary rule.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | ERC-8434: Agent Identity (AID) | 0 | 9.38 | 19-10-2026 |
| 2 | EIP Editing Office Hour (EIP + ERC ) Meeting #111, Aug 18, 2026 | 0 | 18.71 | 13-08-2026 |
| 3 | ERC-8226: Regulated Agent Mandate | 0 | 8.97 | 14-08-2026 |
| 4 | ERC-8004: Trustless Agents | 0 | 8.78 | 17-10-2026 |
| 5 | ERC-8337: Agent Memory State | 0 | 7.65 | 26-07-2026 |
| 6 | ERC-8100: Representable Contract State | 0 | 5 | 08-07-2026 |
| 7 | EIP-0000 Native ETH as ERC-20 System Contract – Draft for feedback | 0 | 12.39 | 05-08-2026 |
| 8 | EIP Editing Office Hour (EIP + ERC ) Meeting #108, July 28, 2026 | 0 | 18.32 | 27-07-2026 |
| 9 | ERC-8335: Account-Level Transfer With Authorization | 0 | 7 | 10-07-2026 |
| 10 | Post-Quantum Stateless Steganography & MTU Bounds: Bridging P2P Censorship Resistance to Quantum Networks | 0 | 18.31 | 17-10-2026 |