Commit 5e401575 authored by Roberto Bayardo's avatar Roberto Bayardo Committed by GitHub

fix base bee naming consistency in the specs (#8974)

parent 10238744
......@@ -282,13 +282,13 @@ The overall calldata layout is as follows:
| Input arg | Type | Calldata bytes | Segment |
| ----------------- | ----------- | -------------- | --------|
| {0x440a5e20} | | 0-3 | n/a |
| basefeeScalar | uint32 | 4-7 | 1 |
| blobBasefeeScalar | uint32 | 8-11 | |
| baseFeeScalar | uint32 | 4-7 | 1 |
| blobBaseFeeScalar | uint32 | 8-11 | |
| sequenceNumber | uint64 | 12-19 | |
| l1BlockTimestamp | uint64 | 20-27 | |
| l1BlockNumber | uint64 | 28-35 | |
| basefee | uint256 | 36-67 | 2 |
| blobBasefee | uint256 | 68-99 | 3 |
| blobBaseFee | uint256 | 68-99 | 3 |
| l1BlockHash | bytes32 | 100-131 | 4 |
| batcherHash | bytes32 | 132-163 | 5 |
......@@ -334,9 +334,9 @@ The predeploy stores the following values:
- `overhead` (`uint256`): The L1 fee overhead to apply to L1 cost computation of transactions in this L2 block.
- `scalar` (`uint256`): The L1 fee scalar to apply to L1 cost computation of transactions in this L2 block.
- With the Ecotone upgrade, the predeploy additionally stores:
- `blobBasefee` (`uint256`)
- `basefeeScalar` (`uint32`): system configurable to scale the `basefee` in the Ecotone l1 cost computation
- `blobBasefeeScalar` (`uint32`): system configurable to scale the `blobBasefee` in the Ecotone l1 cost computation
- `blobBaseFee` (`uint256`)
- `baseFeeScalar` (`uint32`): system configurable to scale the `basefee` in the Ecotone l1 cost computation
- `blobBasefeeScalar` (`uint32`): system configurable to scale the `blobBaseFee` in the Ecotone l1 cost computation
Following the Ecotone upgrade, `overhead` and `scalar` are frozen at the values they had on the
block immediately prior to the fork.
......@@ -367,9 +367,9 @@ The L1 Attributes Predeployed contract, `L1Block.sol`, is upgraded as part of th
The version is incremented to `1.2.0`, one new storage slot is introduced, and one existing slot
begins to store additional data:
- `blobBasefee` (`uint256`): The L1 basefee for blob transactions.
- `blobBasefeeScalar` (`uint32`): The scalar value applied to the L1 blob base fee portion of the L1 cost.
- `basefeeScalar` (`uint32`): The scalar value applied to the L1 base fee portion of the L1 cost.
- `blobBaseFee` (`uint256`): The L1 blob base fee.
- `blobBaseFeeScalar` (`uint32`): The scalar value applied to the L1 blob base fee portion of the L1 cost.
- `baseFeeScalar` (`uint32`): The scalar value applied to the L1 base fee portion of the L1 cost.
Additionally, the `setL1BlockValues` function is deprecated and MUST never be called when the L2 block number
is greater than the Ecotone activation block number. `setL1BlockValues` MUST be called on the Ecotone hardfork
......
......@@ -111,7 +111,7 @@ the upgrades that are active.
#### Pre-Ecotone
Before Ecotone activation, L1 cost is calculated as:
`(rollupDataGas + l1FeeOverhead) * l1Basefee * l1FeeScalar / 1e6` (big-int computation, result
`(rollupDataGas + l1FeeOverhead) * l1BaseFee * l1FeeScalar / 1e6` (big-int computation, result
in Wei and `uint256` range)
Where:
......@@ -123,7 +123,7 @@ Where:
- With Regolith fork: `rollupDataGas = zeroes * 4 + ones * 16`
- `l1FeeOverhead` is the Gas Price Oracle `overhead` value.
- `l1FeeScalar` is the Gas Price Oracle `scalar` value.
- `l1Basefee` is the L1 Base fee of the latest L1 origin registered in the L2 chain.
- `l1BaseFee` is the L1 base fee of the latest L1 origin registered in the L2 chain.
Note that the `rollupDataGas` uses the same byte cost accounting as defined in [eip-2028],
except the full L2 transaction now counts towards the bytes charged in the L1 calldata.
......@@ -132,7 +132,7 @@ This behavior matches pre-Bedrock L1-cost estimation of L2 transactions.
Compression, batching, and intrinsic gas costs of the batch transactions are accounted for by the protocol
with the Gas Price Oracle `overhead` and `scalar` parameters.
The Gas Price Oracle `l1FeeOverhead` and `l1FeeScalar`, as well as the `l1Basefee` of the L1 origin,
The Gas Price Oracle `l1FeeOverhead` and `l1FeeScalar`, as well as the `l1BaseFee` of the L1 origin,
can be accessed in two interchangeable ways:
- read from the deposited L1 attributes (`l1FeeOverhead`, `l1FeeScalar`, `basefee`) of the current L2 block
......@@ -148,7 +148,7 @@ can be accessed in two interchangeable ways:
Ecotone allows posting batches via Blobs which are subject to a new fee market. To account for this feature,
L1 cost is computed as:
`(zeroes*4 + ones*16) * (16*l1Basefee*l1BasefeeScalar + l1BlobBasefee*l1BlobBasefeeScalar) / 16e6`
`(zeroes*4 + ones*16) * (16*l1BaseFee*l1BaseFeeScalar + l1BlobBaseFee*l1BlobBaseFeeScalar) / 16e6`
Where:
......@@ -158,34 +158,33 @@ Where:
- zeoroes and ones are the count of zero and non-zero bytes respectively in the *full* encoded
signed transaction.
- `l1Basefee` is the L1 basefee of the latest L1 origin registered in the L2 chain.
- `l1BaseFee` is the L1 base fee of the latest L1 origin registered in the L2 chain.
- `l1BlobBasefee` is the blob gasprice, computed as described in [EIP-4844][4844-gas] from the
- `l1BlobBaseFee` is the blob gas price, computed as described in [EIP-4844][4844-gas] from the
header of the latest registered L1 origin block.
Conceptually what the above function captures is the formula below, where `compressedTxSize =
(zeroes*4 + ones*16) / 16` can be thought of as a rough approximation of how many bytes the
transaction occupies in a compressed batch.
`(compressedTxSize) * (16*l1Basefee*lBasefeeScalar + l1BlobBasefee*l1BlobBasefeeScalar) / 1e6`
`(compressedTxSize) * (16*l1BaseFee*lBaseFeeScalar + l1BlobBaseFee*l1BlobBaseFeeScalar) / 1e6`
The precise cost function used by Ecotone at the top of this section preserves precision under
integer arithmetic by postponing the inner division by 16 until the very end.
[4844-gas]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md#gas-accounting
The two basefee values and their respective scalars can be accessed in two interchangeable
ways:
The two base fee values and their respective scalars can be accessed in two interchangeable ways:
- read from the deposited L1 attributes (`l1BasefeeScalar`, `l1BlobBasefeeScalar`, `basefee`,
`blobBasefee`) of the current L2 block
- read from the deposited L1 attributes (`l1BaseFeeScalar`, `l1BlobBaseFeeScalar`, `basefee`,
`blobBaseFee`) of the current L2 block
- read from the L1 Block Info contract (`0x4200000000000000000000000000000000000015`)
- using the respective solidity getter functions
- using direct storage-reads:
- basefee `uint256` in slot `1`
- blobBasefee `uint256` in slot `7`
- l1BasefeeScalar big-endian `uint32` slot `3` at offset `12`
- l1BlobBasefeeScalar big-endian `uint32` in slot `3` at offset `8`
- blobBaseFee `uint256` in slot `7`
- l1BaseFeeScalar big-endian `uint32` slot `3` at offset `12`
- l1BlobBaseFeeScalar big-endian `uint32` in slot `3` at offset `8`
## Engine API
......
......@@ -539,6 +539,7 @@ L2 derivation inputs include:
- block number
- timestamp
- basefee
- blob base fee
- [deposits] (as log data)
- [sequencer batches][sequencer-batch] (as transaction data)
- [System configuration][system-config] updates (as log data)
......
......@@ -26,29 +26,29 @@ to purchase (on L1) on top of that.
Guaranteed gas on L2 is bought in the following manner. An L2 gas price is calculated via an
EIP-1559-style algorithm. The total amount of ETH required to buy that gas is then calculated as
(`guaranteed gas * L2 deposit basefee`). The contract then accepts that amount of ETH (in a future
upgrade) or (only method right now), burns an amount of L1 gas that corresponds to the L2 cost
(`L2 cost / L1 Basefee`). The L2 gas price for guaranteed gas is not synchronized with the basefee
on L2 and will likely be different.
(`guaranteed gas * L2 deposit base fee`). The contract then accepts that amount of ETH (in a future
upgrade) or (only method right now), burns an amount of L1 gas that corresponds to the L2 cost (`L2
cost / L1 base fee`). The L2 gas price for guaranteed gas is not synchronized with the base fee on
L2 and will likely be different.
## Gas Stipend
To offset the gas spent on the deposit event, we credit `gas spent * L1 basefee` ETH to the cost of
the L2 gas, where `gas spent` is the amount of L1 gas spent processing the deposit. If the ETH value
of this credit is greater than the ETH value of the requested guaranteed gas
(`requested guaranteed gas * L2 gas price`), no L1 gas is burnt.
To offset the gas spent on the deposit event, we credit `gas spent * L1 base fee` ETH to the cost
of the L2 gas, where `gas spent` is the amount of L1 gas spent processing the deposit. If the ETH
value of this credit is greater than the ETH value of the requested guaranteed gas (`requested
guaranteed gas * L2 gas price`), no L1 gas is burnt.
## Default Values
| Variable | Value |
| -------------------------------- | ---------------------------------------------- |
| `MAX_RESOURCE_LIMIT` | 20,000,000 |
| `ELASTICITY_MULTIPLIER` | 10 |
| `BASEFEE_MAX_CHANGE_DENOMINATOR` | 8 |
| `MINIMUM_BASEFEE` | 1 gwei |
| `MAXIMUM_BASEFEE` | type(uint128).max |
| `SYSTEM_TX_MAX_GAS` | 1,000,000 |
| `TARGET_RESOURCE_LIMIT` | `MAX_RESOURCE_LIMIT` / `ELASTICITY_MULTIPLIER` |
| Variable | Value |
| --------------------------------- | ---------------------------------------------- |
| `MAX_RESOURCE_LIMIT` | 20,000,000 |
| `ELASTICITY_MULTIPLIER` | 10 |
| `BASE_FEE_MAX_CHANGE_DENOMINATOR` | 8 |
| `MINIMUM_BASE_FEE` | 1 gwei |
| `MAXIMUM_BASE_FEE` | type(uint128).max |
| `SYSTEM_TX_MAX_GAS` | 1,000,000 |
| `TARGET_RESOURCE_LIMIT` | `MAX_RESOURCE_LIMIT` / `ELASTICITY_MULTIPLIER` |
## Limiting Guaranteed Gas
......@@ -65,17 +65,17 @@ we implement an EIP-1559-style fee market to reduce congestion on deposits. By s
at a multiple of the target, we enable deposits to temporarily use more L2 gas at a greater cost.
```python
# Pseudocode to update the L2 Deposit Basefee and cap the amount of guaranteed gas
# Pseudocode to update the L2 deposit base fee and cap the amount of guaranteed gas
# bought in a block. Calling code must handle the gas burn and validity checks on
# the ability of the account to afford this gas.
# prev_basefee is a u128, prev_bought_gas and prev_num are u64s
prev_basefee, prev_bought_gas, prev_num = <values from previous update>
# prev_base fee is a u128, prev_bought_gas and prev_num are u64s
prev_base_fee, prev_bought_gas, prev_num = <values from previous update>
now_num = block.number
# Clamp the full basefee to a specific range. The minimum value in the range should be around 100-1000
# to enable faster responses in the basefee. This replaces the `max` mechanism in the ethereum 1559
# implementation (it also serves to enable the basefee to increase if it is very small).
# Clamp the full base fee to a specific range. The minimum value in the range should be around 100-1000
# to enable faster responses in the base fee. This replaces the `max` mechanism in the ethereum 1559
# implementation (it also serves to enable the base fee to increase if it is very small).
def clamp(v: i256, min: u128, max: u128) -> u128:
if v < i256(min):
return min
......@@ -84,35 +84,35 @@ def clamp(v: i256, min: u128, max: u128) -> u128:
else:
return u128(v)
# If this is a new block, update the basefee and reset the total gas
# If this is a new block, update the base fee and reset the total gas
# If not, just update the total gas
if prev_num == now_num:
now_basefee = prev_basefee
now_base_fee = prev_base_fee
now_bought_gas = prev_bought_gas + requested_gas
elif prev_num != now_num:
# Width extension and conversion to signed integer math
gas_used_delta = int128(prev_bought_gas) - int128(TARGET_RESOURCE_LIMIT)
# Use truncating (round to 0) division - solidity's default.
# Sign extend gas_used_delta & prev_basefee to 256 bits to avoid overflows here.
base_fee_per_gas_delta = prev_basefee * gas_used_delta / TARGET_RESOURCE_LIMIT / BASEFEE_MAX_CHANGE_DENOMINATOR
now_basefee_wide = prev_basefee + base_fee_per_gas_delta
# Sign extend gas_used_delta & prev_base_fee to 256 bits to avoid overflows here.
base_fee_per_gas_delta = prev_base_fee * gas_used_delta / TARGET_RESOURCE_LIMIT / BASE_FEE_MAX_CHANGE_DENOMINATOR
now_base_fee_wide = prev_base_fee + base_fee_per_gas_delta
now_basefee = clamp(now_basefee_wide, min=MINIMUM_BASEFEE, max=UINT_128_MAX_VALUE)
now_base_fee = clamp(now_base_fee_wide, min=MINIMUM_BASE_FEE, max=UINT_128_MAX_VALUE)
now_bought_gas = requested_gas
# If we skipped multiple blocks between the previous block and now update the basefee again.
# If we skipped multiple blocks between the previous block and now update the base fee again.
# This is not exactly the same as iterating the above function, but quite close for reasonable
# gas target values. It is also constant time wrt the number of missed blocks which is important
# for keeping gas usage stable.
if prev_num + 1 < now_num:
n = now_num - prev_num - 1
# Apply 7/8 reduction to prev_basefee for the n empty blocks in a row.
now_basefee_wide = now_basefee * pow(1-(1/BASEFEE_MAX_CHANGE_DENOMINATOR), n)
now_basefee = clamp(now_basefee_wide, min=MINIMUM_BASEFEE, max=type(uint128).max)
# Apply 7/8 reduction to prev_base_fee for the n empty blocks in a row.
now_base_fee_wide = now_base_fee * pow(1-(1/BASE_FEE_MAX_CHANGE_DENOMINATOR), n)
now_base_fee = clamp(now_base_fee_wide, min=MINIMUM_BASE_FEE, max=type(uint128).max)
require(now_bought_gas < MAX_RESOURCE_LIMIT)
store_values(now_basefee, now_bought_gas, now_num)
store_values(now_base_fee, now_bought_gas, now_num)
```
## Rationale for burning L1 Gas
......
......@@ -242,9 +242,9 @@ L1 on L2.
Address: `0x420000000000000000000000000000000000000F`
In the legacy system, the `GasPriceOracle` was a permissioned contract
that was pushed the L1 basefee and the L2 gas price by an offchain actor.
that was pushed the L1 base fee and the L2 gas price by an offchain actor.
The offchain actor observes the L1 blockheaders to get the
L1 basefee as well as the gas usage on L2 to compute what the L2 gas price
L1 base fee as well as the gas usage on L2 to compute what the L2 gas price
should be based on a congestion control algorithm.
After Bedrock, the `GasPriceOracle` is no longer a permissioned contract
......@@ -267,8 +267,8 @@ has been hardcoded to 6.
Following the Ecotone upgrade, the values used for L1 fee computation are:
- l1BasefeeScalar
- l1BlobBasefeeScalar
- l1BaseFeeScalar
- l1BlobBaseFeeScalar
- decimals
These values are managed by the `SystemConfig` contract on the L1. The`decimals` remains hardcoded
......@@ -335,7 +335,7 @@ depositing native L1 NFTs into.
Address: `0x4200000000000000000000000000000000000019`
The `BaseFeeVault` predeploy receives the basefees on L2. The basefee is not
The `BaseFeeVault` predeploy receives the base fees on L2. The base fee is not
burnt on L2 like it is on L1. Once the contract has received a certain amount
of fees, the ETH can be withdrawn to an immutable address on
L1.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment