Consideration about TransactionSource in validate unsigned, maybe removal

[gui1117]

Context, in the extrinsic horizon #2415 unsigned transactions are deprecated in favor of "General" transactions.
A "General" transaction is a transaction which contains extensions (formely signed extensions) but are not signed, instead some payload may contain the signature of the transaction and the extensions, or the validity is ensure in some way (like claim for example).

We might not want to bring the concept of transaction source in the "general" transaction.

Currently TransactionSource is used to have transaction from the offchain worker put into the block while at the same time blocking the same transaction if it comes from external source.

This is used for unsigned equivocation in babe, beefy and grandpa, also to provide an election solution in an unsigned way, and also unsigned slashing report for disputes.

Instead of transactions those extrinsics really looks like inherent to me, but there is no way to submit some information from the offchain worker to the inherent data to convert this information into some inherent.
Also the inherent data has no concept of longevity, provide, require, nor resubmition in case of uncle-block.

I think touching the inherent architecture is difficult.

So to move into "general" transaction we can:

• 1 - simply make those transaction signed, and free upon success. Nodes will have to pay upfront and are refunded. The downside is that nodes have to ensure that they can pay for it. Considering the importance of those transactions this might be controversial.
  Moreover the extrinsic can get propagated to other nodes when sending uncle-block. In this case if the call is failing the node will have to pay for the failing job, which is not good.

• 2 - try to make feeless if it comes from block author. The issue is we don't have block author when doing the validation of transaction in the transaction pool. So we would have to add some runtime-interface. Or add TransactionSource similar as today but for general transaction.

• 3 - make them inherent, and allow offchain worker to create some optional inherent easily: for example with election solution:

  • offchain worker will set the election solution in the offchain worker storage.
  • offchain worker storage is part of the inherent data or offchain worker storage is accessible from ProvideInherent::create_inherent in some way.
  • create inherent will create an inherent with election solution, doing same check as pre_dispatch.
  • user has to be careful about not removing the solution from inherent data before it is a finalized block.
    we probably want to have a offchain_worker::on_finalized_block which would remove the election solution from offchain worker storage.

  So it would need:

  • new offchain worker to be executed on finalized block
  • a way for offchain worker to put some information in the inherent data (through the offchain worker storage or some other API)

• 4 - make the call signed and only valid if it comes from the node key or from the block author or some account trusted by the block author.

[gui1117]

(4) is probably the solution, I guess digests contain the block author in validate, it can be used to trust an extrinsic.