Clearing the Air: Understanding the Complexities and False Assumptions in Ethereum Development

As software developers, we often hold beliefs that are not entirely accurate, especially when dealing with complex systems such as Ethereum. These assumptions might seem harmless at first glance, but they can lead to severe bugs, incorrect program behavior, and general misunderstanding of the system.

Inspired by articles like Falsehoods programmers believe about time zones and others that highlight common misconceptions, this technical review aims to debunk assumptions about Ethereum, particularly now that it has transitioned to a Proof-of-Stake (PoS) consensus mechanism.

Misunderstanding Gas in the PoS Era

Assumption 1: Calling estimateGas will return the exact gas required by my transaction.

Reality: estimateGas returns an approximation of the gas your transaction would require if it were mined immediately. As the state of the Ethereum chain continuously changes, your transaction might require a different amount of gas when it's actually included in a block. You can learn more about this from the Ethereum documentation.

Assumption 2: The same code execution will always require the same amount of gas.

Reality: This is not always the case, especially considering operations like SSTORE, which are more expensive when writing to a new storage position than an already occupied one (EIP2200).

Assumption 3: Sending more gas will always work.

Reality: Contracts can inspect the gas received in a transaction. It's possible to code a contract to fail intentionally if it receives too much gas. More about this can be read here.

Misconceptions about Transactions in PoS

Assumption 4: A transaction will eventually get mined if it was accepted by a node.

Reality: Even with Ethereum's transition to PoS, network congestion can cause gas prices to fluctuate significantly. If gas prices rise, your transaction may be evicted from the mempool (the collective set of all transactions waiting to be processed), meaning you will need to resubmit it.

Assumption 5: Validators will always pick the transactions with the highest gas price.

Reality: Validators, formerly miners, have the freedom to select transactions as they please. They can inject their own transactions or even include transactions based on criteria outside the protocol. More about this in the Validator Strategies documentation.

Nonces – What Are They Really?

Assumption 6: I can get the nonce for my next transaction via getTransactionCount.

Reality: This is not always true, especially if you query for your transaction count on the latest block. It's important to consider any pending transactions that may not be accounted for.

Log Monitoring – It's Not Always Straightforward

Assumption 7: I can reliably monitor events by calling getLogs continuously.

Reality: While this method may seem effective, blockchain reorganizations can disrupt your monitoring process. It's crucial to consider that if a block you've already seen gets reorganized, you might never know if any of the events you've seen need to be adjusted.

Assumption 8: I can reliably monitor events via a WebSocket subscription.

Reality: This assumption requires the infrastructure or node you are interacting with to stay online. If they happen to go offline, even briefly, you risk missing out on certain events.

We hope that debunking these assumptions can help developers build more robust and reliable Ethereum-based applications, taking full advantage of the network's capabilities in the PoS era.

Understanding Contracts in Ethereum's PoS Era

Assumption 1: Smart contracts are immutable

Reality: While contracts are generally immutable once deployed, there are mechanisms such as DELEGATECALL and CALLCODE that can alter a contract's behavior by executing code from another contract. You can learn more about these from the Solidity documentation.

Assumption 2: Contracts without any kind of CALLs are immutable

Reality: Ethereum introduced CREATE2 in EIP-1014. This allows contracts to be deployed deterministically (i.e., to the same address given the same inputs). If such a contract includes a self-destruct mechanism, it can be destroyed and recreated with different code, thereby changing its behavior.

Dispelling Assumptions About ERC20 Tokens

Assumption 3: All ERC20 tokens behave the same

Reality: While ERC20 tokens follow a standardized interface, their implementation can significantly differ. Some tokens may revert on failure, others may return false, and others might not respond at all. This is why wrappers like OpenZeppelin's SafeERC20 exist - to smooth out these differences and provide a consistent interface.

ETH in the Proof-of-Stake Context

Assumption 4: ETH total supply can only increase

Reality: With the Ethereum 2.0 PoS model, there are mechanisms that can lead to a decrease in total ETH supply. For example, validators who fail to follow protocol rules can have a portion of their staked ETH slashed, effectively reducing the total supply.

Assumption 5: I can write a contract that rejects all ETH transfers

Reality: Even if a contract doesn't have any payable methods, it can still receive ETH through selfdestruct calls from other contracts, or as a block transaction fee recipient (when Ethereum introduces EIP-1559). Also, pre-computed contract deployment addresses can receive ETH before the contract is actually deployed.

By understanding the complexities and exceptions within Ethereum, developers can write safer, more robust smart contracts and DApps.

When working with Ethereum, your choice of JSON RPC provider plays a crucial role in your project's overall performance and responsiveness. This is where ZMOK comes into play.

ZMOK, like Infura, is a JSON RPC provider that supports Ethereum, with a specific focus on speed and efficiency. It is an excellent tool for developers who need a fast and reliable infrastructure for their decentralized applications (dApps). Whether you're dealing with DeFi applications that require real-time updates or a complex dApp that needs a high-performance backend, ZMOK is built to deliver.

Please note that as of now, ZMOK does not support IPFS. Nevertheless, its specialization in Ethereum and commitment to speed and reliability make it a worthy choice for your blockchain projects. It ensures that all data transmitted over its network is secure and private, providing an efficient, yet secure environment for Ethereum developers.

Check out ZMOK here and boost your Ethereum project's performance today.