Uptime incentives in GoS

[leoluk]

The new ruleset states that the GoS incentive will be uptime, not stake:

To determine the winners, Tendermint will primarily consider the uptime (precommit votes on the blockchain) of the validators (operated by the original GoS signup accounts), rather than the total bonded stake or total amount of atoms held. This means that delegating or transferring stake from Sybil accounts does not directly lead to winning.

This creates a strong incentive outside of the Cosmos economics and fundamentally changes the socio-economics of the GoS. By effectively removing the proposer bonus incentive, cartels can censor with (almost) impunity.

We suggest to remove the uptime incentive. Doing so will make the GoS much more useful in validating the Cosmos consensus and economics in an adversarial real-world scenario. Otherwise, the GoS results will not be applicable to mainnet economics.

Let's discuss!

CC @SLAMPER

[zmanian]

My expectation is that accumulating stake will be used in censorship attacks.

Accumulating stake is phase 1 of winning GoS, phase 2 is executing censorship.

We will look at both uptime and stake and strategies used to make recommendations to the ICF on winners.

[Hyung-bharvest]

3% of un-consequtive missing block(can happen to a decent 3-level sentry architecture validator in remote location like asia with +150 validators around the world) will cost a validator almost 1 day of downtime in 4 weeks. It definiteley encourages remote validators to move in to US territory. Do we really need to move it??

[kwunyeung]

When more validators are in the validator set, it will be easier to miss blocks for validators having sentries and relays. If large amount of validators have small value of commit timeout, this is even worse. I have been seeing a lot of blocks time less than 3 seconds. I even see some blocks on genki-2000 have around 1.5 seconds block time. It's penalising validators with a more secure architecture.

[Hyung-bharvest]

Actually, occasional missing block does not penalisize the validator in mainnet.(no slashing, no missing rewards) Only GoS does, because of uptime emphasis by Zaki. Security is less important in GoS than in mainnet also. The whole circumstances of GoS incentivize validators to gather around US area with less security architecture.

[bneiluj]

@dlguddus I think that Security is also very important in GoS. Someone got DDOS a few days ago on the genki-1000 chain and the chain wasn't even running...

[Hyung-bharvest]

Yes I agree, but it is less important than mainnet. I express it with relativity

[cfl0ws]

It does feel like uptime and accumulation are being prioritized over security in GoS, particularly related to the downtime hit a sentry architecture will likely take over time. It does seem like short-term decisions made in GoS won't necessarily be the best longer-term decisions for Cosmos longevity.

[bneiluj]

@chris-remus Agreed!
I do believe that security should be the number one priority.
If people start getting DDOS (loose money through their provider like aws which can be very expensive per second...) or hacked in different ways, it will be very bad for Cosmos. As far as I understand, the goal of GoS is to reproduce the best economic incentive behaviours and attacks. GoS should be close to reality as much as possible.

[jaekwon]

Hi all, sorry, let me clarify what we mean by uptime.

By uptime, we're referring to the amount of blocks for which a validator is a bonded validator.
Even if a validator fails to get their signatures into the blockchain for 94% of blocks within the window, the validator will continue to remain bonded. And this is fine, as long as your validator is occasionally making its signature into the blockchain, the validator will remain bonded (not jailed), and the continuous duration of bondedness will count toward the validator's liveness.

Additionally, we will be adjusting the recommended timeout parameters to be sufficiently long so that honest validators will be able to propose blocks with most of the votes, as it should.

      "params": {
        "signed-blocks-window": "5000",
        "min-signed-per-window": "0.0500000000", // 5% requirement to remain "up"
        "double-sign-unbond-duration": "300000000000",
        "downtime-unbond-duration": "0",
        "slash-fraction-double-sign": "0.2000000000",
        "slash-fraction-downtime": "0.0000000000" // no penalty for getting jailed for downtime.
      },

Timeout updates for config:

timeout_propose = "5s"
timeout_propose_delta = "1000ms"
timeout_prevote = "3s"
timeout_prevote_delta = "1000ms"
timeout_precommit = "3s"
timeout_precommit_delta = "1000ms"
timeout_commit = "5s"

Then, it will be up to the community to figure out who is performing censorship attacks, and to adjust timeouts to be honest, or to participate in censorship attacks.

Since the % of precommit votes that get into the blockchain is low (5% within a window of 5000 blocks), it is OK for some censorship to happen. In order for a cartel to successfully censor a validator enough to become unbonded (e.g. "down"), it will require significant round delays, and it should become possible for the community to figure out who is performing this censorship attack.

So, this "uptime" requirement is actually the opposite of this thread is worried about...

3% of un-consequtive missing block(can happen to a decent 3-level sentry architecture validator in remote location like asia with +150 validators around the world) will cost a validator almost 1 day of downtime in 4 weeks.

According to our definition of "uptime", even 94% of evenly spread out missing precommits in the blockchain will result in 0 days of downtime.

Sentry away!

[Hyung-bharvest]

This is super clear ! Thanks Jae !

[leopoldjoy]

Thanks for clearing this up!

[bneiluj]

crystal clear! 🤗