Blockchain

เหตุใดการอัปเกรด smart contract ของฉันทำให้ฉันสามารถทำลาย storage อย่างเงียบๆ ที่ผู้ตรวจสอบรับรองไปแล้ว?

โอกาส

รูปแบบ upgradeable proxy (UUPS, Transparent Proxy, Diamond) เป็นมาตรฐานใน DeFi การใช้งานจริงแต่มีข้อจำกัดเข้มงวด: layout storage ของ implementation ใหม่ต้องเข้ากันได้กับทุก slot ที่กำหนดโดยฉบับก่อน หากแทรกตัวแปร state ใหม่ในตำแหน่งผิด ทุก slot ที่ตามมาจะเสียหายอย่างเงียบๆ โดยไม่มีข้อผิดพลาดบนเชน เครื่องมือตรวจสอบอัตโนมัติอย่างปลั๊กอิน upgrade ของ OpenZeppelin จับกรณีทั่วไปได้ แต่พลาด ERC-7201 namespaced storage ที่มีการบรรจุแบบกำหนดเอง การกำหนด slot ในระดับ assembly และการชนกันข้ามฟาเซตของ Diamond ที่ฟาเซตสองตัวอ้างสิทธิ์ในพื้นที่ storage เดียวกัน การศึกษาที่ผ่านการทบทวนโดยผู้เชี่ยวชาญในเดือนมกราคม 2026 (ProxyLens) พบช่องโหว่การชนระหว่างฟาเซตประเภทสำคัญที่เครื่องมือที่มีอยู่ตรวจจับไม่ได้ ผู้ตรวจสอบตรวจสอบ implementation contracts แยกกันและไม่สามารถสร้าง storage map ทั้งหมดของ proxy ที่มี delegated facet หลายตัวขึ้นใหม่ได้

ทำไมถึงสำคัญ

เครื่องมือที่สร้างแผนที่พื้นที่จัดเก็บข้อมูลแบบครบถ้วนพร้อม diff ตามเวอร์ชันสำหรับสัญญา proxy และสัญญา implementation ทั้งหมด จะเปลี่ยนปัญหาข้อมูลเสียหายแบบเงียบๆ ให้กลายเป็นการบล็อก deployment ได้

วิธีที่ผมให้คะแนนโอกาส

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

ความรุนแรง9/10

ความเจ็บปวดที่มันก่อขึ้นเมื่อปรากฏตัว

ความถี่6/10

ความถี่ที่คนจริงๆ เจอมัน

ช่องว่าง8/10

ความขาดแคลนของเครื่องมือที่ดีสำหรับมันในปัจจุบัน