Monorepo for the Ethereum VM TypeScript Implementation
This release comes with some RPC improvements as well as various updates to catch up for testnets preparing for the Prague hardfork as well as the Verkle tree integration. Note that for running/participating in the latest Prague and Verkle testnets it is still needed to join with a build from master
since testnets are evolving so quickly that it is not practical to catch up with official client releases!
--ignoreStatelessInvalidExecs
for Verkle debugging, PR #3269
verkle-cryptography-wasm
migration, PRs #3355 and #3356
kzg-wasm
to 0.4.0
, PR #3358
osaka
hardfork, PR #3371
--ignoreStatelessInvalidExecs
to just a boolean flag, PR #3395
executeBlocks()
, PR #3406
--startExectionFrom
and --startExecution
CLI options, PR #3269
eth_blobBaseFee
RPC endpoint, PR #3436
pending
in eth_getTransactionCount
RPC method, PR #3415
--loadBlocksFromRlp
, PR #3442
--execution
flag guard, PR #3363
multiaddress
dependency, PR #3384
QHeap
dependency, PR #3451
jwt-simple
dependency, PR #3458
Published by holgerd77 2 months ago
This library now supports EIP-6110
deposit requests, see PR #3390, EIP-7002
withdrawal requests, see PR #3385 and EIP-7251
consolidation requests, see PR #3477 as well as the underlying generic execution layer request logic introduced with EIP-7685
(PR #3372).
These new request types will be activated with the Prague
hardfork, see @ethereumjs/block README for detailed documentation.
Starting with this release the VM supports EIP-2935 which stores the latest 256 block hashes in the storage of a system contract, see PR #3475 as the major integrational PR (while work on this has already been done in previous PRs).
This EIP will be activated along the Prague hardfork. Note that this EIP has no effect on the resolution of the BLOCKHASH
opcode, which will be a separate activation taking place by the integration of EIP-7709 in the following Osaka hardfork.
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.
verkle-cryptography-wasm
migration, PRs #3355 and #3356
evmOpts
to the VM opts to allow for options chaining to the underlying EVM, PR #3481
VM._emit()
, PR #3396
mcl-wasm
Dependency (Esbuild Issue), PR #3461
Published by holgerd77 2 months ago
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.
verkle-cryptography-wasm
migration, PRs #3355 and #3356
kzg-wasm
to 0.4.0
, PR #3358
osaka
hardfork, PR #3371
accessWitness
passing, PR #3405
npm run visualize:bundle
), PR #3463
mcl-wasm
Dependency (Esbuild Issue), PR #3461
Published by holgerd77 2 months ago
This library now supports EIP-6110
deposit requests, see PR #3390, EIP-7002
withdrawal requests, see PR #3385 and EIP-7251
consolidation requests, see PR #3477 as well as the underlying generic execution layer request logic introduced with EIP-7685
(PR #3372).
These new request types will be activated with the Prague
hardfork, see @ethereumjs/block README for detailed documentation.
Published by holgerd77 2 months ago
Maintenance release with downstream dependency updates, see PR #3527
Published by holgerd77 2 months ago
Maintenance release with downstream dependency updates, see PR #3527
Published by holgerd77 2 months ago
Starting with this release this library supports requests to the consensus layer (see PRs #3372 and #3393) which have been introduced with EIP-7685 and will come into play for deposit and withdrawal requests along the upcoming Prague hardfork.
EIP-6110 introduces deposit requests allowing beacon chain deposits being triggered from the execution layer, see PRs #3390 and #3397. Starting with this release this library supports deposit requests and a containing block can be instantiated as follows:
import { Chain, Common, Hardfork } from '@ethereumjs/common'
import { Block } from '@ethereumjs/block'
import {
bytesToBigInt,
DepositRequest,
randomBytes,
type CLRequest,
type CLRequestType,
} from '@ethereumjs/util'
const main = async () => {
const common = new Common({
chain: Chain.Mainnet,
hardfork: Hardfork.Prague,
})
const depositRequestData = {
pubkey: randomBytes(48),
withdrawalCredentials: randomBytes(32),
amount: bytesToBigInt(randomBytes(8)),
signature: randomBytes(96),
index: bytesToBigInt(randomBytes(8)),
}
const request = DepositRequest.fromRequestData(depositRequestData) as CLRequest<CLRequestType>
const requests = [request]
const requestsRoot = await Block.genRequestsTrieRoot(requests)
const block = Block.fromBlockData(
{
requests,
header: { requestsRoot },
},
{ common }
)
console.log(
`Instantiated block with ${
block.requests?.length
} request, requestTrieValid=${await block.requestsTrieIsValid()}`
)
}
main()
Have a look at the EIP for some guidance on how to use and fill in the various deposit request parameters.
EIP-7002 introduces the possibility for validators to trigger exits and partial withdrawals via the execution layer, see PR #3385. Starting with this release this library supports withdrawal requests and a containing block can be instantiated as follows:
import { Chain, Common, Hardfork } from '@ethereumjs/common'
import { Block } from '@ethereumjs/block'
import {
bytesToBigInt,
randomBytes,
WithdrawalRequest,
type CLRequest,
type CLRequestType,
} from '@ethereumjs/util'
const main = async () => {
const common = new Common({
chain: Chain.Mainnet,
hardfork: Hardfork.Prague,
})
const withdrawalRequestData = {
sourceAddress: randomBytes(20),
validatorPubkey: randomBytes(48),
amount: bytesToBigInt(randomBytes(8)),
}
const request = WithdrawalRequest.fromRequestData(
withdrawalRequestData
) as CLRequest<CLRequestType>
const requests = [request]
const requestsRoot = await Block.genRequestsTrieRoot(requests)
const block = Block.fromBlockData(
{
requests,
header: { requestsRoot },
},
{ common }
)
console.log(
`Instantiated block with ${
block.requests?.length
} withdrawal request, requestTrieValid=${await block.requestsTrieIsValid()}`
)
}
main()
Have a look at the EIP for some guidance on how to use and fill in the various withdrawal request parameters.
EIP-7251 introduces consolidation requests allowing staked ETH from more than one validator on the beacon chain to be consolidated into one validator, triggered from the execution layer, see PR #3477. Starting with this release this library supports consolidation requests and a containing block can be instantiated as follows:
// ./examples/7251Requests.ts
import { Chain, Common, Hardfork } from '@ethereumjs/common'
import { Block } from '@ethereumjs/block'
import {
bytesToBigInt,
ConsolidationRequest,
randomBytes,
type CLRequest,
type CLRequestType,
} from '@ethereumjs/util'
const main = async () => {
const common = new Common({
chain: Chain.Mainnet,
hardfork: Hardfork.Prague,
})
const consolidationRequestData = {
sourceAddress: randomBytes(20),
sourcePubkey: randomBytes(48),
targetPubkey: randomBytes(48),
}
const request = ConsolidationRequest.fromRequestData(
consolidationRequestData
) as CLRequest<CLRequestType>
const requests = [request]
const requestsRoot = await Block.genRequestsTrieRoot(requests)
const block = Block.fromBlockData(
{
requests,
header: { requestsRoot },
},
{ common }
)
console.log(
`Instantiated block with ${
block.requests?.length
} consolidation request, requestTrieValid=${await block.requestsTrieIsValid()}`
)
}
main()
Have a look at the EIP for some guidance on how to use and fill in the various deposit request parameters.
kzg-wasm
to 0.4.0
, PR #3358
osaka
hardfork, PR #3371
Block.toExecutionPayload()
method to map to the execution payload structure from the beacon chain, PR #3269
Published by holgerd77 2 months ago
getContractCodeSize()
, other), PR #3269
verkle-cryptography-wasm
migration, PRs #3355 and #3356
getAccount()
, PR #3345
Published by holgerd77 2 months ago
This is the first (still experimental) Verkle library release with some basic put()
and get()
functionality working! 🎉 Still highly moving and evolving parts, but early experiments and feedback welcome!
verkle-cryptography-wasm
migration, PRs #3355 and #3356
trie.put()
, PR #3473
trie.del()
, PR #3486
Published by holgerd77 2 months ago
Maintenance release with downstream dependency updates, see PR #3527
Published by holgerd77 2 months ago
Maintenance release with downstream dependency updates, see PR #3527
Published by holgerd77 2 months ago
This release introduces support for a non-final version of EIP-7702 EOA code transactions, see PR #3470. This tx type allows to run code in the context of an EOA and therefore extend the functionality which can be "reached" from respectively integrated into the scope of an otherwise limited EOA account.
The following is a simple example how to use an EOACodeEIP7702Transaction
with one autorization list item:
// ./examples/EOACodeTx.ts
import { Chain, Common, Hardfork } from '@ethereumjs/common'
import { EOACodeEIP7702Transaction } from '@ethereumjs/tx'
import type { PrefixedHexString } from '@ethereumjs/util'
const ones32 = `0x${'01'.repeat(32)}` as PrefixedHexString
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Cancun, eips: [7702] })
const tx = EOACodeEIP7702Transaction.fromTxData(
{
authorizationList: [
{
chainId: '0x1',
address: `0x${'20'.repeat(20)}`,
nonce: ['0x1'],
yParity: '0x1',
r: ones32,
s: ones32,
},
],
},
{ common }
)
console.log(
`EIP-7702 EOA code tx created with ${tx.authorizationList.length} authorization list item(s).`
)
Note: Things move fast with EIP-7702
and the released implementation is based on this commit and therefore already outdated. An up-to-date version will be released along our breaking release round planned for early September 2024.
BlobEIP4844Transaction.networkWrapperToJson()
to also include the 4844 fields, PR #3365
Published by holgerd77 2 months ago
Published by holgerd77 2 months ago
This library now supports EIP-6110
deposit requests, see PR #3390, EIP-7002
withdrawal requests, see PR #3385 and EIP-7251
consolidation requests, see PR #3477 as well as the underlying generic execution layer request logic introduced with EIP-7685
(PR #3372).
These new request types will be activated with the Prague
hardfork, see @ethereumjs/block README for detailed documentation.
verkle-cryptography-wasm
migration, PRs #3355 and #3356
Published by holgerd77 2 months ago
For Verkle or other contexts it can be useful to create partial accounts not containing all the account parameters. This is now supported starting with this release, see PR #3269:
import { Account } from '@ethereumjs/util'
const account = Account.fromPartialAccountData({
nonce: '0x02',
balance: '0x0384',
})
console.log(`Partial account with nonce=${account.nonce} and balance=${account.balance} created`)
requests
ModuleThis release introduces a new requests
module (see PRs #3372, #3393, #3398 and #3477) with various type and an abstract base class for EIP-7685 general purpose execution layer requests to the CL (Prague hardfork) as well as concrete implementations for the currently supported request types:
DepositRequest
(Prague Hardfork)WithdrawawlRequest
(Prague Hardfork)ConsolidationRequest
(Prague Hardfork)These request types are mainly used within the @ethereumjs/block library where applied usage instructions are provided in the README.
kzg-wasm
to 0.4.0
, PR #3358
osaka
hardfork, PR #3371
verkle
module with utility methods and interfaces, PR #3462
Account.isContract()
(in Verkle context work), PR #3343
Account.isEmpty()
to also work for partial accounts, PR #3405
validatorPublicKey
to validatorPubkey
, PR #3474
Published by holgerd77 7 months ago
This is mainly a maintenance release coming with a few internal changes and minor bug fixes, single user-focused addition is the support for the eth_feeHistory
RPC call.
Support for the eth_feeHistory
RPC endpoint has been added in PR #3295. The endpoint allows to query the base fee and the priority fee per gas for a requested/supported block range.
kzg-wasm
instead of the c-kzg
Node.js bindings for 4844 functionality, PR #3294
devnet6.txt
trusted setup file and all test usages in downstream libraries, PR #3288
Published by holgerd77 7 months ago
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 compatiblity 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. If you pass in a custom EVM
along your VM
initialization you need to update your EVM initialization.
An EVM is now initialized like the following:
import { hexToBytes } from '@ethereumjs/util'
import { EVM } from '@ethereumjs/evm'
const evm = await EVM.create()
const res = await evm.runCode({ code: hexToBytes('0x6001') })
For the VM
there has been an async create()
constructor before already and the main constructor was labelled as deprecated
. While this main constructor was still working before, along with these releases the main VM constructor is now "fully out of order" and VM initialization solely work with the async create()
constructor.
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.
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.
Published by holgerd77 7 months ago
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 compatiblity 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.
startReportingPreimages()
method, PR #3143 and #3298
getOpcodesForHF()
helper method, PR #3322
Published by holgerd77 7 months ago
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.
Published by holgerd77 7 months ago
Maintenance release with downstream dependency updates, see PR #3297