DA nodes should provide a simple api for any node to read and write data blobs, and be agnostic to the underlying DA blob encoding scheme.
General Nomos DA flow
- Data Object is “chunked” by the Zone
- Chunks are dispersed to the nodes (ideally all)
- In the DA node, the chunk is held in memory until the block with related certificate is received
- Attestation about received chunk is sent back to the Zone
-
The certificate (Blob Certificate in Block - ‣) is created after Zone receives the attestations from the nodes that they will try to “persist” the chunks.
-
The certificate is sent to the DA mempool of Nomos node by the Zone
-
The block producer picks the certificate form the DA specific mempool and writes it into the block
- When writing, the "index" (for the Certificate that AppID owns) is checked with the most recent written
nonce index for the same AppID. It needs to be
- In addition to the certificates, block also has a corresponding range (or sequential nonce) to each certificate, that tells how many rows a related data chunk has
- The block is created with a list of such certificates
- When a DA node receives a new block, it double checks if it has data to be written, related to the certificates that are included in the block.
- DA node tracks the latest state of the blockchain
- If it doesn’t have such a data chunk, it skips it (or marks as absent) and continues to the next certificate in the block.
- If it has such a data chunk, then it persists this data chunk into the node's “database” using the range (sequential nonce) ids attached to the certificate in the block.
- Index+AppId progression in blockchain needs to be sequential, but is not required to be sequential in the DA nodes. Some DA nodes might be missing some chunks from the previous blocks.
-
The data chunks for AppID should be available in DA nodes via the READ API shortly after the block is considered available in the blockchain
-
When a client wants to query a specific range (or sequential nonce) of rows from a node for a specific blob, it has to provide the AppID for witch to retrieve data for and provide the range of "nonces".
- Nomos DA api provides simple read api for Clients/Zones.
- Clients/Zones need to know which ranges to query for specific AppID in order to get meaningful data.
- The ranges should be communicated by the Zones to the interested parities by the channels that are controlled by the Zones.
Verifiable Information Dispersal Certificate (VID Certificate)
The VID Certificate is a crucial part of ensuring data integrity in Nomos DA. It's created as part of chunk dissemination process by Nomos Zone and is used by Block Producer to verify the dissemination:
- Data Blob & Chunk Distribution: Initially, a large piece of data (Data Blob) is split into smaller chunks, following the Nomos DA Protocol. These chunks are then sent out to different DA Nodes.
- Aggregate Commitment (C_agg): Along with each chunk sent to the DA Nodes, there are accompanying commitments: a column commitment specific to the chunk, a list of row commitments for the entire Data Blob, and an aggregate commitment (C_agg). These commitments, including C_agg which is a result of the Nomos DA Protocol encoding, are provided to ensure the integrity and consistency of data across all nodes.
- Verification by DA Nodes: Each DA Node checks the commitment of the column value it receives. Afterwards, it checks each chunk in the column via row commitment.
- Creating the VID Certificate: Once a DA Node verifies its chunk matches the original data, it signs the C_agg and sends back (to NZ) signature as a form of confirmation. The VID Certificate is a list of these signatures from all (or a subset) the DA Nodes that received a chunk.
- Verification by Block Producers: Once the Nomos Zone sends the VID Certificate, which contains C_agg + signatures from DA Nodes and Metadata about the DataBlob (AppID, index) to Block Producer. Block Producers verify each signature against the Aggregate Commitment (C_agg). This step confirms that each data chunk seen by the DA Nodes matches the original data. The Block Producers use cryptographic methods to validate the signatures. Upon successful verification, C_agg is hashed into CertificateID. Only {CertificateID + AppID + index} is stored in the block.
Metadata Required from NZ to Block Producer
When the NZ sends the VID Certificate to the Block Producer, it includes essential metadata about the DataBlob. This metadata consists of: