การระเบิดและการถอดชิ้นส่วนของ Ethereum Hardy Bomb
หมายเหตุบรรณาธิการ: บทความนี้มาจากผู้ที่ชื่นชอบ Ethereum (ID: ethfans)หมายเหตุบรรณาธิการ: บทความนี้มาจาก
ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)
ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)
, ผู้แต่ง: Thomas Jay Rush, แปลและพิสูจน์อักษร: Zeng Mi & A Jian, พิมพ์ซ้ำโดย Odaily โดยได้รับอนุญาต
เมื่อไหร่ก็ตามที่ระเบิดเวลาของ Ethereum ดับลง จะมีปัญหา 2 ประการเกิดขึ้นตรงหน้าเสมอ คำถามแรก (และอาจเป็นคำถามที่สำคัญกว่า) คือ: "การปิดกั้นการผลิตจะช้าลงเมื่อใด นั่นเป็นเรื่องที่ทนไม่ได้" คำถามที่สองคือ "คราวนี้ เราควรชะลอการวางระเบิดนานแค่ไหน"
ในเรียงความสั้นๆ นี้ ฉันขอเสนอคำตอบง่ายๆ เล็กน้อยสำหรับคำถามที่สอง ระเบิดความยากควรล่าช้านานแค่ไหน? คำแนะนำของฉันคือ: "จำเป็นต้องทำการฮาร์ดฟอร์กที่ความสูงบล็อก N เลื่อนการระเบิดความยากไปอีก N บล็อก (หรือน้อยกว่าเพื่อเพิ่มความปลอดภัย)"
ฉันจะไม่อธิบายว่าควรคำนวณความยากอย่างไรในบทความนี้ (โปรดดูบทความก่อนหน้าของฉันหากคุณต้องการทราบ) รูปภาพด้านล่างได้ปรากฏในบทความล่าสุดของฉันแล้ว ซึ่งแสดงรายการสูตรการคำนวณความยาก
(ข้อความในภาพ: ค่าความยากปัจจุบัน dc ได้มาจากการเพิ่มค่าความยากก่อนหน้า dp กับสองส่วน ส่วนแรกปรับระดับความยากตามช่วงเวลาระหว่างบล็อกปัจจุบันและบล็อกก่อนหน้า ให้ s = tsc - ts เมื่อ s < 10 ตัวประกอบ max(x) ในสูตรด้านบนจะประเมินเป็น 1 (สมมติว่าใช้วิธีหาร) ในกรณีนี้ การสร้างบล็อกเร็วเกินไปจะเพิ่มความยากและทำให้ความเร็วในการผลิตบล็อกช้าลง ถ้า 10<= s < 20 ตัวประกอบ max(x) จะกลายเป็น 0 ดังนั้นจึงมั่นใจได้ว่าเมื่อ s เข้าใกล้เวลาเป้าหมาย 14 วินาที ความยากจะไม่ถูกปรับอีกต่อไป และถ้า s>=20 ค่าของ ตัวคูณ max(x) จะกลายเป็น ตัวคูณค่อยๆ ลดลงจนเหลือ -99 ซึ่งทำให้ความยากลดลงจึงช่วยเพิ่มความเร็วในการผลิตบล็อก ส่วนที่สอง ของสมการจะขึ้นอยู่กับจำนวนบล็อกของบล็อกก่อนหน้า โดย แบ่ง 100,000 ในเลขชี้กำลัง 100,000 บล็อกเป็นฟังก์ชันขั้นเป็นระยะ ส่วนที่สองคือสิ่งที่เรามักเรียกว่าความยากลำบาก ถ้าไม่มีส่วนที่สอง จะไม่สามารถพูดถึงระเบิดความยากลำบากได้)
ส่วนแรกของสูตร ผมเรียกว่า "การปรับ" (หรือส่วน A) ส่วนนี้แก้ไขความเบี่ยงเบนของเวลาในการสร้างบล็อกของบล็อกก่อนหน้าโดยการปรับความยากของบล็อกปัจจุบัน การปรับนี้จะลดหรือเพิ่มความยาก ขึ้นอยู่กับว่าใช้เวลานานเท่าใดในการสร้างบล็อกสุดท้าย วงเล็บแรกในภาพด้านบนเน้นส่วนนี้ โปรดใช้เวลาสักครู่เพื่อทำความเข้าใจว่ามันทำงานอย่างไร ผลกระทบที่แท้จริงของส่วน A นั้นเหมือนกับเป้าหมายการออกแบบทุกประการ หน้าที่ของมันคือการทำให้ผลกระทบของความผันผวนของอัตราแฮชต่อการทำงานของเครือข่ายราบรื่น (หมายเหตุของผู้แปล: อัตราแฮชเป็นหน่วยของพลังการประมวลผล ดังนั้นจึงใช้เพื่ออ้างถึง พลังการคำนวณ) . จากแผนภูมิด้านล่าง คุณจะเห็นได้อย่างชัดเจนว่าส่วน A ของสูตรการคำนวณทำงานตรงตามที่คาดไว้
เพียงเพราะว่าส่วน A ทำงานตามที่ออกแบบมาเพื่อแยกอิทธิพลของอัตราแฮช ฉันไม่คิดว่าจำเป็นต้องพิจารณาขนาดที่แท้จริงของพลังการประมวลผลเมื่อคิดถึงวิธีหน่วงเวลาระเบิดเวลา กล่าวอีกนัยหนึ่ง พลังการประมวลผลที่ต่ำเกินไปจะไม่ทำให้เวลาในการสร้างบล็อกนานขึ้นเมื่อระเบิดความยากระเบิด และพลังการประมวลผลที่สูงเกินไปจะไม่บรรเทาผลกระทบของระเบิดความยาก จากการวิเคราะห์ข้างต้น ข้อสรุปของฉันคือส่วน A ของสูตรไม่เกี่ยวข้องกับการชะลอเวลาบล็อก และส่วนที่สองของสูตร (ส่วน B ที่ทำให้เกิดระเบิด) เป็นตัวการที่ทำให้เกิดปัญหาทั้งหมด
การวิเคราะห์ที่ตามมาจะทำให้คุณมั่นใจว่าเป็นไปได้ค่อนข้างมากที่จะจัดการกับสองส่วนนี้แยกกัน การวิเคราะห์เหล่านี้ช่วยให้เห็นได้ง่ายขึ้นว่าส่วน A ไม่มีผลต่อการสร้างบล็อก ในขณะที่ส่วน B - ระเบิด - ทำให้เวลาบล็อกนานขึ้น นอกจากนี้ คุณจะรู้ว่าการปลดชนวนระเบิดนั้นง่ายเพียงใดเพียงแค่รีเซ็ตยุคเป็น 0 ในทุก ๆ ทางแยก
ชื่อเรื่องรอง
สร้างข้อมูลและรูปแบบ
เรียกใช้โค้ดด้านบน คุณสามารถสร้างไฟล์ข้อมูลอย่างง่ายต่อไปนี้ในรูปแบบ .csv...
ข้อมูลข้างต้นเมื่อรวมกับรายการอัตราการแฮชรายวันที่ได้รับจาก EtherScan ก็เพียงพอแล้วสำหรับเราที่จะเข้าใจการคำนวณความยากของ Ethereum เราใช้ RStudio และภาษาการเขียนโปรแกรมข้อมูลที่เรียกว่า "R" เพื่อสร้างแผนภูมิด้านล่าง หากคุณไม่คุ้นเคยกับภาษา "R" ขอแนะนำให้คุณลองใช้ดู เป็นภาษาโปรแกรมที่ดีมาก
มาดูอัตราแฮชของ Ethereum ก่อน
อัตราแฮชเฉลี่ยรายวัน
แผนภูมิแรกแสดงอัตราแฮชเฉลี่ยรายวันของ Ethereum mainnet พร้อมข้อมูลจาก EtherScan เนื่องจากฉันไม่รู้ว่าข้อมูลถูกรวบรวม/สร้างขึ้นอย่างไร ฉันจึงไม่สามารถรับรองความถูกต้องได้ แต่ฉันถือว่าข้อมูลนั้นถูกต้อง คุณสามารถคลิกที่ลิงค์นี้เพื่อดูข้อมูลที่เกี่ยวข้อง
การสนทนา: จากกราฟด้านบน เห็นได้ชัดว่าอัตราแฮชของ Ethereum แปรผันตามราคาของ Ether กราฟนี้ทำให้ฉันนึกถึงการเคลื่อนไหวของราคาของ Ethereum ในช่วงฤดูร้อนปี 2017 อัตราแฮชพุ่งสูงขึ้นและพุ่งสูงสุดในไตรมาสแรกของปี 2018 (เท่ากับราคาสกุลเงินทุกประการ) ความผันผวนของอัตราแฮชในเดือนตุลาคม 2559 เกิดจากการโจมตี DDos ที่โด่งดังในเวลานั้น เส้นแนวตั้งสีเทา 2 เส้นในภาพด้านบนแสดงถึงฮาร์ดฟอร์ก 2 อัน ได้แก่ ฮาร์ดฟอร์ก Byzantine (ตุลาคม 2560) และฮาร์ดฟอร์กคอนสแตนติโนเปิล (มกราคม 2562) . ภาพนี้ได้รับการวิเคราะห์ที่นี่ในขณะนี้ แต่เราจะยังคงกล่าวถึงเมื่อเราพูดถึงข้อมูลความยากของ blockchain ต่อไป
ชื่อเรื่องรอง
ข้อมูลความยากดิบ
กราฟแรกที่อิงตามข้อมูลความยากจะแสดงข้อมูลที่ส่งคืนโดยการเรียก get_Block ของ RPC ของ Parity อันดับแรก สถิติมาตรฐานบางส่วนแสดงไว้ด้านล่าง:
กราฟแรกของเราค่อนข้างตรงไปตรงมา:
การสนทนา: ข้อมูลในรูปด้านบนถูกสร้างขึ้นที่บล็อก 8,920,000 แม้ว่าการประมวลผลบันทึกข้อมูลจำนวนมากนี้จะเป็นเรื่องง่ายๆ ในภาษา "R" เนื่องจากลักษณะการทำเหมืองข้อมูลซ้ำๆ เราสุ่มตัวอย่าง 1 ระเบียนจากทุกๆ 100 ทำให้เกิดประมาณ 9,000 ระเบียนและแสดงข้อมูลข้างต้นในรูป สอดคล้องกับบทความก่อนหน้านี้ เส้นแนวตั้งสีเทาในภาพด้านบนยังแสดงถึงการฮาร์ดฟอร์กอีกด้วย
ความสูงของเส้นสีแดง (y(x) = ความยากที่ block.x ) แสดงถึงค่าความยากที่บล็อกที่กำหนด คุณสามารถเห็นผลของการถอดประกอบระเบิดความยากได้อย่างง่ายดายที่ส้อมทุกอัน ย้อนกลับไปที่กราฟอัตราแฮชในบทความก่อนหน้า ในการโจมตี DDos ในฤดูใบไม้ร่วงปี 2016 คุณจะเห็นความสัมพันธ์ระหว่างความยากและอัตราแฮช
สมมติว่าระเบิดความยากไม่ได้ถูกแยกส่วน - จริง ๆ แล้วขยายเส้นสีแดงขึ้นไปจากความสูงที่เปิดใช้งานความยาก - ทำเช่นเดียวกันกับฮาร์ดฟอร์กทั้งสอง และคุณจะพบว่าสิ่งนี้สอดคล้องกับกราฟของการเปลี่ยนแปลงในอัตราแฮชอย่างน่าประหลาดใจ . กล่าวอีกนัยหนึ่ง อัตราแฮชและความยากมีความเชื่อมโยงกันอย่างใกล้ชิด ซึ่งเหมาะสมอย่างยิ่ง เพราะนั่นคือสิ่งที่ส่วน A ของสูตรความยากถูกออกแบบมา มีไว้เพื่อปรับค่าความยากโดยตรงสำหรับแฮชเรตต่างๆ
พฤติกรรมของคนงานเหมืองอาจไม่เปลี่ยนแปลงเนื่องจากการแยกส่วนของระเบิดความยากลำบาก แท่นขุดของพวกเขายังคงทำงานได้ดีพอ ๆ กันทั้งก่อนและหลังระเบิดความยากลำบากถูกทำลาย การเปลี่ยนแปลงเพียงอย่างเดียวคือเวลาเฉลี่ยในการสร้างบล็อกสั้นลง
การสนทนา: เราแบ่งกราฟด้านบนด้วยเส้นแนวตั้งในกลุ่มละ 100,000 บล็อก ลืมตาและมองอย่างระมัดระวัง เส้นโค้งที่แสดงถึงความยากในการกระโดดจะตรงกับเส้นแนวตั้ง (เส้นแบ่ง) ที่เราสร้างขึ้น ระหว่างเส้นแบ่งเหล่านี้ ความยากยังคงเพิ่มขึ้น แต่จะไม่เร็วเท่ากับการกระโดดข้ามเส้นแบ่ง ความยากที่เพิ่มขึ้นอย่างรวดเร็วนั้นสอดคล้องกับข้อเท็จจริงที่ว่าอัตราการแฮชพุ่งสูงขึ้นอย่างรวดเร็วในปี 2560
บางทีคุณอาจสังเกตเห็น "การระเบิด" ที่ต่อเนื่องกัน - ทุกครั้งที่ระเบิด ค่าความยากจะเพิ่มขึ้นสองเท่าจากค่าก่อนหน้า ปรากฎว่าช่วงเวลาของการกระโดดเหล่านี้มีความสำคัญอย่างยิ่งต่อการทำความเข้าใจสิ่งที่เกิดขึ้นในช่วงเวลาปัจจุบัน
ในไดอะแกรมสำหรับส่วนที่เหลือของบทความนี้ เป้าหมายของเราคือแยกส่วนแรก (เช่น ส่วน A หรือ "การปรับแต่ง") และส่วนที่สอง (เช่น ส่วน B หรือ "การระเบิด") ของสูตรความยาก จึงช่วยให้เราเข้าใจวิธีจัดการกับระเบิดความยากในอนาคตได้ดีขึ้น
ชื่อเรื่องรอง
ความยากเปลี่ยนทุกบล็อก
ในแผนภูมิถัดไป เราจะพิจารณาการเปลี่ยนแปลงของความยากระหว่างแต่ละบล็อกที่ต่อเนื่องกัน สูตรการคำนวณคือ y(x) = ค่าความยากของบล็อก x - ค่าความยากของบล็อก x-1
สำหรับคุณแล้ว กราฟนี้อาจเป็นการแสดงภาพแรกของคุณเกี่ยวกับระเบิดความยาก เห็นได้ชัดว่าการระเบิดแต่ละครั้งยากเป็นสองเท่าของครั้งก่อน
แต่ในความคิดของฉันภาพนี้ยังไม่ชัดเจนพอ ตัวอย่างเช่น เหตุใดรูปแบบเดียวกันจึงไม่ปรากฏขึ้นอีกอย่างชัดเจนในสมัยกรุงคอนสแตนติโนเปิล อันที่จริงเป็นเพราะอัตราการแฮชเพิ่มขึ้นอย่างมาก การคำนวณส่วนนี้สามารถคงเวลาบล็อกไว้ที่ 14 วินาที แต่ระบบจะผันผวนรุนแรงกว่า สิ่งนี้ยังอธิบายว่าทำไมเราไม่สามารถระบุระเบิดความยากได้ในขณะที่มันเข้าใกล้ทางแยกของคอนสแตนติโนเปิล เนื่องจากมันถูกบดบังด้วยความผันผวนที่รุนแรงกว่า
แล้วมีมาตรการอื่นที่ทำให้เราเห็นภาพได้ชัดเจนขึ้นไหม? แน่นอน! วิธีการนี้มีอยู่จริง และเราจะเปิดเผยให้คุณทราบในแผนภูมิถัดไป
ชื่อเรื่องรอง
การเปลี่ยนแปลงสัมพัทธ์ในความยากลำบาก
แผนภูมิสุดท้ายในส่วนนี้ของบทความแสดงเปอร์เซ็นต์การเปลี่ยนแปลงของความยากเทียบกับความยากในการบล็อกทั้งหมด สูตรการคำนวณคือ
แผนภูมิก่อนหน้าแสดงการเปลี่ยนแปลงความยากดิบ กราฟนี้แสดงการเปลี่ยนแปลงความยากมาตรฐาน ซึ่งจะลบผลกระทบของการเพิ่มอัตราแฮช เพื่อให้เราสามารถเห็นส่วนต่าง ๆ ของสูตรการคำนวณความยากสองส่วนได้ชัดเจนยิ่งขึ้น - ส่วน A และส่วน B
การสนทนา: ตอนนี้ คุณควรเข้าใจว่าทำไมฉันถึงพูดในบทความก่อนหน้านี้ว่าเมื่อพูดถึงการระเบิดความยาก การกังวลเกี่ยวกับพลังการประมวลผลจะส่งผลเสีย จากกราฟนี้ คุณจะเห็นได้อย่างชัดเจนว่าการผลิตบล็อกจะไม่ได้รับผลกระทบจากการเพิ่ม (หรือลดลง) ของอัตราแฮชจนกว่าระเบิดเวลาจะ "ผงาด" ส่วน A ของสูตรช่วยให้ความเร็วและเอาต์พุตของการผลิตบล็อกอยู่ในสถานะคงที่ ความยาก (จากข้อมูลเฉลี่ยและค่ามาตรฐาน) แทบจะไม่ได้รับผลกระทบมากนักจนกว่าระเบิดเวลาจะดับลง
มีสองสิ่งที่น่าสนใจเพิ่มเติมที่ควรทราบที่นี่: (1) จากภาพด้านบน คุณยังเห็นได้ว่าระเบิดเริ่ม "เงยหน้าขึ้น" ทางด้านขวาสุดของแผนภูมิ แม้ว่าจะไกลกว่าระยะทางระหว่าง Byzantium และ Constantinople (2) ลายเส้นที่ด้านล่างของแผนภูมิเกิดจากส่วนหนึ่งของสูตรที่หารด้วย 10 ในส่วน A ของสูตร (3) Ha ยิ่งสูง ดูเหมือนว่า Hitch rate จะชะลอการ "มุ่งหน้าขึ้น" " ดังที่ Lane Rettig กล่าวไว้ก่อนหน้า Constantinople fork ซึ่งเราได้เขียนถึงในบทความที่กล่าวถึงข้างต้นด้วย
ฉันยังมีอีกมากที่จะแบ่งปันเกี่ยวกับภาพนี้ สักวันหนึ่งฉันอาจจะกลับมาเขียนต่อ แต่ในอนาคต ฉันอยากจะมีวิธีที่ดีกว่านี้ในการปลดชนวนระเบิด
ชื่อเรื่องรอง
วิธีที่ดีกว่าในการปลดชนวนระเบิด
ก่อนอื่น ฉันต้องการเน้นย้ำอีกครั้งว่าการกังวลเกี่ยวกับความผันผวนของพลังงานในการคำนวณในขณะที่กังวลเกี่ยวกับระเบิดเวลานั้นเป็นสิ่งที่ตรงกันข้าม ส่วน A ของสูตรการคำนวณได้ไม่รวมผลกระทบของการเพิ่ม (หรือลดลง) ของกำลังการประมวลผลแล้ว นี่คือสิ่งที่ภาค A เป็นเรื่องเกี่ยวกับ ความยากที่เพิ่มขึ้นเกือบสมบูรณ์แบบ (เทียบกับความสูงของบล็อกในขณะนั้น) พิสูจน์ให้เห็นว่าส่วน A ทำงานได้เกือบสมบูรณ์แบบ เห็นได้ชัดว่าอัตราแฮชไม่มีผลต่อเวลาบล็อก - แต่เรารู้แล้ว - ซึ่งเป็นสิ่งที่ออกแบบมาเพื่อการปรับความยาก
ระเบิดถูกกำหนดโดยค่าพิเศษต่อท้ายสูตรข้างต้น:
(หมายเหตุผู้แปล: floor(x) เป็นฟังก์ชันของการปัดเศษลง นั่นคือ เอาจำนวนเต็มที่มากที่สุดไม่เกิน x เช่น floor(3.14) = 3)
สูตรข้างต้นเป็นฟังก์ชันยกกำลังที่มีฐาน 2 ให้ p = floor(บล็อกปัจจุบัน/100,000) เราสามารถเขียนสูตรข้างต้นใหม่เป็น 2p (คุณอาจสงสัยว่า -2 ที่ท้ายสูตรถูกกินหรือไม่ ไม่ เราแค่เพิกเฉยชั่วคราว เพราะหน้าที่ของมันคือทำให้ค่าที่คำนวณได้เล็กลง) สุดท้าย เราได้ฟังก์ชัน long step
อย่างไรก็ตาม โปรดทราบว่าผู้พัฒนาหลักได้รีเซ็ตการระเบิดสองครั้ง ใช่แล้ว เป็นการ "รีเซ็ต" ตามตัวอักษร พวกเขารีเซ็ตการเริ่มรอบของการคำนวณการระเบิด สิ่งนี้ทำได้โดยใช้รหัส Go เพื่อสร้างบล็อกหลอกที่ใช้ในการคำนวณ จนถึงตอนนี้ บล็อกปลอมดูเหมือนจะมีผลในการรีเซ็ตระเบิดในอดีต แผนภูมิที่แก้ไขด้านล่างแสดงสิ่งที่เกิดขึ้นจริงในช่วงเวลานี้
ตารางต่อไปนี้แสดงข้อมูลบางอย่างหลังจากรีเซ็ต คุณพบอะไรแปลกๆ หรือไม่?
หมายเลขบล็อกหลอกหลัง Byzantine fork คือ 1,370,000 และค่านี้หารด้วย 100,000 เพื่อให้ได้ระยะเวลา 13 นั่นคือหลังจากปรับอัตราแฮช ความยากของแต่ละบล็อกจะเพิ่มขึ้นอีก 213 เมื่อเกิดการ hard fork ของคอนสแตนติโนเปิล หมายเลขบล็อกปลอมจะถูกรีเซ็ตเป็น 2,280,000 ซึ่งหมายความว่าช่วงเวลานั้นกลายเป็น 22 ซึ่งหมายความว่าความยากของแต่ละบล็อกเพิ่มขึ้นอีก 222 ฉันคิดว่านั่นเป็นสาเหตุที่ระเบิดเวลาระเบิดเร็วกว่าที่เราคาดไว้ เนื่องจากเราไม่ได้ย้อนกลับไปไกลพอเมื่อเรารีเซ็ตครั้งล่าสุด
ค่าที่แนะนำสำหรับการรีเซ็ตระเบิดเวลาในครั้งนี้คือการย้อนกลับ 69,000 บล็อก ทำให้ยุคเป็น 0 นี่คือจำนวนเงินที่ถูกต้องในการรีเซ็ต
เมื่อใดก็ตามที่เราต้องรีเซ็ตระเบิดเวลา มีวิธีง่ายๆ และสะดวกมากในการรีเซ็ตให้เป็นค่าที่ถูกต้อง ด้วยวิธีนี้ ปัญหาส่วนใหญ่ที่เกี่ยวข้องกับการระเบิดความยากจะหายไป เพียงตั้งค่าจำนวนบล็อกกลับเมื่อรีเซ็ตระเบิดความยากให้เท่ากับ FORK_BLOCK_NUMBER (หมายเลขบล็อกทางแยก) ของทางแยก (หรือปรับเล็กน้อย) ด้วยวิธีนี้ หมายเลขบล็อกปลอมจะถูกตั้งค่าให้ใกล้เคียงกับ 0 และยุคก็จะกลายเป็น 0
สรุปแล้ว
เนื่องจากการชะลอตัวของอัตราการผลิตบล็อกมีสาเหตุหลักมาจากการมีอยู่ของไทม์บอมบ์ ด้วยวิธีการข้างต้น เอฟเฟกต์ "มุ่งหน้า" จะกลายเป็นสิ่งที่คาดเดาได้อย่างสมบูรณ์ การคำนวณส่วน B นั้นขึ้นอยู่กับหมายเลขบล็อกเทียม หากเราทำสิ่งนี้ในเวลาที่คอนสแตนติโนเปิลแยก (ดังแสดงในตารางด้านล่าง) ระเบิดเวลาจะไม่ระเบิดอย่างรวดเร็ว
ชื่อเรื่องรอง
สรุปแล้ว
