Ethereum Alarm Clock
ethereum-alarm-clock.com
ethereum-alarm-clock.com
Its one of those things that you need some background on Ethereum to understand, but if you understand Ethereum you know why something like could be the cornerstone of a lot of apps.
a) What this is. b) Why it's valuable.
Contracts expose functions as an API that others can use to interact with them.
A contract is a group of functions that live in the Ethereum Blockchain (a distributed virtual machine for running decentralized applications)
> Why would people want one called periodically?
For the same reason people need cron to call periodic functions.
Does that mean that if 'market conditions' deteriorate or make it unfavorable to 'take the job' as it were, that the reliability of this system would take a hit?
The market aspect is more akin to a marketplace where people are hired to do a job. And the job is entirely automatable.
I'm just thinking this is really loosely tied system, and it's interesting to think of all the possibilities for how it could break down.
You are correct that it would be an interesting world if somehow demand for scheduled call execution spiked to some massive number that outpaced the ability to execute them. I am having trouble thinking of realistic scenarios where that happens but that doesn't preclude it as a possibility.
Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.
I guess because they aren't aware of the precursors.
"What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code."
The banks that are talking about blockchain technology for settlements have a better handle on this. If bond ownership transfers are actually recorded through a transaction on the bond blockchain, then you could have offers, acceptances, contracts, and verified deliveries without a trusted back-end service.
Conceivably you could put a music or video download service on Etherium, where you got a crypto key to unlock the content by paying for it. But Etherium can't tell if the key you got was any good, or that the file it unlocks was what was ordered.
Does someone have a convincing use case for this thing?
Outsourcing function calls to 'trusted' providers is brilliantly interesting, and a terrible, terrible idea.
What if this used for trading purposes, e.g. price reports from an exchange?
"We had a hiccup with processing USD and EUR prices, and briefly crossed them with this code push, sorry. Everything is back to normal now."
While it's easy to imagine how you'd use this as a trader, I think my fundamental disagreement with the idea is that you are expanding your threat surface for anything that consumes data from 'trusted' providers. That seems almost impossible to be a good idea.
Mitigating this risk with, e.g. multiple 'trusted' providers reduces to the problem bitcoin mining solves in the first place.
I think I would have a more informed opinion if you detailed a sample application consuming this; I'm not trying to shit on what was undoubtedly very solid work putting the service together, but I'm very dubious about the breadth of useful services that wouldn't have unacceptable risk profiles.
Most of the other potential applications it's easy to argue that they could set up their own incentives to get some user in the system to execute the call. (lottery payout, scheduled trade, crowdfunding payout, etc).
I think that yes, each of those applications has a viable way of motivating some party to execute the call. However, if a service like Alarm proved to be very reliable, it may be simpler to just automate it with a scheduling service. Scheduled or recurring execution doesn't have to be the only solution to a problem for it to still be a good solution.
If I were running it, I would still make strong recommendations that recipients of the alarm 'ping' only execute idempotent functions which do not rely on any data from the ping itself, or on the ping being executed implying any state anywhere in the world, whether on blockchain or not.
Here's one example: Augur (http://www.augur.net/) have already released an alpha of their fully decentralized prediction market. With bitcoin someone could run a prediction market, pools payments and pay out to winners. With Ethereum you will be able to send cryptocurrency directly to a contract that manages the bet and pays out to the winners, based on some prearranged signal source.
Under no circumstances should Ethereum Alarm Clock be used as the signal source for Augur's "signal source" / adjudication on prop bets.
Just saying it shouldn't be used isn't very constructive.
Edit:
If I make some assumptions about why you think it's a bad idea then I would guess it is that you think the call executors can behave badly in some way. The way the call execution works is that as long as there is at least one honest caller, then calls cannot be censored. Call execution is a binary operation as the executor can't control the call data. So the only thing a call executor has control over is whether or not they execute the call. Even in the situation where some attacker represents a large part of the caller pool, there is a section during the last part of the call window where anyone may execute the function call in exchange for a large payout. So even if an attacker is operating 99/100 of the accounts executing function calls, that 1 honest person can execute the call if everyone else chooses not to.
Augur must in some way be designed to get information from outside the blockchain, unless it only allows prop bets about things directly observable inside Ethereum.
Therefore, part of the risk model for someone making a prop bet with Augur is that a trusted and verified third party at some point tells the Augur contract e.g. "Carly Fiorina did not win the Republican Nomination."
All those who transact with Augur have to reason about the trustworthiness and risk model for the parties that inform the Augur contract. This is how I interpret the idea of the "signal source" in the comment above.
To restate what I said above, under no circumstances should Ethereum Alarm be used to trigger the "Carly Fiorina did not win" action for a prop bet. It's too risky; we have to think about and validate the risk profile for someone cheating.
What I'm guessing you're imagining is that it would be fine to instrument our prop bet contract in such a way as to say "If our trusted Augur oracle has deemed this prop bet decided, be available for Ethereum Alarm to trigger the payouts".
That seems fine to me, and given the limitations in how Ethereum works, makes sense as something valuable to the creators of the prop bet markets.
My larger point, poorly stated at the start, and I would say that I at least am beating a dead horse now, is that it would pay good safety dividends for neophyte Ethereum devs to get some suggested rules about using the Alarm.
This is a great point. I think a list of dos/don'ts, design patterns, and examples of complete systems built with Alarm would be very useful.
> To restate what I said above, under no circumstances should Ethereum Alarm be used to trigger the "Carly Fiorina did not win" action for a prop bet. It's too risky; we have to think about and validate the risk profile for someone cheating.
I don't think this is possible: you could trustlessly trigger an "It is 5pm EST November 11 2015" bet via Ethereum Alarm, but not anything more complex. This might be useful for betting on the apocalypse happening or not happening, but not much more.
>What I'm guessing you're imagining is that it would be fine to instrument our prop bet contract in such a way as to say "If our trusted Augur oracle has deemed this prop bet decided, be available for Ethereum Alarm to trigger the payouts".
IIRC Augur includes a semi-decentralized reputation oracle where each bet has a pool of oracles, each with a reputation maintained by Augur on the ethereum blockchain, that are paid some percentage of the total bet value. Anyone can sign up as an oracle, but to get to a reasonable reputation (and payout amount) you need a consistent reputation for correctness (or at least consensus).
The Alarm service supports designation of certain addresses as authorized
schedulers. Contracts can trust authorized calls were scheduled by an address
that they authorized, allowing you to schedule calls to functions that would
normally not be publicly callable.
I'm not sure if your code allows such a thing or not, either specifically, or just by assumption in the original contract ("Only my trusted callers will be able to call this, and I can therefore rely on them for indication of some event happening")
Timestamping trades clearly is not the use case for this. Don't blame the tool but he who uses it in the wrong way...
I believe all engineers have a responsibility to adjust design for risks, especially unintended use cases.
Most engineers would generally agree with this principle, although I have found software engineers tend to be a little more lax than, say civilian engineers.
Guarantees - Will the call happen?
There are no guarantees that your function will be called. The design of this service is meant to provide the proper motivation for calls to be executed, but it is entirely possible that certain calls will be missed due to unforseen circumstances.
This is a fundamental limitation of the network as opposed to a shortcoming of the service. When you submit a transaction, it is up to the miners as to whether it gets included in the next block. There are lots of factors that go into this decision, and in normal situations, transactions are going to get included in a block very quickly.
If you accept the assumption that there are enough people executing calls (in exchange for $$) and that the network is not so flooded with transactions that miners are having to exclude them due to volume, then the likelihood that your function won't be called drops near zero.
If the network is congested with too many transactions, then it doesn't matter if the call was triggered by the alarm service or somewhere else, it will still have to compete to be included in a block just like any other transaction.
Now if you want to talk about selective censorship of function calls, then that is an interesting attack vector that I'd love to chat about.
Since the caller gets rewarded for making the call, the incentives should be in place to make things work without any need for centralization.
Since there is no way to reject a transaction, every person who attempts to execute a scheduled call will have to pay some small amount for the transaction. If the service is implemented as a first call wins sort of thing, then all of the people who tried and failed would be out the gas cost of that transaction. For calling contracts to be profitable, these costs would have to be covered somehow, otherwise there is no incentive for people to execute calls.
So, this cost would have to be offloaded onto the people scheduling calls which would cause a significant increase in the overhead of scheduling a function call.
The alternative solution I came up with was having a caller pool. The people executing the calls are guaranteed a window of time where they can call the contract and also incentivized (by their bond) to fulfill that duty lest the next person in the pool claim their bond.
I'm open to alternate solutions to this problem.