Author: @Álvaro Castro-Castilla
The key points where everything derives from are:
- As a base case, nodes are run in laptop devices with intermittent connectivity and a home connection. We will also support desktops, and mid-resource machines potentially (Raspberry Pi)
- UI and configuration should be trivial: users should not be selecting many options. The one thing they should might be privacy control, but nothing of the likes of “type of node", whether “to mix or not", etc. The objective is to make validating dumb-easy.
- Credible neutrality. The primary purpose of Private PoS is to support credible neutrality, by mitigating self-censorship (alongside DA and the ZK verification-only CL).
The secondary purpose is to hide large-stake nodes. This secondary purpose can only be achieved with tradeoffs, which should be at least partially optional or configurable to nodes as it has a high cost.
Technical requirements derived from this end-game:
- Simplicity.
- Only the minimal incentives required (avoid bloat and complexity)
- All nodes participate.
- Have a single type of node. Avoid at all costs having specialized roles (for example for measurement or control).
- The bandwidth requirements should be viable for home connections. A good starting point is 500kb/s, with half dedicated to consensus and half to DA. This is a tentative initial value.
- Not require on-chain registration, or bonding. Providing a proof of minimum stake (what we call Proof of Validator) is required to avoid Sybils, but it should be a dynamic process that doesn't require writing to the ledger. A solution for this is to distribute the required information off-chain via membership protocols / gossipping, assuming eventual consistency guarantees.
- Allow the leader nodes to increase communication reliability (even at some cost) in the event of network congestion, unreliability or attack.
- Allow the leader nodes to increase anonymity guarantees, even if at the cost of higher fees and/or lower communication reliability.
Design Framework
This is the current working proposal. The design reflects all the requirements described here, although thorough analysis and simulation is necessary.
It is likely that issues are found, which need to be solved. In this case, the desired path is to work incrementally with modifications. If some component or layer isn't working