SIP-025: Iterating towards WSTS #183
Conversation
There was a problem hiding this comment.
I have read the PR and first of all I have to say: very well written! Finally a team that takes care of clearly explaining (and presenting) the challenge, proposed solution and the necessary adaptations needed to speed up these major changes.
Secondly, is it possible for the protocol to know the Liveness and Safety of other nodes, create a list of top performers, pick one random or round robbin as coordinator, and put it in standby for an X amount of next blocks? The Byzantine problem will always exist, but the chances of using a faulty signer will decrease by identifying well-performing signers imo. Please correct me if wrong. Trying to think outside the box.
It would be a slight adaptation to BFT Paxos, but it might be worth considering as it is a custom implementation which not only shows the skill level of the team by increasing the effectiveness of BFT Paxos, it also decreases the use of a faulty signers and it also shows how important well-running signers are in the ecosystem. You could even show the status of well-performing signers on the explorer as a social gimmick, further increasing active involvement.
There was a problem hiding this comment.
We understand the necessity of this change, having integrated the WSTS implementation for signing in the decentralized mining pools. In our case, a faulty coordinator means no participation in the mining process on that pool, allowing users to switch to another pool. However, in the PoX mechanism, a faulty coordinator significantly impacts block finality, as no signatures are produced during that cycle. Addressing this issue is crucial. The two-iteration proposal is practical: the first iteration allows for quicker implementation with minimal impact aside from block size. The second iteration, while the ideal solution, may take too long for Nakamoto 3.0 at this stage. Therefore, implementing it after the first iteration makes sense.
Additionally, although it may be outside the scope of this SIP, it seems necessary to penalize faulty coordinators more than faulty signers, as they disrupt the flow significantly. Penalties could include suspending their participation for a certain number of cycles or allowing them to stack but burning their rewards instead of transferring them. The severity of penalties should escalate with repeated faults. Regarding @crypt0jan point about the ranking system, there is concern that someone with a consistently higher ranking may not want to be the coordinator in most cycles.
|
This SIP is clear on its reasons and also the context of the plan to implement full WSTS in the future. Acrossfire (SIP Editor) - putting forward SIP Editor approval |
This PR proposes SIP-025, which is a simpler and more robust but less space-efficient signature scheme for Nakamoto block headers. It is a rider SIP, meaning that it will only activate if SIP-021 activates and some additional criteria are met.