|
我们知道 Classic 的 75% 算力分叉在圈内引起很大的争议,有人认为太低了,它可能会带来两条链;有人认为足够高,因为较少算力的一方会妥协。
实际上,到底是分叉,还是较少算力方妥协,根本没有人知道。在事情没有真正发生之前,所有的一切都是猜测。
现在分叉规则是,最近 1000 个块中有 750 个标注 Classic ,就开始执行分叉。我的问题是一定需要掌握 75% 的算力才能分叉吗?低算力是否可以靠运气爆棚,达到分叉阈值呢?
于是,我做了下计算,老实说我的统计学学得很差。我一直等人计算,结果等了很久,没有人算,所以没办法,我只能自己动手,有错误请大家指出。
其实,这是个二项式概率分布问题。如果 Classic 掌握的算力比例为 p,那么它在最近 1000 个块中爆 750 个块的概率为:
X(750) = C(750, 1000) * P ^750 * (1-P) ^ 250
那么,它在最近 1000 个块中爆 >= 750 个块的概率是:
X = X(750) + X(751) + X (752) + ……. + X (1000)
于是,我分别对阈值 950, 900, 750, 500 做了计算,结果见下表。
这个表的意思是,如果阈值是950个块,那么掌握95%的算力,将有53.75%的成功概率,这个概率很高,基本上铁定会成功。如果掌握94%的算力,也有10.06%的概率成功,经过一段时间也肯定会成功。如果我们认为万分之一才代表万无一失。那么,算力小于 91.94% 的话,就基本不可能成功了。
同理,如果阈值是900个块,算力小于86.04% 就不可能成功了。如果阈值是750个块,算力小于69.64% 就不可能成功了。如果阈值是 500个块,算力小于44.10%就不可能成功了。
有没有发现什么呢?是的,阈值越高,运气成分越小。如果阈值是950个块,必须达到92%的算力才有可能靠运气蒙。如果阈值是750个块,只要算力70% 就可以依靠运气去蒙,哪天运气爆棚,说不定就成功逆袭了。
不要觉得运气因素不重要。大家还记得前段时间突然在 4 小时内爆 48 个块吗?有人计算说是几十年才能一遇。
以上我只列结果,不想下结论。每个人都有自己的解释,也有人根本不在乎70% 算力就分叉,所以多说也无益。
最后,我想说说,我为什么做这件事情。
做任何事情都有风险,但是我们总是可以通过一些计算,或者一些模拟去降低风险。如果你真的想推进扩容,就去做一些力所能及的事情,让大家对各种风险越来越明确。
我不得不说, Classic 是非常不负责任的。为什么?当一件事情的后果不明确的时候,如果你一定要推进它,那么你就得对这件事情的风险进行评估。
如何评估呢?其实工程上有很多手段。比如:建立一个类似的网络(如:某山寨币),呼吁大家一起建立节点,并做分叉实验,随机选择一定比例的节点拒绝更新,另外一些节点更新,看看什么情况下会分叉,什么情况下不会分叉,以及通过分析,建立一些可行的机制或者流程,把分叉风险降到最低。如果你觉得真实实验成本太高,或者不容易实现,你也可以在计算机上做仿真模拟实验,看看到底会发生什么情况。实验做完之后,发布完整的实验报告,以及各种风险的评估,包括概率和后果。这样做才是负责任的态度。
不是说有风险的事情就不能做,而是说你要尽可能对风险进行评估,并且将风险降到最低。不是简简单单一句“较少算力的一方会妥协”就完事了,然后开始没完没了的撕逼,我倒是想支持你,可惜我说服不了自己。
反过来, Core 推行的 SW 方案,已经在 test-net 上开始测试,这就是负责任的态度,无论这个测试花多长时间,无论测试过程中发现多少 bug ,都是负责的表现。因为测试时间越长,测试得越仔细,我们才越有把握。所谓代码改动太大,根本不是反对 SW 的理由。很多软件在开发的过程中都经历过推倒重写,只要新版本经历过足够仔细的测试,就没有问题。
不要再说什么扩容很急了,如果真着急,是不是早就应该去做模拟或者仿真实验了?我真的没有感觉到着急,真正着急的人不会什么测试都不做的。
至于政治上的事,我就问你,支持了 Classic 是不是就不独裁了?从加文的表现看,他会比 Core 更独裁。他独裁的时候,怎么不提花园论?他下台了,花园论就出来了,呵呵!
开发者干不了坏事的,客户端需要矿工和节点支持才能实施。如果矿工和节点拒绝支持,开发者狗屁都干不了。比特币的设计是完美的,开发者和矿工,谁也别想轻易改动网络,互相制衡。这种不能轻易被改变,才是我们用户敢拿它储值的根本。
来自:币科技
比特币感谢地址:1AHR999Dsz1J3it2XHjKJvWsMqRaTaBchm
注:本文观点仅代表作者,与比特币之家无关 |
|