Code Analysis Why Blast is not L2 at all

Uncovering the Truth Why Blast Cannot Be Considered L2 Through Code Analysis

Author: Jarrod Watts, Polygon Developer Relations Engineer, Founder of evmkit.com; Translation: LianGuai0xjs

Someone said, “Blast is just a 3/5 multisig…”

Over the past few days, I have delved into the source code to see if this claim is true.

Here’s everything I found:

• Why is it said that Blast is a feast for the wealthy and doomsday for the little guys?
• Kyberswap was hacked for $48 million, but the drama-loving hackers took the initiative to negotiate.
• Virtual Currency Judicial Disposal Merchants How to Ensure Their Own Security?

1. A new wallet, 0x52c31, deployed two contracts: 1. 0xa01: Blast Deposit proxy contract; 2. 0x5f6: Blast Deposit implementation contract.

If you’re not familiar with these “proxy contracts” settings, we’ll come back to this later.

2. After deploying these contracts, 0x52c31 transferred ownership to the Gnosis Safe smart contract.

Gnosis Safe or “Safe2” contracts are the most popular and trusted multisig smart contracts. They require the majority of signers to sign for a transaction to be executed.

3. The Blast contract within the Safe contract now has 5 signers.

This means that the majority (i.e., 3/5) of signers are needed to execute transactions on behalf of this Safe contract. These 5 wallets are very new, but the owner is unknown.

4. So the 3/5 multisig contract is now the “owner” of the Blast Deposit contract.

As mentioned, the Blast Deposit contract consists of two contracts: the proxy and the implementation.

What does it actually mean to be their “owner”?

5. For regular smart contracts, once deployed to the blockchain, you cannot change the code. Proxy smart contracts allow you to “upgrade” (change) smart contracts without replacing the entire contract. This is commonly used to fix bugs or add features.

6. The Blast proxy implements OpenZeppelin’s UUPSUpgradeable contract. This includes functions like “_upgradeTo” that allow changing the logic of the implementation contract. This means that contracts interacting with users can maintain the same contract address.

7. The worst-case scenario for this upgradability is that the (multisig) owners change the contract’s logic to malicious content.

That sounds a bit scary, right?… Well, in fact, these “upgradeability” features are adopted by most L2 solutions today.

8. Optimistic Rollups like Optimism and Arbitrum also have this feature.

According to L2Beat:

• The code protecting the OP Mainnet and Base systems is subject to changes without prior notice.

• The upgrades on Arbitrum One have about a 12-day delay, but the council can approve them without any delay.

9. zkEVM is the same

According to L2Beat:

• The code protecting the Linea, Scroll, and zkSync systems is subject to change without notice.

• The upgrade for Polygon zkEVM has a delay of approximately 10 days (unless emergency status is activated).

10. The reason these Rollups have multi-signature capabilities for upgrades is to achieve temporary security when the technology is mature. As outlined in the L2Beat blog in its L2 phase, the final stage of Rollup should restrict the ability of these security committees to address “critical vulnerabilities”.

11. The ability of the security council weakens over time. However, the reputation of its members is important.

For example, Polygon PIP-29 proposes to be managed by 13 members for “narrow-scoped, time-bound changes to system smart contracts”.

12. Therefore, although Blast indeed has the potential to execute code upgrades and immediately steal funds through multi-signatures, many other L2 solutions *currently* have the same capabilities.

So far, I have been defending Blast. But now, here comes the bad news… let’s continue.

13. Blast is not L2.

Blast is merely a smart contract with two functions: 1. Accepting user funds. 2. Investing user funds into protocols like Lido.

No testnet, no transactions, no bridge, no Rollup, and no sending transaction data to Ethereum. This is not L2.

14. By depositing to the Blast contract, you essentially trust 3-5 strangers to stake your funds for you.

Unless these 3-5 individuals decide to do the right thing in the future, you will not be able to withdraw your money at any time. Once again, there’s no bridge here.

15. This is truly insane for me…

You cannot retrieve your money from Blast until:

• A group of strangers deploys a new contract via 3/5 multi-signature;

• The contract has the ability to withdraw funds from it;

• They transfer all funds to the new contract.

16. However, there is an even worse scenario.

I can tell you that they don’t even need to perform an “upgrade” to steal all the funds in the contract, and others cannot withdraw the funds deposited by users in this contract.

Let’s continue.

17. The function “enableTransition” requires the “mainnetBridge” contract as a parameter.

The functionality of this “mainnetBridge” contract: to retrieve all staked ETH and DAI.

So, what does this “mainnetBridge” contract look like?

18. It can be absolutely anything! Blast approves any “mainnetBridge” contract to spend the maximum possible amount of LIDO and DAI…

Are there any limitations to the correctness of this contract? Well, *yes*, let’s take a look at the code.

19. Here are the assertion statements in the “_setMainnetBridge” function.

It…checks if the address has any code! Yes, as long as it’s not an EOA address; it has approved access to all funds in the contract. The total amount of funds currently exceeds $200 million.

20. Therefore, it can be assumed that they can:

1. Create an extremely simple smart contract and set it as the mainnetBridge contract;

2. Have the smart contract receive all staked ETH and DAI (over $200 million).

Call the smart contract to withdraw all funds to an EOA wallet.

21. We’ve identified two main threats:

• Malicious code approved through a 3/5 multisig upgrade to steal funds.

• Create a malicious smart contract and set it as the “mainnetBridge” smart contract to steal funds, also through a 3/5 multisig.

22. Will this actually happen? Personally, if I had to guess, I don’t think the funds will be stolen.

Regardless, I actually think the idea of earning native Blast rewards is a very interesting trade-off.

23. Therefore, while I personally believe that sending funds to Blast carries risks in its current state, whether or not to send is ultimately the user’s decision, and I’m just here to share what I’ve seen.

I still wish the Blast team and everyone who has deposited all the best.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!