The narrow case - scheduling based on time.
Sometimes you want to create a transaction that will not be executed until some future date. This will be a common use-case with smart contracts, whenever the contract is initiating a Time Bounded activity you will probably need some action to happen at the end of the time period.
Example 1: An auction that runs for 24 hours, at the end of the time period the auction should be settled; the coins are transferred from the winning purchaser to the seller.
Example 2: Options contracts run for a period of time, at the end of that period the option is settled; if the option is in-the-money the option writer pays the holder what is due, the remainder is returned to him.
Whenever there is time based settlement, you want contract execution (ie. a transaction) to happen at a future date. Relying on an actor to manually initiate, is not a nice solution.
Bitcoin implements absolute time based scheduling very simply in it’s base protocol using the CHECKLOCKTIMEVERIFY opcode, which takes either unixtime or blocknumber.
Bitcoin also implements relative time based scheduling using the CHECKSEQUENCEVERIFY opcode.
How does Ethereum deal with this issue?
There is no scheduling in the base protocol, so it has to be done outside somehow. Of course you can just write your own scheduler to do this, but then you are taking a process which was totally decentralised and sticking a centralised bit on the end, compromising the whole thing.
The best solution I have seen so far, is something called the Ethereum Alarm Clock. These guys have attempted to decentralise the scheduling of transactions using a network of Time Nodes and a smart contract. You request a “scheduled transaction” with certain parameters, this creates a special smart contract instance that can only be called at the time you specified with the parameters you specified. The network of Time Nodes is looking for these contracts to execute, for which they are paid a bounty that was locked in when the special smart contract instance was created. Of course there is no scheduling in the base protocol, so all the Time Nodes try to execute the same contract as soon as it becomes due, the winner gets the bounty, the rest lose some gas in their failed attempt to execute. I hear they are going to redesign their system to use some kind of proof-of-stake to determine what Time Node’s turn it is to execute contracts. It’s all very clever. It requires a team of 8 people. https://chronologic.network They even have their own t-shirts. https://blog.chronologic.network/chronologic-developers-to-hack-at-ethberlin-d578f3e09e72
All for something Bitcoin does 100% decentralised with a single opcode.
This is what happens when the wrong thing is in the wrong place. The base protocol should be as slim as possible but not too slim. I think scheduling needs to be in the base protocol.
When I open my auction, I should also be able to specify when and how it will settle.
Obviously this needs to be thought through carefully. The main problem I see is with the way gas works, because gas price is always “spot”. I know what the required gas price is right now, I do not know what the gas price will be in a months time. Ideally I would be able to pay now for service later, like a postage stamp. Or perhaps it could work like a collect call, where the transaction is billed against a specific account. For sure this requires careful thought.
The broad case - scheduling based on events.
Smart contracts should be able to model real world activity, many of which have duration; they have a start and an end. Sometimes that end point is known in advance, other times it is not. Time based scheduling is really just an instance of the more general case of event based scheduling.
Example: I am selling tokens on a first come basis. There are 100 tokens to sell at fixed price. When the last token is sold the sale is over. At the end of the sale I have to do a really big computation.
Ideally my “close of sale” computation should happen automatically on the sale of the last ticket. Right now that is not possible, unless you make the last purchaser pay for the huge computation. Really I want to pay for the huge computation and have it automatically triggered upon sale of the last ticket.