Partnered With:

Polygon Engineer: Why is Blast not L2 at all?

Read this article in 7 Minutes

Blast is not L2, it is just a smart contract with two functions: accept user funds; put user funds into protocols such as Lido.

Original Title: "Code Analysis: Why Blast is Not L2"

Original Author: Jarrod Watts

Original Compilation: Golden Finance 0xjs

Some people say "Blast is just a 3/5 multisig..."

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

Here is everything I see:

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" settings, we will come back to this later in the article.

2.0x52c31 After deploying these contracts, transfer ownership to the Gnosis Safe smart contract.

Gnosis Safe or "Safe2" contract is the most popular and trusted multi-signature smart contract in the encryption industry. They require a majority of signers to sign before a transaction can be executed.

3.There are 5 signers in the Safe contract that currently owns the Blast contract.

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

4. Therefore, the 3/5 multi-signature contract is now owned by the Blast Deposit contract.

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

Becoming their "owner" actually means what?

5. For regular smart contracts, once deployed on the blockchain, you cannot change the code. Proxy smart contracts allow you to "upgrade" (modify) smart contracts without replacing the entire contract. This is typically used to fix errors or add functionality.

6. Blast agent implements OpenZeppelin's UUPSUpgradeable contract. This includes functions such as "_upgradeTo" that allow for changes to the logic of the implementation contract. This means that user-interacting contracts can maintain the same contract address.

7. This worst-case scenario for upgradability is that the owner of the contract (multi-signature) changes the logic of the contract to malicious content.

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

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

According to L2Beat:

· The code that protects the OP Mainnet and Base system can be modified at will without further notice.

· The upgrade of Arbitrum One is expected to be delayed by about 12 days, but the council can approve it without delay.

9.zkEVM The world is also like this

According to L2Beat:

· The code that protects the Linea, Scroll, and zkSync systems can be modified at will without further notice.

·The upgrade of Polygon zkEVM has a delay of about 10 days (unless emergency status is activated).

10. The reason why these Rollups have multiple signatures that can execute upgrades is to achieve temporary security when the technology is mature. As outlined in L2Beat's blog on the L2 phase, the final stage of Rollup should limit the ability of these security committees to address "serious flaws".

11. The ability of the Security Council weakens over time. However, the notability of its members is important.

For example, Polygon PIP-29 proposes that "changes to the system's smart contract with narrow scope and time constraints" be managed by a group of 13 members.

12. Therefore, although Blast may indeed be able to execute code upgrades and immediately steal funds through multi-signature, many other L2 solutions currently have the same functionality.