李笑来最“正经”的一条微博，却鲜有人留意它对行业的重大影响

作者 | 孙副社长

作为区块链领域的早期投资者，李笑来毫无疑问是这个领域长盛不衰的IP。即便是现在这个熊市，他的微博仍然吸引了不少的转发、评论和点赞，尽管近期的微博绝大多数与区块链无关。

但是，10月7日下午，李笑来却转发了一条极为“技术流”的微博：

“一个高效，但超级节省空间的UTXO验证方案（可以实现存在验证和排除验证），昨天由斯坦福Benedikt提出。”

对于比特币矿工而言，如果要挖矿，就要下载比特币客户端，而比特币客户端超过160G。如果是基于比特币网络的DApp开发者，选择全节点数据作为开发的基础设施，那他也要下载超过160G的比特币客户端。

这条微博里提到的UTXO，主要作用是计算余额和验证新的交易。比特币客户端之所以如此庞大，就是因为

比特币的UTXO集庞大

。斯坦福的这项技术，如果成功，就可以把比特币的客户端大大压缩存储空间，实现质的飞跃。

所以说，这条转发的微博状态，是李笑来最近发布的、最有含金量的一条微博，只可惜并没有引发太多的关注度。从下面的评论来看，也都是“没看懂”、“不明觉厉”这样的表态。

正因为如此，鲜有人意识到，这条新闻，可能会对区块链行业产生重大的影响……

01

庞大的全节点客户端

先给一些不太了解相关概念的朋友具体解释一下：以比特币为代表的UTXO空间问题是怎么让人们感到纠结的。

今年年初，三点钟群“忽悠”大家All In区块链之后，一些传统行业的成功人士真的入场了。出乎很多人的意料，他们入场的方式并不是投资数字资产，而是想要挖比特币，毕竟对于传统行业的人来说，没有什么比设备和厂房那一堆堆的固定重资产更能让他们安心的了。

既然想挖矿，就要下载比特币客户端，尤其是这些成功人士还特别想要打造自己的品牌，当独立矿工。然而，开始下载比特币全节点客户端的时候，他们几乎全都愣住了——因为比特币的核心客户端，大小有160G。

160G是一个什么概念？160G可以存放80多部高清电影，或是2.7万首音乐，或是5万多张手机拍摄的照片。

所以说，走到这一步时，几乎每一个比特币新粉看到这个数字，都是各种不解：我为什么要下载多达160G的客户端？毕竟，下载这个大的东西可不是闹着玩的，硬盘容量够不够先不说，就下载所用的时间，可能就需要好几天，尤其是很多朋友所在的城市网速并不快。

其实，比特币独立矿工之所以需要下载160G的客户端，除了客户端一些必要的功能之外，还有另外一个至关重要的原因：验证UTXO集。

02

UTXO集到底是什么？

关于UTXO这个词，相信很多朋友都听过一句“咬文嚼字”的话：

世界上根本没有比特币账户，只有UTXO。

这句话隐含的意思是：要是实在理解不了UTXO，就干脆把它当做比特币账户来理解也行，因为这两者真的很像（虽然在技术上并不能划等号）。UTXO 是 Unspent Transaction Output的缩写，翻译成中文是未花费的输出。

UTXO集，就是所有UTXO的集合。比特币的客户端之所以如此庞大，就是因为要给这些UTXO集合做担保，确保每笔交易中的输出地址中有足够的UTXO来满足交易条件。这就好比很多企业的关键岗位需要保留员工的档案，只有确保他们的过往经历没有出现过大的差错，才敢让他们上岗就业一样。就某种意义上讲，比特币的客户端，装着的就是现在网络上这些UTXO的历史档案。

然而，问题在于：如果工作单位里有几个、几十个、甚至是几百个员工也就算了，但若是几万个、几十万个员工呢？这资料的规模又得有多大啊？

所以，我们可以看到，很多机构的档案库，里面的资料都是堆积如山。而比特币也是这样——斯坦福大学提供的数据显示，现在比特币全网大约有6000万个UTXO，而他们的所有历史数据，加起来正是160G。

注：最新消息显示，比特币的客户端已经突破200G，斯坦福大学的数据可能略有落后。

从当下的情况来看，UTXO集的快速膨胀，直接导致了一个关键的问题：全节点的运行成本越来越高。

在2014年年初，比特币的客户端总共也不过20G，一台台式电脑就能当记账节点，独立矿工遍地走。现在，随着客户端容量的膨胀，运营一个全节点的成本越来越高，已经远非普通的个体所能胜任。所以最近几年，比特币的全节点日趋减少，比特币“越来越中心化了”。

比特现金的出世，更是引发舆论抗议，认为大区块只会导致全节点运营成本的提升，从而导致区块链的中心化。

（图：不断膨胀的UTXO规模）

斯坦福方面的技术，正是针对这个问题所提出的。

03

从160G到1.5K！DApp开发的福音来了？

斯坦福方面所称，他们希望通过一项名为“RSA累加器”的技术，来替代现有的、基于默克尔树的UTXO验证方案，从而用1个只有1.5KB大的区块，就可以证明所有的UTXO集是否可以满足交易的条件。

老实说，看到这里，笔者个人是有点不太敢相信自己的眼睛——160G的数据包，就这么被压缩了？

严格来讲，在此之前，并不是没人研究过压缩比特币全节点数据包的事情。无论是早先的Mimble-Wimble，还是后来BCH社区提出的“UTXO Commitment”，做的其实都是这件事。但前者只将全节点数据包压缩了68%至50G，后者则压缩了约98%至2G，然斯坦福大学这一次居然将其压缩了约99.999%，到了1.5KB……

从这点来看，笔者对这项技术还持观望态度，毕竟区块链行业之前也曾放过“百万TPS”的卫星，具体能够落实到什么地步，还有待于实践的进一步验证。

但是，即便斯坦福方面成果大缩水，最终只能实现1.5GB，都堪称区块链行业一个明显的进步，因为对区块链全节点UTXO集的压缩，将会引发一个非常正面的效应：可能促进使用UTXO模型公链上的DApp数量激增。

看到这里，很多朋友可能并不明白：这玩意怎么还和DApp联系起来了？

相信很多读者都知道，DApp通常都是基于某条底层公链开发的。但是有没有人想过：基于XXX链开发应用，到底是怎么一个流程？具体来说，有两种开发路线：

走全节点路线：要下载底层公链的全节点数据，作为开发的基础设施，然后开工；

走轻节点路线：不用下载全节点的海量数据，只要基于轻钱包的基础设施就可以开工；

很显然，从表面上看，稍有常识的人都会选择路线2——在钱包上开发，毕竟全节点占用的空间实在是太大了，况且未来的区块高度还会不断增加，再过两三年的功夫，没准直接突破1T。

然而，事实证明，任何形式的偷懒，最后都会以某种形式反弹到自己身上。DApp的开发也不例外。对于众多的DApp开发者来说，下载底层公链的全节点客户端固然前期成本较高，但好处在于：前期花功夫，后期就省事——由于必要的基础设施都已经被下载到了机器中，所以基于庞大的“全节点客户端”开发DApp，是工作量最少的一种开发模式。

对某些公链来说，只要掌握比较通用的C语言，就可以上阵开发智能合约。至于其他的麻烦事（诸如阅读源码、整合代码），基本都不用做。

而基于钱包呢？固然不用去下载几百G的历史区块（这个过程通常需要几天甚至十几天），启动也相当快捷。然而，前面省事，后面就要吃苦。事实证明，基于轻钱包开发DApp的工作量和工作难度都相当之大，因为很多的基础设施层（包括后台统计程序和API）都需要自己搭建。

从实例来看，如果开发团队没有两把刷子，就给扔到钱包模式里，那他们摸索的过程可能就得几个月，仔细一算，竟然还不如下载全节点客户端来的省时间。

从这点我们可以看出，当下DApp的开发，真不是一件容易的事。对于开发者来说，要么忍受几天十几天的客户端全节点下载，要么忍受基础设施简陋无比的钱包。

可以说，除了对DApp特别有执念的团队之外，基本没人愿意去做这种没流量、没现金流的事情。这也是我们目前所看到DApp特别少的一个重要原因：开发环境真的不是特别友好。

在这样的情况下，包括斯坦福大学本次的成果在内，任何能够削减全节点客户端容量的努力，都是值得肯定的，因为它们都是为DApp的落地做出了一份贡献。虽然不敢说是多么重大的突破，但毕竟证明了区块链技术目前一直在进步。

只不过，如此耐嚼的新闻热度却这么低，多少还是有点让人唏嘘。毕竟去年此时，行业的口水战多少还围绕着“大区块、闪电网络、隔离见证”等技术话题展开，今年却真的只剩下人物八卦了，也许大家真的积极践行“币圈就是娱乐圈”。

不过，正所谓娱乐工作两不误，该打起精神的时候，还是得关注一下有点干货的新闻。毕竟，引得众人为之“All In”的区块链行业终究不是娱乐文艺圈。

一个离钱这么近的行业，起码的“逼格”还是要有一点的