Medium 1. DDos to prevent poll owner from generating mergedStateRoot After voting is over, poll owner is supposed to call mergeMaciStateAqSubRoots(...) repeatedly, until all subtrees are merged, then owner will then call mergeMaciStateAq(...) to create mergedStateRoot. However, the last call may always be front-run by a signup call by an unknowing or malicious user, such that subTreesMerged is no longer True. https://github.com/privacy-scaling-explorations/maci/blob/776f9ece4191c765e59168b3214418e461af909c/contracts/contracts/trees/AccQueue.sol#L149 If the signup gate keeper maintains only limited registration quota, then this is a gas-grief attack, as mergeMaciStateAqSubRoots(...) is more expensive then a signup. However, if there is no limit on registration, the poll may be DDosed to prevent tallying.

The Power of Crowdsourcing Smart Contract Security for L2 scaling solutions By @0xDatapunk at PSE Security Introduction Smart contract security is of paramount importance in the blockchain ecosystem. As the adoption of Layer 2 (L2) solutions increases, ensuring the security of these contracts becomes even more critical. Due to their complexity and the potential for significant value stored in L2 contracts, they become attractive targets for malicious actors. In this article, we will explore the power of crowdsourcing smart contract security and how it compares to traditional audit firms for two leading L2 scaling solutions (Optimism and zkSync). We will delve into their engagement with auditing firms and the surprising findings from crowdsourced security competitions. Traditional audit firms vs crowdsourcing security Traditional audit firms and crowdsourcing security offer different approaches to enhancing smart contract security. Traditional audit firms typically involve a select group of experts who conduct a comprehensive review of the smart contracts. They bring deep expertise and experience in identifying vulnerabilities and providing recommendations. These firms follow established methodologies and provide a sense of assurance due to their reputation and track record.

While Optimism has been operating since Nov of 2021 (see "An Introduction to Optimism’s Optimistic Rollup" by Kyle Charbonnet), the Optimism team is hard at work for next major release of the Optimism network called "Bedrock". As the release is planned for the last quarter of 2022, it is time to take a look at its solidity contracts and understand transaction trails as well as security measures around them. Current Optimism From various articles describing how current Optimism works and past audits, it seems the current version of Optimism had gone through a few major iterations, and the final deployed version has a much smaller scope than Optimism set out to do. Most notably, order of transactions in CanonicalTransactionChain is not guaranteed and fraud proof procedure is not currently in operation, despite its on-chain vestige. This is quite understandable, given the current highly centralized stage of the project. Transaction flows A user of Optimism interacts with the system through three different types of transactions: L1 to L2, L2 to L1 and L2 transactions. Based on current contracts, the following diagram depicts how messages are passed through different components.

Current OP It seems current OP is a very centralized system, where sequencer, proposer, fraudverifier, bond manager all have a single address, likely controlled by optimism team. If this is the case, I found it hard for the system to really go wrong. Q1: enqueue() and appendSequencerBatch() in CanonicalTransactionChain.sol do not check the order of transactions, how is it being ensured? Q2: for deposit transactions, L2bridge received the cross domain message with require(undoL1ToL2Alias(msg.sender) == l1CrossDomainMessager). My question is how is this msg sent from this sender? L1CrossDomainMessager is not predeployed, therefore the sender should have a random address on L2 https://github.com/ethereum-optimism/optimism/blob/1975480fc04d532ebf5cf8ff263a8f3b626f5aff/packages/contracts/contracts/L2/messaging/L2CrossDomainMessenger.sol#L102 Q3: role of replayMessage how does replayMessage work? It can be called by anyone and the same existing transaction may be processed more than once. Is it a concern?