Open the complete story and reading map
Bitcoin made the relationship between authorization, validation and ordering concrete. The next question was broader: could applications share a programmable environment instead of each building its own network or fitting every rule into a payment-specific design?
Ethereum's original whitepaper argues for a general platform whose applications can define state transitions and interact. That is a design argument, not a claim that Ethereum invented every form of smart contract. Bitcoin already had a scripting system, and programmable agreements had earlier precedents. Ethereum's whitepaper should also be read as a historical document: its implementation details are not a substitute for current protocol documentation.
2015: an environment people could actually use
The Ethereum Foundation's July 30, 2015 announcement marks Frontier, the first live release. This separates the proposal and development period from network launch. The historical shift was not “payments stopped mattering.” It was that transfers could now be one step inside a more general application.
A shared escrow, without magical knowledge
Consider a fictional digital-design commission. Noor deposits 100 units into an escrow program. The program tracks a buyer, a seller, a deadline and a status. It releases payment when the buyer signs acceptance; if a dispute occurs, a named arbitrator can decide under the agreed rules. This is a teaching design, not deployable contract code.
| Before | Accepted input | After | Unsolved outside question |
|---|---|---|---|
| Awaiting deposit | Required funds arrive | Funded | Was the buyer misled about the product? |
| Funded | Buyer's valid acceptance | Paid to seller | Was acceptance obtained under pressure? |
| Disputed | Authorized arbitrator decision | Release or refund | Is the arbitrator competent and available? |
State means the recorded situation that the next operation reads and changes. Every validating participant should obtain the same result from the same accepted inputs and rules. That consistency does not tell the program whether a design is beautiful, a parcel arrived or a human acted fairly. External information needs a defined source—often called an oracle—or an explicit human decision.
Why not run the same escrow on an ordinary server?
You can. A server may offer cheaper execution, private data and easier correction. A shared blockchain becomes interesting when multiple parties need to verify a common state and accept its control arrangements. It also brings public execution costs and constraints. The choice should start with the participants' problem, not with a rule that every application needs a token.
Compare the two deployments by asking who can change the program, who can stop execution, who holds the assets and how a dispute is resolved. A contract with an administrator upgrade key may still give that administrator substantial power. The presence of a blockchain does not answer those questions for you.
Gas: a resource budget, not a promise of success
Executing shared programs consumes resources. Ethereum uses gas to meter work and transactions set limits on consumption. The historical whitepaper explains why unbounded computation would be a problem. A request that fails can still consume work; a transaction fee is not a warranty that the business outcome will be what the user intended.
In our escrow, imagine the buyer accidentally chooses the wrong function. The network may faithfully execute an authorized instruction that the buyer regrets. A good interface must explain the requested action before signing, while the contract must handle the situations its designers intend to support.
Composability creates both opportunities and dependencies
Now imagine the escrow receives a token, consults a price feed and sends funds to another application. Reusing components can make new services easier to build. It also creates a dependency chain. An error in a token permission, an unsuitable price observation or an unavailable outside decision can affect the larger workflow.
Draw the chain as four questions: what comes in, which rule runs, what outside evidence is trusted and who receives control afterward? This is a more useful beginner exercise than memorizing dozens of application names.
The next chapter examines what happens when deployed application code behaves in a way its users did not expect. The DAO made the difference between contract behavior and collective governance impossible to ignore.
Check your reasoning: if every node agrees that the escrow paid correctly, must the seller have delivered?
No. Agreement means the accepted inputs produced the specified state transition. Delivery is an outside fact. The design must identify who attests to it and what happens if that information is wrong or contested.
Go deeper: Ethereum architecture · Oracles and outside data.