Issuance rate parameterization under adversarial conditions

[adlerjohn]

Thanks @Mikerah for initial discussions on this.

#251 provided some initial discussion on issuance rate, but does not discuss how to avoid the two extremes presented in the design rationale, namely:

two common models, (i) fixed reward rate, and (ii) fixed total reward

Each can be solved individually, but let's consider the first case for now:

The main argument against (i) is that it imposes too much uncertainty on the network of two kinds: uncertainty of the total level of issuance, and uncertainty of the total level of deposits (as if a fixed reward rate is set too low then almost no one will participate, threatening the network, and if a rate is set too high then very many validators will participate, leading to unexpectedly high issuance).

The solution to the above two extreme cases is a mid-way compromise of inverse-square root issuance based on the total balance. The design rationale states that "The inverse-square-root approach compromises between the two and avoids the worst consequences of each one," but I argue that it does not, continuing discussion from #832 in this comment. In the worst case, an inv-sqrt scaling on rewards does not solve the problem of having set the parameter too low. To actually solve it would require an inverse-exponential function, where the rewards increase to infinite with no validators.

A compromise solves neither problem, and instead leaves the worst case scenario for both intact. How can the rewards be scaled in a way that we have rigorous proofs of how the system performs in adversarial conditions?

Is there actually a real, provable problem with using a linear scaling reward function, other than the optics that inflation is too high?

[vbuterin]

A compromise solves neither problem, and instead leaves the worst case scenario for both intact.

Huh? That's definitely not true. First of all, y = 1/sqrt(x) is unbounded with y approaching infinity as x approaches zero, so it is the case that if the parameter set is too low it will still reach an equilibrium with a significant number of validators. Second, as my paper on discouragement attacks shows, using a square root formula instead of a simple y = 1/x does make discouragement attacks 2x weaker, to the point where it does possibly solve the issue (see "this implies we need p < 1/2 for epsilon attacks to be unprofitable" on page 6).

[adlerjohn]

Hmm. Sorry for jumping the gun on a proposed solution. I'll try to articulate my thoughts here, please correct if they're wrong.

There are two problems we have to consider:
(i) What if we set our parameters too low? Then no one will validate.
(ii) Is our system vulnerable to discouragement attacks?

The first suggestion for a reward rate is constant, independent of the total validating stake, i.e., B = k * Di. The problem with this is that it does not solve (i), since we may have set our parameter k too low. Let's consider the case of the inv-sqrt rewards, i.e., B = k * Di / sqrt(Dtotal).

Yes the inv-sqrt goes to infinity when Dtotal = 0, but I'll argue that this is not what should be looked at. When a validator is looking to enter the system, and they check what rate they are going to get, we need to consider the rewards they would get after they enter the system. In other words, we only care about the value of B after Dtotal = 1 (if we normalize deposits to units) or Dtotal = 32 (if we don't normalize and instead take raw rewards). When Dtotal > 0, B with inv-sqrt is a finite number, a function of the parameter k. What if we set this k too low? Then no one will validate. Therefore the inv-sqrt does not solve the problem of having set parameters too low. An equilibrium exists where no one validates because rewards are too low.

Now, I argue if we can solve (i). Based on the above, if the reward for Dtotal = 1 is infinite, then we're sure we haven't set our constants too low. There's no way we can be sure any finite value isn't too low. We can apply this argument iteratively for all values of Dtotal. The only way to be sure we haven't set the parameters too low is to have infinite rewards always. Of course this isn't a useful solution, but shows that this problem is impossible to solve usefully.

To address whether the inv-sqrt solves discouragement attacks, I'm not convinced that the linked paper proves a tight upper bound on p of 1/2, but rather only shows that discouragement attacks are profitable (?) when p > 1/2. As mentioned, setting p = 1/2 (i.e., inv-sqrt) probably solves discouragement, but we're not sure of this and it's optimistic to assume this paper covers all forms of discouragement attacks.

By the above, we can't solve the problem of having set the parameters too low, and inv-sqrt isn't guaranteed to solve the discouragement attacks. Constant rewards (i.e., set B = k * Di) do not solve the problem of having set parameters too low (same as with inv-sqrt), but do trivially make discouragement attacks non-profitable.

[adlerjohn]

I'm also not sure there's any justification for an issuance rate that's "too high." What is "too high"? 10%? 1%? It would be nice to have some justification on that end as well.

[djrtwo]

Probably the max "too high" would be the current inflation on the eth1 chain. Given that PoS validation is more efficient wrt security per unit issued than PoW, the max inflation should arguable less than the current eth1 chain

[JustinDrake]

(i) What if we set our parameters too low? Then no one will validate.

There seems to be broad consensus that targeting a max of 2^21 ETH annual issuance when the total effective balance is 2^17 ETH is a reasonable first shot. This is implemented here. If issuance is too low (e.g. we don't reach the 2M ETH as fast as we'd like) we can always review it upwards.

(ii) Is our system vulnerable to discouragement attacks?

I think this boils down to what @djrtwo said: "general approach is large enough initial v-set, honest assumption, and forced deposits". If there are discouragement attacks then the honesty assumption is flawed and we're in much deeper trouble.

Feel free to reopen an issue or PR if you feel strongly :)