anchor.diff:  can then take over the role of validating certificates on clients' behalf.
   
   As the client half this relationship can be maintained from within a library
  -such as `cueball`, this will ease integration for headnode services -- they will
  +such as `cueball`, this will ease integration for core services -- they will
   merely need to use the `cueball` library to manage their connections and will
   then get identity validation on their outgoing connections "for free".
   
  
positive.code: few contexts in which authenticating individual instances (zones) on the system
  is useful.
  
  This particularly applies in the context of headnode service zones in Triton,
  where it would be desirable for each service to be able to authenticate itself
  to any other service, giving a path forward to eliminate the special "trusted"
  status of all hosts on the admin VLAN.
  
negative.code: Once the gossip process has stabilized, all CNs in the system are aware of the
  identities and keys of nodes that are authorized to act as Trusted CNs (hosting
  core Triton services). This means that zone certificates presented by zones on
  these CNs can be validated, authenticating core services to each other.
  
  It is important to note that changes to the set of Trusted CNs are expected to be
  infrequent, so it is not important to use a distributed system here that offers
  