Skip to content
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

Merged
merged 12 commits into from
Jan 16, 2024
Merged

Reward granularity #698

merged 12 commits into from
Jan 16, 2024

Conversation

maplant
Copy link
Contributor

@maplant maplant commented Jan 3, 2024

No description provided.

*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;
Copy link
Contributor

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 ?

Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

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 ?

Copy link
Contributor Author

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;
Copy link
Contributor

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

@maplant maplant merged commit 9e076d1 into main Jan 16, 2024
1 check passed
@maplant maplant deleted the map/reward-granularity branch January 16, 2024 19:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants