In this track: Execution traces and low-level calls
advanced · 4 MIN READ
Transaction context versus call context
One transaction can contain several message-call contexts.
LET’S PICTURE IT
A single project can involve several workers, each with a different immediate supervisor.
SEE IT FOR YOURSELF
A valid counter call, step by stepStep 1 / 4
This example begins with count zero and a request to call increment(). No real contract is deployed.
This example begins with count zero and a request to call increment(). No real contract is deployed.Execution follows the code’s input and permission rules. A website button is not the access-control mechanism.The function reads zero, calculates zero plus one, and writes one to persistent storage.The accepted state contains count one. Later reads can inspect it. Events are emitted only if the code implements them.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Identify the outer request
A transaction has a sender and transaction-wide context. Executing it can create a tree of calls, rather than one uninterrupted frame with identical local inputs.
Identify each frame
A frame has its own executing code, call input, memory and immediate caller context. Nested frames can operate on different storage owners depending on the call kind.
Separate shared and local information
Some facts originate from the surrounding transaction while others change at each call boundary. Treating every caller field as the original transaction sender loses that distinction.
Write a context table
For a trace, list code address, storage address, caller and value for each frame. This makes ordinary calls and delegatecalls easier to distinguish.
Follow the execution
Transaction: User → A
Frame A: calls B
Frame B: calls C
One transaction, three contract frames.
A local conceptual trace with explicit assumptions; this is not a trace of a live transaction.