จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้
คำตอบโดยตรง
ติดตามเส้นทางการควบคุมของระบบที่อัปเกรดได้ควบคู่กับที่อยู่พร็อกซี การแจ้งเตือนควรระบุว่าใครอนุมัติและดำเนินการอัปเกรดได้ ระยะเวลาหน่วงที่บังคับใช้ implementation เดิมและใหม่ และ calldata สำหรับการเริ่มต้นระบบ หลังดำเนินการแล้ว ให้อ่านการกำหนดค่าบนเชนจากแหล่งอิสระและทดสอบพฤติกรรมสำคัญ
ที่อยู่พร็อกซีและยอดคงเหลืออาจไม่เปลี่ยนแปลง แม้โค้ดที่มอบหมายจะเปลี่ยนสิทธิ์ ค่าธรรมเนียม การบัญชี การหยุดชั่วคราว หรือตรรกะการถอน การตรวจสอบความปลอดภัยครั้งก่อนไม่ได้ครอบคลุม implementation ใหม่หรือการเริ่มต้นระบบโดยอัตโนมัติ
วิธีการทำงาน
ขั้นแรกให้ระบุรูปแบบพร็อกซี ERC-1967 กำหนดสล็อตจัดเก็บแยกสำหรับ eip1967.proxy.implementation, eip1967.proxy.beacon และ eip1967.proxy.admin ซึ่งเป็นตัวเลือก การเปลี่ยน implementation โดยตรงควรส่งเหตุการณ์ Upgraded การเปลี่ยนที่อยู่ beacon ควรส่ง BeaconUpgraded และการเปลี่ยนสล็อตผู้ดูแลควรส่ง AdminChanged สำหรับพร็อกซี beacon ให้เรียก implementation() ที่ beacon ด้วย เพราะ beacon เปลี่ยน implementation ได้โดยสล็อต beacon ของพร็อกซีไม่เปลี่ยน
อย่าสรุปรูปแบบอำนาจทั้งหมดจากสล็อตผู้ดูแล พร็อกซี Transparent อาจควบคุมผ่าน ProxyAdmin ส่วนการอนุมัติการอัปเกรด UUPS อยู่ในสัญญาตรรกะปัจจุบันผ่าน _authorizeUpgrade ให้ติดตามเจ้าของ บทบาท เกณฑ์ multisig timelock สัญญากำกับดูแล เส้นทางฉุกเฉิน และสิทธิ์ในการเปลี่ยนการควบคุมเหล่านี้
ใช้ทั้งการสมัครรับเหตุการณ์และการอ่านสถานะเป็นระยะ ERC-1967 แนะนำให้ส่งเหตุการณ์ แต่ไม่ได้บังคับทุก implementation ให้ทำเช่นนั้น บันทึกเชน บล็อก ธุรกรรม พร็อกซี implementation หรือ beacon แฮชโค้ด runtime ผู้ดำเนินการ และสถานะการควบคุมที่เกี่ยวข้องจากปลายทาง RPC อิสระ แจ้งเตือนเมื่อมีการจัดกำหนดการ ยกเลิก และดำเนินการ และรอตามนโยบายการยืนยันหรือ finality ของเชนก่อนถือว่าสถานะเสร็จสมบูรณ์
ตัวอย่าง
พร็อกซีการให้กู้ถูกควบคุมด้วย multisig 3 จาก 5 ผ่าน timelock 24 ชั่วโมง เมื่อกำหนดการอัปเกรด ระบบติดตามจะบันทึกรหัสข้อเสนอ เป้าหมาย calldata เวลาดำเนินการเร็วที่สุด implementation ปัจจุบัน implementation ที่เสนอ และสถานะการยืนยันซอร์สโค้ด ผู้ตรวจสอบเปรียบเทียบโค้ดและผังพื้นที่จัดเก็บ ตรวจสอบการเรียกเริ่มต้นระบบ และตรวจการเปลี่ยนแปลงบทบาท การเรียกภายนอก ค่าธรรมเนียม กฎการหยุด และเส้นทางการถอน
หลังดำเนินการ ระบบติดตามจะอ่านสล็อต ERC-1967 ที่เกี่ยวข้องอีกครั้ง ตรวจสอบโค้ด runtime ที่ใช้งาน และตรวจเงื่อนไขหลังดำเนินการ เช่น เวอร์ชัน implementation ผู้ดูแลหรือผู้ถือบทบาท สถานะหยุดชั่วคราว การบัญชีสินทรัพย์ และตัวอย่างการถอนแบบอ่านอย่างเดียว ระบบจะส่งการแจ้งเตือนอีกครั้งหากที่อยู่หรือแฮชโค้ดที่พบต่างจากข้อเสนอที่ตรวจสอบแล้ว หรือการสำรวจเป็นระยะพบการเปลี่ยนแปลงที่ไม่มีเหตุการณ์รายงาน
ความเสี่ยง
- ความเสี่ยงด้านการควบคุม: multisig ที่เห็นอาจถูกข้ามด้วยเจ้าของอื่น บทบาท โมดูล สัญญากำกับดูแล คีย์ฉุกเฉิน หรือ timelock ที่แก้ไขได้ ให้ติดตามทุกเส้นทางถึงผู้ลงนามสุดท้ายและระยะหน่วง
- ความเสี่ยงด้านโค้ดและพื้นที่จัดเก็บ: โค้ดที่ไม่ยืนยัน ผังพื้นที่จัดเก็บที่เข้ากันไม่ได้ การเริ่มต้นระบบที่ไม่ปลอดภัย หรือ dependency ที่เปลี่ยนไป อาจทำลายสถานะหรือให้สิทธิ์โดยไม่ตั้งใจ ตรวจสอบ artefact ที่นำไปใช้จริง ไม่ใช่เพียง branch ของ repository หรือชื่อการตรวจสอบ
- ความเสี่ยงด้านการติดตาม: RPC เดียว ตัวสร้างดัชนีที่ดูเฉพาะเหตุการณ์ front-end หรือเครื่องมือสำรวจบล็อกอาจล่าช้าหรือผิดพลาด กระทบยอดเหตุการณ์กับพื้นที่จัดเก็บ bytecode ใบรับธุรกรรม และสถานะโปรโตคอลจากแหล่งข้อมูลอิสระ
- ความเสี่ยงด้านการตอบสนอง: การแจ้งเตือนที่ไม่มีผู้รับผิดชอบและขั้นตอนที่ทดสอบแล้วอาจมาช้าเกินไป กำหนดว่าใครตรวจสอบ หยุดการเชื่อมต่อ สื่อสาร หรือถอนตัวในช่วงหน่วง และตระหนักว่าการอนุมัติที่รีบร้อนกับลิงก์กู้คืนที่ไม่เป็นทางการเพิ่มความเสี่ยง
ขั้นตอนขั้นต่ำ:
- ทำรายการพร็อกซี beacon implementation ผู้ดูแล บทบาท และจุดเข้าสำหรับการอัปเกรดทั้งหมดในแต่ละเชน
- บันทึกค่าฐานที่ทราบว่าถูกต้องของสล็อต แฮชโค้ด สถานะการควบคุม และผลลัพธ์สำคัญแบบอ่านอย่างเดียว
- แจ้งเตือนก่อนดำเนินการเมื่อการจัดกำหนดการโดยการกำกับดูแลหรือ timelock ทำได้ และแจ้งอีกครั้งเมื่อดำเนินการหรือยกเลิก
- เปรียบเทียบเป้าหมาย calldata implementation bytecode ผังพื้นที่จัดเก็บ และสถานะหลังอัปเกรดที่ดำเนินการจริงกับข้อเสนอที่ตรวจสอบแล้ว
- ยกระดับการเปลี่ยนแปลงที่ไม่คาดคิด เงื่อนไขหลังดำเนินการที่ล้มเหลว การไม่มีการยืนยันซอร์ส หรือระยะหน่วงที่สั้นลงหรือถูกข้าม อย่าใช้ที่อยู่พร็อกซีที่ไม่เปลี่ยนเป็นหลักฐานความปลอดภัย
ความเข้าใจผิดที่พบบ่อย
- ความเชื่อผิด 1: “ติดตาม
Upgradedก็เพียงพอ” การเปลี่ยน implementation ของ beacon และพร็อกซีที่ไม่เป็นมาตรฐานอาจต้องติดตามอีกสัญญาหนึ่งหรือสำรวจสถานะ ให้กระทบยอดเหตุการณ์กับการอ่านโดยตรง - ความเชื่อผิด 2: “สล็อตผู้ดูแลบอกได้ว่าใครควบคุมทุกการอัปเกรด” สล็อตนี้เป็นตัวเลือก และรูปแบบ Transparent, UUPS, beacon, การกำกับดูแล และแบบกำหนดเองวางอำนาจไว้ในสัญญาและฟังก์ชันต่างกัน
- ความเชื่อผิด 3: “ซอร์สโค้ดที่ยืนยันแล้วหรือการตรวจสอบเดิมพิสูจน์ว่าการอัปเกรดปลอดภัย” ตรวจสอบ bytecode ที่ใช้งานจริง สมมติฐานของ compiler และ constructor ความเข้ากันได้ของพื้นที่จัดเก็บ การเริ่มต้นระบบ การกำหนดค่า และพฤติกรรมของรุ่นที่ตรงกัน
หัวข้อที่เกี่ยวข้อง
- ความเสี่ยงของโมดูล multisig
- สัญญาพร็อกซี
- การชนกันของพื้นที่จัดเก็บพร็อกซี
- การหยุดโปรโตคอลในกรณีฉุกเฉิน
- สัญญาที่อัปเกรดได้
แหล่งที่มา
- ERC-1967: สล็อตจัดเก็บของพร็อกซี - Ethereum Improvement Proposals (เข้าถึง: 2026-08-21)
- พร็อกซี - OpenZeppelin (เข้าถึง: 2026-08-21)
- การเขียนสัญญาที่อัปเกรดได้ - OpenZeppelin (เข้าถึง: 2026-08-21)
- การควบคุมการเข้าถึง - OpenZeppelin (เข้าถึง: 2026-08-21)