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

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

รากสถานะคือข้อผูกมัดเชิงการเข้ารหัสขนาด 32 ไบต์ในส่วนหัวบล็อก Ethereum ต่อสถานะโลกหลังประมวลผลบล็อกนั้น สถานะโลกจับคู่ที่อยู่กับบัญชี แต่ละบัญชีผูกมัด nonce ยอดคงเหลือ รากพื้นที่จัดเก็บ และแฮชโค้ด ส่วนรากพื้นที่จัดเก็บของสัญญาแต่ละรายการผูกมัดสล็อตจัดเก็บของบัญชีนั้นอีกชั้นหนึ่ง

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

คำว่า “รากสถานะ” ขึ้นกับโปรโตคอล ปัจจุบัน Ethereum ผูกมัดสถานะชั้นการดำเนินการด้วย Merkle-Patricia trie แบบดัดแปลง เครือข่ายอื่นอาจใช้แบบจำลองสถานะ การเข้ารหัส ฟังก์ชันแฮช หรือโครงสร้างข้อมูลที่รับรองแล้วต่างกัน ชื่อเดียวกันจึงไม่ได้ทำให้รากหรือหลักฐานใช้แทนกันได้

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

## กลไกการทำงาน

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

`S_n = Υ(S_(n-1), B_n)`

ในที่นี้ `S_(n-1)` คือสถานะแม่ `B_n` คือการประมวลผลทั้งหมดที่โปรโตคอลกำหนดสำหรับบล็อกใหม่ และ `S_n` คือสถานะผลลัพธ์ ไคลเอนต์เข้ารหัสสถานะใน state trie แบบกำหนดผลแน่นอนแล้วคำนวณแฮชราก ส่วนหัวบล็อกที่ถูกต้องต้องมีผลเดียวกัน หากไม่ตรงกันไคลเอนต์ต้องถือว่าบล็อกไม่ถูกต้อง

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

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

EIP-1186 กำหนด `eth_getProof` ซึ่งคืนหลักฐานบัญชีและหลักฐานพื้นที่จัดเก็บที่ร้องขอสำหรับบล็อกที่ระบุได้ ผู้ตรวจสอบยังต้องมีแฮชบล็อกหรือรากสถานะที่รับรอง กฎ trie และการเข้ารหัสที่ถูกต้อง และนโยบายการยืนยันหรือความเป็นที่สุดที่เหมาะสม

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

## ตัวอย่าง

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

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

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

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

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

- **รากที่ไม่น่าเชื่อถือ:** หลักฐานที่ถูกต้องต่อรากที่ผู้โจมตีเลือกหรือรากเก่าพิสูจน์จุดอ้างอิงผิด ต้องผูกรากกับแฮชบล็อก ID เชน และหมายเลขบล็อกที่ตรวจสอบแล้ว
- **การจัดระเบียบใหม่และความเป็นที่สุด:** หลักฐานอาจถูกต้องสำหรับบล็อกที่ภายหลังหลุดจากเชนหลัก ควรกำหนดระดับการยืนยันหรือความเป็นที่สุดตามความเสียหายที่แอปรับได้
- **การเข้ารหัสผิด:** การแฮชที่อยู่ RLP เส้นทาง nibble โหนดฝังตัว และคีย์พื้นที่จัดเก็บต้องตรงตามโปรโตคอล ไลบรารีหลักฐาน Merkle แบบไบนารีทั่วไปไม่เพียงพอ
- **ข้อมูลขาดหาย:** รากผูกมัดสถานะ แต่ไม่ทำให้โหนด trie สถานะย้อนหลัง หรือบริการสร้างหลักฐานพร้อมใช้ โหนดที่ตัดข้อมูลอาจให้หลักฐานเก่าไม่ได้
- **การรับประกันเกินจริง:** รากตรงกันตรวจพบการดำเนินการไม่สอดคล้อง แต่ไม่ตรวจสอบตรรกะสัญญา รับรองข้อมูล oracle ป้องกัน endpoint RPC รับประกันมูลค่าสินทรัพย์ หรือหยุดคีย์ที่รั่วจากการอนุมัติธุรกรรม

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

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

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

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

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

- [โมเดลแบบบัญชี](/th/crypto/account-based-model/)
- [ต้นไม้ Merkle](/th/crypto/merkle-tree/)
- [โหนดเต็ม](/th/crypto/full-node/)
- [ไคลเอนต์แบบเบา](/th/crypto/light-client/)
- [การยืนยันบล็อก](/th/crypto/block-confirmation/)

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

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

- [Ethereum Execution Specifications: Block Header](https://ethereum.github.io/execution-specs/src/ethereum/forks/frontier/blocks.py.html) - Ethereum Foundation (เข้าถึง: 2026-08-21)
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum Foundation (เข้าถึง: 2026-08-21)
- [EIP-1186: RPC-Method to get Merkle Proofs](https://eips.ethereum.org/EIPS/eip-1186) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-21)

Source: https://wiki.fcontext.com/th/crypto/state-root/index.mdx