You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We introduce a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) transaction type, with the format 0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s]).
There is a base fee per gas in protocol, which can move up or down each block according to a formula which is a function of gas used in parent block and gas target (block gas limit divided by elasticity multiplier) of parent block. The algorithm results in the base fee per gas increasing when blocks are above the gas target, and decreasing when blocks are below the gas target. The base fee per gas is burned. Transactions specify the maximum fee per gas they are willing to give to miners to incentivize them to include their transaction (aka: priority fee). Transactions also specify the maximum fee per gas they are willing to pay total (aka: max fee), which covers both the priority fee and the block’s network fee per gas (aka: base fee). Senders will always pay the base fee per gas of the block their transaction was included in, and they will pay the priority fee per gas set in the transaction, as long as the combined amount of the two fees doesn’t exceed the transaction’s maximum fee per gas.
Structural changes in EVM
Add a BaseFee field in types.Header
Add a BaseFee opcode, returns the base fee of the current block where the code is running in
Add NoBaseFee option in EVM config to disable base fee checking in certain cases, such as testing, gas estimating, call or tracing RPC APIs
Following the abstract, we will define a new DynamicFeeTxType with the format 0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s]). The current transaction struct below will be specify as LegacyTxType
typeTransactionstruct {
datatxdata// cacheshash atomic.Valuesize atomic.Valuefrom atomic.Value
}
typetxdatastruct {
AccountNonceuint64`json:"nonce" gencodec:"required"`Price*big.Int`json:"gasPrice" gencodec:"required"`GasLimituint64`json:"gas" gencodec:"required"`Recipient*common.Address`json:"to" rlp:"nil"`// nil means contract creationAmount*big.Int`json:"value" gencodec:"required"`Payload []byte`json:"input" gencodec:"required"`// Signature valuesV*big.Int`json:"v" gencodec:"required"`R*big.Int`json:"r" gencodec:"required"`S*big.Int`json:"s" gencodec:"required"`// This is only used when marshaling to JSON.Hash*common.Hash`json:"hash" rlp:"-"`
}
Both transaction types need to expose some same certain fields so the idea here is transform this txdata struct into an interface for both transaction types to implement
// TxData is the underlying data of a transaction.//// This is implemented by DynamicFeeTx, LegacyTx and AccessListTx.typeTxDatainterface {
txType() byte// returns the type IDcopy() TxData// creates a deep copy and initializes all fieldschainID() *big.Intdata() []bytegas() uint64gasPrice() *big.IntgasTipCap() *big.IntgasFeeCap() *big.Intvalue() *big.Intnonce() uint64to() *common.AddressrawSignatureValues() (v, r, s*big.Int)
setSignatureValues(chainID, v, r, s*big.Int)
// effectiveGasPrice computes the gas price paid by the transaction, given// the inclusion block baseFee.//// Unlike other TxData methods, the returned *big.Int should be an independent// copy of the computed value, i.e. callers are allowed to mutate the result.// Method implementations can use 'dst' to store the result.effectiveGasPrice(dst*big.Int, baseFee*big.Int) *big.Intencode(*bytes.Buffer) errordecode([]byte) error
}
The text was updated successfully, but these errors were encountered:
Abstract
From the official EIP-1559 of Ethereum
We introduce a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) transaction type, with the format 0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s]).
There is a base fee per gas in protocol, which can move up or down each block according to a formula which is a function of gas used in parent block and gas target (block gas limit divided by elasticity multiplier) of parent block. The algorithm results in the base fee per gas increasing when blocks are above the gas target, and decreasing when blocks are below the gas target. The base fee per gas is burned. Transactions specify the maximum fee per gas they are willing to give to miners to incentivize them to include their transaction (aka: priority fee). Transactions also specify the maximum fee per gas they are willing to pay total (aka: max fee), which covers both the priority fee and the block’s network fee per gas (aka: base fee). Senders will always pay the base fee per gas of the block their transaction was included in, and they will pay the priority fee per gas set in the transaction, as long as the combined amount of the two fees doesn’t exceed the transaction’s maximum fee per gas.
Structural changes in EVM
BaseFee
field intypes.Header
BaseFee
opcode, returns the base fee of the current block where the code is running inNoBaseFee
option in EVM config to disable base fee checking in certain cases, such as testing, gas estimating, call or tracing RPC APIsImplement EIP-2718 typed transaction envelope for
DynamicFeeTxType
and unify with currentLegacyTxType
Following the abstract, we will define a new
DynamicFeeTxType
with the format0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])
. The current transaction struct below will be specify asLegacyTxType
Both transaction types need to expose some same certain fields so the idea here is transform this
txdata
struct into an interface for both transaction types to implementThe text was updated successfully, but these errors were encountered: