Toward or away from network-provided cron service

[anorth]

The built-in Filecoin actors make use of a cron service provided by the chain (via the CronActor) to schedule repeated tasks. Two example use cases for this are checking for the on-time submission of a miner's WindowPost each deadline, and periodically processing payments for storage deals in the storage market.

The "network" pays for the cost of this processing as all validating nodes must perform the computations, but the CronActor enjoys a gas price of zero and no practical gas limit. This restricts its use to actors which the network can trust not to abuse it (which is all of the built-in ones). The processing it performs is a non-trivial part of chain validation cost and grows linearly with network growth and utilisation (until something like Neutron breaks linearities). We do ensure some contortions to ensure that processing is roughly evenly distributed between epochs, and cannot perform extremely long computations at once.

The cron service is very useful as a development primitive. It was introduced in the design of the actors for network launch partially as a mechanism to speed up development. Alternative mechanisms to solve the kind of things that cron solves trivially often involve off-chain parties ("keepers") monitoring for certain conditions and submitting explicit transactions to trigger action. These have much weaker guarantees, delays, and introduce additional system complexity making the whole thing harder to reason about. (Prior art: Chronologic/Automate/EthAlarmClock, Aion).

Nevertheless, I think many people regard cron as a kind of crutch that we should try to move away from, and certainly not a facility we'd consider exposing to user contracts in the FVM.

This topic is to question that point of view, and discuss various ways in which we could provide that utility to developers safely. Anecdotally, developers of other blockchains have expressed admiration that Filecoin has a cron facility [citation needed]. How could we elevate cron as a network service so that built-in and third-party applications could build upon it? E.g. how could we price its use? Why would we shy away from that, and how could we mitigate risks?

[steven004]

I would support keeping cron actor as a network service, and keep the current functions to on-time check the wdPost and deal payment processing (this might be considered to be one of user-defined cron jobs.)

In addition, supporting user-defined cron jobs will be wonderful feature, which may enable lots of new ideas in smart contracts. The key things is how to evaluate gas consuming and make sure the network is not be impacted by bad job setting. There are a few consideration:

1. The cron actor just keeps a list of jobs, which can be added or removed by job owners. A real job execution is actually calling a method of another actor. Thus, the gas calculation should be no difference than a normal method;
2. A small amount of gas could be added for a job execution to pay for cron list resource cost, routing check and invoking method fee
3. A job execution will consume gas which the job owner should provide. A job owner could be an actor, or a signable account, even a multisig address. This can be deducted automatically from the owner whenever the job is being executed, or with a deposit mechanism to handle this.
4. To make sure each item of the cron job list is effective, any insufficient gas execution job could be removed immediately.
5. Of course, we need add-job and remove-job method for cron actor, the gas design for the two may consider both to add-job, and free for remove-job for safe. (sometimes, the remove will be automatically executed)
6. Any other attacks? looks other attacks to cron actors can also apply to other actor. It should be safe while the gas is consumed and all the executions.