@Adeilton_Filho 24 February 2025

Ethereum: The Root of the $1.5 Billion Bybit Exploit Recently, the exchange Bybit suffered an attack that resulted in the loss of over $1.5 billion from a supposedly "cold" wallet. This incident highlights a larger issue: the complexity of the Ethereum blockchain, which can make even the most cautious institutions vulnerable to unforeseen attacks. To better understand this exploit, I recommend watching the video by Brazilian programmer Tiago Salém, who explains the incident in detail here. https://youtu.be/Nx7kzGf6snk?si=-8UPCzT0sTmN3_iV https://youtu.be/Nx7kzGf6snk?si=PR7_My_ssWjtuAS_ The Trap of Ethereum's Complexity Ethereum was created as a decentralized platform to run smart contracts, which are codes that automatically execute agreements when certain conditions are met. While this flexibility is appealing, it also comes at a cost: technical complexity. Layers Upon Layers of Abstraction In Bybit's case, the exchange used Gnosis Safe, a popular security solution. However, this choice reveals the complications of Ethereum: **Proxy Standards**: Use of proxy contracts, which can point to other contracts, creating multiple layers where errors can occur. **DelegateCall**: A command that allows one contract to execute the code of another. This is powerful but can be dangerous. **Storage Slots**: The way Ethereum stores data can lead to unexpected vulnerabilities. **Signatures and Verification**: The complex signature system for transactions adds another layer of potential failures. These layers of complexity make it difficult to anticipate all vulnerabilities. How Complexity Allowed the Attack Bybit did not make a simple security mistake; it was affected by Ethereum's complexity. Here’s how it happened: The Hidden Breach in the Fundamentals The attacker exploited a feature of Ethereum: the address of the proxy contract is stored in a specific location in memory (slot 0). This is not an obvious flaw but a consequence of how Ethereum was designed. // Apparently harmless code: function transfer(address _addr) external { // Modifies slot 0 assembly { sstore(0, _addr) } } When this code is executed, it can compromise the security of a valuable system not due to negligence but because of the complexity of how Ethereum manages contracts.

The Illusion of Multi-Signature Security Gnosis Safe uses multiple signatures to authorize transactions, a method that should be secure. However, Ethereum's complexity can make this system vulnerable: The attacker obtained a valid signature (possibly through deception). With a single signed transaction, they altered the system's implementation. Thus, the security guarantees were nullified. A system that appears secure can become vulnerable due to complex interactions within Ethereum. Lightning Network: When Complexity Threatens Even Bitcoin While Bitcoin was created with a simple structure, the introduction of the Lightning Network (LN) for scalability brings similar complexity risks as Ethereum. Complexity in the Lightning Network The Lightning Network adds several layers to Bitcoin: **Bidirectional Payment Channels**: Require participants to always be online. **HTLC Contracts**: Create complex temporal dependencies. **Multi-Hop Routing**: Depends on intermediary nodes, which can fail. **Liquidity Management**: Can lock funds in unbalanced channels. **Watchtowers**: A structure needed to monitor for fraud.

New Risks in the Lightning Network These complexities have already resulted in vulnerabilities: **Congestion Attacks**: Attackers can overwhelm channels with false transactions. **Channel Exhaustion Attacks**: Manipulating routing to drain liquidity. **Pre-image Disclosure Issues**: Failures can leave funds trapped. **Wormhole Attacks**: Exploiting routing flaws. **Pinning Attacks**: Using Bitcoin's limitations to delay transactions. BCH and SmartBCH: The Security of Simplicity In contrast to the complexity of Ethereum and the Lightning Network, Bitcoin Cash (BCH) offers a different approach to smart contracts, prioritizing security through simplicity. The Minimalist Approach to Contracts in BCH Bitcoin Cash contracts are based on simple principles: **Limited Script Language**: Unlike Ethereum, BCH uses a language that avoids unpredictable behaviors. **Predefined Contracts**: Instead of allowing any code, BCH uses tested contract templates. **Determinism**: BCH contracts have predictable outcomes. **No Shared Global State**: BCH contracts are isolated, reducing vulnerabilities. CashScript: Security Through Restrictions The CashScript language was designed to avoid Ethereum's issues: // Example of a CashScript contract - simple and predictable contract EscrowWithTimeout( pubkey buyer, pubkey seller, pubkey arbiter, int timeout ) { // Resolution by agreement function spend(sig buyerSig, sig sellerSig) { require(checkSig(buyerSig, buyer)); require(checkSig(sellerSig, seller)); } // Resolution via arbiter function resolve(sig arbiterSig, sig secondSig, pubkey secondPubkey) { require(checkSig(arbiterSig, arbiter)); require(checkSig(secondSig, secondPubkey)); require( secondPubkey == buyer || secondPubkey == seller ); } // Resolution by timeout function timeout(sig buyerSig) { require(checkSig(buyerSig, buyer)); require(tx.time >= timeout); } } This contract illustrates the philosophy that functionality should be clear and predictable.

SmartBCH: The Best of Both Worlds The SmartBCH sidechain complements BCH with EVM compatibility but with safeguards: **Isolation by Design**: Operates independently of BCH. **Simplified Federation Model**: A clear set of validators. **Selective Compatibility**: Implements parts of the EVM with modifications for security. **Specific Mitigations**: Learning from Ethereum's exploits. Why the Bybit Attack Would Be Impossible on BCH The Bybit hack exploited specific vulnerabilities of Ethereum. In BCH: There are no proxy contracts that change implementation in real-time. The absence of `delegateCall` prevents this type of vulnerability. BCH contracts cannot arbitrarily modify storage slots. The security model is based on well-defined and tested contracts. Security Through Simplicity BCH shows that true innovation in smart contracts lies in finding a balance between functionality and security: **Sufficient Functionality**: Offers the essentials for financial contracts. **Deliberate Restrictions**: Limits what contracts can do. **Isolation by Design**: Avoids complex interactions. **Formal Verifiability**: Simpler contracts can be verified. Why Ethereum Is Vulnerable to Attacks Ethereum's complexity creates a favorable environment for attacks for several reasons: 1. Wide Attack Surface Each new feature in Ethereum increases the chances of an attack. This includes: Upgradable proxies Contracts that interact with each other Storage slots Governance mechanisms 2. Irreversible Consequences In Ethereum, a malicious transaction cannot be reversed. This becomes a problem when combined with complexity: There’s no way to "undo" a transaction. There’s no central authority to correct mistakes. 3. Non-Intuitive Tools Development in Ethereum uses languages like Solidity, which do not prioritize security: Non-intuitive behaviors. Lack of security guarantees. Lessons for the Crypto Ecosystem The attack on Bybit, the risks of the Lightning Network, and BCH's approach offer important lessons: **Simplicity is Security**: Less complexity can lead to greater security. **Necessary Limits**: Allowing execution of any code can be risky. **New Approaches**: We need to rethink how we design secure systems. **Functionality vs. Security**: Adding features is not always the best option. Conclusion The attack on Bybit leads us to question complexity in blockchain platforms. While Ethereum offers flexibility, its complexity can introduce vulnerabilities. Bitcoin Cash, with its simplified approach, may provide a solution that prioritizes security. As the industry evolves, the future may belong not to the most powerful platforms but to those that balance functionality and security—an equilibrium that Bitcoin Cash seems to be closer to achieving. *Note: This analysis reflects a viewpoint on the risks of complexity in blockchain systems. It’s important to consider different perspectives when evaluating the security of these technologies.*