Ethereum is often introduced with a list of things built on it, which is a bit like explaining a city by naming its restaurants. A more useful starting point is to ask what problem the network solves at all. Ethereum is a shared computer that many people operate together, where the state of every account and every contract is public, and where any change to that state has to be agreed on by the whole network before it sticks. If you write code that runs there, you are not calling an API that quietly updates a row; you are proposing a transition that thousands of independent machines will re-execute and either accept or reject.
That single design decision explains nearly everything else, including the odd parts that confuse first-timers. This orientation is aimed at the practical questions: what the network actually stores, what patterns developers keep reaching for, and what to learn about the connection layer before you build something you depend on. If you have never sent a request to a chain, treat this as a map of the terrain, not a tutorial on syntax.
Accounts, not files
The mental model that breaks most often is assuming there is a database you can query and edit. Ethereum has no tables. It has accounts, each with an address, a balance in ether, and optionally some code and storage. Two kinds exist: externally owned accounts, which are controlled by a private key and can initiate transactions, and contract accounts, which hold code and react to messages sent to them. A wallet is not a place coins live; it is a key that proves authority over an address.
State is the sum of every account and its storage at a given moment. Nobody hands you that state directly. Nodes keep it, and they agree on each new version of it block by block. This is why you will hear talk about historical state: reading a balance from a block from two years ago is a different request from reading the current one, and not every node keeps the older layers.
What execution looks like from above
When you send a transaction, several things happen in order. It arrives at a node, gets gossiped to the network, and eventually lands in a block. Every node that validates the block runs the same computation, with the same inputs, and should arrive at the same result. If your contract loops forever or runs out of gas, the execution reverts and the state change never happens. Gas is the meter that makes this bounded: you pay for computation because every node repeats it.
The execution environment is the Ethereum Virtual Machine. Contracts are compiled to bytecode that the EVM runs deterministically. Deterministic matters here. A contract cannot call a weather API or read a random number from the operating system, because different nodes would disagree about the answer. Anything that enters the computation from outside has to arrive as a transaction, signed and ordered like the others.
One consequence that trips up newcomers: reading is free, writing is not. A view function call is a local question you ask a node; a state-changing call is a transaction that costs gas and needs a signature. Knowing which of the two you are doing is half of debugging a first app.
Patterns you will meet constantly
Three patterns show up in almost every beginner-facing project. The first is a token contract, which is really just a mapping from addresses to balances exposed through standard functions. It is a spreadsheet anyone can read and only the holder can move. The second is an approval flow, where you let a contract spend on your behalf up to a limit. This exists because a transaction can only carry one signature, so interacting with a protocol usually means two steps. The third is an event log, where a contract records that something happened. Events are cheap for contracts to write and are how off-chain software notices that a swap occurred or a transfer settled.
Events are also where a lot of uncertainty lives for beginners. An event is not a message to your server; it is a log entry attached to a block. Your app learns about it by asking a node for logs in a block range or by subscribing to new ones. That is a polling or subscription design question, and it shapes your whole backend.
Where your code actually plugs in
Directly talking to Ethereum peers is possible but painful: discovery, handshakes, encoding, and reorg handling all become your problem. Nearly everyone instead speaks JSON-RPC to a node that is already connected to the network. The API is small and mostly mechanical. You send a method name and parameters, and you get JSON back.
A few calls carry most of the weight. eth_blockNumber tells you the latest height and is a useful liveness check. eth_getBalance and eth_call read state. eth_sendRawTransaction broadcasts a signed transaction, meaning your application handles key management and signing. eth_getLogs retrieves events, and eth_subscribe over a WebSocket gives you a push-style feed of new blocks or logs instead of constant polling.
The caveats matter more than the calls. Rate limits on shared endpoints are real; a public endpoint that answers a health check will not necessarily survive a log query over a million blocks. Archive access is the difference between reading present state and tracing what happened months ago, and it is not universally available. Trace and debug methods expose the internal steps of contract execution, which is invaluable when a transaction fails and the error message says nothing useful, but those methods are heavy and often sit behind higher access tiers. Dedicated infrastructure, such as OnFinality's Ethereum endpoints, is the standard answer when shared limits start shaping your product design.
Two more practical notes. Chain ID is worth hard-coding and checking; Ethereum Mainnet is chain ID 1, and testnets use different values, so a mismatch is a common cause of confusing failures. Finality is not instant either. A block can be replaced during a shallow reorg, so anything that credits value should wait a few confirmations before treating it as settled.
A balanced place to start
Ethereum is not the fastest place to put data, and it is not free to write to. It is a network built for shared state that multiple parties can trust without a referee, and that trade-off costs computation and coordination. Start with small reads, a testnet transaction you can watch confirm, and a clear picture of which parts of your app are reads, which are writes, and which depend on logs. Once those boundaries are visible, the RPC layer stops feeling like plumbing and starts reading like the interface it is.
Useful Resources:
• eth_getLogs
Useful Resources: