Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA Two things came out of an adversarial pass on my own reference implementation this week. One is already fixed in the text; the other is a design question I’d rather put here before writing any code.
How it was done, because the method may be more reusable than either finding. Four independent model families — DeepSeek, Perplexity, ChatGPT, Gemini — were each given the same thing: the source of the deployed contract, the claim to refute, and nothing else. No expected outcomes, no hints about which checks exist, no cross-contamination. Every proposed sequence was then executed against the deployed contract or a local fork. The chain decided, not the model.
That inverts the usual objection to using a model for review. Its unreliability stops mattering, because it is never asked to assert anything — only to propose something that execution will accept or reject. An unreliable generator plus an infallible verifier is a fuzzer. Three of the four produced real findings; one produced nothing usable. The strongest finding came from a single model, which is the argument against asking only one.
Finding one, already corrected in the spec. My conservation rule debits the immediate parent at spawn, which stops N siblings from each carrying the full parent cap. It does not stop depth: a child that has been debited from its parent still starts its own allocation counter at zero, so a chain of D generations each re-issuing its cap reaches D times the root’s ceiling. Measured: root at 100, three generations, lineage at 300. The Security Considerations previously recommended “debiting the parent” as the mitigation for aggregate spend — my own implementation does exactly that, and does not achieve the bound. That entry now says an aggregate bound requires debiting the whole lineage, not just the parent.
Finding two, and the actual question. My mandate carries a requireLease flag — a dead-man’s switch. The spec defines renew() for it. The deployed reference contract never implements renew() and never reads the flag at runtime: it is stored, inherited, non-strippable, and completely inert. A smoke detector with no battery.
Implementing renew() is where I got stuck, and the objection is not about the code.
The whole design rests on one sentence: nothing ever relaxes. A child can only narrow, a generation counter only counts down, an expiry never moves out. renew() would be the first function in the contract that relaxes anything. Even guardian-gated and bounded by the parent’s expiry, the claim degrades from “nothing relaxes” to “nothing relaxes, except the guardian may extend a lease.” That is a materially weaker thing to defend, and the weakening is permanent.
What I’m leaning toward: seal the lease at birth, and renew in fixed periods.
Three values are set when the agent is created and never change again: the length of one period, the number of periods, and therefore the absolute end. Each is subject to the same inheritance rule as everything else — a child’s may never exceed its parent’s. Renewal advances the current expiry by exactly one period, never past the absolute end.
Nothing relaxes. Renewal does not extend a bound; it consumes slack that was granted at creation. It is not extending a lease, it is paying monthly rent on a three-year lease signed up front — you may leave early, you may not stay four years.
The second effect matters as much as the first: it removes discretion. With a free renew() the guardian picks the new date. With fixed periods the guardian can only answer yes or no to the next one. Merit stops setting a duration and merely ticks a box — and “this agent is performing well, so it deserves more life” is exactly the kind of judgement a control layer should not be making. If an agent genuinely needs more than its ceiling, the answer is to spawn a new one with a fresh grant: a visible, dated decision rather than a quiet extension.
Where I’d like to be wrong:
Is there a real deployment where the ceiling has to be revisable — where sealing total lifetime at creation is operationally impossible rather than merely inconvenient?
Is reducing the guardian to a binary the right target, or is a renewal decision at all too much discretion for this layer, and expiry should simply be final?
Does anyone see a way a fixed-period lease reintroduces a relaxation I haven’t spotted — particularly across a lineage where ancestors and descendants are on different period boundaries?
The third one is where I’d put my own money.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | ERC-8226: Regulated Agent Mandate | 0 | 8.97 | 14-08-2026 |
| 2 | ERC-8337: Agent Memory State | 0 | 7.65 | 26-07-2026 |
| 3 | Proposing a family of candidate ERC interfaces for titled asset infrastructure — architecture review | 0 | 7.85 | 27-07-2026 |
| 4 | ERC-8348: Financial Lease | 0 | 8.24 | 28-07-2026 |
| 5 | [IDEA] Native Ethereum Delegation (NED) - Protocol-Routed Delegation With Split-Neutral Allocation and Coverage-Bounded Consensus Amplification | 0 | 13.6 | 13-08-2026 |
| 6 | ERC-8350: Agent Memory State Registry | 0 | 13.32 | 14-08-2026 |
| 7 | ERC-8354: Confidential Agent Policy Verdicts | 0 | 12.87 | 24-07-2026 |
| 8 | EIP Editing Office Hour (EIP + ERC ) Meeting #111, Aug 18, 2026 | 0 | 18.71 | 13-08-2026 |
| 9 | ERC-8004: Trustless Agents | 0 | 7.85 | 13-08-2026 |
| 10 | ERC-8240: Trust Infrastructure for Agents and Assets | 0 | 5 | 08-07-2026 |