All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog (modification: no type change headlines) and this project adheres to Semantic Versioning.
This is a first round of alpha releases for our upcoming breaking release round with a focus on bundle size (tree shaking) and security (dependencies down + no WASM (by default)). Note that alpha releases are not meant to be fully API-stable yet and are for early testing only. This release series will be then followed by a beta release round where APIs are expected to be mostly stable. Final releases can then be expected for late October/early November 2024.
The static constructors for our library classes have been reworked to now be standalone methods (with a similar naming scheme). This allows for better tree shaking of unused constructor code (see PR #3516):
EVM.create()->createEVM
This is the first EthereumJS EVM release where we could realize a fully WASM-free EVM by default! 🤩 We were finally able to replace all crypto primitives which still relied on Web Assembly code with pure JavaScript/TypeScript pendants, thanks a lot to @paulmillr from Noble for the cooperation on this! ❤️
Together with a strong dependency reduction being accomplished along this release this opens up for new use cases for the JavaScript EVM in more security sensitive contexts. The code of the EVM is now compact enough that it gets fully auditable (and we plan an EVM audit for 2025), see e.g. here for an EVM bundle snapshot including all dependencies!
So, what changed?
The previously WASM-backed BN254 (or previously called alt_BN128) precompile implementations have first decoupled from the WASM-backend by introducing a generic interface EVMBN254Interface, see PR #3564. Then the WASM version - using the rustbn-wasm binding library to the BN Rust library - has been replaced by using the corresponding JS functionality from noble-curves.
It is still possible to use the WASM version (if more performance is needed) like this using the bn254 constructor option:
import { initRustBN } from 'rustbn-wasm'
const bn254 = await initRustBN()
const evm = await createEVM({ bn254: new RustBN254(bn254) })The WASM based KZG integration for 4844 support and usage for the EVM KZG point evaluation precompile has been replaced with a pure JS-based solution (micro-eth-singer, see PR #3674. The JS version is indeed even faster then the WASM one (we benchmarked), so we recommend to just switch over!
KZG is one-time initialized by providing to Common, in the updated version now like this:
import { trustedSetup } from '@paulmillr/trusted-setups/fast.js'
import { KZG as microEthKZG } from 'micro-eth-signer/kzg'
const kzg = new microEthKZG(trustedSetup)
// Pass the following Common to the EthereumJS library
const common = new Common({
chain: Mainnet,
customCrypto: {
kzg,
},
})Note that you need to provide this if you want to have a fully Shanghai/Cancun compliant EVM (otherwise the KZG precompile will not work if called)!
HF-sensitive parameters like maxInitCodeSize were previously by design all provided by the @ethereumjs/common library. This meant that all parameter sets were shared among the libraries and libraries carried around a lot of unnecessary parameters.
With the Common refactoring from PR #3537 parameters now moved over to a dedicated params.ts file (exposed as e.g. paramsEVM) within the parameter-using library and the library sets its own parameter set by internally calling a new Common method updateParams(). For shared Common instances parameter sets then accumulate as needed.
Beside having a lighter footprint this additionally allows for easier parameter customization. There is a new params constructor option which leverages this new possibility and where it becomes possible to provide a fully customized set of core library parameters.
There is a new Common API for simplification and better tree shaking, see PR #3545. Change your Common initializations as follows (see Common release for more details):
// old
import { Chain, Common } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet })
// new
import { Common, Mainnet } from '@ethereumjs/common'
const common = new Common({ chain: Mainnet })This is one of the few big EIP additions within this breaking release series: Jochem has re-taken upon EOF and fully implemented the new Mega EOF specification, see #3440 and #3553! ❤️ Note that - while most code should be there in its final form - the implementation is still marked as experimental - since there are still various moving parts within EOF.
It would get too extensive to fully recite the functional changes here. If you are interested in EOF please have a look at the above linked core implementation PR and see the EVM examples folder for EOF usage examples.
The dedicated EVMStateManagerInterface has been removed and the EVM now uses the generic StateManagerInterface (located in the @ethereumjs/util package for re-usability reasons), see PR #3543. This comes along with some refactoring and adjustments on the interface itself (see @ethereumjs/statemanager release notes for more details).
This simplifies the StateManager usage and allows for easier swapping between different state managers (stateful/stateless, Verkle/Merkle, RPC).
- New
SimpleStateManageras default state manager (reduces bundle size), PR #3482 - New default hardfork:
Shanghai->Cancun, see PR #3566 - Removed
EIP-3074(AUTH / AUTHCALL opcodes) support, since superseded byEIP-7702, PR #3582 - Rename
ec*BN254 (aka alt_bn128) precompile parameters and names tobn254*(e.g. paramecAddGas->bn254AddGas, nameECMUL->BN254MUL), partly also BLS name alignment, PR #3655
- Upgrade to TypeScript 5, PR #3607
- Node 22 support, PR #3669
- Upgrade
ethereum-cryptographyto v3, PR #3668 - Fix BLS usage for BLS12-381 precompiles, PR #3623
- kaustinen7 verkle testnet preparation (update verkle leaf structure -> BASIC_DATA), PR #3433
Starting with this release the EVM support the BLS precompiles introduced with EIP-2537. These precompiles run natively using the @noble/curves library (❤️ to @paulmillr!), see PRs #3350 and #3471.
An alternative WASM implementation (using bls-wasm) can be optionally used like this if needed for performance reasons:
import { EVM, MCLBLS } from '@ethereumjs/evm'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Prague })
await mcl.init(mcl.BLS12_381)
const mclbls = new MCLBLS(mcl)
const evm = await EVM.create({ common, bls })We have relatively light-heartedly added a new @ethereumjs/verkle main dependency to the VM/EVM stack in the v7.2.1 release, which added an additional burden to the bundle size by several hundred KB and additionally draws in unnecessary WASM code. Coupling with Verkle has been refactored in PR #3462 and the direct dependency has been removed again.
An update to this release is therefore strongly recommended even if other fixes or features are not that relevant for you right now.
- Adds ability to run EIP-7702 EOA code transactions (see tx library for full documentation), see PR #3470
- Fixes for Kaustinen4 support, PR #3269
- Kaustinen5 related fixes, PR #3343
- Kaustinen6 adjustments,
verkle-cryptography-wasmmigration, PRs #3355 and #3356 - Update
kzg-wasmto0.4.0, PR #3358 - Shift Verkle to
osakahardfork, PR #3371 - Fix
accessWitnesspassing, PR #3405 - Remove the hacks to prevent account cleanups of system contracts, PR #3418
- Fix EIP-2935 address conversion issues, PR #3447
- Add support for retroactive EIP-7610, PR #3480
- Adds bundle visualizer (to be used with
npm run visualize:bundle), PR #3463 - Stricter prefixed hex typing, PRs #3348, #3427 and #3357 (some changes removed in PR #3382 for backwards compatibility reasons, will be reintroduced along upcoming breaking releases)
- Removes support for EIP-2315 simple subroutines for EVM (deprecated with an alternative version integrated into EOF), PR #3342
- Update
mcl-wasmDependency (Esbuild Issue), PR #3461
This is an in-between breaking release on both the EVM and VM packages due to a problematic top level await() discovery in the underlying rustbn-wasm library (see issue #10) generally affecting the compatibility of our libraries.
The EVM direct constructor initialization with new EVM() now has been deprecated and replaced by an async static create() constructor, as it is already done in various other libraries in the EthereumJS monorepo, see PRs #3304 and #3315.
An EVM is now initialized like the following (from our examples):
import { hexToBytes } from '@ethereumjs/util'
import { EVM } from '@ethereumjs/evm'
const evm = await EVM.create()
const res = await evm.runCode({ code: hexToBytes('0x6001') })Beyond solving this specific problem this generally allows for a cleaner and async-complete initialization of underlying libraries and is more future proof towards eventual upcoming async initialization additions.
Note that the direct usage of the main constructor is not possible anymore with these releases and you need to update your constructor usages!
Shortly following the "Dencun Hardfork Support" release round from last month, this is now the first round of releases where the EthereumJS libraries are now fully browser compatible regarding the new 4844 functionality, see PRs #3294 and #3296! 🎉
Our WASM wizard @acolytec3 has spent the last two weeks and created a WASM build of the c-kzg library which we have released under the kzg-wasm name on npm (and you can also use independently for other projects). See the newly created GitHub repository for some library-specific documentation.
This WASM KZG library can now be used for KZG initialization (replacing the old recommended c-kzg initialization), see the respective README section from the tx library for usage instructions (which is also accurate for the other using upstream libraries like block or EVM).
Note that kzg-wasm needs to be added manually to your own dependencies and the KZG initialization code needs to be adopted like the following (which you will likely want to do in most cases, so if you deal with post Dencun EVM bytecode and/or 4844 blob txs in any way):
import { loadKZG } from 'kzg-wasm'
import { Chain, Common, Hardfork } from '@ethereumjs/common'
const kzg = await loadKZG()
// Instantiate `common`
const common = new Common({
chain: Chain.Mainnet,
hardfork: Hardfork.Cancun,
customCrypto: { kzg },
})Manual addition is necessary because we did not want to bundle our libraries with WASM code by default, since some projects are then prevented from using our libraries.
Note that passing in the KZG setup file is not necessary anymore, since this is now defaulting to the setup file from the official KZG ceremony (which is now bundled with the KZG library).
Since this fits well also to be placed here relatively prominently for awareness: we had a relatively nasty bug in the @ethereumjs/trie library with a Node.js web stream import also affecting browser compatibility, see PR #3280. This bug has been fixed along with these releases and this library now references the updated trie library version.
- Support for Preimage generation (verkle-related, experimental), new
startReportingPreimages()method, PR #3143 and #3298 - Early support for EIP-2935 - "Save historical block hashes in state" (Verkle related, likely subject to change), PRs #3268 and #3327
- Export
getOpcodesForHF()helper method, PR #3322
- Hotfix release moving the
@ethereumjs/verkledependency for@ethereumjs/statemanagerfrom a peer dependency to the main dependencies (note that this decision might be temporary)
While all EIPs contained in the upcoming Dencun hardfork run pretty much stable within the EthereumJS libraries for quite some time, this is the first release round which puts all this in the official space and removes "experimental" labeling preparing for an imminent Dencun launch on the last testnets (Holesky) and mainnet activation! 🎉
Dencun hardfork on the execution side is called Cancun and can be activated within the EthereumJS libraries (default hardfork still Shanghai) with a following common instance:
import * as kzg from 'c-kzg'
import { Common, Chain, Hardfork } from '@ethereumjs/common'
import { initKZG } from '@ethereumjs/util'
initKZG(kzg, __dirname + '/../../client/src/trustedSetups/official.txt')
const common = new Common({
chain: Chain.Mainnet,
hardfork: Hardfork.Cancun,
customCrypto: { kzg: kzg },
})
console.log(common.customCrypto.kzg) // Should print the initialized KZG interfaceNote that the kzg initialization slightly changed from previous experimental releases and a custom KZG instance is now passed to Common by using the customCrypto parameter, see PR #3262.
At the moment using the Node.js bindings for the c-kzg library is the only option to get KZG related functionality to work, note that this solution is not browser compatible. We are currently working on a WASM build of that respective library. Let us know on the urgency of this task! 😆
While EIP-4844 - activating shard blob transactions - is for sure the most prominent EIP from this hardfork, enabling better scaling for the Ethereum ecosystem by providing cheaper block space for L2s, there are in total 6 EIPs contained in the Dencun hardfork. The following is an overview of which EthereumJS libraries mainly implement the various EIPs:
- EIP-1153: Transient storage opcodes (
@ethereumjs/evm) - EIP-4788: Beacon block root in the EVM (
@ethereumjs/block,@ethereumjs/evm,@ethereumjs/vm) - EIP-4844: Shard Blob Transactions (
@ethereumjs/tx,@ethereumjs/block,@ethereumjs/evm) - EIP-5656: MCOPY - Memory copying instruction (
@ethereumjs/evm) - EIP-6780: SELFDESTRUCT only in same transaction (
@ethereumjs/vm) - EIP-7516: BLOBBASEFEE opcode (
@ethereumjs/block,@ethereumjs/evm)
With this release round there is a new way to replace the native JS crypto primitives used within the EthereumJS ecosystem by custom/other implementations in a controlled fashion, see PR #3192.
This can e.g. be used to replace time-consuming primitives like the commonly used keccak256 hash function with a more performant WASM based implementation, see @ethereumjs/common README for some detailed guidance on how to use.
All code examples in EthereumJS monorepo library README files are now self-contained and can be executed "out of the box" by simply copying them over and running "as is", see tracking issue #3234 for an overview. Additionally all examples can now be found in the respective library examples folder (in fact the README examples are now auto-embedded from over there). As a nice side effect all examples are now run in CI on new PRs and so do not risk to get outdated or broken over time.
- Fix
modexpprecompile edge cases (❤️ to @last-las for reporting!), PR #3169 - Fix bug in custom precompile functionality (❤️ to @roninjin10 for the contribution!), PR #3158
- Fix Blake2F gas + output calculation on non-zero aligned inputs (❤️ to @kchojn for the contribution!), PR #3201
- Ensure
modexpright-pads input data (❤️ to @last-las for reporting!), PR #3206 - Fix CALL(CODE) gas (❤️ to @last-las for reporting!), PR #3195
- Add
runCallOptsandrunCodeOptsto evm exports, PR #3172 - Add test for
ecrecoverprecompile, PR #3184 - Additional tests for the
ripemd160andblake2fprecompiles, PR #3189
This releases ships with a completely new dedicated EVM profiler (❤️ to Jochem for the integration) to measure how the different opcode implementations are doing, see PR #2988, #3011, #3013 and #3041.
See the new dedicated README section for a detailed usage instruction.
We were already able to do various performance related improvements using this tool (and we hope that you will be too) 🤩:
- Substantial stack optimizations (
PUSHandPOPn+30-40%,DUP+40%), PR #3000 JUMPDESToptimizations, PR #3000- Various EVM interpreter optimizations (overall 7-15% performance gain), PR #2996
- Memory optimizations (
MLOADandMSTORE+ 10-20%), PR #3032 - Reused BigInts cache, PR #3034 and #3050
EXPopcode optimizations (real-world 3x gain, not attack resistant), PR #3034
This release supports EIP-7516 with a new BLOBBASEFEE opcode added to and scheduled for the Dencun HF, see PR #3035 and #3068. The opcode returns the value of the blob base-fee of the current block it is executing in.
This release contains various fixes and spec updates related to the Dencun (Deneb/Cancun) HF and is now compatible with the specs as used in devnet-11 (October 2023).
- Update
EIP-4788: do not use precompile anymore but use the pre-deployed bytecode, PR #2955
- Add missing
debugdependency types, PR #3072
Final release version from the breaking release round from Summer 2023 on the EthereumJS libraries, thanks to the whole team for this amazing accomplishment! ❤️ 🥳
See RC1 release notes for the main change description.
Following additional changes since RC1/RC2:
- 4844: Rename
dataGastoblobGas(see EIP-4844 PR #7354), PR #2919 - Fix some remaining type issues, PR #2918
- Add missing
@ethereumjs/statemanagerdependency
This is the release candidate (RC1) for the upcoming breaking releases on the various EthereumJS libraries. The associated release notes below are the main source of information on the changeset, also for the upcoming final releases, where we'll just provide change addition summaries + references to these RC1 notes.
At time of the RC1 releases there is/was no plan for a second RC round and breaking releases following relatively shorty (2-3 weeks) after the RC1 round. Things may change though depending on the feedback we'll receive.
This round of breaking releases brings the EthereumJS libraries to the browser. Finally! 🤩
While you could use our libraries in the browser libraries before, there had been caveats.
WE HAVE ELIMINATED ALL OF THEM.
The largest two undertakings: First: we have rewritten all (half) of our API and eliminated the usage of Node.js specific Buffer all over the place and have rewritten with using Uint8Array byte objects. Second: we went through our whole stack, rewrote imports and exports, replaced and updated dependencies all over and are now able to provide a hybrid CommonJS/ESM build, for all libraries. Both of these things are huge.
Together with some few other modifications this now allows to run each (maybe adding an asterisk for client and devp2p) of our libraries directly in the browser - more or less without any modifications - see the examples/browser.html file in each package folder for an easy to set up example.
This is generally a big thing for Ethereum cause this brings the full Ethereum Execution Layer (EL) protocol stack to the browser in an easy accessible way for developers, for the first time ever! 🎉
This will allow for easy-to-setup browser applications both around the existing as well as the upcoming Ethereum EL protocol stack in the future. 🏄🏾♂️ We are beyond excitement to see what you guys will be building with this for "Browser-Ethereum". 🤓
Browser is not the only thing though why this release round is exciting: default Shanghai hardfork, full Cancun support, significantly smaller bundle sizes for various libraries, new database abstractions, a simpler to use EVM, API clean-ups throughout the whole stack. These are just the most prominent additional things here to mention which will make the developer heart beat a bit faster hopefully when you are scanning to the vast release notes for every of the 15 (!) releases! 🧑🏽💻
So: jump right in and enjoy. We can't wait to hear your feedback and see if you agree that these releases are as good as we think they are. 🙂 ❤️
The EthereumJS Team
The Shanghai hardfork is now the default HF in @ethereumjs/common and therefore for all libraries who use a Common-based HF setting internally (e.g. Tx, Block or EVM), see PR #2655.
Also the Merge HF has been renamed to Paris (Hardfork.Paris) which is the correct HF name on the execution side, see #2652. To set the HF to Paris in Common you can do:
import { Chain, Common, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Paris })And third on hardforks 🙂: the upcoming Cancun hardfork is now fully supported and all EIPs are included (see PRs #2659 and #2892). The Cancun HF can be activated with:
import { Chain, Common, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Cancun })Note that not all Cancun EIPs are in a FINAL EIP state though and particularly EIP-4844 will likely still receive some changes.
During the last round of breaking releases we separated the EVM and VM packages and largely decoupled the outer execution part (VM) and the "pure" EVM, being just a package containing the "Ethereum Virtual Machine" code with no notion of the outer txs or blocks which include the executable byte code.
While this was a large step in the "right direction" [TM] we realized over the last months that the structure we introduced with a separate EEI as an additional abstraction layer for talking of the EVM with the "outside world" (another [TM]) for e.g. retrieving block hashes or the like still unnecessarily tied the VM/EVM structures together and didn't fully allow for a truly separate EVM initialization.
We have now further refactored this - see PR #2649 and PR #2702 - and simplified the interface and completely removed the EEI package, with most of the EEI related logic now either handled internally or more generic functionality being taken over by the @ethereumjs/statemanager package.
So the mandatory eei option now goes away and is replaced by two optional stateManager and blockchain options, and if not provided, default values are taken here.
So the EVM initialization in its most simple form now goes to:
import { hexToBytes } from '@ethereumjs/util'
import { EVM } from '@ethereumjs/evm'
const evm = new EVM()
evm.runCode({ code: hexToBytes('0x01') })🎉
This release adds support for EIP-5656 "MCOPY - Memory copying instruction" - which is scheduled to be activated along the Cancun HF.
You can initialize an EIP-5656 activated EVM with:
import { Chain, Common, Hardfork } from '@ethereumjs/common'
import { EVM } from '@ethereumjs/evm'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Cancun })
const evm = new EVM({ common })See the EVM EIP-5656 API test file for a respective test scenario on the bytecode level.
This new copy operation reduces overhead (and therefore saves gas costs) in certain memory copy scenarios.
Support for EIP-6780 "SELFDESTRUCT only in same transaction" - which is scheduled to be activated along the Cancun HF - has been added to the EVM.
You can initialize an EIP-6780 activated EVM with:
import { Chain, Common, Hardfork } from '@ethereumjs/common'
import { EVM } from '@ethereumjs/evm'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Cancun })
const evm = new EVM({ common })See the VM EIP-6780 API test file for a respective test scenario on the bytecode level.
In this release two opcodes have been renamed to more adequately match their functionality, see PR #2706.
The 0x20 opcode - previously wrongly named SHA3 - has been renamed to KECCAK.
The 0x44 (old DIFFICULTY) opcode - is now named PREVRANDAO - starting with the Paris (Merge) HF.
While there might be last-round final tweaks, EIP-4844 is closing in on its final format. A lot of spec changes happened during the last 2-3 months and these are included in this release round. So the released version should be relatively close to a future production ready version.
This release supports EIP-4844 along this snapshot b9a5a11 from the EIP repository with the EIP being in Review status and features/changes included which made it into 4844-devnet-7.
The global initialization method for the KZG setup has been moved to a dedicated kzg.ts module in @ethereumjs/util for easy reuse across the libraries, see PR #2567.
The initKZG() method can be used as follows:
// Make the kzg library available globally
import * as kzg from 'c-kzg'
import { initKZG } from '@ethereumjs/util'
// Initialize the trusted setup
initKZG(kzg, 'path/to/my/trusted_setup.txt')For further information on this see the respective section in @ethereumjs-util README.
The following changes are included:
- Fix the availability of versioned hashes in contract calls, PR #2694
- Rename
DATAHASHtoBLOBHASH, PR #2711 - Add
dataGasUsedtotxReceiptand EVM execution result, PR #2620 - Update c-kzg to big endian implementation (
0x0aKZG point evaluation precompile), PR #2746
We now provide both a CommonJS and an ESM build for all our libraries. 🥳 This transition was a huge undertaking and should make the usage of our libraries in the browser a lot more straight-forward, see PR #2685, #2783, #2786, #2764, #2804 and #2809 (and others). We rewrote the whole set of imports and exports within the libraries, updated or completely removed a lot of dependencies along the way and removed the usage of all native Node.js primitives (like https or util).
There are now two different build directories in our dist folder, being dist/cjs for the CommonJS and dist/esm for the ESM build. That means that direct imports (which you generally should try to avoid, rather open an issue on your import needs), need an update within your code (do a dist or the like code search).
Both builds have respective separate entrypoints in the distributed package.json file.
A CommonJS import of our libraries can then be done like this:
const { Chain, Common } = require('@ethereumjs/common')
const common = new Common({ chain: Chain.Mainnet })And this is how an ESM import looks like:
import { Chain, Common } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet })Using ESM will give you additional advantages over CJS beyond browser usage like static code analysis / Tree Shaking which CJS can not provide.
Side note: along this transition we also rewrote our whole test suite (yes!!!) to now work with Vitest instead of Tape.
With these releases we remove 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). While this is a big step towards interoperability and browser compatibility of our libraries, this is also one of the most invasive operations we have ever done, see the huge changeset from PR #2566 and #2607. 😋
We nevertheless think this is very much worth it and we tried to make transition work as easy as possible.
For this library you should check if you use one of the following constructors, methods, constants or types and do a search and update input and/or output values or general usages and add conversion methods if necessary:
// evm
EVM.runCall(opts: EVMRunCallOpts): Promise<EVMResult> // data, code, salt, versionedHashes (4844)
EVM.runCode(opts: EVMRunCodeOpts): Promise<ExecResult> // data, code, versionedHashes (4844)
// events
EVM.on('newContract', ...) // code
EVM.on('beforeMessage', ...) // Message
EVM.on('afterMessage', ...) // EVMResult
EVM.on('step', ...) // InterpreterStepWe have converted existing Buffer conversion methods to Uint8Array conversion methods in the @ethereumjs/util bytes module, see the respective README section for guidance.
The mixed usage of prefixed and unprefixed hex strings is a constant source of errors in byte-handling code bases.
We have therefore decided to go "prefixed" by default, see PR #2830 and #2845.
The hexToBytes and bytesToHex methods, also similar methods like intToHex, now take 0x-prefixed hex strings as input and output prefixed strings. The corresponding unprefixed methods are marked as deprecated and usage should be avoided.
Please therefore check you code base on updating and ensure that values you are passing to constructors and methods are prefixed with a 0x.
- Support for
Node.js 16has been removed (minimal version:Node.js 18), PR #2859 - Replace
rustbn.jswith wasm-compiledrustbn-wasmmodule, PR #2834 - Consistent usage of an
EVMInterfacefor easier EVM adoption, PR #2869 - Move KZG precompile address from
0x14to0x0a, PR #2811 - Breaking: The
copy()method has been renamed toshallowCopy()(same underlying state DB), PR #2826 - Breaking: following properties have been renamed and the underscore removed:
_allowUnlimitedContractSize,allowUnlimitedInitCodeSize,_transientStorage, PR #2857 - Fix the gasCost logs in op code trace (
stepevent) to better match Geth output and reflect dynamic gas changes, PR #2686 - EIP-1153 TLOAD TSTORE update opcode byte, PR #2884
- EVM runCode/runCall type cleanup, PR #2861
- Better error handling for contract creation errors, PR #2723
- Add
allowUnlimitedInitcodeSizeoption to partially disable EIP-3860, PR #2594
- Fixed
EIP-3860(max init code size) for CREATE and CREATE2, PR #2601 - Fixed block hash calculation when creating a new block object From JSON RPC (Shanghai), PR #2600
- Fix
memoryinstepevent to report the actual memory which the EVM sees, PR #2598
- Avoid memory.read() Memory Copy (performance), PR #2573
- Memory Fix & selected performance optimizations, PR #2570
bnadd/bnmulPrecompile Performance Optimization, PR #2568
- Update ethereum-cryptography from 1.2 to 2.0 (switch from noble-secp256k1 to noble-curves), PR #2641
- Bump
@ethereumjs/util@chainsafe/sszdependency to 0.11.1 (no WASM, native SHA-256 implementation, ES2019 compatible, explicit imports), PRs #2622, #2564 and #2656 - Precompile Debug Logger Improvements, PR #2572
- Pinned
@ethereumjs/util@chainsafe/sszdependency tov0.9.4due to ES2021 features used inv0.10.+causing compatibility issues, PR #2555
DEPRECATED: Release is deprecated due to broken dependencies, please update to the subsequent bugfix release version.
This release fully supports all EIPs included in the Shanghai feature hardfork scheduled for early 2023. Note that a timestamp to trigger the Shanghai fork update is only added for the sepolia testnet and not yet for goerli or mainnet.
You can instantiate a Shanghai-enabled Common instance for your transactions with:
import { Common, Chain, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Shanghai })Note: that this is only a finalizing release by e.g. integrating an updated @ethereumjs/common library with an updated Shanghai HF setting and all Shanghai related EIP functionality has been already released in former releases. Do a fulltext search on the EIP numbers in the EVM/VM CHANGELOG files for additional information and usage instructions.
This release supports an experimental version of the blob transaction type introduced with EIP-4844 as being specified in the 01d3209 EIP version from February 8, 2023 and deployed along eip4844-devnet-4 (January 2023), see PR #2349 as well as PRs #2522 and #2526.
To run EVM related EIP-4844 functionality you have to active the EIP in the associated @ethereumjs/common library:
import { Common, Chain, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Shanghai, eips: [4844] })The EVM now supports the DATAHASH opcode which can return the versioned hash from blobs if blobs are associated with a submitting transaction (see EIP-4844 specification).
The EVM now integrates a new point evaluation precompile at address 0x14 to "verify a KZG proof which claims that a blob (represented by a commitment) evaluates to a given value at a given point" (from the EIP definition).
Note: Usage of the point evaluation precompile needs a manual KZG library installation and global initialization, see KZG Setup for instructions.
- Gas cost fixes for
EIP-3860(experimental), PR #2397 - More correctly timed
nonceupdates to avoid certain consensus-criticalnonce/accountupdate constellations. PR #2404 - Fixed chainstart/Frontier mainnet bug, PR #2439
- EVM memory expansion performance optimizations, PR #2405
EIP-4895beacon chain withdrawals support (see@ethereumjs/vmfor full documentation), PRs #2353 and #2401
- Fixed
EIP-3540bug where EOF header validation was incorrectly applied to legacy contract code in EVM calls, PR #2381 - Various non-empty "empty" account bugfixes, PR #2383
This release replaces the v1.1.0 release from a couple of days ago which now becomes deprecated. The async event emitter library switch from the async-eventemitter package to the eventemitter2 package turned out to be breaking along parts of the functionality.
This release therefore switches back to a modernized version of the async-eventemitter package - now also solving previous import problems - which has been internalized and integrated into the @ethereumjs/util package, see PR #2376.
[ DEPRECATED ]: Async event emitter library switch turned out to be breaking. If you have got problems, please update to v1.2.0 or above.
For lots of custom chains (for e.g. devnets and testnets), you might come across a Geth genesis.json config which has both config specification for the chain as well as the genesis state specification.
Common now has a new constructor Common.fromGethGenesis() - see PRs #2300 and #2319 - which can be used in following manner to instantiate for example a VM run or a tx with a genesis.json based Common:
import { Common } from '@ethereumjs/common'
// Load geth genesis json file into lets say `genesisJson` and optional `chain` and `genesisHash`
const common = Common.fromGethGenesis(genesisJson, { chain: 'customChain', genesisHash })
// If you don't have `genesisHash` while initiating common, you can later configure common (for e.g.
// calculating it afterwards by using the `@ethereumjs/blockchain` package)
common.setForkHashes(genesisHash)Along some deeper investigation of build errors related to the usage of the async-eventemitter package we finally decided to completely switch to a new async event emitter package for VM/EVM events, see PR #2303. The old async-eventemitter package hasn't been updated for several years and the new eventemitter2 package is more modern and maintained as well as substantially more used and therefore a future-proof choice for an async event emitter library to build the VM/EVM event emitting system upon.
The significant parts of the API of both the old and the new libraries are the same and the switch shouldn't cause too much hassle for people upgrading. In case you nevertheless stumble upon upgrading problems regarding the event emitter package switch please feel free to open an issue, we'll be there to assist you on the upgrade!
- Moved
EIP-4399state to non-experimental (docs only), PR #2355 - Memory extend optimization in
write()function, PR #2276 - Added
getActiveOpcodes?(): OpcodeListas an optional method toEVMInterface, PR #2361
Final release - tada 🎉 - of a wider breaking release round on the EthereumJS monorepo libraries, see the Beta 1 release notes for the main long change set description as well as the Beta 2, Beta 3 and Release Candidate (RC) 1 release notes for notes on some additional changes (CHANGELOG).
- Added a new error type
CodesizeExceedsMaximumErrorto better differentiate between (Homestead or later) contract creation goes OOG and deposited code being too large (exceeds maximum code size), PR #2239 - Internal refactor: removed ambiguous boolean checks within conditional clauses, PR #2252
Release candidate 1 for the upcoming breaking release round on the EthereumJS monorepo libraries, see the Beta 1 release notes for the main long change set description as well as the Beta 2 and 3 release notes for notes on some additional changes (CHANGELOG).
Since this bug was so severe it gets its own section: mainnet in the underlying @ethereumjs/common library (Chain.Mainnet) was accidentally not updated yet to default to the merge HF (Hardfork.Merge) by an undiscovered overwrite back to london.
This has been fixed in PR #2206 and mainnet now default to the merge as well.
This is the biggest EVM change in this release. The inheritance structure of the EVM has been reworked and the EVM class has been freed from being a child class of AsyncEventEmitter and inheriting all its properties and methods in favor of a new events property cleanly separating all events logic from the core EVM, see PR #2235.
This allows for an easier typing of the EVM and makes the core EVM class leaner and not overloaded with various other partly unused properties. The new events property is optional.
Usage code of events needs to be slightly adopted and updated from:
evm.on('step', (e) => {
// Do something
}To:
evm.events.on('step', (e) => {
// Do something
}- Reworked/adjusted
skipBalanceoption semantics, PR #2138 - Fixed an event signature typing bug, PR #2184
- Added
enginefield topackage.jsonlimiting Node versions to v14 or higher, PR #2164 - Replaced
nyc(code coverage) configurations withc8configurations, PR #2192 - Code formats improvements by adding various new linting rules, see Issue #1935
Beta 3 release for the upcoming breaking release round on the EthereumJS monorepo libraries, see the Beta 1 release notes for the main long change set description as well as the Beta 2 release notes for notes on some additional changes (CHANGELOG).
Since the Merge HF is getting close we have decided to directly jump on the Merge HF (before: Istanbul) as default in the underlying @ethereumjs/common library and skip the London default HF as we initially intended to set (see Beta 1 CHANGELOG), see PR #2087.
This means that if this library is instantiated without providing an explicit Common, the Merge HF will be set as the default hardfork and the behavior of the library changes according to up-to-Merge HF rules.
If you want to prevent these kind of implicit HF switches in the future it is likely a good practice to just always do your upper-level library instantiations with a Common instance setting an explicit HF, e.g.:
import { Common, Chain, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.London })- Ensure EVM runs when nonce is 0, PR #2054
- EVM/VM instantiation fixes, PR #2078
- Moved
@types/async-eventemitterfrom devDependencies to dependencies, PR #2077 - Added additional exports
EvmErrorMessage,ExecResult,InterpreterStep,Message, PR #2063
Beta 2 release for the upcoming breaking release round on the EthereumJS monorepo libraries, see the Beta 1 release notes (CHANGELOG) for the main change set description.
The change with the biggest effect on UX since the last Beta 1 releases is for sure that we have removed default exports all across the monorepo, see PR #2018, we even now added a new linting rule that completely disallows using.
Default exports were a common source of error and confusion when using our libraries in a CommonJS context, leading to issues like Issue #978.
Now every import is a named import and we think the long term benefits will very much outweigh the one-time hassle of some import adoptions.
Since our @ethereumjs/common library is used all across our libraries for chain and HF instantiation this will likely be the one being the most prevalent regarding the need for some import updates.
So Common import and usage is changing from:
import Common, { Chain, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Merge })to:
import { Common, Chain, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Merge })The main EVM class import has been updated, so import changes from:
import EVM from '@ethereumjs/evm'to:
import { EVM } from '@ethereumjs/evm'Other updates:
- EVM
ExecResult - Various internal components like
Stack,Memory,Message,TransientStorage - Internal precompile exports
- Added
ESLintstrict boolean expressions linting rule, PR #2030 - Aligned EVM debug logger names, e.g.
vm:ops->evm:ops, PR #2029 - Fixed EVM precompile loading on hardfork change, PR #2040
This release is part of a larger breaking release round where all EthereumJS monorepo libraries (VM, Tx, Trie, other) get major version upgrades. This round of releases has been prepared for a long time and we are really pleased with and proud of the result, thanks to all team members and contributors who worked so hard and made this possible! 🙂 ❤️
We have gotten rid of a lot of technical debt and inconsistencies and removed unused functionality, renamed methods, improved on the API and on TypeScript typing, to name a few of the more local type of refactoring changes. There are also broader structural changes like a full transition to native JavaScript BigInt values as well as various somewhat deep-reaching refactorings, both within a single package as well as some reaching beyond the scope of a single package. Also two completely new packages - @ethereumjs/evm (in addition to the existing @ethereumjs/vm package) and @ethereumjs/statemanager - have been created, leading to a more modular Ethereum JavaScript VM.
We are very much confident that users of the libraries will greatly benefit from the changes being introduced. However - along the upgrade process - these releases require some extra attention and care since the changeset is both so big and deep reaching. We highly recommend to closely read the release notes, we have done our best to create a full picture on the changes with some special emphasis on delicate code and API parts and give some explicit guidance on how to upgrade and where problems might arise!
So, enjoy the releases (this is a first round of Beta releases, with final releases following a couple of weeks after if things go well)! 🎉
The EthereumJS Team
With this release there is now a dedicated @ethereumjs/evm package extracted from the VM (or: @ethereumjs/vm package), see PRs #1892, #1955 and #1977 for the main implementation work and PR #1974 for the package extraction work. The new package can be installed with:
npm i @ethereumjs/evm(please note that atm this package is not yet completely standalone but still needs the outer VM package to have some useful context to run. Functionality to have the EVM completely standalone will be added later on in a non-breaking way,)
The new EVM package extracts the bytecode execution logic and leaves the handling of the outer environment like setting up some pre-state, processing txs and blocks, generating receipts and paying miners (on a PoW chain) to the outer package.
This makes for a cleaner separation of concerns and generally brings the the new packages a lot closer to being a pure bytecode execution Ethereum Virtual Machine (EVM) implementation than before. This will allow for new ways of both customizing and adopting the inner EVM as well as providing an alternative environmental context and customize on the outer processing used in the outer VM package.
The EVM now provides interfaces for the EVM itself and for the EEI, the environmental interface which allows for the EVM to request external data like a blockhash for the respective BLOCKHASH opcode. The EEI is intended as "bridge" between the EVM, the VM, and the StateManager. It is now possible to import a new EVM and EEI into the VM, as long as these implement the provided interfaces.
Almost all environment related variables are extracted from EEI and are now in EVM. The environment provides information to the EVM about the code, the remaining gas left, etc. The only environment-related variables left in EEI are the warmed addresses and storage slots, and also keeps track of which accounts are touched (to cleanup later if these are "empty" after running a transaction).
The EEI is created once, not each time when a transaction is ran in the VM. The VM's access to the StateManager is now all done through the EEI.
Internally, in the EVM, the Env environment variable is used to track any variables which do not change during a call frame, for instance the code, the caller, etc. The RunState is used to track anything which can change during the execution, such as the remaining gas, the selfdestruct lists, the stack, the program counter, etc.
In this release the underlying @ethereumjs/common version is updated to v3 which sets the default HF to London (before: Istanbul).
This means that a Block object instantiated without providing an explicit Common is using London as the default hardfork as well and behavior of the library changes according to up-to-London HF rules.
If you want to prevent these kind of implicit HF switches in the future it is likely a good practice to just always do your upper-level library instantiations with a Common instance setting an explicit HF, e.g.:
import Common, { Chain, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Merge })With this round of breaking releases the whole EthereumJS library stack removes the BN.js library and switches to use native JavaScript BigInt values for large-number operations and interactions.
This makes the libraries more secure and robust (no more BN.js v4 vs v5 incompatibilities) and generally comes with substantial performance gains for the large-number-arithmetic-intense parts of the libraries (particularly the VM).
To allow for BigInt support our build target has been updated to ES2020. We feel that some still remaining browser compatibility issues on the edges (old Safari versions e.g.) are justified by the substantial gains this step brings along.
See #1671 and #1771 for the core BigInt transition PRs.
The whole EVM has been rewritten to use BigInt which has been a huge undertaking. Both all internal representation for values previously represented as BN.js instances (gas values, stack, opcode parameters,...) as well as all VM arithmetics have been rewritten to use native BigInts.
This comes with a substantial increase in overall EVM performance, we will provide some numbers on this later on! 🙂
The EVM now comes with experimental support for EIP-3074 introducing two new opcodes Auth and Authcall to allow externally owned accounts to delegate control to a contract, see PRs #1788 and #1867.
The above TypeScript options provide some semantic sugar like allowing to write an import like import React from "react" instead of import * as React from "react", see esModuleInterop and allowSyntheticDefaultImports docs for some details.
While this is convenient, it deviates from the ESM specification and forces downstream users into using these options, which might not be desirable, see this TypeScript Semver docs section for some more detailed argumentation.
Along with the breaking releases we have therefore deactivated both of these options and you might therefore need to adapt some import statements accordingly. Note that you still can activate these options in your bundle and/or transpilation pipeline (but now you also have the option not to, which you didn't have before).
- The EVM is now fully typed. Before, the
AsyncEventEmitterdid not have an interface, therefore TypeScript internally casts it asany. It also provides types for the available events - TransientStorage (EIP-1153) is now part of EVM and not of EEI
- Renamed
gasUsedtoexecutionGasUsedas part ofExecResult
- Fixed expanded memory reporting in
stepevent on reading previously untouched location - thanks to @theNvN for the contribution ❤️, PR #1887 - New optional
hasStateRootmethod onStateManagerinterface, PR #1878 EIP-1153Transient Storage (experimental): Improve the time taken to commit by using a journal instead of stack of maps (potential DoS attack vector), PR #1860- Additional guard for
ecrecoverprecompile if used withvvalues other than27or28, PR #1905
- Updated
ethereum/teststov10.4, PR #1896 - Ensure verifyPostConditions works in
ethereum/testsblockchain test runs, PR #1900
Small EIP - see EIP-3651 considered for inclusion (CFI) in Shanghai to address an initially overpriced COINBASE access, PR #1814.
EIP can be activated manually with:
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.London, eips: [3651] })Experimental implementation of EIP-1153, see PR #1768, thanks to Mark Tyneway from Optimism for the implementation! ❤️
The EIP adds opcodes for manipulating state that behaves identically to storage but is discarded after every transaction. This makes communication via storage (SLOAD/SSTORE) more efficient and would allow for significant gas cost reductions for various use cases.
Hardfork inclusion of the EIP was extensively discussed during ACD 135, April 1 2022.
EIP can be activated manually with:
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.London, eips: [1153] })It is now possible to add, override or delete precompiles in the VM with a new customPrecompiles option, see PR #1813. This allows for further customization of VM behavior in addition to the recently added customOpcodes option, which can be useful for L2 solutions, EVM-based side chains, and other L1s.
An EVM initialization with a custom precompile looks roughly like this where you can provide the intended precompile address and some precompile function which needs to adhere to some specific format to be internally readable and executable:
const vm = await VM.create({
customPrecompiles: [
{
address: shaAddress,
function: customPrecompile,
},
],
})- Updated
ethereum/teststo10.3, PR #1826 - Set
callerinVM.runCall()to zero address if not provided, PR #1840
This release fully supports the Merge Kiln testnet v2 complying with the latest Merge specs. The release is part of an @ethereumjs/client v0.4 release which can be used to sync with the testnet, combining with a suited consensus client (e.g. the Lodestar client). See Kiln instructions to get things going! 🚀
In the VM the merge HF is now activated as being supported and an (experimental) Merge-ready VM can be instantiated with:
import VM from '@ethereumjs/vm'
import Common, { Chain, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Merge })
const vm = new VM({ common })
vm._common.isActivatedEIP(4399) // true- EIP-4399 Support: Supplant DIFFICULTY opcode with PREVRANDAO, PR [#1565](https:// github.com//pull/1565)
This release supports EIP-3540 and EIP-3670 in an experimental state. Both EIPs together define a container format EOF for the VM in v1 which allows for more flexible EVM updates in the future and allows for improved EVM bytecode validation, see PR #1719.
Note that this EIP is not part of a specific hardfork yet and is considered EXPERIMENTAL (implementation can change along bugfix releases).
For now the EIP has to be activated manually which can be done by using a respective Common instance:
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.London, eips: [3540, 3670] })Support for EIP-3860 has been added to the VM. This EIP limits the maximum size of initcode to 49152 and apply extra gas cost of 2 for every 32-byte chunk of initcode, see PR #1619.
Also here, implementation still EXPERIMENTAL and needs to be manually activated:
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.London, eips: [3860] })It is now possible within the VM to initialize with an extended genesis state not only containing account balances but also code and storage, see PR #1757. This is part of our emerging L2 support strategy to allow for a VM instantiation that closer resembles a specific L2 (or generally: custom chain) setup. Many L2 chains come with specific system contracts pre-initialized on genesis - see e.g. Optimism.
See Common custom chain initialization API on how to initialize a Common instance with a code-storage-containing custom genesis state.
Note that state in the VM is not activated by default (this also goes for account-only state). A state activation can now be explicitly triggered though by using the new activateGenesisState VM option.
There is now a new option customOpcodes for the VM which allows to add custom opcodes to the VM, see PR #1705. This should be useful for L2s and other EVM based side chains if they come with a slightly different opcode set for bytecode execution.
New opcodes can be passed in with its own logic function and an additional function for gas calculation. Additionally the new option allows for overwriting and/or deleting existing opcodes.
- Added new
VM.runBlock()optionhardforkByTDfor Merge transition support, PR #1802
- Fixed
REVERTbug where under certain conditions (revert reason larger than max code size), too much (all) gas was consumed, PR #1700 - Debug log improvements on
VM.runTx()execution and inEVM, PR #1677
This patch release adds a guard to not enable the recently added EIP-3607 by default. This helps downstream users who may emulate contract accounts as part of their testing strategies.
- Add guard to not enable EIP-3607 by default, PR #1691
Also included is a performance enhancement to skip extra log processing when debug is not enabled:
Jochem from our team did a great refactoring how the VM handles gas costs in PR #1364 by splitting up the opcode gas cost calculation (new file: evm/opcodes/gas.ts) from their actual behavior (stack edits, getting block hashes, etc.).
This initial work was adopted a bit in PR #1553 to remain backwards-compatible and now allows to output the dynamic gas cost value in the VM step event (see README) now taking things like memory usage, address access or storage changes into account and therefore much better reflecting the real gas usage than only showing the (much lower) static part.
So along with the static opcode.fee output there is now a new event object property opcode.dynamicFee.
The VM StateManager has been substantially refactored in PR #1548 and most of the generic functionality has been extracted to a super class BaseStateManager. This should make it substantially easier to do custom StateManager implementations with an alternative access to the state by inheriting from BaseStateManager and only adopting the methods which directly access the underlying data structure. Have a look at the existing DefaultStateManager implementation for some guidance.
- New
ProofStateManagerto get an EIP-1186-compatible (respectively `eth_getProof rPC endpoint-compatible) proof for a specific address and associated storage slots, PR #1590 and PR #1660 - VM JumpDest analysis refactor for better performance, PR #1629
- EIP-3607: Reject transactions from senders with deployed code, PR #1568
- Support for new Sepolia PoW test network (use
Chain.Sepoliafor@ethereumjs/commoninstance passed in), PR #1581 - EIP-2681: Limit account nonce to 2^64-1, PR #1608
- EIP-3855: Push0 opcode, PR #1616
- Addressed consensus issue: tx goes OOG but refunds get applied anyways (thanks @LogvinovLeon for reporting! ❤️), PR #1603
- VM now throws when a negative
Callvalueis passed in, PR #1606
This release adds support for the upcoming ArrowGlacier HF (see PR #1527) targeted for December 2021. The only included EIP is EIP-4345 which delays the difficulty bomb to June/July 2022.
Please note that for backwards-compatibility reasons the associated Common is still instantiated with istanbul by default.
An ArrowGlacier VM can be instantiated with:
import VM from '@ethereumjs/vm'
import Common, { Chain, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.ArrowGlacier })
const vm = new VM({ common })This release extends the text of the error messages in the library with some consistent context information (see PR #1540), here an example for illustration:
Before:
invalid receiptTrieNew:
invalid receiptTrie (vm hf=berlin -> block number=1 hash=0x8e368301586b53e30c58dd4734de4b3d6e17db837eb3fbde8cc0036bc7752d9a hf=berlin baseFeePerGas=none txs=1 uncles=0)
The extended errors give substantial more object and chain context and should ease debugging.
Potentially breaking: Attention! If you do react on errors in your code and do exact error matching (error.message === 'invalid transaction trie') things will break. Please make sure to do error comparisons with something like error.message.includes('invalid transaction trie') instead. This should generally be the pattern used for all error message comparisons and is assured to be future proof on all error messages (we won't change the core text in non-breaking releases).
- Fixed accountExists bug in pre-Spurious Dragon HFs, PR #1516 and PR #1524
- New
putBlockIntoBlockchainoption forBlockBuilder(default:true), PR #1530 - Extended
StateManager.generateGenesis()to also allow for creating genesis blocks with contract accounts, PR #1530 and PR #1541 - Use
RLPlibrary exposed byethereumjs-utildependency (deduplication), PR #1549
- Fixed a consensus-relevant bug in the Blake2B precompile (see EIP-152) with messages with a length >= 5 (thanks @jochem-brouwer for the great analysis and quick fix on this! ❤️), PR #1486
- Improved support for custom chain genesis states in
StateManager.generateCanonicalGenesis()(seeCommonv2.5.0 release for the corresponding functionality), PR #1409 - Fixed
VM.copy()to also copy theblockchainandcommonobjects, PR #1444
And, also worth to note: we are not susceptible to the IDENTITY precompile bug which caused a minority fork in August 2021, see PR #1436 and - again - thanks @jochem-brouwer for the quick analysis! 😃
New Features
Bug Fixes and Maintenance
Dependencies, CI and Docs
Bug fix release to reverse StateManager interface breaking change. The method modifyAccountFields will be re-added in v6 release (#1024)
New Features
- StateManager: Added
modifyAccountFieldsmethod to simplify thegetAccount-> modify fields ->putAccountpattern, PR #1369 - Report dynamic gas values in
feefield ofstepevent, PR #1364
Bug Fixes
- Fix EIP1559 bug to include tx value in balance check, fix nonce check, PR #1372
- Update
ethereum/teststo v9.0.3 and fix for uncles at hardfork transition, PR #1347
Maintenance
- Update internal
commonusage to new Chain & Hardfork enums, PR #1363 - Add tests for wrong transactions, PR #1374
- Fix several internal todos, PR #1375
Dependencies, CI and Docs
- Add hardhat e2e test integration, PR #1348
This release integrates a Common library version which provides the london HF blocks for all networks including mainnet and is therefore the first release with finalized London HF support.
Source files from the src folder are now included in the distribution build, see PR #1301. This allows for a better debugging experience in debug tools like Chrome DevTools by having working source map references to the original sources available for inspection.
- Improved browser compatibility by replacing
instanceofcalls on tx objects with functionality checks, PR #1315
- BlockBuilder: allow customizable baseFeePerGas, PR #1326
This release comes with some additional EIP-1559 checks and functionality:
- Additional 1559 check in
VM.runTx()that the tx sender balance must be >= gas_limit * max_fee_per_gas, PR #1272 - Additional 1559 check in
VM.runTx()to ensure that the user was willing to at least pay the base fee (transaction.max_fee_per_gas >= block.base_fee_per_gas), PR #1276 - 1559 support for the BlockBuilder (
VM.buildBlock()) by setting the new block'sbaseFeePerGastoparentBlock.header.calcNextBaseFee(), PR #1280
This VM release comes with full functional support for the london hardfork (all EIPs are finalized and integrated and london HF can be activated, there are no final block numbers for the HF integrated though yet). Please note that the default HF is still set to istanbul. You therefore need to explicitly set the hardfork parameter for instantiating a VM with the london HF activated:
import VM from '@ethereumjs/vm'
import Common from '@ethereumjs/common'
const common = new Common({ chain: 'mainnet', hardfork: 'london' })
const vm = new VM({ common })Support for the following EIPs has been added:
- EIP-1559: Fee market change for ETH 1.0 chain, PR #1148
- EIP-3198: BASEFEE opcode, PR #1148
- EIP-3529: Reduction in refunds, PR #1239
- EIP-3541: Reject new contracts starting with the 0xEF byte, PR #1240
It is also possible to run these EIPs in isolation by instantiating a berlin common and activate selected EIPs with the eips option:
const common = new Common({ chain: 'mainnet', hardfork: 'berlin', eips: [3529] })The VM can now run EIP-1559 compatible blocks (introduced with the @ethereumjs/block v3.3.0 release) with VM.runBlock() as well as EIP-1559 txs with type 2 (introduced along the @ethereumjs/tx v3.2.0 release), which can now be passed to VM.runTx() as the tx to be executed. Block and tx validation is happening accordingly and the gas calculation takes the new gas fee market parameters from the block (baseFeePerGas) and the tx(s) (maxFeePerGas and maxPriorityFeePerGas instead of a gasPrice) into account.
There is a new opcode BASEFEE added to the VM, see PR #1148. This opcode is active starting with london and returns the base fee of the current executed upon block.
EIP-3529 removes gas refunds for SELFDESTRUCT, and reduces gas refunds for SSTORE, an implementation has been done in PR #1239.
There is a new EVM Object Format (EOF) in preparation which will allow to validate contracts at deploy time. This EIP is a preparation for the introduction of this format and disallows contracts which start with the 0xEF byte. Contracts created in the VM via create transaction, CREATE or CREATE2 starting with this byte are now rejected when the EIP is activated and an INVALID_BYTECODE_RESULT is returned as an EVM error with the result, see PR #1240.
This VM release bumps the merkle-patricia-tree dependency to v4.2.0, which is used as a datastore for the default StateManager implementation. The new MPT version switches to a default behavior to not delete any trie nodes on checkpoint commits, which has implications on the StateManager.commit() function which internally calls the MPT commit. This allows to go back to older trie states by setting a new (old) state root with StateManager.setStateRoot(). The trie state is now guaranteed to still be consistent and complete, which has not been the case before and lead to erroneous behaviour in certain usage scenarios (e.g. reported by HardHat).
See PR #1262
In former versions of the VM non-VM errors happing inside the VM have been (unintentionally) shielded by a try / catch clause in the VM Interpreter class. This lead to existing bugs being hidden and channeled through as VM errors, which made it extremely difficult to trace such bugs down to the root cause. These kind of errors are now properly propagated and therefore lead to a break of the VM control flow. Please note that this might lead to your code breaking if you have got an error in your implementation (this should be a good this though since now this bug can finally be fixed 😀 ).
See PR #1168
- StateManager: fixed buffer comparison in
setStateRoot(), PR #1212
- New
blockGasUsedoption forVM.runTx()allowing to provide the block gas used up until the tx to be executed to obtain an accurate tx receipt, PR #1264 StateManager.getStateRoot()is not throwing any more on uncommitted checkpoints, PR #1216
This is a hot-fix performance release, removing the debug functionality from PR #1080 and follow-up PRs. While highly useful for debugging, this feature side-introduced a significant reduction in VM performance which went along unnoticed. For now we will remove since upstream dependencies are awaiting a new release before the Berlin HF happening. We will try to re-introduce in a performance friendly manner in some subsequent release (we cannot promise on that though).
See PR #1198.
Features
- Added
receipttoRunTxResult, moved the tx receipt generation logic fromVM.runBlock()toVM.runTx()(generateTxReceipt()and receipt exports inrunBlockare now marked as deprecated), PR #1185
Bug Fixes
- Fixed BlockBuilder (see
v5.3.0release) to allow building a block with zero txs, PR #1185 - BlockBuilder: Moves the
stateManager.committo after putting the block in blockchain in case it throws on validating, PR #1185
Testing
- Added test cases for legacy and access list transactions to
VM.runBlock()tests, PR #1185 - Added type safety test (thanks to @alcuadrado from Hardhat for this code magic piece ❤️), PR #1185
This release adds the ability to generate access lists from tx runs with VM.runTx(), see PR #1170. There is a new option reportAccessList which can be used on all tx types to generate an access list as defined by EIP-2930 which is then returned along the VM.runTx() result adhering to the @ethereumjs/tx AccessList TypeScript type definition.
Note that this functionality needs the new StateManager.generateAccessList() function which is not yet part of the StateManager interface for compatibility reasons. If you implement an own StateManager make sure that this function is present (e.g. by inheriting your StateManager from the DefaultStateManager implementation).
Another note: there is an edge case on accessList generation where an internal call might revert without an accessList but pass if the accessList is used for a tx run (so the subsequent behavior might change). This edge case is not covered by this implementation.
There is a new Block Builder API for creating new blocks on top of the current state by adding transactions one at a time, see PR #1158.
It can be used like the following:
const blockBuilder = await vm.buildBlock({ parentBlock, blockData, blockOpts })
const txResult = await blockBuilder.addTransaction(tx)
// reset the state with `blockBuilder.revert()`
const block = await blockBuilder.build()When the block is built it becomes fully executed in the vm and its blockchain.
- Fixed
VM.runBlock()withgenerate: trueby setting the header fields forgasUsed,logsBloom,receiptTrie, andtransactionsTrie, PR #1158 - Fixed a bug in
VM.runTx()withreportAccessList=truereturning addresses without a0xprefix, PR #1183 - Do not include the tx sender address in the access list in
VM.runTx()withreportAccessList=true, only include thetoaddress if storage slots have been touched, PR #1183
This release is the first VM release with official berlin HF support. All EthereumJS dependencies are updated with berlin enabling versions and support for all EIPs which finally made it into berlin has been added, namely:
- EIP-2565: ModExp gas cost
- EIP-2718: Typed transactions
- EIP-2929: Gas cost increases for state access opcodes
- EIP-2930: Optional Access Lists Typed Transactions
Please note that the default HF is still set to istanbul. You therefore need to explicitly set the hardfork parameter for instantiating a VM instance with a berlin HF activated:
import VM from '@ethereumjs/vm'
import Common from '@ethereumjs/common'
const common = new Common({ chain: 'mainnet', hardfork: 'berlin' })
const vm = new VM({ common })There is a relatively broad set of changes since the last VM version v5.1.0 introducing support for a first set of to-be-expected berlin EIPs, here is a summary:
The VM is now prepared to work with Typed Transactions (EIP2718) which have been introduced along the @ethereumjs/tx v3.1.0 release. It now therefore gets possible to pass typed txs to VM.runTx() respectively a block containing typed txs to VM.runBlock(), see PR #1048 and PR #1138.
There is a first concrete tx type 1 including optional access lists added along the berlin HF (EIP2930). Access lists are now properly detected by the VM and gas costs calculated accordingly.
Our implementation of EIP-2929 (gas cost increases for state access opcodes) was falling short in the form that warm storage slots / addresses were only tracked per internal message, not on the entire transaction as implied by the EIP. This needed a relatively intense rework along PR #1124. We are now confident in the implementation and official tests are passing.
Along with this rework a new StateManager interface EIP2929StateManager has been introduced which inherits from StateManager and adds the following methods:
export interface EIP2929StateManager extends StateManager {
addWarmedAddress(address: Buffer): void
isWarmedAddress(address: Buffer): boolean
addWarmedStorage(address: Buffer, slot: Buffer): void
isWarmedStorage(address: Buffer, slot: Buffer): boolean
clearWarmedAccounts(): void
}The StateManager base interface and the inherited EIP2929StateManager interface will be merged again on the next breaking release.
EIP-2315 has been removed from the list of EIPs included in berlin. This is ensured by using a Common dependency version v2.2.0+ containing the final list of Berlin EIPs and also needed some changes in the VM code, see PR #1142.
If you are using this library in conjunction with other EthereumJS libraries make sure to minimally have the following library versions installed for typed transaction support:
@ethereumjs/commonv2.2.0@ethereumjs/txv3.1.0@ethereumjs/blockv3.2.0@ethereumjs/blockchainv5.2.0@ethereumjs/vmv5.2.0
{ stateRoot, gasUsed, logsBloom, receiptRoot }have been added toRunBlockResultand will be emitted withafterBlock, PR #853- Added
vm:eei:gasEEI gas debug logger, PR #1124
- Fixes VM Node 10 support being broken due to the usage of
globalThisfor browser detection, PR #1151 - Fixed
ECRECOVERprecompile to work correctly on networks with very large chain IDs, PR #1139
CI and Test Improvements
- Benchmark improvements and fixes, PR #853
This release introduces Clique/PoA support, see the main PR #1032 as well as the follow-up PRs #1074 and PR #1088. This means that you now can run a VM with blocks or transactions from the main PoA networks Goerli and Rinkeby and generally can use the VM in a Clique/PoA context.
Here is a simple example:
import VM from '@ethereumjs/vm'
import Common from '@ethereumjs/common'
const common = new Common({ chain: 'goerli' })
const hardforkByBlockNumber = true
const vm = new VM({ common, hardforkByBlockNumber })
const serialized = Buffer.from('f901f7a06bfee7294bf4457...', 'hex')
const block = Block.fromRLPSerializedBlock(serialized, { hardforkByBlockNumber })
const result = await vm.runBlock(block)All the corresponding internal dependencies have been updated to Clique/PoA supporting versions, namely:
- @ethereumjs/block ->
v3.1.0 - @ethereumjs/blockchain ->
v5.1.0 - @ethereumjs/common" ->
v2.1.0
Note that you need to also use library versions equal or higher than the ones mentioned above when you pass in an instance from one of the libraries to an API call (e.g. VM.runBlock(), see example above) to ensure everything is working properly in a Clique/PoA context.
New VM behavior in a Clique/PoA context:
VM.runBlock(): If you do block validation along block runs blocks are now validated to comply with the various Clique/PoA block format specifications (variousextraDatachecks e.g.)VM.runBlock(): There is no assignment of block rewards to thecoinbaseaccount taking placeVM.runTx(): Tx fees are attributed to the block signer instead of thecoinbaseaccountCOINBASEopcode: TheCOINBASEopcode returns the block signer instead of thecoinbaseaddress (Clique specification)
This is the first release which reliably exposes performance gains on all checkpointing operations by integrating the respective merkle-patricia-trie v4.1.0 where the checkpointing mechanism has been reworked substantially.
This leads to linearly growing performance gains on all checkpointing operations (in VM.runBlock(), VM.runTx() as well as along all message calls) along with the size of the trie (state) being operated upon. In practice we have seen 10-50x increases when working on blocks from mainnet or the other test networks.
We would be happy on some feedback if this integration is noticeable in your execution context! 😀
This release adds support for EIP 2565, ModExp precompile gas cost, which is planned to be included in the Berlin hardfork, see PR #1026.
The VM now comes with an integrated debug logger which gives you fine-grained control to display selected log output along the VM execution flow, see PR #1080. These loggers use the debug library and can be activated on the CL with DEBUG=[Logger Selection] node [Your Script to Run].js and produce output like the following:
For an overview on the different loggers available see the respective README section.
- The
afterBlock(VM.runBlock()) andafterTx(VM.runTx()) events now expose the respective block or transaction in the event results, PR #965 - New
hardforkByBlockNumberVM constructor option forVM.runBlock()runs (see also correspondingBlockoption), PR #966 and #967 (option renamed along release PR) - Added new optional
maxBlocksoption toVM.runBlockchain(), PR #1025 VM.runBlockchain()now returns the number of actual blocks run (needsBlockchainv5.1.0or higher,voidkept inTypeScriptfunction signature for backwards-compatibility), PR #1065- New option
skipBlockGasLimitValidationto disable the block gas limit check inVM.runTx(), PR #1039 - Added type definition
Logfor logs inTxReceiptitems returned (result ofVM.runBlocks()andafterBlockevent), PR #1084
- Consensus: fixed
Frontierconsensus bug alongCREATEwith not enough gas, PR #1081 - Update opcodes along HF switches, added a dedicated
tangerineWhistleopcode list (no need for calls toVM._updateOpcodes()on HF switches manually any more), PR #1101 and #1112 - Use
commonfrom VM when creating default blocks inVM.runCall()andVM.runCode(), PR #1011 - Fixed a bug when the result of the
MODEXPopcode is 0, PR #1026
- Updated
run-solidity-contractexample, PR #1104 - Updated
ethereum/testssubmodule to1fcd4e5(2021-02-02), PR #1116 - Only expose API method on docs, PR #1119
Attention! This new version is part of a series of EthereumJS releases all moving to a new scoped package name format. In this case the library is renamed as follows:
ethereumjs-vm->@ethereumjs/vm
Please update your library references accordingly or install with:
npm i @ethereumjs/vmThis is the first release of the VM which supports all hardforks currently applied on mainnet starting with the support of the Frontier HF rules all along up to MuirGlacier. 🎉
The following HFs have been added:
- Spurious Dragon, PR #791
- Tangerine Whistle, PR #807
- DAO, PR #843
- Homestead, PR #815
- Frontier, PR #828
A VM with the specific HF rules (on the chain provided) can be instantiated by passing in a Common instance:
import VM from '@ethereumjs/vm'
import Common from '@ethereumjs/common'
const common = new Common({ chain: 'mainnet', hardfork: 'spuriousDragon' })
const vm = new VM({ common })Breaking: The default HF from the VM has been updated from petersburg to istanbul. The HF setting is now automatically taken from the HF set for Common.DEFAULT_HARDFORK, see PR #906.
Breaking: Please note that the options to directly pass in chain and hardfork strings have been removed to simplify the API. Providing a Common instance is now the only way to change the chain setup, see PR #863
This releases adds support for subroutines (EIP-2315) which gets activated under the berlin HF setting which can now be used as a hardfork instantiation option, see PR #754.
Attention! Berlin HF support is still considered experimental and implementations can change on non-major VM releases!
Support for BLS12-381 precompiles (EIP-2537) is added as an independent EIP implementation - see PR #785 - since there is still an ongoing discussion on taking this EIP in for Berlin or using a more generalized approach on curve computation with the Ethereum EVM (evm384 by the eWASM team).
Another new EIP added is the EIP-2929 with gas cost increases for state access opcodes, see PR #889.
These integrations come along with an API addition to the VM to support the activation of specific EIPs, see PR #856, PR #869 and PR #872.
This API can be used as follows:
import Common from '@ethereumjs/common'
import VM from '@ethereumjs/vm'
const common = new Common({ chain: 'mainnet', eips: [2537] })
const vm = new VM({ common })The following EthereumJS libraries which are used within the VM internally and can be passed in on instantiation have been updated to new major versions.
merkle-patricia-treev3(VM optionstate) ->merkle-patricia-treev4, PR #787ethereumjs-blockchainv4->@ethereumjs/blockchainv5, PR #833ethereumjs-commonv1->@ethereumjs/commonv2
Breaking: If you pass in instances of these libraries to the VM please make sure to update these library versions as stated. Please also take a note on the package name changes!
All these libraries are now written in TypeScript and use promises instead of callbacks for accessing their APIs.
There is now a new TypeScript interface for the StateManager, see PR #763. If you are
using a custom StateManager you can use this interface to get better assurance that you are using a StateManager which conforms with the current StateManager API and will run in the VM without problems.
The integration of this new interface is highly encouraged since this release also comes with StateManager API changes. Usage of the old
ethereumjs-account package (this package will be retired) has been replaced by the new
Account class from the ethereumjs-util package. This affects all Account related StateManager methods, see PR #911.
The Util package also introduces a new Address class. This class replaces all current Buffer inputs on StateManager methods representing an address.
We significantly updated our internal tool and CI setup along the work on PR #913 with an update to ESLint from TSLint for code linting and formatting and the introduction of a new build setup.
Packages now target ES2017 for Node.js builds (the main entrypoint from package.json) and introduce a separate ES5 build distributed along using the browser directive as an entrypoint, see PR #921. This will result in performance benefits for Node.js consumers, see here for a related discussion.
Changes and Refactoring
- Group opcodes based upon hardfork, PR #798
- Split opcodes logic into codes, fns, and utils files, PR #896
- Group precompiles based upon hardfork, PR #783
- Breaking: the
stepevent now emits anethereumjs-utilAccount object instead of an ethereumjs-account (package retired) object - Breaking:
NewContractEventnow emits anaddressof typeAddress(seeethereumjs-util) instead of aBuffer, PR #919 - Breaking:
EVMResultnow returns acreatedAddressof typeAddress(seeethereumjs-util) instead of aBuffer, PR #919 - Breaking:
RunTxResultnow returns acreatedAddressof typeAddress(seeethereumjs-util) instead of aBuffer, PR #919 - Breaking:
RunCallOptsnow expectsorigin,callerandtoinputs to be of typeAddress(seeethereumjs-util) instead of aBuffer, PR #919 - Breaking:
RunCodeOptsnow expectsorigin,callerandaddressinputs to be of typeAddress(seeethereumjs-util) instead of aBuffer, PR #919 - Visibility cleanup (Renaming and/or code docs additions) for class members not being part of the API, PR #925
- Make
memory.tsuse Buffers instead of Arrays, PR #850 - Use
MapforOpcodeListandopcodehandlers, PR #852 - Compare buffers directly, PR #851
- Moved gas base fees from VM to Common, PR #806
- Return precompiles on
getPrecompile()based on hardfork, PR #783 - Removed
asyncdependency, PR #779 - Updated
ethereumjs-utilto v7, PR #748
CI and Test Improvements
- New benchmarking tool for the VM, CI integration on GitHub actions, PR #794 and PR #830
- Various updates, fixes and refactoring work on the test runner, PR #752 and PR #849
- Integrated
ethereumjs-testingcode logic into VM for more flexible future test load optimizations, PR #808 - Transition VM tests to TypeScript, PR #881 and PR #882
- On-demand state and blockchain test runs for all hardforks triggered by PR label, PR #951
- Dropped
ethereumjs-testingdev dependency, PR #953
Bug Fixes
- Fix
activatePrecompiles, PR #797 - Strip zeros when putting contract storage in StateManager, PR #880
- Two bug fixes along
istanbulSSTOREgas calculation, PR #870 - Security fixes by
mcl-wasmpackage dependency update, PR #955
This is the first release candidate towards a final library release, see beta.2 and especially beta.1 release notes for an overview on the full changes since the last publicly released version.
- Security fixes by
mcl-wasmpackage dependency update, PR #955 - On-demand state and blockchain test runs for all hardforks triggered by PR label, PR #951
- Dropped
ethereumjs-testingdev dependency, PR #953
This is the second beta release towards a final library release, see beta.1 release notes for an overview on the full changes since the last publicly released version.
- Fixed
SSTOREgas calculation onconstantinople, PR #931 - Visibility cleanup (Renaming and/or code docs additions) for class members not being part of the API, PR #925
Attention! This new version is part of a series of EthereumJS releases all moving to a new scoped package name format. In this case the library is renamed as follows:
ethereumjs-monorepo->@ethereumjs/vm
Please update your library references accordingly or install with:
npm i @ethereumjs/vmThis is the first release of the VM which supports all hardforks currently applied on mainnet starting with the support of the Frontier HF rules all along up to MuirGlacier. 🎉
The following HFs have been added:
- Spurious Dragon, PR #791
- Tangerine Whistle, PR #807
- DAO, PR #843
- Homestead, PR #815
- Frontier, PR #828
A VM with the specific HF rules (on the chain provided) can be instantiated
by passing in a Common instance:
import VM from '@ethereumjs/vm'
import Common from '@ethereumjs/common'
const common = new Common({ chain: 'mainnet', hardfork: 'spuriousDragon' })
const vm = new VM({ common })Breaking: The default HF from the VM has been updated from petersburg to istanbul.
The HF setting is now automatically taken from the HF set for Common.DEFAULT_HARDFORK,
see PR #906.
Breaking: Please note that the options to directly pass in
chain and hardfork strings have been removed to simplify the API.
Providing a Common instance is now the only way to change
the chain setup, see PR #863
This releases adds support for subroutines (EIP-2315) which gets
activated under the berlin HF setting which can now be used
as a hardfork instantiation option, see
PR #754.
Attention! Berlin HF support is still considered experimental and implementations can change on non-major VM releases!
Support for BLS12-381 precompiles (EIP-2537) is added as an independent EIP
implementation - see PR #785 -
since there is still an ongoing discussion on taking this EIP in for Berlin or
using a more generalized approach on curve computation with the Ethereum EVM
(evm384 by the eWASM team).
Another new EIP added is the EIP-2929 with gas cost increases for state access
opcodes, see PR #889.
These integrations come along with an API addition to the VM to support the activation of specific EIPs, see PR #856, PR #869 and PR #872.
This API can be used as follows:
import Common from '@ethereumjs/common'
import VM from '@ethereumjs/vm'
const common = new Common({ chain: 'mainnet', eips: [2537] })
const vm = new VM({ common })The following EthereumJS libraries which are used within the VM internally
and can be passed in on instantiation have been updated to new major versions.
merkle-patricia-treev3(VM optionstate) ->merkle-patricia-treev4, PR #787ethereumjs-blockchainv4->@ethereumjs/blockchainv5, PR #833ethereumjs-commonv1->@ethereumjs/commonv2
Breaking: If you pass in instances of these libraries to the VM please make sure to update these library versions as stated. Please also take a note on the package name changes!
All these libraries are now written in TypeScript and use promises instead of
callbacks for accessing their APIs.
There is now a new TypeScript interface for the StateManager, see
PR #763. If you are
using a custom StateManager you can use this interface to get better
assurance that you are using a StateManager which conforms with the current
StateManager API and will run in the VM without problems.
The integration of this new interface is highly encouraged since this release
also comes with StateManager API changes. Usage of the old
ethereumjs-account package
(this package will be retired) has been replaced by the new
Account class
from the ethereumjs-util package. This affects all Account related
StateManager methods, see PR #911.
The Util package also introduces a new
Address class.
This class replaces all current Buffer inputs on StateManager methods representing an address.
We significantly updated our internal tool and CI setup along the work on
PR #913 with an update to ESLint from TSLint
for code linting and formatting and the introduction of a new build setup.
Packages now target ES2017 for Node.js builds (the main entrypoint from package.json) and introduce
a separate ES5 build distributed along using the browser directive as an entrypoint, see
PR #921. This will result
in performance benefits for Node.js consumers, see here for a related discussion.
Changes and Refactoring
- Group opcodes based upon hardfork, PR #798
- Split opcodes logic into codes, fns, and utils files, PR #896
- Group precompiles based upon hardfork, PR #783
- Breaking: the
stepevent now emits anethereumjs-utilAccount object instead of an ethereumjs-account (package retired) object - Breaking:
NewContractEventnow emits anaddressof typeAddress(seeethereumjs-util) instead of aBuffer, PR #919 - Breaking:
EVMResultnow returns acreatedAddressof typeAddress(seeethereumjs-util) instead of aBuffer, PR #919 - Breaking:
RunTxResultnow returns acreatedAddressof typeAddress(seeethereumjs-util) instead of aBuffer, PR #919 - Breaking:
RunCallOptsnow expectsorigin,callerandtoinputs to be of typeAddress(seeethereumjs-util) instead of aBuffer, PR #919 - Breaking:
RunCodeOptsnow expectsorigin,callerandaddressinputs to be of typeAddress(seeethereumjs-util) instead of aBuffer, PR #919 - Make
memory.tsuse Buffers instead of Arrays, PR #850 - Use
MapforOpcodeListandopcodehandlers, PR #852 - Compare buffers directly, PR #851
- Moved gas base fees from VM to Common, PR #806
- Return precompiles on
getPrecompile()based on hardfork, PR #783 - Removed
asyncdependency, PR #779 - Updated
ethereumjs-utilto v7, PR #748
CI and Test Improvements
- New benchmarking tool for the VM, CI integration on GitHub actions, PR #794 and PR #830
- Various updates, fixes and refactoring work on the test runner, PR #752 and PR #849
- Integrated
ethereumjs-testingcode logic into VM for more flexible future test load optimizations, PR #808 - Transition VM tests to TypeScript, PR #881 and PR #882
Bug Fixes
- Fix
activatePrecompiles, PR #797 - Strip zeros when putting contract storage in StateManager, PR #880
- Two bug fixes along
istanbulSSTOREgas calculation, PR #870
Additions
- Add
codeAddressto VMsstepevent, PR #651 - Support for
skipNonceandskipBalancetx options inrunBlock, PR #663 - Add
init()method to prevent race conditions, PR #665
Removals
- Remove
PStateManager(StateManagernow uses Promises by default), PR #719
Bug Fixes
- Explicitly duplicate EVMs stack items to ensure these do not get accidentally modified internally, PR #733
Other changes
- Refactor opcodes, PR #664
4.1.3 - 2020-01-09
This release fixes a critical bug preventing the MuirGlacier release 4.1.2
working properly, an update is mandatory if you want a working installation.
Bug Fixes
- Fixed
getOpcodesForHF()opcode selection for any HF > Istanbul, PR #647
Test Related Changes
- Switched from
CoverallstoCodecov(monorepo preparation, coverage reports on PRs), PR #646 - Added nightly
StateTestsruns, PR #639 - Run consensus tests on
MuirGlacier, PR #648
4.1.2 - 2019-12-19 [DEPRECATED]
Deprecation Notice: This is a broken release containing a critical bug
affecting all installations using the MuirGlacier HF option. Please update
to the 4.1.3 release.
Release adds support for the MuirGlacier hardfork by updating relevant
dependencies:
ethereumjs-tx: v2.1.2ethereumjs-block: v2.2.2ethereumjs-blockchain: v4.0.3ethereumjs-common: v1.5.0
Other changes:
- Upgraded
ethereumjs-utiltov6.2.0, PR #621 - Removed outdated cb param definition in
runBlockchain, PR #623 - Properly output zero balance in
examples/run-transactions-complete, PR #624
4.1.1 - 2019-11-19
First stable Istanbul release passing all StateTests and BlockchainTests
from the official Ethereum test suite
v7.0.0-beta.1.
Test suite conformance have been reached along work on
PR #607 (thanks @s1na!)
and there were several fixes along the way, so it is strongly recommended that
you upgrade from the first beta Istanbul release v4.1.0.
Istanbul Related Fixes
- Refund counter has been moved from the
EEIto theEVMmodule, PR #612,gasRefundis re-added to theexecResultin theEVMmodule at the end of message execution inEVMto remain (for the most part) backwards-compatible in the release - Fixed
blake2fprecompile for rounds >0x4000000 - Fixed issues causing
RevertPrecompiled*test failures - Fixed an issue where the
RIPEMDprecompile has to remain touched even when the call reverts and be considered for deletion, see EIP issue #716 for context - Updated
ethereumjs-blocktov2.2.1 - Updated
ethereumjs-blockchaintov4.0.2 - Limited
ethereumjs-utilfrom^6.1.0to~6.1.0 - Hardfork-related fixes in test runners and test utilities
Other Changes
- Introduction of a new caching mechanism to cache calls towards
promisifybeing present in hot paths (performance optimization), PR #600 - Renamed some missing
result.returntoresult.returnValueonEVMexecution in examples, PR #604 - Improved event documentation, PR #601
4.1.0 - 2019-09-12
This is the first feature-complete Istanbul release, containing implementations
for all 6 EIPs, see the HF meta EIP EIP-1679
for an overview. Beside this release contains further unrelated features as
well as bug fixes.
Note that Istanbul support is still labeled as beta. All implementations
have only basic test coverage since the official Ethereum consensus tests are
not yet merged. There might be also last minute changes to EIPs during the
testing period.
Istanbul Summary
See the VM Istanbul hardfork meta issue
#501 for a summary
on all the changes.
Added EIPs:
- EIP-152: Blake 2b
Fprecompile, PR #584 - EIP-1108: Reduce
alt_bn128precompile gas costs,
PR #540 (already released inv4.0.0) - EIP-1344: Add ChainID Opcode, PR #572
- EIP-1884: Trie-size-dependent Opcode Repricing, PR #581
- EIP-2200: Rebalance net-metered SSTORE gas costs, PR #590
Other Features
- Two new event types
beforeMessageandafterMessage, emitting aMessagebefore and anEVMResultafter running aMessage, see also the updated section in theREADMEon this, PR #577
Bug Fixes
- Transaction error strings should not contain multiple consecutive whitespace characters, this has been fixed, PR #578
- Fixed
vm.stateManager.generateCanonicalGenesis()to produce a correct genesis block state root (in particular for theGoerlitestnet), PR #589
Refactoring / Docs
- Preparation for separate lists of opcodes for the different HFs, PR #582, see also follow-up PR #592 making this list a property of the VM instance
- Clarification in the docs for the behavior of the
activatePrecompilesVM option, PR #595
4.0.0 - 2019-08-06
First TypeScript based VM release, other highlights:
- New Call and Code Loop Structure / EVM Encapsulation
- EEI for Environment Communication
- Istanbul Process Start
- Promise-based API
See v4.0.0-beta.1 release for full release notes.
Changes since last beta
- Simplification of execution results, PR #551
- Fix error propagation in
Cache.flush()method fromStateManager, PR #562 StateManagerstorage key length validation (now throws on addresses not having a 32-byte length), PR #565
4.0.0-beta.1 - 2019-06-19
Since changes in this release are pretty deep reaching and broadly distributed,
we will first drop out one or several beta releases until we are confident on
both external API as well as inner structural changes. See
v4 branch for some
major entry point into the work on the release.
It is highly recommended that you do some testing of your library against this
and following beta versions and give us some feedback!
These will be the main release notes for the v4 feature updates, subsequent
beta releases and the final release will just publish the delta changes and
point here for reference.
Breaking changes in the release notes are preceded with [BREAKING], do a
search for an overview.
The outstanding work of @s1na has to be mentioned here. He has done the very large portion of the coding and without him this release wouldn't have been possible. Thanks Sina! 🙂
So what's new?
This is the first TypeScript release of the VM (yay! 🎉).
TypeScript handles ES6 transpilation
a bit differently (at the
end: cleaner) than babel so require syntax of the library slightly changes to:
const VM = require('ethereumjs-monorepo').defaultThe library now also comes with type declaration files distributed along with the package published.
- Preparation, migration of
Bloom,StackandMemory, PR #495 StateManagermigration, PR #496- Migration of precompiles, opcode list,
EEI,Message,TxContexttoTypeScript, PR #497 - Migration of
EVM(old:Interpreter) and exceptions, PR #504 - Migration of
Interpreter(old:Loop), PR #505 - Migration of
opFns(opcode implementations), PR #506 - Migration of the main
index.jsVMclass, PR #507 - Migration of
VM.runCode(), PR #508 - Migration of
VM.runCall(), PR #510 - Migration of
VM.runTx(), PR #511 - Migration of
VM.runBlock(), PR #512 - Migration of
VM.runBlockchain(), PR #517 TypeScriptfinalization PR, config switch, PR #518- Doc generation via
TypeDoc, PR #522
This release switches to a new class based and promisified structure for
working down VM calls and running through code loops, and encapsulates this
logic to be bound to the specific EVM (so the classical Ethereum Virtual Machine)
implementation in the
evm module,
opening the way for a future parallel eWASM additional implementation.
This new logic is mainly handled by the two new classes EVM (old: Interpreter)
and Interpreter (old: Loop),
see PR #483
for the initial work on this. The old VM.runCall() and VM.runCode()
methods are just kept as being wrappers and will likely be deprecated on future
releases once the inner API structure further stabilizes.
This new structure should make extending the VM by subclassing and
adopting functionality much easier, e.g. by changing opcode functionality or adding
custom onces by using an own Interpreter.getOpHandler() implementation. You are
highly encouraged to play around, see what you can do and give us feedback on
possibilities and limitations.
For interacting with the blockchain environment there has been introduced a
dedicated EEI (Ethereum Environment Interface) module closely resembling the
respective
EEI spec, see
PR #486 for the initial
work.
This makes handling of environmental data by the VM a lot cleaner and transparent and should as well allow for much easier extension and modification.
- Detached precompiles from the VM, PR #492
- Subdivided
runState, refactoredInterpreter(old:Loop), PR #498 - [BREAKING] Dropped
emitFreeLogsflag, to replace it is suggested to implement by inheritingInterpreter(old:Loop), PR #498 - Split
EVM.executeMessage()withEVM.executeCall()andEVM.executeCreate()forcallandcreatespecific logic (old names:Interpreter.[METHOD_NAME]()), PR #499 - Further simplification of
Interpreter/EVM(old:Loop/Interpreter) structure, PR #506 - [BREAKING] Dropped
VM.runJit()in favor of direct handling inEVM(old:Interpreter), officially not part of the external API but mentioning just in case, PR #515 - Removed
StorageReader, moved logic toStateManager, #534
With this release we start the Istanbul hardfork integration process and
have activated the istanbul hardfork option for the constructor.
This is meant to be used experimentation and reference implementations, we have made
a start with integrating draft EIP-1108
Istanbul candidate support reducing the gas costs for alt_bn128 precompiles,
see PR #539 for
implementation details.
Note that this is still very early in the process since no EIP in a final
state is actually accepted for being included into Istanbul on the time of
release. The v4 release series will be kept as an experimental series
during the process with breaking changes introduced along the way without too
much notice, so be careful and tighten the VM dependency if you want to give
your users the chance for some early experimentation with some specific
implementation state.
Once scope of Istanbul as well as associated EIPs are finalized a stable
Istanbul VM version will be released as a subsequent major release.
The main API with the v4 release switches from being callback based to
using promises,
see PR #546.
Here is an example for changed API call runTx.
Old callback-style invocation:
vm.runTx(
{
tx: tx,
},
function (err, result) {
if (err) {
// Handle errors appropriately
}
// Do something with the result
},
)Promisified usage:
try {
let result = await vm.runTx({ tx: tx })
// Do something with the result
} catch (err) {
// handle errors appropriately
}- Promisified internal usage of async opcode handlers, PR #491
- Promisified
runTxinternals, PR #493 - Promisified
runBlockinternals, restructure, reduced shared global state, PR #494
- Updated
ethereumjs-accountfrom2.xto3.x, part of PR #496
- Fixed error message in
runTx(), PR #523 - Changed default hardfork in
StateManagertopetersburg, PR #524 - Replaced
Object.assign()calls and fixed type errors, PR #529
- Significant blockchain test speed improvements, PR #536
3.0.0 - 2019-03-29
This release comes with a modernized ES6-class structured code base, some
significant local refactoring work regarding how Stack and Memory
are organized within the VM and it finalizes a first round of module structuring
now having separate folders for bloom, evm and state related code. The
release also removes some rarely used parts of the API (hookedVM, VM.deps).
All this is to a large extend preparatory work for a v4.0.0 release which will
follow in the next months with TypeScript support and more system-wide
refactoring work leading to a more modular and expandable VM and providing the
ground for future eWASM integration. If you are interested in the release
process and want to take part in the refactoring discussion see the associated
issue #455.
VM Refactoring/Breaking Changes
- New
Memoryclass for evm memory manipulation, PR #442 - Refactored
Stackmanipulation in evm, PR #460 - Dropped
createHookedVm(BREAKING), being made obsolete by the newStateManagerAPI, PR #451 - Dropped
VM.depsattribute (please require dependencies yourself if you used this), PR #478 - Removed
fakeBlockchainclass and associated tests, PR #466 - The
petersburghardfork rules are now run as default (before:byzantium), PR #485
Modularization
- Renamed
vmmodule toevm, moveprecompilestoevmmodule, PR #481 - Moved
stateManager,storageReaderandcachetostatemodule, #443 - Replaced static VM
logTablewith dynamic inline version inEXPopcode, #450
Code Modernization/ES6
- Converted
VMtoES6class, PR #478 - Migrated
stateManagerandstorageReadertoES6class syntax, PR #452
Bug Fixes
- Fixed a bug where
stateManager.setStateRoot()didn't clear the_storageTriescache, PR #445 - Fixed longer output than return length in
CALLopcode, PR #454 - Use
BN.toArrayLike()instead ofBN.toBuffer()(browser compatibility), PR #458 - Fixed tx value overflow 256 bits, PR #471
Maintenance/Optimization
- Use
BNreduction context inMODEXPprecompile, PR #463
Documentation
- Fixed API doc types for
Bloomfilter methods, PR #439
Testing
- New Karma browser testing for the API tests, PRs #461, #468
- Removed unused parts and tests within the test setup, PR #437
- Fixed a bug using
--jsontrace flag in the tests, PR #438 - Complete switch to Petersburg on tests, fix coverage, PR #448
- Added test for
StateManager.dumpStorage(), PR #462 - Fixed
ecmul_0-3_5616_28000_96(by test setup adoption), PR #473
2.6.0 - 2019-02-07
Petersburg Support
Support for the Petersburg (aka constantinopleFix) hardfork by integrating
Petersburg ready versions of associated libraries, see also
PR #433:
ethereumjs-common(chain and HF logic and helper functionality) v1.1.0ethereumjs-blockchainv3.4.0ethereumjs-blockv2.2.0
To instantiate the VM with Petersburg HF rules set the opts.hardfork
constructor parameter to petersburg. This will run the VM on the new
Petersburg rules having removed the support for
EIP 1283.
Goerli Readiness
The VM is now also ready to execute on blocks from the final version of the
Goerli cross-client testnet and can
therefore be instantiated with opts.chain set to goerli.
Bug Fixes
- Fixed mixed
sync/asyncfunctions incache, PR #422 - Fixed a bug in
setStaterootand caching by clearing thestateManagercache after setting the state root such that stale values are not returned, PR #420 - Fixed cache access on the hooked VM (deprecated), PR #434
Refactoring
Following changes might be relevant for you if you are hotfixing/monkey-patching on parts of the VM:
- Moved
bloomto its own directory, PR #429 - Moved
opcodes,opFnsandlogTabletolib/vm, PR #425 - Converted
BloomtoES6class, PR #428 - Converted
CachetoES6class, added unit tests, PR 427
2.5.1 - 2019-01-19
- Added
memoryWordCountto thestepevent object, PR #405
- Fixed a bug which caused an overwrite of the passed state trie (
opts.state) when instantiating the library with theopts.activatePrecompilesoption, PR #415 - Fixed error handling in
runCode(in caseloadContractfails), PR #408 - Fixed a bug in the
StateManager.generateGenesis()function, PR #400
- Upgraded
ethereumjs-blockchainandlevelfor test runs, PR #414 - Fixed issue when running code coverage on PRs from forks, PR #402
2.5.0 - 2018-11-21
This is the first release of the VM with full support for all Constantinople EIPs. It further comes along with huge improvements on consensus conformity and introduces the Beta version of a new StateManager API.
For running the VM with Constantinople hardfork rules, set the option in the VM constructor opts.hardfork to constantinople. Supported hardforks are byzantium and constantinople, default setting will stay on byzantium for now but this will change in a future release.
Changes related to Constantinople:
- EIP 1283
SSTORE, see PR #367 - EIP 1014
CREATE2, see PR #329 - EIP 1052
EXTCODEHASH, see PR #324 - Constantinople ready versions of ethereumjs-block and ethereumjs-blockchain dependencies (difficulty bomb delay), see PRs #371, #325
This release is making a huge leap forward regarding consensus conformity, and even if you are not interested in Constantinople support at all, you should upgrade just for this reason. Some context: we couldn't run blockchain tests for a long time on a steady basis due to performance constraints and when we re-triggered a test run after quite some time with PR #341 the result was a bit depressing with over 300 failing tests. Thanks to joined efforts from the community and core team members we could bring this down far quicker than expected and this is the first release for a long time which practically comes with complete consensus conformity - with just three recently added tests failing (see skipBroken list in test/tester.js) and otherwise passing all blockchain tests and all state tests for both Constantinople and Byzantium rules. 🏆 🏆 🏆
Consensus Conformity related changes:
- Reset
selfdestructonREVERT, see PR #392 - Undo
Bloomfilter changes from PR #295, see PR #384 - Fixes broken
BLOCKHASHopcode, see PR #381 - Fix failing blockchain test
GasLimitHigherThan2p63m1, see PR #380 - Stop adding
accounttocachewhen checking if it is empty, see PR #375
The StateManager (lib/stateManager.js) - providing a high-level interface to account and contract data from the underlying state trie structure - has been completely reworked and there is now a close-to-being finalized API (currently marked as Beta) coming with its own documentation.
This comes along with larger refactoring work throughout more-or-less the whole code base and the StateManager now completely encapsulates the trie structure and the cache backend used, see issue #268 and associated PRs for reference. This will make it much easier in the future to bring along an own state manager serving special needs (optimized for memory and performance, run on mobile,...) by e.g. using a different trie implementation, cache or underlying storage or database backend.
We plan to completely separate the currently still integrated state manager into its own repository in one of the next releases, this will then be a breaking v3.0.0 release. Discussion around a finalized interface (we might e.g. drop all genesis-related methods respectively methods implemented in the DefaultStateManager) is still ongoing and you are very much invited to jump in and articulate your needs, just take e.g. the issue mentioned above as an entry point.
Change related to the new StateManager interface:
StateManagerinterface simplification, see PR #388- Make
StateManagercache and trie private, see PR #385 - Remove vm accesses to
StateManagertrieandcache, see PR #376 - Remove explicit direct cache interactions, see PR #366
- Remove contract specific commit, see PR #335
- Fixed incorrect references to
triein tests, see PR #345 - Added
StateManagerAPI documentation, see PR #393
- New
emitFreeLogsoption, allowing any contract to emit an unlimited quantity of events without modifying the block gas limit (default:false) which can be used in debugging contexts, see PRs #378, #379
Beyond the reintegrated blockchain tests there is now a separate test suite to test the API of the library, see test/api. This should largely reduce the risk of introducing new bugs on the API level on future changes, generally ease the development process by being able to develop against the specific tests and also allows using the tests as a reference for examples on how to use the API.
On the documentation side the API documentation has also been consolidated and there is now a unified and auto-generated API documentation (previously being manually edited (and too often forgotten) in README).
- Added API tests for
index.js,StateManager, see PR #364 - Added API Tests for
runJitandfakeBlockchain, see PR #331 - Added API tests for
runBlockchain, see PR #336 - Added
runBlockAPI tests, see PR #360 - Added
runTxAPI tests, see PR #352 - Added API Tests for the
Bloommodule, see PR #330 - New consistent auto-generated API documentation, see PR #377
- Blockchain tests now run by default on CI, see PR #374
- Switched from
istanbultonyc, see PR #334 - Usage of
sealEnginein blockchain tests, see PR #373 - New
tap-specoption to get a formatted test run result summary, see README, see PR #363 - Updates/fixes on the JSDoc comments, see PRs #362, #361
Some bug fix and maintenance updates:
Special thanks to:
- @mattdean-digicatapult for his indefatigable work on the new StateManager interface and for fixing a large portion of the failing blockchain tests
- @rmeissner for the work on Constantinople
- @vpulim for jumping in so quickly and doing a reliable
SSTOREimplementation within 4 days - @s1na for the new API test suite
Beyond this release contains contributions from the following people: @jwasinger, @Agusx1211, @HolgerD77, @danjm, @whymarrh, @seesemichaelj, @kn
Thank you all very much, and thanks @axic for keeping an ongoing eye on overall library quality!
2.4.0 - 2018-07-27
With the 2.4.x release series we now start to gradually add Constantinople features with the
bitwise shifting instructions from EIP 145
making the start being introduced in the v2.4.0 release.
Since both the scope of the Constantinople hardfork as well as the state of at least some of the EIPs
to be included are not yet finalized, this is only meant for EXPERIMENTAL purposes, e.g. for developer
tools to give users early access and make themselves familiar with dedicated features.
Once scope and EIPs from Constantinople are final we will target a v2.5.0 release which will officially
introduce Constantinople support with all the changes bundled together.
Note that from this release on we also introduce new chain (default: mainnet) and hardfork
(default: byzantium) initialization parameters, which make use of our new ethereumjs-common library and in the future will allow
for parallel hardfork support from Byzantium onwards.
Since hardfork default might be changed or dropped in future releases, you might want to explicitly
set this to byzantium on your next update to avoid future unexpected behavior.
All the changes from this release:
FEATURES/FUNCTIONALITY
- Improved chain and fork support, see PR #304
- Support for the
Constantinoplebitwise shifting instructionsSHL,SHRandSAR, see PR #251 - New
newContractevent which can be used to do interrupting tasks on contract/address creation, see PR #306 - Alignment of behavior of bloom filter hashing to go along with mainnet compatible clients BREAKING, see PR #295
UPDATES/TESTING
- Usage of the latest
rustbn.jsAPI, see PR #312 - Some cleanup in precompile error handling, see PR #318
- Some cleanup for
StateManager, see PR #266 - Renaming of
util.sha3usages toutil.keccak256and bumpethereumjs-utiltov5.2.0(you should do to if you useethereumjs-util) - Parallel testing of the
ByzantiumandConstantinoplestate tests, see PR #317 - For lower build times our CI configuration now runs solely on
CircleCIand support forTravishave been dropped, see PR #316
BUG FIXES
- Programmatic runtime errors in the VM execution context (within an opcode) are no longer absorbed and displayed as a VMError but explicitly thrown, allowing for easier discovery of implementation bugs, see PR #307
- Fix of the
Bloom.check()method not working properly, see PR #311 - Fix a bug when
REVERTis used within aCREATEcontext, see PR #297 - Fix a bug in
FakeBlockChainerror handing, see PR #320
2.3.5 - 2018-04-25
- Fixed
BYTEopcode return value bug, PR #293 - Clean up touched-accounts management in
StateManager, PR #287 - New
stateManager.copy()function, PR #276 - Updated Circle CI configuration to 2.0 format, PR #292
2.3.4 - 2018-04-06
- Support of external statemanager in VM constructor (experimental), PR #264
ES5distribution on npm for better toolchain compatibility, PR #281allowUnlimitedContractSizeVM option for debugging purposes, PR #282- Added
gasRefundto transaction results, PR #284 - Test coverage / coveralls support for the library, PR #270
- Properly calculate totalgas for large return values, PR #275
- Improve iterateVm check output after step hook, PR #279
2.3.3 - 2018-02-02
- Reworked memory expansion/access for opcodes, PR #174 (fixes consensus bugs on large numbers >= 53 bit for opcodes using memory location)
- Keep stack items as bn.js instances (arithmetic performance increases), PRs #159, #254 and #256
- More consistent VM error handling, PR #219
- Validate stack items after operations, PR #222
- Updated
ethereumjs-utildependency from4.5.0to5.1.x, PR #241 - Fixed child contract deletion bug, PR #246
- Fixed a bug associated with direct stack usage, PR #240
- Fix error on large return fees, PR #235
- Various bug fixes
2.3.2 - 2017-10-29
- Better handling of
rustbn.jsexceptions - Fake (default if non-provided) blockchain fixes
- Testing improvements (separate skip lists)
- Minor optimizations and bug fixes
2.3.1 - 2017-10-11
Byzantiumcompatible- New opcodes
REVERT,RETURNDATAandSTATICCALL - Precompiles for curve operations and bigint mod exp
- Transaction return data in receipts
- For detailed list of changes see PR #161
- For a
Spurious Dragon/EIP 150compatible version of this library install latest version of2.2.x
2.2.2 - 2017-09-19
- Fixed JS number issues and certain edge cases
- Fixed various smaller bugs and improved code consistency
- Some VM speedups
- Testing improvements
- Narrowed down dependencies for library not to break after Byzantium release
2.2.1 - 2017-08-04
- Fixed bug prevent the library to be used in the browser
2.2.0 - 2017-07-28
Spurious Dragon&EIP 150compatible- Detailed list of changes in pull requests #147 and #143
- Removed
enableHomesteadoption when creating a new VM object (pre-Homestead fork rules not supported any more)
2.1.0 - 2017-06-28
- Homestead compatible
- update state test runner for General State Tests