It has come to my attention that storage clients wish to obtain the CommD and CommR associated with the sector into which the piece referenced in their storage deal has been sealed.


  • administrators

    It has come to my attention that storage clients wish to obtain the CommD and CommR associated with the sector into which the piece referenced in their storage deal has been sealed. The client can already use the query-deal command to obtain the CID of the commitSector message corresponding to that sector - but message wait doesn't show individual commitSector arguments - it just shows some string encoding of the concatenated arguments' bytes.
    I propose to augment the ProofInfo struct with CommR and CommD such that the storage client can query for their deal and, when available, see the replica and data commitments in the query-storage-deal command. Alternatively, the query-storage-deal code could get deal state from the miner and use the CommitmentMessage CID to look up CommR and CommD (on chain) - but this seems like more work than is really necessary.


Log in to reply
 

转让域名

This domain for sale!

Email:filapp@protonmail.com

Twitter:

https://twitter.com/RalapXStartUp

Telegram:

https://t.me/bigdog403
  • X

    It shouldn't be a significant centralization risk. The costs of buying your own GPUs or starting a new outsourced proving service will be pretty low. Even if many people decide to use third-party provers, there should be a competitive and well-distributed market.

    阅读更多
  • X

    We're working really hard to reduce sealing and proving costs. We really want to support smaller miners, but not at the cost of security. It's always possible to make things faster and cheaper through later optimizations, but it's hard to make things more secure.

    阅读更多
  • X

    Why here! We will make this customizable, right now in lotus its set to some pretty big value. We might even make a special mode for 'filler storage', storage youre adding just for power that doesnt have any real deals associated with it.

    阅读更多
  • X

    Details around faults and recovery can be found in the spec (https://github.com/filecoin-project/specs/). The protocol will accommodate both realistic operational needs for good miners and service providers, while maintaining the security of the protocol and Quality of Service for Clients' data. Having a data storage service offline is not good for Clients, and are not good for the service. At the same time, temporary power failures happen, and the protocol needs to accommodate them to some extent. As we get closer to mainnet, we will set cryptoecon parameters and policies, and we will explain them clearly for everyone.

    阅读更多

Looks like your connection to Filecoin中文网 was lost, please wait while we try to reconnect.