document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

edition 4

Browse Source
This commit is contained in:
songshunqiang 2018-04-09 12:46:16 +08:00
parent 9b369fba47
commit db918eb453
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
translated/talk/20180323 How to tell when moving to blockchain is a bad idea.md
View File

@ -8,15 +8,15 @@
众所周知，我一直关注区块链及相关技术的成熟度发展情况，思考其是否达到过高期望的峰值（peak hype）；但从目前的情况来看，还没有这个迹象。我在文中提到的区块链技术是广义上的，包含了狭义上不属于区块链的分布式账本技术（DLTs）。我对私有链更感兴趣，其中私有链的定义可以参考我的文章[区块链是安全性方面的话题吗？][1]。简而言之，我对加密货币之外的区块链业务应用特别感兴趣<sup>[1](#footnote1)</sup>。
我们对区块链的技术成熟度的判断应该有一部分可以得到证实[#2]。如果我们判断正确，未来将会出现海量的区块链应用。这很可能会变成现实，但并不是所有的应用都是优秀的区块链应用，其中一部分很可能是非常糟糕的。
我们对区块链的技术成熟度的判断应该有一部分可以得到证实<sup>[2](#footnote2)</sup>。如果我们判断正确，未来将会出现海量的区块链应用。这很可能会变成现实，但并不是所有的应用都是优秀的区块链应用，其中一部分很可能是非常糟糕的。
但区块链所处的技术成熟度意味着，大量业务将快速拥抱新技术[#3]，但对于可能的前景却一知半解。促成这种情况的原因可以大致分为三种：
但区块链所处的技术成熟度意味着，大量业务将快速拥抱新技术<sup>[3](#footnote3)</sup>，但对于可能的前景却一知半解。促成这种情况的原因可以大致分为三种：
1. 对于涉及多用户数据存储的业务应用，在投入精力的情况下，几乎都可以改造为基于区块链的版本；
2. 很多区块链相关的会议和“专家”呼吁尽快拥抱区块链，否则可能会在半年内被淘汰[#4]；
2. 很多区块链相关的会议和“专家”呼吁尽快拥抱区块链，否则可能会在半年内被淘汰<sup>[4](#footnote4)</sup>；
3. 完全理解区块链技术是很难的，支持其在企业中落地的往往是工程师。
对于最后一条，我必须补充几句，不然很容易被引起众怒[#5]。作为一名工程师，我显然无意贬低工程师。但工程师的天性使然，我们对见到的新鲜事物（亮点）热情澎湃，却对业务本身神交[#6]不足，故对于新技术给业务带来的影响理解可能并不深刻。在业务领导者看来，这些影响不一定是有利的。
对于最后一条，我必须补充几句，不然很容易被引起众怒<sup>[5](#footnote5)</sup>。作为一名工程师，我显然无意贬低工程师。但工程师的天性使然，我们对见到的新鲜事物（亮点）热情澎湃，却对业务本身神交<sup>[6](#footnote6)</sup>不足，故对于新技术给业务带来的影响理解可能并不深刻。在业务领导者看来，这些影响不一定是有利的。
上面提到的三种促因可能导致一种风险，即在没有充分评估利弊的情况下，将业务改造为区块链应用。在另一文（[区块链：每个人都应该参与进来吗？][2]）中提到几个场景，用于判断一个业务什么情况下适合采用区块链技术。这些场景是有益的，但更进一步，我坚信人们更加需要的是，业务完全不适用区块链的几种简单的场景判定。我总结了三种场景判定，如果对于其中任何一个问题你给出了肯定的回答，那么很大概率上区块链不适合你。
@ -34,7 +34,7 @@
该场景似乎与上一个场景是强相关的，但并不总是如此。在一些应用中，处理流程是分布的，但信息存储是中心化的；在另外一些应用中，处理流程需要中心化的授权，但信息存储是分布的，即总有一个并不是分布式的。但如果业务使用经典数据库可以工作量良好的话，使用经典数据库是一个好主意。
经典数据库不仅性能良好，在设计与运营成本方面低比区块链或分布式账本，而且我们在这方面技术积累丰厚。区块链让所有人[#8]可以查看和持有数据，但间接成本和潜在成本都比较高昂。
经典数据库不仅性能良好，在设计与运营成本方面低比区块链或分布式账本，而且我们在这方面技术积累丰厚。区块链让所有人<sup>[8](#footnote8)</sup>可以查看和持有数据，但间接成本和潜在成本都比较高昂。
### 场景判定3：业务采用新技术是否成本高昂或对合作伙伴有负面效果？
@ -50,19 +50,19 @@
<a name="footnote1">1</a>\. 请不要误解我的意思，加密货币显然是一种有趣的区块链业务应用，只是不在本文的讨论范畴而已。
[#2]\. 知道具体是哪些部分是很有意义的，如果你知道，请告诉我好吗？
<a name="footnote2">2</a>\. 知道具体是哪些部分是很有意义的，如果你知道，请告诉我好吗？
[#3]\. 坦率的说，它其实更像是一大堆技术的集合体。
<a name="footnote3">3</a>\. 坦率的说，它其实更像是一大堆技术的集合体。
[#4]\. 这显然是假的，如果被淘汰的主体是这些会议和“专家”本身倒十分有可能。
<a name="footnote4">4</a>\. 这显然是假的，如果被淘汰的主体是这些会议和“专家”本身倒十分有可能。
[#5]\. 由于比方打得有些不恰当，估计还是会引起众怒。
<a name="footnote5">5</a>\. 由于比方打得有些不恰当，估计还是会引起众怒。
[#6]\. 我太喜欢grok这个单词了，我把它放在这里作为我的工程师标志[#7]。
<a name="footnote6">6</a>\. 我太喜欢grok这个单词了，我把它放在这里作为我的工程师标志<sup>[7](#footnote7)</sup>。
[#7]\. 你可能已经想到了，我读过_Stranger in a Strange Land_一书，包括删减版和原版。
<a name="footnote7">7</a>\. 你可能已经想到了，我读过_Stranger in a Strange Land_一书，包括删减版和原版。
[#8]\. 在合理的情况下。
<a name="footnote8">8</a>\. 在合理的情况下。
原文最初发表于[爱丽丝, 夏娃和鲍勃 – 一个安全性主题博客][3]，以获得转载许可。