Polygon engineer: Why is it said that Blast is not an L2 at all?

Original Title: “Code Analysis: Why Blast is Not a Layer 2”

Original Author: Jarrod Watts

Original Compilation: Jinse Finance 0xjs

Editor's Note: Since the launch of the new L2 network Blast this week, it has been a hot topic in public opinion. Not only did NFT whale Christian deposit 500 stETH into Blast, but on the 22nd, Blast also announced that it had completed a $20 million financing round. Many developers have also debated the code and essence of Blast, with Polygon's Jarrod Watts bluntly stating that Blast is not a Layer 2 network. This article is translated from his X tweet.

Some say "Blast is just a 3/5 multisig…"

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

Here’s everything I observed:

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

If you are not familiar with these "proxy contract" setups, we will return to this later.

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

The Gnosis Safe or "Safe2" contract is the most popular and trusted multisig smart contract. They require a majority of signers to sign off to execute transactions.

3. The Safe contract that now owns the Blast contracts has 5 signers.

This means that a majority (i.e., 3/5) of the signers need to execute transactions on behalf of this Safe contract. All 5 wallets are very new, but the owners are unknown.

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

As we 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 perform "upgrades" (changes) to the smart contract without replacing the entire contract. This is typically used to fix bugs or add features.

6. The Blast proxy implements OpenZeppelin's UUPSUpgradeable contract. This includes functions like "_upgradeTo," which allow changes to the logic of the implementation contract. This means that the contract interacting with users can maintain the same contract address.

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

That sounds a bit scary, right? … In fact, these "features" are adopted by most L2s today.

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

According to L2Beat:

· The code protecting the OP Mainnet and Base system can be changed at any time without notice.

· Upgrades to Arbitrum One take about 12 days of delay, but the council can approve them without delay.

9. The same goes for the zkEVM world.

According to L2Beat:

· The code protecting Linea, Scroll, and zkSync systems can be changed at any time without notice.

· Upgrades to Polygon zkEVM have about a 10-day delay (unless emergency state is activated).

10. The reason these Rollups have multisig that can perform upgrades is to achieve temporary security while the technology matures. As outlined in L2Beat's L2 stage blog, the final stage of Rollups should limit the ability of these security councils to address "serious flaws."

11. The power of the security council diminishes over time. However, the notoriety of its members is important.

For example, Polygon PIP-29 proposed a council of 13 members to manage "narrow, time-limited changes to the system's smart contracts."

12. Therefore, while Blast does have the potential to execute code upgrades and immediately steal funds through multisig, *currently* many other L2 solutions also have the same capability.

So far, I have been defending Blast. However, here comes the bad news… Let's continue.

13. Blast is not L2.

Blast is simply a smart contract with two functions: 1. Accept user funds. 2. Invest user funds into protocols like Lido.

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

14. By depositing into the Blast contract, you are essentially trusting 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 this money at any time. Again, there is no bridge here.

15. This is really crazy to me…

You cannot get your money back from Blast until:

A new contract is deployed by a 3/5 multisig composed of strangers;

That contract has the functionality to withdraw funds;

They transfer all funds to the new contract.

16. However, there is an even worse scenario.

I can tell you that they do not even need to perform an "upgrade" to steal all the funds in the contract, and the funds deposited by users cannot be withdrawn by others.

Let’s look further.

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

The function of this "mainnetBridge" contract: to obtain all staked ETH and DAI.

So, what does this "mainnetBridge" contract look like?

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

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

19. Below is the assertion statement in the "_setMainnetBridge" function.

It… checks if the address has any code! Yes, as long as it is not an EOA address; it has been approved to hold all the funds in the contract. The total amount of funds has already exceeded $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) Allow that smart contract to receive all staked ETH and DAI (over $200 million)

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

21. The two main threats we discovered are:

· Approving malicious code to steal funds through a 3/5 multisig.

· Creating a malicious smart contract and setting it as the "mainnetBridge" smart contract to steal funds, also through a 3/5 multisig.

22. Will this really happen? Personally, if I had to guess, I think the funds will not be stolen.

In any case, I actually think the idea of native yield from Blast is a very interesting trade-off.

23. Therefore, while I personally believe that sending funds to Blast in its current state is risky, whether to send or not is ultimately the user's decision, and I am just here to share what I have seen.

I still wish the Blast team and everyone who has already deposited the best of luck.