Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
syntrust wants to merge 4 commits into
base: goshard/base
Choose a base branch
from
Open

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

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
0df3dcd
qkc/testdata, qkc/config: add the pyquarkchain execution golden gener…
syntrust Aug 21, 2026
d4c9f97
qkc/testdata: pin the state, message and block level execution vectors
syntrust Aug 21, 2026
bba7731
add log
syntrust Aug 25, 2026
4b814d8
update case of create2
syntrust Sep 1, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions qkc/config/singularity/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -89,4 +89,48 @@ print('gas_limit ', block.header.evm_gas_limit, block.meta.evm_xshard_gas_limit
"
```

## Execution golden vectors

The execution layer is pinned the same way, but by a script rather than a one-liner:
[`qkc/testdata/gen_exec_golden.py`](../../testdata/gen_exec_golden.py) drives
pyquarkchain's own `EvmState` and `ShardState` and writes
`qkc/testdata/exec_golden/*.json`. It reads the two configs in this directory, so
the vectors are bound to the configs goshard ships rather than to whatever a
pyquarkchain checkout happens to carry.

Three granularities are emitted, each with its own file and its own consumer in
`qkc/core`:

| file | input | pinned output |
| --- | --- | --- |
| `state_level.json` | direct `EvmState` mutations | post state root, per-account reads |
| `message_level.json` | one signed transaction or one cross-shard deposit | post state root, receipts, gas counters, produced deposits, coinbase fees |
| `block_level.json` | whole minor blocks against a shard built from its genesis, with a root chain alongside | the seven values a block commits to, plus the deposits it consumed |

A block-level case carries the shard's genesis allocation, the serialized root
blocks it saw, the deposit lists its neighbours sent, and each block in order.
The allocation is the shard's `GENESIS.ALLOC`, so a consumer reaches the genesis
state root by applying it and nothing else — which is the same self-check the
genesis cases make, one level up.

Regenerate with:

```
# from the root of a pyquarkchain checkout, inside a virtualenv with its
# requirements installed:
python <path-to-goshard>/qkc/testdata/gen_exec_golden.py
```

The checkout is taken from `$PYQUARKCHAIN`, defaulting to the current directory.

Two things guard the result. The script's first two cases are the genesis
allocations themselves, and it fails unless their state roots match the pinned
values above — a mismatch elsewhere is then a real disagreement, not a case
description that never reached `EvmState`. And because that self-check says
nothing about execution — changing `messages.py` leaves the genesis root
untouched — every vector file records the oracle it came from: the pyquarkchain
commit and a digest of each module that decides execution. The script refuses to
run when one of those modules has uncommitted changes; `--allow-dirty` proceeds
and names the edited modules in the output instead.

Consumed by `qkc`, `qkc/config`, `qkc/types`, and `cmd/slave` tests.
Loading