Releases: eosnetworkfoundation/eos-evm-node
EOS EVM Node v1.0.4
Introduction
The latest patch release of EOS EVM Node introduces fixes for edge cases where state history connections may enter a stuck state and where call_eth would return insufficient gas values.
Read on for more details.
Updates
Improper use of state history's get_blocks_ack_request_v0 leading to "stuck" state history connection
EOS EVM Node was incorrectly using the get_blocks_ack_request_v0 interface, which could lead to the state history connection entering a stuck state. send_get_blocks_ack_request has been removed to fix this issue.
call_eth returns insufficient gas when called with from field
When called with the from field, call_eth was returning insufficient gas values due to max_fee_per_gas, which had be previously added to resolve a prior assertion error. Because this issue was previously fixed, this part has been removed.
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 1.0.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
Full Changelog: v1.0.3...v1.0.4
Contributors
Assets 2
EOS EVM Node v1.0.3
Introduction
The latest patch release of EOS EVM Node introduces fixes to gas estimation failures.
Read on for more details.
Updates
Gas estimation failing when the contract accesses EvmHost::get_tx_context
It was observed that the effective_gas_price was being calculated incorrectly in EvmHost::get_tx_context impacting gas estimation and traces.
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 1.0.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
Full Changelog: v1.0.2...v1.0.3
Contributors
Assets 2
EOS EVM Node v1.0.2
Introduction
The latest patch release of EOS EVM Node introduces a fix to an EOS EVM transaction ordering edge case and the application of a Business Service License (BSL) for the EOS EVM Node codebase.
Read on for more details.
Updates
EOS EVM Transaction Order Discrepancy
Edge cases were discovered where transactions may be incorrectly ordered if more than one EOS transaction took place from the same address within one block. An update has been made to ensure transactions use the evmtx parent sequence number. No instances of this scenario have occurred for EOS EVM Mainnet.
Business Service License
PRs
The EOS EVM Node codebase has transitioned to a Business Service License (BSL), which introduces a structured licensing framework that promotes responsible and open use of the code. The BSL allows for commercial use while encouraging contributors and users to adhere to the terms outlined in the license. This change supports continued innovation within the EOS ecosystem and ensures that all users have a consistent and fair understanding of usage rights. More information can be found in the repo’s license file.
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 1.0.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
Full Changelog: v1.0.1...v1.0.2
Contributors
Assets 2
EOS EVM Node v1.0.1
Introduction
The latest patch release of EOS EVM Node introduces fixes to the TraceCallExecutor and EVMExecutor related to newly introduced EOS EVM versions and gas parameters. This update improves the accuracy of gas calculations and resolves specific refund handling issues.
Read on for more details.
Updates
EVMExecutor using the wrong refund algorithm for certain EOS EVM versions
It was discovered that the refund mechanism was incorrectly implemented for EOS EVM versions greater than 0. Specifically, EVMExecutor was applying a refund algorithm that miscalculated gas refunds.
Perform a gas bailout when no from address is specified for EVMExecutor
It was discovered that EVMExecutor could encounter issues during transaction execution when no from address was specified, resulting in execution errors or incomplete transactions. This update introduces a gas bailout to manage these cases.
TraceCallExecutor using incorrect gas parameters for the transaction being traced
It was discovered that TraceCallExecutor was not correctly assigning gas parameters when tracing transactions, causing discrepancies in gas usage and tracing accuracy.
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 1.0.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
Full Changelog: v1.0.0...v1.0.1
Contributors
Assets 2
EOS EVM Node v1.0.0
Introduction
The latest release of EOS EVM introduces support for Shanghai and London Hard Fork and their comprised features, a new gas fee algorithm to more accurately price transactions for underlying resource costs involved, and configuration settings to adjust the base token of the network.
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
CALLorSELFDESTRUCTopcodes. This value defaults to to 25000 and is denoted asG_newaccount. - Static gas consumed in the
CREATEandCREATE2opcodes 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
CREATEandCREATE2opcodes, 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
SSTOREopcode 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_byteG_newaccount=account_bytes * gas_per_byteG_txcreate=contract_fixed_bytes * gas_per_byteG_codedeposit=gas_per_byteG_sset= 2900 +storage_slot_bytes * gas_per_byte
Each of these five parameters are accounted for an stored when establishing an updated gas cost.
Change max gas refund in ExecutionProcessor to 100% with a limit in the minimum gas used of 21k
The max refund setting of 20% as part of the standard protocol has been updated to 100% to improve overall user experience as the next generation of the gas fee algorithm is developed.
Increase kGasCap in EstimateGasOracle to 100M
The new gas fee parameters result in gas consumption estimates larger than the previous 25M limit set in the gas fee oracle. This cap has been increased to 100M in order to support these new value ranges.
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.
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. If upgrading from v1.0.0-rc1 or v1.0.0-rc2 replay is needed.
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](https://github.com/eosnetworkfoundation/eos-evm-...
Contributors
Assets 2
EOS EVM Node v0.7.1
The latest patch release of EOS EVM Node introduces a bug fix to flags set improperly for MDBX and a unit discrepancy for a test.
Read on for more details.
Bug fixes
Wrong flag when opening database
It was discovered that use the exclusive and shared flag for MDBX was being used incorrectly, which was leading performance issues.
Unit comparison issue in block_conversion_plugin_impl::timestamp_to_evm_block_num
A mismatch in the units being compared to detect if a transaction occurs before the genesis timestamp was discovered.
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.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
Full Changelog: v0.7.0...v0.7.1
Contributors
Assets 2
EOS EVM Node v1.0.0-rc4
Introduction
The latest release candidate of EOS EVM Node includes updates to resolve an issue discovered with disproportionally high gas fees and insufficient returns for certain types of transactions related to the new gas fee algorithm.
Read on for more details.
Updates
Make an exception for privileged accounts when calculating gas
It was discovered that privileged accounts were being treated as if they were new, not previously created accounts when calculating gas fees. An update has been made to make an exception for these accounts for all operations.
Change max gas refund in ExecutionProcessor to 100% with a limit in the minimum gas used of 21k
In certain scenarios, where disproportionately high gas fees were charged, inadequate refunds were returned due to the max refund setting of 20% as part of the protocol. This value has been updated to a max of 100% to improve overall user experience as the next generation of the gas fee algorithm is developed.
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. If upgrading from v1.0.0-rc1 or v1.0.0-rc2 replay is needed.
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
Full Changelog: v1.0.0-rc3...v1.0.0-rc4
Contributors
Assets 2
EOS EVM Node v1.0.0-rc3
Introduction
The latest release candidate introduces a fix to issues discovered with how non-legacy transactions where serialized into the database.
Read on for more details.
Updates
Change db serialization format for non-legacy transactions
The eos-evm-node previously stored RLP-serialized transactions in the database in a format that prevented directly obtaining the transaction hash by hashing the binary blob data. The current fix uses a transaction binary representation compatible with direct hashing, as other parts of the code assumed that representation.
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. If upgrading from v1.0.0-rc1 or v1.0.0-rc2 replay is needed.
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
- (221) [1.0->main] add integration test for differen test token
- (225) [1.0 -> main] Bump 1.0.0-rc1 version
- (226) [1.0 -> main] Use updated silkworm with the new block-extra-data storage
- (227) [1.0 -> main] Bump 1.0.0-rc2 version
- (231) [1.0] add get transaction & get transaction receipt from rpc test
- (232) [1.0] Update silkworm 1.0.1
- (233) [1.0] Bump 1.0.0-rc3 version
Full Changelog: v1.0.0-rc2...v1.0.0-rc3
Contributors
Assets 2
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
Contributors
Assets 2
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
CALLorSELFDESTRUCTopcodes. This value defaults to to 25000 and is denoted asG_newaccount. - Static gas consumed in the
CREATEandCREATE2opcodes 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
CREATEandCREATE2opcodes, 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
SSTOREopcode 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_byteG_newaccount=account_bytes * gas_per_byteG_txcreate=contract_fixed_bytes * gas_per_byteG_codedeposit=gas_per_byteG_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...