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

โดย Jae Kwon and Ethan Buchman · 2016

โหมดเดี่ยว v1.cosmos.network

การแนะนำ

ความสำเร็จร่วมกันของระบบนิเวศโอเพ่นซอร์ส การแบ่งปัน yle แบบกระจายอำนาจ และ cryptocurrencies สาธารณะก็มี เป็นแรงบันดาลใจให้เกิดความเข้าใจว่าโปรโตคอลอินเทอร์เน็ตแบบกระจายอำนาจ สามารถใช้เพื่อปรับปรุงโครงสร้างพื้นฐานทางเศรษฐกิจและสังคมอย่างรุนแรง เราได้เห็นแอปพลิเคชันพิเศษ blockchain เช่น Bitcoin [1] (a cryptocurrency), Zerocash [2] (สกุลเงินดิจิตอลเพื่อความเป็นส่วนตัว) และ แพลตฟอร์ม smart contract ทั่วไป เช่น Ethereum [3] ด้วย แอปพลิเคชั่นแบบกระจายจำนวนนับไม่ถ้วนสำหรับ Etherium Virtual เครื่องจักร (EVM) เช่น Augur (ตลาดการทำนาย) และ TheDAO [4] (สโมสรการลงทุน) อย่างไรก็ตาม จนถึงขณะนี้ blockchains เหล่านี้ได้รับความเดือดร้อนจากจำนวนหนึ่ง ข้อเสีย รวมถึงการขาดพลังงานรวม แย่หรือ ประสิทธิภาพที่จำกัด และกลไกการกำกับดูแลที่ยังไม่บรรลุนิติภาวะ ข้อเสนอเพื่อขยายปริมาณธุรกรรมของ Bitcoin เช่น แยกพยาน [5] และ BitcoinNG [6] เป็นการปรับขนาดแนวตั้ง โซลูชันที่ยังคงถูกจำกัดด้วยความจุทางกายภาพเพียงเครื่องเดียว เครื่องจักรเพื่อให้มั่นใจในคุณสมบัติของการตรวจสอบที่สมบูรณ์ Lightning Network [7] สามารถช่วยปรับขนาดธุรกรรม Bitcoin ได้

ปริมาณโดยทิ้งธุรกรรมบางอย่างออกจากบัญชีแยกประเภทโดยสมบูรณ์ และเหมาะอย่างยิ่งสำหรับการชำระเงินแบบไมโครและการรักษาความเป็นส่วนตัว รางการชำระเงิน แต่อาจไม่เหมาะกับการใช้งานทั่วไปมากขึ้น ความต้องการปรับขนาด วิธีแก้ปัญหาในอุดมคติคือวิธีที่อนุญาตให้ blockchains หลายขนานกันได้ ทำงานร่วมกันโดยยังคงรักษาคุณสมบัติด้านความปลอดภัยไว้ นี้ก็มี พิสูจน์แล้วว่าเป็นเรื่องยาก หากไม่ใช่เป็นไปไม่ได้ ด้วย proof-of-work รวมแล้ว ตัวอย่างเช่น การขุดช่วยให้งานที่ทำสามารถรักษาความปลอดภัยให้กับผู้ปกครองได้ chain เพื่อนำมาใช้ซ้ำบน chain ลูก แต่ธุรกรรมจะต้องยังคงอยู่ ตรวจสอบตามลำดับโดยแต่ละโหนดและ blockchain ที่ขุดแบบผสาน มีความเสี่ยงที่จะถูกโจมตีหากพลัง hashing ส่วนใหญ่บน parent ไม่ได้ทำการผสานการขุดลูกอย่างแข็งขัน การทบทวนทางวิชาการ ของสถาปัตยกรรมเครือข่ายทางเลือก blockchain มีไว้สำหรับ บริบทเพิ่มเติมและเราให้ข้อมูลสรุปของข้อเสนออื่นๆ และข้อเสียในงานที่เกี่ยวข้อง ที่นี่เราขอนำเสนอ Cosmos สถาปัตยกรรมเครือข่ายแบบใหม่ blockchain ที่ตอบโจทย์ปัญหาเหล่านี้ทั้งหมด Cosmos เป็นเครือข่ายของหลายๆ คน blockchains อิสระ เรียกว่าโซน โซนต่างๆ ขับเคลื่อนโดย Tendermint Core [8] ซึ่งให้ประสิทธิภาพสูง กลไกฉันทามติเหมือน PBFT ที่สอดคล้องและปลอดภัย โดยที่การรับประกันการรับผิดชอบที่เข้มงวดจะยึดถือพฤติกรรมของผู้ประสงค์ร้าย นักแสดง อัลกอริธึมฉันทามติ BFT ของ Tendermint Core เหมาะสมอย่างยิ่ง สำหรับการปรับขนาดสาธารณะ proof-of-stake blockchains โซนแรกบน Cosmos เรียกว่า Cosmos Hub Cosmos Hub เป็นสกุลเงินดิจิตอล proof-of-stake หลายสินทรัพย์ที่มีความเรียบง่าย กลไกการกำกับดูแลที่ทำให้เครือข่ายสามารถปรับตัวและ อัพเกรด นอกจากนี้ Cosmos Hub ยังสามารถขยายได้ด้วย เชื่อมต่อโซนอื่นๆ ฮับและโซนของเครือข่าย Cosmos สื่อสารด้วย ซึ่งกันและกันผ่านทางโปรโตคอลการสื่อสารระหว่าง-blockchain (IBC) UDP เสมือนหรือ TCP ชนิดหนึ่งสำหรับ blockchains โทเค็นสามารถเป็นได้ ถ่ายโอนจากโซนหนึ่งไปยังอีกโซนหนึ่งอย่างปลอดภัยและรวดเร็วโดยไม่ต้องมีการแลกเปลี่ยนสภาพคล่องระหว่างโซน แทน การถ่ายโอน token ระหว่างโซนทั้งหมดจะต้องผ่าน Cosmos Hub ซึ่ง ติดตามจำนวนรวมของ tokens ที่ถือโดยแต่ละโซน ที่ ฮับจะแยกแต่ละโซนออกจากความล้มเหลวของโซนอื่น เพราะว่า ทุกคนสามารถเชื่อมต่อโซนใหม่กับ Cosmos Hub ได้ โซนอนุญาต เพื่อความเข้ากันได้กับนวัตกรรม blockchain ใหม่ในอนาคต ในส่วนนี้ เราจะอธิบายโปรโตคอลฉันทามติของ Tendermint และอินเทอร์เฟซที่ใช้สร้างแอปพลิเคชันด้วย สำหรับข้อมูลเพิ่มเติม รายละเอียดดูภาคผนวก ในอัลกอริธึมความทนทานต่อข้อผิดพลาดของไบเซนไทน์คลาสสิก (BFT) แต่ละโหนด มีน้ำหนักเท่ากัน ใน Tendermint โหนดจะมีค่าไม่เป็นลบ จำนวนอำนาจการลงคะแนนเสียง และโหนดที่มีการลงคะแนนเสียงเชิงบวก กำลังเรียกว่า validators ผู้ตรวจสอบมีส่วนร่วมใน โปรโตคอลฉันทามติโดยการเผยแพร่ลายเซ็นเข้ารหัสหรือ โหวตเพื่อตกลงในบล็อกถัดไป อำนาจการลงคะแนนของผู้ตรวจสอบจะถูกกำหนดตั้งแต่กำเนิดหรือเป็น เปลี่ยนตามที่กำหนดโดย blockchain ขึ้นอยู่กับ ใบสมัคร ตัวอย่างเช่น ในแอปพลิเคชัน proof-of-stake เช่น Cosmos Hub อำนาจการลงคะแนนอาจถูกกำหนดโดย จำนวน staking tokens ที่ผูกมัดเป็นหลักประกัน หมายเหตุ: เศษส่วนเช่น ⅔ และ ⅓ หมายถึงเศษส่วนของการลงคะแนนเสียงทั้งหมด กำลัง ไม่เคยเป็นจำนวนรวมของ validators ยกเว้น validators ทั้งหมด มีน้ำหนักเท่ากัน >⅔ หมายถึง “มากกว่า ⅔”, ≥⅓ หมายถึง “อย่างน้อย ⅓” Tendermint เป็นโปรโตคอลฉันทามติ BFT แบบซิงโครนัสบางส่วน มาจากอัลกอริธึมฉันทามติ DLS [20] อ่อนโยนคือ

โดดเด่นด้วยความเรียบง่าย ประสิทธิภาพ และความรับผิดชอบทางแยก โปรโตคอลต้องการชุด validators ที่รู้จัก yxed โดยที่แต่ละชุด validator ถูกระบุโดยรหัสสาธารณะ ผู้ตรวจสอบพยายามที่จะ ตกลงกันทีละบล็อก โดยที่บล็อกคือรายการ ของการทำธุรกรรม การลงคะแนนเสียงเพื่อให้เห็นพ้องต้องกันในบล็อกดำเนินไป รอบ แต่ละรอบจะมีผู้นำรอบหรือผู้เสนอชื่อใคร เสนอบล็อก จากนั้น validators จะลงคะแนนเสียงเป็นระยะว่าหรือไม่ เพื่อยอมรับบล็อกที่เสนอหรือผ่านเข้าสู่รอบต่อไป ที่ ผู้เสนอรอบจะถูกเลือกตามที่กำหนดจากคำสั่ง รายการ validators ตามสัดส่วนของอำนาจการลงคะแนนของพวกเขา รายละเอียดทั้งหมดของโปรโตคอลมีอธิบายไว้ที่นี่ ความปลอดภัยของ Tendermint มาจากการใช้ Byzantine ที่เหมาะสมที่สุด การยอมรับข้อผิดพลาดผ่านการลงคะแนนเสียงส่วนใหญ่มาก (>⅔) และการล็อค กลไก พวกเขาร่วมกันรับประกันว่า: อำนาจการลงคะแนนเสียง≥⅓จะต้องเป็นไบเซนไทน์จึงจะทำให้เกิดการละเมิด ความปลอดภัยซึ่งมีความมุ่งมั่นมากกว่าสองค่า หากชุด validators ใด ๆ ประสบความสำเร็จในการละเมิดความปลอดภัย หรือแม้กระทั่ง พยายามที่จะทำเช่นนั้น สามารถระบุได้โดยโปรโตคอล นี้ รวมถึงทั้งการลงคะแนนสำหรับบล็อกที่ขัดแย้งกันและการออกอากาศ คะแนนเสียงที่ไม่ยุติธรรม แม้จะมีการรับประกันที่แข็งแกร่ง แต่ Tendermint ก็มอบสิ่งที่ยอดเยี่ยม ประสิทธิภาพการทำงาน ในการวัดประสิทธิภาพ 64 โหนดที่กระจายอยู่ใน 7 ศูนย์ข้อมูลใน 5 ทวีป บนอินสแตนซ์คลาวด์สินค้าโภคภัณฑ์ ฉันทามติ Tendermint สามารถประมวลผลธุรกรรมได้หลายพันรายการต่อ ประการที่สอง โดยมีเวลาแฝงประมาณหนึ่งถึงสองวินาที โดยเฉพาะอย่างยิ่งประสิทธิภาพการทำธุรกรรมมากกว่าหนึ่งพันรายการต่อ ประการที่สองยังคงอยู่แม้ในสภาวะที่ไม่เป็นมิตรด้วย validators หยุดทำงานหรือเผยแพร่การโหวตที่จัดทำขึ้นโดยมีเจตนาร้าย ดูสิ ygure ด้านล่างเพื่อดูรายละเอียด

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

ประโยชน์หลักของอัลกอริธึมฉันทามติของ Tendermint นั้นเรียบง่าย การรักษาความปลอดภัยไคลเอ็นต์แบบเบา ทำให้เป็นตัวเลือกที่เหมาะสำหรับมือถือและ กรณีการใช้งานอินเทอร์เน็ตออฟธิงส์ ในขณะที่ไคลเอ็นต์ light Bitcoin ต้องซิงค์ โซ่ของส่วนหัวของบล็อกและอันที่มีการพิสูจน์มากที่สุด การทำงาน ลูกค้า Tendermint light ต้องการเพียงเพื่อให้ทันกับการเปลี่ยนแปลง ไปที่ชุด validator จากนั้นตรวจสอบ >⅔ PreCommits ใน บล็อกล่าสุดเพื่อกำหนดสถานะล่าสุด การพิสูจน์ไคลเอ็นต์แบบเบาที่กระชับยังเปิดใช้งาน inter-blockchain การสื่อสาร Tendermint มีมาตรการป้องกันในการป้องกันบางอย่าง การโจมตีที่โดดเด่น เช่น การโจมตีระยะไกลโดยไม่มีอะไรต้องเดิมพันเป็นสองเท่า และการเซ็นเซอร์ สิ่งเหล่านี้จะกล่าวถึงอย่างละเอียดยิ่งขึ้นในภาคผนวกอัลกอริธึมฉันทามติของ Tendermint ถูกนำมาใช้ใน โปรแกรมชื่อ Tendermint Core Tendermint Core เป็น “กลไกฉันทามติ” ที่ไม่เชื่อเรื่องแอปพลิเคชันซึ่งสามารถเปลี่ยนอะไรก็ได้ แอปพลิเคชัน blackbox ที่กำหนดไว้ในการจำลองแบบกระจาย blockchain. Tendermint Core เชื่อมต่อกับแอปพลิเคชัน blockchain ผ่านทาง Application Blockchain Interface (ABCI) [17] ดังนั้น ABCI อนุญาตให้ blockchain โปรแกรมใด ๆ ก็ได้ ภาษาไม่ใช่แค่ภาษาโปรแกรมที่มติเป็นเอกฉันท์ เอ็นจิ้นถูกเขียนไว้ นอกจากนี้ ABCI ยังทำให้เป็นไปได้อย่างง่ายดาย สลับเลเยอร์ฉันทามติของสแต็ก blockchain ที่มีอยู่ เราทำการเปรียบเทียบกับสกุลเงินดิจิทัลที่รู้จักกันดี Bitcoin Bitcoin เป็นสกุลเงินดิจิทัล blockchain โดยที่แต่ละโหนดจะรักษา ฐานข้อมูล Unspent Transaction Output (UTXO) ที่ได้รับการตรวจสอบอย่างครบถ้วน ถ้า มีคนต้องการสร้างระบบที่เหมือน Bitcoin บน ABCI Tendermint Core จะต้องรับผิดชอบ การแชร์บล็อกและธุรกรรมระหว่างโหนด การสร้างลำดับการทำธุรกรรมที่เป็นที่ยอมรับ/ไม่เปลี่ยนรูป (the 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 เป็นเครือข่ายของ blockchains แบบขนานอิสระที่ แต่ละอันขับเคลื่อนโดยอัลกอริธึมฉันทามติคลาสสิก BFT เช่น เทนเดอร์มินต์ 1. blockchain ปีแรกในเครือข่ายนี้จะเป็น Cosmos Hub ที่ Cosmos ฮับเชื่อมต่อกับ blockchains (หรือโซน) อื่นๆ มากมายผ่าน โปรโตคอลการสื่อสารระหว่าง-blockchain ใหม่ ฮับ Cosmos ติดตาม token ประเภทจำนวนมากและเก็บบันทึกผลรวมทั้งหมด จำนวน tokens ในแต่ละโซนที่เชื่อมต่อ โทเค็นสามารถเป็นได้ ถ่ายโอนจากโซนหนึ่งไปยังอีกโซนหนึ่งอย่างปลอดภัยและรวดเร็ว โดยไม่ต้องมีการแลกเปลี่ยนของเหลวระหว่างโซนเพราะทั้งหมด การโอนเหรียญระหว่างโซนต้องผ่าน Cosmos Hub สถาปัตยกรรมนี้แก้ปัญหามากมายที่พื้นที่ blockchain ใบหน้าในปัจจุบัน เช่น การทำงานร่วมกันของแอปพลิเคชัน ความสามารถในการปรับขนาด และ การอัพเกรดที่ราบรื่น ตัวอย่างเช่น โซนที่ได้มาจาก Bitcoind Go-Ethereum, CryptoNote, ZCash หรือระบบ blockchain ใด ๆ สามารถทำได้ เสียบเข้ากับฮับ Cosmos โซนเหล่านี้อนุญาตให้ Cosmos ปรับขนาดได้อย่างไม่มีที่สิ้นสุดเพื่อตอบสนองความต้องการในการทำธุรกรรมทั่วโลก โซนก็เช่นกัน yt ที่ดีสำหรับการแลกเปลี่ยนแบบกระจายซึ่งจะได้รับการสนับสนุนเป็น เอาล่ะ Cosmos ไม่ได้เป็นเพียงบัญชีแยกประเภทแบบกระจายเดียว และ Cosmos ฮับไม่ใช่สวนที่มีกำแพงล้อมรอบหรือศูนย์กลางของจักรวาล เราเป็น การออกแบบโปรโตคอลสำหรับเครือข่ายเปิดของบัญชีแยกประเภทแบบกระจาย ที่สามารถใช้เป็นรากฐานใหม่สำหรับระบบการเงินในอนาคต ตามหลักการของการเข้ารหัส เศรษฐศาสตร์ที่ดี ฉันทามติ ทฤษฎี ความโปร่งใส และความรับผิดชอบ Cosmos Hub เป็น blockchain สาธารณะแห่งแรกใน Cosmos เครือข่าย ขับเคลื่อนโดยอัลกอริธึมฉันทามติ BFT ของ Tendermint ที่ โครงการโอเพ่นซอร์ส Tendermint ถือกำเนิดขึ้นในปี 2014 เพื่อจัดการกับ ความเร็ว ความสามารถในการปรับขนาด และปัญหาด้านสิ่งแวดล้อมของอัลกอริธึมฉันทามติพิสูจน์การทำงานของ Bitcoin โดยใช้และปรับปรุงตามที่ได้รับการพิสูจน์แล้ว

BFT อัลกอริธึมที่พัฒนาขึ้นที่ MIT ในปี 1988 [20] Tendermint ทีมงานเป็นทีมแรกที่สาธิตแนวคิด proof-of-stake สกุลเงินดิจิทัลที่จัดการกับปัญหาที่ไม่มีความเสี่ยง ได้รับความทุกข์ทรมานจาก cryptocurrencies รุ่นแรก proof-of-stake เช่นนี้ เป็น NXT และ BitShares1.0 ทุกวันนี้ กระเป๋าเงินมือถือ Bitcoin ทั้งหมดใช้เซิร์ฟเวอร์ที่เชื่อถือได้ ให้การยืนยันธุรกรรมแก่พวกเขา นี่เป็นเพราะว่าการพิสูจน์การทำงานต้องรอการยืนยันหลายครั้งก่อน a ธุรกรรมถือได้ว่ามีความมุ่งมั่นอย่างถาวร การโจมตีแบบ Doublespend ได้แสดงให้เห็นแล้วในบริการต่างๆ เช่น CoinBase. แตกต่างจากระบบฉันทามติอื่นๆ blockchain Tendermint เสนอ การยืนยันการชำระเงินผ่านมือถือของลูกค้าทันทีและพิสูจน์ได้อย่างปลอดภัย เนื่องจาก Tendermint ได้รับการออกแบบมาให้เคลื่อนที่ได้ไม่เคยแยกเลย กระเป๋าเงินสามารถรับการทำธุรกรรมได้ทันทีซึ่งทำให้ การชำระเงินที่ไม่น่าเชื่อถือและใช้งานได้จริงบนสมาร์ทโฟน นี้ มีขอบเขตที่ชัดเจนสำหรับแอปพลิเคชัน Internet of Things เช่น เอาล่ะ เครื่องมือตรวจสอบใน Cosmos มีบทบาทคล้ายกับ Bitcoin นักขุด แต่ ใช้ลายเซ็นเข้ารหัสแทนในการลงคะแนนเสียง ผู้ตรวจสอบความถูกต้องคือ เครื่องจักรเฉพาะที่ปลอดภัยซึ่งมีหน้าที่รับผิดชอบในการดำเนินการ บล็อก ผู้ที่ไม่ใช่ validators สามารถมอบหมาย staking tokens ของตนได้ (เรียกว่า “อะตอม”) ไปยัง validator ใดๆ เพื่อรับส่วนแบ่งค่าธรรมเนียมบล็อกและอะตอม รางวัล แต่พวกเขามีความเสี่ยงที่จะถูกลงโทษ (เฉือน) หาก ผู้รับมอบสิทธิ์ validator ถูกแฮ็กหรือละเมิดโปรโตคอล ที่ได้รับการพิสูจน์แล้ว รับประกันความปลอดภัยของ Tendermint BFT ฉันทามติและหลักประกัน ฝากของผู้มีส่วนได้ส่วนเสีย–validatorsและผู้มอบหมาย–ให้ การรักษาความปลอดภัยเชิงปริมาณที่พิสูจน์ได้สำหรับโหนดและไคลเอ็นต์แบบเบา บัญชีแยกประเภทสาธารณะแบบกระจายควรมีรัฐธรรมนูญและก ระบบการกำกับดูแล Bitcoin อาศัย Bitcoin มูลนิธิและการขุดเพื่อประสานงานการอัพเกรด แต่นี่เป็นกระบวนการที่ช้า Ethereum แบ่งออกเป็น ETH และ ETC หลังจากการฮาร์ดฟอร์กเพื่อระบุที่อยู่ แฮ็คDAO ส่วนใหญ่เป็นเพราะไม่มีสัญญาทางสังคมมาก่อน หรือกลไกในการตัดสินใจดังกล่าว ผู้ตรวจสอบและผู้มอบหมายใน Cosmos Hub สามารถลงคะแนนได้ ข้อเสนอที่สามารถเปลี่ยนพารามิเตอร์ที่ตั้งไว้ล่วงหน้าของระบบได้ อัตโนมัติ (เช่น บล็อกแก๊สจำกัด) ประสานงานการอัพเกรด เช่น รวมถึงการลงคะแนนเสียงแก้ไขรัฐธรรมนูญที่มนุษย์อ่านได้ ที่ควบคุมนโยบายของ Cosmos Hub รัฐธรรมนูญ ช่วยให้เกิดการทำงานร่วมกันระหว่างผู้มีส่วนได้ส่วนเสียในประเด็นต่างๆเช่น การโจรกรรมและข้อบกพร่อง (เช่นเหตุการณ์ TheDAO) ช่วยให้ดำเนินการได้รวดเร็วยิ่งขึ้น ความละเอียดที่สะอาดยิ่งขึ้น แต่ละโซนสามารถมีรัฐธรรมนูญและการปกครองของตนเองได้ กลไกเช่นกัน ตัวอย่างเช่น Cosmos Hub อาจมี รัฐธรรมนูญที่บังคับใช้ความไม่เปลี่ยนแปลงที่ศูนย์กลาง (ไม่มีการย้อนกลับ บันทึกสำหรับข้อบกพร่องของการใช้งานโหนด Cosmos Hub) ในขณะที่ แต่ละโซนสามารถกำหนดนโยบายของตนเองเกี่ยวกับการย้อนกลับได้ โดยการเปิดใช้งานการทำงานร่วมกันระหว่างโซนนโยบายที่แตกต่างกัน เครือข่าย Cosmos มอบอิสระและศักยภาพสูงสุดให้กับผู้ใช้ การทดลองโดยไม่ได้รับอนุญาต ที่นี่เราจะอธิบายรูปแบบใหม่ของการกระจายอำนาจและความสามารถในการปรับขนาด Cosmos เป็นเครือข่ายของ blockchains มากมายที่ขับเคลื่อนโดย สะระแหน่. ในขณะที่ข้อเสนอที่มีอยู่มุ่งเป้าไปที่การสร้าง “โสด” blockchain” พร้อมลำดับธุรกรรมทั่วโลกทั้งหมด Cosmos อนุญาตให้ blockchains จำนวนมากทำงานพร้อมกัน ในขณะที่ยังคงรักษาความสามารถในการทำงานร่วมกัน โดยพื้นฐานแล้ว Cosmos Hub จะจัดการอิสระจำนวนมาก blockchains เรียกว่า "โซน" (บางครั้งเรียกว่า "เศษชิ้นส่วน" ใน อ้างอิงถึงเทคนิคการปรับขนาดฐานข้อมูลที่เรียกว่า "การแบ่งส่วน")

การส่งบล็อกล่าสุดอย่างต่อเนื่องจากโซนที่โพสต์ไว้ Hub ช่วยให้ Hub ติดตามสถานะของแต่ละโซนได้ ในทำนองเดียวกัน แต่ละโซนจะติดตามสถานะของ Hub (แต่โซน ไม่ตามทันกันเว้นแต่ทางอ้อมผ่านทาง ฮับ) จากนั้นแพ็คเก็ตข้อมูลจะถูกสื่อสารจากที่เดียว ไปยังอีกฟากหนึ่งโดยการโพสต์หลักฐาน Merkle ไว้เป็นหลักฐานว่า ข้อมูลถูกส่งและรับ กลไกนี้เรียกว่า การสื่อสารระหว่าง-blockchain หรือเรียกสั้น ๆ ว่า IBC โซนใดๆ ก็สามารถเป็นศูนย์กลางเพื่อสร้างกราฟแบบอะไซคลิกได้ แต่เพื่อความชัดเจนเราจะอธิบายเฉพาะเรื่องง่ายๆ เท่านั้น การกำหนดค่าที่มีฮับเพียงอันเดียวและหลายอันที่ไม่ใช่ฮับ โซน Cosmos Hub คือ blockchain ที่โฮสต์หลายสินทรัพย์ บัญชีแยกประเภทแบบกระจาย โดยที่ tokens สามารถถือครองโดยผู้ใช้แต่ละรายหรือ ตามโซนต่างๆ เอง tokens เหล่านี้สามารถย้ายจากโซนเดียวได้ ไปยังอีกอันในแพ็กเก็ต IBC พิเศษที่เรียกว่า "แพ็กเก็ตเหรียญ" ศูนย์กลางอยู่ที่ รับผิดชอบในการรักษาค่าคงที่ทั่วโลกของยอดรวม จำนวนแต่ละ token ทั่วทั้งโซน IBC ซองใส่เหรียญ ธุรกรรมจะต้องกระทำโดยผู้ส่ง ฮับ และผู้รับ blockchainส.เนื่องจาก Cosmos Hub ทำหน้าที่เป็นบัญชีแยกประเภทกลางสำหรับทั้งหมด ความปลอดภัยของ Hub มีความสำคัญอย่างยิ่ง ในขณะที่ แต่ละโซนอาจเป็น Tendermint blockchain ที่ถูกรักษาความปลอดภัยโดย as น้อยกว่า 4 (หรือน้อยกว่านั้นหากไม่ต้องการฉันทามติ BFT) ฮับ จะต้องได้รับการรักษาความปลอดภัยโดยชุดการกระจายอำนาจทั่วโลกของ validators นั้น สามารถทนต่อสถานการณ์การโจมตีที่รุนแรงที่สุด เช่น ก พาร์ติชันเครือข่ายระดับทวีปหรือการโจมตีที่ได้รับการสนับสนุนจากรัฐชาติ โซน Cosmos เป็นโซนอิสระ blockchain ที่แลกเปลี่ยน IBC ข้อความกับฮับ จากมุมมองของ Hub โซนคือ บัญชีหลายลายเซ็นสมาชิกแบบไดนามิกหลายสินทรัพย์นั้น สามารถส่งและรับ tokens โดยใช้แพ็กเก็ต IBC เหมือนก บัญชีสกุลเงินดิจิตอล โซนไม่สามารถถ่ายโอนมากกว่า tokens ได้ มี แต่สามารถรับ tokens จากผู้อื่นที่มีได้ โซน อาจถูกกำหนดให้เป็น "แหล่งที่มา" ของ token หนึ่งประเภทขึ้นไป ให้อำนาจแก่มันในการเติมพลัง token อุปทานนั้น อะตอมของ Cosmos Hub อาจถูกเดิมพันโดย validators ของโซน เชื่อมต่อกับฮับ ในขณะที่โจมตีสองครั้งในโซนเหล่านี้ จะส่งผลให้เกิดการเฉือนอะตอมด้วยความต้องรับผิดชอบของ Tendermint ซึ่งเป็นโซนที่ >⅔ ของอำนาจการลงคะแนนเสียงอยู่ที่ ไบเซนไทน์สามารถกระทำสถานะที่ไม่ถูกต้อง Cosmos Hub ไม่มี ตรวจสอบหรือดำเนินธุรกรรมที่กระทำในโซนอื่น ๆ ดังนั้นจึงเป็นเช่นนั้น ความรับผิดชอบของผู้ใช้ในการส่ง tokens ไปยังโซนที่พวกเขาเชื่อถือ ในอนาคต ระบบการกำกับดูแลของ Cosmos Hub อาจผ่าน Hub ข้อเสนอการปรับปรุงที่คำนึงถึงความล้มเหลวของโซน สำหรับ ตัวอย่างเช่น การถ่ายโอน token ขาออกจากบางโซน (หรือทั้งหมด) อาจเกิดขึ้น ถูกควบคุมปริมาณเพื่อให้สามารถตัดวงจรฉุกเฉินของโซนได้ (หยุดการถ่ายโอน token ชั่วคราว) เมื่อตรวจพบการโจมตี ตอนนี้เรามาดูกันว่าฮับและโซนต่างๆ สื่อสารกันอย่างไร อื่น ๆ ตัวอย่างเช่น หากมี blockchain สามรายการ ได้แก่ “Zone1”, “Zone2”

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

และ "Hub" และเราหวังว่า "Zone1" จะผลิตแพ็กเก็ตที่ถูกกำหนดไว้ สำหรับ “Zone2” ผ่าน “Hub” เพื่อย้ายแพ็กเก็ตจากที่หนึ่ง blockchain ไปยังอีกคนหนึ่ง มีการโพสต์หลักฐานบนห่วงโซ่การรับ หลักฐานระบุว่าห่วงโซ่การส่งเผยแพร่แพ็กเก็ตสำหรับ จุดหมายปลายทางที่ถูกกล่าวหา เพื่อให้สายรับสามารถตรวจสอบหลักฐานนี้ได้ ต้องสามารถติดตามส่วนหัวบล็อกของผู้ส่งได้ นี้ กลไกคล้ายกับที่ใช้โดย sidechains ซึ่งต้องใช้ สองเครือข่ายที่มีปฏิสัมพันธ์เพื่อรับทราบถึงกันและกันผ่านทาง กระแสข้อมูลแบบสองทิศทางของดาต้าแกรมพิสูจน์การมีอยู่ (ธุรกรรม) โปรโตคอล IBC สามารถกำจัดได้ตามธรรมชาติโดยใช้สองประเภท ธุรกรรม: ธุรกรรม IBCBlockCommitTx  ซึ่งอนุญาตให้ blockchain เพื่อพิสูจน์ให้ผู้สังเกตการณ์เห็นบล็อกล่าสุด-hash และธุรกรรม IBCPacketTx  ซึ่งอนุญาตให้ blockchain พิสูจน์ให้ผู้สังเกตการณ์เห็นว่าแพ็กเก็ตที่ให้มานั้นได้รับการเผยแพร่แล้วจริงๆ โดยแอปพลิเคชันของผู้ส่งผ่านการพิสูจน์ Merkle ไปจนถึงล่าสุด บล็อก-hash. เราแบ่งกลไก IBC ออกเป็นสองธุรกรรมแยกกัน อนุญาตให้มีกลไกตลาดค่าธรรมเนียมดั้งเดิมของห่วงโซ่การรับ กำหนดว่าแพ็กเก็ตใดที่ได้รับการคอมมิต (เช่น ได้รับการยอมรับ) ในขณะที่ ปล่อยให้มีอิสระเต็มที่ในห่วงโซ่การส่งว่าอย่างไร อนุญาตให้ใช้แพ็กเก็ตขาออกจำนวนมาก ในตัวอย่างด้านบน เพื่ออัปเดต block-hash ของ "Zone1" บน “Hub” (หรือของ “Hub” บน “Zone2”), IBCBlockCommitTxธุรกรรมจะต้องโพสต์บน "Hub" ด้วย block-hash of “Zone1” (หรือบน "Zone2" พร้อมด้วยบล็อก-hash ของ “Hub”) ดู IBCBlockCommitTx และ IBCPacketTx สำหรับข้อมูลเพิ่มเติม ในธุรกรรม IBC สองประเภท ในลักษณะเดียวกับที่ Bitcoin มีความปลอดภัยมากขึ้นโดยการกระจาย บัญชีแยกประเภทที่ทำซ้ำจำนวนมาก เราสามารถทำให้การแลกเปลี่ยนมีความเสี่ยงน้อยลง แฮ็กภายนอกและภายในโดยเรียกใช้บน blockchain เรา เรียกสิ่งนี้ว่าการแลกเปลี่ยนแบบกระจาย สิ่งที่ชุมชนสกุลเงินดิจิทัลเรียกว่าการกระจายอำนาจ การแลกเปลี่ยนในปัจจุบันขึ้นอยู่กับบางสิ่งที่เรียกว่าธุรกรรม "atomic crosschain" (AXC) ด้วยธุรกรรม AXC ผู้ใช้สองคนเปิดอยู่ สองเครือข่ายที่แตกต่างกันสามารถทำธุรกรรมการโอนได้สองรายการนั่นคือ มุ่งมั่นร่วมกันในทั้งสองบัญชีแยกประเภทหรือไม่มีเลย (เช่น ในทางอะตอม) ตัวอย่างเช่น ผู้ใช้สองคนสามารถแลกเปลี่ยน bitcoins เป็น ether (หรือ 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.

การใช้งาน

การแลกเปลี่ยนแบบรวมศูนย์สามารถสร้างรายการสั่งซื้อที่มีขีดจำกัดในระดับลึกได้ คำสั่งซื้อและดึงดูดเทรดเดอร์มากขึ้น สภาพคล่องเริ่มเพิ่มมากขึ้น สภาพคล่องในโลกการแลกเปลี่ยนจึงมีเครือข่ายที่แข็งแกร่ง เอฟเฟกต์ (หรืออย่างน้อยก็เอฟเฟกต์ของผู้ชนะ-ได้มากที่สุด) ในการแลกเปลี่ยน ธุรกิจ ผู้นำปัจจุบันสำหรับการแลกเปลี่ยนสกุลเงินดิจิทัลในปัจจุบัน คือ Poloniex ที่มีปริมาณการขายตลอด 24 ชั่วโมงที่ 20 ล้านเหรียญสหรัฐ และอันดับที่สองคือ Bitynex ด้วยปริมาณการซื้อขายตลอด 24 ชั่วโมงที่ 5 ล้านเหรียญสหรัฐ ด้วยเครือข่ายที่แข็งแกร่งเช่นนี้ ผลกระทบ ไม่น่าจะเป็นไปได้สำหรับการแลกเปลี่ยนแบบกระจายอำนาจตาม AXC ชนะปริมาณมากกว่าการแลกเปลี่ยนแบบรวมศูนย์ สำหรับการกระจายอำนาจ การแลกเปลี่ยนเพื่อแข่งขันกับการแลกเปลี่ยนแบบรวมศูนย์ก็จะต้องมี เพื่อรองรับคำสั่งซื้อเชิงลึกที่มีคำสั่งซื้อที่จำกัด มีแต่แจก การแลกเปลี่ยนใน blockchain สามารถให้ได้ Tendermint ให้ประโยชน์เพิ่มเติมในการทำธุรกรรมที่รวดเร็วยิ่งขึ้น กระทำ โดยจัดลำดับความสำคัญของความรวดเร็วโดยไม่เสียสละ ความสอดคล้อง โซนใน Cosmos สามารถวิเคราะห์ธุรกรรมได้อย่างรวดเร็ว ทั้งธุรกรรม Exchange Order และ IBC token โอนไปที่ และจากโซนอื่นๆ เมื่อพิจารณาถึงสถานะของการแลกเปลี่ยนสกุลเงินดิจิตอลในปัจจุบัน ถือว่ายอดเยี่ยมมาก แอปพลิเคชันสำหรับ Cosmos คือการแลกเปลี่ยนแบบกระจาย (หรือที่เรียกว่า Cosmos เดกซ์) ความสามารถในการรับส่งข้อมูลของธุรกรรมเช่นกัน เวลาแฝงที่กระทำสามารถเทียบเคียงได้กับเวลาแฝงแบบรวมศูนย์ การแลกเปลี่ยน เทรดเดอร์สามารถส่งคำสั่งจำกัดที่สามารถดำเนินการได้ โดยที่ทั้งสองฝ่ายไม่ต้องออนไลน์ และด้วยเทนเดอร์มิ้นต์ ฮับ Cosmos และ IBC เทรดเดอร์สามารถโอนเงินเข้าและออกจาก การแลกเปลี่ยนไปและกลับจากโซนอื่นด้วยความรวดเร็ว โซนสิทธิพิเศษสามารถทำหน้าที่เป็นแหล่งที่มาของการเชื่อมต่อ token ของ สกุลเงินดิจิทัลอื่น สะพานก็คล้ายกับความสัมพันธ์ ระหว่างฮับ Cosmos และโซน ทั้งสองจะต้องตามให้ทัน บล็อกล่าสุดของอีกบล็อกหนึ่งเพื่อตรวจสอบหลักฐานที่ tokens มี ย้ายจากที่หนึ่งไปอีกที่หนึ่ง "โซนสะพาน" บน Cosmos เครือข่ายสามารถติดตาม Hub ได้เป็นอย่างดี

สกุลเงินดิจิทัล ทิศทางผ่านโซนสะพานช่วยให้ ตรรกะของ Hub ที่จะคงความเรียบง่ายและไม่เชื่อเรื่องพระเจ้าสำหรับผู้อื่น blockchain กลยุทธ์ที่เป็นเอกฉันท์ เช่น Bitcoin ของ proof-of-work การทำเหมืองแร่ แต่ละบริดจ์โซน validator จะขับเคลื่อนด้วย Tendermint blockchain พร้อมด้วย ABCI บริดจ์แอปพิเศษ แต่ยังเป็นโหนดเต็มของ “ต้นกำเนิด” blockchain เมื่อมีการขุดบล็อกใหม่บนจุดเริ่มต้น โซนสะพาน validators จะบรรลุข้อตกลงเกี่ยวกับบล็อกที่กระทำโดยการลงนาม และแบ่งปันมุมมองในท้องถิ่นของตนเกี่ยวกับ blockchain ของแหล่งกำเนิด ทิป เมื่อโซนบริดจ์ได้รับการชำระเงินจากต้นทาง (และ มีการเห็นพ้องต้องกันอย่างเพียงพอในกรณีนี้ ของห่วงโซ่ PoW เช่น Ethereum หรือ Bitcoin) ที่สอดคล้องกัน บัญชีถูกสร้างขึ้นบนบริดจ์โซนด้วยยอดคงเหลือนั้น ในกรณีของ Ethereum โซนบริดจ์สามารถใช้ร่วมกันได้ validator-ตั้งเป็น Cosmos ฮับ ที่ด้าน Ethereum (the origin) สัญญาสะพานจะอนุญาตให้ผู้ถืออีเทอร์ส่งอีเทอร์ได้ ไปยังเขตสะพานโดยส่งไปที่สัญญาสะพานบน Ethereum. เมื่อสัญญาสะพานได้รับอีเธอร์แล้ว อีเทอร์ไม่สามารถถอนออกได้เว้นแต่จะมีแพ็กเก็ต IBC ที่เหมาะสม ได้รับสัญญาสะพานจากโซนสะพาน ที่ Bridge-contract ติดตาม validator-set ของ Bridge-zone ซึ่ง อาจเหมือนกับชุด Cosmos ของ validator ของ Hub ในกรณีของ Bitcoin แนวคิดจะคล้ายกันยกเว้นว่าแทนที่จะเป็น สัญญาบริดจ์เดียว แต่ละ UTXO จะถูกควบคุมโดย pubscript P2SH แบบหลายลายเซ็นตามเกณฑ์ เนื่องจากข้อจำกัดของ ระบบ P2SH ผู้ลงนามไม่สามารถเหมือนกับ Cosmos ฮับ validator-ชุดอีเธอร์บนบริดจ์โซน (“บริดจ์-อีเทอร์”) สามารถถ่ายโอนไปได้ และจากฮับและต่อมาก็ถูกทำลายด้วยธุรกรรมนั้น ส่งไปยังที่อยู่การถอนเงินเฉพาะใน Ethereum IBC แพ็กเก็ตพิสูจน์ว่าธุรกรรมเกิดขึ้นบนบริดจ์โซน สามารถโพสต์ไปที่ Ethereum สัญญาบริดจ์เพื่ออนุญาตอีเธอร์ ที่จะถูกถอนออก ในกรณีของ Bitcoin ระบบสคริปต์ที่ถูกจำกัดจะทำขึ้นมา ยากที่จะจำลองกลไกการโอนเหรียญ IBC แต่ละ UTXO มี pubscript อิสระของตัวเอง ดังนั้นทุก UTXO จะต้องเป็น ย้ายไปยัง UTXO ใหม่เมื่อมีการเปลี่ยนแปลงในชุดของ Bitcoin ผู้ลงนามเอสโครว์ ทางออกหนึ่งคือการบีบอัดและ ขยาย UTXO-set ตามความจำเป็นเพื่อคงจำนวนทั้งหมดไว้ จาก UTXOs ลง ความเสี่ยงของสัญญาเชื่อมโยงดังกล่าวถือเป็นชุดโกง validator ≥⅓ อำนาจการลงคะแนนแบบไบแซนไทน์อาจทำให้เกิดการแตกแยกและถอนอีเทอร์ได้ จากสัญญาสะพานเมื่อ Ethereum ในขณะที่รักษาสะพานไว้บนโซนสะพาน ที่แย่กว่านั้นคือ >⅔ อำนาจการลงคะแนนแบบไบเซนไทน์สามารถทำได้ ขโมยอีเธอร์ทันทีจากผู้ที่ส่งมันไปที่สัญญาสะพาน โดยการเบี่ยงเบนไปจากตรรกะการบริดจ์ดั้งเดิมของโซนบริดจ์ สามารถแก้ไขปัญหาเหล่านี้ได้ด้วยการออกแบบสะพานให้เป็น รับผิดชอบโดยสิ้นเชิง ตัวอย่างเช่น แพ็กเก็ต IBC ทั้งหมด จากฮับและ ต้นกำเนิดอาจต้องได้รับการตอบรับจากโซนสะพานใน ในลักษณะที่การเปลี่ยนสถานะของโซนบริดจ์ทั้งหมดสามารถทำได้ ถูกท้าทายและตรวจสอบอย่างมีประสิทธิภาพโดยทั้งฮับหรือต้นกำเนิด สัญญาสะพาน ฮับและต้นทางควรอนุญาตให้บริดจ์โซน validators โพสต์หลักประกัน และ token โอนออกจาก สัญญาสะพานควรล่าช้า (และการปลดหลักประกัน ระยะเวลานานเพียงพอ) เพื่อให้สามารถรับมือกับความท้าทายต่างๆ ได้ ผู้ตรวจสอบอิสระ เราทิ้งการออกแบบ speciycation และ การนำระบบนี้ไปใช้ในอนาคต Cosmos

ข้อเสนอการปรับปรุงที่จะส่งผ่านโดย Cosmos Hub's ระบบการกำกับดูแล การแก้ปัญหาการปรับขนาดเป็นปัญหาแบบเปิดสำหรับ Ethereum ปัจจุบัน Ethereum โหนดประมวลผลทุกธุรกรรมและ ยังเก็บทุกรัฐอีกด้วย ลิงค์ เนื่องจาก Tendermint สามารถคอมมิตบล็อกได้เร็วกว่า Ethereum's มาก proof-of-work, EVM โซนขับเคลื่อนโดยฉันทามติของ Tendermint และ การทำงานบนบริดจ์อีเทอร์สามารถให้ประสิทธิภาพที่สูงกว่าได้ Ethereum blockchains. นอกจากนี้ แม้ว่า Cosmos Hub และ IBC กลไกแพ็กเก็ตไม่อนุญาตให้มีตรรกะสัญญาตามอำเภอใจ การดำเนินการต่อ se สามารถใช้เพื่อประสานงานการเคลื่อนไหว token ระหว่าง Ethereum สัญญาที่ทำงานในโซนที่แตกต่างกัน จัดเตรียมรากฐานสำหรับการปรับขนาด token-centric Ethereum ผ่าน การแบ่งส่วน Cosmos โซนเรียกใช้ตรรกะของแอปพลิเคชันตามอำเภอใจ ซึ่งกำหนดไว้ที่ จุดเริ่มต้นของชีวิตของโซนและสามารถอัปเดตได้ เมื่อเวลาผ่านไปโดยการปกครอง zexibility ดังกล่าวอนุญาตให้ Cosmos โซนได้ ทำหน้าที่เป็นสะพานเชื่อมไปยัง cryptocurrencies อื่น ๆ เช่น Ethereum หรือ Bitcoin และยังอนุญาตให้มีอนุพันธ์ของ blockchains เหล่านั้นด้วย ใช้โค้ดเบสเดียวกัน แต่มีชุด validator และที่แตกต่างกัน การกระจายเบื้องต้น สิ่งนี้ทำให้มีสกุลเงินดิจิทัลที่มีอยู่มากมาย เฟรมเวิร์ก เช่น Ethereum, Zerocash, Bitcoin, CryptoNote และอื่นๆ ที่จะนำมาใช้กับ Tendermint Core ซึ่งก็คือ กลไกฉันทามติที่มีประสิทธิภาพสูงกว่าบนเครือข่ายทั่วไป เปิดโอกาสอันยิ่งใหญ่สำหรับการทำงานร่วมกันข้าม แพลตฟอร์ม นอกจากนี้ ในฐานะสินทรัพย์หลายรายการ blockchain เดียว ธุรกรรมอาจมีหลายอินพุตและเอาต์พุตโดยที่แต่ละอินพุต อินพุตสามารถเป็นประเภท token ใดก็ได้ ทำให้ Cosmos ทำหน้าที่โดยตรงเป็น แพลตฟอร์มสำหรับการแลกเปลี่ยนแบบกระจายอำนาจ แม้ว่าจะมีคำสั่งซื้อก็ตามเพื่อจับคู่ผ่านแพลตฟอร์มอื่นๆ หรือจะให้บริการโซนก็ได้ เป็นการแลกเปลี่ยนที่ทนต่อข้อผิดพลาดแบบกระจาย (พร้อมใบสั่งซื้อ) ซึ่ง สามารถปรับปรุงอย่างเข้มงวดเหนือการรวมศูนย์ที่มีอยู่ การแลกเปลี่ยนสกุลเงินดิจิทัลซึ่งมีแนวโน้มที่จะถูกแฮ็กเมื่อเวลาผ่านไป โซนยังสามารถทำหน้าที่เป็นเวอร์ชันขององค์กรที่ได้รับการสนับสนุน blockchain ได้อีกด้วย และระบบราชการซึ่งชิ้นส่วนของบริการเฉพาะนั้น มักจะดำเนินการโดยองค์กรหรือกลุ่มองค์กร จะถูกเรียกใช้เป็นแอปพลิเคชัน ABCI ในบางโซนแทน ซึ่ง ช่วยให้สามารถสืบทอดความปลอดภัยและการทำงานร่วมกันของสาธารณะได้ Cosmos เครือข่ายโดยไม่สูญเสียการควบคุมพื้นฐาน บริการ ดังนั้น Cosmos อาจเสนอสิ่งที่ดีที่สุดของทั้งสองโลกให้ องค์กรที่ต้องการใช้เทคโนโลยี blockchain แต่เป็นใคร ระวังการสละการควบคุมอย่างสมบูรณ์ให้กับบุคคลที่สามแบบกระจาย ปาร์ตี้ บางคนอ้างว่าเป็นปัญหาสำคัญเกี่ยวกับความสม่ำเสมอ อัลกอริธึมที่เป็นเอกฉันท์เช่น Tendermint คือเครือข่ายใดก็ได้ พาร์ติชันซึ่งทำให้ไม่มีพาร์ติชันเดียวที่มี >⅔ อำนาจการลงคะแนนเสียง (เช่น ≥⅓ กำลังจะหมดไป) จะหยุดฉันทามติโดยสิ้นเชิง สถาปัตยกรรม Cosmos สามารถช่วยบรรเทาปัญหานี้ได้โดยใช้ ศูนย์กลางระดับโลกที่มีเขตปกครองตนเองของภูมิภาคซึ่งมีอำนาจในการลงคะแนนเสียง สำหรับแต่ละโซนจะกระจายตามภูมิศาสตร์ทั่วไป ภูมิภาค ตัวอย่างเช่น กระบวนทัศน์ทั่วไปอาจเป็นเรื่องสำหรับบุคคล เมืองหรือภูมิภาคเพื่อดำเนินการโซนของตนเองในขณะที่แบ่งปัน ศูนย์กลางทั่วไป (เช่น Cosmos Hub) ช่วยให้สามารถทำกิจกรรมของเทศบาลได้ คงอยู่ในกรณีที่ฮับหยุดทำงานเนื่องจากเครือข่ายชั่วคราว พาร์ติชัน โปรดทราบว่าสิ่งนี้ช่วยให้เกิดธรณีวิทยา การเมือง และได้อย่างแท้จริง คุณสมบัติทอพอโลยีเครือข่ายที่ต้องพิจารณาในการออกแบบที่แข็งแกร่ง ระบบทนทานต่อข้อผิดพลาดแบบรวมศูนย์

NameCoin เป็นหนึ่งใน blockchains แรกที่พยายามแก้ไขปัญหา ปัญหาการแก้ไขชื่อโดยการปรับ Bitcoin blockchain น่าเสียดายที่แนวทางนี้มีปัญหาหลายประการ ด้วย Namecoin เราสามารถตรวจสอบได้ว่า @satoshi เคยเป็นเช่นนั้น ลงทะเบียนด้วยกุญแจสาธารณะเฉพาะ ณ จุดใดจุดหนึ่งในอดีต แต่เราไม่รู้ว่ารหัสสาธารณะนั้นมีตั้งแต่นั้นมาหรือไม่ อัปเดตเมื่อเร็ว ๆ นี้เว้นแต่เราจะดาวน์โหลดบล็อกทั้งหมดตั้งแต่ครั้งล่าสุด อัปเดตชื่อนั้น นี่เป็นเพราะข้อจำกัดของ Bitcoin's UTXO ธุรกรรมรูปแบบ Merkle-ization โดยที่เท่านั้น ธุรกรรม (แต่ไม่ใช่สถานะแอปพลิเคชันที่ไม่แน่นอน) เป็นแบบ Merkle เข้าไปในบล็อก-hash สิ่งนี้ช่วยให้เราพิสูจน์ได้ว่ามีอยู่จริง แต่ไม่ใช่การไม่มีการอัปเดตชื่อในภายหลัง ดังนั้นเราจึงไม่สามารถรู้ได้ ตรวจสอบค่าล่าสุดของชื่อโดยไม่ต้องเชื่อถือเต็ม โหนดหรือทำให้เกิดค่าใช้จ่ายแบนด์วิดท์ที่สำคัญโดยการดาวน์โหลด ทั้งหมด blockchain แม้ว่าแผนผังการค้นหาแบบ Merkle-ized จะถูกนำมาใช้ใน NameCoin ก็ตาม การพึ่งพา proof-of-work ทำให้การตรวจสอบไคลเอ็นต์แบบเบา มีปัญหา ลูกค้า Light ต้องดาวน์โหลดสำเนาที่สมบูรณ์ของ ส่วนหัวสำหรับบล็อกทั้งหมดใน blockchain ทั้งหมด (หรืออย่างน้อยทั้งหมด ส่วนหัวตั้งแต่การอัปเดตชื่อครั้งล่าสุด) ซึ่งหมายความว่า ความต้องการแบนด์วิธจะปรับขนาดเป็นเส้นตรงกับระยะเวลา [21]. นอกจากนี้ การเปลี่ยนชื่อใน proof-of-work blockchain ต้องรอบล็อกการเชื่อมต่อ proof-of-work เพิ่มเติม ซึ่งอาจใช้เวลาถึงหนึ่งชั่วโมงใน Bitcoin ด้วย Tendermint สิ่งเดียวที่เราต้องการคือบล็อกล่าสุด-hash ลงนามโดยองค์ประชุม validators (ตามอำนาจการลงคะแนน) และ Merkle พิสูจน์ถึงมูลค่าปัจจุบันที่เกี่ยวข้องกับชื่อ แค่นี้ก็ทำให้ เป็นไปได้ที่จะมี light-client ที่กระชับ รวดเร็ว และปลอดภัย การยืนยันค่าชื่อ ใน Cosmos เราสามารถนำแนวคิดนี้ไปขยายเพิ่มเติมได้ แต่ละ โซนการลงทะเบียนชื่อใน Cosmos สามารถมีชื่อโดเมนระดับบนสุด (TLD) ที่เกี่ยวข้อง เช่น “.com” หรือ “.org” และแต่ละชื่อ-

โซนการลงทะเบียนสามารถมีการปกครองและการลงทะเบียนของตนเองได้ กฎ

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 Hub จะเป็นบัญชีแยกประเภทแบบกระจายหลายสินทรัพย์ แต่ก็มีอยู่ token พื้นเมืองพิเศษที่เรียกว่าอะตอม อะตอมเป็นเพียง staking token ของ Cosmos ฮับ อะตอมเป็นใบอนุญาตสำหรับผู้ถือ โหวต ตรวจสอบ หรือมอบหมายให้ validators อื่น ๆ ชอบ Ethereum อีเทอร์ อะตอมยังสามารถใช้เพื่อชำระค่าธรรมเนียมการทำธุรกรรมได้ ลดปัญหาสแปม อะตอม inzationary เพิ่มเติมและบล็อกธุรกรรม ค่าธรรมเนียมจะมอบให้กับ validators และผู้มอบหมายที่มอบหมายให้ validatorส. ธุรกรรม  BurnAtomTx  สามารถใช้เพื่อกู้คืนรายการใดก็ได้ จำนวนตามสัดส่วนของ tokens จากพูลสำรอง การกระจายเริ่มต้นของอะตอม tokens และ validators บน Genesis จะมอบให้กับผู้บริจาคของ Cosmos Fundraiser (75%) ผู้บริจาคหลัก (5%), Cosmos รากฐานเครือข่าย (10%) และ ALL IN BITS, Inc. (10%) ตั้งแต่กำเนิดเป็นต้นไป จะมี 1/3 ของจำนวนอะตอมทั้งหมด ได้รับรางวัลสำหรับ validators และผู้ได้รับมอบหมายที่ถูกผูกมัดทุกปี ดูแผน Cosmos สำหรับรายละเอียดเพิ่มเติม ต่างจาก Bitcoin หรือ proof-of-work blockchains อื่นๆ ที่เป็น Tendermint blockchain ช้าลงด้วย validators ที่มากขึ้นเนื่องจากการเพิ่มขึ้น ความซับซ้อนในการสื่อสาร โชคดีเรารองรับได้มากพอ validators เพื่อสร้างการกระจายทั่วโลกที่แข็งแกร่ง blockchain ด้วยเวลาการทำธุรกรรมที่รวดเร็วมากและในฐานะแบนด์วิธ

พื้นที่เก็บข้อมูลและความสามารถในการประมวลผลแบบขนานเพิ่มขึ้น เราก็สามารถทำได้ เพื่อสนับสนุน validators เพิ่มเติมในอนาคต ในวันที่กำเนิด จำนวนสูงสุดของ validators จะถูกตั้งค่าเป็น 100 และตัวเลขนี้จะเพิ่มขึ้นในอัตรา 13% เป็นเวลา 10 ปี และ ชำระที่ 300 validators ผู้ถือ Atom ที่ยังไม่ได้สามารถเป็น validators ได้ การลงนามและส่งธุรกรรม  BondTx จำนวน อะตอมที่เป็นหลักประกันจะต้องไม่เป็นศูนย์ ใครๆ ก็สามารถเป็นได้ validator ได้ตลอดเวลา ยกเว้นเมื่อขนาดของกระแส validator ชุดมากกว่าจำนวนสูงสุด validators ได้รับอนุญาต ในกรณีนั้น ธุรกรรมจะมีผลก็ต่อเมื่อจำนวนเงิน อะตอมมีค่ามากกว่าปริมาณอะตอมที่มีประสิทธิผลที่ถือโดย validator ที่เล็กที่สุด โดยที่อะตอมที่มีประสิทธิผลรวมถึงอะตอมที่ได้รับมอบหมายด้วย เมื่อ validator ใหม่แทนที่ validator ที่มีอยู่ในลักษณะดังกล่าว validator ที่มีอยู่จะไม่ใช้งานและอะตอมทั้งหมดและ อะตอมที่ได้รับมอบหมายจะเข้าสู่สถานะที่ไม่มีพันธะ จะต้องมีการลงโทษสำหรับ validators สำหรับสิ่งใดก็ตาม การเบี่ยงเบนโดยเจตนาหรือไม่ตั้งใจจากการลงโทษ โปรโตคอล หลักฐานบางอย่างสามารถยอมรับได้ทันที เช่น ก เครื่องหมายสองครั้งที่สูงและกลมเท่ากันหรือฝ่าฝืน ปีที่ 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 ใน กองสำรอง – เรียกรวมกันว่า “เดิมพัน” – จะถูกเฉือน บางครั้ง validators จะไม่สามารถใช้งานได้ เนื่องจากภูมิภาค การหยุดชะงักของเครือข่าย ไฟฟ้าขัดข้อง หรือสาเหตุอื่นๆ ถ้าอย่างใดอย่างหนึ่ง ชี้ไปที่บล็อก  ValidatorTimeoutWindow  ที่ผ่านมา ซึ่งเป็น validator การลงคะแนนเสียงจะไม่รวมอยู่ใน blockchain มากกว่า  ValidatorTimeoutMaxAbsent  ครั้งที่ validator จะกลายเป็น ไม่ได้ใช้งาน และเสีย ValidatorTimeoutPenalty  (ค่าเริ่มต้น 1%) สัดส่วนการถือหุ้น พฤติกรรม "ที่เป็นอันตราย" บางอย่างไม่ได้ทำให้มองเห็นได้ชัดเจน หลักฐานใน blockchain ในกรณีเหล่านี้ validators สามารถทำได้ ประสานงานนอกแบนด์เพื่อบังคับให้หมดเวลาของผู้ที่เป็นอันตรายเหล่านี้ validators หากมีฉันทามติที่คนส่วนใหญ่เห็นด้วย ในสถานการณ์ที่ Cosmos Hub หยุดทำงานเนื่องจากการรวมตัวกัน ≥⅓ ของ อำนาจการลงคะแนนเสียงหมดไป หรือในสถานการณ์ที่มีแนวร่วม ≥⅓ จากการเซ็นเซอร์หลักฐานการลงคะแนนเสียงพฤติกรรมที่เป็นอันตรายจาก เมื่อเข้าสู่ blockchain ฮับจะต้องกู้คืนด้วยการฮาร์ดฟอร์ก ข้อเสนอ reorg (ลิงก์ไปยัง “การโจมตีทางแยกและการเซ็นเซอร์”) Cosmos ฮับ validators สามารถยอมรับประเภท token ใดๆ หรือการรวมกัน ประเภทเป็นค่าธรรมเนียมในการทำธุรกรรม validator แต่ละอันสามารถ กำหนดอัตราแลกเปลี่ยนที่ต้องการตามใจชอบแล้วเลือก ธุรกรรมใดก็ตามที่ต้องการ ตราบใดที่ BlockGasLimit  ยังคงอยู่ ไม่เกิน. ค่าธรรมเนียมที่เรียกเก็บ ลบภาษีใด ๆ ที่ระบุด้านล่าง จะถูกแจกจ่ายให้กับผู้มีส่วนได้ส่วนเสียที่ถูกผูกมัดตามสัดส่วน อะตอมที่ถูกผูกมัด ทุก ๆ ValidatorPayoutPeriod  (ค่าเริ่มต้น 1 ชั่วโมง)จากค่าธรรมเนียมการทำธุรกรรมที่เรียกเก็บ  ReserveTax  (ค่าเริ่มต้น 2%) ไปที่กองสำรองเพื่อเพิ่มกองสำรองและ เพิ่มความปลอดภัยและมูลค่าของเครือข่าย Cosmos เหล่านี้ สามารถกระจายกองทุนได้ตามการตัดสินใจ จัดทำโดยระบบการปกครอง ผู้ถือ Atom ที่มอบอำนาจการลงคะแนนของตนให้กับ validators อื่น ๆ จ่ายค่าคอมมิชชันให้กับผู้ได้รับมอบหมาย validator ค่าคอมมิชชั่นก็ได้ ถูกตั้งค่าโดยแต่ละ validator การรักษาความปลอดภัยของ Cosmos Hub เป็นฟังก์ชันของการรักษาความปลอดภัยของ validators พื้นฐานและการเลือกการมอบหมายโดยผู้มอบหมาย เพื่อส่งเสริมให้มีการค้นพบและรายงานสิ่งที่ค้นพบตั้งแต่เนิ่นๆ ช่องโหว่ Cosmos Hub สนับสนุนให้แฮกเกอร์เผยแพร่ การหาประโยชน์ที่ประสบความสำเร็จผ่านธุรกรรม ReportHackTx ที่ระบุว่า “นี่ validator ถูกแฮ็ก กรุณาส่งของรางวัลมาตามที่อยู่นี้” เมื่อ การใช้ประโยชน์ดังกล่าว validator และผู้รับมอบสิทธิ์จะไม่ใช้งาน  HackPunishmentRatio  (ค่าเริ่มต้น 5%) ของอะตอมของทุกคนจะได้รับ เฉือนและ  HackRewardRatio  (ค่าเริ่มต้น 5%) ของอะตอมของทุกคน จะได้รับรางวัลตามที่อยู่ค่าหัวของแฮกเกอร์ validator ต้องกู้คืนอะตอมที่เหลือโดยใช้คีย์สำรอง เพื่อป้องกันไม่ให้คุณลักษณะนี้ถูกละเมิดในการถ่ายโอน อะตอมที่ยังไม่ได้ลงทุน ส่วนของอะตอมที่ตกเป็นของเทียบกับที่ยังไม่ได้เป็นของ validators และผู้รับมอบสิทธิ์ก่อนและหลัง  ReportHackTx  จะ ยังคงเหมือนเดิม และความโปรดปรานของแฮ็กเกอร์จะรวมอยู่ด้วย อะตอมที่ยังไม่ได้ลงทุน ถ้ามี Cosmos Hub ดำเนินการโดยองค์กรแบบกระจายที่ จำเป็นต้องมีกลไกการกำกับดูแลที่ดีเพื่อที่จะ ประสานการเปลี่ยนแปลงต่างๆ กับ blockchain เช่น ตัวแปร

พารามิเตอร์ของระบบตลอดจนการอัพเกรดซอฟต์แวร์และ การแก้ไขรัฐธรรมนูญ validators ทั้งหมดมีหน้าที่ลงคะแนนเสียงในข้อเสนอทั้งหมด ล้มเหลวที่จะ โหวตข้อเสนอในเวลาที่เหมาะสมจะส่งผลให้ validator ถูกปิดการใช้งานโดยอัตโนมัติเป็นระยะเวลาหนึ่งเรียกว่า  การขาดเรียนระยะเวลาการลงโทษ  (ค่าเริ่มต้น 1 สัปดาห์) ผู้รับมอบสิทธิ์จะสืบทอดคะแนนเสียงของผู้รับมอบสิทธิ์โดยอัตโนมัติ validator. การลงคะแนนเสียงนี้อาจถูกแทนที่ด้วยตนเอง อะตอมที่ไม่มีพันธะ ไม่ได้รับการลงคะแนน ข้อเสนอแต่ละรายการกำหนดให้มีเงินฝากขั้นต่ำสำหรับข้อเสนอขั้นต่ำ  tokens ซึ่งอาจเป็นการรวมกันของ tokens ตั้งแต่หนึ่งรายการขึ้นไป รวมทั้งอะตอมด้วย สำหรับแต่ละข้อเสนอ ผู้ลงคะแนนเสียงอาจลงคะแนนเสียงรับ เงินฝาก หากผู้มีสิทธิเลือกตั้งเกินครึ่งเลือกที่จะรับ เงินฝาก (เช่น เนื่องจากข้อเสนอเป็นสแปม) เงินฝากจะไปที่ แหล่งสำรอง ยกเว้นอะตอมใดๆ ที่ถูกเผา สำหรับแต่ละข้อเสนอ ผู้ลงคะแนนอาจลงคะแนนเสียงด้วยตัวเลือกต่อไปนี้: ใช่ ใช่แล้วด้วย Force ไม่นะ ไม่ด้วยForce งดเว้น เสียงส่วนใหญ่ของ Yea หรือ YeaWithForce ที่เข้มงวด (หรือ Nay หรือ NayWithForce โหวต) เป็นสิ่งจำเป็นสำหรับข้อเสนอที่จะตัดสินใจเป็น ผ่าน (หรือตัดสินว่าล้มเหลว) แต่ 1/3+ สามารถยับยั้งคนส่วนใหญ่ได้ การตัดสินใจโดยการลงคะแนนเสียง “อย่างใช้กำลัง” เมื่อเสียงข้างมากถูกยับยั้ง ทุกคนจะถูกลงโทษโดยการสูญเสีย VetoPenaltyFeeBlocks  (มูลค่าบล็อกเริ่มต้น 1 วัน) มูลค่าค่าธรรมเนียม (ยกเว้นภาษี ซึ่งจะไม่ได้รับผลกระทบ) และฝ่ายที่วีโต้เสียงข้างมาก

การตัดสินจะถูกลงโทษเพิ่มเติมโดยการสูญเสีย VetoPenaltyAtoms  (ค่าเริ่มต้น 0.1%) ของอะตอม พารามิเตอร์ใดๆ ที่กำหนดไว้ที่นี่สามารถเปลี่ยนแปลงได้ด้วย การส่งผ่าน  ParameterChangeProposal  อะตอมสามารถถูกเผาและสำรองกองทุนรวมที่ใช้ไปกับ การผ่าน  BountyProposal  ข้อเสนออื่นๆ ทั้งหมด เช่น ข้อเสนอเพื่ออัปเกรดโปรโตคอล จะได้รับการประสานงานผ่าน  TextProposal  ทั่วไป ดูแผน มีนวัตกรรมมากมายใน blockchain ฉันทามติและ ความสามารถในการขยายขนาดในช่วงสองสามปีที่ผ่านมา ส่วนนี้จะให้ข้อมูลโดยย่อ สำรวจประเด็นสำคัญที่เลือกไว้จำนวนหนึ่ง ฉันทามติต่อหน้าผู้เข้าร่วมที่เป็นอันตรายเป็นปัญหา ย้อนกลับไปในช่วงต้นทศวรรษ 1980 เมื่อเลสลี แลมพอร์ตประกาศเกียรติคุณ วลี “Byzantine Fault” เพื่ออ้างถึงพฤติกรรมกระบวนการตามอำเภอใจนั้น เบี่ยงเบนไปจากพฤติกรรมที่ตั้งใจไว้ ตรงกันข้ามกับ "ความผิดพลาดจากการชน" โดยที่กระบวนการก็ขัดข้อง มีการค้นพบวิธีแก้ปัญหาเบื้องต้น สำหรับเครือข่ายซิงโครนัสที่มีขอบเขตบนเวลาแฝงของข้อความ แม้ว่าการใช้งานจริงจะถูกจำกัดไว้ที่ระดับสูงก็ตาม สภาพแวดล้อมที่มีการควบคุม เช่น เครื่องควบคุมเครื่องบิน และ ศูนย์ข้อมูลซิงโครไนซ์ผ่านนาฬิกาอะตอม มันไม่ได้เป็นเช่นนั้นจนกระทั่ง ช่วงปลายยุค 90 ที่ค่าเผื่อความผิดพลาดของไบเซนไทน์ในทางปฏิบัติ (PBFT) [11] คือ แนะนำเป็นฉันทามติแบบซิงโครนัสบางส่วนที่มีประสิทธิภาพ อัลกอริธึมสามารถทนต่อพฤติกรรมของกระบวนการได้ถึง⅓ โดยพลการ PBFT กลายเป็นอัลกอริธึมมาตรฐานซึ่งมีอยู่มากมาย รูปแบบต่างๆ รวมถึงรูปแบบล่าสุดที่สร้างโดย IBM โดยเป็นส่วนหนึ่งของ การมีส่วนร่วมของพวกเขาใน Hyperledger ประโยชน์หลักของฉันทามติของ Tendermint เหนือ PBFT ก็คือ Tendermint มีโครงสร้างพื้นฐานที่ดีขึ้นและเรียบง่ายขึ้น บางส่วนเป็นผลมาจากการยอมรับกระบวนทัศน์ blockchain บล็อก Tendermint จะต้องดำเนินการตามลำดับ ซึ่งจะขัดขวาง ความซับซ้อนและค่าใช้จ่ายในการสื่อสารที่เกี่ยวข้องกับ PBFT's มุมมองการเปลี่ยนแปลง ใน Cosmos และ cryptocurrencies มากมายไม่มี จำเป็นต้องอนุญาตให้บล็อก N+i โดยที่ i >= 1 กระทำ เมื่อบล็อก N ตัวเองยังไม่ได้กระทำ หากแบนด์วิธเป็นเหตุให้บล็อก N ไม่ได้คอมมิตในโซน Cosmos ดังนั้นจึงไม่มีประโยชน์ในการใช้งาน การโหวตการแบ่งปันแบนด์วิธสำหรับบล็อก N+i หากเป็นพาร์ติชันเครือข่ายหรือ โหนด ofzine คือเหตุผลว่าทำไม block N จึงไม่คอมมิต N+ฉันจะไม่กระทำอยู่แล้ว นอกจากนี้ การแบ่งกลุ่มธุรกรรมเป็นบล็อกยังช่วยให้ทำได้ Merkle-hashing ของสถานะแอปพลิเคชันปกติ แทนที่จะเป็น การแยกย่อยเป็นระยะเช่นเดียวกับแผนการตรวจสอบของ PBFT สิ่งนี้ช่วยให้ เพื่อธุรกรรมที่พิสูจน์ได้เร็วยิ่งขึ้นสำหรับลูกค้ารายย่อยและรวดเร็วยิ่งขึ้น การสื่อสารระหว่าง-blockchain Tendermint Core ยังมีการเพิ่มประสิทธิภาพและฟีเจอร์มากมายอีกด้วย ที่เหนือกว่าสิ่งที่ระบุไว้ใน PBFT ตัวอย่างเช่น บล็อกที่เสนอโดย validators ถูกแบ่งออกเป็นส่วน ๆ Merkle-ized และซุบซิบในลักษณะที่ทำให้การออกอากาศดีขึ้น ประสิทธิภาพ (ดู LibSwift [19] สำหรับแรงบันดาลใจ) เทนเดอร์มิ้นต์ อีกด้วย Core ไม่ได้ตั้งสมมติฐานเกี่ยวกับจุดต่อจุด

การเชื่อมต่อและฟังก์ชั่นต่างๆ ตราบเท่าที่เครือข่าย P2P ยังคงอยู่ เชื่อมต่ออย่างอ่อนแอ แม้ว่าจะไม่ใช่ปีแรกที่ปรับใช้ proof-of-stake (PoS) แต่ BitShares1.0 [12] มีส่วนอย่างมากในการวิจัยและการนำ PoS มาใช้ blockchains โดยเฉพาะอย่างยิ่งที่รู้จักกันในชื่อ PoS "ที่ได้รับมอบสิทธิ์" ใน BitShares ผู้มีส่วนได้ส่วนเสียเลือก "พยาน" ซึ่งรับผิดชอบในการสั่งซื้อ และการทำธุรกรรมและ "ผู้รับมอบสิทธิ์" รับผิดชอบ การประสานงานการอัปเดตซอฟต์แวร์และการเปลี่ยนแปลงพารามิเตอร์ BitShares2.0 มุ่งหวังที่จะบรรลุประสิทธิภาพสูง (100k tx/s, 1s เวลาแฝง) ในสภาวะที่เหมาะสม โดยแต่ละบล็อกลงนามโดยบล็อกเดียว ผู้ลงนามและการทำธุรกรรมใช้เวลานานกว่าเล็กน้อย ช่วงเวลาบล็อก ข้อมูลจำเพาะแบบ Canonical ยังอยู่ในระหว่างการพัฒนา ผู้มีส่วนได้ส่วนเสียสามารถถอดถอนหรือเปลี่ยนพยานที่ประพฤติมิชอบได้ที่ ทุกวัน แต่ไม่มีหลักประกันที่เป็นสาระสำคัญของพยานหรือ ผู้เข้าร่วมประชุมที่มีลักษณะเหมือน Tendermint PoS ที่ถูกเฉือนเข้ามา กรณีการโจมตีแบบใช้จ่ายสองครั้งสำเร็จ จากแนวทางที่ Ripple บุกเบิก Stellar [13] ได้ดำเนินการ รูปแบบของข้อตกลง Federated Byzantine ซึ่งกระบวนการต่างๆ การมีส่วนร่วมในฉันทามติไม่ถือเป็น yxed และทั่วโลก ชุดที่รู้จัก แต่แต่ละโหนดกระบวนการจะดูแลจัดการอย่างน้อยหนึ่งรายการ “ส่วนองค์ประชุม” แต่ละส่วนประกอบด้วยชุดกระบวนการที่เชื่อถือได้ ก “องค์ประชุม” ใน Stellar ถูกกำหนดให้เป็นชุดของโหนดที่มี อย่างน้อยหนึ่งส่วนโควรัมสำหรับแต่ละโหนดในชุดเช่นนั้น สามารถบรรลุข้อตกลงได้ ความปลอดภัยของกลไก Stellar ขึ้นอยู่กับสมมติฐาน จุดตัดกันของโควรัมทั้งสองนั้นไม่ว่างเปล่า ในขณะที่ ความพร้อมใช้งานของโหนดต้องมีองค์ประกอบควอรัมอย่างน้อยหนึ่งชิ้น ประกอบด้วยโหนดที่ถูกต้องทั้งหมด ทำให้เกิดการแลกเปลี่ยนระหว่าง โดยใช้โควรัมชิ้นใหญ่หรือเล็กที่อาจรักษาสมดุลได้ยาก โดยไม่ตั้งสมมติฐานที่สำคัญเกี่ยวกับความไว้วางใจ ท้ายที่สุดแล้วโหนดจะต้องเลือกส่วนโควรัมให้เพียงพอ มีความทนทานต่อข้อผิดพลาดอย่างเพียงพอ (หรือ "โหนดที่ไม่เสียหาย" เลย ผลลัพธ์ของรายงานส่วนใหญ่ขึ้นอยู่กับ) และเพียงอย่างเดียว กลยุทธ์ที่ให้ไว้เพื่อให้แน่ใจว่าการกำหนดค่าดังกล่าวเป็นแบบลำดับชั้น และคล้ายกับ Border Gateway Protocol (BGP) ซึ่งใช้โดย ISP ระดับบนสุดบนอินเทอร์เน็ตเพื่อสร้างตารางเส้นทางทั่วโลก และโดย ที่ใช้โดยเบราว์เซอร์เพื่อจัดการใบรับรอง TLS ทั้งฉาวโฉ่ สำหรับความไม่มั่นคงของพวกเขา การวิพากษ์วิจารณ์ในรายงาน Stellar ของระบบพิสูจน์การเดิมพันที่ใช้ Tendermint ได้รับการบรรเทาลงโดยกลยุทธ์ token ที่อธิบายไว้ ที่นี่ซึ่งมีการออก token ประเภทใหม่ที่เรียกว่าอะตอมออกมา เป็นตัวแทนของการเรียกร้องค่าธรรมเนียมและผลตอบแทนในอนาคต ที่ ข้อดีของ proof-of-stake ที่ใช้ Tendermint นั้นสัมพันธ์กัน ความเรียบง่ายแต่ยังคงให้ความปลอดภัยที่เพียงพอและพิสูจน์ได้ การค้ำประกัน BitcoinNG เป็นการปรับปรุงที่เสนอสำหรับ Bitcoin ที่จะช่วยให้ สำหรับรูปแบบของความสามารถในการขยายแนวตั้ง เช่น การเพิ่มขนาดบล็อก โดยไม่มีผลกระทบด้านลบทางเศรษฐกิจที่เกี่ยวข้องโดยทั่วไป กับการเปลี่ยนแปลงดังกล่าว เช่น ผลกระทบใหญ่อย่างไม่สมส่วน บนคนงานเหมืองขนาดเล็ก การปรับปรุงนี้ทำได้โดยการแยก การเลือกตั้งผู้นำจากการออกอากาศรายการ: ผู้นำเป็นปีแรก เลือกโดย proof-of-work ใน "ไมโครบล็อก" แล้วจึงสามารถทำได้ การทำธุรกรรมออกอากาศจะต้องกระทำจนกว่าจะมีไมโครบล็อกใหม่ พบแล้ว ซึ่งจะช่วยลดความต้องการแบนด์วิธที่จำเป็น ชนะการแข่งขัน PoW ช่วยให้นักขุดรายย่อยสามารถแข่งขันได้อย่างยุติธรรมมากขึ้น และช่วยให้การทำธุรกรรมมีความสม่ำเสมอมากขึ้นโดย คนขุดแร่คนสุดท้ายที่จะค้นพบไมโครบล็อก Casper [16] เป็นอัลกอริทึมที่เป็นเอกฉันท์ proof-of-stake ที่เสนอสำหรับ Ethereum. โหมดการดำเนินงานที่สำคัญคือ “ฉันทามติต่อการเดิมพัน” โดย ปล่อยให้ validators เดิมพันซ้ำ ๆ ว่าบล็อกใดที่พวกเขาเชื่อว่าจะทำได้

มุ่งมั่นใน blockchain ตามการเดิมพันอื่นๆ ที่พวกเขาได้เห็นมาจนถึงตอนนี้ ความเป็น ynality ก็สามารถบรรลุได้ในที่สุด ลิงค์ นี่เป็นงานวิจัยที่ดำเนินการโดยทีมแคสเปอร์ ที่ ความท้าทายคือการสร้างกลไกการเดิมพันที่สามารถเป็นได้ ได้รับการพิสูจน์แล้วว่าเป็นกลยุทธ์ที่มีความมั่นคงทางวิวัฒนาการ ประโยชน์หลักของ แคสเปอร์เมื่อเทียบกับ Tendermint อาจเสนอ "ความพร้อม" เกินความสม่ำเสมอ” - ฉันทามติไม่จำเป็นต้องมีองค์ประชุม >⅔ ของ อำนาจในการลงคะแนนเสียง - อาจต้องแลกกับความเร็วในการกระทำการหรือ ความซับซ้อนในการดำเนินการ Interledger Protocol [14] ไม่ใช่โซลูชันด้านความสามารถในการปรับขนาดอย่างเคร่งครัด มัน ให้การทำงานร่วมกันเฉพาะกิจระหว่างบัญชีแยกประเภทที่แตกต่างกัน ผ่านเครือข่ายความสัมพันธ์ทวิภาคีที่เชื่อมโยงอย่างหลวมๆ เช่นเดียวกับ Lightning Network จุดประสงค์ของ ILP คือการอำนวยความสะดวก การชำระเงิน แต่จะเน้นไปที่การชำระเงินที่แตกต่างกันโดยเฉพาะ ประเภทบัญชีแยกประเภทและขยายกลไกการทำธุรกรรมแบบอะตอมมิกไปที่ รวมถึงไม่เพียงแต่ hash-ล็อค แต่ยังรวมถึงองค์ประชุมของโนตารีด้วย (เรียกว่า พิธีสารการขนส่งปรมาณู) กลไกหลังสำหรับ การบังคับใช้อะตอมมิกซิตีในธุรกรรมระหว่างบัญชีแยกประเภทก็คล้ายคลึงกับ กลไก SPV แบบ light-client ของ Tendermint จึงเป็นภาพประกอบของ รับประกันความแตกต่างระหว่าง ILP และ Cosmos/IBC และ ที่ให้ไว้ด้านล่าง 1. เอกสารรับรองของตัวเชื่อมต่อใน ILP ไม่รองรับการเป็นสมาชิก เปลี่ยนแปลงและไม่อนุญาตให้มีการถ่วงน้ำหนักแบบ zexible ระหว่าง ทนายความ ในทางกลับกัน IBC ได้รับการออกแบบมาโดยเฉพาะสำหรับ blockchains โดยที่ validators สามารถมีน้ำหนักที่แตกต่างกัน และ โดยที่สมาชิกสามารถเปลี่ยนแปลงได้ตลอดหลักสูตร blockchain. 2. เช่นเดียวกับใน Lightning Network ผู้รับการชำระเงินใน ILP ต้องออนไลน์เพื่อส่งคอนคอนกลับไปยังผู้ส่ง ในกtoken โอนผ่าน IBC ซึ่งเป็นชุด validator ของผู้รับ blockchain มีหน้าที่รับผิดชอบในการให้ข้อมูลร่วมกัน ไม่ใช่ ผู้ใช้ที่ได้รับ 3. ความแตกต่างที่ชัดเจนที่สุดคือตัวเชื่อมต่อของ ILP ไม่ใช่ รับผิดชอบหรือรักษาสถานะเผด็จการเกี่ยวกับการชำระเงิน ในขณะที่ Cosmos validators ของฮับเป็นผู้มีอำนาจ สถานะของ IBC token การโอน เช่นเดียวกับอำนาจของ จำนวน tokens ที่ถือโดยแต่ละโซน (แต่ไม่ใช่จำนวน tokens ถือโดยแต่ละบัญชีภายในโซน) นี่คือ นวัตกรรมพื้นฐานที่ช่วยให้มีความปลอดภัยไม่สมมาตร ถ่ายโอน tokens จากโซนหนึ่งไปอีกโซนหนึ่ง อะนาล็อกของ ILP ตัวเชื่อมต่อใน Cosmos เป็นแบบถาวรและปลอดภัยสูงสุด blockchain บัญชีแยกประเภท Cosmos ฮับ 4. การชำระเงินระหว่างบัญชีแยกประเภทใน ILP จะต้องได้รับการสนับสนุนจาก สมุดคำสั่งแลกเปลี่ยนเนื่องจากไม่มีการถ่ายโอนแบบไม่สมมาตร เหรียญจากบัญชีแยกประเภทหนึ่งไปยังอีกบัญชีหนึ่งเฉพาะการโอนมูลค่าหรือ เทียบเท่ากับตลาด Sidechains [15] เป็นกลไกที่นำเสนอสำหรับการปรับขนาด Bitcoin เครือข่ายผ่านทางเลือก blockchains ที่ "ตรึงไว้สองทาง" Bitcoin blockchain. (การตรึงแบบสองทางเทียบเท่ากับ การเชื่อมโยง ใน Cosmos เราพูดว่า "การเชื่อมโยง" เพื่อแยกความแตกต่างจากการเชื่อมโยงการตลาด) Sidechains อนุญาตให้ bitcoins ย้ายจาก Bitcoin blockchain ไปยัง sidechain และ back และอนุญาต การทดลองคุณสมบัติใหม่บนไซด์เชน เช่นเดียวกับใน Cosmos ฮับ ไซด์เชน และ Bitcoin ทำหน้าที่เป็น light-client ของ ซึ่งกันและกันโดยใช้หลักฐาน SPV เพื่อกำหนดว่าเหรียญควรเป็นเมื่อใด ถ่ายโอนไปยังไซด์เชนและด้านหลัง แน่นอน ตั้งแต่ Bitcoin ใช้ proof-of-work ไซด์เชนที่มีศูนย์กลางอยู่ที่ Bitcoin ต้องทนทุกข์ทรมาน จากปัญหาและความเสี่ยงมากมายของ proof-of-work ในฐานะ กลไกฉันทามติ นอกจากนี้ นี่คือ Bitcoin-maximalist โซลูชันที่ไม่รองรับ tokens และ

โทโพโลยีเครือข่ายระหว่างโซนเช่นเดียวกับที่ Cosmos ทำ ที่กล่าวว่าแกนกลาง กลไกของหมุดสองทางก็มีหลักการเหมือนกัน ทำงานโดยเครือข่าย Cosmos Ethereum กำลังค้นคว้ากลยุทธ์ต่างๆ มากมาย เพื่อแบ่งสถานะของ Ethereum blockchain ไปยังที่อยู่ ความต้องการความสามารถในการขยายขนาด ความพยายามเหล่านี้มีเป้าหมายในการรักษา เลเยอร์นามธรรมที่นำเสนอโดย Ethereum Virtual Machine ปัจจุบัน ทั่วพื้นที่ของรัฐที่ใช้ร่วมกัน มีความพยายามวิจัยหลายประการ กำลังดำเนินการอยู่ในขณะนี้ [18][22] Cosmos และ Ethereum 2.0 Mauve [22] มีเป้าหมายการออกแบบที่แตกต่างกัน Cosmos มีความเฉพาะเจาะจงเกี่ยวกับ tokens สีม่วงเป็นเรื่องเกี่ยวกับการปรับขนาด การคำนวณทั่วไป Cosmos ไม่ได้เชื่อมโยงกับ EVM ดังนั้นแม้แต่ VM ที่แตกต่างกันก็สามารถทำได้ ทำงานร่วมกัน Cosmos ให้ผู้สร้างโซนกำหนดว่าใครเป็นผู้ตรวจสอบ โซน ทุกคนสามารถเริ่มโซนใหม่ใน Cosmos (ยกเว้นการกำกับดูแล ตัดสินใจเป็นอย่างอื่น) ฮับแยกความล้มเหลวของโซน ดังนั้นค่าคงที่ token ส่วนกลางจึงเป็นเช่นนั้น เก็บรักษาไว้ Lightning Network เป็นเครือข่ายการถ่ายโอน token ที่นำเสนอ ทำงานที่เลเยอร์เหนือ Bitcoin blockchain (และสาธารณะอื่นๆ blockchains) ทำให้สามารถปรับปรุงลำดับความสำคัญได้มากมาย ในการทำธุรกรรมโดยการย้ายธุรกรรมส่วนใหญ่ นอกบัญชีแยกประเภทที่เป็นเอกฉันท์ไปสู่สิ่งที่เรียกว่า "ช่องทางการชำระเงิน"สิ่งนี้เกิดขึ้นได้โดยใช้สคริปต์สกุลเงินดิจิทัลออนไลน์ซึ่ง ช่วยให้ฝ่ายต่างๆ สามารถทำสัญญาเก็บสถานะทวิภาคีได้ โดยที่ สถานะสามารถอัปเดตได้โดยการแชร์ลายเซ็นดิจิทัลและสัญญา สามารถปิดได้โดยการเผยแพร่หลักฐานโดย ynally ไปยัง blockchain, a กลไกได้รับความนิยมเป็นครั้งแรกโดยการแลกเปลี่ยนอะตอมแบบข้ามสายโซ่ โดย เปิดช่องทางการชำระเงินกับหลายฝ่ายผู้เข้าร่วม Lightning Network สามารถกลายเป็นจุดโฟกัสสำหรับการกำหนดเส้นทาง การชำระเงินของผู้อื่น นำไปสู่ช่องทางการชำระเงินที่เชื่อมโยงกันอย่างเต็มรูปแบบ เครือข่ายโดยต้นทุนเงินทุนเชื่อมโยงกับช่องทางการชำระเงิน ในขณะที่ Lightning Network ยังสามารถขยายข้ามได้อย่างง่ายดาย blockchains อิสระหลายรายการเพื่อให้สามารถถ่ายโอนมูลค่าได้ ผ่านตลาดแลกเปลี่ยน ไม่สามารถใช้แบบไม่สมมาตรได้ โอน tokens จาก blockchain หนึ่งไปยังอีกแห่งหนึ่ง เบเนต์หลัก ของเครือข่าย Cosmos ที่อธิบายไว้ที่นี่คือการเปิดใช้งานโดยตรงดังกล่าว token การโอน กล่าวคือเราคาดหวังช่องทางการชำระเงินและ Lightning Network ที่จะได้รับการยอมรับอย่างกว้างขวางพร้อมกับเรา token กลไกการถ่ายโอน เพื่อการประหยัดต้นทุนและความเป็นส่วนตัว Segregated Witness คือลิงก์ข้อเสนอการปรับปรุง Bitcoin ตั้งเป้าที่จะเพิ่มปริมาณธุรกรรมต่อบล็อก 2X หรือ 3X ในขณะเดียวกันก็ทำให้การซิงค์บล็อกเร็วขึ้นสำหรับโหนดใหม่ ความฉลาดของโซลูชันนี้อยู่ที่วิธีการทำงานภายใน ข้อจำกัดของโปรโตคอลปัจจุบันของ Bitcoin และอนุญาตให้ใช้ soft-fork อัปเกรด (เช่น ลูกค้าที่มีซอฟต์แวร์เวอร์ชันเก่ากว่าจะ ยังคงทำงานต่อไปหลังจากการอัปเกรด) Tendermint เป็นของใหม่ โปรโตคอลไม่มีข้อจำกัดในการออกแบบ จึงมีมาตราส่วนที่แตกต่างกัน ลำดับความสำคัญ โดยพื้นฐานแล้ว Tendermint ใช้อัลกอริธึมแบบ Round-robin 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.

ฉันทามติและรายละเอียดทางเทคนิค

ระเบียบวิธีฉันทามติที่ออกแบบมาอย่างดีควรจัดเตรียมไว้บ้าง รับประกันในกรณีที่เกินขีดความสามารถที่ยอมรับได้ และฉันทามติล้มเหลว นี่เป็นสิ่งจำเป็นอย่างยิ่งในด้านเศรษฐกิจ ระบบซึ่งพฤติกรรมไบเซนไทน์สามารถมีการเงินจำนวนมากได้ รางวัล การรับประกันที่สำคัญที่สุดคือรูปแบบของ forkaaccountability ซึ่งกระบวนการที่ทำให้เกิดฉันทามติ ล้มเหลว (เช่น ทำให้ไคลเอนต์ของโปรโตคอลยอมรับค่าที่แตกต่างกัน - ทางแยก) สามารถระบุและลงโทษได้ตามกฎของ ระเบียบการหรืออาจรวมถึงระบบกฎหมาย เมื่อระบบกฎหมายเป็น ไม่น่าเชื่อถือหรือมีราคาแพงเกินไปในการเรียกใช้ validators สามารถทำได้ ถูกบังคับให้วางเงินประกันเพื่อเข้าร่วมและอื่นๆ เงินฝากสามารถเพิกถอนหรือเฉือนได้เมื่อมีพฤติกรรมที่เป็นอันตราย ตรวจพบ [10] โปรดทราบว่าสิ่งนี้ไม่เหมือนกับ Bitcoin ซึ่งการฟอร์กเกิดขึ้นเป็นประจำ เนื่องจากเครือข่ายไม่ซิงโครไนซ์และลักษณะความน่าจะเป็นของ ynding การชนกันของ hash บางส่วน เนื่องจากในหลายกรณี การแยกที่เป็นอันตรายคือ แยกไม่ออกจากทางแยกเนื่องจากไม่ซิงโครไนซ์ Bitcoin ไม่สามารถ ใช้ fork-accountability ได้อย่างน่าเชื่อถือ นอกเหนือจากโดยนัย ค่าเสียโอกาสที่นักขุดจ่ายสำหรับการขุดบล็อกกำพร้า เราเรียกขั้นตอนการลงคะแนนเสียงว่า PreVote และ PreCommit สามารถลงคะแนนเสียงได้ บล็อกเฉพาะหรือสำหรับไม่มี เราเรียกการรวบรวม >⅔ PreVotes สำหรับบล็อกเดียวในรอบเดียวกันคือ Polka และชุดสะสม >⅔ PreCommits สำหรับบล็อกเดียวในรอบเดียวกันของ Commit ถ้า >⅔ PreCommit for Nil ในรอบเดียวกันก็เลื่อนไปรอบถัดไป รอบ โปรดทราบว่าการกำหนดระดับที่เข้มงวดในโปรโตคอลทำให้เกิดจุดอ่อน ต้องตรวจพบสมมติฐานแบบซิงโครนัสในฐานะผู้นำที่ผิดพลาดและ

ข้ามไป ดังนั้น validators รอสักระยะหนึ่ง TimeoutPropose ก่อนที่พวกเขา Prevote Nil และค่าของ การหมดเวลาเสนอเพิ่มขึ้นในแต่ละรอบ ความก้าวหน้าผ่าน ส่วนที่เหลือของรอบเป็นแบบอะซิงโครนัสอย่างสมบูรณ์ ในความคืบหน้านั้นเท่านั้น ทำเมื่อ validator ได้ยินจาก >⅔ ของเครือข่าย ในทางปฏิบัติ ต้องใช้ศัตรูที่แข็งแกร่งอย่างยิ่งในการขัดขวางอย่างไม่มีกำหนด สมมติฐานซิงโครไนซ์ที่อ่อนแอ (ทำให้ฉันทามติล้มเหลว เคยกระทำการบล็อก) และการทำเช่นนี้จะยิ่งเพิ่มมากขึ้นไปอีก ยุ่งยากโดยใช้ค่าสุ่มของ TimeoutPropose ในแต่ละค่า validator. ชุดข้อจำกัดเพิ่มเติมหรือกฎการล็อคทำให้แน่ใจได้ว่า ในที่สุดเครือข่ายก็จะส่งเพียงหนึ่งบล็อกที่แต่ละความสูง อะไรก็ได้ ความพยายามที่เป็นอันตรายที่จะทำให้เกิดการคอมมิตมากกว่าหนึ่งบล็อก ที่ความสูงที่กำหนดสามารถระบุได้ ขั้นแรก ให้กระทำการล่วงหน้าสำหรับบล็อก จะต้องมาพร้อมกับ justiycation ในรูปแบบของลายสำหรับบล็อกนั้น หาก validator ได้มอบหมายบล็อกล่วงหน้าที่รอบ R_1 แล้ว เราก็ บอกว่าพวกเขาถูกล็อคอยู่บนบล็อกนั้น และลายก็เคยแก้ตัว PreCommit ใหม่ในรอบ R_2 จะต้องมาในรอบ R_polka โดยที่ R_1 < R_polka <= R_2 ประการที่สอง validators ต้องเสนอ และ/หรือโหวตล่วงหน้าบล็อกที่พวกเขาล็อคอยู่ กันเหล่านี้ เงื่อนไขทำให้มั่นใจได้ว่า validator จะไม่กระทำการล่วงหน้าหากไม่มี หลักฐานเพียงพอเป็นข้ออ้าง และ validators ซึ่งมี PreCommit ไม่สามารถสนับสนุนหลักฐานให้กับ PreCommit ได้ อย่างอื่น ทำให้มั่นใจทั้งความปลอดภัยและความมีชีวิตชีวาของ อัลกอริธึมฉันทามติ รายละเอียดทั้งหมดของโปรโตคอลมีอธิบายไว้ที่นี่ ความจำเป็นในการซิงค์ส่วนหัวของบล็อกทั้งหมดจะถูกกำจัดใน TendermintPoS เนื่องจากการมีอยู่ของห่วงโซ่ทางเลือก (ทางแยก) หมายถึง ≥⅓ของ สามารถเฉือนหุ้นที่ถูกผูกมัดได้ แน่นอน เนื่องจากต้องใช้การเฉือน ว่ามีคนแบ่งปันหลักฐานของทางแยก ลูกค้ารายย่อยควรเก็บไว้ block-hash ใด ๆ กระทำการที่เห็น นอกจากนี้ลูกค้าตัวเบาสามารถซิงค์เป็นระยะกับการเปลี่ยนแปลงของชุด validator ใน เพื่อหลีกเลี่ยงการโจมตีระยะไกล (แต่วิธีแก้ไขอื่นคือ เป็นไปได้) ด้วยจิตวิญญาณที่คล้ายคลึงกับ Ethereum Tendermint ช่วยให้แอปพลิเคชันสามารถ ฝัง Merkle root ทั่วโลก hash ในแต่ละบล็อก ได้อย่างง่ายดาย การสอบถามสถานะที่ตรวจสอบได้สำหรับสิ่งต่างๆ เช่น ยอดคงเหลือในบัญชี มูลค่า เก็บไว้ในสัญญาหรือการมีอยู่ของธุรกรรมที่ยังไม่ได้ใช้ เอาท์พุตขึ้นอยู่กับลักษณะของแอปพลิเคชัน สมมติว่ามีการรวบรวมเครือข่ายการออกอากาศที่มีความยืดหยุ่นเพียงพอ และชุด validator แบบคงที่ ทางแยกใด ๆ ใน blockchain สามารถเป็นได้ ตรวจพบและเงินฝากของ validators ที่กระทำผิดถูกตัดออก นี้ นวัตกรรมที่แนะนำครั้งแรกโดย Vitalik Buterin เมื่อต้นปี 2014 ได้รับการแก้ไขแล้ว ปัญหาที่ไม่มีความเสี่ยงของ proof-of-stake อื่นๆ cryptocurrencies (ดูงานที่เกี่ยวข้อง) อย่างไรก็ตาม เนื่องจาก validator ตั้งค่า จะต้องสามารถเปลี่ยนแปลงได้ในระยะยาวตามเดิม validators ทั้งหมดอาจไม่ถูกผูกมัด และด้วยเหตุนี้จึงมีอิสระที่จะ สร้าง chain ใหม่จาก genesis block โดยไม่มีค่าใช้จ่ายใดๆ ทั้งสิ้น พวกเขาไม่มีการล็อคเงินฝากอีกต่อไป การโจมตีครั้งนี้เกิดขึ้น รู้จักกันในชื่อการโจมตีระยะไกล (LRA) ซึ่งตรงกันข้ามกับการโจมตีระยะสั้น การโจมตีระยะไกล โดยที่ validators ที่ถูกผูกมัดอยู่ในขณะนี้ทำให้เกิด ทางแยกและด้วยเหตุนี้จึงมีโทษ (สมมติว่าผู้รับผิดชอบทางแยก BFT อัลกอริทึมเช่นฉันทามติ Tendermint) การโจมตีระยะไกลนั้น มักคิดว่าเป็นการโจมตีที่สำคัญต่อ proof-of-stake โชคดีที่ LRA สามารถบรรเทาได้ดังนี้ ประการแรก สำหรับก validator ยกเลิกการผูกมัด (จึงกู้คืนเงินฝากหลักประกันได้ และไม่ได้รับค่าธรรมเนียมในการเข้าร่วมฉันทามติอีกต่อไป) การฝากเงินจะต้องทำให้ไม่สามารถโอนได้เป็นระยะเวลาหนึ่ง เรียกว่า “ช่วงปลดหนี้” ซึ่งอาจเป็นไปตามคำสั่งของ สัปดาห์หรือเดือน ประการที่สอง เพื่อให้ลูกค้ารายย่อยมีความปลอดภัย สิ่งแรก เวลาที่เชื่อมต่อกับเครือข่ายจะต้องตรวจสอบบล็อกล่าสุด-hash กับแหล่งที่เชื่อถือได้หรือหลายแหล่งโดยเฉพาะอย่างยิ่ง นี้

สภาวะบางครั้งเรียกว่า “อัตวิสัยที่อ่อนแอ” สุดท้ายนี้ เพื่อความปลอดภัย จะต้องซิงค์กับชุด validator ล่าสุดที่ น้อยที่สุดเท่าระยะเวลาที่ไม่มีการผูกมัด นี้ ตรวจสอบให้แน่ใจว่าไคลเอ็นต์แบบ light รู้เกี่ยวกับการเปลี่ยนแปลงใน validator กำหนดไว้ก่อนที่ validator จะไม่มีทุนที่ผูกมัด และไม่มีอีกต่อไป ที่เป็นเดิมพันซึ่งจะทำให้สามารถหลอกลวงลูกค้าได้โดยการดำเนินการ การโจมตีระยะไกลโดยการสร้างบล็อกใหม่โดยเริ่มกลับมาที่ ความสูงที่ติดกัน (สมมติว่าสามารถควบคุมได้เพียงพอ กุญแจส่วนตัวในยุคแรก ๆ จำนวนมาก) โปรดทราบว่าการเอาชนะ LRA ในลักษณะนี้จำเป็นต้องมีการยกเครื่องใหม่ รูปแบบการรักษาความปลอดภัยดั้งเดิมของ proof-of-work ใน PoW มันคือ สันนิษฐานว่าไคลเอนต์แบบเบาสามารถซิงค์กับความสูงปัจจุบันได้จาก บล็อกกำเนิดที่เชื่อถือได้ตลอดเวลาโดยการประมวลผลการพิสูจน์การทำงานในทุกส่วนหัวของบล็อก อย่างไรก็ตาม เพื่อเอาชนะ LRA เรา ต้องการให้ไคลเอ็นต์ขนาดเล็กออนไลน์อย่างสม่ำเสมอ ติดตามการเปลี่ยนแปลงในชุด validator และในครั้งแรกที่เกิดขึ้น เมื่อออนไลน์ พวกเขาจะต้องระมัดระวังเป็นพิเศษในการตรวจสอบสิทธิ์ สิ่งที่พวกเขาได้ยินจากเครือข่ายกับแหล่งที่เชื่อถือได้ ของ แน่นอนว่าข้อกำหนดหลังนี้คล้ายกับของ Bitcoin โดยที่ โปรโตคอลและซอฟต์แวร์จะต้องได้รับจากที่เชื่อถือได้ด้วย แหล่งที่มา วิธีการป้องกัน LRA ข้างต้นเหมาะสำหรับ validators และโหนดเต็มของ blockchain ที่ขับเคลื่อนด้วย Tendermint เพราะสิ่งเหล่านี้ โหนดมีไว้เพื่อให้เชื่อมต่อกับเครือข่ายต่อไป ที่ วิธีการนี้ยังเหมาะสำหรับลูกค้ารายย่อยที่สามารถคาดหวังได้ ซิงค์กับเครือข่ายบ่อยๆ อย่างไรก็ตามสำหรับลูกค้ารายย่อยนั้น ไม่คาดว่าจะมีการเข้าถึงอินเทอร์เน็ตหรืออินเทอร์เน็ตบ่อยครั้ง blockchain เครือข่าย แต่ยังสามารถใช้โซลูชันอื่นเพื่อเอาชนะได้ แอลอาร์เอ ผู้ที่ไม่ใช่ validator token ผู้ถือสามารถโพสต์ tokens ของตนเป็น หลักประกันที่มีระยะเวลาปลดหนี้ยาวนานมาก (เช่น นานกว่ามาก กว่าระยะเวลาที่ไม่มีการผูกมัดสำหรับ validators) และให้บริการลูกค้ารายย่อย ด้วยวิธีรองในการรับรองความถูกต้องของกระแสและ บล็อกที่ผ่านมา-hashes แม้ว่า tokens เหล่านี้จะไม่นับรวมใน ความปลอดภัยของความเห็นพ้องต้องกันของ blockchain พวกเขาก็สามารถทำได้ให้การรับประกันที่แข็งแกร่งสำหรับลูกค้าที่มีน้ำหนักเบา หากบล็อกประวัติศาสตร์-hash การสืบค้นได้รับการสนับสนุนใน Ethereum ทุกคนสามารถเชื่อมโยงกันได้ tokens ในการออกแบบพิเศษ smart contract และจัดให้มี บริการรับรองการจ่ายเงิน สร้างตลาดสำหรับการรักษาความปลอดภัย LRA ของ lightclient อย่างมีประสิทธิภาพ เนื่องจากการละทิ้งการคอมมิตแบบบล็อก การรวมกลุ่ม ≥⅓ ใดๆ ของ อำนาจการลงคะแนนสามารถหยุด blockchain ได้โดยไปที่ ofzine หรือไม่ ออกอากาศการลงคะแนนเสียงของพวกเขา แนวร่วมดังกล่าวสามารถเซ็นเซอร์ได้เช่นกัน ธุรกรรมเฉพาะโดยการปฏิเสธบล็อกที่มีสิ่งเหล่านี้ ธุรกรรมแม้ว่าจะส่งผลให้มีสัดส่วนที่มีนัยสำคัญก็ตาม ของข้อเสนอบล็อกที่จะปฏิเสธซึ่งจะทำให้อัตราช้าลง ของการคอมมิตบล็อกของ blockchain ซึ่งลดอรรถประโยชน์และความคุ้มค่าลง แนวร่วมที่เป็นอันตรายอาจออกอากาศการลงคะแนนเสียงแบบหยดเช่นกัน ในการบดบล็อก blockchain กระทำการใกล้หยุดหรือมีส่วนร่วม การโจมตีเหล่านี้รวมกัน สุดท้ายก็อาจทำให้เกิดการ blockchain แยก โดยการลงนามสองครั้งหรือละเมิดการล็อค กฎ หากมีศัตรูที่มีบทบาทอยู่ทั่วโลกเข้ามาเกี่ยวข้องด้วย ก็สามารถแบ่งพาร์ติชันได้ เครือข่ายในลักษณะที่อาจปรากฏว่าผิด ชุดย่อยของ validators มีส่วนรับผิดชอบต่อการชะลอตัว นี่ไม่ใช่ เป็นเพียงข้อจำกัดของ Tendermint แต่เป็นข้อจำกัดของทั้งหมด โปรโตคอลที่เป็นเอกฉันท์ซึ่งเครือข่ายอาจถูกควบคุมโดย ศัตรูที่แข็งขัน สำหรับการโจมตีประเภทนี้ ควรมีชุดย่อยของ validators ประสานงานผ่านช่องทางภายนอกเพื่อลงนามในข้อเสนอการปรับโครงสร้างองค์กรใหม่ว่า เลือกทางแยก (และหลักฐานใดๆ ในนั้น) และเซตย่อยเริ่มต้นของ validators พร้อมลายเซ็นของพวกเขา ผู้ตรวจสอบที่ลงนามในข้อเสนอการปรับโครงสร้างองค์กรดังกล่าวจะละทิ้งหลักประกันใน Fork อื่นๆ ทั้งหมด ลูกค้าควร ตรวจสอบลายเซ็นในข้อเสนอการจัดองค์กรใหม่ ตรวจสอบหลักฐานใด ๆ และตัดสินหรือแจ้งให้ผู้ใช้ปลายทางตัดสินใจ สำหรับ ตัวอย่างเช่น แอพกระเป๋าเงินโทรศัพท์อาจแจ้งให้ผู้ใช้ทราบถึงระบบรักษาความปลอดภัย

คำเตือน ในขณะที่ตู้เย็นอาจยอมรับข้อเสนอการจัดองค์กรใหม่ ลงนามโดย +½ ของต้นฉบับ validators ตามอำนาจการลงคะแนน ไม่มีอัลกอริธึมที่ทนต่อข้อผิดพลาดของ Byzantine ที่ไม่ซิงโครนัสเกิดขึ้นได้ ฉันทามติเมื่ออำนาจการลงคะแนนเสียง≥⅓ไม่ซื่อสัตย์ แต่ก็ถือเป็นทางแยก ถือว่าอำนาจการลงคะแนนเสียง≥⅓นั้นไม่ซื่อสัตย์อยู่แล้ว การลงนามสองครั้งหรือการเปลี่ยนล็อคโดยไม่มีเหตุผล ดังนั้นการลงนาม ข้อเสนอการจัดองค์กรใหม่เป็นปัญหาการประสานงานที่ไม่สามารถทำได้ แก้ไขได้โดยโปรโตคอลที่ไม่ซิงโครนัส (เช่น อัตโนมัติ และ โดยไม่ตั้งสมมติฐานเกี่ยวกับความน่าเชื่อถือของ เครือข่ายพื้นฐาน) สำหรับตอนนี้ เราทิ้งปัญหาของการประสานงานข้อเสนอองค์กรใหม่ไว้กับการประสานงานของมนุษย์ผ่านฉันทามติทางสังคม บนสื่ออินเทอร์เน็ต ผู้ตรวจสอบจะต้องดูแลให้มั่นใจว่ามี ไม่มีพาร์ติชันเครือข่ายที่เหลืออยู่ก่อนที่จะลงนามข้อเสนอองค์กรใหม่ เพื่อหลีกเลี่ยงสถานการณ์ที่มีการลงนามข้อเสนอองค์กรใหม่สองครั้งที่ขัดแย้งกัน สมมติว่ามีสื่อและโปรโตคอลการประสานงานภายนอกอยู่ แข็งแกร่ง ตามมาด้วยว่า forks มีข้อกังวลน้อยกว่าการเซ็นเซอร์ การโจมตี นอกเหนือจากส้อมและการเซ็นเซอร์ซึ่งต้องใช้ ≥⅓ Byzantine อำนาจในการลงคะแนนเสียง รัฐบาลผสมที่มีอำนาจลงคะแนนเสียง >⅔ อาจกระทำได้ โดยพลการรัฐที่ไม่ถูกต้อง นี่คือลักษณะของ (BFT) ใด ๆ ระบบฉันทามติ ต่างจากการลงนามสองครั้งซึ่งจะสร้างทางแยก มีหลักฐานที่ตรวจสอบได้ง่าย ตรวจพบการกระทำของ สถานะที่ไม่ถูกต้องต้องมีเพียร์ที่ไม่ตรวจสอบเพื่อตรวจสอบบล็อกทั้งหมด ซึ่งหมายความว่าพวกเขาเก็บสำเนาของรัฐในเครื่องและดำเนินการ แต่ละธุรกรรม โดยคำนวณสถานะรูทอย่างอิสระ ตัวเอง เมื่อตรวจพบแล้ว วิธีเดียวที่จะจัดการกับความล้มเหลวดังกล่าวได้ ผ่านทางฉันทามติทางสังคม ตัวอย่างเช่น ในสถานการณ์ที่ Bitcoin ล้มเหลว ไม่ว่าจะฟอร์กเนื่องจากข้อบกพร่องของซอฟต์แวร์ (เช่นในเดือนมีนาคม 2013) หรือกระทำการสถานะที่ไม่ถูกต้องเนื่องจากพฤติกรรมไบแซนไทน์ของ นักขุด (ณ เดือนกรกฎาคม 2558) ซึ่งเป็นชุมชนที่เชื่อมต่อกันอย่างดีของ ธุรกิจ นักพัฒนา นักขุด และองค์กรอื่นๆ สร้างฉันทามติทางสังคมว่าการดำเนินการโดยเจ้าหน้าที่คืออะไรผู้เข้าร่วมต้องการเพื่อรักษาเครือข่าย นอกจากนี้ เนื่องจาก validators ของ Tendermint blockchain อาจถูกคาดหวังให้เป็น ระบุตัวตนได้ ความมุ่งมั่นของรัฐที่ไม่ถูกต้องอาจเป็นได้ มีโทษตามกฎหมายหรือนิติศาสตร์ภายนอกหากต้องการ ABCI ประกอบด้วยข้อความหลัก 3 ประเภทที่ส่งมาจาก แกนหลักของแอปพลิเคชัน แอปพลิเคชันตอบกลับด้วย ข้อความตอบกลับที่สอดคล้องกัน ข้อความ  AppendTx  เป็นส่วนสำคัญของแอปพลิเคชัน แต่ละ ธุรกรรมใน blockchain ถูกส่งมาพร้อมกับข้อความนี้ ที่ แอปพลิเคชันจำเป็นต้องตรวจสอบแต่ละธุรกรรมที่ได้รับด้วย ข้อความ AppendTx กับสถานะปัจจุบัน โปรโตคอลแอปพลิเคชัน และข้อมูลรับรองการเข้ารหัสของธุรกรรม มีการตรวจสอบแล้ว ธุรกรรมจำเป็นต้องอัปเดตสถานะแอปพลิเคชัน — โดย การเชื่อมโยงค่าเข้ากับที่เก็บค่าคีย์หรือโดยการอัพเดต UTXO ฐานข้อมูล ข้อความ  CheckTx  คล้ายกับ AppendTx แต่มีไว้สำหรับเท่านั้น ตรวจสอบธุรกรรม การตรวจสอบ mempool ครั้งแรกของ Tendermint Core ความถูกต้องของธุรกรรมกับ CheckTx และรีเลย์ที่ถูกต้องเท่านั้น การทำธุรกรรมกับคู่แข่ง แอปพลิเคชันอาจตรวจสอบการเพิ่มขึ้น nonce ในการทำธุรกรรมและส่งกลับข้อผิดพลาดเมื่อ CheckTx หาก nonce เก่าแล้ว ข้อความ  Commit  ใช้เพื่อคำนวณการเข้ารหัส ความมุ่งมั่นต่อสถานะแอปพลิเคชันปัจจุบันที่จะวางไว้ใน ส่วนหัวของบล็อกถัดไป นี่มีคุณสมบัติที่มีประโยชน์บางอย่าง ความไม่สอดคล้องกันในการอัปเดตสถานะนั้นจะปรากฏเป็น blockchain forks ที่รองรับการเขียนโปรแกรมทั้งคลาส ข้อผิดพลาด นอกจากนี้ยังช่วยลดความยุ่งยากในการพัฒนาผลิตภัณฑ์น้ำหนักเบาที่ปลอดภัยอีกด้วย ลูกค้า เนื่องจาก Merkle-hash สามารถตรวจสอบได้โดยการตรวจสอบเทียบกับ block-hash และ block-hash ได้รับการลงนามโดยองค์ประชุมของ validators (ตามอำนาจการลงคะแนน)

ข้อความ ABCI เพิ่มเติมทำให้แอปพลิเคชันสามารถติดตามได้ และเปลี่ยนชุด validator และเพื่อให้แอปพลิเคชันได้รับ บล็อกข้อมูล เช่น ความสูงและการลงคะแนนเสียง ABCI คำขอ/การตอบกลับเป็นข้อความง่ายๆ ของ Protobuf ตรวจสอบ ออกจากสคีมา yle ข้อโต้แย้ง: ข้อมูล ([] ไบต์) : ไบต์ของธุรกรรมคำขอ ผลตอบแทน: รหัส (uint32) : รหัสตอบกลับ ข้อมูล ([]ไบต์) : ไบต์ผลลัพธ์ ถ้ามี บันทึก (สตริง) : แก้ไขข้อบกพร่องหรือข้อความแสดงข้อผิดพลาด การใช้งาน:

ผนวกและรันธุรกรรม หากการทำธุรกรรมถูกต้อง ส่งคืน CodeType.OK ข้อโต้แย้ง: ข้อมูล ([] ไบต์) : ไบต์ของธุรกรรมคำขอ ผลตอบแทน: รหัส (uint32) : รหัสตอบกลับ ข้อมูล ([]ไบต์) : ไบต์ผลลัพธ์ ถ้ามี บันทึก (สตริง) : แก้ไขข้อบกพร่องหรือข้อความแสดงข้อผิดพลาด การใช้งาน:

ตรวจสอบธุรกรรม ข้อความนี้ไม่ควรเปลี่ยนรูปแบบ รัฐ การทำธุรกรรมจะดำเนินการผ่าน CheckTx มาก่อน ออกอากาศไปยังเพื่อนในเลเยอร์ mempool คุณก็ทำได้ CheckTx กึ่งเก็บสถานะและล้างสถานะเมื่อคอมมิตหรือ BeginBlock เพื่ออนุญาตลำดับการทำธุรกรรมที่ขึ้นต่อกัน ในบล็อกเดียวกัน

ผลตอบแทน: ข้อมูล ([] ไบต์) : ราก Merkle hash บันทึก (สตริง) : แก้ไขข้อบกพร่องหรือข้อความแสดงข้อผิดพลาด การใช้งาน:

ส่งคืน Merkle root hash ของสถานะแอปพลิเคชัน ข้อโต้แย้ง: ข้อมูล ([] ไบต์) : ไบต์คำขอค้นหา ผลตอบแทน: รหัส (uint32) : รหัสตอบกลับ Data ([]byte) : ไบต์การตอบกลับคำค้นหา บันทึก (สตริง) : แก้ไขข้อบกพร่องหรือข้อความแสดงข้อผิดพลาด การใช้งาน:

ล้างคิวการตอบกลับ แอพพลิเคชั่นที่นำไปใช้งาน types.Application ไม่จำเป็นต้องใช้ข้อความนี้ – มันคือ จัดการโดยโครงการ ผลตอบแทน: ข้อมูล ([]ไบต์) : ไบต์ข้อมูล การใช้งาน:

ส่งกลับข้อมูลเกี่ยวกับสถานะแอปพลิเคชัน ใบสมัคร เฉพาะเจาะจง ข้อโต้แย้ง: คีย์ (สตริง) : คีย์เพื่อตั้งค่า

ค่า (สตริง) : ค่าที่จะตั้งค่าสำหรับคีย์ ผลตอบแทน: บันทึก (สตริง) : แก้ไขข้อบกพร่องหรือข้อความแสดงข้อผิดพลาด การใช้งาน:

ตั้งค่าตัวเลือกแอปพลิเคชัน เช่น คีย์ = “โหมด”, ค่า = “mempool” สำหรับ การเชื่อมต่อ mempool หรือ Key = “mode”, Value = “consensus” สำหรับ การเชื่อมต่อฉันทามติ ตัวเลือกอื่นๆ คือข้อกำหนดเฉพาะของแอปพลิเคชัน ข้อโต้แย้ง: เครื่องมือตรวจสอบ ([]เครื่องมือตรวจสอบ) : กำเนิดเริ่มต้น-validators การใช้งาน:

เรียกว่ากาลครั้งหนึ่ง ข้อโต้แย้ง: Height (uint64) : ความสูงของบล็อกที่กำลังเริ่มต้น การใช้งาน:

ส่งสัญญาณการเริ่มต้นบล็อกใหม่ เรียกว่ามาก่อนแต่อย่างใด ผนวกTxs ข้อโต้แย้ง: ความสูง (uint64) : ความสูงของบล็อกที่สิ้นสุด ผลตอบแทน: เครื่องมือตรวจสอบ ([]เครื่องมือตรวจสอบ) : เปลี่ยน validators ด้วยเครื่องมือใหม่ อำนาจการลงคะแนน (0 เพื่อลบ) การใช้งาน:

ส่งสัญญาณการสิ้นสุดของบล็อก เรียกว่าก่อนการคอมมิตแต่ละครั้ง การทำธุรกรรม ดูที่เก็บ ABCI สำหรับรายละเอียดเพิ่มเติมมีสาเหตุหลายประการที่ผู้ส่งอาจต้องการ รับทราบการส่งมอบแพ็กเก็ตโดยห่วงโซ่การรับ เช่น ผู้ส่งอาจไม่ทราบสถานะของการ ห่วงโซ่ปลายทาง หากคาดว่าจะเกิดข้อผิดพลาด หรือผู้ส่งก็ได้ ต้องการกำหนดการหมดเวลาบนแพ็กเก็ต (ด้วย  MaxHeight  แพ็คเก็ต yeld) ในขณะที่เครือข่ายปลายทางใดๆ อาจประสบปัญหาจากการโจมตีแบบปฏิเสธการให้บริการ โดยมีจำนวนขาเข้าที่เพิ่มขึ้นอย่างกะทันหัน แพ็กเก็ต ในกรณีเหล่านี้ ผู้ส่งสามารถขอการตอบรับการจัดส่งได้ โดยการตั้งค่าสถานะแพ็กเก็ตเริ่มต้นเป็น  AckPending แล้วมันคือ การรับความรับผิดชอบของห่วงโซ่ในการยืนยันการจัดส่งโดยรวม ย่อ IBCPacket  ในแอป Merkle hash ขั้นแรก  IBCBlockCommit  และ  IBCPacketTx  จะถูกโพสต์บน “Hub” ที่พิสูจน์การมีอยู่ของ IBCPacket  บน “Zone1” พูดอย่างนั้น  IBCPacketTx  มีค่าต่อไปนี้: FromChainID : “Zone1” FromBlockHeight : 100 (พูด) แพ็คเก็ต : IBCแพ็คเก็ต :

ส่วนหัว : IBCPacketHeader : SrcChainID : “Zone1” DstChainID : “Zone2” หมายเลข : 200 (พูด) สถานะ : อยู่ระหว่างดำเนินการ ประเภท : “เหรียญ” MaxHeight : 350 (พูดว่า “Hub” ปัจจุบันอยู่ที่ความสูง 300) เพย์โหลด : <ไบต์ของเพย์โหลด “เหรียญ”> ถัดไป  IBCBlockCommit  และ  IBCPacketTx  จะถูกโพสต์บน “Zone2” ที่พิสูจน์การมีอยู่ของ IBCPacket  บน “Hub” พูดอย่างนั้น  IBCPacketTx  มีค่าต่อไปนี้: FromChainID : “ฮับ” จากความสูงบล็อก : 300 แพ็คเก็ต : IBCแพ็คเก็ต : ส่วนหัว : IBCPacketHeader : SrcChainID : “Zone1” DstChainID : “Zone2” จำนวน : 200 สถานะ : อยู่ระหว่างดำเนินการ ประเภท : “เหรียญ” ความสูงสูงสุด : 350 เพย์โหลด : <ไบต์เดียวกันของเพย์โหลด “เหรียญ”> ถัดไป “Zone2” จะต้องรวมแพ็กเก็ตตัวย่อไว้ในแอป-hash ที่แสดงสถานะใหม่ของ  AckSent IBCBlockCommit และ  IBCPacketTx  ถูกโพสต์กลับไปที่ “Hub” เพื่อพิสูจน์การมีอยู่จริง ของตัวย่อ IBCPacket  บน "Zone2" พูดว่า IBCPacketTx  มีค่าดังต่อไปนี้: FromChainID : “Zone2”

FromBlockHeight : 400 (พูด) แพ็คเก็ต : IBCแพ็คเก็ต : ส่วนหัว : IBCPacketHeader : SrcChainID : “Zone1” DstChainID : “Zone2” จำนวน : 200 สถานะ : AckSent ประเภท : “เหรียญ” ความสูงสูงสุด : 350 PayloadHash : <ไบต์ hash ของเพย์โหลด “เหรียญ” เดียวกัน> สุดท้าย “ฮับ” จะต้องอัปเดตสถานะของแพ็กเก็ตจาก  อยู่ระหว่างดำเนินการ  ถึง  ได้รับแล้ว หลักฐานของสถานะ ynalized ใหม่นี้ ควรกลับไปที่ "Zone2" สมมติว่า IBCPacketTx  มีดังต่อไปนี้ ค่า: FromChainID : “ฮับ” จาก BlockHeight : 301 แพ็คเก็ต : IBCแพ็คเก็ต : ส่วนหัว : IBCPacketHeader : SrcChainID : “Zone1” DstChainID : “Zone2” จำนวน : 200 สถานะ : รับทราบแล้ว ประเภท : “เหรียญ” ความสูงสูงสุด : 350 PayloadHash : <ไบต์ hash ของเพย์โหลด “เหรียญ” เดียวกัน> ในขณะเดียวกัน “Zone1” อาจถือว่าส่งมอบได้สำเร็จในแง่ดี ของซอง "เหรียญ" เว้นแต่จะมีการพิสูจน์หลักฐานที่ขัดแย้งกัน “ฮับ”. ในตัวอย่างข้างต้น หาก “Hub” ไม่ได้รับ  AckSent

สถานะจาก “Zone2” โดยบล็อก 350 ก็จะมีการกำหนดสถานะ โดยอัตโนมัติเป็น  หมดเวลา สามารถรับหลักฐานการหมดเวลานี้ได้ โพสต์กลับไปที่ “Zone1” และสามารถส่งคืน tokens ใดๆ ได้ Merkle trees ที่ได้รับการสนับสนุนมีสองประเภทใน Tendermint/Cosmos ระบบนิเวศ: The Simple Tree และ IAVL+ ต้นไม้. Simple Tree คือ Merkle tree สำหรับรายการองค์ประกอบแบบคงที่ ถ้า จำนวนรายการไม่ยกกำลังสอง บางใบก็จะอยู่ที่ ระดับที่แตกต่างกัน Simple Tree พยายามรักษาต้นไม้ทั้งสองด้านไว้ สูงเท่ากันแต่ข้างซ้ายอาจจะใหญ่กว่าหนึ่งอัน Merkle tree นี่คือ ใช้ในการ Merkle-ize ธุรกรรมของบล็อกและระดับบนสุด องค์ประกอบของรูทสถานะแอปพลิเคชันวัตถุประสงค์ของโครงสร้างข้อมูล IAVL+ คือเพื่อให้มีความคงอยู่ ที่เก็บข้อมูลสำหรับคู่คีย์-ค่าในสถานะแอปพลิเคชันดังกล่าว Merkle root ที่กำหนดขึ้นเอง hash สามารถคำนวณได้อย่างมีประสิทธิภาพ ที่ tree มีความสมดุลโดยใช้อัลกอริธึม AVL และทั้งหมด การดำเนินการคือ O(log(n)) ในแผนผัง AVL หมายถึงความสูงของแผนผังย่อยทั้งสองของโหนดใดๆ แตกต่างกันอย่างมากที่สุดอย่างหนึ่ง เมื่อใดก็ตามที่เงื่อนไขนี้ถูกละเมิดเมื่อ อัปเดตทรีจะถูกปรับสมดุลโดยการสร้างโหนดใหม่ O(log(n)) ชี้ไปที่โหนดของต้นไม้เก่าที่ยังไม่ปรับแต่ง ใน AVL ดั้งเดิม อัลกอริธึมโหนดภายในสามารถเก็บคู่คีย์-ค่าได้ เอวีแอล+ อัลกอริธึม (หมายเหตุเครื่องหมายบวก) แก้ไขอัลกอริธึม AVL เพื่อเก็บทั้งหมด ค่าบนโหนดปลายสุด ในขณะที่ใช้เฉพาะโหนดสาขาเพื่อจัดเก็บคีย์ สิ่งนี้ทำให้อัลกอริทึมง่ายขึ้นในขณะที่ยังคงรักษาเส้นทาง merkle hash ไว้ สั้น AVL+ Tree คล้ายคลึงกับความพยายามของ Patricia ของ Ethereum มี การแลกเปลี่ยน คีย์ไม่จำเป็นต้อง hashed ก่อนที่จะแทรก แผนผัง IAVL+ ดังนั้นจึงให้การวนซ้ำตามลำดับที่เร็วขึ้นในคีย์ พื้นที่ซึ่งอาจเป็นประโยชน์ต่อบางแอปพลิเคชัน ตรรกะนั้นง่ายกว่า นำไปใช้โดยต้องใช้โหนดเพียงสองประเภทเท่านั้น – โหนดภายในและ โหนดใบ โดยเฉลี่ยแล้วการพิสูจน์ของ Merkle จะสั้นกว่า โดยเป็น a                 *                 / \               /     \             /         \           /             \          *               *         / \             / \        /   \           /   \       /     \         /     \      *       *       *       *       *       h6     / \     / \     / \    h0  h1  h2  h3  h4  h5    SimpleTree ที่มี 7 องค์ประกอบ

ต้นไม้ไบนารีที่สมดุล ในทางกลับกัน ราก Merkle ของ an แผนผัง IAVL+ ขึ้นอยู่กับลำดับของการอัพเดต เราจะสนับสนุน Merkle trees ที่มีประสิทธิภาพเพิ่มเติม เช่น Patricia Trie ของ Ethereum เมื่อตัวแปรไบนารี่กลายเป็น ใช้ได้ ในการดำเนินการตามรูปแบบบัญญัติ ธุรกรรมจะถูกสตรีมไปที่ แอปพลิเคชันฮับ Cosmos ผ่านอินเทอร์เฟซ ABCI Cosmos Hub จะยอมรับธุรกรรมหลักจำนวนหนึ่ง ประเภท รวมถึง  SendTx ,  BondTx ,  UnbondTx ,  ReportHackTx ,  SlashTx ,  BurnAtomTx ,  ProposalCreateTx  และ  ProposalVoteTx  ซึ่งอธิบายได้ค่อนข้างชัดเจนและจะบันทึกไว้ในก การแก้ไขบทความนี้ในอนาคต ที่นี่เราจัดทำเอกสารสองรายการหลัก ประเภทธุรกรรมสำหรับ IBC:  IBCBlockCommitTx  และ IBCPacketTx  ธุรกรรม IBCBlockCommitTx  ประกอบด้วย: ChainID (สตริง) : ID ของ blockchain BlockHash ([]byte) : block-hash bytes, ราก Merkle ซึ่งรวมถึงแอป-hash BlockPartsHeader (PartSetHeader) : ส่วนหัวของชุดส่วนของบล็อก ไบต์ จำเป็นเท่านั้นในการตรวจสอบลายเซ็นการลงคะแนนเสียง BlockHeight (int) : ความสูงของการคอมมิต BlockRound (int) : รอบของการคอมมิต Commit ([]Vote) : การโหวต >⅔ Tendermint Precommit นั้น ประกอบด้วยบล็อกคอมมิต ValidatorsHash ([]byte) : ราก Merkle-tree hash ของ new validator ชุด

ValidatorsHashProof (SimpleProof) : SimpleTree Merkleproof สำหรับการพิสูจน์ ValidatorsHash กับ BlockHash AppHash ([]byte) : ราก IAVLTree Merkle-tree hash ของ สถานะการสมัคร AppHashProof (SimpleProof) : SimpleTree Merkle ที่พิสูจน์ได้สำหรับ พิสูจน์ AppHash กับ BlockHash IBCแพ็คเก็ต  ประกอบด้วย: Header (IBCPacketHeader) : ส่วนหัวของแพ็กเก็ต เพย์โหลด ([] ไบต์) : ไบต์ของเพย์โหลดแพ็กเก็ต ไม่จำเป็น PayloadHash ([]byte) : hash สำหรับไบต์ของแพ็กเก็ต ไม่จำเป็น ต้องมี  Payload  หรือ  PayloadHash  อย่างใดอย่างหนึ่ง hash ของ IBCPacket  เป็น Merkle root แบบง่ายของทั้งสองรายการ  Header  และ  เพย์โหลด  IBCPacket  ที่ไม่มีเพย์โหลดเต็มเรียกว่า an แพ็คเก็ตแบบย่อ IBCPacketHeader  ประกอบด้วย: SrcChainID (สตริง) : รหัสต้นทาง blockchain DstChainID (สตริง) : ปลายทาง blockchain ID Number (int) : หมายเลขเฉพาะสำหรับแพ็กเก็ตทั้งหมด สถานะ (enum) : สามารถเป็นหนึ่งใน AckPending , AckSent , AckReceived , NoAck หรือการหมดเวลา Type (string) : ประเภทต่างๆ ขึ้นอยู่กับแอปพลิเคชัน Cosmos ขอสงวนสิทธิ์ประเภทแพ็คเก็ต "เหรียญ" MaxHeight (int) : หากสถานะไม่ใช่ NoAckWanted หรือ AckReceived ด้วยความสูงนี้ สถานะจะกลายเป็น Timeout ไม่จำเป็น ธุรกรรม IBCPacketTx  ประกอบด้วย:FromChainID (string) : ID ของ blockchain ซึ่งก็คือ มอบแพ็กเก็ตนี้ ไม่จำเป็นต้องเป็นแหล่งที่มา FromBlockHeight (int) : ความสูง blockchain ที่ แพ็กเก็ตต่อไปนี้ถูกรวมไว้ (Merkle-ized) ในบล็อก-hash of ห่วงโซ่แหล่งที่มา แพ็คเก็ต (IBCPacket) : แพ็คเก็ตข้อมูลที่มีสถานะอาจเป็นหนึ่ง ของ AckPending , AckSent , AckReceived , NoAck หรือการหมดเวลา PacketProof (IAVLProof) : IAVLTree Merkle-proof สำหรับการพิสูจน์ hash ของแพ็กเก็ตเทียบกับ AppHash ของซอร์สเชนที่ ความสูงที่กำหนด ลำดับการส่งแพ็คเก็ตจาก “Zone1” ไปยัง “Zone2” ผ่าน "Hub" จะแสดงใน {รูปที่ X} ขั้นแรก  IBCPacketTx  พิสูจน์ให้ "ฮับ" ว่าแพ็กเก็ตนั้นรวมอยู่ในสถานะแอปของ “โซน1”. จากนั้น IBCPacketTx  อีกอันหนึ่งพิสูจน์ให้ “Zone2” ว่า แพ็กเก็ตรวมอยู่ในสถานะแอปของ "Hub" ในระหว่างนี้ ขั้นตอน IBCPacket  yelds เหมือนกัน:  SrcChainID  คือ “Zone1” เสมอ และ  DstChainID  จะเป็น "Zone2" เสมอ PacketProof ต้องมีเส้นทางป้องกัน Merkle ที่ถูกต้อง เช่น ดังต่อไปนี้: เมื่อ “Zone1” ต้องการส่งแพ็กเก็ตไปที่ “Zone2” ผ่าน “Hub” ข้อมูล IBCPacket  จะเหมือนกันไม่ว่าแพ็กเก็ตจะถูก Merkleized บน "Zone1", "Hub" หรือ "Zone2" การตะโกนที่ไม่แน่นอนเพียงอย่างเดียวคือ  สถานะสำหรับการติดตามการจัดส่ง เราขอขอบคุณเพื่อนและเพื่อนร่วมงานของเราสำหรับความช่วยเหลือในการจัดทำแนวความคิด ตรวจสอบและให้การสนับสนุนการทำงานของเรากับ Tendermint และ Cosmos IBC///<หมายเลข>

Zaki Manian จาก SkuChain ให้ความช่วยเหลืออย่างมากในการจัดรูปแบบและ ถ้อยคำ โดยเฉพาะภายใต้ส่วน ABCI Jehan Tremback จาก Althea และ Dustin Byington ที่ให้ความช่วยเหลือ การทำซ้ำครั้งแรก Andrew Miller จาก Honey Badger สำหรับข้อเสนอแนะเกี่ยวกับฉันทามติ Greg Slepak สำหรับข้อเสนอแนะเกี่ยวกับฉันทามติและถ้อยคำ ขอขอบคุณ Bill Gleim และ Seunghwan Han สำหรับสิ่งต่างๆ มากมาย ผลงาน ชื่อและองค์กรของคุณที่นี่สำหรับการบริจาคของคุณ 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 ซีโร่แคช: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4DAO: 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 nceAnalysisOfLibswift.pdf 20 ดีแอลเอส: 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