Cosmos: Dağıtılmış Defterlerden Oluşan Bir Ağ
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.
giriiş
Açık kaynak ekosisteminin birleşik başarısı, merkezi olmayan yle paylaşımı ve halka açık kripto para birimleri merkezi olmayan internet protokollerinin olduğu anlayışına ilham verdi Sosyo-ekonomik altyapının radikal bir şekilde iyileştirilmesi için kullanılabilir. Bitcoin [1] gibi özel blockchain uygulamalar gördük (a kripto para birimi), Zerocash [2] (gizlilik için bir kripto para birimi) ve Ethereum [3] gibi genelleştirilmiş smart contract platformları, Etherium Virtual için sayısız dağıtılmış uygulama Augur (tahmin piyasası) ve TheDAO gibi makine (EVM) [4] (bir yatırım kulübü). Ancak bugüne kadar bu blockchain'lar çok sayıda sorunla karşı karşıya kaldı Brüt enerji verimsizliği, zayıf veya sınırlı performans ve olgunlaşmamış yönetişim mekanizmaları. Bitcoin adlı kişinin işlem hacmini ölçeklendirmeye yönelik teklifler, örneğin Ayrılmış Tanık [5] ve BitcoinNG [6], dikey ölçeklendirmedir tek bir fiziksel kapasiteyle sınırlı kalan çözümler Tam denetlenebilirlik özelliğini sağlamak için makine. Lightning Network [7], Bitcoin işleminin ölçeklendirilmesine yardımcı olabilir
bazı işlemleri defterin tamamen dışında bırakarak hacim, ve mikro ödemeler ve gizliliğin korunması için çok uygundur ödeme rayları, ancak daha genelleştirilmiş ödeme rayları için uygun olmayabilir ölçeklendirme ihtiyaçları. İdeal bir çözüm, birden fazla paralel blockchain'nin birbirine bağlanmasına izin veren çözümdür. güvenlik özelliklerini korurken birlikte çalışabilirler. Bu var proof-of-work ile imkansız olmasa da zor olduğu kanıtlanmıştır. Birleştirilmiş örneğin madencilik, bir ebeveynin güvenliğini sağlamak için yapılan işin yapılmasına olanak tanır zincirin bir alt zincirde yeniden kullanılması gerekir, ancak işlemlerin yine de olması gerekir sırasıyla her düğüm tarafından doğrulanır ve birleştirme madenciliği yapılır blockchain hashing gücünün çoğunluğunun üzerinde olması durumunda saldırıya karşı savunmasızdır ebeveyn çocuğu aktif olarak birleştirme madenciliği yapmıyor. Akademik bir inceleme alternatif blockchain ağ mimarilerinin sayısı sağlanmıştır ek bağlam ve diğer tekliflerin özetlerini sunuyoruz ve İlgili Çalışmalardaki dezavantajları. Burada yeni bir blockchain ağ mimarisi olan Cosmos'yi sunuyoruz bu, tüm bu sorunları giderir. Cosmos birçok kişiden oluşan bir ağdır bağımsız blockchain'ler, bölgeler olarak adlandırılır. Bölgeler tarafından desteklenmektedir Yüksek performans sağlayan Tendermint Core [8], tutarlı, güvenli PBFT benzeri konsensüs motoru; burada kötü niyetli davranışların kontrol altında tutulması için katı bir hesap verebilirlik garanti edilir aktörler. Tendermint Core'un BFT fikir birliği algoritması çok uygundur genel proof-of-stake blockchains'yi ölçeklendirmek için. Cosmos üzerindeki ilk bölgeye Cosmos Hub adı verilir. Cosmos Hub, basit bir yapıya sahip çok varlıklı bir proof-of-stake kripto para birimidir. Ağın uyum sağlamasını ve uyum sağlamasını sağlayan yönetişim mekanizması yükseltme. Ayrıca Cosmos Hub şu kadar genişletilebilir: diğer bölgeleri birbirine bağlamak. Cosmos ağının hub'ları ve bölgeleri aşağıdakilerle iletişim kurar: blockchain arası iletişim (IBC) protokolü aracılığıyla birbirlerine, blockchains için bir tür sanal UDP veya TCP. Jetonlar olabilir bir bölgeden diğerine güvenli ve hızlı bir şekilde aktarılırbölgeler arasında döviz likiditesine ihtiyaç duymadan. Bunun yerine, tüm bölgeler arası token aktarımlar Cosmos Hub'dan geçer; her bölgenin tuttuğu toplam tokens miktarını takip eder. hub, her bölgeyi diğer bölgelerin arızasından izole eder. Çünkü herkes Cosmos Hub'a yeni bir bölge bağlayabilir, bölgeler buna izin verir yeni blockchain yeniliklerle geleceğe yönelik uyumluluk için. Bu bölümde Tendermint konsensüs protokolünü açıklıyoruz ve onunla uygulamalar oluşturmak için kullanılan arayüz. Daha fazlası için ayrıntılar için eke bakın. Klasik Bizans hataya dayanıklı (BFT) algoritmalarında her düğüm aynı ağırlığa sahiptir. Tendermint'te düğümlerin negatif olmayan bir değeri vardır. oylama gücü miktarı ve olumlu oy kullanan düğümler güçlere validators denir. Doğrulayıcılar katılıyor kriptografik imzalar yayınlayarak fikir birliği protokolü veya bir sonraki blok üzerinde anlaşmaya varmak için oy kullandı. Doğrulayıcıların oy verme yetkileri başlangıçta belirlenir veya bağlı olarak blockchain tarafından deterministik olarak değiştirildi uygulama. Örneğin, aşağıdaki gibi bir proof-of-stake uygulamasında Cosmos Merkezde, oylama gücü şu şekilde belirlenebilir: staking tokens miktarı teminat olarak teminat altına alındı. NOT: ⅔ ve ⅓ gibi kesirler toplam oyların kesirlerini ifade eder güç, tüm validator'ler olmadıkça asla validator'lerin toplam sayısı eşit ağırlığa sahip. >⅔ “⅔'den fazla”, ≥⅓ “en az” anlamına gelir ⅓”. Tendermint kısmen senkronize bir BFT konsensüs protokolüdür DLS konsensüs algoritmasından türetilmiştir [20]. Nane:
basitliği, performansı ve çatal sorumluluğuyla dikkat çekiyor. Protokol, yxed bilinen bir validator kümesi gerektirir; burada her biri validator ortak anahtarıyla tanımlanır. Doğrulayıcılar şunları yapmaya çalışır: Bir bloğun bir liste olduğu her seferinde bir blok üzerinde fikir birliğine varmak işlemler. Blok üzerinde fikir birliği için oylama sürüyor mermi. Her turun bir tur lideri veya teklif sahibi vardır. bir blok öneriyor. validator'ler daha sonra aşamalı olarak oy verirler. Önerilen bloğu kabul etmek veya bir sonraki tura geçmek için. Bir tur için öneride bulunan kişi, sıralananlar arasından deterministik olarak seçilir. oylama güçleriyle orantılı olarak validator'lerin listesi. Protokolün tüm ayrıntıları burada açıklanmaktadır. Tendermint'in güvenliği optimal Bizans kullanımından kaynaklanmaktadır. Süper çoğunluk (>⅔) oylama ve kilitleme yoluyla hata toleransı mekanizma. Birlikte şunları sağlarlar: ≥⅓ ihlale neden olabilmesi için oylama gücünün Bizans olması gerekir ikiden fazla değerin taahhüt edildiği güvenlik. herhangi bir validator kümesi güvenliği ihlal etmeyi başarırsa veya hatta bunu yapmaya kalkışırlarsa protokol tarafından tanımlanabilirler. Bu hem blokların birleştirilmesi hem de yayın için oylamayı içerir haksız oylar Güçlü garantilerine rağmen Tendermint olağanüstü çözümler sunuyor performans. 7'ye dağıtılmış 64 düğümden oluşan kıyaslamalarda 5 kıtadaki veri merkezleri, emtia bulutu örnekleri, Tendermint konsensüs başına binlerce işlemi işleyebilir ikincisi, bir ila iki saniyelik taahhüt gecikmeleriyle. Özellikle, başına binin üzerinde işlem performansı ikincisi zorlu düşmanlık koşullarında bile korunur; validators çöküyor veya kötü niyetle hazırlanmış oylar yayınlıyor. Bkz. ayrıntılar için aşağıdaki resme bakın.
Tendermint'in fikir birliği algoritmasının önemli bir avantajı basitleştirilmiştir hafif istemci güvenliği, onu mobil ve mobil cihazlar için ideal bir aday haline getiriyor Nesnelerin interneti kullanım örnekleri. Bitcoin hafif istemcinin senkronize edilmesi gerekirken blok başlık zincirleri ve en fazla kanıta sahip olanı bulun Tendermint hafif istemcilerinin yalnızca değişikliklere ayak uydurması gerekir validator kümesine gidin ve ardından >⅔ Ön Taahhütleri doğrulayın. En son durumu belirlemek için en son blok. Kısa ve öz hafif istemci provaları aynı zamanda inter-blockchain'yi de etkinleştirir iletişim. Tendermint'in belirli durumları önlemek için koruyucu önlemleri vardır. Uzun menzilli, tehlikede olmayan çifte harcamalar gibi dikkate değer saldırılar ve sansür. Bunlar ekte daha ayrıntılı olarak tartışılmaktadır.Tendermint fikir birliği algoritması, Tendermint Core adlı program. Tendermint Core bir herhangi bir şeyi dönüştürebilen, uygulamadan bağımsız “fikir birliği motoru” deterministik kara kutu uygulamasını dağıtılmış olarak çoğaltılmış bir uygulamaya dönüştürün blockchain. Tendermint Core blockchain uygulamaya bağlanır Uygulama Blok Zinciri Arayüzü aracılığıyla (ABCI) [17]. Böylece, ABCI blockchain uygulamaların herhangi bir biçimde programlanmasına olanak tanır dil, yalnızca fikir birliğine varılan programlama dili değil motora yazılmıştır. Ek olarak ABCI bunu kolayca mümkün kılar mevcut herhangi bir blockchain yığınının fikir birliği katmanını değiştirin. Tanınmış kripto para birimi Bitcoin ile bir benzetme yapıyoruz. Bitcoin her düğümün koruduğu bir blockchain kripto para birimidir tamamen denetlenmiş Harcanmamış İşlem Çıkışı (UTXO) veritabanı. Eğer ABCI üzerine Bitcoin benzeri bir sistem oluşturmak isteniyordu, Tendermint Core şunlardan sorumlu olacak: Düğümler arasında blokları ve işlemleri paylaşma Kanonik/değişmez bir işlem sırası oluşturmak ( blockchain) Bu arada, ABCI uygulaması şunlardan sorumlu olacaktır: UTXO veritabanının bakımı İşlemlerin kriptografik imzalarını doğrulama İşlemlerin var olmayan fonları harcamasını önleme İstemcilerin UTXO veritabanını sorgulamasına izin veriliyor Tendermint, blockchain tasarımını şu şekilde ayrıştırabilir: başvuru süreci arasında çok basit bir API sunuyor ve fikir birliği süreci.
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 Mimarlık
Cosmos bağımsız paralel blockchain'lerden oluşan bir ağdır ve bunlar her biri klasik BFT fikir birliği algoritmaları tarafından desteklenmektedir: İhale 1. Bu ağdaki ilk blockchain, Cosmos Hub olacaktır. Cosmos Hub, diğer birçok blockchains'ye (veya bölgeye) bir ağ aracılığıyla bağlanır. yeni inter-blockchain iletişim protokolü. Cosmos Merkezi çok sayıda token türünü izler ve toplamın kaydını tutar bağlı her bölgedeki tokens sayısı. Jetonlar olabilir bir bölgeden diğerine güvenli ve hızlı bir şekilde aktarılır bölgeler arasında sıvı değişimine gerek kalmadan, çünkü hepsi bölgeler arası para transferleri Cosmos Hub üzerinden yapılır. Bu mimari, blockchain alanının karşılaştığı birçok sorunu çözmektedir. Uygulamaların birlikte çalışabilirliği, ölçeklenebilirliği ve kesintisiz yükseltilebilirlik. Örneğin, Bitcoind'den türetilen bölgeler, Go-Ethereum, CryptoNote, ZCash veya herhangi bir blockchain sistemi şunları yapabilir: Cosmos Hub'a takılmalıdır. Bu bölgeler Cosmos'nin şunları yapmasına izin verir: Küresel işlem talebini karşılamak için sonsuz ölçeklenebilirlik. Bölgeler aynı zamanda olarak desteklenecek olan dağıtılmış bir değişim için harika bir yt peki. Cosmos yalnızca tek bir dağıtılmış defter değildir ve Cosmos Hub duvarlarla çevrili bir bahçe ya da evrenin merkezi değil. Biz dağıtılmış defterlerden oluşan açık bir ağ için bir protokol tasarlamak gelecekteki finansal sistemler için yeni bir temel görevi görebilecek, Kriptografi ilkelerine, sağlam ekonomiye, fikir birliğine dayalı teori, şeffaflık ve hesap verebilirlik. Cosmos Hub, Cosmos bölgesindeki ilk genel blockchain merkezidir. Ağ, Tendermint'in BFT fikir birliği algoritması tarafından desteklenmektedir. Tendermint açık kaynak projesi 2014 yılında bu sorunu çözmek için doğdu. Bitcoin'nin çalışma kanıtı fikir birliği algoritmasının hızı, ölçeklenebilirliği ve çevresel sorunları. Kanıtlanmış olanı kullanarak ve geliştirerek
BFT MIT'de 1988'de geliştirilen algoritmalar [20], Tendermint ekip kavramsal olarak proof-of-stake'yi sergileyen ilk ekip oldu tehlikede olmayan hiçbir şey sorununu çözen kripto para birimi ilk nesil proof-of-stake kripto para birimlerinin sıkıntısını çekti NXT ve BitShares1.0 olarak. Bugün neredeyse tüm Bitcoin mobil cüzdanlar güvenilir sunucuları kullanıyor. onlara işlem doğrulaması sağlayın. Bunun nedeni, iş kanıtının bir onaydan önce birçok onayın beklenmesini gerektirmesidir. işlemin geri dönülemez şekilde taahhüt edildiği kabul edilebilir. Doublespend saldırıları halihazırda aşağıdaki gibi hizmetlerde gösterilmiştir: CoinBase. Diğer blockchain fikir birliği sistemlerinden farklı olarak Tendermint şunları sunar: anında ve kanıtlanabilir şekilde güvenli mobil müşteri ödeme doğrulaması. Tendermint hiçbir zaman çatallanmayacak şekilde tasarlandığından, mobil cüzdanlar anında işlem onayı alabilir, bu da Güvenilir ve pratik ödemeler akıllı telefonlarda gerçek oluyor. Bu Nesnelerin İnterneti uygulamaları için önemli sonuçlar doğurmaktadır. peki. Cosmos içindeki doğrulayıcılar, Bitcoin madencilerine benzer bir role sahiptir, ancak bunun yerine oy vermek için kriptografik imzaları kullanın. Doğrulayıcılar taahhüt etmekten sorumlu güvenli, özel makineler bloklar. validator olmayanlar staking token'leri devredebilir (çağrılır) Blok ücretlerinin ve atomun bir kısmını kazanmak için herhangi bir validator'ye "atomlar") ödüller, ancak cezalandırılma (kesilme) riskiyle karşı karşıya kalırlar; validator numaralı delege saldırıya uğradı veya protokolü ihlal etti. Kanıtlanmış Tendermint BFT konsensusunun güvenlik garantileri ve teminatlar paydaşların depozitosu–validators ve delegeler–sağlar Düğümler ve hafif istemciler için kanıtlanabilir, ölçülebilir güvenlik. Dağıtılmış kamu defterlerinin bir anayasası ve yönetim sistemi. Bitcoin, Bitcoin Vakfına güveniyor veyükseltmeleri koordine etmek için madencilik yapın, ancak bu yavaş bir süreçtir. Ethereum, adrese zorlanmanın ardından ETH ve ETC'ye bölündü DAO hacklenmesinin nedeni büyük ölçüde önceden bir toplumsal sözleşmenin olmamasıydı ne de bu tür kararları almaya yönelik mekanizma. Cosmos Merkezindeki doğrulayıcılar ve yetki verenler oy verebilir sistemin önceden ayarlanmış parametrelerini değiştirebilecek öneriler otomatik olarak (blok gaz limiti gibi), yükseltmeleri koordine edin insanların okuyabileceği anayasada yapılacak değişikliklere oy vermek Cosmos Hub'ın politikalarını yöneten. Anayasa gibi konularda paydaşlar arasında uyum sağlar. hırsızlık ve hatalar (TheDAO olayı gibi), daha hızlı ve daha temiz çözünürlük. Her bölgenin kendi anayasası ve yönetimi de olabilir mekanizması da. Örneğin, Cosmos Hub'ın bir özelliği olabilir Merkezde değişmezliği zorunlu kılan anayasa (geri alma yok, Cosmos Hub düğümü uygulamasının hataları için tasarruf edin), her bölge geri alma işlemleriyle ilgili kendi politikalarını belirleyebilir. Farklı politika alanları arasında birlikte çalışabilirliği sağlayarak, Cosmos ağı, kullanıcılarına en üst düzeyde özgürlük ve potansiyel sunar. izinsiz deneme. Burada yeni bir ademi merkeziyet ve ölçeklenebilirlik modelini tanımlıyoruz. Cosmos, birçok blockchain'den oluşan bir ağdır. Nane. Mevcut teklifler “tek bir blockchain” toplam küresel işlem sıralamasıyla birlikte, Cosmos birçok blockchain'nin birbiriyle eşzamanlı çalışmasına izin verir birlikte çalışabilirliği korurken. Temelde Cosmos Hub birçok bağımsız yönetimi yönetiyor blockchains "bölgeler" olarak adlandırılır (bazen "parçalar" olarak da anılır), "parçalama" olarak bilinen veritabanı ölçeklendirme tekniğine referans.
Yayınlanan bölgelerden gelen son blok işlemlerinin sürekli akışı Hub, Hub'ın her bölgenin durumunu takip etmesine olanak tanır. Benzer şekilde, her bölge Hub'ın durumuna ayak uydurur (ancak bölgeler aracılığıyla dolaylı olarak birbirinizi takip etmeyin. Merkez). Bilgi paketleri daha sonra birinden iletilir. Merkle-kanıtlarını kanıt olarak yayınlayarak bölgeden diğerine geçin. Bilgiler gönderildi ve alındı. Bu mekanizmaya denir inter-blockchain iletişim veya kısaca IBC. Bölgelerden herhangi biri döngüsel olmayan bir grafik oluşturmak için merkez olabilir, ancak netlik sağlamak amacıyla yalnızca basit olanı tanımlayacağız. Yalnızca bir hub'ın ve birçok hub'ın olmadığı yapılandırma bölgeler. Cosmos Hub, çoklu varlıkları barındıran bir blockchain'dır token'lerin bireysel kullanıcılar tarafından tutulabileceği dağıtılmış defter veya bölgelerin kendileri tarafından. Bu token'ler bir bölgeden taşınabilir diğerine "bozuk para paketi" adı verilen özel bir IBC paketinde. Merkez toplamın küresel değişmezliğini korumaktan sorumludur bölgeler genelinde her token miktarı. IBC bozuk para paketi işlemler gönderen, hub ve alıcı tarafından gerçekleştirilmelidir blockchains.Cosmos Merkez, tüm hesap için merkezi defter görevi gördüğü için Sistemde Hub'ın güvenliği büyük önem taşımaktadır. iken her bölge şu şekilde güvence altına alınan bir Tendermint blockchain olabilir: 4 kadar az (veya BFT fikir birliğine ihtiyaç duyulmuyorsa daha da az), Hub küresel olarak merkezi olmayan bir validator kümesi tarafından güvence altına alınmalıdır; gibi en şiddetli saldırı senaryolarına dayanabilir. kıtasal ağ bölünmesi veya ulus devlet destekli bir saldırı. Cosmos bölgesi, IBC alışverişini yapan bağımsız bir blockchain bölgesidir Hub ile mesajlar. Merkezin bakış açısına göre bir bölge bir çok varlıklı dinamik üyelikli çoklu imza hesabı IBC paketleri kullanarak tokens gönderip alabilir. Bir gibi kripto para birimi hesabı, bir bölge şu sayıdan daha fazla tokens aktaramaz sahiptir, ancak bunlara sahip olan diğer kişilerden token alabilir. Bir bölge bir veya daha fazla token türünün "kaynağı" olarak belirtilebilir, ona token arzını doldurma gücü veriyor. Cosmos Hub'ın atomları bir bölgenin validator'leri tarafından desteklenebilir Hub'a bağlı. Bu bölgelere çift harcama saldırıları yapılırken oylama gücünün >⅔'ünün olduğu bir bölge olan Tendermint'in hesap verebilirliği ile atomların parçalanmasıyla sonuçlanacaktır Bizans geçersiz durumu taahhüt edebilir. Cosmos Hub çalışmıyor diğer bölgelerde gerçekleştirilen işlemleri doğrulayın veya yürütün; güvendikleri bölgelere token'ler gönderme sorumluluğu kullanıcıların sorumluluğundadır. Gelecekte Cosmos Hub'ın yönetim sistemi Hub'ı geçebilir Bölge arızalarını hesaba katan iyileştirme önerileri. için örneğin, bazı (veya tüm) bölgelerden giden token aktarımlar Bölgelerin acil devre kesilmesine izin vermek için kısılabilir (token aktarımların geçici olarak durdurulması) bir saldırı algılandığında. Şimdi Hub ve bölgelerin birbiriyle nasıl iletişim kurduğuna bakıyoruz diğer. Örneğin, üç adet blockchains varsa, "Bölge1", "Bölge2",
ve “Hub” ve "Bölge1"in hedeflenen bir paket üretmesini diliyoruz. “Hub”tan geçen “Bölge2” için. Bir paketi birinden taşımak için blockchain diğerine, alıcı zincirine bir kanıt gönderilir. Kanıt, gönderen zincirin bir paket yayınladığını belirtir. iddia edilen varış noktası Alıcı zincirin bu kanıtı kontrol etmesi için gönderenin blok başlıklarını takip edebilmelidir. Bu mekanizma, yan zincirler tarafından kullanılan mekanizmaya benzer; Birbiriyle etkileşim halinde olan iki zincirin birbirinden haberdar olması varoluş kanıtı datagramlarının çift yönlü akışı (işlemler). IBC protokolü doğal olarak iki tür kullanılarak tanımlanabilir. işlemler: izin veren bir IBCBlockCommitTx işlemi blockchain herhangi bir gözlemciye en son bloğunun hash olduğunu kanıtlamak için, ve bir IBCPacketTx işlemi; bu, blockchain işleminin yapılmasına olanak tanır. herhangi bir gözlemciye verilen paketin gerçekten yayınlandığını kanıtlayın gönderenin başvurusuyla, Merkle-kanıtı aracılığıyla en son blok-hash. IBC mekaniğini iki ayrı işleme bölerek, Alıcı zincirin yerel ücret piyasası mekanizmasının hangi paketlerin işleneceğini (yani onaylanacağını) belirlerken, Gönderim zincirinde bunun nasıl yapılacağı konusunda tam bir özgürlük sağlanması birçok giden pakete izin verilir. Yukarıdaki örnekte, "Zone1"in-hash bloğunu güncellemek için “Hub”da (veya “Zone2”deki “Hub”da), bir IBCBlockCommitTxişlem “Hub” üzerinde hash bloğuyla yayınlanmalıdır. “Bölge1” (veya “Hub”ın hash bloğuyla "Bölge2" üzerinde). Daha fazla bilgi için IBCBlockCommitTx ve IBCPacketTx'e bakın. iki IBC işlem türünde. Aynı şekilde Bitcoin dağıtılmış olduğundan daha güvenlidir, toplu kopyalanmış defter sayesinde borsaları daha az savunmasız hale getirebiliriz blockchain üzerinde çalıştırarak harici ve dahili saldırıları gerçekleştirebilirsiniz. Biz buna dağıtılmış değişim diyoruz. Kripto para topluluğunun merkezi olmayan yapı olarak adlandırdığı şey Bugünkü borsalar “atomik çapraz zincir” (AXC) işlemleri adı verilen bir şeye dayanıyor. Bir AXC işlemiyle iki kullanıcı iki farklı zincir iki transfer işlemi yapabilir her iki defterde birlikte işlenir veya hiç yapılmaz (ör. atomik olarak). Örneğin, iki kullanıcı bitcoinleri eterle takas edebilir (veya AXC işlemlerini kullanarak iki farklı defterdeki herhangi iki tokens, Bitcoin ve Ethereum her birine bağlı olmasa da diğer. AXC işlemlerinde borsa çalıştırmanın faydası kullanıcıların birbirlerine veya ticari eşleştirmeye güvenmesine gerek yok hizmet. Dezavantajı ise her iki tarafın da çevrimiçi olması gerekmesidir. gerçekleşecek olan ticarettir. Merkezi olmayan değişimin bir başka türü de kitlesel olarak kopyalanan borsalardır. kendi başına çalışan dağıtılmış borsa blockchain. Kullanıcılar bu tür borsalar limit emri verebilir ve emirlerini çevirebilirler. bilgisayar kapalıdır ve işlem kullanıcı olmadan yürütülebilir çevrimiçi. blockchain eşleşir ve takası onun adına tamamlar tüccarın.
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.
Uygulamalar
Merkezi bir borsa, derin bir limit emir defteri oluşturabilir siparişler verir ve böylece daha fazla tüccar çeker. Likidite daha fazlasını doğurur Borsa dünyasında likidite ve dolayısıyla güçlü bir ağ var takasta etkisi (veya en azından kazananın çoğunu alması etkisi) iş. Bugünün kripto para borsalarının mevcut lideri Poloniex 24 saatlik hacimle 20 milyon dolar ile ikinci sırada yer alıyor. Bitynex'in 24 saatlik hacmi 5 milyon dolar. Bu kadar güçlü bir ağ göz önüne alındığında AXC tabanlı merkezi olmayan borsaların Merkezi borsalarda hacim kazanma. Merkezi olmayan bir sistem için Merkezi bir borsayla rekabet edebilmek için borsanın derin emir defterlerini limitli emirlerle desteklemek. Yalnızca dağıtılmış blockchain üzerindeki değişim bunu sağlayabilir. Tendermint, daha hızlı işlem yapmanın ek faydalarını sağlar taahhüt eder. Ödün vermeden hızlı üretime öncelik vererek tutarlılık sayesinde Cosmos içindeki bölgeler işlemleri hızlı bir şekilde analiz edebilir; hem takas emri işlemleri hem de IBC token transferleri ve diğer bölgelerden. Kripto para borsalarının bugünkü durumu göz önüne alındığında, büyük bir Cosmos başvurusu dağıtılmış borsadır (diğer adıyla Cosmos DEX). İşlem çıkış kapasitesi ve taahhüt gecikmesi merkezileştirilmiş olanlarla karşılaştırılabilir olabilir borsalar. Yatırımcılar gerçekleştirilebilecek limitli emirler gönderebilirler her iki tarafın da çevrimiçi olmasına gerek kalmadan. Ve Tendermint ile, Cosmos merkezi ve IBC ile yatırımcılar fonları içeri ve dışarı taşıyabilirler hızlı bir şekilde diğer bölgelere gidiş-dönüş alışverişi. Ayrıcalıklı bir bölge, köprülenmiş bir token kaynağı olarak hareket edebilir başka bir kripto para birimi. Köprü ilişkiye benzer Cosmos hub ve bölge arasında; her ikisi de buna ayak uydurmalı tokens'nin sahip olduğu kanıtları doğrulamak için diğerinin en son blokları birinden diğerine taşındı. Cosmos üzerinde bir "köprü bölgesi" ağ hem Hub'a hem de diğerine ayak uydurur
kripto para birimi. Köprü bölgesi üzerinden yönlendirme, Hub'ın mantığının basit kalması ve diğerlerine göre agnostik olması blockchain Bitcoin'nın proof-of-work gibi fikir birliği stratejileri madencilik. Her köprü bölgesi validator Tendermint destekli bir sistem çalıştıracaktır. blockchain özel bir ABCI köprü uygulamasına ve aynı zamanda tam düğüme sahip “köken” blockchain. Başlangıç noktasında yeni bloklar çıkarıldığında köprü bölgesi validators imzalayarak taahhüt edilen bloklar üzerinde anlaşmaya varacak ve kaynağın blockchain ile ilgili yerel görüşlerini paylaşıyorlar ipucu. Bir köprü bölgesi başlangıç noktasında ödeme aldığında (ve davada yeterli onayın görüldüğü konusunda anlaşmaya varıldı Ethereum veya Bitcoin gibi bir PoW zincirinin), karşılık gelen Bu bakiye ile köprü bölgesinde hesap oluşturulur. Ethereum durumunda köprü bölgesi aynısını paylaşabilir validator--Cosmos Hub olarak ayarlandı. Ethereum tarafında ( Origin), bir köprü sözleşmesi, Ether sahiplerinin Ether göndermesine izin verecek tarihinde köprü sözleşmesine göndererek köprü bölgesine Ethereum. Köprü sözleşmesiyle eter alındıktan sonra, Uygun bir IBC paketi sağlanmadıkça eter geri çekilemez köprü sözleşmesiyle köprü bölgesinden alındı. köprü sözleşmesi köprü bölgesinin validator kümesini izler; Cosmos Hub'ın validator-setiyle aynı olabilir. Bitcoin durumunda kavram benzerdir ancak bunun yerine tek bir köprü sözleşmesi, her UTXO bir kişi tarafından kontrol edilecektir. eşik çoklu imza P2SH yayını. Sınırlamalar nedeniyle P2SH sisteminde imzalayanlar Cosmos ile aynı olamaz Hub validator-set.Köprü bölgesindeki eter ("köprülü eter") şuraya aktarılabilir: ve Hub'dan ve daha sonra bir işlemle yok edilmesi Ethereum adresindeki belirli bir para çekme adresine gönderir. Bir IBC İşlemin köprü bölgesinde gerçekleştiğini kanıtlayan paket etere izin vermek için Ethereum köprü sözleşmesine gönderilebilir geri çekilmek. Bitcoin durumunda, kısıtlı komut dosyası sistemi bunu yapar IBC para transfer mekanizmasını yansıtmak zor. Her biri UTXO kendi bağımsız yayın metni vardır, dolayısıyla her UTXO kümesinde bir değişiklik olduğunda yeni bir UTXO'ye taşındı Bitcoin emanet imzalayanlar. Çözümlerden biri sıkıştırmak ve toplam sayıyı korumak için UTXO-setinin sıkıştırmasını gerektiği kadar açın UTXOs'den fazlası kapatıldı. Böyle bir köprüleme sözleşmesinin riski hileli bir validator kümesidir. ≥⅓ Bizans'ın oy verme gücü eterin çekilmesine neden olabilir Ethereum üzerindeki köprü sözleşmesinden, köprüyü köprü bölgesinde tutarken. Daha da kötüsü, Bizans'ın oylama gücü >⅔ Eteri köprü sözleşmesine gönderenlerden doğrudan çalmak köprü bölgesinin orijinal köprüleme mantığından saparak. Köprüyü uygun şekilde tasarlayarak bu sorunları çözmek mümkündür. tamamen sorumlu. Örneğin, hub'dan gelen tüm IBC paketleri ve menşei, köprü bölgesi tarafından onaylanmayı gerektirebilir öyle ki köprü bölgesinin tüm durum geçişleri merkez ya da menşe tarafından verimli bir şekilde sorgulanmış ve doğrulanmıştır köprü sözleşmesi. Hub ve menşe, validators köprü bölgesinin teminat göndermesine ve token'nin merkezden transfer yapmasına izin vermelidir. Köprü sözleşmesi ertelenmeli (ve teminatların çözülmesi yeterince uzun bir süre) herhangi bir zorluğun üstesinden gelinmesine izin vermek için bağımsız denetçiler. Şartnamenin tasarımını bırakıyoruz ve bu sistemin uygulanması gelecekte açık olacak Cosmos
iyileştirme teklifi, Cosmos Merkez tarafından onaylanacak yönetim sistemi. Ölçekleme sorununu çözmek Ethereum için açık bir konudur. Şu anda Ethereum düğüm her bir işlemi işliyor ve ayrıca tüm durumları saklar. bağlantı. Tendermint, blokları Ethereum'den çok daha hızlı işleyebildiğinden proof-of-work, EVM bölgeleri Tendermint konsensusu tarafından desteklenmektedir ve köprülü eter üzerinde çalışmak daha yüksek performans sağlayabilir Ethereum blockchains. Ayrıca, Cosmos Hub ve IBC paket mekaniği keyfi sözleşme mantığına izin vermez kendi başına yürütme, token hareketleri koordine etmek için kullanılabilir farklı bölgelerde çalışan Ethereum sözleşmeler arasında, token merkezli Ethereum ölçeklendirme için bir temel sağlar parçalama. Cosmos bölgeleri, şu saatte tanımlanan rastgele uygulama mantığını çalıştırır: bölgenin yaşamının başlangıcıdır ve potansiyel olarak güncellenebilir zamanla yönetim tarafından Bu esneklik, Cosmos bölgelerinin Ethereum gibi diğer kripto para birimlerine köprü görevi görür veya Bitcoin ve aynı zamanda bu blockchain'lerin türevlerine de izin verir, aynı kod tabanını kullanıyor ancak farklı bir validator kümesiyle ve ilk dağıtım. Bu, mevcut birçok kripto para biriminin Ethereum, Zerocash, Bitcoin gibi çerçeveler, Tendermint Core ile kullanılacak CryptoNote vb. ortak bir ağ üzerinde daha yüksek performanslı bir fikir birliği motoru, arasında birlikte çalışabilirlik için muazzam bir fırsat yaratıyor platformlar. Ayrıca, çoklu varlık blockchain olarak tek bir işlem birden fazla girdi ve çıktı içerebilir; burada her biri giriş herhangi bir token türünde olabilir; bu, Cosmos öğesinin doğrudan şu şekilde hizmet vermesini sağlar: emirlerin varsayılmasına rağmen merkezi olmayan değişim için bir platformdiğer platformlar aracılığıyla eşleştirilecek. Alternatif olarak bir bölge hizmet verebilir Dağıtılmış, hataya dayanıklı bir borsa olarak (sipariş defterleri ile), mevcut merkezi sisteme göre kesin bir gelişme olabilir zamanla saldırıya uğrama eğiliminde olan kripto para borsaları. Bölgeler ayrıca kurumsal işletmenin blockchain destekli sürümleri olarak da hizmet verebilir ve belirli bir hizmetin parçalarının bulunduğu hükümet sistemleri geleneksel olarak bir kuruluş veya kuruluşlar grubu tarafından yönetilir bunun yerine belirli bir bölgede ABCI uygulaması olarak çalıştırılır; Kamunun güvenliğini ve birlikte çalışabilirliğini devralmasına izin verir Temeldeki kontrolden ödün vermeden Cosmos ağı hizmet. Dolayısıyla Cosmos her iki dünyanın da en iyisini sunabilir blockchain teknolojisini kullanmak isteyen ancak Kontrolü tamamen dağıtılmış bir üçüncüye bırakma konusunda ihtiyatlı davranın parti. Bazıları tutarlılığı tercih etmenin büyük bir sorun olduğunu iddia ediyor Tendermint gibi fikir birliği algoritmaları, herhangi bir ağın
⅔ ile tek bir bölümün olmamasına neden olan bölüm oylama gücü (örneğin ≥⅓ fanzinden çıkmak) fikir birliğini tamamen durduracaktır. Cosmos mimarisi, aşağıdakileri kullanarak bu sorunun azaltılmasına yardımcı olabilir: oy verme yetkisinin olduğu bölgesel özerk bölgelere sahip küresel bir merkez her bölge için ortak bir coğrafi temele göre dağıtılır bölge. Örneğin, ortak bir paradigma bireysel olabilir. şehirleri veya bölgeleri paylaşırken kendi bölgelerini işletmek ortak merkez (ör. Cosmos Merkez), belediye faaliyetlerinin hub'ın geçici bir ağ nedeniyle durması durumunda devam etmesi bölüm. Bunun gerçek jeolojik, politik ve Sağlam tasarımda dikkate alınması gereken ağ topolojik özellikleri Birleşik hataya dayanıklı sistemler.
NameCoin bu sorunu çözmeye çalışan ilk blockchain'lardan biriydi. Bitcoin blockchain uyarlanarak ad çözümleme sorunu. Ne yazık ki bu yaklaşımla ilgili çeşitli sorunlar yaşandı. Namecoin ile örneğin @satoshi'nin olduğunu doğrulayabiliriz. Geçmişte bir noktada belirli bir genel anahtarla kayıtlı olan, ancak genel anahtarın o zamandan beri kullanılıp kullanılmadığını bilemiyoruz. sonuncusundan bu yana tüm blokları indirmediğimiz sürece yakın zamanda güncellendi bu ismin güncellenmesi. Bunun nedeni Bitcoin'nin sınırlamasıdır UTXO işlem Merkleleştirme modeli; burada yalnızca işlemler (ancak değiştirilebilir uygulama durumu değil) Merkle'lidir hash bloğuna. Bu, bir ismin daha sonraki güncellemelerinin var olmadığını değil, varlığını kanıtlamamızı sağlar. Bu nedenle bunu bilemeyiz tam olarak güvenmeden bir ismin en son değerini kesin olarak belirlemek indirerek bant genişliğinde önemli maliyetlere neden olmak tamamı blockchain. NameCoin'de Merkle'li bir arama ağacı uygulanmış olsa bile, proof-of-work bağımlılığı, hafif istemci doğrulamasını sağlar sorunlu. Light istemcilerin tam bir kopyasını indirmeleri gerekir. blockchain'un tamamındaki tüm bloklar için başlıklar (veya en azından bir ismin son güncellemesinden bu yana başlıklar). Bu şu anlama gelir: bant genişliği gereksinimleri zaman miktarıyla doğrusal olarak ölçeklenir [21]. Ayrıca proof-of-work blockchain numaralı telefondaki ad değişiklikleri ek proof-of-work onaylama bloklarının beklenmesini gerektirir, Bitcoin tarihinde bu işlem bir saate kadar sürebilir. Tendermint ile ihtiyacımız olan tek şey en son blok-hash validators'lik bir çoğunluk (oy gücüne göre) ve bir Merkle tarafından imzalandı isimle ilişkili mevcut değerin kanıtı. Bu onu yapar kısa ve öz, hızlı ve güvenli bir ışık istemcisine sahip olmak mümkün ad değerlerinin doğrulanması. Cosmos'de bu konsepti alıp daha da genişletebiliriz. Her biri Cosmos içindeki ad kayıt bölgesi, ".com" veya ".org" gibi ilişkili bir üst düzey alan (TLD) adına sahip olabilir ve her ad-
kayıt bölgesinin kendi yönetimi ve kaydı olabilir kurallar.
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.
Yönetişim ve Ekonomi
Cosmos Hub çok varlıklı dağıtılmış bir defter olsa da, atom adı verilen özel bir yerli token. Atomlar tek staking Cosmos Hub'ın token. Atomlar, sahibine ait bir lisanstır. oy verin, doğrulayın veya diğer validator'lere yetki verin. Ethereum gibi eter, atomlar aynı zamanda işlem ücretlerini ödemek için de kullanılabilir spam'ı azaltın. Ek şişirici atomlar ve blok işlemi ücretler validator'lere ve yetki veren delegelere ödüllendirilir validators. BurnAtomTx işlemi herhangi bir veriyi kurtarmak için kullanılabilir. rezerv havuzundan orantılı miktarda tokens. tokens ve validators atomunun Genesis'teki ilk dağılımı Cosmos Bağış Kampanyasının bağışçılarına (%75), lider bağışçılara gidecek (%5), Cosmos Network Foundation (%10) ve ALL IN BITS, Inc. (%10). Oluşumdan itibaren toplam atom miktarının 1/3'ü her yıl kefil validator'lere ve delegelere ödüllendirilecektir. Ek ayrıntılar için Cosmos Plana bakın. Bitcoin veya diğer proof-of-work blockchain'lerden farklı olarak, bir Tendermint Artan hız nedeniyle blockchain daha fazla validator ile yavaşlıyor iletişim karmaşıklığı. Neyse ki yeterince destek verebiliyoruz validators, küresel olarak sağlam bir şekilde dağıtılmış blockchain oluşturmak için çok hızlı işlem onaylama süreleriyle ve bant genişliği olarak,
depolama ve paralel bilgi işlem kapasitesi artışları sayesinde şunları yapabileceğiz: gelecekte daha fazla validator desteklemek için. Yaratılış gününde maksimum validators sayısı şu şekilde ayarlanacak: 100, bu sayı 10 yıl boyunca %13 oranında artacak, 300 validators'ye yerleşti. Henüz atom sahibi olmayanlar şu tarihe kadar validators olabilirler. bir BondTx işleminin imzalanması ve gönderilmesi. miktarı Teminat olarak sağlanan atomların sıfırdan farklı olması gerekir. Herkes olabilir Geçerli boyutun boyutu dışında herhangi bir zamanda validator validator kümesi maksimum validators sayısından daha büyük izin verildi. Bu durumda işlem ancak tutarı kadar geçerli olur. atomları, tutulan etkin atomların miktarından daha fazladır. en küçük validator; burada etkin atomlar, devredilen atomları içerir. Yeni bir validator mevcut bir validator öğesinin yerini bu şekilde aldığında, mevcut validator devre dışı kalır ve tüm atomlar ve delege edilen atomlar bağlanmamış duruma girer. validators'ye herhangi bir ceza uygulanması gerekir. yaptırımlardan kasıtlı veya kasıtsız sapma protokol. Bazı deliller derhal kabul edilebilir. aynı yükseklikte ve yuvarlakta çift işaret veya kuralların ihlali Yıl 0: 100 Yıl 1: 113 2. Yıl: 127 Yıl 3: 144 4. Yıl: 163 Yıl 5: 184 Yıl 6: 208 Yıl 7: 235 Yıl 8: 265 Yıl 9: 300 Yıl 10: 300 ...
"kilidi önceden oyla" (Tendermint konsensüs protokolünün bir kuralı). Bu tür kanıtlar validator'nin iyi itibarını kaybetmesine neden olacaktır ve bağlı atomlarının yanı sıra tokens'nin orantılı payı topluca "hissesi" olarak adlandırılan rezerv havuzu kesilecek. Bazen bölgesel nedenlerden dolayı validators kullanılamayabilir ağ kesintileri, elektrik kesintisi veya diğer nedenler. Eğer herhangi bir zamanda geçmiş ValidatorTimeoutWindow bloklarındaki bir nokta, bir validator taahhüt oyu blockchain sayısından fazlasına dahil edilmedi ValidatorTimeoutMaxAbsent kez, bu validator olur etkin değil ve ValidatorTimeoutPenalty'yi (VARSAYILAN %1) kaybedersiniz hisse. Bazı “kötü niyetli” davranışlar açıkça fark edilebilir sonuçlar doğurmaz blockchain ile ilgili kanıt. Bu durumlarda validators şunları yapabilir: Bu kötü amaçlı yazılımların zaman aşımını zorlamak için bant dışı koordinasyonu sağlayın validators, eğer çoğunlukta bir fikir birliği varsa. Cosmos Merkezin ≥⅓ koalisyon nedeniyle durduğu durumlarda Oy gücünün tükenmesi veya ≥⅓ koalisyonun olduğu durumlarda oy verme yetkisinin kötü niyetli davranışlara dair kanıtlarını sansürlemek blockchain'ye girildiğinde hub'ın hard fork ile kurtarılması gerekir yeniden düzenleme teklifi. (“Çatallar ve Sansür Saldırıları”na bağlantı). Cosmos Hub validator'ler herhangi bir token türünü veya kombinasyonunu kabul edebilir Bir işlemin işlenmesine ilişkin ücretler gibi türler. Her validator şunları yapabilir: istediği döviz kurunu öznel olarak belirler ve seçer BlockGasLimit olduğu sürece istediği işlemler ne olursa olsun aşılmadı. Toplanan ücretlerden aşağıda belirtilen vergiler düşüldükten sonra, bağlı hissedarlara orantılı olarak yeniden dağıtılır. bağlı atomları, her ValidatorPayoutPeriod (VARSAYILAN 1 saat).Toplanan işlem ücretlerinden ReserveTax (VARSAYILAN %2) rezerv havuzunu arttırmak için rezerv havuzuna gidin ve Cosmos ağının güvenliğini ve değerini artırın. Bunlar fonlar da kararlara uygun olarak dağıtılabilir yönetim sistemi tarafından yapılmıştır. Oy verme yetkisini diğer validator'lere devreden atom sahipleri Yetki verilen validator'ye komisyon ödeyin. Komisyon şunları yapabilir: her validator tarafından ayarlanabilir. Cosmos Hub'ın güvenliği, temel validators ve yetki verenlerin yetki seçimi. Bulunanların keşfedilmesini ve erken raporlanmasını teşvik etmek amacıyla Cosmos Hub, bilgisayar korsanlarını güvenlik açıklarını yayınlamaya teşvik ediyor "Bu, validator saldırıya uğradı. Lütfen bu adrese ödül gönderin”. üzerine böyle bir istismar durumunda validator ve yetki verenler pasif hale gelecektir, Herkesin atomlarının HackPunishmentRatio (varsayılan %5'i) alınacak kesildi ve herkesin atomlarının HackRewardRatio'su (varsayılan %5) hackerın ödül adresine ödüllendirilecek. validator kalan atomları yedek anahtarlarını kullanarak kurtarmaları gerekir. Bu özelliğin kötüye kullanılmasını önlemek için aktarıma yatırımsız atomlar, yatırımsız atomlara karşı yatırımsız atomların kısmı validator'ler ve delegeler ReportHackTx'ten önce ve sonra aynı kalacak ve hacker ödülü bazı varsa, yatırımsız atomlar. Cosmos Hub, dağıtılmış bir kuruluş tarafından işletilmektedir. iyi tasarlanmış bir yönetim mekanizmasına ihtiyaç duymaktadır. değişken gibi blockchain'deki çeşitli değişiklikleri koordine edin
sistem parametrelerinin yanı sıra yazılım yükseltmeleri ve anayasa değişiklikleri. Tüm validator'ler tüm tekliflere oy vermekten sorumludur. başarısız Bir teklife zamanında oy vermek validator ile sonuçlanacaktır adı verilen bir süre boyunca otomatik olarak devre dışı bırakılır. Devamsızlık Cezası Süresi (VARSAYILAN 1 hafta). Delege edenler, delege edilenlerin oylarını otomatik olarak devralır validator. Bu oy manuel olarak geçersiz kılınabilir. Bağlanmamış atomlar oy alamamak Her teklif için MinimumProposalDeposit tutarında bir depozito gerekir tokens; bir veya daha fazla tokens'nin birleşimi olabilir atomlar dahil. Seçmenler her öneri için oy kullanabilirler. depozito. Seçmenlerin yarısından fazlası seçime girerse depozito (ör. teklifin spam olması nedeniyle), depozito şu adrese gider: yakılan atomlar hariç yedek havuz. Her öneri için seçmenler aşağıdaki seçeneklerle oy kullanabilir: Evet EvetWithForce Hayır NayWithForce Çekimser Evet veya YeaWithForce oylarının tam çoğunluğu (veya Hayır veya Teklifin şu şekilde karara bağlanması için NayWithForce oyu gereklidir) geçti (veya başarısız olduğuna karar verildi), ancak 1/3+ çoğunluğu veto edebilir “zorla” oy kullanarak karar verir. Kesin çoğunluk veto edildiğinde, herkes VetoPenaltyFeeBlocks'u kaybederek cezalandırılır (VARSAYILAN 1 günlük blok değerinde) tutarında ücret (vergiler hariç) etkilenmeyecektir) ve çoğunluğu veto eden taraf
karar ayrıca VetoPenaltyAtoms'un kaybedilmesiyle cezalandırılacaktır (VARSAYILAN %0,1) atomlarının. Burada tanımlanan parametrelerden herhangi biri değiştirilebilir. bir ParameterChangeProposal'ın iletilmesi. Atomlar şişirilebilir ve havuz fonları harcanabilir. Bir Ödül Teklifinin kabul edilmesi. Protokolün yükseltilmesi teklifi gibi diğer tüm teklifler, genel TextProposal aracılığıyla koordine edilecektir. Plana bakınız. blockchain fikir birliğinde birçok yenilik oldu ve Son birkaç yılda ölçeklenebilirlik. Bu bölüm kısa bir bilgi sağlar seçilmiş sayıda önemli olanın araştırılması. Kötü niyetli katılımcıların varlığında fikir birliği bir sorundur Leslie Lamport'un icat ettiği 1980'lerin başlarına kadar uzanıyor. "Bizans hatası" ifadesi, keyfi süreç davranışını ifade eder. “Çarpışma hatasının” aksine, amaçlanan davranıştan saparsa, burada bir süreç basitçe çöküyor. Erken çözümler keşfedildi bir üst sınırın olduğu senkronize ağlar içinmesaj gecikmesi, ancak pratik kullanım oldukça sınırlıydı uçak kontrolörleri gibi kontrollü ortamlar ve veri merkezleri atom saatleri aracılığıyla senkronize edilir. O zamana kadar değildi 90'ların sonlarında Pratik Bizans Hata Toleransının (PBFT) [11] olduğu Verimli, kısmen senkronize bir fikir birliği olarak tanıtıldı algoritma, davranan süreçlerin ⅓'üne kadar tolere edebilir keyfi olarak. PBFT standart algoritma haline geldi ve birçok kapsamında IBM tarafından en son oluşturulanlar da dahil olmak üzere varyasyonlar Hyperledger'a katkıları. PBFT üzerinde Tendermint fikir birliğinin ana avantajı şudur: Tendermint geliştirilmiş ve basitleştirilmiş bir temel yapıya sahiptir, bunlardan bazıları blockchain paradigmasını benimsemenin bir sonucudur. Tendermint blokları sırayla işlenmelidir, bu da PBFT ile ilişkili karmaşıklık ve iletişim ek yükü görünüm değişiklikleri. Cosmos ve birçok kripto para biriminde N bloğu olduğunda i >= 1'in işleme alınması için N+i bloğuna izin verilmesi gerekir kendisi henüz taahhütte bulunmadı. N bloğunun nedeni bant genişliği ise Cosmos bölgesinde taahhütte bulunmadıysa, kullanılmasına yardımcı olmaz N+i blokları için bant genişliği paylaşımı oyları. Bir ağ bölümü veya N bloğunun taahhüt edilmemesinin nedeni ofzine düğümleridir, o zaman N+i yine de taahhütte bulunmayacağım. Ayrıca işlemlerin bloklar halinde gruplandırılması, yerine uygulama durumunun düzenli Merkle-hashing'lenmesi PBFT'nın kontrol noktası şemasındaki gibi periyodik özetler. Bu izin verir hafif istemciler için daha hızlı kanıtlanabilir işlem taahhütleri ve daha hızlı blockchain arası iletişim. Tendermint Core ayrıca birçok optimizasyon ve özellik içerir PBFT'de belirtilenlerin ötesine geçen. Örneğin, validators tarafından önerilen bloklar Merkle'li parçalara bölünmüştür, ve yayıncılığı iyileştirecek şekilde dedikodu yapıldı performansı (ilham için bkz. LibSwift [19]). Ayrıca, Tendermint Core noktadan noktaya herhangi bir varsayımda bulunmaz
P2P ağı açık olduğu sürece bağlantı ve işlevler zayıf bağlantılı. proof-of-stake (PoS), BitShares1.0 [12] dağıtımını yapan ilk yıl olmasa da PoS'un araştırılmasına ve benimsenmesine önemli ölçüde katkıda bulundu blockchains, özellikle "yetkilendirilmiş" PoS olarak bilinenler. içinde BitShares, paydaşlar siparişten sorumlu "tanıkları" seçer işlemleri gerçekleştiren ve yürüten "temsilciler" yazılım güncellemelerini ve parametre değişikliklerini koordine etmek. BitShares2.0 yüksek performansa ulaşmayı hedefliyor (100k tx/s, 1s gecikme) ideal koşullarda, her bloğun tek bir kişi tarafından imzalandığı imzalayan kişi ve işlem bütünlüğü, imzalayandan biraz daha uzun sürüyor blok aralığı. Kanonik bir spesifikasyon halen geliştirilme aşamasındadır. Paydaşlar, uygunsuz davranan tanıkları bir platformda kaldırabilir veya değiştirebilir. günlük olarak, ancak önemli bir tanık veya tanık teminatı yoktur. Tendermint PoS benzeri delegeler kesildi Başarılı bir çift harcama saldırısı durumunda. Ripple'ın öncülüğünü yaptığı bir yaklaşımı temel alan Stellar [13], Federe Bizans Anlaşması modeli burada süreçler fikir birliğine katılmak yxed ve küresel bir anlaşma oluşturmaz bilinen küme. Bunun yerine, her süreç düğümü bir veya daha fazlasını seçer Her biri bir dizi güvenilir süreçten oluşan “çekirdek dilimleri”. bir Stellar içindeki “yesayı”nın, aşağıdakileri içeren bir düğüm kümesi olduğu tanımlanmaktadır: kümedeki her düğüm için en az bir yetersayı dilimi, öyle ki anlaşmaya varılabilir. Stellar mekanizmasının güvenliği şu varsayıma dayanır: herhangi iki yeter sayının kesişiminin boş olmadığı, ancak Bir düğümün kullanılabilirliği, çekirdek dilimlerinden en az birinin tamamen doğru düğümlerden oluşur ve bunlar arasında bir değiş-tokuş yaratır. Dengelenmesi zor olabilecek büyük veya küçük çekirdek dilimlerinin kullanılması Güvenle ilgili önemli varsayımlar empoze etmeden. Sonuçta,düğümlerin bir şekilde yeterli çekirdek dilimlerini seçmesi gerekir yeterli hata toleransı (veya herhangi bir "sağlam düğüm" olması, makalenin sonuçlarının çoğu buna bağlıdır) ve tek böyle bir yapılandırmanın hiyerarşik olmasını sağlamak için sağlanan strateji ve internetteki üst düzey ISP'ler tarafından küresel yönlendirme tabloları oluşturmak için kullanılan Sınır Ağ Geçidi Protokolüne (BGP) benzer ve TLS sertifikalarını yönetmek için tarayıcılar tarafından kullanılanlar; ikisi de meşhur güvensizlikleri için. Tendermint tabanlı hisse kanıtı sistemlerine ilişkin Stellar belgesindeki eleştiri, açıklanan token stratejisiyle hafifletildi burada atom adı verilen yeni bir token türü yayınlanır; ücret ve ödüllerin gelecekteki kısımlarına ilişkin talepleri temsil eder. Tendermint tabanlı proof-of-stake'nin avantajı görecelidir basitlik, aynı zamanda yeterli ve kanıtlanabilir güvenlik sağlarken garanti eder. BitcoinNG, Bitcoin için önerilen ve aşağıdakilere izin verecek bir iyileştirmedir: blok boyutunun arttırılması gibi dikey ölçeklenebilirlik biçimleri için, tipik olarak ilişkili olumsuz ekonomik sonuçlar olmadan orantısız derecede büyük etki gibi bir değişiklikle küçük madencilerde. Bu iyileştirme, ayrıştırılarak elde edilir. işlem yayınından lider seçimi: liderler ilk sırada proof-of-work tarafından "mikro bloklar" halinde seçildi ve ardından yeni bir mikro bloğa kadar gerçekleştirilecek yayın işlemleri Bulundu. Bu, gerekli bant genişliği gereksinimlerini azaltır. PoW yarışını kazanarak küçük madencilerin daha adil bir şekilde rekabet edebilmesini sağlayın, ve işlemlerin daha düzenli yapılmasına olanak sağlanması Mikro bloğu bulan son madenci. Casper [16] önerilen bir proof-of-stake fikir birliği algoritmasıdır. Ethereum. Başlıca çalışma şekli “bahse dayalı fikir birliği”dir. Tarafından validators'nin hangi blokta olacağına inandıkları üzerine yinelemeli olarak bahis oynamasına izin vermek
diğer bahislere bağlı olarak blockchain'ye bağlanın Şu ana kadar gördükleri gibi, sonunda aynılığa ulaşılabilir. bağlantı. Bu, Casper ekibinin aktif bir araştırma alanıdır. Buradaki zorluk, yapılabilecek bir bahis mekanizması oluşturmaktır. evrimsel olarak istikrarlı bir strateji olduğu kanıtlanmıştır. Başlıca faydası Casper, Tendermint ile karşılaştırıldığında "kullanılabilirlik" sunuyor olabilir aşırı tutarlılık” – fikir birliği >⅔ yeterli çoğunluk gerektirmez oylama gücü – belki taahhüt hızı pahasına veya uygulama karmaşıklığı. Interledger Protokolü [14] kesinlikle bir ölçeklenebilirlik çözümü değildir. o farklı defterler arasında geçici bir birlikte çalışma sağlar Gevşek bir şekilde bağlı ikili ilişkiler ağı aracılığıyla sistemler. Lightning Network gibi ILP'nin amacı da ödemeler, ancak özellikle farklı ödemeler arasındaki ödemelere odaklanıyor defter türleri ve atomik işlem mekanizmasını genişletir yalnızca hash kilitleri değil, aynı zamanda noter yetersayısını da içerir (buna denir) Atomik Taşıma Protokolü). için ikinci mekanizma Defterler arası işlemlerde atomikliğin uygulanması şuna benzer: Tendermint'in hafif istemci SPV mekanizması, yani ILP ve Cosmos/IBC arasındaki ayrım garanti edilir ve aşağıda verilmiştir. 1. ILP'deki bağlayıcının noterleri üyeliği desteklemez değişiklikler arasında zexible ağırlıklandırmaya izin vermeyin ve noterler. Öte yandan, IBC özellikle şunlar için tasarlanmıştır: blockchains; burada validators farklı ağırlıklara sahip olabilir ve üyeliğin dönem boyunca değişebileceği yer blockchain. 2. Lightning Network'te olduğu gibi ILP'de ödemenin alıcısı Gönderene onay gönderebilmek için çevrimiçi olmanız gerekir. birtoken, alıcının validator kümesi olan IBC üzerinden aktarım blockchain onayın sağlanmasından sorumludur, kullanıcıyı alıyor. 3. En çarpıcı fark, ILP'nin konnektörlerinin Ödemeler konusunda sorumlu veya yetkili devleti tutmak, Cosmos'de ise bir hub'ın validator'leri şu otoritenin yetkisindedir: IBC token eyaleti transferlerinin yanı sıra her bir bölgede tutulan tokens miktarı (ancak miktarı değil) token'ler bir bölge içindeki her hesapta tutulur). Bu Güvenli asimetriklik sağlayan temel yenilik token'lerin bölgeden bölgeye aktarılması; ILP'nin analogu Cosmos içindeki bağlayıcı kalıcı ve maksimum düzeyde güvenlidir blockchain defter, Cosmos Merkez. 4. ILP'deki defterler arası ödemelerin bir belgeyle desteklenmesi gerekir. Asimetrik transfer olmadığından takas emir defteri madeni paraların bir defterden diğerine aktarılması, yalnızca değerin veya piyasa eşdeğerleri. Yan zincirler [15], Bitcoin'yi ölçeklendirmek için önerilen bir mekanizmadır. "iki yönlü sabitlenmiş" alternatif blockchain'ler aracılığıyla ağ Bitcoin blockchain. (İki yönlü sabitleme şuna eşdeğerdir: köprüleme. Cosmos'de piyasa sabitlemeden ayırt etmek için "köprüleme" diyoruz). Yan zincirler, bitcoinlerin etkili bir şekilde hareket etmesini sağlar. Bitcoin blockchain yan zincire ve arkaya doğru ilerleyin ve aşağıdakilere izin verin: yan zincirdeki yeni özelliklerin denenmesi. Olarak Cosmos Hub, yan zincir ve Bitcoin hafif istemciler olarak hizmet eder madeni paraların ne zaman yatırılması gerektiğini belirlemek için SPV kanıtlarını kullanarak birbirlerine yan zincire ve arkaya aktarılır. Elbette, Bitcoin tarihinden beri proof-of-work kullanıyor, Bitcoin merkezli yan zincirler zarar görüyor proof-of-work'nın birçok sorunu ve riskinden dolayı Konsensüs mekanizması. Üstelik bu bir Bitcoin-maksimalist çeşitli token'leri yerel olarak desteklemeyen çözüm ve
Cosmos'un yaptığı gibi bölgeler arası ağ topolojisi. Bununla birlikte, çekirdek iki yönlü çivinin mekanizması prensipte bununla aynıdır Cosmos ağı tarafından kullanılıyor. Ethereum şu anda bir dizi farklı stratejiyi araştırıyor Ethereum blockchain adresinin durumunu parçalamak için ölçeklenebilirlik ihtiyaçları. Bu çabaların amacı, Geçerli Ethereum Sanal Makine tarafından sunulan soyutlama katmanı paylaşılan durum alanı boyunca. Çoklu araştırma çabaları şu sıralar sürüyor. [18][22] Cosmos ve Ethereum 2.0 Leylak rengi [22] farklı tasarım hedeflerine sahiptir. Cosmos özellikle tokens ile ilgilidir. Mauve ölçeklendirmeyle ilgilidir genel hesaplama. Cosmos EVM'ye bağlı değildir, dolayısıyla farklı VM'ler bile birlikte çalışabiliriz. Cosmos, bölgeyi oluşturanın bölgeyi kimin doğruladığını belirlemesine olanak tanır bölge. Cosmos bölgesinde herkes yeni bir alt bölge başlatabilir (yönetim olmadığı sürece) aksi yönde karar verir). Hub bölge hatalarını izole ederek global token değişmezlerinin korunmuş. Lightning Network önerilen bir token aktarım ağıdır Bitcoin blockchain (ve diğer genel) üzerindeki bir katmanda çalışan blockchains), birçok büyüklükte iyileştirmeye olanak sağlar işlemlerin çoğunluğunu taşıyarak işlem verimini artırın fikir birliği defterinin dışında sözde "ödeme kanallarına" aktarılır.Bu, zincir üstü kripto para birimi komut dosyalarıyla mümkün olmaktadır. Tarafların ikili devlet sözleşmeleri yapmalarına olanak sağlamak, dijital imzalar ve sözleşmeler paylaşılarak durum güncellenebilir kanıtların blockchain üzerinde Yynal olarak yayınlanmasıyla kapatılabilir. Mekanizma ilk olarak zincirler arası atomik takaslarla popüler hale getirildi. Tarafından Birçok tarafla ödeme kanallarının açılması, katılımcılar Lightning Network, yönlendirme için odak noktaları haline gelebilir başkalarının ödemeleri, tamamen bağlantılı bir ödeme kanalına yol açar sermayenin ödeme kanallarına bağlanması pahasına ağ. Lightning Network aynı zamanda kolaylıkla genişleyebilir. değer aktarımına izin vermek için birden fazla bağımsız blockchains bir döviz piyasası yoluyla asimetrik olarak kullanılamaz token'ları bir blockchain'den diğerine aktarın. Asıl fayda burada açıklanan Cosmos ağının amacı bu tür doğrudan token aktarımlar. Bununla birlikte, ödeme kanallarının ve Lightning Network, ürünlerimizle birlikte geniş çapta benimsenecek token aktarım mekanizması, maliyet tasarrufu ve gizlilik nedeniyle. Ayrılmış Tanık, bir Bitcoin iyileştirme teklifi bağlantısıdır. Blok başına işlem hacmini 2 kat veya 3 kat artırmayı hedefliyor, aynı anda yeni düğümler için blok senkronizasyonunu daha hızlı hale getirir. Bu çözümün mükemmelliği, sistem içinde nasıl çalıştığındadır. Bitcoin'nin mevcut protokolünün sınırlamaları vardır ve yumuşak çatala izin verir yükseltme (yani yazılımın eski sürümlerine sahip istemciler yükseltmeden sonra çalışmaya devam edin). Tendermint, yeni olmak protokolün tasarım kısıtlaması yoktur, dolayısıyla farklı bir ölçeklendirmeye sahiptir öncelikler. Tendermint öncelikle BFT hepsini bir kez deneme algoritması kullanır madencilik yerine kriptografik imzalara dayalı birden fazla paralel üzerinden yatay ölçeklendirmeye önemsiz bir şekilde izin verir blockchains, düzenli, daha sık blok işlemeleri izin verirken dikey ölçeklendirme de.
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
è
Fikir Birliği ve Teknik Detaylar
İyi tasarlanmış bir fikir birliği protokolü bazı özellikleri sağlamalıdır. Tolerans kapasitesinin aşılması durumunda garantiler ve fikir birliği başarısız olur. Bu özellikle ekonomik açıdan gereklidir. Bizans davranışının önemli mali etkiye sahip olabileceği sistemler ödül. Bu türden en önemli garanti, fikir birliğine yol açan süreçlerin başarısız (yani protokol istemcilerinin farklı değerleri kabul etmesine neden oldu - bir çatal) kurallarına göre belirlenebilir ve cezalandırılabilir. protokol veya muhtemelen hukuk sistemi. Hukuk sistemi ne zaman güvenilmez veya çağrılması aşırı pahalı, validators olabilir katılmak için depozito yatırmaya zorlananlar ve Kötü niyetli davranışlar ortaya çıktığında mevduatlar iptal edilebilir veya kesilebilir. [10] algılandı. Bunun, çatallanmanın olağan bir olay olduğu Bitcoin'den farklı olduğunu unutmayın ağ eşzamansızlığı ve göndermenin olasılıksal doğası nedeniyle kısmi hash çarpışmalar. Çoğu durumda kötü niyetli bir çatal olduğundan eşzamansızlık nedeniyle çataldan ayırt edilemez, Bitcoin olamaz Örtülü olanlar dışında çatal sorumluluğunu güvenilir bir şekilde uygulayın Yetim durumdaki bir bloğun madenciliği için madencilerin ödediği fırsat maliyeti. Oylama aşamalarına PreVote ve PreCommit diyoruz. Bir oy şuna olabilir: belirli bir blok veya Nil için. >⅔ ÖnOylardan oluşan bir koleksiyona diyoruz aynı turdaki tek bir blok için bir Polka ve >⅔ koleksiyonu Aynı turda tek bir blok için Ön Taahhütler. >⅔ ise Aynı turda Nil için Ön Komite, bir sonrakine geçiyorlar yuvarlak. Protokoldeki katı determinizmin zayıf bir etki yarattığını unutmayın. Hatalı liderlerin tespit edilmesi gerektiğinden senkronizasyon varsayımı ve
atlandı. Böylece, validators bir süre bekler, TimeoutPropose, Ön Oy Vermeden Önce ve değeri TimeoutPropose her turda artar. İlerleme bir turun geri kalanı tamamen eşzamansızdır, bu nedenle ilerleme yalnızca validator ağın >⅔'ünden haber aldığında yapılır. Pratikte, süresiz olarak engellemek için son derece güçlü bir düşman gerekirdi zayıf eşzamanlılık varsayımı (uzlaşının başarısız olmasına neden olur) asla bir blok gerçekleştirin) ve bunu yapmak daha da fazla yapılabilir Her birinde TimeoutPropose'un rastgele değerlerini kullanarak zor validator. Ek bir dizi kısıtlama veya Kilitleme Kuralı, ağ sonunda her yükseklikte yalnızca bir blok işleyecektir. Herhangi biri Birden fazla bloğun işlenmesine neden olmaya yönelik kötü niyetli girişim Belirli bir yükseklikte tanımlanabilir. İlk olarak, bir blok için PreCommit o blok için bir Polka şeklinde gerekçeli olarak gelmelidir. validator zaten R_1 turunda bir blok PreCommit'e sahipse, o blokta kilitli olduklarını söylüyorlardı ve Polka da bu durumu haklı çıkarıyordu. R_2 turundaki yeni Ön Taahhüt, R_polka turunda gelmelidir burada R_1 < R_polka <= R_2. İkincisi, validator'ler Teklif Vermeli ve/veya kilitli oldukları bloğa ÖnOy verin. Birlikte bunlar koşullar, bir validator'nin olmadan Ön Taahhüt yapmamasını sağlar Gerekçe olarak yeterli delil ve validator'ler PreCommit zaten PreCommit'e delil olarak katkıda bulunamaz başka bir şey. Bu hem güvenliği hem de canlılığı sağlar. fikir birliği algoritması. Protokolün tüm ayrıntıları burada açıklanmaktadır. Alternatif bir zincirin (çatal) varlığı ≥⅓ anlamına geldiğinden TendermintPoS'ta tüm blok başlıklarını senkronize etme ihtiyacı ortadan kalkar. bağlı hisse kesilebilir. Tabii ki, kesme işlemi gerektirdiğinden Birisi bir çatalın kanıtını paylaşıyorsa, hafif istemciler saklamalıdır herhangi bir blok-hash gördüğünü taahhüt eder. Ayrıca hafif istemcilervalidator kümesinde yapılan değişikliklerle periyodik olarak senkronize kalabilir. uzun menzilli saldırılardan kaçınmak için (ancak diğer çözümler mümkün). Ethereum'ye benzer bir ruhla Tendermint, uygulamaların her bloğa global bir Merkle kökü hash gömerek kolayca izin verin Hesap bakiyeleri, değer gibi şeyler için doğrulanabilir durum sorguları bir sözleşmede saklanması veya harcanmamış bir işlemin varlığı uygulamanın niteliğine bağlı olarak çıktı. Yeterince dayanıklı bir yayın ağları koleksiyonu varsayarsak ve statik bir validator kümesi varsa, blockchain içindeki herhangi bir çatal tespit edildi ve rahatsız edici validator'lerin mevduatları kesildi. Bu Vitalik Buterin'in ilk olarak 2014'ün başlarında önerdiği yenilik, diğer proof-of-stake'nin tehlikede olmayan hiçbir şey sorunu kripto para birimleri (bkz. İlgili Çalışma). Ancak validator ayarlandığından beri orijinali uzun bir süre boyunca değiştirebilmelidir validators'nin tümü bağımsız hale gelebilir ve dolayısıyla hiçbir maliyete katlanmadan, oluşum bloğundan yeni bir zincir oluşturun artık kilitli mevduatları yok. Bu saldırı gerçekleşti Kısa Menzilli Saldırının aksine Uzun Menzilli Saldırı (LRA) olarak bilinir Şu anda bağlı olan validator'lerin menzil saldırısına neden olduğu Menzil Saldırısı çataldır ve bu nedenle cezalandırılabilir (çataldan sorumlu olduğu varsayılarak BFT Tendermint fikir birliği gibi bir algoritma). Uzun Menzilli Saldırılar genellikle proof-of-stake'ye kritik bir darbe olduğu düşünülür. Neyse ki LRA aşağıdaki şekilde hafifletilebilir. Öncelikle bir süreliğine validator borcunu çözebilir (böylece teminat depozitolarını geri alabilir) ve artık fikir birliğine katılmak için ücret kazanmıyoruz), depozito belirli bir süre devredilemez hale getirilmelidir "bağların çözülme dönemi" olarak bilinen ve haftalar veya aylar. İkincisi, hafif istemcinin güvende olması için ilk ağa bağlandığında yeni bir bloğu doğrulaması gerekir-hash güvenilir bir kaynağa veya tercihen birden fazla kaynağa karşı. Bu
duruma bazen “zayıf öznellik” adı verilir. Son olarak, güvende kalabilmesi için şu tarihteki en son validator ayarıyla senkronize edilmesi gerekir en az bağlanma süresinin uzunluğu kadar sıklıkta. Bu Hafif istemcinin validator'deki değişikliklerden haberdar olmasını sağlar validator'nin sermayesi serbest olduğundan ve dolayısıyla artık tehlikede, bu da müşteriyi kandırmasına izin verecek bir noktadan başlayarak yeni bloklar oluşturarak uzun menzilli bir saldırı bağlandığı yerin yüksekliği (yeterince kontrole sahip olduğu varsayılarak) ilk özel anahtarların çoğu). LRA'nın bu şekilde üstesinden gelinmesinin, proof-of-work orijinal güvenlik modeli. PoW'da, hafif bir istemcinin mevcut yükseklikle senkronize edilebileceğini varsaydı. her blok başlığında iş kanıtını işleyerek istediğiniz zaman güvenilir bir oluşum bloğu oluşturabilirsiniz. Ancak LRA'nın üstesinden gelmek için hafif bir istemcinin belli bir düzenlilikle çevrimiçi olmasını gerektirir validator kümesindeki değişiklikleri takip edin ve ilk kez çevrimiçi olduklarında kimlik doğrulama konusunda özellikle dikkatli olmaları gerekir ağdan güvenilir kaynaklara karşı duyduklarını. arasında elbette, bu ikinci gereksinim Bitcoin gereksinimine benzer; burada protokol ve yazılımın da güvenilir bir yerden alınması gerekir. kaynak. LRA'yı önlemeye yönelik yukarıdaki yöntem validators için çok uygundur ve Tendermint destekli bir blockchain'nin tam düğümleri çünkü bunlar düğümlerin ağa bağlı kalması amaçlanır. yöntem aynı zamanda hafif istemciler için de uygundur. ağ ile sık sık senkronize edin. Ancak hafif istemciler için internete sık erişime sahip olmaları beklenmemektedir veya blockchain ağı, üstesinden gelmek için başka bir çözüm daha kullanılabilir LRA. validator olmayan token sahipleri token'lerini şu şekilde gönderebilir: çok uzun bir çözülme süresine sahip teminat (örneğin çok daha uzun validators için ayrılma döneminden daha uzun) ve hafif istemcilere hizmet veriyor Geçerliliğin geçerliliğini doğrulamak için ikincil bir yöntemle ve geçmiş blok-hashes. Bu token'ler hesaba katılmasa da blockchain'in fikir birliğinin güvenliği, yine deHafif müşteriler için güçlü garantiler sağlayın. Geçmiş blok ise-hash sorgulama Ethereum'de destekleniyordu, herkes kendi tokens'yi özel olarak tasarlanmış bir smart contract içinde sağlayın ve sağlayın Ücretli tasdik hizmetleri, hafif istemci LRA güvenliği için etkili bir pazar oluşturuyor. Blok taahhüdünün tanımlanması nedeniyle herhangi bir ≥⅓ koalisyonu oylama gücü blockchain'yi fanzin kapanıp kapanmayarak durdurabilir oylarını yayınlıyorlar. Böyle bir koalisyon aynı zamanda sansür de yapabilir bunları içeren blokları reddederek belirli işlemleri işlemler, ancak bu önemli bir oranda sonuçlanacaktır hızı yavaşlatacak blok tekliflerinin reddedilmesi blockchain'nin blok taahhütlerinin artması, faydasını ve değerini azaltır. Kötü niyetli koalisyon aynı zamanda oyları damla damla yayınlayabilir. blockchain blok taahhütlerinin neredeyse durma noktasına gelmesi veya devreye girmesi için bu saldırıların herhangi bir kombinasyonu. Son olarak aşağıdakilere neden olabilir: blockchain çift imzalayarak veya kilitlemeyi ihlal ederek çatallanmaya kurallar. Eğer küresel çapta aktif bir düşman da işin içinde olsaydı, bu durum bölüşülebilirdi. ağı yanlış gibi görünebilecek şekilde Yavaşlamadan validators alt kümesi sorumluydu. bu değil sadece Tendermint'in bir sınırlaması, daha ziyade hepsinin bir sınırlaması Ağı potansiyel olarak bir kişi tarafından kontrol edilen konsensüs protokolleri aktif düşman Bu tür saldırılar için validators'nin bir alt kümesi bir yeniden düzenleme teklifini imzalamak için harici yollarla koordinasyon sağlamak bir çatal (ve bunun herhangi bir kanıtını) ve başlangıç alt kümesini seçer validators imzalarıyla birlikte. Böyle bir yeniden düzenleme teklifini imzalayan doğrulayıcılar, diğer tüm çatallardaki teminatlarından vazgeçer. Müşteriler şunları yapmalıdır: Yeniden düzenleme teklifindeki imzaları doğrulayın, her türlü kanıtı doğrulayın, ve bir karar verin veya son kullanıcıyı bir karara yönlendirin. için Örneğin, bir telefon cüzdanı uygulaması kullanıcıya bir güvenlik kodu sorabilir.
uyarı, buzdolabı herhangi bir yeniden düzenleme teklifini kabul edebilirken Orijinal validator'lerin +½'si tarafından oylama yetkisiyle imzalanmıştır. Hiçbir senkronize olmayan Bizans hataya dayanıklı algoritma gelemez Oylama gücünün ≥⅓'ü sahtekâr olduğunda fikir birliğine varmak, ancak yine de çatallanmak oylama gücünün ≥⅓'ünün halihazırda sahtekâr olduğunu varsayar gerekçesiz olarak çift imza veya kilit değiştirme. Yani imzalamak yeniden düzenleme teklifi çözülemeyecek bir koordinasyon sorunudur senkronize olmayan herhangi bir protokolle çözülür (ör. otomatik olarak ve güvenilirliği hakkında varsayımlarda bulunmadan temel ağ). Şimdilik, yeniden düzenleme önerisi koordinasyonu sorununu toplumsal uzlaşma yoluyla insan koordinasyonuna bırakıyoruz. internet medyasında. Doğrulayıcılar, orada olduğundan emin olmak için dikkatli olmalıdır. Çakışan iki yeniden düzenleme teklifinin imzalandığı durumları önlemek için, bir yeniden düzenleme teklifinin imzalanmasından önce kalan ağ bölümü yoktur. Harici koordinasyon ortamının ve protokolün sağlam, buradan çatalların sansürden daha az endişe verici olduğu sonucu çıkıyor saldırılar. ≥⅓ Bizans gerektiren çatal ve sansüre ek olarak oylama gücü, >⅔ oylama gücünden oluşan bir koalisyon taahhütte bulunabilir keyfi, geçersiz durum. Bu herhangi bir (BFT) özelliğidir Konsensüs sistemi. Çatal oluşturan çift imzalamanın aksine kolayca doğrulanabilir kanıtlarla, bir kişinin bağlılığını tespit etmek geçersiz durum, doğrulama yapmayan eşlerin tüm blokları doğrulamasını gerektirir, bu, durumun yerel bir kopyasını tuttukları ve yürüttükleri anlamına gelir Her işlem için durum kökünü bağımsız olarak hesaplayarak kendileri. Bir kez tespit edildiğinde böyle bir arızayla baş etmenin tek yolu toplumsal mutabakat yoluyla gerçekleşir. Örneğin, Bitcoin durumunda yazılım hataları nedeniyle çatallanma başarısız oldu (Mart ayında olduğu gibi) 2013) veya Bizans davranışından dolayı geçersiz bir durumun gerçekleştirilmesi Madenciler (Temmuz 2015'te olduğu gibi), iyi bağlantılara sahip bir topluluk işletmeler, geliştiriciler, madenciler ve diğer kuruluşlar manuel eylemlerin ne olduğu konusunda toplumsal bir fikir birliği oluşturduKatılımcıların ağı iyileştirmesi gerekiyor. Ayrıca, beri validators İhale blockchain olması beklenebilir tanımlanabilir, geçersiz bir durumun taahhüdü bile olabilir istenirse kanun veya bazı harici içtihatlar tarafından cezalandırılabilir. ABCI, şu adresten teslim edilen 3 ana mesaj türünden oluşur: uygulamanın çekirdeği. Uygulama şu şekilde yanıt verir: karşılık gelen yanıt mesajları. AppendTx mesajı uygulamanın çalışma atıdır. Her biri blockchain içindeki işlem bu mesajla iletilir. uygulamanın, alınan her işlemi doğrulaması gerekir. Mevcut duruma, uygulama protokolüne karşı AppendTx mesajı, ve işlemin kriptografik kimlik bilgileri. Doğrulanmış işlemin daha sonra uygulama durumunu güncellemesi gerekir - tarafından bir değeri anahtar değerler deposuna bağlamak veya UTXO değerini güncelleyerek veritabanı. CheckTx mesajı AppendTx'e benzer ancak yalnızca işlemlerin doğrulanması. Tendermint Core'un ilk bellek havuzu kontrolleri CheckTx ile yapılan bir işlemin geçerliliği ve yalnızca aktarmaların geçerli olması akranlarıyla işlem yapıyor. Uygulamalar artan bir değeri kontrol edebilir işlemde nonce ve eğer CheckTx'te bir hata döndürüyorsa nonce eski. Taahhüt mesajı bir şifreleme hesaplamak için kullanılır mevcut başvuru durumuna bağlılık, sonraki blok başlığı. Bunun bazı kullanışlı özellikleri var. Bu durumun güncellenmesindeki tutarsızlıklar artık şu şekilde görünecek: blockchain tüm programlama sınıfını yakalayan çatallar hatalar. Bu aynı zamanda güvenli hafifliğin geliştirilmesini de kolaylaştırır. Merkle-hash kanıtları kontrol edilerek doğrulanabildiği için istemciler blok-hash ve blok-hash yetersayı tarafından imzalandı validators (oy gücüne göre).
Ek ABCI mesajları uygulamanın takip etmesine olanak tanır ve validator kümesini değiştirin ve uygulamanın yükseklik ve taahhüt oyları gibi bilgileri bloke edin. ABCI istekler/yanıtlar basit Protobuf mesajlarıdır. Kontrol et şemayı çıkarın. Argümanlar: Veri ([]bayt): İstek işlemi baytları İade: Kod (uint32): Yanıt kodu Veri ([]bayt): Varsa sonuç baytları Günlük (dize): Hata ayıklama veya hata mesajı Kullanımı:
Bir işlem ekleyin ve çalıştırın. İşlem geçerli ise CodeType.OK değerini döndürür Argümanlar: Veri ([]bayt): İstek işlemi baytları İade: Kod (uint32): Yanıt kodu Veri ([]bayt): Varsa sonuç baytları Günlük (dize): Hata ayıklama veya hata mesajı Kullanımı:
Bir işlemi doğrulayın. Bu mesaj, devlet. İşlemler ilk önce CheckTx üzerinden gerçekleştirilir bellek katmanındaki eşlere yayınlanır. Yapabilirsin CheckTx yarı durumlu ve Taahhüt üzerine durumu temizler veya BeginBlock , bağımlı işlem dizilerine izin vermek için aynı blokta.
İade: Veri ([]bayt): Merkle kökü hash Günlük (dize): Hata ayıklama veya hata mesajı Kullanımı:
Uygulama durumunun Merkle kökünü hash döndürün. Argümanlar: Veri ([]bayt): Sorgu isteği baytları İade: Kod (uint32): Yanıt kodu Veri ([]bayt): Sorgu yanıtı baytları Günlük (dize): Hata ayıklama veya hata mesajı Kullanımı:
Yanıt kuyruğunu temizleyin. Gerçekleştiren uygulamalar type.Uygulamanın bu mesajı uygulamasına gerek yoktur; proje tarafından ele alınmaktadır. İade: Veri ([]bayt): Bilgi baytları Kullanımı:
Uygulama durumuyla ilgili bilgileri döndürün. Başvuru özel. Argümanlar: Anahtar (dize): Ayarlanacak anahtar
Değer (dize): Anahtar için ayarlanacak değer İade: Günlük (dize): Hata ayıklama veya hata mesajı Kullanımı:
Uygulama seçeneklerini ayarlayın. Örn. Anahtar=“mod”, Değer=“bellek havuzu” için bir bellek havuzu bağlantısı veya Anahtar=“mod”, Değer=“fikir birliği” fikir birliği bağlantısı. Diğer seçenekler uygulamaya özeldir. Argümanlar: Doğrulayıcılar ([]Doğrulayıcı): İlk oluşum-validators Kullanımı:
Bir zamanlar yaradılışta çağrıldı Argümanlar: Yükseklik (uint64): Başlangıç bloğunun yüksekliği Kullanımı:
Yeni bir bloğun başlangıcını işaret eder. Herhangi birinden önce çağrıldı Ek Tx'ler. Argümanlar: Yükseklik (uint64): Biten blok yüksekliği İade: Doğrulayıcılar ([]Doğrulayıcı): validators yenisiyle değiştirildi oylama yetkileri (kaldırmak için 0) Kullanımı:
Bir bloğun sonunu işaret eder. Sonuçta her Taahhütten önce çağrıldı işlemler Daha fazla ayrıntı için ABCI deposuna bakın.Bir göndericinin bu bilgiyi istemesinin birkaç nedeni vardır. Paketin tesliminin alıcı zincir tarafından onaylanması. Örneğin, gönderen e-postanın durumunu bilmiyor olabilir. Arızalı olması bekleniyorsa hedef zincir. Veya gönderen pakete bir zaman aşımı uygulamak istiyorsanız (MaxHeight ile) Paket sarımı), ancak herhangi bir hedef zincir, gelen paketlerin sayısında ani bir artışla hizmet reddi saldırılarına maruz kalabilir. paketler. Bu durumlarda gönderici teslimat onayını talep edebilir. başlangıç paket durumunu AckPending olarak ayarlayarak. O halde, bu teslimatı onaylamak için teslim alma zincirinin sorumluluğundadır. Merkle uygulamasında IBCPacket olarak kısaltılmıştır hash. İlk olarak, "Hub" üzerinde bir IBCBlockCommit ve IBCPacketTx yayınlanır. bu, "Bölge1"de bir IBCPaket 'in varlığını kanıtlar. Bunu söyle IBCPacketTx şu değere sahiptir: FromChainID : “Bölge1” FromBlockHeight: 100 (örneğin) Paket : bir IBCPaket :
Başlık: an IBCPacketHeader:
SrcChainID : “Bölge1”
DstChainID : “Bölge2”
Sayı: 200 (örneğin)
Durum : Onay Bekleniyor
Tür: “para”
MaxHeight : 350 (“Hub”ın şu anda 300 yükseklikte olduğunu söyleyin)
Yük :
FromBlockHeight: 400 (örneğin)
Paket : bir IBCPaket :
Başlık : an IBCPacketHeader :
SrcChainID : “Bölge1”
DstChainID : “Bölge2”
Sayı : 200
Durum: AlındıGönderildi
Tür: “para”
Maksimum Yükseklik : 350
PayloadHash :
durumu 350 bloğundaki “Bölge2”den ayarlasaydı, durumu ayarlardı otomatik olarak Zaman Aşımı'na geçer. Bu zaman aşımı kanıtı, “Bölge1”e geri gönderilir ve tüm token'ler iade edilebilir. Desteklenen iki tür Merkle trees vardır Tendermint/Cosmos ekosistemi: Basit Ağaç ve IAVL+ Ağaç. Basit Ağaç, statik bir öğe listesi için Merkle tree'dur. Eğer öğelerin sayısı ikinin katı değil, bazı yapraklar farklı seviyeler. Simple Tree, ağacın her iki tarafını da aynı seviyede tutmaya çalışır. aynı yükseklikte, ancak soldaki daha büyük olabilir. Bu Merkle tree Bir bloğun işlemlerini ve üst seviyeyi Merkle-ize etmek için kullanılır uygulama durumu kökünün öğeleri.IAVL+ veri yapısının amacı kalıcı uygulama durumundaki anahtar/değer çiftleri için depolama, öyle ki deterministik Merkle kökü hash verimli bir şekilde hesaplanabilir. ağaç, AVL algoritmasının bir çeşidi kullanılarak dengelenir ve tümü işlemler O(log(n))'dir. Bir AVL ağacında herhangi bir düğümün iki alt alt ağacının yükseklikleri en fazla bir farklılık gösterir. Bu koşul herhangi bir şekilde ihlal edildiğinde güncelleme, ağaç O(log(n)) yeni düğümler oluşturularak yeniden dengelenir eski ağacın değiştirilmemiş düğümlerine işaret eder. Orijinal AVL'de Algoritmaya göre iç düğümler aynı zamanda anahtar/değer çiftlerini de tutabilir. AVL+ algoritma (artıya dikkat edin) tümünü koruyacak şekilde AVL algoritmasını değiştirir anahtarları depolamak için yalnızca dal düğümlerini kullanırken, yaprak düğümlerdeki değerler. Bu, merkle hash izini korurken algoritmayı basitleştirir kısa. AVL+ Ağacı, Ethereum'nin Patricia denemelerine benzer. var ödünleşimler. Anahtarların eklenmeden önce hashed edilmesi gerekmez IAVL+ ağaçları, böylece anahtarda daha hızlı sıralı yineleme sağlar bazı uygulamalara fayda sağlayabilecek alan. Mantık daha basit yalnızca iki tür düğüm gerektiren uygulama; iç düğümler ve yaprak düğümleri. Merkle kanıtı ortalama olarak daha kısadır; * / \ / \ / \ / \ * * / \ / \ / \ / \ / \ / \ * * * h6 / \ / \ / \ h0 h1 h2 h3 h4 h5 7 öğeli bir SimpleTree
dengeli ikili ağaç Öte yandan, bir sayının Merkle kökü IAVL+ ağacı güncellemelerin sırasına bağlıdır. Ek verimli Merkle tree'leri destekleyeceğiz, örneğin Ethereum’den Patricia Trie ikili değişken haline geldiğinde mevcut. Kanonik uygulamada, işlemler şu adrese aktarılır: ABCI arayüzü aracılığıyla Cosmos hub uygulaması. Cosmos Hub bir dizi birincil işlemi kabul edecektir SendTx , BondTx , UnbondTx , ReportHackTx dahil olmak üzere türler, SlashTx , BurnAtomTx , ProposalCreateTx ve ProposalVoteTx , bunlar oldukça açıklayıcıdır ve bir belgede belgelenecektir. Bu makalenin gelecekteki revizyonu. Burada iki birincil belgeyi belgeliyoruz IBC için işlem türleri: IBCBlockCommitTx ve IBCPacketTx. Bir IBCBlockCommitTx işlemi şunlardan oluşur: ChainID (string) : blockchain'nin kimliği BlockHash ([]byte) : Block-hash bayt, Merkle kökü bu uygulamayı içerir-hash BlockPartsHeader (PartSetHeader) : Blok parça kümesi başlığı bayt, yalnızca oy imzalarını doğrulamak için gerekli BlockHeight (int) : Taahhüdün yüksekliği BlockRound (int) : Taahhüt turu Taahhüt ([]Oy): >⅔ Tendermint Ön Taahhüdü şunu oylar: bir blok taahhüdünü içerir ValidatorsHash ([]byte) : Yeninin Merkle ağacı kökü hash validator ayarlandı
ValidatorsHashProof (SimpleProof): ValidatorsHash'in BlockHash'e karşı kanıtlanması için SimpleTree Merkleproof
AppHash ([]byte) : IAVLTree Merkle ağacı kökü hash
uygulama durumu
AppHashProof (SimpleProof): SimpleTree Merkle'ye karşı dayanıklı
AppHash'in BlockHash'a karşı kanıtlanması
Bir IBCPaket aşağıdakilerden oluşur:
Başlık (IBCPacketHeader): Paket başlığı
Yük ([]bayt): Paket yükünün baytları. İsteğe bağlı
PayloadHash ([]byte) : Paketin baytları için hash.
İsteğe bağlı
Payload veya PayloadHash'tan birinin mevcut olması gerekir. hash
IBCPaket 'in iki öğesi olan Başlık'ın basit Merkle köküdür
ve Yük . Tam yük taşımayan bir IBCPakete adı verilir
kısaltılmış paket
Bir IBCPacketHeader aşağıdakilerden oluşur:
SrcChainID (string) : Kaynak blockchain kimliği
DstChainID (string): Hedef blockchain kimliği
Sayı (int): Tüm paketler için benzersiz bir sayı
Durum (numaralandırma): AckPending , AckSent ,'den biri olabilir
AckReceived, NoAck veya Zaman Aşımı
Tür (dize): Türler uygulamaya bağlıdır. Cosmos
"jeton" paket türünü saklı tutar
MaxHeight (int): Durum NoAckWanted veya AckReceived değilse
bu yüksekliğe göre durum Timeout olur. İsteğe bağlı
Bir IBCPacketTx işlemi şunlardan oluşur:FromChainID (string) : blockchain'nın kimliği:
bu paketi sağlamak; mutlaka kaynak değil
FromBlockHeight (int) : blockchain yüksekliği
Aşağıdaki paket, hash bloğuna dahil edilmiştir (Merkle-ized)
kaynak zinciri
Paket (IBCPacket): Durumu bir olabilecek bir veri paketi
AckPending , AckSent , AckReceived , NoAck veya Timeout'un sayısı
PacketProof (IAVLProof): Kanıtlama için IAVLTree Merkle geçirmez
paketin hash kaynak zincirinin AppHash'ine karşı
verilen yükseklik
“Bölge1”den “Bölge2”ye paket gönderme sırası
"Hub" aracılığıyla geçiş {Şekil X}'te gösterilmektedir. İlk olarak bir IBCPacketTx
"Hub"a paketin uygulama durumuna dahil olduğunu kanıtlar
“Bölge1”. Daha sonra başka bir IBCPacketTx "Bölge2"ye şunu kanıtlar:
paket “Hub”un uygulama durumuna dahil edilir. Bu sırada
prosedür, IBCPacket verileri aynıdır: SrcChainID
her zaman “Bölge1”dir ve DstChainID her zaman "Bölge2"dir.
PacketProof doğru Merkle geçirmez yola sahip olmalıdır.
şöyle:
“Bölge1” “Hub” üzerinden “Bölge2”ye paket göndermek istediğinde,
IBCPaket verileri, paketin "Bölge1", "Hub" veya "Bölge2"de Merkleleştirilmiş olmasına bakılmaksızın aynıdır. Değişebilen tek sarı
Teslimatı takip etme durumu.
Kavramsallaştırmada yardım eden arkadaşlarımıza ve akranlarımıza teşekkür ederiz.
Tendermint ile yaptığımız çalışmaları gözden geçirmek ve destek sağlamak
ve Cosmos.
IBC/
SkuChain'den Zaki Manian, biçimlendirme konusunda çok yardımcı oldu ve özellikle ABCI bölümü altındaki ifadeler Althea'dan Jehan Tremback ve Dustin Byington'a yardımlarından dolayı ilk yinelemeler Honey Badger'dan Andrew Miller'a fikir birliğiyle ilgili geri bildirimleri için teşekkür ederiz Greg Slepak'a fikir birliği ve ifadelerle ilgili geribildirim için teşekkür ederiz. Ayrıca çeşitli katkılarından dolayı Bill Gleim ve Seunghwan Han'a teşekkürler. katkılar. Adınız ve kuruluşunuz katkılarınız için burada 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 ZeroCash: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 Ayrılmış Tanık: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 Yıldırım Ağı: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 İhale: https://github.com/tendermint/tendermint/wiki 9 FLP İmkansızlığı: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 Kesici: 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 Yan Zincir: 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 Parçalama: https://github.com/ethereum/EIPs/issues/53 19 LibSwift: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalizOfLibswift.pdf 20 DLS: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 İnce İstemci Güvenliği: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 Leylak Rengi Kağıt: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html
3 e