Editor's Note: This article comes fromEthereum enthusiastEditor's Note: This article comes fromPreethi KasireddyEthereum enthusiast

(WeChat ID: ethfans), original author: Preethi Kasireddy, source:

Editor's Note: This article provides a detailed comparison of blockchains in the Cosmos network with Bitcoin and Ethereum. The author starts from the stack layer of the blockchain system, analyzes the technical points of Bitcoin and Ethereum on different stack layers, and finally returns to the blockchain in the Cosmos network. The conceptual explanation is particularly clear, which is a rare explanation arts.

Table of contents

• In view of the fact that the article is too long, we have attached a table of contents at the beginning of the article.

• Table of contents

• What is Cosmos?

• Introduction to Blockchain Structure

• Bitcoin stack layer structure

• Ethereum stack layer structure

• Build applications on Bitcoin and Ethereum

• Cosmos blockchain structure

• Cosmos network layer

• in conclusion

Cosmos application layer

in conclusion

The cryptocurrency industry never stops.

It all started with the advent of Bitcoin in 2010. When Bitcoin first came out, everyone thought it was the holy grail of digital currencies. What was once considered impossible is now a reality: the first peer-to-peer (P2P) payment network has emerged.

Even today, trust in things remains the most elusive and most precious asset. Bitcoin circumvented this problem by creating the first "trustless" system. But this is just the beginning.

Since then, Bitcoin has been a catalyst for broader innovations in cryptography that have led to a series of new decentralized systems and financial infrastructures: Ethereum, Lightning Network, EOS, Tezos, Maker... The list is still growing.

But one project stands out: Cosmos.

In the field of blockchain, Cosmos is a "new baby". Although its concept has been around for some time, its development team has been slowly developing behind the scenes to ensure the correctness of the Cosmos design and implementation. This also makes Cosmos only recently launched publicly.

So it's no surprise that many people look at the Cosmos project and don't understand it. Simply browsing Cosmos-related materials will not allow them to understand Cosmos intuitively, but will make them have more questions:

What is Cosmos?

How does Cosmos work?

How is Cosmos different from Bitcoin and Ethereum?

What are the characteristics of Cosmos?

I've known the Cosmos team for almost two years. Honestly, when I first heard what they were doing, I was as clueless as anyone else about the concept.

But as I got to know more about Cosmos, I started to appreciate it a lot. And I don't just say this for attention, I really mean it from the heart.

I'm so fascinated by Cosmos, so we decided to build the TruStory app as a Cosmos blockchain app. (Interlude: I will explain why we made this decision in more detail in a future article)

Still, there is a lot of confusion about the universe. So I decided to write an article just for that. I want readers to have a deeper understanding of what Cosmos is and its place in the blockchain world.

Are you ready to start? Clear your mind, put on your thinking hat, and buckle up. we are going to drive

What is Cosmos?

Cosmos defines itself like this:

"A decentralized network composed of multiple independent parallel blockchains, each of which uses a BFT consensus algorithm (eg: Tendermint consensus)."

Wow, what a mouthful! Let's break this definition down into easy-to-understand parts.

"Decentralized Network of Independent Parallel Blockchains"

I'm assuming here that the reader already knows a lot about blockchain! Still, a quick recap:

In simple terms, a blockchain is a database distributed across many computers, with the database on each computer maintaining the same state. In other words, the databases on each computer contain the exact same data. Together, these computers make up what is known as a "blockchain network."

Both Bitcoin and Ethereum are blockchains, and Cosmos is a blockchain network made up of many such blockchains running in parallel.

If you can't fully understand what I just said, you'd better read some more basics about blockchain before learning more about how Cosmos works. (Editor's note: For the Chinese translation, see the hyperlink at the end of the article "What the hell is a blockchain")

"Each blockchain adopts BFT consensus algorithm"

BFT is an acronym for "Byzantine Fault-Tolerant". A Byzantine fault-tolerant blockchain can ensure that the network still has the properties of "security" and "activity" when some nodes in the network go down and/or do evil (so-called "Byzantine nodes"). Security and activity can ensure that each node in the blockchain network maintains the same state.

Interlude: If you want a deeper understanding of what Safety and Liveness are, read my article on distributed consensus. (Editor's Note: For the Chinese translation, see the hyperlink at the end of the article "How Distributed Consensus Works, Part-2")

Therefore, a "BFT consensus algorithm" is an algorithm that defines the communication and coordination between computers, making the blockchain Byzantine fault tolerant. All blockchains in the Cosmos network employ some sort of BFT consensus algorithm.

The consensus algorithms of Bitcoin and Ethereum are not typical BFT algorithms. So they don't fit the definition of a blockchain in the Cosmos network. (It’s worth noting that while they’re not Byzantine Fault Tolerant, it’s still possible for blockchains like Bitcoin and Ethereum to join the Cosmos network with just a few extra steps. Don’t worry if you find this puzzling — we’ll get to that later. Do a more in-depth study on this.)

Interlude: If you still don't know what BFT is, I wrote it quite clearly in this article. (Editor's note: For the Chinese translation, see the hyperlink at the end of the article "How Distributed Consensus Works, Part-3")

"Tendermint Consensus Algorithm"

Tendermint is a BFT consensus algorithm proposed and built by Cosmos developers. Blockchains in the Cosmos network can use Tendermint consensus or any other BFT consensus algorithm. We'll learn more about Tendermint later in this article.

Simply put, the Cosmos network is an ecosystem consisting of multiple independent Byzantine fault-tolerant blockchains running in parallel. These blockchains operate independently and are able to interoperate with other blockchains.

Now you might be thinking, “Why would blockchains interoperate?”

good question! We'll get to that shortly. But first we need to review the structure of the blockchain.

Introduction to Blockchain Structure

Before delving into how blockchains work and interoperate in the Cosmos ecosystem, let's review the basics of blockchain structure.

As we discussed earlier, a blockchain is a multi-machine replicated database and maintains the same data on each computer. This type of distributed system is also known as a "replicated state machine".

A replicated state machine is a multi-machine replicated deterministic state machine, but because each computer in the network maintains the same state, it functions like a single machine.

Sounds familiar, right? Looking back at the definition of blockchain above, the definition here is just to replace "database" with "state machine" and "data" with "state". I believe you can understand what I mean.

"Deterministic" can be simply understood as, given a certain input, the state machine will always produce the same output. In blockchain systems, "determinism" means that if you start from a given state and perform the same sequence of transactions, you will always end up with the same final state.

A replicated state machine starts from a certain state. Each valid transaction will result in a transition of the system state to the next state (this is the same as updating an entry in a database: if you update an entry, the database will migrate to a new state containing the updated data entry).

A replicated state machine conceptually has three stack layers:

1) Application layer

The application layer is responsible for defining state transitions and updating the state machine state after a transaction occurs.

2) Network layer

The network layer is responsible for propagating transactions executed on one state machine to all other state machines in the network.

3) Consensus layer

The consensus layer consists of algorithms responsible for ensuring that each state machine stores the same state after a transaction has been executed (ie, a state machine cannot forge a non-existing transaction).

3a) Anti-Sybil layer

A replicated state machine attempting to run on a decentralized public network also requires a fourth layer (“Sybil resistance layer”) to ensure that no single state machine can corrupt the network. Without this layer, a state machine could tamper with the state by creating many false identities to gain influence or benefits disproportionate to its investment (i.e., launch a Sybil attack).

In summary, the application layer is responsible for defining state and managing state transitions. The network and consensus layer is responsible for keeping the state on each machine consistent (that is, ensuring that the data in each database in the network is consistent). The Anti-Sybil layer is (obviously) responsible for avoiding Sybil attacks.

Now, let's see how these stack layers are defined and implemented in the Bitcoin and Ethereum blockchains.

Bitcoin stack layer structure

1) Application layer

The main application of Bitcoin is P2P transactions. Bitcoin uses Script (a stacked, non-Turing-complete language) to define and execute transactions. When a sender sends bitcoins through a transaction, the sender uses a script to encode who is in control of the funds. A script contains a set of opcodes, or commands, that a sender can use to specify the conditions that need to be met in order to spend a bitcoin.

2) Network layer

When a sender sends bitcoins to a receiver, the transfer must be broadcast to the network for miners to include it in a block. Bitcoin uses a "Gossip protocol" to ensure that each node sends all new blocks or transactions it receives to its neighbors (peers). The Gossip protocol is a P2P protocol that ensures message dissemination among all nodes. All nodes in the Bitcoin network will immediately send their newly received valid transactions to their neighbor nodes, so that the transaction to be packaged can be propagated to most nodes through the peer-to-peer network within a few seconds.

3) Consensus layer

After the transaction is relayed to the network, it needs to be added to the blockchain to complete the transfer (that is, let the computers in the network execute the transaction). The process of validating transactions and packing them into blocks is called "Nakamoto Consensus". The working principle of Nakamoto Consensus can be found in other forums or articles. This article is a good primer if you want to dig deeper.

3a) Anti-Sybil layer

Nakamoto consensus relies on "Proof-of-Work" to prevent Sybil attacks. Basically, the computational power required to generate a new block makes the Bitcoin consensus protocol itself resistant to Sybil attacks. Since miners need a lot of computing power to generate the next block, they cannot "fake" multiple identities without investing a lot of computing power (and money).

Ethereum stack layer structure

1) Application layer

Unlike Bitcoin, Ethereum was originally designed to be a platform capable of running decentralized applications. Ethereum includes a high-level language (i.e., Solidity) that enables developers to define the specific functionality of decentralized applications by writing smart contracts. EVM (Ethereum Virtual Machine, Ethereum Virtual Machine) is the core of the Ethereum application layer. EVM uses the EVM compiler to compile smart contract codes into bytecodes. Users can upload the bytecodes to the blockchain in the form of transactions, and EVM can execute these bytecodes, thereby changing the decentralized application. State (that is, update the relevant state of this smart contract stored by the Ethereum node). Since all nodes in the Ethereum network run EVM, this also ensures that the state of all nodes is consistent.

2) Network layer

Similar to Bitcoin, Ethereum also uses the Gossip protocol, which enables nodes to communicate with their neighbors.

3) Consensus layer

To achieve consensus, Ethereum uses "Ethash", which is similar to Nakamoto consensus, but Ethash has some key differences from Nakamoto consensus. If you need to understand how the Ethereum consensus algorithm works, read one of my previous articles. (Editor's Note: For the Chinese translation, see the hyperlink "How Ethereum Works" at the end of the article)

3a) Anti-Sybil layer

Like Bitcoin, Ethash relies on Proof of Work (so far, Translator's Note: Ethereum 2.0 will switch to the PoS consensus mechanism in the future) to resist Sybil attacks.

Build applications on Bitcoin and Ethereum

I hope the above has given you a certain understanding of the blockchain structure. When we talk about "Bitcoin" or "Ethereum", these names refer to all the stack layers involved. Because Bitcoin and Ethereum are a whole made up of these stack layers.

You can't separate Ethereum smart contracts from their underlying Ethhash consensus layer, so it doesn't make sense to discuss these two topics separately. The same is true for Bitcoin, you cannot conduct Bitcoin transactions without using Nakamoto Consensus and Proof of Work.

Cosmos, on the other hand, follows a slightly different model: it separates the application layer from the consensus and network layers.

Since the goal of Cosmos is to build a blockchain network, it makes sense to design it this way. In this blockchain network, each blockchain is independent and has its own needs and requirements (ie, its own application). In this case, it is not feasible to propose a one-size-fits-all application layer for all blockchains. Let's examine why with a few examples.

An example of Bitcoin's limitations

Let's say we're going to build a currency application. In this case, a simple stack-based scripting language like Bitcoin Scrypt is the best choice. Not only does the Bitcoin scripting language work well for transferring value from one address to another, it is also very simple and not Turing-complete.

As such, it is less susceptible to various types of security flaws that could seriously affect a Turing-complete programming language. This is exactly what we want when dealing with money and store of value. But this simplicity has its limits.

Doing anything more complex (eg: decentralized prediction markets) with Scrypt is very difficult. Bitcoin scripting language is not only limited by the complexity of its executable code, but also very unfriendly to developers. To make matters worse, transactions on the Bitcoin blockchain are slow to process (approximately 7 transactions per second). Therefore, it is unrealistic to build applications that require high transaction throughput directly on the Bitcoin blockchain.

An example of the limitations of Ethereum

In contrast to Bitcoin, Ethereum's EVM and smart contract language (Solidity) are designed to support more flexible applications. Solidity is a Turing-complete programming language, so it can theoretically execute code of arbitrary algorithmic complexity.

In practical applications, it is quite difficult to develop programs of arbitrary complexity using Solidity because Solidity is error-prone and vulnerable to security attacks. This characteristic runs counter to applications that deal with value transfers, where security is paramount.

In addition, smart contracts are also very difficult to upgrade, making iterative development very difficult. Once the contract is deployed on the chain, all you can do is pray that it can run smoothly! Like Bitcoin, Ethereum's transaction processing rate is very low (about 15 transactions per second), so it is not practical to build applications requiring high transaction throughput on the Ethereum blockchain.

Cosmos was proposed to meet this practical business need, although it has made some major sacrifices for this purpose. We'll dive into the specifics next. But before that, we also have to understand what the three stack layers of the blockchain in Cosmos look like.

Cosmos blockchain structure

First, we'll look at Cosmos, starting with the consensus layer, to better understand how developing applications on Cosmos differs from using Bitcoin or Ethereum.

Cosmos Consensus Layer

The blockchain in the Cosmos network uses the Tendermint consensus algorithm. Tendermint is an open source project born in 2014, "designed to solve the speed, scalability and environmental problems of the Bitcoin Proof-of-Work (PoW) consensus algorithm."

The Tendermint consensus algorithm is an "application-agnostic consensus engine". Essentially, this means that any blockchain can use the Tendermint consensus algorithm, which is Byzantine fault tolerant, and uses a PoS algorithm to resist Sybil attacks.

Another lot of jargon! We talked about it.

To review, the consensus algorithm exists to ensure that after the transaction is executed, the state saved in the state machine is consistent; and the Tendermint consensus algorithm defines a rule that "allows all nodes to reach a consensus on the next block".

Verifier

Let's see how the correlation factors and rules work!

Verifier

Nodes responsible for reaching state consensus are called "validators". Any participating node willing to assist the entire network to reach a consensus can become a validator; in return, the validator will receive transaction fees and block rewards. Tendermint aggregates the votes of these validators to determine the correct state for the next block.

Fighting Sybil Attacks with Staking

Each validator's vote has its own voting weight. The voting weight is usually determined when the genesis block is generated, or after it starts running, it is determined according to some logic designed by the application layer developer. Generally speaking, the weight of the vote is determined by the amount of tokens locked in the system by the validator (as collateral), which is also called a "bond".

• consensus

• According to the rules, verifiers must reach a consensus on each block in rounds. Each round consists of three basic steps: Propose, Prevote, Precommit, and two subsequent steps: Commit, NewHeight. From an abstract point of view, validators jointly decide what block to use at the next height according to the following protocol rules:

• The first is the proposal phase, where a designated validator proposes a block—proposers in each round are deterministically selected from an ordered list in proportion to their voting weight.

• Then comes the pre-vote phase - each validator broadcasts their respective pre-vote.

• When a block in the round receives more than 2/3 of the pre-votes, we call it "polka". As soon as the "polka" appears, go to the next stage.

• Entering the pre-commit phase, each validator broadcasts their pre-commit votes.

If a particular block receives more than 2/3 of the pre-votes, it enters the commit phase, which adds the block to the blockchain and increases the block height. Whenever a new block is added to the blockchain, the block height of the blockchain is +1.

• If it fails, it will either go back to the pre-vote phase or the pre-commit phase.

• Note that at any height, more than one round of voting may be required to commit a block. Because the following situations may occur:

• The designated "proposer" goes offline when the block is supposed to be proposed

The block proposed by the proposer violates some predefined rules

Tendermint relies on a timeout mechanism to ensure that the blockchain does not encounter delays in producing blocks. If the proposed block does not receive more than 2/3 of the pre-votes before the timeout, the new proposer will proceed with the proposed block process again.

Details of the agreement can be found here.

In general, Tendermint has chosen a different route from Bitcoin's Nakamoto Consensus and Ethereum's Ethash. Let us make some key comparisons:

Deterministic vs. Probable

Unlike probabilistic consensus such as Nakamoto Consensus and Ethash, Tendermint is a deterministic consensus-meaning that each block of Tendermint is finalized, unlike Bitcoin's blocks that are only "probably" finalized status.

Let's review the Nakamoto consensus, the block is always in the "undetermined" state - only by confirming that a block is on the "longest chain" can we be sure that the block is being finalized, which is why Bitcoin The transaction needs to wait for "6 block confirmation".

In Tendermint, the block is confirmed immediately after the verifier successfully votes and commits.

Fixed validators vs. variable validators

Nakamoto Consensus and Ethash allow miners to choose to join or quit at any time without requiring other miners to know in advance. In contrast, Tendermint consensus requires maintaining a fixed set of validators known in advance, identified by their public keys.

Leader vs. No Leader

Nakamoto Consensus and Ethash do not have a designated leader to propose the next block (ie any miner may mine the next block). Tendermint, on the other hand, elects leaders, or proposers, who are responsible for proposing the next block.

Explicit vs. vague timeout mechanisms

Nakamoto Consensus and Ethash do not use a timeout mechanism to ensure that miners will be able to produce blocks, while Tendermint has a clear timeout mechanism to ensure that the blockchain block production process will not encounter delays.

100 validators vs. 1000 validators

Tendermint follows the traditional consensus consensus algorithm, and each validator must communicate with each other. Considering the communication overhead, Tendermint cannot infinitely increase validators like Bitcoin or Ethereum. The Tendermint consensus schedules 100 validators.

So one of the disadvantages of Tendermint is that it requires prior knowledge of all validators and does not allow validators to join or leave at any time; unlike Bitcoin or Ethereum.

In addition, Tendermint also requires the entire system to maintain a unified clock; although in practice Tendermint has proved that it can maintain a unified clock by integrating the timestamps of each node, everyone knows that synchronizing time is a very complicated theoretical problem.

Tendermint has fewer verifiers than Bitcoin and requires prior knowledge of the set of verifiers, so some people may question that the Tendermint consensus protocol is "not decentralized enough".

However, decentralization is a matter of opinion. Okay, without being shy, what I want to say is that decentralization is a means to achieve a certain goal, not the goal itself; I don't like to make judgments without understanding the goal of decentralization.

I think Tendermint's conservative approach of requiring a fixed and prior knowledge of the set of validators is feasible in many cases (or even most cases), as long as the cost of breaking the system is high enough, and there are defenses and penalties for attackers.

If we go back to the prediction market example, I would say that a decentralized prediction market application simply does not need to have the same level of decentralization as a sound currency or a store of value application, 10, 20 or 100 validators are enough. carry on.

Taking TruStory as an example, we use the Cosmos SDK to build the back-end application logic, and store the state and logic of the application on the blockchain, while the front-end is private to some extent—the Cosmos SDK allows us to build a system that rewards good and punishes evil Incentivize the system, transparently display the data layer, allow users to share the ownership and governance of the network, and jointly decide on future affairs, kick out malicious users, and design the network for the user layer or the base layer according to personal preferences. For developers, they can also build their own development tools and services based on the back-end blockchain logic. So having 10 or 100 verifiers who execute and verify transactions can guarantee the transparency, ownership, and accountability needs of users and developers.

safety and activity

high performance

Tendermint's protocol guarantees security and liveness. Assuming that more than 2/3 of the verifiers' voting weight is not in the hands of Byzantine verifiers (that is, more than 2/3 of the verifiers abide by the agreement), in other words, less than 1/3 of the votes are malicious, then the protocol can Ensure the security and activity of the network (ie, verifiers will never propose conflicting blocks at the same block height, and the blockchain will always produce blocks normally).

high performance

The block generation time of the Tendermint consensus can be as low as 1 second, reaching the speed of processing thousands of transactions per second, making Tendermint more suitable for applications that require frequent transactions.

instant confirmation

As we mentioned earlier, Nakamoto consensus has its probabilistic nature, so there is no way to guarantee finality. You can only guarantee that the fork chain your transaction is on is the consensus chain based on the probability that most miners are still mining in that fork.

responsibility system

However, Tendermint requires validators to vote and finalize each block. So we can say that with less than 1/3 malicious validators, the transaction can be "instantly confirmed" - when the block is created, users know that their transaction has been confirmed.

responsibility system

Tendermint uses PoS as an anti-Sybil mechanism - requiring validators to stake tokens (ie their "bond") to ensure nodes cannot cheat the system by creating multiple fake accounts.

PoS is more energy-efficient than PoW (the proof of PoW comes from the computing power consumed by miners to solve the hash of the next block), but its inherent "no stake" flaw makes it easy for verifiers to cheat.

Tendermint penalizes validators who violate the protocol rules (eg voting for conflicting blocks, and broadcasting unverified votes) by slashing the deposit to avoid disinterested issues. More specifically, the protocol has "locking rules" that regulate what each validator can do when voting for a particular block. For example, once a validator pre-commits a vote, it is "locked" in that block; the validator can only unlock and pre-commit another block if it wants to make a different block polka in the next round piece. If the locking rules are violated, the validator will be fined forfeiting the security deposit.

Simpler light client

Light clients are "lighter" than full nodes because they don't store all the state of the blockchain, only block headers. Unless it is a mining node responsible for verification and block generation, or a validator node, most nodes do not actually need to store the full state of the blockchain.

Instead of downloading and storing the entire chain, the light client downloads block headers from the genesis block to the current block. Compared with the full node, the light client only needs to store a small amount of data, because the block header is enough to verify the validity of some specific transactions.

The coolest thing is that a light client of a Tendermint-based blockchain doesn't even need to sync all the block headers, just download the block headers periodically.

As we discussed earlier, Tendermint is different from Bitcoin and Ethereum, all its blocks must be voted and finally confirmed; because each block is finally confirmed, so the light client only needs to pay attention to the changes in the validator set— - As long as the latest set of validators is known, the light client can download the latest block headers and verify that these blocks have more than 2/3 validator votes.

Cosmos network layer

As we said above, Tendermint's consensus relies on validators to vote in each round. Therefore, nodes must be able to communicate and transfer messages to ensure that all participants in the network can see the same data.

Like Bitcoin and Ethereum, Tendermint uses the gossip protocol to rapidly propagate the latest blockchain state.

Nodes in the network do not have to be validators to play a role in the network consensus process. For example, a node can be a light node or a full node instead of a validator; such nodes are also called "non-validator nodes".

Validator and non-validator nodes are responsible for delivering data (such as proposal data, block data, and voting data) to ensure that all nodes can receive the information and transactions being generated by the system.

Cosmos application layer

At present, we have understood the core components of the Tendermint network layer and consensus layer; the network layer is responsible for the transfer of transactions between all computers in the network, and the Tendermint consensus algorithm ensures the consistency of the state machine (that is, the blockchain in all nodes is consistent of).

• But what transactions are we passing and validating? Here comes the application layer.

• Define and submit transactions that need to be recorded in the blockchain

Continuously update the blockchain state after transactions are committed through the consensus layer

text

Cosmos SDK provides a framework for building application layers, just like Ruby-on-Rails in the blockchain world (Ruby-on-Rails is a framework that allows developers to easily build web-side applications with default settings), Cosmos SDK It also provides developers with a framework for building secure blockchain applications based on the Tendermint kernel.

Remember that a blockchain is a state machine with the same backup of state across all nodes, and the Cosmos SDK allows you to build actual state machines that are replicated across multiple nodes. The SDK allows you to customize the application's state, transaction types, and functions and tools required for state-transition functions.

text

How Cosmos Applications Work (Abstract Perspective)

• The Cosmos SDK provides a "multistore" mechanism to define and maintain the state of the application layer state machine. Multistore divides the state of the application layer into different components and manages them through their respective "modules".

• The strength of the Cosmos SDK is its unique modular design. Each module defines and maintains a subset of states that constitute a complete blockchain. for example:

• Banking module: Allows you to hold tokens in the app and transfer tokens

Permissions module: Allows you to create and manage accounts and signatures

Staking and slashing module: Allows you to build a PoS consensus mechanism through coding

Each module is a small state machine that can be aggregated to generate an overall state machine.

Application developers define subsets according to the idiomatic logic of each module and modification state. In addition to the modules provided by the Cosmos SDK, developers can also call third-party modules.

This plug-in module for building blockchain applications is very powerful because it gives developers the flexibility to use the SDK or external modules.

Transactions at the application layer communicate with the Tendermint consensus and the network layer through the application blockchain interface (ABCI, Application Blockchain Interface).

ABCI is a Socket communication protocol that connects Tendermint core (consensus + network) and applications. It is compatible with any programming language, which means that blockchain applications built using the Cosmos SDK can theoretically be written in any language, not just the programming language used by Tendermint's underlying consensus and network layers.

text

Note: The current version of Cosmos mainly supports Golang, and more languages ​​will be added in the future.

All in all, the Cosmos SDK allows developers to build decentralized applications based on the Tendermint core. This application can theoretically be developed in any language and connect to the Tendermint consensus engine through ABCI.

Separating the application layer (Cosnos SDK, ABCI) from the network layer and consensus layer (Tendermint core) allows developers to have greater flexibility in developing various types of applications, and the Cosmos SDK allows these applications to be Any language development (eg Golang) makes the blockchain App development process more like ordinary application development.

This is in stark contrast to developing applications on Ethereum, because the latter requires developers to learn the new language Solidity and overcome many limitations and defects of Solidity, and Golang has more development tools than Solidity, and the development experience is 10 times better .

In addition, all Ethereum Apps operate on a single network. The advantage of this is that these Apps can share the Ethereum standard and the corresponding scale effect; the disadvantage is that all these Apps share the Ethereum consensus layer , will be affected by the size of the newly added application. Additionally, the entire network must be managed as a gigantic unit, bound by governance philosophies and ideological differences, making scaling difficult.

Of course, such benefits come with certain sacrifices: each blockchain application in the Cosmos network must import its own verifier, community, and economic system; it is impossible to directly use all verifiers and powerful communities, and existing economic systems.

in conclusion

first level title

in conclusion