mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
77 lines
7.0 KiB
Markdown
77 lines
7.0 KiB
Markdown
区块链不适用的若干场景
|
||
======
|
||
|
||
> 这三个问题可以帮你避开不实宣传。
|
||
|
||
|
||
|
||
不错，“区块链”这个概念异常的火热。
|
||
|
||
众所周知，我一直关注区块链及相关技术的成熟度发展情况，思考我们是否对其评价过高了；但从目前的情况来看，还没有这个迹象。我在文中提到的区块链技术是广义上的，包含了狭义上不属于区块链的分布式账本技术（DLT）。我对<ru by>私有链<rt>permissioned blockchain</rt></ruby>更感兴趣，其中私有链的定义可以参考我的文章《[区块链是安全性方面的话题吗？][1]》。简而言之，我对加密货币之外的区块链业务应用特别感兴趣^[注1](#footnote1) 。
|
||
|
||
我们对区块链的技术成熟度的判断应该有一部分可以得到证实^[注2](#footnote2) 。如果我们判断正确，未来将会出现海量的区块链应用。这很可能会变成现实，但并不是所有的应用都是优秀的区块链应用，其中一部分很可能是非常糟糕的。
|
||
|
||
但区块链所处的技术成熟度意味着，大量业务将快速拥抱新技术^[注3](#footnote3) ，但对于可能的前景却一知半解。促成这种情况的原因可以大致分为三种：
|
||
|
||
1. 对于涉及多用户数据存储的业务应用，在投入精力的情况下，几乎都可以改造为基于区块链的版本；
|
||
2. 很多区块链相关的会议和“专家”呼吁尽快拥抱区块链，否则可能会在半年内被淘汰^[注4](#footnote4) ；
|
||
3. 完全理解区块链技术是很难的，支持其在企业中落地的往往是工程师。
|
||
|
||
对于最后一条，我必须补充几句，不然很容易被引起众怒^[注5](#footnote5) 。作为一名工程师，我显然无意贬低工程师。但工程师的天性使然，我们对见到的新鲜事物（亮点）热情澎湃，却对业务本身<ruby>深入<rt>fully grok</rt></ruby>^[注6](#footnote6) 不足，故对于新技术给业务带来的影响理解可能并不深刻。在业务领导者看来，这些影响不一定是有利的。
|
||
|
||
上面提到的三种促因可能导致一种风险，即在没有充分评估利弊的情况下，将业务改造为区块链应用。在另一文（[区块链：每个人都应该参与进来吗？][2]）中提到几个场景，用于判断一个业务什么情况下适合采用区块链技术。这些场景是有益的，但更进一步，我坚信人们更加需要的是，业务完全不适用区块链的几种简单的场景判定。我总结了三种场景判定，如果对于其中任何一个问题你给出了肯定的回答，那么很大概率上区块链不适合你。
|
||
|
||
### 场景判定 1：业务是否需要集中式的管控或授权？
|
||
|
||
如果你给出了肯定的回答，那么区块链不适合你。
|
||
|
||
例如，假设你是一个普通销售商，具有唯一的订单系统，那么对于何时发货你有唯一的授权，显然区块链不适合你。假设你是一个内容提供商，所有提供的内容都会经过唯一的编辑和发布过程，显然区块链不适合你。
|
||
|
||
**经验总结：只有当任务对应的执行流程及相应的认证流程是分布于众多主体时，区块链是有价值的。**
|
||
|
||
### 场景判定 2：业务使用经典数据库是否工作良好？
|
||
|
||
如果你给出了肯定的回答，那么区块链不适合你。
|
||
|
||
该场景似乎与上一个场景是强相关的，但并不总是如此。在一些应用中，处理流程是分布的，但信息存储是中心化的；在另外一些应用中，处理流程需要中心化的授权，但信息存储是分布的，即总有一个并不是分布式的。但如果业务使用经典数据库可以工作量良好的话，使用经典数据库是一个好主意。
|
||
|
||
经典数据库不仅性能良好，在设计与运营成本方面低比区块链或分布式账本，而且我们在这方面技术积累丰厚。区块链让所有人^[注8](#footnote8) 可以查看和持有数据，但间接成本和潜在成本都比较高昂。
|
||
|
||
### 场景判定 3：业务采用新技术是否成本高昂或对合作伙伴有负面效果？
|
||
|
||
如果你给出了肯定的回答，那么区块链不适合你。
|
||
|
||
我曾听过这种观点，即区块链会让所有人获益。但这显然是不可能的。假设你正在为某个流程设计一个应用，改变合作伙伴与你及应用的交互方式，那么你需要判断这个改变是否符合合作伙伴的想法。不论是否涉及区块链，可以很容易的设计并引入一个应用，虽然降低了你自己的业务阻力，但与此同时增加了合作伙伴的业务阻力。
|
||
|
||
假设我为汽车行业生产发动机配件，那么使用区块链追溯和管理配件会让我受益匪浅。例如，我可以查看购买的滚珠轴承的生产商、生产时间和钢铁材料供应商等。换一个角度，假设我是滚珠轴承生产商，已经为40多个客户公司建立了处理流程。为一家客户引入新的流程会涉及工作方式、系统体系、储藏和安全性标准等方面的变更，这无法让我感兴趣，相反，这会导致复杂性和高开销。
|
||
|
||
### 总结
|
||
|
||
这几个场景判定用于提纲挈领，并不是一成不变的。其中数据库相关的那个场景判定更像是技术方面的，但也是紧密结合业务定位和功能的。希望这几个判定可以为区块链技术引进促因带来的过热进行降温。
|
||
|
||
- 注 1. 请不要误解我的意思，加密货币显然是一种有趣的区块链业务应用，只是不在本文的讨论范畴而已。
|
||
- 注 2. 知道具体是哪些部分是很有意义的，如果你知道，请告诉我好吗？
|
||
- 注 3. 坦率的说，它其实更像是一大堆技术的集合体。
|
||
- 注 4. 这显然是不太可能的，如果被淘汰的主体是这些会议和“专家”本身倒十分有可能。
|
||
- 注 5. 由于比方打得有些不恰当，估计还是会引起众怒。
|
||
- 注 6. 我太喜欢 grok 这个单词了，我把它放在这里作为我的工程师标志^[注7](#footnote7) 。
|
||
- 注 7. 你可能已经想到了，我读过*Stranger in a Strange Land*一书，包括删减版和原版。
|
||
- 注 8. 在合理的情况下。
|
||
|
||
原文最初发表于[爱丽丝, 夏娃和鲍勃 – 一个安全性主题博客][3]，已获得转载许可。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://opensource.com/article/18/3/3-tests-not-moving-blockchain
|
||
|
||
作者：[Mike Bursell][a]
|
||
译者：[pinewall](https://github.com/pinewall)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://opensource.com/users/mikecamel
|
||
[1]:https://opensource.com/article/17/12/blockchain-security-topic
|
||
[2]:https://aliceevebob.com/2017/09/12/blockchain-should-we-all-play/
|
||
[3]:https://aliceevebob.com/2018/02/13/3-tests-for-not-moving-to-blockchain/
|