7 ms·

Ethereum Alarm Clock

94 points by mwilcox 11y ago

joosters 11y ago
Just one minor problem: There are no guarantees that your function will be called. So it's an alarm clock that might not work.
- dangero 11y ago
  Is this because of the unknown cost at the time?
  - ludbb 11y ago
    I believe the reference is coming from http://docs.ethereum-alarm-clock.com/en/latest/overview.html#guarantees http://docs.ethereum-alarm-clock.com/en/latest/overview.html...: 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.
    - avmich 11y ago
      Strictly speaking, there is no such a thing as "guarantee". Your alarm clock may malfunction in an important moment. An asteroid can suddenly wipe civilization with all insurance providers (now that's an idea...) So you - in a strict sense of a word - always have to estimate and compare probabilities.
  - joosters 11y ago
    It's because the alarm program relies upon someone calling it at the right time. The code itself does not 'sleep' until the right time.
- llamataboot 11y ago
  room for an insurance contract on the alarm clock call. Libertarians love contracts ;)
- pipermerriam 11y ago
  I'm the author of the service. 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.
vessenes 11y ago
So often Ethereum straddles the line between brilliant and terrible idea. 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?
- pipermerriam 11y ago
  I'm curious if you would expand on why this is a terrible idea.
  - vessenes 11y ago
    1) Get trusted 2) Wait until your function is used a lot 3) Lie, ideally in a plausibly deniable way. 4) Profit. "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.
    - pipermerriam 11y ago
      * Recurring and Scheduled payments. On the first of every month, the alarm service pings my wallet to pay my utility bill. 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.
rubicon33 11y ago
This sounds interesting, but I'm not sure I really grasp what it 'is'. Can you explain what this it to me, as if I were 5 years old? I really struggle to understand two things: a) What this is. b) Why it's valuable.
- pipermerriam 11y ago
  On Ethereum there is no built in way to have a contract be called periodically, say every 5 blocks, or at a specific time in the future. This contract creates a market which allows contracts to hire people to call them at the requested time.
  - mmanfrin 11y ago
    What is a contract, and why would people want one called periodically?
    - pipermerriam 11y ago
      A contract is the term for an application that has been deployed on Ethereum. Contracts expose functions as an API that others can use to interact with them.
    - joeyspn 11y ago
      > What is a contract... 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.
      - deleted 11y ago
        [deleted]
  - calinet6 11y ago
    > This contract creates a market which allows contracts to hire people to call them at the requested time. 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?
to3m 11y ago
Why is a caller pool required? You don't care who calls your contract, as I see it, nor how reliable they are in general - provided they call your contract at the right time, you're happy! Since the caller gets rewarded for making the call, the incentives should be in place to make things work without any need for centralization.
- pipermerriam 11y ago
  Calling contracts has to be profitable, otherwise nobody would do it. 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.
tonetheman 11y ago
While this site looks interesting enough and even the comments below sort of say the same thing. What is this? I mean really. I look at this site and think. I do not know what this is. And even worse there is nothing on the site that even remotely explains it. Why was it even posted?
- aakilfernandes 11y ago
  Its a cron system for decentralized apps. Since there's no way to run 'cron' trustlessly, this alarm clock creates an incentive to call functions at given time periods. 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.
  - sdoering 11y ago
    Thanks for clarification. I had the same problem as OP and was literary scratching my head.
GPGPU 11y ago
I think if I brought an Ethereum Alarm Clock to school, they'd call the police!
pcl 11y ago
For those of us who are new to Ethereum: 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. https://www.ethereum.org/ https://www.ethereum.org/
- deleted 11y ago
  [deleted]
- CGamesPlay 11y ago
  After reading about this for the past hour or so, I found this to be the most helpful document to understanding Etherium: https://github.com/ethereum/wiki/wiki/Ethereum-Development-Tutorial https://github.com/ethereum/wiki/wiki/Ethereum-Development-T...
  - kristopolous 11y ago
    Great. It's essentially a cluster computing platform with a handful of small permutations on that basic idea. Why don't these people use more accessible language? It would dramatically help increase adoption.
    - bildung 11y ago
      >Great. It's essentially a cluster computing platform with a handful of small permutations on that basic idea. Why don't these people use more accessible language? It would dramatically help increase adoption. I guess because they aren't aware of the precursors.
- grubles 11y ago
  Maybe a more descriptive explanation (from the White Paper[0]): "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." [0]https://github.com/ethereum/wiki/wiki/White-Paper https://github.com/ethereum/wiki/wiki/White-Paper
Animats 11y ago
Ethereum's contract system has no way of knowing whether events outside its little world actually occurred. It can't tell if someone who said they'd send your alarm message actually did so before paying them. There's talk of "trusted intermediaries", but if you have trusted parties, then you don't need Ethereum. 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?

94 points by mwilcox 11y ago

Just one minor problem: There are no guarantees that your function will be called. So it's an alarm clock that might not work.

dangero 11y ago
Is this because of the unknown cost at the time?
- ludbb 11y ago
  I believe the reference is coming from http://docs.ethereum-alarm-clock.com/en/latest/overview.html#guarantees http://docs.ethereum-alarm-clock.com/en/latest/overview.html...: 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.
  - avmich 11y ago
    Strictly speaking, there is no such a thing as "guarantee". Your alarm clock may malfunction in an important moment. An asteroid can suddenly wipe civilization with all insurance providers (now that's an idea...) So you - in a strict sense of a word - always have to estimate and compare probabilities.
- joosters 11y ago
  It's because the alarm program relies upon someone calling it at the right time. The code itself does not 'sleep' until the right time.
llamataboot 11y ago
room for an insurance contract on the alarm clock call. Libertarians love contracts ;)
pipermerriam 11y ago
I'm the author of the service. 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.

vessenes 11y ago

So often Ethereum straddles the line between brilliant and terrible idea. 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?

pipermerriam 11y ago
I'm curious if you would expand on why this is a terrible idea.
- vessenes 11y ago
  1) Get trusted 2) Wait until your function is used a lot 3) Lie, ideally in a plausibly deniable way. 4) Profit. "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.
  - pipermerriam 11y ago
    * Recurring and Scheduled payments. On the first of every month, the alarm service pings my wallet to pay my utility bill. 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.

rubicon33 11y ago

This sounds interesting, but I'm not sure I really grasp what it 'is'. Can you explain what this it to me, as if I were 5 years old? I really struggle to understand two things: a) What this is. b) Why it's valuable.

pipermerriam 11y ago
On Ethereum there is no built in way to have a contract be called periodically, say every 5 blocks, or at a specific time in the future. This contract creates a market which allows contracts to hire people to call them at the requested time.
- mmanfrin 11y ago
  What is a contract, and why would people want one called periodically?
  - pipermerriam 11y ago
    A contract is the term for an application that has been deployed on Ethereum. Contracts expose functions as an API that others can use to interact with them.
  - joeyspn 11y ago
    > What is a contract... 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.
    - deleted 11y ago
      [deleted]
- calinet6 11y ago
  > This contract creates a market which allows contracts to hire people to call them at the requested time. 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?

to3m 11y ago

Why is a caller pool required? You don't care who calls your contract, as I see it, nor how reliable they are in general - provided they call your contract at the right time, you're happy! Since the caller gets rewarded for making the call, the incentives should be in place to make things work without any need for centralization.

pipermerriam 11y ago
Calling contracts has to be profitable, otherwise nobody would do it. 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.

tonetheman 11y ago

While this site looks interesting enough and even the comments below sort of say the same thing. What is this? I mean really. I look at this site and think. I do not know what this is. And even worse there is nothing on the site that even remotely explains it. Why was it even posted?

aakilfernandes 11y ago
Its a cron system for decentralized apps. Since there's no way to run 'cron' trustlessly, this alarm clock creates an incentive to call functions at given time periods. 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.
- sdoering 11y ago
  Thanks for clarification. I had the same problem as OP and was literary scratching my head.

GPGPU 11y ago

I think if I brought an Ethereum Alarm Clock to school, they'd call the police!

pcl 11y ago

For those of us who are new to Ethereum: 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. https://www.ethereum.org/ https://www.ethereum.org/

deleted 11y ago
[deleted]
CGamesPlay 11y ago
After reading about this for the past hour or so, I found this to be the most helpful document to understanding Etherium: https://github.com/ethereum/wiki/wiki/Ethereum-Development-Tutorial https://github.com/ethereum/wiki/wiki/Ethereum-Development-T...
- kristopolous 11y ago
  Great. It's essentially a cluster computing platform with a handful of small permutations on that basic idea. Why don't these people use more accessible language? It would dramatically help increase adoption.
  - bildung 11y ago
    >Great. It's essentially a cluster computing platform with a handful of small permutations on that basic idea. Why don't these people use more accessible language? It would dramatically help increase adoption. I guess because they aren't aware of the precursors.
grubles 11y ago
Maybe a more descriptive explanation (from the White Paper[0]): "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." [0]https://github.com/ethereum/wiki/wiki/White-Paper https://github.com/ethereum/wiki/wiki/White-Paper

Animats 11y ago

Ethereum's contract system has no way of knowing whether events outside its little world actually occurred. It can't tell if someone who said they'd send your alarm message actually did so before paying them. There's talk of "trusted intermediaries", but if you have trusted parties, then you don't need Ethereum. 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?