Stellar コンセンサスプロトコル
خلاصة
المدفوعات الدولية بطيئة ومكلفة، ويرجع ذلك جزئيًا إلى توجيه الدفع متعدد القفزات عبر طرق غير متجانسة الأنظمة المصرفية. Stellar هي شبكة دفع عالمية جديدة التي يمكنها تحويل الأموال الرقمية مباشرة إلى أي مكان في العالم العالم في ثواني. الابتكار الرئيسي هو معاملة آمنة آلية عبر وسطاء غير موثوق بهم، وذلك باستخدام جديد بروتوكول الاتفاقية البيزنطية يسمى SCP. مع SCP، لكل منهما تحدد المؤسسة المؤسسات الأخرى التي ستبقى معها في الاتفاق؛ من خلال الترابط العالمي النظام المالي، ثم توافق الشبكة بأكملها على الذرية المعاملات التي تشمل مؤسسات تعسفية، مع عدم وجود مخاطر الملاءة المالية أو سعر الصرف من مصدري الأصول الوسطاء أو صناع السوق. نقدم نموذج SCP وبروتوكوله و التحقق الرسمي؛ وصف شبكة الدفع Stellar؛ وأخيرًا قم بتقييم Stellar تجريبيًا من خلال المعايير وخبرتنا مع عدة سنوات من استخدام الإنتاج. مفاهيم CCS • الأمن والخصوصية →الموزعة أمن الأنظمة؛ • تنظيم أنظمة الكمبيوتر → أبنية نظير إلى نظير؛ • نظم المعلومات → تحويل الأموال إلكترونيا. الكلمات الرئيسية blockchain, BFT, النصاب القانوني, الدفعات التنسيق المرجعي ACM: مارتا لوخافا، جوليانو لوسا، ديفيد مازيير، جرايدون هور، نيكولا باري، إيلي جافني، جوناثان جوف، رافائيل مالينوفسكي، جيد مكالب. 2019. مدفوعات عالمية سريعة وآمنة باستخدام Stellar. في SOSP ’19: ندوة حول مبادئ أنظمة التشغيل، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا. ACM، نيويورك، نيويورك، الولايات المتحدة الأمريكية، 17 صفحة. https://doi.org/10.1145/3341301.3359636
概要
国際決済は遅くて高価ですが、その理由の 1 つは、異種混合を介したマルチホップ決済ルーティングです。 銀行システム。 Stellar は新しいグローバル決済ネットワークです どこにでもデジタルマネーを直接送金できる 秒単位の世界。重要なイノベーションは安全なトランザクションです 新しいメカニズムを使用した、信頼できない仲介者間のメカニズム SCPと呼ばれるビザンチン協定プロトコル。 SCPでは、それぞれ 機関は、所属する他の機関を指定します 同意します。のグローバルな相互接続を通じて、 金融システムでは、ネットワーク全体がアトミックに同意します。 任意の機関にまたがる取引で、仲介資産発行会社による支払い能力や為替リスクがありません またはマーケットメーカー。 SCP のモデル、プロトコル、および 正式な検証。 Stellar 支払いネットワークについて説明します。 そして最後にベンチマークを通じて Stellar を経験的に評価します そして数年間の実稼働環境での使用経験。 CCS の概念 • セキュリティとプライバシー →分散 システムのセキュリティ。 • コンピュータシステムの組織 → ピアツーピアアーキテクチャ。・情報システム → 電子送金。 キーワード blockchain、BFT、定足数、支払い ACM 参照形式: マルタ・ロカバ、ジュリアーノ・ロサ、デビッド・マジエール、グレイドン・ホア、 ニコラス・バリー、イーライ・ガフニ、ジョナサン・ジョーブ、ラファウ・マリノフスキー、ジェド・マッケイレブ。 2019. Stellar による高速かつ安全なグローバル支払い。 SOSPで ’19: オペレーティング システム原則に関するシンポジウム、10 月 27 ～ 30 日 2019年、カナダ、オンタリオ州ハンツビル。 ACM、米国ニューヨーク州ニューヨーク、17 ページ。 https://doi.org/10.1145/3341301.3359636
مقدمة
من المعروف أن المدفوعات الدولية بطيئة ومكلفة [32]. خذ بعين الاعتبار عدم جدوى إرسال 0.50 دولار من الولايات المتحدة إلى * شركة جالوا †جامعة كاليفورنيا الإذن بعمل نسخ رقمية أو ورقية من كل هذا العمل أو جزء منه يُمنح الاستخدام الشخصي أو الاستخدام في الفصل الدراسي بدون رسوم بشرط عدم وجود نسخ صنعت أو وزعت لتحقيق الربح أو الميزة التجارية وتحمل تلك النسخ هذا الإشعار والاقتباس الكامل في الصفحة الأولى. حقوق الطبع والنشر للمكونات يجب تكريم هذا العمل المملوك لآخرين غير ACM. التجريد مع الائتمان مسموح به. النسخ بخلاف ذلك، أو إعادة النشر، للنشر على الخوادم أو إلى إعادة التوزيع على القوائم يتطلب الحصول على إذن محدد مسبق و/أو دفع رسوم. طلب الأذونات من [email protected]. SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا © 2019 جمعية آلات الحوسبة. ACM ISBN 978-1-4503-6873-5/19/10...$15.00 https://doi.org/10.1145/3341301.3359636 المكسيك دولتان متجاورتان. يدفع المستخدمون النهائيون ما يقرب من 9 دولارات لمتوسط هذا النقل [32]، واتفاق ثنائي ولم يكن من الممكن إلا أن تخفض الديون التي توسطت فيها البنوك المركزية في البلدان تبلغ تكلفة البنك الأساسي 0.67 دولارًا أمريكيًا لكل عنصر [2]. على رأس الرسوم، يتم احتساب زمن الوصول للمدفوعات الدولية بشكل عام في أيام، مما يجعل من المستحيل الحصول على الأموال في الخارج بسرعة حالات الطوارئ. في البلدان التي لا يوجد بها نظام مصرفي العمل أو لا يخدم جميع المواطنين، أو عندما تكون الرسوم غير محتملة، يلجأ الناس إلى إرسال المدفوعات بالحافلة [38]، عن طريق القارب [19]، وأحيانًا الآن بواسطة Bitcoin [55]، وكلها تحمل المخاطر أو الكمون أو الإزعاج. على الرغم من أنه ستكون هناك دائمًا تكاليف امتثال، تشير الأدلة إلى ضياع مبلغ كبير بسبب انعدام المنافسة [21]، والتي تتفاقم بسبب التكنولوجيا غير الفعالة. حيث الناس يمكن أن يبتكر، وتنخفض الأسعار وفترات التأخير. على سبيل المثال، بلغت تكلفة التحويلات من الحسابات المصرفية في الربع الثاني من عام 2019 ما متوسطه 6.99%، بينما بلغت نسبة تحويل الأموال عبر الهاتف المحمول 4.88% فقط [13]. شبكة دفع عالمية مفتوحة تجذب الابتكار ومن الممكن أن تؤدي المنافسة من جانب الكيانات غير المصرفية إلى الانخفاض التكاليف وزمن الوصول في جميع الطبقات، بما في ذلك الامتثال [83]. تعرض هذه الورقة Stellar، دفعة مستندة إلى blockchain شبكة مصممة خصيصًا لتسهيل الابتكار و المنافسة في المدفوعات الدولية. Stellar هو الأول نظام لتحقيق الأهداف الثلاثة التالية (تحت أ "فرضية الإنترنت" جديدة ولكنها صالحة تجريبيًا): 1. العضوية المفتوحة – يمكن لأي شخص إصدار عملة مدعومة tokens الرقمية التي يمكن تبادلها بين المستخدمين. 2. النهاية التي يفرضها المُصدر - يمكن لجهة إصدار token أن تمنع المعاملات في token من التراجع أو التراجع. 3. الذرية عبر المُصدر – يمكن للمستخدمين التبادل ذريًا وتداول tokens من جهات إصدار متعددة. إن تحقيق الأولين أمر سهل. يمكن لأي شركة أن تقدم من جانب واحد منتجًا مثل Paypal وVenmo وWeChat الدفع، أو Alipay والتأكد من نهائية المدفوعات في العملات الافتراضية التي قاموا بإنشائها. ولسوء الحظ، فإن التعامل ذريًا عبر هذه العملات أمر مستحيل. في الواقع، على الرغم من استحواذ Paypal على الشركة الأم لشركة Venmo في عام 2013، لا يزال من المستحيل على المستخدمين النهائيين إرسال Venmo دولار لمستخدمي Paypal [78]. في الآونة الأخيرة فقط يمكن للتجار حتى قبول كلاهما بتكامل واحد. يمكن تحقيق الهدفين 2 و 3 في نظام مغلق. وعلى وجه الخصوص، يتمتع عدد من البلدان بمدفوعات محلية تتسم بالكفاءة الشبكات، التي تشرف عليها عادةً هيئة تنظيمية موثوقة عالميًا. ومع ذلك، تقتصر العضوية على مغلقة مجموعة من البنوك المعتمدة والشبكات تقتصر على مدى وصول السلطة التنظيمية في البلاد.SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. تم تحقيق الهدفين 1 و3 في blockchains، وعلى الأخص في شكل ERC20 tokens على Ethereum [3]. الفكرة الرئيسية لهذه blockchain هي إنشاء عملة مشفرة جديدة يمكن من خلالها مكافأة الأشخاص على تسوية الأمر المعاملات من الصعب العودة. لسوء الحظ، هذا يعني أن جهات إصدار token لا تتحكم في نهائية المعاملة. إذا البرمجيات تتسبب الأخطاء في إعادة تنظيم سجل المعاملات [26، 73]، أو عندما تكون غنائم الغشاشين أكثر من تكلفة إعادة تنظيم التاريخ [74، 97]، قد يكون المصدرون مسؤولين عن tokens لقد قاموا بالفعل باستبدال أموال العالم الحقيقي. يحتوي Stellar blockchain على خاصيتين مميزتين. أولاً، يدعم أصلاً الأسواق الفعالة بين tokens من مصدرين مختلفين. على وجه التحديد، يمكن لأي شخص إصدار token، يوفر blockchain سجل طلبات مدمجًا للتداول بين أي زوج من token، ويمكن للمستخدمين إصدار دفعات المسار التي تتداول ذريًا عبر عدة أزواج عملات بينما ضمان سعر الحد الشامل. ثانيًا، يقدم Stellar اتفاقية بيزنطية جديدة البروتوكول SCP (Stellar بروتوكول الإجماع) والذي من خلاله يقوم مصدرو token بتعيين خوادم validator محددة للتنفيذ نهائية المعاملة. طالما لم يقم أحد بالمساس بـ validators الخاصة بجهة الإصدار (والتوقيعات الرقمية الأساسية و التشفير hashes آمن)، يعرف المصدر بالضبط المعاملات التي حدثت ويتجنب المخاطر من الخسائر الناجمة عن blockchain إعادة تنظيم التاريخ. الفكرة الرئيسية لشركة SCP هي أن معظم مصدري الأصول يستفيدون منها الأسواق السائلة وتريد تسهيل المعاملات الذرية مع الأصول الأخرى. ومن ثم، يتم تكوين مسؤولي validator خوادمهم للاتفاق مع validators الأخرى على وجه التحديد تاريخ جميع المعاملات على جميع الأصول. يمكن أن يكون validator v1 يمكن تكوينه للموافقة على الإصدار 2، أو يمكن تكوين الإصدار 2 للموافقة مع الإصدار 1، أو قد يتم تكوين كليهما للاتفاق مع بعضهما البعض؛ وفي جميع الحالات، لن يلتزم أي منهما بسجل المعاملات حتى إنها تعلم أن الآخر لا يمكنه الالتزام بتاريخ مختلف. بواسطة العبور، إذا كان v1 لا يمكن أن يختلف مع v2 وv2 لا يمكن أن يختلف مع v3 (أو العكس)، فإن v1 لا يمكن أن يختلف مع v3 v3، سواء كان v3 يمثل الأصول التي سمعها v1 أم لا من. في ظل فرضية أن هذه العلاقات اتفاق ربط الشبكة بالكامل بشكل عابر، يضمن SCP اتفاقية عالمية، مما جعلها اتفاقية بيزنطية عالمية بروتوكول ذو عضوية مفتوحة. نحن نطلق على افتراض الترابط الجديد هذا اسم فرضية الإنترنت، ونلاحظ ذلك يحمل كلا من "الإنترنت" (الذي يفهمه الجميع يعني أكبر شبكة IP متصلة بشكل عابر) والمدفوعات الدولية القديمة (التي تتم على أساس خطوة تلو الأخرى غير ذرية، ولكنها تستفيد من عالمية متصلة بشكل عابر شبكة المؤسسات المالية). Stellar قيد الاستخدام الإنتاجي منذ سبتمبر 2015. للحفاظ على طول blockchain قابلاً للإدارة، يتم تشغيل النظام SCP على فترات زمنية مدتها 5 ثوانٍ — بسرعة وفقًا لمعايير blockchain، ولكن أبطأ بكثير من التطبيقات النموذجية للاتفاقية البيزنطية. على الرغم من أن الاستخدام الأساسي كان عبارة عن مدفوعات، إلا أن Stellar كان كذلك أيضًا أثبتت جاذبيتها للأشياء القابلة للاستبدال غير المالية token والتي تستفيد منها من الأسواق الثانوية المباشرة (انظر القسم 7.1). ويناقش القسم التالي الأعمال ذات الصلة. يعرض القسم 3 SCP. يصف القسم 4 التحقق الرسمي من SCP. يصف القسم 5 طبقة الدفع الخاصة بـ Stellar. ويتعلق القسم 6 بعض خبراتنا في النشر والدروس المستفادة. القسم 7 يقيم النظام. وينتهي القسم 8.
導入
国際支払いは遅くて費用がかかることで有名です[32]。 米国から0.50ドルを送金することが非現実的であることを考えてみましょう。 ※株式会社ガロア †カリフォルニア大学ロサンゼルス校 この作品の全部または一部のデジタルコピーまたはハードコピーを作成する許可 個人または教室での使用は、コピーが行われない限り、無料で許可されます。 営利または商業的利益を目的として作成または配布され、そのコピーには この通知と最初のページの引用全文。コンポーネントの著作権 ACM 以外の者が所有するこの作品は尊重されなければなりません。で抽象化する クレジットは許可されています。別の方法でコピーしたり再公開したり、サーバーに投稿したり、 リストに再配布するには、事前の特定の許可および/または料金が必要です。リクエスト 許可は、[email protected] から取得します。 SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル © 2019 コンピューティング機械協会。 ACM ISBN 978-1-4503-6873-5/19/10...$15.00 https://doi.org/10.1145/3341301.3359636 メキシコ、隣り合う2つの国。エンドユーザーは 9 ドル近くを支払います 平均的な転送[32]と二国間協定の場合 各国の中央銀行が仲介するのは、削減することしかできない 基本的な銀行コストはアイテム [2] あたり 0.67 ドルになります。手数料に加えて、 通常、国際決済の遅延は考慮されます 数日かかるため、すぐに海外でお金を得ることができなくなります 緊急事態。銀行システムが整備されていない国では 仕事をしていないか、すべての国民にサービスを提供していない場合、または手数料が耐えられない場合、人々はバス [38] による支払いに頼ることになります。 ボート [19]、そして時々 Bitcoin [55] によって、すべて リスク、遅延、または不便が生じる可能性があります。 コンプライアンスコストは常に発生しますが、競争の欠如により多額の損失が発生することを示す証拠 [21]、 これは非効率なテクノロジーによってさらに悪化します。人がいる場所 イノベーションが可能になり、価格とレイテンシが下がります。たとえば、2019 年第 2 四半期の銀行口座からの送金には平均で次の費用がかかりました。 6.99% であるのに対し、モバイル マネーの数字は 4.88% [13] にすぎませんでした。 イノベーションを呼び込むオープンでグローバルな決済ネットワーク 銀行以外の組織との競争が激化する可能性がある コンプライアンス [83] を含む、すべてのレイヤーでのコストとレイテンシ。 このペーパーでは、Stellar、blockchain ベースの支払いについて説明します。 イノベーションを促進するために特別に設計されたネットワーク 国際決済における競争。 Stellar が最初です 以下の 3 つの目標をすべて満たすシステム ( 新規だが経験的に有効な「インターネット仮説」): 1. オープンメンバーシップ – 誰でも通貨を裏付けとした発行が可能 ユーザー間で交換できるデジタル token。 2. 発行者による強制的なファイナリティ – token の発行者は、これを防ぐことができます token のトランザクションが取り消されたり取り消されたりすることを防ぎます。 3. 発行者間のアトミック性 – ユーザーはアトミックに交換できる 複数の発行者からの token を取引します。 最初の 2 つを達成するのは簡単です。 Paypal、Venmo、WeChat などの製品をどの企業も一方的に提供できる Pay または Alipay を使用して、支払いの最終性を確保します。 彼らが作った仮想通貨。残念ながら、これらの通貨間でアトミックに取引することは不可能です。実際、 PaypalがVenmoの親会社を買収したにもかかわらず 2013 年になっても、エンドユーザーが Venmo を送信することはまだ不可能です Paypal ユーザー [78] にドル。販売者ができるようになったのは最近になってからです 単一の統合で両方を受け入れることもできます。 目標 2 と 3 はクローズド システムで達成できます。特に、多くの国では効率的な国内決済が行われています。 ネットワークは、通常、広く信頼されている規制当局によって監督されています。ただし会員資格は非公開に限ります 一連のチャータード銀行とネットワークは以下に限定されます。 国の規制当局の管轄範囲。SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル ロカバら。 目標 1 と 3 はマイニングされた blockchain で達成されました。 最も顕著なのは、Ethereum [3] 上の ERC20 token の形式です。 これらのblockchainの重要なアイデアは、定住した人々に報酬を与える新しい暗号通貨を作成することです。 トランザクションを元に戻すのは困難です。残念ながら、これは、token 発行者がトランザクションのファイナリティを制御していないことを意味します。ソフトウェアの場合 エラーによりトランザクション履歴が再編成される [26、73]、 あるいは、人をだまして得た戦利品がその費用を超えたとき。 歴史の再編成 [74、97]、発行者はtokens について責任を負う可能性がある 彼らはすでに現実世界のお金と引き換えています。 Stellar blockchain には 2 つの特徴的なプロパティがあります。 まず、token 間の効率的な市場をネイティブにサポートします。 さまざまな発行者からのもの。具体的には、誰でもtokenを発行できます。 blockchain は、token の任意のペア間の取引用の組み込みオーダーブックを提供し、ユーザーはパス支払いを発行できます 複数の通貨ペアにわたってアトミックに取引されますが、 エンドツーエンドの制限価格を保証します。 第二に、Stellar は新しいビザンチン協定を導入します プロトコル、SCP (Stellar コンセンサス プロトコル)、これを介して token 発行者は、強制する特定の validator サーバーを指定します トランザクションのファイナリティ。誰も発行者のvalidator（および基礎となるデジタル署名と 暗号 hashes は安全なままです)、発行者はどのトランザクションが発生したかを正確に把握し、リスクを回避します blockchain 履歴の再編成による損失の増加。 SCP の重要な考え方は、ほとんどの資産発行者が次のような恩恵を受けるということです。 流動性の高い市場であり、アトミックな取引を促進したいと考えています 他の資産と一緒に。したがって、validator 管理者は次のように設定します。 サーバーが他の validator と正確に一致するようにします。 すべての資産に対するすべてのトランザクションの履歴。 validator v1 は次のようになります。 v2 と一致するように構成されているか、v2 が一致するように構成できます v1 と、または両方が相互に一致するように構成できます。 どのような場合でも、どちらもトランザクション履歴にコミットすることはありません。 それは、相手が異なる歴史にコミットできないことを知っています。 推移性により、v1 が v2 に同意できず、v2 が v3 に同意できない場合 (またはその逆)、v1 は v3 に同意できません。 v3、v3 が v1 が聞いたアセットを表すかどうか の。これらの合意関係が仮定されると、 ネットワーク全体を推移的に接続することを SCP が保証します 世界的な協定となり、世界的なビザンチン協定となる オープンなメンバーシップを持つプロトコル。私たちはこの新しい接続性の仮定をインターネット仮説と呼びます。 「インターネット」（誰もがそう理解している）の両方が保持されます。 推移的に接続された単一最大の IP ネットワークを意味します) 従来の国際決済（ホップバイホップ） 非アトミックですが、推移的に接続されたグローバルなネットワークを活用します。 金融機関のネットワーク）。 Stellar は、2015 年 9 月から本番環境で使用されています。 blockchain の長さを管理しやすい状態に保つために、システムは 5 秒間隔の SCP - blockchain 標準では高速ですが、 ビザンチン協定の典型的な適用よりもはるかに遅い。 主な用途は支払いですが、Stellar はまた、 利益をもたらす非金銭代替可能tokenにとって魅力的であることが証明されている 即時流通市場からの取引（セクション 7.1 を参照）。 次のセクションでは、関連する作業について説明します。セクション 3 の紹介 SCP。セクション 4 では、SCP の正式な検証について説明します。セクション 5 では、Stellar の支払いレイヤーについて説明します。セクション 6 に関連する 導入の経験と学んだ教訓の一部。 セクション 7 ではシステムを評価します。セクション 8 は終了です。
Stellar بروتوكول الإجماع
يعتمد بروتوكول الإجماع Stellar (SCP) على النصاب القانوني بروتوكول الاتفاقية البيزنطية ذو العضوية المفتوحة. تنشأ النصاب القانوني من قرارات التكوين المحلي المجمعة للعقد الفردية. ومع ذلك، العقد تعترف فقط النصاب الذي ينتمون إليه أنفسهم، وبعد ذلك فقط التعرف على التكوينات المحلية لجميع أعضاء النصاب القانوني الآخرين. إحدى فوائد هذا النهج هو أن SCP بطبيعته يتسامح مع وجهات النظر غير المتجانسة حول ما هي العقد الموجودة. وبالتالي، يمكن للعقد الانضمام والمغادرة من جانب واحد دون الحاجة إلى بروتوكول "عرض التغيير" لتنسيق العضوية. 3.1 الاتفاقية البيزنطية الفيدرالية تتكون مشكلة الاتفاقية البيزنطية التقليدية من أ نظام مغلق من العقد N، وبعضها معيب وربما التصرف بشكل تعسفي. تتلقى العقد قيم الإدخال والتبادل الرسائل لتحديد قيمة الإخراج بين المدخلات. يكون بروتوكول الاتفاقية البيزنطية آمنًا عندما لا تنتج عقدتان جيدتا التصرف قرارات مختلفة وفريدة من نوعها كان القرار مدخلاً صالحًا (بالنسبة لبعض التعريفات الصالحة المتفق عليهاSOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. عليه مسبقًا). يكون البروتوكول حيًا عندما يضمن ذلك كل عقدة صادقة تنتج في النهاية قرارًا. عادةً، تفترض البروتوكولات N = 3f + 1 لبعض الأعداد الصحيحة f > 0، ثم ضمان السلامة وشكل من أشكال الحيوية طالما أن معظم العقد f معيبة. في مرحلة ما في هذه البروتوكولات، والعقد تصوت على القيم المقترحة والاقتراح الحصول على 2f + 1 صوت، وهو ما يسمى نصاب الأصوات، يصبح القرار. مع N = 3f + 1 العقد، أي نصابين من يتداخل الحجم 2f + 1 في العقد f + 1 على الأقل؛ حتى لو و من هذه العقد المتداخلة معيبة، ويشترك النصابان على الأقل عقدة واحدة غير معيبة، مما يمنع اتخاذ قرارات متناقضة. ومع ذلك، فإن هذا النهج لا يعمل إلا إذا اتفقت جميع العقد ما يشكل النصاب القانوني، وهو أمر مستحيل في SCP حيث قد لا تعرف العقدتان وجود بعضهما البعض. مع SCP، كل عقدة v تعلن من جانب واحد عن مجموعات من العقد، تسمى شرائح النصاب القانوني، بحيث (أ) v يعتقد أنه إذا كان كل شيء إذن، يتفق أعضاء الشريحة على حالة النظام إنهم على حق، و(ب) v يعتقد أن شريحة واحدة على الأقل من شرائحه سيكون متاحًا لتقديم المعلومات في الوقت المناسب حول حالة النظام. نحن نسمي النظام الناتج، يتكون العقد وشرائحها، اتفاقية بيزنطية موحدة نظام (FBA). وكما سنرى بعد ذلك، يظهر نظام النصاب القانوني من شرائح العقد. بشكل غير رسمي، تعبر شرائح عقدة FBA عن من معه العقدة تتطلب الاتفاق. على سبيل المثال، قد تتطلب العقدة اتفاقًا مع 4 مؤسسات محددة، تدير كل منها 3 عقد؛ ل لاستيعاب وقت التوقف عن العمل، فقد يقوم بتعيين شرائحه لتكون جميع المجموعات تتكون من عقدتين من كل منظمة. إذا كان هذا "يتطلب الاتفاق مع "العلاقة ترتبط بشكل متعدٍ بأي عقدتين، نحصل على اتفاق عالمي. وإلا فإننا قد نحصل على الاختلاف، ولكن فقط بين المنظمات لا يتطلب أي منهما الاتفاق مع الآخر. بالنظر إلى طوبولوجيا اليوم في النظام المالي، فإننا نفترض أن التقارب واسع النطاق سوف يستمر في إنتاج سجل تاريخي واحد يسميه الناس "شبكة Stellar"، بقدر ما نتحدث عن الإنترنت. النصاب القانوني ينشأ من الشرائح على النحو التالي. تحدد كل عقدة شرائح النصاب القانوني في كل رسالة يرسلها. دع S يكون مجموعة العقد التي نشأت منها مجموعة من الرسائل. أ تعتبر العقدة أن مجموعة الرسائل قد وصلت إلى النصاب القانوني العتبة عندما يكون لدى كل عضو في S شريحة مضمنة في S. من خلال البناء، فإن مثل هذه المجموعة S، إذا تم الإجماع عليها، تلبي متطلبات الاتفاق لكل عضو من أعضائها. قد يعلن النظير المعيب عن شرائح تم تصميمها لتغيير ما العقد حسنة التصرف تأخذ في الاعتبار النصاب القانوني. من أجل تحليل البروتوكول، حددنا النصاب القانوني في FBA ليكون غير فارغ مجموعة S من العقد تشمل شريحة نصاب واحدة على الأقل كل عضو غير معيب. وهذا التجريد سليم، كأي مجموعة من الرسائل التي يزعم أنها تمثل النصاب القانوني بالإجماع في الواقع (حتى لو كان يحتوي على رسائل من عقد معيبة)، ويكون دقيقًا عندما يحتوي S على العقد جيدة التصرف فقط. في في هذا القسم، نفترض أيضًا أن شرائح العقد لا تتغير. ومع ذلك، فإن نتائجنا تنتقل إلى حالة الشريحة المتغيرة لأن النظام الذي يتم فيه تغيير الشرائح لا يقل أمانًا عن نظام شريحة ثابتة تتكون فيه شرائح العقدة من جميع الشرائح التي تستخدمها على الإطلاق في حالة الشرائح المتغيرة (انظر النظرية 13 في [68]). كما هو موضح في القسم 4، تعتمد الحيوية على العقد حسنة التصرف تقوم في النهاية بإزالة العقد غير الموثوقة من شرائحهم. نظرًا لأن العقد المختلفة لها متطلبات اتفاقية مختلفة، فإن FBA يمنع تعريفًا عالميًا للسلامة. نحن نقول تتشابك العقد غير المعيبة v1 وv2 عند كل منهما يتقاطع نصاب v1 مع كل نصاب v2 في واحد على الأقل عقدة غير معيبة. يمكن لبروتوكول FBA ضمان الاتفاق فقط بين العقد المتشابكة؛ منذ SCP يفعل ذلك، خطأه التسامح من أجل السلامة هو الأمثل. فرضية الإنترنت ينص تصميم Stellar الأساسي على أن العقد تهتم بالأشخاص حول سوف تكون متشابكة. نقول إن مجموعة العقد I سليمة إذا كنت نصابًا غير معيب بشكل موحد بحيث يتشابك كل عضوين من I حتى لو كانت كل عقدة خارج I معيبة. بشكل حدسي، إذن، يجب أن أبقى منيعًا أمام تصرفات غير سليمة العقد. يضمن SCP كلاً من الحيوية غير المحظورة [93] و السلامة لمجموعات سليمة، على الرغم من أن العقد نفسها لا تحتاج إليها لمعرفة (وقد لا تكون قادرًا على معرفة) المجموعات السليمة. علاوة على ذلك، فإن اتحاد مجموعتين سليمتين متقاطعتين هو مجموعة سليمة. لذلك، تحدد المجموعات السليمة قسمًا من ملف العقد حسنة التصرف، حيث يكون كل قسم آمنًا وحيويًا (في ظل بعض الشروط)، ولكن قد يتم إخراج أقسام مختلفة قرارات متباينة. 3.1.1 اعتبارات السلامة مقابل الحياة في FBA مع استثناءات محدودة [64]، يتم ضبط معظم بروتوكولات الاتفاقية البيزنطية المغلقة على نقطة التوازن التي عندها السلامة والحيوية لهما نفس التسامح مع الخطأ. في فبا، وهذا يعني التكوينات التي، بغض النظر عن الفشل، كل شيء المجموعات المتشابكة سليمة أيضًا. بالنظر إلى أن FBA يحدد النصاب القانوني بطريقة لا مركزية، فمن غير المرجح أن تؤدي اختيارات الشرائح الفردية إلى هذا التوازن. علاوة على ذلك، في على الأقل في Stellar، التوازن غير مرغوب فيه: العواقب من فشل السلامة (أي الأموال الرقمية التي تم إنفاقها بشكل مزدوج). أسوأ بكثير من فشل الحياة (أي التأخير في الدفعات التي استغرقت على أي حال أيامًا قبل Stellar). الناس ولذلك ينبغي القيام بتحديد شرائح النصاب القانوني الكبيرة من هذا القبيل من المرجح أن تظل عقدها متشابكة أكثر من كونها سليمة. علاوة على ذلك، يصبح التعافي منه أسهل إخفاقات الحيوية النموذجية في نظام FBA مقارنةً بالنظام التقليدي المغلق. في الأنظمة المغلقة، يجب أن تكون كافة الرسائل يتم تفسيرها فيما يتعلق بنفس مجموعة النصاب القانوني. وبالتالي، يتطلب إضافة العقد وإزالتها للتعافي من الفشل التوصل إلى إجماع حول حدث إعادة التشكيل، وهو أمر صعب بمجرد انتهاء الإجماع. على النقيض من ذلك، مع FBA، يمكن لأي عقدة ضبط شرائح النصاب القانوني الخاصة بها من جانب واحد في أي وقت الوقت. ردا على انقطاع التيار الكهربائي في أهمية نظامية المؤسسة، يمكن لمسؤولي العقدة ضبط الشرائح الخاصة بهم وفقًا لذلك التغلب على المشكلة، يشبه إلى حد ما تنسيق الاستجابات لكوارث BGP [63] (على الرغم من عدم وجود قيود التوجيه عبر روابط الشبكة الفعلية).
مدفوعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا 3.1.2 نظرية التتالي يتبع SCP قالب النموذج الدائري الأساسي [42]؛ تتقدم العقد من خلال سلسلة من بطاقات الاقتراع المرقمة، لكل منها محاولة القيام بثلاث مهام: (1) تحديد قيمة "آمنة" لا تتعارض مع أي قرار تم اتخاذه في الاقتراع السابق (يُطلق عليه غالبًا إعداد الاقتراع)، (2) الاتفاق على القيمة الآمنة، و (3) اكتشاف أن الاتفاق كان ناجحًا. ومع ذلك، FBA مفتوح العضوية تحبط العديد من التقنيات الشائعة، مما يجعلها من المستحيل "نقل" البروتوكولات التقليدية المغلقة إلى FBA النموذج ببساطة عن طريق تغيير تعريف النصاب القانوني. إحدى التقنيات المستخدمة في العديد من البروتوكولات هي التدوير من خلال العقد الرائدة بطريقة دائرية بعد انتهاء المهلات. في النظام المغلق، يتم ضمان اختيار القائد بشكل دائري في نهاية المطاف، ينتهي الأمر بالقائد الصادق الفريد إلى تنسيق الاتفاق على قيمة واحدة. لسوء الحظ، جولة روبن لا يمكن العمل في نظام FBA بعضوية غير معروفة. أسلوب شائع آخر يفشل مع FBA هو افتراض أن نصابًا معينًا يمكنه إقناع جميع العقد. على سبيل المثال، إذا تعرف الجميع على أي عقد 2f + 1 كنصاب قانوني، إذن تكفي توقيعات 2f + 1 لإثبات حالة البروتوكول لجميع العقد. وبالمثل، إذا تلقت العقدة نصابًا من الرسائل المتطابقة من خلال البث الموثوق [24]، يمكن للعقدة أن تفترض أن جميع العقد غير الخاطئة سوف تشهد أيضًا النصاب القانوني. في FBA، على النقيض من ذلك، أ النصاب القانوني لا يعني شيئا للعقد خارج النصاب القانوني. وأخيرا، غالبا ما تستخدم الأنظمة غير الفيدرالية "الرجعية" التفكير في السلامة: إذا كانت العقد f + 1 معيبة، فكل الأمان فقدت الضمانات. وبالتالي، إذا سمعت العقدة v جميع العقد f + 1 اذكر بعض الحقائق F، v يمكن أن تفترض أن واحدًا على الأقل هو الذي يخبر الحقيقة (وبالتالي F صحيحة) دون فقدان الأمان. مثل هذا يفشل المنطق في FBA لأن السلامة هي خاصية للأزواج من العقد، لذلك يمكن للعقدة التي فقدت الأمان لبعض أقرانها تفقد الأمان دائمًا لمزيد من العقد من خلال افتراض حقائق سيئة. ومع ذلك، يمكن لـ FBA التفكير بشكل عكسي فيما يتعلق بالحيوية. حدد مجموعة v-blocking كمجموعة من العقد التي تتقاطع مع كل منها شريحة v. إذا كانت مجموعة حجب v B معيبة بالإجماع، فإن B يمكن رفض العقدة ضد النصاب القانوني وتكلفتها الحيوية. وبالتالي، إذا ينص B بالإجماع على الحقيقة F، ثم يعرف v أن أيًا من F هو صحيح أو v ليس سليما. ومع ذلك، لا يزال v بحاجة لرؤية كامل النصاب القانوني لمعرفة أن العقد المتشابكة لن تتعارض مع F، مما يؤدي إلى الجولة النهائية من الاتصالات في SCP و بروتوكولات FBA الأخرى [47] غير المطلوبة في الأنظمة المشابهة بروتوكولات العضوية المغلقة. والنتيجة هي أن لدينا ثلاثة مستويات محتملة من الثقة في الحقائق المحتملة: غير محددة، وآمنة للافتراض بين العقد السليمة (وهو ما سنفعله). مصطلح حقائق مقبولة)، وآمن الافتراض فيما بينها العقد (والتي سنسميها حقائق مؤكدة). يمكن للعقدة v تحديد ما إذا كانت المجموعة B محظورة بكفاءة عن طريق التحقق مما إذا كانت B تتقاطع مع جميع شرائحها. ومن المثير للاهتمام أنه إذا كانت العقد تعلن دائمًا عن البيانات فإنها قبول والنصاب القانوني الكامل لقبول بيان، فإنه يطلق عملية متتالية يتم من خلالها نشر البيانات في جميع أنحاء مجموعات سليمة. نحن نسمي الحقيقة الأساسية الكامنة وراء هذا الانتشار النظرية المتتالية، التي تنص على ما يلي: إذا كنت مجموعة سليمة، Q هو النصاب القانوني لأي عضو في I، وS هو أي مجموعة شاملة من Q، ثم إما S ⊇I أو هناك عضو v ∈I بحيث يكون v < S و I ∩S بمثابة حجب v. حدسيًا، كان هذا ليس الأمر كذلك، فإن تكملة S سوف تحتوي على النصاب القانوني الذي يتقاطع مع I وليس Q، مما ينتهك تقاطع النصاب القانوني. لاحظ أنه إذا بدأنا بـ S = Q وقمنا بتوسيع S بشكل متكرر إلى بتضمين جميع العقد التي يحظرها، نحصل على تأثير متتالي حتى، في النهاية، S يشمل كل I. 3.2 وصف البروتوكول SCP هو بروتوكول إجماع متزامن جزئيًا [42] يتكون من سلسلة من المحاولات للوصول إلى إجماع يسمى بطاقات الاقتراع. تستخدم بطاقات الاقتراع فترات زمنية أطول. أ يضمن بروتوكول مزامنة الاقتراع بقاء العقد قائمة نفس الاقتراع لفترات زمنية متزايدة حتى الاقتراع متزامنة بشكل فعال. الإنهاء غير مضمون حتى تصبح بطاقات الاقتراع متزامنة، ولكن ورقتين متزامنتين وهو ما يفعله الأعضاء المعيبون في شرائح العقد حسنة التصرف عدم التدخل كافية لإنهاء SCP. ويحدد بروتوكول الاقتراع الإجراءات المتخذة خلال كل منها الاقتراع. يبدأ الاقتراع بمرحلة إعداد، حيث يتم تحديد العقد محاولة تحديد قيمة لاقتراح لا يتعارض أي قرار سابق. ثم، في مرحلة الالتزام، تحاول العقد لاتخاذ قرار بشأن القيمة المعدة. يستخدم الاقتراع بروتوكولًا فرعيًا للاتفاق يسمى التصويت الفيدرالي، أيn التي العقد تصوت على البيانات المجردة والتي قد يتم تأكيدها في النهاية أو تتعثر. قد يتم تصنيف بعض العبارات على أنها متناقضة، والسلامة ضمان التصويت الفيدرالي هو عدم وجود عضوين في أي عضو مجموعة متشابكة تؤكد تصريحات متناقضة. ولا يضمن تأكيد القول إلا سليما تعيين الذي يصوت جميع أعضائه بنفس الطريقة. ومع ذلك، إذا كان أ عضو في مجموعة سليمة يؤكد بيانًا متحدًا يضمن التصويت أن جميع أعضاء المجموعة السليمة يؤكدون هذا البيان في النهاية. وبالتالي اتخاذ خطوات لا رجعة فيها ردا على تأكيد التصريحات يحفظ الحيوية ل العقد سليمة. تقترح العقد في البداية القيم التي تم الحصول عليها من الترشيح البروتوكول الذي يزيد من فرص جميع الأعضاء سليمة مجموعة تقترح نفس القيمة، والتي تتقارب في نهاية المطاف (على الرغم من عدم وجود طريقة لتحديد التقارب الكامل). يجمع الترشيح بين التصويت الفيدرالي واختيار القائد. لأن جولة روبن مستحيلة في FBA، يستخدم الترشيح مخطط احتمالي لاختيار القائد. تلعب نظرية التعاقب دورًا حاسمًا في الاقتراع المزامنة وتجنب الحالات المحظورة منها الإنهاء لم يعد ممكنا. 3.2.1 الاقتراع تستمر عقد SCP عبر سلسلة من بطاقات الاقتراع المرقمة، باستخدام التصويت الفيدرالي للاتفاق على البيانات المتعلقة بها يتم أو لا يتم تحديد القيم في أي بطاقة اقتراع. إذا كان غير متزامن أو السلوك الخاطئ يمنع التوصل إلى قرار في الاقتراع ن، انتهت مهلة العقد وحاول مرة أخرى في الاقتراع n + 1.
SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. تذكر أن التصويت الفيدرالي قد لا ينتهي. وبالتالي بعض يمكن أن تتعثر البيانات المتعلقة بأوراق الاقتراع بشكل دائم حالة غير محددة حيث لا يمكن للعقد أبدًا تحديد ما إذا كانت لا تزال في التقدم أو عالقة. لأن العقد لا يمكن استبعادها إمكانية إثبات صحة البيانات غير المحددة لاحقًا، ويجب عليهم ألا يحاولوا أبدًا التصويت الفيدرالي على البيانات الجديدة يتعارض مع غير المحدد. في كل اقتراع n، تستخدم العقد التصويت الفيدرالي على نوعين من البيان: • تحضير ⟨n,x⟩– ينص على عدم وجود قيمة أخرى غير x تم أو سيتم تحديده في أي اقتراع. • الالتزام ⟨n,x⟩– الدول x يتم تحديدها في الاقتراع n. الأهم من ذلك، لاحظ أن تحضير ⟨n,x⟩تناقضات الالتزام ⟨n',x ′⟩عندما n ≥n' و x , x ′. تبدأ العقدة الاقتراع n من خلال محاولة التصويت الفيدرالي على a بيان تحضير ⟨n,x⟩. إذا كان هناك أي بيان إعداد سابق تم تأكيده بنجاح من خلال التصويت الفيدرالي تختار العقدة x من الإعداد المؤكد لأعلى بطاقة اقتراع. وبخلاف ذلك، تقوم العقدة بتعيين x إلى إخراج الملف بروتوكول الترشيح الموضح في القسم الفرعي التالي. إذا وفقط إذا أكدت العقدة بنجاح التحضير ⟨n,x⟩ في الاقتراع n، يحاول التصويت الفيدرالي على الالتزام ⟨n,x⟩. إذا إذا نجح، فهذا يعني أن SCP قد قرر، وبالتالي يتم إخراج العقدة القيمة من بيان الالتزام المؤكد. النظر في مجموعة متشابكة S. منذ قيمة واحدة على الأكثر يمكن تأكيد إعدادها من قبل أعضاء S في اقتراع معين، ولا يجوز تأكيد الالتزام بقيمتين مختلفتين أعضاء S في اقتراع معين. علاوة على ذلك، إذا ارتكبت ⟨n,x⟩ تم تأكيده، ثم تم تأكيد إعداد ⟨n,x⟩ أيضًا؛ منذ ذلك الحين يعد ⟨n,x⟩يناقض أي التزام سابق بقيمة مختلفة، بموجب اتفاقية ضمانات التصويت الفيدرالي لقد حصلنا على أنه لا يمكن تحديد قيمة مختلفة في وقت سابق الاقتراع من قبل أعضاء S. عن طريق التعريف بأرقام الاقتراع، نحن لذا تأكد من أن SCP آمن. من أجل الحيوية، فكر في مجموعة سليمة وطويلة بما فيه الكفاية اقتراع متزامن إذا ظهرت العقد الخاطئة في الشرائح من العقد حسنة التصرف لا تتدخل في ن، ثم عن طريق الاقتراع n + 1 جميع أعضاء لقد أكدوا نفس المجموعة P من بيانات الإعداد. إذا كانت P = ∅وبطاقة الاقتراع n طويلة بما فيه الكفاية، فإن سيكون بروتوكول الترشيح قد تقارب على بعض القيمة x. بخلاف ذلك، اجعل x هي القيمة من الإعداد بأعلى ورقة اقتراع في P. وفي كلتا الحالتين، سأحاول بشكل موحد التصويت على إعداد ⟨n + 1,x⟩ في الاقتراع التالي. لذلك، إذا n + 1 متزامن أيضًا، ويتبع ذلك حتماً قرار x. 3.2.2 الترشيح يستلزم الترشيح التصويت الموحد على البيانات: • ترشيح x - الدول x هي مرشح صالح للقرار. قد تصوت العقد لترشيح قيم متعددة — مختلفة تصريحات الترشيح ليست متناقضة. ومع ذلك، مرة واحدة تؤكد العقدة أي بيان ترشيح، وتتوقف عن التصويت عليه ترشيح قيم جديدة. لا يزال التصويت الفيدرالي يسمح للعقدة بذلك تأكيد بيانات الترشيح الجديدة التي لم تصوت لها التصويت أو القبول أ من النصاب القانوني قبول أ من النصاب القانوني أ صالح قبول من مجموعة الحظر غير ملتزم صوت أ قبلت أ أكد أ تم التصويت بـ أ الشكل 1. مراحل التصويت الفيدرالي يسمح لأعضاء مجموعة سليمة بتأكيد مجموعة بعضهم البعض القيم المرشحة مع الاستمرار في حجب الأصوات الجديدة. النتيجة (المتطورة) للترشيح هي مزيج حتمي من جميع القيم في بيانات الترشيح المؤكدة. إذا يمثل x مجموعة من المعاملات، ويمكن للعقد أن تأخذ الاتحاد من المجموعات، المجموعة الأكبر، أو المجموعة ذات أعلى hash، لذا طالما أن جميع العقد تفعل الشيء نفسه. لأن العقد حجب جديدة الأصوات بعد تأكيد بيان ترشيح واحد، مجموعة يمكن أن تحتوي البيانات المؤكدة على عدد محدود من القيم فقط. حقيقة أن التصريحات المؤكدة انتشرت بشكل موثوق من خلال المجموعات السليمة تعني أن العقد السليمة تتقارب في النهاية على نفس مجموعة القيم المرشحة وبالتالي نتيجة الترشيح، وإن كان عند نقطة غير معروفة بشكل تعسفي في وقت متأخر من البروتوكول. تستخدم العقد اختيار القائد المتحد لتقليل عدد القيم المختلفة في بيانات الترشيح. فقط يجوز للقائد الذي لم يصوت بالفعل لصالح بيان الترشيح أن يقدم علامة x جديدة. العقد الأخرى تنتظر أن تسمع منها القادة ويقومون فقط بنسخ أصوات ترشيح قادتهم (الصالحة). لاستيعاب الفشل، تستمر مجموعة القادة في النمو تحدث المهلات، على الرغم من أن عددًا قليلاً فقط من العقد تقدم قيمًا جديدة لـ x. 3.2.3 التصويت الفيدرالي يستخدم التصويت الفيدرالي بروتوكولًا ثلاثي المراحل كما هو موضح في الشكل 1. تحاول العقد الاتفاق على البيانات المجردة أولاً التصويت، ثم القبول، وأخيراً تأكيد البيانات. قد تصوت العقدة v لأي بيان صالح لا ينطبق عليه ذلك يناقض غيرهالأصوات المتميزة والبيانات المقبولة. ويتم ذلك عن طريق بث رسالة تصويت موقعة. v ثم يقبل a إذا كان a متوافقًا مع البيانات المقبولة الأخرى وإما (الحالة 1)v هو عضو في النصاب القانوني الذي كل عقدة إما تصوت لـ أو تقبل أو (الحالة 2) حتى لو كانت v لم أصوت لصالح مجموعة v-blocking تقبل a. في الحالة 2، قد سبق أن أدلوا بأصوات تتعارض مع ما حدث الآن تم نقضها. v يُسمح له بنسيان الأصوات الملغاة ويتظاهر بأنه لم يلقيهم أبدًا لأنه إذا كان سليمًا، فهو يعلم لا يمكن للأصوات الملغاة إكمال النصاب القانوني من خلال الحالة 1. v يبث أنه يقبل a، ثم يؤكد a عندما يكون موجودًا نصاب يقبل بالإجماع أ. ويبين الشكل 2 تأثير مجموعات الحجب v ونظرية التتالي خلال التصويت الفيدرالي. لا يمكن لعقدتين متشابكتين تأكيد البيانات المتناقضة، حيث يجب أن يتشارك النصابان المطلوبان في أمدفوعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا 3 4 2 1 5 7
Stellar コンセンサスプロトコル
Stellar コンセンサス プロトコル (SCP) はクォーラムベースの オープンメンバーシップを備えたビザンチン協定プロトコル。クォーラムは、個々のノードのローカル構成の決定を組み合わせて生成されます。ただし、ノードは認識するだけです 自分自身が所属する定員会に参加した後のみ、 他のすべての定足数メンバーのローカル構成を学習します。このアプローチの利点の 1 つは、SCP が本質的に どのようなノードが存在するかについての異種のビューを許容します。したがって、 ノードは一方的に参加したり離脱したりできます。 メンバーシップを調整するための「ビュー変更」プロトコル。 3.1 ビザンチン連邦協定 伝統的なビザンチン協定の問題は次のようなもので構成されています。 N 個のノードからなるクローズド システム。そのうちのいくつかには障害があり、 恣意的に行動する。ノードは入力値を受け取り、交換します。 入力の中から出力値を決定するためのメッセージ。 ビザンチン協定プロトコルは、行儀の良い 2 つのノードが異なる決定を出力せず、一意の決定を出力しない場合には安全です。 決定は有効な入力でした（有効な合意の定義にとって）SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル ロカバら。 事前に）。プロトコルが有効であることは、それが保証する場合に有効です。 すべての正直なノードは最終的に決定を出力します。 通常、プロトコルは整数に対して N = 3f + 1 を想定します。 f > 0 の場合、安全性と何らかの形の生存性が保証されるため、 最大でも f 個のノードに障害がある限り。これらのある段階で、 プロトコル、ノードは提案された値と提案に投票します 投票の定足数と呼ばれる 2f + 1 票を受け取ると、 決定。 N = 3f + 1 ノードの場合、任意の 2 つのクォーラム サイズ 2f + 1 は少なくとも f + 1 ノードでオーバーラップします。たとえこれらのうちの 重複するノードに障害がある場合、2 つのクォーラムは少なくとも共有します 障害のない 1 つのノードにより、矛盾した決定が防止されます。 ただし、このアプローチは、すべてのノードが同意する場合にのみ機能します。 定足数を構成するものは何ですか。SCP では不可能です。 2 つのノードは互いの存在を知らない場合もあります。 SCP では、各ノード v が一方的にノードのセットを宣言します。 (a) v は、すべての場合に次のように信じます。 スライスのメンバーがシステムの状態について同意すると、 彼らは正しく、(b) v はそのスライスの少なくとも 1 つが、 に関するタイムリーな情報を提供できるようになります。 システムの状態。結果として得られるシステムを次のように呼びます。 ノードとそのスライスの統合ビザンチン協定 （FBA）システム。次に見るように、定足数システムが登場します ノードのスライスから。 非公式には、FBA ノードのスライスは誰との関係を表します。 ノードには同意が必要です。たとえば、ノードには、それぞれ 3 つのノードを実行する 4 つの特定の組織との合意が必要な場合があります。に ダウンタイムに対応するため、スライスをすべてのセットに設定する場合があります 各組織の 2 つのノードで構成されます。これが「必要な場合」 「一致」関係は任意の 2 つのノードを推移的に関連付けます。 世界的な合意が得られます。そうしないと、発散が発生する可能性があります。 ただし組織間のみであり、どちらの組織も必要ありません 相手との合意。今日のトポロジーを考えると、 金融システムでは、広範な収束が人々が呼ぶ単一の元帳履歴を生み出し続けると仮説を立てています。 私たちがインターネットについて話すのと同じように、「Stellar ネットワーク」です。 クォーラムは次のようにスライスから生成されます。すべてのノードが指定します 送信するすべてのメッセージのクォーラム スライスが発生します。 S を 一連のメッセージの発信元となるノードのセット。あ ノードは一連のメッセージがクォーラムに達したとみなします。 S のすべてのメンバーが S に含まれるスライスを持つ場合のしきい値。 構造上、そのような集合 S は、全員一致であれば、次の条件を満たします。 各メンバーの同意要件。 障害のあるピアは、内容を変更するために作成されたスライスをアドバタイズする可能性があります。 正常に動作するノードはクォーラムを考慮します。プロトコル分析のために、FBA のクォーラムは空ではないものとして定義されます。 少なくとも 1 つのクォーラム スライスを含むノードのセット S 欠陥のない各メンバー。他のセットと同様に、この抽象化は健全です 全会一致の定足数を表すと称するメッセージの数 実際には (障害のあるノードからのメッセージが含まれている場合でも)、 そして、S に行儀の良いノードのみが含まれている場合は正確です。で このセクションでは、ノードのスライスは変更されないと仮定します。 それにもかかわらず、私たちの結果はスライス変更の場合に当てはまります。 なぜなら、スライスが変化するシステムは安全であることに劣らないからです。 ノードのスライスがすべての要素で構成される固定スライス システム。 スライス変更の場合に使用するスライス (定理を参照) [68] の 13)。セクション 4 で説明したように、活性度は以下に依存します。 行儀の良いノードは最終的に信頼性の低いノードを削除します 彼らのスライスから。 異なるノードには異なる合意要件があるため、FBA では安全性のグローバルな定義が妨げられます。私たちは言います 障害のないノード v1 と v2 が絡み合っているのは、 v1 のクォーラムが少なくとも 1 つで v2 のすべてのクォーラムと交差します。 障害のないノード。 FBAプロトコルにより合意を保証できる 絡み合ったノード間のみ。 SCP がそうするのですから、SCP のせいです 安全性に対する許容度は最適です。インターネット仮説、 Stellar の設計の根底にあるのは、人々が気にかけているノードであると述べています について絡みます。 I の外側のすべてのノードに障害がある場合でも、I のすべての 2 つのメンバーが絡み合っているような、一様に障害のないクォーラムである場合、ノードのセット I は無傷であると言います。直感的には、 それなら、私は無傷でない者の行為に影響されないようにする必要があります ノード。 SCP は、ノンブロッキングな生存性 [93] と ノード自体は必要ありませんが、無傷のセットに対する安全性 どのセットが無傷であるかを知るためです (また、知ることができない場合もあります)。 さらに、交差する 2 つのそのままのセットの和集合は次のようになります。 無傷のセット。したがって、そのままのセットは、 各パーティションが安全で稼働している、正常に動作するノード (条件によっては)ただし、異なるパーティションが出力する場合があります 異なる決定。 3.1.1 FBA における安全性と生存性の考慮事項 限られた例外 [64] を除いて、ほとんどの終了したビザンチン協定プロトコルは、均衡点に調整されています。 安全性と活性性は同じ耐障害性を持っています。 FBAでは、 つまり、障害に関係なく、すべての 絡み合ったセットもそのままです。 FBAが判断した場合、 分散型のクォーラムでは、個々のスライスの選択がこの均衡につながる可能性は低いです。さらに、 少なくともStellarでは、均衡は望ましくない: その結果 安全上の欠陥（デジタルマネーの二重使用）は、 liveness 障害 (つまり、遅延) よりもはるかに悪いです。 いずれにしても Stellar までに数日かかった支払いの場合）。人々 したがって、次のような大きなクォーラム スライスを選択する必要がありますし、実際に選択する必要があります。 それらのノードは無傷よりも絡み合ったままになる可能性が高くなります。 さらに状況が悪化すると、回復が容易になります。 FBA システムでは、従来のクローズドシステムよりも一般的な liveness 障害が発生します。閉じたシステムでは、すべてのメッセージは次のとおりである必要があります。 同じクォーラムのセットに関して解釈されます。したがって、 障害から回復するためにノードを追加および削除するには、次のことが必要です 再構成イベントについて合意に達することですが、合意が得られなくなると困難になります。それに対してFBAの場合は、 どのノードもクォーラム スライスをいつでも一方的に調整できます。 時間。システム上重要なシステムの停止に対応して 組織では、ノード管理者はスライスを次のように調整できます。 対応を調整するような感じで問題を回避する BGP の大惨事 [63] まで (ただし、次のような制約はありません) 物理ネットワークリンクを介したルーティング）。
Stellar による高速かつ安全なグローバル支払い SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル 3.1.2 カスケード定理 SCP は、基本的なラウンド モデル [42] のテンプレートに従います。 ノードは一連の番号付き投票を進めていきます。 3 つのタスクを試みます：（1）以前の投票の決定と矛盾しない「安全な」値を特定します（よくこのように呼ばれます） (2) 安全値に同意し、(3) 同意が成功したことを検出します。ただし、FBAは開いています メンバーシップはいくつかの一般的な手法を妨げ、 従来のクローズドプロトコルをFBAに「移植」することは不可能 クォーラムの定義を変更するだけでモデルを構築できます。 多くのプロトコルで採用されている手法の 1 つがローテーションです。 タイムアウト後にラウンドロビン方式でリーダー ノードを経由します。クローズド システムでは、ラウンドロビンのリーダー選択により確実に 最終的には、唯一無二の誠実なリーダーが、単一の価値観についての合意を調整することになるのです。残念ながらラウンドロビン メンバーシップが不明な FBA システムでは機能できません。 FBA で失敗するもう 1 つの一般的なテクニックは、特定のクォーラムがすべてのノードを説得できると想定することです。たとえば、 全員が 2f + 1 ノードをクォーラムとして認識すると、 2f + 1 署名は、すべてのノードに対してプロトコル状態を証明するのに十分です。 同様に、ノードが同一のメッセージのクォーラムを受信した場合、 信頼性の高いブロードキャスト [24] を通じて、ノードは障害のないすべてのノードにもクォーラムがあると想定できます。対照的に、FBA では、 クォーラムは、クォーラム外のノードにとっては何の意味も持ちません。 最後に、非連合システムは「逆方向」を使用することがよくあります。 安全性に関する推論: f + 1 ノードに障害がある場合、すべてが安全である 保証は失われます。したがって、ノード v が f + 1 ノードすべてを聞くと、 何らかの事実を述べる F、v は、少なくとも 1 人が、 安全性を損なうことなく、真実（したがって F は真実）になります。そんな 安全性はペアの特性であるため、FBA では推論が失敗します ノードの数が多いため、一部のピアに対して安全性を失ったノードは、 悪い事実を仮定することにより、常により多くのノードの安全性が失われます。 ただし、FBA はライブ性について逆に推論することができます。 v ブロッキング セットを、すべてのノードと交差するノードのセットとして定義します。 v のスライス。v ブロッキング セット B が満場一致で欠陥がある場合、B ノードとクォーラムを拒否し、活性を損なう可能性があります。したがって、もし B が満場一致で事実 F を述べた場合、v はいずれかの F が true または v はそのままではありません。ただし、v はまだ完全なものを確認する必要があります。 絡み合ったノードが F と矛盾しないことを知るための定足数、 これはSCPでのコミュニケーションの最終ラウンドにつながり、 類似のプロトコルでは必要のない他の FBA プロトコル [47] 非公開メンバーシッププロトコル。その結果、 潜在的な事実に対する信頼度の 3 つの可能なレベル: 不確定、無傷のノード間で想定しても安全 (これについては後で説明します) 用語は受け入れられた事実）、絡み合っていると想定するのが安全です ノード（これを確認された事実と呼びます）。 ノード v は、セット B がそのすべてのスライスと交差するかどうかをチェックすることで、セット B が vblocking かどうかを効率的に判断できます。興味深いことに、ノードが常にステートメントをアナウンスする場合、 accept し、フルクォーラムがステートメントを受け入れると、ステートメントが全体に伝播するカスケード プロセスが開始されます。 無傷のセット。この伝播の根底にある重要な事実を カスケード定理は次のことを述べています。 そのままのセット、Q は I の任意のメンバーの定足数、S は任意のメンバー Q のスーパーセットの場合、S ⊇I か、メンバー v ∈I が存在します。 v < S および I ∩S は v ブロッキングです。直感的には、これでしたか そうでない場合、S の補数には定足数が含まれます。 これは I と交差しますが、Q とは交差せず、クォーラム交差に違反しています。 S = Q から始めて S を繰り返し拡張すると、 ブロックするすべてのノードを含めると、次のようなカスケード効果が得られます。 最終的に、S は I のすべてを包含します。 3.2 プロトコルの説明 SCP は、部分同期コンセンサス プロトコル [42] であり、コンセンサスに達するための一連の試みで構成されます。 投票用紙。投票では、継続時間が長くなるタイムアウトが採用されます。あ 投票同期プロトコルにより、ノードが確実に稼働状態に維持されます。 投票用紙が届くまでの期間が長くなり、同じ投票用紙が使用される 事実上同期しています。終了は保証されません 投票が同期されるまで、ただし 2 つの同期投票 正常に動作するノードのスライスの欠陥のあるメンバーがそうなる SCP が終了するには、干渉しないだけで十分です。 投票プロトコルは、投票ごとに実行されるアクションを指定します。 投票用紙。投票は準備フェーズから始まります。 矛盾しない提案する値を決定してください 以前の決定。次に、コミットフェーズで、ノードは次のことを試みます。 準備された値に基づいて決定を行います。 投票には、連合投票と呼ばれる合意サブプロトコルが使用されます。n どのノードが抽象ステートメントに投票するか それは最終的に確認されるか、行き詰まる可能性があります。一部の記述は矛盾しているとみなされる可能性があり、安全性は 連合投票の保証は、2 人のメンバーが連合投票を行わないことです。 絡み合ったセットは矛盾したステートメントを裏付けます。ステートメントが無傷である場合を除き、ステートメントの確認は保証されません メンバー全員が同じように投票するセット。ただし、 完全なセットのメンバーがステートメントを確認します。フェデレーテッド 投票により、無傷のセットのすべてのメンバーが最終的にそのステートメントを確認することが保証されます。そこで、取り返しのつかない措置を講じる 確認ステートメントに応じて、生存期間を維持します 無傷のノード。 ノードは最初に、候補から取得した値を提案します。 メンバー全員が無傷である可能性を高めるプロトコル 同じ値を提案する集合、そして最終的には収束する (ただし、収束が完了したかどうかを判断する方法はありません)。 指名は、連合による投票とリーダーの選択を組み合わせたものです。 FBAでは総当たりが不可能なため、指名は 確率的なリーダー選択スキーム。 カスケード定理は投票においても重要な役割を果たします。 同期を確立し、ブロック状態を回避します。 終了はもう不可能です。 3.2.1 投票 SCP ノードは一連の番号付き投票を進め、連合投票を利用して以下の声明に同意します。 値はどの投票用紙で決定されるか決定されません。非同期の場合 または、誤った行動により投票番号 n での決定に達することができません。 ノードがタイムアウトになり、投票 n + 1 で再試行します。
SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル ロカバら。 連合投票が終了しない可能性があることを思い出してください。したがって、いくつかの 投票用紙に関する発言は永久に固定化される可能性があります ノードがその状態にあるかどうかを決して判断できない不定状態。 まだ進行中か停止中です。ノードは除外できないため 不確定な発言が後で真実であることが判明する可能性、 新しい声明に対する連合投票を決して試みてはなりません 矛盾する不定なもの。 各投票 n では、ノードは 2 つのタイプの連合投票を使用します。 ステートメントの: • prepare ⟨n,x⟩ – x 以外の値がないことを示します n 以内の投票で決定された、または今後決定されることになります。 • commit ⟨n,x⟩ – x が投票 n で決定されると述べます。 重要なのは、prepare ⟨n,x⟩ は commit に矛盾することに注意してください。 ⟨n′,x ′⟩ n ≧ n′かつ x , x ′のとき。 ノードは、投票 n に対して連合投票を試みることによって開始します。 ステートメントは ⟨n,x⟩ を準備します。以前の準備ステートメントがある場合 連合投票により無事確認されました。 ノードは、確認された最高の投票用紙から x を選択します。それ以外の場合、ノードは x を 指名プロトコルについては次のサブセクションで説明します。 ノードが ⟨n,x⟩ の準備を正常に確認した場合にのみ 投票 n では、コミット ⟨n,x⟩ で統合投票を試みます。もし それが成功した場合、SCP が決定したことを意味するため、ノードは次のように出力します。 確認されたコミットステートメントの値。 絡み合った集合 S を考えてみましょう。値は 1 つだけなので、 特定の投票用紙で S のメンバーが作成したものであることを確認できますが、2 つの異なる値がコミットされたことを確認することはできません。 特定の投票用紙に含まれる S のメンバー。さらに、 commit ⟨n,x⟩ の場合 が確認されたら、⟨n,x⟩ を準備することも確認されました。それ以来 prepare ⟨n,x⟩ は、フェデレーション投票の合意保証により、異なる値に対する以前のコミットと矛盾します。 異なる値が以前に決定されることはないことがわかります。 S のメンバーによる投票。投票番号の誘導により、 したがって、SCP は安全であることがわかります。 生存性については、無傷のセット I と十分に長いものを考慮してください。 同期投票 n.スライスに障害のあるノードが現れた場合 行儀の良いノードのうち、n に干渉しないノードは投票によって決定されます n + 1 I のすべてのメンバーは、prepare ステートメントの同じ集合 P を確認しました。 P = ∅で投票用紙 n が十分に長い場合、 指名プロトコルは、ある値 x に収束します。 それ以外の場合、x を P で最も高い投票数を持つ準備からの値とします。いずれにしても、私は一律にフェデレーションを試みます。 次の投票で⟨n + 1,x⟩を準備することに投票します。したがって、もし n + 1 も同期しているため、必然的に x の決定が続きます。 3.2.2 指名 指名には、以下の声明に対する連合投票が必要となります。 • nominate x – x が有効な決定候補であると述べます。 ノードは、複数の値 (異なる値) を指名するために投票することができます。 指名発言は矛盾していない。ただし、一度、 ノードは任意の指名ステートメントを確認すると、投票を停止します。 新しい価値観を提案します。フェデレーション投票により、ノードは引き続き次のことを行うことができます。 投票しなかった新たな指名声明を確認する。 投票または承認 定足数から 受け入れる 定足数から は有効です からのを受け入れる ブロッキングセット コミットされていない に投票した を受け入れました を確認した に投票しました 図 1. 連合投票の段階 完全なセットのメンバーがお互いのことを確認できるようになります。 新たな投票を保留しながら、ノミネートされた値を変更します。 指名の (進化する) 結果は、確認された指名ステートメント内のすべての値の決定論的な組み合わせです。もし x はトランザクションのセットを表し、ノードは和集合を取ることができます セットの中で、最大のセット、または最も高い hash を持つセット、つまり すべてのノードが同じことを行う限り。ノードが新規を保留しているため 1 つの指名発言を確認した後に投票します。 確認されたステートメントには、有限個の値のみを含めることができます。 確認された声明が確実に拡散したという事実 無傷のセットとは、無傷のノードが最終的に 候補値のセットが同じであるため、候補結果が得られます。 ただし、プロトコルの後半の未知の時点で任意に行われました。 ノードはフェデレーテッド リーダー選択を採用して、 nominate ステートメント内の異なる値の数。のみ 指名声明にまだ投票していない指導者は、新しい × を導入することができます。他のノードはメッセージの受信を待機します リーダーの（有効な）指名投票をコピーするだけです。 失敗に対応するために、リーダーのセットは成長し続けます。 タイムアウトが発生しますが、実際には x の新しい値を導入するノードはわずかです。 3.2.3 連合投票 連合投票では、以下に示す 3 段階のプロトコルが採用されています。 図 1. ノードは最初に抽象ステートメントに同意しようとします 投票し、次に承認し、最後に声明を確認します。 ノード v は、有効なステートメント a に投票できます。 他と矛盾する未決の投票数と受け入れられた声明。これは、署名された投票メッセージをブロードキャストすることによって行われます。 v 次に、a が他の受け入れられたステートメントと一致しており、かつ (ケース 1)v が次のクォーラムのメンバーである場合に、a を受け入れます。 各ノードは、a に投票するか、a を受け入れるか、または (ケース 2) v の場合でも a に投票しませんでしたが、v ブロッキング セットは a を受け入れます。ケース 2 の場合、v は 以前に a に反対する票を投じたことがあるが、現在は 却下されました。 v 否決された投票については忘れてもよい そして、もしvが無傷なら、それは知っているので、それらをキャストしなかったふりをします 否決された投票では、ケース 1 によって定足数を満たすことはできません。 v a を受け入れることをブロードキャストし、それが入っているときに a を確認します。 全会一致で承認する定足数。図 2 は、 v ブロック集合とカスケード定理の効果 連合投票。 2 つの必要なクォーラムが共有する必要があるため、絡み合った 2 つのノードは矛盾するステートメントを確認できません。Stellar による高速かつ安全なグローバル支払い SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル 3 4 2 1 5 7
التصويت ×
التصويت ي (أ) 3 4 2 1 5 7 6 التصويت X التصويت X التصويت X التصويت ي التصويت X التصويت ي التصويت ي (ب) 3 4 2 1 5 7 6 قبول X التصويت X قبول X التصويت ي قبول X التصويت ي التصويت ي (ج) 3 4 2 1 5 7 6 قبول X قبول X قبول X التصويت ي قبول X قبول X التصويت ي (د) 3 4 2 1 5 7 6 قبول X التصويت X قبول X قبول X قبول X قبول X قبول X (هـ) الشكل 2. تأثير تتالي في التصويت الاتحادي. تحتوي كل عقدة على شريحة نصاب واحدة يُشار إليها بأسهم لأعضاء الشريحة. (أ) تم تقديم بيانات متناقضة X وY. (ب) تصوت العقد على البيانات الصحيحة. (ج) العقدة 1 تقبل X بعد نصابها القانوني {1، 2، 3، 4} يصوتون بالإجماع لصالح X. (د) تقبل جميع العقد 1 و2 و3 و4 X؛ المجموعة {1} عبارة عن 5 حظر، لذا تقبل العقدة 5 X، مما يؤدي إلى إلغاء ذلك تصويتها السابق لصالح Y. (هـ) المجموعة {5} عبارة عن حجب 6 و7، لذا يقبل كل من 6 و7 X. عقدة غير معيبة لا يمكنها قبول البيانات المتناقضة. تأكيد البيان غير مضمون: في وفي حالة انقسام التصويت، يجوز أن يكون كلا البيانين بشكل دائم عالقون في انتظار اكتمال النصاب القانوني في مرحلة التصويت. ومع ذلك، إذا عقدة في مجموعة سليمة تؤكد بيانًا، التتالي النظرية وقبول الحالة 2 تأكد من أنني سأفعل ذلك جميعًا في النهاية تأكيد هذا البيان. 3.2.4 مزامنة الاقتراع إذا كانت العقد غير قادرة على تأكيد بيان الالتزام لـ الاقتراع الحالي، فإنهم يستسلمون بعد مهلة. يحصل المهلة لفترة أطول مع كل اقتراع حتى يتسنى التكيف مع الحدود التعسفية على تأخير الشبكة. ومع ذلك، فإن المهلات وحدها ليست كافية لمزامنة بطاقات الاقتراع الخاصة بالعقد التي لم تبدأ في نفس الوقت أو حصلت على غير متزامنة لأسباب أخرى. لتحقيق التزامن، تبدأ العقد في تشغيل المؤقت فقط عندما تصبح جزءًا من ملف النصاب القانوني الذي يكون موجودًا في الاقتراع الحالي (أو اللاحق) n. هذا يبطئ العقد التي بدأت مبكرًا ويضمن عدم حدوث ذلك يبقى العضو في مجموعة سليمة متقدمًا جدًا على المجموعة. علاوة على ذلك، إذا لاحظت العقدة v تعيين حجب v في وقت لاحق الاقتراع، فإنه يتخطى على الفور إلى أدنى بطاقة اقتراع مثل هذا لم يعد هذا هو الحال، بغض النظر عن أي توقيت. الشلال ثم تضمن النظرية أن جميع المتطرفين يلحقون بالركب. النتيجة هو أن بطاقات الاقتراع تتم مزامنتها تقريبًا في جميع أنحاء سليمة يتم ضبطه بمجرد أن يصبح النظام متزامنًا. 3.2.5 اختيار الزعيم الاتحادي يسمح اختيار القائد لكل عقدة باختيار القادة في مثل هذا الطريقة التي تختار بها العقد عمومًا واحدًا أو عددًا صغيرًا فقط من القادة. لاستيعاب فشل القائد، يتم اختيار القائد العائدات من خلال جولات. إذا كان قادة الجولة الحالية يبدو أنهم لا يقومون بمسؤولياتهم، ثم بعد أ تنتقل عقد معينة في فترة المهلة إلى الجولة التالية توسيع مجموعة القادة الذين يتبعونهم. تستخدم كل جولة وظيفتين تشفيريتين فريدتين hash، H0 وH1، اللتين تنتجان أعدادًا صحيحة في النطاق [0,hmax). على سبيل المثال، Stellar يستخدم Hi(m) = SHA256(i∥b∥r ∥m)، حيث b هو مثيل SCP الإجمالي (رقم الكتلة أو دفتر الأستاذ)، وr هو الرقم الدائري لاختيار القائد، وhmax = 2256. ضمن جولة، نحدد أولوية العقدة v على النحو التالي: الأولوية (ت) = H1(ت) سيكون رجل القش واحدًا لكل عقدة لتختاره كقائد العقدة ذات الأولوية العليا (v). هذا النهج يعمل بشكل جيد مع شرائح النصاب القانوني المتطابقة تقريبًا، ولكن ليس بشكل صحيح التقاط أهمية العقد في التكوينات غير المتوازنة. على سبيل المثال، إذا ساهمت كل من أوروبا والصين بـ 3 عقد لكل نصاب، لكن الصين تدير 1000 عقدة وأوروبا 4، عندها ستحصل الصين على العقدة ذات الأولوية القصوى بنسبة 99.6% من الوقت. لذلك نقدم فكرة وزن الشريحة، حيث الوزن (u,v) ∈[0, 1] هو جزء من شرائح النصاب القانوني للعقدة u تحتوي على العقدة v. عندما تقوم العقدة u باختيار قائد جديد، فإنه يأخذ في الاعتبار الجيران فقط، ويتم تعريفهم على النحو التالي: الجيران (ش) = { ت | H0(v) < hmax · الوزن(u,v) } تبدأ العقدة بعد ذلك بمجموعة فارغة من القادة، وعند كل منهم تضيف إليها العقدة v في الجيران (u) ذات الأعلى الأولوية (ت). إذا كانت مجموعة الجيران فارغة في أي جولة، فبدلاً من ذلك تضيف العقدة ذات القيمة الأقل H0(v)/weight(u,v).
X に投票
Yに投票 (a) 3 4 2 1 5 7 6 投票する × 投票する × 投票する × 投票する Y 投票する × 投票する Y 投票する Y (b) 3 4 2 1 5 7 6 受け入れる × 投票する × 受け入れる × 投票する Y 受け入れる × 投票する Y 投票する Y (c) 3 4 2 1 5 7 6 受け入れる × 受け入れる × 受け入れる × 投票する Y 受け入れる × 受け入れる × 投票する Y (d) 3 4 2 1 5 7 6 受け入れる × 投票する × 受け入れる × 受け入れる × 受け入れる × 受け入れる × 受け入れる × (e) 図 2. 連合投票におけるカスケード効果。各ノードには、スライスのメンバーへの矢印で示される 1 つのクォーラム スライスがあります。 (a) 矛盾したステートメント X と Y が導入されます。 (b) ノードは有効なステートメントに投票します。 (c) ノード 1 はクォーラムの後に X を受け入れます {1, 2, 3, 4} は全会一致で X に投票します。(d) ノード 1、2、3、および 4 はすべて X を受け入れます。セット {1} は 5 ブロッキングであるため、ノード 5 は X を受け入れ、これを無効にします。 (e) セット {5} は 6 および 7 ブロックであるため、6 と 7 は両方とも X を受け入れます。 矛盾していないステートメントを受け入れることができない障害のないノード。ステートメントの確認は保証されていません: 投票が分かれた場合、両方の声明が永久に残る可能性がある 投票フェーズで定足数に達するのを待っている状態です。ただし、 無傷のセット内のノード 私はステートメント、カスケードを確認します 定理とケース 2 を受け入れると、最終的にはすべてが確実に その発言を確認します。 3.2.4 投票用紙の同期 ノードがコミットステートメントを確認できない場合、 現在の投票では、タイムアウト後にギブアップします。タイムアウトが発生する 任意の範囲に調整するために投票ごとに長くする ネットワーク遅延について。 ただし、タイムアウトだけでは、同時に開始されなかったノードの投票を同期するには十分ではありません。 他の理由で非同期になりました。同期を実現するために、ノードはノードの一部になったときにのみタイマーを開始します。 現在 (または今後) の投票ですべての定足数 n.これ 早期に起動したノードの速度を低下させ、 無傷のセットのメンバーがグループよりもはるかに先にいる。 さらに、ノード v が後で v-blocking セットに気づいた場合 投票の場合、すぐに最下位の投票にスキップします。 タイマーに関係なく、これはもう当てはまりません。カスケード 定理により、すべての落伍者が確実に追いつきます。結果 投票用紙は無傷の組織全体でほぼ同期されているということです。 システムが同期状態になると設定されます。 3.2.5 連合リーダーの選択 リーダーの選択により、各ノードがそのようなリーダーを選択できるようになります。 ノードが通常 1 つまたは少数の数だけを選択する方法 リーダーたちの。リーダーの失敗に対応するためのリーダーの選択 ラウンドを経て進みます。現在のラウンドのリーダーの場合 責任を果たしていないように見え、その後、 特定のタイムアウト期間のノードは次のラウンドに進みます。 彼らが従うリーダーの集団を拡大します。 各ラウンドでは、[0,hmax) の範囲の整数を出力する 2 つの固有の暗号化関数 hash 関数 H0 と H1 が使用されます。 たとえば、Stellar は Hi(m) = SHA256(i∥b∥r ∥m) を使用します。 b は SCP インスタンス全体 (ブロックまたは台帳番号)、r は リーダー選択ラウンド番号、および hmax = 2256。 ラウンドでは、ノード v の優先順位を次のように定義します。 優先度(v) = H1(v) 各ノードで 1 人のストローマンがリーダーとして選択されます 最も高い優先順位を持つノード (v)。このアプローチは機能します ほぼ同一のクォーラム スライスでは問題ありませんが、正しく動作しません 不均衡な構成におけるノードの重要性を把握します。たとえば、ヨーロッパと中国がそれぞれ 3 を貢献した場合、 すべてのクォーラムにノードを追加しますが、中国が 1,000 ノード、ヨーロッパが 4 ノードを実行すると、中国が 99.6% の優先順位の最も高いノードを持つことになります。 当時の。 したがって、スライス重みの概念を導入します。 Weight(u,v) ∈[0, 1] はノード u のクォーラム スライスの割合です ノード v を含む。ノード u が新しいリーダーを選択するとき、 次のように定義される近傍のみを考慮します。 隣人(u) = { v | H0(v) < hmax · 重み(u,v) } 次に、ノードは空のリーダーのセットから開始され、それぞれのリーダーで ラウンドは、最も高い値を持つneighbors(u)のノードvをそれに追加します。 優先度(v)。いずれかのラウンドで近隣セットが空の場合、u は代わりに H0(v)/weight(u,v) の最小値を持つ nodev を追加します。
التحقق الرسمي من SCP
للتخلص من أخطاء التصميم، قمنا بالتحقق رسميًا من سلامة SCP وخصائص الحيوية (انظر [65]). على وجه التحديد، لقد تحققنا وأن العقد المتشابكة لا تختلف أبدًا، وأنه في ظل الظروف الموضحة أدناه، يقرر كل عضو في المجموعة السليمة في النهاية. ومن المثير للاهتمام أن التحقق كشف أن الظروف التي بموجبها تضمن SCP الحيوية تكون دقيقة، وأقوى مما كان يعتقد في البداية [68]: كما هو موضح أدناه، العقد الخبيثة التي تتلاعب بالتوقيت دون غير ذلك قد يحتاج الانحراف عن البروتوكول إلى الإخلاء يدويًا من شرائح النصاب.
SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. للتأكد من أن الخصائص ثبت ثباتها بكل ما هو ممكن تكوينات FBA وعمليات التنفيذ، نعتبرها تعسفية عدد العقد ذات التكوينات المحلية التعسفية. هذا يتضمن سيناريوهات ذات مجموعات سليمة مفككة، بالإضافة إلى عمليات تنفيذ طويلة بلا حدود. العيب هو أننا مواجهة المشكلة الصعبة المتمثلة في التحقق من المعلمات نظام الدولة اللانهائية. لإبقاء التحقق سهلاً، قمنا بتصميم SCP في منطق الدرجة الأولى (FOL) باستخدام Ivy [69] ومنهجية [82]. تتكون عملية التحقق من تقديم تخمينات استقرائية يدويًا، والتي يتم بعد ذلك التحقق منها تلقائيًا اللبلاب. يلخص نموذج FOL لملخصات SCP بعض جوانب أنظمة FBA التي يصعب التعامل معها في FOL (على سبيل المثال، يتم أخذ نظرية التتالي كبديهية)، لذلك نحن نتحقق من سلامة التجريد باستخدام Isabelle/HOL [75]. بعد التعبير عن مشكلة التحقق في FOL، نتحقق من السلامة من خلال توفير ثابت استقرائي. الاستقرائي يتكون الثابت من عشرات التخمينات ذات السطر الواحد لحوالي 150 سطرًا من مواصفات البروتوكول. نقوم بعد ذلك بتحديد خصائص حيوية SCP في المنطق الزمني الخطي لـ Ivy ونستخدم من الحيوية إلى تقليل السلامة [80، 81] لتقليل الحيوية مشكلة التحقق لمشكلة العثور على الاستقرائي ثابت. في حين أن سلامة SCP واضحة نسبيًا أثبت أن حجة حيوية SCP أكثر تعقيدًا و يتكون من حوالي 150 ثابتًا في سطر واحد. يتطلب إثبات الحيوية إضفاء الطابع الرسمي الدقيق على الافتراضات التي بموجبها تضمن SCP الإنهاء. لقد اعتقدنا في البداية أن المجموعة السليمة سوف أقوم بإنهائها دائمًا قام الأعضاء بإزالة العقد المعيبة من شرائحهم [68]. ومع ذلك، فقد تبين أن هذا غير كاف: حسن التصرف (لكن غير سليمة) عقدة في النصاب القانوني لعضو أستطيع، تحت تأثير العقد الخاطئة، ومنع الإنهاء عن طريق استكمال النصاب القانوني قبل نهاية الاقتراع مباشرة، مما يتسبب في ذلك أعضاء I لاختيار قيم مختلفة لـ x في الاقتراع التالي. ولذلك يجب علينا بالإضافة إلى ذلك أن نفترض أنه، بشكل غير رسمي، كل عقدة في النصاب القانوني لعضو من أنا في نهاية المطاف سواء يصبح في الوقت المناسب أو لا يرسل الرسائل على الإطلاق لفترة كافية. في الممارسة العملية، هذا يعني أعضاء يجوز لي بحاجة إلى ضبط شرائحهم حتى يستمر الشرط. هذا المشكلة ليست متأصلة في أنظمة FBA: Losa et al. [47] موجود بروتوكول تعتمد حيويته على الأضعف تمامًا افتراضات التزامن النهائي وانتخاب القائد في نهاية المطاف، دون الحاجة إلى إزالة العقد المعيبة من الشرائح.
SCPの正式な検証
設計ミスを排除するために、SCP の安全性を正式に検証しました および liveness プロパティ ([65] を参照)。具体的に検証したところ、 絡み合ったノードは決して意見が一致せず、以下で説明する条件下では、無傷のセットのすべてのメンバーが最終的に決定するということです。興味深いことに、検証の結果、 SCPが生存を保証する条件は微妙ですが、 そして当初考えられていたよりも強力です [68]: 以下で説明するように、 意図せずにタイミングを操作する悪意のあるノード プロトコルから逸脱すると、手動で削除する必要がある場合があります クォーラムスライスから。
SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル ロカバら。 証明された特性がすべての可能な状況に当てはまることを確認するため FBA の構成と実行については、任意のものを考慮します。 任意のローカル構成を持つノードの数。これ これには、結合されていないそのままのセットを含むシナリオや、無限に長い実行が発生する可能性のあるシナリオが含まれます。欠点は、私たちが パラメータ化されたパラメータを検証するという困難な問題に直面しています 無限状態システム。 検証を扱いやすくするために、Ivy [69] と [82] の方法論を使用して、一次ロジック (FOL) で SCP をモデル化しました。 検証プロセスは、帰納的推測を手動で提供することで構成され、その後、それが自動的にチェックされます。 アイビー。 SCP の FOL モデルは、SCP のいくつかの側面を要約しています。 FOL での取り扱いが難しい FBA システム（例: カスケード定理を公理として採用します）ので、次を検証します。 Isabelle/HOL [75] を使用した抽象化の健全性。 FOLで検証問題を表現した後、帰納的不変量を与えることで安全性を検証します。帰納的 不変式は、約 10 個の 1 行の推測で構成されます 150 行のプロトコル仕様。次に、Ivy の線形時間論理で SCP の活性プロパティを指定し、 生存性を安全性まで減らす [80, 81] の生存性を減らす 検証問題から帰納法を見つける問題へ 不変。 SCP の安全性は比較的簡単ですが、 証明してください、SCP の生存に関する議論ははるかに複雑であり、 約 150 の単一行の不変式で構成されます。 生きていることを証明するには、 SCP が終了を保証する前提。私たちは当初、無傷のセットをすべて削除した場合に常に終了すると考えていました。 メンバーはスライス [68] から障害のあるノードを削除しました。しかし、これでは不十分であることが判明しました。 完全ではありません) I can のメンバーのクォーラム内のノード。 障害ノードの影響、完了による終了を防止 投票終了直前に定足数に満たないため、 I のメンバーは、次の投票で x の異なる値を選択します。 したがって、非公式には次のように仮定する必要があります。 I のメンバーのクォーラム内の各ノードは、最終的に次のいずれかを実行します。 タイムリーになるか、十分な期間メッセージをまったく送信しません。実際には、これは、I のメンバーが 条件が整うまでスライスを調整する必要があります。これ この問題は FBA システムに固有のものではありません: Losa et al. [47] 現在 活性が厳密に弱いプロトコルに依存するプロトコル スライスから障害のあるノードを削除する必要がなく、最終的には同期が行われ、最終的にはリーダーが選出されると仮定します。
شبكة الدفع
يصف هذا القسم شبكة الدفع الخاصة بـ Stellar، والتي تم تنفيذها كجهاز حالة منسوخ [88] أعلى SCP. 5.1 نموذج دفتر الأستاذ تم تصميم دفتر الأستاذ Stellar حول تجريد الحساب (في على النقيض من مخرجات المعاملات غير المنفقة التي تركز على العملات المعدنية أو UTXO طراز Bitcoin). تتكون محتويات الدفتر من أ مجموعة من إدخالات دفتر الأستاذ من أربعة أنواع متميزة: الحسابات، وخطوط الثقة، العروض وبيانات الحساب. الحسابات هي المديرون الذين يمتلكون الأصول ويصدرونها. كل تتم تسمية الحساب بواسطة مفتاح عام. افتراضيًا، يمكن للمفتاح الخاص المقابل توقيع المعاملات الخاصة بالحساب. ومع ذلك، يمكن إعادة تكوين الحسابات لإضافة موقعين آخرين وإلغاء تخويل المفتاح الذي يُسمي الحساب، باستخدام خيار "multisig" يتطلب عدة موقعين. كل حساب يحتوي أيضًا على: رقم تسلسلي (مدرج في المعاملات لمنع الإعادة)، وبعض الأعلام، ورصيد في “أصلي” عملة مشفرة تم تعدينها مسبقًا تسمى XLM، تهدف إلى التخفيف بعض هجمات حجب الخدمة وتسهيل صناعة السوق كعملة محايدة. تقوم خطوط الثقة بتتبع ملكية الأصول المصدرة، وهي اسمه زوج يتكون من حساب الإصدار وقصير رمز الأصل (على سبيل المثال، "USD" أو "EUR"). يحدد كل خط ثقة حساب، أصل، رصيد الحساب في ذلك الأصل، أ الحد الذي لا يمكن أن يرتفع الميزان فوقه، وبعض الأعلام. يجب أن يوافق الحساب صراحةً على الاحتفاظ بالأصل من خلاله إنشاء خط ثقة، ومنع مرسلي البريد العشوائي من التسلل حسابات ذات أصول غير مرغوب فيها. تتطلب لوائح اعرف عميلك (KYC) من العديد من المؤسسات المالية معرفة الودائع التي تحتفظ بها، على سبيل المثال عن طريق التحقق من بطاقة الهوية التي تحتوي على صورة. للامتثال، يمكن للمصدرين تعيين علامة auth_reqired اختيارية على حساباتهم، مما يقيد ملكية الأصول التي يصدرونها للحسابات المعتمدة. لمنح هذا الترخيص، يقوم المصدر بتعيين معتمد وضع علامة على خطوط ثقة العملاء. تتوافق العروض مع رغبة الحساب في التداول إلى مبلغ معين من أصل معين لآخر في وقت معين السعر في دفتر الطلبات؛ تتم مطابقتها تلقائيًا و يتم ملؤها عندما تتقاطع أسعار الشراء/البيع. وأخيرًا، تتكون بيانات الحساب من الحساب والمفتاح والقيمة الثلاثية، مما يسمح لأصحاب الحساب لنشر قيم البيانات الوصفية الصغيرة. لمنع البريد العشوائي في دفتر الأستاذ، يوجد حد أدنى لرصيد XLM، يسمى الاحتياط. يزداد احتياطي الحساب مع كل منها يرتبط إدخال دفتر الأستاذ ويتناقص عند إدخال دفتر الأستاذ يختفي (على سبيل المثال، عند تنفيذ أمر ما أو إلغاؤه، أو عند أ تم حذف خط الثقة). حاليًا ينمو الاحتياطي بمقدار 0.5 XLM (∼ 0.03 دولار) لكل إدخال في دفتر الأستاذ. بغض النظر عن الاحتياطي، فهو كذلك من الممكن استعادة القيمة الكاملة للحساب عن طريق الحذف مع عملية AccountMerge. يقوم رأس دفتر الأستاذ، الموضح في الشكل 3، بتخزين السمات العامة: رقم دفتر الأستاذ، والمعلمات مثل الرصيد الاحتياطي لكل إدخال دفتر الأستاذ، hash من رأس دفتر الأستاذ السابق (في الواقع عدة hashes تشكل قائمة تخطي)، بما في ذلك إخراج SCP hash من المعاملات الجديدة المطبقة في دفتر الأستاذ هذا، hash من نتائج تلك المعاملات (على سبيل المثال، النجاح أو الفشل ل لكل منهما)، ولقطة hash لجميع إدخالات دفتر الأستاذ. نظرًا لأن اللقطة hash تشتمل على كافة محتويات دفتر الأستاذ، لا يحتاج validators إلى الاحتفاظ بالسجل للتحقق من صحة المعاملات. ومع ذلك، لتوسيع نطاق مئات الملايين من المتوقع الحسابات، لا يمكننا إعادة hash جميع جداول إدخال دفتر الأستاذ في كل منها إغلاق دفتر الأستاذ. علاوة على ذلك، ليس من العملي نقل دفتر الأستاذمدفوعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا دفتر الأستاذ # = 4 H (نطاق عالي الديناميكية السابق) مخرجات SCP ح∗(النتائج) ح∗(لقطة) ... header دفتر الأستاذ # = 5 H (نطاق عالي الديناميكية السابق) مخرجات SCP ح∗(النتائج) ح∗(لقطة) ... header . . . الشكل 3. محتويات دفتر الأستاذ. H هو SHA-256، بينما H ∗ يمثل التطبيق الهرمي أو التكراري لـ H. مخرجات SCP يعتمد أيضًا على الرأس السابق hash. إنشاء حساب إنشاء وتمويل إدخال دفتر الأستاذ الجديد للحساب دمج الحساب حذف إدخال دفتر الأستاذ الحساب خيارات الضبط تغيير علامات الحساب والموقعين الدفع ادفع كمية محددة من الأصول إلى الوجهة. com.acct. مسار الدفع مثل الدفع، ولكن الدفع في أصول مختلفة (ما يصل للحد)؛ حدد ما يصل إلى 5 أصول وسيطة إدارة العرض إنشاء/حذف/تغيير إدخال دفتر الأستاذ للعرض، -العرض السلبي مع متغير سلبي للسماح بانتشار صفر إدارة البيانات إنشاء/حذف/تغيير الحساب. إدخال دفتر البيانات تغيير الثقة إنشاء/حذف/تغيير خط الثقة السماح بالثقة قم بتعيين أو مسح العلامة المعتمدة على خط الثقة BumpSequence زيادة ما يلي. رقم على الحساب الشكل 4. عمليات دفتر الأستاذ الرئيسي بهذا الحجم في كل مرة يتم فيها قطع اتصال العقدة الشبكة لفترة طويلة جدًا. وبالتالي فإن اللقطة hash هي مصمم لتحسين كل من hashing وتسوية الحالة. على وجه التحديد، تقوم اللقطة بتقسيم إدخالات دفتر الأستاذ حسب الوقت التعديل الأخير في مجموعة من الحاويات ذات الحجم المتضاعف تسمى الدلاء. يسمى جمع الدلاء بالدلو القائمة، وتحمل بعض التشابه مع أشجار الدمج المنظمة بالسجل (أشجار-LSM) [77]. لا تتم قراءة قائمة المجموعة أثناء معالجة المعاملات (انظر القسم 5.4). ومن ثم تصميم معين يمكن تخفيف جوانب أشجار LSM. وعلى وجه الخصوص، عشوائية الوصول عن طريق المفتاح غير مطلوب، ولا تتم قراءة الدلاء إلا على الإطلاق بالتتابع كجزء من دمج المستويات. تجزئة الدلو يتم إجراء القائمة عن طريق hashing كل مجموعة أثناء دمجها وحساب تراكمي جديد hash للمجموعة hashes (صغير، الفهرس المرجعي الثابت hashes) عند كل إغلاق لدفتر الأستاذ. تتطلب تسوية قائمة المجموعة بعد قطع الاتصال التنزيل الدلاء فقط التي تختلف. 5.2 نموذج الصفقة تتكون المعاملة من حساب المصدر ومعايير الصلاحية وأ مذكرة، وقائمة واحدة أو أكثر من العمليات. يسرد الشكل 4 العمليات المتاحة. كل عملية لها حساب مصدر، والذي الافتراضيات لتلك الصفقة الشاملة. لا بد من الصفقة يتم توقيعه بواسطة المفاتيح المقابلة لكل حساب مصدر في عملية. يمكن أن تتطلب حسابات Multisig توقيعًا أعلى الوزن لبعض العمليات (مثل SetOptions) وأقل للآخرين (مثلallowTrust). المعاملات ذرية - إذا فشلت أي عملية، فلن يحدث أي منها ينفذون. وهذا يبسط الصفقات متعددة الاتجاهات. لنفترض أن يقوم المُصدر بإنشاء أصل لتمثيل سندات الأرض، ويقوم المستخدم أ يريد استبدال قطعة أرض صغيرة بالإضافة إلى 10000 دولار مقابل أ قطعة أرض أكبر يملكها B. يمكن لكلا المستخدمين التوقيع معاملة واحدة تحتوي على ثلاث عمليات: أرضان المدفوعات ودفع دولار واحد. معيار صلاحية المعاملة الرئيسي هو رقمها التسلسلي، الذي يجب أن يكون أكبر من الرقم التسلسلي للمعاملة. إدخال دفتر الأستاذ حساب المصدر. تنفيذ معاملة صالحة (بنجاح أم لا) يؤدي إلى زيادة الرقم التسلسلي، مما يمنع إعادة التشغيل. تحتوي أرقام التسلسل الأولية على دفتر الأستاذ عدد البتات العالية لمنع إعادة التشغيل حتى بعد الحذف وإعادة إنشاء الحساب. معيار الصلاحية الآخر هو الحد الاختياري للوقت يمكن تنفيذ الصفقة. العودة إلى الأرض والدولار المبادلة أعلاه، إذا قام A بتوقيع المعاملة قبل B، فلا يجوز لـ A ذلك تريد B أن يجلس على المعاملة لمدة عام قبل تقديمها عليه، وبالتالي يمكن وضع حد زمني لإبطال المعاملة بعد بضعة أيام. يمكن أيضًا تكوين حسابات Multisig لإضفاء وزن التوقيع على الكشف عن الصورة المسبقة hash، والتي، إلى جانب الحدود الزمنية، تسمح بالتداول عبر سلسلة ذرية [1]. يدفع الحساب المصدر للمعاملة رسومًا بسيطة بعملة XLM، 10−5 XLM ما لم يكن هناك ازدحام. في ظل الازدحام يتم تحديد تكلفة العمليات عن طريق المزاد الهولندي. المصادقون هم لا يتم تعويضها بالرسوم لأن validators متشابهة إلى Bitcoin العقد الكاملة، وليس عمال المناجم. بدلاً من تدمير XLM، يتم إعادة تدوير الرسوم وتوزيعها بشكل متناسب عن طريق التصويت حاملي XLM الحاليين، والذي قد يكون أو قد يكون في وقت لاحق لم تكن تستحق التعقيد. 5.3 قيم الإجماع بالنسبة لكل دفتر أستاذ، يستخدم Stellar SCP للموافقة على بنية البيانات مع ثلاثة حقول: مجموعة المعاملات hash (بما في ذلك hash) من رأس دفتر الأستاذ السابق)، في وقت قريب، ود ترقيات. عندما يتم تأكيد ترشيح قيم متعددة، يأخذ Stellar المعاملة التي تم تعيينها بأكبر عدد من العمليات (قطع العلاقات بإجمالي الرسوم، ثم مجموعة المعاملات hash)، اتحاد الكل ترقيات، وأعلى وقت إغلاق. وقت قريب هو فقط صالح إذا كان بين وقت إغلاق دفتر الأستاذ الأخير و موجودة، لذلك لا ترشح العقد أوقاتًا غير صالحة. تقوم الترقيات بضبط المعلمات العالمية مثل الرصيد الاحتياطي والحد الأدنى لرسوم التشغيل وإصدار البروتوكول. متى مجتمعة أثناء الترشيح، تحل الرسوم الأعلى وأرقام إصدار البروتوكول محل الأرقام الأقل. ترقيات تأثير الحكم من خلال مساحة صراع التصويت الفيدرالي [34]، ولا مساواة ولا مركزية. تم تكوين كل validator كـ إما الحاكم أو غير الحاكم (الافتراضي)، وفقا إلى ما إذا كان مشغلها يريد المشاركة في الحكم. تعتبر إدارة validators ثلاثة أنواع من الترقية: مطلوب وصالح وغير صالح (أي شيء لا يفعله validator
SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. validator الأساسية الأفق خ.س ديسيبل ديسيبل إرسال العميل العميل validators أخرى الشكل 5. بنية Stellar validator تعرف كيفية التنفيذ). تم تكوين الترقيات المطلوبة ل الزناد في وقت محدد، والمقصود أن يتم التنسيق فيما بينهم مشغلي. العقد الحاكمة تصوت دائمًا للترشيح المرغوب الترقيات، اقبل ولكن لا تصوت لترشيح ترقيات صالحة (أي، وافق على النصاب القانوني المحظور)، ولا تصوت لصالحه أبدًا أو قبول ترقيات غير صالحة. صدى validators غير الحاكم أي تصويت يرونه لترقية صالحة، هو في الأساس تفويض القرار بشأن الترقيات المطلوبة لأولئك الذين يختارون ذلك لدور الحكم. 5.4 التنفيذ يوضح الشكل 5 بنية Stellar validator. شيطان يُسمى Stellar-core (∼ 92 ألف سطر من C ++، دون احتساب مكتبات الطرف الثالث) ينفذ بروتوكول SCP وجهاز الحالة المنسوخ. يتطلب إنتاج قيم SCP تقليل أعداد كبيرة من إدخالات دفتر الأستاذ إلى عمليات تشفير صغيرة hashes. وعلى النقيض من ذلك، التحقق من صحة المعاملة وتنفيذها يتطلب البحث عن حالة الحساب ومطابقة الطلب في أفضل الأسعار. لخدمة كلتا الوظيفتين بكفاءة، نجمي النواة يحتفظ بتمثيلين لدفتر الأستاذ: تمثيل خارجي يحتوي على قائمة الجرافة، المخزنة كملفات ثنائية يمكن تحديثه بكفاءة وإعادة hashed بشكل تدريجي، و تمثيل داخلي في قاعدة بيانات SQL (PostgreSQL لعقد الإنتاج). Stellar- يقوم النواة بإنشاء أرشيف محفوظات للكتابة فقط يحتوي على كل مجموعة معاملات تم تأكيدها ولقطات منها دلاء. يتيح الأرشيف للعقد الجديدة أن تقوم بتمهيد نفسها عند الانضمام إلى الشبكة. كما يوفر سجلا لدفتر الأستاذ التاريخ - يجب أن يكون هناك مكان ما يمكن للمرء البحث عنه الصفقة منذ عامين. منذ التاريخ هو إلحاق فقط ولا يتم الوصول إليه بشكل متكرر، ويمكن الاحتفاظ به في أماكن رخيصة مثل Amazon Glacier أو أي خدمة تسمح بالتخزين واسترجاع الملفات المسطحة. عادةً لا يستضيف مضيفو أداة التحقق أرشيفاتهم الخاصة لتجنب أي تأثير على التحقق من الصحة الأداء من خدمة التاريخ. لإبقاء النواة النجمية بسيطة، فهي غير مخصصة للاستخدام مباشرة عن طريق التطبيقات ولا يعرض سوى واجهة ضيقة جدًا لتقديم المعاملات الجديدة. لدعم العملاء، يقوم معظم validators بتشغيل برنامج خفي يسمى Horizon (∼18k خطوط Go) التي توفر واجهة HTTP للإرسال وتعلم المعاملات . Horizon لديه حق الوصول للقراءة فقط قاعدة بيانات SQL الخاصة بـ stellar-core، مما يقلل من مخاطر الأفق زعزعة الاستقرار النجمي. يتم تنفيذ ميزات مثل العثور على مسار الدفع بالكامل في الأفق ويمكن ترقيتها من جانب واحد دون التنسيق مع validators الأخرى. العديد من البرامج الاختيارية ذات الطبقة العليا هي عملاء للأفق، مما يكمل النظام البيئي. يسهل خادم الجسر تكامل Stellar مع الأنظمة الحالية، على سبيل المثال، نشر إشعارات بجميع المدفوعات المستلمة بواسطة حساب معين. أ يوفر خادم الامتثال خطافات للمؤسسات المالية تبادل واعتماد معلومات المرسل والمستفيد بشأن المدفوعات، للامتثال لقوائم العقوبات. وأخيرا، ينفذ خادم الاتحاد تسمية يمكن قراءتها بواسطة الإنسان نظام للحسابات. 6 تجربة النشر Stellar نمت لعدة سنوات إلى دولة معتدلة عدد مشغلي العقدة الكاملة الموثوقين بشكل معقول. ومع ذلك، كانت تكوينات العقد بحيث تكون الحيوية (وإن لم تكن كذلك). السلامة) تعتمد علينا، مؤسسة Stellar التنمية (قسد)؛ لو اختفت قوات الدفاع الذاتي فجأة، مشغلي العقدة الآخرين كان سيحتاج إلى التدخل وإزالتنا يدويًا من شرائح النصاب القانوني لاستمرار الشبكة. في حين أننا والعديد من الآخرين نريد تقليل الأهمية النظامية لقوات سوريا الديمقراطية، فقد حظي هذا الهدف بأولوية متزايدة بعد ذلك قام الباحثون [58] بقياس ونشر مركزية الشبكة دون التمييز بين المخاطر على السلامة حيوية. كان رد فعل عدد من المشغلين هو إجراء تعديلات التكوين النشطة، مما أدى في المقام الأول إلى زيادة حجم طائراتهم شرائح النصاب القانوني في محاولة لتخفيف أهمية قوات سوريا الديمقراطية؛ ومن المفارقات أن هذا أدى فقط إلى زيادة المخاطر على الحيوية. مشكلتان أدت إلى تفاقم الوضع. أولا شعبية تم استخدام أداة مراقبة Stellar التابعة لجهة خارجية [5] بشكل منهجي المبالغة في تقدير وقت تشغيل validator من خلال عدم التحقق فعليًا كان ذلك النواة النجمية يعمل؛ هذا يقود الناس إلى تضمين العقد غير الموثوقة في شرائح النصاب القانوني الخاصة بهم. ثانياً: خطأ في يُقصد بالنواة النجمية بمجرد انتقال validator إلى دفتر الأستاذ التالي، لم يساعد العقد المتبقية بشكل كافٍ في إكمال العقد السابقدفتر الأستاذ في حالة فقدان الرسائل. ونتيجة لذلك، شهدت الشبكة 67 دقيقة من التوقف وكانت مطلوبة التنسيق اليدوي بواسطة مسؤولي validator لإعادة التشغيل. والأسوأ من ذلك، أثناء محاولة إعادة تشغيل الشبكة، أدت عمليات إعادة التكوين السريعة المتزامنة على عقد متعددة في تكوين خاطئ جماعي سمح لبعض العقد بذلك تتباعد، مما يتطلب الإغلاق اليدوي لتلك العقد و إعادة تقديم المعاملات المقبولة أثناء الاختلاف. ولحسن الحظ، تم اكتشاف هذا الاختلاف وتصحيحه بسرعة ولم تحتوي على أي معاملات متضاربة، ولكن خطر فشل الشبكة في التمتع بتقاطع النصاب القانوني— الانقسام مع الاستمرار في قبول التضارب المحتمل المعاملات، وذلك ببساطة بسبب التكوين الخاطئ ملموسة جدا من هذا الحادث. أدت مراجعة هذه التجارب إلى استنتاجين رئيسيين والإجراءات التصحيحية المقابلة.مدفوعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا حرجة 100% 51% 51% عالية 67% 51% متوسطة 67% 51% منخفض، 67% 51% 51% ... ... ... 51% ... 51% الشكل 6. التسلسل الهرمي لجودة المدقق. أعلى جودة العقد تتطلب الحد الأعلى وهو 100%، في حين يتم ضبط الجودة الأدنى على عتبة 67%. العقد داخل واحدة تتطلب المنظمة أغلبية بسيطة بنسبة 51٪. 6.1 تعقيد التكوين وهشاشته Stellar يعبر عن شرائح النصاب كمجموعات نصاب متداخلة تتكون من n إدخالات وعتبة k حيث توجد أي مجموعة من إدخالات k يشكل شريحة النصاب القانوني. كل من الإدخالات n هو إما validator مفتاح عام أو، بشكل متكرر، مجموعة نصاب أخرى. وعلى الرغم من مرونتنا وصغر حجمنا، فقد حققنا النصاب القانوني المتداخل أتاحت المجموعات في الوقت نفسه لمشغلي العقد مرونة كبيرة جدًا وقليلًا جدًا من التوجيه: كان من السهل كتابة ملفات غير آمنة (أو حتى لا معنى لها) التكوينات. معايير التجميع العقد إلى مجموعات، لتنظيم المجموعات الفرعية في تسلسل هرمي، و لاختيار العتبات كلها كانت غير واضحة بما فيه الكفاية وساهمت في الفشل التشغيلي. ولم يكن من الواضح ما إذا كان الأمر كذلك التعامل مع "المستوى" في التسلسل الهرمي المتداخل كمستوى ثقة، أو منظمة، أو كليهما؛ العديد من التكوينات في هذا المجال اختلطت هذه المفاهيم، بالإضافة إلى تحديد الخطورة أو عتبات لا معنى لها. ولذلك أضفنا آلية تكوين أبسط الذي يفصل بين جانبين من مجموعات النصاب المتداخلة: التجميع العقد معًا حسب المؤسسة، وتصنيف كل مؤسسة بتصنيف ثقة بسيط (منخفض، متوسط، مرتفع، أو حرجة). مطلوب من المنظمات ذات المستوى الأعلى وما فوق ذلك نشر أرشيف التاريخ. يقوم النظام الجديد بتجميع مجموعات النصاب المتداخلة التي يتم فيها تمثيل كل مؤسسة كـ تم تحديد عتبة 51%، ويتم تجميع المنظمات في مجموعات بحدود 67% أو 100% (حسب جودة المجموعة). كل مجموعة عبارة عن إدخال واحد في المجموعة التالية (الأعلى جودة)، كما هو موضح في الشكل 6. هذا النموذج المبسط يقلل من احتمالية التكوين الخاطئ، سواء من حيث الهيكل من المجموعات المتداخلة المركبة والعتبات المختارة كل مجموعة. 6.2 الكشف الاستباقي عن التكوين الخاطئ ثانياً، أدركنا أن اكتشاف سوء التشكيل الجماعي من خلال الانتظار لملاحظة آثاره السلبية قد فات الأوان. خاصة فيما يتعلق بالتكوينات الخاطئة التي يمكن أن تتباعد — أ وضع فشل أكثر خطورة من التوقف — احتياجات الشبكة لتكون قادرًا على اكتشاف التكوين الخاطئ على الفور حتى يتمكن المشغلون من التراجع عنه قبل حدوث أي اختلاف فعليًا. لتلبية هذه الحاجة، قمنا ببناء آلية في برنامج validator تعمل بشكل مستمر على جمع حالة التكوين الجماعية لجميع النظراء في الإغلاق المتعدي للعقدة وتكتشف احتمالية الاختلاف، أي الانفصال النصاب القانوني – ضمن هذا التكوين الجماعي. 6.2.1 التحقق من تقاطع النصاب القانوني على الرغم من أن جمع شرائح النصاب أمر سهل، إلا أن العثور على النصاب المنفصل فيما بينها يعد أمرًا صعبًا [62]. ومع ذلك، اعتمدنا مجموعة من الاستدلالات الخوارزمية وقواعد حذف الحالات اقترحه Lachowski [62] للتحقق من الحالات النموذجية من المشكلة عدة أوامر من حيث الحجم أسرع من تكلفة أسوأ الحالات. من الناحية العملية، الشبكة الحالية تكون عمليات الإغلاق الانتقالية لشريحة النصاب في حدود 20-30 العقد، وباستخدام تحسينات Lachowski، يتم التحقق عادةً في غضون ثوان على وحدة المعالجة المركزية واحدة. إذا دعت الحاجة لتعزيز الأداء، يمكننا موازاة البحث. 6.2.2 التحقق من التكوينات الخطرة يعد اكتشاف أن الشبكة تقبل النصاب القانوني المنفصل بمثابة خطوة في الاتجاه الصحيح، لكنه يشير إلى الخطر في وقت متأخر بشكل غير مريح لمثل هذه القضية الحرجة. من الناحية المثالية، نريد أن يتلقى مشغلو العقد تحذيرات عند التكوين الجماعي للشبكة يقترب فقط من حالة محفوفة بالمخاطر. ولذلك قمنا بتوسيع مدقق تقاطع النصاب القانوني للكشف عن حالة نسميها الحرجية: عندما يكون التيار التكوين الجماعي هو تكوين خاطئ واحد بعيدا عن دولة تقبل النصاب القانوني المنفصل. للكشف عن الأهمية، يقوم المدقق باستبدال تكوين كل مؤسسة بشكل متكرر بمحاكاة تكوين خاطئ لأسوأ الحالات إعادة تشغيل مدقق تقاطع النصاب الداخلي على النتيجة. في حالة وجود أي خطأ فادح في التكوين على بعد خطوة واحدة من الحالة الحالية، يصدر البرنامج تحذيرًا و تقارير المنظمة التي تشكل خطر التكوين الخاطئ. تمنح هذه التغييرات مجتمع المشغلين طبقتين من الإشعار والتوجيه للعزل ضد أسوأ الأشكال من سوء التكوين الجماعي
決済ネットワーク
このセクションでは、SCP 上に複製されたステート マシン [88] として実装された Stellar の支払いネットワークについて説明します。 5.1 台帳モデル Stellar の台帳は、アカウントの抽象化を中心に設計されています ( よりコイン中心の未使用トランザクション出力とは対照的です または Bitcoin の UTXO モデル)。台帳の内容は次のもので構成されます。 アカウント、トラストライン、 オファー、およびアカウントデータ。 アカウントは、資産を所有および発行する主体です。それぞれ アカウントは公開キーによって名前が付けられます。デフォルトでは、対応する秘密キーでアカウントのトランザクションに署名できます。 ただし、アカウントを再構成して、他の署名者を追加し、アカウントに名前を付けるキーの認証を解除することはできます。 複数の署名者を必要とする「multisig」オプション。各アカウント シーケンス番号 (トランザクションに含まれる) も含まれます。 リプレイを防ぐため）、いくつかのフラグ、および「ネイティブ」のバランス XLM と呼ばれる、事前に採掘された仮想通貨で、被害を軽減することを目的としています。 一部のサービス拒否攻撃を防止し、市場形成を促進します 中立通貨として。 トラストラインは、発行された資産の所有権を追跡します。 発行アカウントと短いアカウントからなるペアで名前が付けられます。 資産コード (例: 「USD」または「EUR」)。各トラストラインは次のように指定します 口座、資産、その資産の口座残高、 それを超えると残高が上昇できない制限と、いくつかのフラグ。 アカウントは、次の方法で資産の保有に明示的に同意する必要があります。 トラストラインを作成し、スパマーのサドルを防止します 不要な資産を含むアカウント。 顧客確認 (KYC) 規制により、多くの金融機関は誰の預金を保有しているかを把握する必要があります。 たとえば写真付き身分証明書を確認することによって。準拠するために、発行者は設定できます アカウントにオプションの auth_reqired フラグを設定し、発行するアセットの所有権を承認されたアカウントに制限します。 このような認可を与えるために、発行者は認可された権限を設定します。 顧客のトラストラインにフラグを立てます。 オファーはアカウントの取引意欲に対応します 特定の資産の一定量を、特定の時点で別の資産に割り当てる 注文簿上の価格。それらは自動的に照合され、 買値と売値がクロスすると約定します。最後に、アカウント データはアカウント、キー、値の 3 つの組み合わせで構成され、アカウント所有者が許可します。 小さなメタデータ値を公開します。 台帳スパムを防ぐために、最小 XLM 残高があり、 予備と呼ばれます。アカウントの準備金は毎回増加します 関連する元帳エントリと元帳エントリが減少すると減少します 消える（注文が約定またはキャンセルされたとき、または注文が完了したときなど） トラストラインは削除されます）。現在、リザーブは 0.5 XLM 増加します 台帳エントリごとに (〜$0.03)。予備力とは関係なく、 アカウントを削除することで、アカウントの価値全体を取り戻すことが可能 AccountMerge オペレーションを使用してこれを実行します。 図 3 に示すレジャー ヘッダーには、グローバル属性が保存されます。 元帳番号、毎の準備金残高などのパラメータ 元帳エントリ、前の元帳ヘッダーの hash (実際には スキップリストを形成するいくつかの hashes)、SCP 出力には以下が含まれます この台帳に適用された新しいトランザクションの hash、 の hash それらのトランザクションの結果 (例: トランザクションの成功または失敗) それぞれ）、およびすべての台帳エントリのスナップショット hash。 スナップショット hash には元帳のすべての内容が含まれているため、 validator は、トランザクションを検証するために履歴を保持する必要はありません。 ただし、予想される数億件にスケールするには アカウントの場合、すべての台帳エントリ テーブルをhash 再設定することはできません。 帳簿を閉じます。また、台帳を移転することは現実的ではありませんStellar による高速かつ安全なグローバル支払い SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル 元帳番号 = 4 H(前のHDR) SCP出力 H(結果) H∗(スナップショット) ... ヘッダー 元帳番号 = 5 H(前のHDR) SCP出力 H(結果) H∗(スナップショット) ... ヘッダー 。 。 。 図 3. 元帳の内容。 H は SHA-256 ですが、H ∗ は H の階層的または再帰的適用を表します。 SCP 出力 前のヘッダー hash にも依存します。 アカウントの作成 新しい口座元帳エントリを作成して資金を投入する アカウントマージ 勘定科目元帳エントリの削除 オプションの設定 アカウントフラグと署名者を変更する お支払い 特定の量の資産を宛先に支払います。アカウント。 パス支払い Payment と同様ですが、別の資産で支払います (上 制限する);最大 5 つの中間資産を指定します オファーの管理 オファー台帳エントリの作成/削除/変更、 -パッシブオファー ゼロスプレッドを可能にするパッシブバリアントを使用 データの管理 アカウントの作成/削除/変更。データ台帳の入力 チェンジトラスト トラストラインの作成/削除/変更 信頼を許可する トラストラインで承認済みフラグを設定またはクリアする バンプシーケンス シーケンスを増加します。アカウントの番号 図 4. 主な台帳操作 ノードが切断されるたびにそのサイズの ネットワークが長すぎます。したがって、スナップショット hash は次のようになります。 hashing と状態調整の両方を最適化するように設計されています。 具体的には、スナップショットは台帳エントリを時間ごとに階層化します。 指数関数的にサイズが大きいコンテナのセットにおける最後の変更の内容 バケットと呼ばれます。バケットの集合はバケットと呼ばれます リストであり、ログ構造のマージツリーとある程度の類似点があります。 (LSM ツリー) [77]。バケット リストはトランザクション処理中に読み取られません (セクション 5.4 を参照)。したがって、特定のデザイン LSM ツリーの側面を緩和することができます。特にランダム キーによるアクセスは必要なく、バケットは読み取られるだけです レベルの結合の一部として順次。バケットのハッシュ化 リストは、マージされる各バケットを hash し、バケット hashes (小さい、 元帳が閉じるたびに参照の固定インデックス hashes)。切断後にバケット リストを調整するにはダウンロードが必要です バケットのみが異なります。 5.2 トランザクションモデル トランザクションは、ソースアカウント、有効性基準、 メモ、および 1 つ以上の操作のリスト。図 4 に、利用可能な操作を示します。各操作にはソース アカウントがあり、 デフォルトはトランザクション全体のデフォルトです。トランザクションは次のことを行う必要があります すべてのソースアカウントに対応するキーで署名されること 手術。マルチシグアカウントではより高度な署名が必要になる場合があります 一部の操作 (SetOptions など) の重み以下 他のもの (AllowTrust など)。 トランザクションはアトミックです。いずれかの操作が失敗した場合、いずれの操作も失敗しません。 彼らは実行します。これにより、多方向の取引が簡素化されます。仮に 発行者は土地権利書を表す資産を作成し、ユーザー A 小さな土地区画と10,000ドルを交換したい B が所有するより大きな土地区画。2 人のユーザーは両方とも署名できます。 3 つの操作を含む 1 つのトランザクション: 2 つのランド 支払いと1ドルの支払い。 トランザクションの主な有効性基準はシーケンス番号であり、これはトランザクションのシーケンス番号より 1 大きい必要があります。 ソースアカウント元帳エントリ。有効なトランザクションの実行 (成功したかどうかに関係なく) シーケンス番号がインクリメントされ、再生が防止されます。初期シーケンス番号には元帳が含まれます 削除した後でも再生を防ぐための上位ビットの数値 そしてアカウントを再作成します。 もう 1 つの有効性基準は、次の場合に関するオプションの制限です。 トランザクションを実行できます。土地とドルへの回帰 上記のスワップでは、A が B より先にトランザクションに署名した場合、A は署名できない可能性があります B が提出する前に 1 年間取引を続けてほしい そのため、トランザクションを無効にする時間制限が設けられる可能性があります 数日後。マルチシグアカウントも設定可能 hash プレイメージの暴露に署名の重要性を与えるため、 これと時間制限を組み合わせることで、アトミックなクロスチェーン取引 [1] が可能になります。 トランザクションのソースアカウントは、XLM でわずかな手数料を支払います。 輻輳がない場合は 10−5 XLM。混雑時には、 運営コストはオランダのオークションによって設定されます。バリデーターは validator は類似しているため、料金による補償はありません マイナーではなく、Bitcoin フルノードに。 XLMを破壊するのではなく、 料金は再利用され、投票によって比例配分されます。 既存の XLM ホルダー、振り返ってみると、 複雑さの価値はありませんでした。 5.3 コンセンサス値 各台帳について、Stellar は SCP を使用してデータ構造に同意します 3 つのフィールド: トランザクション セット hash (hash を含む) 前の元帳ヘッダーの）、終了時間、d アップグレード。 複数の値がノミネートされていることが確認された場合、Stellar はかかります 最も多くの操作を含むトランザクション セット (関係を破る) 合計手数料、次にトランザクション セット hash)、すべての和集合 アップグレード、および最高の終了時間。閉店時間はあくまで 最後の元帳の終了時刻と次の時刻の間の場合に有効です。 存在するため、ノードは無効な時間を指定しません。 アップグレードでは、リザーブ残高、最低運用料金、プロトコル バージョンなどのグローバル パラメーターが調整されます。いつ 指名中に組み合わせた場合、高い料金とプロトコルのバージョン番号が低い料金とプロトコルのバージョン番号に優先します。アップグレードは、連合投票による争奪スペース [34] を通じてガバナンスに影響を与えますが、どちらでもありません 平等主義でも中央集権主義でもありません。各 validator は次のように構成されます 応じて、統治または非統治（デフォルト）のいずれか 運営者がガバナンスに参加したいかどうか。 validator を管理する場合は、次の 3 種類のアップグレードを検討します。 望ましい、有効、および無効 (validator に含まれないもの)
SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル ロカバら。 validator コア 地平線 FS DB DB 提出する クライアント クライアント その他のvalidator 図 5. Stellar validator アーキテクチャ 実装方法を知っています）。必要なアップグレードは次のように構成されています 特定の時間にトリガーし、相互に調整することを目的としています。 オペレーター。統治ノードは常に投票して希望するノードを指名します アップグレード、受け入れますが、有効なアップグレードを推薦するために投票はしません (つまり、ブロッキング定足数に従う)、決して投票しないでください。 または無効なアップグレードを受け入れます。非政府validatorのエコー 有効なアップグレードに対する投票、つまり本質的に委任 アップグレードを選択する人がどのようなアップグレードを希望するかについての決定 ガバナンスの役割のために。 5.4 実装 図 5 は、Stellar の validator アーキテクチャを示しています。デーモン stellar-core (約 92k 行の C++、サードパーティ ライブラリを除く) と呼ばれる SCP プロトコルと複製されたステート マシンを実装します。 SCP の値を生成するには、多数の台帳エントリを小さな暗号化に削減する必要があります。 hashes。対照的に、トランザクションの検証と実行 アカウントの状態と注文の照合を検索する必要があります。 最高の価格。両方の機能を効率的に提供するには、ステラコア 台帳の 2 つの表現を保持します。1 つはバケット リストを含む外部表現で、バイナリ ファイルとして保存されます。 効率的に更新し、段階的に再hashすることができます。 SQL データベースの内部表現 (PostgreSQL) 実稼働ノードの場合)。 Stellar-core は、次の内容を含む書き込み専用の履歴アーカイブを作成します。 確認された各トランザクションセットとそのスナップショット バケツ。アーカイブにより、新しいノードが自らブートストラップできるようになります ネットワークに参加するとき。台帳の記録も提供します 歴史 - 歴史を調べることができる場所が必要です ２年前の取引です。履歴は追加専用なので アクセス頻度が低いため、安価な場所に保管できます Amazon Glacier または保存できるサービスなど フラット ファイルを取得します。バリデーターホストは通常、ホストをホストしません。 検証への影響を避けるために独自のアーカイブを作成する 配信履歴からのパフォーマンス。 Stellar-Core をシンプルに保つため、使用することは意図されていません。 アプリケーションによって直接実行され、新しいトランザクションを送信するための非常に狭いインターフェイスのみが公開されます。サポートする クライアントでは、ほとんどの validator が Horizon と呼ばれるデーモンを実行します (〜18k Go の行) を送信するための HTTP インターフェイスを提供します そして取引の学習。 Horizon には読み取り専用アクセス権があります stellar-core の SQL データベース、ホライズンのリスクを最小限に抑える 不安定化する恒星の核。支払い経路検索などの機能はすべて Horizon 内に実装されており、アップグレード可能です 他のvalidatorと調整せずに一方的に。 いくつかのオプションの上位層デーモンがクライアントとなり、エコシステムを完成させます。ブリッジサーバーにより、 Stellar と既存のシステムの統合 (例: 特定のアカウントで受け取ったすべての支払いの通知を投稿する)。あ コンプライアンス サーバーは金融機関にフックを提供します。 送金者と受取人の情報を交換し、承認する 支払いに関して、制裁リストの順守のために。最後に、 フェデレーション サーバーは人間が判読できる名前を実装します。 アカウントのシステム。 6 導入経験 Stellar は数年間で中程度の状態に成長しました 適度に信頼できるフルノードオペレーターの数。ただし、 ノードの構成は、活性を維持するようなものでした（ただし、 安全性) 私たち、Stellar 開発財団に依存していました (自衛隊); SDF が突然失踪した場合、他のノード運営者は 介入して手動で私たちを削除する必要があったでしょう ネットワークを継続するにはクォーラム スライスから削除します。 私たちや他の多くの人々は、SDF の組織的重要性を軽減したいと考えていますが、この目標はその後、ますます優先されるようになりました。 研究者 [58] は、安全性とリスクを区別することなく、ネットワークの集中化を定量化し、公表しました。 活気。多くの通信事業者は積極的な設定調整に対応し、主に通信事業者のサイズを拡大しました。 SDF の重要性を薄めるために定足数を削減する。皮肉なことに、これは生命へのリスクを増大させるだけでした。 2 つの問題が状況を悪化させました。まずは人気の サードパーティの Stellar 監視ツール [5] が体系的に 実際に検証していないため、validator 稼働時間を過大評価しています その恒星コアが稼働していました。これにより、人々は次のことを含めるようになります クォーラム スライス内の信頼性の低いノード。 2番目に、バグです。 ステラコアとは、validator が次の台帳に移動すると、 残りのノードが previ を完了するのに十分に役立ちませんでしたメッセージが失われた場合の台帳。その結果、 ネットワークで 67 分間のダウンタイムが発生し、必要なダウンタイムが発生しました validator 管理者による手動調整で再起動してください。 さらに悪いことに、ネットワークを再起動しようとしているときに、複数のノードで同時に急いで再構成が行われてしまいました。 集団的な構成ミスにより、一部のノードが 分岐すると、それらのノードを手動でシャットダウンする必要があり、 乖離中に受け入れられたトランザクションの再送信。幸いなことに、この相違は発見され、修正されました 迅速に処理され、競合するトランザクションは含まれていませんでしたが、 ネットワークがクォーラム交差を享受できないリスク - 潜在的に矛盾するものを受け入れ続けながら分割する 単に設定ミスによりトランザクションが実行されました この出来事によって、非常に具体的なことが分かりました。 これらの経験を検討すると、2 つの主要な結論が得られました。 および対応する是正措置。Stellar による高速かつ安全なグローバル支払い SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル クリティカル、100% 51% 51% 高、67% 51% 中、67% 51% 低い、67% 51% 51% ... ... ... 51% ... 51% 図 6. バリデータの品質階層。最高品質のノード 最高のしきい値 100% が必要ですが、それより低い品質は 67% のしきい値に設定されます。単一内のノード 組織には単純に 51% の過半数が必要です。 6.1 構成の複雑さと脆弱性 Stellar は、クォーラム スライスを、n 個のエントリとしきい値 k で構成されるネストされたクォーラム セットとして表現します。ここで、k 個のエントリのセットはどれも同じです。 クォーラム スライスを構成します。 n 個のエントリはそれぞれ次のいずれかになります。 validator 公開キー、または再帰的に別のクォーラム セット。 柔軟かつコンパクトでありながら、ネストされたクォーラムを実現 セットは同時にノード演算子に柔軟性を与えすぎ、ガイダンスが少なすぎるため、安全でない (または たとえ無意味な構成であっても。グループ化の基準 ノードをセットに分割し、サブセットを階層に編成します。 しきい値の選択についてはすべて明確さが不十分であり、運用上の失敗の一因となっていました。するかどうかは不明 ネストされたセット階層内の「レベル」を信頼のレベルとして扱います。 または組織、またはその両方。現場での多くの構成 危険性を特定することに加えて、これらの概念を混合しました。 または無意味なしきい値。 したがって、より単純な構成メカニズムを追加しました。 これは、ネストされたクォーラム セットの 2 つの側面を分離します: グループ化 ノードを組織ごとにまとめ、各組織に単純な信頼分類 (低、中、高、または クリティカル)。高位以上の組織には、次のことが求められます。 歴史アーカイブを公開します。新しいシステムは、各組織が 51% のしきい値が設定され、組織はセットにグループ化されます 67% または 100% のしきい値 (グループの品質に応じて)。 各グループは、次の (高品質) グループの 1 つのエントリです。 図 6 に示すように、この単純化されたモデルにより、 構造の両方の点で構成ミスが発生する可能性 合成されたネストされたセットと選択されたしきい値の 各セット。 6.2 構成ミスのプロアクティブな検出 第 2 に、悪影響を観察するのを待って集団的な設定ミスを検出するのでは遅すぎることに気づきました。特に、分岐する可能性のある構成ミスに関しては、 停止よりも深刻な障害モード - ネットワークが必要とする 構成ミスを即座に検出できるため、オペレーターは実際に相違が発生する前に構成を元に戻すことができます。 このニーズに対処するために、ノードの推移閉包内のすべてのピアの集合的な構成状態を継続的に収集し、発散の可能性、つまり素性を検出するメカニズムを validator ソフトウェアに組み込みました。 クォーラム - その集合的な構成内。 6.2.1 クォーラム交差のチェック クォーラム スライスを収集するのは簡単ですが、それらの間で互いに素なクォーラムを見つけるのは、NP にとって非常に困難です [62]。ただし、私たちが採用したのは、 一連のアルゴリズムヒューリスティックと大文字小文字の区別ルール Lachowski [62] によって提案された、典型的なインスタンスをチェックする 問題の解決は、 最悪の場合のコスト。実際的に言えば、現在のネットワークは クォーラム スライスの推移的クロージャは 20 ～ 30 程度です ノードを作成し、Lachowski の最適化を使用して、通常は次のチェックを行います。 単一の CPU 上で数秒で完了します。必要が生じた場合 パフォーマンスを向上させるために、検索を並列化する場合があります。 6.2.2 危険な構成のチェック ネットワークが素のクォーラムを許可していることを検出することがステップです 正しい方向に進んでいるが、危険を知らせるのが不快なほど遅い このような重大な問題に対して。理想的には、ネットワークの集合的な設定が行われたときにノード オペレータが警告を受け取るようにしたいと考えています。 単に危険な状態に近づいているだけです。 したがって、クォーラム交差チェッカーを拡張しました。 臨界と呼ばれる状態を検出するには、現在の状態が 集合的な設定は、設定ミスが 1 つあるだけです バラバラな定足数を認める州。重大度を検出するには、 チェッカーは、各組織の構成を、シミュレートされた最悪の構成ミスに繰り返し置き換えます。 結果に対して内部クォーラム交差チェッカーを再実行します。 このような重大な構成ミスが一歩手前に存在する場合 現在の状態から、ソフトウェアは警告を発行し、 組織が構成ミスのリスクを引き起こしていると報告しています。 これらの変更により、オペレーターのコミュニティに 2 つの層が与えられます。 最悪の事態を防ぐための通知と指導 集団的な設定ミス。
تقييم
لفهم مدى ملاءمة Stellar كدفعة عالمية و شبكة التداول، قمنا بتقييم حالة الشبكة العامة وأجرى تجارب مضبوطة على تجربة خاصة شبكة. ركزنا على الأسئلة التالية: • كيف تبدو طوبولوجيا شبكة الإنتاج؟ كم عدد الرسائل التي يتم بثها في المتوسط، و كيف يواجه SCP المهلات؟ • هل يظل زمن الاستجابة لتحديث الإجماع ودفتر الأستاذ مستقلاً عن عدد الحسابات؟SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. • كيف تتأثر فترات الاستجابة بزيادة (أ) المعاملات في الثانية (وبالتالي المعاملات في كل ثانية). دفتر الأستاذ)، و(ب) عدد العقد validator؟ • ما هي تكلفة تشغيل العقدة من حيث وحدة المعالجة المركزية، الذاكرة وعرض النطاق الترددي للشبكة؟ تتمتع شبكات الدفع بمعدلات معاملات منخفضة مقارنة إلى أنواع أخرى من النظام الموزع. الرائدة blockchains، Bitcoin وEthereum، تأكيد ما يصل إلى 15 معاملة في الثانية، أقل من Stellar. علاوة على ذلك، تستغرق هذه الأنظمة دقائق ساعة لتأكيد المعاملة بشكل آمن، لأن إثبات العمل يتطلب الانتظار حتى يتم تعدين عدة كتل. ال بلغ متوسط شبكة غير blockchain SWIFT 420 معاملة في الثانية فقط في يوم الذروة [14]. لذلك اخترنا لمقارنة قياساتنا مع هدف الـ 5 ثواني الفاصل الزمني دفتر الأستاذ، وهو هدف أكثر عدوانية. تظهر نتائجنا أن زمن الوصول أقل من هذا الحد بشكل مريح حتى مع العديد من التحسينات غير المنفذة لا تزال قيد التنفيذ. 7.1 المراسي تشمل الأصول الأكثر تداولًا من حيث الحجم العملة (على سبيل المثال، 3 دولارات أمريكية المرساة، 2 يوان صيني)، المرساة Bitcoin، والأمان المدعوم بالعقارات token [92]، والعملة داخل التطبيق [8]. المراسي المختلفة لها سياسات مختلفة. على سبيل المثال، مرساة واحدة بالدولار الأمريكي، Stronghold، يقوم بتعيين auth_reqired ويتطلب عملية معرفة عميلك (KYC) لكل حساب يحتفظ به الأصول. آخر، AnchorUSD، يتيح لأي شخص الاستلام والتداول الدولار الأمريكي (مما يجعل من الممكن حرفيًا إرسال 0.50 دولارًا إلى المكسيك في 5 ثواني برسوم قدرها 0.000001 دولار). ومع ذلك، مرساةUSD يتطلب KYC ورسومًا لشراء أو استرداد الدولار الأمريكي مع التحويلات البرقية التقليدية. في الفلبين حيث تعتبر اللوائح المصرفية أكثر مرونة فيما يتعلق بالمدفوعات الواردة، والعملات المعدنية يدعم صرف PHP من أي ماكينة صراف آلي [36]. بالإضافة إلى الأمان المذكور أعلاه token والعملة داخل التطبيق، هناك مجموعة من العملات غير token تتراوح من السندات التجارية [22] وأرصدة الكربون [85، 96] وأكثر الأصول الباطنية مثل token التحفيز التعاوني استعادة ملكية السيارة [35]. 7.2 شبكة عامة حتى كتابة هذه السطور، هناك 126 عقدة كاملة نشطة، 66 منها المشاركة في الإجماع من خلال التوقيع على رسائل التصويت. الشكل 7 (تم إنشاؤه بواسطة [5]) يصور الشبكة، مع وجود خط بينهما عقدتان إذا ظهرت إحداهما في شرائح النصاب القانوني للأخرى و أ خط أزرق غامق لإظهار الاعتماد ثنائي الاتجاه. في المركز عبارة عن مجموعة من 17 "المستوى الأول validators" بحكم الأمر الواقع يديرها SDF، وSatoshiPay، وLOBSTR، وCOINQVEST، وKeybase. قبل أربعة أشهر، قبل أحداث القسم السادس، هناك كانت هناك 15 عقدة ذات أهمية نظامية: 3 منها على ما يبدو منظمات من المستوى الأول والعديد من المفردات العشوائية. ال بدا الرسم البياني أيضًا أقل انتظامًا. ومن ثم، تظهر آلية التكوين الجديدة و/أو قرارات المشغل الأفضل للمساهمة في طوبولوجيا الشبكة الأكثر صحة. بدون موارد مالية كبيرة (والمساهمين المقابلين الشكل 7. خريطة شريحة النصاب القانوني الالتزامات)، كان من الصعب تعيين 5 الطبقة الأولى لكن المنظمات منذ البداية. وهذا يشير إلى النصاب القانوني تلعب الشرائح دورًا مفيدًا في تمهيد الشبكة: يمكن لأي شخص ذلك انضم بهدف أن تصبح لاعبًا مهمًا بسبب لا يوجد حراس على الاتفاق الزوجي. يوجد حاليًا أكثر من 3.3 مليون حساب في دفتر الأستاذ. انتهى خلال فترة 24 ساعة الأخيرة، بلغ متوسط Stellar 4.5 معاملة و 15.7 عملية في الثانية. مراجعة دفاتر الأستاذ الأخيرة، أكثر يبدو أن المعاملات لديها عملية واحدة، في حين أن كل عدد قليل دفاتر الأستاذ نرى المعاملات التي تحتوي على العديد من العمليات التي يبدو أنها تأتي من صانعي السوق الذين يديرون العروض. ال متوسط الأوقات لتحقيق الإجماع وتحديث دفتر الأستاذ كان 1061 مللي ثانية و 46 مللي ثانية على التوالي. وكانت النسب المئوية 99 2252 مللي ثانية و142 مللي ثانية (يعكس الأول مهلة مدتها ثانية واحدة في اختيار زعيم الترشيح). لاحظ أن أداء SCP هو معظمها مستقلة عن المعاملات في الثانية الواحدة، منذ SCP يوافق على hash من العديد من المعاملات بشكل تعسفي. من المرجح أن تنشأ الاختناقات من نشر المرشح المعاملات أثناء الترشيح والتنفيذ والمصادقة المعاملات، ودمج الدلاء. لم نحتاج بعد لموازاة معالجة المعاملات الخاصة بـ Stellar-core عبر عدة مراكز لوحدة المعالجة المركزية أو محركات الأقراص. قمنا أيضًا بتقييم عدد رسائل SCP التي يتم بثها على شبكة الإنتاج. في الحالة العادية مع واحد الزعيم المنتخب لترشيح قيمة، نتوقع سبعة منطقية الرسائل التي سيتم بثها: رسالتان للتصويت والقبول نوميبيان نيت، رسالتين للقبول والتأكيد بيان إعداد، رسالتين للقبول والتأكيد بيان الالتزام، وأخيرا، رسالة خارجية (تم إرساله بعد الالتزام بدفتر أستاذ جديد على القرص لمساعدة المتطرفين اللحاق). يجمع التنفيذ بين تأكيد الالتزام وإضفاء الطابع الخارجي على الرسائل كتحسين، لأنه كذلك من الآمن إضفاء الطابع الخارجي على القيمة بعد الالتزام بها. نقوم بعد ذلك بتحليل المقاييس المجمعة على الإنتاج Stellar validator. انتهى على مدار 68 ساعة، تم بث 1.3 رسالة في الثانية، بمتوسط 6-7 رسائل لكل دفتر. ونلاحظ أن المجموع
مدفوعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا المئوي عدد المهلات الترشيح الاقتراع 75% 0 0 99% 1 0 ماكس 4 1 الشكل 8. المهلة لكل دفتر الأستاذ أكثر من 68 ساعة عدد الرسائل التي يتم بثها بواسطة validators أكبر، منذ عام بالإضافة إلى رسائل التصويت الموحد، يتم أيضًا بث العقد أي معاملات يتعلمون عنها. ويبين الشكل 8 المهلات التي يمر بها الإنتاج validator خلال فترة 68 ساعة. مهلة الترشيح هي وهو مقياس لمدى (عدم) فعالية وظيفة انتخاب القائد، في حين أن مهلة الاقتراع تعتمد بشكل كبير على الشبكة والتأخير المحتمل للرسائل. المهلات متسقة مع عدد الرسائل المرسلة: ستة رسائل في أفضل السيناريوهات، وسبع رسائل على الأقل إذا كانت هناك حاجة إلى جولة ترشيح إضافية. 7.3 التجارب الخاضعة للرقابة أجرينا تجارب مضبوطة في حاويات معبأة مثيلات Amazon EC2 c5d.9xlarge مع 72 جيجابايت من ذاكرة الوصول العشوائي، 900 جيجابايت من NVMe SSD و36 وحدة معالجة مركزية افتراضية. كل مثيل كان في نفس منطقة EC2 وكان لها عرض نطاق ترددي ثابت يبلغ 10 جيجابت في الثانية. استخدمنا SQLite كمتجر. (Stellar يدعم أيضًا PostgreSQL، ولكن هذا يحتوي على مهام غير متزامنة تضخ الضوضاء في القياسات.) يوفر Stellar استعلامًا مدمجًا في وقت التشغيل، وإنشاء التحميل، الذي يسمح بتوليد حمل اصطناعي على هدف محدد المعاملة/المعدل الثاني. على الرغم من أن Stellar يدعم العديد من ميزات التداول، مثل دفتر الطلبات ومسار الأصول المشتركة المدفوعات، ركزنا على المدفوعات البسيطة. يتكون تأكيد المعاملات من خطوات متعددة، لذلك نحن سجلت القياسات لكل مما يلي: • الترشيح: الوقت منذ الترشيح وحتى الإعداد الأول • الاقتراع: الوقت من الإعداد الأول إلى التأكيد ارتكبت الاقتراع • تحديث دفتر الأستاذ: حان الوقت لتطبيق القيمة المتفق عليها • عدد المعاملات: المعاملات المؤكدة لكل دفتر الأستاذ تم تعريف كل تجربة من تجاربنا من خلال ثلاث معلمات: عدد إدخالات الحساب في دفتر الأستاذ، ومبلغ التحميل (في شكل دفعات XLM) المقدمة في الثانية، وعدد validators. قمنا بتكوين كل validator لمعرفة المزيد عن كل validator (السيناريو الأسوأ بالنسبة إلى SCP)، مع تعيين شرائح النصاب القانوني على أي أغلبية بسيطة من العقد (بسبب زيادة عدد النصاب القانوني المختلفة). خط الأساس تم قياس تجربتنا الأساسية بـ Stellar بـ 100000 حساب، وأربعة validators، وتوليد التحميل معدل 100 معاملة / ثانية. لقد لاحظنا 507 معاملة لكل دفتر أستاذ في المتوسط، مع انحراف معياري قدره 49 (9.7%). لاحظ أنه لم يتم إسقاط أية معاملات؛ الطفيف 105 106 107 0 500 1000 1500 2000 الحسابات الكمون [مللي ثانية] تحديث دفتر الأستاذ الاقتراع الترشيح الشكل 9. الكمون مع زيادة عدد الحسابات يرجع التباين إلى قيود الجدولة الخاصة بمولد الحمل. لاحظنا أن عدد المعاملات لكل دفتر الأستاذ كان متسقًا مع معدل توليد التحميل لدينا، نظرًا لدفتر الأستاذ إغلاق كل 5 ثواني الترشيح والاقتراع وسجل الأستاذ أظهر التحديث متوسط زمن الوصول 82.53 مللي ثانية، 95.96 مللي ثانية، و 174.08 مللي ثانية، على التوالي. لاحظنا أن الكمون الترشيح النسبة المئوية 99 دائمًا أقل من 61 مللي ثانية، مع بعض الأحيان طفرات مدتها ثانية واحدة تقريبًا، تتوافق مع الخطوة الأولى في وظيفة المهلة لاختيار القائد. وبالنظر إلى الأداء الأساسي، نظرنا إلى التأثيرات من تغيير كل من معلمات إعداد الاختبار. الحسابات تشير البيانات الواردة في الشكل 9 إلى أن المقياس Stellar وكذلك عدد الحسابات يزيد. جيل الاختبار أصبحت الحسابات عملية طويلة، حيث أن إنشاء الدلو و لقد منعنا الدمج من ملء قاعدة البيانات ببساطة مع الحسابات مباشرة عبر SQL. ولذلك، أجرينا لدينا تجارب لما يصل إلى 50,000,000 حساب. في حين أن هناك الحد الأدنى من التأثير على الإجماع وزمن وصول تحديث دفتر الأستاذ، نلاحظ أن زيادة الحسابات تؤدي إلى زيادة في النفقات العامة دمج الدلاء، والتي تصبح أكبر. معدل المعاملة يؤثر معدل المعاملة على المبلغ حركة البث المتعدد بين validators، وعدد المعاملات المضمنة في كل دفتر أستاذ، وحجم المستوى الأعلى دلاء. لفهم آثار زيادة المعاملات التحميل، أجرينا تجربة على 100000 حساب و4 validators. ويبين الشكل 10 النمو البطيء في زمن الوصول المتفق عليه، بينما تم قضاء معظم الوقت في تحديث دفتر الأستاذ. ليس من المستغرب أنه مع زيادة حجم مجموعة المعاملات، فإنه يستغرق وقتًا أطول لربطه بقاعدة البيانات. ونلاحظ ذلك أيضا يعتمد زمن استجابة تحديث دفتر الأستاذ بشكل كبير على التنفيذ، ويتأثر باختيار قاعدة البيانات. عقد التحقق من الصحة لمعرفة كيفية زيادة عدد tierone validatorsيؤثر على الأداء، أجرينا التجارب مع 100000 حساب، و100 معاملة في الثانية، وعدد متفاوت من validators من 4 إلى 43. ظهرت جميع validators في جميع شرائح النصاب القانوني لـ validators؛ سوف شرائح النصاب أصغر لها تأثير أقل على الأداء.SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. 100 150 200 250 300 350 0 500 1000 1500 2000 تحميل [المعاملات/الثانية] الكمون [مللي ثانية] تحديث دفتر الأستاذ الاقتراع الترشيح الشكل 10. زمن الوصول مع زيادة حمل المعاملات 10 20 30 40 0 500 1000 1500 2000 المدققون الكمون [مللي ثانية] تحديث دفتر الأستاذ الاقتراع الترشيح الشكل 11. الكمون مع زيادة عدد العقد تغيير عدد عقد التحقق على الشبكة يؤثر أيضًا على عدد رسائل SCP المتبادلة عدد القيم المحتملة أثناء الترشيح. الشكل 11 يُظهر أن وقت الترشيح ينمو بمعدل صغير نسبيًا. وفي حين تشير البيانات إلى أن الاقتراع هو عنق الزجاجة، فإننا نعتقد أنه يمكن معالجة العديد من مشكلات التوسع من خلال التحسين شبكة Stellar المتراكبة لتحسين حركة مرور الشبكة. كما المتوقع، ظل زمن استجابة تحديث دفتر الأستاذ مستقلاً عن عدد العقد. سعر الإغلاق أخيرًا، أردنا قياس أداء Stellar الشامل من خلال قياس عدد مرات تأكيد دفاتر الأستاذ وما إذا كان Stellar يحقق هدفه البالغ 5 ثوانٍ دون إسقاط أي معاملات. لاحظنا إغلاق دفتر الأستاذ المتوسط مرات 5.03 ثانية و 5.10 ثانية و 5.15 ثانية مع زيادة الحساب الإدخالات ومعدل المعاملات وعدد العقد على التوالي. تشير النتائج إلى أن Stellar يمكنه إغلاق دفاتر الأستاذ باستمرار تحت حمولة عالية. 7.4 تشغيل validator إحدى الميزات المهمة لـ Stellar هي التكلفة المنخفضة تشغيل validator، حيث يجب تشغيل المراسي (أو التعاقد معها) validators لفرض النهاية. يقوم SDF بتشغيل 3 وحدات إنتاج validator، جميعها على مثيلات c5.large AWS، والتي تحتوي على مركزين، 4 غيغابايت من ذاكرة الوصول العشوائي ووحدة المعالجة المركزية Intel (R) Xeon (R) Platinum 8124M معالجات بسرعة 3.00 جيجا هرتز. فحص استخدام الموارد على واحد من هذه الأجهزة، لاحظنا استخدام عملية Stellar حوالي 7% من وحدة المعالجة المركزية و300 ميجابايت من الذاكرة. من حيث حركة مرور الشبكة، مع 28 اتصالاً بالأقران وحجم النصاب القانوني من 34، كانت معدلات الدخول والخروج 2.78 ميجابت/ثانية و 2.56 ميجابت/ثانية، على التوالي. الأجهزة المطلوبة لتشغيل مثل هذا العملية غير مكلفة. في حالتنا، تبلغ التكلفة 0.054 دولارًا في الساعة أو حوالي 40 دولارًا في الشهر. 7.5 العمل المستقبلي تشير هذه التجارب إلى أن Stellar يمكنه بسهولة التوسع في طلب واحد أو أمرين بحجم يتجاوز استخدام الشبكة اليوم. لأن لقد كانت متطلبات الأداء متواضعة جدًا حتى الآن، Stellar يترك مجالًا للعديد من التحسينات المباشرة باستخدام تقنيات معروفة. على سبيل المثال، المعاملات وSCP يتم بث الرسائل بواسطة validators باستخدام فيضان ساذج بروتوكول، ولكن يجب أن يستخدم بشكل مثالي أكثر كفاءة وتنظيما البث المتعدد من نظير إلى نظير [30]. بالإضافة إلى ذلك، قاعدة بيانات ثقيلة يمكن تحسين وقت تحديث دفتر الأستاذ من خلال تقنيات التجميع والجلب المسبق القياسية.
評価
Stellar のグローバルな支払いとしての適性を理解するため、 取引ネットワーク、パブリック ネットワークの状態を評価しました そして私的な実験で管理された実験を実行しました ネットワーク。私たちは次の質問に焦点を当てました。 • 実稼働ネットワーク トポロジはどのようなものですか? ブロードキャストされるメッセージの平均数、および SCP はどのようにタイムアウトを経験しますか? • コンセンサスと台帳の更新の遅延はアカウントの数に依存しませんか?SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル ロカバら。 • (a) 1 秒あたりのトランザクション (したがって、1 あたりのトランザクション数) の増加によってレイテンシはどのような影響を受けるか 台帳)、および (b) validator ノードの数? • CPU の観点から見たノードの実行コストはいくらですか。 メモリとネットワーク帯域幅は? 決済ネットワークは他のものと比べて取引率が低い 他のタイプの分散システムへ。先頭のblockchain、 Bitcoin および Ethereum、最大 15 トランザクション/秒を確認します。 Stellar 未満。さらに、これらのシステムは、 プルーフ・オブ・ワークではいくつかのブロックがマイニングされるのを待つ必要があるため、トランザクションを安全に確認するには 1 時間かかります。の blockchain 以外の SWIFT ネットワークでは、ピーク日 [14] には 1 秒あたり平均 420 トランザクションしかありませんでした。そこで私たちが選んだのは、 測定値を 5 秒の目標と比較するため 元帳間隔、より積極的な目標。私たちの結果は次のことを示しています レイテンシはこの制限を快適に下回っています。 いくつかの未実装の最適化がまだパイプラインにあります。 7.1 アンカー 取引量で上位の資産には通貨が含まれます (例: 3 USD アンカー、2 CNY)、Bitcoin アンカー、不動産担保証券 token [92]、およびアプリ内通貨 [8]。アンカーが異なれば、ポリシーも異なります。たとえば、1 つの USD アンカー、 Stronghold、auth_reqired を設定し、顧客を保持するすべてのアカウントに対して顧客確認 (KYC) プロセスを要求します。 資産。もう 1 つの AnchorUSD は、誰でも受け取って取引できます 彼らの米ドル（文字通り0.50ドルをメキシコに送金することが可能になります） 5 秒で 0.000001 ドルの手数料がかかります）。ただし、アンカーUSD USDの購入または引き換えにはKYCと手数料が必要です 従来の電信送金を使用します。フィリピンでは、 Coins.ph の入金に対する銀行の規制は緩い 任意の ATM マシン [36] での PHP のキャッシュアウトをサポートします。前述のセキュリティ token とアプリ内通貨に加えて、次のようなさまざまな非通貨 token があります。 商業債券 [22] および炭素クレジット [85、96] からその他 協力を促す token などの難解な資産 車の差し押さえ [35]。 7.2 パブリックネットワーク この記事の執筆時点では、126 個のアクティブなフル ノードがあり、そのうち 66 個は 投票メッセージに署名してコンセンサスに参加します。図7 ([5] によって生成) は、ネットワークを視覚化します。 一方が他方のクォーラム スライスに存在する場合は 2 つのノード、もう一方のクォーラム スライスに存在する場合は 2 つのノード 濃い青の線は双方向の依存性を示します。で センターは、17 の事実上の「ティア 1 validators」からなるクラスターであり、以下によって運営されています。 SDF、SatoshiPay、LOBSTR、COINQVEST、および Keybase。 4 か月前、第 6 節の出来事が起こる前に、 システム的に重要なノードは 15 個あり、そのうち 3 個は一見したところからのノードでした 第一層の組織といくつかのランダムなシングルトン。の グラフもかなり規則性が欠けているように見えました。したがって、新しい構成メカニズムおよび/またはより適切なオペレーターの決定が必要と思われます。 より健全なネットワーク トポロジに貢献します。なし 莫大な資金力（そしてそれに対応する株主） 図 7. クォーラム スライス マップ 義務）、ティア1を5人採用するのは困難だったでしょう ただし、組織は最初からそうなっています。これは定足数を示唆しています スライスはネットワーク ブートストラップで便利な役割を果たします。誰でも実行できます。 重要なプレーヤーになるという目標を持って参加するため、 ペアごとの合意の門番は存在しません。 現在、台帳には 330 万を超えるアカウントがあります。終わった 最近 24 時間で、Stellar のトランザクションは平均 4.5 件で、 1 秒あたり 15.7 回の操作。最近の台帳を確認すると、ほとんどの場合、 トランザクションには単一の操作があるように見えますが、数回ごとに 台帳では、多くの操作を含むトランザクションが見られます。 オファーを管理するマーケットメーカーから来ているようです。の 合意形成と台帳の更新にかかる平均時間は それぞれ1061ミリ秒と46ミリ秒。 99 パーセンタイルは次のとおりです。 2252 ミリ秒と 142 ミリ秒 (前者は 1 秒のタイムアウトを反映) 指名リーダーの選択において）。 SCP のパフォーマンスは次のとおりです。 SCP 以来、1 秒あたりのトランザクションにほとんど依存しません。 任意の多数のトランザクションの hash に同意します。ボトルネックは候補の伝播によって発生する可能性が高くなります 指名、実行、検証中のトランザクション トランザクションとバケットのマージ。まだ必要ありません 複数の CPU コアまたはディスク ドライブ上で Stellar-core のトランザクション処理を並列化します。 また、ブロードキャストされた SCP メッセージの数も評価しました。 本番ネットワーク上で。通常のシングルの場合 リーダーが価値を指名するために選出された場合、私たちは 7 つの論理的価値を期待します ブロードキャストされるメッセージ: 投票して承認する 2 つのメッセージ のみnate ステートメント、受け入れて確認する 2 つのメッセージ 準備ステートメント、受け入れと確認のための 2 つのメッセージ commit ステートメント、そして最後に externalize メッセージ (敗者を支援するために新しい台帳をディスクにコミットした後に送信されます) 追いつきます）。実装はコミット確認を組み合わせます そしてメッセージを最適化として外部化します。 コミット後に値を安全に外部化できます。次に、本番環境 Stellar validator で収集されたメトリクスを分析します。終わった 68 時間にわたって、1 秒あたり 1.3 メッセージが送信されました。 台帳あたりのメッセージは平均して 6 ～ 7 件です。合計は
Stellar による高速かつ安全なグローバル支払い SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル パーセンタイル タイムアウト数 指名 投票 75% 0 0 99% 1 0 マックス 4 1 図 8. 68 時間にわたるレジャーごとのタイムアウト validators によってブロードキャストされるメッセージの数は大きくなります。 フェデレーテッド投票メッセージに加えて、ノードはブロードキャストも行います。 彼らが知ったあらゆる取引。 図 8 は、プロダクションで発生したタイムアウトを示しています。 validator 68 時間にわたって。指名タイムアウトは、 リーダー選出機能の（非）有効性の尺度。投票タイムアウトはネットワークに大きく依存します。 メッセージの遅延の可能性もあります。タイムアウトは一貫しています 発行されるメッセージの数: 6 つのメッセージ 最良のシナリオ、および追加の指名ラウンドが必要な場合は少なくとも 7 つのメッセージ。 7.3 管理された実験 に詰められたコンテナ内で制御された実験を実行しました。 72 GiB の RAM を備えた Amazon EC2 c5d.9xlarge インスタンス、 900 GB の NVMe SSD、および 36 個の vCPU。各インスタンスは 同じ EC2 リージョンにあり、10 Gbps の固定帯域幅がありました。 ストアとして SQLite を使用しました。 (Stellar は PostgreSQL もサポートしています。 ただし、測定にノイズを注入する非同期タスクが含まれます)。 Stellar は、組み込みのランタイム クエリ、generateload、 特定のターゲットで合成負荷を生成できるようにします トランザクション/秒レート。 Stellar はさまざまな機能をサポートしていますが、 オーダーブックやクロスアセットパスなどの取引機能 決済においては、シンプルな決済に注力しました。 トランザクションの確認は複数のステップで構成されているため、 次のそれぞれの測定値を記録しました。 • 指名: 指名から最初の準備までの時間 • 投票: 最初の準備から投票の確認までの時間 投票用紙がコミットされました • 台帳の更新: コンセンサス値を適用する時期 • トランザクション数: 台帳ごとに確認されたトランザクション 私たちの各実験は 3 つのパラメーターによって定義されました。 台帳の口座エントリの数、金額 1 秒あたりに送信される負荷 (XLM 支払いの形式)、 そしてvalidatorの数。 validator ごとに構成しました validator ごとに知るため (最悪のシナリオ) SCP の場合）、クォーラム スライスは単純過半数に設定されます。 (異なるクォーラムの数を最大化するため)。 ベースライン ベースライン実験では Stellar を測定しました 100,000 アカウント、4 つの validator、および負荷生成 100 トランザクション/秒のレート。台帳ごとに平均 507 件のトランザクションが観察され、標準偏差は 49 でした。 (9.7%)。トランザクションがドロップされなかったことに注意してください。わずかな 105 106 107 0 500 1,000 1,500 2,000 アカウント レイテンシ[ミリ秒] 台帳の更新 投票 指名 図 9. アカウント数の増加に伴う待ち時間 差異は、ロード ジェネレーターのスケジュール制限によるものです。台帳ごとのトランザクション数が観察されました。 台帳を考慮すると、負荷生成率と一致していました 5秒ごとに閉まります。指名、投票、台帳 アップデートでは、平均レイテンシが 82.53 ミリ秒、95.96 ミリ秒、 それぞれ174.08ミリ秒。指名のレイテンシーが観察されました 99 パーセンタイルは常に 61 ミリ秒未満ですが、場合によっては 最初のステップに相当する約 1 秒のスパイク リーダー選択のタイムアウト機能で。 ベースラインのパフォーマンスを考慮して、その影響を調べました。 各テスト設定パラメータを変更します。 アカウント 図 9 のデータは、Stellar がスケールすることを示唆しています。 アカウントの数も増えます。テストの生成 バケットの作成と、アカウントの作成に時間がかかるプロセスになりました。 マージにより、単にデータベースにデータを追加することができなくなりました SQL 経由でアカウントを直接使用します。そこで私たちは、 最大 50,000,000 アカウントを対象とした実験。あるうちに コンセンサスと台帳更新の遅延への影響を最小限に抑え、 アカウントを増やすと、次のようなオーバーヘッドが発生することに注意してください。 バケットを結合すると、サイズが大きくなります。 トランザクションレート 取引レートは金額に影響を与えます validator 間のトラフィック マルチキャスト、各台帳に含まれるトランザクションの数、および最上位のサイズ バケツ。トランザクションの増加による影響を理解するため 負荷に応じて、100,000 のアカウントと 4 つの validator を使用して実験を実行しました。 図 10 は、コンセンサス レイテンシーの緩やかな増加を示しています。 一方、大部分の時間は台帳の更新に費やされました。 当然のことですが、トランザクション セットのサイズが大きくなるにつれて、 データベースにコミットするのに時間がかかります。また、 台帳更新の遅延は実装に大きく依存します。 データベースの選択によって影響を受けます。 バリデータノード tierone validators の数がどのように増加するかを確認するにはパフォーマンスに影響を与えるため、実験を実行しました 100,000 のアカウント、100 トランザクション/秒、validator の数は 4 ～ 43 で、すべての validator が表示されました。 すべての validator のクォーラム スライス内。より小さいクォーラム スライスは、 パフォーマンスへの影響が少なくなります。SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル ロカバら。 100 150 200 250 300 350 0 500 1,000 1,500 2,000 ロード [トランザクション/秒] レイテンシ[ミリ秒] 台帳の更新 投票 指名 図 10. トランザクション負荷の増加に伴うレイテンシ 10 20 30 40 0 500 1,000 1,500 2,000 バリデーター レイテンシ[ミリ秒] 台帳の更新 投票 指名 図 11. ノード数の増加に伴うレイテンシ ネットワーク上の検証ノードの数の変更 交換される SCP メッセージの数に影響を与えるだけでなく、 推薦中の潜在的な値の数。図11 は、指名時間の増加率が比較的小さいことを示しています。 データは投票がボトルネックであることを示唆していますが、 スケーリングに関する多くの問題は、改善することで解決できると考えています。 Stellar のオーバーレイ ネットワークを使用してネットワーク トラフィックを最適化します。として 予想通り、台帳更新の遅延は独立したままでした ノードの数。 成約率 最後に、台帳が確認される頻度と、Stellar が 5 秒の目標を達成するかどうかを測定することで、Stellar のエンドツーエンドのパフォーマンスを測定したいと考えました。 トランザクションを削除します。平均的な元帳のクローズが観察されました アカウントの増加に伴い、5.03 秒、5.10 秒、5.15 秒の時間になりました それぞれ、エントリ、トランザクション レート、ノード数です。 結果は、Stellar が元帳を一貫してクローズできることを示唆しています 高負荷時。 7.4 validator を実行しています Stellar の重要な特徴の 1 つは、コストが低いことです。 validator を実行します。アンカーは実行 (または契約) する必要があります。 validators でファイナリティを強制します。 SDF は 3 つの本番 validator を実行し、すべて 2 つのコアを持つ c5.large AWS インスタンス上で実行します。 4 GiB の RAM および Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz プロセッサ。 1 台でのリソース使用状況の検査 これらのマシンのうち、Stellar プロセスを観察しました。 CPU の約 7% とメモリ 300 MiB。ネットワーク トラフィックに関しては、ピアへの接続数が 28、クォーラム サイズが 1 つあります。 34 の場合、受信速度と送信速度は 2.78 Mbit/s でした。 それぞれ2.56Mビット/秒。このようなものを実行するにはハードウェアが必要です プロセスが安価です。この場合、コストは 0.054 ドル/時間です。 または月額約40ドル。 7.5 今後の取り組み これらの実験は、Stellar が 1 ～ 2 個の注文を簡単にスケールできることを示しています 今日のネットワーク使用量を超える規模です。なぜなら、 これまでのところ、パフォーマンスに対する要求は非常に控えめです。Stellar を使用して多くの直接的な最適化の余地を残します。 有名なテクニック。例: トランザクションと SCP メッセージは素朴なフラッディングを使用して validators によってブロードキャストされます プロトコルを使用しますが、理想的には、より効率的で構造化されたプロトコルを使用する必要があります。 ピアツーピア マルチキャスト [30]。さらに、データベースを多用する 台帳の更新時間は、標準のバッチ処理およびプリフェッチ技術によって改善できます。
خاتمة
المدفوعات الدولية باهظة الثمن وتستغرق أيامًا. الصندوق تمر الحضانة عبر مؤسسات مالية متعددة بما في ذلك البنوك المراسلة وخدمات تحويل الأموال. لأن كل قفزة يجب أن تكون موثوقة تماما، فمن الصعب على الجديد الداخلين للحصول على حصة في السوق والمنافسة. Stellar يظهر كيفية إرسال الأموال حول العالم بسعر رخيص في ثواني. ال الابتكار الرئيسي هو بروتوكول اتفاقية بيزنطية جديد مفتوح العضوية، SCP، الذي يعزز بنية نظير إلى نظير للشبكة المالية لتحقيق توافق عالمي في الآراء بموجب أ فرضية الإنترنت الجديدة. يتيح SCP لـ Stellar الالتزام ذريًا معاملات لا رجعة فيها عبر المشاركين التعسفيين الذين لا يعرفون أو يثقون ببعضهم البعض. وهذا بدوره يضمن للداخلين الجدد الوصول إلى نفس الأسواق القائمة اللاعبين، يجعلها آمنة للحصول على أفضل تبادل متاح أسعار حتى من صناع السوق غير موثوق بهم، وبشكل كبير يقلل من زمن الوصول للدفع. شكر وتقدير Stellar لن يكون حيث هو اليوم دون المبكر قيادة جويس كيم أو المساهمات الهائلة لـ سكوت فليكنشتاين وبارتيك نوفوتارسكي في البناء و الحفاظ على الأفق، وStellar SDK، والأجزاء الرئيسية الأخرى للنظام البيئي Stellar. ونشكر أيضًا كولتن بيرجيرون، هنري كوريجان جيبس، كانديس كيلي، كابيل ك. جاين، بوريس ريزنيكوف، جيريمي روبن، كريستيان رودر، إريك سوندرز، تورستن ستوبر، تومر ويلر، المراجعون المجهولون، و راعيتنا جوستين شيري على تعليقاتها المفيدة المسودات السابقة. إخلاء المسؤولية وكانت مساهمة البروفيسور مازيير في هذا المنشور بمثابة مستشار مدفوع الأجر، ولم تكن جزءًا منه واجبات أو مسؤوليات جامعة ستانفورد.
دفعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا
結論
国際決済は高額で日数もかかります。基金 保管はコルレス銀行や送金サービスを含む複数の金融機関を経由します。 各ホップは完全に信頼される必要があるため、新しいホップは困難です。 参入者は市場シェアを獲得し、競争します。 Stellar の番組 数秒で世界中に安く送金する方法。の 主要な革新は、ピアツーピア構造を活用した新しいオープンメンバーシップのビザンチン協定プロトコルである SCP です。 世界的なコンセンサスを達成するための金融ネットワークの構築 新しいインターネット仮説。 SCP は Stellar をアトミックにコミットさせます 任意の参加者間の不可逆的なトランザクション。 お互いのことを知らないし信頼もしていない。これにより、新規参入者が既存の市場と同じ市場にアクセスできることが保証されます。 プレーヤーは、利用可能な最高の交換を安全に入手できます 信頼できないマーケットメーカーからのレートであっても、劇的に上昇します。 支払いの待ち時間を短縮します。 謝辞 Stellar は、初期の ジョイス・キムのリーダーシップまたは多大な貢献 スコット・フレッケンシュタインとバルテック・ノヴォタルスキーが建築と Horizon、Stellar SDK、およびその他の重要な要素の維持 Stellar エコシステムの。コルテン・ベルジェロンにも感謝します。 ヘンリー・コリガン＝ギブス、キャンディス・ケリー、カピル・K・ジェイン、ボリス レズニコフ、ジェレミー・ルービン、クリスチャン・ラダー、エリック・サンダース、 Torsten Stüber、Tomer Weller、匿名の査読者、 私たちの羊飼いのジャスティン・シェリーさんに有益なコメントをいただきました 以前の草案。 免責事項 マジエール教授のこの出版物への貢献は有償コンサルタントとしてのものであり、教授の活動の一部ではありませんでした。 スタンフォード大学の義務または責任。
Stellar による高速かつ安全なグローバル支払い SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル