中文版 · Blockchain learning guide
Blockchain learning · Extension BCX001
Choose a practice environment by the question you want to answer. A local development chain can give you a repeatable starting state. A locally simulated fork can expose an application to selected existing state. A public testnet can provide shared network interaction. These environments produce different evidence, and the word “test” does not make their boundaries interchangeable.
This guide follows a fictional experiment across three environments. You will identify which state an operation changes, decide what a local reset restores, and explain why an old observation can remain in a file after the simulated chain has moved back. The result is a reproducible environment record rather than a misleading “it worked” screenshot.
The exercise is entirely hypothetical and nonfinancial. It needs no installation, account connection, faucet, real secret, public submission or purchase. Its labels are invented, and no actual network is accessed. Readers in mainland China should not interpret a technical description as confirmation that a service is available to them or that a financial activity is permitted.
Choose your reading route
In this guide
- 1. Three environments, three different starting points
- 2. Locality is a location claim, not a complete isolation claim
- 3. Separate practice identities, data and assets
- 4. Read the fixed experiment dossier
- 5. Apply the same operation to two different states
- 6. Reset L and account for every surviving record
- 7. Do not promote a transaction identifier into a complete experiment identity
- 8. Choose an environment for the question
- 9. Understand the extra assumptions in a local fork
- 10. Write a reproducibility record and a bounded conclusion
- Exercise: repair the environment report
- Frequently asked questions
- Sources and further reading
Read sections 1–3 to distinguish the environments and contain the experiment. Sections 4–7 supply the worked state and reset dossier. Sections 8–10 help select an environment and report the limits of a successful test. The exercise and model answers follow. For designing assertions after the environment is settled, use the defensive contract test matrix.
Back to contents · Next section
1. Three environments, three different starting points
A fresh local development chain starts from a deliberately configured state. The operator can often control conveniences such as initial test balances, block production and debugging. Those powers make repeated experiments easier, but they are part of the experiment’s conditions.
A local fork simulation starts from state associated with an identified source-chain block, then runs a separate local experiment. “Fork” here describes a development construction. It does not mean the student has created a live consensus dispute or changed the source chain. A local modification is local only if its destination and surrounding integrations are actually confined to that environment.
A shared public testnet has other participants and a history the learner does not personally control. It may be useful for observing integration with shared infrastructure. It is not a private scratch file, and an ordinary local reset cannot erase its history.
Ethereum’s network documentation distinguishes independent networks and explains that an account’s balances and history do not carry from one to another. The same account representation is not evidence of the same state. This lesson goes further by assigning explicit run identities, because even two local runs can reuse a chain identifier and endpoint label.
Back to contents · Next section
2. Locality is a location claim, not a complete isolation claim
A process running on your computer can still contact external services. A fork simulator may read remote state. An application may send requests to a different endpoint from the one shown in a test script. A separate indexer or exported file may preserve observations after the simulated chain resets.
Therefore, describe the whole experiment boundary: the chain process, application, request destination, signing context, remote reads and independent stores. Do not infer that “localhost” somewhere in a project name proves every operation stays local.
The Geth developer-mode documentation describes a single-node development network without external peers and with on-demand blocks. That is a specific node configuration. It does not establish that every surrounding browser, application or file operation is offline. Its single-node behaviour also cannot demonstrate a distributed consensus property by itself.
For our fictional fresh environment L, the dossier explicitly supplies a stronger boundary: no external network calls, no public endpoint, no external signer and no integration that writes outside its specified local stores. This is an assumption we can reason from, not a safety guarantee supplied by the letter L.
Back to contents · Next section
3. Separate practice identities, data and assets
A practice environment should not depend on a production secret or contain real customer data. This worksheet uses labels such as Practice-A, not actual addresses or recovery phrases. The environment provides only synthetic permissions and quantities. Nothing represents a transferable asset or a real entitlement.
Do not reuse a real account simply because a test screen appears familiar. Ethereum’s network documentation explicitly discourages reusing mainnet and testnet accounts. It also describes test assets as intended for testing while acknowledging markets for some scarce test assets. “Always worthless” would therefore be an inaccurate universal claim.
Public test data should be treated as potentially visible and retained. A fake token balance does not make a real name, document, credential or business record safe to publish. There is no need to publish any such material to understand how environments differ.
Development tools may offer privileged shortcuts that would not be available on another network. These should be recorded as test controls. A result achieved using a supplied local administrative capability is evidence about that controlled setup, not proof that the user possesses the same authority elsewhere.
Back to contents · Next section
4. Read the fixed experiment dossier
The worksheet contains three separate execution contexts and one observation file. All starting values and behaviours are stipulated. This is not a report of running a real client.
- L is a fresh isolated local simulator. It runs tool profile Sim-A version 1 with rule profile R1. Its record Counter begins at 0 in snapshot S0. Its configured chain identifier is 31337, its endpoint label is LOCAL-L, and the first experiment identifier is L/run01.
- F is a separate local fork simulation. Its source context is fictional network S, identified block K with an independently supplied block identity. At that source block, Counter is 7. F starts with that value, uses its own configured chain identifier 31337 and endpoint label LOCAL-F, and records experiment F/run01.
- T is a fictional shared public testnet. The supplied observation at an identified testnet block shows Counter = 11. We perform no operation on T in this lesson.
- O is an independent local observation file. It is outside L’s chain snapshot and initially contains no result. Its record includes the experiment identifier and observed value.
The integer 31337 is a supplied configuration value here, not proof that either endpoint belongs to a particular product. L and F deliberately share it. They remain distinct experiments with different starting states and destinations.
F is allowed to make read-only requests to its specified source-state provider when needed. It has no configured source-chain submission path in this dossier. Unlike L, it is therefore not stipulated to be offline. These permissions are part of the model, and no live provider is contacted by the exercise.
Back to contents · Next section
5. Apply the same operation to two different states
The toy application allows the authorised practice actor to add 2 to Counter. It changes no other tracked state. We ignore fees and account-level bookkeeping because the question concerns environment identity and reset scope, not transaction accounting.
Apply the operation to L/run01 at LOCAL-L. Counter becomes 2. Export an observation to O containing the pair L/run01 and value 2. The file is a record of this observed result; it is not automatically a live view of the chain.
Apply the same operation to F/run01 at LOCAL-F. F’s Counter becomes 9 because it started at 7. The source record at the pinned block K remains 7. We have made no operation on source network S, and the dossier supplies no claim about S’s later live tip.
T’s supplied observed value remains 11 in our record because we neither submit an operation nor obtain a new observation. This does not assert that other public participants cannot change T after that observation. A fixed observation and a continuously current state are different things.
The two local results differ without either implementation necessarily being faulty. The inputs include the starting state, not only the increment instruction. Reporting “the same test gave different answers” without naming L’s 0 and F’s 7 would conceal the reason.
Back to contents · Next section
6. Reset L and account for every surviving record
The next action is precisely defined: restore only L’s tracked simulator state to snapshot S0. In this model S0 includes the original Counter = 0 and application setup. It does not include O, F, T or any source network.
After restoration, L’s Counter is 0. F’s Counter remains 9. O still records L/run01 with value 2. The supplied observation of T remains 11. The source state at pinned block K remains 7.
There is no contradiction between L now showing 0 and O recording an earlier 2, provided O retains its run and observation context. A problem appears if a user interface strips that context and presents O as the current result of the restored L instance.
For the next experiment, the worksheet assigns the new provenance label L/run02, while keeping LOCAL-L and configured chain identifier 31337. This label is a laboratory bookkeeping choice, not a claim that a particular tool automatically generates a new network identity on reset. Before comparing results, the observer must associate them with the correct run.
A reset is also different from application failure rollback. Here the operator deliberately restores a prior simulator snapshot after a completed experiment. We are not describing the execution semantics of a reverted transaction or a public-chain reorganisation.
Back to contents · Next section
7. Do not promote a transaction identifier into a complete experiment identity
Imagine O also retained a transaction hash from L/run01. That hash does not by itself prove that the transaction belongs to the current L/run02 history. The new run might not contain it, or a sufficiently identical reconstruction might reproduce an identifier. The lesson does not need to assume which outcome occurs.
A useful lookup therefore names the environment, run, endpoint provenance and relevant block context. A familiar address, hash or chain identifier cannot replace those fields. If a local history has been reset, an old result should not be silently relabelled as evidence from the new history.
For the same reason, observing chain identifier 31337 from both LOCAL-L and LOCAL-F does not authenticate either service or prove their state is equal. In the supplied dossier we already know the endpoints’ identities through separate trusted setup evidence. Without that evidence, matching numeric responses would leave endpoint authenticity unresolved.
This is a practical reason to record provenance before debugging. Otherwise, a team may spend hours searching for a calculation bug when the application is querying F while the test runner is inspecting L.
Back to contents · Next section
8. Choose an environment for the question
Consider five proposed experiments. Each selection is conditional on its documented setup, not a recommendation to connect to a public service now.
For a repeatable application-logic bug with a tiny fixture, use the fresh isolated local environment L. Its controlled initial state makes the comparison meaningful. It does not establish behaviour under unknown peers or real shared-network load.
For compatibility with a specified existing state layout, use a local fork such as F with the source block and overrides recorded. It can expose assumptions hidden by an empty fixture. It does not establish that the same operation is authorised or will succeed on the source network today.
For two independently operated clients exchanging records, use a deliberately configured multi-node test environment that actually contains those clients and communication paths. Our single-process L dossier does not contain that evidence. Merely opening two browser tabs would not supply it.
For observing interaction with shared public infrastructure, a suitable public testnet may answer a narrower integration question. Its lifecycle, access, data exposure and dependencies must be considered separately. This article performs no such interaction and does not certify service availability in the reader’s location.
For validator or protocol-upgrade behaviour, use an environment designed for that protocol question, with the required client versions and roles. An application simulator producing instant blocks is not an adequate substitute simply because both environments use the word blockchain.
Back to contents · Next section
9. Understand the extra assumptions in a local fork
Hardhat 3’s EDR simulated-network reference describes fork state loaded from a remote network as needed. It also says configured accounts can override balances and code, while the configured chain identifier need not be the source chain’s identifier. These details show why a fork is not automatically an offline, untouched production replica.
For a reproducible fork experiment, record the tool version, rule configuration, source network and block identity, configured overrides, remote provider dependency and operation destination. If a required state item is not available locally and the provider is unavailable, the experiment may fail to obtain its inputs. That is different from proving the application rule rejects the operation.
Our F dossier already supplies these distinctions at a simplified level: Counter comes from block K, local execution changes F only, remote reads are allowed, and no source submission path is configured. A reader should not generalise that final restriction to every development project without checking its actual integrations.
A fork can be useful precisely because it is controlled. The mistake is forgetting the controls when interpreting the outcome. If an administrative override manufactured a balance or permission, include that fact in the result rather than presenting the experiment as an ordinary-user action on the source chain.
Back to contents · Next section
10. Write a reproducibility record and a bounded conclusion
A good record names the question, environment type, exact tool and rule versions, starting state, input operation, observation endpoint, run identifier, external dependencies and reset boundary. It also names independent stores that were not reset. A screenshot can supplement this record but should not replace it.
The model conclusion for our experiment is: “Under the supplied R1 fixture, incrementing by 2 produces L=2 from 0 and F=9 from 7. Restoring only L to S0 returns L to 0 while the independent observation file retains its historical L/run01 value 2. No source-chain or public-testnet operation was performed.”
That conclusion does not establish production finality, fee levels, congestion behaviour, adversarial safety, recovery from arbitrary failures or a legal entitlement to deploy. Fast local success can be valuable evidence for the stated fixture without answering any of those broader questions.
The EDR reference also describes automatic block production for development. Such timing is a configured convenience. An application that appears immediate under it still needs appropriately designed evidence for shared-network waiting and failure conditions. Do not convert a local elapsed time into a production service promise.
Back to contents · Next section
Exercise: repair the environment report
A learner writes: “Both networks say 31337, so they are the same. The increment returned 2 locally and 9 on the fork, so one must be broken. I reset the chain, which deleted the old value everywhere. The public testnet is now ready for production because the local operation was instant.”
Identify at least six unsupported claims or missing distinctions before reading the answers.
Model answer: the matching chain identifier does not establish the same instance or authentic endpoint. L and F start at different values. Their results 2 and 9 are both correct under the supplied rule. Resetting L restores only the stipulated simulator state. O retains its historical value 2, and F remains 9. No operation or reset was performed on T. Local timing does not establish production readiness or public-network behaviour.
Now answer four narrower questions:
- What is L immediately after restoring S0? Counter 0.
- What does O contain? The historical observation L/run01, value 2; it is not automatically a current-state query.
- Does F’s result 9 prove that source network S changed? No. The operation was directed only to F, and the pinned source state remains 7 in the dossier.
- What should a new result under LOCAL-L be labelled after the reset? L/run02 under this worksheet’s provenance scheme, with its starting snapshot and other configuration recorded.
For an extension, suppose an application screen reads O while the test runner reads L. Explain the apparent disagreement without changing any chain state. The screen is displaying retained historical evidence; the runner observes the restored state. Repair the labelling and observation path before claiming a computation defect.
Back to contents · Next section
Frequently asked questions
Is a public testnet private because its assets are for testing?
No. Treat published data as potentially public and retained. Synthetic assets do not protect real information or authenticate a website asking for it.
Which named testnet should I learn about?
As checked on 12 October 2026, Ethereum’s network page assigns Sepolia to application development and Hoodi to protocol and validator testing. These are dated roles, not permanent availability guarantees. Consult maintained official documentation before any separately authorised practical project; this worksheet needs neither network.
Can every reset erase files and indexers too?
No such general rule follows. State exactly which component is restored and inspect the behaviour of the actual tool and surrounding stores. Our toy deliberately keeps O outside the reset.
What should come after an environment experiment?
Use the defensive testing lesson to design properties and negative cases. Use the pilot acceptance lesson when deciding whether a larger system has met predeclared gates. Selecting an environment is a different task from passing those tests.
Back to contents · Next section
Sources and further reading
- Ethereum networks: network separation, practice-account caution and dated testnet purposes; checked 12 October 2026.
- Geth developer mode: page last edited 29 May 2024, checked 12 October 2026; single-node development configuration, not a whole-application isolation guarantee.
- Hardhat 3 EDR simulated networks: fork dependencies, configured state and development block production; checked 12 October 2026. No installation commands, secrets or live defaults are reproduced.
A successful practice result becomes useful when another reader can say exactly where it happened, what was controlled and what the experiment never tested.