# Erigon Engine API Simulator Test Results ## Suggested Fee Recipient Test ### Description Set the fee recipient to a custom address and verify that (a) balance is not increased when no fees are collected (b) balance is increased appropriately when fees are collected. Test sends around 20 tx which are expected to be included in the following GetPayload Engine command. ### Current Outcome Panic during transaction submitting after a couple of transactions are sent with eth_sendRawTransaction: `[EROR] [03-22|19:50:11.518] RPC method eth_sendRawTransaction crashed: discard reason: 11` `[service.go:217 panic.go:1038 pool.go:208 grpc_server.go:224 txpool_client.go:32 send_transaction.go:38 value.go:556 value.go:339 service.go:222 handler.go:484 handler.go:389 handler.go:343 handler.go:181 handler.go:271 asm_amd64.s:1581]` `[WARN] [03-22|19:50:11.518] Served conn=172.17.0.3:58776 method=eth_sendRawTransaction reqid=19 t=239.914µs err="method handler crashed"` Test continued and after all transactions were sent, engine_getPayloadV1 returned a payload without any transactions included: `{"jsonrpc":"2.0","id":3,"method":"engine_getPayloadV1","params":["0x0000000000000001"]}` `{"jsonrpc":"2.0","id":3,"result":{"parentHash":"0x67ead97eb79b47a1638659942384143f36ed44275d4182799875ab5a87324055","feeRecipient":"0x87ad3d32781bd0206308102c6ddb97c99892551d","stateRoot":"0x84308e7d0abf860412f4a0c6fc25709a6e9eaba20a0d085a0344d271f40109ec","receiptsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","prevRandao":"0x42b39bdd7feffa992292549a2a8d30d15bbec17ef79816db709af4d56ccd15e2","blockNumber":"0x1","gasLimit":"0x2fefd8","gasUsed":"0x0","timestamp":"0x1235","extraData":"0x","baseFeePerGas":"0x342770c0","blockHash":"0x851d022cef553cff37e890242cdfb752bce4b916b4011c304cb5b741f2ef1e16","transactions":[]}}` ## Bad Hash on NewPayload ### Description Send a NewPayload directive to the client including an incorrect BlockHash, should result in an error. Afterwards send a payload with a valid hash that attempts to build on top of the Bad-Hash payload. ### Current Outcome During the first part of the test, the payload with an invalid hash is correctly rejected: `{"jsonrpc":"2.0","id":1,"method":"engine_newPayloadV1","params":[{"parentHash":"0xd331c030ddb52a106816a41e95da09f3f4f043d833056e6c77247fb63c4ffcf7","feeRecipient":"0x0000000000000000000000000000000000000000","stateRoot":"0x84308e7d0abf860412f4a0c6fc25709a6e9eaba20a0d085a0344d271f40109ec","receiptsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","prevRandao":"0x159b3f331929803a2981ff9af04166958b327544fe844f78069e4f4be199f767","blockNumber":"0x6","gasLimit":"0x2fefd8","gasUsed":"0x0","timestamp":"0x123a","extraData":"0x","baseFeePerGas":"0x1ac012b7","blockHash":"0x73f95275eeaa2e769fe2afbfcd746406a8fc136bbf05f45bac5e3e188bb2cbb8","transactions":[]}]}` `{"jsonrpc":"2.0","id":1,"result":{"status":"INVALID_BLOCK_HASH"}}` During the second part of the test, where a new valid payload attempting to build on top of the invalid one is sent using engine_newPayloadV1, the client correctly returns `SYNCING`. However, every subsequent engine_newPayloadV1 also results in `SYNCING` status, even when the payload has the current canonical chain head as `parentHash`: #### Payload building on top of discarded invalid payload: `{"parentHash":"0x73f95275eeaa2e769fe2afbfcd746406a8fc136bbf05f45bac5e3e188bb2cbb8","feeRecipient":"0x0000000000000000000000000000000000000000","stateRoot":"0x84308e7d0abf860412f4a0c6fc25709a6e9eaba20a0d085a0344d271f40109ec","receiptsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","prevRandao":"0xe7740b13d582686d2096ee6657b20335e086150ef26cb964a155b830db6abffc","blockNumber":"0x7","gasLimit":"0x2fefd8","gasUsed":"0x0","timestamp":"0x123b","extraData":"0x","baseFeePerGas":"0x17681061","blockHash":"0xe5be34e5c1d0fe1f9b07e9e2bdf40fa7eeb786e05d3f89a4c64e0ccc5126dab9","transactions":[]}]}` `{"jsonrpc":"2.0","id":2,"result":{"status":"SYNCING"}}` `[Erigon 00 ⚫] [INFO] [03-22|20:06:30.612] [1/16 Headers] Handling new payload height=7 hash=0xe5be34e5c1d0fe1f9b07e9e2bdf40fa7eeb786e05d3f89a4c64e0ccc5126dab9` `[Erigon 00 ⚫] [INFO] [03-22|20:06:30.612] [1/16 Headers] Downloading PoS headers... height=6 hash=0x73f95275eeaa2e769fe2afbfcd746406a8fc136bbf05f45bac5e3e188bb2cbb8` #### Payload correctly building on top of correct canonical chain head: `{"parentHash":"0x73f95275eeaa2e769fe2afbfcd746406a8fc136bbf05f45bac5e3e188bb2cb47","feeRecipient":"0x0000000000000000000000000000000000000000","stateRoot":"0x84308e7d0abf860412f4a0c6fc25709a6e9eaba20a0d085a0344d271f40109ec","receiptsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","prevRandao":"0xe7740b13d582686d2096ee6657b20335e086150ef26cb964a155b830db6abffc","blockNumber":"0x7","gasLimit":"0x2fefd8","gasUsed":"0x0","timestamp":"0x123b","extraData":"0x","baseFeePerGas":"0x17681061","blockHash":"0xd3b97044ed91ecaaf37436ae7f1d4e118e0fbff9580c29262b030818df716c85","transactions":[]}]}` `[Erigon 00 ⚫] [INFO] [03-22|20:06:30.613] Received NewPayload height=0x7 hash=0xd3b97044ed91ecaaf37436ae7f1d4e118e0fbff9580c29262b030818df716c85` `[Erigon 00 ⚫] [INFO] [03-22|20:06:30.719] [NewPayload] stage loop is busy ` ## Latest Block after NewPayload ### Description Verify the Block returned by the Eth RPC after a new payload is executed. Eth RPC should still return previous block. ### Current Outcome After receiving a valid new payload with engine_newPayloadV1, client is expected to still return the previous block when `latest` is queried using the Eth RPC, until the client receives an engine_forkchoiceUpdatedV1 directive indicating that the payload is the new canonical chain head. However the client is currently switching to the new payload immediately: `{"jsonrpc":"2.0","id":34,"method":"engine_newPayloadV1","params":[{"parentHash":"0xd89fbb603f75ad4d8714710d09d041a9cb16b4d897dab5419745d83a32ae9838","feeRecipient":"0x0000000000000000000000000000000000000000","stateRoot":"0x84308e7d0abf860412f4a0c6fc25709a6e9eaba20a0d085a0344d271f40109ec","receiptsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","prevRandao":"0x5f65759ec32db4ea44452b0a11b005194facd5a3889c95de1d9cf06ed830d654","blockNumber":"0x6","gasLimit":"0x2fefd8","gasUsed":"0x0","timestamp":"0x123a","extraData":"0x","baseFeePerGas":"0x1ac012b7","blockHash":"0x12c4029f6b78ddd5d7dd849d9283851b08a6989b90a145a6a707ff3e729dd991","transactions":[]}]}` `[Erigon 00 ⚫] [INFO] [03-22|21:05:43.001] Received NewPayload height=0x6 hash=0x12c4029f6b78ddd5d7dd849d9283851b08a6989b90a145a6a707ff3e729dd991` `{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["latest",false]}` `{"jsonrpc":"2.0","id":1,"result":{"baseFeePerGas":"0x1ac012b7","difficulty":"0x0","extraData":"0x","gasLimit":"0x2fefd8","gasUsed":"0x0","hash":"0x12c4029f6b78ddd5d7dd849d9283851b08a6989b90a145a6a707ff3e729dd991","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","miner":"0x0000000000000000000000000000000000000000","mixHash":"0x5f65759ec32db4ea44452b0a11b005194facd5a3889c95de1d9cf06ed830d654","nonce":"0x0000000000000000","number":"0x6","parentHash":"0xd89fbb603f75ad4d8714710d09d041a9cb16b4d897dab5419745d83a32ae9838","receiptsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347","size":"0x1ff","stateRoot":"0x84308e7d0abf860412f4a0c6fc25709a6e9eaba20a0d085a0344d271f40109ec","timestamp":"0x123a","totalDifficulty":"0x30000","transactions":[],"transactionsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","uncles":[]}}`
Last changed by  
 
Mario Vega
691

Read more

Invalid Block Tests Validation

Perform the following steps: Run using invalid block and transaction tests using blockchain_test_engine Verify exception messages returned in the validation_error field of the engine_newPayloadVX response If a client returns any of the following three exceptions:Invalid Receipt Trie Hash Invalid State Root Hash Invalid Gas Used It is highly likely that there's a combination of the three fields which would result in the client accepting the invalid block.

4/14/2025
Leo Lara Techincal Interview

Could you walk us through your changes? Could you explain how these changes affect the clients and what changes do they have to do on their clients to process them? Could you explain why you chose to implement these format changes and what's the benefit of them over the previous format? What was your approach to understanding the repository/tests? Bonus (Maybe too specific?): What do you think are the advantages of producing tests per "process name" as compared to the full epoch and why do you think this approach was chosen in the first place? Is there anything you would do to improve the test generation?

4/2/2025
Consensus-specs Tester Take-Home Assignment

Hi ! As discussed in the interview, a next step in the recruitment process, we'd like to ask you to work on a take-home assignment. This assignment is based on the consensus-specs repository which would be the main focus of the position you are applying to: Build the consensus-specs and run tests. Write a new test based on any of the existing tests that you find interesting. Open a PR to the consensus-specs repo with the new test. Include in the PR some ideas of potential improvements to the repository and, specifically, improvements to the tests and/or tests framework.

2/21/2025
Untitled

[STEEL - February 2025] Prague Devnet-6 EELS and EEST integration Hiring EELS & EEST in the EIP Process EOF Testing - Prague Devnet-6 Specs and Testing On February 13th, EELS made their first release that follows the new versioning scheme to mark the specification of Prague's Devnet-6, which is the same finalized spec that will make it to Mainnet:

2/18/2025
Read more from Mario Vega
Published on HackMD