SMART CONTRACTS, DEFI & WEB3 SECURITY - Chapter 2, Exercise 3 Solution ========================================================== Why "Finish Within 10 Seconds" Doesn't Solve What Gas Solves PROBLEM ------- Explain, using this chapter's own halting-problem reasoning, why Ethereum couldn't simply say "every contract function must finish within 10 seconds" as an alternative to gas — what real problem would that alternative rule fail to solve? SOLUTION -------- A fixed real-time limit like "10 seconds" sounds like it would also guarantee execution eventually stops, and in one narrow sense it would - but it fails to solve the two real, distinct problems this chapter says gas is actually designed to address together. First, a real-time limit says nothing about fairly charging for the actual computational effort different operations require. Two different contract calls might both finish comfortably within 10 seconds, but one might perform vastly more actual computational work than the other on a given node (a simple addition versus, say, a computation-heavy loop across many stored values). A flat time limit doesn't distinguish between light and heavy real work at all - it only cares about elapsed time, not the genuine cost imposed on every node that has to independently re-execute the same operation, which is exactly the fairness problem gas is built to solve. Second, and just as important, different real machines run at different real speeds. A powerful, modern node might comfortably finish a given contract call well inside 10 seconds, while an underpowered node struggles to finish the exact same, deterministic operation in that same window. Since Course 2 Chapter 2 (and Course 1's own chapters on consensus) require every node to reach an identical result from identical input, a rule based on real-world elapsed time would make the network's own behavior depend on whose hardware happens to be running it - directly breaking the deterministic, "same input, same output, on any machine" property this chapter says the EVM formally guarantees. Gas avoids both of these problems at once: it counts real, deterministic units of computational work (via opcode costs) rather than real-world elapsed time, so every node performs and is charged for the identical amount of "gas work" regardless of how fast its own hardware happens to run, while still guaranteeing execution provably halts once the purchased gas is exhausted. ANSWER: A fixed time limit would technically guarantee execution stops eventually, but it wouldn't fairly measure or charge for the real computational effort different operations actually require, and it would make results depend on which node's hardware speed happened to be running the code - breaking the deterministic, same-input-same- output guarantee the EVM is specifically designed to provide. Gas solves both problems together by counting deterministic units of work rather than real-world elapsed time. ---- WHY THIS WORKS AS AN ANSWER This identifies two separate real failures of the proposed alternative (no fairness in charging for actual work, and a break in determinism across different hardware) rather than only restating that gas "solves the halting problem," which the proposed 10-second rule would also nominally do - the deeper point is that gas solves more than just the halting problem alone.