From 80d6931c2a414a5e806e9c7d77664dcbdd72fc6e Mon Sep 17 00:00:00 2001 From: Cofson Date: Tue, 6 Jan 2026 09:59:00 +0100 Subject: [PATCH] Add Bedrock Service Reward Distribution specification --- .../bedrock-service-reward-distribution.md | 176 ++++++++++++++++++ 1 file changed, 176 insertions(+) create mode 100644 nomos/raw/bedrock-service-reward-distribution.md diff --git a/nomos/raw/bedrock-service-reward-distribution.md b/nomos/raw/bedrock-service-reward-distribution.md new file mode 100644 index 0000000..68abe28 --- /dev/null +++ b/nomos/raw/bedrock-service-reward-distribution.md @@ -0,0 +1,176 @@ +--- +title: BEDROCK-SERVICE-REWARD-DISTRIBUTION +name: Bedrock v1.2 Service Reward Distribution Protocol +status: raw +category: Standards Track +tags: nomos, bedrock, rewards, services, validators +editor: Thomas Lavaur +contributors: +- David Rusu +- Mehmet Gonen +- Marcin Pawlowski +- Filip Dimitrijevic +--- + +## Abstract + +This specification defines the Service Reward Distribution Protocol +for distributing rewards to validators based on their participation +in Nomos services such as Data Availability and Blend Network. +The protocol enables deterministic, efficient, and verifiable reward distribution +to validators based on their activity within each service. + +## Semantics + +The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", +"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" +in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). + +### Definitions + +| Terminology | Description | +| ----------- | ----------- | +| Session | A fixed number of blocks during which the validator set remains unchanged. | +| Service Validator | A node participating in a service (DA or Blend Network). | +| Activity Message | A signed message attesting to a validator's participation. | +| zk_id | The zero-knowledge identity of a validator from SDP declarations. | +| SDP_ACTIVE | A Mantle Operation used to submit activity attestations. | + +## Background + +Nomos relies on multiple services, +including the Data Availability and Blend Network - +each operated by independent validator sets. +For sustainability and fairness, +these services must compensate service validators based on their participation. +Validators first declare their participation through +[Service Declaration Protocol][sdp]. + +Each service defines: + +- The session length, a fixed number of blocks + during which its validator set remains unchanged. +- The validator activity rule that distinguishes + between active and inactive validators. +- The reward formula for distributing the session's rewards + at the end of the session. + +The protocol unfolds over three key phases, aligned with validator sessions: + +1. **Service Activity Tracking** (Session N+1): + Service validators submit signed activity messages + to attest to their participation of session N through a Mantle Transaction, + including an activity message + (see [Mantle Specification - SDP_ACTIVE][mantle-sdp-active]). + +1. **Service Reward Derivation** (End of Session N+1): + Nodes compute each validator's reward based on validated activity messages + and the different service reward policies. + +1. **Service Reward Distribution** (First block of session N+2): + Rewards are distributed to validators marked as active for the service. + This is done by inserting new notes in the ledger + corresponding to the reward amount for each active validator. + +**Core Properties:** + +- Service rewards are distributed to the `zk_id` from validator SDP declarations. +- Minimal Block Overhead: rewards are directly added to the ledger + without involving Mantle Transactions. + +## Protocol + +### Sessions + +Each service defines its own session length (e.g., 10000 blocks), during which: + +- The service validator set remains static. +- Activity criteria and reward policy are fixed. + +### Activity Tracking + +Throughout session N+1, the block proposers integrate Mantle Transactions +containing `SDP_ACTIVE` Operations. +These transactions originate from service validators +and are used to derive their activity +according to the service provided policy. +The protocol does not prescribe a unique activity rule: +each service defines what qualifies as valid participation, +enabling flexibility across different services. + +Service validators are economically incentivized to participate actively +since only active validators will be rewarded. +Moreover, by decoupling activity submission from reward calculation, +the system remains robust to network latency. + +This generalized mechanism accommodates a wide range of services +without requiring specialized infrastructure. +It enables services to evolve their own activity rules independently +while preserving a shared framework for reward distribution. + +### Service Reward Calculation + +At the end of session N+1, +service rewards for the validator `n` for the session N +are computed by the different services +taking as input the rewards of the session: + +```text +Rewards^n := serviceReward(n, Rewards_Session) +``` + +Where `Rewards_Session` are the total rewards of session N. +The `Rewards_Session` is determined by the service, +which calculates how much each service receives +based on fees burnt during session N and the blockchain's state. +`Rewards^n` is stored as an array that maps each validator's `zk_id` +to their allocated reward. + +### Service Reward Distribution + +Starting immediately after session N+1, +service rewards are distributed in the first block of session N+2. +The rewards are inserted directly in the ledger +without triggering any Mantle validation. + +The note ID is computed using the result of +`zkhash(FiniteField(ServiceType, byte_order="little", modulus=p) || session_number)` +as the transaction hash. +The output number corresponds to the position of the `zk_id` +when sorted in ascending order. + +The reward MUST: + +- Transfer the correct reward amount + according to [Service Reward Calculation](#service-reward-calculation). +- Be sent to the public key `zk_id` of the validator + registered during declaration of the service. +- Be distributed into a single note if several rewards share the same `zk_id`. +- Be executed identically by every node processing the first block of session N+2. + This happens by inserting notes in the ledger in ascending order of `zk_id`. + +Nodes indirectly verify the correct inclusion of rewards +because all consensus-validating nodes must maintain the same ledger view +to derive the latest ledger root, +which serves as input for verifying the [Proof of Leadership][pol]. + +## References + +### Normative + +- [Service Declaration Protocol][sdp] - Protocol for declaring service participation +- [Mantle Specification][mantle-sdp-active] - SDP_ACTIVE operation specification +- [Proof of Leadership][pol] - Proof of Leadership specification + +### Informative + +- [v1.2 Service Reward Distribution Protocol][origin-ref] - Original specification document + +[sdp]: https://nomos-tech.notion.site/Service-Declaration-Protocol +[mantle-sdp-active]: https://nomos-tech.notion.site/Mantle-Specification +[pol]: https://nomos-tech.notion.site/Proof-of-Leadership +[origin-ref]: https://nomos-tech.notion.site/v1-2-Service-Reward-Distribution-Protocol-26b261aa09df8032861dddf01182e242 + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).