1. Design Philosophy of Solidity

Solidity is a statically typed, contract-oriented programming language whose semantics are tightly bound to the EVM. The language is intentionally restrictive, emphasising:

• Deterministic execution: No non-deterministic system calls.
• Low-level bytecode alignment: Language constructs correspond to VM operations.
• Predictable gas consumption: Explicit handling of state writes, loops, and dynamic structures.
• Security-first patterns: Explicit visibility, modifiers, re-entrancy mitigation.

Solidity is designed not as a general-purpose language but as a domain-specific language for writing deterministic state machines on a replicated execution environment.

2. Basic Structure of a Solidity Contract

A minimal Solidity contract has:

• A version pragma
• Optional imports
• State variables
• Constructor
• Functions with explicit visibility
• Events
• Error types or require/ revert statements

// Example structure (illustrative)

pragma solidity ^0.8.0;

contract Example {
    uint256 public value;

    constructor(uint256 _v) {
        value = _v;
    }

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

Solidity enforces explicitness: every function must declare its visibility and mutability constraints (pure/view/payable).

3. Data Types and Memory Model

Understanding Solidity’s data types is crucial because they directly map to EVM data structures.

3.1 Value Types

• uint/int: 8–256-bit integers
• bool
• address
• bytes1–bytes32
• enum

3.2 Reference Types

• arrays (fixed or dynamic)
• structs
• mappings (hash-based associative arrays)

3.3 Memory vs Storage vs Calldata

Solidity has three distinct memory regions:

• storage: persistent, expensive, on-chain key-value store
• memory: temporary, cleared after function execution
• calldata: read-only arguments passed into external functions

Misunderstanding these distinctions is a common source of security bugs and gas inefficiency.

4. Functions, Visibility, Mutability & Modifiers

4.1 Function Visibility

• public – callable internally and externally
• external – callable only from outside
• internal – callable only within contract or inherited contracts
• private – callable only within contract

4.2 Mutability Keywords

• pure: no state access
• view: reads but does not write state
• payable: receives Ether
• non-payable: default state-changing function

4.3 Modifiers

Modifiers allow execution pre-conditions:

modifier onlyOwner() {
    require(msg.sender == owner, "Not owner");
    _;
}

function changeOwner(address newOwner) public onlyOwner {
    owner = newOwner;
}
    

The _; keyword represents the insertion point for the modified function’s body.

5. Ether Transfers & Payable Semantics

Solidity provides three main mechanisms for transferring Ether:

• transfer() – fixed 2300 gas stipend, reverts on failure
• send() – returns boolean instead of reverting
• call{value: x}("") – recommended, forwards all available gas

5.1 The receive() and fallback() Functions

Contracts can react to plain Ether transfers using:

receive() external payable {
    // triggered when msg.data is empty
}

fallback() external payable {
    // triggered when no function matches msg.data
}
    

These functions are essential for wallet-like contracts or payment-handling logic.

6. Events and Logging

Events allow smart contracts to emit logs that off-chain systems can efficiently index and query. Events do not modify contract state but form the backbone of DApp UI synchronisation.

event Deposit(address indexed user, uint256 amount);

function deposit() public payable {
    emit Deposit(msg.sender, msg.value);
}
    

Indexed parameters appear in log topics, enabling efficient filtering by analytics tools.

7. Error Handling & Defensive Programming

Solidity supports structured error handling, essential for safe execution:

• require() – for validating inputs and external conditions
• revert() – for returning custom error messages
• assert() – used to validate internal invariants

require(balance >= amount, "Insufficient balance");
revert("Manual failure");
assert(x + y >= x);
    

With Solidity 0.8+, arithmetic overflow is checked automatically.

8. Inheritance, Interfaces & Polymorphism

Solidity supports single and multiple inheritance, enabling reusable logic between contracts.

8.1 Basic Inheritance

contract A {
    function foo() public pure returns (uint256) {
        return 1;
    }
}

contract B is A {
    function bar() public pure returns (uint256) {
        return foo() + 1;
    }
}
    

8.2 Interfaces

Interfaces declare function signatures without implementation:

interface IERC20 {
    function transfer(address to, uint256 amount) external returns (bool);
}
    

Interfaces enforce cross-contract communication in a predictable format.

9. ABI Encoding, Function Selectors & Data Layout

External function calls use the Ethereum ABI (Application Binary Interface) to encode:

• Function selector – first 4 bytes of keccak256(function signature)
• Arguments – tightly packed 32-byte words

Example:

transfer(address,uint256)
→ keccak256(...) → first 4 bytes = selector
    

Understanding ABI encoding is essential for:

• Interacting with contracts via low-level call
• Building cross-language tooling
• Debugging transaction input data

10. Storage Layout & Compiler Behaviour

Each state variable is assigned a storage slot. Variables may be packed to reduce gas usage. For example:

uint128 a;
uint128 b;  // packed into same slot as 'a'
    

Complex structures like mappings and dynamic arrays require hashed keys to derive storage positions.

10.1 Mappings

mapping(address => uint256) balances;
    

Storage slot = keccak256(key . slot)

10.2 Dynamic Arrays

Arrays store length at the base slot; elements are stored in contiguous slots starting at:

keccak256(slot)

11. Common Solidity Patterns

Solidity development has converged around a set of widely used design patterns:

11.1 Ownable Pattern

Used for access control.

11.2 Pausable Pattern

Allows emergency shutdown of functionality.

11.3 Checks-Effects-Interactions

A defensive pattern to prevent re-entrancy.

11.4 Pull Payment Pattern

Instead of sending funds automatically, allow users to withdraw — prevents gas issues and re-entrancy.

11.5 Upgradeable Proxy Pattern

Contracts cannot be modified directly after deployment. Upgradeable patterns use proxy contracts with delegatecall to enable logic upgrades.

12. Compilation Pipeline, Bytecode & Deployment Process

The Solidity compiler solc produces:

• Bytecode: Executed by the EVM
• ABI JSON: Defines external interface
• Metadata: Compiler version, settings, source hashes

Deployment occurs via a special “creation transaction” whose input data is:

• Contract creation bytecode
• Constructor ABI-encoded arguments

After deployment, only the runtime bytecode remains on-chain.

13. Security Considerations and Audit Priorities

Safe Solidity development requires vigilance. Key risks include:

• Re-entrancy vulnerabilities
• Unchecked external calls
• Arithmetic assumptions (despite built-in checks)
• Incorrect event indexing
• Improperly initialised storage
• Upgradeability misconfiguration

Best practices include:

• Use libraries from reputable sources
• Minimise state writes
• Perform differential testing
• Use static analysis tools
• Conduct external audits

14. Module Summary

This module presented a rigorous technical treatment of Solidity’s syntax, semantics, memory model, ABI encoding, visibility rules, Ether flows, events, error handling, inheritance, and common programming patterns. These foundations prepare the learner for Module 3, which transitions into applied development — designing, building, and testing practical smart contracts and fully functional decentralised applications.