Smart Contract Lifecycle & Security — Deployment, Gas & Vulnerabilities

Smart Contracts — Code That Is Law

Smart contracts power everything on Ethereum — DeFi, NFTs, DAOs, and stablecoins. But their immutability makes them uniquely unforgiving. History is littered with hacks that drained hundreds of millions because of a single overlooked line. We'll walk through deployment, gas optimization, and the most dangerous vulnerability classes, each with a practical example.

The Smart Contract Lifecycle

Every smart contract travels through a well-defined lifecycle, from source code to a permanent, running program on-chain. Understanding each stage is the foundation for writing, deploying, and maintaining contracts safely.

Deployment — Birth Of A Contract

Deployment is a special transaction with no recipient (to field empty) whose data field contains the contract's bytecode. The EVM runs the constructor, stores the code, and assigns the contract a unique address derived from the deployer's address and nonce.

// A minimal Solidity contract
pragma solidity ^0.8.20;

contract SimpleStorage {
    uint256 private value;          // state stored on-chain

    // constructor runs ONCE at deployment
    constructor(uint256 _initial) {
        value = _initial;
    }

    function set(uint256 _v) public {
        value = _v;
    }

    function get() public view returns (uint256) {
        return value;
    }
}

Gas Optimization — Writing Efficient Contracts

Every operation in a contract costs gas, and users pay that gas in real ETH. A poorly optimized contract can cost users 10× more per transaction than a lean one. Gas optimization is both a cost-saving art and, sometimes, a security concern (bloated code is harder to audit).

// BAD: two storage writes, reads storage in a loop
function sumBad() public {
    for (uint i = 0; i < items.length; i++) {
        total = total + items[i];   // SSTORE every loop! costly
    }
}

// GOOD: cache in memory, one storage write at the end
function sumGood() public {
    uint256 sum = 0;                 // memory, cheap
    uint256 len = items.length;      // cache length
    for (uint i = 0; i < len; i++) {
        sum += items[i];
    }
    total = sum;                     // single SSTORE
}

Security Best Practices — The Big Picture

Smart contract security follows a handful of guiding principles. Master these before diving into specific vulnerabilities — most real-world hacks are just violations of one of these rules.

Vulnerability 1 — Reentrancy

Reentrancy is the most infamous smart contract bug. It happens when a contract sends ETH to an external address before updating its own state. The receiving contract can "call back" into the original function repeatedly, draining funds before the balance is ever reduced. This is exactly how The DAO lost $60M in 2016.

// VULNERABLE: sends ETH before updating balance
function withdraw() public {
    uint bal = balances[msg.sender];
    (bool ok, ) = msg.sender.call{value: bal}("");  // ⚠ external call FIRST
    balances[msg.sender] = 0;                              // too late! attacker re-entered
}

// SAFE: Checks-Effects-Interactions + reentrancy guard
function withdraw() public nonReentrant {
    uint bal = balances[msg.sender];
    balances[msg.sender] = 0;                              // update state FIRST
    (bool ok, ) = msg.sender.call{value: bal}("");  // interact LAST
    require(ok, "transfer failed");
}

Vulnerability 2 — Integer Overflow & Underflow

Before Solidity 0.8, numbers could silently wrap around. Subtract 1 from a uint that is 0 and instead of an error you get the maximum possible value — a number with 78 digits. Attackers exploited this to mint themselves near-infinite tokens or bypass balance checks.

// VULNERABLE (Solidity < 0.8): silent wrap-around
function transfer(address to, uint amt) public {
    balances[msg.sender] -= amt;   // ⚠ underflows if amt > balance
    balances[to] += amt;             // could overflow too
}

// SAFE (Solidity >= 0.8): reverts automatically on overflow
// ...or use OpenZeppelin SafeMath on older versions
function transfer(address to, uint amt) public {
    require(balances[msg.sender] >= amt, "insufficient");
    balances[msg.sender] -= amt;   // safe: 0.8 reverts on underflow
    balances[to] += amt;
}

Vulnerability 3 — Front-Running

Ethereum transactions sit in a public mempool before being mined, visible to everyone. A front-running attacker watches for a profitable pending transaction, then submits their own with a higher gas tip so it gets mined first — jumping ahead to steal the opportunity. This is a huge part of what's now called MEV (Maximal Extractable Value).

Vulnerability 4 — Timestamp Dependency

Contracts sometimes use block.timestamp for randomness, deadlines, or lottery winners. But block producers can nudge the timestamp by a few seconds. Any logic that depends on a precise time — especially "random" number generation — can be manipulated by a validator to favor themselves.

// VULNERABLE: validator can bias the "random" winner
function pickWinner() public {
    uint winner = block.timestamp % players.length;  // ⚠ manipulable
    payable(players[winner]).transfer(prize);
}

// SAFE: use Chainlink VRF for tamper-proof randomness
// request randomness from the oracle, then in the callback:
function fulfillRandomWords(uint reqId, uint[] memory rand) internal {
    uint winner = rand[0] % players.length;  // verifiable, unbiased
    payable(players[winner]).transfer(prize);
}

Vulnerability 5 — Broken Access Control

Access control bugs are among the costliest of all. If a sensitive function — one that withdraws funds, mints tokens, or changes ownership — isn't properly restricted, anyone can call it. The Parity wallet disaster of 2017 froze $280M forever because a critical function lacked proper protection.

// VULNERABLE: anyone can call this and steal everything
function withdrawAll() public {          // ⚠ no restriction!
    payable(msg.sender).transfer(address(this).balance);
}

// SAFE: guard with an access-control modifier
modifier onlyOwner() {
    require(msg.sender == owner, "not authorized");
    _;
}

function withdrawAll() public onlyOwner {   // only owner passes
    payable(owner).transfer(address(this).balance);
}

Upgradeable Contracts — Fixing The Unfixable

Contracts are immutable — so how do teams fix bugs or add features? The answer is the proxy pattern. A permanent proxy contract holds all the funds and state but delegates its logic to a separate implementation contract. To upgrade, you simply point the proxy at a new implementation. The address users interact with never changes.

Golden Rules — Smart Contract Security