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

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

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

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

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

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

## วิธีทำงาน

1. **เปิดและใส่เงินทุน** ผู้เข้าร่วมตกลงตัวตน กฎแอป ระยะเวลาท้าทาย และการจัดสรรเริ่มต้น แล้วล็อกเงินในสัญญาตัดสินบนเชนหรือสร้างช่องทางจากช่องทางที่มีเงินทุนอยู่ เงินทุนดังกล่าวใช้เป็นยอดกระเป๋าปกติไม่ได้ขณะค้ำประกันช่องทาง
2. **แลกเปลี่ยนสถานะที่ลงนาม** ผู้เข้าร่วมคำนวณสถานะถัดไปที่ถูกต้องและแลกเปลี่ยนลายเซ็นหรือข้อความโปรโตคอลที่สนับสนุนสถานะนั้น สถานะผูกกับรหัสช่องทางเฉพาะและค่าลำดับที่เพิ่มขึ้น เพื่อป้องกันการสับเปลี่ยนลายเซ็นจากช่องทางอื่นหรือรอบเก่า
3. **เก็บชุดข้อมูลสำหรับบังคับใช้** กระเป๋าหรือโหนดเก็บสถานะล่าสุดที่ได้รับการสนับสนุน ลายเซ็น การโอนแบบมีเงื่อนไขที่ค้างอยู่ และข้อมูลเพิกถอนหรือข้อมูลลับตามโปรโตคอล วลี seed อาจกู้กุญแจได้ แต่ไม่ได้กู้ข้อมูลนอกเชนที่เปลี่ยนตลอดเวลาเสมอไป
4. **ดำเนินต่อไปนอกเชน** อัปเดตได้หลายครั้งโดยไม่มีธุรกรรมชั้นฐาน แต่การโอนยังถูกจำกัดด้วยความจุ ผู้เข้าร่วมส่งในทิศทางหนึ่งได้ไม่เกินการจัดสรรปัจจุบันและเงินสำรองของโปรโตคอล การส่งผ่านหลายช่องทางเพิ่มการพึ่งพาสภาพคล่องและความพร้อมในทุกฮอป
5. **ปิดร่วมกันเมื่อทำได้** ผู้เข้าร่วมลงนามผลลัพธ์สุดท้ายและส่งธุรกรรมบนเชนขั้นต่ำตามโปรโตคอล การปิดร่วมกันมักเลี่ยงการแข่งขันช่วงท้าทายและเร็วหรือถูกกว่าการปิดฝ่ายเดียว
6. **ยกระดับข้อพิพาทขึ้นเชน** หากผู้เข้าร่วมหายไปหรือเสนอสถานะล้าสมัย อีกฝ่ายส่งหลักฐานที่บังคับใช้ได้ สัญญาตัดสินใช้กฎลำดับ เวลา และการเปลี่ยนสถานะ แต่ละแบบต่างกัน บางแบบใช้สถานะใหม่ท้าทายสถานะเก่า ส่วนแบบ Lightning ใช้กฎ commitment และ revocation แทนการแข่งขัน nonce สูงสุดทั่วไป
7. **สรุปผลหลังหมดเวลา** เมื่อช่วงท้าทายหรือ timelock สิ้นสุด ผู้เข้าร่วมจึงรับผลลัพธ์ จนกว่าเอาต์พุตทั้งหมดจะถูกแก้ไข ซอฟต์แวร์อาจต้องเฝ้าดูเชน รับมือการ reorganize และเพิ่มค่าธรรมเนียมธุรกรรมที่มีเส้นตาย

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

## ตัวอย่าง

Alice และ Bob เปิดช่องทางการชำระเงินสองฝ่ายอย่างง่าย โดยใส่ฝ่ายละ `5 ETH` ช่องทางจึงควบคุม `10 ETH` สถานะเปิดที่ทั้งคู่ลงนามคือรอบ `0` หากชำระตอนนี้ Alice ได้ `5 ETH` และ Bob ได้ `5 ETH`

Alice จ่าย Bob `1 ETH` ทั้งคู่ตรวจสอบการเปลี่ยนและลงนามรอบ `1` ซึ่งจัดสรร Alice `4 ETH` และ Bob `6 ETH` ต่อมา Bob จ่าย Alice `2 ETH` รอบ `2` จัดสรร Alice `6 ETH` และ Bob `4 ETH` ระหว่างการทำงานแบบร่วมมือ มีเพียงการใส่เงินทุนและการชำระสุดท้ายที่ต้องถึงเชนฐาน

สมมติ Bob ส่งรอบ `1` ในภายหลัง ในแบบที่ตัดสินด้วยรอบสูงสุด Alice ต้องแสดงรอบ `2` ที่ได้รับการสนับสนุนครบก่อนเส้นตาย หากทำได้ สัญญาปฏิเสธผลเก่าและชำระรอบ `2` แต่หากเธอทำรอบ `2` หาย ใช้กุญแจลงนามไม่ได้ ไม่มีสินทรัพย์ฐานสำหรับค่าธรรมเนียม หรือออฟไลน์เลยเส้นตาย โปรโตคอลอนุมานประวัติส่วนตัวไม่ได้ ผลที่บังคับใช้อาจจึงต่างจากอัปเดตล่าสุดที่ตกลงกันจริง

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

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

## ความเสี่ยงและการควบคุม

- **ชำระด้วยสถานะเก่า** เก็บชุดข้อมูลบังคับใช้ล่าสุดให้ครบและทดสอบการกู้คืน ใช้ watchtower ที่เข้ากันได้หลังเข้าใจข้อมูลและอำนาจที่มอบให้แล้ว
- **พลาดช่วงท้าทาย** เฝ้าดูเชนที่ถูกต้องจนเอาต์พุตทั้งหมดถึงที่สุด เผื่อเวลาให้ระบบล่ม การ reorganize ความแออัด และการตอบสนองของคนอย่างสมจริง
- **ค่าธรรมเนียมและความแออัด** เก็บสินทรัพย์ฐานที่ไม่ถูกล็อกและทางเพิ่มค่าธรรมเนียม ข้อพิพาทพร้อมกันจำนวนมากอาจทำให้ระบบแพงในเวลาที่ต้องออกเร่งด่วน
- **กุญแจหรือข้อมูลสถานะสูญหาย** สำรองสถานะตามวิธีในเอกสารของระบบ อย่ากู้ช่องทางที่ยังทำงานจาก snapshot เก่า เว้นแต่โปรโตคอลระบุว่าปลอดภัย
- **ความจุและเส้นทางล้มเหลว** ตรวจสภาพคล่องขาเข้าและขาออก เงินสำรอง เพดานการโอนแบบมีเงื่อนไข ระยะเผื่อหมดอายุ และตัวกลางทุกแห่ง ยอดกระเป๋ารวมไม่ใช่ความจุช่องทางที่ใช้ได้
- **คู่สัญญาและความพร้อม** คู่สัญญามักเขียนทับผลที่ป้องกันถูกต้องไม่ได้ แต่ปฏิเสธอัปเดตหรือปิดร่วมกันและบังคับให้ใช้ทางพิพาทที่ช้ากว่าได้
- **ความเสี่ยงจากการพัฒนา** บั๊กในไคลเอนต์ สัญญาตัดสิน โดเมนลายเซ็น ตรรกะการเปลี่ยน หรือการควบคุมอัปเกรดอาจทำลายหลักประกัน ตรวจการติดตั้งจริงและผลการตรวจสอบ
- **ข้อมูลส่วนตัวรั่วไหล** การอัปเดตนอกเชนไม่ได้ไม่ระบุตัวตนอัตโนมัติ เพียร์ เราเตอร์ ผู้สังเกตการณ์ สำรองข้อมูล และธุรกรรมพิพาทสุดท้ายอาจเผยความสัมพันธ์หรือข้อมูลแอป

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

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

- **“นอกเชนหมายถึงไม่ต้องเชื่อใจโดยไม่ใช้บล็อกเชน”** เส้นทางบังคับใช้บนเชนที่น่าเชื่อถือต่างหากที่ลดความไว้ใจคู่สัญญา ความปลอดภัย ความพร้อม และค่าธรรมเนียมยังสำคัญ
- **“สถานะใดที่ทั้งสองฝ่ายลงนามก็ชำระได้”** กฎเฉพาะโปรโตคอลเรื่องลำดับ ความถูกต้อง ผลสิ้นสุด การเพิกถอน และเวลาเป็นตัวตัดสินว่าหลักฐานใดบังคับได้
- **“วลี seed กู้ทั้งช่องทางได้”** โดยทั่วไปกู้กุญแจ แต่ไม่จำเป็นต้องกู้สถานะล่าสุด ความลับเพิกถอน การโอนค้าง หรือฐานข้อมูลเพียร์
- **“ผู้ใช้จะออฟไลน์ตลอดไปก็ได้”** หลายแบบต้องสังเกตและตอบในเวลาจำกัดด้วยตนเองหรือผ่านบริการเฝ้าติดตามที่มอบหมาย
- **“ความจุช่องทางเท่ากับยอดกระเป๋า”** ต้องผูกเงินกับช่องทาง และความจุใช้ได้ขึ้นกับทิศทาง เงินสำรอง การโอนค้าง และสภาพคล่องเส้นทาง
- **“ช่องทางสถานะแทน Rollup ได้ทุกกรณี”** เหมาะที่สุดกับการโต้ตอบซ้ำระหว่างผู้เข้าร่วมที่รู้จัก แอปที่ต้องการสมาชิกเปิด สถานะส่วนกลางร่วม หรือการประกอบกว้างอาจเหมาะกับ Rollup หรือการทำงานบนเชนปกติกว่า

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

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

- [ค่าธรรมเนียม Gas](/crypto/gas-fee/)
- [HTLC](/crypto/htlc/)
- [เลเยอร์ 2](/crypto/layer2/)
- [Rollup](/crypto/rollup/)
- [สัญญาอัจฉริยะ](/crypto/smart-contract/)

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

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

- [General State Channel Networks](https://doi.org/10.1145/3243734.3243856) - ACM (เข้าถึง: 2026-08-21)
- [Nitro Protocol](https://eprint.iacr.org/2019/219) - Cryptology ePrint Archive (เข้าถึง: 2026-08-21)
- [States & Channels](https://docs.statechannels.org/protocol-tutorial/0010-states-channels/) - State Channels (เข้าถึง: 2026-08-21)
- [BOLT #2: โปรโตคอลเพียร์สำหรับจัดการช่องทาง](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning Specifications (เข้าถึง: 2026-08-21)
- [BOLT #5: คำแนะนำสำหรับการจัดการธุรกรรมบนเชน](https://github.com/lightning/bolts/blob/master/05-onchain.md) - Lightning Specifications (เข้าถึง: 2026-08-21)

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