I just do not understand why emit Event(...) is cheaper than a = b. The only difference I noted between events and storage variables is that event logs is not accessible from Solidity. But both of them are stored in blockchain and both of them are accessible from external applications. So why have etherium devs made SSTORE so expensive?


emitting Events makes use of a log storage, which as you've noted is a 4th form of contract information that is much cheaper than the other three kinds of accessible from solidity (memory, storage, stack). EVM nodes are not required to keep logs forever and can garbage collect old logs to save space. Dapps listening for these logs cannot rely on them being persisted forever (e.g. really old events), but can probably listen to new events as a means of updating on changes.

My favorite article about EVM events / log storage is here https://blog.qtum.org/how-solidity-events-are-implemented-diving-into-the-ethereum-vm-part-6-30e07b3037b9

Although I don't know the exact rationale of the EVM designers, I would guess they wanted to provide a cheap, but not free, way of storing information from contracts and publishing notification information for outside listeners (not on the blockchain). Free storage would be open to abuse / denial-of-service attacks.

In particular from the article, we can compare the cost of storing in logs versus storing in storage (the choice of names is mildly confusing and regrettable, but what can you do). That would address your question of LOG versus SSTORE opcodes.

Don’t forget the memory used, which is 3 gas per byte:
MemoryGas        uint64 = 3    
Wait what? It costs only 8 gas per byte of log data? That’s 256 gas for 32 bytes, and 96 gas for the memory use. So 322 gas versus 20000 gas for storing the same amount of data in storage, only 1.7% of the cost!
| improve this answer | |
  • Are you sure nodes are not required to store logs? In the official doc is said that now (as far as I know, Serenity is not ready yet) logs are stored in blockchain and available forever. – Andrew Aug 9 '19 at 12:05
  • You can always find a node that has the logs you're looking for, or use a public node where logs are guaranteed to be kept (e.g. Subgraph). Since contract state can't access log storage, they would have no way of enforcing/knowing if the node deletes old logs. – Paul Pham Aug 10 '19 at 13:17

The main difference is that events can't change state while variable assignation (SSTORE) can.

State it one of the most important aspects of Ethereum contracts. State can be modified and it can be read. Emitting events does not modify any state (at least not any state which could influence contracts) and basically nobody has to care about the events - they are only for informational purposes for example for backend systems.

Therefore modifying the state has far greater implications than simply emitting an event and that's probably why it's so much more expensive. There are also some differences under the hood in how the data is stored (events vs state) and that may explain some of the price difference as well.

| improve this answer | |
  • So is it okay to store important data via events? This data won't be changed and won't be used inside smart-contracts, but may be read in relation to the id which is stored normally (in storage). – Andrew Aug 9 '19 at 12:27
  • In theory yes but as far as I've understood the logs may get pruned at some point, although clients don't do that yet. – Lauri Peltonen Aug 9 '19 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.