-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reward granularity #698
Reward granularity #698
Conversation
*map.entry(session.pub_key).or_default() += session.num_dcs as u64 | ||
let rewards = map.entry(session.pub_key).or_default(); | ||
rewards.rewardable_dc += session.num_dcs as u64; | ||
rewards.rewardable_bytes += session.upload_bytes as u64 + session.download_bytes as u64; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we not be carrying rewardable_bytes from the proto:ValidDataTransferSession into this session object and use that to accumulate rewardable_bytes rather than the older upload and download bytes values ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the difference between rewardable bytes transferred and num_dcs
? isn't num_dcs
just the number of data credits burned which is a direct result of data transferred? i'm missing why we're tracking both
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added rewardable_bytes to the gateway_reward
proto, I was thinking just to make it clearer how many bytes were considered rewardable for the gateway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seeing it in practice, i wonder if that wouldn't just cause more confusion having both. "why did i only get half of the rewards i should have when i processed this much burned data credits and transferred this much bytes?" #angrypitchforks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
further note on using rewardable_bytes vs upload + download bytes....cant the sum of upload+download bytes exceed that rewardable...hence why rewardable bytes was added ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also just more transparency - the rewardable_dc calculation uses a div_ceil operation, so the function is not exactly one to one
*map.entry(session.pub_key).or_default() += session.num_dcs as u64 | ||
let rewards = map.entry(session.pub_key).or_default(); | ||
rewards.rewardable_dc += session.num_dcs as u64; | ||
rewards.rewardable_bytes += session.upload_bytes as u64 + session.download_bytes as u64; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the difference between rewardable bytes transferred and num_dcs
? isn't num_dcs
just the number of data credits burned which is a direct result of data transferred? i'm missing why we're tracking both
No description provided.