Background

We will have large number of channels when in production, on the order of 1-10M. These need to be paid out regularly on the basis of judgements about the value they bring to the system, for example informed by how much traffic they drive to Gateways. Let us leave aside the question of what method will be used to determine what each channel should be paid, and just focus on the question of how to make such payments of given quantities of JOY to given channels.

Specifying the full set of payments through one or more extrinsics will be infeasible, due to the sheer size, and also because of the tremendous computational cost of making all the payments in anything like a timely manner. This means we must instead consider some sort of pull based payment scheme.

Proposal

Let {c_1,...,c_N} denote the ids of all channels that are owed some reward outstanding, and let p_i denote the JOY payment to the channel with id c_i. Let m_i denote some hash commitment over some report or manifest which explains, in terms of some standard, the basis for the relevant p value on c_i . Let commitment be some sort of accumualtor over the set F = {(c_1, p_1, m_1), ...., (c_N, p_N, m_N)}. It just needs to allow efficient membership proofs in terms of N, so Merkle trees could perhaps be a good starting point. Now, payments are made by having a value for commitment placed in the content directory, and the full set F placed in the storage of the council or the relevant working group. This F will allow any channel to construct the full proof required to cash out. There should probably also be some runtime value S which bounds how much can be cashed out for, so as to prevent an attack from introducing absurdly large p_i values. When the cumulative cashout amount for a given commitment reaches S, no further cashout is allowed until the value is raised.

To prevent a channel from cashing out more than once on the same commitment and in order for the process of setting p values from one commitment to the next not having to take account of who has cashed out or not at what time, we do as follows.

• the semantics of this value p should be total amount of money earned by this channel
• each cashout is for the maximum allowed amount, and the cumulative value v of all prior successful cashouts in a given channel is stored in the channel
• it is only possible to cashout if v <= p-MIN_CASHOUT, where MIN_CASHOUT>0 is some runtime constant for the smallest value cashout allowed, at which point the cashed out value is p-v and the new value of v is set to += p-v.

Note that nothing prevent p from actually decreasing from one commitment to the next, something which would reflect the channel having previously gotten credit for fraudulent activity.

Note: this explanation is quite rough, but it gives a good idea for how one can proceed.