Feature Request: message scheduling queue

What if a contract needs periodic behavior outside of "external" transactions?

An example might be a smart contract transaction which cancels due to a timeout at a certain block height. This could be an important building block for Atomic Cross-chain Trading (see https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ).

Another example might be periodic disbursement of funds in a contract representing a trust.

A brainstormed serpent call would be:

msgLater(blockheight, to, value, gas, datastart, datalen) // with no return value.

An implementation I can imagine requires adding a priority queue [ (blockHeight, pendingTransaction) ] to the world state, along with the { address -> account } mapping. The pendingMessage entries could include gas which is deducted from a contract (or external agent) immediately on a msgLater opcode. Miners apply these transactions when the block serial number reaches the given blockHeight, and the application is marked by moving the transaction out of the queue into the canonical transactions list of the block.

If there is insufficient gas for a miner's taste, I'm not sure what should happen.


  • mids106mids106 Member Posts: 188 ✭✭✭
    There is an (unofficial) specification for ALARM. Note that this is not yet implemented and can change at any time. However this looks like what you are looking for.

    NOT YET: ALARM -6 +1
    Registers for delayed execution a call where:
    The recipient is given by S'[0], when interpreted as an address.
    The value is given by S'[1]
    The gas (to convert from ETH at the later time) is given by S'[2]
    The number of blocks to wait before executing is S'[3]
    The input data of the call is given by T'[ S'[4] ... ( S'[4] + S'[5] - 1 ) ]
    (Thus the number of bytes of the transaction is given by S'[5].)
    Total gas used now is S'[3] * S'[5] * deferFee.
    Contract pays for itself to run at the defered time converting given amount of gas from its ETH balance; if it cannot pay it terminates as a bad transaction. TODO: include baseFee and allow miner freedom to determine whether to execute or not. If not, the next miner will have the chance.
  • nejucomonejucomo Member Posts: 40
    Thanks! Where did you find this specification text?
Sign In or Register to comment.