What are the security risks of Ethereum using Rollup technology?

This article was published on the WeChat public account "White Plan," author: Qingzhou.

Ethereum has confirmed a Rollup-centric 2.0 roadmap, making Rollup a hot technology and arguably the mainstream solution for layer2 scaling. When paired with zero-knowledge proofs, Rollup could become the ultimate solution in layer2 technology.
However, as the saying goes, "there is no absolutely secure system," Rollup also has certain security risks, which developers on the Ethereum research forum are already discussing. Below is a discussion organized and modified by the White Plan team based on Ethereum developer "jchancehud"'s previous post about virtual Rollup attacks.
Reasons for Rollup's Security Risks
The basic principle of simulating Rollup attacks is: as long as the virtual state is valid, any Ethereum node can lie to the Optimistic Rollup coordinator. The coordinator will only discover this when attempting to send transactions or switch Ethereum providers (which means synchronizing the full node state).
Optimistic Rollup operates by using calldata to store block information on the Ethereum network. This process allows anyone to operate an Ethereum node and download the Rollup state. However, in reality, some people do not operate their own Ethereum nodes but rely on hosted solutions (like Infura).
Need for Validity Verification
To quickly and cost-effectively build a valid Rollup chain, one needs to conduct transactions, build states, and store them in locations outside the Ethereum network. When the Rollup coordinator receives the state history from Ethereum nodes, it can determine whether the data is valid by replaying state transactions. However, the coordinator cannot ascertain whether that state exists on-chain; the best way is to ask the Ethereum nodes.
If Human Attacks Occur
Imagine an Ethereum node service called Untrust. Untrust provides low-cost infrastructure for Ethereum dapps. If they choose not to trust, they can view specific Rollups and create fictitious histories. They can even create semi-virtual histories by extracting communication data from some real transactions and mixing it with virtual transactions. In this way, they will create a completely different current state hash, but this will only be discovered if the Rollup operator using Untrust submits a block (which would be fraudulent) to the chain.
This type of attack is not particularly powerful. Attackers cannot forge signatures or directly steal funds, but they can lie about their activities in the Rollup.
Now imagine Untrust becomes more sophisticated. They decide to attack a Rollup called MoneyMover.

When receiving a request for the MoneyMover address, they return information from nodes running a completely independent Ethereum network. In this independent Ethereum network, Untrust mirrors most transactions (making account balances appear similar) and injects their own (fake) transactions when necessary.
Now suppose Untrust finds a website that accepts payments using MoneyMover Rollup. This website runs its own MoneyMover coordinator, which connects to Untrust to access the Ethereum network.

Untrust could create fictitious transactions in its mirrored network, which the MoneyMover coordinator would interpret as valid (as long as the state transactions are valid). Since the MoneyMover coordinator is not connected to any peers, the only way to determine whether the state exists on-chain is to ask the Ethereum nodes (in this case, Untrust).
Untrust performs a fictitious transaction on its mirrored network, and the MoneyMover coordinator operated by the website detects it as a valid payment. Untrust can now access the website without paying. The website will only discover this fictitious payment when they submit a transaction or switch to another Ethereum provider (i.e., to synchronize data with other nodes).
Actual Risks That May Arise
The above attack only makes sense if the coordinator is not running its own Ethereum node. There are some problematic scenarios:

1. Downstream users of the coordinator's data cannot know whether the data they receive exists (on-chain); they cannot trust the Ethereum node the coordinator is using because the users do not run that node themselves.
2. Fraud proofers (the party proving malicious transactions) are particularly vulnerable to this attack because they only submit transactions when they detect fraud. Malicious Ethereum nodes may strip invalid transactions from the blockchain data and only return different state hashes. Fraud proofers will not be able to tell that the state hash is fictitious and will never submit a fraud claim.
3. Ethereum node operators lie to the Rollup coordinator to entice them to either submit invalid state transactions or submit invalid fraud claims. Once this happens, malicious Ethereum node operators can act as valid trading counterparts and collect the staked funds.
   Solution 1
   In the context of proof-of-work chains, coordinators can request block data and check if it is sufficiently difficult. Checking at least half of the current difficulty should make most attacks financially unfeasible.
   In proof-of-stake chains, this process becomes unfeasible because malicious Ethereum nodes may provide signatures from addresses that have never voted. They can do this by staking the collateral amount at the time of the query.
   Solution 2
   A less elegant solution is to continuously sign with reputable nodes and publish a list of Rollup state hashes that already exist on the chain. This list can be published on services like IPFS. Coordinator nodes can include a preset list of known reputable public keys (Rollup creators, EF, etc.).
   If the following conditions are met, the coordinator will know that the Rollup data is genuine:
4. All state transactions are valid.
5. All state hashes are signed by reputable sources (nodes).
   This will ensure that Rollup data is valid and non-fictitious, allowing Rollup nodes to use any Ethereum node to synchronize data.
   The above discusses the potential for Rollup security attacks as mentioned by "jchancehud." Mainly because Rollup is an off-chain state, it is easy for information synchronization issues to arise in many states. According to "jchancehud," those needing to verify the validity of off-chain states must synchronize data from other Ethereum full nodes to confirm final security, which means many platforms need to run an Ethereum node.
   Regarding the virtual attack methods mentioned above, Konstantin Kladko, CTO of the Ethereum layer2 solution team SKALE Labs, stated, "This is really interesting! I think it indicates that by compromising Infura, you can essentially compromise all Rollups."
   Of course, this represents products that communicate with Ethereum through Infura, which bears a significant scale of Ethereum node services. There has previously been discussion about whether Infura could be the largest single point of failure in the Ethereum network. For this single point of security risk, the main approach is to handle it through multi-node load balancing to avoid it as much as possible.
   Regarding the discussion by "jchancehud," the most interesting point was raised by developer "adlerjohn," who suggested that this kind of virtual "attack" seems to apply not only to optimistic Rollups but also to zkRollups, and in fact, to any smart contract.
   This inference is likely based on the notion that "as long as there is a danger of information asymmetry," the collaborative process will face the attack risks mentioned by "jchancehud."
   Thus, "adlerjohn" proposed that in section 8 of the Bitcoin white paper, there is a way to verify the correctness of information, namely that verifiers determine the longest chain and trust the longest chain. This method describes a well-known scheme that can be used to prevent Sybil nodes from providing false information, thereby not requiring the majority of computations to be honest.

Section 8 of the Bitcoin White Paper
Additionally, "adlerjohn" suggested that the Rollup state root could be emitted as an event and could even be stored in the Ethereum state, allowing for queries of forged transactions (as indicated in section 7 of the Bitcoin white paper, which states that confirmation can be achieved by verifying block headers).

Section 8 of the Bitcoin White Paper

Furthermore, "adlerjohn" also mentioned that the optimistic Rollup scheme could include a design called "minimum viable merge consensus," which can achieve data availability by publishing ordered data, allowing multiple sidechains and shards to use it.

However, it is foreseeable that using the method proposed by "adlerjohn" presents significant design challenges.
At the end of the discussion, "jchancehud" replied to "adlerjohn," stating that it cannot be determined whether this attack prediction applies to ZKRollups. However, since ZK proofs are harder to generate, it will at least be more difficult. If Rollups are widely adopted, then considering this aspect of Rollups is especially important.
Rollup coordinators can verify all block headers in the nodes before using them, which is another potential solution, although it is costly in terms of time and bandwidth. However, users are better off running their own trusted Ethereum light nodes. If the verification issue is resolved, running light nodes can also query events.

At the end of the discussion, we find that to achieve security, scalability, and efficiency, these solutions can be attempted from an engineering perspective, but the implementation process will certainly be challenging, as the different developers' discussions must ultimately be synthesized into code, along with multiple challenges including network structure, clients, languages, and user interfaces.

Time stamps move forward, blocks keep coming, and we continue to look forward.