Event Handlers

robmyers

Is it possible for a contract to handle events other than transactions?

For example can a contract check the current block number on every block and change its state in response to that?

mids106

No, there is an unofficial & unimplemented ALARM opcode that might be able to let you do this in the future. But no guarantees that this will ever be implemented:
https://forum.ethereum.org/discussion/comment/4047/#Comment_4047

Until then you could rely on a third party to send your contract a transaction every block. If you pay them a little reward each time, with bonus points for consistent calling, they might just do that.

robmyers

I can see how alarms might be a burden if lots of contracts are endlessly sending themselves notifications they don't really need. At the same time it does remove some agency from contracts that they cannot initiate actions themselves.

A cron contract makes sense. It would just need triggering externally, which pushes back the problem of agency one contract.

I considered having the contract perform some tickle code whenever it receives a transaction (like the cron substitutes for web apps...), but if a contract isn't called very often that doesn't work.

I guess that for the scenarios I have in mind, it's enough for the contract to advertise when a particular transaction will be valid/responded to (e.g. after block XXXXXXXXX). I wonder if there are any scenarios in which actions cannot be converted to promises in this way.

nejucomo

For a contract design I was working on I realized that it can always update state "lazily" based on the block height during current message processing. That makes me wonder if this is always possible in every case where ALARM might be used (ignoring gas differences). Any thoughts?

The problem for my contract case is that it needs to do more work if many blocks have past, making the transaction use more gas, thus introducing a tragedy of the commons. Actually in this contract it's not quite ToTC, but rather more like a "game of chicken": If *no one* sends a transaction before a block height, they all lose, but whoever sends the first transaction pays more gas.

I'm quite baffled as to how the Ethereum ecosystem performance will look once I begin to realize these kinds of incentives and race conditions. Contracts with "first sender" incentives, contracts with "game of chicken" issues, contracts with transaction ordering dependencies at the sub block level... these may all produce pathological bursts of traffic and perverse mining incentives. I'm excited to see how this pans out.