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
介绍
国际支付速度缓慢且成本高昂 [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 节总结。
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
投票 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。
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] 目前 其活性取决于严格较弱的协议 假设只是最终同步和最终领导者选举，而不需要从切片中删除故障节点。
支付网络
本节介绍 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 检查有风险的配置 检测网络是否承认不相交的仲裁是一个步骤 方向正确，但危险信号却迟到了 对于如此关键的问题。理想情况下，我们希望节点操作员在网络集体配置时收到警告 只是接近危险状态。 因此，我们扩展了群体交叉检查器 检测我们称之为关键性的条件：当电流 集体配置是一种错误配置 承认不相交法定人数的国家。为了检测关键性， 检查器反复用模拟的最坏情况错误配置替换每个组织的配置，然后 对结果重新运行内部仲裁交集检查器。 如果存在任何此类严重错误配置，只需一步之遥 从当前状态来看，软件会发出警告并 报告该组织存在配置错误风险。 这些变化为运营商社区提供了两个层次 防范最坏形式的通知和指导 集体错误配置。
评估
了解 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]。此外，数据库密集型 可以通过标准批处理和预取技术来缩短账本更新时间。
结论
国际付款费用昂贵且需要数天时间。基金 托管通过多个金融机构，包括代理银行和汇款服务机构。 因为每一跳都必须完全可信，所以新的很难 进入者获得市场份额并参与竞争。 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 日，加拿大安大略省亨茨维尔
常见问题
- Stellar 白皮书是什么？
- Stellar 共识协议（SCP）白皮书由 David Mazières 于2015年撰写，描述了一种联邦拜占庭协议系统，无需封闭的验证者集合或工作量证明（PoW）挖矿即可实现去中心化共识。
- Stellar 白皮书由谁撰写，发布于何时？
- SCP 白皮书由斯坦福大学教授、Stellar 开发基金会首席科学家 David Mazières 撰写，于2015年作为正式学术论文发表。
- Stellar 的核心技术创新是什么？
- Stellar 的核心创新是联邦拜占庭协议（FBA）——一种共识模型，每个节点自主选择其信任集合（法定切片）。系统通过各个信任决策的交集推导出全局共识，无需预定义的验证者名单。
- Stellar 的共识机制如何运作？
- 在 SCP 中，每个节点选择一个受信任对等节点的法定切片。共识通过提名阶段（提出候选值）和投票阶段（就单一值达成一致）来实现。法定切片的交集确保了在无全局权威机构的情况下仍能保证安全性。
- Stellar 与 XRP 有何不同？
- Stellar 由 Jed McCaleb（也是 Ripple 联合创始人）联合创立，但采用了本质上不同的共识模型。Stellar 的 FBA 允许开放参与共识，而 XRP 要求验证者必须出现在预先协商的唯一节点列表（Unique Node List）上。
- Stellar 的供应模型是什么？
- Stellar 的 XLM 固定供应量为500亿枚（社区投票销毁550亿枚后，从1000亿枚减少至此）。没有通胀机制。少量基础手续费（0.00001 XLM）被收入手续费池，不予销毁。
- Stellar 的主要使用场景有哪些？
- Stellar 专注于跨境支付、资产代币化和普惠金融。它为汇款走廊提供支持，原生托管 USDC，并支持稳定币、证券和央行数字货币（CBDC）的发行。
- Stellar 解决了什么问题？
- Stellar 解决了国际汇款的成本和速度障碍，尤其面向无银行账户的人群。其网络能够在3至5秒内完成结算，手续费仅为几分之一美分，使小额支付在经济上具有可行性。
- Stellar 的安全模型如何运作？
- Stellar 的安全性依赖于法定切片的交集——即网络中各信任集合之间的重叠部分。只要各法定切片之间存在足够的交集，网络就能维持安全性。单个节点可以承受其受信任节点的故障。
- Stellar 生态系统目前的状态如何？
- Stellar 的生态系统包括与 MoneyGram 的集成、USDC 原生支持、Soroban（智能合约平台）以及与新兴市场金融机构的合作。Stellar 开发基金会持续推动支付和资产代币化领域的采用。