Smart contract Study Guide

📖 Core Concepts Smart contract: a self‑executing computer program or transaction protocol that enforces contract terms automatically. Primary objectives: eliminate trusted intermediaries, cut arbitration costs, lower fraud losses, and reduce accidental or malicious exceptions. Deployment: a compiled contract is sent in a signed transaction to a special address; once the transaction is mined, the code becomes immutable. State & computation: contracts can store arbitrary data (state) and run any computation allowed by the blockchain VM. Determinism: every node must obtain the same result from the same transaction to preserve Byzantine fault tolerance. Legal status: generally not a legally binding agreement; only “smart legal contracts” meet enforceability requirements. Programming languages: most Ethereum contracts use Solidity (Turing‑complete); alternatives (Vyper, Simplicity, Scilla, Bitcoin Script) avoid Turing completeness to improve safety. --- 📌 Must Remember Immutability – after a contract is included in a block, its code cannot be changed. Visibility – all transaction data and contract code are public on the blockchain. Turing completeness ≈ higher risk (halting problem, unbounded loops). Smart legal contract ≠ smart contract; the former must satisfy all legal elements of enforceability. Deterministic execution is mandatory for consensus; randomness must be injected via secure off‑chain sources. --- 🔄 Key Processes Deploying a contract Write code → compile to bytecode → sign transaction → send from wallet to a new contract address → miner includes transaction in a block → contract’s initial state is set, code becomes immutable. Interacting with a contract User sends a transaction → EVM (or other VM) executes the called function → state may change or tokens are transferred → transaction receipt is recorded on‑chain. Formal verification (high‑level) Write contract → specify safety properties → run static analysis or theorem prover → prove properties before deployment (required because bugs are permanent). --- 🔍 Key Comparisons Smart contract vs. Smart legal contract Smart contract: code + data; may automate execution but lacks legal enforceability. Smart legal contract: full legal contract whose terms are also expressed in code; enforceable in court. Solidity (Turing‑complete) vs. Non‑Turing‑complete languages Solidity: expressive, but vulnerable to infinite loops, halting‑problem issues. Vyper / Simplicity / Bitcoin Script: limited expressiveness, designed to prevent unsafe constructs. --- ⚠️ Common Misunderstandings “Smart contracts are legally binding.” → Only smart legal contracts meet that standard. “Once deployed, a contract can be patched.” → Immutability means bugs remain unless a new contract is deployed and users migrate. “Deterministic code cannot use randomness.” → It can, but randomness must be sourced off‑chain (e.g., VRF) and fed in securely. --- 🧠 Mental Models / Intuition “Code as escrow” – think of a smart contract as an automated escrow agent that only releases assets when predefined conditions (encoded in code) are met. “Immutable ledger = permanent warranty” – once a contract lives on the blockchain, it’s a permanent warranty of its behavior—good if correct, disastrous if buggy. --- 🚩 Exceptions & Edge Cases Hard forks: In extreme attacks (e.g., DAO hack), a community may create a hard fork to roll back state, but this breaks immutability guarantees. Gas limits: Excessive computation can cause out‑of‑gas errors, aborting execution even if logic is correct. Integer overflow/underflow: Pre‑Solidity 0.8 contracts need explicit checks; later versions include built‑in safety. --- 📍 When to Use Which Choose Solidity when you need full expressiveness and are comfortable with rigorous testing/verification. Choose a non‑Turing‑complete language for high‑value, safety‑critical contracts (e.g., financial primitives) to reduce attack surface. Use a smart legal contract only when the agreement must be enforceable in court and you can map every legal term to code. --- 👀 Patterns to Recognize Reentrancy pattern: external call → state change after call → vulnerable to recursive re‑entry (e.g., DAO attack). Unchecked arithmetic: look for +, -, without SafeMath or compiler version ≥0.8. Missing access control: functions lacking onlyOwner or similar modifiers often lead to privilege escalation. --- 🗂️ Exam Traps “All smart contracts are legally enforceable.” – distractor; only smart legal contracts qualify. “Immutability can be overridden by the contract owner.” – false; only a hard fork can alter history. “Deterministic execution means no randomness is possible.” – misleading; randomness can be imported securely from off‑chain sources. “Using Solidity guarantees safety because it’s the official language.” – incorrect; Solidity’s Turing completeness introduces classic programming hazards.