How Blockchain Works | Logs, Events and Application Memory

A fictional club’s cupboard currently has three balls available. Its noticeboard lists several earlier loans and returns.

The count describes a current condition. The list describes selected historical actions. They are related, but they are not the same object.

A blockchain application can similarly have current contract state, execution logs and an off-chain display that organises historical data.

This guide uses application memory in that broad explanatory sense. It does not mean every kind of computer memory has the same technical role.

Our cupboard, requests and identifiers are invented. No live contract needs to be called.

Start with three boxes: state, event record and history display. We will follow the connections between them and ask which question each box can answer. That separation makes many confusing explorer and application screens easier to interpret.

Contents · Next chapter

The fictional lending program stores available stock and whether each borrower has an outstanding loan. Its rules consult those values when processing the next request.

These stored values form part of the application’s state.

A state query can answer a question about the referenced point in the ledger, such as how many balls are recorded as available there. It does not automatically return a narrated list of every earlier action.

The exact storage and query mechanisms depend on the platform and implementation.

For our paper model, keep a state card that is updated after each accepted action. It begins with four balls available and no outstanding loans.

The card’s purpose is to support the program’s next decision. The historical notices we add later have another role: making selected execution information available for observers and applications.

Contents · Previous chapter · Next chapter

When the fictional program accepts a loan, it updates the relevant state and emits a message called LoanOpened.

In Solidity, events are an abstraction over the EVM’s logging mechanism. They allow execution to produce structured information that outside applications can obtain.

The emitted information is determined by code. A reassuring event name is not an independent witness watching the physical cupboard.

This distinction is important. LoanOpened may mean the software recorded a loan, not that a particular person physically received a ball.

Our paper model writes the event on a separate slip after applying the stated rule. The slip and state card can be compared.

The beginner question is what the event is intended to report and whether the implementation supports that meaning. The name alone does not establish the full result.

Contents · Previous chapter · Next chapter

A transaction’s receipt provides information about its execution in the relevant network context. On Ethereum, that information includes logs produced by successful surviving execution.

A transaction and an event are not interchangeable objects. One transaction can produce several logs from one or more contracts, depending on the calls it makes.

Our fictional request T17 opens a loan and produces one teaching event. A more complex fictional request could update several related components.

When reading a receipt, identify which log is relevant and which contract emitted it. Do not assume every line in a friendly display is a separate top-level transaction.

The related branch has a guide to reading receipts. Here the focus is narrower: understanding how an execution record can carry messages that another application later turns into a useful history.

Contents · Previous chapter · Next chapter

Two fictional contracts can both use the name LoanOpened. One is the club’s recognised lending program; another is an unrelated demonstration.

A log with a familiar event name does not, by itself, establish that it came from the intended program.

The emitting address and network context are essential to interpretation. A data format and code context are also needed to understand the fields.

Our paper event slip therefore records Practice Network, Lending Contract C and Request T17 before the event label.

This is not a cryptographic implementation. It is a way to make provenance visible.

The general lesson is familiar from digital identity: a statement needs a source. A well-formed message can come from the wrong source for the task. Correctly decoding that message does not repair the missing connection to the intended application.

Contents · Previous chapter · Next chapter

The fictional event slip contains borrower LARK, item Ball-1 and loan identifier L17. The teaching program defines what those fields mean.

Real event data is encoded according to the relevant interface. A tool uses a suitable description to turn bytes into readable field names and values.

The ABI, or application binary interface, is part of that decoding context in Ethereum applications.

A decoded display is useful, but it is still an interpretation of encoded information. Using an inappropriate description can produce misleading labels.

The beginner does not need to decode bytes manually. It is enough to ask where the readable names came from and whether they match the emitting contract’s interface.

This keeps a friendly table from becoming unquestioned truth. The data, its source and the method used to interpret it each contribute a distinct part of the evidence.

Contents · Previous chapter · Next chapter

A large application can emit many events. Readers need a way to locate the ones relevant to a question.

Ethereum logs include topics used for filtering, and Solidity event declarations can mark certain parameters as indexed. The exact encoding and limits belong to the platform’s specification.

Our paper analogy uses coloured tabs to find loan events for an invented borrower. The tabs make searching easier; they do not replace the event’s meaning or provenance.

Not every displayed field is necessarily stored in the same way. A reader should not assume that an indexed complex value is always present as its original readable text.

We do not need those encoding details for the tabletop lesson. The key distinction is between a search aid and a factual guarantee. A convenient filter helps find candidates; the relevant context still has to be checked.

Contents · Previous chapter · Next chapter

At the time of T17, the fictional program emitted LoanOpened for LARK. Later LARK returned the ball and the loan was closed.

The old event still describes the earlier recorded action. A current state query can correctly report no outstanding loan.

These answers do not conflict. They concern different moments and questions.

This is why historical event evidence should not automatically be read as current eligibility or permission. The token-approval guide uses the same distinction for old Approval events.

Our paper model places a LoanClosed slip after the LoanOpened slip and updates the state card. The sequence explains how both views fit together.

A clear evidence sentence names whether it reports an event at a particular execution point or a state at a particular reference. The word is should not silently replace the words was recorded.

Contents · Previous chapter · Next chapter

Solidity documentation distinguishes event logs from state variables that a contract uses during execution. A contract cannot simply read its past event logs as if they were its own ordinary stored fields.

External applications can obtain logs through the appropriate interfaces. Special constructions can supply evidence to contracts, but that is different from an automatic direct lookup of every past event.

Our fictional program therefore keeps an outstanding-loan field when its next decision needs that information. It does not rely on reading its paper noticeboard each time.

This chapter explains a design distinction rather than offering implementation instructions.

The beginner lesson is that emitting an announcement and storing a value for future program decisions are different actions. A history display can be rich while the contract’s state remains carefully structured around the checks it needs to perform.

Contents · Previous chapter · Next chapter

The fictional LoanOpened event lists the borrower and loan number but not the equipment’s colour. A reader cannot recover the colour from that slip alone.

An event schema records selected information. It is not necessarily a complete transcript of every computation or every state value.

The program may also have behaviours for which it emits no event of the kind a particular observer expects.

This matters when an application builds a history only from selected logs. The resulting view can be useful without being a complete account of all relevant state changes.

Ask what the event definition includes and omits. Then match the conclusion to those fields.

Our paper exercise deliberately leaves out the colour. The omission teaches a useful restraint: do not fill missing information with a plausible story and then describe that story as something the log itself proved.

Contents · Previous chapter · Next chapter

The fictional noticeboard sorts loan events by borrower and date. Someone or some software has collected and organised the slips to produce that view.

An indexer performs a comparable role for blockchain data. It retrieves relevant records and builds structures that make them easier to search and display.

The index is not identical to the underlying chain. Its completeness, update position and interpretation can affect what the user sees.

A website can therefore show an incomplete history while the relevant logs exist in the source data.

This is not a reason to reject every index. It is a reason to understand its role.

Our three-box picture now has a clear route: execution changes state and emits logs; an indexing service reads selected records; the application displays a convenient history. Each connection has work to do.

Contents · Previous chapter · Next chapter

The fictional program has processed a return, but the noticeboard has not yet collected the LoanClosed slip. It still displays the loan as open.

The mismatch may concern indexing delay rather than a disagreement in the accepted state.

To investigate, compare the relevant reference points and the index’s processing position. A cached display can add another delay.

The network-partition guide explains why local observations need timing context. That habit applies to derived history tables too.

Our paper model places the new event in an incoming tray while leaving the noticeboard unchanged. The picture shows exactly where the lag occurs.

A careful statement says that this display had not yet reflected the later record at the observed time. It does not immediately claim that the return failed, the contract lost data or every participant has an inconsistent history.

Contents · Previous chapter · Next chapter

An event appears in a block that one service initially treats as part of the selected history. Later the relevant branch changes and that block is no longer in the selected chain.

An indexer needs to handle the network’s changing-history and settlement context appropriately. Simply appending every observed log forever can create a misleading current history.

The forks guide explains the underlying concept. Here we connect it to an application’s derived records.

Our fictional noticeboard marks provisional slips differently until its defined settlement condition is met. That is a teaching choice, not a universal policy recommendation.

The evidence note should identify the block and its relevant status. An event’s bytes and source are only part of the story; the accepted-history context matters too.

This is why a screenshot of an early event display is not automatically definitive evidence of a permanently settled application outcome.

Contents · Previous chapter · Next chapter

An execution can reach code that would emit a log and then revert. Logs belonging to a reverted execution scope do not remain as successful receipt logs from that scope.

A transaction trace or diagnostic tool may show attempted execution details. That is different from a retained event in the accepted receipt.

Nested calls and caught failures can make the full picture more complex, so the relevant execution scope matters.

Our beginner model uses a simple all-reverted request: the loan update and event do not survive as accepted effects of that request.

Do not treat a debugging screen and the final receipt as identical evidence sources.

The useful question is what the tool actually reports. Did code attempt an action, did a call succeed, did a log survive, and which resulting state was accepted? Those questions should be answered separately.

Contents · Previous chapter · Next chapter

The fictional club wants to calculate current loans by replaying LoanOpened and LoanClosed slips.

That can work in its simple model if the event history is complete, the ordering is correct and every relevant state transition is represented faithfully.

Those are conditions, not automatic properties of every contract.

A real application may emit insufficient information, use additional change paths or have implementation-specific event behaviour. The indexer also needs the correct starting point and version context.

This is why event-based reconstruction should be explained as a defined method with assumptions.

Our paper example can deliberately remove one closing slip and show the wrong reconstructed result. The exercise reveals the dependency on completeness without touching a real system.

A current-state query and an event-derived estimate can be compared, but agreement or disagreement needs interpretation within the actual contract design.

Contents · Previous chapter · Next chapter

The fictional contract emits EquipmentDelivered. The name sounds conclusive, but the program only knows the inputs and rules it processes.

It may be recording an authorised claim rather than observing the physical handover.

The oracles and supply-chain guides establish this boundary. A log can be excellent evidence that a program emitted certain data while remaining insufficient evidence that every outside claim is true.

Our paper model writes “reported delivery” beside the event and separately records the fictional observer’s handover evidence.

This is not wordplay. It identifies the source of each assertion.

When explaining an event, begin with what was emitted and by which program. Then add any outside conclusion only when its evidence route is available. A strong event name cannot supply a sensor, trusted observation or factual check that the application never had.

Contents · Previous chapter · Next chapter

Create a fictional state card with four balls available. Process one loan to LARK and write a LoanOpened slip. Update the count to three.

Now process a return, write LoanClosed and update the count to four.

Give a second reader only the first slip. Ask whether that reader can establish the current loan state. Then give the full slips but leave the noticeboard unrefreshed.

Finally add a second contract that emits the same event name. Ask which provenance fields distinguish it.

The exercise uses no code or live accounts.

Its purpose is to make the three views concrete. State supports current program decisions. Events expose selected execution information. An index and display organise that information for readers. Understanding the route is more useful than treating every history-shaped screen as a direct, complete copy of the application’s state.

Contents · Previous chapter · Next chapter

Logs, events and state describe different aspects of an application. A current count is not a complete story, and an old event is not automatically a current condition.

The display adds another layer through decoding, indexing and caching. Its usefulness depends on those processes being appropriate to the question.

Carry four labels into the technical companion: source, format, reference point and scope. Who emitted the data? How was it interpreted? Which history or state does it concern? What does it actually establish?

Our fictional cupboard shows how a correct old event and a correct current query can differ without contradiction. It also shows why a familiar event name is not enough to establish provenance or an outside outcome.

The reader’s task is to choose evidence that answers the actual question, rather than asking one convenient table to represent every kind of application memory.

Contents · Previous chapter · Worked situations