Releases · eosnetworkfoundation/eos-evm-contract

14 May 16:58

v1.0.0-rc1

150166f

EOS EVM Contract v1.0.0-rc1 Pre-release

Pre-release

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

(698) Remove minimum_gas_price from consensus parameters
(699) use base_fee_per_gas for exec a trx
(702) Kayan min inclusion price
(704) Change miner portion calculation
(701) Update behavior when changing gas-price

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

PRs

(709) Use Shanghai consensus tests

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

(682) gas param config change event
(692) Use active gas parameters in ExecutionState

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 asG_txnewaccount.
Additional gas consumed when creating a new non-contract account due to the CALL or SELFDESTRUCT opcodes. This value defaults to to 25000 and is denoted as G_newaccount.
Static gas consumed in the CREATE and CREATE2 opcodes and also acts as the additional gas consumed in a contract-creating transaction. This value defaults to 32000 and is denoted G_txcreate.
Factor that multiplies the deployed code size within CREATE and CREATE2 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 as G_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

PRs

(677) Add support for EOSEVM version

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

(675) [0.6] Allow transfer non-EOS tokens out.
(676) [0.6->main] Allow transfer non-EOS tokens out

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

PRs

(707) 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

elmato, taokayan, and yarkinwho

Assets 2

29 Sep 01:28

stephenpdeos

v0.6.0

d1f3c22

EOS EVM Contract v0.6.0 Latest

Latest

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:

call action
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.