ホワイトペーパー ストーリー 図 用語集 グラフ 検索

Giao thức đồng thuận Stellar

著 David Mazières · 2015

単一表示 stellar.org
🇺🇸 English (原文)
🇻🇳 Tiếng Việt (翻訳)

概要

国際決済は遅くて高価ですが、その理由の 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

Tóm tắt

Thanh toán quốc tế chậm và tốn kém, một phần là do định tuyến thanh toán nhiều bước thông qua các mạng không đồng nhất. các hệ thống ngân hàng. Stellar là mạng thanh toán toàn cầu mới có thể chuyển trực tiếp tiền kỹ thuật số đến bất kỳ đâu trên thế giới thế giới trong vài giây. Sự đổi mới quan trọng là một giao dịch an toàn cơ chế thông qua các trung gian không đáng tin cậy, sử dụng một cơ chế mới Giao thức thỏa thuận Byzantine được gọi là SCP. Với SCP, mỗi tổ chức chỉ định các tổ chức khác sẽ ở lại đồng ý; thông qua sự kết nối toàn cầu của hệ thống tài chính, toàn bộ mạng lưới sau đó đồng ý về nguyên tử giao dịch trải rộng trên các tổ chức tùy ý, không có rủi ro về khả năng thanh toán hoặc tỷ giá hối đoái từ các tổ chức phát hành tài sản trung gian hoặc các nhà tạo lập thị trường. Chúng tôi trình bày mô hình, giao thức và xác minh chính thức; mô tả mạng thanh toán Stellar; và cuối cùng đánh giá Stellar theo kinh nghiệm thông qua điểm chuẩn và kinh nghiệm của chúng tôi với nhiều năm sử dụng sản xuất. Khái niệm CCS • Bảo mật và quyền riêng tư → Phân tán bảo mật hệ thống; • Tổ chức hệ thống máy tính → Kiến trúc ngang hàng; • Hệ thống thông tin → Chuyển tiền điện tử. Từ khóa blockchain, BFT, số đại biểu, thanh toán Định dạng tham chiếu ACM: Marta Lokhava, Giuliano Losa, David Mazières, Graydon Hoare, Nicolas Barry, Eli Gafni, Jonathan Jove, Rafał Malinowsky, Jed McCaleb. 2019. Thanh toán toàn cầu nhanh chóng và an toàn với Stellar. trong SOSP '19: Hội nghị chuyên đề về Nguyên tắc hệ điều hành, ngày 27–30 tháng 10, 2019, Huntsville, ON, Canada. ACM, New York, NY, Mỹ, 17 trang. https://doi.org/10.1145/3341301.3359636

導入

国際支払いは遅くて費用がかかることで有名です[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 は終了です。

Giới thiệu

Thanh toán quốc tế nổi tiếng là chậm và tốn kém [32]. Hãy xem xét tính phi thực tế của việc gửi 0,5 đô la từ Hoa Kỳ tới *Galois, Inc. †UCLA Quyền tạo bản sao kỹ thuật số hoặc bản cứng của tất cả hoặc một phần tác phẩm này cho việc sử dụng cá nhân hoặc lớp học được cấp miễn phí với điều kiện là các bản sao không được thực hiện hoặc phân phối vì lợi nhuận hoặc lợi ích thương mại và các bản sao đó mang thông báo này và trích dẫn đầy đủ ở trang đầu tiên. Bản quyền cho các thành phần tác phẩm này thuộc sở hữu của người khác ngoài ACM phải được tôn vinh. Trừu tượng hóa với tín dụng được cho phép. Sao chép theo cách khác hoặc xuất bản lại để đăng trên máy chủ hoặc phân phối lại vào danh sách, cần có sự cho phép cụ thể trước và/hoặc phải trả phí. Yêu cầu quyền từ [email protected]. SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada © 2019 Hiệp hội Máy tính. ACM ISBN 978-1-4503-6873-5/19/10...$15,00 https://doi.org/10.1145/3341301.3359636 Mexico, hai nước láng giềng. Người dùng cuối phải trả gần 9 USD đối với mức chuyển khoản trung bình như vậy [32] và thỏa thuận song phương được môi giới bởi ngân hàng trung ương của các nước chỉ có thể làm giảm chi phí ngân hàng cơ bản lên tới 0,67 USD cho mỗi mặt hàng [2]. Ngoài phí, độ trễ của thanh toán quốc tế thường được tính trong vài ngày, khiến cho việc chuyển tiền ra nước ngoài nhanh chóng trong trường hợp khẩn cấp. Ở những nước mà hệ thống ngân hàng không làm việc hoặc không phục vụ mọi công dân hoặc khi mức phí không thể chấp nhận được, mọi người chuyển sang gửi thanh toán bằng xe buýt [38], bằng thuyền [19] và thỉnh thoảng bây giờ là Bitcoin [55], tất cả đều như vậy phải chịu rủi ro, độ trễ hoặc sự bất tiện. Mặc dù sẽ luôn có chi phí tuân thủ nhưng bằng chứng cho thấy tổn thất một khoản đáng kể do thiếu cạnh tranh [21], càng trở nên trầm trọng hơn do công nghệ kém hiệu quả. Nơi mọi người có thể đổi mới, giá cả và độ trễ giảm xuống. Chẳng hạn, chuyển tiền từ tài khoản ngân hàng trong quý 2 năm 2019 có chi phí trung bình là 6,99%, trong khi con số về tiền di động chỉ là 4,88% [13]. Mạng thanh toán toàn cầu mở thu hút sự đổi mới và sự cạnh tranh từ các tổ chức phi ngân hàng có thể làm giảm chi phí và độ trễ ở tất cả các lớp, bao gồm cả việc tuân thủ [83]. Bài viết này trình bày Stellar, khoản thanh toán dựa trên blockchain mạng được thiết kế đặc biệt để tạo thuận lợi cho sự đổi mới và cạnh tranh trong thanh toán quốc tế. Stellar là lần đầu tiên thống để đáp ứng cả ba mục tiêu sau (theo một “Giả thuyết Internet” mới lạ nhưng có giá trị thực nghiệm: 1. Tư cách thành viên mở – Bất kỳ ai cũng có thể phát hành được hỗ trợ bằng tiền tệ token kỹ thuật số có thể được trao đổi giữa những người dùng. 2. Quyết định cuối cùng do nhà phát hành thực thi – Nhà phát hành của token có thể ngăn chặn các giao dịch trong token không bị đảo ngược hoặc hoàn tác. 3. Tính nguyên tử của nhà phát hành chéo – Người dùng có thể trao đổi nguyên tử và giao dịch token từ nhiều tổ chức phát hành. Đạt được hai điều đầu tiên thật dễ dàng. Bất kỳ công ty nào cũng có thể đơn phương cung cấp một sản phẩm như Paypal, Venmo, WeChat Thanh toán hoặc Alipay và đảm bảo tính cuối cùng của thanh toán trong tiền ảo mà họ đã tạo ra. Thật không may, giao dịch nguyên tử giữa các loại tiền tệ này là không thể. Trên thực tế, mặc dù Paypal đã mua lại công ty mẹ của Venmo vào năm 2013, người dùng cuối vẫn không thể gửi Venmo đô la cho người dùng Paypal [78]. Chỉ gần đây các thương nhân mới có thể thậm chí chấp nhận cả hai với một sự tích hợp duy nhất. Mục tiêu 2 và 3 có thể đạt được trong một hệ thống khép kín. Đặc biệt, một số nước đã có thanh toán nội địa hiệu quả mạng, thường được giám sát bởi một cơ quan quản lý đáng tin cậy trên toàn cầu. Tuy nhiên, tư cách thành viên được giới hạn ở mức đóng tập hợp các ngân hàng đặc quyền và mạng lưới được giới hạn ở tầm với của cơ quan quản lý của một quốc gia.SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada Lokhava và cộng sự. Mục tiêu 1 và 3 đã đạt được trong blockchain giây được khai thác, đáng chú ý nhất là ở dạng ERC20 tokens trên Ethereum [3]. Ý tưởng chính của những blockchain này là tạo ra một loại tiền điện tử mới để thưởng cho mọi người vì đã thanh toán giao dịch khó hoàn nguyên. Thật không may, điều này có nghĩa là nhà phát hành token không kiểm soát tính cuối cùng của giao dịch. Nếu phần mềm lỗi khiến lịch sử giao dịch bị sắp xếp lại [26, 73], hoặc khi chiến lợi phẩm của việc lừa gạt người khác vượt quá chi phí sắp xếp lại lịch sử [74, 97], nhà phát hành có thể phải chịu trách nhiệm về tokens họ đã đổi lấy tiền thật. Stellar blockchain có hai thuộc tính phân biệt. Đầu tiên, nó thực sự hỗ trợ thị trường hiệu quả trong khoảng token giây từ các tổ chức phát hành khác nhau. Cụ thể, bất kỳ ai cũng có thể phát hành token, blockchain cung cấp sổ đặt hàng tích hợp để giao dịch giữa bất kỳ cặp token nào và người dùng có thể phát hành thanh toán đường dẫn giao dịch nguyên tử trên một số cặp tiền tệ trong khi đảm bảo giá giới hạn từ đầu đến cuối. Thứ hai, Stellar giới thiệu thỏa thuận Byzantine mới giao thức, SCP (Stellar Giao thức đồng thuận), thông qua đó token nhà phát hành chỉ định máy chủ validator cụ thể để thực thi sự cuối cùng của giao dịch. Miễn là không ai xâm phạm validator của nhà phát hành (và các chữ ký số cơ bản và mật mã hash vẫn được bảo mật), nhà phát hành biết chính xác giao dịch nào đã xảy ra và tránh rủi ro về tổn thất từ blockchain việc sắp xếp lại lịch sử. Ý tưởng chính của SCP là hầu hết các nhà phát hành tài sản đều được hưởng lợi từ thị trường thanh khoản và muốn tạo điều kiện thuận lợi cho các giao dịch nguyên tử với các tài sản khác. Do đó, quản trị viên validator định cấu hình máy chủ của họ đồng ý chính xác với các validator khác lịch sử của tất cả các giao dịch trên tất cả các tài sản. validator v1 có thể được cấu hình để đồng ý với v2 hoặc v2 có thể được cấu hình để đồng ý với v1 hoặc cả hai có thể được cấu hình để đồng ý với nhau; trong mọi trường hợp, sẽ không cam kết về lịch sử giao dịch cho đến khi nó biết người kia không thể cam kết với một lịch sử khác. Theo tính bắc cầu, nếu v1 không thể không đồng ý với v2 và v2 không thể không đồng ý với v3 (hoặc ngược lại) thì v1 không thể không đồng ý với v3, v3 có đại diện cho tài sản v1 hay không thì đã nghe nói rồi của. Theo giả thuyết rằng các mối quan hệ thỏa thuận này kết nối liên tục toàn bộ mạng, SCP đảm bảo thỏa thuận toàn cầu, biến nó thành một thỏa thuận Byzantine toàn cầu giao thức với tư cách thành viên mở. Chúng tôi gọi giả định kết nối mới này là giả thuyết Internet và lưu ý rằng nó nắm giữ cả “Internet” (điều mà mọi người đều hiểu có nghĩa là mạng IP được kết nối bắc cầu lớn nhất) và thanh toán quốc tế truyền thống (được thực hiện theo từng bước phi nguyên tử, nhưng tận dụng một kết nối xuyên suốt, toàn cầu mạng lưới các tổ chức tài chính). Stellar đã được đưa vào sử dụng sản xuất từ tháng 9 năm 2015. Để duy trì độ dài blockchain có thể quản lý được, hệ thống sẽ chạy SCP trong khoảng thời gian 5 giây—nhanh theo tiêu chuẩn blockchain, nhưng chậm hơn nhiều so với các ứng dụng điển hình của thỏa thuận Byzantine. Mặc dù mục đích sử dụng chính là thanh toán, Stellar cũng có đã được chứng minh là hấp dẫn đối với những token có thể thay thế được bằng tiền và được hưởng lợi từ thị trường thứ cấp trực tiếp (xem Phần 7.1). Phần tiếp theo thảo luận về công việc liên quan. Phần 3 trình bày SCP. Phần 4 mô tả xác minh chính thức của chúng tôi về SCP. Phần 5 mô tả lớp thanh toán của Stellar. Mục 6 liên quan một số kinh nghiệm triển khai và bài học kinh nghiệm của chúng tôi. Phần 7 đánh giá hệ thống. Phần 8 kết thúc.

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

Stellar giao thức đồng thuận

Giao thức đồng thuận Stellar (SCP) là giao thức dựa trên đại biểu Giao thức thỏa thuận Byzantine với tư cách thành viên mở. Số đại biểu xuất hiện từ các quyết định cấu hình cục bộ kết hợp của các nút riêng lẻ. Tuy nhiên, các nút chỉ nhận ra số đại biểu mà họ thuộc về, và chỉ sau khi tìm hiểu cấu hình cục bộ của tất cả các thành viên trong nhóm túc số khác. Một lợi ích của phương pháp này là SCP vốn đã chấp nhận các quan điểm không đồng nhất về những nút nào tồn tại. Do đó, các nút có thể tham gia và rời đi một cách đơn phương mà không cần Giao thức "xem thay đổi" để điều phối thành viên. 3.1 Thỏa thuận Byzantine liên bang Bài toán thỏa thuận Byzantine truyền thống bao gồm một hệ thống khép kín gồm N nút, một số trong đó bị lỗi và có thể hành xử tùy tiện. Các nút nhận giá trị đầu vào và trao đổi thông báo để quyết định giá trị đầu ra trong số các đầu vào. Giao thức thỏa thuận Byzantine là an toàn khi không có hai nút hoạt động tốt nào đưa ra các quyết định khác nhau và địa chỉ duy nhất quyết định là một đầu vào hợp lệ (đối với một số định nghĩa về thỏa thuận hợp lệSOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada Lokhava và cộng sự. trước đó). Một giao thức hoạt động khi nó đảm bảo rằng mọi nút trung thực cuối cùng đều đưa ra quyết định. Thông thường, các giao thức giả định N = 3f + 1 đối với một số nguyên f > 0 thì đảm bảo an toàn và một dạng sống động nào đó miễn là nhiều nhất f nút bị lỗi. Ở một giai đoạn nào đó trong số này giao thức, các nút bỏ phiếu cho các giá trị được đề xuất và một đề xuất nhận được 2f + 1 phiếu bầu, gọi là số phiếu đại biểu, trở thành quyết định. Với N = 3f + 1 nút, hai số đại biểu bất kỳ của kích thước 2f + 1 chồng lên nhau ở ít nhất các nút f + 1; ngay cả khi f trong số này các nút chồng chéo bị lỗi thì ít nhất hai đại biểu chia sẻ một nút không bị lỗi, ngăn chặn các quyết định trái ngược nhau. Tuy nhiên, cách tiếp cận này chỉ hoạt động nếu tất cả các nút đồng ý những gì tạo nên số đại biểu, điều này là không thể trong SCP khi hai nút thậm chí có thể không biết đến sự tồn tại của nhau. Với SCP, mỗi nút v đơn phương khai báo các tập hợp nút, được gọi là các lát đại biểu của nó, sao cho (a) v tin rằng nếu tất cả các thành viên của một lát đồng ý về trạng thái của hệ thống, sau đó họ đúng, và (b) v tin rằng ít nhất một trong các lát cắt của nó sẵn sàng cung cấp thông tin kịp thời về trạng thái của hệ thống. Chúng tôi gọi hệ thống kết quả, bao gồm của các nút và các lát cắt của chúng, một Thỏa thuận Byzantine Liên bang (FBA) hệ thống. Như chúng ta sẽ thấy tiếp theo, một hệ thống đại biểu xuất hiện từ các lát cắt của nút. Một cách không chính thức, các lát cắt của nút FBA thể hiện ai nút yêu cầu sự đồng ý. Ví dụ: một nút có thể yêu cầu thỏa thuận với 4 tổ chức cụ thể, mỗi tổ chức điều hành 3 nút; để để phù hợp với thời gian ngừng hoạt động, nó có thể đặt các lát cắt của nó thành tất cả các bộ bao gồm 2 nút từ mỗi tổ chức. Nếu điều này “yêu cầu thỏa thuận với” mối quan hệ liên kết bắc cầu với hai nút bất kỳ, chúng tôi có được thỏa thuận toàn cầu. Ngược lại, chúng ta có thể có được sự phân kỳ, mà chỉ giữa các tổ chức không yêu cầu thỏa thuận với người kia. Với cấu trúc liên kết ngày nay thống tài chính, chúng tôi đưa ra giả thuyết rằng sự hội tụ rộng rãi sẽ tiếp tục tạo ra một lịch sử sổ cái duy nhất mà mọi người gọi là “mạng Stellar,” giống như cách chúng ta nói về Internet. Số đại biểu phát sinh từ các lát cắt như sau. Mỗi nút chỉ định số đại biểu của nó bị cắt trong mỗi tin nhắn nó gửi. Gọi S là tập hợp các nút mà từ đó một tập hợp các thông điệp bắt nguồn. A nút coi tập hợp các tin nhắn đã đạt đến số đại biểu ngưỡng khi mọi thành viên của S đều có một lát nằm trong S. Bằng cách xây dựng, tập S như vậy, nếu nhất trí, thỏa mãn điều kiện yêu cầu thoả thuận của mỗi thành viên. Một thiết bị ngang hàng bị lỗi có thể quảng cáo các lát cắt được tạo ra để thay đổi những gì các nút hoạt động tốt sẽ xem xét số đại biểu. Vì mục đích phân tích giao thức, chúng tôi xác định số đại biểu trong FBA là không trống tập S gồm các nút bao gồm ít nhất một lát đại biểu của từng thành viên không có lỗi. Sự trừu tượng này là âm thanh, như bất kỳ tập hợp nào của các thông điệp có ý đại diện cho một số đại biểu nhất trí thực sự có (ngay cả khi nó chứa thông báo từ các nút bị lỗi), và nó chính xác khi S chỉ chứa các nút hoạt động tốt. trong phần này, chúng tôi cũng giả định rằng các lát cắt của nút không thay đổi. Tuy nhiên, kết quả của chúng tôi chuyển sang trường hợp lát cắt thay đổi bởi vì một hệ thống trong đó các lát thay đổi không kém an toàn hơn một hệ thống lát cắt cố định trong đó các lát cắt của nút bao gồm tất cả các các lát cắt mà nó từng sử dụng trong trường hợp các lát cắt thay đổi (xem Định lý 13 trong [68]). Như đã giải thích ở Phần 4, tính sống động phụ thuộc vào các nút hoạt động tốt cuối cùng sẽ loại bỏ các nút không đáng tin cậy từ lát cắt của họ. Bởi vì các nút khác nhau có các yêu cầu thỏa thuận khác nhau nên FBA loại trừ định nghĩa toàn cầu về an toàn. Chúng tôi nói các nút không bị lỗi v1 và v2 được đan xen khi mỗi nút số đại biểu của v1 cắt mọi số đại biểu của v2 tại ít nhất một nút không bị lỗi. Một giao thức FBA có thể đảm bảo sự đồng thuận chỉ giữa các nút đan xen; vì SCP làm như vậy nên lỗi của nó dung sai cho sự an toàn là tối ưu. Giả thuyết về Internet thiết kế cơ bản của Stellar, nêu rõ rằng các nút mà mọi người quan tâm về sẽ được đan xen. Chúng ta nói một tập hợp các nút I còn nguyên vẹn nếu I là một đại biểu không bị lỗi thống nhất sao cho mỗi hai thành viên của I đều gắn bó với nhau ngay cả khi mọi nút bên ngoài I đều bị lỗi. Một cách trực quan, thì tôi nên tránh xa những hành động không còn nguyên vẹn nút. SCP đảm bảo cả tính sống động không bị chặn [93] và an toàn cho các tập hợp nguyên vẹn, mặc dù bản thân các nút không cần để biết (và có thể không biết) bộ nào còn nguyên vẹn. Hơn nữa, hợp của hai tập hợp nguyên vẹn giao nhau là một bộ còn nguyên vẹn. Do đó, các bộ nguyên vẹn xác định một phân vùng của các nút hoạt động tốt, trong đó mỗi phân vùng đều an toàn và hoạt động (trong một số điều kiện), nhưng các phân vùng khác nhau có thể xuất ra những quyết định khác nhau. 3.1.1 Cân nhắc về an toàn và tính sống động trong FBA Với các ngoại lệ hạn chế [64], hầu hết các giao thức thỏa thuận Byzantine đóng đều được điều chỉnh đến điểm cân bằng tại đó sự an toàn và sự sống động có khả năng chịu lỗi như nhau. Trong FBA, điều đó có nghĩa là các cấu hình trong đó, bất kể lỗi, tất cả các bộ đan xen cũng còn nguyên vẹn. Cho rằng FBA xác định số đại biểu theo cách phi tập trung, khó có khả năng các lựa chọn lát cắt riêng lẻ sẽ dẫn đến trạng thái cân bằng này. Hơn nữa, tại ít nhất là trong Stellar, trạng thái cân bằng là không mong muốn: hậu quả về lỗi an toàn (cụ thể là tiền kỹ thuật số được chi tiêu hai lần) là tệ hơn nhiều so với những trường hợp hỏng hóc về khả năng hoạt động (cụ thể là sự chậm trễ trong các khoản thanh toán dù sao cũng phải mất vài ngày trước Stellar). mọi người do đó nên và nên chọn các lát đại biểu lớn sao cho các nút của chúng có nhiều khả năng vẫn gắn liền với nhau hơn là nguyên vẹn. Nghiêng hơn nữa, việc phục hồi sau đó sẽ dễ dàng hơn các lỗi hoạt động điển hình trong hệ thống FBA so với hệ thống đóng truyền thống. Trong các hệ thống đóng, tất cả các thông điệp phải được được giải thích đối với cùng một tập hợp các đại biểu. Do đó, việc thêm và xóa các nút để phục hồi sau lỗi yêu cầu đạt được sự đồng thuận về một sự kiện cấu hình lại, điều này rất khó khăn khi sự đồng thuận không còn tồn tại. Ngược lại, với FBA, bất kỳ nút nào cũng có thể đơn phương điều chỉnh các lát cắt đại biểu của nó bất kỳ lúc nào thời gian. Để ứng phó với sự cố mất điện tại một điểm quan trọng mang tính hệ thống tổ chức, quản trị viên nút có thể điều chỉnh các lát cắt của họ để giải quyết vấn đề, hơi giống như điều phối các phản ứng tới thảm họa BGP [63] (mặc dù không có ràng buộc về định tuyến qua các liên kết mạng vật lý).

Thanh toán toàn cầu nhanh chóng và an toàn với Stellar SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada 3.1.2 Định lý tầng SCP tuân theo khuôn mẫu của mô hình tròn cơ bản [42]; các nút tiến triển thông qua một loạt các phiếu bầu được đánh số, mỗi nút cố gắng thực hiện ba nhiệm vụ: (1) xác định giá trị “an toàn” không mâu thuẫn với bất kỳ quyết định nào trong cuộc bỏ phiếu trước đó (thường được gọi là chuẩn bị phiếu), (2) thống nhất về giá trị an toàn, và (3) phát hiện thỏa thuận đã thành công. Tuy nhiên, FBA mở cửa tư cách thành viên cản trở một số kỹ thuật phổ biến, khiến nó không thể “chuyển” các giao thức đóng truyền thống sang FBA mô hình bằng cách thay đổi định nghĩa về số đại biểu. Một kỹ thuật được nhiều giao thức sử dụng là xoay vòng thông qua các nút dẫn đầu theo kiểu quay vòng sau khi hết thời gian chờ. Trong một hệ thống khép kín, việc lựa chọn người lãnh đạo theo vòng tròn đảm bảo rằng cuối cùng một nhà lãnh đạo trung thực duy nhất sẽ đạt được thỏa thuận điều phối về một giá trị duy nhất. Thật không may, vòng tròn không thể hoạt động trong hệ thống FBA với tư cách thành viên không xác định. Một kỹ thuật phổ biến khác không thành công với FBA là giả sử một số đại biểu cụ thể có thể thuyết phục được tất cả các nút. Ví dụ, nếu mọi người nhận ra bất kỳ nút 2f + 1 nào là số đại biểu thì Chữ ký 2f + 1 đủ để chứng minh trạng thái giao thức cho tất cả các nút. Tương tự, nếu một nút nhận được số lượng tin nhắn giống hệt nhau thông qua chương trình phát sóng đáng tin cậy [24], nút có thể cho rằng tất cả các nút không bị lỗi cũng sẽ thấy số đại biểu. Ngược lại, trong FBA, một đại biểu không có ý nghĩa gì đối với các nút bên ngoài đại biểu. Cuối cùng, các hệ thống không liên kết thường sử dụng “ngược” lý luận về an toàn: nếu nút f + 1 bị lỗi, tất cả đều an toàn bảo lãnh bị mất. Do đó, nếu nút v nghe thấy tất cả các nút f + 1 nêu một sự thật nào đó F, v có thể cho rằng ít nhất một người đang nói với sự thật (và do đó F đúng) mà không mất đi sự an toàn. Như vậy lý luận thất bại trong FBA vì an toàn là thuộc tính của các cặp của các nút, do đó, một nút đã mất đi sự an toàn đối với một số nút ngang hàng có thể luôn mất đi sự an toàn đối với nhiều nút hơn bằng cách giả định các sự kiện xấu. Tuy nhiên, FBA có thể lý giải ngược lại về tính sống động. Xác định tập v-blocking là tập hợp các nút giao nhau lát của v. Nếu tập chặn v B bị lỗi nhất trí, B có thể từ chối nút và số đại biểu và khiến nó mất đi sự sống động. Do đó, nếu B nhất trí nêu sự thật F, khi đó v biết rằng F là đúng hoặc v không còn nguyên vẹn. Tuy nhiên v vẫn cần xem đầy đủ đủ số đại biểu để biết rằng các nút đan xen sẽ không mâu thuẫn với F, dẫn đến vòng giao tiếp cuối cùng trong SCP và các giao thức FBA khác [47] không bắt buộc tương tự giao thức thành viên đóng. Kết quả là chúng ta có ba mức độ tin cậy có thể có đối với các sự kiện tiềm ẩn: không xác định, an toàn để giả định giữa các nút nguyên vẹn (chúng tôi sẽ thuật ngữ được chấp nhận thực tế), và an toàn để giả định giữa đan xen các nút (mà chúng tôi sẽ gọi là sự thật đã được xác nhận). Nút v có thể xác định một cách hiệu quả liệu một tập hợp B có bị vblocking hay không bằng cách kiểm tra xem B có giao nhau với tất cả các lát cắt của nó hay không. Điều thú vị là nếu các nút luôn thông báo các câu lệnh mà chúng chấp nhận và đủ số đại biểu chấp nhận một tuyên bố, nó sẽ khởi động một quá trình xếp tầng theo đó các tuyên bố được lan truyền xuyên suốt bộ còn nguyên vẹn. Chúng tôi gọi thực tế quan trọng đằng sau sự truyền bá này định lý tầng, trong đó thỏa mãn điều sau: Nếu tôi là một tập nguyên vẹn, Q là số đại biểu của bất kỳ phần tử nào của I, và S là bất kỳ tập siêu của Q thì S ⊇I hoặc có thành viên v ∈I sao cho v < S và I ∩S bị chặn v. Bằng trực giác, liệu đây có phải là không phải như vậy, phần bù của S sẽ chứa đại biểu cắt I nhưng không cắt Q, vi phạm giao điểm đại biểu. Lưu ý rằng nếu chúng ta bắt đầu với S = Q và liên tục mở rộng S thành bao gồm tất cả các nút mà nó chặn, chúng tôi có được hiệu ứng xếp tầng cho đến khi, cuối cùng, S bao gồm tất cả I. 3.2 Mô tả giao thức SCP là một giao thức đồng thuận đồng bộ một phần [42] bao gồm một loạt các nỗ lực nhằm đạt được sự đồng thuận được gọi là phiếu bầu. Phiếu bầu sử dụng thời gian chờ với thời lượng tăng dần. A giao thức đồng bộ hóa lá phiếu đảm bảo rằng các nút luôn hoạt động cùng một lá phiếu trong khoảng thời gian tăng dần cho đến khi các lá phiếu được đồng bộ một cách hiệu quả. Việc chấm dứt không được đảm bảo cho đến khi các lá phiếu được đồng bộ, nhưng có hai lá phiếu đồng bộ trong đó các thành viên bị lỗi của các lát cắt của nút hoạt động tốt không can thiệp là đủ để SCP chấm dứt. Một giao thức bỏ phiếu chỉ định các hành động được thực hiện trong mỗi lá phiếu. Một cuộc bỏ phiếu bắt đầu bằng giai đoạn chuẩn bị, trong đó các nút cố gắng xác định một giá trị để đề xuất không mâu thuẫn quyết định nào trước đó. Sau đó, trong giai đoạn cam kết, các nút sẽ thử để đưa ra quyết định về giá trị đã chuẩn bị. Việc bỏ phiếu sử dụng một giao thức con thỏa thuận được gọi là bỏ phiếu liên kết, tôin nút nào bỏ phiếu cho các câu lệnh trừu tượng điều đó cuối cùng có thể được xác nhận hoặc bị mắc kẹt. Một số tuyên bố có thể được coi là mâu thuẫn và sự an toàn đảm bảo cho việc bỏ phiếu liên bang là không có hai thành viên của một tập hợp đan xen xác nhận các tuyên bố trái ngược nhau. Việc xác nhận một tuyên bố không được đảm bảo ngoại trừ một bản còn nguyên vẹn tập hợp mà tất cả các thành viên đều bỏ phiếu theo cùng một cách. Tuy nhiên, nếu một thành viên của một tập hợp nguyên vẹn xác nhận một tuyên bố, được liên kết việc bỏ phiếu đảm bảo rằng tất cả các thành viên của tập hợp nguyên vẹn cuối cùng sẽ xác nhận tuyên bố đó. Do đó, thực hiện các bước không thể đảo ngược để đáp lại những tuyên bố xác nhận sẽ duy trì sự sống động cho các nút còn nguyên vẹn. Các nút ban đầu đề xuất các giá trị thu được từ một đề cử giao thức làm tăng cơ hội của tất cả các thành viên trong một mạng lưới nguyên vẹn tập đề xuất cùng một giá trị và cuối cùng hội tụ (mặc dù không có cách nào để xác định sự hội tụ đã hoàn tất). Đề cử kết hợp bỏ phiếu liên bang với lựa chọn người lãnh đạo. Vì FBA không thể thực hiện vòng tròn tính điểm nên việc đề cử sẽ được sử dụng một kế hoạch lựa chọn người lãnh đạo theo xác suất. Định lý xếp tầng đóng một vai trò quan trọng cả trong việc bỏ phiếu đồng bộ hóa và tránh các trạng thái bị chặn từ đó việc chấm dứt là không thể được nữa. 3.2.1 Bỏ phiếu Các nút SCP tiến hành thông qua một loạt các lá phiếu được đánh số, sử dụng biểu quyết liên đoàn để thống nhất các tuyên bố về cái nào giá trị được quyết định hay không trong lá phiếu nào. Nếu không đồng bộ hoặc hành vi sai sót ngăn cản việc đưa ra quyết định trong lá phiếu n, các nút hết thời gian chờ và thử lại trong lá phiếu n + 1.

SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada Lokhava và cộng sự. Hãy nhớ lại việc bỏ phiếu liên bang có thể không chấm dứt. Do đó, một số các tuyên bố về lá phiếu có thể bị kẹt vĩnh viễn trạng thái không xác định trong đó các nút không bao giờ có thể xác định liệu chúng có vẫn đang được tiến hành hoặc bị mắc kẹt. Bởi vì các nút không thể loại trừ khả năng những tuyên bố không xác định sau này được chứng minh là đúng, họ không bao giờ được cố gắng bỏ phiếu liên bang cho các tuyên bố mới mâu thuẫn với những cái không xác định. Trong mỗi lá phiếu n, các nút sử dụng biểu quyết liên kết trên hai loại của tuyên bố: • chuẩn bị ⟨n,x⟩– cho biết không có giá trị nào khác ngoài x đã hoặc sẽ được quyết định trong bất kỳ cuộc bỏ phiếu nào ≤n. • cam kết ⟨n,x⟩– nêu x được quyết định trong lá phiếu n. Điều quan trọng, lưu ý rằng chuẩn bị ⟨n,x⟩contradicts cam kết ⟨n′,x ′⟩khi n ≥n′ và x , x ′. Một nút bắt đầu bỏ phiếu n bằng cách thử bỏ phiếu liên bang trên một câu lệnh chuẩn bị ⟨n,x⟩. Nếu có tuyên bố chuẩn bị trước đó đã được xác nhận thành công thông qua bỏ phiếu liên đoàn, nút chọn x từ sự chuẩn bị đã được xác nhận của lá phiếu cao nhất. Mặt khác, nút đặt x thành đầu ra của thức đề cử được mô tả trong tiểu mục tiếp theo. Nếu và chỉ khi một nút xác nhận thành công, hãy chuẩn bị ⟨n,x⟩ trong lá phiếu n, nó cố gắng bỏ phiếu liên kết theo cam kết ⟨n,x⟩. Nếu thành công, điều đó có nghĩa là SCP đã quyết định, do đó nút xuất ra giá trị từ tuyên bố cam kết được xác nhận. Xét một tập S đan xen. Vì có nhiều nhất một giá trị có thể được xác nhận bởi các thành viên của S trong một lá phiếu nhất định, không được xác nhận hai giá trị khác nhau do thành viên của S trong một lá phiếu nhất định. Hơn nữa, nếu cam kết ⟨n,x⟩ được xác nhận, sau đó chuẩn bị ⟨n,x⟩cũng được xác nhận; kể từ khi chuẩn bị ⟨n,x⟩trái ngược với bất kỳ cam kết nào trước đó về một giá trị khác, bằng thỏa thuận đảm bảo về bỏ phiếu liên bang chúng tôi hiểu rằng không có giá trị khác nào có thể được quyết định sớm hơn phiếu bầu của các thành viên của S. Bằng cách quy nạp số phiếu bầu, chúng tôi do đó hãy chắc chắn rằng SCP vẫn an toàn. Để có sự sống động, hãy xem xét một tập I nguyên vẹn và đủ dài lá phiếu đồng bộ n. Nếu các nút bị lỗi xuất hiện trong các lát của các nút hoạt động tốt không can thiệp vào n, sau đó bằng cách bỏ phiếu n + 1 tất cả các thành viên của I đều đã xác nhận cùng một tập P của các câu lệnh chuẩn bị. Nếu P = ∅ và lá phiếu n đủ dài thì giao thức đề cử sẽ hội tụ về một số giá trị x. Mặt khác, đặt x là giá trị từ lượt chuẩn bị có phiếu bầu cao nhất ở P. Dù thế nào đi nữa, tôi sẽ thống nhất thử liên kết bỏ phiếu chuẩn bị ⟨n + 1,x⟩trong lần bỏ phiếu tiếp theo. Vì vậy, nếu n + 1 cũng đồng bộ nên quyết định về x tất yếu sẽ xảy ra sau đó. 3.2.2 Đề cử Đề cử đòi hỏi phải bỏ phiếu liên bang về các tuyên bố: • đề cử x – cho biết x là ứng cử viên quyết định hợp lệ. Các nút có thể bỏ phiếu để đề cử nhiều giá trị—khác nhau các tuyên bố đề cử không mâu thuẫn nhau. Tuy nhiên, một lần một nút xác nhận bất kỳ tuyên bố đề cử nào, nó sẽ dừng bỏ phiếu đề cử các giá trị mới. Bỏ phiếu liên kết vẫn cho phép một nút xác nhận các tuyên bố đề cử mới mà họ không bỏ phiếu, bỏ phiếu hoặc chấp nhận một từ đại biểu chấp nhận một từ đại biểu a là hợp lệ chấp nhận từ bộ chặn không cam kết đã bình chọn một chấp nhận một đã xác nhận một đã bình chọn -a Hình 1. Các giai đoạn bỏ phiếu liên bang cho phép các thành viên của một tập hợp nguyên vẹn xác nhận ý kiến của nhau các giá trị được đề cử trong khi vẫn giữ lại phiếu bầu mới. Kết quả (đang phát triển) của việc đề cử là sự kết hợp mang tính quyết định của tất cả các giá trị trong các tuyên bố đề cử đã được xác nhận. Nếu x đại diện cho một tập hợp các giao dịch, các nút có thể kết hợp trong số các bộ, bộ lớn nhất hoặc bộ có hash cao nhất, vì vậy miễn là tất cả các nút đều làm như vậy. Bởi vì các nút giữ lại cái mới phiếu bầu sau khi xác nhận một tuyên bố đề cử, tập hợp các các câu lệnh được xác nhận chỉ có thể chứa hữu hạn nhiều giá trị. Thực tế là các tuyên bố đã được xác nhận được lan truyền một cách đáng tin cậy thông qua tập hợp nguyên vẹn có nghĩa là các nút nguyên vẹn cuối cùng hội tụ trên cùng một tập hợp các giá trị được đề cử và do đó kết quả đề cử, mặc dù tại một điểm không xác định, tùy ý bị trễ trong giao thức. Các nút sử dụng lựa chọn lãnh đạo liên kết để giảm số lượng các giá trị khác nhau trong các câu lệnh đề cử. Chỉ một nhà lãnh đạo chưa bỏ phiếu cho tuyên bố đề cử có thể giới thiệu một x mới. Các nút khác đang chờ phản hồi từ lãnh đạo và chỉ sao chép phiếu đề cử (hợp lệ) của lãnh đạo họ. Để đối phó với thất bại, đội ngũ lãnh đạo không ngừng phát triển xảy ra thời gian chờ, mặc dù trong thực tế chỉ có một số nút đưa ra các giá trị mới của x. 3.2.3 Bỏ phiếu liên bang Bỏ phiếu liên bang sử dụng giao thức ba giai đoạn được hiển thị trong Hình 1. Các nút cố gắng thống nhất các câu lệnh trừu tượng trước tiên bỏ phiếu, sau đó chấp nhận và cuối cùng là xác nhận các tuyên bố. Nút v có thể bỏ phiếu cho bất kỳ câu lệnh a hợp lệ nào mà không mâu thuẫn với cái khác của nósố phiếu còn tồn đọng và các tuyên bố được chấp nhận. Nó làm như vậy bằng cách phát đi một tin nhắn biểu quyết đã ký. v sau đó chấp nhận a nếu a phù hợp với các phát biểu được chấp nhận khác và (trường hợp 1)v là thành viên của một đại biểu trong đó mỗi nút hoặc bỏ phiếu cho a hoặc chấp nhận a hoặc (trường hợp 2) ngay cả khi v không bỏ phiếu cho a, tập hợp chặn v chấp nhận a. Trường hợp 2, v có thể trước đây đã bỏ phiếu mâu thuẫn với a, hiện đã bỏ phiếu bị bác bỏ. v được phép quên đi những phiếu bầu bị bác bỏ và giả vờ như nó chưa bao giờ sử dụng chúng vì ifv còn nguyên vẹn, nó biết phiếu bị bác bỏ không thể hoàn thành số đại biểu thông qua trường hợp 1. v thông báo rằng nó chấp nhận a, sau đó xác nhận a khi nó ở trong số đại biểu nhất trí chấp nhận a. Hình 2 cho thấy ảnh hưởng của tập chặn v và định lý xếp tầng trong bỏ phiếu liên bang. Hai nút đan xen nhau không thể xác nhận các tuyên bố trái ngược nhau, vì hai số đại biểu bắt buộc sẽ phải chia sẻ mộtThanh toán toàn cầu nhanh chóng và an toàn với Stellar SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada 3 4 2 1 5 7

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 を追加します。

Bình chọn X

Bầu Y (a) 3 4 2 1 5 7 6 Bình chọn X Bình chọn X Bình chọn X Bình chọn Y Bình chọn X Bình chọn Y Bình chọn Y (b) 3 4 2 1 5 7 6 Chấp nhận X Bình chọn X Chấp nhận X Bình chọn Y Chấp nhận X Bình chọn Y Bình chọn Y (c) 3 4 2 1 5 7 6 Chấp nhận X Chấp nhận X Chấp nhận X Bình chọn Y Chấp nhận X Chấp nhận X Bình chọn Y (d) 3 4 2 1 5 7 6 Chấp nhận X Bình chọn X Chấp nhận X Chấp nhận X Chấp nhận X Chấp nhận X Chấp nhận X (e) Hình 2. Hiệu ứng xếp tầng trong bỏ phiếu liên bang. Mỗi nút có một lát đại biểu được biểu thị bằng các mũi tên tới các thành viên của lát. (a) Các phát biểu mâu thuẫn X và Y được đưa ra. (b) Các nút bỏ phiếu cho các phát biểu hợp lệ. (c) Nút 1 chấp nhận X sau đại biểu của nó {1, 2, 3, 4} nhất trí bỏ phiếu cho X. (d) Các nút 1, 2, 3 và 4 đều chấp nhận X; tập {1} là 5-blocking, vì vậy nút 5 chấp nhận X, ghi đè phiếu bầu trước đó của nó cho Y. (e) Tập {5} là 6- và 7-chặn, vì vậy cả 6 và 7 đều chấp nhận X. nút không bị lỗi không thể chấp nhận các câu lệnh mâu thuẫn. Việc xác nhận một tuyên bố không được đảm bảo: trong trường hợp biểu quyết chia rẽ, cả hai tuyên bố có thể có hiệu lực vĩnh viễn bị mắc kẹt khi chờ số đại biểu trong giai đoạn bỏ phiếu. Tuy nhiên, nếu một nút trong một tập nguyên vẹn Tôi xác nhận một câu lệnh, tầng định lý và chấp nhận trường hợp 2 đảm bảo rằng tất cả I cuối cùng sẽ xác nhận tuyên bố đó. 3.2.4 Đồng bộ hóa phiếu bầu Nếu các nút không thể xác nhận một tuyên bố cam kết cho lá phiếu hiện tại, họ sẽ bỏ cuộc sau khi hết thời gian chờ. Thời gian chờ được dài hơn với mỗi lá phiếu để điều chỉnh theo giới hạn tùy ý về độ trễ mạng. Tuy nhiên, chỉ thời gian chờ là không đủ để đồng bộ hóa phiếu bầu của các nút không bắt đầu cùng lúc hoặc đã không đồng bộ hóa vì các lý do khác. Để đạt được sự đồng bộ hóa, các nút chỉ khởi động bộ đếm thời gian khi chúng là một phần của số đại biểu có ở lá phiếu hiện tại (hoặc sau này) n. Cái này làm chậm các nút bắt đầu sớm và đảm bảo rằng không có thành viên của một nhóm nguyên vẹn luôn dẫn đầu nhóm quá xa. Hơn nữa, nếu một nút v nhận thấy một tập hợp chặn v sau đó. lá phiếu, nó ngay lập tức chuyển sang lá phiếu thấp nhất sao cho không còn như vậy nữa, bất kể bất kỳ bộ tính giờ nào. thác nước định lý sau đó đảm bảo rằng tất cả những người đi sau đều bắt kịp. kết quả là các lá phiếu gần như được đồng bộ hóa xuyên suốt một cách nguyên vẹn được thiết lập khi hệ thống trở nên đồng bộ. 3.2.5 Lựa chọn lãnh đạo liên bang Lựa chọn người lãnh đạo cho phép mỗi nút chọn những người lãnh đạo theo cách như vậy theo cách mà các nút thường chỉ chọn một hoặc một số nhỏ của các nhà lãnh đạo. Để khắc phục sự thất bại của người lãnh đạo, việc lựa chọn người lãnh đạo tiến hành qua các vòng. Nếu người dẫn đầu vòng hiện tại dường như không hoàn thành trách nhiệm của mình thì sau một thời gian các nút trong khoảng thời gian chờ nhất định sẽ chuyển sang vòng tiếp theo để mở rộng nhóm lãnh đạo mà họ theo đuổi. Mỗi vòng sử dụng hai hàm mật mã hash duy nhất, H0 và H1, xuất ra các số nguyên trong phạm vi [0,hmax). Ví dụ: Stellar sử dụng Hi(m) = SHA256(i∥b∥r ∥m), trong đó b là phiên bản SCP tổng thể (số khối hoặc sổ cái), r là số vòng lựa chọn người lãnh đạo và hmax = 2256. Trong một vòng, chúng tôi xác định mức độ ưu tiên của nút v là: mức độ ưu tiên(v) = H1(v) Mỗi nút sẽ chọn một người làm ống hút làm người lãnh đạo nút có mức độ ưu tiên cao nhất (v). Cách tiếp cận này hoạt động tốt với các lát đại biểu gần như giống hệt nhau, nhưng không đúng cách nắm bắt được tầm quan trọng của các nút trong cấu hình không cân bằng. Ví dụ: nếu Châu Âu và Trung Quốc mỗi nước đóng góp 3 các nút theo mọi đại biểu, nhưng Trung Quốc chạy 1.000 nút và Châu Âu 4, thì Trung Quốc sẽ có nút ưu tiên cao nhất 99,6% của thời đại. Do đó chúng tôi giới thiệu một khái niệm về trọng lượng lát cắt, trong đó trọng lượng(u,v) ∈[0, 1] là một phần của các lát đại biểu của nút u chứa nút v. Khi nút u đang chọn người lãnh đạo mới, nó chỉ xem xét hàng xóm, được xác định như sau: hàng xóm(u) = { v | H0(v) < hmax · trọng lượng(u,v) } Sau đó, một nodeu bắt đầu với một tập hợp các nhà lãnh đạo trống và tại mỗi vòng thêm vào đó nút v trong hàng xóm (u) có giá trị cao nhất ưu tiên(v). Nếu tập hàng xóm trống trong bất kỳ vòng nào, thay vào đó, u sẽ thêm nút có giá trị thấp nhất làH0(v)/weight(u,v).

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] 現在 活性が厳密に弱いプロトコルに依存するプロトコル スライスから障害のあるノードを削除する必要がなく、最終的には同期が行われ、最終的にはリーダーが選出されると仮定します。

Xác minh chính thức của SCP

Để loại bỏ các lỗi thiết kế, chúng tôi đã chính thức xác minh tính an toàn của SCP và các thuộc tính sống động (xem [65]). Cụ thể, chúng tôi đã xác minh các nút đan xen đó không bao giờ bất đồng ý kiến và rằng, trong các điều kiện được thảo luận dưới đây, mọi thành viên của một tập hợp nguyên vẹn cuối cùng sẽ quyết định. Điều thú vị là việc xác minh cho thấy rằng những điều kiện mà SCP đảm bảo sự sống rất tinh tế, và mạnh mẽ hơn suy nghĩ ban đầu [68]: như được thảo luận bên dưới, các nút độc hại thao túng thời gian mà không có cách nào khác đi chệch khỏi giao thức có thể cần phải được gỡ bỏ bằng tay từ các lát đại biểu.

SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada Lokhava và cộng sự. Để đảm bảo rằng các tài sản đã được chứng minh có giá trị nhất có thể cấu hình và thực thi FBA, chúng tôi xem xét tùy ý số nút có cấu hình cục bộ tùy ý. Cái này bao gồm các kịch bản với các bộ nguyên vẹn rời rạc, cũng như các lần thực thi có thể kéo dài vô tận. Nhược điểm là chúng ta phải đối mặt với vấn đề đầy thách thức trong việc xác minh một tham số hệ thống trạng thái vô hạn. Để duy trì việc xác minh dễ dàng, chúng tôi đã lập mô hình SCP theo logic bậc nhất (FOL) bằng cách sử dụng Ivy [69] và phương pháp của [82]. Quá trình xác minh bao gồm việc cung cấp các phỏng đoán quy nạp theo cách thủ công, sau đó được kiểm tra tự động bởi Cây thường xuân. Mô hình FOL của SCP tóm tắt một số khía cạnh của Các hệ thống FBA khó xử lý trong FOL (ví dụ: định lý tầng được coi là một tiên đề), vì vậy chúng tôi xác minh tính đúng đắn của sự trừu tượng hóa bằng cách sử dụng Isabelle/HOL [75]. Sau khi trình bày vấn đề xác minh trong FOL, chúng tôi xác minh tính an toàn bằng cách cung cấp một bất biến quy nạp. quy nạp bất biến bao gồm hàng tá phỏng đoán một dòng cho khoảng 150 dòng đặc tả giao thức. Sau đó, chúng tôi chỉ định các thuộc tính sống của SCP trong Logic Thời gian Tuyến tính của Ivy và sử dụng giảm độ sống để an toàn [80, 81] để giảm độ sống bài toán xác minh cho bài toán tìm biểu thức quy nạp bất biến. Mặc dù sự an toàn của SCP tương đối dễ thực hiện chứng minh, lập luận về sự sống của SCP phức tạp hơn nhiều và bao gồm khoảng 150 bất biến một dòng. Việc chứng minh tính sống động đòi hỏi một sự hình thức hóa chính xác của giả định theo đó SCP đảm bảo chấm dứt. Ban đầu chúng tôi nghĩ rằng một bộ nguyên vẹn sẽ luôn chấm dứt nếu tất cả các thành viên đã loại bỏ các nút bị lỗi khỏi lát cắt của họ [68]. Tuy nhiên, điều này hóa ra vẫn chưa đủ: một người cư xử tốt (nhưng không còn nguyên vẹn) nút trong số đại biểu thành viên của I can, theo ảnh hưởng của các nút bị lỗi, ngăn chặn việc chấm dứt bằng cách hoàn thành đủ số đại biểu ngay trước khi kết thúc cuộc bỏ phiếu, do đó gây ra thành viên của I chọn các giá trị khác nhau của x trong lần bỏ phiếu tiếp theo. Do đó, chúng ta phải giả định thêm rằng, một cách không chính thức, cuối cùng mỗi nút trong số đại biểu của một thành viên của tôi trở nên kịp thời hoặc không gửi tin nhắn nào trong một khoảng thời gian vừa đủ. Trong thực tế, điều này có nghĩa là các thành viên của tôi có thể cần điều chỉnh các lát cắt của chúng cho đến khi điều kiện được giữ nguyên. Cái này vấn đề không phải là cố hữu của hệ thống FBA: Losa et al. [47] có mặt một giao thức mà sự tồn tại của nó phụ thuộc vào điểm yếu hơn giả định về sự đồng bộ hóa cuối cùng và sự lựa chọn lãnh đạo cuối cùng mà không cần phải loại bỏ các nút bị lỗi khỏi các lát cắt.

決済ネットワーク

このセクションでは、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 つの層が与えられます。 最悪の事態を防ぐための通知と指導 集団的な設定ミス。

Mạng thanh toán

Phần này mô tả mạng thanh toán của Stellar, được triển khai dưới dạng máy trạng thái được sao chép [88] trên SCP. 5.1 Mô hình sổ cái Sổ cái của Stellar được thiết kế dựa trên sự trừu tượng hóa tài khoản (trong tương phản với sản lượng giao dịch chưa chi tiêu tập trung vào tiền xu hơn hoặc mẫu UTXO của Bitcoin). Nội dung sổ cái bao gồm một tập hợp các mục sổ cái gồm bốn loại riêng biệt: tài khoản, đường tin cậy, ưu đãi và dữ liệu tài khoản. Tài khoản là người chủ sở hữu và phát hành tài sản. Mỗi tài khoản được đặt tên theo khóa công khai. Theo mặc định, khóa riêng tương ứng có thể ký giao dịch cho tài khoản. Tuy nhiên, các tài khoản có thể được cấu hình lại để thêm những người ký khác và hủy cấp phép khóa đặt tên cho tài khoản, bằng một Tùy chọn “multisig” để yêu cầu nhiều người ký. Mỗi tài khoản cũng chứa: số thứ tự (có trong giao dịch để tránh phát lại), một số cờ và số dư trong "bản địa" tiền điện tử được khai thác trước có tên là XLM, nhằm giảm thiểu một số cuộc tấn công từ chối dịch vụ và tạo điều kiện thuận lợi cho việc tạo lập thị trường như một loại tiền tệ trung lập. Trustlines theo dõi quyền sở hữu các tài sản đã phát hành, được đặt tên bởi một cặp bao gồm tài khoản phát hành và một tài khoản ngắn hạn mã tài sản (ví dụ: “USD” hoặc “EUR”). Mỗi đường dây tin cậy chỉ định một tài khoản, một tài sản, số dư của tài khoản trong tài sản đó, một vượt quá giới hạn mà số dư không thể tăng lên và một số cờ. Một tài khoản phải đồng ý rõ ràng để nắm giữ một tài sản bằng cách tạo ra một đường dây tin cậy, ngăn chặn những kẻ gửi thư rác tài khoản có tài sản không mong muốn. Quy định về nhận biết khách hàng (KYC) yêu cầu nhiều tổ chức tài chính phải biết họ đang nắm giữ tiền gửi của ai, ví dụ bằng cách kiểm tra ID ảnh. Để tuân thủ, tổ chức phát hành có thể thiết lập cờ auth_reqired tùy chọn trên tài khoản của họ, hạn chế quyền sở hữu tài sản mà họ cấp cho các tài khoản được ủy quyền. Để cấp phép như vậy, người phát hành thiết lập một ủy quyền gắn cờ trên đường tin cậy của khách hàng. Ưu đãi tương ứng với sự sẵn sàng giao dịch của tài khoản một số lượng nhất định của một tài sản cụ thể cho một tài sản khác tại một thời điểm nhất định giá trên sổ lệnh; chúng được tự động khớp và được lấp đầy khi giá mua/bán giao nhau. Cuối cùng, dữ liệu tài khoản bao gồm bộ ba tài khoản, khóa, giá trị, cho phép chủ tài khoản để xuất bản các giá trị siêu dữ liệu nhỏ. Để ngăn chặn thư rác sổ cái, cần có số dư XLM tối thiểu, gọi là dự trữ. Dự trữ của tài khoản tăng lên theo từng mục sổ cái liên quan và giảm khi mục sổ cái biến mất (ví dụ: khi một đơn hàng được thực hiện hoặc bị hủy, hoặc khi một đường dây tin cậy sẽ bị xóa). Hiện tại dự trữ tăng thêm 0,5 XLM (∼$0,03) cho mỗi mục sổ cái. Bất kể dự trữ là gì, nó là có thể lấy lại toàn bộ giá trị của tài khoản bằng cách xóa nó bằng thao tác AccountMerge. Tiêu đề sổ cái, được hiển thị trong Hình 3, lưu trữ các thuộc tính chung: số sổ cái, các thông số như số dư dự trữ trên mỗi mục sổ cái, hash của tiêu đề sổ cái trước đó (thực tế là một số hashes tạo thành danh sách bỏ qua), đầu ra SCP bao gồm hash giao dịch mới được áp dụng vào sổ cái này, hash trong số kết quả của các giao dịch đó (ví dụ: thành công hay thất bại đối với từng mục) và ảnh chụp nhanh hash của tất cả các mục trong sổ cái. Bởi vì ảnh chụp nhanh hash bao gồm tất cả nội dung sổ cái, validator không cần giữ lại lịch sử để xác thực giao dịch. Tuy nhiên, để mở rộng quy mô lên tới hàng trăm triệu dự kiến tài khoản, chúng tôi không thể rehash tất cả các bảng nhập sổ cái trên mỗi sổ cái đóng lại. Hơn nữa, việc chuyển sổ cáiThanh toán toàn cầu nhanh chóng và an toàn với Stellar SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada sổ cái # = 4 H(HDR trước) Đầu ra SCP H∗(kết quả) H∗(ảnh chụp nhanh) ... tiêu đề sổ cái # = 5 H(HDR trước) Đầu ra SCP H∗(kết quả) H∗(ảnh chụp nhanh) ... tiêu đề . . . Hình 3. Nội dung sổ cái. H là SHA-256, trong khi H ∗ thể hiện ứng dụng phân cấp hoặc đệ quy của đầu ra H. SCP cũng phụ thuộc vào tiêu đề trước hash. Tạo tài khoản Tạo và nạp tiền vào sổ cái tài khoản mới Hợp nhất tài khoản Xóa mục nhập sổ cái tài khoản Đặt tùy chọn Thay đổi cờ tài khoản và người ký Thanh toán Trả số lượng tài sản cụ thể cho đích. tài khoản. Đường dẫnThanh toán Giống như Thanh toán, nhưng thanh toán bằng nội dung khác (tối đa hạn chế); chỉ định tối đa 5 tài sản trung gian Quản lý ưu đãi Tạo/xóa/thay đổi mục nhập sổ cái ưu đãi, -Ưu đãi thụ động với biến thể thụ động để cho phép lan truyền bằng không Quản lý dữ liệu Tạo/xóa/thay đổi tài khoản. nhập sổ cái dữ liệu Thay đổi tin cậy Tạo/xóa/thay đổi đường dây tin cậy AllowTrust Đặt hoặc xóa cờ được ủy quyền trên đường dây tin cậy Trình tự va chạm Tăng thứ tự số trên tài khoản Hình 4. Hoạt động sổ cái chính có kích thước đó mỗi khi một nút bị ngắt kết nối khỏi mạng quá lâu. Do đó, ảnh chụp nhanh hash là được thiết kế để tối ưu hóa cả hashing và điều chỉnh trạng thái. Cụ thể, ảnh chụp nhanh phân loại các mục sổ cái theo thời gian sửa đổi cuối cùng trong một tập hợp các thùng chứa có kích thước theo cấp số nhân gọi là xô. Bộ sưu tập các thùng được gọi là thùng danh sách và có một số điểm tương đồng với cây hợp nhất có cấu trúc nhật ký (LSM-cây) [77]. Danh sách nhóm không được đọc trong quá trình xử lý giao dịch (xem Phần 5.4). Do đó, thiết kế nhất định các khía cạnh của cây LSM có thể được nới lỏng. Đặc biệt, ngẫu nhiên không cần truy cập bằng khóa và các nhóm chỉ được đọc tuần tự như một phần của các cấp độ hợp nhất. Băm xô danh sách được thực hiện bằng cách hashing từng nhóm khi nó được hợp nhất và tính toán hash tích lũy mới của nhóm hashes (nhỏ, chỉ số tham chiếu cố định hashes) khi đóng mỗi sổ cái. Điều chỉnh danh sách nhóm sau khi ngắt kết nối yêu cầu tải xuống chỉ có các thùng khác nhau. 5.2 Mô hình giao dịch Một giao dịch bao gồm một tài khoản nguồn, tiêu chí hợp lệ, một bản ghi nhớ và danh sách một hoặc nhiều thao tác. Hình 4 liệt kê các hoạt động có sẵn. Mỗi hoạt động có một tài khoản nguồn, tài khoản này mặc định cho giao dịch tổng thể. Một giao dịch phải được ký bằng các khóa tương ứng với mọi tài khoản nguồn trong một cuộc phẫu thuật. Tài khoản Multisig có thể yêu cầu chữ ký cao hơn trọng lượng cho một số thao tác (chẳng hạn như SetOptions) và thấp hơn cho những người khác (chẳng hạn như AllowTrust). Giao dịch là nguyên tử—nếu bất kỳ thao tác nào thất bại, không có thao tác nào họ thực thi. Điều này đơn giản hóa các giao dịch đa chiều. Giả sử một nhà phát hành tạo ra một tài sản để đại diện cho chứng thư đất đai và người dùng A muốn đổi một thửa đất nhỏ cộng thêm 10.000 USD lấy một thửa đất lớn hơn thuộc sở hữu của B. Hai người sử dụng đều có thể ký một giao dịch duy nhất bao gồm ba hoạt động: hai đất thanh toán và thanh toán một đô la. Tiêu chí hiệu lực chính của giao dịch là số thứ tự của nó, số này phải lớn hơn số thứ tự của giao dịch. mục nhập sổ cái tài khoản nguồn. Thực hiện một giao dịch hợp lệ (thành công hay không) tăng số thứ tự, ngăn chặn việc phát lại. Số thứ tự ban đầu chứa sổ cái số ở bit cao để tránh phát lại ngay cả sau khi xóa và tạo lại tài khoản. Tiêu chí hợp lệ khác là giới hạn tùy chọn khi một giao dịch có thể thực hiện. Trở về đất và đô la hoán đổi trên, nếu A ký giao dịch trước B thì A không được muốn B tham gia giao dịch trong một năm trước khi nộp đơn nó và do đó có thể đặt ra giới hạn thời gian làm mất hiệu lực giao dịch sau một vài ngày. Tài khoản Multisig cũng có thể được cấu hình để tạo sức thuyết phục cho việc tiết lộ hình ảnh trước hash, kết hợp với giới hạn thời gian, cho phép giao dịch chuỗi chéo nguyên tử [1]. Tài khoản nguồn của giao dịch trả một khoản phí nhỏ bằng XLM, 10−5 XLM trừ khi có tắc nghẽn. Dưới tình trạng tắc nghẽn, chi phí hoạt động được thiết lập bởi đấu giá Hà Lan. Trình xác nhận là không được trả phí vì validator tương tự tới Bitcoin nút đầy đủ, không phải công cụ khai thác. Thay vì phá hủy XLM, phí được tái chế và phân bổ theo tỷ lệ bằng phiếu bầu của những người nắm giữ XLM hiện có, mà nhìn lại có thể hoặc có thể không có giá trị phức tạp. 5.3 Giá trị đồng thuận Đối với mỗi sổ cái, Stellar sử dụng SCP để thống nhất về cấu trúc dữ liệu với ba trường: bộ giao dịch hash (bao gồm hash của tiêu đề sổ cái trước đó), thời gian đóng,d nâng cấp. Khi nhiều giá trị được xác nhận đề cử, Stellar sẽ thực hiện tập hợp giao dịch có nhiều hoạt động nhất (phá vỡ mối quan hệ theo tổng phí, sau đó là tập giao dịch hash), liên minh của tất cả nâng cấp và thời gian đóng cao nhất. Một thời gian gần gũi chỉ là hợp lệ nếu nó nằm trong khoảng thời gian đóng của sổ cái cuối cùng và hiện tại, do đó các nút không chỉ định thời gian không hợp lệ. Các bản nâng cấp điều chỉnh các tham số chung như số dư dự trữ, phí hoạt động tối thiểu và phiên bản giao thức. Khi nào được kết hợp trong quá trình đề cử, mức phí cao hơn và số phiên bản giao thức sẽ thay thế mức phí thấp hơn. Nâng cấp hiệu quả quản trị thông qua không gian tranh chấp biểu quyết liên bang [34], cũng không bình đẳng và không tập trung. Mỗi validator được định cấu hình là quản lý hoặc không quản lý (mặc định), theo liệu người điều hành nó có muốn tham gia quản trị hay không. validator quản trị xem xét ba loại nâng cấp: mong muốn, hợp lệ và không hợp lệ (bất cứ điều gì validator không

SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada Lokhava và cộng sự. validator cốt lõi chân trời FS cơ sở dữ liệu cơ sở dữ liệu nộp khách hàng khách hàng validator khác Hình 5. Kiến trúc Stellar validator biết cách thực hiện). Các nâng cấp mong muốn được cấu hình để kích hoạt tại một thời điểm cụ thể, nhằm mục đích phối hợp giữa các nhà khai thác. Các nút quản trị luôn bỏ phiếu để đề cử mong muốn nâng cấp, chấp nhận nhưng không bỏ phiếu để đề cử nâng cấp hợp lệ (tức là tuân theo số đại biểu chặn) và không bao giờ bỏ phiếu cho hoặc chấp nhận nâng cấp không hợp lệ. Tiếng vang validators không quản lý bất kỳ phiếu bầu nào họ thấy cho một bản nâng cấp hợp lệ, về cơ bản là ủy quyền quyết định về những nâng cấp mong muốn đối với những người lựa chọn cho vai trò quản trị. 5,4 Thực hiện Hình 5 hiển thị kiến trúc validator của Stellar. Một con quỷ được gọi là Stellar-core (∼92k dòng C++, không tính thư viện của bên thứ ba) triển khai giao thức SCP và máy trạng thái được sao chép. Việc tạo ra các giá trị cho SCP yêu cầu giảm số lượng lớn các mục sổ cái thành các mật mã nhỏ hashes. Ngược lại, việc xác nhận và thực hiện giao dịch yêu cầu tra cứu trạng thái tài khoản và khớp lệnh tại giá tốt nhất. Để phục vụ cả hai chức năng một cách hiệu quả, Stellar-core giữ hai cách trình bày của sổ cái: một cách trình bày bên ngoài chứa danh sách nhóm, được lưu trữ dưới dạng tệp nhị phân có thể được cập nhật một cách hiệu quả và được rehashed tăng dần, và một biểu diễn nội bộ trong cơ sở dữ liệu SQL (PostgreSQL cho các nút sản xuất). Stellar-core tạo kho lưu trữ lịch sử chỉ ghi có chứa mỗi bộ giao dịch đã được xác nhận và ảnh chụp nhanh của xô. Kho lưu trữ cho phép các nút mới tự khởi động khi tham gia mạng. Nó cũng cung cấp một bản ghi sổ cái lịch sử—cần có một nơi nào đó để người ta có thể tra cứu giao dịch từ hai năm trước. Vì lịch sử chỉ được thêm vào và được truy cập không thường xuyên, nó có thể được giữ ở những nơi rẻ tiền chẳng hạn như Amazon Glacier hoặc bất kỳ dịch vụ nào cho phép một người lưu trữ và truy xuất các tập tin phẳng. Máy chủ xác thực thường không lưu trữ tài liệu lưu trữ của riêng họ để tránh bất kỳ tác động nào đến việc xác thực hiệu suất từ lịch sử phục vụ. Để giữ cho lõi sao đơn giản, nó không được thiết kế để sử dụng trực tiếp bởi các ứng dụng và chỉ hiển thị một giao diện rất hẹp để gửi các giao dịch mới. Để hỗ trợ khách hàng, hầu hết validator đều chạy một daemon có tên là Horizon (∼18k dòng Go) cung cấp giao diện HTTP để gửi và tìm hiểu các giao dịch. Horizon có quyền truy cập chỉ đọc vào cơ sở dữ liệu SQL của Stellar-core, giảm thiểu rủi ro về chân trời làm mất ổn định lõi sao. Các tính năng như tìm đường dẫn thanh toán được triển khai hoàn toàn trong thời gian ngắn và có thể được nâng cấp đơn phương mà không phối hợp với validator khác. Một số daemon lớp cao hơn tùy chọn là ứng dụng khách ở đường chân trời, hoàn thiện hệ sinh thái. Một máy chủ cầu nối tạo điều kiện thuận lợi tích hợp Stellar với các hệ thống hiện có, ví dụ: đăng thông báo về tất cả các khoản thanh toán mà một tài khoản cụ thể nhận được. A máy chủ tuân thủ cung cấp các kết nối cho các tổ chức tài chính để trao đổi và phê duyệt thông tin người gửi và người thụ hưởng về thanh toán, để tuân thủ danh sách trừng phạt. Cuối cùng, một máy chủ liên kết thực hiện cách đặt tên mà con người có thể đọc được hệ thống cho các tài khoản. 6 Kinh nghiệm triển khai Stellar đã phát triển trong vài năm thành một tiểu bang có mức độ phát triển vừa phải số lượng nhà khai thác nút đầy đủ có độ tin cậy hợp lý. Tuy nhiên, cấu hình của các nút sao cho có tính sống động (mặc dù không an toàn) phụ thuộc vào chúng tôi, Quỹ Phát triển Stellar (SDF); SDF đột nhiên biến mất, các nhà khai thác nút khác sẽ cần phải can thiệp và loại bỏ chúng tôi theo cách thủ công từ các lát đại biểu để mạng tiếp tục. Trong khi chúng tôi và nhiều người khác muốn giảm tầm quan trọng mang tính hệ thống của SDF, mục tiêu này ngày càng được ưu tiên hơn sau các nhà nghiên cứu [58] đã định lượng và công khai tính tập trung của mạng mà không phân biệt các rủi ro đối với sự an toàn và sự sống động. Một số nhà khai thác đã phản ứng bằng các điều chỉnh cấu hình tích cực, chủ yếu là tăng kích thước cắt giảm số đại biểu trong nỗ lực làm giảm tầm quan trọng của SDF; Trớ trêu thay, điều này chỉ làm tăng nguy cơ ảnh hưởng đến sự sống. Hai vấn đề làm trầm trọng thêm tình hình. Đầu tiên, một phổ biến công cụ giám sát Stellar của bên thứ ba [5] được thực hiện một cách có hệ thống đánh giá quá cao validator thời gian hoạt động do không thực sự xác minh lõi sao đó đang chạy; điều này khiến mọi người bao gồm các nút không đáng tin cậy trong các lát đại biểu của chúng. Thứ hai, một lỗi trong lõi sao có nghĩa là khi validator được chuyển sang sổ cái tiếp theo, nó không giúp ích đầy đủ cho các nút còn lại hoàn thành giai đoạn trướcsổ cái trong trường hợp mất tin nhắn. Kết quả là, mạng đã trải qua 67 phút ngừng hoạt động và được yêu cầu quản trị viên validator phối hợp thủ công để khởi động lại. Tệ hơn nữa, trong khi cố gắng khởi động lại mạng, việc cấu hình lại vội vàng đồng thời trên nhiều nút đã dẫn đến kết quả là trong một cấu hình sai tập thể cho phép một số nút phân kỳ, yêu cầu tắt thủ công các nút đó và gửi lại các giao dịch được chấp nhận trong thời gian phân kỳ. May mắn thay, sự khác biệt này đã được phát hiện và khắc phục nhanh chóng và không chứa các giao dịch xung đột, nhưng nguy cơ mạng không đạt được giao điểm đại biểu— chia rẽ trong khi vẫn tiếp tục chấp nhận những xung đột tiềm ẩn giao dịch, đơn giản là do cấu hình sai—đã được thực hiện rất cụ thể về sự việc này. Việc xem xét lại những kinh nghiệm này dẫn đến hai kết luận chính và các hành động khắc phục tương ứng.Thanh toán toàn cầu nhanh chóng và an toàn với Stellar SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada Quan trọng, 100% 51% 51% Cao, 67% 51% Trung bình, 67% 51% Thấp, 67% 51% 51% ... ... ... 51% ... 51% Hình 6. Phân cấp chất lượng của trình xác thực. Các nút chất lượng cao nhất yêu cầu ngưỡng cao nhất là 100%, trong khi chất lượng thấp hơn được định cấu hình ở ngưỡng 67%. Các nút trong một tổ chức yêu cầu đa số đơn giản là 51%. 6.1 Cấu hình phức tạp và dễ vỡ Stellar biểu thị các lát cắt đại biểu dưới dạng tập hợp đại biểu lồng nhau bao gồm n mục nhập và ngưỡng k trong đó bất kỳ tập hợp k mục nào tạo thành một lát đại biểu. Mỗi mục trong số n mục sau đó là một khóa công khai validator hoặc theo cách đệ quy, một tập đại biểu khác. Mặc dù linh hoạt và nhỏ gọn, chúng tôi đã nhận ra số đại biểu lồng nhau đặt đồng thời các toán tử nút có quá nhiều tính linh hoạt và quá ít hướng dẫn: rất dễ viết không an toàn (hoặc thậm chí là cấu hình vô nghĩa). Tiêu chí phân nhóm các nút thành các tập hợp, để tổ chức các tập hợp con thành một hệ thống phân cấp và để lựa chọn các ngưỡng đều không đủ rõ ràng và góp phần gây ra những thất bại trong hoạt động. Không rõ liệu có nên coi một “cấp độ” trong hệ thống phân cấp lồng nhau là một mức độ tin cậy, hoặc một tổ chức, hoặc cả hai; nhiều cấu hình trong lĩnh vực này trộn lẫn các khái niệm này, ngoài việc xác định mức độ nguy hiểm hoặc ngưỡng vô nghĩa. Do đó chúng tôi đã thêm một cơ chế cấu hình đơn giản hơn phân tách hai khía cạnh của các nhóm đại biểu lồng nhau: nhóm các nút lại với nhau theo tổ chức và gắn nhãn cho mỗi tổ chức bằng một phân loại tin cậy đơn giản (thấp, trung bình, cao hoặc quan trọng). Các tổ chức ở cấp cao trở lên được yêu cầu phải xuất bản kho lưu trữ lịch sử. Hệ thống mới tổng hợp các tập hợp đại biểu lồng nhau trong đó mỗi tổ chức được biểu diễn dưới dạng Đã đặt ngưỡng 51% và các tổ chức được nhóm thành các nhóm với ngưỡng 67% hoặc 100% (tùy chất lượng nhóm). Mỗi nhóm là một mục duy nhất trong nhóm tiếp theo (chất lượng cao hơn), như minh họa trong Hình 6. Mô hình đơn giản hóa này làm giảm khả năng cấu hình sai, cả về mặt cấu trúc của các tập hợp lồng nhau được tổng hợp và các ngưỡng được chọn cho mỗi bộ. 6.2 Chủ động phát hiện cấu hình sai Thứ hai, chúng tôi nhận ra rằng việc phát hiện hành vi cấu hình sai tập thể bằng cách chờ quan sát tác động tiêu cực của nó là quá muộn. Đặc biệt đối với các cấu hình sai có thể khác nhau—a chế độ lỗi nghiêm trọng hơn là tạm dừng—mạng cần có thể phát hiện cấu hình sai ngay lập tức để người vận hành có thể hoàn nguyên cấu hình đó trước khi bất kỳ sự khác biệt nào thực sự xảy ra. Để giải quyết nhu cầu này, chúng tôi đã xây dựng một cơ chế trong phần mềm validator để liên tục thu thập trạng thái cấu hình chung của tất cả các nút ngang hàng trong quá trình đóng chuyển tiếp của nút và phát hiện khả năng phân kỳ—tức là rời rạc nhóm túc số—trong cấu hình tập thể đó. 6.2.1 Kiểm tra giao lộ đại biểu Mặc dù việc thu thập các nhóm đại biểu là điều dễ dàng nhưng việc tìm ra các nhóm túc số rời rạc trong số đó là việc khó [62]. Tuy nhiên, chúng tôi đã thông qua một tập hợp các phương pháp chẩn đoán thuật toán và quy tắc loại bỏ trường hợp được đề xuất bởi Lachowski [62] để kiểm tra các trường hợp điển hình của vấn đề nhanh hơn nhiều bậc so với chi phí trong trường hợp xấu nhất. Thực tế mà nói, mạng hiện tại các lần đóng chuyển tiếp lát cắt đại biểu theo thứ tự 20–30 các nút và, với sự tối ưu hóa của Lachowski, thường kiểm tra chỉ trong vài giây trên một CPU. Nếu có nhu cầu phát sinh để nâng cao hiệu suất, chúng tôi có thể thực hiện tìm kiếm song song. 6.2.2 Kiểm tra cấu hình rủi ro Phát hiện mạng thừa nhận các đại biểu rời rạc là một bước đi đúng hướng nhưng báo nguy hiểm muộn một cách khó chịu đối với một vấn đề quan trọng như vậy. Lý tưởng nhất là chúng tôi muốn các nhà khai thác nút nhận được cảnh báo khi cấu hình chung của mạng chỉ đang tiến đến một trạng thái rủi ro. Do đó, chúng tôi đã mở rộng trình kiểm tra giao điểm đại biểu để phát hiện một điều kiện mà chúng tôi gọi là tới hạn: khi dòng điện cấu hình tập thể chỉ là một cấu hình sai một tiểu bang thừa nhận số đại biểu rời rạc. Để phát hiện mức độ nghiêm trọng, trình kiểm tra liên tục thay thế cấu hình của mỗi tổ chức bằng cấu hình sai mô phỏng trong trường hợp xấu nhất, sau đó chạy lại trình kiểm tra giao điểm đại biểu bên trong trên kết quả. Nếu có bất kỳ cấu hình sai nghiêm trọng nào như vậy tồn tại thì chỉ còn một bước nữa là từ trạng thái hiện tại, phần mềm sẽ đưa ra cảnh báo và báo cáo tổ chức gây ra rủi ro cấu hình sai. Những thay đổi này cung cấp cho cộng đồng các nhà khai thác hai lớp thông báo và hướng dẫn cách ly chống lại các hình thức tồi tệ nhất của việc cấu hình sai tập thể.

評価

Stellar network quorum slice map showing validator nodes and their bidirectional dependencies

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]。さらに、データベースを多用する 台帳の更新時間は、標準のバッチ処理およびプリフェッチ技術によって改善できます。

Sự đánh giá

Stellar network quorum slice map showing validator nodes and their bidirectional dependencies

Để hiểu sự phù hợp của Stellar với tư cách là phương thức thanh toán toàn cầu và mạng lưới giao dịch, chúng tôi đã đánh giá trạng thái của mạng công cộng và chạy các thí nghiệm có kiểm soát trên một phòng thí nghiệm riêng mạng. Chúng tôi tập trung vào các câu hỏi sau: • Cấu trúc liên kết mạng sản xuất trông như thế nào? Trung bình có bao nhiêu tin nhắn được phát đi và SCP trải qua thời gian chờ như thế nào? • Độ trễ đồng thuận và cập nhật sổ cái có còn độc lập với số lượng tài khoản không?SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada Lokhava và cộng sự. • Độ trễ bị ảnh hưởng như thế nào khi tăng (a) giao dịch trên giây (và do đó, giao dịch trên mỗi giây) sổ cái) và (b) số nút validator? • Chi phí chạy một nút tính theo CPU là bao nhiêu, bộ nhớ và băng thông mạng? Mạng thanh toán có tỷ lệ giao dịch thấp so với với các loại hệ thống phân tán khác. blockchain hàng đầu, Bitcoin và Ethereum, xác nhận tối đa 15 giao dịch/giây, nhỏ hơn Stellar. Hơn nữa, các hệ thống này mất vài phút để một giờ để xác nhận giao dịch một cách an toàn, vì bằng chứng công việc yêu cầu phải chờ một số khối được khai thác. các mạng không phảiblockchain SWIFT chỉ đạt trung bình 420 giao dịch mỗi giây vào ngày cao điểm [14]. Do đó chúng tôi đã chọn để so sánh số đo của chúng tôi với mục tiêu 5 giây khoảng thời gian sổ cái, một mục tiêu tích cực hơn. Kết quả của chúng tôi cho thấy độ trễ ở dưới mức giới hạn này một cách thoải mái ngay cả với một số tối ưu hóa chưa được thực hiện vẫn đang được thực hiện. 7.1 Neo Các tài sản được giao dịch nhiều nhất theo khối lượng bao gồm tiền tệ (ví dụ: 3 USD neo, 2 CNY), neo Bitcoin, chứng khoán được hỗ trợ bởi bất động sản token [92] và tiền tệ trong ứng dụng [8]. Các neo khác nhau có chính sách khác nhau. Ví dụ: một mỏ neo USD, Stronghold, đặt auth_reqired và yêu cầu quy trình xác định khách hàng (KYC) cho mọi tài khoản nắm giữ tài sản. Một cái khác, AnchorUSD, để mọi người nhận và giao dịch USD của họ (làm cho việc gửi 0,50 USD đến Mexico theo đúng nghĩa đen là có thể trong 5 giây với mức phí 0,000001 USD). Tuy nhiên, AnchorUSD không yêu cầu KYC và phí để mua hoặc đổi USD của họ với chuyển khoản thông thường. Ở Philippines, nơi các quy định của ngân hàng lỏng lẻo hơn đối với các khoản thanh toán đến, coins.ph hỗ trợ rút tiền PHP tại bất kỳ máy ATM nào [36]. Ngoài bảo mật token và đơn vị tiền tệ trong ứng dụng nói trên, còn có nhiều loại token phi tiền tệ khác nhau, từ trái phiếu thương mại [22] và tín chỉ carbon [85, 96] trở lên nội dung bí truyền chẳng hạn như token khuyến khích cộng tác thu hồi xe [35]. 7.2 Mạng công cộng Tính đến thời điểm viết bài này, có 126 nút đầy đủ đang hoạt động, 66 trong số đó tham gia thống nhất bằng cách ký vào tin nhắn biểu quyết. Hình 7 (được tạo bởi [5]) trực quan hóa mạng, với một đường giữa hai nút nếu một nút xuất hiện trong các lát đại biểu của nút kia và một đường màu xanh đậm hơn để hiển thị sự phụ thuộc hai chiều. Tại trung tâm là một cụm gồm 17 “cấp một validators” trên thực tế được điều hành bởi SDF, SatoshiPay, LOBSTR, COINQVEST và Keybase. Bốn tháng trước, trước sự kiện ở Phần 6, có có 15 nút quan trọng về mặt hệ thống: 3 từ dường như các tổ chức cấp một và một số đơn vị ngẫu nhiên. các biểu đồ cũng trông kém đều đặn hơn nhiều. Do đó, cơ chế cấu hình mới và/hoặc các quyết định vận hành tốt hơn dường như để góp phần tạo nên cấu trúc liên kết mạng lành mạnh hơn. không có nguồn tài chính lớn (và cổ đông tương ứng Hình 7. Bản đồ lát cắt đại biểu nghĩa vụ), sẽ rất khó để tuyển dụng 5 cấp một Tuy nhiên, các tổ chức ngay từ đầu. Điều này cho thấy số đại biểu các lát cắt đóng một vai trò hữu ích trong quá trình khởi động mạng: bất kỳ ai cũng có thể tham gia với mục tiêu trở thành một người chơi quan trọng bởi vì không có người gác cổng để thỏa thuận theo cặp. Hiện có hơn 3,3 triệu tài khoản trong sổ cái. Kết thúc trong khoảng thời gian 24 giờ gần đây, Stellar trung bình có 4,5 giao dịch và 15,7 hoạt động mỗi giây. Xem lại sổ cái gần đây, hầu hết các giao dịch dường như chỉ có một thao tác duy nhất, trong khi cứ một vài giao dịch sổ cái chúng ta thấy các giao dịch chứa nhiều hoạt động dường như đến từ việc các nhà tạo lập thị trường quản lý các chào hàng. các thời gian cần thiết để đạt được sự đồng thuận và cập nhật sổ cái là lần lượt là 1061 ms và 46 ms. Phân vị thứ 99 là 2252 ms và 142 ms (trước đây phản ánh thời gian chờ 1 giây trong việc lựa chọn lãnh đạo đề cử). Lưu ý hiệu suất của SCP là hầu như độc lập với các giao dịch mỗi giây, vì SCP đồng ý với hash nhiều giao dịch tùy ý. Nút thắt có nhiều khả năng phát sinh từ việc tuyên truyền ứng cử viên giao dịch trong quá trình đề cử, thực hiện và xác nhận giao dịch và nhóm hợp nhất. Chúng tôi vẫn chưa cần để song song quá trình xử lý giao dịch của Stellar-Core trên nhiều lõi CPU hoặc ổ đĩa. Chúng tôi cũng đã đánh giá số lượng tin nhắn SCP được phát đi trên mạng sản xuất. Trong trường hợp bình thường với một lãnh đạo được bầu để đề cử một giá trị, chúng tôi mong đợi bảy hợp lý tin nhắn được phát sóng: hai tin nhắn để bỏ phiếu và chấp nhận một nomituyên bố nate, hai tin nhắn để chấp nhận và xác nhận một tuyên bố chuẩn bị, hai tin nhắn để chấp nhận và xác nhận một tuyên bố cam kết và cuối cùng là một thông báo bên ngoài (được gửi sau khi ghi một sổ cái mới vào đĩa để giúp những người đi lạc bắt kịp). Việc thực hiện kết hợp xác nhận cam kết và hiển thị các thông điệp như một sự tối ưu hóa, vì nó an toàn để đưa ra ngoài một giá trị sau khi nó được cam kết. Sau đó, chúng tôi phân tích các số liệu được thu thập trong quá trình sản xuất Stellar validator. Kết thúc trong 68 giờ, 1,3 tin nhắn/giây được phát ra, trung bình có 6-7 tin nhắn trên mỗi sổ cái. Chúng tôi lưu ý rằng tổng

Thanh toán toàn cầu nhanh chóng và an toàn với Stellar SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada Phần trăm Số lần hết giờ Đề cử Bỏ phiếu 75% 0 0 99% 1 0 Tối đa 4 1 Hình 8. Thời gian chờ trên mỗi sổ cái hơn 68 giờ số lượng tin nhắn được phát bởi validators lớn hơn vì trong Ngoài các tin nhắn biểu quyết liên kết, các nút còn phát sóng bất kỳ giao dịch nào họ tìm hiểu. Hình 8 cho thấy thời gian chờ của quá trình sản xuất validator trong khoảng thời gian 68 giờ. Thời gian chờ đề cử là thước đo tính hiệu quả (trong) của chức năng bầu cử người lãnh đạo, trong khi thời gian chờ bỏ phiếu phụ thuộc nhiều vào mạng và sự chậm trễ của tin nhắn có thể xảy ra. Thời gian chờ nhất quán với số lượng tin nhắn được phát ra: sáu tin nhắn trong trường hợp tốt nhất và ít nhất bảy tin nhắn nếu cần một vòng đề cử bổ sung. 7.3 Thí nghiệm có kiểm soát Chúng tôi đã tiến hành các thí nghiệm có kiểm soát trong các thùng chứa được đóng gói trên Phiên bản Amazon EC2 c5d.9xlarge có RAM 72 GiB, 900 GB SSD NVMe và 36 vCPU. Mỗi trường hợp nằm trong cùng vùng EC2 và có băng thông cố định 10 Gbps. Chúng tôi đã sử dụng SQLite làm cửa hàng. (Stellar cũng hỗ trợ PostgreSQL, nhưng nó có các tác vụ không đồng bộ gây nhiễu vào các phép đo.) Stellar cung cấp truy vấn thời gian chạy tích hợp, tạo tải, cho phép tạo tải tổng hợp tại một mục tiêu cụ thể giao dịch/tỷ lệ thứ hai. Mặc dù Stellar hỗ trợ nhiều các tính năng giao dịch, chẳng hạn như sổ đặt hàng và đường dẫn tài sản chéo thanh toán, chúng tôi tập trung vào thanh toán đơn giản. Việc xác nhận giao dịch bao gồm nhiều bước, vì vậy chúng tôi ghi lại các phép đo cho mỗi trường hợp sau: • Đề cử: thời gian từ khi đề cử đến khi chuẩn bị lần đầu • Bỏ phiếu: thời gian từ khi chuẩn bị lần đầu đến khi xác nhận phiếu cam kết • Cập nhật sổ cái: thời gian áp dụng giá trị đồng thuận • Số lượng giao dịch: số giao dịch được xác nhận trên mỗi sổ cái Mỗi thử nghiệm của chúng tôi được xác định bởi ba tham số: số lượng tài khoản trong sổ cái, số tiền tải (dưới dạng thanh toán XLM) được gửi mỗi giây, và số lượng validator giây. Chúng tôi đã định cấu hình mọi validator biết về mọi validator khác (trường hợp xấu nhất cho SCP), với các lát đại biểu được đặt thành bất kỳ phần lớn đơn giản nào các nút (để tối đa hóa số lượng đại biểu khác nhau). Đường cơ sở Thử nghiệm cơ bản của chúng tôi đã đo Stellar bằng 100.000 tài khoản, bốn validator và tạo tải tốc độ 100 giao dịch/giây. Chúng tôi quan sát thấy trung bình 507 giao dịch trên mỗi sổ cái, với độ lệch chuẩn là 49. (9,7%). Lưu ý rằng không có giao dịch nào bị hủy; sự nhẹ nhàng 105 106 107 0 500 1.000 1.500 2.000 Tài khoản Độ trễ [ms] Cập nhật sổ cái Bỏ phiếu Đề cử Hình 9. Độ trễ khi số lượng tài khoản tăng lên phương sai là do các hạn chế về lịch trình của bộ tạo tải. Chúng tôi quan sát thấy rằng số lượng giao dịch trên mỗi sổ cái phù hợp với tốc độ tạo tải của chúng tôi, dựa trên sổ cái đóng mỗi 5 giây. Đề cử, bỏ phiếu và sổ cái bản cập nhật cho thấy độ trễ trung bình là 82,53 ms, 95,96 ms và tương ứng là 174,08 ms. Chúng tôi quan sát thấy độ trễ đề cử Phân vị thứ 99 luôn dưới 61 mili giây, thỉnh thoảng tăng đột biến khoảng 1 giây, tương ứng với bước đầu tiên trong chức năng hết thời gian của việc lựa chọn người lãnh đạo. Dựa trên hiệu suất cơ bản, chúng tôi đã xem xét tác động thay đổi từng thông số thiết lập thử nghiệm. Tài khoản Dữ liệu trong Hình 9 gợi ý rằng thang đo Stellar cũng như số lượng tài khoản tăng lên. Tạo thử nghiệm tài khoản đã trở thành một quá trình kéo dài vì việc tạo nhóm và việc hợp nhất đã ngăn cản chúng tôi điền vào cơ sở dữ liệu với các tài khoản trực tiếp qua SQL. Vì vậy, chúng tôi đã tiến hành thử nghiệm cho tối đa 50.000.000 tài khoản. Trong khi có tác động tối thiểu đến sự đồng thuận và độ trễ cập nhật sổ cái, chúng tôi lưu ý rằng việc tăng tài khoản sẽ tạo ra chi phí chung các thùng hợp nhất sẽ lớn hơn. Tỷ giá giao dịch Tỷ giá giao dịch ảnh hưởng đến số lượng lưu lượng truy cập đa hướng giữa validator, số lượng giao dịch có trong mỗi sổ cái và kích thước của cấp cao nhất xô. Để hiểu tác động của việc tăng giao dịch tải, chúng tôi đã chạy thử nghiệm với 100.000 tài khoản và 4 validators. Hình 10 cho thấy độ trễ đồng thuận tăng chậm, trong khi phần lớn thời gian được dành để cập nhật sổ cái. Không có gì ngạc nhiên khi tập giao dịch tăng kích thước, nó mất nhiều thời gian hơn để đưa nó vào cơ sở dữ liệu. Chúng tôi cũng lưu ý rằng độ trễ cập nhật sổ cái phụ thuộc rất nhiều vào việc thực hiện, và bị ảnh hưởng bởi việc lựa chọn cơ sở dữ liệu. Các nút xác thực Để xem số cấp bậc validators tăng như thế nàotác động đến hiệu suất, chúng tôi đã chạy thử nghiệm với 100.000 tài khoản, 100 giao dịch/giây và số lượng validator khác nhau từ 4 đến 43. Tất cả validator đều xuất hiện trong tất cả các phần đại biểu của validator; lát đại biểu nhỏ hơn sẽ có tác động ít hơn đến hiệu suất.SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada Lokhava và cộng sự. 100 150 200 250 300 350 0 500 1.000 1.500 2.000 Tải [giao dịch/giây] Độ trễ [ms] Cập nhật sổ cái Bỏ phiếu Đề cử Hình 10. Độ trễ khi tải giao dịch tăng lên 10 20 30 40 0 500 1.000 1.500 2.000 Trình xác nhận Độ trễ [ms] Cập nhật sổ cái Bỏ phiếu Đề cử Hình 11. Độ trễ khi số lượng nút tăng lên Thay đổi số lượng nút xác thực trên mạng ảnh hưởng đến số lượng tin nhắn SCP được trao đổi cũng như số lượng giá trị tiềm năng trong quá trình đề cử. Hình 11 cho thấy thời gian đề cử tăng với tốc độ tương đối nhỏ. Mặc dù dữ liệu cho thấy việc bỏ phiếu là điểm nghẽn, chúng tôi tin rằng nhiều vấn đề về quy mô có thể được giải quyết bằng cách cải thiện Mạng lớp phủ của Stellar để tối ưu hóa lưu lượng truy cập mạng. Như dự kiến, độ trễ cập nhật sổ cái vẫn độc lập với số lượng nút. Tỷ lệ đóng Cuối cùng, chúng tôi muốn đo lường hiệu suất từ đầu đến cuối của Stellar bằng cách đo tần suất các sổ cái được xác nhận và liệu Stellar có đáp ứng được mục tiêu 5 giây của nó mà không bỏ bất kỳ giao dịch nào. Chúng tôi quan sát thấy sổ cái trung bình đóng lần 5,03 giây, 5,10 giây và 5,15 giây khi chúng tôi tăng tài khoản các mục nhập, tỷ lệ giao dịch và số lượng nút tương ứng. Kết quả cho thấy Stellar có thể đóng sổ cái một cách nhất quán dưới tải cao. 7.4 Đang chạy validator Một trong những tính năng quan trọng của Stellar là chi phí thấp đang chạy validator, vì các neo sẽ chạy (hoặc ký hợp đồng với) validators để thực thi quyết định cuối cùng. SDF chạy 3 validator sản xuất, tất cả đều trên phiên bản AWS c5.large có hai lõi, RAM 4 GiB và CPU Intel(R) Xeon(R) Platinum 8124M @ Bộ xử lý 3.00GHz. Kiểm tra việc sử dụng tài nguyên trên một trong số các máy này, chúng tôi đã quan sát quy trình Stellar bằng cách sử dụng khoảng 7% CPU và 300 MiB bộ nhớ. Về lưu lượng mạng, với 28 kết nối tới các thiết bị ngang hàng và quy mô đại biểu trong số 34, tốc độ đến và đi là 2,78 Mbit/s và tương ứng là 2,56 Mbit/s. Phần cứng cần thiết để chạy như vậy quá trình là không tốn kém. Trong trường hợp của chúng tôi, chi phí là 0,054 USD/giờ hoặc khoảng $40/tháng. 7,5 Công việc tương lai Những thử nghiệm này cho thấy Stellar có thể dễ dàng mở rộng quy mô từ 1–2 đơn hàng có tầm quan trọng vượt xa mức sử dụng mạng ngày nay. Bởi vì nhu cầu về hiệu suất cho đến nay vẫn rất khiêm tốn, Stellar nhường chỗ cho nhiều cách tối ưu hóa đơn giản bằng cách sử dụng những kỹ thuật nổi tiếng. Ví dụ: giao dịch và SCP tin nhắn được phát bởi validator bằng cách sử dụng tính năng tràn ngập đơn giản giao thức, nhưng lý tưởng nhất là nên sử dụng hiệu quả hơn, có cấu trúc hơn phát đa hướng ngang hàng [30]. Ngoài ra, cơ sở dữ liệu nặng Thời gian cập nhật sổ cái có thể được cải thiện thông qua các kỹ thuật phân nhóm và tìm nạp trước tiêu chuẩn.

結論

国際決済は高額で日数もかかります。基金 保管はコルレス銀行や送金サービスを含む複数の金融機関を経由します。 各ホップは完全に信頼される必要があるため、新しいホップは困難です。 参入者は市場シェアを獲得し、競争します。 Stellar の番組 数秒で世界中に安く送金する方法。の 主要な革新は、ピアツーピア構造を活用した新しいオープンメンバーシップのビザンチン協定プロトコルである SCP です。 世界的なコンセンサスを達成するための金融ネットワークの構築 新しいインターネット仮説。 SCP は Stellar をアトミックにコミットさせます 任意の参加者間の不可逆的なトランザクション。 お互いのことを知らないし信頼もしていない。これにより、新規参入者が既存の市場と同じ市場にアクセスできることが保証されます。 プレーヤーは、利用可能な最高の交換を安全に入手できます 信頼できないマーケットメーカーからのレートであっても、劇的に上昇します。 支払いの待ち時間を短縮します。 謝辞 Stellar は、初期の ジョイス・キムのリーダーシップまたは多大な貢献 スコット・フレッケンシュタインとバルテック・ノヴォタルスキーが建築と Horizon、Stellar SDK、およびその他の重要な要素の維持 Stellar エコシステムの。コルテン・ベルジェロンにも感謝します。 ヘンリー・コリガン＝ギブス、キャンディス・ケリー、カピル・K・ジェイン、ボリス レズニコフ、ジェレミー・ルービン、クリスチャン・ラダー、エリック・サンダース、 Torsten Stüber、Tomer Weller、匿名の査読者、 私たちの羊飼いのジャスティン・シェリーさんに有益なコメントをいただきました 以前の草案。 免責事項 マジエール教授のこの出版物への貢献は有償コンサルタントとしてのものであり、教授の活動の一部ではありませんでした。 スタンフォード大学の義務または責任。

Stellar による高速かつ安全なグローバル支払い SOSP ’19、2019 年 10 月 27 ～ 30 日、カナダ、オンタリオ州ハンツビル

Phần kết luận

Thanh toán quốc tế rất tốn kém và mất nhiều ngày. Quỹ quyền giám hộ đi qua nhiều tổ chức tài chính bao gồm các ngân hàng đại lý và dịch vụ chuyển tiền. Bởi vì mỗi bước nhảy phải được tin cậy hoàn toàn nên rất khó cho các bước nhảy mới. những người tham gia để giành thị phần và cạnh tranh. Stellar trình chiếu cách gửi tiền khắp thế giới với chi phí rẻ chỉ trong vài giây. các cải tiến quan trọng là giao thức thỏa thuận Byzantine dành cho thành viên mở mới, SCP, thúc đẩy cấu trúc ngang hàng của mạng lưới tài chính để đạt được sự đồng thuận toàn cầu theo một giả thuyết Internet mới lạ. SCP cho phép Stellar cam kết nguyên tử giao dịch không thể đảo ngược giữa những người tham gia tùy ý không biết hoặc tin tưởng lẫn nhau. Điều đó đảm bảo cho những người mới tham gia tiếp cận được các thị trường giống như đã được thiết lập người chơi, đảm bảo an toàn để có được trao đổi tốt nhất hiện có ngay cả từ những nhà tạo lập thị trường không đáng tin cậy, và đáng kể giảm độ trễ thanh toán. Lời cảm ơn Stellar sẽ không có được ngày hôm nay nếu không sớm sự lãnh đạo của Joyce Kim hay những đóng góp to lớn của Scott Fleckenstein và Bartek Nowotarski trong việc xây dựng và duy trì chân trời, Stellar SDK và các phần quan trọng khác của hệ sinh thái Stellar. Chúng tôi cũng cảm ơn Kolten Bergeron, Henry Corrigan-Gibbs, Candace Kelly, Kapil K. Jain, Boris Reznikov, Jeremy Rubin, Christian Rudder, Eric Saunders, Torsten Stüber, Tomer Weller, những người đánh giá ẩn danh, và người chăn cừu Justine Sherry của chúng tôi vì những nhận xét hữu ích của họ về những bản thảo trước đó. Tuyên bố từ chối trách nhiệm Đóng góp của Giáo sư Mazières cho ấn phẩm này là một nhà tư vấn được trả lương chứ không phải là một phần trong công việc của ông. Nhiệm vụ hoặc trách nhiệm của Đại học Stanford.

Thanh toán toàn cầu nhanh chóng và an toàn với Stellar SOSP '19, ngày 27–30 tháng 10 năm 2019, Huntsville, ON, Canada