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

บทคัดย่อ

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

การแนะนำ

การชำระเงินระหว่างประเทศช้ามากและมีค่าใช้จ่ายสูง [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 สิ้นสุดลง

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

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

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

โหวต 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) แทน

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

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

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

การประเมิน

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