@@ -18,14 +18,17 @@ an L2 account to an L1 account.
more specific terms to differentiate:
- A _withdrawal initiating transaction_ refers specifically to a transaction on L2 sent to the Withdrawals predeploy.
- A _withdrawal proofing transaction_ refers specifically to an L1 transaction which proves the withdrawal is correct (that it has been included in a merkle tree whose root is available on L1).
- A _withdrawal proofing transaction_ refers specifically to an L1 transaction
which proves the withdrawal is correct (that it has been included in a merkle
tree whose root is available on L1).
- A _withdrawal finalizing transaction_ refers specifically to an L1 transaction which finalizes and relays the
withdrawal.
Withdrawals are initiated on L2 via a call to the Message Passer predeploy contract, which records the important
properties of the message in its storage.
Withdrawals are proven on L1 via a call to the `OptimismPortal`, which proves the inclusion of this withdrawal message.
Withdrawals are finalized on L1 via a call to the `OptimismPortal` contract, which verifies that the fault challenge period has passed since the withdrawal message has been proved.
Withdrawals are finalized on L1 via a call to the `OptimismPortal` contract,
which verifies that the fault challenge period has passed since the withdrawal message has been proved.
In this way, withdrawals are different from [deposits][g-deposits] which make use of a special transaction type in the
[execution engine][g-execution-engine] client. Rather, withdrawals transaction must use smart contracts on L1 for
...
...
@@ -61,8 +64,8 @@ This is a very simple contract that stores the hash of the withdrawal data.
### On L1
1. A [relayer][g-relayer] submits a withdrawal proving transaction required inputs to the `OptimismPortal` contract. The relayer
is not necessarily the same entity which initiated the withdrawal on L2.
1. A [relayer][g-relayer] submits a withdrawal proving transaction required inputs to the `OptimismPortal` contract.
The relayer is not necessarily the same entity which initiated the withdrawal on L2.
These inputs include the withdrawal transaction data, inclusion proofs, and a block number. The block number
must be one for which an L2 output root exists, which commits to the withdrawal as registered on L2.
1. The `OptimismPortal` contract retrieves the output root for the given block number from the `L2OutputOracle`'s
...
...
@@ -72,7 +75,8 @@ This is a very simple contract that stores the hash of the withdrawal data.
1. After the withdrawal is proven, it enters a 7 day challenge period, allowing time for other network participants
to challenge the integrity of the corresponding output root.
1. Once the challenge period has passed, a relayer submits a withdrawal finalizing transaction once again to the
`OptimismPortal` contract. Again, the relayer is not necessarily the same entity which initiated the withdrawal on L2.
`OptimismPortal` contract.
Again, the relayer is not necessarily the same entity which initiated the withdrawal on L2.
1. The `OptimismPortal` contract receives the withdrawal transaction data and verifies that the withdrawal has
both been proven and passed the challenge period.
1. If the requirements are not met, the call reverts. Otherwise the call is forwarded, and the hash is recorded to
