Musings on future design patterns for Alarm

This has been an inspirational week.  Devcon1 has been one of my first opportunities to have in person conversations about Ethereum and Alarm with people who are familiar with the subject matter.  It isn't surprising that I've had a few great ideas come out of those conversations, and I'd like to share them with you.

Separation of Data

@peterborah's talk on Contract-Oriented Programming got me thinking about a data portability as Alarm matures.  One of the unsolved problems thus far with Alarm is managing support for older deprecated versions of the API.  Those contracts will live on forever and in theory, it would be ideal for any calls that happen to get registered with them to be just as important as calls registered with the newest version of the service.  In reality, it's hard to know how that will play out.

I currently have a command line utility embedded in the the main Alarm source code that can be used pretty painlessly to monitor and execute scheduled calls.  Part of my development roadmap is to provide thorough documentation on how to use this package, and as part of that, I can potentially spend a bit of extra time making it support all of the legacy versions of the API.  This however, isn't a very scalable solution given that I expect there to be many more iterations.

The solution outlined in the talk requires a privileged function call to transfer the ownership of the data model contract onto the latest version.  For me to maintain the trustless nature of Alarm, this isn't a possibility.  The idea however got me thinking about the concept of exporting the data.  While it isn't possible for an already deployed Alarm service to learn about a newer version of the API, it is possible for a new version to be deployed with full knowledge of the old versions.

So, in the next version of Alarm, there will be a new export function which takes a call address, validates it is one of it's official addresses, and reports it to the new version of the service.  This mechanism helps solve data migration in a trustless way, as there the new version of Alarm can trust that any data coming from the old version is the original data.  This does however still leave the problem of call contract ownership.  Each call contract will only accept execution from the main alarm service, which currently only accepts execution from the proper member of the call pool.  This leads me to my second idea.

No More Caller Pools

The caller pool idea originated from a problem that showed up late in the original development.  Call execution must be profitable.  For example, if instead of a caller pool, the Alarm service just worked on a first execution wins model then economic problems start showing up for the incentives for callers to perform the execution.  Suppose there are 3 people competing to execute scheduled calls and the payments involved for doing so.  We can suppose that they would each have an equal probability in executing each call, meaning that 1/3 of the time they would be paid for their service, and 2/3 of the time they would not come in first, and thus would not be reimbursed for their gas costs.  For this to be profitable, that means that the payment must be 3x the cost of a failed attempt.  The result of this is that initially, as more call executors compete, the price for scheduling a call increases linearly with the number of people competing.  This essentially drives the cost up for those who want their calls scheduled while not increasing the profitability of call execution since the extra money is going towards paying for transactions that did not actually produce any value.

The caller pool fixes this by removing the competition in favor of having people commit to executing calls by putting a bond up.  While functional, it isn't an ideal solution as it implements a *lot* of complexity in managing the bonds and pool membership.

Alex Van De Sande had an excellent idea about how to fix this.

When a call is scheduled, instead of specifying a fixed payment amount, the scheduler will specify a maximum payment amount.  Then, starting a few hundred blocks before the scheduled execution time, anyone may bid on call.  The window for bidding will close somewhere shortly before the scheduled execution time.  At the time of the call, the bidder with the lowest bid will be given the first window to execute the call, and the next lowest bid the second window, and so on.  Each bid will be required to put down a deposit with their bid, and anyone who fails to execute the contract during their call window (assuming it hasn't already been executed) will not only be rewarded with the payment, but will also be rewarded with some portion (or all of) the bond that was put up by the previous bidders who didn't do their jobs.

This eliminates the caller pool, and removes the need for the executing transaction to come through the main alarm contract since the bidding can all occur on the call contract itself.  With the need for the call to originate from the main alarm service, this also means that a call contract can easily be exported to newer versions of the alarm service, fixing the data migration problem.

No more Suicide

The final bit of inspiration came from chriseth's talk on solidity contract writing.  There are some unfortunate side effects of suiciding a contract that I had not considered.  One is that it can result in unintended destruction of ether, if anyone sends it a transaction (with ether) after it's been suicided.  Ultimately, suicide was an easy mechanism for returning the remaining funds to the scheduler, but this has made me realize that it is better to just send them back, and then disable the contract entirely.  This way, all of the call information is preserved on the chain, and anyone who accidentally sends a transaction to the contract containing ether won't lose it.

Less fully formed ideas.

I've had a number of other ideas but they are less fully formed, and I am less sure they are good ideas.  Here they are in their infant form.

Tokens?

How can a token based system improve the service?  Tokens are one way to remove the fee system and instead introduce a more public ownership model.  Tokens could be created on each executed call as well as placing a small percentage of the payment into a central pool.  This could be thought of as dividends being paid to shareholders.  I'm honestly unsure of the specifics of how such a system should work, or whether it improves the service in any way.

Crowdfund?

I've struggled with two seemingly conflicting goals.  One is to have the service be trustless and something that can be considered public property.  The other is that I wouldn't mind making a living off of the work that I put into it.  Originally, the service had a hard coded fee that was sent to my ethereum address.  My most recent release, changes this to be non-compulsary, allow my fee to be set to whatever value a scheduler chooses.  One possible way to remove this entirely is to crowdfund the project and sell *shares* in the service.  Then, instead of having my address hard coded into the service, the funds could be distributed to the shareholders.

Again, I'm unsure of whether this idea improves the service in any way, or whether it's even something that people would invest in.

Last Thoughs

Ultimately, I want to do things that allow for Alarm to be a pillar that other applications can build on, knowing that it will serve the ecosystem reliably for many many years to come.  Because of this, I won't be doing anything that I'm not 100% sure moves the needle in this direction, and specifically I won't be doing any of the high level ideas (tokens, crowdfunding) without expressed community support.