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

View changes in idle conditions #3103

Closed
mversic opened this issue Feb 1, 2023 · 3 comments
Closed

View changes in idle conditions #3103

mversic opened this issue Feb 1, 2023 · 3 comments
Labels
Consensus This issue is related to the Sumeragi consensus iroha2-dev The re-implementation of a BFT hyperledger in RUST question Further information is requested

Comments

@mversic
Copy link
Contributor

mversic commented Feb 1, 2023

The whitepaper states that once a valid set A is found it should be kept, i.e. not mixed with set B until there is a consensus failure. From a performance perspective this makes sense, we don't want to waste time on determining non-faulty peers that comprise set A on every sumeragi round

The question is whether we want to do view changes when there are no transactions. Current situation is such that we do view changes every time a block isn't produced in due time. A block may not be produced because of faulty peers in set A or because there are no transactions.

Benefits

  • mitigates censorship - otherwise the same set of nodes (namely the set A) will always be validating peers unless one of the nodes becomes faulty. Low contention is the perfect time to bring in observing nodes to consensus and, consequently, recreate sets A and B. Mitigating censorship is the reason why we change set Apeer roles as per the whitepaper
  • negligible performance impact

Downsides

  • to be discussed

This discussion is relevant

@mversic mversic added Consensus This issue is related to the Sumeragi consensus iroha2-dev The re-implementation of a BFT hyperledger in RUST question Further information is requested labels Feb 1, 2023
@Erigara
Copy link
Contributor

Erigara commented Feb 2, 2023

One downside i observed so far is that if idle state continues for large amount of time view change proofs we send with every message became bigger and bigger slowing down message processing.
Situation will be better after #3110 where i use more efficient way to merge view changes, but problem still there.
Maybe we should reconsider how we transfer proofs.

@mversic
Copy link
Contributor Author

mversic commented Feb 17, 2023

Since the #3166 bug we're not doing view changes on idle. Should we or should we not can still be discussed in this ticket

@appetrosyan appetrosyan pinned this issue Jul 25, 2023
@nxsaken nxsaken added this to Iroha Sep 11, 2024
@nxsaken nxsaken moved this to Roadmap in Iroha Sep 11, 2024
@mversic
Copy link
Contributor Author

mversic commented Oct 8, 2024

not relevant anymore

@mversic mversic closed this as completed Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Consensus This issue is related to the Sumeragi consensus iroha2-dev The re-implementation of a BFT hyperledger in RUST question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants