This is general idea for creating off chain computation that has various levels of security.
Off-chain computation can span from providing external data to on-chain (e.g. price feed, twitter API) to complex computation over on-chain data (e.g. average over transactions in the last 24 hours, merkle root of all users across all contracts).
All these use cases can benefit from security that is provided by validators of the chain, but there are few reasons why this is not possible to achieve directly on chain as part of the protocol:
- Data provided is external to chain
- Computation takes too long (seconds to minutes) or too much memory (load the whole tx history)
- In sharded environment, it may also be also too expensive because it requires lots of cross shard communication
Another use case for such off-chain computation that is still shares the validator set is various bridging.
In the generic case, a new
worker client is built.
worker client 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.
There is a
jobs contract on-chain, where developers and other contracts that need off-chain jobs to be done can post what needs to be executed. They pay $NEAR or new token for this job to be executed that then gets split among the runners of
Now, validators are generally open to provide more utility to the network. They can be running such
One trick that’s possible on NEAR is that
jobs contract can actually link the chain validators and these
worker runners based on who is staking at any moment. This means that for any job executed, you can see how much of the
stake executed this job.
Jobs can implement aggregation / challenge system: from simple that super majority needs to agree, median of price with 2 standard deviations, etc. if the validators disagree their stake can be “challenged” by smart contract (this would require staking smart contract modification to support it).
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. More advanced version with challenges can be then added as validators migrate to next version of the staking smart contract.
Validator’s job is easy to just run such
worker client and register another account or a key in
jobs that this
worker is operating under (it’s not the same account as the one that does validation to avoid any issues).
More specific version of worker can be developed where it’s required (e.g. wasm is too slow for complex computation or may be some external operations are not supported). Validators adopting workers will register which types of tasks they support.
Bridge can leverage this framework to use the same security of validators to sign with secp256k1 blocks or transactions that must be relayed to other chains.
This ways protocol doesn’t need to directly do this, while majority of validators can be running separate piece of software and with challenge functionality providing the same level of security.