谈谈虫洞协议

虚拟机 2018-08-29

去中心化系统在基础架构上的升级迭代是很困难的,一个小小的改动往往也需要一个硬分叉来完成。在没有一个EVM以及大的状态树的情况下,为了保持BCH本身的中心化同时又能支持合约,omni协议就只能利用现有数据结构中的op-return字段做文章,尽管在BTC主网上有了USDT的实现,但它离合约还很远。


首先,Op-return依然是被包含在交易里的,也就是说一段合约的执行需要一笔实实在在的交易来承载,由于每一笔交易都需要签名,一旦改了字段签名就失效,所以正常的BCH交易里是无法加载外部信息进op-return字段。这样导致会出现大量的新增BCH交易作为载体,这些交易本身可能是没有意义的,网络压力会很大,并且被打包除了支付官方燃料WHC外还需要支付BCH。  


其次,没有EVM的存在,纯文本的账本解释压力是很大的,错了也需要被解释。 一个op-return字段只要不为空,就必须每次都要被外挂系统解释,即便它是不合法的。 如果在外部加一个跳过的逻辑,则又属于一种中心化的干预。


平常写错了代码可以不执行,退回来重做,而op-return的任何输入都是默认合法的,一旦开始支持大量的token,状况非常堪忧。


根据虫洞的发展计划,它的第一步是将omni移植过来,第二阶段要做个去中心化协议,类似0x,第三阶段是支持ERC721这样的非同质化代币需求。而第四阶段是要引用plasma这样添加链外的结算机制。


但在我看来这个路径的设计是很奇怪的。如果顺着我前面的分析来推演应该是这样的:主链能支持的也就是利用一个字段去拓展出一个账本,还最好不要制造大量的交易,所以虫洞一旦要计划支撑dapp的第一天就应该有一个layer 2的体系来解释执行一定量合约,最后创建一笔BCH上的交易来打包提交。WHC的计量单位应该是gas,而这个gas可以通过对网络资源的评估计算出每一个区块所包含的合理的合约执行量(数量趋于稳定)。


正确的顺序应该是: 1. 移植omni。 2. 在一笔交易中实现BCH和token之间的去中心化结算。(这里有个坑,由于eth不是erc20标准的代币,0x这样的协议还需要一个eth代币来辅助,bch也是如此。)3. 建立一个独立的扩展层负责打包WHC合约再集中提交。 4. 等别的新技术起来了,追上去。


我记得我在给火币公链提建议的时候,我开头第一段就是写其战略定位,也就是动机是什么,为什么要做这个,然后再去订技术和运营上的目标。 BCH网络上支持合约的目的是什么?  BCH本身的宿命又是什么? 比特币的白皮书讲述的是一个点对点的支付系统,而非一个支持众多分布式应用的超级大账本加操作系统。 虫洞的历史使命不是要干死以太坊,战翻eos。 支付宝也不是炒作系统,支付宝是银行。 

    本站仅按申请收录文章,版权归原作者所有
    如若侵权,请联系本站删除
    觉得不错,分享给更多人看到

    虚拟机 微信二维码

    虚拟机 微信二维码

    虚拟机 最新文章

    8%的股神  2018-10-16

    交易的价值  2018-09-13

    机会在哪里  2018-09-12

    谈谈虫洞协议  2018-08-29

    Ruff 回购计划  2018-06-14

    躺赢  2018-05-15

    大人物的失败  2018-05-10

    小人物的成功  2018-05-09