Cosmos: uma rede de livros-razão distribuídos
Introduction
Introduction
The combined success of the open-source ecosystem, decentralized yle-sharing, and public cryptocurrencies has inspired an understanding that decentralized internet protocols can be used to radically improve socio-economic infrastructure. We have seen specialized blockchain applications like Bitcoin [1] (a cryptocurrency), Zerocash [2] (a cryptocurrency for privacy), and generalized smart contract platforms such as Ethereum [3], with countless distributed applications for the Etherium Virtual Machine (EVM) such as Augur (a prediction market) and TheDAO [4] (an investment club). To date, however, these blockchains have suffered from a number of drawbacks, including their gross energy inefyciency, poor or limited performance, and immature governance mechanisms. Proposals to scale Bitcoin’s transaction throughput, such as Segregated-Witness [5] and BitcoinNG [6], are vertical scaling solutions that remain limited by the capacity of a single physical machine, in order to ensure the property of complete auditability. The Lightning Network [7] can help scale Bitcoin transaction
volume by leaving some transactions off the ledger completely, and is well suited for micropayments and privacy-preserving payment rails, but may not be suitable for more generalized scaling needs. An ideal solution is one that allows multiple parallel blockchains to interoperate while retaining their security properties. This has proven difycult, if not impossible, with proof-of-work. Merged mining, for instance, allows the work done to secure a parent chain to be reused on a child chain, but transactions must still be validated, in order, by each node, and a merge-mined blockchain is vulnerable to attack if a majority of the hashing power on the parent is not actively merge-mining the child. An academic review of alternative blockchain network architectures is provided for additional context, and we provide summaries of other proposals and their drawbacks in Related Work. Here we present Cosmos, a novel blockchain network architecture that addresses all of these problems. Cosmos is a network of many independent blockchains, called zones. The zones are powered by Tendermint Core [8], which provides a high-performance, consistent, secure PBFT-like consensus engine, where strict forkaccountability guarantees hold over the behaviour of malicious actors. Tendermint Core’s BFT consensus algorithm is well suited for scaling public proof-of-stake blockchains. The yrst zone on Cosmos is called the Cosmos Hub. The Cosmos Hub is a multi-asset proof-of-stake cryptocurrency with a simple governance mechanism which enables the network to adapt and upgrade. In addition, the Cosmos Hub can be extended by connecting other zones. The hub and zones of the Cosmos network communicate with each other via an inter-blockchain communication (IBC) protocol, a kind of virtual UDP or TCP for blockchains. Tokens can be transferred from one zone to another securely and quickly
without the need for exchange liquidity between zones. Instead, all inter-zone token transfers go through the Cosmos Hub, which keeps track of the total amount of tokens held by each zone. The hub isolates each zone from the failure of other zones. Because anyone can connect a new zone to the Cosmos Hub, zones allow for future-compatibility with new blockchain innovations. In this section we describe the Tendermint consensus protocol and the interface used to build applications with it. For more details, see the appendix. In classical Byzantine fault-tolerant (BFT) algorithms, each node has the same weight. In Tendermint, nodes have a non-negative amount of voting power, and nodes that have positive voting power are called validators. Validators participate in the consensus protocol by broadcasting cryptographic signatures, or votes, to agree upon the next block. Validators’ voting powers are determined at genesis, or are changed deterministically by the blockchain, depending on the application. For example, in a proof-of-stake application such as the Cosmos Hub, the voting power may be determined by the amount of staking tokens bonded as collateral. NOTE: Fractions like ⅔ and ⅓ refer to fractions of the total voting power, never the total number of validators, unless all the validators have equal weight. \(> 2/3\) means “more than ⅔”, \(\geq 1/3\) means “at least ⅓”. Tendermint is a partially synchronous BFT consensus protocol derived from the DLS consensus algorithm [20]. Tendermint is
notable for its simplicity, performance, and fork-accountability. The protocol requires a yxed known set of validators, where each validator is identiyed by their public key. Validators attempt to come to consensus on one block at a time, where a block is a list of transactions. Voting for consensus on a block proceeds in rounds. Each round has a round-leader, or proposer, who proposes a block. The validators then vote, in stages, on whether to accept the proposed block or move on to the next round. The proposer for a round is chosen deterministically from the ordered list of validators, in proportion to their voting power. The full details of the protocol are described here. Tendermint’s security derives from its use of optimal Byzantine fault-tolerance via super-majority (\(> 2/3\)) voting and a locking mechanism. Together, they ensure that: \(\geq 1/3\) voting power must be Byzantine to cause a violation of safety, where more than two values are committed. if any set of validators ever succeeds in violating safety, or even attempts to do so, they can be identiyed by the protocol. This includes both voting for conzicting blocks and broadcasting unjustiyed votes. Despite its strong guarantees, Tendermint provides exceptional performance. In benchmarks of 64 nodes distributed across 7 datacenters on 5 continents, on commodity cloud instances, Tendermint consensus can process thousands of transactions per second, with commit latencies on the order of one to two seconds. Notably, performance of well over a thousand transactions per second is maintained even in harsh adversarial conditions, with validators crashing or broadcasting maliciously crafted votes. See the ygure below for details.
A major beneyt of Tendermint’s consensus algorithm is simpliyed light client security, making it an ideal candidate for mobile and internet-of-things use cases. While a Bitcoin light client must sync chains of block headers and ynd the one with the most proof of work, Tendermint light clients need only to keep up with changes to the validator set, and then verify the \(> 2/3\) PreCommits in the latest block to determine the latest state. Succinct light client proofs also enable inter-blockchain communication. Tendermint has protective measures for preventing certain notable attacks, like long-range-nothing-at-stake double spends and censorship. These are discussed more fully in the appendix.
The Tendermint consensus algorithm is implemented in a program called Tendermint Core. Tendermint Core is an application-agnostic “consensus engine” that can turn any deterministic blackbox application into a distributedly replicated blockchain. Tendermint Core connects to blockchain applications via the Application Blockchain Interface (ABCI) [17]. Thus, ABCI allows for blockchain applications to be programmed in any language, not just the programming language that the consensus engine is written in. Additionally, ABCI makes it possible to easily swap out the consensus layer of any existing blockchain stack. We draw an analogy with the well-known cryptocurrency Bitcoin. Bitcoin is a cryptocurrency blockchain where each node maintains a fully audited Unspent Transaction Output (UTXO) database. If one wanted to create a Bitcoin-like system on top of ABCI, Tendermint Core would be responsible for Sharing blocks and transactions between nodes Establishing a canonical/immutable order of transactions (the blockchain) Meanwhile, the ABCI application would be responsible for Maintaining the UTXO database Validating cryptographic signatures of transactions Preventing transactions from spending non-existent funds Allowing clients to query the UTXO database Tendermint is able to decompose the blockchain design by offering a very simple API between the application process and consensus process.
Introdução
O sucesso combinado do ecossistema de código aberto, compartilhamento descentralizado de yle e criptomoedas públicas inspirou um entendimento de que protocolos descentralizados de internet pode ser usado para melhorar radicalmente a infra-estrutura socioeconómica. Vimos aplicativos blockchain especializados como Bitcoin [1] (um criptomoeda), Zerocash [2] (uma criptomoeda para privacidade) e plataformas smart contract generalizadas, como Ethereum [3], com inúmeras aplicações distribuídas para o Etherium Virtual Máquina (EVM), como Augur (um mercado de previsão) e TheDAO [4] (um clube de investimento). Até o momento, entretanto, esses blockchains sofreram com uma série de de inconvenientes, incluindo a sua grave ineficiência energética, fraca ou desempenho limitado e mecanismos de governação imaturos. Propostas para dimensionar a taxa de transferência de transações de Bitcoin, como Segregated-Witness [5] e BitcoinNG [6], são de escala vertical soluções que permanecem limitadas pela capacidade de um único máquina, a fim de garantir a propriedade de completa auditabilidade. A Lightning Network [7] pode ajudar a dimensionar a transação Bitcoin
volume deixando algumas transações completamente fora do razão, e é adequado para micropagamentos e preservação de privacidade trilhos de pagamento, mas pode não ser adequado para pagamentos mais generalizados necessidades de escala. Uma solução ideal é aquela que permite que vários blockchains paralelos sejam interoperar, mantendo suas propriedades de segurança. Isso tem comprovadamente difícil, se não impossível, com proof-of-work. Mesclado a mineração, por exemplo, permite que o trabalho realizado para proteger um pai cadeia a ser reutilizada em uma cadeia filha, mas as transações ainda devem ser validado, em ordem, por cada nó, e um blockchain extraído por mesclagem é vulnerável a ataques se a maioria do poder hashing no o pai não está minerando ativamente o filho. Uma revisão acadêmica de arquiteturas de rede alternativas blockchain são fornecidas para contexto adicional e fornecemos resumos de outras propostas e suas desvantagens em trabalhos relacionados. Aqui apresentamos Cosmos, uma nova arquitetura de rede blockchain que resolve todos esses problemas. Cosmos é uma rede de muitos blockchains independentes, chamados zonas. As zonas são alimentadas por Tendermint Core [8], que fornece um alto desempenho, mecanismo de consenso consistente e seguro do tipo PBFT, onde garantias estritas de responsabilização prevalecem sobre o comportamento de maliciosos atores. O algoritmo de consenso BFT do Tendermint Core é adequado para dimensionar proof-of-stake blockchains públicos. A primeira zona em Cosmos é chamada de Hub Cosmos. O Cosmos Hub é uma criptomoeda proof-of-stake multiativos com um simples mecanismo de governança que permite à rede se adaptar e atualizar. Além disso, o Hub Cosmos pode ser estendido por conectando outras zonas. O hub e as zonas da rede Cosmos se comunicam com entre si por meio de um protocolo de comunicação inter-blockchain (IBC), uma espécie de UDP ou TCP virtual para blockchains. Os tokens podem ser transferido de uma zona para outra com segurança e rapidezsem a necessidade de liquidez cambial entre zonas. Em vez disso, todas as transferências entre zonas token passam pelo hub Cosmos, que mantém registro da quantidade total de tokens mantidos por cada zona. O hub isola cada zona da falha de outras zonas. Porque qualquer pessoa pode conectar uma nova zona ao hub Cosmos, as zonas permitem para compatibilidade futura com novas inovações blockchain. Nesta seção descrevemos o protocolo de consenso Tendermint e a interface usada para construir aplicativos com ele. Para mais detalhes, consulte o apêndice. Nos algoritmos clássicos de tolerância a falhas bizantinas (BFT), cada nó tem o mesmo peso. No Tendermint, os nós têm um valor não negativo quantidade de poder de voto e nós que têm votação positiva potência são chamados de validators. Os validadores participam do protocolo de consenso transmitindo assinaturas criptográficas, ou votos, para chegar a acordo sobre o próximo bloco. Os poderes de voto dos validadores são determinados na génese ou são alterado deterministicamente pelo blockchain, dependendo do aplicação. Por exemplo, em um aplicativo proof-of-stake como no Hub Cosmos, o poder de voto poderá ser determinado pelo valor de staking tokens garantidos como garantia. NOTA: Frações como ⅔ e ⅓ referem-se a frações do total de votos potência, nunca o número total de validators, a menos que todos os validators têm peso igual. >⅔ significa “mais de ⅔”, ≥⅓ significa “pelo menos ⅓”. Tendermint é um protocolo de consenso BFT parcialmente síncrono derivado do algoritmo de consenso DLS [20]. Tendermint é
notável por sua simplicidade, desempenho e responsabilidade de garfo. O protocolo requer um conjunto conhecido yxed de validators, onde cada validator é identificado pela sua chave pública. Os validadores tentam chegar a um consenso sobre um bloco de cada vez, onde um bloco é uma lista de transações. A votação para o consenso sobre um bloco prossegue em rodadas. Cada rodada tem um líder, ou proponente, que propõe um bloqueio. Os validators então votam, em etapas, se aceitar o bloco proposto ou passar para a próxima rodada. O proponente para uma rodada é escolhido de forma determinística a partir do ordenado lista de validators, proporcionalmente ao seu poder de voto. Os detalhes completos do protocolo estão descritos aqui. A segurança do Tendermint deriva do uso de recursos bizantinos ideais tolerância a falhas por meio de votação por supermaioria (>⅔) e bloqueio mecanismo. Juntos, eles garantem que: ≥⅓ o poder de voto deve ser bizantino para causar uma violação do segurança, onde mais de dois valores estão comprometidos. se algum conjunto de validators conseguir violar a segurança, ou mesmo tentativas de fazê-lo, eles podem ser identificados pelo protocolo. Isto inclui votação para bloqueios de conspiração e transmissão votos injustificados. Apesar das suas fortes garantias, o Tendermint oferece resultados excepcionais desempenho. Em benchmarks de 64 nós distribuídos em 7 datacenters nos 5 continentes, em instâncias de nuvem de commodities, O consenso do Tendermint pode processar milhares de transações por segundo, com latências de commit da ordem de um a dois segundos. Notavelmente, o desempenho de bem mais de mil transações por segundo é mantido mesmo em condições adversas adversas, com validator está travando ou transmitindo votos criados com códigos maliciosos. Veja a figura abaixo para obter detalhes.
Um grande benefício do algoritmo de consenso do Tendermint é simplificado leve segurança do cliente, tornando-o um candidato ideal para dispositivos móveis e casos de uso de internet das coisas. Embora um cliente light Bitcoin deva sincronizar cadeias de cabeçalhos de bloco e encontre aquele com maior prova de trabalho, os clientes Tendermint light precisam apenas acompanhar as mudanças para o conjunto validator e, em seguida, verifique os >⅔ PreCommits no bloco mais recente para determinar o estado mais recente. Provas de cliente leves sucintas também permitem inter-blockchain comunicação. Tendermint possui medidas de proteção para prevenir certos ataques notáveis, como gastos duplos de longo alcance e nada em jogo e censura. Eles são discutidos mais detalhadamente no apêndice.O algoritmo de consenso Tendermint é implementado em um programa chamado Tendermint Core. Tendermint Core é um “mecanismo de consenso” independente de aplicação que pode transformar qualquer aplicativo blackbox determinístico em um replicado distribuídamente blockchain. Tendermint Core se conecta a aplicativos blockchain por meio da Interface Blockchain do Aplicativo (ABCI) [17]. Assim, ABCI permite que aplicações blockchain sejam programadas em qualquer linguagem, não apenas a linguagem de programação que o consenso motor está escrito. Além disso, ABCI torna possível facilmente troque a camada de consenso de qualquer pilha blockchain existente. Fazemos uma analogia com a conhecida criptomoeda Bitcoin. Bitcoin é uma criptomoeda blockchain onde cada nó mantém um banco de dados de saída de transação não gasta (UTXO) totalmente auditado. Se queria-se criar um sistema semelhante a Bitcoin em cima de ABCI, O Tendermint Core seria responsável por Compartilhando blocos e transações entre nós Estabelecer uma ordem canônica/imutável de transações (o blockchain) Enquanto isso, o aplicativo ABCI seria responsável por Mantendo o banco de dados UTXO Validando assinaturas criptográficas de transações Evitar que as transações gastem fundos inexistentes Permitindo que clientes consultem o banco de dados UTXO Tendermint é capaz de decompor o design blockchain por oferecendo uma API muito simples entre o processo de inscrição e processo de consenso.
Cosmos Architecture
Cosmos Architecture
Cosmos is a network of independent parallel blockchains that are each powered by classical BFT consensus algorithms like Tendermint 1. The yrst blockchain in this network will be the Cosmos Hub. The Cosmos Hub connects to many other blockchains (or zones) via a novel inter-blockchain communication protocol. The Cosmos Hub tracks numerous token types and keeps record of the total number of tokens in each connected zone. Tokens can be transferred from one zone to another securely and quickly without the need for a liquid exchange between zones, because all inter-zone coin transfers go through the Cosmos Hub. This architecture solves many problems that the blockchain space faces today, such as application interoperability, scalability, and seamless upgradability. For example, zones derived from Bitcoind, Go-Ethereum, CryptoNote, ZCash, or any blockchain system can be plugged into the Cosmos Hub. These zones allow Cosmos to scale inynitely to meet global transaction demand. Zones are also a great yt for a distributed exchange, which will be supported as well. Cosmos is not just a single distributed ledger, and the Cosmos Hub isn’t a walled garden or the center of its universe. We are designing a protocol for an open network of distributed ledgers that can serve as a new foundation for future ynancial systems, based on principles of cryptography, sound economics, consensus theory, transparency, and accountability. The Cosmos Hub is the yrst public blockchain in the Cosmos Network, powered by Tendermint’s BFT consensus algorithm. The Tendermint open-source project was born in 2014 to address the speed, scalability, and environmental issues of Bitcoin’s proof-ofwork consensus algorithm. By using and improving upon proven
BFT algorithms developed at MIT in 1988 [20], the Tendermint team was the yrst to conceptually demonstrate a proof-of-stake cryptocurrency that addresses the nothing-at-stake problem suffered by yrst-generation proof-of-stake cryptocurrencies such as NXT and BitShares1.0. Today, practically all Bitcoin mobile wallets use trusted servers to provide them with transaction veriycation. This is because proofof-work requires waiting for many conyrmations before a transaction can be considered irreversibly committed. Doublespend attacks have already been demonstrated on services like CoinBase. Unlike other blockchain consensus systems, Tendermint offers instant and provably secure mobile-client payment veriycation. Since the Tendermint is designed to never fork at all, mobile wallets can receive instant transaction conyrmation, which makes trustless and practical payments a reality on smartphones. This has signiycant ramiycations for Internet of Things applications as well. Validators in Cosmos have a similar role to Bitcoin miners, but instead use cryptographic signatures to vote. Validators are secure, dedicated machines that are responsible for committing blocks. Non-validators can delegate their staking tokens (called “atoms”) to any validator to earn a portion of block fees and atom rewards, but they incur the risk of getting punished (slashed) if the delegate validator gets hacked or violates the protocol. The proven safety guarantees of Tendermint BFT consensus, and the collateral deposit of stakeholders–validators and delegators–provide provable, quantiyable security for nodes and light clients. Distributed public ledgers should have a constitution and a governance system. Bitcoin relies on the Bitcoin Foundation and
mining to coordinate upgrades, but this is a slow process. Ethereum split into ETH and ETC after hard-forking to address TheDAO hack, largely because there was no prior social contract nor mechanism for making such decisions. Validators and delegators on the Cosmos Hub can vote on proposals that can change preset parameters of the system automatically (such as the block gas limit), coordinate upgrades, as well as vote on amendments to the human-readable constitution that govern the policies of the Cosmos Hub. The constitution allows for cohesion among the stakeholders on issues such as theft and bugs (such as TheDAO incident), allowing for quicker and cleaner resolution. Each zone can also have their own constitution and governance mechanism as well. For example, the Cosmos Hub could have a constitution that enforces immutability at the Hub (no roll-backs, save for bugs of the Cosmos Hub node implementation), while each zone can set their own policies regarding roll-backs. By enabling interoperability among differing policy zones, the Cosmos network gives its users ultimate freedom and potential for permissionless experimentation. Here we describe a novel model of decentralization and scalability. Cosmos is a network of many blockchains powered by Tendermint. While existing proposals aim to create a “single blockchain” with total global transaction ordering, Cosmos permits many blockchains to run concurrently with one another while retaining interoperability. At the basis, the Cosmos Hub manages many independent blockchains called “zones” (sometimes referred to as “shards”, in reference to the database scaling technique known as “sharding”).
A constant stream of recent block commits from zones posted on the Hub allows the Hub to keep up with the state of each zone. Likewise, each zone keeps up with the state of the Hub (but zones do not keep up with each other except indirectly through the Hub). Packets of information are then communicated from one zone to another by posting Merkle-proofs as evidence that the information was sent and received. This mechanism is called inter-blockchain communication, or IBC for short. Any of the zones can themselves be hubs to form an acyclic graph, but for the sake of clarity we will only describe the simple conyguration where there is only one hub, and many non-hub zones. The Cosmos Hub is a blockchain that hosts a multi-asset distributed ledger, where tokens can be held by individual users or by zones themselves. These tokens can be moved from one zone to another in a special IBC packet called a "coin packet". The hub is responsible for preserving the global invariance of the total amount of each token across the zones. IBC coin packet transactions must be committed by the sender, hub, and receiver blockchains.
Since the Cosmos Hub acts as the central ledger for the whole system, the security of the Hub is of paramount importance. While each zone may be a Tendermint blockchain that is secured by as few as 4 (or even less if BFT consensus is not needed), the Hub must be secured by a globally decentralized set of validators that can withstand the most severe attack scenarios, such as a continental network partition or a nation-state sponsored attack. A Cosmos zone is an independent blockchain that exchanges IBC messages with the Hub. From the Hub’s perspective, a zone is a multi-asset dynamic-membership multi-signature account that can send and receive tokens using IBC packets. Like a cryptocurrency account, a zone cannot transfer more tokens than it has, but can receive tokens from others who have them. A zone may be designated as an "source" of one or more token types, granting it the power to inzate that token supply. Atoms of the Cosmos Hub may be staked by validators of a zone connected to the Hub. While double-spend attacks on these zones would result in the slashing of atoms with Tendermint’s forkaccountability, a zone where \(> 2/3\) of the voting power are Byzantine can commit invalid state. The Cosmos Hub does not verify or execute transactions committed on other zones, so it is the responsibility of users to send tokens to zones that they trust. In the future, the Cosmos Hub’s governance system may pass Hub improvement proposals that account for zone failures. For example, outbound token transfers from some (or all) zones may be throttled to allow for the emergency circuit-breaking of zones (a temporary halt of token transfers) when an attack is detected. Now we look at how the Hub and zones communicate with each other. For example, if there are three blockchains, “Zone1”, “Zone2”,
and “Hub”, and we wish for "Zone1" to produce a packet destined for “Zone2” going through “Hub”. To move a packet from one blockchain to another, a proof is posted on the receiving chain. The proof states that the sending chain published a packet for the alleged destination. For the receiving chain to check this proof, it must be able keep up with the sender’s block headers. This mechanism is similar to that used by sidechains, which requires two interacting chains to be aware of one another via a bidirectional stream of proof-of-existence datagrams (transactions). The IBC protocol can naturally be deyned using two types of transactions: an IBCBlockCommitTx transaction, which allows a blockchain to prove to any observer of its most recent block-hash, and an IBCPacketTx transaction, which allows a blockchain to prove to any observer that the given packet was indeed published by the sender’s application, via a Merkle-proof to the recent block-hash. By splitting the IBC mechanics into two separate transactions, we allow the native fee market-mechanism of the receiving chain to determine which packets get committed (i.e. acknowledged), while allowing for complete freedom on the sending chain as to how many outbound packets are allowed. In the example above, in order to update the block-hash of "Zone1" on “Hub” (or of “Hub” on “Zone2”), an IBCBlockCommitTx
transaction must be posted on “Hub” with the block-hash of “Zone1” (or on "Zone2" with the block-hash of “Hub”). See IBCBlockCommitTx and IBCPacketTx for for more information on the two IBC transaction types. In the same way that Bitcoin is more secure by being a distributed, mass-replicated ledger, we can make exchanges less vulnerable to external and internal hacks by running it on the blockchain. We call this a distributed exchange. What the cryptocurrency community calls a decentralized exchange today are based on something called “atomic crosschain” (AXC) transactions. With an AXC transaction, two users on two different chains can make two transfer transactions that are committed together on both ledgers, or none at all (i.e. atomically). For example, two users can trade bitcoins for ether (or any two tokens on two different ledgers) using AXC transactions, even though Bitcoin and Ethereum are not connected to each other. The beneyt of running an exchange on AXC transactions is that neither users need to trust each other or the trade-matching service. The downside is that both parties need to be online for the trade to occur. Another type of decentralized exchange is a mass-replicated distributed exchange that runs on its own blockchain. Users on this kind of exchange can submit a limit order and turn their computer off, and the trade can execute without the user being online. The blockchain matches and completes the trade on behalf of the trader.
Cosmos Arquitetura
Cosmos é uma rede de blockchains paralelos independentes que são cada um alimentado por algoritmos de consenso clássicos BFT como Menta 1. O primeiro blockchain nesta rede será o Hub Cosmos. O Cosmos O hub se conecta a muitos outros blockchains (ou zonas) por meio de um novo protocolo de comunicação inter-blockchain. O Centro Cosmos rastreia vários tipos token e mantém registro do total número de tokens em cada zona conectada. Os tokens podem ser transferido de uma zona para outra com segurança e rapidez sem a necessidade de troca de líquidos entre zonas, porque todos as transferências de moedas entre zonas passam pelo Hub Cosmos. Esta arquitetura resolve muitos problemas que o espaço blockchain enfrenta hoje, como interoperabilidade de aplicativos, escalabilidade e capacidade de atualização perfeita. Por exemplo, zonas derivadas de Bitcoind, Go-Ethereum, CryptoNote, ZCash ou qualquer sistema blockchain pode ser conectado ao hub Cosmos. Essas zonas permitem que Cosmos escalar indefinidamente para atender à demanda global de transações. As zonas também são um ótimo ano para uma troca distribuída, que será suportada como bem. Cosmos não é apenas um único razão distribuído, e o Cosmos Hub não é um jardim murado ou o centro do seu universo. Nós somos projetando um protocolo para uma rede aberta de livros distribuídos que pode servir como uma nova base para futuros sistemas financeiros, baseado em princípios de criptografia, economia sólida, consenso teoria, transparência e responsabilidade. O Cosmos Hub é o primeiro blockchain público no Cosmos Rede, alimentada pelo algoritmo de consenso BFT do Tendermint. O O projeto de código aberto Tendermint nasceu em 2014 para abordar o velocidade, escalabilidade e questões ambientais do algoritmo de consenso de prova de trabalho de Bitcoin. Usando e melhorando os comprovados
BFT algoritmos desenvolvidos no MIT em 1988 [20], o Tendermint a equipe foi a primeira a demonstrar conceitualmente um proof-of-stake criptomoeda que resolve o problema do nada em jogo sofrido pelas criptomoedas proof-of-stake de primeira geração, como como NXT e BitShares1.0. Hoje, praticamente todas as carteiras móveis Bitcoin usam servidores confiáveis para fornecer-lhes a verificação da transação. Isso ocorre porque a prova de trabalho exige a espera de muitas confirmações antes de um transação pode ser considerada irreversivelmente comprometida. Ataques de gasto duplo já foram demonstrados em serviços como CoinBase. Ao contrário de outros sistemas de consenso blockchain, o Tendermint oferece verificação de pagamento de cliente móvel instantânea e comprovadamente segura. Como o Tendermint foi projetado para nunca bifurcar, dispositivos móveis carteiras podem receber confirmação instantânea da transação, o que torna pagamentos práticos e confiáveis são uma realidade em smartphones. Isto tem ramificações significativas para aplicações da Internet das Coisas, como bem. Os validadores em Cosmos têm uma função semelhante aos mineradores de Bitcoin, mas em vez disso, use assinaturas criptográficas para votar. Validadores são máquinas seguras e dedicadas que são responsáveis por cometer blocos. Não-validators podem delegar seus staking tokens (chamados “átomos”) para qualquer validator para ganhar uma parte das taxas de bloco e átomo recompensas, mas correm o risco de serem punidos (cortados) se o o delegado validator é hackeado ou viola o protocolo. O comprovado garantias de segurança do consenso Tendermint BFT, e a garantia depósito das partes interessadas –validators e delegantes – fornecer segurança comprovável e quantificável para nós e clientes leves. Os livros-razão públicos distribuídos devem ter uma constituição e um sistema de governança. Bitcoin depende da Fundação Bitcoin emineração para coordenar atualizações, mas este é um processo lento. Ethereum dividido em ETH e ETC após hard fork para endereçar O hackDAO, em grande parte porque não havia contrato social anterior nem mecanismo para tomar tais decisões. Validadores e delegadores no Hub Cosmos podem votar propostas que podem alterar parâmetros predefinidos do sistema automaticamente (como o limite de gás do bloco), coordenar atualizações, como bem como votar em emendas à constituição legível por humanos que regem as políticas do Hub Cosmos. A constituição permite a coesão entre as partes interessadas em questões como roubo e bugs (como o incidente TheDAO), permitindo uma abordagem mais rápida e resolução mais limpa. Cada zona também pode ter sua própria constituição e governança mecanismo também. Por exemplo, o Hub Cosmos poderia ter um constituição que impõe a imutabilidade no Centro (sem retrocessos, exceto para bugs da implementação do nó Hub Cosmos), enquanto cada zona pode definir suas próprias políticas em relação a reversões. Ao permitir a interoperabilidade entre diferentes zonas políticas, o A rede Cosmos oferece aos seus usuários total liberdade e potencial para experimentação sem permissão. Aqui descrevemos um novo modelo de descentralização e escalabilidade. Cosmos é uma rede de muitos blockchains alimentada por Menta macia. Embora as propostas existentes visem criar um “único blockchain” com ordem de transação global total, Cosmos permite que muitos blockchains sejam executados simultaneamente entre si mantendo a interoperabilidade. Basicamente, o Hub Cosmos gerencia muitos blockchains chamadas “zonas” (às vezes chamadas de “fragmentos”, em referência à técnica de escalonamento de banco de dados conhecida como “sharding”).
Um fluxo constante de commits recentes de blocos de zonas postadas em o Hub permite que o Hub acompanhe o estado de cada zona. Da mesma forma, cada zona acompanha o estado do Hub (mas as zonas não se acompanham, exceto indiretamente através do Central). Pacotes de informações são então comunicados de um zona para outra, afixando provas Merkle como evidência de que o informações foram enviadas e recebidas. Este mecanismo é denominado comunicação inter-blockchain ou IBC para abreviar. Qualquer uma das zonas pode ser hubs para formar um gráfico acíclico, mas por uma questão de clareza, descreveremos apenas o simples configuração onde há apenas um hub e muitos não-hub zonas. O Cosmos Hub é um blockchain que hospeda um multiativo razão distribuída, onde tokens podem ser mantidos por usuários individuais ou pelas próprias zonas. Esses tokens podem ser movidos de uma zona para outro em um pacote IBC especial chamado "pacote de moedas". O centro é responsável por preservar a invariância global do total quantidade de cada token nas zonas. IBC pacote de moedas as transações devem ser confirmadas pelo remetente, hub e destinatário blockchains.Como o Hub Cosmos atua como o razão central para todo o sistema, a segurança do Hub é de suma importância. Enquanto cada zona pode ser um Tendermint blockchain que é protegido por como poucos como 4 (ou até menos se o consenso BFT não for necessário), o Hub deve ser protegido por um conjunto globalmente descentralizado de validators que pode suportar os cenários de ataque mais severos, como um partição de rede continental ou um ataque patrocinado por um estado-nação. Uma zona Cosmos é uma blockchain independente que troca IBC mensagens com o Hub. Da perspectiva do Hub, uma zona é um conta com múltiplas assinaturas e associação dinâmica de múltiplos ativos que pode enviar e receber tokens usando pacotes IBC. Como um conta de criptomoeda, uma zona não pode transferir mais tokens do que tem, mas pode receber tokens de outras pessoas que os possuem. Uma zona pode ser designado como uma "fonte" de um ou mais tipos token, concedendo-lhe o poder de injetar aquele suprimento token. Átomos do Hub Cosmos podem ser piquetados por validators de uma zona conectado ao Hub. Embora os ataques de gasto duplo nessas zonas resultaria no corte de átomos com a responsabilidade do Tendermint, uma zona onde> ⅔ do poder de voto são Byzantine pode cometer estado inválido. O hub Cosmos não verificar ou executar transações comprometidas em outras zonas, por isso é é responsabilidade dos usuários enviar tokens para zonas em que confiam. No futuro, o sistema de governança do Hub Cosmos poderá passar pelo Hub propostas de melhoria que levam em conta as falhas da zona. Para por exemplo, transferências de saída token de algumas (ou todas) zonas podem ser estrangulado para permitir a interrupção de emergência das zonas (uma interrupção temporária das transferências token) quando um ataque é detectado. Agora veremos como o Hub e as zonas se comunicam entre si outro. Por exemplo, se houver três blockchains, “Zona1”, “Zona2”,
e “Hub”, e desejamos que “Zone1” produza um pacote destinado para “Zona2” passando por “Hub”. Para mover um pacote de um blockchain para outro, uma prova é postada na cadeia de recebimento. A prova afirma que a cadeia emissora publicou um pacote para o suposto destino. Para que a cadeia receptora verifique esta prova, é deve ser capaz de acompanhar os cabeçalhos de bloco do remetente. Isto O mecanismo é semelhante ao usado pelas cadeias laterais, o que requer duas cadeias interagindo para estarem cientes uma da outra através de um fluxo bidirecional de datagramas de prova de existência (transações). O protocolo IBC pode naturalmente ser definido usando dois tipos de transações: uma transação IBCBlockCommitTx , que permite um blockchain para provar a qualquer observador seu bloco mais recente - hash, e uma transação IBCPacketTx , que permite que um blockchain provar a qualquer observador que o pacote fornecido foi de fato publicado pela aplicação do remetente, através de uma prova de Merkle para o recente bloco-hash. Ao dividir a mecânica IBC em duas transações separadas, permitir que o mecanismo de mercado de taxas nativo da cadeia de recebimento determinar quais pacotes serão confirmados (ou seja, reconhecidos), enquanto permitindo total liberdade na cadeia de envio sobre como muitos pacotes de saída são permitidos. No exemplo acima, para atualizar o bloco-hash da "Zona1" no “Hub” (ou de “Hub” na “Zona2”), um IBCBlockCommitTxa transação deve ser postada no “Hub” com o bloco-hash de “Zona1” (ou em “Zona2” com o bloco-hash de “Hub”). Consulte IBCBlockCommitTx e IBCPacketTx para obter mais informações nos dois tipos de transação IBC. Da mesma forma que Bitcoin é mais seguro por ser distribuído, livro razão replicado em massa, podemos tornar as exchanges menos vulneráveis a hacks externos e internos executando-o em blockchain. Nós chame isso de troca distribuída. O que a comunidade de criptomoedas chama de descentralizada exchange hoje são baseadas em algo chamado de transações “atomic crosschain” (AXC). Com uma transação AXC, dois usuários em duas cadeias diferentes podem fazer duas transações de transferência que são comprometidos juntos em ambos os livros, ou nenhum (ou seja, atomicamente). Por exemplo, dois usuários podem trocar bitcoins por ether (ou quaisquer dois tokens em dois livros razão diferentes) usando transações AXC, mesmo que Bitcoin e Ethereum não estejam conectados um ao outro outro. O benefício de executar uma exchange em transações AXC é que nem os usuários precisam confiar uns nos outros ou na correspondência comercial serviço. A desvantagem é que ambas as partes precisam estar online para que o comércio ocorra. Outro tipo de exchange descentralizada é a replicada em massa troca distribuída que funciona por conta própria blockchain. Usuários ativados esse tipo de exchange pode enviar um pedido com limite e transformar seu computador desligado e a negociação pode ser executada sem que o usuário seja on-line. O blockchain corresponde e conclui a negociação em nome do comerciante.
Applications
Applications
A centralized exchange can create a deep orderbook of limit orders and thereby attract more traders. Liquidity begets more liquidity in the exchange world, and so there is a strong network effect (or at least a winner-take-most effect) in the exchange business. The current leader for cryptocurrency exchanges today is Poloniex with a 24-hour volume of $20M, and in second place is Bitynex with a 24-hour volume of $5M. Given such strong network effects, it is unlikely for AXC-based decentralized exchanges to win volume over the centralized exchanges. For a decentralized exchange to compete with a centralized exchange, it would need to support deep orderbooks with limit orders. Only a distributed exchange on a blockchain can provide that. Tendermint provides additional beneyts of faster transaction commits. By prioritizing fast ynality without sacriycing consistency, zones in Cosmos can ynalize transactions fast – for both exchange order transactions as well as IBC token transfers to and from other zones. Given the state of cryptocurrency exchanges today, a great application for Cosmos is the distributed exchange (aka the Cosmos DEX). The transaction throughput capacity as well as commit latency can be comparable to those of centralized exchanges. Traders can submit limit orders that can be executed without both parties having to be online. And with Tendermint, the Cosmos hub, and IBC, traders can move funds in and out of the exchange to and from other zones with speed. A privileged zone can act as the source of a bridged token of another cryptocurrency. A bridge is similar to the relationship between a Cosmos hub and zone; both must keep up with the latest blocks of the other in order to verify proofs that tokens have moved from one to the other. A "bridge-zone" on the Cosmos network keeps up with the Hub as well as the other
cryptocurrency. The indirection through the bridge-zone allows the logic of the Hub to remain simple and agnostic to other blockchain consensus strategies such as Bitcoin’s proof-of-work mining. Each bridge-zone validator would run a Tendermint-powered blockchain with a special ABCI bridge-app, but also a full-node of the “origin” blockchain. When new blocks are mined on the origin, the bridge-zone validators will come to agreement on committed blocks by signing and sharing their respective local view of the origin’s blockchain tip. When a bridge-zone receives payment on the origin (and sufycient conyrmations were agreed to have been seen in the case of a PoW chain such as Ethereum or Bitcoin), a corresponding account is created on the bridge-zone with that balance. In the case of Ethereum, the bridge-zone can share the same validator-set as the Cosmos Hub. On the Ethereum side (the origin), a bridge-contract would allow ether holders to send ether to the bridge-zone by sending it to the bridge-contract on Ethereum. Once ether is received by the bridge-contract, the ether cannot be withdrawn unless an appropriate IBC packet is received by the bridge-contract from the bridge-zone. The bridge-contract tracks the validator-set of the bridge-zone, which may be identical to the Cosmos Hub’s validator-set. In the case of Bitcoin, the concept is similar except that instead of a single bridge-contract, each UTXO would be controlled by a threshold multisignature P2SH pubscript. Due to the limitations of the P2SH system, the signers cannot be identical to the Cosmos Hub validator-set.
Ether on the bridge-zone (“bridged-ether”) can be transferred to and from the Hub, and later be destroyed with a transaction that sends it to a particular withdrawal address on Ethereum. An IBC packet proving that the transaction occurred on the bridge-zone can be posted to the Ethereum bridge-contract to allow the ether to be withdrawn. In the case of Bitcoin, the restricted scripting system makes it difycult to mirror the IBC coin-transfer mechanism. Each UTXO has its own independent pubscript, so every UTXO must be migrated to a new UTXO when there is a change in the set of Bitcoin escrow signers. One solution is to compress and decompress the UTXO-set as necessary to keep the total number of UTXOs down. The risk of such a bridgeging contract is a rogue validator set. \(\geq 1/3\) Byzantine voting power could cause a fork, withdrawing ether from the bridge-contract on Ethereum while keeping the bridgedether on the bridge-zone. Worse, \(> 2/3\) Byzantine voting power can steal ether outright from those who sent it to the bridge-contract by deviating from the original bridgeging logic of the bridge-zone. It is possible to address these issues by designing the bridge to be totally accountable. For example, all IBC packets, from the hub and the origin, might require acknowledgement by the bridge-zone in such a way that all state transitions of the bridge-zone can be efyciently challenged and veriyed by either the hub or the origin’s bridge-contract. The Hub and the origin should allow the bridgezone validators to post collateral, and token transfers out of the bridge-contract should be delayed (and collateral unbonding period sufyciently long) to allow for any challenges to be made by independent auditors. We leave the design of the speciycation and implementation of this system open as a future Cosmos
improvement proposal, to be passed by the Cosmos Hub’s governance system. Solving the scaling problem is an open issue for Ethereum. Currently, Ethereum nodes process every single transaction and also store all the states. link. Since Tendermint can commit blocks much faster than Ethereum’s proof-of-work, EVM zones powered by Tendermint consensus and operating on bridged-ether can provide higher performance to Ethereum blockchains. Additionally, though the Cosmos Hub and IBC packet mechanics does not allow for arbitrary contract logic execution per se, it can be used to coordinate token movements between Ethereum contracts running on different zones, providing a foundation for token-centric Ethereum scaling via sharding. Cosmos zones run arbitrary application logic, which is deyned at the beginning of the zone’s life and can potentially be updated over time by governance. Such zexibility allows Cosmos zones to act as bridges to other cryptocurrencies such as Ethereum or Bitcoin, and it also permits derivatives of those blockchains, utilizing the same codebase but with a different validator set and initial distribution. This allows many existing cryptocurrency frameworks, such as those of Ethereum, Zerocash, Bitcoin, CryptoNote and so on, to be used with Tendermint Core, which is a higher performance consensus engine, on a common network, opening tremendous opportunity for interoperability across platforms. Furthermore, as a multi-asset blockchain, a single transaction may contain multiple inputs and outputs, where each input can be any token type, enabling Cosmos to serve directly as a platform for decentralized exchange, though orders are assumed
to be matched via other platforms. Alternatively, a zone can serve as a distributed fault-tolerant exchange (with orderbooks), which can be a strict improvement over existing centralized cryptocurrency exchanges which tend to get hacked over time. Zones can also serve as blockchain-backed versions of enterprise and government systems, where pieces of a particular service that are traditionally run by an organization or group of organizations are instead run as a ABCI application on a certain zone, which allows it to inherit the security and interoperability of the public Cosmos network without sacriycing control over the underlying service. Thus, Cosmos may offer the best of both worlds for organizations looking to utilize blockchain technology but who are wary of relinquishing control completely to a distributed third party. Some claim that a major problem with consistency-favouring consensus algorithms like Tendermint is that any network partition which causes there to be no single partition with \(> 2/3\) voting power (e.g. \(\geq 1/3\) going ofzine) will halt consensus altogether. The Cosmos architecture can help mitigate this problem by using a global hub with regional autonomous zones, where voting power for each zone are distributed based on a common geographic region. For instance, a common paradigm may be for individual cities, or regions, to operate their own zones while sharing a common hub (e.g. the Cosmos Hub), enabling municipal activity to persist in the event that the hub halts due to a temporary network partition. Note that this allows real geological, political, and network-topological features to be considered in designing robust federated fault-tolerant systems.
NameCoin was one of the yrst blockchains to attempt to solve the name-resolution problem by adapting the Bitcoin blockchain. Unfortunately there have been several issues with this approach. With Namecoin, we can verify that, for example, @satoshi was registered with a particular public key at some point in the past, but we wouldn’t know whether the public key had since been updated recently unless we download all the blocks since the last update of that name. This is due to the limitation of Bitcoin’s UTXO transaction Merkle-ization model, where only the transactions (but not mutable application state) are Merkle-ized into the block-hash. This lets us prove existence, but not the nonexistence of later updates to a name. Thus, we can’t know for certain the most recent value of a name without trusting a full node, or incurring signiycant costs in bandwidth by downloading the whole blockchain. Even if a Merkle-ized search tree were implemented in NameCoin, its dependency on proof-of-work makes light client veriycation problematic. Light clients must download a complete copy of the headers for all blocks in the entire blockchain (or at least all the headers since the last update to a name). This means that the bandwidth requirements scale linearly with the amount of time [21]. In addition, name-changes on a proof-of-work blockchain requires waiting for additional proof-of-work conyrmation blocks, which can take up to an hour on Bitcoin. With Tendermint, all we need is the most recent block-hash signed by a quorum of validators (by voting power), and a Merkle proof to the current value associated with the name. This makes it possible to have a succinct, quick, and secure light-client veriycation of name values. In Cosmos, we can take this concept and extend it further. Each name-registration zone in Cosmos can have an associated toplevel-domain (TLD) name such as “.com” or “.org”, and each name-
registration zone can have its own governance and registration rules.
Aplicativos
Uma exchange centralizada pode criar uma carteira de pedidos profunda e limitada ordens e, assim, atrair mais comerciantes. Liquidez gera mais liquidez no mundo cambial e, portanto, existe uma rede forte efeito (ou pelo menos um efeito do tipo "o vencedor leva mais") na troca negócio. O atual líder em trocas de criptomoedas hoje está a Poloniex com um volume de US$ 20 milhões em 24 horas, e em segundo lugar está Bitynex com um volume de 24 horas de US$ 5 milhões. Dada uma rede tão forte efeitos, é improvável que as exchanges descentralizadas baseadas em AXC ganhar volume sobre as exchanges centralizadas. Para uma descentralização exchange para competir com uma exchange centralizada, seria necessário para oferecer suporte a carteiras de pedidos profundas com pedidos limitados. Apenas um distribuído exchange em blockchain pode fornecer isso. Tendermint oferece benefícios adicionais de transações mais rápidas compromete. Priorizando a sinalidade rápida sem sacrificar consistência, as zonas em Cosmos podem ynalizar transações rapidamente – por tanto as transações de ordens de câmbio quanto as transferências de IBC token para e de outras zonas. Dado o estado atual das trocas de criptomoedas, um grande aplicação para Cosmos é a troca distribuída (também conhecida como CosmosDEX). A capacidade de transferência de transações, bem como a latência de commit pode ser comparável àquelas de centralizado trocas. Os traders podem enviar ordens limitadas que podem ser executadas sem que ambas as partes tenham que estar online. E com Tendermint, o hub Cosmos e IBC, os traders podem movimentar fundos para dentro e para fora a troca de e para outras zonas com rapidez. Uma zona privilegiada pode atuar como fonte de uma ponte token de outra criptomoeda. Uma ponte é semelhante ao relacionamento entre um hub e uma zona Cosmos; ambos devem acompanhar o últimos blocos do outro para verificar provas de que tokens possuem passou de um para outro. Uma "zona de ponte" no Cosmos A rede acompanha o Hub, bem como os outros
criptomoeda. A indireção através da zona-ponte permite a lógica do Hub permanecer simples e agnóstica em relação a outros blockchain estratégias de consenso, como proof-of-work de Bitcoin mineração. Cada zona de ponte validator executaria um sistema alimentado por Tendermint blockchain com um aplicativo de ponte ABCI especial, mas também um nó completo de a “origem” blockchain. Quando novos blocos são minerados na origem, a zona-ponte validators chegarão a um acordo sobre os blocos comprometidos assinando e compartilhando sua respectiva visão local do blockchain da origem dica. Quando uma zona-ponte recebe pagamento na origem (e concordaram que confirmações suficientes foram vistas no caso de uma cadeia PoW como Ethereum ou Bitcoin), um correspondente conta é criada na zona de ponte com esse saldo. No caso de Ethereum, a zona de ponte pode compartilhar o mesmo validator-definido como o hub Cosmos. No lado Ethereum (o origem), um contrato-ponte permitiria que os detentores de Ether enviassem Ether para a zona de ponte, enviando-o para o contrato de ponte em Ethereum. Uma vez que o Ether é recebido pelo contrato-ponte, o ether não pode ser retirado a menos que um pacote IBC apropriado seja recebido pelo contrato-ponte da zona-ponte. O bridge-contract rastreia o conjunto validator da zona de ponte, que pode ser idêntico ao conjunto validator do Hub Cosmos. No caso de Bitcoin, o conceito é semelhante, exceto que em vez de um único contrato-ponte, cada UTXO seria controlado por um limite de multiassinatura P2SH pubscript. Devido às limitações de no sistema P2SH, os signatários não podem ser idênticos ao Cosmos Conjunto de hub validator.O éter na zona de ponte (“éter em ponte”) pode ser transferido para e do Hub, e posteriormente destruído com uma transação que envia para um endereço de retirada específico em Ethereum. Um IBC pacote provando que a transação ocorreu na zona de ponte pode ser postado no contrato de ponte Ethereum para permitir o ether para ser retirado. No caso de Bitcoin, o sistema de script restrito torna difícil espelhar o mecanismo de transferência de moedas IBC. Cada UTXO tem seu próprio pubscript independente, então cada UTXO deve ser migrado para um novo UTXO quando há alteração no conjunto de Bitcoin signatários de garantia. Uma solução é comprimir e descompacte o conjunto UTXO conforme necessário para manter o número total de UTXOs inativos. O risco de tal contrato de transição é um conjunto desonesto validator. ≥⅓ O poder de voto bizantino pode causar uma bifurcação, retirando o éter do contrato de ponte em Ethereum enquanto mantém o bridgedether na zona de ponte. Pior ainda, >⅔ o poder de voto bizantino pode roubar éter imediatamente daqueles que o enviaram para o contrato de ponte desviando-se da lógica de ponte original da zona de ponte. É possível resolver estas questões projetando a ponte para ser totalmente responsável. Por exemplo, todos os pacotes IBC, do hub e a origem, pode exigir reconhecimento pela zona de ponte em de tal forma que todas as transições de estado da zona de ponte possam ser eficientemente desafiado e verificado pelo centro ou pela origem contrato-ponte. O Centro e a origem devem permitir que os validators da zona-ponte depositem garantias e que token transfiram para fora do o contrato-ponte deve ser adiado (e a dissolução da garantia período suficientemente longo) para permitir quaisquer desafios a serem feitos por auditores independentes. Deixamos o desenho da especificação e implementação deste sistema aberta como um futuro Cosmos
proposta de melhoria, a ser aprovada pelo Hub Cosmos sistema de governança. Resolver o problema de dimensionamento é um problema em aberto para Ethereum. Atualmente, os nós Ethereum processam cada transação e também armazene todos os estados. link. Como o Tendermint pode confirmar blocos muito mais rápido que o de Ethereum Zonas proof-of-work, EVM alimentadas por consenso Tendermint e operar em éter em ponte pode fornecer maior desempenho para Ethereum blockchains. Além disso, embora o Hub Cosmos e IBC a mecânica de pacotes não permite lógica de contrato arbitrária execução por si só, pode ser usado para coordenar movimentos token entre Ethereum contratos executados em zonas diferentes, fornecendo uma base para o escalonamento token centrado em Ethereum por meio de fragmentação. Cosmos zonas executam lógica de aplicativo arbitrária, que é definida em o início da vida da zona e pode potencialmente ser atualizada ao longo do tempo pela governação. Essa zexibilidade permite que zonas Cosmos atuam como pontes para outras criptomoedas, como Ethereum ou Bitcoin, e também permite derivados desses blockchains, utilizando a mesma base de código, mas com um conjunto validator diferente e distribuição inicial. Isso permite que muitas criptomoedas existentes estruturas, como as de Ethereum, Zerocash, Bitcoin, CryptoNote e assim por diante, para ser usado com Tendermint Core, que é um mecanismo de consenso de maior desempenho, em uma rede comum, abrindo uma tremenda oportunidade para a interoperabilidade entre plataformas. Além disso, como um multiativo blockchain, um único transação pode conter múltiplas entradas e saídas, onde cada a entrada pode ser de qualquer tipo token, permitindo que Cosmos sirva diretamente como uma plataforma para troca descentralizada, embora as ordens sejam assumidaspara ser correspondido através de outras plataformas. Alternativamente, uma zona pode servir como uma troca distribuída tolerante a falhas (com carteiras de pedidos), que pode ser uma melhoria estrita em relação à centralização existente trocas de criptomoedas que tendem a ser hackeadas com o tempo. As zonas também podem servir como versões corporativas apoiadas por blockchain e sistemas governamentais, onde partes de um determinado serviço que são tradicionalmente administrados por uma organização ou grupo de organizações em vez disso, são executados como um aplicativo ABCI em uma determinada zona, que permite-lhe herdar a segurança e a interoperabilidade do público Cosmos rede sem sacrificar o controle sobre o subjacente serviço. Assim, Cosmos pode oferecer o melhor dos dois mundos para organizações que desejam utilizar a tecnologia blockchain, mas que estão cauteloso em ceder completamente o controle a um terceiro distribuído festa. Alguns afirmam que um grande problema com o favorecimento da consistência algoritmos de consenso como o Tendermint é que qualquer rede partição que faz com que não haja uma partição única com >⅔ o poder de voto (por exemplo, ≥⅓ sair do zine) interromperá completamente o consenso. A arquitetura Cosmos pode ajudar a mitigar esse problema usando um centro global com zonas autónomas regionais, onde o poder de voto para cada zona são distribuídos com base em uma área geográfica comum região. Por exemplo, um paradigma comum pode ser para indivíduos cidades, ou regiões, para operar suas próprias zonas enquanto compartilham um centro comum (por exemplo, o Centro Cosmos), permitindo que a atividade municipal persistir no caso de o hub parar devido a uma rede temporária partição. Observe que isso permite que dados geológicos, políticos e recursos topológicos de rede a serem considerados no projeto robusto sistemas federados tolerantes a falhas.
NameCoin foi um dos primeiros blockchains a tentar resolver o problema de resolução de nomes adaptando o Bitcoin blockchain. Infelizmente, houve vários problemas com essa abordagem. Com Namecoin podemos verificar que, por exemplo, @satoshi foi registrado com uma chave pública específica em algum momento no passado, mas não saberíamos se a chave pública já havia sido atualizado recentemente, a menos que baixemos todos os blocos desde o último atualização desse nome. Isso se deve à limitação de Bitcoin’s UTXO modelo de merkle-ização de transação, onde apenas o transações (mas não o estado mutável do aplicativo) são Merkle-izadas no bloco-hash. Isso nos permite provar a existência, mas não a inexistência de atualizações posteriores de um nome. Assim, não podemos saber por certo o valor mais recente de um nome sem confiar em um valor completo nó, ou incorrer em custos significativos em largura de banda baixando todo o blockchain. Mesmo que uma árvore de pesquisa Merkleizada fosse implementada no NameCoin, sua dependência de proof-of-work facilita a verificação do cliente problemático. Os clientes Light devem baixar uma cópia completa do cabeçalhos para todos os blocos em todo o blockchain (ou pelo menos todos os cabeçalhos desde a última atualização de um nome). Isto significa que o os requisitos de largura de banda aumentam linearmente com a quantidade de tempo [21]. Além disso, mudanças de nome em proof-of-work blockchain requer espera por blocos de confirmação proof-of-work adicionais, o que pode levar até uma hora em Bitcoin. Com o Tendermint, tudo que precisamos é do bloco mais recente-hash assinado por um quórum de validators (por poder de voto) e um Merkle prova para o valor atual associado ao nome. Isso faz com que possível ter um light-client sucinto, rápido e seguro verificação dos valores dos nomes. Em Cosmos, podemos pegar esse conceito e estendê-lo ainda mais. Cada zona de registro de nome em Cosmos pode ter um nome de domínio de nível superior (TLD) associado, como “.com” ou “.org”, e cada nome-
zona de registro pode ter sua própria governança e registro regras.
Governance and Economics
Governance and Economics
While the Cosmos Hub is a multi-asset distributed ledger, there is a special native token called the atom. Atoms are the only staking token of the Cosmos Hub. Atoms are a license for the holder to vote, validate, or delegate to other validators. Like Ethereum’s ether, atoms can also be used to pay for transaction fees to mitigate spam. Additional inzationary atoms and block transaction fees are rewarded to validators and delegators who delegate to validators. The BurnAtomTx transaction can be used to recover any proportionate amount of tokens from the reserve pool. The initial distribution of atom tokens and validators on Genesis will go to the donors of the Cosmos Fundraiser (75%), lead donors (5%), Cosmos Network Foundation (10%), and ALL IN BITS, Inc (10%). From genesis onward, 1/3 of the total amount of atoms will be rewarded to bonded validators and delegators every year. See the Cosmos Plan for additional details. Unlike Bitcoin or other proof-of-work blockchains, a Tendermint blockchain gets slower with more validators due to the increased communication complexity. Fortunately, we can support enough validators to make for a robust globally distributed blockchain with very fast transaction conyrmation times, and, as bandwidth,
storage, and parallel compute capacity increases, we will be able to support more validators in the future. On genesis day, the maximum number of validators will be set to 100, and this number will increase at a rate of 13% for 10 years, and settle at 300 validators. Atom holders who are not already can become validators by signing and submitting a BondTx transaction. The amount of atoms provided as collateral must be nonzero. Anyone can become a validator at any time, except when the size of the current validator set is greater than the maximum number of validators allowed. In that case, the transaction is only valid if the amount of atoms is greater than the amount of effective atoms held by the smallest validator, where effective atoms include delegated atoms. When a new validator replaces an existing validator in such a way, the existing validator becomes inactive and all the atoms and delegated atoms enter the unbonding state. There must be some penalty imposed on the validators for any intentional or unintentional deviation from the sanctioned protocol. Some evidence is immediately admissible, such as a double-sign at the same height and round, or a violation of Year 0: 100 Year 1: 113 Year 2: 127 Year 3: 144 Year 4: 163 Year 5: 184 Year 6: 208 Year 7: 235 Year 8: 265 Year 9: 300 Year 10: 300 ...
“prevote-the-lock” (a rule of the Tendermint consensus protocol). Such evidence will result in the validator losing its good standing and its bonded atoms as well its proportionate share of tokens in the reserve pool – collectively called its “stake” – will get slashed. Sometimes, validators will not be available, either due to regional network disruptions, power failure, or other reasons. If, at any point in the past ValidatorTimeoutWindow blocks, a validator’s commit vote is not included in the blockchain more than ValidatorTimeoutMaxAbsent times, that validator will become inactive, and lose ValidatorTimeoutPenalty (DEFAULT 1%) of its stake. Some “malicious” behavior does not produce obviously discernable evidence on the blockchain. In these cases, the validators can coordinate out of band to force the timeout of these malicious validators, if there is a supermajority consensus. In situations where the Cosmos Hub halts due to a \(\geq 1/3\) coalition of voting power going ofzine, or in situations where a \(\geq 1/3\) coalition of voting power censor evidence of malicious behavior from entering the blockchain, the hub must recover with a hard-fork reorg-proposal. (Link to “Forks and Censorship Attacks”). Cosmos Hub validators can accept any token type or combination of types as fees for processing a transaction. Each validator can subjectively set whatever exchange rate it wants, and choose whatever transactions it wants, as long as the BlockGasLimit is not exceeded. The collected fees, minus any taxes speciyed below, are redistributed to the bonded stakeholders in proportion to their bonded atoms, every ValidatorPayoutPeriod (DEFAULT 1 hour).
Of the collected transaction fees, ReserveTax (DEFAULT 2%) will go toward the reserve pool to increase the reserve pool and increase the security and value of the Cosmos network. These funds can also be distributed in accordance with the decisions made by the governance system. Atom holders who delegate their voting power to other validators pay a commission to the delegated validator. The commission can be set by each validator. The security of the Cosmos Hub is a function of the security of the underlying validators and the choice of delegation by delegators. In order to encourage the discovery and early reporting of found vulnerabilities, the Cosmos Hub encourages hackers to publish successful exploits via a ReportHackTx transaction that says, “This validator got hacked. Please send bounty to this address”. Upon such an exploit, the validator and delegators will become inactive, HackPunishmentRatio (default 5%) of everyone’s atoms will get slashed, and HackRewardRatio (default 5%) of everyone’s atoms will get rewarded to the hacker’s bounty address. The validator must recover the remaining atoms by using their backup key. In order to prevent this feature from being abused to transfer unvested atoms, the portion of vested vs unvested atoms of validators and delegators before and after the ReportHackTx will remain the same, and the hacker bounty will include some unvested atoms, if any. The Cosmos Hub is operated by a distributed organization that requires a well-deyned governance mechanism in order to coordinate various changes to the blockchain, such as the variable
parameters of the system, as well as software upgrades and constitutional amendments. All validators are responsible for voting on all proposals. Failing to vote on a proposal in a timely manner will result in the validator being deactivated automatically for a period of time called the AbsenteeismPenaltyPeriod (DEFAULT 1 week). Delegators automatically inherit the vote of the delegated validator. This vote may be overridden manually. Unbonded atoms get no vote. Each proposal requires a deposit of MinimumProposalDeposit tokens, which may be a combination of one or more tokens including atoms. For each proposal, the voters may vote to take the deposit. If more than half of the voters choose to take the deposit (e.g. because the proposal was spam), the deposit goes to the reserve pool, except any atoms which are burned. For each proposal, voters may vote with the following options: Yea YeaWithForce Nay NayWithForce Abstain A strict majority of Yea or YeaWithForce votes (or Nay or NayWithForce votes) is required for the proposal to be decided as passed (or decided as failed), but 1/3+ can veto the majority decision by voting “with force”. When a strict majority is vetoed, everyone gets punished by losing VetoPenaltyFeeBlocks (DEFAULT 1 day’s worth of blocks) worth of fees (except taxes which will not be affected), and the party that vetoed the majority
decision will be additionally punished by losing VetoPenaltyAtoms (DEFAULT 0.1%) of its atoms. Any of the parameters deyned here can be changed with the passing of a ParameterChangeProposal . Atoms can be inzated and reserve pool funds spent with the passing of a BountyProposal . All other proposals, such as a proposal to upgrade the protocol, will be coordinated via the generic TextProposal . See the Plan. There have been many innovations in blockchain consensus and scalability in the past couple of years. This section provides a brief survey of a select number of important ones. Consensus in the presence of malicious participants is a problem dating back to the early 1980s, when Leslie Lamport coined the phrase “Byzantine fault” to refer to arbitrary process behavior that deviates from the intended behavior, in contrast to a “crash fault”, wherein a process simply crashes. Early solutions were discovered for synchronous networks where there is an upper bound on
message latency, though practical use was limited to highly controlled environments such as airplane controllers and datacenters synchronized via atomic clocks. It was not until the late 90s that Practical Byzantine Fault Tolerance (PBFT) [11] was introduced as an efycient partially synchronous consensus algorithm able to tolerate up to ⅓ of processes behaving arbitrarily. PBFT became the standard algorithm, spawning many variations, including most recently one created by IBM as part of their contribution to Hyperledger. The main beneyt of Tendermint consensus over PBFT is that Tendermint has an improved and simpliyed underlying structure, some of which is a result of embracing the blockchain paradigm. Tendermint blocks must commit in order, which obviates the complexity and communication overhead associated with PBFT’s view-changes. In Cosmos and many cryptocurrencies, there is no need to allow for block N+i where i >= 1 to commit, when block N itself hasn’t yet committed. If bandwidth is the reason why block N hasn’t committed in a Cosmos zone, then it doesn’t help to use bandwidth sharing votes for blocks N+i. If a network partition or ofzine nodes is the reason why block N hasn’t committed, then N+i won’t commit anyway. In addition, the batching of transactions into blocks allows for regular Merkle-hashing of the application state, rather than periodic digests as with PBFT’s checkpointing scheme. This allows for faster provable transaction commits for light-clients and faster inter-blockchain communication. Tendermint Core also includes many optimizations and features that go above and beyond what is speciyed in PBFT. For example, the blocks proposed by validators are split into parts, Merkle-ized, and gossipped in such a way that improves broadcasting performance (see LibSwift [19] for inspiration). Also, Tendermint Core doesn’t make any assumption about point-to-point
connectivity, and functions for as long as the P2P network is weakly connected. While not the yrst to deploy proof-of-stake (PoS), BitShares1.0 [12] contributed considerably to research and adoption of PoS blockchains, particularly those known as “delegated” PoS. In BitShares, stake holders elect "witnesses", responsible for ordering and committing transactions, and "delegates", responsible for coordinating software updates and parameter changes. BitShares2.0 aims to achieve high performance (100k tx/s, 1s latency) in ideal conditions, with each block signed by a single signer, and transaction ynality taking quite a bit longer than the block interval. A canonical speciycation is still in development. Stakeholders can remove or replace misbehaving witnesses on a daily basis, but there is no signiycant collateral of witnesses or delegators in the likeness of Tendermint PoS that get slashed in the case of a successful double-spend attack. Building on an approach pioneered by Ripple, Stellar [13] reyned a model of Federated Byzantine Agreement wherein the processes participating in consensus do not constitute a yxed and globally known set. Rather, each process node curates one or more “quorum slices”, each constituting a set of trusted processes. A “quorum” in Stellar is deyned to be a set of nodes that contain at least one quorum slice for each node in the set, such that agreement can be reached. The security of the Stellar mechanism relies on the assumption that the intersection of any two quorums is non-empty, while the availability of a node requires at least one of its quorum slices to consist entirely of correct nodes, creating a trade-off between using large or small quorum-slices that may be difycult to balance without imposing signiycant assumptions about trust. Ultimately,
nodes must somehow choose adequate quorum slices for there to be sufycient fault-tolerance (or any “intact nodes” at all, of which much of the results of the paper depend on), and the only provided strategy for ensuring such a conyguration is hierarchical and similar to the Border Gateway Protocol (BGP), used by toptier ISPs on the internet to establish global routing tables, and by that used by browsers to manage TLS certiycates; both notorious for their insecurity. The criticism in the Stellar paper of the Tendermint-based proofof-stake systems is mitigated by the token strategy described here, wherein a new type of token called the atom is issued that represent claims to future portions of fees and rewards. The advantage of Tendermint-based proof-of-stake, then, is its relative simplicity, while still providing sufycient and provable security guarantees. BitcoinNG is a proposed improvement to Bitcoin that would allow for forms of vertical scalability, such as increasing the block size, without the negative economic consequences typically associated with such a change, such as the disproportionately large impact on small miners. This improvement is achieved by separating leader election from transaction broadcast: leaders are yrst elected by proof-of-work in “micro-blocks”, and then able to broadcast transactions to be committed until a new micro-block is found. This reduces the bandwidth requirements necessary to win the PoW race, allowing small miners to more fairly compete, and allowing transactions to be committed more regularly by the last miner to ynd a micro-block. Casper [16] is a proposed proof-of-stake consensus algorithm for Ethereum. Its prime mode of operation is “consensus-by-bet”. By letting validators iteratively bet on which block they believe will
become committed into the blockchain based on the other bets that they have seen so far, ynality can be achieved eventually. link. This is an active area of research by the Casper team. The challenge is in constructing a betting mechanism that can be proven to be an evolutionarily stable strategy. The main beneyt of Casper as compared to Tendermint may be in offering “availability over consistency” – consensus does not require a \(> 2/3\) quorum of voting power – perhaps at the cost of commit speed or implementation complexity. The Interledger Protocol [14] is not strictly a scalability solution. It provides an ad hoc interoperation between different ledger systems through a loosely coupled bilateral relationship network. Like the Lightning Network, the purpose of ILP is to facilitate payments, but it speciycally focuses on payments across disparate ledger types, and extends the atomic transaction mechanism to include not only hash-locks, but also a quorum of notaries (called the Atomic Transport Protocol). The latter mechanism for enforcing atomicity in inter-ledger transactions is similar to Tendermint’s light-client SPV mechanism, so an illustration of the distinction between ILP and Cosmos/IBC is warranted, and provided below. 1. The notaries of a connector in ILP do not support membership changes, and do not allow for zexible weighting between notaries. On the other hand, IBC is designed speciycally for blockchains, where validators can have different weights, and where membership can change over the course of the blockchain. 2. As in the Lightning Network, the receiver of payment in ILP must be online to send a conyrmation back to the sender. In a
token transfer over IBC, the validator-set of the receiver’s blockchain is responsible for providing conyrmation, not the receiving user. 3. The most striking difference is that ILP’s connectors are not responsible or keeping authoritative state about payments, whereas in Cosmos, the validators of a hub are the authority of the state of IBC token transfers as well as the authority of the amount of tokens held by each zone (but not the amount of tokens held by each account within a zone). This is the fundamental innovation that allows for secure asymmetric transfer of tokens from zone to zone; the analog to ILP’s connector in Cosmos is a persistent and maximally secure blockchain ledger, the Cosmos Hub. 4. The inter-ledger payments in ILP need to be backed by an exchange orderbook, as there is no asymmetric transfer of coins from one ledger to another, only the transfer of value or market equivalents. Sidechains [15] are a proposed mechanism for scaling the Bitcoin network via alternative blockchains that are “two-way pegged” to the Bitcoin blockchain. (Two-way pegging is equivalent to bridging. In Cosmos we say "bridging" to distinguish from marketpegging). Sidechains allow bitcoins to effectively move from the Bitcoin blockchain to the sidechain and back, and allow for experimentation in new features on the sidechain. As in the Cosmos Hub, the sidechain and Bitcoin serve as light-clients of each other, using SPV proofs to determine when coins should be transferred to the sidechain and back. Of course, since Bitcoin uses proof-of-work, sidechains centered around Bitcoin suffer from the many problems and risks of proof-of-work as a consensus mechanism. Furthermore, this is a Bitcoin-maximalist solution that doesn’t natively support a variety of tokens and
inter-zone network topology as Cosmos does. That said, the core mechanism of the two-way peg is in principle the same as that employed by the Cosmos network. Ethereum is currently researching a number of different strategies to shard the state of the Ethereum blockchain to address scalability needs. These efforts have the goal of maintaining the abstraction layer offered by the current Ethereum Virtual Machine across the shared state space. Multiple research efforts are underway at this time. [18][22] Cosmos and Ethereum 2.0 Mauve [22] have different design goals. Cosmos is speciycally about tokens. Mauve is about scaling general computation. Cosmos is not bound to the EVM, so even different VMs can interoperate. Cosmos lets the zone creator determine who validates the zone. Anyone can start a new zone in Cosmos (unless governance decides otherwise). The hub isolates zone failures so global token invariants are preserved. The Lightning Network is a proposed token transfer network operating at a layer above the Bitcoin blockchain (and other public blockchains), enabling improvement of many orders of magnitude in transaction throughput by moving the majority of transactions outside of the consensus ledger into so-called “payment channels”.
This is made possible by on-chain cryptocurrency scripts, which enable parties to enter into bilateral stateful contracts where the state can be updated by sharing digital signatures, and contracts can be closed by ynally publishing evidence onto the blockchain, a mechanism yrst popularized by cross-chain atomic swaps. By opening payment channels with many parties, participants in the Lightning Network can become focal points for routing the payments of others, leading to a fully connected payment channel network, at the cost of capital being tied up on payment channels. While the Lightning Network can also easily extend across multiple independent blockchains to allow for the transfer of value via an exchange market, it cannot be used to asymmetrically transfer tokens from one blockchain to another. The main beneyt of the Cosmos network described here is to enable such direct token transfers. That said, we expect payment channels and the Lightning Network to become widely adopted along with our token transfer mechanism, for cost-saving and privacy reasons. Segregated Witness is a Bitcoin improvement proposal link that aims to increase the per-block transaction throughput 2X or 3X, while simultaneously making block syncing faster for new nodes. The brilliance of this solution is in how it works within the limitations of Bitcoin’s current protocol and allows for a soft-fork upgrade (i.e. clients with older versions of the software will continue to function after the upgrade). Tendermint, being a new protocol, has no design restrictions, so it has a different scaling priorities. Primarily, Tendermint uses a BFT round-robin algorithm based on cryptographic signatures instead of mining, which trivially allows horizontal scaling through multiple parallel blockchains, while regular, more frequent block commits allow for vertical scaling as well.
Governança e Economia
Embora o Hub Cosmos seja um livro-razão distribuído de vários ativos, há um nativo especial token chamado átomo. Os átomos são os únicos staking token do hub Cosmos. Os átomos são uma licença para o titular votar, validar ou delegar para outros validators. Como Ethereum éter, os átomos também podem ser usados para pagar taxas de transação para mitigar spam. Átomos inzacionários adicionais e transação em bloco as taxas são recompensadas para validators e delegadores que delegam para validators. A transação BurnAtomTx pode ser usada para recuperar qualquer quantidade proporcional de tokens do pool de reserva. A distribuição inicial dos átomos tokens e validators no Gênesis irá para os doadores da arrecadação de fundos Cosmos (75%), doadores principais (5%), Cosmos Network Foundation (10%) e ALL IN BITS, Inc. (10%). Da gênese em diante, 1/3 da quantidade total de átomos será ser recompensado a validators e delegadores vinculados todos os anos. Consulte o Plano Cosmos para obter detalhes adicionais. Ao contrário de Bitcoin ou outros proof-of-work blockchains, um Tendermint blockchain fica mais lento com mais validators devido ao aumento complexidade da comunicação. Felizmente, podemos apoiar o suficiente validators para criar um blockchain robusto e globalmente distribuído com tempos de confirmação de transação muito rápidos e, como largura de banda,
armazenamento e aumento da capacidade de computação paralela, seremos capazes para oferecer suporte a mais validators no futuro. No dia da gênese, o número máximo de validators será definido para 100, e esse número aumentará a uma taxa de 13% durante 10 anos, e estabilize em 300 validators. Os detentores de átomos que ainda não o são podem se tornar validators por assinar e enviar uma transação BondTx . A quantidade de os átomos fornecidos como garantia devem ser diferentes de zero. Qualquer um pode se tornar a validator a qualquer momento, exceto quando o tamanho do atual validator conjunto é maior que o número máximo de validators permitido. Nesse caso, a transação só é válida se o valor do átomos é maior que a quantidade de átomos efetivos mantidos pelo menor validator, onde átomos efetivos incluem átomos delegados. Quando um novo validator substitui um validator existente dessa forma, o validator existente torna-se inativo e todos os átomos e átomos delegados entram no estado de desvinculação. Deve haver alguma penalidade imposta aos validators para qualquer desvio intencional ou não intencional do sancionado protocolo. Algumas provas são imediatamente admissíveis, como uma sinal duplo na mesma altura e redondo, ou violação de Ano 0: 100 Ano 1: 113 Ano 2: 127 Ano 3: 144 Ano 4: 163 Ano 5: 184 Ano 6: 208 Ano 7: 235 Ano 8: 265 Ano 9: 300 Ano 10: 300 ...
“prevote-the-lock” (uma regra do protocolo de consenso Tendermint). Tal evidência resultará na perda de sua regularidade por validator e seus átomos ligados, bem como sua parcela proporcional de tokens em o conjunto de reservas – coletivamente chamado de “participação” – será reduzido. Às vezes, validators não estarão disponíveis, seja devido a questões regionais interrupções de rede, falha de energia ou outros motivos. Se, em qualquer ponto nos últimos blocos ValidatorTimeoutWindow , um validator commit vote não está incluído em blockchain mais de ValidatorTimeoutMaxAbsent, esse validator se tornará inativo e perderá ValidatorTimeoutPenalty (PADRÃO 1%) de seu aposta. Alguns comportamentos “maliciosos” não produzem resultados obviamente discerníveis evidências em blockchain. Nestes casos, os validators podem coordenar fora da banda para forçar o tempo limite desses maliciosos validators, se houver consenso por maioria qualificada. Em situações em que o Hub Cosmos para devido a uma coalizão ≥⅓ de poder de voto saindo do zine ou em situações em que uma coalizão ≥⅓ do poder de voto censurar evidências de comportamento malicioso de entrando no blockchain, o hub deve se recuperar com um hard-fork proposta de reorganização. (Link para “Forks e ataques de censura”). Cosmos Hub validators podem aceitar qualquer tipo ou combinação de token de tipos como taxas para processar uma transação. Cada validator pode definir subjetivamente qualquer taxa de câmbio desejada e escolher quaisquer transações que desejar, desde que o BlockGasLimit seja não excedido. As taxas cobradas, menos quaisquer impostos especificados abaixo, são redistribuídos às partes interessadas vinculadas na proporção seus átomos ligados, cada ValidatorPayoutPeriod (DEFAULT 1 hora).Das taxas de transação cobradas, ReserveTax (PADRÃO 2%) será vá em direção ao pool de reserva para aumentar o pool de reserva e aumentar a segurança e o valor da rede Cosmos. Estes os fundos também podem ser distribuídos de acordo com as decisões feita pelo sistema de governança. Detentores de átomos que delegam seu poder de voto a outros validators pagar uma comissão ao delegado validator. A comissão pode ser definido por cada validator. A segurança do Hub Cosmos é uma função da segurança do validators subjacentes e a escolha da delegação pelos delegantes. A fim de encorajar a descoberta e a notificação precoce de vulnerabilidades, o Hub Cosmos incentiva os hackers a publicar explorações bem-sucedidas por meio de uma transação ReportHackTx que diz: “Este validator foi hackeado. Por favor, envie recompensa para este endereço”. Após tal exploração, o validator e os delegantes ficarão inativos, HackPunishmentRatio (padrão 5%) dos átomos de todos receberão cortado e HackRewardRatio (padrão 5%) dos átomos de todos será recompensado no endereço de recompensa do hacker. O validator deve recuperar os átomos restantes usando sua chave de backup. Para evitar que este recurso seja abusado para transferir átomos não adquiridos, a porção de átomos adquiridos versus átomos não adquiridos de validators e delegadores antes e depois do ReportHackTx permanecem os mesmos, e a recompensa do hacker incluirá alguns átomos não adquiridos, se houver. O Cosmos Hub é operado por uma organização distribuída que requer um mecanismo de governança bem definido para coordenar várias alterações no blockchain, como a variável
parâmetros do sistema, bem como atualizações de software e emendas constitucionais. Todos os validators são responsáveis pela votação de todas as propostas. Falhando em votar uma proposta em tempo hábil resultará em validator sendo desativado automaticamente por um período de tempo denominado AbsenteísmoPenaltyPeriod (PADRÃO 1 semana). Os delegadores herdam automaticamente o voto do delegado validator. Esta votação pode ser anulada manualmente. Átomos não ligados não obtenha voto. Cada proposta exige um depósito de MinimumProposalDeposit tokens, que pode ser uma combinação de um ou mais tokens incluindo átomos. Para cada proposta, os eleitores poderão votar para o depósito. Se mais de metade dos eleitores optarem por depósito (por exemplo, porque a proposta era spam), o depósito vai para reserva, exceto quaisquer átomos que sejam queimados. Para cada proposta, os eleitores poderão votar com as seguintes opções: Sim Sim com força Não NayWithForce Abster-se Uma maioria estrita de votos Sim ou Sim com Força (ou Não ou votos NayWithForce) é necessário para que a proposta seja decidida como aprovado (ou considerado reprovado), mas 1/3+ pode vetar a maioria decisão votando “com força”. Quando uma maioria estrita é vetada, todos são punidos com a perda de VetoPenaltyFeeBlocks (PADRÃO 1 dia de blocos) valor de taxas (exceto impostos que não será afetado), e o partido que vetou a maioria
a decisão será punida adicionalmente com a perda de VetoPenaltyAtoms (PADRÃO 0,1%) de seus átomos. Qualquer um dos parâmetros aqui definidos pode ser alterado com o passagem de uma ParameterChangeProposal . Os átomos podem ser injetados e os fundos do pool de reserva gastos com o aprovação de uma Proposta de Recompensa . Todas as outras propostas, como uma proposta para atualizar o protocolo, será coordenado por meio da TextProposal genérica. Veja o Plano. Houve muitas inovações no consenso blockchain e escalabilidade nos últimos dois anos. Esta seção fornece um breve levantamento de um seleto número de importantes. O consenso na presença de participantes mal-intencionados é um problema que remonta ao início da década de 1980, quando Leslie Lamport cunhou o frase “falha bizantina” para se referir ao comportamento arbitrário do processo que se desvia do comportamento pretendido, em contraste com uma “falha de colisão”, em que um processo simplesmente falha. As primeiras soluções foram descobertas para redes síncronas onde existe um limite superiorlatência da mensagem, embora o uso prático fosse limitado a altamente ambientes controlados, como controladores de aviões e datacenters sincronizados por meio de relógios atômicos. Não foi até o final dos anos 90 que a tolerância prática a falhas bizantinas (PBFT) [11] foi introduzido como um consenso eficiente parcialmente síncrono algoritmo capaz de tolerar até ⅓ dos processos se comportando arbitrariamente. PBFT tornou-se o algoritmo padrão, gerando muitos variações, incluindo mais recentemente uma criada pela IBM como parte do sua contribuição para o Hyperledger. O principal benefício do consenso do Tendermint sobre PBFT é que Tendermint tem uma estrutura subjacente melhorada e simplificada, alguns dos quais são resultado da adoção do paradigma blockchain. Os blocos do Tendermint devem ser confirmados em ordem, o que evita o complexidade e sobrecarga de comunicação associada a PBFT's mudanças de visualização. Em Cosmos e em muitas criptomoedas, não há precisa permitir que o bloco N+i onde i >= 1 seja confirmado, quando o bloco N em si ainda não se comprometeu. Se a largura de banda é a razão pela qual o bloco N não fez commit em uma zona Cosmos, então não ajuda usar votos de compartilhamento de largura de banda para blocos N+i. Se uma partição de rede ou nós ofzine é a razão pela qual o bloco N não foi confirmado, então N+i não vou me comprometer de qualquer maneira. Além disso, o agrupamento de transações em blocos permite Merkle-hashing regular do estado do aplicativo, em vez de resumos periódicos como no esquema de checkpoint de PBFT. Isso permite para commits de transações comprováveis mais rápidos para clientes leves e mais rápidos comunicação inter-blockchain. Tendermint Core também inclui muitas otimizações e recursos que vão além do especificado em PBFT. Por exemplo, os blocos propostos por validators são divididos em partes, Merkle-izados, e fofocaram de uma forma que melhorou a transmissão desempenho (veja LibSwift [19] para inspiração). Além disso, Tendermint Core não faz nenhuma suposição sobre ponto a ponto
conectividade e funções enquanto a rede P2P estiver fracamente conectado. Embora não seja o primeiro a implantar proof-of-stake (PoS), BitShares1.0 [12] contribuiu consideravelmente para a pesquisa e adoção de PoS blockchains, especialmente aqueles conhecidos como PoS “delegados”. Em BitShares, stakeholders elegem “testemunhas”, responsáveis pelo pedido e cometer transações, e "delegados", responsáveis por coordenar atualizações de software e alterações de parâmetros. BitShares2.0 visa alcançar alto desempenho (100k tx/s, 1s latência) em condições ideais, com cada bloco assinado por um único assinante e a ynalidade da transação demorando um pouco mais do que o intervalo de bloco. Uma especificação canônica ainda está em desenvolvimento. As partes interessadas podem remover ou substituir testemunhas que se comportam mal em uma diariamente, mas não há nenhuma garantia significativa de testemunhas ou delegadores à semelhança do Tendermint PoS que são cortados o caso de um ataque de gasto duplo bem-sucedido. Com base em uma abordagem pioneira em Ripple, Stellar [13] refina um modelo de Acordo Federado Bizantino em que os processos participar em consenso não constitui uma situação yxa e global conjunto conhecido. Em vez disso, cada nó do processo faz a curadoria de um ou mais “fatias de quórum”, cada uma constituindo um conjunto de processos confiáveis. Um “quorum” em Stellar é definido como um conjunto de nós que contém pelo menos pelo menos uma fatia de quorum para cada nó do conjunto, de modo que um acordo pode ser alcançado. A segurança do mecanismo Stellar depende da suposição que a interseção de quaisquer dois quóruns não é vazia, enquanto o a disponibilidade de um nó requer que pelo menos uma de suas fatias de quorum seja consistem inteiramente em nós corretos, criando um trade-off entre usando fatias de quórum grandes ou pequenas que podem ser difíceis de equilibrar sem impor suposições significativas sobre confiança. Em última análise,os nós devem de alguma forma escolher fatias de quorum adequadas para que haja ter tolerância a falhas suficiente (ou quaisquer “nós intactos”, dos quais muitos dos resultados do artigo dependem), e o único estratégia fornecida para garantir que tal configuração seja hierárquica e semelhante ao Border Gateway Protocol (BGP), usado por ISPs de primeira linha na Internet para estabelecer tabelas de roteamento globais, e por aquele usado pelos navegadores para gerenciar certificados TLS; ambos notórios pela sua insegurança. As críticas no artigo Stellar aos sistemas de prova de participação baseados no Tendermint são atenuadas pela estratégia token descrita aqui, onde um novo tipo de token chamado átomo é emitido que representam reivindicações de parcelas futuras de taxas e recompensas. O vantagem do proof-of-stake baseado em Tendermint, então, é seu relativo simplicidade, ao mesmo tempo que fornece segurança suficiente e comprovável garantias. BitcoinNG é uma melhoria proposta para Bitcoin que permitiria para formas de escalabilidade vertical, como aumentar o tamanho do bloco, sem as consequências económicas negativas normalmente associadas com tal mudança, como o impacto desproporcionalmente grande em pequenos mineiros. Esta melhoria é conseguida através da separação eleição do líder a partir da transmissão da transação: os líderes são os primeiros eleito por proof-of-work em “microblocos”, e então capaz de transações de transmissão a serem confirmadas até um novo microbloco é encontrado. Isto reduz os requisitos de largura de banda necessários para vencer a corrida PoW, permitindo que pequenos mineiros concorram de forma mais justa, e permitindo que as transações sejam cometidas com mais regularidade pelos último mineiro a encontrar um microbloco. Casper [16] é um algoritmo de consenso proof-of-stake proposto para Ethereum. Seu principal modo de operação é “consenso por aposta”. Por deixando validators apostar iterativamente em qual bloco eles acreditam que irá
tornar-se comprometido com blockchain com base nas outras apostas que eles viram até agora, a inalidade pode ser alcançada eventualmente. link. Esta é uma área ativa de pesquisa da equipe Casper. O desafio está na construção de um mecanismo de apostas que possa ser provou ser uma estratégia evolutivamente estável. O principal benefício de Casper, em comparação com Tendermint, pode oferecer “disponibilidade consistência excessiva” – o consenso não requer um quórum >⅔ de poder de voto - talvez ao custo da velocidade de confirmação ou complexidade de implementação. O Protocolo Interledger [14] não é estritamente uma solução de escalabilidade. Isso fornece uma interoperação ad hoc entre diferentes livros contábeis sistemas através de uma rede de relacionamento bilateral fracamente acoplada. Assim como a Lightning Network, o objetivo do ILP é facilitar pagamentos, mas concentra-se especificamente em pagamentos em diferentes tipos de razão e estende o mecanismo de transação atômica para incluem não apenas hash-locks, mas também um quórum de notários (chamado Protocolo de Transporte Atômico). Este último mecanismo para impor a atomicidade em transações entre livros é semelhante a O mecanismo SPV de cliente leve do Tendermint, portanto, uma ilustração do a distinção entre ILP e Cosmos/IBC é garantida, e fornecido abaixo. 1. Os cartórios de um conector no ILP não apoiam a adesão mudanças, e não permitem ponderação zexível entre notários. Por outro lado, IBC foi projetado especificamente para blockchains, onde validators podem ter pesos diferentes, e onde a adesão pode mudar ao longo do blockchain. 2. Assim como na Lightning Network, o destinatário do pagamento no ILP deve estar on-line para enviar uma confirmação ao remetente. Em umtoken transferência sobre IBC, o conjunto validator do receptor blockchain é responsável por fornecer a confirmação, não o usuário receptor. 3. A diferença mais marcante é que os conectores do ILP não são responsável ou mantendo estado de autoridade sobre pagamentos, enquanto em Cosmos, os validators de um hub são autoridade de o estado de IBC token transfere, bem como a autoridade do quantidade de tokens mantidos por cada zona (mas não a quantidade de tokens mantidos por cada conta dentro de uma zona). Este é o inovação fundamental que permite segurança assimétrica transferência de tokens de zona para zona; o análogo ao ILP conector em Cosmos é persistente e maximamente seguro blockchain razão, o hub Cosmos. 4. Os pagamentos entre livros no ILP precisam ser respaldados por um carteira de ordens de câmbio, pois não há transferência assimétrica de moedas de um livro-razão para outro, apenas a transferência de valor ou equivalentes de mercado. Sidechains [15] são um mecanismo proposto para dimensionar o Bitcoin rede por meio de blockchains alternativos que são “atrelados bidirecionalmente” a o Bitcoin blockchain. (A indexação bidirecional é equivalente a ponte. Em Cosmos dizemos "ponte" para distinguir de marketpegging). Sidechains permitem que os bitcoins se movam efetivamente do Bitcoin blockchain para a cadeia lateral e para trás, e permitir experimentação de novos recursos na cadeia lateral. Como no Cosmos Hub, o sidechain e Bitcoin servem como clientes leves de entre si, usando provas SPV para determinar quando as moedas devem ser transferido para a cadeia lateral e vice-versa. Claro, desde Bitcoin usa proof-of-work, cadeias laterais centradas em Bitcoin sofrem dos muitos problemas e riscos de proof-of-work como um mecanismo de consenso. Além disso, este é um Bitcoin-maximalista solução que não suporta nativamente uma variedade de tokens e
topologia de rede entre zonas como Cosmos faz. Dito isto, o núcleo O mecanismo da cavilha bidirecional é, em princípio, o mesmo que empregado pela rede Cosmos. Ethereum está atualmente pesquisando diversas estratégias diferentes para fragmentar o estado de Ethereum blockchain para resolver necessidades de escalabilidade. Esses esforços têm como objetivo manter a camada de abstração oferecida pela máquina virtual Ethereum atual em todo o espaço de estado compartilhado. Múltiplos esforços de pesquisa são em andamento neste momento. [18][22] Cosmos e Ethereum 2.0 Mauve [22] têm objetivos de design diferentes. Cosmos é especificamente sobre tokens. Mauve é sobre dimensionamento cálculo geral. Cosmos não está vinculado a EVM, portanto, mesmo VMs diferentes podem interoperar. Cosmos permite que o criador da zona determine quem valida o zona. Qualquer pessoa pode iniciar uma nova zona em Cosmos (a menos que a governança decide de outra forma). O hub isola falhas de zona para que invariantes token globais sejam preservado. A Lightning Network é uma rede de transferência proposta token operando em uma camada acima de Bitcoin blockchain (e outros públicos blockchains), permitindo melhorias em muitas ordens de magnitude no rendimento da transação, movendo a maioria das transações fora do livro-razão de consenso nos chamados “canais de pagamento”.Isso é possível graças aos scripts de criptomoeda on-chain, que permitir que as partes celebrem contratos bilaterais estatais onde o o estado pode ser atualizado compartilhando assinaturas digitais e contratos pode ser encerrado publicando inicialmente evidências no blockchain, um mecanismo inicialmente popularizado por trocas atômicas entre cadeias. Por abrindo canais de pagamento com muitas partes, participantes do A Lightning Network pode se tornar pontos focais para rotear o pagamentos de terceiros, levando a um canal de pagamento totalmente conectado rede, ao custo do capital estar vinculado aos canais de pagamento. Embora a Lightning Network também possa se estender facilmente por vários blockchains independentes para permitir a transferência de valor através de um mercado de câmbio, não pode ser usado para transferir tokens de um blockchain para outro. O principal benefício da rede Cosmos descrita aqui é permitir tal token transferências. Dito isto, esperamos que os canais de pagamento e o Lightning Network será amplamente adotada junto com nosso token mecanismo de transferência, por razões de economia de custos e privacidade. Segregated Witness é um link de proposta de melhoria Bitcoin que visa aumentar o rendimento da transação por bloco em 2X ou 3X, ao mesmo tempo que torna a sincronização de blocos mais rápida para novos nós. O brilho desta solução está em como ela funciona dentro do limitações do protocolo atual de Bitcoin e permite um soft-fork atualização (ou seja, clientes com versões mais antigas do software continuar a funcionar após a atualização). Tendermint, sendo um novo protocolo, não tem restrições de design, portanto tem um escalonamento diferente prioridades. Principalmente, o Tendermint usa um algoritmo round-robin BFT baseado em assinaturas criptográficas em vez de mineração, que permite trivialmente o escalonamento horizontal através de múltiplos paralelos blockchains, enquanto commits de bloco regulares e mais frequentes permitem escala vertical também.
Consensus and Technical Details
Consensus and Technical Details
A well designed consensus protocol should provide some guarantees in the event that the tolerance capacity is exceeded and the consensus fails. This is especially necessary in economic systems, where Byzantine behaviour can have substantial ynancial reward. The most important such guarantee is a form of forkaccountability, where the processes that caused the consensus to fail (ie. caused clients of the protocol to accept different values - a fork) can be identiyed and punished according to the rules of the protocol, or, possibly, the legal system. When the legal system is unreliable or excessively expensive to invoke, validators can be forced to make security deposits in order to participate, and those deposits can be revoked, or slashed, when malicious behaviour is detected [10]. Note this is unlike Bitcoin, where forking is a regular occurence due to network asynchrony and the probabilistic nature of ynding partial hash collisions. Since in many cases a malicious fork is indistinguishable from a fork due to asynchrony, Bitcoin cannot reliably implement fork-accountability, other than the implicit opportunity cost paid by miners for mining an orphaned block. We call the voting stages PreVote and PreCommit. A vote can be for a particular block or for Nil. We call a collection of \(> 2/3\) PreVotes for a single block in the same round a Polka, and a collection of \(> 2/3\) PreCommits for a single block in the same round a Commit. If \(> 2/3\) PreCommit for Nil in the same round, they move to the next round. Note that strict determinism in the protocol incurs a weak synchrony assumption as faulty leaders must be detected and
skipped. Thus, validators wait some amount of time, TimeoutPropose, before they Prevote Nil, and the value of TimeoutPropose increases with each round. Progression through the rest of a round is fully asynchronous, in that progress is only made once a validator hears from \(> 2/3\) of the network. In practice, it would take an extremely strong adversary to indeynitely thwart the weak synchrony assumption (causing the consensus to fail to ever commit a block), and doing so can be made even more difycult by using randomized values of TimeoutPropose on each validator. An additional set of constraints, or Locking Rules, ensure that the network will eventually commit just one block at each height. Any malicious attempt to cause more than one block to be committed at a given height can be identiyed. First, a PreCommit for a block must come with justiycation, in the form of a Polka for that block. If the validator has already PreCommit a block at round R_1, we say they are locked on that block, and the Polka used to justify the new PreCommit at round R_2 must come in a round R_polka where R_1 < R_polka <= R_2. Second, validators must Propose and/or PreVote the block they are locked on. Together, these conditions ensure that a validator does not PreCommit without sufycient evidence as justiycation, and that validators which have already PreCommit cannot contribute to evidence to PreCommit something else. This ensures both safety and liveness of the consensus algorithm. The full details of the protocol are described here. The need to sync all block headers is eliminated in TendermintPoS as the existence of an alternative chain (a fork) means \(\geq 1/3\) of bonded stake can be slashed. Of course, since slashing requires that someone share evidence of a fork, light clients should store any block-hash commits that it sees. Additionally, light clients
could periodically stay synced with changes to the validator set, in order to avoid long range attacks (but other solutions are possible). In spirit similar to Ethereum, Tendermint enables applications to embed a global Merkle root hash in each block, allowing easily veriyable state queries for things like account balances, the value stored in a contract, or the existence of an unspent transaction output, depending on the nature of the application. Assuming a sufyciently resilient collection of broadcast networks and a static validator set, any fork in the blockchain can be detected and the deposits of the offending validators slashed. This innovation, yrst suggested by Vitalik Buterin in early 2014, solves the nothing-at-stake problem of other proof-of-stake cryptocurrencies (see Related Work). However, since validator sets must be able to change, over a long range of time the original validators may all become unbonded, and hence would be free to create a new chain from the genesis block, incurring no cost as they no longer have deposits locked up. This attack came to be known as the Long Range Attack (LRA), in contrast to a Short Range Attack, where validators who are currently bonded cause a fork and are hence punishable (assuming a fork-accountable BFT algorithm like Tendermint consensus). Long Range Attacks are often thought to be a critical blow to proof-of-stake. Fortunately, the LRA can be mitigated as follows. First, for a validator to unbond (thereby recovering their collateral deposit and no longer earning fees to participate in the consensus), the deposit must be made untransferable for an amount of time known as the “unbonding period”, which may be on the order of weeks or months. Second, for a light client to be secure, the yrst time it connects to the network it must verify a recent block-hash against a trusted source, or preferably multiple sources. This
condition is sometimes referred to as “weak subjectivity”. Finally, to remain secure, it must sync up with the latest validator set at least as frequently as the length of the unbonding period. This ensures that the light client knows about changes to the validator set before a validator has its capital unbonded and thus no longer at stake, which would allow it to deceive the client by carrying out a long range attack by creating new blocks beginning back at a height where it was bonded (assuming it has control of sufyciently many of the early private keys). Note that overcoming the LRA in this way requires an overhaul of the original security model of proof-of-work. In PoW, it is assumed that a light client can sync to the current height from the trusted genesis block at any time simply by processing the proofof-work in every block header. To overcome the LRA, however, we require that a light client come online with some regularity to track changes in the validator set, and that the yrst time they come online they must be particularly careful to authenticate what they hear from the network against trusted sources. Of course, this latter requirement is similar to that of Bitcoin, where the protocol and software must also be obtained from a trusted source. The above method for preventing LRA is well suited for validators and full nodes of a Tendermint-powered blockchain because these nodes are meant to remain connected to the network. The method is also suitable for light clients that can be expected to sync with the network frequently. However, for light clients that are not expected to have frequent access to the internet or the blockchain network, yet another solution can be used to overcome the LRA. Non-validator token holders can post their tokens as collateral with a very long unbonding period (e.g. much longer than the unbonding period for validators) and serve light clients with a secondary method of attesting to the validity of current and past block-hashes. While these tokens do not count toward the security of the blockchain’s consensus, they nevertheless can
provide strong guarantees for light clients. If historical block-hash querying were supported in Ethereum, anyone could bond their tokens in a specially designed smart contract and provide attestation services for pay, effectively creating a market for lightclient LRA security. Due to the deynition of a block commit, any \(\geq 1/3\) coalition of voting power can halt the blockchain by going ofzine or not broadcasting their votes. Such a coalition can also censor particular transactions by rejecting blocks that include these transactions, though this would result in a signiycant proportion of block proposals to be rejected, which would slow down the rate of block commits of the blockchain, reducing its utility and value. The malicious coalition might also broadcast votes in a trickle so as to grind blockchain block commits to a near halt, or engage in any combination of these attacks. Finally, it can cause the blockchain to fork, by double-signing or violating the locking rules. If a globally active adversary were also involved, it could partition the network in such a way that it may appear that the wrong subset of validators were responsible for the slowdown. This is not just a limitation of Tendermint, but rather a limitation of all consensus protocols whose network is potentially controlled by an active adversary. For these types of attacks, a subset of the validators should coordinate through external means to sign a reorg-proposal that chooses a fork (and any evidence thereof) and the initial subset of validators with their signatures. Validators who sign such a reorgproposal forego their collateral on all other forks. Clients should verify the signatures on the reorg-proposal, verify any evidence, and make a judgement or prompt the end-user for a decision. For example, a phone wallet app may prompt the user with a security
warning, while a refrigerator may accept any reorg-proposal signed by +½ of the original validators by voting power. No non-synchronous Byzantine fault-tolerant algorithm can come to consensus when \(\geq 1/3\) of voting power are dishonest, yet a fork assumes that \(\geq 1/3\) of voting power have already been dishonest by double-signing or lock-changing without justiycation. So, signing the reorg-proposal is a coordination problem that cannot be solved by any non-synchronous protocol (i.e. automatically, and without making assumptions about the reliability of the underlying network). For now, we leave the problem of reorgproposal coordination to human coordination via social consensus on internet media. Validators must take care to ensure that there are no remaining network partitions prior to signing a reorgproposal, to avoid situations where two conzicting reorgproposals are signed. Assuming that the external coordination medium and protocol is robust, it follows that forks are less of a concern than censorship attacks. In addition to forks and censorship, which require \(\geq 1/3\) Byzantine voting power, a coalition of \(> 2/3\) voting power may commit arbitrary, invalid state. This is characteristic of any (BFT) consensus system. Unlike double-signing, which creates forks with easily veriyable evidence, detecting committment of an invalid state requires non-validating peers to verify whole blocks, which implies that they keep a local copy of the state and execute each transaction, computing the state root independently for themselves. Once detected, the only way to handle such a failure is via social consensus. For instance, in situations where Bitcoin has failed, whether forking due to software bugs (as in March 2013), or committing invalid state due to Byzantine behavior of miners (as in July 2015), the well connected community of businesses, developers, miners, and other organizations established a social consensus as to what manual actions were
required by participants to heal the network. Furthermore, since validators of a Tendermint blockchain may be expected to be identiyable, commitment of an invalid state may even be punishable by law or some external jurisprudence, if desired. ABCI consists of 3 primary message types that get delivered from the core to the application. The application replies with corresponding response messages. The AppendTx message is the work horse of the application. Each transaction in the blockchain is delivered with this message. The application needs to validate each transactions received with the AppendTx message against the current state, application protocol, and the cryptographic credentials of the transaction. A validated transaction then needs to update the application state — by binding a value into a key values store, or by updating the UTXO database. The CheckTx message is similar to AppendTx, but it’s only for validating transactions. Tendermint Core’s mempool yrst checks the validity of a transaction with CheckTx, and only relays valid transactions to its peers. Applications may check an incrementing nonce in the transaction and return an error upon CheckTx if the nonce is old. The Commit message is used to compute a cryptographic commitment to the current application state, to be placed into the next block header. This has some handy properties. Inconsistencies in updating that state will now appear as blockchain forks which catches a whole class of programming errors. This also simpliyes the development of secure lightweight clients, as Merkle-hash proofs can be veriyed by checking against the block-hash, and the block-hash is signed by a quorum of validators (by voting power).
Additional ABCI messages allow the application to keep track of and change the validator set, and for the application to receive the block information, such as the height and the commit votes. ABCI requests/responses are simple Protobuf messages. Check out the schema yle. Arguments: Data ([]byte) : The request transaction bytes Returns: Code (uint32) : Response code Data ([]byte) : Result bytes, if any Log (string) : Debug or error message Usage:
Append and run a transaction. If the transaction is valid, returns CodeType.OK Arguments: Data ([]byte) : The request transaction bytes Returns: Code (uint32) : Response code Data ([]byte) : Result bytes, if any Log (string) : Debug or error message Usage:
Validate a transaction. This message should not mutate the state. Transactions are yrst run through CheckTx before broadcast to peers in the mempool layer. You can make CheckTx semi-stateful and clear the state upon Commit or BeginBlock , to allow for dependent sequences of transactions in the same block.
Returns: Data ([]byte) : The Merkle root hash Log (string) : Debug or error message Usage:
Return a Merkle root hash of the application state. Arguments: Data ([]byte) : The query request bytes Returns: Code (uint32) : Response code Data ([]byte) : The query response bytes Log (string) : Debug or error message Usage:
Flush the response queue. Applications that implement types.Application need not implement this message – it’s handled by the project. Returns: Data ([]byte) : The info bytes Usage:
Return information about the application state. Application speciyc. Arguments: Key (string) : Key to set
Value (string) : Value to set for key Returns: Log (string) : Debug or error message Usage:
Set application options. E.g. Key=“mode”, Value=“mempool” for a mempool connection, or Key=“mode”, Value=“consensus” for a consensus connection. Other options are application speciyc. Arguments: Validators ([]Validator) : Initial genesis-validators Usage:
Called once upon genesis Arguments: Height (uint64) : The block height that is starting Usage:
Signals the beginning of a new block. Called prior to any AppendTxs. Arguments: Height (uint64) : The block height that ended Returns: Validators ([]Validator) : Changed validators with new voting powers (0 to remove) Usage:
Signals the end of a block. Called prior to each Commit after all transactions See the ABCI repository for more details.
There are several reasons why a sender may want the acknowledgement of delivery of a packet by the receiving chain. For example, the sender may not know the status of the destination chain, if it is expected to be faulty. Or, the sender may want to impose a timeout on the packet (with the MaxHeight packet yeld), while any destination chain may suffer from a denialof-service attack with a sudden spike in the number of incoming packets. In these cases, the sender can require delivery acknowledgement by setting the initial packet status to AckPending . Then, it is the receiving chain’s responsibility to conyrm delivery by including an abbreviated IBCPacket in the app Merkle hash. First, an IBCBlockCommit and IBCPacketTx are posted on “Hub” that proves the existence of an IBCPacket on “Zone1”. Say that IBCPacketTx has the following value: FromChainID : “Zone1” FromBlockHeight : 100 (say) Packet : an IBCPacket :
Header : an IBCPacketHeader :
SrcChainID : “Zone1”
DstChainID : “Zone2”
Number : 200 (say)
Status : AckPending
Type : “coin”
MaxHeight : 350 (say “Hub” is currently at height 300)
Payload :
FromBlockHeight : 400 (say)
Packet : an IBCPacket :
Header : an IBCPacketHeader :
SrcChainID : “Zone1”
DstChainID : “Zone2”
Number : 200
Status : AckSent
Type : “coin”
MaxHeight : 350
PayloadHash :
status from “Zone2” by block 350, it would have set the status automatically to Timeout . This evidence of a timeout can get posted back on “Zone1”, and any tokens can be returned. There are two types of Merkle trees supported in the Tendermint/Cosmos ecosystem: The Simple Tree, and the IAVL+ Tree. The Simple Tree is a Merkle tree for a static list of elements. If the number of items is not a power of two, some leaves will be at different levels. Simple Tree tries to keep both sides of the tree the same height, but the left may be one greater. This Merkle tree is used to Merkle-ize the transactions of a block, and the top level elements of the application state root.
The purpose of the IAVL+ data structure is to provide persistent storage for key-value pairs in the application state such that a deterministic Merkle root hash can be computed efyciently. The tree is balanced using a variant of the AVL algorithm, and all operations are \(O(\log n)\). In an AVL tree, the heights of the two child subtrees of any node differ by at most one. Whenever this condition is violated upon an update, the tree is rebalanced by creating \(O(\log n)\) new nodes that point to unmodiyed nodes of the old tree. In the original AVL algorithm, inner nodes can also hold key-value pairs. The AVL+ algorithm (note the plus) modiyes the AVL algorithm to keep all values on leaf nodes, while only using branch-nodes to store keys. This simpliyes the algorithm while keeping the merkle hash trail short. The AVL+ Tree is analogous to Ethereum’s Patricia tries. There are tradeoffs. Keys do not need to be hashed prior to insertion in IAVL+ trees, so this provides faster ordered iteration in the key space which may beneyt some applications. The logic is simpler to implement, requiring only two types of nodes – inner nodes and leaf nodes. The Merkle proof is on average shorter, being a * / \ / \ / \ / \ * * / \ / \ / \ / \ / \ / \ * * * h6 / \ / \ / \ h0 h1 h2 h3 h4 h5 A SimpleTree with 7 elements
balanced binary tree. On the other hand, the Merkle root of an IAVL+ tree depends on the order of updates. We will support additional efycient Merkle trees, such as Ethereum’s Patricia Trie when the binary variant becomes available. In the canonical implementation, transactions are streamed to the Cosmos hub application via the ABCI interface. The Cosmos Hub will accept a number of primary transaction types, including SendTx , BondTx , UnbondTx , ReportHackTx , SlashTx , BurnAtomTx , ProposalCreateTx , and ProposalVoteTx , which are fairly self-explanatory and will be documented in a future revision of this paper. Here we document the two primary transaction types for IBC: IBCBlockCommitTx and IBCPacketTx . An IBCBlockCommitTx transaction is composed of: ChainID (string) : The ID of the blockchain BlockHash ([]byte) : The block-hash bytes, the Merkle root which includes the app-hash BlockPartsHeader (PartSetHeader) : The block part-set header bytes, only needed to verify vote signatures BlockHeight (int) : The height of the commit BlockRound (int) : The round of the commit Commit ([]Vote) : The \(> 2/3\) Tendermint Precommit votes that comprise a block commit ValidatorsHash ([]byte) : A Merkle-tree root hash of the new validator set
ValidatorsHashProof (SimpleProof) : A SimpleTree Merkleproof for proving the ValidatorsHash against the BlockHash AppHash ([]byte) : A IAVLTree Merkle-tree root hash of the application state AppHashProof (SimpleProof) : A SimpleTree Merkle-proof for proving the AppHash against the BlockHash An IBCPacket is composed of: Header (IBCPacketHeader) : The packet header Payload ([]byte) : The bytes of the packet payload. Optional PayloadHash ([]byte) : The hash for the bytes of the packet. Optional Either one of Payload or PayloadHash must be present. The hash of an IBCPacket is a simple Merkle root of the two items, Header and Payload . An IBCPacket without the full payload is called an abbreviated packet. An IBCPacketHeader is composed of: SrcChainID (string) : The source blockchain ID DstChainID (string) : The destination blockchain ID Number (int) : A unique number for all packets Status (enum) : Can be one of AckPending , AckSent , AckReceived , NoAck , or Timeout Type (string) : The types are application-dependent. Cosmos reserves the "coin" packet type MaxHeight (int) : If status is not NoAckWanted or AckReceived by this height, status becomes Timeout . Optional An IBCPacketTx transaction is composed of:
FromChainID (string) : The ID of the blockchain which is
providing this packet; not necessarily the source
FromBlockHeight (int) : The blockchain height in which the
following packet is included (Merkle-ized) in the block-hash of
the source chain
Packet (IBCPacket) : A packet of data, whose status may be one
of AckPending , AckSent , AckReceived , NoAck , or Timeout
PacketProof (IAVLProof) : A IAVLTree Merkle-proof for proving
the packet’s hash against the AppHash of the source chain at
given height
The sequence for sending a packet from “Zone1” to “Zone2”
through the "Hub" is depicted in {Figure X}. First, an IBCPacketTx
proves to "Hub" that the packet is included in the app-state of
“Zone1”. Then, another IBCPacketTx proves to “Zone2” that the
packet is included in the app-state of “Hub”. During this
procedure, the IBCPacket yelds are identical: the SrcChainID is
always “Zone1”, and the DstChainID is always "Zone2".
The PacketProof must have the correct Merkle-proof path, as
follows:
When “Zone1” wants to send a packet to “Zone2” through “Hub”,
the IBCPacket data are identical whether the packet is Merkleized on “Zone1”, the “Hub”, or “Zone2”. The only mutable yeld is
Status for tracking delivery.
We thank our friends and peers for assistance in conceptualizing,
reviewing, and providing support for our work with Tendermint
and Cosmos.
IBC/
Zaki Manian of SkuChain provided much help in formatting and wording, especially under the ABCI section Jehan Tremback of Althea and Dustin Byington for helping with initial iterations Andrew Miller of Honey Badger for feedback on consensus Greg Slepak for feedback on consensus and wording Also thanks to Bill Gleim and Seunghwan Han for various contributions. Your name and organization here for your contribution 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 ZeroCash: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4 TheDAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 Segregated Witness: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 Lightning Network: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 Tendermint: https://github.com/tendermint/tendermint/wiki 9 FLP Impossibility: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 Slasher: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 BitShares: https://bitshares.org/technology/delegatedproof-of-stake-consensus/
13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 Interledger: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15 Sidechains: https://blockstream.com/sidechains.pdf 16 Casper: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum Sharding: https://github.com/ethereum/EIPs/issues/53 19 LibSwift: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalysisOfLibswift.pdf 20 DLS: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 Thin Client Security: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 Mauve Paper: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html
è
Consenso e detalhes técnicos
Um protocolo de consenso bem concebido deve fornecer algumas garantias caso a capacidade de tolerância seja ultrapassada e o consenso falha. Isto é especialmente necessário na economia sistemas, onde o comportamento bizantino pode ter um impacto financeiro substancial recompensa. A garantia mais importante é uma forma de responsabilização, onde os processos que levaram ao consenso falhar (ou seja, fez com que os clientes do protocolo aceitassem valores diferentes - um garfo) pode ser identificado e punido de acordo com as regras do protocolo, ou, possivelmente, o sistema legal. Quando o sistema jurídico é não confiável ou excessivamente caro para invocar, validators podem ser forçados a fazer depósitos de segurança para participar, e aqueles os depósitos podem ser revogados ou cortados quando um comportamento malicioso é detectado [10]. Observe que isso é diferente de Bitcoin, onde a bifurcação é uma ocorrência regular devido à assincronia da rede e à natureza probabilística da localização colisões parciais hash. Como em muitos casos um fork malicioso é indistinguível de uma bifurcação devido à assincronia, Bitcoin não pode implementar de forma confiável a responsabilidade do fork, além da implícita custo de oportunidade pago pelos mineradores para minerar um bloco órfão. Chamamos os estágios de votação de PreVote e PreCommit. Uma votação pode ser a favor um bloco específico ou para Nil. Chamamos uma coleção de >⅔ Pré-Votos para um único bloco na mesma rodada, uma Polca e uma coleção de >⅔ Pré-Commits para um único bloco na mesma rodada de um Commit. Se >⅔ Pré-Commit para Nil na mesma rodada, eles passam para a próxima redondo. Observe que o determinismo estrito no protocolo incorre em uma fraqueza suposição de sincronia, pois líderes defeituosos devem ser detectados e
ignorado. Assim, validators esperam algum tempo, TimeoutPropose, antes de Prevote Nil, e o valor de TimeoutPropose aumenta a cada rodada. Progressão através o resto da rodada é totalmente assíncrona, pois o progresso só é feito assim que um validator recebe notícias de >⅔ da rede. Na prática, seria necessário um adversário extremamente forte para frustrar indefinidamente a suposição de sincronia fraca (fazendo com que o consenso não consiga já cometeu um bloco), e isso pode ser ainda mais difícil usando valores aleatórios de TimeoutPropose em cada validator. Um conjunto adicional de restrições, ou regras de bloqueio, garantem que o a rede eventualmente comprometerá apenas um bloco em cada altura. Qualquer tentativa maliciosa de fazer com que mais de um bloco seja confirmado a uma determinada altura pode ser identificado. Primeiro, um PreCommit para um bloco deve vir com justificativa, em forma de Polca para aquele bloco. Se o validator já tiver pré-comprometido um bloco na rodada R_1, nós dizem que estão trancados naquele quarteirão, e a Polca costumava justificar o novo PreCommit na rodada R_2 deve vir em uma rodada R_polka onde R_1 < R_polka <= R_2. Em segundo lugar, validators devem propor e/ou pré-votar o bloco em que estão bloqueados. Juntos, esses condições garantem que um validator não faça Pré-Commit sem evidências suficientes como justificativa, e que validators que têm já o PreCommit não pode contribuir com evidências para o PreCommit outra coisa. Isso garante a segurança e a vivacidade do algoritmo de consenso. Os detalhes completos do protocolo estão descritos aqui. A necessidade de sincronizar todos os cabeçalhos de bloco é eliminada no TendermintPoS, pois a existência de uma cadeia alternativa (um fork) significa ≥⅓ de a participação vinculada pode ser reduzida. Claro, já que cortar requer que alguém compartilhe evidências de um fork, os clientes leves devem armazenar qualquer block-hash confirma que vê. Além disso, clientes levespoderia ficar periodicamente sincronizado com as alterações no conjunto validator, em para evitar ataques de longo alcance (mas outras soluções são possível). Com espírito semelhante ao Ethereum, o Tendermint permite que os aplicativos incorporar uma raiz Merkle global hash em cada bloco, permitindo facilmente consultas de estado verificáveis para coisas como saldos de contas, o valor armazenado em um contrato, ou a existência de uma transação não gasta saída, dependendo da natureza da aplicação. Assumindo uma coleção de redes de transmissão suficientemente resiliente e um conjunto validator estático, qualquer bifurcação no blockchain pode ser detectado e os depósitos dos validators infratores cortados. Isto inovação, sugerida pela primeira vez por Vitalik Buterin no início de 2014, resolve o problema de nada em jogo de outros proof-of-stake criptomoedas (ver Trabalho Relacionado). No entanto, como validator define deve ser capaz de alterar, durante um longo período de tempo, o original validators podem todos se tornar desvinculados e, portanto, estariam livres para criar uma nova cadeia a partir do bloco gênese, sem incorrer em nenhum custo, pois eles não têm mais depósitos bloqueados. Este ataque veio a ser conhecido como Ataque de Longo Alcance (LRA), em contraste com um Ataque de Curto Alcance Ataque à distância, onde validators que estão atualmente vinculados causam um fork e são, portanto, puníveis (assumindo um fork responsável BFT algoritmo como consenso Tendermint). Ataques de longo alcance são muitas vezes considerado um golpe crítico para proof-of-stake. Felizmente, o LRA pode ser mitigado da seguinte forma. Primeiro, por um validator para desvincular (recuperando assim seu depósito de garantia e não ganhando mais taxas para participar do consenso), o o depósito deve ser intransferível por um período de tempo conhecido como “período de desvinculação”, que pode ser da ordem de semanas ou meses. Segundo, para que um cliente leve esteja seguro, o primeiro vez que se conecta à rede, ele deve verificar um bloco recente-hash contra uma fonte confiável ou, de preferência, múltiplas fontes. Isto
Essa condição é às vezes chamada de “subjetividade fraca”. Finalmente, para permanecer seguro, ele deve sincronizar com o validator mais recente definido em menos tão frequentemente quanto a duração do período de desvinculação. Isto garante que o cliente light saiba sobre as alterações no validator definido antes de um validator ter seu capital não garantido e, portanto, não mais em jogo, o que lhe permitiria enganar o cliente realizando um ataque de longo alcance criando novos blocos começando em um altura onde foi colado (assumindo que tenha controle de muitas das primeiras chaves privadas). Note-se que superar o LRA desta forma requer uma revisão o modelo de segurança original de proof-of-work. No PoW, é assumiu que um cliente leve pode sincronizar com a altura atual do bloco genesis confiável a qualquer momento, simplesmente processando a prova de trabalho em cada cabeçalho do bloco. Para superar o LRA, no entanto, exigem que um cliente light fique online com alguma regularidade para rastrear alterações no conjunto validator e que na primeira vez elas ficam on-line, eles devem ter cuidado especial para autenticar o que ouvem da rede em relação a fontes confiáveis. De claro, este último requisito é semelhante ao de Bitcoin, onde o protocolo e o software também devem ser obtidos de um confiável fonte. O método acima para prevenir LRA é adequado para validators e nós completos de um blockchain alimentado por Tendermint porque estes os nós devem permanecer conectados à rede. O método também é adequado para clientes leves que podem esperar sincronizar com a rede frequentemente. No entanto, para clientes leves que não se espera que tenham acesso frequente à Internet ou ao blockchain rede, ainda outra solução pode ser usada para superar o LRA. Titulares que não sejam validator token podem postar seus tokens como garantia com um período de desvinculação muito longo (por exemplo, muito mais longo do que o período de desvinculação para validators) e atender clientes light com um método secundário de atestar a validade dos dados atuais e bloco passado-hashes. Embora esses tokens não contem para o segurança do consenso de blockchain, eles podem, no entanto,fornecer fortes garantias para clientes leves. Se bloco histórico-hash consultas eram suportadas em Ethereum, qualquer um poderia vincular seus tokens em um smart contract especialmente projetado e fornece serviços de atestado pagos, criando efetivamente um mercado para segurança LRA lightclient. Devido à definição de um bloco commit, qualquer coalizão ≥⅓ de o poder de voto pode interromper o blockchain ficando offzine ou não transmitindo seus votos. Tal coligação também pode censurar transações específicas, rejeitando blocos que incluem esses transações, embora isso resultasse em uma proporção significativa de propostas de bloco a serem rejeitadas, o que desaceleraria o ritmo de commits de bloco do blockchain, reduzindo sua utilidade e valor. A coalizão maliciosa também pode transmitir votos aos poucos, para que quanto a moer o bloco blockchain quase paralisar ou se envolver em qualquer combinação desses ataques. Finalmente, pode causar blockchain para bifurcar, assinando duas vezes ou violando o bloqueio regras. Se um adversário globalmente activo também estivesse envolvido, poderia particionar a rede de tal forma que pode parecer que o errado subconjunto de validators foram responsáveis pela desaceleração. Isto não é apenas uma limitação do Tendermint, mas sim uma limitação de todos protocolos de consenso cuja rede é potencialmente controlada por um adversário ativo. Para esses tipos de ataques, um subconjunto de validators deve coordenar através de meios externos para assinar uma proposta de reorganização que escolhe uma bifurcação (e qualquer evidência dela) e o subconjunto inicial de validators com suas assinaturas. Os validadores que assinam tal proposta de reorganização renunciam à sua garantia em todos os outros forks. Os clientes devem verificar as assinaturas na proposta de reorganização, verificar qualquer evidência, e fazer um julgamento ou solicitar uma decisão ao usuário final. Para Por exemplo, um aplicativo de carteira telefônica pode solicitar ao usuário uma mensagem de segurança
aviso, embora uma geladeira possa aceitar qualquer proposta de reorganização assinado por +½ dos validators originais com poder de voto. Nenhum algoritmo bizantino tolerante a falhas não síncrono pode surgir ao consenso quando ≥⅓ do poder de voto são desonestos, mas uma bifurcação assume que ≥⅓ do poder de voto já foi desonesto por assinatura dupla ou alteração de bloqueio sem justificativa. Então, assinando a proposta de reorganização é um problema de coordenação que não pode ser resolvido por qualquer protocolo não síncrono (isto é, automaticamente, e sem fazer suposições sobre a confiabilidade do rede subjacente). Por enquanto, deixamos o problema da coordenação de propostas de reorganização para a coordenação humana via consenso social na mídia da internet. Os validadores devem ter cuidado para garantir que haja não há partições de rede restantes antes de assinar uma proposta de reorganização, para evitar situações em que duas propostas de reorganização conflitantes sejam assinadas. Supondo que o meio e o protocolo de coordenação externa sejam robusto, segue-se que os forks são menos preocupantes do que a censura ataques. Além de bifurcações e censura, que exigem ≥⅓ Bizantina poder de voto, uma coalizão com >⅔ poder de voto pode comprometer estado arbitrário e inválido. Isso é característico de qualquer (BFT) sistema de consenso. Ao contrário da assinatura dupla, que cria bifurcações com evidências facilmente verificáveis, detectando o comprometimento de um estado inválido requer pares não validados para verificar blocos inteiros, o que implica que eles mantenham uma cópia local do estado e executem cada transação, calculando a raiz do estado de forma independente para eles mesmos. Uma vez detectada, a única maneira de lidar com tal falha é através do consenso social. Por exemplo, em situações onde Bitcoin falhou, seja bifurcação devido a bugs de software (como em março 2013), ou cometendo estado inválido devido ao comportamento bizantino de mineiros (como em julho de 2015), a comunidade bem conectada de empresas, desenvolvedores, mineradores e outras organizações estabeleceu um consenso social sobre quais ações manuais eramexigido pelos participantes para curar a rede. Além disso, desde Pode-se esperar que validators de um Tendermint blockchain sejam identificável, o comprometimento de um estado inválido pode até ser punível por lei ou alguma jurisprudência externa, se desejado. ABCI consiste em 3 tipos de mensagens principais que são entregues de o núcleo da aplicação. O aplicativo responde com mensagens de resposta correspondentes. A mensagem AppendTx é o carro-chefe do aplicativo. Cada a transação em blockchain é entregue com esta mensagem. O aplicativo precisa validar cada transação recebida com o Mensagem AppendTx em relação ao estado atual, protocolo de aplicação, e as credenciais criptográficas da transação. Um validado transação então precisa atualizar o estado do aplicativo - por vinculando um valor a um armazenamento de valores-chave ou atualizando o UTXO banco de dados. A mensagem CheckTx é semelhante a AppendTx, mas é apenas para validando transações. Primeiras verificações do mempool do Tendermint Core a validade de uma transação com CheckTx, e apenas retransmite válido transações para seus pares. Os aplicativos podem verificar um incremento nonce na transação e retornará um erro no CheckTx se o nonce é antigo. A mensagem Commit é usada para calcular uma criptografia compromisso com o estado atual da aplicação, para ser colocado no cabeçalho do próximo bloco. Isso tem algumas propriedades úteis. Inconsistências na atualização desse estado agora aparecerão como blockchain bifurcações que capturam toda uma classe de programação erros. Isso também simplifica o desenvolvimento de soluções leves e seguras clientes, como as provas Merkle-hash podem ser verificadas verificando-se o bloco-hash, e o bloco-hash é assinado por um quórum de validators (por poder de voto).
Mensagens ABCI adicionais permitem que o aplicativo acompanhe e alterar o conjunto validator, e para que a aplicação receba o bloquear informações, como a altura e os votos de confirmação. ABCI solicitações/respostas são mensagens simples do Protobuf. Verifique o esquema yle. Argumentos: Dados ([]byte): os bytes da transação da solicitação Retorna: Código (uint32): código de resposta Dados ([]byte): bytes de resultado, se houver Log (string): mensagem de depuração ou erro Uso:
Anexe e execute uma transação. Se a transação for válida, retorna CodeType.OK Argumentos: Dados ([]byte): os bytes da transação da solicitação Retorna: Código (uint32): código de resposta Dados ([]byte): bytes de resultado, se houver Log (string): mensagem de depuração ou erro Uso:
Valide uma transação. Esta mensagem não deve alterar o estado. As transações são executadas primeiro através do CheckTx antes transmitir para pares na camada mempool. Você pode fazer CheckTx semi-stateful e limpe o estado após Commit ou BeginBlock , para permitir sequências dependentes de transações no mesmo bloco.
Retorna: Dados ([]byte): raiz Merkle hash Log (string): mensagem de depuração ou erro Uso:
Retorne uma raiz Merkle hash do estado do aplicativo. Argumentos: Dados ([]byte): os bytes da solicitação de consulta Retorna: Código (uint32): código de resposta Dados ([]byte): os bytes de resposta da consulta Log (string): mensagem de depuração ou erro Uso:
Limpe a fila de respostas. Aplicativos que implementam types.Application não precisa implementar esta mensagem – é manipulados pelo projeto. Retorna: Dados ([]byte): os bytes de informação Uso:
Retorne informações sobre o estado do aplicativo. Aplicação específico. Argumentos: Chave (string): chave a ser definida
Valor (string): valor a ser definido para a chave Retorna: Log (string): mensagem de depuração ou erro Uso:
Defina as opções do aplicativo. Por exemplo Chave=“modo”, Valor=“mempool” para uma conexão mempool, ou Key=“mode”, Value=“consensus” para uma conexão de consenso. Outras opções são específicas do aplicativo. Argumentos: Validadores ([]Validador): gênese inicial-validators Uso:
Chamado uma vez no Gênesis Argumentos: Altura (uint64): a altura do bloco que está começando Uso:
Sinaliza o início de um novo bloco. Chamado antes de qualquer ApêndiceTxs. Argumentos: Altura (uint64): a altura do bloco que terminou Retorna: Validadores ([]Validador): validators alterados com novos poderes de voto (0 para remover) Uso:
Sinaliza o fim de um bloco. Afinal, chamado antes de cada Commit transações Consulte o repositório ABCI para obter mais detalhes.Existem vários motivos pelos quais um remetente pode querer que o confirmação da entrega de um pacote pela cadeia receptora. Por exemplo, o remetente pode não saber o status do cadeia de destino, se for esperado que esteja com defeito. Ou o remetente pode deseja impor um tempo limite ao pacote (com o parâmetro MaxHeight rendimento de pacotes), enquanto qualquer cadeia de destino pode sofrer um ataque de negação de serviço com um aumento repentino no número de mensagens recebidas. pacotes. Nestes casos, o remetente pode exigir confirmação de entrega definindo o status inicial do pacote como AckPending . Então, é o responsabilidade da cadeia de recebimento de confirmar a entrega, incluindo um abreviado como IBCPacket no aplicativo Merkle hash. Primeiro, um IBCBlockCommit e um IBCPacketTx são postados no “Hub” isso comprova a existência de um IBCPacket na “Zona1”. Diga isso IBCPacketTx tem o seguinte valor: FromChainID: “Zona1” FromBlockHeight: 100 (digamos) Pacote: um IBCPacket:
Cabeçalho: um IBCPacketHeader:
SrcChainID: “Zona1”
DstChainID: “Zona2”
Número: 200 (digamos)
Status: ConfirmadoPendente
Tipo: “moeda”
MaxHeight: 350 (digamos que “Hub” está atualmente na altura 300)
Carga útil:
FromBlockHeight: 400 (digamos)
Pacote: um IBCPacket:
Cabeçalho: um IBCPacketHeader:
SrcChainID: “Zona1”
DstChainID: “Zona2”
Número: 200
Status: AckSent
Tipo: “moeda”
Altura máxima: 350
PayloadHash:
status de “Zona2” pelo bloco 350, teria definido o status automaticamente para Tempo limite . Esta evidência de um tempo limite pode ser postado de volta em “Zone1”, e qualquer tokens pode ser retornado. Existem dois tipos de Merkle trees suportados no Ecossistema Tendermint/Cosmos: A Árvore Simples e o IAVL+ Árvore. A Árvore Simples é um Merkle tree para uma lista estática de elementos. Se o número de itens não é uma potência de dois, algumas folhas estarão em níveis diferentes. Simple Tree tenta manter ambos os lados da árvore mesma altura, mas a esquerda pode ser uma maior. Este Merkle tree é usado para Merkle-ize as transações de um bloco, e o nível superior elementos da raiz do estado do aplicativo.O objetivo da estrutura de dados IAVL+ é fornecer dados persistentes armazenamento para pares de valores-chave no estado do aplicativo, de modo que um A raiz determinística de Merkle hash pode ser calculada de forma eficiente. O árvore é balanceada usando uma variante do algoritmo AVL, e todos as operações são O (log (n)). Em uma árvore AVL, as alturas das duas subárvores filhas de qualquer nó diferem em no máximo um. Sempre que esta condição for violada por um atualização, a árvore é reequilibrada criando O(log(n)) novos nós que apontam para nós não modificados da árvore antiga. No AVL original algoritmo, os nós internos também podem conter pares de valores-chave. O AVL+ algoritmo (observe o sinal de mais) modifica o algoritmo AVL para manter todos valores em nós folha, enquanto usa apenas nós de ramificação para armazenar chaves. Isso simplifica o algoritmo enquanto mantém a trilha merkle hash curto. A árvore AVL + é análoga às tentativas de Patricia de Ethereum. Existem compensações. As chaves não precisam ser hashed antes da inserção em Árvores IAVL+, portanto, isso fornece iteração ordenada mais rápida na chave espaço que pode beneficiar algumas aplicações. A lógica é mais simples de implementar, exigindo apenas dois tipos de nós – nós internos e nós de folha. A prova de Merkle é em média mais curta, sendo uma * / \ / \ / \ / \ * * / \ / \ / \ / \ / \ / \ * * * h6 / \ / \ / \ h0 h1 h2 h3 h4 h5 Uma SimpleTree com 7 elementos
árvore binária balanceada. Por outro lado, a raiz Merkle de um A árvore IAVL+ depende da ordem das atualizações. Apoiaremos Merkle trees eficientes adicionais, como Patricia Trie de Ethereum quando a variante binária se torna disponível. Na implementação canônica, as transações são transmitidas para o Aplicativo hub Cosmos por meio da interface ABCI. O hub Cosmos aceitará uma série de transações primárias tipos, incluindo SendTx , BondTx , UnbondTx , ReportHackTx , SlashTx , BurnAtomTx , ProposalCreateTx e ProposalVoteTx , que são bastante autoexplicativos e serão documentados em um revisão futura deste artigo. Aqui documentamos os dois principais tipos de transação para IBC: IBCBlockCommitTx e IBCPacketTx . Uma transação IBCBlockCommitTx é composta por: ChainID (string): o ID de blockchain BlockHash ([]byte): O bloco-hash bytes, a raiz Merkle que inclui o aplicativo-hash BlockPartsHeader (PartSetHeader): o cabeçalho do conjunto parcial do bloco bytes, necessários apenas para verificar assinaturas de votos BlockHeight (int): a altura do commit BlockRound (int): a rodada do commit Commit ([]Vote): O >⅔ Tendermint Precommit vota que compreende um commit de bloco ValidatorsHash ([]byte): uma raiz Merkle-tree hash do novo validator conjunto
ValidatorsHashProof (SimpleProof): um SimpleTree Merkleproof para provar o ValidatorsHash em relação ao BlockHash
AppHash ([]byte): uma raiz da árvore IAVLTree Merkle hash do
estado do aplicativo
AppHashProof (SimpleProof): uma prova SimpleTree Merkle para
provando o AppHash contra o BlockHash
Um IBCPacket é composto por:
Cabeçalho (IBCPacketHeader): o cabeçalho do pacote
Carga útil ([]byte): os bytes da carga útil do pacote. Opcional
PayloadHash ([]byte) : o hash para os bytes do pacote.
Opcional
Um dos Payload ou PayloadHash deve estar presente. O hash
de um IBCPacket é uma raiz simples de Merkle dos dois itens, Header
e Carga útil . Um IBCPacket sem a carga completa é chamado de
pacote abreviado.
Um IBCPacketHeader é composto por:
SrcChainID (string): o ID blockchain de origem
DstChainID (string): o ID de destino blockchain
Número (int): um número exclusivo para todos os pacotes
Status (enum): pode ser AckPending , AckSent ,
AckReceived , NoAck ou Tempo limite
Tipo (string): os tipos dependem do aplicativo. Cosmos
reserva o tipo de pacote "moeda"
MaxHeight (int): se o status não for NoAckWanted ou AckReceived
nesta altura, o status se torna Timeout . Opcional
Uma transação IBCPacketTx é composta por:FromChainID (string): o ID do blockchain que é
fornecendo este pacote; não necessariamente a fonte
FromBlockHeight (int): a altura blockchain em que o
O seguinte pacote está incluído (Merkle-izado) no bloco-hash de
a cadeia de origem
Pacote (IBCPacket): um pacote de dados, cujo status pode ser um
de AckPending , AckSent , AckReceived , NoAck ou Timeout
PacketProof (IAVLProof): uma prova IAVLTree Merkle para prova
o hash do pacote em relação ao AppHash da cadeia de origem em
dada altura
A sequência para enviar um pacote de “Zona1” para “Zona2”
através do "Hub" está representado na {Figura X}. Primeiro, um IBCPacketTx
prova ao "Hub" que o pacote está incluído no estado do aplicativo de
“Zona1”. Então, outro IBCPacketTx prova para “Zona2” que o
o pacote está incluído no estado do aplicativo “Hub”. Durante este
procedimento, os rendimentos IBCPacket são idênticos: o SrcChainID é
sempre “Zone1” e o DstChainID é sempre "Zone2".
O PacketProof deve ter o caminho à prova de Merkle correto, conforme
segue:
Quando “Zone1” deseja enviar um pacote para “Zone2” através de “Hub”,
os dados de IBCPacket são idênticos, quer o pacote seja Merkleizado na “Zona1”, no “Hub” ou na “Zona2”. O único rendimento mutável é
Status para rastreamento de entrega.
Agradecemos aos nossos amigos e colegas pela ajuda na conceituação,
revisando e fornecendo suporte para nosso trabalho com Tendermint
e Cosmos.
IBC/
Zaki Manian do SkuChain forneceu muita ajuda na formatação e redação, especialmente na seção ABCI Jehan Tremback da Althea e Dustin Byington por ajudar com iterações iniciais Andrew Miller da Honey Badger pelo feedback sobre o consenso Greg Slepak pelo feedback sobre consenso e redação Também obrigado a Bill Gleim e Seunghwan Han por vários contribuições. Seu nome e organização aqui pela sua contribuição 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2ZeroCash: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4 ODAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 Testemunha Segregada: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 Rede Lightning: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8Tendermint: https://github.com/tendermint/tendermint/wiki 9 Impossibilidade de FLP: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10Cortador: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf Compartilhamentos de 12 bits: https://bitshares.org/technology/delegatedproof-of-stake-consensus/
13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 Registro intermediário: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15 Cadeias laterais: https://blockstream.com/sidechains.pdf 16 Cáspero: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum Fragmentação: https://github.com/ethereum/EIPs/issues/53 19LibSwift: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalysisOfLibswift.pdf 20 DLS: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 Segurança de Thin Client: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum Papel Malva 2.0: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html
³ é