Concerns Regarding Open Participation in Running Validators on TFChain

[sameh-farouk]

Summary

The recent proposal/movement to allow anyone to run a validator on our PoA-based Substrate blockchain raises some concerns. While this initiative aims to enhance network security, based on the nature of PoA networks and our existing setup, I believe it may introduce more challenges than benefits.

I attempted to express my concerns on a related issue a few months ago and explained them to @coesensbert as well, but I believe they will be more noticeable here.

Details and Concerns

1. PoA vs PoS Validator Dynamics

• In PoS (Proof of Stake) networks, slashing and staking mechanisms ensure validators act responsibly. Even if a few validators miss their assigned slots, the impact is minimal since the network typically has a backup consensus mechanism in place.
• However, PoA networks operate differently. We don’t use slashing or staking, and our validator set is intentionally small and trusted. If a validator goes offline, the network suffers from increased latency and degraded performance since each validator plays a crucial role.

2. Impact on Block Production

With a small validator set, any downtime from a validator has a noticeable impact.

Example:

• 10 validators, 6-second block time.
• If one validator goes offline, the block time increases by 10%, and it takes 66 seconds to produce 10 blocks instead of 60.
• If two validators go offline, it takes 72 seconds for 10 blocks, and the delays increase further with additional failures.

During that outage, with just 2 validators down, a simple transaction could take more than 12 seconds to resolve. Additionally, since we don’t control these validators, we won’t be able to address the issue in a timely manner.

3. Challenges of Open Validators in PoA Networks

• Unlike PoS, we cannot enforce slashing or economic penalties for misbehavior or downtime.
• Allowing anyone to run a validator increases the likelihood of unresponsive or poorly maintained nodes.
• Even if we distribute validators geographically, adding more unvetted validators introduces uncertainty and inconsistency, potentially causing latency and poor user experience.

4. Current Setup Already Ensures Security and Redundancy

• We already run multiple validators across different locations, ensuring redundancy and fault tolerance.
• Adding more, less reliable validators may not increase security but could instead destabilize block production if even a few nodes become unresponsive.

Recommendation

Instead of opening validator participation to anyone, we could:

• Define a clear answer to why we need to pursue this and explore better redundancy measures within the current trusted validator set to improve fault tolerance, if needed, without introducing unreliable nodes.

Alternative

Yet, if there’s a strong justification to proceed with this approach—despite the concerns raised—and it outweighs the required effort, we can move forward only by implementing runtime logic for automatic offline detection and resolution. This logic can kick these offline authorities out of the active set, and the network would not wait for them to produce blocks. The average block time would then recover after some time. While this solution won’t entirely prevent network degradation, it will help enable auto-healing.

Conclusion

Given the nature of PoA networks, proceeding with open validator participation might result in latency issues, block delays, and degraded user experience. Our current model of multiple, geographically distributed validators already provides adequate security and redundancy. I recommend that we reconsider this proposal or explore safer alternatives to improve network resilience.
@xmonader @renauter @LeeSmet

[xmonader]

@despiegk what do you suggest

[renauter]

Is the idea here to open validator participation in our already existing PoA system ?
Like switching for a PoS design but without staking/slashing mechanisms ?
If this is the case here are some inputs around it:

Opening validator participation fundamentally conflicts with PoA's design principles.
It's like trying to transform a trusted committee system into a public voting system while keeping the committee's operating rules.
The fundamental structure wasn't designed for this kind of open participation.

Core PoA Principles:

• Trust-Based System
  • Validators are specifically chosen for their reputation
  • Network security relies on known, accountable entities
  • Identity verification is crucial
• Intentional Design Limitations
  • Small validator set by design
  • Each validator has significant responsibility
  • Network optimized for limited participants

Challenges when opening participation:

• Trust Dilution
  • Can't properly vet all new participants
  • Reduced accountability
  • Higher risk of malicious behavior
• Performance Issues
  • Network designed for small validator set
  • Block production becomes less predictable
  • No economic penalties (unlike PoS) for poor performance
• Operational Conflicts
  • Original PoA benefits lost (quick consensus / predictable block times / easy coordination)
  • No built-in mechanisms to handle unreliable validators
• Security Concerns
  • No financial stake to ensure good behavior
  • Harder to maintain network quality
  • More complex coordination needed