中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC052
A cross-chain message does not become trustworthy merely because somebody carried it from one network to another. The destination needs a rule for recognising the source, authenticating the message, accepting the relevant source state, preventing repeated effects and deciding what its own application should do.
These are separate questions. A relayer can deliver correct bytes late. A valid source record can target another destination. An authentic message can arrive before an application prerequisite. A repeated delivery can be harmless if the destination correctly remembers the first accepted effect.
This guide follows a fictional museum revision notice across two chains. No assets move, no bridge is selected, and no live transaction or exploit is performed. The aim is to read a cross-chain acceptance rule carefully enough to explain both successful and rejected deliveries.
Choose your reading route
In this guide
- 1. Separate delivery from authority
- 2. What makes a remote state acceptable?
- 3. Define the museum message completely
- 4. Normal delivery and duplicate delivery
- 5. Wrong context is not repaired by a correct proof
- 6. Authentic messages can arrive out of application order
- 7. Reorganisation before acceptance and contradiction afterwards
- 8. Source finality and destination finality are different observations
- 9. Change the verifier and the guarantee changes
- 10. Build a message acceptance record
- 11. Exercises and worked answers
- 12. Frequently asked questions
- Sources and next reading
Sections 1–3 identify the trust boundaries and define the complete exercise. Sections 4–8 test normal delivery, duplication, wrong context, out-of-order messages and source-history assumptions. Sections 9–11 turn those results into a review checklist and worked questions.
A bridge can carry messages and arbitrary data as well as support asset-related applications. Those uses do not all have the same verification or governance design. The lesson therefore starts with one explicit acceptance contract rather than treating “bridge” as a universal security guarantee. Ethereum bridge documentation
Back to contents · Next section
1. Separate delivery from authority
Imagine that a courier hands a museum branch a signed instruction. The courier’s arrival proves that a package arrived. It does not, by itself, prove who authorised the instruction, whether it is current, whether it names this branch or whether the instruction has already been acted upon.
The same separation matters in cross-chain systems. A relayer transports information; a verifier determines whether the supplied evidence satisfies the configured rule. The destination application then applies its own conditions. Combining these jobs in one diagram should not erase their different responsibilities.
IBC’s channel specification describes packets relayed between independently confirming chains and separates channel semantics from the application’s interpretation of packet data. That separation is useful here, even though the exercise is not an implementation of IBC. IBC ICS 4: Channel and packet semantics
A relayer may affect delivery availability without having authority to invent accepted content. Conversely, a system that accepts a relayer’s signature as the decisive evidence is assigning that actor an additional verification role. The role must be named explicitly rather than inferred from the word “relayer”.
Back to contents · Next section
2. What makes a remote state acceptable?
A destination does not independently gain knowledge of another chain just by opening a connection. It needs a configured verification method and starting assumptions. These may involve an authenticated trusted state, rules for accepting later source states, a specified finality policy and a correctly implemented proof checker.
IBC’s client specification describes a validity predicate paired with a trusted state and notes that light clients generally do not execute the remote state machine’s entire transition logic. Client-specific assumptions therefore remain relevant. IBC ICS 2: Client semantics
For this lesson, the source-state verifier is a supplied idealised component. It is correctly initialised, checks the specified source identity and accepts only states meeting the source’s stated finality rule under its stated fault assumptions. A separate membership check authenticates the exact message bytes against the accepted source state.
We are not building that verifier or claiming that a short checklist implements a secure light client. Its correctness and assumptions are inputs to the exercise. If they fail, the exercise’s resulting guarantee must be reconsidered; repeating the word “proof” does not repair them.
Back to contents · Next section
3. Define the museum message completely
The source chain is S, with application ArchiveA. The destination chain is D, with application MirrorB. The configured source stream is epoch1. Within that stream, the source assigns a unique sequence number to each message and does not reuse it for different content.
The destination stores a revision number for object42. Initially it is 2. Its set of successfully consumed message identities is initially empty.
Message m7 has these fields:
- Source chain S and source application ArchiveA.
- Stream epoch1 and sequence 7.
- Destination chain D and destination application MirrorB.
- Object object42, expected prior revision 2, new revision 3.
The full message identity is the tuple S, ArchiveA, epoch1, 7, D, MirrorB. Exact canonical message encoding, including the payload fields, is authenticated by the membership check. The identity and payload therefore cannot be freely recombined by the courier.
MirrorB accepts m7 only if every condition holds: the configured source and destination domains match; the source state passes its verifier; the exact message passes membership verification; the identity is unused; and object42 currently has the expected prior revision.
On success, MirrorB atomically writes revision 3 and records the identity as consumed. On any rejection, neither changes. Assume correct implementation, serial transaction execution for this state, fixed verifier configuration and no administrator override or upgrade during the exercise. There are no expiries, asset transfers or timeout refunds in this toy.
Back to contents · Next section
4. Normal delivery and duplicate delivery
In the first card, all verification conditions pass and object42 still has revision 2. MirrorB accepts m7, writes revision 3 and records the full identity. There has been one accepted application effect.
A second relayer later delivers the same m7 with equally valid evidence. The identity is already consumed, so the destination rejects repeated application. The revision remains 3 and the consumed set still contains one identity.
Changing the relayer does not create a new message. Changing the transport connection does not create a new message either. The acceptance rule uses the authenticated identity, not the identity of the courier or the number of delivery attempts.
This is an at-most-once effect within the supplied destination state machine. It is not an unconditional promise that every source message eventually succeeds. A message might never be delivered, its evidence might be unavailable, or its application condition might remain unsatisfied.
The atomic step matters. If the revision changed but the consumed marker were lost, the implementation would no longer match the exercise. If the marker were recorded while the application update failed, it would also violate the stated success rule. The two changes form one transition here.
Back to contents · Next section
5. Wrong context is not repaired by a correct proof
Reset the destination to revision 2 with no consumed identities for each card in this section.
Wrong source application. A valid proof establishes a message from OtherArchive on S. MirrorB is configured for ArchiveA. The message is rejected. A genuine record from an unauthorised source is still outside the acceptance contract.
Wrong destination. The authentic message names chain E or application OtherMirror. It is rejected by MirrorB on D. The fact that its object field also says object42 does not override the destination domain.
Altered payload. A relayer changes new revision 3 to revision30 but supplies evidence for the original bytes. Exact-message membership verification fails. The destination does not apply the altered revision.
Unaccepted source state. A message is present in a source block, but the required finality condition has not been established. The source-state verifier does not accept it, so there is no destination update. A later delivery with adequate evidence could produce a different result; the present card does not supply that evidence.
Each rejection has a different reason. Recording only “bridge failed” would hide the difference between domain mismatch, byte mismatch and insufficient source-state evidence. Useful reports preserve the first unsupported condition without inventing a broader network failure.
Back to contents · Next section
6. Authentic messages can arrive out of application order
Now introduce m8. It uses the same source and destination domains, epoch1 and sequence8. Its authenticated payload is object42, expected prior revision 3, new revision 4. Both m7 and m8 have acceptable source-state and membership evidence.
The toy has no transport rule requiring delivery by ascending sequence number. Instead, its application checks the expected prior revision. Start again at revision 2 with an empty consumed set.
- Deliver m8 first. Its proof passes, but the expected prior revision 3 does not match current revision 2. Reject without consuming m8.
- Deliver m7. Its expected revision 2 matches. Accept, write revision 3 and consume m7.
- Deliver m8 again. Its expected revision 3 now matches. Accept, write revision 4 and consume m8.
- Deliver m7 again. It is already consumed. Reject; revision remains 4.
The outcome is revision 4 with exactly two consumed identities. There were four delivery attempts but only two accepted updates.
This trace is not a claim about every IBC channel type or every bridge’s retry behaviour. It follows our explicit application guard and rejection rule. A design that consumes failed messages, enforces transport ordering or applies expiries would require a different trace.
Sequence numbers and application revisions also play different roles. Sequence identifies a message in its stream. Expected revision expresses the state prerequisite for this object. Their numerical values need not match, and neither field should silently replace the other.
Back to contents · Next section
7. Reorganisation before acceptance and contradiction afterwards
Consider a candidate source block containing m7 that has not met the configured acceptance condition. It is later removed from the source’s selected history. Under the supplied rule, MirrorB had not accepted it. There is no destination revision change to reverse.
Now consider a more serious hypothetical: the verifier had accepted a source state as final, m7 was applied, and later evidence genuinely contradicts that accepted finality under the same source rules. This is not merely a courier delay. It means that a premise of the exercise, or the verifier’s implementation of that premise, has failed.
The worksheet does not contain a rule that automatically rewrites D whenever S changes. D has its own history and execution rules. A report cannot claim that the destination update vanishes without identifying an actual destination mechanism and its authorisation.
The responsible conclusion is to identify the failed assumption, the affected accepted messages and the destination states that depend on them. What a real system can freeze, correct or otherwise resolve depends on its configured design and governance. Those actions are not invented by this lesson.
This distinction matters even for non-financial messages. If a museum has already published a display using a mirrored revision, a later correction is another workflow problem. Cryptographic verification does not erase external actions that people already took.
Back to contents · Next section
8. Source finality and destination finality are different observations
Suppose m7 has adequate source evidence and a destination transaction includes the successful MirrorB update. The source condition and destination inclusion have both been established, but they refer to different chains and different events.
To say that the destination effect is final, the reviewer must also apply D’s relevant finality rule to the destination transaction’s block. A source certificate cannot by itself certify the destination block. A relayer’s delivery acknowledgement cannot do that either.
Likewise, a missing acknowledgement does not prove that the destination rejected the message. The acknowledgement path may fail after acceptance. Our consumed-identity record permits the toy to distinguish a duplicate delivery from a new application effect, but the evidence still has to be read in the correct destination context.
Do not infer a source-side undo permission from a missing response. This exercise defines no refund or reverse-message mechanism. Real protocols that implement such mechanisms require explicit conditions, proofs and state transitions of their own.
The discipline is to name both observations: the accepted source state that authenticates the message, and the destination state that records its application. “Cross-chain complete” without those references can conceal an unfinished step.
Back to contents · Next section
9. Change the verifier and the guarantee changes
Imagine a variant that replaces the source-state verifier with approval signatures from three designated reviewers out of four. Assume signature verification and membership of that reviewer set are correctly checked. What follows directly is that the required designated keys approved the exact message.
Whether those reviewers correctly observed S, applied the finality policy and reported truthfully is an additional assumption. The threshold does not turn their statement into a replay of the source chain’s full validation. This is a different evidence model, even if the destination application guard is unchanged.
An administrative ability to replace the verifier is another relevant boundary. Our base exercise excluded it. If a variant gives an administrator that power, the acceptance rule can potentially change through that route. Technical capability to change a rule is not evidence that a particular change is authorised or intended.
Ethereum’s bridge documentation identifies contract and counterparty risks. Those categories are useful prompts for asking what code and actors a particular system depends on; they do not justify a blanket safety ranking from a label such as “trustless”. Ethereum bridge risks
A good comparison names the actual verification rule, configuration controls, source assumptions and destination application logic. It does not substitute an attractive category name for those details.
Back to contents · Next section
10. Build a message acceptance record
For each message under review, record:
- Source network, source application and stream identity.
- Destination network and destination application.
- Exact message identity and authenticated payload.
- Accepted source state and the verifier assumptions supporting it.
- Membership evidence binding this message to that state.
- Destination replay status and application prerequisites.
- Destination transaction outcome and, separately, its finality evidence.
- Missing evidence, configuration changes and unresolved assumptions.
This record also helps explain rejection without overstating it. “Correctly authenticated but wrong application revision” is different from “invalid proof”. “Delivered twice, applied once” is different from “the first delivery never arrived”.
The record should preserve the scope of any guarantee. At-most-once application depends on correct identity handling, atomic state changes and the destination history being considered. It does not provide a delivery deadline, nor does it prove the truth of an off-chain museum claim merely because the source application recorded it.
Back to contents · Next section
11. Exercises and worked answers
Question 1. Starting at revision 2, deliver m8, m7, m8 and m7 with valid source evidence each time. What is the final revision and number of consumed identities?
Answer. The outcomes are reject, accept, accept, reject. Final revision is 4; there are two consumed identities. The first m8 rejection did not consume it under the supplied rule.
Question 2. A different relayer delivers already consumed m7. Does that make it a fresh message?
Answer. No. The full authenticated message identity is unchanged.
Question 3. A proof correctly authenticates a message from OtherArchive. Must ArchiveA-configured MirrorB accept it?
Answer. No. Proof correctness cannot remove the source-application restriction.
Question 4. A source block is removed before it meets the acceptance rule. What destination change must be reversed in this card?
Answer. None. No update was accepted under the supplied verifier rule.
Question 5. The destination update is included, but its block has not met D’s finality rule. May source finality fill that gap?
Answer. No. Source and destination finality concern different histories.
Question 6. Three approved reviewer signatures are genuine. Do they alone prove that the reviewers reported source events truthfully?
Answer. No. They establish approval by the specified keys. Truthful observation and correct finality assessment remain assumptions of that variant.
Back to contents · Next section
12. Frequently asked questions
Does a bridge copy the whole source blockchain?
Not necessarily. The destination may verify a specific claim using a configured client or other evidence mechanism. Its actual validation responsibility must be identified.
Does a valid proof guarantee that the application update succeeds?
No. The application can reject a correctly authenticated message because its own conditions are not satisfied, as m8 demonstrates.
Is repeated delivery always harmful?
No. Correct replay handling can prevent a repeated application effect. Delivery and effect counts should be reported separately.
Are these message rules a deployable bridge design?
No. They are deliberately bounded teaching rules. Real systems require complete protocol definitions, implementation review and operational assumptions far beyond this worksheet.
Back to contents · Next section
Sources and next reading
Primary sources checked on 12 October 2026:
- IBC ICS 2: Client semantics. The inspected main-branch document is marked draft, created 25 February 2019, modified 4 August 2022, with ibc-go v7.0.0 compatibility metadata.
- IBC ICS 4: Channel and packet semantics. The inspected main-branch document is marked draft, created 7 March 2019, modified 25 August 2019, with ibc-go v7.0.0 compatibility metadata.
- Ethereum bridges, used for message-carrying scope and risk categories, not current provider recommendations.
The moving specification pages provide conceptual reference points. The museum message format, acceptance rules and traces are original examples, not statements that this toy is a deployed IBC channel or bridge implementation.