区块链的设计和建设, 表面上看似乎只是纯粹的技術工作, 但真正关键的难点在于要把业务需求和技术架构匹配得恰到好处。
很多企业或者团队在进入项目的时候没有先搞清楚实际情况, 而是直接把注意力集中在挑选共识机制和选择技术框架上这么一些比较次要的技术细节问题上, 这样就容易犯错误, 开发出来的产品跟实际使用场景没有办法对应得上, 虽然投入了很多的钱, 但是项目还是没法子顺利地推进下去。
区块链设计建设难在哪
最让人感到头疼的问题, 是对于数据上链的边界如何进行的划定。到底哪些数据需要做到不可篡改, 哪些数据可以放在链下仅仅是做一个索引, 这个划分的方式,会直接去决定整一套架构所能够达到的复杂程度有多少。
非常多的团队, 在这个具体的阶段里面并没有把问题去想得十分清楚, 等到后面再去进行修改的时候, 所要付出的代价是非常极大的, 这完全等同于把所有之前的工作都推倒重新来进行。
性能表现也是一个比较大的坑。公共链的每秒交易处理数量有限。私有链与联盟链在寻求扩展方案的时候, 又关联到了节点的部署以及带宽的使用还有存储的成本等方面。很多的团队直到进入压力测试的环节才察觉到其完全无法承载并发的访问量。
区块链设计建设选什么链
在选型这件事情上, 根本不存在什么唯一的标准答案, 必须得看具体的应用场景是什么样子。对于像供应链追根溯源或者数字票据处理这些需要很强的信任基础还要多方共同协作的需求来说, 使用联盟链是比较合适的;而只有那些真正追求开放生态环境或者去中心化金融的情况, 才值得大家考虑使用公链。

一旦选错了区块链的类型, 那么后续开发和维护过程中出现的各种问题, 只能不断打补丁来应付。
团队现在拥有的技术栈情况, 也会影响到大家的决策结果。如果团队成员擅长使用Solidity语言以及熟悉以太坊生态环境的话, 就选择Besu或者Polygon这类方案。
要是大家更熟悉Java编程语言和分布式系统相关知识的话, 就应该走Hyperledger Fabric这条路线。在技术选型方面, 不要进行强行跨领域的做法。
从最终的结果来看, 区块链的设计和建设这一事情, 是没有那种一劳永逸的万能钥匙的。
我们应当把核心的业务流程先进行打通和运行, 在此基础上, 再对是否需要将其移动到链上, 以及需要移动到哪种特定的区块链网络上去, 做出决定, 这种操作路径, 比起在一开始就盲目地堆积大量的技术框架, 要更加具备实际意义和实在感。
转载请注明出处:imtoken,如有疑问,请联系()。
本文地址:https://m.zmdyd.cn/imazbqb/11474.html
