It has been represented that there is a “race” to see which data holder delivers up a chunk fastest, as determined by the chunk being received by the requestor, and only then is a Farming Attempt awarded to the serving-up vault.
From my understanding of how the network works, this could not be so for several reasons:
- For this to happen, each returning chunk would have to have metadata attached as to which exact vault served up that particular chunk at that time. This would be a potential security problem, not to mention all the added traffic, as per further points below.
- The Client receiving the chunks would then have the burden of assessing the winner of the “race” and then have to send a message back to the Data Manager group responsible for that chunk, noting which specific vault won the race. This would be additional traffic for EACH unique chunk of a file.
- Only then could a request be sent as a Farming Attempt on behalf of the “winning” vault, to determine if a safecoin is available at the targeted safecoin address.
I can see even more potential for additional traffic having to be generated to do it this way.
I suspect that the simplicity is that if a vault serves up a valid chunk in response to a request, the math-“lottery” is run to see if it gets the chance to submit a Farming Attempt. If that is successful, only then does it get to submit a Farming Attempt, and perhaps get lucky and earn a safecoin.
Might more than one vault earn a farming attempt or even a safecoin for the same chunk? Sure. But then, each did serve up a valuable chunk. This is the most atomic action of a vault, done repeatedly and often. The Farming Rate is the lever. Determining winners and losers or all these “races”, with all the developed traffic, can’t be the way it’s done.
Am I wrong?