Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
N
nebula
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
exchain
nebula
Commits
5e401575
Unverified
Commit
5e401575
authored
Jan 12, 2024
by
Roberto Bayardo
Committed by
GitHub
Jan 12, 2024
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
fix base bee naming consistency in the specs (#8974)
parent
10238744
Changes
5
Hide whitespace changes
Inline
Side-by-side
Showing
5 changed files
with
62 additions
and
62 deletions
+62
-62
deposits.md
specs/deposits.md
+9
-9
exec-engine.md
specs/exec-engine.md
+13
-14
glossary.md
specs/glossary.md
+1
-0
guaranteed-gas-market.md
specs/guaranteed-gas-market.md
+34
-34
predeploys.md
specs/predeploys.md
+5
-5
No files found.
specs/deposits.md
View file @
5e401575
...
...
@@ -282,13 +282,13 @@ The overall calldata layout is as follows:
| Input arg | Type | Calldata bytes | Segment |
| ----------------- | ----------- | -------------- | --------|
| {0x440a5e20} | | 0-3 | n/a |
| base
f
eeScalar | uint32 | 4-7 | 1 |
| blobBase
f
eeScalar | uint32 | 8-11 | |
| base
F
eeScalar | uint32 | 4-7 | 1 |
| blobBase
F
eeScalar | uint32 | 8-11 | |
| sequenceNumber | uint64 | 12-19 | |
| l1BlockTimestamp | uint64 | 20-27 | |
| l1BlockNumber | uint64 | 28-35 | |
| basefee | uint256 | 36-67 | 2 |
| blobBase
f
ee | uint256 | 68-99 | 3 |
| blobBase
F
ee | 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:
-
`blobBase
f
ee`
(
`uint256`
)
-
`base
f
eeScalar`
(
`uint32`
): system configurable to scale the
`basefee`
in the Ecotone l1 cost computation
-
`blobBasefeeScalar`
(
`uint32`
): system configurable to scale the
`blobBase
f
ee`
in the Ecotone l1 cost computation
-
`blobBase
F
ee`
(
`uint256`
)
-
`base
F
eeScalar`
(
`uint32`
): system configurable to scale the
`basefee`
in the Ecotone l1 cost computation
-
`blobBasefeeScalar`
(
`uint32`
): system configurable to scale the
`blobBase
F
ee`
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:
-
`blobBase
fee`
(
`uint256`
): The L1 basefee for blob transactions
.
-
`blobBase
f
eeScalar`
(
`uint32`
): The scalar value applied to the L1 blob base fee portion of the L1 cost.
-
`base
f
eeScalar`
(
`uint32`
): The scalar value applied to the L1 base fee portion of the L1 cost.
-
`blobBase
Fee`
(
`uint256`
): The L1 blob base fee
.
-
`blobBase
F
eeScalar`
(
`uint32`
): The scalar value applied to the L1 blob base fee portion of the L1 cost.
-
`base
F
eeScalar`
(
`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
...
...
specs/exec-engine.md
View file @
5e401575
...
...
@@ -111,7 +111,7 @@ the upgrades that are active.
#### Pre-Ecotone
Before Ecotone activation, L1 cost is calculated as:
`(rollupDataGas + l1FeeOverhead) * l1Base
f
ee * l1FeeScalar / 1e6`
(big-int computation, result
`(rollupDataGas + l1FeeOverhead) * l1Base
F
ee * 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.
-
`l1Base
fee`
is the L1 B
ase fee of the latest L1 origin registered in the L2 chain.
-
`l1Base
Fee`
is the L1 b
ase 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
`l1Base
f
ee`
of the L1 origin,
The Gas Price Oracle
`l1FeeOverhead`
and
`l1FeeScalar`
, as well as the
`l1Base
F
ee`
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*l1Base
fee*l1BasefeeScalar + l1BlobBasefee*l1BlobBasef
eeScalar) / 16e6`
`(zeroes*4 + ones*16) * (16*l1Base
Fee*l1BaseFeeScalar + l1BlobBaseFee*l1BlobBaseF
eeScalar) / 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.
-
`l1Base
fee`
is the L1 base
fee of the latest L1 origin registered in the L2 chain.
-
`l1Base
Fee`
is the L1 base
fee of the latest L1 origin registered in the L2 chain.
-
`l1BlobBase
fee`
is the blob gas
price, computed as described in
[
EIP-4844
][
4844-gas
]
from the
-
`l1BlobBase
Fee`
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*l1Base
fee*lBasefeeScalar + l1BlobBasefee*l1BlobBasef
eeScalar) / 1e6`
`(compressedTxSize) * (16*l1Base
Fee*lBaseFeeScalar + l1BlobBaseFee*l1BlobBaseF
eeScalar) / 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 (
`l1Base
feeScalar`
,
`l1BlobBasef
eeScalar`
,
`basefee`
,
`blobBase
f
ee`
) of the current L2 block
-
read from the deposited L1 attributes (
`l1Base
FeeScalar`
,
`l1BlobBaseF
eeScalar`
,
`basefee`
,
`blobBase
F
ee`
) 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`
-
blobBase
f
ee
`uint256`
in slot
`7`
-
l1Base
f
eeScalar big-endian
`uint32`
slot
`3`
at offset
`12`
-
l1BlobBase
f
eeScalar big-endian
`uint32`
in slot
`3`
at offset
`8`
-
blobBase
F
ee
`uint256`
in slot
`7`
-
l1Base
F
eeScalar big-endian
`uint32`
slot
`3`
at offset
`12`
-
l1BlobBase
F
eeScalar big-endian
`uint32`
in slot
`3`
at offset
`8`
## Engine API
...
...
specs/glossary.md
View file @
5e401575
...
...
@@ -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)
...
...
specs/guaranteed-gas-market.md
View file @
5e401575
...
...
@@ -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 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.
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 Base
fee 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_base
fee
=
prev_base
fee
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_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
# 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_base
fee
=
clamp
(
now_basefee_wide
,
min
=
MINIMUM_BASE
FEE
,
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_base
fee_wide
=
now_basefee
*
pow
(
1
-
(
1
/
BASE
FEE_MAX_CHANGE_DENOMINATOR
),
n
)
now_base
fee
=
clamp
(
now_basefee_wide
,
min
=
MINIMUM_BASE
FEE
,
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
...
...
specs/predeploys.md
View file @
5e401575
...
...
@@ -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:
-
l1Base
f
eeScalar
-
l1BlobBase
f
eeScalar
-
l1Base
F
eeScalar
-
l1BlobBase
F
eeScalar
-
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 base
fees on L2. The base
fee 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.
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment