您怎么在Filecoin的去中心化存储网络上避免信息遗失的发生?

  • Filecoin专为高冗余,高可用性和高地理复制的存储而设计。没有人能够应付数据丢失的所有情况,但我们可以通过鼓励高度复制,主动修复损坏以及使矿工失败成本高昂来大幅提高成功的可能性。

    Filecoin以冗余方式将数据存储在多个存储矿工上。如果其中一个矿工丢失了文件,他们就会失去其抵押品(作为未能履行交易的支付费用),并且一名新矿工会被自动雇佣来存储该文件的另一个副本。通过这种方式,Filecoin网络有望自我修复,并随着时间的推移修复损坏。这在某些方面与今天的专业云存储提供商的工作方式相似,但多了一个可以在多个存储提供商之间的修复功能。

    在Filecoin网络上,客户可以调整其数据复制的次数,也称为复制因子(或擦除编码),以更高价格来实现更高级别的数据冗余和安全性。复制默认值将被仔细选择以提升安全存储能力和降低数据丢失的风险。客户可以调整这些默认值,以不同的成本实现更高(或更低)的冗余和安全级别。

    此外,我们预计声誉系统的产生。我们希望客户节点能够运行软件来了解存储矿工过去工作表现并有望雇佣到更可靠的矿工。

Log in to reply
 

Email:filapp@protonmail.com

Twitter:

https://twitter.com/RalapXStartUp

Telegram:

https://t.me/bigdog403

全球Filecoin中文爱好者网站

  • X

    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.

    阅读更多
  • X

    Hmmmm. These are just my thoughts off the cuff:

    For straight-ahead performance that's not specifically concerned with the issue of loading the data (from wherever), then work on smaller (1GiB) sectors is okay. When considering optimization for space so that large sectors can be replicated, 128GB for >1GiB sectors is obviously problematic from a normal replication perspective. However, if we consider the attacker who wants to replicate fast at any cost, then maybe it's okay.
    Based on this, we could probably focus on smaller sectors as a reasonable representation of the problem. This has the unfortunate consequence that the work is less applicable to the related problem of speeding replication even when memory must be conserved to some extent.
    I guess as a single datum to help calibrate our understanding of how R2 scales, it would be worth knowing exactly how much RAM is required for both 1GiB and (I guess) 2GiB. If the latter really fails with 128GB RAM, how much does it require not to? If the work you're already doing makes it easy to get this information, it might help us reason through this. I don't think you should spend much time or go out of your way to perform this investigation though, otherwise.
    Others may feel differently about any of this.

    阅读更多
  • X

    @xiedapao
    If there does exist such a thing, I cannot find it.

    zenground0 [7 hours ago]
    I don't believe there is

    zenground0 [7 hours ago]
    tho maybe phritz has some "refactor the vm" issues that are relevant

    laser [7 hours ago]
    I assert to you that we must create an InitActor in order for CreateStorageMiner conform to the specification.

    Why [7 hours ago]
    I’ll take things I don’t disagree with for $400 Alex

    zenground0 [7 hours ago]
    Agreement all around. However this is one of those changes that is pretty orthogonal to getting the storage protocol to work and something we can already do. We need to track it but I see it as a secondary priority to (for example) getting faults or arbitrating deals working.

    anorth [3 hours ago]
    Thanks @zenground0, I concur. Init actor is in our high-level backlog, but I'm not surprised there's no issue yet. Is it reasonable to draw our boundary there for now?

    阅读更多
  • X

    Does there already exist a story which addresses the need to create an InitActor?

    阅读更多

Looks like your connection to Filecoin.cn中国爱好者社区 was lost, please wait while we try to reconnect.