RFC: Introducing a reward / collateral ratio for data requests

[drcpu-github]

Solving data requests should make sense from an economical standpoint. Currently this is not the case. The collateral data requests require and the reward payed out actually make the average node operator lose money (if you ignore block rewards). Take a price feed data request as an example. These requests require a 5 WIT collateral while paying 1 mWIT. If a node operator lies (unintentionally) in 1% of the data requests he solves, he will lose 5 WIT and only get payed 0.1 WIT per 100 data requests solved. Even if the unintentional lie rate is 10x smaller, the reward is still 5x smaller than the collateral lost. This obviously constitutes a problem. The point of this discussion is to ascertain if miners in the Witnet network should be able to enforce a reward to collateral ratio through a witnet.toml setting.

Several versions of this proposal have been discussed before and have been turned down because it introduces a vector to game the reputation system. If a default value is introduced, most node operators will use it without a second thought. Other node operators could then on purpose create data requests with a ratio lower than this value and thereby exclude a subset of nodes from solving them. This would in turn result in these nodes gaining reputation more easily than others. This is obviously an issue, but variations on this already exist in the current network either way.

I do believe a solution for this attack could come in the form of the network protocol enforcing a minimum reward / collateral ratio. This could be implemented similarly to how a minimum collateral is required through a consensus constant. If a data request does not adhere to the minimum ratio, miners will simply refuse to include it in a block and if a miner does include it in a block (e.g. in an attempt to game the network), other nodes will simply discard the block as being invalid. I believe that in order for this solution to fail, a group of node operators would need to control a supermajority of the network and at that point, there are obviously bigger issues than abusing the reputation system. From an implementation point of view, this also seems like a reasonable approach since there are already plenty of other rules being enforced which can render a block invalid.

Of course, we need to decide what a proper ratio would be. I am of the opinion that a minimum 1% reward to collateral ratio would be a decent setting, but this is obviously open for discussion. Node operators could also set this higher through the setting in the witnet.toml file.

A data request will typically require at most one hundred witnesses. It is technically possible to request a slightly higher amount of witnesses, but not that much due to block space limitations. This would thus imply that the data request total reward never exceeds the requested collateral keeping them economically interesting.

However, the more important reason for picking a 1% reward to collateral ratio is the current data request lie rate. I have looked at a large sample of solved data requests in the past two months. Looking at the (unintentional) lie rate, this is on average 0.26% with a daily maximum of 1.55% as shown in the graph below. Given that over 90% of the data requests in the network are price feed requests, this can presumably be attributed to unintentional lies in periods of high price volatility. By guaranteeing a 1% ratio, a miner should statistically be profitable with respect to the collateral he has to put up.

I believe there are a couple of additional benefits to this. First of all, requiring a reward collateral ratio drives demand for the native Witnet coin. Secondly, it tackles a number of situations where people can try and game the reputation system because they now need to actually pay for that instead of launching 1 nanoWIT requests, making attacks like this potentially economically infeasible. Thirdly, by assuring that a node operator can operate in a profitable manner by solving data requests only block reward subsidy reductions can be discussed.

In summary, I think a reward / collateral ratio is necessary to make solving data requests sensible from an economic standpoint. By introducing a consensus constant that enforces this ratio, I believe it cannot be used to easily game the reputation system. I also believe that introducing a change like this would strengthen the network.

[lrubiorod]

Totally agree with this proposal. Enforce a minimum ratio between collateral and reward sounds really good to me by the reasons that you wrote.

Moreover I would also standardize the fees, makes not sense to me that the miner who include the data request earns more than the miner than include the commits or reveals. And follow the same line of thought, enforce a ratio between the fee and the reward could produce that miners always have more incentives to include requests with higher rewards, and avoid that a requester could include a request with a big fee but a ridiculous reward, consuming the bandwidth of the Witnet network (Despite the fact that your proposal would mitigate so much this problem)

[tmpolaczyk]

Did some statistics on this, will post more details tomorrow but the average reward is around 3000 nanowits per witness per request, so it is not true that the average node operator loses money. This is because when one witness is slashed, the collateral is divided among the other honest witnesses. Also I don't think we should ignore block rewards, because the protocol is designed to give a higher block mining probability to identities that resolve data requests. Adding the rewards from block mining (mint + fees), the average reward is around 40_000_000 nanowits per witness per request.

[tmpolaczyk]

There were 206628 data requests in the block range 700000 - 1010454, resolved by 73078 different witnesses. The table below shows the total amount of nanowits that were gained by data request witnesses in the tally transaction. The average is simply the total divided by the number of witnesses, and divided by the number of data requests. This average can be used to answer the question "I have a node that has been running since epoch 700000 and it has solved at least one request, what is my expected profit?" So for example an average of 109 nanowits means that this node operator should have gained 109 nanowits * 206628 data requests = 22522452 nanowits. And it doesn't matter in how many of these requests the node was eligible, because it is the average. Enforcing a minimum reward of 1% would increase the average to 9227 nanowits, so this node operator would have gained 1906556556 nanowits, or 1.9 wits. The time period needed for that number of requests is around 5.2 months.

It is hard to say how accurate is this average because it doesn't take into account the identities that attempted to resolve requests but were never selected. That's why the previous tests showed an average of 3000 nanowits while these longer test shows an average of 109 nanowits, because in a longer period there are more identities that participate only once, bringing the average down.

All the units are in nanowits. The 0% row is the current value (the minimum reward is 0%), the other rows are the simulated values if there was a minimum reward. I also added 10% and 100% as possibilities, so we can extrapolate the data. "No reward" means forcing the witness_reward to be 0. "Total + mint" also includes the rewards from block mining, when any of the identities that resolved a data request mined a block in this period.

Min. reward	Total	Per witness per request	Total + mint	Per witness per request
No reward	-449512	-2.9769083541096915e-05	62299850121610872	4125828.5493336124
0%	1645962445192	109.00441709326738	62301496084505576	4125937.553780475
1%	139332389550488	9227.334408222998	62439182511610872	4135055.8837716044
10%	1393323899550488	92273.34435015173	63693174021610872	4218101.893713534
100%	13933238999550488	922733.443769439	76233089121610872	5048561.993132821

You can check the code I used to gather the data here. Further questions or ideas about what kind of data would be useful are welcome.

[drcpu-github]

This is interesting. I must admit that I did not consider node operators receiving the collateral from other slashed node operators in my initial analysis and that this seems to contribute significantly to whether isolated data request solving is profitable or not. I don't quite like the fact that you need to rely on other operators lying to be profitable as a protocol-level feature, but I'm somewhat biased of course.

Taking this into account I'm curious whether you think enforing a reward / collateral ratio is a bad idea or not as you don't seem to explicitly voice an opinion? Granted, the profitability issue is not as bad as I thought, but there are still a couple of other issues that a reward / collateral ratio would solve (both on the protocol level and generating coin demand).

I explored the data request probability a bit more. I was mostly wondering whether using averages did not hide the nuances required to draw the correct conclusions. I calculated the top 1.000 nodes which solved the most data requests. I think this is interesting because these are supposed to be top-performing nodes. Just like in your analysis, I took the ~200k data request from the last 300k epochs and then calculated whether the node operators lost Witnet coins due to (involuntarily) lying.

Label	Amount
Top 1000 nodes, most requests solved	1725
Top 1000 nodes, least requests solved	420
Top 1000 nodes, average reward	20.94 WIT
Top 1000 nodes, total reward < 0	154

Given that even the least active node solved 420 data requests, I'd say this is a pretty decent sample of node operators. The majority of node operators gained Witnet coins and the average is positive. They did only gain an average of 20 WIT for operating a node during 5 months, so that is still quite low. However, more importantly, 154 of the top-performing active nodes still lost coins due to solving data requests. The fact that well-performing nodes have such a high probability of losing coins seems like an issue to me. I looked at the breakdown of lie rates versus profitability, see below.

Looking at the curve, most of these 154 node operators exhibit a significant (involuntary) lie rate. Below table summarizes the breakdown of the lie rate of nodes which lost coins solving data requests. What do you think is an acceptable lie rate and still end up with a positive balance?

Lie rate	Nodes
< 0.5%	1
< 1.0%	4
< 1.5%	22
< 2.0%	65
< 2.5%	109
< 3.0%	135
< 3.5%	144
< 4.0%	150
< 4.5%	153
< 5.0%	154

Also I don't think we should ignore block rewards, because the protocol is designed to give a higher block mining probability to identities that resolve data requests.

I agree that the current block rewards serve as a subsidy to make operating a node economically interesting. However, I firmly believe the rewards for data request solving and block mining should be decoupled because then you can tweak both knobs independently of each other. It would allow for exploring many different settings: reducing block reward issuance reduction, burning coins of nodes that are caught lying, ...

[Steve00111]

This looks like a good solution to make the witnet token more valuable. Please put it into action.

[tmpolaczyk]

So it is true that currently the witness_reward field is useless, because any value is accepted and there is no benefit in providing a higher reward.

We could add a miner-configurable option to witnet.toml to allow rejecting requests with low reward, but that would lead to a very poor user experience: the data requestor will get no errors or warnings but if the reward is too low then their data request will never be included in a block. Even though a similar setting already exists in the case of value transfer transactions, that case is much simpler: if the value transfer transaction is not included in a block, you need to increase the fee and try again. But in the case of data requests there are several fees and parameter options, so if the request is not included the data requestor probably won't know why. Here I agree with @lrubiorod that we should try to standarize the fees, because if there was only one fee then the data requestor could simply increase that fee when their data request is not included.

Setting a minimum witness_reward as a consensus constant would allow us to give feedback to the data requestor when they set a reward that is too low, but it doesn't really solve the problem of the witness_reward field being useless. I would expect most requests to use exactly the minimum value, because there is no benefit in giving a higher reward. The case of collateral is different because setting a higher collateral increases the quality of the result, because "low quality" nodes will likely have little collateral available.

So in my opinion the best option is to enforce a fixed witness_reward. These are the current data request parameters:

    /// Reward in nanowits that will be earned by honest witnesses
    pub witness_reward: u64,
    /// Number of witnesses that will resolve this data request
    pub witnesses: u16,
    /// This fee will be earn by the miner when include commits and/or reveals in the block
    pub commit_and_reveal_fee: u64,
    /// The minimum percentage of non-error reveals required to consider this data request as
    /// "resolved" instead of as "error".
    pub min_consensus_percentage: u32,
    /// The amount of nanowits that each witness must collateralize in order to claim eligibility of
    /// this data request.
    pub collateral: u64,

commit_and_reveal_fee could be calculated from the transaction fee, and witness_reward could be calculated from the collateral value. That would leave the parameters of witnesses, min_consensus_percentage, and collateral, which all directly affect the quality of the result.

Not sure what would be the best default value for witness_reward. If we want to separate data request witnesses from block miners, then this needs to be a high percentage, at least 10%. I like the option of setting it to 0, because that way the data request is cheaper for the requestor, and it wouldn't change the current profits too much. But not sure if that would introduce any attack vectors.

What do you think is an acceptable lie rate and still end up with a positive balance?

The network should be able to tolerate a high lie rate as long as it does not affect the outcome of many requests. Specially because sometimes this is inevitable, in case of volatile price feeds for example. I would focus on the probability of multiple witnesses lying at the same time, because we want that to be as rare as possible. A lie rate of 4% seems fine, around 20% should start to penalize, and above 40% should never be profitable, for example.

[drcpu-github]

So it is true that currently the witness_reward field is useless, because any value is accepted and there is no benefit in providing a higher reward.

I was somewhat thrown off by this comment, so I took a closer look at the code and I actually think this is not the case? The witness_reward field is part of the total data request fee as calculated in chain.rs:

total_value = (witness_reward + commit_and_reveal_fee + commit_and_reveal_fee) * witnesses

Given that data requests are included sorted by priority (total_value / transaction_weight), increasing the witness_reward should yield a higher priority which seems to be a clear benefit?

This does highlight the extra issue that currently a miner does not directly benefit from including data requests with a high witness_reward into the blocks he proposes. An alternative implementation of the mining node where higher commit_and_reveal fees yield higher priority and the witness_reward is simply ignored does make economical sense from a miner's perspective. After all, a miner is unlikely to (have) participate(d) in solving the exact data request transactions he's including and thus has no incentive to include a data request with a high witness_reward.

commit_and_reveal_fee could be calculated from the transaction fee, and witness_reward could be calculated from the collateral value. That would leave the parameters of witnesses, min_consensus_percentage, and collateral, which all directly affect the quality of the result.

Ideally, if we want an easy-to-understand fee market, I think all fees should deterministically derive from one base fee (e.g. the collateral value) and have a minimum ratio. That way each party partaking in solving data requests and including the transactions in blocks shares the same economic incentive to include higher paying data requests. If you calculate commit_and_reveal_fee and witness_reward using a different base, you are not aligning miner incentives with incentives of data request solvers which could become problematic.

We could add a miner-configurable option to witnet.toml to allow rejecting requests with low reward, but that would lead to a very poor user experience: the data requestor will get no errors or warnings but if the reward is too low then their data request will never be included in a block.

Obviously if a proposal like this is implemented, we want to add an extra error similar to InsufficientCommits which indicates that you should increase your fees. Note that this poor user experience already exists to some degree. If the network is saturated, the data request will simply fail with an InsufficientCommits message, I think, and the end user has no idea it's because his fees were too low.

[aesedepece]

total_value = (witness_reward + commit_and_reveal_fee + commit_and_reveal_fee) * witnesses

Given that data requests are included sorted by priority (total_value / transaction_weight), increasing the witness_reward should yield a higher priority which seems to be a clear benefit?

I don't think this is correct. Priority is miner_fee / transaction_weight. But the total_value (requester cost) of a data request is not the same as the miner fee (inputs - outputs).

An alternative implementation of the mining node where higher commit_and_reveal fees yield higher priority and the witness_reward is simply ignored does make economical sense from a miner's perspective. After all, a miner is unlikely to (have) participate(d) in solving the exact data request transactions he's including and thus has no incentive to include a data request with a high witness_reward.

This reasoning seems correct to me.

Ideally, if we want an easy-to-understand fee market, I think all fees should deterministically derive from one base fee (e.g. the collateral value) and have a minimum ratio. That way each party partaking in solving data requests and including the transactions in blocks shares the same economic incentive to include higher paying data requests. If you calculate commit_and_reveal_fee and witness_reward using a different base, you are not aligning miner incentives with incentives of data request solvers which could become problematic.

This as well.

We could add a miner-configurable option to witnet.toml to allow rejecting requests with low reward, but that would lead to a very poor user experience: the data requestor will get no errors or warnings but if the reward is too low then their data request will never be included in a block.

Indeed. Letting witnesses abstain from committing could very easily lead to consistent InsufficientCommits for highly collateralized requests.

[drcpu-github]

I don't think this is correct. Priority is miner_fee / transaction_weight. But the total_value (requester cost) of a data request is not the same as the miner fee (inputs - outputs).

As per the calculation of the DR fee, this is indeed simply the difference between inputs and outputs. As far as I know, this does include the witness reward since all different fees which need to be payed at the different stages of the data request are included in this UTXO difference. The DR fee calculation function is used to validate the DR whenever a new transaction is validated. The latter is called at the time you add a transaction into the pool. I'm not sure where the witness reward would be discounted to not be taken into account when calculating the priority at insertion?

EDIT: I finally understand why this is wrong. In the dr_transaction_fee function there is an addition with the result of checked_total_value() which adds all transaction rewards.

[Chainguys]

just curious...

is there any punishment if "low quality data or false info" provided?

[drcpu-github]

If you are refering to node revealing a value that is not in line with what other nodes are revealing, then yes. Nodes that reveal a value that is outside of the range accepted by other nodes (usually this is something like two standard deviations away from the average value as revealed by all nodes), will lose the collateral they put up when they were eligible to solve the data request.

[aesedepece]

WIP-0022 is live now on Witnet mainnet!