Automated Periodic Function Calling?

jzenjzen Member Posts: 49
Is is it possible for a contract to automatically and periodically call one of its own functions, for example every 500 blocks on the chain? Or would an external call need to be made on a periodic basis to the contract function to achieve the desired effect?


  • StephanTualStephanTual London, EnglandMember, Moderator Posts: 1,282 mod
    edited August 2015
    Afraid not, it would make Ethereum self-aware.

    Kidding - it's called the ALARM opcode but it does have a few issues that needs resolving before we can implement it - check
  • jzenjzen Member Posts: 49
    Great, will the ALARM have a SNOOZE option? But seriously, looking forward to it. Thanks Stephan!
  • berkenberken Member Posts: 3
    edited August 2015
    Until then, perhaps an alarm-clock-as-a-service could be used? It'd be centralized, though.
  • MetalMetal Member Posts: 17
    At the risk of performing minor thread necromancy, has any progress been made on designing this?

    The elephant in the room, as far as I can spot it, is that contracts cannot create transactions. All transactions must be signed, which require a private key. That guarantees that a transaction's existence relies on math rather than mere consensus. No matter how many miners collude, they can never decide that you've just spent all your ether on a pyramid scheme against your will. Even when a contract calls another contract, there's always a base transaction, with a signature, that enables it to happen. In addition, a given transaction may end up changing a bunch of state across a bunch of contracts, but it ends in the same block it started. Nothing else ran in the middle of that transaction, which makes things easy to reproduce across nodes and agree with.

    The ALARM opcode seems to require breaking at least some of this to be implemented.

    You can either decide that transactions can exist across multiple blocks, which would mean that things will run in the middle of your long-lived transactions. It would mean that transactions that did not complete would be entered in the blockchain, and transaction continuations would appear in various later blocks.

    Alternatively, you can decide that transactions can exist without a valid signature. Contracts can start transactions without an underlying spark from outside the blockchain. Network consensus becomes a sufficient mean to make transactions appear. This arguably would make contract balances significantly less secure than (current) wallet balances.

    If I had to pick, the first approach seems less broken, but it's not a small change to do correctly.

    On the plus side, if there's in fact a sane design that allows an ALARM opcode to exist, then we could have more asynchronous callback mechanisms baked in the EVM (such as the ability to listen for topics appearing in transaction logs..)
  • sillytunasillytuna Member Posts: 38 ✭✭
    edited September 2015
    Been working on the same thing with several more features conceptually. PMed about a collaboration.

    I'm looking at dealing with time (blocks, UTC), running out of gas and needing renewal, on-chain oracles (such as augur, Maker exchange rates), off-chain oracles/transactions via signatures, and in future client-code if/when proof of execution is possible in an on-chain context.

    Basically any situation where external input from a client source can be used definitively.

    We are considering a a tokenised DAO, possibly using Maker or based on the Maker contract framework, with voting to allow contract changes. This would start off being run by the team then graduate to a full token holder voting only DAO. Similarly, profits shared among token holders.

    It's a little fiddly sorting out reward structures so we were writing up a paper and going to get feedback from ethereum and people here in the next week or so.
    Post edited by sillytuna on
Sign In or Register to comment.