区块链工作量到底有哪些？共识合约运维全链路拆给你看

导读： 进行了为期三年的区块链研发工作, 经历了从PoS共识机制的调试到跨链桥服务上线的完整周期, 这一过程的复杂程度远远超出了单一由少数几名工程师就能承担的范围。...

进行了为期三年的区块链研发工作, 经历了从PoS共识机制的调试到跨链桥服务上线的完整周期, 这一过程的复杂程度远远超出了单一由少数几名工程师就能承担的范围。

现将整个项目链路中所涉及的具体工作量进行详细拆解展示, 以此提示在项目预算评估时, 严禁简单地套用开发一个去中心化应用程序所对应的低成本估算法则。

区块链工作量怎么评估

千万别把眼神只死盯着写代码这件事儿上。像共识层的参数调优, 还有分叉处理这一类的事, 也包括 P2P 网络协议的适配, 这些活儿通常比搞智能合约还要多消耗人力跟精力。

拿一个小项目来举例, 仅仅只是做共识模块的联合调试和压力测试这两项工作, 就足够耗费掉两三个月的时间了。你只要对 调参进行哪怕一次修改, 整个区块链链路上的出块节奏就必须重新去进行全面验证。

大家一看合约开发, 觉得只有几十行Solidity代码, 但实际上这些内容必须通过形式化验证环节、安全审计环节以及gas优化环节。针对一条ERC-20合约而言, 其背后涉及上百个测试用例的内容, 若是无法通过审计那关, 那么前面的努力就全都没用了, 仅仅是安全审计这一轮的报价就不低。

区块链运维工作量有多大

链运行起来, 这不是说部署完成就可以收摊子不干了。节点的监控、快照的备份、参数的热更新, 以及七十二小时全天候的在线待命值班, 这都是很平常的事情。小规模的团队里面, 至少需要两到三个人轮流进行值守工作。即便是节假日的时候, 这些工作也是不可能停止了的。

像浏览器这样的服务, 还有索引器, 以及跨链桥这些东西, 它们都需要耗费大量的人力来进行维护, 导致周边这些服务会持续地吃掉团队的人力资源。

很多队伍往往是在项目进行到一半的时候, 才忽然意识到运维这项工作所需要的资源其实比开发工作还要多得多。所以,人力缺口这个问题必须要在前期就及时补上人才, 否则只要节点发生了宕机情况, 就会导致整个业务链路全面停止运转。

将共识、合约以及运维这这三条业务线分别进行单独估算, 不要将其随意塞进所谓的“开发”这个笼统的大分类里去统一考量, 只有这样, 才能够确保在项目交付的那一天, 不会出现预算超支和排期混乱那种令人崩溃的状况。