Stellar Konsensüs Protokolü
摘要
国际支付缓慢且昂贵，部分原因是通过异构的多跳支付路由 银行系统。 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
Özet
Uluslararası ödemeler yavaş ve pahalıdır; bunun nedeni kısmen, heterojen ödemeler üzerinden çok duraklı ödeme yönlendirmesidir. bankacılık sistemleri. Stellar yeni bir küresel ödeme ağıdır dijital parayı dünyanın herhangi bir yerine doğrudan aktarabilen saniyeler içinde dünya. En önemli yenilik güvenli bir işlemdir güvenilmeyen aracılar arasında yeni bir mekanizma kullanarak Bizans anlaşma protokolüne SCP denir. SCP ile her biri kurum kalacağı diğer kurumları belirtir anlaşarak; küresel birbirine bağlılığı sayesinde finansal sistem, tüm ağ daha sonra atomik aracı varlık ihraççılarından kaynaklanan ödeme gücü veya döviz kuru riski olmayan, keyfi kurumları kapsayan işlemler veya piyasa yapıcılar. SCP'nin modelini, protokolünü ve resmi doğrulama; Stellar ödeme ağını açıklayın; ve son olarak Stellar'yi karşılaştırmalar yoluyla ampirik olarak değerlendirin ve birkaç yıllık üretim kullanımı deneyimimiz. CCS Konseptleri • Güvenlik ve gizlilik →Dağıtılmış sistem güvenliği; • Bilgisayar sistemleri organizasyonu → Eşler arası mimariler; • Bilgi sistemleri → Elektronik fon transferi. Anahtar Kelimeler blockchain, BFT, yetersayılar, ödemeler ACM Referans Formatı: Marta Lokhava, Giuliano Losa, David Mazières, Graydon Hoare, Nicolas Barry, Eli Gafni, Jonathan Jove, Rafał Malinowsky, Jed McCaleb. 2019. Stellar ile hızlı ve güvenli küresel ödemeler. SOSP'de '19: İşletim Sistemleri İlkeleri Sempozyumu, 27–30 Ekim, 2019, Huntsville, ON, Kanada. ACM, New York, NY, ABD, 17 sayfa. 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 节总结。
giriiş
Uluslararası ödemeler herkesin bildiği gibi yavaş ve maliyetlidir [32]. ABD'den ABD'ye 0,50 dolar göndermenin pratik olmadığını düşünün. *Galois, Inc. †UCLA Bu çalışmanın tamamının veya bir kısmının dijital veya basılı kopyalarını alma izni kopyalarının olmaması koşuluyla kişisel veya sınıf kullanımı ücretsiz olarak sağlanır. kar veya ticari avantaj amacıyla yapılmış veya dağıtılmış ve kopyaların bu duyuru ve alıntının tamamı ilk sayfadadır. Bileşenler için telif hakları Bu çalışmanın ACM dışında başkaları tarafından sahiplenilmesi onurlandırılmalıdır. ile soyutlama krediye izin veriliyor. Başka bir şekilde kopyalamak veya yeniden yayınlamak, sunuculara göndermek veya listelere yeniden dağıtılması, önceden özel izin ve/veya ücret gerektirir. Talep izinler:[email protected]'dan. SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada © 2019 Bilgisayar Makineleri Derneği. ACM ISBN 978-1-4503-6873-5/19/10...$15,00 https://doi.org/10.1145/3341301.3359636 Meksika, iki komşu ülke. Son kullanıcılar yaklaşık 9$ ödüyor ortalama olarak bu tür bir transfer [32] ve ikili bir anlaşma için ülkelerin merkez bankalarının aracılığı ile ancak azaltılabilir temel bankanın maliyeti [2] öğe başına 0,67 ABD dolarıdır. Ücretlerin yanı sıra, Uluslararası ödemelerin gecikmesi genellikle sayılır birkaç gün içinde yurt dışından hızlı bir şekilde para almayı imkansız hale getiriyor acil durumlar. Bankacılık sisteminin olmadığı ülkelerde Çalışıyor veya tüm vatandaşlara hizmet vermiyorsa ya da ücretlerin kabul edilemez olduğu durumlarda insanlar ödemelerini [38] numaralı otobüsle göndermeye başvuruyor. [19] tekneyle ve ara sıra Bitcoin [55] ile, hepsi riske, gecikmeye veya rahatsızlığa neden olabilir. Uyum maliyetleri her zaman mevcut olsa da, kanıtlar rekabet eksikliği nedeniyle önemli miktarda kaybın olduğunu gösteriyor [21], verimsiz teknoloji nedeniyle daha da kötüleşiyor. İnsanlar nerede yenilik yapılabilir, fiyatlar ve gecikmeler düşer. Örneğin, 2019'un 2. çeyreğinde banka hesaplarından yapılan havalelerin maliyeti ortalama %6,99, mobil paranın rakamı ise yalnızca %4,88 idi [13]. Yeniliği cezbeden açık, küresel bir ödeme ağı ve banka dışı kuruluşların rekabeti bu durumu aşağı çekebilir uyumluluk [83] dahil olmak üzere tüm katmanlardaki maliyetler ve gecikmeler. Bu belgede blockchain tabanlı bir ödeme olan Stellar anlatılmaktadır Yeniliği kolaylaştırmak için özel olarak tasarlanmış ağ ve Uluslararası ödemelerde rekabet. Stellar ilki Aşağıdaki hedeflerin üçünü de karşılayacak sistem (bir yeni ama ampirik olarak geçerli “İnternet hipotezi”): 1. Açık üyelik – Herkes paraya dayalı para basabilir kullanıcılar arasında değiş tokuş edilebilecek dijital token'ler. 2. İhraççı tarafından uygulanan kesinlik – Bir token'nın ihraççısı engelleyebilir token içindeki işlemlerin geri alınmasını veya geri alınmasını önleyin. 3. Veren kurumlar arası atomiklik – Kullanıcılar atomik olarak alışveriş yapabilir ve birden fazla ihraççıdan tokens ticareti yapın. İlk ikisine ulaşmak kolaydır. Paypal, Venmo, WeChat gibi bir ürünü her firma tek taraflı olarak sunabilir Pay veya Alipay ile ödemelerin kesinliğini sağlayın yarattıkları sanal para birimleri. Ne yazık ki, bu para birimleri arasında atomik işlem yapmak imkansızdır. Aslında Paypal'ın Venmo'nun ana şirketini satın almasına rağmen 2013'te son kullanıcıların Venmo'yu göndermesi hala imkansız Paypal kullanıcılarına [78] dolar. Satıcılar yalnızca son zamanlarda hatta tek entegrasyonla ikisini de kabul edin. 2. ve 3. hedeflere kapalı bir sistemde ulaşılabilir. Özellikle bazı ülkelerde etkin yurt içi ödeme sistemi mevcuttur. ağlar genellikle evrensel olarak güvenilen bir düzenleyici otorite tarafından denetlenir. Ancak üyelik kapalı bir alanla sınırlıdır. anlaşmalı bankalar kümesi ve ağlar aşağıdakilerle sınırlıdır: Bir ülkenin düzenleyici otoritesinin erişimi.SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. Kazılan blockchains'de 1. ve 3. hedeflere ulaşıldı, en önemlisi Ethereum [3] üzerindeki ERC20 tokens biçimindedir. Bu blockchain'lerin ana fikri, insanları ödeme yaptıkları için ödüllendirecek yeni bir kripto para birimi yaratmaktır. işlemlerin geri döndürülmesi zor. Maalesef bu, token veren kuruluşların işlemin kesinliğini kontrol etmediği anlamına gelir. Eğer yazılım hatalar işlem geçmişinin yeniden düzenlenmesine neden olur [26, 73], veya insanları dolandırmanın ganimeti, maliyeti aştığında geçmişi yeniden düzenlerken [74, 97], ihraççılar tokens'den sorumlu olabilir zaten gerçek dünya parası karşılığında kullandılar. Stellar blockchain'nin iki ayırt edici özelliği vardır. İlk olarak, tokens arasındaki verimli pazarları yerel olarak destekler farklı ihraççılardan. Özellikle herkes token düzenleyebilir, blockchain, herhangi bir token çifti arasındaki ticaret için yerleşik bir emir defteri sağlar ve kullanıcılar yol ödemeleri yapabilir birkaç döviz çifti arasında atomik olarak ticaret yaparken uçtan uca limit fiyatı garanti eder. İkincisi, Stellar yeni bir Bizans anlaşması getiriyor protokol, SCP (Stellar Konsensüs Protokolü), bunun aracılığıyla token verenler, zorunlu kılmak için belirli validator sunucularını belirler işlem kesinliği. Hiç kimse ihraççının validator'lerinden (ve temel dijital imzalarından ve kriptografik hashes güvende kalır), ihraççı tam olarak hangi işlemlerin gerçekleştiğini bilir ve riskten kaçınır blockchain geçmişin yeniden düzenlenmesinden kaynaklanan kayıplar. SCP'nin temel fikri, çoğu varlık ihraççısının bundan faydalanmasıdır. Likit piyasalar ve atomik işlemleri kolaylaştırmak istiyor diğer varlıklarla. Bu nedenle, validator yöneticiler yapılandırıyor sunucularının diğer validator'lerle tam olarak aynı fikirde olması tüm varlıklardaki tüm işlemlerin geçmişi. Bir validator v1 olabilir v2 ile anlaşacak şekilde yapılandırılmış veya v2 kabul edecek şekilde yapılandırılabilir v1 ile veya her ikisi de birbiriyle uyumlu olacak şekilde yapılandırılabilir; her durumda, ikisi de bir işlem geçmişini taahhüt etmeyecektir. diğerinin farklı bir tarihe bağlanamayacağını biliyor. Geçişliliğe göre, eğer v1, v2 ile anlaşamıyorsa ve v2, v3 ile anlaşamıyorsa (veya tam tersi), v1, v2 ile anlaşamıyorsa v3, v3'ün v1'in duyduğu varlıkları temsil edip etmediği arasında. Bu anlaşma ilişkilerinin hipotezi altında SCP, tüm ağı geçişli olarak bağlamayı garanti eder küresel bir anlaşma, onu küresel bir Bizans anlaşması haline getiriyor açık üyelik protokolü Bu yeni bağlantılılık varsayımına İnternet hipotezi diyoruz ve bunun hem “İnternet”i (herkesin anladığı) geçişli olarak bağlanan en büyük tek IP ağı anlamına gelir) ve eski uluslararası ödemeler (bunlar adım adım atomik değildir ancak geçişli olarak bağlantılı, küresel bir yapıdan yararlanır finansal kurumlar ağı). Stellar Eylül 2015'ten bu yana üretimde kullanılıyor. blockchain uzunluğunu yönetilebilir tutmak için sistem çalışır 5 saniyelik aralıklarla SCP — blockchain standartlarına göre hızlı, ancak Bizans anlaşmasının tipik uygulamalarından çok daha yavaş. Ana kullanım alanı ödemeler olsa da Stellar aynı zamanda Fayda sağlayan parasal olmayan takas edilebilir token'ler için cazip olduğu kanıtlanmış doğrudan ikincil piyasalardan (bkz. Bölüm 7.1). Bir sonraki bölümde ilgili çalışmalar anlatılmaktadır. Bölüm 3 sunar SCP. Bölüm 4, SCP'nin resmi doğrulamasını açıklamaktadır. Bölüm 5'te Stellar'nin ödeme katmanı açıklanmaktadır. Bölüm 6 ilgilidir dağıtım deneyimlerimizden ve öğrendiğimiz derslerden bazıları. Bölüm 7'de sistem değerlendirilmektedir. Bölüm 8 sona eriyor.
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 fikir birliği protokolü
Stellar konsensüs protokolü (SCP) yeter sayıya dayalıdır Açık üyelikle Bizans anlaşması protokolü. Yeterli çoğunluk, bireysel düğümlerin birleşik yerel yapılandırma kararlarından ortaya çıkar. Ancak düğümler yalnızca tanır kendilerinin ait olduğu yetersayılar ve ancak bundan sonra diğer tüm çekirdek üyelerinin yerel konfigürasyonlarının öğrenilmesi. Bu yaklaşımın bir faydası SCP'nin doğası gereği Hangi düğümlerin var olduğuna dair heterojen görüşlere tolerans gösterir. Bu nedenle, düğümler herhangi bir müdahaleye gerek kalmadan tek taraflı olarak katılıp ayrılabilirler. Üyeliği koordine etmek için “değişikliği görüntüle” protokolü. 3.1 Federe Bizans anlaşması Geleneksel Bizans anlaşma problemi, N düğümden oluşan kapalı sistem; bunlardan bazıları hatalıdır ve keyfi davranın. Düğümler giriş değerlerini alır ve değiştirir Girişler arasında bir çıkış değerine karar vermek için mesajlar. Bir Bizans anlaşma protokolü, iyi davranan iki düğümün farklı kararlar vermediği ve benzersiz bir karar vermediği durumlarda güvenlidir. karar geçerli bir girdiydi (geçerli mutabakata varılan bazı tanımlar için)SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. önceden). Bir protokol bunu garanti ettiğinde yayındadır Her dürüst düğüm sonunda bir karar verir. Tipik olarak protokoller bazı tamsayılar için N = 3f + 1 olduğunu varsayar f > 0 ise güvenliği ve bir tür canlılığı garanti eder, böylece en fazla f düğümü hatalı olduğu sürece. Bunların bir aşamasında protokoller, düğümler önerilen değerlere ve bir teklife oy verir Oy yeter sayısı olarak adlandırılan 2f + 1 oy alınması, Karar. N = 3f + 1 düğüm ile herhangi iki yeter sayı boyut 2f + 1 en az f + 1 düğümde örtüşüyor; bunlardan f olsa bile örtüşen düğümler hatalı, iki çekirdek en azından paylaşıyor hatalı olmayan bir düğüm, çelişkili kararları önler. Ancak bu yaklaşım yalnızca tüm düğümlerin aynı fikirde olması durumunda işe yarar. SCP'de imkansız olan yeterli çoğunluğu ne oluşturur? iki düğüm birbirinin varlığından bile haberdar olmayabilir. SCP ile her düğüm tek taraflı olarak düğüm kümelerini bildirir, yetersayı dilimleri olarak adlandırılır, öyle ki (a) v, eğer hepsi varsa bir dilimin üyeleri sistemin durumu hakkında hemfikirdir, ardından haklılar ve (b) v, dilimlerinden en az birinin hakkında zamanında bilgi sağlamak için mevcut olacaktır. sistemin durumu. Ortaya çıkan sistemi diyoruz, düğümler ve bunların dilimleri, bir Birleşik Bizans Anlaşması (FBA) sistemi. Daha sonra göreceğimiz gibi, bir yeter sayı sistemi ortaya çıkıyor düğümlerin dilimlerinden. Gayri resmi olarak, bir FBA düğümünün dilimleri kiminle olduğunu ifade eder düğüm anlaşmayı gerektirir. Örneğin bir düğüm, her biri 3 düğüm çalıştıran 4 özel kuruluşla anlaşma gerektirebilir; için kesinti süresini karşılamak için dilimlerini tüm setler olacak şekilde ayarlayabilir Her kuruluştan 2 düğümden oluşur. Eğer bu “gerekiyorsa "ile anlaşma" ilişkisi herhangi iki düğümü geçişli olarak ilişkilendirir, küresel bir anlaşmaya varıyoruz. Aksi halde ayrılık yaşayabiliriz ancak yalnızca hiçbiri gerektirmeyen kuruluşlar arasında diğeriyle anlaşma. Günümüzün topolojisi göz önüne alındığında Finansal sistemdeki yaygın yakınlaşmanın, insanların tek bir defter tarihi olarak adlandırdığı bir defter tarihi üretmeye devam edeceğini varsayıyoruz. İnternetten bahsettiğimiz şekliyle “Stellar ağı”. Yeter sayı, dilimlerden aşağıdaki gibi ortaya çıkar. Her düğüm belirtir Gönderdiği her mesajdaki yetersayı dilimleri. S olsun bir dizi mesajın kaynaklandığı düğümler kümesi. bir düğüm, mesaj kümesinin yeter sayıya ulaştığını düşünüyor S'nin her üyesinin S'de yer alan bir dilime sahip olduğu eşik. Yapı itibarıyla böyle bir S kümesi, eğer oybirliğiyle kabul edilirse, şu koşulu karşılar: üyelerinin her birinin anlaşma gereksinimleri. Hatalı bir eş, neyi değiştirmek için hazırlanmış dilimlerin reklamını yapabilir? iyi huylu düğümler yeterli çoğunlukları dikkate alır. Protokol analizi açısından, FBA'daki yeter çoğunluğu boş olmayan bir sayı olarak tanımlıyoruz. en az bir yetersayı dilimini kapsayan düğümlerin S kümesi kusurlu olmayan her üye. Bu soyutlama, herhangi bir küme gibi sağlamdır. Oybirliğiyle alınmış bir yeter sayıyı temsil ettiği iddia edilen mesajların sayısı aslında öyledir (hatalı düğümlerden gelen mesajları içerse bile), ve S'nin yalnızca iyi davranan düğümleri içermesi kesindir. içinde Bu bölümde ayrıca düğümlerin dilimlerinin değişmediğini varsayıyoruz. Bununla birlikte, sonuçlarımız değişen dilim vakasına aktarılıyor Çünkü dilimlerin değiştiği bir sistem, bundan daha az güvenli değildir. bir düğümün dilimlerinin tüm bileşenlerden oluştuğu sabit dilim sistemi değişen dilimler durumunda kullandığı dilimler (bkz. Teorem [68] içinde 13). Bölüm 4'te açıklandığı gibi canlılık şunlara bağlıdır: iyi davranan düğümler sonunda güvenilmez düğümleri ortadan kaldırır onların dilimlerinden. Farklı düğümlerin farklı anlaşma gereksinimleri olduğundan, FBA küresel bir güvenlik tanımına izin vermez. Diyoruz Arızalı olmayan düğümler v1 ve v2 her seferinde iç içe geçmiş durumda v1 yeter sayısı, v2'nin her yeter sayısıyla en az bir noktada kesişiyor arızalı olmayan düğüm Bir FBA protokolü anlaşmayı sağlayabilir yalnızca iç içe geçmiş düğümler arasında; SCP bunu yaptığına göre bu onun hatası Güvenlik toleransı optimaldir. İnternet hipotezi, Stellar tasarımının temelinde, insanların önemsediği düğümlerin olduğu belirtiliyor hakkında iç içe geçecektir. Eğer I, tekdüze olarak hatasız bir çekirdek ise, I'in her iki üyesi de iç içe geçmişse, I'in dışındaki her düğüm hatalı olsa bile, bir I düğümleri kümesinin sağlam olduğunu söyleriz. Sezgisel olarak, o zaman, sağlam olmayanların eylemlerine karşı dayanıklı kalmalıyım düğümler. SCP, hem [93] engellenmeyen canlılığı hem de düğümlerin kendilerine ihtiyaç duymasa da, bozulmamış kümelerin güvenliği hangi setlerin sağlam olduğunu bilmek (ve bilememek). Ayrıca kesişen iki sağlam kümenin birleşimi bozulmamış bir set. Bu nedenle, bozulmamış kümeler bir bölümü tanımlar. Her bölümün güvenli ve canlı olduğu iyi huylu düğümler (bazı koşullar altında), ancak farklı bölümler çıktı alabilir farklı kararlar. 3.1.1 Amazon Lojistik'te Güvenlik ve Canlılık hususları Sınırlı istisnalar [64] dışında, kapalı Bizans anlaşma protokollerinin çoğu, denge noktasına göre ayarlanmıştır. Güvenlik ve canlılık aynı hata toleransına sahiptir. FBA'da, bu, arızalardan bağımsız olarak tümünün iç içe setler de sağlamdır. FBA'nın belirlediği göz önüne alındığında Yeterli çoğunluk merkezi olmayan bir şekilde sağlanıyorsa, bireysel dilim seçimlerinin bu dengeye yol açması pek olası değildir. Üstelik en azından Stellar'de denge istenmiyor: sonuçlar Bir güvenlik arızasının (yani çift harcanan dijital paranın) canlılık başarısızlığından çok daha kötü (yani gecikmeler) zaten Stellar tarihinden birkaç gün önce yapılan ödemelerde). İnsanlar bu nedenle büyük çekirdek dilimleri seçilmelidir ve seçilmelidir, öyle ki düğümlerinin sağlam olmaktan ziyade iç içe geçmiş kalması daha olasıdır. Teraziyi daha da eğmek, iyileşmeyi kolaylaştırır FBA sisteminde geleneksel kapalı sisteme kıyasla tipik canlılık hataları. Kapalı sistemlerde tüm mesajların aynı nisaplar dizisine göre yorumlanır. Bu nedenle, Arızadan kurtulmak için düğüm ekleme ve kaldırma gerektirir bir yeniden yapılandırma olayı üzerinde fikir birliğine varmak; fikir birliği artık canlı olmadığında bu zordur. FBA'nın aksine, herhangi bir düğüm çekirdek dilimlerini herhangi bir zamanda tek taraflı olarak ayarlayabilir zaman. Sistemik olarak önemli bir tesisteki kesintiye yanıt olarak düğüm yöneticileri dilimlerini şu şekilde ayarlayabilir: Sorunu çözmeye çalışın, biraz yanıtları koordine etmeye benzer BGP felaketlerine [63] (her ne kadar kısıtlamalar olmasa da) fiziksel ağ bağlantıları üzerinden yönlendirme).
Stellar ile hızlı ve güvenli küresel ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada 3.1.2 Basamaklı teoremi SCP, [42] temel yuvarlak modelinin şablonunu takip eder; Düğümler, her biri bir dizi numaralı oy pusulası aracılığıyla ilerler. üç görevi yerine getirmek: (1) önceki oylamada alınan herhangi bir kararla çelişmeyen "güvenli" bir değer belirlemek (genellikle bu değer olarak adlandırılır) oy pusulasını hazırlamak), (2) güvenli değer üzerinde anlaşmak ve (3) anlaşmanın başarılı olduğunu tespit etmek. Ancak FBA'nın açık Üyelik birçok yaygın tekniğin önünde engel teşkil ediyor. Geleneksel kapalı protokolleri Amazon Lojistik'e "taşımak" imkansız yetersayı tanımını değiştirerek modeli değiştirin. Birçok protokolün kullandığı tekniklerden biri rotasyondur Zaman aşımlarını takiben lider düğümler aracılığıyla dönüşümlü olarak. Kapalı bir sistemde, çevrimsel lider seçimi, sonunda benzersiz ve dürüst bir lider, tek bir değer üzerinde anlaşmayı koordine eder. Ne yazık ki, dönüşümlü üyeliği bilinmeyen bir FBA sisteminde çalışamaz. FBA'da başarısız olan diğer bir yaygın teknik, belirli bir yeter sayının tüm düğümleri ikna edebileceğini varsaymaktır. Örneğin, eğer herkes herhangi bir 2f + 1 düğümünü çekirdek olarak tanırsa, o zaman 2f + 1 imza, protokol durumunu tüm düğümlere kanıtlamak için yeterlidir. Benzer şekilde, eğer bir düğüm aynı mesajlardan oluşan bir çoğunluk alırsa güvenilir yayın [24] aracılığıyla, düğüm, arızalı olmayan tüm düğümlerin de yeterli çoğunluğu göreceğini varsayabilir. FBA'da ise tam tersine, yetersayı, yetersayı dışındaki düğümler için hiçbir şey ifade etmez. Son olarak, federe olmayan sistemler sıklıkla “geriye doğru” Güvenlikle ilgili akıl yürütme: f + 1 düğümleri hatalıysa, tüm güvenlik garantiler kaybolur. Dolayısıyla, eğer v düğümü f + 1 düğümlerin hepsini duyarsa bazı gerçekleri belirtin F, v en az birinin bunu söylediğini varsayabilir hiçbir güvenlik kaybı olmadan gerçektir (ve dolayısıyla F doğrudur). Böyle Güvenlik çiftlerin bir özelliği olduğu için FBA'da mantık başarısız oluyor düğüm sayısı, böylece bazı eşler için güvenliğini kaybetmiş bir düğüm Kötü gerçekleri varsayarak her zaman daha fazla düğümün güvenliğini kaybedersiniz. Ancak FBA, canlılık konusunda geriye doğru mantık yürütebilir. Bir v-engelleme kümesini her bir düğümle kesişen bir düğüm kümesi olarak tanımlayın. v dilimi. Eğer bir v-engelleme seti B oybirliğiyle hatalıysa, B düğüm v'nin yeterli çoğunluğunu reddedebilir ve canlılığına mal olabilir. Dolayısıyla eğer B oybirliğiyle F gerçeğini belirtiyorsa v, F'den birinin olduğunu biliyor doğru veya v sağlam değil. Ancak v'nin yine de tam bir görünüm görmesi gerekiyor iç içe geçmiş düğümlerin F ile çelişmeyeceğini bilmek için yeter sayı, bu da SCP'de son bir iletişim turuna yol açar ve benzer şekilde gerekli olmayan diğer FBA protokolleri [47] kapalı üyelik protokolleri. Sonuç şu ki, elimizde Potansiyel gerçeklere ilişkin üç olası güven düzeyi: belirsiz, sağlam düğümler arasında varsayılması güvenli (ki bunu yapacağız) kabul edilen gerçekler) ve iç içe geçmiş durumlar arasında varsayılması güvenli düğümler (bunlara doğrulanmış gerçekler adını vereceğiz). V düğümü, B kümesinin vbblocking olup olmadığını, B'nin tüm dilimleriyle kesişip kesişmediğini kontrol ederek etkili bir şekilde belirleyebilir. İlginç bir şekilde, düğümler her zaman yaptıkları açıklamaları duyuruyorsa kabul ederse ve tam çoğunluk bir ifadeyi kabul ederse, bu, ifadelerin her yere yayıldığı basamaklı bir süreci başlatır. sağlam setler. Bu yayılmanın altında yatan temel gerçeği diyoruz aşağıdakileri karşılayan basamaklı teorem: Eğer ben bir bozulmamış küme, Q I'in herhangi bir üyesinin yeter sayısıdır ve S herhangi bir üyedir Q'nun üst kümesi ise ya S ⊇I ya da bir v ∈I üyesi vardır öyle ki v < S ve I ∩S v-bloke edicidir. Sezgisel olarak bu durum böyle değilse, S'nin tamamlayıcısı bir yeter sayı içerecektir I ile kesişiyor ama Q ile kesişmiyor, çekirdek kesişimini ihlal ediyor. S = Q ile başlarsak ve S'yi tekrar tekrar genişletirsek şunu unutmayın: Engellediği tüm düğümleri dahil edersek basamaklı bir etki elde ederiz, ta ki, sonuçta S, I'in tamamını kapsar. 3.2 Protokol açıklaması SCP, adı verilen fikir birliğine varmaya yönelik bir dizi girişimden oluşan, kısmen senkronize bir fikir birliği protokolü [42] oy pusulaları. Oy pusulalarında artan süreli zaman aşımları kullanılır. bir oylama senkronizasyon protokolü düğümlerin açık kalmasını sağlar oylamalara kadar artan sürelerde aynı oylama etkili bir şekilde senkronizedir. Sonlandırma garanti edilmez oylamalar eşzamanlı olana kadar, ancak iki eşzamanlı oylama iyi davranan düğüm dilimlerinin hatalı üyelerinin yaptığı SCP'nin sonlandırılması için müdahale etmemek yeterlidir. Bir oylama protokolü, her oylama sırasında gerçekleştirilen eylemleri belirtir. oy pusulası. Oylama, düğümlerin yer aldığı bir hazırlık aşamasıyla başlar. önermek için çelişmeyen bir değer belirlemeye çalışın önceki herhangi bir karar. Daha sonra, bir taahhüt aşamasında düğümler şunu dener: Hazırlanan değere karar vermek. Oylamada, birleşik oylama adı verilen bir anlaşma alt protokolü kullanılır.n hangi düğümler soyut ifadelere oy verir bu sonunda onaylanabilir veya takılıp kalabilir. Bazı ifadeler çelişkili olarak adlandırılabilir ve güvenlik Federasyon oylamanın garantisi, bir oylamada iki üyenin olmamasıdır. iç içe geçmiş küme çelişkili ifadeleri doğrular. Bir bildirimin onaylanması, sağlam olması dışında garanti edilmez. üyelerinin hepsinin aynı şekilde oy kullandığı bir grup. Ancak eğer bir sağlam bir grubun üyesi bir beyanı doğruluyor, birleştirilmiş oylama, bozulmamış setin tüm üyelerinin eninde sonunda bu ifadeyi onaylamasını garanti eder. Bu nedenle geri dönüşü olmayan adımlar atmak teyit edici ifadelere yanıt olarak canlılığı korur sağlam düğümler Düğümler başlangıçta bir adaylıktan elde edilen değerleri önerir tüm üyelerin sağlam olma şansını artıran protokol aynı değeri öneren ve sonunda yakınsayan küme (yakınsamanın tamamlandığını belirlemenin hiçbir yolu olmasa da). Aday gösterme, birleşik oylamayı lider seçimiyle birleştirir. FBA'da hepsini bir kez denemek mümkün olmadığından, aday gösterme yöntemleri olasılıksal bir lider seçim şeması. Basamaklı teoremi hem oylamada önemli bir rol oynar senkronizasyon ve engellenen durumlardan kaçınma fesih artık mümkün değildir. 3.2.1 oylama SCP düğümleri, bir dizi numaralı oylama yoluyla ilerler ve hangi beyanlar üzerinde anlaşmaya varmak için birleşik oylama kullanır? Değerlerin hangi oylamada belirlenip belirlenmeyeceğine karar verilir. Eşzamansız ise veya hatalı davranışın n oylamasında karara varılmasını engellemesi, düğümler zaman aşımına uğradı ve n + 1 oylamasında tekrar deneyin.
SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. Federal oylamanın sona ermeyebileceğini hatırlayın. Dolayısıyla bazı Oy pusulalarıyla ilgili açıklamalar kalıcı olarak sıkışıp kalabilir düğümlerin asla karar veremeyecekleri belirsiz durum hala devam ediyor veya takılıp kaldı. Çünkü düğümler göz ardı edilemez belirsiz ifadelerin daha sonra doğru çıkma olasılığı, yeni beyanlar üzerinde asla federal oylamaya kalkışmamalılar belirsiz olanlarla çelişen. Her n oylamasında, düğümler iki türde birleştirilmiş oylamayı kullanır beyanının: • hazırla ⟨n,x⟩– x dışında hiçbir değerin olmadığını belirtir ≤n herhangi bir oylamada kararlaştırıldı veya belirlenecek. • taahhüt ⟨n,x⟩– x'e n oylamasında karar verildiğini belirtir. Önemli olarak, ⟨n,x⟩contradicts taahhütlerini hazırladığınızı unutmayın ⟨n',x ′⟩n ≥n' ve x , x ′ olduğunda. Bir düğüm, birleştirilmiş oylamayı deneyerek n oylamaya başlar. ifade hazırlığı ⟨n,x⟩. Daha önce hazırlanmış bir beyan varsa Federasyon oylamasıyla başarıyla onaylanan düğüm, en yüksek oylamanın onaylanmış formundan x'i seçer. Aksi halde düğüm x'i çıktıya ayarlar. Bir sonraki alt bölümde açıklanan adaylık protokolü. Ancak ve ancak bir düğüm başarılı bir şekilde hazırlığı onaylarsa ⟨n,x⟩ n oylamasında, ⟨n,x⟩ taahhüdü üzerine federal oylama girişiminde bulunur. Eğer başarılı olursa, bu SCP'nin karar verdiği anlamına gelir, dolayısıyla düğüm çıktı verir onaylanmış taahhüt beyanındaki değer. İç içe geçmiş bir S kümesi düşünün. En fazla bir değer olduğundan Belirli bir oylamada S üyeleri tarafından hazırlanan teyit edilebilir, iki farklı değerin taahhüt edildiği teyit edilemez. Belirli bir oylamada S üyeleri. Üstelik ⟨n,x⟩ taahhüt edilirse onaylandı, ardından ⟨n,x⟩ hazırlığı da onaylandı; o zamandan beri ⟨n,x⟩ hazırlamak, federal oylamanın anlaşma garantileri ile daha önce farklı bir değere yönelik taahhütlerle çelişir daha erken bir tarihte farklı bir değere karar verilemeyeceğini anlıyoruz S üyeleri tarafından yapılan oylama. Oy pusulası sayılarına ilişkin tümevarım yoluyla, bu nedenle SCP'nin güvenli olduğunu anlayın. Canlılık için sağlam bir I kümesini ve yeterince uzun bir diziyi düşünün. eşzamanlı oylama Dilimlerde hatalı düğümler görünüyorsa iyi huylu düğümlerin sayısı n'ye müdahale etmez, ardından oylamayla n + 1 I'in tüm üyeleri aynı P hazırlama ifadesini onayladılar. Eğer P = ∅ ve oy pusulası n yeterince uzunsa, adaylık protokolü bazı x değerlerine yakınlaşacaktır. Aksi takdirde, P'de en yüksek oyu alan hazırlıktan elde edilen değer x olsun. Her iki durumda da, eşit şekilde federal girişimde bulunacağım Bir sonraki oylamada ⟨n + 1,x⟩ hazırlığı için oylama. Bu nedenle eğer n + 1 de eşzamanlıdır, kaçınılmaz olarak x kararı takip eder. 3.2.2 Adaylık Aday gösterme, aşağıdaki ifadeler üzerinde federal oylamayı gerektirir: • x'i aday gösterin – x'in geçerli bir karar adayı olduğunu belirtir. Düğümler birden fazla değeri aday göstermek için oy kullanabilir (farklı) aday ifadeleri çelişkili değildir. Ancak bir kez bir düğüm herhangi bir aday beyanını onayladığında oylamayı durdurur yeni değerleri aday gösterin. Birleşik oylama hala bir düğümün şunları yapmasına izin veriyor: oy vermediği yeni aday beyanlarını onaylayın; oy ver ya da kabul et çoğunluktan kabul etmek çoğunluktan a geçerlidir gelen bir teklifi kabul et engelleme seti taahhütsüz oy verdi kabul edildi doğrulandı oy verildi ¬a Şekil 1. Birleştirilmiş oylamanın aşamaları bozulmamış bir kümenin üyelerinin birbirlerinin bilgilerini onaylamasına olanak tanır yeni oyları alıkoyarken değerleri aday gösterdi. Aday göstermenin (gelişen) sonucu, onaylanmış aday gösterme ifadelerindeki tüm değerlerin deterministik bir birleşimidir. Eğer x bir dizi işlemi temsil eder, düğümler birliği alabilir kümelerin en büyüğü veya en yüksek hash değerine sahip olanıdır, yani tüm düğümler aynı şeyi yaptığı sürece. Çünkü düğümler yeniyi saklıyor bir aday beyanını onayladıktan sonra oylar, Onaylanmış ifadeler yalnızca sonlu sayıda değer içerebilir. Onaylanan açıklamaların güvenilir bir şekilde yayılması bozulmamış kümeler, bozulmamış düğümlerin eninde sonunda aynı noktada birleşeceği anlamına gelir aynı aday değerler kümesi ve dolayısıyla adaylık sonucu, ancak bilinmeyen bir noktada keyfi olarak protokolün sonlarında. Düğümler, birleşik lider seçimini kullanarak aday ifadelerindeki farklı değerlerin sayısı. Yalnızca Henüz aday beyanına oy vermemiş bir lider yeni bir x getirebilir. Diğer düğümler sizden haber almayı bekliyor Liderlerin (geçerli) aday oylarını kopyalayın. Başarısızlığa uyum sağlamak için liderler kümesi büyümeye devam ediyor zaman aşımları meydana gelir, ancak pratikte yalnızca birkaç düğüm yeni x değerlerini sunar. 3.2.3 Federe oylama Birleşik oylamada gösterilen üç aşamalı bir protokol kullanılır Şekil 1. Düğümler öncelikle soyut ifadeler üzerinde anlaşmaya varmaya çalışırlar. oylama, ardından kabul etme ve son olarak beyanları onaylama. Bir v düğümü, geçerli olmayan herhangi bir a ifadesine oy verebilir. diğeriyle çelişiyorödenmemiş oylar ve kabul edilen beyanlar. Bunu imzalı bir oylama mesajı yayınlayarak yapar. v daha sonra a'nın kabul edilen diğer ifadelerle tutarlı olması ve her iki (durum 1)v'nin bir yetersayı üyesi olması durumunda a'yı kabul eder; her düğüm ya a'ya oy verir ya da a'yı kabul eder veya (durum 2) v olsa bile a'ya oy vermediyse, v-engelleyici küme a'yı kabul eder. Durum 2'de v olabilir daha önce a ile çelişen oylar kullanmışken, şimdi bunlar reddedildi. v'nin geçersiz oyları unutmasına izin verilir ve onları hiç kullanmamış gibi davran çünkü eğerv sağlamsa, biliyor Reddedilen oylar, 1. durumda yetersayıyı tamamlayamaz. v a'yı kabul ettiğini yayınlar, ardından içeri girdiğinde a'yı onaylar oybirliğiyle kabul eden bir yeter sayı. Şekil 2 şunları göstermektedir: v-bloklama kümelerinin etkisi ve basamak teoremi federal oylama. İç içe geçmiş iki düğüm, çelişkili ifadeleri onaylayamaz çünkü gerekli iki yeter sayının aynı fikirde olması gerekir.Stellar ile hızlı ve güvenli küresel ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada 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。
X'e oy ver
E oyu ver (bir) 3 4 2 1 5 7 6 Oy ver X Oy ver X Oy ver X Oy ver e Oy ver X Oy ver e Oy ver e (b) 3 4 2 1 5 7 6 Kabul et X Oy ver X Kabul et X Oy ver e Kabul et X Oy ver e Oy ver e (c) 3 4 2 1 5 7 6 Kabul et X Kabul et X Kabul et X Oy ver e Kabul et X Kabul et X Oy ver e (d) 3 4 2 1 5 7 6 Kabul et X Oy ver X Kabul et X Kabul et X Kabul et X Kabul et X Kabul et X (e) Şekil 2. Birleştirilmiş oylamada kademeli etki. Her düğüm, dilimin üyelerine oklarla gösterilen bir çekirdek dilime sahiptir. (a) Çelişkili X ve Y ifadeleri tanıtılır. (b) Düğümler geçerli ifadelere oy verir. (c) Düğüm 1, yeterli çoğunluktan sonra X'i kabul eder {1, 2, 3, 4} oybirliğiyle X'e oy verir. (d) 1, 2, 3 ve 4. düğümlerin tümü X'i kabul eder; {1} kümesi 5'i engelliyor, dolayısıyla düğüm 5 X'i kabul ederek geçersiz kılıyor önceki oyu Y'ye verilmiştir. (e) {5} kümesi 6- ve 7'yi bloke etmektedir, dolayısıyla 6 ve 7'nin her ikisi de X'i kabul etmektedir. çelişkili ifadeleri kabul edemeyen hatalı olmayan düğüm. Bir bildirimin onaylanması garanti edilmez: Oyların bölünmesi durumunda her iki beyan da kalıcı olarak geçerli olabilir. oylama aşamasında yetersayıyı beklemek zorunda kaldı. Ancak eğer bozulmamış bir kümedeki bir düğüm Bir ifadeyi doğrularım, basamaklı teorem ve durum 2'nin kabul edilmesi, sonunda I'in tamamının olmasını sağlar bu ifadeyi onaylayın. 3.2.4 Oy pusulası senkronizasyonu Düğümler bir taahhüt ifadesini onaylayamıyorsa mevcut oylamada, bir mola sonrasında pes ediyorlar. Zaman aşımı alır keyfi sınırlara uyum sağlamak için her oylamada daha uzun ağ gecikmesinde. Ancak zaman aşımları tek başına aynı anda başlamamış veya başlamamış düğümlerin oylamalarını senkronize etmek için yeterli değildir. başka nedenlerden dolayı senkronizasyonu bozuldu. Senkronizasyonu sağlamak için düğümler zamanlayıcıyı yalnızca bir sistemin parçası olduklarında başlatır. mevcut (veya daha sonraki) oylamada bulunan yeter çoğunluk Bu erken başlayan düğümleri yavaşlatır ve hiçbir Sağlam bir grubun üyesi grubun çok ilerisinde kalır. Ayrıca, eğer bir v düğümü daha sonra bir v-engelleme setini fark ederse oylamada hemen en düşük oylamaya atlanır, öyle ki herhangi bir zamanlayıcıdan bağımsız olarak artık durum böyle değil. Çağlayan teoremi daha sonra tüm başıboş kalanların yetişmesini sağlar. Sonuç oy pusulalarının sağlam bir şekilde kabaca senkronize edilmesidir sistem senkronize hale geldiğinde ayarlanır. 3.2.5 Federe lider seçimi Lider seçimi, her düğümün böyle bir şekilde liderleri seçmesine olanak tanır. düğümlerin genellikle yalnızca bir veya küçük bir sayı seçmesi liderlerin. Lider başarısızlığını telafi etmek için lider seçimi turlarla ilerler. Mevcut turun liderleri ise sorumluluklarını yerine getirmiyor gibi görünüyorlar ve bir süre sonra belirli zaman aşımı süresi düğümleri bir sonraki tura geçer Takip ettikleri liderler kümesini genişletin. Her turda, [0,hmax] aralığında tamsayıların çıktısını veren iki benzersiz şifreleme hash işlevi (H0 ve H1) kullanılır. Örneğin, Stellar Hi(m) = SHA256(i∥b∥r ∥m) kullanır; burada b genel SCP örneğidir (blok veya defter numarası), r ise lider seçim turu numarası ve hmax = 2256. Bir turda v düğümünün önceliğini şu şekilde tanımlarız: öncelik(v) = H1(v) Her düğüm için bir saman adam lider olarak seçilecek en yüksek önceliğe sahip düğüm(v). Bu yaklaşım işe yarıyor neredeyse aynı çekirdek dilimleriyle iyi, ancak düzgün şekilde çalışmıyor Dengesiz konfigürasyonlarda düğümlerin önemini yakalayın. Örneğin, eğer Avrupa ve Çin'in her biri 3 katkı sağlıyorsa her çoğunluk için düğümler, ancak Çin 1.000 düğüm ve Avrupa 4 çalıştırıyorsa, o zaman Çin %99,6 ile en yüksek öncelikli düğüme sahip olacak zamanın. Bu nedenle dilim ağırlığı kavramını tanıtıyoruz; ağırlık(u,v) ∈[0, 1] u düğümünün çekirdek dilimlerinin kesridir v düğümünü içeren. U düğümü yeni bir lider seçerken, yalnızca aşağıdaki şekilde tanımlanan komşuları dikkate alır: komşular(u) = { v | H0(v) < hmax · ağırlık(u,v) } Daha sonra bir düğüm boş bir lider kümesiyle başlar ve her birinde round ona en yüksek değere sahip komşulardaki (u) v düğümünü ekler öncelik(v). Eğer komşular seti herhangi bir turda boşsa, u bunun yerine en düşük H0(v)/ağırlık(u,v) değerine sahip düğümü ekler.
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] 目前 其活性取决于严格较弱的协议 假设只是最终同步和最终领导者选举，而不需要从切片中删除故障节点。
SCP'nin resmi doğrulaması
Tasarım hatalarını ortadan kaldırmak için SCP'nin güvenliğini resmi olarak doğruladık ve canlılık özellikleri (bkz. [65]). Özellikle, doğruladık iç içe geçmiş düğümlerin hiçbir zaman anlaşmazlığa düşmemesi ve aşağıda tartışılan koşullar altında, sağlam bir kümenin her üyesinin eninde sonunda karar vermesi. İlginç bir şekilde, doğrulama şunu ortaya çıkardı: SCP'nin canlılığı garanti ettiği koşullar incelikli, ve başlangıçta düşünülenden daha güçlü [68]: aşağıda tartışıldığı gibi, Aksi halde zamanlamayı değiştiren kötü niyetli düğümler protokolden sapmanın manuel olarak tahliye edilmesi gerekebilir çekirdek dilimlerinden.
SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. Özelliklerin mümkün olan her durumda geçerli olmasını sağlamak için FBA yapılandırmaları ve uygulamalarının keyfi olduğunu düşünüyoruz keyfi yerel konfigürasyonlara sahip düğümlerin sayısı. Bu ayrık bozulmamış kümelerin yanı sıra potansiyel olarak sonsuz uzunlukta yürütmelere sahip senaryoları içerir. Dezavantajımız şu ki Parametrelendirilmiş bir doğrulamanın zorlu sorunuyla karşı karşıya sonsuz durum sistemi. Doğrulamayı izlenebilir kılmak için, Ivy [69] ve [82] metodolojisini kullanarak SCP'yi birinci dereceden mantıkta (FOL) modelledik. Doğrulama süreci, daha sonra otomatik olarak kontrol edilen tümevarımsal varsayımların manuel olarak sağlanmasından oluşur. Sarmaşık. SCP'nin FOL modeli bazı yönleri özetliyor FOL'de yönetimi zor olan FBA sistemleri (örn. kaskad teoremi bir aksiyom olarak alınır), bu nedenle şunu doğrularız: Isabelle/HOL [75] kullanarak soyutlamanın sağlamlığı. Doğrulama problemini FOL'de ifade ettikten sonra, endüktif bir değişmez sağlayarak güvenliği doğruluyoruz. endüktif değişmez yaklaşık olarak bir düzine tek satırlık varsayımdan oluşur 150 satırlık protokol spesifikasyonu. Daha sonra Ivy'nin Doğrusal Zamansal Mantığı'nda SCP'nin canlılık özelliklerini belirliyoruz ve Canlılığı azaltmak için canlılıktan güvenliğe azalma [80, 81] doğrulama probleminden tümevarım bulma problemine değişmez. SCP'nin güvenliği nispeten basit olsa da SCP'nin canlılık argümanının çok daha karmaşık olduğunu kanıtlayın ve yaklaşık 150 tek satırlı değişmezden oluşur. Canlılığın kanıtlanması, kesin bir resmileştirmeyi gerektiriyordu. SCP'nin fesih sağladığı varsayımlar. Başlangıçta bozulmamış bir seti her zaman sonlandıracağımı düşündük. üyeler hatalı düğümleri dilimlerinden kaldırdı [68]. Ancak bunun yetersiz olduğu ortaya çıktı: iyi huylu (ama (sağlam değil) düğümün bir üye yeter sayısı altında, hatalı düğümlerin etkisi, tamamlanarak sonlandırmayı önleyin oylamanın bitiminden hemen önce yeter sayının sağlanması, dolayısıyla I üyeleri bir sonraki oylamada x'in farklı değerlerini seçecek. Bu nedenle ayrıca gayri resmi olarak şunu varsaymalıyız: I üyesinin yeterli çoğunluğundaki her düğüm sonunda zamanında geliyor veya yeterli bir süre boyunca hiç mesaj göndermiyor. Uygulamada bu, I üyelerinin durum devam edene kadar dilimlerini ayarlamaları gerekir. Bu sorun FBA sistemlerine özgü değildir: Losa ve ark. [47] mevcut canlılığı kesinlikle zayıf olana bağlı olan bir protokol hatalı düğümleri dilimlerden çıkarmaya gerek kalmadan, yalnızca nihai senkronizasyon ve nihai lider seçimi varsayımları.
支付网络
本节介绍 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 检查有风险的配置 检测网络是否承认不相交的仲裁是一个步骤 方向正确，但危险信号却迟到了 对于如此关键的问题。理想情况下，我们希望节点操作员在网络集体配置时收到警告 只是接近危险状态。 因此，我们扩展了群体交叉检查器 检测我们称之为关键性的条件：当电流 集体配置是一种错误配置 承认不相交法定人数的国家。为了检测关键性， 检查器反复用模拟的最坏情况错误配置替换每个组织的配置，然后 对结果重新运行内部仲裁交集检查器。 如果存在任何此类严重错误配置，只需一步之遥 从当前状态来看，软件会发出警告并 报告该组织存在配置错误风险。 这些变化为运营商社区提供了两个层次 防范最坏形式的通知和指导 集体错误配置。
Ödeme ağı
Bu bölümde, Stellar'nin, SCP'nin üzerinde kopyalanmış bir durum makinesi [88] olarak uygulanan ödeme ağı açıklanmaktadır. 5.1 Defter modeli Stellar'in defteri, hesap soyutlaması etrafında tasarlanmıştır (içinde daha çok madeni para merkezli harcanmamış işlem çıktısının aksine veya UTXO modelinin Bitcoin modeli). Defterin içeriği şunlardan oluşur: Dört farklı türden defter girişleri kümesi: hesaplar, güven hatları, teklifler ve hesap verileri. Hesaplar, varlıkların sahibi olan ve ihraç eden müdürlerdir. Her biri hesap genel anahtarla adlandırılır. Varsayılan olarak karşılık gelen özel anahtar, hesap için işlemleri imzalayabilir. Ancak hesaplar, başka imzalayanlar eklemek ve hesabı adlandıran anahtarın yetkisini kaldırmak için yeniden yapılandırılabilir. Birden fazla imzalayanın kullanılmasını gerektiren "multisig" seçeneği. Her hesap ayrıca şunları içerir: bir sıra numarası (işlemlere dahil edilir) tekrarı önlemek için), bazı bayraklar ve “yerel” bir denge hafifletmeyi amaçlayan, XLM adı verilen önceden çıkarılmış kripto para birimi bazı hizmet reddi saldırıları ve pazar oluşumunu kolaylaştırma nötr bir para birimi olarak. Trustlines, ihraç edilen varlıkların sahipliğini takip eder. veren hesap ve kısa bir hesaptan oluşan bir çift tarafından adlandırılır. varlık kodu (ör. "USD" veya "EUR"). Her güven hattı şunları belirtir: bir hesap, bir varlık, hesabın o varlıktaki bakiyesi, bir dengenin üzerine çıkamayacağı limit ve bazı bayraklar. Bir hesap, bir varlığın elde tutulmasına açıkça izin vermelidir: Spam gönderenlerin engellenmesini önleyen bir güven hattı oluşturmak İstenmeyen varlıklara sahip hesaplar. Müşterinizi Tanıyın (KYC) düzenlemeleri, birçok finans kuruluşunun kimin mevduatını tuttuğunu bilmesini gerektirir. örneğin fotoğraflı kimliği kontrol ederek. Uyumluluk için, ihraççılar ayarlayabilir Hesaplarında isteğe bağlı bir auth_reqired bayrağı yer alıyor ve verdikleri varlıkların sahipliğini yetkili hesaplarla sınırlıyorlar. Bu yetkiyi vermek için ihraççı, yetkili bir Müşterilerin güven hatlarını işaretleyin. Teklifler bir hesabın takas yapma isteğine karşılık gelir Belirli bir varlık için belirli bir miktardaki bir başka varlığa belirli bir zamanda sipariş defterindeki fiyat; otomatik olarak eşleştirilirler ve alış/satış fiyatları kesiştiğinde doldurulur. Son olarak hesap verileri hesap, anahtar, değer üçlülerinden oluşur ve hesap sahiplerine izin verir. küçük meta veri değerlerini yayınlamak için. Defter spam'ını önlemek için minimum XLM bakiyesi vardır, rezerv denir. Bir hesabın rezervi her biri ile artar ilgili defter girişi ve defter girişi yapıldığında azalır kaybolur (örn. bir sipariş yerine getirildiğinde veya iptal edildiğinde ya da güven hattı silinir). Şu anda rezerv 0,5 XLM artıyor (∼$0,03) defter girişi başına. Rezerv ne olursa olsun, silerek bir hesabın tüm değerini geri almak mümkün Bunu bir AccountMerge işlemiyle yapın. Şekil 3'te gösterilen genel muhasebe başlığı genel nitelikleri saklar: bir defter numarası, rezerv bakiyesi gibi parametreler defter girişi, önceki defter başlığının hash'si (aslında birkaç hashes bir atlama listesi oluşturur), SCP çıktısı şunları içerir: bu deftere hash yeni işlem uygulandı, hash bu işlemlerin sonuçları (örneğin, başarı veya başarısızlık) her biri) ve tüm genel muhasebe girişlerinin anlık görüntüsü hash. hash anlık görüntüsü tüm defter içeriğini içerdiğinden, validators'nin işlemleri doğrulamak için geçmişi saklamasına gerek yoktur. Ancak yüz milyonlarca beklenen sayıya ölçeklendirmek için hesaplarda, her hesapta tüm genel muhasebe giriş tablolarını yenidenhash yeniden yapamıyoruz. defter yakın. Ayrıca defter aktarımı pratik değildir.Stellar ile hızlı ve güvenli global ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada defter numarası = 4 H(önceki hdr) SCP çıkışı H∗(sonuçlar) H∗(anlık görüntü) ... başlık defter numarası = 5 H(önceki hdr) SCP çıkışı H∗(sonuçlar) H∗(anlık görüntü) ... başlık . . . Şekil 3. Defter içeriği. H, SHA-256'dir; H ∗, H.SCP çıktısının hiyerarşik veya özyinelemeli uygulamasını temsil eder aynı zamanda önceki başlığa da bağlıdır hash. Hesap Oluştur Yeni hesap defteri girişi oluşturun ve finanse edin HesapBirleştirme Hesap defteri girişini sil Seçenekleri Ayarla Hesap işaretlerini ve imzalayanları değiştirme Ödeme Hedefe belirli miktarda varlık ödeyin. kanun. YolÖdeme Ödemeyi beğenin, ancak farklı bir varlıkla ödeme yapın (yukarı sınırlamak için); 5'e kadar aracı varlık belirtin Teklifi Yönet Teklif defteri girişi oluşturma/silme/değiştirme, -PasifTeklif sıfır yayılmaya izin veren pasif değişkenli Verileri Yönet Hesap oluştur/sil/değiştir. veri defteri girişi Güveni Değiştir Güven hattı oluştur/sil/değiştir İzin VerGüven Güven hattında yetkili bayrağını ayarlayın veya temizleyin Çarpma Sırası Sırayı artırın hesaptaki numara Şekil 4. Ana defter işlemleri bir düğümün bağlantısı her kesildiğinde bu boyutta ağ çok uzun süredir. Bu nedenle anlık görüntü hash hem hashing hem de durum uzlaşmasını optimize etmek için tasarlanmıştır. Özellikle, anlık görüntü genel muhasebe girişlerini zamana göre katmanlandırır üstel boyutlu kaplar kümesindeki son değişiklik kovalar denir. Kovaların toplanmasına kova denir listesidir ve log yapılı birleştirme ağaçlarıyla bazı benzerlikler taşır (LSM ağaçları) [77]. Yapılacaklar listesi işlem gerçekleştirilirken okunmaz (bkz. Bölüm 5.4). Bu nedenle belirli bir tasarım LSM ağaçlarının bazı yönleri gevşetilebilir. Özellikle rastgele anahtarla erişim gerekli değildir ve paketler yalnızca okunur seviyelerin birleştirilmesinin parçası olarak sırayla. Kovayı karıştırmak liste, birleştirilirken her bir paket hash'ye tabi tutularak ve hashes paketinin (küçük, her defter kapanışında sabit referans indeksi hashes). Bağlantı kesildikten sonra yapılacaklar listesinin uzlaştırılması, indirmeyi gerektirir yalnızca kovalar farklıdır. 5.2 İşlem modeli Bir işlem kaynak hesaptan, geçerlilik kriterlerinden ve not ve bir veya daha fazla işlemin listesi. Şekil 4'te mevcut işlemler listelenmektedir. Her işlemin bir kaynak hesabı vardır. varsayılan olarak genel işlemin varsayılanıdır. Bir işlem yapılmalı içindeki her kaynak hesaba karşılık gelen anahtarlar tarafından imzalanacaktır. bir operasyon. Çoklu imzalı hesaplar daha yüksek imza gerektirebilir bazı işlemler için ağırlık (SetOptions gibi) ve daha düşük diğerleri için (AllowTrust gibi). İşlemler atomiktir; herhangi bir işlem başarısız olursa hiçbiri idam ederler. Bu, çok yönlü anlaşmaları basitleştirir. varsayalım ki ihraççı, arazi tapularını temsil edecek bir varlık oluşturur ve A kullanıcısı Küçük bir arazi parselini artı 10.000 $'la takas etmek istiyor B'ye ait olan daha büyük arazi parseli. İki kullanıcı da imza atabilir üç işlemi içeren tek bir işlem: iki arazi ödemeler ve bir dolar ödeme. Bir işlemin ana geçerlilik kriteri, işlemin sıra numarasından bir büyük olması gereken sıra numarasıdır. kaynak hesap defteri girişi. Geçerli bir işlemin yürütülmesi (başarılı olsun ya da olmasın) sıra numarasını artırarak tekrar oynatmayı engeller. İlk sıra numaraları defteri içerir Sildikten sonra bile tekrar oynatmayı önlemek için yüksek bitlerdeki sayı ve bir hesabı yeniden oluşturma. Diğer geçerlilik kriteri ise ne zaman yapılacağına ilişkin isteğe bağlı bir sınırdır. bir işlem yürütülebilir. Toprağa ve dolara dönüş yukarıdaki takas, eğer A işlemi B'den önce imzalarsa, A bunu yapmayabilir B'nin göndermeden önce bir yıl boyunca işlemde kalmasını istiyor ve böylece işlemi geçersiz kılan bir zaman sınırı koyabilir birkaç gün sonra. Multisig hesapları da yapılandırılabilir hash ön görüntünün ortaya çıkmasına imza ağırlığı vermek, bu, zaman sınırlarıyla birlikte atomik çapraz zincir ticaretine izin verir [1]. Bir işlemin kaynak hesabı XLM'de önemsiz bir ücret öder, Tıkanıklık olmadığı sürece 10−5 XLM. Sıkışıklık altında, Operasyonların maliyeti Hollanda açık artırmasıyla belirlenir. Doğrulayıcılar validator'lar benzer olduğundan ücretlerle karşılanmıyor madencilere değil, Bitcoin tam düğümlere. XLM'yi yok etmek yerine, ücretler geri dönüştürülür ve oylamayla orantılı olarak dağıtılır geçmişe bakıldığında mevcut XLM sahipleri karmaşıklığa değmedi. 5.3 Konsensüs değerleri Her defter için Stellar, bir veri yapısı üzerinde anlaşmak amacıyla SCP'yi kullanır üç alanlı: hash işlem kümesi (hash dahil) önceki genel muhasebe başlığının), yakın bir zaman, bird yükseltmeleri. Birden fazla değerin aday gösterildiği onaylandığında, Stellar alınır en fazla işlemi içeren işlem seti (bağları koparmak) toplam ücretlere göre, ardından işlem seti hash), hepsinin birleşimi yükseltmeler ve en yüksek kapanış süresi. Yakın bir zaman sadece son defterin kapanış zamanı ile son defterin kapanış zamanı arasında ise geçerlidir. mevcut olduğundan düğümler geçersiz süreleri belirtmez. Yükseltmeler, rezerv bakiyesi, minimum işletim ücreti ve protokol sürümü gibi genel parametreleri ayarlar. Ne zaman aday gösterme sırasında bir araya getirildiğinde, yüksek ücretler ve protokol sürüm numaraları düşük olanların yerini alır. Yükseltmeler, federal oylama mücadele alanı [34] aracılığıyla yönetimi etkiler; ikisi de eşitlikçi ve merkezi değil. Her validator şu şekilde yapılandırılmıştır: göre, yöneten ya da olmayan (varsayılan), operatörünün yönetişime katılmak isteyip istemediğine bağlıdır. validator'leri yönetenler üç tür yükseltmeyi dikkate alır: istenen, geçerli ve geçersiz (validator'nin yapmadığı herhangi bir şey)
SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. validator çekirdek ufuk FS Veritabanı Veritabanı gönder müşteri müşteri diğer validators Şekil 5. Stellar validator mimarisi nasıl uygulanacağını biliyorum). İstenilen yükseltmeler şu şekilde yapılandırılmıştır: arasında koordine edilmesi amaçlanan, belirli bir zamanda tetiklenmesi operatörler. Yönetici düğümler her zaman istenen adaya oy verir yükseltmeleri kabul edin ancak geçerli yükseltmeleri aday göstermek için oy vermeyin (yani, engelleme yeter çoğunluğuna uyun) ve asla oy vermeyin. veya geçersiz yükseltmeleri kabul edin. Yönetim dışı validators echo geçerli bir yükseltme için gördükleri herhangi bir oy, esasen yetki devri tercih edenler için hangi yükseltmelerin istendiğine ilişkin karar bir yönetim rolü için. 5.4 Uygulama Şekil 5, Stellar'nin validator mimarisini göstermektedir. Bir şeytan Stellar-core olarak adlandırılan (∼92k C++ satırı, üçüncü taraf kitaplıkları sayılmaz) SCP protokolünü ve çoğaltılmış durum makinesini uygular. SCP için değer üretmek, çok sayıdaki defter girişini küçük kriptografik girişlere azaltmayı gerektirir hashes. Buna karşılık, işlem doğrulama ve yürütme hesap durumuna ve sipariş eşleşmesine bakmayı gerektirir en iyi fiyat. Her iki işlevi de verimli bir şekilde yerine getirmek için yıldız çekirdeği Defterin iki temsilini tutar: ikili dosyalar olarak saklanan, yapılacaklar listesini içeren harici bir temsil. verimli bir şekilde güncellenebilir ve artımlı olarak yeniden hashed edilebilir ve SQL veritabanındaki dahili bir temsil (PostgreSQL üretim düğümleri için). Stellar-core, aşağıdakileri içeren salt okunur bir geçmiş arşivi oluşturur: onaylanan her işlem seti ve bunların anlık görüntüleri kovalar. Arşiv, yeni düğümlerin kendilerini önyüklemesine olanak tanıyor ağa katıldığınızda. Aynı zamanda bir defter kaydı sağlar tarih—birinin arayabileceği bir yer olması gerekiyor iki yıl önceki işlem. Geçmiş yalnızca ekleme amaçlı olduğundan ve nadiren erişildiği için ucuz yerlerde saklanabilir Amazon Glacier veya depolamaya izin veren herhangi bir hizmet gibi ve düz dosyaları alın. Doğrulayıcı ana bilgisayarlar genellikle barındırmaz Doğrulama üzerinde herhangi bir etkiyi önlemek için kendi arşivleri Hizmet geçmişinden performans. Yıldız çekirdeğini basit tutmak için kullanılması amaçlanmamıştır. doğrudan uygulamalar tarafından sağlanır ve yeni işlemlerin sunulması için yalnızca çok dar bir arayüz sunar. Desteklemek istemcilerde, çoğu validator, Horizon adı verilen bir arka plan programı çalıştırır (∼18k gönderme için bir HTTP arayüzü sağlayan Go satırları) ve işlemlerin öğrenilmesi. Horizon'un salt okunur erişimi var Stellar-core'un SQL veritabanı, ufuk riskini en aza indiriyor yıldız çekirdeğinin istikrarını bozuyor. Ödeme yolu bulma gibi özellikler tamamen ufukta uygulanır ve yükseltilebilir diğer validator'larla koordinasyon olmadan tek taraflı olarak. Birkaç isteğe bağlı üst düzey arka plan programı, ekosistemi tamamlayan, ufuktaki istemcilerdir. Bir köprü sunucusu kolaylaştırır Stellar'nin mevcut sistemlerle entegrasyonu; örneğin, belirli bir hesap tarafından alınan tüm ödemelerin bildirimlerinin yayınlanması. bir uyumluluk sunucusu finansal kurumların Gönderen ve yararlanıcı bilgilerinin değişimi ve onaylanması ödemeler konusunda, yaptırım listelerine uyum için. Son olarak, bir federasyon sunucusu insan tarafından okunabilen bir adlandırma uygular hesaplar için sistem. 6 Dağıtım deneyimi Stellar birkaç yıl boyunca ılımlı bir eyalet haline geldi makul derecede güvenilir tam düğüm operatörlerinin sayısı. Ancak, düğümlerin konfigürasyonları canlılık sağlayacak şekildeydi (ancak güvenliği) bize, yani Stellar Kalkınma Vakfı'na bağlıydı (SDF); SDF aniden ortadan kaybolsaydı, diğer düğüm operatörleri müdahale etmesi ve bizi manuel olarak kaldırması gerekirdi ağın devam etmesi için çekirdek dilimlerinden. Biz ve pek çok kişi SDG'nin sistemik önemini azaltmak istesek de, bu hedef daha sonra artan bir öncelik kazandı. araştırmacılar [58] güvenlik risklerini ayırt etmeden ağın merkezileşmesini ölçtü ve duyurdu. canlılık. Bazı operatörler aktif konfigürasyon ayarlamaları yaparak tepki gösterdiler ve öncelikle kendi SDF'nin önemini azaltmak amacıyla çoğunluk dilimleri; ironik bir şekilde bu yalnızca canlılık riskini artırdı. İki sorun durumu daha da kötüleştirdi. İlk olarak popüler bir üçüncü taraf Stellar izleme aracı [5] sistematik olarak doğrulama yapmayarak validator çalışma süresini olduğundan fazla tahmin ediyorsunuz o yıldız çekirdeği çalışıyordu; bu insanları dahil etmeye yönlendirir çekirdek dilimlerindeki güvenilmez düğümler. İkincisi, bir hata yıldız çekirdeği, validator bir sonraki deftere taşındığında anlamına gelir, kalan düğümlerin önceki işlemi tamamlamasına yeterince yardımcı olmadıMesajların kaybolması durumunda büyük defter. Sonuç olarak, ağda 67 dakikalık kesinti yaşandı ve gerekli yeniden başlatmak için validator yöneticiler tarafından manuel koordinasyon. Daha da kötüsü, ağı yeniden başlatmaya çalışırken, birden çok düğümde eş zamanlı ve aceleyle yapılan yeniden yapılandırmalar ortaya çıktı bazı düğümlerin çalışmasına izin veren toplu bir yanlış yapılandırmada bu düğümlerin manuel olarak kapatılmasını gerektiren ve Farklılaşma sırasında kabul edilen işlemlerin yeniden sunulması. Neyse ki bu farklılık fark edildi ve düzeltildi hızlı bir şekilde ve birbiriyle çelişen işlemler içermedi, ancak ağın çekirdek kesişiminden yararlanamama riski— potansiyel olarak çelişkili olanı kabul etmeye devam ederken bölünme yanlış yapılandırma nedeniyle yapılan işlemler bu olay çok somut. Bu deneyimleri gözden geçirmek iki önemli sonuca yol açtı ve ilgili düzeltici eylemler.Stellar ile hızlı ve güvenli küresel ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Kritik, %100 %51 %51 Yüksek, %67 %51 Orta, %67 %51 Düşük, %67 %51 %51 ... ... ... %51 ... %51 Şekil 6. Doğrulayıcı kalite hiyerarşisi. En yüksek kalitede düğümler %100'lük en yüksek eşiği gerektirirken, daha düşük kaliteler %67 eşiğine göre yapılandırılmıştır. Tek bir düğüm içindeki düğümler organizasyon için %51'lik basit bir çoğunluk gerekiyor. 6.1 Yapılandırma karmaşıklığı ve kırılganlığı Stellar çekirdek dilimlerini, n giriş ve k eşiğinden oluşan iç içe çekirdek kümeleri olarak ifade eder; burada herhangi bir k giriş kümesi vardır yetersayı dilimi oluşturur. O zaman n girişin her biri ya bir validator genel anahtarı veya yinelemeli olarak başka bir çekirdek kümesi. Esnek ve kompakt olmasına rağmen iç içe geçmiş bir çoğunluk elde ettik kümeler aynı anda düğüm operatörlerine çok fazla esneklik ve çok az rehberlik sağlıyordu: güvenli olmayan (veya hatta saçma) konfigürasyonlar. Gruplandırma kriterleri alt kümeleri bir hiyerarşi halinde düzenlemek için düğümleri kümeler halinde ve Eşiklerin seçimine ilişkin hususların tümü yeterince açık değildi ve operasyonel başarısızlıklara katkıda bulundu. yapılıp yapılmayacağı belli değildi İç içe geçmiş hiyerarşideki bir "düzeyi" güven düzeyi olarak ele alın, veya bir kuruluş veya her ikisi; sahada birçok konfigürasyon Tehlikeli olanı belirtmenin yanı sıra bu kavramları karıştırdı veya anlamsız eşikler. Bu nedenle daha basit bir yapılandırma mekanizması ekledik iç içe çekirdek kümelerinin iki yönünü ayıran şey: gruplama düğümlerin kuruluşa göre bir araya getirilmesi ve her kuruluşun basit bir güven sınıflandırmasıyla (düşük, orta, yüksek veya kritik). Üst düzey ve üzeri kuruluşların şunları yapması gerekir: tarih arşivlerini yayınlayın. Yeni sistem, her organizasyonun bir grup olarak temsil edildiği iç içe çekirdek kümelerini sentezler. %51 eşik belirlendi ve kuruluşlar gruplar halinde gruplandırıldı %67 veya %100 eşik değerleri ile (grup kalitesine bağlı olarak). Her grup bir sonraki (daha yüksek kalitede) grupta tek bir giriştir, Şekil 6'da gösterildiği gibi. Bu basitleştirilmiş model, hem yapı açısından yanlış yapılandırma olasılığı Sentezlenen iç içe geçmiş kümelerin ve seçilen eşiklerin her set. 6.2 Yanlış yapılandırmanın proaktif tespiti İkincisi, toplu yanlış yapılandırmanın olumsuz etkilerini gözlemlemeyi bekleyerek tespit etmenin çok geç olduğunu fark ettik. Özellikle farklılık gösterebilecek yanlış yapılandırmalarla ilgili olarak durmaktan daha ciddi bir arıza modu; ağın ihtiyacı var Yanlış yapılandırmayı anında tespit edebilmek, böylece operatörlerin herhangi bir sapma meydana gelmeden önce bunu geri döndürebilmesini sağlamak. Bu ihtiyacı karşılamak için validator yazılımına, düğümün geçişli kapanışındaki tüm eşlerin kolektif konfigürasyon durumunu sürekli olarak toplayan ve sapma potansiyelini (yani ayrıklığı) tespit eden bir mekanizma oluşturduk. yetersayılar - bu kolektif konfigürasyon dahilinde. 6.2.1 Çekirdek kesişimi kontrol ediliyor Çekirdek dilimlerini toplamak kolay olsa da, aralarında ayrık çekirdekleri bulmak eş-NP-zordur [62]. Ancak biz benimsedik bir dizi algoritmik buluşsal yöntem ve vaka eleme kuralları Tipik örnekleri kontrol eden Lachowski [62] tarafından önerildi Sorunun birkaç kat daha hızlı çözülmesi en kötü durum maliyeti. Pratik olarak konuşursak, mevcut ağ çekirdek dilimi geçişli kapanışları 20-30 düzeyindedir düğümleri ve Lachowski'nin optimizasyonlarıyla genellikle kontrol edin tek bir CPU'da birkaç saniye içinde. İhtiyaç ortaya çıkarsa Performansı artırmak için aramayı paralel hale getirebiliriz. 6.2.2 Riskli konfigürasyonların kontrol edilmesi Ağın ayrık yeter çoğunlukları kabul ettiğini tespit etmek bir adımdır doğru yönde, ancak tehlikeyi rahatsız edici derecede geç işaretliyor Böyle kritik bir konu için. İdeal olarak, ağın toplu yapılandırması sırasında düğüm operatörlerinin uyarı almasını isteriz. sadece riskli bir duruma yaklaşıyor. Bu nedenle çekirdek-kesişme denetleyicisini genişlettik kritiklik dediğimiz bir durumu tespit etmek için: mevcut durum kolektif yapılandırma, bir yanlış yapılandırmadan uzaktadır ayrık yeter çoğunlukları kabul eden bir eyalet. Kritikliği tespit etmek için, denetleyici sürekli olarak her kuruluşun yapılandırmasını simüle edilmiş en kötü durum yanlış yapılandırmasıyla değiştirir ve ardından sonuç üzerinde iç çekirdek kesişim denetleyicisini yeniden çalıştırır. Böyle kritik bir yanlış yapılandırmanın bir adım ötede olması durumunda mevcut durumdan itibaren yazılım bir uyarı verir ve Kuruluşun yanlış yapılandırma riski oluşturduğunu bildirir. Bu değişiklikler operatör topluluğuna iki katman kazandırıyor en kötü biçimlere karşı izolasyon sağlamak için bildirim ve rehberlik kolektif yanlış yapılandırma.
评估
了解 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]。此外，数据库密集型 可以通过标准批处理和预取技术来缩短账本更新时间。
Değerlendirme
Stellar'nin küresel ödeme olarak uygunluğunu anlamak ve ticaret ağı, genel ağın durumunu değerlendirdik ve özel bir deneyde kontrollü deneyler yürüttük ağ. Aşağıdaki sorulara odaklandık: • Üretim ağı topolojisi neye benziyor? Ortalama kaç mesaj yayınlanıyor ve SCP zaman aşımlarını nasıl yaşıyor? • Konsensüs ve defter güncelleme gecikmeleri hesap sayısından bağımsız mı kalıyor?SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. • (a) Saniye başına işlemlerin (ve dolayısıyla saniye başına işlemlerin) artmasından gecikmeler nasıl etkilenir? defter) ve (b) validator düğümlerin sayısı? • Bir düğümü çalıştırmanın CPU açısından maliyeti nedir, bellek ve ağ bant genişliği? Ödeme ağları karşılaştırıldığında düşük işlem oranlarına sahiptir diğer dağıtılmış sistem türlerine. Önde gelen blockchain'ler, Bitcoin ve Ethereum, saniyede 15 işleme kadar onaylayın, Stellar'den az. Üstelik bu sistemlerin çalışması dakikalar sürüyor. Bir işlemin güvenli bir şekilde onaylanması bir saat sürer, çünkü iş kanıtı birkaç bloğun çıkarılmasını beklemeyi gerektirir. blockchain olmayan SWIFT ağı, en yoğun olduğu gün olan [14]'de saniyede yalnızca 420 işlem gerçekleştirdi. Bu nedenle seçtik ölçümlerimizi 5 saniyelik hedefle karşılaştırmak için defter aralığı, daha agresif bir hedef. Sonuçlarımız gösteriyor gecikmelerin rahatlıkla bu sınırın altında olduğu hala geliştirilme aşamasında olan birkaç uygulanmamış optimizasyon. 7.1 Çapalar Hacim bazında en çok işlem gören varlıklar arasında para birimi de yer alıyor (ör. 3 USD) çapa, 2 CNY), bir Bitcoin çapa, gayrimenkul destekli bir menkul kıymet token [92] ve uygulama içi para birimi [8]. Farklı çapaların farklı politikaları vardır. Örneğin, bir USD çapası, Stronghold, auth_reqired'i ayarlar ve müşterilerini tanıyan her hesap için müşterini tanı (KYC) süreci gerektirir. varlıklar. Bir diğeri, AnchorUSD, herkesin alıp ticaret yapmasına izin verin USD'leri (Meksika'ya 0,50 $ göndermeyi tam anlamıyla mümkün kılıyor) 0,000001 ABD Doları ücretle 5 saniye içinde). Ancak AnchorUSD USD'lerini satın almak veya kullanmak için KYC ve ücret gerektirir geleneksel banka havaleleriyle. Filipinler'de, nerede banka düzenlemeleri gelen ödemeler konusunda daha gevşektir, coin.ph PHP'nin herhangi bir ATM makinesinden [36] paraya çevrilmesini destekler. Yukarıda bahsedilen güvenlik token ve uygulama içi para birimine ek olarak, para birimi olmayan tokens aralığı da vardır: ticari tahviller [22] ve karbon kredileri [85, 96] daha fazlasına token gibi ortak çalışmayı teşvik eden ezoterik varlıklar arabanın yeniden ele geçirilmesi [35]. 7.2 Genel ağ Bu yazının yazıldığı an itibariyle 126 aktif tam düğüm mevcut olup bunların 66'sı oylama mesajlarını imzalayarak fikir birliğine katılın. Şekil 7 ([5] tarafından oluşturulmuştur) ağı aralarında bir çizgiyle görselleştirir biri diğerinin çekirdek dilimlerinde görünüyorsa iki düğüm ve iki yönlü bağımlılığı göstermek için daha koyu mavi çizgi. Şunda merkez, tarafından yönetilen 17 fiili "birinci kademe validators"den oluşan bir kümedir. SDF, SatoshiPay, LOBSTR, COINQVEST ve Keybase. Dört ay önce, Bölüm 6'daki olaylardan önce, orada 15 sistemik olarak önemli düğüm vardı: 3'ü görünüşte birinci kademe organizasyonlar ve birkaç rastgele singleton. grafik de çok daha az düzenli görünüyordu. Dolayısıyla yeni konfigürasyon mekanizması ve/veya daha iyi operatör kararları görünmektedir. daha sağlıklı bir ağ topolojisine katkıda bulunmak. olmadan büyük mali kaynaklar (ve ilgili hissedarlar) Şekil 7. Çekirdek dilim haritası yükümlülükler), 5. kademeyi işe almak zor olurdu Ancak başlangıçtan itibaren organizasyonlar. Bu yeter sayıyı öneriyor dilimler ağ önyüklemesinde yararlı bir rol oynar: herkes yapabilir önemli bir oyuncu olma hedefiyle katılın çünkü ikili anlaşmanın bekçileri yoktur. Şu anda defterde 3,3 milyondan fazla hesap var. bitti son 24 saatlik dönemde Stellar ortalama 4,5 işlem gerçekleştirdi ve Saniyede 15,7 işlem. Son defterlerin incelenmesi, çoğu işlemlerin tek bir işlemi varmış gibi görünürken, her birkaç Defterlerde birçok işlemi içeren işlemleri görüyoruz teklifleri yöneten piyasa yapıcılardan geliyor gibi görünüyor. Fikir birliğine varmak ve defteri güncellemek için ortalama süreler Sırasıyla 1061 ms ve 46 ms. 99. yüzdelik dilimler şunlardı: 2252 ms ve 142 ms (ilki 1 saniyelik zaman aşımını yansıtıyor) adaylık lideri seçiminde). SCP'nin performansının şu şekilde olduğunu unutmayın: SCP'den beri çoğunlukla saniyedeki işlemlerden bağımsızdır keyfi olarak birçok işlemden oluşan hash üzerinde anlaşır. Adayın propagandası nedeniyle darboğazların ortaya çıkma olasılığı daha yüksektir Aday gösterme, yürütme ve doğrulama sırasındaki işlemler işlemler ve paketlerin birleştirilmesi. Henüz ihtiyacımız olmadı Stellar-core'un işlem işlemlerini birden fazla CPU çekirdeği veya disk sürücüsü üzerinden paralelleştirmek için. Ayrıca yayınlanan SCP mesajlarının sayısını da değerlendirdik üretim ağında. Normal durumda tek Bir değeri aday göstermek için seçilen liderden yedi mantıksal değer bekliyoruz yayınlanacak mesajlar: oylanacak ve kabul edilecek iki mesaj bir isimnate beyanı, kabul edilecek ve onaylanacak iki mesaj bir hazırlık ifadesi, kabul etmek ve onaylamak için iki mesaj bir taahhüt beyanı ve son olarak bir dışsallaştırma mesajı (başıboş kalanlara yardım etmek için diske yeni bir defter işlendikten sonra gönderilir) yetişin). Uygulama onaylama taahhüdünü birleştirir ve mesajları bir optimizasyon olarak dışsallaştırın, çünkü Bir değeri taahhüt edildikten sonra dışsallaştırmak güvenlidir. Daha sonra Stellar validator numaralı üretimde toplanan metrikleri analiz ederiz. bitti 68 saat boyunca saniyede 1,3 mesaj gönderildi, Defter başına ortalama 6-7 mesaj. Toplamın olduğunu not ediyoruz
Stellar ile hızlı ve güvenli küresel ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Yüzdelik dilim Zaman Aşımı Sayısı Adaylık oylama %75 0 0 %99 1 0 Maksimum 4 1 Şekil 8. Defter başına 68 saatten fazla zaman aşımı validators tarafından yayınlanan mesajların sayısı daha fazla, çünkü Birleşik oylama mesajlarına ek olarak düğümler aynı zamanda yayın da yapar öğrendikleri herhangi bir işlem. Şekil 8, bir üretimin yaşadığı zaman aşımlarını göstermektedir validator 68 saatlik bir süre boyunca. Adaylık zaman aşımları oylama zaman aşımları büyük ölçüde ağa bağlıyken, lider seçim fonksiyonunun etkili(olmayan)etkinliğinin bir ölçüsü ve potansiyel mesaj gecikmeleri. Zaman aşımları tutarlı gönderilen mesaj sayısıyla birlikte: altı mesaj en iyi senaryo ve ek bir adaylık turu gerekiyorsa en az yedi mesaj. 7.3 Kontrollü deneyler Ambalajlı kaplarda kontrollü deneyler yaptık. 72 GiB RAM'e sahip Amazon EC2 c5d.9xlarge bulut sunucuları, 900 GB NVMe SSD ve 36 vCPU. Her örnek şu şekildeydi: aynı EC2 bölgesi ve 10 Gbps sabit bant genişliğine sahipti. SQLite'ı mağaza olarak kullandık. (Stellar ayrıca PostgreSQL'i de destekler, ancak ölçümlere gürültü katan eş zamanlı olmayan görevleri vardır.) Stellar yerleşik bir çalışma zamanı sorgusu sağlar, createdload, belirli bir hedefte sentetik yük oluşturulmasına olanak sağlayan işlem/ikinci oran. Stellar çeşitli destekleri olsa da Sipariş defteri ve çapraz varlık yolu gibi ticaret özellikleri ödemelerde basit ödemelere odaklandık. İşlemlerin onaylanması birden fazla adımdan oluşur, bu nedenle aşağıdakilerin her biri için ölçümleri kaydetti: • Aday gösterme: aday gösterilme anından ilk hazırlığa kadar geçen süre • Oylama: ilk hazırlıktan bir oylamanın onaylanmasına kadar geçen süre oy pusulası işlendi • Defter güncellemesi: fikir birliği değerini uygulama zamanı • İşlem sayısı: defter başına onaylanmış işlemler Deneylerimizin her biri üç parametreyle tanımlandı: Defterdeki hesap girişlerinin sayısı, tutarı Saniyede gönderilen yük (XLM ödemeleri şeklinde), ve validators sayısı. Her validator'yı yapılandırdık diğer validator hakkında bilgi sahibi olmak (en kötü senaryo) SCP için), çekirdek dilimleri herhangi bir basit çoğunluğa ayarlanmış olarak düğümler (farklı yetersayıların sayısını en üst düzeye çıkarmak için). Temel Temel denememiz Stellar ile ölçüldü 100.000 hesap, dört validator ve yük oluşturma 100 işlem/saniye hızı. Defter başına ortalama 507 işlem gözlemledik, standart sapma 49 (%9,7). Hiçbir işlemin iptal edilmediğini unutmayın; hafif 105 106 107 0 500 1.000 1.500 2.000 Hesaplar Gecikme [ms] Defter güncellemesi oylama Adaylık Şekil 9. Hesap sayısı arttıkça gecikme varyans, yük oluşturucunun planlama sınırlamalarından kaynaklanmaktadır. Defter başına işlem sayısının arttığını gözlemledik. defter göz önüne alındığında, yük oluşturma oranımızla tutarlıydı Her 5 saniyede bir kapanıyor. Aday gösterme, oylama ve defter güncelleme ortalama 82,53 ms, 95,96 ms gecikme süresi gösterdi ve Sırasıyla 174,08 ms. Aday gösterme gecikmesini gözlemledik 99. yüzdelik dilim sürekli olarak 61 ms'nin altındadır, ara sıra İlk adıma karşılık gelen yaklaşık 1 saniyelik ani artışlar lider seçiminin zaman aşımı fonksiyonunda. Temel performans göz önüne alındığında, etkilere baktık test kurulum parametrelerinin her birini değiştirme. Hesaplar Şekil 9'daki veriler Stellar'nin ölçeklendiğini göstermektedir hesap sayısı da artıyor. Testin oluşturulması hesaplar, paket oluşturma ve birleştirme veritabanını basitçe doldurmamızı engelledi hesaplarla doğrudan SQL üzerinden. Bu nedenle çalışmalarımızı gerçekleştirdik. 50.000.000'e kadar hesap için denemeler. varken Konsensüs ve defter güncelleme gecikmeleri üzerinde minimum etki, Artan hesapların bir ek yük yarattığını not ediyoruz giderek büyüyen kovaları birleştiriyor. İşlem oranı İşlem oranı tutarı etkiler validators arasındaki trafik çoklu yayını, her bir defterde yer alan işlem sayısı ve üst düzeyin boyutu kovalar. Artan işlemlerin etkilerini anlamak yüklendiğinde, 100.000 hesap ve 4 validators ile bir deneme yaptık. Şekil 10, fikir birliği gecikmesindeki yavaş büyümeyi göstermektedir, zamanın büyük bir kısmı defteri güncellemekle geçiyordu. İşlem kümesinin boyutu arttıkça şaşırtıcı olmayan bir şekilde veritabanına kaydedilmesi daha uzun sürer. Ayrıca şunu da not ediyoruz Defter güncelleme gecikmesi büyük ölçüde uygulamaya bağlıdır, ve veritabanı seçiminden etkilenir. Doğrulayıcı düğümler validators katman sayısının nasıl arttığını görmek içinperformansı etkiliyor, deneyler yaptık 100.000 hesap, 100 işlem/saniye ve 4 ile 43 arasında değişen sayıda validator ile. Tüm validator'ler göründü validators'nin tüm çekirdek dilimlerinde; daha küçük çoğunluk dilimleri performans üzerinde daha az etkiye sahiptir.SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. 100 150 200 250 300 350 0 500 1.000 1.500 2.000 Yükle [işlem/saniye] Gecikme [ms] Defter güncellemesi oylama Adaylık Şekil 10. İşlem yükü arttıkça gecikme 10 20 30 40 0 500 1.000 1.500 2.000 Doğrulayıcılar Gecikme [ms] Defter güncellemesi oylama Adaylık Şekil 11. Düğüm sayısı arttıkça gecikme Ağdaki doğrulayan düğümlerin sayısını değiştirme değiştirilen SCP mesajlarının sayısını ve ayrıca Aday gösterme sırasındaki potansiyel değerlerin sayısı. Şekil 11 adaylık süresinin nispeten küçük bir oranda arttığını gösteriyor. Veriler oylamanın bir darboğaz olduğunu öne sürse de, biz ölçeklendirme sorunlarının çoğunun iyileştirilerek çözülebileceğine inanıyorum Ağ trafiğini optimize etmek için Stellar'nin yer paylaşımlı ağı. olarak beklenen, defter güncelleme gecikmesi bağımsız kaldı düğüm sayısı. Kapanış oranı Son olarak, Stellar'nin uçtan uca performansını, defterlerin ne sıklıkta onaylandığını ve Stellar'nin 5 saniyelik hedefine herhangi bir müdahale olmadan ulaşıp ulaşmadığını ölçerek ölçmek istedik. herhangi bir işlemin bırakılması. Ortalama defter kapanışını gözlemledik hesabı artırdıkça 5,03 sn, 5,10 sn ve 5,15 sn'lik zamanlar sırasıyla girişler, işlem oranı ve düğüm sayısı. Sonuçlar Stellar'nın defterleri tutarlı bir şekilde kapatabildiğini gösteriyor yüksek yük altında. 7.4 validator çalıştırılıyor Stellar'nin önemli özelliklerinden biri de düşük maliyetidir. çapaların çalışması (veya sözleşme yapması) gerektiği için validator çalıştırılıyor Kesinliği uygulamak için validators. SDF, tamamı iki çekirdeğe sahip c5.large AWS örneklerinde olmak üzere 3 adet üretim validator çalıştırıyor. 4 GiB RAM ve Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz işlemciler. Birinde kaynak kullanımı inceleniyor bu makinelerin Stellar işlemini kullanarak gözlemledik CPU'nun yaklaşık %7'si ve 300 MiB bellek. Ağ trafiği açısından, eşlerle 28 bağlantı ve çekirdek boyutuyla 34'ün giriş ve çıkış hızları 2,78 Mbit/s idi ve Sırasıyla 2,56 Mbit/s. Böyle bir işlemi çalıştırmak için gerekli donanım süreç ucuzdur. Bizim durumumuzda maliyet 0,054$/saattir veya ayda yaklaşık 40$. 7.5 Gelecekteki çalışmalar Bu deneyler, Stellar ürününün 1-2 siparişi kolayca ölçeklendirebileceğini gösteriyor günümüzün ağ kullanımının ötesinde büyüklükte. Çünkü performans talepleri bugüne kadar çok mütevazıydı, Stellar kullanarak birçok basit optimizasyona yer bırakır iyi bilinen teknikler. Örneğin, işlemler ve SCP mesajlar saf bir Flood kullanarak validators tarafından yayınlanıyor protokol, ancak ideal olarak daha verimli, yapılandırılmış bir protokol kullanmalıdır eşler arası çoklu yayın [30]. Ayrıca veritabanı ağırlıklı Defter güncelleme süresi, standart toplu işlem ve önceden getirme teknikleri yoluyla iyileştirilebilir.
结论
国际付款费用昂贵且需要数天时间。基金 托管通过多个金融机构，包括代理银行和汇款服务机构。 因为每一跳都必须完全可信，所以新的很难 进入者获得市场份额并参与竞争。 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 日，加拿大安大略省亨茨维尔
Çözüm
Uluslararası ödemeler pahalıdır ve günler sürer. Fon saklama, muhabir bankalar ve para transfer hizmetleri de dahil olmak üzere birden fazla finansal kurumdan geçer. Her bir şerbetçiotuna tamamen güvenilmesi gerektiğinden, yeni Katılımcıların pazar payı kazanmaları ve rekabet edebilmeleri. Stellar gösterileri Saniyeler içinde dünyanın her yerine ucuza nasıl para gönderilir? Temel yenilik, eşler arası yapıyı güçlendiren yeni bir açık üyelik Bizans anlaşma protokolü SCP'dir. finansal ağın küresel fikir birliğine varılması için Yeni İnternet hipotezi. SCP, Stellar'nin atomik olarak işlemesine izin veriyor keyfi katılımcılar arasında geri dönüşü olmayan işlemler Birbirinizi tanımıyorsunuz veya güvenmiyorsunuz. Bu da yeni girenlerin yerleşik pazarlarla aynı pazarlara erişmesini garanti eder oyuncular, mevcut en iyi değişimi almayı güvenli hale getirir güvenilmeyen piyasa yapıcılardan bile yüksek oranlar ve dramatik bir şekilde ödeme gecikmesini azaltır. Teşekkür Stellar erken olmasaydı bugün olduğu yerde olmazdı Joyce Kim'in liderliği veya muazzam katkıları Scott Fleckenstein ve Bartek Nowotarski inşaatta ve ufku, Stellar SDK'yı ve diğer önemli parçaları korumak Stellar ekosisteminin. Ayrıca Kolten Bergeron'a da teşekkür ederiz. Henry Corrigan-Gibbs, Candace Kelly, Kapil K. Jain, Boris Reznikov, Jeremy Rubin, Christian Rudder, Eric Saunders, Torsten Stüber, Tomer Weller, anonim eleştirmenler ve çobanımız Justine Sherry'e faydalı yorumlarından dolayı teşekkür ederiz. önceki taslaklar. Sorumluluk reddi beyanı Profesör Mazières'in bu yayına katkısı ücretli danışman olarak olmuştur ve kendi görevinin bir parçası değildir. Stanford Üniversitesi'nin görevleri veya sorumlulukları.
Stellar ile hızlı ve güvenli küresel ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada