การรีสตาร์ท Ethereum สามารถลดภาระของโหนดได้หรือไม่?

หมายเหตุบรรณาธิการ: บทความนี้มาจากผู้ที่ชื่นชอบ Ethereum (ID: ethfans)ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)

ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)

ผู้แต่ง: Alexey Akhunov แปลและพิสูจน์อักษร: Min Min & A Jian พิมพ์ซ้ำโดยได้รับอนุญาตจาก Odaily

ประสบการณ์จาก Cosmos Hub

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

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

เราสามารถ "รีบูต" ETH 1.0 ได้หรือไม่?

ลองจินตนาการว่าวิธีการเดียวกันนี้สามารถใช้กับ Ethereum ได้หรือไม่ Ethereum blockchain มีขนาดใหญ่ (150-160 Gb) และสถานะมีขนาดใหญ่มาก (40-100 Gb ขึ้นอยู่กับว่าคุณจัดเก็บสถานะอย่างไร) ข้อดีที่ชัดเจนของการ "รีบูต" Ethereum blockchain ก็คือการเข้าร่วมโหนดใหม่จำเป็นต้องดาวน์โหลดสถานะการกำเนิด 40Gb แทนที่จะเป็น 150Gb blockchain อย่างไรก็ตาม การดาวน์โหลดสถานะการกำเนิด 40 Gb ก็ไม่ใช่ประสบการณ์ที่ดีเช่นกัน

เก็บสถานะของ Ethereum นอกเชน เฉพาะแฮชรากของ Merkle เท่านั้นที่มองเห็นได้บนเชน

สมมติว่าเราสามารถจัดเก็บ "off-chain" ขนาด 40 Gb นี้และบรรจุเฉพาะรูทแฮชลงในบล็อกการกำเนิด เราสามารถเริ่มต้นจากสถานะว่างได้ แต่เราจะให้ธุรกรรมเข้าถึงสถานะโดยนัยนี้ได้อย่างไร

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

นี่ไม่ใช่ ethereum ไร้สัญชาติใช่ไหม

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

การพิสูจน์ในบล็อก vs การพิสูจน์ในการทำธุรกรรม

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

ข้อเสียของหลักฐานการทำธุรกรรม

สมมติว่าเราต้องการให้ผู้ส่งธุรกรรมเพิ่มหลักฐานของทุกสถานะที่เกี่ยวข้องในธุรกรรม ข้อดีของการทำเช่นนี้คือจะทำให้งานที่เราต้องทำเพื่อเรียกเก็บเงินเพิ่มสำหรับพยานง่ายขึ้น ข้อเสียเปรียบหลักคือสิ่งนี้มักจะต้องทำให้สำเร็จด้วย Dynamic State Access (DSA) ซึ่งตรงข้ามกับ Static State Access (SSA) หากธุรกรรมเกี่ยวข้องกับสัญญาอัจฉริยะที่ซับซ้อนเป็นพิเศษ เช่น มีการเรียกใช้สัญญาอื่นๆ ที่ซ้อนกันจำนวนมาก อาจเป็นเรื่องยากที่จะคำนวณล่วงหน้าถึงรายการสถานะที่ธุรกรรมจะเกี่ยวข้อง ผู้โจมตียังสามารถใช้ DSA เพื่อ "ตั้งค่า" ผู้ใช้ กล่าวคือ เพื่อยึดครองธุรกรรมของตน (ส่งธุรกรรมที่มีเนื้อหาเหมือนกันแต่ค่าธรรมเนียมน้ำมันสูงกว่า เพื่อบรรจุไว้ข้างหน้าพวกเขา) เพื่อให้ธุรกรรมของผู้ใช้ล้มเหลวเนื่องจากไม่เพียงพอ การพิสูจน์.

การบรรเทาผลกระทบโดย ReGenesis

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

เมื่อสถานะโดยปริยายเพิ่มขึ้นจากไม่มี (เพิ่งเริ่มใหม่) เป็นสถานะที่มีการเข้าถึงมากขึ้นเรื่อย ๆ ธุรกรรมจำเป็นต้องแสดงหลักฐานน้อยลง หลังจากนั้นไม่นาน ธุรกรรมส่วนใหญ่ไม่จำเป็นต้องมีหลักฐานใดๆ แนบมาด้วย ยกเว้นธุรกรรมที่เกี่ยวข้องกับรัฐเมื่อนานมาแล้ว

เราสามารถทำ ReGenesis ได้เป็นประจำ

ฉันเรียกสิ่งนี้ว่า "รีสตาร์ท" reGenesis ซึ่งสามารถดำเนินการเป็นระยะเพื่อให้โหลดบนโหนดที่ไม่ใช่การขุดเบาลง ReGenesis ยังเป็นตัวแทนของ Ethereum ไร้สัญชาติรุ่นที่รุนแรงน้อยกว่า

การนำ ReGenesis ไปใช้ซ้ำๆ จะทำให้สถาปัตยกรรมของการใช้งานไคลเอนต์ Ethereum ง่ายขึ้น เกือบจะขจัดความจำเป็นสำหรับอัลกอริธึมการซิงโครไนซ์สแนปชอตระดับสูงกว่า หากเราทำ ReGenesis ทุกๆ 1 ล้านบล็อก (ประมาณ 6 เดือน) ภาพสถานะและไฟล์บล็อกเชนสามารถเผยแพร่สู่สาธารณะบน BitTorrent, Swarm และ IPFS ขณะนี้เราไม่สามารถทำเช่นนี้ได้ (พื้นที่เก็บข้อมูลตามที่สร้างขึ้น) เนื่องจากสถานะเปลี่ยนทุกๆ 15 วินาทีแทนที่จะเป็น 6 เดือน หากการใช้งานไคลเอนต์สามารถเล่นซ้ำบล็อกมูลค่า 6 เดือนได้ เราก็ไม่ต้องการอัลกอริทึมสแน็ปช็อตที่ซับซ้อนมากนัก ดังนั้นความซับซ้อนของการใช้งาน Ethereum จะลดลง

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

• ข้อเสียของ ReGenesis

• ฉันไม่ได้สำรวจสิ่งนี้ในเชิงลึก แต่ข้อเสียสามประการที่ฉันได้เห็นคือ: