Skip to content

Latest commit

 

History

History
332 lines (223 loc) · 19.4 KB

lip-0071.md

File metadata and controls

332 lines (223 loc) · 19.4 KB
Raw
LIP: 0071
Title: Introduce dynamic block rewards module
Author: Vikas Jaiman <[email protected]>
Discussions-To: https://research.lisk.com/t/introduce-dynamic-block-rewards-module/387
Status: Draft
Type: Standards Track
Created: 2022-10-28
Updated: 2023-02-16
Required: LIP 0044, LIP 0051, LIP 0057, LIP 0058

Abstract

This LIP introduces the Dynamic Block Rewards module that is responsible for providing the base reward system for the Lisk blockchain according to the validator weight. In this LIP, we specify the properties of the Dynamic Block Rewards module, along with their default values. Furthermore, we specify the protocol logic injected during the block lifecycle, and the functions that can be called from other modules or off-chain services. This module is mainly used for Proof-of-Stake (PoS) in the Lisk ecosystem.

Copyright

This LIP is licensed under the Creative Commons Zero 1.0 Universal.

Motivation

In the current Lisk protocol, the rewards are the same for all active and standby validators (selected according to the selection mechanism described in LIP 0022 and LIP 0023) who forge a block in a round, irrespective of their validator weight. In the current scenario, the rewards for generating a block are fixed and therefore a validator with a large validator weight does not have incentives to lock further tokens via self-stakes unless they run multiple validators, which is not desirable for them due to operational costs and maintenance efforts. Thus, the LIP aims to simplify PoS participation for validators to lock the large number of tokens. By more participation, we expect to increase the Total Value Locked (TVL) and therefore, the security of the Lisk Mainchain. To achieve this, we assign block rewards to also depend on the weight of the validator generating the block.

Rationale

​​The main purpose of Dynamic Block Rewards module is to compute the block rewards according to the validator weight for active validators and induces specific logic after the application of a block:

Minimum Reward for Active Validators

This module assigns a minimum reward i.e. minimumRewardActiveValidators per round to all active validators to cover the minimal operational cost to run a validator. For the Lisk mainchain, the minimum reward is 107 beddows or 0.1 LSK.

Rewards Proportional to the Validators Weight

  • This module distributes the remaining stake rewards i.e. stakeRewardActiveValidators proportional to the validators weight. It is given to the active validators (per round) after giving the minimum reward. For the Lisk mainchain, as calculated in the table, the rewards are 90.9*10^8 beddows or 90.9 LSK. This way, the module achieves fairness (higher weight implies higher rewards) while ensuring that rewards of low-weight validators do not go below the threshold of profitability.
  • In principle, if percentage of rewards shared equally among active validators is set to 0% i.e.FACTOR_MINIMUM_REWARD_ACTIVE_VALIDATORS == 0 (as described in table), then it will be a proof-of-stake system where rewards are proportional to the validator weight. On the other hand, if the percentage of rewards shared equally among active validators is set to 100% i.e. FACTOR_MINIMUM_REWARD_ACTIVE_VALIDATORS == 10000, it will be the previous proof-of-stake (PoS) system where each validator received the same reward for forging a block irrespective of their weights. Therefore, this reward system can be seen as a generalization of the previous one and allows flexibility to developers to use the variant of Proof-of-Stake they find more appropriate for their use case.

Default Reward for StandBy Validators

This module assigns the default reward defaultRewardStandByValidators to all stand-by validators i.e. there is a fixed reward irrespective of the validator weight. For the Lisk mainchain, the default reward for standby validator is 108 beddows or 1 LSK at current block height. This will help stand-by validators to cover the costs of running a node even though the probability of the selection is low in a round.

Reward for Missed blocks

Currently, in the Lisk protocol if a validator misses a block, some other validators forge the block and the validator gets a default reward at current block height (1 LSK for mainchain). The reason is, the total rewards shouldn't exceed in a round it if a validator misses a block. Now, in the dynamic block rewards, validators get rewards proportional to the validator weight. If a validator misses a block then a validator forging the block second time will get the reward proportional to their weight. This results in imbalancing the total reward in a round. In terms of inflation, currently in the Lisk mainchain, there is a maximum minting of 6*60*24*365 = 3153600 LSK per year. Every time a validator misses their block, 1 LSK less is minted per year. So the important aspect that we want to guarantee here is that in the dynamic block rewards also never more than 3153600 LSK are minted per year so that there is a reliable upper bound on the inflation. In terms of incentives, it is also important that it should never be profitable for a validator if someone misses a block. Therefore, for missed blocks, validators forging blocks for the second time in the round, gets minimumRewardActiveValidators. For the Lisk mainchain, the reward for missed blocks is 107 beddows or 0.1 LSK at current block height. Since validators are already running full nodes and there is no additional effort for them to forge a missed block. There is a possibility that the minting of the tokens will be less if there are missed blocks.

Minting of the Rewards

After applying the block, a certain quantity of the native token of the blockchain is minted. The exact amount assigned to the block generator, i.e. the reward is calculated depending on the rules of the Random module and the Lisk-BFT protocol. Specifically, the reward is reduced for not participating in BFT block finalization or failure to properly reveal the random seed. This reduction happens exactly as before mentioned in the previous Reward module. After minting the block rewards, updateSharedRewards function is called from the reward sharing mechanism of the Proof-of-Stake (PoS) module which locks the amount of the rewards which will be shared with the stakers.

Specification

In this section, we specify the protocol logic in the lifecycle of a block injected by the Dynamic Block Rewards module as well as the functions that can be called from off-chain services. It depends on the Token, Random module, and Lisk-BFT protocol. (see the table below).

Notation and Constants

We define the following constants:

Name Type Value Description
MODULE_NAME_DYNAMIC_BLOCK_REWARDS string "dynamicBlockRewards" The module name of the Dynamic Block Rewards module.
EVENT_NAME_REWARD_MINTED string "rewardMinted" Name of the event during minting of the rewards.
REWARD_NO_REDUCTION uint32 0 Return code for no block reward reduction.
REWARD_REDUCTION_SEED_REVEAL uint32 1 Return code for block reward reduction because of the failed seed reveal.
REWARD_REDUCTION_MAX_PREVOTES uint32 2 Return code for block reward reduction because the block header does not imply the maximal number of prevotes.
REWARD_REDUCTION_NO_ACCOUNT uint32 3 Return code for block reward reduction because the TOKEN_ID_DYNAMIC_BLOCK_REWARD account is not initialized.
REWARD_REDUCTION_FACTOR_BFT uint32 4 The reduction factor for validator block reward in case when the block header does not imply the maximal number of prevotes.
SUBSTORE_PREFIX_END_OF_ROUND_TIMESTAMP bytes 0xe000 The substore prefix of the End-Of-Round timestamp substore.
Configurable Constants Mainchain Value
FACTOR_MINIMUM_REWARD_ACTIVE_VALIDATORS uint32 1000 It determines the percentage of rewards assigned equally to all active validators. The percentage can be obtained by dividing the value by 100, i.e., a value of 1000 corresponds to 10% .
TOKEN_ID_DYNAMIC_BLOCK_REWARD bytes configurable The token ID of the token used for the reward system of the Blockchain.
NUMBER_ACTIVE_VALIDATORS uint32 101 The number of active validators (as defined in PoS module).
ROUND_LENGTH uint32 103 The round length (as defined in PoS module).

Furthermore, for the rest of this LIP we indicate with ctx the execution context which is passed as extra input to each method call.

Reward Computation

We calculate the rewards for validators as follows:

Name Mainchain Value Computation Description
minimumRewardActiveValidators 107 (FACTOR_MINIMUM_REWARD_ACTIVE_VALIDATORS * getDefaultRewardAtHeight(blockHeader.height))//DECIMAL_PERCENT_FACTOR The minimum reward per round for an active validator. Here DECIMAL_PERCENT_FACTOR == 10000 and blockHeader.height is the current block height.
totalRewardActiveValidators 101*108 NUMBER_ACTIVE_VALIDATORS * getDefaultRewardAtHeight(blockHeader.height) The total reward per round for active validators. Here blockHeader.height is the current block height.
stakeRewardActiveValidators 90.9*108 totalRewardActiveValidators - NUMBER_ACTIVE_VALIDATORS * minimumRewardActiveValidators The remaining rewards for active validators (per round) after giving the minimum reward.
defaultRewardStandByValidators 108 getDefaultRewardAtHeight(blockHeader.height) The default reward per round for standby validators irrespective of their validator weight. Here blockHeader.height is the current block height.

Here getDefaultRewardAtHeight, returns a 64-bit unsigned integer value, the default block reward, given the block height as input.

Functions from Other Modules

Calling a function fct from another module (named module) is represented by module.fct(required inputs).

Dynamic Block Rewards Module Store

The key-value pairs in the module store are organized as follows:

End-Of-Round Timestamp Substore

Substore Prefix, Store Key, and Store Value

The entry in the end-of-round timestamp substore is as follows:

  • The substore prefix is set to SUBSTORE_PREFIX_END_OF_ROUND_TIMESTAMP.
  • The store key is set to empty bytes.
  • The store value is the serialization of an object following endOfRoundTimestampStoreSchema
  • Notation: For the rest of this proposal, let endOfRoundTimestamp be the timestamp property of the entry in the end-of-round timestamp substore, deserialized using the endOfRoundTimestampStoreSchema schema.
JSON Schema
endOfRoundTimestampStoreSchema = {
    "type": "object",
    "required": ["timestamp"],
    "properties": {
        "timestamp": {
            "dataType": "uint32",
            "fieldNumber": 1
        }
    }
}
Properties
  • timestamp: The timestamp of the last block in a round.

Token for Rewards

The Dynamic Block Rewards module triggers the minting of rewards in the fungible token identified by the value of TOKEN_ID_DYNAMIC_BLOCK_REWARD, which denotes a token ID. The value of TOKEN_ID_DYNAMIC_BLOCK_REWARD is set according to the initial configuration of the Dynamic Block Rewards module.

Reward Brackets

As part of the Dynamic Block Rewards module configuration, the module has to define certain reward brackets, i.e., the values of the default block reward depending on the height of the block. For this LIP, we assume the reward brackets are given by the function getDefaultRewardAtHeight, which returns a 64-bit unsigned integer value, the default block reward, given the block height as input.

Lisk Mainchain Configuration

Mainchain Rewards Token

The token for rewards on the Lisk mainchain is the LSK token. The value of TOKEN_ID_DYNAMIC_BLOCK_REWARD is defined in LIP 0063.

Mainchain Reward Brackets

The reward brackets for the Lisk Mainchain are as follows:

Height Default Reward
From 1,451,520 to 4,451,519 5 × 108
From 4,451,520 to 7,451,519 4 × 108
From 7,451,520 to 10,451,519 3 × 108
From 10,451,520 to 13,451,519 2 × 108
From 13,451,520 onwards 1 × 108

This corresponds to default rewards of 5 LSK, 4 LSK, 3 LSK, 2 LSK, and 1 LSK respectively.

Commands

This module does not define any command.

Events

rewardMinted

The event is emitted when the reward is minted. In case of a reward reduction, it provides information about the reason for the reduction. This event has the name = EVENT_NAME_REWARD_MINTED.

Topics

  • generatorAddress: the address of the block generator that obtains the reward.

Data

rewardMintedDataSchema = {
    "type": "object",
    "required": ["amount", "reduction"],
    "properties": {
        "amount": {
            "dataType": "uint64",
            "fieldNumber": 1
        },
        "reduction": {
            "dataType": "uint32",
            "fieldNumber": 2
        }
    }
}
  • amount: the amount of rewards minted.
  • reduction: an integer indicating whether the reward was reduced and for which reason. Allowed values are: REWARD_NO_REDUCTION, REWARD_REDUCTION_SEED_REVEAL, REWARD_REDUCTION_MAX_PREVOTES, REWARD_REDUCTION_NO_ACCOUNT.

Internal Functions

The Dynamic Block Rewards module has the following internal functions.

getDynamicBlockReward

This function is used to retrieve the reward of a block for a validator.

Returns

  • amount: amount of block reward to be minted.
  • reduction: an integer indicating whether the reward is reduced and if yes, for which reason. Possible values are REWARD_NO_REDUCTION, and REWARD_REDUCTION_SEED_REVEAL.
def getDynamicBlockReward(blockHeader: BlockHeader)-> tuple[uint64, uint32]:
    if Random.isSeedRevealValid(blockHeader.generatorAddress, blockHeader.seedReveal) == False:
        return (0, REWARD_REDUCTION_SEED_REVEAL)

    validatorReward = getValidatorBlockReward(blockHeader)

    if blockHeader.impliesMaxPrevotes == False:
        return (validatorReward // REWARD_REDUCTION_FACTOR_BFT, REWARD_REDUCTION_MAX_PREVOTES)

    return (validatorReward, REWARD_NO_REDUCTION)

Here // represents integer division.

getValidatorBlockReward

This function is used to retrieve the block reward for a validator.

Returns

  • reward: amount of block reward for a validator.
def getValidatorBlockReward(blockHeader: BlockHeader) -> uint64:
    if len(Validators.getGeneratorsBetweenTimestamps(endOfRoundTimestamp, blockHeader.timestamp)) >= ROUND_LENGTH:
        return minimumRewardActiveValidators

    validatorParams = Validators.getValidatorParams()
    totalBftWeight = sum(validator.bftWeight for validator in validatorParams.validators)

    let validator be the item of validatorParams.validators with item.address == blockHeader.generatorAddress

    if validator.bftWeight > 0:
        reward = minimumRewardActiveValidators + (validator.bftWeight * stakeRewardActiveValidators)//totalBftWeight
        return reward
    else:
        return defaultRewardStandByValidators

Protocol Logic for Other Modules

The Dynamic Block Rewards module exposes the following functions for other modules.

getDefaultRewardAtHeight

This function is used to retrieve the expected default reward at a given height.

Parameters

The height of a block as a 32-bit unsigned integer.

Returns

The default reward of the block as a 64-bit unsigned integer.

Endpoints for Off-Chain Services

TBD.

Genesis Block Processing

Genesis State Initialization

After the genesis block b is executed, the following logic is executed:

  • Create the entry in the end-of-round timestamp substore, setting endOfRoundTimestamp.timestamp to b.header.timestamp.

Genesis State Finalization

The Dynamic Block Rewards module does not execute any logic during the genesis state finalization.

Block Processing

Before Transactions Execution

Before the transactions of a block b are executed, the following logic is executed:

def beforeTransactionsExecute(b: Block) -> None:
    # Update blockReward value of the block reward substore.
    (ctx.blockReward, ctx.reduction) = getDynamicBlockReward(b.header)

Here we calculate the reward for the block generator; then this value will be stored in the context in memory for the afterTransactionsExecute in order to mint this reward and assign it to the generator. The reason for calculating the reward here is to make sure that during the call to getDynamicBlockReward function, the Validators module takes the BFT weight from the PoS module. Therefore, if we calculate the reward in afterTransactionsExecute, there might be a case where BFT weights are being updated by PoS module before calculating the reward then the reward could be from the next/future round.

After Transactions Execution

The following function assigns block rewards after all transactions in the block are executed.

def afterTransactionsExecute(b: Block) -> None:
    if ctx.blockReward > 0:
        if Token.userSubstoreExists(b.header.generatorAddress, TOKEN_ID_DYNAMIC_BLOCK_REWARD):
            Token.mint(b.header.generatorAddress, TOKEN_ID_DYNAMIC_BLOCK_REWARD, ctx.blockReward)
            PoS.updateSharedRewards(b.header.generatorAddress, TOKEN_ID_DYNAMIC_BLOCK_REWARD, ctx.blockReward)
        else:
            ctx.blockReward = 0
            ctx.reduction = REWARD_REDUCTION_NO_ACCOUNT

    if PoS.isEndOfRound(b.header.height):
        # Update the entry in the End-Of-Round timestamp substore.
        endOfRoundTimestamp = b.header.timestamp

    emitEvent(
        module = MODULE_NAME_DYNAMIC_BLOCK_REWARDS,
        name = EVENT_NAME_REWARD_MINTED,
        data = {
            "amount": ctx.blockReward,
            "reduction": ctx.reduction
        },
        topics = [b.header.generatorAddress]
    )

Backwards Compatibility

This LIP defines the interface for the Dynamic Block Rewards module but does not introduce any change to the protocol, hence it is a backward compatible change.