Skip to content
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

Delay validator set changes by 1 block in the SDK to reflect changes in Tendermint #1789

Closed
jaekwon opened this issue Jul 23, 2018 · 7 comments

Comments

@jaekwon
Copy link
Contributor

jaekwon commented Jul 23, 2018

Corresponding PR on Tendermint: tendermint/tendermint#1815
We need this for launch, as lite requires it.

Please sync with me for any issues or questions, and Ethan for timeline for merging on the tendermint side.

@rigelrozanski
Copy link
Contributor

yeah bucky and I were talking about this -
It would be nice to have some kind of linkage here rather than just (more or less arbitrarily) having a block delay in the SDK with a comment explaining that it just happens this way in tendermint.

Ideally we need some kind of a response from abci that a validator has actually entered the tendermint validator set - OR alternatively - if this "1-block" is some kind of a genesis constant (I don't think it is though) - we could could just read it in - which could help code comprehension. What do you think? Not totally adverse to just hard-coding it with a comment, I just think it's not ideal (prone to slip-ups also if this changes in Tendermint at some point in the future too)

@jaekwon
Copy link
Contributor Author

jaekwon commented Jul 24, 2018

I think it won't change until Tendermint v2, so it's something hard-coded.
We can always upgrade in a backwards compatible way to pass more info, but I think it would be fine to assume that the sdk know and deal with this.

Tendermint <> SDK <> App, and I think we can assume that SDK developers can deal with these quirks for general app developers. And if not, we can introduce new measures down the line. For launch lets just hard-code it.

@cwgoes
Copy link
Contributor

cwgoes commented Jul 25, 2018

This needs to also change slashing logic since "contributing stake" is now offset by one block - if you unbond at block n, your stake now can contribute to a Byzantine fault at block n+1.

@cwgoes
Copy link
Contributor

cwgoes commented Aug 24, 2018

Subset of #2142 (or maybe a duplicate, but leaving both for now).

@rigelrozanski
Copy link
Contributor

As Jae and I discussed a while ago these changes do not affect staking in any real way - only slashing

@cwgoes
Copy link
Contributor

cwgoes commented Aug 28, 2018

As Jae and I discussed a while ago these changes do not affect staking in any real way - only slashing

We need to modify Slash(), which is in the staking module (should it be? a question for another time...) - but if you mean otherwise, I guess not, although some of the queries will return confusing results (the SDK will think a validator is bonded before it actually signs blocks in Tendermint, for example).

@rigelrozanski
Copy link
Contributor

In the medium term I think it makes sense to have these to entirely aligned to avoid confusion - it's only prelaunch that I'm not concerned about - there are a few very fundamental changes which are required to be made for staking to fully align with tendermint - but it barely affects the functionality.

Yeah I'll think about the best way to move Slash() out of staking - may still make sense there in the end however

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

No branches or pull requests

4 participants