五大要点，解析区块链产品的设计基础

一、上链数据处理

1. Hash

一般的，出于以下原因，我们无法在区块链上存储数据的原文：

出于上述原因，普遍做法是在区块链上存储数据原文的Hash值。基于Hash算法的特点，数据原文均会被转换为固定长度的字符串，且无法通过Hash值反推出数据原文，简单有效地避免了上述问题的发生。

当然，这一做法也有其局限性，即只存储Hash值的区块链，只能用作数据在某一时刻的存在性验证，而无法替用户存储数据原文。数据原文需由用户自行保管，或交由第三方机构保管（可能面临数据被篡改而无法通过验证的风险）。

2. Merkel Proof

在日常工作中，我们可能会面临这样一种情况：一条数据包含A、B、C、D四个字段，此时如何将这条数据上链呢？

简单的将字段A、B、C、D连接并进行Hash是一种方案，但对于某些场景，比如应聘者要将这条数据分享给用人单位，但出于隐私考虑，只想分享字段A、B的数据原文，而不想分享字段C、D的数据原文，在这一场景下，只对数据进行Hash计算并上链，显然无法满足这一需求。

此时，一种可行的方案是基于Merkel Proof，使用各字段计算出Merkel Root Hash，并将该Root Hash上链。Merkel Root Hash的计算过程示意见下图。

当用户在分享数据时，愿意展示给他人的字段显示为数据原文，不愿意展示给他人的字段显示为Hash值，根据Merkel Proof，拿到这条数据的人依然可以计算出Merkel Root Hash，并在区块链上验证数据是否未被篡改。示意如下图：

应用Merkel Proof除了可以解决涉及隐私的数据分享的问题外，还可以大幅降低上链数据的数量，间接提高TPS，如果数据上链是在如以太坊等公链，还可以大幅降低上链成本。

例如，有100条数据需要上链，通过Merkel Proof，可以将这100条数据计算为一个Merkel Root Hash。

缺点在于，若用户自行保管数据，除了要保管自己的数据外，还要保管跟自己的数据相关的数据Hash，增加了用户需要存储的数据量。

示意如下图，用户需要保管红框中的数据。

二、私钥管理

私钥管理目前常用的有四种模式：

1. 不为用户生成公钥和私钥

用户在签名交易（数据上链）时，由平台使用统一的私钥进行签名。

优点：用户学习成本很低；开发成本低；用户不需要担心私钥丢失问题。

缺点：由于所有数据均使用一个私钥签名，无法在区块链上区分执行数据上链操作的用户；过于中心化的处理方式，导致用户有可能质疑上链数据的真实性；平台将承担重大的安全责任。

2. 为用户生成公钥和私钥

私钥由平台统一保管，用户在签名交易（数据上链）时，由平台直接使用用户私钥签名。

优点：用户学习成本很低；开发成本低；用户不需要担心私钥丢失问题；可以在区块链上分辨出数据是由哪个用户执行的上链操作。

缺点：过于中心化的处理方式，导致用户有可能质疑上链数据的真实性；平台将承担重大的安全责任。

3. Keystore

为用户生成公钥和私钥。其中私钥由用户自行设置密码加密，并由平台统一保管。用户在签名交易（数据上链）时，需输入密码解密获得私钥并签名。

优点：用户学习成本较低；可以在区块链上分辨出数据是由哪个用户执行的上链操作；在某种程度上，可以认为是去中心化的数据上链方式。

缺点：开发成本高；用户多了一步设置密码操作，以及在每次执行上链操作时多了一步输入密码的操作；由于平台没有保存用户私钥的原文，一旦用户丢失或忘记用于加密私钥的密码，后续该用户上链的数据的真实性将无法保证，甚至无法执行上链操作。

4. 为用户生成公钥和私钥，由用户自行保管私钥。

优点：开发成本很低；可以分辨出数据是由哪个用户执行的上链操作；完全去中心化的数据上链方式。

缺点：用户学习成本高；用户每次执行上链操作时多了一步输入私钥的操作；由于平台没有保存用户私钥的原文，一旦用户丢失或忘记私钥，后续该用户上链的数据的真实性将无法保证，甚至无法执行上链操作。

具体采用哪种方式，需要根据去中心化要求、安全、成本、开发能力等多方情况综合考虑。

三、私钥的丢失处理

在第三节列举的私钥管理方案中，无论私钥由平台保管还是用户保管，都可能涉及遗忘私钥或私钥的加密密码的情况。在传统互联 产品中，若用户忘记密码，可以通过手机 、邮箱等方式重新设置密码，但对于区块链产品，无论是私钥还是私钥的加密密码，都不能简单的使用传统的忘记密码流程进行处理。

目前一种可行的处理方式是，在区块链上的智能合约中，记录用户信息、用户公钥地址、公钥地址的有效状态（包括有效和实效）和失效时间。其中公钥地址为与用户私钥唯一对应的公钥的Hash值，有效状态和失效时间用于在数据验证时，验证数据的有效性（在第七节将具体说明）。

当用户遗忘私钥或私钥的加密密码时，可以为其重新生成一组公私钥对，并把新的公钥地址写入智能合约，并与用户信息关联，同时将旧公钥地址的有效状态改为失效，并写入失效时间。

可见，这一方式通过在区块链上为用户关联多个公钥地址，解决了用户遗忘私钥或私钥加密密码的问题，同时还能标识出公钥的拥有者，便于确定执行上链数据的用户。

四、用户的自我数据保管

传统的互联 产品，用户数据由平台中心化保管，这导致了用户隐私、数据安全等问题，且用户自己产生的数据没有为用户创造出价值。

而在区块链产品中，为改变这一情况，需要允许用户导出自己的数据。有一个原则是，用户导出的数据，需要能不依赖于任何中心化的验证平台，独立在区块链上验证该数据是否存在，这就要求导出的文件中必须包含所有数据验证所需的字段，如数据原文、Hash算法等，这些数据通常以json文件的形式存。

同时，考虑到json文件的可读性较差，导出的数据还可以包含易读的明文数据（比如用户的原始数据文件，如图片或文档）。通常会将这些导出的数据打包为一个压缩包供用户下载。另外，为提升用户体验，压缩包中还可以带有使用说明，以说明压缩包中各文件的作用，及数据验证方法。

一般来说，对于删除的数据，需要重新在区块链上发起一笔交易，除带有该数据的Hash等常规信息外，还需要额外带有数据撤销标识。在数据验证时，如果待验证的数据所在交易中，存在撤销标识，则意味着这条数据已被删除，验证将无法通过。

一般来说，用户自身不具备通过区块链验证数据是否存在且未被篡改的能力，而是需要通过中心化的平台提供的验证能力进行验证，这里就涉及到平台需要验证哪些内容。

下面列举一些较为通用的验证项（不代表先后顺序），可根据实际需要选取：

题图来自Unsplash, 基于CC0协议