วิศวกรของ Lido เตือนถึงความเสี่ยงการถูกขโมยการฝากการstaking ระหว่างการเปลี่ยนผ่านของ Ethereum สู่ Glamsterdam

2026/10/21 14:09:00

เหตุผลที่นักพัฒนา Ethereum ปฏิเสธการแก้ไขระดับโปรโตคอล

การอัปเกรดเครือข่ายครั้งใหญ่ครั้งต่อไปของ Ethereum มีเป้าหมายเพื่อขยายฐานล่างผ่านการแยกผู้เสนอและผู้สร้างอย่างเป็นทางการ และการเพิ่มขีดจำกัดแก๊ส อย่างไรก็ตาม ช่องโหว่ที่เกี่ยวข้องกับเวลาได้ดึงดูดความสนใจจากผู้ให้บริการ liquid staking รายใหญ่ที่สุดรายหนึ่ง เมื่อวันที่ 20 ตุลาคม 2026 ดิมา กูซาคอฟ หัวหน้าฝ่ายวิศวกรรมของ Lido Finance ได้เปิดเผยอย่างเปิดเผยว่า การเปลี่ยนผ่านสู่ Glamsterdam อาจอนุญาตให้ผู้ดำเนินการโหนดที่มีเจตนาไม่ดีสามารถ front-run การฝาก validator ของผู้ staker การโจมตีจะใช้การฝากจาก builder ที่มีข้อมูลการถอนที่ขึ้นต้นด้วย 0xB0 ซึ่งแบ่งปันคิวการฝากชั่วคราว อาจทำให้ ETH ถูกเครดิตไปยังบัญชีของ builder แทนที่จะเปิดใช้งาน validator ที่ตั้งใจไว้ ช่วงเวลาที่เสี่ยงนี้จำกัดอยู่เฉพาะในช่วงการเปลี่ยนผ่าน hard-fork เท่านั้น หลังจากการอัปเกรด การฝากจาก builder จะถูกส่งไปยังเส้นทางสัญญาที่แยกต่างหาก

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

หัวหน้าทีมวิศวกรรม Lido ระบุช่องโหว่การซื้อล่วงหน้าบน X และในการประชุมนักพัฒนา

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

ความกังวลเดียวกันนี้ปรากฏขึ้นในการประชุม All Core Devs Consensus (ACDC #189) Gusakov ชี้ให้เห็นว่ากลไกการลงทะเบียนผู้สร้างแบบครั้งเดียวของ Glamsterdam อาจรบกวนรูปแบบการป้องกันการฝากที่โปรโตคอลการสแตกคิงเคยพึ่งพาเป็นเวลานาน ภายใต้กฎปัจจุบัน การฝากครั้งแรกที่ถูกต้องสำหรับกุญแจสาธารณะจะกำหนดข้อมูลการถอนอย่างถาวร โปรโตคอลมักจะฝากจำนวนเล็กน้อยก่อน ยืนยันว่าข้อมูลที่คาดหวังปรากฏขึ้น และจึงเติมยอดคงเหลือที่เหลือเท่านั้น ในระหว่างการเปลี่ยนผ่าน Fork เส้นทางการลงทะเบียนพิเศษนี้สามารถสร้างผลลัพธ์ที่สามได้: ไม่มีตัวตรวจสอบใดเปิดใช้งาน และการฝากทั้งหมดจะถูกกำหนดให้กับผู้สร้าง นักพัฒนาหลักปฏิเสธการเปลี่ยนแปลงข้อกำหนดในขั้นสุดท้ายที่จะรักษาความแตกต่างระหว่างการฝากของตัวตรวจสอบและผู้สร้างในระหว่างการลงทะเบียนแบบครั้งเดียว โดยอ้างว่า Sepolia ได้เปิดใช้งานไปแล้วภายใต้กฎปัจจุบัน และการปล่อยตัว Hoodi อยู่ในขั้นเตรียมการแล้ว การเปลี่ยนพฤติกรรมในขั้นตอนนั้นจะต้องมีการปรับใช้ Sepolia ใหม่และรอบการทดสอบเพิ่มเติม

วิธีที่ข้อมูลรับรองของ 0xB0 Builder ทำงานร่วมกับคิวการฝากแบบร่วม

Glamsterdam แนะนำการฝากแบบ builder เป็นส่วนหนึ่งของการเปลี่ยนไปสู่การแยกผู้เสนอและผู้สร้างอย่างเป็นทางการ การฝากเหล่านี้มีข้อมูลการถอนที่เริ่มต้นด้วยรหัส 0xB0 ซึ่งแยกต่างหากจากข้อมูลการรับรองของ validator ทั่วไป ในช่วงการเปลี่ยนผ่าน ประเภทการฝากทั้งสองประเภทจะใช้เส้นทางการประมวลผลคิวเดียวกัน ดังนั้น ผู้ดำเนินการโหนดที่ควบคุมหรือสามารถมีอิทธิพลต่อลำดับการส่งการฝาก จึงสามารถแทรกการฝากที่มีข้อมูลการรับรองของ builder ที่ตรงกับกุญแจสาธารณะของผู้staking ที่ยังค้างอยู่ เมื่อการฝากแรกได้รับการยอมรับ เครือข่ายจะถือว่ากุญแจสาธารณะนั้นถูกยึดถือภายใต้ข้อมูลการรับรองของ builder การฝากเพิ่มเติมภายใต้กุญแจเดียวกันจะถูกละเว้นสำหรับการเปิดใช้งาน validator หรือถูกเปลี่ยนเส้นทางตามกฎการตีความใหม่ที่ใช้บริเวณขอบเขตของ Fork

ผลที่เกิดขึ้นจริงคือผู้staking สูญเสียทั้งตัวผู้ตรวจสอบที่คาดหวังและ ETH ที่ฝากไว้ ซึ่งตอนนี้อยู่ภายใต้การควบคุมของผู้สร้าง ตัวตรวจสอบที่เปิดใช้งานอยู่แล้วและการฝากที่ผ่านการประมวลผลแล้วไม่ได้รับผลกระทบ ความเสี่ยงนี้จำกัดอยู่ที่การฝากใหม่หรือการฝากที่ยังอยู่ในคิวซึ่งข้ามช่วงเวลาการเปิดใช้งาน เนื่องจากพฤติกรรมคิวร่วมจะสิ้นสุดลงเมื่อ Fork เสร็จสิ้นและเงินฝากของผู้สร้างจะถูกย้ายไปยังสัญญาเฉพาะของตนเอง จึงทำให้ความเสี่ยงนี้มีลักษณะชั่วคราว ลักษณะชั่วคราวนี้เป็นเหตุผลหลักที่ Gusakov แนะนำให้หลีกเลี่ยงความตื่นตระหนก แต่ยังเรียกร้องให้บริการ staking แบบมอบอำนาจทุกแห่งดำเนินการหรือเสริมการตรวจสอบก่อนการฝากก่อนการเปิดใช้งาน Mainnet

นักพัฒนาหลักปิดข้อเสนอ Consensus-Specs ว่าไม่ได้วางแผน

การอภิปรายเชิงเทคนิคเกี่ยวกับวิธีแก้ไขระดับโปรโตคอลปรากฏในปัญหา consensus-specs หมายเลข #5735 ข้อเสนอเรียกร้องให้มีการตรวจสอบก่อนการฝาก เพื่อยืนยันเงื่อนไขบางประการก่อนที่จะรับการฝากเข้าคิว หลังจากการทบทวน ปัญหานี้ถูกปิดด้วยสถานะ “ไม่ได้วางแผน” การตัดสินใจนี้ทำให้ความรับผิดชอบด้านการป้องกันยังคงอยู่ที่ชั้นแอปพลิเคชันแทนที่จะฝังการตรวจสอบเพิ่มเติมไว้ในโปรโตคอลหลัก ดังนั้นคำแนะนำสาธารณะของกูซาคอฟจึงเน้นที่โปรโตคอลการstaking ควรดำเนินการตรวจสอบก่อนการฝากด้วยตนเอง เวลาเป็นปัจจัยสำคัญที่มีอิทธิพลต่อผลลัพธ์นี้ Sepolia ได้ทำการฟอร์กภายใต้ข้อกำหนดเดิมแล้วเมื่อวันที่ 6 ตุลาคม 2026

การปล่อยตัว Hoodi กำลังก้าวไปสู่การเปิดใช้งานวันที่ 26 ตุลาคม การแนะนำการเปลี่ยนแปลงพฤติกรรมล่าช้าอาจเสี่ยงต่อการต้องปรับใช้ใหม่บน Sepolia และทำให้เกิดความล่าช้าในการทดสอบเพิ่มเติม นักพัฒนาหลักพิจารณาว่าช่วงเวลาที่จำกัดและความสามารถของทีมระดับแอปพลิเคชันในการเพิ่มการตรวจสอบทำให้ไม่จำเป็นต้องใช้แพตช์โปรโตคอลในขั้นตอนนี้ ผลลัพธ์คือแบบจำลองความปลอดภัยแบบกระจายซึ่งผู้ให้บริการ liquid staking แต่ละรายต้องยืนยันว่าระบบการฝากของตนสามารถแยกแยะหรือบล็อกการฝากที่ขึ้นต้นด้วย 0xB0 ซึ่งพยายามอ้างสิทธิ์ในกุญแจสาธารณะของตัวตรวจสอบได้อย่างถูกต้อง

การตรวจสอบก่อนการฝากกลายเป็นการป้องกันหลักสำหรับบริการสแตกิงแบบเหลว

Lido ได้ดำเนินการโมดูลความปลอดภัยในการฝากเงินและคณะกรรมการผู้ดูแลตั้งแต่ช่องโหว่ที่เกี่ยวข้องกับการฝากเงินปรากฏขึ้นเมื่อหลายปีก่อน ผู้ดูแลจะทบทวนภาพถ่าย deposit-root ก่อนที่จะดำเนินการเป็นชุด และผู้ดูแลที่ซื่อสัตย์เพียงคนเดียวสามารถระงับการฝากเงินได้ คำถามที่ยังค้างอยู่คือ โครงสร้างพื้นฐานที่มีอยู่นี้ได้รองรับประเภทข้อมูลประจำตัว 0xB0 ใหม่และกลไกคิวที่ใช้ร่วมกันชั่วคราวแล้วหรือยัง หรือจำเป็นต้องมีตรรกะเพิ่มเติมสำหรับการเปลี่ยนผ่านไปสู่ Glamsterdam โปรโตคอลอื่นๆ ที่ไม่มีการกำกับดูแลแบบหลายฝ่ายที่เทียบเคียงได้จะต้องเผชิญกับภาระการเตรียมความพร้อมที่หนักหน่วงกว่า

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

ตารางการเปิดใช้งาน Glamsterdam ทิ้งช่วงเวลาเตรียมการน้อยมาก

องค์กร Ethereum ยืนยันว่า Glamsterdam จะเปิดใช้งานบน Hoodi testnet ที่ epoch 132,352, slot 4,235,264 ซึ่งตรงกับวันที่ 26 ตุลาคม 2026 เวลา 17:42:48 UTC ใน epoch เดียวกัน ขีดจำกัดแก๊สของ Hoodi จะเพิ่มขึ้นเป็น 200 ล้าน Sepolia ได้รับการเปิดใช้งานไปแล้วเมื่อวันที่ 6 ตุลาคม เวลาบน Mainnet ยังไม่ได้ตัดสินใจ โดยมีวันที่เสนอในช่วงต้นเดือนธันวาคมอยู่ระหว่างการพิจารณา ขึ้นอยู่กับการ Fork ของ Hoodi ที่สะอาด ผู้ดำเนินการโหนดและทีมstaking จึงมีเวลาเพียงไม่กี่วันหลังคำเตือนของ Gusakov เพื่อตรวจสอบกระบวนการฝากของตนบน Hoodi

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

การแยกผู้เสนอและผู้สร้างอย่างเป็นทางการ เปิดทางการฝากใหม่

Glamsterdam รวมการเปลี่ยนแปลงระดับการดำเนินการของ Amsterdam เข้ากับการเปลี่ยนแปลงระดับความเห็นพ้องต้องกันของ Gloas คุณลักษณะหลักสองประการของมันคือการแยกผู้เสนอและผู้สร้างที่ได้รับการรับรอง (EIP-7732) และรายการการเข้าถึงระดับบล็อก ภายใต้ ePBS ผู้สร้างจะลงทะเบียนบนโซ่ด้วยยอดเงินและกุญแจสาธารณะของตนเอง ส่งข้อเสนอ และเปิดเผย payload การดำเนินการในภายหลัง โปรโตคอลจะจัดการการจ่ายเงินให้ผู้เสนอโดยตรง ลดการพึ่งพา external relays การฝากและถอนของผู้สร้างกลายเป็นคำขอการดำเนินการระดับแรก ซึ่งเป็นเหตุผลที่คำนำหน้าคุณลักษณะ 0xB0 และการทับซ้อนของคิวชั่วคราวปรากฏขึ้น

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

ประสบการณ์ด้านความปลอดภัยของการฝากของ Lido ในครั้งก่อนหน้าช่วยเป็นแนวทางในการตอบสนองปัจจุบัน

Lido เคยเผชิญความเสี่ยงจากการ front-running ในการฝากในปีที่ผ่านมา และได้ตอบสนองโดยการกำหนดโมดูลความปลอดภัยในการฝากพร้อมคณะกรรมการผู้ดูแล คณะกรรมการจะอนุมัติภาพถ่าย snapshot ของ deposit-root; ผู้ดูแลเพียงคนเดียวสามารถกระตุ้นการหยุดชั่วคราวได้ โครงสร้างพื้นฐานนี้ได้พิสูจน์แล้วว่ามีประโยชน์ในเหตุการณ์ดำเนินงานอื่นๆ กรณี Glamsterdam ทดสอบว่าการควบคุมเดียวกันสามารถระบุประเภทข้อมูลประจำตัวใหม่และช่วงเวลาสั้นๆ ของการแชร์คิวได้อย่างถูกต้องหรือไม่

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

ผู้ดำเนินการโหนดและผู้ลงทุนที่มอบหมายการstaking ต้องเผชิญกับความเสี่ยงที่มีความเข้มข้นสูงในช่วงเวลานี้

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

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

Hoodi ให้สภาพแวดล้อมแบบเรียลไทม์แห่งแรกสำหรับการทดสอบกระบวนการฝาก

การเปิดใช้งาน Hoodi วันที่ 26 ตุลาคม เป็นโอกาสสาธารณะครั้งแรกที่ทีมstaking สามารถสังเกตพฤติกรรมของคิวแบบร่วมกันภายใต้สภาวะจริง โปรโตคอลสามารถส่งการฝากทดสอบด้วยข้อมูลประจำตัวทั่วไปและ 0xB0 วัดผลการเรียงลำดับ และยืนยันว่าตัวกรองก่อนการฝากของพวกเขาปฏิเสธหรือกักกันเส้นทางที่ไม่ต้องการ ทีมไคลเอนต์ได้เปิดตัวเวอร์ชันที่เข้ากันได้กับ Hoodi แล้ว; ผู้ดำเนินการต้องแน่ใจว่าไคลเอนต์การดำเนินการและไคลเอนต์ความเห็นพ้องต้องกันได้รับการอัปเดต และเครื่องมือภายนอกใดๆ ที่เกี่ยวข้องได้รับการทบทวนสำหรับอินเทอร์เฟซใหม่

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

ความรับผิดชอบในการบรรเทาสถานการณ์ตอนนี้อยู่ที่แต่ละโปรโตคอลการสแตก

โดยการปิดปัญหา consensus-specs ว่าไม่ได้วางแผนไว้ นักพัฒนาหลักได้ส่งสัญญาณว่าความเสี่ยงชั่วคราวควรจัดการที่ชั้นแอปพลิเคชัน ดังนั้น ผู้ให้บริการ liquid staking แพลตฟอร์มผู้ดำเนินการรายเดี่ยว และบริการใดๆ ที่ส่งการฝากแทนผู้ใช้ ต้องดำเนินการตรวจสอบของตนเอง ผู้ให้บริการที่มีคณะกรรมการผู้พิทักษ์หรือกระบวนการยืนยัน deposit-root อยู่แล้วสามารถขยายกระบวนการเหล่านั้นเพื่อครอบคลุมรหัส 0xB0 ผู้ให้บริการที่ไม่มีโครงสร้างพื้นฐานดังกล่าวจะมีกำหนดเวลาที่เข้มงวดกว่าในการเพิ่มการควบคุมที่เทียบเท่า

โมเดลการกระจายมีทั้งข้อดีและข้อเสีย มันช่วยให้สามารถตอบสนองอย่างรวดเร็วและปรับให้เหมาะสมโดยไม่ต้องรอการเปลี่ยนแปลงแบบ hard-fork ของเครือข่ายทั้งหมด นอกจากนี้ยังหมายความว่าความปลอดภัยของการฝากของผู้ให้สตีกแต่ละรายขึ้นอยู่กับวิธีการเฉพาะของโปรโตคอลที่พวกเขาเลือก ความโปร่งใสเกี่ยวกับขั้นตอนการจัดการการฝากในช่วงเวลาการเปิดใช้งานจะช่วยให้ผู้ใช้สามารถประเมินความเสี่ยงที่เหลืออยู่

เป้าหมายการปรับขนาดและกรณีขอบที่ชั่วคราวยังคงเชื่อมโยงกันในการอัปเกรด Ethereum

Glamsterdam ขับเคลื่อนเส้นทางการปรับขนาดระดับ L1 ของ Ethereum โดยการเพิ่มขีดจำกัดแก๊สเชิงปฏิบัติให้ใกล้เคียงกับ 200 ล้าน ทำให้สามารถประมวลผลธุรกรรมแบบขนานผ่านรายการการเข้าถึงระดับบล็อก และกำจัดการเชื่อมต่อภายนอกออกจากเส้นทางสำคัญของการผลิตบล็อก ผลลัพธ์เหล่านี้ต้องการองค์ประกอบพื้นฐานใหม่บนโซ่ ซึ่งส่งผลให้เกิดการทับซ้อนของคิวการฝากชั่วคราว รูปแบบนี้เป็นลักษณะเฉพาะของการอัปเกรดครั้งใหญ่: การปรับปรุงสถาปัตยกรรมในระยะยาวอาจเปิดเผยกรณีขอบที่มีอายุสั้นซึ่งทีมแอปพลิเคชันต้องจัดการ

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

การฝากที่อยู่ในระหว่างรอต้องได้รับการตรวจสอบอย่างเข้มงวดจนกว่าการเปลี่ยนผ่านจะเสร็จสมบูรณ์

กุญแจสาธารณะใดๆ ที่ยังมีการฝากที่ยังไม่ได้รับการประมวลผลในขณะที่กฎ Glamsterdam ใช้บังคับ จะอยู่ภายในช่วงเวลาที่อาจถูกโจมตี โปรโตคอลสามารถลดความเสี่ยงนี้ได้โดยการระบายหรือเร่งคิวการฝากก่อนช่วงเวลาใหม่ การปฏิเสธใบรับรอง 0xB0 สำหรับเจตนาของตัวตรวจสอบ หรือการระงับการส่งข้อมูลใหม่เป็นระยะเวลาสั้นๆ รอบช่วงเปิดใช้งาน การติดตามอย่างต่อเนื่องเกี่ยวกับการเปลี่ยนแปลงของ deposit-root และสถานะการอ้างสิทธิ์กุญแจสาธารณะในชั่วโมงวิกฤตจะช่วยให้สามารถตอบสนองอย่างรวดเร็วหากพบกิจกรรมผิดปกติ

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

🔥 นอกเหนือจากหัวข้อข่าว: KuCoin 5.0 มีความหมายอย่างไรกับคุณ

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

บัญชีเดียวสำหรับทุกอย่าง แพลตฟอร์มรุ่นเก่าแบ่งเงินของคุณออกเป็นบัญชี “สปอต” “หลักประกัน” และ “ฟิวเจอร์ส” แยกจากกัน และคาดหวังให้คุณเข้าใจเหตุผล บัญชีแบบครบวงจร Unified Account ของ KuCoin 5.0 ลบการแบ่งแยกนี้ออกทั้งหมด — ฝากเพียงครั้งเดียว และทุกอย่างจะอยู่ที่นั่นทันที (ขณะนี้มีให้เฉพาะสำหรับผู้ใช้ระดับ VIP)
หุ้น ดัชนี และสินค้าโภคภัณฑ์ KuCoin 5.0 ขยายขอบเขตออกไปนอกเหนือจากสกุลเงินดิจิทัลสู่ตลาดโลก เมื่อสกุลเงินดิจิทัลเคลื่อนไหวแบบทรงตัว ในขณะที่ตลาดหุ้นฟื้นตัว (หรือในทางกลับกัน) คุณสามารถสลับการลงทุนภายในไม่กี่นาที โดยไม่ต้องเปิดบัญชีนายหน้าซื้อขายหลักทรัพย์และรอเป็นวันๆ เพื่อให้ระบบเงิน Fiat ทำงาน
สินทรัพย์ในโลกจริง (RWA) การเข้าถึงสินทรัพย์ดั้งเดิมเช่น สินค้าโภคภัณฑ์ผ่านการแปลงเป็นโทเค็น ภายในบัญชีคริปโตของคุณเอง หนึ่งใน segement ที่เติบโตเร็วที่สุดในระบบการเงินระดับโลก ไม่ได้ถูกจำกัดไว้สำหรับสถาบันอีกต่อไป — คุณสามารถเข้าถึงมันได้จากยอดเงินเดียวกันที่คุณใช้เทรด
หารายได้ขณะเรียนรู้ ยังไม่พร้อมเทรด? KCUSD ช่วยให้ Stablecoin ของคุณสร้างรายได้ทุกวันด้วยดอกเบี้ยทบต้นอัตโนมัติ วิธีที่ผ่อนคลายที่สุดในการทำให้เงินฝากที่ไม่ได้ใช้งานทำงานให้คุณด้วยผลตอบแทน 4%
ผู้ช่วย AI ที่ใช้ภาษาธรรมดา ถามคำถาม รับบริบทตลาด เข้าใจสิ่งที่คุณกำลังดู — ติดตั้งไว้ในแพลตฟอร์ม ไม่ต้องใช้ศัพท์เทคนิค
แอปที่ไม่ทำให้รู้สึกหนักหน่วง รวดเร็ว สะอาด และสอดคล้องกัน — ใช้งานง่ายตั้งแต่แตะครั้งแรก ไม่ต้องรอเรียนรู้ผ่านคำแนะนำ
ความปลอดภัยที่คุณสามารถตรวจสอบได้ ไม่ใช่แค่เชื่อใจเท่านั้น บริษัทในสหภาพยุโรปที่ได้รับใบอนุญาตตาม MiCAR, Proof of Reserves ที่คุณสามารถตรวจสอบด้วยตัวเอง และความปลอดภัยที่ได้รับการรับรองระดับสากล (SOC 2 Type II, ISO 27001:2022)

สร้างบัญชีของคุณในไม่กี่นาที — และเริ่มต้นบนแพลตฟอร์มที่ออกแบบมาสำหรับอนาคตของคริปโต ไม่ใช่อดีต

คำถามที่พบบ่อย

การอัปเกรด Glamsterdam คืออะไร และทำไมมันถึงมีความสำคัญต่อการสแตกging?

Glamsterdam เป็นชื่อรวมสำหรับการเปลี่ยนแปลงระดับการดำเนินการของ Amsterdam และระดับความเห็นพ้องต้องกันของ Gloas เป้าหมายหลักคือการแยกผู้เสนอและผู้สร้างอย่างเป็นทางการ และรายการการเข้าถึงระดับบล็อกที่สนับสนุนขีดจำกัดแก๊สที่สูงขึ้นและการประมวลผลบล็อกที่มีประสิทธิภาพมากขึ้น สำหรับการstaking การแนะนำการลงทะเบียนผู้สร้างบนโซ่และเส้นทางการฝากที่เกี่ยวข้อง สร้างพฤติกรรมการแชร์คิวชั่วคราวซึ่งเป็นพื้นฐานของความเสี่ยงจากการซื้อขายล่วงหน้า

ช่องเวลาในการขโมยการฝากนานแค่ไหน?

หน้าต่างนี้มีอยู่เฉพาะเมื่อการฝากของ builder ยังคงเดินทางผ่านคิวการฝากของ validator เงื่อนไขนี้ยังคงมีอยู่ในช่วงการเปลี่ยนผ่าน hard-fork เอง หลังจากการอัปเกรดเสร็จสิ้น การฝากของ builder จะถูกประมวลผลผ่านสัญญาที่แยกต่างหาก ทำให้เส้นทางคิวร่วมปิดลง ดังนั้นระยะเวลาที่ใช้งานจริงจึงวัดเป็นชั่วโมงรอบช่วงเวลาเปิดใช้งาน ไม่ใช่เป็นวันหรือสัปดาห์

ความเสี่ยงนี้ส่งผลต่อตัวตรวจสอบที่เปิดใช้งานแล้วหรือ ETH ที่ถูกวางเดิมพันอยู่แล้วหรือไม่?

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

ผู้ถือสตีกทั่วไปสามารถทำอะไรเพื่อป้องกันตัวเองได้บ้าง

ผู้stakingที่ฝากผ่านโปรโตคอล liquid staking ควรยืนยันว่าโปรโตคอลได้เผยแพร่คำแนะนำเฉพาะเกี่ยวกับการจัดการการฝากในช่วงการเปิดใช้งาน Glamsterdam การเลือกผู้ให้บริการที่ดำเนินการด้านความปลอดภัยของการฝากแบบหลายฝ่ายหรือการกำกับดูแลแบบ guardian จะช่วยลดความเสี่ยงที่เหลืออยู่ ผู้stakingที่รัน validator ของตนเองควรตรวจสอบให้แน่ใจว่าตรรกะการส่งการฝากของพวกเขาไม่อนุญาตให้การฝาก 0xB0 ที่แข่งขันกันสามารถอ้างสิทธิ์ในคีย์สาธารณะเดียวกัน

ทำไมนักพัฒนาหลักจึงปฏิเสธการแก้ไขระดับโปรโตคอล?

ข้อเสนอสำหรับการตรวจสอบก่อนการฝากถูกปิดเนื่องจากไม่อยู่ในแผนส่วนใหญ่เนื่องจากความกดดันด้านตารางเวลา เซพอลียาได้เปิดใช้งานแล้วภายใต้กฎเดิม และการปล่อยรุ่น Hoodi client กำลังดำเนินไปอย่างก้าวหน้า การเปลี่ยนแปลงพฤติกรรมในระยะล่าช้าจะเสี่ยงต่อการปรับใช้ Testnet เพิ่มเติมและการเลื่อนเวลา นักพัฒนาพิจารณาว่าการลดผลกระทบในระดับแอปพลิเคชันนั้นเพียงพอแล้วในบริบทของระยะเวลาการเปิดเผยที่จำกัด

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

คำปฏิเสธความรับผิดชอบ: หน้านี้แปลโดยใช้เทคโนโลยี AI เพื่อความสะดวกของคุณ สำหรับข้อมูลที่ถูกต้องที่สุด โปรดดูต้นฉบับภาษาอังกฤษ