Cosmos: شبكة من دفاتر الأستاذ الموزعة
導入
オープンソース エコシステムの総合的な成功により、 分散型ファイル共有とパブリック暗号通貨は、 分散型インターネットプロトコルという理解を促した 社会経済インフラを根本的に改善するために使用できます。 Bitcoin [1] のような特殊な blockchain アプリケーションを見てきました ( 暗号通貨)、Zerocash [2] (プライバシーのための暗号通貨)、および Ethereum [3] などの一般化された smart contract プラットフォーム、 Ethereum Virtual 用の無数の分散アプリケーション Augur (予測市場) や TheDAO などのマシン (EVM) [4] (投資クラブ)。 しかし、これまでに、これらのblockchainは数多くの被害を受けてきました。 総エネルギー効率の悪さ、貧弱な、または パフォーマンスが限られており、ガバナンスメカニズムが未熟です。 Bitcoin のトランザクション スループットを拡張するための提案。たとえば、 Segregated-Witness [5] および BitcoinNG [6] は垂直スケーリングです 単一の物理的な容量によって依然として制限されるソリューション 完全な監査可能性の特性を確保するために、マシン。 ライトニング ネットワーク [7] は、Bitcoin トランザクションのスケールアップに役立ちます
一部の取引を台帳から完全に除外することで取引量を削減し、 少額決済やプライバシー保護に適しています。 支払いレールを備えていますが、より一般化された用途には適していない可能性があります スケーリングのニーズ。 理想的なソリューションは、複数の blockchain を並列に実行できるソリューションです。 セキュリティ特性を維持しながら相互運用できます。これには、 proof-of-work では、不可能ではないにしても、難しいことが証明されています。合併しました たとえば、マイニングでは、親を確保するために行われる作業が可能になります。 チェーンは子チェーンで再利用されますが、トランザクションは依然として 各ノードによって順番に検証され、マージマイニングされた blockchain hash の電源の大部分がオンになっている場合、攻撃に対して脆弱になります。 親は子を積極的にマージマイニングしていません。学術的なレビュー 代替 blockchain ネットワーク アーキテクチャが提供されています 追加のコンテキスト、および他の提案の概要を提供します とその欠点を関連作品で説明します。 ここでは、新しい blockchain ネットワーク アーキテクチャである Cosmos を紹介します。 これらすべての問題に対処します。 Cosmos は多くのネットワークです ゾーンと呼ばれる独立した blockchain。ゾーンの電源は次のとおりです。 高性能を提供する Tendermint Core [8]、 一貫性のある安全な PBFT のようなコンセンサス エンジン。悪意のある者の行動に対して厳格な責任追及保証が保持されます。 俳優たち。 Tendermint Core の BFT コンセンサス アルゴリズムが最適です パブリック proof-of-stake blockchains のスケーリング用。 Cosmos の最初のゾーンは、Cosmos ハブと呼ばれます。 Cosmos Hub は、シンプルな機能を備えたマルチアセット proof-of-stake 暗号通貨です。 ネットワークの適応を可能にするガバナンス メカニズム アップグレードします。さらに、Cosmos ハブは次のように拡張できます。 他のゾーンを接続します。 Cosmos ネットワークのハブとゾーンは以下と通信します。 blockchain 間通信 (IBC) プロトコルを介して相互に、 blockchain の一種の仮想 UDP または TCP。トークンは次のことができます あるゾーンから別のゾーンに安全かつ迅速に転送ゾーン間で流動性を交換する必要はありません。代わりに、 すべてのゾーン間の token 転送は Cosmos ハブを経由します。 各ゾーンが保持する token の合計量を追跡します。の ハブは、各ゾーンを他のゾーンの障害から隔離します。なぜなら 誰でも新しいゾーンを Cosmos ハブに接続できます。ゾーンでは許可されています 新しい blockchain イノベーションとの将来の互換性を実現します。 このセクションでは、Tendermint コンセンサス プロトコルについて説明します。 およびそれを使用してアプリケーションを構築するために使用されるインターフェイス。さらに詳しく 詳細については、付録を参照してください。 古典的なビザンチン フォールト トレラント (BFT) アルゴリズムでは、各ノード 同じ重さです。 Tendermint では、ノードには非負の値があります。 投票権の量と肯定的な投票を持つノード 電力はvalidatorと呼ばれます。バリデーターは 暗号署名をブロードキャストすることによるコンセンサス プロトコル、または 次のブロックに同意するために投票します。 バリデーターの投票権は生成時に決定されるか、 に応じて、blockchain によって決定的に変更されます。 アプリケーション。たとえば、次のような proof-of-stake アプリケーションでは、 Cosmos ハブ、投票力は次によって決定される場合があります。 staking token が担保として保証されます。 注: 2/3 や 1/3 などの端数は、投票総数の端数を指します。 すべての validator を除く、validator の合計数ではありません。 等しい重みを持っています。 >2/3 は「2/3 以上」を意味し、≥1/3 は「少なくとも」を意味します ⅓」。 Tendermint は部分同期 BFT コンセンサス プロトコルです DLS コンセンサス アルゴリズム [20] から派生しました。テンダーミントは
そのシンプルさ、パフォーマンス、フォークの説明責任で注目に値します。 このプロトコルには、固定された既知の validator セットが必要です。 validator は公開鍵によって識別されます。バリデータは次のことを試みます 一度に 1 つのブロックについて合意に達します (ブロックはリストです) 取引の。ブロックのコンセンサスに対する投票は次の手順で行われます。 ラウンドします。各ラウンドにはラウンドリーダー、つまり提案者がいます。 ブロックを提案します。次に、validator は、次のいずれかについて段階的に投票します。 提案されたブロックを受け入れるか、次のラウンドに進みます。の ラウンドの提案者は、順序付けられたものから決定的に選択されます。 投票力に比例した validator のリスト。 プロトコルの完全な詳細はここで説明されています。 Tendermint のセキュリティは、最適な Byzantine の使用に由来します。 超過半数 (>2/3) の投票とロックによるフォールト トレランス 仕組み。これらは連携して次のことを保証します。 違反を引き起こすには 1/3 以上の投票権がビザンチンでなければなりません 安全性。2 つ以上の値がコミットされます。 validator のセットが安全性の侵害に成功した場合、あるいは そうしようとすると、プロトコルによって識別される可能性があります。これ 競合するブロックへの投票とブロードキャストの両方が含まれます 不当な投票。 その強力な保証にもかかわらず、Tendermint は例外的なサービスを提供します パフォーマンス。 7 つのノードに分散された 64 ノードのベンチマーク 5 大陸のデータセンター、コモディティ クラウド インスタンス、 Tendermint コンセンサスは、1 回あたり数千のトランザクションを処理できます。 2 番目は、コミットの遅延が 1 ～ 2 秒程度です。 特に、1 回あたり 1,000 件をはるかに超えるトランザクションのパフォーマンスが優れています。 過酷な敵対状況でも秒速が維持されます。 validator は、悪意を持って作成された投票をクラッシュまたはブロードキャストします。参照 詳細については、以下の図を参照してください。
Tendermint のコンセンサス アルゴリズムの大きな利点は、簡素化されることです。 クライアントのセキュリティが軽いため、モバイルおよび モノのインターネットの使用例。 Bitcoin ライトクライアントは同期する必要がありますが、 ブロックヘッダーのチェーンを検索し、最も証拠のあるものを見つけます。 Tendermint ライト クライアントは変更に対応するだけで済みます。 validator セットに追加し、>2/3 PreCommit を確認します。 最新の状態を判断するための最新ブロック。 簡潔なライト クライアント証明により、inter-blockchain も有効になります コミュニケーション。 Tendermint には、特定の現象を防ぐための保護手段があります。 長距離の何も賭けない二重支払いなどの注目すべき攻撃 そして検閲。これらについては、付録で詳しく説明します。Tendermint コンセンサス アルゴリズムは、 Tendermint Coreと呼ばれるプログラム。テンダーミントコアは、 アプリケーションに依存しない「コンセンサスエンジン」により、あらゆるものを変えることができます。 決定論的なブラックボックス アプリケーションを分散複製される blockchain。 Tendermint Core は blockchain アプリケーションに接続します アプリケーション ブロックチェーン インターフェイス (ABCI) [17] 経由。したがって、ABCI blockchain アプリケーションを任意の形式でプログラムできるようにします コンセンサスが得られるプログラミング言語だけでなく、 さらに、ABCI を使用すると、簡単に 既存の blockchain スタックのコンセンサス層を交換します。 私たちは、よく知られた暗号通貨 Bitcoin から類推します。 Bitcoin は、各ノードが維持する暗号通貨 blockchain です。 完全に監査された未使用トランザクション出力 (UTXO) データベース。もし ある人は、ABCI の上に Bitcoin のようなシステムを作成したいと考えていました。 Tendermint Core が担当するのは、 ノード間でブロックとトランザクションを共有する トランザクションの正規/不変順序の確立 ( blockchain) 一方、ABCI アプリケーションは次のことを担当します。 UTXO データベースの保守 トランザクションの暗号化署名の検証 トランザクションによる存在しない資金の使用を防止する クライアントが UTXO データベースにクエリできるようにする Tendermint は、blockchain デザインを次のように分解できます。 アプリケーションプロセスとの間に非常にシンプルな API を提供します。 コンセンサスプロセス。
مقدمة
النجاح المشترك للنظام البيئي مفتوح المصدر، المشاركة اللامركزية، والعملات المشفرة العامة ألهمت فهم بروتوكولات الإنترنت اللامركزية يمكن استخدامها لتحسين البنية التحتية الاجتماعية والاقتصادية بشكل جذري. لقد رأينا تطبيقات blockchain متخصصة مثل Bitcoin [1] (أ العملة المشفرة)، Zerocash [2] (عملة مشفرة للخصوصية)، و منصات smart contract المعممة مثل Ethereum [3]، مع عدد لا يحصى من التطبيقات الموزعة لـ Etherium Virtual الآلة (EVM) مثل Augur (سوق التنبؤ) وTheDAO [4] (نادي استثماري). ومع ذلك، حتى الآن، عانى هؤلاء blockchain من عدد من المشاكل من العيوب، بما في ذلك عدم كفاءة الطاقة الإجمالية، أو الفقراء أو الأداء المحدود، وآليات الحوكمة غير الناضجة. مقترحات لتوسيع نطاق معاملات Bitcoin، مثل الشاهد المنفصل [5] و BitcoinNG [6]، عبارة عن مقياس رأسي الحلول التي تظل محدودة بقدرة جسدية واحدة الآلة، وذلك لضمان خاصية المراجعة الكاملة. يمكن أن تساعد الشبكة المسرّعة [7] في توسيع نطاق المعاملات Bitcoin
الحجم عن طريق ترك بعض المعاملات خارج دفتر الأستاذ تمامًا، وهو مناسب تمامًا للمدفوعات الصغيرة والحفاظ على الخصوصية قضبان الدفع، ولكنها قد لا تكون مناسبة لمزيد من التعميم احتياجات التحجيم. الحل المثالي هو الذي يسمح بتعدد blockchains المتوازية التفاعل مع الاحتفاظ بخصائصها الأمنية. هذا قد ثبت أنه صعب، إن لم يكن مستحيلاً، مع proof-of-work. تم الدمج التعدين، على سبيل المثال، يسمح بالعمل المنجز لتأمين أحد الوالدين السلسلة ليتم إعادة استخدامها في سلسلة فرعية، ولكن يجب أن تظل المعاملات كذلك تم التحقق من صحتها، بالترتيب، بواسطة كل عقدة، وتم الدمج blockchain يكون عرضة للهجوم إذا كانت أغلبية hashing السلطة على لا يقوم الوالد بدمج تعدين الطفل بشكل نشط. مراجعة أكاديمية يتم توفير بنيات الشبكة البديلة blockchain سياق إضافي، ونقدم ملخصات للمقترحات الأخرى وعيوبها في الأعمال ذات الصلة. نقدم هنا Cosmos، بنية شبكة جديدة blockchain الذي يعالج كل هذه المشاكل. Cosmos عبارة عن شبكة تضم الكثيرين blockchains مستقلة، تسمى المناطق. يتم تشغيل المناطق بواسطة Tendermint Core [8]، والذي يوفر أداءً عاليًا، محرك إجماع متسق وآمن يشبه PBFT، حيث تضمن المساءلة الصارمة للفرعية التحكم في سلوك البرامج الضارة الجهات الفاعلة. تعتبر خوارزمية الإجماع BFT الخاصة بـ Tendermint Core مناسبة تمامًا لتوسيع النطاق العام proof-of-stake blockchains. المنطقة الأولى في Cosmos تسمى Cosmos Hub. Cosmos Hub عبارة عن عملة مشفرة متعددة الأصول proof-of-stake ذات قيمة بسيطة آلية الحوكمة التي تمكن الشبكة من التكيف و ترقية. بالإضافة إلى ذلك، يمكن تمديد المحور Cosmos بواسطة ربط مناطق أخرى. يتواصل مركز ومناطق شبكة Cosmos معها بعضهما البعض عبر بروتوكول اتصال inter-blockchain (IBC)، نوع UDP أو TCP افتراضي لـ blockchains. يمكن أن تكون الرموز يتم نقلها من منطقة إلى أخرى بشكل آمن وسريعدون الحاجة إلى سيولة التبادل بين المناطق. بدلا من ذلك، جميع عمليات النقل بين المناطق token تمر عبر مركز Cosmos، والذي يتتبع المبلغ الإجمالي لـ tokens الذي تحتفظ به كل منطقة. ال يعزل المحور كل منطقة عن فشل المناطق الأخرى. لان يمكن لأي شخص توصيل منطقة جديدة بمركز Cosmos، كما تسمح المناطق بذلك من أجل التوافق المستقبلي مع ابتكارات blockchain الجديدة. في هذا القسم نصف بروتوكول توافق Tendermint والواجهة المستخدمة لبناء التطبيقات بها. للمزيد التفاصيل، انظر الملحق. في الخوارزميات البيزنطية الكلاسيكية المتسامحة مع الأخطاء (BFT)، كل عقدة له نفس الوزن. في Tendermint، العقد لها قيمة غير سلبية مقدار قوة التصويت، والعقد التي لها تصويت إيجابي تسمى الطاقة validators. يشارك المصادقون في بروتوكول الإجماع عن طريق بث التوقيعات المشفرة، أو الأصوات، للاتفاق على الكتلة التالية. يتم تحديد صلاحيات التصويت للمصادقين عند النشأة، أو يتم تحديدها تم تغييره بشكل حتمي بواسطة blockchain، اعتمادًا على application. على سبيل المثال، في تطبيق proof-of-stake مثل مركز Cosmos، قد يتم تحديد قوة التصويت بواسطة مبلغ staking tokens مرهون كضمان. ملاحظة: تشير الكسور مثل ⅔ و⅓ إلى أجزاء من إجمالي التصويت الطاقة، لا العدد الإجمالي لـ validators أبدًا، ما لم يكن كل validators لها وزن متساوي. >⅔ تعني "أكثر من ⅔"، ≥⅓ تعني "على الأقل". ⅓". Tendermint هو بروتوكول إجماع BFT متزامن جزئيًا مشتقة من خوارزمية إجماع DLS [20]. النعناع هو
يتميز ببساطته وأدائه ومسؤوليته. يتطلب البروتوكول مجموعة yxed المعروفة من validators، حيث يكون كل منها يتم التعرف على validator بواسطة مفتاحهم العام. يحاول المدققون القيام بذلك التوصل إلى توافق في الآراء بشأن كتلة واحدة في كل مرة، حيث تكون الكتلة عبارة عن قائمة من المعاملات. يستمر التصويت للتوافق على الكتلة جولات. كل جولة لها قائد مستدير أو مقترح يقترح كتلة. ثم يصوت validators، على مراحل، على ما إذا كان ذلك أم لا لقبول الكتلة المقترحة أو الانتقال إلى الجولة التالية. ال يتم اختيار مقدم العرض للجولة بشكل حتمي من الأمر قائمة validators، بما يتناسب مع قوة التصويت الخاصة بهم. يتم وصف التفاصيل الكاملة للبروتوكول هنا. أمان Tendermint مستمد من استخدامه للبيزنطية المثالية التسامح مع الخطأ من خلال التصويت بالأغلبية العظمى (>⅔) والقفل آلية. ويضمنون معًا ما يلي: ≥⅓ قوة التصويت يجب أن تكون بيزنطية للتسبب في انتهاك السلامة، حيث يتم الالتزام بأكثر من قيمتين. إذا نجحت أي مجموعة من validators في انتهاك السلامة، أو حتى محاولات القيام بذلك، يمكن التعرف عليهم من خلال البروتوكول. هذا يشمل كلا من التصويت للكتل conzicting والبث أصوات غير مبررة على الرغم من ضماناته القوية، يقدم Tendermint منتجات استثنائية الأداء. في معايير 64 عقدة موزعة على 7 مراكز البيانات في 5 قارات، في المثيلات السحابية للسلع الأساسية، يمكن لتوافق Tendermint معالجة آلاف المعاملات لكل ثانيًا، مع فترات استجابة للالتزام تتراوح من ثانية إلى ثانيتين. والجدير بالذكر أن أداء ما يزيد عن ألف معاملة لكل يتم الحفاظ على الثانية حتى في ظروف الخصومة القاسية validators يعطل أو يبث أصواتًا ضارة. انظر ygur أدناه للحصول على التفاصيل.
تم تبسيط إحدى المزايا الرئيسية لخوارزمية الإجماع الخاصة بـ Tendermint أمان العميل الخفيف، مما يجعله مرشحًا مثاليًا للهواتف المحمولة و حالات استخدام إنترنت الأشياء. بينما يجب على العميل الخفيف Bitcoin المزامنة سلاسل رؤوس الكتل والسلسلة التي تحتوي على أكبر دليل على ذلك في العمل، يحتاج عملاء Tendermint Light فقط إلى مواكبة التغييرات إلى مجموعة validator، ثم تحقق من >⅔ PreCommits في أحدث كتلة لتحديد أحدث حالة. تعمل أيضًا أدلة العميل الخفيفة المقتضبة على تمكين inter-blockchain الاتصالات. لدى Tendermint إجراءات وقائية لمنع حدوث بعض الأمراض الهجمات الملحوظة، مثل عمليات الإنفاق المزدوجة بعيدة المدى التي لا تنطوي على أي شيء على المحك والرقابة. وتناقش هذه بشكل كامل في الملحق.يتم تنفيذ خوارزمية إجماع Tendermint في ملف برنامج يسمى Tendermint الأساسية. Tendermint Core هو "محرك الإجماع" الحيادي للتطبيق والذي يمكنه تشغيل أي تطبيق تطبيق الصندوق الأسود الحتمي في نسخة متماثلة موزعة blockchain. يتصل Tendermint Core بتطبيقات blockchain عبر واجهة Blockchain للتطبيق (ABCI) [17]. وبالتالي، ABCI يسمح ببرمجة تطبيقات blockchain في أي اللغة، وليس فقط لغة البرمجة التي تم الإجماع عليها تمت كتابة المحرك. بالإضافة إلى ذلك، ABCI يجعل من الممكن بسهولة قم بتبديل طبقة الإجماع لأي مكدس blockchain موجود. نرسم تشبيهًا بالعملة المشفرة المعروفة Bitcoin. Bitcoin هي عملة مشفرة blockchain حيث تحتفظ كل عقدة قاعدة بيانات لمخرجات المعاملات غير المنفقة (UTXO) المدققة بالكامل. إذا أراد أحدهم إنشاء نظام يشبه Bitcoin أعلى ABCI، سيكون Tendermint Core مسؤولاً عن مشاركة الكتل والمعاملات بين العقد إنشاء ترتيب قانوني/غير قابل للتغيير للمعاملات ( blockchain) وفي الوقت نفسه، سيكون تطبيق ABCI مسؤولاً عن ذلك صيانة قاعدة البيانات UTXO التحقق من صحة التوقيعات المشفرة للمعاملات منع المعاملات من صرف أموال غير موجودة السماح للعملاء بالاستعلام عن قاعدة البيانات UTXO Tendermint قادر على تحليل تصميم blockchain بواسطة تقديم واجهة برمجة تطبيقات بسيطة جدًا بين عملية تقديم الطلب و عملية الإجماع.
Cosmos アーキテクチャ
Cosmos は、独立した並列 blockchain のネットワークです。 それぞれは、次のような古典的な BFT コンセンサス アルゴリズムを利用しています。 テンダーミント1. このネットワークの最初の blockchain が Cosmos ハブになります。の Cosmos ハブは、他の多くの blockchain (またはゾーン) に経由で接続します。 新しいblockchain間通信プロトコル。 Cosmos ハブ 多数の token タイプを追跡し、合計の記録を保持します 接続された各ゾーン内の token の数。トークンは次のことができます あるゾーンから別のゾーンに安全かつ迅速に転送 ゾーン間で液体を交換する必要はありません。 ゾーン間のコイン転送は、Cosmos ハブを経由します。 このアーキテクチャは、blockchain スペースが抱える多くの問題を解決します。 アプリケーションの相互運用性、スケーラビリティ、 シームレスなアップグレード可能。たとえば、Bitcoind から派生したゾーン、 Go-Ethereum、CryptoNote、ZCash、または任意の blockchain システムは、 Cosmos ハブに接続してください。これらのゾーンにより、Cosmos は次のことを行うことができます。 世界的なトランザクション需要に合わせて無限に拡張できます。ゾーンも 分散型取引所にとっては素晴らしい yt であり、次のようにサポートされます。 まあ。 Cosmos は単なる単一の分散台帳ではなく、Cosmos ハブは壁に囲まれた庭園や世界の中心ではありません。私たちは 分散型台帳のオープンネットワーク用のプロトコルの設計 将来の金融システムの新たな基盤として機能する可能性があります。 暗号化、健全な経済学、合意の原則に基づく 理論、透明性、説明責任。 Cosmos ハブは、Cosmos における最初のパブリック blockchain です。 Tendermint の BFT コンセンサス アルゴリズムを利用したネットワーク。の Tendermint オープンソース プロジェクトは、次のような問題に対処するために 2014 年に誕生しました。 Bitcoin のproof-of-workコンセンサスアルゴリズムの速度、スケーラビリティ、環境問題。実績のあるものを使用および改善することにより、
BFT アルゴリズムは 1988 年に MIT で開発されました [20]、Tendermint チームは、proof-of-stake を概念的に実証した最初の人物でした 何も問題がない問題に対処する暗号通貨 第 1 世代 proof-of-stake 暗号通貨の被害 NXT および BitShares1.0 として。 現在、事実上すべての Bitcoin モバイル ウォレットは信頼できるサーバーを使用して、 取引の検証を提供します。これは、proof-of-work では、作業の前に多くの確認を待つ必要があるためです。 トランザクションは不可逆的にコミットされたと見なすことができます。二重支払い攻撃は、次のようなサービスですでに実証されています。 コインベース。 他の blockchain コンセンサス システムとは異なり、Tendermint は以下を提供します 即時かつ確実に安全なモバイルクライアントの支払い検証。 Tendermint は決してフォークしないように設計されているため、モバイル ウォレットは即座にトランザクション確認を受け取ることができるため、 トラストレスで実用的な支払いがスマートフォン上で実現します。これ モノのインターネット アプリケーションに重大な影響を与える まあ。 Cosmos のバリデーターは Bitcoin マイナーと同様の役割を果たしますが、 代わりに暗号署名を使用して投票します。バリデーターは コミットを担当する安全な専用マシン ブロック。 validator 以外のユーザーは、staking token (と呼ばれる) を委任できます。 「アトム」) を任意の validator に送信して、ブロック手数料とアトムの一部を獲得します 報酬は得られますが、次の場合には罰せられる（切り捨てられる）リスクが伴います。 デリゲート validator がハッキングされたか、プロトコルに違反しました。証明された Tendermint BFT コンセンサスの安全性の保証と担保 利害関係者の保証金 – validator および委任者 – が提供する ノードとライトクライアントのための証明可能かつ定量化可能なセキュリティ。 分散型公開台帳には憲法と ガバナンスシステム。 Bitcoin は Bitcoin 財団に依存しており、アップグレードを調整するためにマイニングを行いますが、これには時間がかかります。 Ethereum ハードフォークしてアドレス指定した後、ETH と ETC に分割 DAO ハッキング、主に事前の社会契約がなかったため そのような決定を下すためのメカニズムもありません。 Cosmos ハブの検証者と委任者は、次の項目に投票できます。 システムのプリセットパラメータを変更できる提案 自動的に (ブロックガス制限など)、アップグレードを調整します。 人間が読める憲法の修正案に投票する Cosmos ハブのポリシーを管理します。憲法 などの問題に関して利害関係者間の団結が可能になります。 盗難やバグ (TheDAO インシデントなど) により、より迅速かつ迅速な対応が可能になります。 よりクリーンな解像度。 各ゾーンは独自の憲法と統治を持つこともできます 仕組みも。たとえば、Cosmos ハブには ハブで不変性を強制する構成 (ロールバックなし、 Cosmos ハブ ノード実装のバグを除いて)、 各ゾーンはロールバックに関して独自のポリシーを設定できます。 異なるポリシー ゾーン間の相互運用性を有効にすることで、 Cosmos ネットワークはユーザーに究極の自由と可能性を与えます。 無許可の実験。 ここでは、分散化とスケーラビリティの新しいモデルについて説明します。 Cosmos は、多くの blockchain を搭載したネットワークです。 テンダーミント。既存の提案は「単一の」を作成することを目的としていますが、 blockchain」、グローバル トランザクションの合計順序付け、Cosmos 多数の blockchain を相互に同時に実行できるようにします 相互運用性を維持しながら。 基本的に、Cosmos ハブは多くの独立したものを管理します。 blockchain 「ゾーン」と呼ばれる (以下では「シャード」と呼ばれることもあります) 「シャーディング」として知られるデータベース スケーリング技術を指します)。
に投稿されたゾーンからの最近のブロックコミットの継続的なストリーム ハブにより、ハブは各ゾーンの状態を常に把握できるようになります。 同様に、各ゾーンはハブの状態を常に把握します（ただし、ゾーンは を介して間接的に行われる場合を除いて、互いに連絡を取り合わないでください。 ハブ）。その後、情報のパケットが一方から通信されます。 マークルプルーフを証拠として投稿することで、別のゾーンにゾーンします。 情報が送受信されました。このメカニズムはと呼ばれます blockchain 間通信、または略して IBC。 どのゾーンもそれ自体をハブとして非循環グラフを形成できます。 しかし、明確にするために、簡単なことだけを説明します。 ハブが 1 つだけあり、ハブ以外のものが多数ある構成 ゾーン。 Cosmos ハブは、マルチアセットをホストする blockchain です。 分散型台帳。token は個々のユーザーが保持できます。 ゾーン自体によって。これらのtokenは1つのゾーンから移動できます 「コイン パケット」と呼ばれる特別な IBC パケットで別のパケットに送信します。ハブは 合計の大域的不変性を維持する責任がある ゾーン全体の各 token の量。 IBC コイン パケット トランザクションは送信者、ハブ、受信者によってコミットされる必要があります blockchain秒。Cosmos ハブは全体の中央台帳として機能するため、 システムでは、ハブのセキュリティが最も重要です。その間 各ゾーンは、次のように保護される Tendermint blockchain である可能性があります。 4 つほど少ない (BFT コンセンサスが必要ない場合はさらに少ない)、ハブ グローバルに分散された validator のセットによって保護される必要があります。 などの最も厳しい攻撃シナリオに耐えることができます。 大陸ネットワークの分割または国家支援による攻撃。 Cosmos ゾーンは、IBC を交換する独立した blockchain です。 ハブとのメッセージ。ハブの観点から見ると、ゾーンは マルチアセット ダイナミック メンバーシップ マルチシグネチャ アカウント IBC パケットを使用して token を送受信できます。のように 暗号通貨アカウントでは、ゾーンは token を超えて転送することはできません 持っていますが、token を持っている他のユーザーから token を受け取る可能性があります。ゾーン 1 つ以上の token タイプの「ソース」として指定できます。 token 電源を注入する電力を与えます。 Cosmos ハブのアトムは、ゾーンの validator によってステーキングされる可能性があります ハブに接続されています。これらのゾーンへの二重攻撃攻撃中 その結果、投票権の 2/3 を超えるゾーンであるテンダーミントの責任追及の責任が大幅に削減されることになるでしょう。 Byzantine は無効な状態をコミットする可能性があります。 Cosmos ハブは、 他のゾーンでコミットされたトランザクションを検証または実行するため、 ユーザーは、信頼するゾーンに token を送信する責任があります。 将来的には、Cosmos ハブのガバナンス システムがハブを追い越す可能性があります。 ゾーンの障害を考慮した改善提案。のために たとえば、一部 (またはすべて) ゾーンからのアウトバウンド token 転送は、 ゾーンの緊急サーキットブレークを可能にするためにスロットルされる (token 転送の一時停止) 攻撃が検出されたとき。 ここで、ハブとゾーンがそれぞれとどのように通信するかを見てみましょう。 その他。たとえば、「Zone1」、「Zone2」という 3 つの blockchain がある場合、
と「ハブ」。「ゾーン 1」が次の宛先のパケットを生成することを望みます。 「Hub」を経由する「Zone2」の場合。パケットをあるものから移動するには blockchain を別のユーザーに送信すると、プルーフが受信チェーンに投稿されます。 証拠は、送信チェーンがパケットをパブリッシュしたことを示しています。 疑わしい目的地。受信チェーンがこの証明をチェックするには、 送信者のブロックヘッダーを追跡できる必要があります。これ このメカニズムはサイドチェーンで使用されるものと似ています。 相互作用する 2 つのチェーンが、 存在証明データグラムの双方向ストリーム (トランザクション)。 IBC プロトコルは、当然のことながら 2 種類の トランザクション: IBCBlockCommitTx トランザクション。 blockchain は、最新のブロック hash を観察者に証明します。 IBCPacketTx トランザクションにより、blockchain は 指定されたパケットが実際にパブリッシュされたことをオブザーバーに証明する 送信者のアプリケーションによる、最近のメールに対するマークルプルーフを介した ブロック-hash。 IBC メカニズムを 2 つの別々のトランザクションに分割することで、 受信チェーンのネイティブ料金市場メカニズムを許可します。 どのパケットがコミットされるか (つまり、確認応答されるか) を決定します。 どのように送信するかについて、送信チェーン上で完全な自由を許可します。 多くの送信パケットが許可されます。 上記の例では、「Zone1」のブロック-hashを更新するには 「ハブ」（または「Zone2」の「ハブ」）上、IBCBlockCommitTxトランザクションは、ブロック-hash を使用して「ハブ」に投稿する必要があります。 「ゾーン 1」 (または「ハブ」のブロック hash を持つ「ゾーン 2」)。 詳細については、IBCBlockCommitTx および IBCPacketTx を参照してください。 2 つの IBC トランザクション タイプについて。 Bitcoin が分散型であることで安全性が高まるのと同じように、 台帳を大量に複製することで、取引所の脆弱性を軽減できます。 blockchain で実行することで、外部および内部のハッキングを実行できます。私たち これを分散型交換と呼びます。 暗号通貨コミュニティが分散型と呼ぶもの 今日の取引所は、「アトミック クロスチェーン」（AXC）トランザクションと呼ばれるものに基づいています。 AXC トランザクションでは、2 人のユーザーが 2 つの異なるチェーンは 2 つの転送トランザクションを実行できます。 両方の台帳で一緒にコミットされるか、まったくコミットされない（すなわち、 原子的に）。たとえば、2 人のユーザーがビットコインをイーサ (または 2 つの異なる台帳上の任意の 2 つの token)、AXC トランザクションを使用し、 Bitcoin と Ethereum がそれぞれに接続されていない場合でも その他。 AXC トランザクションで取引所を運営する利点は次のとおりです。 どちらのユーザーもお互いを信頼する必要も、トレードマッチングを信頼する必要もありません サービス。欠点は、双方がオンラインである必要があることです。 起こる貿易。 もう 1 つのタイプの分散型取引所は、大量複製です。 独自の blockchain で実行される分散型交換。上のユーザー この種の取引所は指値注文を発行して、 コンピュータの電源をオフにすると、ユーザーが操作しなくても取引を実行できます。 オンライン。 blockchain が一致し、代わりに取引を完了します トレーダーの。
Cosmos الهندسة المعمارية
Cosmos عبارة عن شبكة متوازية مستقلة blockchains كل منها مدعوم بخوارزميات الإجماع الكلاسيكية BFT مثل النعناع 1. سيكون blockchain الأول في هذه الشبكة هو Cosmos Hub. ال Cosmos يتصل المحور بالعديد من blockchains (أو المناطق) عبر بروتوكول اتصال جديد بين blockchain. المركز Cosmos يتتبع العديد من أنواع token ويحتفظ بسجل للمجموع عدد tokens في كل منطقة متصلة. يمكن أن تكون الرموز يتم نقلها من منطقة إلى أخرى بشكل آمن وسريع دون الحاجة إلى تبادل السوائل بين المناطق، لأن جميعها تتم عمليات تحويل العملات بين المناطق عبر مركز Cosmos. تعمل هذه البنية على حل العديد من المشكلات المتعلقة بمساحة blockchain يواجه اليوم، مثل قابلية التشغيل البيني للتطبيقات، وقابلية التوسع، و إمكانية الترقية السلسة. على سبيل المثال، المناطق المشتقة من Bitcoind، يمكنك الانتقال إلى Ethereum أو CryptoNote أو ZCash أو أي نظام blockchain يتم توصيله بمركز Cosmos. تسمح هذه المناطق لـ Cosmos بذلك التوسع بشكل لا نهائي لتلبية الطلب على المعاملات العالمية. المناطق هي أيضا يعد خيارًا رائعًا للتبادل الموزع، والذي سيتم دعمه كـ حسنا. Cosmos ليس مجرد دفتر أستاذ موزع، وCosmos Hub ليس حديقة مسورة أو مركز الكون. نحن كذلك تصميم بروتوكول لشبكة مفتوحة من دفاتر الأستاذ الموزعة والتي يمكن أن تكون بمثابة أساس جديد للأنظمة المالية المستقبلية، على أساس مبادئ التشفير والاقتصاد السليم والإجماع النظرية والشفافية والمساءلة. يعد مركز Cosmos هو المركز العام الأول blockchain في Cosmos الشبكة، مدعومة بخوارزمية الإجماع BFT الخاصة بـ Tendermint. ال تم إنشاء مشروع Tendermint مفتوح المصدر في عام 2014 لمعالجة المشكلة السرعة وقابلية التوسع والمشكلات البيئية المتعلقة بخوارزمية إجماع إثبات العمل الخاصة بـ Bitcoin. باستخدام وتحسين ما ثبت
BFT خوارزميات تم تطويرها في معهد ماساتشوستس للتكنولوجيا في عام 1988 [20]، Tendermint كان الفريق أول من قدم عرضًا مفاهيميًا لـ proof-of-stake عملة مشفرة تعالج مشكلة عدم وجود شيء على المحك عانى الجيل الأول من العملات المشفرة proof-of-stake مثل مثل NXT وBitShares1.0. اليوم، تستخدم جميع محافظ الهاتف المحمول Bitcoin تقريبًا خوادم موثوقة تزويدهم بالتحقق من المعاملة. وذلك لأن إثبات العمل يتطلب انتظار العديد من التأكيدات قبل يمكن اعتبار المعاملة ملتزمة بشكل لا رجعة فيه. لقد تم بالفعل عرض هجمات Doublespend على خدمات مثل CoinBase. على عكس أنظمة الإجماع blockchain الأخرى، تقدم Tendermint التحقق من الدفع عبر الهاتف المحمول بشكل فوري وآمن. نظرًا لأن Tendermint مصمم بحيث لا يتشعب أبدًا على الإطلاق، فهو متنقل يمكن أن تتلقى المحافظ تأكيدًا فوريًا للمعاملات، مما يجعل المدفوعات غير الموثوقة والعملية حقيقة واقعة على الهواتف الذكية. هذا له تأثيرات كبيرة على تطبيقات إنترنت الأشياء مثل حسنا. يتمتع المدققون في Cosmos بدور مماثل لعمال المناجم Bitcoin، ولكن بدلاً من ذلك استخدم التوقيعات المشفرة للتصويت. المصادقون هم آلات آمنة ومخصصة مسؤولة عن الالتزام كتل. يمكن لغير validators تفويض staking tokens (يُسمى "الذرات") إلى أي validator لكسب جزء من رسوم الكتلة والذرة المكافآت، لكنهم يتعرضون لخطر العقاب (القطع) إذا تم اختراق المندوب validator أو انتهاك البروتوكول. ثبت ضمانات سلامة Tendermint BFT الإجماع والضمانات إيداع أصحاب المصلحة – validator والمفوضين – تقديم أمان يمكن إثباته وقابل للقياس للعقد والعملاء الخفيفين. يجب أن تحتوي الدفاتر العامة الموزعة على دستور و نظام الحكم. Bitcoin يعتمد على Bitcoin الأساس والتعدين لتنسيق الترقيات، ولكن هذه عملية بطيئة. تم تقسيم Ethereum إلى ETH وETC بعد التفرع الصعب للمعالجة يعود سبب الاختراق DAO إلى حد كبير إلى عدم وجود عقد اجتماعي مسبق ولا آلية لاتخاذ مثل هذه القرارات. يمكن للمصادقين والمفوضين في Cosmos التصويت عليهم المقترحات التي يمكن أن تغير المعلمات المحددة مسبقًا للنظام تلقائيا (مثل حد الغاز كتلة)، وتنسيق الترقيات، كما وكذلك التصويت على تعديلات الدستور الذي يمكن قراءته بواسطة الإنسان التي تحكم سياسات Cosmos Hub. الدستور يسمح بالتماسك بين أصحاب المصلحة بشأن قضايا مثل السرقة والأخطاء (مثل حادثة DAO)، مما يسمح بإجراء أسرع وأسرع دقة أنظف. يمكن أن يكون لكل منطقة أيضًا دستورها ونظام حكمها الخاص آلية كذلك. على سبيل المثال، يمكن أن يحتوي المركز Cosmos على الدستور الذي يفرض الثبات في المركز (لا يوجد تراجع، حفظ الأخطاء في تنفيذ العقدة المركزية Cosmos)، بينما يمكن لكل منطقة وضع سياساتها الخاصة فيما يتعلق بالتراجع. ومن خلال تمكين إمكانية التشغيل البيني بين مناطق السياسة المختلفة، فإن تمنح شبكة Cosmos مستخدميها الحرية المطلقة والإمكانات تجريب غير مسموح به. نحن هنا نصف نموذجًا جديدًا للامركزية وقابلية التوسع. Cosmos عبارة عن شبكة تضم العديد من blockchains التي يتم تشغيلها بواسطة النعناع. بينما تهدف المقترحات الحالية إلى إنشاء "فردية". blockchain" مع إجمالي طلب المعاملات العالمية، Cosmos يسمح للعديد من blockchains بالعمل بشكل متزامن مع بعضها البعض مع الاحتفاظ بإمكانية التشغيل البيني. في الأساس، يدير Cosmos Hub العديد من المستقلين blockchains تسمى "المناطق" (يشار إليها أحيانًا باسم "الأجزاء"، في إشارة إلى تقنية قياس قاعدة البيانات المعروفة باسم "التقسيم").
دفق مستمر من عمليات الحظر الأخيرة من المناطق المنشورة عليها يسمح Hub للمركز بمواكبة حالة كل منطقة. وبالمثل، فإن كل منطقة تواكب حالة المحور (لكن المناطق لا يواكبون بعضهم البعض إلا بشكل غير مباشر من خلال المحور). ثم يتم إرسال حزم المعلومات من واحدة منطقة إلى أخرى عن طريق نشر أدلة Merkle كدليل على أن تم إرسال المعلومات واستلامها. وتسمى هذه الآلية التواصل بين blockchain، أو IBC للاختصار. يمكن لأي من المناطق أن تكون في حد ذاتها محاورًا لتكوين رسم بياني غير دوري، ولكن من أجل الوضوح سنصف فقط ما هو بسيط conyguration حيث لا يوجد سوى محور واحد، والعديد من غير المحور المناطق. مركز Cosmos هو blockchain الذي يستضيف أصولًا متعددة دفتر الأستاذ الموزع، حيث يمكن الاحتفاظ بـ tokens بواسطة مستخدمين فرديين أو حسب المناطق نفسها. يمكن نقل هذه tokens من منطقة واحدة إلى أخرى في حزمة خاصة IBC تسمى "حزمة العملات المعدنية". المحور هو مسؤولة عن الحفاظ على الثبات العالمي للمجموع مقدار كل token عبر المناطق. IBC حزمة العملات المعدنية يجب أن يتم تنفيذ المعاملات من قبل المرسل والمركز والمتلقي blockchains.نظرًا لأن Cosmos Hub يعمل بمثابة دفتر الأستاذ المركزي للكل النظام، فإن أمن المركز له أهمية قصوى. بينما قد تكون كل منطقة عبارة عن Tendermint blockchain مؤمنة بواسطة as عدد قليل يصل إلى 4 (أو حتى أقل إذا لم يكن هناك حاجة إلى إجماع BFT)، المحور يجب تأمينها من خلال مجموعة لامركزية عالميًا من validators يمكن أن تصمد أمام سيناريوهات الهجوم الأكثر خطورة، مثل تقسيم الشبكة القارية أو هجوم ترعاه الدولة القومية. منطقة Cosmos هي منطقة blockchain مستقلة تتبادل IBC الرسائل مع المحور. من وجهة نظر المحور، المنطقة هي أ حساب متعدد التوقيع للعضوية الديناميكية المتعددة الأصول يمكن إرسال واستقبال tokens باستخدام IBC الحزم. مثل أ حساب العملة المشفرة، لا يمكن للمنطقة نقل أكثر من tokens من إنه موجود بالفعل، ولكن يمكنه تلقي tokens من الآخرين الذين لديهم تلك الرسائل. منطقة قد يتم تعيينه كـ "مصدر" لواحد أو أكثر من أنواع token، ومنحها القدرة على تعزيز هذا العرض token. قد يتم تثبيت ذرات المركز Cosmos بواسطة validators في المنطقة متصل بالمحور. بينما تشن الهجمات المزدوجة الإنفاق على هذه المناطق من شأنه أن يؤدي إلى خفض الذرات مع المسؤولية الجزئية لـ Tendermint، وهي منطقة حيث يكون >⅔ من قوة التصويت يمكن للبيزنطيين ارتكاب حالة باطلة. مركز Cosmos لا يفعل ذلك التحقق من أو تنفيذ المعاملات المرتكبة في مناطق أخرى، لذلك هو عليه مسؤولية المستخدمين عن إرسال tokens إلى المناطق التي يثقون بها. في المستقبل، قد يجتاز نظام إدارة Cosmos Hub Hub مقترحات التحسين التي تفسر فشل المنطقة. ل على سبيل المثال، قد تكون عمليات النقل الصادرة token من بعض (أو جميع) المناطق يتم خنقها للسماح بقطع دائرة الطوارئ للمناطق (وقف مؤقت لعمليات نقل token) عند اكتشاف هجوم. الآن ننظر إلى كيفية تواصل المركز والمناطق مع كل منهما أخرى. على سبيل المثال، إذا كان هناك ثلاثة blockchains، "Zone1"، "Zone2"،
و"Hub"، ونتمنى أن تقوم "Zone1" بإنتاج حزمة متجهة بالنسبة لـ "Zone2" التي تمر عبر "Hub". لنقل حزمة من واحد blockchain إلى آخر، يتم نشر إثبات على سلسلة الاستلام. يشير الدليل إلى أن سلسلة الإرسال نشرت حزمة لـ الوجهة المزعومة لكي تتحقق السلسلة المتلقية من هذا الإثبات، يجب عليها يجب أن يكون قادرًا على مواكبة رؤوس كتلة المرسل. هذا الآلية مشابهة لتلك المستخدمة في السلاسل الجانبية، الأمر الذي يتطلب سلسلتين متفاعلتين لتكون على علم ببعضهما البعض عبر أ تيار ثنائي الاتجاه من مخططات بيانات إثبات الوجود (المعاملات). من الطبيعي أن يتم فك بروتوكول IBC باستخدام نوعين من المعاملات: معاملة IBCBlockCommitTx ، والتي تسمح بـ blockchain لإثبات لأي مراقب أحدث كتلة لها-hash، ومعاملة IBCPacketTx، والتي تسمح لـ blockchain بـ أثبت لأي مراقب أن الحزمة المحددة قد تم نشرها بالفعل عن طريق تطبيق المرسل، عبر خاصية Merkle-proof للأحدث كتلة-hash. من خلال تقسيم آليات IBC إلى معاملتين منفصلتين، فإننا السماح لآلية سوق الرسوم المحلية لسلسلة الاستقبال بذلك تحديد الحزم التي سيتم الالتزام بها (أي تم الاعتراف بها)، بينما السماح بالحرية الكاملة لسلسلة الإرسال فيما يتعلق بكيفية ذلك يُسمح بالعديد من الحزم الصادرة. في المثال أعلاه، من أجل تحديث الكتلة-hash الخاصة بـ "Zone1" على "Hub" (أو "Hub" في "Zone2")، IBCBlockCommitTxيجب نشر المعاملة على "المركز" مع الكتلة-hash من "Zone1" (أو على "Zone2" مع الكتلة-hash من "Hub"). راجع IBCBlockCommitTx وIBCPacketTx لمزيد من المعلومات على نوعي المعاملات IBC. بنفس الطريقة التي يكون بها Bitcoin أكثر أمانًا من خلال كونه موزعًا، يمكننا أن نجعل التبادلات أقل عرضة للخطر اختراقات خارجية وداخلية عن طريق تشغيله على blockchain. نحن نسمي هذا التبادل الموزع. ما يسميه مجتمع العملات المشفرة اللامركزية تعتمد البورصة اليوم على ما يسمى معاملات "السلسلة الذرية" (AXC). مع معاملة AXC، هناك مستخدمان قيد التشغيل يمكن لسلسلتين مختلفتين إجراء معاملتي تحويل ملتزمة معًا في كلا الدفترين، أو لا شيء على الإطلاق (أي: ذرياً). على سبيل المثال، يمكن لاثنين من المستخدمين تداول عملات البيتكوين مقابل الأثير (أو أي اثنين من tokens في دفتري أستاذ مختلفين) باستخدام معاملات AXC، على الرغم من أن Bitcoin وEthereum غير متصلين ببعضهما أخرى. إن فائدة تشغيل البورصة على معاملات AXC هي أنه لا يحتاج المستخدمون إلى الثقة ببعضهم البعض أو في مطابقة التجارة الخدمة. الجانب السلبي هو أن كلا الطرفين يجب أن يكونا متصلين بالإنترنت التجارة أن تحدث. نوع آخر من التبادل اللامركزي هو التبادل الجماعي التبادل الموزع الذي يعمل من تلقاء نفسه blockchain. المستخدمين على يمكن لهذا النوع من التبادل إرسال أمر محدد وتحويله إيقاف تشغيل الكمبيوتر، ويمكن تنفيذ التجارة دون أن يكون المستخدم موجودًا على الانترنت. يطابق blockchain ويكمل التداول نيابةً عنه من التاجر.
アプリケーション
集中型取引所は、指値の深いオーダーブックを作成できる 注文を増やし、それによってより多くのトレーダーを引き寄せます。流動性がさらに高まる 取引所の世界には流動性があり、強力なネットワークが存在します。 交換における効果（または少なくとも勝者総取り効果） ビジネス。現在の仮想通貨取引所のリーダー Poloniex は 24 時間の出来高が 2,000 万ドルで、2 位は Bitynex の 24 時間取引高は 500 万ドルです。これほど強力なネットワークがあると、 その影響で、AXC ベースの分散型取引所が影響を受ける可能性は低いです。 集中型取引所よりもボリュームを獲得します。分散型の場合 集中型取引所と競合するには、取引所が必要になります。 指値注文によるディープオーダーブックをサポートします。配布のみ blockchain の Exchange がそれを提供します。 Tendermint はトランザクションの高速化による追加のメリットを提供します コミットします。犠牲にすることなく高速性を優先することで 一貫性を保つため、Cosmos のゾーンはトランザクションを高速に処理できます。 為替注文トランザクションと IBC token への送金の両方 そして他のゾーンからも。 今日の暗号通貨取引所の状況を考えると、 Cosmos のアプリケーションは分散型交換 (別名、 Cosmos DEX)。トランザクションのスループット容量と コミットのレイテンシは集中型のレイテンシと同等になる可能性があります 交換。トレーダーは実行可能な指値注文を送信できます 双方がオンラインである必要はありません。そしてテンダーミントと一緒に、 Cosmos ハブと IBC では、トレーダーは資金を出入りできます。 他のゾーンとの間のやり取りをスピーディーに行います。 特権ゾーンは、ブリッジされた token のソースとして機能できます。 別の暗号通貨。橋は関係に似ています Cosmos ハブとゾーンの間。両方ともそれに追いつく必要があります token が持っている証拠を検証するために、他のブロックの最新ブロック 一方からもう一方へ移動しました。 Cosmos の「ブリッジゾーン」 ネットワークはハブおよび他のハブとの通信を維持します
暗号通貨。ブリッジゾーンを介した間接化により、 シンプルであり、他のものにとらわれないハブのロジック blockchain コンセンサス戦略 (Bitcoin の proof-of-work など) 採掘。 各ブリッジゾーン validator は、Tendermint を利用した blockchain と特別な ABCI ブリッジ アプリだけでなく、 「起源」blockchain。 新しいブロックがオリジン、ブリッジゾーンでマイニングされると、 validator は、署名することでコミットされたブロックについて合意します。 そして、オリジンのblockchainについてのそれぞれのローカルな見解を共有します ヒント。ブリッジゾーンがオリジンで支払いを受け取ったとき（そして この事件では十分な確認が見られたことが合意された Ethereum や Bitcoin などの PoW チェーンの)、対応する アカウントはその残高を使用してブリッジ ゾーンに作成されます。 Ethereum の場合、ブリッジ ゾーンは同じものを共有できます。 validator - Cosmos ハブとして設定されます。 Ethereum 側 ( オリジン）、ブリッジコントラクトにより、イーサ所有者はイーサを送信できるようになります 上のブリッジコントラクトに送信することでブリッジゾーンに送信します。 Ethereum。イーサがブリッジコントラクトによって受信されると、 適切な IBC パケットが送信されない限り、イーサを引き出すことはできません。 ブリッジゾーンからブリッジコントラクトによって受信されます。の Bridge-contract は、ブリッジ ゾーンの validator-set を追跡します。 Cosmos ハブの validator セットと同一である可能性があります。 Bitcoin の場合、概念は似ていますが、次の点が異なります。 単一のブリッジ コントラクトの場合、各 UTXO は マルチシグネチャ P2SH 公開スクリプトのしきい値。の制限により、 P2SH システムでは、署名者が Cosmos と同一であってはなりません ハブ validator セット。ブリッジゾーン上のイーサ (「ブリッジイーサ」) は、 ハブから送信され、その後、トランザクションによって破棄されます。 Ethereum の特定の出金アドレスに送信します。 IBC トランザクションがブリッジゾーンで発生したことを証明するパケット Ethereum ブリッジ コントラクトに投稿して、イーサを許可することができます 撤回されること。 Bitcoin の場合、制限されたスクリプト システムにより、 IBC コイン転送メカニズムを反映するのは困難です。それぞれ UTXO には独自の独立した pubscript があるため、すべての UTXO は のセットに変更があると、新しい UTXO に移行されます。 Bitcoin エスクロー署名者。解決策の 1 つは、圧縮して、 必要に応じて UTXO セットを解凍して合計数を維持します UTXO 件ダウンしました。 このようなブリッジ契約のリスクは、不正な validator セットです。 ≥1/3 ビザンチンの投票権によりフォークが発生し、イーサが撤退する可能性がある ブリッジゾーンにブリッジデザーを維持しながら、Ethereum のブリッジ契約から。さらに悪いことに、2/3 を超えるビザンチンの投票権は、 ブリッジコントラクトにイーサを送った人から完全にイーサを盗む ブリッジ ゾーンの元のブリッジング ロジックから逸脱することによって。 ブリッジを次のように設計することで、これらの問題に対処することが可能です。 完全に責任がある。たとえば、ハブからのすべての IBC パケットと、 発信元は、ブリッジ ゾーンによる確認を必要とする場合があります。 これにより、ブリッジ ゾーンのすべての状態遷移が可能になります。 ハブまたはオリジンのいずれかによって効率的に挑戦され、検証される ブリッジ契約。ハブとオリジンでは、ブリッジゾーン validator が担保をポストし、token がブリッジゾーンから転送できるようにする必要があります。 ブリッジ契約は遅らせる必要がある（そして担保解除） 十分に長い期間） 独立監査人。仕様のデザインはお任せしますので、 このシステムの実装は将来的にオープンです Cosmos
改善提案、Cosmos ハブによって可決される予定 ガバナンスシステム。 スケーリングの問題の解決は、Ethereum にとって未解決の問題です。 現在、Ethereum ノードはすべてのトランザクションを処理し、 すべての状態も保存します。リンク。 Tendermint は Ethereum よりもはるかに速くブロックをコミットできるため、 Tendermint コンセンサスを活用した proof-of-work、EVM ゾーンと ブリッジイーサ上で動作すると、より高いパフォーマンスを提供できます。 Ethereum blockchain 秒。さらに、Cosmos ハブと IBC パケットの仕組みでは、任意のコントラクト ロジックが許可されていません 実行自体は、token の動きを調整するために使用できます。 異なるゾーンで実行されているEthereumコントラクト間、 token 中心の Ethereum スケーリングの基盤を提供します。 シャーディング。 Cosmos ゾーンは、任意のアプリケーション ロジックを実行します。 ゾーンの寿命の始まりであり、更新される可能性があります 時間の経過とともにガバナンスによって。このような zexibility により、Cosmos ゾーンは次のことを行うことができます。 Ethereum や Bitcoin、およびそれらの blockchain の派生物も許可されます。 同じコードベースを利用しますが、異なる validator セットを使用し、 初期配布。これにより、多くの既存の暗号通貨が利用可能になります。 Ethereum、Zerocash、Bitcoin などのフレームワーク、 Tendermint Core で使用する CryptoNote など。 共通のネットワーク上の、より高性能なコンセンサス エンジン、 相互運用性の大きな機会を開く プラットフォーム。さらに、マルチアセット blockchain として、単一の トランザクションには複数の入力と出力が含まれる場合があります。 入力は任意の token タイプにすることができ、Cosmos を直接として機能させることができます。 注文が前提となりますが、分散型取引所のプラットフォーム他のプラットフォーム経由でマッチングされます。あるいは、ゾーンでサービスを提供することもできます。 分散型フォールトトレラント取引所 (オーダーブック付き) として、 既存の集中型を大幅に改善できる 時間の経過とともにハッキングされる傾向にある暗号通貨取引所。 ゾーンは、blockchain をサポートするエンタープライズ バージョンとしても機能します 政府システムでは、特定のサービスの一部が 伝統的に組織または組織のグループによって運営されている 代わりに、特定のゾーンで ABCI アプリケーションとして実行されます。 パブリックのセキュリティと相互運用性を継承できるようにします。 Cosmos 基盤となるネットワークの制御を犠牲にすることなくネットワークを構築 サービス。したがって、Cosmos は、両方の長所を提供する可能性があります。 blockchain テクノロジーの利用を検討しているが、どのような組織が利用を検討しているのか 分散したサードパーティに制御を完全に手放すことには慎重である パーティー。 一貫性を重視することに大きな問題があると主張する人もいます Tendermint のようなコンセンサス アルゴリズムは、どのネットワークでも
2/3 の単一パーティションが存在しないパーティション 投票力（例：1/3以上の議決権）があれば、コンセンサスは完全に停止します。 Cosmos アーキテクチャは、次のようにしてこの問題を軽減できます。 地域自治区を備えたグローバルハブであり、そこに投票権がある 各ゾーンは共通の地理に基づいて分散されます 地域。たとえば、共通のパラダイムは個人向けのものかもしれません。 都市や地域は、ゾーンを共有しながら独自のゾーンを運営することができます。 共通ハブ (例: Cosmos ハブ)、地方自治体の活動を可能にします。 一時的なネットワークが原因でハブが停止した場合でも持続します。 パーティション。これにより、実際の地質学的、政治的、および 堅牢な設計で考慮すべきネットワーク トポロジーの特徴 フェデレーテッド・フォールト・トレラント・システム。
NameCoin は、問題の解決を試みた最初の blockchain の 1 つです。 Bitcoin blockchain を適応させることによる名前解決の問題。 残念ながら、このアプローチにはいくつかの問題がありました。 Namecoin を使用すると、たとえば @さとし が 過去のある時点で特定の公開鍵を使用して登録されている、 しかし、公開鍵がその後に作成されたかどうかはわかりません。 前回以降のすべてのブロックをダウンロードしない限り、最近更新されました その名前の更新。これは、Bitcoin の制限によるものです。 UTXO トランザクション マークル化モデル。 トランザクション (ただし変更可能なアプリケーション状態ではない) はマークル化されています ブロック-hashに。これにより、名前の存在は証明できますが、その後の名前の更新が存在しないことは証明できません。したがって、私たちはそれを知ることができません 完全な名前を信頼せずに、名前の最新の値を確認する ノードを削除したり、ダウンロードによって帯域幅に多大なコストが発生したりする blockchain 全体。 たとえマークル化された検索木がNameCoinに実装されたとしても、 proof-of-work への依存性により、クライアント検証が軽量になります 問題のある。ライトクライアントは、完全なコピーをダウンロードする必要があります。 blockchain 全体 (または少なくともすべてのブロック) のすべてのブロックのヘッダー 名前の最後の更新以降のヘッダー）。これは、 帯域幅要件は時間に応じて直線的に増加します [21]。さらに、proof-of-work blockchain の名前変更 追加の proof-of-work 確認ブロックを待つ必要があります。 Bitcoin では最大 1 時間かかる場合があります。 Tendermint を使用する場合、必要なのは最新のブロックだけです-hash validators の定足数 (投票権による) およびマークルによって署名されています。 名前に関連付けられた現在の値を証明します。これでできます 簡潔、迅速、安全なライトクライアントが可能 名前の値の検証。 Cosmos では、この概念をさらに拡張できます。それぞれ Cosmos の名前登録ゾーンには、「.com」や「.org」などのトップレベル ドメイン (TLD) 名を関連付けることができます。
登録ゾーンは独自のガバナンスと登録を持つことができます ルール。
التطبيقات
يمكن للبورصة المركزية إنشاء سجل أوامر عميق للحدود الأوامر وبالتالي جذب المزيد من المتداولين. السيولة تولد المزيد السيولة في عالم الصرف، وبالتالي هناك شبكة قوية التأثير (أو على الأقل الفائز يأخذ أكبر قدر من التأثير) في التبادل عمل. الزعيم الحالي لتبادل العملات المشفرة اليوم هو Poloniex بحجم تداول على مدار 24 ساعة بقيمة 20 مليون دولار، وفي المركز الثاني Bitynex بحجم تداول على مدار 24 ساعة بقيمة 5 ملايين دولار. ونظرا لهذه الشبكة القوية من غير المرجح أن تقوم البورصات اللامركزية القائمة على AXC بذلك الفوز بالحجم عبر البورصات المركزية. من أجل اللامركزية تبادل للتنافس مع تبادل مركزي، فإنه سوف تحتاج لدعم دفاتر الطلبات العميقة مع أوامر الحد. فقط موزعة التبادل على blockchain يمكن أن يوفر ذلك. يوفر Tendermint فوائد إضافية للمعاملات الأسرع يرتكب. من خلال إعطاء الأولوية للسرعة دون التضحية الاتساق، يمكن للمناطق الموجودة في Cosmos إجراء المعاملات بسرعة - من أجل كلاً من معاملات أوامر الصرف وكذلك IBC token التحويلات إلى ومن مناطق أخرى. بالنظر إلى حالة بورصات العملات المشفرة اليوم، يعد هذا أمرًا رائعًا تطبيق Cosmos هو التبادل الموزع (المعروف أيضًا باسم Cosmos ديكس). القدرة الإنتاجية للمعاملة كذلك يمكن أن يكون وقت استجابة الالتزام مشابهًا لتلك المركزية التبادلات. يمكن للمتداولين تقديم أوامر محددة يمكن تنفيذها دون أن يكون كلا الطرفين متصلين بالإنترنت. ومع تندرمينت، مركز Cosmos وIBC، يمكن للمتداولين نقل الأموال داخل وخارج التبادل من وإلى المناطق الأخرى بسرعة. يمكن أن تعمل المنطقة المميزة كمصدر لـ token من عملة مشفرة أخرى. الجسر يشبه العلاقة بين المركز والمنطقة Cosmos؛ كلاهما يجب أن يواكبا أحدث الكتل للآخر من أجل التحقق من الأدلة التي يمتلكها tokens انتقلت من واحدة إلى أخرى. "منطقة الجسر" على Cosmos تواكب الشبكة المحور بالإضافة إلى الآخر
عملة مشفرة. يسمح الاتجاه غير المباشر عبر منطقة الجسر منطق المحور ليظل بسيطًا ومحايدًا للآخرين blockchain إستراتيجيات الإجماع مثل Bitcoin proof-of-work التعدين. سيتم تشغيل كل منطقة جسر validator بواسطة Tendermint blockchain مع تطبيق جسر خاص ABCI، ولكن أيضًا عقدة كاملة لـ "الأصل" blockchain. عندما يتم استخراج كتل جديدة في الأصل، منطقة الجسر سوف يتوصل validators إلى اتفاق بشأن الكتل الملتزم بها من خلال التوقيع ومشاركة وجهة نظرهم المحلية الخاصة بالأصل blockchain نصيحة. عندما تتلقى منطقة الجسر الدفع على الأصل (و وقد تم الاتفاق على ما يكفي من التأكيدات في هذه القضية لسلسلة PoW مثل Ethereum أو Bitcoin)، المقابلة يتم إنشاء الحساب في منطقة الجسر بهذا الرصيد. في حالة Ethereum، يمكن لمنطقة الجسر مشاركة نفس الشيء validator-تم تعيينه كمركز Cosmos. على الجانب Ethereum ( Origin)، سيسمح عقد الجسر لحاملي الأثير بإرسال الأثير إلى منطقة الجسر عن طريق إرسالها إلى عقد الجسر Ethereum. بمجرد استلام الأثير من خلال عقد الجسر، فإن لا يمكن سحب الأثير إلا إذا كانت هناك حزمة IBC مناسبة تم استلامها بموجب عقد الجسر من منطقة الجسر. ال يتتبع عقد الجسر مجموعة validator لمنطقة الجسر، والتي قد تكون مطابقة لمجموعة Cosmos Hub validator. في حالة Bitcoin، المفهوم مشابه باستثناء أنه بدلاً من ذلك عقد جسر واحد، سيتم التحكم في كل UTXO بواسطة أ عتبة متعددة التوقيعات P2SH. بسبب القيود في نظام P2SH، لا يمكن أن يكون الموقعون متطابقين مع Cosmos المحور validator-مجموعة.يمكن نقل الأثير الموجود في منطقة الجسر ("الأثير الجسري") إلى ومن المحور، ويتم تدميرها لاحقًا بمعاملة ذلك يرسلها إلى عنوان سحب معين على Ethereum. IBC حزمة تثبت أن المعاملة حدثت في منطقة الجسر يمكن نشرها على عقد الجسر Ethereum للسماح بالأثير ليتم سحبها. في حالة Bitcoin، يقوم نظام البرمجة النصية المقيدة بذلك من الصعب عكس آلية نقل العملة IBC. كل UTXO لديه منشور مستقل خاص به، لذلك يجب أن يكون كل UTXO تم الترحيل إلى UTXO الجديد عندما يكون هناك تغيير في مجموعة Bitcoin موقعي الضمان. أحد الحلول هو الضغط و قم بفك ضغط مجموعة UTXO حسب الضرورة للحفاظ على العدد الإجمالي من UTXOs لأسفل. إن خطر مثل هذا العقد التجسيري هو مجموعة validator المارقة. ≥⅓ يمكن أن تتسبب قوة التصويت البيزنطية في حدوث شوكة وسحب الأثير من عقد الجسر على Ethereum مع الحفاظ على جسر الجسر في منطقة الجسر. والأسوأ من ذلك أن قوة التصويت البيزنطية يمكنها ذلك سرقة الأثير مباشرة من أولئك الذين أرسلوه إلى عقد الجسر بالانحراف عن منطق التجسير الأصلي لمنطقة الجسر. من الممكن معالجة هذه المشكلات من خلال تصميم الجسر مسؤولة تماما. على سبيل المثال، كافة الحزم IBC من المركز و الأصل، قد يتطلب الاعتراف من قبل منطقة الجسر في بهذه الطريقة يمكن أن تكون جميع التحولات الحكومية في منطقة الجسر يتم تحديها والتحقق منها بكفاءة سواء من خلال المركز أو الأصل عقد الجسر. يجب أن يسمح المركز والأصل لمنطقة الجسر validators بنشر الضمانات، وtoken عمليات النقل خارج يجب تأخير عقد الجسر (وفك الضمانات فترة طويلة بما فيه الكفاية) للسماح بأية تحديات مدققين مستقلين. نترك تصميم المواصفات و تنفيذ هذا النظام مفتوح كمستقبل Cosmos
مقترح التحسين، ليتم تمريره من خلال مركز Cosmos نظام الحكم. يعد حل مشكلة القياس مشكلة مفتوحة لـ Ethereum. حاليًا، تقوم عقد Ethereum بمعالجة كل معاملة و أيضا تخزين جميع الدول. وصلة. نظرًا لأن Tendermint يمكنها تنفيذ الكتل بشكل أسرع بكثير من Ethereum proof-of-work، EVM المناطق المدعومة بإجماع Tendermint و يمكن أن يوفر التشغيل على الأثير الجسري أداءً أعلى Ethereum blockchains. بالإضافة إلى ذلك، على الرغم من أن Cosmos Hub و IBC لا تسمح آليات الحزم بمنطق العقد التعسفي التنفيذ في حد ذاته، يمكن استخدامه لتنسيق حركات token بين Ethereum العقود الجاري تنفيذها في مناطق مختلفة، توفير أساس للتوسع token المتمركز حول Ethereum عبر مشاركة. تعمل مناطق Cosmos على تشغيل منطق التطبيق التعسفي، والذي تم تحديده عند بداية حياة المنطقة ويمكن تحديثها مع مرور الوقت من قبل الحكم. تسمح هذه القابلية للمناطق بـ Cosmos بمثابة جسور إلى العملات المشفرة الأخرى مثل Ethereum أو Bitcoin، كما أنه يسمح بمشتقات تلك blockchains، باستخدام نفس قاعدة التعليمات البرمجية ولكن مع مجموعة validator مختلفة و التوزيع الأولي. وهذا يسمح للعديد من العملات المشفرة الموجودة أطر العمل، مثل تلك الخاصة بـ Ethereum، وZerocash، وBitcoin، CryptoNote وما إلى ذلك، لاستخدامها مع Tendermint Core، وهو محرك توافقي عالي الأداء، على شبكة مشتركة، فتح فرصة هائلة للتشغيل البيني عبر المنصات. علاوة على ذلك، باعتباره أصلًا متعددًا blockchain، واحدًا قد تحتوي المعاملة على مدخلات ومخرجات متعددة، حيث يكون كل منها يمكن أن يكون الإدخال من أي نوع token، مما يتيح لـ Cosmos العمل مباشرةً كـ منصة للتبادل اللامركزي، على الرغم من افتراض الأوامرلتتم مطابقتها عبر منصات أخرى. بدلا من ذلك، يمكن للمنطقة أن تخدم كتبادل موزع متسامح مع الأخطاء (مع دفاتر الطلبات)، والذي يمكن أن يكون هناك تحسن صارم على المركزية الموجودة بورصات العملات المشفرة التي تميل إلى الاختراق مع مرور الوقت. يمكن أن تعمل المناطق أيضًا كإصدارات مدعومة من المؤسسة blockchain والأنظمة الحكومية، حيث أجزاء من خدمة معينة تدار تقليديا من قبل منظمة أو مجموعة من المنظمات يتم تشغيلها بدلاً من ذلك كتطبيق ABCI في منطقة معينة، والتي يسمح لها بوراثة الأمن وقابلية التشغيل البيني للجمهور Cosmos الشبكة دون التضحية بالتحكم في الشبكة الأساسية الخدمة. وبالتالي، قد يقدم Cosmos أفضل ما في العالمين المنظمات التي تتطلع إلى الاستفادة من تقنية blockchain ولكن من هي؟ الحذر من التخلي عن السيطرة بالكامل للثلث الموزع حزب. يدعي البعض أن هناك مشكلة كبيرة في تفضيل الاتساق خوارزميات الإجماع مثل Tendermint هي أن أي شبكة القسم الذي يتسبب في عدم وجود قسم واحد به >⅔ قوة التصويت (على سبيل المثال ≥⅓ الذهاب للخارج) ستوقف الإجماع تمامًا. يمكن أن تساعد بنية Cosmos في تخفيف هذه المشكلة باستخدام مركز عالمي مع مناطق الحكم الذاتي الإقليمية، حيث قوة التصويت لكل منطقة يتم توزيعها على أساس جغرافي مشترك المنطقة. على سبيل المثال، قد يكون النموذج المشترك للفرد المدن أو المناطق لتشغيل مناطقها الخاصة أثناء مشاركة أ المركز المشترك (على سبيل المثال، المركز Cosmos)، مما يتيح للنشاط البلدي تستمر في حالة توقف المحور بسبب شبكة مؤقتة التقسيم. لاحظ أن هذا يسمح بالجيولوجية والسياسية الحقيقية الميزات الطوبولوجية للشبكة التي يجب مراعاتها عند التصميم القوي الأنظمة الموحدة المتسامحة مع الأخطاء.
كانت NameCoin واحدة من أوائل blockchains التي حاولت حل مشكلة مشكلة تحليل الاسم عن طريق تكييف Bitcoin blockchain. لسوء الحظ كانت هناك العديد من المشاكل مع هذا النهج. باستخدام Namecoin، يمكننا التحقق من أن @satoshi، على سبيل المثال، كان كذلك مسجلة بمفتاح عام معين في وقت ما في الماضي، لكننا لا نعرف ما إذا كان المفتاح العام موجودًا منذ ذلك الحين تم تحديثه مؤخرًا ما لم نقم بتنزيل جميع الكتل منذ آخر مرة تحديث لهذا الاسم. ويرجع ذلك إلى القيود المفروضة على Bitcoin UTXO نموذج تحويل المعاملة Merkle، حيث فقط المعاملات (ولكن ليست حالة التطبيق القابلة للتغيير) هي من نوع Merkle في الكتلة-hash. وهذا يتيح لنا إثبات الوجود، ولكن ليس عدم وجود تحديثات لاحقة للاسم. وبالتالي، لا يمكننا أن نعرف تأكد من أحدث قيمة للاسم دون الثقة الكاملة العقدة، أو تكبد تكاليف كبيرة في النطاق الترددي عن طريق التنزيل كله blockchain. حتى لو تم تنفيذ شجرة بحث بحجم Merkle في NameCoin، اعتماده على proof-of-work يجعل عملية التحقق من العميل سهلة إشكالية. يجب على عملاء Light تنزيل نسخة كاملة من رؤوس جميع الكتل في blockchain بالكامل (أو على الأقل كل الرؤوس منذ آخر تحديث للاسم). وهذا يعني أن تتغير متطلبات عرض النطاق الترددي بشكل خطي مع مقدار الوقت [21]. بالإضافة إلى ذلك، يتغير الاسم على proof-of-work blockchain يتطلب انتظار كتل تأكيد إضافية proof-of-work، والذي يمكن أن يستغرق ما يصل إلى ساعة على Bitcoin. مع Tendermint، كل ما نحتاجه هو أحدث كتلة-hash موقعة من قبل نصاب قانوني قدره validators (بواسطة قوة التصويت)، وميركل دليل على القيمة الحالية المرتبطة بالاسم. هذا يجعلها من الممكن أن يكون لديك عميل خفيف مقتضب وسريع وآمن التحقق من قيم الاسم. في Cosmos، يمكننا أن نأخذ هذا المفهوم ونوسعه إلى أبعد من ذلك. كل يمكن أن تحتوي منطقة تسجيل الاسم في Cosmos على اسم نطاق المستوى الأعلى (TLD) مرتبط مثل ".com" أو ".org"، وكل اسم-
منطقة التسجيل يمكن أن يكون لها الإدارة والتسجيل الخاصة بها القواعد.
ガバナンスと経済
Cosmos ハブは複数資産の分散台帳ですが、 アトムと呼ばれる特別なネイティブ token。原子は唯一の staking Cosmos ハブの token。アトムは所有者にとってのライセンスです。 投票、検証、または他の validator への委任。 Ethereum のように イーサ、アトムは取引手数料の支払いにも使用できます。 スパムを軽減します。追加のインザショナルアトムとブロックトランザクション 料金はvalidator と委任者に報酬として支払われます。 validator秒。 BurnAtomTx トランザクションを使用すると、あらゆるデータを復元できます。 リザーブ プールから比例量の token を取得します。 Genesis 上のアトム tokens および validators の初期配布 Cosmos 募金活動の寄付者 (75%)、主要寄付者に寄付されます (5%)、Cosmos Network Foundation (10%)、ALL IN BITS, Inc (10%)。創世記以降、原子の総量の 1/3 が 絆を結んだvalidatorと委任者に毎年報酬が与えられます。 詳細については、Cosmos 計画を参照してください。 Bitcoin や他の proof-of-work blockchain とは異なり、Tendermint blockchain は、validator が増えると遅くなります。 コミュニケーションの複雑さ。幸いなことに、私たちは十分なサポートができます validators により、堅牢なグローバル分散型 blockchain トランザクション確認時間が非常に速く、帯域幅として、
ストレージと並列計算能力が増加すると、 将来的にはさらに多くの validator をサポートする予定です。 創世記の日に、validator の最大数は次のように設定されます。 100 とすると、この数字は 10 年間で 13% の割合で増加します。 300 validator秒で解決します。 まだアトム所有者になっていない人は、次の方法で validator になれます。 BondTx トランザクションに署名して送信します。の量 担保として提供される原子はゼロ以外でなければなりません。誰でもなれる 現在のサイズが変更された場合を除き、いつでも validator validator セットは validator の最大数を超えています 許可されています。その場合、取引は以下の金額を満たした場合にのみ有効です。 原子が保持する有効原子の量よりも多い 最小の validator。有効なアトムには委任されたアトムが含まれます。 このような方法で新しい validator が既存の validator を置き換えると、 既存の validator は非アクティブになり、すべての原子と 委任された原子は非結合状態になります。 validator には、何らかのペナルティが課せられる必要があります。 認可された基準からの意図的または非意図的な逸脱 プロトコル。いくつかの証拠はすぐに認められます。 同じ高さで丸められた二重記号、または違反 0 年: 100 1 年目: 113 2 年目: 127 3 年目: 144 4 年目: 163 5 年目: 184 6 年目: 208 7年目: 235 8年目: 265 9 年目: 300 10年目: 300 ...
「prevote-the-lock」（Tendermint コンセンサス プロトコルのルール）。 このような証拠により、validator は良好な地位を失うことになります およびその結合原子とそれに比例する token の割合 リザーブプール（総称して「ステーク」と呼ばれます）は削減されます。 地域によっては、validator が利用できない場合があります。 ネットワークの中断、停電、またはその他の理由。もし、いずれにしても 過去の ValidatorTimeoutWindow ブロック、validator のポイント コミット投票は blockchain に含まれていません ValidatorTimeoutMaxAbsent 回、validator になります 非アクティブになり、ValidatorTimeoutPenalty (デフォルト 1%) が失われます。 賭け金。 一部の「悪意のある」動作は、明らかに識別できるものを生成しない blockchain に関する証拠。このような場合、validator は次のことができます。 帯域外を調整して、これらの悪意のあるメッセージを強制的にタイムアウトさせます。 validators、超過半数の合意がある場合。 Cosmos ハブが 1/3 以上の連合により停止した場合 議決権が失われるか、連立政権が 1/3 以上になる状況 投票力が悪意のある行動の証拠を検閲する blockchain に入ると、ハブはハードフォークで回復する必要があります 再編成提案。 (「フォークと検閲攻撃」へのリンク)。 Cosmos ハブ validator は、任意の token タイプまたは組み合わせを受け入れることができます 取引を処理するための手数料としての種類。それぞれのvalidatorは、 希望する為替レートを主観的に設定し、選択する BlockGasLimit が設定されている限り、どのようなトランザクションでも可能です。 超えていない。徴収された料金から以下に指定される税金を差し引いたもの、 に比例して保税利害関係者に再分配されます。 それらの結合原子、すべての ValidatorPayoutPeriod (デフォルト 1) 時間）。徴収された取引手数料のうち、ReserveTax（デフォルト 2%）は、 リザーブプールに向かってリザーブプールを増やし、 Cosmos ネットワークのセキュリティと価値を高めます。これら 決定に従って資金を分配することもできる ガバナンスシステムによって作られます。 投票権を他の validator に委任する Atom 保有者 委任されたvalidatorに手数料を支払います。委員会ができることは、 各 validator によって設定されます。 Cosmos ハブのセキュリティは、ハブのセキュリティの関数です。 基礎となる validator と委任者による委任の選択。 発見物の発見と早期通報を促すため Cosmos ハブはハッカーに脆弱性を公開することを奨励しています ReportHackTx トランザクションによるエクスプロイトの成功。 validator がハッキングされました。このアドレスに報奨金を送ってください。」次第 このようなエクスプロイトでは、validator と委任者が非アクティブになります。 全員の原子の HackPunishmentRatio (デフォルト 5%) が取得されます。 スラッシュ、および全員のアトムの HackRewardRatio （デフォルトは 5%） ハッカーの報奨金アドレスに報酬が与えられます。 validator バックアップ キーを使用して残りの原子を回復する必要があります。 この機能を悪用して転送することを防ぐため 権利確定されていないアトム、権利確定済みアトムと権利確定されていないアトムの部分 ReportHackTx の前後の validator と委任者は、 変更はなく、ハッカーの報奨金にはいくらかが含まれます 権利が付与されていない原子 (存在する場合)。 Cosmos ハブは、分散組織によって運営されています。 そのためには綿密なガバナンスメカニズムが必要です 変数など、blockchain に対するさまざまな変更を調整します。
システムのパラメータ、ソフトウェアのアップグレード、 憲法改正。 すべての validator は、すべての提案に投票する責任があります。失敗 提案に適時に投票すると、validator となります。 と呼ばれる一定期間、自動的に非アクティブ化されます。 欠勤ペナルティ期間（デフォルトは 1 週間）。 委任者は、委任された人の投票を自動的に継承します。 validator。この投票は手動で上書きできます。結合していない原子 票が得られない。 各提案には MinimumProposalDeposit のデポジットが必要です token、1 つ以上の token の組み合わせである場合があります 原子も含めて。各提案について、有権者は賛成票を投じることができます。 預金。有権者の半数以上が採用を選択した場合、 デポジット (例: 提案がスパムであったため)、デポジットは次の宛先に送られます。 燃焼する原子を除いたリザーブプール。 各提案について、有権者は次のオプションを選択して投票できます。 そうだね そう、フォースとともに いや ノーウィズフォース 棄権する 賛成票または YeaWithForce 票の厳密過半数 (または反対票、または 提案が次のように決定されるには、NayWithForce 票）が必要です。 可決された（または不合格と決定された）が、1/3 以上が過半数を拒否できる 「強制力」による投票による決定。厳密多数派が拒否権を発動すると、 拒否権ペナルティフィーブロックを失うと全員が罰せられます (デフォルトの 1 日分のブロック) 相当の料金 (税金を除く) 影響を受けません）、および過半数を拒否権を発動した政党
この決定は、VetoPenaltyAtoms を失うことでさらに罰せられます。 (デフォルトでは 0.1%) の原子。 ここで定義されているパラメータはどれも、 ParameterChangeProposal を渡す。 アトムを注入し、プール資金を使用してリザーブすることができます。 BountyProposal の可決。 プロトコルをアップグレードする提案など、他のすべての提案は、 一般的な TextProposal を介して調整されます。 計画を参照してください。 blockchain コンセンサスには多くの革新があり、 過去数年間の拡張性。このセクションでは概要を説明します 選ばれた数の重要なものについての調査。 悪意のある参加者がいる場合の合意形成が問題となる レスリー・ランポートが造語した1980年代初頭に遡ります。 「ビザンチン障害」というフレーズは、任意のプロセスの動作を指します。 「クラッシュ障害」とは対照的に、意図した動作から逸脱します。 この場合、プロセスは単にクラッシュします。早期の解決策が発見されました 上限がある同期ネットワークの場合メッセージ遅延、ただし実際の使用は非常に限られていました 飛行機の管制官などの制御された環境 データセンターは原子時計によって同期されます。まではそうではありませんでした 90 年代後半、実用的なビザンチン フォールト トレランス (PBFT) [11] は 効率的な部分同期コンセンサスとして導入 最大 1/3 のプロセスの動作を許容できるアルゴリズム 勝手に。 PBFT は標準アルゴリズムとなり、多くのアルゴリズムが生成されました バリエーションの一部として IBM によって作成された最新のものを含む 彼らの Hyperledger への貢献。 PBFT に対する Tendermint のコンセンサスの主な利点は、 Tendermint の基本構造は改良され、簡素化されています。 その一部は、blockchain パラダイムを採用した結果です。 Tendermint ブロックは順番にコミットする必要があるため、 PBFT に関連する複雑さと通信オーバーヘッド 視点の変化。 Cosmos および多くの暗号通貨では、 ブロック N の場合、ブロック N+i (i >= 1) のコミットを許可する必要がある それ自体はまだコミットしていません。帯域幅が N をブロックする理由の場合 Cosmos ゾーンでコミットしていない場合は、使用しても役に立ちません ブロック N+i に対する帯域幅共有投票。ネットワークパーティションまたは ofzine ノードがブロック N がコミットされていない理由である場合、 N+i はとにかくコミットしません。 さらに、トランザクションをブロックにバッチ処理することで、 アプリケーション状態の定期的な Merkle-hashing PBFT のチェックポイント設定スキームと同様に、定期的なダイジェスト。これにより、 ライトクライアント向けの証明可能なトランザクションコミットを高速化するため、 blockchain 間通信。 Tendermint Core には多くの最適化と機能も含まれています PBFT で指定されている内容を超えたもの。たとえば、 validators によって提案されたブロックは部分に分割され、マークル化され、 放送を改善するような方法で噂話をした パフォーマンス (インスピレーションについては、LibSwift [19] を参照してください)。あとテンダーミントも Core はポイントツーポイントについて何も想定していません
接続性、および P2P ネットワークが存在する限り機能します。 弱く接続されています。 proof-of-stake (PoS) を導入したのは初めてではありませんが、BitShares1.0 [12] PoSの研究と導入に大きく貢献 blockchain、特に「委任された」PoS として知られるもの。で BitShares、利害関係者は注文の責任を負う「証人」を選出 トランザクションのコミット、および責任を負う「代理人」 ソフトウェアのアップデートやパラメータの変更を調整します。 BitShares2.0 は、高性能 (100k tx/s、1s) の達成を目指しています。 レイテンシ)、理想的な状態では、各ブロックは単一の署名によって署名されます。 署名者、およびトランザクションの性質に比べてかなり長い時間がかかります ブロック間隔。正規の仕様はまだ開発中です。 利害関係者は、不正行為を行った証人を削除または置き換えることができます。 日常的に行われているが、証人や重要な証拠は存在しない。 Tendermint PoS に似たデリゲータが切り込まれる 二重支出攻撃が成功した場合。 リップルが開拓したアプローチに基づいて、Stellar [13] は プロセスが行われる連邦ビザンチン協定のモデル コンセンサスへの参加は、yxed を構成せず、グローバルに行われます。 既知のセット。むしろ、各プロセス ノードは 1 つ以上のプロセスをキュレートします。 「クォーラム スライス」。それぞれが信頼できるプロセスのセットを構成します。あ Stellar の「クォーラム」は、以下を含むノードのセットであると定義されています。 セット内のノードごとに少なくとも 1 つのクォーラム スライス。 合意に達することができる。 Stellar メカニズムのセキュリティは次の仮定に依存しています。 任意の 2 つの定足数の共通部分が空ではないこと、 ノードの可用性には、少なくとも 1 つのクォーラム スライスが必要です。 完全に正しいノードで構成されているため、 バランスを取るのが難しい大小のクォーラム スライスを使用する 信頼について重大な仮定を課すことなく。最終的には、ノードは何らかの方法で適切なクォーラム スライスを選択する必要があります。 十分なフォールト トレランス (またはすべての「無傷のノード」) であること 論文の結果の多くはそれに依存します)、そして唯一の このような構成が階層的であることを保証するために提供された戦略 ボーダー ゲートウェイ プロトコル (BGP) に似ています。インターネット上の一流 ISP がグローバル ルーティング テーブルを確立するために使用します。 TLS 証明書を管理するためにブラウザによって使用されるもの。どちらも悪名高い 彼らの不安のために。 Tendermint ベースのプルーフオブステーク システムに対する Stellar 論文の批判は、説明されている token 戦略によって軽減されます。 ここでは、アトムと呼ばれる新しいタイプの token が発行されます。 料金および報酬の将来の部分に対する請求を表します。の したがって、Tendermint ベースの proof-of-stake の利点は相対的なものになります。 シンプルでありながら、十分かつ証明可能なセキュリティを提供します 保証します。 BitcoinNG は、Bitcoin に対する改善提案です。 ブロックサイズの増加などの垂直方向のスケーラビリティの形式の場合、 通常伴う経済的悪影響を伴うことなく、 このような変化により、不釣り合いに大きな影響が生じる場合 小規模な鉱山労働者について。この改善は、分離することで達成されます。 トランザクション ブロードキャストからのリーダー選挙: リーダーは初めてです 「マイクロブロック」内のproof-of-workによって選出され、次のことが可能になります 新しいマイクロブロックまでコミットされるブロードキャスト トランザクション が見つかりました。これにより、必要な帯域幅要件が軽減されます。 PoW レースに勝利し、小規模マイナーがより公平に競争できるようになり、 そして、トランザクションをより定期的にコミットできるようになります。 マイクロブロックを見つけた最後のマイナー。 Casper [16] は、提案されている proof-of-stake コンセンサス アルゴリズムです。 Ethereum。その主要な動作モードは「コンセンサス・バイ・ベット」です。によって validator に、どのブロックがそうなると信じているかを繰り返し賭けさせます。
他の賭けに基づいて blockchain にコミットするようになる 彼らがこれまでに見てきたことを踏まえれば、最終的にはイナリティが達成されるでしょう。リンク。 これは、Casper チームによる活発な研究分野です。の 課題は、 進化的に安定した戦略であることが証明されています。主なメリットは Tendermint と比較した Casper は、「可用性」を提供している可能性があります。 「一貫性を超えています」 – コンセンサスには 2/3 を超える定足数は必要ありません 投票力 – おそらくコミット速度や 実装の複雑さ。 Interledger Protocol [14] は、厳密にはスケーラビリティ ソリューションではありません。それ 異なる台帳間のアドホックな相互運用を提供します 疎結合された二国間関係ネットワークを介したシステム。 ライトニング ネットワークと同様に、ILP の目的は、 支払いですが、特に異種間での支払いに焦点を当てています 台帳タイプを定義し、アトミック トランザクション メカニズムを次のように拡張します。 hash ロックだけでなく、公証人の定足数 (と呼ばれる) も含まれます。 原子輸送プロトコル)。後者のメカニズムは、 台帳間トランザクションにアトミック性を強制することは、 Tendermint のライトクライアント SPV メカニズムの図 ILP と Cosmos/IBC の区別は保証されています。 以下に提供されます。 1. ILP のコネクターの公証人はメンバーシップをサポートしていません 変化し、その間のゼクシブルな重み付けは許可されません。 公証人。一方、IBC は、特に次の目的のために設計されています。 blockchains、validators は異なる重みを持つことができます。 途中でメンバーが変更される可能性がある場合 blockchain。 2. ライトニングネットワークと同様に、ILP での支払いの受取人 送信者に確認を返信するにはオンラインである必要があります。でtoken は、受信機の validator セットである IBC 経由で転送します。 blockchain は確認を提供する責任を負います。 受信側ユーザー。 3. 最も顕著な違いは、ILP のコネクタが 支払いに関して責任を負う、または権威ある状態を維持する、 一方、Cosmos では、ハブの validator が権限を持ちます。 IBC token の州と権限が移転します。 各ゾーンが保持する token の量 (ただし、 token はゾーン内の各アカウントによって保持されます)。これは、 安全な非対称を可能にする根本的な革新 ゾーンからゾーンへの token の転送。 ILP に類似したもの Cosmos のコネクタは永続的で最大限に安全です blockchain 台帳、Cosmos ハブ。 4. ILP での台帳間支払いは、 非対称転送がないため、オーダーブックを交換します。 ある台帳から別の台帳へのコイン、価値の移動のみ、または 市場同等品。 サイドチェーン [15] は、Bitcoin をスケーリングするために提案されたメカニズムです。 「双方向にペグ」された代替 blockchain を介したネットワーク Bitcoin blockchain。 (双方向ペギングは以下と同等です) 橋渡し。 Cosmos では、市場ペギングと区別するために「ブリッジ」と呼びます)。サイドチェーンにより、ビットコインが効率的に移動できるようになります。 Bitcoin blockchain をサイドチェーンとバックに接続し、 サイドチェーン上の新機能の実験。のように、 Cosmos ハブ、サイドチェーン、および Bitcoin は、 お互いに、SPV プルーフを使用してコインをいつ発行すべきかを決定します。 サイドチェーンに転送されて戻ってきます。もちろん、Bitcoin 以来 proof-of-work を使用すると、Bitcoin を中心とするサイドチェーンが影響を受けます proof-of-work の多くの問題とリスクから、 コンセンサスメカニズム。さらに、これはBitcoin-マキシマリストです さまざまな token をネイティブにサポートしていないソリューション
Cosmos のようなゾーン間ネットワーク トポロジ。とは言え、核心は ツーウェイペグの仕組みは原理的には同じです Cosmos ネットワークによって採用されています。 Ethereum は現在、さまざまな戦略を研究中です Ethereum blockchain の状態をシャーディングしてアドレス指定する スケーラビリティのニーズ。これらの取り組みには、 現在の Ethereum 仮想マシンによって提供される抽象化レイヤー 共有状態空間全体にわたって。複数の研究活動が行われており、 現時点では進行中です。 [18][22] Cosmos と Ethereum 2.0 Mauve [22] には、異なる設計目標があります。 Cosmos は、具体的には token 秒に関するものです。モーブはスケーリングに関するものです 一般的な計算。 Cosmos は EVM にバインドされていないため、異なる VM であってもバインドできます。 相互運用します。 Cosmos ゾーン作成者は、ゾーンを誰が検証するかを決定できます。 ゾーン。 誰でも Cosmos で新しいゾーンを開始できます (ガバナンスがない限り) それ以外の場合は判断します）。 ハブはゾーン障害を分離するため、グローバル token 不変条件は 保存されています。 ライトニング ネットワークは、提案されている token 転送ネットワークです Bitcoin blockchain (および他のパブリック blockchains)、桁違いの改善が可能になります トランザクションの大部分を移動することにより、トランザクション スループットが低下します コンセンサス台帳の外にある、いわゆる「支払いチャネル」にアクセスします。これは、オンチェーンの暗号通貨スクリプトによって可能になります。 当事者が二国間でステートフルな契約を締結できるようにします。 デジタル署名と契約を共有することで状態を更新できます 最終的に証拠をblockchainに公開することで解決できます。 このメカニズムはクロスチェーンアトミックスワップによって初めて普及しました。によって 多くの関係者や参加者との決済チャネルを開く ライトニング ネットワークは、ルーティングの中心となることができます。 他者の支払い、完全に接続された支払いチャネルにつながる 資本が支払いチャネルに拘束されるという代償を払って、ネットワークにアクセスできなくなります。 ライトニング ネットワークは、さまざまな場所に簡単に拡張することもできます。 値の転送を可能にする複数の独立した blockchain 為替市場を介して非対称的に使用することはできません。 token を blockchain から別の blockchain に転送します。主なメリット ここで説明する Cosmos ネットワークのは、そのような直接を有効にすることです。 token は転送します。とはいえ、私たちは支払いチャネルと ライトニングネットワークは当社の token 転送メカニズム。コスト削減とプライバシー上の理由から。 Segregated Witness は Bitcoin 改善提案リンクです。 ブロックごとのトランザクション スループットを 2 倍または 3 倍に向上させることを目的としています。 同時に新しいノードのブロック同期を高速化します。 このソリューションの優れた点は、それがどのように機能するかにあります。 Bitcoin の現在のプロトコルの制限とソフトフォークが可能 アップグレード (つまり、古いバージョンのソフトウェアを使用しているクライアントは、 アップグレード後も機能し続けます)。テンダーミント、新登場 プロトコルには設計上の制限がないため、スケーリングが異なります 優先順位。主に、Tendermint は BFT ラウンドロビン アルゴリズムを使用します。 マイニングではなく暗号署名に基づいています。 複数の並列処理による水平方向のスケーリングが簡単に可能になります blockchains、定期的でより頻繁なブロック コミットにより、 垂直方向のスケーリングも可能です。
الحكم والاقتصاد
في حين أن Cosmos Hub عبارة عن دفتر أستاذ موزع متعدد الأصول، إلا أنه يوجد أصل خاص token يسمى الذرة. الذرات هي staking الوحيدة token للمركز Cosmos. الذرات هي رخصة لحاملها التصويت أو التحقق من الصحة أو التفويض إلى validators أخرى. مثل Ethereum الأثير، يمكن أيضًا استخدام الذرات لدفع رسوم المعاملات تخفيف البريد العشوائي. ذرات إنزاتيوناري إضافية ومعاملة كتلة تتم مكافأة الرسوم إلى validator والمفوضين الذين يفوضون ذلك validators. ويمكن استخدام معاملة BurnAtomTx لاسترداد أي منها مبلغ متناسب من tokens من المجمع الاحتياطي. التوزيع الأولي للذرة tokens و validators في سفر التكوين سيذهب إلى الجهات المانحة لجمع التبرعات Cosmos (75%)، الجهات المانحة الرئيسية (5%)، Cosmos مؤسسة الشبكة (10%)، وALL IN BITS, Inc (10%). ومن لحظة التكوين فصاعدًا، سوف يصبح ثلث إجمالي كمية الذرات سيتم مكافأتك للمستعبدين validator والمفوضين كل عام. راجع خطة Cosmos للحصول على تفاصيل إضافية. على عكس Bitcoin أو غيره من proof-of-work blockchains، فإن Tendermint blockchain يصبح أبطأ مع المزيد من validators بسبب الزيادة تعقيد الاتصالات. ولحسن الحظ، يمكننا دعم ما يكفي validators لإنشاء blockchain قوي وموزع عالميًا مع أوقات تأكيد المعاملات السريعة جدًا، وعرض النطاق الترددي،
التخزين، وزيادة سعة الحوسبة الموازية، سنكون قادرين لدعم المزيد من validators في المستقبل. في يوم التكوين، سيتم تعيين الحد الأقصى لعدد validators إلى 100، وسيزداد هذا العدد بمعدل 13% لمدة 10 سنوات، و استقر عند 300 validators. يمكن لحاملي الذرة الذين ليسوا بالفعل أن يصبحوا validators بحلول التوقيع على معاملة BondTx وإرسالها. كمية الذرات المقدمة كضمان يجب أن تكون غير صفرية. يمكن لأي شخص أن يصبح validator في أي وقت، إلا عندما يكون حجم التيار مجموعة validator أكبر من الحد الأقصى لعدد validators مسموح به. في هذه الحالة، تكون المعاملة صالحة فقط إذا كان المبلغ الذرات أكبر من كمية الذرات الفعالة التي يحتفظ بها الأصغر validator، حيث تشمل الذرات الفعالة الذرات المفوضة. عندما يحل validator الجديد محل validator الحالي بهذه الطريقة، validator الموجود يصبح غير نشط وجميع الذرات و تدخل الذرات المفوضة إلى حالة فك الارتباط. يجب أن يتم فرض بعض العقوبات على validators لأي منها الانحراف المقصود أو غير المقصود عن العقوبة البروتوكول. يتم قبول بعض الأدلة على الفور، مثل أ علامة مزدوجة على نفس الارتفاع والدائرية، أو انتهاكا السنة 0: 100 السنة الأولى: 113 السنة الثانية: 127 السنة 3: 144 السنة الرابعة: 163 السنة 5: 184 السنة 6: 208 السنة 7: 235 السنة 8: 265 السنة 9: 300 السنة 10: 300 ...
"prevote-the-lock" (قاعدة من بروتوكول إجماع Tendermint). سيؤدي مثل هذا الدليل إلى فقدان validator لوضعه الجيد وذراتها المرتبطة بالإضافة إلى حصتها التناسبية البالغة tokens في سيتم تخفيض مجموع الاحتياطي - الذي يطلق عليه مجتمعًا "حصته" -. في بعض الأحيان، لن يكون validators متاحًا، إما بسبب المنطقة انقطاع الشبكة أو انقطاع التيار الكهربائي أو لأسباب أخرى. إذا، في أي نقطة في كتل ValidatorTimeoutWindow السابقة، validator لم يتم تضمين التصويت الالتزام في blockchain أكثر من مرات ValidatorTimeoutMaxAbsent، سيصبح validator غير نشط، وتفقد ValidatorTimeoutPenalty (الافتراضي 1%) من قيمته حصة. بعض السلوكيات "الخبيثة" لا يمكن تمييزها بشكل واضح الأدلة على blockchain. في هذه الحالات، يمكن لـ validators التنسيق خارج النطاق لفرض انتهاء مهلة هذه البرامج الضارة validators، إذا كان هناك إجماع بأغلبية ساحقة. في المواقف التي يتوقف فيها Cosmos Hub بسبب تحالف ≥⅓ من تختفي قوة التصويت، أو في الحالات التي يكون فيها ائتلاف ≥⅓ دليل رقابي على قوة التصويت على السلوك الخبيث من عند إدخال blockchain، يجب أن يتعافى المحور باستخدام شوكة صلبة اقتراح إعادة التنظيم. (رابط إلى "هجمات الشوكات والرقابة"). Cosmos يمكن للمحور validators قبول أي نوع أو مجموعة token أنواعها كرسوم معالجة معاملة. كل validator يمكن قم بتعيين سعر الصرف الذي تريده بشكل شخصي، ثم اختر مهما كانت المعاملات التي تريدها، طالما أن BlockGasLimit هو كذلك لم يتم تجاوزها. الرسوم المحصلة، ناقص أي ضرائب محددة أدناه، يتم إعادة توزيعها على أصحاب المصلحة المستعبدين بما يتناسب مع ذراتها المرتبطة، كل ValidatorPayoutPeriod (الافتراضي 1 ساعة).من بين رسوم المعاملات المحصلة، سيتم تطبيق ReserveTax (الافتراضي 2%) اذهب نحو تجمع الاحتياطي لزيادة تجمع الاحتياطي و زيادة أمان وقيمة شبكة Cosmos. هذه ويمكن أيضًا توزيع الأموال وفقًا للقرارات صنعها نظام الحكم. أصحاب الذرة الذين يفوضون سلطة التصويت الخاصة بهم إلى validators آخرين دفع عمولة للمفوض validator. يمكن للجنة يتم تعيينها بواسطة كل validator. يعد أمان Cosmos Hub إحدى وظائف أمان validators واختيار التفويض من قبل المفوضين. من أجل تشجيع الاكتشاف والإبلاغ المبكر عما تم العثور عليه الثغرات الأمنية، يشجع مركز Cosmos المتسللين على النشر عمليات استغلال ناجحة عبر معاملة ReportHackTx التي تنص على أن "هذا تم اختراق validator. من فضلك أرسل المكافأة إلى هذا العنوان". على مثل هذا الاستغلال، سيصبح validator والمفوضون غير نشطين، HackPunishmentRatio (الافتراضي 5%) من ذرات الجميع سيحصلون عليها مقطوعة، و HackRewardRatio (افتراضي 5%) من ذرات الجميع سوف تحصل على مكافأة على عنوان مكافأة المتسلل. validator يجب استعادة الذرات المتبقية باستخدام مفتاح النسخ الاحتياطي الخاص بهم. من أجل منع إساءة استخدام هذه الميزة للنقل الذرات غير المكتسبة، جزء من الذرات المكتسبة مقابل الذرات غير المكتسبة validators والمفوضون قبل وبعد ReportHackTx سوف تظل كما هي، وستتضمن مكافأة الهاكر بعضًا منها الذرات غير المستثمرة، إن وجدت. يتم تشغيل مركز Cosmos بواسطة مؤسسة موزعة يتطلب آلية حوكمة جيدة التصميم من أجل تنسيق التغييرات المختلفة على blockchain، مثل المتغير
معلمات النظام، بالإضافة إلى ترقيات البرامج و التعديلات الدستورية. جميع validator مسؤولون عن التصويت على جميع المقترحات. الفشل في سيؤدي التصويت على الاقتراح في الوقت المناسب إلى validator يتم إلغاء التنشيط تلقائيًا لفترة من الوقت تسمى عقوبة الغياب (أسبوع واحد افتراضيًا). يرث المفوضون صوت المفوض تلقائيًا validator. قد يتم تجاوز هذا التصويت يدويًا. الذرات غير المرتبطة لا تحصل على أي تصويت. يتطلب كل اقتراح إيداع مبلغ MinimumProposalDeposit tokens، والتي قد تكون مزيجًا من واحد أو أكثر من tokens بما في ذلك الذرات. بالنسبة لكل اقتراح، يجوز للناخبين التصويت لاتخاذه الوديعة. إذا اختار أكثر من نصف الناخبين التصويت الإيداع (على سبيل المثال، لأن الاقتراح كان غير مرغوب فيه)، يذهب الإيداع إلى المجمع الاحتياطي، باستثناء أي ذرات يتم حرقها. لكل مقترح، يمكن للناخبين التصويت بالخيارات التالية: نعم نعم مع القوة كلا NayWithForce امتنع عن التصويت أغلبية صارمة من أصوات نعم أو YeaWithForce (أو لا أو أصوات NayWithForce) مطلوبة حتى يتم تحديد الاقتراح تم إقراره (أو تقرر فشله)، ولكن يمكن لـ 1/3+ استخدام حق النقض ضد الأغلبية القرار بالتصويت "بالقوة". عندما يتم نقض الأغلبية الصارمة، تتم معاقبة الجميع بخسارة VetoPenaltyFeeBlocks (قيمة افتراضية للكتل ليوم واحد) بقيمة الرسوم (باستثناء الضرائب والتي لن تتأثر)، والحزب الذي اعترض على الأغلبية
ستتم معاقبة القرار أيضًا بخسارة VetoPenaltyAtoms (الافتراضي 0.1%) من ذراته. يمكن تغيير أي من المعلمات المحددة هنا باستخدام تمرير ParameterChangeProposal. يمكن تجميد الذرات واحتجاز أموال المجمع التي يتم إنفاقها باستخدام تمرير اقتراح المكافأة. جميع المقترحات الأخرى، مثل اقتراح ترقية البروتوكول، سيتم تنسيقه عبر TextProposal العام. انظر الخطة. لقد كان هناك العديد من الابتكارات في إجماع blockchain و قابلية التوسع في العامين الماضيين. يقدم هذا القسم نبذة مختصرة مسح لعدد مختار من المهم. الإجماع في وجود مشاركين خبيثين يمثل مشكلة يعود تاريخها إلى أوائل الثمانينيات، عندما صاغ ليزلي لامبورت عبارة "خطأ بيزنطي" للإشارة إلى سلوك العملية التعسفية ينحرف عن السلوك المقصود، على عكس "خطأ التصادم"، حيث تتعطل العملية ببساطة. تم اكتشاف الحلول المبكرة للشبكات المتزامنة حيث يوجد حد أعلىزمن وصول الرسالة، على الرغم من أن الاستخدام العملي كان يقتصر على درجة عالية البيئات الخاضعة للرقابة مثل وحدات التحكم في الطائرات و مراكز البيانات متزامنة عبر الساعات الذرية. ولم يكن حتى أواخر التسعينيات أن التسامح مع الخطأ البيزنطي العملي (PBFT) [11] كان تم تقديمه كإجماع متزامن فعال جزئيًا خوارزمية قادرة على تحمل ما يصل إلى ثلث العمليات التي تتصرف تعسفا. أصبحت PBFT هي الخوارزمية القياسية، مما أدى إلى ظهور العديد منها الاختلافات، بما في ذلك أحدثها التي تم إنشاؤها بواسطة IBM كجزء من مساهمتهم في Hyperledger. الميزة الرئيسية لإجماع Tendermint على PBFT هي ذلك يحتوي Tendermint على بنية أساسية محسنة ومبسطة، بعضها نتيجة لتبني نموذج blockchain. يجب أن تلتزم كتل Tendermint بالترتيب، مما يتجنب التعقيد وحمل الاتصالات المرتبط بـ PBFT تغييرات العرض. في Cosmos والعديد من العملات المشفرة، لا يوجد بحاجة إلى السماح للكتلة N+i حيث i >= 1 بالالتزام، عند الكتلة N نفسها لم تلتزم بعد. إذا كان عرض النطاق الترددي هو السبب وراء حظر N لم يتم الالتزام به في منطقة Cosmos، فلا يساعد في الاستخدام أصوات مشاركة النطاق الترددي للكتل N+i. إذا كان قسم الشبكة أو عقد ofzine هي السبب وراء عدم التزام الكتلة N N + لن ألتزم على أي حال. بالإضافة إلى ذلك، فإن تجميع المعاملات في كتل يسمح بذلك Merkle-hashing العادي لحالة التطبيق، بدلاً من الملخصات الدورية كما هو الحال مع مخطط نقاط التفتيش PBFT. هذا يسمح من أجل تنفيذ معاملات أسرع يمكن إثباتها للعملاء الخفيفين وبشكل أسرع التواصل بين blockchain. يتضمن Tendermint Core أيضًا العديد من التحسينات والميزات التي تتجاوز ما هو محدد في PBFT. على سبيل المثال، يتم تقسيم الكتل المقترحة بواسطة validators إلى أجزاء، بحجم Merkle، والنميمة بطريقة تعمل على تحسين البث الأداء (راجع LibSwift [19] للإلهام). أيضا، تندرمينت لا يقدم Core أي افتراضات حول نقطة إلى نقطة
الاتصال والوظائف طالما أن شبكة P2P موجودة متصلة بشكل ضعيف. على الرغم من أنها ليست أول من نشر proof-of-stake (PoS)، إلا أن BitShares1.0 [12] ساهم بشكل كبير في البحث واعتماد إثبات الحصة (PoS). blockchains، وخاصة تلك المعروفة باسم نقاط البيع "المفوضة". في BitShares، أصحاب المصلحة ينتخبون "الشهود"، المسؤولين عن الطلب وارتكاب المعاملات و"المندوبين" المسؤولين عنها تنسيق تحديثات البرامج وتغييرات المعلمات. يهدف BitShares2.0 إلى تحقيق أداء عالي (100k tx/s, 1s الكمون) في ظروف مثالية، مع كل كتلة موقعة من قبل واحد المُوقع، وتستغرق عملية المعاملة وقتًا أطول قليلاً من الفاصل الزمني للكتلة. لا تزال المواصفات الأساسية قيد التطوير. يمكن لأصحاب المصلحة إزالة أو استبدال الشهود الذين يسيئون التصرف على بشكل يومي، ولكن لا يوجد ضمانات هامة من الشهود أو المندوبون على غرار Tendermint PoS الذين تم اقتطاعهم حالة نجاح هجوم الإنفاق المزدوج. بناءً على النهج الذي ابتكرته شركة Ripple، Stellar [13] رينيد أ نموذج للاتفاقية البيزنطية الموحدة حيث تتم العمليات المشاركة في الإجماع لا تشكل yxed وعالميا مجموعة معروفة. بدلاً من ذلك، تقوم كل عقدة عملية برعاية واحدة أو أكثر "شرائح النصاب"، يشكل كل منها مجموعة من العمليات الموثوقة. أ "النصاب القانوني" في Stellar مصمم ليكون مجموعة من العقد التي تحتوي على شريحة نصاب واحدة على الأقل لكل عقدة في المجموعة، بحيث يمكن التوصل إلى اتفاق. يعتمد أمان آلية Stellar على الافتراض أن تقاطع أي نصابين غير فارغ، في حين أن يتطلب توفر العقدة شريحة واحدة على الأقل من شرائح النصاب القانوني الخاصة بها تتكون بالكامل من العقد الصحيحة، مما يخلق مفاضلة بين استخدام شرائح النصاب الكبيرة أو الصغيرة التي قد يكون من الصعب تحقيق التوازن فيها دون فرض افتراضات هامة حول الثقة. أخيرًا،يجب أن تختار العقد بطريقة أو بأخرى شرائح النصاب القانوني المناسبة لذلك أن يكون كافيًا للتسامح مع الأخطاء (أو أي "عقد سليمة" على الإطلاق، منها الكثير من نتائج الورقة تعتمد على)، والوحيد الإستراتيجية المقدمة لضمان مثل هذا التكوين هي تسلسل هرمي وهو مشابه لبروتوكول بوابة الحدود (BGP)، الذي يستخدمه مزودو خدمة الإنترنت من الدرجة الأولى على الإنترنت لإنشاء جداول التوجيه العالمية، ومن خلال التي تستخدمها المتصفحات لإدارة شهادات TLS؛ كلاهما سيئ السمعة لانعدام الأمن لديهم. تم تخفيف الانتقادات الواردة في ورقة Stellar الخاصة بأنظمة إثبات الملكية القائمة على Tendermint من خلال استراتيجية token الموضحة هنا، حيث يتم إصدار نوع جديد من token يسمى الذرة تمثل المطالبات بالأجزاء المستقبلية من الرسوم والمكافآت. ال إن ميزة proof-of-stake المستندة إلى Tendermint هي قريبها البساطة، مع الاستمرار في توفير الأمان الكافي والقابل للإثبات الضمانات. BitcoinNG هو تحسين مقترح لـ Bitcoin من شأنه أن يسمح لأشكال قابلية التوسع الرأسي، مثل زيادة حجم الكتلة، دون العواقب الاقتصادية السلبية المرتبطة عادة مع مثل هذا التغيير، مثل التأثير الكبير بشكل غير متناسب على عمال المناجم الصغيرة. ويتحقق هذا التحسن عن طريق الانفصال انتخاب القائد من بث المعاملات: القادة هم الأولون تم انتخابه بواسطة proof-of-work في "الكتل الصغيرة"، ثم أصبح قادرًا على ذلك يجب الالتزام بمعاملات البث حتى يتم إنشاء كتلة صغيرة جديدة تم العثور عليه. وهذا يقلل من متطلبات عرض النطاق الترددي اللازمة ل الفوز بسباق إثبات العمل (PoW)، مما يسمح لصغار عمال المناجم بالمنافسة بشكل أكثر عدالة، والسماح بإجراء المعاملات بشكل أكثر انتظامًا بواسطة آخر عامل منجم يعثر على كتلة صغيرة. Casper [16] عبارة عن خوارزمية إجماع proof-of-stake مقترحة لـ Ethereum. أسلوب عملها الأساسي هو "الإجماع على الرهان". بواسطة السماح لـ validators بالمراهنة بشكل متكرر على الكتلة التي يعتقدون أنها ستفعل
تصبح ملتزمًا بـ blockchain بناءً على الرهانات الأخرى كما رأوه حتى الآن، يمكن تحقيق النزعة الجنسية في نهاية المطاف. وصلة. يعد هذا مجال بحث نشط بواسطة فريق Casper. ال التحدي يكمن في بناء آلية الرهان التي يمكن أن تكون ثبت أنها استراتيجية مستقرة تطوريا. الفائدة الرئيسية من قد يكون Casper مقارنةً بـ Tendermint في تقديم "التوافر". "على الاتساق" - لا يتطلب الإجماع أكثر من ⅔ النصاب القانوني قوة التصويت - ربما على حساب سرعة الالتزام أو تعقيد التنفيذ. لا يعد بروتوكول Interledger [14] حلاً قابلاً للتوسع بشكل صارم. ذلك يوفر التشغيل البيني المخصص بين دفاتر الأستاذ المختلفة الأنظمة من خلال شبكة علاقات ثنائية مترابطة بشكل فضفاض. مثل شبكة Lightning Network، فإن الغرض من ILP هو التسهيل المدفوعات، لكنه يركز بشكل خاص على المدفوعات عبر متباينة أنواع دفتر الأستاذ، وتمتد آلية المعاملات الذرية إلى لا تتضمن فقط hash-الأقفال، ولكن أيضًا النصاب القانوني لكتاب العدل (يسمى بروتوكول النقل الذري). الآلية الأخيرة ل إن فرض الذرية في المعاملات بين دفاتر الأستاذ يشبه آلية SPV العميلة الخفيفة الخاصة بـ Tendermint، مثال توضيحي لـ التمييز بين ILP و Cosmos/IBC أمر مضمون، و المنصوص عليها أدناه. 1. لا يدعم كتاب العدل للموصل في ILP العضوية التغييرات، ولا تسمح بالترجيح بين كتاب العدل. من ناحية أخرى، تم تصميم IBC خصيصًا لـ blockchains، حيث يمكن أن يكون لـ validators أوزان مختلفة، و حيث يمكن أن تتغير العضوية على مدار blockchain. 2. كما هو الحال في Lightning Network، متلقي الدفع في ILP يجب أن يكون متصلاً بالإنترنت لإرسال رسالة تأكيد إلى المرسل. في أtoken نقل عبر IBC، مجموعة validator لجهاز الاستقبال blockchain هو المسؤول عن توفير التأكيد، وليس استقبال المستخدم. 3. الفرق الأكثر لفتًا للانتباه هو أن موصلات ILP ليست كذلك مسؤولاً أو يحتفظ بحالة موثوقة بشأن المدفوعات، بينما في Cosmos، validators للمحور هي سلطة حالة IBC token عمليات النقل بالإضافة إلى سلطة كمية tokens التي تحتفظ بها كل منطقة (ولكن ليس مقدار tokens التي يحتفظ بها كل حساب داخل المنطقة). هذا هو الابتكار الأساسي الذي يسمح بأمان غير متماثل نقل tokens من منطقة إلى أخرى؛ التناظرية لـ ILP الموصل في Cosmos هو موصل ثابت وآمن إلى أقصى حد blockchain دفتر الأستاذ، مركز Cosmos. 4. يجب أن تكون المدفوعات بين دفاتر الأستاذ في ILP مدعومة بـ دفتر أوامر الصرف، حيث لا يوجد نقل غير متماثل لـ عملات معدنية من دفتر أستاذ إلى آخر، فقط نقل القيمة أو معادلات السوق. السلاسل الجانبية [15] هي آلية مقترحة لتوسيع نطاق Bitcoin الشبكة عبر blockchains البديلة "المرتبطة في اتجاهين". Bitcoin blockchain. (الربط في اتجاهين يعادل التجسير. في Cosmos نقول "جسر" للتمييز عن ربط السوق). تسمح السلاسل الجانبية لعملات البيتكوين بالانتقال بشكل فعال من Bitcoin blockchain إلى السلسلة الجانبية والظهر، والسماح بـ تجربة الميزات الجديدة على السلسلة الجانبية. كما في Cosmos Hub والسلسلة الجانبية وBitcoin بمثابة عملاء خفيفين لـ بعضها البعض، باستخدام أدلة SPV لتحديد متى يجب أن تكون العملات المعدنية نقل إلى Sidechain والعودة. بالطبع منذ Bitcoin الاستخدامات proof-of-work، تعاني السلاسل الجانبية المتمركزة حول Bitcoin من مشاكل ومخاطر proof-of-work العديدة كما أ آلية الإجماع. علاوة على ذلك، هذا هو الحد الأقصى Bitcoin الحل الذي لا يدعم أصلاً مجموعة متنوعة من tokens و
طوبولوجيا الشبكة بين المناطق كما يفعل Cosmos. وقيل: جوهر آلية الربط في الاتجاهين هي من حيث المبدأ نفس تلك الآلية يعمل لدى شبكة Cosmos. يقوم Ethereum حاليًا بالبحث في عدد من الاستراتيجيات المختلفة لتقسيم حالة Ethereum blockchain لمعالجة احتياجات قابلية التوسع. وتهدف هذه الجهود إلى الحفاظ على طبقة التجريد التي تقدمها الآلة الافتراضية Ethereum الحالية عبر مساحة الدولة المشتركة. الجهود البحثية المتعددة هي الجارية في هذا الوقت. [18][22] Cosmos وEthereum 2.0 بنفسجي [22] لهما أهداف تصميمية مختلفة. Cosmos يتعلق بشكل خاص بـ tokens. البنفسجي يدور حول القياس الحساب العام. Cosmos غير مرتبط بـ EVM، لذلك يمكن حتى للأجهزة الافتراضية المختلفة التفاعل. Cosmos يتيح لمنشئ المنطقة تحديد من يقوم بالتحقق من صحة المنطقة. يمكن لأي شخص أن يبدأ منطقة جديدة في Cosmos (ما لم تكن الإدارة يقرر خلاف ذلك). يقوم المحور بعزل حالات فشل المنطقة بحيث تكون الثوابت العالمية token كذلك محفوظ. الشبكة المسرّعة هي شبكة نقل مقترحة token تعمل في طبقة أعلى Bitcoin blockchain (وغيرها من الطبقات العامة blockchains)، مما يتيح تحسين العديد من أوامر الحجم في إنتاجية المعاملات عن طريق نقل غالبية المعاملات خارج دفتر الأستاذ الإجماعي إلى ما يسمى "قنوات الدفع".أصبح هذا ممكنًا بفضل البرامج النصية للعملات المشفرة الموجودة على السلسلة، والتي تمكين الأطراف من الدخول في عقود ثنائية الحالة حيث يمكن تحديث الحالة من خلال مشاركة التوقيعات الرقمية والعقود يمكن إغلاقه عن طريق نشر الأدلة بشكل صريح على blockchain، أ الآلية التي تم نشرها لأول مرة عن طريق المقايضة الذرية عبر السلسلة. بواسطة فتح قنوات الدفع مع العديد من الأطراف والمشاركين في يمكن أن تصبح الشبكة المسرّعة نقاطًا محورية لتوجيه الشبكة مدفوعات الآخرين، مما يؤدي إلى قناة دفع متصلة بالكامل الشبكة، على حساب رأس المال الذي يتم ربطه بقنوات الدفع. بينما يمكن للشبكة المسرّعة أيضًا أن تمتد بسهولة عبرها عدة blockchains مستقلة للسماح بنقل القيمة عبر سوق الصرف، لا يمكن استخدامه بشكل غير متماثل نقل tokens من blockchain إلى آخر. الفائدة الرئيسية الغرض من شبكة Cosmos الموصوفة هنا هو تمكين هذا التوجيه المباشر token التحويلات. ومع ذلك، فإننا نتوقع قنوات الدفع و سيتم اعتماد شبكة Lightning Network على نطاق واسع جنبًا إلى جنب مع شبكتنا token آلية النقل، لتوفير التكاليف ولأسباب تتعلق بالخصوصية. الشاهد المنفصل هو رابط مقترح تحسين Bitcoin يهدف إلى زيادة إنتاجية المعاملات لكل كتلة 2X أو 3X، مع جعل مزامنة الكتلة أسرع للعقد الجديدة في نفس الوقت. يكمن تألق هذا الحل في كيفية عمله داخل قيود بروتوكول Bitcoin الحالي وتسمح بالشوكة الناعمة الترقية (أي أن العملاء الذين لديهم إصدارات أقدم من البرنامج سوف يقومون بذلك الاستمرار في العمل بعد الترقية). تندرمينت، كونها جديدة البروتوكول ليس له قيود على التصميم، لذلك له مقياس مختلف الأولويات. في المقام الأول، يستخدم Tendermint خوارزمية BFT المستديرة على أساس التوقيعات التشفير بدلا من التعدين، والتي يسمح بشكل تافه بالتحجيم الأفقي من خلال التوازي المتعدد blockchains، بينما تسمح عمليات الحظر المنتظمة والمتكررة بذلك التحجيم العمودي كذلك.
コンセンサスと技術的詳細
適切に設計されたコンセンサスプロトコルは、いくつかの機能を提供する必要があります。 許容範囲を超えた場合の保証 そしてコンセンサスは失敗します。これは経済面で特に必要です ビザンチンの行動が重大な経済的影響を与える可能性があるシステム 報酬。このような保証の中で最も重要なのは、責任追及の一形態であり、コンセンサスを引き起こしたプロセスが 失敗 (つまり、プロトコルのクライアントが異なる値を受け入れる原因となった - フォーク）は特定され、規則に従って処罰される可能性があります。 議定書、あるいは場合によっては法制度。法制度が整うと、 validators は信頼性が低いか、呼び出しコストが高すぎるため、 参加するために保証金の預け入れを強制される、および 悪意のある行為があった場合、預金は取り消されるか、削減される可能性があります。 [10] が検出されました。 これは、フォークが定期的に発生する Bitcoin とは異なることに注意してください。 ネットワークの非同期性と ynding の確率的性質によるもの 部分的なhash衝突。多くの場合、悪意のあるフォークは Bitcoin は非同期のためフォークと区別できません。 暗黙的なもの以外のフォーク責任を確実に実装する 孤立したブロックをマイニングするためにマイナーが支払う機会コスト。 投票ステージを PreVote および PreCommit と呼びます。投票できるのは、 特定のブロックまたは Nil の場合。 2/3 を超える PreVote のコレクションを呼び出します 同じラウンド内の単一ブロックの場合はポルカ、および >2/3 のコレクション コミットと同じラウンド内の単一ブロックの PreCommit。 >2/3の場合 同じラウンドで Nil を PreCommit すると、次のラウンドに進みます。 丸い。 プロトコルの厳密な決定論は脆弱性を招くことに注意してください。 欠陥のあるリーダーを検出する必要があるため、同期性を仮定し、
スキップしました。したがって、validator はある程度の時間待機します。 TimeoutPropose、Prevote Nil の前、および の値 TimeoutPropose はラウンドごとに増加します。進行状況 ラウンドの残りの部分は完全に非同期であり、進行状況だけが表示されます。 validator がネットワークの 2/3 以上からの信号を受信すると行われます。実際には、 それを際限なく阻止するには極めて強力な敵が必要となるだろう 弱い同期性の仮定 (コンセンサスの失敗を引き起こす) ブロックをコミットすることはありません）、そうすることでさらに多くのことを行うことができます それぞれの TimeoutPropose のランダムな値を使用して、difycult を実行します。 validator。 追加の制約セットまたはロック ルールにより、 ネットワークは最終的に各高さで 1 つのブロックだけをコミットします。どれでも 複数のブロックをコミットさせる悪意のある試み 特定の高さで識別できます。まず、ブロックの PreCommit そのブロックのポルカの形で、正当性を示す必要があります。 validator がラウンド R_1 ですでにブロックを PreCommit している場合、 彼らはそのブロックに閉じ込められていると言い、ポルカはそれを正当化するために使用されていました ラウンド R_2 の新しい PreCommit はラウンド R_polka に含まれる必要があります ここで、R_1 < R_polka <= R_2。第二に、validator は提案する必要があります および/またはロックオンされているブロックを事前投票します。これらを合わせて、 条件により、validator が事前コミットされないことが保証されます。 正当性として十分な証拠があり、validator が すでに PreCommit は PreCommit に証拠を提供できません 何か他のもの。これにより、安全性と生存性の両方が確保されます。 コンセンサスアルゴリズム。 プロトコルの完全な詳細はここで説明されています。 TendermintPoS では、代替チェーン (フォーク) の存在が 1/3 以上のブロック ヘッダーを同期することを意味するため、すべてのブロック ヘッダーを同期する必要がなくなります。 結合された杭は切断することができます。もちろん、斬撃には必要なものがあるので、 誰かがフォークの証拠を共有した場合、ライトクライアントは保存する必要があります 表示されるブロック hash のコミット。さらに、ライトクライアントvalidator セットへの変更を定期的に同期し続けることができます。 長距離攻撃を避けるため（ただし、他の解決策は 可能です）。 Ethereum と同様の精神で、Tendermint はアプリケーションで次のことを可能にします。 各ブロックにグローバル マークル ルート hash を埋め込み、簡単に許可します 口座残高や金額などの非常に詳細な状態クエリ 契約に保存されているか、または未使用のトランザクションの存在 アプリケーションの性質に応じて出力します。 ブロードキャスト ネットワークのコレクションが十分に復元力があると仮定する および静的 validator セットの場合、blockchain 内の任意のフォークを が検出され、違反したvalidatorの預金が削減されました。これ 2014 年初めに Vitalik Buterin によって最初に提案されたイノベーションは、問題を解決します 他の proof-of-stake の何も問題がない問題 暗号通貨 (関連作品を参照)。ただし、validator が設定されているため、 長期間にわたって元の状態を変更できなければなりません validator はすべて結合解除される可能性があるため、自由に ジェネシスブロックから新しいチェーンを作成し、コストはかかりません 彼らはもう預金をロックされていません。この攻撃はこうなった ショート攻撃とは対照的に、ロングレンジ攻撃（LRA）として知られています。 範囲攻撃。現在結合している validator 人が フォークであるため、罰せられることになります (フォークの責任があると仮定します BFT Tendermint コンセンサスのようなアルゴリズム)。遠距離攻撃は、 proof-of-stake にとって致命的な打撃となると考えられています。 幸いなことに、LRA は次のように軽減できます。まず、 validator を解除する (それにより担保預金を回収する) コンセンサスに参加するための手数料を得ることができなくなります）、 デポジットは一定期間譲渡不能にしなければなりません これは「結合解除期間」として知られており、 数週間または数か月。次に、ライト クライアントを安全にするためには、まず ネットワークに接続するときに、最近のブロックを確認する必要があります-hash 信頼できるソース、またはできれば複数のソースに対して。これ
この状態は「主観性が弱い」と呼ばれることもあります。最後に、 安全を確保するには、次の場所に設定された最新の validator と同期する必要があります。 少なくとも結合解除期間の長さと同じくらいの頻度で。これ ライト クライアントが validator への変更を確実に認識できるようにします。 validator の資本が結合解除され、資本が結合されなくなる前に設定された 危険にさらされているため、次のことを実行してクライアントを欺くことが可能になります。 新しいブロックを作成して遠距離攻撃を開始します。 接着された高さ (十分に制御できると仮定) 初期の秘密鍵の多く）。 この方法で LRA を克服するには、 proof-of-work のオリジナルのセキュリティ モデル。 PoWでは、それは ライトクライアントが現在の高さに同期できることを前提としています。 すべてのブロックヘッダーでproofof workを処理するだけで、いつでも信頼できるジェネシスブロックを作成できます。しかし、LRAを克服するには、 ライトクライアントが一定の規則性を持ってオンラインになることを要求する validator セットの変更を追跡し、最初に変更したとき オンラインになると認証に特に注意する必要があります 信頼できるソースに対してネットワークから聞いたこと。の もちろん、この後者の要件は Bitcoin の要件と似ています。 プロトコルとソフトウェアも信頼できる機関から入手する必要があります。 ソース。 LRA を防止する上記の方法は、validator に適しています。 Tendermint を利用した blockchain のフル ノードは、次のとおりです。 ノードはネットワークに接続されたままになるように設計されています。の この方法は、次のような効果が期待できるライト クライアントにも適しています。 ネットワークと頻繁に同期します。ただし、ライトクライアントの場合は、 インターネットや blockchain ネットワーク、さらに別のソリューションを使用して克服することができます LRA。 validator 以外の token 所有者は、token を次の名前で投稿できます 非常に長い解放期間を持つ担保 (例: 非常に長い) validators の結合解除期間よりも)、ライトクライアントにサービスを提供します 現在のデータの有効性を証明する二次的な方法と 過去のブロック-hashes。これらのtokenは、 blockchain のコンセンサスの安全性が確保されているにもかかわらず、彼らは次のことを行うことができます。ライトクライアントに強力な保証を提供します。過去のブロックの場合-hash クエリは Ethereum でサポートされており、誰でも自分のデータを結合できます。 token を特別に設計された smart contract で提供し、 有料の認証サービスにより、ライトクライアント LRA セキュリティの市場が効果的に創出されます。 ブロックコミットの定義により、すべての ≥1/3 連合は、 投票権は、オフラインになるかどうかによって、blockchain を停止できる可能性があります 彼らの投票をブロードキャストします。このような連合は検閲も行うことができる 特定のトランザクションを含むブロックを拒否することにより、 ただし、これはかなりの割合を占めることになります 拒否されるブロック提案の割合、これにより速度が低下する blockchain のブロック コミットが減少し、その有用性と価値が減少します。 悪意のある連合は、投票を少しずつ放送する可能性もあります。 blockchain ブロックを粉砕する場合、ほぼ停止するか、または開始します。 これらの攻撃のあらゆる組み合わせ。最後に、次のような問題を引き起こす可能性があります。 blockchain は二重署名またはロック違反によりフォークします ルール。 世界的に活動する敵も関与した場合、分断される可能性があります 間違っているように見えるような方法でネットワークに接続する validator のサブセットが速度低下の原因でした。これはそうではありません これは Tendermint の単なる制限ではなく、すべての制限です ネットワークが潜在的に制御されているコンセンサス プロトコル 積極的な敵。 このようなタイプの攻撃の場合、validator のサブセットは次のようにする必要があります。 外部手段を通じて調整し、以下の再編成提案に署名する。 フォーク (およびその証拠) と最初のサブセットを選択します。 validator と署名。このような再組織化提案に署名した検証者は、他のすべてのフォークでの担保を放棄します。クライアントは次のことを行う必要があります。 再編成提案書の署名を検証し、証拠を検証します。 そしてエンドユーザーに判断を下したり、決定を促したりします。のために たとえば、携帯電話のウォレット アプリはユーザーにセキュリティを要求する場合があります。
警告、一方、冷蔵庫はあらゆる再編成提案を受け入れる可能性があります 投票権により元の validator の +1/2 が署名しました。 非同期ビザンチン フォールト トレラント アルゴリズムは実現できません 投票権の 1/3 以上が不正であるにもかかわらず、フォークである場合に合意を形成する 投票権の 1/3 以上が既に不正行為を受けていると仮定します。 正当な理由なく二重署名またはロックを変更すること。ということで、サイン会 reorg-proposal は調整の問題であり、調整することはできません。 非同期プロトコルによって解決されます（つまり、自動的に、 信頼性について仮定を置くことなく、 基礎となるネットワーク)。今のところ、再組織化提案の調整の問題は、社会的合意を介した人間の調整に任せます。 インターネットメディアで。バリデータは、 2 つの再組織提案が同時に署名される状況を避けるため、再組織提案に署名する前にネットワーク パーティションが残っていないこと。 外部調整メディアとプロトコルが 堅牢であるため、フォークは検閲よりも懸念されるということになります。 攻撃します。 フォークと検閲に加えて、1/3 以上の Byzantine が必要です 投票権がある場合、2/3 を超える投票権を有する連合が関与する可能性がある 任意の無効な状態。これはあらゆるものの特徴です (BFT) コンセンサスシステム。フォークを作成する二重署名とは異なります。 簡単に検証できる証拠を用いて、犯罪者の関与を検出します。 無効な状態では、非検証ピアがブロック全体を検証する必要があります。 これは、状態のローカルコピーを保持して実行することを意味します。 各トランザクションでは、ステート ルートを個別に計算します。 自分たち自身。一旦検出されると、そのような障害に対処する唯一の方法 それは社会的合意によるものです。たとえば、Bitcoin のような状況では、 ソフトウェアのバグによるフォークかどうかにかかわらず、失敗しました（3 月の場合と同様） 2013)、またはビザンチン動作による無効な状態のコミット マイナー (2015 年 7 月時点)、よくつながったコミュニティ 企業、開発者、マイナー、その他の組織 手動行為とは何かについての社会的コンセンサスを確立した参加者がネットワークを修復するために必要とするもの。さらに、以来、 テンダーミントの validator blockchain は、 識別可能ですが、無効な状態のコミットメントは、 必要に応じて、法律または外部の判例によって罰せられる可能性があります。 ABCI は、配信される 3 つの主要なメッセージ タイプで構成されます。 アプリケーションのコア。アプリケーションは次のように応答します。 対応する応答メッセージ。 AppendTx メッセージはアプリケーションの主力製品です。それぞれ blockchain のトランザクションは、このメッセージとともに配信されます。の アプリケーションは、受信した各トランザクションを検証する必要があります。 現在の状態、アプリケーション プロトコル、 およびトランザクションの暗号化資格情報。検証済み その後、トランザクションはアプリケーションの状態を更新する必要があります。 値をキー値ストアにバインドするか、UTXO を更新します。 データベース。 CheckTx メッセージは AppendTx に似ていますが、目的は次のとおりです。 トランザクションの検証。 Tendermint Core の mempool の最初のチェック CheckTx によるトランザクションの有効性を確認し、有効なリレーのみを確認します。 ピアへのトランザクション。アプリケーションは増分をチェックする場合があります トランザクション内で nonce が発生し、次の場合は CheckTx でエラーを返します。 nonce は古いです。 Commit メッセージは、暗号化を計算するために使用されます。 現在のアプリケーションの状態に対するコミットメント。 次のブロックヘッダー。これには便利なプロパティがいくつかあります。 その状態を更新する際の不一致は、次のように表示されます。 blockchain プログラミングのクラス全体をキャッチするフォーク エラー。これにより、安全で軽量なシステムの開発も簡素化されます。 Merkle-hash の証明は、クライアントと照合することで検証できます。 ブロック-hashとブロック-hashは定足数によって署名されています。 validators (投票権による)。
追加の ABCI メッセージにより、アプリケーションは次のメッセージを追跡できるようになります。 validator セットを変更し、アプリケーションが 高さやコミット投票などのブロック情報。 ABCI リクエスト/レスポンスは単純な Protobuf メッセージです。チェックする スキーマファイルを外します。 引数: Data ([]byte) : リクエスト トランザクション バイト 戻り値: コード (uint32) : 応答コード Data ([]byte) : 結果のバイト (存在する場合) ログ (文字列) : デバッグまたはエラー メッセージ 使用法:
トランザクションを追加して実行します。トランザクションが有効であれば、 CodeType.OK を返します 引数: Data ([]byte) : リクエスト トランザクション バイト 戻り値: コード (uint32) : 応答コード Data ([]byte) : 結果のバイト (存在する場合) ログ (文字列) : デバッグまたはエラー メッセージ 使用法:
トランザクションを検証します。このメッセージは、 状態。トランザクションはまず CheckTx を介して実行されます。 mempool 層のピアにブロードキャストします。作ることができます CheckTx セミステートフルで、コミット時に状態をクリアするか、 BeginBlock 、トランザクションの依存シーケンスを許可します。 同じブロック内にあります。
戻り値: データ ([] バイト) : マークル ルート hash ログ (文字列) : デバッグまたはエラー メッセージ 使用法:
アプリケーション状態のマークル ルート hash を返します。 引数: Data ([]byte) : クエリリクエストのバイト数 戻り値: コード (uint32) : 応答コード Data ([]byte) : クエリ応答バイト ログ (文字列) : デバッグまたはエラー メッセージ 使用法:
応答キューをフラッシュします。実装するアプリケーション types.Application はこのメッセージを実装する必要はありません。 プロジェクトが担当します。 戻り値: Data ([]byte) : 情報バイト 使用法:
アプリケーションの状態に関する情報を返します。アプリケーション 特定の。 引数: Key (string) : 設定するキー
値（文字列） : キーに設定する値 戻り値: ログ (文字列) : デバッグまたはエラー メッセージ 使用法:
アプリケーションのオプションを設定します。例えば。 Key = “mode”、Value = “mempool” メモリプール接続、または Key=“mode”、Value=“consensus” コンセンサス接続。他のオプションはアプリケーション固有です。 引数: バリデーター ([]バリデーター) : 初期の起源 - validators 使用法:
創世記に一度呼ばれた 引数: Height (uint64) : 開始するブロックの高さ 使用法:
新しいブロックの始まりを知らせます。事前に呼び出される AppendTxs。 引数: Height (uint64) : 終了したブロックの高さ 戻り値: バリデータ ([]バリデータ) : validator を新しいものに変更しました 投票権 (削除するには 0) 使用法:
ブロックの終わりを知らせます。結局、各コミットの前に呼び出されます トランザクション 詳細については、ABCI リポジトリを参照してください。送信者が 受信チェーンによるパケットの配信の確認。 たとえば、送信者はメッセージのステータスを知らない可能性があります。 宛先チェーンに障害があると予想される場合。または、送信者は パケットにタイムアウトを課したい（MaxHeight を使用） パケット イールド）、宛先チェーンは受信パケット数の突然の急増によるサービス拒否攻撃を受ける可能性があります。 パケット。 このような場合、送信者は配送確認を要求できます。 パケットの初期ステータスを「AckPending」に設定します。それから、それは、 受領チェーンには、 アプリ Merkle hash では、IBCPacket と略されます。 まず、IBCBlockCommit と IBCPacketTx が「ハブ」に投稿されます これは、「Zone1」に IBCPacket が存在することを証明します。そう言ってください IBCPacketTx には次の値があります。 FromChainID : “Zone1” FromBlockHeight : 100 (たとえば) パケット: IBCパケット:
ヘッダー: IBCPacketHeader: SrcChainID：「ゾーン1」 DstChainID：「ゾーン2」 数 : 200 (例) ステータス : 確認保留中 種類：「コイン」 MaxHeight : 350 (「ハブ」が現在高さ 300 であるとします) ペイロード : <「コイン」ペイロードのバイト数> 次に、IBCBlockCommit と IBCPacketTx が「Zone2」に投稿されます。 これは、「ハブ」上にIBCパケットが存在することを証明します。そう言ってください IBCPacketTx には次の値があります。 FromChainID : 「ハブ」 ブロックからの高さ : 300 パケット: IBCパケット: ヘッダー: IBCPacketHeader: SrcChainID：「ゾーン1」 DstChainID：「ゾーン2」 数 : 200 ステータス : 確認保留中 種類：「コイン」 最大高さ : 350 ペイロード : <「コイン」ペイロードの同じバイト> 次に、「Zone2」はアプリに短縮パケットを含める必要があります-hash これは、「AckSent」の新しいステータスを示しています。 IBCBlockCommit と IBCPacketTx は存在を証明する「ハブ」にポストバックされます 「Zone2」上の短縮型 IBCパケット 。 IBCPacketTx と言ってください には次の値があります。 FromChainID : “Zone2”
FromBlockHeight : 400 (たとえば) パケット: IBCパケット: ヘッダー : IBCPacketHeader : SrcChainID：「ゾーン1」 DstChainID：「ゾーン2」 数 : 200 ステータス : 送信済み 種類：「コイン」 最大高さ : 350 PayloadHash : <同じ「コイン」ペイロードの hash バイト> 最後に、「ハブ」はパケットのステータスを更新する必要があります。 AckPending から AckReceived まで。この新たな状況の証拠 「Zone2」に戻る必要があります。 IBCPacketTx に次のものがあるとします。 値: FromChainID : 「ハブ」 ブロックの高さから: 301 パケット: IBCパケット: ヘッダー: IBCPacketHeader: SrcChainID：「ゾーン1」 DstChainID：「ゾーン2」 数 : 200 ステータス : 受信確認済み 種類：「コイン」 最大高さ : 350 PayloadHash : <同じ「コイン」ペイロードの hash バイト> 一方、「Zone1」は配信が成功すると楽観的に考える可能性がある 反対の証拠が証明されない限り、「コイン」パケットの 「ハブ」。上の例では、「ハブ」が AckSent を受信していなかった場合
ブロック 350 によって「Zone2」からステータスを取得すると、ステータスが設定されます。 自動的にタイムアウトになります。このタイムアウトの証拠は、 「Zone1」にポストバックされ、token を返すことができます。 では 2 種類の Merkle tree がサポートされています。 Tendermint/Cosmos エコシステム: シンプル ツリーと IAVL+ 木。 シンプル ツリーは、要素の静的リストの Merkle tree です。もし 項目の数は 2 の累乗ではありません。一部の葉は次のようになります。 さまざまなレベル。シンプル ツリーはツリーの両側を維持しようとします。 高さは同じですが、左の方が一つ大きいかもしれません。このMerkle treeは ブロックのトランザクションをマークル化するために使用され、トップレベル アプリケーション状態ルートの要素。IAVL+ データ構造の目的は、永続的なデータ構造を提供することです。 アプリケーション状態のキーと値のペアのストレージ。 決定論的なマークルルート hash を効率的に計算できます。の ツリーは AVL アルゴリズムのバリアントを使用してバランスがとられており、すべて 操作は O(log(n)) です。 AVL ツリーでは、任意のノードの 2 つの子サブツリーの高さ 最大でも 1 つ違います。この条件に違反するたびに、 更新すると、O(log(n)) 個の新しいノードを作成することによってツリーが再バランスされます。 古いツリーの変更されていないノードを指します。オリジナルのAVLでは アルゴリズムでは、内部ノードもキーと値のペアを保持できます。 AVL+ アルゴリズム (プラスに注意してください) すべてを維持するために AVL アルゴリズムを変更します キーを保存するためにブランチノードのみを使用しながら、リーフノードに値を格納します。 これにより、マークル hash の証跡を維持しながらアルゴリズムが簡素化されます。 短い。 AVL+ ツリーは、Ethereum のパトリシアの試みに似ています。あります トレードオフ。キーを挿入する前に hash する必要はありません。 IAVL+ ツリーにより、キー内の順序付けされた反復が高速化されます。 一部のアプリケーションに役立つ可能性のあるスペース。ロジックはもっと簡単です 内部ノードと内部ノードの 2 種類のノードのみが必要な実装です。 葉のノード。マークル証明は平均して短く、 * / \ / \ / \ / \ * * / \ / \ / \ / \ / \ / \ * * * h6 / \ / \ / \ h0 h1 h2 h3 h4 h5 7 つの要素を持つ SimpleTree
バランスの取れた二分木。一方、次のマークル根は、 IAVL+ ツリーは更新の順序に依存します。 次のような追加の効率的な Merkle tree をサポートします。 Ethereum のパトリシア トライは、バイナリ バリアントが次の場合に発生します。 利用可能です。 正規の実装では、トランザクションは Cosmos ハブ アプリケーション (ABCI インターフェイス経由)。 Cosmos ハブは、多数のプライマリ トランザクションを受け入れます タイプ（SendTx、BondTx、UnbondTx、ReportHackTx など）、 SlashTx、BurnAtomTx、ProposalCreateTx、ProposalVoteTx、 これらは非常に一目瞭然であり、次の文書に記載されています。 この文書の将来の改訂。ここでは 2 つの主要な点を文書化します。 IBC のトランザクション タイプ: IBCBlockCommitTx および IBCPacketTx。 IBCBlockCommitTx トランザクションは次のもので構成されます。 ChainID (文字列) : blockchain の ID BlockHash ([]byte) : block-hash バイト、マークル ルート これにはアプリ hash が含まれます BlockPartsHeader (PartSetHeader) : ブロック パーツ セット ヘッダー バイト、投票署名を検証する場合にのみ必要 BlockHeight (int) : コミットの高さ BlockRound (int) : コミットのラウンド Commit ([]Vote) : >2/3 の Tendermint プレコミットが次のことに投票します。 ブロックコミットを構成する ValidatorsHash ([]byte) : 新しいマークルツリー ルート hash validator セット
ValidatorsHashProof (SimpleProof) : BlockHash に対して ValidatorsHash を証明するための SimpleTree Merkleproof
AppHash ([]byte) : の IAVLTree マークルツリー ルート hash
アプリケーションの状態
AppHashProof（SimpleProof）：SimpleTree Merkle-proof
AppHash を BlockHash に対して証明する
IBCパケットは以下で構成されます:
ヘッダー (IBCPacketHeader) : パケット ヘッダー
Payload ([]byte) : パケット ペイロードのバイト数。オプション
PayloadHash ([]byte) : パケットのバイトを表す hash。
オプション
Payload または PayloadHash のいずれかが存在する必要があります。 hash
IBCPacket の は、ヘッダーという 2 つの項目の単純なマークル ルートです。
および ペイロード 。完全なペイロードを含まないIBCパケットは、
短縮されたパケット。
IBCPacketHeader は次のもので構成されます。
SrcChainID (文字列) : ソース blockchain ID
DstChainID (文字列) : 宛先 blockchain ID
Number (int) : すべてのパケットの一意の番号
Status (enum) : AckPending 、 AckSent 、
AckReceived 、 NoAck 、または Timeout
Type (string) : タイプはアプリケーションに依存します。 Cosmos
「コイン」パケットタイプを予約します
MaxHeight (int) : ステータスが NoAckWanted または AckReceived でない場合
この高さになるとステータスは Timeout になります。オプション
IBCPacketTx トランザクションは次のもので構成されます。FromChainID (文字列) : blockchain の ID
このパケットを提供する。必ずしもソースではない
FromBlockHeight (int) : blockchain の高さ
次のパケットがブロック hash に含まれています (マークル化されています)。
ソースチェーン
パケット (IBCPacket) : データのパケット。ステータスは 1 です。
AckPending 、 AckSent 、 AckReceived 、 NoAck 、または Timeout のいずれか
PacketProof (IAVLProof) : 証明用の IAVLTree Merkle-proof
パケットの hash とソース チェーンの AppHash の照合
与えられた高さ
「Zone1」から「Zone2」へパケットを送信するシーケンス
「ハブ」を介した様子を {図 X} に示します。まず、IBCPacketTx
パケットがアプリ状態に含まれていることを「ハブ」に証明します。
「ゾーン1」。次に、別の IBCPacketTx が「Zone2」に対して、
パケットは「Hub」のアプリ状態に含まれます。この間
この手順では、IBCPacket の出力は同一です。SrcChainID は次のとおりです。
常に「Zone1」、DstChainID は常に「Zone2」です。
PacketProof には、次のように正しいマークルプルーフ パスが必要です。
以下に続きます:
「Zone1」が「Hub」を介して「Zone2」にパケットを送信したい場合、
IBCPacket データは、パケットが「Zone1」、「Hub」、または「Zone2」でマークル化されているかどうかに関係なく同一です。唯一変更可能なyieldは、
配送追跡のステータス。
概念化に協力してくれた友人や同僚に感謝します。
Tendermint との取り組みをレビューし、サポートを提供する
そしてCosmos。
IBC/
SkuChain の Zaki Manian は、フォーマットと 特にABCIセクションの下の文言 アルテアのジェハン・トレンバックとダスティン・バイイントンが協力してくれた 初期反復 Honey Badger の Andrew Miller がコンセンサスについてのフィードバックを寄せてくれました Greg Slepak によるコンセンサスと文言に関するフィードバック また、Bill Gleim 氏と Seunghwan Han 氏、さまざまなご協力に感謝します。 貢献。 あなたの名前と組織をここに投稿してください 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 ゼロキャッシュ: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 隔離された証人: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 ライトニング ネットワーク: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 テンダーミント: https://github.com/tendermint/tendermint/wiki 9 FLP 不可能: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 スラッシャー: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 ビットシェア: https://bitshares.org/technology/delegatedproof-of-stake-consensus/
13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 インターレジャー: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15 サイドチェーン: https://blockstream.com/sidechains.pdf 16 キャスパー: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum シャーディング: https://github.com/ethereum/EIPs/issues/53 19 リブスウィフト: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalysisOfLibswift.pdf 20 DLS: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 シンクライアントのセキュリティ: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 藤色紙: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html
�� えー
الإجماع والتفاصيل الفنية
ينبغي لبروتوكول الإجماع المصمم جيدًا أن يوفر بعضًا من ذلك الضمانات في حالة تجاوز قدرة التسامح ويفشل الإجماع. وهذا ضروري بشكل خاص في المجال الاقتصادي الأنظمة، حيث يمكن أن يكون للسلوك البيزنطي قدر كبير من المال مكافأة. وأهم هذه الضمانات هو شكل من أشكال المساءلة، حيث تتم العمليات التي تسببت في الإجماع الفشل (أي جعل عملاء البروتوكول يقبلون قيمًا مختلفة - أ fork) يمكن تحديد هويته ومعاقبته وفقًا لقواعد البروتوكول، أو ربما النظام القانوني. عندما يكون النظام القانوني يمكن أن يكون استدعاء validators غير موثوق به أو باهظ التكلفة اضطروا إلى تقديم ودائع ضمان من أجل المشاركة، وهؤلاء يمكن إلغاء الودائع أو تخفيضها عند حدوث سلوك ضار تم اكتشاف [10]. لاحظ أن هذا يختلف عن Bitcoin، حيث يكون التفرع حدثًا منتظمًا بسبب عدم تزامن الشبكة والطبيعة الاحتمالية للنهاية الاصطدامات الجزئية hash. نظرًا لأنه في كثير من الحالات يكون هناك شوكة ضارة لا يمكن تمييزه عن الشوكة بسبب عدم التزامن، Bitcoin لا يمكن تنفيذ مسؤولية الشوكة بشكل موثوق، بخلاف الضمنية تكلفة الفرصة البديلة التي يدفعها عمال المناجم لتعدين كتلة معزولة. نحن نطلق على مرحلتي التصويت PreVote وPreCommit. يمكن التصويت ل كتلة معينة أو لا شيء. نحن نطلق على مجموعة من >⅔ الأصوات المسبقة لكتلة واحدة في نفس الجولة رقصة البولكا، ومجموعة من >⅔ الالتزام المسبق لكتلة واحدة في نفس جولة الالتزام. إذا> ⅔ الالتزام المسبق لـ Nil في نفس الجولة، ينتقلون إلى الجولة التالية جولة. لاحظ أن الحتمية الصارمة في البروتوكول تنطوي على ضعف يجب اكتشاف افتراض التزامن كقادة خاطئين
تم تخطيه. ومن ثم، ينتظر validators بعض الوقت، TimeoutPropose، قبل أن يصوتوا على Nil، وقيمة TimeoutPropose يزيد مع كل جولة. التقدم من خلال بقية الجولة غير متزامنة تمامًا، في هذا التقدم فقط يتم إجراؤه بمجرد سماع validator من >⅔ الشبكة. في الممارسة العملية، سوف يتطلب الأمر وجود خصم قوي للغاية لإحباطه إلى أجل غير مسمى افتراض التزامن الضعيف (مما يتسبب في فشل الإجماع من أي وقت مضى ارتكاب كتلة)، والقيام بذلك يمكن أن يتم أكثر من ذلك من الصعب استخدام القيم العشوائية لـ TimeoutPropose في كل منها validator. هناك مجموعة إضافية من القيود، أو قواعد القفل، تضمن أن ستلتزم الشبكة في النهاية بكتلة واحدة فقط عند كل ارتفاع. أي محاولة خبيثة للتسبب في ارتكاب أكثر من كتلة واحدة على ارتفاع معين يمكن تحديدها. أولاً، الالتزام المسبق للكتلة يجب أن يأتي مع مبرر، في شكل رقصة البولكا لتلك الكتلة. إذا كان validator قد قام بالفعل بتنفيذ كتلة في الجولة R_1، فإننا ويقول أنهم مقفلون على تلك الكتلة، ويستخدم رقصة البولكا لتبرير يجب أن يأتي الالتزام المسبق الجديد في الجولة R_2 في جولة R_polka حيث R_1 < R_polka <= R_2. ثانيًا، يجب أن يقترح validators و/أو قم بالتصويت المسبق على الكتلة التي تم قفلها عليها. معا، هؤلاء تضمن الشروط أن validator لا يتم الالتزام المسبق بدونه أدلة كافية لتبرير ذلك، وأن validators التي لديها بالفعل لا يمكن لـ PreCommit المساهمة في الأدلة المقدمة إلى PreCommit شيء آخر. وهذا يضمن سلامة وحيوية الجسم خوارزمية الإجماع. يتم وصف التفاصيل الكاملة للبروتوكول هنا. يتم التخلص من الحاجة إلى مزامنة جميع رؤوس الكتل في TendermintPoS حيث أن وجود سلسلة بديلة (شوكة) يعني ≥⅓ من يمكن خفض الحصة المستعبدة. بالطبع، لأن القطع يتطلب أن يشارك شخص ما دليلاً على الشوكة، يجب على العملاء الخفيفين تخزينها أي كتلة-hash ترتكب ما تراه. بالإضافة إلى العملاء الخفيفينيمكن أن تظل متزامنة بشكل دوري مع التغييرات التي يتم إجراؤها على مجموعة validator، في لتجنب الهجمات بعيدة المدى (ولكن الحلول الأخرى هي ممكن). بروح مشابهة لـ Ethereum، يتيح Tendermint للتطبيقات القيام بذلك قم بتضمين جذر Merkle العالمي hash في كل كتلة، مما يسمح بذلك بسهولة استعلامات حالة يمكن التحقق منها لأشياء مثل أرصدة الحسابات، والقيمة المخزنة في العقد، أو وجود معاملة غير منفقة الإخراج، اعتمادا على طبيعة التطبيق. بافتراض وجود مجموعة مرنة بما فيه الكفاية من شبكات البث ومجموعة validator ثابتة، أي شوكة في blockchain يمكن أن تكون تم اكتشافها وخفض رواسب validators المخالفة. هذا الابتكار، الذي اقترحه فيتاليك بوتيرين لأول مرة في أوائل عام 2014، يحل المشكلة مشكلة عدم وجود شيء على المحك للآخرين proof-of-stake العملات المشفرة (انظر الأعمال ذات الصلة). ومع ذلك، منذ validator مجموعات يجب أن تكون قادرة على تغيير الأصل، على مدى فترة طويلة من الزمن قد يصبح جميع validators غير مقيدين، وبالتالي سيكونون أحرارًا في ذلك إنشاء سلسلة جديدة من كتلة التكوين، دون تحمل أي تكلفة لم يعد لديهم ودائع مقفلة. وجاء هذا الهجوم ليكون المعروف باسم الهجوم بعيد المدى (LRA)، على عكس الهجوم القصير هجوم النطاق، حيث يتسبب validators المرتبطين حاليًا في حدوث أ شوكة ومن ثم يعاقب عليها (بافتراض وجود شوكة مسؤولة BFT خوارزمية مثل إجماع Tendermint). الهجمات بعيدة المدى هي غالبًا ما يُعتقد أنها بمثابة ضربة حاسمة لـ proof-of-stake. ولحسن الحظ، يمكن التخفيف من حدة جيش الرب للمقاومة على النحو التالي. أولا بالنسبة ل validator لإلغاء الارتباط (وبالتالي استرداد وديعة الضمان الخاصة بهم ولم يعد يكسب رسوم المشاركة في الإجماع). يجب أن تكون الوديعة غير قابلة للتحويل لفترة من الوقت المعروفة باسم "فترة التفكيك"، والتي قد تكون في حدود أسابيع أو أشهر. ثانيًا، لكي يكون العميل الخفيف آمنًا، الأول عند اتصاله بالشبكة، يجب عليه التحقق من الحظر الأخير-hash ضد مصدر موثوق به، أو يفضل عدة مصادر. هذا
يُشار إلى الحالة أحيانًا باسم "الذاتية الضعيفة". وأخيرا، لكي يظل آمنًا، يجب أن تتم مزامنته مع أحدث validator المعين في على الأقل بشكل متكرر مثل طول فترة فك الارتباط. هذا يضمن أن العميل الخفيف يعرف التغييرات التي تم إجراؤها على validator تم تعيينه قبل validator وقد تم إلغاء رأس ماله وبالتالي لم يعد كذلك على المحك، مما يسمح لها بخداع العميل بتنفيذها هجوم بعيد المدى عن طريق إنشاء كتل جديدة تبدأ من مرة أخرى الارتفاع حيث تم ربطه (بافتراض أنه يتحكم بشكل كافٍ العديد من المفاتيح الخاصة المبكرة). لاحظ أن التغلب على جيش الرب للمقاومة بهذه الطريقة يتطلب إصلاحًا شاملاً نموذج الأمان الأصلي لـ proof-of-work. في إثبات العمل، هو كذلك من المفترض أن العميل الخفيف يمكنه المزامنة مع الارتفاع الحالي من كتلة التكوين الموثوق بها في أي وقت ببساطة عن طريق معالجة إثبات العمل في كل رأس كتلة. ولكن للتغلب على جيش الرب للمقاومة، علينا تتطلب أن يأتي العميل الخفيف عبر الإنترنت مع بعض الانتظام تتبع التغييرات في مجموعة validator، وذلك في المرة الأولى التي يتم فيها ذلك متصلين بالإنترنت ويجب عليهم أن يكونوا حريصين بشكل خاص على المصادقة ما يسمعونه من الشبكة ضد مصادر موثوقة. من بالطبع، هذا المتطلب الأخير مشابه لمتطلب Bitcoin، حيث ويجب أيضًا الحصول على البروتوكول والبرمجيات من جهة موثوقة المصدر. الطريقة المذكورة أعلاه لمنع جيش الرب للمقاومة مناسبة تمامًا لـ validators والعقد الكاملة لـ blockchain التي تعمل بنظام Tendermint لأن هذه من المفترض أن تظل العقد متصلة بالشبكة. ال الطريقة مناسبة أيضًا للعملاء الخفيفين الذين يمكن توقعهم المزامنة مع الشبكة بشكل متكرر. ومع ذلك، بالنسبة للعملاء الخفيفين ليس من المتوقع أن يكون لديك إمكانية الوصول المتكرر إلى الإنترنت أو blockchain الشبكة، ولكن يمكن استخدام حل آخر للتغلب عليها جيش الرب للمقاومة. يمكن لحاملي غير validator token نشر tokens باسمهم الضمانات ذات فترة فك الارتباط طويلة جدًا (على سبيل المثال، أطول بكثير من فترة إلغاء الارتباط لـ validators) وخدمة العملاء الخفيفين مع طريقة ثانوية لإثبات صحة التيار و الكتلة الماضية-hashes. في حين أن هذه tokens لا يتم احتسابها ضمن أمان إجماع blockchain، ومع ذلك يمكنهم ذلكتقديم ضمانات قوية للعملاء الخفيفين. إذا كانت الكتلة التاريخية-hash تم دعم الاستعلام في Ethereum، ويمكن لأي شخص ربطه tokens في smart contract المصممة خصيصًا وتقديمها خدمات التصديق مقابل الأجر، مما يؤدي بشكل فعال إلى إنشاء سوق لأمن LRA من عملاء Lightclient. نظرًا لتعريف التزام الكتلة، فإن أي ≥⅓ تحالف من يمكن لقوة التصويت أن توقف blockchain بالذهاب إلى الخارج أم لا بث أصواتهم يمكن لمثل هذا التحالف أيضًا فرض الرقابة معاملات معينة عن طريق رفض الكتل التي تتضمن هذه المعاملات المعاملات، على الرغم من أن هذا من شأنه أن يؤدي إلى نسبة كبيرة من مقترحات الكتلة التي سيتم رفضها، الأمر الذي من شأنه أن يبطئ المعدل من عمليات تنفيذ الحظر لـ blockchain، مما يقلل من فائدته وقيمته. قد يقوم التحالف الخبيث أيضًا ببث الأصوات بشكل متقطع كما أن طحن كتلة blockchain تلتزم بالتوقف القريب أو الانخراط أي مزيج من هذه الهجمات. وأخيرا، يمكن أن يسبب blockchain إلى الشوكة، بالتوقيع المزدوج أو انتهاك القفل القواعد. وإذا شارك أيضًا خصم نشط عالميًا، فيمكنه التقسيم الشبكة بطريقة قد تبدو خاطئة كانت مجموعة فرعية من validators مسؤولة عن التباطؤ. هذا ليس كذلك مجرد قيود على Tendermint، بل هي قيود على الجميع بروتوكولات الإجماع التي من المحتمل أن يتم التحكم في شبكتها بواسطة الخصم النشط. بالنسبة لهذه الأنواع من الهجمات، ينبغي لمجموعة فرعية من validators التنسيق من خلال وسائل خارجية للتوقيع على مقترح إعادة التنظيم يختار شوكة (وأي دليل على ذلك) والمجموعة الفرعية الأولية من validators مع توقيعاتهم. يتخلى المصادقون الذين يوقعون على مقترح إعادة التنظيم هذا عن ضماناتهم على جميع الشوكات الأخرى. يجب على العملاء التحقق من التوقيعات على مقترح إعادة التنظيم، والتحقق من أي دليل، وإصدار حكم أو مطالبة المستخدم النهائي باتخاذ قرار. ل على سبيل المثال، قد يطلب تطبيق محفظة الهاتف من المستخدم توفير الأمان
تحذير، في حين أن الثلاجة قد تقبل أي اقتراح لإعادة التنظيم موقعة من +½ من أصل validators بقوة التصويت. لا يمكن أن تأتي خوارزمية بيزنطية غير متزامنة متسامحة مع الأخطاء إلى الإجماع عندما يكون ≥⅓ من قوة التصويت غير شريفة، ومع ذلك فهو شوكة يفترض أن ≥⅓ من قوة التصويت كانت غير شريفة بالفعل التوقيع المزدوج أو تغيير القفل دون مبرر. لذلك، التوقيع إن اقتراح إعادة التنظيم يمثل مشكلة تنسيق لا يمكن حلها يتم حلها بواسطة أي بروتوكول غير متزامن (أي تلقائيًا، و دون وضع افتراضات حول موثوقية الشبكة الأساسية). في الوقت الحالي، نترك مشكلة تنسيق إعادة التنظيم للتنسيق البشري من خلال الإجماع الاجتماعي على وسائل الإعلام عبر الإنترنت. يجب على المصادقين الحرص على التأكد من ذلك لا توجد أقسام شبكة متبقية قبل التوقيع على اقتراح إعادة التنظيم، لتجنب المواقف التي يتم فيها التوقيع على اقتراحين متعارضين لإعادة التنظيم. على افتراض أن وسيلة التنسيق الخارجي والبروتوكول قوية، ويترتب على ذلك أن الشوكات أقل إثارة للقلق من الرقابة الهجمات. بالإضافة إلى الشوكة والرقابة التي تتطلب ≥⅓ البيزنطية قوة التصويت، قد يلتزم ائتلاف من >⅔ قوة التصويت حالة تعسفية وغير صالحة. وهذه هي سمة أي (BFT) نظام الإجماع. على عكس التوقيع المزدوج الذي يخلق الشوكات بأدلة يمكن التحقق منها بسهولة، والكشف عن ارتكاب جريمة ما تتطلب الحالة غير الصالحة أن يقوم أقران لم يتم التحقق من صحتهم بالتحقق من الكتل بأكملها، مما يعني أنهم يحتفظون بنسخة محلية من الدولة وينفذونها كل معاملة، وحساب جذر الدولة بشكل مستقل ل أنفسهم. وبمجرد الكشف عنها، فإن الطريقة الوحيدة للتعامل مع مثل هذا الفشل يتم عن طريق الإجماع الاجتماعي. على سبيل المثال، في المواقف التي يكون فيها Bitcoin قد فشل، سواء كان التفرع بسبب أخطاء برمجية (كما في مارس 2013)، أو ارتكاب حالة باطلة بسبب السلوك البيزنطي عمال المناجم (كما في يوليو 2015)، مجتمع متصل جيدًا بـ الشركات والمطورين وعمال المناجم وغيرها من المنظمات أنشأ إجماعًا اجتماعيًا حول ماهية الإجراءات اليدويةالمطلوبة من قبل المشاركين لشفاء الشبكة. وعلاوة على ذلك، منذ من المتوقع أن يكون validators من النعناع blockchain يمكن تحديدها، بل قد يكون التزام دولة غير صالحة يعاقب عليها القانون أو بعض الاجتهادات القضائية الخارجية، إذا رغبت في ذلك. ABCI يتكون من 3 أنواع رسائل أساسية يتم تسليمها منها جوهر التطبيق. التطبيق يجيب ب رسائل الرد المقابلة. تعتبر رسالة AppendTx بمثابة العمود الفقري للتطبيق. كل يتم تسليم المعاملة في blockchain مع هذه الرسالة. ال يحتاج التطبيق إلى التحقق من صحة كل المعاملات الواردة مع رسالة AppendTx مقابل الحالة الحالية، وبروتوكول التطبيق، وبيانات اعتماد التشفير للمعاملة. تم التحقق من صحتها تحتاج المعاملة بعد ذلك إلى تحديث حالة التطبيق — بواسطة ربط قيمة في مخزن القيم الأساسية، أو عن طريق تحديث UTXO قاعدة البيانات. تشبه رسالة CheckTx رسالة AppendTx، ولكنها مخصصة فقط لـ التحقق من صحة المعاملات. الشيكات الأولى لذاكرة Tendermint Core صلاحية المعاملة مع CheckTx، والمرحلات صالحة فقط المعاملات لأقرانها. قد تحقق التطبيقات زيادة nonce في المعاملة وإرجاع خطأ عند CheckTx إذا كان nonce قديم. يتم استخدام رسالة Commit لحساب التشفير الالتزام بحالة التطبيق الحالية، ليتم وضعها في رأس الكتلة التالي. هذا له بعض الخصائص المفيدة. ستظهر الآن التناقضات في تحديث تلك الحالة blockchain شوكات تلتقط فئة كاملة من البرمجة أخطاء. وهذا أيضًا يبسط عملية تطوير آمنة وخفيفة الوزن العملاء، حيث يمكن التحقق من أدلة Merkle-hash عن طريق التحقق منها الكتلة-hash، والكتلة-hash تم توقيعها بنصاب قانوني validators (حسب قوة التصويت).
تسمح رسائل ABCI الإضافية للتطبيق بتتبعها وقم بتغيير مجموعة validator، ولكي يحصل التطبيق على معلومات الحظر، مثل الارتفاع وأصوات الالتزام. ABCI الطلبات/الردود هي رسائل Protobuf بسيطة. تحقق خارج المخطط. الحجج: البيانات ([]بايت): بايتات معاملة الطلب العوائد: الرمز (uint32): رمز الاستجابة البيانات ([]بايت): بايتات النتيجة، إن وجدت السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:
إلحاق المعاملة وتشغيلها. إذا كانت الصفقة صحيحة ترجع CodeType.OK الحجج: البيانات ([]بايت): بايتات معاملة الطلب العوائد: الرمز (uint32): رمز الاستجابة البيانات ([]بايت): بايتات النتيجة، إن وجدت السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:
التحقق من صحة المعاملة. لا ينبغي أن تتحور هذه الرسالة الدولة. يتم تشغيل المعاملات لأول مرة من خلال CheckTx من قبل البث إلى أقرانهم في طبقة mempool. يمكنك صنع CheckTx شبه حالة ومسح الحالة عند الالتزام أو BeginBlock، للسماح بتسلسلات المعاملات التابعة في نفس الكتلة.
العوائد: البيانات ([]بايت): جذر Merkle hash السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:
قم بإرجاع جذر Merkle hash لحالة التطبيق. الحجج: البيانات ([]بايت): بايتات طلب الاستعلام العوائد: الرمز (uint32): رمز الاستجابة البيانات ([]بايت): بايت استجابة الاستعلام السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:
مسح قائمة انتظار الاستجابة. التطبيقات التي تنفذ أنواع.لا يحتاج التطبيق إلى تنفيذ هذه الرسالة - إنه كذلك يعالجها المشروع. العوائد: البيانات ([]بايت): بايت المعلومات الاستخدام:
إرجاع معلومات حول حالة التطبيق. التطبيق com.speciyc. الحجج: المفتاح (سلسلة): مفتاح للضبط
القيمة (سلسلة): القيمة المطلوب تعيينها للمفتاح العوائد: السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:
ضبط خيارات التطبيق. على سبيل المثال. المفتاح = "الوضع"، القيمة = "mempool" لـ اتصال mempool، أو المفتاح = "الوضع"، القيمة = "الإجماع" لـ اتصال توافقي. الخيارات الأخرى هي تطبيق محدد. الحجج: أدوات التحقق من الصحة ([] أداة التحقق من الصحة): التكوين الأولي-validators الاستخدام:
دعا مرة واحدة في سفر التكوين الحجج: الارتفاع (uint64) : ارتفاع الكتلة الذي يبدأ الاستخدام:
يشير إلى بداية كتلة جديدة. دعا قبل أي إلحاقTxs. الحجج: الارتفاع (uint64) : ارتفاع الكتلة الذي انتهى العوائد: أدوات التحقق ([]أداة التحقق) : تم تغيير validators بأخرى جديدة صلاحيات التصويت (0 لإزالة) الاستخدام:
إشارات نهاية الكتلة. تم الاتصال به قبل كل التزام بعد كل شيء المعاملات راجع مستودع ABCI لمزيد من التفاصيل.هناك عدة أسباب وراء رغبة المرسل في الحصول على إقرار بتسليم الحزمة من خلال سلسلة الاستقبال. على سبيل المثال، قد لا يعرف المرسل حالة الملف سلسلة الوجهة، إذا كان من المتوقع أن تكون معيبة. أو يجوز للمرسل تريد فرض مهلة على الحزمة (باستخدام MaxHeight packet yeld)، في حين أن أي سلسلة وجهة قد تعاني من هجوم رفض الخدمة مع ارتفاع مفاجئ في عدد الرسائل الواردة الحزم. في هذه الحالات، يمكن للمرسل أن يطلب إقرار التسليم من خلال تعيين حالة الحزمة الأولية على AckPending. ثم، هو مسؤولية سلسلة الاستلام عن التسليم عن طريق تضمين يُختصر IBCPacket في تطبيق Merkle hash. أولاً، تم نشر IBCBlockCommit و IBCPacketTx على "Hub" مما يثبت وجود IBCPacket على "Zone1". قل ذلك IBCPacketTx له القيمة التالية: من معرف السلسلة: "المنطقة 1" من بلوك الارتفاع: 100 (على سبيل المثال) الحزمة : IBC الحزمة :
الرأس: IBCرأس الحزمة: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" الرقم: 200 (قل) الحالة: قيد الانتظار النوع: "عملة" MaxHeight : 350 (قل "Hub" حاليًا على ارتفاع 300) الحمولة: <بايتات الحمولة "العملة"> بعد ذلك، يتم نشر IBCBlockCommit و IBCPacketTx على "Zone2" مما يثبت وجود IBCPacket على "Hub". قل ذلك IBCPacketTx له القيمة التالية: FromChainID: "المركز" من ارتفاع الكتلة: 300 الحزمة : IBC الحزمة : الرأس: IBCPacketHeader: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" العدد : 200 الحالة: قيد الانتظار النوع: "عملة" أقصى ارتفاع: 350 الحمولة: <نفس وحدات البايت لحمولة "العملة"> بعد ذلك، يجب أن تتضمن "Zone2" في تطبيقها-hash حزمة مختصرة الذي يوضح الحالة الجديدة لـ AckSent. IBCBlockCommit و IBCPacketTx تم نشرها مرة أخرى على "Hub" مما يثبت وجودها من IBCPacket المختصرة في "Zone2". قل ذلك IBCPacketTx له القيمة التالية: من معرف السلسلة: "المنطقة 2"
من بلوك الارتفاع: 400 (على سبيل المثال) الحزمة : IBC الحزمة : الرأس: IBCرأس الحزمة: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" العدد : 200 الحالة: تم الإرسال النوع: "عملة" أقصى ارتفاع: 350 PayloadHash : <البايتات hash من نفس الحمولة النافعة "للعملة"> وأخيرًا، يجب على "Hub" تحديث حالة الحزمة من "AckPending" إلى "AckReceived". دليل على هذا الوضع الجديد ynalized يجب أن يعود إلى "المنطقة 2". لنفترض أن IBCPacketTx يحتوي على ما يلي القيمة: FromChainID: "المركز" من ارتفاع الكتلة: 301 الحزمة : IBC الحزمة : الرأس: IBCرأس الحزمة: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" العدد : 200 الحالة: تم الاستلام النوع: "عملة" أقصى ارتفاع: 350 PayloadHash : <البايتات hash من نفس الحمولة النافعة "للعملة"> وفي الوقت نفسه، قد تفترض "المنطقة 1" بشكل متفائل التسليم الناجح حزمة "النقود المعدنية" ما لم يثبت خلاف ذلك "المحور". في المثال أعلاه، إذا لم يتلق "Hub" رسالة AckSent
الحالة من "المنطقة 2" بواسطة الكتلة 350، كانت ستحدد الحالة تلقائيًا إلى المهلة. يمكن الحصول على هذا الدليل على المهلة تم نشرها مرة أخرى على "Zone1"، ويمكن إرجاع أي tokens. هناك نوعان من Merkle trees مدعومان في النظام البيئي Tendermint/Cosmos: الشجرة البسيطة وIAVL+ شجرة. الشجرة البسيطة هي Merkle tree لقائمة ثابتة من العناصر. إذا عدد العناصر ليس قوة اثنين، وبعض الأوراق ستكون في مستويات مختلفة. تحاول Simple Tree الحفاظ على جانبي الشجرة نفس الارتفاع، ولكن اليسار قد يكون أكبر من ذلك. هذا Merkle tree هو يستخدم لـ Merkle-ize معاملات الكتلة والمستوى الأعلى عناصر جذر حالة التطبيق.الغرض من بنية بيانات IAVL+ هو توفير الدعم المستمر تخزين أزواج القيمة الرئيسية في حالة التطبيق بحيث يكون أ يمكن حساب جذر Merkle الحتمي hash بكفاءة. ال تتم موازنة الشجرة باستخدام البديل من خوارزمية AVL، وجميع العمليات هي O(log(n)). في شجرة AVL، ارتفاعات الشجرتين الفرعيتين لأي عقدة تختلف بواحدة على الأكثر. كلما تم انتهاك هذا الشرط على التحديث، يتم إعادة توازن الشجرة عن طريق إنشاء العقد الجديدة O(log(n)) التي أشر إلى العقد غير المعدلة من الشجرة القديمة. في AVL الأصلي الخوارزمية، يمكن للعقد الداخلية أيضًا الاحتفاظ بأزواج القيمة الرئيسية. ايه في ال+ الخوارزمية (لاحظ الزائد) تقوم بتعديل خوارزمية AVL للاحتفاظ بكل شيء القيم على العقد الطرفية، مع استخدام العقد الفرعية فقط لتخزين المفاتيح. يؤدي هذا إلى تبسيط الخوارزمية مع الحفاظ على مسار Merkle hash قصيرة. تشبه شجرة AVL+ محاولات باتريشيا Ethereum. هناك المقايضات. لا يلزم أن تكون المفاتيح hashed قبل إدراجها أشجار IAVL+، مما يوفر تكرارًا مرتبًا بشكل أسرع في المفتاح المساحة التي قد تفيد بعض التطبيقات. المنطق هو أبسط ل تنفيذ، يتطلب نوعين فقط من العقد - العقد الداخلية و العقد الورقية. إن برهان ميركل أقصر في المتوسط، كونه أ * / \ / \ / \ / \ * * / \ / \ / \ / \ / \ / \ * * * h6 / \ / \ / \ h0 h1 h2 h3 h4 h5 شجرة بسيطة تحتوي على 7 عناصر
شجرة ثنائية متوازنة من ناحية أخرى، جذر ميركل ل تعتمد شجرة IAVL+ على ترتيب التحديثات. سوف ندعم المزيد من Merkle trees، مثل Ethereum باتريشيا تري عندما يصبح المتغير الثنائي متاح. في التنفيذ الأساسي، يتم تدفق المعاملات إلى Cosmos تطبيق المحور عبر واجهة ABCI. سيقبل Cosmos Hub عددًا من المعاملات الأساسية الأنواع، بما في ذلك SendTx ، BondTx ، UnbondTx ، ReportHackTx ، SlashTx، وBurnAtomTx، وProposalCreateTx، وProposalVoteTx، والتي لا تحتاج إلى شرح إلى حد ما وسيتم توثيقها في ملف المراجعة المستقبلية لهذه الورقة. هنا نقوم بتوثيق الأمرين الأساسيين أنواع المعاملات لـ IBC: IBCBlockCommitTx و IBCPacketTx . تتكون معاملة IBCBlockCommitTx من: ChainID (سلسلة): معرف blockchain BlockHash ([]بايت): الكتلة-hash بايت، جذر Merkle والذي يتضمن التطبيق-hash BlockPartsHeader (PartSetHeader): رأس مجموعة أجزاء الكتلة البايتات، مطلوبة فقط للتحقق من توقيعات التصويت BlockHeight (int) : ارتفاع الالتزام BlockRound (int): جولة الالتزام الالتزام ([]تصويت) : يصوت >⅔ Tendermint Precommit على ذلك تتضمن التزامًا بالكتلة ValidatorsHash ([]بايت): جذر شجرة ميركل hash للجديد validator مجموعة
ValidatorsHashProof (SimpleProof): SimpleTree Merkleproof لإثبات ValidatorsHash مقابل BlockHash
AppHash ([]بايت): جذر شجرة IAVLTree Merkle hash لـ
حالة التطبيق
AppHashProof (SimpleProof): أداة SimpleTree Merkle-proof لـ
إثبات AppHash مقابل BlockHash
تتكون الحزمة IBCPacket من:
Header (IBCPacketHeader): رأس الحزمة
الحمولة ([]بايت): بايتات حمولة الحزمة. اختياري
PayloadHash ([]بايت): hash لبايتات الحزمة.
اختياري
يجب أن يكون أي من Payload أو PayloadHash موجودًا. hash
IBCPacket هو جذر Merkle البسيط للعنصرين، الرأس
و الحمولة. يُطلق على IBCPacket بدون الحمولة الكاملة اسم
الحزمة المختصرة.
يتكون IBCPacketHeader من:
SrcChainID (سلسلة): معرف المصدر blockchain
DstChainID (سلسلة): معرف الوجهة blockchain
الرقم (int) : رقم فريد لجميع الحزم
الحالة (التعداد): يمكن أن تكون واحدة من AckPending أو AckSent أو
AckReceived أو NoAck أو Timeout
النوع (سلسلة): تعتمد الأنواع على التطبيق. Cosmos
يحتفظ بنوع الحزمة "العملة المعدنية".
MaxHeight (int) : إذا كانت الحالة ليست NoAckWanted أو AckReceived
وبهذا الارتفاع، تصبح الحالة Timeout . اختياري
تتكون معاملة IBCPacketTx من:FromChainID (سلسلة): معرف blockchain وهو
توفير هذه الحزمة؛ ليس بالضرورة المصدر
FromBlockHeight (int) : الارتفاع blockchain الذي يوجد فيه
تم تضمين الحزمة التالية (بحجم Merkle) في الكتلة-hash من
سلسلة المصدر
الحزمة (IBCPacket): حزمة من البيانات، قد تكون حالتها واحدة
AckPending أو AckSent أو AckReceived أو NoAck أو Timeout
PacketProof (IAVLProof): IAVLTree Merkle-proof للإثبات
الحزمة hash مقابل AppHash لسلسلة المصدر في
ارتفاع معين
تسلسل إرسال الحزمة من "Zone1" إلى "Zone2"
من خلال "المحور" كما هو موضح في {الشكل X}. أولاً، IBCPacketTx
يثبت لـ "Hub" أن الحزمة مضمنة في حالة التطبيق
"المنطقة 1". بعد ذلك، يثبت IBCPacketTx آخر لـ "Zone2" أن
يتم تضمين الحزمة في حالة التطبيق "Hub". خلال هذا
الإجراء، تكون حقول IBCPacket متطابقة: SrcChainID هو
دائمًا "Zone1"، ويكون DstChainID دائمًا "Zone2".
يجب أن يشتمل PacketProof على المسار الصحيح لـ Merkle-proof، مثل
يلي:
عندما يريد "Zone1" إرسال حزمة إلى "Zone2" من خلال "Hub"،
تكون بيانات IBCPacket متطابقة سواء كانت الحزمة Merkleized على "Zone1" أو "Hub" أو "Zone2". الحقل الوحيد القابل للتغيير هو
الحالة لتتبع التسليم.
ونشكر أصدقائنا وزملائنا الذين ساعدونا في وضع المفهوم،
مراجعة وتقديم الدعم لعملنا مع Tendermint
و Cosmos.
IBC/
قدم زكي مانيان من SkuChain الكثير من المساعدة في التنسيق والتنسيق الصياغة، خاصة ضمن القسم ABCI جيهان تريمباك من ألثيا وداستن بينجتون للمساعدة التكرارات الأولية أندرو ميلر من Honey Badger للحصول على تعليقات حول الإجماع جريج سليباك للحصول على تعليقات بشأن الإجماع والصياغة شكرًا أيضًا لبيل جليم وسيونغهوان هان على جهودهما المتنوعة المساهمات. اسمك ومنظمتك هنا لمساهمتك 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 زيرو كاش: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4 DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 الشاهد المنفصل: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 شبكة البرق: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 النعناع: https://github.com/tendermint/tendermint/wiki 9 استحالة FLP: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 المشرح: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 فBFT: 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 nceAnalysOfLibswift.pdf 20 دي إل إس: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 أمان العميل الرقيق: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 ورق بنفسجي: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html
Ó ه