Hello,
I just started using Ethereum and Solidity. For convenience use the events as provided in Solidity a lot, rather then return values in functions.
Our front-end application (Javascript, using web3) subscribes to the events. Since on startup all events since the beginning are re-emitted the current state can be derived.
We just realized we don't have to actually store very little, and probably no state in the contracts itself. So the ethereum-blockchain would in fact become a event-store.
What are other people experience on using the event feature in Solidity? Are there plans to extent the functionality? Maybe allowing contracts to subscribe to events as well, besides emitting them?
2 ·
Comments
If you could walk me through a simple scenario I would really appreciate it. Say for instance, I want to submit a thousand transactions each containing a small text string of metadata to a contract (each of these transactions are originating from a different address). How could the metadata be translated into an event/s? How would I aggregate and search through the discrete metadata entries later?
Is there any benefit to using an event tied to a contract over just sending transactions to a specific address and then using a block explorer to search through all the transactions that went to the address? In the case mentioned above I don't have any way to search for the transactions other than they were all sent to the same address.
Thanks for your help!
You can filter by the indexed items in AddMsg, of which you can have up to 3.
hex2a is just a quick func to turn the bytes32 into a string since I wasn't passing string msgs.
Two small typos:
Also - use web3.toAscii rather than a custom hex2a. Didn't spot that until yesterday
Also, if you use indexed arguments in your log you can search for specific items rather than making a node return all the logs.
I have a question ... when monitoring logs, I want to stop monitoring when I hit the current block (and then, in a few minutes, run a script again to catch up from where I left off).
I'm trying to figure out how to know when to stop.
Be aware that the blockchain can reorganise itself so the results may not be 'true' or could change somewhat underneath you.
I had initially assumed they would stay put, but the recent mention of old block data becoming inaccessible is making me wonder.
Blocks could become invalid because of forks. So maybe the clients should handle invalidation of events too, when a certain block (number) becomes invalid. Not certain how to implement that.
In our (still in development-phase) code, each clients tracks for each event the blocknumber of the last received event. When the client restarts, it'll start listening from that blocknumber to avoid getting all old events again. We haven't added anything to handle forks though.
I've created a gist with our (very preliminary) event handling: https://gist.github.com/gerbrand/cffdc118fef997d9bde6
In our implementation the events are typed, rather than having a general message type as in @sillytuna example. I guess untyped messages are more convenient, as message in various event-libraries are usually untyped too.
Might be interesting to convert into a OS project. Something like Ether Event Store?
https://forum.ethereum.org/discussion/comment/14362/#Comment_14362
@gerbrandvd In my code I'm actually using typed messages based on a bytes32 string.
re: Block changes. I haven't coded for this yet and I'm not entirely sure of the best way to catch inappropriate blocks. In general terms, I wouldn't consider a block valid for 12 blocks, so anything in the interim is pending data.
This implications if you're sending ordered transactions to a contract because I guess they can be accepted in any order, the order could change if the chain you were on is superseded, and you need e.g. 12 blocks to be sufficiently sure.
Does anyone know what happens with event reporting if the event was first reported on chain 1, then that chain becomes superseded and a more recent block has the same 'event'? I guess you get the same event again although it'll only be in the blockchain once.
My colleague just suggested only looking for events and calling contracts 12 blocks away from the current block if providing accurate results, and using the most recent block for pending results.
I guess the 12 blocks is arbitrary? I guess for each new block, the chance a certain block in the past gets exponentially smaller. What would the chance be 12 blocks in the past would be a fork?
*Update in case someone later reads this message: Reason was nonce was not always unique for call-transactions. Not certain what the root cause is, might be related to web3. Back on topic