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

Add a rebuild_tree_c tool for restoring comm_c if needed #1545

Open
cryptonemo opened this issue Nov 30, 2021 · 5 comments
Open

Add a rebuild_tree_c tool for restoring comm_c if needed #1545

cryptonemo opened this issue Nov 30, 2021 · 5 comments
Labels
enhancement New feature or request

Comments

@cryptonemo
Copy link
Collaborator

Description

Consider adding a standalone tool to rebuild tree_c from a sealed sector (by extracting the necessary layers and then re-building the tree).

This is related to #1542, as there is currently no standalone tool to restore the cached comm_c value if lost.

@porcuquine
Copy link
Collaborator

Where will you get these layers from if the sector is already sealed? Unless all of the layer data was saved, you would have to reseal. Both of those options seem prohibitive when compared with just retaining the 32-byte comm_c. I think that's the point: comm_c is truly 'persistent' auxiliary data and must be retained — because it cannot be cheaply recreated once replication is complete.

@cryptonemo
Copy link
Collaborator Author

Where will you get these layers from if the sector is already sealed?

As mentioned, by extracting the layers (i.e. "unsealing").

Unless all of the layer data was saved, you would have to reseal. Both of those options seem prohibitive when compared with just retaining the 32-byte comm_c. I think that's the point: comm_c is truly 'persistent' auxiliary data and must be retained — because it cannot be cheaply recreated once replication is complete.

I understand your point, but on the contrary, I think of avoiding the expensive computation as the strongest reason it's cached in the first place.

@porcuquine
Copy link
Collaborator

porcuquine commented Dec 1, 2021

I guess so, but in that case the replica itself is also a 'cache'. Both are required for PoSt. And the security of Filecoin is predicated on both being prohibitively expensive as an on-demand prerequisite to PoSt.

If the replica is also a cache, sure… but I think that stretches meaning. In reality, comm_c should be thought of as a part of the replica — apart from the fact that it's not required for retrieval.

@porcuquine
Copy link
Collaborator

As mentioned, by extracting the layers (i.e. "unsealing").

It's a minor point, but I wouldn't think in terms of 'extracting' layers. The layers don't require the replica to be generated: just the seed information. So it's more like 'regenerating' than extracting. (I mention this just for your mental model.)

@cryptonemo
Copy link
Collaborator Author

Possibly related (just heard of this project): https://github.com/froghub-io/filecoin-sealer-recover

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants