FRAME: General System for Recognizing and Executing Service Work

[sam0x17]

Fixes paritytech/polkadot-sdk#206

[kianenigma]

As the associated issue is in it, I suggest keeping only one in the roadmap.)

[sam0x17]

Looking forward to see more aspects of the execution part coming out. Any initial design, thoughts or similar?

@kianenigma Right now I am working on the system pallet do_work extrinsic Gav describes here which I think fulfills what you're looking for:

This task would be called into via a System-pallet extrinsic (either through the block-builder, an OCW, submitted via a script or even manually through a transaction) without any further logic in the pallet whatsoever. The extrinsic could be called something like fn do_task(origin: OriginFor<T>, task: Task).

A custom ValidateUnsigned within the System pallet which recognises this extrinsic would ensure that the condition for the task is met prior to accepting it via an inherent/unsigned extrinsic (signed transactions can call it anyway and risk payment not being refunded). tasks would ensure that the OCW/script could easily determine parameters which passed this condition.

[sam0x17]

now need to have Task aggregate like Call/Event/etc does

[kianenigma]

Looking forward to see more aspects of the execution part coming out. Any initial design, thoughts or similar?

@kianenigma Right now I am working on the system pallet do_work extrinsic Gav describes here which I think fulfills what you're looking for:

This task would be called into via a System-pallet extrinsic (either through the block-builder, an OCW, submitted via a script or even manually through a transaction) without any further logic in the pallet whatsoever. The extrinsic could be called something like fn do_task(origin: OriginFor<T>, task: Task). A custom ValidateUnsigned within the System pallet which recognises this extrinsic would ensure that the condition for the task is met prior to accepting it via an inherent/unsigned extrinsic (signed transactions can call it anyway and risk payment not being refunded). tasks would ensure that the OCW/script could easily determine parameters which passed this condition.

My suggestion for you is to just add do_task to the system pallet, let it be only ensure_signed, and wire it to the rest of the system, such that I should be able to call this do_task, reference a task, execute it, and pay for it. The same conditions must be checked against my task.

The Optional refund can come next.

The ValidateUnsigned can come next. This should allow do_work to be something like ensure_signed_or_unsigned, where the unsigned is easier and free, the signed is paid and might refund. A ValidateUnsigned should strictly checked that a valid task is being called.

Finally, then you can work on the path through which OCW code will submit unsigned transactions, so the chain can easily piggy-back on its validators and execute tasks.

signed --> signed+refund --> unsigned --> OCW + unsigned

is the right order to think about this.

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs. Job name: cargo-check-benches Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3409306

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs. Job name: cargo-check-benches Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3409307