作为一种去中心化的信任解决方案，区块链通过在每一个共识节点中对数据库进行备份的形式实现了基于共识算法的全局可信。然而，为了建立这样的一个全局可信基础，每一个节点都必须维护所有的链上的数据。这在区块链运行早期并没有太大的问题，彼时的比特币网络效率低下，数据量增长缓慢，每个节点需要维护的数据很少。但是随着时间的推移，新的区块链项目效率不断提升，共识周期不断缩短，期维护的数据量也是指数型增长，维护一个完整的区块链变得越来越难。对于一个普通用户来说，为了使用区块链而同步几十甚至上百G的链上数据是不可接受的。于是大部分的普通用户都选择直接向已有的区块链全节点进行查询。但是这样就会面临一个问题，我们如何验证从全节点获取到的数据的真实性。
瘦身的大象：简单支付验证协议（SPV）
当然，比特币之父的中本聪大神在创建区块链之初就已经预见到了这样的问题，并且提出了一个高效的解决方案，那就是简单支付验证协议（Simplified Payment Verification。 简单交易验证协议的意思就是对于很多的节点来说，他并不关心和自己需要的交易无关的链上数据，因此它不会去同步整个区块链，而是只同步并保留区块的头部，由于区块的头部已经保存着完整的共识信息，因此仅仅获得并验证区块链中区块的头部是获取当前区块链的运行情况。对于用户想要知道的具体的交易，则可以通过具体的SPV的协议来获取可验证的数据。SPV的提出使得区块链系统对于用户更加友好，它将比特币原本需要同步的数据从数百G瘦身到了几十兆。
瘦身的大象依然是大象
然而，SPV对于一般节点区块链同步数据的瘦身属于一种线性的瘦身，随着区块链数据本身的爆炸性增长，区块链头部也会跟着以一定比例增长。这对于比特币来说不是问题，至少目前来说比特币的头部只有几十兆，远远不足于对普通用户的数据同步产生困扰，然而对于别的高效的区块链系统来说则就是灾难了，比如以太坊的头部是4-5G，NEO仅仅是头部的定长数据也已经有400-500 兆的大小，更可况未来的NEO3更是要数百倍的提升链上效率，到时候的数据量恐怕没有多少的用户可以接受。那如何解决这样的问题呢？
火柴盒里的大象
在2020年的计算机顶会S&P上有人就提出了一个很高效的解决方案，他们称之为FlyClient，超级轻量级的节点，轻到可以飞到天上去。先看一下它需要的数据量： [image:493FADE7-078D-48C9-B1A8-0C18B0156EB6-1885-00012FC30C9D4517/Screen Shot 2020-05-31 at 11.06.01 AM.png]
就看看这个数据量，不仅比SPV更加节省空间，而且是区块链越大，FlyClient越高效，哪怕是7百万的区块高度，也仅仅需要500k的验证数据，从数百G到几百K，完全实现了把一头大象装在一个小小火柴盒里随身携带的梦想。原因就在于FlyClient是针对区块链头部又用Merkel Tree进行了指数级别的组织管理，因此在向全节点进行验证的时候，连区块链头部都不需要再进行同步，而仅仅需要少量的几个在结构上相关的区块链头部进行同步就可以了，这个数据量是log(n)。我们这里不对技术细节进行探讨，感兴趣的可以去看论文。
NEO的超轻量级交易验证
膜拜完别人的火柴盒，我们再回到NEO。当然，直接迁移FlyClient到NEO也未尝不可，但是这种直接迁移来的技术并不能完美的适配NEO的系统，毕竟相对于以太坊，NEO是有很多独特的特征的。
打开NEO Tracker Blockchain Explorer & Wallet，你可以很明显的发现在validator的列表里，所有的地址都是一致的，这是因为这个地址是根据所有的议员公钥而构造的多签地址，除非议员列表发生变更，否则这个地址一直不会变。
现在我们再回顾轻量级节点需要SPV或者FlyClient的原因，是因为轻量级节点从全节点获取交易信息，但是又不想信任全节点，需要能够验证获取到的交易信息的真实性。那在NEO系统里，我们是不是可以利用这个Validator地址来做验证呢？毕竟Validator确定为真实的话，一个区块的合法性我们就可以通过验证这个区块附带的议员签名来保证区块的真实性。
那我们现在把注意力放在这个Validator上，validator是基于议员生成的，而议员的变动也是基于打包到区块链上的交易而进行的。因此当前的validator一定是可以在区块链上追溯到整个列表的变化过程，这个变化过程全程的每一个相关区块都拥有着可验证的议员的签名来验证变化的真实性。因此，我们可以在获取目标数据的同时，也额外的向全节点请求所有的涉及到Validator变化的区块来进行验证。
这样的协议当然会比FlyClient需要更多的数据来验证，毕竟随着时间的推移，NEO的议员节点肯定也是变来变去的，这样就会导致验证的过程中需要的区块越来越多，但是这个数据量首先是跟区块链本身的数据爆炸没有关系的，其次由于Validator在NEO系统中具有一定的稳定性，用户完全可以不需要基于一个早期的Validator来一路追溯，而是自己记下一个最近的已验证过的Validator。如果这个validator已经是过去的，那么再请求基于这个validator之后涉及到议员变化的区块就好了，而不是从创世区块开始。这样在验证交易的时候需要的数据大概率会比FlyClient更少。