Smart Contract Execution Animation

Trace a smart contract call from signed transaction to deterministic execution, receipt, and finality.

animation
blockchain
smart-contract
architecture
iot-security
Interactive smart contract execution lab for IoT scenarios with staged animation, gas/resource estimates, transaction failure modes, oracle boundaries, state deltas, receipts, and mobile-ready learning support.
Smart Contracts IoT Oracles Gas and State Receipts

Smart contract execution is deterministic state transition, not hidden automation.

Follow one IoT-triggered transaction as it is signed, checked, executed by the contract runtime, committed to state, and made final by the ledger. Switch scenarios to see rejection, reverted writes, gas exhaustion, stale oracle data, and unsafe callback risk.

Executedtransaction result
0 gasgas or resource used
0 ETHfee estimate
0 sconfirmation wait

Smart contract execution controls, stages, and learning support

What moves

The transaction token crosses the boundary from off-chain IoT evidence into the ledger runtime, then becomes a receipt.

What changes

Only committed state slots and receipt logs survive. Reverted execution consumes resources but does not keep storage writes.

What to compare

Watch gas limit, storage writes, oracle freshness, and confirmation rounds. They decide whether the design is affordable and timely.

Common trap

A contract cannot directly poll a sensor or web API. An oracle or gateway must submit signed data as transaction input.

1. Observe

Device or gateway measures an event and prepares call data.

2. Sign

A wallet signs the transaction so nodes can verify the sender.

3. Precheck

Nodes reject invalid signatures or senders that cannot pay fees.

4. Execute

Every validator runs the same contract code with the same inputs.

5. Commit

Successful execution writes state and emits logs in the receipt.

6. Finalize

Consensus or ordering makes the included transaction hard to reverse.

Execution Trace

Sensor escrow payment

A signed gateway reading releases escrow when an IoT condition is satisfied.

Smart contract execution pipeline A transaction moves from IoT event through signing, node precheck, contract VM, state commit, and consensus receipt. IoT event sensor or oracle temp 9.2 C Signed call nonce + calldata submitReading() Node check signature + balance accepted Runtime VM deterministic code checking require() State delta storage + logs 2 writes Receipt status: success 6 confirmations All validating nodes replay the same inputs 7 validators/orderers, BFT tolerance 2 External sensor data is already inside the transaction calldata. TX

Transaction envelope

call submitReading(batchId, temp, signature)

State transition

Storage writes2 slots
Events kept2 logs
State deltacommitted

Receipt snapshot

Statussuccess
Gas used0
Block/orderpending

Executed

The transaction passes precheck, contract requirements pass, state writes commit, and a receipt records gas and logs.

Gas/resource budget0%
Gas modelEVM-style
Finality modelL2 rollup

Scenario

Network profile

Execution budget

Ledger timing

Execution conditions

Formula and units

This lab uses an approximate EVM-style gas model for teaching. Exact costs vary by chain, fork, opcode path, storage warm/cold access, and L2 pricing rules.

gas_used = base_tx + calldata + reads*read_cost + writes*write_cost + compute_steps*step_cost + events*event_cost + transfer_cost

fee_eth = gas_used * gas_price_gwei * 10^-9. Confirmation wait is modeled as block_or_order_time_s * confirmation_rounds.

Failure meanings
  • Rejected before execution: invalid transaction signature or sender cannot pay fees; no contract state changes and no on-chain receipt.
  • Failed require: contract code runs and reverts; state writes and logs are not kept, but used gas/resource units are charged.
  • Out of gas: execution stops before commit; writes revert and the transaction consumes the supplied limit.
  • Risky success: execution commits, but a missing guard or stale oracle boundary creates a design risk.
IoT design checks
  • Put raw high-rate telemetry off-chain; anchor hashes, summaries, or breach events on-chain.
  • Have gateways or oracles sign sensor evidence before contract execution.
  • Separate immediate control loops from ledger settlement. Block finality is rarely fast enough for real-time actuation.
  • Validate impossible sensor values before submitting irreversible economic actions.
Technical accuracy notes
  • Smart contracts are replicated programs: validators re-execute the same deterministic bytecode or contract logic.
  • Contracts do not directly call arbitrary web APIs or read sensors. External facts arrive through transactions, gateway signatures, or oracle reports.
  • Receipt logs are part of execution results. If execution reverts, logs emitted on the reverted path are not kept.
  • Ethereum gas terminology is platform-specific; permissioned ledgers may use endorsement, ordering, and resource quotas instead.