feat: PQ threat added as domain + documented#121
Conversation
Meyanis95
requested review from
oskarth and
rymnc
and removed request for
oskarth
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds a Post‑Quantum Threats domain and glossary entries, introduces Native Account Abstraction and ZK Proof Systems patterns, updates the changelog, and inserts post‑quantum exposure notes or See‑also links across multiple existing pattern documents. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@CHANGELOG.md`:
- Around line 9-13: Update each new changelog entry (the five entries about
Post-Quantum Threats, Native Account Abstraction, ZK Proof Systems, glossary PQ
terms, and patterns fix) to include the PR reference "(`#121`)" at the end of each
line; specifically modify the entries shown in the diff so they end with " — ...
(`#121`)" (or append " (`#121`)" if the em-dash is already present), ensuring all
five lines include the PR number.
In `@domains/post-quantum.md`:
- Line 25: The table cell text "Grover only" should be rephrased for
style/precision; update the cell in domains/post-quantum.md (the row with
"**Hash-based signatures** | Merkle / one-time signatures") to use "Grover (not
Shor)" instead of "Grover only" and make the same replacement for the other
occurrence noted (the other cell referenced at lines 29-29) so the authoritative
threat table consistently reads "Grover (not Shor)".
- Line 37: The phrase "Hash/STARK-first stack" in the table is a valid compound
adjective and the static analysis warning is a false positive; either mark the
rule as exempt for this line or, if you must satisfy stricter style checks,
normalize the phrasing to an explicit hyphenation pair such as "Hash-first /
STARK-first stack" or "Hash-first (STARK-first) stack" so the linter recognizes
the compound adjective; target the table cell containing "Hash/STARK-first
stack" (and related "Hash-first" / "STARK-first" usages) when applying the
exemption or replacement.
In `@GLOSSARY.md`:
- Line 164: Update the Poseidon glossary entry to avoid absolute "post-quantum
safe" claims: replace the sentence "**Poseidon**: Arithmetic-friendly hash
function for efficient ZK circuit evaluation. Post-quantum safe." with wording
that states there is no known practical quantum attack (e.g., "no known
practical quantum break (beyond generic Grover-style considerations)") while
keeping the rest of the description intact so the entry references "Poseidon"
and preserves its arithmetic-friendly and ZK circuit properties.
In `@patterns/pattern-tee-key-manager.md`:
- Line 120: Update the post-quantum exposure note that currently mentions "Intel
SGX DCAP / ECDSA quotes" to explicitly call out that attestation infrastructure
(the Intel/AMD signing keys referenced in pattern-tee-based-privacy.md) is also
vulnerable to CRQC and must be migrated alongside user signing keys; add a short
mitigation paragraph recommending coordinated PQ migration of vendor attestation
keys (or use of PQ-capable attestation, multi-root/measurement-based
attestation, or out-of-band validation) and reference both "Intel SGX DCAP /
ECDSA quotes" and the "Attestation rooted in Intel/AMD signing keys" phrase so
reviewers can find and update the same section.
In `@patterns/pattern-threshold-encrypted-mempool.md`:
- Line 99: The phrase "pairing-based threshold encryption (DKG)" inaccurately
conflates DKG with pairing assumptions; update the wording where "Post-quantum
exposure" and the sentence containing "pairing-based threshold encryption (DKG)"
to read something like "pairing-based threshold encryption schemes (and their
assumptions) are broken by CRQC" or equivalent, so it explicitly references
pairing-based schemes/assumptions rather than DKG itself; modify the sentence
that currently contains "pre-inclusion ciphertext has HNDL risk. Mitigation:
lattice-based threshold encryption." to match the new phrasing while preserving
the mitigation recommendation.
In `@patterns/pattern-zk-proof-systems.md`:
- Around line 53-54: Locate the table rows for "STARKs (FRI)" and "Hash-based
SNARKs" (the cells currently containing "Yes (hash-only)") and replace
"hash-only" with "hash-based" so each cell reads "Yes (hash-based)"; apply the
same replacement to any other table cells or occurrences in
patterns/pattern-zk-proof-systems.md to keep terminology consistent.
- Line 26: Replace the abbreviated term on first occurrence so the sentence
reads using the full term: change "A zero-knowledge proof (ZKP) is a
cryptographic protocol..." to explicitly use "zero-knowledge proof" on first
mention and keep the abbreviation in parentheses for later use (i.e.,
"zero-knowledge proof (ZKP)"); update the phrase containing "ZKP" in the
sentence that begins "A zero-knowledge proof (ZKP) is a cryptographic
protocol..." to follow the glossary convention.
- Line 84: Summary: The glossary term "Data Availability" must be capitalized in
the sentence about STARK proofs and EIP-4844 blobs. Fix: update the sentence
that currently reads "...and leverage EIP-4844 blobs for proof data
availability." to use the capitalized glossary term "Data Availability" (i.e.,
"...and leverage EIP-4844 blobs for proof Data Availability."), ensuring the
term matches the project's glossary conventions.
- Line 34: The sentence under "Hash-based proof systems" uses the word "only"
(the phrase: "rely only on collision-resistant hash functions") which the style
guide flags; update that sentence to remove "only" and rephrase to a neutral
factual tone—e.g., state that FRI-based STARKs and hash-based SNARKs (Plonky2/3)
rely on or are based on collision-resistant hash functions (Poseidon, Keccak,
Blake), and keep the note about the SNARK/STARK boundary and Plonky3 using FRI
commitments for SNARK-like succinctness intact.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: ba9dba4c-e8c2-4db8-87b8-163dc9ee9890
📒 Files selected for processing (26)
CHANGELOG.mdGLOSSARY.mddomains/README.mddomains/post-quantum.mdpatterns/pattern-co-snark.mdpatterns/pattern-l2-privacy-evaluation.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-mpc-custody.mdpatterns/pattern-native-account-abstraction.mdpatterns/pattern-noir-private-contracts.mdpatterns/pattern-origin-locked-confidential-ledger.mdpatterns/pattern-permissionless-spend-auth.mdpatterns/pattern-plasma-stateless-privacy.mdpatterns/pattern-pretrade-privacy-encryption.mdpatterns/pattern-private-set-intersection-dh.mdpatterns/pattern-private-shared-state-cosnark.mdpatterns/pattern-safe-proof-delegation.mdpatterns/pattern-shielding.mdpatterns/pattern-stealth-addresses.mdpatterns/pattern-tee-key-manager.mdpatterns/pattern-tee-zk-settlement.mdpatterns/pattern-threshold-encrypted-mempool.mdpatterns/pattern-voprf-nullifiers.mdpatterns/pattern-zk-kyc-ml-id-erc734-735.mdpatterns/pattern-zk-proof-systems.mdpatterns/pattern-zk-tls.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (2)
patterns/pattern-*.md
⚙️ CodeRabbit configuration file
patterns/pattern-*.md: This is a pattern card.Structure & frontmatter: Validate against the template at
patterns/_template.md.
File naming rules are inpatterns/README.md. Filename must start withpattern-in kebab-case.
Pattern names must be vendor-neutral (no vendor-specific names like aztec, nightfall, railgun, etc.).CROPS alignment (CRITICAL):
crops_profilewith all four fields (cr,os,privacy,security) is required — CI will reject patterns missing it.
Exception: meta/evaluation patterns that do not implement privacy directly may setcrops_profile: "n/a"— flag if this is used on a pattern that clearly does implement a privacy primitive.
Valid enum values are defined inCONTRIBUTING.md § CROPS Evaluationand enforced by the JSON schema atscripts/schemas/pattern.json.Your job is to review CROPS scores for plausibility, which CI cannot check:
- A pattern requiring a centralized operator should not claim
cr: high.- If the pattern involves I2U context, check that the CR score accounts for user escape paths per the CR rubric in CONTRIBUTING.md.
- A pattern using proprietary components should not claim
os: yes.- A pattern where the operator sees all user operations should not claim
privacy: full.Word limits: warn > 800, error > 1500.
Tone: factual and neutral per house style. No marketing language.
Files:
patterns/pattern-stealth-addresses.mdpatterns/pattern-noir-private-contracts.mdpatterns/pattern-zk-tls.mdpatterns/pattern-permissionless-spend-auth.mdpatterns/pattern-zk-proof-systems.mdpatterns/pattern-voprf-nullifiers.mdpatterns/pattern-l2-privacy-evaluation.mdpatterns/pattern-pretrade-privacy-encryption.mdpatterns/pattern-plasma-stateless-privacy.mdpatterns/pattern-threshold-encrypted-mempool.mdpatterns/pattern-safe-proof-delegation.mdpatterns/pattern-private-shared-state-cosnark.mdpatterns/pattern-zk-kyc-ml-id-erc734-735.mdpatterns/pattern-mpc-custody.mdpatterns/pattern-native-account-abstraction.mdpatterns/pattern-tee-zk-settlement.mdpatterns/pattern-origin-locked-confidential-ledger.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-tee-key-manager.mdpatterns/pattern-private-set-intersection-dh.mdpatterns/pattern-shielding.mdpatterns/pattern-co-snark.md
CHANGELOG.md
⚙️ CodeRabbit configuration file
CHANGELOG.md: Entries must go under[Unreleased], include a markdown link to the changed file,
reference the PR number(#NNN), and use a semantic prefix (feat(pattern):,feat(vendor):,fix:,docs:, etc.).
Files:
CHANGELOG.md
🧠 Learnings (3)
📓 Common learnings
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:21:53.725Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
📚 Learning: 2026-03-18T09:21:53.725Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:21:53.725Z
Learning: In the ethereum/iptf-map repository, pattern documentation should keep the Protocol section high-level and concise. Do not include granular implementation steps (e.g., explicit point-validation sub-steps). If such concerns must be mentioned, use lightweight callouts in a separate Security Notes or Caveats section. Apply this guideline to all pattern docs under the patterns directory.
Applied to files:
patterns/pattern-stealth-addresses.mdpatterns/pattern-noir-private-contracts.mdpatterns/pattern-zk-tls.mdpatterns/pattern-permissionless-spend-auth.mdpatterns/pattern-zk-proof-systems.mdpatterns/pattern-voprf-nullifiers.mdpatterns/pattern-l2-privacy-evaluation.mdpatterns/pattern-pretrade-privacy-encryption.mdpatterns/pattern-plasma-stateless-privacy.mdpatterns/pattern-threshold-encrypted-mempool.mdpatterns/pattern-safe-proof-delegation.mdpatterns/pattern-private-shared-state-cosnark.mdpatterns/pattern-zk-kyc-ml-id-erc734-735.mdpatterns/pattern-mpc-custody.mdpatterns/pattern-native-account-abstraction.mdpatterns/pattern-tee-zk-settlement.mdpatterns/pattern-origin-locked-confidential-ledger.mdpatterns/pattern-lean-ethereum.mdpatterns/pattern-tee-key-manager.mdpatterns/pattern-private-set-intersection-dh.mdpatterns/pattern-shielding.mdpatterns/pattern-co-snark.md
📚 Learning: 2026-03-18T09:21:53.725Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:21:53.725Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
Applied to files:
domains/post-quantum.mdCHANGELOG.md
🪛 GitHub Check: vale
patterns/pattern-zk-proof-systems.md
[warning] 26-26: [vale] patterns/pattern-zk-proof-systems.md#L26
[IPTF.Terminology] Use 'zero-knowledge proof' instead of 'ZKP' for consistency with GLOSSARY.md.
[warning] 34-34: [vale] patterns/pattern-zk-proof-systems.md#L34
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 53-53: [vale] patterns/pattern-zk-proof-systems.md#L53
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 54-54: [vale] patterns/pattern-zk-proof-systems.md#L54
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 84-84: [vale] patterns/pattern-zk-proof-systems.md#L84
[IPTF.Terminology] Use 'Data Availability' instead of 'data availability' for consistency with GLOSSARY.md.
domains/post-quantum.md
[warning] 25-25: [vale] domains/post-quantum.md#L25
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 29-29: [vale] domains/post-quantum.md#L29
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 37-37: [vale] domains/post-quantum.md#L37
[IPTF.Marketing] Avoid marketing language: 'first'. Use neutral, factual terms.
patterns/pattern-native-account-abstraction.md
[warning] 48-48: [vale] patterns/pattern-native-account-abstraction.md#L48
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 59-59: [vale] patterns/pattern-native-account-abstraction.md#L59
[IPTF.Marketing] Avoid marketing language: 'first'. Use neutral, factual terms.
🔇 Additional comments (27)
patterns/pattern-safe-proof-delegation.md (1)
62-62: Good PQ trade-off addition.Line 62 is clear, scoped, and appropriately linked to the domain-level guidance.
domains/README.md (1)
13-13: Domain index update looks correct.The new Post-Quantum Threats entry is correctly placed in the Domains list.
patterns/pattern-permissionless-spend-auth.md (1)
108-108: Relevant cross-link added.Line 108 improves discoverability for PQ migration context without adding noise.
patterns/pattern-noir-private-contracts.md (1)
109-109: PQ caveat placement is good here.The added note is concise, actionable, and correctly linked for deeper context.
patterns/pattern-plasma-stateless-privacy.md (1)
79-79: See-also update is appropriate.Line 79 adds the expected PQ cross-reference cleanly.
patterns/pattern-l2-privacy-evaluation.md (1)
201-201: Good linkage to PQ guidance.This See also addition is relevant to the framework’s existing PQ-security axis.
patterns/pattern-private-shared-state-cosnark.md (1)
63-63: PQ trade-off note is clear and appropriately scoped.The addition is concise, neutral, and correctly placed in Trade-offs with a direct mitigation path and cross-link.
patterns/pattern-lean-ethereum.md (1)
106-106: See-also cross-link is appropriate.The added reference improves navigation to domain-level PQ context without introducing extra complexity.
patterns/pattern-zk-tls.md (1)
49-49: Trade-off addition is consistent and well placed.This PQ exposure note is concise, non-promotional, and aligned with the linked domain guidance.
patterns/pattern-co-snark.md (1)
54-54: PQ risk note is clear and consistent with pattern scope.Good concise wording and correct linkage to the shared domain threat model.
patterns/pattern-tee-zk-settlement.md (1)
128-128: PQ exposure caveat is appropriately documented.The added line is concise, actionable, and keeps the card’s neutral tone.
patterns/pattern-voprf-nullifiers.md (1)
117-117: vOPRF PQ trade-off note is coherent and concise.This integrates cleanly with the pattern’s trust model and points to the central PQ reference.
patterns/pattern-stealth-addresses.md (1)
71-71: Stealth-address PQ caveat is well captured.Good risk framing and mitigation pointer, with consistent cross-linking to the domain page.
patterns/pattern-shielding.md (1)
59-59: Shielding PQ trade-off addition is solid.This is concise, technically aligned with the ZK-system guidance, and appropriately placed in Trade-offs.
patterns/pattern-mpc-custody.md (1)
61-61: LGTM: PQ exposure note is accurate and well-sourced.The claim that threshold ECDSA/EdDSA "is not HNDL-urgent — signatures are public" correctly interprets HNDL as targeting encrypted data, not public signatures. The mitigation path (ML-DSA / hash-based threshold) aligns with domains/post-quantum.md.
patterns/pattern-pretrade-privacy-encryption.md (1)
44-44: LGTM: Appropriate hedging and correct mitigation.The phrase "may rely on pairings" appropriately hedges against implementation variability. The mitigation (lattice-based threshold encryption) aligns with domains/post-quantum.md.
patterns/pattern-origin-locked-confidential-ledger.md (1)
67-67: LGTM: Accurate HNDL risk assessment.The "high" HNDL risk for on-chain encrypted balances is correctly assessed. ElGamal ciphertexts are immutably stored and capturable, matching the HNDL threat model. The mitigation path aligns with domains/post-quantum.md.
patterns/pattern-private-set-intersection-dh.md (1)
61-61: LGTM: Accurate DDH vulnerability assessment.The claim that DDH (commutative ECDH) is broken by CRQC is correct. The mitigation (lattice-based PSI) aligns with domains/post-quantum.md.
patterns/pattern-native-account-abstraction.md (2)
1-66: LGTM: Well-structured pattern document with appropriate CROPS profile.The document follows the template structure, maintains neutral tone, and provides accurate technical content. CROPS scores are plausible:
- CR
high: Regular mempool, no bundler centralization- OS
yes: Open EIP standard- Privacy
partial: Auth agility but no transaction graph privacy- Security
high: Protocol-level validationThe static analysis marketing warnings (line 48 "only", line 59 "first") are false positives — both terms are used as technical descriptors, not promotional language.
1-66: Technical details align with EIP-8141 draft (Jan 29, 2026).The pattern's description of the frame model, APPROVE opcode semantics, and validation flow are consistent with the current EIP-8141 specification. Since the EIP targets the Hegotia fork (H2 2026) and remains in draft, plan to review this pattern for updates if the specification changes before finalization.
patterns/pattern-zk-kyc-ml-id-erc734-735.md (1)
39-39: No issue found. The "131x gap" metric is properly sourced and documented in the repository's official domain documentation atdomains/post-quantum.mdline 52. The pattern file correctly references this source. The metric appears as an established comparison within the post-quantum threats table and is not an unsourced performance claim.patterns/pattern-zk-proof-systems.md (2)
1-22: LGTM! Frontmatter is well-formed and CROPS scores are plausible.The CROPS profile correctly reflects the pattern's nature as a decision framework (medium CR), open specification landscape (yes OS), full ZK guarantees (full privacy), and PQ-vulnerability of deployed systems (medium security with explicit justification at line 80).
46-56: LGTM! PQ verdicts align correctly with the authoritative threat landscape.The PQ-Safe column verdicts match the Post-Quantum Threats domain table: pairing-based and EC-based systems correctly marked as vulnerable, hash-based and lattice-based systems correctly marked as safe.
domains/post-quantum.md (4)
1-11: LGTM! Domain frontmatter and TLDR are concise and clear.The threat model introduction appropriately frames CRQC and HNDL urgency for the detailed analysis that follows.
39-65: LGTM! Application-layer breakage analysis provides clear, actionable migration paths.The tables effectively categorize PQ vulnerabilities by surface (anonymity vs confidentiality) and solution status. The HNDL urgency framing (line 41) correctly prioritizes confidentiality migrations.
67-92: LGTM! Comprehensive affected patterns matrix.The table provides clear PQ impact assessment across the pattern catalog. The separate callout of PQ-safe patterns (FHE, Merkle-based, hash-based ZK) is helpful for readers seeking immediate solutions.
93-101: LGTM! See also section provides balanced mix of internal patterns and authoritative external resources.The NIST PQC standards and ethresear.ch references are appropriate external sources for this domain document.
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
CHANGELOG.md (1)
14-14:⚠️ Potential issue | 🟡 MinorAdd the PR reference to the new Line 14 changelog entry.
This entry has the semantic prefix and file link, but it is missing the required PR reference.
Suggested patch
-- fix(domain): Restructured [Post-Quantum Threats](domains/post-quantum.md) threat landscape into four subsections (quantum algorithms, broken assumptions, weakened primitives, PQ-safe foundations) for clarity +- fix(domain): Restructured [Post-Quantum Threats](domains/post-quantum.md) threat landscape into four subsections (quantum algorithms, broken assumptions, weakened primitives, PQ-safe foundations) for clarity ([`#121`](https://github.com/ethereum/iptf-map/pull/121))As per coding guidelines: “Entries must go under
[Unreleased], include a markdown link to the changed file, reference the PR number(#NNN), and use a semantic prefix.”🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@CHANGELOG.md` at line 14, The changelog entry "fix(domain): Restructured [Post-Quantum Threats](domains/post-quantum.md) threat landscape into four subsections (quantum algorithms, broken assumptions, weakened primitives, PQ-safe foundations) for clarity" is missing the required PR reference; update that entry to append the PR number in the format "(`#NNN`)" (replace NNN with the actual PR) so the line reads with the semantic prefix, file link, and PR reference as required.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@domains/post-quantum.md`:
- Line 54: Replace the phrase "relies only on hash security" in the table cell
that mentions "Hash-based signatures | XMSS, SPHINCS+ (SLH-DSA)" with neutral
technical wording (e.g., "relies on hash-based security" or "depends on the
security properties of hash functions") so the entry no longer uses "only";
update the cell text for the Hash-based signatures row accordingly while keeping
XMSS and SPHINCS+ references intact.
- Line 33: Replace the shorthand phrase "ZK proof systems" with the repository's
required term "zero-knowledge proof systems" in the table row containing
"Pairing assumptions (Bilinear DH, q-Strong DH, SXDH) | via ECDLP | BLS
signatures, Groth16, PLONK/KZG commitments | Consensus (BLS), ZK proof
systems, blob commitments"; update the cell so it reads "Consensus (BLS),
zero-knowledge proof systems, blob commitments" to satisfy the terminology gate.
- Around line 93-113: Add a new row to the "Affected Patterns" table in
domains/post-quantum.md referencing patterns/pattern-zk-proof-systems.md; set
the PQ-Broken Primitive to "SNARKs (Groth16/PLONK)", HNDL Risk to "Medium" (or
"High" if you prefer stricter classification), and the Mitigation Path to "STARK
migration / hash-based commitments / hybrid proofs" so readers can find the
SNARK→STARK migration guidance under pattern-zk-proof-systems.md.
---
Duplicate comments:
In `@CHANGELOG.md`:
- Line 14: The changelog entry "fix(domain): Restructured [Post-Quantum
Threats](domains/post-quantum.md) threat landscape into four subsections
(quantum algorithms, broken assumptions, weakened primitives, PQ-safe
foundations) for clarity" is missing the required PR reference; update that
entry to append the PR number in the format "(`#NNN`)" (replace NNN with the
actual PR) so the line reads with the semantic prefix, file link, and PR
reference as required.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 8f386ff8-3950-4a2c-b499-cb2c7370cafe
📒 Files selected for processing (2)
CHANGELOG.mddomains/post-quantum.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (1)
CHANGELOG.md
⚙️ CodeRabbit configuration file
CHANGELOG.md: Entries must go under[Unreleased], include a markdown link to the changed file,
reference the PR number(#NNN), and use a semantic prefix (feat(pattern):,feat(vendor):,fix:,docs:, etc.).
Files:
CHANGELOG.md
🧠 Learnings (2)
📓 Common learnings
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:21:53.725Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
📚 Learning: 2026-03-18T09:21:53.725Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:21:53.725Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
Applied to files:
CHANGELOG.mddomains/post-quantum.md
🪛 GitHub Actions: CI Quality Gates
domains/post-quantum.md
[error] 33-33: Terminology inconsistency: "ZK proof" should be "zero-knowledge proof".
🪛 GitHub Check: vale
domains/post-quantum.md
[warning] 54-54: [vale] domains/post-quantum.md#L54
[IPTF.Marketing] Avoid marketing language: 'only'. Use neutral, factual terms.
[warning] 63-63: [vale] domains/post-quantum.md#L63
[IPTF.Marketing] Avoid marketing language: 'first'. Use neutral, factual terms.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@domains/post-quantum.md`:
- Line 90: The claim in the "Client-side GPU proving" sentence uses broad
numeric deltas; update the wording to explicitly limit these numbers to the
cited benchmark/test conditions (e.g., change the phrase to "in the cited
benchmark/test conditions" or "as measured in [pse.dev blog]" and add a
qualifier like "on that hardware and field size") so the 100+ Gops/s vs <1
Gops/s values are presented as benchmark-specific results rather than general
performance guarantees.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3d6e9c2b-6a3a-40a0-b90f-0983376de5e6
📒 Files selected for processing (1)
domains/post-quantum.md
📜 Review details
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:21:53.725Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
📚 Learning: 2026-03-18T09:21:53.725Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:21:53.725Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
Applied to files:
domains/post-quantum.md
📚 Learning: 2026-03-19T10:42:48.438Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:5-7
Timestamp: 2026-03-19T10:42:48.438Z
Learning: In the ethereum/iptf-map repository, the frontmatter fields `layer` (enum: L1, L2, offchain, hybrid), `privacy_goal` (string, maxLength 200), and `assumptions` (string or array of strings) are all explicitly defined as valid properties in `scripts/schemas/pattern.json`. Do not flag these as invalid or non-schema fields in pattern documents under the `patterns/` directory.
Applied to files:
domains/post-quantum.md
🪛 GitHub Check: vale
domains/post-quantum.md
[warning] 63-63: [vale] domains/post-quantum.md#L63
[IPTF.Marketing] Avoid marketing language: 'first'. Use neutral, factual terms.
🔇 Additional comments (2)
domains/post-quantum.md (2)
63-63: No action on “Hash/STARK-first stack”.This was already reviewed and intentionally kept as a valid technical compound adjective; no new change needed here.
69-70: The Go 1.24 claim is factually accurate; revise the suggested wording to preserve precision.Verification confirms that Go 1.24 does enable hybrid post-quantum TLS (X25519MLKEM768) by default for standard HTTPS/TLS connections (when
tls.Config.CurvePreferencesis nil, the default case). The original statement "Go 1.24 ships hybrid PQ TLS by default" is correct and well-sourced.However, the suggested rewrite introduces imprecision by removing "by default" and weakening "inherits" to "may inherit"—changes that obscure verified facts rather than addressing the valid concern about temporal drift.
For better future-proofing without sacrificing accuracy, qualify the version reference with a date or add source attribution:
♻️ Revised suggestion
-Ethereum inherits PQ transport encryption for some surfaces (Go 1.24 ships hybrid PQ TLS by default for HTTPS/JSON-RPC). What it _cannot_ inherit is application-layer privacy: on-chain ciphertexts, ECDH-based key derivation, stealth address generation, ZK-proven encryption, and access pattern hiding are blockchain-specific problems with no industry equivalent. +Ethereum inherits PQ transport encryption for some surfaces (Go 1.24 ships hybrid PQ TLS by default for HTTPS connections per the official release notes). What it _cannot_ inherit is application-layer privacy: on-chain ciphertexts, ECDH-based key derivation, stealth address generation, ZK-proven encryption, and access pattern hiding are blockchain-specific problems with no industry equivalent.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@domains/post-quantum.md`:
- Line 69: The statement claiming "Go 1.24 ships hybrid PQ TLS by default for
HTTPS/JSON-RPC" must be verified and sourced: check the Go 1.24 release notes
and crypto/tls package docs for the exact default behavior regarding hybrid
post-quantum TLS key exchange, then replace or amend the sentence "Go 1.24 ships
hybrid PQ TLS by default for HTTPS/JSON-RPC" with a precise, sourced claim (or
remove it) and add a citation to the official Go release notes/package
documentation showing whether hybrid PQ KEMs are enabled by default for TLS
clients/servers.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: acbc3d0a-cf4a-4ab0-a8a3-c8f458bbf530
📒 Files selected for processing (1)
domains/post-quantum.md
📜 Review details
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:21:53.725Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
📚 Learning: 2026-03-18T09:21:53.725Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 116
File: patterns/pattern-private-set-intersection-dh.md:38-40
Timestamp: 2026-03-18T09:21:53.725Z
Learning: In the ethereum/iptf-map repository, pattern documentation (e.g., patterns/pattern-private-set-intersection-dh.md) is intentionally kept high-level and concise. Avoid suggesting granular implementation-level steps (e.g., explicit point-validation sub-steps) inside the Protocol section of pattern docs; prefer lightweight callouts in a separate Security Notes or Caveats section if the concern must be mentioned at all.
Applied to files:
domains/post-quantum.md
📚 Learning: 2026-03-19T10:42:48.438Z
Learnt from: rymnc
Repo: ethereum/iptf-map PR: 120
File: patterns/pattern-private-set-intersection-circuit.md:5-7
Timestamp: 2026-03-19T10:42:48.438Z
Learning: In the ethereum/iptf-map repository, the frontmatter fields `layer` (enum: L1, L2, offchain, hybrid), `privacy_goal` (string, maxLength 200), and `assumptions` (string or array of strings) are all explicitly defined as valid properties in `scripts/schemas/pattern.json`. Do not flag these as invalid or non-schema fields in pattern documents under the `patterns/` directory.
Applied to files:
domains/post-quantum.md
🪛 GitHub Check: vale
domains/post-quantum.md
[warning] 63-63: [vale] domains/post-quantum.md#L63
[IPTF.Marketing] Avoid marketing language: 'first'. Use neutral, factual terms.
🔇 Additional comments (2)
domains/post-quantum.md (2)
63-63: No action: “Hash/STARK-first stack” was already reviewed and intentionally kept.This repeats a previously discussed style warning and appears intentionally accepted in prior review.
6-128: Strong structure and scope for a domain-level draft.The document is coherent, high-signal, and appropriately high-level for this repository. Cross-linking and migration framing are solid.
2 participants
Summary
Add post-quantum (PQ) threat documentation across the knowledge base:
New domain: Post-Quantum Threats‚ documents quantum computer attack surfaces (Shor, Grover), what breaks (ECDSA, BLS, ECDH, Groth16, PLONK/KZG), and the migration path for each Ethereum layer (consensus, execution, application). Includes HNDL urgency analysis, application-layer breakage tables for anonymity and confidentiality surfaces, and a full affected-patterns matrix.
New pattern: Native Account Abstraction, documents EIP-8141-style native AA as the execution-layer path to replaceable account validation logic, enabling PQ signature schemes to replace ECDSA without hard forks.
New pattern: ZK Proof Systems‚ comparative overview of ZK proving systems (Groth16, PLONK/KZG, PLONK/IPA, STARKs, Nova/folding) with PQ risk assessment, performance characteristics, and migration guidance.
Updated 20+ existing patterns‚ added PQ threat mentions or links to the domain page for all patterns identified as affected (stealth addresses, shielding, co-SNARK, MPC custody, TEE key manager, threshold encrypted mempool, etc.).
Glossary & changelog‚ added PQ-related terms (CRQC, HNDL, ML-KEM, ML-DSA, etc.) and updated CHANGELOG.md.
Test plan
npm run validatepasses (frontmatter, schemas)npm run check-termspasses (glossary consistency)npm run lint:valepasses (prose quality)Summary by CodeRabbit