>100 subscribers

Understanding Ethereum Transaction Simulation — And Why It Matters

Understanding Ethereum Transaction Simulation — And Why It Matters

While internal transactions have real consequences to account balances, surprisingly the internal transactions themselves are not stored in on-chain. To see internal transactions, you have to run the transaction and trace the calls that it makes. While some contracts do log events to the chain that record internal activity, many do not because doing so requires additional gas.

So tracking the outcome of internal transactions often leaves users in the dark about when their address was involved. 

Before looking into the details of transaction simulation, let's first recap how Ethereum transactions operate:

• When new transactions are included in a block, they must be run on the Ethereum Virtual Machine (EVM).

• This is done to determine the impact of each transaction on the global state trie.

• For every Ethereum transaction address, the global state trie includes ETH balances, token balances, or any other information a contract chooses to store.

When a transaction calls a contract, the transaction execution on the EVM is determined by:

• The smart contract code: which does not change after the contract is deployed on-chain.

• The transaction parameters: which are unique to each transaction.

• The state trie: which is determined by all previous transactions since genesis and updated globally after each new block.

The global state trie update occurs when the entire block is accepted  — or 'hashed' by a miner. As the new block propagates through the network, each node independently executes the transactions in the block and updates its state trie appropriately. This process ensures that all nodes in the network at the same block height maintain an identical global state.

When miners create block templates, they specify the transaction order. The order of transactions in a block is typically determined by the gas price of each transaction. The higher the gas price, the earlier in the block the transaction should appear. The updated global state created by each new block, as well as the success of each transaction, is therefore determined by the previous block's global state and the exact ordering of each transaction within the new block. For more on gas prices and transaction complexity, read our ETH Gas 101 Guide.

With this high-level understanding of the inner workings of Ethereum internal transactions, we can now tackle the subject of simulating internal transactions. 

To simulate a single transaction, you must run the transaction on the EVM, executing all smart contract method calls with the specific transaction input parameters and a known state trie. The state can be represented by the current chain head – that is, the most recently agreed-upon state across the network.

Running a smart contract this way provides an accurate accounting of how the internal transaction will settle under current conditions. Since the transaction is run against a specific chain state, and the state may not be the same as when the transaction is actually confirmed, simulation is also referred to as 'speculative execution.'

To make the transaction simulation useful, the results of the speculative execution need to be traced so that it can be converted into a series of smart contract method calls and their associated parameters. Tracing involves traversing all of the executed op codes, looking for calls to other contract methods, and inspecting the calls to extract the parameters.

With the current node client implementations, this process can take substantially longer than the actual EVM execution. For traders, this time can often be the difference between acting on a trade and missing an opportunity.

Simulating new transactions entering the mempool is not without challenges, especially if the simulation is done using a single node client. These challenges include:

1. Ensuring your node remains properly synced at the time of simulation.

2. Capturing all pending transactions propagating through the mempool. Individual nodes frequently miss pending transactions, particularly during periods of network congestion.

3. Detecting new pending transactions as rapidly as possible.

4. Knowing which transactions are likely to be included in the next block – and thus are candidates to be simulated against the current block state.

5. Performing the simulation quickly to maximize the time the simulation results are actionable.

6. Interpreting the simulation to see how address balances are shifting.

7. And more. 

While transaction simulation is a powerful technique, simulating quickly and at scale is a challenge for even the most well-resourced teams. Keep this in mind as you consider incorporating real-time transaction simulation into your protocol operations and/or trading strategy. 

Ethereum is a public blockchain network where each participant has visibility into what has happened and what is about to happen. Except in the case of internal transactions. Sophisticated teams leverage the techniques detailed above to see into the future, while others are left in the dark. We at Blocknative are committed to leveling the playing field in all matters relating to the mempool – including these.

We have launched our Simulation Platform to make transaction simulation accessible to every Ethereum ecosystem participant. Our Ethereum Simulation Platform computes and summarizes the likely results of every marketable pending transaction against the current state of the chain – in real-time, at scale, and with low latency. You can go hands-on with Simulation Platform in Mempool Explorer today. 
Connect with us on Twitter @Blocknative or join our Discord Community to be the first to know when we publish new research and announce new functionality.

While internal transactions have real consequences to account balances, surprisingly the internal transactions themselves are not stored in on-chain. To see internal transactions, you have to run the transaction and trace the calls that it makes. While some contracts do log events to the chain that record internal activity, many do not because doing so requires additional gas.

So tracking the outcome of internal transactions often leaves users in the dark about when their address was involved. 

Before looking into the details of transaction simulation, let's first recap how Ethereum transactions operate:

• When new transactions are included in a block, they must be run on the Ethereum Virtual Machine (EVM).

• This is done to determine the impact of each transaction on the global state trie.

• For every Ethereum transaction address, the global state trie includes ETH balances, token balances, or any other information a contract chooses to store.

When a transaction calls a contract, the transaction execution on the EVM is determined by:

• The smart contract code: which does not change after the contract is deployed on-chain.

• The transaction parameters: which are unique to each transaction.

• The state trie: which is determined by all previous transactions since genesis and updated globally after each new block.

The global state trie update occurs when the entire block is accepted  — or 'hashed' by a miner. As the new block propagates through the network, each node independently executes the transactions in the block and updates its state trie appropriately. This process ensures that all nodes in the network at the same block height maintain an identical global state.

When miners create block templates, they specify the transaction order. The order of transactions in a block is typically determined by the gas price of each transaction. The higher the gas price, the earlier in the block the transaction should appear. The updated global state created by each new block, as well as the success of each transaction, is therefore determined by the previous block's global state and the exact ordering of each transaction within the new block. For more on gas prices and transaction complexity, read our ETH Gas 101 Guide.

With this high-level understanding of the inner workings of Ethereum internal transactions, we can now tackle the subject of simulating internal transactions. 

To simulate a single transaction, you must run the transaction on the EVM, executing all smart contract method calls with the specific transaction input parameters and a known state trie. The state can be represented by the current chain head – that is, the most recently agreed-upon state across the network.

Running a smart contract this way provides an accurate accounting of how the internal transaction will settle under current conditions. Since the transaction is run against a specific chain state, and the state may not be the same as when the transaction is actually confirmed, simulation is also referred to as 'speculative execution.'

To make the transaction simulation useful, the results of the speculative execution need to be traced so that it can be converted into a series of smart contract method calls and their associated parameters. Tracing involves traversing all of the executed op codes, looking for calls to other contract methods, and inspecting the calls to extract the parameters.

With the current node client implementations, this process can take substantially longer than the actual EVM execution. For traders, this time can often be the difference between acting on a trade and missing an opportunity.

Simulating new transactions entering the mempool is not without challenges, especially if the simulation is done using a single node client. These challenges include:

1. Ensuring your node remains properly synced at the time of simulation.

2. Capturing all pending transactions propagating through the mempool. Individual nodes frequently miss pending transactions, particularly during periods of network congestion.

3. Detecting new pending transactions as rapidly as possible.

4. Knowing which transactions are likely to be included in the next block – and thus are candidates to be simulated against the current block state.

5. Performing the simulation quickly to maximize the time the simulation results are actionable.

6. Interpreting the simulation to see how address balances are shifting.

7. And more. 

While transaction simulation is a powerful technique, simulating quickly and at scale is a challenge for even the most well-resourced teams. Keep this in mind as you consider incorporating real-time transaction simulation into your protocol operations and/or trading strategy. 

Ethereum is a public blockchain network where each participant has visibility into what has happened and what is about to happen. Except in the case of internal transactions. Sophisticated teams leverage the techniques detailed above to see into the future, while others are left in the dark. We at Blocknative are committed to leveling the playing field in all matters relating to the mempool – including these.

We have launched our Simulation Platform to make transaction simulation accessible to every Ethereum ecosystem participant. Our Ethereum Simulation Platform computes and summarizes the likely results of every marketable pending transaction against the current state of the chain – in real-time, at scale, and with low latency. You can go hands-on with Simulation Platform in Mempool Explorer today. 
Connect with us on Twitter @Blocknative or join our Discord Community to be the first to know when we publish new research and announce new functionality.