เอกสารไวท์เปเปอร์ บทความ รูปภาพ อภิธานศัพท์ กราฟ ค้นหา

스텔라 합의 프로토콜

โดย David Mazières · 2015

โหมดเดี่ยว stellar.org
🇺🇸 English (ต้นฉบับ)
🇰🇷 한국어 (คำแปล)

บทคัดย่อ

การชำระเงินระหว่างประเทศนั้นช้าและมีราคาแพง ส่วนหนึ่งเป็นเพราะการกำหนดเส้นทางการชำระเงินแบบหลายฮอปผ่านต่างกัน ระบบธนาคาร 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

초록

국제 결제는 느리고 비용이 많이 듭니다. 부분적으로는 이기종을 통한 멀티홉 결제 라우팅 때문입니다. 은행 시스템. Stellar는 새로운 글로벌 결제 네트워크입니다. 어디서나 디지털 화폐를 직접 전송할 수 있는 몇 초 만에 세계. 핵심 혁신은 안전한 거래입니다 새로운 메커니즘을 사용하여 신뢰할 수 없는 중개자를 통한 메커니즘 SCP라고 불리는 비잔틴 합의 프로토콜. SCP를 사용하면 각각 기관은 남아 있을 다른 기관을 지정합니다. 동의하다; 글로벌 상호 연결을 통해 금융 시스템, 전체 네트워크는 원자에 동의합니다. 중개 자산 발행자의 지급 능력이나 환율 위험 없이 임의의 기관에 걸친 거래 또는 시장 조성자. 우리는 SCP의 모델, 프로토콜 및 공식적인 검증; Stellar 결제 네트워크를 설명하세요. 마지막으로 벤치마크를 통해 경험적으로 Stellar을 평가합니다. 수년간의 생산 사용 경험. CCS 개념 • 보안 및 개인정보 보호 →분산 시스템 보안; • 전산시스템 구성 → 피어 투 피어 아키텍처 • 정보시스템 → 전자 자금 이체. 키워드 blockchain, BFT, 정족수, 지불 ACM 참조 형식: 마르타 로카바, 줄리아노 로사, 데이비드 마지에르, 그레이던 호어, 니콜라스 배리, 엘리 가프니, 조나단 조브, 라파우 말리노프스키, 제드 맥칼렙. 2019. Stellar를 통한 빠르고 안전한 글로벌 결제. SOSP에서는 ’19: 운영 체제 원칙에 관한 심포지엄, 10월 27~30일 2019, 헌츠빌, 온타리오, 캐나다. ACM, 뉴욕, 뉴욕, 미국, 17페이지. https://doi.org/10.1145/3341301.3359636

การแนะนำ

การชำระเงินระหว่างประเทศช้ามากและมีค่าใช้จ่ายสูง [32] พิจารณาความไม่สามารถทำได้จริงในการส่งเงิน $0.50 จากสหรัฐอเมริกาไปที่ *กาลอยส์ อิงค์ †ยูซีแอลเอ อนุญาตให้จัดทำสำเนาดิจิทัลหรือสำเนาของงานนี้ทั้งหมดหรือบางส่วนเพื่อ อนุญาตให้ใช้ส่วนตัวหรือในชั้นเรียนโดยไม่มีค่าธรรมเนียม โดยที่ไม่ต้องทำสำเนา จัดทำหรือแจกจ่ายเพื่อหากำไรหรือข้อได้เปรียบทางการค้าและมีสำเนาดังกล่าว ประกาศนี้และการอ้างอิงฉบับเต็มในหน้าแรก ลิขสิทธิ์สำหรับส่วนประกอบ งานนี้ต้องเป็นของบุคคลอื่นที่ไม่ใช่ ACM จะต้องได้รับเกียรติ นามธรรมด้วย เครดิตได้รับอนุญาต หากต้องการคัดลอกหรือเผยแพร่ซ้ำเพื่อโพสต์บนเซิร์ฟเวอร์หรือไปที่ แจกจ่ายไปยังรายการ ต้องได้รับอนุญาตเฉพาะล่วงหน้าและ/หรือมีค่าธรรมเนียม คำขอ สิทธิ์จาก [email protected] SOSP '19, 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 สิ้นสุดลง

소개

국제 결제는 느리고 비용이 많이 드는 것으로 악명 높습니다 [32]. 미국에서 다음 국가로 0.50달러를 보내는 것은 비실용적입니다. *갈로이스 주식회사 †UCLA 본 저작물의 전부 또는 일부를 디지털 또는 하드 카피로 만들 수 있는 권한 개인 또는 교실 사용은 사본이 아닌 한 무료로 허용됩니다. 영리 또는 상업적 이익을 위해 제작 또는 배포되었으며 그 사본에는 다음과 같은 내용이 포함됩니다. 이 통지문과 첫 페이지에 전체 인용문이 나와 있습니다. 구성 요소에 대한 저작권 ACM이 아닌 타인이 소유한 이 저작물은 존중되어야 합니다. 추상화 신용이 허용됩니다. 다른 방식으로 복사하거나 다시 게시하거나 서버에 게시하거나 목록으로 재배포하려면 사전 특정 허가 및/또는 수수료가 필요합니다. 요청 [email protected]의 권한입니다. SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 © 2019 컴퓨팅 기계 협회. ACM ISBN 978-1-4503-6873-5/19/10...$15.00 https://doi.org/10.1145/3341301.3359636 멕시코, 두 이웃 국가. 최종 사용자는 거의 9달러를 지불합니다. 평균 전송 [32] 및 양자간 합의 국가의 중앙은행이 중개하는 것은 단지 감소할 수 있을 뿐이다. 기본 은행 비용은 항목당 $0.67 [2]입니다. 수수료 외에, 일반적으로 국제 결제 지연 시간이 계산됩니다. 며칠 안에 해외로 빨리 돈을 가져갈 수 없게 만듭니다. 긴급 상황. 은행 시스템이 없는 국가에서는 일하거나 모든 시민에게 서비스를 제공하지 않거나 수수료가 감당할 수 없는 곳에서는 사람들이 버스([38])로 지불금을 보내는 데 의지합니다. 보트 [19], 때로는 지금 Bitcoin [55]까지, 모두 위험, 지연 또는 불편이 발생합니다. 규정 준수 비용은 항상 존재하지만 경쟁 부족으로 인해 상당한 금액의 손실이 발생한다는 증거가 있습니다 [21], 이는 비효율적인 기술로 인해 더욱 악화됩니다. 사람들이 있는 곳 혁신할 수 있고 가격과 지연 시간이 줄어듭니다. 예를 들어, 2019년 2분기 은행 계좌에서 송금하는 데 드는 평균 비용은 6.99%, 모바일 머니 수치는 4.88% [13]에 불과했습니다. 혁신을 불러일으키는 개방형 글로벌 결제 네트워크 비은행 기업과의 경쟁이 위축될 수 있습니다. 규정 준수를 포함한 모든 계층의 비용 및 대기 시간 [83]. 이 백서는 blockchain 기반 결제인 Stellar을 제시합니다. 혁신을 촉진하고 국제 결제 경쟁. Stellar이 첫 번째입니다 다음 세 가지 목표를 모두 충족하는 시스템( 참신하지만 경험적으로 유효한 "인터넷 가설"): 1. 오픈멤버십 – 누구나 통화담보 발행 가능 사용자 간에 교환할 수 있는 디지털 token입니다. 2. 발급자 시행 최종성 – token의 발급자는 이를 방지할 수 있습니다. token의 거래가 취소되거나 실행 취소되지 않습니다. 3. 발행자 간 원자성 – 사용자는 원자적으로 교환할 수 있습니다. 여러 발행자로부터 token을 거래하세요. 처음 두 개를 달성하는 것은 쉽습니다. 어떤 회사라도 Paypal, Venmo, WeChat과 같은 제품을 일방적으로 제공할 수 있습니다. 지불 또는 Alipay를 통해 지불의 최종성을 보장합니다. 그들이 만든 가상 화폐. 불행하게도 이러한 통화 간에 원자적으로 거래하는 것은 불가능합니다. 사실, Paypal이 Venmo의 모회사를 인수했음에도 불구하고 2013년에는 여전히 최종 사용자가 Venmo를 보내는 것이 불가능합니다. PayPal 사용자에게 [78] 달러를 지급합니다. 최근에야 상인들이 단일 통합으로 두 가지를 모두 수용할 수도 있습니다. 목표 2와 3은 폐쇄형 시스템에서 달성할 수 있습니다. 특히 국내결제가 효율적인 국가가 많습니다. 일반적으로 보편적으로 신뢰할 수 있는 규제 기관이 감독하는 네트워크입니다. 단, 회원가입은 비공개로 제한됩니다. 공인 은행 집합과 네트워크는 다음으로 제한됩니다. 국가의 규제 당국에 도달합니다.SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 Lokhavaet al. 목표 1과 3은 채굴된 blockchain에서 달성되었습니다. 특히 Ethereum [3]의 ERC20 tokens 형식입니다. 이 blockchains의 핵심 아이디어는 사람들이 정착에 대해 보상할 수 있는 새로운 암호화폐를 만드는 것입니다. 되돌리기 어려운 거래. 불행하게도 이는 token 발행자가 거래 최종성을 제어하지 않는다는 것을 의미합니다. 소프트웨어인 경우 오류로 인해 거래 내역이 재구성됩니다 [26, 73], 또는 사람들을 속여 얻은 전리품이 그 비용을 초과하는 경우 기록 재구성 [74, 97], 발행자는 tokens에 대해 책임을 질 수 있습니다. 그들은 이미 실제 돈으로 교환했습니다. Stellar blockchain에는 두 가지 구별되는 속성이 있습니다. 첫째, 기본적으로 tokens 간의 효율적인 시장을 지원합니다. 다른 발행자로부터. 특히 누구나 token을 발행할 수 있습니다. blockchain은 token 쌍 간의 거래를 위한 내장 주문서를 제공하며 사용자는 경로 지불을 발행할 수 있습니다. 여러 통화쌍에 걸쳐 원자적으로 거래되는 반면 종단간 한계 가격을 보장합니다. 둘째, Stellar은 새로운 비잔틴 계약을 도입합니다. 프로토콜, SCP(Stellar 합의 프로토콜)를 통해 token 발급자는 시행할 특정 validator 서버를 지정합니다. 거래 최종성. 발행자의 validator(및 기본 디지털 서명 및 암호화 hashes는 안전하게 유지됩니다.) 발행자는 어떤 거래가 발생했는지 정확히 알고 위험을 방지합니다. blockchain 기록 재구성으로 인한 손실. SCP의 핵심 아이디어는 대부분의 자산 발행자가 다음으로부터 이익을 얻는다는 것입니다. 유동적인 시장이며 원자 거래를 촉진하기를 원합니다. 다른 자산과 함께. 따라서 validator 관리자는 해당 서버는 정확한 내용에 대해 다른 validator과 동의합니다. 모든 자산에 대한 모든 거래 내역. validator v1은 다음과 같습니다. v2에 동의하도록 구성하거나 v2에 동의하도록 구성할 수 있습니다. v1을 사용하거나 둘 다 서로 동의하도록 구성할 수 있습니다. 모든 경우에 어느 쪽도 거래 내역을 약속하지 않습니다. 다른 사람이 다른 역사를 맡을 수 없다는 것을 알고 있습니다. 전이성에 따라 v1이 v2에 동의하지 않고 v2가 v3에 동의하지 않으면(또는 그 반대) v1은 v2에 동의하지 않을 수 있습니다. v3, v3이 v1이 들어본 자산을 나타내는지 여부 의. 이러한 합의 관계가 성립한다는 가설 하에 전체 네트워크를 전이적으로 연결, SCP 보장 글로벌 협약, 이를 글로벌 비잔틴 협약으로 만듭니다. 공개 멤버십을 갖춘 프로토콜. 우리는 이 새로운 연결성 가정을 인터넷 가설이라고 부르며, 모두가 이해하는 "인터넷"을 모두 보유하고 있습니다. 전이적으로 연결된 단일 최대 규모의 IP 네트워크를 의미함) 기존 국제 결제(홉별 결제) 비원자적이지만 전이적으로 연결된 글로벌 금융 기관 네트워크). Stellar은 2015년 9월부터 프로덕션에서 사용되었습니다. blockchain 길이를 관리 가능하게 유지하기 위해 시스템이 실행됩니다. 5초 간격의 SCP—blockchain 표준으로는 빠르지만, 비잔틴 계약의 일반적인 적용보다 훨씬 느립니다. 주요 용도는 결제였지만 Stellar은(는) 비화폐 대체 가능 token에 대한 매력이 입증되었습니다. 즉각적인 2차 시장에서 제공됩니다(섹션 7.1 참조). 다음 섹션에서는 관련 작업에 대해 설명합니다. 섹션 3은 다음과 같습니다. SCP. 섹션 4에서는 SCP의 공식 검증을 설명합니다. 섹션 5에서는 Stellar의 결제 계층에 대해 설명합니다. 섹션 6 관련 우리의 배포 경험과 교훈 중 일부. 섹션 7에서는 시스템을 평가합니다. 섹션 8이 마무리됩니다.

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 합의 프로토콜

Stellar 합의 프로토콜(SCP)은 쿼럼 기반입니다. 공개 멤버십을 갖춘 비잔틴 계약 프로토콜. 쿼럼은 개별 노드의 결합된 로컬 구성 결정에서 나타납니다. 그러나 노드는 오직 자신이 속한 정원회, 그리고 그 이후에만 다른 모든 정원회 구성원의 로컬 구성을 학습합니다. 이 접근 방식의 한 가지 이점은 SCP가 본질적으로 어떤 노드가 존재하는지에 대한 이질적인 관점을 허용합니다. 따라서, 노드는 별도의 작업 없이 일방적으로 합류하고 나갈 수 있습니다. 멤버십을 조정하기 위한 "변경 보기" 프로토콜입니다. 3.1 연합 비잔틴 계약 전통적인 비잔틴 합의 문제는 다음과 같이 구성됩니다. N개 노드로 구성된 폐쇄형 시스템. 그 중 일부는 결함이 있으며 임의로 행동하십시오. 노드는 입력 값을 받고 교환합니다. 입력 중 출력 값을 결정하는 메시지입니다. 비잔틴 합의 프로토콜은 선의로 행동하는 두 노드가 서로 다른 결정과 고유한 결과를 출력하지 않을 때 안전합니다. 결정은 유효한 입력이었습니다(유효한 합의의 일부 정의에 대해).SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 Lokhavaet al. 사전에). 프로토콜은 다음을 보장할 때 활성화됩니다. 모든 정직한 노드는 결국 결정을 내립니다. 일반적으로 프로토콜은 일부 정수에 대해 N = 3f + 1이라고 가정합니다. f > 0이면 안전성과 어떤 형태의 활성도 보장됩니다. 최대 f 노드에 결함이 있는 한. 이들 중 어느 단계에서는 프로토콜, 노드는 제안된 값과 제안에 투표합니다. 투표 정족수라고 불리는 2f + 1 표를 받는 것은 다음과 같습니다. 결정. N = 3f + 1개 노드의 경우 두 쿼럼은 크기 2f + 1은 최소 f + 1개 노드에서 겹칩니다. 만약 이것들이 f개라도 겹치는 노드에 결함이 있는 경우 두 쿼럼은 최소한 결함이 없는 노드 하나를 사용하여 모순된 결정을 방지합니다. 그러나 이 접근 방식은 모든 노드가 동의하는 경우에만 작동합니다. 쿼럼을 구성하는 것은 SCP에서는 불가능합니다. 두 노드는 서로의 존재조차 알지 못할 수도 있습니다. SCP를 사용하면 각 노드 v가 일방적으로 노드 집합을 선언합니다. (a) v는 쿼럼 슬라이스라고 부릅니다. 슬라이스의 구성원이 시스템 상태에 동의하면 그들은 옳고, (b) v는 그 조각 중 적어도 하나가 에 관한 정보를 적시에 제공할 수 있을 것입니다. 시스템 상태. 우리는 결과 시스템을 다음과 같이 부릅니다. 노드와 그 조각, 연합 비잔틴 계약 (FBA) 시스템. 다음에 살펴보겠지만, 정족수 시스템이 등장합니다. 노드의 조각에서. 비공식적으로 FBA 노드의 슬라이스는 누구와 함께 있는지 표현합니다. 노드에는 동의가 필요합니다. 예를 들어, 노드는 각각 3개의 노드를 실행하는 4개의 특정 조직과의 계약이 필요할 수 있습니다. 에 가동 중지 시간을 수용하여 슬라이스를 모든 세트로 설정할 수 있습니다. 각 조직의 2개 노드로 구성됩니다. 이것이 "필요하다면 '합의' 관계는 임의의 두 노드를 전이적으로 관련시킵니다. 우리는 세계적인 합의를 얻었습니다. 그렇지 않으면 우리는 발산을 얻을 수 있습니다. 그러나 어느 쪽도 요구하지 않는 조직 사이에서만 가능합니다. 상대방과의 합의. 오늘의 토폴로지를 고려하면 금융 시스템에서 우리는 광범위한 수렴이 사람들이 부르는 단일 원장 기록을 계속 생성할 것이라고 가정합니다. 우리가 인터넷에 대해 말하는 것과 마찬가지로 "Stellar 네트워크"입니다. 쿼럼은 다음과 같이 조각에서 발생합니다. 모든 노드는 지정합니다 보내는 모든 메시지에서 쿼럼 조각이 삭제됩니다. S를 메시지 집합이 시작된 노드 집합입니다. 에이 노드는 메시지 집합이 쿼럼에 도달한 것으로 간주합니다. S의 모든 구성원이 S에 포함된 슬라이스를 가질 때 임계값입니다. 구성에 따르면, 그러한 집합 S는 만장일치로 다음을 만족합니다. 각 회원의 동의 요구 사항. 결함이 있는 피어는 무엇을 변경하기 위해 제작된 슬라이스를 광고할 수 있습니다. 선의로 행동하는 노드는 쿼럼을 고려합니다. 프로토콜 분석을 위해 FBA의 쿼럼을 비어 있지 않은 것으로 정의합니다. 적어도 하나의 쿼럼 슬라이스를 포함하는 노드 집합 S 결함이 없는 각 멤버. 이 추상화는 어떤 집합과 마찬가지로 건전합니다. 만장일치로 정족수를 대표한다고 주장하는 메시지 실제로 그렇습니다(결함 있는 노드의 메시지가 포함된 경우에도). S가 선의로 행동하는 노드만 포함하면 정확합니다. 에서 이 섹션에서는 노드의 슬라이스가 변경되지 않는다고 가정합니다. 그럼에도 불구하고 우리의 결과는 슬라이스 변경 사례로 이전됩니다. 슬라이스가 변경되는 시스템은 다음과 같이 안전하기 때문입니다. 노드의 슬라이스가 모든 항목으로 구성되는 고정 슬라이스 시스템 슬라이스 변경 사례에서 사용한 슬라이스(정리 참조) [68]의 13). 섹션 4에서 설명했듯이 활성 상태는 다음에 따라 달라집니다. 선량하게 행동하는 노드는 결국 신뢰할 수 없는 노드를 제거합니다. 그들의 조각에서. 노드마다 계약 요구 사항이 다르기 때문에 FBA에서는 안전에 대한 글로벌 정의를 배제합니다. 우리는 말한다 결함이 없는 노드 v1과 v2는 다음과 같은 경우 서로 얽혀 있습니다. v1의 쿼럼은 적어도 하나의 v2의 모든 쿼럼과 교차합니다. 결함이 없는 노드. FBA 프로토콜은 합의를 보장할 수 있습니다. 얽힌 노드 사이에서만; SCP가 그렇게 하기 때문에, 그것의 잘못이다 안전에 대한 내성이 최적입니다. 인터넷 가설, Stellar의 기본 디자인에는 사람들이 관심을 갖는 노드가 명시되어 있습니다. 대략 얽히게 됩니다. I 외부의 모든 노드에 결함이 있더라도 I의 모든 두 구성원이 서로 얽혀 있는 균일하게 결함이 없는 쿼럼인 경우 노드 집합 I는 손상되지 않습니다. 직관적으로, 그러면 나는 손상되지 않은 사람의 행동에 영향을 받지 않는 상태를 유지해야 합니다. 노드. SCP는 비차단 활성 [93]과 노드 자체는 필요하지 않지만 손상되지 않은 세트에 대한 안전성 어떤 세트가 손상되지 않았는지 알 수 있습니다(알지 못할 수도 있음). 게다가, 교차하는 두 개의 온전한 집합의 합집합은 다음과 같습니다. 온전한 세트. 따라서 손상되지 않은 세트는 다음의 파티션을 정의합니다. 각 파티션이 안전하고 활성화되어 있는 잘 동작하는 노드 (일부 조건 하에서)하지만 다른 파티션이 출력될 수 있습니다. 다양한 결정. 3.1.1 FBA의 안전 및 활성 고려 사항 제한된 예외([64])를 제외하고 대부분의 폐쇄형 비잔틴 합의 프로토콜은 균형점에 맞춰 조정됩니다. 안전성과 활성성은 동일한 내결함성을 갖습니다. FBA에서는 이는 장애에 관계없이 모든 것이 가능한 구성을 의미합니다. 얽힌 세트도 그대로 유지됩니다. FBA가 결정한다는 점을 고려하면 분산된 방식으로 쿼럼을 구성하는 경우 개별 슬라이스 선택이 이러한 균형으로 이어질 가능성은 거의 없습니다. 더욱이, 적어도 Stellar에서는 균형이 바람직하지 않습니다. 그 결과 안전 실패(즉, 이중 지출 디지털 화폐)는 활성 실패(즉, 지연)보다 훨씬 더 나쁩니다. 어쨌든 Stellar 전에 며칠이 걸린 지불). 사람 그러므로 큰 쿼럼 조각을 선택해야 하며 그렇게 해야 합니다. 그들의 노드는 손상되지 않은 것보다 서로 얽혀 있을 가능성이 더 높습니다. 저울을 더 기울이면 회복하기가 더 쉽습니다. 기존의 폐쇄형 시스템보다 FBA 시스템의 일반적인 활성 오류입니다. 폐쇄형 시스템에서는 모든 메시지가 다음과 같아야 합니다. 동일한 정원회 집합을 기준으로 해석됩니다. 따라서, 장애 복구를 위해 노드를 추가 및 제거하려면 다음이 필요합니다. 합의가 더 이상 활성화되지 않으면 재구성 이벤트에 대한 합의에 도달하기가 어렵습니다. 이에 반해 FBA의 경우 모든 노드는 언제든지 쿼럼 슬라이스를 일방적으로 조정할 수 있습니다. 시간. 시스템적으로 중요한 서비스의 중단에 대응하여 조직에서 노드 관리자는 슬라이스를 다음과 같이 조정할 수 있습니다. 문제를 해결하세요. 대응을 조정하는 것과 비슷합니다. BGP 재앙 63 물리적 네트워크 링크를 통한 라우팅).

Stellar을 통한 빠르고 안전한 글로벌 결제 SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 3.1.2 캐스케이드 정리 SCP는 기본 원형 모델 [42]의 템플릿을 따릅니다. 노드는 번호가 매겨진 일련의 투표를 통해 진행됩니다. 세 가지 작업 시도: (1) 이전 투표의 결정과 모순되지 않는 "안전한" 값을 식별합니다(종종 투표용지 준비), (2) 안전한 값에 동의하고, (3) 합의가 성공적이었음을 감지합니다. 그러나 FBA는 열려 있습니다. 멤버십은 몇 가지 일반적인 기술을 방해합니다. 기존의 폐쇄형 프로토콜을 FBA로 "포팅"하는 것은 불가능합니다. 단순히 쿼럼의 정의를 변경하여 모델을 만들 수 있습니다. 많은 프로토콜에서 사용되는 기술 중 하나는 회전입니다. 시간 초과 후 라운드 로빈 방식으로 리더 노드를 통과합니다. 폐쇄형 시스템에서는 라운드 로빈 리더 선택이 보장됩니다. 결국 독특하고 정직한 리더는 단일 가치에 대한 합의를 조정하게 됩니다. 아쉽게도 라운드 로빈 멤버십을 알 수 없는 FBA 시스템에서는 작업할 수 없습니다. FBA에서 실패하는 또 다른 일반적인 기술은 특정 쿼럼이 모든 노드를 설득할 수 있다고 가정하는 것입니다. 예를 들어, 모든 사람이 2f + 1 노드를 쿼럼으로 인식하면 2f + 1개의 서명이면 모든 노드에 대한 프로토콜 상태를 증명하는 데 충분합니다. 마찬가지로, 노드가 동일한 메시지의 쿼럼을 수신하는 경우 신뢰할 수 있는 브로드캐스트 [24]을 통해 노드는 결함이 없는 모든 노드도 쿼럼을 볼 것이라고 가정할 수 있습니다. 이와 대조적으로 FBA에서는 쿼럼은 쿼럼 외부의 노드에 아무런 의미가 없습니다. 마지막으로, 비연합 시스템은 종종 "역방향"을 사용합니다. 안전에 대한 추론: f + 1개 노드에 결함이 있는 경우 모든 안전 보증이 손실됩니다. 따라서 노드 v가 f + 1개 노드를 모두 듣는다면 어떤 사실 F를 진술하고, v는 적어도 하나가 F를 말하고 있다고 가정할 수 있습니다. 안전의 손실 없이 진실(따라서 F가 참)입니다. 그러한 안전은 쌍의 속성이기 때문에 FBA에서는 추론이 실패합니다. 따라서 일부 피어에 대한 안전성을 잃은 노드는 항상 나쁜 사실을 가정하여 더 많은 노드에 대한 안전을 잃습니다. 그러나 FBA는 활성에 대해 거꾸로 추론할 수 있습니다. v-차단 세트를 모든 노드와 교차하는 노드 세트로 정의합니다. v의 슬라이스. v-차단 세트 B가 만장일치로 결함이 있는 경우 B 노드 v 쿼럼을 거부하고 활성 상태를 저하할 수 있습니다. 따라서 만약 B가 만장일치로 사실 F를 진술하면, v는 F가 다음 중 하나라는 것을 알게 됩니다. true 또는 v가 손상되지 않았습니다. 그러나 v는 여전히 전체 내용을 확인해야 합니다. 얽힌 노드가 F와 모순되지 않는다는 것을 알기 위한 쿼럼 이는 SCP에서의 마지막 의사소통으로 이어지며 유사하게 필요하지 않은 다른 FBA 프로토콜 [47] 폐쇄형 멤버십 프로토콜. 그 결과 우리는 잠재적인 사실에 대한 세 가지 가능한 신뢰 수준: 불확정, 온전한 노드 사이에서 가정해도 안전함(우리는 이를 용어로 인정된 사실), 서로 얽혀 있는 것으로 가정해도 안전합니다. 노드(확인된 사실이라고 부르겠습니다). 노드 v는 B가 모든 슬라이스와 교차하는지 여부를 확인하여 집합 B가 vblocking인지 여부를 효율적으로 결정할 수 있습니다. 흥미롭게도 노드가 항상 성명을 발표한다면 전체 쿼럼이 성명을 수락하면 성명이 전체에 전파되는 계단식 프로세스가 시작됩니다. 온전한 세트. 우리는 이 전파의 기초가 되는 핵심 사실을 다음과 같이 부릅니다. 캐스케이드 정리는 다음과 같습니다. 만약 내가 온전한 집합, Q는 I의 임의 구성원의 쿼럼이고 S는 임의의 구성원입니다. Q의 상위 집합, S ⊇I 또는 멤버 v ∈I가 있음 v < S이고 I ∩S는 v-차단입니다. 직관적으로 이랬나? 그렇지 않은 경우 S의 보수에는 쿼럼이 포함됩니다. 이는 I와 교차하지만 Q와는 교차하지 않아 쿼럼 교차를 위반합니다. S = Q로 시작하여 S를 반복적으로 확장하면 차단하는 모든 노드를 포함하면 계단식 효과를 얻을 수 있습니다. 결국 S는 I를 모두 포함합니다. 3.2 프로토콜 설명 SCP는 합의에 도달하기 위한 일련의 시도로 구성된 부분 동기식 합의 프로토콜 [42]입니다. 투표용지. 투표용지는 지속 시간이 늘어나는 타임아웃을 사용합니다. 에이 투표 동기화 프로토콜은 노드가 계속 유지되도록 보장합니다. 투표용지가 나올 때까지 동일한 투표용지를 점점 더 오랜 기간 동안 사용함 효과적으로 동기식입니다. 종료가 보장되지 않습니다. 투표용지가 동기식일 때까지는 두 개의 동기식 투표용지가 있습니다. 선의로 행동하는 노드 슬라이스의 결함이 있는 구성원이 수행하는 작업 방해하지 않으면 SCP가 종료되기에 충분합니다. 투표 프로토콜은 각 투표 동안 취해지는 조치를 지정합니다. 투표. 투표는 준비 단계로 시작됩니다. 모순되지 않는 제안 가치를 결정하려고 노력하십시오. 이전 결정. 그런 다음 커밋 단계에서 노드는 다음을 시도합니다. 준비된 가치에 대한 결정을 내립니다. 투표는 연합 투표라는 합의 하위 프로토콜을 사용합니다.n 어떤 노드가 추상 진술에 투표하는지 결국 확인되거나 중단될 수 있습니다. 일부 진술은 모순되는 것으로 지정될 수 있으며 안전성은 연합 투표의 보장은 두 명의 구성원이 참여하지 않는다는 것입니다. 서로 얽힌 세트는 모순되는 진술을 확인합니다. 손상되지 않은 경우를 제외하고 명세서의 확인은 보장되지 않습니다. 구성원이 모두 같은 방식으로 투표하도록 설정합니다. 그러나 만약 온전한 집합의 구성원이 연합된 진술을 확인합니다. 투표는 온전한 세트의 모든 구성원이 결국 해당 진술을 확인하도록 보장합니다. 그러므로 되돌릴 수 없는 조치를 취하는 것은 확인 진술에 대한 응답으로 다음의 활성 상태를 유지합니다. 온전한 노드. 노드는 처음에 추천을 통해 얻은 가치를 제안합니다. 손상되지 않은 모든 구성원의 가능성을 높이는 프로토콜 동일한 가치를 제안하는 세트는 결국 수렴됩니다. (그러나 수렴이 완료되었는지 확인할 방법은 없습니다). 지명은 연합 투표와 리더 선택을 결합합니다. FBA에서는 라운드 로빈이 불가능하기 때문에 지명은 다음을 사용합니다. 확률론적 리더 선택 계획. 캐스케이드 정리는 투표에서 중요한 역할을 합니다. 동기화 및 차단된 상태를 방지하는 데 있어 더 이상 종료가 불가능합니다. 3.2.1 투표 SCP 노드는 일련의 번호가 매겨진 투표를 진행하며 연합 투표를 사용하여 다음 사항에 대한 진술에 동의합니다. 가치는 어느 투표에서 결정되거나 결정되지 않습니다. 비동기인 경우 또는 잘못된 행동으로 인해 투표 n에서 결정을 내리지 못하는 경우, 노드는 시간 초과되고 투표 n + 1에서 다시 시도합니다.

SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 Lokhavaet al. 소환 연합 투표는 종료되지 않을 수 있습니다. 따라서 일부 투표 용지에 대한 진술은 영구적으로 정체될 수 있습니다. 노드가 자신인지 여부를 결코 결정할 수 없는 불확정 상태 아직 진행 중이거나 중단되었습니다. 노드는 배제할 수 없기 때문에 불확실한 진술이 나중에 사실로 판명될 가능성, 새로운 진술에 대해 연합 투표를 시도해서는 안 됩니다. 불확실한 것에 반대되는 것. 각 투표 n에서 노드는 두 가지 유형에 대한 연합 투표를 사용합니다. 성명서 : • prepare ⟨n,x⟩ – x 이외의 값은 없음을 나타냅니다. ≤n 투표에서 결정되었거나 결정될 예정입니다. • commit ⟨n,x⟩ – x가 투표 n에서 결정되었음을 나타냅니다. 중요한 것은 ⟨n,x⟩contradicts 커밋을 준비하는 것입니다. ⟨n′,x ′⟩n ≥n′이고 x , x ′인 경우. 노드는 a에 대한 연합 투표를 시도하여 n 투표를 시작합니다. 명령문은 ⟨n,x⟩를 준비합니다. 이전 준비 문이 있는 경우 연합투표를 통해 성공적으로 확인되었으며, 노드는 확인된 가장 높은 투표 준비에서 x를 선택합니다. 그렇지 않으면 노드는 x를 다음의 출력으로 설정합니다. 다음 하위 섹션에 설명된 지명 프로토콜. 노드가 준비 ⟨n,x⟩를 성공적으로 확인한 경우에만 투표 n에서는 커밋 ⟨n,x⟩에 대해 연합 투표를 시도합니다. 만약에 성공하면 SCP가 결정했음을 의미하므로 노드는 다음을 출력합니다. 확인된 커밋 문의 값입니다. 얽힌 집합 S를 생각해 보세요. 최대 하나의 값이므로 특정 투표에서 S 구성원이 작성한 것을 확인할 수 있지만 두 가지 다른 값이 확인되지는 않습니다. 특정 투표 용지에 S 멤버가 포함됩니다. 게다가 ⟨n,x⟩를 커밋하면 확인되면 준비 ⟨n,x⟩도 확인되었습니다. 이후 prepare ⟨n,x⟩는 연합 투표의 합의 보장에 따라 다른 값에 대한 이전 커밋과 모순됩니다. 우리는 이전에 다른 값이 결정될 수 없다는 것을 알고 있습니다. S회원의 투표. 투표용지 번호 유도를 통해 우리는 그러므로 SCP가 안전하다는 것을 알아내십시오. 활성을 위해서는 온전한 세트 I와 충분히 긴 세트를 고려하세요. 동기식 투표 n. 조각에 결함이 있는 노드가 나타나는 경우 선의로 행동하는 노드 중 n개는 간섭하지 않고 투표를 통해 간섭합니다. n + 1 I의 모든 멤버는 동일한 준비문 세트 P를 확인했습니다. P = ∅이고 투표용지 n이 충분히 길면, 지명 프로토콜은 어떤 값 x에 수렴될 것입니다. 그렇지 않은 경우 x를 P에서 가장 높은 투표로 준비한 값으로 둡니다. 어느 쪽이든 균일하게 페더레이션을 시도합니다. 다음 투표에서 준비 ⟨n + 1,x⟩에 투표하세요. 그러므로 만일 n + 1도 동기식이므로 x에 대한 결정은 필연적으로 따릅니다. 3.2.2 지명 지명에는 다음 진술에 대한 연합 투표가 수반됩니다. • x 지명 – x가 유효한 결정 후보임을 명시합니다. 노드는 여러 가치를 지명하기 위해 투표할 수 있습니다. 지명 진술은 모순되지 않습니다. 그러나 일단 노드는 지명 성명을 확인하고 투표를 중단합니다. 새로운 가치를 지명합니다. 연합 투표는 여전히 노드가 다음을 수행할 수 있도록 허용합니다. 투표하지 않은 새로운 지명 성명을 확인합니다. 투표 또는 수락 정족수에서 받아들이다 정족수에서 a는 유효하다 ~로부터 받다 차단 세트 커밋되지 않은 투표했다 받아들였다 확인했다 ¬a에 투표했습니다 그림 1. 연합 투표 단계 온전한 집합의 구성원이 서로 확인할 수 있도록 허용 새로운 투표를 보류하면서 가치를 지명합니다. 지명의 (진화하는) 결과는 확인된 지명 명세서에 있는 모든 값의 결정론적 조합입니다. 만약에 x는 일련의 거래를 나타내며, 노드는 합집합을 취할 수 있습니다. 세트 중 가장 큰 세트 또는 가장 높은 hash을 가진 세트입니다. 모든 노드가 동일한 작업을 수행하는 한. 노드가 새로운 것을 보류하기 때문에 하나의 지명 성명을 확인한 후 투표합니다. 확인된 문에는 한정된 수의 값만 포함될 수 있습니다. 확인된 진술이 확실하게 전파된다는 사실 손상되지 않은 세트는 손상되지 않은 노드가 결국 다음으로 수렴됨을 의미합니다. 동일한 지정 값 세트 및 그에 따른 지정 결과, 하지만 프로토콜의 임의로 늦은 시점에 알 수 없는 지점이 있습니다. 노드는 연합 리더 선택을 사용하여 지명 진술서의 다양한 값 수. 만 지명 성명서에 아직 투표하지 않은 리더는 새로운 x를 도입할 수 있습니다. 다른 노드는 응답을 기다립니다. 리더의 (유효한) 지명 투표를 복사하면 됩니다. 실패를 수용하기 위해 리더 세트는 다음과 같이 계속 성장합니다. 시간 초과가 발생하지만 실제로는 소수의 노드에서만 새로운 x 값이 도입됩니다. 3.2.3 연합 투표 연합 투표는 다음과 같은 3단계 프로토콜을 사용합니다. 그림 1. 노드는 먼저 추상적 진술에 동의하려고 시도합니다. 투표하고, 수락하고, 최종적으로 진술을 확인합니다. 노드 v는 그렇지 않은 유효한 진술 a에 투표할 수 있습니다. 다른 것과 모순된다미결제 투표 및 수락된 성명서. 이는 서명된 투표 메시지를 방송함으로써 이루어집니다. v 그런 다음 a가 다른 승인된 진술과 일치하고 (사례 1) v가 다음과 같은 쿼럼의 구성원인 경우 a를 승인합니다. 각 노드는 a에 투표하거나 a를 수락합니다. 또는 (케이스 2) v인 경우에도 마찬가지입니다. a에 투표하지 않았으면 v-차단 세트가 a를 수락합니다. 경우 2의 경우, v는 이전에 a에 반대되는 투표를 한 적이 있는데, 지금은 기각되었습니다. v 기각된 투표를 잊어버리는 것이 허용됩니다. v가 손상되지 않은 경우 이를 알고 있기 때문에 결코 캐스팅하지 않은 척합니다. 기각된 투표는 사례 1을 통해 정족수를 완료할 수 없습니다. v는 a를 수락한다고 브로드캐스트한 다음 a가 수신되면 확인합니다. 만장일치로 a를 받아들이는 정족수. 그림 2는 v-차단 세트의 효과와 캐스케이드 정리 연합투표. 서로 얽힌 두 개의 노드는 모순되는 진술을 확인할 수 없습니다. 두 개의 필수 쿼럼이 공유해야 하기 때문입니다.Stellar를 통한 빠르고 안전한 글로벌 결제 SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 3 4 2 1 5 7

โหวต X

โหวต Y (ก) 3 4 2 1 5 7 6 โหวต เอ็กซ์ โหวต เอ็กซ์ โหวต เอ็กซ์ โหวต ย โหวต เอ็กซ์ โหวต ย โหวต ย (ข) 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 투표

Y에 투표하세요 (아) 3 4 2 1 5 7 6 투표 X 투표 X 투표 X 투표 Y 투표 X 투표 Y 투표 Y (비) 3 4 2 1 5 7 6 수락 X 투표 X 수락 X 투표 Y 수락 X 투표 Y 투표 Y (다) 3 4 2 1 5 7 6 수락 X 수락 X 수락 X 투표 Y 수락 X 수락 X 투표 Y (디) 3 4 2 1 5 7 6 수락 X 투표 X 수락 X 수락 X 수락 X 수락 X 수락 X (e) 그림 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 투표지 동기화 노드가 해당 커밋 문을 확인할 수 없는 경우 현재 투표용지에서 시간 초과 후 포기합니다. 시간 초과가 발생합니다. 임의의 범위에 맞게 조정하기 위해 각 투표 용지의 길이를 늘립니다. 네트워크 지연에. 그러나 시간 초과만으로는 동시에 시작되지 않은 노드의 투표를 동기화하는 데 충분하지 않습니다. 다른 이유로 동기화가 해제되었습니다. 동기화를 달성하기 위해 노드는 노드가 노드의 일부인 경우에만 타이머를 시작합니다. 현재(또는 이후) 투표 n에 모두 참여하는 정족수. 이 일찍 시작된 노드의 속도를 늦추고 온전한 세트의 구성원이 그룹보다 너무 앞서 있습니다. 게다가 노드 v가 나중에 v-blocking 세트를 발견한 경우 즉시 가장 낮은 투표지로 건너뜁니다. 타이머에 관계없이 더 이상 그렇지 않습니다. 캐스케이드 정리는 모든 낙오자들이 따라잡을 수 있도록 보장합니다. 결과 투표용지는 온전한 전체에 걸쳐 대략적으로 동기화된다는 것입니다. 시스템이 동기화되면 설정됩니다. 3.2.5 연합 리더 선택 리더 선택을 통해 각 노드는 다음과 같은 리더를 선택할 수 있습니다. 노드가 일반적으로 하나 또는 작은 숫자만 선택하는 방식 지도자의. 리더 실패를 수용하기 위해 리더 선택 라운드를 통해 진행됩니다. 현재 라운드의 리더인 경우 자신의 책임을 다하지 않는 것처럼 보이다가 나중에 특정 시간 초과 기간 노드는 다음 라운드로 진행됩니다. 그들이 따르는 리더의 집합을 확장합니다. 각 라운드에서는 [0,hmax) 범위의 정수를 출력하는 두 개의 고유한 암호화 hash 함수인 H0 및 H1을 사용합니다. 예를 들어 Stellar은 Hi(m) = SHA256(ib||r||m)을 사용합니다. 여기서 b는 전체 SCP 인스턴스(블록 또는 원장 번호)이고, r은 리더 선택 라운드 번호, hmax = 2256. 내 라운드마다 노드 v의 우선순위를 다음과 같이 정의합니다. 우선순위(v) = H1(v) 각 노드마다 하나의 Stratman이 리더로 선택됩니다. 우선순위가 가장 높은 노드(v). 이 접근 방식은 효과적입니다. 거의 동일한 쿼럼 슬라이스를 사용하지만 제대로 작동하지 않습니다. 불균형 구성에서 노드의 중요성을 포착합니다. 예를 들어 유럽과 중국이 각각 3씩 기여한다면 모든 쿼럼에 노드를 할당하지만 중국은 1,000개의 노드를 실행하고 유럽은 4개를 실행하는 경우 중국이 99.6%의 가장 높은 우선순위 노드를 갖게 됩니다. 시간의. 따라서 우리는 슬라이스 가중치의 개념을 도입합니다. Weight(u,v) ∈[0, 1]은 노드 u의 쿼럼 슬라이스의 비율입니다. 노드 v를 포함합니다. 노드 u가 새로운 리더를 선택할 때, 다음과 같이 정의된 이웃만 고려합니다. 이웃(u) = {v | H0(v) < hmax · 가중치(u,v) } 그런 다음 노드는 빈 리더 세트로 시작하고 각 라운드는 그것에 가장 높은 이웃(u)의 노드 v를 추가합니다. 우선순위(동사). 모든 라운드에서 이웃 세트가 비어 있으면 u는 대신 H0(v)/weight(u,v)의 가장 낮은 값을 가진 nodev를 추가합니다.

การตรวจสอบ 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의 공식 검증

설계 오류를 없애기 위해 SCP의 안전성을 정식으로 검증했습니다. 및 활성 속성([65] 참조). 구체적으로 우리는 확인했습니다. 서로 얽힌 노드는 결코 동의하지 않으며 아래에 설명된 조건 하에서 온전한 세트의 모든 구성원이 결국 결정합니다. 흥미롭게도 검증 결과 SCP가 활성을 보장하는 조건은 미묘합니다. 처음에 생각했던 것보다 더 강합니다 [68]: 아래에 설명된 대로, 별다른 조치 없이 타이밍을 조작하는 악성 노드 프로토콜에서 벗어나면 수동으로 제거해야 할 수도 있습니다. 쿼럼 조각에서.

SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 Lokhavaet al. 속성이 가능한 모든 측면에서 유지되는지 확인하기 위해 FBA 구성 및 실행은 임의적인 것으로 간주됩니다. 임의의 로컬 구성이 있는 노드 수. 이 분리된 온전한 세트가 있는 시나리오와 잠재적으로 무한히 긴 실행이 포함됩니다. 단점은 우리가 매개변수화된 값을 검증하는 어려운 문제에 직면합니다. 무한 상태 시스템. 검증을 다루기 쉽게 유지하기 위해 우리는 Ivy [69] 및 [82] 방법론을 사용하여 1차 논리(FOL)로 SCP를 모델링했습니다. 검증 프로세스는 수동으로 귀납적 추측을 제공한 다음 자동으로 확인하는 것으로 구성됩니다. 아이비. SCP의 FOL 모델은 다음의 일부 측면을 추상화합니다. FOL에서 다루기 어려운 FBA 시스템(예: 캐스케이드 정리는 공리로 간주되므로) Isabelle/HOL [75]을 사용한 추상화의 건전성. FOL에서 검증 문제를 표현한 후 귀납적 불변량을 제공하여 안전성을 검증합니다. 유도성 불변은 약 12개의 한 줄 추측으로 구성됩니다. 150라인의 프로토콜 사양. 그런 다음 Ivy의 선형 시간 논리에서 SCP의 활성 속성을 지정하고 liveness를 줄이기 위해 [80, 81]의 안전 감소에 대한 liveness 검증 문제에서 귀납적 문제를 찾는 문제 불변. SCP의 안전은 상대적으로 간단하지만 증명하자면, SCP의 생존성 주장은 훨씬 더 복잡하고 약 150개의 단일 행 불변성으로 구성됩니다. 활성을 증명하려면 다음의 정확한 형식화가 필요합니다. SCP가 종료를 보장한다는 가정. 우리는 처음에 온전한 세트가 모두 있는 경우 항상 종료할 것이라고 생각했습니다. 구성원이 슬라이스 [68]에서 결함이 있는 노드를 제거했습니다. 그러나 이것은 불충분한 것으로 판명되었습니다. 손상되지 않음) I can 구성원의 쿼럼에 있는 노드, 결함이 있는 노드의 영향을 완료하여 종료를 방지합니다. 투표가 끝나기 직전에 정족수를 확보하여 I 멤버는 다음 투표에서 다른 x 값을 선택했습니다. 따라서 우리는 비공식적으로 다음을 추가로 가정해야 합니다. I 구성원의 쿼럼에 있는 각 노드는 결국 다음 중 하나를 수행합니다. 적시에 메시지를 보내거나 충분한 기간 동안 메시지를 전혀 보내지 않습니다. 실제로 이는 I의 구성원이 조건이 유지될 때까지 슬라이스를 조정해야 합니다. 이 문제는 FBA 시스템에 고유한 것이 아닙니다: Losa et al. [47] 현재 활성도가 엄격하게 약한 프로토콜에 따라 달라지는 프로토콜 슬라이스에서 결함이 있는 노드를 제거할 필요 없이 최종 동기화 및 최종 리더 선택만 가정합니다.

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

ส่วนนี้จะอธิบายเครือข่ายการชำระเงินของ 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 กำลังตรวจสอบการกำหนดค่าที่มีความเสี่ยง การตรวจพบว่าเครือข่ายยอมรับโควรัมที่ไม่เป็นสมาชิกร่วมนั้นเป็นขั้นตอนหนึ่ง ไปถูกทางแต่ส่งสัญญาณอันตรายช้าอย่างไม่สบายใจ สำหรับปัญหาที่สำคัญเช่นนี้ ตามหลักการแล้ว เราต้องการให้ผู้ดำเนินการโหนดได้รับคำเตือนเมื่อมีการกำหนดค่าโดยรวมของเครือข่าย กำลังเข้าสู่ภาวะเสี่ยงเท่านั้น ดังนั้นเราจึงขยายตัวตรวจสอบโควรัม-ทางแยก เพื่อตรวจจับสภาวะที่เราเรียกว่าวิกฤต: เมื่อกระแส การกำหนดค่าโดยรวมคือการกำหนดค่าที่ไม่ถูกต้องอย่างหนึ่ง รัฐที่ยอมรับองค์ประชุมที่ไม่ต่อเนื่องกัน เพื่อตรวจจับภาวะวิกฤติ ตัวตรวจสอบจะแทนที่การกำหนดค่าของแต่ละองค์กรซ้ำแล้วซ้ำอีกด้วยการกำหนดค่าที่ไม่ถูกต้องที่เลวร้ายที่สุดจำลอง รันตัวตรวจสอบจุดตัดโควรัมด้านในกับผลลัพธ์อีกครั้ง หากมีการกำหนดค่าผิดพลาดร้ายแรงดังกล่าวอยู่อีกขั้นตอนหนึ่ง จากสถานะปัจจุบันซอฟต์แวร์จะออกคำเตือนและ รายงานองค์กรที่มีความเสี่ยงในการกำหนดค่าที่ไม่ถูกต้อง การเปลี่ยนแปลงเหล่านี้ทำให้ชุมชนของผู้ปฏิบัติงานมีสองชั้น การแจ้งเตือนและคำแนะนำเพื่อป้องกันรูปแบบที่เลวร้ายที่สุด ของการกำหนดค่าผิดพลาดร่วมกัน

결제 네트워크

이 섹션에서는 SCP 위에 복제된 상태 머신 [88]으로 구현된 Stellar의 결제 네트워크에 대해 설명합니다. 5.1 원장 모델 Stellar의 원장은 계정 추상화를 중심으로 설계되었습니다( 보다 코인 중심의 사용되지 않은 거래 출력과 대조 또는 UTXO 모델의 Bitcoin). 원장 내용은 다음과 같이 구성됩니다. 계정, 신탁선, 등 네 가지 유형의 원장 항목 집합 제안 및 계정 데이터. 계정은 자산을 소유하고 발행하는 주체입니다. 각각 계정의 이름은 공개 키로 지정됩니다. 기본적으로 해당 개인 키는 계정에 대한 거래에 서명할 수 있습니다. 그러나 다른 서명자를 추가하고 계정 이름을 지정하는 키의 인증을 취소하도록 계정을 재구성할 수 있습니다. 여러 서명자를 요구하는 "다중 서명" 옵션. 각 계정 또한 다음을 포함합니다: 시퀀스 번호(트랜잭션에 포함됨) 재생을 방지하기 위해), 일부 플래그 및 "네이티브"의 균형 XLM이라는 사전 채굴된 암호화폐로, 일부 서비스 거부 공격 및 시장 형성 촉진 중립 통화로. Trustlines는 발행된 자산의 소유권을 추적합니다. 발행 계좌와 숏 계좌로 구성된 쌍으로 명명 자산 코드(예: 'USD' 또는 'EUR'). 각 신뢰선은 다음을 지정합니다. 계정, 자산, 해당 자산의 계정 잔액, 잔고를 초과할 수 없는 한도 및 일부 플래그. 계정은 자산 보유에 명시적으로 동의해야 합니다. 스패머가 안장하는 것을 방지하는 신뢰 라인 생성 원하지 않는 자산이 있는 계정. 고객 파악(KYC) 규정에 따라 많은 금융 기관은 자신이 보유하고 있는 예금이 누구인지 알아야 합니다. 예를 들어 사진이 있는 신분증을 확인하는 것입니다. 이를 준수하기 위해 발급자는 다음을 설정할 수 있습니다. 계정에 선택적인 auth_reqired 플래그를 추가하여 발행한 자산의 소유권을 승인된 계정으로 제한합니다. 그러한 승인을 부여하기 위해 발급자는 승인된 권한을 설정합니다. 고객의 신뢰선에 플래그를 지정합니다. 제안은 계정의 거래 의지에 따라 결정됩니다. 특정 자산의 일정 금액을 다른 자산에 대해 특정 금액으로 주문서의 가격; 자동으로 일치하고 매수/매도 가격이 교차할 때 채워집니다. 마지막으로 계정 데이터는 계정, 키, 값의 세 가지로 구성되어 계정 소유자를 허용합니다. 작은 메타데이터 값을 게시합니다. 원장 스팸을 방지하기 위해 최소 XLM 잔액이 있습니다. 예비라고. 계정의 준비금은 각각 증가합니다. 관련 원장 입력 및 원장 입력 시 감소 사라집니다(예: 주문이 완료되거나 취소되는 경우, 또는 신뢰라인이 삭제되었습니다). 현재 준비금은 0.5 XLM 증가합니다. (~$0.03) 원장 항목당. 보유금액에 상관없이, 삭제를 통해 계정의 전체 가치를 회수 가능 AccountMerge 작업을 사용하여 이를 수행합니다. 그림 3에 표시된 원장 헤더는 전역 속성을 저장합니다. 원장 번호, 예비 잔액과 같은 매개변수 원장 항목, 이전 원장 헤더의 hash(실제로는 여러 hashes가 건너뛰기 목록을 형성함), SCP 출력에는 다음이 포함됩니다. 이 원장에 적용된 새로운 거래의 hash, 의 hash 해당 거래의 결과(예: 성공 또는 실패) 각각) 및 모든 원장 항목의 스냅샷 hash. 스냅샷 hash에는 모든 원장 내용이 포함되어 있으므로, validators는 거래를 검증하기 위해 기록을 보유할 필요가 없습니다. 그러나 예상되는 수억 규모로 확장하려면 계정마다 모든 원장 항목 테이블을 다시hash할 수는 없습니다. 장부를 닫습니다. 또한, 원장을 이전하는 것은 실용적이지 않습니다.Stellar를 통한 빠르고 안전한 글로벌 결제 SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 원장 # = 4 H(이전 hdr) SCP 출력 H(결과) H(스냅샷) ... 헤더 원장 # = 5 H(이전 hdr) SCP 출력 H(결과) H(스냅샷) ... 헤더 . . . 그림 3. 원장 내용. H는 SHA-256이고, H *는 H의 계층적 또는 재귀적 적용을 나타냅니다. SCP 출력 또한 이전 헤더 hash에 따라 달라집니다. 계정 만들기 새 계정 원장 항목 생성 및 자금 조달 계정병합 계정 원장 항목 삭제 옵션 설정 계정 플래그 및 서명자 변경 결제 대상에게 특정 수량의 자산을 지불합니다. 계정 경로지불 결제와 비슷하지만 다른 자산으로 결제(최대 제한하다); 최대 5개의 중개 자산을 지정하세요. 제안 관리 제안 원장 항목 생성/삭제/변경, -패시브 제안 확산을 허용하지 않는 수동적 변형 포함 데이터 관리 계정 생성/삭제/변경 데이터 원장 항목 변화신뢰 신뢰라인 생성/삭제/변경 허용신뢰 트러스트 라인에서 승인된 플래그 설정 또는 지우기 범프 시퀀스 시퀀스를 늘립니다. 계좌번호 그림 4. 원장 운영 노드 연결이 끊어질 때마다 해당 크기 네트워크가 너무 오래 연결되었습니다. 따라서 스냅샷 hash은(는) hashing 및 상태 조정을 모두 최적화하도록 설계되었습니다. 특히 스냅샷은 원장 항목을 시간별로 계층화합니다. 기하급수적으로 크기가 커지는 컨테이너 세트의 마지막 수정 버킷이라고 부릅니다. 버킷 모음을 버킷이라고 합니다. 목록을 작성하며 로그 구조 병합 트리와 일부 유사합니다. (LSM-트리) [77]. 버킷리스트는 트랜잭션 처리 중에는 읽히지 않습니다(섹션 5.4 참조). 그러므로 특정 디자인 LSM 트리의 측면을 완화할 수 있습니다. 특히, 무작위 키로 액세스할 필요가 없으며 버킷은 읽기만 가능합니다. 병합 수준의 일부로 순차적으로. 버킷 해싱 목록은 병합될 때 각 버킷을 hashing하고 버킷 hashes의 새로운 누적 hash을 계산하여 수행됩니다(작은, 각 원장 마감 시 고정 참조 인덱스 hashes). 연결 해제 후 버킷리스트를 조정하려면 다운로드가 필요합니다. 버킷만 다릅니다. 5.2 거래 모델 거래는 원본 계정, 유효성 기준, 메모 및 하나 이상의 작업 목록. 그림 4에는 사용 가능한 작업이 나열되어 있습니다. 각 작업에는 원본 계정이 있습니다. 기본값은 전체 거래의 기본값입니다. 거래는 반드시 모든 소스 계정에 해당하는 키로 서명되어야 합니다. 작업. 다중서명 계정에는 더 높은 서명이 필요할 수 있습니다. 일부 작업(예: SetOptions)의 가중치 이하 다른 경우(예: AllowTrust). 트랜잭션은 원자적입니다. 작업이 실패하면 아무 작업도 수행되지 않습니다. 그들은 실행합니다. 이는 다자간 거래를 단순화합니다. 가정하자 발행자는 토지 증서를 나타내는 자산을 생성하고 사용자 A는 작은 토지 구획과 $10,000를 교환하고 싶습니다. B가 소유한 더 큰 토지 구획. 두 사용자는 모두 서명할 수 있습니다. 세 가지 작업을 포함하는 단일 거래: 두 개의 토지 지불 및 1달러 지불. 트랜잭션의 주요 유효성 기준은 시퀀스 번호이며, 이 시퀀스 번호는 트랜잭션의 시퀀스 번호보다 1 커야 합니다. 원본 계정 원장 항목입니다. 유효한 트랜잭션 실행 (성공 여부에 관계없이) 시퀀스 번호를 증가시켜 재생을 방지합니다. 초기 시퀀스 번호에는 원장이 포함됩니다. 삭제 후에도 재생을 방지하기 위해 상위 비트에 숫자를 넣습니다. 그리고 계정을 다시 만드세요. 다른 타당성 기준은 선택적인 제한입니다. 트랜잭션이 실행될 수 있습니다. 땅과 달러로 돌아가다 위의 스왑에서 A가 B보다 먼저 거래에 서명하면 A는 서명하지 않을 수 있습니다. B가 제출하기 전에 1년 동안 거래를 보류하기를 원합니다. 따라서 거래를 무효화하는 시간 제한을 둘 수 있습니다. 며칠 후. 다중서명 계정도 구성할 수 있습니다 hash 사전 이미지의 공개에 서명 가중치를 부여하기 위해, 이는 시간 제한과 결합되어 원자 크로스체인 거래를 허용합니다 [1]. 거래의 원본 계정은 XLM으로 소소한 수수료를 지불합니다. 정체가 없는 한 10−5 XLM. 혼잡 상황에서는 운영 비용은 네덜란드 경매에 의해 결정됩니다. 검증인은 validators가 유사하기 때문에 수수료로 보상되지 않습니다. 채굴자가 아닌 Bitcoin 전체 노드로. XLM을 파괴하는 대신, 수수료는 투표에 의해 비례적으로 재활용되고 분배됩니다. 기존 XLM 보유자(회고하면 그럴 수도 있고 그럴 수도 있음) 복잡성을 감당할 가치가 없었습니다. 5.3 합의 가치 각 원장에 대해 Stellar은 SCP를 사용하여 데이터 구조에 동의합니다. 세 개의 필드 포함: 트랜잭션 세트 hash(hash 포함) 이전 원장 헤더의), 마감 시간,d 업그레이드. 여러 값이 지명된 것으로 확인되면 Stellar이 가장 많은 작업이 포함된 트랜잭션 세트(연결 끊기) 총 수수료를 기준으로 거래 세트 hash), 모든 항목의 합집합 업그레이드 및 가장 높은 마감 시간. 마감시간은 오직 마지막 원장의 마감 시간과 마감 시간 사이이면 유효합니다. 존재하므로 노드는 잘못된 시간을 지정하지 않습니다. 업그레이드는 준비금 잔액, 최소 운영 비용 및 프로토콜 버전과 같은 글로벌 매개변수를 조정합니다. 언제 지명 중에 결합되면 높은 수수료와 프로토콜 버전 번호가 낮은 번호를 대체합니다. 업그레이드는 연합 투표 난투 공간을 통해 거버넌스에 영향을 미칩니다 [34], 둘 다 평등주의적이지도 중앙집권적이지도 않습니다. 각 validator은(는) 다음과 같이 구성됩니다. 관리 또는 비관리(기본값)에 따라 운영자가 거버넌스에 참여하기를 원하는지 여부. validator을 관리하려면 세 가지 종류의 업그레이드를 고려하세요. 원하는 것, 유효한 것, 유효하지 않은 것(validator이 하지 않는 모든 것)

SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 Lokhavaet al. validator 핵심 지평선 FS DB DB 제출하다 클라이언트 클라이언트 다른 validators 그림 5. Stellar validator 아키텍처 구현 방법을 알고 있습니다). 원하는 업그레이드가 다음과 같이 구성되었습니다. 특정 시간에 트리거되고 서로 조정되도록 의도되었습니다. 연산자. 관리 노드는 항상 원하는 후보를 지명하기 위해 투표합니다. 업그레이드, 수락하지만 유효한 업그레이드를 지명하기 위해 투표하지는 않음 (즉, 차단 정족수를 따르며) 절대로 투표하지 마십시오. 또는 잘못된 업그레이드를 수락합니다. 비정부 validators 에코 유효한 업그레이드에 대해 보는 모든 투표(기본적으로 위임) 선택한 사람들이 원하는 업그레이드에 대한 결정 거버넌스 역할을 위해. 5.4 구현 그림 5는 Stellar의 validator 아키텍처를 보여줍니다. 데몬 stellar-core(~92k 라인의 C++, 타사 라이브러리 제외)라고 불리는 SCP 프로토콜과 복제된 상태 머신을 구현합니다. SCP의 가치를 생성하려면 많은 수의 원장 항목을 작은 암호화로 줄여야 합니다. hashes. 대조적으로, 거래 검증 및 실행 계정 상태 및 주문 일치를 조회해야 합니다. 최고의 가격. 두 기능을 모두 효율적으로 제공하기 위해 stellar-core 원장의 두 가지 표현, 즉 버킷 목록을 포함하는 외부 표현을 유지하며 바이너리 파일로 저장됩니다. 효율적으로 업데이트하고 점진적으로 rehashed할 수 있습니다. SQL 데이터베이스의 내부 표현(PostgreSQL 생산 노드의 경우). Stellar-core는 다음을 포함하는 쓰기 전용 기록 아카이브를 생성합니다. 확인된 각 트랜잭션 세트와 스냅샷 버킷. 아카이브를 통해 새 노드가 스스로 부트스트랩할 수 있습니다. 네트워크에 가입할 때. 장부에 대한 기록도 제공합니다. 역사 - 자료를 찾아볼 수 있는 곳이 있어야 합니다. 2년 전 거래. 기록은 추가 전용이므로 자주 접근하지 않는 정보이므로 저렴한 곳에 보관할 수 있습니다. Amazon Glacier 또는 저장을 허용하는 모든 서비스 등 플랫 파일을 검색합니다. 검증인 호스트는 일반적으로 호스트하지 않습니다. 검증에 영향을 미치지 않도록 자체 아카이브 제공 기록의 실적입니다. 스텔라 코어를 단순하게 유지하기 위해 사용되지 않습니다. 애플리케이션에 의해 직접 제공되며 새로운 트랜잭션 제출을 위해 매우 좁은 인터페이스만 노출합니다. 지원하다 클라이언트, 대부분의 validators는 horizon(~18k)이라는 데몬을 실행합니다. Go 라인) 제출을 위한 HTTP 인터페이스를 제공합니다. 그리고 거래를 학습합니다. horizon에는 읽기 전용 액세스 권한이 있습니다. stellar-core의 SQL 데이터베이스, 지평선의 위험을 최소화 불안정한 항성핵. 지불 경로 찾기와 같은 기능은 완전히 수평으로 구현되며 업그레이드 가능 다른 validator들과 협력하지 않고 일방적으로. 여러 선택적 상위 계층 데몬이 클라이언트가 되어 생태계를 완성합니다. 브릿지 서버는 다음을 용이하게 합니다. Stellar을 기존 시스템과 통합합니다(예: 특정 계정에서 받은 모든 결제에 대한 알림 게시). 에이 규정 준수 서버는 금융 기관에 후크를 제공합니다. 발송인 및 수취인 정보 교환 및 승인 제재 목록 준수를 위해 결제 시. 마지막으로, 페더레이션 서버는 사람이 읽을 수 있는 이름 지정을 구현합니다. 계정 시스템. 6 배포 경험 Stellar은 몇 년 동안 적당한 수준의 상태로 성장했습니다. 합리적으로 신뢰할 수 있는 전체 노드 운영자의 수. 그러나, 노드의 구성은 활성 상태였습니다(물론 그렇지는 않았지만 안전)은 우리 Stellar 개발 재단에 달려 있습니다. (SDF); SDF가 갑자기 사라졌다면, 다른 노드 운영자들은 개입하여 수동으로 우리를 제거해야 했을 것입니다. 네트워크를 계속하려면 쿼럼 슬라이스에서 가져옵니다. 우리와 다른 많은 사람들은 SDF의 시스템적 중요성을 줄이고 싶어하지만 이 목표는 이후에 점점 더 높은 우선순위를 받았습니다. 연구원 [58] 안전 및 위험에 대한 위험을 구분하지 않고 네트워크의 중앙 집중화를 정량화하고 공개했습니다. 활력. 많은 운영자가 적극적인 구성 조정에 반응하여 주로 규모를 늘렸습니다. SDF의 중요성을 희석하기 위한 노력의 일환으로 정족수 분할; 아이러니하게도 이는 생존에 대한 위험만 증가시켰습니다. 두 가지 문제가 상황을 악화시켰습니다. 먼저, 인기 있는 타사 Stellar 모니터링 도구 [5]가 체계적으로 실제로 확인하지 않음으로써 validator 가동 시간을 과대평가함 그 스텔라 코어가 실행 중이었습니다. 이는 사람들이 다음을 포함하도록 유도합니다. 쿼럼 슬라이스에 신뢰할 수 없는 노드가 있습니다. 둘째, 버그 stellar-core는 validator이 다음 원장으로 이동한 것을 의미합니다. 나머지 노드가 사전 준비를 완료하는 데 적절하게 도움이 되지 않았습니다.메시지 분실에 대비한 장부. 그 결과, 네트워크에서 67분의 다운타임이 발생하여 필요 validator 관리자가 수동으로 조정하여 다시 시작합니다. 더 나쁜 것은 네트워크를 다시 시작하려고 시도하는 동안 여러 노드에서 동시에 긴급한 재구성이 발생했다는 것입니다. 일부 노드에서 분기되어 해당 노드를 수동으로 종료해야 하며 분기 동안 승인된 거래를 다시 제출합니다. 다행히도 이러한 차이가 포착되어 수정되었습니다. 신속하고 충돌하는 거래가 포함되지 않았지만 네트워크가 쿼럼 교차를 활용하지 못할 위험 - 잠재적인 충돌을 계속 수용하면서 분열 단순히 구성 오류로 인해 트랜잭션이 발생했습니다. 이번 사건으로 매우 구체적이군요. 이러한 경험을 검토한 결과 두 가지 주요 결론이 도출되었습니다. 그리고 그에 상응하는 시정 조치.Stellar를 통한 빠르고 안전한 글로벌 결제 SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 심각, 100% 51% 51% 높음, 67% 51% 중간, 67% 51% 낮음, 67% 51% 51% ... ... ... 51% ... 51% 그림 6. 유효성 검사기 품질 계층 구조. 최고 품질의 노드 가장 높은 임계값인 100%가 필요한 반면, 낮은 품질은 67% 임계값으로 구성됩니다. 단일 내의 노드 조직은 51%의 과반수를 요구합니다. 6.1 구성의 복잡성과 취약성 Stellar은 쿼럼 슬라이스를 n 항목과 k 항목 집합이 있는 임계값 k로 구성된 중첩된 쿼럼 집합으로 표현합니다. 쿼럼 슬라이스를 구성합니다. n개의 항목 각각은 다음 중 하나입니다. validator 공개 키 또는 재귀적으로 다른 쿼럼 세트. 유연하고 컴팩트하면서도 중첩된 쿼럼을 실현했습니다. 노드 운영자에게 너무 많은 유연성과 너무 적은 지침을 동시에 제공하는 세트: 안전하지 않은 작성이 쉬웠습니다(또는 말도 안되는) 구성. 그룹화 기준 하위 집합을 계층 구조로 구성하기 위해 노드를 집합으로 구성 임계값 선택에 대한 모든 사항이 명확하지 않아 운영 실패의 원인이 되었습니다. 할지 여부가 명확하지 않았습니다. 중첩 집합 계층 구조의 "수준"을 신뢰 수준으로 처리합니다. 또는 조직, 또는 둘 다; 현장의 다양한 구성 위험을 지정하는 것 외에도 이러한 개념을 혼합 또는 의미 없는 임계값. 따라서 우리는 더 간단한 구성 메커니즘을 추가했습니다. 중첩된 쿼럼 집합의 두 가지 측면을 구분하는 것: 그룹화 조직별로 노드를 함께 연결하고 각 조직에 간단한 신뢰 분류(낮음, 중간, 높음 또는 중요). 높은 수준 이상의 조직은 다음을 수행해야 합니다. 역사 기록 보관소를 출판합니다. 새로운 시스템은 각 조직이 다음과 같이 표현되는 중첩된 쿼럼 집합을 통합합니다. 51% 임계값이 설정되고 조직이 세트로 그룹화됩니다. 67% 또는 100% 임계값(그룹 품질에 따라 다름) 각 그룹은 다음(더 높은 품질) 그룹의 단일 항목입니다. 그림 6에 나와 있습니다. 이 단순화된 모델은 구조 측면에서 잘못된 구성 가능성 합성된 중첩 세트와 선택한 임계값 각 세트. 6.2 잘못된 구성을 사전에 감지 둘째, 우리는 부정적인 영향을 관찰하기 위해 기다려서 집합적인 구성 오류를 탐지하는 것은 너무 늦었다는 것을 깨달았습니다. 특히 분기될 수 있는 잘못된 구성과 관련하여 정지보다 더 심각한 장애 모드 - 네트워크 요구 사항 잘못된 구성을 즉시 감지하여 운영자가 실제로 차이가 발생하기 전에 되돌릴 수 있도록 하는 것입니다. 이러한 요구를 해결하기 위해 우리는 노드의 전이적 폐쇄에 있는 모든 피어의 집합적 구성 상태를 지속적으로 수집하고 발산 가능성(예: 분리)을 감지하는 메커니즘을 validator 소프트웨어에 구축했습니다. 쿼럼 - 해당 집단 구성 내에서. 6.2.1 쿼럼 교차 확인 중 쿼럼 조각을 수집하는 것은 쉽지만, 그들 사이에서 연결되지 않은 쿼럼을 찾는 것은 공동 NP가 어렵습니다([62]). 그러나 우리는 채택했습니다. 일련의 알고리즘 휴리스틱 및 사례 제거 규칙 일반적인 사례를 확인하는 Lachowski [62]이 제안한 것 문제보다 몇 배 더 빠르게 문제를 해결합니다. 최악의 비용. 실제로 현재 네트워크의 쿼럼 슬라이스 전이적 폐쇄는 20~30개 정도입니다. 노드를 사용하고 Lachowski의 최적화를 통해 일반적으로 확인합니다. 단일 CPU에서 몇 초 만에 가능합니다. 필요한 경우 성능을 향상시키기 위해 검색을 병렬화할 수 있습니다. 6.2.2 위험한 구성 확인 네트워크가 분리된 쿼럼을 허용하는지 감지하는 것이 한 단계입니다. 올바른 방향으로 가고 있지만 불편할 정도로 늦게 위험을 알립니다. 그런 중요한 문제에 대해. 이상적으로는 네트워크의 집합적 구성이 발생할 때 노드 운영자가 경고를 받기를 원합니다. 위험한 상태에 가까워지고 있을 뿐입니다. 따라서 우리는 쿼럼 교차 검사기를 확장했습니다. 임계성(Criticality)이라고 부르는 조건을 감지하려면: 현재 집합적 구성은 하나의 잘못된 구성입니다. 분리된 정족수를 인정하는 주. 중요도를 탐지하려면, 검사기는 각 조직의 구성을 시뮬레이션된 최악의 구성 오류로 반복적으로 대체합니다. 결과에 대해 내부 쿼럼 교차 검사기를 다시 실행합니다. 그러한 중대한 구성 오류가 한 단계 더 진행된 경우 현재 상태에서 소프트웨어는 경고를 발행하고 잘못된 구성 위험이 있는 조직을 보고합니다. 이러한 변화는 운영자 커뮤니티에 두 가지 계층을 제공합니다. 최악의 형태로부터 보호하기 위한 통지 및 지침 집단적 구성 오류.

การประเมิน

เพื่อทำความเข้าใจความเหมาะสมของ 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

평가

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

Stellar의 글로벌 결제로서의 적합성을 이해하고 거래 네트워크, 우리는 공용 네트워크의 상태를 평가했습니다. 개인 실험에 대해 통제된 실험을 실행했습니다. 네트워크. 우리는 다음 질문에 중점을 두었습니다. • 프로덕션 네트워크 토폴로지는 어떤 모습입니까? 평균적으로 얼마나 많은 메시지가 방송되는지, 그리고 SCP는 어떻게 시간 초과를 경험합니까? • 합의 및 원장 업데이트 지연 시간이 계정 수와 독립적으로 유지됩니까?SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 Lokhavaet al. • (a) 초당 트랜잭션 증가(결과적으로 초당 트랜잭션 증가)가 지연 시간에 어떤 영향을 미칩니까? 원장) 및 (b) validator 노드 수는 무엇입니까? • CPU 측면에서 노드를 실행하는 데 드는 비용은 얼마입니까? 메모리 및 네트워크 대역폭? 결제 네트워크에 비해 거래율이 낮습니다. 다른 유형의 분산 시스템에 적용됩니다. 주요 blockchain, Bitcoin 및 Ethereum, 초당 최대 15개의 트랜잭션을 확인합니다. Stellar 미만. 게다가 이러한 시스템은 작업 증명을 위해서는 여러 블록이 채굴될 때까지 기다려야 하기 때문에 거래를 안전하게 확인하는 데 한 시간이 걸립니다. 는 non-blockchain SWIFT 네트워크는 최대 피크일인 [14]에 초당 평균 420건의 트랜잭션만 처리했습니다. 그러므로 우리는 선택했습니다 측정값을 5초 목표와 비교하기 위해 원장 간격, 더 공격적인 목표입니다. 우리의 결과는 다음과 같습니다 대기 시간은 다음과 같은 경우에도 이 한도보다 훨씬 낮습니다. 아직 구현되지 않은 몇 가지 최적화가 파이프라인에 있습니다. 7.1 앵커 거래량 기준으로 가장 많이 거래되는 자산에는 통화가 포함됩니다(예: 3 USD 앵커, 2 CNY), Bitcoin 앵커, 부동산 담보 증권 token [92] 및 인앱 통화 [8]. 앵커마다 정책이 다릅니다. 예를 들어 USD 앵커 하나는 Stronghold는 auth_reqired를 설정하고 보유하고 있는 모든 계정에 대해 고객 파악(KYC) 프로세스를 요구합니다. 자산. 또 다른 AnchorUSD, 누구나 받고 거래하자 USD(문자 그대로 $0.50를 멕시코로 보내는 것이 가능함) $0.000001의 수수료로 5초 안에 완료됩니다. 그러나 AnchorUSD는 USD를 구매하거나 상환하려면 KYC 및 수수료가 필요합니다. 기존 송금 방식으로. 필리핀에서는 입금에 대한 은행 규정이 완화되었습니다, coin.ph 모든 ATM 기계 [36]에서 PHP 현금화를 지원합니다. 앞서 언급한 보안 token 및 인앱 통화 외에도 다음과 같은 다양한 비통화 token이 있습니다. 상업 채권 [22] 및 탄소 배출권 [85, 96] 더보기 token 협업을 장려하는 난해한 자산 자동차 압수 [35]. 7.2 공용 네트워크 이 글을 쓰는 시점에서 126개의 활성 풀 노드가 있으며 그 중 66개는 투표 메시지에 서명하여 합의에 참여합니다. 그림 7 ([5]에 의해 생성됨)은 사이에 선을 사용하여 네트워크를 시각화합니다. 하나가 다른 노드의 쿼럼 조각에 나타나는 경우 두 개의 노드 진한 파란색 선은 양방향 의존성을 나타냅니다. 에서 센터는 17개의 사실상 "계층 1 validators"로 구성된 클러스터입니다. SDF, SatoshiPay, LOBSTR, COINQVEST 및 Keybase. 4개월 전, 섹션 6의 사건이 일어나기 전, 시스템적으로 중요한 노드는 15개였습니다. 겉보기에는 3개였습니다. Tier 1 조직과 여러 개의 무작위 싱글톤. 는 그래프도 훨씬 덜 규칙적으로 보였습니다. 따라서 새로운 구성 메커니즘 및/또는 더 나은 운영자 결정이 필요한 것 같습니다. 더 건강한 네트워크 토폴로지에 기여합니다. 없이 훌륭한 재정 자원(및 해당 주주) 그림 7. 쿼럼 슬라이스 맵 의무), 5급 1인 채용은 어려웠을 것 그러나 처음부터 조직. 이는 정족수를 제안합니다. 슬라이스는 네트워크 부트스트래핑에서 유용한 역할을 합니다. 누구나 할 수 있습니다. 중요한 플레이어가 되겠다는 목표를 가지고 참여하세요. 쌍으로 합의할 수 있는 문지기가 없습니다. 현재 원장에는 330만 개 이상의 계정이 있습니다. 오버 최근 24시간 동안 Stellar은 평균 4.5건의 거래를 기록했으며 초당 15.7 작업. 최근 원장을 검토하면 대부분 트랜잭션은 단일 작업을 수행하는 것처럼 보이지만 몇 번의 작업마다 원장에는 다음과 같은 많은 작업이 포함된 트랜잭션이 표시됩니다. 제안을 관리하는 시장 조성자로부터 오는 것으로 보입니다. 는 합의를 달성하고 원장을 업데이트하는 데 걸리는 시간은 다음과 같습니다. 각각 1061ms와 46ms입니다. 99번째 백분위수는 2252ms 및 142ms(전자는 1초 시간 초과를 반영함) 지명 지도자 선정에서). 참고 SCP의 성능은 SCP 이후 대부분 초당 트랜잭션과 독립적입니다. 임의의 많은 거래 중 hash에 동의합니다. 병목 현상은 후보 전파로 인해 발생할 가능성이 더 높습니다. 지명, 실행 및 검증 중 거래 트랜잭션 및 버킷 병합. 우리는 아직 필요하지 않았습니다 여러 CPU 코어 또는 디스크 드라이브를 통해 stellar-core의 트랜잭션 처리를 병렬화합니다. 우리는 또한 방송된 SCP 메시지의 수를 평가했습니다. 생산 네트워크에서. 일반적인 경우에는 단일 리더가 가치를 지명하기 위해 선출되면 우리는 7가지 논리적인 가치를 기대합니다. 브로드캐스트할 메시지: 투표하고 수락할 메시지 2개 노미nate 성명, 수락 및 확인을 위한 두 개의 메시지 준비문, 승인 및 확인을 위한 두 개의 메시지 커밋 문, 마지막으로 외부화 메시지 (낙오자를 돕기 위해 새 원장을 디스크에 커밋한 후 전송됨) 따라잡으세요). 구현은 커밋 확인을 결합합니다. 메시지를 최적화로 외부화합니다. 커밋된 후에 값을 외부화하는 것이 안전합니다. 그런 다음 프로덕션 Stellar validator에서 수집된 측정항목을 분석합니다. 오버 68시간 동안 초당 1.3개의 메시지가 방출되었습니다. 원장당 평균 6-7개의 메시지. 우리는 총

Stellar을 통한 빠르고 안전한 글로벌 결제 SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 백분위수 시간 초과 횟수 지명 투표 75% 0 0 99% 1 0 맥스 4 1 그림 8. 68시간이 넘는 원장당 시간 초과 validators가 브로드캐스트한 메시지 수가 더 많습니다. 연합 투표 메시지 외에도 노드도 브로드캐스트합니다. 그들이 배우는 모든 거래. 그림 8은 프로덕션에서 발생한 시간 초과를 보여줍니다. validator 68시간 동안. 추천 시간 제한은 다음과 같습니다. 리더 선출 기능의 효율성(비)을 측정하는 반면, 투표 시간 초과는 네트워크에 크게 의존합니다. 잠재적인 메시지 지연. 시간 초과가 일관되게 발생합니다. 방출된 메시지 수: 최선의 시나리오, 추가 지명 라운드가 필요한 경우 최소 7개의 메시지. 7.3 통제된 실험 우리는 포장된 용기에서 통제된 실험을 실시했습니다. 72GiB RAM을 갖춘 Amazon EC2 c5d.9xlarge 인스턴스, 900GB의 NVMe SSD 및 36개의 vCPU. 각 인스턴스는 동일한 EC2 지역이고 고정 대역폭이 10Gbps였습니다. 우리는 SQLite를 저장소로 사용했습니다. (Stellar은 PostgreSQL도 지원합니다. 하지만 측정에 노이즈를 주입하는 비동기 작업이 있습니다.) Stellar은 내장된 런타임 쿼리, 생성 로드, 특정 대상에서 합성 부하를 생성할 수 있는 기능 거래/두 번째 요율. Stellar은 다양한 기능을 지원하지만 주문장 및 자산 간 경로와 같은 거래 기능 결제 방식으로는 간편결제에 중점을 두었습니다. 거래 확인은 여러 단계로 구성되어 있으므로 다음 각각에 대한 측정값을 기록했습니다. • 추천: 추천부터 첫 준비까지의 시간 • 투표: 처음 준비부터 확인까지의 시간 투표용지가 확정됨 • 원장 업데이트: 합의 가치를 적용하는 시간 • 거래수: 원장별 확인된 거래 각 실험은 세 가지 매개변수로 정의되었습니다. 원장의 계정 항목 수, 금액 초당 제출된 로드(XLM 결제 형식), 그리고 validator의 수. 우리는 validator마다 구성했습니다. 다른 모든 validator에 대해 알고 싶습니다(최악의 시나리오) SCP의 경우) 쿼럼 슬라이스는 단순 과반수로 설정됩니다. 노드(다양한 쿼럼 수를 최대화하기 위해). 기준선 기본 실험에서는 Stellar을(를) 측정했습니다. 100,000개의 계정, 4개의 validator 및 로드 생성 초당 100건의 트랜잭션 속도. 우리는 원장당 평균 507건의 거래를 관찰했으며 표준편차는 49입니다. (9.7%). 삭제된 트랜잭션은 없습니다. 경미한 105 106 107 0 500 1,000 1,500 2,000 계정 지연 시간 [ms] 원장 업데이트 투표 지명 그림 9. 계정 수 증가에 따른 지연 시간 변동은 부하 생성기의 일정 제한으로 인해 발생합니다. 우리는 원장당 거래 수를 관찰했습니다. 원장을 고려하면 로드 생성 속도와 일치했습니다. 5초마다 닫힙니다. 지명, 투표 및 장부 업데이트에서는 평균 대기 시간이 82.53ms, 95.96ms로 나타났습니다. 각각 174.08ms입니다. 우리는 지명 지연 시간을 관찰했습니다. 99번째 백분위수는 지속적으로 61ms 미만입니다. 첫 번째 단계에 해당하는 약 1초의 스파이크 리더 선택의 타임아웃 기능. 기본 성능을 고려하여 효과를 살펴보았습니다. 각 테스트 설정 매개변수를 변경하는 것입니다. 계정 그림 9의 데이터는 Stellar이 확장됨을 시사합니다. 그리고 계정수도 늘어납니다. 테스트 생성 버킷 생성 및 병합으로 인해 단순히 데이터베이스를 채우는 것이 불가능해졌습니다. SQL을 통해 직접 계정을 사용합니다. 따라서 우리는 최대 50,000,000개의 계정에 대한 실험을 수행할 수 있습니다. 있는 동안 합의 및 원장 업데이트 지연 시간에 미치는 영향을 최소화합니다. 계정을 늘리면 다음과 같은 오버헤드가 발생합니다. 버킷을 병합하면 더 커집니다. 거래율 거래율은 금액에 영향을 미칩니다. validator 간의 트래픽 멀티캐스트, 각 원장에 포함된 트랜잭션 수, 최상위 수준의 크기 버킷. 거래 증가의 효과를 이해하려면 로드 후 100,000개의 계정과 4개의 validator을 사용하여 실험을 실행했습니다. 그림 10은 합의 지연 시간의 느린 증가를 보여줍니다. 대부분의 시간은 원장을 업데이트하는 데 소비되었습니다. 당연히 트랜잭션 세트의 크기가 증가함에 따라 데이터베이스에 커밋하는 데 시간이 더 걸립니다. 우리는 또한 원장 업데이트 지연 시간은 구현에 따라 크게 달라집니다. 데이터베이스 선택에 영향을 받습니다. 검증인 노드 Tierone validators의 수가 어떻게 증가하는지 확인하려면성능에 영향을 미치므로 실험을 진행했습니다. 100,000개의 계정, 100개의 트랜잭션/초 및 4에서 43까지 다양한 수의 validator이 있습니다. 모든 validator이 나타났습니다. 모든 validators의 쿼럼 슬라이스에서; 더 작은 쿼럼 슬라이스는 성능에 미치는 영향이 적습니다.SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌 Lokhavaet al. 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이 5초 목표를 달성하는지 여부를 측정하여 Stellar의 엔드투엔드 성능을 측정하고 싶었습니다. 모든 거래를 삭제합니다. 우리는 평균 원장 마감을 관찰했습니다. 계정을 늘리면 5.03초, 5.10초, 5.15초가 됩니다. 각각 항목, 트랜잭션 속도 및 노드 수입니다. 결과는 Stellar이 지속적으로 원장을 마감할 수 있음을 시사합니다. 높은 부하에서. 7.4 validator 실행 Stellar의 중요한 특징 중 하나는 저렴한 비용입니다. 앵커가 실행(또는 계약)되어야 하므로 validator을 실행합니다. validators를 사용하여 최종성을 강화합니다. SDF는 2개의 코어가 있는 c5.large AWS 인스턴스에서 3개의 프로덕션 validator을 실행합니다. 4GiB RAM 및 Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz 프로세서. 하나의 리소스 사용량 검사 이 기계 중 우리는 다음을 사용하여 Stellar 프로세스를 관찰했습니다. CPU는 약 7%, 메모리는 300MiB입니다. 네트워크 트래픽 측면에서 피어에 대한 연결이 28개이고 쿼럼 크기가 있습니다. 34개 중 수신 및 발신 속도는 2.78Mbit/s였으며 각각 2.56Mbit/s입니다. 이러한 실행에 필요한 하드웨어 프로세스가 저렴합니다. 우리의 경우 비용은 $0.054/시간입니다. 또는 월 $40 정도입니다. 7.5 미래의 일 이러한 실험은 Stellar이 쉽게 1~2개 주문을 확장할 수 있음을 시사합니다. 오늘날의 네트워크 사용량을 넘어서는 규모입니다. 왜냐하면 현재까지 성능 요구 사항은 너무 적었습니다. Stellar 다음을 사용하여 많은 간단한 최적화를 위한 여지를 남겨둡니다. 잘 알려진 기술. 예를 들어 트랜잭션과 SCP 메시지는 순진한 플러딩을 사용하여 validators에 의해 방송됩니다. 하지만 이상적으로는 보다 효율적이고 구조화된 프로토콜을 사용해야 합니다. 피어 투 피어 멀티캐스트 [30]. 또한, 데이터베이스가 많이 사용되는 원장 업데이트 시간은 표준 일괄 처리 및 프리페치 기술을 통해 향상될 수 있습니다.

บทสรุป

การชำระเงินระหว่างประเทศมีราคาแพงและใช้เวลาหลายวัน กองทุน การดูแลผ่านสถาบันการเงินหลายแห่ง รวมถึงธนาคารตัวแทนและบริการโอนเงิน เนื่องจากแต่ละฮอปจะต้องได้รับความไว้วางใจอย่างเต็มที่ จึงเป็นเรื่องยากสำหรับฮอปใหม่ ผู้เข้าร่วมเพื่อเพิ่มส่วนแบ่งการตลาดและแข่งขัน 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, แคนาดา

결론

국제 결제는 비용이 많이 들고 며칠이 걸립니다. 기금 보관은 환은행 및 송금 서비스를 포함한 여러 금융 기관을 통해 이루어집니다. 각 홉은 완전히 신뢰되어야 하기 때문에 새로운 홉은 어렵습니다. 시장점유율을 확보하고 경쟁하기 위한 진입자. Stellar 쇼 단 몇 초 만에 전 세계로 저렴하게 송금하는 방법. 는 핵심 혁신은 P2P 구조를 활용하는 새로운 개방형 멤버십 비잔틴 계약 프로토콜인 SCP입니다. 금융 네트워크의 글로벌 합의를 달성하기 위해 새로운 인터넷 가설. SCP는 Stellar을 원자적으로 커밋하도록 허용합니다. 임의 참가자 간의 되돌릴 수 없는 거래 서로에 대해 모르거나 신뢰하지 않습니다. 이는 결과적으로 신규 진입자가 기존 시장과 동일한 시장에 접근할 수 있도록 보장합니다. 플레이어는 최상의 교환을 안전하게 받을 수 있습니다. 신뢰할 수 없는 시장 조성자로부터도 가격이 하락하고 극적으로 결제 지연 시간을 줄입니다. 감사의 말 Stellar는 이른 시간이 없었다면 지금의 모습은 없었을 것입니다. 조이스 김의 리더십이나 Scott Fleckenstein과 Bartek Nowotarski가 건물을 짓고 지평선 유지, Stellar SDK 및 기타 핵심 부분 Stellar 생태계의. Kolten Bergeron에게도 감사드립니다. 헨리 코리건-깁스, 캔디스 켈리, 카필 K. 제인, 보리스 레즈니코프, 제레미 루빈, 크리스티안 러더, 에릭 손더스, Torsten Stüber, Tomer Weller, 익명의 심사위원, 그리고 우리 목자 저스틴 셰리(Justine Sherry)가 도움이 되는 의견을 주었습니다. 이전 초안. 면책조항 이 출판물에 대한 Mazières 교수의 기여는 유급 컨설턴트로서 이루어졌으며 그의 일부는 아닙니다. 스탠포드 대학의 의무 또는 책임.

Stellar를 통한 빠르고 안전한 글로벌 결제 SOSP ’19, 2019년 10월 27~30일, 캐나다 온타리오주 헌츠빌