# Chain reorganization {% embed url="" %} เนิื้อหาในคลิปมีการใช้ AI ในการสร้างเสียง และเนื้อหาไม่ครบถ้วนเท่าบทความด้านล่าง จัดทำเพื่อใครที่ต้องการทำความเข้าใจแบบพื้นฐานก่อนจะลงลึก {% endembed %} Chain reorganization (หรือ “chain reorg”) คือกระบวนการที่เครือข่ายบล็อกเชนเปลี่ยนแปลงประวัติธุรกรรมโดยการแทนที่ชุดบล็อกเดิมด้วยชุดบล็อกใหม่ที่ยาวกว่า หรือกล่าวคือ เมื่อเกิดสาขา (fork) ของเชน บล็อกเชนจะเลือกรับเชนที่มีการขุดสะสมมากที่สุด (longest chain) เป็นเชนหลัก จึงส่งผลให้บล็อกบางส่วนในเชนเดิมที่สั้นกว่า (หรือ “stale blocks”) ถูกยกเลิกการใช้งาน กระบวนการนี้ทำให้โหนดทั้งหมดในเครือข่ายมีสำเนาบัญชีแยกประเภท (ledger) เดียวกันตามกฎ “เชนที่ยาวที่สุด” ของบิตคอยน์ ### กลไกการเกิด Chain Reorg ในการขุดบิตคอยน์ โหนดหลายแห่งแข่งขันกันแก้สมการและผลิตบล็อกใหม่ในเวลาเดียวกัน เนื่องจากการแพร่กระจายของบล็อกในเครือข่ายอาจมีความล่าช้า จึงอาจจะเกิดเหตุการณ์ที่ **สองโหนดขุดบล็อกขึ้นมาได้พร้อมกัน** ตัวอย่างเช่น สมมุติว่ามีโหนดสองตัวขุดบล็อกใหม่พร้อมกัน โหนดบางตัวจะรับบล็อกตัวแรกที่มาถึงก่อน และบล็อกอีกชุดหนึ่งถูกเก็บไว้เป็นบล็อกสำรอง (stale block) เมื่อมีการขุดบล็อกใหม่ขึ้นมาอีกบล็อกหนึ่ง หากบล็อกนั้นต่อยอดจากหนึ่งในสองบล็อกเดิมจนทำให้เชนหนึ่งยาวกว่าอีกฝั่ง เชนที่ยาวกว่าจะกลายเป็นเชนหลัก และโหนดจะทำการ **จัดระเบียบเชนใหม่** (reorg) โดยปิดการใช้งานบล็อกในสาขาเดิมที่สั้นกว่า และยอมรับบล็อกชุดใหม่ที่ยาวกว่าเข้ามาแทนที่ ระบบบิตคอยน์ใช้กฎ “เชนที่ยาวที่สุด” (longest-chain rule) ในการตัดสินว่าเชนใดเป็นเชนหลัก นั่นคือโหนดจะเลือกเชนที่มีการขุดสะสมมากที่สุด (ซึ่งโดยทั่วไปคือเชนที่มีบล็อกมากกว่า) ให้เป็นเชนหลัก เพื่อให้ทุกโหนดมีบล็อกเชนเหมือนกัน เมื่อโหนดสองโหนดขุดบล็อกขึ้นมาได้พร้อมกันตามตัวอย่างข้างต้น เกิดเป็นเชนคู่ (fork) ชั่วคราวที่ทำให้โหนดในเครือข่ายไม่แน่ใจว่าจะยึดบล็อกชุดไหน บางโหนดอาจรับบล็อกจากโหนดตัวแรกก่อน บางโหนดรับบล็อกอีกฝั่งก่อน และถืออีกบล็อกชุดหนึ่งเป็นบล็อกหล่น (stale/orphan) ในสถานการณ์นี้ หากมีโหนดอื่นขุดบล็อกเพิ่มขึ้นมา โดยต่อบนหนึ่งในสองเชนที่เกิด fork ขึ้น โหนดทั้งหมดจะมองเห็นว่าเชนหนึ่งมีความยาวมากกว่า เมื่อเป็นเชนที่ยาวกว่า เชนนั้นก็จะได้รับการยอมรับว่าเป็นเชนหลัก และโหนดต่าง ๆ จะทำการ reorganize โดย **ปิดการใช้งาน** บล็อกในเชนที่สั้นกว่าและ **เปิดใช้งาน** บล็อกในเชนที่ยาวกว่าแทน ผลที่ได้คือโหนดทุกเครื่องจะมีสำเนาบัญชีแยกประเภทที่เหมือนกัน และธุรกรรมที่อยู่ในบล็อกเดิมที่ถูกปิดใช้งานจะกลับเข้าสู่พูลเพื่อถูกรวมในบล็อกใหม่ต่อไป ### ประเภทของ Chain Reorg Chain reorg สามารถแบ่งเป็น **สองประเภทหลัก** ได้แก่ * **จัดระเบียบเชนตามธรรมชาติ (Unintentional Reorg):** เกิดจากความล่าช้าของเครือข่ายหรือการขุดบล็อกพร้อมกันโดยไม่ตั้งใจ เช่น การกระจายบล็อกช้าทำให้เกิด fork ชั่วคราว โดยปกติ reorg ประเภทนี้มักเกิดขึ้นบ่อยในขอบเขตเล็ก (เช่น 1–2 บล็อก) และไม่กระทบความเชื่อมั่นของผู้ใช้งาน * **จัดระเบียบเชนจากการโจมตี (Malicious Reorg):** เกิดโดยเจตนาเพื่อเปลี่ยนแปลงประวัติธุรกรรม เช่น **การทำเหมืองแบบเห็นแก่ตัว (Selfish Mining)** ที่ผู้ขุดเก็บบล็อกไว้ไม่เผยแพร่ทันทีเพื่อหวังสร้างเชนส่วนตัวให้ยาวกว่า และ **การโจมตี 51% (Majority Attack)** ที่ผู้โจมตีควบคุมพลังขุด > 50% จึงสามารถสร้างเชนใหม่ให้ยาวกว่าเชนหลักเดิมได้สำเร็จเสมอ นอกจากนี้ การเปลี่ยนแปลงโปรโตคอลหรือ hard fork ของระบบก็อาจทำให้เกิดเชนใหม่ที่แตกต่างกัน และนำไปสู่การ reorg เมื่อเครือข่ายที่เลือกใช้กฎใหม่ ### ความเสี่ยงและผลกระทบ การเกิด chain reorg ส่งผลต่อความปลอดภัยและความน่าเชื่อถือของเครือข่ายบิตคอยน์และผู้ใช้ได้หลายประการ เช่น * **Double Spending:** หากมีการจัดระเบียบเชนโดยเฉพาะจากการโจมตี จะเปิดโอกาสให้ผู้ประสงค์ร้ายทำธุรกรรมแล้วขุดเชนสำรองในลักษณะเดียวกับ “การโจมตีทางเลือก (alternative history attack)” ยกตัวอย่าง ผู้โจมตีอาจส่งเงินให้ร้านค้าและขุดเชนสำรองที่ไม่รวมธุรกรรมนั้นไว้ หากผู้โจมตีขุดเชนสำรองได้ยาวกว่าหลังจำนวนคอนเฟิร์มที่ร้านค้ารับสินค้าแล้ว ผู้โจมตีสามารถเปิดเชนสำรองเพื่อยกเลิกธุรกรรมเดิมและใช้จ่ายบิตคอยน์ซ้ำ (double-spend) ได้สำเร็จ กรณีโหนดที่ควบคุมพลังขุดเกินครึ่งโอกาสสำเร็จจะเป็น 100% เหตุการณ์นี้เป็นภัยคุกคามต่อผู้ให้บริการรับชำระเงินและธุรกิจที่อาจสูญเสียสินค้าหรือเงินไปโดยที่ธุรกรรมเดิมถูกยกเลิก. * **ความล่าช้าในการยืนยันธุรกรรม:** การ reorganize จะทำให้ธุรกรรมบางส่วนที่อยู่ในบล็อกหล่นต้องถูกยกเลิกและส่งกลับไปยังพูล เพื่อรอถูกรวมในบล็อกใหม่ ส่งผลให้ผู้ใช้ต้องรอนานขึ้นกว่าปกติในการยืนยันความถูกต้องของธุรกรรม โดยเฉพาะในกรณีที่ธุรกรรมเหล่านั้นถูกตั้งความหวังไว้สูง ธุรกรรมในบล็อกเดิมที่กลายเป็น stale block จะกลายเป็น “เหมือนไม่เคยเกิดขึ้น” ต่อเครือข่าย หากผู้ใช้นำเหรียญที่ได้จากบล็อกนั้นไปใช้งาน โหนดจะปฏิเสธเพราะเหรียญไม่มีอยู่จริงในเชนหลัก ### กลไกการป้องกันและลดความเสี่ยง เพื่อรับมือกับปัญหา chain reorg เครือข่ายและผู้ใช้งานมักใช้มาตรการต่างๆ ดังนี้: * **การยืนยันหลายชั้น (Confirmation Depth):** ผู้ใช้งานและบริการมักรอให้ธุรกรรมมีการยืนยันหลายครั้งก่อนถือว่าเชื่อถือได้ อย่างที่มีการแนะนำให้รออย่างน้อย 6 คอนเฟิร์มจากบล็อกใหม่บนเชน เพื่อให้มั่นใจว่าการ reorganize แบบขโมยบล็อกหรือการโจมตี 51% มีโอกาสสำเร็จน้อยลงมาก โดยยิ่งรอ block เพิ่ม การแก้ประวัติยิ่งทำได้ยากขึ้น (probabilistic finality) ตัวอย่างเช่น การศึกษาพบว่า หากผู้โจมตีมีพลังขุดเพียง 10% และผู้รับเงินรอ 6 คอนเฟิร์ม โอกาสประสบความสำเร็จในการโจมตี double-spend จะเหลือประมาณ 0.1% * **หลักนิติธรรมของโหนด (Node Validation):** โหนดบิตคอยน์แต่ละตัวจะตรวจสอบกฎของเครือข่ายอย่างเข้มงวด เช่น ตรวจสอบ Proof-of-Work และการต่อเนื่องของบล็อกก่อนรับไว้ในเชนหลัก เมื่อโหนดได้รับเชนที่ยาวกว่าและ valid ตามกฎทั้งหมด โหนดก็จะยอมรับเชนนั้นเป็นเชนหลัก โดยกระบวนการนี้ทำให้เชนหลักไม่สามารถถูกแทนที่ด้วยเชนปลอมได้ง่าย หากเชนแทนที่ไม่มีการขุดสะสมเพียงพอ โหนดแบบเต็ม (full node) ยังช่วยลดความเสี่ยงจากการถูกหลอกด้วยการเชื่อมต่อกับโหนดอื่น ๆ หลายแห่งเพื่อยืนยันว่าได้อยู่บนเชนที่ยาวที่สุดจริง ๆ * **ความสมบูรณ์ (Finality) แบบมีเงื่อนไข:** ถึงแม้บิตคอยน์จะไม่มี finality แบบทันที แต่ระบบใช้กลไก probabilistic finality โดยให้ความเชื่อมั่นของธุรกรรมเพิ่มขึ้นตามจำนวนบล็อกที่เพิ่มมา นอกจากนี้ แนวทางอื่น ๆ เช่น การบันทึกจุดยืนยัน (checkpoints) หรือการพัฒนาคอนเซนซัสใหม่ ก็อาจช่วยให้เกิดความมั่นใจได้มากขึ้น ปัจจุบันการปฏิบัติทั่วไปคือการปรับใช้มาตรการข้างต้นร่วมกัน เช่น รอคอนเฟิร์มหลายชั้นและการรันโหนด เพื่อรักษาไว้ซึ่งความปลอดภัยและความน่าเชื่อถือของเครือข่ายบิตคอยน์ --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://rs0-5.gitbook.io/righttech/common/chain-reorganization.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.