This question is a development of related questions from existing sources (https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd61e) and prior threads (Do logs/events last forever?, Storing name values off-chain in events and web3.js, etc.) Nevertheless, it appears to raise distinct issues that I have not seen answered:

Events are often proposed as cheap storage that is not accessible to smart contracts. Yet, it seems that event-based storage could be used by smart contracts using the following workflow:

  • At block B: Smart contract S logs an event with data payload D.
  • After block B has been mined: D is available to clients, but not available to S. A daemon can watch for data save events emitted by S and pick up D automatically.
  • At any block after B: Any call to S that requires D for execution can supply D as calldata.
  • If S has security concerns trusting client-supplied D, S can store hash(D) and validate client-supplied D.

(This has some complexities around occasional reorgs that appear tractable, and rare under PoS.)

Does this approach seem viable? If it is viable, doesn’t it follow that events, indirectly, can be used as smart contract storage? Are there any issues with the reliability of this process other than the reorgs?


Your Answer

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

Browse other questions tagged or ask your own question.