---
title: "ภาวะอัตวิสัยแบบอ่อน: เช็กพอยต์ที่เชื่อถือได้และการซิงค์ PoS อย่างปลอดภัย"
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.

# ภาวะอัตวิสัยแบบอ่อน: เช็กพอยต์ที่เชื่อถือได้และการซิงค์ PoS อย่างปลอดภัย

> จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

<a id="answer"></a>

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

ภาวะอัตวิสัยแบบอ่อนเป็นโมเดลความปลอดภัยแบบกลไก Proof of Stake (PoS) ซึ่งในนั้นโหนดสามารถตรวจสอบบล็อก การเปลี่ยนแปลงสถานะ การลงคะแนน และการเลือกสาขาตามกฎของโปรโตคอลหลังจากเริ่มจากเช็กพอยต์ที่เพียงพอใหม่ล่าสุดที่ได้รับผ่านช่องทางที่เชื่อถือได้หรือยืนยันโดยสังคม ข้อมูลอัตวิสัย "อ่อน" คือจุดเริ่มต้น ไม่ใช่การอนุญาตให้เลือกบล็อกภายหลังโดยไม่จำกัด: เมื่อยึดแน่นแล้ว โหนดต้องปฏิเสธประวัติที่ไม่รวมเช็กพอยต์และตรวจสอบไปข้างหน้าอย่างปกติ

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

บน Ethereum เช็กพอยต์ภาวะอัตวิสัยแบบอ่อนคือ `epoch` และ `block_root` ที่ไคลเอนต์ถือว่าเป็นแองเคอร์ที่แน่นอน การซิงค์ที่ประสบความสำเร็จต้องพิสูจน์ว่าเส้นทางมาตรฐานมีรากนั้นในยุคดังกล่าว; ความไม่ตรงกันถือเป็นความล้มเหลวอย่างร้ายแรง ไม่ใช่การลงคะแนนเลือกสาขา เช็กพอยต์ภาวะอัตวิสัยแบบอ่อนยังแตกต่างจากเช็กพอยต์ที่สิ้นสุดตามปกติ: หากโหนดพบประวัติที่สิ้นสุดสองข้อขัดแย้งโดยไม่มีความทรงจำก่อนหน้านี้ กฎของไฟนอลิตี้เพียงอย่างเดียวไม่สามารถระบุได้ว่าประวัติทางสังคมใดเป็นมาตรฐาน.

อย่าสรุปกลไกของ Ethereum ให้เป็นสากล ไคลเอนต์แสง CometBFT เริ่มจากหัวข้อที่เชื่อถือได้ภายใน `trusting_period` ที่กำหนดค่าไว้และถ่ายโอนความเชื่อถือโดยใช้การทับซ้อนของชุดผู้ตรวจสอบ ลายเซ็น ขอบเขตเวลา และพยาน ในทางกลับกัน งานวิจัย Ouroboros Genesis กำหนดกฎการเลือกเชนที่ตั้งใจจะเริ่มต้นจากบล็อกกำเนิดที่เชื่อถือได้ภายใต้โมเดลความปลอดภัยที่ระบุไว้ ดังนั้น "Proof of stake" จึงไม่ได้หมายถึงรูปแบบเช็คพอยต์เดียว สูตรระยะเวลาเดียว หรือกระบวนการบูตสตาร์ทเดียว

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

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

## วิธีการตรวจสอบบูทสแตรปแบบอัตนัยอ่อน

### 1. ระบุโปรโตคอลและโมเดลความปลอดภัยที่แน่นอน

บันทึก `network`, `chain ID`, รากหรือแฮชเริ่มต้น, ฟอร์กหรือรันไทม์ที่ใช้งาน, เวอร์ชันไคลเอนต์, ประเภทเช็คพอยต์ และข้อกำหนดฉันทามติ กำหนดว่าระเบียบโปรโตคอลต้องการเช็คพอยต์สังคมล่าสุด, เฮดเดอร์ที่เชื่อถือได้พร้อมชุดผู้ตรวจสอบ, เชนหลักฐานความสมบูรณ์สุดท้าย, หรือเพียงแค่เริ่มต้นภายใต้โมเดลที่ต่างกัน ห้ามปลูกถ่าย Ethereum ของ `compute_weak_subjectivity_period` หรือ CometBFT ของ `trusting_period` ไปยังเชนอื่นโดยไม่ปฏิบัติตามกฎของมัน

### 2. ตัดสินใจว่าความไว้วางใจที่มีอยู่ยังคงใช้งานได้อยู่หรือไม่

ตรวจสอบเช็กพอยต์ที่เสร็จสมบูรณ์ล่าสุดที่ได้รับการยืนยันในเครื่องของโหนด ยุคหรือความสูงและเวลา แหล่งเวลาในปัจจุบัน และการกู้คืนฐานข้อมูลใด ๆ คำนวณอายุโดยใช้กฎและสถานะสดของโปรโตคอล ไม่ใช่โดยประมาณปฏิทินที่จำได้ สำหรับ Ethereum คู่มือ Phase 0 จะทดสอบ `current_epoch <= ws_state_epoch + ws_period`; Electra เปลี่ยนการคำนวณช่วงเวลาให้ขึ้นอยู่กับยอดรวมของยอดคงเหลือที่ใช้งานอยู่และการเปลี่ยนแปลงของยอดคงเหลือ หากความน่าเชื่อถือหมดอายุ ให้รับแองเคอร์ใหม่จากช่องทางภายนอก แทนที่จะพยายามมากขึ้นกับเพียร์ที่ไม่น่าเชื่อถือ

### 3. เข้าถึงและยืนยันเช็กพอยต์

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

### 4. ผูกทุกสนามตรวจสอบ

ตรวจสอบเครือข่ายและเอกลักษณ์ของเจเนซิสก่อนค่าเช็กพอยต์ รักษารากทั้งหมดโดยไม่ตัดทอนและจับคู่กับยุคหรือความสูงที่แน่นอน ระบุสถานะหากจำเป็น รุ่นฟอร์ก และเวลาการได้มา คู่มือของ Ethereum ใช้ `block_root:epoch_number`; การเริ่มต้น CometBFT ยังผูกกับเฮดเดอร์ที่เชื่อถือได้และชุดผู้ตรวจสอบรวมถึงพารามิเตอร์ความเชื่อถือ รากที่ถูกต้องแต่แนบกับเชนหรือความสูงที่ผิดไม่ใช่จุดยึดที่ถูกต้อง

### 5. บังคับเส้นทางซิงโครไนซ์ให้ปิดล้มเหลว

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

### 6. แยกชั้นที่ได้รับการยืนยันและไม่ได้รับการยืนยัน

ติดตามความเชื่อมั่นของเช็กพอยต์, การตรวจสอบบล็อกบีคอนหรือความเห็นพ้อง, สถานะ payload การดำเนินการ, การซิงค์สถานะการดำเนินการ, การเติมข้อมูลย้อนหลัง และหลักฐานของแอปพลิเคชันแยกจากกัน optimistic sync Ethereum อนุญาตให้ `ExecutionPayload` ของแองเคอร์เช็กพอยต์ถือว่าเป็น `VALID` โดยไม่ต้องให้กับเอนจิ้นการดำเนินการก่อน ในขณะที่โหนดสถานะ optimisticไม่สามารถทำหน้าที่ผู้ตรวจสอบได้ การเติมข้อมูลย้อนหลังเช็กพอยต์ Lighthouse ตรวจสอบความสมบูรณ์ของ hash-chain ประวัติศาสตร์และลายเซ็นของผู้เสนอ แต่โดยค่าเริ่มต้นจะไม่สร้างสถานะประวัติศาสตร์ทั้งหมด

### 7. รีเฟรช ตรวจสอบ และซ้อมการฟื้นฟู

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

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

## ตัวอย่างที่มีการทำงาน

### เช็กพอยต์ Ethereum โดยมีช่องว่างเหลืออยู่

ใช้รัฐตัวอย่างซึ่งการคำนวณอ้างอิง Electra ที่ใช้ได้ให้ค่า `ws_period = 3,532 epochs` สมมติว่า `current_epoch = 420,000` และเช็กพอยต์ที่ยืนยันอิสระคือ `checkpoint_epoch = 418,200`:

`checkpoint_age = 420,000 - 418,200 = 1,800 epochs`.

การทดสอบความใหม่ของไกด์คือ `420,000 <= 418,200 + 3,532` ดังนั้นเช็กพอยต์อยู่ภายในช่วงเวลา ที่ `32 slots * 12 seconds = 6.4 minutes per epoch` อายุของมันคือ `1,800 * 6.4 / 1,440 = 8 days` พื้นที่ว่างที่เหลือคือ `3,532 - 1,800 = 1,732 epochs` หรือ `1,732 * 6.4 / 1,440 = 7.6978 days` สิ่งนี้ใช้ช่วงเวลาตารางอ้างอิง ไม่ใช่คำสัญญาจากเครือข่ายสด ไคลเอนต์ต้องคำนวณจากฟอร์กและสถานะจริง

### เช็กพอยต์หมดอายุไม่ได้รับการซ่อมแซมโดยเพียร์อื่นๆ

สมมติว่า `current_epoch = 500,000`, `checkpoint_epoch = 496,000`, และ `ws_period = 3,532 epochs` ที่ใช้ได้:

`checkpoint_age = 500,000 - 496,000 = 4,000 epochs`.

เนื่องจาก `500,000 > 496,000 + 3,532` เช็กพอยต์ล้าสมัยโดย `4,000 - 3,532 = 468 epochs` ที่ 6.4 นาทีต่อช่วงเวลา นั่นคือ `468 * 6.4 / 60 = 49.92 hours` เกินขอบเขต การดาวน์โหลดรูทที่หมดอายุเดียวกันจากเพื่อน 100 ไม่สามารถคืนสมมติฐานได้ ผู้ปฏิบัติการจึงต้องมีเช็กพอยต์ที่เพียงพอและล่าสุดจากช่องทางที่เชื่อถือได้และสนับสนุนกัน

### จำนวนแหล่งที่มา เทียบกับ ความเป็นอิสระของแหล่งที่มา

ผู้ปฏิบัติการได้รับคำตอบห้าฉบับ สี่ฉบับรายงาน `epoch = 600,000` และรากเต็มที่เหมือนกันที่มีป้ายชื่อ `root_A` ขณะที่อีกหนึ่งฉบับรายงานรากเต็มที่ต่างออกไปที่มีป้ายชื่อ `root_B` การสอบสวนพบว่าเว็บไซต์ที่เห็นด้วยทั้งสามทั้งหมดเป็นพร็อกซีของโหนดที่โฮสต์เดียวกัน; ฉบับที่สี่คือโหนดของผู้ปฏิบัติการเอง ข้อตกลงที่ปรากฏคือ `4 / 5 = 80%` แต่แทนเพียงสองสายพันธุ์อิสระ ภายใต้นโยบายที่ต้องมีเส้นทางการบริหารและข้อมูลอิสระสามเส้น ทางผ่านยังไม่ได้รับการอนุมัติ ผู้ปฏิบัติการอิสระคนที่สามยืนยัน `root_A` บริการที่ไม่เห็นด้วยถูกแยกออก และบันทึกแหล่งที่มาชี้แจงการตัดสินใจดังกล่าว

### งบประมาณระยะเชื่อถือแบบ CometBFT

พิจารณาห่วงเชนที่กำหนดค่าด้วย `unbonding_period = 21 days` และตัวดำเนินการที่เลือก `trusting_period = 14 days` ซึ่งสอดคล้องกับข้อกำหนดว่าระยะเวลาที่เชื่อถือได้จะต้องสั้นกว่าการยกเลิกพันธะ ส่วนหัวที่เชื่อถือได้อายุ `11 days` มีพื้นที่ว่าง `14 - 11 = 3 days` เป้าหมายการรีเฟรชประจำวันยังคงมีส่วนเผื่อการดำเนินงาน หากไคลเอนต์กลับมาหลัง `16 days` ส่วนหัวจะเกินระยะเวลาที่เชื่อถือได้สองวันและต้องถูกแทนที่ผ่านการเริ่มต้นที่เชื่อถือได้ใหม่ สูตรยุคสมัย Ethereum จะไม่ตัดสินกรณี CometBFT นี้

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

## ความเสี่ยงและความล้มเหลวในการทบทวน

- **เครือข่ายผิด:** รากที่ถูกต้องจากเทสต์เน็ต ฟอร์ก เชนที่คัดลอก หรือเจเนซิสอื่น อาจยึดโหนดไว้กับประวัติที่ผิด
- **เช็กพอยต์ล้าสมัย:** รากที่อยู่นอกช่วงที่ใช้ได้ไม่รองรับสมมติฐานเรื่องชุดผู้ตรวจสอบล่าสุดอีกต่อไป
- **ใช้สูตรช่วงเวลาผิด:** การอัปเกรดฟอร์ก ยอดคงเหลือผู้ตรวจสอบ กฎการหมุนเวียน อันบอนดิง และพารามิเตอร์ความปลอดภัยอาจเปลี่ยนขอบเขต
- **แหล่งข้อมูลเป็นจุดล้มเหลวเดียว:** หลายปลายทางอาจใช้โหนด บัญชีคลาวด์ ฐานข้อมูล ผู้ให้บริการ DNS หรือผู้ดำเนินการเดียวกัน
- **ช่องทางเผยแพร่ถูกเจาะ:** รุ่นซอฟต์แวร์ เว็บไซต์ แพ็กเกจ คำตอบ DNS หรือข้อความสนับสนุนที่เป็นอันตรายอาจสับเปลี่ยนเช็กพอยต์
- **เปรียบเทียบข้อมูลแบบตัดทอน:** การเทียบเพียงคำนำหน้า ภาพหน้าจอ หรือตัวระบุที่จัดรูปแบบ อาจซ่อนความต่างของรากฉบับเต็ม
- **ฟิลด์ไม่ตรงกัน:** รากที่ถูกต้องเมื่อจับคู่กับเอพอค ความสูง สถานะ ฟอร์ก หรือเชนที่ผิด ก็ไม่ใช่เช็กพอยต์เดียวกัน
- **ถอยไปใช้เสียงข้างมากของเพียร์:** โหนดที่ถูกโจมตีแบบอีคลิปส์อาจเห็นเพียร์ฝ่ายตรงข้ามจำนวนมาก จำนวนเพียร์ไม่ลบล้างแองเคอร์ที่เชื่อถือได้
- **ถอยกลับโดยไม่แจ้ง:** ไคลเอนต์หรือแรปเปอร์ที่ละเลยเช็กพอยต์ซึ่งถูกปฏิเสธจะทำลายการควบคุมแบบหยุดเมื่อผิดพลาด
- **ประวัติสุดท้ายที่ขัดแย้งกัน:** โหนดใหม่แก้ความล้มเหลวของฉันทามติไม่ได้เพียงเพราะทั้งสองแขนงติดป้ายว่าสิ้นสุดแล้ว
- **นาฬิกาผิด:** เวลาท้องถิ่นที่คลาดเคลื่อนอาจทำให้การตรวจสล็อต เอพอค อายุ ช่วงความเชื่อถือ และเฮดเดอร์อนาคตผิดพลาด
- **สับสนสถานะแบบ optimistic:** บล็อกฉันทามติที่นำเข้าอาจยังมี execution payload ที่ไม่ได้ตรวจสอบครบถ้วน
- **ทำหน้าที่ผู้ตรวจสอบเร็วเกินไป:** การลงนามขณะอยู่ในสถานะ optimistic ยังซิงค์ไม่เสร็จ หรือใช้แองเคอร์ไม่แน่นอน อาจทำให้โหวตผิดหรือถูกสแลช
- **สับสนความครบถ้วนของประวัติ:** แม้เฮดปัจจุบันถูกต้อง การซิงค์จากเช็กพอยต์และการ backfill อาจไม่มีสถานะย้อนหลังทั้งหมด
- **ลายเซ็น backfill ไม่ถูกต้อง:** บล็อกย้อนหลังที่เชื่อมด้วยแฮชยังต้องผ่านการตรวจลายเซ็นผู้เสนอตามที่โปรโตคอลกำหนด
- **หลักฐานชั้น execution หรือแอปไม่เพียงพอ:** การยึดโยงฉันทามติไม่ได้พิสูจน์ค่า RPC ข้ออ้างของสัญญา หรือดัชนีนอกเชนใด ๆ
- **ช่องว่างด้านความพร้อมของข้อมูล:** การรู้ state root ไม่รับประกันว่าจะเข้าถึง body, Blob, witness หรือบันทึกย้อนหลังทุกชิ้น
- **แผนกู้คืนหมดอายุ:** หากเพิ่งพบว่าเช็กพอยต์หมดอายุระหว่างเหตุขัดข้อง ผู้ดำเนินการอาจหาแหล่งอิสระไม่ได้
- **การประสานงานทางสังคมถูกครอบงำ:** ฝ่ายกำกับดูแล ทีมไคลเอนต์ บล็อกเอ็กซ์พลอเรอร์ เอ็กซ์เชนจ์ และผู้ดำเนินการอาจมีแรงจูงใจหรือจุดพึ่งพาร่วมกัน
- **เหมารวมว่าใช้ได้ทุกระบบ:** การออกแบบ PoS อื่นอาจใช้สมมติฐาน เชนพิสูจน์ ช่วงความเชื่อถือ หรือหลักประกันการบูตจากเจเนซิสที่ต่างกัน

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

## ความเข้าใจผิดทั่วไป

### ภาวะอัตวิสัยแบบอ่อนหมายความว่ากฎของโปรโตคอลเป็นเรื่องอัตวิสัยหลังจากเริ่มต้นหรือไม่?

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

### เช็คพอยต์ที่เสร็จสมบูรณ์ใด ๆ ถือเป็นเช็คพอยต์บูตสแตรปที่ปลอดภัยโดยอัตโนมัติหรือไม่?

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

### การซิงค์จากเจเนซิสจะช่วยแก้ปัญหาการโจมตีระยะไกลได้หรือไม่?

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

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

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

### สามารถเชื่อถือเช็กพอยต์ที่เขียนโค้ดแน่นอนได้ตลอดไปหรือไม่?

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

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

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

- [ความแน่นอนสุดท้าย](/th/crypto/finality/)
- [กฎการเลือกฟอร์ก](/th/crypto/fork-choice-rule/)
- [การพิสูจน์ความเป็นเจ้าของเหรียญ](/th/crypto/proof-of-stake/)
- [ฟัน](/th/crypto/slashing/)
- [ไคลเอนต์แบบเบา](/th/crypto/light-client/)

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

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

- [ภาวะอัตวิสัยแบบอ่อน](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (เข้าถึง: 2026-08-19)
- [ขั้นตอน 0 -- คู่มือ Weak Subjectivity](https://ethereum.github.io/consensus-specs/specs/phase0/weak-subjectivity/) - Ethereum ข้อกำหนดฉันทามติ (เข้าถึง: 2026-08-19)
- [Electra -- คู่มือ Weak Subjectivity](https://ethereum.github.io/consensus-specs/electra/weak-subjectivity/) - Ethereum ข้อกำหนดฉันทามติ (เข้าถึง: 2026-08-19)
- [เฟส 0 -- อินเทอร์เฟซ P2P](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Ethereum ข้อกำหนดฉันทามติ (เข้าถึง: 2026-08-19)
- [การซิงค์แบบมองโลกในแง่ดี](https://ethereum.github.io/consensus-specs/sync/optimistic/) - Ethereum ข้อกำหนดฉันทามติ (เข้าถึง: 2026-08-19)
- [การซิงค์เช็กพอยต์](https://lighthouse-book.sigmaprime.io/advanced_checkpoint_sync.html) - Lighthouse Book (เข้าถึง: 2026-08-19)
- [การยืนยันหลักของ CometBFT](https://docs.cometbft.com/v0.38/spec/light-client/verification/) - CometBFT (เข้าถึง: 2026-08-19)
- [Ouroboros Genesis: บล็อกเชนแบบ Proof-of-Stake ที่ประกอบได้พร้อมความพร้อมใช้งานแบบไดนามิก](https://eprint.iacr.org/2018/378.pdf) - IACR Cryptology ePrint Archive (เข้าถึง: 2026-08-19)

Source: https://wiki.fcontext.com/th/crypto/weak-subjectivity/index.mdx