区块链共识折腾十年，最扎心的现状是多数人还在拿旧方案硬撑

导读： 从事了长达五年的链上基础设施相关领域工作, 所以对于区块链共识这一点, 我的感受只有一个方面, 那就是从学术论文到真正能够运行起来, 中间所存在的差距比大多数人都想象的要更加宽阔...

从事了长达五年的链上基础设施相关领域工作, 所以对于区块链共识这一点, 我的感受只有一个方面, 那就是从学术论文到真正能够运行起来, 中间所存在的差距比大多数人都想象的要更加宽阔, 并且有绝大部分的团队甚至都没有搞清楚这个鸿沟的位置在哪里。

区块链共识卡在哪

我见过太多团队, 他们在PPT上写着自研共识协议这几个字, 实际上运行的程序只是对PBFT这个名字进行了一点修改。真正导致项目停滞不前的因素并不是那个算法本身, 而是工程技术方面对于状态同步以及发生错误时候如何恢复运转这两个方面的能力。

这种让人觉得不太光彩的繁琐工作没有几个人情愿去动手去做, 但是如果没有把这些方面给做好, 那么区块链上面数据的保持全部一致的目标就会变成完全没有意义的空谈。

在跨链这种场景下面, 共识机制究竟该怎么实现相互连接和配合, 截至目前为止, 业内并没有一个所有人都认同的标准答案。

因为每个链都按自己的方式去设计规则, 所谓的桥接层只能依靠信任假设硬撑来维持运转。一旦发生过一次事故, 就要损失掉大量的用户群体, 而进行修复和整改的过程, 往往需要耗费两个月的时间或者更长。

区块链共识怎么选

我的标准其实挺简单的, 说白了就是看TPS需求、出块时间和安全假设这三个数字能不能对得上, 只要对不上，那这个项目我就直接不考虑了。你看现在不少项目, 一出场就嚷嚷着什么万级的TPS, 非要把容错窗口压缩到连最基本的可用性都保不住, 这就导致安全假设这一层直接崩塌。

还存在一个经常被大家掉以轻心的要素, 那就是藏在共识层下面的那些经济利益上的互相拉扯和算计, 这才是真正能让项目长期死亡的根本原因。如果激励的机制设计得根本就不合理, 那么哪怕你的算法写得再漂亮、再讲究逻辑美感, 也根本支撑不到两个季度这么短的时间就会出问题。

这时候, 运行的节点会想办法跑路离开系统, 负责验证工作的角色也会纷纷撤资退出, 从而导致整个用来维持运转的经济模型一下子全都破产倒塌。

现在的情况是, 各类论文的数量是最充足的, 反而是那种已经连续运行满三年且没有发生过严重事故的实际案例是最缺乏的。