@ethereumjs/tx v3.1.2

DEPRECATED: Release is deprecated in favor of 3.1.3 which fixes a critical EIP-2930 tx constructor bug.

• Fixed default value for empty access lists in the AccessListEIP2930Transaction.fromValuesArray() static constructor method, PR #1179

@ethereumjs/blockchain v5.2.1

• Fixed a bug leading Blockchain to fail instantiating with a common custom chain setup when no genesisBlock was provided, PR #1167

@ethereumjs/tx v3.1.1

DEPRECATED: Release is deprecated in favor of 3.1.3 which fixes a critical EIP-2930 tx constructor bug.

This release fixes a bug in the v3.1.0 Berlin HF @ethereumjs/tx release where the import path for eip2930Transaction was broken on operating systems with case sensitive filename resolution.

The v3.1.0 release has been deprecated in favor of this new version.

@ethereumjs/vm v5.2.0

Berlin HF Support

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:

Added Typed Transaction Support (EIP-2718 / EIP-2930)

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.

Fixed EIP-2929 Implementation

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.

Removed EIP-2315 from Berlin

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.

EthereumJS Libraries - Typed Transactions Readiness

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/common v2.2.0
• @ethereumjs/tx v3.1.0
• @ethereumjs/block v3.2.0
• @ethereumjs/blockchain v5.2.0
• @ethereumjs/vm v5.2.0

Other Features

• { stateRoot, gasUsed, logsBloom, receiptRoot } have been added to RunBlockResult and will be emitted with afterBlock, PR #853
• Added vm:eei:gas EEI gas debug looger, PR #1124

Other Fixes

• Fixes VM Node 10 support being broken due to the usage of globalThis for browser detection, PR #1151
• Fixed ECRECOVER precompile to work correctly on networks with very large chain IDs, PR #1139

CI and Test Improvements

• Benchmark improvements and fixes, PR #853

@ethereumjs/tx v3.1.0

Berlin HF Support

This release comes with full support for the berlin hardfork by updating the library to support typed transactions (EIP-2718). The first supported transaction type is the AccessListEIP2930Transaction (EIP-2930) which adds optional access lists to the mix and is activated along with the berlin hardfork.

EIP-2930 transactions can be instantiated with:

import Common from '@ethereumjs/common'
import { AccessListEIP2930Transaction } from '@ethereumjs/tx'

const common = new Common({ chain: 'mainnet', hardfork: 'berlin' })

const txData = {
  "data": "0x1a8451e600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "gasLimit": "0x02625a00",
  "gasPrice": "0x01",
  "nonce": "0x00",
  "to": "0xcccccccccccccccccccccccccccccccccccccccc",
  "value": "0x0186a0",
  "v": "0x01",
  "r": "0xafb6e247b1c490e284053c87ab5f6b59e219d51f743f7a4d83e400782bc7e4b9",
  "s": "0x479a268e0e0acd4de3f1e28e4fac2a6b32a4195e8dfa9d19147abe8807aa6f64",
  "chainId": "0x01",
  "accessList": [
    {
      "address": "0x0000000000000000000000000000000000000101",
      "storageKeys": [
        "0x0000000000000000000000000000000000000000000000000000000000000000",
        "0x00000000000000000000000000000000000000000000000000000000000060a7"
      ]
    }
  ],
  "type": "0x01"
}

const tx = AccessListEIP2930Transaction.fromTxData(txData, { common })

Please note that the default HF is still set to istanbul. You therefore need to explicitly set the hardfork parameter for instantiating a Transaction instance with a berlin HF activated.

The now called "legacy" transactions are still supported and can be used as before by using the Transaction class. If the type of a tx is only known at runtime there is a new TransactionFactory class introduced for your convenience. This factory class decides on the tx type based on the input data and uses the corresponding tx type class for instantiation.

For more guidance on how to use the new tx types and the tx factory have a look at the README of this library which has received an extensive update along with this release.

EthereumJS Libraries - Typed Transactions Readiness

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/common v2.2.0
• @ethereumjs/tx v3.1.0
• @ethereumjs/block v3.2.0
• @ethereumjs/blockchain v5.2.0
• @ethereumjs/vm v5.2.0

EIP-2718/EIP-2930 Changes

• Base implementation of both EIPs, PR #1048
• Tx Renaming / Improve backwards-compatibility, PR #1138
• Improvements and additional tests, PR #1141
• Further improvements and small fixes, PR #1144

@ethereumjs/common v2.2.0

Berlin HF Support

This Common release comes with full support for the berlin hardfork. Please note that the default HF is still set to istanbul. You therefore need to explicitly set the hardfork parameter for instantiating a Common instance with a berlin HF activated:

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

Berlin HF Changes

• Added final list of berlin EIPs (EIP-2565, EIP-2929, EIP-2718, EIP-2930), PR #1124 and PR #1048
• Corrected base gas costs for EIP-2929 related opcodes, PR #1124
• New EIP configuration files for EIP-2718 (typed txs) and EIP-2930 (optional access lists), PR #1048
• Added berlin hardfork block numbers for mainnet, ropsten, rinkeby and goerli, PR #1142

BN Support for high Chain IDs and Block Numbers

The library has been updated to support very high chain IDs and block numbers exceeding the Number.MAX_SAFE_INTEGER limit (9007199254740991).

Methods with a respective input parameter now allow for a BNLike input (number (as before), Buffer, (Hex)String or BN). The following function signatures have been updated:

• chain constructor parameter now additionally allowing BN
• setChain(chain: string | number | object) -> setChain(chain: string | number | BN | object)
• getHardforkByBlockNumber(blockNumber: BNLike): string
• setHardforkByBlockNumber(blockNumber: BNLike): string
• paramByBlock(topic: string, name: string, blockNumber: BNLike): any
• hardforkIsActiveOnBlock(hardfork: string | null, blockNumber: BNLike, opts?: hardforkOptions): boolean
• activeOnBlock(blockNumber: BNLike, opts?: hardforkOptions): boolean
• activeHardforks(blockNumber?: BNLike | null, opts: hardforkOptions = {}): Array<any>
• activeHardfork(blockNumber?: BNLike | null, opts: hardforkOptions = {}): string
• isHardforkBlock(blockNumber: BNLike, hardfork?: string): boolean
• isNextHardforkBlock(blockNumber: BNLike, hardfork?: string): boolean

For methods with a respective number return value corresponding [METHOD_NAME]BN methods have been added:

• hardforkBlockBN(hardfork?: string): BN
• nextHardforkBlockBN(hardfork?: string): BN | null
• chainIdBN(): BN
• networkIdBN(): BN

Note that in the next major release these methods will be unified again by switching to use the original version names for the new BN-output functions.

Other Changes

• Added chain config and genesis file for yolov3 testnet, PR #1129
• New Common.copy() function to easily receive a deep copy of a Common instance, PR #1144

@ethereumjs/blockchain v5.2.0

Berlin HF Support

This release comes with full berlin HF support by setting the Block, Tx and Common dependencies to versions which ensure a working set of berlin-enabled library versions. In particular this allows for running a blockchain with blocks containing 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 Blockchain instance with a berlin HF activated:

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

EthereumJS Libraries - Typed Transactions Readiness

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/common v2.2.0
• @ethereumjs/tx v3.1.0
• @ethereumjs/block v3.2.0
• @ethereumjs/blockchain v5.2.0
• @ethereumjs/vm v5.2.0

@ethereumjs/block v3.2.0

This release gets the Block library ready for the berlin HF by adding support for EIP2718 Typed Transactions. Transaction objects are now created with the new TransactionFactory introduced with the @ethereumjs/tx v3.1.0 release which chooses the correct tx type for the data. The initial tx release supports the old legacy transactions and the newly added EIP2930 Access List Transaction Type, see PR #1048.

Please note that the default HF is still set to istanbul. You therefore need to explicitly set the hardfork parameter for instantiating a Block instance with a berlin HF activated:

import { Block } from 'ethereumjs-block'
import Common from '@ethereumjs/common'
const common = new Common({ chain: 'mainnet', hardfork: 'berlin' })
const block = Block.fromBlockData({}, { common })

EthereumJS Libraries - Typed Transactions Readiness

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/common v2.2.0
• @ethereumjs/tx v3.1.0
• @ethereumjs/block v3.2.0
• @ethereumjs/blockchain v5.2.0
• @ethereumjs/vm v5.2.0

Other Changes

• Added support for very large chain IDs when using Block cliqueSigner() address recovery, PR #1139
• Fixed a TS compilation failure on install relating to ethereumjs-util v7.0.9, PR #1136

@ethereumjs/vm v5.1.0

Clique/PoA Support

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 (various extraData checks e.g.)
• VM.runBlock(): There is no assignment of block rewards to the coinbase account taking place
• VM.runTx(): Tx fees are attributed to the block signer instead of the coinbase account
• COINBASE opcode: The COINBASE opcode returns the block signer instead of the coinbase address (Clique specification)

StateManager Checkpointing Performance

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! 😀

New EIPs

EIP-2565: ModExp precompile gas cost

This release adds support for EIP 2565, ModExp precompile gas cost, which is planned to be included in the Berlin hardfork, see PR #1026.

VM Debug Logger

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.

Other Features

• The afterBlock (VM.runBlock()) and afterTx (VM.runTx()) events now expose the respective block or transaction in the event results, PR #965
• New hardforkByBlockNumber VM constructor option for VM.runBlock() runs (see also corresponding Block option), PR #966 and #967 (option renamed along release PR)
• Added new optional maxBlocks option to VM.runBlockchain(), PR #1025
• VM.runBlockchain() now returns the number of actual blocks run (needs Blockchain v5.1.0 or higher, void kept in TypeScript function signature for backwards-compatibility), PR #1065
• New option skipBlockGasLimitValidation to disable the block gas limit check in VM.runTx(), PR #1039
• Added type definition Log for logs in TxReceipt items returned (result of VM.runBlocks() and afterBlock event), PR #1084

Bug Fixes

• Consensus: fixed Frontier consensus bug along CREATE with not enough gas, PR #1081
• Update opcodes along HF switches, added a dedicated tangerineWhistle opcode list (no need for calls to VM._updateOpcodes() on HF switches manually any more), PR #1101 and #1112
• Use common from VM when creating default blocks in VM.runCall() and VM.runCode(), PR #1011
• Fixed a bug when the result of the MODEXP opcode is 0, PR #1026

Maintenance

• Updated run-solidity-contract example, PR #1104
• Updated ethereum/tests submodule to 1fcd4e5 (2021-02-02), PR #1116
• Only expose API method on docs, PR #1119

@ethereumjs/common v2.1.0

Clique/PoA Support

This release completes on Clique/PoA support (see also Clique/PoA related changes in v2.0.0), see PR #1032. The chain configuration files (e.g. chains/goerli.json) are extended by a consensus algorithm-specific config parameter section, here is a sample consensus parameter section, note that the config parameter dict must be named after the consensus algorithm:

{
  "consensus": {
    "type": "poa",
    "algorithm": "clique",
    "clique": {
      "period": 15,
      "epoch": 30000
    }
  }
}

For now this is done in a backwards-compatible way and the consensus parameter section is still marked as optional. You nevertheless might want to add this section already to your custom chain files - even if you don't make usage of the parameters - to remain compatible in the future.

The new parameter section is complemented by a new Common.consensusConfig() function to request these parameters in addition to the Common.consensusType() and Common.consensusAlgorithm() methods introduced in v2.0.0.

Custom Chain File Support

There is now a more convenient and flexible way to integrate custom chains into Common instances complementing the existing Common.fromCustomChain() static constructor, see PR #1034.

This new way adds a new customChains constructor option and can be used as following:

import myCustomChain1 from './[PATH]/myCustomChain1.json'
import myCustomChain2 from './[PATH]/myCustomChain2.json'
// Add two custom chains, initial mainnet activation
const common1 = new Common({ chain: 'mainnet', customChains: [ myCustomChain1, myCustomChain2 ] })
// Somewhat later down the road...
common1.setChain('customChain1')
// Add two custom chains, activate customChain1
const common1 = new Common({ chain: 'customChain1', customChains: [ myCustomChain1, myCustomChain2 ] })

The README section on working with custom chains has been significantly expanded along the way and is a recommended read if you use common for custom chain initialization.

New EIPs

EIP-1459 DNS Peer Discovery

EIP-1459 introduces a way to discover nodes for an Ethereum network connection via DNS. This release adds a new optional chain config file parameter dnsNetworks and an associated method Common.dnsNetworks() to request DNS networks for a chain.

EIP-2565 ModExp Precompile Gas Costs

EIP-2565 introduces a new algorithm for ModExp precompile gas cost calculation. A new EIP file eips/2565.json has been added along the work on PR #1026 with respective parameter updates.

Other Changes

• Common is now implemented as an EventEmitter and emits a hardforkChanged event upon a HF change, PR #1112
• New Common.isActivatedEIP() method, PR #1125
• Updated Goerli bootnodes, PR #1031