Break apart HIP-10 PoC rewards redistribution as a separate rewards type

[abhay]

After the implementation of HIP-10, the remainder of the DC rewards pool is given back to PoC participants during epochs with unspent rewards. This causes a dramatic variation in PoC rewards since they are not broken apart and this causes frequent questions in the community.

Proposal: Implement a new set of reward types and treat them as separate "bonus" categories. We may not be able to backfill this data into etl but at the very least, we can account for this going forward. This will need appropriate planning for mobile app changes.

[abhay]

@evanmcc @vihu thoughts?

[madninja]

backfilling would indeed be reasonably hard since we wouldn't know what the chain decided at the time. In addition since we decided to sum rewards for a hotspot in an epoch it wouldn't matter?

Assuming this would be an official reward type it would go behind a var and at least show in the rewards txn, even if it's summarized in the etl rewards table?

[vihu]

We were discussing doing something like this at some point for reward_v2 txns. It does the opposite of introducing a new type though.

syntax = "proto3";
package helium;

message blockchain_txn_reward_v2 {
    repeated award awards = 1;
}

message award {
    bytes account;
    uint64 amount
}

Primary reason being that our reward transactions are getting ginormous and fundamentally the blockchain doesn't quite care what the types are, all the chain cares about is whether some account X got rewarded in some block Y and is it consistent. The per-type breakdown can instead be handled in etl, blockchain-core can provide accessors to the intermediate per-type calculations. Also per-type breakdown doesn't necessarily need to appear within a block.

That said, doing so would certainly introduce opaqueness to UX (atleast initially).

I know this is not quite what you asked @abhay just something to consider :slightly_smiling_face:

[abhay]

Primary reason being that our reward transactions are getting ginormous and fundamentally the blockchain doesn't quite care what the types are, all the chain cares about is whether some account X got rewarded in some block Y and is it consistent. The per-type breakdown can instead be handled in etl, blockchain-core can provide accessors to the intermediate per-type calculations. Also per-type breakdown doesn't necessarily need to appear within a block.

That said, doing so would certainly introduce opaqueness to UX (atleast initially).

I think there's a way to do this at some point and it becomes a priority when we feel like the repetition of data in the blockchain is too much. We have fairly large addresses that we repeat 5 times already in the worst case (3 PoC, 1 dc, 1 CG, etc). There may be some other ways to compact this without introducing opaqueness (mapped data?) or we could just have blockchain data consumers have to do the same rewards calculations. To be discussed when we cross that road.

[abhay]

backfilling would indeed be reasonably hard since we wouldn't know what the chain decided at the time. In addition since we decided to sum rewards for a hotspot in an epoch it wouldn't matter?

That makes sense. We can avoid doing the backfill for now.

Assuming this would be an official reward type it would go behind a var and at least show in the rewards txn, even if it's summarized in the etl rewards table?

Correct. But I think the types are used in activity and so we'd need to have the app and explorer handle this before we turn on the chain var.

cc @cokes518 @allenan @danielcolinjames