docs: spec for SnapchainConfigRegistry schema and TOML rendering - #489
Merged
Merged
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a normative specification document for the SnapchainConfigRegistry contract’s on-chain schema and its exact TOML rendering contract with consumers (including pagination, validation rules, and TOML-injection considerations), so clients can safely fetch/merge config via eth_call.
Changes:
- Documented the
ValidatorSetdata model and the semantics ofeffectiveAt, key encoding, and ordering. - Specified the exact TOML output grammar/format and pagination composition properties.
- Documented validation responsibilities (on-chain vs operator), peer-string allowlist, and operational/deployment considerations.
Suppressed comments (1)
docs/snapchain-config-registry.md:255
- This references "C4" again, but C4 is not defined anywhere in the document. Remove the label or add a definition so readers can trace the referenced invariant.
a `"`. The invariant C4 asserts as a property test is therefore exact: the number of `"` characters
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
topocount
force-pushed
the
kjs/neyn-13018-c1-snapchain-config-registry-spec
branch
4 times, most recently
from
August 4, 2026 22:13
c0edbbf to
2f477e9
Compare
Pins the byte-level agreement between the registry contract and its consumers before either side is written: struct shape, integer and hex formatting, block separators, the peer-string allowlist, the validation split between contract and operator, and the gas growth curve. Two decisions carry most of the weight: - Public keys are stored as bytes32, so a validator-set entry can only render through a fixed hex alphabet and cannot break out of its TOML string literal. That leaves the two peer strings as the only injection surface, which a strict character allowlist closes. - Each validator-set block carries its own trailing blank line rather than sitting between separators, which is what makes the paginated getter compose exactly with the canonical one.
`forge fmt` output is not stable across foundry releases, and CI installs `stable`, so the formatter drifts underneath `forge fmt --check` without anyone changing a line of Solidity. That has already happened. This tree was formatted with v1.2.3, stable as of the last commit to main on 2025-06-17. Current stable wraps multi-parameter function headers differently and wants to reflow 63 otherwise-untouched files, so `forge fmt --check` fails on a clean checkout of main -- CI is red before any change is applied. Pinning is the smaller fix. The alternative is a repo-wide reformat that touches most of src/, script/ and test/, conflicts with every open PR, and buys nothing but agreement with whichever formatter happens to be current. None of the six `multiline_func_header` settings reproduces the existing style, so there is no configuration that avoids the churn. Verified: v1.2.3 formats main with zero diffs, and builds and tests this tree identically to current stable. Bump this deliberately, in a commit that also runs the repo-wide `forge fmt`, rather than letting it drift.
The pinned v3 cannot run on current runners at all: docker/bake-action < v5 is not compatible with buildx >= 0.20.0, please update your workflow to latest docker/bake-action or use an older buildx version. So the build-image job fails before it builds anything, independently of what is in the tree. `files` is required from v6 on, and names the compose file bake was already reading by default.
topocount
force-pushed
the
kjs/neyn-13018-c1-snapchain-config-registry-spec
branch
from
August 5, 2026 20:55
2f477e9 to
1c210bd
Compare
|
Coverage after merging kjs/neyn-13018-c1-snapchain-config-registry-spec into main will be
Coverage Report
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Describe why this issue should be fixed and link to any relevant design docs, issues or other relevant items.
Change Summary
Describe the changes being made in 1-2 concise sentences.
Merge Checklist
Choose all relevant options below by adding an
xnow or at any time before submitting for reviewAdditional Context
If this is a relatively large or complex change, provide more details here that will help reviewers.
Stack created with GitHub Stacks CLI • Give Feedback 💬
PR-Codex overview
This PR focuses on updating the
ci.ymlworkflow to pin thefoundryversion for consistent formatting and enhancing the documentation forSnapchainConfigRegistryto clarify its schema and operational details.Detailed summary
foundryversion fromstabletov1.2.3in.github/workflows/ci.yml.docker/bake-actionversion fromv3tov7and addedfiles: docker-compose.yml.SnapchainConfigRegistrydetailing its schema, data model, and operational guidelines.