จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้
คำตอบโดยตรง
ภาวะอัตวิสัยแบบอ่อนเป็นโมเดลความปลอดภัยแบบกลไก Proof of Stake (PoS) ซึ่งในนั้นโหนดสามารถตรวจสอบบล็อก การเปลี่ยนแปลงสถานะ การลงคะแนน และการเลือกสาขาตามกฎของโปรโตคอลหลังจากเริ่มจากเช็กพอยต์ที่เพียงพอใหม่ล่าสุดที่ได้รับผ่านช่องทางที่เชื่อถือได้หรือยืนยันโดยสังคม ข้อมูลอัตวิสัย “อ่อน” คือจุดเริ่มต้น ไม่ใช่การอนุญาตให้เลือกบล็อกภายหลังโดยไม่จำกัด: เมื่อยึดแน่นแล้ว โหนดต้องปฏิเสธประวัติที่ไม่รวมเช็กพอยต์และตรวจสอบไปข้างหน้าอย่างปกติ
ปัญหาคือความไม่ชัดเจนทางประวัติศาสตร์ ฝ่ายตรงข้ามที่ได้กุญแจจากผู้ตรวจสอบที่ออกไปแล้วและไม่สามารถถูกลงโทษทางเศรษฐกิจได้ อาจสร้างประวัติศาสตร์ทางเลือกยาวๆ พร้อมลายเซ็นที่ดูเหมือนถูกต้อง โหนดที่สังเกตเห็นเชนมาตรฐานในขณะที่ผู้ตรวจสอบเหล่านั้นยังเสี่ยงถูกสแลช จะเก็บความทรงจำที่เป็นประโยชน์ โหนดใหม่เอี่ยม โหนดที่ฐานข้อมูลถูกลบ หรือโหนดที่ออฟไลน์เกินกว่าหน้าต่างความสดใหม่ที่ปลอดภัยของโปรโตคอล อาจไม่สามารถระบุประวัติศาสตร์ที่เป็นมาตรฐานทางสังคมจากข้อมูลตั้งต้นและข้อความของเพียร์ได้เพียงอย่างเดียว
บน Ethereum เช็กพอยต์ภาวะอัตวิสัยแบบอ่อนคือ epoch และ block_root ที่ไคลเอนต์ถือว่าเป็นแองเคอร์ที่แน่นอน การซิงค์ที่ประสบความสำเร็จต้องพิสูจน์ว่าเส้นทางมาตรฐานมีรากนั้นในยุคดังกล่าว; ความไม่ตรงกันถือเป็นความล้มเหลวอย่างร้ายแรง ไม่ใช่การลงคะแนนเลือกสาขา เช็กพอยต์ภาวะอัตวิสัยแบบอ่อนยังแตกต่างจากเช็กพอยต์ที่สิ้นสุดตามปกติ: หากโหนดพบประวัติที่สิ้นสุดสองข้อขัดแย้งโดยไม่มีความทรงจำก่อนหน้านี้ กฎของไฟนอลิตี้เพียงอย่างเดียวไม่สามารถระบุได้ว่าประวัติทางสังคมใดเป็นมาตรฐาน.
อย่าสรุปกลไกของ Ethereum ให้เป็นสากล ไคลเอนต์แสง CometBFT เริ่มจากหัวข้อที่เชื่อถือได้ภายใน trusting_period ที่กำหนดค่าไว้และถ่ายโอนความเชื่อถือโดยใช้การทับซ้อนของชุดผู้ตรวจสอบ ลายเซ็น ขอบเขตเวลา และพยาน ในทางกลับกัน งานวิจัย Ouroboros Genesis กำหนดกฎการเลือกเชนที่ตั้งใจจะเริ่มต้นจากบล็อกกำเนิดที่เชื่อถือได้ภายใต้โมเดลความปลอดภัยที่ระบุไว้ ดังนั้น “Proof of stake” จึงไม่ได้หมายถึงรูปแบบเช็คพอยต์เดียว สูตรระยะเวลาเดียว หรือกระบวนการบูตสตาร์ทเดียว
แยกภาวะอัตวิสัยแบบอ่อนออกจากทางลัดการซิงค์ การซิงค์แบบเช็กพอยต์สามารถลดเวลาการเริ่มต้นและการประมวลผลสถานะประวัติศาสตร์ได้ แต่ความเร็วไม่ใช่นิยามของความปลอดภัย รากที่เชื่อถือได้ไม่ได้ตรวจสอบความถูกต้องของเว็บไซต์ที่ให้ข้อมูล ไม่ได้ยืนยัน payload การทำงานนอกสมมติฐานที่ระบุโดยไคลเอนต์ ไม่สามารถกู้คืนประวัติที่ถูกตัดทอน พิสูจน์ความพร้อมใช้งานของข้อมูล หรือทำให้ชุดเพียร์ที่ถูกเอาออกไว้มีความซื่อสัตย์
วิธีการตรวจสอบบูทสแตรปแบบอัตนัยอ่อน
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 ความหลากหลายของคู่แข่ง อายุของเช็กพอยต์ และช่องว่างการเติมข้อมูล ซ้อมการกู้คืนจากฐานข้อมูลที่ถูกลบ เช็กพอยต์หมดอายุ แหล่งข้อมูลที่ขัดแย้ง และผู้ให้บริการที่ไม่สามารถใช้งานได้ เก็บบันทึกที่ลงนามของจุดยึดและการตัดสินใจ แต่ไม่ให้เช็กพอยต์ที่เก็บถาวรกลายเป็นเช็กพอยต์เก่าที่เชื่อถือถาวร
ตัวอย่างที่มีการทำงาน
เช็กพอยต์ 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 นี้
ความเสี่ยงและความล้มเหลวในการทบทวน
- เครือข่ายผิด: รากที่ถูกต้องจากเทสต์เน็ต ฟอร์ก เชนที่คัดลอก หรือเจเนซิสอื่น อาจยึดโหนดไว้กับประวัติที่ผิด
- เช็กพอยต์ล้าสมัย: รากที่อยู่นอกช่วงที่ใช้ได้ไม่รองรับสมมติฐานเรื่องชุดผู้ตรวจสอบล่าสุดอีกต่อไป
- ใช้สูตรช่วงเวลาผิด: การอัปเกรดฟอร์ก ยอดคงเหลือผู้ตรวจสอบ กฎการหมุนเวียน อันบอนดิง และพารามิเตอร์ความปลอดภัยอาจเปลี่ยนขอบเขต
- แหล่งข้อมูลเป็นจุดล้มเหลวเดียว: หลายปลายทางอาจใช้โหนด บัญชีคลาวด์ ฐานข้อมูล ผู้ให้บริการ DNS หรือผู้ดำเนินการเดียวกัน
- ช่องทางเผยแพร่ถูกเจาะ: รุ่นซอฟต์แวร์ เว็บไซต์ แพ็กเกจ คำตอบ DNS หรือข้อความสนับสนุนที่เป็นอันตรายอาจสับเปลี่ยนเช็กพอยต์
- เปรียบเทียบข้อมูลแบบตัดทอน: การเทียบเพียงคำนำหน้า ภาพหน้าจอ หรือตัวระบุที่จัดรูปแบบ อาจซ่อนความต่างของรากฉบับเต็ม
- ฟิลด์ไม่ตรงกัน: รากที่ถูกต้องเมื่อจับคู่กับเอพอค ความสูง สถานะ ฟอร์ก หรือเชนที่ผิด ก็ไม่ใช่เช็กพอยต์เดียวกัน
- ถอยไปใช้เสียงข้างมากของเพียร์: โหนดที่ถูกโจมตีแบบอีคลิปส์อาจเห็นเพียร์ฝ่ายตรงข้ามจำนวนมาก จำนวนเพียร์ไม่ลบล้างแองเคอร์ที่เชื่อถือได้
- ถอยกลับโดยไม่แจ้ง: ไคลเอนต์หรือแรปเปอร์ที่ละเลยเช็กพอยต์ซึ่งถูกปฏิเสธจะทำลายการควบคุมแบบหยุดเมื่อผิดพลาด
- ประวัติสุดท้ายที่ขัดแย้งกัน: โหนดใหม่แก้ความล้มเหลวของฉันทามติไม่ได้เพียงเพราะทั้งสองแขนงติดป้ายว่าสิ้นสุดแล้ว
- นาฬิกาผิด: เวลาท้องถิ่นที่คลาดเคลื่อนอาจทำให้การตรวจสล็อต เอพอค อายุ ช่วงความเชื่อถือ และเฮดเดอร์อนาคตผิดพลาด
- สับสนสถานะแบบ optimistic: บล็อกฉันทามติที่นำเข้าอาจยังมี execution payload ที่ไม่ได้ตรวจสอบครบถ้วน
- ทำหน้าที่ผู้ตรวจสอบเร็วเกินไป: การลงนามขณะอยู่ในสถานะ optimistic ยังซิงค์ไม่เสร็จ หรือใช้แองเคอร์ไม่แน่นอน อาจทำให้โหวตผิดหรือถูกสแลช
- สับสนความครบถ้วนของประวัติ: แม้เฮดปัจจุบันถูกต้อง การซิงค์จากเช็กพอยต์และการ backfill อาจไม่มีสถานะย้อนหลังทั้งหมด
- ลายเซ็น backfill ไม่ถูกต้อง: บล็อกย้อนหลังที่เชื่อมด้วยแฮชยังต้องผ่านการตรวจลายเซ็นผู้เสนอตามที่โปรโตคอลกำหนด
- หลักฐานชั้น execution หรือแอปไม่เพียงพอ: การยึดโยงฉันทามติไม่ได้พิสูจน์ค่า RPC ข้ออ้างของสัญญา หรือดัชนีนอกเชนใด ๆ
- ช่องว่างด้านความพร้อมของข้อมูล: การรู้ state root ไม่รับประกันว่าจะเข้าถึง body, Blob, witness หรือบันทึกย้อนหลังทุกชิ้น
- แผนกู้คืนหมดอายุ: หากเพิ่งพบว่าเช็กพอยต์หมดอายุระหว่างเหตุขัดข้อง ผู้ดำเนินการอาจหาแหล่งอิสระไม่ได้
- การประสานงานทางสังคมถูกครอบงำ: ฝ่ายกำกับดูแล ทีมไคลเอนต์ บล็อกเอ็กซ์พลอเรอร์ เอ็กซ์เชนจ์ และผู้ดำเนินการอาจมีแรงจูงใจหรือจุดพึ่งพาร่วมกัน
- เหมารวมว่าใช้ได้ทุกระบบ: การออกแบบ PoS อื่นอาจใช้สมมติฐาน เชนพิสูจน์ ช่วงความเชื่อถือ หรือหลักประกันการบูตจากเจเนซิสที่ต่างกัน
ความเข้าใจผิดทั่วไป
ภาวะอัตวิสัยแบบอ่อนหมายความว่ากฎของโปรโตคอลเป็นเรื่องอัตวิสัยหลังจากเริ่มต้นหรือไม่?
ไม่ โหนดจะยอมรับแองเคอร์เฉพาะที่เพิ่งมาล่าสุดผ่านช่องทางสังคมหรือช่องทางที่เชื่อถือได้ จากนั้นจะใช้การตรวจสอบความถูกต้องแบบกำหนดได้และกฎการเลือกสาขาต่อไป บล็อกที่ขัดแย้งกับแองเคอร์จะถูกปฏิเสธ
เช็คพอยต์ที่เสร็จสมบูรณ์ใด ๆ ถือเป็นเช็คพอยต์บูตสแตรปที่ปลอดภัยโดยอัตโนมัติหรือไม่?
ไม่ มันต้องเป็นของเครือข่ายและประวัติสังคมตามมาตรฐานที่ตั้งใจไว้ ต้องเป็นข้อมูลที่ค่อนข้างใหม่ภายใต้กฎที่ใช้บังคับ รวมถึงมีช่องข้อมูลที่จำเป็น และมาจากเส้นทางที่น่าเชื่อถือและมีการยืนยัน การที่ความสมบูรณ์ถูกสังเกตครั้งแรกในประวัติศาสตร์ที่ผู้โจมตีจัดหาให้ไม่ได้แสดงถึงแหล่งกำเนิด
การซิงค์จากเจเนซิสจะช่วยแก้ปัญหาการโจมตีระยะไกลได้หรือไม่?
ไม่เหมาะสำหรับโพรโตคอลที่โมเดลความปลอดภัยต้องการเช็คพอยต์ความอ่อนแอของซับเจ็กต์ล่าสุด การเล่นซ้ำนิ้วมือที่ถูกต้องภายในตั้งแต่จุดเริ่มต้นไม่บอกโหนดใหม่ว่าประวัติที่ยืนยันแล้วเก่าสองฉบับที่ชุมชนติดตามจริงคือฉบับใด โพรโตคอลอื่นอาจให้การรับประกันการบู๊ตสตาร์ทจากจุดเริ่มต้นที่แตกต่างกันภายใต้สมมติฐานที่ต่างกัน
การซิงค์เช็กพอยต์ตรวจสอบความถูกต้องของการทำงานและสถานะทั้งหมดในอดีตหรือไม่?
ไม่ พฤติกรรมของไคลเอนต์มีหลายชั้นและเฉพาะกับการใช้งาน โหนดอาจเชื่อถือหรือรับเข้า anchor อย่างมองโลกในแง่ดี ซิงค์สถานะการทำงานปัจจุบันแยกกัน และเติมลิงก์บล็อกและลายเซ็นของผู้เสนอเท่านั้นโดยไม่สร้างสถานะทั้งหมดในอดีตใหม่
สามารถเชื่อถือเช็กพอยต์ที่เขียนโค้ดแน่นอนได้ตลอดไปหรือไม่?
ไม่ เช็กพอยต์มักจะถูกผูกกับเครือข่ายและช่วงเวลาเท่านั้น มันยังสามารถมีประโยชน์ในฐานะบันทึกการตรวจสอบหรือข้อจำกัดทางประวัติศาสตร์ แต่โหนดที่การสมมติฐานความน่าเชื่อถือล่าสุดของมันหมดอายุแล้วต้องการจุดยึดที่ใหม่เพียงพอหรือกระบวนการกู้คืนที่ระบุโดยโปรโตคอลนั้น
หัวข้อที่เกี่ยวข้อง
แหล่งที่มา
- ภาวะอัตวิสัยแบบอ่อน - Ethereum.org (เข้าถึง: 2026-08-19)
- ขั้นตอน 0 – คู่มือ Weak Subjectivity - Ethereum ข้อกำหนดฉันทามติ (เข้าถึง: 2026-08-19)
- Electra – คู่มือ Weak Subjectivity - Ethereum ข้อกำหนดฉันทามติ (เข้าถึง: 2026-08-19)
- เฟส 0 – อินเทอร์เฟซ P2P - Ethereum ข้อกำหนดฉันทามติ (เข้าถึง: 2026-08-19)
- การซิงค์แบบมองโลกในแง่ดี - Ethereum ข้อกำหนดฉันทามติ (เข้าถึง: 2026-08-19)
- การซิงค์เช็กพอยต์ - Lighthouse Book (เข้าถึง: 2026-08-19)
- การยืนยันหลักของ CometBFT - CometBFT (เข้าถึง: 2026-08-19)
- Ouroboros Genesis: บล็อกเชนแบบ Proof-of-Stake ที่ประกอบได้พร้อมความพร้อมใช้งานแบบไดนามิก - IACR Cryptology ePrint Archive (เข้าถึง: 2026-08-19)