First, let me introduce the background of the Cosmos project. The Cosmos project is a public chain project initiated by the Tendermint team in Silicon Valley. The Tendermint team and their products will be introduced later. The goal of the Cosmos project is to build an Internet of blockchains and construct a deeply integrated token economic ecosystem through cross-chain token transfer technology.
The Cosmos project completed its ICO in April 2017, raising $17 million worth of bitcoin and ether at the time. A total of 200 million Atom tokens will be issued. The distribution is: ICO sales account for 75%, angel investors account for 5%, ICF (Inter-chain Foundation) foundation 10%, and the team retains 10%. The base price of the ICO is 10 cents, with discounts of 25% and 15% for strategic investors and early investors, respectively.
The Cosmos mainnet was originally planned to be launched at the end of 2017, but it has now been postponed to the end of February this year. Tokens will only be traded on exchanges after the mainnet is launched. It is not clear which exchanges will be listed first.
Unfortunately, there is already a public chain project called Atomic Coin, its token symbol is also Atom, but it is not Cosmos, everyone must be clear. If you did not participate in the ICO, Cosmos' Atom tokens can only be purchased after the mainnet online exchange at the end of February this year.
Cosmos was a relatively popular project in April last year. At that time, the ICO was sold out and quickly ended. Not many people know about it in China, because their team has always been relatively low-key. At that time, in some technical communities in Hangzhou and Shenzhen, some teams that understood blockchain cross-chain technology participated in this ICO. For some detailed information about the background of Cosmos, I will send you a link. After the online communication, if you are interested, you can read it yourself.
https://github.com/cosmos/cosmos/blob/master/PLAN.md
Let's take a look at the cross-chain technology Cosmos. The Tendermint team is the first to develop the BFT consensus engine and the first to propose the concept of cross-chain. It was proposed around 2015, so the Tendermint team is still quite advanced. One of the earliest motivations for the team to do the Cosmos project was to create a so-called decentralized blockchain technology, but it needs to rely on many centralized exchanges for currency transactions. There are many problems with centralized exchanges, so is there no problem with decentralized exchanges? In fact, there is also a problem. It seems that it is a decentralized exchange based on Ethereum. For example, EtherDelta can only conduct currency transactions between ERC20. But in fact, if you look at the top 30 exchanges in coinbase Few of the tokens are ERC20 tokens. Another problem with decentralized exchanges is that they rely on centralized gateways. Therefore, one of the motivations of the Cosmos team when they wanted to do this project was how to transfer this token to a decentralized exchange for trading through the decentralized blockchain technology itself. I think this is their earliest an original intention.
So what are some basic conditions for cross-chain tokens? What is the fundamental difference between the transfer of tokens across blockchains and the transfer of traditional Internet information across subnets in the Internet? The fundamental difference is actually that the latter involves value transfer. So, this is all about money, and money is very important. There should be no mistake in this matter. In fact, there are two very important conditions here. One is to initiate cross-chain transfer, the source chain, which initiates The proof of the real validity of this cross-chain token transfer transaction is very critical, and more importantly, any third party must be able to independently verify the validity of this transaction. This puts forward some requirements for the characteristics of the blockchain. The most important are two: one is that the consensus algorithm must be timely and final. The so-called timely finality means that once a new block is formed after the consensus is passed, then this block is Ultimately, it will not be overturned or forked again in the future. That is very different from the traditional PoW-based consensus mechanism. Second, there must be an efficient and independent proof method for transaction submission confirmation, which is basically based on Merkle proof. Of course, blockchains that lack these features, such as PoW-based Bitcoin and Ethereum, can also be connected to the Cosmos network through a bridge mechanism called Pegged Zone, which is a kind of anchored partition. I will expand on this later. Talk a little bit.
Understanding these characteristics mentioned above partially explains why the Tendermint team first proposed to do cross-chain. Because the Tendermint team is the first consensus engine based on PoS in the world. His PoS engine has the following characteristics. First, it is Byzantine fault-tolerant, which is the so-called BFT. Through a distributed consensus algorithm based on a two-round voting mechanism based on the assumption of weak synchronization, it can tolerate up to one-third of Byzantine node. The second feature is the timeliness and finality. That is, the latest block formed by the consensus is the final block. This finality is not based on probability like PoW. The third is that its consensus efficiency is very high, and it can reach thousands of TPS in seconds.
In addition, both public and private chains can use the Tendermint consensus engine. For example, the more famous Hangzhou Secret Ape Technology in China, the alliance chain product CITA made by them. The bottom layer uses Tendermint as the consensus engine. The last point Tendermint is the reference basis for some other important PoS systems, including the Casper that Ethereum is now ready to cut. This mechanism is also a large number of reference Tendermint designs.
Another important feature of Tendermint architecture design is that it packages the consensus engine and the underlying P2P network layer to form a software called Tendermint Core, which is the core function of the Tendermint product. Tendermint extracts the most commonly used functions related to consensus at the bottom layer into a very refined product, and the logic of the remaining application layer is implemented by application developers. That is to say, the development of the blockchain is divided into two parts: one is the underlying common consensus engine and the network layer (this is implemented by the Tendermint team). The other is the application logic to be completed by the blockchain, which is implemented by the blockchain development team.
Such an architectural design is very interesting. If we design based on this architecture, what should we do to realize Bitcoin? Tendermint defines a set of callback interfaces between the consensus engine and application logic, namely socket-based ABCI. So let's take a look at how to implement Bitcoin based on this architecture. Then the underlying consensus algorithm and network layer should implement the peer-to-peer Gossip protocol between nodes to share transactions and blocks. The other is to maintain an authoritative and immutable transaction order, which is what we commonly call the blockchain. The application logic layer is responsible for maintaining this UTXO database, verifying the digital signature of the transaction, and ensuring that it is a valid transaction. In addition, it can prevent some other invalid transactions, such as trying to spend some non-existing UTXO, or even double spending. The other is to allow the client to query the UTXO database.
Here's another example of an ABCI application, a project also done by the Tendermint team: Ethermint. It is actually Ethereum and Tendermint, two words combined. What it actually does is to remove the PoW consensus algorithm underlying the Ethereum Go-Ethereum code, and then integrate it with Tendermint through the ABCI protocol callback interface. In this way, it realizes an efficient Ethereum based on PoS. The existing Ethereum smart contracts and all Ethereum client tools, development tools, and smart contract calling tools can all be obtained intact. side to use.
The Cosmos SDK is the core product the Cosmos team is working on. You can see that it actually adopts the same ABCI application architecture. It is based on Go language to implement a simple blockchain. Common functions that need to be implemented when we want to implement a blockchain based on PoS: such as a multi-token account system, and everyone entrusting their tokens to witness nodes, responsible for consensus and block generation, and chain some governance. Some of these common functions have been implemented in the SDK.
In this way, if you use the Cosmos SDK to implement your own blockchain, you only need to implement the application logic of one blockchain. The basic functions have been implemented in the SDK. If your application needs some customized development, you can use an extension mechanism in the Cosmos SDK. Write related Plugins according to the Plugin mechanism. So Cosmos SDK is an architecture system that can quickly develop blockchain.
With the above knowledge, let's take a look at what the Cosmos project wants to do. This is a very abstract system architecture. The big circle in the middle is the Cosmos Hub, which we call the Cosmos Hub. Each of these small circles on the side represent other blockchains. These blockchains will be connected to the Cosmos Hub through the communication protocol of the interconnected chain. For example, some chains like Bitcoin, Monero, Ethereum, and other decentralized exchanges can theoretically be connected to this Hub.
Cosmos believes that in the future our world cannot be dominated by one or two blockchains, and there will be more blockchains, each of which will complete its own unique functions. We will live in a multi-chain multi-currency world in the future. What Cosmos wants to do is to realize the basic function of token transfer, and then add some extended functions to form such a unified ecosystem with a highly integrated token economy.
The above is the approximate realization of the architecture. What if we take a closer look? As you can see in this picture, these chains are all based on the Cosmos SDK. The blockchain implemented in the middle is called Cosmos Hub, which is the big circle in the conceptual diagram above. In fact, every place in this chain represents a blockchain, although it draws one of the blockchains. A schema for nodes. But you can imagine it as a structure of several chains, the middle is the Cosmos Hub, there can be Ethermint on the side, as well as a private chain based on Tendermint, a permissioned chain, or another decentralized chain Exchange public chain. For these PoW-based chains, they can be bridged together through a Pegged Zone.
Everyone has noticed that IBC is annotated at the connection between different chains, that is, a protocol for cross-chain communication. This protocol is very critical, because the cross-chain transfer of tokens is achieved through it. So, let me give you a brief introduction to what the IBC protocol is about.
The IBC protocol defines the two main types of transaction packets. One is IBCBlockCommitTx. What it does actually is to transmit the header information of the latest block of the initiated chain to the target blockchain. Such a target blockchain obtains the latest Merkle Root in this chain. Another packet type is IBCPacketTx. This is the transaction information that transmits the cross-chain token transfer. This transaction information is actually the payload information actually contained in the message body. This message is in a Merkle Proof on the original chain.
Taking the left as an example, if the header of the latest block of Zone1 is passed to the Hub, then the Hub will know the Merkle Root of its latest block. When it then receives an IBCPacket, it can use the Merkle Root in the Packet to verify that the Merkle Proof it contains is correct. Of course, the implicit condition is that the Hub knows the current valid verifiers of Zone1, which means that the Hub knows the public keys of all the verifiers of Zone1. It can judge that the information in the header is valid, because each block header is signed by the private keys of more than two-thirds of the validators.
You can see that this diagram is actually a logic sequence diagram. Then you may want to know how this message is transmitted from Zone1 to Hub, and from Hub to Zone2, who initiated this message transmission, which actually involves a concept called Relay, which is actually different Between the two blockchains, there is a third-party independent program called the relay program, which is responsible for generating the Merkle Proof from the original chain, assembling it into a Packet, and then ferrying it to the target chain. I will post the specific architecture diagram for you now.
This diagram is a little more complicated. Let me explain it a little from left to right. If the client wants to initiate a token transfer from Zone A to Zone B. In fact, the first step is to construct such a transaction. After the transaction is sent to the blockchain of Zone A, Zone A will logically process the message, mainly including checking that the client who initiated the transaction is in Zone A. Is there a sufficient number of such tokens in it? If it is valid, go to the second step, generate a corresponding transaction and put it in the message queue facing this Hub. This message queue is shown here as a first-in, first-out queue, but in fact it is implemented as a Merkle Tree in this queue.
In the third step, the relay program acts as a client of Zone A, and it actually monitors this queue all the time. When it sees a new message coming in, it generates a Merkle Proof. Then use this Merkle Proof as the payload of IBCPacketTx. The third step is to send it to this Hub. The Hub verifies this message, because the Hub has all the currently valid IBCBlockCommitTx and all Validator public keys of Zone A, that is, the Merkle Proof of all transactions. So it can verify whether the received Merkle Proof is valid. If it is valid, then the fourth step: put a Message in the Outgoing Queue of Zone B.
The fifth step is very similar to the third step, that is, there is another relay program between the Hub and Zone B. The relay program is the same. It is also monitoring the queue in the Hub. When it finds new messages When it comes in, it constructs a Merkle Proof that the message is in the Hub. Then pass this Merkle Proof to Zone B by message. The next step is that the result of the processing will be returned to Zone A in the form of a receipt according to the process of 6789. This is a highly simplified process, and there are actually many technical details in it, which we can't start talking about today. But this diagram basically accurately reflects the working principle of IBC.
If you still remember the Peg Zone I just talked about, if we now want to transfer tokens from Ethereum to a Hub or transfer the tokens back to Ethereum from the Hub, what should we do? The so-called Peg Zone mechanism. Let me tell you about a project called ETGate. This project is a winning project of a Korean university student named Joon in the Cosmos hackathon. This is not implemented in the way of blockchain for the time being. It just writes a gateway program. What the gateway program does is actually to transfer tokens between Ethereum and a Tendermint partition.
That is, when you want to send tokens from Ethereum, there will be a smart contract in Ethereum. This is a smart contract written by this college student. This smart contract will receive transfer requests. When it receives a transfer request, it generates an Event, which is an event in Ethereum. ETGate as Ethereum's light client extracts Merkle Proof after sufficient block confirmation. Including this Merkle Proof certificate is sent to Tendermint. After Tendermint receives the transaction and proves that the Merkle Proof is correct, even if the transfer is successful. This is the relatively simple process.
反过来也是一样，Tendermint分区如果要向以太坊转代币的时候，就会在Tendermint分区里发起一个定制的一个转账交易。ETGate作为Tendermint分区的一个轻客户端，它将转账交易的证明发到以太坊智能合约。智能合约验证这个证明无误，算转账成功。当然这个也是有一个前提就是ETGate会在以太坊和Tendermint分区之间不断的发送两个分区最新的区块头。ETGate只是一个网关程序，Tendermint分区如果说加以扩展，可以作为一个Peg Zone，但前提是你要对它增加IBC协议的支持，这个细节我就不展开了。
基于Cosmos这个技术的区块链互联网应该有什么样的特性呢？这个特性有很多，那么我今天就简单讲两个特性，一个是可扩展性，一个是自主性。
扩展性分成垂直扩展性和水平扩展性，垂直扩展性主要是针对单节点，就是区块链里单节点的性能处理交易的能力，那么基于PoS共识机制大大的改善了垂直扩展性，所以吞吐量TPS得到了提升。通过Hub加Zone的方式通过多链获得水平扩展性。
针对垂直扩展性，Tendermint团队对Tendermint Core做了一些测试。在跨五大洲的一百个验证节点网络上的可以取得每秒超过一百个交易。这个比传统PoW来说是大大的提高。
水平扩展性比较好理解，就是在以太坊里面，现在你作为一个全接点，上面几百个上千的DApps你都要参与维护它们的状态。但实际上，也许你最关心的就是其中的几个应用。这种情况下以太坊会面临很大的性能瓶颈。所以它现在的改善的方式是迁网，迁到这个PoS共识算法。另外一个就是分片。在Cosmos中通过不同的分区实现分片，所谓Zone就是不同的区块链，按照不同的应用逻辑进行分片的方式。这个水平扩展的分片方式是非常自然合乎逻辑。
另外的就是自主性，自主性也比较好理解。比方说当你这个社区不能取得共识的时候，区块链治理很自然的结果就是分叉。比方说当时的以太坊分叉出来以太坊和以太坊经典。那在Cosmos架构上很自然的这两个区块链的就是两个不同的分区，这两个不同分区里面它们有自己不同的验证人节点，有不同的出块的速率。不同的性能的设置，就是这就很自然地反映了不同的区块链不同的分区反映了不同的治理特点，因此，这也很自然就是许可链或者联盟链。也可以在不失自主性的前提下和共有链交互。
自主性还有个好处体现在，当一个区块链的社区达不成共识的情况下，它不需要通过分叉，而只需要通过增加一个新的分区，在这个新的分区里把一些达不成共识的部分，相当于对于这个社区的这个区块链的治理的一些方式给设到这个新的分区里面。用户完全基于自愿的原则把自己的数字资产移到这个新的分区里面。你可以想象在Cosmos架构内完全可以跑比方说三个分区：EVM1.0、EVM2.0，还有EVM3.0，大家就各自相安无事，这体现了一个区块链的自主性。
基于Cosmos技术以及它的技术特点，我们所说的Cosmos团队所设想的一个生态系统，大概涉及到哪些使用场景呢？第一个就是我已经提到过的去中心化交易所。它是真正实现跨多种区块链交易的技术平台。比如现在Kyber和OmiseGo都决定当Cosmos Hub上线后，会接入Cosmos。这样就可以不仅仅进行ERC20代币之间的交易，也可以把一些非ERC20代币转移到交易所里进行交易。如果这个真的实现，它就是满足现阶段刚需的杀手级应用。
另外Cosmos团队认为潜在的经济模型就是：代币不一定只能用原生链。现在大家默认的一种认知就是一个区块链有一个自己的原生代币，那这个原生代币只能在这个链上使用。但实际上Cosmos认为未来世界代币和链是可以分离的。一个有价值的货币，比如数字代币比特币或者以太币，完全可以通过跨链转移，转移到一些新的或者其他链中使用。它的使用价值在全网都是一致的。比方你有一个链，是用于做分布式存储的，它可以有自己的默认的原生代币，但是也完全可以把以太币或者是比特币转过去作为有价值的一个代币在它的这个区块链应用里面加以使用。
最后一个应用就是许可链，联盟链和私有链也是可以通过Cosmos这个架构可以与其他的联盟链或者是其他公有链进行交互。而且还可以想像一下，现在各国都在推央行的数字货币。联盟链和私有链一般都没有自己的代币，但实际上它们解决了现实世界中的很多问题。智能合约在运行的过程中都跟经济、金融有关系。如果基于Cosmos这样一个架构的话，央行的数字货币完全可以通过这样一个架构把它转移到相关的联盟链里作为一个稳定货币加以使用。
最后，Cosmos只能用来做数字代币跨链吗？能不能做一些更有趣的事情呢？Cosmos团队也说了现在IBC协议的只是用来转移代币的，但是它的IBC协议的Payload里面是定义的扩展机制，理论上它是可以传输其他类型的数据结构，可以做其他的事情。现在万向的新链加速器投资的边界智能团队就在做这样的尝试。他们想通过基于Cosmos实现服务调用的跨链。
这就是他们团队做的一个IRIS项目。它可以把基于云的服务，基于传统企业系统的一些功能，还有其他公有链或者联盟链的一些功能，以服务的方式提供到Cosmos世界上，让大家可以跨链调用不同服务。