Execution Context for the Ethereum EVM Implementation. |
---|
This package provides an Ethereum mainnet
compatible execution context for the
@ethereumjs/evm
EVM implementation.
So beyond bytecode processing this package allows to run or build new Ethereum blocks or single transactions and update a blockchain state accordingly.
Note that up till v5
this package also was the bundled package for the EVM implementation itself.
To obtain the latest version, simply require the project using npm
:
npm install @ethereumjs/vm
Note: Starting with the Dencun hardfork EIP-4844
related functionality will become an integrated part of the EVM functionality with the activation of the point evaluation precompile. It is therefore strongly recommended to always run the EVM with a KZG library installed and initialized, see KZG Setup for instructions.
// ./examples/runTx.ts
import { Common, Hardfork, Mainnet } from '@ethereumjs/common'
import { createLegacyTx } from '@ethereumjs/tx'
import { createZeroAddress } from '@ethereumjs/util'
import { createVM, runTx } from '@ethereumjs/vm'
const main = async () => {
const common = new Common({ chain: Mainnet, hardfork: Hardfork.Shanghai })
const vm = await createVM({ common })
const tx = createLegacyTx({
gasLimit: BigInt(21000),
gasPrice: BigInt(1000000000),
value: BigInt(1),
to: createZeroAddress(),
v: BigInt(37),
r: BigInt('62886504200765677832366398998081608852310526822767264927793100349258111544447'),
s: BigInt('21948396863567062449199529794141973192314514851405455194940751428901681436138'),
})
const res = await runTx(vm, { tx, skipBalance: true })
console.log(res.totalGasSpent) // 21000n - gas cost for simple ETH transfer
}
void main()
Additionally to the VM.runTx()
method there is an API method VM.runBlock()
which allows to run the whole block and execute all included transactions along.
Note: with the switch from v7 to v8 the old direct new VM()
constructor usage has been fully deprecated and a VM
can now solely be instantiated with the async static VM.create()
constructor. This also goes for the underlying EVM
if you use a custom EVM
.
The VM package can also be used to construct a new valid block by executing and then integrating txs one-by-one.
The following non-complete example gives some illustration on how to use the Block Builder API:
// ./examples/buildBlock.ts
import { createBlock } from '@ethereumjs/block'
import { Common, Mainnet } from '@ethereumjs/common'
import { createLegacyTx } from '@ethereumjs/tx'
import { Account, bytesToHex, createAddressFromPrivateKey, hexToBytes } from '@ethereumjs/util'
import { buildBlock, createVM } from '@ethereumjs/vm'
const main = async () => {
const common = new Common({ chain: Mainnet })
const vm = await createVM({ common })
const parentBlock = createBlock(
{ header: { number: 1n } },
{ skipConsensusFormatValidation: true },
)
const headerData = {
number: 2n,
}
const blockBuilder = await buildBlock(vm, {
parentBlock, // the parent @ethereumjs/block Block
headerData, // header values for the new block
blockOpts: {
calcDifficultyFromHeader: parentBlock.header,
freeze: false,
skipConsensusFormatValidation: true,
putBlockIntoBlockchain: false,
},
})
const pk = hexToBytes('0x26f81cbcffd3d23eace0bb4eac5274bb2f576d310ee85318b5428bf9a71fc89a')
const address = createAddressFromPrivateKey(pk)
const account = new Account(0n, 0xfffffffffn)
await vm.stateManager.putAccount(address, account) // create a sending account and give it a big balance
const tx = createLegacyTx({ gasLimit: 0xffffff, gasPrice: 75n }).sign(pk)
await blockBuilder.addTransaction(tx)
// Add more transactions
const block = await blockBuilder.build()
console.log(`Built a block with hash ${bytesToHex(block.hash())}`)
}
void main()
This library by default uses JavaScript implementations for the basic standard crypto primitives like hashing or signature verification (for included txs). See @ethereumjs/common
README for instructions on how to replace with e.g. a more performant WASM implementation by using a shared common
instance.
This projects contain the following examples:
- ./examples/run-blockchain: Loads tests data, including accounts and blocks, and runs all of them in the VM.
- ./examples/run-solidity-contract: Compiles a Solidity contract, and calls constant and non-constant functions.
All of the examples have their own README.md
explaining how to run them.
With the breaking release round in Summer 2023 we have added hybrid ESM/CJS builds for all our libraries (see section below) and have eliminated many of the caveats which had previously prevented a frictionless browser usage.
It is now easily possible to run a browser build of one of the EthereumJS libraries within a modern browser using the provided ESM build. For a setup example see ./examples/browser.html.
For documentation on VM
instantiation, exposed API and emitted events
see generated API docs.
With the breaking releases from Summer 2023 we have started to ship our libraries with both CommonJS (cjs
folder) and ESM builds (esm
folder), see package.json
for the detailed setup.
If you use an ES6-style import
in your code files from the ESM build will be used:
import { EthereumJSClass } from '@ethereumjs/[PACKAGE_NAME]'
If you use Node.js specific require
, the CJS build will be used:
const { EthereumJSClass } = require('@ethereumjs/[PACKAGE_NAME]')
Using ESM will give you additional advantages over CJS beyond browser usage like static code analysis / Tree Shaking which CJS can not provide.
With the breaking releases from Summer 2023 we have removed all Node.js specific Buffer
usages from our libraries and replace these with Uint8Array representations, which are available both in Node.js and the browser (Buffer
is a subclass of Uint8Array
).
We have converted existing Buffer conversion methods to Uint8Array conversion methods in the @ethereumjs/util bytes
module, see the respective README section for guidance.
Starting with v6 the usage of BN.js for big numbers has been removed from the library and replaced with the usage of the native JS BigInt data type (introduced in ES2020
).
Please note that number-related API signatures have changed along with this version update and the minimal build target has been updated to ES2020
.
Starting with the VM
v6 version the inner Ethereum Virtual Machine core previously included in this library has been extracted to an own package @ethereumjs/evm.
It is still possible to access all EVM
functionality through the evm
property of the initialized vm
object, e.g.:
vm.evm.runCode()
vm.evm.events.on('step', function (data) {
console.log(`Opcode: ${data.opcode.name}\tStack: ${data.stack}`)
})
Note that it's now also possible to pass in an own or customized EVM
instance by using the optional evm
constructor option.
With VM
v7 a previously needed EEI interface for EVM/VM communication is not needed any more and the API has been simplified, also see the respective EVM README section. Most of the EEI related logic is now either handled internally or more generic functionality being taken over by the @ethereumjs/statemanager
package, with the EVM
now taking in both an (optional) stateManager
and blockchain
argument for the constructor (which the VM
passes over by default).
With VM
v6 the previously included StateManager
has been extracted to its own package @ethereumjs/statemanager. The StateManager
package provides a unified state interface and it is now also possible to provide a modified or custom StateManager
to the VM via the optional stateManager
constructor option.
Starting with v5.1.0
the VM supports running both Ethash/PoW
and Clique/PoA
blocks and transactions. Clique support has been added along the work on PR #1032 and follow-up PRs and (block) validation checks and the switch of the execution context now happens correctly.
@ethereumjs/blockchain
validates the PoW algorithm with @ethereumjs/ethash
and validates blocks' difficulty to match their canonical difficulty.
The following is a simple example for a block run on Goerli
:
// ./examples/runGoerliBlock.ts
import { createBlockFromRPC } from '@ethereumjs/block'
import { Common, Goerli } from '@ethereumjs/common'
import { bytesToHex } from '@ethereumjs/util'
import { createVM, runBlock } from '../src/index.js'
import goerliBlock2 from './testData/goerliBlock2.json'
const main = async () => {
const common = new Common({ chain: Goerli, hardfork: 'london' })
const vm = await createVM({ common, setHardfork: true })
const block = createBlockFromRPC(goerliBlock2, undefined, { common })
const result = await runBlock(vm, { block, generate: true, skipHeaderValidation: true }) // we skip header validation since we are running a block without the full Ethereum history available
console.log(`The state root for Goerli block 2 is ${bytesToHex(result.stateRoot)}`)
}
void main()
For hardfork support see the Hardfork Support section from the underlying @ethereumjs/evm
instance.
An explicit HF in the VM
- which is then passed on to the inner EVM
- can be set with:
// ./examples/runTx.ts#L1-L8
import { Common, Hardfork, Mainnet } from '@ethereumjs/common'
import { createLegacyTx } from '@ethereumjs/tx'
import { createZeroAddress } from '@ethereumjs/util'
import { createVM, runTx } from '@ethereumjs/vm'
const main = async () => {
const common = new Common({ chain: Mainnet, hardfork: Hardfork.Shanghai })
const vm = await createVM({ common })
Genesis state was huge and had previously been bundled with the Blockchain
package with the burden going over to the VM, since Blockchain
is a dependency.
Starting with the v7 release genesis state has been removed from blockchain
and moved into its own auxiliary package @ethereumjs/genesis, from which it can be included if needed (for most - especially VM - use cases it is not necessary), see PR #2844.
For initializing a custom genesis state you can use the genesisState
constructor option in the Blockchain
and VM
library in a similar way this had been done in the Common
library before.
// ./examples/vmWithGenesisState.ts
import { Chain } from '@ethereumjs/common'
import { getGenesis } from '@ethereumjs/genesis'
import { createAddressFromString } from '@ethereumjs/util'
import { createVM } from '@ethereumjs/vm'
const main = async () => {
const genesisState = getGenesis(Chain.Mainnet)
const vm = await createVM()
await vm.stateManager.generateCanonicalGenesis!(genesisState)
const account = await vm.stateManager.getAccount(
createAddressFromString('0x000d836201318ec6899a67540690382780743280'),
)
if (account === undefined) {
throw new Error('Account does not exist: failed to import genesis state')
}
console.log(
`This balance for account 0x000d836201318ec6899a67540690382780743280 in this chain's genesis state is ${Number(
account?.balance,
)}`,
)
}
void main()
Genesis state can be configured to contain both EOAs as well as (system) contracts with initial storage values set.
For the v6 release responsibility for setting up a custom genesis state moved from the Common library to the Blockchain
package, see PR #1924 for some work context.
A genesis state can be set along Blockchain
creation by passing in a custom genesisBlock
and genesisState
. For mainnet
and the official test networks like sepolia
or goerli
genesis is already provided with the block data coming from @ethereumjs/common
. The genesis state is being integrated in the Blockchain
library (see genesisStates
folder).
It is possible to individually activate EIP support in the VM by instantiate the Common
instance passed
with the respective EIPs, e.g.:
// ./examples/vmWithEIPs.ts
import { Common, Mainnet } from '@ethereumjs/common'
import { createVM } from '@ethereumjs/vm'
const main = async () => {
const common = new Common({ chain: Mainnet, eips: [7702] })
const vm = await createVM({ common })
console.log(`EIP 7702 is active in the VM - ${vm.common.isActivatedEIP(7702)}`)
}
void main()
For a list with supported EIPs see the @ethereumjs/evm documentation.
This library supports the blob transaction type introduced with EIP-4844.
This library support the execution of EIP-7702 EOA code transactions (see tx library for full documentation) with runTx()
or the wrapping runBlock()
execution methods starting with v3.1.0
, see this test setup for a more complete example setup on how to run code from an EOA.
Note: Things move fast with EIP-7702
and the currently released implementation is based on this commit and therefore already outdated. An up-to-date version will be released along our breaking release round planned for early September 2024.
This library supports blocks including the following EIP-7685 requests:
- EIP-6110 - Deposit Requests (
v7.3.0
+) - EIP-7002 - Withdrawal Requests (
v7.3.0
+) - EIP-7251 - Consolidation Requests (
v7.3.0
+)
Starting with v8.1.0
the VM supports EIP-2935 which stores the latest 8192 block hashes in the storage of a system contract, see PR #3475 as the major integration PR (while work on this has already been done in previous PRs).
This EIP will be activated along the Prague hardfork. Note that this EIP has no effect on the resolution of the BLOCKHASH
opcode, which will be a separate activation taking place by the integration of EIP-7709 in the following Osaka hardfork.
To run VM/EVM related EIP-4844 functionality you have to activate the EIP in the associated @ethereumjs/common
library:
// ./examples/vmWith4844.ts
import { Common, Hardfork, Mainnet } from '@ethereumjs/common'
import { createVM } from '../src/index.js'
const main = async () => {
const common = new Common({ chain: Mainnet, hardfork: Hardfork.Shanghai, eips: [4844] })
const vm = await createVM({ common })
console.log(`4844 is active in the VM - ${vm.common.isActivatedEIP(4844)}`)
}
void main()
EIP-4844 comes with a new opcode BLOBHASH
and adds a new point evaluation precompile at address 0x14
in the underlying @ethereumjs/evm
package.
Note: Usage of the point evaluation precompile needs a manual KZG library installation and global initialization, see KZG Setup for instructions.
Our TypeScript
VM emits events that support async listeners.
You can subscribe to the following events:
beforeBlock
: Emits aBlock
right before running it.afterBlock
: EmitsAfterBlockEvent
right after running a block.beforeTx
: Emits aTransaction
right before running it.afterTx
: Emits aAfterTxEvent
right after running a transaction.
Note, if subscribing to events with an async listener, specify the second parameter of your listener as a resolve
function that must be called once your listener code has finished.
// ./examples/eventListener.ts#L10-L19
// Setup an event listener on the `afterTx` event
vm.events.on('afterTx', (event, resolve) => {
console.log('asynchronous listener to afterTx', bytesToHex(event.transaction.hash()))
// we need to call resolve() to avoid the event listener hanging
resolve?.()
})
vm.events.on('afterTx', (event) => {
console.log('synchronous listener to afterTx', bytesToHex(event.transaction.hash()))
})
Please note that there are additional EVM-specific events in the @ethereumjs/evm package.
You can perform asynchronous operations from within an event handler and prevent the VM to keep running until they finish.
In order to do that, your event handler has to accept two arguments. The first one will be the event object, and the second one a function. The VM won't continue until you call this function.
If an exception is passed to that function, or thrown from within the handler or a function called by it, the exception will bubble into the VM and interrupt it, possibly corrupting its state. It's strongly recommended not to do that.
If you want to perform synchronous operations, you don't need to receive a function as the handler's second argument, nor call it.
Note that if your event handler receives multiple arguments, the second one will be the continuation function, and it must be called.
If an exception is thrown from within the handler or a function called by it, the exception will bubble into the VM and interrupt it, possibly corrupting its state. It's strongly recommended not to throw from within event handlers.
If you want to understand your VM runs we have added a hierarchically structured list of debug loggers for your convenience which can be activated in arbitrary combinations. We also use these loggers internally for development and testing. These loggers use the debug library and can be activated on the CL with DEBUG=ethjs,[Logger Selection] node [Your Script to Run].js
and produce output like the following:
The following loggers are currently available:
Logger | Description |
---|---|
vm:block |
Block operations (run txs, generating receipts, block rewards,...) |
vm:tx |
Transaction operations (account updates, checkpointing,...) |
vm:tx:gas |
Transaction gas logger |
vm:state |
StateManager logger |
Note that there are additional EVM-specific loggers in the @ethereumjs/evm package.
Here are some examples for useful logger combinations.
Run one specific logger:
DEBUG=ethjs,vm:tx tsx test.ts
Run all loggers currently available:
DEBUG=ethjs,vm:*,vm:*:* tsx test.ts
Run only the gas loggers:
DEBUG=ethjs,vm:*:gas tsx test.ts
Excluding the state logger:
DEBUG=ethjs,vm:*,vm:*:*,-vm:state tsx test.ts
Run some specific loggers including a logger specifically logging the SSTORE
executions from the VM (this is from the screenshot above):
DEBUG=ethjs,vm:tx,vm:evm,vm:ops:sstore,vm:*:gas tsx test.ts
The VM processes state changes at many levels.
- runBlockchain
- for every block, runBlock
- runBlock
- for every tx, runTx
- pay miner and uncles
- runTx
- check sender balance
- check sender nonce
- runCall
- transfer gas charges
TODO: this section likely needs an update.
Developer documentation - currently mainly with information on testing and debugging - can be found here.
See our organizational documentation for an introduction to EthereumJS
as well as information on current standards and best practices. If you want to join for work or carry out improvements on the libraries, please review our contribution guidelines first.