想搞明白区块链架构怎么设计 还得看它能落地哪些场景

我做了这么多年分布式系统, 然后再转过来做区块链架构设计工作, 我觉得自己最大的感受是这玩意根本没有那么神秘, 把那些广告宣传里用的漂亮话全都扒掉以后你会发现, 区块链架构在本质层面上其实就是共识层、存储层和网络层这三个部分怎么进行组合搭配的问题, 同时还要把这些技术跟你们自己的实际业务需求对应起来, 它不是那种飘在没有地上的空中楼阁, 而是一个实实在在的工程项目问题。

区块链架构怎么设计

在最核心的部分进行选择时, 最需要关注的问题是共识机制。对于公链这种类型的方式, 往往是要去向PoS或者DPoS去靠拢。而对于联盟链来说, 更多是用PBFT或者Raft来作为技术手段。

至于私有链的话，甚至是可以直接拿来BFT这个方案。一旦在选择的时候出了错误, 导致后续在性能方面出现大问题、安全方面出现漏洞、以及节点治理方面出现困难, 那么整个局面就需要进行返工处理, 而且这样带来的成本是非常高的。

我在带领团队工作的时候, 发现了一个普遍存在的问题, 很多团队在刚开始的时候, 就把大量的智能合约和众多功能模块强行堆砌在一起, 却没有确保底层的账本能够同步运行, 节点容错机制也没有经过有效的验证。

因此, 必须首先把基础工作做扎实, 需要重点保障数据的一致性, 还要确保节点的可使用性, 做好这两件关键的事情, 这比起设计那些看起来华丽的功能来说, 会更加有效且实用。

区块链的架构, 是可以来用于完成一些具体的事项的。

像供应链溯源、电子存证以及跨境结算, 这些具体的应用场景, 目前都在实际运行之中。然而, 关键的难点, 从来都不是技术层面是否可以把数据上链。真正的矛盾点在于, 如何彻底打通存在于区块链之外的线下数据, 与位于链上的数据之间的连接通道。

还需要确定数据进行上链操作的具体时间频率, 以及把信息切分成最小单元时的精细程度。当接入的数据总量大幅上升时, 系统整体的数据处理吞吐量, 能否实现同步匹配, 才是技术架构设计中必须解决的难题。

千万不要被那些花哨的概念给带偏了, 真正能够落地的项目, 其中百分之八十的复杂度都在链下环境里, 而区块链上仅仅承担着信任锚点这个作用。在进行架构设计的时候, 一定要把这条清晰的界限划清楚, 这样的话, 项目才不会偏离方向, 预算也不会莫名其妙地被黑洞消费掉。

目前还没有那一种可以放到所有地方都像标准答案一样的解决方法, 只有一套能够和你的业务节奏正好相配合的那一种东西。要想明白这件事情再动手去做, 这个办法比任何其他的办法都要快。