Analysis of Cosmos cross-chain solution

background

Recently, our team is working with customers to discuss the token cross-chain technology solutions for the blockchain projects we have developed for our customers, and to work out specific cross-chain landing schemes with the startup teams in the blockchain cross-chain field.

In the process, we have continuously made new discoveries and accumulations on the emerging technology field of blockchain's side chain / cross-chain and second-tier capacity expansion. In communicating with more customers, we found that more and more cross-chain project opportunities are happening , because sidechain / cross-chain technology and even the entire blockchain capacity expansion technology will always be the industry's hotspot and breakthrough direction. Keep an eye on this technology.

At the same time, we hope that our mastery of technology is systematic , especially the emerging and ever-changing technologies. We plan to release an analysis of the full blockchain expansion technology in the future: including zero-level expansion, one-level expansion (eg Sharding) , Second-tier capacity expansion (eg Sidechain / Crosschain / State Channel) and analysis of some projects and cases.

This blog is an analysis of Cosmos, a cross-chain technology solution and star project for second-tier capacity expansion.

Overview of blockchain cross-chain technology

With the deep development of the Internet, blockchain technology has gradually budded and achieved rapid development. To date, there have been many more mature blockchain platforms such as Bitcoin, Ethereum, EOS, Hyperledger Fabric, Corda, etc. in the blockchain ecosystem. . However, each blockchain platform exists independently. The assets and information on each blockchain platform are isolated from each other, and an island of value for the blockchain is gradually being formed .

However, the formation of value islands is not conducive to the real value of the blockchain . Only when the information on each chain is better connected and integrated can the boundaries of the blockchain be better expanded and its true value. And independent and autonomous blockchains must give up the ability to communicate seamlessly with applications on other chains, because they exist on independent blockchains with different state machines.

Therefore, it is imperative to be able to break through the barriers between various blockchains. This is the origin of cross-chain . But for the exploration of cross-chain, the entire industry is still at an early stage. Cosmos is a star project in the cross-chain field, and it is trying to solve this problem through specific solutions.

What is Cosmos?

Cosmos Introduction

" A decentralized network composed of multiple independent parallel blockchains, each of which uses a BFT consensus algorithm ."

The Cosmos Network is a network of many independent blockchains called zones . The partition runs under the support of Tendermint BFT. Tendermint BFT is a Byzantine fault-tolerant security consensus engine with high performance and consistency, and it can stop the behavior of malicious vandals under a strict fork and accountability mechanism . Tendermint BFT's Byzantine fault-tolerant consensus algorithm is very suitable for use in the public chain under the extended proof of stake (PoS) mechanism. As well as blockchains that use other consensus models, including similar Ethereum based on Proof of Stake (Casper CBC), and Bitcoin can also be connected to the Cosmos network by using the Peg Zone.

Cosmos' first partition was called the Cosmos Hub . The Cosmos hub is a multi-asset proof-of-stake cryptocurrency network, which can adapt and upgrade the network through a simple governance mechanism (voting). In addition, the Cosmos hub can be extended by linking other partitions.

The hub and various partitions of the Cosmos network can communicate through the Inter-Blockchain Communication (IBC) protocol , which is a virtual user datagram protocol (UDP) or transmission control protocol (TCP) for the blockchain. Tokens can be safely and quickly transferred from one partition to another . Instead, all token transfers across partitions go through the Cosmos hub to track and record the total amount of tokens held by each partition . This hub isolates each partition from other failed partitions. Because everyone can connect the new partition to the Cosmos hub, the partition will be backward compatible with the new blockchain technology.

With Cosmos , interoperability between blockchains can be achieved. This is a valuable and valuable Internet network , in which assets are issued and controlled by different validators, and seamless transfer and transactions of cross-chain assets can be achieved without relying on a trusted third party.

What problem to solve

This architecture solves many problems faced by today's blockchain industry, including the interoperability , scalability , and ability to seamlessly upgrade and system performance of blockchain applications. For example, partitions derived from Bitcoin, Ethereum, or other blockchain systems can be anchored into the Cosmos hub. These zones allow Cosmos to scale infinitely to meet the needs of global transactions. In addition, zoning is also fully applicable to distributed exchanges, while exchanges also support zoning operations.

Cosmos is not just a single distributed ledger. Cosmos is designing a set of protocols for the open network of distributed ledgers . This set of protocols will be based on the principles of cryptography, robust economics, consensus theory, transparency, and accountability. A new foundation for the future financial system.

Application scenario

  • Decentralized exchange using Cosmos cross-chain protocol and network — Binance
  • Ethereum Expansion — Ethermint
  • Multi-application integration — Fusion of different application chains and blockchain derivatives

Cosmos architecture anatomy

Introduction to Blockchain Structure

The essence of blockchain is "deterministic replication state machine".

Image source: https://www.preethikasireddy.com/posts/how-does-cosmos-work-part1

The replication state machine has 3 levels in concept:

Image source: https://www.preethikasireddy.com/posts/how-does-cosmos-work-part1

  • Application layer The application layer is responsible for defining state transitions and updating the state machine state after transactions occur.
  • Consensus layer Consensus layer consists of algorithms that are responsible for ensuring that each state machine stores the same state after the transaction is executed (that is, a state machine cannot forge non-existent transactions).
  • Network layer The network layer is responsible for propagating transactions executed on one state machine to all other state machines in the network.
  • The anti-witch attack layer (abstract) attempts to run the decentralized public network to replicate the state machine also requires a fourth layer ("anti-witch attack layer") to ensure that no state machine can damage the network.

Tendermint

Tendermint is essentially an open source, complete blockchain implementation, and is Cosmos' core technology.

You can try to interpret Tendermint in this way. Tendermint can be understood as a modular blockchain software framework that supports developers to personalize their own blockchain without having to consider consensus and the implementation of network transmission.

Tendermint principle

Tendermint official interpretation

Tendermint is software for securely and consistently replicating an application on many machines. By securely, we mean that Tendermint works even if up to 1/3 of machines fail in arbitrary ways. By consistently, we mean that every non-faulty machine sees the same transaction log and computes the same state. Secure and consistent replication is a fundamental problem in distributed systems; it plays a critical role in the fault tolerance of a broad range of applications, from currencies, to elections, to infrastructure orchestration, and beyond. Tendermint consists of two chief technical components: a blockchain consensus engine and a generic application interface. The consensus engine, called Tendermint Core, ensures that the same transactions are recorded on every machine in the same order. The application interface, called the Application BlockChain Interface ( ABCI), enables the transactions to be processed in any programming language. Unlike other blockchain and consensus solutions, which come pre-packaged with built in state machines (like a fancy key-value store, or a quirky scripting language), developers can use Tendermint for BFT state machine replication of applications written in whatever programming language and development environment is right for them.

The official definition of Tendermint is summarized as follows:

  • Tendermint is software that replicates applications securely and consistently across different machines.
  • Tendermint has Byzantine fault tolerance and Byzantine fault tolerance consensus algorithms .
  • Tendermint consists of two main parts:
    • Tendermint Core : Blockchain consensus engine , responsible for data transmission between nodes and Byzantine consensus.
    • ABCI : Blockchain Application Programming Interface , is also a protocol that supports transaction processing implementation in any language.

    Its architecture is shown below:

Consensus layer

Tendermint's consensus mechanism is based on the Byzantine fault tolerance algorithm and resists witch attacks through the PoS protocol .

According to the rules, the verifier must reach a consensus on each block in a round . Each round consists of three basic steps: Propose , Prevote , Precommit , and two subsequent steps: Commit , NewHeight .

! [https://s3-us-west-2.amazonaws.com/secure.notion-static.com/e95d770b-439c-4a3d-8e29-62d71cbf3664/Untitled.png] (https: // s3-us-west -2.amazonaws.com/secure.notion-static.com/e95d770b-439c-4a3d-8e29-62d71cbf3664/Untitled.png) Image source: [https://tendermint.com/docs/introduction/what-is-tendermint .html # consensus-overview] (https://tendermint.com/docs/introduction/what-is-tendermint.html#consensus-overview)

  1. The first is the proposal phase, where a designated verifier proposes a block-the proposers in each round are selected deterministically from an ordered list in accordance with the proportion of voting weight (Stake based) .

The voting ratio in the entire process is calculated based on the Stake ratio. According to the number of tokens pledged by each validator node, each validator node has a different voting weight.

  • Then enter the pre-voting phase-each validator broadcasts their own pre-voting. (Using gossip protocol for broadcasting)
  • When a block receives more than 2/3 of the pre-votes in this round, we call it "polka". Once "polka" appears, proceed to the next stage.
  • Entering the pre-commit phase, each validator broadcasts their pre-commit vote.
    • If a particular block receives more than two- thirds of the pre-vote, it will enter the submission phase, which will add the block to the blockchain and increase the block height . Whenever a new block is added to the block chain, the block height of the block chain is +1.
    • If it fails, either return to the pre-voting phase or return to the pre-commit phase.

    At any height, it may take one and more votes to submit a block. Because the following situations may occur:

  • The designated "Proposer" goes offline when a block should be submitted
  • The block proposed by the proposer violates some predefined rules
  • Tendermint relies on the timeout mechanism to ensure that the block chain will not encounter delays. If the proposed block does not receive more than 2/3 of the pre-votes before the timeout, the new proposer will go through the block submission process again.
  • Network layer

    The network layer is responsible for transaction and data transmission and synchronization.

    btcd P2P Address Book Tendermint's P2P network protocol borrows from Bitcoin's peer-to-peer discovery protocol . More precisely, Tendermint uses btcd's P2P Address Book mechanism . After the connection is established, the new node sends its own Address information (including IP, Port, ID, etc.) to neighboring nodes. After receiving the information, the neighboring node adds it to its own address book, and then relays this Address information to Its neighbors.

    Station-to-Station In order to ensure the security of data transmission between nodes, Tendermint uses an authentication encryption scheme based on the Station-to-Station protocol, which is a key agreement scheme based on the classic DH algorithm and provides mutual Key and entity authentication.

    The general process of S2S is as follows

    1. Each node must generate a pair of ED25519 key pairs as its ID.
    2. When two nodes establish a TCP connection, both will generate a temporary ED25519 key pair and send the temporary public key to each other.
    3. The two nodes multiply their private key and the other's temporary public key to obtain the shared key. This shared-key symmetric encryption key.
    4. Sort the two temporary public keys according to a certain rule, use the Piped160 to hash the two temporary public keys, and then pad them with 4 0s, so you can get a 24-byte random number.
    5. The obtained random number is used as the encryption seed, but in order to ensure that the same random number will not be used twice by the same private key, we set the last bit of the random number to 1, so that we get two random numbers. The high public key uses an inverted random number to encrypt its own message, while the other one is used to decrypt the message of the other node.
    6. Use the sorted temporary public keys to stitch them together and perform a SHA256 hash to get a challenge code.
    7. Each node uses its own private key to sign the challenge code, and sends its public key and signature to other nodes for verification.
    8. After the verification is passed, the authentication of both parties is verified successfully. Subsequent communications are encrypted using shared keys and random numbers to protect data security.

    https://en.wikipedia.org/wiki/Station-to-Station_protocol https://en.wikipedia.org/wiki/Diffie-Herman Key Exchange

    Application layer

    • The application layer can be built in any language .
    • The application layer should implement the complete business logic on the chain.
    • The application layer needs to implement specific interfaces agreed upon by Tendermint ABCI , such as checkTx, deliverTx, etc.

    In general, the application layer is responsible for:

  • Define and submit transactions that need to be recorded on the blockchain
  • After the transaction is submitted through the consensus layer, the blockchain status is continuously updated
  • The application layer is connected to Tendermint Core through the ABCI interface. In abstract terms, the application layer access is shown in the following figure:

    Image source: https://www.preethikasireddy.com/posts/how-does-cosmos-work-part1

    SF

    • Validator Limit On Creation Day, the maximum number of validators will be set to 100. This number will grow at a rate of 13 % for 10 years and eventually reach 300.
    • A validator can replace any Atom holder at any time by signing and submitting a BondTx transaction to become a validator. The number of Atom holders must be greater than the minimum number of valid Atoms among existing validators. When replacing an existing validator, the existing validator will be offline and all of its Atoms will be unbundled.
    • Post-punitive Due to the inherent limitations of PoS , the punishment for malicious validators is obviously post-posed. When a verifier commits an evil act, having certain specific evidence is immediately admissible , such as a double signature at the same height block and round. Its collateralized Atom and its interest in reserves will be significantly reduced. When the validator is unavailable due to network interruption, power failure, etc., if the validator is absent for a certain number of votes , the validator will be offline and his rights will be reduced. Malicious behavior is reported and there is a majority of consensus, and validators will be forced to time out , reducing mortgages and equity . Interestingly, when more than 1/3 of the voting rights of the Cosmos Hub are offline or under review , the network is interrupted at this time. At this time, the Hub must use the hard fork reorganization protocol to recover.

    Tendermint's other features:

    Finality vs. Bitcoin consensus mechanism-the longest chain is legal. Due to the possibility of different miners mining the next block at the same time, Bitcoin may undergo a short-term fork. Any transaction submitted to the chain cannot be 100% confirmed because it may be on the forked chain. It takes several blocks of time for transactions to be confirmed. Probabilistically, this is the 6 confirmation times we often say.

    Image source: https://www.preethikasireddy.com/posts/how-does-cosmos-work-part1

    The Tendermint consensus mechanism is different. When the Validator submits the block, the block is immediately confirmed.

    Image source: https://www.preethikasireddy.com/posts/how-does-cosmos-work-part1

    Variable validator and validator restrictions

    The Tendermint chain will slow down as the number of validators increases , due to the increased complexity of communication. Unlike Bitcoin miners, the Tendermint chain has a validator cap . Take Cosmos Hub as an example. On the creation day, the maximum number of validators will be set to 100. This number will grow at a rate of 13% for 10 years and eventually reach 300. Any Atom holder can become a validator at any time by signing and submitting BondTx transactions, unless the current number of validator groups exceeds the maximum. When a validator is replaced, the replacement condition is that the new validator holds more Atoms than the existing validator holds the least valid Atom. Simply put, whoever has the money is the one who goes.

    Explicit timeout mechanism

    Different from the consensus mechanisms of Bitcoin and ETH, Tendermint has a clear timeout mechanism to ensure that the voting and block generation process will not be delayed. If the pre-voting fails or times out, the new Proposer will initiate the next round of packaging and voting.

    Accountability

    Tendermint uses PoS as an anti-witch attack mechanism. Due to the inherent Nothing At Stake feature of PoS, Tendermint has developed a related responsibility mechanism to deal with this problem.

    • Zoning security and accountability

    Cosmos Hub does not verify or execute transactions submitted to other partitions, so it is the user's responsibility to send tokens to reliable partitions.

    The verifier node and the corresponding principal node are responsible for the results. If the verifier node signs multiple signatures on a fake transaction or fork, the dishonest behavior will punish the verifier node.

  • Network Forking Accountability
  • When more than 1/3 of the node set in the network cooperate evil or enter the review state offline, the Cosmos network will be interrupted, and other non-evil nodes will vote to enter the fork process according to the hard fork agreement, and the margin and equity mortgaged by the verifier nodes Will be confiscated. compatibility

    Tendermint's compatibility is reflected in that it can theoretically support development using any language to develop its application layer and on-chain logic without having to care about the network layer and consensus layer.

    From a higher level, the compatibility of Cosmos is reflected in its compatibility with the deterministic chain (the chain with the deterministic ability to produce a block) and the probability chain. The Hub and the probability chain are bridged through the Peg Zone . This point will be introduced in subsequent chapters.

    Lightweight

    Lightness is reflected in the fact that in addition to the nodes responsible for verification and block production, the remaining nodes do not need to download and store the complete state of the block. They only need to store the block header of the corresponding chain and use Merkle Proof to query specific transactions on other chains. And verification.

    IBC

    IBC (Inter Blockchain Communication) is a protocol used for communication between hubs and partitions.

    Suppose there are now three blockchains, namely "Zone 1", "Zone 2" and "Pivot". We want "Zone 1" to generate a data packet and send it to "Zone 2" through "Pivot". In order for data packets to be transferred from one blockchain to another, a certificate needs to be issued on the receiver's blockchain to clearly indicate that the sender has initiated a data packet to a specified destination. The proof to be verified by the receiver must be consistent with the block header of the sender. This mechanism is similar to the mechanism used with the side chain. It requires two interacting chains to "know" the other party's situation through the two-way transmission of proof data elements (transactions).

    The IBC protocol can naturally be defined as the use of two transactions:

    • IBCBlockCommitTx , this transaction allows the blockchain to prove its latest block hash value to any observer;
    • IBCPacketTx , this transaction can prove that a data packet is indeed transmitted by the sender's application to the hash value of the latest block through Merkle-proof.

    By separating the IBC mechanism into two separate transactions, namely the IBCBlockCommitTx transaction and the IBCPacketTx transaction, we can allow the local fee market mechanism of the receiver's chain to decide which data packet to recognize, and at the same time ensure the complete freedom of the sender. Let it decide how many packets it can send.

    Image source: https://cosmos.network/resources/whitepaper

    In the above case, in order to update the block hash of "partition 1" on the "hub" (or the block hash of "hub" on "partition 2"), the "partition 1" block of the IBCBlockCommitTx transaction must be updated. The Greek value is posted to the "hub" (or the transaction's "hub" block hash value is posted to "partition 2").

    The IBC protocol is currently under development and is not stable for developers. For more information about IBC, we will introduce it in the Cosmos SDK to quickly build a chain . In this article, I will specifically analyze the specific content of the different modules of the Cosmos SDK and the protocols and use procedures of IBC, ABCI and other protocols. In addition, an analysis of the deployment topology of the Cosmos Network is planned in this section.

    Issuance and incentives

    ATOM token

    Cosmos Hub is a multi-asset distributed ledger, which has its own token, Atom . Atom is a certificate of permission for holders to vote, verify or delegate to other validators . Atom can also be used to pay transaction fees. Starting from the genesis block, 1/3 of the total Atom will be issued as a reward to the validators and the trustees who guarantee each year.

    Validator incentives

    Validators need to lock their Atoms to run for validators. In the future, validators can accept any kind of token or combination as a fee for processing transactions.

    Hacking incentives

    To encourage discovery and early reporting of discovered vulnerabilities, Cosmos Hub encourages hackers to post successful vulnerabilities through the ReportHackTx transaction . In this case, the validator and the client will suspend idle, and the Atom of HackPunishmentRatio (default 5%) will be cut and sent to the hacker's bounty address as a reward. The validator must use their backup key to restore the remaining atom.

    Cosmos advantages

    • Cosmos focuses on cross-chain asset transfer, and the design of the cross-chain solution is relatively simple. This simplicity is not derogatory. Under the premise of achieving cross-chain requirements (currently asset transfer), it is a good thing that the protocol and architecture are as simple as possible.
    • BPoS (PoS based on BFT) used by Cosmos is a consensus mechanism with relatively high maturity.
    • Cosmos SDK provides better development support. Developers can quickly "chain" and access quickly with the support of their tools and ecology.
    • Developers can develop Tendermint-specific application chains using any programming language and framework.
    • In the Cosmos Network, each chain runs independently, and has its own validator and independent consensus mechanism, and has an independent security mechanism. And if there are evil events in Cosmos, it will only affect a certain application chain, and will not affect the entire Cosmos network.
    • In terms of governance rules, any node in the Cosmos Network can apply to become a validator to participate in Cosmos network governance as long as it meets certain conditions.
    • In the Cosmos network, for each zone, they can retain their original consensus algorithm, as long as the consensus algorithm meets the ABCI interface.
    • The Cosmos mainnet is live, which gives Cosmos a lead in experience over at least a year.
    • Cosmos supports ecological and multi-party quality projects. For example: Binance Chain, IRISnet, Loom, Terra, etc.
    • Cosmos's TPS can reach the order of 10K.

    Cosmos disadvantages

    • Cosmos does not solve the problem of partition security, or Cosmos avoids the problem of Cosmos security. Once a partition is compromised by a malicious node, the partition can arbitrarily submit fake transactions to the Hub, and Cosmos Hub will not verify the transaction itself. Legitimacy, whether to trust the partition is entirely other partitions or users.
    • In the Cosmos network, each zone has its own validator, and each application chain has independent security. Therefore, there will be cases where multiple application chain validator nodes conspire to commit evil.
    • It is cheaper to do evil in a Cosmos partition. Cosmos uses partitions, and the final security is only responsible for the verifier node of the partition. Considering the N @ S characteristics of BPoS itself, the cost of evil in a partition of Cosmos is relatively low, but it will not affect Other partitions.
    • Cosmos's limit on the number of validator sections helps improve network performance, but reduces the cost of evil.
    • The IBC protocol is still immature and unstable for developers.
    • Since each zone in the Cosmos Network relies on the same Hub, the so-called cross-chain interaction will have some central questions.
    • Cosmos currently only supports asset transfers and does not support cross-chain communication. (In the future roadmap)

    Cosmos indicators

    Tendermint has outstanding performance.

    Taking a commercial cloud platform as an example, the Tendermint consensus is based on 64-bit nodes distributed in seven data centers on five continents. The TPS can reach the order of 10k , and the order submission delay time is 1-2 seconds . It is worth noting that even in extremely hostile environments, such as when a validator crashes or broadcasts maliciously corrupted votes, this high performance of more than a thousand transactions per second can be maintained. See the figure below for details.

    https://raw.githubusercontent.com/gnuclear/atom-whitepaper/master/images/tendermint_throughput_blocksize.png

    Image source: https://cosmos.network/resources/whitepaper

    Cosmos ecology

    Once the Cosmos mainnet was released, the price of its Atom token increased by more than 40 times compared to the time of crowdfunding. At present, there are more and more high-quality projects participating in the Cosmos ecosystem, as shown below.

    These include the top decentralized exchange Binance Chain, the IRISnet Hub as another hub, and the use of Rust language to develop smart contracts in the Cosmos network by the CosmWasm project.

    Concepts

    Hub : refers to the first partition in the Cosmos network, and other partitions will establish a connection with the hub.

    Partition : Refers to an independent chain that connects to the Cosmos Hub and then to the Cosmos network through the IBC protocol.

    Merkle-proof : Merkel proof refers to the fact that a Merkel tree does not need to know other values ​​in a data set to prove that a value belongs to this set.

    Coin Packet : A data packet that packages transaction records in the IBC protocol. BFT : Byzantine Fault Tolerance, Byzantine Fault Tolerance, a consensus mechanism to solve the Byzantine General problem.

    BitShares : BitShares is a global decentralized virtual currency exchange, and its token is BTS Stellar : Created by Jed (founder of eDonkey and founder of Ripple Technology), it is a universal financial platform that allows anyone to receive and pay conveniently .

    BitcoinNG : Bitcoin-NG is a blockchain protocol that can serialize transactions like Bitcoin, but can provide better latency and bandwidth without sacrificing other attributes.

    Casper : Casper is the PoS protocol used by ETH 2.0. So far, there are two co-developed Casper versions in the Ethereum ecosystem: Casper CBC and Casper FFG.

    HD algorithm : It allows the two parties to create a key through an insecure channel without any prior information from the other party. This key can be used as a symmetric key in subsequent communications to encrypt the communication content. https://en.wikipedia.org/wiki/Diffie-Herman Key Exchange Station-to-Station protocol : In public key cryptography, the STS protocol is a key protocol scheme. This protocol is based on the classic Diffie Hellman protocol and provides mutual key and entity authentication. Unlike the classic Diffie Hellman, it cannot prevent man-in-the-middle attacks. The protocol assumes that all parties have a signing key for signing messages, thus providing security against man-in-the-middle attacks. https://en.wikipedia.org/wiki/Station-to-Station_protocol Veyager Node : Client Node Lite Node : Lightweight client node

    Full Node : full node

    Isomorphic cross-chain : refers to the consistency of the security mechanism, formula algorithm, network topology, and block generation verification logic between the cross-chain chains.

    Heterogeneous cross-chain : contrary to the situation faced by homogeneous cross-chain

    Interledger : The interledger protocol (ILP) provides a specified interoperability across different ledger systems through a loosely coupled network of bilateral relationships.

    SPV : Simple Payment Verification is a simple payment confirmation method that can verify payment results without running a complete network node.

    Ethereum 2.0 Mauve : Mauve is a new version of Ethereum 2.0 , mainly to solve its consensus problems and expansion issues. The release of Mauve Paper is called the Purple Book. Pointing directly at the two major problems of Ethereum: the consensus-based mechanism based on proof-of-work is inefficient, energy-consuming, not green, and both the throughput and capacity of the Ethereum public chain system Not enough to support large-scale high-frequency use worldwide.

    Bifurcation accountability : A consensus protocol should be able to provide a certain guarantee mechanism for the system in the event that the fault tolerance is exceeded or the consensus is wrong. Fork accountability has this purpose, it can make a process that leads to consensus errors (such as make the protocol client start to accept different values-that is, forking) to be identified and punished according to the protocol rules, or even to It is transferred to the judicial system.

    LRA (Remote Attack) : Since the validators can change in the Cosmos network, some initial validators will be unbound from the deposit for a long period of time, which will lead them to freely from creation. A new chain is created in the block, and they no longer have a locked deposit, they do not need to pay any fees for this behavior, and this attack is called a remote attack.

    Simple Merkel tree : Merkel tree is a kind of hash binary tree, while simple Merkel tree only targets the basic static list. If the number of items in the Merkel tree is not nth power of 2, some leaf nodes will be on different levels of the tree. The simple Merkel tree tries to have both sides of the tree at the same height, and may be slightly larger on the left. This Merkel tree is called a simple Merkel tree and is used for Merkelization of a block transaction, where the top-level element is the root of the application state.

    IAVL + tree : The IAVL + tree is used to permanently store the key pairs in the application state. This tree can be used to determine the efficient calculation of the Merkel root hash. The balance of this tree is achieved by a variant of the AVL algorithm, and all runs are O (log (n)).

    Post-Punishment : Due to the characteristics of the POS consensus, penalties for malicious validators are all post-positioned. That is, if it is judged that a block is maliciously generated, a part of the token or security deposit will be used as a penalty. But all these penalties and regulatory measures only happen after the fact, unlike the invisible constraint that the PoW consensus requires computing power to produce blocks directly.

    References

    1. Cosmos Network-Internet of Blockchains
    2. cosmos / ics
    3. cosmos / cosmos-sdk
    4. How does Cosmos work? How does it compare to Bitcoin and Ethereum? (Pt. 1)-Blog by Preethi Kasireddy
    5. How does Cosmos work? How does it compare to Bitcoin and Ethereum? (Pt. 2)-Blog by Preethi Kasireddy
    6. Deep analysis of Tendermint and rapid integration into the Cosmos ecosystem
    7. How the Cosmos blockchain works, Part-1: Comparing Cosmos with Bitcoin and Ethereum

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

    Share:

    Was this article helpful?

    93 out of 132 found this helpful

    Discover more