A Napkin Architecture of Ethereum Interfaces for Developers

What does Ethereum infrastructure look like if you remove the blockchain? A look at a simplified architecture of the Ethereum network for a technical reader.

Implementations are shown in blue, interfaces purple.

Browser Provider: (EIP-1193) This JavaScript API specifies how browser applications and Chrome-extension wallets operate. Essentially a thin client that implements the JSON-RPC specification. It also provides event-based handlers for user actions (changing a network, account, or sending a transaction).

Sign Data: (EIP-191) Allows users to sign arbitrary messages with their private key. Signing data happens outside the context of a blockchain – messages may be transactions, but they also may be any data. So if you were to build an identity provider, e.g., Sign-in With Ethereum, you'd sign some message here.

JSON-RPC: A JSON-based RPC (remote procedure call) API. Usually implemented over HTTP/S or WebSockets, but also easy to implement over IPC or stdio. RPC-aaS providers like Alchemy and Infura implement this for high-traffic applications like Metamask. Nodes also implement this interface. There are currently 44 different methods implemented in the eth_ namespace (there's also net, clique, les for p2p) ranging from read-only data eth_getBlockByNumber to mutating calls like eth_sendTransaction. The EVM is also directly exposed with eth_call.

{
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": [
        "0x9b1d35635cc34752ca54713bb99d38614f63c955",
        "latest"
    ],
    "id": 2
}

P2P protocols: Protocols for how nodes communicate, including discovery, wire protocols, snapshotting, and different flavors of nodes.

EVM ABI: The application binary interface for working with the EVM. This ABI specifies how bytecode is passed to the EVM – either creating new smart contracts or calling existing ones with arguments. The specifics of how it works are esoteric. Still, implementations at the top of the stack (i.e., browser providers) often need to implement the ABI to translate a user's contract arguments to a format understandable by the EVM.

NFTs, Tokens, and other well-known interfaces: These are specifications of well-known smart contracts. There's EIP-20 which specifies standard interface methods for token contracts, and EIP-721 for NFTs. If the source isn't available for a smart contract, it can be decompiled, and the ABI can be reconstructed, but these standards provide better interfaces than bytecode for users to interact with. Companies like OpenSea and Dune Analytics rely on these interfaces.

function balanceOf(address _owner) public view returns (uint256 balance)

function transfer(address _to, uint256 _value) public returns (bool success)

function totalSupply() public view returns (uint256)

EVM: The Ethereum virtual machine that executes smart contract bytecode. Input is passed via the ABI. The EVM is mostly a self-contained virtual machine. There are currently 144 different operations, ranging from low level XOR, EQ, NOT to high-level SELFBALANCE to numerous stack operations PUSH1, PUSH2, PUSH3, etc. However, EVM requires a storage interface to access accounts and balances.