Cosmos: เครือข่ายบัญชีแยกประเภทแบบกระจาย

การแนะนำ

ความสำเร็จร่วมกันของระบบนิเวศโอเพ่นซอร์ส การแบ่งปัน 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 นั้นเรียบง่าย การรักษาความปลอดภัยไคลเอ็นต์แบบเบา ทำให้เป็นตัวเลือกที่เหมาะสำหรับมือถือและ กรณีการใช้งานอินเทอร์เน็ตออฟธิงส์ ในขณะที่ไคลเอ็นต์ 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 ที่ง่ายมากระหว่างขั้นตอนการสมัครและ กระบวนการฉันทามติ

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”

และ "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 ตรงกันและเสร็จสิ้นการซื้อขายในนามของ ของเทรดเดอร์

การใช้งาน

การแลกเปลี่ยนแบบรวมศูนย์สามารถสร้างรายการสั่งซื้อที่มีขีดจำกัดในระดับลึกได้ คำสั่งซื้อและดึงดูดเทรดเดอร์มากขึ้น สภาพคล่องเริ่มเพิ่มมากขึ้น สภาพคล่องในโลกการแลกเปลี่ยนจึงมีเครือข่ายที่แข็งแกร่ง เอฟเฟกต์ (หรืออย่างน้อยก็เอฟเฟกต์ของผู้ชนะ-ได้มากที่สุด) ในการแลกเปลี่ยน ธุรกิจ ผู้นำปัจจุบันสำหรับการแลกเปลี่ยนสกุลเงินดิจิทัลในปัจจุบัน คือ 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” และแต่ละชื่อ-

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

ธรรมาภิบาลและเศรษฐศาสตร์

แม้ว่า 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 ในขณะที่บล็อกปกติและบ่อยกว่าอนุญาต มาตราส่วนแนวตั้งเช่นกัน

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

ระเบียบวิธีฉันทามติที่ออกแบบมาอย่างดีควรจัดเตรียมไว้บ้าง รับประกันในกรณีที่เกินขีดความสามารถที่ยอมรับได้ และฉันทามติล้มเหลว นี่เป็นสิ่งจำเป็นอย่างยิ่งในด้านเศรษฐกิจ ระบบซึ่งพฤติกรรมไบเซนไทน์สามารถมีการเงินจำนวนมากได้ รางวัล การรับประกันที่สำคัญที่สุดคือรูปแบบของ 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

¨ อี