corona: doc drift cleanup — CHANGELOG references match renamed Go code

Scientist audit flagged stale Pulsar references in CHANGELOG.md (e.g.
'Pulsar-SHA3' production default name, 'pulsar/primitives/hash.go' paths).
The Go code was already renamed in commit a2c1d1d; this aligns the docs.

DESIGN.md's QUASAR-PULSAR-*-v1 prefix table is preserved — those are
Quasar consensus lane prefixes describing Pulsar pulse messages, NOT
Corona-internal tags. Different scope.
This commit is contained in:
Hanzo AI
2026-05-13 14:28:54 -07:00
parent a2c1d1da31
commit 610263072a
2 changed files with 18 additions and 18 deletions
+14 -14
View File
@@ -1,6 +1,6 @@
# pulsar CHANGELOG
# corona CHANGELOG
Notable changes to the `pulsar` module. Pre-release; semantic versioning
Notable changes to the `corona` module. Pre-release; semantic versioning
applied per PHILOSOPHY.md (patch only — never minor/major without explicit
approval).
@@ -8,7 +8,7 @@ approval).
### Breaking — F22 hash-suite injection into Sign
`pulsar/primitives/hash.go` no longer hardcodes `blake3.New()`. Every
`corona/primitives/hash.go` no longer hardcodes `blake3.New()`. Every
Sign-path primitive now takes a `hash.HashSuite` as its first argument:
```
@@ -21,10 +21,10 @@ Hash(suite, A, b, D, sid, T) // was Hash(A, b, D, sid, T)
LowNormHash(suite, r, A, b, h, mu, kappa) // was LowNormHash(r, A, b, h, mu, kappa)
```
`suite == nil` resolves to the production default, `Pulsar-SHA3`
`suite == nil` resolves to the production default, `Corona-SHA3`
(cSHAKE256 / KMAC256 / TupleHash256 per FIPS 202 + NIST SP 800-185).
The legacy `Pulsar-BLAKE3` suite remains available via
`hash.NewPulsarBLAKE3()` for cross-port byte checks.
The legacy `Corona-BLAKE3` suite remains available via
`hash.NewCoronaBLAKE3()` for cross-port byte checks.
`sign.Party` gains a `Suite hash.HashSuite` field, defaulted by
`NewParty` to `hash.Default()`. Operators can construct with an explicit
@@ -33,29 +33,29 @@ function `sign.Verify(...)` keeps its previous signature and now resolves
to the production default internally; the suite-explicit form is
`sign.VerifyWithSuite(suite, ...)`.
This closes the gap where the HIP-0077 claim that Pulsar uses SHA-3
This closes the gap where the HIP-0077 claim that Corona uses SHA-3
cSHAKE256/KMAC256/TupleHash256 in production was structurally false at
the Sign layer (only `pulsar/reshare/`, `pulsar/dkg2/`, `pulsar/keyera/`
were consuming `pulsar/hash/HashSuite` previously).
the Sign layer (only `corona/reshare/`, `corona/dkg2/`, `corona/keyera/`
were consuming `corona/hash/HashSuite` previously).
### Follow-up — KAT regeneration
The historical BLAKE3 KAT transcripts emitted by
`cmd/corona_oracle_v2` were computed against the previous raw
`blake3.New()` framing in `primitives/hash.go`. After this refactor, the
oracle still emits under `pulsarhash.NewPulsarBLAKE3()`, but the framing
now includes the suite's customization tags (`PULSAR-HC-v1`,
`PULSAR-HU-v1`, `PULSAR-PRF-v1`, etc.) and length-prefixing, so the
oracle still emits under `coronahash.NewCoronaBLAKE3()`, but the framing
now includes the suite's customization tags (`CORONA-HC-v1`,
`CORONA-HU-v1`, `CORONA-PRF-v1`, etc.) and length-prefixing, so the
emitted bytes no longer byte-match pre-refactor JSON.
The Pulsar-SHA3 production KATs are not yet emitted. Both lie outside
The Corona-SHA3 production KATs are not yet emitted. Both lie outside
the scope of this PR:
- Regenerate the legacy BLAKE3 oracle JSON
(`go run ./cmd/corona_oracle_v2 emit --out ./test/kats/blake3`)
and cross-validate with the C++ port.
- Land a parallel `cmd/corona_oracle_v3` (or `--suite` flag) that
emits Pulsar-SHA3 KATs under `./test/kats/sha3/` and pin them as the
emits Corona-SHA3 KATs under `./test/kats/sha3/` and pin them as the
normative reference for downstream ports.
The skipped test `TestKATsRegenerated` in
+4 -4
View File
@@ -380,7 +380,7 @@ Every signature produced under any Quasar lane carries a distinct version-tagged
| `QUASAR-PULSAR-COMBINE-v1` | Pulsar finalize transcript | Pulsar |
| `QUASAR-PULSAR-REFRESH-v1` | Refresh activation cert (same set) | Pulsar |
| `QUASAR-PULSAR-RESHARE-v1` | Reshare activation cert (set rotation) | Pulsar |
| `QUASAR-PULSAR-ACTIVATE-v1` | Generic activation cert (Refresh/Reshare alias) | Pulsar |
| `QUASAR-CORONA-ACTIVATE-v1` | Generic activation cert (Refresh/Reshare alias) | Pulsar |
| `QUASAR-PULSAR-REANCHOR-v1` | Reanchor authorization (governance) | Pulsar |
If a new class of signed message emerges, it MUST get its own version-tagged prefix; never reuse one.
@@ -390,7 +390,7 @@ If a new class of signed message emerges, it MUST get its own version-tagged pre
The activation message bound by the new committee under the unchanged GroupKey:
```
QUASAR-PULSAR-ACTIVATE-v1 ||
QUASAR-CORONA-ACTIVATE-v1 ||
chain_id ||
network_id ||
key_era_id ||
@@ -416,7 +416,7 @@ The last two fields are essential for KAT/cross-language byte-identical replay.
After resharing finishes the math, the chain does NOT accept the new epoch on faith. The new committee threshold-signs an activation message under the **unchanged GroupKey** using their freshly-derived shares; only when this signature verifies does the chain mark the new epoch live.
```
activation_msg = "QUASAR-PULSAR-ACTIVATE-v1"
activation_msg = "QUASAR-CORONA-ACTIVATE-v1"
|| transcript_hash (32 bytes; from TranscriptInputs.Hash)
|| reshare_transcript_hash (32 bytes; exchange digest)
@@ -806,7 +806,7 @@ GPU acceleration: only the **inherited Sign protocol** has GPU-relevant primitiv
| Inherited Sign1/Sign2/Combine | byte-equal vs upstream |
| `pulsar/reshare/` (kernel + VSR scaffolding) | shipping (45 tests passing) |
| `pulsar/keyera/` | shipping (proper t-of-n via general Shamir) |
| Activation cert format `QUASAR-PULSAR-ACTIVATE-v1` | shipping |
| Activation cert format `QUASAR-CORONA-ACTIVATE-v1` | shipping |
| Quasar `epoch.go` LSS-Pulsar wiring | shipping (consensus 119c2166 lineage) |
| LSS-Pulsar adapter at `threshold/protocols/lss/lss_pulsar.go` | shipping (10/10 acceptance tests) |
| Warp 2.0 envelope at `warp/pulsar` | shipping |