BM's latest work: The trade-offs behind blockchain

Author: EOS founder BM, published in the Medium .

When comparing blockchain technologies, we don't need to spend much time to discover that there is tribalism in this technology. I've been working on blockchain technology since 2009, and one thing I found helpful was thinking about all the design trade-offs that people can make. This is not as simple as "fastest", "most scalable", "most decentralized" or "best governance". When choosing which blockchain technology is best for your application, this article will explore some less common issues.

Trust and distrust governance

There are many different types of governance systems on various blockchains, and not all governance systems are suitable for building trust. For example, delegated proof of work (e.g., Bitcoin and Ethereum) is a voting system by which a mining pool can determine which subset of valid transactions can be included in a block. It cannot be assumed that the node generating the block has "higher trust" than any other node, so they can be represented as "harmless" by producing a blockchain.

• "This coin can be reminisced, but it was gone at that time."
• Gray Capital Ethereum Trust Fund has a premium of 426%, and institutional investors are the main buyers
• MakerDAO Risk Leader: ProgPoW may put DeFi at risk, Maker may need to stand as soon as possible

In the entrusted proof-of-stake system, block producers are elected by voting by token holders. Assuming something can be used to trust these selected nodes, if that trust is violated, these things can paralyze the network. Two important examples of EOS include:

1. Become an oracle database at the time of calculation (a bad role may paralyze the network due to lack of infinite loops or insufficient billing).
2. Deploy system contract updates (⅔ + will harm the network).

In a network where anyone can propose a block, all validators must have an objective measure of CPU billing time. Ethereum works like this, but if there is a mismatch between simulated target billing and actual CPU time, it is not without the consequences of performance degradation and attack vectors.

Other proof-of-stake systems, such as Ouroboros, allow any account to produce blocks through simulated mining and staking. This fundamentally limits their smart contract system from running like Ethereum has objective resource counting. If you have an open collection of block producers without a "gate of trust," your code must compromise on performance, which can be avoided with a "trusted but verifiable" system like DPOS.

The impact of your choice of consensus algorithm goes far beyond the way you reach consensus.

Resistance censorship

The challenge for all blockchains is how users can ensure that their "effective transactions" can be truly recorded on the chain without interference from others. In principle, the more “independent” and “non-collusion” the producing and confirming entities are, the more chance there is to find one of them, including the transaction. In the worst case, you may have to produce your own blocks.

The anti-censorship story does not end with the narrative "If you are willing to buy mining hardware, you will not be censored." The only sure way to avoid being subject to transaction scrutiny is to own a 51% mining right. Without a 51% mining capacity, the pool operator can simply ignore any blocks to be audited for transactions. This means that Bitcoin governance generates an inherent "trust", with hardware owners (aka voters) choosing mining pools that are unlikely to be censored.

In this regard, both the entrusted proof of work and the entrusted equity have achieved a form of "trusted governance". To a certain extent, computing power and tokens can be widely distributed among enough independent voters. However, once voters vote, only 3 to 4 representatives (pool, block producer) can review a Bitcoin or Ethereum transaction, while protesting against a specific valid transaction requires 8 or more blocks Only producers can stop the DPOS chain.

Objective and subjective final certainty

Proof-of-work blockchains and some proof-of-stake blockchains lack objective final certainty. Instead, they present a "high probability of ultimate certainty" that grows over time. We can say that the following chains have subjective finality:

• Bitcoin / Ethereum (entrusted proof of work)
• Bitshares / Steem (Entrusted Proof of Stake)
• Cardano (Ouroboros)

The following chains have objective final certainty:

• EOSIO (BFT DPOS and BOS)
• Certain hyperledgers
• Hash graph
• Ripple

Byzantine fault-tolerance algorithms require a closed set of known validators to reach finality. As a result, if one third of the known set is closed, they will not be able to reach final certainty. With subjective certainty, someone will always produce evidence for a better chain, which will cause you to abandon the current chain.

Open access systems often lack finality and some form of "earned trust," so they are limited by performance, governance, and latency.

Easy Blockchain Communication (IBC)

Your choice of blockchain technology and consensus algorithm may affect which IBC is possible and the speed of this IBC. To see the actual situation, consider trying to write a smart contract on EOSIO to process the Bitcoin header and verify the Bitcoin transaction. When can your smart contract consider the finality of Bitcoin transactions? In many cases, even after 100 blocks, the blockchain may restructure. Any amount of confirmation you choose carries the risk of being withdrawn.

Now, suppose you performed an immutable operation on another chain, which has IBC-based finality, and the chain has no finality. In practice, IBCs with chains that lack objective finality must wait a long time to reduce the risk of chain reorganization due to invalid assumptions. If the deposit is withdrawn after more than 6 confirmations, the or your Bitcoin deposit smart contract must have some way to mitigate the damage.

IBC can be used in a subjective finality chain, but if communication is two-way, then God will help you. The latency required for two subjective finality chains communicating with each other is similar to the delay in communicating with a deep space probe, with round trip times in hours or days.

IBC in a chain with objective finality can be completed in seconds.

Finally, just because communication between two chains is theoretically not meant to be easy. The convenience of communication depends in part on how easy it is to build a smart client into another chain as a smart contract. This in turn depends on the complexity and number of header and Merkle proofs, and the robustness and performance of the smart contract language. Too much overhead or too little electricity in a smart contract will kill the potential of IBC.

For example, consider that EOS emulation of Ethereum is much easier than Ethereum simulation of EOSIO!

in conclusion

As the debate over consensus algorithms and decentralization grows fierce, it is imperative that smart observers ask to consider the full cost of all technological compromises. If "decentralized open consensus algorithm" means that the blockchain you own has subjective certainty and high-latency inter-blockchain communication (IBC), and you cannot leverage "trust but verifiable" in the governance Optimization, what are the benefits?

On the other hand, there are risks in providing a final algorithm.

Remember the "All Blockchain Magic comes with a Price", before you entrust your organization to any specific smart contract platform, make sure you have read the fine print.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!