Cosmos: เครือข่ายบัญชีแยกประเภทแบบกระจาย
소개
오픈소스 생태계의 결합된 성공은 분산형 yle 공유 및 공개 암호화폐는 분산화된 인터넷 프로토콜에 대한 이해를 고취시켰습니다. 사회 경제적 인프라를 근본적으로 개선하는 데 사용될 수 있습니다. 우리는 Bitcoin 1와 같은 전문화된 blockchain 애플리케이션을 보았습니다. 암호화폐), Zerocash 2 및 Ethereum [3]와 같은 일반화된 smart contract 플랫폼 Etherium Virtual을 위한 수많은 분산 애플리케이션 Augur(예측 시장) 및 TheDAO과 같은 기계(EVM) [4] (투자 클럽). 그러나 현재까지 이 blockchain은 여러 가지 문제로 어려움을 겪었습니다. 총 에너지 비효율성, 열악함 또는 열악함을 포함한 단점 제한된 성능, 미성숙한 거버넌스 메커니즘. Bitcoin의 거래 처리량을 확장하기 위한 제안: 분리된 증인 [5] 및 BitcoinNG [6]은 수직 확장입니다. 단일 물리적 서버의 용량에 의해 제한되는 솔루션 완전한 감사 가능성의 속성을 보장하기 위해 기계. 라이트닝 네트워크 [7]은 Bitcoin 거래를 확장하는 데 도움이 될 수 있습니다.
일부 거래를 원장에서 완전히 제외하여 거래량 소액결제 및 개인정보 보호에 적합합니다. 지불 레일이지만 더 일반화된 경우에는 적합하지 않을 수 있습니다. 스케일링이 필요합니다. 이상적인 솔루션은 여러 개의 병렬 blockchain을 허용하는 솔루션입니다. 보안 속성을 유지하면서 상호 운용됩니다. 이것은 proof-of-work를 사용하면 불가능하지는 않지만 어려운 것으로 입증되었습니다. 병합됨 예를 들어 채굴을 통해 부모를 확보하는 작업이 가능해집니다. 체인은 하위 체인에서 재사용되지만 트랜잭션은 여전히 유지되어야 합니다. 각 노드별로 순서대로 검증되고 병합 채굴된 blockchain hashing 전력의 대부분이 공격에 취약합니다. 부모가 자식을 적극적으로 병합 채굴하지 않습니다. 학문적 검토 의 대체 blockchain 네트워크 아키텍처가 제공됩니다. 추가적인 맥락을 제공하고 다른 제안에 대한 요약을 제공합니다. 관련 작업의 단점. 여기에서는 새로운 blockchain 네트워크 아키텍처인 Cosmos을 제시합니다. 이 모든 문제를 해결하는 것입니다. Cosmos은 많은 사람들의 네트워크입니다 영역이라고 불리는 독립적인 blockchains. 영역은 다음에 의해 구동됩니다. 고성능을 제공하는 Tendermint Core [8], 일관되고 안전한 PBFT과 유사한 합의 엔진으로, 엄격한 포크책임이 악의적인 행위에 대한 통제를 보장합니다. 배우. Tendermint Core의 BFT 합의 알고리즘이 매우 적합합니다. 공개 proof-of-stake blockchain 확장용. Cosmos의 첫 번째 영역을 Cosmos 허브라고 합니다. Cosmos 허브는 간단한 다중 자산 proof-of-stake 암호화폐입니다. 네트워크가 적응하고 업그레이드. 또한 Cosmos 허브는 다음을 통해 확장할 수 있습니다. 다른 구역을 연결합니다. Cosmos 네트워크의 허브와 영역은 다음과 통신합니다. blockchain 간 통신(IBC) 프로토콜을 통해 서로 blockchains에 대한 일종의 가상 UDP 또는 TCP입니다. 토큰은 다음과 같습니다. 한 구역에서 다른 구역으로 안전하고 신속하게 이전됩니다.구역 간 유동성 교환이 필요하지 않습니다. 대신, 모든 영역 간 token 전송은 Cosmos 허브를 통과합니다. 각 구역이 보유한 token의 총량을 추적합니다. 는 허브는 각 영역을 다른 영역의 장애로부터 격리합니다. 왜냐하면 누구나 Cosmos 허브에 새 영역을 연결할 수 있습니다. 새로운 blockchain 혁신과의 미래 호환성을 위해. 이 섹션에서는 Tendermint 합의 프로토콜을 설명합니다. 그리고 이를 사용하여 애플리케이션을 구축하는 데 사용되는 인터페이스입니다. 더 알아보기 자세한 내용은 부록을 참조하세요. 전통적인 비잔틴 내결함성(BFT) 알고리즘에서 각 노드는 같은 무게를 가지고 있습니다. Tendermint에서 노드는 음수가 아닌 값을 갖습니다. 투표권의 양, 긍정적인 투표를 한 노드 전원을 validators라고 합니다. 검증인은 암호화 서명을 브로드캐스트하여 합의 프로토콜, 또는 다음 블록에 동의하기 위해 투표합니다. 검증인의 투표권은 처음부터 결정되거나 blockchain에 의해 결정적으로 변경되었습니다. 신청. 예를 들어, 다음과 같은 proof-of-stake 애플리케이션에서 Cosmos 허브에서 투표권은 다음에 의해 결정될 수 있습니다. 담보로 보세된 staking token 금액. 참고: ⅔ 및 ⅓과 같은 분수는 전체 투표의 분수를 나타냅니다. 모든 validator이 아닌 한 validator의 총 개수는 절대 아닙니다. 동일한 무게를 가지고 있습니다. >⅔는 “⅔ 이상”을 의미하고, ≥⅓은 “최소”를 의미합니다. ⅓”. Tendermint는 부분적으로 동기식인 BFT 합의 프로토콜입니다. DLS 합의 알고리즘 [20]에서 파생되었습니다. 텐더민트는
단순성, 성능 및 포크 책임으로 유명합니다. 프로토콜에는 알려진 validator 세트가 필요합니다. validator은 공개 키로 식별됩니다. 검증인은 다음을 시도합니다. 한 번에 하나의 블록에 대한 합의에 도달합니다. 여기서 블록은 목록입니다. 거래의. 블록에 대한 합의에 대한 투표는 다음과 같이 진행됩니다. 라운드. 각 라운드에는 라운드 리더 또는 제안자가 있습니다. 블록을 제안합니다. 그런 다음 validator은 단계적으로 다음 사항에 대해 투표합니다. 제안된 블록을 수락하거나 다음 라운드로 넘어갑니다. 는 라운드 제안자는 순서대로 결정적으로 선택됩니다. 투표권에 비례하여 validator 목록입니다. 프로토콜의 전체 세부 사항은 여기에 설명되어 있습니다. Tendermint의 보안은 최적의 비잔틴 사용에서 비롯됩니다. 절대다수(>⅔) 투표 및 잠금을 통한 내결함성 메커니즘. 이들은 함께 다음을 보장합니다. ≥⅓ 투표권은 다음 사항을 위반하는 비잔틴 방식이어야 합니다. 두 개 이상의 값이 커밋되는 안전. validator 세트가 안전 위반에 성공하거나 심지어 그렇게 하려는 시도는 프로토콜에 의해 식별될 수 있습니다. 이 혼란스러운 블록에 대한 투표와 방송이 모두 포함됩니다. 부당한 투표. 강력한 보장에도 불구하고 Tendermint는 탁월한 서비스를 제공합니다. 성능. 7개에 분산된 64개 노드의 벤치마크에서 5개 대륙의 데이터 센터, 상용 클라우드 인스턴스, Tendermint 합의는 한 번에 수천 건의 거래를 처리할 수 있습니다. 둘째, 커밋 대기 시간이 1~2초 정도입니다. 특히 1000건이 넘는 트랜잭션의 성능이 눈에 띕니다. 두 번째는 가혹한 적대적인 상황에서도 유지됩니다. validators가 악의적으로 제작된 투표를 충돌시키거나 방송합니다. 참조 자세한 내용은 아래 그림을 참조하세요.
Tendermint 합의 알고리즘의 주요 이점은 다음과 같습니다. 가벼운 클라이언트 보안으로 인해 모바일 및 사물 인터넷 사용 사례. Bitcoin 라이트 클라이언트는 동기화해야 합니다. 블록 헤더 체인을 찾아 가장 증거가 많은 것을 찾습니다. 작업, Tendermint 라이트 클라이언트는 변경 사항을 따라잡기만 하면 됩니다. validator 세트에 추가한 다음 >⅔ PreCommits를 확인하세요. 최신 상태를 결정하는 최신 블록입니다. 간결한 가벼운 클라이언트 증명으로 inter-blockchain도 가능합니다. 의사소통. Tendermint는 특정 행위를 방지하기 위한 보호 조치를 가지고 있습니다. 장거리 위험이 없는 이중 지출과 같은 주목할만한 공격 그리고 검열. 이에 대해서는 부록에서 더 자세히 설명합니다.Tendermint 합의 알고리즘은 다음과 같이 구현됩니다. Tendermint Core라는 프로그램입니다. 텐더민트 코어는 애플리케이션에 구애받지 않고 모든 것을 바꿀 수 있는 "합의 엔진" 결정론적 블랙박스 애플리케이션을 분산 복제로 변환 blockchain. Tendermint Core는 blockchain 애플리케이션에 연결됩니다. 애플리케이션 블록체인 인터페이스(ABCI) [17]를 통해. 따라서 ABCI blockchain 애플리케이션을 어떤 방식으로든 프로그래밍할 수 있습니다. 언어는 단순히 합의가 이루어지는 프로그래밍 언어가 아닙니다. 엔진이 작성되어 있습니다. 또한 ABCI를 사용하면 쉽게 기존 blockchain 스택의 합의 계층을 교체합니다. 우리는 잘 알려진 암호화폐인 Bitcoin에 비유합니다. Bitcoin는 각 노드가 유지 관리하는 암호화폐 blockchain입니다. 완전히 감사된 미사용 트랜잭션 출력(UTXO) 데이터베이스. 만약에 하나는 ABCI 위에 Bitcoin과 유사한 시스템을 만들고 싶었습니다. Tendermint Core는 다음을 담당합니다. 노드 간 블록 및 트랜잭션 공유 정식/불변의 거래 순서 확립( blockchain) 그 사이에 ABCI 애플리케이션은 다음을 담당합니다. UTXO 데이터베이스 유지 관리 거래의 암호화 서명 검증 거래가 존재하지 않는 자금을 지출하는 것을 방지 클라이언트가 UTXO 데이터베이스를 쿼리하도록 허용 Tendermint는 blockchain 디자인을 다음과 같이 분해할 수 있습니다. 애플리케이션 프로세스와 애플리케이션 사이에 매우 간단한 API를 제공합니다. 합의 과정.
การแนะนำ
ความสำเร็จร่วมกันของระบบนิเวศโอเพ่นซอร์ส การแบ่งปัน 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는 독립적인 병렬 blockchain의 네트워크입니다. 각각은 다음과 같은 고전적인 BFT 합의 알고리즘으로 구동됩니다. 텐더민트 1. 이 네트워크의 첫 번째 blockchain은 Cosmos 허브가 됩니다. 는 Cosmos 허브는 다음을 통해 다른 많은 blockchain(또는 영역)에 연결됩니다. 새로운 inter-blockchain 통신 프로토콜. Cosmos 허브 수많은 token 유형을 추적하고 총계를 기록합니다. 연결된 각 영역의 token 수. 토큰은 다음과 같습니다. 한 구역에서 다른 구역으로 안전하고 신속하게 이전됩니다. 구역 간 액체 교환이 필요하지 않습니다. 존 간 코인 전송은 Cosmos 허브를 통해 이루어집니다. 이 아키텍처는 blockchain 공간이 안고 있는 많은 문제를 해결합니다. 애플리케이션 상호 운용성, 확장성 및 원활한 업그레이드. 예를 들어 Bitcoind에서 파생된 영역은 Go-Ethereum, CryptoNote, ZCash 또는 모든 blockchain 시스템은 Cosmos 허브에 연결하세요. 이 영역에서는 Cosmos이(가) 다음을 수행할 수 있습니다. 글로벌 트랜잭션 수요를 충족하기 위해 무한한 확장이 가능합니다. 구역은 또한 다음과 같이 지원될 분산형 교환을 위한 훌륭한 yt입니다. 음. Cosmos는 단순한 분산 원장이 아니며, Cosmos 허브는 벽으로 둘러싸인 정원이나 우주의 중심이 아닙니다. 우리는 분산 원장의 개방형 네트워크를 위한 프로토콜 설계 미래 금융시스템의 새로운 기반이 될 수 있는 암호화 원칙, 건전한 경제, 합의를 바탕으로 이론, 투명성, 책임. Cosmos 허브는 Cosmos의 첫 번째 공개 blockchain입니다. Tendermint의 BFT 합의 알고리즘으로 구동되는 네트워크. 는 Tendermint 오픈 소스 프로젝트는 2014년에 탄생했습니다. Bitcoin 작업 증명 합의 알고리즘의 속도, 확장성 및 환경 문제. 검증된 기술을 활용하고 개선함으로써
BFT 1988년 MIT에서 개발된 알고리즘 [20], Tendermint 팀은 proof-of-stake을 개념적으로 시연한 최초의 팀이었습니다. 무관계 문제를 해결하는 암호화폐 1세대 proof-of-stake 암호화폐로 인해 어려움을 겪고 있습니다. NXT 및 BitShares1.0으로. 오늘날 거의 모든 Bitcoin 모바일 지갑은 신뢰할 수 있는 서버를 사용하여 거래 확인을 제공합니다. 이는 작업 증명이 완료되기 전에 많은 확인을 기다려야 하기 때문입니다. 트랜잭션은 되돌릴 수 없게 커밋된 것으로 간주될 수 있습니다. Doublespend 공격은 다음과 같은 서비스에서 이미 입증되었습니다. 코인베이스. 다른 blockchain 합의 시스템과 달리 Tendermint는 다음을 제공합니다. 즉각적이고 안전한 모바일 클라이언트 결제 확인. Tendermint는 절대 포크되지 않도록 설계되었기 때문에 모바일에서는 지갑은 즉시 거래 확인을 받을 수 있습니다. 신뢰할 수 없고 실용적인 결제가 스마트폰에서 현실이 되었습니다. 이 다음과 같이 사물 인터넷 애플리케이션에 상당한 영향을 미치고 있습니다. 음. Cosmos의 검증인은 Bitcoin 채굴자와 비슷한 역할을 가지고 있지만 대신 암호화 서명을 사용하여 투표하세요. 검증인은 커밋을 담당하는 안전한 전용 머신 블록. validator이 아닌 사람은 자신의 staking token(라고 함)을 위임할 수 있습니다. “atoms”)를 validator에 보내 블록 수수료와 아톰의 일부를 얻으세요 보상을 제공하지만, 다음과 같은 경우 처벌(삭감)을 받을 위험이 있습니다. 대리인 validator이(가) 해킹당하거나 프로토콜을 위반합니다. 입증된 Tendermint BFT 합의의 안전 보장 및 담보 이해관계자 예치금–validators 및 위임자–제공 노드와 라이트 클라이언트를 위한 입증 가능하고 수량화 가능한 보안. 분산 공공 원장은 헌법과 거버넌스 시스템. Bitcoin은(는) Bitcoin 재단에 의존하며업그레이드를 조정하기 위해 마이닝을 수행하지만 이는 느린 프로세스입니다. Ethereum 주소를 하드포크한 후 ETH와 ETC로 분할 DAO 해킹, 주로 사전 사회 계약이 없었기 때문입니다. 그러한 결정을 내리는 메커니즘도 없습니다. Cosmos 허브의 검증인과 위임자는 투표할 수 있습니다. 시스템의 미리 설정된 매개변수를 변경할 수 있는 제안 자동으로(예: 블록 가스 한도) 업그레이드 조정 인간이 읽을 수 있는 헌법 개정안에 투표할 수도 있습니다. Cosmos 허브의 정책을 관리합니다. 헌법 다음과 같은 문제에 대해 이해관계자 간의 결속력을 허용합니다. 도난 및 버그(예: TheDAO 사건)를 방지하여 더 빠르고 더 깨끗한 해상도. 각 영역은 자체 구성과 거버넌스를 가질 수도 있습니다. 메커니즘도 그렇고. 예를 들어, Cosmos 허브에는 허브에서 불변성을 강제하는 헌법(롤백 없음, Cosmos 허브 노드 구현의 버그를 위해 저장) 각 영역은 롤백과 관련된 자체 정책을 설정할 수 있습니다. 서로 다른 정책 영역 간의 상호 운용성을 가능하게 함으로써 Cosmos 네트워크는 사용자에게 궁극적인 자유와 잠재력을 제공합니다. 무허가 실험. 여기서 우리는 분산화와 확장성의 새로운 모델을 설명합니다. Cosmos는 다음을 기반으로 하는 많은 blockchain의 네트워크입니다. 텐더민트. 기존 제안은 '단일'을 만드는 것을 목표로 하고 있지만 blockchain”(총 글로벌 트랜잭션 주문 포함), Cosmos 많은 blockchain이 서로 동시에 실행되도록 허용합니다. 상호 운용성을 유지하면서. 기본적으로 Cosmos 허브는 많은 독립적인 서비스를 관리합니다. blockchain는 "영역"이라고 합니다(때때로 "샤드"라고도 함). "샤딩"으로 알려진 데이터베이스 확장 기술 참조).
게시된 영역에서 최근 블록 커밋의 지속적인 스트림 허브를 사용하면 허브가 각 영역의 상태를 따라갈 수 있습니다. 마찬가지로 각 영역은 허브의 상태를 따라갑니다(그러나 영역은 간접적인 방법 외에는 서로 연락을 유지하지 마십시오. 허브). 그런 다음 정보 패킷이 한 곳에서 전달됩니다. Merkle 증명을 증거로 게시하여 다른 영역으로 영역을 확장합니다. 정보가 전송되고 수신되었습니다. 이 메커니즘을 inter-blockchain 통신 또는 줄여서 IBC입니다. 모든 영역은 그 자체로 비순환 그래프를 형성하는 허브가 될 수 있습니다. 하지만 명확성을 위해 간단한 내용만 설명하겠습니다. 허브는 하나만 있고 허브가 아닌 많은 구성 구역. Cosmos 허브는 다중 자산을 호스팅하는 blockchain입니다. token을 개인 사용자가 보유할 수 있는 분산 원장 또는 영역 자체별로. 이 token은 하나의 영역에서 이동할 수 있습니다. "코인 패킷"이라고 불리는 특별한 IBC 패킷을 통해 다른 사람에게 전달됩니다. 허브는 전체의 전역 불변성을 보존하는 역할을 담당합니다. 영역 전체에 걸쳐 각 token의 양. IBC 코인 패킷 트랜잭션은 송신자, 허브 및 수신자에 의해 커밋되어야 합니다. blockchains.Cosmos 허브는 전체에 대한 중앙 원장 역할을 하기 때문에 시스템에서는 허브의 보안이 가장 중요합니다. 동안 각 영역은 다음과 같이 보호되는 Tendermint blockchain일 수 있습니다. 4개(또는 BFT 합의가 필요하지 않은 경우 더 적음), 허브 전 세계적으로 분산된 validator 세트로 보호되어야 합니다. 다음과 같은 가장 심각한 공격 시나리오를 견딜 수 있습니다. 대륙 네트워크 분할 또는 국가 후원 공격. Cosmos 영역은 IBC를 교환하는 독립적인 blockchain입니다. 허브와의 메시지. 허브의 관점에서 구역은 다중 자산 동적 멤버십 다중 서명 계정 IBC 패킷을 사용하여 token을 보내고 받을 수 있습니다. 처럼 암호화폐 계정, 영역은 다음보다 더 많은 token을 전송할 수 없습니다. 가지고 있지만 그것을 가지고 있는 다른 사람으로부터 token을(를) 받을 수 있습니다. A 구역 하나 이상의 token 유형의 "소스"로 지정될 수 있습니다. token 공급량을 주입할 수 있는 권한을 부여합니다. Cosmos 허브의 아톰은 영역의 validator에 스테이킹될 수 있습니다. 허브에 연결되었습니다. 이 영역에 대한 이중 지출 공격이 발생하는 동안 투표권의 ⅔ 이상이 있는 영역인 Tendermint의 포크 책임으로 인해 원자가 삭감될 수 있습니다. 비잔틴은 잘못된 상태를 커밋할 수 있습니다. Cosmos 허브는 그렇지 않습니다 다른 영역에서 커밋된 트랜잭션을 확인하거나 실행하므로 신뢰할 수 있는 영역에 token을 보내는 것은 사용자의 책임입니다. 앞으로 Cosmos 허브의 거버넌스 시스템은 허브를 통과할 수 있습니다. 영역 오류를 설명하는 개선 제안. 에 대한 예를 들어 일부(또는 전체) 영역에서 아웃바운드 token 전송이 발생할 수 있습니다. 구역의 비상 회로 차단을 허용하도록 조절됩니다. (token 전송이 일시적으로 중단됨) 공격이 감지되면 이제 허브와 영역이 서로 통신하는 방법을 살펴보겠습니다. 기타. 예를 들어 blockchain이 3개 있는 경우 "Zone1", "Zone2",
그리고 “Hub”, 그리고 우리는 “Zone1”이 목적지로 향하는 패킷을 생성하기를 원합니다. “Hub”를 통과하는 “Zone2”에 대해. 한 곳에서 패킷을 이동하려면 blockchain 다른 사람에게 증거가 수신 체인에 게시됩니다. 증거는 전송 체인이 다음을 위한 패킷을 게시했음을 나타냅니다. 목적지 추정. 수신 체인이 이 증명을 확인하려면 발신자의 블록 헤더를 따라갈 수 있어야 합니다. 이 메커니즘은 사이드체인에서 사용되는 것과 유사합니다. 두 개의 상호 작용하는 체인은 다음을 통해 서로를 인식합니다. 존재 증명 데이터그램의 양방향 스트림 (거래). IBC 프로토콜은 두 가지 유형의 프로토콜을 사용하여 자연스럽게 비활성화될 수 있습니다. 트랜잭션: IBCBlockCommitTx 트랜잭션을 허용합니다. blockchain는 가장 최근 블록-hash의 관찰자에게 증명하기 위해, 및 IBCPacketTx 트랜잭션을 통해 blockchain을(를) 수행할 수 있습니다. 주어진 패킷이 실제로 게시되었음을 모든 관찰자에게 증명합니다. 발신자의 신청에 따라 Merkle-proof을 통해 최근 블록-hash. IBC 메커니즘을 두 개의 개별 트랜잭션으로 분할함으로써 우리는 수신 체인의 기본 수수료 시장 메커니즘을 허용합니다. 어떤 패킷이 커밋(즉, 승인)되는지 결정합니다. 전송 체인에 대해 완전한 자유를 허용합니다. 많은 아웃바운드 패킷이 허용됩니다. 위의 예에서는 "Zone1"의 블록-hash을 업데이트하기 위해 '허브'(또는 'Zone2'의 '허브')에서 IBCBlockCommitTx거래는 블록-hash과 함께 "허브"에 게시되어야 합니다. “Zone1”(또는 “Hub”의 블록이 hash인 “Zone2”). 자세한 내용은 IBCBlockCommitTx 및 IBCPacketTx를 참조하세요. 두 가지 IBC 거래 유형에 대해 Bitcoin이 분산되어 있어 더 안전한 것과 마찬가지로, 대량 복제 원장을 사용하면 교환의 취약성을 줄일 수 있습니다. blockchain에서 실행하여 외부 및 내부 해킹을 수행합니다. 우리 이것을 분산 교환이라고 부릅니다. 암호화폐 커뮤니티가 분산화라고 부르는 것 오늘날의 거래소는 "원자 교차 체인"(AXC) 거래를 기반으로 합니다. AXC 트랜잭션을 사용하면 두 명의 사용자가 두 개의 다른 체인은 두 개의 전송 트랜잭션을 만들 수 있습니다. 두 원장 모두에 함께 커밋되거나 전혀 커밋되지 않습니다(예: 원자적으로). 예를 들어, 두 명의 사용자가 비트코인을 이더(또는 두 개의 서로 다른 원장에 있는 두 개의 token) AXC 트랜잭션을 사용하여 Bitcoin 및 Ethereum이 각각 연결되어 있지 않더라도 기타. AXC 거래에서 거래소를 운영하면 얻을 수 있는 이점은 다음과 같습니다. 두 사용자 모두 서로를 신뢰하거나 거래 매칭을 신뢰할 필요가 없습니다. 서비스. 단점은 양측 모두 온라인 상태여야 한다는 것입니다. 거래가 발생합니다. 또 다른 유형의 탈중앙화 거래소는 대량 복제 거래소입니다. 자체적으로 실행되는 분산 교환 blockchain. 사용자 이러한 종류의 교환은 지정가 주문을 제출하고 전환할 수 있습니다. 컴퓨터가 꺼져 있으면 사용자가 없어도 거래가 실행될 수 있습니다. 온라인. blockchain이(가) 대신하여 거래를 일치시키고 완료합니다. 상인의.
Cosmos สถาปัตยกรรม
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 ตรงกันและเสร็จสิ้นการซื้อขายในนามของ ของเทรดเดอร์
응용
중앙 집중식 거래소는 한도가 높은 주문서를 생성할 수 있습니다. 주문을 통해 더 많은 거래자를 유치할 수 있습니다. 유동성이 더 많은 것을 낳습니다 거래소 세계에는 유동성이 있어 강력한 네트워크가 있습니다. 교환의 효과(또는 최소한 승자 독식 효과) 사업. 현재 암호화폐 거래소의 선두주자 24시간 거래량이 2,000만 달러에 달하는 Poloniex이며 2위는 24시간 거래량이 500만 달러인 Bitynex. 이처럼 강력한 네트워크를 고려하면 따라서 AXC 기반 탈중앙화 거래소가 중앙화된 거래소를 통해 거래량을 확보하세요. 분산화를 위해 중앙화된 거래소와 경쟁하려면 거래소가 필요합니다. 지정가 주문이 포함된 심층 주문장을 지원합니다. 분산된 것만 blockchain에서 교환하면 이를 제공할 수 있습니다. Tendermint는 더 빠른 거래에 대한 추가적인 이점을 제공합니다. 커밋합니다. 희생 없이 빠른 동시성을 우선시하여 일관성, Cosmos의 영역은 트랜잭션을 빠르게 동기화할 수 있습니다. 교환 주문 거래와 IBC token 이체 모두 그리고 다른 지역에서. 오늘날 암호화폐 거래소의 상황을 고려하면, Cosmos에 대한 애플리케이션은 분산 교환(일명 Cosmos DEX). 거래 처리 능력은 물론이고 커밋 대기 시간은 중앙 집중식 커밋 대기 시간과 비슷할 수 있습니다. 교환. 거래자는 실행 가능한 지정가 주문을 제출할 수 있습니다. 양측 모두 온라인 상태일 필요 없이 말이죠. 그리고 텐더민트와 함께, Cosmos 허브 및 IBC, 거래자는 자금을 들어오고 나갈 수 있습니다. 다른 구역과의 빠른 교환. 권한 있는 영역은 연결된 token의 소스 역할을 할 수 있습니다. 또 다른 암호화폐. 다리는 관계와 비슷하다 Cosmos 허브와 영역 사이 둘 다 따라잡아야 해 token이 갖고 있는 증거를 확인하기 위해 다른 블록의 최신 블록 하나에서 다른 것으로 옮겨졌습니다. Cosmos의 "브리지 영역" 네트워크는 허브뿐만 아니라 다른 허브도 따라잡습니다.
암호화폐. 교량 구역을 통한 간접 연결은 다음을 허용합니다. 다른 사람들에게 단순하고 불가지론적인 상태를 유지하는 허브의 논리 blockchain 합의 전략(예: Bitcoin의 proof-of-work) 광산. 각 브리지 영역 validator은 Tendermint 기반의 blockchain 특수 ABCI 브리지 앱을 사용하지만 전체 노드도 "원산지" blockchain. 새로운 블록이 원점에서 채굴되면 브릿지 존은 validators는 서명을 통해 커밋된 블록에 동의하게 됩니다. 출발지의 blockchain에 대한 각자의 로컬 보기를 공유합니다. 팁. 교량지역이 출발지에서 대금을 수령한 경우(그리고 해당 사건에서 충분한 동의가 확인된 것으로 합의되었습니다. Ethereum 또는 Bitcoin과 같은 PoW 체인의 해당 해당 잔액으로 브리지존에 계정이 생성됩니다. Ethereum의 경우 브리지 존은 동일하게 공유할 수 있습니다. validator-Cosmos 허브로 설정됩니다. Ethereum 쪽( 원산지), 브릿지 계약을 통해 이더 보유자가 이더를 보낼 수 있습니다. 브리지 계약으로 전송하여 브리지 영역으로 이동 Ethereum. 브릿지 계약을 통해 에테르가 수신되면, 적절한 IBC 패킷이 없으면 이더를 인출할 수 없습니다. 교량 구역으로부터 교량 계약에 의해 수신됩니다. 는 bridge-contract는 bridge-zone의 validator 세트를 추적합니다. Cosmos 허브의 validator 세트와 동일할 수 있습니다. Bitcoin의 경우, 대신에 단일 브리지 계약, 각 UTXO은 임계값 다중 서명 P2SH 공개 스크립트. 의 한계로 인해 P2SH 시스템에서는 서명자가 Cosmos와 동일할 수 없습니다. 허브 validator-세트.브리지 영역의 이더(“브리지 에테르”)는 다음으로 전송될 수 있습니다. 그리고 허브에서, 나중에 트랜잭션으로 파괴됩니다. Ethereum의 특정 출금 주소로 보냅니다. IBC 브리지존에서 트랜잭션이 발생했음을 증명하는 패킷 Ethereum 브리지 계약에 게시되어 에테르를 허용할 수 있습니다. 철회됩니다. Bitcoin의 경우 제한된 스크립팅 시스템으로 인해 IBC 코인 전송 메커니즘을 반영하기 위해 difycult를 사용하세요. 각 UTXO 자체 독립적인 출판물이 있으므로 모든 UTXO은(는) 세트가 변경되면 새로운 UTXO로 마이그레이션되었습니다. Bitcoin 에스크로 서명자. 한 가지 해결책은 압축하고 총 개수를 유지하기 위해 필요에 따라 UTXO 세트의 압축을 풉니다. UTXOs가 다운되었습니다. 이러한 브리지 계약의 위험은 악성 validator 세트입니다. ≥⅓ 비잔틴 투표권으로 인해 포크가 발생하여 이더가 인출될 수 있습니다. 브리지 영역에 브리지 디더를 유지하면서 Ethereum의 브리지 계약에서. 더 나쁜 것은 >⅔ 비잔틴 투표권이 브릿지 컨트랙트에 보낸 사람에게서 이더를 노골적으로 훔칩니다. 브리지 존의 원래 브리지 논리에서 벗어났습니다. 교량을 다음과 같이 설계함으로써 이러한 문제를 해결할 수 있습니다. 전적으로 책임이 있습니다. 예를 들어 허브와 허브의 모든 IBC 패킷 출발지에서는 교량 구역의 승인이 필요할 수 있습니다. 브리지 영역의 모든 상태 전환이 가능하도록 하는 방식 허브나 원본에서 효율적으로 이의를 제기하고 검증합니다. 브리지 계약. 허브와 오리진은 브리지존 validator이 담보를 게시하고 token이 외부로 전송되도록 허용해야 합니다. 브릿지 계약을 연기해야 합니다(그리고 담보를 해제해야 합니다). 충분히 긴 기간) 독립 감사인. 우리는 사양의 디자인을 남겨두고 이 시스템의 구현은 미래로 공개됩니다 Cosmos
Cosmos 허브에서 통과될 개선 제안 거버넌스 시스템. 확장 문제를 해결하는 것은 Ethereum에 대한 공개 문제입니다. 현재 Ethereum 노드는 모든 단일 트랜잭션을 처리하고 또한 모든 상태를 저장합니다. 링크. Tendermint는 Ethereum보다 훨씬 빠르게 블록을 커밋할 수 있기 때문에 proof-of-work, EVM Tendermint 합의로 구동되는 영역 및 브리지 에테르에서 작동하면 더 높은 성능을 제공할 수 있습니다. Ethereum blockchains. 또한 Cosmos 허브 및 IBC 패킷 메커니즘은 임의의 계약 논리를 허용하지 않습니다. 실행 자체는 token 움직임을 조정하는 데 사용될 수 있습니다. 서로 다른 영역에서 실행되는 Ethereum 계약 간, 다음을 통해 token 중심 Ethereum 확장을 위한 기반 제공 샤딩. Cosmos 영역은 다음에서 정의되는 임의의 응용 프로그램 논리를 실행합니다. 영역 수명의 시작이며 잠재적으로 업데이트될 수 있습니다. 시간이 지남에 따라 거버넌스에 의해. 이러한 zexibility를 통해 Cosmos 영역은 다음을 수행할 수 있습니다. Ethereum와 같은 다른 암호화폐에 대한 브리지 역할을 하거나 Bitcoin 및 해당 blockchain의 파생 상품도 허용합니다. 동일한 코드베이스를 활용하지만 다른 validator 세트와 초기 배포. 이는 기존의 많은 암호화폐를 허용합니다. Ethereum, Zerocash, Bitcoin와 같은 프레임워크, CryptoNote 등이 Tendermint Core와 함께 사용됩니다. 공통 네트워크에서 더 높은 성능의 합의 엔진, 상호 운용성을 위한 엄청난 기회를 열어줍니다. 플랫폼. 또한 다중 자산 blockchain으로서 단일 트랜잭션에는 여러 개의 입력과 출력이 포함될 수 있습니다. 입력은 token 유형이 될 수 있으며, Cosmos을 직접 사용할 수 있습니다. 주문이 가정되지만 분산형 교환을 위한 플랫폼다른 플랫폼을 통해 매칭됩니다. 또는 영역이 게재될 수 있습니다. 분산된 내결함성 교환(주문서 포함)으로, 기존 중앙 집중식에 비해 크게 개선될 수 있습니다. 시간이 지남에 따라 해킹당하는 경향이 있는 암호화폐 거래소. 영역은 blockchain 지원되는 엔터프라이즈 버전으로도 사용할 수 있습니다. 특정 서비스의 일부가 전통적으로 조직이나 조직 그룹에 의해 운영됩니다. 대신 특정 영역에서 ABCI 애플리케이션으로 실행됩니다. 대중의 보안과 상호 운용성을 상속할 수 있습니다. Cosmos 네트워크에 대한 제어권을 희생하지 않고 서비스. 따라서 Cosmos은 두 세계의 장점을 모두 제공할 수 있습니다. blockchain 기술을 활용하려고 하지만 실제로는 그렇지 않은 조직 분산된 제3자에게 통제권을 완전히 양도하는 것을 조심하세요. 파티. 일부에서는 일관성을 선호하는 데 큰 문제가 있다고 주장합니다. Tendermint와 같은 합의 알고리즘은 모든 네트워크에서
⅔인 단일 파티션이 없게 만드는 파티션 투표권(예: ≥⅓이 진에 참여)은 합의를 완전히 중단시킵니다. Cosmos 아키텍처는 다음을 사용하여 이 문제를 완화하는 데 도움이 될 수 있습니다. 투표권이 있는 지역 자치 구역을 갖춘 글로벌 허브 각 영역에 대해 공통 지리적 기반을 기반으로 배포됩니다. 지역. 예를 들어, 공통 패러다임은 개인에 대한 것일 수 있습니다. 도시나 지역을 공유하면서 자체 존을 운영할 수 있습니다. 공통 허브(예: Cosmos 허브)를 통해 지방자치 활동을 가능하게 합니다. 임시 네트워크로 인해 허브가 중단되는 경우에도 지속됩니다. 파티션. 이는 실제 지질학적, 정치적, 견고한 설계 시 고려해야 할 네트워크 토폴로지 특징 연합 내결함성 시스템.
NameCoin은 문제를 해결하려고 시도한 최초의 blockchain 중 하나였습니다. Bitcoin blockchain을 적용하여 이름 확인 문제가 발생했습니다. 불행하게도 이 접근 방식에는 몇 가지 문제가 있었습니다. Namecoin을 사용하면 예를 들어 @satoshi가 과거 어느 시점에 특정 공개 키로 등록된 경우 하지만 그 이후 공개 키가 존재했는지 여부는 알 수 없습니다. 마지막 이후 모든 블록을 다운로드하지 않는 한 최근에 업데이트되었습니다. 그 이름의 업데이트. 이는 Bitcoin의 제한 때문입니다. UTXO 트랜잭션 Merkle-ization 모델, 여기서는 트랜잭션(변경 가능한 애플리케이션 상태는 아님)이 Merkle화되었습니다. 블록-hash에 들어갑니다. 이를 통해 존재를 증명할 수 있지만 이후 이름 업데이트가 존재하지 않는다는 것은 증명할 수 없습니다. 그러므로 우리는 알 수 없다. 전체를 신뢰하지 않고 이름의 가장 최근 값을 확실하게 노드를 다운로드하거나 대역폭에 상당한 비용이 발생합니다. 전체 blockchain. NameCoin에 Merkle화된 검색 트리를 구현하더라도, proof-of-work에 대한 종속성은 가벼운 클라이언트 확인을 만듭니다. 문제가 있다. 라이트 클라이언트는 전체 사본을 다운로드해야 합니다. 전체 blockchain(또는 적어도 모든 블록)의 모든 블록에 대한 헤더 이름에 대한 마지막 업데이트 이후의 헤더). 이는 다음을 의미합니다. 대역폭 요구 사항은 시간에 따라 선형적으로 확장됩니다. [21]. 또한 proof-of-work blockchain의 이름 변경 추가 proof-of-work 확인 블록을 기다려야 합니다. Bitcoin에서는 최대 1시간이 걸릴 수 있습니다. Tendermint를 사용하려면 가장 최근 블록인 hash만 있으면 됩니다. validators 정족수(투표권으로)에 의해 서명되었으며 Merkle 이름과 관련된 현재 값에 대한 증거. 이것은 그것을 만든다 간결하고 빠르며 안전한 라이트 클라이언트를 가질 수 있습니다 이름 값 확인. Cosmos에서는 이 개념을 더 확장할 수 있습니다. 각각 Cosmos의 이름 등록 영역은 ".com" 또는 ".org"와 같은 연관된 최상위 도메인(TLD) 이름을 가질 수 있으며 각 이름은
등록 구역은 자체 거버넌스와 등록을 가질 수 있습니다. 규칙.
การใช้งาน
การแลกเปลี่ยนแบบรวมศูนย์สามารถสร้างรายการสั่งซื้อที่มีขีดจำกัดในระดับลึกได้ คำสั่งซื้อและดึงดูดเทรดเดอร์มากขึ้น สภาพคล่องเริ่มเพิ่มมากขึ้น สภาพคล่องในโลกการแลกเปลี่ยนจึงมีเครือข่ายที่แข็งแกร่ง เอฟเฟกต์ (หรืออย่างน้อยก็เอฟเฟกต์ของผู้ชนะ-ได้มากที่สุด) ในการแลกเปลี่ยน ธุรกิจ ผู้นำปัจจุบันสำหรับการแลกเปลี่ยนสกุลเงินดิจิทัลในปัจจุบัน คือ 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 허브는 다중 자산 분산 원장이지만 다음이 있습니다. 원자라고 불리는 특별한 기본 token. 원자는 유일한 staking Cosmos 허브의 token. 아톰은 보유자가 다음을 수행할 수 있는 라이선스입니다. 다른 validator에 투표하고, 검증하고, 위임하세요. Ethereum처럼 에테르, 아톰은 거래 수수료를 지불하는 데에도 사용될 수 있습니다. 스팸을 완화하세요. 추가적인 Inzationary Atom 및 블록 트랜잭션 수수료는 validators 및 위임한 위임자에게 보상됩니다. validators. BurnAtomTx 거래는 모든 것을 복구하는 데 사용될 수 있습니다. 예비 풀에서 비례적인 양의 tokens. 창세기에서 원자 tokens 및 validators의 초기 분포 Cosmos 모금 행사의 기부자(75%), 주요 기부자에게 전달됩니다. (5%), Cosmos Network Foundation (10%) 및 ALL IN BITS, Inc (10%). 창세기부터 전체 원자량의 1/3이 매년 결속된 validator 및 위임자에게 보상을 받습니다. 자세한 내용은 Cosmos 계획을 참조하세요. Bitcoin 또는 다른 proof-of-work blockchain과 달리 Tendermint는 blockchain은 증가된 validator로 인해 속도가 느려집니다. 통신 복잡성. 다행히도 우리는 충분히 지원할 수 있습니다 validators는 전 세계적으로 분산된 강력한 blockchain을 만들기 위한 것입니다. 매우 빠른 트랜잭션 확인 시간과 대역폭으로서
스토리지와 병렬 컴퓨팅 용량이 늘어나면 다음과 같은 일이 가능해질 것입니다. 앞으로 더 많은 validator을 지원합니다. 생성일에는 최대 validator 수가 다음으로 설정됩니다. 100이고, 이 숫자는 10년 동안 13%의 비율로 증가할 것입니다. 300 validators에 정착합니다. 아직 Atom 보유자가 아닌 경우 다음을 통해 validator이 될 수 있습니다. BondTx 거래에 서명하고 제출합니다. 금액 담보로 제공되는 원자는 0이 아니어야 합니다. 누구나 될 수 있다 a validator, 현재 크기가 validator 세트가 최대 validator 수보다 큽니다. 허용됩니다. 이 경우 해당 거래는 해당 금액만큼만 유효합니다. 원자가 보유하고 있는 유효 원자의 양보다 크다. 가장 작은 validator, 여기서 유효 원자에는 위임된 원자가 포함됩니다. 이러한 방식으로 새로운 validator이 기존 validator을 대체하면, 기존 validator은 비활성화되고 모든 원자와 위임된 원자는 결합 해제 상태로 들어갑니다. 어떤 경우에도 validator에 약간의 벌금이 부과되어야 합니다. 의도적이거나 의도하지 않은 제재 조치로부터의 이탈 프로토콜. 일부 증거는 즉시 인정될 수 있습니다. 동일한 높이와 원형으로 이중 서명을 하거나 다음 사항을 위반하는 경우 0년차: 100 1년차: 113 2년차: 127 3년차: 144 4년차: 163 5년차: 184 6년차: 208 7년차: 235 8년차: 265 9년차: 300 10년차: 300 ...
"prevote-the-lock"(Tendermint 합의 프로토콜의 규칙). 이러한 증거로 인해 validator은(는) 좋은 평판을 잃게 됩니다. 그리고 그것의 결합된 원자뿐만 아니라 tokens의 비례적인 몫도 포함됩니다. 집합적으로 "스테이크"라고 불리는 예비 풀은 삭감됩니다. 때로는 지역적 문제로 인해 validator을 사용할 수 없는 경우도 있습니다. 네트워크 중단, 정전 또는 기타 이유. 만약, 혹시라도 과거 ValidatorTimeoutWindow 블록, validator의 시점을 가리킵니다. 커밋 투표는 blockchain에 포함되지 않습니다. ValidatorTimeoutMaxAbsent 회, 해당 validator는 다음과 같습니다. 비활성화되고 ValidatorTimeoutPenalty(기본값 1%)가 손실됩니다. 스테이크. 일부 "악의적인" 행동은 명확하게 식별할 수 없는 결과를 낳습니다. blockchain에 대한 증거. 이러한 경우 validator은 다음을 수행할 수 있습니다. 대역 외 조정을 통해 이러한 악성 코드의 시간 초과를 강제합니다. validators, 압도적인 합의가 있는 경우. ≥⅓ 연합으로 인해 Cosmos 허브가 중단되는 상황에서 투표권이 사라지거나 ≥⅓ 연합이 있는 상황에서 투표권 검열을 통해 악의적인 행위에 대한 증거를 검열합니다. blockchain를 입력하면 허브는 하드포크로 복구되어야 합니다. 재구성 제안. (“포크 및 검열 공격” 링크) Cosmos 허브 validators는 모든 token 유형 또는 조합을 허용할 수 있습니다. 거래 처리에 대한 수수료 유형입니다. 각 validator은(는) 원하는 환율을 주관적으로 설정하고 선택하세요. BlockGasLimit가 다음인 한 원하는 거래는 무엇이든 가능합니다. 초과하지 않았습니다. 아래에 명시된 세금을 제외한 징수된 수수료는 담보된 이해관계자들에게 비율에 따라 재분배됩니다. ValidatorPayoutPeriod마다 결합된 원자(기본값 1 시간).징수된 거래 수수료 중 ReserveTax(기본 2%)는 예비 풀 쪽으로 가서 예비 풀을 늘리고 Cosmos 네트워크의 보안과 가치를 높입니다. 이것들 결정에 따라 자금을 분배할 수도 있습니다. 거버넌스 시스템에 의해 만들어졌습니다. 자신의 투표권을 다른 validator에게 위임하는 Atom 보유자 위임받은 validator에게 수수료를 지불하세요. 위원회는 다음을 수행할 수 있습니다. validator마다 설정됩니다. Cosmos 허브의 보안은 허브의 보안 기능입니다. 기본 validator 및 위임자의 위임 선택. 발견된 물질의 발견과 조기 보고를 장려하기 위해 취약점, Cosmos 허브는 해커가 게시하도록 권장합니다. 다음과 같은 ReportHackTx 트랜잭션을 통한 성공적인 악용 validator이 해킹당했습니다. 이 주소로 포상금을 보내주세요.” 시 이러한 악용으로 인해 validator 및 위임자는 비활성화됩니다. 모든 사람의 아톰의 HackPunishmentRatio(기본값 5%)는 슬래시 및 모든 원자의 HackRewardRatio(기본값 5%) 해커의 바운티 주소로 보상을 받게 됩니다. validator 백업 키를 사용하여 나머지 Atom을 복구해야 합니다. 이 기능이 남용되어 전송되는 것을 방지하기 위해 미확정 원자, 미확정 원자와 미확정 원자의 부분 ReportHackTx 전후의 validator 및 위임자는 동일하게 유지되며 해커 현상금에는 일부가 포함됩니다. 미확정 원자(있는 경우). Cosmos 허브는 분산 조직에 의해 운영됩니다. 이를 위해서는 잘 정의된 거버넌스 메커니즘이 필요합니다. 변수와 같은 blockchain에 대한 다양한 변경 사항을 조정합니다.
시스템의 매개 변수뿐만 아니라 소프트웨어 업그레이드 및 헌법 개정. 모든 validator은 모든 제안에 대한 투표를 담당합니다. 실패 적시에 제안에 투표하면 validator 결과가 발생합니다. 일정 시간 동안 자동으로 비활성화됩니다. 결석 처벌 기간(기본값 1주). 위임자는 위임자의 투표를 자동으로 상속받습니다. validator. 이 투표는 수동으로 무시될 수 있습니다. 결합되지 않은 원자 투표하지 마세요. 각 제안서에는 MinimumProposalDeposit의 보증금이 필요합니다. tokens(하나 이상의 tokens 조합일 수 있음) 원자를 포함하여. 각 제안에 대해 유권자는 투표를 통해 다음을 선택할 수 있습니다. 보증금. 유권자의 과반수 이상이 투표를 선택하는 경우 예치금(예: 제안이 스팸이었기 때문에), 예치금은 연소된 원자를 제외한 예비 풀. 각 제안에 대해 유권자는 다음 옵션을 선택하여 투표할 수 있습니다. 응 그래위드포스 아니 아니위드포스 기권 찬성 또는 YeaWithForce 투표의 절대 다수(또는 반대 또는 NayWithForce 투표)는 제안이 다음과 같이 결정되는 데 필요합니다. 통과(또는 실패로 결정)되었지만 1/3 이상이 다수를 거부할 수 있음 "강력하게" 투표하여 결정합니다. 절대 다수가 거부권을 행사하면, 모든 사람은 VetoPenaltyFeeBlocks를 잃음으로써 처벌을 받습니다. (기본 1일 블록) 상당의 수수료(세금 제외) 영향을 받지 않음) 및 대다수를 거부한 당사자
결정은 VetoPenaltyAtoms 상실로 추가 처벌을 받게 됩니다. (기본값 0.1%) 원자의 수입니다. 여기에 정의된 모든 매개변수는 다음을 사용하여 변경할 수 있습니다. ParameterChangeProposal 을 전달합니다. 원자는 인젝션될 수 있으며 풀 자금을 다음과 같이 사용할 수 있습니다. BountyProposal 전달. 프로토콜 업그레이드 제안 등 기타 모든 제안은 일반 TextProposal을 통해 조정됩니다. 계획을 참조하십시오. blockchain 합의에는 많은 혁신이 있었고 지난 몇 년간의 확장성. 이 섹션에서는 간략한 설명을 제공합니다. 중요한 항목을 선정하여 조사합니다. 악의적 참여자 존재에 대한 합의가 문제 Leslie Lamport가 이 용어를 만들었던 1980년대 초로 거슬러 올라갑니다. "비잔틴 결함"이라는 문구는 임의의 프로세스 동작을 나타냅니다. "충돌 결함"과 달리 의도된 동작에서 벗어납니다. 여기서 프로세스는 단순히 충돌합니다. 초기 솔루션이 발견되었습니다. 상한이 있는 동기 네트워크의 경우실제 사용은 매우 제한되었지만 메시지 대기 시간 비행기 컨트롤러와 같은 통제된 환경 원자 시계를 통해 동기화되는 데이터 센터. 그때까지는 아니었지만 Practical Byzantine Fault Tolerance(PBFT) [11]이 있었던 90년대 후반 효율적인 부분 동기식 합의로 도입되었습니다. 최대 1/3의 프로세스 동작을 허용할 수 있는 알고리즘 임의로. PBFT은 표준 알고리즘이 되어 많은 알고리즘을 생성했습니다. 가장 최근에 IBM이 다음의 일부로 만든 변형을 포함한 변형 Hyperledger에 대한 기여. PBFT에 대한 Tendermint 합의의 주요 이점은 다음과 같습니다. Tendermint는 개선되고 단순화된 기본 구조를 가지고 있습니다. 그 중 일부는 blockchain 패러다임을 수용한 결과입니다. Tendermint 블록은 순서대로 커밋해야 합니다. PBFT과 관련된 복잡성 및 통신 오버헤드 보기 변경. Cosmos 및 많은 암호화폐에는 블록 N이 커밋될 때 i >= 1인 블록 N+i를 허용해야 합니다. 자체는 아직 커밋되지 않았습니다. 대역폭이 N을 차단하는 이유라면 Cosmos 영역에 커밋하지 않았다면 사용하는 데 도움이 되지 않습니다. N+i 블록에 대한 대역폭 공유 투표. 네트워크 파티션 또는 ofzine 노드는 블록 N이 커밋되지 않은 이유입니다. N+i는 어쨌든 커밋하지 않습니다. 또한 트랜잭션을 블록으로 일괄 처리하면 다음과 같은 이점이 있습니다. 대신 애플리케이션 상태의 일반 Merkle-hashing PBFT의 체크포인트 체계와 마찬가지로 주기적 다이제스트. 이를 통해 라이트 클라이언트를 위한 보다 빠른 증명 가능한 트랜잭션 커밋을 위해 inter-blockchain 통신. Tendermint Core에는 다양한 최적화 및 기능도 포함되어 있습니다. PBFT에 명시된 것 이상입니다. 예를 들어, validators가 제안한 블록은 Merkle화되어 여러 부분으로 분할됩니다. 방송을 개선하는 방식으로 험담을 했습니다. 성능(영감을 얻으려면 LibSwift [19] 참조). 또한 텐더민트는 Core는 Point-to-Point에 대해 어떠한 가정도 하지 않습니다.
P2P 네트워크가 있는 한 연결 및 기능은 약하게 연결되어 있습니다. proof-of-stake(PoS)을 배포한 최초는 아니지만 BitShares1.0 [12] PoS 연구 및 채택에 크게 기여 blockchain, 특히 "위임된" PoS로 알려진 것입니다. 에서 BitShares, 지분 보유자는 주문을 담당하는 "증인"을 선출합니다. 거래를 커밋하고 "대리인"이 책임을 집니다. 소프트웨어 업데이트 및 매개변수 변경 조정. BitShares2.0은 고성능(100k tx/s, 1s) 달성을 목표로 합니다. 대기 시간) 이상적인 조건에서 각 블록은 단일 서명으로 서명됩니다. 서명자 및 트랜잭션 연속성은 서명자보다 꽤 오래 걸립니다. 블록 간격. 정식 사양은 아직 개발 중입니다. 이해관계자는 잘못된 행동을 하는 증인을 제거하거나 교체할 수 있습니다. 매일매일, 그러나 증인이나 중요한 담보가 없습니다. Tendermint PoS와 유사한 위임자가 삭제됩니다. 이중지불 공격이 성공한 경우. Ripple이 개척한 접근 방식을 기반으로 Stellar [13]은 프로세스가 진행되는 Federated Byzantine Agreement 모델 합의에 참여하는 것은 yxed 및 전 세계적으로 구성되지 않습니다. 알려진 세트. 오히려 각 프로세스 노드는 하나 이상의 "쿼럼 슬라이스"는 각각 신뢰할 수 있는 프로세스 집합을 구성합니다. 에이 Stellar의 "쿼럼"은 다음을 포함하는 노드 집합으로 정의되었습니다. 집합의 각 노드에 대해 최소 하나의 쿼럼 슬라이스 합의가 이루어질 수 있습니다. Stellar 메커니즘의 보안은 다음 가정에 의존합니다. 두 정원회의 교차점은 비어 있지 않은 반면, 노드를 사용하려면 최소한 하나의 쿼럼 슬라이스가 필요합니다. 완전히 올바른 노드로 구성되어 균형을 맞추기 어려울 수 있는 크거나 작은 쿼럼 슬라이스 사용 신뢰에 대해 중요한 가정을 부과하지 않고. 궁극적으로,노드는 어떻게든 적절한 쿼럼 슬라이스를 선택해야 합니다. 충분한 내결함성(또는 "온전한 노드")이 있어야 합니다. 논문 결과의 대부분은)에 달려 있으며, 유일한 이러한 구성이 계층적으로 이루어지도록 하기 위한 전략 제공 인터넷의 최상위 ISP가 글로벌 라우팅 테이블을 구축하는 데 사용하는 BGP(Border Gateway Protocol)와 유사합니다. TLS 인증서를 관리하기 위해 브라우저에서 사용하는 것입니다. 둘 다 악명 높은 그들의 불안 때문에. Tendermint 기반 지분 증명 시스템에 대한 Stellar 논문의 비판은 설명된 token 전략에 의해 완화됩니다. 여기에서 원자라고 불리는 새로운 유형의 token이 발행됩니다. 수수료 및 보상의 미래 부분에 대한 청구를 나타냅니다. 는 그렇다면 Tendermint 기반 proof-of-stake의 장점은 상대적입니다. 단순하면서도 충분하고 입증 가능한 보안을 제공합니다. 보증. BitcoinNG는 Bitcoin에 대해 제안된 개선 사항입니다. 블록 크기 증가와 같은 수직 확장성의 형태에 대해 일반적으로 관련된 부정적인 경제적 결과 없이 불균형적으로 큰 영향과 같은 변화로 인해 소규모 광부에서. 이러한 개선은 분리를 통해 달성됩니다. 거래 방송에서 리더 선출: 리더가 첫 번째입니다. "마이크로 블록"에서 proof-of-work에 의해 선출되었으며 다음을 수행할 수 있습니다. 새로운 마이크로 블록이 나올 때까지 커밋되는 브로드캐스트 트랜잭션 발견되었습니다. 이렇게 하면 필요한 대역폭 요구 사항이 줄어듭니다. PoW 경주에서 승리하여 소규모 채굴자들이 더욱 공정하게 경쟁할 수 있도록 하고, 그리고 트랜잭션이 보다 정기적으로 커밋되도록 허용합니다. 마이크로 블록을 발견하는 마지막 광부. 캐스퍼 [16]는 제안된 proof-of-stake 합의 알고리즘입니다. Ethereum. 주요 작동 모드는 "베팅별 합의"입니다. 작성자: validators가 자신이 믿는 블록에 반복적으로 베팅하도록 합니다.
다른 베팅을 바탕으로 blockchain에 전념하게 됩니다. 지금까지 보아온 것처럼 결국에는 동질성이 달성될 수 있습니다. 링크. 이는 Casper 팀이 활발히 연구하고 있는 분야입니다. 는 도전 과제는 다음과 같은 베팅 메커니즘을 구축하는 것입니다. 진화적으로 안정적인 전략임이 입증되었습니다. 주요 혜택 Tendermint와 비교하여 Casper는 "가용성"을 제공할 수 있습니다. 과도한 일관성” – 합의에는 >⅔ 정족수가 필요하지 않습니다. 투표권 – 아마도 커밋 속도를 희생하거나 구현 복잡성. Interledger 프로토콜 [14]은 엄밀히 말하면 확장성 솔루션이 아닙니다. 그것 서로 다른 원장 간의 임시 상호 운용성을 제공합니다. 느슨하게 결합된 양자 관계 네트워크를 통해 시스템을 구축합니다. 라이트닝 네트워크와 마찬가지로 ILP의 목적은 다음과 같습니다. 하지만 특히 서로 다른 결제에 초점을 맞추고 있습니다. 원장 유형을 지정하고 원자 트랜잭션 메커니즘을 다음으로 확장합니다. hash-잠금뿐만 아니라 공증인 정족수(라고 함)도 포함합니다. 원자 전송 프로토콜). 후자의 메커니즘은 원장 간 거래에서 원자성을 적용하는 것은 다음과 유사합니다. Tendermint의 라이트 클라이언트 SPV 메커니즘 ILP와 Cosmos/IBC 간의 구별이 보장됩니다. 아래에 제공됩니다. 1. ILP 커넥터의 공증인은 멤버십을 지원하지 않습니다. 변경하고 사이에 zexible 가중치를 허용하지 않습니다. 공증인. 반면에 IBC은(는) 특별히 다음을 위해 설계되었습니다. blockchains(여기서 validators는 서로 다른 가중치를 가질 수 있음) 회원 자격은 기간 중에 변경될 수 있습니다. blockchain. 2. 라이트닝 네트워크와 마찬가지로 ILP의 결제 수신자는 보낸 사람에게 확인 메시지를 다시 보내려면 온라인 상태여야 합니다. 에서token은 수신기의 validator 세트인 IBC을 통해 전송됩니다. blockchain은(는) 확인 제공을 담당합니다. 받는 사용자. 3. 가장 눈에 띄는 차이점은 ILP의 커넥터가 그렇지 않다는 것입니다. 지불에 대해 책임을 지거나 권위 있는 상태를 유지하는 것, Cosmos에서는 허브의 validator이 다음의 권한입니다. IBC token의 상태 및 이전 권한 각 구역이 보유한 token의 양(그러나 tokens는 영역 내의 각 계정이 보유합니다). 이것은 안전한 비대칭을 가능하게 하는 근본적인 혁신 token을 영역에서 영역으로 전송합니다. ILP와 유사 Cosmos의 커넥터는 지속적이고 최대한 안전합니다. blockchain 원장, Cosmos 허브. 4. ILP의 원장 간 지불은 다음의 지원을 받아야 합니다. 교환 주문서는 비대칭 전송이 없기 때문에 하나의 원장에서 다른 원장으로의 동전, 가치 이전 또는 시장 등가물. 사이드체인 [15]은 Bitcoin 확장을 위해 제안된 메커니즘입니다. "양방향 고정"된 대체 blockchain을 통한 네트워크 Bitcoin blockchain. (양방향 페깅은 다음과 같습니다. 브리징. Cosmos에서는 마켓페깅과 구별하기 위해 "브리징"이라고 말합니다. 사이드체인을 사용하면 비트코인이 사이드체인에서 효과적으로 이동할 수 있습니다. Bitcoin blockchain을 사이드체인과 후면에 연결하고 다음을 허용합니다. 사이드체인의 새로운 기능을 실험합니다. 에서와 같이 Cosmos 허브, 사이드체인 및 Bitcoin은 라이트 클라이언트 역할을 합니다. SPV 증명을 사용하여 코인이 언제 발행되어야 하는지 결정합니다. 사이드체인으로 옮겨졌다가 다시 돌아왔습니다. 물론, Bitcoin 이후로 proof-of-work을 사용하고, Bitcoin을 중심으로 한 사이드체인이 어려움을 겪습니다. proof-of-work의 많은 문제와 위험으로부터 합의 메커니즘. 게다가 이것은 Bitcoin-극대주의자입니다. 다양한 token을 기본적으로 지원하지 않는 솔루션 및
Cosmos과 같은 영역 간 네트워크 토폴로지입니다. 즉 핵심은 양방향 페그의 메커니즘은 원칙적으로 다음과 동일합니다. Cosmos 네트워크에 고용되어 있습니다. Ethereum은 현재 다양한 전략을 연구하고 있습니다. Ethereum blockchain의 상태를 샤딩하여 주소를 지정합니다. 확장성이 필요합니다. 이러한 노력은 현재 Ethereum 가상 머신이 제공하는 추상화 계층 공유 상태 공간 전반에 걸쳐. 다양한 연구 노력은 현재 진행 중입니다. [18][22] Cosmos 및 Ethereum 2.0 Mauve [22]은 디자인 목표가 다릅니다. Cosmos은(는) 특히 token에 관한 것입니다. Mauve는 스케일링에 관한 것입니다. 일반 계산. Cosmos은 EVM에 바인딩되지 않으므로 다른 VM도 가능합니다. 상호 운용. Cosmos을 통해 영역 작성자가 누가 검증하는지 결정할 수 있습니다. 구역. 누구나 Cosmos에서 새 영역을 시작할 수 있습니다(거버넌스가 아닌 경우). 달리 결정합니다). 허브는 영역 오류를 격리하므로 전역 token 불변성은 보존. 라이트닝 네트워크는 제안된 token 전송 네트워크입니다. Bitcoin blockchain(및 기타 공개) 위의 레이어에서 작동 blockchains), 수십 배의 개선이 가능합니다. 대부분의 트랜잭션을 이동하여 트랜잭션 처리량 향상 합의 원장 외부에서 소위 "결제 채널"로 전환됩니다.이는 온체인 암호화폐 스크립트를 통해 가능해졌습니다. 당사자들이 양자 간 국가 계약을 체결할 수 있도록 합니다. 디지털 서명 및 계약을 공유하여 상태를 업데이트할 수 있습니다. blockchain에 증거를 최종적으로 게시하여 종료할 수 있습니다. 메커니즘은 크로스체인 원자 교환을 통해 처음으로 대중화되었습니다. 작성자: 많은 당사자들과 결제 채널을 개설하고, 라이트닝 네트워크는 라우팅의 중심이 될 수 있습니다. 완전히 연결된 결제 채널로 이어지는 타인의 결제 지불 채널에 자본이 묶여 있는 대가를 치르게 됩니다. 라이트닝 네트워크는 여러 곳으로 쉽게 확장될 수도 있습니다. 가치 이전을 허용하는 여러 개의 독립적인 blockchain 교환시장을 통해서는 비대칭적으로 사용될 수 없습니다. token을 하나의 blockchain에서 다른 blockchain로 전송합니다. 메인 베니트 여기에 설명된 Cosmos 네트워크의 기능은 이러한 직접적 사용을 가능하게 하는 것입니다. token 전송. 즉, 우리는 지불 채널과 라이트닝 네트워크는 우리와 함께 널리 채택될 것입니다. token 비용 절감 및 개인 정보 보호를 위한 전송 메커니즘. 분리된 증인은 Bitcoin 개선 제안 링크입니다. 블록당 트랜잭션 처리량을 2배 또는 3배 증가시키는 것을 목표로 합니다. 동시에 새로운 노드에 대한 블록 동기화를 더 빠르게 만듭니다. 이 솔루션의 뛰어난 점은 다음과 같은 환경 내에서 작동하는 방식에 있습니다. Bitcoin의 현재 프로토콜 제한 사항 및 소프트 포크 허용 업그레이드(예: 이전 버전의 소프트웨어를 사용하는 클라이언트는 업그레이드 후에도 계속 작동합니다). 텐더민트, 새로운 존재가 되다 프로토콜에는 설계 제한이 없으므로 크기 조정이 다릅니다. 우선순위. 기본적으로 Tendermint는 BFT 라운드 로빈 알고리즘을 사용합니다. 채굴 대신 암호화 서명을 기반으로 하는 여러 병렬을 통해 수평 확장을 간단하게 허용합니다. blockchains, 정기적이고 더 빈번한 블록 커밋은 다음을 허용합니다. 수직 스케일링도 가능합니다.
ธรรมาภิบาลและเศรษฐศาสตร์
แม้ว่า 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 ในขณะที่บล็อกปกติและบ่อยกว่าอนุญาต มาตราส่วนแนวตั้งเช่นกัน
합의 및 기술적 세부사항
잘 설계된 합의 프로토콜은 다음을 제공해야 합니다. 허용 한도를 초과하는 경우 보장 그리고 합의는 실패합니다. 이는 특히 경제적인 측면에서 필요합니다. 비잔틴 행위가 상당한 재정적 이익을 가져올 수 있는 시스템 보상. 그러한 보장 중 가장 중요한 것은 합의를 야기한 프로세스가 실패(즉, 프로토콜의 클라이언트가 다른 값을 허용하게 함 - 포크)에 대한 규정에 따라 식별 및 처벌될 수 있습니다. 프로토콜 또는 법률 시스템일 수도 있습니다. 법체계가 갖춰지면 신뢰할 수 없거나 호출 비용이 지나치게 높기 때문에 validator은(는) 참가하려면 보증금을 예치해야 하며, 악의적인 행위가 있을 경우 예치금이 취소되거나 삭감될 수 있습니다. [10]이(가) 감지되었습니다. 이는 분기가 정기적으로 발생하는 Bitcoin과 다릅니다. 네트워크 비동기성과 바인딩의 확률적 특성으로 인해 부분적인 hash 충돌. 많은 경우에 악의적인 포크는 비동기성으로 인해 포크와 구별할 수 없습니다. Bitcoin은(는) 암시적인 것 외에 포크 책임을 안정적으로 구현합니다. 고아 블록을 채굴하기 위해 채굴자가 지불하는 기회 비용. 투표 단계를 PreVote 및 PreCommit이라고 합니다. 투표는 다음을 위해 할 수 있습니다 특정 블록 또는 Nil에 대한 것입니다. 우리는 >⅔ PreVotes 모음을 호출합니다. 같은 라운드의 단일 블록에 대해 폴카, >⅔ 컬렉션 동일한 라운드의 단일 블록에 대한 PreCommit은 Commit입니다. >⅔인 경우 같은 라운드에서 Nil에 대한 PreCommit은 다음 라운드로 이동합니다. 라운드. 프로토콜의 엄격한 결정론은 약한 문제를 야기한다는 점에 유의하십시오. 결함이 있는 리더로서의 동시성 가정을 감지해야 하며
건너뛰었습니다. 따라서 validators는 일정 시간 동안 기다립니다. TimeoutPropose, Nil을 Prevote하기 전, 그리고 그 가치 TimeoutPropose는 라운드마다 증가합니다. 진행을 통해 라운드의 나머지 부분은 완전히 비동기식입니다. validator이 네트워크의 ⅔ 이상에서 수신되면 생성됩니다. 실제로, 이를 완전히 좌절시키려면 극도로 강력한 적이 필요할 것입니다. 약한 동시성 가정(합의 실패 원인) 블록을 커밋하는 경우) 그렇게 하면 훨씬 더 많은 일을 할 수 있습니다. 각각에 대해 TimeoutPropose의 무작위 값을 사용하여 difycult validator. 추가 제약 조건 세트 또는 잠금 규칙은 다음을 보장합니다. 네트워크는 결국 각 높이에서 단 하나의 블록만 커밋하게 됩니다. 모두 둘 이상의 블록이 커밋되도록 하는 악의적인 시도 특정 높이에서 식별할 수 있습니다. 먼저, 블록에 대한 PreCommit 해당 블록에 대해 폴카 형태로 정당성을 제시해야 합니다. validator가 R_1 라운드에서 이미 블록을 PreCommit한 경우 그 블록에 갇혀 있다고 말했고 폴카는 그 블록을 정당화하는 데 사용되었습니다. 라운드 R_2의 새로운 PreCommit은 라운드에 와야 합니다 R_polka 여기서 R_1 < R_polka <= R_2. 둘째, validators는 제안해야 합니다. 및/또는 잠겨 있는 블록에 사전 투표를 하세요. 함께, 이들 조건은 validator이 없이 PreCommit하지 않도록 보장합니다. 정당성을 입증하는 충분한 증거와 그 validator 이미 PreCommit은 PreCommit에 대한 증거에 기여할 수 없습니다. 다른 것. 이는 보안과 활성을 모두 보장합니다. 합의 알고리즘. 프로토콜의 전체 세부 사항은 여기에 설명되어 있습니다. 대체 체인(포크)이 존재한다는 것은 ≥⅓의 블록 헤더를 의미하므로 모든 블록 헤더를 동기화할 필요가 TendermintPoS에서는 제거됩니다. 담보 스테이크는 삭감될 수 있습니다. 물론 슬래싱이 필요하기 때문에 누군가가 포크의 증거를 공유한다는 사실을 라이트 클라이언트는 저장해야 합니다. 모든 블록-hash 커밋이 표시됩니다. 또한, 라이트 클라이언트validator 세트의 변경 사항과 주기적으로 동기화를 유지할 수 있습니다. 장거리 공격을 피하기 위해(그러나 다른 솔루션은 가능). Ethereum과 유사한 정신으로 Tendermint는 애플리케이션이 다음을 수행할 수 있도록 합니다. 각 블록에 전역 Merkle 루트 hash을 삽입하여 쉽게 허용 계정 잔액, 가치 등에 대한 검증 가능한 상태 쿼리 계약에 저장되어 있거나 사용되지 않은 거래의 존재 애플리케이션의 성격에 따라 출력됩니다. 충분히 탄력적인 방송 네트워크 모음을 가정합니다. 정적 validator 세트를 사용하면 blockchain의 모든 포크는 감지되어 문제가 되는 validators의 예금이 삭감되었습니다. 이 2014년 초 Vitalik Buterin이 처음으로 제안한 혁신은 다음과 같은 문제를 해결합니다. 다른 proof-of-stake의 위험 없는 문제 암호화폐(관련 작업 참조). 그러나 validator이 설정되었으므로 원본은 장기간에 걸쳐 변경될 수 있어야 합니다. validators는 모두 결합 해제될 수 있으므로 자유롭게 사용할 수 있습니다. 제네시스 블록에서 새로운 체인을 생성하며, 비용은 발생하지 않습니다. 더 이상 예금이 잠겨 있지 않습니다. 이 공격이 나왔습니다 단거리 공격과 달리 장거리 공격(LRA)으로 알려져 있음 현재 결속된 validators가 다음을 유발하는 범위 공격 포크로 인해 처벌을 받을 수 있습니다(포크 책임이 있는 BFT 가정). Tendermint 합의와 같은 알고리즘). 장거리 공격은 종종 proof-of-stake에 심각한 타격을 입혔다고 생각됩니다. 다행히 LRA는 다음과 같이 완화할 수 있다. 첫째, validator 채권을 해제하여 담보 예금을 회수합니다. 더 이상 합의에 참여하기 위해 수수료를 받지 않습니다.) 보증금은 일정 기간 동안 양도할 수 없도록 설정되어야 합니다. "결합 해제 기간"으로 알려져 있으며, 이는 다음과 같은 순서로 나타날 수 있습니다. 몇 주 또는 몇 달. 둘째, 라이트 클라이언트의 보안을 위해서는 가장 먼저 네트워크에 연결되면 최근 블록을 확인해야 합니다-hash 신뢰할 수 있는 소스 또는 바람직하게는 여러 소스에 대해. 이
상태는 때때로 "약한 주관성"으로 지칭됩니다. 마지막으로, 보안을 유지하려면 다음에 설정된 최신 validator과 동기화해야 합니다. 적어도 언본딩 기간만큼 자주. 이 라이트 클라이언트가 validator에 대한 변경 사항을 알고 있는지 확인합니다. validator 이전에 설정된 자본금은 채권이 해제되어 더 이상 존재하지 않습니다. 위태로워서 클라이언트를 속일 수 있습니다. 뒤에서 시작하는 새로운 블록을 생성하여 장거리 공격 접착된 높이(충분히 제어할 수 있다고 가정) 많은 초기 개인 키). 이러한 방식으로 LRA를 극복하려면 proof-of-work의 원래 보안 모델. PoW에서는 라이트 클라이언트가 현재 높이와 동기화할 수 있다고 가정합니다. 모든 블록 헤더의 작업 증명을 처리하기만 하면 언제든지 신뢰할 수 있는 제네시스 블록을 생성할 수 있습니다. 그러나 LRA를 극복하기 위해 우리는 라이트 클라이언트가 정기적으로 온라인에 접속하도록 요구합니다. validator 세트의 변경 사항을 추적하고, 처음으로 온라인에 접속하면 인증에 특히 주의해야 합니다. 신뢰할 수 있는 소스에 대해 네트워크에서 듣는 내용입니다. 의 물론 이 후자의 요구 사항은 Bitcoin의 요구 사항과 유사합니다. 프로토콜과 소프트웨어도 신뢰할 수 있는 곳에서 받아야 합니다. 소스. 위의 LRA 방지 방법은 validators에 매우 적합합니다. 그리고 Tendermint 기반 blockchain의 전체 노드는 다음과 같습니다. 노드는 네트워크에 연결된 상태를 유지하도록 되어 있습니다. 는 이 방법은 다음을 기대할 수 있는 라이트 클라이언트에도 적합합니다. 네트워크와 자주 동기화하세요. 그러나 라이트 클라이언트의 경우 인터넷이나 인터넷에 자주 접속할 것으로 예상되지 않습니다. blockchain 네트워크 문제를 극복하기 위해 또 다른 솔루션을 사용할 수 있습니다. LRA. validator token 보유자가 아닌 사람은 자신의 token을 다음과 같이 게시할 수 있습니다. 해제 기간이 매우 긴 담보(예: 훨씬 더 긴 기간) validators의 언본딩 기간보다) 라이트 클라이언트에게 서비스를 제공합니다. 현재의 타당성을 증명하는 두 번째 방법으로 지난 블록-hashes. 이 token은(는) 그럼에도 불구하고 blockchain 합의의 보안은 가능합니다.라이트 클라이언트에게 강력한 보증을 제공합니다. 과거 블록-hash인 경우 쿼리는 Ethereum에서 지원되었으며 누구나 자신의 특별히 고안된 smart contract의 tokens 및 제공 유료 증명 서비스를 제공하여 라이트 클라이언트 LRA 보안 시장을 효과적으로 창출합니다. 블록 커밋의 해제로 인해 ≥⅓ 연합은 투표 권한으로 진을 떠나거나 말거나 blockchain을 중단할 수 있습니다. 그들의 투표를 방송합니다. 그러한 연합은 검열도 할 수 있습니다. 이를 포함하는 블록을 거부하여 특정 거래 거래가 발생하더라도 상당한 비율의 거래가 발생하게 됩니다. 블록 제안이 거부되어 비율이 느려질 수 있습니다. blockchain의 블록 커밋이 줄어들어 유틸리티와 가치가 감소합니다. 악의적 연합은 투표를 조금씩 방송할 수도 있으므로 blockchain 블록을 갈아서 거의 정지하거나 이러한 공격의 조합. 마지막으로 다음과 같은 원인이 될 수 있습니다. blockchain 이중 서명 또는 잠금 위반으로 포크 규칙. 전 세계적으로 활동하는 적도 연루된 경우 분할될 수 있습니다. 잘못된 것처럼 보일 수 있는 방식으로 네트워크를 validator의 하위 집합이 속도 저하의 원인이었습니다. 이것은 아니다 Tendermint의 한계일 뿐 아니라 오히려 모든 것의 한계입니다. 네트워크가 잠재적으로 통제되는 합의 프로토콜 적극적인 적. 이러한 유형의 공격에 대해서는 validator의 하위 집합이 필요합니다. 외부 수단을 통해 조정하여 재구성 제안에 서명합니다. 포크(및 그 증거)와 초기 하위 집합을 선택합니다. validator의 서명이 포함되어 있습니다. 이러한 조직 개편 제안에 서명한 검증자는 다른 모든 포크에 대한 담보를 포기합니다. 클라이언트는 해야 합니다 재구성 제안의 서명을 확인하고, 증거를 확인하고, 판단을 내리거나 최종 사용자에게 결정을 촉구합니다. 에 대한 예를 들어 휴대폰 지갑 앱은 사용자에게 보안 메시지를 표시할 수 있습니다.
경고하는 반면 냉장고는 재구성 제안을 받아들일 수 있습니다. 투표권을 통해 원본 validator의 +½이 서명했습니다. 비동기식 비잔틴 결함 허용 알고리즘은 제공될 수 없습니다. 투표권의 ⅓ 이상이 부정직할 때 합의를 이루지만 포크는 투표권의 ⅓ 이상이 이미 부정직하다고 가정합니다. 정당화 없이 이중 서명 또는 잠금 변경. 그래서 서명을 재구성 제안은 조정할 수 없는 조정 문제입니다. 비동기 프로토콜로 해결됩니다(즉, 자동으로 신뢰성에 대한 가정을 하지 않고 기본 네트워크). 지금은 조직개편 조정 문제를 사회적 합의를 통한 인간의 조정에 맡겨둔다. 인터넷 매체에서. 검증인은 다음 사항을 보장하기 위해 주의를 기울여야 합니다. 두 개의 복잡한 재구성 제안이 서명되는 상황을 피하기 위해 재구성 제안에 서명하기 전에 남은 네트워크 파티션이 없습니다. 외부 조정 매체와 프로토콜이 다음과 같다고 가정합니다. 강력하기 때문에 포크는 검열보다 덜 문제가 됩니다. 공격. ≥⅓ 비잔틴이 필요한 포크 및 검열 외에도 투표권이 있는 경우, ⅔ 이상의 투표권을 가진 연합이 약속할 수 있습니다. 임의적이고 잘못된 상태입니다. 이것은 (BFT)의 특징입니다. 합의 시스템. 포크를 생성하는 이중 서명과 달리 쉽게 검증할 수 있는 증거를 통해 범죄 행위를 탐지합니다. 유효하지 않은 상태에서는 유효성을 검사하지 않는 피어가 전체 블록을 확인해야 합니다. 이는 상태의 로컬 복사본을 유지하고 실행한다는 것을 의미합니다. 각 트랜잭션에 대해 독립적으로 상태 루트를 계산합니다. 스스로. 일단 감지되면 이러한 오류를 처리할 수 있는 유일한 방법 사회적 합의를 통해서다. 예를 들어, Bitcoin 상황에서 소프트웨어 버그로 인한 분기 여부에 관계없이 실패했습니다(3월과 마찬가지로). 2013) 또는 비잔틴 동작으로 인해 잘못된 상태를 범하는 경우 광부(2015년 7월 기준), 잘 연결된 커뮤니티 기업, 개발자, 광부 및 기타 조직 수동 조치가 무엇인지에 대한 사회적 합의를 확립했습니다.참가자가 네트워크를 치유하는 데 필요합니다. 게다가 이후 Tendermint blockchain의 validator는 다음과 같을 것으로 예상됩니다. 식별 가능하고 유효하지 않은 상태에 대한 약속은 심지어 원하는 경우 법률이나 일부 외부 법률에 의해 처벌될 수 있습니다. ABCI은(는) 전달되는 3가지 기본 메시지 유형으로 구성됩니다. 애플리케이션의 핵심. 애플리케이션은 다음과 같이 응답합니다. 해당 응답 메시지. AppendTx 메시지는 애플리케이션의 작업 도구입니다. 각각 blockchain의 거래가 이 메시지와 함께 전달됩니다. 는 애플리케이션은 수신된 각 트랜잭션을 검증해야 합니다. 현재 상태, 애플리케이션 프로토콜에 대한 AppendTx 메시지, 그리고 거래의 암호화 자격 증명. 검증된 그런 다음 트랜잭션은 애플리케이션 상태를 업데이트해야 합니다. 값을 키 값 저장소에 바인딩하거나 UTXO를 업데이트하여 데이터베이스. CheckTx 메시지는 AppendTx와 유사하지만 거래 검증. Tendermint Core의 mempool 첫 번째 확인 CheckTx와의 거래 유효성, 릴레이만 유효함 동료와의 거래. 응용 프로그램은 증분을 확인할 수 있습니다 nonce를 사용하고 CheckTx 시 오류를 반환합니다. nonce은 오래되었습니다. Commit 메시지는 암호화를 계산하는 데 사용됩니다. 현재 애플리케이션 상태에 대한 약속을 다음 블록 헤더. 여기에는 몇 가지 편리한 속성이 있습니다. 해당 상태 업데이트의 불일치는 이제 다음과 같이 나타납니다. blockchain 프로그래밍의 전체 클래스를 포착하는 포크 오류. 이는 또한 보안 경량의 개발을 단순화합니다. 클라이언트는 Merkle-hash 증거를 확인하여 확인할 수 있습니다. 블록-hash 및 블록-hash은 쿼럼에 의해 서명됩니다. validators (투표권에 따라).
추가 ABCI 메시지를 통해 애플리케이션은 validator 세트를 변경하고 애플리케이션이 높이 및 커밋 투표와 같은 블록 정보. ABCI 요청/응답은 간단한 Protobuf 메시지입니다. 확인 스키마 yle 밖으로. 인수: Data ([]byte) : 요청 트랜잭션 바이트 반품: 코드(uint32): 응답 코드 Data ([]byte) : 결과 바이트(있는 경우) 로그(문자열): 디버그 또는 오류 메시지 사용법:
트랜잭션을 추가하고 실행합니다. 거래가 유효한 경우, CodeType.OK를 반환합니다. 인수: Data ([]byte) : 요청 트랜잭션 바이트 반품: 코드(uint32): 응답 코드 Data ([]byte) : 결과 바이트(있는 경우) 로그(문자열): 디버그 또는 오류 메시지 사용법:
거래를 검증합니다. 이 메시지는 상태. 거래는 이전에 CheckTx를 통해 처음으로 실행됩니다. mempool 계층의 피어에게 브로드캐스팅됩니다. 당신은 만들 수 있습니다 CheckTx 반상태 저장 및 커밋 시 상태 지우기 또는 BeginBlock - 트랜잭션의 종속 시퀀스를 허용합니다. 같은 블록에 있어요.
반품: 데이터([]바이트): 머클 루트 hash 로그(문자열): 디버그 또는 오류 메시지 사용법:
애플리케이션 상태의 머클 루트 hash을 반환합니다. 인수: Data ([]byte) : 쿼리 요청 바이트 반품: 코드(uint32): 응답 코드 Data ([]byte) : 쿼리 응답 바이트 로그(문자열): 디버그 또는 오류 메시지 사용법:
응답 큐를 플러시합니다. 구현하는 애플리케이션 유형. 애플리케이션은 이 메시지를 구현할 필요가 없습니다. 프로젝트에 의해 처리됩니다. 반품: Data ([]byte) : 정보 바이트 사용법:
애플리케이션 상태에 대한 정보를 반환합니다. 신청 특정. 인수: Key (string) : 설정할 키
Value (string) : 키에 설정할 값 반품: 로그(문자열): 디버그 또는 오류 메시지 사용법:
애플리케이션 옵션을 설정합니다. 예: 키=“모드”, 값=“mempool” mempool 연결 또는 Key=“mode”, Value=“consensus” 합의된 연결. 다른 옵션은 애플리케이션에 따라 다릅니다. 인수: 유효성 검사기([]Validator): 초기 생성-validators 사용법:
창세기에 한 번 호출됨 인수: 높이(uint64): 시작되는 블록 높이 사용법:
새로운 블록의 시작을 알립니다. 어떤 일이 일어나기 전에 호출됨 AppendTxs. 인수: 높이(uint64): 끝난 블록 높이 반품: 유효성 검사기([]Validator): validator을 새로 변경했습니다. 투표권(제거하려면 0) 사용법:
블록의 끝을 신호합니다. 결국 각 커밋 전에 호출됩니다. 거래 자세한 내용은 ABCI 저장소를 참조하세요.발신자가 원하는 데에는 여러 가지 이유가 있습니다. 수신 체인에 의한 패킷 전달에 대한 승인. 예를 들어, 보낸 사람이 상태를 알 수 없습니다. 대상 체인에 결함이 있을 것으로 예상되는 경우. 아니면 발신인이 패킷에 시간 초과를 적용하려고 합니다(MaxHeight 사용). 패킷 소리), 대상 체인은 들어오는 숫자의 갑작스러운 급증으로 인해 서비스 거부 공격을 받을 수 있습니다. 패킷. 이 경우 발송인은 배달 확인을 요구할 수 있습니다. 초기 패킷 상태를 AckPending으로 설정합니다. 그렇다면 그것은 다음을 포함하여 체인의 배송 확인 책임을 받습니다. Merkle hash 앱에서는 IBCPacket으로 축약되었습니다. 먼저 IBCBlockCommit 및 IBCPacketTx가 '허브'에 게시됩니다. 이는 'Zone1'에 IBCPacket이 존재함을 증명합니다. 그렇게 말해보세요 IBCPacketTx의 값은 다음과 같습니다. FromChainID : “Zone1” FromBlockHeight : 100 (예:) 패킷: IBC패킷:
헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 (말) 상태 : 승인 보류 중 종류 : “코인” MaxHeight : 350 (예: "허브"의 높이는 현재 300입니다) 페이로드 : <“코인” 페이로드의 바이트 수> 다음으로 IBCBlockCommit 및 IBCPacketTx가 'Zone2'에 게시됩니다. 이는 '허브'에 IBC패킷이 존재함을 증명합니다. 그렇게 말해보세요 IBCPacketTx의 값은 다음과 같습니다. FromChainID : “허브” FromBlockHeight : 300 패킷: IBC패킷: 헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 상태 : 승인 보류 중 종류 : “코인” 최대 높이 : 350 페이로드 : <“코인” 페이로드의 동일한 바이트> 다음으로, “Zone2”는 앱-hash에 축약된 패킷을 포함해야 합니다. AckSent의 새로운 상태를 보여줍니다. IBCBlockCommit 및 IBCPacketTx는 존재를 증명하는 'Hub'에 다시 게시됩니다. 'Zone2'의 축약된 IBC패킷입니다. IBCPacketTx라고 말하세요 다음과 같은 값을 갖습니다: FromChainID : “Zone2”
FromBlockHeight : 400 (예:) 패킷: IBC패킷: 헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 상태 : 승인 전송됨 종류 : “코인” 최대 높이 : 350 PayloadHash : <동일한 "코인" 페이로드의 hash 바이트> 마지막으로 "허브"는 패킷의 상태를 업데이트해야 합니다. AckReceived에 대한 AckPending입니다. 이 새로운 분석 상태에 대한 증거 "Zone2"로 돌아가야 합니다. IBCPacketTx에 다음이 있다고 가정해 보세요. 값: FromChainID : “허브” FromBlockHeight : 301 패킷: IBC패킷: 헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 상태 : 수신확인 종류 : “코인” 최대 높이 : 350 PayloadHash : <동일한 "코인" 페이로드의 hash 바이트> 한편, “Zone1”은 성공적인 배송을 낙관적으로 가정할 수 있습니다. 반대 증거가 입증되지 않는 한 "동전" 패킷 "허브". 위 예에서 'Hub'가 AckSent를 받지 못한 경우
블록 350으로 "Zone2"의 상태를 설정했다면 상태가 설정되었을 것입니다. 자동으로 시간 초과가 발생합니다. 시간 초과에 대한 이 증거는 다음과 같습니다. "Zone1"에 다시 게시되며 모든 token이 반환될 수 있습니다. Merkle tree에는 두 가지 유형이 지원됩니다. Tendermint/Cosmos 생태계: 단순 트리 및 IAVL+ 나무. 단순 트리는 요소의 정적 목록에 대한 Merkle tree입니다. 만약 항목 수는 2의 거듭제곱이 아니며 일부 리프는 다른 수준. Simple Tree는 트리의 양쪽 측면을 유지하려고 시도합니다. 높이는 같지만 왼쪽이 하나 더 클 수 있습니다. 이 Merkle tree은(는) 블록의 거래를 Merkle화하는 데 사용되며 최상위 수준 애플리케이션 상태 루트의 요소.IAVL+ 데이터 구조의 목적은 지속적인 정보를 제공하는 것입니다. 애플리케이션 상태의 키-값 쌍에 대한 저장 결정론적 머클 루트 hash은 효율적으로 계산될 수 있습니다. 는 트리는 AVL 알고리즘의 변형을 사용하여 균형을 이루고 있으며 모든 연산은 O(log(n))입니다. AVL 트리에서 모든 노드의 두 하위 하위 트리의 높이는 최대 1개만 다릅니다. 이 조건을 위반할 때마다 업데이트하면 트리는 O(log(n))개의 새 노드를 생성하여 재조정됩니다. 오래된 트리의 수정되지 않은 노드를 가리킵니다. 원래 AVL에서는 알고리즘에서는 내부 노드도 키-값 쌍을 보유할 수 있습니다. AVL+ 알고리즘(+ 참고) AVL 알고리즘을 수정하여 모든 항목을 유지합니다. 리프 노드에 값을 저장하고 분기 노드만 사용하여 키를 저장합니다. 이는 머클 hash 트레일을 유지하면서 알고리즘을 단순화합니다. 짧다. AVL+ 트리는 Ethereum의 Patricia 시도와 유사합니다. 있다 절충. 키를 삽입하기 전에 hash할 필요는 없습니다. IAVL+ 트리 - 키에서 더 빠른 순서의 반복을 제공합니다. 일부 응용 프로그램에 도움이 될 수 있는 공간입니다. 논리는 더 간단하다 내부 노드와 두 가지 유형의 노드만 필요합니다. 잎 노드. 머클 증명은 평균적으로 더 짧습니다. * / \ / \ / \ / \ * * / \ / \ / \ / \ / \ / \ * * * h6 / \ / \ / \ h0 h1 h2 h3 h4 h5 7개 요소로 구성된 SimpleTree
균형 잡힌 이진 트리. 반면에 Merkle 루트는 IAVL+ 트리는 업데이트 순서에 따라 달라집니다. 우리는 다음과 같은 효율적인 Merkle tree을 추가로 지원할 것입니다. 바이너리 변형이 다음과 같은 경우 Ethereum의 Patricia Trie 가능합니다. 표준 구현에서 트랜잭션은 다음으로 스트리밍됩니다. Cosmos ABCI 인터페이스를 통한 허브 애플리케이션. Cosmos 허브는 다수의 기본 거래를 허용합니다. SendTx, BondTx, UnbondTx, ReportHackTx 등의 유형을 포함합니다. SlashTx, BurnAtomTx, ProposalCreateTx 및 ProposalVoteTx, 이는 상당히 자명하며 다음 문서에 문서화됩니다. 이 문서의 향후 개정판. 여기서 우리는 두 가지 기본 사항을 문서화합니다. IBC의 트랜잭션 유형: IBCBlockCommitTx 및 IBCPacketTx. IBCBlockCommitTx 트랜잭션은 다음으로 구성됩니다. ChainID(문자열): blockchain의 ID BlockHash ([]byte): 블록-hash 바이트, Merkle 루트 여기에는 앱-hash이 포함되어 있습니다. BlockPartsHeader(PartSetHeader): 블록 부분 집합 헤더 바이트, 투표 서명을 확인하는 데만 필요함 BlockHeight(int): 커밋 높이 BlockRound(int): 커밋 라운드 Commit ([]Vote) : >⅔ Tendermint Precommit 투표는 블록 커밋으로 구성 ValidatorsHash ([]byte): 새 항목의 머클 트리 루트 hash validator 세트
ValidatorsHashProof(SimpleProof): BlockHash에 대해 ValidatorsHash를 증명하기 위한 SimpleTree Merkleproof
AppHash([]바이트): IAVLTree Merkle-tree 루트 hash
애플리케이션 상태
AppHashProof(SimpleProof): SimpleTree 머클 증명
BlockHash에 대해 AppHash 증명
IBC패킷은 다음으로 구성됩니다.
헤더(IBCPacketHeader): 패킷 헤더
페이로드([]byte): 패킷 페이로드의 바이트입니다. 선택사항
PayloadHash ([]byte) : 패킷 바이트에 대한 hash입니다.
선택사항
Payload 또는 PayloadHash 중 하나가 있어야 합니다. hash
IBCPacket의 는 두 항목 헤더의 간단한 Merkle 루트입니다.
및 페이로드. 전체 페이로드가 없는 IBC패킷을
약칭패킷.
IBCPacketHeader는 다음으로 구성됩니다.
SrcChainID(문자열): 소스 blockchain ID
DstChainID (문자열) : 대상 blockchain ID
Number(int): 모든 패킷의 고유 번호
상태(열거형): AckPending , AckSent 중 하나일 수 있습니다.
AckReceived, NoAck 또는 시간 초과
유형(문자열): 유형은 애플리케이션에 따라 다릅니다. Cosmos
"코인" 패킷 유형을 예약합니다.
MaxHeight(int): 상태가 NoAckWanted 또는 AckReceived가 아닌 경우
이 높이만큼 상태는 Timeout 이 됩니다. 선택사항
IBCPacketTx 트랜잭션은 다음으로 구성됩니다.FromChainID(문자열): blockchain의 ID입니다.
이 패킷을 제공하고; 꼭 출처는 아니어도
FromBlockHeight(int): blockchain 높이입니다.
다음 패킷은 블록-hash에 포함됩니다(머클화).
소스 체인
패킷(IBCPacket): 상태가 1일 수 있는 데이터 패킷입니다.
AckPending , AckSent , AckReceived , NoAck 또는 Timeout
PacketProof(IAVLProof): 증명을 위한 IAVLTree Merkle 증명
소스 체인의 AppHash에 대한 패킷의 hash
주어진 높이
“Zone1”에서 “Zone2”로 패킷을 보내는 순서
"허브"를 통한 방법은 {그림 X}에 나와 있습니다. 먼저, IBCPacketTx
패킷이 앱 상태에 포함되어 있음을 "허브"에 증명합니다.
“구역 1”. 그런 다음 또 다른 IBCPacketTx는 'Zone2'에 대해
패킷은 "허브"의 앱 상태에 포함됩니다. 이 동안
절차에서 IBCPacket 필드는 동일합니다. SrcChainID는 다음과 같습니다.
항상 "Zone1"이고, DstChainID는 항상 "Zone2"입니다.
PacketProof에는 다음과 같이 올바른 Merkle 방지 경로가 있어야 합니다.
다음과 같습니다:
“Zone1”이 “Hub”를 통해 “Zone2”로 패킷을 보내려고 할 때,
IBCPacket 데이터는 패킷이 "Zone1", "Hub" 또는 "Zone2"에서 Merkleized되었는지 여부와 동일합니다. 유일하게 변경 가능한 Yeld는 다음과 같습니다.
배송 추적 상태입니다.
개념화에 도움을 주신 친구와 동료들에게 감사드립니다.
Tendermint와의 작업을 검토하고 지원합니다.
그리고 Cosmos.
IBC/
SkuChain의 Zaki Manian은 형식 지정 및 작업에 많은 도움을 주었습니다. 특히 ABCI 섹션 아래의 문구 Althea의 Jehan Tremback과 Dustin Byington이 도움을 주었습니다. 초기 반복 합의에 대한 피드백을 주신 Honey Badger의 Andrew Miller 합의와 표현에 대한 피드백을 주신 Greg Slepak 또한 다양한 활동을 해주신 Bill Gleim과 한승환에게도 감사드립니다. 기여. 귀하의 기여를 위해 여기에 귀하의 이름과 조직이 표시됩니다. 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 제로캐시: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4 DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 분리된 증인: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 라이트닝 네트워크: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 텐더민트: https://github.com/tendermint/tendermint/wiki 9 FLP 불가능: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 슬래셔: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 비트셰어: https://bitshares.org/technology/delegatedproof-of-stake-consensus/
13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 중개인: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15개의 사이드체인: https://blockstream.com/sidechains.pdf 16 캐스퍼: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum 샤딩: https://github.com/ethereum/EIPs/issues/53 19 LibSwift: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalyticOfLibswift.pdf 20DLS: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 씬 클라이언트 보안: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 연보라색 종이: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html
¼ è
ฉันทามติและรายละเอียดทางเทคนิค
ระเบียบวิธีฉันทามติที่ออกแบบมาอย่างดีควรจัดเตรียมไว้บ้าง รับประกันในกรณีที่เกินขีดความสามารถที่ยอมรับได้ และฉันทามติล้มเหลว นี่เป็นสิ่งจำเป็นอย่างยิ่งในด้านเศรษฐกิจ ระบบซึ่งพฤติกรรมไบเซนไทน์สามารถมีการเงินจำนวนมากได้ รางวัล การรับประกันที่สำคัญที่สุดคือรูปแบบของ 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
¨ อี