在着手进行联盟链项目的实际落地工作时, 核心的环节总共可以归纳为三个主要方面, 也就是组网、共识、上链这三点。
许多相关的技术团队往往会在一个特定的难点上产生阻碍,这个难点具体指的是如何将日常业务中的数据进行有效地导入到区块链技术框架中去, 这一过程之所以让人困惑, 根本原因在于没能妥善处理好业务层面的整体模型与区块链上层具体数据结构之间的一致性匹配问题, 接下来我们就针对在实际执行层面容易出现的各种常见失误情况进行详细探讨。
联盟链组网怎么做
在组网这一个阶段里面, 人们最容易疏忽掉的问题, 就是节点权限分级这件事。并不是说每一个参与到这个项目里的有关各方, 都需要去运行一个功能完整的节点。特别是在供应链这种场景之下, 上游的那些供应商群体, 通常仅仅只需要拥有读取数据的权限就行了。
而那些占据核心地位的企业, 才需要拥有所需的写入数据的权限。
就我个人而言, 在一个对汽车零件进行溯源的项目实践经历里, 我把12个节点划分成为了三个不同的级别, 经过这样的处理之后, 使得记录在上链接里面的每秒交易处理量, 从之前开始的800这个数值提升到了后来的3200这个数值, 并且同时也让延迟时间缩短下降了百分之六十之多。
共识算法的选择, 你也别非要对PBFT死磕到底。当节点的数目处于10个以下的时候, Raft算法就已经够用了, 并且部署起来也简单。只有超过了20个节点之后, 你再考虑使用PBFT或者HotStuff这些算法吧。一旦选错了算法, 运维的成本是会翻倍的。
业务数据怎么上链
上链这一步操作的本质, 并不是把整条记录全部写上去。我们进行的一项实践做法是这样的, 在链上只存哈希指纹和关键状态字段这样的方式, 让明细数据走的是链下数据库的通道, 这种安排不但既保了可信度, 又不让链上数据变得臃肿。
还有另外一条这样的经验, 是关于合同签署类业务的, 这里面的建议是不要吧PDF文件的原文直接上链进行存储, 你应该把那个文件通过SHA-256算法生成的摘要信息存放在区块链上头, 然后把那些原文内容放在IPFS上面或者是自家的对象存储里面去, 等到需要进行签字验证的时候, 去对比那个哈希值就可以了, 这样做的结果是把存储成本直接削减到了原来费用的1/50那么一点。
所谓落地这件事情, 并不一定要搞得很复杂才行。咱们应该优先把那个最小的、可以被使用的模型给成功地跑通。等这步完成了之后, 再去进行后续的迭代工作。
转载请注明出处：imtoken，如有疑问，请联系（）。
本文地址：https://zmdyd.cn/imgfb/10534.html