v0.4.0 Deployed

I've just finished deploying the 0.4.0 version of the Alarm clock service.  The contract can be found at 0x07307d0b136a79bac718f43388aed706389c4588

Updated documentation available here

This release is largely centered around a major refactor of the contract code to make heavy use of libraries.  0.3.0 introduced the use of Grove to store the call ordering.  This was however accomplished by actually calling out to a separately deployed contract.  Alarm now uses GroveLib as a library allowing it to operate on the Grove index in local contract storage which reduces some of the overhead involved.  Previous releases have had the CallerPool exist as a separate contract.  This functionality has now been factored out into a standalone Resource Pool Library.  This also reduces the overhead involved with Alarm's interactions with the pool, reducing overall gas costs.

The big improvement this has provided is modularity.  Previous releases have deployed at within a few thousand gas of the pi-million gas limit, and only after some work to get them under that limit by removing things like logging statements.  The current Alarm contract is really just a shell that wraps functionality deployed in library contracts.  This has reduced the deployment gas cost to 2,575,605 which is the first time that this project has had breathing room to think about adding new features.

I've got some major improvements lined up for the next few releases.  In no particular order, I'll be working on the following things.

  • Eliminate the need for maintaining an account balance with Alarm.   Instead, provide the gas money you'd like for a call and the un-used portion will be returned to you after the call has been executed.
  • Custom payment amounts for scheduled calls.  Schedulers will have the ability to increase the payout amount that the executor of the call will receive, allowing schedulers to provide increased incentives for executors to execute their call.
  • Remove the maximum gas limit requirement.  Schedulers will be able to provide whatever gas money they would like, as well as possibly a gas hint for the executor to suggest a gas amount that is appropriate for the call.  Currently, the pattern of having call executors send transactions with their gas set to max has proven problematic as those transactions are less likely to be included in blocks in a timely manner.

Once these have been address, I'll plan on starting into support for scheduling a call at a specified time, and recurring calls.