move lamborghini distribution to subfolder
This commit is contained in:
parent
eb6f51ed45
commit
2d613cefe7
|
@ -0,0 +1,2 @@
|
||||||
|
Please note that this folder is a WIP specification for an advanced fee distribution
|
||||||
|
mechanism which is not set to be implemented.
|
|
@ -0,0 +1,54 @@
|
||||||
|
# Distribution
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
Collected fees are pooled globally and divided out passively to validators and
|
||||||
|
delegators. Each validator has the opportunity to charge commission to the
|
||||||
|
delegators on the fees collected on behalf of the delegators by the validators.
|
||||||
|
Fees are paid directly into a global fee pool, and validator proposer-reward
|
||||||
|
pool. Due to the nature of passive accounting whenever changes to parameters
|
||||||
|
which affect the rate of fee distribution occurs, withdrawal of fees must also
|
||||||
|
occur when:
|
||||||
|
|
||||||
|
- withdrawing one must withdrawal the maximum amount they are entitled
|
||||||
|
too, leaving nothing in the pool,
|
||||||
|
- bonding, unbonding, or re-delegating tokens to an existing account a
|
||||||
|
full withdrawal of the fees must occur (as the rules for lazy accounting
|
||||||
|
change),
|
||||||
|
- a validator chooses to change the commission on fees, all accumulated
|
||||||
|
commission fees must be simultaneously withdrawn.
|
||||||
|
|
||||||
|
The above scenarios are covered in `triggers.md`.
|
||||||
|
|
||||||
|
The distribution mechanism outlines herein is used to lazily distribute the
|
||||||
|
following between validators and associated delegators:
|
||||||
|
- multi-token fees to be socially distributed,
|
||||||
|
- proposer reward pool,
|
||||||
|
- inflated atom provisions, and
|
||||||
|
- validator commission on all rewards earned by their delegators stake
|
||||||
|
|
||||||
|
Fees are pooled within a global pool, as well as validator specific
|
||||||
|
proposer-reward pools. The mechanisms used allow for validators and delegators
|
||||||
|
to independently and lazily withdrawn their rewards. As a part of the lazy
|
||||||
|
computations adjustment factors must be maintained for each validator and
|
||||||
|
delegator to determine the true proportion of fees in each pool which they are
|
||||||
|
entitled too. Adjustment factors are updated every time a validator or
|
||||||
|
delegator's voting power changes. Validators and delegators must withdraw all
|
||||||
|
fees they are entitled too before they can change their portion of bonded
|
||||||
|
Atoms.
|
||||||
|
|
||||||
|
## Affect on Staking
|
||||||
|
|
||||||
|
|
||||||
|
Charging commission on Atom provisions while also allowing for Atom-provisions
|
||||||
|
to be auto-bonded (distributed directly to the validators bonded stake) is
|
||||||
|
problematic within DPoS. Fundamentally these two mechnisms are mutually
|
||||||
|
exclusive. If there are atoms commissions and auto-bonding Atoms, the portion
|
||||||
|
of Atoms the fee distribution calculation would become very large as the Atom
|
||||||
|
portion for each delegator would change each block making a withdrawal of fees
|
||||||
|
for a delegator require a calculation for every single block since the last
|
||||||
|
withdrawal. In conclusion we can only have atom commission and unbonded atoms
|
||||||
|
provisions, or bonded atom provisions with no Atom commission, and we elect to
|
||||||
|
implement the former. Stakeholders wishing to rebond their provisions may elect
|
||||||
|
to set up a script to periodically withdraw and rebond fees.
|
||||||
|
|
|
@ -0,0 +1,100 @@
|
||||||
|
## State
|
||||||
|
|
||||||
|
### Global
|
||||||
|
|
||||||
|
All globally tracked parameters for distribution are stored within
|
||||||
|
`Global`. Rewards are collected and added to the reward pool and
|
||||||
|
distributed to validators/delegators from here.
|
||||||
|
|
||||||
|
Note that the reward pool holds decimal coins (`DecCoins`) to allow
|
||||||
|
for fractions of coins to be received from operations like inflation.
|
||||||
|
When coins are distributed from the pool they are truncated back to
|
||||||
|
`sdk.Coins` which are non-decimal.
|
||||||
|
|
||||||
|
- Global: `0x00 -> amino(global)`
|
||||||
|
|
||||||
|
```golang
|
||||||
|
// coins with decimal
|
||||||
|
type DecCoins []DecCoin
|
||||||
|
|
||||||
|
type DecCoin struct {
|
||||||
|
Amount sdk.Dec
|
||||||
|
Denom string
|
||||||
|
}
|
||||||
|
|
||||||
|
type Global struct {
|
||||||
|
PrevBondedTokens sdk.Dec // bonded token amount for the global pool on the previous block
|
||||||
|
Adjustment sdk.Dec // global adjustment factor for lazy calculations
|
||||||
|
Pool DecCoins // funds for all validators which have yet to be withdrawn
|
||||||
|
PrevReceivedPool DecCoins // funds added to the pool on the previous block
|
||||||
|
EverReceivedPool DecCoins // total funds ever added to the pool
|
||||||
|
CommunityFund DecCoins // pool for community funds yet to be spent
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Validator Distribution
|
||||||
|
|
||||||
|
Validator distribution information for the relevant validator is updated each time:
|
||||||
|
1. delegation amount to a validator are updated,
|
||||||
|
2. a validator successfully proposes a block and receives a reward,
|
||||||
|
3. any delegator withdraws from a validator, or
|
||||||
|
4. the validator withdraws it's commission.
|
||||||
|
|
||||||
|
- ValidatorDistribution: `0x02 | ValOwnerAddr -> amino(validatorDistribution)`
|
||||||
|
|
||||||
|
```golang
|
||||||
|
type ValidatorDistribution struct {
|
||||||
|
CommissionWithdrawalHeight int64 // last time this validator withdrew commission
|
||||||
|
Adjustment sdk.Dec // global pool adjustment factor
|
||||||
|
ProposerAdjustment DecCoins // proposer pool adjustment factor
|
||||||
|
ProposerPool DecCoins // reward pool collected from being the proposer
|
||||||
|
EverReceivedProposerReward DecCoins // all rewards ever collected from being the proposer
|
||||||
|
PrevReceivedProposerReward DecCoins // previous rewards collected from being the proposer
|
||||||
|
PrevBondedTokens sdk.Dec // bonded token amount on the previous block
|
||||||
|
PrevDelegatorShares sdk.Dec // amount of delegator shares for the validator on the previous block
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Delegation Distribution
|
||||||
|
|
||||||
|
Each delegation holds multiple adjustment factors to specify its entitlement to
|
||||||
|
the rewards from a validator. `AdjustmentPool` is used to passively calculate
|
||||||
|
each bonds entitled fees from the `RewardPool`. `AdjustmentPool` is used to
|
||||||
|
passively calculate each bonds entitled fees from
|
||||||
|
`ValidatorDistribution.ProposerRewardPool`
|
||||||
|
|
||||||
|
- DelegatorDistribution: ` 0x02 | DelegatorAddr | ValOwnerAddr -> amino(delegatorDist)`
|
||||||
|
|
||||||
|
```golang
|
||||||
|
type DelegatorDist struct {
|
||||||
|
WithdrawalHeight int64 // last time this delegation withdrew rewards
|
||||||
|
Adjustment sdk.Dec // fee provisioning adjustment factor
|
||||||
|
AdjustmentProposer DecCoins // proposers pool adjustment factor
|
||||||
|
PrevTokens sdk.Dec // bonded tokens held by the delegation on the previous block
|
||||||
|
PrevShares sdk.Dec // delegator shares held by the delegation on the previous block
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Power Change
|
||||||
|
|
||||||
|
Every instance that the voting power changes, information about the state of
|
||||||
|
the validator set during the change must be recorded as a `PowerChange` for
|
||||||
|
other validators to run through. Each power change is indexed by its block
|
||||||
|
height.
|
||||||
|
|
||||||
|
- PowerChange: `0x03 | amino(Height) -> amino(validatorDist)`
|
||||||
|
|
||||||
|
```golang
|
||||||
|
type PowerChange struct {
|
||||||
|
Height int64 // block height at change
|
||||||
|
ValidatorBondedTokens sdk.Dec // following used to create distribution scenarios
|
||||||
|
ValidatorDelegatorShares sdk.Dec
|
||||||
|
ValidatorDelegatorShareExRate sdk.Dec
|
||||||
|
ValidatorCommission sdk.Dec
|
||||||
|
PoolBondedTokens sdk.Dec
|
||||||
|
Global Global
|
||||||
|
ValDistr ValidatorDistribution
|
||||||
|
DelegationShares sdk.Dec
|
||||||
|
DelDistr DelegatorDistribution
|
||||||
|
}
|
||||||
|
```
|
|
@ -2,26 +2,31 @@
|
||||||
|
|
||||||
## Overview
|
## Overview
|
||||||
|
|
||||||
Collected fees are pooled globally and divided out passively to validators and
|
This _simple_ distribution mechanism describes a functional way to passively
|
||||||
delegators. Each validator has the opportunity to charge commission to the
|
distribute rewards between validator and delegators. Note that this mechanism does
|
||||||
delegators on the fees collected on behalf of the delegators by the validators.
|
not distribute funds in as precisely as active reward distribution and will therefor
|
||||||
Fees are paid directly into a global fee pool, and validator proposer-reward
|
be upgraded in the future.
|
||||||
pool. Due to the nature of passive accounting whenever changes to parameters
|
|
||||||
which affect the rate of fee distribution occurs, withdrawal of fees must also
|
The mechanism operates as follows. Collected rewards are pooled globally and
|
||||||
occur when:
|
divided out passively to validators and delegators. Each validator has the
|
||||||
|
opportunity to charge commission to the delegators on the rewards collected on
|
||||||
|
behalf of the delegators by the validators. Fees are paid directly into a
|
||||||
|
global reward pool, and validator proposer-reward pool. Due to the nature of
|
||||||
|
passive accounting whenever changes to parameters which affect the rate of reward
|
||||||
|
distribution occurs, withdrawal of rewards must also occur when:
|
||||||
|
|
||||||
- withdrawing one must withdrawal the maximum amount they are entitled
|
- withdrawing one must withdrawal the maximum amount they are entitled
|
||||||
too, leaving nothing in the pool,
|
too, leaving nothing in the pool,
|
||||||
- bonding, unbonding, or re-delegating tokens to an existing account a
|
- bonding, unbonding, or re-delegating tokens to an existing account a
|
||||||
full withdrawal of the fees must occur (as the rules for lazy accounting
|
full withdrawal of the rewards must occur (as the rules for lazy accounting
|
||||||
change),
|
change),
|
||||||
- a validator chooses to change the commission on fees, all accumulated
|
- a validator chooses to change the commission on rewards, all accumulated
|
||||||
commission fees must be simultaneously withdrawn.
|
commission rewards must be simultaneously withdrawn.
|
||||||
|
|
||||||
The above scenarios are covered in `triggers.md`.
|
The above scenarios are covered in `triggers.md`.
|
||||||
|
|
||||||
The distribution mechanism outlines herein is used to lazily distribute the
|
The distribution mechanism outlines herein is used to lazily distribute the
|
||||||
following between validators and associated delegators:
|
following rewards between validators and associated delegators:
|
||||||
- multi-token fees to be socially distributed,
|
- multi-token fees to be socially distributed,
|
||||||
- proposer reward pool,
|
- proposer reward pool,
|
||||||
- inflated atom provisions, and
|
- inflated atom provisions, and
|
||||||
|
@ -29,26 +34,31 @@ following between validators and associated delegators:
|
||||||
|
|
||||||
Fees are pooled within a global pool, as well as validator specific
|
Fees are pooled within a global pool, as well as validator specific
|
||||||
proposer-reward pools. The mechanisms used allow for validators and delegators
|
proposer-reward pools. The mechanisms used allow for validators and delegators
|
||||||
to independently and lazily withdrawn their rewards. As a part of the lazy
|
to independently and lazily withdrawn their rewards.
|
||||||
computations adjustment factors must be maintained for each validator and
|
|
||||||
delegator to determine the true proportion of fees in each pool which they are
|
Within this spec
|
||||||
entitled too. Adjustment factors are updated every time a validator or
|
|
||||||
delegator's voting power changes. Validators and delegators must withdraw all
|
As a part of the lazy computations, each validator and delegator holds an
|
||||||
fees they are entitled too before they can change their portion of bonded
|
accumulation term which is used to estimate what their approximate fair portion
|
||||||
Atoms.
|
of tokens held in the global pool is owed to them. This approximation of owed
|
||||||
|
rewards would be equivalent to the active distribution under the situation that
|
||||||
|
there was a constant flow of incoming reward tokens every block. Because this
|
||||||
|
is not the case, the approximation of owed rewards will deviate from the active
|
||||||
|
distribution based on fluctuations of incoming reward tokens as well as timing
|
||||||
|
of reward withdrawal by other delegators and validators from the reward pool.
|
||||||
|
|
||||||
|
|
||||||
## Affect on Staking
|
## Affect on Staking
|
||||||
|
|
||||||
|
|
||||||
Charging commission on Atom provisions while also allowing for Atom-provisions
|
Charging commission on Atom provisions while also allowing for Atom-provisions
|
||||||
to be auto-bonded (distributed directly to the validators bonded stake) is
|
to be auto-bonded (distributed directly to the validators bonded stake) is
|
||||||
problematic within DPoS. Fundamentally these two mechnisms are mutually
|
problematic within DPoS. Fundamentally these two mechnisms are mutually
|
||||||
exclusive. If there are atoms commissions and auto-bonding Atoms, the portion
|
exclusive. If there are atoms commissions and auto-bonding Atoms, the portion
|
||||||
of Atoms the fee distribution calculation would become very large as the Atom
|
of Atoms the reward distribution calculation would become very large as the Atom
|
||||||
portion for each delegator would change each block making a withdrawal of fees
|
portion for each delegator would change each block making a withdrawal of rewards
|
||||||
for a delegator require a calculation for every single block since the last
|
for a delegator require a calculation for every single block since the last
|
||||||
withdrawal. In conclusion we can only have atom commission and unbonded atoms
|
withdrawal. In conclusion we can only have atom commission and unbonded atoms
|
||||||
provisions, or bonded atom provisions with no Atom commission, and we elect to
|
provisions, or bonded atom provisions with no Atom commission, and we elect to
|
||||||
implement the former. Stakeholders wishing to rebond their provisions may elect
|
implement the former. Stakeholders wishing to rebond their provisions may elect
|
||||||
to set up a script to periodically withdraw and rebond fees.
|
to set up a script to periodically withdraw and rebond rewards.
|
||||||
|
|
||||||
|
|
|
@ -23,11 +23,8 @@ type DecCoin struct {
|
||||||
}
|
}
|
||||||
|
|
||||||
type Global struct {
|
type Global struct {
|
||||||
PrevBondedTokens sdk.Dec // bonded token amount for the global pool on the previous block
|
Accum sdk.Dec // global accumulation factor for lazy calculations
|
||||||
Adjustment sdk.Dec // global adjustment factor for lazy calculations
|
|
||||||
Pool DecCoins // funds for all validators which have yet to be withdrawn
|
Pool DecCoins // funds for all validators which have yet to be withdrawn
|
||||||
PrevReceivedPool DecCoins // funds added to the pool on the previous block
|
|
||||||
EverReceivedPool DecCoins // total funds ever added to the pool
|
|
||||||
CommunityFund DecCoins // pool for community funds yet to be spent
|
CommunityFund DecCoins // pool for community funds yet to be spent
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
@ -45,22 +42,18 @@ Validator distribution information for the relevant validator is updated each ti
|
||||||
```golang
|
```golang
|
||||||
type ValidatorDistribution struct {
|
type ValidatorDistribution struct {
|
||||||
CommissionWithdrawalHeight int64 // last time this validator withdrew commission
|
CommissionWithdrawalHeight int64 // last time this validator withdrew commission
|
||||||
Adjustment sdk.Dec // global pool adjustment factor
|
Accum sdk.Dec // global pool accumulation factor
|
||||||
ProposerAdjustment DecCoins // proposer pool adjustment factor
|
ProposerAccum sdk.Dec // proposer pool accumulation factor
|
||||||
ProposerPool DecCoins // reward pool collected from being the proposer
|
ProposerPool DecCoins // reward pool collected from being the proposer
|
||||||
EverReceivedProposerReward DecCoins // all rewards ever collected from being the proposer
|
|
||||||
PrevReceivedProposerReward DecCoins // previous rewards collected from being the proposer
|
|
||||||
PrevBondedTokens sdk.Dec // bonded token amount on the previous block
|
|
||||||
PrevDelegatorShares sdk.Dec // amount of delegator shares for the validator on the previous block
|
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
### Delegation Distribution
|
### Delegation Distribution
|
||||||
|
|
||||||
Each delegation holds multiple adjustment factors to specify its entitlement to
|
Each delegation holds multiple accumulation factors to specify its entitlement to
|
||||||
the rewards from a validator. `AdjustmentPool` is used to passively calculate
|
the rewards from a validator. `Accum` is used to passively calculate
|
||||||
each bonds entitled fees from the `RewardPool`. `AdjustmentPool` is used to
|
each bonds entitled rewards from the `RewardPool`. `AccumProposer` is used to
|
||||||
passively calculate each bonds entitled fees from
|
passively calculate each bonds entitled rewards from
|
||||||
`ValidatorDistribution.ProposerRewardPool`
|
`ValidatorDistribution.ProposerRewardPool`
|
||||||
|
|
||||||
- DelegatorDistribution: ` 0x02 | DelegatorAddr | ValOwnerAddr -> amino(delegatorDist)`
|
- DelegatorDistribution: ` 0x02 | DelegatorAddr | ValOwnerAddr -> amino(delegatorDist)`
|
||||||
|
@ -68,33 +61,8 @@ passively calculate each bonds entitled fees from
|
||||||
```golang
|
```golang
|
||||||
type DelegatorDist struct {
|
type DelegatorDist struct {
|
||||||
WithdrawalHeight int64 // last time this delegation withdrew rewards
|
WithdrawalHeight int64 // last time this delegation withdrew rewards
|
||||||
Adjustment sdk.Dec // fee provisioning adjustment factor
|
Accum sdk.Dec // reward provisioning accumulation factor
|
||||||
AdjustmentProposer DecCoins // proposers pool adjustment factor
|
AccumProposer sdk.Dec // proposers pool accumulation factor
|
||||||
PrevTokens sdk.Dec // bonded tokens held by the delegation on the previous block
|
|
||||||
PrevShares sdk.Dec // delegator shares held by the delegation on the previous block
|
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
### Power Change
|
|
||||||
|
|
||||||
Every instance that the voting power changes, information about the state of
|
|
||||||
the validator set during the change must be recorded as a `PowerChange` for
|
|
||||||
other validators to run through. Each power change is indexed by its block
|
|
||||||
height.
|
|
||||||
|
|
||||||
- PowerChange: `0x03 | amino(Height) -> amino(validatorDist)`
|
|
||||||
|
|
||||||
```golang
|
|
||||||
type PowerChange struct {
|
|
||||||
Height int64 // block height at change
|
|
||||||
ValidatorBondedTokens sdk.Dec // following used to create distribution scenarios
|
|
||||||
ValidatorDelegatorShares sdk.Dec
|
|
||||||
ValidatorDelegatorShareExRate sdk.Dec
|
|
||||||
ValidatorCommission sdk.Dec
|
|
||||||
PoolBondedTokens sdk.Dec
|
|
||||||
Global Global
|
|
||||||
ValDistr ValidatorDistribution
|
|
||||||
DelegationShares sdk.Dec
|
|
||||||
DelDistr DelegatorDistribution
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
|
@ -1,64 +0,0 @@
|
||||||
# Distribution
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
This _simple_ distribution mechanism describes a functional way to passively
|
|
||||||
distribute rewards between validator and delegators. Note that this mechanism does
|
|
||||||
not distribute funds in as precisely as active reward distribution and will therefor
|
|
||||||
be upgraded in the future.
|
|
||||||
|
|
||||||
The mechanism operates as follows. Collected rewards are pooled globally and
|
|
||||||
divided out passively to validators and delegators. Each validator has the
|
|
||||||
opportunity to charge commission to the delegators on the rewards collected on
|
|
||||||
behalf of the delegators by the validators. Fees are paid directly into a
|
|
||||||
global reward pool, and validator proposer-reward pool. Due to the nature of
|
|
||||||
passive accounting whenever changes to parameters which affect the rate of reward
|
|
||||||
distribution occurs, withdrawal of rewards must also occur when:
|
|
||||||
|
|
||||||
- withdrawing one must withdrawal the maximum amount they are entitled
|
|
||||||
too, leaving nothing in the pool,
|
|
||||||
- bonding, unbonding, or re-delegating tokens to an existing account a
|
|
||||||
full withdrawal of the rewards must occur (as the rules for lazy accounting
|
|
||||||
change),
|
|
||||||
- a validator chooses to change the commission on rewards, all accumulated
|
|
||||||
commission rewards must be simultaneously withdrawn.
|
|
||||||
|
|
||||||
The above scenarios are covered in `triggers.md`.
|
|
||||||
|
|
||||||
The distribution mechanism outlines herein is used to lazily distribute the
|
|
||||||
following rewards between validators and associated delegators:
|
|
||||||
- multi-token fees to be socially distributed,
|
|
||||||
- proposer reward pool,
|
|
||||||
- inflated atom provisions, and
|
|
||||||
- validator commission on all rewards earned by their delegators stake
|
|
||||||
|
|
||||||
Fees are pooled within a global pool, as well as validator specific
|
|
||||||
proposer-reward pools. The mechanisms used allow for validators and delegators
|
|
||||||
to independently and lazily withdrawn their rewards.
|
|
||||||
|
|
||||||
Within this spec
|
|
||||||
|
|
||||||
As a part of the lazy computations, each validator and delegator holds an
|
|
||||||
accumulation term which is used to estimate what their approximate fair portion
|
|
||||||
of tokens held in the global pool is owed to them. This approximation of owed
|
|
||||||
rewards would be equivalent to the active distribution under the situation that
|
|
||||||
there was a constant flow of incoming reward tokens every block. Because this
|
|
||||||
is not the case, the approximation of owed rewards will deviate from the active
|
|
||||||
distribution based on fluctuations of incoming reward tokens as well as timing
|
|
||||||
of reward withdrawal by other delegators and validators from the reward pool.
|
|
||||||
|
|
||||||
|
|
||||||
## Affect on Staking
|
|
||||||
|
|
||||||
Charging commission on Atom provisions while also allowing for Atom-provisions
|
|
||||||
to be auto-bonded (distributed directly to the validators bonded stake) is
|
|
||||||
problematic within DPoS. Fundamentally these two mechnisms are mutually
|
|
||||||
exclusive. If there are atoms commissions and auto-bonding Atoms, the portion
|
|
||||||
of Atoms the reward distribution calculation would become very large as the Atom
|
|
||||||
portion for each delegator would change each block making a withdrawal of rewards
|
|
||||||
for a delegator require a calculation for every single block since the last
|
|
||||||
withdrawal. In conclusion we can only have atom commission and unbonded atoms
|
|
||||||
provisions, or bonded atom provisions with no Atom commission, and we elect to
|
|
||||||
implement the former. Stakeholders wishing to rebond their provisions may elect
|
|
||||||
to set up a script to periodically withdraw and rebond rewards.
|
|
||||||
|
|
|
@ -1,68 +0,0 @@
|
||||||
## State
|
|
||||||
|
|
||||||
### Global
|
|
||||||
|
|
||||||
All globally tracked parameters for distribution are stored within
|
|
||||||
`Global`. Rewards are collected and added to the reward pool and
|
|
||||||
distributed to validators/delegators from here.
|
|
||||||
|
|
||||||
Note that the reward pool holds decimal coins (`DecCoins`) to allow
|
|
||||||
for fractions of coins to be received from operations like inflation.
|
|
||||||
When coins are distributed from the pool they are truncated back to
|
|
||||||
`sdk.Coins` which are non-decimal.
|
|
||||||
|
|
||||||
- Global: `0x00 -> amino(global)`
|
|
||||||
|
|
||||||
```golang
|
|
||||||
// coins with decimal
|
|
||||||
type DecCoins []DecCoin
|
|
||||||
|
|
||||||
type DecCoin struct {
|
|
||||||
Amount sdk.Dec
|
|
||||||
Denom string
|
|
||||||
}
|
|
||||||
|
|
||||||
type Global struct {
|
|
||||||
Accum sdk.Dec // global accumulation factor for lazy calculations
|
|
||||||
Pool DecCoins // funds for all validators which have yet to be withdrawn
|
|
||||||
CommunityFund DecCoins // pool for community funds yet to be spent
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### Validator Distribution
|
|
||||||
|
|
||||||
Validator distribution information for the relevant validator is updated each time:
|
|
||||||
1. delegation amount to a validator are updated,
|
|
||||||
2. a validator successfully proposes a block and receives a reward,
|
|
||||||
3. any delegator withdraws from a validator, or
|
|
||||||
4. the validator withdraws it's commission.
|
|
||||||
|
|
||||||
- ValidatorDistribution: `0x02 | ValOwnerAddr -> amino(validatorDistribution)`
|
|
||||||
|
|
||||||
```golang
|
|
||||||
type ValidatorDistribution struct {
|
|
||||||
CommissionWithdrawalHeight int64 // last time this validator withdrew commission
|
|
||||||
Accum sdk.Dec // global pool accumulation factor
|
|
||||||
ProposerAccum sdk.Dec // proposer pool accumulation factor
|
|
||||||
ProposerPool DecCoins // reward pool collected from being the proposer
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### Delegation Distribution
|
|
||||||
|
|
||||||
Each delegation holds multiple accumulation factors to specify its entitlement to
|
|
||||||
the rewards from a validator. `Accum` is used to passively calculate
|
|
||||||
each bonds entitled rewards from the `RewardPool`. `AccumProposer` is used to
|
|
||||||
passively calculate each bonds entitled rewards from
|
|
||||||
`ValidatorDistribution.ProposerRewardPool`
|
|
||||||
|
|
||||||
- DelegatorDistribution: ` 0x02 | DelegatorAddr | ValOwnerAddr -> amino(delegatorDist)`
|
|
||||||
|
|
||||||
```golang
|
|
||||||
type DelegatorDist struct {
|
|
||||||
WithdrawalHeight int64 // last time this delegation withdrew rewards
|
|
||||||
Accum sdk.Dec // reward provisioning accumulation factor
|
|
||||||
AccumProposer sdk.Dec // proposers pool accumulation factor
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
Loading…
Reference in New Issue