백서 스토리 그림 용어집 그래프 검색

Cosmos：分布式账本网络

저자 Jae Kwon and Ethan Buchman · 2016

단일 보기 v1.cosmos.network
🇺🇸 English (원문)
🇨🇳 中文简体 (번역)

소개

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

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

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

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

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

介绍

开源生态系统的共同成功， 去中心化的yle共享，公共加密货币已经 激发了人们对去中心化互联网协议的理解 可用于从根本上改善社会经济基础设施。 我们已经看到了专门的 blockchain 应用程序，例如 Bitcoin [1] （ 加密货币）、Zerocash [2]（一种保护隐私的加密货币）以及 通用 smart contract 平台，例如 Ethereum [3]， 以太坊虚拟的无数分布式应用程序 机器（EVM），例如 Augur（预测市场）和 TheDAO [4]（投资俱乐部）。 然而，迄今为止，这些 blockchain 已经遭受了许多问题的困扰。 的缺点，包括其总体能源效率低下、贫穷或 绩效有限，治理机制不成熟。 扩大 Bitcoin 交易吞吐量的建议，例如 隔离见证 [5] 和 BitcoinNG [6]，是垂直缩放 解决方案仍然受到单个物理容量的限制 机，以保证性能的完全可审核性。 闪电网络 [7] 可以帮助扩展 Bitcoin 交易

通过将一些交易完全从分类账中删除来增加交易量， 非常适合小额支付和隐私保护 支付轨道，但可能不适合更普遍的情况 扩展需求。 理想的解决方案是允许多个并行 blockchain 互操作，同时保留其安全属性。这有 事实证明，对于 proof-of-work 来说，即使不是不可能，也是很困难的。合并 例如，采矿可以确保父母的安全 链可以在子链上重用，但交易仍然必须 按顺序由每个节点进行验证，并合并挖掘 blockchain 如果 hashing 上的大部分功率都容易受到攻击 父级没有积极地对子级进行合并挖掘。学术评论 提供了替代的 blockchain 网络架构 其他背景，我们提供其他提案的摘要 以及它们在相关工作中的缺点。 在这里，我们介绍 Cosmos，一种新颖的 blockchain 网络架构 解决所有这些问题。 Cosmos 是一个由许多人组成的网络 独立的 blockchain，称为区域。这些区域的动力来自 Tendermint Core [8]，提供高性能、 一致、安全的类似 PBFT 的共识引擎，其中严格的责任保证可以抑制恶意行为 演员。 Tendermint Core 的 BFT 共识算法非常适合 用于缩放 public proof-of-stake blockchains。 Cosmos 上的第一个区域称为 Cosmos 中心。 Cosmos Hub 是一种多资产 proof-of-stake 加密货币，具有简单的 使网络能够适应和适应的治理机制 升级。此外，Cosmos 集线器可以通过以下方式扩展： 连接其他区域。 Cosmos 网络的集线器和区域与 彼此通过 blockchain 间通信 (IBC) 协议， blockchains 的一种虚拟 UDP 或 TCP。代币可以是 安全、快速地从一个区域转移到另一个区域无需在区域之间交换流动性。相反， 所有区域间 token 传输均通过 Cosmos 中心，该中心 跟踪每个区域持有的 token 总量。的 集线器将每个区域与其他区域的故障隔离开来。因为 任何人都可以将新区域连接到 Cosmos 集线器，区域允许 为了与新的 blockchain 创新未来兼容。 在本节中，我们将描述 Tendermint 共识协议 以及用于构建应用程序的接口。了解更多 详情见附录。 在经典拜占庭容错 (BFT) 算法中，每个节点 具有相同的重量。在 Tendermint 中，节点具有非负数 投票权的大小以及投票赞成的节点 电源称为 validators。验证者参与 通过广播加密签名达成共识协议，或者 投票，就下一个区块达成一致。 验证者的投票权是在创世时决定的，或者是 由 blockchain 确定性地更改，具体取决于 应用程序。例如，在 proof-of-stake 应用程序中，例如 Cosmos Hub，投票权可以由 作为抵押品的 staking token 数量。 注：像 ⅔ 和 ⅓ 这样的分数是指总投票数的分数 功率，绝不是 validator 的总数，除非所有 validator 都 具有相同的权重。 >⅔表示“超过⅔”，≥⅓表示“至少 ⅓”。 Tendermint 是一个部分同步的 BFT 共识协议 源自 DLS 共识算法 [20]。嫩薄荷是

以其简单性、性能和分叉责任而闻名。 该协议需要一组已知的 validator，其中每个 validator 由其公钥识别。验证者试图 一次就一个区块达成共识，其中一个区块就是一个列表 的交易。对区块进行投票以达成共识 回合。每轮都有一位轮次领导者或提议者，他们 提出一个区块。然后 validator 分阶段投票决定是否 接受提议的区块或进入下一轮。的 一轮的提议者是从有序的中确定性地选择的 validator 列表，按其投票权比例。 此处描述了该协议的完整细节。 Tendermint 的安全性源自其对最佳拜占庭式的使用 通过绝对多数 (>⅔) 投票和锁定实现容错 机制。他们共同确保： ≥⅓ 投票权必须是拜占庭式的才会导致违反 安全，承诺两个以上的价值观。 如果任何一组 validator 曾经成功违反安全性，甚至 尝试这样做时，它们可以被协议识别。这个 包括对冲突区块的投票和广播 不公正的选票。 尽管有强有力的保证，Tendermint 仍提供卓越的服务 性能。在分布在 7 个节点的 64 个节点的基准测试中 数据中心遍布五大洲，位于商品云实例上， Tendermint 共识可以处理数千笔交易 其次，提交延迟约为一到两秒。 值得注意的是，每笔交易的性能远远超过一千笔 即使在恶劣的对抗条件下，第二个也能保持， validators 崩溃或广播恶意制作的投票。参见 详情请参见下图。

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

Tendermint 共识算法的一个主要好处是简化 轻客户端安全性，使其成为移动和 物联网用例。虽然 Bitcoin 轻客户端必须同步 区块头链，并找到拥有最多证明的区块头链 工作，Tendermint 轻客户端只需要跟上变化 到 validator 集，然后验证 >⅔ PreCommits 最新块来确定最新状态。 简洁的轻客户端证明还可以实现blockchain之间的交互 沟通。 Tendermint 有保护措施来防止某些 值得注意的攻击，例如远程无利害关系双花 和审查制度。这些在附录中进行了更全面的讨论。Tendermint 共识算法是在 名为 Tendermint Core 的程序。 Tendermint 核心是 与应用程序无关的“共识引擎”，可以改变任何 将确定性黑盒应用程序转化为分布式复制 blockchain。 Tendermint Core 连接到 blockchain 应用程序 通过应用程序区块链接口 (ABCI) [17]。因此，ABCI 允许 blockchain 应用程序在任何 语言，而不仅仅是达成共识的编程语言 引擎被写入。此外，ABCI 可以轻松地 交换任何现有 blockchain 堆栈的共识层。 我们用著名的加密货币Bitcoin进行类比。 Bitcoin 是每个节点维护的加密货币 blockchain 经过全面审核的未花费交易输出 (UTXO) 数据库。如果 有人想在 ABCI 之上创建一个类似 Bitcoin 的系统， Tendermint Core 将负责 节点之间共享区块和交易 建立规范/不可变的交易顺序（ blockchain) 同时，ABCI 应用程序将负责 维护 UTXO 数据库 验证交易的加密签名 防止交易花费不存在的资金 允许客户端查询 UTXO 数据库 Tendermint 能够通过以下方式分解 blockchain 设计： 在应用程序进程和 共识过程。

Cosmos 아키텍처

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

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

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

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

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

Cosmos 架构

Cosmos 是一个独立并行 blockchain 的网络，它们是 每个都由经典的 BFT 共识算法提供支持，例如 嫩薄荷 1. 该网络中的第一个 blockchain 将是 Cosmos 中心。的 Cosmos 集线器通过一个连接到许多其他 blockchain（或区域） 新颖的blockchain间通信协议。 Cosmos 中心 跟踪众多 token 类型并记录总数 每个连接区域中的 token 数量。代币可以是 安全、快速地从一个区域转移到另一个区域 无需在区域之间进行液体交换，因为所有 区域间硬币转账通过 Cosmos 中心。 该架构解决了 blockchain 空间的许多问题 今天面临的问题，例如应用程序互操作性、可扩展性和 无缝升级能力。例如，从 Bitcoind 派生的区域， Go-Ethereum、CryptoNote、ZCash 或任何 blockchain 系统都可以 插入 Cosmos 集线器。这些区域允许 Cosmos 无限扩展以满足全球交易需求。区域还有 对于分布式交换来说，这是一个很棒的 yt，它将得到以下支持： 好吧。 Cosmos 不仅仅是一个分布式账本，而且 Cosmos Hub 不是一个有围墙的花园，也不是宇宙的中心。我们是 为分布式账本的开放网络设计协议 可以作为未来金融系统的新基础， 基于密码学原理、健全的经济学、共识 理论、透明度和问责制。 Cosmos 中心是 Cosmos 中的第一个公共 blockchain 网络，由 Tendermint 的 BFT 共识算法提供支持。的 Tendermint 开源项目诞生于 2014 年，旨在解决 Bitcoin 的工作量证明共识算法的速度、可扩展性和环境问题。通过使用和改进经过验证的

BFT 于 1988 年在 MIT 开发的算法 [20]，Tendermint 团队是第一个概念性地演示 proof-of-stake 解决无利害关系问题的加密货币 遭受第一代 proof-of-stake 加密货币的困扰，例如 如 NXT 和 BitShares1.0。 如今，几乎所有 Bitcoin 移动钱包都使用可信服务器来 为他们提供交易验证。这是因为工作量证明需要在执行之前等待许多确认。 事务可以被视为不可逆转地提交。双花攻击已经在诸如 币库。 与其他 blockchain 共识系统不同，Tendermint 提供 即时且可证明安全的移动客户端支付验证。 由于 Tendermint 被设计为根本不会分叉，因此移动 钱包可以接收即时交易确认，这使得 无需信任且实用的支付在智能手机上成为现实。这个 对物联网应用具有重大影响，如 好吧。 Cosmos 中的验证者与 Bitcoin 矿工具有类似的角色，但是 而是使用加密签名进行投票。验证器是 负责提交的安全、专用机器 块。非 validator 可以委托其 staking token（称为 “atoms”）到任何 validator 以赚取部分区块费用和atom 奖励，但如果 委托 validator 被黑客攻击或违反协议。经证实的 Tendermint BFT 共识的安全保证以及抵押品 利益相关者的押金 –validators 和委托人 – 提供 节点和轻客户端的可证明、可量化的安全性。 分布式公共账本应该有一个章程和一个 治理体系。 Bitcoin 依赖于 Bitcoin 基金会并且挖矿来协调升级，但这是一个缓慢的过程。 Ethereum 硬分叉后分裂为 ETH 和 ETC 以解决 DAO 黑客攻击，很大程度上是因为没有事先的社会契约 也没有做出此类决定的机制。 Cosmos Hub 上的验证者和委托者可以投票 可以更改系统预设参数的建议 自动（例如区块gas limit），坐标升级，如 并对人类可读的宪法修正案进行投票 管理 Cosmos 中心的政策。宪法 允许利益相关者在以下问题上保持凝聚力： 盗窃和错误（例如TheDAO事件），允许更快和 更清晰的分辨率。 每个区域也可以有自己的宪法和治理 机制也是如此。例如，Cosmos 集线器可能有一个 强制中心不变性的宪法（无回滚， 保存 Cosmos Hub 节点实现的错误），同时 每个区域都可以设置自己的回滚策略。 通过实现不同政策区域之间的互操作性， Cosmos 网络为其用户提供最终的自由和潜力 未经许可的实验。 在这里，我们描述了一种去中心化和可扩展性的新颖模型。 Cosmos 是一个由许多 blockchain 组成的网络，由 嫩薄荷。虽然现有提案旨在创建“单一 blockchain”，全局交易排序总额为 Cosmos 允许许多 blockchain 彼此同时运行 同时保留互操作性。 在此基础上，Cosmos Hub 管理着许多独立的 blockchain 称为“区域”（有时称为“分片”，在 参考称为“分片”的数据库扩展技术）。

来自发布的区域的最近块提交的持续流 Hub 允许 Hub 跟上每个区域的状态。 同样，每个区域都与集线器的状态保持同步（但区域 除非间接通过 枢纽）。然后，信息包从一个 通过发布默克尔证明作为证据，将区域转移到另一个区域 信息已发送和接收。这种机制被称为 blockchain 间通信，简称 IBC。 任何区域本身都可以成为形成非循环图的中心， 但为了清楚起见，我们只描述简单的 只有一个集线器和许多非集线器的配置 区。 Cosmos 中心是托管多资产的 blockchain 分布式账本，其中 token 可以由个人用户持有或 由区域本身。这些 token 可以从一个区域移动 到另一个特殊的 IBC 数据包中，称为“硬币数据包”。枢纽是 负责保持总的全局不变性 跨区域的每个 token 的数量。 IBC 硬币包 交易必须由发送者、集线器和接收者提交 blockchains。由于 Cosmos Hub 充当整个系统的中央分类账 系统中，Hub 的安全至关重要。同时 每个区域都可以是 Tendermint blockchain，由 as 保护 少至 4 个（如果不需要 BFT 共识，甚至更少），Hub 必须由一组全球分散的 validator 来保证安全 可以承受最严重的攻击场景，例如 大陆网络分区或民族国家发起的攻击。 Cosmos 区域是一个独立的 blockchain，可交换 IBC 与 Hub 的消息。从 Hub 的角度来看，一个区域就是一个 多资产动态会员多重签名账户 可以使用 IBC 数据包发送和接收 tokens。就像一个 加密货币账户，一个区域不能传输超过 tokens 它有，但可以从拥有它们的其他人那里接收 token。 A区 可以被指定为一种或多种 token 类型的“源”， 授予其启动 token 电源的权力。 Cosmos 中心的原子可以由区域的 validator 质押 连接到集线器。虽然对这些区域进行双花攻击 将导致 Tendermint 的 forkaccountability 中的原子被削减，在该区域中，>⅔ 的投票权是 拜占庭可以提交无效状态。 Cosmos 集线器不 验证或执行在其他区域提交的交易，因此 用户有责任将 token 发送到他们信任的区域。 未来Cosmos Hub的治理体系可能会通过Hub 解决区域故障的改进建议。对于 例如，从某些（或所有）区域出站 token 传输可能会 被限制以允许区域紧急断路 （暂时停止 token 传输）当检测到攻击时。 现在我们看看中心和区域如何相互通信 其他。例如，如果有三个blockchain，“Zone1”，“Zone2”，

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

和“Hub”，我们希望“Zone1”生成一个数据包 “Zone2”穿过“Hub”。从一个数据包中移动一个数据包 blockchain 到另一个，一个证明被发布在接收链上。 该证明表明发送链发布了一个数据包 所谓的目的地。为了让接收链检查这个证明，它 必须能够跟上发送者的块头。这个 机制与侧链使用的机制类似，需要 两个相互作用的链通过 存在性数据报的双向流 （交易）。 IBC 协议自然可以使用两种类型来定义 交易：一个 IBCBlockCommitTx 交易，它允许 blockchain 向任何观察者证明其最新区块-hash， 和一个 IBCPacketTx 交易，它允许 blockchain 向任何观察者证明给定的数据包确实已发布 通过发送者的应用程序，通过对最近的 Merkle 证明 块-hash。 通过将 IBC 机制拆分为两个单独的事务，我们 允许接收链的原生费用市场机制 确定哪些数据包被提交（即确认），同时 允许发送链上完全自由地决定如何 允许许多出站数据包。 上例中，为了更新“Zone1”的块-hash 在“Hub”（或“Zone2”上的“Hub”）上，一个 IBCBlockCommitTx交易必须发布在“Hub”上，区块为hash “Zone1”（或在“Zone2”上，具有“Hub”的块hash）。 有关更多信息，请参阅 IBCBlockCommitTx 和 IBCPacketTx 关于两种 IBC 交易类型。 同样，Bitcoin 通过分布式更安全， 大规模复制的账本，我们可以使交易所不易受到 通过在 blockchain 上运行它来进行外部和内部黑客攻击。我们 称之为分布式交换。 加密货币社区所谓的去中心化 今天的交易所基于所谓的“原子跨链”（AXC）交易。通过 AXC 交易，两个用户 两条不同的链可以进行两笔转账交易 在两个分类账上一起承诺，或者根本没有承诺（即 原子地）。例如，两个用户可以用比特币交换以太币（或 两个不同分类账上的任意两个 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 小时交易量为 2000 万美元，位居第二的是 Bitynex 24 小时交易量为 500 万美元。鉴于如此强大的网络 影响，基于 AXC 的去中心化交易所不太可能 赢得中心化交易所的交易量。对于去中心化的 交易所要与中心化交易所竞争，需要 支持带有限价订单的深度订单簿。只有一个分布式 blockchain 上的交换可以提供这一点。 Tendermint 提供更快交易的额外好处 承诺。通过优先考虑快速性而不牺牲 一致性，Cosmos 中的区域可以快速分析事务 – 用于 交换订单交易以及 IBC token 转账至 以及来自其他区域的。 鉴于当今加密货币交易所的状况，一个伟大的 Cosmos 的应用程序是分布式交换（又名 Cosmos DEX)。交易吞吐能力以及 提交延迟可以与集中式的延迟相媲美 交流。交易者可以提交可以执行的限价订单 无需双方都在线。和 Tendermint 一起， Cosmos 中心和 IBC，交易者可以将资金转入和转出 与其他区域的快速交换。 特权区域可以充当桥接 token 的源 另一种加密货币。桥梁类似于关系 Cosmos 中心和区域之间；两者都必须跟上 另一个的最新区块，以验证 tokens 拥有的证据 从一个移动到另一个。 Cosmos 上的“桥接区” 网络与集线器以及其他设备保持同步

加密货币。通过桥接区的间接允许 中心的逻辑保持简单并且与其他人无关 blockchain 共识策略，例如 Bitcoin 的 proof-of-work 采矿。 每个桥区 validator 将运行由 Tendermint 驱动的 blockchain 具有特殊的 ABCI 桥接应用程序，而且也是一个全节点 “起源”blockchain。 当在原点开采新区块时，桥接区 validators 将通过签名就承诺区块达成一致 并分享他们各自对原产地 blockchain 的本地看法 小费。当桥接区域在来源处收到付款时（以及 已同意在本案中看到足够的确认 PoW 链（例如 Ethereum 或 Bitcoin），相应的 帐户是在桥接区域上用该余额创建的。 在 Ethereum 的情况下，桥接区域可以共享相同的 validator-设置为 Cosmos 集线器。在 Ethereum 一侧（ 起源），桥接合约将允许以太币持有者发送以太币 通过将其发送到桥接合约来发送到桥接区 Ethereum。一旦桥接合约收到以太币， 除非有适当的 IBC 数据包，否则无法提取以太币 由桥接合同从桥接区接收。的 桥接合约跟踪桥接区域的 validator 集，其中 可能与 Cosmos 集线器的 validator 集相同。 在 Bitcoin 的情况下，概念类似，只不过不是 一个桥梁合约，每个 UTXO 将由 阈值多重签名 P2SH pubscript。由于限制 P2SH 系统中，签名者不能与 Cosmos 相同 轮毂 validator-套。桥接区域上的以太币（“桥接以太币”）可以转移到 并从中心，然后通过交易销毁 将其发送到 Ethereum 上的特定提款地址。 IBC 证明事务发生在桥接区域的数据包 可以发布到 Ethereum 桥接合约以允许以太币 被撤回。 在 Bitcoin 的情况下，受限脚本系统使其 很难反映 IBC 硬币转移机制。每个 UTXO 有自己独立的pubscript，因此每个 UTXO 必须是 当集合发生变化时迁移到新的 UTXO Bitcoin 托管签名者。一种解决方案是压缩并 根据需要解压 UTXO-set 以保留总数 UTXO 秒下降。 这种桥接合约的风险是流氓 validator 集。 ≥⅓ 拜占庭投票权可能会导致分叉，提取以太币 来自 Ethereum 的桥接合约，同时将桥接以太币保持在桥接区域。更糟糕的是，>⅔ 拜占庭投票权可以 从发送到桥接合约的人那里直接窃取以太币 偏离了桥接区的原始桥接逻辑。 可以通过设计桥梁来解决这些问题 完全负责。例如，来自集线器的所有 IBC 数据包和 起源，可能需要桥接区的确认 这样桥区的所有状态转换都可以 受到枢纽或始发地的有效挑战和验证 过桥合同。中心和来源应允许桥区 validators 发布抵押品，并且 token 转出 过渡合同应该被推迟（并且抵押品解绑 足够长的时间）以允许提出任何挑战 独立审计师。我们留下规格的设计和 该系统的实施作为未来开放 Cosmos

改进提案，由 Cosmos 中心通过 治理体系。 解决缩放问题是 Ethereum 的一个悬而未决的问题。 目前，Ethereum 节点处理每笔交易并 还存储所有状态。关联。 由于 Tendermint 提交区块的速度比 Ethereum 快得多 proof-of-work、EVM 由 Tendermint 共识支持的区域和 在桥接以太网上运行可以提供更高的性能 Ethereum blockchains。此外，虽然 Cosmos 集线器和 IBC 数据包机制不允许任意合约逻辑 执行本身，它可用于协调 token 运动 在不同区域运行的 Ethereum 合约之间， 为以 token 为中心的 Ethereum 扩展提供基础 分片。 Cosmos 区域运行任意应用程序逻辑，其定义为 该区域生命的开始，并且有可能更新 随着时间的推移，通过治理。这种灵活性允许 Cosmos 区域 充当其他加密货币的桥梁，例如 Ethereum 或 Bitcoin，并且它还允许这些 blockchain 的衍生物， 使用相同的代码库但具有不同的 validator 集并且 初始分布。这使得许多现有的加密货币 框架，例如 Ethereum、Zerocash、Bitcoin 的框架， CryptoNote 等，与 Tendermint Core 一起使用， 在公共网络上更高性能的共识引擎， 为跨领域的互操作性提供了巨大的机会 平台。此外，作为多资产 blockchain，单一资产 交易可能包含多个输入和输出，其中每个 输入可以是任何 token 类型，使 Cosmos 能够直接用作 去中心化交易平台，但假设有订单通过其他平台进行匹配。或者，区域可以服务 作为分布式容错交易所（带有订单簿）， 可以是对现有集中式的严格改进 随着时间的推移，加密货币交易所往往会遭到黑客攻击。 区域还可以用作 blockchain 支持的企业版本 和政府系统，其中特定服务的各个部分 传统上由一个组织或一组组织运营 相反，它们作为 ABCI 应用程序在某个区域上运行， 让它继承大众的安全性和互操作性 Cosmos 网络而不牺牲对底层的控制 服务。因此，Cosmos 可能会提供两全其美的方案： 希望利用 blockchain 技术但谁是的组织 警惕将控制权完全交给分布式第三方 聚会。 一些人声称，有利于一致性的一个主要问题是 像 Tendermint 这样的共识算法是任何网络 分区导致不存在 >⅔ 的单个分区 投票权（例如≥⅓）将完全停止共识。 Cosmos 架构可以通过使用来帮助缓解这个问题 拥有区域自治区的全球中心，拥有投票权 每个区域都根据共同的地理分布 地区。例如，一个共同的范式可能适用于个人 城市或地区在共享资源的同时运营自己的区域 公共中心（例如 Cosmos 中心），使市政活动能够 在集线器由于临时网络而停止的情况下继续存在 分区。请注意，这允许真实的地质、政治和 设计鲁棒性时要考虑的网络拓扑特征 联合容错系统。

NameCoin 是第一个尝试解决这个问题的 blockchain 之一 通过调整 Bitcoin blockchain 来解决名称解析问题。 不幸的是，这种方法存在几个问题。 通过 Namecoin，我们可以验证，例如，@satoshi 是 在过去的某个时刻使用特定的公钥注册， 但我们不知道公钥是否已经被 最近更新，除非我们下载自上次以来的所有块 该名称的更新。这是由于 Bitcoin 的限制 UTXO 交易默克尔化模型，其中只有 交易（但不是可变的应用程序状态）是 Merkle 化的 进入块-hash。这让我们可以证明名称的存在，但不能证明名称的后续更新不存在。因此，我们无法得知 确定名称的最新值而不信任完整的 节点，或者通过下载产生大量带宽成本 整个blockchain。 即使在 NameCoin 中实现了 Merkle 化的搜索树， 它对 proof-of-work 的依赖使得轻客户端验证 有问题的。轻客户端必须下载完整的副本 整个 blockchain 中所有块的标头（或者至少是所有 自上次更新名称以来的标题）。这意味着 带宽需求随时间量线性变化 [21]。此外，proof-of-work blockchain 上的名称更改 需要等待额外的 proof-of-work 确认块， Bitcoin 上最多可能需要一个小时。 对于 Tendermint，我们只需要最新的区块 -hash 由 validator 的法定人数（通过投票权）和 Merkle 签署 证明与该名称关联的当前值。这使得 可以拥有一个简洁、快速、安全的轻客户端 名称值的验证。 在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 Cosmos 中心的 token。原子是持有者的许可证 投票、验证或委托给其他 validator。就像 Ethereum 的 以太，原子也可以用来支付交易费用 减少垃圾邮件。额外的信息原子和区块交易 费用奖励给 validator 和委托给的委托人 validators。 BurnAtomTx 交易可用于恢复任何 从储备池中按比例分配 token。 Genesis 上原子 tokens 和 validators 的初始分布 将捐给 Cosmos 筹款活动的捐助者 (75%)，主要捐助者 (5%)、Cosmos 网络基金会 (10%) 和 ALL IN BITS, Inc （10%）。从创世开始，原子总数的 1/3 将 每年都会奖励给绑定的 validator 和委托人。 有关更多详细信息，请参阅 Cosmos 计划。 与 Bitcoin 或其他 proof-of-work blockchain 不同，Tendermint 由于 validator 的数量增加，blockchain 会变慢 通信复杂性。幸运的是，我们可以支持足够多的人 validators 打造强大的全球分布式 blockchain 具有非常快的交易确认时间和带宽，

存储和并行计算能力的增加，我们将能够 将来支持更多 validator。 在创世日，validator 的最大数量将设置为 100，并且这个数字将在10年内以13%的速度增长，并且 稳定在 300 validators。 尚未成为 validators 的 Atom 持有者可以通过以下方式成为 validators： 签署并提交 BondTx 交易。金额 作为抵押品提供的原子必须非零。任何人都可以成为 a validator 在任何时候，除非当前的大小 validator 设置大于 validator 的最大数量 允许。在这种情况下，交易仅在金额达到 原子数大于所持有的有效原子数 最小的 validator，其中有效原子包括委托原子。 当新的 validator 以这种方式替换现有的 validator 时， 现有的 validator 变得不活跃，所有原子和 委托原子进入脱键状态。 必须对 validator 处以任何处罚 有意或无意偏离制裁规定 协议。有些证据可以立即采纳，例如 在相同的高度和轮次处进行双重签名，或者违反 第 0 年：100  第一年：113  第二年：127  第三年：144  第四年：163  5 年：184  第六年：208  7 年：235  8 年：265  9 年：300  10 年：300  ...

“prevote-the-lock”（Tendermint 共识协议的规则）。 此类证据将导致 validator 失去良好信誉 及其键合原子以及 tokens 的比例份额 储备池——统称为“股份”——将被削减。 有时，由于区域原因，validators 将不可用 网络中断、电源故障或其他原因。如果，在任何 在过去的 ValidatorTimeoutWindow 块中，validator 的点 提交投票未包含在 blockchain 中超过  ValidatorTimeoutMaxAbsent 次，validator 将变为 不活动，并失去其 ValidatorTimeoutPenalty（默认 1%） 股份。 一些“恶意”行为不会产生明显可辨别的结果 blockchain 上的证据。在这些情况下，validator 可以 带外协调以强制这些恶意软件超时 validators，如果达成绝大多数共识。 在 Cosmos 集线器因 ≥⅓ 联盟而停止的情况下 投票权消失，或者在 ≥⅓ 联盟的情况下 投票权审查的恶意行为证据 进入blockchain，集线器必须通过硬分叉恢复 重组提案。 （链接至“分叉和审查攻击”）。 Cosmos 集线器 validators 可接受任何 token 类型或组合 作为处理交易的费用的类型。每个 validator 可以 主观设定想要的汇率，然后选择 无论它想要什么交易，只要 BlockGasLimit 是 没有超过。收取的费用减去下面指定的任何税费， 按比例重新分配给担保利益相关者 他们的键合原子，每个 ValidatorPayoutPeriod （默认 1 小时）。在收取的交易费用中，保留税（默认 2%）将 前往储备池增加储备池并 提高 Cosmos 网络的安全性和价值。这些 资金也可以根据决定进行分配 由治理体系制定。 将投票权委托给其他 validator 的 Atom 持有者 向受委托人 validator 支付佣金。委员会可以 由每个 validator 设置。 Cosmos 集线器的安全性取决于 底层 validator 以及委托人的委托选择。 为了鼓励发现并及早报告所发现的 漏洞，Cosmos 中心鼓励黑客发布 通过 ReportHackTx 交易成功利用该交易，该交易表示：“这 validator 被黑了。请将赏金发送至此地址”。之上 这样的漏洞，validator 和委托人将变得不活跃，  每个人的原子都会受到 HackPunishmentRatio（默认 5%） 削减，以及每个人原子的 HackRewardRatio（默认 5%） 将获得奖励至黑客的赏金地址。 validator 必须使用其备份密钥恢复剩余的原子。 为了防止该功能被滥用进行转账 未归属原子，已归属原子与未归属原子的部分 ReportHackTx 之前和之后的 validators 和委托人将 保持不变，黑客赏金将包括一些 未归属的原子，如果有的话。 Cosmos 中心由一个分布式组织运营，该组织 需要一个明确的治理机制 协调对 blockchain 的各种更改，例如变量

系统参数，以及软件升级和 宪法修正案。 所有 validator 负责对所有提案进行投票。未能 及时对提案进行投票将产生 validator 自动停用一段时间，称为  缺勤处罚期（默认 1 周）。 委托人自动继承被委托人的投票权 validator。该投票可能会被手动覆盖。未键合的原子 没有投票权。 每个提案都需要缴纳最低提案存款 (MinimumProposalDeposit)  tokens，可以是一个或多个tokens的组合 包括原子。对于每项提案，选民可以投票通过 押金。如果超过半数选民选择投票 存款（例如，因为该提案是垃圾邮件），存款将转到 储备池，除了被燃烧的任何原子。 对于每项提案，选民可以对以下选项进行投票： 是啊 力挺 不 强行反对 弃权 绝对多数赞成票或 YeaWithForce 票（或反对票或反对票） NayWithForce 投票）需要提案被决定为 通过（或判定失败），但 1/3+ 可以否决多数 通过“强力”投票做出决定。当绝对多数被否决时， 每个人都会因失去 VetoPenaltyFeeBlocks 而受到惩罚  （默认 1 天的区块）价值的费用（税费除外） 不会受到影响），以及否决多数票的一方

决定将受到失去 VetoPenaltyAtoms 的额外惩罚  （默认 0.1%）其原子。 此处定义的任何参数都可以通过以下命令更改 传递 ParameterChangeProposal。 原子可以被注入，储备池资金可以用在 通过赏金提案。 所有其他提案，例如升级协议的提案， 将通过通用的 TextProposal 进行协调。 参见计划。 blockchain 共识有很多创新， 过去几年的可扩展性。本节提供了一个简短的 对选定的一些重要问题进行的调查。 存在恶意参与者的共识是一个问题 可以追溯到 20 世纪 80 年代初，当时 Leslie Lamport 创造了 短语“拜占庭错误”指的是任意进程行为 与“崩溃故障”相比，偏离了预期的行为， 其中一个进程简单地崩溃了。发现了早期的解决方案 对于有上限的同步网络消息延迟，尽管实际使用仅限于高度 受控环境，例如飞机控制器和 通过原子钟同步的数据中心。直到 90 年代末，实用拜占庭容错 (PBFT) [11] 作为有效的部分同步共识引入 算法能够容忍多达 ⅓ 的进程行为 任意地。 PBFT 成为标准算法，催生了许多 变体，包括 IBM 最近创建的一个变体，作为 他们对超级账本的贡献。 Tendermint 共识对 PBFT 的主要好处是 Tendermint 具有改进和简化的底层结构， 其中一些是采用 blockchain 范式的结果。 Tendermint 区块必须按顺序提交，这可以避免 与 PBFT 相关的复杂性和通信开销 视图更改。在 Cosmos 和许多加密货币中，没有 需要允许块 N+i（其中 i >= 1）提交，当块 N 本身还没有承诺。如果带宽是阻止 N 的原因 尚未在 Cosmos 区域中提交，那么使用它无济于事 N+i 块的带宽共享投票。如果网络分区或 ofzine节点是区块N没有提交的原因，那么 无论如何，N+i 都不会承诺。 此外，将交易分批放入区块允许 应用程序状态的常规 Merkle-hashing，而不是 与 PBFT 的检查点方案一样的定期摘要。这允许 为轻客户端提供更快的可证明事务提交，并且速度更快 blockchain 之间的通信。 Tendermint Core 还包括许多优化和功能 超出 PBFT 中指定的范围。例如， validators 提出的区块被分成几个部分，默克尔化， 并以改善广播的方式传播八卦 性能（请参阅 LibSwift [19] 以获取灵感）。还有，嫩薄荷 Core 不做任何关于点对点的假设

只要 P2P 网络存在，连接性和功能就一直存在 弱连接。 虽然不是第一次部署 proof-of-stake (PoS)，但 BitShares1.0 [12] 为 PoS 的研究和采用做出了巨大贡献 blockchains，特别是那些被称为“委托”PoS 的。在 比特股，利益相关者选举“见证人”，负责排序 并提交交易，以及“代表”，负责 协调软件更新和参数更改。 BitShares2.0旨在实现高性能（100k tx/s，1s 延迟）在理想条件下，每个块由单个签名 签名者和交易 ynality 花费的时间比 块间隔。规范规范仍在开发中。 利益相关者可以删除或更换行为不端的证人 每日进行，但没有重要的证人或证据 Tendermint PoS 中的委托人被削减 成功的双花攻击的情况。 基于 Ripple 首创的方法，Stellar [13] 雷尼德 联邦拜占庭协议模型，其中的过程 参与共识并不构成yxed和全球性的 已知集。相反，每个流程节点都会策划一个或多个 “仲裁切片”，每个切片构成一组可信进程。一个 Stellar 中的“quorum”被定义为包含以下内容的一组节点： 集合中的每个节点至少有一个仲裁片，这样 可以达成协议。 Stellar 机制的安全性依赖于以下假设 任意两个法定人数的交集非空，而 节点的可用性至少需要其仲裁片之一 完全由正确的节点组成，在之间创建一个权衡 使用可能难以平衡的大或小的仲裁片 无需对信任强加重大假设。最终，节点必须以某种方式选择足够的仲裁片 具有足够的容错能力（或任何“完整节点”，其中 论文的大部分结果取决于），并且唯一的 提供了确保这种配置是分层的策略 类似于边界网关协议 (BGP)，互联网上的顶级 ISP 使用它来建立全球路由表，并且 浏览器用来管理 TLS 证书；都臭名昭著 因为他们的不安全感。 Stellar 论文中对基于 Tendermint 的权益证明系统的批评通过所描述的 token 策略得到了缓解 这里，发出了一种称为原子的新类型 token 代表对未来部分费用和奖励的要求。的 那么，基于 Tendermint 的 proof-of-stake 的优势是它的相对优势 简单性，同时仍然提供充分且可证明的安全性 保证。 BitcoinNG 是对 Bitcoin 的拟议改进，允许 对于垂直可扩展性的形式，例如增加块大小， 不会产生通常相关的负面经济后果 有了这样的变化，比如不成比例的巨大影响 关于小矿工。这种改进是通过分离来实现的 交易广播中的领导者选举：领导者是第一名 由 proof-of-work 在“微块”中选出，然后能够 广播要提交的交易，直到出现新的微块 被发现。这降低了所需的带宽要求 赢得 PoW 竞赛，让小矿工更公平地竞争， 并允许交易更定期地由 最后一个矿工创建一个微块。 Casper [16] 是一种提议的 proof-of-stake 共识算法 Ethereum。其主要运作模式是“投注共识”。由 让 validators 迭代地押注他们认为会出现的区块

根据其他赌注投入 blockchain 到目前为止，他们已经看到，最终可以实现 ynality。关联。 这是 Casper 团队的一个活跃研究领域。的 挑战在于构建一个可以 被证明是一种进化稳定的策略。主要好处是 Casper 与 Tendermint 相比可能在于提供“可用性” 过度一致性”——共识不需要>⅔法定人数 投票权 – 可能以牺牲提交速度或 实施复杂度。 Interledger 协议 [14] 严格来说并不是一个可扩展性解决方案。它 提供不同账本之间的临时互操作 系统通过松散耦合的双边关系网络。 与闪电网络一样，ILP 的目的是促进 支付，但它特别关注不同领域的支付 账本类型，并将原子交易机制扩展到 不仅包括 hash-锁，还包括法定人数的公证人（称为 原子传输协议）。后一种机制用于 在账本间交易中强制执行原子性类似于 Tendermint 的轻客户端 SPV 机制，因此说明 ILP 和 Cosmos/IBC 之间的区别是有保证的，并且 下面提供。 1. ILP中连接器的公证人不支持会员资格 变化，并且不允许在之间进行灵活的权重 公证人。另一方面，IBC 是专门为 blockchains，其中 validators 可以有不同的权重，并且 成员资格可以在整个过程中发生变化 blockchain。 2. 与闪电网络一样，ILP中的付款接收方 必须在线才能将确认信息发送回发件人。在一个token 通过 IBC 传输，即接收器的 validator 集 blockchain 负责提供确认，而不是 接收用户。 3. 最显着的区别是 ILP 的连接器不是 对付款负责或保持权威状态， 而在 Cosmos 中，集线器的 validator 是 IBC token 的状态转移以及权限 每个区域持有的 token 数量（但不是 区域内每个账户持有的 tokens）。这是 允许安全不对称的根本性创新 将 tokens 从一个区域转移到另一个区域； ILP 的类似物 Cosmos 中的连接器是持久且高度安全的 blockchain 分类账，Cosmos 中心。 4. ILP 中的账本间支付需要有一个 交换订单簿，因为不存在非对称转移 硬币从一个分类账到另一个分类账，仅转移价值或 市场等价物。 侧链 [15] 是一种提议的用于扩展 Bitcoin 的机制 通过“双向挂钩”的替代 blockchain 网络 Bitcoin blockchain。 （双向挂钩相当于 桥接。在 Cosmos 中，我们说“桥接”以区别于市场挂钩）。侧链允许比特币有效地从 Bitcoin blockchain 到侧链和后面，并允许 侧链新功能的实验。正如在 Cosmos Hub、侧链和 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 特别是关于 tokens。紫红色是关于缩放 一般计算。 Cosmos 未绑定到 EVM，因此即使不同的虚拟机也可以 互操作。 Cosmos 让区域创建者确定谁验证该区域 区。 任何人都可以在 Cosmos 中启动一个新区域（除非治理 另有决定）。 集线器隔离区域故障，因此全局 token 不变量是 保存下来。 闪电网络是提议的 token 传输网络 在 Bitcoin blockchain （以及其他公共 blockchains)，实现多个数量级的改进 通过移动大部分交易来提高交易吞吐量 在共识账本之外进入所谓的“支付渠道”。这是通过链上加密货币脚本实现的，该脚本 使各方能够签订双边国家合同，其中 状态可以通过共享数字签名和合约来更新 可以通过将证据发布到 blockchain 来关闭，a 这种机制最早是通过跨链原子交换而普及的。由 与多方、参与者开放支付渠道 闪电网络可以成为路由的焦点 他人支付，形成全连接的支付通道 网络，代价是资金被束缚在支付渠道上。 虽然闪电网络也可以轻松地跨 多个独立的 blockchain 允许价值转移 通过交易市场，它不能被用来不对称地 将 token 从一个 blockchain 转移到另一个。主要收益 这里描述的 Cosmos 网络的目的是启用这种直接 token 转账。也就是说，我们期望支付渠道和 闪电网络将与我们一起被广泛采用 token 传输机制，出于节省成本和隐私的原因。 隔离见证是一个 Bitcoin 改进提案链接， 旨在将每块交易吞吐量提高 2 倍或 3 倍， 同时使新节点的块同步速度更快。 该解决方案的出色之处在于它如何在 Bitcoin 当前协议的限制并允许软分叉 升级（即使用旧版本软件的客户端将 升级后继续使用）。 Tendermint，成为新的 协议，没有设计限制，所以它有不同的缩放比例 优先事项。 Tendermint 主要使用 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

¼ è

共识和技术细节

一个设计良好的共识协议应该提供一些 超出耐受能力时的保证 并且共识失败。这在经济上尤其必要 系统中，拜占庭行为可能会产生大量的经济影响 奖励。最重要的此类保证是一种责任形式，其中导致共识的过程 失败（即导致协议的客户端接受不同的值 - a fork）可以根据规则进行识别和惩罚 协议，或者可能是法律体系。当法律制度 不可靠或调用成本过高， validators 可能是 被迫缴纳保证金才能参加，以及那些 当恶意行为发生时，存款可以被撤销或削减 检测到 [10]。 请注意，这与 Bitcoin 不同，其中分叉是经常发生的 由于网络异步性和 ynding 的概率性质 部分 hash 碰撞。因为在很多情况下，恶意分叉是 由于异步，与分叉无法区分，Bitcoin 不能 可靠地实施分叉责任，而不是隐式的 矿工为开采孤立区块而支付的机会成本。 我们将投票阶段称为 PreVote 和 PreCommit。投票可以是 特定块或 Nil。我们称之为>⅔预投票的集合 对于同一轮 Polka 中的单个块，以及 >⅔ 的集合 在同一轮提交中预提交单个块。如果>⅔ 在同一轮中预提交为零，他们进入下一轮 圆形。 请注意，协议中的严格决定论会导致较弱的 同步假设，因为必须检测到错误的领导者并

跳过了。因此，validators 等待一段时间， TimeoutPropose，在 Prevote Nil 之前，以及值 TimeoutPropose 随着每一轮的增加而增加。进展通过 一轮的其余部分是完全异步的，因为进度只是 一旦 validator 收到来自 >⅔ 的网络消息。在实践中， 需要一个极其强大的对手才能无限期地挫败 弱同步假设（导致共识无法达成） 曾经提交过一个区块），这样做可以使更多 通过在每个上使用 TimeoutPropose 的随机值来实现困难 validator。 一组附加的约束或锁定规则，确保 网络最终将在每个高度只提交一个区块。任意 恶意尝试导致多个区块被提交 可以识别给定高度。首先，对块进行 PreCommit 必须以 Polka 的形式为该块提供合理性。 如果 validator 已经在 R_1 轮预提交了一个区块，我们 说他们被锁定在那个街区，波尔卡用来证明 R_2 轮的新 PreCommit 必须出现在 R_polka 轮中 其中 R_1 < R_polka <= R_2。其次，validators 必须提出 和/或对他们锁定的区块进行预投票。在一起，这些 条件确保 validator 不会在没有预提交的情况下进行预提交 有足够的证据作为正当理由，并且 validators PreCommit 已经无法为 PreCommit 提供证据 其他的东西。这既保证了安全性又保证了活跃性 共识算法。 此处描述了该协议的完整细节。 TendermintPoS 消除了同步所有区块头的需要，因为替代链（分叉）的存在意味着 ≥⅓ 担保权益可以被削减。当然，由于削减需要 有人分享分叉的证据，轻客户端应该存储 任何 block-hash 提交它看到的。此外，轻客户端可以定期与 validator 集的更改保持同步， 为了避免远程攻击（但其他解决方案是 可能）。 本着与 Ethereum 类似的精神，Tendermint 使应用程序能够 在每个块中嵌入一个全局 Merkle 根 hash ，从而轻松地允许 可验证的状态查询，例如帐户余额、价值 存储在合约中，或存在未花费的交易 输出，取决于应用程序的性质。 假设广播网络具有足够的弹性集合 和静态 validator 集，blockchain 中的任何分叉都可以 被发现并削减了违规 validator 的存款。这个 Vitalik Buterin 在 2014 年初提出的创新解决了 其他 proof-of-stake 的无利害关系问题 加密货币（参见相关工作）。但是，由于 validator 设置 必须能够在很长一段时间内改变原来的 validators 可能全部变为非绑定状态，因此可以自由 从创世块创建一条新链，不产生任何成本 他们不再锁定存款。这次攻击发生了 与短程攻击相比，称为远程攻击 (LRA) 范围攻击，当前绑定的 validator 会造成 分叉，因此会受到惩罚（假设分叉负责 BFT 像 Tendermint 共识这样的算法）。远程攻击是 通常被认为是对 proof-of-stake 的致命打击。 幸运的是，LRA 可以通过以下方式缓解。首先，对于一个 validator 解绑（从而收回其抵押存款 并且不再赚取参与共识的费用）， 存款必须在一段时间内不可转让 称为“解绑期”，可能约为 几周或几个月。其次，为了保证轻客户端的安全，第一 当它连接到网络时，它必须验证最近的块-hash 针对可信来源，或者最好是多个来源。这个

这种情况有时被称为“弱主观性”。最后， 为了保持安全，它必须与最新的 validator 设置同步 最少与解绑期的长度一样频繁。这个 确保轻客户端知道 validator 的更改 在 validator 的资本解除绑定之前设置，因此不再 处于危险之中，这将使其能够通过执行来欺骗客户 通过从某个位置开始创建新块来进行远程攻击 它粘合的高度（假设它有足够的控制 许多早期的私钥）。 请注意，以这种方式克服 LRA 需要彻底修改 proof-of-work 的原始安全模型。在 PoW 中，是 假设轻客户端可以从 只需处理每个块头中的工作量证明即可随时获得可信创世块。然而，为了战胜上帝抵抗军，我们 要求轻客户端定期上线 跟踪 validator 集中的变化，并且第一时间他们 上网时他们必须特别小心地进行身份验证 他们从网络上听到的来自可信来源的信息。的 当然，后一个要求类似于 Bitcoin 的要求，其中 协议和软件还必须从受信任的机构获得 来源。 上述预防 LRA 的方法非常适合 validators 以及 Tendermint 支持的 blockchain 的完整节点，因为这些 节点旨在保持与网络的连接。的 该方法也适用于可以预期的轻客户端 经常与网络同步。然而，对于轻量级客户来说 预计不会经常访问互联网或 blockchain 网络，可以使用另一种解决方案来克服 圣主抵抗军。非 validator token 持有者可以将其 token 发布为 具有很长解绑期限的抵押品（例如更长的 超过 validators 的解绑期）并为轻客户端提供服务 使用第二种方法来证明当前和的有效性 过去的区块-hashes。虽然这些 token 不计入 blockchain 共识的安全性，但他们仍然可以为轻客户提供有力保障。如果历史区块-hash Ethereum 支持查询，任何人都可以绑定他们的 tokens 在专门设计的 smart contract 中并提供 付费认证服务，有效地为轻客户端 LRA 安全创造了市场。 由于块提交的定义，任何 ≥⅓ 的联盟 投票权可以通过是否关闭 blockchain 来阻止 blockchain 广播他们的选票。这样的联盟也可以审查 通过拒绝包含这些的块来特定交易 交易，尽管这会导致相当大的比例 的区块提案被拒绝，这将减慢速度 blockchain 的块提交，降低了其实用性和价值。 恶意联盟也可能会少量广播投票，以便 为了磨炼 blockchain 块，承诺几乎停止，或从事 这些攻击的任意组合。最后，它可能会导致 blockchain 通过双重签名或违反锁定来分叉 规则。 如果全球活跃的对手也参与其中，它可能会分裂 网络的方式可能会出现错误 validator 的子集导致了速度下降。这不是 只是 Tendermint 的限制，而是所有的限制 其网络可能由某个人控制的共识协议 积极的对手。 对于这些类型的攻击，validator 的子集应该 通过外部手段协调签署重组提案 选择一个分叉（及其任何证据）和初始子集 validator 及其签名。签署此类重组提案的验证者将放弃所有其他分叉上的抵押品。客户应该 验证重组提案上的签名，验证任何证据， 并做出判断或提示最终用户做出决定。对于 例如，手机钱包应用程序可能会提示用户安全

警告，而冰箱可以接受任何重组建议 由原始 validator 的 +1/2 投票权签署。 没有非同步的拜占庭容错算法可以来 当 ≥⅓ 的投票权不诚实时达成共识，但仍存在分叉 假设 ≥⅓ 的投票权已经被不诚实 没有正当理由的双重签名或锁更改。所以，签 重组提案是一个协调问题，无法解决 通过任何非同步协议解决（即自动，并且 不对可靠性做出假设 底层网络）。目前，我们将重组提案的协调问题留给人类通过社会共识进行协调 在网络媒体上。验证者必须注意确保 在签署重组提案之前没有剩余的网络分区，以避免签署两个相互冲突的重组提案的情况。 假设外部协调介质和协议是 稳健，因此与审查相比，分叉更受关注 攻击。 除了分叉和审查，需要≥⅓拜占庭 投票权，超过⅔投票权的联盟可以承诺 任意的、无效的状态。这是任何 (BFT) 的特征 共识系统。与创建分叉的双重签名不同 通过易于验证的证据，检测某人的承诺 无效状态需要非验证节点来验证整个块， 这意味着他们保留状态的本地副本并执行 每笔交易，独立计算状态根 他们自己。一旦检测到，处理此类故障的唯一方法 是通过社会共识。例如，在 Bitcoin 的情况下 失败了，是否由于软件 bug 导致分叉（如 3 月份 2013），或者由于拜占庭行为而提交无效状态 矿工（截至 2015 年 7 月），紧密联系的社区 企业、开发商、矿工和其他组织 关于什么是手动操作建立了社会共识参与者需要治愈网络。此外，由于 Tendermint blockchain 的 validator 可能预计为 无效国家的承诺甚至可能是可识别的 如果需要的话，可以受到法律或某些外部判例的惩罚。 ABCI 由 3 种主要消息类型组成，这些消息类型从 应用程序的核心。应用程序回复 相应的响应消息。 AppendTx 消息是应用程序的主力。每个 blockchain 中的事务随此消息一起传递。的 应用程序需要验证收到的每笔交易 针对当前状态、应用程序协议的 AppendTx 消息， 以及交易的加密凭证。经过验证的 然后事务需要更新应用程序状态 - 通过 将值绑定到键值存储中，或者通过更新 UTXO 数据库。 CheckTx 消息与 AppendTx 类似，但仅适用于 验证交易。 Tendermint Core 的内存池首次检查 与 CheckTx 交易的有效性，并且仅中继有效 与其同行的交易。应用程序可以检查递增 nonce 在交易中，并在 CheckTx 上返回错误，如果 nonce 已旧。 “提交”消息用于计算密码 对当前应用程序状态的承诺，将被放入 下一个块头。这有一些方便的属性。 更新该状态时的不一致现在将显示为 blockchain fork 捕获整个类的编程 错误。这也简化了安全轻量化的开发 客户，因为 Merkle-hash 证明可以通过检查来验证 区块-hash，区块-hash由法定人数签名 validators（按投票权）。

额外的 ABCI 消息允许应用程序跟踪 并更改 validator 设置，并让应用程序接收 区块信息，例如高度和提交投票。 ABCI 请求/响应是简单的 Protobuf 消息。检查 出架构yle。 论据： 数据（[]byte）：请求交易字节 返回： 代码 (uint32)：响应代码 数据（[]byte）：结果字节（如果有） 日志（字符串）：调试或错误消息 用途：

追加并运行事务。如果交易有效， 返回 CodeType.OK 论据： 数据（[]byte）：请求交易字节 返回： 代码 (uint32)：响应代码 数据（[]byte）：结果字节（如果有） 日志（字符串）：调试或错误消息 用途：

验证交易。此消息不应改变 状态。交易首先通过 CheckTx 运行 广播到内存池层中的对等点。你可以使 CheckTx 半状态并在提交时清除状态或 BeginBlock ，允许依赖的交易序列 在同一个街区。

返回： 数据（[]byte）：Merkle 根 hash 日志（字符串）：调试或错误消息 用途：

返回应用程序状态的 Merkle 根 hash。 论据： Data ([]byte) ：查询请求字节 返回： 代码 (uint32)：响应代码 数据（[]byte）：查询响应字节 日志（字符串）：调试或错误消息 用途：

刷新响应队列。实施的应用程序 types.Application 不需要实现此消息 - 它是 由项目处理。 返回： 数据（[]byte）：信息字节 用途：

返回有关应用程序状态的信息。应用 具体。 论据： Key（字符串）：要设置的键

值（字符串）：为键设置的值 返回： 日志（字符串）：调试或错误消息 用途：

设置应用程序选项。例如。键=“模式”，值=“mempool” 内存池连接，或 Key=“mode”，Value=“consensus” 共识连接。其他选项是特定于应用程序的。 论据： 验证器（[]Validator）：初始起源-validators 用途：

创世时被召唤一次 论据： 高度 (uint64)：起始区块高度 用途：

表示新块的开始。在任何之前调用 追加 Txs。 论据： 高度 (uint64)：结束的区块高度 返回： 验证器（[]Validator）：将 validators 更改为新的 投票权（0表示删除） 用途：

发出块结束的信号。毕竟在每次提交之前调用 交易 有关更多详细信息，请参阅 ABCI 存储库。发件人可能想要的原因有多种 接收链对数据包传送的确认。 例如，发送者可能不知道消息的状态 目标链（如果预计会出现故障）。或者，发件人可以 想要对数据包施加超时（使用 MaxHeight  数据包产量），而任何目标链都可能遭受拒绝服务攻击，传入数量突然激增 数据包。 在这些情况下，发件人可以要求送达确认 将初始数据包状态设置为 AckPending。那么，就是 接收链有责任通过包括 Merkle 应用程序中缩写为 IBCPacket hash。 首先，在“Hub”上发布 IBCBlockCommit 和 IBCPacketTx 这证明了“Zone1”上存在 IBCPacket。这么说  IBCPacketTx 具有以下值： FromChainID：“Zone1” FromBlockHeight : 100 (比如说) 数据包：IBC数据包：

标头：IBCPacketHeader： 源链ID：“Zone1” 目标链 ID：“Zone2” 数量：200（比如说） 状态：确认待处理 类型：“硬币” MaxHeight：350（假设“Hub”当前高度为 300） Payload : <“硬币”有效负载的字节> 接下来，在“Zone2”上发布 IBCBlockCommit 和 IBCPacketTx 这证明了“Hub”上存在IBCPacket。这么说  IBCPacketTx 具有以下值： FromChainID : “Hub” 从块高度：300 数据包： IBC 数据包： 标头：IBCPacketHeader： 源链ID：“Zone1” 目标链 ID：“Zone2” 数量：200 状态：确认待处理 类型：“硬币” 最大高度：350 有效负载：<“硬币”有效负载的相同字节> 接下来，“Zone2”必须在其应用程序-hash中包含一个缩写数据包 显示 AckSent 的新状态。 IBCBlockCommit 和  IBCPacketTx 被发布回“Hub”，证明存在 “Zone2”上的缩写IBCPacket。说 IBCPacketTx  具有以下值： FromChainID：“Zone2”

FromBlockHeight : 400 (比如说) 数据包： IBC 数据包： 标头：IBCPacketHeader： 源链ID：“Zone1” 目标链 ID：“Zone2” 数量：200 状态：已发送 类型：“硬币” 最大高度：350 PayloadHash : <同一“硬币”有效负载的 hash 字节> 最后，“集线器”必须更新数据包的状态  AckPending 到 AckReceived。这种新的分析状态的证据 应该回到“Zone2”。假设 IBCPacketTx 具有以下内容 值： FromChainID : “Hub” 从块高度：301 数据包： IBC 数据包： 标头：IBCPacketHeader： 源链ID：“Zone1” 目标链 ID：“Zone2” 数量：200 状态：已收到 类型：“硬币” 最大高度：350 PayloadHash : <同一“硬币”有效负载的 hash 字节> 同时，“Zone1”可能乐观地认为交付成功 除非有相反的证据证明是“硬币”包 “枢纽”。在上面的示例中，如果“Hub”未收到 AckSent

块 350 来自“Zone2”的状态，它会设置状态 自动超时。这个超时的证据可以得到 发回“Zone1”，并且可以返回任何 token。 支持两种类型的 Merkle tree Tendermint/Cosmos 生态系统：简单树和 IAVL+ 树。 简单树是一个静态元素列表的 Merkle tree 。如果 项目数不是 2 的幂，有些叶子将位于 不同的级别。简单树试图保持树的两侧 高度相同，但左侧可能更大。这个 Merkle tree 是 用于对区块的交易进行 Merkle 化，顶层 应用程序状态根的元素。IAVL+数据结构的目的是提供持久性 应用程序状态中键值对的存储，以便 可以有效地计算确定性 Merkle 根 hash。的 使用 AVL 算法的变体来平衡树，并且所有 操作是 O(log(n))。 在AVL树中，任意节点的两个子子树的高度 最多相差一。每当违反此条件时 更新时，通过创建 O(log(n)) 个新节点来重新平衡树 指向旧树中未修改的节点。在原来的AVL中 算法中，内部节点也可以保存键值对。 AVL+ 算法（注意加号）修改AVL算法以保留所有 叶节点上的值，而仅使用分支节点来存储键。 这简化了算法，同时保留了 Merkle hash 踪迹 短。 AVL+ 树类似于 Ethereum 的 Patricia 尝试。有 权衡。键在插入之前不需要 hashed IAVL+ 树，因此这可以在键中提供更快的有序迭代 空间可能有利于某些应用程序。逻辑更简单 实现，只需要两种类型的节点——内部节点和 叶节点。 Merkle 证明平均较短，是                 *                 / \               /     \             /         \           /             \          *               *         / \             / \        /   \           /   \       /     \         /     \      *       *       *       h6     / \     / \     / \    h0 h1 h2 h3 h4 h5    具有 7 个元素的 SimpleTree

平衡二叉树。另一方面，默克尔根 IAVL+树取决于更新的顺序。 我们将支持额外的高效 Merkle tree，例如 当二进制变体变为 Ethereum 的 Patricia Trie 时 可用。 在规范的实现中，交易被流式传输到 Cosmos 集线器应用程序通过 ABCI 接口。 Cosmos Hub将接受一些主要交易 类型，包括 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) ：提交的轮次 提交（[]投票）：>⅔ Tendermint 预提交投票表明 包含一个块提交 ValidatorsHash ([]byte) ：新的 Merkle 树根 hash validator 设置

ValidatorsHashProof (SimpleProof)：一个 SimpleTree Merkleproof，用于根据 BlockHash 证明 ValidatorsHash AppHash ([]byte) ：IAVLTree Merkle 树根 hash 应用状态 AppHashProof (SimpleProof)：SimpleTree Merkle 证明 对照 BlockHash 证明 AppHash IBC数据包由以下部分组成： 标头 (IBCPacketHeader) ：数据包标头 Payload ([]byte) ：数据包有效负载的字节。可选 PayloadHash ([]byte) ：数据包字节的 hash 。 可选 Payload 或 PayloadHash 之一必须存在。 hash IBCPacket 的 是两个项目的简单 Merkle 根，即 Header  和有效负载。没有完整负载的 IBC 数据包称为 缩写数据包。 IBCPacketHeader 由以下部分组成： SrcChainID（字符串）：源 blockchain ID DstChainID（字符串）：目的地 blockchain ID Number（int）：所有数据包的唯一编号 状态（枚举）：可以是 AckPending 、 AckSent 之一， AckReceived 、 NoAck 或超时 类型（字符串）：类型取决于应用程序。 Cosmos 保留“coin”数据包类型 MaxHeight (int) ：如果状态不是 NoAckWanted 或 AckReceived 到了这个高度，状态就变成 Timeout 。可选 IBCPacketTx 交易由以下部分组成：FromChainID（字符串）：blockchain 的 ID，即 提供此数据包；不一定是来源 FromBlockHeight (int) ： blockchain 高度，其中 以下数据包包含（Merkle 化）在块 hash 中 源链 Packet (IBCPacket) ：数据包，其状态可能是一个 AckPending 、 AckSent 、 AckReceived 、 NoAck 或 Timeout PacketProof (IAVLProof)：用于证明的 IAVLTree Merkle-proof 数据包的 hash 与源链的 AppHash 相对应 给定高度 从“Zone1”到“Zone2”发送数据包的顺序 通过“集线器”的情况如{图X}所示。首先，一个 IBCPacketTx  向“Hub”证明该数据包包含在应用程序状态中 “1区”。然后，另一个 IBCPacketTx 向“Zone2”证明 数据包包含在“Hub”的应用程序状态中。在此期间 过程中，IBCPacket 的结果是相同的：SrcChainID 是 始终为“Zone1”，DstChainID 始终为“Zone2”。 PacketProof 必须具有正确的 Merkle-proof 路径，如下所示 如下： 当“Zone1”想要通过“Hub”向“Zone2”发送数据包时， 无论数据包在“Zone1”、“Hub”还是“Zone2”上进行 Merkleized，IBCPacket 数据都是相同的。唯一可变的yield是  跟踪递送的状态。 我们感谢我们的朋友和同行在概念化方面提供的帮助， 审查并为我们与 Tendermint 的合作提供支持 和 Cosmos。 IBC/<源链ID>/<目标链ID>/<编号>

SkuChain 的 Zaki Manian 在格式化和 措辞，特别是在 ABCI 部分下 Althea 的 Jehan Tremback 和达斯汀·拜因顿 (Dustin Byington) 提供的帮助 初始迭代 Honey Badger 的 Andrew Miller 对共识的反馈 Greg Slepak 对共识和措辞的反馈 还要感谢 Bill Gleim 和 Seunghwan Han 所做的各种努力 贡献。 此处提供您的姓名和组织以供您贡献 1 Bitcoin：https://bitcoin.org/bitcoin.pdf 2 零现金：http://zerocash-project.org/paper 3Ethereum：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/

13Stellar：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/ 17ABCI：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 个 DLS： 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

Ø è