本文重要陈设了一些尔在区块链产品安排过程中，遇到的与区块链相闭的常睹问题和处置筹备，实用于预备大概初入区块链行业的产品经理观赏。本文中陈设的处置筹备并不是独一的，假如大师有其他筹备，大概遇到了其他的问题，迎接留言计划。

一、上链数据处置

1. Hash

普遍的，出于以下缘故，咱们无法在区块链上保存数据的本文：

• 数据秘密；
• 制止因数据量过大，加沉全节点的保存承担；
• 矿工大概分别于世界各地，假如北京的矿工播送了一个高度为100的新掘出的区块（定名为区块100A），受网速效率，位于北京的另一位矿工和位于非洲的矿工接收到这一区块的时间必定不共。区块越大，非洲的矿工接收到区块100A的时间越晚。这便引导了非洲的矿工大概会在高度为99的区块的前提上持续掘矿，从而掘出了区块100B并播送，此时便展示了有比赛闭系的二条分叉，分叉A和分叉B，直到新的主链当采用。这进一步引导了在未当采用为主链的分叉上掘矿的矿工所干的处事均废除，形成了资材的浪费。

出于上述缘故，普遍干法是在区块链上保存数据本文的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等常规信息外，还须要特殊戴罕见据废除标记。在数据考订时，假如待考订的数据地方交易中，存留废除标记，则表示着这条数据已被简略，考订将无法经过。

闭于于编写的数据，相当于在区块链上倡导二笔交易，一笔交易用于废除编写前的数据，另一笔交易用于将编写后的数据上链。

普遍来说，用户自己不具备经过区块链考订数据是否存留且未被篡改的本领，而是须要经过核心化的平台供给的考订本领进行考订，此地便波及到平台须要考订哪些实质。

底下陈设一些较为通用的考订项（不代表先后程序），可依据本质须要采用：

• 获得待考订数据中，代表该数据地方交易的标记，并运用该标记获得区块链上的相应交易确定；
• 从交易确定中获得签发交易的用户的ID，并运用用户ID和交易标记查瞅该交易是否已被废除；
• 考订数据相闭的智能合约是否未被篡改；
• 从交易确定中获得签发该条数据的用户的公钥地方，并在用户控制智能合约（参睹第四节）中，查瞅该公钥地方是否存留且是否未降伍；
• 核对于考订数据的方法是否符合平台典型；
• 核对于考订数据的哈希值是否与区块链上的交易确定中记录的哈希值普遍。

本文由@Nik 本创发布于大众都是产品经理，未经答应，遏止转载

题图来自Unsplash, 基于CC0协议