From 648a8beed7ab35e978069e9dcb7d14c07798c27e Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Mon, 10 Apr 2023 12:45:43 -0500 Subject: [PATCH 01/13] fix(withdrawals): Sherlock #012 fixing https://github.com/sherlock-audit/2023-01-optimism-judging/blob/b7921698c1c537714c5f2021aa46ce0a1935ba39/1-specs-findings/1-processed/1-true/two-step-not-in-spec/012.md#L1 --- specs/withdrawals.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index 61bd8e45e147..229216590b61 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -59,8 +59,8 @@ This is a very simple contract that stores the hash of the withdrawal data. ### On L1 -1. A [relayer][g-relayer] submits the required inputs to the `OptimismPortal` contract. The relayer need - not be the same entity which initiated the withdrawal on L2. +1. A [relayer][g-relayer] submits 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. 1. The `OptimismPortal` contract retrieves the output root for the given block number from the `L2OutputOracle`'s @@ -70,7 +70,7 @@ 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 the withdrawal transaction once again to the - `OptimismPortal` contract. Again, the relayer need not be 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 From d8caba44a4a3ee980469b53d6b585ae6013ec0f4 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Mon, 10 Apr 2023 12:52:35 -0500 Subject: [PATCH 02/13] fix(specs/withdrawal): Sherlock issue https://github.com/sherlock-audit/2023-01-optimism-judging/blob/b7921698c1c537714c5f2021aa46ce0a1935ba39/1-specs-findings/1-processed/1-true/getL2OuputAfter-dedupe/094.md#L1 --- specs/withdrawals.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index 229216590b61..3ad6d42d06e3 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -64,7 +64,7 @@ This is a very simple contract that stores the hash of the withdrawal data. 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 - `getL2OutputAfter()` function, and performs the remainder of the verification process internally. + `getL2Output()` function, and performs the remainder of the verification process internally. 1. If proof verification fails, the call reverts. Otherwise the hash is recorded to prevent it from being re-proven. 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 From 3e281cff224b34729264005b8dc759d3f12a35a7 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Wed, 12 Apr 2023 09:41:17 -0500 Subject: [PATCH 03/13] fix(specs/withdrawals): Sherlock #215 https://github.com/sherlock-audit/2023-01-optimism-judging/blob/b7921698c1c537714c5f2021aa46ce0a1935ba39/1-specs-findings/1-processed/1-true/names/215.md#L1 --- specs/withdrawals.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index 3ad6d42d06e3..33a8fc8756b1 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -175,7 +175,7 @@ The following inputs are required to prove and finalize a withdrawal: These inputs must satisfy the following conditions: 1. The `l2BlockNumber` must be the block number that corresponds to the `OutputProposal` being proven. -1. `L2OutputOracle.getL2OutputAfter(l2BlockNumber)` returns a non-zero `OutputProposal`. +1. `L2OutputOracle.getL2Output(l2BlockNumber)` returns a non-zero `OutputProposal`. 1. The keccak256 hash of the `outputRootProof` values is equal to the `outputRoot`. 1. The `withdrawalProof` is a valid inclusion proof demonstrating that a hash of the Withdrawal transaction data is contained in the storage of the L2ToL1MessagePasser contract on L2. @@ -196,7 +196,7 @@ These inputs must satisfy the following conditions: 1. It should only be possible to finalize the withdrawal once. 1. It should not be possible to relay the message with any of its fields modified, ie. 1. Modifying the `sender` field would enable a 'spoofing' attack. - 1. Modifying the `target`, `message`, or `value` fields would enable an attacker to dangerously change the + 1. Modifying the `target`, `data`, or `value` fields would enable an attacker to dangerously change the intended outcome of the withdrawal. 1. Modifying the `gasLimit` could make the cost of relaying too high, or allow the relayer to cause execution to fail (out of gas) in the `target`. From be9733cd49e96d94d4dd8a9c5f14d853b61c0fd5 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Wed, 12 Apr 2023 10:02:55 -0500 Subject: [PATCH 04/13] fix(specs/withdrawal): Sherlock #166 Based on https://github.com/sherlock-audit/2023-01-optimism-judging/blob/b7921698c1c537714c5f2021aa46ce0a1935ba39/1-specs-findings/1-processed/1-true/portal-interface/166.md#L1 --- specs/withdrawals.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index 33a8fc8756b1..502538ec6f2e 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -139,7 +139,8 @@ withdrawals: ```js interface OptimismPortal { - event WithdrawalFinalized(bytes32 indexed); + event WithdrawalFinalized(bytes32 indexed withdrawalHash, bool success); + function l2Sender() returns(address) external; From fdc62541c68e9916b30f5a8500a850a7882a3292 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Wed, 12 Apr 2023 10:19:17 -0500 Subject: [PATCH 05/13] fix(specs/withdrawal.md): Sherlock #164 https://github.com/sherlock-audit/2023-01-optimism-judging/blob/b7921698c1c537714c5f2021aa46ce0a1935ba39/1-specs-findings/1-processed/1-true/message-passer-interface/164.md#L1 --- specs/withdrawals.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index 502538ec6f2e..1c348c4b9da3 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -102,7 +102,7 @@ interface L2ToL1MessagePasser { function initiateWithdrawal(address _target, uint256 _gasLimit, bytes memory _data) payable external; - function nonce() view external returns (uint256); + function messageNonce() public view returns (uint256); function sentMessages(bytes32) view external returns (bool); } @@ -191,7 +191,7 @@ These inputs must satisfy the following conditions: [polygon-dbl-spend]: https://gerhard-wagner.medium.com/double-spending-bug-in-polygons-plasma-bridge-2e0954ccadf1 -1. For each withdrawal initiated on L2 (ie. with a unique `nonce`), the following properties must hold: +1. For each withdrawal initiated on L2 (i.e. with a unique `messageNonce()`), the following properties must hold: 1. It should only be possible to prove the withdrawal once, unless the outputRoot for the withdrawal has changed. 1. It should only be possible to finalize the withdrawal once. From 9a94d6fb668c210a7ff3837c15f6fd6d500cfd09 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Wed, 12 Apr 2023 10:48:51 -0500 Subject: [PATCH 06/13] fix(specs/withdrawals): Sherlock #217 https://github.com/sherlock-audit/2023-01-optimism-judging/blob/b7921698c1c537714c5f2021aa46ce0a1935ba39/1-specs-findings/1-processed/1-true/two-step-not-in-spec/217.md#L1 --- specs/withdrawals.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index 1c348c4b9da3..1bb3e50c8d4c 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -18,12 +18,14 @@ 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 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 finalized on L1 via a call to the `OptimismPortal` -contract, which proves the inclusion of this withdrawal message. +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. 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 @@ -59,7 +61,7 @@ This is a very simple contract that stores the hash of the withdrawal data. ### On L1 -1. A [relayer][g-relayer] submits the required inputs to the `OptimismPortal` contract. The relayer +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. @@ -69,7 +71,7 @@ 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 the withdrawal transaction once again to the +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. 1. The `OptimismPortal` contract receives the withdrawal transaction data and verifies that the withdrawal has both been proven and passed the challenge period. From 557a9872fd0d191eee7565267d59c968a32d4849 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Wed, 12 Apr 2023 11:01:59 -0500 Subject: [PATCH 07/13] fix(specs/withdrawal): Last of the Sherlock comments (#233) Based on: https://github.com/sherlock-audit/2023-01-optimism-judging/blob/b7921698c1c537714c5f2021aa46ce0a1935ba39/1-specs-findings/1-processed/1-true/233.md#L1 --- specs/withdrawals.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index 1bb3e50c8d4c..4906a0c29098 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -148,7 +148,7 @@ interface OptimismPortal { function proveWithdrawalTransaction( Types.WithdrawalTransaction memory _tx, - uint256 _l2BlockNumber, + uint256 _l2OutputIndex, Types.OutputRootProof calldata _outputRootProof, bytes[] calldata _withdrawalProof ) external; From a822838b90cc5b4e0e7e927dbeae17e09185cb41 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Wed, 12 Apr 2023 11:16:32 -0500 Subject: [PATCH 08/13] fix(specs/withdrawal): Line lengths --- specs/withdrawals.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index 4906a0c29098..f96e070bab1c 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -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 From 4fa8478180a267b6867123b4a917000d71db717d Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Wed, 12 Apr 2023 11:33:15 -0500 Subject: [PATCH 09/13] fix(specs/withdrawals): Trailing spaces --- specs/withdrawals.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index f96e070bab1c..cc43f3a96dc8 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -18,8 +18,8 @@ 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 +- 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. @@ -27,7 +27,7 @@ more specific terms to differentiate: 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, +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 @@ -75,7 +75,7 @@ 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. + `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. From 53bac6622f4ff31888f7e29ba06d2b165df224a2 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Mon, 17 Apr 2023 10:11:15 -0500 Subject: [PATCH 10/13] Update withdrawals.md --- specs/withdrawals.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index cc43f3a96dc8..d0ee97657d8f 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -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 proofing transaction_ refers specifically to an L1 transaction +- A _withdrawal proving 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 From d585586dd009079cf5d6dcda8a2ce09fabab58b4 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Mon, 17 Apr 2023 18:36:17 -0500 Subject: [PATCH 11/13] fix(specs/withdrawals) Bring more in line with the code. --- specs/withdrawals.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index d0ee97657d8f..d6649515d951 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -175,14 +175,14 @@ The following inputs are required to prove and finalize a withdrawal: - `data`: Data to send to the target. - `gasLimit`: Gas to be forwarded to the target. - Proof and verification data: - - `l2BlockNumber`: The L2 block number that corresponds to the output root. + - `l2OutputIndex`: The index in the L2 outputs where the applicable output root may be found. - `outputRootProof`: Four `bytes32` values which are used to derive the output root. - `withdrawalProof`: An inclusion proof for the given withdrawal in the L2ToL1MessagePasser contract. These inputs must satisfy the following conditions: -1. The `l2BlockNumber` must be the block number that corresponds to the `OutputProposal` being proven. -1. `L2OutputOracle.getL2Output(l2BlockNumber)` returns a non-zero `OutputProposal`. +1. The `l2OutputIndex` must be the index in the L2 outputs that contains the applicable output root. +1. `L2OutputOracle.getL2Output(l2OutputIndex)` returns a non-zero `OutputProposal`. 1. The keccak256 hash of the `outputRootProof` values is equal to the `outputRoot`. 1. The `withdrawalProof` is a valid inclusion proof demonstrating that a hash of the Withdrawal transaction data is contained in the storage of the L2ToL1MessagePasser contract on L2. From 80979cc3860623efc9d51aeaa56dc242fbf4f56e Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Mon, 17 Apr 2023 18:40:24 -0500 Subject: [PATCH 12/13] fix(specs/withdrawals): Lint --- specs/withdrawals.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index d6649515d951..aba003504651 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -64,7 +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 with the 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. @@ -181,7 +182,7 @@ The following inputs are required to prove and finalize a withdrawal: These inputs must satisfy the following conditions: -1. The `l2OutputIndex` must be the index in the L2 outputs that contains the applicable output root. +1. The `l2OutputIndex` must be the index in the L2 outputs that contains the applicable output root. 1. `L2OutputOracle.getL2Output(l2OutputIndex)` returns a non-zero `OutputProposal`. 1. The keccak256 hash of the `outputRootProof` values is equal to the `outputRoot`. 1. The `withdrawalProof` is a valid inclusion proof demonstrating that a hash of the Withdrawal transaction data From 111eb357d818f4ed3e65223b5a16554b8ed8a4c7 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Mon, 17 Apr 2023 18:51:20 -0500 Subject: [PATCH 13/13] fix(specs/withdrawals): Still lint --- specs/withdrawals.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/withdrawals.md b/specs/withdrawals.md index aba003504651..afc1737b657a 100644 --- a/specs/withdrawals.md +++ b/specs/withdrawals.md @@ -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 with the required inputs +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