前言：关于区块链适合做什么和不适合做什么？一直都有争议。那么，通过什么方式来辨别呢？本文用详细的流程图来应对这个问题。本文作者是Mohammed ElSeidy，由“蓝狐笔记”社群的“鑫鑫”翻译。
围绕区块链的大肆炒作严重夸大了这项新技术的实际能力和应用。这种狂热使得企业、开发者和投资人难以理解其实际的局限性并找出适合区块链或者分布式账本技术的正确应用场景。
来自ETH Zurich的Karl Wüst和Arthur Gervais最近发布了一份同行评审论文，它提出了一种结构性的方法，该方法有助于确定特定应用问题应该如何解决的合理技术方案。本文中，我们将介绍这种方法并解释论文中的用到的一些例子。
技术对比
区块链是一种持久化（保存）状态的”仅可添加”的账本。状态可以是交易信息，程序数据，或者哈希过的文档等等。基本上，就是任何需要持久化存储的信息。数据库担当这项任务已有几十个年头。此外，区块链代表了一种新的状态持久化技术——并且包含数字签名和防篡改在内的额外特性。让我们来重新审查一下三种主流技术：
1.数据库
首先，数据库（单个，并行，或者分布式）被用于持久化状态和查询数据已经有几十年历史。大量有价值的研究已经被用于优化不同层级的查询处理和状态持久化上。
• 自然地，在交易吞吐量和查询延迟方面它们拥有最高的性能。
• 然而，一直以来，它们被设计为单一机构的中心化管理。因此，不同参与方之间不需要共识机制。
2.公链（Permissionless Blockchains）
公链是不受中心化机构管理的公共账本（状态）。也就是说，账本分布在一个动态P2P网络中，网络中可能还会有恶意的节点。
• 中本聪的智慧在于设计了一种分布式状态上维持共识的机制，且是在动态和不可信的网络中实现的。这意味着公链可以容忍网络中包含少量拜占庭或不可信行为。
• 凡事都有代价，需要在性能消耗（吞吐量和延迟）上有所取舍。在比特币中，急剧的性能下降是由于POW协议本身的设计就非常慢。和普通数据库相比，在任何公链中，性能的下降都是不可避免的。因为不管怎么样，要维护分布式状态的一致性，（地理分布）网络中的不同节点之间就必须进行通信。
3.联盟链（Permissioned Blockchains）
联盟链代表了一种混合式的设计选择。特别的，他们不是单一的中心化实体，而是授权给一小部分预先选定可以写入状态的可信节点。
• 由于数据库网络不会扩展到大量的公共节点，和公链相比，它的吞吐量和延迟要好得多。
• 尽管如此，它的性能仍然无法跟一个中心化数据库相匹敌。
在看完这些不同系统之后，我们很容易认识到没有一个适用于所有场景的方案。任何事情都需要有所取舍。不同的应用有不同的需求，因此需要不同的合适的解决方案。
“你需要区块链吗？”流程图
选择正确技术方案的流程图。TTP（Trusted Third Party）代表可信第三方，writer是一个可以写入状态到数据库或者区块链的实体。
这一节描述了论文中一个通用的高层次流程图，用于为你的应用寻找合适的技术。注意writer是一个可以将状态写入数据库或区块链的实体。
1.如果你的应用不需要持久化状态，那么很明显不需要区块链或者任何数据库。
2.类似的，如果只有一个写入状态的writer，那么和常规数据库相比区块链并不能提供额外的保障。相反，从性能角度来说数据库可能更加高效。
3.否则，如果有超过一个写入状态的writer，我们选择另外一条路径。问题变成了是不是有一个在线TTP（可信第三方）就足够了，或者换句话说，是否需要防篡改。如果应用不能依赖单一可信实体，我们可以进一步分析是否需要区块链。否则，不需要用区块链，从性能角度来说依赖一个中心化实体更加高效。
4.下一个问题是”所有写入状态的writer的身份是否可知？”。如果由于身处不可信的动态网络因而身份不可知，比如互联网，那么公链是合适的选择。
5.否则，如果身份是可知的，那么下一个问题是”这些writer是否彼此信任？”。如果是，那么也不需要区块链，使用提供共享写入权限的数据库就足够了。否则，如果writer们不信任彼此，那么最合适的技术是联盟链。
6.最后，如果是联盟链，取决于是否要求公开可验证性，允许任何人读取状态（公开联盟链）或者只有少部分受限的用户（私有联盟链）。
应用实例
让我们通过一些例子来理解什么应用确实需要区块链，哪些不需要以及为什么不需要。
不需要区块链的应用
• 供应链管理（SCM）：这的确是一类反复出现的应用。让我们按照流程图来找出最为匹配的技术。
1.SCM确实需要存储数据。
2.涉及多个writer，即拥有最终产品的某些部分的不同参与方。
3.继续我们的方法，SCM在技术上很可能总是使用一个在线TTP。例如，Skuchain承认只需要单一的信任源，然而这就去除了区块链的去中心化成分，因此它等价于一个可信的中心化服务器。
4.如果那样做不可行，至少所有的writer是可知的，这样留给我们的只有联盟链或者不使用区块链这两个选择。
5.SCM在数字和物理世界之间的接口存在一致性问题。通常需要人或者某些受单一writer控制的机器来登记到达仓库的某个商品，如果质量没有问题的话。如果这些雇员的操作是不可信的，那么整个供应链就是一种技术上的妥协，因为恶意writer可以提供任意数据。从另一方面来说，如果所有的writer们都是可信的，那么就不需要区块链，因为使用一个提供共享写入权限的常规数据库即可。
注意如果通过一些技术手段，数字和物理世界之间的连接可以通过一种安全的方式实现，那么前面的论证可能会发生变化。
• 物联网：很多人提出了区块链技术在物联网（IoT）上的可能使用场景，通过智能合约来为资源的消费和供给的支付提供一个自治系统。由于系统固有的去中心化特性，实体们彼此互不信任，使用区块链似乎很自然。
然而，和供应链管理一样，物理和数字世界之间的接口造成了潜在的问题。如果计算机把从传感器中读到的数值提供给区块链，区块链无法保证这些数值的正确性。如果只是需要自动化，没有必要使用区块链，可以用一个可信方来代替。
适合使用区块链的应用
跨行和跨境支付：对于金融应用，一般来说区块链技术非常合适，因为参与方通常都希望规避风险并且不想依赖强信任假设。
1.在跨行支付中包含多方（银行）担任的writer及想要交换价值和交易的主体。因此状态需要被持久化。
2.银行都是writer，因此有不止一个writer。
3.在单币种系统中，中央银行可以作为TTP。
4.否则，还有一种配置，中央银行不想担任每笔交易的验证者，只想作为一个认证授权机构给银行们发放牌照，让它们参与到系统中来。这意味着系统的所有writer都是可知的，我们可以使用联盟链。
• 贸易和公平交易协议：类似的，数字商品的交易很可能不需要一个可信的争端调停者，因此非常适合使用区块链，而物理商品则仍然需要可信第三方来解决争端。
• 电子投票：类似的，电子投票也具有区块链可以派上用场的属性。例如，一方面，隐私是一个主要需求，因为投票必须是匿名的从而避免被胁迫。另一方面，电子投票需要提供一定的公开可验证性。由于有这些需求，使用区块链来帮忙获取这些渴望得到的属性似乎是合理的。
结论
和传统观点相反，区块链不是一种能解决所有技术问题的方案。实际上，它们更适用于满足一组要求的某一类应用。特别是那些宁可牺牲性能来换取去中心化和防篡改的一致性状态的应用。
尽管如此，目前很多”承诺的”应用仍然不适合使用区块链，比如供应链管理。在遇到那些狂热的开发者和那些跟风炒作并且不真正去思考他们方案的底层技术和必要性的企业家们时，我们需要保持警惕。
到现在为止，有信任需求的数字商品和服务似乎是最适合使用区块链的应用场景。