Operational Transactions

[kianenigma]

These transactions will be

• Signed.
• Must be charged fees as a normal tx.
• Must make sure that they have precedence in inclusion
• Must make sure that the block weight limit NOT will cause them to be rejected.

Needs:

• Weighable trait to return the priority. fn priority<B>(&self, encodec_len: usize, tip: B)
• Weighable to define a function which indicates block fullness. Then we simply return false if we observe an operational tx.

Not much work. Best to do it after #2930 and #2854 are merged.

[kianenigma]

@rphmeier can you double check that problem definition is correct and will fit what you need? (trying to recall everything we discussed in group)

[gavofyork]

Must make sure that the block weight limit will cause them to be rejected

is this not missing a negative?

[kianenigma]

Must make sure that the block weight limit will cause them to be rejected

is this not missing a negative?

yes. (This is a clear sign that I should stop doing stuff for tonight)

[rphmeier]

Why can't we just use regular transactions for this and change the queue-weighting mechanism a little?

Also it would be good to familiarise yourself with #3063 -- this is the runtime API to be used by the node in constructing those calls.

Weighable

nit: naming in Rust would just call the trait Weight or even better Priority, since it has one fn priority.

All traits indicate foo is bar-able...it's completely redundant.

[kianenigma]

Closed via #3102 and a bunch of others.