Verified data transfer #872
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…sion Verified meaning we know about the entities in the report. Even data sessions that have no rewardable data are written. They will not, however, be put into the database for rewarding.
michaeldjeffrey
force-pushed
the
mj/verified-data-transfer
branch
from
6936a6e
to
fb5fe50
Compare
bbalser
approved these changes
Oct 7, 2024
macpie
approved these changes
Oct 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proto PR: helium/proto#421
Deprecate
InvalidDataTransferIngestReportin lieu ofVerifiedDataTransferIngestReport.This allows someone reading the ingest report to have a full report of data transfer without needing to wait for the Burner to come along and write to
ValidDataTransferSessionwhich can happen an unknown amount of time later.Other
When dealing with many service provider all sending 2x above the total allocated service provider rewards, there is a chance the reported allocation is
1.0000000000000000000000000001%. As long as we never allocate more outgoing rewards than what is allowed, we're okay with this level of rounding error.Because these tests run randomly generated data for every CI, I've commented out the assertion, but left the important one of making sure we don't overallocate at the bone level. If that check fails, we indeed have a problem.