Nomos is designed as a blockchain infrastructure that prioritises privacy, neutrality, and resilience. While its Bedrock layer provides foundational consensus and execution functionality, it is strengthened and enhanced by specialised Bedrock Services that validators can opt into. Participation in a Bedrock Service requires more resources than just acting as a Nomos node, and is therefore incentivised via a rewards system.

This article explores why and how Nomos nodes can participate in these services and the mechanisms that govern reward distribution for their efforts.

Background on Nomos Bedrock Services

Nomos Bedrock Services are specialized protocols run by dedicated subsets of Nomos nodes. These services extend Nomos' core functionality, providing important features like data availability and private block proposals. Unlike basic Bedrock validation, these Services require more resources and are therefore optional for nodes to participate in. While these services demand different forms of participation with different connectivity and processing requirements, they both essentially have a protocol used among their own participating nodes that interact with other types of actors.

Currently, Nomos supports two key Bedrock Services:

NomosDA

NomosDA is Nomos's data availability service, designed to ensure the integrity of data posted to it from architectures (such as Sovereign Rollups) built on top of Nomos. It works by encoding these data (known as blobs) with error-correcting codes and distributing shares of blob data to DA nodes. This approach allows for quick and accessible verification of data availability through sampling techniques while minimising bandwidth requirements for individual DA nodes.

By providing this service, NomosDA allows Nomos network to scale while ensuring that all blob data remains available. NomosDA achieves scalability by minimising the amount of data sent to each node and the bandwidth that the node must support, while maximising the data throughput supported by the network at large.

Blend Network

The Blend Network is a peer-to-peer anonymous broadcasting protocol that enhances Nomos' privacy guarantees. Its primary objective is to make it extremely difficult to link a block proposal with its proposer, which in turn prevents observers from determining a node's relative stake based on proposal frequency. This provides neutrality for proposers who would otherwise find it prudent to engage in self-censorship when building a block.

The Blend Protocol achieves this by routing encrypted proposal messages through multiple Blend nodes before revelation, with timing delays and artificial traffic added to obscure the connection between input and output messages. Blend nodes must maintain connections with other Blend nodes and comply with protocol requirements.

By providing this service, Blend Network validators strengthen the privacy properties of Cryptarchia, Nomos's consensus protocol, making the entire network more resilient against deanonymisation attacks.

Why Service Participation Requires Declaration

Participating as a Nomos validator is simple by design, with a permissionless consensus protocol facilitating dynamic participation by node operators. To ensure that being a Nomos node operator has a low barrier to entry, the basic Nomos node application can be run on an average laptop with a reliable internet connection.

Participation in Bedrock Services, on the other hand, is more complex. These protocols require agreed-upon sets of active participants to ensure their correct operation. For example, NomosDA divides DA nodes into subnetworks that store one share of every blob - a process that depends on knowing which nodes are DA nodes. Similarly, Blend nodes must keep track of connections to other Blend nodes for message relaying. As a result, it is not possible to allow dynamic participation in Bedrock Services as it exists for Bedrock.

Node registration also ensures honest behaviour by requiring each participating node to lock some minimum stake. This stake requirement makes service declarations sufficiently expensive to avoid spamming or Sybil attacks, in which one party runs multiple nodes to attempt to gain more influence. In the current version of Nomos, this stake requirement remains stable over time.

Service Declaration Protocol

The Service Declaration Protocol, or SDP, provides a standardised mechanism for Nomos validators to declare their participation in specific services, demonstrate activity, and withdraw when desired. It operates around a schedule measured by service-specific timeframes known as sessions. This protocol creates a single repository of identifiers used to establish secure communication between validators and manage service participation.

The SDP consists of three basic steps, each of which represents a type of message sent by a participating node:

• Declare: A node elects to participate in a given service.
• Active: To continue participating, the node must send an “active” message after a certain time period.
• Withdraw: A node withdraws its declaration and stops providing a service.

Declare

The registration process begins when a validator sends a valid declaration message to Bedrock’s Mantle indicating their willingness to provide a specific service. This message must include:

• Service type: Either DA for NomosDA or BN for Blend Network.
• Locators: A list of no more than 8 locators (see below) used to identify a node.
• Provider ID: An Ed25519 public key used to sign SDP messages and to establish secure links between nodes.
• ZK ID: A public key used for zero knowledge (ZK) operations, and as the recipient address for reward distribution.

Nodes participating in Services are assigned addresses (known as locators) based on the multiaddr scheme, except that the peer ID at the end of a typical multiaddress is replaced by the provider ID mentioned above. Locators allow nodes to communicate securely while engaging in a Service. For a declaration to be valid, the message must be signed by both the provider ID and the ZK ID.

In addition, the sender must provide the ID of the Mantle note that they intend to lock as their participation stake. This note’s value must meet or exceed the minimum stake threshold to ensure honest participation. The declaration is also assigned a unique declaration ID, calculated by taking the hash of the concatenation of the message data mentioned above.

Once validated, the declaration is stored on the Mantle ledger, together with its ID and a nonce that is initially set to 0. By doing this, the node becomes eligible to participate in the service. The note provided is locked and cannot be transferred until the node withdraws from the service, but remains eligible for consensus leadership.

Active

After declaring participation, validators must regularly confirm their active status by submitting signed activity messages. These messages update the active timestamp in the declaration record and are used to track participation, enhancing the stability of Bedrock Services by pruning inactive nodes. Activity messages are also important for reward distribution, as will be discussed in the following section.

Each service defines its own inactivity period in terms of a number of sessions. If a validator fails to send an activity message within this period, their declaration is considered inactive. After an additional retention period also defined in terms of sessions, the declaration is completely deleted.

The activity message must include:

• Declaration ID: Assigned to a declaration when it is created (see above).
• Nonce: A new nonce value for the declaration. It must increase monotonically with each message sent for that declaration.
• Metadata: A service-specific field with additional activity details. For NomosDA and the Blend Network, this is used to broadcast an activity proof consisting of each node rating the quality of its peers.

This message must also be signed by the ZK ID associated with the declaration. A successful activity message will set the most recent activity of this declaration to the current block.

Withdraw

Validators can exit a service by submitting a withdraw message. This message must be signed by the ZK ID associated with the declaration, and includes:

• Declaration ID: Assigned to a declaration when it is created (see above).
• Nonce: A final nonce value for the declaration.

Withdrawal cannot occur before the end of the lock period, ensuring that nodes remain committed for a minimum duration. Once withdrawal is processed, the node's stake is unlocked and they no longer participate in or receive rewards for the service.

Service Reward Distribution Protocol

The Service Reward Distribution Protocol, or SRDP, enables deterministic, efficient, and verifiable reward distribution to nodes based on their participation in Bedrock Services. Like the SDP, it also operates around sessions. The SRDP process unfolds over three key phases, distributing rewards based on node activity from previous sessions.

Activity Tracking

During a given session, service validators submit signed activity messages (see above) to attest to their participation in the previous session. These messages are submitted as Mantle Transactions and include activity metadata specific to each service. The protocol does not prescribe a unique activity rule: each service independently defines what qualifies as valid participation, enabling flexibility across different services.

Each Nomos node maintains activity records for participating nodes, which are used to determine reward eligibility. These are discarded after the rewards for that session have been distributed. Activity records contain the following information:

• Service type: Either DA for NomosDA or BN for Blend Network.
• Session: The session number of the activity (not the activity messages).
• Activities: Declaration IDs and their associated activity metadata.
• Funds: Rewards to be distributed this session.

Reward Calculation

At the end of the session, the system calculates rewards for validators who participated in the previous session. The calculation takes into account the total rewards allocated to the session and applies service-specific formulas to determine each validator's share.

The reward formula varies by service but generally considers factors such as fees burnt during the session, as well as the blockchain's state. The calculated rewards are stored in an array mapping each validator's ZK ID to their allocated reward amount. This approach ensures that reward distribution is transparent, deterministic, and fair, with validators receiving compensation proportional to their contribution.

Reward Distribution

Starting immediately after the session when activity messages are submitted, rewards are gradually distributed to active service nodes. Each block includes one Mantle Transaction that can distribute rewards to up to four validators per service. The selection of nodes receiving rewards in each block follows a deterministic, pseudo-random process based on the Cryptarchia epoch randomness from the start of the session. This approach ensures fairness and prevents manipulation of the distribution order.

Rewards are sent directly to the validator's ZK ID registered during service declaration, with the transaction containing the correct reward amount as calculated in the previous phase. To ensure all validators can be rewarded within a single session, the protocol imposes limits on the number of validators per service based on session length.

Conclusion

Participating in Nomos Bedrock Services offers node operators an opportunity to contribute to the network's functionality while earning rewards for their efforts. Through the Service Declaration Protocol, validators can seamlessly join services, maintain their active status, and withdraw when needed. Meanwhile, the Service Reward Distribution Protocol ensures they receive fair compensation for their participation.

As Nomos continues to develop, these services will play an increasingly important role in ensuring the network's privacy, neutrality, and resilience. By understanding and participating in these services, node operators can position themselves as key contributors to the Nomos ecosystem while diversifying their revenue streams.

Sources and Further Reading

• Service Declaration Protocol
• Service Reward Distribution Protocol