# #37483 \[BC-Insight] There is a trace discrepancy for Nethermind when handling EOF from PUSH opcode **Submitted on Dec 5th 2024 at 23:46:14 UTC by @Omik for** [**Attackathon | Ethereum Protocol**](https://immunefi.com/audit-competition/ethereum-protocol-attackathon) * **Report ID:** #37483 * **Report Type:** Blockchain/DLT * **Report severity:** Insight * **Target:** * **Impacts:** * (Specifications) A bug in specifications with no direct impact on client implementations ## Description ## Brief/Intro Hey There, I was testing Nethermind, GETH, and EELS evms, using goevmlab and I found out that Nethermind treated push opcode EOF differently. ## Vulnerability Details Traces specification is introduced in the eip 3155 , and it will be emitted for every instruction in the lifetime of the transaction, for example, Push4 (0x63) meaning it is pushing the next 4 bytes to the stack, so 0x63deadbeef will push "deadbeef" to the stack, and it will emit the trace for this push4 instruction, this also means that during the execution of this transaction, push4 was executed. The Nethermind diverges its traces implementation when handling push opcode that has an eof shorter than it is supposed to be, taking from the example above, instead of pushing 4 bytes "deadbeef" to the stack, we will try to push 4 bytes of "deadbe", as you can see it only contains 3 bytes instead of 4, in Nethermind the execution will have one additional opcode that is getting executed after the push 4 instruction executed which is a push 0 opcode. However, in GETH and EELS, both of these EVMs will directly go to the stop instruction, without executing the push 0 opcode. ## Impact Details Although these discrepancies don't change the stateroot for now, this might make any off-chain actor diverge in consensus when handling traces of transaction execution. ## Additional information From testing this case, I also found out that Nethermind never emit the STOP instruction. ## Link to Proof of Concept ## Proof of Concept To reproduce the behavior: 1. clone the goevmlab repo 2. build the docker image, this is to prepare the binary for each evms. (I'm getting errors for building a lot of evms, that's why I only test the most common evm client which are GETH and Nethermind, and the eels to know the intended spec) 3. get the state test from this gist link 4. run the docker image 5. run these commands ``` ###/gethvm statetest --trace.format json --nomemory --noreturndata --trace /shared/push_test.json 2>/traces/push_test.geth.stderr.txt 1>/traces/push_test.geth.stdout.txt ###/ethereum-spec-evm statetest --json --nomemory --noreturndata /shared/push_test.json 2>/traces/push_test.eels.stderr.txt 1>/traces/push_test.eels.stdout.txt ###/neth/nethtest --memory --trace --input /shared/push_test.json 2>/traces/push_test.nethermind.stderr.txt 1>/traces/push_test.nethermind.stdout.txt ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://reports.immunefi.com/ethereum-protocol-or-attackathon/37483-bc-insight-there-is-a-trace-discrepancy-for-nethermind-when-handling-eof-from-push-opcode.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.