feat(zkevm): add engine-witness simulator and add executionWitnessMutated flag into fixtures#2872
Conversation
Adds `consume engine-witness`, a Hive simulator that drives Amsterdam blockchain-engine fixtures through a witness-emitting endpoint and diffs the client-generated `ExecutionWitness` against the fixture's expected witness (set-equality on state/codes/headers). Supports two transports: - Default: JSON-RPC `engine_newPayloadWithWitnessVX` with RLP witness (geth PR #30069, already implemented in go-ethereum and forks). - `--ssz`: REST `POST /new-payload-with-witness` with SSZ witness (execution-apis PR ethereum#773, implemented on Ethrex `feat/zkengine-http`). Both paths converge on a shared `NewPayloadWithWitnessResponse` dataclass and the same assertion helper. Clients that do not implement the chosen transport skip cleanly (HTTP 404/405 for REST, `-32601 Method not found` for JSON-RPC).
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## projects/zkevm #2872 +/- ##
==================================================
+ Coverage 85.72% 88.24% +2.51%
==================================================
Files 612 591 -21
Lines 37853 36832 -1021
Branches 3932 3675 -257
==================================================
+ Hits 32451 32501 +50
+ Misses 4652 3685 -967
+ Partials 750 646 -104
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
|
|
@Dyslex7c, the is this what are you refering to? |
|
@Dyslex7c, I think tehre is a missing folder in your path. |
right that fixed it, thanks |

🗒️ Description
This PR:
uv run consume engine-witnesssimulator to allow running execution witness fixtures in Hive. This is based on feat(test-consume): add engine-witness simulator for witness verification #2724 with a couple of extra fixes needed to finish it.executionWitnessMutatedboolean flag to fixtures (more about this below).Regarding the last point: the existing
executionWitnessin fixtures signals the expected execution witness that a stateful-EL should create for the given fixture. This is similar to an "expected BAL" for the block.But there is a catch: the execution witness isn't part of the execution payload for stateful-ELs; the execution witness is only used as input for the stateless validator.
We have many tests that mutate the correct execution witness for a block, so that we can check that the stateless validator fails when executing the block.
This means that:
This means that fixtures that perform execution-witness mutation shouldn't be run with
uv run consume engine-witness, which targets only stateful-ELs, not stateless validator runs.The way to handle this now is that I added an
executionWitnessMutatedfield in the fixtures, so this can be noted. If it istrue, thenuv run consume engine-witnesswill skip them since those fixtures aren't really a target to test stateful-EL correctness in constructing an execution witness.I've the feeling this situation is just adding a bit more to the tension of using
blockchain_testsas a format. We have been pushing back a bit on a new fixture format to avoid complexity in the testing framework and the need for multiple ELs to support it. But at some point after some things settle, we can reconsider if maybe it is a good strategy. e.g. keepblockchain_testsfor things that only make sense for stateful-ELs, and create a separate format for stateless runs, which would indirectly avoid needing this flag plus avoiding some current bloating of redundant data (in different encoding formats) inblockchain_tests. Created #2873 for tracking discussion.🔗 Related Issues or PRs
N/A.
✅ Checklist
just statictype(scope):.mkdocs servelocally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.@ported_frommarker.Cute Animal Picture