---
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>

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

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

ภาพรวมต้องตรึง repository และ commit หรือ tree hash, submodule และ dependency lock, compiler และ settings, โค้ดที่สร้างขึ้น, deployment scripts, chain และ address เป้าหมาย, proxy, implementation หรือ beacon, ข้อมูล constructor หรือ initializer, library, administrator, timelock และ block หรือเวลา การระบุสิ่งที่ไม่อยู่ในขอบเขตสำคัญเท่ากับสิ่งที่รวมอยู่ เพราะ frontend, keeper, oracle, bridge, governance หรือผู้ลงนามนอกเชนอาจเป็นตัวกำหนดความเสี่ยงแม้ไม่อยู่ในงานตรวจสอบ

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

ใช้บัญชีสี่ชุด ได้แก่ ขอบเขตและอัตลักษณ์ของบิลด์กับการปรับใช้ ข้อกำหนด ภัยคุกคาม และ invariant ข้อค้นพบ หลักฐาน และการทดสอบซ้ำ ตลอดจนความเสี่ยงคงเหลือ การยอมรับ และการเปิดเผย รายงานที่ไม่มีข้อค้นพบ `critical` ไม่ใช่ใบรับรองความปลอดภัย ข้อค้นพบที่ระบุว่า `resolved` ไม่ได้หมายความว่าปรับใช้แล้ว และข้อพิสูจน์ครอบคลุมเฉพาะคุณสมบัติ แบบจำลอง และสมมติฐานที่เข้ารหัสไว้

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

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

การตรวจสอบด้วยมนุษย์ติดตามสถาปัตยกรรม กระแสเงิน สถานะข้ามฟังก์ชัน และเจตนาทางเศรษฐกิจ การวิเคราะห์แบบสถิตค้นหารูปแบบและกระแสข้อมูล แต่อาจให้ผลบวกลวงหรือผลลบลวง การทดสอบหน่วย การทดสอบแบบบูรณาการ การทดสอบบน fork และการทดสอบเชิงเปรียบเทียบตรวจพฤติกรรมที่เป็นรูปธรรม ส่วน stateful fuzzing และการทดสอบ invariant สำรวจลำดับที่สร้างขึ้น แต่ผลขึ้นอยู่กับ handler, selector, seed, corpus, runs, depth และสภาพแวดล้อมที่จำลอง

การประมวลผลเชิงสัญลักษณ์และการพิสูจน์อย่างเป็นทางการอาจยืนยันข้อความเฉพาะภายใต้ความหมายและสมมติฐานที่รองรับ ผลจาก solver เป็น `unknown` การหมดเวลา หรือพฤติกรรมที่ไม่รองรับ ไม่ใช่ข้อพิสูจน์ แม้คุณสมบัติที่พิสูจน์แล้วก็อาจไม่ครอบคลุมเศรษฐศาสตร์ของ oracle, governance, การตั้งค่าการปรับใช้, พฤติกรรมของ chain หรือข้อกำหนดที่ทีมตั้งใจจริง มนุษย์ต้องรับผิดชอบข้อกำหนดและการตีความ ข้อสังเกตที่ AI สร้างไม่ใช่วิธีรับรองอิสระ

ข้อค้นพบแต่ละรายการควรระบุ artifact และ deployment ที่ได้รับผล เงื่อนไขก่อนหน้า หลักฐานขั้นต่ำ เส้นทางการโจมตี การเข้าถึง สิทธิพิเศษ เงินทุนของผู้โจมตี ความสามารถในการทำซ้ำ ผลกระทบทางเศรษฐกิจ เกณฑ์ severity และคำแนะนำ ความสามารถหรือความน่าจะเป็นในการโจมตีกับผลกระทบเป็นคนละมิติ ค่าสูงสุดเชิงทฤษฎี ชื่อช่องโหว่ หรือป้ายจากเครื่องมือไม่ได้พิสูจน์ความเสียหายที่ดำเนินการได้จริง

สถานะ `open`, `acknowledged`, `risk accepted`, `partially fixed`, `resolved` และ `retested` ไม่ใช่มาตรฐานสากล การปิดประเด็นที่มีหลักฐานต้องเชื่อมปัญหาเดิมกับ commit ที่แก้ไขอย่างเจาะจง บันทึกเส้นทางที่เปลี่ยนและเส้นทางข้างเคียงที่ทดสอบ และระบุว่าใครทดสอบอะไรซ้ำเมื่อใด ความเสี่ยงที่ยอมรับยังคงเป็นความเสี่ยง และการทดสอบซ้ำแบบจำกัดไม่ได้ขยายขอบเขตเดิมให้ครอบคลุมโค้ดใหม่ทั้งหมด

การปรับใช้ที่อัปเกรดได้ต้องกระทบยอดเป็นพิเศษ ระบุ proxy, implementation หรือ beacon และ admin slot ตรวจพฤติกรรม initializer กับ reinitializer การล็อก implementation ความเข้ากันได้ของ storage การอนุญาตให้อัปเกรด timelock หรือทางข้ามฉุกเฉิน การย้ายข้อมูล และ rollback สร้าง creation bytecode และ runtime bytecode ซ้ำจากบิลด์ที่ตรวจสอบ แล้วเปรียบเทียบ linked library, parameter, role และสถานะที่เริ่มต้นแล้วบนทุก chain

รายงานสุดท้ายควรระบุ revision ผู้ตรวจสอบ วันที่ ขอบเขตที่แน่นอน วิธีและการตั้งค่า ข้อจำกัด ข้อค้นพบ หลักฐาน สถานะการแก้ไข ความเสี่ยงที่ยังเปิดหรือยอมรับ และเงื่อนไข disclosure หลังเปิดใช้งานให้ติดตาม implementation hash, role, parameter, dependency และ incident การเปลี่ยนแปลงสาระสำคัญทุกครั้งสร้างส่วนต่างใหม่ที่ต้องตรวจสอบ ป้ายจากรายงานเก่าไม่ติดตามโค้ดในอนาคตโดยอัตโนมัติ

ใช้ขั้นตอนต่อไปนี้:

1. ตรึง manifest ของงาน ได้แก่ repository, commit, dependency, compiler และ settings, โค้ดที่สร้างกับโค้ด deployment, chain, address, proxy stack, parameter, block, revision ของรายงาน สิ่งที่รวม และสิ่งที่ยกเว้น
2. กำหนดสินทรัพย์ ผู้มีส่วนเกี่ยวข้อง บทบาทที่มีสิทธิพิเศษ ขอบเขตความไว้วางใจ ความสามารถผู้โจมตี วงจรชีวิต สมมติฐานเรื่องลำดับและความพร้อมทำงาน การพึ่งพาภายนอก และ invariant ที่วัดได้
3. สร้างบิลด์ซ้ำและทำแผนที่สถาปัตยกรรม storage ข้อมูล เงินทุน และการควบคุม กระทบยอด source, artifact, library, creation/runtime bytecode, initializer, role และ deployment ที่ใช้งานจริง
4. ใช้วิธีเสริมกันทั้งการตรวจด้วยมนุษย์ แบบสถิต หน่วย บูรณาการ fork เปรียบเทียบ fuzz invariant เชิงสัญลักษณ์ หรือแบบเป็นทางการ พร้อมบันทึกเวอร์ชันเครื่องมือ การตั้งค่า seed, corpus, coverage, timeout และผลที่ไม่ทราบ
5. บันทึก artifact ที่ได้รับผล เงื่อนไขก่อนหน้า หลักฐาน ความสามารถในการโจมตี ผลกระทบ วิธีประเมิน severity การเปิดรับของ deployment คำแนะนำ และหลักฐานลับของแต่ละประเด็น โดยไม่ถือป้ายเครื่องมือเป็นคำตัดสิน
6. ตรึง commit ที่แก้ไข แล้วทดสอบประเด็น เส้นทางข้างเคียง และ invariant ซ้ำ ตรวจ proxy storage, initialization, migration, rollback, reproducible build และ receipt ของ deployment ก่อนกำหนดสถานะจากหลักฐาน
7. เผยแพร่ขอบเขต วิธี ข้อจำกัด และความเสี่ยงคงเหลือ กระทบยอด artifact ที่ตรวจสอบกับทุก chain ที่ใช้งาน และปรับปรุง monitoring, disclosure, incident response และ bug bounty ตามการเปลี่ยนแปลงของระบบ

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

## ตัวอย่าง

- **เส้นทางเงินเฟ้อของ vault ต้องมีบัญชีครบถ้วน** ผู้โจมตีฝาก `1 asset` ผ่านกรณีฝากครั้งแรกและได้รับ `1 share` แล้วบริจาค `1,000,000 assets` ทำให้ยอดรวมเป็น `1,000,001 assets` และ `1 share` เหยื่อฝาก `500,000 assets` และการปัดเศษลงที่ไม่ปลอดภัยให้ค่า `floor(500,000 * 1 / 1,000,001) = 0 shares` หาก vault รับการฝากที่ได้ศูนย์ share จะถือ `1,500,001 assets` ผู้โจมตีไถ่ถอนทั้งหมดและได้ `500,000 assets` เหนือเงินสมทบ `1,000,001-asset` แต่หาก implementation revert เมื่อได้ศูนย์ share เส้นทางสูญเสียนี้จะเกิดขึ้นไม่ได้
- **การครอบคลุมไฟล์ไม่ใช่การครอบคลุม deployment** manifest มี `24 source units`, `4 deployment scripts` และ `3 keeper services` รวม `31 items` งานครอบคลุม `20 source units` และ `2 scripts` ดังนั้นสัดส่วนตามจำนวนคือ `22 / 31 = 70.96774194%` ส่วนอีก `9 items` ถูกยกเว้น หาก proxy ที่ใช้งานชี้ไปยัง implementation ที่บิลด์จากหน่วยซึ่งถูกยกเว้น การครอบคลุม implementation นั้นคือ `0%` แม้พาดหัวระบุ `70.96774194%`
- **ผลสังเกตจาก fuzzing ไม่ใช่ข้อพิสูจน์ว่าไม่มีข้อผิดพลาด** stateful run ทำ `2,000 sequences * 64 calls = 128,000 calls` และ invariant ล้มเหลวใน `3 sequences` หรือ `3 / 2,000 = 0.15%` ของลำดับที่สร้างและสังเกต หลังแก้ไข `10,000 sequences * 64 calls = 640,000 calls` ไม่พบความล้มเหลว นี่คือศูนย์ใน corpus นี้ ไม่ใช่ข้อพิสูจน์ ภายใต้สมมติฐานเพื่อการสอนว่าตัวอย่างอิสระและ generator คงที่ ขอบบนโดยประมาณตาม rule of three ที่ `95%` คือ `3 / 10,000 = 0.03%` ต่อลำดับที่สร้าง
- **การปิดข้อค้นพบกับอัตลักษณ์ deployment เป็นอิสระกัน** รายงานมี `12 findings` ได้แก่ `2 critical`, `3 high`, `4 medium` และ `3 low` การทดสอบซ้ำปิด `2 + 2 + 3 + 2 = 9` จึงมีอัตราปิด `9 / 12 = 75%` และยังเหลือ high หนึ่ง medium หนึ่ง และ low หนึ่ง runtime hash ที่ตรวจสอบคือ `H1` แต่ implementation ที่ใช้งานคือ `H2` การยืนยัน deployment จึงล้มเหลวไม่ว่าอัตราปิดเท่าใด การแทนด้วย `H1` ที่ตรงกันพร้อม proxy slot, initializer และ role ที่ตรงกัน พิสูจน์เพียงอัตลักษณ์ ณ block ที่ตรวจสอบ

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

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

- repository, commit, submodule หรือ source ที่สร้างขึ้นล้าสมัยหรือกำกวม
- ไม่ได้ตรึงเวอร์ชัน compiler, optimizer settings, library หรือ dependency
- deployment script, constructor data, initializer หรือ CREATE2 salt ถูกตัดออก
- ตรวจ chain, address, proxy, beacon หรือ implementation ผิดรายการ
- source, artifact, creation bytecode และ runtime bytecode กระทบยอดกันไม่ได้
- threat model ละเลยผู้มีส่วนเกี่ยวข้อง สิทธิพิเศษ สินทรัพย์ หรือขอบเขตความไว้วางใจ
- specification หรือ invariant มีหน่วย เงื่อนไขก่อนหน้า หรือข้อยกเว้นที่ผิด
- พลาดเส้นทาง admin, guardian, timelock, pause, upgrade หรือ migration
- สมมติฐานเกี่ยวกับ oracle, token, bridge, keeper, governance หรือ chain ล้มเหลว
- การวิเคราะห์แบบสถิตให้ false positive ที่ไม่ได้คัดกรอง
- การตรวจด้วยมนุษย์ การทดสอบ หรือ fuzzing พลาดเส้นทางที่ไม่ถูกสร้าง
- fuzz harness, selector, seed, corpus, depth หรือแบบจำลอง state มีอคติ
- solver timeout ความหมายที่ไม่รองรับ หรือ `unknown` ถูกเข้าใจผิดว่าเป็นข้อพิสูจน์
- ข้อพิสูจน์ที่ถูกต้องทำให้ข้อกำหนดผิดหรือระบบไม่สมบูรณ์เป็นรูปแบบ
- severity อิงชื่อช่องโหว่แทนความสามารถในการโจมตีและผลกระทบ
- มูลค่าความเสี่ยงเชิงทฤษฎีถูกเข้าใจเป็นความเสียหายที่เข้าถึงได้หรือกำไรผู้โจมตี
- การแก้ไขสร้าง regression ข้างเคียงหรือทำลาย invariant ทางเศรษฐกิจ
- proxy storage, initializer, upgrade หรือ migration ทำลายสถานะที่ใช้งานจริง
- ป้ายผ่านการตรวจสอบบดบังประเด็นที่ยอมรับ เปิดอยู่ หรือแก้เพียงบางส่วน
- รายงานถูกมองเป็นประกัน ใบรับรอง การชดเชย หรือการคุ้มครองถาวร

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

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

- **"ไม่มีข้อค้นพบระดับวิกฤตแปลว่าสัญญาปลอดภัย"** ข้อความนี้อธิบายผลที่รายงานในขอบเขต เวลา และชุดวิธีจำกัด ไม่ใช่ข้อบกพร่องทั้งหมดที่อาจมี
- **"coverage สูงหรือไม่พบ fuzz failure พิสูจน์ว่าไม่มีบั๊ก"** ทั้งสองเป็นการวัดโค้ดและเส้นทางที่สร้างขึ้นบางส่วน ไม่ใช่ข้อพิสูจน์ว่าไม่มีข้อบกพร่อง
- **"การพิสูจน์อย่างเป็นทางการยืนยันว่าโปรโตคอลทั้งหมดปลอดภัย"** มันพิสูจน์คุณสมบัติของแบบจำลองที่เข้ารหัสภายใต้สมมติฐาน แต่ specification และระบบรอบข้างยังอาจผิด
- **"Resolved หมายถึง deployment ที่ใช้งานทั้งหมดได้รับการแก้ไข"** การปิดต้องมี retest อิสระและการกระทบยอด build, bytecode, proxy, parameter และ role ของแต่ละ deployment
- **"ผู้ตรวจสอบที่มีชื่อเสียงรับประกันค่าชดเชยหรือการอัปเกรดในอนาคต"** ความรับผิดขึ้นกับสัญญาว่าจ้าง ผู้ใช้อาจไม่ใช่ผู้รับประโยชน์ และโค้ดหรือการตั้งค่าภายหลังอยู่นอก snapshot เดิม

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

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

- [สัญญาอัจฉริยะ](/th/crypto/smart-contract/)
- [สัญญาที่อัปเกรดได้](/th/crypto/upgradeable-contract/)
- [โครงการรางวัลค้นหาช่องโหว่](/th/crypto/bug-bounty/)

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

## แหล่งข้อมูล

- [OWASP Smart Contract Security Verification Standard (SCSVS)](https://scs.owasp.org/SCSVS/) - OWASP (เข้าถึงเมื่อ: 2026-08-13)
- [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity (เข้าถึงเมื่อ: 2026-08-13)
- [Slither, the smart contract static analyzer](https://github.com/crytic/slither) - Crytic (เข้าถึงเมื่อ: 2026-08-13)
- [Invariant Testing](https://www.getfoundry.sh/guides/invariant-testing) - Foundry (เข้าถึงเมื่อ: 2026-08-13)
- [Certora User's Guide](https://docs.certora.com/en/latest/docs/user-guide/index.html) - Certora (เข้าถึงเมื่อ: 2026-08-13)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
- [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (เข้าถึงเมื่อ: 2026-08-13)
- [Contract Metadata](https://docs.soliditylang.org/en/latest/metadata.html) - Solidity (เข้าถึงเมื่อ: 2026-08-13)

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