中文版 · Blockchain learning guide · Previous article
Blockchain learning · Extension BCX003
A verifiable random output does not automatically make a selection process fair. Someone may choose the input after learning useful information, replace the list to which the output is applied, withhold a reveal or discard an inconvenient result. Review the whole sequence of decisions, not only the final proof.
This lesson examines a harmless fictional exhibition-ordering exercise. It separates four questions: was an input unpredictable at the relevant stage, was the output correctly verified, was it applied to the frozen task, and did the process complete under its stated rules? These questions can have different answers.
No money, prizes, wagering, trading or real personal identities are involved. The examples are paper-level protocol reviews with synthetic records. They do not create a contract, use a paid provider, generate keys or submit a live request. A mathematically consistent procedure also does not settle whether its eligibility policy is socially appropriate.
Choose your reading route
In this guide
- 1. Freeze the task before obtaining its result
- 2. Record who knows and chooses at each stage
- 3. Separate unpredictability, verification, use and completion
- 4. Work a two-party commitment exercise
- 5. The last revealer can still refuse to finish
- 6. What a verifiable random function establishes
- 7. A valid proof applied to the wrong list
- 8. Repeated delivery and discretionary reruns are different
- 9. Check the mapping instead of assuming modulo means uniform
- 10. Build the staged review record
- 11. State the bounded conclusion
- Exercise and model answers
- Frequently asked questions
- Sources and further reading
Sections 1–3 explain the information and authority problem. Sections 4–5 examine a two-party commitment exercise. Sections 6–9 follow a verified output through request and list binding, duplicate delivery and mapping. Sections 10–11 build the review record, followed by exercises and answers. For the underlying mathematical vocabulary, see Random Number Generators, Entropy and Statistical Tests.
Back to contents · Next section
1. Freeze the task before obtaining its result
A fictional exhibition has three cards, A, B and C. The task is to choose which card appears first; the remaining cards then retain their frozen relative order. There is no prize or scarce entitlement. The exercise is about the integrity of the selection procedure.
List version V3 is ordered [A, B, C]. Positions are numbered 0, 1 and 2. The application freezes V3, its exact content identifier, the mapping rule and request identity R7 before obtaining the selection output. Later results must be associated with that request and that list.
If the selected position is 1, B appears first and the displayed order is [B, A, C]. Position 1 is not the abstract instruction “choose whichever card is currently second.” It refers to the second entry of the specific frozen V3 task.
This distinction matters even when a cryptographic component is flawless. A correct answer to one fixed input can be misused by applying it to a different list. The application must preserve the association; a proof cannot infer the organiser’s intended task from a changing interface.
Back to contents · Next section
2. Record who knows and chooses at each stage
Before selection, the organiser can define the eligible list and rule. Once those are frozen, the protocol should not quietly preserve an option to reorder the list after the output becomes known. Such an option lets a person choose the displayed outcome without falsifying the output itself.
A value from an already known block is likewise not unpredictable to someone who chooses their input afterward. Calling the value a hash does not change when it became known. The important question is what each participant could know when they still had a consequential choice.
At a protocol level, EIP-4399 discusses influence through withheld proposals and related randomness considerations. We do not borrow its numerical risk examples or treat a beacon value as an unconditional application-fairness guarantee. Its relevance here is that publication and withholding choices belong in the analysis.
For the exhibition review, make four columns in your notes: stage, information available, permitted choices and consequence of nonparticipation. This turns the vague question “is it random?” into a concrete examination of decisions and dependencies.
Back to contents · Next section
3. Separate unpredictability, verification, use and completion
Unpredictability concerns what an observer can foresee before a specified point, under stated assumptions. It is not an assertion that nobody, including the party computing an output, can ever know it before everyone else.
Verification asks whether an output and proof satisfy a defined relation for a particular input and public key. Correct use asks whether the application binds that verified result to the intended request, frozen list and mapping. Completion asks whether the required participants or service deliver enough information for the procedure to finish.
A system can pass verification and fail correct use. It can preserve committed values and still fail completion. A completed result can also be selected from several valid attempts by someone allowed to discard the others.
Keep these conclusions separate in the report. “The proof was valid” is useful evidence. “Therefore nobody could influence who appeared first” is a larger claim requiring additional facts about the full process.
Back to contents · Next section
4. Work a two-party commitment exercise
First consider a separate two-card demonstration with cards X and Y. Participants P and Q each select a private bit. A stipulated commitment scheme is correctly domain-separated and encoded, uses fresh secret randomness, and is both hiding and binding under the supplied security assumptions. We do not implement that scheme or publish any secret.
Both participants must commit before either reveals. A valid reveal opens that participant’s earlier commitment to the same bit. The final orientation bit is their XOR: 0 keeps [X, Y], while 1 gives [Y, X].
In the supplied run, P committed to 0 and Q committed to 1. P reveals 0, then Q reveals 1. Both reveals verify against the earlier commitments. The XOR is 1, so the displayed orientation is [Y, X].
Binding prevents Q from changing its committed bit to 0 after seeing P’s reveal, within the stated assumptions. Hiding matters before reveals because the other participant should not learn the bit from the commitment. A bare hash of a single bit would not provide that protection: an observer can compare the two possible inputs. The stipulated secret randomness and proper construction are essential premises, not decoration.
The exercise does not prove the scheme secure merely by naming these properties. It assumes them so that we can inspect the application-level choices remaining even when the commitments work as intended.
Back to contents · Next section
5. The last revealer can still refuse to finish
Now keep the same commitments but let Q withhold its reveal after learning P’s bit. Q knows its own bit and can work out the resulting orientation. It cannot change the committed value, yet it can prevent this two-reveal procedure from completing as specified.
The correct record is “Q’s reveal missing; no completed orientation under this rule.” Do not silently replace the missing bit with 0. That would introduce a fallback rule and could make withholding a way to choose between different outcomes.
A predeclared timeout can tell observers when to mark the run incomplete. It does not force the missing information to appear. A fallback, cancellation or restart policy needs its own analysis of who can trigger it and what they know at that moment.
No penalty, recovery mechanism or additional party is supplied here. We therefore cannot claim guaranteed completion or unbiased treatment of aborted runs. Preserving all incomplete attempts is important: looking only at the completed runs could hide a pattern of selective withholding.
This is the key result of the commitment example. Correctly opened commitments can establish consistency of revealed inputs while leaving a consequential choice over whether a result is ever published.
Back to contents · Next section
6. What a verifiable random function establishes
RFC 9381 describes verifiable random functions, including deterministic output for a fixed secret key and input, with verification using the corresponding public key. Its publication is an IRTF Informational RFC from August 2023, not an Internet Standards Track specification. The constructions have stated security properties and assumptions.
For our separate three-card exercise, the dossier supplies a correctly verified output for public key K, input I7 and request R7. I7 is the frozen task’s precisely defined input. The application has already authenticated K as the designated key and bound R7 to V3. No real key or cryptographic output is reproduced.
Assume the defined mapping of this supplied output gives position 1. That is a classroom premise, not a test vector for an RFC construction. The expected result is B first, with display [B, A, C].
Proof validity alone does not establish that K was selected impartially, that I7 was chosen before useful information became available, or that the provider will always answer. Those questions require evidence outside the mathematical verification step.
Back to contents · Next section
7. A valid proof applied to the wrong list
Case A is the correct path. The application checks the designated key, exact input and R7 association, uses frozen V3, applies the mapping to position 1, and records [B, A, C]. The dossier supplies successful checks for this case.
Case B receives the same valid proof but the application uses a reordered list V4 = [C, A, B]. Position 1 now names A, producing [A, C, B]. The cryptographic proof has not become invalid; the application has applied it to the wrong frozen-task context.
The acceptance decision should therefore reject Case B’s displayed selection as a result for R7/V3. Calling it “verified randomness” does not repair the list mismatch. A reviewer should retain the proof-valid result and the application-binding failure as separate findings.
Case C receives a valid proof for a different input I8 associated with R8 and tries to use it for R7. It also fails the R7 acceptance check. A proof can be valid for its actual statement and still be irrelevant to the request being processed.
These cases show why the full evidence identity matters: key, input, request, list version and mapping rule. A generic green verification badge hides too much if it does not identify what was actually verified.
Back to contents · Next section
8. Repeated delivery and discretionary reruns are different
Suppose the correct R7 result is delivered twice. Under the supplied application rule, R7 may transition from Pending to Applied once. The first valid delivery records the result. A matching duplicate leaves the selected order unchanged and is logged as already handled; it does not create a second selection.
That is different from creating a new request R9 after seeing that R7 put B first. If the organiser asks again until A appears first and publishes only that attempt, every individual proof might be valid while the overall procedure is selectively reported.
The fictional policy forbids replacing R7’s accepted result with a newly requested result for the same frozen task merely because the organiser dislikes it. A genuine failure before any result exists would still need a predeclared handling policy; this article does not invent one that guarantees fairness.
Chainlink’s VRF v 2.5 security guidance gives implementation-specific advice on matching fulfilments to request identifiers, freezing relevant inputs and avoiding discretionary re-requesting. We use those narrow engineering lessons, not a service endorsement, availability guarantee or instruction to purchase or fund an account.
Back to contents · Next section
9. Check the mapping instead of assuming modulo means uniform
This is a separate tiny arithmetic model. A raw sample U is stipulated to be uniformly distributed over the eight integers 0 through 7. If the application maps U modulo 3, position 0 receives samples 0, 3, 6; position 1 receives 1, 4, 7; position 2 receives 2, 5.
The counts are 3, 3, 2, so the three positions have probabilities 3/8, 3/8 and 2/8 under this toy assumption. The operation is deterministic and easy to verify, but it is not exactly uniform across three positions.
One illustrative repair rejects 6 and 7, then maps an accepted value from 0 through 5 modulo 3. Each position now has two preimages. Conditional on acceptance, each position has probability 1/3. This calculation assumes the stated uniform source; it does not prove a real generator satisfies that premise.
If the procedure draws again after a rejection, the selection of subsequent samples and their independence must be defined in advance. Rejection sampling under a fixed rule is not permission for an organiser to discard a valid mapped result after seeing which card it selects. Repeated rejection also does not guarantee completion within a fixed finite number of samples.
This arithmetic model is not an eight-value VRF construction, and it does not change the earlier supplied R7 mapping result. Its job is to expose a separate application layer that a valid cryptographic proof does not automatically make correct.
Back to contents · Next section
10. Build the staged review record
Before requesting or revealing anything, record the task identity, frozen ordered list, eligibility policy, designated key or participants, mapping and noncompletion policy. Mark which facts are established and which are merely proposed.
At commitment or request time, record the relevant identities and evidence that the inputs were fixed. For the two-bit demonstration, both commitments must precede the first reveal. For the R7 task, the correct list is V3, not whichever version is displayed later.
At result time, record the proof or reveal checks and exact statement they support. Preserve missing replies and failures as well as successful results. A record of absence should not pretend to reveal the missing secret or prove why a party withheld it.
At application time, record the request association, list version, mapped position, resulting order and whether the request was already applied. If the run remains incomplete, report that state explicitly rather than quietly substituting a new result.
For on-chain implementations, visible storage also matters. Solidity 0.8.30’s security guidance warns that a private variable does not make blockchain information secret. Our assumed hidden bits therefore cannot be treated as hidden merely because a source-code field is named private.
Back to contents · Next section
11. State the bounded conclusion
The complete model conclusion is: “The two-party run with verified reveals 0 and 1 produces XOR 1, but withholding the second reveal leaves that procedure incomplete. The separately supplied verified R7 output maps to position 1 of frozen V3 and therefore puts B first. Applying it to V4 or to a different request fails the application-binding check. Duplicate delivery does not authorise a new selection.”
Add the limits: the cryptographic premises were supplied, not implemented; the exercise does not prove unbiased eligibility, impartial key selection, provider availability or a production protocol’s resistance to every adversary. The separate modulo example demonstrates why the output-to-position mapping also needs review.
A useful report can therefore contain several different verdicts: proof valid, task binding failed, reveal absent, mapping biased under the toy distribution, or request already applied. Combining them into one “randomness passed” label would lose the lesson’s most important information.
Back to contents · Next section
Exercise and model answers
- In the two-bit case, P reveals 0 and Q reveals 1. What orientation follows? XOR 1 gives [Y, X].
- If Q withholds, may the reviewer declare XOR 0? No. The required second reveal is absent, and no substitute rule was supplied.
- A valid R7 proof maps to position 1, but V4 is used. Which card appears, and is it valid for R7/V3? A appears; the binding requirement fails.
- Does a matching duplicate R7 delivery produce a new selection? No. The supplied state rule applies R7 once.
- Why is naive modulo 3 biased for uniform 0–7? The positions have 3, 3, 2 preimages rather than equal counts.
- Does rejecting 6 and 7 prove a real generator is secure? No. It fixes the illustrated mapping under the supplied uniform-source assumption, not the generator or whole protocol.
For a writing exercise, ask who still has a meaningful choice after learning the outcome. In the commitment case, the last revealer can withhold. In the wrong-list case, the organiser changes the task mapping. In the rerun case, the organiser selects which valid attempt to retain. These are different failure paths and need different controls.
Back to contents · Next section
Frequently asked questions
Can a random-looking sequence establish a fair process?
Not by itself. A sequence may look plausible while its inputs, included attempts or list mapping were selected after useful information became available. Review the procedure and retained evidence.
Is a valid VRF proof useless without these extra checks?
No. It supplies a specific, valuable verification result. The mistake is asking it to establish unrelated application choices or guaranteed delivery.
Does commitment mean the participant must reveal?
Binding restricts changing the committed value under the scheme’s assumptions. It does not physically force publication. Completion and abort treatment require additional design.
Where should learning continue?
Return to the mathematical prerequisite for entropy and statistical tests. For blockchain applications, practise drawing the information-and-authority timeline before choosing a mechanism. Keep any real implementation review separate from this synthetic lesson.
Back to contents · Next section
Sources and further reading
- RFC 9381, Verifiable Random Functions: August 2023, IRTF Informational; checked 12 October 2026. No claim of Standards Track status.
- EIP-4399: randomness influence and withholding considerations; checked 12 October 2026. No numerical risk estimate is adopted.
- Chainlink VRF v 2.5 security considerations: request matching, input freezing and re-request cautions; checked 12 October 2026, implementation-specific guidance.
- Solidity 0.8.30 security considerations: chain-visible data and private-variable limits; checked 12 October 2026.
- Random Number Generators, Entropy and Statistical Tests: mathematical foundations.
A trustworthy explanation says who could know, choose, replace or withhold something at each stage, and exactly what the final proof leaves unresolved.