- Blast smart contract ownership transfer to a multi-sig Gnosis Safe introduces unique security dynamics.
- The proxy contract structure allows code upgrades mirroring practices in L2 solutions like Optimism and Arbitrum.
- Potential risks in Blast’s system include unauthorized access and fund withdrawal by a multi-sig majority.
In a recent development within the cryptocurrency domain, a new wallet identified as 0x52c31 has initiated the deployment of two pivotal contracts: the Blast Deposit Proxy Contract (0xa01) and the Blast Deposit Implementation Contract (0x5f6). After this deployment, the ownership of these contracts was transferred to a Gnosis Safe smart contract, a widely recognized and trusted multi-signature smart contract.
Jarrod Watts, a Developer relations engineer at 0xPolygonLabs, shared a twitter post providing the current insights and detailed analysis of the Blast Deposit Smart Contract, particularly emphasizing its transfer of ownership to a multi-sig Gnosis Safe and the intricacies of its upgradeable proxy contract structure.
Gnosis Safe contracts stand out for their robust security feature that necessitates a majority of signers to authorize any transaction. In the case of the Safe contract now governing the Blast contracts, a setup of five signers has been established, requiring a 3-out-of-5 majority for transaction execution. Intriguingly, the identities of these signers remain anonymous, as they are associated with relatively new wallets.
The concept of ownership in the context of smart contracts, especially those like Blast Deposit, is multifaceted. Once deployed, traditional smart contracts do not permit code modifications. However, using proxy smart contracts introduces a layer of flexibility, enabling upgrades. These upgrades, which could include bug fixes or feature additions, are executed without replacing the entire contract.
The Blast proxy utilizes the UUPSUpgradeable contract from OpenZeppelin, which includes functions such as upgrade. This function allows for alterations in the implementation contract’s logic while maintaining the same contract address for user interactions. The primary risk associated with this upgradeability is the potential for the contract’s owner, in this case, the multi-sig, to alter the contract’s logic maliciously.
Despite the apparent risks, this upgradeability feature is not unique to Blast but is a common practice among various Layer 2 solutions. According to L2Beat, Optimistic Rollups like Optimism and Arbitrum can alter their system’s code, with Arbitrum implementing a roughly twelve-day delay for upgrades. Similarly, in the zkEVM sector, platforms such as Linea, Scroll, and zkSync can change their code without prior notice. At the same time, Polygon zkEVM incorporates a 10-day delay, subject to emergencies.
These L2 solutions employ multi-sig arrangements for upgrades as a temporary safety measure while the technology matures. The idea is to restrict the security council’s capabilities over time gradually. An example is Polygon‘s PIP-29 proposal, suggesting a 13-member council for governing limited-scope changes to system smart contracts.
Focusing on the Blast smart contract it functions by accepting and staking user funds into protocols like LIDO. However, it lacks features like a testnet, transaction bridging, or rollup capabilities, distinguishing it from typical L2 platforms. Users trust an anonymous group to manage their funds, with withdrawal contingent on future decisions by this group.
A critical function within the Blast contract is enableTransition, which allows for specifying a mainnetBridge contract. This contract gains access to all staked ETH and DAI with minimal restrictions. The only requirement is for the address to contain some code, regardless of its nature.
In a another scenario, a maliciously crafted smart contract could be set as the mainnetBridge, enabling the withdrawal of all funds to an external owner account (EOA). This possibility, coupled with the power of the multi-sig to approve such actions, underscores the potential risks inherent in the Blast contract system.
Despite these concerns, the probability of such malicious actions remains speculative. The unique approach of Blast in offering native yield presents an interesting trade-off in the evolving landscape of smart contracts. While the system poses certain risks, it ultimately leaves the decision to users, underscoring the need for diligence and awareness in the dynamic world of cryptocurrency.
