LogoLogo
PAO DocsCommunity DocsInfrastructure DocsPeerplays.com
  • Developer Documentation
  • API Reference
    • Peerplays Core API
      • Popular API Calls
      • Account History
      • Asset API
      • Block API
      • Crypto API
      • Database API
      • Network Broadcast API
      • Network Nodes API
      • Orders API
    • Wallet API
      • Account Calls
      • Asset Calls
      • Blockchain Inspection
      • General Calls
      • Governance
      • Privacy Mode
      • Trading Calls
      • Transaction Builder
      • Wallet Calls
    • Bookie API
      • General Calls
      • Listeners
      • Tournaments
  • Peerplays API Libraries
    • Python Peerplays
      • Installation
      • Creating an Account
      • Creating a Peerplays Wallet
      • NFT API
      • Marketplace API
      • Role Based Permissions API
  • Development Guides
    • Creating User Issued Assets
    • Introduction to Permissions
    • NFT Minting
    • Calculating Costs
  • The Cookbook
    • NFTs for Staking Creator Tokens
  • Tools and Integrations
    • PeerID
      • 1.0.0
        • Infrastructure
          • Deployment on a Linux Serve
          • Deployment to AWS ECS
            • Building the Docker Images
            • Storing Secrets in Amazon Parameter Store to use in ECS
            • Creating the Task Definition
            • Creating the Cluster
            • Creating the Service
        • Development
          • How does PeerID work without storing the keys ?
          • Authentication with PeerID
          • Brain Storming
          • Software Requirements
      • Authentication with PeerID
      • Requirements Specification
    • Random Number Generator
      • RNG Technical Summary
      • RNG API
  • Supporting & Reference Docs
    • Peerplays Development FAQs
    • Sidechain Operator Node (SON) Development
      • Generic Sidechain Docs
        • Quick joining GLADIATOR
        • Changes to Peerplaysjs-lib
        • Requirements Specification
        • Low Level Designs
          • bitcoin-deposit-handling-lld
          • bitcoin-operations-draft
          • bitcoin-sidechain-handler-lld
          • bitcoin-sidechain-multisig-bitcoin-wallet-and-bitcoin-addresses-pw
          • bitcoin-withdrawal-handling-lld
          • btc-address-scripting-mechanism
          • comparison-between-scenarios-for-handling-deposits-and-withdrawals
          • exchange-rate-list
          • generic-sidechain-deposit-hld
          • generic-sidechain-high-level-design
          • generic-sidechain-listener-hld
          • generic-sidechain-withdrawal-hld
          • refund-btc-mechanism
          • son-configuration
          • son-consensus-communication-and-transaction-signing-on-chain-lld
          • son-de-register-proposals-lld
          • son-objects-and-operators
          • son-rewards-lld
          • son-voting-lld
          • son-wallet-list_sons-lld
          • creation of a multi-sig bitcoin address lld
          • claiming initial son vesting lld
          • changeover and SON maintenance scenarios lld
          • user-sidechain-addresses-mapping
          • wallet-commands-for-son
        • Functional Specs
          • SON Configuration
          • SON rewards
          • SON Voting and Consensus
          • SONs switchover scenarios
          • SON Status Operations & Monitoring
          • Proposals
          • SON Smart Contracts
      • Bitcoin Sidechain Docs
        • Functional Specs
          • btc-refunds
          • voting-and-consensus
          • son-switchover
          • son-rewards
          • son-proposals
          • son-configuration
          • heartbeat-monitoring
          • BTC Transaction Processing & Signing
          • Bitcoin Withdrawal Handling
          • Bitcoin Deposit Handling
          • SON Multisig Bitcoin Wallet
      • Hive Sidechain Docs
        • Functional Specs
          • HIVE Deposit Handling
          • HIVE Withdrawal Handling
    • Peerplays DEX Development
      • Peerplays NEX
        • Functional Specifications
          • NEX-FS01 Dashboard Page
            • NEX-FS12 ETH-SONs Deposit/Withdraw Functionality
          • NEX-FS02 Login and Account Creation
          • NEX-FS03 Menus and Nav
          • NEX-FS04 Notifications
          • NEX-FS05a Market Page (alpha)
          • NEX-FS05 Market Page
          • NEX-FS06 Profile Page
          • NEX-FS07 Wallet Functions
          • NEX-FS08 App Settings
          • NEX-FS09 Blockchain Page
          • NEX-FS10 GPOS Page
          • NEX-FS11 WhaleVault Integration
      • Requirements Specification
      • Functional Specs
        • Asset Info Page and Asset Lists
        • Dashboard
        • Exchange Page
        • Login and Account Creation
        • User Account Page
        • Voting Page
    • SPK Network
      • Functional Specs
        • Claimdrop Snapshot Functional Specification
        • Initial Claimdrop Functional Specification
    • NFT Development
      • NFT Store
        • NFT Store User Stories
        • NFT Store UI HLD
        • NFT Store Requirements Specification
        • Functional Specifications
          • APP-FS01 App Header
          • APP-FS02 App Body
          • APP-FS03 App Footer
          • APP-FS04 App Navigation
          • APP-FS05 Wallet Functions
          • APP-FS06 App Home Page
          • APP-FS07 Account Page
          • APP-FS08 Browse View
        • App Page List
        • Requirement Traceability Matrix
    • Operation IDs List
    • Sidechain Flow Diagram (HIVE coin)
    • Sidechain Flow Diagram (Bitcoin)
    • Sidechain Flow Diagram (Ethereum coin)
    • TradeHands Explorer
      • User Personas
      • User stories
      • APP-FS01 Detailed View
      • Draft: APP-FS02 Front Page
      • APP-FS03 Collection Details Page
    • Grafana
      • Grafana Installation
      • Install Grafana Behind reverse proxy
      • Loki Installation
      • Promtail agent Installation
      • Grafana Explorer
    • NEX Deployment & Configuration
      • NEX Deployment
      • NEX - Blockchain API configuration
      • Deploying NEX in a HA scenario
    • API Node
      • MarketCap API
    • TOTO Application
      • FS-Subscription Plan
      • FS-Achievements
  • Development Workflow Docs
    • Development Workflow
  • Other Documentation
    • Peerplays Home
    • Community Docs
    • Infrastructure Docs
    • Site Reliability Engineering
Powered by GitBook
On this page
  • 1. Purpose
  • 2. Scope
  • 3. Background
  • 4. Process Overview
  • 5. Flow Diagram
  • 6. Context
  • 7. Requirements
  • 8 Risks
  • Sample test:

Was this helpful?

Export as PDF
  1. Supporting & Reference Docs
  2. Sidechain Operator Node (SON) Development
  3. Generic Sidechain Docs
  4. Functional Specs

SON rewards

1. Purpose

The purpose of this document is to outline the steps required to pay the SONs for their contribution to the Peerplays network.

2. Scope

The functional requirement listed in this document will be limited to the payment portion of the SON. This will outline the required steps to pay the SONs for the functions performed by them on the Peerplays blockchain. Also outlined here will be the sequence in which the required steps will be performed including:

  • any interactions with the user.

  • validations to ensure complete and accurate information gathering.

3. Background

The Bitcoin Sidechain functionality has been implemented in the Peerplays blockchain but it doesn't take into account, the change of SONs. As per the current implementation of Sidechain, a multisig bitcoin wallet will be created on the bitcoin blockchain to hold the bitcoins that have been deposited into the pBTC accounts of the Peerplays users. Every Peerplays witnesses will have a bitcoin transaction signing key for this multisig bitcoin wallet and will be required to sign any withdrawal transaction. When a SONs changes, the transaction signing key of the outgoing witness needs to be removed from the multisig bitcoin wallet and the key of the incoming witness needs to be added. The suggested proposal is to make the Sidechain code available as a plugin and assign the responsibility for running the sidechain code to separate nodes called the Sidechain Operating Nodes (SONs). The SONs will be independent of the witnesses and don't need to be changed much often.

4. Process Overview

Described here is the process to pay the SONs on the Peerplays Blockchain.

5. Flow Diagram

N/A

6. Context

The SON operators will be paid in PPY from the payment pool set up specifically for payments to SONs. This pool will be replenished by depositing a percentage of all the transaction on the Peerplays network. This percentage should be a chain parameter so that it can be changed. The fee will be distributed at the Maintenance intervals based on transactions signed and weight of voting (therefore voting power affects payout) for each SON. Currently set maximum SON payment is 200 PPY daily and is specified in `SONS_DAILY_MAX_REWARD`.

7. Requirements

7.1 Supported Operation Types

All operations performed by SONs must be tallied and paid according to budget and defined payout procedure (as described in sections below).

System must include a library (global parameters) of configurable fee amounts fee amounts associated with each operation. Library must track each operation, its type, fee amount and currency in which fee is charged (PPY by default). Fees are set and amendable by committee members in accordance with committee member procedures to update global parameters.

Operations commonly performed by SONs are as follows:

  • asset_issue_operation

  • asset_reserve_operation

  • proposal_create_operation

  • proposal_update_operation

  • proposal_delete_operation

  • son_create_operation

  • son_update_operation

  • son_delete_operation

  • son_heartbeat_operation

  • son_report_down_operation

  • son_maintenance_operation

  • son_wallet_recreate_operation

  • son_wallet_update_operation

  • son_wallet_deposit_create_operation

  • son_wallet_deposit_process_operation

  • son_wallet_withdraw_create_operation

  • son_wallet_withdraw_process_operation

See Risks section for considerations regarding fee amounts and their implications on financial viability of SON.

7.2 Paying Witnesses

Whenever a witness generates a new block, reward amount must be immediately deposited into witness account's vesting balance.

The amount must be withdrawn from witness_budget

7.3 Collecting Fees

All operations require a fee to be collected and paid to the network.

Fee collection is determined by operation type (as described in section Supported Operation Types):

  1. Core asset transaction fees are deducted from payer's account

  2. UIA (pBTC) transaction fees are converted to core asset using base exchange rate (note: bBTC to BTC is 1:1)fee mus

In a scenario where user has 0 PPY, fee must be collected from fee_pool.

7.4 Calculating budget

The equation for calculating SON budget is as follows:

current_supply = current_supply + (required_witness_budget + required_worker_budget + required_son_budget - leftover_worker_funds - core_accumulated_fee - leftover_witness_budget - leftover_son_budget)

reserve_supply = max_supply - current_supply

  • required_witness_budget - required witness budget till next maintenance interval

  • required_worker_budget - required worker budget till next maintenance interval

  • required_son_budget - reserved SON budget to be paid out in the next maintenance interval = (chain_parameters.son_pay_max)

  • leftover_worker_funds - Remaining funds from previous worker payout

  • core_accumulated_fee - Accumulated fee (after all the cuts removed from it), since the last maintenance interval.

  • leftover_witness_budget - Leftover funds from previous witness budget ( happens if any block is missed in between )

  • leftover_son_budget - Leftover funds from previous son budget ( happens if there are no SON transactions on the network )

other required variables:

  • total_transactions_per_day - tracks number of transactions SON participated in

  • SONs_REWARD_POOL - stores SON reward amounts

  • SONS_DAILY_MAX_REWARD - configurable variable which sets maximum size of reward

  • son_pay_max - dictates how much SONs are to be paid out it next payment interval

7.5 Determining payout

Payout must be determined by the number of transactions verified by a node. Higher availability nodes participate in more transactions and therefore receive higher payout.

SONs are paid based on % ratio between total_transactions_per_day and SONS_DAILY_MAX_REWARD, where SON's % share of daily transactions determines what % of SONS_DAILY_MAX_REWARD is paid. Payout happens only during SON maintenance interval, therefore payout is configurable based on the payment interval and can be configured to happen once every x maintenance intervals.

7.6 Payment Pool

Payments to SONs are stored inside son_budget which functions similarly to witness_budget. Specifically, son_budget accumulates transaction fees collected by peerplays network. As described above, payout happens during the maintenance interval .

SONS_DAILY_MAX_REWARD must initially be set to 200 PPY. We may to have to change this as per market realities etc. Currently BTC is the only supported cryptocurrency.

Note: SONS_DAILY_MAX_REWARD must be reviewed in production to determine whether this limit is too low or restrictive. Depending on the fees associated with each transaction (as described in Transaction Type section above), highly active SONs may perform a number of operations and reach daily max limit quickly thus creation a disproportion between operations performed vs max daily reward.

8 Risks

SON concept has proven to be technically feasible, however, there are financial viability implications that must be taken into account.

SON operations must be priced in ways that offset electricity cost of node operators by a margin that makes it worthwhile to operate a node, however also low enough to make the blockchain cost effective to its users.

Inability to find a fee model attractive to node operators will impede availability of SONs (for which there is a minimum threshold), while high fees are likely to impede user interest due to high cost.

Note that because fees may be amended by committee members, fees they set may create risks mentioned above. It is recommended that committee member operations in relation to fees are closely monitored.

Sample test:

  1. configure witness_pay_per_block chain parameter = 1

  2. configure son_pay_daily_max chain extension parameter = 10000 ( As we don’t have enough fee collected on our chain, keeping it low is essential to test properly)

  3. configure son_pay_time chain extension parameter = maintenance_interval or multiples of maintenance_interval. (Eg. x, 2x, 3x, 4x etc x = maintenance_interval). As budget is calculated during maintenance period son_pay_time should be multiples of maintenance_interval.

  4. Temporarily, txs_signed of son_statistics_object is incremented through son heartbeats to enable testing of SON Rewards. ( txs_signed can be obtained by get_object 2.24.0 command). txs_signed are reset and added to total_txs_signed if SONs are paid out successfully.

  5. Check that the get_dynamic_global_properties has son_budget and last_son_payout_time updated correctly like below,

    get_dynamic_global_properties { "id": "2.1.0", "random": "0f0b35fba1f53d22384e642356c25510e63f18b7", "head_block_number": 4708, "head_block_id": "00001264be90f462d553e2edee2e7fee698215c1", "time": "2020-03-19T10:25:42", "current_witness": "1.6.2", "next_maintenance_time": "2020-03-19T10:30:00", "last_budget_time": "2020-03-19T10:24:00", "witness_budget": 93, "last_son_payout_time": "2020-03-19T10:24:00", "son_budget": 10000, "accounts_registered_this_interval": 0, "recently_missed_count": 7, "current_aslot": 8917831, "recent_slots_filled": "1298074214633706907132624082304903", "dynamic_flags": 0, "last_irreversible_block_num": 4700 }

  6. list_account_balances <sonaccount01> to check that the pay is added to the SON account’s balance.

  7. If there are 13 active SONs, and each SON sent 3 heartbeats before next payout time, You can find below snippet in the log during the chain maintenance, pay 769 to 2.24.0 for 3 transactions signed total txs = 13 x 3 = 39. so pay for each SON -> (3/39)x10000 = 769

PreviousSON ConfigurationNextSON Voting and Consensus

Last updated 3 years ago

Was this helpful?