2017-05-26 10:39

如何促进开发去中心化——纽约共识落实路径猜想

4.3万

共识

第0章 引言

 

纽约共识最大的亮点就是促进了开发去中心化。如何能保证这一成绩落实?

 

第1章 纽约共识并没有落实方式条款

 

纽约共识只提供了一个目标,就是要同时锁定Segwit和2Mb,然后分步激活。但如何实现这个共识,没有任何实际的指导。

这个我回起起香港共识,当时对共识的具体内容如何实现,包括时间和大概的责任划分都有条款落实。比如说了代码归Core写,矿工在什么时候生产之类的。

纽约共识则留下了太多的回旋空间,尤其是对谁来写代码这个事没有确定下来,这份共识最大的成绩就是认可了开发去中心化。相反,香港共识其实是将原本初步形成的开发去中心化的局面一次性葬送掉了,大大强化了Core的开发权力。

如果要将纽约共识对开发去中心的成果真正落实下面,那以下两个问题非常重要确定:

1.代码由谁来写?

2.代码实现是以一个独立的客户端来发布,然后全网各大节点部署这一客户端才能完成升级。还是各自开发组分别开发出相兼容的版本,然后全网依然维持多个版本的客户端的前提下实现协议升级到Segwit2Mb。

如果开发去中心更加成功,需要的答案是:
1.代码由现成的各个开发组各自独立完成。

2.各自开发组独立开发出相兼容的版本,或者哪怕是有些开发组偷懒,抄别人的代码也行,但至少要抄和测试。全网在保持多客户端的前提下完成协议升级。

 

为了促成上述答案,我今天给Classic和BU两个开发组的核心开发者联系,询问他们对纽约共识的态度。

我给Classic的开发者Tom Zander发了邮件,他回复我说:

I have not seen the consensus yet, so I don’t know what was agreed.

(我还没看纽约共识呢,我哪知道该不该同意啊。)

I am still worried about SegWit, yes.

(我依然对Segwit持担心态度)

(注:我和Tom Zander一样,依然对Segwit很担心。为什么那么多人喜欢它,我仰望星空,不知所云。)

BU开发者Andrew Stone还没有回复我,BU开发者@sickpig在Slack里也没有回复我的问题。至少我确认@sickpig是看到了我问题,因为他和我聊了几句。

目前看来,至少Classic和BU两个开发组还没有启动对Segwit2Mb的讨论。

另外Core开发者的核心人员,已经全面否定了Segwit2Mb这个提议。

而参与纽约共识讨论并签名的开发者有:

RSK最主要的开发者Sergio(Segwit2Mb这个提议就是他在3月份提出来的)

Gavin Andresen(他是地位仅次于中本聪的开发者,但在2016年被坏人害的丢掉了开发权力)

Purse(这是Bcoin客户端的开发组)

目前社区成熟的开发组有以下几个:
Bitcoin Core

Bitcoin Classic

Bitcoin XT

Bitcoin Unlimited

Bcoin

而目前明确支持Segwit2Mb提案的只有Bcoin,另外有开发能力的两个个人开发者Sergio和Gavin Andresen。

看起来事实刚刚起步。

纽约共识的讨论者主要是企业,需要更多的开发者加入进来。

 

第2章 怎么办?

 

目前最好的办法就是各大企业去联系自己支持的开发者,咨询意见,协商开发。

如果什么都不做,其实是挺尴尬的。

更多的开发组参与进来,最大的好处在于代码的质量有充分的保证。因为所有的成熟的开发者至少需要读代码、编写代码、抄写其他开发组的代码、测试、各个开发组协同测试。

经过这样的过程,代码质量应该是能达到的最高的了,尤其是针对Segwit这样的对协议的巨大改动量,是非常有必要的。

或许这是所有开发组从敌对走向相互独立却共同合作的一次机会,这样的机会或者能实现远比Segwti更好的解决交易延展性的方案。

 

第3章 结束语

 

欲知后事如何,敬请关注。

 

本文链接:https://www.8btc.com/article/128853
转载请注明文章出处

评论(3)
登录 账号发表你的看法,还没有账号?立即免费 注册
merry 2017-07-11
非常感谢 https://blockmeta.com/btc-tx/55d37fc1c07b8d8ea3a406d1e10860c326af20dc3e9f13e72a2aa3311951c597 赞助0.00339524 BTC
reswz 2017-06-01
具有讽刺意味的是,比特币现在面临的前所未有的危机,这恐怕也是中本聪未曾料到的。
动说科技-专业的互联网金融服务商 2017-05-26
让更多的开发组参与进来,最大的好处在于代码的质量有充分的保证。因为所有的成熟的开发者至少需要读代码、编写代码、抄写其他开发组的代码、测试、各个开发组协同测试。经过这样的过程,代码质量应该是能达到的最高的了,尤其是针对Segwit这样的对协议的巨大改动量,是非常有必要的。或许这是所有开发组从敌对走向相互独立却共同合作的一次机会,这样的机会或者能实现远比Segwti更好的解决交易延展性的方案。
下载
分享
收藏
阅读
评论
3
点赞
上一篇
下一篇