Design goals for a a privacy-preserving PoS optimized networking protocol

[Mikerah]

In order to properly design an anonymity (privacy-preserving as the cool kids call it these days) for PoS systems (might be also applicable to PoW systems but for chains like Zcash and Monero), we need a set of design goals to aim towards. This can be an evolving list of design goals based on feedback.

Design goals

• Low-latency: Due to the heavy emphasis on fixed block times in PoS systems, validators cannot afford to send information across the network later than necessary. Otherwise, they risk getting penalized by the protocol. Ideally, we want to have 0 latency compared to the default networking protocol.
• Accountable: In the protocol, there should be a way to find misbehaving nodes. Otherwise, this can have devastating effects on the higher-level PoS protocol due to the need for long-lasting identities. This can be achieved either by cryptographic means, cryptoeconomic means or a combination of both.
• Forward-secrecy: If keys are compromised, then it should be hard to find out any information from the other peers with regards to previously signed information in the network.
• Peer-to-peer: The anonymity systems of yesteryear are all in the client-server model. These scale well, however, they go against the ethos PoS systems as they aren't decentralized.

[Mikerah]

More design goals:

• Secure against a GPA: GPAs (e.g. NSA) are a real threat as shown by the various concrete attacks on low-latency protocols like Tor. In fact, it may be impossible to design a system that is both secure against a GPA and is low-latency.
• Composable: As the goal of this protocol is to be deployed for validators, it would be nice to have it be composable with another anonymity network for users. For example, in practice, one could compose onion-routing with mixnets for different usecases. There may be a way to do that here as well.

[Mikerah]

To read: https://www.freehaven.net/anonbib/cache/wiangsripanawan-acsw07.pdf to see if one can design such a protocol with both resistance against a GPA and be low-latency.

[Mikerah]

Another important design goal:

• Byzantine fault tolerant