The published patch carried a one-block boundary defect: the seal rule asks the index-to-address map at the parent height (H-1) while the registry schedule binds inclusively from H, so at the very first anchor the schedule was empty and the lookup fell back to a head map that is empty on a node synced from genesis. A valid certificate was rejected. Fixed in both lookup paths: when the schedule has an entry at exactly blockNumber+1, answer from that entry's verified bound registry. The boundary stays exactly one block. Proven by import, not by assertion: the package-built node was stuck at 13,013,999 with 6,646 rejections; with the fix it crossed 13,014,000 in 42 seconds and imported 253,729 further blocks through the anchor era with zero rejections. Tests: new PqParentHeightAlignmentTest 3/3, consensus:common 391/0, consensus:qbft 217/0. Negative control measured: disarm the condition and the measuring test goes red; restore it and it is green. Patch verified to apply cleanly on a pristine upstream checkout, alone and in series with 0001/0004/0005; file list is the previous 75 plus the new test, and every untouched section is byte-identical to the old patch. The anchor/ source copy in this package was brought to the same state so the two cannot diverge. Honest limit, recorded in IMPORT-PROOF-STARE: further along, at 13,267,729, the node stops again for a DIFFERENT reason. Blocks in a band there carry an attached certificate whose vanityData is the ordinary client string rather than the digest, at heights a single static interval treats as anchor heights. The best-supported reading is that the fleet ran a different anchoring configuration in that window (these values are not consensus-bound), so the package needs a HISTORICAL anchoring schedule, not one value. Stated rather than implied.
71 lines
5.2 KiB
Markdown
71 lines
5.2 KiB
Markdown
# Dovada de import a pachetului public: cat s-a dovedit si unde s-a oprit, 15 august 2026
|
|
|
|
Un nod construit DOAR din pachetul public (petice 0001+0003+0004+0005 pe amonte pristin
|
|
d2032017, build verde JDK 21) a fost pus sa sincronizeze chain 2800 de la blocul 0, pe laptop,
|
|
in timpul zilei lui H. Ce s-a dovedit, masurat, si unde s-a oprit, scris cinstit.
|
|
|
|
## DOVEDIT
|
|
- **Sincronizare de la geneza pana in era ancorei.** Nodul a importat de la blocul 0, a
|
|
traversat fork-ul precompilelor (9.189.161, reparat de peticul 0005: izolarea Osaka +
|
|
EIP-2935) si fork-ul pragului de taxa (10.141.734, peticul 0004), fara divergenta, ~13
|
|
milioane de blocuri.
|
|
- **Garda registrului fail-closed, exact cum promite.** La 13.014.000 nodul FARA registre a
|
|
refuzat sa importe (AERE-PQC-REG-BLOCK-01), cu mesajul care spune operatorului sa instaleze
|
|
registrul numit LA ACEA inaltime, nu mai devreme. Instalate registrele publice (aduse intern,
|
|
amprente verificate), nodul le-a legat: 7 chei la 13.014.000, 9 la 13.600.000, fiecare rand cu
|
|
dovada de posesie Falcon verificata, "correctly staged for the activation".
|
|
|
|
## UNDE S-A OPRIT, si e o CONSTATARE, nu un simplu esec
|
|
- La blocul 13.014.000, prima ancora reala (extraData 2515 octeti, certificat cu index 0),
|
|
regula `PqAnchorSealsRule` din binarul PUBLIC respinge blocul:
|
|
"certificate carries index 0, which the registry does not bind to any validator address".
|
|
- **Dar registrul pe care nodul insusi l-a legat (manifest-13014000.json) CONTINE cheia 0**
|
|
(campuri "0".."6", 7 chei, bindHeight 13014000, hash canonic 0xa96ac96d... care e chiar
|
|
hash-ul cerut de lant). Si productia (binarul de productie) valideaza acest bloc
|
|
perfect, de doua luni.
|
|
- Deci binarul PUBLIC leaga registrul intr-un fel si il CITESTE in regula de sigilii in alt fel:
|
|
legarea vede cheia 0, regula spune ca indexul 0 e nelegat. Aceeasi clasa de defect: doua implementari ale aceleiasi idei care diverg. **Peticul 0003 public difera de sursa de
|
|
productie in maparea index -> adresa la validare.**
|
|
|
|
## CE INSEAMNA
|
|
Aceasta e o piesa de dovada, nu o rusine: pachetul public inca NU reproduce validarea ancorei
|
|
bit cu bit fata de productie, si o stim fiindca am incercat pe bune, nu fiindca am presupus.
|
|
Sute de teste unitare verzi nu au prins-o; un import de la geneza a prins-o intr-o seara, a
|
|
doua oara cand aceeasi metoda ne salveaza (prima data: binarul care ingheta nodul, gasit tot prin import real). Reparatia (alinierea maparii index din
|
|
peticul 0003 cu sursa de productie) e o sesiune de binar dedicata, cu control negativ, nu o
|
|
carpeala in focul serii.
|
|
|
|
**RUN-A-NODE.md poarta deja avertismentul corect:** aplica 0001+0003+0004+0005 si trateaza
|
|
build-ul ca urmaritor pana la o dovada de import completa. Aceasta dovada de import a ajuns pana
|
|
la prima ancora si a gasit exact veriga care lipseste. Constatarea intra in registru.
|
|
|
|
## Adus la zi 15 august, noaptea
|
|
|
|
- **Cauza, gasita si dovedita in aceeasi seara:** un decalaj de un bloc la granita orarului.
|
|
Regula sigiliilor judeca certificatul purtat de blocul primei ancore H intreband registrul la
|
|
inaltimea PARINTELUI, H-1, fiindca aceea e inaltimea peste care se semneaza sigiliile. Orarul
|
|
registrelor leaga insa INCLUSIV de la H, deci la H-1 nu leaga nimic, si ambele cautari pe
|
|
inaltime cadeau pe registrul de cap, care pe un nod sincronizat de la geneza e gol. Nu era o
|
|
divergenta de continut a maparii index catre adresa, cum banuia sectiunea de mai sus: era
|
|
intrebarea pusa cu un bloc mai jos decat singura intrare care putea raspunde.
|
|
- **Reparatia minima, in FalconSealSupport, pe amandoua drumurile (cheie si adresa):** cand
|
|
orarul are o intrare la EXACT blockNumber+1, raspunsul vine din registrul legat si verificat
|
|
al acelei intrari, nu din fisierul de cap neverificat. Granita e exact un bloc: cu doua sau
|
|
mai multe blocuri sub orar nu se schimba nimic.
|
|
- **Dovada, masurata, nu presupusa:** nodul construit din pachete a trecut de 13.014.000 si a
|
|
mers peste 25.000 de blocuri fara nicio respingere, trecand si de treapta cu prag 3 de la
|
|
13.034.000. Suitele modulelor de consens: 608 teste, zero esecuri, inclusiv testul nou
|
|
PqParentHeightAlignmentTest, construit pe forma nodului public (cap gol, registrul doar ca
|
|
istorie). Control negativ facut: cu conditia dezarmata, exact proba granitei iese rosie; cu
|
|
ea la loc, verde.
|
|
- **Peticul 0003 publicat poarta acum reparatia**, regenerat din amonte pristin, cu aceeasi
|
|
lista de fisiere plus testul nou, si se aplica curat in seria 0001, 0003, 0004, 0005.
|
|
Avertismentul din RUN-A-NODE.md ramane pana la o dovada de import completa pana la varf.
|
|
- **Unde a ajuns rularea dupa reparatie, scris cinstit:** nodul a mers de la 13.014.000 pana la
|
|
13.267.729, adica 253.729 de blocuri prin era ancorei, cu zero respingeri de certificat, si
|
|
s-a oprit acolo la o granita NOUA, separata de cea reparata: blocuri din banda urmatoare
|
|
poarta certificat atasat dar vanityData e sirul obisnuit al clientului, nu digestul, la
|
|
inaltimi pe care configuratia statica a nodului le considera inaltimi de ancora, si regula
|
|
digestului le refuza. Productia a acceptat acele blocuri la vremea lor, deci pachetul public
|
|
inca nu reproduce si acest interval; e urmatoarea veriga de investigat, cu aceeasi metoda.
|