Two blockchains do not automatically share one memory. Each network maintains its own state and history. To use an event from one chain in another, an application needs a message and a defined way to check why the message should be trusted.
Alicia receives a fictional science-club certificate from one school’s digital system. A partner museum uses another system and wants to recognise the certificate. Tricia cannot simply copy an unfamiliar number and declare it valid. Kai Kai asks which institution issued the claim, what it means and how the museum can check it.
The answer in everyday language
Start by identifying the claim, the people authorised to act, and the exact digital evidence. A network’s accepted record is not a substitute for accurate source information, fair rules or a responsible recovery process.
Why a simpler alternative matters
Before building a blockchain application, compare an ordinary database, signed documents and an accountable service provider. If those meet the actual requirement, additional network complexity may not be justified.
1. Two chains have different histories
An event accepted by Network A is not automatically part of Network B. Their block references, consensus rules, finality and membership may differ. A receiving application needs to identify the exact source and accepted reference.
2. Define the claim before building a bridge
The museum may only need to check whether certificate C was issued by the authorised school and remains valid. That is narrower than transferring every record between the networks. A signed credential could already meet the need.
3. A relayer transports a message
A relayer can convey information or proof material between systems. Carrying a message does not independently prove that the underlying event occurred. The receiving system needs explicit verification rules.
4. Different bridges rely on different trust assumptions
Some bridges rely on a committee of signers, others on light-client verification or cryptographic proofs. A bridge can be weaker than the chains it connects if its own security assumptions are inadequate. There is no universal bridge mechanism.
5. Finality at the source still matters
The receiving chain’s own finality does not guarantee that the source event was sufficiently settled. The application needs to specify when it trusts the source and what happens if the source history changes under its rules.
6. Moving a representation is not duplicating an asset
Some asset bridges lock, burn, mint or account for representations using different mechanisms. A token on another network may represent a claim rather than a second independent asset. Users must examine custody and redemption conditions.
7. When interoperability is unnecessary
If the museum only needs to verify a school-issued certificate, a signed credential and issuer status service may be simpler. Do not deploy a cross-chain bridge simply because two organisations use different software.
8. Paper exercise: the messenger
Give two clubs separate notebooks. Club A approves an imaginary certificate. A messenger carries the claim to Club B. Ask whether the messenger’s word is sufficient, which issuer Club B trusts and what evidence it should require.
9. Plan for a delayed or failed message
A relayer can disappear, a proof can be rejected and a source can become unavailable. The application needs understandable pending statuses, a dispute route and a way to avoid falsely claiming that the second system accepted the event.
A parent-and-child learning check
Use only paper and invented records. Ask the learner to name what the system knows, what an external person must verify and what should happen if the two disagree. No real wallet, key or cryptocurrency is required.
Questions to ask before trusting a result
Who supplied the source information? Which key or role was authorised? What network and state reference are being used? What was actually accepted? Is the displayed result current? Who handles a dispute or missing response?
Frequently asked questions
Does the blockchain guarantee the application is correct?
No. It provides network-specific mechanisms for validating and accepting digital actions. Incorrect inputs, software bugs and mistaken business rules remain possible.
Can a signed message be false?
Yes. A signature can support attribution and integrity under the relevant assumptions. It does not automatically make the statement accurate.
Is this suitable for children?
Yes, when taught as a paper exercise about evidence, permissions and responsibility rather than a cryptocurrency investment activity.
Continue through the eduKateSG learning system
Use the specialist technical companion for implementation details. The English guide, Chinese guide and main hub connect the wider series.
Sources and limits
Primary reference: https://ethereum.org/bridges/. General context: NIST Blockchain Technology Overview. The story is a fictional learning example, not an actual school blockchain deployment or a recommendation to transact with real assets.