feat: deterministic deployment scripts #5
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
5 tasks
zimpha
reviewed
Jul 18, 2024
yiweichi
reviewed
Jul 18, 2024
Co-authored-by: zimpha <[email protected]> Co-authored-by: Péter Garamvölgyi <[email protected]>
yiweichi
force-pushed
the
feat-deterministic-deployment
branch
from
187563f to
65c5b4e
Compare
Co-authored-by: Xi Lin <[email protected]> Co-authored-by: Morty <[email protected]>
Co-authored-by: Péter Garamvölgyi <[email protected]>
Co-authored-by: Morty <[email protected]>
|
moved it here: #63 |
shu-unifra
added a commit
to unifralabs/scroll-contracts
that referenced
this pull request
Apr 28, 2025
comment some unused contract address in verify.sh
dasdsadasca
pushed a commit
to dasdsadasca/scroll-contracts
that referenced
this pull request
May 27, 2025
I've completed a meticulous verification of 8 of your specified vulnerability claims. **Key Confirmed/Partially Confirmed Vulnerabilities:** 1. **scroll-tech#7 Cross-Chain Message Replay via State Inconsistency (CONFIRMED - High/Critical):** * **Issue:** In `L2ScrollMessenger._executeMessage` (and symmetrically in `L1ScrollMessenger.relayMessageWithProof`), the execution flag (`isL1MessageExecuted` / `isL2MessageExecuted`) is set *after* the external call. * **Impact:** If the external call succeeds but the subsequent transaction fails (e.g., out-of-gas before setting the flag), and assuming the target contract's state changes from the successful call persist (as per your detailed exploit premise), the message can be replayed, leading to double execution (e.g., double minting/transfers). * **Recommendation:** Set execution flags *before* the external call. 2. **scroll-tech#8 Gas Price Oracle Manipulation (PARTIALLY CONFIRMED - High):** * **Issue:** If a malicious L2 Sequencer can feed a significantly inflated L1 basefee to the `L1GasPriceOracle` contract on L2. * **Impact:** Users on L2 would be overcharged for initiating L2->L1 messages, potentially making withdrawals/L2->L1 interactions economically unviable. * **Mitigation:** Relies on trusted Sequencer operation and/or L2 node validation of L1 data. 3. **scroll-tech#3 Enforced Batch Mode Bypass (PARTIALLY CONFIRMED - Medium/Low impact on direct censorship):** * **Issue:** Sequencers/Provers can prevent the "finalization staleness" trigger for enforced mode by regularly finalizing batches, even if these batches exclude specific L2-originated transactions. * **Impact:** If L1->L2 messages are not also stuck, enforced mode may not activate, allowing censorship of specific L2-native transactions. This is a limitation of the trigger's scope for L2 tx censorship resistance. * **Mitigation:** Users facing L2 tx censorship would need to use L1->L2 messages. **Refuted Critical/High Vulnerabilities (as per your specific claims):** * **scroll-tech#1 ScrollChain Batch Finalization Race Condition:** REFUTED. Critical state updates occur after proof verification. * **scroll-tech#2 L1ScrollMessenger Withdrawal Proof Bypass:** REFUTED. Comprehensive hashing and replay protection are effective. * **scroll-tech#4 Gateway Router Reentrancy Attack:** REFUTED. Layered defenses (context locks, nonReentrant guards) protect against claimed exploits. * **scroll-tech#5 Batch Bridge Hash Collision Attack:** REFUTED. Hashing mechanism is sound against collisions for fixed-size inputs. * **scroll-tech#6 Lido Bridge Rebasing Token Manipulation:** REFUTED. Bridge is designed for non-rebasing wstETH. This information includes all prior documentation and detailed vulnerability analysis reports culminating in these verified findings.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Migrated from scroll-tech/scroll#1303.
Problem: The current deployment scripts are slow and error-prone. We need to predict the deployment addresses of some contracts (e.g. for preallocating funds to
L2ScrollMessengerin L2 genesis), but currently the addresses depend on the deployer private key and the order of deployment. If one transaction fails, subsequent transactions will lead to different addresses.Solution:
Caveats:
owneras a constructor argument, and the initial owner is the deployer account, so changing this also changes thecreate2deterministic address. But the addresses do not depend on deployment order anymore.