Community address #1498
Community address #1498
Conversation
data/block/proto/metaBlock.proto
Outdated
| uint64 PrevEpochStartRound = 6; | ||
| bytes PrevEpochStartHash = 7; | ||
| bytes RewardsForCommunity = 5 [(gogoproto.casttypewith) = "math/big.Int;github.com/ElrondNetwork/elrond-go/data.BigIntCaster"]; | ||
| bytes CommunityAddress = 6; |
There was a problem hiding this comment.
There is no need for this to appear in the metablock. It is enough to appear in the generated reward transactions
There was a problem hiding this comment.
the bigInt of rewards for community can remain as it is super visible, but the address can be read from the config.
epochStart/metachain/economics.go
Outdated
| func (e *economics) computeRewardsForCommunity(totalRewards *big.Int) *big.Int { | ||
| precentageAdjustment := float64(100) | ||
| communityPercentage := big.NewInt(0).SetUint64(uint64(e.rewardsHandler.CommunityPercentage() * precentageAdjustment)) | ||
| rewardsForCommunity := big.NewInt(0).Mul(totalRewards, communityPercentage) |
There was a problem hiding this comment.
you can use core.GetPercentageOfValue instead of this.
epochStart/metachain/rewards.go
Outdated
| metaBlock *block.MetaBlock, | ||
| ) (*rewardTx.RewardTx, []byte, uint32, error) { | ||
|
|
||
| communityAddress := metaBlock.EpochStart.Economics.CommunityAddress |
There was a problem hiding this comment.
community address may be saved as an internal variable to the rewardsCreator - and this check can be done, address validity at the time of constructor.
config/tomlConfig_test.go
Outdated
| @@ -138,6 +141,7 @@ func TestTomlEconomicsParser(t *testing.T) { | |||
| [RewardsSettings] | |||
| RewardsValue = "` + rewardsValue + `" | |||
There was a problem hiding this comment.
There is no rewardsValue and burnPercentage any more.
| @@ -179,11 +183,16 @@ func convertValues(economics *config.EconomicsConfig) (*EconomicsData, error) { | |||
| func checkValues(economics *config.EconomicsConfig) error { | |||
| if isPercentageInvalid(economics.RewardsSettings.LeaderPercentage) || | |||
There was a problem hiding this comment.
are these tests enough for the rewards percentages? Could it be that all are below 100% but together account for more than 100%? e.g. LeaderPercentage 80% and DeveloperPercentage 80% in total we have 160% of the fees in a SC call?
There was a problem hiding this comment.
indeed these are not enough.
But there are different criterias as the leader percentage is applied to the accumulated fees in the proposed block, whereas the developerPercentage is applied to the transaction fee calling the speciffic SC, so also not part of the total. The community percentage is applied to the total.
Due to your comment I checked a bit and found a bug in the accumulated fees and what the Leader receives. The accumulated fees are considered entirely when computing the rewards per block, but then again the leader receives in addition the leader percentage -> leader percentage should have been subtracted before computing the rewards per block, otherwise we are giving that portion twice.
Added rewards for community
At the end of the epoch a percentage defined in config from the protocol rewards will be directed towards a community account