Cosmos：分布式账本网络
導入
オープンソース エコシステムの総合的な成功により、 分散型ファイル共有とパブリック暗号通貨は、 分散型インターネットプロトコルという理解を促した 社会経済インフラを根本的に改善するために使用できます。 Bitcoin [1] のような特殊な blockchain アプリケーションを見てきました ( 暗号通貨)、Zerocash [2] (プライバシーのための暗号通貨)、および Ethereum [3] などの一般化された smart contract プラットフォーム、 Ethereum Virtual 用の無数の分散アプリケーション Augur (予測市場) や TheDAO などのマシン (EVM) [4] (投資クラブ)。 しかし、これまでに、これらのblockchainは数多くの被害を受けてきました。 総エネルギー効率の悪さ、貧弱な、または パフォーマンスが限られており、ガバナンスメカニズムが未熟です。 Bitcoin のトランザクション スループットを拡張するための提案。たとえば、 Segregated-Witness [5] および BitcoinNG [6] は垂直スケーリングです 単一の物理的な容量によって依然として制限されるソリューション 完全な監査可能性の特性を確保するために、マシン。 ライトニング ネットワーク [7] は、Bitcoin トランザクションのスケールアップに役立ちます
一部の取引を台帳から完全に除外することで取引量を削減し、 少額決済やプライバシー保護に適しています。 支払いレールを備えていますが、より一般化された用途には適していない可能性があります スケーリングのニーズ。 理想的なソリューションは、複数の blockchain を並列に実行できるソリューションです。 セキュリティ特性を維持しながら相互運用できます。これには、 proof-of-work では、不可能ではないにしても、難しいことが証明されています。合併しました たとえば、マイニングでは、親を確保するために行われる作業が可能になります。 チェーンは子チェーンで再利用されますが、トランザクションは依然として 各ノードによって順番に検証され、マージマイニングされた blockchain hash の電源の大部分がオンになっている場合、攻撃に対して脆弱になります。 親は子を積極的にマージマイニングしていません。学術的なレビュー 代替 blockchain ネットワーク アーキテクチャが提供されています 追加のコンテキスト、および他の提案の概要を提供します とその欠点を関連作品で説明します。 ここでは、新しい blockchain ネットワーク アーキテクチャである Cosmos を紹介します。 これらすべての問題に対処します。 Cosmos は多くのネットワークです ゾーンと呼ばれる独立した blockchain。ゾーンの電源は次のとおりです。 高性能を提供する Tendermint Core [8]、 一貫性のある安全な PBFT のようなコンセンサス エンジン。悪意のある者の行動に対して厳格な責任追及保証が保持されます。 俳優たち。 Tendermint Core の BFT コンセンサス アルゴリズムが最適です パブリック proof-of-stake blockchains のスケーリング用。 Cosmos の最初のゾーンは、Cosmos ハブと呼ばれます。 Cosmos Hub は、シンプルな機能を備えたマルチアセット proof-of-stake 暗号通貨です。 ネットワークの適応を可能にするガバナンス メカニズム アップグレードします。さらに、Cosmos ハブは次のように拡張できます。 他のゾーンを接続します。 Cosmos ネットワークのハブとゾーンは以下と通信します。 blockchain 間通信 (IBC) プロトコルを介して相互に、 blockchain の一種の仮想 UDP または TCP。トークンは次のことができます あるゾーンから別のゾーンに安全かつ迅速に転送ゾーン間で流動性を交換する必要はありません。代わりに、 すべてのゾーン間の token 転送は Cosmos ハブを経由します。 各ゾーンが保持する token の合計量を追跡します。の ハブは、各ゾーンを他のゾーンの障害から隔離します。なぜなら 誰でも新しいゾーンを Cosmos ハブに接続できます。ゾーンでは許可されています 新しい blockchain イノベーションとの将来の互換性を実現します。 このセクションでは、Tendermint コンセンサス プロトコルについて説明します。 およびそれを使用してアプリケーションを構築するために使用されるインターフェイス。さらに詳しく 詳細については、付録を参照してください。 古典的なビザンチン フォールト トレラント (BFT) アルゴリズムでは、各ノード 同じ重さです。 Tendermint では、ノードには非負の値があります。 投票権の量と肯定的な投票を持つノード 電力はvalidatorと呼ばれます。バリデーターは 暗号署名をブロードキャストすることによるコンセンサス プロトコル、または 次のブロックに同意するために投票します。 バリデーターの投票権は生成時に決定されるか、 に応じて、blockchain によって決定的に変更されます。 アプリケーション。たとえば、次のような proof-of-stake アプリケーションでは、 Cosmos ハブ、投票力は次によって決定される場合があります。 staking token が担保として保証されます。 注: 2/3 や 1/3 などの端数は、投票総数の端数を指します。 すべての validator を除く、validator の合計数ではありません。 等しい重みを持っています。 >2/3 は「2/3 以上」を意味し、≥1/3 は「少なくとも」を意味します ⅓」。 Tendermint は部分同期 BFT コンセンサス プロトコルです DLS コンセンサス アルゴリズム [20] から派生しました。テンダーミントは
そのシンプルさ、パフォーマンス、フォークの説明責任で注目に値します。 このプロトコルには、固定された既知の validator セットが必要です。 validator は公開鍵によって識別されます。バリデータは次のことを試みます 一度に 1 つのブロックについて合意に達します (ブロックはリストです) 取引の。ブロックのコンセンサスに対する投票は次の手順で行われます。 ラウンドします。各ラウンドにはラウンドリーダー、つまり提案者がいます。 ブロックを提案します。次に、validator は、次のいずれかについて段階的に投票します。 提案されたブロックを受け入れるか、次のラウンドに進みます。の ラウンドの提案者は、順序付けられたものから決定的に選択されます。 投票力に比例した validator のリスト。 プロトコルの完全な詳細はここで説明されています。 Tendermint のセキュリティは、最適な Byzantine の使用に由来します。 超過半数 (>2/3) の投票とロックによるフォールト トレランス 仕組み。これらは連携して次のことを保証します。 違反を引き起こすには 1/3 以上の投票権がビザンチンでなければなりません 安全性。2 つ以上の値がコミットされます。 validator のセットが安全性の侵害に成功した場合、あるいは そうしようとすると、プロトコルによって識別される可能性があります。これ 競合するブロックへの投票とブロードキャストの両方が含まれます 不当な投票。 その強力な保証にもかかわらず、Tendermint は例外的なサービスを提供します パフォーマンス。 7 つのノードに分散された 64 ノードのベンチマーク 5 大陸のデータセンター、コモディティ クラウド インスタンス、 Tendermint コンセンサスは、1 回あたり数千のトランザクションを処理できます。 2 番目は、コミットの遅延が 1 ～ 2 秒程度です。 特に、1 回あたり 1,000 件をはるかに超えるトランザクションのパフォーマンスが優れています。 過酷な敵対状況でも秒速が維持されます。 validator は、悪意を持って作成された投票をクラッシュまたはブロードキャストします。参照 詳細については、以下の図を参照してください。
Tendermint のコンセンサス アルゴリズムの大きな利点は、簡素化されることです。 クライアントのセキュリティが軽いため、モバイルおよび モノのインターネットの使用例。 Bitcoin ライトクライアントは同期する必要がありますが、 ブロックヘッダーのチェーンを検索し、最も証拠のあるものを見つけます。 Tendermint ライト クライアントは変更に対応するだけで済みます。 validator セットに追加し、>2/3 PreCommit を確認します。 最新の状態を判断するための最新ブロック。 簡潔なライト クライアント証明により、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 共识算法的一个主要好处是简化 轻客户端安全性，使其成为移动和 物联网用例。虽然 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 (またはゾーン) に経由で接続します。 新しい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 のproof-of-workコンセンサスアルゴリズムの速度、スケーラビリティ、環境問題。実績のあるものを使用および改善することにより、
BFT アルゴリズムは 1988 年に MIT で開発されました [20]、Tendermint チームは、proof-of-stake を概念的に実証した最初の人物でした 何も問題がない問題に対処する暗号通貨 第 1 世代 proof-of-stake 暗号通貨の被害 NXT および BitShares1.0 として。 現在、事実上すべての Bitcoin モバイル ウォレットは信頼できるサーバーを使用して、 取引の検証を提供します。これは、proof-of-work では、作業の前に多くの確認を待つ必要があるためです。 トランザクションは不可逆的にコミットされたと見なすことができます。二重支払い攻撃は、次のようなサービスですでに実証されています。 コインベース。 他の blockchain コンセンサス システムとは異なり、Tendermint は以下を提供します 即時かつ確実に安全なモバイルクライアントの支払い検証。 Tendermint は決してフォークしないように設計されているため、モバイル ウォレットは即座にトランザクション確認を受け取ることができるため、 トラストレスで実用的な支払いがスマートフォン上で実現します。これ モノのインターネット アプリケーションに重大な影響を与える まあ。 Cosmos のバリデーターは Bitcoin マイナーと同様の役割を果たしますが、 代わりに暗号署名を使用して投票します。バリデーターは コミットを担当する安全な専用マシン ブロック。 validator 以外のユーザーは、staking token (と呼ばれる) を委任できます。 「アトム」) を任意の validator に送信して、ブロック手数料とアトムの一部を獲得します 報酬は得られますが、次の場合には罰せられる（切り捨てられる）リスクが伴います。 デリゲート validator がハッキングされたか、プロトコルに違反しました。証明された Tendermint BFT コンセンサスの安全性の保証と担保 利害関係者の保証金 – validator および委任者 – が提供する ノードとライトクライアントのための証明可能かつ定量化可能なセキュリティ。 分散型公開台帳には憲法と ガバナンスシステム。 Bitcoin は Bitcoin 財団に依存しており、アップグレードを調整するためにマイニングを行いますが、これには時間がかかります。 Ethereum ハードフォークしてアドレス指定した後、ETH と ETC に分割 DAO ハッキング、主に事前の社会契約がなかったため そのような決定を下すためのメカニズムもありません。 Cosmos ハブの検証者と委任者は、次の項目に投票できます。 システムのプリセットパラメータを変更できる提案 自動的に (ブロックガス制限など)、アップグレードを調整します。 人間が読める憲法の修正案に投票する Cosmos ハブのポリシーを管理します。憲法 などの問題に関して利害関係者間の団結が可能になります。 盗難やバグ (TheDAO インシデントなど) により、より迅速かつ迅速な対応が可能になります。 よりクリーンな解像度。 各ゾーンは独自の憲法と統治を持つこともできます 仕組みも。たとえば、Cosmos ハブには ハブで不変性を強制する構成 (ロールバックなし、 Cosmos ハブ ノード実装のバグを除いて)、 各ゾーンはロールバックに関して独自のポリシーを設定できます。 異なるポリシー ゾーン間の相互運用性を有効にすることで、 Cosmos ネットワークはユーザーに究極の自由と可能性を与えます。 無許可の実験。 ここでは、分散化とスケーラビリティの新しいモデルについて説明します。 Cosmos は、多くの blockchain を搭載したネットワークです。 テンダーミント。既存の提案は「単一の」を作成することを目的としていますが、 blockchain」、グローバル トランザクションの合計順序付け、Cosmos 多数の blockchain を相互に同時に実行できるようにします 相互運用性を維持しながら。 基本的に、Cosmos ハブは多くの独立したものを管理します。 blockchain 「ゾーン」と呼ばれる (以下では「シャード」と呼ばれることもあります) 「シャーディング」として知られるデータベース スケーリング技術を指します)。
に投稿されたゾーンからの最近のブロックコミットの継続的なストリーム ハブにより、ハブは各ゾーンの状態を常に把握できるようになります。 同様に、各ゾーンはハブの状態を常に把握します（ただし、ゾーンは を介して間接的に行われる場合を除いて、互いに連絡を取り合わないでください。 ハブ）。その後、情報のパケットが一方から通信されます。 マークルプルーフを証拠として投稿することで、別のゾーンにゾーンします。 情報が送受信されました。このメカニズムはと呼ばれます blockchain 間通信、または略して IBC。 どのゾーンもそれ自体をハブとして非循環グラフを形成できます。 しかし、明確にするために、簡単なことだけを説明します。 ハブが 1 つだけあり、ハブ以外のものが多数ある構成 ゾーン。 Cosmos ハブは、マルチアセットをホストする blockchain です。 分散型台帳。token は個々のユーザーが保持できます。 ゾーン自体によって。これらのtokenは1つのゾーンから移動できます 「コイン パケット」と呼ばれる特別な IBC パケットで別のパケットに送信します。ハブは 合計の大域的不変性を維持する責任がある ゾーン全体の各 token の量。 IBC コイン パケット トランザクションは送信者、ハブ、受信者によってコミットされる必要があります blockchain秒。Cosmos ハブは全体の中央台帳として機能するため、 システムでは、ハブのセキュリティが最も重要です。その間 各ゾーンは、次のように保護される Tendermint blockchain である可能性があります。 4 つほど少ない (BFT コンセンサスが必要ない場合はさらに少ない)、ハブ グローバルに分散された validator のセットによって保護される必要があります。 などの最も厳しい攻撃シナリオに耐えることができます。 大陸ネットワークの分割または国家支援による攻撃。 Cosmos ゾーンは、IBC を交換する独立した blockchain です。 ハブとのメッセージ。ハブの観点から見ると、ゾーンは マルチアセット ダイナミック メンバーシップ マルチシグネチャ アカウント IBC パケットを使用して token を送受信できます。のように 暗号通貨アカウントでは、ゾーンは token を超えて転送することはできません 持っていますが、token を持っている他のユーザーから token を受け取る可能性があります。ゾーン 1 つ以上の token タイプの「ソース」として指定できます。 token 電源を注入する電力を与えます。 Cosmos ハブのアトムは、ゾーンの validator によってステーキングされる可能性があります ハブに接続されています。これらのゾーンへの二重攻撃攻撃中 その結果、投票権の 2/3 を超えるゾーンであるテンダーミントの責任追及の責任が大幅に削減されることになるでしょう。 Byzantine は無効な状態をコミットする可能性があります。 Cosmos ハブは、 他のゾーンでコミットされたトランザクションを検証または実行するため、 ユーザーは、信頼するゾーンに token を送信する責任があります。 将来的には、Cosmos ハブのガバナンス システムがハブを追い越す可能性があります。 ゾーンの障害を考慮した改善提案。のために たとえば、一部 (またはすべて) ゾーンからのアウトバウンド token 転送は、 ゾーンの緊急サーキットブレークを可能にするためにスロットルされる (token 転送の一時停止) 攻撃が検出されたとき。 ここで、ハブとゾーンがそれぞれとどのように通信するかを見てみましょう。 その他。たとえば、「Zone1」、「Zone2」という 3 つの blockchain がある場合、
と「ハブ」。「ゾーン 1」が次の宛先のパケットを生成することを望みます。 「Hub」を経由する「Zone2」の場合。パケットをあるものから移動するには blockchain を別のユーザーに送信すると、プルーフが受信チェーンに投稿されます。 証拠は、送信チェーンがパケットをパブリッシュしたことを示しています。 疑わしい目的地。受信チェーンがこの証明をチェックするには、 送信者のブロックヘッダーを追跡できる必要があります。これ このメカニズムはサイドチェーンで使用されるものと似ています。 相互作用する 2 つのチェーンが、 存在証明データグラムの双方向ストリーム (トランザクション)。 IBC プロトコルは、当然のことながら 2 種類の トランザクション: IBCBlockCommitTx トランザクション。 blockchain は、最新のブロック hash を観察者に証明します。 IBCPacketTx トランザクションにより、blockchain は 指定されたパケットが実際にパブリッシュされたことをオブザーバーに証明する 送信者のアプリケーションによる、最近のメールに対するマークルプルーフを介した ブロック-hash。 IBC メカニズムを 2 つの別々のトランザクションに分割することで、 受信チェーンのネイティブ料金市場メカニズムを許可します。 どのパケットがコミットされるか (つまり、確認応答されるか) を決定します。 どのように送信するかについて、送信チェーン上で完全な自由を許可します。 多くの送信パケットが許可されます。 上記の例では、「Zone1」のブロック-hashを更新するには 「ハブ」（または「Zone2」の「ハブ」）上、IBCBlockCommitTxトランザクションは、ブロック-hash を使用して「ハブ」に投稿する必要があります。 「ゾーン 1」 (または「ハブ」のブロック hash を持つ「ゾーン 2」)。 詳細については、IBCBlockCommitTx および IBCPacketTx を参照してください。 2 つの IBC トランザクション タイプについて。 Bitcoin が分散型であることで安全性が高まるのと同じように、 台帳を大量に複製することで、取引所の脆弱性を軽減できます。 blockchain で実行することで、外部および内部のハッキングを実行できます。私たち これを分散型交換と呼びます。 暗号通貨コミュニティが分散型と呼ぶもの 今日の取引所は、「アトミック クロスチェーン」（AXC）トランザクションと呼ばれるものに基づいています。 AXC トランザクションでは、2 人のユーザーが 2 つの異なるチェーンは 2 つの転送トランザクションを実行できます。 両方の台帳で一緒にコミットされるか、まったくコミットされない（すなわち、 原子的に）。たとえば、2 人のユーザーがビットコインをイーサ (または 2 つの異なる台帳上の任意の 2 つの token)、AXC トランザクションを使用し、 Bitcoin と Ethereum がそれぞれに接続されていない場合でも その他。 AXC トランザクションで取引所を運営する利点は次のとおりです。 どちらのユーザーもお互いを信頼する必要も、トレードマッチングを信頼する必要もありません サービス。欠点は、双方がオンラインである必要があることです。 起こる貿易。 もう 1 つのタイプの分散型取引所は、大量複製です。 独自の 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”，
和“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 代表匹配并完成交易 交易者的。
アプリケーション
集中型取引所は、指値の深いオーダーブックを作成できる 注文を増やし、それによってより多くのトレーダーを引き寄せます。流動性がさらに高まる 取引所の世界には流動性があり、強力なネットワークが存在します。 交換における効果（または少なくとも勝者総取り効果） ビジネス。現在の仮想通貨取引所のリーダー Poloniex は 24 時間の出来高が 2,000 万ドルで、2 位は Bitynex の 24 時間取引高は 500 万ドルです。これほど強力なネットワークがあると、 その影響で、AXC ベースの分散型取引所が影響を受ける可能性は低いです。 集中型取引所よりもボリュームを獲得します。分散型の場合 集中型取引所と競合するには、取引所が必要になります。 指値注文によるディープオーダーブックをサポートします。配布のみ blockchain の Exchange がそれを提供します。 Tendermint はトランザクションの高速化による追加のメリットを提供します コミットします。犠牲にすることなく高速性を優先することで 一貫性を保つため、Cosmos のゾーンはトランザクションを高速に処理できます。 為替注文トランザクションと IBC token への送金の両方 そして他のゾーンからも。 今日の暗号通貨取引所の状況を考えると、 Cosmos のアプリケーションは分散型交換 (別名、 Cosmos DEX)。トランザクションのスループット容量と コミットのレイテンシは集中型のレイテンシと同等になる可能性があります 交換。トレーダーは実行可能な指値注文を送信できます 双方がオンラインである必要はありません。そしてテンダーミントと一緒に、 Cosmos ハブと IBC では、トレーダーは資金を出入りできます。 他のゾーンとの間のやり取りをスピーディーに行います。 特権ゾーンは、ブリッジされた token のソースとして機能できます。 別の暗号通貨。橋は関係に似ています Cosmos ハブとゾーンの間。両方ともそれに追いつく必要があります token が持っている証拠を検証するために、他のブロックの最新ブロック 一方からもう一方へ移動しました。 Cosmos の「ブリッジゾーン」 ネットワークはハブおよび他のハブとの通信を維持します
暗号通貨。ブリッジゾーンを介した間接化により、 シンプルであり、他のものにとらわれないハブのロジック blockchain コンセンサス戦略 (Bitcoin の proof-of-work など) 採掘。 各ブリッジゾーン validator は、Tendermint を利用した blockchain と特別な ABCI ブリッジ アプリだけでなく、 「起源」blockchain。 新しいブロックがオリジン、ブリッジゾーンでマイニングされると、 validator は、署名することでコミットされたブロックについて合意します。 そして、オリジンのblockchainについてのそれぞれのローカルな見解を共有します ヒント。ブリッジゾーンがオリジンで支払いを受け取ったとき（そして この事件では十分な確認が見られたことが合意された Ethereum や Bitcoin などの PoW チェーンの)、対応する アカウントはその残高を使用してブリッジ ゾーンに作成されます。 Ethereum の場合、ブリッジ ゾーンは同じものを共有できます。 validator - Cosmos ハブとして設定されます。 Ethereum 側 ( オリジン）、ブリッジコントラクトにより、イーサ所有者はイーサを送信できるようになります 上のブリッジコントラクトに送信することでブリッジゾーンに送信します。 Ethereum。イーサがブリッジコントラクトによって受信されると、 適切な IBC パケットが送信されない限り、イーサを引き出すことはできません。 ブリッジゾーンからブリッジコントラクトによって受信されます。の Bridge-contract は、ブリッジ ゾーンの validator-set を追跡します。 Cosmos ハブの validator セットと同一である可能性があります。 Bitcoin の場合、概念は似ていますが、次の点が異なります。 単一のブリッジ コントラクトの場合、各 UTXO は マルチシグネチャ P2SH 公開スクリプトのしきい値。の制限により、 P2SH システムでは、署名者が Cosmos と同一であってはなりません ハブ validator セット。ブリッジゾーン上のイーサ (「ブリッジイーサ」) は、 ハブから送信され、その後、トランザクションによって破棄されます。 Ethereum の特定の出金アドレスに送信します。 IBC トランザクションがブリッジゾーンで発生したことを証明するパケット Ethereum ブリッジ コントラクトに投稿して、イーサを許可することができます 撤回されること。 Bitcoin の場合、制限されたスクリプト システムにより、 IBC コイン転送メカニズムを反映するのは困難です。それぞれ UTXO には独自の独立した pubscript があるため、すべての UTXO は のセットに変更があると、新しい UTXO に移行されます。 Bitcoin エスクロー署名者。解決策の 1 つは、圧縮して、 必要に応じて UTXO セットを解凍して合計数を維持します UTXO 件ダウンしました。 このようなブリッジ契約のリスクは、不正な validator セットです。 ≥1/3 ビザンチンの投票権によりフォークが発生し、イーサが撤退する可能性がある ブリッジゾーンにブリッジデザーを維持しながら、Ethereum のブリッジ契約から。さらに悪いことに、2/3 を超えるビザンチンの投票権は、 ブリッジコントラクトにイーサを送った人から完全にイーサを盗む ブリッジ ゾーンの元のブリッジング ロジックから逸脱することによって。 ブリッジを次のように設計することで、これらの問題に対処することが可能です。 完全に責任がある。たとえば、ハブからのすべての IBC パケットと、 発信元は、ブリッジ ゾーンによる確認を必要とする場合があります。 これにより、ブリッジ ゾーンのすべての状態遷移が可能になります。 ハブまたはオリジンのいずれかによって効率的に挑戦され、検証される ブリッジ契約。ハブとオリジンでは、ブリッジゾーン validator が担保をポストし、token がブリッジゾーンから転送できるようにする必要があります。 ブリッジ契約は遅らせる必要がある（そして担保解除） 十分に長い期間） 独立監査人。仕様のデザインはお任せしますので、 このシステムの実装は将来的にオープンです Cosmos
改善提案、Cosmos ハブによって可決される予定 ガバナンスシステム。 スケーリングの問題の解決は、Ethereum にとって未解決の問題です。 現在、Ethereum ノードはすべてのトランザクションを処理し、 すべての状態も保存します。リンク。 Tendermint は Ethereum よりもはるかに速くブロックをコミットできるため、 Tendermint コンセンサスを活用した proof-of-work、EVM ゾーンと ブリッジイーサ上で動作すると、より高いパフォーマンスを提供できます。 Ethereum blockchain 秒。さらに、Cosmos ハブと IBC パケットの仕組みでは、任意のコントラクト ロジックが許可されていません 実行自体は、token の動きを調整するために使用できます。 異なるゾーンで実行されているEthereumコントラクト間、 token 中心の Ethereum スケーリングの基盤を提供します。 シャーディング。 Cosmos ゾーンは、任意のアプリケーション ロジックを実行します。 ゾーンの寿命の始まりであり、更新される可能性があります 時間の経過とともにガバナンスによって。このような zexibility により、Cosmos ゾーンは次のことを行うことができます。 Ethereum や Bitcoin、およびそれらの blockchain の派生物も許可されます。 同じコードベースを利用しますが、異なる validator セットを使用し、 初期配布。これにより、多くの既存の暗号通貨が利用可能になります。 Ethereum、Zerocash、Bitcoin などのフレームワーク、 Tendermint Core で使用する CryptoNote など。 共通のネットワーク上の、より高性能なコンセンサス エンジン、 相互運用性の大きな機会を開く プラットフォーム。さらに、マルチアセット blockchain として、単一の トランザクションには複数の入力と出力が含まれる場合があります。 入力は任意の token タイプにすることができ、Cosmos を直接として機能させることができます。 注文が前提となりますが、分散型取引所のプラットフォーム他のプラットフォーム経由でマッチングされます。あるいは、ゾーンでサービスを提供することもできます。 分散型フォールトトレラント取引所 (オーダーブック付き) として、 既存の集中型を大幅に改善できる 時間の経過とともにハッキングされる傾向にある暗号通貨取引所。 ゾーンは、blockchain をサポートするエンタープライズ バージョンとしても機能します 政府システムでは、特定のサービスの一部が 伝統的に組織または組織のグループによって運営されている 代わりに、特定のゾーンで ABCI アプリケーションとして実行されます。 パブリックのセキュリティと相互運用性を継承できるようにします。 Cosmos 基盤となるネットワークの制御を犠牲にすることなくネットワークを構築 サービス。したがって、Cosmos は、両方の長所を提供する可能性があります。 blockchain テクノロジーの利用を検討しているが、どのような組織が利用を検討しているのか 分散したサードパーティに制御を完全に手放すことには慎重である パーティー。 一貫性を重視することに大きな問題があると主張する人もいます Tendermint のようなコンセンサス アルゴリズムは、どのネットワークでも
2/3 の単一パーティションが存在しないパーティション 投票力（例：1/3以上の議決権）があれば、コンセンサスは完全に停止します。 Cosmos アーキテクチャは、次のようにしてこの問題を軽減できます。 地域自治区を備えたグローバルハブであり、そこに投票権がある 各ゾーンは共通の地理に基づいて分散されます 地域。たとえば、共通のパラダイムは個人向けのものかもしれません。 都市や地域は、ゾーンを共有しながら独自のゾーンを運営することができます。 共通ハブ (例: Cosmos ハブ)、地方自治体の活動を可能にします。 一時的なネットワークが原因でハブが停止した場合でも持続します。 パーティション。これにより、実際の地質学的、政治的、および 堅牢な設計で考慮すべきネットワーク トポロジーの特徴 フェデレーテッド・フォールト・トレラント・システム。
NameCoin は、問題の解決を試みた最初の blockchain の 1 つです。 Bitcoin blockchain を適応させることによる名前解決の問題。 残念ながら、このアプローチにはいくつかの問題がありました。 Namecoin を使用すると、たとえば @さとし が 過去のある時点で特定の公開鍵を使用して登録されている、 しかし、公開鍵がその後に作成されたかどうかはわかりません。 前回以降のすべてのブロックをダウンロードしない限り、最近更新されました その名前の更新。これは、Bitcoin の制限によるものです。 UTXO トランザクション マークル化モデル。 トランザクション (ただし変更可能なアプリケーション状態ではない) はマークル化されています ブロック-hashに。これにより、名前の存在は証明できますが、その後の名前の更新が存在しないことは証明できません。したがって、私たちはそれを知ることができません 完全な名前を信頼せずに、名前の最新の値を確認する ノードを削除したり、ダウンロードによって帯域幅に多大なコストが発生したりする blockchain 全体。 たとえマークル化された検索木がNameCoinに実装されたとしても、 proof-of-work への依存性により、クライアント検証が軽量になります 問題のある。ライトクライアントは、完全なコピーをダウンロードする必要があります。 blockchain 全体 (または少なくともすべてのブロック) のすべてのブロックのヘッダー 名前の最後の更新以降のヘッダー）。これは、 帯域幅要件は時間に応じて直線的に増加します [21]。さらに、proof-of-work blockchain の名前変更 追加の proof-of-work 確認ブロックを待つ必要があります。 Bitcoin では最大 1 時間かかる場合があります。 Tendermint を使用する場合、必要なのは最新のブロックだけです-hash validators の定足数 (投票権による) およびマークルによって署名されています。 名前に関連付けられた現在の値を証明します。これでできます 簡潔、迅速、安全なライトクライアントが可能 名前の値の検証。 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 のように イーサ、アトムは取引手数料の支払いにも使用できます。 スパムを軽減します。追加のインザショナルアトムとブロックトランザクション 料金はvalidator と委任者に報酬として支払われます。 validator秒。 BurnAtomTx トランザクションを使用すると、あらゆるデータを復元できます。 リザーブ プールから比例量の token を取得します。 Genesis 上のアトム 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 validator秒で解決します。 まだアトム所有者になっていない人は、次の方法で validator になれます。 BondTx トランザクションに署名して送信します。の量 担保として提供される原子はゼロ以外でなければなりません。誰でもなれる 現在のサイズが変更された場合を除き、いつでも 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 は良好な地位を失うことになります およびその結合原子とそれに比例する token の割合 リザーブプール（総称して「ステーク」と呼ばれます）は削減されます。 地域によっては、validator が利用できない場合があります。 ネットワークの中断、停電、またはその他の理由。もし、いずれにしても 過去の ValidatorTimeoutWindow ブロック、validator のポイント コミット投票は blockchain に含まれていません ValidatorTimeoutMaxAbsent 回、validator になります 非アクティブになり、ValidatorTimeoutPenalty (デフォルト 1%) が失われます。 賭け金。 一部の「悪意のある」動作は、明らかに識別できるものを生成しない blockchain に関する証拠。このような場合、validator は次のことができます。 帯域外を調整して、これらの悪意のあるメッセージを強制的にタイムアウトさせます。 validators、超過半数の合意がある場合。 Cosmos ハブが 1/3 以上の連合により停止した場合 議決権が失われるか、連立政権が 1/3 以上になる状況 投票力が悪意のある行動の証拠を検閲する blockchain に入ると、ハブはハードフォークで回復する必要があります 再編成提案。 (「フォークと検閲攻撃」へのリンク)。 Cosmos ハブ validator は、任意の token タイプまたは組み合わせを受け入れることができます 取引を処理するための手数料としての種類。それぞれのvalidatorは、 希望する為替レートを主観的に設定し、選択する BlockGasLimit が設定されている限り、どのようなトランザクションでも可能です。 超えていない。徴収された料金から以下に指定される税金を差し引いたもの、 に比例して保税利害関係者に再分配されます。 それらの結合原子、すべての ValidatorPayoutPeriod (デフォルト 1) 時間）。徴収された取引手数料のうち、ReserveTax（デフォルト 2%）は、 リザーブプールに向かってリザーブプールを増やし、 Cosmos ネットワークのセキュリティと価値を高めます。これら 決定に従って資金を分配することもできる ガバナンスシステムによって作られます。 投票権を他の validator に委任する Atom 保有者 委任されたvalidatorに手数料を支払います。委員会ができることは、 各 validator によって設定されます。 Cosmos ハブのセキュリティは、ハブのセキュリティの関数です。 基礎となる validator と委任者による委任の選択。 発見物の発見と早期通報を促すため Cosmos ハブはハッカーに脆弱性を公開することを奨励しています ReportHackTx トランザクションによるエクスプロイトの成功。 validator がハッキングされました。このアドレスに報奨金を送ってください。」次第 このようなエクスプロイトでは、validator と委任者が非アクティブになります。 全員の原子の HackPunishmentRatio (デフォルト 5%) が取得されます。 スラッシュ、および全員のアトムの HackRewardRatio （デフォルトは 5%） ハッカーの報奨金アドレスに報酬が与えられます。 validator バックアップ キーを使用して残りの原子を回復する必要があります。 この機能を悪用して転送することを防ぐため 権利確定されていないアトム、権利確定済みアトムと権利確定されていないアトムの部分 ReportHackTx の前後の validator と委任者は、 変更はなく、ハッカーの報奨金にはいくらかが含まれます 権利が付与されていない原子 (存在する場合)。 Cosmos ハブは、分散組織によって運営されています。 そのためには綿密なガバナンスメカニズムが必要です 変数など、blockchain に対するさまざまな変更を調整します。
システムのパラメータ、ソフトウェアのアップグレード、 憲法改正。 すべての validator は、すべての提案に投票する責任があります。失敗 提案に適時に投票すると、validator となります。 と呼ばれる一定期間、自動的に非アクティブ化されます。 欠勤ペナルティ期間（デフォルトは 1 週間）。 委任者は、委任された人の投票を自動的に継承します。 validator。この投票は手動で上書きできます。結合していない原子 票が得られない。 各提案には MinimumProposalDeposit のデポジットが必要です token、1 つ以上の token の組み合わせである場合があります 原子も含めて。各提案について、有権者は賛成票を投じることができます。 預金。有権者の半数以上が採用を選択した場合、 デポジット (例: 提案がスパムであったため)、デポジットは次の宛先に送られます。 燃焼する原子を除いたリザーブプール。 各提案について、有権者は次のオプションを選択して投票できます。 そうだね そう、フォースとともに いや ノーウィズフォース 棄権する 賛成票または YeaWithForce 票の厳密過半数 (または反対票、または 提案が次のように決定されるには、NayWithForce 票）が必要です。 可決された（または不合格と決定された）が、1/3 以上が過半数を拒否できる 「強制力」による投票による決定。厳密多数派が拒否権を発動すると、 拒否権ペナルティフィーブロックを失うと全員が罰せられます (デフォルトの 1 日分のブロック) 相当の料金 (税金を除く) 影響を受けません）、および過半数を拒否権を発動した政党
この決定は、VetoPenaltyAtoms を失うことでさらに罰せられます。 (デフォルトでは 0.1%) の原子。 ここで定義されているパラメータはどれも、 ParameterChangeProposal を渡す。 アトムを注入し、プール資金を使用してリザーブすることができます。 BountyProposal の可決。 プロトコルをアップグレードする提案など、他のすべての提案は、 一般的な TextProposal を介して調整されます。 計画を参照してください。 blockchain コンセンサスには多くの革新があり、 過去数年間の拡張性。このセクションでは概要を説明します 選ばれた数の重要なものについての調査。 悪意のある参加者がいる場合の合意形成が問題となる レスリー・ランポートが造語した1980年代初頭に遡ります。 「ビザンチン障害」というフレーズは、任意のプロセスの動作を指します。 「クラッシュ障害」とは対照的に、意図した動作から逸脱します。 この場合、プロセスは単にクラッシュします。早期の解決策が発見されました 上限がある同期ネットワークの場合メッセージ遅延、ただし実際の使用は非常に限られていました 飛行機の管制官などの制御された環境 データセンターは原子時計によって同期されます。まではそうではありませんでした 90 年代後半、実用的なビザンチン フォールト トレランス (PBFT) [11] は 効率的な部分同期コンセンサスとして導入 最大 1/3 のプロセスの動作を許容できるアルゴリズム 勝手に。 PBFT は標準アルゴリズムとなり、多くのアルゴリズムが生成されました バリエーションの一部として IBM によって作成された最新のものを含む 彼らの Hyperledger への貢献。 PBFT に対する Tendermint のコンセンサスの主な利点は、 Tendermint の基本構造は改良され、簡素化されています。 その一部は、blockchain パラダイムを採用した結果です。 Tendermint ブロックは順番にコミットする必要があるため、 PBFT に関連する複雑さと通信オーバーヘッド 視点の変化。 Cosmos および多くの暗号通貨では、 ブロック N の場合、ブロック N+i (i >= 1) のコミットを許可する必要がある それ自体はまだコミットしていません。帯域幅が 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の研究と導入に大きく貢献 blockchain、特に「委任された」PoS として知られるもの。で BitShares、利害関係者は注文の責任を負う「証人」を選出 トランザクションのコミット、および責任を負う「代理人」 ソフトウェアのアップデートやパラメータの変更を調整します。 BitShares2.0 は、高性能 (100k tx/s、1s) の達成を目指しています。 レイテンシ)、理想的な状態では、各ブロックは単一の署名によって署名されます。 署名者、およびトランザクションの性質に比べてかなり長い時間がかかります ブロック間隔。正規の仕様はまだ開発中です。 利害関係者は、不正行為を行った証人を削除または置き換えることができます。 日常的に行われているが、証人や重要な証拠は存在しない。 Tendermint PoS に似たデリゲータが切り込まれる 二重支出攻撃が成功した場合。 リップルが開拓したアプローチに基づいて、Stellar [13] は プロセスが行われる連邦ビザンチン協定のモデル コンセンサスへの参加は、yxed を構成せず、グローバルに行われます。 既知のセット。むしろ、各プロセス ノードは 1 つ以上のプロセスをキュレートします。 「クォーラム スライス」。それぞれが信頼できるプロセスのセットを構成します。あ Stellar の「クォーラム」は、以下を含むノードのセットであると定義されています。 セット内のノードごとに少なくとも 1 つのクォーラム スライス。 合意に達することができる。 Stellar メカニズムのセキュリティは次の仮定に依存しています。 任意の 2 つの定足数の共通部分が空ではないこと、 ノードの可用性には、少なくとも 1 つのクォーラム スライスが必要です。 完全に正しいノードで構成されているため、 バランスを取るのが難しい大小のクォーラム スライスを使用する 信頼について重大な仮定を課すことなく。最終的には、ノードは何らかの方法で適切なクォーラム スライスを選択する必要があります。 十分なフォールト トレランス (またはすべての「無傷のノード」) であること 論文の結果の多くはそれに依存します)、そして唯一の このような構成が階層的であることを保証するために提供された戦略 ボーダー ゲートウェイ プロトコル (BGP) に似ています。インターネット上の一流 ISP がグローバル ルーティング テーブルを確立するために使用します。 TLS 証明書を管理するためにブラウザによって使用されるもの。どちらも悪名高い 彼らの不安のために。 Tendermint ベースのプルーフオブステーク システムに対する Stellar 論文の批判は、説明されている token 戦略によって軽減されます。 ここでは、アトムと呼ばれる新しいタイプの token が発行されます。 料金および報酬の将来の部分に対する請求を表します。の したがって、Tendermint ベースの proof-of-stake の利点は相対的なものになります。 シンプルでありながら、十分かつ証明可能なセキュリティを提供します 保証します。 BitcoinNG は、Bitcoin に対する改善提案です。 ブロックサイズの増加などの垂直方向のスケーラビリティの形式の場合、 通常伴う経済的悪影響を伴うことなく、 このような変化により、不釣り合いに大きな影響が生じる場合 小規模な鉱山労働者について。この改善は、分離することで達成されます。 トランザクション ブロードキャストからのリーダー選挙: リーダーは初めてです 「マイクロブロック」内のproof-of-workによって選出され、次のことが可能になります 新しいマイクロブロックまでコミットされるブロードキャスト トランザクション が見つかりました。これにより、必要な帯域幅要件が軽減されます。 PoW レースに勝利し、小規模マイナーがより公平に競争できるようになり、 そして、トランザクションをより定期的にコミットできるようになります。 マイクロブロックを見つけた最後のマイナー。 Casper [16] は、提案されている proof-of-stake コンセンサス アルゴリズムです。 Ethereum。その主要な動作モードは「コンセンサス・バイ・ベット」です。によって validator に、どのブロックがそうなると信じているかを繰り返し賭けさせます。
他の賭けに基づいて blockchain にコミットするようになる 彼らがこれまでに見てきたことを踏まえれば、最終的にはイナリティが達成されるでしょう。リンク。 これは、Casper チームによる活発な研究分野です。の 課題は、 進化的に安定した戦略であることが証明されています。主なメリットは Tendermint と比較した Casper は、「可用性」を提供している可能性があります。 「一貫性を超えています」 – コンセンサスには 2/3 を超える定足数は必要ありません 投票力 – おそらくコミット速度や 実装の複雑さ。 Interledger Protocol [14] は、厳密にはスケーラビリティ ソリューションではありません。それ 異なる台帳間のアドホックな相互運用を提供します 疎結合された二国間関係ネットワークを介したシステム。 ライトニング ネットワークと同様に、ILP の目的は、 支払いですが、特に異種間での支払いに焦点を当てています 台帳タイプを定義し、アトミック トランザクション メカニズムを次のように拡張します。 hash ロックだけでなく、公証人の定足数 (と呼ばれる) も含まれます。 原子輸送プロトコル)。後者のメカニズムは、 台帳間トランザクションにアトミック性を強制することは、 Tendermint のライトクライアント SPV メカニズムの図 ILP と Cosmos/IBC の区別は保証されています。 以下に提供されます。 1. ILP のコネクターの公証人はメンバーシップをサポートしていません 変化し、その間のゼクシブルな重み付けは許可されません。 公証人。一方、IBC は、特に次の目的のために設計されています。 blockchains、validators は異なる重みを持つことができます。 途中でメンバーが変更される可能性がある場合 blockchain。 2. ライトニングネットワークと同様に、ILP での支払いの受取人 送信者に確認を返信するにはオンラインである必要があります。でtoken は、受信機の validator セットである IBC 経由で転送します。 blockchain は確認を提供する責任を負います。 受信側ユーザー。 3. 最も顕著な違いは、ILP のコネクタが 支払いに関して責任を負う、または権威ある状態を維持する、 一方、Cosmos では、ハブの validator が権限を持ちます。 IBC token の州と権限が移転します。 各ゾーンが保持する token の量 (ただし、 token はゾーン内の各アカウントによって保持されます)。これは、 安全な非対称を可能にする根本的な革新 ゾーンからゾーンへの 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 秒に関するものです。モーブはスケーリングに関するものです 一般的な計算。 Cosmos は EVM にバインドされていないため、異なる VM であってもバインドできます。 相互運用します。 Cosmos ゾーン作成者は、ゾーンを誰が検証するかを決定できます。 ゾーン。 誰でも Cosmos で新しいゾーンを開始できます (ガバナンスがない限り) それ以外の場合は判断します）。 ハブはゾーン障害を分離するため、グローバル token 不変条件は 保存されています。 ライトニング ネットワークは、提案されている token 転送ネットワークです Bitcoin blockchain (および他のパブリック blockchains)、桁違いの改善が可能になります トランザクションの大部分を移動することにより、トランザクション スループットが低下します コンセンサス台帳の外にある、いわゆる「支払いチャネル」にアクセスします。これは、オンチェーンの暗号通貨スクリプトによって可能になります。 当事者が二国間でステートフルな契約を締結できるようにします。 デジタル署名と契約を共有することで状態を更新できます 最終的に証拠をblockchainに公開することで解決できます。 このメカニズムはクロスチェーンアトミックスワップによって初めて普及しました。によって 多くの関係者や参加者との決済チャネルを開く ライトニング ネットワークは、ルーティングの中心となることができます。 他者の支払い、完全に接続された支払いチャネルにつながる 資本が支払いチャネルに拘束されるという代償を払って、ネットワークにアクセスできなくなります。 ライトニング ネットワークは、さまざまな場所に簡単に拡張することもできます。 値の転送を可能にする複数の独立した blockchain 為替市場を介して非対称的に使用することはできません。 token を blockchain から別の blockchain に転送します。主なメリット ここで説明する Cosmos ネットワークのは、そのような直接を有効にすることです。 token は転送します。とはいえ、私たちは支払いチャネルと ライトニングネットワークは当社の token 転送メカニズム。コスト削減とプライバシー上の理由から。 Segregated Witness は 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，而定期、更频繁的块提交允许 垂直缩放也是如此。
コンセンサスと技術的詳細
適切に設計されたコンセンサスプロトコルは、いくつかの機能を提供する必要があります。 許容範囲を超えた場合の保証 そしてコンセンサスは失敗します。これは経済面で特に必要です ビザンチンの行動が重大な経済的影響を与える可能性があるシステム 報酬。このような保証の中で最も重要なのは、責任追及の一形態であり、コンセンサスを引き起こしたプロセスが 失敗 (つまり、プロトコルのクライアントが異なる値を受け入れる原因となった - フォーク）は特定され、規則に従って処罰される可能性があります。 議定書、あるいは場合によっては法制度。法制度が整うと、 validators は信頼性が低いか、呼び出しコストが高すぎるため、 参加するために保証金の預け入れを強制される、および 悪意のある行為があった場合、預金は取り消されるか、削減される可能性があります。 [10] が検出されました。 これは、フォークが定期的に発生する Bitcoin とは異なることに注意してください。 ネットワークの非同期性と ynding の確率的性質によるもの 部分的なhash衝突。多くの場合、悪意のあるフォークは Bitcoin は非同期のためフォークと区別できません。 暗黙的なもの以外のフォーク責任を確実に実装する 孤立したブロックをマイニングするためにマイナーが支払う機会コスト。 投票ステージを PreVote および PreCommit と呼びます。投票できるのは、 特定のブロックまたは Nil の場合。 2/3 を超える PreVote のコレクションを呼び出します 同じラウンド内の単一ブロックの場合はポルカ、および >2/3 のコレクション コミットと同じラウンド内の単一ブロックの PreCommit。 >2/3の場合 同じラウンドで Nil を PreCommit すると、次のラウンドに進みます。 丸い。 プロトコルの厳密な決定論は脆弱性を招くことに注意してください。 欠陥のあるリーダーを検出する必要があるため、同期性を仮定し、
スキップしました。したがって、validator はある程度の時間待機します。 TimeoutPropose、Prevote Nil の前、および の値 TimeoutPropose はラウンドごとに増加します。進行状況 ラウンドの残りの部分は完全に非同期であり、進行状況だけが表示されます。 validator がネットワークの 2/3 以上からの信号を受信すると行われます。実際には、 それを際限なく阻止するには極めて強力な敵が必要となるだろう 弱い同期性の仮定 (コンセンサスの失敗を引き起こす) ブロックをコミットすることはありません）、そうすることでさらに多くのことを行うことができます それぞれの TimeoutPropose のランダムな値を使用して、difycult を実行します。 validator。 追加の制約セットまたはロック ルールにより、 ネットワークは最終的に各高さで 1 つのブロックだけをコミットします。どれでも 複数のブロックをコミットさせる悪意のある試み 特定の高さで識別できます。まず、ブロックの PreCommit そのブロックのポルカの形で、正当性を示す必要があります。 validator がラウンド R_1 ですでにブロックを PreCommit している場合、 彼らはそのブロックに閉じ込められていると言い、ポルカはそれを正当化するために使用されていました ラウンド R_2 の新しい PreCommit はラウンド R_polka に含まれる必要があります ここで、R_1 < R_polka <= R_2。第二に、validator は提案する必要があります および/またはロックオンされているブロックを事前投票します。これらを合わせて、 条件により、validator が事前コミットされないことが保証されます。 正当性として十分な証拠があり、validator が すでに PreCommit は PreCommit に証拠を提供できません 何か他のもの。これにより、安全性と生存性の両方が確保されます。 コンセンサスアルゴリズム。 プロトコルの完全な詳細はここで説明されています。 TendermintPoS では、代替チェーン (フォーク) の存在が 1/3 以上のブロック ヘッダーを同期することを意味するため、すべてのブロック ヘッダーを同期する必要がなくなります。 結合された杭は切断することができます。もちろん、斬撃には必要なものがあるので、 誰かがフォークの証拠を共有した場合、ライトクライアントは保存する必要があります 表示されるブロック hash のコミット。さらに、ライトクライアントvalidator セットへの変更を定期的に同期し続けることができます。 長距離攻撃を避けるため（ただし、他の解決策は 可能です）。 Ethereum と同様の精神で、Tendermint はアプリケーションで次のことを可能にします。 各ブロックにグローバル マークル ルート hash を埋め込み、簡単に許可します 口座残高や金額などの非常に詳細な状態クエリ 契約に保存されているか、または未使用のトランザクションの存在 アプリケーションの性質に応じて出力します。 ブロードキャスト ネットワークのコレクションが十分に復元力があると仮定する および静的 validator セットの場合、blockchain 内の任意のフォークを が検出され、違反したvalidatorの預金が削減されました。これ 2014 年初めに Vitalik Buterin によって最初に提案されたイノベーションは、問題を解決します 他の proof-of-stake の何も問題がない問題 暗号通貨 (関連作品を参照)。ただし、validator が設定されているため、 長期間にわたって元の状態を変更できなければなりません validator はすべて結合解除される可能性があるため、自由に ジェネシスブロックから新しいチェーンを作成し、コストはかかりません 彼らはもう預金をロックされていません。この攻撃はこうなった ショート攻撃とは対照的に、ロングレンジ攻撃（LRA）として知られています。 範囲攻撃。現在結合している validator 人が フォークであるため、罰せられることになります (フォークの責任があると仮定します BFT Tendermint コンセンサスのようなアルゴリズム)。遠距離攻撃は、 proof-of-stake にとって致命的な打撃となると考えられています。 幸いなことに、LRA は次のように軽減できます。まず、 validator を解除する (それにより担保預金を回収する) コンセンサスに参加するための手数料を得ることができなくなります）、 デポジットは一定期間譲渡不能にしなければなりません これは「結合解除期間」として知られており、 数週間または数か月。次に、ライト クライアントを安全にするためには、まず ネットワークに接続するときに、最近のブロックを確認する必要があります-hash 信頼できるソース、またはできれば複数のソースに対して。これ
この状態は「主観性が弱い」と呼ばれることもあります。最後に、 安全を確保するには、次の場所に設定された最新の validator と同期する必要があります。 少なくとも結合解除期間の長さと同じくらいの頻度で。これ ライト クライアントが validator への変更を確実に認識できるようにします。 validator の資本が結合解除され、資本が結合されなくなる前に設定された 危険にさらされているため、次のことを実行してクライアントを欺くことが可能になります。 新しいブロックを作成して遠距離攻撃を開始します。 接着された高さ (十分に制御できると仮定) 初期の秘密鍵の多く）。 この方法で LRA を克服するには、 proof-of-work のオリジナルのセキュリティ モデル。 PoWでは、それは ライトクライアントが現在の高さに同期できることを前提としています。 すべてのブロックヘッダーでproofof workを処理するだけで、いつでも信頼できるジェネシスブロックを作成できます。しかし、LRAを克服するには、 ライトクライアントが一定の規則性を持ってオンラインになることを要求する validator セットの変更を追跡し、最初に変更したとき オンラインになると認証に特に注意する必要があります 信頼できるソースに対してネットワークから聞いたこと。の もちろん、この後者の要件は Bitcoin の要件と似ています。 プロトコルとソフトウェアも信頼できる機関から入手する必要があります。 ソース。 LRA を防止する上記の方法は、validator に適しています。 Tendermint を利用した blockchain のフル ノードは、次のとおりです。 ノードはネットワークに接続されたままになるように設計されています。の この方法は、次のような効果が期待できるライト クライアントにも適しています。 ネットワークと頻繁に同期します。ただし、ライトクライアントの場合は、 インターネットや blockchain ネットワーク、さらに別のソリューションを使用して克服することができます LRA。 validator 以外の token 所有者は、token を次の名前で投稿できます 非常に長い解放期間を持つ担保 (例: 非常に長い) validators の結合解除期間よりも)、ライトクライアントにサービスを提供します 現在のデータの有効性を証明する二次的な方法と 過去のブロック-hashes。これらのtokenは、 blockchain のコンセンサスの安全性が確保されているにもかかわらず、彼らは次のことを行うことができます。ライトクライアントに強力な保証を提供します。過去のブロックの場合-hash クエリは Ethereum でサポートされており、誰でも自分のデータを結合できます。 token を特別に設計された smart contract で提供し、 有料の認証サービスにより、ライトクライアント LRA セキュリティの市場が効果的に創出されます。 ブロックコミットの定義により、すべての ≥1/3 連合は、 投票権は、オフラインになるかどうかによって、blockchain を停止できる可能性があります 彼らの投票をブロードキャストします。このような連合は検閲も行うことができる 特定のトランザクションを含むブロックを拒否することにより、 ただし、これはかなりの割合を占めることになります 拒否されるブロック提案の割合、これにより速度が低下する blockchain のブロック コミットが減少し、その有用性と価値が減少します。 悪意のある連合は、投票を少しずつ放送する可能性もあります。 blockchain ブロックを粉砕する場合、ほぼ停止するか、または開始します。 これらの攻撃のあらゆる組み合わせ。最後に、次のような問題を引き起こす可能性があります。 blockchain は二重署名またはロック違反によりフォークします ルール。 世界的に活動する敵も関与した場合、分断される可能性があります 間違っているように見えるような方法でネットワークに接続する validator のサブセットが速度低下の原因でした。これはそうではありません これは Tendermint の単なる制限ではなく、すべての制限です ネットワークが潜在的に制御されているコンセンサス プロトコル 積極的な敵。 このようなタイプの攻撃の場合、validator のサブセットは次のようにする必要があります。 外部手段を通じて調整し、以下の再編成提案に署名する。 フォーク (およびその証拠) と最初のサブセットを選択します。 validator と署名。このような再組織化提案に署名した検証者は、他のすべてのフォークでの担保を放棄します。クライアントは次のことを行う必要があります。 再編成提案書の署名を検証し、証拠を検証します。 そしてエンドユーザーに判断を下したり、決定を促したりします。のために たとえば、携帯電話のウォレット アプリはユーザーにセキュリティを要求する場合があります。
警告、一方、冷蔵庫はあらゆる再編成提案を受け入れる可能性があります 投票権により元の validator の +1/2 が署名しました。 非同期ビザンチン フォールト トレラント アルゴリズムは実現できません 投票権の 1/3 以上が不正であるにもかかわらず、フォークである場合に合意を形成する 投票権の 1/3 以上が既に不正行為を受けていると仮定します。 正当な理由なく二重署名またはロックを変更すること。ということで、サイン会 reorg-proposal は調整の問題であり、調整することはできません。 非同期プロトコルによって解決されます（つまり、自動的に、 信頼性について仮定を置くことなく、 基礎となるネットワーク)。今のところ、再組織化提案の調整の問題は、社会的合意を介した人間の調整に任せます。 インターネットメディアで。バリデータは、 2 つの再組織提案が同時に署名される状況を避けるため、再組織提案に署名する前にネットワーク パーティションが残っていないこと。 外部調整メディアとプロトコルが 堅牢であるため、フォークは検閲よりも懸念されるということになります。 攻撃します。 フォークと検閲に加えて、1/3 以上の Byzantine が必要です 投票権がある場合、2/3 を超える投票権を有する連合が関与する可能性がある 任意の無効な状態。これはあらゆるものの特徴です (BFT) コンセンサスシステム。フォークを作成する二重署名とは異なります。 簡単に検証できる証拠を用いて、犯罪者の関与を検出します。 無効な状態では、非検証ピアがブロック全体を検証する必要があります。 これは、状態のローカルコピーを保持して実行することを意味します。 各トランザクションでは、ステート ルートを個別に計算します。 自分たち自身。一旦検出されると、そのような障害に対処する唯一の方法 それは社会的合意によるものです。たとえば、Bitcoin のような状況では、 ソフトウェアのバグによるフォークかどうかにかかわらず、失敗しました（3 月の場合と同様） 2013)、またはビザンチン動作による無効な状態のコミット マイナー (2015 年 7 月時点)、よくつながったコミュニティ 企業、開発者、マイナー、その他の組織 手動行為とは何かについての社会的コンセンサスを確立した参加者がネットワークを修復するために必要とするもの。さらに、以来、 テンダーミントの validator blockchain は、 識別可能ですが、無効な状態のコミットメントは、 必要に応じて、法律または外部の判例によって罰せられる可能性があります。 ABCI は、配信される 3 つの主要なメッセージ タイプで構成されます。 アプリケーションのコア。アプリケーションは次のように応答します。 対応する応答メッセージ。 AppendTx メッセージはアプリケーションの主力製品です。それぞれ blockchain のトランザクションは、このメッセージとともに配信されます。の アプリケーションは、受信した各トランザクションを検証する必要があります。 現在の状態、アプリケーション プロトコル、 およびトランザクションの暗号化資格情報。検証済み その後、トランザクションはアプリケーションの状態を更新する必要があります。 値をキー値ストアにバインドするか、UTXO を更新します。 データベース。 CheckTx メッセージは AppendTx に似ていますが、目的は次のとおりです。 トランザクションの検証。 Tendermint Core の mempool の最初のチェック CheckTx によるトランザクションの有効性を確認し、有効なリレーのみを確認します。 ピアへのトランザクション。アプリケーションは増分をチェックする場合があります トランザクション内で nonce が発生し、次の場合は CheckTx でエラーを返します。 nonce は古いです。 Commit メッセージは、暗号化を計算するために使用されます。 現在のアプリケーションの状態に対するコミットメント。 次のブロックヘッダー。これには便利なプロパティがいくつかあります。 その状態を更新する際の不一致は、次のように表示されます。 blockchain プログラミングのクラス全体をキャッチするフォーク エラー。これにより、安全で軽量なシステムの開発も簡素化されます。 Merkle-hash の証明は、クライアントと照合することで検証できます。 ブロック-hashとブロック-hashは定足数によって署名されています。 validators (投票権による)。
追加の ABCI メッセージにより、アプリケーションは次のメッセージを追跡できるようになります。 validator セットを変更し、アプリケーションが 高さやコミット投票などのブロック情報。 ABCI リクエスト/レスポンスは単純な Protobuf メッセージです。チェックする スキーマファイルを外します。 引数: Data ([]byte) : リクエスト トランザクション バイト 戻り値: コード (uint32) : 応答コード Data ([]byte) : 結果のバイト (存在する場合) ログ (文字列) : デバッグまたはエラー メッセージ 使用法:
トランザクションを追加して実行します。トランザクションが有効であれば、 CodeType.OK を返します 引数: Data ([]byte) : リクエスト トランザクション バイト 戻り値: コード (uint32) : 応答コード Data ([]byte) : 結果のバイト (存在する場合) ログ (文字列) : デバッグまたはエラー メッセージ 使用法:
トランザクションを検証します。このメッセージは、 状態。トランザクションはまず CheckTx を介して実行されます。 mempool 層のピアにブロードキャストします。作ることができます CheckTx セミステートフルで、コミット時に状態をクリアするか、 BeginBlock 、トランザクションの依存シーケンスを許可します。 同じブロック内にあります。
戻り値: データ ([] バイト) : マークル ルート hash ログ (文字列) : デバッグまたはエラー メッセージ 使用法:
アプリケーション状態のマークル ルート hash を返します。 引数: Data ([]byte) : クエリリクエストのバイト数 戻り値: コード (uint32) : 応答コード Data ([]byte) : クエリ応答バイト ログ (文字列) : デバッグまたはエラー メッセージ 使用法:
応答キューをフラッシュします。実装するアプリケーション types.Application はこのメッセージを実装する必要はありません。 プロジェクトが担当します。 戻り値: Data ([]byte) : 情報バイト 使用法:
アプリケーションの状態に関する情報を返します。アプリケーション 特定の。 引数: Key (string) : 設定するキー
値（文字列） : キーに設定する値 戻り値: ログ (文字列) : デバッグまたはエラー メッセージ 使用法:
アプリケーションのオプションを設定します。例えば。 Key = “mode”、Value = “mempool” メモリプール接続、または Key=“mode”、Value=“consensus” コンセンサス接続。他のオプションはアプリケーション固有です。 引数: バリデーター ([]バリデーター) : 初期の起源 - validators 使用法:
創世記に一度呼ばれた 引数: Height (uint64) : 開始するブロックの高さ 使用法:
新しいブロックの始まりを知らせます。事前に呼び出される AppendTxs。 引数: Height (uint64) : 終了したブロックの高さ 戻り値: バリデータ ([]バリデータ) : validator を新しいものに変更しました 投票権 (削除するには 0) 使用法:
ブロックの終わりを知らせます。結局、各コミットの前に呼び出されます トランザクション 詳細については、ABCI リポジトリを参照してください。送信者が 受信チェーンによるパケットの配信の確認。 たとえば、送信者はメッセージのステータスを知らない可能性があります。 宛先チェーンに障害があると予想される場合。または、送信者は パケットにタイムアウトを課したい（MaxHeight を使用） パケット イールド）、宛先チェーンは受信パケット数の突然の急増によるサービス拒否攻撃を受ける可能性があります。 パケット。 このような場合、送信者は配送確認を要求できます。 パケットの初期ステータスを「AckPending」に設定します。それから、それは、 受領チェーンには、 アプリ Merkle hash では、IBCPacket と略されます。 まず、IBCBlockCommit と IBCPacketTx が「ハブ」に投稿されます これは、「Zone1」に IBCPacket が存在することを証明します。そう言ってください IBCPacketTx には次の値があります。 FromChainID : “Zone1” FromBlockHeight : 100 (たとえば) パケット: IBCパケット:
ヘッダー: IBCPacketHeader: SrcChainID：「ゾーン1」 DstChainID：「ゾーン2」 数 : 200 (例) ステータス : 確認保留中 種類：「コイン」 MaxHeight : 350 (「ハブ」が現在高さ 300 であるとします) ペイロード : <「コイン」ペイロードのバイト数> 次に、IBCBlockCommit と IBCPacketTx が「Zone2」に投稿されます。 これは、「ハブ」上にIBCパケットが存在することを証明します。そう言ってください IBCPacketTx には次の値があります。 FromChainID : 「ハブ」 ブロックからの高さ : 300 パケット: IBCパケット: ヘッダー: IBCPacketHeader: SrcChainID：「ゾーン1」 DstChainID：「ゾーン2」 数 : 200 ステータス : 確認保留中 種類：「コイン」 最大高さ : 350 ペイロード : <「コイン」ペイロードの同じバイト> 次に、「Zone2」はアプリに短縮パケットを含める必要があります-hash これは、「AckSent」の新しいステータスを示しています。 IBCBlockCommit と IBCPacketTx は存在を証明する「ハブ」にポストバックされます 「Zone2」上の短縮型 IBCパケット 。 IBCPacketTx と言ってください には次の値があります。 FromChainID : “Zone2”
FromBlockHeight : 400 (たとえば) パケット: IBCパケット: ヘッダー : IBCPacketHeader : SrcChainID：「ゾーン1」 DstChainID：「ゾーン2」 数 : 200 ステータス : 送信済み 種類：「コイン」 最大高さ : 350 PayloadHash : <同じ「コイン」ペイロードの hash バイト> 最後に、「ハブ」はパケットのステータスを更新する必要があります。 AckPending から AckReceived まで。この新たな状況の証拠 「Zone2」に戻る必要があります。 IBCPacketTx に次のものがあるとします。 値: FromChainID : 「ハブ」 ブロックの高さから: 301 パケット: IBCパケット: ヘッダー: IBCPacketHeader: SrcChainID：「ゾーン1」 DstChainID：「ゾーン2」 数 : 200 ステータス : 受信確認済み 種類：「コイン」 最大高さ : 350 PayloadHash : <同じ「コイン」ペイロードの hash バイト> 一方、「Zone1」は配信が成功すると楽観的に考える可能性がある 反対の証拠が証明されない限り、「コイン」パケットの 「ハブ」。上の例では、「ハブ」が AckSent を受信していなかった場合
ブロック 350 によって「Zone2」からステータスを取得すると、ステータスが設定されます。 自動的にタイムアウトになります。このタイムアウトの証拠は、 「Zone1」にポストバックされ、token を返すことができます。 では 2 種類の Merkle tree がサポートされています。 Tendermint/Cosmos エコシステム: シンプル ツリーと IAVL+ 木。 シンプル ツリーは、要素の静的リストの Merkle tree です。もし 項目の数は 2 の累乗ではありません。一部の葉は次のようになります。 さまざまなレベル。シンプル ツリーはツリーの両側を維持しようとします。 高さは同じですが、左の方が一つ大きいかもしれません。このMerkle treeは ブロックのトランザクションをマークル化するために使用され、トップレベル アプリケーション状態ルートの要素。IAVL+ データ構造の目的は、永続的なデータ構造を提供することです。 アプリケーション状態のキーと値のペアのストレージ。 決定論的なマークルルート hash を効率的に計算できます。の ツリーは AVL アルゴリズムのバリアントを使用してバランスがとられており、すべて 操作は O(log(n)) です。 AVL ツリーでは、任意のノードの 2 つの子サブツリーの高さ 最大でも 1 つ違います。この条件に違反するたびに、 更新すると、O(log(n)) 個の新しいノードを作成することによってツリーが再バランスされます。 古いツリーの変更されていないノードを指します。オリジナルのAVLでは アルゴリズムでは、内部ノードもキーと値のペアを保持できます。 AVL+ アルゴリズム (プラスに注意してください) すべてを維持するために AVL アルゴリズムを変更します キーを保存するためにブランチノードのみを使用しながら、リーフノードに値を格納します。 これにより、マークル hash の証跡を維持しながらアルゴリズムが簡素化されます。 短い。 AVL+ ツリーは、Ethereum のパトリシアの試みに似ています。あります トレードオフ。キーを挿入する前に hash する必要はありません。 IAVL+ ツリーにより、キー内の順序付けされた反復が高速化されます。 一部のアプリケーションに役立つ可能性のあるスペース。ロジックはもっと簡単です 内部ノードと内部ノードの 2 種類のノードのみが必要な実装です。 葉のノード。マークル証明は平均して短く、 * / \ / \ / \ / \ * * / \ / \ / \ / \ / \ / \ * * * h6 / \ / \ / \ h0 h1 h2 h3 h4 h5 7 つの要素を持つ SimpleTree
バランスの取れた二分木。一方、次のマークル根は、 IAVL+ ツリーは更新の順序に依存します。 次のような追加の効率的な Merkle tree をサポートします。 Ethereum のパトリシア トライは、バイナリ バリアントが次の場合に発生します。 利用可能です。 正規の実装では、トランザクションは Cosmos ハブ アプリケーション (ABCI インターフェイス経由)。 Cosmos ハブは、多数のプライマリ トランザクションを受け入れます タイプ（SendTx、BondTx、UnbondTx、ReportHackTx など）、 SlashTx、BurnAtomTx、ProposalCreateTx、ProposalVoteTx、 これらは非常に一目瞭然であり、次の文書に記載されています。 この文書の将来の改訂。ここでは 2 つの主要な点を文書化します。 IBC のトランザクション タイプ: IBCBlockCommitTx および IBCPacketTx。 IBCBlockCommitTx トランザクションは次のもので構成されます。 ChainID (文字列) : blockchain の ID BlockHash ([]byte) : block-hash バイト、マークル ルート これにはアプリ hash が含まれます BlockPartsHeader (PartSetHeader) : ブロック パーツ セット ヘッダー バイト、投票署名を検証する場合にのみ必要 BlockHeight (int) : コミットの高さ BlockRound (int) : コミットのラウンド Commit ([]Vote) : >2/3 の Tendermint プレコミットが次のことに投票します。 ブロックコミットを構成する ValidatorsHash ([]byte) : 新しいマークルツリー ルート hash validator セット
ValidatorsHashProof (SimpleProof) : BlockHash に対して ValidatorsHash を証明するための SimpleTree Merkleproof
AppHash ([]byte) : の IAVLTree マークルツリー ルート hash
アプリケーションの状態
AppHashProof（SimpleProof）：SimpleTree Merkle-proof
AppHash を BlockHash に対して証明する
IBCパケットは以下で構成されます:
ヘッダー (IBCPacketHeader) : パケット ヘッダー
Payload ([]byte) : パケット ペイロードのバイト数。オプション
PayloadHash ([]byte) : パケットのバイトを表す hash。
オプション
Payload または PayloadHash のいずれかが存在する必要があります。 hash
IBCPacket の は、ヘッダーという 2 つの項目の単純なマークル ルートです。
および ペイロード 。完全なペイロードを含まないIBCパケットは、
短縮されたパケット。
IBCPacketHeader は次のもので構成されます。
SrcChainID (文字列) : ソース blockchain ID
DstChainID (文字列) : 宛先 blockchain ID
Number (int) : すべてのパケットの一意の番号
Status (enum) : AckPending 、 AckSent 、
AckReceived 、 NoAck 、または Timeout
Type (string) : タイプはアプリケーションに依存します。 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-proof
パケットの hash とソース チェーンの AppHash の照合
与えられた高さ
「Zone1」から「Zone2」へパケットを送信するシーケンス
「ハブ」を介した様子を {図 X} に示します。まず、IBCPacketTx
パケットがアプリ状態に含まれていることを「ハブ」に証明します。
「ゾーン1」。次に、別の IBCPacketTx が「Zone2」に対して、
パケットは「Hub」のアプリ状態に含まれます。この間
この手順では、IBCPacket の出力は同一です。SrcChainID は次のとおりです。
常に「Zone1」、DstChainID は常に「Zone2」です。
PacketProof には、次のように正しいマークルプルーフ パスが必要です。
以下に続きます:
「Zone1」が「Hub」を介して「Zone2」にパケットを送信したい場合、
IBCPacket データは、パケットが「Zone1」、「Hub」、または「Zone2」でマークル化されているかどうかに関係なく同一です。唯一変更可能なyieldは、
配送追跡のステータス。
概念化に協力してくれた友人や同僚に感謝します。
Tendermint との取り組みをレビューし、サポートを提供する
そしてCosmos。
IBC/
SkuChain の Zaki Manian は、フォーマットと 特にABCIセクションの下の文言 アルテアのジェハン・トレンバックとダスティン・バイイントンが協力してくれた 初期反復 Honey Badger の Andrew Miller がコンセンサスについてのフィードバックを寄せてくれました 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 リブスウィフト: 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
�� えー
共识和技术细节
一个设计良好的共识协议应该提供一些 超出耐受能力时的保证 并且共识失败。这在经济上尤其必要 系统中，拜占庭行为可能会产生大量的经济影响 奖励。最重要的此类保证是一种责任形式，其中导致共识的过程 失败（即导致协议的客户端接受不同的值 - 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
Ø è