@ethereumjs/blockchain v5.1.0

This release introduces Clique/PoA support for the Blockchain library, see the main PR #1032 as well as the follow-up PRs #1074 and PR #1088.

The blockchain package now keeps track of the latest signers and votes on new Clique/PoA signers and saves them to DB. Block format validation is now also taking all the Clique/PoA specifics into account (extraData format and other formal requirements from the EIP) and consensus validation is now also working for Clique/PoA chains (this verifies the respective block signatures from the corresponding authorized signers) and can be activated with the validateConsensus constructor flag. There is a new public method Blockchain.cliqueActiveSigners() to get the currently active signer list.

Other Features/Changes

• Added optional maxBlocks parameter to Blockchain.iterator() method, PR #965
• Blockchain.iterator() now returns a number (instead of void) with the blocks actually iterated (the Blockchain interface allows for both for backwards-compatibility reasons for now, void is considered deprecated though), PR #1065
• Blocks in the blockchain package are now always created with the hardforkByBlockNumber option set to true to avoid inconsistencies in block behavior, PR #1089
• New Blockchain.setHead(tag: string, headHash: Buffer) method to set a specific iterator head to a certain block, PR #965
• Added debug logger integration, first blockchain:clique debug logger (see README), PR #1103
• Fixed a bug in the validation logic to only validate the block header if a header is passed to the internal Blockchain._putBlockOrHeader() function, PR #1105

@ethereumjs/block v3.1.0

Clique/PoA Support

This release introduces Clique/PoA support for the Block library, see the main PR #1032 as well as the follow-up PRs #1074 and PR #1088. The BlockHeader.validate() function now properly validates the various Clique/PoA-specific properties (extraData checks and others, see API documentation) and BlockHeader.validateConsensus() can be used to properly validate that a Clique/PoA block has the correct signature.

For sealing a block on instantiation there is a new cliqueSigner constructor option:

const cliqueSigner = Buffer.from('PRIVATE_KEY_HEX_STRING', 'hex')
const block = Block.fromHeaderData(headerData, { cliqueSigner })

Additionally there are the following new utility methods for Clique/PoA related functionality in the BlockHeader class:

• BlockHeader.validateCliqueDifficulty(blockchain: Blockchain): boolean
• BlockHeader.cliqueSigHash()
• BlockHeader.cliqueIsEpochTransition(): boolean
• BlockHeader.cliqueExtraVanity(): Buffer
• BlockHeader.cliqueExtraSeal(): Buffer
• BlockHeader.cliqueEpochTransitionSigners(): Address[]
• BlockHeader.cliqueVerifySignature(signerList: Address[]): boolean
• BlockHeader.cliqueSigner(): Address

See the API docs for a detailed documentation. Note that these methods will throw if called in a non-Clique/PoA context.

Other Changes

• The Common instance passed is now copied to avoid side-effects towards the outer common instance on HF updates, PR #1089
• Fixed a bug where txs have been created with the wrong HF when hardforkByBlockNumber is used along with the static constructors, PR #1089
• Fixed a bug where Common has not been passed to the returned block in the blockFromRpc() method, PR #1032

merkle-patricia-tree v4.1.0

This release comes with a reworked checkpointing mechanism (PR #1030 and subsequently PR #1035). Instead of copying over the whole DB on checkpoints the operations in between checkpoints are now recorded in memory and either applied in batch on a Trie.checkpoint() call or discarded along a Trie.revert(). This more fine-grained operational mode leads to a substantial performance gain (up to 50x) when working with larger tries.

Another performance related bug has been fixed along PR #127 removing an unnecessary double-serialization call on nodes. This gives a general performance gain of 10-20% on putting new values in a trie.

Other changes:

New Features

A new exported WalkController class has been added and trie.walkTrie() has been made a public method along. This allows for creating own custom ways to traverse a trie. PR #135

Refactoring, Development and Documentation

• Better Trie code documentation, PR #125
• Internal Trie function reordering & partial retwrite, PR #125
• Added simple integrated profiling, PR #128
• Reworked benchmarking to be based on benchmark.js, basic CI integration, PR #130
• Upgrade to ethereumjs-config 2.0 libs for linting and formatting, PR #133
• Switched coverage from coverall to codecov, PR #137

@ethereumjs/tx v3.0.2

Follow-up release on v3.0.1 which only partly addressed a critical bug. An update is - again - strongly recommended.

• Fixes tx.isSigned() always returning true when using the Tx.fromValuesArray() static constructor, see PR #1077

@ethereumjs/tx v3.0.1

• Fixes tx.isSigned() always returning true - so also for unsigned transactions - due to a bug in the Transaction class constructor. This bug is regarded as critical and an update is strongly recommended. See PR #1042

@ethereumjs/vm v5.0.0

New Package Name

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/vm

Support for all current Hardforks / HF API Changes

This 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.DEAULT_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

Berlin HF Support / HF-independent EIPs

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 })

API Change: New Major Library Versions

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-tree v3 (VM option state) -> merkle-patricia-tree v4, PR #787
• ethereumjs-blockchain v4-> @ethereumjs/blockchain v5, PR #833
• ethereumjs-common v1 -> @ethereumjs/common v2

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.

New StateManager Interface / StateManager API Changes

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.

Dual ES5 and ES2017 Builds

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 releated discussion.

Other Changes

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 step event now emits an ethereumjs-util Account object instead of an ethereumjs-account
  (package retired) object
• Breaking: NewContractEvent now emits an address of type Address (see ethereumjs-util) instead of a Buffer, PR #919
• Breaking: EVMResult now returns a createdAddress of type Address (see ethereumjs-util) instead of a Buffer, PR #919
• Breaking: RunTxResult now returns a createdAddress of type Address (see ethereumjs-util) instead of a Buffer, PR #919
• Breaking: RunCallOpts now expects origin, caller and to inputs to be of type Address (see ethereumjs-util) instead of a Buffer, PR #919
• Breaking: RunCodeOpts now expects origin, caller and address inputs to be of type Address (see ethereumjs-util) instead of a Buffer, PR #919
• Visibility cleanup (Renaming and/or code docs additions) for class members not being part of the API, PR #925
• Make memory.ts use Buffers instead of Arrays, PR #850
• Use Map for OpcodeList and opcode handlers, 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 async dependency, PR #779
• Updated ethereumjs-util to 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-testing code 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-testing dev dependency, PR #953

Bug Fixes

• Fix activatePrecompiles, PR #797
• Strip zeros when putting contract storage in StateManager, PR #880
• Two ...

@ethereumjs/tx v3.0.0

New Package Name

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-tx -> @ethereumjs/tx

Please update your library references accordingly or install with:

npm i @ethereumjs/tx

Major Refactoring - Breaking Changes

This release is a major refactoring of the transaction library to simplify and strengthen its code base. Refactoring work has been done along PR #812 and PR #887.

New Constructor Params

The constructor has been reworked and new static factory methods fromTxData, fromRlpSerializedTx, and fromValuesArray have been added for a more TypeScript friendly and less error-prone way to initialize a Transaction object. The direct usage of the main constructor (now just being an alias to Tx.fromTxData(), see PR #944) is now discouraged and the static factory methods should be used.

Breaking: Note that you need to adopt your Transaction initialization code since the constructor API has changed!

Examples:

// Initializing from serialized data
const s1 = tx1.serialize().toString('hex')
const tx = Transaction.fromRlpSerializedTx(toBuffer('0x' + s1))

// Initializing with object
const txData = {
  gasPrice: 1000,
  gasLimit: 10000000,
  value: 42,
}
const tx = Transaction.fromTxData(txData)

// Initializing from array of 0x-prefixed strings.
// First, convert to array of Buffers.
const arr = txFixture.raw.map(toBuffer)
const tx = Transaction.fromValuesArray(arr)

Learn more about the full API in the docs.

Immutability

The returned transaction is now frozen and immutable. To work with a maliable transaction, copy it with const fakeTx = Object.create(tx). For security reasons it is highly recommended to stay in a freezed Transaction context on usage.

If you need Transaction mutability - e.g. because you want to subclass Transaction and modifiy its behavior - there is a freeze option to prevent the Object.freeze() call on initialization, see PR #941.

from

The tx.from alias was removed, please use const from = tx.getSenderAddress().

Message to sign

Getting a message to sign has been changed from calling tx.hash(false) to tx.getMessageToSign().

Fake Transaction

The FakeTransaction class was removed since its functionality can now be implemented with less code. To create a fake tansaction for use in e.g. VM.runTx() overwrite getSenderAddress with your own Address. See a full example in the section in the README.

New Default Hardfork

Breaking: The default HF on the library has been updated from petersburg to istanbul, see PR #906.

The HF setting is now automatically taken from the HF set for Common.DEAULT_HARDFORK, see PR #863.

Dual ES5 and ES2017 Builds

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 releated discussion.

Other Changes

Changes and Refactoring

• Updated ethereumjs-util to v7, PR #748
• Replaced new Buffer() (deprecated) statements with Buffer.from(), PR #721
• Dropped ethereumjs-testing dev dependency, PR #953

@ethereumjs/ethash v1.0.0

New Package Name

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:

• ethashjs -> @ethereumjs/ethash

Please update your library references accordingly or install with:

npm i @ethereumjs/ethash

Library Promisification

The Ethash library has been promisified and callbacks have been removed along PR #833 and preceeding PR #779.

Old API:

ethash.verifyPOW(validblock, (result) => {
  console.log(result)
})

New API:

const result = await ethash.verifyPOW(validBlock)
console.log(result) // => true

See Ethash README for a complete example.

@ethereumjs/common v2.0.0

New Package Name

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-common -> @ethereumjs/common

Please update your library references accordingly or install with:

npm i @ethereumjs/common

New constructor

Breaking: The constructor has been changed to require an options dict to be passed, PR #863

Example:

import Common from '@ethereumjs/common'
const common = new Common({ chain: 'mainnet', hardfork: 'muirGlacier' })

EIP Support

EIPs are now native citizens within the Common library, see PRs #856, #869 and #872. Supported EIPs have their own configuration file like the eips/2537.json file for the BLS precompile EIP and EIP settings can be activated by passing supported EIP numbers to the constructor:

const c = new Common({ chain: 'mainnet', eips: [2537] })

The following EIPs are initially supported within this release:

• EIP-2537 BLS Precompiles
• EIP-2315 EVM Subroutines (PR #876)

EIPs provided are then activated and parameters requested with Common.param() being present in these EIPs take precedence over the setting from the latest hardfork.

There are two new utility functions which return hardfork and EIP values respectively:

• Common.paramByHardfork()
• Common.paramByEIP()

Breaking: It is now not possible any more to pass a dedicated HF setting to Common.param(). Please update your code to explicitly use Common.paramByHardfork() for requesting a parameter for a HF deviating from the HF currently set within your Common instance.

For setting and requesting active EIPs there is Common.setEIPs() and Common.eips() added to the mix.

There is also a new EIP-based hardfork file format which delegates parameter definition to dedicated EIP files (see PR #876). This is in preparation for an upcoming Yolo v2 testnet integration.

Side note: with this new structural setup it gets now possible for all EIPs still implicitly contained within the hardfork files to be extracted as an EIP parameter set within its own dedicated EIP file (which can then be activated via the eip parameter on initialization) without loosing on functionality. If you have a need there feel free to open a PR!

Gas Parameter Completeness for all Hardforks

Remaining gas base fees which still resided in the VM have been moved over to Common along PR #806.

Gas fees for all hardforks up to MuirGlacier are now completely present within the Common library.

Eth/64 Forkhash Support

There is a new Common.forkHash() method returning pre-calculated Forkhash values or alternatively use the internal Common._calcForkHash() implementation to calculate a forkhash on the fly.

Forkhashes are used to uniquely identify a set of hardforks passed to be able to better differentiate between different dedicated chains. This is used for the Eth/64 devp2p protocol update and specificed in EIP-2124 to help improve the devp2p networking stack.

New Block/Hardfork related Utility Functions

The following block and hardfork related utility functions have been added with PRs #863 and #805 respectively:

• setHardforkByBlockNumber() - Sets the hardfork determined by the block number passed
• nextHardforkBlock() - Returns the next HF block for a HF provided or set
• isNextHardforkBlock() - Some convenience additional utility method, matching the existing hardforkBlock() / isHardforkBlock() method setup
• hardforkForForkHash() - Returns the data available for a HF given a specific forkHash

Default Hardfork

The default hardfork has been added as an accessible readonly property DEFAULT_HARDFORK, PR #863. This setting is used starting with the latest major releases of the monorepo libraries like the VM to keep the HF setting in sync across the different libraries.

Current default hardfork is set to istanbul, PR #906.

Dual ES5 and ES2017 Builds

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 releated discussion.

Other Changes

Changes and Refactoring

• Added consensus information to chains, new functions Common.consensusType() for consensus type access ("pow" or "poa") and Common.consensusAlgorithm() to get the associated algorithm or protocol (e.g. "ethash" PoW algorithm or "clique" PoA protocol), see PR #937
• Removed old consensus and finality fields, PR #758
• Removed old casper and sharding fields, PR #762
• Updated ethereumjs-util to v7, PR #748

@ethereumjs/blockchain v5.0.0

New Package Name

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-blockchain -> @ethereumjs/blockchain

Please update your library references accordingly or install with:

npm i @ethereumjs/blockchain

Library Promisification

The Blockchain library has been promisified and callbacks have been removed along PR #833 and preceeding PR #779.

Old API example:

blockchain.getBlock(blockId, (block) => {
  console.log(block)
})

New API example:

const block = await blockchain.getBlock(blockId)
console.log(block)

See Blockchain README for a complete example.

Safe Static Constructor

The library now has an additional safe static constructor Blockchain.create() which awaits the init method and throws if the init method throws:

import Blockchain from '@ethereumjs/blockchain'
const common = new Common({ chain: 'ropsten' })
const blockchain = await Blockchain.create({ common })

This is the new recommended way to instantiate a Blockchain object, see PR #930.

Constructor options (both for the static and the main constructor) for chain setup on all VM monorepo libraries have been simplified and the plain chain and hardfork options have been removed. Passing in a Common instance is now the single way to switch to a non-default chain (mainnet) or start a blockchain with a higher than chainstart hardfork, see PR #863.

Refactored Genesis Block Handling Mechanism

Genesis handling has been reworked to now be safer and reduce the risk of wiping a blockchain by setting a new genesis, see PR #930.

Breaking: The dedicated setGenesisBlock() methods and the optional isGenesis option on Blockchain.putBlock() have been removed. Instead the genesis block is created on initialization either from the Common library instance passed or a custom genesis block passed along with the genesisBlock option. If a custom genesis block is used, this custom block now always has to be passed along on Blockchain initialization, also when operating on an already existing DB.

Removed deprecated validate option

The deprecated validate option has been removed, please use valdiateBlock and validatePow for options when instantiating a new Blockchain.

Dual ES5 and ES2017 Builds

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 releated discussion.

Other Changes

Changes and Refactoring

• Breaking: validatePow option has been renamed to validateConsensus to prepare for a future integration of non-PoW (PoA) consensus mechanisms, validateConsensus as well as validateBlocks options now throw when set to true for validation on a non-PoW chain (determined by Common, e.g. 'goerli'), see PR #937
• Exposed private Blockchain._getTd() total difficulty function as Blockchain.getTotalDifficulty(), PR #956
• Refactored DBManager with the introduction of an abstract DB operation handling mechanism, if you have modified DBManager in your code this will be a potentially breaking change for you, PR #927
• Renaming of internal variables like Blockchain._headBlock, if you are using these variables in your code this will be a potentially breaking change for you, PR #930
• Made internal _ methods like _saveHeads() private, if you are using these functions in your code this will be a potentially breaking change for you, PR #930
• Improved code documentation, PR #930
• Fixed potential blockchain DB concurrency issues along PR #930
• Use @ethereumjs/block v3.0.0 block library version, PR #883
• Removed async dependency, PR #779
• Updated ethereumjs-util to v7, PR #748

Bug Fixes

• Fixed blockchain hanging forever in case code throws between a semaphore lock/unlock,
  Issue #877

Testing and CI

• Dedicated blockchain reorg test setup and executable test, PR #926