Blockstream Research Liquid Network

# The Risks of Expressive Smart Contracts: Lessons from the Latest Ethereum Hack

Blockstream Team
Feb 25, 2025

The fresh Bybit exploit in an Ethereum smart contract has revived long-standing debates about the security trade-offs built into the Ethereum protocol.

This new incident draws attention to the limitations of the Ethereum Virtual Machine (EVM) and its reliance on complex, stateful smart contractsвЂ”particularly when it comes to securing multisignature (multisig) wallets.

## The Core Problem with Ethereum Multisig

Multisig wallets serve as a fundamental security layer by requiring more than one signature to move funds. On Bitcoin and the Liquid Network, implementing multisig is straightforward thanks to native opcodes (e.g., OP_CHECKMULTISIG), or Schnorr-based interactive multisignatures, which keeps the code surface small and less prone to bugs.

On Ethereum, however, developers must create custom code to replicate multisig functionalityвЂ”leading to additional complexity and greater risk. These contracts must manage on-chain state, handle reentrancy (where an attacker calls a contract in the middle of its own execution), and ensure that the logic for multiple signers is correctly enforced.

Mistakes in these areas can introduce critical vulnerabilities, as we have seen with high-profile incidents like the Parity wallet hack in 2017.

## Systemic Challenges in EthereumвЂ™s Design

1. Lack of Native Multisig

BitcoinвЂ™s design includes built-in scripting commands for multisig transactions. Ethereum does not offer a direct equivalent, so you must write a contract that handles multiple signatures, tracks the current state on-chain, and updates each time a signature is added. This approach makes audits more difficult and increases the likelihood of bugs.

2. Highly Expressive Scripting Environment

The EVM allows for almost any type of computation: loops, arbitrary function calls, and interactions with multiple contracts. While this flexibility enables complex decentralized applications (dApps), it also makes formal security audits more challenging. Developers have to consider:

- Reentrancy: When a contract calls out to another contract, that contract can call back into the original one, sometimes before state updates are finalized.
- Shared Global State: Many contracts share the same global key-value store. A bug in one contract or library can open up vulnerabilities that affect completely different contracts.
- Gas Constraints: Every operation costs gas. Running out of gas at the wrong time can freeze or break contract logic.

3. Global Key-Value Store

Ethereum uses an account-based model with a universal state tree. Each contract update can influence or interact with data used by other contracts. In contrast, BitcoinвЂ™s UTXO (Unspent Transaction Output) model localizes state changes to individual transactions, reducing the risk that one contractвЂ™s flaw will leak into anotherвЂ™s operation.

> thank you. so many wise guys on threads today, who do not understand anything. it's not just ledger, all HWW do this with ETH because HWW are far too low power to interpret and contain the information to verify EVM over-complex scripts and state. https://t.co/6m1ymhum78

> вЂ” Adam Back (@adam3us) February 24, 2025

## Why EthereumвЂ™s Multisig Model Fails

Ethereum users seeking enhanced security with multisig generally face three choices:

1. Single Key Management

Straightforward, but if someone gains access to the single private key, they control all the funds.

2. Complex Multiparty Computation (MPC)

Advanced cryptographic techniques, like threshold ECDSA, reduce single points of failure. However, they often require specialized libraries and can be computationally demanding.

3. Custom Smart Contract Multisig

The most common method on Ethereum, yet also the most dangerous. It exposes users to bugs in the underlying contract code, which can be catastrophic if attackers find a loophole.

The latest incident illustrates how EthereumвЂ™s complexity increases reliance on potentially flawed interfaces, where users trust the frontend to display correct transaction details, only to be misled into signing harmful transactions with hardware that does no independent verification.

By contrast, BitcoinвЂ™s native multisig opcode keeps things simpler. You only need to specify how many signatures (e.g., 2-of-3) are required, and the protocol enforces it without complex contract logic.

## A Glimpse into the вЂњPost-SimplicityвЂќ Future

While Ethereum contends with repeated contract exploits, Bitcoin and its sidechains are evolving toward more robust multisig approaches.

On Bitcoin, cryptographic schemes like MuSig aggregate multiple signatures into one, making multisig transactions look like standard singlesig. This benefits both privacy and efficiency.

Looking further ahead, the proposed Simplicity language on Liquid aims to provide the flexibility of a higher-level scripting language while retaining BitcoinвЂ™s careful approach to security.

Rather than offering Turing-complete smart contracts, Simplicity focuses on formally verifiable scripts (easier to audit and prove correct) and advanced features like covenants and custom sighash types, all designed to avoid the pitfalls seen with the EVMвЂ™s unbounded computations.

## A Cautionary Note for Expressive Smart Contracts

The latest Ethereum multisig hack underlines a crucial lesson: the more complex your scripting environment, the more you have to worry about hidden security holes.

EthereumвЂ™s flexibility demands constant vigilance in contract coding, auditing, and updates. By contrast, BitcoinвЂ™s multisig solution is built directly into the protocol, significantly reducing the possibility of critical failure due to coding errors.

As the blockchain industry matures, itвЂ™s increasingly evident that security must be a top-level design choiceвЂ”not a feature layered on after the fact.

EthereumвЂ™s struggles with contract-based multisig make a strong case for protocols that offer robust security primitives natively, rather than placing the burden on developers to reinvent the wheel (and risk reinventing the vulnerabilities) every time they need a secure multisig solution.