EVM Image  

Inside the Ethereum Virtual Machine (EVM)

The EVM uses six data locations during execution, with three dedicated to storage:

-Stack (Temporary): This follows LIFO (Last-In-First-Out) for temporary data used during transactions. It’s cleared after each execution.

-Calldata (Temporary): Holds transaction parameters and function inputs for a smart contract.

-Memory (Temporary): A temporary, indexed byte array for data manipulation during transactions (think scratchpad).

Persistent Storage:

Storage: A key-value store holding the smart contract’s state variables between transactions.
Code: Stores the contract’s code and static data as immutable strings (unchangeable).
Logs (Write-Only): Output for the Ethereum event system, stored in transaction receipts.

These above components work together to ensure the EVM’s Turing completeness.  

Application Binary Interface:
This is a json representation of a smart contract’s functions, methods, constructors and events in Ethereum. The ABI serves as an interface between the smart contract and the outside world including interfaces, clients and other contracts, allowing other softwares to know how to structure function calls and data so the the EVM can correctly execute the calls and return the correct data.
It is a crucial piece of interacting with smart contracts in Ethereum and is typically generating by the solidity compiler when the .sol file is compiled.

Example of what an ABI can look like :

    "name": "name",
    "type": "function",
    "inputs": [],
    "outputs": [{"name": "", "type": "string"}],
    "stateMutability": "view",
    "payable": false
    "name": "Transfer",
    "type": "event",
    "anonymous": false,
    "inputs": [
      {"indexed": true, "name": "from", "type": "address"},
      {"indexed": true, "name": "to", "type": "address"},
      {"indexed": true, "name": "value", "type": "uint256"}


Events: (Transparency and Record-Keeping)

Solidity events allow smart contracts to log information on the blockchain for external applications to access. This fosters transparency and record-keeping for contract actions.

Indexed Parameters: Up to three event parameters can be indexed for efficient searching and filtering by external applications.

Benefits of Events:

  • Communication: Contracts can listen for events emitted by others and react accordingly.
  • Debugging & Auditing: Events offer insights into contract behavior and a permanent record of actions for security purposes.
  • User Interfaces & Notifications: DApps can update interfaces, and external services can trigger notifications based on events.
  • Trade-off: Emitting events consumes gas, so use them judiciously to balance benefits with cost.