Lecture Flashcards: Smart Contract Security and Fully Homomorphic Encryption

Technical Logistics and Presentation Setup

• Connection and Transfer Challenges: The session begins with technical difficulties regarding the connection of a Windows computer to the presentation system.

• Transfer Methods Considered:

  • Switching off the system.

  • Emailing the presentation to a connected university computer.

  • Using Bluetooth to transfer files between the two Windows laptops, provided they are on the same network (University network).

  • Logging into Canvas via the connected laptop to retrieve the file.

• File Requirements: The file mentioned is an HTML file, though the Canvas submission requirement typically asks for a PDF format. The presenter successfully uploads the file to Canvas to initiate the assignment.

Introduction to Cybersecurity in Blockchain and Web 3.0

• Speaker: Sameer Jani.

• Topic: Security analysis of smart contract vulnerabilities in Ethereum-based systems.

• Economic Context: As of $2025$, approximately $\$3,350,000,000$ have been stolen from the crypto market, specifically from smart contracts. This involved around $150$ crypto hacks just in the year $2025$.

• Historical Precedent: The era of significant exploits began in June $2016$ with a specific attack where $\$60,000,000$ were stolen in only $3.5$ hours.

• Evolution of the Web:

  • Web 1.0 (1990s): Defined by static pages where users could only read information stored on a server.

  • Web 2.0: The current standard (e.g., Google, Meta) which allows users to read and write content.

  • Web 3.0: A paradigm shift allowing users to read, write, and own. Users hold their own private keys. Ownership of identity, money, and state is governed by code. Everything in Web 3.0 is publicly available to all users.

Technical Foundations of Blockchain Technology

• Definition: A blockchain is a distributed, decentralized, and tamper-resistant ledger used to perform transactions.

• Public Nature: Every transaction is public, showing the receiver’s address, the source address, and the amount (e.g., $1$ Ethereum) sent.

• Block Structure: Blocks are linked by cryptographic hashes. Each block contains:

  • A unique hash.

  • The previous block’s hash.

  • A transaction root.

• Node Validation: If a new block’s hash does not match the previous block’s hash, that block or node is rejected by the blockchain.

• Immutability: Blockchain uses append-only history. Previous blocks cannot be changed; data can only be added in the future.

Transaction Lifecycle and Finality

1. Signing: A user signs a transaction with their private key using a wallet (e.g., MetaMask). The transaction includes the recipient address, value, gas limit, and calldata.

2. Broadcast: Once sent, the transaction is broadcast to every node in the blockchain.

3. Validation: Validators check the signatures, transaction noise, user balance, and gas limit. They may drop the transaction if requirements are unmet.

4. Inclusion: A validator creates a new block containing the transaction.

5. Finality: The transaction reaches finality. Its effects on the contract state are permanent; there is no roll-back or revert button.

Core Components of the Ethereum Virtual Machine (EVM)

• Accounts:

  • Externally Owned Accounts (EOA): Controlled by a user via a private key (e.g., a standard MetaMask account).

  • Contract Accounts: Controlled by code. These accounts can hold cryptocurrencies and execute transactions based on program logic.

• Wallets: Software that stores private keys and signs transactions on a user’s behalf.

• Gas: A fee paid for the computational work required to process a transaction.

• EVM (Ethereum Virtual Machine): A deterministic, stack-based runtime environment. When a transaction is made, code is converted into bytecode, which the EVM executes to process the transaction on the chain.

• DApps (Decentralized Applications): Applications with a traditional web front end but a backend logic that is completely decentralized and on-chain.

Smart Contract Foundations and Lifecycle

• Definition: A smart contract is deterministic bytecode (simple program logic) residing on the EVM that runs when triggered by a transaction. They cannot run independently.

• Capabilities: Can hold assets like Ethereum or facilitate the creation of NFTs.

• Solidity: The primary language used to write smart contracts.

• Lifecycle:

  • Coding: Writing in Solidity or another preferred language.

  • Compilation: Converting code into EVM bytecode.

  • Deployment: The contract is assigned a permanent $20$-byte address. Once deployed, the contract is live, public, and immutable.

  • Execution: Anyone can call the function, but every call costs gas.

• Unique Constraints:

  • No Patch Cycle: Bugs cannot be patched; they stay live forever.

  • Public Open Source: Attackers can read the code as easily as any user.

  • High Stakes: Errors lead directly to financial loss or data leaks.

  • Mantra: In Web 2.0, you "ship and patch"; in Web 3.0, you "ship and pray."

Analysis of Vulnerability Classes (OWASP Top 10)

1. Access Control

• Issue: Sensitive functions lack proper authorization checks.

• Exploit: Unauthorized users may mint tokens, transfer funds, or take ownership.

• Example Code: A vault with a public setOwner function allows anyone to become the owner and withdraw the balance.

• Mitigation: Use open-source libraries like OpenJaplin. Implement the onlyOwner modifier to ensure only the deployer can call the function.

2. Price Oracle Manipulation

• Definition of Oracle: An entity (e.g., Chainlink) that integrates real-world data (like the price of USDT) into the blockchain.

• Vulnerability: Relying on a single source or a single autonomous market maker. Attackers can move the source pool price using a flash loan, lying to the protocol about collateral value.

• Example Code: A getPrice function relying on a single calculation of getReserves ($r0, r1$).

• Mitigation: Use Chainlink modules to fetch data from the latestRoundData, which checks timestamps and historical averages (e.g., over a $1$-hour window) to prevent manipulation via sudden price spikes.

3. Reentrancy

• Mechanism: An external call is made before a contract updates its state.

• Exploit: An attacker calls a withdrawal function repeatedly. Because the balance is only updated after the funds are sent, the attacker can drain the contract until the balance is zero before the first call ever finishes updating the state.

• Mitigation: Use the "Checks-Effects-Interactions" pattern. First, check the balance; second, update the internal state (the effect); third, perform the external transfer (the interaction).

4. Flash Loan Attacks

• Definition: Loans that allow borrowing uncollateralized funds provided they are repaid within the exact same transaction.

• Impact: Attackers use the borrowed capital (e.g., $100,000,000$) to amplify other bugs, such as manipulating governance votes or liquidity pools.

• Code Vulnerability: Governance votes where someone takes a loan, votes, and repays in one transaction.

• Mitigation: Update and check balances before allowing subsequent actions.

Case Study: The 2016 DAO Exploit

• Context: The DAO (Decentralized Autonomous Organization) was a leaderless investment fund created in $2016$. It held approximately $\$150,000,000$ in Ethereum.

• The Incident: On June 17, $2016$, a reentrancy exploit drained $3,600,000$ Ethereum from the fund.

• Outcome: The event challenged the philosophical idea of immutability. To recover funds, the community performed a hard fork, splitting Ethereum into:

  • ETH: The current live chain.

  • ETC (Ethereum Classic): The original chain that did not implement the roll-back.

• Developer Impact: Led to the widespread adoption of specific security libraries (Open Jaaplin) and the "Checks-Effects-Interactions" standard.

Session 1: Questions & Discussion

• Question: In flash loans with no collateral, what happens if something goes wrong and the payer cannot pay back the loan?

• Response: Because it is a single-transaction process, if any part of the execution fails or the loan cannot be repaid, the entire transaction is reverted. The funds are automatically sent back to the original source. The only cost incurred is the gas fee, which may be substantial (e.g., $10$k or $20$k depending on the coin and amount borrowed, like $\$100,000,000$).

Introduction to Fully Homomorphic Encryption (FHE)

• Speaker: Florence Shi.

• Concept: An encryption scheme that allows operations to be performed on data while it is still in its encrypted form.

• Rationale: To preserve privacy while outsourcing data storage or processing to untrusted third parties (e.g., cloud computing, healthcare analysis). Data can be processed without the server ever knowing the contents.

• History: Originally called "privacy homomorphism," introduced shortly after RSA.

Classification and Standards of Homomorphic Encryption

• Partially Homomorphic Encryption (PHE): Supports only one type of operation (addition OR multiplication) on ciphertext. Examples include RSA and ElGamal (both support multiplication).

• Somewhat Homomorphic Encryption (SHE): Supports both addition and multiplication, but only for a finite/subset of operations. Ciphertexts become "noisy" and eventually cannot be decrypted or evaluated correctly.

• Fully Homomorphic Encryption (FHE): Supports two or more types of operations (addition and multiplication) for an unbounded number of operations. This allows for the construction of all types of logic gates.

Technical Evolution of FHE Schemas (2009–present)

• 2009 (Gentry): First plausible FHE scheme using ideal lattice-based cryptography. While revolutionary, bootstrapping (a noise-reduction step) took $30$ minutes, making it impractical for immediate use.

• 2010 (DGHV): Additional integer-based scheme; however, it has seen few updates.

• Later Schemes: Focus shifted to the "Learning with Errors" (LWE) framework.

  • BGV and BFB: Based on LWE.

  • GSW: Optimized by removing the re-linearization step, leading to slower noise buildup.

  • CKKS: An LWE-based scheme that preserves the precision of encrypted floating-point numbers.

Mathematical Construction of Gentry’s 2009 Scheme

Florence Shi explains a simplified version of Gentry's somewhat homomorphic construction:

• Key Generation (KeyGen): A random $p$ bit, all-numbered, all-integer $p$ (an odd number).

• Encryption (Encrypt): To encrypt a bit $m$:

  • Set a noise value $m'$ to be a random $n$ bit number such that $m' ≡ m \text{ mod } 2$.

  • The parity must match (if $m$ is odd, $m'$ is odd; if $m$ is even, $m'$ is even).

• Decryption (Decrypt): Output is calculated as $c \text{ mod } p \text{ mod } 2$.

• The Noise Problem: Addition and multiplication increase the noise $m'$. Eventually, the ciphertext becomes undecipherable, limited to SHE standards.

The Mechanism of Bootstrapping and Noise Reduction

• Definition: A periodic process to reduce noise and allow for unbounded operations.

• The Logic: If decryption reduces noise, we must perform a decryption without the server learning the secret key.

• The Analogy: Imagine a locked box with gloves inside. You can manipulate the items but cannot see or take them. You place the old locked box inside a new locked box. Inside the new box, you also place the key to the old box. Using the gloves, you use the internal key to unlock the old box within the new box, resulting in a "refreshed" ciphertext.

• Recrypt Algorithm:

  1. Generate a new ciphertext $c_1$ using a new public key ($PK2$).

  2. Encapsulate the old secret key ($SK1$) by encrypting it under the new public key.

  3. Evaluate the decryption circuit homomorphically to refresh the data.

• Circular Security: The assumption that an algorithm is secure even if the encrypted version of the secret key is known. It is difficult to prove but necessary for using a single pair of keys.