译文/Translated：
所有魔法都有小代价——从前……
比较区块链技术并不需要花费太多时间。自2009年以来，我一直在从事区块链技术的研究，我发现考虑人们可以做出的所有设计取舍是一件非常有用的事。这不仅仅只是“最快”、“扩展性最好”或者“治理最好”。本文将深入探讨一些在您选择最适合您的应用的区块链技术时较少思考的问题。
可信与不可信治理
各类区块链运行着各种各样的治理系统，并非所有治理系统都值得信任。例如，工作授权证明（Delegated Proof of Work，例如比特币和以太坊）是一项投票系统，其间矿池决定了验证交易的子集合包含在区块当中。产生区块的节点并不比其它节点拥有“更高的信任水平”，因此它们可通过制造区块来变得“无害”。
股权委托证明系统上，通过代币持有者投票选出区块制作者。此时存在一种假设，可以通过特定事物信任这些所选择的节点，若该信任被违背，那么便能够使整个网络瘫痪。EOS的两个典型示例包括：
- 成为计算运行时间的预言家（1个坏人可能会撒谎说缺少无限循环或计费不足而使网络停滞）
- 部署系统合约更新（所需的三分之二会损害网络）
在任何人都可以提议区块的网络中，所有验证方必须拥有计算CPU计费时间的客观测量方式。这就是以太坊的运作方式，但当模拟目标计费与实际CPU时间不匹配时，性能和攻击向量会随之降低。
其它股权证明系统，例如Ouroboros，允许所有账户通过模拟下注挖矿来生成区块。这从根本上限制了它们的智能合约系统像以太坊一样具有客观的资源计数功能。如果您拥有开放的制作者集合而没有“可信任的门户”，那么您的代码必须在性能上做出妥协，而这原本可以通过“可信任但需验证”（trust but verify）系统（如DPOS）来避免。
您选择的共识算法所带来的影响远不止是影响达成共识的方式。
审查抵抗
所有区块链都面临的一项挑战是用户如何确保他们的“验证交易”能实际在链上留下记录而不会受到他人的干涉。原则上，产生和确认区块的越发“独立”和“非共谋”的实体越可能在其中找到您的交易。最坏的情况是您可能不得不生成自己的区块。
审查抵抗的故事并没有以简单的回答结尾：“如果您愿意购买采矿硬件，就不会受到审查”。唯一确定能不被审查的方式是拥有51%的挖矿能力。如果没有51％的挖矿能力，那么矿池运营商就可以简单地忽略任何要审核交易的区块。这意味着比特币治理创建了固有的“信任”，其中硬件所有者（又名投票人）选择了不太可能审查的挖矿池。
在这方面，工作授权证明和股权授权证明都实现了一种“可信任的治理”形式，以至于哈希运算力和代币在足够多的独立投票人中广泛分布。但是，一旦投票人投票，只需3-4个代表（池）即可审查比特币或以太坊交易，并且要抗议特定的有效交易仅需要8个或更多的人暂停DPOS链。
可观与主观确定性
区块链工作授权证明以及部分股权证明链缺乏客观确定性。相反，它们随着时间呈现出“确定性的高可能性”。我们或许可以说以下链具有主观确定性：
- 比特币/以太坊（工作的授权证明）
- Bitshares/Steem（股权的授权证明）
- Cardano（Ouroboros）
以下链具有客观确定性：
- EOSIO（BFT DPOS 与 BOS）
- Certain Hyperledger
- Hashgraph
- XRP
拜占庭容错算法需要一组封闭的已知验证方才能实现确定性，因此，如果关闭了该已知组的⅓，则它们将无法获得确定性。有了主观确定性，总会有人能生成更好链的证据，这会导致您放弃当前的链。
开放式进入系统往往缺乏确定性和任何形式的“赢取的信任”，因此它们的性能，治理和延迟受到限制。
区块链间通信（IBC）的便易性
您选择的区块链技术和共识算法会对IBC的种类及其速度产生影响。要体会这一点，请考虑尝试在EOSIO上编写智能合约处理比特币区块头并验证比特币交易。您智能合约何时认为比特币交易完结？多数情况下，即便100个区块过后，链也可能会重组。您选择的任何数量的确认都带被撤消。
现在假设您在另一条链上进行了不可改变的操作，而该链的确定性是基于来源于另一条没有确定性的链的IBC。实践中，缺乏可观确定性的链的IBC必须等待很长时间，以减少因无效假设而导致链重组的风险。如果存款经过6次以上的确认后撤消，则该智能合约或您的比特币存款智能合约必须具有减轻损失的方法。
具有主观确定性的链中的IBC或许可行，但是如果交流是双向的，上帝会帮助您。彼此沟通的两个主观确定链需要的延迟类似于与深空探测器交谈，往返时间以小时或天为单位。
具有可观确定性的链的IBC能够以秒为单位运行。
最后，仅仅因为理论上两个链之间可以进行通信并不意味着这很容易。通信的便利性部分取决于将轻端客户建立到另一条作为智能合约的链的难易程度。这又取决于区块头和Merkle证明的复杂性和数量，以及智能合约语言的鲁棒性和性能。智能合约中过多的工作量或太少的电力会杀死IBC的潜力。
例如，考虑一下EOS模拟以太坊要比以太坊模拟EOSIO要容易得多！
结论
随着对共识算法和去中心化的争论日益激烈，当务之急是聪明的观察者要求将所有技术折衷的全部价格都考虑在内。若“更加去中心化的开放式共识算法”意味着您拥有具有主观确定性和高延迟链内通信的区块链，但却无法在治理层面利用“可信任但需验证”（trust but verify）优化功能，这又有什么好处呢？
而另一边，具有确定性的算法也面临风险。
请记住，“所有区块链魔法都有代价”，请在选择将组织提交至特定智能合约平台时，仔细阅读细则。
原文/Original：
All magic comes with a price dearie — Once Upon a Time
It doesn’t take much to bring out tribalism when it comes to comparing blockchain technology. I have been working on blockchain tech since 2009 and one of the things that I find helpful is to consider all of the design tradeoffs that people can make. It isn’t as simple as “fastest”, “most scalable”, “most decentralized”, or “best governance”. This post will look into some of the less frequently thought about issues when it comes to picking which blockchain technology is best for your application.
Trusted vs Untrusted Governance
There are many different kinds of governance systems in play on various blockchains, and not all governance systems are suitable for building trust. For example, Delegated Proof of Work (e.g. Bitcoin & Ethereum) is a voting system whereby mining pools get to determine what subset of valid transactions are included in blocks. The nodes producing the blocks are not presumed to have any “higher level of trust” than anyone else and therefore they can “do no harm” by virtue of producing a block.
On Delegated Proof of Stake systems the block producers are elected by token holder voting. There is a presumption that these elected nodes can be trusted with certain things which could bring down the network if that trust were violated. Two big examples from EOS include:
- Being an oracle for computational runtime (1 bad actor could stall the network by lying about the lack of a infinite loop or under-billing)
- Deploying system contract updates (⅔+ required to harm network)
In a network where anyone can propose a block, all validators must have an objective measure of CPU billing time. This is how Ethereum works, but it isn’t without consequences of slower performance and attack vectors when there is a mismatch between their simulated objective billing and real world CPU time.
Other proof of stake systems, such as Ouroboros, allow any account to produce blocks by simulating mining with staking. This fundamentally limits their smart contract systems to function like Ethereum with objective resource counting. When you have an open set of producers with no “trust gate” then your code must make compromises in performance that could be avoided with a “trust but verify” system like DPOS.
Your choice of consensus algorithm impacts a lot more than just how you reach consensus.
Censorship Resistance
A challenge faced by all blockchains is how does a user ensure that their “valid transaction” can actually get recorded on chain without interference from others. In principle the more “independent” and “non-collusive” entities that are producing and confirming blocks the greater chance you can find one of them which will include your transaction. Worst case you may have to produce your own block.
The story of censorship resistance doesn’t end with the hand waving answer of “you cannot be censored if you are willing to buy mining hardware”. The only sure way to avoid being censored is to have 51% of mining power. Without 51% of mining power, the mining pool operators can simply ignore any block that has a transaction they want to censor. This means that there is inherent “trust” created by bitcoin governance where hardware owners (aka voters) pick mining pools that are less likely to censor.
In this respect, Delegated Proof of Work and Delegated Proof of Stake are both implementing a form of “trusted governance” to the extent that hash power and tokens are widely distributed among a large enough number of independent voters. Once the voters vote, however, it only takes 3–4 representatives (pools) to censor a bitcoin or Ethereum transaction and it takes 8 or more to halt a DPOS chain in protest of a specific valid transaction.
Objective vs Subjective Finality
Proof of work blockchains as well as some proof of stake chains lack objective finality. Instead they present a “high probability of finality” that grows over time. We could say that the following chains have Subjective Finality:
- Bitcoin / Ethereum (Delegated Proof of Work)
- Bitshares / Steem (Delegated Proof of Stake)
- Cardano (Ouroboros)
The following chains have objective finality:
- EOSIO (BFT DPOS and BOS)
- Certain Hyperledger
- Hashgraph
- XRP
The byzantine fault tolerant algorithms require a closed set of known validators to reach finality, as a consequence if ⅓ of this known set is shut down then they cannot reach finality. With Subjective finality there is always the potential for someone to produce evidence of a better chain that will cause you to abandon your current chain.
Open Entry systems tend to lack finality and any kind of “earned trust” so they are limited by both performance, governance, and latency.
Ease of Inter-blockchain Communication (IBC)
Your choice of blockchain technology and consensus algorithms can impact what kind of IBC is possible and the speed of that IBC. To see this in action, consider attempting to write a smart contract on EOSIO to process bitcoin headers and validate Bitcoin transactions. At what point can your smart contract consider the Bitcoin transaction final? There are any number of cases where even after 100 blocks the chain could reorganize. Any number of confirmations you pick carries with it a risk that it could be undone.
Now suppose you take an immutable action on another chain that has finality based upon IBC from a chain without finality. In practice IBC with chains that lack objective finality must wait a very long time to reduce the risk of a chain reorganization from invalidating assumptions. That or your Bitcoin deposit smart contract must have some way of mitigating damage if a deposit gets undone after 6+ confirmations.
IBC among chains with subjective finality may be possible, but God help you if the communication is two-way. Two subjective finality chains talking to each other require latencies similar to talking with deep space probes with round trip times measured in hours or days.
IBC among chains with objective finality can be performed in seconds.
Lastly, just because it is theoretically possible for two chains to communicate doesn’t mean it is easy. The ease of communication depends in part on how easy it is to build a light client to another chain as a smart contract. This in turn depends upon the complexity and volume of the headers and merkle proofs as well as the robustness and performance of the smart contract language. Too much overhead or too little power in the smart contract can kill the potential for IBC.
For an example of this, consider how much easier it is for EOS to emulate Ethereum than for Ethereum to emulate EOSIO!
Conclusion
As the debate over consensus algorithms and decentralization rages on, it is imperative that intelligent observers demand that the full price of all technological tradeoffs is accounted for. What good is a “more decentralized open-entry consensus algorithm” if it means you have a blockchain that has subjective finality and high latency inter-blockchain communication and no ability to leverage “trust but verify” optimizations in the governance layer?
On the other hand, there are risks to algorithms that offer finality as well.
Remember “All Blockchain-Magic comes with a price”, be sure you read the fine print before you commit your organization to any particular smart contract platform.
原文链接/Original URL:
