第0章 引言
作者:闪电HSL
最近几天BCH社区异常激励地讨论着在5月19日的一次在香港开的关于募集BCH开发资金主题会议的事,本文主要想写明白这个主题会议上到底发生了什么,尤其是后面几天社区的各种误读,各位都激动的很,以及我本人对这个会议提案的看法。
第1章 香港BCH开发资金募资方案主题会议
5月19日在香港BCH的爱好者,会议有矿池、节点开发者、钱包开发、爱好者等,规模并不大,我没数人数,估计20人左右吧。
会议最重要的事是BCH节点开发者姜家志(哥白尼项目的负责人)在会议上做了一个主题演讲,演讲的内容是阐述一个针对BCH开发的专项专款募资的方案。
演讲内容包括下面几大块:
1BCH社区的开发现状,竞争者(ETH、Dash、波场等)的开发现状。
2为什么BCH社区应该加大开发的资金投入。
3一个针对BCH开发的专项专款募资方案。
我重点表述第3点。
募资的起点是:有开发者提出资金需求和募资理由,具体方式是使用链上一笔多重签名的交易方式向BCH全网发布,将需求和理由以文字的方式写进OP_Return字段,所有人都可以查阅这些内容,是全网公开的;多重签名的私钥持有者是所有矿池,有多少矿池就有多少把私钥,具体如何构造我们不用管。
募资的审核过程是:矿池所有者看到这笔交易后会对OP_Return里的内容,并评估是否愿意捐赠。如果愿意捐赠,就使用签名的方式投票同意捐赠,捐赠的比例是按矿池所有者的算力占全网比例。多重签名交易广播成功后进入算力投票。
矿池使用区块对募资进行投票,一个块一票,如果全网超过75%的算力都投票同意捐赠,那这个募资需求通过了审核,进入打款阶段。块奖励转入募资的管理地址。
比如有一个开发申请100BCH,有75%算力审核通过后,开始打款。一个区块有12.5BCH的区块奖励,募资方案里提方按每个区块里捐赠0.1BCH,持续1000个区块。在开始打款的区块往后延续1000个区块,挖到区块的矿池就会打款,没挖到当然不打款。
打款也可以辅助阶段性,比如开发者做到什么里程碑才转下一个阶段的款,以便建立监督缺席。
以上就是大概的过程,细节可能有不一样。下面要分析具体的打款实施过程,这是争议最大的地方。
如果75%的算力投票同意捐赠,但其余25%算力不同意,怎么办?
家志的提议是使用一定的方式来“逼迫”不同意的少数服从捐赠,请注意,家志在表达的过程,多次强调这只是一个潜在的可选择的方案,是一个抛砖引玉的提议,这是他目前能想到的最可行性策略,希望引出大家更多的更好的方案。
具体的办法是,因为75%算力同意捐赠,这是多数优势算力,按照少数服从多数的原则,如果少数算力不执行捐赠,首先捐赠会持续,多数算力依然会执行捐赠,会持续在挖到的区块里转出认捐的份额,直到捐赠满为止。但争议的地方在这里,多数算力将会对这些没有捐赠的区块进行孤立。因为是多数算力采取统一行动,所以孤立大概率会成功,这时候少数算力就会损失掉挖出的块。在这种博弈下,少数算力是不会坐视被孤立,会出三种情况,第一是服从捐赠;第二是将算力离开BCH前往BTC挖矿;第三是拉更多的算力过来,反过来压倒捐助者,这时捐助可能就无法执行了。
所以在实际执行过程中,实际发生的情况大概率来说是不会出现真正有区块被孤立,博弈会出现稳定的情况。这是一个介于强制和纯自愿之间的中间地带的机制。
为了实现这个多数算力对少数不认捐的算力进行孤立的行为,矿池会使用特定的机制来达成统一意见,具体的是一个代理机制,代理这个词不好理解,我们可以将这个词理解为一个软件,软件能识别矿池之间发现哪一个区块没有认捐,并且软件可以指挥挖矿软件自动执行孤立不认捐的区块。
第2章 社区最大的两个误解
这几天社区在大讨论这个募资方案,有两个误解最好澄清下。
第一个必须要澄清的是:这次募资方案提议并不是要成立一个长期的收款基金会,不是长期的针对BCH每一个区块要抽固定比例的分成到特定的地址。
这次募资方案是一个专项专款,有人提出资金需求,矿工审核投票,通过则捐赠,通不过则不会出现捐赠。
这个澄清可以避免关于资金腐败的问题,没有特定的基金会用来长期管理资金的问题。可以避免讨论募资的具体使用方式,因为在捐款之前已经确定了使用方式。也可以避免讨论募资额度的问题和误会BCH挖矿被固定抽税的问题,额度都是专项讨论出来的。
第二要澄清的是“孤立不认捐”的区块的机制不是一个共识协议级更改。
社区很多人一听这个方案误认为要对BCH进行一次共识协议升级,使用一个软分叉或硬分叉来部署。没有这回事。上一章讲的“代理”软件不是要针对bitcoin abc这样的节点软件进行部署,而是在矿池挖矿软件上部署。
这个澄清可以避免展开是不是矿工独裁挟持整个社区的讨论。事实上这个募资提案并不是让矿工拥有改协议的能力,只是让矿工达成了某种合谋共事。这种“孤立不认捐”的机制只是矿工之间的事,和非矿工没有什么关系。
第3章 我认可这次募资方案会议的地方
我认可BCH的发展确实如这次会议所说的,是需要更大规模的募资推动发展的。区块链的发展已经过了极客爱好者主导的阶段了,已经步入专业化了。开发难度已经是很难了,不再是业余和少数人能搞定的事。这个背景下,要做出一个伟大的产品,是需要投入更多的资金。但具体金额需要多大,则需要更专业的评估了,我不知道。
不但是开发需要更大的投入,社区的推广,和应用层的开发也需要更多的投入。
我也认同矿工作为协议层最大的受益者主动站出来捐赠资金推动开发是合理的。BCH整个经济生态,矿工肯定不是最挣钱的,但区块奖励确实是只有矿工挖到的,矿工是底层协议最大的受益者。针对推动开发的资金,矿工有必要牵头捐赠。
但这里先补充一点,我认为除了协议开发层面,其他如推广和应用项目开发等,并不能把这个捐款的冤大头也按到矿工头上。咱们有一说一,不能看谁挣钱就咬谁一口,我主张资本主义,不主张劫富济贫。
第三我认同这个募资方案在专项专款透明度上的创举。慈善最大的敌人是腐败,腐败的最大敌人可能是透明。这次会议将募资的需求方、原由、金额、使用策略;捐赠者、捐赠金额、捐赠时间,等信息完全公开写入BCH区块链的试,完全透明、并且不可篡改,而且任何第三方都可以针对这个款项和募资项目发起公开透明化的评论,这对慈善来说是一个非常大的进步。
第4章 我认为这个募资方案存在的最大问题
我不认同这种在矿池之间部署一个“代理”来孤立掉不认捐的小算力区块的设定。这会导致下面的问题。
BCH网络是一个P2P网络,节点可分为挖矿节点和非挖矿节点。现在挖矿节点和非挖矿节点都追随简单的最长链为有效链规则,只有区块处于最长链就是有效区块,不处在最长链的区块就是无效区块。
目前网络挖矿节点和非挖矿节点对最长链最大的分歧在于孤块,如果全网在极短的时间内同时由两个独立的矿池分别在同一高度上挖出区块,就一定会出现其中一个是孤块,另一个才是有效块。这种情况下,哪个区块优先广播到更多的算力节点,获得超过51%的算力的投票,就成为了有效块,链的最新高度就会上升到这个块,而另一个块则成为孤立块。
这种孤块制度在非挖矿节点上也是可以在“秒级”时间侦查到的,所有的非挖矿节点都是和矿池节点一样,会先后收到这两个相竞争的区块,也都可以预见全网将会出现一个孤块。所以非挖矿节点可以和挖矿节点同步知道在接下来的最新高度会是哪一个区块。这种设定下,全网所有节点并不会怕孤块的出现会伤害安全性。这两句话有点难理解,我举例说明。
假设现在全网在同一高度上挖出了两个区块,我们称为A和B两个区块,其中必有一个是孤块。如果有一笔交易tx1被打包进A区块,而没有被打包进B区块。这种情况下,如果非挖矿节点1优先收到了A区块,并且将区块链高度更新到A区块,则在这个节点1来看tx1已经获得了1个确认。但非挖矿节点2优先收到了B区块,并且将区块链高度更新到B区块,则在这个节点2来看tx1还是零确认。这时候区块链处于临时分裂状态,但这种冲突可以在秒级时间内就可以消解,因为几秒时间后,节点1和节点2都会收到另一个相冲突的区块,就可以重新评估最新高度和tx1的安全性了。而这种竞争性一定会在下一个区块决出胜负。而对挖矿节点来说,也是一样的,矿池公司应该会在全球部署更多的节点来侦探这种相竞争的区块A和B,但本质上还是和非挖矿节点处于类似的地位,只是有微弱的优势。
但如果由本次募资方案中的“孤立不认捐的区块”的策略,允许矿池间存在一个联盟,可以联盟可以采取主动孤立掉联盟外的区块政策。在这样的背景设定下,非挖矿节点是无法知道这个挖矿联盟的政策的,非挖矿节点是无法识别是否存在收到的区块是否会被这个联盟孤立掉,这样的设定会让非挖矿节点收到最新区块后无法做出和矿池相同的安全性评估,非挖矿节点只有等到下一个区块时才能发现上一个区块是否被孤立。这一段句话也不好理解,我举例如下。
现在有一个矿池联盟,我们取名为捐赠者联盟,持有75%的算力;其他25%算力构成拒绝捐赠者联盟。前者挖的区块我们称为A;后者挖的矿称为B。现在全网出了一个B1块,全网所有的节点,包括非挖矿节点都会收到B块,非挖矿节点和拒绝捐赠者联盟的矿池节点都将这个B1块列为最新高度,但捐赠者联盟矿池则会拒绝B块。这时候全网处于临时分裂状态,如果下一个区块为A1块,全网都会收到这个A1块。非挖矿节点和拒绝捐赠者联盟节点才发现,我操,我可能收到一个孤块,现在的A块和10分钟前那个B块,形成了竞争关系,有一个必然是孤块。而谁胜出,还需要在下一个区块出现,如果在A1块之后,捐赠者联盟又挖了一个块A2块,则非挖矿节点和拒绝捐赠者联盟节点会将B1块抛弃,认定A2块为最新高度。但如何A1块之后,是拒绝捐赠者联盟挖出一个块B2块,非挖矿节点和拒绝捐赠联盟会将最新高度认定为B2块,这种情况下,竞争还将继续。直到A块爆出的数量多于B块。因为A块的算力更大,有75%的算力优势,会在第二个A2块大概率决出胜负。
这种联盟有权限孤立掉别人的区块的设定会让非挖矿节点和矿池节点处在不同的对最新区块高度的共识上,非挖矿节点就需要更多的确认数才能保证自己的高度是和矿池节点处在相同的共识上。
我认为这是不合理的,这会让非挖矿节点面临潜在的少确认数风险。现在1确认是极端安全的,甚至零确认都是安全的。但如果有这种孤立政策后,1确认的安全性就大大降低了,零确认基本没戏,需要3确认才能达到之前1确认的安全等级。
至于这个募资方案关于自由、权力、义务,这些的争议,我认为永远都不会有答案的,这是阿猫阿狗都有自己自圆其说的说法,讨论这些太虚无缥缈了。
第5章 我认为这个方案值得修改完善的地方
第一应该补充的是限定矿工捐赠资金的使用范围,应该限定在协议层的开发。
我的理由是矿是协议层最大的受益者,加上协议层开发也必须和矿工配合运行,也就是矿工的理念是可以影响协议开发的,那矿工在协议层的进化上就应该承担更多的义务。
但著如BCH推广,搞meetup,应用层的开发,这些就不是矿工受益最大了,这应该是交易所或其他生态节点才是最大的受益方。像这些活动资金需求,就另找出路吧。矿工也不是冤大头。让矿工的捐赠集中在协议层开发,总体出资不会变成无底洞,也就不需要想各种催捐招了。矿工也别剥夺别的经济节点生态做慈善的机会哈。
第二是去掉“孤立不认捐区块”的环节,换成纯粹的自动捐款的设定,加上透明、荣耀和社区舆论压力辅助推动更大的捐款意愿,再配合上述第一条,就够了。还要啥自行车啊。
就目前的现状来说,排名前几的大矿池都愿意捐赠,有产者多出点,换来更多的荣耀和更多的话语权。那些小矿池不捐款,不想要这种荣耀,就算了。维持一个生态的多样性也挺重要的,同时有大方的和自私的,才叫多样性嘛、就维持现状挺好的。
开发者也努力点,努力向社区解释下你要干吗,努力做出真正牛逼的事,做一个真正牛逼的人,为什么要捐赠,不要那么高冷,又不是美女。
第6章 结束语
大家不要激动,我们的目标是星辰大海,土大木。

如何让一种币更有生命力——一种BCH开发资金募集方案大讨论相关推荐

  1. [react] 在React中如何引入图片?哪种方式更好?

    [react] 在React中如何引入图片?哪种方式更好? 第一种导入: import Img from "./images/1.png" 第二种直接获取图片: <img s ...

  2. 余额宝 vs. P2P网贷,谁更有生命力?

    余额宝跟P2P网贷作为一个理财方式,要说谁更有生命力,那就必须从以下几个方面说起,一是收益性,二是风险性,三是流动性,下面从这几个方面来对比一下余额宝跟P2P网贷. 首先是收益性,作为投资理财者,第一 ...

  3. 哪种营销方法效果最差_今日头条广告投放形式分几种?头条品牌营销曝光效果哪种广告更好?...

    一.今日头条广告形式分几种? 所以,广告主们也想借助今日头条投放广告.那么,今日头条怎么投放广告?今日头条平台有三种投放广告形式,开屏广告.信息流广告.详情页广告: 1.开屏广告 该广告位可以让你的产 ...

  4. 实现线程哪种方法更好_实施数据以实现更好的用户体验设计的4种方法

    实现线程哪种方法更好 Gone are the days when design used to rely mainly on the color palettes and the creativit ...

  5. 专访中国移动钱岭:大数据更像是一种“倍增器”

    记者 | 杨丽 出品 | AI科技大本营(rgznai100) 为把握时代特征,2016 年中国移动确定并大力推动"大连接"战略,并制定了"十三五"时期做大连接 ...

  6. 独家 | 使EfficientNet更有效率的三种方法(附链接)

    作者:Dominic Masters翻译:王可汗校对:欧阳锦本文约3300字,建议阅读5分钟本文为大家介绍了提升EffcientNet效率和性能的三个策略. 在实践中有更好性能的EfficientNe ...

  7. TypeScript和JavaScript哪种语言更先进

    TypeScript和JavaScript哪种语言更先进 近两年来最火爆的技术栈毫无争议的是JavaScript,随着ES6的普及,不管是从前端的浏览器来看,还是后端的NodeJS场景,JavaScr ...

  8. 【Python自动化任务】让运维更简单的7种定时任务实现方式,总有一种适合你的场景

    想要看更加舒服的排版.更加准时的推送 关注公众号"不太灵光的程序员" 每日八点有干货推送 有粉丝留言问什么时候可以写一个关于自动化任务的文章 准备上!~ 感觉有用关注公众号 &qu ...

  9. 众多的操作系统中哪种操作系统更安全(转)

    众多的操作系统中哪种操作系统更安全(转) 在很多用户印象里,Windows系统存在着很多漏洞,容易受到尼姆达.红色代码.冲击波.震荡波等病毒的攻击.Windows不安全的证据还有,在Windows中使 ...

最新文章

  1. 软件测试:黑盒白盒与动态静态之间有必然联系吗
  2. Nature撤稿!三年前微软在量子计算上的巨大胜利终究是个错误
  3. DropDownList--下拉菜单
  4. api.dll自己的理解
  5. 基于认证的代理平台搭建配置squid-20130730
  6. 使用计算机比喻的心理学研究取向,心理学入门:6个方面的研究取向
  7. Codeforces Round #666 (Div. 2)
  8. NHibernate之旅(4):探索查询之条件查询(Criteria Query)
  9. Win10系统java环境配置
  10. 最新小白详细描述在centos7.5上安装python3并使用Nginx+virtualenv+supervisor来部署tornado项目(整理集合结合实际)系列2
  11. careercup-递归和动态规划 9.10
  12. 21天学通JAVA:如何使用现有类
  13. 2011总结与2012展望
  14. shell——按指定列排序
  15. css background背景拉伸
  16. C++中的back_inserter
  17. 计算机毕设题目设计与实现(论文+源码)_kaic
  18. 【html标签复习】
  19. 【Vue】pc和移动端网页样式适配
  20. 面向对象设计的3个基本特征和5个原则

热门文章

  1. Linux监控平台介绍、zabbix监控介绍、安装zabbix、忘记Admin密码如何做
  2. iOS中 UITableViewCell cell划线那些事 韩俊强的博客
  3. 在linux和windows下自动备份数据库
  4. JavaScript正则表达式快速判断技巧
  5. 平衡二叉树及其应用场景
  6. 链路负载均衡: 高性能和高安全的同时实现
  7. OceanBase技术直播间开播啦!蚂蚁金服技术专家手把手教你搭建OB数据库~
  8. CentOS7 NTP客户端和服务器安装和使用
  9. Java基础笔记17
  10. easyui_动态添加隐藏toolbar按钮