Stellar Konsensüs Protokolü

โดย David Mazières · 2015

🇺🇸 English (ต้นฉบับ)

🇹🇷 Türkçe (คำแปล)

บทคัดย่อ

การชำระเงินระหว่างประเทศนั้นช้าและมีราคาแพง ส่วนหนึ่งเป็นเพราะการกำหนดเส้นทางการชำระเงินแบบหลายฮอปผ่านต่างกัน ระบบธนาคาร Stellar คือเครือข่ายการชำระเงินระดับโลกแห่งใหม่ ที่สามารถโอนเงินดิจิทัลได้โดยตรงทุกที่ใน โลกในไม่กี่วินาที นวัตกรรมที่สำคัญคือการทำธุรกรรมที่ปลอดภัย กลไกข้ามตัวกลางที่ไม่น่าเชื่อถือโดยใช้กลไกใหม่ โปรโตคอลข้อตกลงไบแซนไทน์ที่เรียกว่า SCP ด้วย SCP แต่ละตัว สถาบันระบุสถาบันอื่นที่จะยังคงอยู่ ในข้อตกลง; ผ่านการเชื่อมโยงระหว่างกันทั่วโลกของ ระบบการเงินทั้งเครือข่ายจึงตกลงกันแบบอะตอมมิก ธุรกรรมที่ครอบคลุมสถาบันต่างๆ โดยพลการ โดยไม่มีความเสี่ยงในการละลายหรืออัตราแลกเปลี่ยนจากผู้ออกสินทรัพย์ตัวกลาง หรือผู้ดูแลสภาพคล่อง เรานำเสนอแบบจำลอง ระเบียบวิธี และ การตรวจสอบอย่างเป็นทางการ อธิบายเครือข่ายการชำระเงิน Stellar และสุดท้ายประเมิน Stellar เชิงประจักษ์ผ่านการวัดประสิทธิภาพ และประสบการณ์ของเราในการใช้งานการผลิตเป็นเวลาหลายปี แนวคิดของซีซีเอส • ความปลอดภัยและความเป็นส่วนตัว →กระจาย ความปลอดภัยของระบบ • การจัดระบบคอมพิวเตอร์ → สถาปัตยกรรมแบบเพียร์ทูเพียร์ • ระบบสารสนเทศ → การโอนเงินทางอิเล็กทรอนิกส์ คำหลัก blockchain, BFT องค์ประชุม การชำระเงิน รูปแบบการอ้างอิง ACM: มาร์ตา โลคาวา, จูเลียโน โลซา, เดวิด มาซิแยร์, เกรย์ดอน ฮวาเร, นิโคลัส แบร์รี่, เอไล กาฟนี่, โจนาธาน โจฟ, ราฟาเอล มาลินอฟสกี้, เจด แม็กคาเลบ 2019 การชำระเงินทั่วโลกที่รวดเร็วและปลอดภัยด้วย Stellar ใน SOSP ’62: การประชุมสัมมนาเรื่องหลักการระบบปฏิบัติการ วันที่ 27–30 ตุลาคม 2019 ฮันต์สวิลล์ ON แคนาดา ACM, นิวยอร์ก, NY, สหรัฐอเมริกา, 17 หน้า https://doi.org/10.1145/3341301.3359636

Özet

Uluslararası ödemeler yavaş ve pahalıdır; bunun nedeni kısmen, heterojen ödemeler üzerinden çok duraklı ödeme yönlendirmesidir. bankacılık sistemleri. Stellar yeni bir küresel ödeme ağıdır dijital parayı dünyanın herhangi bir yerine doğrudan aktarabilen saniyeler içinde dünya. En önemli yenilik güvenli bir işlemdir güvenilmeyen aracılar arasında yeni bir mekanizma kullanarak Bizans anlaşma protokolüne SCP denir. SCP ile her biri kurum kalacağı diğer kurumları belirtir anlaşarak; küresel birbirine bağlılığı sayesinde finansal sistem, tüm ağ daha sonra atomik aracı varlık ihraççılarından kaynaklanan ödeme gücü veya döviz kuru riski olmayan, keyfi kurumları kapsayan işlemler veya piyasa yapıcılar. SCP'nin modelini, protokolünü ve resmi doğrulama; Stellar ödeme ağını açıklayın; ve son olarak Stellar'yi karşılaştırmalar yoluyla ampirik olarak değerlendirin ve birkaç yıllık üretim kullanımı deneyimimiz. CCS Konseptleri • Güvenlik ve gizlilik →Dağıtılmış sistem güvenliği; • Bilgisayar sistemleri organizasyonu → Eşler arası mimariler; • Bilgi sistemleri → Elektronik fon transferi. Anahtar Kelimeler blockchain, BFT, yetersayılar, ödemeler ACM Referans Formatı: Marta Lokhava, Giuliano Losa, David Mazières, Graydon Hoare, Nicolas Barry, Eli Gafni, Jonathan Jove, Rafał Malinowsky, Jed McCaleb. 2019. Stellar ile hızlı ve güvenli küresel ödemeler. SOSP'de '19: İşletim Sistemleri İlkeleri Sempozyumu, 27–30 Ekim, 2019, Huntsville, ON, Kanada. ACM, New York, NY, ABD, 17 sayfa. https://doi.org/10.1145/3341301.3359636

การแนะนำ

การชำระเงินระหว่างประเทศช้ามากและมีค่าใช้จ่ายสูง [32] พิจารณาความไม่สามารถทำได้จริงในการส่งเงิน $0.50 จากสหรัฐอเมริกาไปที่ *กาลอยส์ อิงค์ †ยูซีแอลเอ อนุญาตให้จัดทำสำเนาดิจิทัลหรือสำเนาของงานนี้ทั้งหมดหรือบางส่วนเพื่อ อนุญาตให้ใช้ส่วนตัวหรือในชั้นเรียนโดยไม่มีค่าธรรมเนียม โดยที่ไม่ต้องทำสำเนา จัดทำหรือแจกจ่ายเพื่อหากำไรหรือข้อได้เปรียบทางการค้าและมีสำเนาดังกล่าว ประกาศนี้และการอ้างอิงฉบับเต็มในหน้าแรก ลิขสิทธิ์สำหรับส่วนประกอบ งานนี้ต้องเป็นของบุคคลอื่นที่ไม่ใช่ ACM จะต้องได้รับเกียรติ นามธรรมด้วย เครดิตได้รับอนุญาต หากต้องการคัดลอกหรือเผยแพร่ซ้ำเพื่อโพสต์บนเซิร์ฟเวอร์หรือไปที่ แจกจ่ายไปยังรายการ ต้องได้รับอนุญาตเฉพาะล่วงหน้าและ/หรือมีค่าธรรมเนียม คำขอ สิทธิ์จาก [email protected] SOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา © 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], ซึ่งซ้ำเติมด้วยเทคโนโลยีที่ไม่มีประสิทธิภาพ คนไหน. สามารถสร้างสรรค์สิ่งใหม่ๆ ได้ ราคาและเวลาในการตอบสนองลดลง ตัวอย่างเช่น การโอนเงินจากบัญชีธนาคารในไตรมาสที่ 2 ปี 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, Huntsville, ON, แคนาดา โลกาวา และคณะ บรรลุเป้าหมาย 1 และ 3 ในการขุด blockchains ที่โดดเด่นที่สุดในรูปแบบของ ERC20 tokens บน Ethereum [3] แนวคิดหลักของ blockchains เหล่านี้คือการสร้างสกุลเงินดิจิทัลใหม่เพื่อใช้เป็นรางวัลแก่ผู้คนสำหรับการตั้งถิ่นฐาน ธุรกรรมที่ยากต่อการย้อนกลับ ขออภัย ซึ่งหมายความว่าผู้ออก token ไม่ได้ควบคุมการทำธุรกรรมขั้นสุดท้าย ถ้าเป็นซอฟต์แวร์ ข้อผิดพลาดทำให้ประวัติการทำธุรกรรมถูกจัดระเบียบใหม่ [26, 73] หรือเมื่อริบมาจากคนฉ้อโกงเกินราคา การจัดระเบียบประวัติศาสตร์ใหม่ [74, 97] ผู้ออกอาจต้องรับผิดชอบต่อ tokens พวกเขาได้แลกเป็นเงินในโลกแห่งความเป็นจริงแล้ว Stellar blockchain มีคุณสมบัติที่แตกต่างสองประการ ประการแรก สนับสนุนตลาดที่มีประสิทธิภาพโดยกำเนิดระหว่าง tokens จากผู้ออกบัตรที่แตกต่างกัน โดยเฉพาะ ใครๆ ก็สามารถออก token, blockchain มีสมุดคำสั่งซื้อในตัวสำหรับการซื้อขายระหว่างคู่ tokens ใดๆ และผู้ใช้สามารถออกการชำระเงินตามเส้นทางได้ ที่มีการซื้อขายแบบอะตอมมิกในหลายคู่สกุลเงินในขณะนั้น รับประกันราคาจำกัดตั้งแต่ต้นจนจบ ประการที่สอง Stellar แนะนำข้อตกลงไบเซนไทน์ใหม่ โปรโตคอล SCP (Stellar โปรโตคอลฉันทามติ) ซึ่งผ่านทางนั้น token ผู้ออกกำหนดเซิร์ฟเวอร์ validator เฉพาะเพื่อบังคับใช้ การทำธุรกรรมขั้นสุดท้าย ตราบใดที่ไม่มีใครประนีประนอม validators ของผู้ออก (และลายเซ็นดิจิทัลที่เกี่ยวข้องและ การเข้ารหัสลับ hashes ยังคงปลอดภัย) ผู้ออกจะทราบแน่ชัดว่าธุรกรรมใดเกิดขึ้นและหลีกเลี่ยงความเสี่ยง ของการสูญเสียจากการปรับโครงสร้างประวัติศาสตร์ blockchain แนวคิดหลักของ SCP คือผู้ออกสินทรัพย์ส่วนใหญ่ได้รับประโยชน์จาก ตลาดที่มีสภาพคล่องและต้องการอำนวยความสะดวกในการทำธุรกรรมปรมาณู กับทรัพย์สินอื่นๆ ดังนั้น validator ผู้ดูแลระบบจึงกำหนดค่า เซิร์ฟเวอร์ของพวกเขาจะเห็นด้วยกับ validators อื่น ๆ อย่างแน่นอน ประวัติการทำธุรกรรมทั้งหมดในสินทรัพย์ทั้งหมด validator v1 สามารถเป็นได้ กำหนดค่าให้เห็นด้วยกับ v2 หรือ v2 สามารถกำหนดค่าให้เห็นด้วยได้ กับ v1 หรือทั้งสองอย่างอาจกำหนดค่าให้เห็นด้วยซึ่งกันและกัน ในทุกกรณี จะไม่ยอมรับประวัติการทำธุรกรรมจนกว่า มันรู้ว่าอีกฝ่ายไม่สามารถยอมรับประวัติศาสตร์ที่แตกต่างได้ โดยการเปลี่ยนแปลง ถ้า v1 ไม่เห็นด้วยกับ v2 และ v2 ไม่เห็นด้วยกับ v3 (หรือกลับกัน) v1 จะไม่เห็นด้วยกับ v3 v3 ไม่ว่า v3 จะแสดงถึงสินทรัพย์ v1 หรือไม่ก็ตาม ของ. ภายใต้สมมติฐานที่ว่าข้อตกลงเหล่านี้มีความสัมพันธ์กัน เชื่อมต่อเครือข่ายทั้งหมดอย่างต่อเนื่อง SCP รับประกัน ข้อตกลงระดับโลก ทำให้เป็นข้อตกลงไบแซนไทน์ระดับโลก โปรโตคอลที่มีการเป็นสมาชิกแบบเปิด เราเรียกสมมติฐานการเชื่อมต่อใหม่นี้ว่าสมมติฐานอินเทอร์เน็ต และสังเกตว่ามัน ถือครองทั้ง “อินเทอร์เน็ต” (ซึ่งใครๆ ก็เข้าใจ หมายถึงเครือข่าย IP ที่เชื่อมต่อแบบ Transitive ที่ใหญ่ที่สุดเพียงเครือข่ายเดียว) และการชำระเงินระหว่างประเทศแบบเดิม (ซึ่งเป็นแบบ hop-by-hop ไม่ใช่อะตอม แต่ใช้ประโยชน์จากการเชื่อมต่อแบบเปลี่ยนผ่านทั่วโลก เครือข่ายสถาบันการเงิน) Stellar ใช้งานจริงตั้งแต่เดือนกันยายน 2015 เพื่อให้ blockchain สามารถจัดการความยาวได้ ระบบจะทำงาน SCP ในช่วงเวลา 5 วินาที—เร็วตามมาตรฐาน blockchain แต่ ช้ากว่าการใช้งานทั่วไปของข้อตกลงไบแซนไทน์มาก แม้ว่าการใช้งานหลักจะเป็นการชำระเงิน แต่ Stellar ก็มีเช่นกัน ได้รับการพิสูจน์แล้วว่าน่าสนใจสำหรับ tokens ที่ไม่สามารถทดแทนเงินได้ซึ่งได้รับประโยชน์ จากตลาดรองทันที (ดูหัวข้อ 7.1) ส่วนถัดไปจะกล่าวถึงงานที่เกี่ยวข้อง ส่วนที่ 3 นำเสนอ เอสซีพี. ส่วนที่ 4 อธิบายการตรวจสอบ SCP อย่างเป็นทางการของเรา ส่วนที่ 5 อธิบายชั้นการชำระเงินของ Stellar ส่วนที่ 6 เกี่ยวข้อง ประสบการณ์การปรับใช้บางส่วนและบทเรียนที่ได้เรียนรู้ ส่วนที่ 7 ประเมินระบบ ส่วนที่ 8 สิ้นสุดลง

giriiş

Uluslararası ödemeler herkesin bildiği gibi yavaş ve maliyetlidir [32]. ABD'den ABD'ye 0,50 dolar göndermenin pratik olmadığını düşünün. *Galois, Inc. †UCLA Bu çalışmanın tamamının veya bir kısmının dijital veya basılı kopyalarını alma izni kopyalarının olmaması koşuluyla kişisel veya sınıf kullanımı ücretsiz olarak sağlanır. kar veya ticari avantaj amacıyla yapılmış veya dağıtılmış ve kopyaların bu duyuru ve alıntının tamamı ilk sayfadadır. Bileşenler için telif hakları Bu çalışmanın ACM dışında başkaları tarafından sahiplenilmesi onurlandırılmalıdır. ile soyutlama krediye izin veriliyor. Başka bir şekilde kopyalamak veya yeniden yayınlamak, sunuculara göndermek veya listelere yeniden dağıtılması, önceden özel izin ve/veya ücret gerektirir. Talep izinler:[email protected]'dan. SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada © 2019 Bilgisayar Makineleri Derneği. ACM ISBN 978-1-4503-6873-5/19/10...$15,00 https://doi.org/10.1145/3341301.3359636 Meksika, iki komşu ülke. Son kullanıcılar yaklaşık 9$ ödüyor ortalama olarak bu tür bir transfer [32] ve ikili bir anlaşma için ülkelerin merkez bankalarının aracılığı ile ancak azaltılabilir temel bankanın maliyeti [2] öğe başına 0,67 ABD dolarıdır. Ücretlerin yanı sıra, Uluslararası ödemelerin gecikmesi genellikle sayılır birkaç gün içinde yurt dışından hızlı bir şekilde para almayı imkansız hale getiriyor acil durumlar. Bankacılık sisteminin olmadığı ülkelerde Çalışıyor veya tüm vatandaşlara hizmet vermiyorsa ya da ücretlerin kabul edilemez olduğu durumlarda insanlar ödemelerini [38] numaralı otobüsle göndermeye başvuruyor. [19] tekneyle ve ara sıra Bitcoin [55] ile, hepsi riske, gecikmeye veya rahatsızlığa neden olabilir. Uyum maliyetleri her zaman mevcut olsa da, kanıtlar rekabet eksikliği nedeniyle önemli miktarda kaybın olduğunu gösteriyor [21], verimsiz teknoloji nedeniyle daha da kötüleşiyor. İnsanlar nerede yenilik yapılabilir, fiyatlar ve gecikmeler düşer. Örneğin, 2019'un 2. çeyreğinde banka hesaplarından yapılan havalelerin maliyeti ortalama %6,99, mobil paranın rakamı ise yalnızca %4,88 idi [13]. Yeniliği cezbeden açık, küresel bir ödeme ağı ve banka dışı kuruluşların rekabeti bu durumu aşağı çekebilir uyumluluk [83] dahil olmak üzere tüm katmanlardaki maliyetler ve gecikmeler. Bu belgede blockchain tabanlı bir ödeme olan Stellar anlatılmaktadır Yeniliği kolaylaştırmak için özel olarak tasarlanmış ağ ve Uluslararası ödemelerde rekabet. Stellar ilki Aşağıdaki hedeflerin üçünü de karşılayacak sistem (bir yeni ama ampirik olarak geçerli “İnternet hipotezi”): 1. Açık üyelik – Herkes paraya dayalı para basabilir kullanıcılar arasında değiş tokuş edilebilecek dijital token'ler. 2. İhraççı tarafından uygulanan kesinlik – Bir token'nın ihraççısı engelleyebilir token içindeki işlemlerin geri alınmasını veya geri alınmasını önleyin. 3. Veren kurumlar arası atomiklik – Kullanıcılar atomik olarak alışveriş yapabilir ve birden fazla ihraççıdan tokens ticareti yapın. İlk ikisine ulaşmak kolaydır. Paypal, Venmo, WeChat gibi bir ürünü her firma tek taraflı olarak sunabilir Pay veya Alipay ile ödemelerin kesinliğini sağlayın yarattıkları sanal para birimleri. Ne yazık ki, bu para birimleri arasında atomik işlem yapmak imkansızdır. Aslında Paypal'ın Venmo'nun ana şirketini satın almasına rağmen 2013'te son kullanıcıların Venmo'yu göndermesi hala imkansız Paypal kullanıcılarına [78] dolar. Satıcılar yalnızca son zamanlarda hatta tek entegrasyonla ikisini de kabul edin. 2. ve 3. hedeflere kapalı bir sistemde ulaşılabilir. Özellikle bazı ülkelerde etkin yurt içi ödeme sistemi mevcuttur. ağlar genellikle evrensel olarak güvenilen bir düzenleyici otorite tarafından denetlenir. Ancak üyelik kapalı bir alanla sınırlıdır. anlaşmalı bankalar kümesi ve ağlar aşağıdakilerle sınırlıdır: Bir ülkenin düzenleyici otoritesinin erişimi.SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. Kazılan blockchains'de 1. ve 3. hedeflere ulaşıldı, en önemlisi Ethereum [3] üzerindeki ERC20 tokens biçimindedir. Bu blockchain'lerin ana fikri, insanları ödeme yaptıkları için ödüllendirecek yeni bir kripto para birimi yaratmaktır. işlemlerin geri döndürülmesi zor. Maalesef bu, token veren kuruluşların işlemin kesinliğini kontrol etmediği anlamına gelir. Eğer yazılım hatalar işlem geçmişinin yeniden düzenlenmesine neden olur [26, 73], veya insanları dolandırmanın ganimeti, maliyeti aştığında geçmişi yeniden düzenlerken [74, 97], ihraççılar tokens'den sorumlu olabilir zaten gerçek dünya parası karşılığında kullandılar. Stellar blockchain'nin iki ayırt edici özelliği vardır. İlk olarak, tokens arasındaki verimli pazarları yerel olarak destekler farklı ihraççılardan. Özellikle herkes token düzenleyebilir, blockchain, herhangi bir token çifti arasındaki ticaret için yerleşik bir emir defteri sağlar ve kullanıcılar yol ödemeleri yapabilir birkaç döviz çifti arasında atomik olarak ticaret yaparken uçtan uca limit fiyatı garanti eder. İkincisi, Stellar yeni bir Bizans anlaşması getiriyor protokol, SCP (Stellar Konsensüs Protokolü), bunun aracılığıyla token verenler, zorunlu kılmak için belirli validator sunucularını belirler işlem kesinliği. Hiç kimse ihraççının validator'lerinden (ve temel dijital imzalarından ve kriptografik hashes güvende kalır), ihraççı tam olarak hangi işlemlerin gerçekleştiğini bilir ve riskten kaçınır blockchain geçmişin yeniden düzenlenmesinden kaynaklanan kayıplar. SCP'nin temel fikri, çoğu varlık ihraççısının bundan faydalanmasıdır. Likit piyasalar ve atomik işlemleri kolaylaştırmak istiyor diğer varlıklarla. Bu nedenle, validator yöneticiler yapılandırıyor sunucularının diğer validator'lerle tam olarak aynı fikirde olması tüm varlıklardaki tüm işlemlerin geçmişi. Bir validator v1 olabilir v2 ile anlaşacak şekilde yapılandırılmış veya v2 kabul edecek şekilde yapılandırılabilir v1 ile veya her ikisi de birbiriyle uyumlu olacak şekilde yapılandırılabilir; her durumda, ikisi de bir işlem geçmişini taahhüt etmeyecektir. diğerinin farklı bir tarihe bağlanamayacağını biliyor. Geçişliliğe göre, eğer v1, v2 ile anlaşamıyorsa ve v2, v3 ile anlaşamıyorsa (veya tam tersi), v1, v2 ile anlaşamıyorsa v3, v3'ün v1'in duyduğu varlıkları temsil edip etmediği arasında. Bu anlaşma ilişkilerinin hipotezi altında SCP, tüm ağı geçişli olarak bağlamayı garanti eder küresel bir anlaşma, onu küresel bir Bizans anlaşması haline getiriyor açık üyelik protokolü Bu yeni bağlantılılık varsayımına İnternet hipotezi diyoruz ve bunun hem “İnternet”i (herkesin anladığı) geçişli olarak bağlanan en büyük tek IP ağı anlamına gelir) ve eski uluslararası ödemeler (bunlar adım adım atomik değildir ancak geçişli olarak bağlantılı, küresel bir yapıdan yararlanır finansal kurumlar ağı). Stellar Eylül 2015'ten bu yana üretimde kullanılıyor. blockchain uzunluğunu yönetilebilir tutmak için sistem çalışır 5 saniyelik aralıklarla SCP — blockchain standartlarına göre hızlı, ancak Bizans anlaşmasının tipik uygulamalarından çok daha yavaş. Ana kullanım alanı ödemeler olsa da Stellar aynı zamanda Fayda sağlayan parasal olmayan takas edilebilir token'ler için cazip olduğu kanıtlanmış doğrudan ikincil piyasalardan (bkz. Bölüm 7.1). Bir sonraki bölümde ilgili çalışmalar anlatılmaktadır. Bölüm 3 sunar SCP. Bölüm 4, SCP'nin resmi doğrulamasını açıklamaktadır. Bölüm 5'te Stellar'nin ödeme katmanı açıklanmaktadır. Bölüm 6 ilgilidir dağıtım deneyimlerimizden ve öğrendiğimiz derslerden bazıları. Bölüm 7'de sistem değerlendirilmektedir. Bölüm 8 sona eriyor.

งานที่เกี่ยวข้อง

ระบบที่อธิบายไว้ในบทความนี้เป็นระบบที่สามของเราโดยรวม พยายามสร้างเครือข่ายการชำระเงินแบบกระจายอำนาจ ที่ ความพยายามครั้งแรกโดยผู้เขียนคนหนึ่ง ส่งผลให้เกิด Ripple blockchain. ในขณะที่ยังคงมีอยู่ เราเชื่อว่า Ripple ไม่สามารถบรรลุวิสัยทัศน์ของเครือข่ายการชำระเงินแบบเปิดอย่างแท้จริงได้ ทั้งด้านธรรมาภิบาลและเหตุผลทางเทคนิค เหตุผลในการกำกับดูแลมาจากความตึงเครียดระหว่างผลประโยชน์ของผู้ถือหุ้นและ ผู้ใช้เครือข่ายแต่อยู่นอกเหนือขอบเขตของบทความนี้ ที่ ปัญหาทางเทคนิคคือโปรโตคอลข้อตกลง Byzantine ของ Ripple [89] ต้องการสมาชิกภาพเกือบปิด [33] ทำให้ การทำงานคล้ายกับข้อตกลงไบเซนไทน์ทั่วไป ความพยายามครั้งที่สอง การแยกรหัส Ripple มีอายุสั้น ฐานที่เรียกว่า stellard เปิดใช้งานจริงในเดือนกรกฎาคม 2014 เราได้วางแผนไว้ พัฒนา SCP และใส่มันลงในตัวเอกเมื่อพร้อม แต่แทน ตัดสินใจสร้างระบบใหม่ตั้งแต่ต้นรอบๆ SCP เรียกว่าแกนดาวฤกษ์ และอธิบายไว้ในบทความนี้ แกนดาวฤกษ์ ได้รับการเผยแพร่พร้อมกับคำอธิบายและหลักฐานของ SCP [68] ในเดือนเมษายน พ.ศ. 2558 และเข้าสู่การผลิต 5 เดือนต่อมา ร่างอินเทอร์เน็ต [20] อธิบาย SCP ในภายหลังสำหรับผู้ดำเนินการ แรงจูงใจและโครงสร้างของ SCP นั้นคล้ายคลึงกับความไว้วางใจที่ไม่สมมาตรในการคำนวณหลายฝ่าย [40] แม้ว่าโมเดลนั้นจะเป็นเช่นนั้น โหนดต้องมีมุมมองทั่วโลกเกี่ยวกับโครงสร้างของฝ่ายตรงข้าม ด้วยการแนะนำแนวคิดเรื่องการแบ่งส่วนโควรัม SCP จะเพลิดเพลิน การค้นพบได้และการเป็นสมาชิกแบบไดนามิกที่มีความสำคัญต่อการปรับใช้ของ Stellar โควรัมไบแซนไทน์ส่วนตัว ระบบ [47] และการกระจายความไว้วางใจแบบอสมมาตร [29] สรุปองค์ประชุมของ SCP และลดความซับซ้อนของการเปรียบเทียบกับแบบดั้งเดิม ระบบ ในสภาพแวดล้อมที่จำกัดมากขึ้น Gotsman และคณะ [49] เช่นกัน ศึกษาลักษณะทั่วไปของโควรัมของ Stellar blockchains อื่นๆ อีกหลายรายได้นำ SCP มาใช้ รวมทั้ง MobileCoin [7] และ NCNT Ripple ยังเสนอโปรโตคอลข้อตกลง Byzantine แบบเปิดสำหรับสมาชิกอีกด้วย เรียกว่าโคบอลต์ [66] ความปลอดภัยของ SCP นั้นดีที่สุด ดังนั้น SCP จึงปลอดภัย สถานการณ์ความล้มเหลวใดๆ ที่โคบอลต์อยู่ ในขณะที่กลับกัน ไม่ชัดเจน อย่างไรก็ตาม โคบอลต์อ้างว่าสภาพความปลอดภัยนั้นเข้าใจได้ง่ายกว่า และมีแนวโน้มที่จะกำหนดค่าผิดพลาดน้อยกว่า ซึ่งจะน่าสนใจที่จะประเมินว่าโคบอลต์ถูกนำไปใช้งานหรือไม่ 2.1 ระบบที่ไม่มีสมาชิกแบบเปิด เช่นเดียวกับโปรโตคอลฉันทามติอื่นๆ SCP อยู่บนพื้นฐานของการลงคะแนนเสียง [50, 94] ในระบบองค์ประชุม งานก่อนหน้าเกี่ยวกับระบบองค์ประชุม [52, 67, 72] บางครั้งเรียกว่า “ชุดผู้รอดชีวิต” [57] ศึกษาระบบองค์ประชุมที่คงที่ กล่าวคือ แก้ไขตลอด การดำเนินการของระบบ และรูปแบบเดียวกัน นั่นคือ โดยที่โหนดทั้งหมดมี แนวคิดเดียวกันว่าองค์ประชุมคืออะไร การตั้งค่าของ SCP นั้นแตกต่างออกไป โหนดที่แตกต่างกันยอมรับองค์ประชุมที่แตกต่างกันและกำลังพัฒนาการชำระเงินทั่วโลกที่รวดเร็วและปลอดภัยด้วย Stellar SOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา ฉันทามติที่รวดเร็วต่างกัน [91] อนุญาตให้มีความเหมาะสมยิ่งขึ้น แนวคิดของความไว้วางใจที่จะแสดงผ่านฉลากในตารางและ ใช้ประโยชน์จากสิ่งนี้เพื่อเพิ่มประสิทธิภาพการสื่อสาร แต่ก็ถือว่า สมาชิกแบบปิด ความพยายามอื่นๆ ในการปรับโปรโตคอลข้อตกลงไบแซนไทน์ ไปยังการตั้งค่าที่เหมือนกับบล็อคเชน รวมถึง HoneyBadger [70], SBFT [53] และ HotStuff [99] มุ่งเน้นไปที่ความสามารถในการขยายขนาด แก่ผู้เข้าร่วมจำนวนมากและประสิทธิภาพบนเครือข่ายบริเวณกว้าง โดยยังคงรักษารูปแบบการเป็นสมาชิกแบบปิดแบบดั้งเดิมไว้ Blockchains ที่กำหนดเป้าหมายไปที่สมาชิกแบบปิดได้ใช้ประโยชน์ โปรโตคอลดังกล่าว รวมถึง Libra ล่าสุด [11] 2.2 ระบบที่ไม่มีการบังคับใช้ขั้นสุดท้ายของผู้ออก Bitcoin [71] เป็นสินทรัพย์ดิจิทัลที่สามารถทดแทนได้ชิ้นแรกโดยไม่มี หน่วยงานที่เชื่อถือได้ในการติดตามยอดคงเหลือ มันก็แก้ไขไปพร้อมๆ กัน ปัญหาสองประการ: จะกระจายสินทรัพย์ใหม่อย่างไรให้ผู้คนเชื่อ มันมีมูลค่าและวิธีการให้ธุรกรรมที่ไม่สามารถย้อนกลับได้นั้น ป้องกันการโจมตีแบบใช้จ่ายซ้ำซ้อน Bitcoin สร้างเนื้อหาผ่าน proof-of-work [43] ซึ่งผู้เขียนเปรียบเทียบกับนักขุดทองที่ลงทุนทรัพยากรเพื่อเพิ่มอุปทานทองคำ ที่ งานที่พิสูจน์แล้วขึ้นอยู่กับประวัติการทำธุรกรรมซึ่งขัดขวาง การโจมตีแบบใช้จ่ายสองครั้งเนื่องจากการย้อนกลับธุรกรรมต้องทำงานเทียบเท่ากับการสร้างประวัติดั้งเดิม การโจมตี proof-of-work blockchains เป็นไปได้ เมื่อผู้โจมตีควบคุมพลังการขุดได้ 1/3 [46, 48] การพิสูจน์การทำงานมีความเสี่ยงโดยเฉพาะอย่างยิ่งสำหรับ blockchains ใหม่หรือเล็กกว่า [15, 23]; เป็นที่รู้กันว่าคนงานเหมืองที่จัดตั้งขึ้นเพื่อเปลี่ยนเส้นทางการขุด พลังสู่เครือข่ายขนาดเล็กเพื่อหากำไร [10, 54, 74, 97, 98] หรือเพียงเพื่อ สร้างปัญหา [25, 37] (เรียกว่า "การโจมตีด้วยนิ้วทอง" [60]) ในบางครั้ง นักขุดได้ติดตั้ง "การโจมตี 51%" ดังกล่าวด้วยความกรุณาเพื่อย้อนกลับผลกระทบที่ไม่พึงประสงค์ของข้อบกพร่อง [95] ใหม่ blockchains สามารถรับการป้องกันจากการโจมตี 51% ได้ ใช้ประโยชน์จาก blockchains ที่เป็นที่ยอมรับมากขึ้นด้วยการขุดแบบรวม [6] หรือหลักฐานการเผาไหม้ [79] ในขณะที่เขียนบทความนี้ การโจมตี 51% คาดว่าจะมีค่าใช้จ่าย $823,000/ ชั่วโมงบน Bitcoin, $93,000/hour on Ethereum, and under $20,000/ ชั่วโมงสำหรับ blockchains อื่นๆ ที่ติดตามทั้งหมด [12] ท้ายที่สุดแล้วสิ่งเหล่านี้ ต้นทุนขึ้นอยู่กับมูลค่าของสกุลเงินดิจิทัลที่จูงใจในการขุด ซึ่งไม่ขึ้นอยู่กับมูลค่าที่ออก สินทรัพย์ ในทางตรงกันข้าม ค่าใช้จ่ายในการประนีประนอม Stellar validators นั้นค่อนข้างอยู่ภายใต้การควบคุมของผู้ดูแลระบบ SCP นั้นคล้อยตามการใช้งานที่มีความมั่นใจสูง เช่น การใช้โมดูลความปลอดภัยของฮาร์ดแวร์เพื่อป้องกัน validator จาก การลงนามข้อความที่ขัดแย้งกัน เพื่อประโยชน์เพิ่มเติม Stellar ไม่มีค่าใช้จ่ายในการขุดเพื่อชดใช้ผ่านธุรกรรม ค่าธรรมเนียมหรือ seigniorage Bitcoin การใช้พลังงานมหาศาลของ [76] เป็นแรงบันดาลใจ รูปแบบการพิสูจน์การทำงานที่ประหยัดพลังงานมากขึ้นเช่น หลักฐานแสดงพื้นที่ [16, 17, 44, 87], หลักฐานการจัดเก็บ [18, 56, 86, 90] และหลักฐานแสดงเวลาที่ผ่านไป [4] การพิสูจน์การทำงานอาจช้าโดยมีบล็อกธุรกรรม ใช้เวลาไม่กี่นาทีในการยืนยันและต้องใช้หลายบล็อก การรักษาความปลอดภัยที่แข็งแกร่งยิ่งขึ้น อย่างไรก็ตามงานขุดบล็อกสามารถทำได้ ตัดจำหน่ายตามชุดธุรกรรมที่มีขนาดตามอำเภอใจ ซึ่งจำกัดโดยประเด็นทางการเมืองและความเข้ากันได้เท่านั้น BitcoinNG [45] ใช้หลักฐานการทำงานในการเลือกผู้นำที่ประสานงาน ธุรกรรมชุดใหญ่ขึ้น Thunderella [84] สามารถใช้ proofof-work เป็นทางเลือก "เส้นทางที่ช้า" และยืนยันในแง่ดี การทำธุรกรรมเร็วขึ้นมากโดยใช้ฉันทามติแบบอะซิงโครนัส โปรโตคอลเมื่อโหนดคันเร่งและ 3/4 ของคณะกรรมการที่ได้รับการเลือกตั้งมีความซื่อสัตย์ แม้ว่า SCP จะเร็วกว่า proof-of-work มันต้องการข้อความมากกว่าเส้นทางด่วนของ Thunderella แต่ อาจเป็นเส้นทางที่ช้าของ Thunderella ที่มีประโยชน์ อีกทางเลือกหนึ่งนอกเหนือจากการพิสูจน์การทำงานคือหลักฐานการมีส่วนได้ส่วนเสีย [59], ซึ่งนักขุดได้รับอิทธิพลทั้งทางตรงและทางอ้อมจากการเป็นเจ้าของสินทรัพย์ ในบางกรณี อิทธิพลจะเพิ่มขึ้นตามระยะเวลาที่สินทรัพย์ถูกถือครอง แผนการบางอย่าง ส่งเสริมความซื่อสัตย์โดยการริบหุ้นของคนงานเหมืองหากพวกเขา ประพฤติตัวไม่เหมาะสม [27, 28, 41]. มอบสิทธิ์ proof-of-stake [9, 61] แล้ว โหนดลงคะแนนเสียงในการเลือกตัวแทนสำหรับโปรโตคอลข้อตกลงไบเซนไทน์ทั่วไป เช่น PBFT [31] Algorand [51] ใช้ฟังก์ชันสุ่มที่ตรวจสอบได้เพื่อเลือกโหนดตัวแทนแบบสุ่มโดยมีความน่าจะเป็นเป็นสัดส่วน สู่การถือครองสกุลเงินดิจิทัล สโนว์ไวท์ [39] ทำให้เป็นทางการ คุณสมบัติด้านความปลอดภัยที่จำเป็นในการพิสูจน์การเดิมพัน รองรับโหนด "ง่วง" ที่ดำเนินต่อไปและออฟไลน์ แม้ว่าแผนการ proof-of-stake ส่วนใหญ่จะไม่สามารถบังคับใช้อย่างดุเดือดได้ด้วยการคำนวณที่มีราคาแพง แต่ต้นทุนในการได้รับส่วนแบ่ง หรือผู้ติดสินบนยังคงเกี่ยวข้องกับมูลค่าของสกุลเงินดิจิทัลอ้างอิงและอยู่นอกการควบคุมของผู้ออกสินทรัพย์ แม้ว่าจะไม่มีนักขุดที่เป็นอันตรายก็ตาม ข้อบกพร่องก็สามารถทำให้เกิดได้เช่นกัน blockchain การปรับโครงสร้างองค์กรใหม่ [26, 73] ดังนั้นจึงไม่เหมือนกับ SCP ผู้ออกไม่มีทางที่จะรับประกัน blockchain ขั้นสุดท้ายได้ แลก tokens ออนไลน์สำหรับการโอนเงินในโลกแห่งความเป็นจริงหรือ ถอนเงินสด

İlgili çalışma

Bu yazıda açıklanan sistem toplu olarak bizim üçüncü sistemimizdir. Merkezi olmayan bir ödeme ağı gerçekleştirmeye çalışın. Yazarlardan birinin yaptığı ilk girişim Ripple ile sonuçlandı blockchain. Halen var olmasına rağmen, Ripple'ın gerçekten açık bir ödeme ağı vizyonunu gerçekleştiremeyeceğine inanıyoruz. Hem yönetişim hem de teknik nedenler. Yönetim nedenleri, hissedarların çıkarları ile şirket arasındaki gerilimden kaynaklanmaktadır. ağ kullanıcıları, ancak bu makalenin kapsamı dışındadır. teknik sorun, Ripple'ın Bizans anlaşma protokolünün [89] neredeyse kapalı üyelik [33] gerektirmesidir, bu da onu işlevsel olarak geleneksel Bizans anlaşmasına benzer. İkinci girişim, Ripple kodunun kısa ömürlü bir çatallanması Stellard adlı üs Temmuz 2014'te hayata geçti. SCP'yi geliştirin ve hazır olduğunda onu Stellard'a yerleştirin, ancak bunun yerine SCP etrafında sıfırdan yeni bir sistem kurmaya karar verdi, yıldız çekirdeği olarak adlandırılıyor ve bu makalede anlatılıyor. yıldız çekirdeği SCP'nin açıklaması ve kanıtıyla birlikte yayınlandı [68] Nisan 2015'te üretime girdi ve 5 ay sonra üretime girdi. Daha sonra bir İnternet taslağı [20], uygulayıcılar için SCP'yi tanımladı. SCP'nin motivasyonu ve yapısı çok partili hesaplamadaki asimetrik güvene benzer [40] ancak bu model Düğümlerin düşman yapısına ilişkin küresel bir görüşe sahip olmasını gerektirir. SCP, çekirdek dilimleri kavramını tanıtarak, Stellar dağıtımı için önemli olan keşfedilebilirlik ve dinamik üyelik. Kişisel Bizans yeter sayısı [47] sistemleri ve asimetrik dağıtılmış güven [29] SCP'nin yeter sayılarını genelleştirir ve geleneksel ile karşılaştırmayı basitleştirir sistemler. Daha kısıtlı bir ortamda Gotsman ve ark. [49] ayrıca Stellar yetersayılarının genellemesini inceleyin. Diğer birçok blockchains de SCP'yi benimsemiştir: MobileCoin [7] ve NCNT. Ripple ayrıca yakın zamanda açık üyelikli bir Bizans anlaşması protokolü önerdi Kobalt [66] denir. SCP'nin güvenliği optimal düzeyde olduğundan SCP güvendedir Kobalt'ın olduğu herhangi bir başarısızlık senaryosu, bunun tersi ise belirsiz. Ancak Cobalt, güvenlik durumunun anlaşılmasının daha kolay olduğunu ve dolayısıyla yanlış yapılandırmaya daha az eğilimli olduğunu iddia ediyor. Kobalt'ın konuşlandırılıp konuşlandırılmayacağını değerlendirmek ilginç olacak. 2.1 Açık üyeliğin olmadığı sistemler Birçok fikir birliği protokolü gibi SCP de oylamaya dayanmaktadır [50, 94] yetersayı sisteminde. Bazen "hayatta kalan kümeler" [57] olarak adlandırılan çekirdek sistemleri üzerine önceki çalışma [52, 67, 72], statik olan, yani baştan sona sabit olan çekirdek sistemlerini inceler. sistem yürütme ve tek tip, yani tüm düğümlerin sahip olduğu yer yeter sayının ne olduğuna dair aynı fikir. SCP'nin ayarı farklı farklı düğümlerin farklı ve gelişen yeterli çoğunlukları kabul etmesi.Stellar ile hızlı ve güvenli global ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Heterojen hızlı fikir birliği [91] daha incelikli çalışmalara olanak tanır Kafesteki etiketler yoluyla ifade edilecek güven kavramları ve iletişimi optimize etmek için bundan yararlanır, ancak şunu varsayar: üyeliği kapattık. Bizans anlaşma protokollerini uyarlamaya yönelik diğer çabalar HoneyBadger [70] dahil olmak üzere Blockchain benzeri ayarlara, SBFT [53] ve HotStuff [99] ölçeklenebilirliğe odaklandı Geleneksel kapalı üyelik modelini koruyarak birçok katılımcıya ve geniş alan ağları üzerinden performansa olanak sağlar. Kapalı üyeliği hedefleyen blok zincirler yararlandı en son Libra [11] dahil olmak üzere bu tür protokoller. 2.2 İhraççı tarafından zorunlu kılınan kesinliği olmayan sistemler Bitcoin [71], değeri olmayan ilk takas edilebilir dijital varlıktı. Bakiyeleri takip etmek için güvenilir otorite. Aynı anda çözüldü iki sorun: yeni bir varlığın insanların inanmasını sağlayacak şekilde nasıl dağıtılacağı değeri vardır ve geri dönüşü olmayan işlemlerin nasıl sağlanacağı Çift harcama saldırılarını önleyin. Bitcoin aracılığıyla öğeler oluşturur proof-of-work [43], yazarı bunu, altın arzını artırmak için kaynaklara yatırım yapan altın madencilerine benzetiyor. Kanıtlanmış çalışma işlem geçmişine bağlıdır ve bu da bunu engeller Çift harcama saldırıları, çünkü işlemlerin geri alınması, orijinal geçmişi oluşturmaya benzer bir çalışma gerektirir. proof-of-work blockchains'ye saldırılar mümkün hale geldi Bir saldırgan madencilik gücünün 1/3'ünü kontrol ettiğinde [46, 48]. Kanıt çalışması özellikle yeni veya daha küçük blockchains için risklidir [15, 23]; yerleşik madencilerin madenciliği başka yöne çevirdikleri biliniyor gücü daha küçük zincirlere kâr için [10, 54, 74, 97, 98] veya sadece sorun yaratır [25, 37] ("Goldfinger saldırıları" olarak adlandırılır) [60]). Zaman zaman madenciler, [95] hatalarının istenmeyen etkilerini geri almak için bu tür "%51 saldırılarını" yardımsever bir şekilde gerçekleştirdiler. Yeni blockchains, %51 saldırılarına karşı bir miktar koruma kazanabilir: birleştirilmiş madencilik [6] veya yanma kanıtı [79] ile daha yerleşik blockchain'lerden yararlanılıyor. Bu yazının yazıldığı an itibariyle, %51 saldırısının maliyetinin 823.000 $ olduğu tahmin ediliyor. saat Bitcoin, $93,000/hour on Ethereum, and under $20,000/ izlenen diğer tüm blockchains [12] için saat. Sonuçta bunlar maliyetler, madenciliği teşvik eden kripto para biriminin değerine bağlıdır ve bu, çıkarılan kripto paranın değerinden bağımsızdır. varlıklar. Buna karşılık, Stellar validators'yi tehlikeye atmanın maliyeti bir bakıma yöneticilerinin kontrolü altındadır; SCP, aşağıdakiler gibi yüksek güvenceli uygulamalara uygundur: validator'nin engellenmesi için donanım güvenlik modüllerinin kullanılması çelişkili mesajlara imza atmak Ek bir fayda olarak, Stellar'in işlem yoluyla telafi edilecek madencilik maliyeti yok ücretler veya senyoraj. Bitcoin'nin muazzam enerji tüketimi [76] motive etti iş kanıtının daha enerji verimli çeşitleri alan kanıtı [16, 17, 44, 87], depolama kanıtı [18, 56, 86, 90], ve geçen sürenin kanıtı [4]. İşlem blokları nedeniyle iş kanıtı yavaş olabilir Onaylanması birkaç dakika sürüyor ve bunun için birden fazla blok gerekiyor daha güçlü güvenlik. Ancak bir bloğun çıkarılması işi yalnızca siyasi sorunlar ve uyumlulukla sınırlandırılan, keyfi büyüklükteki bir işlem grubu üzerinden amortismana tabi tutulur. BitcoinNG [45] koordinasyonu sağlayan bir lideri seçmek için iş kanıtını kullanıyor daha büyük bir işlem kümesi. Thunderella [84] iş kanıtını bir geri dönüş "yavaş yol" olarak kullanabilir ve iyimser bir şekilde onaylayabilir Eşzamansız bir fikir birliği kullanarak işlemler çok daha hızlı Bir hızlandırıcı düğüm ve seçilmiş bir komitenin 3/4'ü dürüst olduğunda protokol. SCP proof-of-work'dan daha hızlı olmasına rağmen, Thunderella'nın hızlı yolundan daha fazla mesaj gerektirir, ancak potansiyel olarak yararlı bir Thunderella yavaş yolu olabilir. İş kanıtının bir alternatifi, hisse kanıtıdır [59], Madencilerin doğrudan veya dolaylı olarak varlık sahipliğinden etki elde ettiği. Bazı durumlarda varlıkların elde tutulduğu süre arttıkça etki artar. Bazı planlar madencilerin hisselerine el koyarak dürüstlüğü teşvik edin yaramazlık yapmak [27, 28, 41]. Yetki verilen proof-of-stake [9, 61] şuna sahip: düğümler, PBFT [31] gibi geleneksel bir Bizans anlaşma protokolü için temsilciler seçmek üzere hisselerini oylar. Algorand [51] temsili düğümleri olasılık orantılı olarak sözde rastgele seçmek için doğrulanabilir rastgele işlevler kullanır kripto para birimi holdinglerine. Pamuk Prenses [39] resmileştiriyor Devam eden ve devam eden "uykulu" düğümleri barındıran, hisse kanıtında gerekli güvenlik özellikleriçevrimdışı. Her ne kadar çoğu proof-of-stake planı pahalı hesaplamalarla kaba kuvvetle uygulanamıyorsa da, hisse edinme maliyeti veya madencilere rüşvet verilmesi hala temel kripto para biriminin değeriyle ilgilidir ve varlık ihraççısının kontrolü dışındadır. Kötü niyetli madencilerin yokluğunda bile hatalar da sorunlara neden olabilir. blockchain yeniden düzenleme [26, 73]. Dolayısıyla SCP'den farklı olarak, ihraççıların daha önce blockchain kesinliğini sağlamanın bir yolu yok zincir üzerinde tokens'yi gerçek dünya banka havalesi için kullanmak veya nakit çekme.

Stellar โปรโตคอลฉันทามติ

Stellar ฉันทามติโปรโตคอล (SCP) เป็นแบบองค์ประชุม โปรโตคอลข้อตกลงไบเซนไทน์พร้อมสมาชิกแบบเปิด องค์ประชุมเกิดขึ้นจากการตัดสินใจกำหนดค่าท้องถิ่นแบบรวมของแต่ละโหนด อย่างไรก็ตาม โหนดจะรับรู้เท่านั้น โควรัมที่พวกเขาเป็นเจ้าของและหลังจากนั้นเท่านั้น เรียนรู้การกำหนดค่าในเครื่องของสมาชิกโควรัมคนอื่นๆ ทั้งหมด ข้อดีอย่างหนึ่งของแนวทางนี้คือ SCP โดยธรรมชาติแล้ว ยอมรับมุมมองที่แตกต่างกันของโหนดที่มีอยู่ ดังนั้น โหนดสามารถเข้าร่วมและออกฝ่ายเดียวได้โดยไม่จำเป็นต้องมี “ดูการเปลี่ยนแปลง” โปรโตคอลเพื่อประสานงานสมาชิก 3.1 ข้อตกลงสหพันธรัฐไบเซนไทน์ ปัญหาข้อตกลงไบแซนไทน์แบบดั้งเดิมประกอบด้วย ระบบปิดของโหนด N ซึ่งบางส่วนมีข้อผิดพลาดและอาจเกิดขึ้นได้ ประพฤติตนตามอำเภอใจ โหนดรับค่าอินพุตและการแลกเปลี่ยน ข้อความเพื่อตัดสินใจเกี่ยวกับค่าเอาต์พุตระหว่างอินพุต โปรโตคอลข้อตกลง Byzantine จะปลอดภัยเมื่อไม่มีโหนดใดที่ประพฤติตัวดีสองโหนดจะให้การตัดสินใจที่แตกต่างกันและไม่ซ้ำกัน การตัดสินใจเป็นข้อมูลที่ถูกต้อง (สำหรับคำจำกัดความบางประการของข้อตกลงที่ถูกต้องSOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา โลกาวา และคณะ ไว้ล่วงหน้า) โปรโตคอลจะใช้งานได้เมื่อรับประกันสิ่งนั้น โหนดที่ซื่อสัตย์ทุกอันจะส่งผลให้มีการตัดสินใจในที่สุด โดยทั่วไปแล้ว โปรโตคอลจะถือว่า N = 3f + 1 สำหรับจำนวนเต็มบางตัว f > 0 รับประกันความปลอดภัยและความมีชีวิตชีวาบางรูปแบบดังนั้น ตราบใดที่โหนด f ส่วนใหญ่มีข้อผิดพลาด ในบางช่วงของสิ่งเหล่านี้ โปรโตคอล โหนดลงคะแนนเสียงตามค่าที่เสนอและข้อเสนอ ได้รับคะแนนเสียง 2f + 1 เรียกว่าเป็นองค์ประชุมของการลงคะแนนเสียง การตัดสินใจ ด้วย N = 3f + 1 โหนด สองโควรัมใดๆ ของ ขนาด 2f + 1 ทับซ้อนกันในอย่างน้อย f + 1 โหนด แม้ว่า f ของพวกนี้ก็ตาม โหนดที่ทับซ้อนกันมีข้อบกพร่อง อย่างน้อยทั้งสององค์ก็ใช้ร่วมกัน โหนดเดียวที่ไม่ผิดพลาด ป้องกันการตัดสินใจที่ขัดแย้งกัน อย่างไรก็ตาม วิธีการนี้จะใช้ได้ก็ต่อเมื่อโหนดทั้งหมดเห็นด้วยเท่านั้น สิ่งที่ถือเป็นองค์ประชุมซึ่งเป็นไปไม่ได้ใน SCP ที่ไหน สองโหนดอาจไม่รู้ด้วยซ้ำถึงการมีอยู่ของกันและกัน ด้วย SCP แต่ละโหนด v จะประกาศชุดของโหนดเพียงฝ่ายเดียว เรียกว่าส่วนองค์ประชุมดังกล่าว โดยที่ (ก) v เชื่อว่าถ้าทั้งหมด สมาชิกของสไลซ์เห็นด้วยกับสถานะของระบบแล้ว มันถูกต้อง และ (b) v เชื่อว่ามีชิ้นของมันอย่างน้อยหนึ่งชิ้น จะพร้อมให้ข้อมูลทันเวลาเกี่ยวกับ สถานะของระบบ เราเรียกระบบผลลัพธ์ซึ่งประกอบด้วย ของโหนดและส่วนต่างๆ ของโหนดเหล่านั้น ซึ่งเป็นข้อตกลงแบบสหพันธรัฐไบเซนไทน์ (เอฟบีเอ) ระบบ. ดังที่เราจะเห็นต่อไป ระบบองค์ประชุมเกิดขึ้น จากชิ้นของโหนด อย่างไม่เป็นทางการ ชิ้นส่วนของโหนด FBA จะแสดงกับใคร โหนดต้องมีข้อตกลง เช่น โหนดอาจต้องมีข้อตกลงกับ 4 องค์กรเฉพาะ โดยแต่ละองค์กรใช้งาน 3 โหนด ถึง เพื่อรองรับเวลาหยุดทำงานก็อาจตั้งค่าชิ้นให้เป็นชุดทั้งหมด ประกอบด้วย 2 โหนดจากแต่ละองค์กร หากสิ่งนี้ “ต้องการ ข้อตกลงกับ” ความสัมพันธ์แบบสกรรมกริยาสัมพันธ์ระหว่างสองโหนดใด ๆ เราได้รับข้อตกลงระดับโลก ไม่เช่นนั้น เราก็จะได้รับความแตกต่าง แต่เฉพาะระหว่างองค์กรที่ต้องการเท่านั้น ข้อตกลงกับอีกฝ่าย เมื่อพิจารณาถึงโทโพโลยีของวันนี้ ระบบการเงิน เราตั้งสมมติฐานว่าการบรรจบกันอย่างกว้างขวางจะทำให้เกิดประวัติศาสตร์บัญชีแยกประเภทที่ผู้คนเรียกกันว่า “เครือข่าย Stellar” เช่นเดียวกับที่เราพูดถึงอินเทอร์เน็ต โควรัมเกิดจากสไลซ์ดังนี้ ทุกโหนดระบุ โควรัมจะแบ่งส่วนในทุกข้อความที่ส่ง ให้ S เป็น ชุดของโหนดซึ่งเป็นที่มาของชุดข้อความ ก โหนดถือว่าชุดข้อความถึงองค์ประชุมแล้ว ขีดจำกัดเมื่อสมาชิกทุกคนของ S มีสไลซ์รวมอยู่ใน S โดยการก่อสร้าง ชุด S ดังกล่าว ถ้ามีมติเป็นเอกฉันท์จะเป็นที่พอใจ ข้อกำหนดข้อตกลงของสมาชิกแต่ละคน เพื่อนที่ผิดพลาดอาจโฆษณาชิ้นส่วนที่สร้างขึ้นเพื่อเปลี่ยนแปลงอะไร โหนดที่มีความประพฤติดีจะพิจารณาองค์ประชุม เพื่อประโยชน์ในการวิเคราะห์โปรโตคอล เราจึงกำหนดให้องค์ประชุมใน FBA เป็นองค์ประชุมที่ไม่ว่างเปล่า ชุด S ของโหนดครอบคลุมอย่างน้อยหนึ่งส่วนโควรัมของ สมาชิกแต่ละคนที่ไม่มีข้อบกพร่อง สิ่งที่เป็นนามธรรมนี้มีเสียงเหมือนชุดใด ๆ ของข้อความที่อ้างว่าเป็นองค์ประชุมที่เป็นเอกฉันท์ ทำได้จริง (แม้ว่าจะมีข้อความจากโหนดที่ผิดพลาด) และจะแม่นยำเมื่อ S มีเพียงโหนดที่ประพฤติตัวดีเท่านั้น ใน ในส่วนนี้ เรายังถือว่าสไลซ์ของโหนดไม่มีการเปลี่ยนแปลง อย่างไรก็ตาม ผลลัพธ์ของเราจะถูกถ่ายโอนไปยังกรณีการเปลี่ยนแปลงสไลซ์ เพราะระบบการเปลี่ยนสไลซ์นั้นปลอดภัยไม่น้อยไปกว่า ระบบชิ้นคงที่ซึ่งชิ้นของโหนดประกอบด้วยทั้งหมด สไลซ์ที่เคยใช้ในกรณีการเปลี่ยนสไลซ์ (ดูทฤษฎีบท 13 ใน [68]) ตามที่อธิบายไว้ในส่วนที่ 4 ความมีชีวิตชีวาขึ้นอยู่กับ โหนดที่มีความประพฤติดีจะลบโหนดที่ไม่น่าเชื่อถือออกไปในที่สุด จากชิ้นของพวกเขา เนื่องจากโหนดที่แตกต่างกันมีข้อกำหนดของข้อตกลงที่แตกต่างกัน FBA จึงขัดขวางคำจำกัดความสากลของความปลอดภัย เราพูด โหนดที่ไม่ผิดพลาด v1 และ v2 จะเชื่อมโยงกันทุกครั้ง โควรัมของ v1 ตัดทุกโควรัมของ v2 อย่างน้อยหนึ่งตัว โหนดที่ไม่ผิดพลาด โปรโตคอล FBA สามารถรับประกันข้อตกลงได้ ระหว่างโหนดที่พันกันเท่านั้น เนื่องจาก SCP ทำเช่นนั้น จึงเป็นความผิดของมัน ความอดทนต่อความปลอดภัยเป็นสิ่งที่ดีที่สุด สมมติฐานทางอินเทอร์เน็ต การออกแบบของ Stellar พื้นฐานระบุว่าโหนดที่ผู้คนสนใจ เกี่ยวกับจะเกี่ยวพันกัน เราบอกว่าชุดของโหนดที่ฉันยังคงอยู่หากฉันเป็นองค์ประชุมที่ไม่มีข้อผิดพลาดสม่ำเสมอ โดยที่สมาชิกทุกๆ สองคนของฉันจะเกี่ยวพันกัน แม้ว่าทุกโหนดภายนอกฉันจะมีข้อผิดพลาดก็ตาม โดยสัญชาตญาณ ข้าพเจ้าก็ควรเป็นผู้ไม่ประมาทในการกระทำที่ไม่เสียหาย โหนด SCP รับประกันความมีชีวิตชีวาที่ไม่ปิดกั้น [93] และ ความปลอดภัยต่อชุดที่ไม่เสียหาย แม้ว่าตัวโหนดเองจะไม่ต้องการก็ตาม ให้รู้(และอาจไม่รู้)ว่าชุดไหนสมบูรณ์ นอกจากนี้ การรวมกันของสองฉากที่สมบูรณ์ซึ่งตัดกันก็คือ ชุดที่สมบูรณ์ ดังนั้นชุดที่ไม่เสียหายจึงกำหนดพาร์ติชันของ โหนดที่ประพฤติตัวดี โดยที่แต่ละพาร์ติชั่นปลอดภัยและใช้งานได้จริง (ภายใต้เงื่อนไขบางประการ)แต่พาร์ติชั่นที่แตกต่างกันอาจเอาท์พุตได้ การตัดสินใจที่แตกต่างกัน 3.1.1 ข้อควรพิจารณาด้านความปลอดภัยเทียบกับความมีชีวิตชีวาใน FBA ด้วยข้อยกเว้นที่จำกัด [64] โปรโตคอลข้อตกลงไบแซนไทน์ที่ปิดส่วนใหญ่จะถูกปรับไปยังจุดสมดุลที่ ความปลอดภัยและความมีชีวิตชีวามีความทนทานต่อความผิดพลาดเหมือนกัน ในเอฟบีเอ นั่นหมายถึงการกำหนดค่าทั้งหมดโดยไม่คำนึงถึงความล้มเหลว ชุดที่เกี่ยวพันกันก็ยังคงอยู่เหมือนเดิม เนื่องจาก FBA เป็นผู้กำหนด โควรัมในลักษณะกระจายอำนาจ ไม่น่าเป็นไปได้ที่การเลือกสไลซ์แต่ละรายการจะนำไปสู่ความสมดุลนี้ นอกจากนี้ ณ อย่างน้อยที่สุดใน Stellar ความสมดุลไม่เป็นที่ต้องการ: ผลที่ตามมา ของความล้มเหลวด้านความปลอดภัย (ได้แก่ การใช้เงินดิจิทัลซ้ำซ้อน) เลวร้ายยิ่งกว่าความล้มเหลวด้านความมีชีวิตชีวา (ได้แก่ ความล่าช้า ในการชำระเงินที่ต้องใช้เวลาหลายวันก่อน Stellar) ผู้คน ดังนั้นควรเลือกองค์ประชุมขนาดใหญ่เช่นนั้น โหนดของพวกเขามีแนวโน้มที่จะยังคงพันกันมากกว่าเดิม การเอียงตาชั่งเพิ่มเติมจะทำให้ฟื้นตัวได้ง่ายขึ้น ความล้มเหลวในความมีชีวิตชีวาโดยทั่วไปในระบบ FBA มากกว่าในระบบปิดแบบดั้งเดิม ในระบบปิด ข้อความทั้งหมดจะต้องเป็น ตีความตามโควรัมชุดเดียวกัน ดังนั้น จำเป็นต้องเพิ่มและลบโหนดเพื่อกู้คืนจากความล้มเหลว การบรรลุฉันทามติเกี่ยวกับเหตุการณ์การกำหนดค่าใหม่ ซึ่งเป็นเรื่องยากเมื่อไม่มีฉันทามติอีกต่อไป ในทางตรงกันข้ามกับ FBA โหนดใด ๆ สามารถปรับส่วนโควรัมของมันเพียงฝ่ายเดียวได้ตลอดเวลา เวลา. เพื่อตอบสนองต่อเหตุขัดข้องอย่างเป็นระบบที่สำคัญ องค์กร ผู้ดูแลระบบโหนดสามารถปรับส่วนของตนได้ แก้ไขปัญหา เช่นเดียวกับการประสานงานการตอบสนอง สู่หายนะ BGP [63] (แม้ว่าจะไม่มีข้อจำกัดของ การกำหนดเส้นทางผ่านลิงก์เครือข่ายทางกายภาพ)

การชำระเงินทั่วโลกที่รวดเร็วและปลอดภัยด้วย Stellar SOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา 3.1.2 ทฤษฎีบทน้ำตก SCP เป็นไปตามแม่แบบของโมเดลทรงกลมพื้นฐาน [42]; โหนดคืบหน้าผ่านชุดบัตรลงคะแนนที่มีหมายเลขแต่ละชุด พยายามสามงาน: (1) ระบุค่า “ปลอดภัย” ที่ไม่ขัดแย้งกับการตัดสินใจใดๆ ในบัตรลงคะแนนครั้งก่อน (มักเรียกว่า เตรียมบัตรลงคะแนน) (2) ตกลงเรื่องมูลค่าที่ปลอดภัย และ (3) ตรวจพบว่าข้อตกลงประสบผลสำเร็จ อย่างไรก็ตาม FBA เปิดให้บริการแล้ว การเป็นสมาชิกขัดขวางเทคนิคทั่วไปหลายประการ เป็นไปไม่ได้ที่จะ "ย้าย" โปรโตคอลแบบปิดแบบดั้งเดิมไปยัง FBA แบบจำลองโดยเพียงแค่เปลี่ยนคำจำกัดความขององค์ประชุม เทคนิคหนึ่งที่ใช้โดยโปรโตคอลจำนวนมากคือการหมุนเวียน ผ่านโหนดผู้นำในรูปแบบ Round-Robin หลังจากการหมดเวลา ในระบบปิด การเลือกผู้นำแบบพบกันหมดจะช่วยให้มั่นใจได้ ในที่สุดผู้นำที่ซื่อสัตย์และมีเอกลักษณ์เฉพาะตัวจะจบลงด้วยข้อตกลงการประสานงานด้วยค่านิยมเดียว น่าเสียดายที่เป็นแบบโรบิน ไม่สามารถทำงานในระบบ FBA โดยไม่ทราบสมาชิกภาพ เทคนิคทั่วไปอีกประการหนึ่งที่ล้มเหลวกับ FBA คือการสมมติว่าองค์ประชุมเฉพาะสามารถโน้มน้าวโหนดทั้งหมดได้ ตัวอย่างเช่น ถ้าทุกคนจำโหนด 2f + 1 ใด ๆ ที่เป็นองค์ประชุมได้ ลายเซ็น 2f + 1 เพียงพอที่จะพิสูจน์สถานะโปรโตคอลของโหนดทั้งหมด ในทำนองเดียวกัน หากโหนดได้รับองค์ประชุมของข้อความที่เหมือนกัน ผ่านการออกอากาศที่เชื่อถือได้ [24] โหนดสามารถถือว่าโหนดที่ไม่มีข้อผิดพลาดทั้งหมดจะเห็นองค์ประชุมด้วย ในทางตรงกันข้าม ใน FBA ก องค์ประชุมไม่มีความหมายอะไรกับโหนดที่อยู่นอกองค์ประชุม สุดท้ายแล้ว ระบบที่ไม่ใช่แบบรวมศูนย์มักจะใช้ระบบแบบ "ถอยหลัง" การให้เหตุผลเกี่ยวกับความปลอดภัย: หากโหนด f + 1 ผิดพลาด ความปลอดภัยทั้งหมด การค้ำประกันจะหายไป ดังนั้น ถ้าโหนด v ได้ยิน f + 1 โหนดทั้งหมด บอกข้อเท็จจริงบางประการ F, v สามารถสันนิษฐานได้ว่าอย่างน้อยก็มีหนึ่งคนกำลังบอก ความจริง (และด้วยเหตุนี้ F จึงเป็นจริง) โดยไม่สูญเสียความปลอดภัย เช่น การใช้เหตุผลล้มเหลวใน FBA เนื่องจากความปลอดภัยเป็นสมบัติของคู่ ของโหนด ดังนั้นโหนดที่สูญเสียความปลอดภัยให้กับเพื่อนบางคนสามารถทำได้ สูญเสียความปลอดภัยให้กับโหนดมากขึ้นเสมอโดยสมมติข้อเท็จจริงที่ไม่ดี อย่างไรก็ตาม FBA สามารถให้เหตุผลย้อนหลังเกี่ยวกับความมีชีวิตชีวาได้ กำหนดชุด v-blocking เป็นชุดของโหนดที่ตัดกันทุกๆ ชิ้นของ v ถ้าชุด v-blocking B มีข้อบกพร่องอย่างเป็นเอกฉันท์ B สามารถปฏิเสธโหนด v องค์ประชุมและเสียค่าใช้จ่ายได้ ดังนั้น ถ้า B ระบุข้อเท็จจริง F อย่างเป็นเอกฉันท์ แล้ว v ก็รู้ว่า F คือค่าใดค่าหนึ่ง จริงหรือ v ไม่เสียหาย อย่างไรก็ตาม วียังต้องดูให้ครบ องค์ประชุมที่จะรู้ว่าโหนดที่พันกันจะไม่ขัดแย้งกับ F ซึ่งนำไปสู่การสื่อสารรอบสุดท้ายใน SCP และ โปรโตคอล FBA อื่นๆ [47] ที่ไม่จำเป็นในภาษาอะนาล็อก โปรโตคอลการเป็นสมาชิกแบบปิด ผลลัพธ์ที่ได้ก็คือเรานั้น ความเชื่อมั่นสามระดับที่เป็นไปได้ในข้อเท็จจริงที่อาจเกิดขึ้น: ไม่แน่นอน ปลอดภัยที่จะถือว่าอยู่ในโหนดที่สมบูรณ์ (ซึ่งเราจะ ข้อเท็จจริงที่ยอมรับในระยะ) และปลอดภัยที่จะถือว่าเชื่อมโยงกัน โหนด (ซึ่งเราจะเรียกว่าข้อเท็จจริงที่ได้รับการยืนยัน) Node v สามารถระบุได้อย่างมีประสิทธิภาพว่าชุด B กำลัง vblocking หรือไม่โดยตรวจสอบว่า 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, Huntsville, ON, แคนาดา โลกาวา และคณะ การเรียกคืนการลงคะแนนแบบสหพันธรัฐอาจไม่สิ้นสุด ดังนั้นบางส่วน ข้อความเกี่ยวกับบัตรลงคะแนนอาจติดอยู่อย่างถาวร สถานะที่ไม่แน่นอนซึ่งโหนดไม่สามารถระบุได้ว่าโหนดเหล่านั้นหรือไม่ ยังอยู่ระหว่างดำเนินการหรือติดขัด เพราะโหนดไม่สามารถแยกแยะได้ ความเป็นไปได้ของข้อความที่ไม่แน่นอนซึ่งพิสูจน์ได้ว่าเป็นความจริงในภายหลัง พวกเขาจะต้องไม่พยายามลงคะแนนเสียงแบบสหพันธรัฐในแถลงการณ์ใหม่ ขัดแย้งกับสิ่งที่ไม่แน่นอน ในการลงคะแนนเสียงแต่ละครั้ง n โหนดใช้การลงคะแนนแบบสหพันธรัฐในสองประเภท ของคำสั่ง: • เตรียม ⟨n,x⟩– ระบุว่าไม่มีค่าอื่นใดนอกจาก x เคยเป็นหรือจะได้รับการพิจารณาในบัตรลงคะแนนใด ๆ ≤n • กระทำการ ⟨n,x⟩– ระบุว่า x ได้รับการตัดสินในการลงคะแนนเสียง n ที่สำคัญ โปรดทราบว่าเตรียม ⟨n,x⟩contradicts commit ⟨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⟩ ขัดแย้งกับการกระทำใด ๆ ก่อนหน้านี้สำหรับค่าที่แตกต่าง โดยข้อตกลงรับประกันการลงคะแนนเสียงแบบสหพันธรัฐ เราพบว่าไม่สามารถกำหนดมูลค่าที่แตกต่างกันได้ก่อนหน้านี้ การลงคะแนนเสียงโดยสมาชิกของ ส. โดยการปฐมนิเทศหมายเลขบัตรลงคะแนนเรา จึงได้รู้ว่า SCP นั้นปลอดภัย เพื่อความมีชีวิตชีวาให้พิจารณาชุด I ที่สมบูรณ์และยาวพอสมควร การลงคะแนนเสียงแบบซิงโครนัส หากโหนดผิดพลาดปรากฏขึ้นในชิ้น ของโหนดที่ประพฤติตัวดีจะไม่เข้าไปยุ่งเกี่ยวกับ n จากนั้นโดยการลงคะแนนเสียง 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 อาจลงคะแนนให้กับคำสั่ง a ที่ถูกต้องใดๆ ที่ไม่ลงคะแนน ขัดแย้งกับสิ่งอื่นของมันคะแนนเสียงที่โดดเด่นและคำแถลงที่ยอมรับ ทำได้โดยการเผยแพร่ข้อความลงคะแนนเสียงที่ลงนามแล้ว v จากนั้นยอมรับ a ถ้า a สอดคล้องกับข้อความอื่นๆ ที่ยอมรับ และ (กรณีที่ 1)v เป็นสมาชิกขององค์ประชุมที่ แต่ละโหนดจะโหวตให้ a หรือยอมรับ หรือ (กรณีที่ 2) แม้ว่า v ก็ตาม ไม่ได้โหวตให้ a ชุด v-blocking ยอมรับ a ในกรณีที่ 2 v พฤษภาคม เคยลงคะแนนเสียงขัดแย้งกับ ก. ซึ่งขณะนี้ได้ ถูกแทนที่ v ได้รับอนุญาตให้ลืมเกี่ยวกับการโหวตที่ถูกลบล้าง และแสร้งทำเป็นว่ามันไม่เคยแคสต์มันเลย เพราะถ้า v อยู่ในสภาพสมบูรณ์ มันก็รู้ คะแนนเสียงที่เกินกำหนดไม่สามารถครบองค์ประชุมผ่านกรณีที่ 1 v ออกอากาศว่ายอมรับ a แล้วยืนยันเมื่อเข้ามา องค์ประชุมที่มีมติเป็นเอกฉันท์ยอมรับ รูปที่ 2 แสดง ผลของเซต v-blocking และทฤษฎีบทคาสเคดระหว่าง การลงคะแนนเสียงแบบสหพันธรัฐ โหนดที่เกี่ยวพันกันสองโหนดไม่สามารถยืนยันข้อความที่ขัดแย้งกัน เนื่องจากองค์ประชุมที่จำเป็นทั้งสองจะต้องแบ่งปันการชำระเงินทั่วโลกที่รวดเร็วและปลอดภัยด้วย Stellar SOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา 3 4 2 1 5 7

Stellar fikir birliği protokolü

Stellar konsensüs protokolü (SCP) yeter sayıya dayalıdır Açık üyelikle Bizans anlaşması protokolü. Yeterli çoğunluk, bireysel düğümlerin birleşik yerel yapılandırma kararlarından ortaya çıkar. Ancak düğümler yalnızca tanır kendilerinin ait olduğu yetersayılar ve ancak bundan sonra diğer tüm çekirdek üyelerinin yerel konfigürasyonlarının öğrenilmesi. Bu yaklaşımın bir faydası SCP'nin doğası gereği Hangi düğümlerin var olduğuna dair heterojen görüşlere tolerans gösterir. Bu nedenle, düğümler herhangi bir müdahaleye gerek kalmadan tek taraflı olarak katılıp ayrılabilirler. Üyeliği koordine etmek için “değişikliği görüntüle” protokolü. 3.1 Federe Bizans anlaşması Geleneksel Bizans anlaşma problemi, N düğümden oluşan kapalı sistem; bunlardan bazıları hatalıdır ve keyfi davranın. Düğümler giriş değerlerini alır ve değiştirir Girişler arasında bir çıkış değerine karar vermek için mesajlar. Bir Bizans anlaşma protokolü, iyi davranan iki düğümün farklı kararlar vermediği ve benzersiz bir karar vermediği durumlarda güvenlidir. karar geçerli bir girdiydi (geçerli mutabakata varılan bazı tanımlar için)SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. önceden). Bir protokol bunu garanti ettiğinde yayındadır Her dürüst düğüm sonunda bir karar verir. Tipik olarak protokoller bazı tamsayılar için N = 3f + 1 olduğunu varsayar f > 0 ise güvenliği ve bir tür canlılığı garanti eder, böylece en fazla f düğümü hatalı olduğu sürece. Bunların bir aşamasında protokoller, düğümler önerilen değerlere ve bir teklife oy verir Oy yeter sayısı olarak adlandırılan 2f + 1 oy alınması, Karar. N = 3f + 1 düğüm ile herhangi iki yeter sayı boyut 2f + 1 en az f + 1 düğümde örtüşüyor; bunlardan f olsa bile örtüşen düğümler hatalı, iki çekirdek en azından paylaşıyor hatalı olmayan bir düğüm, çelişkili kararları önler. Ancak bu yaklaşım yalnızca tüm düğümlerin aynı fikirde olması durumunda işe yarar. SCP'de imkansız olan yeterli çoğunluğu ne oluşturur? iki düğüm birbirinin varlığından bile haberdar olmayabilir. SCP ile her düğüm tek taraflı olarak düğüm kümelerini bildirir, yetersayı dilimleri olarak adlandırılır, öyle ki (a) v, eğer hepsi varsa bir dilimin üyeleri sistemin durumu hakkında hemfikirdir, ardından haklılar ve (b) v, dilimlerinden en az birinin hakkında zamanında bilgi sağlamak için mevcut olacaktır. sistemin durumu. Ortaya çıkan sistemi diyoruz, düğümler ve bunların dilimleri, bir Birleşik Bizans Anlaşması (FBA) sistemi. Daha sonra göreceğimiz gibi, bir yeter sayı sistemi ortaya çıkıyor düğümlerin dilimlerinden. Gayri resmi olarak, bir FBA düğümünün dilimleri kiminle olduğunu ifade eder düğüm anlaşmayı gerektirir. Örneğin bir düğüm, her biri 3 düğüm çalıştıran 4 özel kuruluşla anlaşma gerektirebilir; için kesinti süresini karşılamak için dilimlerini tüm setler olacak şekilde ayarlayabilir Her kuruluştan 2 düğümden oluşur. Eğer bu “gerekiyorsa "ile anlaşma" ilişkisi herhangi iki düğümü geçişli olarak ilişkilendirir, küresel bir anlaşmaya varıyoruz. Aksi halde ayrılık yaşayabiliriz ancak yalnızca hiçbiri gerektirmeyen kuruluşlar arasında diğeriyle anlaşma. Günümüzün topolojisi göz önüne alındığında Finansal sistemdeki yaygın yakınlaşmanın, insanların tek bir defter tarihi olarak adlandırdığı bir defter tarihi üretmeye devam edeceğini varsayıyoruz. İnternetten bahsettiğimiz şekliyle “Stellar ağı”. Yeter sayı, dilimlerden aşağıdaki gibi ortaya çıkar. Her düğüm belirtir Gönderdiği her mesajdaki yetersayı dilimleri. S olsun bir dizi mesajın kaynaklandığı düğümler kümesi. bir düğüm, mesaj kümesinin yeter sayıya ulaştığını düşünüyor S'nin her üyesinin S'de yer alan bir dilime sahip olduğu eşik. Yapı itibarıyla böyle bir S kümesi, eğer oybirliğiyle kabul edilirse, şu koşulu karşılar: üyelerinin her birinin anlaşma gereksinimleri. Hatalı bir eş, neyi değiştirmek için hazırlanmış dilimlerin reklamını yapabilir? iyi huylu düğümler yeterli çoğunlukları dikkate alır. Protokol analizi açısından, FBA'daki yeter çoğunluğu boş olmayan bir sayı olarak tanımlıyoruz. en az bir yetersayı dilimini kapsayan düğümlerin S kümesi kusurlu olmayan her üye. Bu soyutlama, herhangi bir küme gibi sağlamdır. Oybirliğiyle alınmış bir yeter sayıyı temsil ettiği iddia edilen mesajların sayısı aslında öyledir (hatalı düğümlerden gelen mesajları içerse bile), ve S'nin yalnızca iyi davranan düğümleri içermesi kesindir. içinde Bu bölümde ayrıca düğümlerin dilimlerinin değişmediğini varsayıyoruz. Bununla birlikte, sonuçlarımız değişen dilim vakasına aktarılıyor Çünkü dilimlerin değiştiği bir sistem, bundan daha az güvenli değildir. bir düğümün dilimlerinin tüm bileşenlerden oluştuğu sabit dilim sistemi değişen dilimler durumunda kullandığı dilimler (bkz. Teorem [68] içinde 13). Bölüm 4'te açıklandığı gibi canlılık şunlara bağlıdır: iyi davranan düğümler sonunda güvenilmez düğümleri ortadan kaldırır onların dilimlerinden. Farklı düğümlerin farklı anlaşma gereksinimleri olduğundan, FBA küresel bir güvenlik tanımına izin vermez. Diyoruz Arızalı olmayan düğümler v1 ve v2 her seferinde iç içe geçmiş durumda v1 yeter sayısı, v2'nin her yeter sayısıyla en az bir noktada kesişiyor arızalı olmayan düğüm Bir FBA protokolü anlaşmayı sağlayabilir yalnızca iç içe geçmiş düğümler arasında; SCP bunu yaptığına göre bu onun hatası Güvenlik toleransı optimaldir. İnternet hipotezi, Stellar tasarımının temelinde, insanların önemsediği düğümlerin olduğu belirtiliyor hakkında iç içe geçecektir. Eğer I, tekdüze olarak hatasız bir çekirdek ise, I'in her iki üyesi de iç içe geçmişse, I'in dışındaki her düğüm hatalı olsa bile, bir I düğümleri kümesinin sağlam olduğunu söyleriz. Sezgisel olarak, o zaman, sağlam olmayanların eylemlerine karşı dayanıklı kalmalıyım düğümler. SCP, hem [93] engellenmeyen canlılığı hem de düğümlerin kendilerine ihtiyaç duymasa da, bozulmamış kümelerin güvenliği hangi setlerin sağlam olduğunu bilmek (ve bilememek). Ayrıca kesişen iki sağlam kümenin birleşimi bozulmamış bir set. Bu nedenle, bozulmamış kümeler bir bölümü tanımlar. Her bölümün güvenli ve canlı olduğu iyi huylu düğümler (bazı koşullar altında), ancak farklı bölümler çıktı alabilir farklı kararlar. 3.1.1 Amazon Lojistik'te Güvenlik ve Canlılık hususları Sınırlı istisnalar [64] dışında, kapalı Bizans anlaşma protokollerinin çoğu, denge noktasına göre ayarlanmıştır. Güvenlik ve canlılık aynı hata toleransına sahiptir. FBA'da, bu, arızalardan bağımsız olarak tümünün iç içe setler de sağlamdır. FBA'nın belirlediği göz önüne alındığında Yeterli çoğunluk merkezi olmayan bir şekilde sağlanıyorsa, bireysel dilim seçimlerinin bu dengeye yol açması pek olası değildir. Üstelik en azından Stellar'de denge istenmiyor: sonuçlar Bir güvenlik arızasının (yani çift harcanan dijital paranın) canlılık başarısızlığından çok daha kötü (yani gecikmeler) zaten Stellar tarihinden birkaç gün önce yapılan ödemelerde). İnsanlar bu nedenle büyük çekirdek dilimleri seçilmelidir ve seçilmelidir, öyle ki düğümlerinin sağlam olmaktan ziyade iç içe geçmiş kalması daha olasıdır. Teraziyi daha da eğmek, iyileşmeyi kolaylaştırır FBA sisteminde geleneksel kapalı sisteme kıyasla tipik canlılık hataları. Kapalı sistemlerde tüm mesajların aynı nisaplar dizisine göre yorumlanır. Bu nedenle, Arızadan kurtulmak için düğüm ekleme ve kaldırma gerektirir bir yeniden yapılandırma olayı üzerinde fikir birliğine varmak; fikir birliği artık canlı olmadığında bu zordur. FBA'nın aksine, herhangi bir düğüm çekirdek dilimlerini herhangi bir zamanda tek taraflı olarak ayarlayabilir zaman. Sistemik olarak önemli bir tesisteki kesintiye yanıt olarak düğüm yöneticileri dilimlerini şu şekilde ayarlayabilir: Sorunu çözmeye çalışın, biraz yanıtları koordine etmeye benzer BGP felaketlerine [63] (her ne kadar kısıtlamalar olmasa da) fiziksel ağ bağlantıları üzerinden yönlendirme).

Stellar ile hızlı ve güvenli küresel ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada 3.1.2 Basamaklı teoremi SCP, [42] temel yuvarlak modelinin şablonunu takip eder; Düğümler, her biri bir dizi numaralı oy pusulası aracılığıyla ilerler. üç görevi yerine getirmek: (1) önceki oylamada alınan herhangi bir kararla çelişmeyen "güvenli" bir değer belirlemek (genellikle bu değer olarak adlandırılır) oy pusulasını hazırlamak), (2) güvenli değer üzerinde anlaşmak ve (3) anlaşmanın başarılı olduğunu tespit etmek. Ancak FBA'nın açık Üyelik birçok yaygın tekniğin önünde engel teşkil ediyor. Geleneksel kapalı protokolleri Amazon Lojistik'e "taşımak" imkansız yetersayı tanımını değiştirerek modeli değiştirin. Birçok protokolün kullandığı tekniklerden biri rotasyondur Zaman aşımlarını takiben lider düğümler aracılığıyla dönüşümlü olarak. Kapalı bir sistemde, çevrimsel lider seçimi, sonunda benzersiz ve dürüst bir lider, tek bir değer üzerinde anlaşmayı koordine eder. Ne yazık ki, dönüşümlü üyeliği bilinmeyen bir FBA sisteminde çalışamaz. FBA'da başarısız olan diğer bir yaygın teknik, belirli bir yeter sayının tüm düğümleri ikna edebileceğini varsaymaktır. Örneğin, eğer herkes herhangi bir 2f + 1 düğümünü çekirdek olarak tanırsa, o zaman 2f + 1 imza, protokol durumunu tüm düğümlere kanıtlamak için yeterlidir. Benzer şekilde, eğer bir düğüm aynı mesajlardan oluşan bir çoğunluk alırsa güvenilir yayın [24] aracılığıyla, düğüm, arızalı olmayan tüm düğümlerin de yeterli çoğunluğu göreceğini varsayabilir. FBA'da ise tam tersine, yetersayı, yetersayı dışındaki düğümler için hiçbir şey ifade etmez. Son olarak, federe olmayan sistemler sıklıkla “geriye doğru” Güvenlikle ilgili akıl yürütme: f + 1 düğümleri hatalıysa, tüm güvenlik garantiler kaybolur. Dolayısıyla, eğer v düğümü f + 1 düğümlerin hepsini duyarsa bazı gerçekleri belirtin F, v en az birinin bunu söylediğini varsayabilir hiçbir güvenlik kaybı olmadan gerçektir (ve dolayısıyla F doğrudur). Böyle Güvenlik çiftlerin bir özelliği olduğu için FBA'da mantık başarısız oluyor düğüm sayısı, böylece bazı eşler için güvenliğini kaybetmiş bir düğüm Kötü gerçekleri varsayarak her zaman daha fazla düğümün güvenliğini kaybedersiniz. Ancak FBA, canlılık konusunda geriye doğru mantık yürütebilir. Bir v-engelleme kümesini her bir düğümle kesişen bir düğüm kümesi olarak tanımlayın. v dilimi. Eğer bir v-engelleme seti B oybirliğiyle hatalıysa, B düğüm v'nin yeterli çoğunluğunu reddedebilir ve canlılığına mal olabilir. Dolayısıyla eğer B oybirliğiyle F gerçeğini belirtiyorsa v, F'den birinin olduğunu biliyor doğru veya v sağlam değil. Ancak v'nin yine de tam bir görünüm görmesi gerekiyor iç içe geçmiş düğümlerin F ile çelişmeyeceğini bilmek için yeter sayı, bu da SCP'de son bir iletişim turuna yol açar ve benzer şekilde gerekli olmayan diğer FBA protokolleri [47] kapalı üyelik protokolleri. Sonuç şu ki, elimizde Potansiyel gerçeklere ilişkin üç olası güven düzeyi: belirsiz, sağlam düğümler arasında varsayılması güvenli (ki bunu yapacağız) kabul edilen gerçekler) ve iç içe geçmiş durumlar arasında varsayılması güvenli düğümler (bunlara doğrulanmış gerçekler adını vereceğiz). V düğümü, B kümesinin vbblocking olup olmadığını, B'nin tüm dilimleriyle kesişip kesişmediğini kontrol ederek etkili bir şekilde belirleyebilir. İlginç bir şekilde, düğümler her zaman yaptıkları açıklamaları duyuruyorsa kabul ederse ve tam çoğunluk bir ifadeyi kabul ederse, bu, ifadelerin her yere yayıldığı basamaklı bir süreci başlatır. sağlam setler. Bu yayılmanın altında yatan temel gerçeği diyoruz aşağıdakileri karşılayan basamaklı teorem: Eğer ben bir bozulmamış küme, Q I'in herhangi bir üyesinin yeter sayısıdır ve S herhangi bir üyedir Q'nun üst kümesi ise ya S ⊇I ya da bir v ∈I üyesi vardır öyle ki v < S ve I ∩S v-bloke edicidir. Sezgisel olarak bu durum böyle değilse, S'nin tamamlayıcısı bir yeter sayı içerecektir I ile kesişiyor ama Q ile kesişmiyor, çekirdek kesişimini ihlal ediyor. S = Q ile başlarsak ve S'yi tekrar tekrar genişletirsek şunu unutmayın: Engellediği tüm düğümleri dahil edersek basamaklı bir etki elde ederiz, ta ki, sonuçta S, I'in tamamını kapsar. 3.2 Protokol açıklaması SCP, adı verilen fikir birliğine varmaya yönelik bir dizi girişimden oluşan, kısmen senkronize bir fikir birliği protokolü [42] oy pusulaları. Oy pusulalarında artan süreli zaman aşımları kullanılır. bir oylama senkronizasyon protokolü düğümlerin açık kalmasını sağlar oylamalara kadar artan sürelerde aynı oylama etkili bir şekilde senkronizedir. Sonlandırma garanti edilmez oylamalar eşzamanlı olana kadar, ancak iki eşzamanlı oylama iyi davranan düğüm dilimlerinin hatalı üyelerinin yaptığı SCP'nin sonlandırılması için müdahale etmemek yeterlidir. Bir oylama protokolü, her oylama sırasında gerçekleştirilen eylemleri belirtir. oy pusulası. Oylama, düğümlerin yer aldığı bir hazırlık aşamasıyla başlar. önermek için çelişmeyen bir değer belirlemeye çalışın önceki herhangi bir karar. Daha sonra, bir taahhüt aşamasında düğümler şunu dener: Hazırlanan değere karar vermek. Oylamada, birleşik oylama adı verilen bir anlaşma alt protokolü kullanılır.n hangi düğümler soyut ifadelere oy verir bu sonunda onaylanabilir veya takılıp kalabilir. Bazı ifadeler çelişkili olarak adlandırılabilir ve güvenlik Federasyon oylamanın garantisi, bir oylamada iki üyenin olmamasıdır. iç içe geçmiş küme çelişkili ifadeleri doğrular. Bir bildirimin onaylanması, sağlam olması dışında garanti edilmez. üyelerinin hepsinin aynı şekilde oy kullandığı bir grup. Ancak eğer bir sağlam bir grubun üyesi bir beyanı doğruluyor, birleştirilmiş oylama, bozulmamış setin tüm üyelerinin eninde sonunda bu ifadeyi onaylamasını garanti eder. Bu nedenle geri dönüşü olmayan adımlar atmak teyit edici ifadelere yanıt olarak canlılığı korur sağlam düğümler Düğümler başlangıçta bir adaylıktan elde edilen değerleri önerir tüm üyelerin sağlam olma şansını artıran protokol aynı değeri öneren ve sonunda yakınsayan küme (yakınsamanın tamamlandığını belirlemenin hiçbir yolu olmasa da). Aday gösterme, birleşik oylamayı lider seçimiyle birleştirir. FBA'da hepsini bir kez denemek mümkün olmadığından, aday gösterme yöntemleri olasılıksal bir lider seçim şeması. Basamaklı teoremi hem oylamada önemli bir rol oynar senkronizasyon ve engellenen durumlardan kaçınma fesih artık mümkün değildir. 3.2.1 oylama SCP düğümleri, bir dizi numaralı oylama yoluyla ilerler ve hangi beyanlar üzerinde anlaşmaya varmak için birleşik oylama kullanır? Değerlerin hangi oylamada belirlenip belirlenmeyeceğine karar verilir. Eşzamansız ise veya hatalı davranışın n oylamasında karara varılmasını engellemesi, düğümler zaman aşımına uğradı ve n + 1 oylamasında tekrar deneyin.

SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. Federal oylamanın sona ermeyebileceğini hatırlayın. Dolayısıyla bazı Oy pusulalarıyla ilgili açıklamalar kalıcı olarak sıkışıp kalabilir düğümlerin asla karar veremeyecekleri belirsiz durum hala devam ediyor veya takılıp kaldı. Çünkü düğümler göz ardı edilemez belirsiz ifadelerin daha sonra doğru çıkma olasılığı, yeni beyanlar üzerinde asla federal oylamaya kalkışmamalılar belirsiz olanlarla çelişen. Her n oylamasında, düğümler iki türde birleştirilmiş oylamayı kullanır beyanının: • hazırla ⟨n,x⟩– x dışında hiçbir değerin olmadığını belirtir ≤n herhangi bir oylamada kararlaştırıldı veya belirlenecek. • taahhüt ⟨n,x⟩– x'e n oylamasında karar verildiğini belirtir. Önemli olarak, ⟨n,x⟩contradicts taahhütlerini hazırladığınızı unutmayın ⟨n',x ′⟩n ≥n' ve x , x ′ olduğunda. Bir düğüm, birleştirilmiş oylamayı deneyerek n oylamaya başlar. ifade hazırlığı ⟨n,x⟩. Daha önce hazırlanmış bir beyan varsa Federasyon oylamasıyla başarıyla onaylanan düğüm, en yüksek oylamanın onaylanmış formundan x'i seçer. Aksi halde düğüm x'i çıktıya ayarlar. Bir sonraki alt bölümde açıklanan adaylık protokolü. Ancak ve ancak bir düğüm başarılı bir şekilde hazırlığı onaylarsa ⟨n,x⟩ n oylamasında, ⟨n,x⟩ taahhüdü üzerine federal oylama girişiminde bulunur. Eğer başarılı olursa, bu SCP'nin karar verdiği anlamına gelir, dolayısıyla düğüm çıktı verir onaylanmış taahhüt beyanındaki değer. İç içe geçmiş bir S kümesi düşünün. En fazla bir değer olduğundan Belirli bir oylamada S üyeleri tarafından hazırlanan teyit edilebilir, iki farklı değerin taahhüt edildiği teyit edilemez. Belirli bir oylamada S üyeleri. Üstelik ⟨n,x⟩ taahhüt edilirse onaylandı, ardından ⟨n,x⟩ hazırlığı da onaylandı; o zamandan beri ⟨n,x⟩ hazırlamak, federal oylamanın anlaşma garantileri ile daha önce farklı bir değere yönelik taahhütlerle çelişir daha erken bir tarihte farklı bir değere karar verilemeyeceğini anlıyoruz S üyeleri tarafından yapılan oylama. Oy pusulası sayılarına ilişkin tümevarım yoluyla, bu nedenle SCP'nin güvenli olduğunu anlayın. Canlılık için sağlam bir I kümesini ve yeterince uzun bir diziyi düşünün. eşzamanlı oylama Dilimlerde hatalı düğümler görünüyorsa iyi huylu düğümlerin sayısı n'ye müdahale etmez, ardından oylamayla n + 1 I'in tüm üyeleri aynı P hazırlama ifadesini onayladılar. Eğer P = ∅ ve oy pusulası n yeterince uzunsa, adaylık protokolü bazı x değerlerine yakınlaşacaktır. Aksi takdirde, P'de en yüksek oyu alan hazırlıktan elde edilen değer x olsun. Her iki durumda da, eşit şekilde federal girişimde bulunacağım Bir sonraki oylamada ⟨n + 1,x⟩ hazırlığı için oylama. Bu nedenle eğer n + 1 de eşzamanlıdır, kaçınılmaz olarak x kararı takip eder. 3.2.2 Adaylık Aday gösterme, aşağıdaki ifadeler üzerinde federal oylamayı gerektirir: • x'i aday gösterin – x'in geçerli bir karar adayı olduğunu belirtir. Düğümler birden fazla değeri aday göstermek için oy kullanabilir (farklı) aday ifadeleri çelişkili değildir. Ancak bir kez bir düğüm herhangi bir aday beyanını onayladığında oylamayı durdurur yeni değerleri aday gösterin. Birleşik oylama hala bir düğümün şunları yapmasına izin veriyor: oy vermediği yeni aday beyanlarını onaylayın; oy ver ya da kabul et çoğunluktan kabul etmek çoğunluktan a geçerlidir gelen bir teklifi kabul et engelleme seti taahhütsüz oy verdi kabul edildi doğrulandı oy verildi ¬a Şekil 1. Birleştirilmiş oylamanın aşamaları bozulmamış bir kümenin üyelerinin birbirlerinin bilgilerini onaylamasına olanak tanır yeni oyları alıkoyarken değerleri aday gösterdi. Aday göstermenin (gelişen) sonucu, onaylanmış aday gösterme ifadelerindeki tüm değerlerin deterministik bir birleşimidir. Eğer x bir dizi işlemi temsil eder, düğümler birliği alabilir kümelerin en büyüğü veya en yüksek hash değerine sahip olanıdır, yani tüm düğümler aynı şeyi yaptığı sürece. Çünkü düğümler yeniyi saklıyor bir aday beyanını onayladıktan sonra oylar, Onaylanmış ifadeler yalnızca sonlu sayıda değer içerebilir. Onaylanan açıklamaların güvenilir bir şekilde yayılması bozulmamış kümeler, bozulmamış düğümlerin eninde sonunda aynı noktada birleşeceği anlamına gelir aynı aday değerler kümesi ve dolayısıyla adaylık sonucu, ancak bilinmeyen bir noktada keyfi olarak protokolün sonlarında. Düğümler, birleşik lider seçimini kullanarak aday ifadelerindeki farklı değerlerin sayısı. Yalnızca Henüz aday beyanına oy vermemiş bir lider yeni bir x getirebilir. Diğer düğümler sizden haber almayı bekliyor Liderlerin (geçerli) aday oylarını kopyalayın. Başarısızlığa uyum sağlamak için liderler kümesi büyümeye devam ediyor zaman aşımları meydana gelir, ancak pratikte yalnızca birkaç düğüm yeni x değerlerini sunar. 3.2.3 Federe oylama Birleşik oylamada gösterilen üç aşamalı bir protokol kullanılır Şekil 1. Düğümler öncelikle soyut ifadeler üzerinde anlaşmaya varmaya çalışırlar. oylama, ardından kabul etme ve son olarak beyanları onaylama. Bir v düğümü, geçerli olmayan herhangi bir a ifadesine oy verebilir. diğeriyle çelişiyorödenmemiş oylar ve kabul edilen beyanlar. Bunu imzalı bir oylama mesajı yayınlayarak yapar. v daha sonra a'nın kabul edilen diğer ifadelerle tutarlı olması ve her iki (durum 1)v'nin bir yetersayı üyesi olması durumunda a'yı kabul eder; her düğüm ya a'ya oy verir ya da a'yı kabul eder veya (durum 2) v olsa bile a'ya oy vermediyse, v-engelleyici küme a'yı kabul eder. Durum 2'de v olabilir daha önce a ile çelişen oylar kullanmışken, şimdi bunlar reddedildi. v'nin geçersiz oyları unutmasına izin verilir ve onları hiç kullanmamış gibi davran çünkü eğerv sağlamsa, biliyor Reddedilen oylar, 1. durumda yetersayıyı tamamlayamaz. v a'yı kabul ettiğini yayınlar, ardından içeri girdiğinde a'yı onaylar oybirliğiyle kabul eden bir yeter sayı. Şekil 2 şunları göstermektedir: v-bloklama kümelerinin etkisi ve basamak teoremi federal oylama. İç içe geçmiş iki düğüm, çelişkili ifadeleri onaylayamaz çünkü gerekli iki yeter sayının aynı fikirde olması gerekir.Stellar ile hızlı ve güvenli küresel ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada 3 4 2 1 5 7

โหวต X

โหวต Y (ก) 3 4 2 1 5 7 6 โหวต เอ็กซ์ โหวต เอ็กซ์ โหวต เอ็กซ์ โหวต ย โหวต เอ็กซ์ โหวต ย โหวต ย (ข) 3 4 2 1 5 7 6 ยอมรับ เอ็กซ์ โหวต เอ็กซ์ ยอมรับ เอ็กซ์ โหวต ย ยอมรับ เอ็กซ์ โหวต ย โหวต ย (ค) 3 4 2 1 5 7 6 ยอมรับ เอ็กซ์ ยอมรับ เอ็กซ์ ยอมรับ เอ็กซ์ โหวต ย ยอมรับ เอ็กซ์ ยอมรับ เอ็กซ์ โหวต ย (ง) 3 4 2 1 5 7 6 ยอมรับ เอ็กซ์ โหวต เอ็กซ์ ยอมรับ เอ็กซ์ ยอมรับ เอ็กซ์ ยอมรับ เอ็กซ์ ยอมรับ เอ็กซ์ ยอมรับ เอ็กซ์ (จ) รูปที่ 2 ผลกระทบแบบเรียงซ้อนในการลงคะแนนเสียงแบบสหพันธรัฐ แต่ละโหนดมีหนึ่งส่วนโควรัมที่ระบุโดยลูกศรไปยังสมาชิกของส่วนนั้น (a) มีการนำข้อความ X และ Y ที่ขัดแย้งกันมาใช้ (b) โหนดลงคะแนนสำหรับข้อความที่ถูกต้อง (c) โหนด 1 ยอมรับ X หลังจากองค์ประชุม {1, 2, 3, 4} โหวตเป็นเอกฉันท์สำหรับ X. (d) โหนด 1, 2, 3 และ 4 ทั้งหมดยอมรับ X; ชุด {1} เป็นการปิดกั้น 5 รายการ ดังนั้นโหนด 5 จึงยอมรับ X ซึ่งอยู่เหนือการควบคุม การโหวตครั้งก่อนสำหรับ Y (e) ชุด {5} คือการบล็อก 6- และ 7 ดังนั้น 6 และ 7 จึงยอมรับ X ทั้งคู่ โหนดที่ไม่ผิดพลาดซึ่งไม่สามารถยอมรับข้อความที่ขัดแย้งกัน ไม่รับประกันการยืนยันคำสั่ง: ใน ในกรณีที่มีการลงคะแนนเสียงแตกแยก ทั้งสองข้อความอาจเป็นรายการถาวรได้ ติดอยู่ในการรอองค์ประชุมในช่วงลงคะแนนเสียง อย่างไรก็ตามหาก โหนดในชุดที่ไม่เสียหายฉันยืนยันคำสั่งแบบเรียงซ้อน ทฤษฎีบทและยอมรับกรณีที่ 2 ทำให้มั่นใจว่าในที่สุดฉันก็จะทำได้ ยืนยันข้อความนั้น 3.2.4 การซิงโครไนซ์บัตรลงคะแนน หากโหนดไม่สามารถยืนยันคำสั่งยืนยันสำหรับ บัตรลงคะแนนปัจจุบัน พวกเขาจะยอมแพ้หลังจากหมดเวลา การหมดเวลาได้รับ นานขึ้นกับการลงคะแนนแต่ละครั้งเพื่อปรับขอบเขตตามอำเภอใจ เกี่ยวกับความล่าช้าของเครือข่าย อย่างไรก็ตาม การหมดเวลาเพียงอย่างเดียวไม่เพียงพอที่จะซิงโครไนซ์บัตรลงคะแนนของโหนดที่ไม่ได้เริ่มต้นในเวลาเดียวกันหรือ ถูกยกเลิกการซิงโครไนซ์ด้วยเหตุผลอื่น เพื่อให้เกิดการซิงโครไนซ์ โหนดจะเริ่มตัวจับเวลาเมื่อเป็นส่วนหนึ่งของ a เท่านั้น องค์ประชุมทั้งหมดที่อยู่ในบัตรลงคะแนนปัจจุบัน (หรือหลังจากนั้น) นี้ ทำให้โหนดที่เริ่มต้นช้าลงและทำให้แน่ใจว่าไม่ สมาชิกของชุดที่สมบูรณ์จะอยู่ไกลกว่ากลุ่มมากเกินไป ยิ่งไปกว่านั้น หากโหนด v สังเกตเห็นการตั้งค่า v-blocking ในภายหลัง บัตรลงคะแนนก็จะข้ามไปที่บัตรลงคะแนนต่ำสุดทันทีเช่นนี้ จะไม่เป็นเช่นนั้นอีกต่อไป โดยไม่คำนึงถึงตัวจับเวลาใดๆ น้ำตก ทฤษฎีบทจะทำให้มั่นใจได้ว่าผู้พลัดหลงทุกคนตามทัน ผลลัพธ์ที่ได้ คือบัตรลงคะแนนมีการซิงโครไนซ์กันคร่าวๆ โดยสมบูรณ์ ตั้งค่าเมื่อระบบกลายเป็นซิงโครนัส 3.2.5 การคัดเลือกผู้นำแบบสหพันธรัฐ การเลือกผู้นำทำให้แต่ละโหนดสามารถเลือกผู้นำในลักษณะดังกล่าวได้ วิธีที่โดยทั่วไปแล้วโหนดจะเลือกเพียงตัวเลขเดียวหรือจำนวนน้อย ของผู้นำ เพื่อรองรับความล้มเหลวของผู้นำ การคัดเลือกผู้นำ ดำเนินการผ่านรอบ หากผู้นำในรอบปัจจุบัน ปรากฏว่าไม่ปฏิบัติตามหน้าที่ของตนแล้วหลังจากนั้น โหนดช่วงหมดเวลาบางรายการจะเข้าสู่รอบถัดไป ขยายกลุ่มผู้นำที่พวกเขาติดตาม แต่ละรอบใช้ฟังก์ชัน hash การเข้ารหัสลับที่ไม่ซ้ำกันสองฟังก์ชัน นั่นคือ H0 และ H1 ซึ่งเอาต์พุตจำนวนเต็มจะอยู่ในช่วง [0,hmax) ตัวอย่างเช่น Stellar ใช้ Hi(m) = SHA256(i∥b∥r ∥m) โดยที่ b คืออินสแตนซ์ SCP โดยรวม (หมายเลขบล็อกหรือบัญชีแยกประเภท) r คือ หมายเลขรอบคัดเลือกผู้นำ และ hmax = 2256 ภายใน ในแต่ละรอบ เรากำหนดลำดับความสำคัญของโหนด v เป็น: ลำดับความสำคัญ(v) = H1(v) ฟางหนึ่งคนจะเลือกแต่ละโหนดให้เป็นผู้นำ โหนดที่มีลำดับความสำคัญสูงสุด (v) แนวทางนี้ใช้ได้ผล มีโควรัมสไลซ์ที่เกือบจะเหมือนกัน แต่ก็ไม่ถูกต้อง จับความสำคัญของโหนดในการกำหนดค่าที่ไม่สมดุล เช่น ถ้ายุโรปและจีนช่วยกันคนละ 3 โหนดทุกโควรัม แต่จีนใช้งาน 1,000 โหนดและยุโรป 4 จากนั้นจีนจะมีโหนดที่มีลำดับความสำคัญสูงสุด 99.6% ของเวลา เราจึงแนะนำแนวคิดเรื่องน้ำหนักชิ้นโดยที่ น้ำหนัก (u,v) ∈[0, 1] คือเศษส่วนของส่วนโควรัมของโหนด u ที่มีโหนด v เมื่อโหนดคุณเลือกผู้นำคนใหม่ พิจารณาเฉพาะเพื่อนบ้าน กำหนดไว้ดังนี้ เพื่อนบ้าน(u) = { v | H0(v) < hmax · น้ำหนัก(u,v) } จากนั้น nodeu จะเริ่มต้นด้วยกลุ่มผู้นำที่ว่างเปล่า และที่แต่ละกลุ่ม round เพิ่มโหนด v ในเพื่อนบ้าน (u) ที่มีค่าสูงสุด ลำดับความสำคัญ(v) หากชุดเพื่อนบ้านว่างเปล่าในรอบใดๆ คุณจะเพิ่มโหนดที่มีค่าต่ำสุดเป็นH0(v)/weight(u,v) แทน

X'e oy ver

E oyu ver (bir) 3 4 2 1 5 7 6 Oy ver X Oy ver X Oy ver X Oy ver e Oy ver X Oy ver e Oy ver e (b) 3 4 2 1 5 7 6 Kabul et X Oy ver X Kabul et X Oy ver e Kabul et X Oy ver e Oy ver e (c) 3 4 2 1 5 7 6 Kabul et X Kabul et X Kabul et X Oy ver e Kabul et X Kabul et X Oy ver e (d) 3 4 2 1 5 7 6 Kabul et X Oy ver X Kabul et X Kabul et X Kabul et X Kabul et X Kabul et X (e) Şekil 2. Birleştirilmiş oylamada kademeli etki. Her düğüm, dilimin üyelerine oklarla gösterilen bir çekirdek dilime sahiptir. (a) Çelişkili X ve Y ifadeleri tanıtılır. (b) Düğümler geçerli ifadelere oy verir. (c) Düğüm 1, yeterli çoğunluktan sonra X'i kabul eder {1, 2, 3, 4} oybirliğiyle X'e oy verir. (d) 1, 2, 3 ve 4. düğümlerin tümü X'i kabul eder; {1} kümesi 5'i engelliyor, dolayısıyla düğüm 5 X'i kabul ederek geçersiz kılıyor önceki oyu Y'ye verilmiştir. (e) {5} kümesi 6- ve 7'yi bloke etmektedir, dolayısıyla 6 ve 7'nin her ikisi de X'i kabul etmektedir. çelişkili ifadeleri kabul edemeyen hatalı olmayan düğüm. Bir bildirimin onaylanması garanti edilmez: Oyların bölünmesi durumunda her iki beyan da kalıcı olarak geçerli olabilir. oylama aşamasında yetersayıyı beklemek zorunda kaldı. Ancak eğer bozulmamış bir kümedeki bir düğüm Bir ifadeyi doğrularım, basamaklı teorem ve durum 2'nin kabul edilmesi, sonunda I'in tamamının olmasını sağlar bu ifadeyi onaylayın. 3.2.4 Oy pusulası senkronizasyonu Düğümler bir taahhüt ifadesini onaylayamıyorsa mevcut oylamada, bir mola sonrasında pes ediyorlar. Zaman aşımı alır keyfi sınırlara uyum sağlamak için her oylamada daha uzun ağ gecikmesinde. Ancak zaman aşımları tek başına aynı anda başlamamış veya başlamamış düğümlerin oylamalarını senkronize etmek için yeterli değildir. başka nedenlerden dolayı senkronizasyonu bozuldu. Senkronizasyonu sağlamak için düğümler zamanlayıcıyı yalnızca bir sistemin parçası olduklarında başlatır. mevcut (veya daha sonraki) oylamada bulunan yeter çoğunluk Bu erken başlayan düğümleri yavaşlatır ve hiçbir Sağlam bir grubun üyesi grubun çok ilerisinde kalır. Ayrıca, eğer bir v düğümü daha sonra bir v-engelleme setini fark ederse oylamada hemen en düşük oylamaya atlanır, öyle ki herhangi bir zamanlayıcıdan bağımsız olarak artık durum böyle değil. Çağlayan teoremi daha sonra tüm başıboş kalanların yetişmesini sağlar. Sonuç oy pusulalarının sağlam bir şekilde kabaca senkronize edilmesidir sistem senkronize hale geldiğinde ayarlanır. 3.2.5 Federe lider seçimi Lider seçimi, her düğümün böyle bir şekilde liderleri seçmesine olanak tanır. düğümlerin genellikle yalnızca bir veya küçük bir sayı seçmesi liderlerin. Lider başarısızlığını telafi etmek için lider seçimi turlarla ilerler. Mevcut turun liderleri ise sorumluluklarını yerine getirmiyor gibi görünüyorlar ve bir süre sonra belirli zaman aşımı süresi düğümleri bir sonraki tura geçer Takip ettikleri liderler kümesini genişletin. Her turda, [0,hmax] aralığında tamsayıların çıktısını veren iki benzersiz şifreleme hash işlevi (H0 ve H1) kullanılır. Örneğin, Stellar Hi(m) = SHA256(i∥b∥r ∥m) kullanır; burada b genel SCP örneğidir (blok veya defter numarası), r ise lider seçim turu numarası ve hmax = 2256. Bir turda v düğümünün önceliğini şu şekilde tanımlarız: öncelik(v) = H1(v) Her düğüm için bir saman adam lider olarak seçilecek en yüksek önceliğe sahip düğüm(v). Bu yaklaşım işe yarıyor neredeyse aynı çekirdek dilimleriyle iyi, ancak düzgün şekilde çalışmıyor Dengesiz konfigürasyonlarda düğümlerin önemini yakalayın. Örneğin, eğer Avrupa ve Çin'in her biri 3 katkı sağlıyorsa her çoğunluk için düğümler, ancak Çin 1.000 düğüm ve Avrupa 4 çalıştırıyorsa, o zaman Çin %99,6 ile en yüksek öncelikli düğüme sahip olacak zamanın. Bu nedenle dilim ağırlığı kavramını tanıtıyoruz; ağırlık(u,v) ∈[0, 1] u düğümünün çekirdek dilimlerinin kesridir v düğümünü içeren. U düğümü yeni bir lider seçerken, yalnızca aşağıdaki şekilde tanımlanan komşuları dikkate alır: komşular(u) = { v | H0(v) < hmax · ağırlık(u,v) } Daha sonra bir düğüm boş bir lider kümesiyle başlar ve her birinde round ona en yüksek değere sahip komşulardaki (u) v düğümünü ekler öncelik(v). Eğer komşular seti herhangi bir turda boşsa, u bunun yerine en düşük H0(v)/ağırlık(u,v) değerine sahip düğümü ekler.

การตรวจสอบ SCP อย่างเป็นทางการ

เพื่อกำจัดข้อผิดพลาดในการออกแบบ เราได้ตรวจสอบความปลอดภัยของ SCP อย่างเป็นทางการ และคุณสมบัติความมีชีวิตชีวา (ดู [65]) โดยเฉพาะเราตรวจสอบแล้ว โหนดที่พันกันไม่เคยไม่เห็นด้วย และภายใต้เงื่อนไขที่กล่าวถึงด้านล่าง สมาชิกทุกคนในชุดที่สมบูรณ์จะตัดสินใจในที่สุด สิ่งที่น่าสนใจคือการตรวจสอบพบว่า เงื่อนไขที่ SCP รับประกันความมีชีวิตชีวานั้นละเอียดอ่อน และแข็งแกร่งกว่าที่คิดไว้ในตอนแรก [68]: ตามที่กล่าวไว้ด้านล่าง โหนดที่เป็นอันตรายซึ่งจัดการเวลาโดยไม่มีอย่างอื่น การเบี่ยงเบนไปจากโปรโตคอลอาจต้องถูกไล่ออกด้วยตนเอง จากชิ้นโควรัม

SOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา โลกาวา และคณะ เพื่อให้แน่ใจว่าคุณสมบัติได้รับการพิสูจน์แล้วว่าสามารถถือครองได้ทั้งหมด การกำหนดค่าและการดำเนินการของ FBA เราพิจารณาโดยพลการ จำนวนโหนดที่มีการกำหนดค่าท้องถิ่นโดยพลการ นี้ รวมถึงสถานการณ์ที่มีชุดที่ไม่เสียหายที่ไม่ต่อเนื่องกัน รวมถึงการดำเนินการที่อาจยาวนานอย่างไม่มีที่สิ้นสุด ข้อเสียเปรียบก็คือเรา เผชิญกับปัญหาที่ท้าทายในการตรวจสอบพารามิเตอร์ ระบบสถานะอนันต์ เพื่อให้การตรวจสอบเป็นไปได้ เราได้จำลอง SCP ในตรรกะลำดับแรก (FOL) โดยใช้ Ivy [69] และวิธีการของ [82] กระบวนการตรวจสอบประกอบด้วยการให้การคาดเดาแบบอุปนัยด้วยตนเอง จากนั้นจะมีการตรวจสอบโดยอัตโนมัติ ไอวี่. โมเดล FOL ของ SCP เป็นนามธรรมเหนือบางแง่มุมของ ระบบ FBA ที่ยากต่อการจัดการใน FOL (เช่น ทฤษฎีบทน้ำตกถือเป็นสัจพจน์) ดังนั้นเราจึงตรวจสอบ ความสมบูรณ์ของนามธรรมโดยใช้ Isabelle/HOL [75] หลังจากแสดงปัญหาการตรวจสอบใน FOL แล้ว เราจะตรวจสอบความปลอดภัยโดยจัดให้มีค่าคงที่อุปนัย อุปนัย ค่าคงที่ประกอบด้วยการคาดเดาบรรทัดเดียวหลายสิบรายการสำหรับประมาณ ข้อกำหนดโปรโตคอล 150 บรรทัด จากนั้นเราจะระบุคุณสมบัติความมีชีวิตชีวาของ SCP ใน Linear Temporal Logic ของ Ivy และใช้ ความมีชีวิตชีวาต่อการลดความปลอดภัย [80, 81] เพื่อลดความมีชีวิตชีวา ปัญหาการตรวจสอบปัญหาการหาอุปนัย ไม่เปลี่ยนแปลง ในขณะที่ความปลอดภัยของ SCP นั้นค่อนข้างตรงไปตรงมา พิสูจน์ว่าข้อโต้แย้งความมีชีวิตชีวาของ SCP นั้นซับซ้อนกว่ามากและ ประกอบด้วยค่าคงที่บรรทัดเดียวประมาณ 150 รายการ การพิสูจน์ความมีชีวิตชีวาจำเป็นต้องมีการทำให้เป็นทางการอย่างแม่นยำ สมมติฐานที่ SCP รับรองการยุติ ตอนแรกเราคิดว่าฉากที่สมบูรณ์ฉันจะยุติลงหากทั้งหมด สมาชิกลบโหนดที่ผิดพลาดออกจากส่วนของพวกเขา [68] อย่างไรก็ตาม สิ่งนี้กลับกลายเป็นว่าไม่เพียงพอ: มีความประพฤติดี (แต่ ไม่เสียหาย) โหนดในองค์ประชุมของสมาชิกของ I can ภายใต้ อิทธิพลของโหนดที่ผิดพลาด ป้องกันการยุติโดยดำเนินการให้เสร็จสิ้น องค์ประชุมก่อนการลงคะแนนเสียงสิ้นสุดลงจึงทำให้ สมาชิกของกลุ่ม I จะต้องเลือกค่า x ที่แตกต่างกันในการลงคะแนนครั้งถัดไป ดังนั้นเราจึงต้องสันนิษฐานเพิ่มเติมว่าอย่างไม่เป็นทางการ แต่ละโหนดในองค์ประชุมของสมาชิกคนหนึ่งของฉันในที่สุดเช่นกัน ทันเวลาหรือไม่ส่งข้อความเลยในระยะเวลาที่เพียงพอ ในทางปฏิบัติ นี่หมายถึงสมาชิกของฉันอาจ ต้องปรับชิ้นจนกว่าสภาพจะคงอยู่ นี้ ปัญหาไม่มีอยู่ในระบบ FBA: Losa และคณะ [47] ปัจจุบัน โปรโตคอลที่ความมีชีวิตชีวาขึ้นอยู่กับจุดอ่อนที่อ่อนแอกว่าอย่างเคร่งครัด สมมติฐานของการซิงโครไนซ์ในท้ายที่สุดและการเลือกผู้นำในที่สุด โดยไม่จำเป็นต้องลบโหนดที่ผิดพลาดออกจากชิ้นส่วน

SCP'nin resmi doğrulaması

Tasarım hatalarını ortadan kaldırmak için SCP'nin güvenliğini resmi olarak doğruladık ve canlılık özellikleri (bkz. [65]). Özellikle, doğruladık iç içe geçmiş düğümlerin hiçbir zaman anlaşmazlığa düşmemesi ve aşağıda tartışılan koşullar altında, sağlam bir kümenin her üyesinin eninde sonunda karar vermesi. İlginç bir şekilde, doğrulama şunu ortaya çıkardı: SCP'nin canlılığı garanti ettiği koşullar incelikli, ve başlangıçta düşünülenden daha güçlü [68]: aşağıda tartışıldığı gibi, Aksi halde zamanlamayı değiştiren kötü niyetli düğümler protokolden sapmanın manuel olarak tahliye edilmesi gerekebilir çekirdek dilimlerinden.

SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. Özelliklerin mümkün olan her durumda geçerli olmasını sağlamak için FBA yapılandırmaları ve uygulamalarının keyfi olduğunu düşünüyoruz keyfi yerel konfigürasyonlara sahip düğümlerin sayısı. Bu ayrık bozulmamış kümelerin yanı sıra potansiyel olarak sonsuz uzunlukta yürütmelere sahip senaryoları içerir. Dezavantajımız şu ki Parametrelendirilmiş bir doğrulamanın zorlu sorunuyla karşı karşıya sonsuz durum sistemi. Doğrulamayı izlenebilir kılmak için, Ivy [69] ve [82] metodolojisini kullanarak SCP'yi birinci dereceden mantıkta (FOL) modelledik. Doğrulama süreci, daha sonra otomatik olarak kontrol edilen tümevarımsal varsayımların manuel olarak sağlanmasından oluşur. Sarmaşık. SCP'nin FOL modeli bazı yönleri özetliyor FOL'de yönetimi zor olan FBA sistemleri (örn. kaskad teoremi bir aksiyom olarak alınır), bu nedenle şunu doğrularız: Isabelle/HOL [75] kullanarak soyutlamanın sağlamlığı. Doğrulama problemini FOL'de ifade ettikten sonra, endüktif bir değişmez sağlayarak güvenliği doğruluyoruz. endüktif değişmez yaklaşık olarak bir düzine tek satırlık varsayımdan oluşur 150 satırlık protokol spesifikasyonu. Daha sonra Ivy'nin Doğrusal Zamansal Mantığı'nda SCP'nin canlılık özelliklerini belirliyoruz ve Canlılığı azaltmak için canlılıktan güvenliğe azalma [80, 81] doğrulama probleminden tümevarım bulma problemine değişmez. SCP'nin güvenliği nispeten basit olsa da SCP'nin canlılık argümanının çok daha karmaşık olduğunu kanıtlayın ve yaklaşık 150 tek satırlı değişmezden oluşur. Canlılığın kanıtlanması, kesin bir resmileştirmeyi gerektiriyordu. SCP'nin fesih sağladığı varsayımlar. Başlangıçta bozulmamış bir seti her zaman sonlandıracağımı düşündük. üyeler hatalı düğümleri dilimlerinden kaldırdı [68]. Ancak bunun yetersiz olduğu ortaya çıktı: iyi huylu (ama (sağlam değil) düğümün bir üye yeter sayısı altında, hatalı düğümlerin etkisi, tamamlanarak sonlandırmayı önleyin oylamanın bitiminden hemen önce yeter sayının sağlanması, dolayısıyla I üyeleri bir sonraki oylamada x'in farklı değerlerini seçecek. Bu nedenle ayrıca gayri resmi olarak şunu varsaymalıyız: I üyesinin yeterli çoğunluğundaki her düğüm sonunda zamanında geliyor veya yeterli bir süre boyunca hiç mesaj göndermiyor. Uygulamada bu, I üyelerinin durum devam edene kadar dilimlerini ayarlamaları gerekir. Bu sorun FBA sistemlerine özgü değildir: Losa ve ark. [47] mevcut canlılığı kesinlikle zayıf olana bağlı olan bir protokol hatalı düğümleri dilimlerden çıkarmaya gerek kalmadan, yalnızca nihai senkronizasyon ve nihai lider seçimi varsayımları.

เครือข่ายการชำระเงิน

ส่วนนี้จะอธิบายเครือข่ายการชำระเงินของ Stellar ซึ่งนำไปใช้เป็นเครื่องจำลองสถานะ [88] ที่ด้านบนของ SCP 5.1 แบบจำลองบัญชีแยกประเภท บัญชีแยกประเภทของ Stellar ได้รับการออกแบบโดยคำนึงถึงนามธรรมของบัญชี (ใน ตรงกันข้ามกับเอาท์พุตธุรกรรมที่ไม่ได้ใช้เหรียญเป็นศูนย์กลางมากกว่า หรือ UTXO โมเดลของ Bitcoin) เนื้อหาบัญชีแยกประเภทประกอบด้วย ชุดรายการบัญชีแยกประเภทสี่ประเภทที่แตกต่างกัน: บัญชี, สายที่เชื่อถือได้, ข้อเสนอและข้อมูลบัญชี บัญชีเป็นตัวการที่เป็นเจ้าของและออกสินทรัพย์ แต่ละ บัญชีถูกตั้งชื่อโดยกุญแจสาธารณะ ตามค่าเริ่มต้น คีย์ส่วนตัวที่เกี่ยวข้องสามารถลงนามธุรกรรมสำหรับบัญชีได้ อย่างไรก็ตาม คุณสามารถกำหนดค่าบัญชีใหม่เพื่อเพิ่มผู้ลงนามรายอื่นและยกเลิกการอนุญาตคีย์ที่ตั้งชื่อบัญชีได้โดยใช้ ตัวเลือก “multisig” เพื่อกำหนดให้ต้องมีผู้ลงนามหลายคน แต่ละบัญชี ประกอบด้วย: หมายเลขลำดับ (รวมอยู่ในธุรกรรม เพื่อป้องกันการเล่นซ้ำ) ธงบางส่วนและความสมดุลใน "พื้นเมือง" สกุลเงินดิจิทัลที่ขุดไว้ล่วงหน้าที่เรียกว่า XLM ซึ่งมีจุดประสงค์เพื่อลดผลกระทบ การโจมตีแบบปฏิเสธการให้บริการและอำนวยความสะดวกในการทำตลาด เป็นสกุลเงินที่เป็นกลาง Trustlines ติดตามความเป็นเจ้าของสินทรัพย์ที่ออกซึ่งได้แก่ ตั้งชื่อโดยคู่ที่ประกอบด้วยบัญชีผู้ออกและชอร์ต รหัสสินทรัพย์ (เช่น “USD” หรือ “EUR”) แต่ละ trustline ระบุ บัญชี สินทรัพย์ ยอดคงเหลือในบัญชีในสินทรัพย์นั้น ก เกินขีดจำกัดซึ่งยอดคงเหลือไม่สามารถเพิ่มขึ้นได้ และธงบางอัน บัญชีจะต้องยินยอมอย่างชัดเจนในการถือครองทรัพย์สินโดย สร้าง trustline เพื่อป้องกันไม่ให้ผู้ส่งอีเมลขยะต้องอานม้า บัญชีที่มีทรัพย์สินที่ไม่ต้องการ กฎระเบียบ Know-your-customer (KYC) กำหนดให้สถาบันการเงินหลายแห่งทราบว่าตนถือเงินฝากของใคร เช่นโดยการตรวจสอบบัตรประจำตัวที่มีรูปถ่าย เพื่อให้เป็นไปตามนั้นผู้ออกสามารถกำหนดได้ การตั้งค่าสถานะ auth_reqired ที่เป็นทางเลือกในบัญชีของพวกเขา ซึ่งจำกัดความเป็นเจ้าของเนื้อหาที่พวกเขาออกให้กับบัญชีที่ได้รับอนุญาต ในการให้อนุญาตดังกล่าว ผู้ออกจะตั้งค่าการอนุญาต ปักธงบนความไว้วางใจของลูกค้า ข้อเสนอที่สอดคล้องกับความเต็มใจของบัญชีในการแลกเปลี่ยน ไปยังสินทรัพย์จำนวนหนึ่งสำหรับอีกสินทรัพย์หนึ่ง ณ เวลาที่กำหนด ราคาในสมุดสั่งซื้อ พวกมันจะถูกจับคู่โดยอัตโนมัติและ เติมเมื่อราคาซื้อ/ขายข้าม สุดท้าย ข้อมูลบัญชีประกอบด้วยบัญชี คีย์ มูลค่าสามเท่า ช่วยให้เจ้าของบัญชี เพื่อเผยแพร่ค่าข้อมูลเมตาขนาดเล็ก เพื่อป้องกันสแปมบัญชีแยกประเภท มียอดคงเหลือ XLM ขั้นต่ำ เรียกว่าสำรอง ทุนสำรองของบัญชีจะเพิ่มขึ้นตามแต่ละบัญชี รายการบัญชีแยกประเภทที่เกี่ยวข้องและลดลงเมื่อรายการบัญชีแยกประเภท หายไป (เช่น เมื่อมีการกรอกหรือยกเลิกคำสั่งซื้อ หรือเมื่อ สายที่เชื่อถือได้จะถูกลบ) ปัจจุบันเงินสำรองเพิ่มขึ้น 0.5 XLM (∼$0.03) ต่อรายการบัญชีแยกประเภท ไม่ว่าจะเป็นเงินสำรองก็เป็นได้ เป็นไปได้ที่จะเรียกคืนมูลค่าทั้งหมดของบัญชีโดยการลบ ด้วยการดำเนินการ AccountMerge ส่วนหัวของบัญชีแยกประเภท แสดงในรูปที่ 3 จัดเก็บแอตทริบิวต์ส่วนกลาง: หมายเลขบัญชีแยกประเภท พารามิเตอร์ เช่น ยอดคงเหลือต่อ รายการบัญชีแยกประเภท hash ของส่วนหัวบัญชีแยกประเภทก่อนหน้า (อันที่จริง hashes หลายรายการสร้างรายการข้าม) เอาต์พุต SCP รวมถึง hash ของธุรกรรมใหม่ที่ใช้กับบัญชีแยกประเภทนี้, hash จาก ผลลัพธ์ของธุรกรรมเหล่านั้น (เช่น สำเร็จหรือล้มเหลวสำหรับ แต่ละรายการ) และสแน็ปช็อต hash ของรายการบัญชีแยกประเภททั้งหมด เนื่องจากสแน็ปช็อต hash มีเนื้อหาบัญชีแยกประเภททั้งหมด validators ไม่จำเป็นต้องเก็บประวัติเพื่อตรวจสอบธุรกรรม อย่างไรก็ตามจะขยายไปถึงหลายร้อยล้านที่คาดไว้ บัญชี เราไม่สามารถ rehash ตารางรายการบัญชีแยกประเภททั้งหมดในทุก ๆ ปิดบัญชีแยกประเภท นอกจากนี้ การโอนบัญชีแยกประเภทไม่สามารถทำได้การชำระเงินทั่วโลกที่รวดเร็วและปลอดภัยด้วย Stellar SOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา บัญชีแยกประเภท # = 4 H(ก่อนหน้า hdr) เอาท์พุท SCP H∗(ผลลัพธ์) H∗(สแนปช็อต) ... ส่วนหัว บัญชีแยกประเภท # = 5 H(ก่อนหน้า hdr) เอาท์พุท SCP H∗(ผลลัพธ์) H∗(สแนปช็อต) ... ส่วนหัว . . . รูปที่ 3 เนื้อหาบัญชีแยกประเภท H คือ SHA-256 ในขณะที่ H ∗ แสดงถึงการประยุกต์ใช้แบบลำดับชั้นหรือแบบเรียกซ้ำของเอาต์พุต H. SCP ยังขึ้นอยู่กับส่วนหัวก่อนหน้า hash สร้างบัญชี สร้างและฝากเงินเข้าบัญชีแยกประเภทบัญชีใหม่ การรวมบัญชี ลบรายการบัญชีแยกประเภทบัญชี ตั้งค่าตัวเลือก เปลี่ยนสถานะบัญชีและผู้ลงนาม การชำระเงิน ชำระสินทรัพย์ตามจำนวนที่ต้องการเพื่อทำลาย บัญชี เส้นทางการชำระเงิน ชอบจ่ายเงินแต่จ่ายเป็นสินทรัพย์ต่างกัน (ขึ้นไป เพื่อจำกัด); ระบุสินทรัพย์ตัวกลางได้สูงสุด 5 รายการ จัดการข้อเสนอ สร้าง/ลบ/เปลี่ยนแปลงรายการบัญชีแยกประเภทข้อเสนอ -ข้อเสนอแบบพาสซีฟ ด้วยตัวแปรแบบพาสซีฟเพื่อให้สเปรดเป็นศูนย์ จัดการข้อมูล สร้าง/ลบ/เปลี่ยนแปลงบัญชี รายการบัญชีแยกประเภทข้อมูล เปลี่ยนความไว้วางใจ สร้าง/ลบ/เปลี่ยน trustline อนุญาตความไว้วางใจ ตั้งค่าหรือล้างธงที่ได้รับอนุญาตบนสายที่เชื่อถือได้ BumpSequence เพิ่มลำดับ หมายเลขในบัญชี รูปที่ 4 การดำเนินการบัญชีแยกประเภทหลัก ขนาดนั้นทุกครั้งที่โหนดถูกตัดการเชื่อมต่อ เครือข่ายนานเกินไป สแนปชอต hash จึงเป็นเช่นนั้น ออกแบบมาเพื่อเพิ่มประสิทธิภาพทั้ง hashing และการกระทบยอดสถานะ โดยเฉพาะอย่างยิ่ง สแน็ปช็อตจะแบ่งชั้นรายการบัญชีแยกประเภทตามเวลา ของการแก้ไขครั้งล่าสุดในชุดคอนเทนเนอร์ที่มีขนาดเอ็กซ์โปเนนเชียล เรียกว่าถัง การรวบรวมถังเรียกว่าถัง รายการ และมีความคล้ายคลึงกับต้นไม้ผสานที่มีโครงสร้างบันทึก (ต้นไม้ LSM) [77]. รายการถังจะไม่ถูกอ่านในระหว่างการประมวลผลธุรกรรม (ดูหัวข้อ 5.4) ดังนั้นการออกแบบบางอย่าง ลักษณะของต้นไม้ LSM สามารถผ่อนคลายได้ โดยเฉพาะการสุ่ม ไม่จำเป็นต้องเข้าถึงด้วยคีย์ และที่เก็บข้อมูลจะถูกอ่านเท่านั้น ตามลำดับซึ่งเป็นส่วนหนึ่งของระดับการผสาน กำลังแฮชถัง รายการเสร็จสิ้นโดย hash แต่ละที่เก็บข้อมูลเมื่อมีการผสานและคำนวณ hash สะสมใหม่ของที่เก็บข้อมูล hashes (ขนาดเล็ก ดัชนีอ้างอิงคงที่ hashes) ที่แต่ละบัญชีแยกประเภทปิด การกระทบยอดรายการฝากข้อมูลหลังจากขาดการเชื่อมต่อจำเป็นต้องดาวน์โหลด เฉพาะถังที่แตกต่างกัน 5.2 รูปแบบการทำธุรกรรม ธุรกรรมประกอบด้วยบัญชีต้นทาง เกณฑ์ความถูกต้อง ก บันทึกช่วยจำ และรายการการดำเนินการตั้งแต่หนึ่งรายการขึ้นไป รูปที่ 4 แสดงการดำเนินการที่มีอยู่ การดำเนินการแต่ละครั้งมีบัญชีต้นทางซึ่ง ค่าเริ่มต้นของธุรกรรมโดยรวม การทำธุรกรรมจะต้อง ลงนามด้วยคีย์ที่สอดคล้องกับทุกบัญชีต้นทาง การดำเนินการ บัญชี Multisig อาจต้องมีการลงนามที่สูงกว่า น้ำหนักสำหรับการดำเนินการบางอย่าง (เช่น SetOptions) และต่ำกว่า สำหรับผู้อื่น (เช่น AllowTrust) ธุรกรรมเป็นแบบอะตอมมิก หากการดำเนินการใดๆ ล้มเหลว จะไม่มีการดำเนินการใดเลย พวกเขาดำเนินการ สิ่งนี้ทำให้ข้อตกลงหลายทางง่ายขึ้น สมมุติว่าอัน ผู้ออกสร้างสินทรัพย์เพื่อแสดงโฉนดที่ดินและผู้ใช้ก ต้องการแลกเปลี่ยนที่ดินผืนเล็กบวก $10,000 เป็นเงิน ที่ดินแปลงใหญ่ที่บีเป็นเจ้าของ ผู้ใช้ทั้งสองคนสามารถลงนามได้ทั้งคู่ ธุรกรรมเดียวที่มีสามการดำเนินงาน: สองที่ดิน การชำระเงินและการชำระหนึ่งดอลลาร์ เกณฑ์ความถูกต้องหลักของธุรกรรมคือหมายเลขลำดับ ซึ่งจะต้องมากกว่าเกณฑ์ของธุรกรรม รายการบัญชีแยกประเภทแหล่งที่มา ดำเนินธุรกรรมที่ถูกต้อง (สำเร็จหรือไม่) เพิ่มหมายเลขลำดับ เพื่อป้องกันการเล่นซ้ำ หมายเลขลำดับเริ่มต้นประกอบด้วยบัญชีแยกประเภท ให้เป็นบิตสูงเพื่อป้องกันการเล่นซ้ำแม้จะลบไปแล้วก็ตาม และสร้างบัญชีใหม่ เกณฑ์ความถูกต้องอื่นๆ คือขีดจำกัดที่เป็นทางเลือกว่าเมื่อใด ธุรกรรมสามารถดำเนินการได้ กลับคืนสู่ดินแดนและดอลลาร์ สลับด้านบน หาก A ลงนามในธุรกรรมก่อน B, A อาจไม่ อยากให้บีนั่งทำธุรกรรมเป็นเวลาหนึ่งปีก่อนที่จะส่ง มันและอาจกำหนดระยะเวลาที่ทำให้ธุรกรรมเป็นโมฆะ หลังจากนั้นไม่กี่วัน สามารถกำหนดค่าบัญชี Multisig ได้ เพื่อให้การลงนามมีน้ำหนักต่อการเปิดเผยของภาพล่วงหน้า hash ซึ่งเมื่อรวมกับขอบเขตเวลา อนุญาตให้มีการซื้อขาย atomic crosschain [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, Huntsville, ON, แคนาดา โลกาวา และคณะ validator แกนกลาง ขอบฟ้า เอฟเอส ดีบี ดีบี ส่ง ลูกค้า ลูกค้า validators อื่นๆ รูปที่ 5. Stellar validator สถาปัตยกรรม รู้วิธีการปฏิบัติ) มีการกำหนดค่าการอัพเกรดที่ต้องการ ทริกเกอร์ในเวลาที่กำหนดโดยมีวัตถุประสงค์เพื่อประสานงานระหว่างกัน ตัวดำเนินการ โหนดที่ควบคุมมักจะลงคะแนนให้เสนอชื่อที่ต้องการ อัปเกรด ยอมรับแต่อย่าลงคะแนนเพื่อเสนอการอัปเกรดที่ถูกต้อง (เช่น ดำเนินการตามองค์ประชุมที่ปิดกั้น) และไม่ต้องลงคะแนนเสียงให้ หรือยอมรับการอัพเกรดที่ไม่ถูกต้อง เสียงสะท้อน validators ที่ไม่อยู่ภายใต้การควบคุม การลงคะแนนใดๆ ที่พวกเขาเห็นสำหรับการอัพเกรดที่ถูกต้อง โดยพื้นฐานแล้วเป็นการมอบหมาย การตัดสินใจว่าต้องการอัปเกรดอะไรสำหรับผู้ที่เลือก เพื่อทำหน้าที่กำกับดูแล 5.4 การนำไปปฏิบัติ รูปที่ 5 แสดงสถาปัตยกรรม validator ของ Stellar ภูต เรียกว่า stellar-core (∼92k บรรทัดของ C ++ ไม่นับไลบรารีบุคคลที่สาม) ใช้โปรโตคอล SCP และเครื่องสถานะที่จำลองแบบ การสร้างมูลค่าสำหรับ SCP จำเป็นต้องลดรายการบัญชีแยกประเภทจำนวนมากให้เหลือเพียงการเข้ารหัสขนาดเล็ก hashส. ในทางตรงกันข้าม การตรวจสอบและดำเนินการธุรกรรม ต้องค้นหาสถานะบัญชีและการจับคู่คำสั่งซื้อที่ ราคาที่ดีที่สุด เพื่อให้บริการทั้งสองฟังก์ชั่นได้อย่างมีประสิทธิภาพ stellar-core เก็บการเป็นตัวแทนของบัญชีแยกประเภทไว้สองรายการ: การเป็นตัวแทนภายนอกที่มีรายการถังซึ่งจัดเก็บเป็นไฟล์ไบนารี่นั้น สามารถอัปเดตได้อย่างมีประสิทธิภาพและเพิ่มขึ้นเรื่อยๆ rehashed และ การแสดงภายในในฐานข้อมูล SQL (PostgreSQL สำหรับโหนดการผลิต) Stellar-core สร้างไฟล์เก็บถาวรประวัติแบบเขียนอย่างเดียวที่มี แต่ละชุดธุรกรรมที่ได้รับการยืนยันและภาพรวมของ ถัง ไฟล์เก็บถาวรช่วยให้โหนดใหม่สามารถบู๊ตตัวเองได้ เมื่อเข้าร่วมเครือข่าย อีกทั้งยังมีบันทึกบัญชีแยกประเภทอีกด้วย ประวัติศาสตร์—จำเป็นต้องมีสถานที่ที่สามารถค้นหาได้ ธุรกรรมเมื่อสองปีที่แล้ว เนื่องจากประวัติศาสตร์เป็นเพียงการผนวกเท่านั้น และเข้าถึงไม่บ่อยก็สามารถเก็บไว้ในที่ราคาถูกได้ เช่น Amazon Glacier หรือบริการใดๆ ที่อนุญาตให้จัดเก็บได้ และดึงไฟล์แฟลต โดยทั่วไปแล้วโฮสต์ของเครื่องมือตรวจสอบจะไม่โฮสต์ ที่เก็บถาวรของตนเองเพื่อหลีกเลี่ยงผลกระทบต่อการตรวจสอบ ประสิทธิภาพจากประวัติการเสิร์ฟ เพื่อให้ stellar-core เรียบง่าย จึงไม่ได้ตั้งใจจะใช้ โดยตรงโดยแอปพลิเคชันและเปิดเผยเฉพาะอินเทอร์เฟซที่แคบมากสำหรับการส่งธุรกรรมใหม่ เพื่อรองรับ ลูกค้า validators ส่วนใหญ่เรียกใช้ daemon ที่เรียกว่าขอบฟ้า (∼18k lines of Go) ที่มีอินเทอร์เฟซ HTTP สำหรับการส่ง และการเรียนรู้ธุรกรรม Horizon มีสิทธิ์เข้าถึงแบบอ่านอย่างเดียว ฐานข้อมูล SQL ของ stellar-core ช่วยลดความเสี่ยงของเส้นขอบฟ้า แกนดาวฤกษ์ที่ไม่เสถียร คุณสมบัติต่างๆ เช่น การค้นหาเส้นทางการชำระเงินนั้นถูกนำไปใช้งานอย่างสมบูรณ์และสามารถอัปเกรดได้ ฝ่ายเดียวโดยไม่ประสานงานกับ validators อื่น ๆ daemons เลเยอร์ที่เป็นตัวเลือกที่สูงกว่าหลายตัวเป็นไคลเอนต์ที่ขอบฟ้า ล้อมรอบระบบนิเวศ บริดจ์เซิร์ฟเวอร์อำนวยความสะดวก การบูรณาการ Stellar กับระบบที่มีอยู่ เช่น การโพสต์การแจ้งเตือนการชำระเงินทั้งหมดที่ได้รับจากบัญชีเฉพาะ ก เซิร์ฟเวอร์การปฏิบัติตามกฎระเบียบมอบ hooks สำหรับสถาบันการเงิน แลกเปลี่ยนและอนุมัติข้อมูลผู้ส่งและผู้รับผลประโยชน์ ในการชำระเงินเพื่อให้สอดคล้องกับรายการคว่ำบาตร สุดท้ายนี้ เซิร์ฟเวอร์รวมใช้การตั้งชื่อที่มนุษย์สามารถอ่านได้ ระบบบัญชี. 6 ประสบการณ์การใช้งาน Stellar เติบโตเป็นเวลาหลายปีจนกลายเป็นรัฐที่มีระดับปานกลาง จำนวนตัวดำเนินการโหนดเต็มรูปแบบที่เชื่อถือได้พอสมควร อย่างไรก็ตาม การกำหนดค่าของโหนดนั้นมีความมีชีวิตชีวา (แม้ว่าจะไม่ใช่ก็ตาม ความปลอดภัย) ขึ้นอยู่กับเรา มูลนิธิ Stellar การพัฒนา (เอสดีเอฟ); หาก SDF หายไปอย่างกะทันหัน ผู้ดำเนินการโหนดรายอื่น จะต้องเข้ามาแทรกแซงและลบเราออกด้วยตนเอง จากส่วนโควรัมเพื่อให้เครือข่ายดำเนินการต่อ แม้ว่าเราและคนอื่นๆ ต้องการลดความสำคัญเชิงระบบของ SDF แต่เป้าหมายนี้ก็ได้รับลำดับความสำคัญเพิ่มมากขึ้นหลังจากนั้น นักวิจัย [58] ระบุปริมาณและเผยแพร่การรวมศูนย์ของเครือข่ายโดยไม่แยกแยะความเสี่ยงด้านความปลอดภัยและ ความมีชีวิตชีวา ผู้ปฏิบัติงานจำนวนหนึ่งตอบสนองต่อการปรับเปลี่ยนการกำหนดค่าที่ใช้งานอยู่ โดยหลักๆ แล้วจะเป็นการเพิ่มขนาดของพวกเขา แบ่งองค์ประชุมเพื่อลดความสำคัญของ SDF; น่าแปลกที่สิ่งนี้เพิ่มความเสี่ยงต่อความมีชีวิตชีวาเท่านั้น ปัญหาสองประการทำให้สถานการณ์รุนแรงขึ้น อันดับแรกเป็นที่นิยม เครื่องมือตรวจสอบบุคคลที่สาม Stellar [5] เป็นระบบ ประเมินเวลาทำงาน validator สูงเกินไปโดยไม่ตรวจสอบจริง แกนดาวฤกษ์นั้นกำลังทำงานอยู่ สิ่งนี้ทำให้ผู้คนรวม โหนดที่ไม่น่าเชื่อถือในส่วนโควรัม ประการที่สอง มีข้อบกพร่องใน stellar-core หมายถึงเมื่อ validator ย้ายไปยังบัญชีแยกประเภทถัดไป มันไม่ได้ช่วยให้โหนดที่เหลือทำ previ ได้เพียงพอบัญชีแยกประเภทในกรณีที่ข้อความสูญหาย เป็นผลให้ เครือข่ายประสบปัญหาการหยุดทำงานเป็นเวลา 67 นาทีและจำเป็น การประสานงานด้วยตนเองโดยผู้ดูแลระบบ validator เพื่อรีสตาร์ท ที่แย่กว่านั้นคือในขณะที่พยายามรีสตาร์ทเครือข่าย ส่งผลให้มีการกำหนดค่าใหม่อย่างรวดเร็วบนหลายโหนด ในการกำหนดค่าที่ไม่ถูกต้องโดยรวมซึ่งทำให้บางโหนดสามารถ แยกออกจากกันโดยต้องมีการปิดโหนดเหล่านั้นด้วยตนเองและ ส่งธุรกรรมที่ยอมรับอีกครั้งระหว่างความแตกต่าง โชคดีที่ความแตกต่างนี้ถูกจับได้และแก้ไขแล้ว อย่างรวดเร็วและไม่มีธุรกรรมที่ขัดแย้งกัน แต่ ความเสี่ยงที่เครือข่ายไม่สามารถเพลิดเพลินกับจุดตัดองค์ประชุม— แยกทางกันในขณะที่ยังคงยอมรับความขัดแย้งที่อาจขัดแย้งกันต่อไป มีการทำธุรกรรมเพียงเพราะการกำหนดค่าที่ไม่ถูกต้อง เหตุการณ์นี้เป็นรูปธรรมมาก การทบทวนประสบการณ์เหล่านี้นำไปสู่ข้อสรุปที่สำคัญสองประการ และการดำเนินการแก้ไขที่สอดคล้องกันการชำระเงินทั่วโลกที่รวดเร็วและปลอดภัยด้วย Stellar SOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา สำคัญ 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 การตรวจสอบจุดตัดองค์ประชุม แม้ว่าการรวบรวมโควรัมสไลซ์จะเป็นเรื่องง่าย แต่การค้นหาโควรัมที่ไม่ต่อเนื่องกันนั้นถือเป็น NP-hard ร่วมกัน [62] อย่างไรก็ตาม เราก็รับเอา ชุดของการวิเคราะห์พฤติกรรมอัลกอริทึมและกฎการกำจัดตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ เสนอโดย Lachowski [62] ที่ตรวจสอบอินสแตนซ์ทั่วไป ของปัญหาที่มีขนาดเร็วกว่านั้นหลายเท่า ต้นทุนกรณีที่เลวร้ายที่สุด ในทางปฏิบัติแล้วเครือข่ายในปัจจุบัน การปิดสกรรมกริยาโควรัมสไลซ์อยู่ในลำดับ 20–30 โหนดและโดยทั่วไปจะตรวจสอบด้วยการเพิ่มประสิทธิภาพของ Lachowski ภายในเวลาไม่กี่วินาทีบน CPU ตัวเดียว หากมีความจำเป็นเกิดขึ้น เพื่อเพิ่มประสิทธิภาพ เราอาจทำการค้นหาแบบขนาน 6.2.2 กำลังตรวจสอบการกำหนดค่าที่มีความเสี่ยง การตรวจพบว่าเครือข่ายยอมรับโควรัมที่ไม่เป็นสมาชิกร่วมนั้นเป็นขั้นตอนหนึ่ง ไปถูกทางแต่ส่งสัญญาณอันตรายช้าอย่างไม่สบายใจ สำหรับปัญหาที่สำคัญเช่นนี้ ตามหลักการแล้ว เราต้องการให้ผู้ดำเนินการโหนดได้รับคำเตือนเมื่อมีการกำหนดค่าโดยรวมของเครือข่าย กำลังเข้าสู่ภาวะเสี่ยงเท่านั้น ดังนั้นเราจึงขยายตัวตรวจสอบโควรัม-ทางแยก เพื่อตรวจจับสภาวะที่เราเรียกว่าวิกฤต: เมื่อกระแส การกำหนดค่าโดยรวมคือการกำหนดค่าที่ไม่ถูกต้องอย่างหนึ่ง รัฐที่ยอมรับองค์ประชุมที่ไม่ต่อเนื่องกัน เพื่อตรวจจับภาวะวิกฤติ ตัวตรวจสอบจะแทนที่การกำหนดค่าของแต่ละองค์กรซ้ำแล้วซ้ำอีกด้วยการกำหนดค่าที่ไม่ถูกต้องที่เลวร้ายที่สุดจำลอง รันตัวตรวจสอบจุดตัดโควรัมด้านในกับผลลัพธ์อีกครั้ง หากมีการกำหนดค่าผิดพลาดร้ายแรงดังกล่าวอยู่อีกขั้นตอนหนึ่ง จากสถานะปัจจุบันซอฟต์แวร์จะออกคำเตือนและ รายงานองค์กรที่มีความเสี่ยงในการกำหนดค่าที่ไม่ถูกต้อง การเปลี่ยนแปลงเหล่านี้ทำให้ชุมชนของผู้ปฏิบัติงานมีสองชั้น การแจ้งเตือนและคำแนะนำเพื่อป้องกันรูปแบบที่เลวร้ายที่สุด ของการกำหนดค่าผิดพลาดร่วมกัน

Ödeme ağı

Bu bölümde, Stellar'nin, SCP'nin üzerinde kopyalanmış bir durum makinesi [88] olarak uygulanan ödeme ağı açıklanmaktadır. 5.1 Defter modeli Stellar'in defteri, hesap soyutlaması etrafında tasarlanmıştır (içinde daha çok madeni para merkezli harcanmamış işlem çıktısının aksine veya UTXO modelinin Bitcoin modeli). Defterin içeriği şunlardan oluşur: Dört farklı türden defter girişleri kümesi: hesaplar, güven hatları, teklifler ve hesap verileri. Hesaplar, varlıkların sahibi olan ve ihraç eden müdürlerdir. Her biri hesap genel anahtarla adlandırılır. Varsayılan olarak karşılık gelen özel anahtar, hesap için işlemleri imzalayabilir. Ancak hesaplar, başka imzalayanlar eklemek ve hesabı adlandıran anahtarın yetkisini kaldırmak için yeniden yapılandırılabilir. Birden fazla imzalayanın kullanılmasını gerektiren "multisig" seçeneği. Her hesap ayrıca şunları içerir: bir sıra numarası (işlemlere dahil edilir) tekrarı önlemek için), bazı bayraklar ve “yerel” bir denge hafifletmeyi amaçlayan, XLM adı verilen önceden çıkarılmış kripto para birimi bazı hizmet reddi saldırıları ve pazar oluşumunu kolaylaştırma nötr bir para birimi olarak. Trustlines, ihraç edilen varlıkların sahipliğini takip eder. veren hesap ve kısa bir hesaptan oluşan bir çift tarafından adlandırılır. varlık kodu (ör. "USD" veya "EUR"). Her güven hattı şunları belirtir: bir hesap, bir varlık, hesabın o varlıktaki bakiyesi, bir dengenin üzerine çıkamayacağı limit ve bazı bayraklar. Bir hesap, bir varlığın elde tutulmasına açıkça izin vermelidir: Spam gönderenlerin engellenmesini önleyen bir güven hattı oluşturmak İstenmeyen varlıklara sahip hesaplar. Müşterinizi Tanıyın (KYC) düzenlemeleri, birçok finans kuruluşunun kimin mevduatını tuttuğunu bilmesini gerektirir. örneğin fotoğraflı kimliği kontrol ederek. Uyumluluk için, ihraççılar ayarlayabilir Hesaplarında isteğe bağlı bir auth_reqired bayrağı yer alıyor ve verdikleri varlıkların sahipliğini yetkili hesaplarla sınırlıyorlar. Bu yetkiyi vermek için ihraççı, yetkili bir Müşterilerin güven hatlarını işaretleyin. Teklifler bir hesabın takas yapma isteğine karşılık gelir Belirli bir varlık için belirli bir miktardaki bir başka varlığa belirli bir zamanda sipariş defterindeki fiyat; otomatik olarak eşleştirilirler ve alış/satış fiyatları kesiştiğinde doldurulur. Son olarak hesap verileri hesap, anahtar, değer üçlülerinden oluşur ve hesap sahiplerine izin verir. küçük meta veri değerlerini yayınlamak için. Defter spam'ını önlemek için minimum XLM bakiyesi vardır, rezerv denir. Bir hesabın rezervi her biri ile artar ilgili defter girişi ve defter girişi yapıldığında azalır kaybolur (örn. bir sipariş yerine getirildiğinde veya iptal edildiğinde ya da güven hattı silinir). Şu anda rezerv 0,5 XLM artıyor (∼$0,03) defter girişi başına. Rezerv ne olursa olsun, silerek bir hesabın tüm değerini geri almak mümkün Bunu bir AccountMerge işlemiyle yapın. Şekil 3'te gösterilen genel muhasebe başlığı genel nitelikleri saklar: bir defter numarası, rezerv bakiyesi gibi parametreler defter girişi, önceki defter başlığının hash'si (aslında birkaç hashes bir atlama listesi oluşturur), SCP çıktısı şunları içerir: bu deftere hash yeni işlem uygulandı, hash bu işlemlerin sonuçları (örneğin, başarı veya başarısızlık) her biri) ve tüm genel muhasebe girişlerinin anlık görüntüsü hash. hash anlık görüntüsü tüm defter içeriğini içerdiğinden, validators'nin işlemleri doğrulamak için geçmişi saklamasına gerek yoktur. Ancak yüz milyonlarca beklenen sayıya ölçeklendirmek için hesaplarda, her hesapta tüm genel muhasebe giriş tablolarını yenidenhash yeniden yapamıyoruz. defter yakın. Ayrıca defter aktarımı pratik değildir.Stellar ile hızlı ve güvenli global ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada defter numarası = 4 H(önceki hdr) SCP çıkışı H∗(sonuçlar) H∗(anlık görüntü) ... başlık defter numarası = 5 H(önceki hdr) SCP çıkışı H∗(sonuçlar) H∗(anlık görüntü) ... başlık . . . Şekil 3. Defter içeriği. H, SHA-256'dir; H ∗, H.SCP çıktısının hiyerarşik veya özyinelemeli uygulamasını temsil eder aynı zamanda önceki başlığa da bağlıdır hash. Hesap Oluştur Yeni hesap defteri girişi oluşturun ve finanse edin HesapBirleştirme Hesap defteri girişini sil Seçenekleri Ayarla Hesap işaretlerini ve imzalayanları değiştirme Ödeme Hedefe belirli miktarda varlık ödeyin. kanun. YolÖdeme Ödemeyi beğenin, ancak farklı bir varlıkla ödeme yapın (yukarı sınırlamak için); 5'e kadar aracı varlık belirtin Teklifi Yönet Teklif defteri girişi oluşturma/silme/değiştirme, -PasifTeklif sıfır yayılmaya izin veren pasif değişkenli Verileri Yönet Hesap oluştur/sil/değiştir. veri defteri girişi Güveni Değiştir Güven hattı oluştur/sil/değiştir İzin VerGüven Güven hattında yetkili bayrağını ayarlayın veya temizleyin Çarpma Sırası Sırayı artırın hesaptaki numara Şekil 4. Ana defter işlemleri bir düğümün bağlantısı her kesildiğinde bu boyutta ağ çok uzun süredir. Bu nedenle anlık görüntü hash hem hashing hem de durum uzlaşmasını optimize etmek için tasarlanmıştır. Özellikle, anlık görüntü genel muhasebe girişlerini zamana göre katmanlandırır üstel boyutlu kaplar kümesindeki son değişiklik kovalar denir. Kovaların toplanmasına kova denir listesidir ve log yapılı birleştirme ağaçlarıyla bazı benzerlikler taşır (LSM ağaçları) [77]. Yapılacaklar listesi işlem gerçekleştirilirken okunmaz (bkz. Bölüm 5.4). Bu nedenle belirli bir tasarım LSM ağaçlarının bazı yönleri gevşetilebilir. Özellikle rastgele anahtarla erişim gerekli değildir ve paketler yalnızca okunur seviyelerin birleştirilmesinin parçası olarak sırayla. Kovayı karıştırmak liste, birleştirilirken her bir paket hash'ye tabi tutularak ve hashes paketinin (küçük, her defter kapanışında sabit referans indeksi hashes). Bağlantı kesildikten sonra yapılacaklar listesinin uzlaştırılması, indirmeyi gerektirir yalnızca kovalar farklıdır. 5.2 İşlem modeli Bir işlem kaynak hesaptan, geçerlilik kriterlerinden ve not ve bir veya daha fazla işlemin listesi. Şekil 4'te mevcut işlemler listelenmektedir. Her işlemin bir kaynak hesabı vardır. varsayılan olarak genel işlemin varsayılanıdır. Bir işlem yapılmalı içindeki her kaynak hesaba karşılık gelen anahtarlar tarafından imzalanacaktır. bir operasyon. Çoklu imzalı hesaplar daha yüksek imza gerektirebilir bazı işlemler için ağırlık (SetOptions gibi) ve daha düşük diğerleri için (AllowTrust gibi). İşlemler atomiktir; herhangi bir işlem başarısız olursa hiçbiri idam ederler. Bu, çok yönlü anlaşmaları basitleştirir. varsayalım ki ihraççı, arazi tapularını temsil edecek bir varlık oluşturur ve A kullanıcısı Küçük bir arazi parselini artı 10.000 $'la takas etmek istiyor B'ye ait olan daha büyük arazi parseli. İki kullanıcı da imza atabilir üç işlemi içeren tek bir işlem: iki arazi ödemeler ve bir dolar ödeme. Bir işlemin ana geçerlilik kriteri, işlemin sıra numarasından bir büyük olması gereken sıra numarasıdır. kaynak hesap defteri girişi. Geçerli bir işlemin yürütülmesi (başarılı olsun ya da olmasın) sıra numarasını artırarak tekrar oynatmayı engeller. İlk sıra numaraları defteri içerir Sildikten sonra bile tekrar oynatmayı önlemek için yüksek bitlerdeki sayı ve bir hesabı yeniden oluşturma. Diğer geçerlilik kriteri ise ne zaman yapılacağına ilişkin isteğe bağlı bir sınırdır. bir işlem yürütülebilir. Toprağa ve dolara dönüş yukarıdaki takas, eğer A işlemi B'den önce imzalarsa, A bunu yapmayabilir B'nin göndermeden önce bir yıl boyunca işlemde kalmasını istiyor ve böylece işlemi geçersiz kılan bir zaman sınırı koyabilir birkaç gün sonra. Multisig hesapları da yapılandırılabilir hash ön görüntünün ortaya çıkmasına imza ağırlığı vermek, bu, zaman sınırlarıyla birlikte atomik çapraz zincir ticaretine izin verir [1]. Bir işlemin kaynak hesabı XLM'de önemsiz bir ücret öder, Tıkanıklık olmadığı sürece 10−5 XLM. Sıkışıklık altında, Operasyonların maliyeti Hollanda açık artırmasıyla belirlenir. Doğrulayıcılar validator'lar benzer olduğundan ücretlerle karşılanmıyor madencilere değil, Bitcoin tam düğümlere. XLM'yi yok etmek yerine, ücretler geri dönüştürülür ve oylamayla orantılı olarak dağıtılır geçmişe bakıldığında mevcut XLM sahipleri karmaşıklığa değmedi. 5.3 Konsensüs değerleri Her defter için Stellar, bir veri yapısı üzerinde anlaşmak amacıyla SCP'yi kullanır üç alanlı: hash işlem kümesi (hash dahil) önceki genel muhasebe başlığının), yakın bir zaman, bird yükseltmeleri. Birden fazla değerin aday gösterildiği onaylandığında, Stellar alınır en fazla işlemi içeren işlem seti (bağları koparmak) toplam ücretlere göre, ardından işlem seti hash), hepsinin birleşimi yükseltmeler ve en yüksek kapanış süresi. Yakın bir zaman sadece son defterin kapanış zamanı ile son defterin kapanış zamanı arasında ise geçerlidir. mevcut olduğundan düğümler geçersiz süreleri belirtmez. Yükseltmeler, rezerv bakiyesi, minimum işletim ücreti ve protokol sürümü gibi genel parametreleri ayarlar. Ne zaman aday gösterme sırasında bir araya getirildiğinde, yüksek ücretler ve protokol sürüm numaraları düşük olanların yerini alır. Yükseltmeler, federal oylama mücadele alanı [34] aracılığıyla yönetimi etkiler; ikisi de eşitlikçi ve merkezi değil. Her validator şu şekilde yapılandırılmıştır: göre, yöneten ya da olmayan (varsayılan), operatörünün yönetişime katılmak isteyip istemediğine bağlıdır. validator'leri yönetenler üç tür yükseltmeyi dikkate alır: istenen, geçerli ve geçersiz (validator'nin yapmadığı herhangi bir şey)

SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. validator çekirdek ufuk FS Veritabanı Veritabanı gönder müşteri müşteri diğer validators Şekil 5. Stellar validator mimarisi nasıl uygulanacağını biliyorum). İstenilen yükseltmeler şu şekilde yapılandırılmıştır: arasında koordine edilmesi amaçlanan, belirli bir zamanda tetiklenmesi operatörler. Yönetici düğümler her zaman istenen adaya oy verir yükseltmeleri kabul edin ancak geçerli yükseltmeleri aday göstermek için oy vermeyin (yani, engelleme yeter çoğunluğuna uyun) ve asla oy vermeyin. veya geçersiz yükseltmeleri kabul edin. Yönetim dışı validators echo geçerli bir yükseltme için gördükleri herhangi bir oy, esasen yetki devri tercih edenler için hangi yükseltmelerin istendiğine ilişkin karar bir yönetim rolü için. 5.4 Uygulama Şekil 5, Stellar'nin validator mimarisini göstermektedir. Bir şeytan Stellar-core olarak adlandırılan (∼92k C++ satırı, üçüncü taraf kitaplıkları sayılmaz) SCP protokolünü ve çoğaltılmış durum makinesini uygular. SCP için değer üretmek, çok sayıdaki defter girişini küçük kriptografik girişlere azaltmayı gerektirir hashes. Buna karşılık, işlem doğrulama ve yürütme hesap durumuna ve sipariş eşleşmesine bakmayı gerektirir en iyi fiyat. Her iki işlevi de verimli bir şekilde yerine getirmek için yıldız çekirdeği Defterin iki temsilini tutar: ikili dosyalar olarak saklanan, yapılacaklar listesini içeren harici bir temsil. verimli bir şekilde güncellenebilir ve artımlı olarak yeniden hashed edilebilir ve SQL veritabanındaki dahili bir temsil (PostgreSQL üretim düğümleri için). Stellar-core, aşağıdakileri içeren salt okunur bir geçmiş arşivi oluşturur: onaylanan her işlem seti ve bunların anlık görüntüleri kovalar. Arşiv, yeni düğümlerin kendilerini önyüklemesine olanak tanıyor ağa katıldığınızda. Aynı zamanda bir defter kaydı sağlar tarih—birinin arayabileceği bir yer olması gerekiyor iki yıl önceki işlem. Geçmiş yalnızca ekleme amaçlı olduğundan ve nadiren erişildiği için ucuz yerlerde saklanabilir Amazon Glacier veya depolamaya izin veren herhangi bir hizmet gibi ve düz dosyaları alın. Doğrulayıcı ana bilgisayarlar genellikle barındırmaz Doğrulama üzerinde herhangi bir etkiyi önlemek için kendi arşivleri Hizmet geçmişinden performans. Yıldız çekirdeğini basit tutmak için kullanılması amaçlanmamıştır. doğrudan uygulamalar tarafından sağlanır ve yeni işlemlerin sunulması için yalnızca çok dar bir arayüz sunar. Desteklemek istemcilerde, çoğu validator, Horizon adı verilen bir arka plan programı çalıştırır (∼18k gönderme için bir HTTP arayüzü sağlayan Go satırları) ve işlemlerin öğrenilmesi. Horizon'un salt okunur erişimi var Stellar-core'un SQL veritabanı, ufuk riskini en aza indiriyor yıldız çekirdeğinin istikrarını bozuyor. Ödeme yolu bulma gibi özellikler tamamen ufukta uygulanır ve yükseltilebilir diğer validator'larla koordinasyon olmadan tek taraflı olarak. Birkaç isteğe bağlı üst düzey arka plan programı, ekosistemi tamamlayan, ufuktaki istemcilerdir. Bir köprü sunucusu kolaylaştırır Stellar'nin mevcut sistemlerle entegrasyonu; örneğin, belirli bir hesap tarafından alınan tüm ödemelerin bildirimlerinin yayınlanması. bir uyumluluk sunucusu finansal kurumların Gönderen ve yararlanıcı bilgilerinin değişimi ve onaylanması ödemeler konusunda, yaptırım listelerine uyum için. Son olarak, bir federasyon sunucusu insan tarafından okunabilen bir adlandırma uygular hesaplar için sistem. 6 Dağıtım deneyimi Stellar birkaç yıl boyunca ılımlı bir eyalet haline geldi makul derecede güvenilir tam düğüm operatörlerinin sayısı. Ancak, düğümlerin konfigürasyonları canlılık sağlayacak şekildeydi (ancak güvenliği) bize, yani Stellar Kalkınma Vakfı'na bağlıydı (SDF); SDF aniden ortadan kaybolsaydı, diğer düğüm operatörleri müdahale etmesi ve bizi manuel olarak kaldırması gerekirdi ağın devam etmesi için çekirdek dilimlerinden. Biz ve pek çok kişi SDG'nin sistemik önemini azaltmak istesek de, bu hedef daha sonra artan bir öncelik kazandı. araştırmacılar [58] güvenlik risklerini ayırt etmeden ağın merkezileşmesini ölçtü ve duyurdu. canlılık. Bazı operatörler aktif konfigürasyon ayarlamaları yaparak tepki gösterdiler ve öncelikle kendi SDF'nin önemini azaltmak amacıyla çoğunluk dilimleri; ironik bir şekilde bu yalnızca canlılık riskini artırdı. İki sorun durumu daha da kötüleştirdi. İlk olarak popüler bir üçüncü taraf Stellar izleme aracı [5] sistematik olarak doğrulama yapmayarak validator çalışma süresini olduğundan fazla tahmin ediyorsunuz o yıldız çekirdeği çalışıyordu; bu insanları dahil etmeye yönlendirir çekirdek dilimlerindeki güvenilmez düğümler. İkincisi, bir hata yıldız çekirdeği, validator bir sonraki deftere taşındığında anlamına gelir, kalan düğümlerin önceki işlemi tamamlamasına yeterince yardımcı olmadıMesajların kaybolması durumunda büyük defter. Sonuç olarak, ağda 67 dakikalık kesinti yaşandı ve gerekli yeniden başlatmak için validator yöneticiler tarafından manuel koordinasyon. Daha da kötüsü, ağı yeniden başlatmaya çalışırken, birden çok düğümde eş zamanlı ve aceleyle yapılan yeniden yapılandırmalar ortaya çıktı bazı düğümlerin çalışmasına izin veren toplu bir yanlış yapılandırmada bu düğümlerin manuel olarak kapatılmasını gerektiren ve Farklılaşma sırasında kabul edilen işlemlerin yeniden sunulması. Neyse ki bu farklılık fark edildi ve düzeltildi hızlı bir şekilde ve birbiriyle çelişen işlemler içermedi, ancak ağın çekirdek kesişiminden yararlanamama riski— potansiyel olarak çelişkili olanı kabul etmeye devam ederken bölünme yanlış yapılandırma nedeniyle yapılan işlemler bu olay çok somut. Bu deneyimleri gözden geçirmek iki önemli sonuca yol açtı ve ilgili düzeltici eylemler.Stellar ile hızlı ve güvenli küresel ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Kritik, %100 %51 %51 Yüksek, %67 %51 Orta, %67 %51 Düşük, %67 %51 %51 ... ... ... %51 ... %51 Şekil 6. Doğrulayıcı kalite hiyerarşisi. En yüksek kalitede düğümler %100'lük en yüksek eşiği gerektirirken, daha düşük kaliteler %67 eşiğine göre yapılandırılmıştır. Tek bir düğüm içindeki düğümler organizasyon için %51'lik basit bir çoğunluk gerekiyor. 6.1 Yapılandırma karmaşıklığı ve kırılganlığı Stellar çekirdek dilimlerini, n giriş ve k eşiğinden oluşan iç içe çekirdek kümeleri olarak ifade eder; burada herhangi bir k giriş kümesi vardır yetersayı dilimi oluşturur. O zaman n girişin her biri ya bir validator genel anahtarı veya yinelemeli olarak başka bir çekirdek kümesi. Esnek ve kompakt olmasına rağmen iç içe geçmiş bir çoğunluk elde ettik kümeler aynı anda düğüm operatörlerine çok fazla esneklik ve çok az rehberlik sağlıyordu: güvenli olmayan (veya hatta saçma) konfigürasyonlar. Gruplandırma kriterleri alt kümeleri bir hiyerarşi halinde düzenlemek için düğümleri kümeler halinde ve Eşiklerin seçimine ilişkin hususların tümü yeterince açık değildi ve operasyonel başarısızlıklara katkıda bulundu. yapılıp yapılmayacağı belli değildi İç içe geçmiş hiyerarşideki bir "düzeyi" güven düzeyi olarak ele alın, veya bir kuruluş veya her ikisi; sahada birçok konfigürasyon Tehlikeli olanı belirtmenin yanı sıra bu kavramları karıştırdı veya anlamsız eşikler. Bu nedenle daha basit bir yapılandırma mekanizması ekledik iç içe çekirdek kümelerinin iki yönünü ayıran şey: gruplama düğümlerin kuruluşa göre bir araya getirilmesi ve her kuruluşun basit bir güven sınıflandırmasıyla (düşük, orta, yüksek veya kritik). Üst düzey ve üzeri kuruluşların şunları yapması gerekir: tarih arşivlerini yayınlayın. Yeni sistem, her organizasyonun bir grup olarak temsil edildiği iç içe çekirdek kümelerini sentezler. %51 eşik belirlendi ve kuruluşlar gruplar halinde gruplandırıldı %67 veya %100 eşik değerleri ile (grup kalitesine bağlı olarak). Her grup bir sonraki (daha yüksek kalitede) grupta tek bir giriştir, Şekil 6'da gösterildiği gibi. Bu basitleştirilmiş model, hem yapı açısından yanlış yapılandırma olasılığı Sentezlenen iç içe geçmiş kümelerin ve seçilen eşiklerin her set. 6.2 Yanlış yapılandırmanın proaktif tespiti İkincisi, toplu yanlış yapılandırmanın olumsuz etkilerini gözlemlemeyi bekleyerek tespit etmenin çok geç olduğunu fark ettik. Özellikle farklılık gösterebilecek yanlış yapılandırmalarla ilgili olarak durmaktan daha ciddi bir arıza modu; ağın ihtiyacı var Yanlış yapılandırmayı anında tespit edebilmek, böylece operatörlerin herhangi bir sapma meydana gelmeden önce bunu geri döndürebilmesini sağlamak. Bu ihtiyacı karşılamak için validator yazılımına, düğümün geçişli kapanışındaki tüm eşlerin kolektif konfigürasyon durumunu sürekli olarak toplayan ve sapma potansiyelini (yani ayrıklığı) tespit eden bir mekanizma oluşturduk. yetersayılar - bu kolektif konfigürasyon dahilinde. 6.2.1 Çekirdek kesişimi kontrol ediliyor Çekirdek dilimlerini toplamak kolay olsa da, aralarında ayrık çekirdekleri bulmak eş-NP-zordur [62]. Ancak biz benimsedik bir dizi algoritmik buluşsal yöntem ve vaka eleme kuralları Tipik örnekleri kontrol eden Lachowski [62] tarafından önerildi Sorunun birkaç kat daha hızlı çözülmesi en kötü durum maliyeti. Pratik olarak konuşursak, mevcut ağ çekirdek dilimi geçişli kapanışları 20-30 düzeyindedir düğümleri ve Lachowski'nin optimizasyonlarıyla genellikle kontrol edin tek bir CPU'da birkaç saniye içinde. İhtiyaç ortaya çıkarsa Performansı artırmak için aramayı paralel hale getirebiliriz. 6.2.2 Riskli konfigürasyonların kontrol edilmesi Ağın ayrık yeter çoğunlukları kabul ettiğini tespit etmek bir adımdır doğru yönde, ancak tehlikeyi rahatsız edici derecede geç işaretliyor Böyle kritik bir konu için. İdeal olarak, ağın toplu yapılandırması sırasında düğüm operatörlerinin uyarı almasını isteriz. sadece riskli bir duruma yaklaşıyor. Bu nedenle çekirdek-kesişme denetleyicisini genişlettik kritiklik dediğimiz bir durumu tespit etmek için: mevcut durum kolektif yapılandırma, bir yanlış yapılandırmadan uzaktadır ayrık yeter çoğunlukları kabul eden bir eyalet. Kritikliği tespit etmek için, denetleyici sürekli olarak her kuruluşun yapılandırmasını simüle edilmiş en kötü durum yanlış yapılandırmasıyla değiştirir ve ardından sonuç üzerinde iç çekirdek kesişim denetleyicisini yeniden çalıştırır. Böyle kritik bir yanlış yapılandırmanın bir adım ötede olması durumunda mevcut durumdan itibaren yazılım bir uyarı verir ve Kuruluşun yanlış yapılandırma riski oluşturduğunu bildirir. Bu değişiklikler operatör topluluğuna iki katman kazandırıyor en kötü biçimlere karşı izolasyon sağlamak için bildirim ve rehberlik kolektif yanlış yapılandırma.

การประเมิน

เพื่อทำความเข้าใจความเหมาะสมของ Stellar ในฐานะการชำระเงินทั่วโลกและ เครือข่ายการซื้อขาย เราประเมินสถานะของเครือข่ายสาธารณะ และทำการทดลองแบบควบคุมในการทดลองส่วนตัว เครือข่าย เรามุ่งเน้นไปที่คำถามต่อไปนี้: • โทโพโลยีเครือข่ายการผลิตมีลักษณะอย่างไร? โดยเฉลี่ยจะออกอากาศกี่ข้อความ และ SCP ประสบกับการหมดเวลาอย่างไร • เวลาแฝงในการอัปเดตฉันทามติและบัญชีแยกประเภทยังคงไม่ขึ้นอยู่กับจำนวนบัญชีหรือไม่SOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา โลกาวา และคณะ • เวลาแฝงจะได้รับผลกระทบอย่างไรจากการเพิ่ม (ก) ธุรกรรมต่อวินาที (และผลที่ตามมาคือ ธุรกรรมต่อ บัญชีแยกประเภท) และ (b) จำนวน validator โหนด? • ค่าใช้จ่ายในการรันโหนดในแง่ของ CPU คือเท่าไร หน่วยความจำและแบนด์วิธเครือข่าย? เครือข่ายการชำระเงินมีอัตราการทำธุรกรรมต่ำเมื่อเปรียบเทียบ ไปยังระบบกระจายประเภทอื่นๆ blockchains ชั้นนำ Bitcoin และ Ethereum ยืนยันธุรกรรมสูงสุด 15 รายการ/วินาที น้อยกว่า Stellar นอกจากนี้ระบบเหล่านี้ยังใช้เวลาเพียงไม่กี่นาที หนึ่งชั่วโมงเพื่อยืนยันธุรกรรมอย่างปลอดภัย เนื่องจากการพิสูจน์การทำงานต้องรอหลายบล็อคจึงจะขุดได้ ที่ ไม่ใช่-blockchain เครือข่าย SWIFT เฉลี่ยเพียง 420 ธุรกรรมต่อวินาทีในวันที่มีการใช้งานสูงสุด [14] เราจึงเลือก เพื่อเปรียบเทียบการวัดของเรากับเป้าหมาย 5 วินาที ช่วงบัญชีแยกประเภทซึ่งเป็นเป้าหมายเชิงรุกมากขึ้น ผลลัพธ์ของเราแสดงให้เห็น เวลาแฝงนั้นต่ำกว่าขีดจำกัดนี้อย่างสบายใจด้วย การเพิ่มประสิทธิภาพที่ยังไม่ได้ใช้งานหลายอย่างยังคงอยู่ในขั้นตอนการทำงาน 7.1 จุดยึด สินทรัพย์ที่มีการซื้อขายสูงสุดตามปริมาณ ได้แก่ สกุลเงิน (เช่น 3 USD จุดยึด 2 หยวน) จุดยึด Bitcoin การรักษาความปลอดภัยที่ได้รับการสนับสนุนจากอสังหาริมทรัพย์ token [92] และสกุลเงินในแอป [8] แองเคอร์ที่ต่างกันมีนโยบายที่แตกต่างกัน ตัวอย่างเช่น สมอหนึ่งดอลลาร์สหรัฐ Stronghold ตั้งค่า auth_reqired และต้องการกระบวนการ Know-yourcustomer (KYC) สำหรับทุกบัญชีที่ถือครอง สินทรัพย์ อีกอันคือ AnchorUSD ใครๆ ก็รับและซื้อขายกัน USD ของพวกเขา (ทำให้สามารถส่ง $0.50 ไปยังเม็กซิโกได้อย่างแท้จริง ใน 5 วินาทีโดยมีค่าธรรมเนียม $0.000001) อย่างไรก็ตาม AnchorUSD ต้องใช้ KYC และค่าธรรมเนียมในการซื้อหรือแลก USD ด้วยการโอนเงินแบบธรรมดา ในประเทศฟิลิปปินส์ที่ไหน กฎระเบียบของธนาคารเข้มงวดกว่าสำหรับการชำระเงินที่เข้ามา, Coins.ph รองรับการถอนเงิน PHP ที่ตู้ ATM ใดก็ได้ [36] นอกเหนือจากการรักษาความปลอดภัย token ที่กล่าวมาข้างต้นและสกุลเงินในแอปแล้ว ยังมี token ที่ไม่ใช่สกุลเงินที่หลากหลายตั้งแต่ พันธบัตรเชิงพาณิชย์ [22] และคาร์บอนเครดิต [85, 96] ขึ้นไปอีก เนื้อหาลึกลับ เช่น token ที่จูงใจในการทำงานร่วมกัน การยึดรถ [35]. 7.2 เครือข่ายสาธารณะ ในขณะที่เขียนบทความนี้ มีโหนดเต็มรูปแบบที่ใช้งานอยู่ 126 โหนด โดยในจำนวนนี้มี 66 โหนด มีส่วนร่วมในการลงมติโดยการลงนามในข้อความลงคะแนนเสียง รูปที่ 7 (สร้างโดย [5]) แสดงภาพเครือข่ายโดยมีเส้นแบ่งระหว่าง สองโหนดหากมีอันหนึ่งปรากฏในส่วนโควรัมของอีกอันหนึ่งและ เส้นสีน้ำเงินเข้มเพื่อแสดงการพึ่งพาแบบสองทิศทาง ที่ center คือกลุ่มของ 17 de facto “tier-one validators” ที่ดำเนินการโดยพฤตินัย SDF, SatoshiPay, LOBSTR, COINQVEST และ Keybase เมื่อสี่เดือนก่อนก่อนเกิดเหตุการณ์มาตรา 6 ที่นั่น มี 15 โหนดที่สำคัญอย่างเป็นระบบ: 3 โหนดจากที่ดูเหมือน องค์กรระดับหนึ่งและซิงเกิลตันแบบสุ่มหลายรายการ ที่ กราฟยังดูไม่ปกติมากนัก ดังนั้นกลไกการกำหนดค่าใหม่และ/หรือการตัดสินใจของผู้ปฏิบัติงานที่ดีขึ้นจึงดูเหมือน เพื่อสนับสนุนโทโพโลยีเครือข่ายที่ดียิ่งขึ้น โดยไม่ต้อง ทรัพยากรทางการเงินที่ยอดเยี่ยม (และผู้ถือหุ้นที่เกี่ยวข้อง รูปที่ 7 แผนที่ชิ้นโควรัม ภาระผูกพัน) คงเป็นเรื่องยากที่จะรับสมัคร 5 ระดับหนึ่ง องค์กรตั้งแต่เริ่มต้นอย่างไรก็ตาม นี่แสดงว่าองค์ประชุม สไลซ์มีบทบาทสำคัญในการบูตเครือข่าย: ใครๆ ก็สามารถทำได้ เข้าร่วมโดยมีเป้าหมายในการเป็นผู้เล่นคนสำคัญเพราะว่า ไม่มีผู้เฝ้าประตูที่จะตกลงกันเป็นคู่ ขณะนี้มีบัญชีมากกว่า 3.3 ล้านบัญชีในบัญชีแยกประเภท จบแล้ว ในช่วง 24 ชั่วโมงล่าสุด Stellar เฉลี่ย 4.5 ธุรกรรม และ การดำเนินงาน 15.7 ต่อวินาที การตรวจสอบบัญชีแยกประเภทล่าสุดส่วนใหญ่ ธุรกรรมดูเหมือนจะมีการดำเนินการเพียงครั้งเดียว ในขณะที่ทุก ๆ สองสามรายการ บัญชีแยกประเภทที่เราเห็นธุรกรรมที่มีการดำเนินการหลายอย่างนั้น ดูเหมือนจะมาจากผู้ดูแลสภาพคล่องที่จัดการข้อเสนอ ที่ เวลาเฉลี่ยเพื่อให้บรรลุฉันทามติและปรับปรุงบัญชีแยกประเภทได้ 1,061 มิลลิวินาที และ 46 มิลลิวินาที ตามลำดับ เปอร์เซ็นไทล์ที่ 99 คือ 2252 ms และ 142 ms (อันแรกสะท้อนการหมดเวลา 1 วินาที ในการคัดเลือกผู้นำการเสนอชื่อ) หมายเหตุประสิทธิภาพของ SCP คือ ส่วนใหญ่ไม่ขึ้นอยู่กับธุรกรรมต่อวินาที ตั้งแต่ SCP เห็นด้วยกับ hash ของธุรกรรมจำนวนมากโดยพลการ คอขวดมีแนวโน้มที่จะเกิดจากการเผยแพร่ผู้สมัคร ธุรกรรมระหว่างการเสนอชื่อ การดำเนินการ และการตรวจสอบความถูกต้อง ธุรกรรมและการรวมถัง เรายังไม่ต้องการ เพื่อทำการประมวลผลธุรกรรมของ stellar-core แบบขนานบนแกน CPU หรือดิสก์ไดรฟ์หลายตัว เรายังประเมินจำนวนข้อความ SCP ที่ออกอากาศด้วย บนเครือข่ายการผลิต ในกรณีปกติที่มีตัวเดียว ผู้นำเลือกที่จะเสนอชื่อค่าเราคาดหวังเจ็ดตรรกะ ข้อความที่จะออกอากาศ: สองข้อความที่จะโหวตและยอมรับ โนมิคำสั่งเนท สองข้อความที่ต้องยอมรับและยืนยัน เตรียมคำสั่งสองข้อความเพื่อยอมรับและยืนยัน คำสั่งยืนยันและสุดท้ายคือข้อความภายนอก (ส่งหลังจากทำบัญชีแยกประเภทใหม่ไปยังดิสก์เพื่อช่วยเหลือผู้หลงทาง ตามทัน) การใช้งานจะรวมการยืนยันการคอมมิต และส่งออกข้อความเป็นการเพิ่มประสิทธิภาพ เนื่องจากเป็นเช่นนั้น ปลอดภัยในการแปลงค่าภายนอกหลังจากที่มีการดำเนินการแล้ว จากนั้นเราจะวิเคราะห์ตัวชี้วัดที่รวบรวมจากการผลิต Stellar validator จบแล้ว ตลอดระยะเวลา 68 ชั่วโมง มีการส่งข้อความ 1.3 ข้อความ/วินาที โดยเฉลี่ย 6-7 ข้อความต่อบัญชีแยกประเภท เราสังเกตว่ายอดรวม

การชำระเงินทั่วโลกที่รวดเร็วและปลอดภัยด้วย Stellar SOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา เปอร์เซ็นต์ไทล์ จำนวนการหมดเวลา การสรรหา การลงคะแนนเสียง 75% 0 0 99% 1 0 สูงสุด 4 1 รูปที่ 8 การหมดเวลาต่อบัญชีแยกประเภทเกิน 68 ชั่วโมง จำนวนข้อความที่ออกอากาศโดย validators นั้นมากกว่า เนื่องจากใน นอกเหนือจากข้อความการลงคะแนนแบบรวมศูนย์แล้ว โหนดยังออกอากาศอีกด้วย ธุรกรรมใดๆ ที่พวกเขาเรียนรู้ รูปที่ 8 แสดงการหมดเวลาที่เกิดขึ้นจากการผลิต validator ในช่วง 68 ชั่วโมง หมดเวลาการเสนอชื่อคือ การวัดประสิทธิภาพ (ใน) ของฟังก์ชันการเลือกตั้งผู้นำ ในขณะที่การหมดเวลาของบัตรลงคะแนนจะขึ้นอยู่กับเครือข่ายเป็นอย่างมาก และข้อความอาจล่าช้า การหมดเวลามีความสอดคล้องกัน ด้วยจำนวนข้อความที่ส่ง: หกข้อความใน สถานการณ์กรณีที่ดีที่สุด และข้อความอย่างน้อยเจ็ดข้อความหากจำเป็นต้องมีการเสนอชื่อเพิ่มเติม 7.3 การทดลองที่มีการควบคุม เราทำการทดลองแบบควบคุมในภาชนะที่บรรจุไว้ อินสแตนซ์ Amazon EC2 c5d.9xlarge พร้อม RAM ขนาด 72 GiB NVMe SSD ขนาด 900 GB และ vCPU 36 ตัว แต่ละกรณีอยู่ใน ภูมิภาค EC2 เดียวกันและมีแบนด์วิดท์คงที่ 10 Gbps เราใช้ SQLite เป็นร้านค้า (Stellar ยังรองรับ PostgreSQL ด้วย แต่มีงานแบบอะซิงโครนัสที่ส่งเสียงรบกวนเข้าสู่การวัด) Stellar ให้แบบสอบถามรันไทม์ในตัว, Generateload, ที่ช่วยให้สามารถสร้างโหลดสังเคราะห์ที่เป้าหมายเฉพาะได้ ธุรกรรม/อัตราที่สอง แม้ว่า Stellar รองรับหลากหลาย คุณสมบัติการซื้อขาย เช่น หนังสือสั่งซื้อและเส้นทางข้ามสินทรัพย์ การชำระเงิน เราเน้นการชำระเงินแบบง่ายๆ การยืนยันธุรกรรมประกอบด้วยหลายขั้นตอนดังนั้นเราจึง บันทึกการวัดสำหรับแต่ละสิ่งต่อไปนี้: • การสรรหา: ระยะเวลาตั้งแต่การเสนอชื่อจนถึงการเตรียมการครั้งแรก • การลงคะแนนเสียง: ระยะเวลาตั้งแต่การเตรียมการครั้งแรกจนถึงการยืนยัน ก ลงคะแนนเสียงแล้ว • การอัปเดตบัญชีแยกประเภท: ถึงเวลาใช้มูลค่าที่เป็นเอกฉันท์ • จำนวนธุรกรรม: ธุรกรรมที่ยืนยันต่อบัญชีแยกประเภท การทดลองแต่ละครั้งของเราถูกกำหนดโดยพารามิเตอร์สามตัว: จำนวนรายการบัญชีในบัญชีแยกประเภท, จำนวนเงิน โหลด (ในรูปแบบของการชำระเงิน XLM) ที่ส่งต่อวินาที และจำนวน validators เรากำหนดค่าทุก ๆ validator เพื่อทราบเกี่ยวกับ validator อื่นๆ ทั้งหมด (สถานการณ์ที่เลวร้ายที่สุด สำหรับ SCP) โดยกำหนดให้โควรัมเป็นส่วนใหญ่อย่างง่าย โหนด (เพื่อเพิ่มจำนวนองค์ประชุมที่แตกต่างกันให้สูงสุด) พื้นฐาน การทดสอบพื้นฐานของเราวัดได้ Stellar ด้วย 100,000 บัญชี สี่ validators และการสร้างโหลด อัตราการทำธุรกรรม 100 รายการ/วินาที เราสังเกตธุรกรรม 507 รายการต่อบัญชีแยกประเภทโดยเฉลี่ย โดยมีค่าเบี่ยงเบนมาตรฐานอยู่ที่ 49 (9.7%) โปรดทราบว่าไม่มีธุรกรรมใดตกหล่น เล็กน้อย 105 106 107 0 500 1,000 1,500 2,000 บัญชี เวลาแฝง [ms] การปรับปรุงบัญชีแยกประเภท การลงคะแนนเสียง การสรรหา รูปที่ 9. เวลาแฝงเมื่อจำนวนบัญชีเพิ่มขึ้น ความแปรปรวนเกิดจากข้อจำกัดด้านตารางเวลาของตัวสร้างโหลด เราสังเกตว่าจำนวนธุรกรรมต่อบัญชีแยกประเภท สอดคล้องกับอัตราการสร้างโหลดของเรา ตามบัญชีแยกประเภท ปิดทุกๆ 5 วินาที การสรรหา การลงคะแนนเสียง และบัญชีแยกประเภท การอัปเดตแสดงเวลาแฝงเฉลี่ย 82.53 ms, 95.96 ms และ 174.08 มิลลิวินาที ตามลำดับ เราสังเกตเห็นความล่าช้าในการเสนอชื่อ เปอร์เซ็นไทล์ที่ 99 ต่ำกว่า 61 มิลลิวินาทีอย่างสม่ำเสมอ โดยอาจมีเป็นครั้งคราว เพิ่มขึ้นประมาณ 1 วินาที ซึ่งสอดคล้องกับก้าวแรก ในฟังก์ชันหมดเวลาของการเลือกผู้นำ เมื่อพิจารณาถึงประสิทธิภาพพื้นฐานแล้ว เราจึงพิจารณาถึงผลกระทบ ของการเปลี่ยนแปลงพารามิเตอร์การตั้งค่าการทดสอบแต่ละรายการ บัญชี ข้อมูลในรูปที่ 9 แสดงให้เห็นว่า Stellar ปรับขนาด รวมถึงจำนวนบัญชีที่เพิ่มขึ้น การสร้างแบบทดสอบ บัญชีกลายเป็นกระบวนการที่ใช้เวลานาน เช่น การสร้างที่เก็บข้อมูลและ การรวมเข้าด้วยกันทำให้เราไม่สามารถเติมฐานข้อมูลได้อย่างง่ายดาย ด้วยบัญชีโดยตรงผ่าน SQL ดังนั้นเราจึงดำเนินการของเรา ทดลองได้ถึง 50,000,000 บัญชี ในขณะที่มี ผลกระทบน้อยที่สุดต่อเวลาแฝงในการอัปเดตฉันทามติและบัญชีแยกประเภท เราทราบว่าการเพิ่มบัญชีทำให้เกิดค่าใช้จ่าย การรวมถังซึ่งมีขนาดใหญ่ขึ้น อัตราการทำธุรกรรม อัตราการทำธุรกรรมส่งผลกระทบต่อจำนวนเงิน ทราฟฟิกมัลติคาสต์ระหว่าง validators จำนวนธุรกรรมที่รวมอยู่ในแต่ละบัญชีแยกประเภท และขนาดของระดับบนสุด ถัง เพื่อให้เข้าใจถึงผลกระทบของการทำธุรกรรมที่เพิ่มขึ้น โหลดเลย เราทำการทดสอบกับ 100,000 บัญชีและ 4 validators รูปที่ 10 แสดงการเติบโตที่ช้าในเวลาแฝงที่เป็นเอกฉันท์ ในขณะที่ใช้เวลาส่วนใหญ่ในการอัปเดตบัญชีแยกประเภท ไม่น่าแปลกใจเลยที่ชุดธุรกรรมมีขนาดเพิ่มขึ้น ใช้เวลานานกว่าในการส่งไปยังฐานข้อมูล เรายังทราบด้วยว่า เวลาแฝงในการอัปเดตบัญชีแยกประเภทขึ้นอยู่กับการใช้งานอย่างมาก และได้รับผลกระทบจากการเลือกฐานข้อมูล โหนดตัวตรวจสอบ หากต้องการดูว่าจำนวน tierone validators เพิ่มขึ้นเพียงใดส่งผลต่อประสิทธิภาพ เราได้ทำการทดลอง ด้วยบัญชี 100,000 บัญชี 100 ธุรกรรม/วินาที และจำนวน validators ที่แตกต่างกันตั้งแต่ 4 ถึง 43 validators ทั้งหมดปรากฏขึ้น ในส่วนโควรัมของ validators ทั้งหมด ชิ้นโควรัมที่มีขนาดเล็กลง มีผลกระทบต่อประสิทธิภาพน้อยกว่าSOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา โลกาวา และคณะ 100 150 200 250 300 350 0 500 1,000 1,500 2,000 โหลด [ธุรกรรม/วินาที] เวลาแฝง [ms] การปรับปรุงบัญชีแยกประเภท การลงคะแนนเสียง การสรรหา รูปที่ 10 เวลาแฝงเมื่อโหลดธุรกรรมเพิ่มขึ้น 10 20 30 40 0 500 1,000 1,500 2,000 ผู้ตรวจสอบความถูกต้อง เวลาแฝง [ms] การปรับปรุงบัญชีแยกประเภท การลงคะแนนเสียง การสรรหา รูปที่ 11. เวลาแฝงเมื่อจำนวนโหนดเพิ่มขึ้น การเปลี่ยนจำนวนโหนดตรวจสอบความถูกต้องบนเครือข่าย ส่งผลกระทบต่อจำนวนข้อความ SCP ที่มีการแลกเปลี่ยนเช่นกัน จำนวนค่าที่เป็นไปได้ในระหว่างการเสนอชื่อ รูปที่ 11 แสดงเวลาการเสนอชื่อที่เพิ่มขึ้นในอัตราที่ค่อนข้างน้อย แม้ว่าข้อมูลจะชี้ให้เห็นว่าการลงคะแนนเสียงถือเป็นปัญหาคอขวด แต่เรา เชื่อว่าปัญหาการปรับขนาดหลายอย่างสามารถแก้ไขได้ด้วยการปรับปรุง เครือข่ายซ้อนทับของ Stellar เพื่อเพิ่มประสิทธิภาพการรับส่งข้อมูลเครือข่าย เช่น ที่คาดไว้ เวลาแฝงในการอัปเดตบัญชีแยกประเภทยังคงไม่ขึ้นอยู่กับ จำนวนโหนด อัตราปิด สุดท้ายนี้ เราต้องการวัดประสิทธิภาพตั้งแต่ต้นจนจบของ Stellar โดยการวัดความถี่ในการยืนยันบัญชีแยกประเภท และ Stellar บรรลุเป้าหมาย 5 วินาทีโดยไม่ วางธุรกรรมใด ๆ เราสังเกตเห็นการปิดบัญชีแยกประเภทโดยเฉลี่ย เท่าของ 5.03 วิ, 5.10 วิ และ 5.15 วิ เมื่อเราเพิ่มบัญชี รายการ อัตราการทำธุรกรรม และจำนวนโหนด ตามลำดับ ผลลัพธ์แนะนำว่า Stellar สามารถปิดบัญชีแยกประเภทได้อย่างสม่ำเสมอ ภายใต้ภาระสูง 7.4 กำลังเรียกใช้ validator คุณสมบัติที่สำคัญอย่างหนึ่งของ Stellar คือต้นทุนที่ต่ำ ใช้งาน validator ตามที่จุดยึดควรทำงาน (หรือทำสัญญาด้วย) validators เพื่อบังคับใช้ขั้นสุดท้าย SDF รันการผลิต 3 รายการ validators ทั้งหมดบนอินสแตนซ์ AWS c5.large ซึ่งมี 2 คอร์ RAM 4 GiB และ CPU Intel(R) Xeon(R) Platinum 8124M @ โปรเซสเซอร์ 3.00GHz การตรวจสอบการใช้ทรัพยากรในที่เดียว ของเครื่องเหล่านี้ เราสังเกตเห็นการใช้กระบวนการ Stellar CPU ประมาณ 7% และหน่วยความจำ 300 MiB ในแง่ของการรับส่งข้อมูลเครือข่าย โดยมีการเชื่อมต่อกับเพียร์ 28 รายการและขนาดองค์ประชุม จาก 34 อัตราขาเข้าและขาออกอยู่ที่ 2.78 Mbit/s และ 2.56 Mbit/s ตามลำดับ ฮาร์ดแวร์ที่จำเป็นในการทำงานดังกล่าว กระบวนการมีราคาไม่แพง ในกรณีของเรา ค่าใช้จ่ายคือ 0.054 USD/ชั่วโมง หรือประมาณ $40/เดือน 7.5 งานในอนาคต การทดลองเหล่านี้แนะนำว่า Stellar สามารถปรับขนาดคำสั่งซื้อ 1–2 รายการได้อย่างง่ายดาย ยิ่งใหญ่เกินกว่าการใช้งานเครือข่ายในปัจจุบัน เพราะว่า ความต้องการด้านประสิทธิภาพนั้นค่อนข้างเรียบง่ายจนถึงปัจจุบัน Stellar เหลือพื้นที่ไว้สำหรับการเพิ่มประสิทธิภาพแบบตรงไปตรงมาหลายอย่างโดยใช้ เทคนิคที่รู้จักกันดี ตัวอย่างเช่น ธุรกรรมและ SCP ข้อความถูกถ่ายทอดโดย validators โดยใช้การฟลัดแบบไร้เดียงสา โปรโตคอล แต่ควรใช้อย่างมีประสิทธิภาพและมีโครงสร้างมากกว่า มัลติคาสต์แบบเพียร์ทูเพียร์ [30] นอกจากนี้ฐานข้อมูลยังหนัก เวลาในการอัปเดตบัญชีแยกประเภทสามารถปรับปรุงได้โดยใช้เทคนิคการแบทช์มาตรฐานและการดึงข้อมูลล่วงหน้า

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

Değerlendirme

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

Stellar'nin küresel ödeme olarak uygunluğunu anlamak ve ticaret ağı, genel ağın durumunu değerlendirdik ve özel bir deneyde kontrollü deneyler yürüttük ağ. Aşağıdaki sorulara odaklandık: • Üretim ağı topolojisi neye benziyor? Ortalama kaç mesaj yayınlanıyor ve SCP zaman aşımlarını nasıl yaşıyor? • Konsensüs ve defter güncelleme gecikmeleri hesap sayısından bağımsız mı kalıyor?SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. • (a) Saniye başına işlemlerin (ve dolayısıyla saniye başına işlemlerin) artmasından gecikmeler nasıl etkilenir? defter) ve (b) validator düğümlerin sayısı? • Bir düğümü çalıştırmanın CPU açısından maliyeti nedir, bellek ve ağ bant genişliği? Ödeme ağları karşılaştırıldığında düşük işlem oranlarına sahiptir diğer dağıtılmış sistem türlerine. Önde gelen blockchain'ler, Bitcoin ve Ethereum, saniyede 15 işleme kadar onaylayın, Stellar'den az. Üstelik bu sistemlerin çalışması dakikalar sürüyor. Bir işlemin güvenli bir şekilde onaylanması bir saat sürer, çünkü iş kanıtı birkaç bloğun çıkarılmasını beklemeyi gerektirir. blockchain olmayan SWIFT ağı, en yoğun olduğu gün olan [14]'de saniyede yalnızca 420 işlem gerçekleştirdi. Bu nedenle seçtik ölçümlerimizi 5 saniyelik hedefle karşılaştırmak için defter aralığı, daha agresif bir hedef. Sonuçlarımız gösteriyor gecikmelerin rahatlıkla bu sınırın altında olduğu hala geliştirilme aşamasında olan birkaç uygulanmamış optimizasyon. 7.1 Çapalar Hacim bazında en çok işlem gören varlıklar arasında para birimi de yer alıyor (ör. 3 USD) çapa, 2 CNY), bir Bitcoin çapa, gayrimenkul destekli bir menkul kıymet token [92] ve uygulama içi para birimi [8]. Farklı çapaların farklı politikaları vardır. Örneğin, bir USD çapası, Stronghold, auth_reqired'i ayarlar ve müşterilerini tanıyan her hesap için müşterini tanı (KYC) süreci gerektirir. varlıklar. Bir diğeri, AnchorUSD, herkesin alıp ticaret yapmasına izin verin USD'leri (Meksika'ya 0,50 $ göndermeyi tam anlamıyla mümkün kılıyor) 0,000001 ABD Doları ücretle 5 saniye içinde). Ancak AnchorUSD USD'lerini satın almak veya kullanmak için KYC ve ücret gerektirir geleneksel banka havaleleriyle. Filipinler'de, nerede banka düzenlemeleri gelen ödemeler konusunda daha gevşektir, coin.ph PHP'nin herhangi bir ATM makinesinden [36] paraya çevrilmesini destekler. Yukarıda bahsedilen güvenlik token ve uygulama içi para birimine ek olarak, para birimi olmayan tokens aralığı da vardır: ticari tahviller [22] ve karbon kredileri [85, 96] daha fazlasına token gibi ortak çalışmayı teşvik eden ezoterik varlıklar arabanın yeniden ele geçirilmesi [35]. 7.2 Genel ağ Bu yazının yazıldığı an itibariyle 126 aktif tam düğüm mevcut olup bunların 66'sı oylama mesajlarını imzalayarak fikir birliğine katılın. Şekil 7 ([5] tarafından oluşturulmuştur) ağı aralarında bir çizgiyle görselleştirir biri diğerinin çekirdek dilimlerinde görünüyorsa iki düğüm ve iki yönlü bağımlılığı göstermek için daha koyu mavi çizgi. Şunda merkez, tarafından yönetilen 17 fiili "birinci kademe validators"den oluşan bir kümedir. SDF, SatoshiPay, LOBSTR, COINQVEST ve Keybase. Dört ay önce, Bölüm 6'daki olaylardan önce, orada 15 sistemik olarak önemli düğüm vardı: 3'ü görünüşte birinci kademe organizasyonlar ve birkaç rastgele singleton. grafik de çok daha az düzenli görünüyordu. Dolayısıyla yeni konfigürasyon mekanizması ve/veya daha iyi operatör kararları görünmektedir. daha sağlıklı bir ağ topolojisine katkıda bulunmak. olmadan büyük mali kaynaklar (ve ilgili hissedarlar) Şekil 7. Çekirdek dilim haritası yükümlülükler), 5. kademeyi işe almak zor olurdu Ancak başlangıçtan itibaren organizasyonlar. Bu yeter sayıyı öneriyor dilimler ağ önyüklemesinde yararlı bir rol oynar: herkes yapabilir önemli bir oyuncu olma hedefiyle katılın çünkü ikili anlaşmanın bekçileri yoktur. Şu anda defterde 3,3 milyondan fazla hesap var. bitti son 24 saatlik dönemde Stellar ortalama 4,5 işlem gerçekleştirdi ve Saniyede 15,7 işlem. Son defterlerin incelenmesi, çoğu işlemlerin tek bir işlemi varmış gibi görünürken, her birkaç Defterlerde birçok işlemi içeren işlemleri görüyoruz teklifleri yöneten piyasa yapıcılardan geliyor gibi görünüyor. Fikir birliğine varmak ve defteri güncellemek için ortalama süreler Sırasıyla 1061 ms ve 46 ms. 99. yüzdelik dilimler şunlardı: 2252 ms ve 142 ms (ilki 1 saniyelik zaman aşımını yansıtıyor) adaylık lideri seçiminde). SCP'nin performansının şu şekilde olduğunu unutmayın: SCP'den beri çoğunlukla saniyedeki işlemlerden bağımsızdır keyfi olarak birçok işlemden oluşan hash üzerinde anlaşır. Adayın propagandası nedeniyle darboğazların ortaya çıkma olasılığı daha yüksektir Aday gösterme, yürütme ve doğrulama sırasındaki işlemler işlemler ve paketlerin birleştirilmesi. Henüz ihtiyacımız olmadı Stellar-core'un işlem işlemlerini birden fazla CPU çekirdeği veya disk sürücüsü üzerinden paralelleştirmek için. Ayrıca yayınlanan SCP mesajlarının sayısını da değerlendirdik üretim ağında. Normal durumda tek Bir değeri aday göstermek için seçilen liderden yedi mantıksal değer bekliyoruz yayınlanacak mesajlar: oylanacak ve kabul edilecek iki mesaj bir isimnate beyanı, kabul edilecek ve onaylanacak iki mesaj bir hazırlık ifadesi, kabul etmek ve onaylamak için iki mesaj bir taahhüt beyanı ve son olarak bir dışsallaştırma mesajı (başıboş kalanlara yardım etmek için diske yeni bir defter işlendikten sonra gönderilir) yetişin). Uygulama onaylama taahhüdünü birleştirir ve mesajları bir optimizasyon olarak dışsallaştırın, çünkü Bir değeri taahhüt edildikten sonra dışsallaştırmak güvenlidir. Daha sonra Stellar validator numaralı üretimde toplanan metrikleri analiz ederiz. bitti 68 saat boyunca saniyede 1,3 mesaj gönderildi, Defter başına ortalama 6-7 mesaj. Toplamın olduğunu not ediyoruz

Stellar ile hızlı ve güvenli küresel ödemeler SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Yüzdelik dilim Zaman Aşımı Sayısı Adaylık oylama %75 0 0 %99 1 0 Maksimum 4 1 Şekil 8. Defter başına 68 saatten fazla zaman aşımı validators tarafından yayınlanan mesajların sayısı daha fazla, çünkü Birleşik oylama mesajlarına ek olarak düğümler aynı zamanda yayın da yapar öğrendikleri herhangi bir işlem. Şekil 8, bir üretimin yaşadığı zaman aşımlarını göstermektedir validator 68 saatlik bir süre boyunca. Adaylık zaman aşımları oylama zaman aşımları büyük ölçüde ağa bağlıyken, lider seçim fonksiyonunun etkili(olmayan)etkinliğinin bir ölçüsü ve potansiyel mesaj gecikmeleri. Zaman aşımları tutarlı gönderilen mesaj sayısıyla birlikte: altı mesaj en iyi senaryo ve ek bir adaylık turu gerekiyorsa en az yedi mesaj. 7.3 Kontrollü deneyler Ambalajlı kaplarda kontrollü deneyler yaptık. 72 GiB RAM'e sahip Amazon EC2 c5d.9xlarge bulut sunucuları, 900 GB NVMe SSD ve 36 vCPU. Her örnek şu şekildeydi: aynı EC2 bölgesi ve 10 Gbps sabit bant genişliğine sahipti. SQLite'ı mağaza olarak kullandık. (Stellar ayrıca PostgreSQL'i de destekler, ancak ölçümlere gürültü katan eş zamanlı olmayan görevleri vardır.) Stellar yerleşik bir çalışma zamanı sorgusu sağlar, createdload, belirli bir hedefte sentetik yük oluşturulmasına olanak sağlayan işlem/ikinci oran. Stellar çeşitli destekleri olsa da Sipariş defteri ve çapraz varlık yolu gibi ticaret özellikleri ödemelerde basit ödemelere odaklandık. İşlemlerin onaylanması birden fazla adımdan oluşur, bu nedenle aşağıdakilerin her biri için ölçümleri kaydetti: • Aday gösterme: aday gösterilme anından ilk hazırlığa kadar geçen süre • Oylama: ilk hazırlıktan bir oylamanın onaylanmasına kadar geçen süre oy pusulası işlendi • Defter güncellemesi: fikir birliği değerini uygulama zamanı • İşlem sayısı: defter başına onaylanmış işlemler Deneylerimizin her biri üç parametreyle tanımlandı: Defterdeki hesap girişlerinin sayısı, tutarı Saniyede gönderilen yük (XLM ödemeleri şeklinde), ve validators sayısı. Her validator'yı yapılandırdık diğer validator hakkında bilgi sahibi olmak (en kötü senaryo) SCP için), çekirdek dilimleri herhangi bir basit çoğunluğa ayarlanmış olarak düğümler (farklı yetersayıların sayısını en üst düzeye çıkarmak için). Temel Temel denememiz Stellar ile ölçüldü 100.000 hesap, dört validator ve yük oluşturma 100 işlem/saniye hızı. Defter başına ortalama 507 işlem gözlemledik, standart sapma 49 (%9,7). Hiçbir işlemin iptal edilmediğini unutmayın; hafif 105 106 107 0 500 1.000 1.500 2.000 Hesaplar Gecikme [ms] Defter güncellemesi oylama Adaylık Şekil 9. Hesap sayısı arttıkça gecikme varyans, yük oluşturucunun planlama sınırlamalarından kaynaklanmaktadır. Defter başına işlem sayısının arttığını gözlemledik. defter göz önüne alındığında, yük oluşturma oranımızla tutarlıydı Her 5 saniyede bir kapanıyor. Aday gösterme, oylama ve defter güncelleme ortalama 82,53 ms, 95,96 ms gecikme süresi gösterdi ve Sırasıyla 174,08 ms. Aday gösterme gecikmesini gözlemledik 99. yüzdelik dilim sürekli olarak 61 ms'nin altındadır, ara sıra İlk adıma karşılık gelen yaklaşık 1 saniyelik ani artışlar lider seçiminin zaman aşımı fonksiyonunda. Temel performans göz önüne alındığında, etkilere baktık test kurulum parametrelerinin her birini değiştirme. Hesaplar Şekil 9'daki veriler Stellar'nin ölçeklendiğini göstermektedir hesap sayısı da artıyor. Testin oluşturulması hesaplar, paket oluşturma ve birleştirme veritabanını basitçe doldurmamızı engelledi hesaplarla doğrudan SQL üzerinden. Bu nedenle çalışmalarımızı gerçekleştirdik. 50.000.000'e kadar hesap için denemeler. varken Konsensüs ve defter güncelleme gecikmeleri üzerinde minimum etki, Artan hesapların bir ek yük yarattığını not ediyoruz giderek büyüyen kovaları birleştiriyor. İşlem oranı İşlem oranı tutarı etkiler validators arasındaki trafik çoklu yayını, her bir defterde yer alan işlem sayısı ve üst düzeyin boyutu kovalar. Artan işlemlerin etkilerini anlamak yüklendiğinde, 100.000 hesap ve 4 validators ile bir deneme yaptık. Şekil 10, fikir birliği gecikmesindeki yavaş büyümeyi göstermektedir, zamanın büyük bir kısmı defteri güncellemekle geçiyordu. İşlem kümesinin boyutu arttıkça şaşırtıcı olmayan bir şekilde veritabanına kaydedilmesi daha uzun sürer. Ayrıca şunu da not ediyoruz Defter güncelleme gecikmesi büyük ölçüde uygulamaya bağlıdır, ve veritabanı seçiminden etkilenir. Doğrulayıcı düğümler validators katman sayısının nasıl arttığını görmek içinperformansı etkiliyor, deneyler yaptık 100.000 hesap, 100 işlem/saniye ve 4 ile 43 arasında değişen sayıda validator ile. Tüm validator'ler göründü validators'nin tüm çekirdek dilimlerinde; daha küçük çoğunluk dilimleri performans üzerinde daha az etkiye sahiptir.SOSP '19, 27–30 Ekim 2019, Huntsville, ON, Kanada Lokhava ve diğerleri. 100 150 200 250 300 350 0 500 1.000 1.500 2.000 Yükle [işlem/saniye] Gecikme [ms] Defter güncellemesi oylama Adaylık Şekil 10. İşlem yükü arttıkça gecikme 10 20 30 40 0 500 1.000 1.500 2.000 Doğrulayıcılar Gecikme [ms] Defter güncellemesi oylama Adaylık Şekil 11. Düğüm sayısı arttıkça gecikme Ağdaki doğrulayan düğümlerin sayısını değiştirme değiştirilen SCP mesajlarının sayısını ve ayrıca Aday gösterme sırasındaki potansiyel değerlerin sayısı. Şekil 11 adaylık süresinin nispeten küçük bir oranda arttığını gösteriyor. Veriler oylamanın bir darboğaz olduğunu öne sürse de, biz ölçeklendirme sorunlarının çoğunun iyileştirilerek çözülebileceğine inanıyorum Ağ trafiğini optimize etmek için Stellar'nin yer paylaşımlı ağı. olarak beklenen, defter güncelleme gecikmesi bağımsız kaldı düğüm sayısı. Kapanış oranı Son olarak, Stellar'nin uçtan uca performansını, defterlerin ne sıklıkta onaylandığını ve Stellar'nin 5 saniyelik hedefine herhangi bir müdahale olmadan ulaşıp ulaşmadığını ölçerek ölçmek istedik. herhangi bir işlemin bırakılması. Ortalama defter kapanışını gözlemledik hesabı artırdıkça 5,03 sn, 5,10 sn ve 5,15 sn'lik zamanlar sırasıyla girişler, işlem oranı ve düğüm sayısı. Sonuçlar Stellar'nın defterleri tutarlı bir şekilde kapatabildiğini gösteriyor yüksek yük altında. 7.4 validator çalıştırılıyor Stellar'nin önemli özelliklerinden biri de düşük maliyetidir. çapaların çalışması (veya sözleşme yapması) gerektiği için validator çalıştırılıyor Kesinliği uygulamak için validators. SDF, tamamı iki çekirdeğe sahip c5.large AWS örneklerinde olmak üzere 3 adet üretim validator çalıştırıyor. 4 GiB RAM ve Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz işlemciler. Birinde kaynak kullanımı inceleniyor bu makinelerin Stellar işlemini kullanarak gözlemledik CPU'nun yaklaşık %7'si ve 300 MiB bellek. Ağ trafiği açısından, eşlerle 28 bağlantı ve çekirdek boyutuyla 34'ün giriş ve çıkış hızları 2,78 Mbit/s idi ve Sırasıyla 2,56 Mbit/s. Böyle bir işlemi çalıştırmak için gerekli donanım süreç ucuzdur. Bizim durumumuzda maliyet 0,054$/saattir veya ayda yaklaşık 40$. 7.5 Gelecekteki çalışmalar Bu deneyler, Stellar ürününün 1-2 siparişi kolayca ölçeklendirebileceğini gösteriyor günümüzün ağ kullanımının ötesinde büyüklükte. Çünkü performans talepleri bugüne kadar çok mütevazıydı, Stellar kullanarak birçok basit optimizasyona yer bırakır iyi bilinen teknikler. Örneğin, işlemler ve SCP mesajlar saf bir Flood kullanarak validators tarafından yayınlanıyor protokol, ancak ideal olarak daha verimli, yapılandırılmış bir protokol kullanmalıdır eşler arası çoklu yayın [30]. Ayrıca veritabanı ağırlıklı Defter güncelleme süresi, standart toplu işlem ve önceden getirme teknikleri yoluyla iyileştirilebilir.

บทสรุป

การชำระเงินระหว่างประเทศมีราคาแพงและใช้เวลาหลายวัน กองทุน การดูแลผ่านสถาบันการเงินหลายแห่ง รวมถึงธนาคารตัวแทนและบริการโอนเงิน เนื่องจากแต่ละฮอปจะต้องได้รับความไว้วางใจอย่างเต็มที่ จึงเป็นเรื่องยากสำหรับฮอปใหม่ ผู้เข้าร่วมเพื่อเพิ่มส่วนแบ่งการตลาดและแข่งขัน Stellar รายการ วิธีส่งเงินทั่วโลกอย่างถูกในไม่กี่วินาที ที่ นวัตกรรมที่สำคัญคือโปรโตคอลข้อตกลงไบแซนไทน์แบบเปิดสมาชิกใหม่ SCP ซึ่งใช้ประโยชน์จากโครงสร้างแบบเพียร์ทูเพียร์ ของเครือข่ายทางการเงินเพื่อให้บรรลุฉันทามติระดับโลกภายใต้ก สมมติฐานอินเทอร์เน็ตใหม่ SCP อนุญาตให้ Stellar กระทำแบบอะตอมมิก ธุรกรรมที่ไม่สามารถย้อนกลับได้ระหว่างผู้เข้าร่วมโดยพลการซึ่ง ไม่รู้หรือเชื่อใจกัน ซึ่งจะรับประกันว่าผู้เข้ามาใหม่จะสามารถเข้าถึงตลาดเดียวกันกับที่จัดตั้งขึ้น ผู้เล่นทำให้ปลอดภัยที่จะได้รับการแลกเปลี่ยนที่ดีที่สุด อัตราแม้จากผู้ดูแลสภาพคล่องที่ไม่น่าเชื่อถือและอย่างมาก ลดความล่าช้าในการชำระเงิน รับทราบ Stellar คงมาไม่ถึงทุกวันนี้ถ้าไม่ตื่นแต่เช้า ความเป็นผู้นำของจอยซ์ คิม หรือการมีส่วนร่วมอันยิ่งใหญ่ของ Scott Fleckenstein และ Bartek Nowotarski ในการก่อสร้างและ การรักษาขอบฟ้า, Stellar SDK และส่วนสำคัญอื่นๆ ของระบบนิเวศ Stellar นอกจากนี้เรายังขอขอบคุณ Kolten Bergeron เฮนรี คอร์ริแกน-กิบส์, แคนเดซ เคลลี, คาพิล เค. เจน, บอริส เรซนิคอฟ, เจเรมี รูบิน, คริสเตียน รัดเดอร์, เอริก ซอนเดอร์ส, Torsten Stüber, Tomer Weller, ผู้วิจารณ์ที่ไม่เปิดเผยนาม และ Justine Sherry คนเลี้ยงแกะของเราสำหรับความคิดเห็นที่เป็นประโยชน์ของพวกเขา ร่างก่อนหน้านี้ ข้อสงวนสิทธิ์ การสนับสนุนของศาสตราจารย์ Mazières ในสิ่งพิมพ์นี้ถือเป็นที่ปรึกษาที่ได้รับค่าตอบแทน และไม่ได้เป็นส่วนหนึ่งของเขา หน้าที่หรือความรับผิดชอบของมหาวิทยาลัยสแตนฟอร์ด

การชำระเงินทั่วโลกที่รวดเร็วและปลอดภัยด้วย Stellar SOSP '19, 27–30 ตุลาคม 2019, Huntsville, ON, แคนาดา

Çö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