Cosmos: Dağıtılmış Defterlerden Oluşan Bir Ağ

저자 Jae Kwon and Ethan Buchman · 2016

소개

오픈소스 생태계의 결합된 성공은 분산형 yle 공유 및 공개 암호화폐는 분산화된 인터넷 프로토콜에 대한 이해를 고취시켰습니다. 사회 경제적 인프라를 근본적으로 개선하는 데 사용될 수 있습니다. 우리는 Bitcoin 1와 같은 전문화된 blockchain 애플리케이션을 보았습니다. 암호화폐), Zerocash 2 및 Ethereum [3]와 같은 일반화된 smart contract 플랫폼 Etherium Virtual을 위한 수많은 분산 애플리케이션 Augur(예측 시장) 및 TheDAO과 같은 기계(EVM) [4] (투자 클럽). 그러나 현재까지 이 blockchain은 여러 가지 문제로 어려움을 겪었습니다. 총 에너지 비효율성, 열악함 또는 열악함을 포함한 단점 제한된 성능, 미성숙한 거버넌스 메커니즘. Bitcoin의 거래 처리량을 확장하기 위한 제안: 분리된 증인 [5] 및 BitcoinNG [6]은 수직 확장입니다. 단일 물리적 서버의 용량에 의해 제한되는 솔루션 완전한 감사 가능성의 속성을 보장하기 위해 기계. 라이트닝 네트워크 [7]은 Bitcoin 거래를 확장하는 데 도움이 될 수 있습니다.

일부 거래를 원장에서 완전히 제외하여 거래량 소액결제 및 개인정보 보호에 적합합니다. 지불 레일이지만 더 일반화된 경우에는 적합하지 않을 수 있습니다. 스케일링이 필요합니다. 이상적인 솔루션은 여러 개의 병렬 blockchain을 허용하는 솔루션입니다. 보안 속성을 유지하면서 상호 운용됩니다. 이것은 proof-of-work를 사용하면 불가능하지는 않지만 어려운 것으로 입증되었습니다. 병합됨 예를 들어 채굴을 통해 부모를 확보하는 작업이 가능해집니다. 체인은 하위 체인에서 재사용되지만 트랜잭션은 여전히 유지되어야 합니다. 각 노드별로 순서대로 검증되고 병합 채굴된 blockchain hashing 전력의 대부분이 공격에 취약합니다. 부모가 자식을 적극적으로 병합 채굴하지 않습니다. 학문적 검토 의 대체 blockchain 네트워크 아키텍처가 제공됩니다. 추가적인 맥락을 제공하고 다른 제안에 대한 요약을 제공합니다. 관련 작업의 단점. 여기에서는 새로운 blockchain 네트워크 아키텍처인 Cosmos을 제시합니다. 이 모든 문제를 해결하는 것입니다. Cosmos은 많은 사람들의 네트워크입니다 영역이라고 불리는 독립적인 blockchains. 영역은 다음에 의해 구동됩니다. 고성능을 제공하는 Tendermint Core [8], 일관되고 안전한 PBFT과 유사한 합의 엔진으로, 엄격한 포크책임이 악의적인 행위에 대한 통제를 보장합니다. 배우. Tendermint Core의 BFT 합의 알고리즘이 매우 적합합니다. 공개 proof-of-stake blockchain 확장용. Cosmos의 첫 번째 영역을 Cosmos 허브라고 합니다. Cosmos 허브는 간단한 다중 자산 proof-of-stake 암호화폐입니다. 네트워크가 적응하고 업그레이드. 또한 Cosmos 허브는 다음을 통해 확장할 수 있습니다. 다른 구역을 연결합니다. Cosmos 네트워크의 허브와 영역은 다음과 통신합니다. blockchain 간 통신(IBC) 프로토콜을 통해 서로 blockchains에 대한 일종의 가상 UDP 또는 TCP입니다. 토큰은 다음과 같습니다. 한 구역에서 다른 구역으로 안전하고 신속하게 이전됩니다.구역 간 유동성 교환이 필요하지 않습니다. 대신, 모든 영역 간 token 전송은 Cosmos 허브를 통과합니다. 각 구역이 보유한 token의 총량을 추적합니다. 는 허브는 각 영역을 다른 영역의 장애로부터 격리합니다. 왜냐하면 누구나 Cosmos 허브에 새 영역을 연결할 수 있습니다. 새로운 blockchain 혁신과의 미래 호환성을 위해. 이 섹션에서는 Tendermint 합의 프로토콜을 설명합니다. 그리고 이를 사용하여 애플리케이션을 구축하는 데 사용되는 인터페이스입니다. 더 알아보기 자세한 내용은 부록을 참조하세요. 전통적인 비잔틴 내결함성(BFT) 알고리즘에서 각 노드는 같은 무게를 가지고 있습니다. Tendermint에서 노드는 음수가 아닌 값을 갖습니다. 투표권의 양, 긍정적인 투표를 한 노드 전원을 validators라고 합니다. 검증인은 암호화 서명을 브로드캐스트하여 합의 프로토콜, 또는 다음 블록에 동의하기 위해 투표합니다. 검증인의 투표권은 처음부터 결정되거나 blockchain에 의해 결정적으로 변경되었습니다. 신청. 예를 들어, 다음과 같은 proof-of-stake 애플리케이션에서 Cosmos 허브에서 투표권은 다음에 의해 결정될 수 있습니다. 담보로 보세된 staking token 금액. 참고: ⅔ 및 ⅓과 같은 분수는 전체 투표의 분수를 나타냅니다. 모든 validator이 아닌 한 validator의 총 개수는 절대 아닙니다. 동일한 무게를 가지고 있습니다. >⅔는 “⅔ 이상”을 의미하고, ≥⅓은 “최소”를 의미합니다. ⅓”. Tendermint는 부분적으로 동기식인 BFT 합의 프로토콜입니다. DLS 합의 알고리즘 [20]에서 파생되었습니다. 텐더민트는

단순성, 성능 및 포크 책임으로 유명합니다. 프로토콜에는 알려진 validator 세트가 필요합니다. validator은 공개 키로 식별됩니다. 검증인은 다음을 시도합니다. 한 번에 하나의 블록에 대한 합의에 도달합니다. 여기서 블록은 목록입니다. 거래의. 블록에 대한 합의에 대한 투표는 다음과 같이 진행됩니다. 라운드. 각 라운드에는 라운드 리더 또는 제안자가 있습니다. 블록을 제안합니다. 그런 다음 validator은 단계적으로 다음 사항에 대해 투표합니다. 제안된 블록을 수락하거나 다음 라운드로 넘어갑니다. 는 라운드 제안자는 순서대로 결정적으로 선택됩니다. 투표권에 비례하여 validator 목록입니다. 프로토콜의 전체 세부 사항은 여기에 설명되어 있습니다. Tendermint의 보안은 최적의 비잔틴 사용에서 비롯됩니다. 절대다수(>⅔) 투표 및 잠금을 통한 내결함성 메커니즘. 이들은 함께 다음을 보장합니다. ≥⅓ 투표권은 다음 사항을 위반하는 비잔틴 방식이어야 합니다. 두 개 이상의 값이 커밋되는 안전. validator 세트가 안전 위반에 성공하거나 심지어 그렇게 하려는 시도는 프로토콜에 의해 식별될 수 있습니다. 이 혼란스러운 블록에 대한 투표와 방송이 모두 포함됩니다. 부당한 투표. 강력한 보장에도 불구하고 Tendermint는 탁월한 서비스를 제공합니다. 성능. 7개에 분산된 64개 노드의 벤치마크에서 5개 대륙의 데이터 센터, 상용 클라우드 인스턴스, Tendermint 합의는 한 번에 수천 건의 거래를 처리할 수 있습니다. 둘째, 커밋 대기 시간이 1~2초 정도입니다. 특히 1000건이 넘는 트랜잭션의 성능이 눈에 띕니다. 두 번째는 가혹한 적대적인 상황에서도 유지됩니다. validators가 악의적으로 제작된 투표를 충돌시키거나 방송합니다. 참조 자세한 내용은 아래 그림을 참조하세요.

Tendermint throughput vs block size benchmarked across 64 nodes in 7 datacenters on 5 continents

Tendermint 합의 알고리즘의 주요 이점은 다음과 같습니다. 가벼운 클라이언트 보안으로 인해 모바일 및 사물 인터넷 사용 사례. Bitcoin 라이트 클라이언트는 동기화해야 합니다. 블록 헤더 체인을 찾아 가장 증거가 많은 것을 찾습니다. 작업, Tendermint 라이트 클라이언트는 변경 사항을 따라잡기만 하면 됩니다. validator 세트에 추가한 다음 >⅔ PreCommits를 확인하세요. 최신 상태를 결정하는 최신 블록입니다. 간결한 가벼운 클라이언트 증명으로 inter-blockchain도 가능합니다. 의사소통. Tendermint는 특정 행위를 방지하기 위한 보호 조치를 가지고 있습니다. 장거리 위험이 없는 이중 지출과 같은 주목할만한 공격 그리고 검열. 이에 대해서는 부록에서 더 자세히 설명합니다.Tendermint 합의 알고리즘은 다음과 같이 구현됩니다. Tendermint Core라는 프로그램입니다. 텐더민트 코어는 애플리케이션에 구애받지 않고 모든 것을 바꿀 수 있는 "합의 엔진" 결정론적 블랙박스 애플리케이션을 분산 복제로 변환 blockchain. Tendermint Core는 blockchain 애플리케이션에 연결됩니다. 애플리케이션 블록체인 인터페이스(ABCI) [17]를 통해. 따라서 ABCI blockchain 애플리케이션을 어떤 방식으로든 프로그래밍할 수 있습니다. 언어는 단순히 합의가 이루어지는 프로그래밍 언어가 아닙니다. 엔진이 작성되어 있습니다. 또한 ABCI를 사용하면 쉽게 기존 blockchain 스택의 합의 계층을 교체합니다. 우리는 잘 알려진 암호화폐인 Bitcoin에 비유합니다. Bitcoin는 각 노드가 유지 관리하는 암호화폐 blockchain입니다. 완전히 감사된 미사용 트랜잭션 출력(UTXO) 데이터베이스. 만약에 하나는 ABCI 위에 Bitcoin과 유사한 시스템을 만들고 싶었습니다. Tendermint Core는 다음을 담당합니다. 노드 간 블록 및 트랜잭션 공유 정식/불변의 거래 순서 확립( blockchain) 그 사이에 ABCI 애플리케이션은 다음을 담당합니다. UTXO 데이터베이스 유지 관리 거래의 암호화 서명 검증 거래가 존재하지 않는 자금을 지출하는 것을 방지 클라이언트가 UTXO 데이터베이스를 쿼리하도록 허용 Tendermint는 blockchain 디자인을 다음과 같이 분해할 수 있습니다. 애플리케이션 프로세스와 애플리케이션 사이에 매우 간단한 API를 제공합니다. 합의 과정.

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 throughput vs block size benchmarked across 64 nodes in 7 datacenters on 5 continents

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 아키텍처

Cosmos는 독립적인 병렬 blockchain의 네트워크입니다. 각각은 다음과 같은 고전적인 BFT 합의 알고리즘으로 구동됩니다. 텐더민트 1. 이 네트워크의 첫 번째 blockchain은 Cosmos 허브가 됩니다. 는 Cosmos 허브는 다음을 통해 다른 많은 blockchain(또는 영역)에 연결됩니다. 새로운 inter-blockchain 통신 프로토콜. Cosmos 허브 수많은 token 유형을 추적하고 총계를 기록합니다. 연결된 각 영역의 token 수. 토큰은 다음과 같습니다. 한 구역에서 다른 구역으로 안전하고 신속하게 이전됩니다. 구역 간 액체 교환이 필요하지 않습니다. 존 간 코인 전송은 Cosmos 허브를 통해 이루어집니다. 이 아키텍처는 blockchain 공간이 안고 있는 많은 문제를 해결합니다. 애플리케이션 상호 운용성, 확장성 및 원활한 업그레이드. 예를 들어 Bitcoind에서 파생된 영역은 Go-Ethereum, CryptoNote, ZCash 또는 모든 blockchain 시스템은 Cosmos 허브에 연결하세요. 이 영역에서는 Cosmos이(가) 다음을 수행할 수 있습니다. 글로벌 트랜잭션 수요를 충족하기 위해 무한한 확장이 가능합니다. 구역은 또한 다음과 같이 지원될 분산형 교환을 위한 훌륭한 yt입니다. 음. Cosmos는 단순한 분산 원장이 아니며, Cosmos 허브는 벽으로 둘러싸인 정원이나 우주의 중심이 아닙니다. 우리는 분산 원장의 개방형 네트워크를 위한 프로토콜 설계 미래 금융시스템의 새로운 기반이 될 수 있는 암호화 원칙, 건전한 경제, 합의를 바탕으로 이론, 투명성, 책임. Cosmos 허브는 Cosmos의 첫 번째 공개 blockchain입니다. Tendermint의 BFT 합의 알고리즘으로 구동되는 네트워크. 는 Tendermint 오픈 소스 프로젝트는 2014년에 탄생했습니다. Bitcoin 작업 증명 합의 알고리즘의 속도, 확장성 및 환경 문제. 검증된 기술을 활용하고 개선함으로써

BFT 1988년 MIT에서 개발된 알고리즘 [20], Tendermint 팀은 proof-of-stake을 개념적으로 시연한 최초의 팀이었습니다. 무관계 문제를 해결하는 암호화폐 1세대 proof-of-stake 암호화폐로 인해 어려움을 겪고 있습니다. NXT 및 BitShares1.0으로. 오늘날 거의 모든 Bitcoin 모바일 지갑은 신뢰할 수 있는 서버를 사용하여 거래 확인을 제공합니다. 이는 작업 증명이 완료되기 전에 많은 확인을 기다려야 하기 때문입니다. 트랜잭션은 되돌릴 수 없게 커밋된 것으로 간주될 수 있습니다. Doublespend 공격은 다음과 같은 서비스에서 이미 입증되었습니다. 코인베이스. 다른 blockchain 합의 시스템과 달리 Tendermint는 다음을 제공합니다. 즉각적이고 안전한 모바일 클라이언트 결제 확인. Tendermint는 절대 포크되지 않도록 설계되었기 때문에 모바일에서는 지갑은 즉시 거래 확인을 받을 수 있습니다. 신뢰할 수 없고 실용적인 결제가 스마트폰에서 현실이 되었습니다. 이 다음과 같이 사물 인터넷 애플리케이션에 상당한 영향을 미치고 있습니다. 음. Cosmos의 검증인은 Bitcoin 채굴자와 비슷한 역할을 가지고 있지만 대신 암호화 서명을 사용하여 투표하세요. 검증인은 커밋을 담당하는 안전한 전용 머신 블록. validator이 아닌 사람은 자신의 staking token(라고 함)을 위임할 수 있습니다. “atoms”)를 validator에 보내 블록 수수료와 아톰의 일부를 얻으세요 보상을 제공하지만, 다음과 같은 경우 처벌(삭감)을 받을 위험이 있습니다. 대리인 validator이(가) 해킹당하거나 프로토콜을 위반합니다. 입증된 Tendermint BFT 합의의 안전 보장 및 담보 이해관계자 예치금–validators 및 위임자–제공 노드와 라이트 클라이언트를 위한 입증 가능하고 수량화 가능한 보안. 분산 공공 원장은 헌법과 거버넌스 시스템. Bitcoin은(는) Bitcoin 재단에 의존하며업그레이드를 조정하기 위해 마이닝을 수행하지만 이는 느린 프로세스입니다. Ethereum 주소를 하드포크한 후 ETH와 ETC로 분할 DAO 해킹, 주로 사전 사회 계약이 없었기 때문입니다. 그러한 결정을 내리는 메커니즘도 없습니다. Cosmos 허브의 검증인과 위임자는 투표할 수 있습니다. 시스템의 미리 설정된 매개변수를 변경할 수 있는 제안 자동으로(예: 블록 가스 한도) 업그레이드 조정 인간이 읽을 수 있는 헌법 개정안에 투표할 수도 있습니다. Cosmos 허브의 정책을 관리합니다. 헌법 다음과 같은 문제에 대해 이해관계자 간의 결속력을 허용합니다. 도난 및 버그(예: TheDAO 사건)를 방지하여 더 빠르고 더 깨끗한 해상도. 각 영역은 자체 구성과 거버넌스를 가질 수도 있습니다. 메커니즘도 그렇고. 예를 들어, Cosmos 허브에는 허브에서 불변성을 강제하는 헌법(롤백 없음, Cosmos 허브 노드 구현의 버그를 위해 저장) 각 영역은 롤백과 관련된 자체 정책을 설정할 수 있습니다. 서로 다른 정책 영역 간의 상호 운용성을 가능하게 함으로써 Cosmos 네트워크는 사용자에게 궁극적인 자유와 잠재력을 제공합니다. 무허가 실험. 여기서 우리는 분산화와 확장성의 새로운 모델을 설명합니다. Cosmos는 다음을 기반으로 하는 많은 blockchain의 네트워크입니다. 텐더민트. 기존 제안은 '단일'을 만드는 것을 목표로 하고 있지만 blockchain”(총 글로벌 트랜잭션 주문 포함), Cosmos 많은 blockchain이 서로 동시에 실행되도록 허용합니다. 상호 운용성을 유지하면서. 기본적으로 Cosmos 허브는 많은 독립적인 서비스를 관리합니다. blockchain는 "영역"이라고 합니다(때때로 "샤드"라고도 함). "샤딩"으로 알려진 데이터베이스 확장 기술 참조).

게시된 영역에서 최근 블록 커밋의 지속적인 스트림 허브를 사용하면 허브가 각 영역의 상태를 따라갈 수 있습니다. 마찬가지로 각 영역은 허브의 상태를 따라갑니다(그러나 영역은 간접적인 방법 외에는 서로 연락을 유지하지 마십시오. 허브). 그런 다음 정보 패킷이 한 곳에서 전달됩니다. Merkle 증명을 증거로 게시하여 다른 영역으로 영역을 확장합니다. 정보가 전송되고 수신되었습니다. 이 메커니즘을 inter-blockchain 통신 또는 줄여서 IBC입니다. 모든 영역은 그 자체로 비순환 그래프를 형성하는 허브가 될 수 있습니다. 하지만 명확성을 위해 간단한 내용만 설명하겠습니다. 허브는 하나만 있고 허브가 아닌 많은 구성 구역. Cosmos 허브는 다중 자산을 호스팅하는 blockchain입니다. token을 개인 사용자가 보유할 수 있는 분산 원장 또는 영역 자체별로. 이 token은 하나의 영역에서 이동할 수 있습니다. "코인 패킷"이라고 불리는 특별한 IBC 패킷을 통해 다른 사람에게 전달됩니다. 허브는 전체의 전역 불변성을 보존하는 역할을 담당합니다. 영역 전체에 걸쳐 각 token의 양. IBC 코인 패킷 트랜잭션은 송신자, 허브 및 수신자에 의해 커밋되어야 합니다. blockchains.Cosmos 허브는 전체에 대한 중앙 원장 역할을 하기 때문에 시스템에서는 허브의 보안이 가장 중요합니다. 동안 각 영역은 다음과 같이 보호되는 Tendermint blockchain일 수 있습니다. 4개(또는 BFT 합의가 필요하지 않은 경우 더 적음), 허브 전 세계적으로 분산된 validator 세트로 보호되어야 합니다. 다음과 같은 가장 심각한 공격 시나리오를 견딜 수 있습니다. 대륙 네트워크 분할 또는 국가 후원 공격. Cosmos 영역은 IBC를 교환하는 독립적인 blockchain입니다. 허브와의 메시지. 허브의 관점에서 구역은 다중 자산 동적 멤버십 다중 서명 계정 IBC 패킷을 사용하여 token을 보내고 받을 수 있습니다. 처럼 암호화폐 계정, 영역은 다음보다 더 많은 token을 전송할 수 없습니다. 가지고 있지만 그것을 가지고 있는 다른 사람으로부터 token을(를) 받을 수 있습니다. A 구역 하나 이상의 token 유형의 "소스"로 지정될 수 있습니다. token 공급량을 주입할 수 있는 권한을 부여합니다. Cosmos 허브의 아톰은 영역의 validator에 스테이킹될 수 있습니다. 허브에 연결되었습니다. 이 영역에 대한 이중 지출 공격이 발생하는 동안 투표권의 ⅔ 이상이 있는 영역인 Tendermint의 포크 책임으로 인해 원자가 삭감될 수 있습니다. 비잔틴은 잘못된 상태를 커밋할 수 있습니다. Cosmos 허브는 그렇지 않습니다 다른 영역에서 커밋된 트랜잭션을 확인하거나 실행하므로 신뢰할 수 있는 영역에 token을 보내는 것은 사용자의 책임입니다. 앞으로 Cosmos 허브의 거버넌스 시스템은 허브를 통과할 수 있습니다. 영역 오류를 설명하는 개선 제안. 에 대한 예를 들어 일부(또는 전체) 영역에서 아웃바운드 token 전송이 발생할 수 있습니다. 구역의 비상 회로 차단을 허용하도록 조절됩니다. (token 전송이 일시적으로 중단됨) 공격이 감지되면 이제 허브와 영역이 서로 통신하는 방법을 살펴보겠습니다. 기타. 예를 들어 blockchain이 3개 있는 경우 "Zone1", "Zone2",

Cosmos hub and zones architecture showing the Cosmos Hub connecting multiple independent zones via IBC

그리고 “Hub”, 그리고 우리는 “Zone1”이 목적지로 향하는 패킷을 생성하기를 원합니다. “Hub”를 통과하는 “Zone2”에 대해. 한 곳에서 패킷을 이동하려면 blockchain 다른 사람에게 증거가 수신 체인에 게시됩니다. 증거는 전송 체인이 다음을 위한 패킷을 게시했음을 나타냅니다. 목적지 추정. 수신 체인이 이 증명을 확인하려면 발신자의 블록 헤더를 따라갈 수 있어야 합니다. 이 메커니즘은 사이드체인에서 사용되는 것과 유사합니다. 두 개의 상호 작용하는 체인은 다음을 통해 서로를 인식합니다. 존재 증명 데이터그램의 양방향 스트림 (거래). IBC 프로토콜은 두 가지 유형의 프로토콜을 사용하여 자연스럽게 비활성화될 수 있습니다. 트랜잭션: IBCBlockCommitTx 트랜잭션을 허용합니다. blockchain는 가장 최근 블록-hash의 관찰자에게 증명하기 위해, 및 IBCPacketTx  트랜잭션을 통해 blockchain을(를) 수행할 수 있습니다. 주어진 패킷이 실제로 게시되었음을 모든 관찰자에게 증명합니다. 발신자의 신청에 따라 Merkle-proof을 통해 최근 블록-hash. IBC 메커니즘을 두 개의 개별 트랜잭션으로 분할함으로써 우리는 수신 체인의 기본 수수료 시장 메커니즘을 허용합니다. 어떤 패킷이 커밋(즉, 승인)되는지 결정합니다. 전송 체인에 대해 완전한 자유를 허용합니다. 많은 아웃바운드 패킷이 허용됩니다. 위의 예에서는 "Zone1"의 블록-hash을 업데이트하기 위해 '허브'(또는 'Zone2'의 '허브')에서 IBCBlockCommitTx거래는 블록-hash과 함께 "허브"에 게시되어야 합니다. “Zone1”(또는 “Hub”의 블록이 hash인 “Zone2”). 자세한 내용은 IBCBlockCommitTx 및 IBCPacketTx를 참조하세요. 두 가지 IBC 거래 유형에 대해 Bitcoin이 분산되어 있어 더 안전한 것과 마찬가지로, 대량 복제 원장을 사용하면 교환의 취약성을 줄일 수 있습니다. blockchain에서 실행하여 외부 및 내부 해킹을 수행합니다. 우리 이것을 분산 교환이라고 부릅니다. 암호화폐 커뮤니티가 분산화라고 부르는 것 오늘날의 거래소는 "원자 교차 체인"(AXC) 거래를 기반으로 합니다. AXC 트랜잭션을 사용하면 두 명의 사용자가 두 개의 다른 체인은 두 개의 전송 트랜잭션을 만들 수 있습니다. 두 원장 모두에 함께 커밋되거나 전혀 커밋되지 않습니다(예: 원자적으로). 예를 들어, 두 명의 사용자가 비트코인을 이더(또는 두 개의 서로 다른 원장에 있는 두 개의 token) AXC 트랜잭션을 사용하여 Bitcoin 및 Ethereum이 각각 연결되어 있지 않더라도 기타. AXC 거래에서 거래소를 운영하면 얻을 수 있는 이점은 다음과 같습니다. 두 사용자 모두 서로를 신뢰하거나 거래 매칭을 신뢰할 필요가 없습니다. 서비스. 단점은 양측 모두 온라인 상태여야 한다는 것입니다. 거래가 발생합니다. 또 다른 유형의 탈중앙화 거래소는 대량 복제 거래소입니다. 자체적으로 실행되는 분산 교환 blockchain. 사용자 이러한 종류의 교환은 지정가 주문을 제출하고 전환할 수 있습니다. 컴퓨터가 꺼져 있으면 사용자가 없어도 거래가 실행될 수 있습니다. 온라인. blockchain이(가) 대신하여 거래를 일치시키고 완료합니다. 상인의.

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",

Cosmos hub and zones architecture showing the Cosmos Hub connecting multiple independent zones via IBC

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.

응용

중앙 집중식 거래소는 한도가 높은 주문서를 생성할 수 있습니다. 주문을 통해 더 많은 거래자를 유치할 수 있습니다. 유동성이 더 많은 것을 낳습니다 거래소 세계에는 유동성이 있어 강력한 네트워크가 있습니다. 교환의 효과(또는 최소한 승자 독식 효과) 사업. 현재 암호화폐 거래소의 선두주자 24시간 거래량이 2,000만 달러에 달하는 Poloniex이며 2위는 24시간 거래량이 500만 달러인 Bitynex. 이처럼 강력한 네트워크를 고려하면 따라서 AXC 기반 탈중앙화 거래소가 중앙화된 거래소를 통해 거래량을 확보하세요. 분산화를 위해 중앙화된 거래소와 경쟁하려면 거래소가 필요합니다. 지정가 주문이 포함된 심층 주문장을 지원합니다. 분산된 것만 blockchain에서 교환하면 이를 제공할 수 있습니다. Tendermint는 더 빠른 거래에 대한 추가적인 이점을 제공합니다. 커밋합니다. 희생 없이 빠른 동시성을 우선시하여 일관성, Cosmos의 영역은 트랜잭션을 빠르게 동기화할 수 있습니다. 교환 주문 거래와 IBC token 이체 모두 그리고 다른 지역에서. 오늘날 암호화폐 거래소의 상황을 고려하면, Cosmos에 대한 애플리케이션은 분산 교환(일명 Cosmos DEX). 거래 처리 능력은 물론이고 커밋 대기 시간은 중앙 집중식 커밋 대기 시간과 비슷할 수 있습니다. 교환. 거래자는 실행 가능한 지정가 주문을 제출할 수 있습니다. 양측 모두 온라인 상태일 필요 없이 말이죠. 그리고 텐더민트와 함께, Cosmos 허브 및 IBC, 거래자는 자금을 들어오고 나갈 수 있습니다. 다른 구역과의 빠른 교환. 권한 있는 영역은 연결된 token의 소스 역할을 할 수 있습니다. 또 다른 암호화폐. 다리는 관계와 비슷하다 Cosmos 허브와 영역 사이 둘 다 따라잡아야 해 token이 갖고 있는 증거를 확인하기 위해 다른 블록의 최신 블록 하나에서 다른 것으로 옮겨졌습니다. Cosmos의 "브리지 영역" 네트워크는 허브뿐만 아니라 다른 허브도 따라잡습니다.

암호화폐. 교량 구역을 통한 간접 연결은 다음을 허용합니다. 다른 사람들에게 단순하고 불가지론적인 상태를 유지하는 허브의 논리 blockchain 합의 전략(예: Bitcoin의 proof-of-work) 광산. 각 브리지 영역 validator은 Tendermint 기반의 blockchain 특수 ABCI 브리지 앱을 사용하지만 전체 노드도 "원산지" blockchain. 새로운 블록이 원점에서 채굴되면 브릿지 존은 validators는 서명을 통해 커밋된 블록에 동의하게 됩니다. 출발지의 blockchain에 대한 각자의 로컬 보기를 공유합니다. 팁. 교량지역이 출발지에서 대금을 수령한 경우(그리고 해당 사건에서 충분한 동의가 확인된 것으로 합의되었습니다. Ethereum 또는 Bitcoin과 같은 PoW 체인의 해당 해당 잔액으로 브리지존에 계정이 생성됩니다. Ethereum의 경우 브리지 존은 동일하게 공유할 수 있습니다. validator-Cosmos 허브로 설정됩니다. Ethereum 쪽( 원산지), 브릿지 계약을 통해 이더 보유자가 이더를 보낼 수 있습니다. 브리지 계약으로 전송하여 브리지 영역으로 이동 Ethereum. 브릿지 계약을 통해 에테르가 수신되면, 적절한 IBC 패킷이 없으면 이더를 인출할 수 없습니다. 교량 구역으로부터 교량 계약에 의해 수신됩니다. 는 bridge-contract는 bridge-zone의 validator 세트를 추적합니다. Cosmos 허브의 validator 세트와 동일할 수 있습니다. Bitcoin의 경우, 대신에 단일 브리지 계약, 각 UTXO은 임계값 다중 서명 P2SH 공개 스크립트. 의 한계로 인해 P2SH 시스템에서는 서명자가 Cosmos와 동일할 수 없습니다. 허브 validator-세트.브리지 영역의 이더(“브리지 에테르”)는 다음으로 전송될 수 있습니다. 그리고 허브에서, 나중에 트랜잭션으로 파괴됩니다. Ethereum의 특정 출금 주소로 보냅니다. IBC 브리지존에서 트랜잭션이 발생했음을 증명하는 패킷 Ethereum 브리지 계약에 게시되어 에테르를 허용할 수 있습니다. 철회됩니다. Bitcoin의 경우 제한된 스크립팅 시스템으로 인해 IBC 코인 전송 메커니즘을 반영하기 위해 difycult를 사용하세요. 각 UTXO 자체 독립적인 출판물이 있으므로 모든 UTXO은(는) 세트가 변경되면 새로운 UTXO로 마이그레이션되었습니다. Bitcoin 에스크로 서명자. 한 가지 해결책은 압축하고 총 개수를 유지하기 위해 필요에 따라 UTXO 세트의 압축을 풉니다. UTXOs가 다운되었습니다. 이러한 브리지 계약의 위험은 악성 validator 세트입니다. ≥⅓ 비잔틴 투표권으로 인해 포크가 발생하여 이더가 인출될 수 있습니다. 브리지 영역에 브리지 디더를 유지하면서 Ethereum의 브리지 계약에서. 더 나쁜 것은 >⅔ 비잔틴 투표권이 브릿지 컨트랙트에 보낸 사람에게서 이더를 노골적으로 훔칩니다. 브리지 존의 원래 브리지 논리에서 벗어났습니다. 교량을 다음과 같이 설계함으로써 이러한 문제를 해결할 수 있습니다. 전적으로 책임이 있습니다. 예를 들어 허브와 허브의 모든 IBC 패킷 출발지에서는 교량 구역의 승인이 필요할 수 있습니다. 브리지 영역의 모든 상태 전환이 가능하도록 하는 방식 허브나 원본에서 효율적으로 이의를 제기하고 검증합니다. 브리지 계약. 허브와 오리진은 브리지존 validator이 담보를 게시하고 token이 외부로 전송되도록 허용해야 합니다. 브릿지 계약을 연기해야 합니다(그리고 담보를 해제해야 합니다). 충분히 긴 기간) 독립 감사인. 우리는 사양의 디자인을 남겨두고 이 시스템의 구현은 미래로 공개됩니다 Cosmos

Cosmos 허브에서 통과될 개선 제안 거버넌스 시스템. 확장 문제를 해결하는 것은 Ethereum에 대한 공개 문제입니다. 현재 Ethereum 노드는 모든 단일 트랜잭션을 처리하고 또한 모든 상태를 저장합니다. 링크. Tendermint는 Ethereum보다 훨씬 빠르게 블록을 커밋할 수 있기 때문에 proof-of-work, EVM Tendermint 합의로 구동되는 영역 및 브리지 에테르에서 작동하면 더 높은 성능을 제공할 수 있습니다. Ethereum blockchains. 또한 Cosmos 허브 및 IBC 패킷 메커니즘은 임의의 계약 논리를 허용하지 않습니다. 실행 자체는 token 움직임을 조정하는 데 사용될 수 있습니다. 서로 다른 영역에서 실행되는 Ethereum 계약 간, 다음을 통해 token 중심 Ethereum 확장을 위한 기반 제공 샤딩. Cosmos 영역은 다음에서 정의되는 임의의 응용 프로그램 논리를 실행합니다. 영역 수명의 시작이며 잠재적으로 업데이트될 수 있습니다. 시간이 지남에 따라 거버넌스에 의해. 이러한 zexibility를 통해 Cosmos 영역은 다음을 수행할 수 있습니다. Ethereum와 같은 다른 암호화폐에 대한 브리지 역할을 하거나 Bitcoin 및 해당 blockchain의 파생 상품도 허용합니다. 동일한 코드베이스를 활용하지만 다른 validator 세트와 초기 배포. 이는 기존의 많은 암호화폐를 허용합니다. Ethereum, Zerocash, Bitcoin와 같은 프레임워크, CryptoNote 등이 Tendermint Core와 함께 사용됩니다. 공통 네트워크에서 더 높은 성능의 합의 엔진, 상호 운용성을 위한 엄청난 기회를 열어줍니다. 플랫폼. 또한 다중 자산 blockchain으로서 단일 트랜잭션에는 여러 개의 입력과 출력이 포함될 수 있습니다. 입력은 token 유형이 될 수 있으며, Cosmos을 직접 사용할 수 있습니다. 주문이 가정되지만 분산형 교환을 위한 플랫폼다른 플랫폼을 통해 매칭됩니다. 또는 영역이 게재될 수 있습니다. 분산된 내결함성 교환(주문서 포함)으로, 기존 중앙 집중식에 비해 크게 개선될 수 있습니다. 시간이 지남에 따라 해킹당하는 경향이 있는 암호화폐 거래소. 영역은 blockchain 지원되는 엔터프라이즈 버전으로도 사용할 수 있습니다. 특정 서비스의 일부가 전통적으로 조직이나 조직 그룹에 의해 운영됩니다. 대신 특정 영역에서 ABCI 애플리케이션으로 실행됩니다. 대중의 보안과 상호 운용성을 상속할 수 있습니다. Cosmos 네트워크에 대한 제어권을 희생하지 않고 서비스. 따라서 Cosmos은 두 세계의 장점을 모두 제공할 수 있습니다. blockchain 기술을 활용하려고 하지만 실제로는 그렇지 않은 조직 분산된 제3자에게 통제권을 완전히 양도하는 것을 조심하세요. 파티. 일부에서는 일관성을 선호하는 데 큰 문제가 있다고 주장합니다. Tendermint와 같은 합의 알고리즘은 모든 네트워크에서

⅔인 단일 파티션이 없게 만드는 파티션 투표권(예: ≥⅓이 진에 참여)은 합의를 완전히 중단시킵니다. Cosmos 아키텍처는 다음을 사용하여 이 문제를 완화하는 데 도움이 될 수 있습니다. 투표권이 있는 지역 자치 구역을 갖춘 글로벌 허브 각 영역에 대해 공통 지리적 기반을 기반으로 배포됩니다. 지역. 예를 들어, 공통 패러다임은 개인에 대한 것일 수 있습니다. 도시나 지역을 공유하면서 자체 존을 운영할 수 있습니다. 공통 허브(예: Cosmos 허브)를 통해 지방자치 활동을 가능하게 합니다. 임시 네트워크로 인해 허브가 중단되는 경우에도 지속됩니다. 파티션. 이는 실제 지질학적, 정치적, 견고한 설계 시 고려해야 할 네트워크 토폴로지 특징 연합 내결함성 시스템.

NameCoin은 문제를 해결하려고 시도한 최초의 blockchain 중 하나였습니다. Bitcoin blockchain을 적용하여 이름 확인 문제가 발생했습니다. 불행하게도 이 접근 방식에는 몇 가지 문제가 있었습니다. Namecoin을 사용하면 예를 들어 @satoshi가 과거 어느 시점에 특정 공개 키로 등록된 경우 하지만 그 이후 공개 키가 존재했는지 여부는 알 수 없습니다. 마지막 이후 모든 블록을 다운로드하지 않는 한 최근에 업데이트되었습니다. 그 이름의 업데이트. 이는 Bitcoin의 제한 때문입니다. UTXO 트랜잭션 Merkle-ization 모델, 여기서는 트랜잭션(변경 가능한 애플리케이션 상태는 아님)이 Merkle화되었습니다. 블록-hash에 들어갑니다. 이를 통해 존재를 증명할 수 있지만 이후 이름 업데이트가 존재하지 않는다는 것은 증명할 수 없습니다. 그러므로 우리는 알 수 없다. 전체를 신뢰하지 않고 이름의 가장 최근 값을 확실하게 노드를 다운로드하거나 대역폭에 상당한 비용이 발생합니다. 전체 blockchain. NameCoin에 Merkle화된 검색 트리를 구현하더라도, proof-of-work에 대한 종속성은 가벼운 클라이언트 확인을 만듭니다. 문제가 있다. 라이트 클라이언트는 전체 사본을 다운로드해야 합니다. 전체 blockchain(또는 적어도 모든 블록)의 모든 블록에 대한 헤더 이름에 대한 마지막 업데이트 이후의 헤더). 이는 다음을 의미합니다. 대역폭 요구 사항은 시간에 따라 선형적으로 확장됩니다. [21]. 또한 proof-of-work blockchain의 이름 변경 추가 proof-of-work 확인 블록을 기다려야 합니다. Bitcoin에서는 최대 1시간이 걸릴 수 있습니다. Tendermint를 사용하려면 가장 최근 블록인 hash만 있으면 됩니다. validators 정족수(투표권으로)에 의해 서명되었으며 Merkle 이름과 관련된 현재 값에 대한 증거. 이것은 그것을 만든다 간결하고 빠르며 안전한 라이트 클라이언트를 가질 수 있습니다 이름 값 확인. Cosmos에서는 이 개념을 더 확장할 수 있습니다. 각각 Cosmos의 이름 등록 영역은 ".com" 또는 ".org"와 같은 연관된 최상위 도메인(TLD) 이름을 가질 수 있으며 각 이름은

등록 구역은 자체 거버넌스와 등록을 가질 수 있습니다. 규칙.

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.

거버넌스와 경제

Cosmos 허브는 다중 자산 분산 원장이지만 다음이 있습니다. 원자라고 불리는 특별한 기본 token. 원자는 유일한 staking Cosmos 허브의 token. 아톰은 보유자가 다음을 수행할 수 있는 라이선스입니다. 다른 validator에 투표하고, 검증하고, 위임하세요. Ethereum처럼 에테르, 아톰은 거래 수수료를 지불하는 데에도 사용될 수 있습니다. 스팸을 완화하세요. 추가적인 Inzationary Atom 및 블록 트랜잭션 수수료는 validators 및 위임한 위임자에게 보상됩니다. validators.  BurnAtomTx  거래는 모든 것을 복구하는 데 사용될 수 있습니다. 예비 풀에서 비례적인 양의 tokens. 창세기에서 원자 tokens 및 validators의 초기 분포 Cosmos 모금 행사의 기부자(75%), 주요 기부자에게 전달됩니다. (5%), Cosmos Network Foundation (10%) 및 ALL IN BITS, Inc (10%). 창세기부터 전체 원자량의 1/3이 매년 결속된 validator 및 위임자에게 보상을 받습니다. 자세한 내용은 Cosmos 계획을 참조하세요. Bitcoin 또는 다른 proof-of-work blockchain과 달리 Tendermint는 blockchain은 증가된 validator로 인해 속도가 느려집니다. 통신 복잡성. 다행히도 우리는 충분히 지원할 수 있습니다 validators는 전 세계적으로 분산된 강력한 blockchain을 만들기 위한 것입니다. 매우 빠른 트랜잭션 확인 시간과 대역폭으로서

스토리지와 병렬 컴퓨팅 용량이 늘어나면 다음과 같은 일이 가능해질 것입니다. 앞으로 더 많은 validator을 지원합니다. 생성일에는 최대 validator 수가 다음으로 설정됩니다. 100이고, 이 숫자는 10년 동안 13%의 비율로 증가할 것입니다. 300 validators에 정착합니다. 아직 Atom 보유자가 아닌 경우 다음을 통해 validator이 될 수 있습니다. BondTx 거래에 서명하고 제출합니다. 금액 담보로 제공되는 원자는 0이 아니어야 합니다. 누구나 될 수 있다 a validator, 현재 크기가 validator 세트가 최대 validator 수보다 큽니다. 허용됩니다. 이 경우 해당 거래는 해당 금액만큼만 유효합니다. 원자가 보유하고 있는 유효 원자의 양보다 크다. 가장 작은 validator, 여기서 유효 원자에는 위임된 원자가 포함됩니다. 이러한 방식으로 새로운 validator이 기존 validator을 대체하면, 기존 validator은 비활성화되고 모든 원자와 위임된 원자는 결합 해제 상태로 들어갑니다. 어떤 경우에도 validator에 약간의 벌금이 부과되어야 합니다. 의도적이거나 의도하지 않은 제재 조치로부터의 이탈 프로토콜. 일부 증거는 즉시 인정될 수 있습니다. 동일한 높이와 원형으로 이중 서명을 하거나 다음 사항을 위반하는 경우 0년차: 100  1년차: 113  2년차: 127  3년차: 144  4년차: 163  5년차: 184  6년차: 208  7년차: 235  8년차: 265  9년차: 300  10년차: 300  ...

"prevote-the-lock"(Tendermint 합의 프로토콜의 규칙). 이러한 증거로 인해 validator은(는) 좋은 평판을 잃게 됩니다. 그리고 그것의 결합된 원자뿐만 아니라 tokens의 비례적인 몫도 포함됩니다. 집합적으로 "스테이크"라고 불리는 예비 풀은 삭감됩니다. 때로는 지역적 문제로 인해 validator을 사용할 수 없는 경우도 있습니다. 네트워크 중단, 정전 또는 기타 이유. 만약, 혹시라도 과거  ValidatorTimeoutWindow 블록, validator의 시점을 가리킵니다. 커밋 투표는 blockchain에 포함되지 않습니다.  ValidatorTimeoutMaxAbsent 회, 해당 validator는 다음과 같습니다. 비활성화되고 ValidatorTimeoutPenalty(기본값 1%)가 손실됩니다. 스테이크. 일부 "악의적인" 행동은 명확하게 식별할 수 없는 결과를 낳습니다. blockchain에 대한 증거. 이러한 경우 validator은 다음을 수행할 수 있습니다. 대역 외 조정을 통해 이러한 악성 코드의 시간 초과를 강제합니다. validators, 압도적인 합의가 있는 경우. ≥⅓ 연합으로 인해 Cosmos 허브가 중단되는 상황에서 투표권이 사라지거나 ≥⅓ 연합이 있는 상황에서 투표권 검열을 통해 악의적인 행위에 대한 증거를 검열합니다. blockchain를 입력하면 허브는 하드포크로 복구되어야 합니다. 재구성 제안. (“포크 및 검열 공격” 링크) Cosmos 허브 validators는 모든 token 유형 또는 조합을 허용할 수 있습니다. 거래 처리에 대한 수수료 유형입니다. 각 validator은(는) 원하는 환율을 주관적으로 설정하고 선택하세요. BlockGasLimit가 다음인 한 원하는 거래는 무엇이든 가능합니다. 초과하지 않았습니다. 아래에 명시된 세금을 제외한 징수된 수수료는 담보된 이해관계자들에게 비율에 따라 재분배됩니다. ValidatorPayoutPeriod마다 결합된 원자(기본값 1 시간).징수된 거래 수수료 중 ReserveTax(기본 2%)는 예비 풀 쪽으로 가서 예비 풀을 늘리고 Cosmos 네트워크의 보안과 가치를 높입니다. 이것들 결정에 따라 자금을 분배할 수도 있습니다. 거버넌스 시스템에 의해 만들어졌습니다. 자신의 투표권을 다른 validator에게 위임하는 Atom 보유자 위임받은 validator에게 수수료를 지불하세요. 위원회는 다음을 수행할 수 있습니다. validator마다 설정됩니다. Cosmos 허브의 보안은 허브의 보안 기능입니다. 기본 validator 및 위임자의 위임 선택. 발견된 물질의 발견과 조기 보고를 장려하기 위해 취약점, Cosmos 허브는 해커가 게시하도록 권장합니다. 다음과 같은  ReportHackTx  트랜잭션을 통한 성공적인 악용 validator이 해킹당했습니다. 이 주소로 포상금을 보내주세요.” 시 이러한 악용으로 인해 validator 및 위임자는 비활성화됩니다.  모든 사람의 아톰의 HackPunishmentRatio(기본값 5%)는 슬래시 및 모든 원자의 HackRewardRatio(기본값 5%) 해커의 바운티 주소로 보상을 받게 됩니다. validator 백업 키를 사용하여 나머지 Atom을 복구해야 합니다. 이 기능이 남용되어 전송되는 것을 방지하기 위해 미확정 원자, 미확정 원자와 미확정 원자의 부분 ReportHackTx 전후의 validator 및 위임자는 동일하게 유지되며 해커 현상금에는 일부가 포함됩니다. 미확정 원자(있는 경우). Cosmos 허브는 분산 조직에 의해 운영됩니다. 이를 위해서는 잘 정의된 거버넌스 메커니즘이 필요합니다. 변수와 같은 blockchain에 대한 다양한 변경 사항을 조정합니다.

시스템의 매개 변수뿐만 아니라 소프트웨어 업그레이드 및 헌법 개정. 모든 validator은 모든 제안에 대한 투표를 담당합니다. 실패 적시에 제안에 투표하면 validator 결과가 발생합니다. 일정 시간 동안 자동으로 비활성화됩니다.  결석 처벌 기간(기본값 1주). 위임자는 위임자의 투표를 자동으로 상속받습니다. validator. 이 투표는 수동으로 무시될 수 있습니다. 결합되지 않은 원자 투표하지 마세요. 각 제안서에는 MinimumProposalDeposit의 보증금이 필요합니다.  tokens(하나 이상의 tokens 조합일 수 있음) 원자를 포함하여. 각 제안에 대해 유권자는 투표를 통해 다음을 선택할 수 있습니다. 보증금. 유권자의 과반수 이상이 투표를 선택하는 경우 예치금(예: 제안이 스팸이었기 때문에), 예치금은 연소된 원자를 제외한 예비 풀. 각 제안에 대해 유권자는 다음 옵션을 선택하여 투표할 수 있습니다. 응 그래위드포스 아니 아니위드포스 기권 찬성 또는 YeaWithForce 투표의 절대 다수(또는 반대 또는 NayWithForce 투표)는 제안이 다음과 같이 결정되는 데 필요합니다. 통과(또는 실패로 결정)되었지만 1/3 이상이 다수를 거부할 수 있음 "강력하게" 투표하여 결정합니다. 절대 다수가 거부권을 행사하면, 모든 사람은 VetoPenaltyFeeBlocks를 잃음으로써 처벌을 받습니다.  (기본 1일 블록) 상당의 수수료(세금 제외) 영향을 받지 않음) 및 대다수를 거부한 당사자

결정은 VetoPenaltyAtoms 상실로 추가 처벌을 받게 됩니다.  (기본값 0.1%) 원자의 수입니다. 여기에 정의된 모든 매개변수는 다음을 사용하여 변경할 수 있습니다.  ParameterChangeProposal 을 전달합니다. 원자는 인젝션될 수 있으며 풀 자금을 다음과 같이 사용할 수 있습니다.  BountyProposal  전달. 프로토콜 업그레이드 제안 등 기타 모든 제안은 일반 TextProposal을 통해 조정됩니다. 계획을 참조하십시오. blockchain 합의에는 많은 혁신이 있었고 지난 몇 년간의 확장성. 이 섹션에서는 간략한 설명을 제공합니다. 중요한 항목을 선정하여 조사합니다. 악의적 참여자 존재에 대한 합의가 문제 Leslie Lamport가 이 용어를 만들었던 1980년대 초로 거슬러 올라갑니다. "비잔틴 결함"이라는 문구는 임의의 프로세스 동작을 나타냅니다. "충돌 결함"과 달리 의도된 동작에서 벗어납니다. 여기서 프로세스는 단순히 충돌합니다. 초기 솔루션이 발견되었습니다. 상한이 있는 동기 네트워크의 경우실제 사용은 매우 제한되었지만 메시지 대기 시간 비행기 컨트롤러와 같은 통제된 환경 원자 시계를 통해 동기화되는 데이터 센터. 그때까지는 아니었지만 Practical Byzantine Fault Tolerance(PBFT) [11]이 있었던 90년대 후반 효율적인 부분 동기식 합의로 도입되었습니다. 최대 1/3의 프로세스 동작을 허용할 수 있는 알고리즘 임의로. PBFT은 표준 알고리즘이 되어 많은 알고리즘을 생성했습니다. 가장 최근에 IBM이 다음의 일부로 만든 변형을 포함한 변형 Hyperledger에 대한 기여. PBFT에 대한 Tendermint 합의의 주요 이점은 다음과 같습니다. Tendermint는 개선되고 단순화된 기본 구조를 가지고 있습니다. 그 중 일부는 blockchain 패러다임을 수용한 결과입니다. Tendermint 블록은 순서대로 커밋해야 합니다. PBFT과 관련된 복잡성 및 통신 오버헤드 보기 변경. Cosmos 및 많은 암호화폐에는 블록 N이 커밋될 때 i >= 1인 블록 N+i를 허용해야 합니다. 자체는 아직 커밋되지 않았습니다. 대역폭이 N을 차단하는 이유라면 Cosmos 영역에 커밋하지 않았다면 사용하는 데 도움이 되지 않습니다. N+i 블록에 대한 대역폭 공유 투표. 네트워크 파티션 또는 ofzine 노드는 블록 N이 커밋되지 않은 이유입니다. N+i는 어쨌든 커밋하지 않습니다. 또한 트랜잭션을 블록으로 일괄 처리하면 다음과 같은 이점이 있습니다. 대신 애플리케이션 상태의 일반 Merkle-hashing PBFT의 체크포인트 체계와 마찬가지로 주기적 다이제스트. 이를 통해 라이트 클라이언트를 위한 보다 빠른 증명 가능한 트랜잭션 커밋을 위해 inter-blockchain 통신. Tendermint Core에는 다양한 최적화 및 기능도 포함되어 있습니다. PBFT에 명시된 것 이상입니다. 예를 들어, validators가 제안한 블록은 Merkle화되어 여러 부분으로 분할됩니다. 방송을 개선하는 방식으로 험담을 했습니다. 성능(영감을 얻으려면 LibSwift [19] 참조). 또한 텐더민트는 Core는 Point-to-Point에 대해 어떠한 가정도 하지 않습니다.

P2P 네트워크가 있는 한 연결 및 기능은 약하게 연결되어 있습니다. proof-of-stake(PoS)을 배포한 최초는 아니지만 BitShares1.0 [12] PoS 연구 및 채택에 크게 기여 blockchain, 특히 "위임된" PoS로 알려진 것입니다. 에서 BitShares, 지분 보유자는 주문을 담당하는 "증인"을 선출합니다. 거래를 커밋하고 "대리인"이 책임을 집니다. 소프트웨어 업데이트 및 매개변수 변경 조정. BitShares2.0은 고성능(100k tx/s, 1s) 달성을 목표로 합니다. 대기 시간) 이상적인 조건에서 각 블록은 단일 서명으로 서명됩니다. 서명자 및 트랜잭션 연속성은 서명자보다 꽤 오래 걸립니다. 블록 간격. 정식 사양은 아직 개발 중입니다. 이해관계자는 잘못된 행동을 하는 증인을 제거하거나 교체할 수 있습니다. 매일매일, 그러나 증인이나 중요한 담보가 없습니다. Tendermint PoS와 유사한 위임자가 삭제됩니다. 이중지불 공격이 성공한 경우. Ripple이 개척한 접근 방식을 기반으로 Stellar [13]은 프로세스가 진행되는 Federated Byzantine Agreement 모델 합의에 참여하는 것은 yxed 및 전 세계적으로 구성되지 않습니다. 알려진 세트. 오히려 각 프로세스 노드는 하나 이상의 "쿼럼 슬라이스"는 각각 신뢰할 수 있는 프로세스 집합을 구성합니다. 에이 Stellar의 "쿼럼"은 다음을 포함하는 노드 집합으로 정의되었습니다. 집합의 각 노드에 대해 최소 하나의 쿼럼 슬라이스 합의가 이루어질 수 있습니다. Stellar 메커니즘의 보안은 다음 가정에 의존합니다. 두 정원회의 교차점은 비어 있지 않은 반면, 노드를 사용하려면 최소한 하나의 쿼럼 슬라이스가 필요합니다. 완전히 올바른 노드로 구성되어 균형을 맞추기 어려울 수 있는 크거나 작은 쿼럼 슬라이스 사용 신뢰에 대해 중요한 가정을 부과하지 않고. 궁극적으로,노드는 어떻게든 적절한 쿼럼 슬라이스를 선택해야 합니다. 충분한 내결함성(또는 "온전한 노드")이 있어야 합니다. 논문 결과의 대부분은)에 달려 있으며, 유일한 이러한 구성이 계층적으로 이루어지도록 하기 위한 전략 제공 인터넷의 최상위 ISP가 글로벌 라우팅 테이블을 구축하는 데 사용하는 BGP(Border Gateway Protocol)와 유사합니다. TLS 인증서를 관리하기 위해 브라우저에서 사용하는 것입니다. 둘 다 악명 높은 그들의 불안 때문에. Tendermint 기반 지분 증명 시스템에 대한 Stellar 논문의 비판은 설명된 token 전략에 의해 완화됩니다. 여기에서 원자라고 불리는 새로운 유형의 token이 발행됩니다. 수수료 및 보상의 미래 부분에 대한 청구를 나타냅니다. 는 그렇다면 Tendermint 기반 proof-of-stake의 장점은 상대적입니다. 단순하면서도 충분하고 입증 가능한 보안을 제공합니다. 보증. BitcoinNG는 Bitcoin에 대해 제안된 개선 사항입니다. 블록 크기 증가와 같은 수직 확장성의 형태에 대해 일반적으로 관련된 부정적인 경제적 결과 없이 불균형적으로 큰 영향과 같은 변화로 인해 소규모 광부에서. 이러한 개선은 분리를 통해 달성됩니다. 거래 방송에서 리더 선출: 리더가 첫 번째입니다. "마이크로 블록"에서 proof-of-work에 의해 선출되었으며 다음을 수행할 수 있습니다. 새로운 마이크로 블록이 나올 때까지 커밋되는 브로드캐스트 트랜잭션 발견되었습니다. 이렇게 하면 필요한 대역폭 요구 사항이 줄어듭니다. PoW 경주에서 승리하여 소규모 채굴자들이 더욱 공정하게 경쟁할 수 있도록 하고, 그리고 트랜잭션이 보다 정기적으로 커밋되도록 허용합니다. 마이크로 블록을 발견하는 마지막 광부. 캐스퍼 [16]는 제안된 proof-of-stake 합의 알고리즘입니다. Ethereum. 주요 작동 모드는 "베팅별 합의"입니다. 작성자: validators가 자신이 믿는 블록에 반복적으로 베팅하도록 합니다.

다른 베팅을 바탕으로 blockchain에 전념하게 됩니다. 지금까지 보아온 것처럼 결국에는 동질성이 달성될 수 있습니다. 링크. 이는 Casper 팀이 활발히 연구하고 있는 분야입니다. 는 도전 과제는 다음과 같은 베팅 메커니즘을 구축하는 것입니다. 진화적으로 안정적인 전략임이 입증되었습니다. 주요 혜택 Tendermint와 비교하여 Casper는 "가용성"을 제공할 수 있습니다. 과도한 일관성” – 합의에는 >⅔ 정족수가 필요하지 않습니다. 투표권 – 아마도 커밋 속도를 희생하거나 구현 복잡성. Interledger 프로토콜 [14]은 엄밀히 말하면 확장성 솔루션이 아닙니다. 그것 서로 다른 원장 간의 임시 상호 운용성을 제공합니다. 느슨하게 결합된 양자 관계 네트워크를 통해 시스템을 구축합니다. 라이트닝 네트워크와 마찬가지로 ILP의 목적은 다음과 같습니다. 하지만 특히 서로 다른 결제에 초점을 맞추고 있습니다. 원장 유형을 지정하고 원자 트랜잭션 메커니즘을 다음으로 확장합니다. hash-잠금뿐만 아니라 공증인 정족수(라고 함)도 포함합니다. 원자 전송 프로토콜). 후자의 메커니즘은 원장 간 거래에서 원자성을 적용하는 것은 다음과 유사합니다. Tendermint의 라이트 클라이언트 SPV 메커니즘 ILP와 Cosmos/IBC 간의 구별이 보장됩니다. 아래에 제공됩니다. 1. ILP 커넥터의 공증인은 멤버십을 지원하지 않습니다. 변경하고 사이에 zexible 가중치를 허용하지 않습니다. 공증인. 반면에 IBC은(는) 특별히 다음을 위해 설계되었습니다. blockchains(여기서 validators는 서로 다른 가중치를 가질 수 있음) 회원 자격은 기간 중에 변경될 수 있습니다. blockchain. 2. 라이트닝 네트워크와 마찬가지로 ILP의 결제 수신자는 보낸 사람에게 확인 메시지를 다시 보내려면 온라인 상태여야 합니다. 에서token은 수신기의 validator 세트인 IBC을 통해 전송됩니다. blockchain은(는) 확인 제공을 담당합니다. 받는 사용자. 3. 가장 눈에 띄는 차이점은 ILP의 커넥터가 그렇지 않다는 것입니다. 지불에 대해 책임을 지거나 권위 있는 상태를 유지하는 것, Cosmos에서는 허브의 validator이 다음의 권한입니다. IBC token의 상태 및 이전 권한 각 구역이 보유한 token의 양(그러나 tokens는 영역 내의 각 계정이 보유합니다). 이것은 안전한 비대칭을 가능하게 하는 근본적인 혁신 token을 영역에서 영역으로 전송합니다. ILP와 유사 Cosmos의 커넥터는 지속적이고 최대한 안전합니다. blockchain 원장, Cosmos 허브. 4. ILP의 원장 간 지불은 다음의 지원을 받아야 합니다. 교환 주문서는 비대칭 전송이 없기 때문에 하나의 원장에서 다른 원장으로의 동전, 가치 이전 또는 시장 등가물. 사이드체인 [15]은 Bitcoin 확장을 위해 제안된 메커니즘입니다. "양방향 고정"된 대체 blockchain을 통한 네트워크 Bitcoin blockchain. (양방향 페깅은 다음과 같습니다. 브리징. Cosmos에서는 마켓페깅과 구별하기 위해 "브리징"이라고 말합니다. 사이드체인을 사용하면 비트코인이 사이드체인에서 효과적으로 이동할 수 있습니다. Bitcoin blockchain을 사이드체인과 후면에 연결하고 다음을 허용합니다. 사이드체인의 새로운 기능을 실험합니다. 에서와 같이 Cosmos 허브, 사이드체인 및 Bitcoin은 라이트 클라이언트 역할을 합니다. SPV 증명을 사용하여 코인이 언제 발행되어야 하는지 결정합니다. 사이드체인으로 옮겨졌다가 다시 돌아왔습니다. 물론, Bitcoin 이후로 proof-of-work을 사용하고, Bitcoin을 중심으로 한 사이드체인이 어려움을 겪습니다. proof-of-work의 많은 문제와 위험으로부터 합의 메커니즘. 게다가 이것은 Bitcoin-극대주의자입니다. 다양한 token을 기본적으로 지원하지 않는 솔루션 및

Cosmos과 같은 영역 간 네트워크 토폴로지입니다. 즉 핵심은 양방향 페그의 메커니즘은 원칙적으로 다음과 동일합니다. Cosmos 네트워크에 고용되어 있습니다. Ethereum은 현재 다양한 전략을 연구하고 있습니다. Ethereum blockchain의 상태를 샤딩하여 주소를 지정합니다. 확장성이 필요합니다. 이러한 노력은 현재 Ethereum 가상 머신이 제공하는 추상화 계층 공유 상태 공간 전반에 걸쳐. 다양한 연구 노력은 현재 진행 중입니다. [18][22] Cosmos 및 Ethereum 2.0 Mauve [22]은 디자인 목표가 다릅니다. Cosmos은(는) 특히 token에 관한 것입니다. Mauve는 스케일링에 관한 것입니다. 일반 계산. Cosmos은 EVM에 바인딩되지 않으므로 다른 VM도 가능합니다. 상호 운용. Cosmos을 통해 영역 작성자가 누가 검증하는지 결정할 수 있습니다. 구역. 누구나 Cosmos에서 새 영역을 시작할 수 있습니다(거버넌스가 아닌 경우). 달리 결정합니다). 허브는 영역 오류를 격리하므로 전역 token 불변성은 보존. 라이트닝 네트워크는 제안된 token 전송 네트워크입니다. Bitcoin blockchain(및 기타 공개) 위의 레이어에서 작동 blockchains), 수십 배의 개선이 가능합니다. 대부분의 트랜잭션을 이동하여 트랜잭션 처리량 향상 합의 원장 외부에서 소위 "결제 채널"로 전환됩니다.이는 온체인 암호화폐 스크립트를 통해 가능해졌습니다. 당사자들이 양자 간 국가 계약을 체결할 수 있도록 합니다. 디지털 서명 및 계약을 공유하여 상태를 업데이트할 수 있습니다. blockchain에 증거를 최종적으로 게시하여 종료할 수 있습니다. 메커니즘은 크로스체인 원자 교환을 통해 처음으로 대중화되었습니다. 작성자: 많은 당사자들과 결제 채널을 개설하고, 라이트닝 네트워크는 라우팅의 중심이 될 수 있습니다. 완전히 연결된 결제 채널로 이어지는 타인의 결제 지불 채널에 자본이 묶여 있는 대가를 치르게 됩니다. 라이트닝 네트워크는 여러 곳으로 쉽게 확장될 수도 있습니다. 가치 이전을 허용하는 여러 개의 독립적인 blockchain 교환시장을 통해서는 비대칭적으로 사용될 수 없습니다. token을 하나의 blockchain에서 다른 blockchain로 전송합니다. 메인 베니트 여기에 설명된 Cosmos 네트워크의 기능은 이러한 직접적 사용을 가능하게 하는 것입니다. token 전송. 즉, 우리는 지불 채널과 라이트닝 네트워크는 우리와 함께 널리 채택될 것입니다. token 비용 절감 및 개인 정보 보호를 위한 전송 메커니즘. 분리된 증인은 Bitcoin 개선 제안 링크입니다. 블록당 트랜잭션 처리량을 2배 또는 3배 증가시키는 것을 목표로 합니다. 동시에 새로운 노드에 대한 블록 동기화를 더 빠르게 만듭니다. 이 솔루션의 뛰어난 점은 다음과 같은 환경 내에서 작동하는 방식에 있습니다. Bitcoin의 현재 프로토콜 제한 사항 및 소프트 포크 허용 업그레이드(예: 이전 버전의 소프트웨어를 사용하는 클라이언트는 업그레이드 후에도 계속 작동합니다). 텐더민트, 새로운 존재가 되다 프로토콜에는 설계 제한이 없으므로 크기 조정이 다릅니다. 우선순위. 기본적으로 Tendermint는 BFT 라운드 로빈 알고리즘을 사용합니다. 채굴 대신 암호화 서명을 기반으로 하는 여러 병렬을 통해 수평 확장을 간단하게 허용합니다. blockchains, 정기적이고 더 빈번한 블록 커밋은 다음을 허용합니다. 수직 스케일링도 가능합니다.

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.

합의 및 기술적 세부사항

잘 설계된 합의 프로토콜은 다음을 제공해야 합니다. 허용 한도를 초과하는 경우 보장 그리고 합의는 실패합니다. 이는 특히 경제적인 측면에서 필요합니다. 비잔틴 행위가 상당한 재정적 이익을 가져올 수 있는 시스템 보상. 그러한 보장 중 가장 중요한 것은 합의를 야기한 프로세스가 실패(즉, 프로토콜의 클라이언트가 다른 값을 허용하게 함 - 포크)에 대한 규정에 따라 식별 및 처벌될 수 있습니다. 프로토콜 또는 법률 시스템일 수도 있습니다. 법체계가 갖춰지면 신뢰할 수 없거나 호출 비용이 지나치게 높기 때문에 validator은(는) 참가하려면 보증금을 예치해야 하며, 악의적인 행위가 있을 경우 예치금이 취소되거나 삭감될 수 있습니다. [10]이(가) 감지되었습니다. 이는 분기가 정기적으로 발생하는 Bitcoin과 다릅니다. 네트워크 비동기성과 바인딩의 확률적 특성으로 인해 부분적인 hash 충돌. 많은 경우에 악의적인 포크는 비동기성으로 인해 포크와 구별할 수 없습니다. Bitcoin은(는) 암시적인 것 외에 포크 책임을 안정적으로 구현합니다. 고아 블록을 채굴하기 위해 채굴자가 지불하는 기회 비용. 투표 단계를 PreVote 및 PreCommit이라고 합니다. 투표는 다음을 위해 할 수 있습니다 특정 블록 또는 Nil에 대한 것입니다. 우리는 >⅔ PreVotes 모음을 호출합니다. 같은 라운드의 단일 블록에 대해 폴카, >⅔ 컬렉션 동일한 라운드의 단일 블록에 대한 PreCommit은 Commit입니다. >⅔인 경우 같은 라운드에서 Nil에 대한 PreCommit은 다음 라운드로 이동합니다. 라운드. 프로토콜의 엄격한 결정론은 약한 문제를 야기한다는 점에 유의하십시오. 결함이 있는 리더로서의 동시성 가정을 감지해야 하며

건너뛰었습니다. 따라서 validators는 일정 시간 동안 기다립니다. TimeoutPropose, Nil을 Prevote하기 전, 그리고 그 가치 TimeoutPropose는 라운드마다 증가합니다. 진행을 통해 라운드의 나머지 부분은 완전히 비동기식입니다. validator이 네트워크의 ⅔ 이상에서 수신되면 생성됩니다. 실제로, 이를 완전히 좌절시키려면 극도로 강력한 적이 필요할 것입니다. 약한 동시성 가정(합의 실패 원인) 블록을 커밋하는 경우) 그렇게 하면 훨씬 더 많은 일을 할 수 있습니다. 각각에 대해 TimeoutPropose의 무작위 값을 사용하여 difycult validator. 추가 제약 조건 세트 또는 잠금 규칙은 다음을 보장합니다. 네트워크는 결국 각 높이에서 단 하나의 블록만 커밋하게 됩니다. 모두 둘 이상의 블록이 커밋되도록 하는 악의적인 시도 특정 높이에서 식별할 수 있습니다. 먼저, 블록에 대한 PreCommit 해당 블록에 대해 폴카 형태로 정당성을 제시해야 합니다. validator가 R_1 라운드에서 이미 블록을 PreCommit한 경우 그 블록에 갇혀 있다고 말했고 폴카는 그 블록을 정당화하는 데 사용되었습니다. 라운드 R_2의 새로운 PreCommit은 라운드에 와야 합니다 R_polka 여기서 R_1 < R_polka <= R_2. 둘째, validators는 제안해야 합니다. 및/또는 잠겨 있는 블록에 사전 투표를 하세요. 함께, 이들 조건은 validator이 없이 PreCommit하지 않도록 보장합니다. 정당성을 입증하는 충분한 증거와 그 validator 이미 PreCommit은 PreCommit에 대한 증거에 기여할 수 없습니다. 다른 것. 이는 보안과 활성을 모두 보장합니다. 합의 알고리즘. 프로토콜의 전체 세부 사항은 여기에 설명되어 있습니다. 대체 체인(포크)이 존재한다는 것은 ≥⅓의 블록 헤더를 의미하므로 모든 블록 헤더를 동기화할 필요가 TendermintPoS에서는 제거됩니다. 담보 스테이크는 삭감될 수 있습니다. 물론 슬래싱이 필요하기 때문에 누군가가 포크의 증거를 공유한다는 사실을 라이트 클라이언트는 저장해야 합니다. 모든 블록-hash 커밋이 표시됩니다. 또한, 라이트 클라이언트validator 세트의 변경 사항과 주기적으로 동기화를 유지할 수 있습니다. 장거리 공격을 피하기 위해(그러나 다른 솔루션은 가능). Ethereum과 유사한 정신으로 Tendermint는 애플리케이션이 다음을 수행할 수 있도록 합니다. 각 블록에 전역 Merkle 루트 hash을 삽입하여 쉽게 허용 계정 잔액, 가치 등에 대한 검증 가능한 상태 쿼리 계약에 저장되어 있거나 사용되지 않은 거래의 존재 애플리케이션의 성격에 따라 출력됩니다. 충분히 탄력적인 방송 네트워크 모음을 가정합니다. 정적 validator 세트를 사용하면 blockchain의 모든 포크는 감지되어 문제가 되는 validators의 예금이 삭감되었습니다. 이 2014년 초 Vitalik Buterin이 처음으로 제안한 혁신은 다음과 같은 문제를 해결합니다. 다른 proof-of-stake의 위험 없는 문제 암호화폐(관련 작업 참조). 그러나 validator이 설정되었으므로 원본은 장기간에 걸쳐 변경될 수 있어야 합니다. validators는 모두 결합 해제될 수 있으므로 자유롭게 사용할 수 있습니다. 제네시스 블록에서 새로운 체인을 생성하며, 비용은 발생하지 않습니다. 더 이상 예금이 잠겨 있지 않습니다. 이 공격이 나왔습니다 단거리 공격과 달리 장거리 공격(LRA)으로 알려져 있음 현재 결속된 validators가 다음을 유발하는 범위 공격 포크로 인해 처벌을 받을 수 있습니다(포크 책임이 있는 BFT 가정). Tendermint 합의와 같은 알고리즘). 장거리 공격은 종종 proof-of-stake에 심각한 타격을 입혔다고 생각됩니다. 다행히 LRA는 다음과 같이 완화할 수 있다. 첫째, validator 채권을 해제하여 담보 예금을 회수합니다. 더 이상 합의에 참여하기 위해 수수료를 받지 않습니다.) 보증금은 일정 기간 동안 양도할 수 없도록 설정되어야 합니다. "결합 해제 기간"으로 알려져 있으며, 이는 다음과 같은 순서로 나타날 수 있습니다. 몇 주 또는 몇 달. 둘째, 라이트 클라이언트의 보안을 위해서는 가장 먼저 네트워크에 연결되면 최근 블록을 확인해야 합니다-hash 신뢰할 수 있는 소스 또는 바람직하게는 여러 소스에 대해. 이

상태는 때때로 "약한 주관성"으로 지칭됩니다. 마지막으로, 보안을 유지하려면 다음에 설정된 최신 validator과 동기화해야 합니다. 적어도 언본딩 기간만큼 자주. 이 라이트 클라이언트가 validator에 대한 변경 사항을 알고 있는지 확인합니다. validator 이전에 설정된 자본금은 채권이 해제되어 더 이상 존재하지 않습니다. 위태로워서 클라이언트를 속일 수 있습니다. 뒤에서 시작하는 새로운 블록을 생성하여 장거리 공격 접착된 높이(충분히 제어할 수 있다고 가정) 많은 초기 개인 키). 이러한 방식으로 LRA를 극복하려면 proof-of-work의 원래 보안 모델. PoW에서는 라이트 클라이언트가 현재 높이와 동기화할 수 있다고 가정합니다. 모든 블록 헤더의 작업 증명을 처리하기만 하면 언제든지 신뢰할 수 있는 제네시스 블록을 생성할 수 있습니다. 그러나 LRA를 극복하기 위해 우리는 라이트 클라이언트가 정기적으로 온라인에 접속하도록 요구합니다. validator 세트의 변경 사항을 추적하고, 처음으로 온라인에 접속하면 인증에 특히 주의해야 합니다. 신뢰할 수 있는 소스에 대해 네트워크에서 듣는 내용입니다. 의 물론 이 후자의 요구 사항은 Bitcoin의 요구 사항과 유사합니다. 프로토콜과 소프트웨어도 신뢰할 수 있는 곳에서 받아야 합니다. 소스. 위의 LRA 방지 방법은 validators에 매우 적합합니다. 그리고 Tendermint 기반 blockchain의 전체 노드는 다음과 같습니다. 노드는 네트워크에 연결된 상태를 유지하도록 되어 있습니다. 는 이 방법은 다음을 기대할 수 있는 라이트 클라이언트에도 적합합니다. 네트워크와 자주 동기화하세요. 그러나 라이트 클라이언트의 경우 인터넷이나 인터넷에 자주 접속할 것으로 예상되지 않습니다. blockchain 네트워크 문제를 극복하기 위해 또 다른 솔루션을 사용할 수 있습니다. LRA. validator token 보유자가 아닌 사람은 자신의 token을 다음과 같이 게시할 수 있습니다. 해제 기간이 매우 긴 담보(예: 훨씬 더 긴 기간) validators의 언본딩 기간보다) 라이트 클라이언트에게 서비스를 제공합니다. 현재의 타당성을 증명하는 두 번째 방법으로 지난 블록-hashes. 이 token은(는) 그럼에도 불구하고 blockchain 합의의 보안은 가능합니다.라이트 클라이언트에게 강력한 보증을 제공합니다. 과거 블록-hash인 경우 쿼리는 Ethereum에서 지원되었으며 누구나 자신의 특별히 고안된 smart contract의 tokens 및 제공 유료 증명 서비스를 제공하여 라이트 클라이언트 LRA 보안 시장을 효과적으로 창출합니다. 블록 커밋의 해제로 인해 ≥⅓ 연합은 투표 권한으로 진을 떠나거나 말거나 blockchain을 중단할 수 있습니다. 그들의 투표를 방송합니다. 그러한 연합은 검열도 할 수 있습니다. 이를 포함하는 블록을 거부하여 특정 거래 거래가 발생하더라도 상당한 비율의 거래가 발생하게 됩니다. 블록 제안이 거부되어 비율이 느려질 수 있습니다. blockchain의 블록 커밋이 줄어들어 유틸리티와 가치가 감소합니다. 악의적 연합은 투표를 조금씩 방송할 수도 있으므로 blockchain 블록을 갈아서 거의 정지하거나 이러한 공격의 조합. 마지막으로 다음과 같은 원인이 될 수 있습니다. blockchain 이중 서명 또는 잠금 위반으로 포크 규칙. 전 세계적으로 활동하는 적도 연루된 경우 분할될 수 있습니다. 잘못된 것처럼 보일 수 있는 방식으로 네트워크를 validator의 하위 집합이 속도 저하의 원인이었습니다. 이것은 아니다 Tendermint의 한계일 뿐 아니라 오히려 모든 것의 한계입니다. 네트워크가 잠재적으로 통제되는 합의 프로토콜 적극적인 적. 이러한 유형의 공격에 대해서는 validator의 하위 집합이 필요합니다. 외부 수단을 통해 조정하여 재구성 제안에 서명합니다. 포크(및 그 증거)와 초기 하위 집합을 선택합니다. validator의 서명이 포함되어 있습니다. 이러한 조직 개편 제안에 서명한 검증자는 다른 모든 포크에 대한 담보를 포기합니다. 클라이언트는 해야 합니다 재구성 제안의 서명을 확인하고, 증거를 확인하고, 판단을 내리거나 최종 사용자에게 결정을 촉구합니다. 에 대한 예를 들어 휴대폰 지갑 앱은 사용자에게 보안 메시지를 표시할 수 있습니다.

경고하는 반면 냉장고는 재구성 제안을 받아들일 수 있습니다. 투표권을 통해 원본 validator의 +½이 서명했습니다. 비동기식 비잔틴 결함 허용 알고리즘은 제공될 수 없습니다. 투표권의 ⅓ 이상이 부정직할 때 합의를 이루지만 포크는 투표권의 ⅓ 이상이 이미 부정직하다고 가정합니다. 정당화 없이 이중 서명 또는 잠금 변경. 그래서 서명을 재구성 제안은 조정할 수 없는 조정 문제입니다. 비동기 프로토콜로 해결됩니다(즉, 자동으로 신뢰성에 대한 가정을 하지 않고 기본 네트워크). 지금은 조직개편 조정 문제를 사회적 합의를 통한 인간의 조정에 맡겨둔다. 인터넷 매체에서. 검증인은 다음 사항을 보장하기 위해 주의를 기울여야 합니다. 두 개의 복잡한 재구성 제안이 서명되는 상황을 피하기 위해 재구성 제안에 서명하기 전에 남은 네트워크 파티션이 없습니다. 외부 조정 매체와 프로토콜이 다음과 같다고 가정합니다. 강력하기 때문에 포크는 검열보다 덜 문제가 됩니다. 공격. ≥⅓ 비잔틴이 필요한 포크 및 검열 외에도 투표권이 있는 경우, ⅔ 이상의 투표권을 가진 연합이 약속할 수 있습니다. 임의적이고 잘못된 상태입니다. 이것은 (BFT)의 특징입니다. 합의 시스템. 포크를 생성하는 이중 서명과 달리 쉽게 검증할 수 있는 증거를 통해 범죄 행위를 탐지합니다. 유효하지 않은 상태에서는 유효성을 검사하지 않는 피어가 전체 블록을 확인해야 합니다. 이는 상태의 로컬 복사본을 유지하고 실행한다는 것을 의미합니다. 각 트랜잭션에 대해 독립적으로 상태 루트를 계산합니다. 스스로. 일단 감지되면 이러한 오류를 처리할 수 있는 유일한 방법 사회적 합의를 통해서다. 예를 들어, Bitcoin 상황에서 소프트웨어 버그로 인한 분기 여부에 관계없이 실패했습니다(3월과 마찬가지로). 2013) 또는 비잔틴 동작으로 인해 잘못된 상태를 범하는 경우 광부(2015년 7월 기준), 잘 연결된 커뮤니티 기업, 개발자, 광부 및 기타 조직 수동 조치가 무엇인지에 대한 사회적 합의를 확립했습니다.참가자가 네트워크를 치유하는 데 필요합니다. 게다가 이후 Tendermint blockchain의 validator는 다음과 같을 것으로 예상됩니다. 식별 가능하고 유효하지 않은 상태에 대한 약속은 심지어 원하는 경우 법률이나 일부 외부 법률에 의해 처벌될 수 있습니다. ABCI은(는) 전달되는 3가지 기본 메시지 유형으로 구성됩니다. 애플리케이션의 핵심. 애플리케이션은 다음과 같이 응답합니다. 해당 응답 메시지. AppendTx 메시지는 애플리케이션의 작업 도구입니다. 각각 blockchain의 거래가 이 메시지와 함께 전달됩니다. 는 애플리케이션은 수신된 각 트랜잭션을 검증해야 합니다. 현재 상태, 애플리케이션 프로토콜에 대한 AppendTx 메시지, 그리고 거래의 암호화 자격 증명. 검증된 그런 다음 트랜잭션은 애플리케이션 상태를 업데이트해야 합니다. 값을 키 값 저장소에 바인딩하거나 UTXO를 업데이트하여 데이터베이스.  CheckTx  메시지는 AppendTx와 유사하지만 거래 검증. Tendermint Core의 mempool 첫 번째 확인 CheckTx와의 거래 유효성, 릴레이만 유효함 동료와의 거래. 응용 프로그램은 증분을 확인할 수 있습니다 nonce를 사용하고 CheckTx 시 오류를 반환합니다. nonce은 오래되었습니다.  Commit  메시지는 암호화를 계산하는 데 사용됩니다. 현재 애플리케이션 상태에 대한 약속을 다음 블록 헤더. 여기에는 몇 가지 편리한 속성이 있습니다. 해당 상태 업데이트의 불일치는 이제 다음과 같이 나타납니다. blockchain 프로그래밍의 전체 클래스를 포착하는 포크 오류. 이는 또한 보안 경량의 개발을 단순화합니다. 클라이언트는 Merkle-hash 증거를 확인하여 확인할 수 있습니다. 블록-hash 및 블록-hash은 쿼럼에 의해 서명됩니다. validators (투표권에 따라).

추가 ABCI 메시지를 통해 애플리케이션은 validator 세트를 변경하고 애플리케이션이 높이 및 커밋 투표와 같은 블록 정보. ABCI 요청/응답은 간단한 Protobuf 메시지입니다. 확인 스키마 yle 밖으로. 인수: Data ([]byte) : 요청 트랜잭션 바이트 반품: 코드(uint32): 응답 코드 Data ([]byte) : 결과 바이트(있는 경우) 로그(문자열): 디버그 또는 오류 메시지 사용법:

트랜잭션을 추가하고 실행합니다. 거래가 유효한 경우, CodeType.OK를 반환합니다. 인수: Data ([]byte) : 요청 트랜잭션 바이트 반품: 코드(uint32): 응답 코드 Data ([]byte) : 결과 바이트(있는 경우) 로그(문자열): 디버그 또는 오류 메시지 사용법:

거래를 검증합니다. 이 메시지는 상태. 거래는 이전에 CheckTx를 통해 처음으로 실행됩니다. mempool 계층의 피어에게 브로드캐스팅됩니다. 당신은 만들 수 있습니다 CheckTx 반상태 저장 및 커밋 시 상태 지우기 또는 BeginBlock - 트랜잭션의 종속 시퀀스를 허용합니다. 같은 블록에 있어요.

반품: 데이터([]바이트): 머클 루트 hash 로그(문자열): 디버그 또는 오류 메시지 사용법:

애플리케이션 상태의 머클 루트 hash을 반환합니다. 인수: Data ([]byte) : 쿼리 요청 바이트 반품: 코드(uint32): 응답 코드 Data ([]byte) : 쿼리 응답 바이트 로그(문자열): 디버그 또는 오류 메시지 사용법:

응답 큐를 플러시합니다. 구현하는 애플리케이션 유형. 애플리케이션은 이 메시지를 구현할 필요가 없습니다. 프로젝트에 의해 처리됩니다. 반품: Data ([]byte) : 정보 바이트 사용법:

애플리케이션 상태에 대한 정보를 반환합니다. 신청 특정. 인수: Key (string) : 설정할 키

Value (string) : 키에 설정할 값 반품: 로그(문자열): 디버그 또는 오류 메시지 사용법:

애플리케이션 옵션을 설정합니다. 예: 키=“모드”, 값=“mempool” mempool 연결 또는 Key=“mode”, Value=“consensus” 합의된 연결. 다른 옵션은 애플리케이션에 따라 다릅니다. 인수: 유효성 검사기([]Validator): 초기 생성-validators 사용법:

창세기에 한 번 호출됨 인수: 높이(uint64): 시작되는 블록 높이 사용법:

새로운 블록의 시작을 알립니다. 어떤 일이 일어나기 전에 호출됨 AppendTxs. 인수: 높이(uint64): 끝난 블록 높이 반품: 유효성 검사기([]Validator): validator을 새로 변경했습니다. 투표권(제거하려면 0) 사용법:

블록의 끝을 신호합니다. 결국 각 커밋 전에 호출됩니다. 거래 자세한 내용은 ABCI 저장소를 참조하세요.발신자가 원하는 데에는 여러 가지 이유가 있습니다. 수신 체인에 의한 패킷 전달에 대한 승인. 예를 들어, 보낸 사람이 상태를 알 수 없습니다. 대상 체인에 결함이 있을 것으로 예상되는 경우. 아니면 발신인이 패킷에 시간 초과를 적용하려고 합니다(MaxHeight 사용).  패킷 소리), 대상 체인은 들어오는 숫자의 갑작스러운 급증으로 인해 서비스 거부 공격을 받을 수 있습니다. 패킷. 이 경우 발송인은 배달 확인을 요구할 수 있습니다. 초기 패킷 상태를 AckPending으로 설정합니다. 그렇다면 그것은 다음을 포함하여 체인의 배송 확인 책임을 받습니다. Merkle hash 앱에서는 IBCPacket으로 축약되었습니다. 먼저 IBCBlockCommit 및 IBCPacketTx가 '허브'에 게시됩니다. 이는 'Zone1'에 IBCPacket이 존재함을 증명합니다. 그렇게 말해보세요  IBCPacketTx의 값은 다음과 같습니다. FromChainID : “Zone1” FromBlockHeight : 100 (예:) 패킷: IBC패킷:

헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 (말) 상태 : 승인 보류 중 종류 : “코인” MaxHeight : 350 (예: "허브"의 높이는 현재 300입니다) 페이로드 : <“코인” 페이로드의 바이트 수> 다음으로 IBCBlockCommit 및 IBCPacketTx가 'Zone2'에 게시됩니다. 이는 '허브'에 IBC패킷이 존재함을 증명합니다. 그렇게 말해보세요  IBCPacketTx의 값은 다음과 같습니다. FromChainID : “허브” FromBlockHeight : 300 패킷: IBC패킷: 헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 상태 : 승인 보류 중 종류 : “코인” 최대 높이 : 350 페이로드 : <“코인” 페이로드의 동일한 바이트> 다음으로, “Zone2”는 앱-hash에 축약된 패킷을 포함해야 합니다. AckSent의 새로운 상태를 보여줍니다. IBCBlockCommit 및  IBCPacketTx는 존재를 증명하는 'Hub'에 다시 게시됩니다. 'Zone2'의 축약된 IBC패킷입니다. IBCPacketTx라고 말하세요  다음과 같은 값을 갖습니다: FromChainID : “Zone2”

FromBlockHeight : 400 (예:) 패킷: IBC패킷: 헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 상태 : 승인 전송됨 종류 : “코인” 최대 높이 : 350 PayloadHash : <동일한 "코인" 페이로드의 hash 바이트> 마지막으로 "허브"는 패킷의 상태를 업데이트해야 합니다.  AckReceived에 대한 AckPending입니다. 이 새로운 분석 상태에 대한 증거 "Zone2"로 돌아가야 합니다. IBCPacketTx에 다음이 있다고 가정해 보세요. 값: FromChainID : “허브” FromBlockHeight : 301 패킷: IBC패킷: 헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 상태 : 수신확인 종류 : “코인” 최대 높이 : 350 PayloadHash : <동일한 "코인" 페이로드의 hash 바이트> 한편, “Zone1”은 성공적인 배송을 낙관적으로 가정할 수 있습니다. 반대 증거가 입증되지 않는 한 "동전" 패킷 "허브". 위 예에서 'Hub'가 AckSent를 받지 못한 경우

블록 350으로 "Zone2"의 상태를 설정했다면 상태가 설정되었을 것입니다. 자동으로 시간 초과가 발생합니다. 시간 초과에 대한 이 증거는 다음과 같습니다. "Zone1"에 다시 게시되며 모든 token이 반환될 수 있습니다. Merkle tree에는 두 가지 유형이 지원됩니다. Tendermint/Cosmos 생태계: 단순 트리 및 IAVL+ 나무. 단순 트리는 요소의 정적 목록에 대한 Merkle tree입니다. 만약 항목 수는 2의 거듭제곱이 아니며 일부 리프는 다른 수준. Simple Tree는 트리의 양쪽 측면을 유지하려고 시도합니다. 높이는 같지만 왼쪽이 하나 더 클 수 있습니다. 이 Merkle tree은(는) 블록의 거래를 Merkle화하는 데 사용되며 최상위 수준 애플리케이션 상태 루트의 요소.IAVL+ 데이터 구조의 목적은 지속적인 정보를 제공하는 것입니다. 애플리케이션 상태의 키-값 쌍에 대한 저장 결정론적 머클 루트 hash은 효율적으로 계산될 수 있습니다. 는 트리는 AVL 알고리즘의 변형을 사용하여 균형을 이루고 있으며 모든 연산은 O(log(n))입니다. AVL 트리에서 모든 노드의 두 하위 하위 트리의 높이는 최대 1개만 다릅니다. 이 조건을 위반할 때마다 업데이트하면 트리는 O(log(n))개의 새 노드를 생성하여 재조정됩니다. 오래된 트리의 수정되지 않은 노드를 가리킵니다. 원래 AVL에서는 알고리즘에서는 내부 노드도 키-값 쌍을 보유할 수 있습니다. AVL+ 알고리즘(+ 참고) AVL 알고리즘을 수정하여 모든 항목을 유지합니다. 리프 노드에 값을 저장하고 분기 노드만 사용하여 키를 저장합니다. 이는 머클 hash 트레일을 유지하면서 알고리즘을 단순화합니다. 짧다. AVL+ 트리는 Ethereum의 Patricia 시도와 유사합니다. 있다 절충. 키를 삽입하기 전에 hash할 필요는 없습니다. IAVL+ 트리 - 키에서 더 빠른 순서의 반복을 제공합니다. 일부 응용 프로그램에 도움이 될 수 있는 공간입니다. 논리는 더 간단하다 내부 노드와 두 가지 유형의 노드만 필요합니다. 잎 노드. 머클 증명은 평균적으로 더 짧습니다.                 *                 / \               /     \             /         \           /             \          *               *         / \             / \        /   \           /   \       /     \         /     \      *       *       *       h6     / \     / \     / \    h0  h1  h2  h3  h4  h5    7개 요소로 구성된 SimpleTree

균형 잡힌 이진 트리. 반면에 Merkle 루트는 IAVL+ 트리는 업데이트 순서에 따라 달라집니다. 우리는 다음과 같은 효율적인 Merkle tree을 추가로 지원할 것입니다. 바이너리 변형이 다음과 같은 경우 Ethereum의 Patricia Trie 가능합니다. 표준 구현에서 트랜잭션은 다음으로 스트리밍됩니다. Cosmos ABCI 인터페이스를 통한 허브 애플리케이션. Cosmos 허브는 다수의 기본 거래를 허용합니다. SendTx,  BondTx,  UnbondTx,  ReportHackTx 등의 유형을 포함합니다.  SlashTx,  BurnAtomTx,  ProposalCreateTx 및  ProposalVoteTx, 이는 상당히 자명하며 다음 문서에 문서화됩니다. 이 문서의 향후 개정판. 여기서 우리는 두 가지 기본 사항을 문서화합니다. IBC의 트랜잭션 유형: IBCBlockCommitTx 및 IBCPacketTx. IBCBlockCommitTx 트랜잭션은 다음으로 구성됩니다. ChainID(문자열): blockchain의 ID BlockHash ([]byte): 블록-hash 바이트, Merkle 루트 여기에는 앱-hash이 포함되어 있습니다. BlockPartsHeader(PartSetHeader): 블록 부분 집합 헤더 바이트, 투표 서명을 확인하는 데만 필요함 BlockHeight(int): 커밋 높이 BlockRound(int): 커밋 라운드 Commit ([]Vote) : >⅔ Tendermint Precommit 투표는 블록 커밋으로 구성 ValidatorsHash ([]byte): 새 항목의 머클 트리 루트 hash validator 세트

ValidatorsHashProof(SimpleProof): BlockHash에 대해 ValidatorsHash를 증명하기 위한 SimpleTree Merkleproof AppHash([]바이트): IAVLTree Merkle-tree 루트 hash 애플리케이션 상태 AppHashProof(SimpleProof): SimpleTree 머클 증명 BlockHash에 대해 AppHash 증명 IBC패킷은 다음으로 구성됩니다. 헤더(IBCPacketHeader): 패킷 헤더 페이로드([]byte): 패킷 페이로드의 바이트입니다. 선택사항 PayloadHash ([]byte) : 패킷 바이트에 대한 hash입니다. 선택사항  Payload  또는  PayloadHash 중 하나가 있어야 합니다. hash IBCPacket의 는 두 항목 헤더의 간단한 Merkle 루트입니다.  및  페이로드. 전체 페이로드가 없는 IBC패킷을 약칭패킷. IBCPacketHeader는 다음으로 구성됩니다. SrcChainID(문자열): 소스 blockchain ID DstChainID (문자열) : 대상 blockchain ID Number(int): 모든 패킷의 고유 번호 상태(열거형): AckPending , AckSent 중 하나일 수 있습니다. AckReceived, NoAck 또는 시간 초과 유형(문자열): 유형은 애플리케이션에 따라 다릅니다. Cosmos "코인" 패킷 유형을 예약합니다. MaxHeight(int): 상태가 NoAckWanted 또는 AckReceived가 아닌 경우 이 높이만큼 상태는 Timeout 이 됩니다. 선택사항 IBCPacketTx  트랜잭션은 다음으로 구성됩니다.FromChainID(문자열): blockchain의 ID입니다. 이 패킷을 제공하고; 꼭 출처는 아니어도 FromBlockHeight(int): blockchain 높이입니다. 다음 패킷은 블록-hash에 포함됩니다(머클화). 소스 체인 패킷(IBCPacket): 상태가 1일 수 있는 데이터 패킷입니다. AckPending , AckSent , AckReceived , NoAck 또는 Timeout PacketProof(IAVLProof): 증명을 위한 IAVLTree Merkle 증명 소스 체인의 AppHash에 대한 패킷의 hash 주어진 높이 “Zone1”에서 “Zone2”로 패킷을 보내는 순서 "허브"를 통한 방법은 {그림 X}에 나와 있습니다. 먼저, IBCPacketTx  패킷이 앱 상태에 포함되어 있음을 "허브"에 증명합니다. “구역 1”. 그런 다음 또 다른 IBCPacketTx는 'Zone2'에 대해 패킷은 "허브"의 앱 상태에 포함됩니다. 이 동안 절차에서 IBCPacket 필드는 동일합니다. SrcChainID는 다음과 같습니다. 항상 "Zone1"이고, DstChainID는 항상 "Zone2"입니다. PacketProof에는 다음과 같이 올바른 Merkle 방지 경로가 있어야 합니다. 다음과 같습니다: “Zone1”이 “Hub”를 통해 “Zone2”로 패킷을 보내려고 할 때,  IBCPacket  데이터는 패킷이 "Zone1", "Hub" 또는 "Zone2"에서 Merkleized되었는지 여부와 동일합니다. 유일하게 변경 가능한 Yeld는 다음과 같습니다.  배송 추적 상태입니다. 개념화에 도움을 주신 친구와 동료들에게 감사드립니다. Tendermint와의 작업을 검토하고 지원합니다. 그리고 Cosmos. IBC///<번호>

SkuChain의 Zaki Manian은 형식 지정 및 작업에 많은 도움을 주었습니다. 특히 ABCI 섹션 아래의 문구 Althea의 Jehan Tremback과 Dustin Byington이 도움을 주었습니다. 초기 반복 합의에 대한 피드백을 주신 Honey Badger의 Andrew Miller 합의와 표현에 대한 피드백을 주신 Greg Slepak 또한 다양한 활동을 해주신 Bill Gleim과 한승환에게도 감사드립니다. 기여. 귀하의 기여를 위해 여기에 귀하의 이름과 조직이 표시됩니다. 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 제로캐시: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4 DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 분리된 증인: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 라이트닝 네트워크: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 텐더민트: https://github.com/tendermint/tendermint/wiki 9 FLP 불가능: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 슬래셔: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 비트셰어: https://bitshares.org/technology/delegatedproof-of-stake-consensus/

13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 중개인: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15개의 사이드체인: https://blockstream.com/sidechains.pdf 16 캐스퍼: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum 샤딩: https://github.com/ethereum/EIPs/issues/53 19 LibSwift: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalyticOfLibswift.pdf 20DLS: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 씬 클라이언트 보안: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 연보라색 종이: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html

¼ è

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 : Daha sonra, "Zone2"de bir IBCBlockCommit  ve  IBCPacketTx  yayınlanır. bu, "Hub" üzerinde bir IBCPacket 'in varlığını kanıtlar. Bunu söyle  IBCPacketTx şu değere sahiptir: FromChainID : “Hub” Bloktan Yükseklik : 300 Paket : bir IBCPaket : Başlık : an IBCPacketHeader : SrcChainID : “Bölge1” DstChainID : “Bölge2” Sayı : 200 Durum : Onay Bekleniyor Tür: “para” Maksimum Yükseklik : 350 Yük : Daha sonra, "Bölge2" uygulamasına hash kısaltılmış bir paket eklemelidir bu,  AckSent'in yeni durumunu gösterir. Bir IBCBlockCommit  ve  IBCPacketTx  varlığını kanıtlayan "Hub"a geri gönderilir "Bölge2"deki IBCPacket 'in kısaltılmış halidir. Bunu söyle IBCPacketTx  aşağıdaki değere sahiptir: FromChainID : “Bölge2”

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 : Son olarak “Hub” paketin durumunu şu adresten güncellemelidir:  AckReceived'a AckBekleniyor. Bu yeni ynalize durumun kanıtı "Bölge2"ye geri dönmelidir. IBCPacketTx 'in aşağıdaki özelliklere sahip olduğunu varsayalım değer: FromChainID : “Hub” Bloktan Yükseklik : 301 Paket : bir IBCPaket : Başlık : an IBCPacketHeader : SrcChainID : “Bölge1” DstChainID : “Bölge2” Sayı : 200 Durum: Alındı Alındı Tür: “para” Maksimum Yükseklik : 350 PayloadHash : Bu arada, “Bölge1” iyimser bir şekilde başarılı teslimatı varsayabilir Aksi kanıtlanmadıkça bir "madeni para" paketinin "Merkez". Yukarıdaki örnekte "Hub" bir AckSent almamışsa

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