V God บอกเล่าหลักการออกแบบของ Serenity เป็นการส่วนตัว และพาคุณไปทำความเข้าใจความเฉลียวฉลาดที่อยู

星球君的朋友们

Odaily资深作者

2019-08-16 12:50 (UTC+8)

บทความนี้มีประมาณ 14422 คำ การอ่านทั้งหมดใช้เวลาประมาณ 21 นาที

โปรโตคอลควรพยายามให้มีความเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ในการตัดสินใจ

สรุปโดย AI

หมายเหตุบรรณาธิการ: บทความนี้มาจากUnitimes（ID：Uni-times）หมายเหตุบรรณาธิการ: บทความนี้มาจาก

สำหรับเอกสารหลักการออกแบบของห่วงโซ่ Eth1.0 โปรดดูที่:

https://github.com/ethereum/wiki/wiki/Design-Rationale

ชื่อเรื่องรอง

หลักการออกแบบความสงบ

▲ ความเรียบง่าย: โดยเฉพาะอย่างยิ่งเนื่องจาก PoS เชิงเศรษฐกิจแบบเข้ารหัสลับและการแบ่งส่วนย่อยแบบกำลังสองนั้นมีความซับซ้อนโดยธรรมชาติ โปรโตคอลจึงควรพยายามให้มีความเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ในการตัดสินใจ สิ่งนี้สำคัญมากเพราะจะ:

(i) ลดต้นทุนการพัฒนา

(ii) ลดความเสี่ยงของปัญหาด้านความปลอดภัยที่ไม่ได้ตั้งใจ และ

(iii) ช่วยให้ผู้ออกแบบโปรโตคอลโน้มน้าวใจผู้ใช้ถึงความชอบธรรมของตัวเลือกพารามิเตอร์ได้ง่ายขึ้น

ตามลิงค์นี้ [1] สำหรับข้อมูลพื้นฐาน เมื่อเราต้องการบรรลุการทำงานในระดับหนึ่ง เราไม่สามารถหลีกเลี่ยงความซับซ้อนบางอย่างได้ ระดับความสำคัญของความซับซ้อนคือ: ความซับซ้อนของโปรโตคอลเลเยอร์ 2 > ความซับซ้อนของการใช้งานไคลเอนต์ > ความซับซ้อนของข้อกำหนดโปรโตคอล

▲ความเสถียรในระยะยาว: ตามหลักการแล้ว โปรโตคอลระดับล่างควรสร้างขึ้นเพื่อให้ไม่จำเป็นต้องทำการเปลี่ยนแปลงโปรโตคอลใน 10 ปีขึ้นไป และนวัตกรรมที่จำเป็นใดๆ สามารถนำไปใช้ในระดับที่สูงขึ้นได้ (การใช้งานของลูกค้าหรือข้อตกลง Layer2) .

▲ ความเพียงพอ: ควรมีการสร้างหมวดหมู่แอปพลิเคชันให้มากที่สุดเท่าที่จะทำได้บนโปรโตคอล

▲การตรวจสอบความถูกต้องของไคลเอ็นต์แบบไลท์: เมื่อพิจารณาถึงสมมติฐานด้านความปลอดภัย (เช่น เวลาแฝงของเครือข่าย ขอบเขตงบประมาณของผู้โจมตี ผู้ตรวจสอบความถูกต้องเพียง 1/n หรือเพียงไม่กี่คน) ตรวจสอบข้อมูล O© (ควรตรวจสอบความถูกต้องของห่วงโซ่บีคอนเท่านั้น) ลูกค้าของควรจะสามารถรับการรับประกันทางอ้อมได้ ข้อมูลทั้งหมดในระบบมีอยู่และถูกต้อง แม้ในกรณีที่มีการโจมตี 51% (หมายเหตุ: นี่เป็นหนึ่งในเป้าหมายของมุมมอง "การป้องกันในเชิงลึก")

ชื่อเรื่องรอง

การประนีประนอมระหว่าง Layer1 และ Layer2

ผู้อ่านสามารถอ่านบทความสองบทความก่อนหน้าของฉัน: เลเยอร์ 1 ควรเป็นนวัตกรรมในระยะสั้น แต่น้อยลงในระยะยาว [2] และ Sidechains vs Plasma vs Sharding [3]

ในการออกแบบโปรโตคอลบล็อกเชนใดๆ มีความแตกต่างระหว่างการแนะนำคุณสมบัติเพิ่มเติมที่เลเยอร์ 1 (นั่นคือเลเยอร์ฉันทามติ) กับการสร้างโปรโตคอลเลเยอร์ 1 ที่รัดกุมมากขึ้นและอนุญาตให้สร้างฟีเจอร์เหล่านี้บนเลเยอร์ 2 (นั่นคือ แอปพลิเคชัน ชั้น) แต่ละคนมีการแลกเปลี่ยน:

อาร์กิวเมนต์ที่สนับสนุน Layer2:
ลดความซับซ้อนของชั้นฉันทามติ (ดู "ความเรียบง่าย" ที่กล่าวถึงข้างต้น);
ลดความจำเป็นในการแก้ไขโปรโตคอลเลเยอร์ (ดู "ความเสถียรในระยะยาว" ที่กล่าวถึงข้างต้น):
-- ลดความเสี่ยงของการไม่สามารถบรรลุฉันทามติ;
-- ลดภาระงานในการกำกับดูแลโปรโตคอลและความเสี่ยงทางการเมือง
มีความยืดหยุ่นและความสามารถในการนำแนวคิดใหม่ๆ ไปใช้ได้มากขึ้นเมื่อเวลาผ่านไป
อาร์กิวเมนต์ที่สนับสนุน Layer1:
ลดความเสี่ยงของการหยุดชะงักของความคืบหน้าเนื่องจากขาดกลไกในการบังคับให้ทุกคนอัปเกรดเป็นโปรโตคอลใหม่ (เช่น การฮาร์ดฟอร์ก)
อาจลดความซับซ้อนของระบบโดยรวม
หาก Layer1 ไม่แข็งแกร่งเพียงพอ เป็นไปไม่ได้ที่จะสร้างระบบ Layer2 ที่มีประสิทธิภาพตามที่ต้องการบน Layer1 (ดู "ความมากมาย" ที่กล่าวถึงข้างต้น)
การออกแบบของ Ethereum 2.0 ส่วนใหญ่ทุ่มเทเพื่อรักษาสมดุลระหว่างเลเยอร์ 1 และเลเยอร์ 2 อย่างระมัดระวัง ซึ่งรวมถึง (i) การดำเนินการโค้ดที่สมบูรณ์ของทัวริงและเต็มไปด้วยสถานะ (ii) ความสามารถในการปรับขนาดในแง่ของความถูกต้องของข้อมูลและการคำนวณ และ (iii) เวลาในการยืนยันบล็อกที่เร็วขึ้นซึ่งมีความสำคัญอย่างยิ่งต่อการนำโปรโตคอลไปใช้ เพศ] มีความจำเป็นมากเนื่องจาก:
หากไม่มีการใช้งาน (i) จะไม่สามารถสร้างแอปพลิเคชันเลเยอร์ 2 ด้วยโมเดลความน่าเชื่อถือที่แข็งแกร่งได้
หากไม่มี (ii) ความสามารถในการขยายขนาดจะถูกจำกัดไว้เฉพาะเทคโนโลยี เช่น ช่องสัญญาณของรัฐหรือพลาสมา ซึ่งมีความท้าทายในการปรับขนาดและล็อกเงินทุน และ/หรือออกจากระบบตามขนาด
หาก (iii) ไม่บรรลุผล ก็จะไม่มีทางทำธุรกรรมที่รวดเร็วโดยไม่ใช้เทคโนโลยีช่องทาง ซึ่งมีความท้าทายในแง่ของการส่งเสริมและการล็อคเงินทุนและ/หรือการออกจากระบบขนาดใหญ่
แต่ Ethereum 2.0 ยังตั้งใจทิ้งคุณสมบัติอื่น ๆ ไว้ในเลเยอร์ 2: (i) ความเป็นส่วนตัว (ii) ภาษาโปรแกรมระดับสูง (iii) ที่เก็บข้อมูลสถานะที่ปรับขนาดได้และ (iv) รูปแบบลายเซ็น คุณลักษณะเหล่านี้ถูกปล่อยให้อยู่ในชั้นที่ 2 เนื่องจากลักษณะเหล่านี้เป็นพื้นที่ของนวัตกรรมที่รวดเร็ว โซลูชันที่มีอยู่จำนวนมากมีลักษณะเฉพาะที่แตกต่างกัน และการแลกเปลี่ยนเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้เพื่อให้ได้โซลูชันที่ดีกว่าและใหม่กว่า ตัวอย่างเช่น:
ความเป็นส่วนตัว: Ring Signature + Confidential Values เทียบกับ ZK-SNARKs และ ZK-STARKs, Rollup vs. ZEXE เป็นต้น
ภาษาการเขียนโปรแกรมระดับสูง: การเขียนโปรแกรมเชิงประกาศเทียบกับการเขียนโปรแกรมที่จำเป็น ไวยากรณ์ คุณลักษณะการตรวจสอบอย่างเป็นทางการ ระบบประเภท คุณลักษณะการป้องกัน (เช่น การห้ามใช้ฟังก์ชันที่ไม่บริสุทธิ์ในนิพจน์ทางคณิตศาสตร์) คุณลักษณะความเป็นส่วนตัวที่ได้รับการสนับสนุนโดยกำเนิด ฯลฯ
รูปแบบลายเซ็น: ลายเซ็น Schnorr, ลายเซ็น BLS, ลายเซ็น Lamport เป็นต้น

ชื่อเรื่องรอง

ดู:

https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51

ชื่อเรื่องรอง

ทำไมต้องใช้แคสเปอร์?

อัลกอริทึมฉันทามติ Proof-of-stake (PoS) ในปัจจุบันแบ่งออกเป็นสามค่ายหลัก:
อัลกอริธึมการพิสูจน์การเดิมพันที่ได้รับแรงบันดาลใจจาก Satoshi Nakamoto (เช่น Peercoin (Peercoin), NXT (Future Coin), Ouroboros (อัลกอริทึมที่สอดคล้องกันของ Cardano) และอัลกอริทึมเชิงปฏิบัติอื่นๆ)
อัลกอริทึม Proof-of-Stake ที่ได้รับแรงบันดาลใจจาก PBFT (Byzantine Fault Tolerance ที่ใช้งานได้จริง) (เช่น Tendermint, Casper FFG, Hotstuff เป็นต้น)
CBC Casper (ดู [4] และ [5] สำหรับคำอธิบาย)

ในสองค่ายหลังมีคำถามว่าควรใช้การวางเงินประกัน (การปักหลัก) และการเฉือน (การปักหลัก) อย่างไรและควรใช้อย่างไร กลไกการพิสูจน์การเดิมพันทั้งสามนั้นเหนือกว่าการพิสูจน์การทำงาน (PoW) แต่เราต้องการปกป้องแนวทางที่ Ethereum 2.0 ใช้ในบทความนี้

เจ็บแสบ

Ethereum 2.0 ใช้กลไก Slashing (ค่าปรับจากการฝากเงิน) กล่าวคือ ผู้ตรวจสอบที่ตรวจพบว่าประพฤติตนไม่เหมาะสมจะถูกลงโทษ การลงโทษที่เบาที่สุดคือการทำลาย ~1% ของคำสัญญา และการลงโทษที่ร้ายแรงที่สุดคือการทำลายผู้ตรวจสอบทั้งหมด เงินฝาก

เราปกป้องการใช้กลไกการฟันด้วยเหตุผลดังต่อไปนี้:
ต้นทุนการโจมตีที่เพิ่มขึ้น: สิ่งที่เราต้องการให้แน่ใจว่าการโจมตี 51% ใด ๆ บนเครือข่าย PoS จะส่งผลให้ผู้โจมตีต้องเสียค่าธรรมเนียมจำนวนมาก (เช่น มูลค่าหลายร้อยล้านดอลลาร์ในการกู้คืนจากการโจมตี สิ่งนี้ทำให้แคลคูลัสการโจมตี/ป้องกันไม่เอื้ออำนวยต่อผู้โจมตีอย่างมาก และสามารถทำให้การโจมตีไม่เกิดผลได้

เอาชนะภาวะกลืนไม่เข้าคายไม่ออกที่เกิดจากผู้ตรวจสอบ: วิธีที่เป็นไปได้จริงและตรงที่สุดสำหรับโหนดที่จะเริ่มเบี่ยงเบนจากพฤติกรรมที่ "ซื่อสัตย์" คือความประมาทเลินเล่อ (เช่น ผู้ตรวจสอบควรเข้าร่วมในการตรวจสอบ แต่ไม่เข้าร่วมในการตรวจสอบ หรือลงนามเมื่อ ไม่ควรเซ็นชื่อ เป็นต้น) ภาวะที่กลืนไม่เข้าคายไม่ออกที่เกิดจากตัวตรวจสอบมีรายละเอียดอยู่ใน [6] และการขุด Bitcoin SPV [7] เป็นตัวอย่างของเหตุการณ์นี้ ซึ่งจะนำไปสู่ผลลัพธ์ที่ร้ายแรงมาก บทลงโทษในการตรวจสอบสำหรับผู้ตรวจสอบที่ไม่ซื่อสัตย์ช่วยบรรเทาปัญหาที่กลืนไม่เข้าคายไม่ออกเหล่านี้

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

ข้อความ

การเลือกอัลกอริทึมที่สอดคล้องกัน

ในบรรดาสามกลุ่มของอัลกอริทึมฉันทามติของ PoS ที่กล่าวถึงข้างต้น มีเพียงสองกลุ่มหลังเท่านั้น (เช่น อัลกอริทึมฉันทามติที่ได้รับแรงบันดาลใจจาก PBFT และ CBC Casper) เท่านั้นที่มีแนวคิดของการสิ้นสุดในอัลกอริทึมทั้งสองนี้ นั่นคือ บล็อกพื้นที่หนึ่งได้รับการยืนยันใน ด้วยวิธีนี้: ก็ต่อเมื่อมีตัวตรวจสอบความถูกต้องในสัดส่วนที่มาก (อัลกอริทึมที่ได้รับแรงบันดาลใจจาก PBFT ต้องการตัวตรวจสอบความถูกต้องอย่างน้อย 1/3 ส่วนอัลกอริทึม CBC Casper ต้องการตัวตรวจสอบความถูกต้องอย่างน้อย 1/4) ทำงานผิดพลาด ดังนั้นบล็อกจะถูกย้อนกลับเมื่อถูกเฉือนเท่านั้น

และค่ายแรก - อัลกอริธึมฉันทามติที่ได้รับแรงบันดาลใจจาก Nakamoto (กฎลูกโซ่ที่ยาวที่สุด) ไม่สามารถบรรลุผลสุดท้ายในแง่นี้ได้

เราเลือก Casper FFG เพียงเพราะมันเป็นอัลกอริธึมที่ง่ายที่สุดที่มีในโปรโตคอลเมื่อบรรลุระดับที่กำหนด ขณะนี้เรากำลังสำรวจการเปลี่ยนไปใช้ CBC Casper ในเฟส 3 ของ Ethereum 2.0

ชื่อเรื่องรอง

Sharding หรือทำไมเราถึงเกลียด Super Node?

สำหรับการขยายตัวของ Layer1 หนึ่งในทางเลือกหลักของการชาร์ดดิ้งคือการใช้ supernodes Supernodes กำหนดให้โหนดที่สอดคล้องกันแต่ละโหนดต้องมีเซิร์ฟเวอร์ที่ทรงพลังเพื่อให้โหนดสามารถประมวลผลธุรกรรมแต่ละรายการแยกกันได้ การแลกเปลี่ยน

การปรับขนาดตาม Supernode นั้นสะดวกเพราะง่ายต่อการติดตั้ง: เป็นแนวทางเดียวกับที่ใช้กับบล็อกเชนปัจจุบันจำนวนมาก ยกเว้นว่าต้องใช้การออกแบบซอฟต์แวร์มากขึ้นเพื่อสร้างในลักษณะที่ขนานกันมากขึ้น

เราไม่เลือกใช้ super node ด้วยวิธีนี้ด้วยเหตุผลหลักดังต่อไปนี้:
ความเสี่ยงในการรวมศูนย์การตรวจสอบความถูกต้องของพูล: ในระบบที่ใช้ supernode การรันโหนดจะต้องมีค่าใช้จ่ายคงที่สูง ซึ่งจะจำกัดจำนวนผู้ใช้ที่สามารถเข้าร่วมได้ ในขณะที่บางคนโต้แย้งว่า "ใน cryptocurrencies PoW และ PoS ส่วนใหญ่ ฉันทามติถูกควบคุมโดย 5-20 พูล (พูลการขุดหรือพูลตรวจสอบความถูกต้อง) ที่สามารถเรียกใช้โหนดได้ดี" ปัญหาคือมันไม่สนใจความเสี่ยงของแรงกดดันจากการรวมศูนย์ แม้แต่ในหมู่ สระน้ำที่มีกระเป๋าลึก หากต้นทุนคงที่ในการรัน Validator นั้นสูงมากเมื่อเทียบกับรางวัล กลุ่ม Validator ขนาดใหญ่สามารถเสนอค่าธรรมเนียมต่ำกว่ากลุ่ม Validator ขนาดเล็ก ซึ่งอาจทำให้กลุ่ม Validator ขนาดเล็กเหล่านั้นแออัดและรู้สึกกดดันในการรวมเข้าด้วยกัน ในระบบ Sharding ผู้ตรวจสอบความถูกต้องที่จำนำ ETH มากขึ้นจะต้องตรวจสอบธุรกรรมเพิ่มเติม ดังนั้นค่าใช้จ่ายจะไม่คงที่
ความเสี่ยงของการรวมศูนย์ในระบบคลาวด์: ในระบบที่ใช้ supernode ผู้ใช้จะไม่สามารถเดิมพันที่บ้านได้ ดังนั้นการเดิมพันส่วนใหญ่จึงมีแนวโน้มที่จะเกิดขึ้นในสภาพแวดล้อมการประมวลผลแบบคลาวด์ สิ่งนี้ทำให้เกิดความล้มเหลวเพียงจุดเดียว
ลดการต่อต้านการเซ็นเซอร์: เป็นไปไม่ได้ที่ผู้ใช้จะมีส่วนร่วมในฉันทามติโดยปราศจากข้อกำหนดด้านคอมพิวเตอร์ + แบนด์วิดท์สูง ซึ่งทำให้ตรวจจับและเซ็นเซอร์ตัวตรวจสอบความถูกต้องได้ง่ายขึ้น

ความเสี่ยงในการรวมศูนย์เหล่านี้ที่กล่าวถึงข้างต้นยังเป็นเหตุผลที่เราจะไม่พยายามบรรลุความหน่วงแฝงที่ต่ำเป็นพิเศษของ Ethereum (น้อยกว่า 1 วินาที) แต่เลือกเวลาแฝงที่อนุรักษ์นิยม (ค่อนข้าง) ในระบบ Ethereum 2.0 เป็นไปได้ที่จะเข้าร่วมโดยใช้ ETH น้อยหรือมากที่สุดเท่าที่จะเป็นไปได้ และใช้พลังการประมวลผลน้อยหรือมากที่สุดเท่าที่จะเป็นไปได้ (แม้ว่าคุณจะต้องสอดคล้องกันในแง่ของ ETH และพลังในการคำนวณ นั่นคือ คุณ ไม่สามารถเดิมพัน ETH จำนวนมากด้วยพลังการประมวลผลเพียงเล็กน้อยได้) ต้นทุนคงที่จะลดลง แม้ว่าค่าใช้จ่ายนี้จะเพิ่มขึ้นตามจำนวน ETH ที่คุณเดิมพัน (เมื่อคุณเดิมพัน หากจำนวน ETH เกิน 32,768 ETH คุณจะ ตรวจสอบ Shard Chain ทั้งหมดเป็นส่วนใหญ่ (หมายเหตุ: มี Shard Chain ทั้งหมด 1,024 รายการ และข้อมูลประจำตัวของ Validator แต่ละคนจำเป็นต้องจำนำ 32 ETH ดังนั้น 1024*32=32,768))

ชื่อเรื่องรอง

โมเดลความปลอดภัย

เป็นที่เชื่อกันโดยทั่วไปว่าการรักษาความปลอดภัยของบล็อกเชนนั้นขึ้นอยู่กับสมมติฐานที่ว่า "ผู้เข้าร่วมส่วนใหญ่มีความซื่อสัตย์" นั่นคือ ≥50% ของผู้เข้าร่วมจะปฏิบัติตามข้อตกลงที่กำหนดไว้อย่างตรงไปตรงมา และจะละทิ้งโอกาสในการขายชาติเพื่อผลประโยชน์ส่วนตัว

ในความเป็นจริง (i) ข้อสันนิษฐานที่ว่า "ผู้เข้าร่วมส่วนใหญ่มีความซื่อสัตย์" นั้นไม่สมจริง เนื่องจากผู้เข้าร่วมอาจ "ขี้เกียจ" และลงชื่อบล็อกโดยไม่ตรวจสอบความถูกต้อง (ดู Validator [9] และส้อมที่เกิดจากการขุด Bitcoin SPV[10]) ซึ่งเป็นกรณีทั่วไปของการแปรพักตร์ แต่โชคดีที่ (ii) บล็อกเชนมักจะผ่านรูปแบบความปลอดภัยบางอย่าง (แม้ว่าจะไม่คิดว่าผู้เข้าร่วมส่วนใหญ่จะยังคงซื่อสัตย์) เพื่อรักษาคุณสมบัติด้านความปลอดภัยของตนเอง

รูปแบบการรักษาความปลอดภัยทั่วไปและเข้มงวดคือรูปแบบเสียงส่วนใหญ่ที่ไม่ประสานกัน (uncoordinated rational major) กล่าวคือ ผู้เข้าร่วมจะดำเนินการตามผลประโยชน์ของตนเอง แต่จำนวนผู้เข้าร่วมที่ร่วมมือกันจะไม่เกินสัดส่วนที่กำหนด (พูดง่ายๆ ในห่วงโซ่ PoW สัดส่วนนี้คือ 23.2% [11])

รูปแบบการรักษาความปลอดภัยที่เข้มงวดมากขึ้นอีกรูปแบบหนึ่งคือรูปแบบกรณีที่เลวร้ายที่สุด กล่าวคือ เมื่อผู้เข้าร่วมรายเดียวควบคุมพลังการประมวลผลหรือจำนำมากกว่า 50% ปัญหาในขณะนี้จะกลายเป็น:

(1) ในกรณีนี้ เราสามารถรับประกันได้หรือไม่ว่าผู้ตรวจสอบจะต้องเสียค่าใช้จ่ายสูงมากเมื่อพยายามทำลายห่วงโซ่ทั้งหมด

(2) เรารับประกันอะไรโดยไม่มีเงื่อนไขได้บ้าง?

ในห่วงโซ่ PoS การเฉือน (การฟันเงินฝาก) สามารถรับประกันปัญหาแรกข้างต้นได้ นั่นคือเมื่อผู้โจมตีพยายามทำลายห่วงโซ่ทั้งหมด จะต้องมีราคาแพงมาก ในบล็อกเชนที่ไม่มีการแตกแฟรกเมนต์ (เช่น เชน Ethereum 1.0 ในปัจจุบัน) แต่ละโหนดที่ตรวจสอบบล็อกทั้งหมดจะเป็นไปตามข้อกำหนดของคำถามที่สองข้างต้นโดยให้การรับประกันสองข้อต่อไปนี้: (i) เชนที่ยาวที่สุดนั้นถูกต้อง และ (ii) มีห่วงโซ่ที่ยาวที่สุด (ดูลิงก์นี้ [12] สำหรับเหตุผลทางทฤษฎีสำหรับความสำคัญของ "ความพร้อมใช้งานของข้อมูล")

ใน Ethereum 2.0 เราใช้การป้องกันเชิงลึกผ่านการแบ่งกลุ่มย่อย (sharding) นั่นคือโดยการรวมคณะกรรมการตรวจสอบความถูกต้องที่สุ่มเลือก โดยยึดตามแบบจำลองความปลอดภัยที่ผู้ตรวจสอบความถูกต้องส่วนใหญ่จะยังคงซื่อสัตย์ เพื่อให้บรรลุการรับประกันประสิทธิภาพและความพร้อมใช้งาน และป้องกันผู้ตรวจสอบความถูกต้องที่ขี้เกียจผ่าน หลักฐานการดูแล (เช่น หากผู้ตรวจสอบ "ขี้เกียจ" และจะไม่เข้าร่วมในการตรวจสอบจะต้องถูกลงโทษ) ผ่านหลักฐานการฉ้อโกงและหลักฐานความพร้อมใช้งานของข้อมูล [9] ตรวจหาเชนที่ไม่ถูกต้องและใช้ไม่ได้โดยไม่ต้องดาวน์โหลดและตรวจสอบข้อมูลทั้งหมด ซึ่งจะช่วยให้ไคลเอ็นต์สามารถปฏิเสธเชนที่ไม่ถูกต้องและใช้ไม่ได้ แม้ว่าเชนจะได้รับการสนับสนุนจากตัวตรวจสอบความถูกต้องของ PoS ส่วนใหญ่ก็ตาม

คุณลักษณะด้านความปลอดภัยที่คาดหวังแสดงไว้ในตารางด้านล่าง:

ชื่อเรื่องรอง

กลไกจูงใจที่กำหนดโดยแคสเปอร์

รางวัลพื้นฐาน

ในแต่ละยุค (ใน Ethereum 2.0 ทุกๆ 64 บล็อกที่สร้างขึ้น (ประมาณ 6.4 นาที) เรียกว่ายุค) ผู้ตรวจสอบความถูกต้องแต่ละคนจะต้องดำเนินการ "รับรอง" นั่นคือกับหัวของห่วงโซ่ (หัว) เพื่อลงคะแนนและลงนาม (หัวของห่วงโซ่คือ บล็อคบน) หากรวม "หลักฐาน" ของผู้ตรวจสอบไว้ในส่วนหัวของห่วงโซ่ ผู้ตรวจสอบจะได้รับรางวัล รางวัลนี้ประกอบด้วยห้าส่วน:
รางวัลสำหรับการรวม "การพิสูจน์อักษร" ในบล็อกด้านบน
รางวัลสำหรับการ "พิสูจน์" จุดตรวจสอบยุคที่ถูกต้อง (หมายเหตุ: ช่องสุดท้ายในแต่ละยุคเรียกว่าจุดตรวจ (จุดตรวจ) และช่องคือเวลาที่ต้องใช้ในการสร้างบล็อกที่กำหนดโดยโปรโตคอล ( 6 วินาที));
รางวัลสำหรับการ "พิสูจน์" ว่าระบุหัวโซ่ (บล็อกบน) ที่ถูกต้อง
รางวัลสำหรับ "หลักฐาน" ที่รวมอยู่ในเครือข่ายอย่างรวดเร็ว (หากรวม "หลักฐาน" หลัง 1 ช่อง ผู้ตรวจสอบจะได้รับรางวัลเต็มจำนวน หากรวมหลังจาก n ช่องบนห่วงโซ่ รางวัลที่ได้รับจะเป็น 1/n ของรางวัลทั้งหมด);

รางวัลสำหรับการ "พิสูจน์" ว่ามีการระบุ Shard Block ที่ถูกต้อง

ในแต่ละกรณี ผลตอบแทนจริงจะถูกคำนวณดังนี้ หาก B เป็นรางวัลพื้นฐานและ P เป็นเศษส่วนของผู้ตรวจสอบที่ดำเนินการ "พิสูจน์" ที่ต้องการ ผู้ตรวจสอบความถูกต้องที่ดำเนินการตามที่กำหนดจะได้รับรางวัลเป็น B*P ในขณะที่ผู้ตรวจสอบความถูกต้องควรดำเนินการที่เกี่ยวข้องแต่มี not Validators ที่ไม่ทำเช่นนี้จะถูกลงโทษด้วย -B เป้าหมายของกลไก "รางวัลส่วนรวม" นี้คือ "ถ้าใครทำได้ดีกว่า ทุกคนจะทำได้ดีกว่า" ด้วยเหตุนี้จึงจำกัดปัจจัยด้านการทำลายล้าง (ดูบทความนี้ [13] สำหรับคำอธิบายเกี่ยวกับปัจจัยการก่อกวนและเหตุใดการจำกัดปัจจัยเหล่านี้จึงมีความสำคัญ)

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

รางวัลพื้นฐาน B นั้นคำนวณโดยที่ D1...Dn คือขนาดของเงินฝากของผู้ตรวจสอบความถูกต้อง และ k คือค่าคงที่ นี่คือการประนีประนอมระหว่างสองรูปแบบทั่วไปของ (i) การตั้งค่าอัตรารางวัลคงที่ เช่น k*Di และ (ii) การตั้งค่ารางวัลรวมคงที่ เช่น

ข้อโต้แย้งหลักที่ต่อต้าน (i) คือโมเดลนี้นำความไม่แน่นอนสองประการมาสู่เครือข่าย: จำนวนเหรียญทั้งหมดที่ออกนั้นไม่แน่นอน และจำนวนรวมของคำมั่นสัญญาที่เข้าร่วมนั้นไม่แน่นอน (เพราะหากอัตรารางวัลคงที่ต่ำเกินไป โดยทั่วไปแล้วจะไม่ หนึ่งจะเข้าร่วมซึ่งคุกคามเครือข่ายทั้งหมดและหากอัตรารางวัลคงที่สูงเกินไปผู้คนจำนวนมากจะเข้าร่วมทำให้การหมุนเวียนของเหรียญสูงอย่างไม่คาดคิด)

ข้อโต้แย้งหลักที่ต่อต้าน (ii) คือรูปแบบนี้จะทำให้เครือข่ายมีความเสี่ยงมากขึ้นต่อ "การโจมตีเพื่อกีดกัน" โปรดดู [13] สำหรับรายละเอียด

ผู้เสนอบล็อกจะได้รับรางวัล 1/8 ของรางวัลพื้นฐานสำหรับการรวม "หลักฐาน" ในบล็อก เพื่อกระตุ้นให้ผู้เสนอบล็อกรับฟังข้อมูลมากที่สุดและยอมรับข้อมูลมากที่สุดเท่าที่จะเป็นไปได้

เวลาออนไลน์ถึงจุดคุ้มทุน

ข้อความ

สมมติว่ามีผู้ตรวจสอบสองประเภท: (i) ผู้ตรวจสอบออนไลน์ที่มีบทบาท และ (ii) ผู้ตรวจสอบออฟไลน์ หากผู้ตรวจสอบประเภทเดิมคือ P บางส่วนและรางวัลพื้นฐานคือ B แสดงว่าผู้ตรวจสอบออนไลน์คาดว่าจะได้รับ รางวัลคือ: ให้รางวัล B*4P สำหรับกรณีที่ 1, 2, 3 และ 5 ข้างต้น + 7/8*B*(P+(P*(1-P))/2+(P *(1-P)^2) /3+...) (เนื่องจาก "หลักฐาน" อาจล่าช้าจากการรวมอยู่ในส่วนหัวของห่วงโซ่เนื่องจากไม่มีตัวตรวจสอบความถูกต้อง) + รางวัลผู้เสนอบล็อก 1/8*B*P ผู้ตรวจสอบที่ไม่อยู่ (กล่าวคือ ควรมีส่วนร่วมในการตรวจสอบแต่ไม่ได้ตรวจสอบจริง) จะถูกลงโทษโดย B*4 ดังนั้น หากผู้ตรวจสอบรายอื่นทั้งหมดออนไลน์อยู่ ผู้ตรวจสอบจะได้รับรางวัลเป็น B*5 เมื่อออนไลน์ และปรับเป็น B*4 เมื่อออฟไลน์ ดังนั้นหากผู้ตรวจสอบออนไลน์มีค่า ≥4/(4+ 5) ≈ 44.44% ผู้ตรวจสอบยืนยัน จะสามารถคุ้มทุน (จุดคุ้มทุน) ถ้า P=2/3 (นั่นคือ ผู้ตรวจสอบออนไลน์คิดเป็น 2/3 ของผู้ตรวจสอบทั้งหมด) ผู้ตรวจสอบจะได้รับรางวัลสำหรับการออนไลน์คือ ≈B*(2/3*4.125+7/8*0.81 )≈B *3.46 หรือจะถึงยอดการชำระเงินเนื่องจากเวลาออนไลน์ ≥ 53.6%

Inacivity leak

อย่างไรก็ตาม หากค่า P ต่ำกว่า 2/3 (นั่นคือ จำนวนผู้ตรวจสอบออนไลน์น้อยกว่า 2/3 ของจำนวนทั้งหมด) ผู้ตรวจสอบแบบออฟไลน์จะถูกลงโทษที่เรียกว่า "การรั่วไหลที่ไม่ใช้งาน"

หากเชน Ethereum 2.0 ล้มเหลวในการบรรลุจุดสิ้นสุดมากกว่า 4 ยุค จะมีการเพิ่มบทลงโทษเพิ่มเติมเพื่อให้รางวัลสูงสุดที่เป็นไปได้คือศูนย์ (ผู้ตรวจสอบที่ไม่ดำเนินการอย่างถูกต้องจะถูกลงโทษ) และบทลงโทษที่สองจะถูกเพิ่มเข้ามา ซึ่งจะ เพิ่มขึ้นตามสัดส่วนตามจำนวนยุคที่ล้มเหลวในการบรรลุขั้นสุดท้าย ทั้งนี้เพื่อให้แน่ใจว่าหากมากกว่า 1/3 ของโปรแกรมตรวจสอบสถานะออฟไลน์ โปรแกรมตรวจสอบสถานะออฟไลน์เหล่านี้จะถูกลงโทษรุนแรงขึ้น และบทลงโทษนี้จะเพิ่มขึ้นอย่างทวีคูณเมื่อเวลาผ่านไป

สิ่งนี้จะมีผลสามประการ:
ผู้ตรวจสอบความถูกต้องแบบออฟไลน์จะถูกลงโทษรุนแรงกว่า เนื่องจากในขณะนี้ การออฟไลน์ของผู้ตรวจสอบความถูกต้องจะป้องกันไม่ให้การบล็อกเสร็จสิ้น
เสิร์ฟเป้าหมายของ "การลงโทษต่อต้านความสัมพันธ์" (อธิบายเพิ่มเติมด้านล่าง)

ตรวจสอบให้แน่ใจว่าหากมากกว่า 1/3 ของ Validator ออฟไลน์ในเวลาเดียวกัน จำนวน Validator ที่กลับมาออนไลน์ในที่สุดจะกลับมาเป็น 2/3 ของทั้งหมด เนื่องจากการลดลงของ Validator ที่ออฟไลน์จะทำให้พวกเขาถูกไล่ออกจากระบบ ตรวจสอบอันดับ

ซึ่งหมายความว่าหาก 50% ของ Validator ออฟไลน์ การบล็อกจะเสร็จสิ้นอีกครั้งหลังจาก 21 วัน เนื่องจากหลังจาก 21 วัน Validator ออฟไลน์ทั้งหมดจะสูญเสีย 50% ของเงินฝาก (16 ETH) และหากเงินฝากของ Validator ต่ำกว่า 16 ETH เขาจะถูกไล่ออกจากตำแหน่งผู้ตรวจสอบความถูกต้อง

ข้อความ

การลงโทษอย่างเจ็บแสบและการต่อต้านความสัมพันธ์

หากพบว่าผู้ตรวจสอบความถูกต้องละเมิดเงื่อนไขการเฉือนของ Casper FFG ผู้ตรวจสอบความถูกต้องนั้นจะถูกลงโทษ (สูญเสียส่วนหนึ่งของเงินเดิมพัน) หากผู้ตรวจสอบความถูกต้องรายอื่นถูกเฉือนในช่วงเวลาเดียวกัน (โดยเฉพาะ ตั้งแต่ 18 วันก่อนที่ผู้ตรวจสอบความถูกต้องจะถูกลงโทษจนถึงช่วงระยะเวลาหนึ่ง) เมื่อผู้ตรวจสอบออกจากผู้ตรวจสอบ) ค่าปรับจะเป็น 3 เท่าของครั้งก่อน สิ่งนี้มีจุดประสงค์หลายประการ:
เฉพาะเมื่อตัวตรวจสอบทำงานผิดปกติกับตัวตรวจสอบความถูกต้องอื่นๆ จำนวนมากในเวลาเดียวกันเท่านั้นที่พฤติกรรมของตัวตรวจสอบความถูกต้องจะสร้างความเสียหายให้กับเครือข่ายได้ ดังนั้นบทลงโทษในกรณีนี้จะรุนแรงกว่า
สิ่งนี้จะลงโทษการโจมตีที่เกิดขึ้นจริงอย่างหนัก แต่เบามากสำหรับความผิดพลาดส่วนบุคคลที่อาจไม่เป็นอันตราย
สิ่งนี้ขัดขวางทุกคนจากการเข้าร่วมกลุ่มผู้ตรวจสอบความถูกต้องที่ใหญ่ที่สุด

ลายเซ็น BLS

ข้อความ

เราจะใช้ลายเซ็น BLS เนื่องจากลายเซ็น BLS เป็นมิตรกับการรวม: ข้อความ M ได้รับการประมวลผลโดยคีย์ k1 และ k2 (คีย์สาธารณะที่สอดคล้องกัน K1=G*k1, K2=G*k2 โดยที่ G เป็นจุดฐานของเส้นโค้งวงรี) สามารถรวมสองลายเซ็น S1 และ S2 ได้ง่ายๆ โดยการเพิ่มจุดโค้งวงรี: S1+S2 ซึ่งช่วยให้สามารถสร้างลายเซ็นได้หลายพันรายการ โดยแต่ละลายเซ็นมีค่าใช้จ่ายส่วนเพิ่มของบิตข้อมูลหนึ่งบิต (เพื่อแสดงถึงการมีอยู่ของคีย์สาธารณะเฉพาะในลายเซ็นรวมนั้น) และการเพิ่มเส้นโค้งวงรีหนึ่งเส้นโค้งในการคำนวณ

เราใช้ลายเซ็นของข้อความจำนองของผู้ตรวจสอบความถูกต้องเป็นหลักฐานแสดงความเป็นเจ้าของ ซึ่งระบุรหัสการลงนามและข้อมูลสำคัญอื่นๆ เช่น รหัสการถอน

ชื่อเรื่องรอง

การเลือกผู้ตรวจสอบแบบสุ่ม<- hash(seed,เมล็ดที่ใช้ในการบรรลุการสุ่มนั้นทำได้โดยการ "ผสม" ค่าที่ผู้เสนอให้บล็อกต้องเปิดเผย (เช่นเมล็ด

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

ในอนาคต เราวางแผนที่จะใช้ VDF (Verifiable Delay Functions) เพื่อเพิ่มความทนทานของเมล็ดแบบสุ่มต่อการยักย้ายถ่ายเท

ข้อความ

ตัวตรวจสอบความถูกต้องแบบสุ่ม

ในแต่ละยุค เราใช้การสับเปลี่ยนหรือไม่สับเปลี่ยน [13] เพื่อสับเปลี่ยนผู้ตรวจสอบความถูกต้องและมอบหมายความรับผิดชอบ อัลกอริทึมนี้ช่วยให้แน่ใจว่า:

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

ข้อความ

คณะกรรมการการเชื่อมขวาง

ในแต่ละยุค แต่ละชาร์ดจะทำการเชื่อมขวาง (crosslink) นั่นคือสุ่มเลือก 2/3 ของผู้ตรวจสอบความถูกต้องจากคณะกรรมการชาร์ด (จำนวนผู้รับรองในคณะกรรมการชาร์ดแต่ละอันคือประมาณ 128 คน) แฮชของข้อมูลทั้งหมดที่มีอยู่ ในชาร์ดตั้งแต่การเซ็นชื่อครอสลิงก์ล่าสุด (เนื่องจากครอสลิงก์ในชาร์ดอาจล้มเหลว แฮชสามารถแสดงข้อมูลของ 64 ยุคแรกได้มากที่สุด หากมีหลายยุคติดต่อกันในชาร์ด หากครอสลิงค์แรกล้มเหลว อาจ ใช้ crosslinks ที่ประสบความสำเร็จหลายอันเพื่อตามให้ทัน)

จำนวนผู้ตรวจสอบความถูกต้องต่อคณะกรรมการย่อยถูกตั้งค่าเป็น 128 เนื่องจากเป็นจำนวนขั้นต่ำเพื่อป้องกันผู้โจมตีที่ควบคุมสมาชิกคณะกรรมการ 2/3 โดยไม่ได้ตั้งใจ ในขณะที่ควบคุมน้อยกว่า 1/3 ของผู้ตรวจสอบความถูกต้องทั้งหมด ตามทฤษฎีบททวินาม โอกาสที่ ผู้โจมตีที่ควบคุม 2/3 ของคณะกรรมการคือ 5.55*10^(-15)

หลังจากแต่ละยุค (64 บล็อก ประมาณ 6.4 นาที) บีคอนเชนจะจัดระเบียบคณะกรรมการชาร์ดใหม่สำหรับแต่ละเชนชาร์ด (นั่นคือ รบกวนผู้ตรวจสอบความถูกต้อง) จุดประสงค์ของเครื่องมือตรวจสอบความถูกต้องแบบเร็วคือเพื่อให้แน่ใจว่าหากผู้โจมตีต้องการโจมตี Shard Chain ผู้โจมตีจะต้องทำลาย (เข้าควบคุม) คณะกรรมการชิ้นส่วนอย่างรวดเร็ว

ข้อความ

คณะกรรมการระยะยาว

ทุก ๆ 27 ชั่วโมง ระบบจะเลือกคณะกรรมการถาวรสำหรับแต่ละเชนชาร์ด ผู้ตรวจสอบความถูกต้องทุกคนในระบบ Ethereum 2.0 เป็นสมาชิกของหนึ่งในคณะกรรมการระยะยาวเหล่านี้ คณะกรรมการระยะยาวมีหน้าที่รับผิดชอบในการเสนอ Shard Block โดยให้การรับประกันระดับหนึ่งแก่ผู้ใช้เกี่ยวกับ Shard Block (จนกว่า Shard Block จะรวมอยู่ใน crosslink) และลูกค้ารายย่อยสามารถพึ่งพาคณะกรรมการระยะยาวได้ เพื่อรักษาความเสถียรของเครือข่าย P2P และประสิทธิภาพของไคลเอนต์แบบไลท์ การเปลี่ยนแปลงคณะกรรมการระยะยาวนั้นค่อนข้างไม่บ่อยนัก (ในขณะที่คณะกรรมการย่อยจะมีการเปลี่ยนแปลงทุกๆ ~6 นาที)

เพื่อรักษาความเสถียรของเครือข่ายต่อไป ผู้ตรวจสอบความถูกต้องบางส่วนจะไม่ถูกหมุนเวียนจากคณะกรรมการระยะยาว n ช่วงเวลา ไปยังคณะกรรมการระยะยาว n+1 ช่วงเวลาพร้อมกัน แต่จะหมุนเวียนกันแทน เครื่องมือตรวจสอบความถูกต้องจะเลื่อนออกไปจนกว่าจะมีการหมุนเวียนครั้งต่อไปที่จุดเวลาสุ่มในช่วงเวลาหนึ่ง

ชื่อเรื่องรอง

กฎการเลือกส้อม LMD GHOST

กฎการเลือกทางแยกของ LMD GHOST จะรวมข้อมูลจากตัวตรวจสอบทั้งหมดเพื่อให้แน่ใจว่าภายใต้สถานการณ์ปกติ เป็นไปไม่ได้ที่บล็อกใดๆ จะถูกย้อนกลับ เนื่องจากกฎการเลือก fork นี้ขึ้นอยู่กับตัวตรวจสอบความถูกต้องทั้งหมด ดังนั้น จึงช่วยให้มั่นใจได้ว่าบล็อกจะไม่สามารถย้อนกลับได้เว้นแต่ผู้โจมตีจะควบคุมตัวตรวจสอบความถูกต้องมากกว่า 50% ซึ่งในกรณีนี้ผู้โจมตีไม่สามารถได้รับผลประโยชน์มากนักจากการจัดการแบบสุ่ม ข้อได้เปรียบใหญ่

ชื่อเรื่องรอง

โครงสร้าง Beacon Chain/Shard Chain

โครงสร้างของระบบ Sharding ของ Ethereum 2.0 ประกอบด้วย "beacon chain" ส่วนกลางที่ประสานงานกิจกรรมทั้งหมด และ 1024 shard chain โซ่เศษแต่ละอันเชื่อมต่อกับโซ่บีคอนอย่างสม่ำเสมอผ่านครอสลิงค์

ทางเลือกอื่นสำหรับโครงสร้างการแบ่งส่วนนี้:

(1) ลงนามในเศษบล็อกผ่านคณะกรรมการ และใส่เศษบล็อกทั้งหมดลงในห่วงโซ่บีคอนโดยตรง

(2) ไม่มีห่วงโซ่บีคอน แต่โซ่เศษทั้งหมดเชื่อมต่อผ่านโครงสร้างบางอย่าง

เหตุผลที่โครงสร้างด้านบน (1) ถูกละทิ้งคือ แนะนำให้ตั้งเวลา 6 วินาที (สล็อต) สำหรับบล็อกเชนแบบแตก แต่การทำครอสลิงค์ 1024 ครั้งบนบีคอนเชนทุกๆ 6 วินาทีจะนำไปสู่เชน อยู่ภายใต้ภาระที่สูงมาก

เหตุผลของการละทิ้งโครงสร้างในข้อ (2) ของการอุทธรณ์คือโครงสร้างห่วงโซ่บีคอนแบบฮับและซี่นั้นง่ายต่อการใช้งานและเข้าใจมากกว่าโครงสร้างที่ซับซ้อนใดๆ

การออกแบบห่วงโซ่เศษ

ชิ้นส่วนแต่ละชิ้นเป็นโซ่กึ่งอิสระที่สามารถประมวลผลบล็อกได้เร็วกว่าบล็อกรวมที่เชื่อมโยงข้าม (เป้าหมาย 3-6 วินาที) ซึ่งช่วยให้ธุรกรรมได้รับการยืนยันในระดับหนึ่งอย่างรวดเร็วผ่านคณะกรรมการระยะยาวของชาร์ดก่อนที่จะได้รับการยืนยันโดยบีคอนเชน (โดยวิธีการเชื่อมโยงข้าม)

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

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

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

ข้อมูลเชื่อมโยงข้าม

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

ชื่อเรื่องรอง

วงจรชีวิตของ Validator

จำนำ

ผู้ตรวจสอบดำเนินการจำนำ ETH โดยการส่งธุรกรรม (ธุรกรรมนี้จะเรียกฟังก์ชันของสัญญาเงินฝากที่ใช้งานบนเชน Eth1.0) และสุดท้าย เราจะเพิ่มวิธีการจำนำในเชน Eth2.0 การดำเนินการนี้โดยผู้ตรวจสอบชี้แจง:
คีย์สาธารณะที่ตรงกับคีย์ส่วนตัวที่ใช้ในการเซ็นชื่อข้อความ
ข้อมูลรับรองการถอน (นั่นคือ แฮชคีย์สาธารณะ ซึ่งจะใช้ในการถอนเงินเมื่อผู้ตรวจสอบยืนยันเสร็จสิ้น)
จำนวนเงินจำนำ
ค่าเหล่านี้ทั้งหมดลงนามโดยคีย์การลงนาม จุดประสงค์ของการแยกคีย์การเซ็นชื่อออกจากคีย์การถอนคือเพื่อให้คีย์การถอนที่มีความเสี่ยงมากกว่ามีความปลอดภัยมากขึ้น (คีย์การถอนอยู่ในสถานะออฟไลน์และจะไม่แชร์กับกลุ่มคำจำนำใดๆ เป็นต้น) และคีย์การเซ็นชื่อจะใช้เพื่อเซ็นข้อความ ในแต่ละยุคสมัย

สัญญาฝากถือเป็นรากฐานของ Merkle ของคำมั่นสัญญาทั้งหมด เมื่อราก Merkle ให้คำมั่นโดยผู้ตรวจสอบความถูกต้องรวมอยู่ในเชน Eth2.0 (ผ่านกลไกการลงคะแนนข้อมูล Eth1.0) ผู้เสนอบล็อก Eth2.0 สามารถส่งหลักฐาน Merkle ของการจำนำและเริ่มกระบวนการจำนำได้

การเปิดใช้งาน

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

หากจำนวนผู้ตรวจสอบที่มีอยู่ใน Eth2.0 คือ |V| ดังนั้นจำนวนผู้ตรวจสอบสูงสุดที่สามารถเพิ่มได้ในแต่ละยุคจะเท่ากับสูงสุด (4, |V|/65536) หากผู้ตรวจสอบต้องการเข้าร่วมมากกว่านี้ จะต้องต่อคิวและระบบจะดำเนินการให้เร็วที่สุด

ล้มเลิก

เมื่อ Validator ถอนตัวออกจากระบบ Eth2.0 (ไม่ว่าจะโดยการโพสต์ข้อความออกโดยสมัครใจหรือออกเนื่องจากการฟัน) Validator จะต้องต่อคิวเพื่อถอนตัวออกจากระบบ ในแต่ละยุค จำนวนสูงสุดของ Validator ที่สามารถออกได้ จะเท่ากับจำนวนสูงสุดของตัวตรวจสอบความถูกต้องใหม่ที่สามารถเพิ่มได้ตามที่อธิบายไว้ข้างต้น

เหตุผลสำหรับขีดจำกัดการเข้าคิวเข้าร่วม/ออกใหม่นี้คือเพื่อให้แน่ใจว่าจำนวนรวมของ Validator ในระบบจะไม่เปลี่ยนแปลงเร็วเกินไประหว่างสองจุดใดๆ ในเวลา ซึ่งทำให้มั่นใจว่าตราบใดที่ Validators ล็อกอินบ่อยเพียงพอ (หาก Validators มีจำนวนทั้งหมด หมายเลข ≥ 262144 จากนั้นผู้ตรวจสอบจะรับประกันว่าจะสามารถเข้าสู่ระบบได้ทุกๆ 1-2 เดือน) จากนั้นจะสามารถมั่นใจได้ว่ายังมีความแน่นอนระหว่างเชนเก่าและใหม่ของ Ethereum หลักการที่เกี่ยวข้องอ้างถึง [17] และ [18]

เบิกเงิน

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

นี่เป็นเวลาสำหรับความท้าทายในการเริ่มต้น Proof of Escrow

ในระหว่างเฟส 0 ผู้ตรวจสอบความถูกต้องที่ต้องการ "ถอน" ไม่สามารถทำได้จริง ในขั้นตอนต่อมา พวกเขาจะสามารถโอนเงินที่ถอนโดยผู้ตรวจสอบความถูกต้องไปยังสภาพแวดล้อมการดำเนินการ

สมดุลอย่างมีประสิทธิภาพ

การคำนวณส่วนใหญ่ตามยอดคงเหลือของผู้ตรวจสอบความถูกต้องจะใช้ "ยอดคงเหลือที่มีประสิทธิผล (EB)" ของผู้ตรวจสอบความถูกต้อง ข้อยกเว้นเพียงอย่างเดียวคือการคำนวณที่เพิ่มหรือลดยอดคงเหลือของผู้ตรวจสอบความถูกต้อง เฉพาะเมื่อยอดคงเหลือ B ของผู้ตรวจสอบต่ำกว่า EB หรือสูงกว่า EB+1.5 เท่านั้น EB จะถูกปรับให้เท่ากับพื้น (B) นี่คือเพื่อให้แน่ใจว่ายอดคงเหลือที่มีประสิทธิภาพจะไม่เปลี่ยนแปลงบ่อยนัก ลดปริมาณการแฮชที่ต้องใช้ในการคำนวณสถานะใหม่ในแต่ละยุค โดยเฉลี่ยแล้ว เฉพาะยอดคงเหลือเท่านั้นที่ต้องได้รับการอัปเดต และตัวตรวจสอบความถูกต้องแต่ละรายการจำเป็นต้องอัปเดตยอดคงเหลือที่มีประสิทธิภาพค่อนข้างน้อย

ชื่อเรื่องรอง

กลไกส้อม

โครงสร้างข้อมูลส้อมประกอบด้วย (i) "fork ID" ปัจจุบัน (ii) "fork ID" ก่อนหน้าและ (iii) ช่องที่สลับส้อมทั้งสอง รหัสทางแยกที่ความสูงบล็อกปัจจุบันส่งผลต่อลายเซ็นที่ถูกต้องของข้อความทั้งหมด ดังนั้น ข้อความที่ลงนามด้วยรหัสทางแยกเดียวจึงไม่ถูกต้องสำหรับฟังก์ชันการตรวจสอบโดยใช้รหัสทางแยกอื่นๆ

การ Fork สามารถทำได้โดยเพิ่มการเปลี่ยนสถานะใน "fork slot" ฟังก์ชันการตรวจสอบลายเซ็นจะใช้ fork ID ของช่องที่มีข้อความอยู่เพื่อตรวจสอบข้อความ ID fork นี้อาจเป็น ID fork ก่อนหน้าหรือ ID fork ปัจจุบัน

หากผู้ใช้ไม่ต้องการเข้าร่วม fork ให้อยู่ใน chain ที่ไม่ได้เปลี่ยน ID fork ในช่อง fork โซ่ทั้งสองสามารถคงอยู่ต่อไปได้ และผู้ตรวจสอบความถูกต้องมีอิสระในการตรวจสอบทั้งสองโซ่โดยไม่มีการลงโทษ

หมายเหตุ: การแปลถูกลบแล้ว

[1]:https://radicalxchange.org/blog/posts/2018-11-26-4m9b8b/

[2]:https://vitalik.ca/general/2018/08/26/layer_1.html

[3]:https://vitalik.ca/general/2019/06/12/plasma_vs_sharding.html

[4]:https://vitalik.ca/general/2018/12/05/cbc_casper.html

[5]:https://medium.com/@aditya.asgaonkar/casper-cbc-simplified-2370922f9aa6

[6]:https://eprint.iacr.org/2015/702.pdf

[7]:https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa

[8]:https://twitter.com/VitalikButerin/status/1145576103089602560

[9]:https://eprint.iacr.org/2015/702.pdf

[10]:https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa

[11]:https://arxiv.org/abs/1507.06183