中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC058
Two blocks can obey the same execution rules while giving different people the scarce opportunity. The difference may come from which requests are included, which are omitted and how the included requests are ordered. Agreement on a valid result does not, by itself, establish that the selection process was fair.
Maximal extractable value, or MEV, concerns value obtainable through influence over transaction selection and ordering. Ethereum’s documentation defines it relative to value beyond ordinary block rewards and transaction fees. The useful beginner question is not “Which bot wins?” It is “Which decision can change the outcome, who controls that decision and who bears the consequence?” Ethereum MEV overview
This guide answers that question with a fictional catalogue spotlight. There are no currencies, trades, payments or live transaction instructions. The model isolates an ordering incentive; its positions and allocations are not estimates of financial MEV.
Choose your reading route
In this guide
- 1. Start with a fully specified scarce opportunity
- 2. Reordering can change position without changing membership
- 3. Adding another eligible request changes the competition
- 4. Omission must be described separately from failure
- 5. “First” needs an observer and a promise
- 6. Validity, transparency and fairness answer different questions
- 7. Incentive is not the same as proven motive
- 8. Test a visibility change with the same questions
- 9. Test a rule change rather than trusting its name
- 10. Write an outcome report that survives scrutiny
- 11. Exercises and worked answers
- 12. Frequently asked questions
- Sources and next reading
Sections 1–4 work through the allocation example. Sections 5–7 examine the evidence needed for fairness and incentive claims. Sections 8–10 test proposed improvements and their remaining assumptions. The exercises ask you to distinguish a changed sequence, a changed winner and a proven broken promise.
If the actor names are unfamiliar, first review the lesson on sequencers, batchers and proposers. Here the emphasis moves from locating authority to understanding what different uses of that authority do to participants.
Back to contents · Next section
1. Start with a fully specified scarce opportunity
A museum’s fictional learning catalogue has two spotlight positions for one round. Each position displays a different eligible collection. Requests A, B and C represent three different eligible collections. Their owners have authorised their own requests; the ordering operator cannot forge those authorisations.
The round begins with both positions empty. The application processes the selected requests in sequence. The first request from each distinct collection receives the next empty position, if one remains. A later eligible request when both positions are occupied records “no allocation” and changes no spotlight assignment.
Every selected request is evaluated under these rules. “No allocation” is an ordinary application outcome in this toy, not an Ethereum revert or a claim about fees. We omit account nonces, monetary costs, duplicate identities and later rounds. Each request appears at most once in every sequence below.
The operator may choose the sequence from the eligible requests it has received. No FIFO promise, mandatory inclusion deadline or rule against preferring a collection is initially supplied. Those omissions matter: we can compare outcomes before claiming that someone broke a rule.
For the first comparison, A and B are the only selected requests. The sequence is A, B. Position one goes to A and position two to B. Both receive a spotlight allocation.
Back to contents · Next section
2. Reordering can change position without changing membership
Now process B, A from the same empty initial state. B receives position one; A receives position two. The allocated set is still {A, B}, and the number of allocations is still two.
Whether that change matters depends on the application. Our first model says only that each position is a spotlight allocation. It does not assign extra traffic, prestige or monetary worth to position one. We therefore cannot calculate a loss to A merely because A moved down one position.
A clearly labelled extension could give position one an extra benefit. If it did, the outcome measure would need to include that difference. The extension would change the interpretation, even though the allocation set remained the same.
This is an important discipline when assessing order-sensitive systems. “The transactions moved” and “a participant lost an opportunity” are different statements. Sometimes both are true; sometimes the supplied application rules establish only the first.
A report should preserve enough detail to tell them apart: initial state, selected requests, actual sequence, resulting positions and the stated benefit being measured. A transaction list alone cannot supply an unstated valuation.
Back to contents · Next section
3. Adding another eligible request changes the competition
Introduce C as a separate, correctly authorised eligible request. We compare two sequences containing exactly the same three requests, each starting from the same empty state.
In A, B, C, A and B take the two positions. C is processed after capacity is exhausted and receives no allocation. In C, A, B, C takes position one and A takes position two. B receives no allocation.
Relative to A, B, C, the second sequence changes the allocated set from {A, B} to {A, C}. A remains allocated, C gains an allocation and B loses one. Two positions are allocated in both cases. Counting only total successful allocations would hide the distributional change.
Suppose the operator has a disclosed preference for collection C. Then choosing C, A, B serves that preference under the supplied application rule. That establishes a direction of incentive in our model. It does not tell us how much money the operator earned, whether any payment occurred or what happened on a real network.
The operator did not change a signed A request into a C request. C is independently authorised. The relevant power is selecting and placing an eligible competing request, not forging another participant’s identity.
This simplified allocation example helps explain why transaction-ordering opportunities can matter even when execution is correct. It remains an analogy rather than a measurement of market MEV.
Back to contents · Next section
4. Omission must be described separately from failure
Consider an independent variant in which A, B and C have all reached the operator, but the selected sequence is A, C. A and C receive the two positions. B is not processed in the round’s selected sequence.
The final allocation set matches C, A, B, although the positions differ. But B’s evidence is different. In C, A, B, B was processed and received no allocation. In A, C, B was absent from the selected sequence.
Do not report both situations as “B’s transaction failed”. One is an application outcome after processing; the other is non-inclusion in the identified sequence. The model supplies no subsequent round, expiration or retry result, so B’s later fate is unknown.
Omission from one observed round also does not automatically establish permanent censorship. To support that stronger claim, an investigator would need the applicable inclusion policy, observation scope and evidence of the relevant actor’s choices or repeated exclusion.
At the same time, absence should not be dismissed merely because the selected block is valid. A policy can require treatment of eligible requests beyond what the execution-validity rules check. The correct analysis asks which obligation is being tested and what evidence would demonstrate its violation.
Back to contents · Next section
5. “First” needs an observer and a promise
Suppose a gateway G records receipt A, then B, then C. That is a useful local sequence. It is not automatically a globally agreed arrival order across every participant and network path.
If the service explicitly promises “For eligible requests received by G in this round, preserve G’s recorded order”, the promise has a testable scope. Given trustworthy receipt records and the same eligibility set, C, A, B would violate that supplied promise.
Without that promise, the same ordering may remain allowed by the toy’s validity rules. A critic can still argue that the policy is undesirable, but should distinguish that judgement from proof of a broken protocol rule.
The receipts also need enough binding information. A record must identify the request and round, and the review must establish that the request met the policy’s eligibility conditions. A timestamp screenshot without those connections may be inadequate evidence.
For a multi-gateway service, a fairness claim needs a rule for reconciling observations. One gateway’s A-before-B and another’s B-before-A do not create a single obvious global answer. The policy must explain which observations count and how disagreements are handled.
Back to contents · Next section
6. Validity, transparency and fairness answer different questions
Validity asks whether the selected sequence and state transitions satisfy the specified rules. Transparency asks which relevant choices and evidence observers can inspect. Fairness asks whether an explicitly chosen treatment criterion is satisfied.
Our sequences can all be valid under the initial permissive selection rule, yet produce different allocation sets. Publishing the final sequence makes that outcome visible, but may leave the omitted-request set and prior commitments unknown.
A service could publish every selected request while hiding its receipt records. That would help replay execution without proving that every eligible arrival was treated according to a promised admission policy. Conversely, a receipt log could expose selection choices without proving that the executed application code was correct.
Useful fairness criteria might concern preserving a named gateway’s order, giving each eligible collection one entry or applying a disclosed selection procedure. These are different criteria. Satisfying one does not silently establish the others.
For this exercise, do not label one criterion as universally correct. Instead, write the chosen criterion before observing which participant benefits. That prevents a review from defining “fair” retrospectively as “the result I preferred”.
Back to contents · Next section
7. Incentive is not the same as proven motive
The catalogue model supplies the operator’s preference for C, so it is legitimate to analyse how one sequence serves that preference. A real observation that C won would not, by itself, prove such a preference or an undisclosed arrangement.
A careful investigation separates capability, opportunity, incentive and observed action. Capability is the operator’s control over selection or sequence. Opportunity is an order-sensitive application state. Incentive is a reason to prefer one result. Observed action is evidence that a particular choice actually occurred.
The 2019 research paper Flash Boys 2.0 examined transaction-ordering competition and connected ordering-dependent value to broader blockchain risks. Its arXiv submission is dated 10 April 2019. It is historical research, not a current revenue estimate or evidence about the fictional catalogue. Flash Boys 2.0
The umbrella term MEV does not make every activity identical in mechanism or effect. The assessment must identify the specific state change, affected participants and consequences rather than assign every example the same moral or economic conclusion.
Our toy provides no fees or prices, so even a precise allocation difference cannot be converted into a financial return. The defensible result is a change in who receives the supplied opportunity.
Back to contents · Next section
8. Test a visibility change with the same questions
A proposed improvement says requests will be hidden from the public before ordering. That changes an information boundary. To evaluate it, ask who still sees the content, when it becomes visible and what those parties can do with it.
If the operator still sees all requests and keeps discretionary ordering, hiding them from outside observers does not, by itself, remove the operator’s preference for C. It may reduce some outsiders’ opportunities while leaving that particular choice unchanged.
As a real example of why details matter, the Flashbots Protect settings guide describes sharing choices and explicitly notes that adding builders introduces trust in those builders. We use that narrow point to illustrate the need to identify recipients and assumptions, not to recommend a service or reproduce its configuration instructions. The page was updated on 12 May 2026. Flashbots Protect settings guide
A privacy statement should therefore identify whose visibility is restricted. “Not publicly broadcast before inclusion” and “no party can use the contents before ordering” are substantially different promises.
The review must also retain availability and inclusion questions. A private route can still need a specified response to unavailable participants or unprocessed requests. A confidentiality claim alone does not answer those questions.
Back to contents · Next section
9. Test a rule change rather than trusting its name
Imagine the catalogue replaces discretionary order with a precisely specified, independently checkable allocation procedure. That could change the operator’s available choices. To assess the proposal, examine the whole input-selection boundary, not merely the last calculation.
Who determines which requests enter the round? Can a participant submit multiple identities? How is the round closed? Can the operator omit a request before the checkable procedure begins? What evidence allows a disappointed participant to challenge that omission?
These questions do not prove that the proposal fails. They identify assumptions needed before claiming that it solves the original problem. A perfectly reproduced calculation over a selectively chosen input set can still leave the admission question unresolved.
A hypothetical random selection rule likewise needs specified eligibility, an appropriate randomness mechanism and a defined resistance to manipulation. Calling the output “random” does not establish those properties. This article does not implement such a mechanism.
An alternative application design could remove the scarce first-two allocation entirely. If every eligible collection receives an equivalent spotlight in the toy, reordering no longer changes membership under that modified rule. But the design has changed the resource requirement; it has not demonstrated how to allocate the original two positions fairly among three requests.
Back to contents · Next section
10. Write an outcome report that survives scrutiny
A useful report for our main comparison might read: “From the same empty two-position state, A, B, C allocates A and B, while C, A, B allocates C and A. Both sequences satisfy the supplied execution rules. The second benefits the operator-preferred C at B’s expense in allocation terms. No FIFO commitment or monetary valuation was supplied.”
That report preserves the meaningful difference without adding facts. It does not confuse total allocations with participant outcomes, attribute an unstated fee or turn a model into a claim about a real provider.
For a broader review, record five items: the state and capacity, eligible requests, relevant observer and commitment, actor’s available choices, and outcomes for each participant. Add unknowns such as omitted arrivals or unverified receipt records rather than filling them with assumptions.
When assessing a mitigation, rerun the same comparison under its actual rules. Identify which choice disappeared, which party gained responsibility and which assumptions remain. A changed label or architecture diagram is insufficient evidence of a changed allocation guarantee.
The most useful conclusion may be limited: “This proposal reduces one actor’s visibility, but its admission policy remains unverified.” A bounded finding is more actionable than an unsupported promise that ordering risk has vanished.
Back to contents · Next section
11. Exercises and worked answers
Question 1. Compare A, B with B, A under the original two-position rules. What changes?
Answer. Positions change; the allocated set remains {A, B}. No different value for the two positions was supplied.
Question 2. Compare A, B, C with C, A, B. Who gains and loses an allocation?
Answer. C gains, B loses, and A remains allocated. The total stays two.
Question 3. In A, C, what is established about B?
Answer. B is absent from this selected sequence. It is not established that B was processed, permanently excluded or included in a later round.
Question 4. Trusted G receipts show A, B, C, all eligible. A binding policy promises to preserve that order. Does C, A, B comply?
Answer. No. Under the added policy and evidence, the sequence violates the stated ordering promise. This differs from the original model without that promise.
Question 5. Public observers cannot read pending requests, but the ordering operator can and retains the same discretion. Is its preference for C eliminated?
Answer. No. The visibility change alone does not remove that actor’s information or ordering power.
Question 6. Both sequences allocate two positions. Is that enough to call their participant outcomes equivalent?
Answer. No. Equal totals can hide a changed allocation set.
Back to contents · Next section
12. Frequently asked questions
Is every reordered transaction evidence of wrongdoing?
No. Establish the applicable rule, actor, evidence and consequence before reaching that conclusion.
Does a valid block prove a fair ordering process?
Only if the claimed fairness property is actually enforced by the relevant rules and its required evidence is established. Valid execution alone is insufficient in this example.
Does this catalogue calculate financial MEV?
No. It demonstrates an order-sensitive allocation and a supplied preference, without money or a revenue model.
Does one privacy feature remove every ordering risk?
That conclusion needs much more evidence. Visibility, admission, sequencing and enforcement are separate parts of the design.
Back to contents · Next section
Sources and next reading
Sources checked on 12 October 2026:
- Ethereum MEV overview, used for the definition and selection/ordering scope, not its operational strategies or revenue claims.
- Flash Boys 2.0, arXiv submission 10 April 2019, used as historical primary research on ordering-dependent value.
- Flashbots Protect settings guide, updated 12 May 2026, used only for the explicit information-sharing and builder-trust boundary.
The catalogue rules, sequences and conclusions are original teaching examples. Continue to the benchmarking lesson to see how equal headline totals can also hide different transaction outcomes and observation windows.