Skip to content

Latest commit

 

History

History
59 lines (42 loc) · 6.68 KB

dip-0002.md

File metadata and controls

59 lines (42 loc) · 6.68 KB

DIG Reward Distributor

Authors: yakuhito, Michael Taylor

Abstract

This proposal outlines a design for an on-chain reward distributor. It covers the requirements of such a system, then presents technical implementation details.

Introduction

In a recent community space, Michael outlined a call to action for the DIG network highlighing two main problems that need to be solved. One of them is a need for a reliable, trustless payment mechanism:

Currently, our payment model relies on trust - a “Trust Me Bro” approach - which is neither sustainable nor secure. Store sponsors can announce on-chain or elsewhere that they will pay for propagation, but there’s nothing forcing them to follow through. This opens the door to abuse and inconsistencies, especially if store sponsors struggle to maintain their incentive servers. We need a robust, on-chain mechanism that ensures guaranteed and provably fair payments to peers. This involves:

  • Escrow System: Store sponsors must lock funds in an escrow as proof of guaranteed payment to peer mirrors.
  • Proof of Service: Developing mechanisms to prove that peers have fulfilled their responsibilities throughout the epoch.
  • Payment Unlocking: Establishing a way to unlock payments based on these proofs.

To solve this problem, we propose a liquidity farm-like mechanism. A validator is an entity that identifies online mirrors and submits on-chain changes when a mirror's state is changed (i.e., a transaction is made when a previously online mirror becomes offline or when a new mirror goes online). The mechanism rewards mirrors per second of uptime, with an off-chain reputation system being used to monitor validator behavior.

This document is an early draft intended to invite community feedback and foster discussions to refine the design of the reward distributor.

Requirements

Through public and private discussions, we identified the following requirements:

  • XCH and CAT payouts: Reward distributors should be able to pay incentives in either XCH, the native currency of the Chia blockchain or in a specific CATs.
  • Continuous uptime rewards: A mirror’s reward should accurately reflect its uptime in a given epoch. While a transaction is not made every second, mirror owners should have confidence that a deterministic amount of XCH or CATs is set aside for them every second. This amount can only be paid out to them, even if the validator starts misbehaving in the future.
  • Anyone can commit incentives for future epochs: Anyone should be able to commit funds to sponsoring future epochs. To account for the possibility that a validator might go rogue or offline, commitments can be clawed back. This clawback incurs a penalty, making validator misconduct costly to all parties: the validator loses reputation and future rewards, while the sponsor loses a part of their commitment.
  • Validator controls list of active mirrors: The validator is the only entity that can add or remove entries from the active mirror list. Active mirrors continuously earn a part of the epoch's total payout (share also depends on the total number of active mirrors).
  • Validator fee proportional on total payout amount: The validator provides an essential service and has to cover network fees for transactions marking mirrors as online/offline. As such, it makes sense to incentivize the validator by reserving a fixed percentage of each epoch’s total rewards.
  • Mirror payouts can be manually triggered: Mirrors are automatically paid out when they go offline. Payouts can also be triggered 'manually' after the accrued rewards exceed a threshold.

Design Details

The proposed design leverages two new primitives introduced in slot-machine: the action layer and slots.

The action layer allows the singleton to support multiple spend paths, akin to Solidity functions. The following methods are proposed:

  • sync: Distributes rewards for the elapsed time since the last sync in the same epoch.
  • new_epoch: Transitions to a new epoch at the end of the current one, also transferring the validator’s fee.
  • commit_incentives & withdraw_incentives : Used to commit incentives for a future round (i.e., sponsor it) and to withdraw a previous commitment. As mentioned previously, the latter operation carries an associated penalty.
  • add_current_epoch_incentives: Adds incentives to the current epoch. The amount cannot be clawed back.
  • add_mirror & remove_mirror: Called by the validator to update the active mirror list.
  • inititate_payout: Initiates a payout of accrued rewards for a mirror.

The action layer also holds a 'state', a set of variables that are frequently used. We predict the following variables will be needed for the reward distributor to work:

  • epoch_start: Start time (timestamp) of the current epoch.
  • cumulative_payout: Tracks total payout for a theoretical mirror active since the distributor launch, allowing calculation of each mirror’s payout by comparing cumulative payout values at entry and at payout. For example, if 10 XCH needed to be paid when mirror A was added and the current value is 15 XCH, the mirror would be paid 5 XCH since all active mirrors earn the same amount of XCH over the same period of time.
  • last_update: Last timestamp used to compute cumulative payout.
  • remainign_rewards: Rewards left to be distributed in the current epoch.
  • active_mirrors: Count of currently active mirrors.

Slots offer a higher-cost storage ideal for data retrieved infrequently, such as:

  • total rewards of a future epoch: Slots that store (epoch_number next_epoch . total_rewards). next_epoch ensures that no two slots describe the same future epoch - a value of 0 indicates that the slot for the next epoch needs to be created.
  • precommitments: Slots that store (epoch_number clawback_ph . committed_value), which will be used when a sponsor wishes to claw back their commitment.
  • active stores: Slots storing (payout_puzzle_hash . initial_cumulative_payout) that will be used to calculate store payout amounts.

Future Directions

We're extremely excited about the possibilities DIG reward distributors open up. This technology ensures secure, predictable rewards with minimal on-chain transactions. Moreover, it allows multiple entities to incentivize the same mirrors. For example, mirrors supporting the BananaTalk website could receive rewards from both DIG and a separate distributor run by Banana Gang, creating a multi-layered incentive structure.