食品安全溯源区块链解决方案探索

本文节选自电子书《Netkiller Blockchain 手札》

Netkiller Blockchain 手札

Mr.NeoChan,陈景峯(BG7NYT)

文档始创于2018-02-10

版权 © 2018 Netkiller(Neo Chan). All rights reserved.

版权声明

转载请与作者联系，转载时请务必标明文章原始出处和作者信息及本声明。

内容摘要

这一部关于区块链开发及运维的电子书。

为什么会写区块链电子书？因为2018年是区块链年。

这本电子书是否会出版（纸质图书）？ 不会，因为互联网技术更迭太快，纸质书籍的内容无法实时更新，一本书动辄百元，很快就成为垃圾，你会发现目前市面的上区块链书籍至少是一年前写的，内容已经过时，很多例子无法正确运行。所以我不会出版，电子书的内容会追逐技术发展，及时跟进软件版本的升级，做到内容最新，至少是主流。

这本电子书与其他区块链书籍有什么不同？市面上大部分区块链书籍都是用2/3去讲区块链原理，只要不到 1/3 的干货，干货不够理论来凑，通篇将理论或是大谈特谈区块链行业，这些内容更多是头脑风暴，展望区块链，均无法落地实施。本书与那些书籍完全不同，不讲理论和原理，面向应用落地，注重例子，均是干货。

电子书更新频率？每天都会有新内容加入，更新频率最迟不会超过一周，更新内容请关注 https://github.com/netkiller/netkiller.github.io/commits/master

http://www.netkiller.cn/blockchain/index.html

您的打赏是我的写作动力：http://www.netkiller.cn/blockchain/donations.html

==============================

33.2. 食品安全溯源案例

33.2.1. 背景

需求是通过区块链跟踪产品，实现产品产地，生产，流通等环节溯源。

需求归纳，需要实现下面几点：

产品具备通用的属性，例如名称，价格，重量，颜色，体积等等

生产销售链条跟踪

涉及环节，农产品的供应链是一个非常复杂的过程，涉及多方，农业局、卫生局、药监局、工商局、环保局等多个部门交织其中。

参与者角色，我们为每个环节的参与者分配一个以太坊账号，例如每个供应商一个账号，每个代理商一个账号。这样任何一方经手后都会使用自己的账号想合约中添加数据。

33.2.2. 安全问题

我将安全划分为六层，分别是：

+----------+-----------------------------+| 实体层 | 物 |+----------+-----------------------------+| 用户层 | 人 |+----------+-----------------------------+| 网络层 | 网络 |+----------+-----------------------------+| 应用层 | 操作系统，应用服务器 |+----------+-----------------------------+| 业务逻辑层 | 功能，业务逻辑 |+----------+-----------------------------+| 存储层 | 物理存储，硬盘 |+----------+-----------------------------+

并不是实施了区块链技术就安全无忧了，安全分为很多层，区块链只能做到存储层的安全。区块链无法解决用户层，应用层，逻辑层等安全问题，他只能保证存储在硬盘上的区块不被修改。

因为区块链仅仅能解决数据存储层的安全问题，不能保证上链的数据是真实的，上链前绝对不会被篡改；所以仅仅朔源，不考虑防伪是没有意义的，防伪仍然是重中之重。

33.2.3. 防伪问题

如何做防伪呢，这个领域很多公司已经探索多年，各种高科技应用，武装到牙齿，但仍没有解决假货问题。

区块链的出现很可能是一个突破，我们只需将现有成熟的防伪技术与区块链结合即可。

现在流行的访问技术太多了，我倾向于采用二维码技术，二维码与互联网紧密相连。

33.2.4. 性能问题

区块链目前的底层只适合做，低频高价值的业务。

区块链的读取性能通常是没有问题的，但是区块链的写入实际上无论你用多少个服务器节点都不能提升，因为写入区块需要做共识算法，这步操作，会在所有节点上进行，同时还需要加密运算，这些操作都是 CPU 密集型操作。所以写入操作是存在瓶颈的。

解决这个问题，我想出了几种方案：

性能解决方案

通过消息队列技术异步写入，将需要写入的区块放入队列，异步完成上链操作。

并行写入，我们可以建设多个区块链平台。多个平台同时服务于业务。

为了达到去中心化并行写入，我们将在客户端通过算法，匹配服务器。而不是在两个平台前面增加负载均衡。因为这样又回到了中心化系统。

33.2.5. 颗粒度问题

朔源的颗粒度问题，例如“红酒”的溯源，我们是将单位溯源做到箱呢？还是打，或是瓶呢？

我们用“四象限法则”分析

高价值 o | | o | 低频率 --------------+------------- 高频率 操作频率 | o |o | 低价值 物品价值

通过观察上面图，我们可以看到可以有四种情况，低频低价值，低频高价值，高频高价值，高频低价值

我认为对于低频高价值和高频高价值的业务，尽量做到最小颗粒度。

而对于低频低价值和高频低价值的业务，可以颗粒度更粗。

33.2.6. 存储规划

如果是高频低价值的业务，那么溯源数据源源将会不断的被添加到区块，以此同时区块的访问率极低。迟早会达到一个临界值。

所以你要规划存储，例如溯源数据的过期时间，对于 hyperledger 可以使用 DelState(key) 删除历史数据。

如果是高频高价值的业务是否要考虑永久保留数据呢？

这些问题都是需要考虑的。因为目前我们还不知道区块链的存储临界值。

33.2.7. 大数据问题

区块链替代不了数据库，它与数据库是互补关系。

对于低频的业务，通常传统数据库足以应付。那么对于高频操作的业务呢？暂时可能没有问题，但总有一天会遇到瓶颈。