Distributed Name System

Protocol Design P2P Protocols
1

In this topic we’ll explore the design of a Distributed Name System.
Here’s a brief overview of the design to start.

Design overview

The distributed identity & name system allows identities (e.g. user/topic/domain/node) to publish & update a signed map of names to records, called a zone,
which can be used for address resolution by other nodes in the network.

The system is considered a petname system where names are secure, memorable, but not global. Names are transitive and every identity starts resolving names relative to their own zone associated with their own identity.

A zone may contain records of various types, where the type can be another identity, an advertisement, or other data.

Various identity types can use this system to publish their advertisements, membership sets, etc. that is needed by various protocols in the network subsystem for creating/updating/querying bindings between different layers, such as:

  • node identity → node advert (set of transport addresses)
  • topic identity → topic advert (sets of publisher/query nodes), set of subscriber node IDs
  • domain identity → domain advert (set of nodes to send join/query requests), set of member user & node IDs
  • user identity → user advert (node IDs of user devices)

Mappings of names → identities serve as a reference to another zone that enables transitivity of names.

A zone, i.e. a map of records associated with an identity may be published, updated, and queried via a KV store backed by a pub/sub topic that is designated for the name system in each domain, where each identity may only update its own zone.
An identity may replicate its zone in multiple domains for discoverability and query speed.

Since zones are single-writer, i.e. only can be updated by the identity itself, simple read/write operations on the KV store are sufficient to implement them, however integrating it with the RDT system would make sense (once ready) for a unified data model.

The work involves defining:

  • data types for zones & records
  • update and query mechanisms
  • how it is used within Anoma

Related work:

1 Like
2

Thanks for the post, I think we should work this design out in more detail. I first wanted to ask – have you read the Identity Names section in the specs, and how do these two systems relate to each other?

3

Yes, and also talked to Isaac about it

Identity names are immutable names assigned to identities.

The name system allows mutability and different record types, not just identities.

Identity names can be thus expressed within the name system.
They were immutable in the identity name design as an update mechanism is non-trivial in a distributed system and this is the simplest design that allows assigning names to identities.

The name system design goes further to provide mutability and a generic name system with various record types.
It uses pub/sub for update dissemination, and a zone can designate one or more domains where a pub/sub topic disseminates record updates for the zone. The topic identity key corresponds to the zone identity key.