Giao thức đồng thuận Stellar
摘要
国际支付缓慢且昂贵，部分原因是通过异构的多跳支付路由 银行系统。 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 墨西哥，两个邻国。最终用户支付近 9 美元 平均此类转让 [32]，以及双边协议 由各国央行斡旋只能减少 每个项目 [2] 的基础银行成本为 0.67 美元。除了费用之外， 国际支付的延迟一般都算在内 几天之内，就不可能在短时间内快速将钱转移到国外 紧急情况。在没有银行系统的国家 工作或不为所有公民提供服务，或者在费用无法忍受的情况下，人们求助于通过巴士 [38] 发送付款， 乘船[19]，现在偶尔乘Bitcoin [55]，所有这些 招致风险、延迟或不便。 虽然合规成本始终存在，但有证据表明，由于缺乏竞争而损失了大量成本[21]， 低效的技术加剧了这种情况。凡人 可以创新，价格和延迟都会下降。例如，2019 年第二季度的银行账户汇款平均费用为 6.99%，而移动货币仅为4.88%[13]。 吸引创新的开放的全球支付网络 来自非银行实体的竞争可能会压低 所有层的成本和延迟，包括合规性 [83]。 本文提出了 Stellar，一种基于 blockchain 的支付方式 专门为促进创新而设计的网络 国际支付的竞争。 Stellar 是第一个 系统以满足以下所有三个目标（在 新颖但经验有效的“互联网假设”）： 1. 开放会员制——任何人都可以发行货币支持 可以在用户之间交换的数字token。 2. 发行人强制的最终性 – token 的发行人可以阻止 token 中的交易被撤销或撤消。 3. 跨发行者原子性——用户可以原子地交换 并交易来自多个发行人的 token。 实现前两个目标很容易。任何公司都可以单方面提供Paypal、Venmo、微信等产品 支付宝或支付宝并确保付款的最终性 他们创造的虚拟货币。不幸的是，跨这些货币进行原子交易是不可能的。事实上， 尽管 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 有两个显着的属性。 首先，它本身支持 tokens 之间的有效市场 来自不同的发行人。具体来说，任何人都可以发出 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是否代表资产v1甚至听说过 的。假设这些协议关系 传递连接整个网络，SCP保证 全球协议，使其成为全球拜占庭协议 具有开放成员资格的协议。我们将这种新的连通性假设称为互联网假设，并注意到它 拥有“互联网”（每个人都理解为 指单个最大的可传递连接的 IP 网络） 以及传统的国际支付（逐跳 非原子的，但利用传递连接的全局 金融机构网络）。 Stellar 自 2015 年 9 月起已投入生产使用。 为了保持 blockchain 长度易于管理，系统运行 SCP 以 5 秒为间隔——按照 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) 是一种基于法定人数的协议 具有开放成员资格的拜占庭协议协议。仲裁是由各个节点的本地配置决策组合而成的。然而，节点只识别 他们自己所属的法定人数，并且只有在之后 了解所有其他仲裁成员的本地配置。这种方法的一个好处是 SCP 本质上 容忍节点存在的异构视图。因此， 节点可以单方面加入和离开，无需 协调成员资格的“视图变更”协议。 3.1 联邦拜占庭协议 传统的拜占庭协议问题包括 N 个节点的封闭系统，其中一些节点出现故障，可能会 行为任意。节点接收输入值并交换 消息来决定输入中的输出值。 当没有两个行为良好的节点输出不同的决策并且唯一的决策时，拜占庭协议是安全的。 决定是一个有效的输入（对于有效商定的某些定义SOSP '19，2019 年 10 月 27-30 日，加拿大安大略省亨茨维尔 洛哈瓦等人。 事先）。当协议保证以下内容时，它就是有效的： 每个诚实节点最终都会输出一个决策。 通常，协议假设某个整数 N = 3f + 1 f > 0，然后保证安全性和某种形式的活性 只要最多 f 个节点出现故障。在这些过程中的某个阶段 协议、节点对提议值和提案进行投票 收到 2f + 1 票，称为投票法定人数，变为 的决定。对于 N = 3f + 1 个节点，任意两个法定人数 大小 2f + 1 在至少 f + 1 个节点中重叠；即使其中 f 重叠节点有故障，两个法定人数至少共享 一个无故障的节点，防止矛盾的决策。 然而，这种方法只有在所有节点都同意的情况下才有效 什么构成了法定人数，这在 SCP 中是不可能的 两个节点甚至可能不知道彼此的存在。 通过 SCP，每个节点 v 单方面声明节点集， 称为它的仲裁切片，使得 (a) v 相信如果所有 切片的成员就系统的状态达成一致，然后 他们是对的，并且 (b) v 相信至少其中一个切片 将能够及时提供有关 系统的状态。我们称由此产生的系统为 节点及其切片，联邦拜占庭协议 （FBA）系统。正如我们接下来将看到的，法定人数系统出现了 来自节点的切片。 非正式地，FBA 节点的切片表示该节点与谁 节点需要同意。例如，一个节点可能需要与 4 个特定组织达成协议，每个组织运行 3 个节点；到 适应停机时间，它可以将其切片设置为全部集合 由每个组织的 2 个节点组成。如果这“需要 同意”关系传递地关联任意两个节点， 我们达成全球协议。否则，我们会得到分歧， 但仅限于双方都不需要的组织之间 与对方达成一致。考虑到当今的拓扑 金融体系中，我们假设广泛的融合将不断产生人们所说的单一分类账历史 “Stellar 网络”，就像我们所说的互联网一样。 法定人数由切片产生，如下所示。每个节点指定 它发送的每条消息中的法定人数切片。设 S 为 一组消息源自的节点集。一个 节点认为消息集已达到法定人数 当 S 的每个成员都有一个切片包含在 S 中时的阈值。 通过构造，这样一个集合 S，如果一致的话，满足 其每个成员的协议要求。 有故障的对等点可能会通告精心设计的切片来改变什么 表现良好的节点会考虑法定人数。为了协议分析的目的，我们将FBA中的法定人数定义为非空 包含至少一个仲裁片的节点集 S 每个非故障成员。这个抽象是合理的，就像任何集合一样 声称代表一致法定人数的消息 实际上确实如此（即使它包含来自故障节点的消息）， 当 S 只包含行为良好的节点时，它是精确的。在 在本节中，我们还假设节点的切片不会改变。 尽管如此，我们的结果转移到了改变切片的情况 因为切片变化的系统的安全性不亚于 固定切片系统，其中节点的切片由所有 它在改变切片的情况下使用过的切片（参见定理 13 在 [68])。正如第 4 节中所解释的，活跃度取决于 表现良好的节点最终会删除不可靠的节点 从他们的切片中。 由于不同节点有不同的协议要求，FBA 排除了安全性的全局定义。我们说 当每个节点发生故障时，无故障节点 v1 和 v2 会交织在一起 v1 的仲裁数与 v2 的每个仲裁数至少在一个相交 无故障节点。 FBA 协议可以确保达成一致 仅在交织的节点之间；既然SCP这样做了，那是它的错 安全容忍度是最佳的。互联网假设， Stellar 的设计的底层，指出人们关心的节点 大约会交织在一起。 如果 I 是一致无故障的法定人数，即使 I 之外的每个节点都有故障，I 的每两个成员都交织在一起，我们就说一组节点 I 是完整的。直观地说， 那么，我应该对不完整的人的行为保持不受影响 节点。 SCP 保证非阻塞活性 [93] 和 对完整集合的安全性，尽管节点本身不需要 知道（并且可能无法知道）哪些集合是完整的。 此外，相交的两个完整集合的并集是 完整的一套。因此，完整集定义了一个分区 表现良好的节点，其中每个分区都是安全且活跃的 （在某些条件下），但是不同的分区可能会输出 不同的决定。 3.1.1 FBA 中的安全性与活性考虑因素 除了有限的例外 [64]，大多数封闭式拜占庭协议都被调整到平衡点，在该平衡点 安全性和活性具有相同的容错能力。在亚马逊物流中， 这意味着无论发生什么故障，所有的配置 相互缠绕的集合也完好无损。鉴于 FBA 确定 以去中心化的方式组成法定人数，个体切片的选择不太可能导致这种平衡。此外，在 至少在 Stellar 中，均衡是不可取的：后果 安全故障（即双花数字货币）是 比活性失败（即延迟）更糟糕 无论如何，付款都在 Stellar 之前几天完成）。人 因此应该并且确实选择大的法定人数切片，以便 它们的节点更有可能保持交织在一起，而不是完好无损。 进一步倾斜天平，更容易恢复 与传统封闭系统相比，FBA 系统中典型的活性故障。在封闭系统中，所有消息都必须 针对同一组法定人数进行解释。因此， 添加和删除节点以从故障中恢复需要 就重新配置事件达成共识，一旦共识不再有效，就很难达成共识。相比之下，对于FBA， 任何节点都可以随时单方面调整其仲裁切片 时间。响应具有系统重要性的停电 组织，节点管理员可以调整他们的切片 解决问题，有点像协调响应 BGP 灾难 [63] （尽管没有限制 通过物理网络链路进行路由）。
使用 Stellar 进行快速、安全的全球支付 SOSP '19，2019 年 10 月 27-30 日，加拿大安大略省亨茨维尔 3.1.2 级联定理 SCP遵循基本圆形模型[42]的模板； 节点通过一系列编号的选票取得进展，每个选票 尝试三个任务：（1）确定一个与之前投票中的任何决定不矛盾的“安全”值（通常称为 准备选票），(2) 就安全值达成一致，以及 (3) 检测协议是否成功。不过FBA开放 会员资格阻碍了几种常见的技术，使其 不可能将传统的封闭协议“移植”到FBA 通过简单地改变法定人数的定义来建立模型。 许多协议采用的一项技术是轮换 超时后以循环方式通过领导节点。在封闭系统中，循环领导者选择可确保 最终，一个独特的诚实领导者最终会就单一价值观达成一致。不幸的是，循环赛 无法在成员身份未知的 FBA 系统中工作。 FBA 失败的另一种常见技术是假设特定的法定人数可以说服所有节点。例如， 如果每个人都承认任意 2f + 1 个节点为法定人数，那么 2f + 1 个签名足以向所有节点证明协议状态。 类似地，如果一个节点收到一定数量的相同消息 通过可靠的广播 [24]，节点可以假设所有非故障节点也将看到法定人数。相比之下，在 FBA 中， 仲裁对于仲裁之外的节点没有任何意义。 最后，非联邦系统通常采用“向后”方式 安全性推理：如果f+1个节点出现故障，则全部安全 保证消失。因此，如果节点 v 听到 f + 1 个节点全部 陈述一些事实 F, v 可以假设至少有一个事实告诉 真实（因此 F 为真）且不损失安全性。这样的 FBA 推理失败，因为安全是成对的属性 节点，因此对某些对等方失去安全性的节点可以 总是因为假设不好的事实而失去更多节点的安全性。 然而，FBA 可以对活跃度进行反向推理。将 v 阻塞集定义为与每个节点相交的节点集 v 的切片。如果 v 阻塞集 B 一致错误，则 B 可以拒绝节点 v 的仲裁并降低其活跃度。因此，如果 B 一致陈述事实 F，则 v 知道 F 是 true 或 v 不完整。然而，v仍然需要看到完整的 法定人数知道交织的节点不会与 F 相矛盾， 这导致了 SCP 中的最后一轮沟通 类似中不需要的其他 FBA 协议 [47] 封闭式会员协议。结果是我们有 对潜在事实的三种可能的置信水平：不确定，在完整节点中安全地假设（我们将 术语接受的事实），并且可以安全地在交织在一起的情况下进行假设 节点（我们将其称为已确认的事实）。 节点v可以通过检查B是否与其所有切片相交来有效地确定集合B是否是vblocking。有趣的是，如果节点总是宣布它们的声明 接受并且全部法定人数接受一条语句，它会启动一个级联过程，通过该过程语句在整个过程中传播 完好无损的套装。我们称这种传播背后的关键事实为 级联定理，其表述如下：如果 I 是 完整集合，Q 是 I 中任意成员的法定人数，S 是任意 Q 的超集，则要么 S ΣI 要么有一个成员 v ∈I 使得 v < S 且 I ∩S 是 v 阻塞。直观上看，这是 情况并非如此，S 的补集将包含法定人数 与 I 相交但不与 Q 相交，违反了群体交集。 请注意，如果我们从 S = Q 开始并重复将 S 展开为 包括它阻止的所有节点，我们获得级联效果，直到， 最终，S包含了I的全部。 3.2 协议说明 SCP 是一个部分同步共识协议 [42]，由一系列达成共识的尝试组成，称为 选票。投票采用越来越长的超时。一个 选票同步协议确保节点保持在线状态 相同的选票持续增加的时间，直到选票 是有效同步的。不保证终止 直到选票同步，但是两个同步选票 其中表现良好的节点切片的错误成员会 不干扰足以使 SCP 终止。 投票协议规定了每次投票期间采取的行动 投票。投票从准备阶段开始，其中节点 尝试确定一个不矛盾的值来提议 任何先前的决定。然后，在提交阶段，节点尝试 对准备值做出决定。 投票采用称为联合投票的协议子协议，我n 哪些节点对抽象语句进行投票 这最终可能会得到证实或陷入困境。有些陈述可能被指定为矛盾的，并且安全性 联合投票的保证是一个组织中没有两个成员 相互交织的集合证实了相互矛盾的陈述。除完好无损外，不保证对声明的确认 设置所有成员都以相同方式投票。然而，如果一个 完整集合的成员确实确认了一个声明，联邦 投票保证完整集的所有成员最终都会确认该声明。因此，采取不可逆转的步骤 响应确认声明保留活性 完整的节点。 节点最初提出从提名中获得的值 增加所有成员完整的机会的协议 集合提出相同的值，最终收敛 （尽管没有办法确定收敛是否完成）。 提名将联合投票与领导人选举结合起来。 由于 FBA 中不可能进行循环赛，因此提名使用 概率领导者选择方案。 级联定理在投票中都起着至关重要的作用 同步并避免阻塞状态 不再可能终止。 3.2.1 投票 SCP 节点进行一系列编号投票，采用联合投票来就哪些声明达成一致 价值观是或不是在哪些选票中决定的。如果异步 或错误行为阻止在投票 n 中做出决定， 节点超时并在选票 n + 1 中重试。
SOSP '19，2019 年 10 月 27-30 日，加拿大安大略省亨茨维尔 洛哈瓦等人。 回想一下，联合投票可能不会终止。因此，一些 关于选票的陈述可能会永久陷入困境 不确定状态，节点永远无法确定它们是否 仍在进行中或陷入困境。因为节点不能排除 不确定的陈述后来被证明是正确的可能性， 他们绝不能尝试对新声明进行联合投票 与不确定的矛盾。 在每个投票 n 中，节点对两种类型使用联合投票 声明： • 准备⟨n,x⟩– 表示除了x 之外没有其他值 已经或将在任何≤n 的投票中决定。 • 提交⟨n,x⟩– 表明x 在投票n 中决定。 重要的是，请注意准备⟨n，x⟩与提交相矛盾 ⟨n′,x ′⟩当 n ≥n′ 且 x , x ′ 时。 节点通过尝试对 a 进行联合投票来开始投票 n 语句准备⟨n,x⟩。如果之前有任何准备语句 经过联合投票成功确认， 节点从最高选票的确认准备中选择x。否则，节点将 x 设置为 提名协议将在下一小节中描述。 当且仅当节点成功确认准备⟨n,x⟩ 在投票 n 中，它尝试对提交 ⟨n,x⟩ 进行联合投票。如果 成功，说明SCP已经决定，所以节点输出 来自已确认的提交语句的值。 考虑一个交织的集合 S。因为最多有一个值 可以确认由 S 成员在给定选票中准备，不能确认由 S 成员提交的两个不同值 给定选票中的 S 成员。此外，如果提交⟨n,x⟩ 确定了，则准备⟨n,x⟩也确定了；自从 通过联合投票的协议保证，准备⟨n,x⟩与任何早期提交的不同值相矛盾 我们知道在早期可能不会决定不同的值 由 S 成员投票。通过对选票号码的归纳，我们 因此认为SCP是安全的。 对于活性，考虑一个完整的集合 I 和一个足够长的集合 同步投票如果切片中出现故障节点 表现良好的节点不干预n，然后通过投票 I 中的 n+1 个所有成员都已确认相同的 P 组准备语句。如果 P = ∅ 并且选票 n 足够长，则 提名协议将收敛于某个值 x。 否则，令 x 为 P 中具有最高选票的准备中的值。无论哪种方式，我都会统一尝试联合 在下一次投票中对准备⟨n + 1,x⟩进行投票。因此，如果 n + 1 也是同步的，x 的决定不可避免地随之而来。 3.2.2 提名 提名需要对声明进行联合投票： • 提名x – 表明x 是有效的决策候选者。 节点可以投票提名多个不同的值 提名声明并不矛盾。然而，有一次 节点确认任何提名声明后，将停止投票 提名新的价值观。联合投票仍然允许节点 确认其未投票赞成的新提名声明，其中 投票或接受 从法定人数 接受一个 从法定人数 a 有效 接受来自 阻塞集 未承诺的 投票了 接受了一个 确认了一个 投票给 Øa 图 1. 联合投票的阶段 允许完整集合的成员相互确认 提名值，同时仍保留新的选票。 提名的（不断变化的）结果是已确认的提名声明中所有值的确定性组合。如果 x代表一组交易，节点可以取并集 集合中最大的集合，或者具有最高 hash 的集合，所以 只要所有节点都做同样的事情。因为节点保留新的 确认一项提名声明后进行投票，一组 已确认的陈述只能包含有限多个值。 已确认的陈述可靠地传播的事实 完整集意味着完整节点最终收敛于 相同的一组提名值和提名结果， 尽管在协议中任意后期的未知点。 节点采用联邦领导者选择来减少 提名语句中不同值的数量。仅 尚未投票支持提名声明的领导者可以引入新的 x。其他节点等待接收消息 领导人并复制其领导人的（有效）提名票。 为了适应失败，领导者队伍不断壮大 尽管实际上只有少数节点引入了新的 x 值，但还是会发生超时。 3.2.3 联合投票 联合投票采用如图所示的三阶段协议 图 1. 节点首先尝试就抽象语句达成一致 投票，然后接受，最后确认声明。 节点 v 可以投票给任何不支持的有效语句 a 与其他的相矛盾未决投票和已接受的声明。它通过广播签名投票消息来实现这一点。 如果 a 与其他接受的语句一致并且（情况 1）v 是法定人数的成员，则 v 然后接受 a 每个节点要么投票支持 a 要么接受 a，或者（情况 2）即使 v 没有投票给a，v-blocking集合接受a。在情况 2 中，v 可以 之前曾投过与 a 相矛盾的票，现在已 被否决了。 v 可以忘记被否决的选票 假装它从未施放它们，因为 ifv 完好无损，它知道 被否决的投票无法达到案例 1 的法定人数。 v 广播它接受 a，然后在 a 存在时确认它 一致接受 a 的法定人数。图 2 显示了 v-阻塞集和级联定理的影响 联合投票。 两个交织在一起的节点无法确认矛盾的陈述，因为两个所需的法定人数必须共享一个使用 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 (一) 3 4 2 1 5 7 6 投票 X 投票 X 投票 X 投票 是 投票 X 投票 是 投票 是 (二) 3 4 2 1 5 7 6 接受 X 投票 X 接受 X 投票 是 接受 X 投票 是 投票 是 (三) 3 4 2 1 5 7 6 接受 X 接受 X 接受 X 投票 是 接受 X 接受 X 投票 是 (四) 3 4 2 1 5 7 6 接受 X 投票 X 接受 X 接受 X 接受 X 接受 X 接受 X （五） 图 2. 联合投票中的级联效应。每个节点都有一个仲裁片，用箭头指示该片的成员。 (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 阻塞 选票，它立即跳到最低的选票，这样 现在情况不再是这样，无论任何计时器如何。级联 然后定理确保所有掉队者都能赶上。结果 是选票在整个完整的过程中大致同步 一旦系统变得同步就设置。 3.2.5 联邦领导人选举 领导者选择允许每个节点在这样的情况下选择领导者 节点一般只选择一个或少数的方式 的领导者。为了适应领导者失败，领导者选择 分轮进行。如果本轮领先者 似乎没有履行自己的职责，然后经过一段时间 一定的超时时间节点进入下一轮 扩大他们追随的领导者群体。 每轮使用两个独特的加密 hash 函数 H0 和 H1，输出 [0,hmax) 范围内的整数。 例如，Stellar 使用 Hi(m) = SHA256(i∥b∥r ∥m)，其中 b 是整个 SCP 实例（区块或账本编号），r 是 领导者选择轮数，hmax = 2256。 一轮中，我们定义节点v的优先级为： 优先级(v) = H1(v) 每个节点将选择一名稻草人作为领导者 具有最高优先级（v）的节点。这种方法有效 具有几乎相同的仲裁切片，但不正确 捕捉不平衡配置中节点的重要性。例如，如果欧洲和中国各贡献 3 每个法定人数都有节点，但中国运行 1,000 个节点，欧洲运行 4 个，那么中国将拥有最高优先级节点 99.6% 的时间。 因此，我们引入切片权重的概念，其中 Weight(u,v) ∈[0, 1] 是节点 u 的仲裁切片的分数 包含节点 v。当节点 u 选择新的领导者时，它 只考虑邻居，定义如下： 邻居（u）= { v | H0(v) < hmax · 权重(u,v) } 然后，nodeu 从一组空的领导者开始，并且在每个 round 将邻居(u) 中具有最高值的节点 v 添加到其中 优先级（v）。如果任何一轮中邻居集为空，则 u 添加具有最低值 H0(v)/weight(u,v) 的节点 v。
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的安全性 和活性属性（参见 [65]）。具体来说，我们验证了 相互交织的节点永远不会意见不一致，并且在下面讨论的条件下，完整集合中的每个成员最终都会做出决定。有趣的是，经核查发现， SCP 保证活性的条件很微妙， 并且比最初想象的更强 [68]：如下所述， 恶意节点操纵时间而不用其他方式 违反协议的可能需要手动驱逐 来自法定人数切片。
SOSP '19，2019 年 10 月 27-30 日，加拿大安大略省亨茨维尔 洛哈瓦等人。 确保属性在所有可能的情况下都被证明成立 FBA配置和执行，我们考虑任意 具有任意本地配置的节点数量。这个 包括具有不相交完整集的场景，以及可能无限长的执行。缺点是我们 面临验证参数化的挑战性问题 无限状态系统。 为了使验证易于处理，我们使用 Ivy [69] 和 [82] 的方法在一阶逻辑 (FOL) 中对 SCP 进行建模。 验证过程包括手动提供归纳猜想，然后由系统自动检查 常春藤。 SCP 的 FOL 模型抽象了 难以在 FOL 中处理的 FBA 系统（例如， 级联定理被视为公理），因此我们验证 使用 Isabelle/HOL [75] 进行抽象的健全性。 在用 FOL 表达验证问题后，我们通过提供归纳不变量来验证安全性。感应式 不变量由十几个单行猜想组成，大约 150行协议规范。然后，我们在 Ivy 的线性时序逻辑中指定 SCP 的活性属性，并使用 活性降低 [80, 81] 的安全性以降低活性 验证问题转化为寻找电感问题 不变的。虽然 SCP 的安全性相对简单 证明，SCP 的活性论证要复杂得多 由大约 150 个单行不变量组成。 证明活性需要精确形式化 SCP 确保终止的假设。我们最初认为是一个完整的集合，如果全部的话我总是会终止 成员从其切片 [68] 中删除了故障节点。然而，事实证明这还不够：一个行为良好的（但 不完整）节点中的法定人数我可以，在 故障节点的影响，通过完成来防止终止 投票结束前达到法定人数，从而导致 I 的成员在下一次投票中选择不同的 x 值。 因此，我们还必须非正式地假设， I 成员的法定人数中的每个节点最终要么 变得及时或在足够长的时间内根本不发送消息。实际上，这意味着 I 的成员可以 需要调整他们的切片，直到条件成立。这个 问题不是 FBA 系统固有的：Losa 等人。 [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.
支付网络
本节介绍 Stellar 的支付网络，该网络作为 SCP 之上的复制状态机 [88] 实现。 5.1 账本模型 Stellar 的分类账是围绕帐户抽象设计的（在 与更以币为中心的未花费交易输出形成对比 或 Bitcoin 的 UTXO 型号）。分类账内容包括 四种不同类型的分类账条目集：账户、信任线、 优惠和帐户数据。 账户是拥有和发行资产的主体。每个 帐户由公钥命名。默认情况下，对应的私钥可以为账户签署交易。 但是，可以重新配置帐户以添加其他签名者并取消授权命名该帐户的密钥，并使用 “多重签名”选项需要多个签名者。每个账户 还包含：序列号（包含在交易中 以防止重播），一些标志，以及“native”中的平衡 称为 XLM 的预开采加密货币，旨在缓解 一些拒绝服务攻击并促进做市 作为中性货币。 Trustlines 跟踪已发行资产的所有权，这些资产是 由发行帐户和短帐户组成的一对命名 资产代码（例如“美元”或“欧元”）。每个信任线指定 一个账户、一项资产、该资产的账户余额、 余额不能超过该限制，以及一些标志。 账户必须明确同意持有资产 创建信任线，防止垃圾邮件发送者上当 拥有不需要的资产的账户。 了解你的客户（KYC）法规要求许多金融机构知道他们持有谁的存款， 例如通过检查带照片的身份证件。为了遵守规定，发行人可以设置 他们的账户上有一个可选的 auth_reqired 标志，限制他们向授权账户发行的资产的所有权。 为了授予此类授权，发行人设置了授权 标记客户的信任线。 报价与账户的升级意愿相对应 在给定的时间内将一定数量的特定资产换成另一种资产 订单簿上的价格；它们会自动匹配并且 当买入/卖出价格交叉时填充。最后，账户数据由账户、键、值三元组组成，允许账户持有者 发布小的元数据值。 为了防止账本垃圾邮件，有一个最低的 XLM 余额， 称为储备。账户的准备金随着每次增加而增加 关联的分类账条目和当分类账条目减少时 消失（例如，当订单被执行或取消时，或者当 信任线已删除）。目前储备增长0.5 XLM 每个账本条目 (∼$0.03)。无论储备如何，它都是 可以通过删除来收回帐户的全部价值 它与 AccountMerge 操作。 如图 3 所示，账本标头存储全局属性： 账本编号、每个准备金余额等参数 账本条目，前一个账本标题的 hash （实际上 几个 hashes 形成一个跳过列表），SCP 输出包括 应用于此分类账的 hash 笔新交易， hash 笔 这些交易的结果（例如，成功或失败 每个），以及所有分类帐条目的快照 hash。 因为快照 hash 包含所有账本内容， validators 不需要保留历史记录来验证交易。 然而，要扩展到数亿预期 帐户，我们无法重新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。 创建帐户 创建新账户分类账条目并为其提供资金 账户合并 删除账户分类帐条目 设置选项 更改帐户标志和签名者 付款方式 向目的地支付特定数量的资产。帐户。 路径支付 与支付类似，但以不同的资产支付（最多 限制）；指定最多 5 个中间资产 管理报价 创建/删除/更改报价分类帐条目， -被动报价 具有被动变体以允许零传播 管理数据 创建/删除/更改帐户。数据分类账录入 改变信任 创建/删除/更改信任线 允许信任 在信任线上设置或清除授权标志 凹凸序列 增加序列账户号码 图 4. 主要账本操作 每次节点断开连接时的大小 网络时间太长。因此，快照 hash 是 旨在优化 hashing 和状态协调。 具体来说，快照按时间对账本条目进行分层 一组指数大小的容器中的最后一次修改 称为桶。桶的集合称为桶 列表，与日志结构的合并树有一些相似之处 （LSM 树）[77]。在事务处理期间不会读取存储桶列表（参见第 5.4 节）。因此，一定的设计 LSM 树的各个方面都可以放宽。特别是随机 不需要通过密钥访问，并且只能读取存储桶 按顺序作为合并级别的一部分。哈希桶 列表是通过在合并每个桶时对每个桶进行 hash 并计算桶 hashes 的新累积 hash 来完成的（一个小的， 每个分类帐关闭时参考的固定索引 hashes)。断开连接后协调存储桶列表需要下载 只有不同的桶。 5.2 交易模式 一笔交易由源账户、有效性标准、 备忘录，以及一个或多个操作的列表。图 4 列出了可用的操作。每个操作都有一个源账户， 默认为整个交易的值。一笔交易必须 由与每个源帐户相对应的密钥进行签名 一次手术。多重签名帐户可能需要更高的签名 某些操作（例如 SetOptions）的权重及更低 对于其他人（例如AllowTrust）。 事务是原子的——如果任何操作失败，则任何操作都失败 他们执行。这简化了多方交易。假设一个 发行人创建资产来代表土地契约，用户A 想要用一块小地块加上 10,000 美元换取一块 B 拥有更大的土地。两个用户都可以签名 一笔交易包含三项操作：两块土地 付款和一美元付款。 交易的主要有效性标准是其序列号，该序列号必须比交易的序列号大1 源帐户分类帐条目。执行有效交易 （成功与否）增加序列号，防止重播。初始序列号包含账本 高位数字以防止删除后重播 并重新创建一个帐户。 另一个有效性标准是对何时的可选限制 交易可以执行。回归土地和美元 上面交换，如果A在B之前签署交易，A可能不会 希望 B 在提交交易之前等待一年 它，因此可以设置使交易无效的时间限制 几天后。还可以配置多重签名帐户 为 hash 原像的揭示赋予签名权重， 它与时间限制相结合，允许原子跨链交易 [1]。 交易的源账户用 XLM 支付少量费用， 10−5 XLM，除非出现拥塞。拥堵情况下， 运营成本通过荷兰式拍卖确定。验证器是 不通过费用补偿，因为 validator 是类似的 到 Bitcoin 全节点，而不是矿工。与其破坏 XLM， 费用通过投票回收并按比例分配 现有的 XLM 持有者，回想起来可能会或可能 不值得这么复杂。 5.3 共识价值观 对于每个账本，Stellar 使用 SCP 就数据结构达成一致 具有三个字段：交易集 hash （包括 hash 前一个分类帐标题的）、关闭时间、d 升级。 当确认指定多个值时，Stellar 取 操作最多的交易集（打破联系 按总费用，然后交易集 hash)，所有的并集 升级和最高关闭时间。关闭时间仅 如果在最后一个账本的关闭时间和当前账本的关闭时间之间有效 存在，因此节点不会指定无效时间。 升级调整储备余额、最低操作费、协议版本等全局参数。当 在提名期间，较高的费用和协议版本号会取代较低的费用和协议版本号。通过联合投票的斗争空间 [34] 升级效果治理，两者都不是 平等主义，也不是中央集权主义。每个 validator 配置为 治理或非治理（默认），根据 其运营者是否愿意参与治理。 管理 validators 考虑三种升级： 期望的、有效的和无效的（validator 没有的任何内容）
SOSP '19，2019 年 10 月 27-30 日，加拿大安大略省亨茨维尔 洛哈瓦等人。 validator 核心 地平线 FS 数据库 数据库 提交 客户 客户 其他 validators 图 5. Stellar validator 架构 知道如何实施）。所需的升级配置为 在特定时间触发，旨在协调 运营商。治理节点总是投票提名所需的 升级，接受但不投票提名有效升级 （即，遵守阻塞法定人数），并且永远不要投票给 或接受无效的升级。非治理 validators 回声 他们看到的任何有效升级的投票，本质上是授权 决定那些选择的人希望进行哪些升级 担任治理角色。 5.4 实施 图 5 显示了 Stellar 的 validator 架构。一个守护进程 称为 stellar-core（约 92k 行 C++，不包括第三方库）实现了 SCP 协议和复制状态机。为 SCP 生成价值需要将大量账本条目减少为小型加密货币 hashes。相比之下，交易验证和执行 需要在以下位置查找帐户状态和订单匹配 最优惠的价格。为了有效地服务这两个功能，stellar-core 保留分类帐的两种表示形式：包含存储桶列表的外部表示形式，存储为二进制文件 可以有效地更新和增量重新hashed，并且 SQL 数据库（PostgreSQL 对于生产节点）。 Stellar-core 创建一个只写历史存档，其中包含 每个已确认的交易集及其快照 桶。该存档让新节点能够自行引导 加入网络时。它还提供分类账记录 历史——需要有一个地方可以让人们查阅 两年前的交易。由于历史只能追加 并且不经常访问，可以将其保存在便宜的地方 例如 Amazon Glacier 或任何允许存储的服务 并检索平面文件。验证者主机通常不托管 他们自己的档案，以避免对验证产生任何影响 服务历史的表现。 为了保持 stellar-core 简单，不打算使用它 直接由应用程序使用，并且仅公开一个非常狭窄的接口用于提交新事务。支持 客户端，大多数 validator 运行一个名为 Horizon 的守护进程（∼18k Go 行）提供了用于提交的 HTTP 接口 以及交易的学习。 Horizon 具有只读访问权限 stellar-core 的 SQL 数据库，最大限度地降低地平线风险 破坏恒星核心的稳定。支付路径查找等功能完全在 Horizon 中实现，并且可以升级 单方面不与其他 validator 协调。 几个可选的高层守护进程是 Horizon 的客户端，完善了生态系统。桥接服务器有助于 将 Stellar 与现有系统集成，例如，发布特定帐户收到的所有付款的通知。一个 合规服务器为金融机构提供挂钩 交换并批准发件人和受益人信息 关于付款，遵守制裁清单。最后， 联合服务器实现人类可读的命名 账户系统。 6 部署经验 Stellar 经过几年发展成为一个中等程度的州 相当可靠的全节点运营商的数量。然而， 节点的配置使得活跃度（尽管不是 安全）取决于我们，Stellar 发展基金会 （自卫队）；如果SDF突然消失，其他节点运营商 需要干预并手动删除我们 从仲裁切片中让网络继续。 虽然我们和许多其他人希望降低自卫队的系统重要性，但这一目标在 研究人员 [58] 量化并公开了网络的中心化程度，而没有区分安全风险和 活力。许多运营商积极进行配置调整，主要是增加其规模 削减法定人数，以淡化自卫队的重要性；讽刺的是，这只会增加活性风险。 有两个问题加剧了这种情况。首先，一个流行的 系统地第三方Stellar监控工具[5] 由于没有实际验证而高估了 validator 正常运行时间 那个恒星核心正在运行；这导致人们包括 仲裁切片中的不可靠节点。其次，一个错误 stellar-core 意味着一旦 validator 移动到下一个分类帐， 它没有充分帮助剩余节点完成先前的任务如果丢失消息，我们的分类帐将被删除。结果， 网络出现 67 分钟的停机时间，需要 由 validator 管理员手动协调重新启动。 更糟糕的是，在尝试重新启动网络时，导致多个节点同时仓促重新配置 在集体错误配置中，允许某些节点 分歧，需要手动关闭这些节点并且 重新提交分歧期间接受的交易。幸运的是，这种分歧被发现并纠正了 速度很快并且不包含任何冲突的交易，但是 网络无法享受法定人数交叉的风险—— 分裂，同时继续接受潜在的冲突 交易，仅仅是由于错误配置而进行的 这件事非常具体。 回顾这些经验得出两个主要结论 以及相应的纠正措施。使用 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 公钥，或者递归地另一个仲裁集。 在灵活和紧凑的同时，我们实现了嵌套仲裁 同时设置为节点操作员提供了太多的灵活性和太少的指导：很容易写出不安全的（或 甚至是无意义的）配置。分组标准 将节点分成集合，用于将子集组织成层次结构，以及 选择阈值的方法都不够明确，导致操作失败。尚不清楚是否要 将嵌套集层次结构中的“级别”视为信任级别， 或一个组织，或两者兼而有之；现场多种配置 除了指定危险之外，还混合了这些概念 或无意义的阈值。 因此我们添加了一个更简单的配置机制 它将嵌套仲裁集的两个方面分开：分组 按组织将节点聚集在一起，并用简单的信任分类（低、中、高或 关键）。高级及以上组织必须 出版历史档案。新系统综合了嵌套仲裁集，其中每个组织都表示为 51%阈值设定，组织分组 67% 或 100% 阈值（取决于群体质量）。 每个组都是下一个（更高质量）组中的一个条目， 如图 6 所示。这个简化的模型减少了 结构错误配置的可能性 合成的嵌套集和选择的阈值 每套。 6.2 主动检测错误配置 其次，我们意识到，通过等待观察其负面影响来发现集体错误配置已经为时已晚。特别是对于可能出现分歧的错误配置——a 比停止更严重的故障模式——网络需要 能够立即检测到错误配置，以便操作员可以在任何分歧实际发生之前恢复它。 为了满足这一需求，我们在 validator 软件中构建了一种机制，该机制不断收集节点传递闭包中所有对等点的集体配置状态，并检测潜在的发散（即不相交） 法定人数——在该集体配置内。 6.2.1 检查仲裁交叉点 虽然收集仲裁切片很容易，但在其中找到不相交的仲裁却是共 NP 难题 [62]。然而，我们采用了 一组算法启发式和案例消除规则 由 Lachowski [62] 提出，检查典型实例 问题的解决速度比问题快几个数量级 最坏情况下的成本。从实际情况来看，目前的网络 仲裁切片传递闭包数量级为 20–30 节点，并且通过 Lachowski 的优化，通常会检查 在单个 CPU 上只需几秒钟。如果有需要的话 为了提高性能，我们可以并行化搜索。 6.2.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 作为全球支付的适用性和 交易网络，我们评估了公共网络的状态 并在私人实验上进行了对照实验 网络。我们重点关注以下问题： • 生产网络拓扑是什么样的？ 平均广播多少条消息，以及 SCP 如何经历超时？ • 共识和账本更新延迟是否独立于账户数量？SOSP '19，2019 年 10 月 27-30 日，加拿大安大略省亨茨维尔 洛哈瓦等人。 • 增加 (a) 每秒事务数（以及因此增加的每秒事务数）对延迟有何影响？ (b) validator 节点的数量？ • 运行一个节点的CPU 成本是多少？ 内存和网络带宽？ 相比之下，支付网络的交易率较低 到其他类型的分布式系统。领先的 blockchains， Bitcoin 和 Ethereum，确认每秒最多 15 笔交易， 小于 Stellar。此外，这些系统需要几分钟的时间 安全确认交易需要一个小时，因为工作量证明需要等待几个区块被开采。的 非blockchain SWIFT 网络在高峰日[14] 平均每秒仅处理420 笔交易。因此我们选择了 将我们的测量值与 5 秒目标进行比较 账本间隔，一个更激进的目标。我们的结果显示 即使在以下情况下，延迟也完全低于此限制 一些尚未实施的优化仍在进行中。 7.1 锚 按交易量排名前列的资产包括货币（例如 3 美元 锚点，2 元人民币）、一个 Bitcoin 锚点、一个房地产支持的证券 token [92] 和一个应用内货币 [8]。不同的主播有不同的政策。例如，一个美元锚， Stronghold，设置 auth_reqired 并要求每个持有其账户的账户都有一个了解你的客户 (KYC) 流程 资产。另一个，AnchorUSD，让任何人都可以接收和交易 他们的美元（实际上可以向墨西哥发送 0.50 美元） 5 秒内，费用为 0.000001 美元）。然而，AnchorUSD 购买或赎回美元确实需要 KYC 和费用 与传统的电汇。在菲律宾，哪里 银行对收款的监管较为宽松，coins.ph 支持在任何 ATM 机 [36] 上提取 PHP 现金。除了前面提到的安全 token 和应用内货币之外，还有一系列非货币 token，范围从 商业债券 [22] 和碳信用额 [85, 96] 等等 深奥的资产，例如 token 激励协作 汽车收回[35]。 7.2 公网 截至撰写本文时，有 126 个活动全节点，其中 66 个 通过签署投票消息参与共识。图7 （由 [5] 生成）可视化网络，中间有一条线 两个节点，如果一个出现在另一个节点的仲裁切片中，并且 深蓝色线表示双向依赖性。在 该中心是由 17 个事实上的“一级 validator”组成的集群，由 SDF、SatoshiPay、LOBSTR、COINQVEST 和 Keybase。 四个月前，在第六节事件发生之前，有 共有 15 个具有系统重要性的节点：3 个看似 一级组织和几个随机的单身人士。的 图表看起来也不太规则。因此，新的配置机制和/或更好的操作员决策似乎 为更健康的网络拓扑做出贡献。没有 雄厚的财力（及相应股东 图 7. 仲裁切片图 义务），招募 5 名一级人员是很困难的 然而，从一开始就组织。这表明法定人数 切片在网络引导中发挥着有用的作用：任何人都可以 加入的目标是成为重要的参与者，因为 成对协议没有看门人。 目前账本上有超过 330 万个账户。结束 最近 24 小时内，Stellar 平均有 4.5 笔交易， 每秒 15.7 次操作。回顾最近的账本，大多数 交易似乎只有一个操作，而每隔几个 在分类账中，我们看到包含许多操作的交易 似乎来自管理报价的做市商。的 达成共识和更新账本的平均时间是 分别为 1061 毫秒和 46 毫秒。第 99 个百分位数是 2252 毫秒和 142 毫秒（前者反映 1 秒超时 提名领导者的选择）。注意 SCP 的性能是 基本上与每秒交易无关，因为 SCP 就任意多笔交易的 hash 达成一致。瓶颈更有可能来自宣传候选人 提名、执行和验证期间的交易 事务和合并桶。我们还没有需要 在多个 CPU 核心或磁盘驱动器上并行 stellar-core 的事务处理。 我们还评估了 SCP 消息广播的数量 在生产网络上。在正常情况下，有一个 领导者选出提名一个值，我们期望七个逻辑 要广播的消息：两个要投票和接受的消息 阿诺米nate声明，两条消息接受和确认 一个准备声明，两条接受和确认消息 提交语句，最后是外部化消息 （在将新账本提交到磁盘后发送，以帮助落后者 赶上）。该实现结合了确认提交 并将消息外部化作为优化，因为它是 提交值后可以安全地将其外部化。然后，我们分析在生产 Stellar validator 上收集的指标。结束 在 68 小时的过程中，每秒发出 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.3 对照实验 我们在装满的容器中进行了对照实验 具有 72 GiB RAM 的 Amazon EC2 c5d.9xlarge 实例， 900 GB NVMe SSD 和 36 个 vCPU。每个实例都位于 相同的 EC2 区域并具有 10 Gbps 的固定带宽。 我们使用 SQLite 作为存储。 （Stellar 还支持 PostgreSQL， 但它有异步任务，会向测量中注入噪声。） Stellar 提供内置的运行时查询、generateload、 允许在特定目标处生成合成负载 交易/二流。虽然 Stellar 支持各种 交易功能，例如订单簿和跨资产路径 支付方面，我们专注于简单支付。 确认交易由多个步骤组成，因此我们 记录以下各项的测量值： • 提名：从提名到第一次准备的时间 • 投票：从最初准备到确认的时间 已提交选票 • 账本更新：应用共识值的时间 • 交易计数：每个分类账已确认的交易 我们的每个实验都由三个参数定义： 分类账中的账户条目数、金额 每秒提交的负载（以 XLM 付款的形式）， 以及 validator 的数量。我们配置了每个 validator 了解所有其他 validator （最坏的情况 对于 SCP），法定人数切片设置为任何简单多数 节点（以便最大化不同仲裁的数量）。 基线 我们的基线实验测量了 Stellar 100,000 个帐户、四个 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 秒的峰值，对应于第一步 在leader选择的超时函数中。 考虑到基准性能，我们研究了效果 改变每个测试设置参数。 账户 图 9 中的数据表明 Stellar 具有扩展性 以及账户数量的增加。测试生成 帐户成为一个漫长的过程，因为存储桶创建和 合并阻止我们简单地填充数据库 直接通过 SQL 处理帐户。因此，我们进行了 最多可对 50,000,000 个帐户进行实验。虽然有 对共识和账本更新延迟的影响最小， 我们注意到，增加帐户会产生以下开销 合并桶，变得更大。 交易率 交易率影响金额 validator之间的流量多播，每个账本包含的交易数量，以及顶层的大小 桶。了解增加交易的影响 负载，我们用 100,000 个帐户和 4 个 validator 进行了实验。 图 10 显示了共识延迟的缓慢增长， 而大部分时间都花在更新账本上。 毫不奇怪，随着交易集规模的增加， 将其提交到数据库需要更长的时间。我们还注意到 账本更新延迟在很大程度上取决于实现， 并且受到数据库选择的影响。 验证节点 查看如何增加 tierone validator 的数量影响性能，我们进行了实验 有 100,000 个账户，每秒 100 笔交易，validator 的数量从 4 到 43 不等。所有 validator 都出现了 在所有 validators 的仲裁切片中；较小的仲裁片会 对性能的影响较小。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 s、5.10 s 和 5.15 s 分别是条目数、交易率和节点数。 结果表明 Stellar 可以持续关闭账本 高负载下。 7.4 运行 validator Stellar 的重要特征之一是低成本 运行 validator，因为锚应该运行（或与之签约） validators 强制确定性。 SDF 运行 3 个生产 validator，全部在 c5.large AWS 实例上，该实例有两个核心， 4 GiB RAM 和 Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz 处理器。检查其中一台的资源使用情况 在这些机器中，我们使用以下命令观察了 Stellar 进程 大约 7% 的 CPU 和 300 MiB 内存。就网络流量而言，与对等点的连接数为 28 个，法定人数大小 34条中，进出速率为2.78Mbit/s， 分别为 2.56 Mbit/s。运行此类程序所需的硬件 过程成本低廉。在我们的例子中，成本为 0.054 美元/小时 或约 40 美元/月。 7.5 未来的工作 这些实验表明 Stellar 可以轻松扩展 1-2 个订单 其规模超出了当今的网络使用量。因为 迄今为止，性能要求非常有限，Stellar 为许多直接优化留下了空间 众所周知的技术。例如，交易和 SCP validators 使用简单的洪泛方式广播消息 协议，但理想情况下应该使用更高效、结构化的 点对点多播 [30]。此外，数据库密集型 可以通过标准批处理和预取技术来缩短账本更新时间。
Sự đánh giá
Để 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 就不会成为今天的样子 乔伊斯·金 (Joyce Kim) 的领导或巨大贡献 斯科特·弗莱肯斯坦 (Scott Fleckenstein) 和巴特克·诺沃塔斯基 (Bartek Nowotarski) 在建筑和 维护地平线、Stellar SDK 和其他关键部分 Stellar 生态系统的一部分。我们还要感谢 Kolten Bergeron， 亨利·科里根-吉布斯、坎迪斯·凯利、卡皮尔·贾恩、鲍里斯 雷兹尼科夫、杰里米·鲁宾、克里斯蒂安·鲁德、埃里克·桑德斯、 Torsten Stüber、Tomer Weller、匿名审稿人以及 我们的牧羊人贾斯汀雪莉对 早期的草稿。 免责声明 Mazières 教授对本出版物的贡献是作为付费顾问，而不是他的工作的一部分 斯坦福大学的职责或责任。
使用 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