By destroying Infrua, basically all Rollups can be destroyed.Text｜Qingzhou
Ethereum has confirmed the 2.0 roadmap centered on Rollup, which makes Rollup a hot technology, and it can also be said that it has become the mainstream technology for layer2 expansion. If paired with zero-knowledge proof proof, Rollup will be a master of solutions in layer2 technology.But as the saying goes, there is no absolutely safe system, Rollup also has certain security risks. Developers in the Ethereum Research Forum have already discussed this matter. On January 20, Ethereum developer jchancehud posted a discussion about virtual Rollup attacks.Reasons for Rollups Security Risks
The rationale behind the simulated Rollup attack is that any Ethereum node can lie to the Optimistic Rollup coordinator as long as the virtual state is valid. And the coordinator only discovers this when trying to send transactions or switch ethereum providers (meaning sync full node state).Need to verify validity
If you want to build a valid Rollup chain quickly and cheaply, all you need to do is conduct transactions, build state, and store it in other locations outside of the Ethereum network. When a Rollup coordinator receives state history from an Ethereum node, the coordinator can determine whether the data is valid by replaying state transactions. However, the coordinator cannot be sure that the state exists on the chain, the best way is to ask the Ethereum node.In the event of a human attackIf you imagine an Ethereum node service called Untrust. Untrust provides low-cost infrastructure for Ethereum dapps. If they choose not to trust, they can look at a particular Rollup and create a fictional history. They can even create semi-virtual histories by extracting communication data from some real transactions and mixing it with virtual ones.This way, they will create a completely different hash of the current state, but this will only be discovered (which would be fraudulent) if a block is committed (on-chain) using Untrusts Rollup operator.This type of attack is not particularly powerful. Attackers cannot forge signatures, cannot steal funds directly, but can lie about their activities in a Rollup.Imagine Untrust getting more complicated. They decided to attack Rollup called MoneyMover.When requests for MoneyMover addresses are received, they return information from nodes running a completely separate Ethereum network. On this separate Ethereum network, Untrust mirrors most transactions (making account balances look similar) and injects its own (fake) transactions when needed.Now say Untrust finds a site that pays with MoneyMoverRollup. The site runs its own MoneyMover coordinator that connects Untrust to access the Ethereum network.Untrust may create fictitious transactions in its mirror network that the MoneyMover coordinator interprets as valid (as long as the state transaction is valid). Since the MoneyMover coordinator is not connected to any peers, the only way to determine presence on-chain is to ask an Ethereum node (Untrust in this case).Actual possible risks
The attack above is only meaningful if the coordinator is not running its own Ethereum node. There are some situations where this is problematic:1. Downstream consumers of the coordinators data have no way of knowing whether the data they receive exists (on-chain), and they cannot trust the eth node the coordinator is using because the consumer does not run that node themselves.2. Fraud provers (the party proving a malicious transaction) are especially vulnerable to this attack because they only submit transactions when fraud is detected. A malicious eth node could strip invalid transactions from the blockchain data and just return a different state hash. A fraud prover will have no way of knowing that the state hash is fabricated and will never commit a fraud claim.In the context of a proof-of-work chain, a coordinator can request block data and check whether it is hard enough. Checking at least half of the current difficulty should make most attacks financially impossible.A less elegant solution is to continuously sign reputable nodes and publish a list of Rollup state hashes that already exist on-chain. The list can be published on a service like IPFS. The coordinator node can include a preset list of known reputable public keys (Rollup Creator, EF, etc.).Coordinators know that Rollup data is real if:1. All status transactions are valid.2. All state hashes are signed by reputable sources (nodes).This will ensure that Rollup data is valid and non-fictitious, and will allow Rollup nodes to use any Ethereum node to sync data.The above is the possibility of Rollup security attack discussed by jchancehud.The main reason is that Rollup is an off-chain state, and it is easy for information synchronization to be untimely in many states. According to jchancehud, the party that needs to verify whether the off-chain state is valid needs to synchronize the data of other Ethereum full nodes to confirm Ultimately for security, this means that many platforms need to run an Ethereum node.Regarding the virtual attack method mentioned above, Konstantin Kladko, chief technology officer of Ethereums layer2 solution team SKALE Labs, said, This is really interesting! I think it shows that by destroying Infrua, basically all Rollups can be destroyed. .”Of course, this represents those products that communicate with Ethereum through Infura. Infura undertakes a large scale of Ethereum node services. There have also been discussions on whether Infura will be the biggest single point of vulnerability in the Ethereum network. As for this single-point security risk, it is mainly handled in a multi-node load balancing manner to avoid it as much as possible.As for the discussion of jchancehud, the most interesting thing is that the developer adlerjohn proposed that this virtual attack seems to be applicable not only to optimistic Rollup, but also to zkRollup, and in fact to any smart contract.This inference is likely to be based on the collaborative process as long as there is a danger of information asymmetry, it will face the risk of attack mentioned by jchancehud.
Section 8 of the Bitcoin White Paper
Section 7 of the Bitcoin White Paper
In addition, adlerjohn also mentioned that the optimistic Rollup scheme can also include a design called Minimum Feasible Merge Consensus, which can achieve data availability by publishing ordered data, allowing multiple sidechains, shards use.But it is foreseeable that using the method proposed by adlerjohn is more difficult to design.At the end of the discussion, jchancehud replied to adlerjohn that it is not sure whether this attack prediction is applicable to ZKRollup. But since ZK proofs are harder to generate, at least it will be harder. Thinking about Rollups in this way is especially important if they become widely adopted.Rollup coordinators can verify all block headers in a node before using the node, which is another potential solution, although expensive in time and bandwidth. But users are better off running eth light nodes they know they can trust. Running a light node can also query events if validation issues have been resolved.At the end of the discussion, we will find that in order to achieve security, scalability, and efficiency, these solutions can be tried according to the idea of engineering, but the implementation process must be difficult, because the discussion ideas of different developers need to synthesize code at the end , and includes many challenges such as network structure, client, language, and operation interface.The time stamp moves forward, and the blocks dont stop. Lets continue to look forward to it. 
Group
