การวิเคราะห์และการเพิ่มประสิทธิภาพของปัญหา Storage Explosion ใน Ethereum

特邀专栏作者

2021-12-28 11:22

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

การพัฒนาอย่างแข็งขันของแอพพลิเคชั่นแบบกระจายอำนาจ เช่น DeFi และ GameFi ได้เพิ่มความต้องการอย่า

พื้นหลัง

การพัฒนาอย่างแข็งขันของแอปพลิเคชันแบบกระจายศูนย์ เช่น DeFi และ GameFi ได้เพิ่มความต้องการอย่างมากสำหรับบล็อกเชนประสิทธิภาพสูงที่มีค่าธรรมเนียมการทำธุรกรรมต่ำ อย่างไรก็ตาม ความท้าทายหลักในการสร้างบล็อกเชนประสิทธิภาพสูงคือการระเบิดของสตอเรจ ภาพด้านล่างเป็นกราฟที่นำมาจาก Etherscan ที่แสดงขนาดข้อมูล blockchain ของ Ethereum full node (ไฟล์เก็บถาวร)

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

แบ่งพื้นที่จัดเก็บเหนือศีรษะ

หากเราวิเคราะห์การใช้พื้นที่เก็บข้อมูลเพิ่มเติม เราจะพบว่าข้อมูลบล็อกคิดเป็นข้อมูลประมาณ 300GB เท่านั้น (จากความสูงบล็อก 0 ถึง 13.6M) ซึ่งน้อยกว่า 9TB มาก แล้วข้อมูลที่เหลืออีก 8.7TB มาจากไหน?

ปิดกั้น

ปิดกั้น
สถานะ
ใบเสร็จรับเงิน

ในหมู่พวกเขา รัฐเป็นองค์ประกอบหลักของ 8.7TB ดังนั้น บางครั้งเราเรียกการระเบิดของสตอเรจว่า "การระเบิดของรัฐ" แต่ทำไมรัฐจึงมีขนาดใหญ่?

สถานะ Ethereum คืออะไร?

สถานะ Ethereum คือ Merkle Patrica tree (MPT) โดยที่

โหนดปลายสุดคือการแมปที่อยู่ (0x...) => บัญชี โดยที่บัญชีจะเก็บยอดคงเหลือ nonces ฯลฯ ที่เกี่ยวข้องกับที่อยู่
โหนดภายในรักษาโครงสร้างต้นไม้เพื่อให้สามารถคำนวณรากแฮชของต้นไม้ทั้งหมดได้อย่างรวดเร็ว

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

รับโหนดเต็ม

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

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

โหนดเต็มรูปแบบที่ซิงโครไนซ์ได้อย่างรวดเร็วสำหรับ Geth

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

คำถาม

ด้วยขนาดพื้นที่จัดเก็บ Ethereum ปัจจุบันที่ 447GB และ 15 TPS เราคาดว่าคอมพิวเตอร์การกำหนดค่าทั่วไปที่มี SSD ขนาด 1TB จะสามารถเรียกใช้โหนด Ethereum เป็นระยะเวลานาน (เช่น ปี) มีการระเบิดของคลังสินค้าหรือการระเบิดของรัฐหรือไม่? บางที Ethereum อาจจะไม่ใช่ในอีกไม่กี่ปีข้างหน้า แต่ถ้าเราสามารถปรับขนาดเครื่องเสมือน (VM) ของ Ethereum เป็นร้อยหรือพัน TPS ได้ล่ะ?

หันมาสนใจเชนอื่นที่ใช้ EVM กัน นั่นคือ Binance Smart Chain (BSC) ณ วันที่ 8 ธันวาคม 2564 BSC มี:

ข้อมูลออนเชนประมาณ 984 GB ซึ่งบล็อกบัญชีประมาณ 550 GB และสถานะบัญชีประมาณ 400 GB
2.06623 พันล้านธุรกรรม 100 TPS

หากเราคาดการณ์ขนาดข้อมูลเพิ่มเติมตามจำนวนธุรกรรม เราจะได้:

ถ้า TPS เท่ากับ 100 นั่นคือ ~3,153 M TPY

1 ปีต่อมา รวม TX ~5,219M บล็อก ~1.375 TB สถานะ ~1.085TB
3 ปีต่อมา รวม TX ~11,525M บล็อก ~3.025TB สถานะ ~2.387 TB

ถ้า TPS เท่ากับ 150 (สังเกต TPS สูงสุด) นั่นคือ ~4,730 M TPY

1 ปีต่อมา รวม TX ~6,796M บล็อก ~1.809 TB สถานะ ~1.427 TB
3 ปีต่อมา รวม TX ~16,256M บล็อก ~4.327 TB สถานะ ~3.414TB

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

ปัญหาการระเบิดของพื้นที่เก็บข้อมูลสำหรับบล็อกเชนที่มี TPS สูงมาก

หากเราตั้งสมมติฐานที่ชัดเจนยิ่งขึ้นเกี่ยวกับบล็อกเชนที่มี TPS สูงมาก (เช่น QuarkChain สามารถทำได้) ตัวเลขนี้จะกลายเป็นอะไร ลองพิจารณาบล็อกเชนที่มี 1,000 TPS และวิเคราะห์ขนาดบล็อกและสถานะของมัน จะเป็น:

สมมติว่าขนาด tx ประมาณ 100 ไบต์ พื้นที่เก็บข้อมูลที่จำเป็นสำหรับแต่ละบล็อกคือ 1,000 (TPS) * 100 (ไบต์ต่อ tx) * 365 * 24 * 3600 = 2.86 TB
สมมติว่า MPT มี 10 พันล้านบัญชี (มากกว่าประชากรโลก!) เราคาดว่าขนาดสถานะจะเป็น 150G (ขนาดสถานะ Ethereum) / 0.18B (ที่อยู่เฉพาะ Ethereum) * 10B = 8.3 TB

เมื่อนำตัวเลขเหล่านี้มารวมกัน เป็นเรื่องง่ายที่จะสรุปได้ว่านี่เป็นข้อกำหนดที่คอมพิวเตอร์ส่วนใหญ่ที่มีการกำหนดค่าปกติจะไม่สามารถจัดการได้!

การเพิ่มประสิทธิภาพ

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

การเพิ่มประสิทธิภาพการจัดเก็บสถานะ

การเพิ่มประสิทธิภาพแรกที่เราเสนอคือการใช้ KV ธรรมดาแทน MPT เมื่อ MPT มีขนาดใหญ่ โหนดภายในทั้งหมดใน MPT อาจมีราคาแพงมาก และการเพิ่มประสิทธิภาพของเราจะลบโหนดภายในทั้งหมดใน MPT สมมติว่าข้อมูลของแต่ละบัญชีมีขนาดประมาณ 50 ไบต์ (20 ที่อยู่ + 2 nonces + 12 บัญชี + อื่นๆ) เราสามารถบันทึกข้อมูลของ 10 พันล้านบัญชีถัดไปเป็น:

~ 10B * 50 + 100GB (รหัส) = 600 GB ประมาณ 1/10 ของรุ่น MPT!

แม้ว่าการใช้ KV แบบธรรมดาจะมีประโยชน์มากมาย แต่ปัญหาหลักคือเราไม่สามารถคำนวณสถานะหลังการแฮชของแต่ละบล็อกในช่วงเวลาบล็อกสั้น ๆ ดังกล่าวได้ ซึ่งหมายความว่าเราจะสูญเสียประโยชน์ต่อไปนี้ของ Ethereum:

Fast Sync: ดาวน์โหลดสถานะของบล็อกและซิงค์เครือข่ายอย่างรวดเร็วโดยเล่นซ้ำบล็อกที่เหลือ
การตรวจจับ Fork (หรือการตรวจจับ Byzantine): บล็อกที่สร้างขึ้นใหม่จากเพียร์จะส่งผลให้มีสถานะแตกต่างจากบล็อกที่ดำเนินการในเครื่องหรือไม่

เพื่อเปิดใช้งานการซิงค์อย่างรวดเร็ว เรามีบล็อกสแน็ปช็อตเป็นระยะ (ช่วงสแนปชอต = ยุค = เช่น 14 สัปดาห์) บล็อกสแน็ปช็อตประกอบด้วยข้อมูลเพิ่มเติมของแฮชสถานะก่อนสถานะ ซึ่งเป็นแฮชหลังสถานะของบล็อกสแน็ปช็อตก่อนหน้า (สถานะแฮชหลังจากดำเนินการธุรกรรม):

บล็อกที่ไม่ใช่สแนปช็อตจะไม่รักษาสถานะแฮช แต่จะมีแฮชที่เพิ่มขึ้นแทน ซึ่งประกอบด้วยแฮชของการดำเนินการฐานข้อมูลดั้งเดิม (ลบ อัปเดต) ของธุรกรรมทั้งหมดสำหรับบล็อกนั้น ทำให้สามารถตรวจจับส้อมได้!
เราใช้แฮชสถานะก่อนการทำธุรกรรมแทนแฮชสถานะหลังการทำธุรกรรมสำหรับการบล็อกใน Ethereum เหตุผลคือโหนดไม่สามารถคำนวณสถานะแฮชได้ทันทีหลังการทำธุรกรรม แต่ด้วยการใช้สถานะก่อนการทำธุรกรรม โหนดสามารถใช้ช่วงเวลาทั้งหมดเพื่อคำนวณแฮช ตัวอย่างเช่น สมมติว่าการคำนวณสถานะแฮชประมวลผลข้อมูลสถานะ 10M ต่อวินาที จากนั้นการคำนวณสถานะทั้งหมด 600 GB จะใช้เวลา 600 GB / 10 M ~ 16.67 ชั่วโมง (เทียบกับยุค = 14 สัปดาห์)

ขั้นตอนการคำนวณแฮชก่อนสถานะมีดังนี้:

1. เมื่อได้รับบล็อกสแน็ปช็อตและสิ้นสุด สถานะ KV จะถูกสแนปช็อตและเธรดพื้นหลังจะถูกสร้างขึ้นเพื่อวนซ้ำรายการ KV ทั้งหมด (ที่อยู่ => บัญชี) และคำนวณแฮช

2. เมื่อบล็อกสแน็ปช็อตถัดไปถูกสร้างขึ้น ค่าแฮชสถานะล่วงหน้าที่คำนวณได้จะถูกเก็บไว้ในบล็อกนั้น ในทำนองเดียวกัน โหนดจะสร้างสแน็ปช็อตของ KV และคำนวณแฮชในเบื้องหลัง

3. เมื่อบล็อกสแน็ปช็อตถัดไปถูกสร้างขึ้น นอกเหนือจากการจัดเก็บแฮชสถานะล่วงหน้าแล้ว โหนดสามารถปล่อยสแน็ปช็อต KV ของบล็อกสแน็ปช็อตได้ ซึ่งหมายความว่าข้อมูลที่ถูกลบ/อัปเดตทั้งหมดจากบล็อกสแน็ปช็อตจะเป็นการรวบรวมขยะโดยอัตโนมัติ (เช่นการบดอัดใน levelDB)

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

การเพิ่มประสิทธิภาพพื้นที่เก็บข้อมูลบล็อก

การใช้บล็อกสแน็ปช็อต เราสามารถลดข้อมูลบล็อกที่ต้องการในโหนดได้มากขึ้นโดยจัดเก็บเฉพาะ:

สแน็ปช็อตสถานะก่อนดำเนินการธุรกรรมของบล็อกสแน็ปช็อตล่าสุด นั่นคือ (ล่าสุด — 1) สถานะหลังการดำเนินการธุรกรรมของบล็อกสแน็ปช็อต
(ล่าสุด — 1) บล็อกเต็มหลังบล็อกสแนปชอต

เราสามารถคำนวณต้นทุนพื้นที่จัดเก็บอย่างง่ายได้: สมมติว่าระยะเวลาของยุคคือ 2 สัปดาห์ การปรับขนาดบล็อกคือ