Hardhat's ethereumjs-vm fork
This is a fork of ethereumjs-vm
compiled with different options.
Go to this PR to learn more about them.
An Ethereum VM implementation
This is a fork of ethereumjs-vm
compiled with different options.
Go to this PR to learn more about them.
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 maintenance release preceding the v5.
API
skipNonce
and skipBalance
to the runBlock
function
PR #663codeAddress
to the step
event, allowing to have an address disambiguation when running DELEGATECALL
or CALLCODE
PR #651Fixes
level
dependency from ^4.0.0
to ^6.0.0
PR #662Internal
ts-node
PRs #654, #658This 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
getOpcodesForHF()
opcode selection for any HF > Istanbul,
PR #647Test Related Changes
Coveralls
to Codecov
(monorepo preparation, coverage
reports on PRs),
PR #646StateTests
runs,
PR #639MuirGlacier
,
PR #648Deprecation 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.0Other changes:
ethereumjs-util
to v6.2.0
,
PR #621runBlockchain
,
PR #623examples/run-transactions-complete
,
PR #624First 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
EEI
to the EVM
module,
PR #612, gasRefund
is re-added to the execResult
in the EVM
module at the end of message
execution in EVM
to remain (for the most part) backwards-compatible in the
releaseblake2f
precompile for rounds > 0x4000000
RevertPrecompiled*
test failuresRIPEMD
precompile has to remain touched even
when the call reverts and be considered for deletion,
see EIP issue #716 for contextethereumjs-block
to v2.2.1
ethereumjs-blockchain
to v4.0.2
ethereumjs-util
from ^6.1.0
to ~6.1.0
Other Changes
promisify
being present in hot paths (performance optimization),
PR #600result.return
to result.returnValue
on EVM
execution in examples,
PR #604This 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:
F
precompile,
PR #584alt_bn128
precompile gas costs,v4.0.0
)Other Features
beforeMessage
and afterMessage
, emitting a Message
before and an EVMResult
after running a Message
, see also the
updated section
in the README
on this,
PR #577Bug Fixes
vm.stateManager.generateCanonicalGenesis()
to produce a correct
genesis block state root (in particular for the Goerli
testnet),
PR #589Refactoring / Docs
activatePrecompiles
VM option,
PR #595First TypeScript
based VM release, other highlights:
See v4.0.0-beta.1 release for full release notes.
Changes since last beta
Cache.flush()
method from StateManager
,
PR #562StateManager
storage key length validation (now throws on addresses not
having a 32-byte length),
PR #565Since 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 preeceeded 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-vm').default
The library now also comes with type declaration files distributed along with the package published.
Bloom
, Stack
and Memory
,
PR #495StateManager
migration,
PR #496EEI
, Message
, TxContext
to
TypeScript
, PR #497EVM
(old: Interpreter
) and exceptions,
PR #504Interpreter
(old: Loop
),
PR #505opFns
(opcode implementations),
PR #506index.js
VM
class,
PR #507VM.runCode()
,
PR #508VM.runCall()
,
PR #510VM.runTx()
,
PR #511VM.runBlock()
,
PR #512VM.runBlockchain()
,
PR #517TypeScript
finalization PR, config switch,
PR #518TypeDoc
,
PR #522This 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.
runState
, refactored Interpreter
(old: Loop
),
PR #498emitFreeLogs
flag, to replace it is suggested to
implement by inheriting Interpreter
(old: Loop
),
PR #498EVM.executeMessage()
with EVM.executeCall()
and
EVM.executeCreate()
for call
and create
specific logic
(old names: Interpreter.[METHOD_NAME]()
),
PR #499Interpreter
/EVM
(old: Loop
/Interpreter
) structure,
PR #506VM.runJit()
in favor of direct handling in
EVM
(old: Interpreter
),
officially not part of the external API but mentioning just in case,
PR #515StorageReader
, moved logic to StateManager
,
#534With 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
}
runTx
internals,
PR #493runBlock
internals, restructure, reduced shared global state,
PR #494ethereumjs-account
from 2.x
to 3.x
, part of
PR #496runTx()
,
PR #523StateManager
to petersburg
,
PR #524Object.assign()
calls and fixed type errors,
PR #529This 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
Memory
class for evm memory manipulation,
PR #442Stack
manipulation in evm,
PR #460createHookedVm
(BREAKING), being made obsolete by the
new StateManager
API,
PR #451VM.deps
attribute (please require dependencies yourself if you
used this),
PR #478fakeBlockchain
class and associated tests,
PR #466petersburg
hardfork rules are now run as default
(before: byzantium
),
PR #485Modularization
vm
module to evm
, move precompiles
to evm
module,
PR #481stateManager
, storageReader
and cache
to state
module,
#443logTable
with dynamic inline version in EXP
opcode,
#450Code Modernization/ES6
VM
to ES6
class,
PR #478stateManager
and storageReader
to ES6
class syntax,
PR #452Bug Fixes
stateManager.setStateRoot()
didn't clear
the _storageTries
cache,
PR #445CALL
opcode,
PR #454BN.toArrayLike()
instead of BN.toBuffer()
(browser compatibility),
PR #458Maintenance/Optimization
BN
reduction context in MODEXP
precompile,
PR #463Documentation
Bloom
filter methods,
PR #439Testing
--json
trace flag in the tests,
PR #438StateManager.dumpStorage()
,
PR #462ecmul_0-3_5616_28000_96
(by test setup adoption),
PR #473Petersburg 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-blockchain
v3.4.0ethereumjs-block
v2.2.0To 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
sync
/async
functions in cache
,
PR #422setStateroot
and caching by clearing the stateManager
cache
after setting the state root such that stale values are not returned,
PR #420Refactoring
Following changes might be relevant for you if you are hotfixing/monkey-patching on parts of the VM:
bloom
to its own directory,
PR #429opcodes
, opFns
and logTable
to lib/vm
,
PR #425Bloom
to ES6
class,
PR #428Cache
to ES6
class, added unit tests,
PR 427memoryWordCount
to the step
event object,
PR #405opts.state
)
when instantiating the library with the opts.activatePrecompiles
option,
PR #415runCode
(in case loadContract
fails),
PR #408StateManager.generateGenesis()
function,
PR #400ethereumjs-blockchain
and level
for test runs,
PR #414This 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:
SSTORE
, see PR #367CREATE2
, see PR #329EXTCODEHASH
, see PR #324This 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 tests/tester.js
) and otherwise passing all blockchain tests and all state tests for both Constantinople
and Byzantium
rules. 🏆 🏆 🏆
Consensus Conformity related changes:
selfdestruct
on REVERT
, see PR #392Bloom
filter changes from PR #295, see PR #384BLOCKHASH
opcode, see PR #381GasLimitHigherThan2p63m1
, see PR #380account
to cache
when checking if it is empty, see PR #375The 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-releated 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:
StateManager
interface simplification, see PR #388StateManager
cache and trie private, see PR #385StateManager
trie
and cache
, see PR #376trie
in tests, see PR #345StateManager
API documentation, see PR #393emitFreeLogs
option, 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, #379Beyond the reintegrated blockchain tests there is now a separate test suite to test the API of the library, see tests/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
).
index.js
, StateManager
, see PR #364runJit
and fakeBlockchain
, see PR #331runBlockchain
, see PR #336runBlock
API tests, see PR #360runTx
API tests, see PR #352Bloom
module, see PR #330istanbul
to nyc
, see PR #334sealEngine
in blockchain tests, see PR #373tap-spec
option to get a formatted test run result summary, see README, see PR #363Some bug fix and maintenance updates:
Special thanks to:
SSTORE
implementation within 4 daysBeyond 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!
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 themself 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
Constantinople
bitwise shifiting instructions SHL
, SHR
and SAR
, see PR #251newContract
event which can be used to do interrupting tasks on contract/address creation, see PR #306UPDATES/TESTING
rustbn.js
API, see PR #312StateManager
, see PR #266util.sha3
usages to util.keccak256
and bump ethereumjs-util
to v5.2.0
(you should do to if you use ethereumjs-util
)Byzantium
and Constantinople
state tests, see PR #317CircleCI
and support for Travis
have been dropped, see PR #316BUG FIXES
Bloom.check()
method not working properly, see PR #311REVERT
is used within a CREATE
context, see PR #297FakeBlockChain
error handing, see PR #320BYTE
opcode return value bug, PR #293StateManager
, PR #287stateManager.copy()
function, PR #276ES5
distribution on npm for better toolchain compatibility, PR #281allowUnlimitedContractSize
VM option for debugging purposes, PR #282gasRefund
to transaction results, PR #284ethereumjs-util
dependency from 4.5.0
to 5.1.x
, PR #241rustbn.js
exceptionsByzantium
compatibleREVERT
, RETURNDATA
and STATICCALL
Spurious Dragon
/EIP 150
compatible version of this library install latest version of 2.2.x
Spurious Dragon
& EIP 150
compatibleenableHomestead
option when creating a new VM object (pre-Homestead fork rules not supported any more)