目录区块链方案落地就三件事说人话版本别被PPT忽悠了

导读： 所谓把目录上链这件事, 如果要说得直白一点, 意思就是把那些被反复修改、被不断核查的索引数据, 完整地填充到一个无法进行任何变动的、基于区块链技术的存储区域里头去。...

所谓把目录上链这件事, 如果要说得直白一点, 意思就是把那些被反复修改、被不断核查的索引数据, 完整地填充到一个无法进行任何变动的、基于区块链技术的存储区域里头去。

从本质上进行解释, 目录所指代的对象也就是这些内容, 其中涉及到的工作人员发生变更、资产所有权的归属发生转换、以及对使用的权限进行调整等诸多事项, 在日常工作当中每天都在进行修改。完成修改动作之后, 必须确保所有的相关人员均能够查询到最新的状态信息, 与此同时, 过往的历史记录也得以完整保留。

你千万不要跟我扯什么共识算法有多么的强大和厉害, 目录数据最核心的本质特征, 从严格意义上来说, 就是读取的次数远远多于写入的次数,同时对于任何篡改的行为都是绝对不能容忍的。

你要是用那种需要耗费大量计算去算哈希值的去中心化机制去处理一次简单的目录变更操作, 这简直就是非常不合理的事情, 用叉车去帮忙拧螺丝钉, 完全是不可想象的荒谬场景。

在实际的技术落地场景中, 使用PBFT或者Raft这种相对高效的主从复制协议, 通常只需要让五个这样的节点同时进行运行, 就已经足够满足需求了, 而且所有的数据变更请求都必须依靠多个私钥签名来进行共同确认。

在上一年度, 某省级政务云所使用的这套系统在接入高达三万人的用户目录数据进行负载测试的过程中, 其数据查询响应的耗时维持在八十毫秒的水平。面对当前这样的技术表现标准, 我们认为相关方面不应再进行过度夸张的宣传与评价。

在进行溯源工作的时候, 如果通过链上的方式来查询一下数据, 那么究竟是谁在具体的哪一个时间点修改了哪一个特定的字段, 这个情况都会变得非常清楚明白, 这样一来, 相关的审计工作人员也就不需要再去翻阅那一大堆的Excel表格文件来核对签字的内容了。

方案不要做得像科研论文一样。目录里把区块链仅仅说成是一个防止篡改的保护外壳就行了, 它的读取速度快而写入速度慢, 说到这里就可以了。