Releases: eosnetworkfoundation/eos-evm-contract
EOS EVM Contract 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 handled 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 fee 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. In EOS EVM, the priority fee does not prioritize transactions. Instead, it is a fee set by the miner to cover their costs for processing the transaction and pushing it into the network. This fee goes directly to the miner and is not burned.
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.
Configurable Base Token
EOS EVM now has the ability to be deployed with a different base token for fees and a different chain id as a configuration setting. This enables other EVM instances to exist that utilize other ecosystem tokens, such as BTC for exSat.
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
Allow transfer of non-EOS tokens out of contract account
PRs
Previously, only EOS was capable of being moved out of the contract account in order to be utilized for operational costs. Recent updates now allow other token types to be transferred out of the account.
Building, compatibility, and upgrading
Building
The README in the eos-evm repository contains instructions on how to build EOS EVM Contract.
Compatibility and upgrading
EOS EVM Contract can be upgraded from the prior 0.6.0 version by simply deploying the WASM and ABI.
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
- (665)[0.6 -> main] Bump 0.6.0 version
- (667) fix unittest compile error, explicitly set inline action size to 4kB
- (675) [0.6] Allow transfer non-EOS tokens out.
- (676) [0.6->main] Allow transfer non-EOS tokens out
- (665) [0.6 -> main] Bump 0.6.0 version
- (667) fix unittest compile error, explicitly set inline action size to 4kB
- (675) [0.6] Allow transfer non-EOS tokens out.
- ([676](http...
Contributors
Assets 2
EOS EVM Contract v1.0.0-rc4
Introduction
The latest release candidate of EOS EVM Contract 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
The README in the eos-evm repository contains instructions on how to build EOS EVM Contract.
Compatibility and upgrading
EOS EVM Contract can be upgraded from the prior 0.6.0 version by simply deploying the WASM and ABI.
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-rc3...v1.0.0-rc4
Contributors
Assets 2
EOS EVM Contract v1.0.0-rc3
Introduction
The latest release candidate of the EOS EVM Contract includes restrictions on RLP formats when decoding input transactions.
Read on for more details.
Updates
Restrict rlp formats when decoding transaction
It was discovered that the EVM contract allowed the deserialization of certain RLP formats for input transactions, which could cause the miner to generate a different transaction hash than the one the transaction originally had.
Building
The README in the eos-evm repository contains instructions on how to build EOS EVM Contract.
Compatibility and upgrading
EOS EVM Contract can be upgraded from the prior 0.6.0 version by simply deploying the WASM and ABI.
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-rc2...v1.0.0-rc3
Contributors
Assets 2
EOS EVM Contract v1.0.0-rc2
Introduction
The latest release candidate of EOS EVM Contract includes a fix to how handle_evm_transfer manages gas_limit to align with the new gas fee algorithm.
Read on for more details.
Updates
Make gas_limit in handle_evm_transfer dynamic based on the existence of the destination address
It was discovered that gas_limit in handle_evm_transfer had not been modified to update dynamically in support of changes in the gas fee algorithm associated with this release.
Building
The README in the eos-evm repository contains instructions on how to build EOS EVM Contract.
Compatibility and upgrading
EOS EVM Contract can be upgraded from the prior 0.6.0 version by simply deploying the WASM and ABI.
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 Contract 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 handled 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 fee 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. In EOS EVM, the priority fee does not prioritize transactions. Instead, it is a fee set by the miner to cover their costs for processing the transaction and pushing it into the network. This fee goes directly to the miner and is not burned.
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
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.
Bug fixes
Allow transfer of non-EOS tokens out of contract account
PRs
Previously, only EOS was capable of being moved out of the contract account in order to be utilized for operational costs. Recent updates now allow other token types to be transferred out of the account.
Other changes
Dynamically support different base token via init
The initial work required in the contract to support different base tokens for EOS EVM is introduced in this release. Full support for this feature across other related repos will be part of a future release.
Building, compatibility, and upgrading
Building
The README in the eos-evm repository contains instructions on how to build EOS EVM Contract.
Compatibility and upgrading
EOS EVM Contract can be upgraded from the prior 0.6.0 version by simply deploying the WASM and ABI.
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
- (665)[0.6 -> main] Bump 0.6.0 version
- (667) fix unittest compile error, explicitly set inline action size to 4kB
- (675) [0.6] Allow transfer non-EOS tokens out.
- (676) [0.6->main] Allow transfer non-EOS tokens out
- (665) [0.6 -> main] Bump 0.6.0 version
- (667) fix unittest compile error, explicitly set inline action size to 4kB
- (675) [0.6] Allow transfer non-EOS tokens out.
- (676) [0.6->main] Allow transfer non-EOS tokens out
- (677) Add support for EOSEVM version
- (681) use libtester 5.0 in CI; use ubuntu 22.04 for CI...
Contributors
Assets 2
EOS EVM Contract v0.6.0
This release rearranges how EOS EVM components are organized within the eos-evm repository. This repository now only contains the EOS EVM Contract which has been upgraded to provide new functionality in support of an enhanced Trustless Bridge.
New features
Enhancements to the Trustless Bridge
Prior to this release, the Trustless Bridge of the EOS EVM only supporting the EOS token between the EVM and EOS environments.
This release adds two new mechanism which provide the foundation necessary for other components to expand the Trustless Bridge far beyond its initial capabilities:
callaction- Bridge messages
The release of EOS EVM Bridge Contracts demonstrates how these mechanisms can be used to enable other tokens on EOS such as USDT to be moved across the Trustless Bridge to the EOS EVM side and then back to to the EOS Native side.
call action
The EOS EVM Contract now has a new action named call which is similar to a pushtx except that it can be called by an EOS account under the authority of that account. For example, an EOS account test could use the call action to send an EVM transaction that came from the reserved address that maps to the test account. The funds to pay for the gas and any value of the EVM transaction comes from the open balance of the test account within the EOS EVM Contract.
Bridge messages
This release of EOS EVM Contract also introduces the mechanism of bridge messages.
Calls to the reserved address mapped to the eosio.evm account with non-empty call data will now be treated with stricter validation. They must match a function signature that is used to emit new bridge messages on the EOS Native side. If the call data does not appropriately encode the expected function call, the EOS transaction will abort.
Assuming the encoding is correct, further validation is done by the EOS EVM Contract. The receiver account specified in the function call must be registered as a receiver in the EOS EVM Contract. Furthermore, if it enforces a minimum fee, the value transferred alongside the call to the reserved address mapped to the eosio.evm account must be no less than minimum fee specified by the registered receiver. If these conditions are not met, the EOS transaction will abort.
If the conditions are met, a onbridgemsg inline action is sent by EOS EVM Contract to the handler account specified by the registered receiver which contains the data relevant to the emitted bridge message.
Building, compatibility, and upgrading
Building
The README in the eos-evm repository contains instructions on how to build EOS EVM Contract.
Compatibility and upgrading
EOS EVM Contract can be upgraded from the prior 0.5.2 version by simply deploying the WASM and ABI.
Feature lifecycle updates
Removals
TX-Wrapper removed
TX-Wrapper was deprecated in the 0.5.2 release and has now been removed. Users are recommended to switch to eos-evm-miner instead.
EOS EVM Node and EOS EVM RPC moved
EOS EVM Node and EOS EVM RPC have been removed from this repository. They are still supported but now live in their own eos-evm-node repository.
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
- (564) Remove SSH URL for git submodules
- (520) update contract unit tests to work with libtester from leap's main branch
- (561) Update nonce description in deployment docs
- (380) Add scripts to measure EVM contract performance
- (595) [0.5 -> main] EstimateGasOracle: fix estimate_gas; Return better result when accessed by GET
- (599) [0.5->main]Handle transfers from reserved address in the same way as other places
- (580) Fix documentation
- (623) [0.5 -> main] Enforce chain-id in transactions pushed to the contract
- (628) Repository refactor
- (639) Reduce artifact size remove obj
- (634) Add call actions
- (641) Update silkworm submodule
- (643) Bridge basic message emission (2)
- (646) Add assertnonce action.
- (647) Add handler option to bridge message feature.
- (652) [0.5 -> main] Change account id generation logic
- (654) [0.5 -> main] Add admin actions
- (656) [0.5 -> main] Correct processing of pushtx actions in ship_receiver_plugin
- (658) [0.5 -> main] bump version 0.5.2
- (659) Update silkworm
- (660) Bump 0.6.0-rc1 version
- (664) [0.6] Bump 0.6.0 version
Full Changelog: v0.5.2...v0.6.0
Contributors
Assets 2
EOS EVM Contract v0.6.0-rc1
This release rearranges how EOS EVM components are organized within the eos-evm repository. This repository now only contains the EOS EVM Contract which has been upgraded to provide new functionality in support of an enhanced Trustless Bridge.
New features
Enhancements to the Trustless Bridge
Prior to this release, the Trustless Bridge of the EOS EVM only supporting the EOS token between the EVM and EOS environments.
This release adds two new mechanism which provide the foundation necessary for other components to expand the Trustless Bridge far beyond its initial capabilities:
callaction- Bridge messages
The release of EOS EVM Bridge Contracts demonstrates how these mechanisms can be used to enable other tokens on EOS such as USDT to be moved across the Trustless Bridge to the EOS EVM side and then back to to the EOS Native side.
call action
The EOS EVM Contract now has a new action named call which is similar to a pushtx except that it can be called by an EOS account under the authority of that account. For example, an EOS account test could use the call action to send an EVM transaction that came from the reserved address that maps to the test account. The funds to pay for the gas and any value of the EVM transaction comes from the open balance of the test account within the EOS EVM Contract.
Bridge messages
This release of EOS EVM Contract also introduces the mechanism of bridge messages.
Calls to the reserved address mapped to the eosio.evm account with non-empty call data will now be treated with stricter validation. They must match a function signature that is used to emit new bridge messages on the EOS Native side. If the call data does not appropriately encode the expected function call, the EOS transaction will abort.
Assuming the encoding is correct, further validation is done by the EOS EVM Contract. The receiver account specified in the function call must be registered as a receiver in the EOS EVM Contract. Furthermore, if it enforces a minimum fee, the value transferred alongside the call to the reserved address mapped to the eosio.evm account must be no less than minimum fee specified by the registered receiver. If these conditions are not met, the EOS transaction will abort.
If the conditions are met, a onbridgemsg inline action is sent by EOS EVM Contract to the handler account specified by the registered receiver which contains the data relevant to the emitted bridge message.
Building, compatibility, and upgrading
Building
The README in the eos-evm repository contains instructions on how to build EOS EVM Contract.
Compatibility and upgrading
EOS EVM Contract can be upgraded from the prior 0.5.2 version by simply deploying the WASM and ABI.
Feature lifecycle updates
Removals
TX-Wrapper removed
TX-Wrapper was deprecated in the 0.5.2 release and has now been removed. Users are recommended to switch to eos-evm-miner instead.
EOS EVM Node and EOS EVM RPC moved
EOS EVM Node and EOS EVM RPC have been removed from this repository. They are still supported but now live in their own eos-evm-node repository.
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
- (564) Remove SSH URL for git submodules
- (520) update contract unit tests to work with libtester from leap's main branch
- (561) Update nonce description in deployment docs
- (380) Add scripts to measure EVM contract performance
- (595) [0.5 -> main] EstimateGasOracle: fix estimate_gas; Return better result when accessed by GET
- (599) [0.5->main]Handle transfers from reserved address in the same way as other places
- (580) Fix documentation
- (623) [0.5 -> main] Enforce chain-id in transactions pushed to the contract
- (628) Repository refactor
- (639) Reduce artifact size remove obj
- (634) Add call actions
- (641) Update silkworm submodule
- (643) Bridge basic message emission (2)
- (646) Add assertnonce action.
- (647) Add handler option to bridge message feature.
- (652) [0.5 -> main] Change account id generation logic
- (654) [0.5 -> main] Add admin actions
- (656) [0.5 -> main] Correct processing of pushtx actions in ship_receiver_plugin
- (658) [0.5 -> main] bump version 0.5.2
- (659) Update silkworm
- (660) Bump 0.6.0-rc1 version
Full Changelog: v0.5.2...v0.6.0-rc1
Contributors
Assets 2
EOS EVM v0.5.2 Release Notes
This release fixes several security vulnerabilities discovered in EOS EVM Contract and EOS EVM Node.
Components
EOS EVM Contract
Prevent account ID reuse
The use of available_primary_key from multi_index to determine the internal account ID of a new EVM account was undesirable because that internal account ID would be reused by new EVM account after the previous account that was using that ID destroyed itself via the SELFDESTRUCT EVM opcode.
But this undesired behavior actually was a security issue due to another design decision in EOS EVM Contract to delay clean up of contract account state to later calls of the gc action; this design decision needed to be made due to the limitation that EOS transaction execution time is tightly bounded but the same is not true for the number of storage slots that an EVM contract may have accumulated over time. The design of delaying garbage collection of a self-destructed contract storage for later was safe under the assumption that internal account IDs would never be reused. Unfortunately, due to the way internal account IDs for new accounts were generated, that assumption did not hold.
The fix to the security issue is actually very simple: keep track of the next internal account ID to use and increment it after create a new account. This change fixes the security issue for the EOS EVM Contract going forward.
However, the bug could easily be triggered (even inadvertently) causing a newly deployed EVM contract to inherit the state of an unrelated EVM contract that self-destructed earlier. One caveat is that no new externally-owned accounts would need to be created between the self-destruction of one contract and the creation of a new contract account. Unfortunately, both mainnet and testnet had at least one account that triggered the undesired state inheritance side-effect which led to deviations in EVM state from what was intended y the EVM protocol.
So, this security release also includes new administrative actions to correct aspects of the EVM state.
Note: The administrative actions have already been used to correct unwanted state differences on both testnet and mainnet. Additionally, the account ID reuse bug has already been patched on both testnet and mainnet.
Admin actions to correct state in EOS EVM
It is always possible for issues to arise due to bugs within the EOS EVM Contract that causes it to deviate from the intended behavior of the EVM protocol. This can lead to the state in the contract deviating from what it should be and deviating from what the state in the EOS EVM Node. So, it is desirable to have administrative actions, which can only be used by the same authority that can change the code of the EOS EVM Contract, to correct faulty state.
This deviation of state already occurred on both testnet and mainnet from transactions that inadvertently triggered the undesired state inheritance side-effect due to the account ID reuse bug mentioned above. So some of the admin actions introduced in this release were essential for properly resolving the impact due to security bug on both testnet and mainnet. This is also why these admin actions were introduced in the security patch despite technically being a new feature and not a bug fix.
EOS EVM Node and RPC
Correct processing of pushtx actions in ship_receiver_plugin
A bug was identified in EOS EVM Node which could cause it to process a different sequence of EVM transactions than the one processed by the EOS EVM Contract.
Because the state computed by EOS EVM Node is used by EOS EVM RPC to process read requests for the EOS EVM state (e.g. executing view functions), it is possible that vulnerable EOS EVM Nodes could provide responses that deviate from the intended result that would be computed by EOS EVM Contract (e.g. via its exec function).
It is critical that operators of EOS EVM Node upgrade their software to avoid returning incorrect responses to read requests. A proper upgrade to fix this issue requires that EOS EVM Node replay the virtual blockchain generated from genesis of EOS EVM.
Note: The EOS EVM Nodes operated by the ENF which serve the RPC requests to the https://api.evm.eosnetwork.com/ (for mainnet) and https://api.testnet.evm.eosnetwork.com/ (for testnet) endpoints have already been upgraded.
Feature lifecycle updates
Deprecations
TX-Wrapper
TX-Wrapper has been deprecated with plans to remove and replace with eos-evm-miner for the release of EOS EVM v0.6.0.
Building, compatibility, and upgrading
Building
The README in the eos-evm repository contains instructions on how to build the components.
Compatibility and upgrading
The components can be upgraded from the 0.5.0 and 0.5.1 releases.
EOS EVM Node binaries should be replaced and relaunched with a full replay from the EOS EVM genesis.
Assuming the state inheritance side-effect has not been triggered on the target network, the EOS EVM Contract can be upgraded by deploying the new WASM and ABI and then creating a new account. On a fresh network, simply deploying the contract with the fix is sufficient and there is no need to even create the new account.
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.5.1...v0.5.2
Contributors
Assets 2
EOS EVM v0.5.1 Release Notes
This release fixes a security vulnerability discovered in EOS EVM Contract. EOS EVM RPC has also been updated with an unrelated bug fix.
Components
EOS EVM Contract
Enforce ChainID in transactions
According to EIP-155, a transaction must have a (matched) ChainID for replay protection. However, prior to this release, the ChainID in a transaction was only checked if it was provided.
This release of EOS EVM Contract enforces that the transaction pushed to the EOS EVM includes a valid ChainID. Exceptions are only made for transactions that are internally generated by the EOS EVM Contract itself since there is no concern of replay attacks for such transactions (they do not even contain valid signatures).
EOS EVM Node and RPC
Handle transfers to reserved addresses consistently in EOS EVM RPC
EOS EVM RPC processed transactions involving a transfer from a reserved address differently than the other components which could lead to several trace functions to fail. This release fixes that bug as well.
Building, compatibility, and upgrading
Building
The README in the eos-evm repository contains instructions on how to build the components.
Compatibility and upgrading
The components can be upgraded from the 0.5.0 release.
The EOS EVM Contract is simply upgrading by deploying the WASM and ABI.
EOS EVM Node and EOS EVM RPC binaries can be replaced and relaunched (no replay required). There is also no need to upgrade the EOS EVM Node since the only change to it is the reported version number.
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.5.0...v0.5.1
Contributors
Assets 2
EOS EVM v0.5.0 Release Notes
This release contains changes to all major components of the EOS EVM.
Components
EOS EVM Contract
Action to execute read-only transactions
The EOS EVM contract now has a new action called exec which allows the caller to execute EVM code and get the return value. No side-effects will be committed to state and this action is intended to be used for read-only executions, e.g. calling Solidity view functions.
There are two ways of getting the return value. If no callback is specified in the arguments of the exec action, then the EVM contract message call return value will be included as part of the return value of the exec action. Otherwise, if a callback (of the form of a contract account name and action name) is specified, the EOS EVM Contract will deliver the return value as an inline action call made to contract specified in the callback.
This feature is a necesssary component for Yield+ integration with the EOS EVM.
Increased stack size to allow deeper nested calls
The EOS EVM Contact has a limit on the stack used within WASM linear memory. This puts a limit to how deeply nested EVM contract calls can get within the EVM implementation before it runs out of stack.
The stack limit in prior releases allow nested calls to get to a depth of 5. Optimizations in the EOS EVM Contract implementation have allowed for almost doubling the stack size which has correspondingly increased the EVM call depth limit by a significant amount thus enabling contract use cases that may have been rejected before.
Other improvements to the EOS EVM Contract
PRs
The inevm table now shows up in the ABI which should allow for easy exploration of the total sum of the EOS balances within the EVM environment using an EOS block explorer. Note that this balance does not include any of the other balances held by the EOS EVM Contract on the EOS side, e.g. the accumulated gas fees in the eosio.evm balances or the balances of miners who have explicitly opened an account in the contract using the open action.
The withdraw action has been modified to take an optional extra argument called to. Normally, when to is not specified, the funds beloging to the owner are withdraw to the balance within the eosio.token contract belonging to owner. If to is specified, then the funds are instead sent to the to account.
The EOS EVM Contract will now reject any non-EOS tokens, e.g. USDT, that are sent to it. As a reminder, the trustless bridge does not yet support any tokens other than EOS.
A more descriptive error message is now returned if validation of a pushed EVM transaction fails.
EOS EVM Node and RPC
Various bug fixes
PRs
A bug in the history index of EOS EVM Node was fixed. This bug caused the block explorer to show incorrect records. To resolve this issue in an already deployed instance, it is necessary to replay the EOS EVM Node and then it is necessary to re-index the block explorer that used data from the buggy EOS EVM Node.
Additional bugs in EOS EVM RPC were fixed. An eth_call request without an explicit from value specified now works correctly. Gas estimation now returns expected responses under certain error conditions, and other fixes were made to gas estimation in EOS EVM RPC.
TX-Wrapper
Configurable permission and expiration
Prior to this release, TX-Wrapper had a hard-coded expiration for the EOS wrapped transaction set to 50 minutes in the future. In this release, the expiration time is configurable with the optional EXPIRE_SEC parameter (takes the expiration duration in seconds). If not specified, the expiration time will default to 5 minutes.
TX-Wrapper also now requires an additional parameter EOS_PERMISSION to set the permission to use for the miner's authorization of the pushtx action. To maintain existing behavior, ensure this parameter is set to "active". The permission can be changed to a custom permission on the account specified by EOS_SENDER. However, ensure that linkauth is used to allow that custom permission to satisfy the pushtx action of the EOS EVM Contract, otherwise TX-Wrapper will not function correctly.
Building, compatibility, and upgrading
Building
The README in the eos-evm repository contains instructions on how to build the components.
Compatibility and upgrading
The components can be upgraded from any prior 0.4.x release.
The EOS EVM Contract is simply upgrading by deploying the WASM and ABI.
EOS EVM Node needs to replay from genesis. Block explorers leveraging data from EOS EVM Node are recommended to re-index.
The .env file used by TX-Wrapper should first ensure the line EOS_PERMISSION="active" is added before starting the new TX-Wrapper to ensure it can start up and behave the same way as before.
Deprecations, removals, and dropped support
TX-Wrapper deprecated
TX-Wrapper has been deprecated and will be removed in a future release. Users are recommended to switch to eos-evm-miner instead.
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
- (505) [0.4 -> main] Bring recent 0.4.x changes into main. Bump version to 0.5.0
- (508) [0.4 -> main] add missing nginx log settings
- (511) Update README to include links to EOS EVM docs and evm-public-docs
- (503) configurable permission in tx_wrapper
- (522) Remove flask_proxy
- (532) evmone version
- (534) [0.4 -> main] Enable keep alive to read and test endpoint
- (538) [0.4 -> main] fix silkworm stability
- (521) fix #465 #451 extra param for withdraw, inevm table abi
- (544) Reject non eos token in bridging
- (546) add some additional tests for invalid addresses in EOS->EVM bridge memos
- (550) more briging tests
- (474) Remove advanced execution to increase nested call level
- (553) eth_call: use default from address when not specified
- (555) Fix Wrong History Index
- (557) Fix gas estimation return value
- (541) Return error number and more descriptive message when validation failed
- (547) Add read-only transaction execution support to EVM contract
- (593) [0.5] EstimateGasOracle: fix estimate_gas
- (594) [0.5] Return better result when accessed by GET
Full Changelog: v0.4.2...v0.5.0