Filecoin如何挖矿

  • 本指南概述了挖矿原理,以及如何在Filecoin网络挖矿。

    什么是采矿?

    在大多数区块链协议中,“矿工”是网络上的参与者,他们做必要的工作来保持区块链的有效性和安全性。为了提供这些服务,矿工得到本机加密货币的补偿。“矿工”一词的出现,是为了将确保区块链的工作与为扩大黄金供应而消耗资源的黄金矿商的工作进行比较。

    Filecoin网络将有多种类型的矿工:
    • 存储矿工
    • 检索矿工
    • 修复矿工
    在当前,我们主要关注存储矿工。存储矿工出售存储容量以换取filecoin。

    开始挖矿

    首先在Filecoin节点上运行Go-filecoin进程,默认情况下,Filecoin节点不会自动建立挖矿,您可以先创建一个矿工。

    1.建立一个矿工,承诺10个扇区(目前每个256 MIB)的储存和100 FIL作为抵押品,信息gas价格为0 FIL/单位,并限制为1000个gas上限。成功后,它返回新创建的矿工地址。
    注意:此步骤可能需要大约一分钟的时间处理,但如果时间过长,请再次检查。gas价格和gas上限。

    go-filecoin miner create 10 100 --price=0 --limit=1000 --peerid `go-filecoin id | jq -r '.ID'`   # this may take a minute
    

    一旦创建了矿工,我们就可以运行以下操作来开始挖掘:

    go-filecoin mining start
    

    恭喜,你们现在正在挖掘FIL代币!现在,您正在挖掘包含网络上的块。

    探索已经挖出来的块
    您可以使用Filecoin块资源管理器,或者通过命令行来探索。例如,让我们获得blockID区块链的第一个区块,我们称他为创世块。

    1.显示创世块并复制块ID(可能有多个):

    go-filecoin chain head # returns JSON including the <blockID> of the chain head
    

    2.然后观察他的目录

    go-filecoin show block <blockID>
    

    许多命令还支持--enc=json机器可读输出选项。

    如何创建存储申请
    在Filecoin存储市场上,客户提出一个文件存储的需求,矿工们接受了需求订单,并向他们提供了一些关于其可用存储空间的详细信息。发起存储申请需要以下几点:

    1. 您的矿工地址(在本教程前面创建)启动挖矿时创建)
    2. 矿工所有者地址(启动守护进程时自动创建)
    3. 你愿意出售这么多存储的价格(以FIL/字节/块为单位)
    4. 此要价有效的块数。
    5. 每一个天然气gas消耗单位所支付的价格,以挖掘这条信息(以FIL计价)
    6. 此消息要消耗的最大gas单位数。
      举例说明:
      1.获取矿工地址,并将其导出到一个变量中:
    export MINER_ADDR=`go-filecoin config mining.minerAddress | tr -d \"`
    

    2.获取矿工所有者地址,并将其导出到一个变量中:

    export MINER_OWNER_ADDR=`go-filecoin miner owner $MINER_ADDR`
    

    添加一个需求订单,其价格为0.000000001 FIL/字节/块,有效期为2880个区块,消息gas价格为0 FIL/单位,限制为1000个gas单位:

    go-filecoin miner set-price --from=$MINER_OWNER_ADDR --miner=$MINER_ADDR --price=0 --limit=1000 0.000000001 2880 # output: CID of the ask
    

    4.一旦您下了订单,等待您的请求的块被处理(大约30秒),然后检查client list-asks确认您的请求已被添加(请查找您的$miner_addr):

    go-filecoin client list-asks --enc=json | jq 
    

    接受交易并得到报酬
    客户向储量充足、价格低于其支付意愿的矿商提出储存协议。
    关于截至2018年12月目前执行情况的几个说明:
    • 目前,矿商以足够的资金接受客户向他们提出的所有交易。付款确认是自动完成的,所以你不需要采取任何行动来接受交易。
    • 交易付款和支付渠道被已经完成。因此,在整个交易期内,矿商都会定期通过付款渠道贷记资金。
    停止开采
    如果在任何时候想停止开采,都可以停止:

    go-filecoin mining stop
    

    还可以删除与Filecoin节点实例关联的所有数据:

    rm -rf ~/.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.