@illia This
workerclient reads the job description posted on-chain (wasm file to execute, periodicity, where to take arguments from). It then executes this job locally and posts results back on-chain.
Where would the wasm file be hosted / distributed through? How would one upload it to a Jobs contract, perhaps without external dependencies like IPFS, conveniently referencing by hash, letting anyone check the wasm’s validity by compiling its source instructions.
Speaking of source, does the wasm file describing computation steps for a Job need to be implemented as an SDK contract, or adhere to some alternative requirements to be interpreted properly by the client?
Does the Worker client itself need to inherit from, or even plug into neard somehow? Would a controller process in the daemon need to dispatch the running of Worker, in order to,
benefit from security that is provided by validators of the chain
and if not, then which component would govern the provisioning of “read request from chain, process off-chain, and call back with results”?
To my understanding, Worker may need to sit on top of an Indexer in order to be capable of doing Jobs that require reading an on-chain contract’s entire state. It probably would not be necessary given reads could be chunked into separate Jobs, for instance, each reading one struct from a persistent map at a time rather than reading the entire map at once.
@illia First version of this though can just rely on social consensus around delegations - most validators are leveraging delegations and thus providing invalid data will lead to loosing the delegations and loosing their spot as validator.
In my way of thinking, Jobs would be split according to the owner of the input data they work on, input being structured as { ‘contract-account-name’ ; ‘getter function therein’ ; ‘owner as param into getter’ }.
The Job would be backed by an owner’s STAKE, abstracted over by an stNEAR-style basket contract auxiliary to the existing @oysterpack implementation. Such a basket contract would be one-to-one coupled with a Jobs registry contract.
All the various owners of data processed through Jobs would be stakers, spread over all validators pertaining to the basket. Every validator in the basket would run the same Job for a given owner regardless of whether owner is staked to that validator or not.
Assuming all-or-nothing consensus, if one validator’s result for a given Job differs from the results of 2/3 of the rest, and it so happens that the relevant owner is staked to that validator, then owner’s STAKE is automatically booted out from the validator and, for instance, spread equally to the 2/3. The basket contract later prevents owner from ever staking back to the validator in the wrong, which is also useful if owner was STAKEd to a different validator.
If the validator had not been in the wrong, they would keep a small cut of owner’s STAKE rewards for themselves as payment for successfully fulfilling the Job. An owner’s stake traveling between validators in a basket would have no impact on owner’s basket share balance, changing only the revenue stream associated with the balance.