Ethereum เตือนเทสต์เน็ต Glamsterdam เสี่ยงถูก Builder โจมตี
cryptonewsบันทึกการประชุม All Core Developers Consensus ของ Ethereum เมื่อวันที่ 17 ก.ย. แสดงให้เห็นว่าผู้เข้าร่วมยอมรับวันที่ 6 ต.ค. หลังจากทบทวนผลลัพธ์ล่าสุดของ Devnet Glamsterdam แม้ว่านักพัฒนาจะแสดงความกังวลพร้อมกันว่า Enshrined Proposer-Builder Separation (ePBS, การแยกผู้เสนอและผู้สร้างบล็อกแบบฝังในโปรโตคอล) อาจมีพฤติกรรมอย่างไรบนเครือข่ายสาธารณะที่ ETH สำหรับทดสอบไม่มีต้นทุนทางเศรษฐกิจที่มีนัยสำคัญ
หัวใจของคำเตือนคือ EIP-7732 ซึ่งเป็นการออกแบบ Enshrined Proposer-Builder Separation ของ Glamsterdam Ethereum.org อธิบายว่า ePBS คือการเปลี่ยนแปลงโปรโตคอลที่แยกงานประกอบ payload ธุรกรรมออกจากหน้าที่ฉันทามติของผู้ตรวจสอบ โดยย้ายความสัมพันธ์ที่ปัจจุบันพึ่งพาโครงสร้างพื้นฐานภายนอกอย่างมากเข้ามาอยู่ในกฎฉันทามติของ Ethereum
ภายใต้การออกแบบนี้ Builder (ผู้สร้างบล็อก) สามารถยื่นประมูลเพื่อสิทธิ์ในการจัดหา execution payload (เพย์โหลดการประมวลผล) เมื่อผู้เสนอ commit กับราคาประมูลที่ชนะแล้ว Builder ถูกคาดหวังให้เปิดเผยธุรกรรมที่อยู่เบื้องหลัง ข้อกำหนดฉันทามติของ Ethereum กำหนดให้ Builder เป็นผู้มีส่วนได้ส่วนเสียที่แยกต่างหากซึ่งยื่นประมูล execution payload ที่ลงนามแล้วก่อนที่จะกระจาย payload envelope (ซองเพย์โหลด) ที่เกี่ยวข้อง
ระหว่างการประชุมนักพัฒนาเมื่อวันพฤหัสบดี Potuz นักพัฒนาฉันทามติเตือนว่าเศรษฐศาสตร์บนเทสต์เน็ตเปลี่ยนไปเพราะผู้โจมตีสามารถรับ ETH สำหรับทดสอบได้โดยไม่ต้องจ่ายมูลค่าตลาดบนเมนเน็ต ผู้ดำเนินการที่เป็นอันตรายสามารถสร้างตัวตน Builder จำนวนมาก ยื่นประมูลสูงกว่าคู่แข่งที่ถูกต้องตามกฎหมายอย่างมาก แล้วปฏิเสธที่จะให้ payload ตามสัญญาหลังจากชนะ
“ฉันสามารถสร้าง Builder ขึ้นมาเป็นพันรายการได้เลย” Potuz กล่าว พร้อมอธิบายว่าผู้โจมตีสามารถหมุนเวียนพวกมัน ประมูลอย่างดุดัน และระงับ payload ได้ ต่อมาเขาเสริมว่า “วัยรุ่นคนไหนก็ทำได้”
นักพัฒนารายนี้วางกรอบความกังวลว่าเป็นปัญหาความพร้อมใช้งานของเทสต์เน็ตสาธารณะ ไม่ใช่ช่องทางใหม่ในการขโมย ETH บนเมนเน็ต บนเมนเน็ต ผู้เข้าร่วมสามารถจ่ายเงินเพื่อสร้างบล็อกเปล่าได้อยู่แล้ว แต่ต้นทุนทางเศรษฐกิจในการได้พื้นที่บล็อกจำกัดพฤติกรรมดังกล่าว ETH สำหรับทดสอบทำให้การก่อกวนต่อเนื่องมีราคาถูกลงมาก
ไคลเอนต์อาจต้องมีเซอร์กิตเบรกเกอร์ระดับ Builder
มาตรการป้องกันที่มีอยู่อาจไม่เพียงพอสำหรับสภาพแวดล้อม Sepolia Potuz บอกนักพัฒนาว่าเซอร์กิตเบรกเกอร์ (กลไกตัดวงจร) ของไคลเอนต์บางตัวจะถอยกลับไปใช้บล็อกที่สร้างในเครื่องหลังจากพลาด payload หลายครั้งเท่านั้น และเขาไม่ทราบว่ามีการป้องกันสากลที่สามารถปฏิเสธ Builder ที่ละเมิดเป็นรายบุคคลได้หรือไม่
ความกังวลของเขามุ่งเน้นไปที่ผู้โจมตีที่กลับมาภายใต้ตัวตนใหม่ แม้ว่าไคลเอนต์จะตอบสนองต่อ payload ที่หายไป Builder ที่ใช้ครั้งเดียวแล้วทิ้งก็ยังสามารถประมูลต่อไปได้ เว้นแต่ตรรกะการป้องกันจะระบุและจำกัดพฤติกรรมได้เร็วพอ
นักพัฒนาไม่ได้นำเสนอการโจมตีของ Builder ว่าเป็นช่องโหว่ที่ยืนยันแล้วต่อ Sepolia การอภิปรายเกี่ยวข้องกับสถานการณ์ที่พวกเขาคาดว่าการทดสอบสาธารณะอาจเปิดเผยเมื่อบุคคลภายนอกสามารถเข้าร่วมได้ภายใต้เงื่อนไข ePBS Potuz โต้แย้งว่าเทสต์เน็ตของ Ethereum ต้องการมาตรการป้องกันที่แข็งแกร่งขึ้น เนื่องจากทีมแอปพลิเคชันและโครงสร้างพื้นฐานพึ่งพาพวกมันในการทดสอบซอฟต์แวร์กับบล็อกที่ทำงานได้
Ethereum.org ระบุว่า Sepolia ใช้ชุดผู้ตรวจสอบความถูกต้อง (validator) ที่ได้รับอนุญาตซึ่งควบคุมโดยทีมไคลเอนต์และทีมทดสอบ ในขณะที่ Hoodi มีชุดผู้ตรวจสอบความถูกต้องแบบเปิดสำหรับการทดสอบการ stake และโปรโตคอล โครงสร้างของ Sepolia ช่วยให้นักพัฒนา Ethereum ควบคุมการปฏิบัติงานได้มากขึ้น หากการปรับใช้ Glamsterdam สาธารณะระยะยาวครั้งแรกประสบปัญหา
ตามที่ crypto.news รายงานก่อนหน้านี้ นักพัฒนาได้เลือกวันที่ 6 ต.ค. ไว้ชั่วคราวก่อนการประชุมล่าสุด โดยวันที่ยังขึ้นอยู่กับการเปลี่ยนผ่าน Devnet ส่วนตัวที่เสถียรอีกครั้ง การประชุมฉันทามติเมื่อวันที่ 17 ก.ย. ได้เลื่อนกำหนดการดังกล่าวให้เร็วขึ้นหลังจาก Devnet-11 เสร็จสิ้นการซ้อม fork ตามกำหนด
Devnet-11 ทดสอบแก๊ส 200 ล้านก่อน Sepolia
Glamsterdam Devnet-11 ถูกสร้างขึ้นเพื่อเป็นการซ้อม "เส้นทางปกติ (happy-path)" ที่ควบคุมได้ มากกว่าเครือข่ายโจมตีเชิงปฏิปักษ์ ข้อกำหนดอย่างเป็นทางการกำหนด genesis ในวันที่ 14 ก.ย. การเปลี่ยนผ่าน Gloas ในวันที่ 16 ก.ย. และการเพิ่มขีดจำกัดแก๊สของบล็อกจาก 60 ล้านเป็น 200 ล้านไม่นานหลังจากนั้น
เครือข่ายทดสอบใช้ผู้ตรวจสอบความถูกต้อง 84,000 รายในการกำหนดค่าแบบหลายไคลเอนต์ และใช้ชุด EIP หลักเดียวกันกับที่วางแผนไว้สำหรับการทดสอบ Glamsterdam ผู้จัดงานได้แยกการโจมตีโดยเจตนาออกจากขอบเขตของ Devnet-11 อย่างชัดเจน โดยเก็บการทดลองเชิงปฏิปักษ์ไว้ในสภาพแวดล้อม Platåberget ที่ทำงานยาวนานกว่า
CoinDesk รายงานว่า Devnet-11 เสร็จสิ้นการเปลี่ยนผ่านและเพิ่มขีดจำกัดแก๊สไปที่ 200 ล้านโดยไม่สูญเสีย finality (ความสมบูรณ์ขั้นสุดท้าย) การตั้งค่า 200 ล้านเป็นพารามิเตอร์ทดสอบ ไม่ใช่การยืนยันขีดจำกัดแก๊สของเมนเน็ต
โรดแมป Glamsterdam ของ Ethereum เองระบุว่าการอัปเกรดได้รับการออกแบบเพื่อเพิ่มความจุของ Layer 1 (เลเยอร์ 1) ในขณะที่เปลี่ยนวิธีการสร้างและตรวจสอบบล็อก EIP-7732 ขยายหน้าต่างการกระจาย execution payload จากประมาณสองวินาทีเป็นประมาณเก้าวินาที ทำให้โหนดมีเวลามากขึ้นในการกระจายและตรวจสอบ payload ที่ใหญ่ขึ้น
การอัปเกรดยังรวมถึง Block-Level Access Lists (รายการเข้าถึงระดับบล็อก) และการเปลี่ยนแปลงราคาแก๊สอีกหลายรายการ รายงานความเข้ากันได้ของ Glamsterdam ก่อนหน้านี้ระบุว่ากระเป๋าเงิน อินเด็กเซอร์ และตัวประมาณแก๊สที่ใช้สมมติฐานคงที่อาจต้องมีการเปลี่ยนแปลง เนื่องจากการสร้างบัญชีใหม่และการดำเนินการที่ใช้สถานะหนักบางอย่างได้รับการปฏิบัติด้านแก๊สที่แตกต่างกันภายใต้ fork ที่วางแผนไว้
การตรวจสอบความเสี่ยงของสัญญาอัจฉริยะแยกต่างหากพบว่าสัญญาที่ใช้ค่าแก๊สคงที่ (gas stipend) หรือรูปแบบการดำเนินการที่ไวต่อแก๊สอาจต้องมีการทดสอบก่อนที่การอัปเกรดจะไปถึงเมนเน็ต
หน้าต่างการตรวจสอบไคลเอนต์ Sepolia ลดลงเหลือเจ็ดวัน
กำหนดการวันที่ 6 ต.ค. ทำให้ทีมไคลเอนต์มีเวลาตรวจสอบน้อยกว่าที่กระบวนการอัปเกรดปกติของ Ethereum แนะนำ
ระหว่างการประชุมวันที่ 17 ก.ย. นักพัฒนา Fredrik Svantes บอกผู้เข้าร่วมว่ากระบวนการมาตรฐานกำหนดให้มีอย่างน้อย 14 วันระหว่างซอฟต์แวร์ไคลเอนต์ที่พร้อมเปิดตัวกับการเปิดใช้งานเทสต์เน็ตสาธารณะครั้งแรก เขากล่าวว่าสองสัปดาห์นั้นปกติใช้สำหรับการตรวจสอบความปลอดภัยภายใน การเปิดรับ bug bounty (โปรแกรมรางวัลสำหรับการรายงานบั๊ก) และงานรักษาความปลอดภัยภายนอกที่เป็นไปได้
เมื่อ Sepolia ใกล้เข้ามา นักพัฒนาหารือถึงวันที่ 29 ก.ย. เป็นวันล่าสุดสำหรับการเปิดตัวไคลเอนต์ เจ็ดวันระหว่างวันที่ 29 ก.ย. ถึง 6 ต.ค. จะเหลือครึ่งหนึ่งของระยะเวลาตรวจสอบปกติ ผู้เข้าร่วมยอมรับความเสี่ยงนั้นสำหรับ Sepolia ส่วนหนึ่งเพราะชุดผู้ตรวจสอบความถูกต้องค่อนข้างรวมศูนย์ และเครือข่ายสามารถกู้คืนได้ง่ายกว่าหากซอฟต์แวร์เสียหาย
Alex Stokes นักพัฒนาหลักกระตุ้นให้ทีมต่างๆ เปิดตัวซอฟต์แวร์เร็วขึ้นหากเป็นไปได้ เพื่อให้ผู้ตรวจสอบจำนวนมากขึ้นสามารถตรวจสอบได้ เมื่อไคลเอนต์ที่พร้อมเปิดตัวพร้อมใช้งาน พวกมันสามารถเข้าสู่กระบวนการ bug bounty ของ Ethereum ได้ทันที
กำหนดการที่บีบอัดตามมาหลังจากปัญหาการทดสอบหลายครั้งก่อนหน้านี้ วาระการประชุมนักพัฒนาวันที่ 3 ก.ย. บันทึกการไม่บรรลุ finality ระหว่างการเปิดใช้งาน Gloas ของ Devnet-8 ซึ่งส่งผลกระทบต่อไคลเอนต์ฉันทามติหลายตัว ในขณะที่การทดสอบ Devnet ในภายหลังตรวจสอบการแก้ไขและกรณีขอบเพิ่มเติม
การประชุมทดสอบอีกครั้งบันทึกปัญหาที่สถานการณ์ Platåberget ทำให้โหนด Besu 12 จาก 13 โหนดออฟไลน์ และทำให้โหนด Erigon และ Ethrex ช้าลง Devnet-9 ประสบกับการไม่บรรลุ finality ที่ไม่ได้วางแผนไว้ ผลักดันให้ทีมต้องทำซ้ำเพิ่มเติมก่อน Devnet-11
การเปิดใช้งานเมนเน็ตยังไม่มีวันที่ยืนยัน
โรดแมปสาธารณะของ Ethereum ยังคงระบุ Glamsterdam สำหรับไตรมาสที่สี่ของปี 2026 แต่ระบุว่าวันที่เมนเน็ตยังไม่ได้รับการยืนยัน เหตุการณ์สำคัญถัดไปที่เผยแพร่คือ fork Sepolia ในวันที่ 6 ต.ค.
คาดว่า Hoodi จะตามหลัง Sepolia เนื่องจากมีสภาพแวดล้อมผู้ตรวจสอบความถูกต้องแบบเปิดสำหรับการทดสอบการ stake และการอัปเกรด นักพัฒนาหารือถึงขั้นตอน Hoodi ระหว่างการประชุมวันที่ 17 ก.ย. แต่ผูกเวลากับความคืบหน้าของ Sepolia หมายความว่าปัญหาบนเทสต์เน็ตสาธารณะแรกอาจเลื่อนวันที่ถัดไป
ร่างแผนตอบสนองเหตุการณ์บนเมนเน็ตของ Ethereum ยังไม่มี epoch (รอบเวลา) หรือ timestamp (เวลาประทับ) การเปิดใช้งาน เอกสารดังกล่าวปล่อยให้ช่องข้อมูลการอัปเกรดว่างเปล่า ในขณะที่แสดงรายการบทบาทไคลเอนต์และการประสานงานที่จะถูกเติมเต็มก่อนการปรับใช้เมนเน็ต
ตามที่รายงานข่าว Glamsterdam ของ crypto.news ก่อนหน้านี้ การอัปเกรดมุ่งเน้นที่ ePBS, Block-Level Access Lists และการปรับราคาแก๊สที่ออกแบบมาเพื่อปริมาณงาน Layer 1 ที่สูงขึ้น นักพัฒนายังคงถือว่าการทดสอบหลายไคลเอนต์ที่ประสบความสำเร็จเป็นข้อกำหนดเบื้องต้นก่อนกำหนด fork เมนเน็ต
สำหรับตอนนี้ ทีมไคลเอนต์เผชิญกับกำหนดเส้นตายซอฟต์แวร์วันที่ 29 ก.ย. ที่หารือในการประชุม ตามด้วยการเปิดใช้งาน Sepolia ในวันที่ 6 ต.ค. นักพัฒนา Ethereum ยังไม่ได้เผยแพร่ epoch เมนเน็ตหรือ timestamp การเปิดใช้งานขั้นสุดท้าย
เนื้อหานี้จัดทำขึ้นโดยมีวัตถุประสงค์เพื่อแจ้งข้อมูลและให้ความรู้เท่านั้น และไม่ถือว่าเป็นคำแนะนำด้านการลงทุนที่เกี่ยวข้องกับ BTCC แต่อย่างใด BTCC ใช้ความพยายามอย่างเต็มที่ แต่ไม่สามารถรับประกันความจริงแท้ ความถูกต้อง หรือความเป็นต้นฉบับของเนื้อหาข้างต้นได้