Adding Scheduler and Cron Job Functionality

digimbyte commented 1 year ago

Summary:

Despite significant advancements in blockchain technology, native support for scheduling and executing functions at specific time intervals, including both one-time and repeating events, remains lacking. Many blockchain applications currently rely on external solutions for time-based events, which can be complex, less secure, and unreliable. This proposal addresses this gap by introducing a native scheduler and cron job functionality within Neo smart contracts.

Proposal:

The primary goal of this proposal is to innovate Neo smart contracts by introducing a built-in scheduler. This empowers contracts to autonomously schedule and execute functions at custom intervals, enhancing reliability and self-sufficiency. Additionally, it underscores the necessity of unique identifiers to ensure idempotency on the blockchain and to facilitate the management of previously scheduled events.

Features:

Scheduler Functionality:

Neo smart contracts will include a native scheduler to automate the execution of functions at specific time intervals, enabling both one-time and repeating events. Developers can configure the timing of function executions. For example, "1 hour" can be used for a one-time event, while "every 6 hours" can be employed for a repeating event. Timezone offsets from -12 to +12 can be applied. If a schedule uses "0" as the interval, it will fire on the next block. (specifics of the intervals should not emulate cron jobs directly but be sculpted to the requirements of the blockchain per its needs)

Unique Identifiers:

Each scheduled event is associated with a unique identifier generated by the contract. This identifier enables the management of scheduled events, including updates and deletions. It ensures that scheduled events are idempotent and can be tracked and managed efficiently.

Benefits:

Enhanced Neo smart contract versatility with native support for both one-time and repeating event scheduling. Reduced reliance on external off-chain solutions for time-based events. Improved transparency and auditing through dedicated event logging, separate from normal invocations. Ensured idempotency and reliability with unique identifiers that facilitate scheduler management. Provision for fallback invocations to handle cases when off-chain requests may have failed, ensuring robustness and continuity of contract actions.

Neo Version

Neo 3

Where in the software does this update applies to?

Unknown: the layer that runs and manages smart contracts?

steven1227 commented 1 year ago

I remember there was similar idea from @Liaojinghui

roman-khimov commented 1 year ago

Duplicates #2817, which in turn duplicates a set of older issues mentioned there (but those are closed).

digimbyte commented 1 year ago

Duplicates #2817, which in turn duplicates a set of older issues mentioned there (but those are closed).

I believe this post is more fleshed out in scope, I also commented on #672 this seems to be a long standing feature request and facilitating autonomy on the blockchain can improve many situations. such as auctions and timed events, fallback functions, etc.

in my case, I have a function where people will provide NFTs and tokens and if my off-chain server is offline, crashed, or down for any reason, those users assets are locked in limbo because the contract has no way to auto timeout or cancel that operation after X hours.

additionally: simply invoking a contract that updates values daily or weekly without an RPC hook would be amazing for large scale contracts.

end of the day, discussion needs to happen around some form of autonomation on the platform. even if its some sort of CRON scheduler on the NVM

shargon commented 1 year ago

I remember to close mine https://github.com/neo-project/neo/issues/672

cschuchardt88 commented 1 year ago

do u really want a million threads or timers running on a handful of nodes? Yes, there is many way of doing this, But bottom line is someone is going to have to pay the server resource cost. Having consensus doing it or having every node doing it; isn't practical. One practical solution is to make your plugin for neo-cli and do things that way or write your own cron program to talk to Rpc or some node to send a transaction to invoke a contract method. Built this in a afternoon isn't perfect it and its untested... If you like code, well check it out.

digimbyte commented 1 year ago

that's what gas is for? we already do this with oracle, only difference is we introduce a custom delay. and the meta doesn't need to rely on egress. it's easily an extension of that or something that gets passed onto the parent infrastructure.

not sure how the scalability would result in millions of threads as you could easily run this on a single service. idempotency is the only concern

Code you provided looks like a great starting point, I don't run a node personally but this could be standardized with idempotency. are there other options within the tech stack to register events onto a single thread?

cschuchardt88 commented 1 year ago

Your forgetting about something needs to run 24/7 to see the time and would have to potentially run tons of operations (invokeinng tasks). so who will be responsible for 100% Fault tolerance and never going down or never miss a schedule. There is no refund process (besides the gas you get for holding NEO). I'm not saying it's a bad idea or not possible. The way things in code function need to be revamped.... NEO 5.0

where does Neo see itself in the next 5 years?

Just need some re-structure in code. Neo need to meet the architect, if u know what i mean.

are there other options within the tech stack to register events onto a single thread?

The VM isn't anything more than a calculator (scientific one at that). But currently what i have drawn up is the simplest form to integrate with Neo. I have been for a while now building a system that does just that; what you are asking for. But this would be a 3rd party service...mostly free if not free at the start.

Neo would need a system for refunds; if jobs are missed or delayed... among other things.

digimbyte commented 1 year ago

the server structure that runs the node/chain is live in parallel with the chain and could talk to the contracts. being time related, its not essential to be within a single block but can be invoked at a later point.

I am highly tempted to make something myself but I am not a block chain/node dev - my area is Javascript/Typescript I am keen to see any progress to making neo dev friendly, even 3rd party.

Jim8y commented 1 year ago

@cschuchardt88 not that heavy load as you expected, leader checks it when a new consensus starts, even its time based, its block index based, cant be some real time thing.

cschuchardt88 commented 1 year ago

@Liaojinghui You could convert my Crontab Plugin into service like that of oracle service. You would have to add the interop service. Than add something like "if crontab job successful than send transaction for contract invoking, than send payment for the service transaction". I think that would be the best the solution. So this way people that install the neo-cli can pick if they want a workload like that on their computer. Also you would get a discount if the crontab job is missed or delayed for any reason. Also you don't take payment for service until successful execution of job. This transaction would have an attribute of Crontab.

roman-khimov commented 1 year ago

I believe this post is more fleshed out in scope

In general, I prefer keeping the oldest one open and closing duplicates, even if they add something, they're not going away after closure and can be referred to/discussed. But hey, I don't even have any buttons to press here, so.

Let me throw some random thoughts in:

crontab plugin is nice in its own way, but it requires having the key of the target signer
any generic mechanism will be overriding signers like oracle responses currently do (hi, #1976)
which can be done with an additional attribute, but we obviously can't trust a single entity to create these transactions and we can't trust random people to do the job (much like we can't have a single weird oracle node)
which means we need to have a multisig of designated (by committee) nodes
which means... :drum: :drum: :drum: #1573 (ok, ok, #2905 has some parts of it included)
with #1573 this can be implemented relatively easily as an additional network service

At the same time an idea from https://github.com/neo-project/neo/issues/672#issuecomment-478526899 can be implemented with NVBs (#1992) safely now even with a single third-party entity. A service can accept transactions that transfer some GAS to its account (in a regular way) and do whatever they want to do with regular witnesses. A user can send a set of transactions to it with NVB fields set to 100, 200, 300, etc and service couldn't send these transactions before NVB. But it's still economically motivated to hold them in the queue and release when time comes (caveat: transaction can fail and in this case the service would get nothing). Not exactly the perfect solution, but a solution that can be implemented with 3.6 right now.

neo-project / neo