Initial draft for on chain commd #819
Conversation
ZenGround0
requested review from
momack2,
arajasek,
jennijuju,
kaitlin-beegle,
anorth and
raulk
as code owners
| ... | ||
| // Flag for QA power mechanism introduced in fip 0045 | ||
| pub simple_qa_power: bool, | ||
| } |
There was a problem hiding this comment.
pub struct SectorOnChainInfo {
pub sector_number: SectorNumber,
...
pub piece_cids: Option<Cid>, // NEW Amt[string]
...
// Flag for QA power mechanism introduced in fip 0045
pub simple_qa_power: bool,
}| Pieces: []PieceActivationManifest, | ||
| KeepCommD: bool, // NEW | ||
| } | ||
| ``` |
There was a problem hiding this comment.
struct PieceActivationManifest {
PieceCid Cid
PieceSize u64
Keep: bool, // NEW SP tell network to store or not
}
struct SectorActivationManifest {
// Sector to be activated.
Sector: SectorNumber,
// Pieces comprising the sector content, in order.
Pieces: []PieceActivationManifest,
}There was a problem hiding this comment.
@ZenGround0 Commd is hard to use, prefer to keep piece cids of data. however, considering the cost of on-chain storage, network can allow the SP to decide whether or not to store the piece of data. with this approach, the storage fee can regulate storage pressure and user demands.. network must do some verify to ensure pieces correctly.
- get unseadcid from precommit info
- calc commd from
[]PieceActivationManifest - check commd with precommit info
- keep pieces that SP want
There was a problem hiding this comment.
Thanks for reviewing @hunjixin. Take a look at my arguments against using CommP here: #760 (reply in thread). I agree CommP is more directly useful. I strongly disagree it belongs in the miner actor.
There was a problem hiding this comment.
I agree with @ZenGround0 position, a CommP can be proven to correspond to a given CommD, with proof of size O(log2(sector_size) - log2(piece_size)).
There was a problem hiding this comment.
Agree with @ZenGround0 arguments - the design needs to be scalable.
There was a problem hiding this comment.
Hello, @ZenGround0,
Ready for review
cc @Fatman13
Thank you for opening this up!
Some high-level points discussed within Venus team wrt to your comment here. We probably should have brought up this much earlier but wasn't sure about how to go about it until the opt-in model proposed in this draft...
- Too Expensive.
The team thinks that cost could be paid by imposing a gas model to whoever opt-in to save commP, so that each sector is encouraged to have one or two pieceCid rather than to have a long list of pieceCid like in Web3 dot storage.
- CommP is not much more useful than CommD.
The team thinks that CommP could be directly used in a L2 contract to initiate storage deal disputes with a better user experience than CommD. Using CommD to dispute a deal might involve extensive on-chain analytics and history lookbacks which client may or may not capable of doing?
- Leads to unscalable usage.
I think this maybe where the opt-in gas model coming into play, which may allow more diversed storage markets to be built, ie a market with a higher premium for easier ux.
High Level Rationale
Overall, apart from the exact technical route to achieve the stated goal of the FIP, the following are also worth considering...
- What really sets Filecoin apart from other storage chains? Given the current design route we are considering, could other chain or project, say eth.storage, achieve the same?
- Given that we want the minimal on-chain footprint, can we still provide features guided by the invisible hand of gas to let market to reach equilibrium?
- A better UX for storage client? (Especially from a L2 storage market perspective)
| --- | ||
| fip: "<to be assigned>" <!--keep the qoutes around the fip number, i.e: `fip: "0001"`--> | ||
| title: On Chain CommD | ||
| author: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s), e.g. (use with the parentheses or triangular brackets): @zenground0, Alex North (@anorth), ... |
| fip: "<to be assigned>" <!--keep the qoutes around the fip number, i.e: `fip: "0001"`--> | ||
| title: On Chain CommD | ||
| author: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s), e.g. (use with the parentheses or triangular brackets): @zenground0, Alex North (@anorth), ... | ||
| discussions-to: https://github.com/filecoin-project/FIPs/discussions/496, https://github.com/filecoin-project/FIPs/discussions/760 |
There was a problem hiding this comment.
can we point to one primary discussion rather than two? otherwise it could be messy to leave and track peer review feedback imho
|
|
||
| ## Change Motivation | ||
| <!--The motivation is critical for FIPs that want to change the Filecoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.--> | ||
| The filecoin development community has a demonstrated interest in enabling innovation in smart contracts that interact with verifiable storage. It is the FVM's main differentiator when compared with other blockchain runtimes. Two different groups have arrived at similar conclusions on a particular useful direction for the miner actor in relation to these goals: myself [here](https://github.com/filecoin-project/FIPs/discussions/496) and venus dev team [here](https://github.com/filecoin-project/FIPs/discussions/760). The first step in this direction is to allow SPs to keep CommD on chain in the sector info. |
There was a problem hiding this comment.
It is the FVM's main differentiator when compared with other blockchain runtimes.
im not sure why verifiable storage is a runtime feature rather than a system feature..?
There was a problem hiding this comment.
Two different groups have arrived at similar conclusions on a particular useful direction for the miner actor in relation to these goals: myself here and venus dev team here.
could you please summarize what does the current Filecoin protocol cant do that motivates this change instead?
(we wanna know why an FIP is proposed based on the problem and solution, more than who has the cool idea.)
| <!--The motivation is critical for FIPs that want to change the Filecoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.--> | ||
| The filecoin development community has a demonstrated interest in enabling innovation in smart contracts that interact with verifiable storage. It is the FVM's main differentiator when compared with other blockchain runtimes. Two different groups have arrived at similar conclusions on a particular useful direction for the miner actor in relation to these goals: myself [here](https://github.com/filecoin-project/FIPs/discussions/496) and venus dev team [here](https://github.com/filecoin-project/FIPs/discussions/760). The first step in this direction is to allow SPs to keep CommD on chain in the sector info. | ||
|
|
||
| Adding CommD to sector info requires a sector info migration which on its own is a costly in terms of network development and risk. Similarly it will require changes to parameters being introduced in ongoing [direct data onboarding (DDO) work](https://github.com/filecoin-project/FIPs/pull/804). Doing this work at the same time as DDO (which also needs a full sector info migration) makes the upgrade risk and development cost overhead much smaller. |
There was a problem hiding this comment.
This seems like it fits in design rationale or an implementation suggestion.
| ``` | ||
|
|
||
|
|
||
| New ProveCommit and PRU messages will then parse this new bool flag and store CommD if specified. |
There was a problem hiding this comment.
Could you please use the FULL method name here? (im not the best person to call this out cuz I use acronym excessively lmao
|
|
||
|
|
||
| New ProveCommit and PRU messages will then parse this new bool flag and store CommD if specified. | ||
| If CommD is the zero data CommD then the system will always avoid storing even if KeepCommD is true. |
There was a problem hiding this comment.
peer review: have we considered reject message early that has KeepCommD = true yet is zero data commD? Im always a bit put off with the "set this flag to do a thing, but the thing wont necessarily happen even you set the right flag"
| ### Implementing CommD on chain | ||
| Since CommD is a property of an individual sector if it is onchain it belongs on the sector info. | ||
|
|
||
| Specifying inclusion as part of the DDO sector activation manifest allows for user control over which specific sectors can store CommD. |
There was a problem hiding this comment.
im not sure DDO sector is a term that everyone could understand.
| <!--All FIPs must contain a section that discusses the product implications/considerations relative to the proposed change. Include information that might be important for product discussion. A discussion on how the proposed change will enable better storage-related goods and services to be developed on Filecoin. FIP submissions missing the "Product Considerations" section will be rejected. An FIP cannot proceed to status "Final" without a Product Considerations discussion deemed sufficient by the reviewers.--> | ||
| Sector infos are the datatype that dominate space used by the filecoin state and therefore blockchain syncing storage costs. Adding a potentially large field to this data type therefore has a risk of significantly increasing the data storage needed to sync the filecoin chain. To understand this risk I measured sector info stats and reported findings [here](https://github.com/filecoin-project/FIPs/discussions/795). | ||
|
|
||
| The results are encouraging. CommR, which is the same size as CommD, takes up about 47% of all of sector info space. Looking at the number of sectors that have deals vs total live sectors we see that all deal bearing sectors (living and dead) are < 14 percent of all currently live sectors. So in the worst (for space usage) case we would see a 6-7% increase in space usage of state if we retroactively added CommD on chain for all existing non-CC sectors. In practice the state impact will be lower. Only a fraction of users will opt into the new data onboarding flow adding CommD on chain and it will only apply to new deals. |
There was a problem hiding this comment.
Peer review: thanks for calling out the state size impact here. As you mentioned CommD is going to the same size as CommR. so if the data onboarded doubled, tripled in the next couple months, how would that impact filecoin state and snapshot sizes?
|
@ZenGround0 is currently on extended vacation, though we expect them to return. With @jsoares in agreement, I am closing this as stale for now. Of course it can be re-opened in the future. |
Depends on direct data on boarding draft: #730
Ready for review
cc @Fatman13