Cosmos: Một mạng lưới sổ cái phân tán

著 Jae Kwon and Ethan Buchman · 2016

導入

オープンソース エコシステムの総合的な成功により、 分散型ファイル共有とパブリック暗号通貨は、 分散型インターネットプロトコルという理解を促した 社会経済インフラを根本的に改善するために使用できます。 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 throughput vs block size benchmarked across 64 nodes in 7 datacenters on 5 continents

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 を提供します。 コンセンサスプロセス。

Giới thiệu

Sự thành công tổng hợp của hệ sinh thái nguồn mở, chia sẻ yle phi tập trung và tiền điện tử công cộng có truyền cảm hứng cho sự hiểu biết rằng các giao thức internet phi tập trung có thể được sử dụng để cải thiện triệt để cơ sở hạ tầng kinh tế xã hội. Chúng tôi đã thấy các ứng dụng blockchain chuyên dụng như Bitcoin [1] (a tiền điện tử), Zerocash [2] (tiền điện tử bảo mật) và nền tảng smart contract tổng quát như Ethereum [3], với vô số ứng dụng được phân phối cho Etherium Virtual Máy (EVM) như Augur (thị trường dự đoán) và TheDAO [4] (câu lạc bộ đầu tư). Tuy nhiên, cho đến nay, blockchain này đã gặp phải một số vấn đề về những hạn chế, bao gồm cả sự kém hiệu quả về năng lượng, kém hoặc hiệu quả hoạt động còn hạn chế và cơ chế quản trị chưa trưởng thành. Đề xuất mở rộng quy mô thông lượng giao dịch của Bitcoin, chẳng hạn như Nhân chứng tách biệt [5] và BitcoinNG [6], có tỷ lệ theo chiều dọc các giải pháp vẫn bị giới hạn bởi khả năng của một thiết bị vật lý duy nhất máy, để đảm bảo tính chất có thể kiểm toán hoàn chỉnh. Lightning Network [7] có thể giúp mở rộng quy mô giao dịch Bitcoin

khối lượng bằng cách loại bỏ hoàn toàn một số giao dịch khỏi sổ cái, và rất phù hợp cho các khoản thanh toán vi mô và bảo vệ quyền riêng tư đường ray thanh toán, nhưng có thể không phù hợp cho tổng quát hơn nhu cầu mở rộng quy mô. Giải pháp lý tưởng là giải pháp cho phép nhiều blockchains song song tương tác trong khi vẫn giữ được các đặc tính bảo mật của chúng. Cái này có đã được chứng minh là khó khăn, nếu không nói là không thể, với proof-of-work. Đã hợp nhất ví dụ: khai thác mỏ cho phép công việc được thực hiện để bảo đảm cấp độ cha mẹ chuỗi được tái sử dụng trên chuỗi con, nhưng các giao dịch vẫn phải được thực hiện được xác thực theo thứ tự theo từng nút và blockchain được khai thác hợp nhất dễ bị tấn công nếu phần lớn nguồn điện hash trên cha mẹ không tích cực khai thác hợp nhất đứa trẻ. Một đánh giá học thuật kiến trúc mạng blockchain thay thế được cung cấp cho bối cảnh bổ sung và chúng tôi cung cấp bản tóm tắt các đề xuất khác và những hạn chế của chúng trong Công việc liên quan. Ở đây chúng tôi giới thiệu Cosmos, một kiến trúc mạng blockchain mới lạ đó giải quyết tất cả những vấn đề này. Cosmos là một mạng lưới gồm nhiều blockchain độc lập, được gọi là vùng. Các khu vực được cung cấp năng lượng bởi Tendermint Core [8], cung cấp hiệu suất cao, công cụ đồng thuận giống như PBFT nhất quán, an toàn, trong đó trách nhiệm phân tách nghiêm ngặt đảm bảo duy trì hành vi độc hại diễn viên. Thuật toán đồng thuận BFT của Tendermint Core rất phù hợp để mở rộng quy mô công khai proof-of-stake blockchains. Vùng đầu tiên trên Cosmos được gọi là Cosmos Hub. Cosmos Hub là một loại tiền điện tử proof-of-stake đa tài sản với cách thức đơn giản Cơ chế quản trị cho phép mạng thích ứng và nâng cấp. Ngoài ra, Cosmos Hub có thể được mở rộng bằng cách kết nối các khu vực khác. Trung tâm và các vùng của mạng Cosmos giao tiếp với với nhau thông qua giao thức liên lạc giữa blockchain (IBC), một loại UDP hoặc TCP ảo cho blockchains. Token có thể chuyển từ vùng này sang vùng khác một cách an toàn và nhanh chóngmà không cần trao đổi thanh khoản giữa các khu vực. Thay vào đó, tất cả các giao dịch chuyển khoản liên vùng token đều đi qua Trung tâm Cosmos. theo dõi tổng số token được nắm giữ bởi mỗi khu vực. các hub cô lập từng vùng khỏi sự thất bại của các vùng khác. Bởi vì bất kỳ ai cũng có thể kết nối một vùng mới với Cosmos Hub, các vùng cho phép để có khả năng tương thích trong tương lai với những cải tiến blockchain mới. Trong phần này chúng tôi mô tả giao thức đồng thuận Tendermint và giao diện được sử dụng để xây dựng các ứng dụng với nó. Để biết thêm chi tiết xem phụ lục. Trong thuật toán chịu lỗi Byzantine cổ điển (BFT), mỗi nút có cùng trọng lượng. Trong Tendermint, các nút có giá trị không âm số lượng quyền biểu quyết và các nút có biểu quyết tích cực sức mạnh được gọi là validators. Người xác nhận tham gia vào giao thức đồng thuận bằng cách phát sóng chữ ký mật mã, hoặc phiếu bầu, để thống nhất khối tiếp theo. Quyền biểu quyết của người xác nhận được xác định ngay từ đầu hoặc được thay đổi một cách xác định bởi blockchain, tùy thuộc vào ứng dụng. Ví dụ: trong ứng dụng proof-of-stake chẳng hạn như Trung tâm Cosmos, quyền biểu quyết có thể được xác định bởi số tiền staking token được thế chấp làm tài sản thế chấp. LƯU Ý: Các phân số như ⅔ và ⅓ đề cập đến các phân số của tổng số phiếu bầu công suất, không bao giờ là tổng số validator giây, trừ khi tất cả validators có trọng lượng bằng nhau. >⅔ có nghĩa là “hơn ⅔”, ≥⅓ có nghĩa là “ít nhất ⅓”. Tendermint là giao thức đồng thuận BFT đồng bộ một phần bắt nguồn từ thuật toán đồng thuận DLS [20]. bạc hà là

đáng chú ý vì tính đơn giản, hiệu suất và trách nhiệm giải trình của nó. Giao thức yêu cầu một tập hợp validator đã biết yxed, trong đó mỗi validator được xác định bằng khóa chung của họ. Người xác thực cố gắng đạt được sự đồng thuận về từng khối một, trong đó khối là một danh sách của các giao dịch. Việc bỏ phiếu cho sự đồng thuận về một khối tiến hành trong vòng. Mỗi vòng có một người đứng đầu hoặc người đề xuất, người này đề xuất một khối. Sau đó, validator sẽ bỏ phiếu theo từng giai đoạn về việc liệu chấp nhận khối được đề xuất hoặc chuyển sang vòng tiếp theo. các người đề xuất cho một vòng được chọn một cách xác định từ thứ tự danh sách validator, tương ứng với quyền biểu quyết của họ. Các chi tiết đầy đủ của giao thức được mô tả ở đây. Tính bảo mật của Tendermint bắt nguồn từ việc sử dụng Byzantine tối ưu khả năng chịu lỗi thông qua biểu quyết siêu đa số (>⅔) và khóa cơ chế. Cùng nhau, họ đảm bảo rằng: ≥⅓ quyền biểu quyết phải thuộc về Byzantine mới có thể vi phạm an toàn, trong đó có nhiều hơn hai giá trị được cam kết. nếu bất kỳ tập hợp validator nào vi phạm an toàn thành công hoặc thậm chí cố gắng làm như vậy, chúng có thể được xác định bởi giao thức. Cái này bao gồm cả việc bỏ phiếu cho các khối xung đột và phát sóng số phiếu không chính đáng. Mặc dù có sự đảm bảo mạnh mẽ, Tendermint vẫn mang đến những điều đặc biệt hiệu suất. Trong điểm chuẩn của 64 nút được phân bổ trên 7 trung tâm dữ liệu trên 5 châu lục, trên các phiên bản đám mây hàng hóa, Sự đồng thuận của Tendermint có thể xử lý hàng nghìn giao dịch mỗi lần thứ hai, với độ trễ cam kết theo thứ tự từ một đến hai giây. Đáng chú ý là hiệu suất của hơn một nghìn giao dịch trên mỗi thứ hai được duy trì ngay cả trong điều kiện đối nghịch khắc nghiệt, với validator bị lỗi hoặc phát đi các phiếu bầu được tạo ra một cách độc hại. Xem ygure bên dưới để biết chi tiết.

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

Lợi ích chính của thuật toán đồng thuận của Tendermint được đơn giản hóa bảo mật khách hàng nhẹ, làm cho nó trở thành một ứng cử viên lý tưởng cho thiết bị di động và các trường hợp sử dụng internet của vạn vật. Trong khi ứng dụng khách nhẹ Bitcoin phải đồng bộ hóa chuỗi tiêu đề khối và tìm chuỗi có nhiều bằng chứng nhất về hoạt động, khách hàng của Tendermint chỉ cần theo kịp các thay đổi đến bộ validator, sau đó xác minh >⅔ Cam kết trước trong khối mới nhất để xác định trạng thái mới nhất. Bằng chứng ứng dụng khách ngắn gọn cũng cho phép inter-blockchain giao tiếp. Tendermint có các biện pháp bảo vệ để ngăn ngừa một số các cuộc tấn công đáng chú ý, chẳng hạn như chi tiêu gấp đôi tầm xa mà không bị đe dọa và kiểm duyệt. Những vấn đề này sẽ được thảo luận đầy đủ hơn trong phần phụ lục.Thuật toán đồng thuận Tendermint được triển khai theo cách chương trình có tên Tendermint Core. Tendermint Core là một "công cụ đồng thuận" bất khả tri về ứng dụng có thể biến bất kỳ ứng dụng hộp đen xác định thành một bản sao phân tán blockchain. Tendermint Core kết nối với blockchain ứng dụng thông qua Giao diện chuỗi khối ứng dụng (ABCI) [17]. Vì vậy, ABCI cho phép các ứng dụng blockchain được lập trình ở bất kỳ ngôn ngữ, không chỉ là ngôn ngữ lập trình mà sự đồng thuận công cụ được ghi vào. Ngoài ra, ABCI giúp bạn có thể dễ dàng hoán đổi lớp đồng thuận của bất kỳ ngăn xếp blockchain hiện có nào. Chúng tôi rút ra sự tương tự với tiền điện tử nổi tiếng Bitcoin. Bitcoin là tiền điện tử blockchain trong đó mỗi nút duy trì cơ sở dữ liệu Đầu ra giao dịch chưa chi tiêu (UTXO) đã được kiểm tra đầy đủ. Nếu người ta muốn tạo một hệ thống giống Bitcoin trên ABCI, Tendermint Core sẽ chịu trách nhiệm Chia sẻ khối và giao dịch giữa các nút Thiết lập một trật tự giao dịch chuẩn/bất biến (các blockchain) Trong khi đó, ứng dụng ABCI sẽ chịu trách nhiệm Duy trì cơ sở dữ liệu UTXO Xác thực chữ ký mật mã của các giao dịch Ngăn chặn các giao dịch chi tiêu các khoản tiền không tồn tại Cho phép khách hàng truy vấn cơ sở dữ liệu UTXO Tendermint có thể phân hủy thiết kế blockchain bằng cách cung cấp một API rất đơn giản giữa quá trình đăng ký và quá trình đồng thuận.

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 がある場合、

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

と「ハブ」。「ゾーン 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 Kiến trúc

Cosmos là mạng gồm các blockchains song song độc lập mỗi cái được hỗ trợ bởi các thuật toán đồng thuận BFT cổ điển như Bạc hà dịu dàng 1. blockchain năm đầu tiên trong mạng này sẽ là Cosmos Hub. các Cosmos Hub kết nối với nhiều blockchain (hoặc vùng) khác thông qua giao thức truyền thông liên blockchain mới. Trung tâm Cosmos theo dõi nhiều loại token và lưu giữ bản ghi tổng số số token trong mỗi vùng được kết nối. Token có thể chuyển từ vùng này sang vùng khác một cách an toàn và nhanh chóng mà không cần trao đổi chất lỏng giữa các vùng, bởi vì tất cả Chuyển tiền liên vùng đi qua Trung tâm Cosmos. Kiến trúc này giải quyết được nhiều vấn đề mà không gian blockchain phải đối mặt ngày nay, chẳng hạn như khả năng tương tác ứng dụng, khả năng mở rộng và khả năng nâng cấp liền mạch. Ví dụ: các vùng bắt nguồn từ Bitcoind, Go-Ethereum, CryptoNote, ZCash hoặc bất kỳ hệ thống blockchain nào đều có thể được cắm vào Cosmos Hub. Những vùng này cho phép Cosmos mở rộng quy mô một cách vô tận để đáp ứng nhu cầu giao dịch toàn cầu. Các khu vực cũng một yt tuyệt vời cho một sàn giao dịch phân tán, sẽ được hỗ trợ như tốt. Cosmos không chỉ là một sổ cái phân tán duy nhất và Cosmos Hub không phải là một khu vườn có tường bao quanh hay trung tâm vũ trụ của nó. Chúng tôi là thiết kế một giao thức cho một mạng lưới sổ cái phân tán mở có thể đóng vai trò là nền tảng mới cho các hệ thống tài chính trong tương lai, dựa trên các nguyên tắc mật mã, kinh tế hợp lý, sự đồng thuận lý thuyết, tính minh bạch và trách nhiệm giải trình. Trung tâm Cosmos là công khai đầu tiên blockchain trong Cosmos Mạng, được hỗ trợ bởi thuật toán đồng thuận BFT của Tendermint. các Dự án nguồn mở Tendermint ra đời vào năm 2014 nhằm giải quyết vấn đề các vấn đề về tốc độ, khả năng mở rộng và môi trường của thuật toán đồng thuận bằng chứng công việc của Bitcoin. Bằng cách sử dụng và cải tiến dựa trên những gì đã được chứng minh

BFT thuật toán được phát triển tại MIT vào năm 1988 [20], Tendermint nhóm là nhóm đầu tiên chứng minh một cách khái niệm proof-of-stake tiền điện tử giải quyết vấn đề không có gì đáng lo ngại phải chịu đựng các loại tiền điện tử thế hệ thứ nhất proof-of-stake như như NXT và BitShares1.0. Ngày nay, thực tế tất cả ví di động Bitcoin đều sử dụng máy chủ đáng tin cậy để cung cấp cho họ xác minh giao dịch. Điều này là do bằng chứng công việc đòi hỏi phải chờ nhiều sự đồng ý trước khi giao dịch có thể được coi là cam kết không thể đảo ngược. Các cuộc tấn công chi tiêu gấp đôi đã được chứng minh trên các dịch vụ như CoinBase. Không giống như các hệ thống đồng thuận blockchain khác, Tendermint cung cấp xác minh thanh toán của khách hàng di động ngay lập tức và được chứng minh là an toàn. Vì Tendermint được thiết kế để không bao giờ phân nhánh nên thiết bị di động ví có thể nhận được xác nhận giao dịch ngay lập tức, điều này làm cho thanh toán đáng tin cậy và thiết thực trở thành hiện thực trên điện thoại thông minh. Cái này có sự phân chia đáng kể cho các ứng dụng Internet of Things như tốt. Trình xác thực trong Cosmos có vai trò tương tự như công cụ khai thác Bitcoin, nhưng thay vào đó hãy sử dụng chữ ký mật mã để bỏ phiếu. Trình xác nhận là máy móc an toàn, chuyên dụng chịu trách nhiệm thực hiện khối. Những người không phảivalidator có thể ủy quyền staking token của họ (được gọi là “nguyên tử”) cho bất kỳ validator nào để kiếm một phần phí khối và nguyên tử phần thưởng, nhưng họ có nguy cơ bị trừng phạt (chém) nếu đại biểu validator bị hack hoặc vi phạm giao thức. Đã được chứng minh đảm bảo an toàn của sự đồng thuận Tendermint BFT và tài sản thế chấp tiền gửi của các bên liên quan–validators và người được ủy quyền–cung cấp bảo mật có thể chứng minh, định lượng được cho các nút và máy khách hạng nhẹ. Sổ cái công khai được phân phối phải có cấu trúc và hệ thống quản trị. Bitcoin dựa vào Bitcoin Foundation vàkhai thác để phối hợp nâng cấp, nhưng đây là một quá trình chậm. Ethereum chia thành ETH và ETC sau khi hard fork để giải quyết Vụ hackDAO, phần lớn là do không có hợp đồng xã hội trước đó cũng như cơ chế đưa ra các quyết định đó. Người xác nhận và người ủy quyền trên Trung tâm Cosmos có thể bỏ phiếu đề xuất có thể thay đổi các tham số đặt trước của hệ thống tự động (chẳng hạn như giới hạn khối gas), phối hợp nâng cấp, như cũng như bỏ phiếu về việc sửa đổi hiến pháp mà con người có thể đọc được chi phối các chính sách của Cosmos Hub. Hiến pháp cho phép sự gắn kết giữa các bên liên quan về các vấn đề như trộm cắp và lỗi (chẳng hạn như sự cố TheDAO), cho phép xử lý nhanh hơn và độ phân giải sạch hơn. Mỗi khu vực cũng có thể có hiến pháp và quản lý riêng cơ chế nữa. Ví dụ: Trung tâm Cosmos có thể có hiến pháp thực thi tính bất biến tại Hub (không quay lui, lưu lại các lỗi trong quá trình triển khai nút Trung tâm Cosmos), trong khi mỗi khu vực có thể thiết lập chính sách riêng của mình về việc khôi phục. Bằng cách cho phép khả năng tương tác giữa các vùng chính sách khác nhau, Mạng Cosmos mang đến cho người dùng sự tự do tối đa và tiềm năng thử nghiệm không được phép. Ở đây chúng tôi mô tả một mô hình mới về phân quyền và khả năng mở rộng. Cosmos là mạng gồm nhiều blockchain được cung cấp bởi Bạc hà. Trong khi các đề xuất hiện tại nhằm mục đích tạo ra một “khu vực duy nhất blockchain” với tổng số đơn đặt hàng giao dịch toàn cầu, Cosmos cho phép nhiều blockchain chạy đồng thời với nhau trong khi vẫn duy trì khả năng tương tác. Về cơ bản, Trung tâm Cosmos quản lý nhiều blockchain được gọi là "vùng" (đôi khi được gọi là "phân đoạn", trong tham chiếu đến kỹ thuật mở rộng quy mô cơ sở dữ liệu được gọi là “sharding”).

Một luồng liên tục các cam kết khối gần đây từ các khu vực được đăng trên Hub cho phép Hub theo dõi trạng thái của từng vùng. Tương tự như vậy, mỗi vùng sẽ cập nhật trạng thái của Hub (nhưng các vùng không theo kịp nhau ngoại trừ gián tiếp thông qua trung tâm). Các gói thông tin sau đó được truyền đi từ một vùng này sang vùng khác bằng cách đăng Merkle-proofs làm bằng chứng cho thấy thông tin đã được gửi và nhận. Cơ chế này được gọi là liên lạc giữa blockchain hoặc gọi tắt là IBC. Bản thân bất kỳ vùng nào cũng có thể là trung tâm để tạo thành biểu đồ không theo chu kỳ, nhưng để rõ ràng, chúng tôi sẽ chỉ mô tả những điều đơn giản tập đoàn nơi chỉ có một trung tâm và nhiều trung tâm không phải là trung tâm khu. Trung tâm Cosmos là blockchain lưu trữ nhiều nội dung sổ cái phân tán, trong đó token có thể được giữ bởi người dùng cá nhân hoặc theo từng khu vực. Những token này có thể được di chuyển từ một vùng tới gói khác trong gói IBC đặc biệt được gọi là "gói tiền xu". Trung tâm là chịu trách nhiệm bảo toàn tính bất biến toàn cục của tổng số lượng của mỗi token trên các vùng. IBC gói tiền xu giao dịch phải được cam kết bởi người gửi, trung tâm và người nhận blockchains.Vì Trung tâm Cosmos đóng vai trò là sổ cái trung tâm cho toàn bộ hệ thống, tính bảo mật của Hub là hết sức quan trọng. Trong khi mỗi vùng có thể là Tendermint blockchain được bảo mật bởi ít nhất là 4 (hoặc thậm chí ít hơn nếu không cần sự đồng thuận BFT), Hub phải được bảo mật bằng một tập hợp validator phi tập trung toàn cầu có thể chịu được các tình huống tấn công nghiêm trọng nhất, chẳng hạn như phân vùng mạng lục địa hoặc một cuộc tấn công do quốc gia tài trợ. Vùng Cosmos là blockchain độc lập trao đổi IBC tin nhắn với Hub. Từ quan điểm của Hub, một vùng là một tài khoản đa chữ ký thành viên năng động đa tài sản có thể gửi và nhận token bằng gói IBC. Giống như một tài khoản tiền điện tử, một vùng không thể chuyển nhiều hơn token giây nó có nhưng có thể nhận token từ những người khác có chúng. Một khu vực có thể được chỉ định là "nguồn" của một hoặc nhiều loại token, cấp cho nó quyền cung cấp token nguồn cung cấp đó. Các nguyên tử của Cosmos Hub có thể được đặt cọc bởi validator của một vùng được kết nối với Hub. Trong khi các cuộc tấn công chi tiêu gấp đôi vào các khu vực này sẽ dẫn đến việc cắt giảm các nguyên tử với khả năng phân chia của Tendermint, một khu vực có >⅔ quyền biểu quyết Byzantine có thể cam kết trạng thái không hợp lệ. Trung tâm Cosmos không xác minh hoặc thực hiện các giao dịch đã cam kết trên các vùng khác, do đó, trách nhiệm của người dùng là gửi token tới các vùng mà họ tin tưởng. Trong tương lai, hệ thống quản trị của Hub Cosmos có thể vượt qua Hub đề xuất cải tiến giải thích cho các lỗi vùng. cho ví dụ: chuyển khoản đi token từ một số (hoặc tất cả) khu vực có thể được điều chỉnh để cho phép ngắt mạch khẩn cấp các khu vực (tạm dừng token chuyển) khi phát hiện một cuộc tấn công. Bây giờ chúng ta xem xét cách Hub và các vùng giao tiếp với nhau khác. Ví dụ: nếu có ba blockchain, “Zone1”, “Zone2”,

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

và “Hub”, đồng thời chúng tôi mong muốn “Zone1” tạo ra gói tin được gửi đến cho “Zone2” đi qua “Hub”. Để di chuyển một gói từ một blockchain cho người khác, bằng chứng được đăng trên chuỗi nhận. Bằng chứng chỉ ra rằng chuỗi gửi đã xuất bản một gói cho điểm đến được cho là. Để chuỗi nhận kiểm tra bằng chứng này, nó phải có khả năng theo kịp các tiêu đề khối của người gửi. Cái này cơ chế tương tự như cơ chế được sử dụng bởi sidechains, đòi hỏi hai chuỗi tương tác để nhận biết nhau thông qua một luồng hai chiều của các gói dữ liệu chứng minh sự tồn tại (giao dịch). Giao thức IBC có thể được loại bỏ một cách tự nhiên bằng cách sử dụng hai loại giao dịch: giao dịch  IBCBlockCommitTx , cho phép blockchain để chứng minh cho bất kỳ người quan sát nào về khối gần đây nhất của nó-hash, và giao dịch  IBCPacketTx , cho phép blockchain chứng minh cho bất kỳ người quan sát nào rằng gói đã cho thực sự đã được xuất bản bởi ứng dụng của người gửi, thông qua Merkle-proof đến gần đây khối-hash. Bằng cách chia cơ chế IBC thành hai giao dịch riêng biệt, chúng tôi cho phép cơ chế thị trường phí gốc của chuỗi tiếp nhận xác định gói nào được cam kết (tức là đã được xác nhận), trong khi cho phép hoàn toàn tự do trong chuỗi gửi về cách thức nhiều gói gửi đi được cho phép. Trong ví dụ trên, để cập nhật block-hash của "Zone1" trên “Hub” (hoặc của “Hub” trên “Zone2”),  IBCBlockCommitTxgiao dịch phải được đăng trên “Hub” với khối-hash của “Zone1” (hoặc trên "Zone2" có khối-hash của “Hub”). Xem IBCBlockCommitTx và IBCPacketTx để biết thêm thông tin trên hai loại giao dịch IBC. Theo cách tương tự, Bitcoin sẽ an toàn hơn bằng cách được phân phối, sổ cái được sao chép hàng loạt, chúng ta có thể làm cho các sàn giao dịch ít bị tấn công hơn hack bên ngoài và bên trong bằng cách chạy nó trên blockchain. Chúng tôi gọi đây là một cuộc trao đổi phân tán. Cái mà cộng đồng tiền điện tử gọi là phi tập trung Exchange ngày nay dựa trên một thứ gọi là giao dịch “chuỗi chéo nguyên tử” (AXC). Với giao dịch AXC, hai người dùng trên hai chuỗi khác nhau có thể thực hiện hai giao dịch chuyển khoản được cam kết cùng nhau trên cả hai sổ cái hoặc không có gì cả (tức là về mặt nguyên tử). Ví dụ: hai người dùng có thể giao dịch bitcoin lấy ether (hoặc bất kỳ hai token nào trên hai sổ cái khác nhau) sử dụng giao dịch AXC, mặc dù Bitcoin và Ethereum không được kết nối với nhau khác. Lợi ích của việc thực hiện trao đổi trên các giao dịch AXC là rằng cả hai người dùng đều không cần phải tin tưởng lẫn nhau hoặc việc kết hợp giao dịch dịch vụ. Nhược điểm là cả hai bên cần trực tuyến để thương mại xảy ra. Một loại sàn giao dịch phi tập trung khác là sàn giao dịch được nhân rộng hàng loạt trao đổi phân phối tự chạy blockchain. Người dùng trên loại sàn giao dịch này có thể gửi lệnh giới hạn và chuyển giao tắt máy tính và giao dịch có thể được thực hiện mà người dùng không cần phải trực tuyến. blockchain thay mặt khớp và hoàn tất giao dịch của người buôn bán.

アプリケーション

集中型取引所は、指値の深いオーダーブックを作成できる 注文を増やし、それによってより多くのトレーダーを引き寄せます。流動性がさらに高まる 取引所の世界には流動性があり、強力なネットワークが存在します。 交換における効果(または少なくとも勝者総取り効果) ビジネス。現在の仮想通貨取引所のリーダー 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) 名を関連付けることができます。

登録ゾーンは独自のガバナンスと登録を持つことができます ルール。

Ứng dụng

Một sàn giao dịch tập trung có thể tạo ra một sổ đặt hàng có giới hạn sâu đơn đặt hàng và do đó thu hút nhiều thương nhân hơn. Thanh khoản ngày càng nhiều tính thanh khoản trong thế giới trao đổi và do đó có một mạng lưới mạnh mẽ hiệu ứng (hoặc ít nhất là hiệu ứng người thắng được nhiều nhất) trong trao đổi kinh doanh. Người dẫn đầu hiện tại về trao đổi tiền điện tử là Poloniex với khối lượng giao dịch trong 24 giờ là 20 triệu USD và ở vị trí thứ hai là Bitynex với khối lượng 24 giờ là 5 triệu USD. Với mạng lưới mạnh mẽ như vậy có hiệu lực, các sàn giao dịch phi tập trung dựa trên AXC khó có thể giành được khối lượng trên các sàn giao dịch tập trung. Đối với một nền tảng phi tập trung trao đổi để cạnh tranh với một sàn giao dịch tập trung, nó sẽ cần để hỗ trợ sổ đặt hàng sâu với các đơn đặt hàng giới hạn. Chỉ có một phân phối trao đổi trên blockchain có thể cung cấp điều đó. Tendermint cung cấp thêm lợi ích cho giao dịch nhanh hơn cam kết. Bằng cách ưu tiên khả năng hoạt động nhanh chóng mà không phải hy sinh tính nhất quán, các vùng trong Cosmos có thể thúc đẩy giao dịch nhanh chóng – cho cả giao dịch đặt hàng trao đổi cũng như IBC token chuyển tới và từ các khu vực khác. Với tình trạng trao đổi tiền điện tử ngày nay, một điều tuyệt vời ứng dụng cho Cosmos là sàn giao dịch phân tán (còn gọi là Cosmos DEX). Năng lực thông lượng giao dịch cũng như độ trễ cam kết có thể tương đương với độ trễ của tập trung trao đổi. Nhà giao dịch có thể gửi lệnh giới hạn có thể được thực hiện mà không cần cả hai bên phải trực tuyến. Và với Tendermint, trung tâm Cosmos và IBC, nhà giao dịch có thể chuyển tiền vào và ra trao đổi đến và đi từ các khu vực khác với tốc độ. Vùng đặc quyền có thể đóng vai trò là nguồn của token cầu nối của một loại tiền điện tử khác. Một cây cầu tương tự như mối quan hệ giữa trung tâm và vùng Cosmos; cả hai đều phải theo kịp các khối mới nhất của khối kia để xác minh bằng chứng rằng token có chuyển từ cái này sang cái khác. "Khu vực cầu" trên Cosmos mạng theo kịp Hub cũng như các mạng khác

tiền điện tử. Việc chuyển hướng qua vùng cầu cho phép logic của Hub vẫn đơn giản và không thể tin được đối với những người khác blockchain chiến lược đồng thuận như proof-of-work của Bitcoin khai thác mỏ. Mỗi vùng cầu validator sẽ chạy một hệ thống được hỗ trợ bởi Tendermint blockchain với ứng dụng cầu nối ABCI đặc biệt nhưng cũng có nút đầy đủ của “nguồn gốc” blockchain. Khi các khối mới được khai thác ở điểm gốc, vùng cầu validators sẽ đi đến thống nhất về các khối đã cam kết bằng cách ký tên và chia sẻ quan điểm địa phương tương ứng của họ về nguồn gốc blockchain tiền boa. Khi một bridge-zone nhận được khoản thanh toán từ nguồn gốc (và sự đồng ý đầy đủ đã được đồng ý đã được nhìn thấy trong vụ án của chuỗi PoW chẳng hạn như Ethereum hoặc Bitcoin), tương ứng tài khoản được tạo trên bridge-zone với số dư đó. Trong trường hợp Ethereum, bridge-zone có thể chia sẻ tương tự validator-được đặt làm Trung tâm Cosmos. Về phía Ethereum ( Origin), một hợp đồng bắc cầu sẽ cho phép người nắm giữ ether gửi ether tới bridge-zone bằng cách gửi nó tới bridge-contract trên Ethereum. Sau khi hợp đồng cầu nối nhận được ether, không thể rút ether trừ khi có gói IBC thích hợp được nhận bởi hợp đồng cầu từ khu vực cầu. các hợp đồng cầu nối theo dõi tập hợp validator của vùng cầu, trong đó có thể giống hệt với bộ validator của Hub Cosmos. Trong trường hợp Bitcoin, khái niệm này tương tự ngoại trừ việc thay vì một hợp đồng cầu nối duy nhất, mỗi UTXO sẽ được kiểm soát bởi một ngưỡng công bố P2SH đa chữ ký. Do những hạn chế của hệ thống P2SH, người ký không thể giống với Cosmos Bộ trung tâm validator.Ether trên vùng cầu (“bridged-ether”) có thể được chuyển sang và từ Hub, sau đó bị hủy bởi một giao dịch gửi nó đến một địa chỉ rút tiền cụ thể trên Ethereum. Một IBC gói chứng minh rằng giao dịch xảy ra trên bridge-zone có thể được đăng lên hợp đồng cầu nối Ethereum để cho phép ether được rút lại. Trong trường hợp Bitcoin, hệ thống tập lệnh bị hạn chế khiến nó khó có thể phản ánh cơ chế chuyển tiền IBC. Mỗi UTXO có bản công bố độc lập riêng, vì vậy mọi UTXO đều phải được di chuyển sang UTXO mới khi có thay đổi trong tập hợp Bitcoin người ký khế ước. Một giải pháp là nén và giải nén bộ UTXO nếu cần để giữ tổng số trong số UTXO giây bị hỏng. Rủi ro của một hợp đồng bắc cầu như vậy là có thể xảy ra validator lừa đảo. ≥⅓ Quyền biểu quyết của Byzantine có thể gây ra fork, rút ether từ hợp đồng cầu trên Ethereum trong khi vẫn giữ cầu nối trên vùng cầu. Tệ hơn nữa, >⅔ Quyền biểu quyết của Byzantine có thể ăn cắp ether hoàn toàn từ những người đã gửi nó đến hợp đồng cầu nối bằng cách đi chệch khỏi logic bắc cầu ban đầu của vùng cầu. Có thể giải quyết những vấn đề này bằng cách thiết kế cây cầu phù hợp hoàn toàn chịu trách nhiệm. Ví dụ: tất cả các gói IBC, từ trung tâm và nguồn gốc, có thể yêu cầu xác nhận của bridge-zone trong theo cách mà tất cả các chuyển đổi trạng thái của vùng cầu có thể được được thách thức và xác minh một cách hiệu quả bởi trung tâm hoặc nguồn gốc hợp đồng cầu đường. Hub và nguồn gốc phải cho phép các bridgezone validator gửi tài sản thế chấp và token chuyển ra khỏi hợp đồng bắc cầu sẽ bị trì hoãn (và tài sản thế chấp sẽ được hủy bỏ khoảng thời gian đủ dài) để cho phép mọi thách thức được thực hiện bởi kiểm toán viên độc lập. Chúng tôi để lại thiết kế của thông số kỹ thuật và việc triển khai hệ thống này mở như một tương lai Cosmos

đề xuất cải tiến sẽ được Trung tâm Cosmos thông qua hệ thống quản trị. Giải quyết vấn đề mở rộng quy mô là một vấn đề mở đối với Ethereum. Hiện tại, các nút Ethereum xử lý mọi giao dịch và cũng lưu trữ tất cả các trạng thái. liên kết. Vì Tendermint có thể thực hiện các khối nhanh hơn nhiều so với Ethereum proof-of-work, EVM khu vực được hỗ trợ bởi sự đồng thuận của Tendermint và hoạt động trên bridged-ether có thể mang lại hiệu suất cao hơn cho Ethereum blockchains. Ngoài ra, mặc dù Trung tâm Cosmos và IBC cơ chế gói không cho phép logic hợp đồng tùy ý thực chất nó có thể được sử dụng để phối hợp các chuyển động token giữa Ethereum hợp đồng chạy trên các vùng khác nhau, cung cấp nền tảng cho việc mở rộng quy mô token lấy trung tâm Ethereum thông qua phân mảnh. Cosmos vùng chạy logic ứng dụng tùy ý, được xác định tại thời điểm bắt đầu vòng đời của vùng và có thể được cập nhật theo thời gian bởi sự quản lý. Tính linh hoạt như vậy cho phép các vùng Cosmos đóng vai trò là cầu nối với các loại tiền điện tử khác như Ethereum hoặc Bitcoin và nó cũng cho phép các dẫn xuất của blockchain đó, sử dụng cùng một cơ sở mã nhưng với bộ validator khác và phân phối ban đầu. Điều này cho phép nhiều loại tiền điện tử hiện có các khuôn khổ, chẳng hạn như của Ethereum, Zerocash, Bitcoin, CryptoNote, v.v., sẽ được sử dụng với Tendermint Core, một công cụ đồng thuận hiệu suất cao hơn, trên một mạng chung, mở ra cơ hội to lớn cho khả năng tương tác giữa nền tảng. Hơn nữa, với tư cách là nhiều nội dung blockchain, một giao dịch có thể chứa nhiều đầu vào và đầu ra, trong đó mỗi đầu vào có thể là bất kỳ loại token nào, cho phép Cosmos phân phát trực tiếp dưới dạng một nền tảng trao đổi phi tập trung, mặc dù các đơn đặt hàng được giả địnhđể được khớp thông qua các nền tảng khác. Ngoài ra, một vùng có thể phục vụ như một sàn giao dịch có khả năng chịu lỗi phân tán (với sổ đặt hàng), có thể là một cải tiến nghiêm ngặt so với tập trung hiện có trao đổi tiền điện tử có xu hướng bị hack theo thời gian. Các vùng cũng có thể đóng vai trò là phiên bản doanh nghiệp được blockchain hỗ trợ và các hệ thống chính phủ, nơi các phần của một dịch vụ cụ thể theo truyền thống được điều hành bởi một tổ chức hoặc một nhóm tổ chức thay vào đó được chạy dưới dạng ứng dụng ABCI trên một vùng nhất định, cho phép nó kế thừa tính bảo mật và khả năng tương tác của công chúng Cosmos mạng mà không hy sinh quyền kiểm soát cơ bản dịch vụ. Do đó, Cosmos có thể mang lại những điều tốt nhất cho cả hai thế giới các tổ chức đang tìm cách sử dụng công nghệ blockchain nhưng ai cảnh giác với việc từ bỏ hoàn toàn quyền kiểm soát cho một bên thứ ba được phân phối bữa tiệc. Một số người cho rằng vấn đề lớn với việc ủng hộ tính nhất quán các thuật toán đồng thuận như Tendermint là bất kỳ mạng nào phân vùng khiến không có phân vùng duy nhất có >⅔ quyền biểu quyết (ví dụ: ≥⅓ chuyển sang sử dụng zine) sẽ ngăn chặn hoàn toàn sự đồng thuận. Kiến trúc Cosmos có thể giúp giảm thiểu vấn đề này bằng cách sử dụng một trung tâm toàn cầu với các khu tự trị khu vực, nơi quyền biểu quyết cho mỗi khu vực được phân bổ dựa trên một địa lý chung khu vực. Ví dụ, một mô hình chung có thể dành cho cá nhân thành phố hoặc khu vực để vận hành các khu vực riêng của họ trong khi chia sẻ trung tâm chung (ví dụ: Trung tâm Cosmos), cho phép hoạt động của thành phố tồn tại trong trường hợp trung tâm tạm dừng do mạng tạm thời phân vùng. Lưu ý rằng điều này cho phép thực tế về địa chất, chính trị và các tính năng cấu trúc liên kết mạng cần được xem xét trong việc thiết kế mạnh mẽ các hệ thống có khả năng chịu lỗi liên kết.

NameCoin là một trong những blockchain đầu tiên cố gắng giải quyết vấn đề vấn đề phân giải tên bằng cách điều chỉnh Bitcoin blockchain. Thật không may, đã có một số vấn đề với cách tiếp cận này. Với Namecoin, chúng tôi có thể xác minh rằng, chẳng hạn như @satoshi đã được đăng ký với một khóa công khai cụ thể tại một thời điểm nào đó trong quá khứ, nhưng chúng tôi không biết liệu khóa công khai đã được được cập nhật gần đây trừ khi chúng tôi tải xuống tất cả các khối kể từ lần cuối cùng cập nhật tên đó. Điều này là do hạn chế của Bitcoin UTXO mô hình Merkle-ization giao dịch, trong đó chỉ có các giao dịch (nhưng không phải trạng thái ứng dụng có thể thay đổi) được Merkle-ized vào khối-hash. Điều này cho phép chúng tôi chứng minh sự tồn tại chứ không phải sự không tồn tại của các bản cập nhật sau này cho một tên. Vì vậy, chúng ta không thể biết đối với nhất định giá trị gần đây nhất của một tên mà không tin tưởng vào giá trị đầy đủ nút hoặc phát sinh chi phí đáng kể về băng thông bằng cách tải xuống toàn bộ blockchain. Ngay cả khi cây tìm kiếm được Merkle hóa đã được triển khai trong NameCoin, sự phụ thuộc của nó vào proof-of-work khiến việc xác minh ứng dụng khách trở nên dễ dàng có vấn đề. Các khách hàng nhẹ phải tải xuống bản sao hoàn chỉnh của tiêu đề cho tất cả các khối trong toàn bộ blockchain (hoặc ít nhất là tất cả tiêu đề kể từ lần cập nhật cuối cùng cho một tên). Điều này có nghĩa là yêu cầu về băng thông tỉ lệ tuyến tính với lượng thời gian [21]. Ngoài ra, việc thay đổi tên trên proof-of-work blockchain yêu cầu chờ thêm proof-of-work khối xác nhận, việc này có thể mất tới một giờ trên Bitcoin. Với Tendermint, tất cả những gì chúng ta cần là khối gần đây nhất-hash được ký bởi số đại biểu validators (theo quyền biểu quyết) và Merkle bằng chứng cho giá trị hiện tại được liên kết với tên. Điều này làm cho nó có thể có một light-client ngắn gọn, nhanh chóng và an toàn xác minh các giá trị tên. Trong Cosmos, chúng tôi có thể áp dụng khái niệm này và mở rộng nó hơn nữa. Mỗi vùng đăng ký tên trong Cosmos có thể có tên miền cấp cao nhất (TLD) được liên kết chẳng hạn như “.com” hoặc “.org” và mỗi tên-

khu vực đăng ký có thể có quản trị và đăng ký riêng quy luật.

ガバナンスと経済

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、定期的でより頻繁なブロック コミットにより、 垂直方向のスケーリングも可能です。

Quản trị và Kinh tế

Mặc dù Trung tâm Cosmos là sổ cái phân phối nhiều tài sản, nhưng có một người bản địa đặc biệt token được gọi là nguyên tử. Nguyên tử là staking duy nhất token của Trung tâm Cosmos. Nguyên tử là một giấy phép cho người nắm giữ bỏ phiếu, xác thực hoặc ủy quyền cho validators khác. Giống như của Ethereum ether, nguyên tử cũng có thể được sử dụng để thanh toán phí giao dịch cho giảm thiểu thư rác. Các nguyên tử bổ sung và giao dịch khối phí được thưởng cho validator và người được ủy quyền validator giây. Giao dịch  BurnAtomTx  có thể được sử dụng để khôi phục mọi số lượng tương ứng token từ nhóm dự trữ. Sự phân bổ ban đầu của nguyên tử tokens và validators trên Genesis sẽ đến tay các nhà tài trợ của Cosmos Người gây quỹ (75%), nhà tài trợ chính (5%), Cosmos Network Foundation (10%) và ALL IN BITS, Inc (10%). Từ khi hình thành trở đi, 1/3 tổng số nguyên tử sẽ được khen thưởng cho validator ngoại quan và người được ủy quyền hàng năm. Xem Kế hoạch Cosmos để biết thêm chi tiết. Không giống như Bitcoin hoặc proof-of-work blockchain khác, Tendermint blockchain trở nên chậm hơn với nhiều validator giây hơn do tăng sự phức tạp trong giao tiếp. May mắn thay, chúng tôi có thể hỗ trợ đủ validators để tạo nên sự phân phối mạnh mẽ trên toàn cầu blockchain với thời gian xác nhận giao dịch rất nhanh và băng thông,

lưu trữ và khả năng tính toán song song tăng lên, chúng ta sẽ có thể để hỗ trợ thêm validators trong tương lai. Vào ngày khởi nguồn, số lượng validator tối đa sẽ được đặt thành 100, và con số này sẽ tăng với tốc độ 13% trong 10 năm, và giải quyết ở mức 300 validator giây. Những người nắm giữ Atom chưa có thể trở thành validators bằng cách ký và gửi giao dịch  BondTx. Số lượng của các nguyên tử được cung cấp làm tài sản thế chấp phải khác không. Bất cứ ai cũng có thể trở thành a validator bất cứ lúc nào, ngoại trừ khi kích thước của dòng điện Bộ validator lớn hơn số lượng tối đa validator giây được phép. Trong trường hợp đó, giao dịch chỉ có hiệu lực nếu số tiền nguyên tử lớn hơn số lượng nguyên tử hữu hiệu được giữ bởi nhỏ nhất validator, trong đó các nguyên tử hiệu quả bao gồm các nguyên tử được ủy quyền. Khi validator mới thay thế validator hiện có theo cách như vậy, validator hiện có sẽ không hoạt động và tất cả các nguyên tử và các nguyên tử được ủy quyền đi vào trạng thái không liên kết. Phải có một số hình phạt áp dụng đối với validator đối với bất kỳ cố ý hoặc vô ý đi chệch khỏi mức bị xử phạt giao thức. Một số bằng chứng được chấp nhận ngay lập tức, chẳng hạn như một ký kép ở cùng độ cao và hình tròn hoặc vi phạm Năm 0: 100  Năm 1: 113  Năm 2: 127  Năm 3: 144  Năm 4: 163  Năm 5: 184  Năm 6: 208  Năm 7: 235  Năm 8: 265  Năm 9: 300  Năm 10: 300  ...

“prevote-the-lock” (một quy tắc của giao thức đồng thuận Tendermint). Bằng chứng như vậy sẽ khiến validator mất đi vị thế tốt và các nguyên tử liên kết của nó cũng như tỷ lệ tokens trong quỹ dự trữ – được gọi chung là “cổ phần” của nó – sẽ bị cắt giảm. Đôi khi, validator sẽ không khả dụng do điều kiện khu vực gián đoạn mạng, mất điện hoặc các lý do khác. Nếu, bất cứ lúc nào điểm trong các khối  ValidatorTimeoutWindow  trước đây, validator's phiếu cam kết không được bao gồm trong blockchain nhiều hơn  ValidatorTimeoutMaxAbsent  lần, validator đó sẽ trở thành không hoạt động và mất  ValidatorTimeoutPenalty  (MẶC ĐỊNH 1%) trong tổng số cổ phần. Một số hành vi “có hại” không tạo ra sự khác biệt rõ ràng bằng chứng trên blockchain. Trong những trường hợp này, validator có thể phối hợp ngoài băng để buộc thời gian chờ của những kẻ độc hại này validators, nếu có sự đồng thuận của đa số. Trong trường hợp Trung tâm Cosmos dừng do liên minh ≥⅓ quyền biểu quyết sẽ thuộc về zine hoặc trong trường hợp liên minh ≥⅓ quyền biểu quyết kiểm duyệt bằng chứng về hành vi độc hại từ vào blockchain, trung tâm phải khôi phục bằng hard-fork đề xuất tái tổ chức. (Liên kết đến “Các cuộc tấn công phân nhánh và kiểm duyệt”). Cosmos Hub validator có thể chấp nhận bất kỳ loại token hoặc kết hợp nào các loại phí để xử lý một giao dịch. Mỗi validator có thể chủ quan đặt ra bất kỳ tỷ giá hối đoái nào nó muốn và chọn bất kỳ giao dịch nào họ muốn, miễn là  BlockGasLimit  là không vượt quá. Các khoản phí thu được, trừ đi các khoản thuế được quy định dưới đây, được phân phối lại cho các bên liên quan theo tỷ lệ các nguyên tử liên kết của chúng, mỗi  ValidatorPayoutPeriod  (MẶC ĐỊNH 1 giờ).Trong số phí giao dịch được thu,  ReserveTax  (MẶC ĐỊNH 2%) sẽ đi về phía nhóm dự trữ để tăng nhóm dự trữ và tăng tính bảo mật và giá trị của mạng Cosmos. Những cái này nguồn vốn cũng có thể được phân bổ theo các quyết định do hệ thống quản lý thực hiện. Người sở hữu Atom ủy quyền quyền biểu quyết của họ cho validators khác trả hoa hồng cho người được ủy quyền validator. Ủy ban có thể được đặt bởi mỗi validator. Tính bảo mật của Cosmos Hub là một chức năng bảo mật của validator cơ bản và sự lựa chọn ủy quyền của người được ủy quyền. Để khuyến khích việc phát hiện và báo cáo sớm các phát hiện các lỗ hổng bảo mật, Trung tâm Cosmos khuyến khích tin tặc xuất bản khai thác thành công thông qua giao dịch  ReportHackTx  có nội dung: “Điều này validator đã bị hack. Vui lòng gửi tiền thưởng đến địa chỉ này”. Khi việc khai thác như vậy, validator và người ủy quyền sẽ không hoạt động,  HackPunishmentRatio  (mặc định 5%) nguyên tử của mọi người sẽ nhận được bị chém và  HackRewardRatio  (mặc định 5%) nguyên tử của mọi người sẽ nhận được phần thưởng theo địa chỉ tiền thưởng của hacker. validator phải phục hồi các nguyên tử còn lại bằng cách sử dụng khóa dự phòng của chúng. Để ngăn chặn tính năng này bị lạm dụng để chuyển các nguyên tử chưa được đầu tư, phần nguyên tử được giao so với các nguyên tử chưa được đầu tư của validators và người được ủy quyền trước và sau  ReportHackTx  sẽ vẫn giữ nguyên và tiền thưởng của hacker sẽ bao gồm một số nguyên tử chưa đầu tư, nếu có. Trung tâm Cosmos được vận hành bởi một tổ chức phân phối đòi hỏi phải có cơ chế quản lý chặt chẽ để điều phối các thay đổi khác nhau đối với blockchain, chẳng hạn như biến

các thông số của hệ thống, cũng như nâng cấp phần mềm và sửa đổi hiến pháp. Tất cả validator đều có trách nhiệm bỏ phiếu cho tất cả đề xuất. Không thể bỏ phiếu cho một đề xuất một cách kịp thời sẽ dẫn đến validator bị vô hiệu hóa tự động trong một khoảng thời gian được gọi là  Vắng mặtThời gian phạt  (MẶC ĐỊNH 1 tuần). Người được ủy quyền tự động kế thừa phiếu bầu của người được ủy quyền validator. Phiếu bầu này có thể được ghi đè bằng tay. nguyên tử không liên kết không nhận được phiếu bầu. Mỗi đề xuất yêu cầu một khoản tiền gửi là  Tiền gửi đề xuất tối thiểu  tokens, có thể là sự kết hợp của một hoặc nhiều tokens trong đó có nguyên tử. Đối với mỗi đề xuất, cử tri có thể bỏ phiếu để thông qua tiền đặt cọc. Nếu hơn một nửa số cử tri chọn tham gia tiền gửi (ví dụ: vì đề xuất là thư rác), khoản tiền gửi sẽ chuyển đến nguồn dự trữ, ngoại trừ bất kỳ nguyên tử nào bị đốt cháy. Đối với mỗi đề xuất, cử tri có thể bỏ phiếu với các phương án sau: vâng YeaWithForce không NayVới Lực Lượng kiêng Đa số phiếu thuận hoặc YeaWithForce (hoặc Không hoặc Cần có phiếu bầu NayWithForce) để đề xuất được quyết định là được thông qua (hoặc quyết định là thất bại), nhưng 1/3+ có thể phủ quyết đa số quyết định bằng cách bỏ phiếu "có hiệu lực". Khi đa số tuyệt đối bị phủ quyết, mọi người đều bị trừng phạt bằng cách thua  VetoPenaltyFeeBlocks  (MẶC ĐỊNH số khối có giá trị trong 1 ngày) phí (trừ thuế sẽ không bị ảnh hưởng) và bên phủ quyết đa số

quyết định sẽ bị phạt bổ sung bằng việc mất  VetoPenaltyAtoms  (MẶC ĐỊNH 0,1%) số nguyên tử của nó. Bất kỳ tham số nào được mô tả ở đây đều có thể được thay đổi bằng chuyển  Đề xuất thay đổi thông số . Các nguyên tử có thể được sản xuất và dự trữ quỹ dành cho thông qua  Đề xuất tiền thưởng . Tất cả các đề xuất khác, chẳng hạn như đề xuất nâng cấp giao thức, sẽ được điều phối thông qua  Đề xuất văn bản  chung. Xem Kế hoạch. Đã có nhiều đổi mới trong blockchain sự đồng thuận và khả năng mở rộng trong vài năm qua. Phần này cung cấp một bản tóm tắt khảo sát một số lựa chọn quan trọng. Sự đồng thuận khi có sự hiện diện của những người tham gia độc hại là một vấn đề bắt đầu từ đầu những năm 1980, khi Leslie Lamport đặt ra cụm từ “Lỗi Byzantine” để chỉ hành vi xử lý tùy ý đi chệch khỏi hành vi dự định, trái ngược với “lỗi sự cố”, trong đó một quá trình chỉ đơn giản là gặp sự cố. Các giải pháp ban đầu được phát hiện đối với các mạng đồng bộ có giới hạn trênđộ trễ của tin nhắn, mặc dù việc sử dụng thực tế bị giới hạn ở mức cao môi trường được kiểm soát như bộ điều khiển máy bay và trung tâm dữ liệu được đồng bộ hóa thông qua đồng hồ nguyên tử. Mãi cho đến khi vào cuối những năm 90, Dung sai lỗi Byzantine thực tế (PBFT) [11] là được giới thiệu như một sự đồng thuận đồng bộ một phần hiệu quả thuật toán có thể chịu được tới ⅓ quy trình hoạt động tùy ý. PBFT đã trở thành thuật toán tiêu chuẩn, tạo ra nhiều thuật toán các biến thể, bao gồm cả biến thể gần đây nhất do IBM tạo ra như một phần của đóng góp của họ cho Hyperledger. Lợi ích chính của sự đồng thuận của Tendermint đối với PBFT là Tendermint có cấu trúc cơ bản được cải tiến và đơn giản hóa, một số trong đó là kết quả của việc áp dụng mô hình blockchain. Các khối Tendermint phải được thực hiện theo thứ tự, điều này ngăn cản độ phức tạp và chi phí liên lạc liên quan đến PBFT lượt xem-thay đổi. Trong Cosmos và nhiều loại tiền điện tử, không có cần cho phép khối N+i trong đó i >= 1 được cam kết, khi khối N bản thân nó vẫn chưa cam kết. Nếu băng thông là nguyên nhân khiến khối N chưa cam kết trong vùng Cosmos thì việc sử dụng sẽ không có ích gì phiếu chia sẻ băng thông cho khối N+i. Nếu một phân vùng mạng hoặc nút ofzine là lý do tại sao khối N chưa được cam kết, thì N+i dù sao cũng sẽ không cam kết. Ngoài ra, việc gộp các giao dịch thành các khối cho phép Merkle-hashing thường xuyên của trạng thái ứng dụng, thay vì các bản tóm tắt định kỳ như với sơ đồ điểm kiểm tra của PBFT. Điều này cho phép để có các cam kết giao dịch có thể chứng minh nhanh hơn dành cho khách hàng nhẹ và nhanh hơn liên lạc giữablockchain. Tendermint Core cũng bao gồm nhiều tính năng và tối ưu hóa vượt xa những gì được chỉ định trong PBFT. Ví dụ, các khối do validators đề xuất được chia thành các phần, được Merkle hóa, và buôn chuyện theo cách giúp cải thiện việc phát sóng hiệu suất (xem LibSwift [19] để biết cảm hứng). Ngoài ra, bạc hà Core không đưa ra bất kỳ giả định nào về điểm-điểm

khả năng kết nối và hoạt động miễn là mạng P2P kết nối yếu. Mặc dù không phải là năm đầu tiên triển khai proof-of-stake (PoS), BitShares1.0 [12] đóng góp đáng kể vào việc nghiên cứu và áp dụng PoS blockchains, đặc biệt là những PoS được ủy quyền. trong BitShares, người nắm giữ cổ phần bầu ra “nhân chứng”, chịu trách nhiệm ra lệnh và thực hiện các giao dịch, và các "đại biểu" chịu trách nhiệm về phối hợp cập nhật phần mềm và thay đổi thông số. BitShares2.0 nhằm mục đích đạt được hiệu suất cao (100k tx/s, 1s độ trễ) trong điều kiện lý tưởng, với mỗi khối được ký bởi một người ký và thời gian thực hiện giao dịch mất nhiều thời gian hơn một chút so với khoảng chặn. Một đặc tả kinh điển vẫn đang được phát triển. Các bên liên quan có thể loại bỏ hoặc thay thế các nhân chứng có hành vi sai trái hàng ngày, nhưng không có tài sản thế chấp đáng kể của nhân chứng hoặc các đại biểu giống như Tendermint PoS bị chém vào trường hợp tấn công chi tiêu gấp đôi thành công. Dựa trên cách tiếp cận do Ripple tiên phong, Stellar [13] đã đưa ra một mô hình Thỏa thuận Byzantine Liên bang trong đó các quy trình tham gia vào sự đồng thuận không cấu thành một yxed và trên toàn cầu tập đã biết. Đúng hơn, mỗi nút quy trình quản lý một hoặc nhiều “các lát cắt đại biểu”, mỗi lát tạo thành một tập hợp các quy trình đáng tin cậy. A “quorum” trong Stellar được coi là tập hợp các nút chứa tại ít nhất một lát đại biểu cho mỗi nút trong tập hợp, sao cho thỏa thuận có thể đạt được. Tính bảo mật của cơ chế Stellar dựa trên giả định rằng giao điểm của hai đại biểu bất kỳ không trống, trong khi tính khả dụng của một nút yêu cầu ít nhất một trong các lát cắt đại biểu của nó để bao gồm toàn bộ các nút chính xác, tạo ra sự cân bằng giữa sử dụng các lát đại biểu lớn hoặc nhỏ có thể khó cân bằng mà không áp đặt những giả định quan trọng về niềm tin. Cuối cùng,các nút bằng cách nào đó phải chọn các lát đại biểu đầy đủ để có có đủ khả năng chịu lỗi (hoặc bất kỳ "nút nguyên vẹn" nào, trong đó phần lớn kết quả của bài báo phụ thuộc vào) và duy nhất cung cấp chiến lược để đảm bảo sự kết hợp như vậy được phân cấp và tương tự như Giao thức cổng biên (BGP), được sử dụng bởi các ISP hàng đầu trên internet để thiết lập các bảng định tuyến toàn cầu và bởi được trình duyệt sử dụng để quản lý chứng chỉ TLS; cả hai đều khét tiếng vì sự bất an của họ. Những lời chỉ trích trong bài báo Stellar về hệ thống bằng chứng cổ phần dựa trên Tendermint được giảm nhẹ nhờ chiến lược token được mô tả ở đây, trong đó một loại token mới được gọi là nguyên tử được phát hành thể hiện các yêu cầu đối với các phần phí và phần thưởng trong tương lai. các thì lợi thế của proof-of-stake dựa trên Tendermint là tương đối của nó đơn giản, trong khi vẫn cung cấp đủ mức độ bảo mật và có thể chứng minh được sự đảm bảo. BitcoinNG là cải tiến được đề xuất cho Bitcoin sẽ cho phép dành cho các dạng khả năng mở rộng theo chiều dọc, chẳng hạn như tăng kích thước khối, không có những hậu quả kinh tế tiêu cực thường liên quan đến với sự thay đổi như vậy, chẳng hạn như tác động lớn không tương xứng trên các thợ mỏ nhỏ. Sự cải thiện này đạt được bằng cách tách bầu cử lãnh đạo từ phát sóng giao dịch: lãnh đạo là người đầu tiên được bầu chọn bởi proof-of-work trong “khối vi mô” và sau đó có thể các giao dịch quảng bá sẽ được cam kết cho đến khi có một khối vi mô mới được tìm thấy. Điều này làm giảm các yêu cầu về băng thông cần thiết để giành chiến thắng trong cuộc đua PoW, cho phép các thợ mỏ nhỏ cạnh tranh công bằng hơn, và cho phép các giao dịch được thực hiện thường xuyên hơn bởi thợ mỏ cuối cùng tìm được một khối vi mô. Casper [16] là thuật toán đồng thuận proof-of-stake được đề xuất cho Ethereum. Phương thức hoạt động chính của nó là “đồng thuận bằng cách đặt cược”. Bởi để validator đặt cược lặp đi lặp lại vào khối mà họ tin rằng sẽ

cam kết tham gia blockchain dựa trên các cược khác mà họ đã thấy cho đến nay, cuối cùng thì tính đồng bộ có thể đạt được. liên kết. Đây là một lĩnh vực nghiên cứu tích cực của nhóm Casper. các thách thức là xây dựng một cơ chế cá cược có thể đã được chứng minh là một chiến lược ổn định về mặt tiến hóa. Lợi ích chính của Casper so với Tendermint có thể cung cấp “tính khả dụng quá nhất quán” – sự đồng thuận không yêu cầu >⅔ số đại biểu quyền biểu quyết - có lẽ phải trả giá bằng tốc độ cam kết hoặc độ phức tạp thực hiện. Giao thức Interledger [14] không hẳn là một giải pháp có khả năng mở rộng. Nó cung cấp sự tương tác đặc biệt giữa các sổ cái khác nhau hệ thống thông qua mạng lưới quan hệ song phương được kết nối lỏng lẻo. Giống như Lightning Network, mục đích của ILP là tạo điều kiện thuận lợi thanh toán, nhưng nó đặc biệt tập trung vào các khoản thanh toán khác nhau các loại sổ cái và mở rộng cơ chế giao dịch nguyên tử sang bao gồm không chỉ hash-khóa mà còn bao gồm số đại biểu công chứng viên (được gọi là Giao thức vận chuyển nguyên tử). Cơ chế sau cho thực thi tính nguyên tử trong các giao dịch giữa các sổ cái tương tự như Cơ chế SPV máy khách nhẹ của Tendermint, do đó minh họa về sự khác biệt giữa ILP và Cosmos/IBC được đảm bảo và được cung cấp dưới đây. 1. Công chứng viên kết nối trong ILP không hỗ trợ tư cách thành viên thay đổi và không cho phép trọng số linh hoạt giữa công chứng viên. Mặt khác, IBC được thiết kế đặc biệt cho blockchains, trong đó validators có thể có trọng số khác nhau và nơi tư cách thành viên có thể thay đổi trong quá trình blockchain. 2. Giống như trong Lightning Network, người nhận thanh toán trong ILP phải trực tuyến để gửi xác nhận lại cho người gửi. trong mộttoken chuyển qua IBC, bộ validator của máy thu blockchain chịu trách nhiệm cung cấp xác nhận chứ không phải người dùng nhận. 3. Điểm khác biệt nổi bật nhất là đầu nối của ILP không chịu trách nhiệm hoặc giữ thẩm quyền về các khoản thanh toán, trong khi ở Cosmos, validator của trung tâm là thẩm quyền của trạng thái IBC token chuyển giao cũng như thẩm quyền của số lượng token được giữ bởi mỗi vùng (nhưng không phải số lượng token được nắm giữ bởi mỗi tài khoản trong một vùng). Đây là sự đổi mới cơ bản cho phép đảm bảo tính bất đối xứng chuyển token từ vùng này sang vùng khác; tương tự như ILP trình kết nối trong Cosmos là một kết nối ổn định và an toàn tối đa sổ cái blockchain, trung tâm Cosmos. 4. Các khoản thanh toán liên sổ cái trong ILP cần được hỗ trợ bởi một sổ đặt hàng trao đổi, vì không có sự chuyển giao bất đối xứng của tiền từ sổ cái này sang sổ cái khác, chỉ chuyển giá trị hoặc tương đương trên thị trường. Chuỗi bên [15] là cơ chế được đề xuất để mở rộng quy mô Bitcoin mạng thông qua các blockchain thay thế được “chốt hai chiều” với Bitcoin blockchain. (Chốt hai chiều tương đương với bắc cầu. Trong Cosmos chúng tôi nói "bắc cầu" để phân biệt với định vị thị trường). Sidechains cho phép bitcoin di chuyển một cách hiệu quả từ Bitcoin blockchain vào sidechain và ngược lại, đồng thời cho phép thử nghiệm các tính năng mới trên sidechain. Như trong Cosmos Hub, sidechain và Bitcoin đóng vai trò là khách hàng nhẹ của lẫn nhau, sử dụng bằng chứng SPV để xác định khi nào các đồng xu sẽ được được chuyển sang sidechain và ngược lại. Tất nhiên, vì Bitcoin sử dụng proof-of-work, các chuỗi bên xoay quanh Bitcoin bị ảnh hưởng khỏi nhiều vấn đề và rủi ro của proof-of-work như một cơ chế đồng thuận Hơn nữa, đây là một người theo chủ nghĩa tối đa Bitcoin giải pháp vốn không hỗ trợ nhiều loại token và

cấu trúc liên kết mạng liên vùng như Cosmos. Điều đó nói lên rằng, cốt lõi cơ chế của chốt hai chiều về nguyên tắc giống như cơ chế đó được sử dụng bởi mạng Cosmos. Ethereum hiện đang nghiên cứu một số chiến lược khác nhau để phân chia trạng thái của Ethereum blockchain để giải quyết nhu cầu về khả năng mở rộng. Những nỗ lực này nhằm mục đích duy trì lớp trừu tượng được cung cấp bởi Máy ảo Ethereum hiện tại trên không gian trạng thái được chia sẻ. Nhiều nỗ lực nghiên cứu đang đang được tiến hành vào thời điểm này. [18][22] Cosmos và Ethereum 2.0 Màu hoa cà [22] có các mục tiêu thiết kế khác nhau. Cosmos đặc biệt là khoảng tokens. Mauve là về việc mở rộng quy mô tính toán tổng quát. Cosmos không bị ràng buộc với EVM, do đó, ngay cả các máy ảo khác nhau cũng có thể tương tác. Cosmos cho phép người tạo vùng xác định ai xác thực khu. Bất kỳ ai cũng có thể bắt đầu một khu vực mới trong Cosmos (trừ khi quản trị quyết định khác). Hub cách ly các lỗi vùng nên các bất biến token toàn cầu được được bảo tồn. Mạng Lightning là mạng chuyển giao token được đề xuất hoạt động ở lớp phía trên Bitcoin blockchain (và lớp công cộng khác blockchains), cho phép cải thiện nhiều cấp độ lớn trong thông lượng giao dịch bằng cách di chuyển phần lớn các giao dịch ngoài sổ cái đồng thuận vào cái gọi là “kênh thanh toán”.Điều này được thực hiện nhờ các tập lệnh tiền điện tử trên chuỗi, cho phép các bên ký kết các hợp đồng nhà nước song phương trong đó trạng thái có thể được cập nhật bằng cách chia sẻ chữ ký số và hợp đồng có thể bị đóng bằng cách xuất bản bằng chứng đồng thời lên blockchain, một cơ chế lần đầu tiên được phổ biến rộng rãi nhờ sự hoán đổi nguyên tử xuyên chuỗi. Bởi mở kênh thanh toán với nhiều bên, người tham gia Lightning Network có thể trở thành điểm tập trung cho việc định tuyến thanh toán của người khác, dẫn đến một kênh thanh toán được kết nối đầy đủ mạng, với chi phí vốn bị ràng buộc trên các kênh thanh toán. Mặc dù Lightning Network cũng có thể dễ dàng mở rộng khắp nhiều blockchain độc lập để cho phép chuyển giá trị thông qua thị trường trao đổi, nó không thể được sử dụng để chuyển token từ blockchain này sang blockchain khác. Lợi ích chính của mạng Cosmos được mô tả ở đây là kích hoạt trực tiếp như vậy token chuyển khoản. Điều đó nói lên rằng, chúng tôi kỳ vọng các kênh thanh toán và Lightning Network sẽ được áp dụng rộng rãi cùng với token cơ chế chuyển giao, vì lý do tiết kiệm chi phí và bảo mật. Segregated Witness là một liên kết đề xuất cải tiến Bitcoin nhằm mục đích tăng thông lượng giao dịch trên mỗi khối lên gấp 2 lần hoặc 3 lần, đồng thời làm cho việc đồng bộ hóa khối nhanh hơn cho các nút mới. Điểm sáng chói của giải pháp này nằm ở cách nó hoạt động trong hạn chế của giao thức hiện tại của Bitcoin và cho phép phân nhánh mềm nâng cấp (tức là các máy khách có phiên bản phần mềm cũ hơn sẽ tiếp tục hoạt động sau khi nâng cấp). Tendermint, là một sản phẩm mới giao thức, không có hạn chế về thiết kế, vì vậy nó có tỷ lệ khác những ưu tiên. Về cơ bản, Tendermint sử dụng thuật toán quay vòng BFT dựa trên chữ ký mật mã thay vì khai thác, một cách tầm thường cho phép chia tỷ lệ theo chiều ngang thông qua nhiều song song blockchains, trong khi các cam kết khối thường xuyên hơn, thường xuyên hơn cho phép cũng có thể chia tỷ lệ theo chiều dọc.

コンセンサスと技術的詳細

適切に設計されたコンセンサスプロトコルは、いくつかの機能を提供する必要があります。 許容範囲を超えた場合の保証 そしてコンセンサスは失敗します。これは経済面で特に必要です ビザンチンの行動が重大な経済的影響を与える可能性があるシステム 報酬。このような保証の中で最も重要なのは、責任追及の一形態であり、コンセンサスを引き起こしたプロセスが 失敗 (つまり、プロトコルのクライアントが異なる値を受け入れる原因となった - フォーク)は特定され、規則に従って処罰される可能性があります。 議定書、あるいは場合によっては法制度。法制度が整うと、 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

�� えー

Sự đồng thuận và chi tiết kỹ thuật

Một giao thức đồng thuận được thiết kế tốt sẽ cung cấp một số đảm bảo trong trường hợp vượt quá khả năng chịu đựng và sự đồng thuận không thành công. Điều này đặc biệt cần thiết trong nền kinh tế các hệ thống, nơi hành vi của Byzantine có thể có tác động tài chính đáng kể phần thưởng. Sự đảm bảo quan trọng nhất như vậy là một hình thức phân tách trách nhiệm, trong đó các quy trình tạo ra sự đồng thuận thất bại (tức là khiến các máy khách của giao thức chấp nhận các giá trị khác nhau - a nĩa) có thể bị xác định và trừng phạt theo quy định của giao thức, hoặc có thể là hệ thống pháp luật. Khi hệ thống pháp luật được không đáng tin cậy hoặc quá tốn kém để gọi, validators có thể buộc phải đặt cọc tiền bảo đảm để tham gia, và những tiền gửi có thể bị thu hồi hoặc bị cắt giảm khi có hành vi nguy hiểm đã phát hiện [10]. Lưu ý rằng điều này không giống như Bitcoin, trong đó việc phân nhánh là chuyện thường xuyên xảy ra do mạng không đồng bộ và tính chất xác suất của kết quả hash va chạm một phần. Vì trong nhiều trường hợp một fork độc hại có thể không thể phân biệt được với ngã ba do không đồng bộ, Bitcoin không thể thực hiện một cách đáng tin cậy trách nhiệm giải trình của ngã ba, ngoại trừ ngầm định chi phí cơ hội mà thợ mỏ phải trả khi khai thác một khối mồ côi. Chúng tôi gọi giai đoạn bỏ phiếu là PreVote và PreCommit. Một cuộc bỏ phiếu có thể dành cho một khối cụ thể hoặc cho Nil. Chúng tôi gọi một tập hợp >⅔ Phiếu bầu trước cho một khối trong cùng một vòng, một Polka và một bộ sưu tập >⅔ Cam kết trước cho một khối trong cùng một vòng Cam kết. Nếu >⅔ Cam kết trước cho Nil trong cùng một vòng, họ sẽ chuyển sang vòng tiếp theo tròn. Lưu ý rằng tính xác định nghiêm ngặt trong giao thức phát sinh một điểm yếu giả định đồng bộ là các nhà lãnh đạo bị lỗi phải được phát hiện và

bỏ qua. Vì vậy, validator hãy đợi một khoảng thời gian, Hết thời gianĐề xuất, trước khi họ bỏ phiếu trước cho con số không và giá trị của Thời gian chờĐề xuất tăng theo mỗi vòng. Tiến triển thông qua phần còn lại của vòng hoàn toàn không đồng bộ, trong tiến trình đó chỉ có được thực hiện khi validator nghe được từ >⅔ mạng. Trong thực tế, phải có một đối thủ cực kỳ mạnh mới có thể ngăn cản được giả định về tính đồng bộ yếu (làm cho sự đồng thuận không thành công) từng thực hiện một khối) và làm như vậy có thể còn được thực hiện nhiều hơn khó khăn bằng cách sử dụng các giá trị ngẫu nhiên của TimeoutPropose trên mỗi validator. Một tập hợp các ràng buộc bổ sung, hoặc Quy tắc khóa, đảm bảo rằng mạng cuối cùng sẽ chỉ cam kết một khối ở mỗi độ cao. bất kỳ nỗ lực ác ý nhằm thực hiện nhiều hơn một khối ở một độ cao nhất định có thể được xác định. Đầu tiên, PreCommit cho một khối phải đi kèm với sự biện minh, dưới dạng Polka cho khối đó. Nếu validator đã PreCommit một khối ở vòng R_1, chúng tôi nói rằng họ bị khóa ở khu nhà đó và Polka dùng để biện minh cho việc đó PreCommit mới ở vòng R_2 phải có trong vòng R_polka trong đó R_1 < R_polka <= R_2. Thứ hai, validators phải Đề xuất và/hoặc Bỏ phiếu trước cho khối mà họ đang bị khóa. Cùng với nhau, những điều này điều kiện đảm bảo rằng validator không PreCommit mà không có có đủ bằng chứng để biện minh và validator có PreCommit đã không thể đóng góp bằng chứng cho PreCommit một cái gì đó khác. Điều này đảm bảo cả sự an toàn và sự sống động của thuật toán đồng thuận. Các chi tiết đầy đủ của giao thức được mô tả ở đây. Nhu cầu đồng bộ hóa tất cả các tiêu đề khối bị loại bỏ trong TendermintPoS vì sự tồn tại của một chuỗi thay thế (một nhánh) có nghĩa là ≥⅓ của cổ phần ngoại quan có thể được cắt giảm. Tất nhiên, vì việc chém đòi hỏi rằng ai đó chia sẻ bằng chứng về một fork, light client nên lưu trữ bất kỳ khối-hash nào cam kết rằng nó nhìn thấy. Ngoài ra, các client nhẹcó thể được đồng bộ hóa định kỳ với các thay đổi đối với bộ validator, trong để tránh các cuộc tấn công tầm xa (nhưng các giải pháp khác có thể). Với tinh thần tương tự Ethereum, Tendermint cho phép các ứng dụng nhúng gốc Merkle toàn cầu hash vào mỗi khối, cho phép dễ dàng truy vấn trạng thái có thể kiểm chứng được về những thứ như số dư tài khoản, giá trị được lưu trữ trong hợp đồng hoặc sự tồn tại của một giao dịch chưa được chi tiêu đầu ra, tùy thuộc vào tính chất của ứng dụng. Giả sử một tập hợp các mạng phát sóng có đủ khả năng phục hồi và một bộ validator tĩnh, bất kỳ phân nhánh nào trong blockchain đều có thể bị phát hiện và số tiền gửi của validator vi phạm bị cắt giảm. Cái này sự đổi mới, được đề xuất lần đầu tiên bởi Vitalik Buterin vào đầu năm 2014, giải quyết vấn đề không có gì đáng lo ngại của proof-of-stake khác tiền điện tử (xem Công việc liên quan). Tuy nhiên, vì validator đặt phải có khả năng thay đổi, trong một khoảng thời gian dài, bản gốc validator đều có thể không được liên kết và do đó có thể tự do tạo một chuỗi mới từ khối gốc, không phát sinh chi phí như họ không còn tiền gửi bị khóa nữa. Cuộc tấn công này đã xảy ra được gọi là Tấn công tầm xa (LRA), trái ngược với Tấn công ngắn Tấn công tầm xa, trong đó validator hiện đang được liên kết gây ra fork và do đó có thể bị trừng phạt (giả sử một fork chịu trách nhiệm BFT thuật toán như sự đồng thuận của Tendermint). Tấn công tầm xa là thường được cho là đòn chí mạng đối với proof-of-stake. May mắn thay, LRA có thể được giảm nhẹ như sau. Đầu tiên, đối với một validator hủy trái phiếu (do đó lấy lại tiền ký quỹ của họ và không còn kiếm được phí để tham gia vào sự đồng thuận), tiền gửi phải được đặt ở mức không thể chuyển nhượng trong một khoảng thời gian được gọi là “thời kỳ không liên kết”, có thể theo thứ tự tuần hoặc tháng. Thứ hai, để một khách hàng hạng nhẹ được an toàn, lần đầu tiên khi kết nối với mạng, nó phải xác minh khối gần đây-hash chống lại một nguồn đáng tin cậy, hoặc tốt nhất là nhiều nguồn. Cái này

điều kiện đôi khi được coi là “tính chủ quan yếu”. Cuối cùng, để duy trì tính bảo mật, nó phải đồng bộ hóa với validator mới nhất được đặt tại ít nhất là thường xuyên như độ dài của thời kỳ không liên kết. Cái này đảm bảo rằng ứng dụng khách nhẹ biết về những thay đổi đối với validator được đặt trước validator có vốn không bị ràng buộc và do đó không còn đang bị đe dọa, điều này sẽ cho phép nó đánh lừa khách hàng bằng cách thực hiện một cuộc tấn công tầm xa bằng cách tạo các khối mới bắt đầu từ chiều cao nơi nó được liên kết (giả sử nó có đủ khả năng kiểm soát nhiều khóa riêng đầu tiên). Lưu ý rằng việc khắc phục LRA theo cách này đòi hỏi phải xem xét lại mô hình bảo mật ban đầu của proof-of-work. Trong PoW, đó là giả sử rằng một máy khách nhẹ có thể đồng bộ hóa với chiều cao hiện tại từ khối gốc đáng tin cậy bất cứ lúc nào chỉ bằng cách xử lý bằng chứng công việc trong mỗi tiêu đề khối. Tuy nhiên, để khắc phục LRA, chúng tôi yêu cầu một khách hàng nhỏ phải lên mạng thường xuyên để theo dõi các thay đổi trong bộ validator và lần đầu tiên chúng khi trực tuyến họ phải đặc biệt cẩn thận để xác thực những gì họ nghe được từ mạng so với các nguồn đáng tin cậy. của Tất nhiên, yêu cầu sau này tương tự như yêu cầu của Bitcoin, trong đó giao thức và phần mềm cũng phải được lấy từ một cơ quan đáng tin cậy nguồn. Phương pháp ngăn chặn LRA ở trên rất phù hợp với validators và các nút đầy đủ của blockchain được hỗ trợ bởi Tendermint vì những nút này các nút có nghĩa là vẫn được kết nối với mạng. các Phương pháp này cũng phù hợp với những khách hàng nhẹ nhàng có thể mong đợi đồng bộ với mạng thường xuyên. Tuy nhiên, đối với những khách hàng nhẹ thì dự kiến sẽ không có quyền truy cập thường xuyên vào internet hoặc các blockchain mạng, nhưng có thể sử dụng một giải pháp khác để khắc phục LRA. Những người không thuộc validator token chủ sở hữu có thể đăng token của họ dưới dạng tài sản thế chấp có thời hạn không ràng buộc rất dài (ví dụ: dài hơn nhiều hơn khoảng thời gian không liên kết trong validator giây) và phục vụ các khách hàng nhẹ bằng phương pháp thứ cấp để chứng thực tính hợp lệ của thông tin hiện hành và khối quá khứ-hashes. Mặc dù những token này không được tính vào bảo mật cho sự đồng thuận của blockchain, tuy nhiên họ có thểcung cấp sự đảm bảo mạnh mẽ cho các khách hàng nhẹ. Nếu khối lịch sử-hash truy vấn được hỗ trợ trong Ethereum, bất kỳ ai cũng có thể liên kết token trong smart contract được thiết kế đặc biệt và cung cấp dịch vụ chứng thực được trả tiền, tạo ra một thị trường hiệu quả cho bảo mật LRA của khách hàng nhẹ. Do sự từ chối của cam kết khối, bất kỳ liên minh ≥⅓ nào của quyền biểu quyết có thể tạm dừng blockchain bằng cách tắt zine hoặc không phát sóng phiếu bầu của họ. Một liên minh như vậy cũng có thể kiểm duyệt các giao dịch cụ thể bằng cách từ chối các khối bao gồm những giao dịch này giao dịch, mặc dù điều này sẽ dẫn đến một tỷ lệ đáng kể số đề xuất chặn bị từ chối, điều này sẽ làm chậm tốc độ cam kết khối của blockchain, làm giảm tiện ích và giá trị của nó. Liên minh độc hại cũng có thể phát tán phiếu bầu một cách nhỏ giọt nên để nghiền nát khối blockchain cam kết gần như dừng lại hoặc tham gia vào bất kỳ sự kết hợp nào của các cuộc tấn công này. Cuối cùng, nó có thể gây ra blockchain phân nhánh, bằng cách ký hai lần hoặc vi phạm khóa quy luật. Nếu một đối thủ hoạt động toàn cầu cũng tham gia, nó có thể phân chia mạng theo cách mà có thể có vẻ như sai tập hợp con validator là nguyên nhân gây ra tình trạng chậm lại. Đây không phải là chỉ là một hạn chế của Tendermint, mà đúng hơn là một hạn chế của tất cả các giao thức đồng thuận có mạng lưới có khả năng được kiểm soát bởi một đối thủ tích cực. Đối với những kiểu tấn công này, một tập hợp con của validator sẽ phối hợp thông qua các phương tiện bên ngoài để ký một đề xuất tái tổ chức chọn một ngã ba (và bất kỳ bằng chứng nào về nó) và tập hợp con ban đầu của validator có chữ ký của họ. Những người xác thực ký một đề xuất tái tổ chức như vậy sẽ từ bỏ tài sản thế chấp của họ trên tất cả các nhánh khác. Khách hàng nên xác minh các chữ ký trong đề xuất tái tổ chức, xác minh mọi bằng chứng, và đưa ra phán quyết hoặc nhắc nhở người dùng cuối đưa ra quyết định. cho Ví dụ: ứng dụng ví điện thoại có thể nhắc người dùng về bảo mật

cảnh báo, trong khi tủ lạnh có thể chấp nhận bất kỳ đề xuất tái tổ chức nào được ký bởi +½ trong số validator ban đầu theo quyền biểu quyết. Không có thuật toán chịu lỗi Byzantine không đồng bộ nào có thể xảy ra đạt được sự đồng thuận khi ≥⅓ quyền biểu quyết là không trung thực, nhưng vẫn có một fork giả định rằng ≥⅓ quyền biểu quyết đã không trung thực bởi ký hai lần hoặc thay đổi khóa mà không có lý do chính đáng. Vì vậy, việc ký kết đề xuất tái tổ chức là một vấn đề phối hợp không thể giải quyết được được giải quyết bằng bất kỳ giao thức không đồng bộ nào (tức là tự động và mà không đưa ra giả định về độ tin cậy của mạng cơ bản). Hiện tại, chúng tôi để vấn đề phối hợp đề xuất tổ chức lại cho sự phối hợp của con người thông qua sự đồng thuận xã hội. trên phương tiện truyền thông internet. Người xác nhận phải cẩn thận để đảm bảo rằng có không có phân vùng mạng nào còn lại trước khi ký một đề xuất tái tổ chức, để tránh tình huống hai đề xuất tái tổ chức xung đột được ký kết. Giả sử rằng phương tiện và giao thức phối hợp bên ngoài là mạnh mẽ, theo đó việc phân nhánh ít được quan tâm hơn việc kiểm duyệt các cuộc tấn công. Ngoài fork và kiểm duyệt, yêu cầu ≥⅓ Byzantine quyền biểu quyết, một liên minh có >⅔ quyền biểu quyết có thể vi phạm trạng thái tùy ý, không hợp lệ. Đây là đặc điểm của bất kỳ (BFT) nào hệ thống đồng thuận. Không giống như ký kép, tạo ra các nhánh với bằng chứng dễ dàng xác minh, phát hiện sự cam kết của một trạng thái không hợp lệ yêu cầu các đồng nghiệp không xác thực phải xác minh toàn bộ khối, ngụ ý rằng họ giữ một bản sao cục bộ của trạng thái và thực thi mỗi giao dịch, tính toán gốc trạng thái một cách độc lập cho chính họ. Một khi đã được phát hiện, cách duy nhất để xử lý lỗi đó là là thông qua sự đồng thuận xã hội. Ví dụ: trong các tình huống Bitcoin đã thất bại, cho dù việc phân nhánh do lỗi phần mềm (như vào tháng 3 2013), hoặc phạm phải trạng thái không hợp lệ do hành vi của Byzantine thợ mỏ (như vào tháng 7 năm 2015), cộng đồng được kết nối tốt của doanh nghiệp, nhà phát triển, thợ mỏ và các tổ chức khác đã thiết lập sự đồng thuận xã hội về những hành động thủ công nào được thực hiệnđược yêu cầu bởi những người tham gia để chữa lành mạng. Hơn nữa, kể từ khi validators của Tendermint blockchain có thể được mong đợi có thể xác định được, cam kết của một trạng thái không hợp lệ thậm chí có thể có thể bị trừng phạt bởi luật pháp hoặc một số luật lệ bên ngoài, nếu muốn. ABCI bao gồm 3 loại tin nhắn chính được gửi từ cốt lõi của ứng dụng. Ứng dụng trả lời bằng tin nhắn phản hồi tương ứng. Thông báo  AppendTx  là công cụ chính của ứng dụng. Mỗi giao dịch trong blockchain được gửi cùng với thông báo này. các ứng dụng cần xác thực từng giao dịch nhận được bằng Thông báo AppendTx dựa vào trạng thái hiện tại, giao thức ứng dụng, và thông tin xác thực mật mã của giao dịch. Đã được xác thực giao dịch sau đó cần cập nhật trạng thái ứng dụng - bằng cách liên kết một giá trị vào kho lưu trữ giá trị khóa hoặc bằng cách cập nhật UTXO cơ sở dữ liệu. Thông báo  CheckTx  tương tự như AppendTx nhưng chỉ dành cho xác thực các giao dịch. Lần kiểm tra mempool đầu tiên của Tendermint Core tính hợp lệ của giao dịch với CheckTx và chỉ chuyển tiếp hợp lệ giao dịch với các đồng nghiệp của nó. Các ứng dụng có thể kiểm tra mức tăng dần nonce trong giao dịch và trả về lỗi khi CheckTx nếu nonce đã cũ. Thông báo  Cam kết  được dùng để tính toán mật mã cam kết với trạng thái ứng dụng hiện tại, được đưa vào tiêu đề khối tiếp theo. Điều này có một số thuộc tính tiện dụng. Sự không nhất quán trong việc cập nhật trạng thái đó bây giờ sẽ xuất hiện dưới dạng blockchain nhánh giúp nắm bắt cả lớp lập trình lỗi. Điều này cũng đơn giản hóa sự phát triển của an toàn nhẹ khách hàng, vì bằng chứng Merkle-hash có thể được xác minh bằng cách kiểm tra khối-hash và khối-hash được ký bởi số đại biểu validators (theo quyền biểu quyết).

Thông báo ABCI bổ sung cho phép ứng dụng theo dõi và thay đổi bộ validator và để ứng dụng nhận được chặn thông tin, chẳng hạn như chiều cao và phiếu bầu cam kết. ABCI yêu cầu/phản hồi là các tin nhắn Protobuf đơn giản. Kiểm tra ra lược đồ yle. Lập luận: Dữ liệu ([]byte): Các byte giao dịch yêu cầu Trả về: Mã (uint32): Mã phản hồi Dữ liệu ([]byte): Byte kết quả, nếu có Nhật ký (chuỗi): Gỡ lỗi hoặc thông báo lỗi Cách sử dụng:

Nối và chạy một giao dịch. Nếu giao dịch hợp lệ, trả về CodeType.OK Lập luận: Dữ liệu ([]byte): Các byte giao dịch yêu cầu Trả về: Mã (uint32): Mã phản hồi Dữ liệu ([]byte): Byte kết quả, nếu có Nhật ký (chuỗi): Gỡ lỗi hoặc thông báo lỗi Cách sử dụng:

Xác thực một giao dịch. Thông báo này không được làm thay đổi trạng thái. Giao dịch lần đầu tiên được thực hiện thông qua CheckTx trước phát sóng tới các đồng nghiệp trong lớp mempool. Bạn có thể làm CheckTx bán trạng thái và xóa trạng thái khi Cam kết hoặc BeginBlock , để cho phép các chuỗi giao dịch phụ thuộc trong cùng một khối.

Trả về: Dữ liệu ([]byte): Gốc Merkle hash Nhật ký (chuỗi): Gỡ lỗi hoặc thông báo lỗi Cách sử dụng:

Trả về gốc Merkle hash của trạng thái ứng dụng. Lập luận: Dữ liệu ([]byte): Các byte yêu cầu truy vấn Trả về: Mã (uint32): Mã phản hồi Dữ liệu ([]byte): Các byte phản hồi truy vấn Nhật ký (chuỗi): Gỡ lỗi hoặc thông báo lỗi Cách sử dụng:

Xóa hàng đợi phản hồi. Các ứng dụng thực hiện loại. Ứng dụng không cần triển khai thông báo này - đó là do dự án xử lý. Trả về: Dữ liệu ([]byte): Các byte thông tin Cách sử dụng:

Trả về thông tin về trạng thái ứng dụng. ứng dụng cụ thể. Lập luận: Khóa (chuỗi): Khóa để đặt

Giá trị (chuỗi): Giá trị cần đặt cho khóa Trả về: Nhật ký (chuỗi): Gỡ lỗi hoặc thông báo lỗi Cách sử dụng:

Đặt tùy chọn ứng dụng. Ví dụ. Key=“mode”, Value=“mempool” cho kết nối mempool hoặc Key=“mode”, Value=“consensus” cho một kết nối đồng thuận. Các tùy chọn khác là ứng dụng cụ thể. Lập luận: Trình xác thực ([]Trình xác thực): Nguồn gốc ban đầu-validators Cách sử dụng:

Được gọi một lần khi có nguồn gốc Lập luận: Chiều cao (uint64): Chiều cao khối bắt đầu Cách sử dụng:

Báo hiệu sự bắt đầu của một khối mới. Được gọi trước bất kỳ Nối thêm Tx. Lập luận: Chiều cao (uint64): Chiều cao khối kết thúc Trả về: Trình xác thực ([]Trình xác thực): Đã thay đổi validator bằng mới quyền biểu quyết (0 để loại bỏ) Cách sử dụng:

Báo hiệu sự kết thúc của một khối. Được gọi trước mỗi lần Commit giao dịch Xem kho lưu trữ ABCI để biết thêm chi tiết.Có một số lý do tại sao người gửi có thể muốn xác nhận việc gửi gói tin của chuỗi nhận. Ví dụ, người gửi có thể không biết trạng thái của chuỗi đích nếu nó được cho là có lỗi. Hoặc người gửi có thể muốn áp đặt thời gian chờ cho gói (với  MaxHeight  gói tin), trong khi bất kỳ chuỗi đích nào cũng có thể bị tấn công từ chối dịch vụ với sự gia tăng đột ngột về số lượng gói tin đến. gói. Trong những trường hợp này, người gửi có thể yêu cầu xác nhận việc gửi bằng cách đặt trạng thái gói ban đầu thành  Đang chờ xử lý . Sau đó, nó là trách nhiệm của chuỗi nhận hàng trong việc đồng ý giao hàng bằng cách bao gồm một viết tắt  IBCPacket  trong ứng dụng Merkle hash. Đầu tiên, _IBCBlockCommit  và  IBCPacketTx  được đăng trên “Hub” điều đó chứng tỏ sự tồn tại của _IBCGói  trên “Vùng 1”. Nói thế  IBCPacketTx  có giá trị sau: FromChainID : “Khu vực1” FromBlockHeight : 100 (nói) Gói: một IBCGói:

Tiêu đề : một IBCPacketHeader : SrcChainID: “Vùng 1” DstChainID : “Khu vực2” Số: 200 (giả sử) Trạng thái: Đang chờ xử lý Loại: “đồng xu” MaxHeight : 350 (giả sử “Hub” hiện ở độ cao 300) Tải trọng: Tiếp theo, _IBCBlockCommit  và  IBCPacketTx  được đăng trên “Zone2” điều đó chứng tỏ sự tồn tại của _IBCGói  trên “Hub”. Nói thế  IBCPacketTx  có giá trị sau: FromChainID : “Trung tâm” TừBlockHeight : 300 Gói: một IBCGói: Tiêu đề : một IBCPacketHeader : SrcChainID: “Vùng 1” DstChainID : “Khu vực2” Số lượng: 200 Trạng thái: Đang chờ xử lý Loại: “đồng xu” Chiều cao tối đa: 350 Tải trọng: Tiếp theo, “Zone2” phải bao gồm trong ứng dụng của nó-hash một gói viết tắt hiển thị trạng thái mới của  AckSent . Một _IBCBlockCommit  và  IBCPacketTx  được đăng lại trên “Hub” chứng minh sự tồn tại của một  IBCGói  viết tắt trên "Zone2". Nói như vậy  IBCPacketTx  có giá trị sau: FromChainID : “Khu vực2”

FromBlockHeight : 400 (giả sử) Gói: một IBCGói: Tiêu đề : một IBCPacketHeader : SrcChainID: “Vùng 1” DstChainID : “Khu vực2” Số lượng: 200 Trạng thái: Đã xác nhận Loại: “đồng xu” Chiều cao tối đa: 350 PayloadHash : Cuối cùng, “Hub” phải cập nhật trạng thái của gói tin từ  Đang chờ xác nhận  đến  Đã nhận được. Bằng chứng về tình trạng ynalized mới này nên quay lại "Zone2". Giả sử rằng _IBCPacketTx  có nội dung sau giá trị: FromChainID : “Trung tâm” TừBlockHeight : 301 Gói: một IBCGói: Tiêu đề : một IBCPacketHeader : SrcChainID: “Vùng 1” DstChainID : “Khu vực2” Số lượng: 200 Trạng thái: Đã nhận Loại: “đồng xu” Chiều cao tối đa: 350 PayloadHash : Trong khi đó, “Zone1” có thể lạc quan cho rằng việc giao hàng thành công của gói "đồng xu" trừ khi có bằng chứng ngược lại được chứng minh trên “Trung tâm”. Trong ví dụ trên, nếu “Hub” chưa nhận được  AckSent

trạng thái từ “Zone2” theo khối 350, nó sẽ đặt trạng thái tự động chuyển sang  Hết giờ . Bằng chứng về thời gian chờ này có thể nhận được được đăng lại trên “Zone1” và mọi tokens đều có thể được trả lại. Có hai loại Merkle tree được hỗ trợ trong Hệ sinh thái Tendermint/Cosmos: Cây đơn giản và IAVL+ Cây. Cây đơn giản là Merkle tree cho danh sách các phần tử tĩnh. Nếu số lượng vật phẩm không phải là lũy thừa của hai, một số lá sẽ ở mức mức độ khác nhau. Cây đơn giản cố gắng giữ cả hai mặt của cây cùng chiều cao nhưng bên trái có thể lớn hơn một đơn vị. Merkle tree này là được sử dụng để Merkle-ize các giao dịch của một khối và mức cao nhất các phần tử của trạng thái gốc của ứng dụng.Mục đích của cấu trúc dữ liệu IAVL+ là cung cấp khả năng liên tục lưu trữ các cặp khóa-giá trị ở trạng thái ứng dụng sao cho Căn cứ Merkle xác định hash có thể được tính toán một cách hiệu quả. các cây được cân bằng bằng cách sử dụng một biến thể của thuật toán AVL và tất cả hoạt động là O(log(n)). Trong cây AVL, chiều cao của hai cây con con của bất kỳ nút nào khác nhau nhiều nhất là một. Bất cứ khi nào điều kiện này bị vi phạm cập nhật, cây được cân bằng lại bằng cách tạo các nút mới O(log(n)) trỏ đến các nút chưa được sửa đổi của cây cũ. Trong AVL gốc thuật toán, các nút bên trong cũng có thể chứa các cặp khóa-giá trị. AVL+ thuật toán (lưu ý dấu cộng) sửa đổi thuật toán AVL để giữ tất cả giá trị trên các nút lá, trong khi chỉ sử dụng các nút nhánh để lưu trữ khóa. Điều này giúp đơn giản hóa thuật toán trong khi vẫn giữ dấu vết hash ngắn. Cây AVL+ tương tự như nỗ lực của Patricia của Ethereum. có sự đánh đổi. Khóa không cần phải hashed trước khi chèn vào Cây IAVL+, do đó, điều này mang lại phép lặp có thứ tự nhanh hơn trong khóa không gian có thể mang lại lợi ích cho một số ứng dụng. Logic đơn giản hơn để thực hiện, chỉ yêu cầu hai loại nút – các nút bên trong và các nút lá. Bằng chứng Merkle trung bình ngắn hơn, là một                 *                 / \               /     \             /         \           /             \          *               *         / \            //\        /   \           /   \       /     \        //     \      *       *       *       h6     / \     / \     / \    h0  h1  h2  h3  h4  h5    Một SimpleTree có 7 phần tử

cây nhị phân cân bằng. Mặt khác, gốc Merkle của một Cây IAVL+ phụ thuộc vào thứ tự cập nhật. Chúng tôi sẽ hỗ trợ thêm Merkle trees hiệu quả, chẳng hạn như Ethereum Patricia Trie khi biến thể nhị phân trở thành có sẵn. Trong quá trình triển khai chuẩn, các giao dịch được truyền trực tiếp đến Ứng dụng trung tâm Cosmos qua giao diện ABCI. Trung tâm Cosmos sẽ chấp nhận một số giao dịch chính các loại, bao gồm  SendTx ,  BondTx ,  UnbondTx ,  ReportHackTx ,  SlashTx ,  BurnAtomTx ,  ProposalCreateTx  và  ProposalVoteTx , khá dễ hiểu và sẽ được ghi lại trong một sửa đổi trong tương lai của bài viết này. Ở đây chúng tôi ghi lại hai vấn đề chính loại giao dịch cho IBC:  IBCBlockCommitTx  và  IBCPacketTx . Giao dịch  IBCBlockCommitTx  bao gồm: ChainID (chuỗi): ID của blockchain BlockHash ([]byte): Các byte block-hash, gốc Merkle bao gồm ứng dụng-hash BlockPartsHeader (PartSetHeader): Tiêu đề tập hợp phần khối byte, chỉ cần thiết để xác minh chữ ký biểu quyết BlockHeight (int): Chiều cao của cam kết BlockRound (int) : Vòng cam kết Cam kết ([]Bỏ phiếu) : >⅔ Phiếu cam kết trước Tendermint rằng bao gồm một cam kết khối Trình xác thựcHash ([]byte): Gốc cây Merkle hash của cái mới validator đã đặt

Trình xác thựcHashProof (SimpleProof): Bằng chứng Merkleproof của SimpleTree để chứng minh Trình xác thựcHash so với BlockHash AppHash ([]byte): Gốc cây Merkle IAVLtree hash của trạng thái ứng dụng AppHashProof (SimpleProof): Bằng chứng Merkle SimpleTree dành cho chứng minh AppHash chống lại BlockHash Một _IBCGói  bao gồm: Tiêu đề (IBCPacketHeader): Tiêu đề gói Tải trọng ([]byte): Các byte của tải trọng gói. Tùy chọn PayloadHash ([]byte) : hash cho byte của gói. Tùy chọn Phải có một trong  Payload  hoặc  PayloadHash . hash của  IBCGói  là gốc Merkle đơn giản của hai mục,  Tiêu đề  và  Tải trọng . Một _IBCGói  không có tải trọng đầy đủ được gọi là gói rút gọn. Một _IBCPacketHeader  bao gồm: SrcChainID (chuỗi) : ID nguồn blockchain DstChainID (chuỗi): ID đích blockchain Số (int): Một số duy nhất cho tất cả các gói Trạng thái (enum): Có thể là một trong số AckPending , AckSent , Đã nhận, Không cóAck hoặc Hết thời gian chờ Loại (chuỗi) : Các loại phụ thuộc vào ứng dụng. Cosmos dự trữ loại gói "đồng xu" MaxHeight (int) : Nếu trạng thái không phải là NoAckWanted hoặc AckReceived ở độ cao này, trạng thái sẽ trở thành Timeout . Tùy chọn Giao dịch  IBCPacketTx  bao gồm:FromChainID (string) : ID của blockchain là cung cấp gói này; không nhất thiết phải là nguồn FromBlockHeight (int) : Chiều cao blockchain trong đó gói sau được bao gồm (Merkle-ized) trong khối-hash của chuỗi nguồn Gói (IBCPacket): Một gói dữ liệu có trạng thái có thể là một trong số AckPending , AckSent , AckReceived , NoAck hoặc Timeout PacketProof (IAVLProof): Bằng chứng Merkle IAVLTree để chứng minh hash của gói đối với AppHash của chuỗi nguồn tại chiều cao nhất định Trình tự gửi gói tin từ “Zone1” đến “Zone2” thông qua "Hub" được mô tả trong {Hình X}. Đầu tiên, _IBCPacketTx  chứng minh cho "Hub" rằng gói được đưa vào trạng thái ứng dụng của “Khu 1”. Sau đó, _IBCPacketTx  khác chứng minh cho “Zone2” rằng gói được bao gồm trong trạng thái ứng dụng của “Hub”. Trong thời gian này quy trình, các trường  IBCPacket  giống hệt nhau:  SrcChainID  là luôn là “Zone1” và  DstChainID  luôn là "Zone2".  PacketProof  phải có đường dẫn chống Merkle chính xác, vì sau: Khi “Zone1” muốn gửi gói đến “Zone2” thông qua “Hub”, dữ liệu _IBCGói  giống hệt nhau cho dù gói được Merkleized trên “Zone1”, “Hub” hay “Zone2”. Yeld có thể thay đổi duy nhất là  Trạng thái theo dõi quá trình phân phối. Chúng tôi xin cảm ơn bạn bè và đồng nghiệp đã hỗ trợ trong việc hình thành ý tưởng, xem xét và cung cấp hỗ trợ cho công việc của chúng tôi với Tendermint và Cosmos. IBC///

Zaki Manian của SkuChain đã cung cấp nhiều trợ giúp về định dạng và cách diễn đạt, đặc biệt là trong phần ABCI Jehan Tremback của Althea và Dustin Byington đã giúp đỡ lần lặp ban đầu Andrew Miller của Honey Badger đã đưa ra phản hồi về sự đồng thuận Greg Slepak đã đưa ra phản hồi về sự đồng thuận và cách diễn đạt Cũng xin cảm ơn Bill Gleim và Seunghwan Han vì nhiều đóng góp. Tên và tổ chức của bạn ở đây để đóng góp 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 ZeroCash: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 Nhân chứng tách biệt: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 Mạng Lightning: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 Cây bạc hà dịu dàng: https://github.com/tendermint/tendermint/wiki 9 FLP Không thể thực hiện được: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 Kẻ Chém: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 lượt chia sẻ bit: https://bitshares.org/technology/delegatedproof-of-stake-consensus/

13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 Sổ cái xen kẽ: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15 chuỗi bên: https://blockstream.com/sidechains.pdf 16 Casper: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum Phân mảnh: 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 Bảo mật máy khách mỏng: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 Giấy màu hoa cà: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html

¥ è