Step 6 / Ethereum & Shared Applications
Follow a request through Ethereum.
Watch Maya buy a ticket, pay for the work, and check the result.
Maya has 1 ETH in an ordinary account controlled by her key. In this fictional example, a ticket on Ethereum’s base network costs 0.01 ETH.
Her wallet shows a ticket payment and a separate network fee. We will follow the purchase until she knows what changed. Then we will see what changes if the seller uses a token or another network.
Prepare and sign the request.
Maya’s address identifies her account in Ethereum’s shared record. Her wallet is a tool that shows the record and helps her approve actions. Installing another wallet would not move the account to another blockchain.
Ethereum keeps current account balances, contract code, and the values stored by those contracts. Together, these records are called its state. Buying a ticket asks the network to change that state.
This differs from Bitcoin’s payment records. Bitcoin spends earlier outputs and creates new outputs. Ethereum updates account and contract records. Both still need rules for which changes are allowed.
Maya’s wallet prepares a request for the ticket contract. It asks the purchase function to run and includes 0.01 ETH for the ticket. She checks the network, the contract, the action, and the fee limits.
Then her wallet signs the request with her key. The signature can travel with the request; the private key does not need to. Signing gives permission. It does not mean the program has issued a ticket yet.
The next model shows why the starting record matters. If three computers start with five and follow “add three,” each should reach eight. The real ticket program has more steps, but its checkers also need to agree on the starting record and the result.
Every copy starts at five. This is a simplified deterministic state update.
After running “Add three,” notice that all copies show eight. They did not each choose a result. They applied the same instruction to the same starting number.
The program rules and the order of requests
The Ethereum Virtual Machine, or EVM, defines how contract instructions run. It is a set of execution rules, not a separate physical computer.
An ordinary account controlled by a key can begin a signed transaction. A contract runs when a request calls it. A date arriving on the calendar does not, by itself, wake a contract up.
A sending account gives each transaction a sequence number called a nonce. This helps keep requests in order and stop the same request being used again in that sequence. Bitcoin mining also uses a number called a nonce, but that number has a different job in the search for a block.
Some wallets use smart accounts, relays, or delegated account code. These can bundle actions or let a service pay a fee for the user. The screen may look simpler, but the underlying rules and required permissions still apply. A website does not gain spending permission merely by using these tools.
From “sent” to a recorded result.
First, the wallet sends Maya’s signed request toward the network. Computers may check and pass it along while it waits. A “sent” message means the request has been sent, not that Maya owns the ticket.
Next, a block proposer chooses requests and puts them in an order. A block is the next batch of entries proposed for the shared history. The order matters because each request starts from the record left by the ones before it.
When execution reaches Maya’s request, the ticket program runs. In this successful example, her payment is right and a ticket is still available. The program records Maya as its holder.
Computers called full validating nodes check the proposed block and its results. They follow Ethereum’s rules instead of trusting a green check on the ticket website.
There are two connected jobs here. First, check whether a proposed change is allowed; this is validity. Then decide which valid history to follow if there are competing branches. Both are part of how the network reaches agreement, often called consensus.
After inclusion in a block, a receipt reports whether Maya’s request succeeded or failed. Being included, succeeding, and becoming part of a finalized history are different steps. Finality means the network has reached a stronger stage of agreement about that history; we will examine it in the proof-of-stake lesson.
Count the work, then price it.
The network does work to process Maya’s request. Ethereum counts that work in gas. The gas limit says how much work the request may use. The price per unit says what the used work costs.
Start with the smaller numbers in the model. The job needs four work units. Each unit costs three fee units. Four groups of three cost twelve fee units: 4 × 3 = 12.
Now raise the work limit from four to six. The job still uses only four units, so its fee is still twelve. The limit is a ceiling, not a bill for everything below the ceiling.
Lower the limit below four and the job cannot finish. Its requested changes are undone, but it has used some work. That work still has a fee.
The same distinction applies to real execution. A request may run out of gas, or the contract may reject it and undo its requested changes. A block can validly record that failed attempt. A failed request is not the same thing as a block that breaks the network’s rules.
We can now name the fee calculation: gas used × effective price per gas. “Effective” means the actual price charged for each used unit, rather than just a maximum shown in the wallet.
Execution finishes. Unused work allowance is not charged in this simplified model.
Fictional work units and prices. Not an Ethereum gas estimate.
Return to Maya’s successful ticket. Suppose the receipt shows a made-up network fee of 0.0001 ETH. First subtract the ticket price from her balance: 1 − 0.01 = 0.99 ETH.
Now subtract the work fee: 0.99 − 0.0001 = 0.9899 ETH. The contract also records Maya as the ticket holder. These are teaching numbers, not a price quote for a real ticket.
The program has done its part. Maya still needs the venue to honor the ticket. A correct record does not itself open a real door.
Read a real fee format: ETH and gwei
Gas prices often use a smaller ETH unit called gwei. One gwei is one-billionth of an ETH. That means one billion gwei make one ETH.
Suppose the fictional receipt shows 50,000 gas used, with a price of 2 gwei per gas. Multiply the work by its price: 50,000 × 2 = 100,000 gwei.
To express that fee in ETH, divide by one billion: 100,000 ÷ 1,000,000,000 = 0.0001 ETH. This gives the fee in Maya’s example. It does not predict how much gas a real ticket program needs.
The fee has parts. The base fee is burned, which removes that ETH from the supply. The priority fee goes to the block proposer. Demand affects fee prices.
A wallet’s maximum fee setting is not always the price actually charged. The account must also meet the transaction’s upfront ETH requirements before execution can proceed.
This example is an ordinary execution transaction on Ethereum’s base network. Other networks called rollups can add data or service fee parts. Some wallets arrange for someone else to sponsor fees. Check the actual network and payment asset instead of copying this example’s amount.
Permission to spend is not a purchase.
Now another seller asks Maya for ten tokens instead of ETH. Those tokens have their own contract. Maya’s token balance is usually recorded there, separate from her native ETH balance.
Having ten tokens does not by itself pay an ordinary Ethereum network fee. The token payment and the ETH work fee are separate.
Apps need shared ways to ask a token contract about balances and transfers. These shared interfaces are called token standards. ERC-20 describes interchangeable units, such as ten units of the same token. ERC-721 describes distinct tokens, each with its own identifier.
A standard tells apps how to communicate. It does not prove that a token has value, that its code is safe, or that its holder gets particular legal rights.
In one common ERC-20 payment flow, Maya first names a spender and gives it permission to move up to ten tokens. The token contract records this allowance. Nothing has been bought yet.
Next, Maya sends the purchase request. The named spender can use the allowance to move the tokens as the purchase rules allow. Approval and purchase are separate actions in this example.
Closing or disconnecting the website does not erase an existing allowance. Maya needs to check who can spend and how much. “Allow this spender to act later” is different from “pay now.”
Smart wallets and different token designs can combine or present the steps differently. The screen may change, but the important question stays the same: what authority did Maya give?
Changing networks adds another set of rules.
Suppose the ticket service becomes busy. Many users compete for limited space on Ethereum’s base network. One way to handle more activity is to run groups of requests elsewhere and connect their results back to Ethereum.
A system that does this is called a rollup. It does much of the execution outside Ethereum’s base execution. Moving to one means using another execution system, not just choosing a new wallet design.
The rollup publishes data needed to rebuild its record. It also submits a result, with a way to check that result. Ethereum provides a place for those checks and for settling the result.
An optimistic rollup gives participants a period to challenge an invalid result. This depends on a dispute process that works. A validity rollup supplies a proof that the execution followed the rules, which a checking contract verifies.
Both still need data people can obtain and contracts that work as intended. A checking method alone does not answer every safety question.
A rollup may also use an operator called a sequencer to order requests. Its choices can affect which requests get included and when. Different rollups have different upgrade controls, proof systems, withdrawal delays, and emergency exit rules.
Maya may need to move an asset or message between systems. A bridge makes such a connection. Some bridges lock an asset on one side and issue a claim on the other. Other bridges work differently and make different trust assumptions.
Before using the ticket service there, Maya needs the right contract and asset on the right network. She also needs to understand the route used to move them. Two addresses having the same shape does not prove that these other parts match.
A submitted result can be challenged during the protocol’s dispute process. Security depends on working challenges, available data, and the rollup’s controls.
A simplified data path. Sequencing, upgrade permissions and exit conditions vary by rollup.
Maya’s first ticket purchase was complete on Ethereum’s base network. Tokens and rollups add options, along with more permissions and connections to check. For each one, ask what she approved, what record changed, who checked it, and which outside promises remain.
The idea to keep
Maya’s wallet signs a request. A block places it in order, and computers check the work and resulting record. The receipt shows whether the request succeeded. Used work has a fee even if the requested changes fail.
A token adds questions about spending permission. Another network adds questions about its rules and connections. Follow the same path each time: permission, execution, result, and remaining promises.