V God เปิดตัวข้อเสนอ hard fork HF1 แรกของ ETH2.0 beacon chain ซึ่งแนะนำกลไกการลงโทษโหนดที่ยุติธรรมกว่า
หมายเหตุบรรณาธิการ: บทความนี้มาจากข้อมูล Babbitt (รหัส: bitcoin8btc)โดย Kyle เผยแพร่โดยได้รับอนุญาต
หมายเหตุบรรณาธิการ: บทความนี้มาจาก
ข้อมูล Babbitt (รหัส: bitcoin8btc)
ข้อมูล Babbitt (รหัส: bitcoin8btc)
โดย Kyle เผยแพร่โดยได้รับอนุญาต
"V God ผู้ก่อตั้ง Ethereum ได้แนะนำข้อเสนอการอัพเกรดของ hard fork แรกของ Ethereum Beacon Chain (ชื่ออย่างไม่เป็นทางการว่า "HF1") บน Twitter V God กล่าวว่า HF1 ได้เพิ่มการสนับสนุนไคลเอ็นต์แบบเบาและข้อกำหนดที่ง่ายขึ้น ปรับปรุงประสิทธิภาพ และ นำเสนอกลไกการลงโทษการไม่ใช้งานที่มีโทษน้อยกว่า ตามเอกสาร การฮาร์ดฟอร์กจะช่วยให้นักพัฒนาทำการอัปเกรดคีย์บางอย่างไปยัง beacon chain ที่เพิ่งเปิดตัวและยังเป็นวิธีการทดสอบที่เป็นประโยชน์เชิงลึกสำหรับการเปลี่ยนแปลง ที่มีความต้องการทรัพยากรน้อยที่สุดและสามารถทำงานบนอุปกรณ์พกพาได้ ซึ่งจะช่วยให้ "กระเป๋าเงินเชื่อขั้นต่ำ" สามารถตรวจสอบบล็อกเชนได้เองแทนที่จะพึ่งพาบริการภายนอกในการให้บริการโดย"
HF1 เป็นชื่อรหัสเบื้องต้นสำหรับการอัปเกรด hard fork ครั้งแรกของ Ethereum beacon chain (ดูที่นี่สำหรับแนวคิดการตั้งชื่อระยะยาวสำหรับ hard fork นี้) เป้าหมายหลักของ HF1 คือ:
เพิ่มการสนับสนุนไคลเอ็นต์แบบไลท์
แก้ไขช่องโหว่บางอย่างในห่วงโซ่สัญญาณ ช่องโหว่เหล่านี้ถูกค้นพบช้าเกินไปที่จะแก้ไขเมื่อกำเนิด Beacon Chain เริ่มต้นขึ้น
กลไกการอัปเกรดแบบฮาร์ดฟอร์กของบีคอนเชนได้รับการทดสอบในสภาพแวดล้อมของการอัปเกรดการเปลี่ยนแปลงเล็กน้อย เพื่อให้สามารถทำการเปลี่ยนแปลงขนาดใหญ่ได้ในภายหลัง
การเปลี่ยนแปลงฉันทามติที่เสนอใน HF1 รวมถึง:https://github.com/ethereum/eth2.0-specs/pull/2130
คณะกรรมการประสาน
เราเพิ่ม "คณะกรรมการการซิงค์" แบบสุ่มลงในห่วงโซ่บีคอน จุดประสงค์ของการดำเนินการนี้คือเพื่อให้ไคลเอ็นต์แบบเบาสามารถกำหนดหัวโซ่โดยมีค่าใช้จ่ายเพียงเล็กน้อย (ขั้นต่ำประมาณ 20 กิโลไบต์ต่อวัน และประมาณ 500 ไบต์สำหรับตรวจสอบบล็อกเดียว) สิ่งนี้จะช่วยให้ไคลเอ็นต์แบบไลท์สามารถใช้บีคอนเชนสำหรับกรณีการใช้งาน เช่น อุปกรณ์พกพา เบราว์เซอร์ในตัว เป็นการปูทางสำหรับระบบนิเวศกระเป๋าเงินที่ลดความน่าเชื่อถือลง
ในแต่ละช่วงเวลา (ประมาณ 27 ชั่วโมง) ผู้ตรวจสอบความถูกต้อง 1,024 คนจะถูกสุ่มเลือกให้เป็นสมาชิกของคณะกรรมการการซิงค์ โหนดตัวตรวจสอบความถูกต้องในคณะกรรมการการซิงค์จะออกลายเซ็นเพื่อยืนยันส่วนหัวปัจจุบัน ลายเซ็นเหล่านี้จะเผยแพร่โดยเป็นส่วนหนึ่งของวัตถุ LightClientUpdate ที่ช่วยให้ไคลเอนต์ light ค้นหาส่วนหัวนี้และจะรวมอยู่ในห่วงโซ่สัญญาณเพื่อรับรางวัลhttps://github.com/ethereum/eth2.0-specs/pull/2176
เนื้อหาเพิ่มเติม:
การปฏิรูปการทำบัญชี (ชั้นที่ 1)
เราแทนที่การคำนวณรางวัลผู้พิสูจน์ แทนที่จะเก็บออบเจกต์ PendingAttestation และประมวลผลในตอนท้าย เราเลือกที่จะเพิ่มบิตฟิลด์ที่เก็บสถานะของตัวตรวจสอบความถูกต้องแต่ละตัว ทำให้สามารถรวบรวมข้อมูลแบบเรียลไทม์เกี่ยวกับผู้ที่เข้าร่วม บิตฟิลด์ถูกจัดเรียงใน "ลำดับการสับเปลี่ยน" เพื่อให้แน่ใจว่าบันทึกจากตัวตรวจสอบความถูกต้องในคณะกรรมการชุดเดียวกันปรากฏพร้อมกัน จุดประสงค์ของการเปลี่ยนแปลงนี้คือเพื่อลดความซับซ้อนของการใช้งานไคลเอนต์ และทำให้การอัพเดท Merkle tree ถูกลง
การอ้างอิงเฉพาะ:
การปฏิรูปการทำบัญชี (ชั้นที่ 2)https://github.com/ethereum/eth2.0-specs/issues/2098
เราทำการเปลี่ยนแปลงชุดเครื่องมือตรวจสอบความถูกต้อง และการทำบัญชีค่าปรับจะเกิดขึ้นทุกๆ 64 ยุคเท่านั้น ไม่ใช่ทุกๆ ยุคเดียว จุดประสงค์ของการดำเนินการนี้คือเพื่อลดความซับซ้อนในการจัดการกับ "ช่วงการเปลี่ยนผ่านของช่วงช่องว่าง" อย่างมาก ตัวอย่างเช่น มีเชนที่มีส่วนร่วมต่ำมาก โดยที่บล็อกสองบล็อกที่ต่อเนื่องกันถูกคั่นด้วยช่องหนึ่งพันช่องที่มีช่วงช่องว่างระหว่างกันเท่านั้น ในการจัดการห่วงโซ่ดังกล่าว ในปัจจุบันลูกค้าจำเป็นต้องลงโทษผู้ตรวจสอบความถูกต้องสำหรับการไม่ใช้งานโดยการคำนวณยอดคงเหลือของผู้ตรวจสอบความถูกต้องแต่ละคนใหม่ทุก ๆ ยุค ในข้อเสนอใหม่ พวกเขาต้องทำทุก ๆ 64 ยุคเท่านั้น
นอกจากนี้ เราได้ทำการเปลี่ยนแปลงสองประการเกี่ยวกับวิธีการทำงานของบทลงโทษการไม่ใช้งาน:https://github.com/ethereum/eth2.0-specs/pull/2192
https://github.com/ethereum/eth2.0-specs/pull/2194
บทลงโทษการไม่ใช้งานจะกลายเป็นกำลังสองสำหรับผู้ตรวจสอบความถูกต้องแต่ละคน นั่นคือ หากมีบทลงโทษที่ไม่มีการใช้งานในระหว่างที่ Validator ที่ออฟไลน์โดยสมบูรณ์จะสูญเสียประมาณ 10% ของยอดคงเหลือ Validator ที่ออนไลน์ 90% ของเวลาทั้งหมดในช่วงเวลานี้จะเสียเพียง 0.1% ของยอดคงเหลือ (เทียบกับ ถึง ~ 1%) การดำเนินการนี้พยายามเน้นบทลงโทษที่โหนดที่ทำงานผิดปกติอย่างแท้จริง และน้อยลงในโหนดที่ซื่อสัตย์ที่ออฟไลน์เนื่องจากปัญหาการเชื่อมต่อเครือข่าย
INACTIVITY_PENALTY_QUOTIENT: reduced from 2**26 (= 67,108,864) to 3 * 2**24 (= 50,331,648)
PROPORTIONAL_SLASHING_MULTIPLIER: increased from 1 to 2
MIN_SLASHING_PENALTY_QUOTIENT: reduced from 2**7 (= 128) to 2**6 (= 64)
สามารถดูการสนทนาเพิ่มเติมได้ที่นี่:
บทลงโทษการไม่ใช้งานของ Validator จะค่อยๆ ช้าลงแทนที่จะหยุดลงหลังจากได้รับการพิจารณาแล้ว การดำเนินการนี้ทำให้มั่นใจได้ว่าเมื่อถึงสถานะสุดท้ายแล้ว โหนดออฟไลน์จะยังคงสูญเสียยอดคงเหลือต่อไปอีกระยะหนึ่ง เพื่อให้แน่ใจว่าเปอร์เซ็นต์เวลาออนไลน์ของเครื่องมือตรวจสอบความถูกต้องนั้นสูงกว่า 2/3 อย่างมาก แทนที่จะสูงกว่าเกณฑ์ดังกล่าวเพียงเล็กน้อย
การอ้างอิงเฉพาะ:
สิ่งหนึ่งที่ต้องฉลองคือการลดบทลงโทษของ Validator ลง เราอาจออกจากป่าได้เล็กน้อย (แต่ไม่สมบูรณ์) เราจะทำการเปลี่ยนแปลงค่าคงที่:
การเปลี่ยนแปลงตัวเลือกทางแยกใช้งานได้ (เกือบ) ในเวลาเดียวกันกับ HF1https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf
(บล็อก, ช่อง) คู่ (คู่) การเลือกส้อม
ปัจจุบัน หากไม่มีการเผยแพร่บล็อกในช่องล่าสุด จะถือว่าเป็นบล็อกล่าสุดในห่วงโซ่ที่ผู้พิสูจน์สนับสนุนเพื่อวัตถุประสงค์ในการพิสูจน์ LMD GHOST ในช่องนั้น ตัวอย่างเช่น ในแผนภาพด้านล่างนี้ การพิสูจน์บน BLANK นับเป็นการพิสูจน์ใน A:https://github.com/ethereum/eth2.0-specs/pull/2197
อย่างไรก็ตาม นี่เป็นการเปิดประตูสำหรับการโจมตี 34% สมมติว่ามีการกำหนดตัวตรวจสอบ m ให้กับแต่ละสล็อต โดยที่ผู้โจมตีที่เป็นอันตรายควบคุม 0.34*m ผู้โจมตียังมีสิทธิ์เผยแพร่บล็อก B สำหรับช่อง n+1 การโจมตีดำเนินไปดังนี้: ผู้โจมตีไม่ได้เผยแพร่ B หรือหลักฐานใด ๆ เกี่ยวกับเรื่องนี้ ผู้รับรองที่ซื่อสัตย์ทุกคนจะลงคะแนนให้กับการอ้างว่าพวกเขาเห็นบล็อก A ในช่อง n และไม่เห็นช่อง n+1 และปัจจุบันการนับนี้ถือเป็นการลงคะแนนสำหรับ A ในช่อง n + 2 ผู้เสนอที่ซื่อสัตย์จะสร้างบล็อก C ด้านบนของ A ในเวลานี้ ผู้เสนอที่ประสงค์ร้ายจะประกาศ B และหลักฐานของ B ในช่อง n + 1 และ n + 2 ส้อมด้านบนมีตัวตรวจสอบความถูกต้อง 0.68*m สำรองไว้ แต่ส้อมด้านบนมีเพียง 0.66*m สำรอง ดังนั้นส้อมล่างจึงชนะ
การโจมตีนี้มีรายละเอียดเพิ่มเติมในหัวข้อ 3.1 ของเอกสาร:
วิธีแก้ปัญหาที่เสนอคือเปลี่ยนวิธีการทำงานของการเลือกส้อมเพื่อให้ทำงานบนต้นไม้ของคู่ (บล็อก, ช่อง) แทนที่จะเป็นต้นไม้ของบล็อก ดังนั้น ในกราฟด้านบน การโหวตอย่างซื่อสัตย์ในช่อง n+1 จะนับเป็นการโหวตสำหรับ (ว่าง,n+1) ดังนั้นจะนับอย่างถูกต้องว่าสนับสนุน fork ด้านบน ดังนั้นการสนับสนุน fork ด้านบนจึงเท่ากับ 1.32*m จึงเอาชนะการโจมตีได้
