Replies: 1 comment
-
Good question! On the protocol level, QAP is based on the “sum of the verified data size” not the sector size, same goes to datacap usage. However, I think your concern around how data preparers/aggregators manipulate the car size with many paddings is valid. I think you might have more insight than I do - is there a reason why all the cars have to be prepared as 32gib/64gib, even when there is less data to store? i personally think the governance process of fil+ where the client is verified not the data is somewhat questionable. Especially with LDN, one may get datacap that’s way more than the actual data size. I’m wondering: should therebe a step along the lines of clients submit the CIDs of the data segment upon datacap application, which later will be used for verification via PoDSI later after car aggregation. Someone may run an offchain fil+ verifying service/oracle that checks the stored data is what’s claimed in the application, if not, there shall be some penalize mechanisms (a smart contract?). |
Beta Was this translation helpful? Give feedback.
-
Situation:
When data is packed into CAR files, the data preparer may choose to have a lot of padding (to reach a power of two).
For example a deal with 16.8 GiB of data will pad to a full 32 GiB sector and provide 320 GiB QAP.
The majority of real data sectors I see in Evergreen are closer to 53% than 95% efficiency.
Why this matters:
The Filecoin QAP calculation is based on padded sector size (i.e., round up to next size that is power of 2, a 16.8 GiB deal is worth 320 GiB total QAP)
This translates into much more power per GiB of real data, thus almost twice as profitable.
When we apply for datacap, we need to factor in the padded piece size as part of the application.
Real world example of a recent sector:
Example deal and power on my machine:
Sector Status On Chain Proving Expiration Epoch Deals in Sector Raw Power additional QAP power
5821 Proving YES YES 3943292 (in 1 year 23 weeks) 1 32GiB 288GiB
To arrive at total QAP add 32GiB + 288GiB = 320GiB total QAP
Questions:
Is the way QAP calculated going to change based on this?
Data cap requests need to take this into account? (there is never 100% efficiency in packing)
What other issues does this raise?
Beta Was this translation helpful? Give feedback.
All reactions