Releases: VaultaFoundation/evm-node
EOS EVM Node v1.0.0-rc2
Introduction
The latest release candidate introduces to a fix to issues discovered with how EOS EVM Node managed field extensions.
Read on for more details.
Updates
Improve block encode and decode logic to allow more flexibile field extensions
It was discovered that within EOS EVM Node v1.0.0-rc1 that the logic would break if block_body.withdrawals
exists but block_body.consensus_parameter_index
did not exist.
void encode(Bytes& to, const BlockBody& block_body) {
encode_header(to, rlp_header_body(block_body));
encode(to, block_body.transactions);
encode(to, block_body.ommers);
if (block_body.consensus_parameter_index) {
encode(to, *block_body.consensus_parameter_index);
}
if (block_body.withdrawals) {
encode(to, *block_body.withdrawals);
}
}
Building, compatibility, and upgrading
Building
The README in the eos-evm-node repository contains instructions on how to build EOS EVM Node and EOS EVM RPC.
Compatibility and upgrading
EOS EVM Node and EOS EVM RPC can be upgraded from the prior 0.7.x or v1.0.0-rc1 version by replacing the binaries.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
Full Changelog: v1.0.0-rc1...v1.0.0-rc2
EOS EVM Node v1.0.0-rc1
Introduction
The latest release candidate of EOS EVM introduces support for Shanghai and London Hard Fork and their comprised features along with a new dynamic gas fee algorithm to more accurately price transactions for underlying resource costs involved.
This release contains changes to silkworm
, eos-evm-contract
, eos-evm-node
, and eos-evm-miner
.
Read on for more details.
New features
London Fork Compatibility
EIP-1559: Transaction Fee Reform
PRs
A critical component of the London Hard Fork is EIP-1559, which introduces a new transaction fee mechanism. This update changes how gas fees are estimated on the EOS EVM network with new components including a base fee and priority fee combined to calculate the overall cost of a transaction based on units of gas used.
Base fee
The base fee, implemented as the base_fee_per_gas
, is the minimum amount of gas required for a transaction to be included in a block. This fee is burned in the Ethereum implementation, but is instead credited to the contract for EOS EVM. The base_fee_per_gas
is now part of the block header information and is returned in both eth_getBlockByNumber
and eth_getBlockByHash
API calls.
Priority fee
The priority fee, implemented as the inclusion_price
, is a fee historically designed so that users can pay to miners to incentivize them to prioritize their transactions over others, but is not applicable to EOS EVM. For the EOS EVM, this instead evaluates the updated gas fee algorithm (explained further in later section) to properly manage a minimum inclusion price. This fee is not burned but goes directly to the miners.
The priority fee or inclusion_price
can be calculated as min(max_priority_fee_per_gas, max_fee_per_gas - base_fee_per_gas)
.
Max fee
Users may now specify a maximum fee they are willing to pay for the sum of base and priority fees. If the max fee is higher than the sum of the base fee and the priority fee, the difference is refunded to the user. This ensures users don't overpay beyond what is necessary to get their transactions processed.
Overall transaction fee
The overall cost of a transaction fee utilizes a price per gas unit implemented as the effective_gas_price
, which can be calculated as
inclusion_price + base_fee_per_gas
. The overall cost of any given transaction is then calculated as the product ofeffective_gas_price * gas_used
.
Fee distribution
The fees associated with transactions are now distributed to where the contract receives base_fee_per_gas*gas_used
and the miner receives inclusion_price*gas_used
.
Feature activation for wallet users
The flag for the EIP-1559 network support is cached, so users will have to refresh their network selection by changing the active network to another network and go back to eos-evm in order for many common wallets like Metamask to start sending EIP-1559 transactions.
Shanghai Fork Compatibility
PUSH0 Opcode Support
Support has been added for the PUSH0
opcode as introduced in the Shanghai Hard Fork. This opcode pushes a zero onto the stack, optimizing certain types of smart contract code and potentially reducing gas costs for operations that frequently use zero values.
Gas Fee Algorithm Enhancements
PRs
A new gas fee algorithm has been introduced to alleviate challenges with a prior one-size-fits-all gas fee structure. Because the previous method used to calculate gas fees did not account for the varying computational resources required by transactions, many transactions were priced higher than their resource costs for the safety of the network.
To accomplish this, five new parameters are now tracked including:
- Additional gas consumed when creating a new non-contract account due to a message-call transaction that sends positive value to an empty account. This value defaults to 0 and is denoted as
G_txnewaccount
. - Additional gas consumed when creating a new non-contract account due to the
CALL
orSELFDESTRUCT
opcodes. This value defaults to to 25000 and is denoted asG_newaccount
. - Static gas consumed in the
CREATE
andCREATE2
opcodes and also acts as the additional gas consumed in a contract-creating transaction. This value defaults to 32000 and is denotedG_txcreate
. - Factor that multiplies the deployed code size within
CREATE
andCREATE2
opcodes, as well as contract-creating transactions, to determine the code deposit cost. This value defaults to 200 and is denoted asG_codedeposit
. - Gas consumed when an
SSTORE
opcode causes the storage value to go from zero to non-zero. This value defaults to 20000 and is denoted asG_sset
.
These five new parameters can be calculated as follows:
G_txnewaccount
=account_bytes * gas_per_byte
G_newaccount
=account_bytes * gas_per_byte
G_txcreate
=contract_fixed_bytes * gas_per_byte
G_codedeposit
=gas_per_byte
G_sset
= 2900 +storage_slot_bytes * gas_per_byte
Each of these five parameters are accounted for an stored when establishing an updated gas cost.
General Hard Fork Solution
EOS EVM now officially supports multiple versions and the ability to perform a hard forks when required for future versions such as London Hard Fork detailed above.
This release implements a linear versioning system for EOS EVM hard forks, mapping each EOSEVM version to a corresponding EVMC revision:
EOSEVM Version | EVMC Revision |
---|---|
0 | ISTANBUL |
1 | SHANGHAI |
Note: for this release, EOS EVM is moving directly from Instanbul to Shanghai, including all support for London Hard Fork within that version.
Benefits
- Improved Transaction Efficiency: By adopting EIP-1559 and the PUSH0 opcode, EOS EVM ensures transactions are processed more efficiently, with a fee structure that adapts to network demand and simplifies certain operations.
- Cost Reduction and Predictability: The dual fee mechanism under EIP-1559, coupled with the dynamic gas fee algorithm, offers users a more predictable and often lower cost structure, especially less complex less or RAM-intensive transactions.
Bug fixes
MDBX configuration creating mapsize issue
The shared and exculsive flags set for MDBX were leading to an MDBX_MAP_FULL error.
Error building with ARM
There was an issue where the ARM version of protobuf was not being fetched properly and causing CMAKE to fail.
Building, compatibility, and upgrading
Building
The README in the eos-evm-node repository contains instructions on how to build EOS EVM Node and EOS EVM RPC.
Compatibility and upgrading
EOS EVM Node and EOS EVM RPC can be upgraded from the prior 0.7.x version by replacing the binaries.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (144) bump abieos submodule
- (157) [0.7 -> main] blockchain-plugin: Shutdown node on error during block processing
- (162) [0.7 -> main] Merge nginx config change for long connection
- (164) [0.7 -> main] Update silkworm with fixes in fork switching
- (165) [0.7->main] Merge in nginx docker file fix for WS_ENDPOINT
- (168) [0.7 -> main] Bump 0.7.0-rc2 version
- (174) Update README.md
- (170) Support sync start from certain evm height
- (176) [0.7->main] Disable deprecated ship-start-from options
- (178) [0.7 -> main] Update README
- (180) [0.7 -> main] Bump 0.7.0 version
- (172) Add evmtx actions processing
- ([185](https://github...
EOS EVM Node v0.7.0
The latest release of EOS EVM Node introduces WebSocket support for EOS EVM, an RPC compatibility change, and several updates to improve system performance under heavy load.
This release contains changes to EOS EVM Node, EOS EVM RPC, EOS EVM Miner, and tx_proxy. This release also introduces eos-evm-ws-proxy.
Read on for more details.
New features
WebSocket support
PRs
WebSocket functionality is now supported via thew WebSocket Proxy (eos-evm-ws-proxy) which allows developers and users to establish real-time communication channels with the blockchain network. This initial implementation enables instant updates on events, transactions, and contract state changes, enhancing the user experience and enabling more interactive features in dApps.
The WebSocket proxy can be found within peripherals/eos-evm-ws-proxy
.
Other changes
Support the block parameter scheme for eth_call
PRs
- (134) Allow use object with "blockHash" and "blockNumber" field to specify block in eth_call and some other calls
The JSON-RPC method eth_call has been updated to add support for the use of an object to specify blockHash
and blockNumber
as part of the block parameter scheme.
Node fork handling behavior
Shut down EOS EVM Node when encountering error during block processing
Unexpected behavior was observed where Silkworm would continue to attempt to process transactions in later blocks when a previous block necessary to execute could not be found in the database, leading to a wrong nonce error. The behavior has been updated to shut down the node in these scenarios instead of continuing to attempt to process transactions.
Always ensure block is added to database regardless of header existing in cache
It was discovered that the fork switching logic in Silkworm does not clear the block header from the cache, which can lead to an edge case where a node recovering from a fork cannot add a block to the database when a block header is already previously stored. An update has been made to add blocks to the database even when a block header may be stored in the cache.
Miner connection settings
Use keepalive in tx-proxy to resolve http connection limit for miner
During a high traffic event the http connection limit in tx-proxy was being hit for EOS EVM Miner. The keepalive setting has been implemented for this connection to enable long connections from tx_proxy to miner as a workaround.
Feature Lifecycle Updates
All deprecated features, not yet removed
ship-start-from options
The mechanism to start EOS EVM Node from a specific block was discovered to not work as intended and as a result has been deprecated for removal in a future release.
Building, compatibility, and upgrading
Building
The README in the eos-evm-node repository contains instructions on how to build EOS EVM Node and EOS EVM RPC.
Compatibility and upgrading
EOS EVM Node and EOS EVM RPC can be upgraded from the prior 0.6.x version by replacing the binaries.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (54) [0.6 -> main] Update silkworm
- (57) [0.6 -> main] update submodule to contain the fix. #55
- (59) [0.6 -> main] Bump 0.6.0-rc2 version
- (78) [0.6 -> main] Update silkworm (fix HashState stage, speed up Senders stage)
- (80) [0.6 -> main] Bump 0.6.0 version
- (74) Add initial version of eos-evm-ws-proxy
- (102) [0.6->main] Support batch requests in tx_proxy
- (104) [0.6->main] Update silkworm to include 0.6.1 fixes
- (87) basic websocket integration test
- (107) websocket: use batch request in getLogs
- (111) Add launch scripts
- (110) eos-evm-ws-proxy blockmonitor: Fix fork handling
- (117) [0.6->main] Merge in release 0.6 fix: trace quirk mode, eth_call blockhash fix, and eth_estimateGas now accept extra parameter
- (116) Update nginx config to support websocket traffic.
- (99) Websocket integration test for fork handling
- (119) route websocket proxy traffics to different destinations
- (124) [0.6 ->main] Merge in the fix for the quirk mode. Also include some fix to CI
- (127) [0.6->main] Update silkworm with PR #99 (EVMExecutor::reset fix)
- (130) [0.6 -> main] Bump 0.6.3 version
- (129) Prepare rate limit in nginx config files
- (131) Add ship-receiver-plugin defer tests
- (134) Allow use object with "blockHash" or "blockBumber" field to specify block in eth_call and some other calls
- (137) Add special signatures handling integration tests
- (136) ensure log always available if the same block is available
- (138) Update silkworm to HEAD of master
- (139) Bump 0.7.0-rc1 version
- (156) [0.6 -> 0.7] blockchain-plugin: Shutdown node on error during block processing
- (158) [0.6->0.7] Merge nginx config change for long connection
- (161) [0.6 -> 0.7] Update silkworm with fixes in fork switching
- (141) [0.7] Fix docker file to take WS_ENDPOINT
- (167) [0.7] Bump 0.7.0-rc2 version
- (169) [0.6] Disable deprecated ship-start-from options.
- (173) [0.6->0.7] pull option changes to disable ship-start-from options
- (175) [0.7] Update README.md
- (179) [0.7] Bump 0.7.0 version
Full Changelog: v0.6.3...v0.7.0
EOS EVM Node v0.7.0-rc2
This latest patch release includes fixes to Silkworm fork handling behavior and improved connection settings for eos-evm-miner.
This release contains changes to EOS EVM Node, EOS EVM RPC, and tx-proxy.
Read on for more details.
Updates
Node fork handling behavior
Shut down EOS EVM Node when encountering error during block processing
Unexpected behavior was observed where Silkworm would continue to attempt to process transactions in later blocks when a previous block necessary to execute could not be found in the database, leading to a wrong nonce error. The behavior has been updated to shut down the node in these scenarios instead of continuing to attempt to process transactions.
Always ensure block is added to database regardless of header existing in cache
It was discovered that the fork switching logic in Silkworm does not clear the block header from the cache, which can lead to an edge case where a node recovering from a fork cannot add a block to the database when a block header is already previously stored. An update has been made to add blocks to the database even when a block header may be stored in the cache.
Miner connection settings
Use keepalive in tx-proxy to resolve http connection limit for miner
During a high traffic event the http connection limit in tx-proxy was being hit for EOS EVM Miner. The keepalive setting has been implemented for this connection to enable long connections from tx_proxy to miner as a workaround.
Building, compatibility, and upgrading
Building
The README in the eos-evm-node repository contains instructions on how to build EOS EVM Node and EOS EVM RPC.
Compatibility and upgrading
EOS EVM Node and EOS EVM RPC can be upgraded from the prior version by replacing the binaries.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
EOS EVM Node v0.6.4
This latest patch release includes fixes to Silkworm fork handling behavior and improved connection settings for eos-evm-miner.
This release contains changes to EOS EVM Node, EOS EVM RPC, and tx-proxy.
Read on for more details.
Updates
Node fork handling behavior
Shut down EOS EVM Node when encountering error during block processing
Unexpected behavior was observed where Silkworm would continue to attempt to process transactions in later blocks when a previous block necessary to execute could not be found in the database, leading to a wrong nonce error. The behavior has been updated to shut down the node in these scenarios instead of continuing to attempt to process transactions.
Always ensure block is added to database regardless of header existing in cache
It was discovered that the fork switching logic in Silkworm does not clear the block header from the cache, which can lead to an edge case where a node recovering from a fork cannot add a block to the database when a block header is already previously stored. An update has been made to add blocks to the database even when a block header may be stored in the cache.
Miner connection settings
Use keepalive in tx-proxy to resolve http connection limit for miner
During a high traffic event the http connection limit in tx-proxy was being hit for EOS EVM Miner. The keepalive setting has been implemented for this connection to enable long connections from tx_proxy to miner as a workaround.
Building, compatibility, and upgrading
Building
The README in the eos-evm-node repository contains instructions on how to build EOS EVM Node and EOS EVM RPC.
Compatibility and upgrading
EOS EVM Node and EOS EVM RPC can be upgraded from the prior version by replacing the binaries.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
EOS EVM Node v0.7.0-rc1
The latest release candidate of EOS EVM Node introduces WebSocket support for EOS EVM and one additional compatibility change.
This release contains changes to EOS EVM Node, EOS EVM RPC, and tx_proxy. This release also introduces eos-evm-ws-proxy.
Read on for more details.
New features
WebSocket support
PRs
WebSocket functionality is now supported via thew WebSocket Proxy (eos-evm-ws-proxy) which allows developers and users to establish real-time communication channels with the blockchain network. This initial implementation enables instant updates on events, transactions, and contract state changes, enhancing the user experience and enabling more interactive features in dApps.
The WebSocket proxy can be found within peripherals/eos-evm-ws-proxy
.
Other changes
Support the block parameter scheme for eth_call
PRs
- (134) Allow use object with "blockHash" and "blockNumber" field to specify block in eth_call and some other calls
The JSON-RPC method eth_call has been updated to add support for the use of an object to specify blockHash
and blockNumber
as part of the block parameter scheme.
Building, compatibility, and upgrading
Building
The README in the eos-evm-node repository contains instructions on how to build EOS EVM Node and EOS EVM RPC.
Compatibility and upgrading
EOS EVM Node and EOS EVM RPC can be upgraded from the prior 0.6.x version by replacing the binaries.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (54) [0.6 -> main] Update silkworm
- (57) [0.6 -> main] update submodule to contain the fix. #55
- (59) [0.6 -> main] Bump 0.6.0-rc2 version
- (78) [0.6 -> main] Update silkworm (fix HashState stage, speed up Senders stage)
- (80) [0.6 -> main] Bump 0.6.0 version
- (74) Add initial version of eos-evm-ws-proxy
- (102) [0.6->main] Support batch requests in tx_proxy
- (104) [0.6->main] Update silkworm to include 0.6.1 fixes
- (87) basic websocket integration test
- (107) websocket: use batch request in getLogs
- (111) Add launch scripts
- (110) eos-evm-ws-proxy blockmonitor: Fix fork handling
- (117) [0.6->main] Merge in release 0.6 fix: trace quirk mode, eth_call blockhash fix, and eth_estimateGas now accept extra parameter
- (116) Update nginx config to support websocket traffic.
- (99) Websocket integration test for fork handling
- (119) route websocket proxy traffics to different destinations
- (124) [0.6 ->main] Merge in the fix for the quirk mode. Also include some fix to CI
- (127) [0.6->main] Update silkworm with PR #99 (EVMExecutor::reset fix)
- (130) [0.6 -> main] Bump 0.6.3 version
- (129) Prepare rate limit in nginx config files
- (131) Add ship-receiver-plugin defer tests
- (134) Allow use object with "blockHash" or "blockBumber" field to specify block in eth_call and some other calls
- (137) Add special signatures handling integration tests
- (136) ensure log always available if the same block is available
- (138) Update silkworm to HEAD of master
- (139) Bump 0.7.0-rc1 version
EOS EVM Node v0.6.3
This latest patch release includes a bug fix.
This release contains changes to EOS EVM Node and EOS EVM RPC.
Read on for more details.
Bug fixes
Extend EVMExecutor to perform both complete and partial resets of its internal state
In scenarios where multiple EVM transactions happen in the same EVM block (which is one Leap transaction containing multiple eosio.evm::pushtx) a bug was uncovered where the trace API was not properly calculating the correct state, leading to incorrectly reported transaction statuses. An update has been made to EVMExecutor to be able to perform complete and partial resets of internal state to resolve this discrepancy.
Because silkworm's execution engine is separate from the trace engine, this bug would never result in a direct risk of token loss and has not been deemed a security issue.
Building, compatibility, and upgrading
Building
The README in the eos-evm-node repository contains instructions on how to build EOS EVM Node and EOS EVM RPC.
Compatibility and upgrading
EOS EVM Node and EOS EVM RPC can be upgraded from the prior version by replacing the binaries.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
EOS EVM Node v0.6.2
This latest patch release includes a bug fix and updates to calls to match current Ethereum client standards.
This release contains changes to EOS EVM Node and EOS EVM RPC.
Read on for more details.
Bug fixes
Patch for blockscout trace calls edge case
It was observed in EOS EVM Node v0.6.0 that blockscout would mark some failed transactions as successful. The root cause was that the traces had both error and result fields set but blockscout does not anticipate that behavior.
Currently, the blockscout team plans to keep their designed behavior until there is stronger support for an update. For now, we have implemented a patch to accomodate for this discrepancy. The explorer nodes had already been patched with this verison, and this release is now formalizing this change across all nodes.
Other changes
Support for block_number_or_hash
as parameter in eth_call
eth_call
now supports the parameter, block_number_or_hash
properly. Previously, this call only accepted block_id
.
Partial support for block_tag
parameter in eth_estimateGas
eth_estimateGas
now partially supports the second parameter, block_tag
. For now, the call will return a -39001: Unknown block
error if the block tag2 is earliest
, finalized
, or safe
. If the tag is latest
or pending
then it will execute the transaction to estimate gas on the latest block. This means pending
is acting like latest
.
Building, compatibility, and upgrading
Building
The README in the eos-evm-node repository contains instructions on how to build EOS EVM Node and EOS EVM RPC.
Compatibility and upgrading
EOS EVM Node and EOS EVM RPC can be upgraded from the prior 0.6.1 version by replacing the binaries.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
EOS EVM Node v0.6.1
This latest patch release includes several bug fixes and updates to calls to match current Ethereum client standards.
This release contains changes to EOS EVM Node, EOS EVM RPC, and tx_proxy.
Read on for more details.
Bug fixes
Support for batch requests in tx_proxy
Support for batch requests was introduced in EOS EVM Node v0.6.0, however, an issue was recently found with tx_proxy. If a batch request included methods to send transaction or get gas price (which EOS EVM RPC does not support since EOS EVM Miner is supposed to handle it), then the batch requests could previously fail.
Correction to trace_block API reports for mining rewards
No EOS was ever actually minted per block as mining rewards. However, an error in the trace_block API incorrectly reported that 2 EOS was minted per block. This error has now been fixed to correctly report that 0 EOS is minted per block as mining rewards.
Other changes
Support for input parameter in eth_call
Due to recent updates to use the field name input
instead of data
in transactions by other clients, an update has been made with the following logic for best compatibility:
- If only one field is set, use that field.
- If both fields are set and identical, just pick a field one.
- If both fields are set but not the same, reject the call.
Building, compatibility, and upgrading
Building
The README in the eos-evm-node repository contains instructions on how to build EOS EVM Node and EOS EVM RPC.
Compatibility and upgrading
EOS EVM Node and EOS EVM RPC can be upgraded from the prior 0.6.0 version by replacing the binaries.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
EOS EVM Node v0.6.0
EOS EVM Node brings the components EOS EVM Node and EOS EVM RPC from the eos-evm repository into its own repository: eos-evm-node. In addition, the 0.6.0 release of EOS EVM Node introduces improvements over prior versions.
New features
Recent changes from upstream silkworm
More recent improvements from the upstream silkworm repository were brought into the ENF fork of silkworm which is a critical component of EOS EVM Node.
That automatically gives EOS EVM Node some enhancements such as batch request support.
Batch requests support
Users can now submit multiple actions or transactions to the EVM as a single request. This enhances efficiency, reduces transaction costs, and provides a better user experience for interacting with smart contracts and dApps.
Bug fixes
Trace executor now generates trace for calls to pre-compiled contract addresses
In the previous versions, a transfer or call to an address of a pre-compiled contract would erroneously not generate a trace. Traces are now generated for calls to pre-compiled contract addresses.
Building, compatibility, and upgrading
Building
The README in the eos-evm-node repository contains instructions on how to build EOS EVM Node and EOS EVM RPC.
Compatibility and upgrading
EOS EVM Node and EOS EVM RPC can be upgraded from the prior 0.5.2 version by replacing the binaries and relaunching with a replay.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
This is the first stable release from the new repository, so a GitHub link to compare all changes since the 0.5.2 release cannot be provided. But the list of all PRs merged in the new repository is provided below.
PRs
- (1) Many fixes
- (4) Merge elmato/dev
- (7) Update silkworm
- (8) Use regular endpoints as the default values in command line options
- (10) Fix compilation
- (16) Get EOS EVM Node Build job to succeed
- (17) eos-evm-node repo integration test
- (18) Update supported Ubuntu and gcc versions in README
- (3) Refactor to allow reconnection to SHiP endpoints after connection lost.
- (21) Replace tx_wrapper with eos-evm-miner for integration test.
- (27) fix special signature handling
- (32) Correct processing of pushtx actions in ship_receiver_plugin
- (42) Add conan install to build instructions
- (41) Fix nodeos_eos_evm_server.py
- (43) Fix eos-evm-rpc crash
- (44) Bump 0.6.0-rc1 version
- (47) [0.6] Fix eth_call id bug
- (53) [0.6] Update silkworm
- (55) [0.6] update submodule to contain the fix.
- (58) [0.6] Bump 0.6.0-rc2 version
- (72)[0.6] Update silkworm (fix HashState stage, speed up Senders stage)
- (79) Bump 0.6.0 version