## 5 Applying the Guidelines to Well-Known Decentralized Systems
### PGP Keyservers  
Pretty Good Privacy (PGP) [53] is a de-facto standard for cryptographic identities used to secure email, providing cryptographic signatures and encryption. These identities are often uploaded and shared at PGP keyservers. These keyservers form a decentralized network in which users upload their key to one of the servers, but the servers need to update each other in order to keep the global set of public keys available for any user that requests keys from other users. Moreover, users validate (sign) each other's keys in a distributed manner, forming a \"web of trust\". Below, we describe how each of the guidelines applies to this system.  
When [PERSON] receives a signed message from [PERSON], she needs to verify that the signature indeed belongs to [PERSON]. A first approach for this verification is to find a signed message from a person [PERSON] trusts stating they trust that the key belongs to [PERSON]. This is the basis of the web of trust for PGP identities. In this simplified first approach, this is a non-monotonic query, since if a signature from a trusted person says that the key belongs to [PERSON], no new information would override that statement. Following Guideline 1, if we do not need strong availability, we do not need coordination technologies. This is true for many uses of PGP, where users simply share their keys with the few relevant people that they use PGP to communicate with. Still, public keyservers have emerged for convenience, and in these systems, users could upload their public keys with the signatures of the keys they trust.  
However, people soon realized that keys could be compromised or that people could revoke the trust they shared about a public key. Thus, the question of whether to trust a key can change in the face of new information, making the system non-monotonic. Facing this issue and following Guideline 2, the system designer should chose whether consistent behavior is acceptable or not (i.e. if it is required to stop trusting a key as soon as the owner or the trusted parties revoke their trust). Many PGP users believe this is a strong requirement and therefore use keyservers to share and update information about trusted keys. With respect to the operations of trusting and revoking trust of a key, Guideline 3 ensures that we will eventually achieve consistency (e.g., once the user receives meaningful revocations). However, trusting cryptographic keys is considered by many to be an issue with strong consistency requirements, as it is dangerous to trust a key that has been compromised. Thus, as Guideline 4 states, there is a need for coordination technologies. In the case of the PGP web of trust, this is achieved by a network of keyservers that update each other and that users can query whenever they need to verify the status of a public identity. Indeed, some have proposed the use of the Blockchain for this strong consistency requirement [54]. However, as we have discussed above when referring to Guideline 3, we are considering a problem in which meaningful consistency is eventually achieved. Thus, we might argue that the Blockchain is actually not needed, and a network of public keyservers that keeps updated information might be sufficient.  
\begin{table}
\begin{tabular}{c c c} \hline \hline  & **Weak Consistency** & \
\begin{tabular}{c} **Eventual** \\ **Consistency** \\ \end{tabular} & **Strong Consistency** \\ \hline \multirow{4}{*}{**Weak availability**} & No need for & \multirow{4}{*}{
\begin{tabular}{c} Logical Monotonicity \\ or Blockchain \\ (Guidelines 1, 4) \\ \end{tabular} } \\  & coordination & & \\ technologies & & \\ \cline{1-1}  & & \\ \cline{1-1}  & & \\ \cline{1-1}  & & \\ \cline{1-1}  & & \\ \cline{1-1}  & & \\ \cline{1-1}  & & \\ \hline \hline \end{tabular}
\end{table}
Table 1: Guidelines summary.