PIP-24: Change Proposer on Double Proposing
| Authors | B00f (@b00f) |
|---|---|
| Discussion | View Discussion PIP-24 |
| Category | Core |
| Created | 10-05-2024 |
Table of Contents
Abstract
This proposal suggests initiating the āchange proposerā phase 1 once a second signed proposal is received, regardless of its validity.
Motivation
Based on some observations, we have discovered that some validators in the network are running duplicated nodes. The current consensus detects double proposals and ignores them. The procedure is as follows: Once an honest validator receives a proposal, it validates it. If valid, it broadcasts a prepare vote to other validators. Upon receiving a second proposal, the validator checks if they have already voted for a valid proposal. If so, they simply ignore the second proposal to prevent double voting.
Sending a double proposal, in theory, should reduce the chances for validators to get rewarded. For example, if validator Vb sends 2 valid proposals P1 and P2 to other validators, half of the network may receive P1 and the rest receive P2. In this scenario, neither proposal can secure 2/3 of the prepare votes. Consequently, validators will initiate a change in the proposer phase after some time.
However, in practice, the double proposer often still manages to get rewarded. Here are some reasons:
-
In some cases, one of the proposals is invalid, especially if the validator runs two different versions of Pactus. It is quite possible that the older version produces an invalid block. Since the majority of the nodes are running the latest version, the outdated proposal will get ignored, and only one proposal will be voted on.
-
Due to network topology and time differences between validators, one proposal can be received by the majority of the validators faster. Therefore, the first proposal can garner 2/3 of the votes before the second proposal causes vote divergence.
This proposal suggests starting the āchange proposerā phase once the second signed proposal is received by the validators, no matter its validity. By doing so, validators will have no incentive to run duplicated nodes.
Specification
Backward Compatibility
Security
References
Copyright
Copyright and related rights waived via CC0.