Events vs. Storage
Gas-Abwägungen
Events vs. Storage ist eine kostenlose Web3 & DApp Development Fundamentals-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Web3 & DApp Development Fundamentals-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Web3 & DApp Development Fundamentals-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
Two Ways to Record Data
When something happens in a contract you can record it in storage or in an event log. Choosing wisely is a core gas-optimization skill.
This lesson compares the trade-offs so you know when to use each.
Storage Recap
Storage is the contract's permanent state. It is the only data the contract itself can read back later, but writing to it is very expensive.
<code>mapping(address => uint256) public balances; // contract can read this</code>Events Recap
Events write to the transaction log. They are far cheaper, but the contract cannot read them back on-chain - only off-chain clients can.
<code>event BalanceChanged(address indexed who, uint256 newBalance);
// off-chain apps read this; the contract cannot</code>Gas Cost Difference
Writing a fresh storage slot (an SSTORE from zero) costs around 20,000 gas. Emitting a log topic or word costs only a few hundred gas. Events can be an order of magnitude cheaper.
The Golden Rule
A simple guideline:
- Store data the contract needs to read or use in future logic
- Emit data only the outside world needs (history, UI, analytics)
Do not store data purely for display - emit it instead.
What Must Be Storage
Balances, ownership, allowances, and any value used in require checks or future calculations must live in storage, because the contract reads them.
<code>function transfer(address to, uint256 amt) public {
require(balances[msg.sender] >= amt); // needs storage
balances[msg.sender] -= amt;
balances[to] += amt;
}</code>What Can Be Events Only
A transaction history, audit trail, or notification feed is perfect for events. The contract never needs to revisit those records, so storing them would waste gas.
<code>event Logged(address indexed user, string action, uint256 time);
function act(string memory a) public {
emit Logged(msg.sender, a, block.timestamp); // no storage
}</code>Use Both Together
The most common pattern is to store the new state and emit an event describing the change. The storage value drives logic; the event keeps the UI in sync.
<code>function deposit() public payable {
balances[msg.sender] += msg.value; // storage for logic
emit BalanceChanged(msg.sender, balances[msg.sender]); // event for UI
}</code>Logs Cannot Be Queried On-Chain
A critical limitation: another contract cannot read your emitted logs. If contract B needs a value, contract A must expose it via storage or a return value, never via an event.
Avoid Storing for History
A common beginner mistake is pushing every action into a storage array to build a history. This grows unbounded and becomes hugely expensive. Emit events instead and let an off-chain indexer rebuild the history.
<code>// Anti-pattern: unbounded, costly
// historyArray.push(record);
// Better:
emit ActionRecorded(msg.sender, block.timestamp);</code>Decision Checklist
Ask: Does any on-chain code read this value later?
- Yes - storage (and optionally emit too)
- No, it is only for display or audit - event only
This single question resolves most design choices.
Quick Check
Test your understanding of events versus storage.
Recap
You learned the storage vs events trade-off:
- Storage is readable on-chain but expensive (~20k gas per fresh slot)
- Events are cheap but only off-chain clients can read them
- Store what the contract needs; emit what only the outside world needs
- The common pattern: update storage AND emit an event
Never store data purely for history or display.
Lerne Web3 & DApp Development Fundamentals mit einem KI-Tutor — kostenlos
Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.
- Kurse
- 29
- Lektionen
- 105
Häufig gestellte Fragen
Ist die Lektion „Events vs. Storage“ kostenlos?
Ja — der vollständige Text von „Events vs. Storage“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Web3 & DApp Development Fundamentals-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Web3 & DApp Development Fundamentals-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Events vs. Storage“?
Gas-Abwägungen Du übst Web3 & DApp Development Fundamentals mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Web3 & DApp Development Fundamentals zu starten?
Keine Vorkenntnisse erforderlich. Web3 & DApp Development Fundamentals auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.
Wie lange dauert die Lektion „Events vs. Storage“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Web3 & DApp Development Fundamentals-Lektion Code schreiben und ausführen?
Ja. Jede Web3 & DApp Development Fundamentals-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Events deklarieren
- Indizierte Parameter
- Auf Events lauschen
- Events vs. Storage