技术分享:区块链技术的“垃圾输入和垃圾输出”

转载
1757 天前
5900
Taraxa

来源:Taraxa


写在前言

前之前,我们写了一篇文章介绍了“区块链技术为不同种类数据带去的价值”,即区块链在保障不同数据的来源、不可变性以及真实性方面的能力。本文,我们会继续解答另一个常常被大家(有意)忽视的问题:数据如何同区块链交互。就像其他众多系统一样,区块链技术也正经历着“垃圾输入,垃圾输出”(GIGO)的痛。

01

向区块链撒谎

之前发布的关于数据的文章中,我们发现对于那些非区块链本地生成且非公开可获取的数据,区块链系统并不能确保其真实性,而不幸的是,全球绝大多数都是这类数据。因此,如果某人(某设备)提交欺诈性数据到区块链上,我们根本无法确定其真实性,结果就是你不停地提交假数据到区块链历史。于是,你让垃圾上了链,区块链再还你垃圾。

据悉,如今忽略这个问题的应用比比皆是,通常它们会再附加一些技术层确保数据正确性,这里是几个案例:

去中心化数据市场:用代币激励企业挂牌出售数据——你怎么知道你买的数据是真实的?

隐私保护查询:这项服务通过一种零知识范围证明来计算银行高净值人士数量,这样你就可以收获一个数字而银行不用提交任何客户数据——那么你怎么确认银行没有伪造整个客户数据库?

对于公开可获取的数据,你可以设计一个游戏,让有资金风险的玩家向其他玩家的数据真实性发起挑战,就像Chainlink设计的那样。但正如我们之前所说的,世界上绝大多数数据并非公开可获取。

那该怎么办?关键是要在源头确保数据安全。


02

确保数据来源安全

如果我们没有从源头获得数据,而是通过第三方或中间商获取,那么在不信任这个中介的情况下,这个数据的真实性也就不再可信。越多中介参与的数据管理,越是不得不信,但如果中介数量多到一定程度,这个数据就有可能是由随机数生成器生成的了。

所以,我们的目标就是尽可能从靠近源头的地方获得数据。例如:

  • 与其从零售商的数据库获得销售数据,不如从销售点硬件入手;
  • 与其在网站上订阅天气预报,不如关注采集数据的天气传感器;
  • 与其查看桥梁运营企业的PDF报告,不如从桥体上安装的摄像头和传感器获得原始数据等。

但是如何从源头确保数据安全呢?由于世界上大部分数据都是由设备产生或捕捉,我们这里也可以把这个问题描述为如何保护设备生成的数据。现在,我们面临着三个潜在的失败点:

  • 身份:你如何知晓正在生成数据的是什么设备?是你预想的温度感应器吗?还是作恶者的随机数生成器?
  • 处理和传输:即使数据来源真实可确定,你又从何得知这个数据没有被更改、损坏或在设备的处理和传输过程中被直接替换掉(比如从传感器传输到通信模块)?
  • 数字/模拟接口:就算身份、处理以及传输途径都安全,那你又要如何预防有人通过接入假的输入信号源来物理更换设备采集数据的渠道?

下面我们来一一解决这些问题。


03

一个实用的方法

  • 身份:

为了确保生成数据的设备身份受到保护,我们可以在设备上嵌入一组公私钥,让公钥知晓并且现场检查实际设备的输出,通过这种切实可行的手段确保硬件的身份没有问题。——当然,这是相对简单的一步。

棘手的部分是,你如何确保这个身份不是偷来的或者只对设备可知?这里可以采用一种叫做“安全元素”(Secure Element, SE)的硬件模块,它能够在芯片上生成公私钥对,并且高度防篡改。通常情况下,这个安全模块只做一件事:签署消息。——这是一个提供身份证明的好方法。如果你持有过信用卡,或者用过现代智能手机,那么你已经享受到了这个安全元素的好处。

  • 处理和传输:

为了保护数据处理与传输逻辑的安全,我们采用了一个带有安全启动程序(SB)的微控制器(MCU)。你可以把这里的微控制器想象成一台超级简单的计算机。

SB确保只有拥有正确私钥的实体能够加载应用程序到MCU中。而这个应用程序的逻辑和相关的校验能够提前共享给利益相关方(或者直接开源),这样就可以在加载后对其进行验证。

接下来更关键的是,在应用程序经过了全面的测试后,我们需要禁用应用程序和MCU上所有的修改功能。这一点是为了确保从现在起该应用程序的逻辑彻底不可更改,就算是制造商也无法再做改动。

这个方案也存在一些明显的缺点,比如之后应用程序就不能再更新了。但是相比之下,我们获得了真正的设备独立性(结合SE)而不再受外部干扰,并且具有了完美的确定性与不可更改性足以让我们信赖。

  • 数字/模拟接口

这方面的问题比较难,不能通过数据采集与中继设备上嵌入的硬件来解决。通常必须设计出创新机制来确保接口不被中断,但这一点还要看每个应用程序的情况。下面我们来举个例子。

假设你有一台冷藏车,服务于某冷链物流公司,日常工作是为当地的超市配送新鲜的鱼。为了保鲜,鱼必须保存在一定温度范围内。如果温度过高,鱼就会变质;而温度过低,鱼的口感和肉质就会变差。为了确认物流公司遵守了合同约定的温度范围,超市会在卡车上安装一个温度传感器。

但是,如果卡车司机为了节省电费而调高制冷装置的温度,然后把传感器拿走放到车前的一个冷却器里怎么办?传感器根本不会知道自己被挪动了,只是继续收集、报告那个恒定在合同约定的温度范围里的数据。也就是说,传感器被骗了。

减轻这种风险的一个方法就是把传感器也做成硬件接到制冷装置中,这样就几乎不可能被移动了。不过,这种对策仍旧可以通过某种方式避开,比如在传感器周围缠一袋冰,而卡车其他部位依旧比合同规定的温度高。

另一个可能更好的方案(也更贵一点)是给每包鱼的包装上贴个防篡改的密封条,并且在每个包装上配置一个温度传感器。这样一来,如果司机想要拆开温度传感器,他就不得不撕开封条,这样就很容易被发现是违背了合约的关键条款。

就像前面提到的,解决数字/模拟接口的问题需要大量的创造力,且解决方案需要“具体问题具体分析”。