深入讨论 “验证”

我们现在进入下一个话题，这个话题对轻客户端与分片之类的话题非常重要：验证的时候我们到底是在做什么？要理解这一点，我们需要回到更早的时间点。对于一次攻击，我有以下的偏好顺序：默认造成失败 > 默认导致混乱 > 默认取得成功这里的 “大于号” 意思是前者比后者更优。最优的情况是攻击直接失败，次优的情况是攻击导致混乱，造成大家无法就合法链达成一致，而最坏的情况则是攻击成功。为什么说造成混乱要大大优于攻击成功？这可以归结为激励机制，混乱也会给攻击者带来成本，使他们无法确信攻击能成功，因此能削减攻击者发起攻击的动力。天然导致混乱的环境对攻击者来说，意味着他们需要赢得区块链战争（成功发起 51% 攻击）还要 赢得 “舆论战”，说服整个社区跟进攻击链。相较于仅仅发动 51% 攻击就必然成功，上述情况将使攻击变得异常困难，也没那么有利可图了。进行验证的目标就是让攻击从天然取得成功的状态变为天然失败的状态（最优），或者变为天然导致混乱的状态（次优）。如果你运行一个完全验证所有区块的节点，攻击者试图让网络接受一条规则不同的链，攻击就会失败。如果部分用户运行验证全节点而还有很多人没有，攻击则会导致混乱。但我们还要思考，有没有别的方法可以达到相同的效果呢？

轻客户端与欺诈证明（Fraud Proof）

一个更好的办法自然是使用带有欺诈证明的轻客户端。当前的大多数区块链轻客户端仅仅验证是否大多数矿工都支持特定区块，而不会验证协议规则是否得到满足。这些客户端的正常运行假设了大部分矿工都是诚实的。一旦出现有争议的分叉，这类客户端会天然随大流，用户需要主动采取措施才能留在旧规则下的少数方链上。因此，对于当前的轻客户端发起攻击，攻击者可以天然成功。但有了欺诈证明技术，情况就大不相同了。简单来说，欺诈证明的工作原理如下。通常来说，区块链中的单个区块仅仅会涉及到区块链 “状态”（账户余额、智能合约代码……）的一小部分。如果一个全节点处理完一个区块发现其无效，就可以生成一个数据包（即欺诈证明），并广播给轻客户端。数据包内仅包括该区块及足够处理该区块的数据，轻客户端拿到数据包后则可以自行验证该区块，而无需链上的其他数据。 (责任编辑：admin1)