更好地构建：区块链用例的简单指南

根据德勤最近的一项研究显示，在过去两年中创建的26,000个区块链项目中，92%已经死亡。

在第一次听到这个消息后，我不得不问自己：这个数字是如何失控的?

本文试图清楚地说明导致此问题的原因，旨在帮助我们热情的区块链爱好者避免启动成为92%的一部分的项目。

从头开始构建一个好的区块链用例

对于那些仍然不熟悉区块链功能的基础知识的人，我强烈建议您首先阅读数据区块链去年在伯克利的Ashley Lannquist撰写的文章“ 区块链，密码货币和新的分散经济：第一部分 - 一个温和的介绍 ”。

对于熟悉这个主题的人，我们可以开始深入分析可用于创建有意义用例的区块链核心功能。

分布式账本技术框架

利用分布式账本技术(如区块链)，用户可以创建数据库环境，让多个互不信任的用户交换价值或在没有中央协调员的情况下追加记录。

通过结合密码学和博弈论的概念，区块链消除了对系统信任的需求，确保用户能够透明地与第三方权威机构进行互动。

区块链系统的固有“分散化”非常重要，因为它消除了中央失效点的负面影响：安全漏洞，网络停机或网络中断。此外，只要安全性和活跃性保证完好无损，区块链将消除来自不可靠演员的交易审查或恶意行为网络。

这些分布式账本系统已经在“财务”或“争端解决”等领域成功实施，交易各方历来需要信任中央当局监督交易数据并确保遵守过去的协议。

公司如超级账本创建，旨在分散这些交易的生态系统，主要配套技术，财务和供应链公司的全球业务交易民营企业数据区块链。值得注意的是，这些实现是区块链技术的特例 - 不是普通的 - 例如92%基于区块链的项目迄今未能实现的事实就证明了这一点。

下面是一个流程图，作为希望实施区块链解决方案的人员的清单，以及在跳转到分布式总账技术(DLT)之前应该考虑的步骤。

在决定区块链使用案例时要考虑的标准

确定区块链用例时的清单

1.数据库

首先，当试图建立区块链使用案例时，我们必须问我们是否拥有一个在所有端点基本安全的数据库。

如果我们试图在易受外部世界篡改或改造的系统上实施区块链，我们将失去在系统中拥有无信任和分权的能力，从而导致区块链使用案例相对有限。

这类问题的例子可以在诸如“血钻追踪”等使用案例中看到，公司利用区块链跟踪从生产者到消费者的供应链上合法钻石的流动。虽然区块链可能是追踪与该钻石相关的交易的好方案，但该解决方案仍然对将这些钻石加入区块链系统的员工或节点给予很大的信任。在这种情况下，“数据库端点”并不安全，从而导致困扰区块链使用案例的信任问题。

2.交易者

在使用区块链之前要问的下一个最重要的问题是，是否会有多方协调我们数据库的操作。

如果我们的数据库不需要大量利益相关者之间的协调，并且可以使用一个关键“编写者”的功能，那么我们应该使用集中式数据库。区块链本质上是“分布式账本技术”，如果不需要“分配”数据库的所有权，那么我们应该使用不同的数据库结构。

这一点虽然简单，但在构建优质区块链用例的过程中往往会被遗忘。事实上，像Oracle数据库或 MySQL 这样的集中式软件比现有的分散式区块链系统拥有更强大的交易基础设施，这意味着如果分散化对我们的项目来说绝对必要的话，我们应该只使用DLT。

集中化案例

集中化趋势更加明显的典型例子是现有技术巨头(如Facebook或Google)的用例，他们管理的Exabytes用户数据。

尽管谷歌能够分散用户交易是一件好事，但区块链用例并不合适。这是因为在集中式系统中跟踪信息要容易得多，所有信息都是通过单一点进行的。

集中式系统从根本上说可以比分散式系统拥有更加内聚的内部整合，因此更有可能利用比DLT更大的规模经济。事实上，像Gmail这样的Google产品只能拥有“智能垃圾邮件过滤器”这样的功能，因为Google可以轻松查看几乎所有人的电子邮件。

3.信任

在确定集中对您的用例是否重要之后，询问我们需要信任谁才能使该系统运行以及在违反信任的结果中会发生什么是至关重要的。

在任何集中式系统中，恶意行为都可以以多种形式形成。中央当局不仅可以尝试编辑现有交易，还可以隐藏信息，通过网络报告不一致的交易，或审查用户访问特定交易。如果有任何激励中央当局在我们现有的系统中采取这些行动，我们至少应该考虑在我们的用例中实施像区块链这样的安全措施。

如果用户之间的信任不是一个重大问题，那么可以简单地利用分布式数据库，其中每个用户维护数据库的副本，并且可以随意编辑和更新数据库的状态。由于区块链安全功能(如“拜占庭容错”)(防篡改和不一致)不需要考虑，因此实施起来要容易得多。

特例：公开和授权区块链

Photo by Samson Duborg-Rankin在Unsplash上同样重要的是要注意，有些方法可以利用区块链系统来合并来自集中式数据库，分布式数据库和分布式账本技术的概念。

“ 允许区块链 ”是概念联姻的一个例子，将集中式用户授权与分散式区块链交易生态系统相结合。

通过有能力控制区块链网络上允许的用户，我们能够降低恶意操作的可能性，并增强对系统尝试管理的内容的控制 - 创建一个不需要尽可能多的容错，安全性，并作为传统的“公共”区块链进行维护。

这种区块链结构的不利之处在于它比公共区块链“不可靠”，因为用户仍然必须对授予权限的权限以及系统正在使用的共识机制给予信任。

摩根大通的Quorum机制是一个授权区块链使用案例的典范，因为它们创造了一种产品，通过利用对BFT进行交易的低需求，为金融行业提供高速交易(每秒几十到几百个)允许的一组用户允许(请参阅QuorumChain)。

4.非中介

在着手区块链使用案例之前，确定我们的交易系统是否需要非中介化是非常重要的。

如果我们的区块链前解决方案需要大量的中间商费用或确认时间延迟，区块链自然适合加速此过程，从而降低所有用户的成本。

如果非中介化对我们的交易系统不是必不可少的，那么将验证交易的任务分配给中间人或中央机构就更容易了，从而不再需要区块链网络上的分布式验证器。

目前利用非中介的用例的一个很好的例子是slock.it，他已经围绕创建个性化IOT设备的智能合约的概念构建了数字业务，消除了人为干预或调整的需要。借助slock.it的技术，任何物联网设备都可以拥有自己的身份，并且可以签署复杂的协议(包括接受付款的协议) - 所有这些都不需要使用中介。

5.交易依赖

在实施区块链使用案例之前自问的最后一个问题是我们的交易是否相互依赖。

交易依赖是一种可以在各种数据库系统中看到的特征，特别是在涉及涉及资产或商品交换(如房地产或零售)交易的多方或多个系统的多用户系统中。

如果我们的交易不需要彼此交互，那么利用“主/从”数据库结构会更加有效，其中一个“主”节点充当验证和批准交易的某个子集的支持者“从属“节点执行工作。

如果我们的事务确实相互依赖，那么确定如何在主节点之间分配相应的事务变得非常困难，这导致需要类似区块链来改变数据库的集体状态。

区块链还向其用户提供原子性(防止部分更新数据库的能力)，确保相互依存的交易将立即执行，而不会取消或篡改交易中心。这确保了系统中任何复杂的交易结构都不会造成或破坏财富。

概要

恭喜，我们现在正在努力构建正确的用例!尽管这篇文章存在反向色调，但区块链技术实际上有很多应用可以更好地影响现有的交易系统。然而，在成为这些应用程序之前，重要的是在决定将区块链作为合适的解决方案之前先问自己我们的用例需要运行的功能。

如果我们能够沿着上图流程图前进，我们正在逐步建立完善的区块链使用案例，增加了我们成为区块链项目中能够承受测试的8%之一的可能性的时间。

附录

本文的精神，我认为我会在下面添加一些我最喜欢的区块链使用案例 - 我鼓励大家把它们作为一个练习来思考使用例有价值的因素!

i)Gnosis - 建立在以太坊平台上的分散式预测市场

ii)Blocknotary - 具有时间戳验证的分散式公证服务

iii)Zcash - 开放，无许可的加密货币，使用零知识密码技术充分保护交易隐私。