---
title: "วิธีติดตามการอัปเกรดสัญญาพร็อกซี"
description: "ติดตามการเปลี่ยนแปลง implementation, beacon และสิทธิ์ควบคุมของพร็อกซีที่อัปเกรดได้ จากนั้นตรวจสอบโค้ด ความเข้ากันได้ของพื้นที่จัดเก็บ การเริ่มต้นระบบ สิทธิ์ และพฤติกรรมสำคัญหลังดำเนินการ"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# วิธีติดตามการอัปเกรดสัญญาพร็อกซี

> จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

<a id="answer"></a>

## คำตอบโดยตรง

ติดตามเส้นทางการควบคุมของระบบที่อัปเกรดได้ควบคู่กับที่อยู่พร็อกซี การแจ้งเตือนควรระบุว่าใครอนุมัติและดำเนินการอัปเกรดได้ ระยะเวลาหน่วงที่บังคับใช้ implementation เดิมและใหม่ และ calldata สำหรับการเริ่มต้นระบบ หลังดำเนินการแล้ว ให้อ่านการกำหนดค่าบนเชนจากแหล่งอิสระและทดสอบพฤติกรรมสำคัญ

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

<a id="mechanism"></a>

## วิธีการทำงาน

ขั้นแรกให้ระบุรูปแบบพร็อกซี 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 ของเชนก่อนถือว่าสถานะเสร็จสมบูรณ์

<a id="example"></a>

## ตัวอย่าง

พร็อกซีการให้กู้ถูกควบคุมด้วย multisig 3 จาก 5 ผ่าน timelock 24 ชั่วโมง เมื่อกำหนดการอัปเกรด ระบบติดตามจะบันทึกรหัสข้อเสนอ เป้าหมาย calldata เวลาดำเนินการเร็วที่สุด implementation ปัจจุบัน implementation ที่เสนอ และสถานะการยืนยันซอร์สโค้ด ผู้ตรวจสอบเปรียบเทียบโค้ดและผังพื้นที่จัดเก็บ ตรวจสอบการเรียกเริ่มต้นระบบ และตรวจการเปลี่ยนแปลงบทบาท การเรียกภายนอก ค่าธรรมเนียม กฎการหยุด และเส้นทางการถอน

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

<a id="risks"></a>

## ความเสี่ยง

- **ความเสี่ยงด้านการควบคุม:** multisig ที่เห็นอาจถูกข้ามด้วยเจ้าของอื่น บทบาท โมดูล สัญญากำกับดูแล คีย์ฉุกเฉิน หรือ timelock ที่แก้ไขได้ ให้ติดตามทุกเส้นทางถึงผู้ลงนามสุดท้ายและระยะหน่วง
- **ความเสี่ยงด้านโค้ดและพื้นที่จัดเก็บ:** โค้ดที่ไม่ยืนยัน ผังพื้นที่จัดเก็บที่เข้ากันไม่ได้ การเริ่มต้นระบบที่ไม่ปลอดภัย หรือ dependency ที่เปลี่ยนไป อาจทำลายสถานะหรือให้สิทธิ์โดยไม่ตั้งใจ ตรวจสอบ artefact ที่นำไปใช้จริง ไม่ใช่เพียง branch ของ repository หรือชื่อการตรวจสอบ
- **ความเสี่ยงด้านการติดตาม:** RPC เดียว ตัวสร้างดัชนีที่ดูเฉพาะเหตุการณ์ front-end หรือเครื่องมือสำรวจบล็อกอาจล่าช้าหรือผิดพลาด กระทบยอดเหตุการณ์กับพื้นที่จัดเก็บ bytecode ใบรับธุรกรรม และสถานะโปรโตคอลจากแหล่งข้อมูลอิสระ
- **ความเสี่ยงด้านการตอบสนอง:** การแจ้งเตือนที่ไม่มีผู้รับผิดชอบและขั้นตอนที่ทดสอบแล้วอาจมาช้าเกินไป กำหนดว่าใครตรวจสอบ หยุดการเชื่อมต่อ สื่อสาร หรือถอนตัวในช่วงหน่วง และตระหนักว่าการอนุมัติที่รีบร้อนกับลิงก์กู้คืนที่ไม่เป็นทางการเพิ่มความเสี่ยง

ขั้นตอนขั้นต่ำ:

1. ทำรายการพร็อกซี beacon implementation ผู้ดูแล บทบาท และจุดเข้าสำหรับการอัปเกรดทั้งหมดในแต่ละเชน
2. บันทึกค่าฐานที่ทราบว่าถูกต้องของสล็อต แฮชโค้ด สถานะการควบคุม และผลลัพธ์สำคัญแบบอ่านอย่างเดียว
3. แจ้งเตือนก่อนดำเนินการเมื่อการจัดกำหนดการโดยการกำกับดูแลหรือ timelock ทำได้ และแจ้งอีกครั้งเมื่อดำเนินการหรือยกเลิก
4. เปรียบเทียบเป้าหมาย calldata implementation bytecode ผังพื้นที่จัดเก็บ และสถานะหลังอัปเกรดที่ดำเนินการจริงกับข้อเสนอที่ตรวจสอบแล้ว
5. ยกระดับการเปลี่ยนแปลงที่ไม่คาดคิด เงื่อนไขหลังดำเนินการที่ล้มเหลว การไม่มีการยืนยันซอร์ส หรือระยะหน่วงที่สั้นลงหรือถูกข้าม อย่าใช้ที่อยู่พร็อกซีที่ไม่เปลี่ยนเป็นหลักฐานความปลอดภัย

<a id="misconceptions"></a>

## ความเข้าใจผิดที่พบบ่อย

- **ความเชื่อผิด 1: "ติดตาม `Upgraded` ก็เพียงพอ"** การเปลี่ยน implementation ของ beacon และพร็อกซีที่ไม่เป็นมาตรฐานอาจต้องติดตามอีกสัญญาหนึ่งหรือสำรวจสถานะ ให้กระทบยอดเหตุการณ์กับการอ่านโดยตรง
- **ความเชื่อผิด 2: "สล็อตผู้ดูแลบอกได้ว่าใครควบคุมทุกการอัปเกรด"** สล็อตนี้เป็นตัวเลือก และรูปแบบ Transparent, UUPS, beacon, การกำกับดูแล และแบบกำหนดเองวางอำนาจไว้ในสัญญาและฟังก์ชันต่างกัน
- **ความเชื่อผิด 3: "ซอร์สโค้ดที่ยืนยันแล้วหรือการตรวจสอบเดิมพิสูจน์ว่าการอัปเกรดปลอดภัย"** ตรวจสอบ bytecode ที่ใช้งานจริง สมมติฐานของ compiler และ constructor ความเข้ากันได้ของพื้นที่จัดเก็บ การเริ่มต้นระบบ การกำหนดค่า และพฤติกรรมของรุ่นที่ตรงกัน

<a id="related"></a>

## หัวข้อที่เกี่ยวข้อง

- [ความเสี่ยงของโมดูล multisig](/th/crypto/multisig-module-risk/)
- [สัญญาพร็อกซี](/th/crypto/proxy-contract/)
- [การชนกันของพื้นที่จัดเก็บพร็อกซี](/th/crypto/proxy-storage-collision/)
- [การหยุดโปรโตคอลในกรณีฉุกเฉิน](/th/crypto/protocol-emergency-pause/)
- [สัญญาที่อัปเกรดได้](/th/crypto/upgradeable-contract/)

<a id="sources"></a>

## แหล่งที่มา

- [ERC-1967: สล็อตจัดเก็บของพร็อกซี](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-21)
- [พร็อกซี](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (เข้าถึง: 2026-08-21)
- [การเขียนสัญญาที่อัปเกรดได้](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (เข้าถึง: 2026-08-21)
- [การควบคุมการเข้าถึง](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin (เข้าถึง: 2026-08-21)

Source: https://wiki.fcontext.com/th/crypto/proxy-upgrade-monitoring/index.mdx