eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

Blockchain Oracles: Check the Report Before Trusting the External Fact

—

by

eduKate Asia
Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.

中文版 · Blockchain learning guide · Previous article

Blockchain learning · Article BC040

Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.
Study photograph for illustration; it does not establish that the pictured students are studying blockchain.

An oracle brings information from outside a blockchain into a form that on-chain code can consume. The blockchain can check the report’s programmed acceptance conditions and process it consistently. That does not automatically establish that the underlying measurement or event is true.

This lesson follows a fictional cabinet-temperature report from observation to a contract’s inspection flag. You will check identity, units, freshness, sequence and disagreement before computing a median. The example is non-financial and uses arbitrary classroom thresholds, not real storage, conservation or safety requirements.

Choose your reading route

In this guide

Start with the data pathway and the distinction between a signed statement and an accurate observation. Then work through the three-report acceptance test. The stale-data and correlated-source cases explain why a correct signature and a plausible median are only parts of the evidence.

No real sensors, keys, feeds or transactions are configured. The report format and policy below are invented for learning; they are not a claim about the implementation of any named oracle service.

Back to contents · Next section

1. An oracle connects two evidence domains

A contract can evaluate the inputs available in its execution context. It cannot independently inspect a physical cabinet merely because its code contains a variable named temperature.

The Ethereum oracle overview explains how off-chain components supply information for on-chain consumption. Oracle designs vary in data sources, operators and delivery methods. The important common question is how an external observation becomes a specific accepted statement.

Picture the path as physical condition, measurement source, report preparation, authentication, delivery, on-chain acceptance and application use. Each step introduces its own assumptions. A correctly processed last step does not erase uncertainty introduced at the first.

For example, a sensor may be calibrated incorrectly, a reporter may use the wrong unit, delivery may be delayed, or the consumer may read the wrong feed. These failures have different causes and need different checks. Calling the entire path “verified by blockchain” hides rather than resolves them.

Back to contents · Next section

2. A signature identifies an authorised statement, not a thermometer’s accuracy

Suppose reporter A signs a message saying that a cabinet measured 7 degrees Celsius at a stated time. A valid signature can support the conclusion that the corresponding signing authority authorised those bytes under the applicable scheme.

It does not prove the sensor was inside the intended cabinet, that its calibration was correct or that the reading was copied without an upstream mistake before signing. A compromised or mistaken authorised reporter can produce an authentic but false statement.

Likewise, several signatures are not automatically several independent measurements. Reporters may all read one upstream database. If that database is wrong, the reports can agree perfectly while sharing the same error.

This is why an oracle review should distinguish signer diversity, operator diversity and source diversity. Counting keys is not enough to understand dependence. The worksheet will check distinct authorised reporters, then separately explain what that check cannot establish.

Back to contents · Next section

3. Specify exactly what the report means

Our fictional application monitors Cabinet-7 for a classroom inspection exercise. It records a flag, not an instruction to open a door, release goods or make a payment.

Each signed report contains the network and consumer-contract context, cabinet identifier, reporter identifier, batch sequence, observation time, unit and integer reading. The signature is assumed to cover all these fields in an unambiguous encoding.

The unit is explicitly whole degrees Celsius. A value of 7 means 7 degrees, not 0.7, 70 or an unlabelled quantity. The accepted numeric range is 0 through 50, solely as a classroom plausibility rule.

The context fields prevent this exercise from treating a report for another cabinet or consumer as interchangeable. The sequence field helps reject an already consumed batch. The timestamp supports an age check under a supplied time reference. None of those fields alone establishes physical truth.

The Chainlink Data Feeds API reference provides a useful real-world reminder that answers, decimal scaling and update timestamps are separate interface data. Its updatedAt field describes the round’s update time; it should not automatically be relabelled as the time a physical source was measured. Our toy explicitly supplies an observation-time field instead.

Back to contents · Next section

4. The classroom consumer has a complete acceptance rule

The consumer’s last accepted batch is 11. Its authorised reporter registry contains A, B and C. For this exercise, an update requires one valid report from each of those three distinct reporters.

All three reports must identify the same intended network, consumer, Cabinet-7, new batch and observation time, and use the specified unit. Their batch must be greater than 11. A repeated signature from A cannot substitute for B or C.

The supplied evaluation time is 1030 seconds on the exercise’s shared time scale. Each observation must be no later than 1030 and no more than 60 seconds old. We deliberately allow no future-time tolerance in the toy; real systems must specify their own clock and timestamp assumptions.

Each reading must be an integer from 0 through 50. After those checks, the largest reading minus the smallest must be at most 4. If the spread check passes, the consumer takes the median of the three readings.

An accepted report sets a classroom flag to WithinRange if the median is at most 8, otherwise Review. It also stores the accepted batch and observation time. These thresholds are arbitrary teaching choices and must not be used as real cabinet-management guidance.

Back to contents · Next section

5. Work through the accepted batch

Batch 12 contains three validly signed reports: A reports 7, B reports 8 and C reports 7. All identify Cabinet-7, the required context and unit, and observation time 1000.

The batch is new because 12 is greater than the stored 11. Reporter identities are distinct and authorised. The age is 1030−1000=30 seconds, which is within the 60-second limit, and the observation time is not in the future.

All readings lie in the supplied range. Sorted values are 7, 7 and 8. The spread is 8−7=1, which is at most 4, and the median is 7.

The report is accepted. The stored batch becomes 12, observation time becomes 1000 and the flag becomes WithinRange because 7 is at most 8. The application has accepted a properly structured, sufficiently recent and internally consistent report under its toy policy.

That last sentence is the justified conclusion. “The physical cabinet is definitely safe” is not. Neither the numerical threshold nor the report pathway was designed or validated for such a real-world claim.

Back to contents · Next section

6. Reject replay, duplicate identity and wrong context before aggregation

After batch 12 is accepted, submitting that same batch again fails the new-sequence condition. The signature can remain valid while the report is no longer acceptable as a new update.

A packet containing A’s report three times also fails. There are three delivered messages but only one distinct authorised reporter. Aggregating their values would hide the missing B and C evidence.

A signed report for Cabinet-8 does not become a Cabinet-7 report because the numeric reading looks plausible. Similarly, a report using another unit or another consumer context should fail the corresponding check rather than be silently reinterpreted.

This order matters. Calculate a median only after establishing that the candidate reports belong to the required set. A beautifully computed statistic over the wrong cabinet, duplicate sources or incompatible units does not answer the application’s question.

For each independent exercise case later, reset the last accepted batch to 11 unless the case explicitly says batch 12 has already been consumed. This avoids confusing replay rejection with a separate test of freshness or values.

Back to contents · Next section

7. Freshness concerns the meaning of time, not just a small subtraction

With observation time 1000 and evaluation time 1100, the age is 100 seconds. The report fails the toy’s 60-second limit even if every signature verifies and the readings still agree.

At evaluation time 1060, the age is exactly 60 and passes the inclusive rule. At 1061 it fails. A future observation time 1050 evaluated at 1030 also fails; the toy must not treat a negative age as proof of freshness.

The arithmetic is easy. The harder question is what the timestamp means and who can influence it. A signed observation time is still a reporter’s statement. The consumer’s evaluation time also needs a defined protocol context rather than an arbitrary local clock chosen by each validator.

A delivery timestamp, an aggregation timestamp and the original observation timestamp can describe different stages. A recent on-chain update can carry old source information. Before using a real feed’s timestamp, read its actual semantics instead of assuming that every field called updated means freshly measured.

Back to contents · Next section

8. Rejecting a stale update does not make an old stored value fresh

Suppose the accepted batch 12 remains stored with observation time 1000. At time 1100, a consumer reads the old WithinRange flag. No fresh batch has arrived.

The stored flag may still contain that label, but its underlying observation is now 100 seconds old. The consuming operation must apply its freshness condition when using the value, not only when the original update was accepted.

Under our supplied use rule, stale stored data cannot support the WithinRange outcome for a new inspection decision. The application reports data unavailable or requests review rather than treating an old green label as indefinitely current.

This does not require storage to rewrite itself when time passes. As in the contract-state-machine lesson, changing eligibility and executing a state update are different. The relevant read or action checks the current context against the stored observation time.

A fallback policy is a design choice with consequences. Keeping the last value, pausing an action or seeking manual review each handles availability differently. The worksheet chooses a conservative classroom response; it does not claim that one fallback suits every application.

Back to contents · Next section

9. A median can hide disagreement unless the policy checks it

Consider an independent batch with readings 7, 7 and 25, all otherwise valid and fresh. The median is 7, but the spread is 25−7=18.

Our policy rejects the batch because 18 exceeds 4. It does not accept the median first and then ignore the outlier. The explicit disagreement rule makes the consumer ask for review rather than presenting a reassuring summary without its context.

This is one possible policy, not a universal oracle algorithm. A different design might use other aggregation, outlier or fault assumptions. The key is to state which conditions justify the output and what happens when those conditions fail.

Now consider 9, 10 and 9. The spread is 1 and the median is 9. This is an acceptable report under the authenticity, freshness and agreement checks, but it sets Review because the median exceeds the classroom threshold 8.

Distinguish invalid evidence from valid evidence of an out-of-range condition. Rejecting every inconvenient value would make the application incapable of reporting the condition it was meant to detect.

Back to contents · Next section

10. Three agreeing reporters can share one bad source

Suppose A, B and C all report 7 because they read the same malfunctioning upstream database. Their signatures, sequences, units and timestamps satisfy the toy checks. Their spread is zero and median is 7.

The consumer can accept the batch while the underlying physical condition is different. This is not an arithmetic failure. It is a source-dependence failure outside the guarantees of our acceptance rule.

The Chainlink guide to selecting data feeds emphasises assessing source accuracy, availability and risk, including dependence on a single provider. We use that source-level lesson without implying that this cabinet model is a Chainlink implementation or that any provider eliminates all risk.

A meaningful review asks where the observations originate, whether supposedly separate reporters share infrastructure, how measurements are calibrated and who can change those dependencies. “Three signatures” answers a different question from “three independently reliable observations.”

Back to contents · Next section

11. Availability and authority need their own questions

An oracle pathway can stop delivering data because a source, reporter, network route or update mechanism is unavailable. A contract cannot produce a new trustworthy observation merely by continuing to execute old code.

Our three-of-three reporting rule is intentionally easy to inspect but has an availability cost: one missing required reporter prevents a new accepted batch. Changing that threshold would change the trust and fault assumptions. It is not a cosmetic configuration adjustment.

The reporter registry is also a source of authority. Who can add a reporter, replace a compromised key or change the allowed cabinet context? The toy holds the registry fixed; a real application must identify those control paths and their safeguards.

The Chainlink Data Feeds overview describes an ecosystem of feed components and consumption patterns. Real systems have specific architectures and operational requirements. A diagram with an oracle box should not conceal the operators and dependencies inside that box.

Back to contents · Next section

12. Separate a blockchain decision from a physical action

Our accepted flag is only an application record. It does not physically inspect the cabinet or command a lock. If a later system uses the flag to trigger an external action, it adds a new delivery and control boundary.

That external system must identify which state it trusts, whether the report remains fresh, whether the containing history is sufficiently settled for its purpose and whether the requested physical action actually completed.

A successful on-chain update and a successful physical action are different events. An actuator can fail, a human can misunderstand the instruction or an external service can process it twice. Those possibilities need their own evidence and operating rules.

The lesson is not that automation is impossible. It is that a complete explanation follows the entire path instead of stopping at the first valid signature or accepted transaction. Record integrity, external truth and real-world completion remain separate claims.

Back to contents · Next section

13. Exercise: classify the reports and their limits

Unless stated otherwise, begin with last accepted batch 11, evaluation time 1030 and the supplied three-reporter policy. All unspecified context and signatures are correct.

  1. Batch 12 reports 7, 8 and 7 at observation time 1000. What are age, spread, median and flag?
  2. After accepting batch 12, the same batch is submitted again. Does a valid signature make it a new update?
  3. A’s signed report is delivered three times, with no B or C report. Does that satisfy the reporter requirement?
  4. Observation time is 1000 but evaluation time is 1100. Does agreement among the values overcome the age failure?
  5. A fresh batch reports 7, 7 and 25. Why is the median alone insufficient under the stated policy?
  6. A fresh batch reports 9, 10 and 9. Is it an invalid report or accepted evidence producing Review?
  7. All three reporters copy a wrong upstream value of 7. Can the toy checks prove the real cabinet condition?
  8. An old WithinRange flag remains stored after its observation becomes stale. May a new consumer action treat it as fresh without another check?

Answers and reasoning

  1. Age 30 seconds, spread 1, median 7; the report is accepted and the flag is WithinRange.
  2. No. Its batch sequence is no longer greater than the last accepted sequence.
  3. No. Three deliveries from one reporter do not satisfy three distinct authorised identities.
  4. No. Age 100 exceeds the 60-second limit. Agreement does not repair staleness.
  5. The spread is 18, which violates the maximum 4. The policy rejects the batch despite median 7.
  6. It is accepted evidence: spread 1 and median 9, so the flag is Review.
  7. No. The checks do not establish independent accurate measurement. Common-source error can survive every listed acceptance test.
  8. No. The consuming operation must evaluate freshness at use time under its policy.

Extension: test the exact age boundary

At evaluation time 1060, observation time 1000 has age 60 and passes. At 1061 it has age 61 and fails. A claimed observation time of 1050 at evaluation time 1030 fails the no-future-time condition rather than being treated as age minus 20 and therefore acceptable.

Boundary tests expose what vague words such as recent often hide. A useful interface documents both the timestamp semantics and the exact comparison.

Back to contents · Next section

14. Frequently asked questions

Is an oracle a single trusted person?

It can involve one or multiple sources, operators and components. Inspect the actual architecture rather than inferring it from the name.

Does decentralisation prove the external data is true?

No. Diversity can address specified failure assumptions, but shared sources, measurement errors and incorrect interpretation can remain.

Does fresh mean correct?

No. Freshness limits age under stated timestamp assumptions. A newly signed wrong observation is still wrong.

Can a contract repair a broken sensor?

It can apply rules to the information it receives, but physical repair and calibration require external action. A rejected report is a signal for handling, not a repaired instrument.

Back to contents · Next section

15. Sources and next reading

Primary sources checked on 12 October 2026, Singapore time. Vendor documentation is cited for specific interface and risk concepts, not as an endorsement, investment recommendation or statement that a service is available in every jurisdiction.

Review signatures for what authentication establishes, and contract conditions for how a consumer applies its checks. Continue to the scaling module with the same habit: identify exactly which claim a mechanism supports, and which assumptions remain outside it.

Back to contents