aere-network/aere-node
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Dated correction 2026-11-04 (fourth pass) to vote and message attribution since block 24,300,000: one path of the second client until 2026-10-31 12:27Z (AIP-22 rule 3, correction of 2026-11-01)

Browse Source
This commit is contained in:
Aere Network 2026-11-04 10:35:12 +02:00
parent 8db21bdc75
commit c03d4266eb
2 changed files with 10 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -319,4 +319,4 @@ able to trust without checking.
well: every validator refuses a commit without a valid seal, and nine of the ten refuse any consensus message without well: every validator refuses a commit without a valid seal, and nine of the ten refuse any consensus message without
one; the tenth, which runs the second client, applies the rule to proposal, prepare and round-change messages from one; the tenth, which runs the second client, applies the rule to proposal, prepare and round-change messages from
AIP-22 stage 4, whose height is not yet set on chain 2800. On the testnet the second client's validator enforces AIP-22 stage 4, whose height is not yet set on chain 2800. On the testnet the second client's validator enforces
commits since block 1,314,403 and all four types since block 3,117,000 (SPEC section 2.6).) (*Added 2026-10-27:* stage 4 is in force on chain 2800 since block 24,300,000, reached on 2026-10-25; from it the second client judges all four message types by their seals.) commits since block 1,314,403 and all four types since block 3,117,000 (SPEC section 2.6).) (*Added 2026-10-27:* stage 4 is in force on chain 2800 since block 24,300,000, reached on 2026-10-25; from it the second client judges all four message types by their seals.) (*Note added 2026-11-04 (to the addition of 2026-10-27 before it):* its clause on the second client had one exception until 2026-10-31 12:27Z: on one path of the second client (the Nethermind-derived one) the author of a proposal was taken at the height named in its payload, so for a payload height below 24,300,000 it was the signer of the ECDSA envelope; since 2026-10-31 12:27Z that client refuses at decoding a proposal whose block number differs from its payload height (AIP-22, correction of 2026-11-01 to rule 3 of section 4).)

10
SPEC.md
View File

@ -41,6 +41,14 @@ force; below `H_hdr` a header is still admitted on the ECDSA commit seals of one
2026-10-26 to rule 2 of section 4). The notes of 2026-10-14 that call `H_r` not set or inert, and of 2026-10-26 to rule 2 of section 4). The notes of 2026-10-14 that call `H_r` not set or inert, and of
2026-09-17 and 2026-10-09 that say `H_fin` is not set on chain 2800, describe their date; nothing removed). 2026-09-17 and 2026-10-09 that say `H_fin` is not set on chain 2800, describe their date; nothing removed).
Amended 2026-11-04 (to the amendment of 2026-10-26 above). Its sentence that from `H_fin` both clients attribute every
consensus message only through its verified post-quantum seal, and that the second client's proposal, prepare and
round-change layers are in force, had one exception until 2026-10-31 12:27Z: on one path of the second client (the
Nethermind-derived one) the author of a proposal was taken at the height named in its payload, so for a payload height
below 24,300,000 it was the signer of the ECDSA envelope. Since 2026-10-31 12:27Z that client refuses at decoding a
proposal whose block number differs from its payload height (AIP-22, correction of 2026-11-01 to rule 3 of section 4).
The amendment above is kept as it was written; section 2.7 carries a dated parenthesis; nothing removed.
## 0. Conventions, and how every statement here is grounded ## 0. Conventions, and how every statement here is grounded
Every normative statement in this document carries one of three markers: Every normative statement in this document carries one of three markers:
@ -525,7 +533,7 @@ second client applies the rule to the other three from AIP-22 stage 4, whose hei
on chain 2800 (section 2.6). A forged classical validator key alone therefore no longer opens a on chain 2800 (section 2.6). A forged classical validator key alone therefore no longer opens a
round, prepares or commits a block on the live network, since nine of the ten validators refuse such round, prepares or commits a block on the live network, since nine of the ten validators refuse such
messages without a seal. Until AIP-22 stage 4 it can still present proposal, prepare and round-change messages without a seal. Until AIP-22 stage 4 it can still present proposal, prepare and round-change
messages in that validator's name to the second client. Alone, that misleads one validator of ten, messages in that validator's name to the second client (corrected 2026-11-04: from block 24,300,000 until 2026-10-31 12:27Z one path of the second client took the author of a proposal that named a height below 24,300,000 from its ECDSA envelope, as the correction of 2026-11-01 to rule 3 of AIP-22 says). Alone, that misleads one validator of ten,
below `f` = 3, whose own commits stay sealed with its own key; combined with `f` Byzantine below `f` = 3, whose own commits stay sealed with its own key; combined with `f` Byzantine
validators, the misled second client would count as one more faulty node, and that case is not validators, the misled second client would count as one more faulty node, and that case is not
analyzed (*Corrected 2026-10-09:* until that date this paragraph said that all four messages "carry analyzed (*Corrected 2026-10-09:* until that date this paragraph said that all four messages "carry