Skip to content

exec(s0): pin execution golden vectors from pyquarkchain - #53

Open
syntrust wants to merge 4 commits into
goshard/basefrom
exec-s0
Open

exec(s0): pin execution golden vectors from pyquarkchain#53
syntrust wants to merge 4 commits into
goshard/basefrom
exec-s0

Conversation

@syntrust

@syntrust syntrust commented Aug 21, 2026

Copy link
Copy Markdown

What

Adds the reference vectors the QuarkChain execution layer will be written against, generated from pyquarkchain itself.

  • Three granularities, each in its own file: direct state mutations (17 cases), a single transaction or cross-shard deposit (41 cases), and whole minor blocks run against a shard built from its own genesis with a root chain alongside (11 cases).
  • Message-level cases pin the post state root, receipts, gas counters, produced cross-shard deposits and coinbase fees, and a case that pins a rejection also names the pyquarkchain exception the rejection must be attributed to.
  • Block-level cases pin the seven values a minor block commits to and the cross-shard deposits it consumed.
  • The generator reads the singularity configs this repo ships, so the vectors are bound to our own artifacts rather than to whatever a pyquarkchain checkout happens to carry.
  • Every vector file records the oracle it came from, the pyquarkchain commit and a digest of each module that decides execution, and generation refuses to run against a modified oracle.
  • No Go code changes.

Test

Nothing in the tree reads the vectors yet, so this PR changes no behavior. The vectors are verified by regenerating them.

  • The generator calibrates itself with the two networks' genesis allocations to reproduce the state roots already pinned in qkc/testdata/minor_genesis_golden.json.
  • Reproduced against pyquarkchain commit bf860bf on a clean checkout, and all three files came back byte-identical.
  • To repeat that, follow the "Execution golden vectors" section of qkc/config/singularity/README.md: build a virtualenv from that checkout's requirements, run python <path-to-goshard>/qkc/testdata/gen_exec_golden.py from the checkout root, and confirm git diff is empty.

syntrust and others added 2 commits August 21, 2026 17:08
…ator

gen_exec_golden.py drives pyquarkchain's own EvmState and ShardState and
exports what the Go execution layer has to reproduce, at three granularities:
direct state mutations, one transaction or one cross-shard deposit, and a
whole minor block on a shard built from its own genesis with a root chain
alongside. A block-level case carries the shard's GENESIS.ALLOC, the
serialized root blocks the shard saw, the deposit lists its neighbours sent,
and each block in order.

The generator reads the singularity configs this repo ships rather than a
pyquarkchain checkout's, so the vectors are bound to our own artifacts. Its
first two cases are the two networks' genesis allocations and it refuses to
write anything unless they reproduce the roots already pinned in
minor_genesis_golden.json -- without that calibration a mismatch cannot be
told apart from a case description that never reached EvmState. The same
trick works one level up: a block-level allocation is injected as the shard's
own, so a consumer that applies it and nothing else must land on the genesis
state root.

That calibration says nothing about execution, though -- changing messages.py
leaves the genesis root untouched. So every output file also records the
oracle it came from: the pyquarkchain commit and a digest of each module that
decides execution, with a refusal to run when one of those modules has
uncommitted changes.

Two things stood between the script and a clean pyquarkchain checkout, and
both are handled from the outside so no oracle module is patched.
cluster_config resolves the local hostname at import time, which raises on a
machine whose hostname does not resolve, so gethostbyname is pinned to
loopback before that import. And add_block publishes subscription
notifications through asyncio.create_task, so main() runs inside asyncio.run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The three files gen_exec_golden.py writes, generated against pyquarkchain
master 75f8d7e1 with no oracle module modified:

- state_level.json, 17 cases: direct EvmState mutations, pinning the post
  state root and per-account reads. The first two are the generator's own
  calibration against minor_genesis_golden.json.
- message_level.json, 41 cases: one signed transaction or one cross-shard
  deposit through apply_transaction / apply_xshard_deposit, pinning the post
  root, receipts, gas counters, produced deposits and coinbase fees. Each
  case declares whether it pins a successful execution or a rejection, and
  a rejection names the pyquarkchain exception it must be attributed to.
- block_level.json, 11 cases: whole minor blocks through
  ShardState.run_block, pinning the seven values a block commits to and the
  cross-shard deposits it consumed.

Nothing in the tree reads these yet. They are the reference the Go execution
layer is written against, and its consumers arrive with it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@syntrust
syntrust marked this pull request as ready for review September 1, 2026 02:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant