在区块链落地场景中，区块链的作用，有时候被定义为用于信息存证的，具有不可篡改特性的“公示板”，例如在很多溯源、票据流转场景中，“公示板”的表现的比较明显。但是究其本质：区块链是作为一个提供数据可信流动的通道被使用的。区块链上数据的处理就变成了场景的关键环节，链上数据存储则是链上数据处理的重头大戏。数据处理吞吐量和存储空间有限一直是区块链在应用落地上的大阻碍。
本文针对区块链数据存储问题做一次剖析（隔离见证-外挂DB-分布式存储），并提出一些可行的区块链数据存储模式。针对区块链的吞吐量问题将在下一篇文章中进行讨论。
区块链上每个区块只能限制在一定的体积下（原始比特币的区块大小约为1M），不能无限扩充；区块链出块间隔必须达到一定的间隔（例如比特币为约10分钟，本体为约6秒）。这是由于区块链自身节点分布性的特色导致的（区块体积太大，会导致区块传播的带宽压力和传播延时增大。由于区块传播延时的存在，出块间隔太小会导致链上分叉太过频繁）。
针对“怎样在区块体积有限的前提下，能够承载更多的数据量?”业内进行了诸多的探索。笔者将他们大概归为三种类型：（1）调整块内数据结构，来扩容。例如隔离见证。（2）链上保存索引，外挂数据库存储具体内容。（3）链上存储索引，具体内容存储到分布式存储系统中。
1. 隔离见证
隔离见证将原来区块中“必要”的交易信息（输入、输出）和“非必要”信息（脚本签名）分开，并把脚本签名信息从区块基本结构里拿出来，放在一个新的数据结构当中。这样可以把块内可容纳的数据记录增大约60%。（备注：隔离见证并不只用于扩容）。
隔离见证中的见证数据还是存储在链上。每个全节点依然会同步所有的数据。
2. 外挂DB
在使用区块链存证时，如果要存证的数据体积较小（一般建议小于1Kb），可以直接被记录到链上区块中。但是对于要存证的数据体量很大时，如果将数据全部存储到链上就很容易造成链的过载，这种情况下，建议将数据结构化之后计算数据整体的哈希，将数据哈希和数据的相关属性（例如哈希算法、时间戳、数据所有者签名、数据路径等）上传到链上并获得返回的数据ID，而将数据本身存储到区块链的外挂数据库中。
当需要调用链上已存证过的数据时，（1）首先根据数据ID验证是否是链上有效的，（2）然后获取链上对应的数据的属性信息，从外挂DB中找出对应的具体数据。（3）验证具体数据的哈希是否和链上哈希匹配。如果不匹配则证明外挂DB中的数据被篡改过。
从上述步骤可以看出通过外挂DB模式进行链上数据存储的时候：（1）链上数据哈希可以防止篡改。（2）可验证具体数据是否被篡改过。（3）不能保证外挂DB中存储的具体数据不被篡改。
综上可得：对于大体量数据进行区块链上存证（或者说数据存储）时，如果采用DB外挂的模式，存在具体数据被篡改的风险。
为了抵御具体数据被篡改的风险，需要对外挂DB的部署模式和数据备份模式进行考虑。外挂DB的部署模式分为三种模式：（1）中心外挂DB群（2）分布式外挂DB（2）授权访问式外挂DB；
（1）中心外挂DB群是指所有链上的节点公用一个外挂DB群，所有的大体量数据都被存储在该中心外挂DB中。
（2）分布式外挂DB是指每个节点根据自己的业务需求或数据安全需求，设置自用或与其他节点公用的独立外挂DB，各个外挂DB支持的数据备份模式分为全备份（同步所有数据内容）和轻备份（仅同步关心的数据内容）。
（3）对于一些数据明文内容不方便公开的情况（例如个人信用数据等），具体的明文数据被存储在专有节点的专有数据库（即授权访问外挂DB）中。数据所有方（例如个人）可以通过将自己的数据哈希上链，然后数据调用方（例如贷款放款方）可以通过数据所有方授权的方式去访问授权访问外挂DB中对应的数据。
3. 分布式存储
分布式存储例如IPFS设计初衷是用于区块链的数据存储。其分布式和多备份的特点，可以有效的防止中心外挂DB可能造成的数据篡改问题，同时可以避免分布式外挂DB可能存在的过度备份对，存储资源的浪费。分布式存储是一个理想的可用于存储区块链大体量数据的存储方式。
目前的分布式存储系统例如IPFS还很不成熟，系统可用度很差（数据存取速度很慢，数据存储体量小），现在不能用于区块链上大体量数据的存储。
文中讨论了目前区块链上数据存储的各种形式，可以得出以下结论：
（1）链上大体量数据存储目前没有落地性问题。
（2）在大体量数据存储方面还是推荐链上哈希和外挂传统DB的模式。
（3）分布式存储例如IPFS，是一个有前途但目前不可用的存储模式。
网友评论