A smart contract is a program that runs on the Ethereum blockchain. It combines code and data at a particular Ethereum address. The code defines functions; the data is called the contract’s state. Those three elements—code, state, and address—give a concrete answer to the question “what is a smart contract?”
To understand how someone interacts with one, add a fourth element: a call to a defined function through a transaction. This guide explains that relationship, the distinction between user-controlled and code-controlled accounts, and why information from outside Ethereum needs a separate supply mechanism.
Code, state, and address: the basic structure
The Ethereum introduction to smart contracts describes a contract as a collection of functions and state at a specific address. Each part answers a different question:
- Code: What functions does the program define?
- State: What data belongs to the contract?
- Address: Which contract is being discussed?
State is a technical word for data. For example, in an invented classroom contract, a variable named counter could be part of its state. The name tells us what the example calls that variable; it does not tell us its starting value or what operations affect it.
Functions belong to the code side of the explanation. A function’s name can help someone discuss it, but the name alone does not establish its behavior. Understanding a specific contract requires information about the particular functions and data involved.
A useful deduction follows from this structure: an address identifies the contract under discussion, while its functions and state explain different aspects of that contract. Merely supplying an address leaves the behavior unexplained. This is a reading principle derived from the definition, rather than a separate guarantee about any address.
How control differs between account types
The Ethereum accounts documentation distinguishes an externally owned account, or EOA, from a contract account. An EOA is controlled by whoever holds its private keys. A contract account is controlled by its smart contract code.
Keep the subject of each statement clear. The EOA description identifies a private-key control model. The contract-account description identifies code as the controlling logic. Neither statement, by itself, evaluates the security of a particular account or program.
Code control also needs careful wording. It does not mean people cannot interact with a contract. User interaction and contract control answer different questions: who is making a request, and what program governs the contract’s behavior?
When reading an explanation, try replacing a vague reference to “the account” with either “the sending EOA” or “the contract account,” where appropriate. That small editorial habit makes it easier to follow which participant is being described without assuming that every Ethereum account operates identically.
What invoking a contract function means
User accounts can interact with smart contracts by submitting transactions that invoke functions defined by those contracts. At this conceptual level, the important relationship is between a user account, a particular contract, and a function that the contract defines.
Consider three questions when reading an interaction description:
- Which user account is making the request?
- Which contract address is the request directed to?
- Which defined function is being invoked?
These questions describe the interaction mechanism. They do not establish successful execution or a particular resulting state. A statement that someone submitted a transaction should therefore remain a statement about submission unless the explanation supplies evidence for a stronger conclusion.
Transaction sequencing is a separate topic. If that terminology appears in further reading, our guide to the Ethereum account nonce and transaction sequence provides the relevant background. Here, the focus remains on invoking a contract’s defined functions.
A hypothetical counter contract
Imagine an invented contract used only for a classroom reading exercise. Stipulate that it has a state variable named counter and a function named recordVisit. These names describe a hypothetical program, not a deployed contract.
Write the example on three lines:
- Contract: the hypothetical program at an unspecified Ethereum address.
- State: a variable called
counter. - Function: a defined function called
recordVisit.
Now imagine a user account submitting a transaction that invokes recordVisit. This connects the interaction mechanism to the program’s structure: the request concerns a defined function of the hypothetical contract.
Stop there before assigning an outcome. The assumptions do not specify an initial counter value, an increment rule, or any other change to the variable. In particular, the word “counter” and the name “recordVisit” are not substitutes for an explanation of the function’s logic.
The lesson is a deduction from the stipulated example: knowing that a contract contains a variable and a named function is insufficient to calculate a resulting value. To explain more, the example would need additional assumptions. Leaving that value unspecified preserves the distinction between what the exercise states and what a reader might guess.
Why outside information needs an oracle
Smart contracts alone cannot retrieve data from offchain sources. “Offchain” means outside the blockchain in this context. The qualifier alone matters: the limitation does not mean blockchain applications can never use outside information.
Ethereum’s documentation describes oracles as tools that ingest offchain data and make it available to smart contracts. This gives the data-supply role a name. The contract and the mechanism supplying outside data should remain distinct in an explanation.
For a hypothetical extension of the classroom exercise, suppose someone proposes that the counter should depend on attendance recorded outside Ethereum. That proposal introduces an outside-data requirement. Merely naming recordVisit does not explain how that information becomes available to the contract.
The deduction is limited: because the proposed input is offchain and contracts cannot retrieve such data alone, the explanation needs to identify how it is supplied. An oracle’s data-supply role does not, by itself, establish the accuracy or trustworthiness of the supplied information.
A checklist for reading smart contract explanations
- Identify the program. Keep the explanation tied to Ethereum and the particular contract being discussed.
- Separate code from state. Identify functions as code and variables as data without inventing initial values.
- Clarify account control. Distinguish the EOA’s private-key control model from the contract account’s code control.
- Name the interaction. Identify the contract and defined function involved in the transaction description.
- Match conclusions to evidence. Submission alone does not establish an outcome, and function names alone do not explain behavior.
- Locate outside inputs. If an explanation uses offchain information, ask how it is made available to the contract.
Use this checklist to assess whether an explanation makes its assumptions visible. Source attribution supports the conceptual account given here; it does not establish the safety or correctness of a particular contract.
This educational article was prepared with AI assistance. Its hypothetical example is a reading exercise, not a recommendation to submit a transaction or sign a wallet request.