بروتوكول إجماع Stellar
Ö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
خلاصة
المدفوعات الدولية بطيئة ومكلفة، ويرجع ذلك جزئيًا إلى توجيه الدفع متعدد القفزات عبر طرق غير متجانسة الأنظمة المصرفية. Stellar هي شبكة دفع عالمية جديدة التي يمكنها تحويل الأموال الرقمية مباشرة إلى أي مكان في العالم العالم في ثواني. الابتكار الرئيسي هو معاملة آمنة آلية عبر وسطاء غير موثوق بهم، وذلك باستخدام جديد بروتوكول الاتفاقية البيزنطية يسمى SCP. مع SCP، لكل منهما تحدد المؤسسة المؤسسات الأخرى التي ستبقى معها في الاتفاق؛ من خلال الترابط العالمي النظام المالي، ثم توافق الشبكة بأكملها على الذرية المعاملات التي تشمل مؤسسات تعسفية، مع عدم وجود مخاطر الملاءة المالية أو سعر الصرف من مصدري الأصول الوسطاء أو صناع السوق. نقدم نموذج SCP وبروتوكوله و التحقق الرسمي؛ وصف شبكة الدفع Stellar؛ وأخيرًا قم بتقييم Stellar تجريبيًا من خلال المعايير وخبرتنا مع عدة سنوات من استخدام الإنتاج. مفاهيم CCS • الأمن والخصوصية →الموزعة أمن الأنظمة؛ • تنظيم أنظمة الكمبيوتر → أبنية نظير إلى نظير؛ • نظم المعلومات → تحويل الأموال إلكترونيا. الكلمات الرئيسية blockchain, BFT, النصاب القانوني, الدفعات التنسيق المرجعي ACM: مارتا لوخافا، جوليانو لوسا، ديفيد مازيير، جرايدون هور، نيكولا باري، إيلي جافني، جوناثان جوف، رافائيل مالينوفسكي، جيد مكالب. 2019. مدفوعات عالمية سريعة وآمنة باستخدام Stellar. في SOSP ’19: ندوة حول مبادئ أنظمة التشغيل، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا. ACM، نيويورك، نيويورك، الولايات المتحدة الأمريكية، 17 صفحة. https://doi.org/10.1145/3341301.3359636
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.
مقدمة
من المعروف أن المدفوعات الدولية بطيئة ومكلفة [32]. خذ بعين الاعتبار عدم جدوى إرسال 0.50 دولار من الولايات المتحدة إلى * شركة جالوا †جامعة كاليفورنيا الإذن بعمل نسخ رقمية أو ورقية من كل هذا العمل أو جزء منه يُمنح الاستخدام الشخصي أو الاستخدام في الفصل الدراسي بدون رسوم بشرط عدم وجود نسخ صنعت أو وزعت لتحقيق الربح أو الميزة التجارية وتحمل تلك النسخ هذا الإشعار والاقتباس الكامل في الصفحة الأولى. حقوق الطبع والنشر للمكونات يجب تكريم هذا العمل المملوك لآخرين غير ACM. التجريد مع الائتمان مسموح به. النسخ بخلاف ذلك، أو إعادة النشر، للنشر على الخوادم أو إلى إعادة التوزيع على القوائم يتطلب الحصول على إذن محدد مسبق و/أو دفع رسوم. طلب الأذونات من [email protected]. SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا © 2019 جمعية آلات الحوسبة. ACM ISBN 978-1-4503-6873-5/19/10...$15.00 https://doi.org/10.1145/3341301.3359636 المكسيك دولتان متجاورتان. يدفع المستخدمون النهائيون ما يقرب من 9 دولارات لمتوسط هذا النقل [32]، واتفاق ثنائي ولم يكن من الممكن إلا أن تخفض الديون التي توسطت فيها البنوك المركزية في البلدان تبلغ تكلفة البنك الأساسي 0.67 دولارًا أمريكيًا لكل عنصر [2]. على رأس الرسوم، يتم احتساب زمن الوصول للمدفوعات الدولية بشكل عام في أيام، مما يجعل من المستحيل الحصول على الأموال في الخارج بسرعة حالات الطوارئ. في البلدان التي لا يوجد بها نظام مصرفي العمل أو لا يخدم جميع المواطنين، أو عندما تكون الرسوم غير محتملة، يلجأ الناس إلى إرسال المدفوعات بالحافلة [38]، عن طريق القارب [19]، وأحيانًا الآن بواسطة Bitcoin [55]، وكلها تحمل المخاطر أو الكمون أو الإزعاج. على الرغم من أنه ستكون هناك دائمًا تكاليف امتثال، تشير الأدلة إلى ضياع مبلغ كبير بسبب انعدام المنافسة [21]، والتي تتفاقم بسبب التكنولوجيا غير الفعالة. حيث الناس يمكن أن يبتكر، وتنخفض الأسعار وفترات التأخير. على سبيل المثال، بلغت تكلفة التحويلات من الحسابات المصرفية في الربع الثاني من عام 2019 ما متوسطه 6.99%، بينما بلغت نسبة تحويل الأموال عبر الهاتف المحمول 4.88% فقط [13]. شبكة دفع عالمية مفتوحة تجذب الابتكار ومن الممكن أن تؤدي المنافسة من جانب الكيانات غير المصرفية إلى الانخفاض التكاليف وزمن الوصول في جميع الطبقات، بما في ذلك الامتثال [83]. تعرض هذه الورقة Stellar، دفعة مستندة إلى blockchain شبكة مصممة خصيصًا لتسهيل الابتكار و المنافسة في المدفوعات الدولية. Stellar هو الأول نظام لتحقيق الأهداف الثلاثة التالية (تحت أ "فرضية الإنترنت" جديدة ولكنها صالحة تجريبيًا): 1. العضوية المفتوحة – يمكن لأي شخص إصدار عملة مدعومة tokens الرقمية التي يمكن تبادلها بين المستخدمين. 2. النهاية التي يفرضها المُصدر - يمكن لجهة إصدار token أن تمنع المعاملات في token من التراجع أو التراجع. 3. الذرية عبر المُصدر – يمكن للمستخدمين التبادل ذريًا وتداول tokens من جهات إصدار متعددة. إن تحقيق الأولين أمر سهل. يمكن لأي شركة أن تقدم من جانب واحد منتجًا مثل Paypal وVenmo وWeChat الدفع، أو Alipay والتأكد من نهائية المدفوعات في العملات الافتراضية التي قاموا بإنشائها. ولسوء الحظ، فإن التعامل ذريًا عبر هذه العملات أمر مستحيل. في الواقع، على الرغم من استحواذ Paypal على الشركة الأم لشركة Venmo في عام 2013، لا يزال من المستحيل على المستخدمين النهائيين إرسال Venmo دولار لمستخدمي Paypal [78]. في الآونة الأخيرة فقط يمكن للتجار حتى قبول كلاهما بتكامل واحد. يمكن تحقيق الهدفين 2 و 3 في نظام مغلق. وعلى وجه الخصوص، يتمتع عدد من البلدان بمدفوعات محلية تتسم بالكفاءة الشبكات، التي تشرف عليها عادةً هيئة تنظيمية موثوقة عالميًا. ومع ذلك، تقتصر العضوية على مغلقة مجموعة من البنوك المعتمدة والشبكات تقتصر على مدى وصول السلطة التنظيمية في البلاد.SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. تم تحقيق الهدفين 1 و3 في blockchains، وعلى الأخص في شكل ERC20 tokens على Ethereum [3]. الفكرة الرئيسية لهذه blockchain هي إنشاء عملة مشفرة جديدة يمكن من خلالها مكافأة الأشخاص على تسوية الأمر المعاملات من الصعب العودة. لسوء الحظ، هذا يعني أن جهات إصدار token لا تتحكم في نهائية المعاملة. إذا البرمجيات تتسبب الأخطاء في إعادة تنظيم سجل المعاملات [26، 73]، أو عندما تكون غنائم الغشاشين أكثر من تكلفة إعادة تنظيم التاريخ [74، 97]، قد يكون المصدرون مسؤولين عن tokens لقد قاموا بالفعل باستبدال أموال العالم الحقيقي. يحتوي Stellar blockchain على خاصيتين مميزتين. أولاً، يدعم أصلاً الأسواق الفعالة بين tokens من مصدرين مختلفين. على وجه التحديد، يمكن لأي شخص إصدار token، يوفر blockchain سجل طلبات مدمجًا للتداول بين أي زوج من token، ويمكن للمستخدمين إصدار دفعات المسار التي تتداول ذريًا عبر عدة أزواج عملات بينما ضمان سعر الحد الشامل. ثانيًا، يقدم Stellar اتفاقية بيزنطية جديدة البروتوكول SCP (Stellar بروتوكول الإجماع) والذي من خلاله يقوم مصدرو token بتعيين خوادم validator محددة للتنفيذ نهائية المعاملة. طالما لم يقم أحد بالمساس بـ validators الخاصة بجهة الإصدار (والتوقيعات الرقمية الأساسية و التشفير hashes آمن)، يعرف المصدر بالضبط المعاملات التي حدثت ويتجنب المخاطر من الخسائر الناجمة عن blockchain إعادة تنظيم التاريخ. الفكرة الرئيسية لشركة SCP هي أن معظم مصدري الأصول يستفيدون منها الأسواق السائلة وتريد تسهيل المعاملات الذرية مع الأصول الأخرى. ومن ثم، يتم تكوين مسؤولي validator خوادمهم للاتفاق مع validators الأخرى على وجه التحديد تاريخ جميع المعاملات على جميع الأصول. يمكن أن يكون validator v1 يمكن تكوينه للموافقة على الإصدار 2، أو يمكن تكوين الإصدار 2 للموافقة مع الإصدار 1، أو قد يتم تكوين كليهما للاتفاق مع بعضهما البعض؛ وفي جميع الحالات، لن يلتزم أي منهما بسجل المعاملات حتى إنها تعلم أن الآخر لا يمكنه الالتزام بتاريخ مختلف. بواسطة العبور، إذا كان v1 لا يمكن أن يختلف مع v2 وv2 لا يمكن أن يختلف مع v3 (أو العكس)، فإن v1 لا يمكن أن يختلف مع v3 v3، سواء كان v3 يمثل الأصول التي سمعها v1 أم لا من. في ظل فرضية أن هذه العلاقات اتفاق ربط الشبكة بالكامل بشكل عابر، يضمن SCP اتفاقية عالمية، مما جعلها اتفاقية بيزنطية عالمية بروتوكول ذو عضوية مفتوحة. نحن نطلق على افتراض الترابط الجديد هذا اسم فرضية الإنترنت، ونلاحظ ذلك يحمل كلا من "الإنترنت" (الذي يفهمه الجميع يعني أكبر شبكة IP متصلة بشكل عابر) والمدفوعات الدولية القديمة (التي تتم على أساس خطوة تلو الأخرى غير ذرية، ولكنها تستفيد من عالمية متصلة بشكل عابر شبكة المؤسسات المالية). Stellar قيد الاستخدام الإنتاجي منذ سبتمبر 2015. للحفاظ على طول blockchain قابلاً للإدارة، يتم تشغيل النظام SCP على فترات زمنية مدتها 5 ثوانٍ — بسرعة وفقًا لمعايير blockchain، ولكن أبطأ بكثير من التطبيقات النموذجية للاتفاقية البيزنطية. على الرغم من أن الاستخدام الأساسي كان عبارة عن مدفوعات، إلا أن Stellar كان كذلك أيضًا أثبتت جاذبيتها للأشياء القابلة للاستبدال غير المالية token والتي تستفيد منها من الأسواق الثانوية المباشرة (انظر القسم 7.1). ويناقش القسم التالي الأعمال ذات الصلة. يعرض القسم 3 SCP. يصف القسم 4 التحقق الرسمي من SCP. يصف القسم 5 طبقة الدفع الخاصة بـ Stellar. ويتعلق القسم 6 بعض خبراتنا في النشر والدروس المستفادة. القسم 7 يقيم النظام. وينتهي القسم 8.
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
Stellar بروتوكول الإجماع
يعتمد بروتوكول الإجماع Stellar (SCP) على النصاب القانوني بروتوكول الاتفاقية البيزنطية ذو العضوية المفتوحة. تنشأ النصاب القانوني من قرارات التكوين المحلي المجمعة للعقد الفردية. ومع ذلك، العقد تعترف فقط النصاب الذي ينتمون إليه أنفسهم، وبعد ذلك فقط التعرف على التكوينات المحلية لجميع أعضاء النصاب القانوني الآخرين. إحدى فوائد هذا النهج هو أن SCP بطبيعته يتسامح مع وجهات النظر غير المتجانسة حول ما هي العقد الموجودة. وبالتالي، يمكن للعقد الانضمام والمغادرة من جانب واحد دون الحاجة إلى بروتوكول "عرض التغيير" لتنسيق العضوية. 3.1 الاتفاقية البيزنطية الفيدرالية تتكون مشكلة الاتفاقية البيزنطية التقليدية من أ نظام مغلق من العقد N، وبعضها معيب وربما التصرف بشكل تعسفي. تتلقى العقد قيم الإدخال والتبادل الرسائل لتحديد قيمة الإخراج بين المدخلات. يكون بروتوكول الاتفاقية البيزنطية آمنًا عندما لا تنتج عقدتان جيدتا التصرف قرارات مختلفة وفريدة من نوعها كان القرار مدخلاً صالحًا (بالنسبة لبعض التعريفات الصالحة المتفق عليهاSOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. عليه مسبقًا). يكون البروتوكول حيًا عندما يضمن ذلك كل عقدة صادقة تنتج في النهاية قرارًا. عادةً، تفترض البروتوكولات N = 3f + 1 لبعض الأعداد الصحيحة f > 0، ثم ضمان السلامة وشكل من أشكال الحيوية طالما أن معظم العقد f معيبة. في مرحلة ما في هذه البروتوكولات، والعقد تصوت على القيم المقترحة والاقتراح الحصول على 2f + 1 صوت، وهو ما يسمى نصاب الأصوات، يصبح القرار. مع N = 3f + 1 العقد، أي نصابين من يتداخل الحجم 2f + 1 في العقد f + 1 على الأقل؛ حتى لو و من هذه العقد المتداخلة معيبة، ويشترك النصابان على الأقل عقدة واحدة غير معيبة، مما يمنع اتخاذ قرارات متناقضة. ومع ذلك، فإن هذا النهج لا يعمل إلا إذا اتفقت جميع العقد ما يشكل النصاب القانوني، وهو أمر مستحيل في SCP حيث قد لا تعرف العقدتان وجود بعضهما البعض. مع SCP، كل عقدة v تعلن من جانب واحد عن مجموعات من العقد، تسمى شرائح النصاب القانوني، بحيث (أ) v يعتقد أنه إذا كان كل شيء إذن، يتفق أعضاء الشريحة على حالة النظام إنهم على حق، و(ب) v يعتقد أن شريحة واحدة على الأقل من شرائحه سيكون متاحًا لتقديم المعلومات في الوقت المناسب حول حالة النظام. نحن نسمي النظام الناتج، يتكون العقد وشرائحها، اتفاقية بيزنطية موحدة نظام (FBA). وكما سنرى بعد ذلك، يظهر نظام النصاب القانوني من شرائح العقد. بشكل غير رسمي، تعبر شرائح عقدة FBA عن من معه العقدة تتطلب الاتفاق. على سبيل المثال، قد تتطلب العقدة اتفاقًا مع 4 مؤسسات محددة، تدير كل منها 3 عقد؛ ل لاستيعاب وقت التوقف عن العمل، فقد يقوم بتعيين شرائحه لتكون جميع المجموعات تتكون من عقدتين من كل منظمة. إذا كان هذا "يتطلب الاتفاق مع "العلاقة ترتبط بشكل متعدٍ بأي عقدتين، نحصل على اتفاق عالمي. وإلا فإننا قد نحصل على الاختلاف، ولكن فقط بين المنظمات لا يتطلب أي منهما الاتفاق مع الآخر. بالنظر إلى طوبولوجيا اليوم في النظام المالي، فإننا نفترض أن التقارب واسع النطاق سوف يستمر في إنتاج سجل تاريخي واحد يسميه الناس "شبكة Stellar"، بقدر ما نتحدث عن الإنترنت. النصاب القانوني ينشأ من الشرائح على النحو التالي. تحدد كل عقدة شرائح النصاب القانوني في كل رسالة يرسلها. دع S يكون مجموعة العقد التي نشأت منها مجموعة من الرسائل. أ تعتبر العقدة أن مجموعة الرسائل قد وصلت إلى النصاب القانوني العتبة عندما يكون لدى كل عضو في S شريحة مضمنة في S. من خلال البناء، فإن مثل هذه المجموعة S، إذا تم الإجماع عليها، تلبي متطلبات الاتفاق لكل عضو من أعضائها. قد يعلن النظير المعيب عن شرائح تم تصميمها لتغيير ما العقد حسنة التصرف تأخذ في الاعتبار النصاب القانوني. من أجل تحليل البروتوكول، حددنا النصاب القانوني في FBA ليكون غير فارغ مجموعة S من العقد تشمل شريحة نصاب واحدة على الأقل كل عضو غير معيب. وهذا التجريد سليم، كأي مجموعة من الرسائل التي يزعم أنها تمثل النصاب القانوني بالإجماع في الواقع (حتى لو كان يحتوي على رسائل من عقد معيبة)، ويكون دقيقًا عندما يحتوي S على العقد جيدة التصرف فقط. في في هذا القسم، نفترض أيضًا أن شرائح العقد لا تتغير. ومع ذلك، فإن نتائجنا تنتقل إلى حالة الشريحة المتغيرة لأن النظام الذي يتم فيه تغيير الشرائح لا يقل أمانًا عن نظام شريحة ثابتة تتكون فيه شرائح العقدة من جميع الشرائح التي تستخدمها على الإطلاق في حالة الشرائح المتغيرة (انظر النظرية 13 في [68]). كما هو موضح في القسم 4، تعتمد الحيوية على العقد حسنة التصرف تقوم في النهاية بإزالة العقد غير الموثوقة من شرائحهم. نظرًا لأن العقد المختلفة لها متطلبات اتفاقية مختلفة، فإن FBA يمنع تعريفًا عالميًا للسلامة. نحن نقول تتشابك العقد غير المعيبة v1 وv2 عند كل منهما يتقاطع نصاب v1 مع كل نصاب v2 في واحد على الأقل عقدة غير معيبة. يمكن لبروتوكول FBA ضمان الاتفاق فقط بين العقد المتشابكة؛ منذ SCP يفعل ذلك، خطأه التسامح من أجل السلامة هو الأمثل. فرضية الإنترنت ينص تصميم Stellar الأساسي على أن العقد تهتم بالأشخاص حول سوف تكون متشابكة. نقول إن مجموعة العقد I سليمة إذا كنت نصابًا غير معيب بشكل موحد بحيث يتشابك كل عضوين من I حتى لو كانت كل عقدة خارج I معيبة. بشكل حدسي، إذن، يجب أن أبقى منيعًا أمام تصرفات غير سليمة العقد. يضمن SCP كلاً من الحيوية غير المحظورة [93] و السلامة لمجموعات سليمة، على الرغم من أن العقد نفسها لا تحتاج إليها لمعرفة (وقد لا تكون قادرًا على معرفة) المجموعات السليمة. علاوة على ذلك، فإن اتحاد مجموعتين سليمتين متقاطعتين هو مجموعة سليمة. لذلك، تحدد المجموعات السليمة قسمًا من ملف العقد حسنة التصرف، حيث يكون كل قسم آمنًا وحيويًا (في ظل بعض الشروط)، ولكن قد يتم إخراج أقسام مختلفة قرارات متباينة. 3.1.1 اعتبارات السلامة مقابل الحياة في FBA مع استثناءات محدودة [64]، يتم ضبط معظم بروتوكولات الاتفاقية البيزنطية المغلقة على نقطة التوازن التي عندها السلامة والحيوية لهما نفس التسامح مع الخطأ. في فبا، وهذا يعني التكوينات التي، بغض النظر عن الفشل، كل شيء المجموعات المتشابكة سليمة أيضًا. بالنظر إلى أن FBA يحدد النصاب القانوني بطريقة لا مركزية، فمن غير المرجح أن تؤدي اختيارات الشرائح الفردية إلى هذا التوازن. علاوة على ذلك، في على الأقل في Stellar، التوازن غير مرغوب فيه: العواقب من فشل السلامة (أي الأموال الرقمية التي تم إنفاقها بشكل مزدوج). أسوأ بكثير من فشل الحياة (أي التأخير في الدفعات التي استغرقت على أي حال أيامًا قبل Stellar). الناس ولذلك ينبغي القيام بتحديد شرائح النصاب القانوني الكبيرة من هذا القبيل من المرجح أن تظل عقدها متشابكة أكثر من كونها سليمة. علاوة على ذلك، يصبح التعافي منه أسهل إخفاقات الحيوية النموذجية في نظام FBA مقارنةً بالنظام التقليدي المغلق. في الأنظمة المغلقة، يجب أن تكون كافة الرسائل يتم تفسيرها فيما يتعلق بنفس مجموعة النصاب القانوني. وبالتالي، يتطلب إضافة العقد وإزالتها للتعافي من الفشل التوصل إلى إجماع حول حدث إعادة التشكيل، وهو أمر صعب بمجرد انتهاء الإجماع. على النقيض من ذلك، مع FBA، يمكن لأي عقدة ضبط شرائح النصاب القانوني الخاصة بها من جانب واحد في أي وقت الوقت. ردا على انقطاع التيار الكهربائي في أهمية نظامية المؤسسة، يمكن لمسؤولي العقدة ضبط الشرائح الخاصة بهم وفقًا لذلك التغلب على المشكلة، يشبه إلى حد ما تنسيق الاستجابات لكوارث BGP [63] (على الرغم من عدم وجود قيود التوجيه عبر روابط الشبكة الفعلية).
مدفوعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا 3.1.2 نظرية التتالي يتبع SCP قالب النموذج الدائري الأساسي [42]؛ تتقدم العقد من خلال سلسلة من بطاقات الاقتراع المرقمة، لكل منها محاولة القيام بثلاث مهام: (1) تحديد قيمة "آمنة" لا تتعارض مع أي قرار تم اتخاذه في الاقتراع السابق (يُطلق عليه غالبًا إعداد الاقتراع)، (2) الاتفاق على القيمة الآمنة، و (3) اكتشاف أن الاتفاق كان ناجحًا. ومع ذلك، FBA مفتوح العضوية تحبط العديد من التقنيات الشائعة، مما يجعلها من المستحيل "نقل" البروتوكولات التقليدية المغلقة إلى FBA النموذج ببساطة عن طريق تغيير تعريف النصاب القانوني. إحدى التقنيات المستخدمة في العديد من البروتوكولات هي التدوير من خلال العقد الرائدة بطريقة دائرية بعد انتهاء المهلات. في النظام المغلق، يتم ضمان اختيار القائد بشكل دائري في نهاية المطاف، ينتهي الأمر بالقائد الصادق الفريد إلى تنسيق الاتفاق على قيمة واحدة. لسوء الحظ، جولة روبن لا يمكن العمل في نظام FBA بعضوية غير معروفة. أسلوب شائع آخر يفشل مع FBA هو افتراض أن نصابًا معينًا يمكنه إقناع جميع العقد. على سبيل المثال، إذا تعرف الجميع على أي عقد 2f + 1 كنصاب قانوني، إذن تكفي توقيعات 2f + 1 لإثبات حالة البروتوكول لجميع العقد. وبالمثل، إذا تلقت العقدة نصابًا من الرسائل المتطابقة من خلال البث الموثوق [24]، يمكن للعقدة أن تفترض أن جميع العقد غير الخاطئة سوف تشهد أيضًا النصاب القانوني. في FBA، على النقيض من ذلك، أ النصاب القانوني لا يعني شيئا للعقد خارج النصاب القانوني. وأخيرا، غالبا ما تستخدم الأنظمة غير الفيدرالية "الرجعية" التفكير في السلامة: إذا كانت العقد f + 1 معيبة، فكل الأمان فقدت الضمانات. وبالتالي، إذا سمعت العقدة v جميع العقد f + 1 اذكر بعض الحقائق F، v يمكن أن تفترض أن واحدًا على الأقل هو الذي يخبر الحقيقة (وبالتالي F صحيحة) دون فقدان الأمان. مثل هذا يفشل المنطق في FBA لأن السلامة هي خاصية للأزواج من العقد، لذلك يمكن للعقدة التي فقدت الأمان لبعض أقرانها تفقد الأمان دائمًا لمزيد من العقد من خلال افتراض حقائق سيئة. ومع ذلك، يمكن لـ FBA التفكير بشكل عكسي فيما يتعلق بالحيوية. حدد مجموعة v-blocking كمجموعة من العقد التي تتقاطع مع كل منها شريحة v. إذا كانت مجموعة حجب v B معيبة بالإجماع، فإن B يمكن رفض العقدة ضد النصاب القانوني وتكلفتها الحيوية. وبالتالي، إذا ينص B بالإجماع على الحقيقة F، ثم يعرف v أن أيًا من F هو صحيح أو v ليس سليما. ومع ذلك، لا يزال v بحاجة لرؤية كامل النصاب القانوني لمعرفة أن العقد المتشابكة لن تتعارض مع F، مما يؤدي إلى الجولة النهائية من الاتصالات في SCP و بروتوكولات FBA الأخرى [47] غير المطلوبة في الأنظمة المشابهة بروتوكولات العضوية المغلقة. والنتيجة هي أن لدينا ثلاثة مستويات محتملة من الثقة في الحقائق المحتملة: غير محددة، وآمنة للافتراض بين العقد السليمة (وهو ما سنفعله). مصطلح حقائق مقبولة)، وآمن الافتراض فيما بينها العقد (والتي سنسميها حقائق مؤكدة). يمكن للعقدة v تحديد ما إذا كانت المجموعة B محظورة بكفاءة عن طريق التحقق مما إذا كانت B تتقاطع مع جميع شرائحها. ومن المثير للاهتمام أنه إذا كانت العقد تعلن دائمًا عن البيانات فإنها قبول والنصاب القانوني الكامل لقبول بيان، فإنه يطلق عملية متتالية يتم من خلالها نشر البيانات في جميع أنحاء مجموعات سليمة. نحن نسمي الحقيقة الأساسية الكامنة وراء هذا الانتشار النظرية المتتالية، التي تنص على ما يلي: إذا كنت مجموعة سليمة، Q هو النصاب القانوني لأي عضو في I، وS هو أي مجموعة شاملة من Q، ثم إما S ⊇I أو هناك عضو v ∈I بحيث يكون v < S و I ∩S بمثابة حجب v. حدسيًا، كان هذا ليس الأمر كذلك، فإن تكملة S سوف تحتوي على النصاب القانوني الذي يتقاطع مع I وليس Q، مما ينتهك تقاطع النصاب القانوني. لاحظ أنه إذا بدأنا بـ S = Q وقمنا بتوسيع S بشكل متكرر إلى بتضمين جميع العقد التي يحظرها، نحصل على تأثير متتالي حتى، في النهاية، S يشمل كل I. 3.2 وصف البروتوكول SCP هو بروتوكول إجماع متزامن جزئيًا [42] يتكون من سلسلة من المحاولات للوصول إلى إجماع يسمى بطاقات الاقتراع. تستخدم بطاقات الاقتراع فترات زمنية أطول. أ يضمن بروتوكول مزامنة الاقتراع بقاء العقد قائمة نفس الاقتراع لفترات زمنية متزايدة حتى الاقتراع متزامنة بشكل فعال. الإنهاء غير مضمون حتى تصبح بطاقات الاقتراع متزامنة، ولكن ورقتين متزامنتين وهو ما يفعله الأعضاء المعيبون في شرائح العقد حسنة التصرف عدم التدخل كافية لإنهاء SCP. ويحدد بروتوكول الاقتراع الإجراءات المتخذة خلال كل منها الاقتراع. يبدأ الاقتراع بمرحلة إعداد، حيث يتم تحديد العقد محاولة تحديد قيمة لاقتراح لا يتعارض أي قرار سابق. ثم، في مرحلة الالتزام، تحاول العقد لاتخاذ قرار بشأن القيمة المعدة. يستخدم الاقتراع بروتوكولًا فرعيًا للاتفاق يسمى التصويت الفيدرالي، أيn التي العقد تصوت على البيانات المجردة والتي قد يتم تأكيدها في النهاية أو تتعثر. قد يتم تصنيف بعض العبارات على أنها متناقضة، والسلامة ضمان التصويت الفيدرالي هو عدم وجود عضوين في أي عضو مجموعة متشابكة تؤكد تصريحات متناقضة. ولا يضمن تأكيد القول إلا سليما تعيين الذي يصوت جميع أعضائه بنفس الطريقة. ومع ذلك، إذا كان أ عضو في مجموعة سليمة يؤكد بيانًا متحدًا يضمن التصويت أن جميع أعضاء المجموعة السليمة يؤكدون هذا البيان في النهاية. وبالتالي اتخاذ خطوات لا رجعة فيها ردا على تأكيد التصريحات يحفظ الحيوية ل العقد سليمة. تقترح العقد في البداية القيم التي تم الحصول عليها من الترشيح البروتوكول الذي يزيد من فرص جميع الأعضاء سليمة مجموعة تقترح نفس القيمة، والتي تتقارب في نهاية المطاف (على الرغم من عدم وجود طريقة لتحديد التقارب الكامل). يجمع الترشيح بين التصويت الفيدرالي واختيار القائد. لأن جولة روبن مستحيلة في FBA، يستخدم الترشيح مخطط احتمالي لاختيار القائد. تلعب نظرية التعاقب دورًا حاسمًا في الاقتراع المزامنة وتجنب الحالات المحظورة منها الإنهاء لم يعد ممكنا. 3.2.1 الاقتراع تستمر عقد SCP عبر سلسلة من بطاقات الاقتراع المرقمة، باستخدام التصويت الفيدرالي للاتفاق على البيانات المتعلقة بها يتم أو لا يتم تحديد القيم في أي بطاقة اقتراع. إذا كان غير متزامن أو السلوك الخاطئ يمنع التوصل إلى قرار في الاقتراع ن، انتهت مهلة العقد وحاول مرة أخرى في الاقتراع n + 1.
SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. تذكر أن التصويت الفيدرالي قد لا ينتهي. وبالتالي بعض يمكن أن تتعثر البيانات المتعلقة بأوراق الاقتراع بشكل دائم حالة غير محددة حيث لا يمكن للعقد أبدًا تحديد ما إذا كانت لا تزال في التقدم أو عالقة. لأن العقد لا يمكن استبعادها إمكانية إثبات صحة البيانات غير المحددة لاحقًا، ويجب عليهم ألا يحاولوا أبدًا التصويت الفيدرالي على البيانات الجديدة يتعارض مع غير المحدد. في كل اقتراع n، تستخدم العقد التصويت الفيدرالي على نوعين من البيان: • تحضير ⟨n,x⟩– ينص على عدم وجود قيمة أخرى غير x تم أو سيتم تحديده في أي اقتراع. • الالتزام ⟨n,x⟩– الدول x يتم تحديدها في الاقتراع n. الأهم من ذلك، لاحظ أن تحضير ⟨n,x⟩تناقضات الالتزام ⟨n',x ′⟩عندما n ≥n' و x , x ′. تبدأ العقدة الاقتراع n من خلال محاولة التصويت الفيدرالي على a بيان تحضير ⟨n,x⟩. إذا كان هناك أي بيان إعداد سابق تم تأكيده بنجاح من خلال التصويت الفيدرالي تختار العقدة x من الإعداد المؤكد لأعلى بطاقة اقتراع. وبخلاف ذلك، تقوم العقدة بتعيين x إلى إخراج الملف بروتوكول الترشيح الموضح في القسم الفرعي التالي. إذا وفقط إذا أكدت العقدة بنجاح التحضير ⟨n,x⟩ في الاقتراع n، يحاول التصويت الفيدرالي على الالتزام ⟨n,x⟩. إذا إذا نجح، فهذا يعني أن SCP قد قرر، وبالتالي يتم إخراج العقدة القيمة من بيان الالتزام المؤكد. النظر في مجموعة متشابكة S. منذ قيمة واحدة على الأكثر يمكن تأكيد إعدادها من قبل أعضاء S في اقتراع معين، ولا يجوز تأكيد الالتزام بقيمتين مختلفتين أعضاء S في اقتراع معين. علاوة على ذلك، إذا ارتكبت ⟨n,x⟩ تم تأكيده، ثم تم تأكيد إعداد ⟨n,x⟩ أيضًا؛ منذ ذلك الحين يعد ⟨n,x⟩يناقض أي التزام سابق بقيمة مختلفة، بموجب اتفاقية ضمانات التصويت الفيدرالي لقد حصلنا على أنه لا يمكن تحديد قيمة مختلفة في وقت سابق الاقتراع من قبل أعضاء S. عن طريق التعريف بأرقام الاقتراع، نحن لذا تأكد من أن SCP آمن. من أجل الحيوية، فكر في مجموعة سليمة وطويلة بما فيه الكفاية اقتراع متزامن إذا ظهرت العقد الخاطئة في الشرائح من العقد حسنة التصرف لا تتدخل في ن، ثم عن طريق الاقتراع n + 1 جميع أعضاء لقد أكدوا نفس المجموعة P من بيانات الإعداد. إذا كانت P = ∅وبطاقة الاقتراع n طويلة بما فيه الكفاية، فإن سيكون بروتوكول الترشيح قد تقارب على بعض القيمة x. بخلاف ذلك، اجعل x هي القيمة من الإعداد بأعلى ورقة اقتراع في P. وفي كلتا الحالتين، سأحاول بشكل موحد التصويت على إعداد ⟨n + 1,x⟩ في الاقتراع التالي. لذلك، إذا n + 1 متزامن أيضًا، ويتبع ذلك حتماً قرار x. 3.2.2 الترشيح يستلزم الترشيح التصويت الموحد على البيانات: • ترشيح x - الدول x هي مرشح صالح للقرار. قد تصوت العقد لترشيح قيم متعددة — مختلفة تصريحات الترشيح ليست متناقضة. ومع ذلك، مرة واحدة تؤكد العقدة أي بيان ترشيح، وتتوقف عن التصويت عليه ترشيح قيم جديدة. لا يزال التصويت الفيدرالي يسمح للعقدة بذلك تأكيد بيانات الترشيح الجديدة التي لم تصوت لها التصويت أو القبول أ من النصاب القانوني قبول أ من النصاب القانوني أ صالح قبول من مجموعة الحظر غير ملتزم صوت أ قبلت أ أكد أ تم التصويت بـ أ الشكل 1. مراحل التصويت الفيدرالي يسمح لأعضاء مجموعة سليمة بتأكيد مجموعة بعضهم البعض القيم المرشحة مع الاستمرار في حجب الأصوات الجديدة. النتيجة (المتطورة) للترشيح هي مزيج حتمي من جميع القيم في بيانات الترشيح المؤكدة. إذا يمثل x مجموعة من المعاملات، ويمكن للعقد أن تأخذ الاتحاد من المجموعات، المجموعة الأكبر، أو المجموعة ذات أعلى hash، لذا طالما أن جميع العقد تفعل الشيء نفسه. لأن العقد حجب جديدة الأصوات بعد تأكيد بيان ترشيح واحد، مجموعة يمكن أن تحتوي البيانات المؤكدة على عدد محدود من القيم فقط. حقيقة أن التصريحات المؤكدة انتشرت بشكل موثوق من خلال المجموعات السليمة تعني أن العقد السليمة تتقارب في النهاية على نفس مجموعة القيم المرشحة وبالتالي نتيجة الترشيح، وإن كان عند نقطة غير معروفة بشكل تعسفي في وقت متأخر من البروتوكول. تستخدم العقد اختيار القائد المتحد لتقليل عدد القيم المختلفة في بيانات الترشيح. فقط يجوز للقائد الذي لم يصوت بالفعل لصالح بيان الترشيح أن يقدم علامة x جديدة. العقد الأخرى تنتظر أن تسمع منها القادة ويقومون فقط بنسخ أصوات ترشيح قادتهم (الصالحة). لاستيعاب الفشل، تستمر مجموعة القادة في النمو تحدث المهلات، على الرغم من أن عددًا قليلاً فقط من العقد تقدم قيمًا جديدة لـ x. 3.2.3 التصويت الفيدرالي يستخدم التصويت الفيدرالي بروتوكولًا ثلاثي المراحل كما هو موضح في الشكل 1. تحاول العقد الاتفاق على البيانات المجردة أولاً التصويت، ثم القبول، وأخيراً تأكيد البيانات. قد تصوت العقدة v لأي بيان صالح لا ينطبق عليه ذلك يناقض غيرهالأصوات المتميزة والبيانات المقبولة. ويتم ذلك عن طريق بث رسالة تصويت موقعة. v ثم يقبل a إذا كان a متوافقًا مع البيانات المقبولة الأخرى وإما (الحالة 1)v هو عضو في النصاب القانوني الذي كل عقدة إما تصوت لـ أو تقبل أو (الحالة 2) حتى لو كانت v لم أصوت لصالح مجموعة v-blocking تقبل a. في الحالة 2، قد سبق أن أدلوا بأصوات تتعارض مع ما حدث الآن تم نقضها. v يُسمح له بنسيان الأصوات الملغاة ويتظاهر بأنه لم يلقيهم أبدًا لأنه إذا كان سليمًا، فهو يعلم لا يمكن للأصوات الملغاة إكمال النصاب القانوني من خلال الحالة 1. v يبث أنه يقبل a، ثم يؤكد a عندما يكون موجودًا نصاب يقبل بالإجماع أ. ويبين الشكل 2 تأثير مجموعات الحجب v ونظرية التتالي خلال التصويت الفيدرالي. لا يمكن لعقدتين متشابكتين تأكيد البيانات المتناقضة، حيث يجب أن يتشارك النصابان المطلوبان في أمدفوعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا 3 4 2 1 5 7
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.
التصويت ×
التصويت ي (أ) 3 4 2 1 5 7 6 التصويت X التصويت X التصويت X التصويت ي التصويت X التصويت ي التصويت ي (ب) 3 4 2 1 5 7 6 قبول X التصويت X قبول X التصويت ي قبول X التصويت ي التصويت ي (ج) 3 4 2 1 5 7 6 قبول X قبول X قبول X التصويت ي قبول X قبول X التصويت ي (د) 3 4 2 1 5 7 6 قبول X التصويت X قبول X قبول X قبول X قبول X قبول X (هـ) الشكل 2. تأثير تتالي في التصويت الاتحادي. تحتوي كل عقدة على شريحة نصاب واحدة يُشار إليها بأسهم لأعضاء الشريحة. (أ) تم تقديم بيانات متناقضة X وY. (ب) تصوت العقد على البيانات الصحيحة. (ج) العقدة 1 تقبل X بعد نصابها القانوني {1، 2، 3، 4} يصوتون بالإجماع لصالح X. (د) تقبل جميع العقد 1 و2 و3 و4 X؛ المجموعة {1} عبارة عن 5 حظر، لذا تقبل العقدة 5 X، مما يؤدي إلى إلغاء ذلك تصويتها السابق لصالح Y. (هـ) المجموعة {5} عبارة عن حجب 6 و7، لذا يقبل كل من 6 و7 X. عقدة غير معيبة لا يمكنها قبول البيانات المتناقضة. تأكيد البيان غير مضمون: في وفي حالة انقسام التصويت، يجوز أن يكون كلا البيانين بشكل دائم عالقون في انتظار اكتمال النصاب القانوني في مرحلة التصويت. ومع ذلك، إذا عقدة في مجموعة سليمة تؤكد بيانًا، التتالي النظرية وقبول الحالة 2 تأكد من أنني سأفعل ذلك جميعًا في النهاية تأكيد هذا البيان. 3.2.4 مزامنة الاقتراع إذا كانت العقد غير قادرة على تأكيد بيان الالتزام لـ الاقتراع الحالي، فإنهم يستسلمون بعد مهلة. يحصل المهلة لفترة أطول مع كل اقتراع حتى يتسنى التكيف مع الحدود التعسفية على تأخير الشبكة. ومع ذلك، فإن المهلات وحدها ليست كافية لمزامنة بطاقات الاقتراع الخاصة بالعقد التي لم تبدأ في نفس الوقت أو حصلت على غير متزامنة لأسباب أخرى. لتحقيق التزامن، تبدأ العقد في تشغيل المؤقت فقط عندما تصبح جزءًا من ملف النصاب القانوني الذي يكون موجودًا في الاقتراع الحالي (أو اللاحق) n. هذا يبطئ العقد التي بدأت مبكرًا ويضمن عدم حدوث ذلك يبقى العضو في مجموعة سليمة متقدمًا جدًا على المجموعة. علاوة على ذلك، إذا لاحظت العقدة v تعيين حجب v في وقت لاحق الاقتراع، فإنه يتخطى على الفور إلى أدنى بطاقة اقتراع مثل هذا لم يعد هذا هو الحال، بغض النظر عن أي توقيت. الشلال ثم تضمن النظرية أن جميع المتطرفين يلحقون بالركب. النتيجة هو أن بطاقات الاقتراع تتم مزامنتها تقريبًا في جميع أنحاء سليمة يتم ضبطه بمجرد أن يصبح النظام متزامنًا. 3.2.5 اختيار الزعيم الاتحادي يسمح اختيار القائد لكل عقدة باختيار القادة في مثل هذا الطريقة التي تختار بها العقد عمومًا واحدًا أو عددًا صغيرًا فقط من القادة. لاستيعاب فشل القائد، يتم اختيار القائد العائدات من خلال جولات. إذا كان قادة الجولة الحالية يبدو أنهم لا يقومون بمسؤولياتهم، ثم بعد أ تنتقل عقد معينة في فترة المهلة إلى الجولة التالية توسيع مجموعة القادة الذين يتبعونهم. تستخدم كل جولة وظيفتين تشفيريتين فريدتين hash، H0 وH1، اللتين تنتجان أعدادًا صحيحة في النطاق [0,hmax). على سبيل المثال، Stellar يستخدم Hi(m) = SHA256(i∥b∥r ∥m)، حيث b هو مثيل SCP الإجمالي (رقم الكتلة أو دفتر الأستاذ)، وr هو الرقم الدائري لاختيار القائد، وhmax = 2256. ضمن جولة، نحدد أولوية العقدة v على النحو التالي: الأولوية (ت) = H1(ت) سيكون رجل القش واحدًا لكل عقدة لتختاره كقائد العقدة ذات الأولوية العليا (v). هذا النهج يعمل بشكل جيد مع شرائح النصاب القانوني المتطابقة تقريبًا، ولكن ليس بشكل صحيح التقاط أهمية العقد في التكوينات غير المتوازنة. على سبيل المثال، إذا ساهمت كل من أوروبا والصين بـ 3 عقد لكل نصاب، لكن الصين تدير 1000 عقدة وأوروبا 4، عندها ستحصل الصين على العقدة ذات الأولوية القصوى بنسبة 99.6% من الوقت. لذلك نقدم فكرة وزن الشريحة، حيث الوزن (u,v) ∈[0, 1] هو جزء من شرائح النصاب القانوني للعقدة u تحتوي على العقدة v. عندما تقوم العقدة u باختيار قائد جديد، فإنه يأخذ في الاعتبار الجيران فقط، ويتم تعريفهم على النحو التالي: الجيران (ش) = { ت | H0(v) < hmax · الوزن(u,v) } تبدأ العقدة بعد ذلك بمجموعة فارغة من القادة، وعند كل منهم تضيف إليها العقدة v في الجيران (u) ذات الأعلى الأولوية (ت). إذا كانت مجموعة الجيران فارغة في أي جولة، فبدلاً من ذلك تضيف العقدة ذات القيمة الأقل H0(v)/weight(u,v).
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ı.
التحقق الرسمي من SCP
للتخلص من أخطاء التصميم، قمنا بالتحقق رسميًا من سلامة SCP وخصائص الحيوية (انظر [65]). على وجه التحديد، لقد تحققنا وأن العقد المتشابكة لا تختلف أبدًا، وأنه في ظل الظروف الموضحة أدناه، يقرر كل عضو في المجموعة السليمة في النهاية. ومن المثير للاهتمام أن التحقق كشف أن الظروف التي بموجبها تضمن SCP الحيوية تكون دقيقة، وأقوى مما كان يعتقد في البداية [68]: كما هو موضح أدناه، العقد الخبيثة التي تتلاعب بالتوقيت دون غير ذلك قد يحتاج الانحراف عن البروتوكول إلى الإخلاء يدويًا من شرائح النصاب.
SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. للتأكد من أن الخصائص ثبت ثباتها بكل ما هو ممكن تكوينات FBA وعمليات التنفيذ، نعتبرها تعسفية عدد العقد ذات التكوينات المحلية التعسفية. هذا يتضمن سيناريوهات ذات مجموعات سليمة مفككة، بالإضافة إلى عمليات تنفيذ طويلة بلا حدود. العيب هو أننا مواجهة المشكلة الصعبة المتمثلة في التحقق من المعلمات نظام الدولة اللانهائية. لإبقاء التحقق سهلاً، قمنا بتصميم SCP في منطق الدرجة الأولى (FOL) باستخدام Ivy [69] ومنهجية [82]. تتكون عملية التحقق من تقديم تخمينات استقرائية يدويًا، والتي يتم بعد ذلك التحقق منها تلقائيًا اللبلاب. يلخص نموذج FOL لملخصات SCP بعض جوانب أنظمة FBA التي يصعب التعامل معها في FOL (على سبيل المثال، يتم أخذ نظرية التتالي كبديهية)، لذلك نحن نتحقق من سلامة التجريد باستخدام Isabelle/HOL [75]. بعد التعبير عن مشكلة التحقق في FOL، نتحقق من السلامة من خلال توفير ثابت استقرائي. الاستقرائي يتكون الثابت من عشرات التخمينات ذات السطر الواحد لحوالي 150 سطرًا من مواصفات البروتوكول. نقوم بعد ذلك بتحديد خصائص حيوية SCP في المنطق الزمني الخطي لـ Ivy ونستخدم من الحيوية إلى تقليل السلامة [80، 81] لتقليل الحيوية مشكلة التحقق لمشكلة العثور على الاستقرائي ثابت. في حين أن سلامة SCP واضحة نسبيًا أثبت أن حجة حيوية SCP أكثر تعقيدًا و يتكون من حوالي 150 ثابتًا في سطر واحد. يتطلب إثبات الحيوية إضفاء الطابع الرسمي الدقيق على الافتراضات التي بموجبها تضمن SCP الإنهاء. لقد اعتقدنا في البداية أن المجموعة السليمة سوف أقوم بإنهائها دائمًا قام الأعضاء بإزالة العقد المعيبة من شرائحهم [68]. ومع ذلك، فقد تبين أن هذا غير كاف: حسن التصرف (لكن غير سليمة) عقدة في النصاب القانوني لعضو أستطيع، تحت تأثير العقد الخاطئة، ومنع الإنهاء عن طريق استكمال النصاب القانوني قبل نهاية الاقتراع مباشرة، مما يتسبب في ذلك أعضاء I لاختيار قيم مختلفة لـ x في الاقتراع التالي. ولذلك يجب علينا بالإضافة إلى ذلك أن نفترض أنه، بشكل غير رسمي، كل عقدة في النصاب القانوني لعضو من أنا في نهاية المطاف سواء يصبح في الوقت المناسب أو لا يرسل الرسائل على الإطلاق لفترة كافية. في الممارسة العملية، هذا يعني أعضاء يجوز لي بحاجة إلى ضبط شرائحهم حتى يستمر الشرط. هذا المشكلة ليست متأصلة في أنظمة FBA: Losa et al. [47] موجود بروتوكول تعتمد حيويته على الأضعف تمامًا افتراضات التزامن النهائي وانتخاب القائد في نهاية المطاف، دون الحاجة إلى إزالة العقد المعيبة من الشرائح.
Ö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، والتي تم تنفيذها كجهاز حالة منسوخ [88] أعلى SCP. 5.1 نموذج دفتر الأستاذ تم تصميم دفتر الأستاذ Stellar حول تجريد الحساب (في على النقيض من مخرجات المعاملات غير المنفقة التي تركز على العملات المعدنية أو UTXO طراز Bitcoin). تتكون محتويات الدفتر من أ مجموعة من إدخالات دفتر الأستاذ من أربعة أنواع متميزة: الحسابات، وخطوط الثقة، العروض وبيانات الحساب. الحسابات هي المديرون الذين يمتلكون الأصول ويصدرونها. كل تتم تسمية الحساب بواسطة مفتاح عام. افتراضيًا، يمكن للمفتاح الخاص المقابل توقيع المعاملات الخاصة بالحساب. ومع ذلك، يمكن إعادة تكوين الحسابات لإضافة موقعين آخرين وإلغاء تخويل المفتاح الذي يُسمي الحساب، باستخدام خيار "multisig" يتطلب عدة موقعين. كل حساب يحتوي أيضًا على: رقم تسلسلي (مدرج في المعاملات لمنع الإعادة)، وبعض الأعلام، ورصيد في “أصلي” عملة مشفرة تم تعدينها مسبقًا تسمى XLM، تهدف إلى التخفيف بعض هجمات حجب الخدمة وتسهيل صناعة السوق كعملة محايدة. تقوم خطوط الثقة بتتبع ملكية الأصول المصدرة، وهي اسمه زوج يتكون من حساب الإصدار وقصير رمز الأصل (على سبيل المثال، "USD" أو "EUR"). يحدد كل خط ثقة حساب، أصل، رصيد الحساب في ذلك الأصل، أ الحد الذي لا يمكن أن يرتفع الميزان فوقه، وبعض الأعلام. يجب أن يوافق الحساب صراحةً على الاحتفاظ بالأصل من خلاله إنشاء خط ثقة، ومنع مرسلي البريد العشوائي من التسلل حسابات ذات أصول غير مرغوب فيها. تتطلب لوائح اعرف عميلك (KYC) من العديد من المؤسسات المالية معرفة الودائع التي تحتفظ بها، على سبيل المثال عن طريق التحقق من بطاقة الهوية التي تحتوي على صورة. للامتثال، يمكن للمصدرين تعيين علامة auth_reqired اختيارية على حساباتهم، مما يقيد ملكية الأصول التي يصدرونها للحسابات المعتمدة. لمنح هذا الترخيص، يقوم المصدر بتعيين معتمد وضع علامة على خطوط ثقة العملاء. تتوافق العروض مع رغبة الحساب في التداول إلى مبلغ معين من أصل معين لآخر في وقت معين السعر في دفتر الطلبات؛ تتم مطابقتها تلقائيًا و يتم ملؤها عندما تتقاطع أسعار الشراء/البيع. وأخيرًا، تتكون بيانات الحساب من الحساب والمفتاح والقيمة الثلاثية، مما يسمح لأصحاب الحساب لنشر قيم البيانات الوصفية الصغيرة. لمنع البريد العشوائي في دفتر الأستاذ، يوجد حد أدنى لرصيد XLM، يسمى الاحتياط. يزداد احتياطي الحساب مع كل منها يرتبط إدخال دفتر الأستاذ ويتناقص عند إدخال دفتر الأستاذ يختفي (على سبيل المثال، عند تنفيذ أمر ما أو إلغاؤه، أو عند أ تم حذف خط الثقة). حاليًا ينمو الاحتياطي بمقدار 0.5 XLM (∼ 0.03 دولار) لكل إدخال في دفتر الأستاذ. بغض النظر عن الاحتياطي، فهو كذلك من الممكن استعادة القيمة الكاملة للحساب عن طريق الحذف مع عملية AccountMerge. يقوم رأس دفتر الأستاذ، الموضح في الشكل 3، بتخزين السمات العامة: رقم دفتر الأستاذ، والمعلمات مثل الرصيد الاحتياطي لكل إدخال دفتر الأستاذ، hash من رأس دفتر الأستاذ السابق (في الواقع عدة hashes تشكل قائمة تخطي)، بما في ذلك إخراج SCP hash من المعاملات الجديدة المطبقة في دفتر الأستاذ هذا، hash من نتائج تلك المعاملات (على سبيل المثال، النجاح أو الفشل ل لكل منهما)، ولقطة hash لجميع إدخالات دفتر الأستاذ. نظرًا لأن اللقطة hash تشتمل على كافة محتويات دفتر الأستاذ، لا يحتاج validators إلى الاحتفاظ بالسجل للتحقق من صحة المعاملات. ومع ذلك، لتوسيع نطاق مئات الملايين من المتوقع الحسابات، لا يمكننا إعادة hash جميع جداول إدخال دفتر الأستاذ في كل منها إغلاق دفتر الأستاذ. علاوة على ذلك، ليس من العملي نقل دفتر الأستاذمدفوعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا دفتر الأستاذ # = 4 H (نطاق عالي الديناميكية السابق) مخرجات SCP ح∗(النتائج) ح∗(لقطة) ... header دفتر الأستاذ # = 5 H (نطاق عالي الديناميكية السابق) مخرجات SCP ح∗(النتائج) ح∗(لقطة) ... header . . . الشكل 3. محتويات دفتر الأستاذ. H هو SHA-256، بينما H ∗ يمثل التطبيق الهرمي أو التكراري لـ H. مخرجات SCP يعتمد أيضًا على الرأس السابق hash. إنشاء حساب إنشاء وتمويل إدخال دفتر الأستاذ الجديد للحساب دمج الحساب حذف إدخال دفتر الأستاذ الحساب خيارات الضبط تغيير علامات الحساب والموقعين الدفع ادفع كمية محددة من الأصول إلى الوجهة. com.acct. مسار الدفع مثل الدفع، ولكن الدفع في أصول مختلفة (ما يصل للحد)؛ حدد ما يصل إلى 5 أصول وسيطة إدارة العرض إنشاء/حذف/تغيير إدخال دفتر الأستاذ للعرض، -العرض السلبي مع متغير سلبي للسماح بانتشار صفر إدارة البيانات إنشاء/حذف/تغيير الحساب. إدخال دفتر البيانات تغيير الثقة إنشاء/حذف/تغيير خط الثقة السماح بالثقة قم بتعيين أو مسح العلامة المعتمدة على خط الثقة BumpSequence زيادة ما يلي. رقم على الحساب الشكل 4. عمليات دفتر الأستاذ الرئيسي بهذا الحجم في كل مرة يتم فيها قطع اتصال العقدة الشبكة لفترة طويلة جدًا. وبالتالي فإن اللقطة hash هي مصمم لتحسين كل من hashing وتسوية الحالة. على وجه التحديد، تقوم اللقطة بتقسيم إدخالات دفتر الأستاذ حسب الوقت التعديل الأخير في مجموعة من الحاويات ذات الحجم المتضاعف تسمى الدلاء. يسمى جمع الدلاء بالدلو القائمة، وتحمل بعض التشابه مع أشجار الدمج المنظمة بالسجل (أشجار-LSM) [77]. لا تتم قراءة قائمة المجموعة أثناء معالجة المعاملات (انظر القسم 5.4). ومن ثم تصميم معين يمكن تخفيف جوانب أشجار LSM. وعلى وجه الخصوص، عشوائية الوصول عن طريق المفتاح غير مطلوب، ولا تتم قراءة الدلاء إلا على الإطلاق بالتتابع كجزء من دمج المستويات. تجزئة الدلو يتم إجراء القائمة عن طريق hashing كل مجموعة أثناء دمجها وحساب تراكمي جديد hash للمجموعة hashes (صغير، الفهرس المرجعي الثابت hashes) عند كل إغلاق لدفتر الأستاذ. تتطلب تسوية قائمة المجموعة بعد قطع الاتصال التنزيل الدلاء فقط التي تختلف. 5.2 نموذج الصفقة تتكون المعاملة من حساب المصدر ومعايير الصلاحية وأ مذكرة، وقائمة واحدة أو أكثر من العمليات. يسرد الشكل 4 العمليات المتاحة. كل عملية لها حساب مصدر، والذي الافتراضيات لتلك الصفقة الشاملة. لا بد من الصفقة يتم توقيعه بواسطة المفاتيح المقابلة لكل حساب مصدر في عملية. يمكن أن تتطلب حسابات Multisig توقيعًا أعلى الوزن لبعض العمليات (مثل SetOptions) وأقل للآخرين (مثلallowTrust). المعاملات ذرية - إذا فشلت أي عملية، فلن يحدث أي منها ينفذون. وهذا يبسط الصفقات متعددة الاتجاهات. لنفترض أن يقوم المُصدر بإنشاء أصل لتمثيل سندات الأرض، ويقوم المستخدم أ يريد استبدال قطعة أرض صغيرة بالإضافة إلى 10000 دولار مقابل أ قطعة أرض أكبر يملكها B. يمكن لكلا المستخدمين التوقيع معاملة واحدة تحتوي على ثلاث عمليات: أرضان المدفوعات ودفع دولار واحد. معيار صلاحية المعاملة الرئيسي هو رقمها التسلسلي، الذي يجب أن يكون أكبر من الرقم التسلسلي للمعاملة. إدخال دفتر الأستاذ حساب المصدر. تنفيذ معاملة صالحة (بنجاح أم لا) يؤدي إلى زيادة الرقم التسلسلي، مما يمنع إعادة التشغيل. تحتوي أرقام التسلسل الأولية على دفتر الأستاذ عدد البتات العالية لمنع إعادة التشغيل حتى بعد الحذف وإعادة إنشاء الحساب. معيار الصلاحية الآخر هو الحد الاختياري للوقت يمكن تنفيذ الصفقة. العودة إلى الأرض والدولار المبادلة أعلاه، إذا قام A بتوقيع المعاملة قبل B، فلا يجوز لـ A ذلك تريد B أن يجلس على المعاملة لمدة عام قبل تقديمها عليه، وبالتالي يمكن وضع حد زمني لإبطال المعاملة بعد بضعة أيام. يمكن أيضًا تكوين حسابات Multisig لإضفاء وزن التوقيع على الكشف عن الصورة المسبقة hash، والتي، إلى جانب الحدود الزمنية، تسمح بالتداول عبر سلسلة ذرية [1]. يدفع الحساب المصدر للمعاملة رسومًا بسيطة بعملة XLM، 10−5 XLM ما لم يكن هناك ازدحام. في ظل الازدحام يتم تحديد تكلفة العمليات عن طريق المزاد الهولندي. المصادقون هم لا يتم تعويضها بالرسوم لأن validators متشابهة إلى Bitcoin العقد الكاملة، وليس عمال المناجم. بدلاً من تدمير XLM، يتم إعادة تدوير الرسوم وتوزيعها بشكل متناسب عن طريق التصويت حاملي XLM الحاليين، والذي قد يكون أو قد يكون في وقت لاحق لم تكن تستحق التعقيد. 5.3 قيم الإجماع بالنسبة لكل دفتر أستاذ، يستخدم Stellar SCP للموافقة على بنية البيانات مع ثلاثة حقول: مجموعة المعاملات hash (بما في ذلك hash) من رأس دفتر الأستاذ السابق)، في وقت قريب، ود ترقيات. عندما يتم تأكيد ترشيح قيم متعددة، يأخذ Stellar المعاملة التي تم تعيينها بأكبر عدد من العمليات (قطع العلاقات بإجمالي الرسوم، ثم مجموعة المعاملات hash)، اتحاد الكل ترقيات، وأعلى وقت إغلاق. وقت قريب هو فقط صالح إذا كان بين وقت إغلاق دفتر الأستاذ الأخير و موجودة، لذلك لا ترشح العقد أوقاتًا غير صالحة. تقوم الترقيات بضبط المعلمات العالمية مثل الرصيد الاحتياطي والحد الأدنى لرسوم التشغيل وإصدار البروتوكول. متى مجتمعة أثناء الترشيح، تحل الرسوم الأعلى وأرقام إصدار البروتوكول محل الأرقام الأقل. ترقيات تأثير الحكم من خلال مساحة صراع التصويت الفيدرالي [34]، ولا مساواة ولا مركزية. تم تكوين كل validator كـ إما الحاكم أو غير الحاكم (الافتراضي)، وفقا إلى ما إذا كان مشغلها يريد المشاركة في الحكم. تعتبر إدارة validators ثلاثة أنواع من الترقية: مطلوب وصالح وغير صالح (أي شيء لا يفعله validator
SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. validator الأساسية الأفق خ.س ديسيبل ديسيبل إرسال العميل العميل validators أخرى الشكل 5. بنية Stellar validator تعرف كيفية التنفيذ). تم تكوين الترقيات المطلوبة ل الزناد في وقت محدد، والمقصود أن يتم التنسيق فيما بينهم مشغلي. العقد الحاكمة تصوت دائمًا للترشيح المرغوب الترقيات، اقبل ولكن لا تصوت لترشيح ترقيات صالحة (أي، وافق على النصاب القانوني المحظور)، ولا تصوت لصالحه أبدًا أو قبول ترقيات غير صالحة. صدى validators غير الحاكم أي تصويت يرونه لترقية صالحة، هو في الأساس تفويض القرار بشأن الترقيات المطلوبة لأولئك الذين يختارون ذلك لدور الحكم. 5.4 التنفيذ يوضح الشكل 5 بنية Stellar validator. شيطان يُسمى Stellar-core (∼ 92 ألف سطر من C ++، دون احتساب مكتبات الطرف الثالث) ينفذ بروتوكول SCP وجهاز الحالة المنسوخ. يتطلب إنتاج قيم SCP تقليل أعداد كبيرة من إدخالات دفتر الأستاذ إلى عمليات تشفير صغيرة hashes. وعلى النقيض من ذلك، التحقق من صحة المعاملة وتنفيذها يتطلب البحث عن حالة الحساب ومطابقة الطلب في أفضل الأسعار. لخدمة كلتا الوظيفتين بكفاءة، نجمي النواة يحتفظ بتمثيلين لدفتر الأستاذ: تمثيل خارجي يحتوي على قائمة الجرافة، المخزنة كملفات ثنائية يمكن تحديثه بكفاءة وإعادة hashed بشكل تدريجي، و تمثيل داخلي في قاعدة بيانات SQL (PostgreSQL لعقد الإنتاج). Stellar- يقوم النواة بإنشاء أرشيف محفوظات للكتابة فقط يحتوي على كل مجموعة معاملات تم تأكيدها ولقطات منها دلاء. يتيح الأرشيف للعقد الجديدة أن تقوم بتمهيد نفسها عند الانضمام إلى الشبكة. كما يوفر سجلا لدفتر الأستاذ التاريخ - يجب أن يكون هناك مكان ما يمكن للمرء البحث عنه الصفقة منذ عامين. منذ التاريخ هو إلحاق فقط ولا يتم الوصول إليه بشكل متكرر، ويمكن الاحتفاظ به في أماكن رخيصة مثل Amazon Glacier أو أي خدمة تسمح بالتخزين واسترجاع الملفات المسطحة. عادةً لا يستضيف مضيفو أداة التحقق أرشيفاتهم الخاصة لتجنب أي تأثير على التحقق من الصحة الأداء من خدمة التاريخ. لإبقاء النواة النجمية بسيطة، فهي غير مخصصة للاستخدام مباشرة عن طريق التطبيقات ولا يعرض سوى واجهة ضيقة جدًا لتقديم المعاملات الجديدة. لدعم العملاء، يقوم معظم validators بتشغيل برنامج خفي يسمى Horizon (∼18k خطوط Go) التي توفر واجهة HTTP للإرسال وتعلم المعاملات . Horizon لديه حق الوصول للقراءة فقط قاعدة بيانات SQL الخاصة بـ stellar-core، مما يقلل من مخاطر الأفق زعزعة الاستقرار النجمي. يتم تنفيذ ميزات مثل العثور على مسار الدفع بالكامل في الأفق ويمكن ترقيتها من جانب واحد دون التنسيق مع validators الأخرى. العديد من البرامج الاختيارية ذات الطبقة العليا هي عملاء للأفق، مما يكمل النظام البيئي. يسهل خادم الجسر تكامل Stellar مع الأنظمة الحالية، على سبيل المثال، نشر إشعارات بجميع المدفوعات المستلمة بواسطة حساب معين. أ يوفر خادم الامتثال خطافات للمؤسسات المالية تبادل واعتماد معلومات المرسل والمستفيد بشأن المدفوعات، للامتثال لقوائم العقوبات. وأخيرا، ينفذ خادم الاتحاد تسمية يمكن قراءتها بواسطة الإنسان نظام للحسابات. 6 تجربة النشر Stellar نمت لعدة سنوات إلى دولة معتدلة عدد مشغلي العقدة الكاملة الموثوقين بشكل معقول. ومع ذلك، كانت تكوينات العقد بحيث تكون الحيوية (وإن لم تكن كذلك). السلامة) تعتمد علينا، مؤسسة Stellar التنمية (قسد)؛ لو اختفت قوات الدفاع الذاتي فجأة، مشغلي العقدة الآخرين كان سيحتاج إلى التدخل وإزالتنا يدويًا من شرائح النصاب القانوني لاستمرار الشبكة. في حين أننا والعديد من الآخرين نريد تقليل الأهمية النظامية لقوات سوريا الديمقراطية، فقد حظي هذا الهدف بأولوية متزايدة بعد ذلك قام الباحثون [58] بقياس ونشر مركزية الشبكة دون التمييز بين المخاطر على السلامة حيوية. كان رد فعل عدد من المشغلين هو إجراء تعديلات التكوين النشطة، مما أدى في المقام الأول إلى زيادة حجم طائراتهم شرائح النصاب القانوني في محاولة لتخفيف أهمية قوات سوريا الديمقراطية؛ ومن المفارقات أن هذا أدى فقط إلى زيادة المخاطر على الحيوية. مشكلتان أدت إلى تفاقم الوضع. أولا شعبية تم استخدام أداة مراقبة Stellar التابعة لجهة خارجية [5] بشكل منهجي المبالغة في تقدير وقت تشغيل validator من خلال عدم التحقق فعليًا كان ذلك النواة النجمية يعمل؛ هذا يقود الناس إلى تضمين العقد غير الموثوقة في شرائح النصاب القانوني الخاصة بهم. ثانياً: خطأ في يُقصد بالنواة النجمية بمجرد انتقال validator إلى دفتر الأستاذ التالي، لم يساعد العقد المتبقية بشكل كافٍ في إكمال العقد السابقدفتر الأستاذ في حالة فقدان الرسائل. ونتيجة لذلك، شهدت الشبكة 67 دقيقة من التوقف وكانت مطلوبة التنسيق اليدوي بواسطة مسؤولي validator لإعادة التشغيل. والأسوأ من ذلك، أثناء محاولة إعادة تشغيل الشبكة، أدت عمليات إعادة التكوين السريعة المتزامنة على عقد متعددة في تكوين خاطئ جماعي سمح لبعض العقد بذلك تتباعد، مما يتطلب الإغلاق اليدوي لتلك العقد و إعادة تقديم المعاملات المقبولة أثناء الاختلاف. ولحسن الحظ، تم اكتشاف هذا الاختلاف وتصحيحه بسرعة ولم تحتوي على أي معاملات متضاربة، ولكن خطر فشل الشبكة في التمتع بتقاطع النصاب القانوني— الانقسام مع الاستمرار في قبول التضارب المحتمل المعاملات، وذلك ببساطة بسبب التكوين الخاطئ ملموسة جدا من هذا الحادث. أدت مراجعة هذه التجارب إلى استنتاجين رئيسيين والإجراءات التصحيحية المقابلة.مدفوعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا حرجة 100% 51% 51% عالية 67% 51% متوسطة 67% 51% منخفض، 67% 51% 51% ... ... ... 51% ... 51% الشكل 6. التسلسل الهرمي لجودة المدقق. أعلى جودة العقد تتطلب الحد الأعلى وهو 100%، في حين يتم ضبط الجودة الأدنى على عتبة 67%. العقد داخل واحدة تتطلب المنظمة أغلبية بسيطة بنسبة 51٪. 6.1 تعقيد التكوين وهشاشته Stellar يعبر عن شرائح النصاب كمجموعات نصاب متداخلة تتكون من n إدخالات وعتبة k حيث توجد أي مجموعة من إدخالات k يشكل شريحة النصاب القانوني. كل من الإدخالات n هو إما validator مفتاح عام أو، بشكل متكرر، مجموعة نصاب أخرى. وعلى الرغم من مرونتنا وصغر حجمنا، فقد حققنا النصاب القانوني المتداخل أتاحت المجموعات في الوقت نفسه لمشغلي العقد مرونة كبيرة جدًا وقليلًا جدًا من التوجيه: كان من السهل كتابة ملفات غير آمنة (أو حتى لا معنى لها) التكوينات. معايير التجميع العقد إلى مجموعات، لتنظيم المجموعات الفرعية في تسلسل هرمي، و لاختيار العتبات كلها كانت غير واضحة بما فيه الكفاية وساهمت في الفشل التشغيلي. ولم يكن من الواضح ما إذا كان الأمر كذلك التعامل مع "المستوى" في التسلسل الهرمي المتداخل كمستوى ثقة، أو منظمة، أو كليهما؛ العديد من التكوينات في هذا المجال اختلطت هذه المفاهيم، بالإضافة إلى تحديد الخطورة أو عتبات لا معنى لها. ولذلك أضفنا آلية تكوين أبسط الذي يفصل بين جانبين من مجموعات النصاب المتداخلة: التجميع العقد معًا حسب المؤسسة، وتصنيف كل مؤسسة بتصنيف ثقة بسيط (منخفض، متوسط، مرتفع، أو حرجة). مطلوب من المنظمات ذات المستوى الأعلى وما فوق ذلك نشر أرشيف التاريخ. يقوم النظام الجديد بتجميع مجموعات النصاب المتداخلة التي يتم فيها تمثيل كل مؤسسة كـ تم تحديد عتبة 51%، ويتم تجميع المنظمات في مجموعات بحدود 67% أو 100% (حسب جودة المجموعة). كل مجموعة عبارة عن إدخال واحد في المجموعة التالية (الأعلى جودة)، كما هو موضح في الشكل 6. هذا النموذج المبسط يقلل من احتمالية التكوين الخاطئ، سواء من حيث الهيكل من المجموعات المتداخلة المركبة والعتبات المختارة كل مجموعة. 6.2 الكشف الاستباقي عن التكوين الخاطئ ثانياً، أدركنا أن اكتشاف سوء التشكيل الجماعي من خلال الانتظار لملاحظة آثاره السلبية قد فات الأوان. خاصة فيما يتعلق بالتكوينات الخاطئة التي يمكن أن تتباعد — أ وضع فشل أكثر خطورة من التوقف — احتياجات الشبكة لتكون قادرًا على اكتشاف التكوين الخاطئ على الفور حتى يتمكن المشغلون من التراجع عنه قبل حدوث أي اختلاف فعليًا. لتلبية هذه الحاجة، قمنا ببناء آلية في برنامج validator تعمل بشكل مستمر على جمع حالة التكوين الجماعية لجميع النظراء في الإغلاق المتعدي للعقدة وتكتشف احتمالية الاختلاف، أي الانفصال النصاب القانوني – ضمن هذا التكوين الجماعي. 6.2.1 التحقق من تقاطع النصاب القانوني على الرغم من أن جمع شرائح النصاب أمر سهل، إلا أن العثور على النصاب المنفصل فيما بينها يعد أمرًا صعبًا [62]. ومع ذلك، اعتمدنا مجموعة من الاستدلالات الخوارزمية وقواعد حذف الحالات اقترحه Lachowski [62] للتحقق من الحالات النموذجية من المشكلة عدة أوامر من حيث الحجم أسرع من تكلفة أسوأ الحالات. من الناحية العملية، الشبكة الحالية تكون عمليات الإغلاق الانتقالية لشريحة النصاب في حدود 20-30 العقد، وباستخدام تحسينات Lachowski، يتم التحقق عادةً في غضون ثوان على وحدة المعالجة المركزية واحدة. إذا دعت الحاجة لتعزيز الأداء، يمكننا موازاة البحث. 6.2.2 التحقق من التكوينات الخطرة يعد اكتشاف أن الشبكة تقبل النصاب القانوني المنفصل بمثابة خطوة في الاتجاه الصحيح، لكنه يشير إلى الخطر في وقت متأخر بشكل غير مريح لمثل هذه القضية الحرجة. من الناحية المثالية، نريد أن يتلقى مشغلو العقد تحذيرات عند التكوين الجماعي للشبكة يقترب فقط من حالة محفوفة بالمخاطر. ولذلك قمنا بتوسيع مدقق تقاطع النصاب القانوني للكشف عن حالة نسميها الحرجية: عندما يكون التيار التكوين الجماعي هو تكوين خاطئ واحد بعيدا عن دولة تقبل النصاب القانوني المنفصل. للكشف عن الأهمية، يقوم المدقق باستبدال تكوين كل مؤسسة بشكل متكرر بمحاكاة تكوين خاطئ لأسوأ الحالات إعادة تشغيل مدقق تقاطع النصاب الداخلي على النتيجة. في حالة وجود أي خطأ فادح في التكوين على بعد خطوة واحدة من الحالة الحالية، يصدر البرنامج تحذيرًا و تقارير المنظمة التي تشكل خطر التكوين الخاطئ. تمنح هذه التغييرات مجتمع المشغلين طبقتين من الإشعار والتوجيه للعزل ضد أسوأ الأشكال من سوء التكوين الجماعي
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 المهلات؟ • هل يظل زمن الاستجابة لتحديث الإجماع ودفتر الأستاذ مستقلاً عن عدد الحسابات؟SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. • كيف تتأثر فترات الاستجابة بزيادة (أ) المعاملات في الثانية (وبالتالي المعاملات في كل ثانية). دفتر الأستاذ)، و(ب) عدد العقد validator؟ • ما هي تكلفة تشغيل العقدة من حيث وحدة المعالجة المركزية، الذاكرة وعرض النطاق الترددي للشبكة؟ تتمتع شبكات الدفع بمعدلات معاملات منخفضة مقارنة إلى أنواع أخرى من النظام الموزع. الرائدة blockchains، Bitcoin وEthereum، تأكيد ما يصل إلى 15 معاملة في الثانية، أقل من Stellar. علاوة على ذلك، تستغرق هذه الأنظمة دقائق ساعة لتأكيد المعاملة بشكل آمن، لأن إثبات العمل يتطلب الانتظار حتى يتم تعدين عدة كتل. ال بلغ متوسط شبكة غير blockchain SWIFT 420 معاملة في الثانية فقط في يوم الذروة [14]. لذلك اخترنا لمقارنة قياساتنا مع هدف الـ 5 ثواني الفاصل الزمني دفتر الأستاذ، وهو هدف أكثر عدوانية. تظهر نتائجنا أن زمن الوصول أقل من هذا الحد بشكل مريح حتى مع العديد من التحسينات غير المنفذة لا تزال قيد التنفيذ. 7.1 المراسي تشمل الأصول الأكثر تداولًا من حيث الحجم العملة (على سبيل المثال، 3 دولارات أمريكية المرساة، 2 يوان صيني)، المرساة Bitcoin، والأمان المدعوم بالعقارات token [92]، والعملة داخل التطبيق [8]. المراسي المختلفة لها سياسات مختلفة. على سبيل المثال، مرساة واحدة بالدولار الأمريكي، Stronghold، يقوم بتعيين auth_reqired ويتطلب عملية معرفة عميلك (KYC) لكل حساب يحتفظ به الأصول. آخر، AnchorUSD، يتيح لأي شخص الاستلام والتداول الدولار الأمريكي (مما يجعل من الممكن حرفيًا إرسال 0.50 دولارًا إلى المكسيك في 5 ثواني برسوم قدرها 0.000001 دولار). ومع ذلك، مرساةUSD يتطلب KYC ورسومًا لشراء أو استرداد الدولار الأمريكي مع التحويلات البرقية التقليدية. في الفلبين حيث تعتبر اللوائح المصرفية أكثر مرونة فيما يتعلق بالمدفوعات الواردة، والعملات المعدنية يدعم صرف PHP من أي ماكينة صراف آلي [36]. بالإضافة إلى الأمان المذكور أعلاه token والعملة داخل التطبيق، هناك مجموعة من العملات غير token تتراوح من السندات التجارية [22] وأرصدة الكربون [85، 96] وأكثر الأصول الباطنية مثل token التحفيز التعاوني استعادة ملكية السيارة [35]. 7.2 شبكة عامة حتى كتابة هذه السطور، هناك 126 عقدة كاملة نشطة، 66 منها المشاركة في الإجماع من خلال التوقيع على رسائل التصويت. الشكل 7 (تم إنشاؤه بواسطة [5]) يصور الشبكة، مع وجود خط بينهما عقدتان إذا ظهرت إحداهما في شرائح النصاب القانوني للأخرى و أ خط أزرق غامق لإظهار الاعتماد ثنائي الاتجاه. في المركز عبارة عن مجموعة من 17 "المستوى الأول validators" بحكم الأمر الواقع يديرها SDF، وSatoshiPay، وLOBSTR، وCOINQVEST، وKeybase. قبل أربعة أشهر، قبل أحداث القسم السادس، هناك كانت هناك 15 عقدة ذات أهمية نظامية: 3 منها على ما يبدو منظمات من المستوى الأول والعديد من المفردات العشوائية. ال بدا الرسم البياني أيضًا أقل انتظامًا. ومن ثم، تظهر آلية التكوين الجديدة و/أو قرارات المشغل الأفضل للمساهمة في طوبولوجيا الشبكة الأكثر صحة. بدون موارد مالية كبيرة (والمساهمين المقابلين الشكل 7. خريطة شريحة النصاب القانوني الالتزامات)، كان من الصعب تعيين 5 الطبقة الأولى لكن المنظمات منذ البداية. وهذا يشير إلى النصاب القانوني تلعب الشرائح دورًا مفيدًا في تمهيد الشبكة: يمكن لأي شخص ذلك انضم بهدف أن تصبح لاعبًا مهمًا بسبب لا يوجد حراس على الاتفاق الزوجي. يوجد حاليًا أكثر من 3.3 مليون حساب في دفتر الأستاذ. انتهى خلال فترة 24 ساعة الأخيرة، بلغ متوسط Stellar 4.5 معاملة و 15.7 عملية في الثانية. مراجعة دفاتر الأستاذ الأخيرة، أكثر يبدو أن المعاملات لديها عملية واحدة، في حين أن كل عدد قليل دفاتر الأستاذ نرى المعاملات التي تحتوي على العديد من العمليات التي يبدو أنها تأتي من صانعي السوق الذين يديرون العروض. ال متوسط الأوقات لتحقيق الإجماع وتحديث دفتر الأستاذ كان 1061 مللي ثانية و 46 مللي ثانية على التوالي. وكانت النسب المئوية 99 2252 مللي ثانية و142 مللي ثانية (يعكس الأول مهلة مدتها ثانية واحدة في اختيار زعيم الترشيح). لاحظ أن أداء SCP هو معظمها مستقلة عن المعاملات في الثانية الواحدة، منذ SCP يوافق على hash من العديد من المعاملات بشكل تعسفي. من المرجح أن تنشأ الاختناقات من نشر المرشح المعاملات أثناء الترشيح والتنفيذ والمصادقة المعاملات، ودمج الدلاء. لم نحتاج بعد لموازاة معالجة المعاملات الخاصة بـ Stellar-core عبر عدة مراكز لوحدة المعالجة المركزية أو محركات الأقراص. قمنا أيضًا بتقييم عدد رسائل SCP التي يتم بثها على شبكة الإنتاج. في الحالة العادية مع واحد الزعيم المنتخب لترشيح قيمة، نتوقع سبعة منطقية الرسائل التي سيتم بثها: رسالتان للتصويت والقبول نوميبيان نيت، رسالتين للقبول والتأكيد بيان إعداد، رسالتين للقبول والتأكيد بيان الالتزام، وأخيرا، رسالة خارجية (تم إرساله بعد الالتزام بدفتر أستاذ جديد على القرص لمساعدة المتطرفين اللحاق). يجمع التنفيذ بين تأكيد الالتزام وإضفاء الطابع الخارجي على الرسائل كتحسين، لأنه كذلك من الآمن إضفاء الطابع الخارجي على القيمة بعد الالتزام بها. نقوم بعد ذلك بتحليل المقاييس المجمعة على الإنتاج Stellar validator. انتهى على مدار 68 ساعة، تم بث 1.3 رسالة في الثانية، بمتوسط 6-7 رسائل لكل دفتر. ونلاحظ أن المجموع
مدفوعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا المئوي عدد المهلات الترشيح الاقتراع 75% 0 0 99% 1 0 ماكس 4 1 الشكل 8. المهلة لكل دفتر الأستاذ أكثر من 68 ساعة عدد الرسائل التي يتم بثها بواسطة validators أكبر، منذ عام بالإضافة إلى رسائل التصويت الموحد، يتم أيضًا بث العقد أي معاملات يتعلمون عنها. ويبين الشكل 8 المهلات التي يمر بها الإنتاج validator خلال فترة 68 ساعة. مهلة الترشيح هي وهو مقياس لمدى (عدم) فعالية وظيفة انتخاب القائد، في حين أن مهلة الاقتراع تعتمد بشكل كبير على الشبكة والتأخير المحتمل للرسائل. المهلات متسقة مع عدد الرسائل المرسلة: ستة رسائل في أفضل السيناريوهات، وسبع رسائل على الأقل إذا كانت هناك حاجة إلى جولة ترشيح إضافية. 7.3 التجارب الخاضعة للرقابة أجرينا تجارب مضبوطة في حاويات معبأة مثيلات Amazon EC2 c5d.9xlarge مع 72 جيجابايت من ذاكرة الوصول العشوائي، 900 جيجابايت من NVMe SSD و36 وحدة معالجة مركزية افتراضية. كل مثيل كان في نفس منطقة EC2 وكان لها عرض نطاق ترددي ثابت يبلغ 10 جيجابت في الثانية. استخدمنا SQLite كمتجر. (Stellar يدعم أيضًا PostgreSQL، ولكن هذا يحتوي على مهام غير متزامنة تضخ الضوضاء في القياسات.) يوفر Stellar استعلامًا مدمجًا في وقت التشغيل، وإنشاء التحميل، الذي يسمح بتوليد حمل اصطناعي على هدف محدد المعاملة/المعدل الثاني. على الرغم من أن Stellar يدعم العديد من ميزات التداول، مثل دفتر الطلبات ومسار الأصول المشتركة المدفوعات، ركزنا على المدفوعات البسيطة. يتكون تأكيد المعاملات من خطوات متعددة، لذلك نحن سجلت القياسات لكل مما يلي: • الترشيح: الوقت منذ الترشيح وحتى الإعداد الأول • الاقتراع: الوقت من الإعداد الأول إلى التأكيد ارتكبت الاقتراع • تحديث دفتر الأستاذ: حان الوقت لتطبيق القيمة المتفق عليها • عدد المعاملات: المعاملات المؤكدة لكل دفتر الأستاذ تم تعريف كل تجربة من تجاربنا من خلال ثلاث معلمات: عدد إدخالات الحساب في دفتر الأستاذ، ومبلغ التحميل (في شكل دفعات XLM) المقدمة في الثانية، وعدد validators. قمنا بتكوين كل validator لمعرفة المزيد عن كل validator (السيناريو الأسوأ بالنسبة إلى SCP)، مع تعيين شرائح النصاب القانوني على أي أغلبية بسيطة من العقد (بسبب زيادة عدد النصاب القانوني المختلفة). خط الأساس تم قياس تجربتنا الأساسية بـ Stellar بـ 100000 حساب، وأربعة validators، وتوليد التحميل معدل 100 معاملة / ثانية. لقد لاحظنا 507 معاملة لكل دفتر أستاذ في المتوسط، مع انحراف معياري قدره 49 (9.7%). لاحظ أنه لم يتم إسقاط أية معاملات؛ الطفيف 105 106 107 0 500 1000 1500 2000 الحسابات الكمون [مللي ثانية] تحديث دفتر الأستاذ الاقتراع الترشيح الشكل 9. الكمون مع زيادة عدد الحسابات يرجع التباين إلى قيود الجدولة الخاصة بمولد الحمل. لاحظنا أن عدد المعاملات لكل دفتر الأستاذ كان متسقًا مع معدل توليد التحميل لدينا، نظرًا لدفتر الأستاذ إغلاق كل 5 ثواني الترشيح والاقتراع وسجل الأستاذ أظهر التحديث متوسط زمن الوصول 82.53 مللي ثانية، 95.96 مللي ثانية، و 174.08 مللي ثانية، على التوالي. لاحظنا أن الكمون الترشيح النسبة المئوية 99 دائمًا أقل من 61 مللي ثانية، مع بعض الأحيان طفرات مدتها ثانية واحدة تقريبًا، تتوافق مع الخطوة الأولى في وظيفة المهلة لاختيار القائد. وبالنظر إلى الأداء الأساسي، نظرنا إلى التأثيرات من تغيير كل من معلمات إعداد الاختبار. الحسابات تشير البيانات الواردة في الشكل 9 إلى أن المقياس Stellar وكذلك عدد الحسابات يزيد. جيل الاختبار أصبحت الحسابات عملية طويلة، حيث أن إنشاء الدلو و لقد منعنا الدمج من ملء قاعدة البيانات ببساطة مع الحسابات مباشرة عبر SQL. ولذلك، أجرينا لدينا تجارب لما يصل إلى 50,000,000 حساب. في حين أن هناك الحد الأدنى من التأثير على الإجماع وزمن وصول تحديث دفتر الأستاذ، نلاحظ أن زيادة الحسابات تؤدي إلى زيادة في النفقات العامة دمج الدلاء، والتي تصبح أكبر. معدل المعاملة يؤثر معدل المعاملة على المبلغ حركة البث المتعدد بين validators، وعدد المعاملات المضمنة في كل دفتر أستاذ، وحجم المستوى الأعلى دلاء. لفهم آثار زيادة المعاملات التحميل، أجرينا تجربة على 100000 حساب و4 validators. ويبين الشكل 10 النمو البطيء في زمن الوصول المتفق عليه، بينما تم قضاء معظم الوقت في تحديث دفتر الأستاذ. ليس من المستغرب أنه مع زيادة حجم مجموعة المعاملات، فإنه يستغرق وقتًا أطول لربطه بقاعدة البيانات. ونلاحظ ذلك أيضا يعتمد زمن استجابة تحديث دفتر الأستاذ بشكل كبير على التنفيذ، ويتأثر باختيار قاعدة البيانات. عقد التحقق من الصحة لمعرفة كيفية زيادة عدد tierone validatorsيؤثر على الأداء، أجرينا التجارب مع 100000 حساب، و100 معاملة في الثانية، وعدد متفاوت من validators من 4 إلى 43. ظهرت جميع validators في جميع شرائح النصاب القانوني لـ validators؛ سوف شرائح النصاب أصغر لها تأثير أقل على الأداء.SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا لوخافا وآخرون. 100 150 200 250 300 350 0 500 1000 1500 2000 تحميل [المعاملات/الثانية] الكمون [مللي ثانية] تحديث دفتر الأستاذ الاقتراع الترشيح الشكل 10. زمن الوصول مع زيادة حمل المعاملات 10 20 30 40 0 500 1000 1500 2000 المدققون الكمون [مللي ثانية] تحديث دفتر الأستاذ الاقتراع الترشيح الشكل 11. الكمون مع زيادة عدد العقد تغيير عدد عقد التحقق على الشبكة يؤثر أيضًا على عدد رسائل SCP المتبادلة عدد القيم المحتملة أثناء الترشيح. الشكل 11 يُظهر أن وقت الترشيح ينمو بمعدل صغير نسبيًا. وفي حين تشير البيانات إلى أن الاقتراع هو عنق الزجاجة، فإننا نعتقد أنه يمكن معالجة العديد من مشكلات التوسع من خلال التحسين شبكة Stellar المتراكبة لتحسين حركة مرور الشبكة. كما المتوقع، ظل زمن استجابة تحديث دفتر الأستاذ مستقلاً عن عدد العقد. سعر الإغلاق أخيرًا، أردنا قياس أداء Stellar الشامل من خلال قياس عدد مرات تأكيد دفاتر الأستاذ وما إذا كان Stellar يحقق هدفه البالغ 5 ثوانٍ دون إسقاط أي معاملات. لاحظنا إغلاق دفتر الأستاذ المتوسط مرات 5.03 ثانية و 5.10 ثانية و 5.15 ثانية مع زيادة الحساب الإدخالات ومعدل المعاملات وعدد العقد على التوالي. تشير النتائج إلى أن Stellar يمكنه إغلاق دفاتر الأستاذ باستمرار تحت حمولة عالية. 7.4 تشغيل validator إحدى الميزات المهمة لـ Stellar هي التكلفة المنخفضة تشغيل validator، حيث يجب تشغيل المراسي (أو التعاقد معها) validators لفرض النهاية. يقوم SDF بتشغيل 3 وحدات إنتاج validator، جميعها على مثيلات c5.large AWS، والتي تحتوي على مركزين، 4 غيغابايت من ذاكرة الوصول العشوائي ووحدة المعالجة المركزية Intel (R) Xeon (R) Platinum 8124M معالجات بسرعة 3.00 جيجا هرتز. فحص استخدام الموارد على واحد من هذه الأجهزة، لاحظنا استخدام عملية Stellar حوالي 7% من وحدة المعالجة المركزية و300 ميجابايت من الذاكرة. من حيث حركة مرور الشبكة، مع 28 اتصالاً بالأقران وحجم النصاب القانوني من 34، كانت معدلات الدخول والخروج 2.78 ميجابت/ثانية و 2.56 ميجابت/ثانية، على التوالي. الأجهزة المطلوبة لتشغيل مثل هذا العملية غير مكلفة. في حالتنا، تبلغ التكلفة 0.054 دولارًا في الساعة أو حوالي 40 دولارًا في الشهر. 7.5 العمل المستقبلي تشير هذه التجارب إلى أن Stellar يمكنه بسهولة التوسع في طلب واحد أو أمرين بحجم يتجاوز استخدام الشبكة اليوم. لأن لقد كانت متطلبات الأداء متواضعة جدًا حتى الآن، Stellar يترك مجالًا للعديد من التحسينات المباشرة باستخدام تقنيات معروفة. على سبيل المثال، المعاملات وSCP يتم بث الرسائل بواسطة validators باستخدام فيضان ساذج بروتوكول، ولكن يجب أن يستخدم بشكل مثالي أكثر كفاءة وتنظيما البث المتعدد من نظير إلى نظير [30]. بالإضافة إلى ذلك، قاعدة بيانات ثقيلة يمكن تحسين وقت تحديث دفتر الأستاذ من خلال تقنيات التجميع والجلب المسبق القياسية.
Çö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
خاتمة
المدفوعات الدولية باهظة الثمن وتستغرق أيامًا. الصندوق تمر الحضانة عبر مؤسسات مالية متعددة بما في ذلك البنوك المراسلة وخدمات تحويل الأموال. لأن كل قفزة يجب أن تكون موثوقة تماما، فمن الصعب على الجديد الداخلين للحصول على حصة في السوق والمنافسة. Stellar يظهر كيفية إرسال الأموال حول العالم بسعر رخيص في ثواني. ال الابتكار الرئيسي هو بروتوكول اتفاقية بيزنطية جديد مفتوح العضوية، SCP، الذي يعزز بنية نظير إلى نظير للشبكة المالية لتحقيق توافق عالمي في الآراء بموجب أ فرضية الإنترنت الجديدة. يتيح SCP لـ Stellar الالتزام ذريًا معاملات لا رجعة فيها عبر المشاركين التعسفيين الذين لا يعرفون أو يثقون ببعضهم البعض. وهذا بدوره يضمن للداخلين الجدد الوصول إلى نفس الأسواق القائمة اللاعبين، يجعلها آمنة للحصول على أفضل تبادل متاح أسعار حتى من صناع السوق غير موثوق بهم، وبشكل كبير يقلل من زمن الوصول للدفع. شكر وتقدير Stellar لن يكون حيث هو اليوم دون المبكر قيادة جويس كيم أو المساهمات الهائلة لـ سكوت فليكنشتاين وبارتيك نوفوتارسكي في البناء و الحفاظ على الأفق، وStellar SDK، والأجزاء الرئيسية الأخرى للنظام البيئي Stellar. ونشكر أيضًا كولتن بيرجيرون، هنري كوريجان جيبس، كانديس كيلي، كابيل ك. جاين، بوريس ريزنيكوف، جيريمي روبن، كريستيان رودر، إريك سوندرز، تورستن ستوبر، تومر ويلر، المراجعون المجهولون، و راعيتنا جوستين شيري على تعليقاتها المفيدة المسودات السابقة. إخلاء المسؤولية وكانت مساهمة البروفيسور مازيير في هذا المنشور بمثابة مستشار مدفوع الأجر، ولم تكن جزءًا منه واجبات أو مسؤوليات جامعة ستانفورد.
دفعات عالمية سريعة وآمنة باستخدام Stellar SOSP '19، 27-30 أكتوبر 2019، هانتسفيل، أونتاريو، كندا