Commit 2d884f19 authored by protolambda's avatar protolambda Committed by GitHub

specs: regolith deposit spec review-changes

Co-authored-by: default avatarAdrian Sutton <adrian@oplabs.co>
parent 328ac3e8
...@@ -53,7 +53,7 @@ transaction types: ...@@ -53,7 +53,7 @@ transaction types:
for the rationale). for the rationale).
3. They buy their L2 gas on L1 and, as such, the L2 gas is not refundable. 3. They buy their L2 gas on L1 and, as such, the L2 gas is not refundable.
We define a new [EIP-2718] compatible transaction type with the prefix `0x7E`. We define a new [EIP-2718] compatible transaction type with the prefix `0x7E` to represent a deposit transaction.
A deposit has the following fields A deposit has the following fields
(rlp encoded in the order they appear here): (rlp encoded in the order they appear here):
...@@ -146,7 +146,7 @@ transaction's attributes, in exactly the same manner as it would be for an EIP-1 ...@@ -146,7 +146,7 @@ transaction's attributes, in exactly the same manner as it would be for an EIP-1
The deposit transaction is processed exactly like a type-3 (EIP-1559) transaction, with the exception of: The deposit transaction is processed exactly like a type-3 (EIP-1559) transaction, with the exception of:
- No fee fields are verified: the deposit does not have any, as it pays for gas on L1. - No fee fields are verified: the deposit does not have any, as it pays for gas on L1.
- Not `nonce` field is verified: the deposit does not have any, it's uniquely identified by its `sourceHash`. - No `nonce` field is verified: the deposit does not have any, it's uniquely identified by its `sourceHash`.
- No access-list is processed: the deposit has no access-list, and it is thus processed as if the access-list is empty. - No access-list is processed: the deposit has no access-list, and it is thus processed as if the access-list is empty.
- No check if `from` is an Externally Owner Account (EOA): the deposit is ensured not to be an EAO through L1 address - No check if `from` is an Externally Owner Account (EOA): the deposit is ensured not to be an EAO through L1 address
masking, this may change in future L1 contract-deployments to e.g. enable an account-abstraction like mechanism. masking, this may change in future L1 contract-deployments to e.g. enable an account-abstraction like mechanism.
...@@ -165,8 +165,8 @@ and gas metering is the same (with the exception of fee related changes above), ...@@ -165,8 +165,8 @@ and gas metering is the same (with the exception of fee related changes above),
Any non-EVM state-transition error emitted by the EVM execution is processed in a special way: Any non-EVM state-transition error emitted by the EVM execution is processed in a special way:
- It is transformed into an EVM-error: - It is transformed into an EVM-error:
i.e. the deposit will always be included, but its receipt will indicate a failure, i.e. the deposit will always be included, but its receipt will indicate a failure
if it runs into a non-EVM a state-transition error, e.g. failure to transfer the specified if it runs into a non-EVM state-transition error, e.g. failure to transfer the specified
`value` amount of ETH due to insufficient account-balance. `value` amount of ETH due to insufficient account-balance.
- The world state is rolled back to the start of the EVM processing, after the minting part of the deposit. - The world state is rolled back to the start of the EVM processing, after the minting part of the deposit.
- The `nonce` of `from` in the world state is incremented by 1, making the error equivalent to a native EVM failure. - The `nonce` of `from` in the world state is incremented by 1, making the error equivalent to a native EVM failure.
......
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