<progress id="pthrx"><span id="pthrx"><ruby id="pthrx"></ruby></span></progress>

<dl id="pthrx"></dl><dl id="pthrx"></dl><em id="pthrx"></em>

                        专注区块链信息及金融服务

                        区块奖励减半之后,BCH和BTC谁更吸引矿工?

                        比特币之家 ·

                        03月05日

                        热度: 16835

                        自比特币诞生以来,矿工就一直是比特币生态中最重要的一环。

                        自比特币诞生以来,矿工就一直是比特币生态中最重要的一环,历史上第一个矿工就是比特币设计师中本聪。矿工投入算力打包区块、处理交易信息,不仅完善了区块链生态的完整功能性,强大的算力更是形成了比特币的护城河,抵御算力攻击。如果没有算力来保护区块链平稳运行,可以说比特币的框架体系早就已经被击垮,例如BTG,因算力过少被成功51%算力攻击,在这之后BTG基本处于停盘的状态。所以说比特币能够平稳运行10年,矿工们功不可没。所以,在POW机制下的币种们,都希望能够吸引足够多的算力来保护区块平稳运行。

                        矿工们?#19981;?#21306;块拥堵吗?

                        矿工的收益来源是?#20013;?#36153;+区块奖励,在比特币早期交易量极度匮乏的时期,也是比特币最高区块奖励的时期,早期的矿工等于是每个区块50比特币+寥寥无几的?#20013;?#36153;,可以说早期矿工根本不靠交易费吃饭。随着比特币逐渐发展成熟,它从早期的单个区块几?#24335;?#26131;发展到现在——每个区块都被塞满了交易,网络拥堵现象也成了常态,交易量提高这自然就生成了更多的?#20013;?#36153;。而当平均区块容量达到上限的95%,内存池开始膨?#20572;?#29992;户开始不断提高?#20013;?#36153;,希望能在不经历延迟的前提下尽快让矿工把自己的交易写入下一区块,最终?#20013;?#36153;开始飞涨。

                        在2016年以前,矿工们每天收入的?#20013;?#36153;大概是50~60比特币,在这之后矿工每天的交易费收入大幅增长至250个比特币,比特币的交易费用正在以相当大的幅度上涨。

                        对于短期矿工来说,自然是希望区块上限越小越好,限制交易空间,最好让平均区块容量永远大于95%,这样?#20013;?#36153;竞争就会越来越激烈。短期来看,最佳的区块容量就是“在保证容量较小的同时出现拥堵现象?#20445;欢?#38271;期矿工则希望尽可能的提升交易吞吐能力,使之交易量大幅提升,在合理范围内赚取?#20013;?#36153;。

                        BCH路线——交易量就是矿工之命

                        2017年8月1日,由另外一批大区块支?#32456;?#21644;开发者共同推动的另一个版本的比特币正式推出,被命名为比特币现金(BCH)。BCH派认为比特币应该是拥有更大区块上限以处理更多交易,提升交易吞吐量,同时应该保持?#22270;?#30340;平均?#20013;?#36153;,最大程度的满足用户交易需求。所以最初的BCH被设定为8MB区块上限,并放弃了隔离见证。运行至今以平稳发展1年半,经历了两次硬分叉升级逐步调整区块上限和交易性能,BCH已经证明?#36865;?#36807;提升区块上限来解决交易拥堵的?#34892;?#24615;。

                        比特币现金(BCH)的路线其实就是最初白皮书规划的发展路线,根据硬件和需求逐步提升区块上限,尽可能的不让主链处于拥堵状态,最大化提升用户体验。

                        大区块可以解决交易拥堵的问题,虽然降低单?#24335;?#26131;?#20013;?#36153;,但如果交易量提升,那么?#35789;?#26080;法达到平均区块容量95%时膨胀的?#20013;?#36153;,但提升的交易量的整体收益是寥寥数笔的高价?#20013;?#36153;所不能比的。比如现在BCH已经达到32MB,而BTC依然是1MB,BTC理论上每秒处理7?#24335;?#26131;,而BCH理论上最高可以处理224?#24335;?#26131;,假设BTC满负载出块,BCH只有50%区块容量,那么仅仅是7笔高价?#20013;?#36153;能与112笔平价?#20013;?#36153;相比吗?

                        而矿工目前对大区块的担忧是对硬件水平的担忧,提升区块上限自?#27426;?#30719;工在处理超大区块时的挖矿设备提出了更高的要求,这也是短视矿工反对大区块的最大原因;同时大区块也提升了孤块率,浪费了矿工的时间和资源,且对全节点的存储空间提出了更高的要求。根据BCH这一年来的升级方向来看来看,在目前交易量没有爆发?#20445;?#24320;发者正在试图稳定区块上限,当前32MB区块上限已经稳定?#20013;?#20102;一年以上的时间,且短期内似乎开发组都没有进一步提升区块上限的计划,根据摩尔定律来看,未来再次提升区块上限?#24065;?#24517;然能够跟上硬件水平的发展。而针对孤块率的问题,BCH社区也提出了使用小?#35759;?#21306;块(弱区块weak blocks)创建子链(subchains)连接匹配完整?#35759;?#21306;块(强区块)方案,?#34892;?#38477;低孤块风险。

                        随着区块奖励的不断减半,2020年将会降低至每区块6.25BTC,未来矿工主要的收入依旧是交易费,未来BCH面临亿万级的市场的同?#20445;?#30719;工将井喷式增长,可以预期未来BCH的矿工和算力大概率会一?#25918;?#21319;。

                        BTC路线——矿工只是我的主链服务员

                        BTC则走了一条截然不同的路线,BTC选择继续维持1MB的区块上限,而面对交易需求他们认为二层网络才是解决问题之道。就在最近,被他们寄予厚望的闪电网络最近突破700BTC交易大关,初步推广取得了一定的进展,那么闪电网络对矿工友好吗?

                        闪电网络是一种在主链之外的交易方式,交易双方将币锁定在自己的闪电节点中,在开启闪电通道后,双方可以在通道里无限次的交易,只有在关?#32960;?#36947;时才在主链进行一次结算。这就形成了侧链交易量极大,而主链成为交易量极低的结算层,无论进行了多少次交易,只有结算时矿工才有一次出场机会,?#20013;?#36153;收益大大降低。闪电网络打破了比特币生态一贯以来的格局,矿工在BTC世界里正在逐渐的边缘化,随着区块奖励的逐步降?#20572;?#30719;工们越来越不愿意在BTC挖矿,未来BTC的矿工和算力大概率会一路走低。

                        或许有人认为闪电网络的中心节点就是新时代的矿工,确实这些中心节点担任了交易中转的任务,也能够借此收取?#20013;?#36153;。但闪电网络的经济模型一直存在较大的争议,中介节点的必然是垄断性质的,只有一个超级节点能够胜出,也就是这个所谓的新时代矿工只是一个个人或公司,根本无法形成一?#20013;幸担?#22240;为闪电网络是一种赢家通吃的商业行为,强者越强,弱者消亡,这样的局面从经济学来讲是最?#34892;?#29575;的。

                        最后还有BTC还面临一场算力危机,BTC对矿工的不友好可能会驱逐一大批矿工,最终会导致主链的算力降?#20572;?#22312;POW机制下,这是BTC亟需解决的问题。而被驱逐的矿工或许未来终究都会转移至BCH上。

                        声明:本文为入驻“火星号”作者作品,不代表火星财经官方立场。转载请注明出处、作者和本文链接
                        提示?#21644;蹲视?#39118;险,入?#34892;?#35880;慎。本资讯不作为投资理财建议。

                        推广
                        相关新闻
                        福建11选5前一推荐

                        <progress id="pthrx"><span id="pthrx"><ruby id="pthrx"></ruby></span></progress>

                        <dl id="pthrx"></dl><dl id="pthrx"></dl><em id="pthrx"></em>

                                              <progress id="pthrx"><span id="pthrx"><ruby id="pthrx"></ruby></span></progress>

                                              <dl id="pthrx"></dl><dl id="pthrx"></dl><em id="pthrx"></em>