Prevent validators from being penalized when the chain is not finalizing

[3esmit]

trafficstars

Because Medalla testnet does not have real incentives (besides testing and learning about ETH 2.0), ocasionally the number of Voted does not reach 60%. When this situation happens, some honest nodes start being penalized. This is what happened to my node, which at the time was always connected to 79 peers, using Nimbus, which is working fine in when blocks are finalizing.

My node pubkey is a40237ae62e6cbf4f65d82ea90ea7862346da553543d00466b655de5e655a0ca2e8a4fede966762bc12f268266da1f7a

This is my earnings graph (don't mind my double deposit test)

However, in meanwhile my node was operating correctly as beaconcha.in shows:

And also shows operating normally in beaconscan:

This penalizations seem to align with the chain liveness graph:

I believe this is bug, so I started a discussion in ETH 2.0 Discord, and this were the main points made:

• @nisdas stated that I shouldn't be penalized unless I am voting in the wrong head. If that is the case, how can I configure my validator node to vote in the correct head? Is possible to identify what is the correct head? @nisdas also agreed that "is a gap that should be fixed"

• Adrian Sutton (pegasys) noticed that

  "There's an important difference between the inclusion difference that Beaconcha.in shows and what is used for paying rewards. Rewards are paid strictly on how many slots after the attestation slot it was included in a block. There's no allowance for empty slots. Beaconcha.in does give an allowance for empty slots so reports 0 inclusion distance even when the actual inclusion distance is higher and so rewards are lower. Beaconcha.in's value is useful for determining if your validator is doing the best it can, but it does mean you can have perfect 0s on beaconcha.in and still lose money because attestations weren't included in the next block (because it was not created)."

  ok, but that is not the main issue, but that a honest validator shouldn't be penalized, specially in a period which they are really needed.

• As @nisdas said,

  "(Beaconcha.in) It shows a validator as stable and running normally when its actually being penalised"

  which is something confusing and strange.

• Adrian Sutton (pegasys) added that

  "You are dependent on other nodes not just to create the next block, but also to propagate your individual attestation, include it in an aggregate and propagate that aggregate."

  I understand the issue, and I think that this needs to be solved unless there is a technical limitation for it.

• @nisdas

  In a period of non-finality the best outcome is that they are neutral so you arent penalised.

  Wouldn't this incentive nodes to behave in self interest during this scenario?

• jqm:

  "Worth pointing out that effectiveness != reward, so "differs from the spec" isn't really accurate. Attestation effectiveness is a derived value, useful for some purposes as you mentioned above, but not so useful for others (calculating the Ether reward)."

• randomuser said that

  "I don't think that you lose out if you're included in the first block that you could. It doesn't really make sense to lose eth if you're node is running properly. " "But I could still see that you should not lose if you got into the next available slot, and then you should break even. The loss would then occur only in the case where you don't get into the next available slot, in which case you wouldn't break even. That would work pretty well, since on average the same proportion of blocks are being produced as attestations, so there wouldn't be to much overflow. The algorithm that they say there could still work. Is that how it goes?"

I understand that in a livenet this scenario would be very unlikely, because there is high economic incentives to keep nodes running, however I see that this scenario can become reality in a possible real world events like "implementation bug", "protocol bug", "fail of submarine communications cable", "draconian crypto laws", "worldwide natural disasters", "war", etc, therefore I believe that if is possible to make this scenario more stable, it should be done.

Related issue: https://github.com/ethereum/eth2.0-specs/issues/2098

[mratsim]

This was already fixed in the past, likely for another scenario since it seems to happen again https://github.com/ethereum/eth2.0-specs/pull/1830 https://github.com/ethereum/eth2.0-specs/issues/1370

[djrtwo]

This is a known issue due to (very likely) sparse block proposals during an inactivity leak. The amount penalized is very small but serves no game theoretic purpose and is clearly discouraging for users.

This is planned to be fixed at Phase 1

[pintail-xyz]

I disagree that the amount being penalised is small. As an example, one of my validators has missed only a single attestation in the last 24 hours, but its balance is down 0.05 ETH over that time. According to beaconcha.in almost all attestations were included at an inclusion distance of 0. It feels like my validator has been very reliable in difficult network conditions and yet is being punished harshly.

Why wait until phase 1 to fix this? This seems like a significant weakness in the spec to me.

[mcdee]

As a counterpoint, another validator lost less than 0.01 Ether over the same period.

It would be nice to fix this, but I don't see it as in any way critical to the launch of phase 0. Any change could introduce subtleties that make sustained periods of inactivity possible with little or no penalty, and I'd rather they were discussed in detail and prototyped than put in as a "quick fix".

Also worth pointing out that any loss made during the period of inactivity leak should be made up (and more) pretty quickly once the inactive validators are kicked, as rewards will increase due to fewer active validators.

[pintail-xyz]

Fair enough. I'm certainly not advocating taking shortcuts to a quick fix. However I think it's worth understanding how severely different validators are being punished and why. Time for some more Medalla data analysis I guess...