New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uptime incentives in GoS #196

Open
leoluk opened this Issue Dec 7, 2018 · 12 comments

Comments

Projects
None yet
8 participants
@leoluk
Copy link
Contributor

leoluk commented Dec 7, 2018

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

This comment has been minimized.

Copy link
Member

zmanian commented Dec 7, 2018

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.

@dlguddus

This comment has been minimized.

Copy link

dlguddus commented Dec 9, 2018

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

This comment has been minimized.

Copy link
Contributor

kwunyeung commented Dec 10, 2018

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.

@dlguddus

This comment has been minimized.

Copy link

dlguddus commented Dec 10, 2018

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

This comment has been minimized.

Copy link

bneiluj commented Dec 10, 2018

@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...

@dlguddus

This comment has been minimized.

Copy link

dlguddus commented Dec 10, 2018

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

@chris-remus

This comment has been minimized.

Copy link
Contributor

chris-remus commented Dec 10, 2018

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

This comment has been minimized.

Copy link

bneiluj commented Dec 10, 2018

@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

This comment has been minimized.

Copy link
Contributor

jaekwon commented Dec 17, 2018

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!

@dlguddus

This comment has been minimized.

Copy link

dlguddus commented Dec 17, 2018

This is super clear ! Thanks Jae !

@leopoldjoy

This comment has been minimized.

Copy link
Contributor

leopoldjoy commented Dec 17, 2018

Thanks for clearing this up!

@bneiluj

This comment has been minimized.

Copy link

bneiluj commented Dec 17, 2018

crystal clear! 🤗

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment