เสียงบี๊บ, เสียงบี๊บ, เสียงบี๊บ เสียงบี๊บ, เสียงบี๊บ, เสียงบี๊บ

การนอนหลับของสตีเวนพังทลายลงด้วยเสียงกระดิ่งที่รุนแรงของโทรศัพท์ของเขาลากเขาออกจากความฝันอย่างกะทันหัน ในที่มืดหน้าจอเรืองแสงสดใสสั่นสะเทือนอย่างโกรธเกรี้ยวบนโต๊ะข้างเตียงของเขา เสียงบี๊บ, เสียงบี๊บ, เสียงบี๊บ เขาคร่ําครวญขยี้ตาอย่างเกรี้ยวกราดและเอื้อมมือไปหาอุปกรณ์ เหล่มองข้อความหัวใจของเขาจมลง—โหนดลง โดยไม่ลังเลเขาลุกขึ้นจากเตียงแต่งตัวครึ่งตัวคลําเพื่อปลดล็อกโทรศัพท์ของเขาเมื่อมีข้อความหลั่งไหลเข้ามามากขึ้น จากนั้นก็กระทบเขา—คลัสเตอร์ทั้งหมดก็ล่ม

ในขณะนี้ที่แน่นอนทั่วโลก ในเมืองที่กระจายและเขตเวลาต่าง ๆ มีพันธุ์ไมโครจักรกำลังมองหาโทรศัพท์ของพวกเขาด้วยความรู้สึกเดียวกัน: ช่วงเวลาที่พวกเขากลัวได้มาถึงแล้ว - การขาดการเชื่อมต่อ

บทนำ

เช่นเดียวกับระบบกระจายทั้งหมด Solana ทํางานภายใต้ความเป็นจริงว่าข้อบกพร่องในการใช้งานเพียงครั้งเดียวหรือกรณีขอบที่คลุมเครือสามารถนําไปสู่ความล้มเหลวทั่วทั้งเครือข่าย การหยุดทํางานในขณะที่ก่อกวนเป็นส่วนที่หลีกเลี่ยงไม่ได้ในการรักษาโครงสร้างพื้นฐานแบบกระจายที่ซับซ้อนไม่ว่าจะเป็นบล็อกเชนแบบกระจายอํานาจการแลกเปลี่ยนแบบรวมศูนย์หรือแม้แต่ผู้ให้บริการคลาวด์รายใหญ่เช่น Amazon หรือ Microsoft

คําถามไม่ใช่ว่าความล้มเหลวจะเกิดขึ้นเมื่อใด แต่เมื่อใดและเครือข่ายมีวิวัฒนาการอย่างไรเพื่อปรับตัวและแข็งตัวจากเหตุการณ์ในอนาคต แม้จะมีการทดสอบจําลองอย่างเข้มงวด testnet ที่จูงใจและโปรแกรม Bug Bounty ที่ใช้งานอยู่ แต่ไม่มีระบบใดที่ออกแบบมาอย่างดีก็สามารถคาดการณ์โหมดความล้มเหลวที่เป็นไปได้ทุกโหมดได้ บทเรียนที่มีค่าที่สุดมาจากการดําเนินงานในโลกแห่งความเป็นจริง

ในช่วงห้าปีที่ผ่านมา Solana ประสบกับเหตุการณ์ไฟดับเจ็ดครั้งซึ่งห้าเหตุการณ์เกิดจากข้อบกพร่องของลูกค้าและอีกสองเหตุการณ์เกิดจากการที่เครือข่ายไม่สามารถจัดการกับสแปมธุรกรรมได้ Solana เวอร์ชันแรกๆ ขาดกลไกการจัดการความแออัดที่สําคัญ เช่น ค่าธรรมเนียมลําดับความสําคัญและตลาดค่าธรรมเนียมท้องถิ่น ซึ่งต่อมาได้พิสูจน์แล้วว่าจําเป็นในการบรรเทาความเครียดของเครือข่าย การขาดกลไกดังกล่าวทําให้ประสิทธิภาพและความแออัดลดลงเป็นเวลานานตลอดปี 2022 เนื่องจากเครือข่ายจูงใจให้เกิดสแปมเป็นหลัก

ประวัติศาสตร์ของปัญหาด้านการเชื่อมต่อและประสิทธิภาพที่ลดลงของ Solana

บทความนี้จะวิเคราะห์ข้อบกพร่องของ Solana แต่ละรายการอย่างละเอียด โดยพิจารณาสาเหตุหลัก เหตุการณ์ที่เป็นตัวกระตุ้น และมาตรการที่นำมาใช้เพื่อแก้ไขปัญหา นอกจากนี้เราจะอธิบายด้านสำคัญของการเริ่มต้นเครือข่าย การรายงานข้อบกพร่อง และแนวคิดพื้นฐานของความสามารถในการดำเนินงานและความเสี่ยงที่เกิดขึ้น แม้ว่าส่วนเหล่านี้ถูกออกแบบให้อ่านเป็นลำดับ แต่แต่ละส่วนถูกออกแบบให้สามารถทำงานอิสระ ทำให้ผู้อ่านสามารถกระโดดไปยังหัวข้อหรือเหตุการณ์ขอบกพร่องที่ทำให้สนใจมากที่สุด

ความมีชีวิตชีวาและความปลอดภัย

ตามทฤษฎี CAP หรือที่เรียกว่า ทฤษฎีของ Brewer ระบบกระจายสามารถบรรลุคุณสมบัติสองประการจากสามประการ

• ความมั่นคง - การอ่านทุกครั้งเห็นการเขียนก่อนหน้าทั้งหมด
• ความพร้อมใช้บริการ - ทุกคำขอจะได้รับการตอบกลับ
• ความทนทานต่อการแบ่งส่วน - ระบบยังดำเนินการต่อไป หลังจากมีการแบ่งส่วนของเครือข่าย

สําหรับบล็อกเชน ความทนทานต่อพาร์ติชันเป็นสิ่งสําคัญ—การหยุดชะงักของเครือข่ายเป็นสิ่งที่หลีกเลี่ยงไม่ได้ สิ่งนี้บังคับให้มีทางเลือกระหว่าง AP (ความพร้อมใช้งาน + ความอดทนของพาร์ติชัน) และ CP (ความสอดคล้อง + ความอดทนของพาร์ติชัน) เช่นเดียวกับเครือข่าย PoS ที่จบเร็วส่วนใหญ่ Solana ให้ความสําคัญกับความสม่ําเสมอมากกว่าความพร้อมใช้งานทําให้เป็นระบบ CP มันหยุดในช่วงความล้มเหลวที่สําคัญแทนที่จะให้บริการข้อมูลเก่าหรืออนุญาตให้เขียนที่ไม่ปลอดภัย แม้ว่านี่จะหมายความว่าซอฟต์แวร์โหนดอาจเข้าสู่สถานะที่ไม่สามารถกู้คืนได้ซึ่งต้องการการแทรกแซงด้วยตนเอง แต่ก็ช่วยให้มั่นใจได้ว่าเงินทุนของผู้ใช้จะยังคงปลอดภัย

ตำแหน่งของ Solana ภายในการค้า off theorem CAP

การล้มเหลวในการเป็นประจำ: เกิดขึ้นเมื่อบล็อกเชนหยุดก้าวหน้า ทำให้ธุรกรรมไม่สามารถยืนยันได้ และบล็อกไม่สามารถถูกสร้างเนื่องจากความไม่พร้อมของ validator, การแบ่งเน็ตเวิร์ค, หรือการหยุดของความเห็นร่วม ในบริบทของทฤษฎี CAP นี้มีความสัมพันธ์กับการสูญเสียความพร้อมใช้งาน

ความเสี่ยงในด้านความปลอดภัย: เกิดขึ้นเมื่อสถานะที่ได้รับการ finalize ของบล็อกเชนถูกเปลี่ยนแปลงหรือ fork อย่างไม่ถูกต้อง สาเหตุที่อาจทำให้เกิดประวัติที่ขัดแย้งหรือการใช้จ่ายเงินซ้ำ ๆ โดยทั่วไปเกิดจากบั๊กของ consensus หรือการโจมตีอย่างไม่ดี ในบริบทของทฤษฎี CAP นี้ จะสอดคล้องกับการสูญเสียความสอดคล้อง

Solana มีความสำคัญกับความปลอดภัยมากกว่าความสามารถในการทำงานอยู่ตลอดเวลา ดังนั้น เครือข่ายจะหยุดทำงานในกรณีที่มีการกดดันจากเครือข่ายหรือความล้มเหลวในการเชื่อมั่นเชิงรัฐบาล เช่นเดียวกับการเสียหายจากการขาดการเชื่อมต่อที่กระทบต่อแอปพลิเคชันผู้ใช้ และผู้ตรวจสอบ ยังคงเป็นสิ่งที่เลือกติดต่อกับผลที่เลวร้ายจากการมีปัญหาเกี่ยวกับข้อมูลหรือกระดาษงบบกพร่อง

เครือข่ายเริ่มทำงานใหม่

การรีสตาร์ทเครือข่าย Solana เกี่ยวข้องกับการระบุสล็อตบล็อกที่ได้รับการยืนยันในแง่ดีล่าสุดและการรีบูตโหนดจากสแนปช็อตสถานะท้องถิ่นที่เชื่อถือได้ของสล็อตนั้น เนื่องจากสล็อตรีสตาร์ทไม่ได้ถูกกําหนดแบบ on-chain ผู้ดําเนินการตรวจสอบความถูกต้องจึงต้องบรรลุฉันทามตินอกเครือข่ายเพื่อตกลงในจุดย้อนกลับที่ปลอดภัย การประสานงานนี้เกิดขึ้นอย่างเปิดเผยในช่อง #mb-validators บน Solana Tech Discord ซึ่งผู้ดําเนินการตรวจสอบมืออาชีพสื่อสารแบบเรียลไทม์ ผู้ปฏิบัติงานส่วนใหญ่มีระบบแจ้งเตือนอัตโนมัติที่แจ้งเตือนพวกเขาทันทีที่หยุดการผลิตเพื่อให้แน่ใจว่ามีการตอบสนองที่รวดเร็ว

เมื่อบรรลุฉันทามติในช่องรีสตาร์ทที่ถูกต้องโอเปอเรเตอร์จะใช้เครื่องมือบัญชีแยกประเภทเพื่อสร้างสแนปช็อตภายในเครื่องใหม่รีบูตผู้ตรวจสอบความถูกต้องและรออย่างน้อย 80% ของเงินเดิมพันทั้งหมดเพื่อกลับมาออนไลน์ จากนั้นเครือข่ายจะกลับมาบล็อกการผลิตและการตรวจสอบความถูกต้อง การตรวจสอบว่ามีการเดิมพันออฟไลน์มากที่สุด 20% เมื่อคลัสเตอร์รีสตาร์ทช่วยให้มั่นใจได้ถึงความปลอดภัยเพียงพอที่จะออนไลน์ในกรณีที่โหนดแยกหรือกลับไปออฟไลน์ทันทีหลังจากรีสตาร์ท

รายงานปัญหา

โปรแกรม Bug bounty ให้รางวัลแก่นักวิจัยด้านความปลอดภัยที่ค้นพบและรายงานช่องโหว่ของซอฟต์แวร์ นี่เป็นเส้นป้องกันที่สำคัญเนื่องจากมันสร้างสติ๊มูลัสให้ล่วงหน้าการจับบั๊กก่อนที่จะถูกใช้เอาประโยชน์. นักวิจัยและนักพัฒนาด้านความปลอดภัยที่ระบุช่องโหว่ที่อาจเกิดขึ้นในไคลเอนต์ Agave ควรรายงานผ่านช่องทางการรักษาความปลอดภัยที่เหมาะสม แนวทางการเปิดเผยข้อมูลโดยละเอียดสามารถพบได้ในที่เก็บ Agave GitHub.

มีการเสนอรางวัลสำหรับรายงานช่องโหว่ที่สำคัญที่ถูกต้อง โดยมีการจ่ายเงินตามความรุนแรง:

• การสูญเสียเงินทุน: สูงถึง 25,000 SOL
• การล้มละลายหรือการละเมิดความปลอดภัย: สูงสุด 12,500 SOL
• ความมีชีวิตหรือสูญเสียความพร้อมใช้: สูงสุด 5,000 SOL

นอกจากนี้ ไคลเอนต์ FireDancer มีโปรแกรม Bug Bounty แยกต่างหาก โฮสต์ผ่าน Immunefi โดยเสนอรางวัลสูงสุด $ 500,000 USDC สําหรับการค้นพบที่สําคัญ

กรณีขัดข้อง

ส่วนต่อไปนี้ให้การวิเคราะห์โดยละเอียดตามลําดับเวลาของการหยุดทํางานของ Solana และช่วงเวลาของประสิทธิภาพที่ลดลงโดยเริ่มจากการเปิดตัว Mainnet Beta เมื่อวันที่ 16 มีนาคม 2020 การตรวจสอบนี้จะเน้นเหตุการณ์สําคัญสาเหตุที่แท้จริงและการปรับปรุงที่ตามมาของเครือข่ายโดยให้ข้อมูลเชิงลึกว่า Solana มีวิวัฒนาการอย่างไรเพื่อเพิ่มเสถียรภาพและความยืดหยุ่นเมื่อเวลาผ่านไป

Turbine Bug: ธันวาคม 2020

เวลาหยุดทํางาน: ประมาณหกชั่วโมง

ปัญหาหลัก: บั๊กการ传播บล็อก

Fixes:

• ติดตามบล็อกโดยแฮชแทนหมายเลขสล็อต
• แก้ไขสถานที่ในกังหันที่การตรวจจับข้อผิดพลาดสามารถทําได้ก่อนหน้านี้
• ส่งต่อข้อบกพร่องที่ตรวจพบครั้งแรกไปยังผู้ตรวจสอบทั้งหมดผ่านการกระจายข่าว

ไฟดับนี้เกิดจาก ปัญหาการซ่อมแซมบล็อกที่รู้จักก่อนหน้านี้และปัญหาการประมวลผลโค้ดเกิดจากบั๊กที่ไม่ระบุชื่อในกลไกการขยายบล็อกของ Solana. ความล้มเหลวเกิดขึ้นเมื่อผู้ตรวจสอบส่งสองบล็อกที่แตกต่างกันสำหรับช่องเดียวกันและแพร่กระจายเข้าสู่พาร์ติชันสองส่วน (A และ B) ในขณะที่พาร์ทิชันที่สามตรวจพบความไม่สอดคล้องอย่างอิสระ

เนื่องจากแต่ละพาร์ทิชันถือหุ้นเพียงส่วนน้อยจึงไม่มีใครสามารถบรรลุฉันทามติสุดยอดเพื่อพัฒนาห่วงโซ่ได้ ปัญหาพื้นฐานเกิดจากวิธีที่โครงสร้างข้อมูลภายในของ Solana ติดตามบล็อกและสถานะการคํานวณ ระบบใช้หมายเลขสล็อต Proof of History (PoH) (ตัวระบุ u64) เพื่ออ้างอิงสถานะและบล็อกที่ช่องนั้น เมื่อเครือข่ายแยกออกเป็นพาร์ติชันโหนดจะตีความผิดบล็อก A และ B ว่าเหมือนกันป้องกันการซ่อมแซมที่เหมาะสมและการซิงโครไนซ์บล็อก

ทุกพาร์ติชันถือว่าอีกฝ่ายมีบล็อกเดียวกัน ทำให้เกิดความขัดแย้งพื้นฐาน:

• โหนดที่ถือบล็อก A ปฏิเสธการแขวนลอยที่มาจากบล็อก B
• โหนดที่ถือบล็อก B ปฏิเสธการแยก Fork ที่ได้มาจากบล็อก A

เนื่องจากการเปลี่ยนแปลงของสถานะแตกต่างกันระหว่างพาร์ติชันทำให้ผู้ตรวจสอบไม่สามารถซ่อมแซมหรือปรับปรุงการแยกชั้นที่มีอยู่ ซึ่งจะป้องกันความสมบูรณ์

การแก้ไขปัญหานี้คืออนุญาตให้บริการติดตามบล็อกโดยใช้แฮชแทนหมายเลขสล็อตถ้ามีจำนวนบล็อกสำหรับสล็อตเดียวกันที่สร้างพาร์ติชัน การจัดการกับมันจะไม่ต่างกันจากพาร์ติชันที่มีบล็อกที่ครอบครองสล็อตที่แตกต่างกัน โหนดจะสามารถซ่อมแซมฟอร์กที่เป็นไปได้ทั้งหมด และความเห็นร่วมสามารถแก้ไขพาร์ติชันได้

หมื่นข้อผิดพลาดเป็นสาเหตุเริ่มแรกของการตัดการใช้งาน แต่ส่วนใหญ่ของเวลาที่ใช้งานไม่ได้เกิดจากการรอนับพอดีนักเดิมพันเพียงพอที่จะกลับมาออนไลน์ เนื่องจาก Solana ต้องการอย่างน้อย 80% การมีส่วนร่วมนักเดิมพันเพื่อดำเนินการการผลิตบล็อกต่อ

The Grape Protocol IDO: กันยายน 2021

เวลาหยุดทำงาน: สิบเจ็ด ชั่วโมง

ปัญหาหลัก: การเกิดการใช้หน่วยความจำเกินจากธุรกรรมของบอท

การแก้ไข:

• ละเว้นการล็อกการเขียนบนโปรแกรม
• จำกัดอัตราการส่งข้อมูลการทำธุรกรรม
• พฤติกรรมการลองเรียกร้อง RPC ที่สามารถปรับแต่งได้
• การจัดลําดับความสําคัญของธุรกรรมการลงคะแนนเสียงของ TPU

เมื่อวันที่ 14 กันยายน พ.ศ. 2021 Solana ได้สัมผัสกับแผงเครือข่ายหลักหลังจาก Grape Protocol เปิดตัวข้อเสนอ DEX เริ่มต้นแบบ on-chain (IDO) บนแพลตฟอร์มคราวด์ฟันดิง Raydium AcceleRaytor ภายใน 12 นาทีของ IDO เครือข่ายถูกครอบงําโดยธุรกรรมที่ขับเคลื่อนด้วยบอทอย่างไม่เคยปรากฏมาก่อนและหยุดผลิตสล็อตที่ฝังราก บอทเหล่านี้ดําเนินการโจมตีแบบปฏิเสธการให้บริการแบบกระจาย (DDoS) ได้อย่างมีประสิทธิภาพผลักดันภาระธุรกรรมเกินความสามารถของเครือข่าย

ในช่วงการแออัดสูงสุด:

• บางคนที่ทำการตรวจสอบข้อมูลได้รับมากกว่า 300,000 รายการต่อวินาที
• ข้อมูลธุรกรรมดิบเกิน 1 Gbps พร้อมกับ 120,000 แพ็กเก็ตต่อวินาที
• บางครั้งการรับส่งข้อมูลเกินขีด จํากัด ทางกายภาพของอินเทอร์เฟซเครือข่ายทําให้แพ็กเก็ตสูญเสียที่พอร์ตสวิตช์ก่อนที่จะถึงผู้ตรวจสอบความถูกต้อง

Solana slots per second during the Grape IDO outage of September 14th, 2021 (แหล่งข้อมูล: Jump Crypto)

หนึ่งในบอทได้โครงสร้างการทำธุรกรรมของมันให้เขียนล็อก 18 บัญชีหลัก รวมถึงโปรแกรมโทเค็น SPL ระดับโลกและโปรแกรม Serum DEX ที่ไม่มีอยู่ตอนนี้ สิ่งนี้ทำให้ทุกการทำธุรกรรมที่มีการจับคู่กับบัญชีเหล่านี้ถูกบล็อก ลดความสามารถในการประมวลผลของ Solana อย่างรุนแรง แทนที่จะดำเนินการทำธุรกรรมอย่างอิสระ เครือข่ายกลายเป็นขวดคอ ประมวลผลการทำธุรกรรมตามลำดับ—ทำให้ปัญหาการแอบอุดตันมีความรุนแรงขึ้น

มีการแก้ไขที่ไม่สนใจการล็อกเขียนบนโปรแกรมที่ถูกพัฒนาไว้แล้วและกำหนดเวลาสำหรับการปล่อยออกมา ภายหลัง เครือข่ายรีบูตเปิดใช้การอัพเกรดนี้โดยถาวร ลบเส้นทางโจมตีนี้

ในระหว่างเหตุการณ์ IDO ผู้ตรวจสอบความถูกต้องได้รับธุรกรรมที่ขับเคลื่อนด้วยบอทจํานวนมากและในทางกลับกันก็ส่งต่อธุรกรรมส่วนเกินไปยังผู้นําคนต่อไปซึ่งเพิ่มความแออัด การรีบูตเครือข่ายแนะนําขีด จํากัด อัตราการส่งต่อธุรกรรมเพื่อป้องกันพายุธุรกรรมในอนาคตจากผู้นําที่ครอบงํา

โหนด RPC ของ Solana จะลองทำธุรกรรมที่ล้มเหลวโดยอัตโนมัติ ซึ่งเป็นคุณสมบัติที่ออกแบบมาเพื่อปรับปรุงความเชื่อถือได้ อย่างไรก็ตาม กลไกการลองทำธุรกรรมนี้ทำให้ปัญหาการล้มเหลวของธุรกรรมมากขึ้นในสภาวะแฝงมาก ๆ โดยทำให้ธุรกรรมเก่ายังอยู่รอบ ๆ แทนที่จะทำให้เครือข่ายกลับคืนสภาพได้ Solana 1.8 ได้เปิดให้ใช้การลองทำธุรกรรม RPC ที่กำหนดได้ ซึ่งทำให้แอปพลิเคชันสามารถปรับลองทำธุรกรรมใหม่ได้ด้วยเวลาหมดอายุที่สั้นลงและกลยุทธ์ exponential backoff

ภายใต้ความแออัดอย่างหนักผู้นํา Solana ล้มเหลวในการรวมธุรกรรมการลงคะแนนซึ่งมีความสําคัญต่อการรักษาฉันทามติ เป็นผลให้การขาดคะแนนเสียงที่ได้รับการยืนยันนําไปสู่แผงฉันทามติหยุดการผลิตบล็อกรากใหม่ ลูกค้า Solana รุ่นต่อมาได้แนะนํากลไกในการจัดลําดับความสําคัญของธุรกรรมการลงคะแนนเสียงเพื่อป้องกันไม่ให้พวกเขาจมน้ําตายจากการทําธุรกรรมปกติในเหตุการณ์ในอนาคต

ข้อผิดพลาดครั้งที่สอง: การเกิดการเกินทศนิยม

ในระหว่างการรีสตาร์ทเครือข่ายปัญหาที่สองเกิดขึ้น ผู้ตรวจสอบรายงานจํานวนเงินเดิมพันที่ผันผวนอย่างมาก ปัญหานี้เกิดจากจุดบกพร่องที่เปอร์เซ็นต์เงินเดิมพันถูกคูณอย่างไม่ถูกต้องด้วย 100 ซึ่งเกินค่าสูงสุดที่เป็นไปได้ กลไกเงินเฟ้อได้สร้างโทเค็น SOL ใหม่จํานวนมากจนล้นจํานวนเต็มที่ไม่ได้ลงชื่อ 64 บิต ข้อผิดพลาดนี้ถูกระบุและแก้ไขอย่างรวดเร็วก่อนที่จะรีสตาร์ทครั้งที่สอง

การแออัดสูง: มกราคม 2022

Downtime: None

สาเหตุหลัก: ธุรกรรมที่ซ้ำซ้อนมากเกินไป

การแก้ไขบางส่วน:

• รุ่น Solana 1.8.12 และ 1.8.14
• การปรับปรุงการตรวจสอบลายเซ็น SigVerify
• การปรับปรุงในประสิทธิภาพของแคชผู้ดำเนินการ

ระหว่างวันที่ 6 มกราคมถึง 12 มกราคม 2022 เครือข่ายหลักของ Solana ประสบปัญหาความแออัดของเครือข่ายอย่างรุนแรงซึ่งนําไปสู่ประสิทธิภาพที่ลดลงและการหยุดทํางานบางส่วน การหยุดชะงักเกิดจากบอทสแปมธุรกรรมที่ซ้ําซ้อนมากเกินไปซึ่งช่วยลดความจุของเครือข่ายลงอย่างมาก บล็อกใช้เวลานานกว่าที่คาดไว้ในการประมวลผลทําให้ผู้นําคนต่อไปแยกและลดปริมาณงานลงอีก เมื่อถึงจุดสูงสุดอัตราความสําเร็จในการทําธุรกรรมลดลงมากถึง 70% ลูกค้าพยายามดิ้นรนเพื่อจัดการกับธุรกรรมการประมวลผลที่ซับซ้อนและซับซ้อนมากขึ้นของเครือข่ายซึ่งเปิดเผยข้อ จํากัด ในความสามารถในการตอบสนองความต้องการ

ความไม่มั่นคงเพิ่มขึ้นเพิ่มเติมตั้งแต่วันที่ 21 ถึง 23 มกราคม โดยการจอดชะลอยังคงมีอยู่ ในวันที่ 22 มกราคม จุดปลายทาง RPC สาธารณะhttps://api.mainnet-beta.solana.com) ถูกปิดชั่วคราวเนื่องจากการใช้งานที่ไม่เหมาะสม เนื่องจากการโทรเรียก RPC แบบกลุ่มโดยไม่จำกัดที่ท้าทายระบบ

เพื่อแก้ไขปัญหาเหล่านี้ Solana 1.8.12 ปล่อยเฉพาะโปรแกรมเป้าหมายแคชอ่อนเพลียขณะ เวอร์ชัน 1.8.14 ได้เสนอการปรับปรุงให้กับแคช Sysvar, การทิ้ง SigVerify และการดูดซับ SigVerify.

สแปมเครื่องกล่องลูกอม: เมษายน/พฤษภาคม 2022

การหยุดชั่วคราว: แปดชั่วโมง

ปัญหาหลัก: การสแปมธุรกรรมจากบัญชีบอต

การแก้ไข:

• ภาษีบอทบนโปรแกรมตู้อาหาร
• การปรับปรุงหน่วยความจำใน Solana v1.10

ในวันที่ 30 เมษายน 2022 Solana ประสบการณ์การเพิ่มขึ้นที่ไม่เคยเป็นมาก่อนในคำขอธุรกรรม บางโหนดรายงานว่ามีการขอข้อมูลถึงหกล้านคำขอต่อวินาที สร้างมากกว่า 100 Gbps ของการจราจรต่อโหนด การเพิ่มขึ้นนี้เกิดจากบอทพยายามรักษา NFTs ที่พึ่งสร้างขึ้นผ่านโปรแกรม Metaplex Candy Machine กลไกการสร้างใหม่นี้ทำงานตามหลักคนมาก่อนคนแรกได้บริการสร้างแรงกระตุ้นทางเศรษฐกิจที่แข็งแรงให้กับการล้นเครือข่ายด้วยธุรกรรมและชนะการสร้าง

30 เมษายน / 1 พฤษภาคม 2565 การตัดบริการของเครื่องอุปกรณ์ตัดสินใจ แพ็กเก็ตต่อวินาทีเข้า (ข้อมูลจาก: Jump Crypto)

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

ในขณะที่ความขัดข้องนี้มีความคล้ายคลึงกับเหตุการณ์ในเดือนกันยายน 2021 แต่ Solana ได้แสดงให้เห็นถึงความทนทานที่ดีขึ้น แม้ว่าจะเผชิญกับคำขอธุรกรรมมากถึง 10,000% มากกว่าในครั้งก่อน แต่เครือข่ายยังคงสามารถให้บริการได้อย่างยาวนานมากขึ้น ทำให้เห็นถึงการปรับปรุงที่ชุมชนผู้ตรวจสอบได้ทำเพื่อรับมือกับความท้าทายในการขยายมากขึ้นก่อนหน้า

การขัดข้องของเครื่องอาหารลูกอม 30 เมษายน / 1 พฤษภาคม 2565, validators ที่ใช้งาน (แหล่งข้อมูล: Jump Crypto)

การรีสตาร์ทเครือข่ายใช้เวลาน้อยกว่า 1.5 ชั่วโมงหลังจากที่ถ่ายภาพสเนปช็อตแบบคานอนิคอลได้รับการตกลงแล้ว ซอลาน่าเวอร์ชัน 1.10 รวมการปรับปรุงการใช้หน่วยความจำเพื่อเพิ่มเวลาที่โหนดสามารถทนต่อการตกต่อหรือการตัดสินใจช้า

อย่างไรก็ตาม ปัญหาพื้นฐานยังคงคงอยู่ที่ยังไม่ได้แก้ไข ผู้นำยังคงประมวลผลธุรกรรมที่ส่วนแข่งขันสำหรับข้อมูลบัญชีเดียวกันตามลำดับของการมาก่อนเป็นหลักโดยไม่มีการป้องกันสแปมอย่างมีประสิทธิภาพ ทำให้ผู้ใช้ไม่สามารถจัดลำดับความเร่งด่วนของธุรกรรมของตนได้ ในการแก้ไขประเด็นนี้ มีการเสนอเครื่องมือสามประการที่ยาวนานเป็นวิธีการที่เป็นปฏิบัติ

การนำ QUIC มาใช้: ก่อนหน้านี้ Solana พึ่ง UDP (User Datagram Protocol) โปรโตคอลในการส่งธุรกรรมผ่าน Gulf Stream จากโหนด RPC ไปยังผู้นำปัจจุบัน อย่างไรก็ตาม UDP เป็นโปรโตคอลแบบไม่เชื่อมต่อ ที่ขาดควบคุมการไหลและการยืนยันการรับ ด้วยเหตุนี้ไม่มีทางที่มีนัยสำคัญในการป้องกันหรือบรรเทาพฤติกรรมที่ไม่เหมาะสม ในการควบคุมการจราของเครือข่าย โปรโตคอลการรับธุรกรรมของ validator (เช่น Fetch Stage ของ TPU) ถูกทำใหม่ด้วย QUIC

QUIC พยายามที่จะให้คุณสมบัติที่ดีที่สุดของ TCP และ UDP มันทำให้การสื่อสารแบบไม่ระบุเวลาเป็นไปอย่างรวดเร็ว คล้ายกับ UDP แต่มีเซสชันที่ปลอดภัยและกลยุทธ์ควบคุมการไหลขั้นสูงของ TCP นี้ทำให้สามารถกำหนดขีดจำกัดในแหล่งกำเนิดการจราจรแต่ละแหล่งได้ ดังนั้นเครือข่ายสามารถมุ่งเน้นการประมวลผลธุรกรรมที่แท้จริง QUIC ยังมีแนวคิดของการสตรีมแยกต่าง ๆ ดังนั้นหากธุรกรรมหนึ่งถูกทิ้งไป มันจะไม่บล็อกธุรกรรมที่เหลือ QUIC ในที่สุดถูกนำเข้าไปในไคลเอ็นต์ของ Solana Labs กับการปล่อยเวอร์ชัน 1.13.4

คุณภาพของบริการที่มีน้ำหนักในการจำนน (SWQoS): ระบบใหม่ที่ให้ลำดับความสำคัญในการส่งข้อมูลของเครือข่ายโดยดูจากการถือหุ้นของผู้ตรวจสอบ ทำให้ผู้ที่ถือหุ้นมากกว่าสามารถส่งธุรกรรมได้มีประสิทธิภาพมากขึ้น ภายใต้กลไกนี้ ผู้ตรวจสอบที่ถือหุ้น 3% ของทั้งหมดสามารถส่งได้สูงสุด 3% ของหน่วยข้อมูลทั้งหมดไปยังผู้นำ SWQoS ทำหน้าที่เป็นมาตรการต้านซิบิล ทำให้มันยากขึ้นสำหรับผู้กระทำที่ไม่ดีที่จะทำให้เครือข่ายเต็มไปด้วยธุรกรรมคุณภาพต่ำ วิธีการนี้จะทำให้การมาถึงก่อนเป็นอดีต ๆ ที่ยอมรับธุรกรรมอย่างไม่มีเงื่อนไขโดยไม่คำนึงถึงแหล่งที่มาของมัน

การแนะนำค่าธรรมเนียมความสำคัญ:เมื่อธุรกรรมถูกนำเข้าแล้ว พวกเขายังคอมพีตในการเข้าถึงข้อมูลบัญชีที่ใช้ร่วมกัน ในอดีต การชิงชังนี้ถูกแก้ไขตามหลักการเข้ามาก่อนเข้าก่อนให้บริการโดยไม่มีวิธีใด ๆ ที่จะแสดงถึงความเร่งด่วนของธุรกรรมของพวกเขา โดยที่ใครก็สามารถส่งธุรกรรม การให้น้ำหนักของเข็มไม่เหมาะสำหรับการจัดลำดับลำดับในขั้นตอนนี้ โดยที่จะจัดการกับสิ่งนี้ ได้เพิ่มคำสั่งใหม่ในโปรแกรม Compute Budget ที่อนุญาตให้ผู้ใช้ระบุค่าธรรมเนียมเพิ่มเติมที่รวบรวมขณะดำเนินการและรวมอยู่ในบล็อก อัตราส่วนค่าธรรมเนียมต่อหน่วยคำนวณกำหนดลำดับการดำเนินการของธุรกรรม ทำให้มีวิธีการที่มีความหลากหลายและเชื่อถือได้มากขึ้นในการจัดลำดับธุรกรรมจากตลาด

Candy Machine Bot Tax

Metaplex ได้ทันทีใช้ภาษีบอทเข้ารหัสแบบคงที่ 0.01 SOL ในธุรกรรมการสรรพสินค้าการจับคู่กับโปรแกรม Candy Machine เพื่อต่อสู้กับสแปมที่มาจากบอท กลไกต้านสแปมนี้ใช้ค่าธรรมเนียมขั้นต่ำเพื่อป้องกันกิจกรรมที่ไม่เพราะต่อผู้ใช้ที่ทำข้อผิดพลาดโดยไม่ได้ตั้งใจ ภาษีถูกนำมาใช้ในสถานการณ์ที่เฉพาะเจาะจง เช่น:

• พยายามหยิบเหรียญเมื่อเครื่องจำหน่ายลูกอมไม่ได้เปิดใช้งาน
• พยายามทำการสร้างเหรียญเมื่อไม่มีสิ่งของที่เหลือ
• ธุรกรรมที่การสร้างหรือตั้งค่าคอลเลคชันไม่ใช่คำสั่งสุดท้าย
• การใช้ ID คอลเลกชันไม่ถูกต้อง
• คำสั่งการเก็บข้อมูลชุดที่ไม่ตรงกัน
• ความไม่สอดคล้องระหว่างผู้ลงนาม-ผู้จ่ายเงินระหว่างชุดการเก็บเงินและคำสั่งการสร้างเหรียญ
• ธุรกรรมที่น่าสงสัยที่เกี่ยวข้องกับโปรแกรมที่ไม่ได้รับอนุญาต
• พยายามพิมพ์จากเครื่องขนมที่ได้รับการป้องกันด้วย AllowList โดยไม่ถือโทเค็นที่ได้รับอนุญาตที่จำเป็น

มลธ. นี้เป็นปัจจัยกันใจทางเศรษฐกิจที่มีประสิทธิภาพมาก สไนเปอร์ของมินต์ถูกดูดและกิจกรรมสแปมหยุด ในระยะเวลาไม่กี่วันแรก บอทเตอร์สูญเสียรวมกันมากกว่า 426 SOL

บั๊ก Nonce ที่แข็งแรง: มิถุนายน 2022

เวลาที่ระบบปิด: สี่ชั่วโมงครึ่ง

ปัญหาราก: ข้อผิดพลาด nonce ที่ทนทานซึ่งนําไปสู่ความล้มเหลวของฉันทามติ

Fixes:

• การปิดใช้งานชั่วคราวของการทำธุรกรรมที่มีความคงทน
• Solana 1.10.23 การอัปเดต

บั๊กรันไทม์อนุญาตให้ประมวลผลธุรกรรม nonce ที่ทนทานบางอย่างได้สองครั้ง—หนึ่งครั้งเป็นธุรกรรมปกติและอีกครั้งเป็นธุรกรรม nonce—หากพวกเขาใช้ blockhash ล่าสุดแทนที่จะเป็น nonce ที่ทนทานในฟิลด์ recent_blockhash สิ่งนี้นําไปสู่พฤติกรรมที่ไม่กําหนดในหมู่ผู้ตรวจสอบเนื่องจากบางโหนดปฏิเสธการดําเนินการครั้งที่สองในขณะที่คนอื่นยอมรับ ที่สําคัญเนื่องจากผู้ตรวจสอบความถูกต้องมากกว่าหนึ่งในสามยอมรับการบล็อกจึงป้องกันไม่ให้เสียงข้างมากสองในสามที่ต้องการบรรลุฉันทามติ

ไม่เหมือนธุรกรรมมาตรฐาน ธุรกรรม nonce ที่มีความทนทานไม่มีวันหมดอายุและต้องใช้กลไกที่ไม่เหมือนใครเพื่อป้องกันการดำเนินการซ้ำ การดำเนินการนี้จะถูกประมวลผลเป็นลำดับโดยใช้ค่า nonce on-chain ที่เชื่อมโยงกับแต่ละบัญชี ซึ่งจะถูกหมุนเปลี่ยนทุกครั้งที่มีการดำเนินการธุรกรรม nonce ที่ทนทาน หลังจากหมุนเปลี่ยนแล้ว ธุรกรรม nonce เดียวกันไม่ควรถูกต้องอีกครั้ง

เพื่อลดปัญหาการใช้งาน การทำธุรกรรม nonce ที่ทนทานได้ถูกปิดใช้ชั่วคราวการแก้ไขถูกนํามาใช้ในภายหลังใน Solana 1.10.23 ที่ป้องกันการดำเนินการที่ซ้ำกันโดยการแยกโดเมน nonce และโดเมน blockhash การอัปเดตแน่ใจว่าเมื่อเดินหน้าไปที่บัญชี nonce blockhash จะถูกแฮชด้วยสตริงคงที่ ทำให้ blockhash ไม่ถูกต้องเป็นค่า nonce ผลลัพธ์คือ ธุรกรรมที่ดำเนินการหนึ่งครั้งเป็นธุรกรรมปกติไม่สามารถดำเนินการอีกครั้งเป็นการดำเนินการที่ยั่งยืนได้และในทางกลับกัน นอกจากนี้ ประเภท DurableNonce ใหม่ได้แทนค่า blockhash ก่อนหน้าในสถานะบัญชี nonce เพิ่มความปลอดภัยในการใช้งานและป้องกันปัญหาที่คล้ายกันในอนาคต

อ่านบทความบล็อกก่อนหน้าของเรา Helius เพื่อทําความเข้าใจเพิ่มเติมเกี่ยวกับ nonces ที่ทนทานและการใช้งาน.

ข้อบกพร่องบล็อกซ้ำ: กันยายน 2022

เวลาหยุดทำงาน: แปดชั่วโมงครึ่ง

ปัญหาราก: ข้อผิดพลาดในกฎการเลือกส้อมนําไปสู่ความล้มเหลวของฉันทามติ

แก้ไข:

• Client patch

การขัดข้องนี้เกิดจากผู้ตรวจสอบที่สร้างบล็อกซ้ำๆ ในระดับบล็อกเดียวกันโดยความผิดพลาด สถานการณ์นี้เกิดขึ้นเพราะโหนดหลักของผู้ตรวจสอบและโหนดสำรองทดแทนเปิดใช้งานพร้อมกันโดยใช้ตัวตนโหนดเดียวกัน แต่เสนอบล็อกที่แตกต่างกัน สถานการณ์นี้ยังคงอยู่เป็นเวลาอย่างน้อย 24 ชั่วโมงก่อนการขัดข้อง ในช่วงนั้นเครือข่ายได้จัดการกับช่องทางนำของผู้ตรวจสอบที่ซ้ำๆ ได้ถูกต้อง

กลุ่มสุดท้ายจึงหยุดเมื่อเครือข่ายพบการแยกแซงที่ไม่สามารถกู้คืนได้เนื่องจากข้อบกพร่องในตรรกะการเลือกแยกแซง ข้อบกพร่องนี้ป้องกันผู้ผลิตบล็อกไม่สามารถสร้างบนบล็อกก่อนหน้านั้น ทำให้เกิดความล้มเหลวในการเชื่อมั่น

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

ข้อบกพร่องของบล็อกที่ซ้ำซ้อนเกิดปัญหาในการเลือกฟอร์คเมื่อเดือนกันยายน 2022 (ที่มา: Laine, Michael Hubbard)

ในตัวอย่างข้างต้น ผู้ตรวจสอบที่เสีย C สร้างบล็อกซ้ำสำหรับช่องนำของตน 5 ถึง 8 เมื่อผู้ตรวจสอบ G เข้ามาเป็นผู้นำต่อไป มันสังเกตเห็นเพียงหนึ่งของบล็อกที่ซ้ำและขยายคาดของมันตามนั้น อย่างไรก็ตาม ผู้นำต่อไป ผู้ตรวจสอบ D ตรวจพบบล็อกที่ซ้ำจาก C และตัดสินใจที่จะทอดทิ้งแทนการสร้างคาดของมันบนช่อง 4

เมื่อเครือข่ายดําเนินไปส้อมที่สร้างขึ้นโดยผู้ตรวจสอบความถูกต้อง G จะได้รับคะแนนเสียงจากสัดส่วนการถือหุ้นส่วนใหญ่โดยสร้างตัวเองเป็นห่วงโซ่บัญญัติ เมื่อตระหนักถึงส้อมของมันคือการสูญเสียผู้ตรวจสอบ D พยายามที่จะเปลี่ยนไปใช้ส้อมของผู้ตรวจสอบ G อย่างไรก็ตามการเปลี่ยนแปลงล้มเหลวเนื่องจากข้อผิดพลาดในตรรกะการเลือกส้อม ปัญหานี้เกิดขึ้นเนื่องจากบรรพบุรุษทั่วไปของส้อมทั้งสองซึ่งเป็นบล็อกที่ซ้ํากันที่ช่อง 5 ไม่ได้รับการจัดการอย่างถูกต้องทําให้ผู้ตรวจสอบ D ไม่สามารถจดจําส้อมส่วนใหญ่ได้ เป็นผลให้ผู้ตรวจสอบ D ยังคงติดอยู่บนส้อมของตัวเองไม่สามารถเข้าร่วมห่วงโซ่หลักได้

ปัญหาได้รับการแก้ไขหลังจากทีมหลักตรวจสอบแพทช์ถูกรวมเข้ากับสาขาหลักและ backported ไปยังสาขาที่วางจําหน่ายทั้งหมด.

Large Block Overwhelms Turbine: กุมภาพันธ์ 2023

เวลาที่ปิดปรับ: เกือบ 19 ชั่วโมง

ปัญหาหลัก: ความล้มเหลวของตรรกะในการดูปลักษณ์ในบริการส่งข้อมูล

การแก้ไข:

• การปรับปรุงหลายอย่างในตรรกะการซ้ำซ้อนและการกรองของ Turbine
• เพิ่มแพทช์ลูกค้าที่บังคับผู้ผลิตบล็อกให้ยกเลิกหากพวกเขาสร้างบล็อกขนาดใหญ่

บริการส่งต่อฉีกแบบกําหนดเองของผู้ตรวจสอบทํางานผิดปกติโดยส่งบล็อกขนาดใหญ่เป็นพิเศษ (เกือบ 150,000 ชิ้น) หลายคําสั่งที่มีขนาดใหญ่กว่าบล็อกมาตรฐานในระหว่างช่องผู้นํา ตัวกรองการขจัดข้อมูลซ้ําซ้อนของผู้ตรวจสอบที่ล้นหลามนี้ทําให้ข้อมูลถูกส่งต่ออย่างต่อเนื่อง ปัญหาเกิดขึ้นเมื่อมีการผลิตบล็อกใหม่ในที่สุดก็อิ่มตัวโปรโตคอล

การขัดข้องบล็อกขนาดใหญ่, เศษต่อบล็อก, กุมภาพันธ์ 2023 (ที่มา: Laine, Michael Hubbard)

การเพิ่มขึ้นของการรับส่งข้อมูลเครือข่ายที่ผิดปกติทําให้ Turbine ล้นหลามบังคับให้ส่งข้อมูลบล็อกผ่านโปรโตคอล Block Repair สํารองที่ช้าลงอย่างมาก แม้ว่า Turbine จะได้รับการออกแบบมาให้ทนต่อบล็อกขนาดใหญ่โดยการกรองออก แต่บริการส่งต่อแบบฉีกจะทํางานต้นน้ําของตรรกะการกรองนี้ทําให้ประสิทธิภาพลดลง ในช่วงเวลาที่เสื่อมโทรมผู้นําบล็อกจะเปลี่ยนเข้าสู่โหมดการลงคะแนนอย่างเดียวโดยอัตโนมัติซึ่งเป็นกลไกความปลอดภัยที่ผู้นําไม่รวมธุรกรรมที่ไม่ใช่การลงคะแนนเสียงทางเศรษฐกิจ

สาเหตุหลักของปัญหาคือการล้มเหลวในตรรกะการลบข้อมูลซ้ำในบริการส่งข้อมูล shred-forwarding ซึ่งป้องกันการส่งข้อมูล shred อีกครั้งโดยไม่จำเป็น นอกจากนี้ ตัวกรองการลบข้อมูลซ้ำในท่อส่งข้อมูลซ้ำไม่ได้ถูกออกแบบมาเพื่อป้องกันการวนวายในต้นไม้ Turbine ทำให้ปัญหาแย่ลง

เครือข่ายเริ่มต้นใหม่ด้วยตนเองด้วยการดาวน์เกรดเป็นเวอร์ชันซอฟต์แวร์ตรวจสอบที่เสถียรล่าสุดที่รู้จัก เพื่อบรรเทาปัญหาเหล่านี้ Solana v1.13.7 และ v1.14.17 ได้นำเสนอการปรับปรุงในตรรกะการดูดซ้ำ, ปรับปรุงความสามารถในการป้องกันการอิ่มตัวของฟิลเตอร์และรับรองประสิทธิภาพของเครือข่ายที่แข็งแรงมากยิ่งขึ้น

วงจรการคอมไพล์ไร้ขอบเขต: กุมภาพันธ์ 2024

เวลาหยุดทำงาน: เกือบห้าชั่วโมง

ปัญหาหลัก: บั๊กที่ทำให้การคอมไพล์วนซ้ำไร้อยิงในแคช JIT ได้รับการแก้ไข

Fixes:

• ปิดใช้งานตัวโหลดแบบดั้งเดิม v1.17.20

Agave validator just-in-time (JIT) จะคอมไพล์โปรแกรมทั้งหมดก่อนที่จะทําธุรกรรมที่อ้างอิงถึงโปรแกรมเหล่านั้น เพื่อเพิ่มประสิทธิภาพเอาต์พุต JIT ของโปรแกรมที่ใช้บ่อยจะถูกแคชเพื่อลดการคอมไพล์ใหม่ที่ไม่จําเป็น ในฐานะที่เป็นส่วนหนึ่งของ Agave v1.16 กลไกการแคชที่มีอยู่ LoadedPrograms ถูกแทนที่ด้วยการใช้งานใหม่ที่เรียกว่า ExecutorsCache ซึ่งแนะนําประสิทธิภาพหลายประการ

LoadedPrograms ให้มุมมองระดับโลกที่ตระหนักรู้ถึงโปรแกรมที่ถูกแคชไว้เพื่อลดการทำซ้ำของข้อมูลบัญชีและอนุญาตให้เธรดการกระทำธุรกรรมโหลดโปรแกรมใหม่และป้องกันข้อขัดแย้งในการคอมไพล์อย่างร่วมมือ คุณลักษณะสำคัญของระบบนี้คือการติดตามสล็อตที่โปรแกรมกลายเป็นใช้งาน (ที่รู้จักกันว่าความสูงของสล็อตที่มีผล) เพื่อตรวจจับการยกเลิกแคชเมื่อข้อมูลโปรแกรมบนเชนถูกอัปเดต

ความสูงของสล็อตที่มีประสิทธิภาพของโปรแกรมส่วนใหญ่มาจากสล็อตการปรับใช้ซึ่งถูกเก็บไว้ในบัญชีแบบ on-chain อย่างไรก็ตาม โปรแกรมที่ปรับใช้โดยใช้ตัวโหลดแบบเดิมไม่ได้เก็บสล็อตการปรับใช้นี้ไว้ในบัญชีของตน LoadedPrograms มอบหมายให้โปรแกรมเหล่านี้มีความสูงของสล็อตที่มีประสิทธิภาพเป็นศูนย์เป็นวิธีแก้ปัญหา

มีข้อยกเว้นเกิดขึ้นเมื่อตรวจพบคําสั่งการปรับใช้ ซึ่งเป็นสัญญาณว่าไบต์โค้ดของโปรแกรมถูกแทนที่ ในกรณีนี้ LoadedPrograms แทรกรายการชั่วคราวด้วยความสูงของสล็อตที่ถูกต้อง อย่างไรก็ตามเนื่องจากธุรกรรมไม่เคยอ้างอิงรายการนี้จึงมีความเสี่ยงสูงต่อการขับไล่ เมื่อถูกขับไล่เอาต์พุต JIT จะถูกทิ้งและโปรแกรมถูกทําเครื่องหมายว่ายกเลิกการโหลด แต่ความสูงของสล็อตที่มีประสิทธิภาพจะถูกเก็บไว้

หากธุรกรรมอ้างอิงถึงโปรแกรมที่ไม่ได้โหลดนี้ในภายหลัง LoadedPrograms จะคอมไพล์ใหม่และแทรกรายการใหม่ที่ความสูงของสล็อตที่มีประสิทธิภาพ โดยทั่วไปสิ่งนี้จะทําให้โปรแกรมพร้อมใช้งานสําหรับการดําเนินการในการทําซ้ําครั้งต่อไป อย่างไรก็ตามสําหรับโปรแกรมตัวโหลดแบบเดิมเอาต์พุต JIT ใหม่ถูกกําหนดความสูงของสล็อต Sentinel เป็นศูนย์โดยวางไว้ด้านหลังรายการที่ไม่ได้โหลดก่อนหน้านี้ เป็นผลให้ LoadedPrograms ไม่เคยรู้จักโปรแกรมว่าโหลดแล้วทําให้เกิดลูปคอมไพล์ใหม่อย่างต่อเนื่องในทุกการทําซ้ํา

ใน Agave v1.16, LoadedPrograms ไม่สนับสนุนการโหลดแบบร่วมมือทําให้ธุรกรรมทริกเกอร์ถูกบรรจุลงในบล็อก บล็อกนี้ถูกเผยแพร่ไปทั่วเครือข่ายทําให้ผู้ตรวจสอบทุกคนเล่นซ้ําและเข้าสู่ลูปการคอมไพล์ใหม่ที่ไม่มีที่สิ้นสุด เนื่องจากกว่า 95% ของสัดส่วนการถือหุ้นคลัสเตอร์ใช้ Agave v1.17 ในช่วงที่ไฟดับผู้ตรวจสอบส่วนใหญ่จึงหยุดชะงักในบล็อกนี้ทําให้เครือข่ายหยุดชะงัก

ข้อบกพร่องนี้ถูกพบในสัปดาห์ก่อนหน้านี้ระหว่างการสำรวจเกี่ยวกับปัญหาในกลุ่ม Devnet และมีการกำหนดการให้สมบัติ@jeff.washington/2024-02-06-solana-mainnet-beta-outage-report-619bd75b3ce0">การบรรเทาที่เลือกคือการเปลี่ยนแปลงแบ็คพอร์ตเป็น Agave v1.17 และลบประตูคุณลักษณะทันทีเมื่อรีสตาร์ทเครือข่าย สิ่งนี้ปิดใช้งานตัวโหลดดั้งเดิมที่รับผิดชอบในการทริกเกอร์บั๊กเพื่อป้องกันการเกิดขึ้นอีก

แพตช์ช่องโหว่ที่ประสานงาน: สิงหาคม 2024

การหยุดทํางาน: ไม่มี

ปัญหาราก: สมมติฐานการจัดตําแหน่งที่อยู่ ELF ไม่ถูกต้อง

Fixes:

• อัปเดตแพตช์

เมื่อวันที่ 5 สิงหาคม วิศวกรหลักของ Anza ได้รับการแจ้งเตือนถึงช่องโหว่ในไคลเอนต์ Agave ซึ่งรายงานโดยนักวิจัยภายนอก. ผู้โจมตีอาจใช้ประโยชน์จากข้อบกพร่องนี้เพื่อทําลายผู้ตรวจสอบผู้นําซึ่งนําไปสู่การหยุดทั่วทั้งเครือข่าย ในการตอบสนองวิศวกรของ Anza ได้พัฒนาแพตช์อย่างรวดเร็วซึ่ง บริษัท รักษาความปลอดภัยบุคคลที่สามหลายแห่งได้ตรวจสอบแล้ว

โปรแกรม Solana ถูกรวบรวมโดยใช้ LLVM ลงใน รูปแบบปฏิบัติการและเชื่อมโยงได้ (ELF). ช่องโหว่เกิดจากสมมติฐานการจัดตําแหน่งที่อยู่ที่ไม่ถูกต้องภายในไฟล์ ELF ที่สร้างขึ้นเหล่านี้ แม้ว่าการฆ่าเชื้อ ELF โดยทั่วไปจะบังคับใช้การตรวจสอบความสมบูรณ์ต่างๆ แต่ก็ไม่ได้ตรวจสอบการจัดตําแหน่งของส่วน .text การกํากับดูแลนี้อาจอนุญาตให้ไฟล์ ELF ที่ออกแบบมาเพื่อประสงค์ร้ายกําหนดส่วน. text ที่ไม่ตรงแนวทําให้เครื่องเสมือนข้ามไปยังที่อยู่ที่ไม่ถูกต้อง สิ่งนี้จะส่งผลให้เกิดความผิดพลาดในการแบ่งส่วนโฮสต์ทําให้ตัวตรวจสอบหยุดทํางาน

ผู้โจมตีอาจใช้ประโยชน์จากช่องโหว่นี้โดย:

• การสร้างโปรแกรม Solana ที่เป็นอันตรายที่ใช้ opcode CALL_REG
• การปรับแต่งไฟล์ ELF เพื่อทำให้ .text ส่วนถูกจัดตำแหน่งผิด
• การใช้งานและเรียกใช้โปรแกรมบนเครือข่าย ทำให้ validator ต้องดับ

กระบวนการอัปเดตแพตช์

การอัปเดตแพตช์ที่เผยแพร่ต่อสาธารณะจะทําให้ช่องโหว่ชัดเจนสําหรับทุกคนทันที สิ่งนี้อาจทําให้ผู้โจมตีมีเวลามากพอที่จะทําวิศวกรรมย้อนกลับช่องโหว่และหยุดเครือข่ายก่อนที่จะมีการอัปเกรดเงินเดิมพันในปริมาณที่เพียงพอ ผู้ตรวจสอบจํานวนมากจะต้องใช้การปล่อยแพตช์ใด ๆ โดยเร็วที่สุดเพื่อหลีกเลี่ยงสถานการณ์ดังกล่าว

ภายในวันที่ 7 สิงหาคม สมาชิกหลายคนของ มูลนิธิโซลานาได้ติดต่อผู้ตรวจสอบความถูกต้องผ่านข้อความส่วนตัวบนแพลตฟอร์มการสื่อสารต่างๆแจ้งให้พวกเขาทราบถึงแพตช์สําคัญที่จะเกิดขึ้นและแบ่งปันข้อความแฮชที่ยืนยันวันที่และตัวระบุที่ไม่ซ้ํากันของเหตุการณ์ สมาชิก Anza, Jito และ Solana Foundation ที่มีชื่อเสียงหลายคนแบ่งปันแฮชนี้บน X, GitHub และ LinkedIn เพื่อตรวจสอบความถูกต้องของข้อความ ตัวอย่างแฮชที่แชร์:

ในวันถัดไป สมาชิกหลักยังคงติดต่อกับผู้ตรวจสอบอย่างต่อเนื่อง เน้นความสำคัญของความเร่งด่วนและความลับ ในเวลาที่กำหนดไว้ คือ วันที่ 8 สิงหาคม เวลา 14:00 น. ตามเวลาสากล (UTC) ผู้ดำเนินการตรวจสอบได้รับข้อความเพิ่มเติมที่ประกอบด้วยคำแนะนำในการดาวน์โหลด ตรวจสอบ และนำแพทช์ไปใช้ แพทช์ถูกโฮสต์บนที่เก็บรักษาข้อมูล Github ของวิศวกร Anza ที่รู้จัก ไม่ใช่ที่เก็บรักษาข้อมูล Agave หลัก คำแนะนำรวมถึงการตรวจสอบของไฟล์แพทช์ที่ดาวน์โหลดสุ่มได้มากมาย

ภายในเวลา 20.00 น. UTC ของวันที่ 8 สิงหาคม ได้มีการแก้ไขสัดส่วนการถือหุ้นสูงสุดเพื่อความปลอดภัยของเครือข่าย หลังจากนี้ช่องโหว่และแพตช์ที่เกี่ยวข้องได้รับการเปิดเผยต่อสาธารณะพร้อมกับการเรียกร้องให้ผู้ตรวจสอบที่เหลือทั้งหมดอัปเกรด

การกระจายตัวอย่างเงียบ ๆ ของแพตช์และการประสานงานเบื้องหลังของผู้ตรวจสอบทําให้เกิดความกังวลเกี่ยวกับการกระจายอํานาจของ Solana ไม่นานหลังจากเหตุการณ์ Dan Albert ผู้อํานวยการบริหารของ Solana Foundation ได้กล่าวถึงคําวิพากษ์วิจารณ์เหล่านี้ในการให้สัมภาษณ์สื่อ

“ฉันคิดว่าสำคัญที่จะไม่สับสนกับการกลายเป็นส่วนกลางกับความสามารถในการประสานงาน มีโหนดผลิตบล็อก 1,500 โหนดทั่วโลกที่ดำเนินการโดยผู้คนเกือบ ๆ จำนวนเท่ากัน.... ความสามารถในการสื่อสารกับพวกเขา หรือบางส่วนของพวกเขา โดยสมัครสมาคม ไม่ควรสับสนกับการกลายเป็นส่วนกลาง”

สัปดาห์ Blockchain เกาหลี (KBW) 2024

ฉันคิดว่ามันเป็นสิ่งสําคัญที่จะไม่สับสนการรวมศูนย์กับความสามารถในการประสานงาน มีโหนดที่ผลิตบล็อก 1,500 โหนดทั่วโลกที่ดําเนินการโดยบุคคลเกือบเท่า... ความสามารถในการสื่อสารกับพวกเขาหรือบางส่วนโดยสมัครใจไม่ควรสับสนกับการรวมศูนย์

บทสรุป

จากการเขียนนี้ Solana ได้ผ่านไปหนึ่งปีโดยไม่มีการหยุดทํางานซึ่งถือเป็นก้าวสําคัญในการลบแท็ก "เบต้า" ออกจาก mainnet-beta ความถี่ของการหยุดทํางานดูเหมือนจะลดลงเมื่อเครือข่ายเติบโตขึ้นและการเปิดตัว Firedancer คาดว่าจะช่วยเพิ่มความหลากหลายของลูกค้าลดความเสี่ยงของข้อบกพร่องที่ยังไม่ถูกค้นพบหรือกรณีขอบที่ทําให้เกิดการปิดระบบทั่วทั้งคลัสเตอร์ อย่างไรก็ตาม ผู้นําชุมชนบางคน รวมถึง Mert Mumtaz ผู้ก่อตั้ง Helius ได้คาดการณ์ว่าไฟดับจะยังคงดําเนินต่อไป เวลาจะบอก

ขอบคุณมาก Zantetsu (Shinobi Systems) และ OxIchigo สำหรับการทบทวนเวอร์ชันก่อนหน้าของงานนี้

ข้อความปฏิเสธความรับผิดชอบ:

1. บทความนี้พิมพ์ซ้ําจาก [Helius]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [หลงทาง]. หากมีการคัดค้านการพิมพ์ซ้ํานี้โปรดติดต่อ Gate Learnทีมและพวกเขาจะจัดการกับมันโดยทันที
2. ข้อจํากัดความรับผิดชอบความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนและไม่ถือเป็นคําแนะนําการลงทุนใด ๆ
3. ทีม gate Learn ทำการแปลบทความเป็นภาษาอื่น ๆ การคัดลอก การกระจาย หรือการลอกเลียนแบบบทความที่ถูกแปลนั้นถูกห้าม นอกจากจะได้ระบุไว้