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
|`SELFDESTRUCT`|`selfdestruct`| Disabled. If the opcode is encountered, the transaction will be reverted.[^willadpot]|
@@ -38,60 +37,13 @@ We support the `cancun` EVM target and the latest Solidity version `0.8.26`.
38
37
39
38
## EVM Precompiles
40
39
41
-
The `RIPEMD-160` (address `0x3`) `blake2f` (address `0x9`), and `point evaluation` (address `0x0a`) precompiles are currently not supported. Calls to unsupported precompiled contracts will revert. We plan to enable these precompiles in future hard forks.
40
+
The `RIPEMD-160` (address `0x3`),`blake2f` (address `0x9`), and `point evaluation` (address `0x0a`) precompiles are currently not supported. Calls to unsupported precompiled contracts will revert.
42
41
43
-
The `modexp` precompile is supported but only supports inputs of size less than or equal to 32 bytes (i.e. `u256`).
44
-
45
-
The `ecPairing` precompile is supported, but the number of points(sets, pairs) is limited to 4, instead of 6.
46
-
47
-
The other EVM precompiles are all supported: `ecRecover`, `identity`, `ecAdd`, `ecMul`.
48
-
49
-
### Precompile Limits
50
-
51
-
Because of a bounded size of the zkEVM circuits, there is an upper limit on the number of calls that can be made for some precompiles. These transactions will not revert, but simply be skipped by the sequencer if they cannot fit into the space of the circuit. Read more about the [Circuit Capacity Checker](/en/technology/sequencer/execution-node#circuit-capacity-checker).
52
-
53
-
| Precompile / Opcode | Limit |
54
-
| ------------------- | ----- |
55
-
|`keccak256`| 3157 |
56
-
|`ecRecover`| 119 |
57
-
|`modexp`| 23 |
58
-
|`ecAdd`| 50 |
59
-
|`ecMul`| 50 |
60
-
|`ecPairing`| 2 |
61
-
{/* TODO: Add SHA256 after upgrade */}
62
-
63
-
64
-
## State Account
65
-
66
-
### **Additional Fields**
67
-
68
-
We added two fields in the current `StateAccount` object: `PoseidonCodehash` and `CodeSize`.
69
-
70
-
```go
71
-
typeStateAccountstruct {
72
-
Nonceuint64
73
-
Balance *big.Int
74
-
Root common.Hash// merkle root of the storage trie
75
-
KeccakCodeHash []byte// still the Keccak codehash
76
-
// added fields
77
-
PoseidonCodeHash []byte// the Poseidon codehash
78
-
CodeSizeuint64
79
-
}
80
-
```
81
-
82
-
### **CodeHash**
83
-
84
-
Related to this, we maintain two types of codehash for each contract bytecode: Keccak hash and Poseidon hash.
85
-
86
-
`KeccakCodeHash` is kept to maintain compatibility for `EXTCODEHASH`. `PoseidonCodeHash` is used for verifying the correctness of bytecodes loaded in the zkEVM, where Poseidon hashing is far more efficient.
87
-
88
-
### CodeSize
89
-
90
-
When verifying `EXTCODESIZE`, it is expensive to load the whole contract data into the zkEVM. Instead, we store the contract size in storage during contract creation. This way, we do not need to load the code — a storage proof is sufficient to verify this opcode.
42
+
All other EVM precompiles are fully supported and behave the same as Ethereum.
91
43
92
44
## Block Time
93
45
94
-
To improve the throughput of the Scroll chain, we introduced a dynamic block time in our [Curie upgrade](/technology/overview/scroll-upgrades#curie-upgrade). During the congestion period, a block will be sealed once the transactions in the block reach the circuit limit instead of waiting for the 3-second interval. During normal hours, blocks will still be sealed at 3-second interval to ensure a consistent user experience.
46
+
Scroll uses a dynamic block time to optimize throughput. During congestion periods, blocks are sealed as soon as they are full instead of waiting for the 3-second interval. During normal hours, blocks are sealed at 3-second intervals to ensure a consistent user experience.
Copy file name to clipboardExpand all lines: src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx
+1-3Lines changed: 1 addition & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,9 +28,7 @@ When bridging ERC20 tokens, you don’t have to worry about selecting the right
28
28
All Gateway contracts will form the message and send it to the `L1ScrollMessenger` which can send arbitrary messages to L2. The `L1ScrollMessenger` passes the message to the `L1MessageQueue`. Any user can send messages directly to the Messenger to execute arbitrary data on L2. This means they can execute any function on L2 from a transaction made on L1 via the bridge. Although an application could directly pass messages to existing token contracts, the Gateway abstracts the specifics and simplifies making transfers and calls.
29
29
30
30
<Asidetype="tip"title="">
31
-
In future upgrades, users will be able to bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue`. If a message is sent
32
-
via the `L1MessageQueue`, the transaction's sender will be the address of the user sending the transaction, not the
33
-
address of the `L1ScrollMessenger`.
31
+
Users can bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue` using the `EnforcedTxGateway` contract. When a message is sent this way, the transaction's sender on L2 will be the address of the user, not the address of the `L1ScrollMessenger`.
34
32
</Aside>
35
33
36
34
When a new block gets created on L1, the Watcher will detect the message on the `L1MessageQueue` and will pass it to the Relayer service, which will submit the transaction to the L2 via the l2geth node. Finally, the l2geth node will pass the transaction to the `L2ScrollMessenger` contract for execution on L2.
Copy file name to clipboardExpand all lines: src/content/docs/en/developers/transaction-fees-on-scroll.mdx
+57-19Lines changed: 57 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -81,23 +81,29 @@ when the sequencer commits the data to L1.
81
81
82
82
As mentioned, the `L1GasPriceOracle` is used to estimate the L1 gas fee given raw transaction data. This is a **push oracle**, updated by a relayer run by Scroll.
83
83
84
-
The data fee is based on multiple factors:
84
+
<Asidetype="note"title="Fee Calculation Changes">
85
+
The L1 data fee calculation has evolved through several network upgrades:
86
+
-**Pre-Curie**: Based on calldata gas costs
87
+
-**Curie**: Introduced blob-based data availability with `commitScalar` and `blobScalar`
88
+
-**Feynman**: Added compression penalty factor
89
+
-**Galileo**: Updated penalty calculation formula
90
+
</Aside>
91
+
92
+
#### Post-Curie Fee Calculation (Current)
85
93
86
-
- The bytes which are `zeros` and `nonzeros` of an RLP-encoded transaction with Signature
87
-
-`l1BaseFee` - Current base fee on the L1
88
-
-`overhead` - Additional gas overhead of a data commitment transaction
89
-
-`scalingFactor` - A scaling factor used to account for price spikes
90
-
-`PRECISION` - A constant used to scale the final fee
94
+
Since the [Curie upgrade](/technology/overview/scroll-upgrades/curie-upgrade), transaction data is stored in blobs, and the fee is calculated as:
91
95
92
-
The following steps are taken to calculate the L1 data fee:
1. Read three fields `l1BaseFee`, `overhead`, `scalar` from the `L1GasPriceOracle` contract. The slots for these fields in the contract are:
100
+
Where `PRECISION = 1e9`.
95
101
96
-
| Field | Slot |
97
-
| --------- | ---- |
98
-
| l1BaseFee | 1 |
99
-
| overhead | 2 |
100
-
| scalar | 3 |
102
+
#### Pre-Curie Fee Calculation (Legacy)
103
+
104
+
Before Curie, the fee was based on calldata gas costs:
105
+
106
+
1. Read three fields `l1BaseFee`, `overhead`, `scalar` from the `L1GasPriceOracle` contract.
101
107
102
108
2. Count the number of zero bytes and non-zero bytes from the transaction.
103
109
3. Calculate the L1 data fee, given `TX_DATA_ZERO_GAS = 4` and `TX_DATA_NON_ZERO_GAS = 16`[^eip-2028] and `PRECISION = 1e9`:
@@ -119,31 +125,63 @@ The following steps are taken to calculate the L1 data fee:
119
125
function overhead() external view returns (uint256);
120
126
```
121
127
122
-
Returns the current L1 fee overhead
128
+
Returns the current L1 fee overhead (used in pre-Curie fee calculation).
123
129
124
130
#### scalar
125
131
126
132
```solidity
127
133
function scalar() external view returns (uint256);
128
134
```
129
135
130
-
Returns the current l1 fee scalar
136
+
Returns the current L1 fee scalar (used in pre-Curie fee calculation).
131
137
132
138
#### l1BaseFee
133
139
134
140
```solidity
135
141
function l1BaseFee() external view returns (uint256);
136
142
```
137
143
138
-
Returns the latest known l1 base fee
144
+
Returns the latest known L1 base fee.
145
+
146
+
#### l1BlobBaseFee
147
+
148
+
```solidity
149
+
function l1BlobBaseFee() external view returns (uint256);
150
+
```
151
+
152
+
Returns the latest known L1 blob base fee (introduced in Curie upgrade).
153
+
154
+
#### commitScalar
155
+
156
+
```solidity
157
+
function commitScalar() external view returns (uint256);
158
+
```
159
+
160
+
Returns the current L1 commit fee scalar (introduced in Curie upgrade).
161
+
162
+
#### blobScalar
163
+
164
+
```solidity
165
+
function blobScalar() external view returns (uint256);
166
+
```
167
+
168
+
Returns the current L1 blob fee scalar (introduced in Curie upgrade).
169
+
170
+
#### penaltyFactor
171
+
172
+
```solidity
173
+
function penaltyFactor() external view returns (uint256);
174
+
```
175
+
176
+
Returns the current compression penalty factor (introduced in Feynman upgrade).
139
177
140
178
#### getL1Fee
141
179
142
180
```solidity
143
181
function getL1Fee(bytes memory data) external view returns (uint256);
144
182
```
145
183
146
-
Computes the L1 portion of the fee based on the size of the RLP encoded input transaction, the current L1 base fee, and the various dynamic parameters.
184
+
Computes the L1 portion of the fee based on the size of the RLP encoded input transaction, the current L1 base fee, and the various dynamic parameters. The calculation method depends on the current network fork (pre-Curie, Curie, Feynman, or Galileo).
147
185
148
186
**Returns:** L1 fee that should be paid for the transaction
149
187
@@ -157,9 +195,9 @@ Computes the L1 portion of the fee based on the size of the RLP encoded input tr
157
195
function getL1GasUsed(bytes memory data) external view returns (uint256);
158
196
```
159
197
160
-
Computes the amount of L1 gas used for a transaction. Adds the overhead which represents the per-transaction gas overhead of posting the transaction and state roots to L1. Adds 74 bytes of padding to account for the fact that the input does not have a signature.
198
+
Computes the amount of L1 gas used for a transaction. After the Curie upgrade, this returns 0 since all transaction data is stored in blobs.
161
199
162
-
**Returns:** Amount of L1 gas used to publish the transaction.
200
+
**Returns:** Amount of L1 gas used to publish the transaction (0 post-Curie).
Copy file name to clipboardExpand all lines: src/content/docs/en/technology/bridge/cross-domain-messaging.mdx
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,8 +23,8 @@ Scroll has an arbitrary message passing bridge that enables token transfers and
23
23
24
24
There are two primary approaches to sending a message from L1 to L2: sending arbitrary messages via `L1ScrollMessenger` and sending enforced transactions via `EnforcedTxGateway`. Both approaches allow users to initiate a L2 transaction on L1 and call arbitrary contracts on L2. For arbitrary messages, the sender of the L2 transactions is the aliased `L1ScrollMessenger` address. For enforced transactions, the L2 sender is an externally-owned account (EOA). In addition, we provide several standard token gateways to make it easier for users to deposit ETH and other standard tokens including ERC-20, ERC-677, ERC-721, and ERC-1155. In essence, these gateways encode token deposits into a message and send it to their counterparts on L2 through the `L1ScrollMessenger` contract. You can find more details about the L1 token gateways in the [Deposit Gateways](/technology/bridge/deposit-gateways).
25
25
26
-
<Asidetype="danger"title="">
27
-
Enforced Transactions are not yet enabled on Scroll. In future upgrades, users will be able to use this functionality to bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue`.
26
+
<Asidetype="tip"title="">
27
+
Enforced Transactions allow users to bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue`. This provides a censorship-resistance mechanism, ensuring users can always force transaction inclusion on L2.
28
28
</Aside>
29
29
30
30
As depicted in Figure 1, both arbitrary messages and enforced transactions are appended to the message queue stored in the `L1MessageQueue` contract. The `L1MessageQueue` contract provides two functions `appendCrossDomainMessage` and `appendEnforcedTransaction` for appending arbitrary messages and enforced transactions respectively.
@@ -117,8 +117,8 @@ The deposited ETH of `value` amount is locked in the `L1ScrollMessenger` contrac
117
117
118
118
### Sending Enforced Transactions
119
119
120
-
<Aside type="danger" title="">
121
-
Enforced Transactions are not yet enabled on Scroll. In future upgrades, users will be able to use this functionality to bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue`.
120
+
<Aside type="tip" title="">
121
+
Enforced Transactions allow users to bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue`. This provides a censorship-resistance mechanism, ensuring users can always force transaction inclusion on L2.
122
122
</Aside>
123
123
124
124
The `EnforcedTxGateway` contract provides two `sendTransaction` functions to send an enforced transaction. In the first function, the sender of the generated `L1MessageTx` transaction is the transaction sender. On the other hand, the second function uses the passed `sender` address as the sender of the `L1MessageTx` transaction. This allows a third party to send an enforced transaction on behalf of the user and pay the relay fee. Note that the second function requires providing a valid signature of the generated `L1MessageTx` transaction that matches the `sender` address. Both `sendTransaction` functions enforce the sender to be an EOA account.
Same as Ethereum, Scroll has two account types: Externally-owned account (EOA) and contract account that holds the smart contract and additional storage.
13
13
14
-
Scroll stores additional information of the contract bytecode in the account to facilitate the zkEVM circuit to prove the state transition more efficiently.
15
-
16
-
The account in Scroll contains the following fields:
14
+
The account structure in Scroll follows the standard Ethereum format:
17
15
18
16
-`nonce`: A counter that indicates the number of transactions sent by the sender.
19
17
-`balance`: The balance of `ETH` token in the account (unit in wei).
20
-
-`storageRoot`: The root hash of the storage trie. Since Scroll uses the [zkTrie](/technology/sequencer/zktrie) for the storage trie, the `storageRoot` stores the Poseidon hash digest in a 256-bit integer.
18
+
-`storageRoot`: The root hash of the storage trie.
21
19
-`codeHash`: The Keccak hash digest of the contract bytecode.
22
-
-`PoseidonCodeHash` (**new field**): The Poseidon hash digest of the contract bytecode in a 256-bit integer.
23
-
-`CodeSize` (**new field**): The size of the contract bytecode in bytes.
24
20
25
21
## State
26
22
27
23
The state of a blockchain is a collection of account data. The _state trie_ encodes account data and their corresponding addresses to a [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree) data structure. The root of tree, or the state of the blockchain, is a cryptographic digest of all the account data contained in the tree.
28
24
29
-
Ethereum uses a data structure called [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) for both the state trie and the storage trie that stores the key-value entries stored in a smart contract. In Scroll, we replace the Patricia Merkle Trie with a more zk-friendly data structure, called zkTrie, for both state trie and storage trie. At a high level, the zkTrie data structure is a sparse binary Merkle tree with the [Poseidon hash](https://eprint.iacr.org/2019/458.pdf), a zk-friendly hash function. The [zkTrie](/technology/sequencer/zktrie) document describes more details about this data structure.
25
+
Scroll uses Ethereum's [Merkle-Patricia Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)(MPT) for both the state trie and the storage trie that stores the key-value entries in smart contracts. This ensures full compatibility with Ethereum's state proof format and tooling.
Copy file name to clipboardExpand all lines: src/content/docs/en/technology/chain/blocks.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -30,7 +30,7 @@ The block header in Scroll mirrors the structure of Ethereum's. However, certain
30
30
|`extraData`| Signature by the block's signer, followed by arbitrary additional data. |
31
31
|`mixHash`| Always 0. |
32
32
|`nonce`| Always 0. |
33
-
|`baseFee`|Currently empty in Scroll because we haven't enabled the EIP-1559. |
33
+
|`baseFee`|The base fee for this block. Since the [Curie upgrade](/technology/overview/scroll-upgrades/curie-upgrade), Scroll uses EIP-1559 with the base fee set by the sequencer. |
|`0x0a`|`point evaluation`| Not supported as a precompile. Blob verification is done in ZK circuits. |
30
27
31
-
The remaining precompiled contracts have the same behavior as Ethereum. However, their maximum usage within a block is constrained by a limit tied to the zkEVM circuit capacity.
28
+
The remaining precompiled contracts have the same behavior as Ethereum.
0 commit comments