The channels of the blockchain platform are becoming more and more crowded. Despite the rapid development of the technology and many interesting experiments in the areas of scalability, usability, and governance, no platform has yet established a usable, scalable platform that ordinary people care about. Today's blockchain technology, networks and communities are the social networks of the heyday of Myspace and Friendster (before Facebook).
Of course, our position today depends on your criteria, and success criteria are highly subjective. Simple indicators such as time of existence, trading volume, or market value are not enough: on the one hand, they can be manipulated, and they don't even know what criteria are important and promising for judging these projects.
In order to evaluate various projects, I have found subjectively that a clear set of criteria is very helpful in measuring current and potential successful projects. My standards are not based on any particular platform, but on a set of values, principles, goals and ideals. The framework of the following article is to clarify these standards to myself and the community, and compare the service situation of Bitcoin, Ethereum and other blockchain platforms based on these standards.
- Babbitt column | Tencent blockchains are strong, what is the opportunity for the public chain?
- Exploring Bitcoin: Explaining Bitcoin's Intrinsic Investment Logic
- US SEC Chairman: Blockchain technology development helps promote capital formation and provides investment opportunities for investors
- Research Report | From the Bakkt online to see the way traditional institutions lay out digital assets
- Babbitt column | Incentive noise: talk about the impact of the economy
- Blockchain Science Fiction: "Recalling Computing Power" (Part 2)
Another question is what standards should be followed to design, launch and run a successful blockchain platform. Bitcoin and Ethereum have done a lot of things, but like all platforms, they also have many shortcomings. I think their development to date has been limited because they have not met other criteria. Future platforms can learn from these mistakes, pay attention to these standards, and avoid encountering risks.
Three important warnings. First, as with all complex technologies, there are many trade-offs in blockchain. Therefore, the promotion of one standard may sacrifice other standards and adopt the "Goldilocks principle". It is best that the project will choose the most reasonable of all solutions. I will focus on this compromise.
The second caveat is that although I have chosen relatively objective and uncontested standards wherever possible, many of them are subjective. These standards are also incomplete. What do you agree or disagree with? What standards are ignored? What standards are overemphasized? Can share your thoughts with me.
The third is what I call "blockchain": I want to tell the term in the most popular way. I don't like the word, but this is the most appropriate term at the moment. I refer to all distributed ledger technologies (DLT), including technologies that are not strictly chains, such as DAG-based technologies and technologies with multiple chains. (I refuse to use the term "DLT" because acronyms are bad and extended versions are too long and obscure.) I refer not only to the underlying software and technology, but also to the wider ecosystem platform and community. My ideas are mainly applicable to public blockchains, especially on topics such as community and governance, but some of them may also be related to alliance chains.
I divided these standards into several categories and will launch a series of topic articles for each standard. The first article explored one of the most important standards: technology and protocols.
Part I: Technology and Protocol
Technology is at the core of any blockchain platform. How good is the function of the technology, what can you do on the chain, and how well is the protocol designed?
- Is the agreement incentive reasonable? Incentives are always important! This is because network participants can maximize their own interests by following the rules of the agreement, rather than profiting from manipulation. Even relatively well-known systems, such as Bitcoin mining rewards, have proven to be not entirely reasonable.
- Is the agreement easy to understand? With the innovation and differentiation of the protocol and technical route of the blockchain platform, the entire protocol system is becoming more and more complex. Under the same conditions, the agreement should be as simple as possible. More complex protocols require more time and resources to design delivery. In addition, designing and constructing more complex protocols faces team communication, pushing developers to work on their platforms and gaining user trust. Coordination is needed here, as implementing many other standards may require a degree of complex agreement. The ease of understanding of the agreement is closely related to the educational documentation of the agreement and its design.
- Is authorization allowed? If you, like me, believe that the reason blockchain exists is to enable people around the world to join a more open and fair value creation network, then no authorization is necessary. This refers to both the supply side and the demand side: mining or performing verification procedures, and transactions (sending funds, deploying applications, using applications, etc.). Ideally, any user should be able to do a small part of the valuable work for the network, such as running the CPU for several hours and getting rewards for tokens, and they can use these tokens to use the network's services. Although the mining of POW in the early days of Bitcoin and Ethereum did not require authorization, this is no longer the case, because the mining rewards in the network have been completely monopolized by professional miners. A POS-based network is not really authorization-free, because someone must sell you tokens and provide you with a validator location before you can become a validator, which means that in theory,> 50% of the network can be used by one person Monopoly, and will likely not be found.
- Can virtual machines allow developers to develop easily, cheaply, and securely? There are many trade-offs, and experts disagree on what is optimal. Bitcoin scripts severely limit the kinds of applications built on Bitcoin in exchange for security. In contrast, the Ethereum virtual machine is Turing complete, which means that in theory it can run applications of arbitrary complexity, but in fact it runs even if it runs relatively basic calculations (such as encryption) very expensive. A VM standard like WebAssembly may be needed because it can be embedded into an existing compiler toolchain (LLVM, such as Wasm), which can take advantage of a more mature tool ecosystem (compiler, analyzer, debugger, etc.), subject to Wider application.
- Do you need to do too much on the chain? In addition to security, powerful and fast VMs need to consider other pitfalls, such as slow global consensus, expensive and not suitable for most use cases. VMs like Bitcoin with limited functionality and high cost may be seen as a feature rather than a defect, as long as there are good tools to move application logic to the second layer, but still consensus key code paths, such as generation Coin transmission is placed on the first layer. Platforms like Holochain and SSB (not blockchain because they have no concept of global consensus) are lightweight architectures, while Turing's complete VMS Ethereum is the exact opposite. In contrast, Blockstack stuck to a reasonable central line.
- Is the consensus engine confirmation fast and accurate? The main function of the blockchain is to reach a consensus on a set of standardized transactions or state transitions, so the success of the agreement can be measured by whether the consensus is reached quickly and reliably. Proof mechanisms based on POW consensus such as Bitcoin and Ethereum will never provide 100% certainty (guaranteed that transactions will not be reversed), but they do provide extremely high degree of certainty: guaranteed after a certain number of confirmations The possibility of invalidating a transaction and rolling back quickly approaches zero. Waiting an hour for the block height on Bitcoin is definitely a pain. Ethereum provides similar certainty on the order of minutes, which is easier to use. In the next generation, POS-based consensus mechanisms such as Ethereum Serenity and Polkadot may go further and provide determinism in a few minutes (with low latency and no network attacks). Eth2.0 is a new era and can achieve 6.4 Minutes are even lower at 6.4 seconds.
- Can users pay more for a safer or faster consensus? Because transactions may be more or less valuable to their senders, not every transaction type requires the same priority or level of security. On platforms such as Bitcoin and Ethereum, higher fees may need to be paid to ensure faster transactions, but there are only two cases of consensus: transactions will eventually be confirmed by the entire chain, or not. The form of hierarchical consensus is very good, in which transactions can achieve higher security, for example, if a trader pays more for reaching a higher consensus level, it can be confirmed by more validators. Theoretically, it is feasible to use the second layer technology today (actually the difference between sending funds through state channels such as Lightning Network and sending transactions directly on the mainnet), but in the future on the first layer protocol It is also possible.
- Is the platform throughput high? Both Bitcoin and Ethereum are currently on the order of 10 tx / sec, which may not be enough. Network congestion on both networks at the end of 2017 is the best proof. I think about 1000 tx / sec is a reasonable goal at the moment because the consensus should be layered (see the main points above) and not every transaction needs to be confirmed at the first layer, although if it is cheap, the first layer The additional throughput may be quickly occupied. Higher value, higher priority transactions can pay higher fees and be confirmed at the first level, while other transactions can be confirmed at a higher level, or slower confirmations can be performed in batches at the first level.
- Can the platform easily interoperate? Cosmos and Polkadot platforms can achieve different levels of cross-chain interoperability. In theory, any VM platform with Turing completeness (such as Ethereum) can perfectly cross-chain with any other platform, but actually verifying transactions from other chains can be very expensive. Interoperability may also require temporary bridging, which is costly in terms of operation and maintenance. For example, Ethereum's BTCRelay service is not maintained and is not easy to use. Platforms with less scalable VMs (such as Bitcoin) need to build relatively clumsy, inefficient solutions based on more scalable platforms (such as Ethereum).
- Does the platform provide basic elements beyond consensus? The most basic service provided by the smart contract blockchain is in-protocol calculation: a specific code segment generates consensus based on the execution of the protocol rules. However, powerful, user-friendly applications will depend on other services, such as messaging and storage. To continue to rely on centralized service providers to provide these services is to abandon the prototype of Web3, but directly using Bitcoin or Ethereum transactions to store data is very expensive for all applications. Projects such as Ethereum's Whisper and Swarm and Protocol Labs' Filecoin plan to provide these missing services, but no product has yet been launched. Whether such services are provided inside or outside the agreement, they need to be integrated directly into applications and smart contracts.
The second part, decentralization : https://realsatoshi.net/15891/
Part III, Community : https://realsatoshi.net/15891/
Original title: The key ingredients to a better blockchain, Part I: Tech and protocol
Original link: https://www.etherean.org/blockchain/2019/09/09/key-ingredients-better-blockchain-part-i-tech-and-protocol.html
Author: Lane Rettig