工程项目管理应用的低存储量区块链实现
区块链不仅仅构造了数字货币，作为可信底层架构，区块链通过保存历史信息提供了可追溯的功能。该功能在获得用户信任基础上，保证了产品可信度，降低业务审查、清算等会计成本。状态区块链是一种比传统区块链更加激进的区块链底层架构，它选择了不保存所有历史，而是选择通过总结来归纳出每个可信区段中所有账户的状态，从而实现在现有可信基础上更加灵活的应用部署，彻底摆脱了原本对每个节点存储空间的苛刻要求。工程建设过程中随着工程的推进，尤其是大工程，工程管理对于可信基础上的账簿、设备以及合同等元素管理的需求越加强烈。但由于工程环境及项目成本的限制，相比传统区块链，状态区块链应更具优势。
本文中，在对区块链相关技术进行综述的基础上，对市场上的低存储量区块链技术进行了比较分析，提出了基于状态的低存储量区块链的实现方案和部署思路。然后，在工程项目管理领域中，对提出的低存储量区块链进行了实现和场景分析，表明本文所提方案在保障区块链安全性的基础上，具有项目成本优势。
论文PDF标准版下载
区块链中存储的成本
首先，随着技术的提高，假定存储数据的成本呈指数级下降。我们则可得到一个这样的模型
c(t)是在任何给定年份t中存储1GB数据的成本。
A是当前按存储1GB1年的成本。通过Amazon Elastic File System进行定价。使用EFS，全年存储1GB数据的6个副本的成本为每年21.60美元。即A=21.60美元。
k是存储成本随着时间推移下降的速度。k越大，价格越快降低。根据过去35年的历史数据，k约为0.2502，但对未来存储成本的预测表明未来这种变化率会下降。
这可以得出我们在任何一年内将要花费的存储容量。现在我们可以计算我们的存储总成本。
每年我们必须为当年收到的新数据支付费用，并继续存储前几年的所有数据。所以每年的存储成本为：
由于众所周知的区块链扩容，比如比特币从1MB过渡到2MB，模型中的Predicted_GB本质也是在逐年增加的值。随着数字货币与区块链逐步被越来越多的人所认可，区块容量(BuiltinSize)增加的步伐也越来越快。作为激进的比特币分叉，比特币现金，已经分叉至32MB。从市场来看，越是热门的区块链产品的信息存储量增速越快。而热门程度我们可以根据其代币的交易量来判断。
那么最终的每年存储成本即为：
总而言之，通过该模型，我们可以清晰地看出，这通过优化后的区块链存储成本模型，最终其是递增膨胀，还是逼近指数下降，取决于科技发展的k值（<1）与年存储量，也可以说是k值与产品热度之间的博弈。作为跑赢市场的明星产品，例如Ethereum，必面临存储量爆炸的问题。当然从一般角度来看，服务器硬盘的发展是完全超越一般的区块链增长的。
但是在特定环境，尤其是分布式的物联网环境，区块链上为了实现分布式与数据可信，设备往往分散且数量可观。因此，实际在物联网或多节点等正常区块链环境下，当区块链应用全网设备数为DeviceNum时，存储成本为：
也因此，为了节约成本，项目往往选择具有较少的存储空间的设备，这就更进一步限制了区块链存储不能无限制地膨胀。因此，换句话来说，在存储成本较低基础之上，倘若能够限制住区块链数据存储的膨胀，区块链产品则能够部署于更广泛的领域。
区块链在工程管理中的应用
到目前为止，区块链在建造行业中的实际使用并不常见。有些人正在使用它结合物联网来存储建筑物的传感器数据。还有人认为类似以太坊的分布式平台可以托管BIM应用程序。也有人提到区块链在合建项目中的应用，因为它可以提供一个有用的工具，通过使用智能合约，监控各方在整个设计和施工阶段管理和记录上对BIM模型的更改，即通过编辑和存储建筑模型的所有修改记录到不可变的公共记录中（区块）。
首先，众所周知的是，区块链可以作为数字账簿的存在，如hyperledger，中文名超级账簿。
当前，企业间的战略联盟（partnering模式）中，由于各个企业仍然是独立法人，战略联盟中经常会发生由于道德风险、逆向选择等问题造成的联盟合作关系不稳定。因此，目前急需一种合理的激励机制，保障供应链联盟之间的信息开放共享来防止问题发生。因此，需要一种受到各方信任的信息技术手段，来支持分布式的信息记录储存，联盟中的企业从不同途径来分享多样化的信息。区块链技术的应用，在对企业共识数字化的基础上，受所有人信任，不仅能实现价值共创共享的目标，而且构建了利益相关者之间的共生关系，实现了多元资本共生和利益相关者的共同治理。万达、百度、空客、美国运通、思科、富士通、日立等国内外各个行业的大公司在战略上往往拥有更加错综复杂的联盟关系，因此其对hyperledger的需求更为强烈。除他们以外，hyperledger还有约200余个企业合作伙伴，可见世界领先的企业对区块链在账簿上应用的普遍认可。
虽然区块链技术为项目相关的会计更多样化的工作与管理模式提供了可能。但与金融领域相比，项目管理会计领域拥有复杂性和独特性，区块链技术在该方面应用中依然面临数据存储空间有限、业务数据处理难度高、对现有中心化记录的管理会计基础业务架构和业务规则挑战等问题。
更贴近工程内容的，区块链往往依托着物联网或BIM这类将传统产品信息化的载体，以此方式在工程项目之中得到运用。
以前的方案可用于管理存储在文件中的任何建筑物信息，包括BIM文件。然而，在BIM设置中实施区块链的正确方法是将其与BIM服务器集成。架构如图所示。
Barnett正在确定建筑行业中区块链的一些用途，例如维护记录数字财产，基于时间戳记录行为或交易，多重签名交易，智能监控情况并执行自己的计算机程序以及与真实世界结合的智能合约信息存储库。还有争议中能够使用自动化区块链解决方案，基于智能合约的智慧城市，以及区块链房地产投资等也被设想出来。
Security Ledger指出，“在保卫物联网安全方面最大的挑战之一就是身份问题。更明确一点就是：我们如何确保数十亿或者百亿的智能设备相互之间的连接与交流安全。看起来区块链能够提供答案。”
在与区块链结合之前，物联网一直是个“矛盾的存在”，物联网的发展前景已被所有人认可，但是症结问题一直得不到解决。中心化的管理架构存在无法自证清白的问题，也即不管你是否窃取了参与方的隐私，都容易被怀疑，没有理性的方式可以证明你的清白，完全靠相互的自觉与信任。况且，个人隐私数据被泄露的相关时间时有发生，例如，摄像头被网络直播的事屡见不鲜。物联网的参与者，尤其是工程项目中物联网的参与者，通常不完全被发起方所单独掌控（例如普通私人用户、企业用户），如何让其他的合作方能够更好地参与到项目之中，面临极为复杂的协同成本。
但是如此看待区块链，大多是由于当今区块链产品多基于以太坊等平台，制作思维也跳脱不出数字货币的范畴。以太坊中除了CAP冲突以外，对于合约本身的进行也存在着合约不可修改、合约太过依赖主网等缺陷。这未免太过局限了其区块链应用的发展。本质上来说，区块链的应用重点在于其共识的形成，共识才是一个分布式应用与区块链应用的最大差别，最重要的，包括区块形成条件（挖矿条件）、出块时间、区块存储方式设计等各种被平台所简化的内容本应也是应用的重要内容。
因此除了传统的和物联网、BIM等信息元素结合以外，工程项目之中可以将生产过程、交付过程等一系列费时费力的过程量化编译成数个共识，将这些共识合并起来数字化形成针对项目的合约。
市场上的低存储区块链方案
在UTXO中，比如比特币，抛去了状态的概念，其中账户（即地址）的余额通过与它相关的事务来进行判断，例如某个地址在区块链中的出现是先通过工作证明获得了100货币单位，然后在其之后8个区块时间后它将88个货币单位转移到另一个地址中，其后没有任何相关交易。这样在当一个节点遍历完所有区块之后就可以计算出该地址余额为12个货币单位。
这样的产品设计，虽说要求了节点必须下载并遍历整个区块才能分析出地址余额这样累赘的工作，但是也的确非常成功地解除了他人尤其是非技术人员对区块链的怀疑——至少让区块链概念更加通俗易懂。
可是区块链的不断增长使得这个下载与遍历操作越来越困难。比特币核心开发者团队意识到了这个问题的严肃性。在2016年初bitcoin的区块就已经超过60G，开发者团队在新核心钱包中针对节点新加了区块链存储的修剪模式（prune）。全节点钱包，即核心钱包的使用者通过在个人目录中bitcoin.conf配置文件中，输入“prune=1024”并保存，重启钱包后即可打开节点的修剪模式。通过该模式，节点可以将60多G的存储不断删减直至你设定的值（1024mb），且相比以前能更加快速地打开钱包。但是这个模式仍有局限性——及其耗时且耗计算的同步过程：它需要先从p2p网络上下载这所有的区块，再对已下载的区块逐个进行散列计算生成散列值，并校对散列值的树结构，以此保证所下载区块的完整与安全——这样的下载过程中耗费数G的带宽流量以及堪比数字货币挖矿的计算任务依旧非个人电脑，或者非一般的服务器所能承受。尤其是在用户重新导入一个新私钥后，为了获取这个私钥对应地址的余额信息，节点必须再重复一遍上述所有操作。
随着时代的发展，在2016年开始行业进入了基于区块链的链上应用，即分布式应用（decentralized application，简称DApp）的时代。简单来说，DApp和普通的App原理一样，除了他们是完全去中心化的。由底层区块链网络自己的节点来运作的DApp，不依赖于任何中心化的服务器。虽然DApp是去中心化的，可以完全自动地运行，但是依然也有可能性会被入侵。为了要能够很好地使用这些DApp，就需要定制的入口。例如其中较为著名的就是Augur，一个基于以太坊的去中心化市场预测平台，完全不需要通过任何第三方服务器。目前来看，由于以太坊EVM的健壮，大部分分布式应用都是基于以太坊。
但是，从现状来看，如今很多区块链产品中的“永久存储”特性却仅仅只是一个吸引投资人和购买者的华丽噱头，或者说是一个非常普遍的对当下区块链模式的一种妥协现象：想要让人可信就必须永久存储所有事务。毕竟，在以太坊平台上就已经拥有了在链上存储的功能，无需再多费手脚即可拥有。
但是从产品设计的角度来看，在许多的特定环境下，区块链产品本质上其实并不需求永久的存储——例如游戏、匿名货币以及数据存储等。拿游戏作为例子来看，基于区块链的互联网游戏本身就是在飞速信息交换，在存储和带宽以及共识的限制下，这个交换的成本被无限放大。
如CryptoKitties这个在中心化时代看起来非常简单的养猫游戏。
CryptoKitties(加密猫)是因为一款基于以太坊的DAPP，它由设计工作室AxiomZen打造，它是一个围绕着可育，可收集和可爱生物的游戏，每只猫都是独一无二的，100％归您所有，而且它不能被复制，带走或毁坏。
CryptoKitties是世界上第一款基于区块链技术的游戏，这一突破使得一些像比特币和以太坊的虚拟物品成为可能。比特币和以太币是加密货币，但CryptoKitties是加密的收藏品。就像传统的收藏品一样，你可以购买，出售或交易你的CryptoKitty，在知识产权保护上，区块链会监测保障您的所有权。简单来说，就是利用链来存储了信息。
但是在以太坊网络中部署后，由于销量火爆，直接压垮了以太坊平台的交易传输。据悉以太坊网络在该期间平均堵了近2万笔交易。众所周知，无论是以太坊还是比特币都对每个区块限定了大小，这就决定了每次的区块打包交易中交易总数据量都有上限。对于超出上限的交易，就被拖至下个区块中打包。“近2万笔交易”，可见该应用在链上究竟写入了多少庞大的数据。
因此“永久存储”这个功能对于区块链应用底层来说非常容易成为网络的累赘。纵观当今部署的互联网应用，应用都是以一个“状态”实现的部署——持续集成（CI）就是这种理念的实现，通过不停的覆盖“状态”来达到工程合作的统一；同样的还有应用的持续发布，都是以最终的“状态”作为最终的目的。
对于此问题，以太坊选择的是利用分片技术对其网络进行扩容。
“分片”的大致设计思路是：将区块链网络中的每个区块变为一个子区块链，子区块链中可以容纳若干（目前为100个）打包了交易数据的Collation（大概可以称为“校验块”，为了在分片的情景中将其与区块的概念区分开），这些Collation最终组成一个在主链上区块；因为这些Collation是整体作为区块存在的，所以其数据必定是全部由某个特定的矿工所打包生成，本质上和现有协议中的区块没有区别，所以不再需要增加额外的网络确认。这样，每个区块的交易容量就大概扩大了100倍；而且这种设计还有利于未来的继续扩展，整个扩展计划目前也被大致分为4个阶段；本文所介绍的仅仅是第一阶段的相关实现细节。本质来说就是通过层叠的状态和少量的过程区块来保证性能与可信的双重获利。除此之外，以太坊在新节点部署上通过引入账户（Account）与状态（State）的概念来实现区块更加迅速的同步。其中账户即为已经出现在链上的地址，而状态即为一个时间点上账户及其相关信息的列表。
其实在以太坊启用分片之前，在市场上早已经出现了成型的利用类似技术的数字货币，PascalCoin，它通过pascal编程语言重写了比特币奠定的数字货币的架构，并且引入了账户和状态的概念，实现了其数字货币后台区块链的秒同步。但是，由于高度去中心化的办公模式带来的低效更新以及pascal编程语言死气沉沉的社区，目前情况来看，其在链上应用等方面的发展非常局限。
简单来说，PascalCoin中的块将超过100的检查点高度新的块将附加到链的顶部，旧的块从底部删除，只有一个任何时候都将需要不断的块数。检查点在每100个区块中发生一次，并简单地压缩成SafeBox。当新节点加入网络时，它只会下载最新的检查点和几十个块。此外，SafeBox现在包含在每一个账户段子结构块头信息中。这使得节点成为能独立地计算、验证和构建SafeBox结构所需的累积工作。
它通过以下方式实现:
- 检查是否所有区块头通过SafeBox以类区块链接方式连接
- 使用工作证明方式重新计算SafeBox的累积工作
- 验证是否SafeBox的累积工作是网络中最大的已知工作。
因此，相比其他加密货币，PascalCoin会以指数方式达到更高的每单位存储吞吐量，因为节点只需要存储网络吞吐而不是累积的网络吞吐量。 换句话说，PascalCoin存储的是交易流，而不是交易历史 。如果流量不变，存储也是恒定的。这里要提醒的是SafeBox确实在每个区块都变得可以忽略不计，但总是在固定数量中且无论交易数量如何变化。
且由于节点在任何时间只需要保持100个块，所以相比其他加密数字货币，PascalCoin考虑到了以指数方式增长的更大的区块规模。例如，对于相同数量的存储，即一个Bitcoin节点在现在消耗的存储，PascalCoin理论上可以支持吞吐量为每秒72,000个交易，本地只需5.4GB区块大小。
从模型角度来说，传统区块链，例如比特币，区块大小起初线性增长，在触及区块上限后开启扩容分叉。
而状态链限制其账户增长。PascalCoin的主要新功能之一是帐户可以有唯一的公开可见的名称，与域名系统的方式大致相同。这允许用户接收资金到他们的电子邮件地址或聊天昵称。它允许商店用他们的域名或品牌名称收款。支付本质上仍然是通过数字号码来引用帐户，但是名称用于查找背后的帐号，就像是域名是用于查找背后的IP地址。
低存储方案
思路
虽然区块链总是存在着在新块生成同时有分叉的风险，但是在旧的区块链中，各节点总是形成相同的一条无任何分叉的链
传统的区块链存储结构与内容如下图所示：
可见大部分数据（难度、随机数、版本号等）都存在非常严重的冗余。而交易数据根据UTXO形式，分为交易发送者、交易接受者、交易货币数量、以及交易签名。其中交易签名占空间最大且基本上是一次性数据，对区块链后续发展并无推动作用。
因此我们需要从区块链结构入手设计低存储区块链的设计。
如图中四个区块链节点形成了一个区块链网络。我们可以看到每个节点都保存了从创世区块（GenesisBlock）到N号区块（BlockN），因此从创世区块到N号区块之间的链，根据共识来说，它们就是经过了所有节点的审计且已经可以被我们认为是可信的——那么对于可信的内容，我们则无需再进行验算（尤其是私钥导入新节点接入等流程中），因而我们可以将其删除。但是为了下方（N+1）号区块以及更新的节点的安全保证，我们仍然需要k个区块来形成最长链以防止分叉。同时为了防止数据的丢失，我们也应当将从创世区块到N号区块之间的链中的数据以其他格式存储起来。
因此我们将创世区块到（N-k）号区块的内容整合为“状态区块”来保存内容。
在每过一定阶段，根据全网节点状态进行区块删减，形成由数个“状态区块”形成的“状态区块链”。但是由于状态内容的冗余与过时我们仅仅保留数个最新块。最终则形成了我们的新方案。
用公式表示原始方案与改进方案的存储量如下
原始方案即为直接对区块的存储。StorageSize为总存储规模，blockHeight为区块高度（个数），BlockSize为内置的区块大小，例如Bitcoin初始为1M。
而在针对存储内容优化的新方案中，去除了极大部分的区块，引入了新的"状态区块"Generation来存储每个时间段账户信息。其中，StorageSize为总存储规模，blockHeight为区块高度（个数），GenerationSize为单个“状态区块”的大小，为了安全我们本地需要两个状态区块来保证安全性。CredibleHeight为可信高度，在PascalCoin中该高度被固定设定为100个区块。BuiltinTxNum为单个区块中的事务（交易）个数。
从数学模型可见，该方案除了删除了大部分冗余数据以外，还限制住了数据量体积，可以有效防止数据量的无限扩张。
为什么该方案依旧安全可信
Bitcoin从Merkle树，即默克尔树出发来保证区块安全。如上所述，在进行区块“压缩”、“删减”过程之中链的默克尔树实际上是被破坏了——无法从创世区块重新递推至最新块。
但这并不意味着方案的安全性被打破。我们的关注点在于共识之上——在共识中，所有达到了N的节点在确认全网都已经达到N（通常实践上由8个“确认”消息来判断，与Bitcoin交易的广播类似）之后都会将（N-k）号区块之前的区块进行“删减”——这就如同一次简易的硬分叉（hard fork），在共识之中，虽然树被打破，但是所有交易信息所有事务的结果不会丢失。
而且，新方案中依然存在着默克尔树。首先是“状态区块”能够形成简短的默克尔树，防止恶意用户上线多个恶意节点利用共识篡改历史数据。其次，区块的默克尔树依然存在，但仅仅服务于现在与未来，关注于新区块是否安全可信。
低存储的应用部署思路
本质来说，低存储方案中应用部署相比正常方案中并不具有相对更多的限制。但是若是需要最大程度地发挥其中优势，则需要更好地对应用进行筛选。
首先，最佳效果之下，信息应当存储于各个账户的状态之中。如此便可直接摆脱UTXO货币在导入新私钥时，或是创建账号地址时，不得不通过P2P网络将所有区块同步之后才能安全进行其余例如交易等操作的这一困境。这对于数字货币钱包来说，是加强了其易用性，几乎能够直接在打开瞬间开始进行操作。且摆脱了SPV协议轻钱包。由于SPV钱包不能检查区块上任意其他的交易，理论上讲，区块就有可能是无效的。而且spv协议往往指向一个中心服务器，这可能被重定向到一个恶意地址，给用户带来财产损失的风险。这对于如以太坊这类的应用入口来说，更可以大大加快应用开发速度，加快应用加载速度。
其次，尽可能地删除不必要的旧区块。在过了可信高度，即几乎所有节点的区块链存储都高于某一高度一定高度之后，区块链系统完全可以将某一高度前的区块进行删除来达到节省存储空间的目的。因为首先数据我们是选择存储在各个账户状态之中，换句话说就是即便删除了历史的区块也不会造成信息的损失。其次我们所有节点都在这“某一高度”上方，我们在这“某一高度”上达成了共识，即每个节点在“某一高度”之前的区块都是完全相同的，之后的区块的merkle树或trie树都可以在这“某一高度”开始进行，不必强制从创世区块开始。对于这之前的区块，已经无特别重要的作用，当然对于存储空间足够的设备来说依然可以保留这些区块，但是对于空间较小或者更加集约的环境下，将这之前的区块删除应当是最为正确的操作。
再者，必须限制账户、事务的膨胀。首先，区块的大小和事务数量有直接关系，因此中本聪利用了fee也就是手续费概念，fee的竞争以及区块打包交易上限增加了事务进入系统的成本，以此来防止事务的过度或恶意的膨胀。
其次由于新的区块链中选择将信息存储于账户之中，因此在打包账户时账户数量和使用存储量有直接的正比关系
倘若不限制账户数量，依旧和比特币一样提供无限的基于私钥与ECDSA椭圆曲线数字签名算法生成的账户地址，那么存储量很容易脱离监管。例如可能有人恶意地通过给许多未在网络出现的地址发送事务，强制增加了许多新的账户，那么在该网络下：
而为了交易的速度，我们往往在一个区块中打包许多事务。如比特币中，一般一个交易（事务）在250字节左右，扩容前1M大概就能容纳4000多笔。
即每次都需要增加整整4000k大小存储空间，而由于在攻击下，大部分账户不具有真实性，并不真正被他人使用，即很可能这4000k大小将是无用的。随着时间推移以及区块高度增加，在攻击之下的真实账户所占空间增长缓慢，无用账户所占空间却越来越多，最终和改良前无用区块冗余的状态一致。即无法达到限制膨胀，无法将其应用于多设备尤其是类似物联网的场景之中。可见限制账户与事务非常有必要。
项目案例
实际工程项目中可能涉及工地环境，计算机环境以及经济环境等等具有非常鲜明特点且各不相同的方面。
因此，区块链在工程的每个部分中的应用都有所不同。但是在大多数场景中，我们都可以将其功能与需求部署在区块链中，从最基本的可信数据存储的基础之上开始向上增加特性。
应用概述
本案例从事务存储角度进行，假设进行的是一个混合了高频率的物联网监管信息监管以及企业间合约的共识化
首先，我们通过定义一系列参数为常见数字货币公有链中内置参数，来模拟通用状态下，基于状态的理论低存储非膨胀方案相比原始中本聪论文内方案在存储上的差异。
其次针对工程设计与安全责任的监控项目的低存储区块链化的目标设定相关内容，进行实验
最后根据工程合同的低存储区块链化来制定另一实验。
不同的区块链底层设计
首先，基于Python，我们可以从中本聪（Satoshi）论文中轻易地制作一个基本的区块链模型。
为了快速地实现多层的区块，我们可以将其中繁杂的工作证明、密钥交换、交易签名等安全细节删去。最终我们生成一个较为简易但具有完整的在挖矿成功后建立新区块并对数据进行存储的功能。
然后我们再建立一个基于状态的区块链系统。除了Block区块以外，我们还需要一个新的对象——该对象需要保存一个时间点上的账户状态信息以及之前历史区块信息，同时它也和传统的区块一样能够通过散列值来形成一个链。如前文介绍中简写，该“状态区块”也可以叫做Generation（代）。同样地为了测试我们将其中繁杂的工作证明、密钥交换、交易签名等安全细节删去，将判断可信高度的方法简便化。但是依然保留状态区块链之中删除历史区块的功能。
最终我们再写一个程序，通过该程序我们能对两个系统进行“挖矿”操作。简单来说，该程序能够在两个系统之中分别注入相对相同的事务信息，并不断激活两者新区块打包存储功能。在这个过程之中，两个不同的区块链系统会用两者不同的方式打包交易。但是，状态区块链除了单纯的打包储存以外，也会将交易信息在生成状态区块的过程中归纳进账户信息之中，在每个可信高度之后追加一个包含当前时间点链上所有账户的“状态区块”，并删除可信高度个“状态区块”之前的过久的区块。
公平起见，所有写入区块的交易本质相同，唯一不同在于低存储区块链中为数字（账户编号），传统区块链之中为对该数字进行类比特币地址生成方式处理（即sha256计算散列后将该值进行base58加密）后得到的地址。
此外，我们还可以通过修改模拟生成的交易内容来控制对实验内容的模拟。
在工程设计与安全责任的监控项目的低存储区块链化中，大部分事务是由物联网设备的工作证明与工作状态构成。这里的工作证明和传统的数字货币的工作证明挖矿是有些许区别的，工作内容不再是通过计算无意义的散列值，而是根据工程环境进行定制。例如在我们假设的传感器监控环境之中，所有进行正常工作（搜集数据，打包数据，分析数据等等）的时间都可以被视为其工作，而其对于每个时间段进行的工作总结即为工作证明。换句话说，我们是摆脱了账户间交易，或者说是只考虑工作证明并没有其他账户之间的交易，即我们可以选择将事务发送目标与发送货币数量字段都设置为空且增加可能的账户数（通用场景中设为100，在多设备的监控环境之中设置为10万，即100000）。对应的，又由于高速出块，我们将可信高度也拔高数倍（10000）。
在工程合同的低存储区块链化项目之中，往往参与账户相对较少（100），企业之间即合约内的总代币量不变。公司（账号0）为总发包方，即最终的代币兑现方，在初始即创世区块中账户就具备该代币量。其他各个承包方与“0”公司，或承包方之间，进行代币交易并在交易内签署合同落实细则来实现现实中项目转接或合同内外事件的发生。该场景下对于共识中区块生成条件没有额外要求，但是在最优情况下，应当结合底层设施，或者底层人员，对于项目工作落实的监测与管理汇报，在与实际工作相有机结合之后来实现上层管理（合约）与下层劳动的联动。在保证工作基础上，透明化联盟内合作企业之间关系，真正实现付出换来收获，也最大幅度地扩大各企业效益。
模拟数据
通过Python制作的相关应用，我们可以得到各方案在区块存储方面随着区块高度逐步增加而变化的状况。我们将数据再次用Python清洗整理后，通过JavaScript配合Echarts进行渲染，我们即可得到可视化的数据图。
最终我们能够得到对比结果
具体的，对于传统区块链的存储使用情况如下：
对于状态的低存储区块链模型在使用中存储情况如下：
首先我们录入的数据分为两种。
第一种工程设计与安全责任的监控项目的低存储区块链化中，与第二种在工程合同的低存储区块链化项目之中，我们得到的结果都和通用情况下结果相近。
更详细实验与后续分析请见最上面PDF