区块链不适用的若干场景
这三个问题可以帮你避开不实宣传。
区块链
这三个问题可以帮你避开不实宣传。

> 
> 这三个问题可以帮你避开不实宣传。
> 
> 
> 


![](/data/attachment/album/201804/10/160115nbh05s7q56psbzag.jpg)


不错，“区块链”这个概念异常的火热。


众所周知，我一直关注区块链及相关技术的成熟度发展情况，思考我们是否对其评价过高了；但从目前的情况来看，还没有这个迹象。我在文中提到的区块链技术是广义上的，包含了狭义上不属于区块链的分布式账本技术（DLT）。我对私有链permissioned blockchain更感兴趣，其中私有链的定义可以参考我的文章《[区块链是安全性方面的话题吗？](https://opensource.com/article/17/12/blockchain-security-topic)》。简而言之，我对加密货币之外的区块链业务应用特别感兴趣<sup> <a href="#footnote1">  注1 </a></sup> 。


我们对区块链的技术成熟度的判断应该有一部分可以得到证实<sup> <a href="#footnote2">  注2 </a></sup> 。如果我们判断正确，未来将会出现海量的区块链应用。这很可能会变成现实，但并不是所有的应用都是优秀的区块链应用，其中一部分很可能是非常糟糕的。


但区块链所处的技术成熟度意味着，大量业务将快速拥抱新技术<sup> <a href="#footnote3">  注3 </a></sup> ，但对于可能的前景却一知半解。促成这种情况的原因可以大致分为三种：


1. 对于涉及多用户数据存储的业务应用，在投入精力的情况下，几乎都可以改造为基于区块链的版本；
2. 很多区块链相关的会议和“专家”呼吁尽快拥抱区块链，否则可能会在半年内被淘汰<sup> <a href="#footnote4">  注4 </a></sup> ；
3. 完全理解区块链技术是很难的，支持其在企业中落地的往往是工程师。


对于最后一条，我必须补充几句，不然很容易被引起众怒<sup> <a href="#footnote5">  注5 </a></sup> 。作为一名工程师，我显然无意贬低工程师。但工程师的天性使然，我们对见到的新鲜事物（亮点）热情澎湃，却对业务本身<ruby> 深入 <rt>  fully grok </rt></ruby><sup> <a href="#footnote6">  注6 </a></sup> 不足，故对于新技术给业务带来的影响理解可能并不深刻。在业务领导者看来，这些影响不一定是有利的。


上面提到的三种促因可能导致一种风险，即在没有充分评估利弊的情况下，将业务改造为区块链应用。在另一文（[区块链：每个人都应该参与进来吗？](https://aliceevebob.com/2017/09/12/blockchain-should-we-all-play/)）中提到几个场景，用于判断一个业务什么情况下适合采用区块链技术。这些场景是有益的，但更进一步，我坚信人们更加需要的是，业务完全不适用区块链的几种简单的场景判定。我总结了三种场景判定，如果对于其中任何一个问题你给出了肯定的回答，那么很大概率上区块链不适合你。


### 场景判定 1：业务是否需要集中式的管控或授权？


如果你给出了肯定的回答，那么区块链不适合你。


例如，假设你是一个普通销售商，具有唯一的订单系统，那么对于何时发货你有唯一的授权，显然区块链不适合你。假设你是一个内容提供商，所有提供的内容都会经过唯一的编辑和发布过程，显然区块链不适合你。


**经验总结：只有当任务对应的执行流程及相应的认证流程是分布于众多主体时，区块链是有价值的。**


### 场景判定 2：业务使用经典数据库是否工作良好？


如果你给出了肯定的回答，那么区块链不适合你。


该场景似乎与上一个场景是强相关的，但并不总是如此。在一些应用中，处理流程是分布的，但信息存储是中心化的；在另外一些应用中，处理流程需要中心化的授权，但信息存储是分布的，即总有一个并不是分布式的。但如果业务使用经典数据库可以工作量良好的话，使用经典数据库是一个好主意。


经典数据库不仅性能良好，在设计与运营成本方面低比区块链或分布式账本，而且我们在这方面技术积累丰厚。区块链让所有人<sup> <a href="#footnote8">  注8 </a></sup> 可以查看和持有数据，但间接成本和潜在成本都比较高昂。


### 场景判定 3：业务采用新技术是否成本高昂或对合作伙伴有负面效果？


如果你给出了肯定的回答，那么区块链不适合你。


我曾听过这种观点，即区块链会让所有人获益。但这显然是不可能的。假设你正在为某个流程设计一个应用，改变合作伙伴与你及应用的交互方式，那么你需要判断这个改变是否符合合作伙伴的想法。不论是否涉及区块链，可以很容易的设计并引入一个应用，虽然降低了你自己的业务阻力，但与此同时增加了合作伙伴的业务阻力。


假设我为汽车行业生产发动机配件，那么使用区块链追溯和管理配件会让我受益匪浅。例如，我可以查看购买的滚珠轴承的生产商、生产时间和钢铁材料供应商等。换一个角度，假设我是滚珠轴承生产商，已经为40多个客户公司建立了处理流程。为一家客户引入新的流程会涉及工作方式、系统体系、储藏和安全性标准等方面的变更，这无法让我感兴趣，相反，这会导致复杂性和高开销。


### 总结


这几个场景判定用于提纲挈领，并不是一成不变的。其中数据库相关的那个场景判定更像是技术方面的，但也是紧密结合业务定位和功能的。希望这几个判定可以为区块链技术引进促因带来的过热进行降温。


* 注 1. 请不要误解我的意思，加密货币显然是一种有趣的区块链业务应用，只是不在本文的讨论范畴而已。
* 注 2. 知道具体是哪些部分是很有意义的，如果你知道，请告诉我好吗？
* 注 3. 坦率的说，它其实更像是一大堆技术的集合体。
* 注 4. 这显然是不太可能的，如果被淘汰的主体是这些会议和“专家”本身倒十分有可能。
* 注 5. 由于比方打得有些不恰当，估计还是会引起众怒。
* 注 6. 我太喜欢 grok 这个单词了，我把它放在这里作为我的工程师标志<sup> <a href="#footnote7">  注7 </a></sup> 。
* 注 7. 你可能已经想到了，我读过*Stranger in a Strange Land*一书，包括删减版和原版。
* 注 8. 在合理的情况下。


原文最初发表于[爱丽丝, 夏娃和鲍勃 – 一个安全性主题博客](https://aliceevebob.com/2018/02/13/3-tests-for-not-moving-to-blockchain/)，已获得转载许可。




---


via: <https://opensource.com/article/18/3/3-tests-not-moving-blockchain>


作者：[Mike Bursell](https://opensource.com/users/mikecamel) 译者：[pinewall](https://github.com/pinewall) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

