Skip to main content

NOMOS-DA-NETWORK

Introduction​

NomosDA is the scalability solution protocol for data availability within the Nomos network. This document delineates the protocol's structure at the network level, identifies participants, and describes the interactions among its components.
Please note that this document does not delve into the cryptographic aspects of the design. For comprehensive details on the cryptographic operations, a detailed specification is a work in progress.

Objectives​

NomosDA was created to ensure that data from Nomos zones is distributed, verifiable, immutable, and accessible. At the same time, it is optimised for the following properties:

  • Decentralization: NomosDA’s data availability guarantees must be achieved with minimal trust assumptions and centralised actors. Therefore, permissioned DA schemes involving a Data Availability Committee (DAC) had to be avoided in the design. Schemes that require some nodes to download the entire blob data were also off the list due to the disproportionate role played by these “supernodes”.

  • Scalability: NomosDA is intended to be a bandwidth-scalable protocol, ensuring that its functions are maintained as the Nomos network grows. Therefore, NomosDA was designed to minimise the amount of data sent to participants, reducing the communication bottleneck and allowing more parties to participate in the DA process.

To achieve the above properties, NomosDA splits up zone data and distributes it among network participants, with cryptographic properties used to verify the data’s integrity. A major feature of this design is that parties who wish to receive an assurance of data availability can do so very quickly and with minimal hardware requirements. However, this comes at the cost of additional complexity and resources required by more integral participants.

Requirements​

In order to ensure that the above objectives are met, the NomosDA network requires a group of participants that undertake a greater burden in terms of active involvement in the protocol. Recognising that not all node operators can do so, NomosDA assigns different roles to different kinds of participants, depending on their ability and willingness to contribute more computing power and bandwidth to the protocol. It was therefore necessary for NomosDA to be implemented as an opt-in Service Network.

Because the NomosDA network has an arbitrary amount of participants, and the data is split into a fixed number of portions (see the Encoding & Verification Specification), it was necessary to define exactly how each portion is assigned to a participant who will receive and verify it. This assignment algorithm must also be flexible enough to ensure smooth operation in a variety of scenarios, including where there are more or fewer participants than the number of portions.

Overview​

Network Participants​

The NomosDA network includes three categories of participants:

  • Executors: Tasked with the encoding and dispersal of data blobs.
  • DA Nodes: Receive and verify the encoded data, subsequently temporarily storing it for further network validation through sampling.
  • Light Nodes: Employ sampling to ascertain data availability.

Network Distribution​

The NomosDA network is segmented into num_subnets subnetworks. These subnetworks represent subsets of peers from the overarching network, each responsible for a distinct portion of the distributed encoded data. Peers in the network may engage in one or multiple subnetworks, contingent upon network size and participant count.

Sub-protocols​

The NomosDA protocol consists of the following sub-protocols:

  • Dispersal: Describes how executors distribute encoded data blobs to subnetworks. NomosDA Dispersal
  • Replication: Defines how DA nodes distribute encoded data blobs within subnetworks. NomosDA Subnetwork Replication
  • Sampling: Used by sampling clients (e.g., light clients) to verify the availability of previously dispersed and replicated data. NomosDA Sampling
  • Reconstruction: Describes gathering and decoding dispersed data back into its original form. NomosDA Reconstruction
  • Indexing: Tracks and exposes blob metadata on-chain. NomosDA Indexing

Construction​

NomosDA Network Registration​

Entities wishing to participate in NomosDA must declare their role via SDP (Service Declaration Protocol). Once declared, they're accounted for in the subnetwork construction.

This enables participation in:

  • Dispersal (as executor)
  • Replication & sampling (as DA node)
  • Sampling (as light node)

Subnetwork Assignment​

The NomosDA network comprises num_subnets subnetworks, which are virtual in nature. A subnetwork is a subset of peers grouped together so nodes know who they should connect with, serving as groupings of peers tasked with executing the dispersal and replication sub-protocols. In each subnetwork, participants establish a fully connected overlay, ensuring all nodes maintain permanent connections for the lifetime of the SDP set with peers within the same subnetwork. Nodes refer to nodes in the Data Availability SDP set to ascertain their connectivity requirements across subnetworks.

Assignment Algorithm​

The concrete distribution algorithm is described in the following specification: DA Subnetwork Assignation

Executor Connections​

Each executor maintains a connection with one peer per subnetwork, necessitating at least num_subnets stable and healthy connections. Executors are expected to allocate adequate resources to sustain these connections. An example algorithm for peer selection would be:

def select_peers(
    subnetworks: Sequence[Set[PeerId]],
    filtered_subnetworks: Set[int],
    filtered_peers: Set[PeerId]
) -> Set[PeerId]:
    result = set()
    for i, subnetwork in enumerate(subnetworks):
        available_peers = subnetwork - filtered_peers
        if i not in filtered_subnetworks and available_peers:
            result.add(next(iter(available_peers)))
    return result

NomosDA Protocol Steps​

Dispersal​

  1. The NomosDA protocol is initiated by executors who perform data encoding as outlined in the Encoding Specification.
  2. Executors prepare and distribute each encoded data portion to its designated subnetwork (from 0 to num_subnets - 1 ).
  3. Executors might opt to perform sampling to confirm successful dispersal.
  4. Post-dispersal, executors publish the dispersed blob_id and metadata to the mempool.

Replication​

DA nodes receive columns from dispersal or replication and validate the data encoding. Upon successful validation, they replicate the validated column to connected peers within their subnetwork. Replication occurs once per blob; subsequent validations of the same blob are discarded.

Sampling​

  1. Sampling is invoked based on the node's current role.
  2. The node selects sample_size random subnetworks and queries each for the availability of the corresponding column for the sampled blob. Sampling is deemed successful only if all queried subnetworks respond affirmatively.

Network Schematics​

The overall network and protocol interactions is represented by the following diagram

Details​

Network specifics​

The NomosDA network is engineered for connection efficiency. Executors manage numerous open connections, utilizing their resource capabilities. DA nodes, with their resource constraints, are designed to maximize connection reuse.

NomosDA uses multiplexed streams over QUIC connections. For each sub-protocol, a stream protocol ID is defined to negotiate the protocol, triggering the specific protocol once established:

  • Dispersal: /nomos/da/{version}/dispersal
  • Replication: /nomos/da/{version}/replication
  • Sampling: /nomos/da/{version}/sampling

Through these multiplexed streams, DA nodes can utilize the same connection for all sub-protocols. This, combined with virtual subnetworks (membership sets), ensures the overlay node distribution is scalable for networks of any size.

References​

Copyright and related rights waived via CC0.