Questions: Contract Verification (Blockchain)

Question 1

The 'reentrancy bug' in the DAO contract (2016) allowed an attacker to withdraw funds repeatedly. In pseudo-code: function withdraw(amount) { if (balance[msg.sender] >= amount) { call(msg.sender).send(amount); balance[msg.sender] -= amount; } }. Why is this vulnerable?

Model answer: The contract sends funds (call.send) BEFORE updating the balance. The call to an attacker's contract can recursively call withdraw again. Since balance hasn't been decremented yet, the condition (balance >= amount) is still true, and the attacker withdraws again. This loop repeats until all funds are drained. This is a classic ordering bug: the contract should decrement the balance before making the external call (checks-effects-interactions pattern). Formal verification can prove this property: 'before any external call that might reach user code, the contract has established an invariant (like updated balance) that protects against recursion.'

Reentrancy is a high-level, logical error difficult for traditional testing to catch because it requires knowing that an external call might recursively invoke the contract. Formal methods address this by reasoning about contract semantics: when you call external code, that code can call back into your contract. Static analysis can detect reentrancy patterns; deductive verification can prove a contract is free of reentrancy by establishing an invariant that prevents loops. The DAO attack cost $50M and led to an Ethereum hard fork, motivating intense focus on contract verification.

Question 2

A formal specification for a smart contract token might state: 'the total supply of tokens is immutable — the sum of all balances equals the initial supply.' How would you formally verify this invariant?

Model answer: You would prove a loop invariant: before and after every state-changing operation (mint, burn, transfer), the invariant (sum of balances = total supply) remains true. For each operation, you show: if the invariant holds before the operation, it holds afterward. For example, in 'transfer(from, to, amount)', the operation decrements balance[from] by amount and increments balance[to] by amount — the net change to the sum is zero, so the invariant is preserved. Induction proves that if the invariant holds initially (at contract deployment), it holds after any sequence of operations. This is a formal proof of a critical property.

Loop invariants are the key to reasoning about mutable state in contracts. Each operation is a loop iteration; the invariant must hold before and after. Automated tools like Certora use SMT solvers to discharge these proof obligations. If an operation violates the invariant, the SMT solver finds a counterexample — a sequence of operations that breaks the property. This same technique is used in program verification (Hoare logic) but applied to blockchain contracts where the stakes are extraordinarily high.

Question 3

Contracts interact with other contracts through external calls. If contract A calls contract B, and B calls back to A, how does formal verification ensure no reentrancy occurs?

• A. Reentrancy is impossible on blockchains, so no verification is needed
• B. Verification establishes an invariant (e.g., a lock or state flag) that prevents recursion. Before calling external code, the contract sets a state flag (locked = true). External calls cannot reenter because the flag prevents re-execution of the critical section. The proof shows that the lock is always set before external calls and released after
• C. Verification randomly tests the contract with concurrent calls
• D. Reentrancy must be prevented by manually auditing code

Answer: (B)

The contracts-locking pattern prevents reentrancy by establishing a mutex-like invariant: a critical section (funds transfer) can only execute if a state flag (locked) is false. Before the critical section, lock(); after, unlock(). Formal verification proves that the lock is always held during the critical section, preventing concurrent/reentrant execution. This is analogous to mutex verification in concurrent programs but applied to blockchain contracts. Tools like Certora verify this automatically.

Question 4

Many contract verification efforts focus on 'functional correctness' (the contract does what it's supposed to do) but overlook 'economic properties' (incentives are sound). Why is verifying economic properties harder?

Model answer: Functional correctness is about program behavior: does the contract execute the right operations? Economic properties are about incentives: does the contract's reward structure incentivize honest behavior? Proving economic properties requires reasoning about agents' decisions under game-theoretic incentives, which is not purely a program verification problem. Example: an exchange contract is functionally correct (trades execute as specified) but economically broken (front-running attacks are profitable). Verifying economic properties requires modeling agents, incentives, and adversarial strategies — far beyond traditional software verification.

This is an open research problem. Functional verification can be automated (SMT solvers, theorem provers); economic verification requires understanding rational agents and game theory. Some projects (like Formal Verification Research) are developing frameworks for specifying and verifying economic properties, but this is nascent. The insight is that even a formally verified contract can be economically broken, leading to unintended but predictable attacks.