الأحداث مقابل التخزين
الموازنة في تكلفة Gas
الأحداث مقابل التخزين درس مجاني في Web3 & DApp Development Fundamentals على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Web3 & DApp Development Fundamentals، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Web3 & DApp Development Fundamentals 4 دروس في المجموع.
بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.
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.
تعلم Web3 & DApp Development Fundamentals مع معلم ذكاء اصطناعي — مجانًا
اكتب وقم بتشغيل أكوادك الفعلية في المتصفح، واحصل على مساعدة فورية من معلم ذكاء اصطناعي متاح 24/7، واستمر من حيث توقفت على الويب أو في التطبيق.
- الدورات
- 29
- الدروس
- 105
الأسئلة الشائعة
هل درس «الأحداث مقابل التخزين» مجاني؟
نعم — نص درس «الأحداث مقابل التخزين» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Web3 & DApp Development Fundamentals، انتقل إلى CoddyKit PRO. تتضمن دورة Web3 & DApp Development Fundamentals 4 دروس في المجموع.
ماذا ستتعلم في «الأحداث مقابل التخزين»؟
الموازنة في تكلفة Gas تتمرن على Web3 & DApp Development Fundamentals مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ Web3 & DApp Development Fundamentals؟
لا تُشترط خبرة سابقة. Web3 & DApp Development Fundamentals على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.
كم من الوقت يستغرق درس «الأحداث مقابل التخزين»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس Web3 & DApp Development Fundamentals هذا؟
نعم. كل درس في Web3 & DApp Development Fundamentals يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- تعريف الأحداث
- المعاملات المفهرسة
- الاستماع إلى الأحداث
- الأحداث مقابل التخزين