ชื่อเรื่องต้นฉบับ: โครงสร้างพื้นฐานคริปโตยังห่างไกลจากความสมบูรณ์แบบ

ผู้เขียนต้นฉบับ: YQ, Crypto KOL

ผู้แปลต้นฉบับ: AididiaoJP, Foresight News

Amazon Web Services ประสบปัญหาขัดข้องครั้งใหญ่อีกครั้ง ส่งผลกระทบอย่างรุนแรงต่อโครงสร้างพื้นฐานคริปโต ปัญหา AWS ในเขต 1 ฝั่งตะวันออกของสหรัฐอเมริกา (ศูนย์ข้อมูลเวอร์จิเนียตอนเหนือ) ส่งผลให้ Coinbase และแพลตฟอร์มคริปโตหลักอื่นๆ อีกหลายสิบแห่ง รวมถึง Robinhood, Infura, Base และ Solana ต้องหยุดชะงัก

AWS ยอมรับว่า "อัตราข้อผิดพลาดที่เพิ่มขึ้น" ส่งผลกระทบต่อ Amazon DynamoDB และ EC2 ซึ่งเป็นบริการฐานข้อมูลหลักและการประมวลผลที่บริษัทหลายพันแห่งใช้งาน การหยุดให้บริการครั้งนี้เป็นการยืนยันข้อโต้แย้งหลักของบทความนี้ในทันทีและชัดเจน นั่นคือ การที่โครงสร้างพื้นฐานคริปโตพึ่งพาผู้ให้บริการคลาวด์แบบรวมศูนย์สร้างช่องโหว่ของระบบที่ปรากฏขึ้นซ้ำแล้วซ้ำเล่าภายใต้แรงกดดัน

ช่วงเวลานี้ช่างน่าหดหู่ใจ เพียงสิบวันหลังจากการชำระบัญชีมูลค่า 19.3 พันล้านดอลลาร์สหรัฐฯ เผยให้เห็นถึงความล้มเหลวของโครงสร้างพื้นฐานในระดับแพลตฟอร์มการซื้อขาย การหยุดให้บริการของ AWS ในวันนี้แสดงให้เห็นว่าปัญหาขยายวงกว้างเกินกว่าแพลตฟอร์มเดียวไปจนถึงชั้นโครงสร้างพื้นฐานคลาวด์พื้นฐาน เมื่อ AWS ล้มเหลว ผลกระทบแบบลูกโซ่จะส่งผลกระทบต่อการแลกเปลี่ยนแบบรวมศูนย์ แพลตฟอร์มแบบ "กระจายศูนย์" ที่มีการพึ่งพาแบบรวมศูนย์ และบริการอื่นๆ อีกมากมายพร้อมกัน นี่ไม่ใช่เหตุการณ์ที่เกิดขึ้นเพียงครั้งเดียว แต่เป็นรูปแบบหนึ่ง การวิเคราะห์ต่อไปนี้แสดงให้เห็นถึงการหยุดให้บริการของ AWS ที่คล้ายคลึงกันในเดือนเมษายน 2025 ธันวาคม 2021 และมีนาคม 2017 ซึ่งแต่ละกรณีได้ทำให้บริการคริปโตหลักๆ หยุดชะงัก คำถามไม่ใช่ว่าความล้มเหลวของโครงสร้างพื้นฐานครั้งต่อไปจะเกิดขึ้นหรือไม่ แต่เป็นว่าจะเกิดขึ้นเมื่อใดและอะไรจะกระตุ้นให้เกิดความล้มเหลว ห่วงโซ่การชำระบัญชี 10-11 ตุลาคม 2568: กรณีศึกษา ห่วงโซ่การชำระบัญชี 10-11 ตุลาคม 2568 นำเสนอกรณีศึกษาที่ให้ความกระจ่างเกี่ยวกับรูปแบบความล้มเหลวของโครงสร้างพื้นฐาน เมื่อเวลา 20:00 น. UTC การประกาศทางภูมิรัฐศาสตร์ครั้งใหญ่ได้กระตุ้นให้เกิดการเทขายทั่วทั้งตลาด ภายในหนึ่งชั่วโมง เกิดการชำระบัญชีมูลค่า 6 พันล้านดอลลาร์สหรัฐ เมื่อตลาดเอเชียเปิดทำการ สถานะเลเวอเรจมูลค่า 19.3 พันล้านดอลลาร์สหรัฐได้หายไปในบัญชีเทรดเดอร์ 1.6 ล้านคนรูปที่ 1: ไทม์ไลน์ของเหตุการณ์ในห่วงโซ่อุปทานการชำระบัญชี ตุลาคม 2568 แผนภูมิไทม์ไลน์แบบโต้ตอบนี้แสดงให้เห็นความคืบหน้าอันน่าทึ่งของการชำระบัญชีรายชั่วโมง โดยสูญเสียเงินไป 6 พันล้านดอลลาร์ภายในชั่วโมงแรกเพียงชั่วโมงเดียว ตามมาด้วยชั่วโมงที่สองอันน่าตื่นเต้นยิ่งกว่าเมื่อห่วงโซ่อุปทานเร่งตัวขึ้น ภาพแสดง:

· 20:00-21:00: ผลกระทบเบื้องต้น - ชำระบัญชีมูลค่า 6 พันล้านดอลลาร์ (พื้นที่สีแดง)

· 21:00-22:00: จุดสูงสุดของห่วงโซ่ - 4.2 พันล้านดอลลาร์ เมื่อเริ่มมีการลดปริมาณ API

· 22:00-04:00: การเสื่อมสภาพอย่างต่อเนื่อง - ชำระบัญชีมูลค่า 9.1 พันล้านดอลลาร์ในตลาดที่มีสภาพคล่องต่ำ

· จุดเปลี่ยนสำคัญ: การจำกัดอัตรา API, การถอนตัวของผู้ดูแลตลาด, การลดจำนวนคำสั่งซื้อขาย

ขนาดใหญ่อย่างน้อยหนึ่งลำดับของขนาดเมื่อเทียบกับเหตุการณ์ในตลาดคริปโตครั้งก่อนๆ และการเปรียบเทียบในอดีตแสดงให้เห็นถึงลักษณะฟังก์ชันขั้นบันไดของเหตุการณ์นี้:

รูปที่ 4.5: การหยุดให้บริการของ AWS ส่งผลกระทบต่อบริการคริปโต

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

ช่องโหว่ด้านการจัดการและการกำหนดราคาของ Oracle

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

รูปที่ 3: แผนผังกระบวนการจัดการ Oracle

แผนผังกระบวนการแบบโต้ตอบนี้แสดงภาพเวกเตอร์การโจมตีห้าขั้นตอน:

· การเทขายครั้งแรก: แรงกดดันการขาย USDe มูลค่า 60 ล้านดอลลาร์

· การจัดการราคา: USDe ร่วงลงจาก 1.00 ดอลลาร์เหลือ 0.65 ดอลลาร์ในการแลกเปลี่ยนครั้งเดียว

Oracle ล้มเหลว: ระบบมาร์จิ้นใช้ฟีดราคาภายในที่เสียหาย ทริกเกอร์แบบเรียงซ้อน: หลักประกันถูกประเมินค่าต่ำกว่าความเป็นจริง การบังคับชำระบัญชี เริ่มต้นการขยาย: การชำระบัญชีมูลค่า 19.3 พันล้านดอลลาร์ (ขยาย 322 เท่า) การโจมตีนี้ใช้ประโยชน์จากการใช้ราคาตลาดสปอตของ Binance สำหรับหลักประกันสังเคราะห์ที่ห่อหุ้ม เมื่อผู้โจมตีเทขาย USDe มูลค่า 60 ล้านดอลลาร์ลงในสมุดคำสั่งซื้อขายที่ค่อนข้างน้อย ราคาสปอตก็ร่วงลงจาก 1.00 ดอลลาร์เหลือ 0.65 ดอลลาร์ ระบบมาร์จิ้นซึ่งกำหนดค่าให้ทำเครื่องหมายหลักประกันกับราคาสปอต ได้ปรับมูลค่าสถานะทั้งหมดที่มีหลักประกันเป็น USDe ลดลง 35% ทำให้เกิดการเรียกมาร์จิ้นและบังคับให้ชำระบัญชีสำหรับบัญชีหลายพันบัญชี การชำระบัญชีเหล่านี้บังคับให้มีคำสั่งขายเพิ่มขึ้นในตลาดที่ไม่มีสภาพคล่องเดิม ทำให้ราคาตกต่ำลงอีก ระบบมาร์จิ้นสังเกตเห็นราคาที่ลดลงเหล่านี้และทำเครื่องหมายมูลค่าของสถานะเพิ่มเติม ซึ่งเป็นวงจรป้อนกลับที่เพิ่มแรงกดดันการขาย 60 ล้านดอลลาร์ให้กลายเป็นการบังคับชำระบัญชีมูลค่า 19.3 พันล้านดอลลาร์ รูปที่ 4: วงจรป้อนกลับของ Liquidation Chain แผนภาพวงจรป้อนกลับนี้แสดงให้เห็นถึงลักษณะการเสริมกำลังตนเองของห่วงโซ่: ราคาลดลง → กระตุ้นให้เกิดการชำระบัญชี → บังคับขาย → ราคาลดลงอีก → [วงจรซ้ำ] หากระบบ Oracle ที่ออกแบบมาอย่างเหมาะสม กลไกนี้จะใช้งานไม่ได้ หาก Binance ใช้ราคาเฉลี่ยถ่วงน้ำหนักตามเวลา (TWAP) ในหลายแพลตฟอร์มแลกเปลี่ยน การควบคุมราคาในทันทีจะไม่ส่งผลกระทบต่อการประเมินมูลค่าหลักประกัน หาก Binance ใช้ฟีดราคารวมจาก Chainlink หรือ Oracle หลายแหล่งอื่นๆ การโจมตีก็จะล้มเหลว เหตุการณ์ wBETH เมื่อสี่วันก่อนแสดงให้เห็นถึงช่องโหว่ที่คล้ายคลึงกัน wBETH ควรรักษาอัตราส่วนการแลกเปลี่ยน 1:1 กับ ETH ในระหว่างเหตุการณ์แบบเรียงซ้อน สภาพคล่องลดลง และตลาดสปอต wBETH/ETH ซื้อขายกันที่ส่วนลด 20% ระบบมาร์จิ้นจึงลดมูลค่าของหลักประกัน wBETH ลง ทำให้เกิดการชำระบัญชีของสถานะที่มี ETH เป็นหลักประกันอย่างเต็มประสิทธิภาพ

กลไกการลดหนี้อัตโนมัติ (ADL)

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

ในช่วงเหตุการณ์ Cascading ในเดือนตุลาคม Binance ได้ดำเนินการ ADL กับคู่ซื้อขายหลายคู่ เทรดเดอร์ที่ถือสถานะ Long ที่ทำกำไรได้พบว่าการซื้อขายของพวกเขาถูกบังคับให้ถูกขายออกไป ไม่ใช่เพราะความล้มเหลวในการบริหารความเสี่ยงของตนเอง แต่เป็นเพราะสถานะการถือครองของเทรดเดอร์รายอื่นล้มละลาย ADL สะท้อนถึงทางเลือกทางสถาปัตยกรรมพื้นฐานในการซื้อขายตราสารอนุพันธ์แบบรวมศูนย์ ตลาดแลกเปลี่ยนรับประกันตัวเองจากการขาดทุน ซึ่งหมายความว่าการขาดทุนจะต้องเป็นความรับผิดชอบของฝ่ายใดฝ่ายหนึ่งหรือมากกว่าต่อไปนี้: · กองทุนประกัน (กองทุนที่ตลาดแลกเปลี่ยนสำรองไว้เพื่อรองรับการขาดดุลจากการชำระบัญชี) · ADL (บังคับให้เทรดเดอร์ที่ทำกำไรได้ปิดสถานะ) · การขาดทุนแบบ Socialized (การแบ่งปันการขาดทุนระหว่างผู้ใช้ทั้งหมด)

ขนาดของกองทุนประกันเทียบกับขนาดของดอกเบี้ยเปิด (Open Interest) กำหนดความถี่ของ ADL กองทุนประกันของ Binance มีมูลค่ารวมประมาณ 2 พันล้านดอลลาร์สหรัฐในเดือนตุลาคม 2568 ซึ่งให้ความคุ้มครอง 50% เมื่อเทียบกับดอกเบี้ยเปิด 4 พันล้านดอลลาร์สหรัฐในสัญญา BTC, ETH และ BNB แบบไม่มีกำหนดระยะเวลา อย่างไรก็ตาม ในช่วงเหตุการณ์แบบเรียงซ้อนในเดือนตุลาคม มูลค่าเปิดของคู่ซื้อขายทั้งหมดสูงกว่า 2 หมื่นล้านดอลลาร์สหรัฐ กองทุนประกันไม่สามารถชดเชยส่วนที่ขาดได้

หลังจากเหตุการณ์แบบเรียงซ้อนในเดือนตุลาคม Binance ประกาศว่าจะรับประกัน ADL บนสัญญาซื้อขาย BTC, ETH และ BNB USDⓈ-M ตราบใดที่มูลค่าเปิดรวมยังคงต่ำกว่า 4 พันล้านดอลลาร์สหรัฐ สิ่งนี้สร้างโครงสร้างจูงใจ: ตลาดแลกเปลี่ยนสามารถรักษาเงินทุนประกันที่มากขึ้นเพื่อหลีกเลี่ยง ADL แต่เงินทุนนี้กลับถูกผูกมัดไว้ ซึ่งสามารถนำไปใช้ให้เกิดประโยชน์ได้

ความล้มเหลวบนเครือข่าย: ข้อจำกัดของโปรโตคอลบล็อกเชน

แผนภูมิแท่งเปรียบเทียบระยะเวลาหยุดทำงานในเหตุการณ์ต่างๆ:

· Solana (กุมภาพันธ์ 2024): 5 ชั่วโมง - ปัญหาคอขวดในการรับส่งข้อมูลการโหวต

· Polygon (มีนาคม 2024): 11 ชั่วโมง - เวอร์ชันตัวตรวจสอบไม่ตรงกัน

· Optimism (มิถุนายน 2024): 2.5 ชั่วโมง - Sequencer โอเวอร์โหลด (airdrop)

· Solana (กันยายน 2024): 4.5 ชั่วโมง - การโจมตีสแปมธุรกรรม

· Arbitrum (ธันวาคม 2024): 1.5 ชั่วโมง - ความล้มเหลวของผู้ให้บริการ RPC

รูปที่ 5: การหยุดให้บริการเครือข่ายหลัก - การวิเคราะห์ระยะเวลา

Solana: ปัญหาคอขวดตามมติ

Solana ประสบปัญหาการหยุดให้บริการหลายครั้งในช่วงปี 2024-2025 การหยุดให้บริการในเดือนกุมภาพันธ์ 2024 ใช้เวลาประมาณ 5 ชั่วโมง และในเดือนกันยายน 2024 นาน 4-5 ชั่วโมง การหยุดให้บริการเหล่านี้มีสาเหตุหลักที่คล้ายคลึงกัน นั่นคือ เครือข่ายไม่สามารถรองรับปริมาณธุรกรรมระหว่างการโจมตีด้วยสแปมหรือช่วงที่มีกิจกรรมรุนแรง

รายละเอียดรูปที่ 5: การหยุดให้บริการของ Solana (5 ชั่วโมงในเดือนกุมภาพันธ์, 4.5 ชั่วโมงในเดือนกันยายน) เน้นย้ำถึงปัญหาที่เกิดขึ้นซ้ำๆ เกี่ยวกับความยืดหยุ่นของเครือข่ายภายใต้สภาวะกดดัน

สถาปัตยกรรมของ Solana ได้รับการปรับให้เหมาะสมสำหรับปริมาณงาน ภายใต้สภาวะที่เหมาะสม เครือข่ายจะประมวลผลธุรกรรม 3,000-5,000 รายการต่อวินาทีด้วยความละเอียดขั้นสุดท้ายที่ต่ำกว่าวินาที ประสิทธิภาพนี้สูงกว่า Ethereum หลายเท่าตัว อย่างไรก็ตาม ในช่วงที่เกิดภาวะวิกฤต การเพิ่มประสิทธิภาพนี้จะสร้างช่องโหว่

การหยุดทำงานของเครือข่ายในเดือนกันยายน 2024 เกิดจากธุรกรรมขยะจำนวนมากที่ล้นหลามจนกลไกการลงคะแนนเสียงของตัวตรวจสอบ (validator) ทำงานหนักเกินไป ตัวตรวจสอบ Solana ต้องลงคะแนนเสียงในบล็อกเพื่อให้ได้ฉันทามติ ในระหว่างการดำเนินงานปกติ ตัวตรวจสอบจะให้ความสำคัญกับธุรกรรมการลงคะแนนเสียงเพื่อให้มั่นใจว่ากระบวนการลงคะแนนเสียงจะดำเนินไปอย่างราบรื่น อย่างไรก็ตาม ก่อนหน้านี้โปรโตคอลได้ปฏิบัติต่อธุรกรรมการลงคะแนนเสียงเหมือนธุรกรรมปกติสำหรับตลาดค่าธรรมเนียม

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

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

Ethereum: ค่าธรรมเนียมแก๊สพุ่งสูง

Ethereum เผชิญกับค่าธรรมเนียมแก๊สพุ่งสูงอย่างมากในช่วงที่ DeFi เฟื่องฟูในปี 2021 โดยการโอนแบบง่ายๆ มีค่าธรรมเนียมมากกว่า 100 ดอลลาร์สหรัฐ การโต้ตอบสัญญาอัจฉริยะที่ซับซ้อนมีค่าใช้จ่าย 500-1,000 ดอลลาร์สหรัฐ ค่าธรรมเนียมเหล่านี้ทำให้เครือข่ายไม่สามารถใช้งานได้สำหรับธุรกรรมขนาดเล็ก และทำให้เกิดการโจมตีแบบอื่น นั่นคือ การสกัด MEV

รูปที่ 7: ต้นทุนธุรกรรมระหว่างที่เกิดภาวะเครือข่ายตึงเครียด

แผนภูมิเส้นนี้แสดงให้เห็นการเพิ่มขึ้นของค่าธรรมเนียมแก๊สทั่วทั้งเครือข่ายอย่างชัดเจนระหว่างที่เกิดภาวะเครือข่ายตึงเครียด:

· Ethereum: $5 (ปกติ) → $450 (ช่วงที่มีการใช้งานหนาแน่นสูงสุด) - เพิ่มขึ้น 90 เท่า

· Arbitrum: $0.50 → $15 - เพิ่มขึ้น 30 เท่า

· มุมมองในแง่ดี: $0.30 → $12 - เพิ่มขึ้น 40 เท่า

ภาพที่แสดงแสดงให้เห็นว่าแม้แต่โซลูชันเลเยอร์ 2 ก็ประสบกับการเพิ่มขึ้นของค่าธรรมเนียมแก๊สอย่างมีนัยสำคัญ แม้ว่าจะมาจากจุดเริ่มต้นที่ต่ำกว่ามากก็ตาม มูลค่าสูงสุดที่สกัดได้ (MEV) หมายถึงกำไรที่ผู้ตรวจสอบสามารถสกัดได้โดยการเรียงลำดับใหม่ รวม หรือยกเว้นธุรกรรม MEV จะทำกำไรได้มากเป็นพิเศษในสภาพแวดล้อมที่มีค่าธรรมเนียมแก๊สสูง เหล่า Arbitrageurs จะแข่งขันกันเพื่อนำหน้าการซื้อขาย DEX ขนาดใหญ่ และบอทชำระบัญชีจะแข่งขันกันเพื่อเป็นคนแรกที่ชำระบัญชีสถานะที่มีหลักประกันไม่เพียงพอ การแข่งขันนี้ปรากฏให้เห็นในรูปแบบของสงครามการเสนอราคาแก๊ส ผู้ใช้ที่ต้องการให้แน่ใจว่าธุรกรรมของตนจะถูกรวมไว้ในช่วงที่มีความหนาแน่นสูงจะต้องเสนอราคาสูงกว่าบอท MEV ซึ่งจะสร้างสถานการณ์ที่ค่าธรรมเนียมธุรกรรมสูงกว่ามูลค่าของธุรกรรม ต้องการรับสิทธิ์ Airdrop มูลค่า 100 ดอลลาร์ของคุณหรือไม่? จ่ายค่าธรรมเนียมแก๊ส 150 ดอลลาร์ ต้องการเพิ่มหลักประกันเพื่อหลีกเลี่ยงการชำระบัญชีหรือไม่? แข่งขันกับบอทที่จ่ายค่าธรรมเนียมลำดับความสำคัญ 500 ดอลลาร์ ขีดจำกัดแก๊สของ Ethereum จำกัดปริมาณการคำนวณทั้งหมดต่อบล็อก ในช่วงที่มีความหนาแน่นสูง ผู้ใช้จะเสนอราคาเพื่อพื้นที่บล็อกที่หายาก ตลาดค่าธรรมเนียมทำงานตามที่ออกแบบไว้: ผู้เสนอราคาสูงสุดจะได้รับสิทธิ์ก่อน แต่การออกแบบนี้ทำให้เครือข่ายมีราคาแพงขึ้นในช่วงที่มีการใช้งานสูง ซึ่งเป็นช่วงเวลาที่ผู้ใช้จำเป็นต้องเข้าถึงมากที่สุด

โซลูชันเลเยอร์ 2 พยายามแก้ไขปัญหานี้โดยการย้ายการประมวลผลออกจากเชน พร้อมกับสืบทอดความปลอดภัยของ Ethereum ผ่านการชำระเงินเป็นระยะ Optimism, Arbitrum และ Rollup อื่นๆ ประมวลผลธุรกรรมหลายพันรายการนอกเชน แล้วส่งหลักฐานการบีบอัดไปยัง Ethereum สถาปัตยกรรมนี้ช่วยลดต้นทุนของแต่ละธุรกรรมระหว่างการดำเนินการปกติได้สำเร็จ

เลเยอร์ 2: ปัญหาคอขวดของ Sequencer

แต่โซลูชันเลเยอร์ 2 ก่อให้เกิดปัญหาคอขวดใหม่ Optimism ประสบปัญหาขัดข้องในเดือนมิถุนายน 2024 เมื่อที่อยู่ 250,000 ที่อยู่ถูกอ้างสิทธิ์ในการ Airdrop พร้อมกัน Sequencer ซึ่งเป็นส่วนประกอบที่สั่งธุรกรรมก่อนส่งไปยัง Ethereum มีปัญหาล้นมือ และผู้ใช้ไม่สามารถส่งธุรกรรมได้เป็นเวลาหลายชั่วโมง

การหยุดทำงานครั้งนี้แสดงให้เห็นว่าการย้ายการประมวลผลออกจากเชนไม่ได้ขจัดความต้องการด้านโครงสร้างพื้นฐาน ซีเควนเซอร์ต้องประมวลผลธุรกรรมขาเข้า สั่งการ ดำเนินการ และสร้างหลักฐานการฉ้อโกงหรือหลักฐาน ZK สำหรับการชำระเงินบน Ethereum ภายใต้ปริมาณการใช้งานที่สูงมาก ซีเควนเซอร์ต้องเผชิญกับความท้าทายด้านการปรับขนาดเช่นเดียวกับบล็อกเชนแบบสแตนด์อโลน ต้องมีผู้ให้บริการ RPC หลายราย หากผู้ให้บริการหลักล้มเหลว ผู้ใช้ควรเปลี่ยนผู้ให้บริการไปยังผู้ให้บริการอื่นได้อย่างราบรื่น ระหว่างการหยุดทำงานของ Optimism ผู้ให้บริการ RPC บางรายยังคงใช้งานได้ ในขณะที่บางรายล้มเหลว ผู้ใช้ที่ตั้งค่าวอลเล็ตเป็นผู้ให้บริการที่ล้มเหลวจะไม่สามารถโต้ตอบกับเชนได้ แม้ว่าเชนจะยังคงออนไลน์อยู่ก็ตาม การหยุดทำงานของ AWS ได้แสดงให้เห็นซ้ำแล้วซ้ำเล่าถึงความเสี่ยงด้านโครงสร้างพื้นฐานที่กระจุกตัวอยู่ในระบบนิเวศคริปโต: 20 ตุลาคม 2568 (ปัจจุบัน): การหยุดทำงานในภูมิภาคตะวันออกของสหรัฐอเมริกาส่งผลกระทบต่อ Coinbase รวมถึง Venmo, Robinhood และ Chime AWS ยอมรับว่าอัตราข้อผิดพลาดที่เพิ่มขึ้นสำหรับบริการ DynamoDB และ EC2

· เมษายน 2568: Binance, KuCoin และ MEXC เกิดการขัดข้องในภูมิภาคพร้อมกัน แพลตฟอร์มแลกเปลี่ยนหลักหลายแห่งไม่สามารถใช้งานได้เมื่อส่วนประกอบที่โฮสต์บน AWS ล้มเหลว

· ธันวาคม 2564: การขัดข้องในภูมิภาคตะวันออกของสหรัฐอเมริกาทำให้ Coinbase, Binance.US และแพลตฟอร์มแลกเปลี่ยนแบบกระจายศูนย์ dYdX หยุดชะงักเป็นเวลา 8-9 ชั่วโมง ส่งผลกระทบต่อคลังสินค้าและบริการสตรีมมิ่งหลักของ Amazon เอง

· มีนาคม 2560: การขัดข้องของ S3 ทำให้ผู้ใช้ไม่สามารถเข้าสู่ระบบ Coinbase และ GDAX ได้เป็นเวลาห้าชั่วโมง ประกอบกับอินเทอร์เน็ตขัดข้องเป็นวงกว้าง

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

Polygon: ความไม่ตรงกันของเวอร์ชันฉันทามติ

Polygon (เดิมชื่อ Matic) ประสบปัญหาการหยุดทำงานนานถึง 11 ชั่วโมงในเดือนมีนาคม 2024 สาเหตุหลักเกิดจากความไม่ตรงกันของเวอร์ชันตัวตรวจสอบ โดยตัวตรวจสอบบางรายใช้ซอฟต์แวร์เวอร์ชันเก่า และบางรายใช้เวอร์ชันที่อัปเกรด เวอร์ชันเหล่านี้คำนวณการเปลี่ยนสถานะแตกต่างกัน

รายละเอียดรูปที่ 5: การหยุดทำงานของ Polygon (11 ชั่วโมง) เป็นเหตุการณ์สำคัญที่ใช้เวลานานที่สุดที่วิเคราะห์ ซึ่งแสดงให้เห็นถึงความรุนแรงของความล้มเหลวของคอนเซนซัส

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

การแลกเปลี่ยนทางสถาปัตยกรรม

รูปที่ 6: Blockchain Trilemma - การกระจายอำนาจเทียบกับประสิทธิภาพ

ภาพกราฟแบบกระจายนี้แสดงแผนที่ระบบต่างๆ ออกเป็นสองมิติหลัก:

· Bitcoin: การกระจายอำนาจสูง ประสิทธิภาพต่ำ

· Ethereum: การกระจายอำนาจสูง ประสิทธิภาพปานกลาง

· Solana: การกระจายอำนาจปานกลาง ประสิทธิภาพสูง

· Binance (CEX): การกระจายอำนาจขั้นต่ำ ประสิทธิภาพสูงสุด

· Arbitrum/Optimism: การกระจายอำนาจระดับปานกลางถึงสูง ประสิทธิภาพปานกลาง

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

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

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

การเพิ่มแบบจำลองช่วยปรับปรุงความทนทานต่อความผิดพลาด แต่เพิ่มต้นทุนการประสานงาน ในระบบที่ทนทานต่อความผิดพลาดแบบไบแซนไทน์ ตัวตรวจสอบความถูกต้องที่เพิ่มเข้ามาแต่ละตัวจะเพิ่มค่าใช้จ่ายในการสื่อสาร สถาปัตยกรรมที่มีปริมาณงานสูงช่วยลดค่าใช้จ่ายนี้ด้วยการสื่อสารของตัวตรวจสอบความถูกต้องที่ได้รับการปรับแต่งให้เหมาะสมที่สุด ทำให้ได้ประสิทธิภาพที่เหนือกว่าแต่มีความเสี่ยงต่อรูปแบบการโจมตีบางรูปแบบ สถาปัตยกรรมที่เน้นความปลอดภัยให้ความสำคัญกับความหลากหลายของตัวตรวจสอบความถูกต้องและความทนทานตามฉันทามติ ซึ่งจำกัดปริมาณงานของเลเยอร์พื้นฐาน พร้อมกับเพิ่มความยืดหยุ่นสูงสุด โซลูชันเลเยอร์ 2 พยายามมอบคุณสมบัติทั้งสองผ่านการออกแบบแบบเลเยอร์ พวกเขาสืบทอดคุณสมบัติด้านความปลอดภัยของ Ethereum ผ่านการชำระเงินเลเยอร์ 1 พร้อมกับให้ปริมาณงานสูงผ่านการประมวลผลแบบออฟเชน อย่างไรก็ตาม พวกเขาสร้างปัญหาคอขวดใหม่ที่เลเยอร์ซีเควนเซอร์และเลเยอร์ RPC ซึ่งแสดงให้เห็นว่าความซับซ้อนของสถาปัตยกรรมสร้างโหมดความล้มเหลวแบบใหม่พร้อมกับแก้ไขปัญหาบางอย่าง การปรับขนาดยังคงเป็นปัญหาพื้นฐาน เหตุการณ์เหล่านี้เผยให้เห็นรูปแบบที่สอดคล้องกัน นั่นคือ ระบบได้รับทรัพยากรสำหรับโหลดปกติ จากนั้นก็ล้มเหลวอย่างรุนแรงภายใต้แรงกดดัน Solana จัดการปริมาณการใช้งานปกติได้อย่างมีประสิทธิภาพ แต่ล้มเหลวเมื่อปริมาณธุรกรรมเพิ่มขึ้น 10,000% ค่าธรรมเนียมแก๊สของ Ethereum ยังคงอยู่ในระดับที่สมเหตุสมผลจนกระทั่งการนำ DeFi มาใช้ทำให้เกิดความแออัด โครงสร้างพื้นฐานของ Optimism ยังคงทำงานได้ดีจนกระทั่งมีที่อยู่ถึง 250,000 ที่อยู่ได้อ้างสิทธิ์ในการ Airdrop พร้อมกัน API ของ Binance ทำงานได้ตามปกติในระหว่างการซื้อขายปกติ แต่ถูกจำกัดปริมาณในช่วงการชำระบัญชีแบบต่อเนื่อง เหตุการณ์ในเดือนตุลาคม 2025 แสดงให้เห็นถึงพลวัตนี้ในระดับการแลกเปลี่ยน ในระหว่างการดำเนินงานปกติ ขีดจำกัดอัตรา API และการเชื่อมต่อฐานข้อมูลของ Binance เพียงพอ แต่ในช่วงการชำระบัญชีแบบต่อเนื่อง เมื่อเทรดเดอร์ทุกคนพยายามปรับสถานะของตนพร้อมกัน ขีดจำกัดเหล่านี้กลายเป็นคอขวด ระบบมาร์จิ้นที่ออกแบบมาเพื่อป้องกันการแลกเปลี่ยนจากการบังคับชำระบัญชี ได้ทำให้วิกฤตรุนแรงขึ้นโดยการสร้างผู้ขายแบบบังคับในช่วงเวลาที่เลวร้ายที่สุด การปรับขนาดอัตโนมัติให้การป้องกันที่ไม่เพียงพอต่อการเพิ่มขึ้นของภาระงานแบบฟังก์ชันขั้นตอน การเพิ่มเซิร์ฟเวอร์เพิ่มเติมใช้เวลาเพียงไม่กี่นาที และในช่วงเวลาดังกล่าว ระบบมาร์จิ้นได้ทำเครื่องหมายมูลค่าสถานะโดยอ้างอิงจากข้อมูลราคาที่เสียหายจากสมุดคำสั่งซื้อขนาดเล็ก เมื่อกำลังการผลิตใหม่พร้อมใช้งาน ปฏิกิริยาลูกโซ่ก็ได้แพร่กระจายไปแล้ว การจัดเตรียมทรัพยากรมากเกินไปสำหรับเหตุการณ์ตึงเครียดที่เกิดขึ้นน้อยครั้งทำให้ต้นทุนลดลงในระหว่างการดำเนินการตามปกติ ผู้ให้บริการแลกเปลี่ยนปรับแต่งให้เหมาะสมกับภาระงานทั่วไป โดยยอมรับความล้มเหลวเป็นครั้งคราวเป็นทางเลือกที่คุ้มค่าทางเศรษฐกิจ ต้นทุนจากการหยุดทำงานจะถูกโอนไปยังผู้ใช้ภายนอก ซึ่งต้องเผชิญกับการถูกขายกิจการ การซื้อขายติดขัด หรือไม่สามารถเข้าถึงเงินทุนได้ในช่วงที่ตลาดมีการเคลื่อนไหวสำคัญ

การปรับปรุงโครงสร้างพื้นฐาน

รูปที่ 8: การกระจายตัวของรูปแบบความล้มเหลวของโครงสร้างพื้นฐาน (2024-2025)

แผนภูมิวงกลมที่แจกแจงสาเหตุหลักแสดงให้เห็นว่า:

· โครงสร้างพื้นฐานโอเวอร์โหลด: 35% (พบมากที่สุด)

· ความแออัดของเครือข่าย: 20%

· ความล้มเหลวของการบรรลุฉันทามติ: 18%

· การจัดการ Oracle: 12%

· ปัญหาของตัวตรวจสอบ: 10%

· ช่องโหว่ของสัญญาอัจฉริยะ: 5%

การเปลี่ยนแปลงสถาปัตยกรรมหลายอย่างอาจลดความถี่และความรุนแรงของความล้มเหลว แม้ว่าแต่ละอย่างจะต้องมีการแลกเปลี่ยน:

การแยกระบบกำหนดราคาและการหักบัญชี

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

การจัดเตรียมทรัพยากรมากเกินไปและโครงสร้างพื้นฐานที่ซ้ำซ้อน

การหยุดให้บริการของ AWS ในเดือนเมษายน 2568 ซึ่งส่งผลกระทบต่อ Binance, KuCoin และ MEXC แสดงให้เห็นถึงความเสี่ยงของการพึ่งพาโครงสร้างพื้นฐานแบบรวมศูนย์ การรันส่วนประกอบที่สำคัญบนผู้ให้บริการคลาวด์หลายรายจะเพิ่มความซับซ้อนและต้นทุนในการดำเนินงาน แต่ช่วยลดความล้มเหลวที่สัมพันธ์กัน เครือข่ายเลเยอร์ 2 สามารถรักษาผู้ให้บริการ RPC หลายรายด้วย Failover อัตโนมัติ ค่าใช้จ่ายเพิ่มเติมอาจดูเหมือนสิ้นเปลืองในระหว่างการดำเนินการตามปกติ แต่ช่วยป้องกันการหยุดทำงานหลายชั่วโมงในช่วงที่มีความต้องการใช้งานสูงสุด

การทดสอบความเครียดและการวางแผนกำลังการผลิตขั้นสูง

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

หนทางข้างหน้า

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

แรงกดดันจากหน่วยงานกำกับดูแลอาจบังคับให้เกิดการเปลี่ยนแปลง หากกฎระเบียบกำหนดระยะเวลาใช้งานสูงสุด 99.9% หรือจำกัดระยะเวลาหยุดทำงานที่ยอมรับได้ แพลตฟอร์มการซื้อขายจะต้องจัดเตรียมทรัพยากรสำรองไว้มากเกินไป แต่กฎระเบียบมักจะตามมาหลังจากภัยพิบัติ ไม่ใช่ป้องกันภัยพิบัติ การล่มสลายของ Mt. Gox ในปี 2014 นำไปสู่กฎระเบียบอย่างเป็นทางการสำหรับแพลตฟอร์มการซื้อขายสกุลเงินดิจิทัลในญี่ปุ่น ปฏิกิริยาลูกโซ่ของเหตุการณ์ในเดือนตุลาคม 2025 น่าจะกระตุ้นให้เกิดการตอบสนองของหน่วยงานกำกับดูแลที่คล้ายคลึงกัน ยังไม่แน่ชัดว่าการตอบสนองเหล่านี้จะระบุผลลัพธ์ (ระยะเวลาหยุดทำงานสูงสุดที่ยอมรับได้, อัตราการลื่นไถลสูงสุดระหว่างการชำระบัญชี) หรือวิธีการนำไปใช้งาน (ผู้ให้บริการ Oracle เฉพาะราย, เกณฑ์เซอร์กิตเบรกเกอร์) ความท้าทายพื้นฐานคือระบบเหล่านี้ทำงานอย่างต่อเนื่องในตลาดโลก แต่พึ่งพาโครงสร้างพื้นฐานที่ออกแบบมาสำหรับเวลาทำการแบบดั้งเดิม เมื่อเกิดความเครียดในเวลา 02:00 น. ทีมงานจะรีบหาทางแก้ไขปัญหาในขณะที่ผู้ใช้ต้องเผชิญกับความสูญเสียที่เพิ่มขึ้น ตลาดแบบดั้งเดิมจะหยุดการซื้อขายในช่วงที่มีความเครียด ตลาดสกุลเงินดิจิทัลจะล่มสลายทันที ไม่ว่าสิ่งนี้จะเป็นคุณสมบัติหรือข้อบกพร่องขึ้นอยู่กับมุมมอง ระบบบล็อกเชนประสบความสำเร็จในความซับซ้อนทางเทคนิคอย่างน่าทึ่งในช่วงเวลาสั้นๆ การรักษาฉันทามติแบบกระจายศูนย์ระหว่างโหนดหลายพันโหนดถือเป็นความสำเร็จทางวิศวกรรมที่แท้จริง แต่การบรรลุความน่าเชื่อถือภายใต้สภาวะกดดันนั้นจำเป็นต้องก้าวข้ามสถาปัตยกรรมต้นแบบไปสู่โครงสร้างพื้นฐานระดับการใช้งานจริง การเปลี่ยนแปลงนี้จำเป็นต้องอาศัยเงินทุนและการให้ความสำคัญกับความทนทานมากกว่าความเร็วในการพัฒนาฟีเจอร์

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

ลิงก์ต้นฉบับ

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia