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
53bac662
Unverified
Commit
53bac662
authored
Apr 17, 2023
by
Ori Pomerantz
Committed by
GitHub
Apr 17, 2023
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Update withdrawals.md
parent
4fa84781
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
4 additions
and
4 deletions
+4
-4
withdrawals.md
specs/withdrawals.md
+4
-4
No files found.
specs/withdrawals.md
View file @
53bac662
...
...
@@ -18,7 +18,7 @@ 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 pro
of
ing transaction_ refers specifically to an L1 transaction
-
A _withdrawal pro
v
ing 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
...
...
@@ -64,7 +64,7 @@ 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.
1.
A
[
relayer
][
g-relayer
]
submits a withdrawal proving transaction
with the
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.
...
...
@@ -74,9 +74,9 @@ This is a very simple contract that stores the hash of the withdrawal data.
Note that the withdrawal can be proven more than once if the corresponding output root changes.
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
1.
Once the challenge period has passed, a relayer submits a withdrawal finalizing transaction to the
`OptimismPortal`
contract.
Again, the relayer is not necessarily the same entity which
initiated the withdrawal on L2.
The relayer doesn't need to be the same entity that
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
...
...
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