Owner: @Marcin Pawlowski

Reviewers: 🟢@Alexander Mozeika 🟢@Mehmet 🟢@Daniel Sanchez Quiros 🟢@Álvaro Castro-Castilla

Introduction

The Nomos Data Availability (NomosDA or DA for short) service is a crucial component of the Nomos architecture, responsible for ensuring accessibility and retrievability of the blockchain data. This document outlines the design of an opinion-based rewarding mechanism that incentivises DA nodes to maintain consistent and high-quality service.

Our approach uses peer evaluation through a binary opinion system, where nodes assess the service quality of their counterparts across different subnetworks of DA. This mechanism effectively balances simplicity and effectiveness by integrating with the existing Nomos architecture while promoting decentralised quality control.

While the system has some limitations, including the subjectivity of node opinions and potential for dishonest evaluation, our design prioritises simplicity of practical implementation over other possible, but potentially more complex, validation schemes. The strength of the approach used comes from its economic design, which reduces possibilities for dishonest behaviour and collusion.

The following sections provide detailed explanations of the protocol's operation across multiple sessions, including how activity proofs are constructed and the mathematical framework used for reward distribution.

Terminology

• Block Finality is a period expressed in number of blocks that defines the moment after which a block is considered finalized. In the current version of the protocol, this is $2160$ blocks, as defined by the parameter $k$ in Constants .
• Session is a time during which the same set of nodes executes the protocol. When a session ends, a new one begins, and the set of nodes is refreshed. In this version of the protocol, the session length is set to two block finalization periods, which equals $4320$ blocks. The latter ensures that a node samples (with high probability) all of its peers in the network with the number of nodes less than (or equal) $4000$.

Overview

We define an opinion-based rewarding mechanism for the NomosDA service that incentivizes nodes to maintain high quality service. The mechanism operates across three consecutive sessions:

• During session $s$ (where $s$ represents the current session), NomosDA nodes perform their primary function of sampling data blobs referenced in blocks. While sampling, nodes interact with and evaluate the service quality of other randomly selected nodes from different subnetworks. Nodes sample both new blocks and old blocks as part of this process.
• In session $s+1$, nodes formalise their evaluations by submitting Activity Proofs — binary vectors where each bit represents their opinion (positive or negative) about other nodes' service quality. These opinions are tracked separately for new and old blocks. The proofs are recorded on the ledger through Active Messages — part of the Service Declaration Protocol that confirms a node's activity.
• Finally, in session $s+2$, rewards are distributed. Nodes that accumulate positive opinions above a defined threshold receive a fixed reward, calculated as a portion of the session's DA service income. Each node receives a reward based on the network's opinion of its performance in handling both new and old blocks.

The mechanism intentionally uses subjective node opinions rather than strict performance metrics. While this introduces some arbitrariness, it provides a simple and flexible approach that aligns with Nomos' architectural goals. The reward calculation method, which divides rewards based on the total number of nodes rather than just active ones, further discourages manipulation of the opinion system.

Protocol

1. During the session $s$:
   1. If the number of DA nodes (unique ProviderIds from declarations) retrieved from the SDP (Service Declaration Protocol) is below the minimum (Minimum Network Size), then do not perform sampling for new blocks.
   2. If the number of DA nodes retrieved from the SDP for the session $s-1$ was below the minimum, then do not perform sampling for old blocks.
   3. If the number of DA nodes retrieved from the SDP is below the minimum for both session $s$ and $s-1$, then stop and do not execute this protocol.
   4. The DA node performs sampling for every new block $b$ it receives (where $b$ is the block number), and for an old block $b-S$ for every new block received (where $b-S$ is the old block number). Here $S=4320$ is the length of the session.
      1. The node selects at random (without replacement) 20 out of 2048 subnetworks (the motivation for selecting 20 can be found here: Analysis of Sampling Strategy). We note that the set of nodes selected does not have to be the same for old and new blocks.
      2. The node connects to a random node in each of the selected subnetworks. If a node does not respond to a sampling request, then another node is selected from the same subnetwork and the sampling request is repeated until success is achieved or a specified limit is reached.
   5. During the sampling, the node measures the quality of the service provided by the selected nodes as defined below in Data Availability Sampling Quality of Service Measurement.
2. During the session $s+1$:
   1. The DA node generates an Activity Proof that contains opinion vectors, where all of the DA nodes are rated by the node for a positive or negative quality of service for new and old blocks.
   2. The DA node sends an Active Message that is registered on the ledger and contains the node Activity Proof.
3. During the session $s+2$ and after finalization of the session $s+1$:
   1. Every node that collected above Activity Threshold of positive opinions receives a fixed reward as defined in the Reward Calculation.
   2. The rewards are distributed by the Service Reward Distribution Protocol.