哪些适合用区块链？哪些不适合？

图片来源图虫：已授站长之家使用

声明：本文来自于微信公众号蓝狐笔记(ID：lanhubiji )，授权站长之家转载发布。

前言：关于区块链适合做什么和不适合做什么?一直都有争议。那么，通过什么方式来辨别呢?本文用详细的流程图来应对这个问题。本文作者是Mohammed ElSeidy，由“蓝狐笔记”社群的“鑫鑫”翻译。

围绕区块链的大肆炒作严重夸大了这项新技术的实际能力和应用。这种狂热使得企业、开发者和投资人难以理解其实际的局限性并找出适合区块链或者分布式账本技术的正确应用场景。

来自ETH Zurich的Karl Wüst和Arthur Gervais最近发布了一份同行评审论文，它提出了一种结构性的方法，该方法有助于确定特定应用问题应该如何解决的合理技术方案。本文中，我们将介绍这种方法并解释论文中的用到的一些例子。

技术对比

不同类型的状态持久化对比

区块链是一种持久化(保存)状态的"仅可添加"的账本。状态可以是交易信息，程序数据，或者哈希过的文档等等。基本上，就是任何需要持久化存储的信息。数据库担当这项任务已有几十个年头。此外，区块链代表了一种新的状态持久化技术——并且包含数字签名和防篡改在内的额外特性。让我们来重新审查一下三种主流技术：

首先，数据库(单个，并行，或者分布式)被用于持久化状态和查询数据已经有几十年历史。大量有价值的研究已经被用于优化不同层级的查询处理和状态持久化上。

• 自然地，在交易吞吐量和查询延迟方面它们拥有最高的性能。

• 然而，一直以来，它们被设计为单一机构的中心化管理。因此，不同参与方之间不需要共识机制。

公链是不受中心化机构管理的公共账本(状态)。也就是说，账本分布在一个动态P2P网络中，网络中可能还会有恶意的节点。

• 中本聪的智慧在于设计了一种分布式状态上维持共识的机制，且是在动态和不可信的网络中实现的。这意味着公链可以容忍网络中包含少量拜占庭或不可信行为。

• 凡事都有代价，需要在性能消耗(吞吐量和延迟)上有所取舍。在比特币中，急剧的性能下降是由于POW协议本身的设计就非常慢。和普通数据库相比，在任何公链中，性能的下降都是不可避免的。因为不管怎么样，要维护分布式状态的一致性，(地理分布)网络中的不同节点之间就必须进行通信。

联盟链代表了一种混合式的设计选择。特别的，他们不是单一的中心化实体，而是授权给一小部分预先选定可以写入状态的可信节点。

• 由于数据库网络不会扩展到大量的公共节点，和公链相比，它的吞吐量和延迟要好得多。

• 尽管如此，它的性能仍然无法跟一个中心化数据库相匹敌。

在看完这些不同系统之后，我们很容易认识到没有一个适用于所有场景的方案。任何事情都需要有所取舍。不同的应用有不同的需求，因此需要不同的合适的解决方案。

选择正确技术方案的流程图。TTP(Trusted Third Party)代表可信第三方，writer是一个可以写入状态到数据库或者区块链的实体。

这一节描述了论文中一个通用的高层次流程图，用于为你的应用寻找合适的技术。注意writer是一个可以将状态写入数据库或区块链的实体。

1.如果你的应用不需要持久化状态，那么很明显不需要区块链或者任何数据库。

2.类似的，如果只有一个写入状态的writer，那么和常规数据库相比区块链并不能提供额外的保障。相反，从性能角度来说数据库可能更加高效。