Cosmos is generally regarded as an ‘interoperability solution’ that connects multiple block chains. However, interoperability is one of the goals of the Cosmos team, and if you see Cosmos as a simple interoperability solution, you miss out on the essentials of Cosmos. Cosmos is not simply a project created to serve as an interoperability solution. In order to properly explain the true value of Cosmos, I would like to explain the vision of Cosmos from the beginning.
A simple block chain is a deterministic state machine that is copied from nodes that do not need to trust each other. What the state means depends on each application (for example: the token balance in each account is ‘state’). And, it is the transaction that changes this state. (When a coin is transferred from account A to B, the transaction is propagated to the block chain, and the coins ‘balance’ of A and B accounts corresponding to ‘state’ Change). From a structural point of view, a block chain can be divided into three conceptual layers.
▪ Networking: The layer that is responsible for propagating transactions
▪ Consensus: A layer that causes the validator nodes to agree on a list of transactions to be processed next
▪ Application: The layer that updates the status according to the transactions agreed upon by the probes (the role of adding the transaction information contained in the block to the block chain)
Structure of simplified block chain
The networking layer allows each node to exchange transactions with each other. The consensus layer makes it possible to agree to change the state recorded in the block chain held by each node based on ‘all the same transactions’. In the case of the application layer, the verifier processes agreed transactions. When a transaction that has passed the assurance of the assurer and the existing state are passed to the application layer, the application layer changes the existing state value to the new state value. In the case of the bit coin, for example, ‘state’ means the ‘bit coin balance’ in each account (‘bit coin balance’ means exactly a list of UTXOs, where UTXO is the unused transaction output value [Unspent Transaction Output], but it is referred to as ‘bit coin balance’ for the sake of brevity. The transaction changes the ‘state of being’ bit coin balance ‘. In the case of Ethernet, the application is a virtual machine. Each transaction is passed to the virtual machine, which then modifies the state by the smart contract, which is called by the transferred transaction.
Before Tender Mint appeared in the world, I had to build all three layers from scratch to make a block chain. So to avoid this tedious task, most developers preferred to fork block codes into bit-coin code, but this was accompanied by the disadvantage that the block chains created were limited to the limits of the bit coin protocol. With the advent of Etherium, it is now much easier to create distributed applications as Etherium’s virtual machines can easily implement their own logic through smart contracts. However, Etherium did not simplify the process of developing the block chain itself. Because Go-Ethereum is a single block chain that is hard to fork like bit coin. Tender mint is needed at this point.
The purpose of Tender Mint is to provide a versatile engine that can be used to create a variety of block-chain applications. For this purpose, Tender Mint provides users with a networking layer and a consensus layer of the block chain. If there is a tender mint, developers only need to develop the application layer when building the block chain. This shortens the development time of hundreds of hours required when developers assume that they build block chains from scratch. Tender Mint is also the name of the Byzantine Fault Consensus Algorithm used in the ‘Tendermint core engine’. If you are more concerned with the protocol, you can refer to this podcast.
Structure of Tender Mint ABCI
The Tender Mint Core Engine is connected to the application via a socket protocol called the Application Block Chain Interface (ABCI). Because this protocol can be developed in any computer language, developers can choose the language they want to use to build the application. This is not all . Tender Mint’s goal is not to provide developers with tools to create simple test-block-chain applications, but to provide a tool for developing very high-performance block-chain applications. The following features make the Tender Mint a state-of-the-art block chain engine:
▪ Public or private blockchain capable: Tender Mint is a block chain engine that deals only with the networking and consensus layers of the block chain. That is, the Tender Mint engine handles the process of agreeing that nodes propagate transactions and that the verifiers add a set of identical transactions to the block chain. The rules and regulations such as ‘How are the auditors selected?’ Are determined at the application layer. Therefore, developers can create both public and private chains based on Tender Mint. If the application layer chooses ‘how many coins are tied’ to the selection criteria of the verifier, the corresponding block chain is a POS (Proof-Of-Stake) block chain. However, if at the application layer, the verifier specifies that only a pre-approved restricted subject can be a validator, then this block chain becomes a private block of POA (Proof-Of-Authority) -based chains. Developers can freely set the criteria for selecting a validator for their block chain.
▪ High Performance: The Tender Mint core has a block time of about one second and processes thousands of transactions per second.
▪ Instant finality: The feature of the Tender Mint consensus algorithm is immediate completeness. This means that a fork does not occur unless a verification of ⅓ or more is performed by Byzantine action. Users can be assured that their transaction is completed as soon as the block is created.
▪ Security: The Tender Mind Consensus has not only resistance to Byzantine disability, but also accountability. If a fork occurs in the block chain, it is possible to determine which verifier is responsible for the fork.
Another advantage of TenderMint is that it can be used to port existing block chain code to the Tender Mint engine because ABCI is modular. For example, you can take Etherium’s virtual machine code and plug it in over the tender mint. In fact, we did this job and named the result ethermint on the EtherMent virtual machine on the tender mint. Ether Mint works the same as Etherium. However, all the advantages of the above-mentioned Tender Mint can be utilized. Ether tools such as Truffle and Metamask are equally usable in Ether Mint, and existing Ether Smart Controct Codes can also be used in Ether Mint without additional effort. Do.
We can now use ‘Tender Mint’ to develop block chains. With TenderMint, developers can easily develop high-performance block chains without worrying about networking and consensus layers. The application layers of these developed chain chains are all different, but all have the same networking and consensus layers. For this reason, block chains based on tender mints are easily connected to each other.
The link between the Tender Mint Block Chains is accomplished through a protocol called IBC. IBC is short for Inter-Blockchain Communication Protocol. The IBC makes it possible for heterogeneous chains to exchange value (eg, coins) with each other based on the immediate block integrity of the Tender Mint. How the IBC works and how it is used to form the cosmos of the block chain Internet is described in the white paper.
First, we need to understand what a heterogeneous chain means. The heterogeneous chain has the following characteristics.
▪ Different layers: The heterogeneous chains have different layers. In other words, heterogeneous chains are chains with different networks, consensus, and application layers. This difference is mainly caused by limitation of communication between block chains, and communication among block chains becomes very difficult if the consensus does not have fast completion. Proof-of-work (POW) chains are classified as chains that do not have fast completion because they are stochastically complete.
▪ Sovereignty: All block chains are maintained by a set of validators. The verifiers play a role in agreeing which transactions to include in the next block to be committed to the block chain. In the case of POWs, verifiers are called miners. A block chain with sovereignty means that the block chain has a unique set of checks. In most cases, it is very important for each block chain to have a unique sovereignty, since verifiers are responsible for changing the state of the block chain. In the case of Ethernet, each application has a very limited sovereignty because all applications are operated by the same verifier.
IBC makes it possible to exchange coins between different chains. This means that the block chains have a different set of checks and interoperability between block chains, even if the application leers created on the block chain are different. This is very important in that it maximizes the flexibility of the block chain. For example, when an IBC is introduced, coin exchange between a public block chain and a private block chain becomes possible.
How does IBC work? (How IBC works)
The operation principle of the IBC is very simple. Consider the case of sending ten ‘X coins’ from block chain A to block chain B. First, these 10 X coins must be ‘locked’ in the chain A to prevent them from moving arbitrarily. Then the fact that ‘ten X coins are locked immovably in the block chain A’ is transferred from the A chain to the B chain. Then chain B verifies how the ‘set of verifiers’ of chain A has changed. If two-thirds of the verifiers in chain A sign the facts (ten X coins are locked in chain A), they are validated as validators in chain B and issue ten X coins to chain B .
A similar mechanism applies to the process of returning 10 X coins in chain B back to chain A to unlock the coin locked in chain A. A more comprehensive description of the IBC is provided in the document. Currently, the IBC protocol is optimized for value movement between heterogeneous block chains and can support heterogeneous block-body human logic movement in the future.
Cosmos – Hubs and Zones
We have a protocol called IBC that enables coin exchange between heterogeneous chains. How can you make the Internet of a block chain based on this?
One way is that all block chains on the network are directly connected to each other through the IBC. This approach has two problems.
▪ Number of connections: If 100 block chains are present on the network and they are all connected directly through the IBC, a total of 4,950 contact points are required. That is, when the number of block chains on the network increases, the number of contact points required increases exponentially.
▪ High trust requirements: If chain A receives the coin directly from the block chain that issued the coin, only one level of trust is required (only the block chain that issued the coin is trusted). That is, chain A only believes that the verifiers of the chain that sent the coin will not lock the coin by the quantity sent, or do not do double spanding. However, if chain A receives a coin that it has not issued in that block chain, chain A is required to have higher reliability. In order to trust the coin from the position of the chain A receiving the coin, the assumption is that the coin is properly locked in the block of coins issued, and that there is no double spanding in every block chain the coin has passed through It is because we have to trust the condition. As the number of block chains that the coin has passed increases, the block chain that receives the coins is required to be more reliable. This is not realistic. To prevent this problem, you can unlock the coin in the block chain where the coin is generated, and then send it back to the other block chain (the method of receiving only the coins sent from the block chain that issued the coin unconditionally). But there is a better solution than this.
To solve this problem, Cosmos proposes a modular structure of two types of block chains (hub and zone). A zone generally refers to a different block chain, and a hub refers to a special block chain connecting zones. When a zone is connected through a hub and IBC, this zone can exchange coins with other zones connected to the hub. This allows each zone to have only a limited number of hubs and a limited number of IBC connections. This allows the hub to avoid double spandering of zones, and each zone can only trust the hub it is connected to when it receives another coin and the zone where the coin is created.
Cosmos – Cosmos hub and Zones
Cosmos Hub is the first hub launched in the Cosmos Ecosystem. The Cosmos hub is a POS block chain based on a coin named Atom, and many coins can be used, including Atom and Photon, as a transfer fee for the block chain. With the launch of this first hub, the cosmos network begins.
Only the tender mint-based chain seems to be able to secure interoperability in the cosmos ecosystem structure so far described. However, Cosmos ecosystems are not limited to tender mint-based chains. In fact, any block chain can be linked to the Cosmos ecosystem.
A chain with fast completeness and a chain with probabilistic completeness are connected to the cosmos ecosystem as follows.
Block chains using consensus algorithms with fast completion can accept IBCs and connect to the Cosmos network. For example, if Etherium’s consensus is converted to Casper FFG (which is quickly finalized), it will be able to accept the IBC in Casper and connect it with the Cosmos ecosystem.
Linking a chain that uses consensus that is not as fast as a POW to a Cosmos ecosystem can be more difficult. A specialized proxy chain named Peg-Zone is used to link these chains to the Cosmos ecosystem.
The peg zone is a block chain that tracks the state of other block chains. The peg zone itself is compatible with IBC because it has a fast completion. The peg zone is responsible for the fast completeness needed to link the block chain to the Cosmos ecosystem. Let’s take a closer look at this example.
We would like to link the POW-based Etherium to the Cosmos ecosystem to enable coin migration between cosmos and etherium. Since the POW-based Ether does not have a fast completion, a peg zone is needed to connect the Etherium and Cosmos.
First, the peg zone must decide how long to wait until it is complete in the original chain. For example, a peg zone can establish a criterion that about 100 blocks must be created before the integrity of the original chain is secured. When a particular contract is created in the Ethernet main block chain and propagated over the network, the peg zone keeps track of that particular contract. If a user wants to send a coin from Etherium to Cosmos, the user actually sends ether to this contract address. Then, the Etherium that came into the contract address by the agreement written on Etherium is locked, 100 coins are issued in the Peg Zone with 100 Etheriums value after 100 Etherium Blocks are created. The same mechanism occurs even when coins are sent from Cosmos to Etherium (Cosmos coins are issued in ERC20 form on Etherium). The Tender Mint team is currently creating Peggy, a peg zone linking ether chains and cosmos.
The problem with the peg zone is that you need to create a peg zone that is tailored to match each block chain. It is relatively easy to create an Etherium peg zone because it is possible for an account-based structure, smart contract. But making bit coin peg zones is more difficult. How to make a bit coin peg zone goes beyond the scope of this article. However, it is theoretically possible to create a bit coin peg zone, and a detailed description of the peg zone can be found in the corresponding document.
Etherium block chain connected with Cosmos ecosystem through Peg Zone
Until now, we have been working hard to design the following tools.
But is it still too easy for developers to develop a block chain? At this point, if developers use Tender Mint core, you can create a block chain by creating only the application layer. This means that it is already easy enough to develop a block chain. But we want to make it easier for developers to develop a block chain.
Developing applications based on block chains may not be easy. Therefore, cosmos-SDK becomes necessary. Cosmos-SDK is a generalized development tool for developing secure block-chain applications on top of tender mints. This has two important principles:
▪ Composability: Cosmos-SDK’s goal is to create a modular ecosystem that allows developers to easily create side chains by combining modules without having to code all the functionality of the application directly. Anyone can create a module that is used in Cosmos-SDK, and you can simply apply the already created module to your own application. For example, the Tender Mint team is building basic modules such as staking, IBC, and governance that are needed to run Cosmos hubs. These modules can be used by any developer who wants to create block-chain applications using Tender Mint. Developers only need to develop their own modules that are not yet developed. As a development team at Cosmos Network, we expect the module ecosystem to expand rapidly and we expect it will be easier to build complex block-chain applications. Documents describing how to use Cosmos-SDK will be available soon.
▪ Capabilities based security: Because Capabilities limit the boundaries of security between modules, developers can further delve into the possibilities of module configuration and limit the extent to which malicious attacks and unanticipated interactions can occur. Features are described in detail in the documentation. We will publish a document detailing the function-based security used by Cosmos-SDK.
Simplified structure of block chain based on cosmos-SDK
Cosmos-SDK has useful tools such as command-line interface, REST server, and HSM library.
Finally, cosmos-SDK is designed in the same module as other cosmos tools. This allows developers to easily develop block chains on the Tender Mind consensus engine. Cosmos-SDK can also be used in other consensus engines. In the future, we expect that various SDKs designed with completely different architectures will be developed and compatible with multiple consensus engines. There is a lot of block chains in a single ecosystem called cosmos (all within a single ecosystem: Cosmos).
We can now easily create block chains and connect them together. So what’s left? Perhaps you will recall the title of this session, “scalability”. Today ‘s block chain is not scalable. This is one of the biggest problems in the block chain ecosystem.
Cosmos offers the following two extensions:
▪ Vertical scalability: Vertical scalability means a method of increasing the scalability of the block chain itself. By opting out of the POW and optimizing each component, the Tender Mint core can handle thousands of transactions per second. The factors that reduce processing performance usually occur in the application itself. For example, the transaction processing performance of applications such as virtual machines (Etheric’s virtual machines) is significantly lower than applications whose state changes and transaction processing functions are directly linked to the block chain (applications made with Cosmos-SDK). This is one of the reasons that application-specific block chains are needed (other additional reasons are described in the documentation).
▪ Horizontal scalability: No matter how optimal the consensus engine and application are, the transactional capacity that can be handled in one chain reaches the limit at which it can no longer grow. This is the limit of vertical scalability. To overcome this vertical scalability, we introduced multi-chains architectures. At the heart of the idea is that multiple chains in a horizontal relationship run the same application by the same set of checks, which in theory makes it possible to have theoretically indefinitely scalable. The details of this horizontal scalability are very complex and are not covered in this article.
Cosmos will support vertical scalability at the time of launch, and this alone will greatly increase the scalability of the block chain. A horizontal scaling solution will then be introduced.
There may be questions here. Why can I create a distributed application on a block-chain virtual machine, and if this block-chain can be scalable, why create a new block-chain? Considering that the majority of decentralization applications have been created on block chains that currently support virtual machines, such as Etherium, this is a natural question. We think that the main reason for this phenomenon is that it is more difficult to develop a block chain than developing a smart contract application. But it is not anymore. Cosmos-SDK makes it easy for anyone to create application-specific block chains. Why the application-specific block chain is necessary and why this is reasonable is detailed in the document that explains the content. If a developer does not want to create their own block chain, it is possible to develop applications through smart contracts in the same zone as Cosmoth-compatible EtherMent.
We have covered a lot of things about cosmos so far. Let’s briefly summarize and summarize what the cosmos is in three sentences.
Above all, cosmos is not a product. Cosmos is a modular development tool and one that is made from adaptable, interchangeable tools ecosystem . I encourage developers to join in the realization of the original purpose of the block chain technology by improving already developed tools and creating new tools. These tools will be the basis for creating a decentralized Internet and designing the future of global finance.
We have had time to learn Cosmos ‘vision and Cosmos’ potential. From now on, we will explain how cosmos is used with clear examples of use.
Consider the case of creating ICO zones in Cosmos. The ICO zone created at Cosmos is decentralized and can accept any cryptographic currency that is operated transparently. Also, the ICO zone is extensible and does not run with other distributed applications (it runs as a stand-alone application without an application like a virtual machine). That is, users can participate in all ICOs through one high-performance platform.
We want to create an ICO zone using Cosmos-SDK for developers’ convenience. The ICO zone we will create is a public POS zone, and the following modules are used.
▪ Staking: Modules to handle POS
▪ Accounts and Bank: A module that keeps track of each user’s coin quantity
▪ Governance: Modules for software upgrades and maintenance
▪ IBC: Modules for sending and receiving coins
Fortunately, all the modules needed to create an ICO zone have already been developed. We do not need to do any new coding for the ICO zone. Now I just need to create the ICO modules I need to create specialized applications. This is not difficult (documentation will be forthcoming shortly describing how to code Cosmos-SDK modules).
This is all! Coding a public, interoperable, and scalable block chain is now possible simply by combining modules. What remains is front-end development for block-chain applications. This is not so difficult.
If we have an open source spirit, we can make free the ICO module code and documentation that we have developed so that every developer can use the ICO module in their applications to use that functionality.
Implementing a decentralization exchange can be called the “holy grail” of cryptographic exchanges (long awaited). In a decentralized exchange, users always control their own assets. In other words, the decentralization exchange is totally different from the existing centralized exchange with the systems where users entrust their assets to exchange operators and trust them.
It is quite simple to create a decentralization exchange on cosmos. Exchange block chains are responsible for the keeping and clearing of funds. Order book matching can be managed by centralized operators to provide a user experience and a rich order book that can satisfy users (the details are described in detail in that document).
We want to support court money in the de – centralization exchange we design. However, because the legal currency is not free from regulations, it is difficult to issue on the public block chain. Because of this, our decentralization exchange will have a two-chain infrastructure. One chain will be a private Proof-Of-Authority (POA) chain responsible for the legal currency, and the other chain will be responsible for cryptographic transactions in the public POS chain. Both of these chains are based on the Tender Mint consensus engine. These two chains are interconnected via the IBC and can be connected to the Cosmos hub.
What do you need to create a decentralized exchange with such a complex structure? I do not need much more than I thought. Staking, governance, account-banking, and IBC modules are already implemented. The modules that need further development are:
▪ A Proof-Of-Authority module: A module for setting up the assertion set of the private block chain that deals with the legal currency
▪ A FIAT-token module: Modules that issue and transfer statutory currencies to block chains within the jurisdiction’s legal framework
▪ A settlement module: Module for concluding a coin transaction between two chains
Once these three modules are added, we can construct the underlying block-chaining architectural layer needed to create a decentralized exchange.
Consider the case of seven US state governments trying to issue their own local currency. Each state will manage the local currency issued by the state by operating a block chain connecting the cities of its state. It is very easy to make these block chains on cosmos. There is already an account-bank module and a governance module. What remains is to create a POA module so that each state can operate their own private chain.
Now, let’s imagine the need to have interoperability (exchange of coins) by connecting the private chains that each of the seven states run together. It is very easy to solve this need. The problem is solved by launching a ‘hub’ that connects all the state-run private block chains. There are seven private chains independently operated by each state and one hub connecting them. The process involves attaching an IBC module to seven private chains and connecting seven chains to the hub through an IBC module.
Through this, a total of 7 local currencies are issued, and 7 local currencies are distributed and available over 7 states. What if the seven state governments want their local currency to be exchanged with a cryptograph based on a public block chain? This is not difficult. The problem is solved when the hub connected to the 7 private chains is connected via the IBC to the Cosmos hub. If this connection is successful, the cipher money can flow into the seven-block chain through the local hub. Thus, the structure of connecting and exchanging coins through IBC has a great advantage. Even if the cosmos hub is down, the local hub still functions. In other words, if the cosmos hub is down, the seven state-run block chains can not send coins through the cosmos hub, but coins and currency exchanges between them still remain unaffected through the regional hub. This is the strength of the structure of the IBC, and through the IBC each block chain is able to secure interoperability with other block chains that maintain their own sovereignty.
So far I have heard some concrete examples. The potential of cosmos applications is virtually limitless. Cosmos has been modularized, adaptable everywhere, and designed extensively. Cosmos exists to make the promise of the block chain to the world. Whatever block chain you create, you’ll find tools that make it easy to build on top of Cosmos. This is not the story of the future in a few years, now It is possible.
top cryptocurrency news in your mailbox