---
title: "สัญญาพร็อกซี"
description: "สัญญาพร็อกซีส่งต่อการเรียกไปยังโค้ดอิมพลีเมนเทชัน โดยคงที่อยู่และสถานะไว้ที่พร็อกซี เรียนรู้กลไกและความเสี่ยงจากการอัปเกรด พื้นที่จัดเก็บ และผู้ดูแลระบบ"
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>

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

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

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

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

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

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

เมื่อการเรียกมาถึงพร็อกซี เส้นทาง fallback จะคัดลอกหรือส่งต่อข้อมูลการเรียกไปยังอิมพลีเมนเทชัน เมื่อใช้ `delegatecall` ค่า `address(this)` คือพร็อกซี การอ่านและเขียนพื้นที่จัดเก็บมีผลต่อพร็อกซี และค่าเดิมของ `msg.sender` กับ `msg.value` จะยังคงอยู่ จากนั้นพร็อกซีจะส่งคืนข้อมูลจากอิมพลีเมนเทชันหรือย้อนกลับพร้อมกัน

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

การออกแบบที่พบบ่อยวางอำนาจอัปเกรดไว้ต่างตำแหน่งกัน:

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

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

## ตัวอย่าง

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

ต่อมา ฝ่ายกำกับดูแลเปลี่ยนสล็อตอิมพลีเมนเทชัน ERC-1967 เป็นอิมพลีเมนเทชัน B ที่อยู่พร็อกซีและยอดคงเหลือที่บันทึกไว้ไม่ย้าย แต่การเรียกในอนาคตจะทำงานด้วยโค้ดของ B หาก B รักษาเค้าโครงพื้นที่จัดเก็บและใช้กฎตามที่ตั้งใจ ผู้ใช้จะเห็นพฤติกรรมใหม่ที่ที่อยู่เดิม

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

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

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

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

ก่อนฝากสินทรัพย์หรือให้สิทธิ์อนุมัติ ให้ค้นหาอิมพลีเมนเทชันหรือบีคอนปัจจุบันบนเชน ระบุผู้มีอำนาจอัปเกรดและ timelock ตรวจสอบซอร์สโค้ดที่ยืนยันแล้วและความเข้ากันได้ของพื้นที่จัดเก็บ และดูอีเวนต์ล่าสุด `Upgraded`, `BeaconUpgraded` และ `AdminChanged` เมื่อเกี่ยวข้อง ยังต้องติดตามต่อหลังการตรวจสอบครั้งแรก เพราะเส้นทางการทำงานสามารถเปลี่ยนได้

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

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

- **“พร็อกซีไม่ได้เก็บสถานะที่มีความหมาย”** เมื่อใช้ `delegatecall` สถานะของแอปพลิเคชันและโดยมากรวมถึงสินทรัพย์เป็นของพร็อกซี แม้ว่าลอจิกจะมาจากอีกที่อยู่หนึ่ง
- **“อิมพลีเมนเทชันที่ยืนยันแล้วทำให้ระบบไม่ต้องอาศัยความไว้วางใจ”** คีย์อัปเกรด การกำกับดูแล บีคอน การเริ่มต้น และอิมพลีเมนเทชันในอนาคตยังเป็นส่วนหนึ่งของแบบจำลองความไว้วางใจ
- **“พร็อกซีทุกตัวอัปเกรดได้”** โคลนและพร็อกซีแบบคงที่อื่นอาจมอบหมายงานอย่างถาวร ความสามารถในการอัปเกรดขึ้นอยู่กับการออกแบบและโค้ดอนุญาตเฉพาะ

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

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

- [ความเสี่ยงของพื้นที่จัดเก็บจาก Delegatecall](/th/crypto/delegatecall-storage-risk/)
- [การชนกันของพื้นที่จัดเก็บพร็อกซี](/th/crypto/proxy-storage-collision/)
- [การติดตามการอัปเกรดพร็อกซี](/th/crypto/proxy-upgrade-monitoring/)
- [สัญญาอัจฉริยะ](/th/crypto/smart-contract/)
- [สัญญาที่อัปเกรดได้](/th/crypto/upgradeable-contract/)

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

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

- [บทนำสู่สัญญาอัจฉริยะ](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html) - Solidity Documentation (เข้าถึง: 2026-08-21)
- [ERC-1967: สล็อตพื้นที่จัดเก็บของพร็อกซี](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-21)
- [ERC-1822: มาตรฐานพร็อกซีที่อัปเกรดได้แบบสากล (UUPS)](https://eips.ethereum.org/EIPS/eip-1822) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-21)
- [พร็อกซี](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin Documentation (เข้าถึง: 2026-08-21)

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