Introduction

NomosDA reconstruction is the sub-protocol for gathering encoded shares of data from the NomosDA network so the original data can be restored. This sub-protocol is available to any client that may require it.

Objectives

NomosDA reconstruction aims to provide clients with a method of recovering specific shares of encoded data for further decoding and restoration of the original published data. The data needs to be:

Publicly available. Anyone should be able to engage in data reconstruction.
Verifiable. Clients should be able to verify the downloaded shares of data.

Overview

DA nodes offer a single HTTP API entry point for querying. Nodes may store more than a single share of that data because they are members of different subnetworks and may return all the shares they have on demand.

Once clients have gathered enough shares, they can perform local reconstruction to obtain the original data.

Protocol

Glossary

Name	Description	Representation
`DALightShare`	Contents of a share of a blob. Same as sampling data ‣	`DALightShare` ‣
`ShareIndex`	Index of the share. There are `sample_count` (from `0` to `sample_count - 1`) as per the encoding. It matches the number of subnetworks.	`u16`

Client flow

The reconstruction process proceeds as follows:

The client needs to find the list of DA nodes at the time the blob was originally dispersed.
The client requests the pertinent blob through the get-blob endpoint. ****A node may have one or several different blob shares. Clients may need to send requests to different nodes to get all the required shares.
The client receives a set of DALightShare corresponding to the different shares the node is storing that are relevant to the request.
The client validates all shares as per the encoding specification.