Replies: 9 comments 1 reply
-
|
Can you define in more detail what you mean by "sub group of validatorSet"? For understanding, the validator set defines: (i) the validators (using public validator keys) and (ii) the voting power associated to each of them. The vote set abstraction uses the validator set ( |
Beta Was this translation helpful? Give feedback.
-
Can you be more specific? For instance, can you provide the output of the test unit that is failing? |
Beta Was this translation helpful? Give feedback.
-
|
It's not important how to take sub group. we can take 2/3 or more small validators from hvs.valSet. They all have same 30 as a voting power, we've changed precommit valSet as a subgroup, so total power is just 90. to avoid validator index issue in vote message, I've customized consensus/state.go file like this In this case, validators which don't included to sub group, will not make vote at precommit step. In byzantian test case 1, I'm getting timeout issue. Of course at block height 2, duplicated prevote doesn't success in consensus so did not more state machine to precommit step. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @dedicatedDev for opening this issue. I understand your attempt to - At the Precommit step, take more smaller subgroup than the prevote validator group. What I don't understand is the what you are trying to achieve by this change. To me it seems unreasonably complicated to change the protocol. Even if were done (again fairly complicated) it would also introduce liveliness and security issues. Again, if we could understand the final goal, we might be able to suggest alternatives. |
Beta Was this translation helpful? Give feedback.
-
|
final goal, we wanna decrease telecommunication complexity and link 1k+ validators |
Beta Was this translation helpful? Give feedback.
-
Actually, it is. The protocol is correct as long as a set of assumptions regarding the composition of the validator set and the distribution of voting power between correct and Byzantine processes are observed. And its based on this information that we can produce the quorums required for ensure a correct operation of the protocol. Probably it is worth noting that defining quorums based on the system size and failure assumptions is an assumption of any consensus protocol I am aware of, not only for Tendermint. Regarding the composition of the quorums (a quorum is the minimum size of a subset of validators, weighted by voting power, which have to vote identically to enable state transitions on the consensus protocol), the main property that has to be observed is that any two quorums must have an intersection that includes a correct process. In the standard scenario, considered by the pseudo-code of Tendermint, in a system with Adopting different quorums (sizes) for different steps or rounds of the algorithm is something never really considered for Tendermint. I mean, we are unaware of any proposal in this direction that has been evaluated and proved correct. There are, however, in the literature proposals of flexible quorums for consensus algorithm, several of them. So, this approach is feasible, in general terms, but never really considered for Tendermint. To conclude, your proposal of having |
Beta Was this translation helpful? Give feedback.
-
|
okay, but I guess quorum is defined as a 2/3 of total power + 1 in current implementation. And then, prevote, and precommit is separately independently so if we use different quorum or not, it doesn't affect pervious step at all. |
Beta Was this translation helpful? Give feedback.
-
|
This is an interesting conversation and I suggest we convert this issue into an discussion and brainstorm further. |
Beta Was this translation helpful? Give feedback.
-
Indeed, for example: https://fpaxos.github.io/
That's a great goal 👍 We're (@informalsystems) working on reducing the amount of data sent between peers, specifically block parts and mempool transactions (see https://forum.cosmos.network/t/proposal-cosmos-hub-adopt-the-skip-block-sdk/11641/35?u=melekes). As for your proposal, I'd love to see a prototype (plus a TLA+ spec to ensure correctness and liveness properties) for an algorithm you've described. Do you have time to work on this? |
Beta Was this translation helpful? Give feedback.
-
|
yep, I've already fully implemented this. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Protocol Change Proposal
Summary
Hello. I wanna use sub group of validatorSet in precommit step.
For example.
consensus/types/height_vote_set.go
something like this.
In this case, valIndex of Vote message is wrong so it can be flxed again to get from precommitValSet.
Some validator will exclude in precommit voting mechanism.
Looks working correctly but I'm failing byzantian_test (consensus/byzantian_test.go), test case failed because of evidence problem.
Problem Definition
Decrease more to reduce communication complexity.
Beta Was this translation helpful? Give feedback.
All reactions