การตัดแต่งกิ่งต้นไม้ บล็อกมูลนิธิ Ethereum

หนึ่งในประเด็นสำคัญที่เกิดขึ้นตลอดระยะเวลาการปล่อยความเครียดโอลิมปิกคือข้อมูลจำนวนมากที่ลูกค้าจำเป็นต้องจัดเก็บ มากกว่าการดำเนินงานน้อยกว่าสามเดือนและโดยเฉพาะอย่างยิ่งในช่วงเดือนที่ผ่านมาจำนวนข้อมูลในโฟลเดอร์บล็อกเชนของไคลเอนต์ Ethereum แต่ละรายการได้ส่งผลให้กิกะไบต์ 10-40 กิกะไบต์ที่น่าประทับใจขึ้นอยู่กับลูกค้าที่คุณใช้และเปิดใช้งานการบีบอัดหรือไม่ แม้ว่าจะเป็นสิ่งสำคัญที่จะต้องทราบว่านี่เป็นสถานการณ์การทดสอบความเครียดที่ผู้ใช้ได้รับแรงจูงใจในการทิ้งธุรกรรมใน blockchain ที่จ่ายเฉพาะการทดสอบฟรี-Ether เป็นค่าธรรมเนียมการทำธุรกรรมและระดับปริมาณการทำธุรกรรมนั้นสูงกว่า bitcoin หลายเท่า

ก่อนอื่นให้เราเริ่มต้นด้วยการสำรวจว่าทำไมฐานข้อมูลไคลเอนต์ Ethereum ปัจจุบันมีขนาดใหญ่มาก Ethereum ซึ่งแตกต่างจาก Bitcoin มีคุณสมบัติที่ทุกบล็อกมีสิ่งที่เรียกว่า “state root”: hash root ของ a ต้นไม้ Merkle ชนิดพิเศษ ซึ่งเก็บสถานะทั้งหมดของระบบ: ยอดคงเหลือบัญชีทั้งหมดการจัดเก็บสัญญารหัสสัญญาและการไม่อยู่ในบัญชีอยู่ภายใน

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

1. ดาวน์โหลดส่วนหัวของบล็อกได้มากเท่าที่ลูกค้าจะได้รับ
2. กำหนดส่วนหัวซึ่งอยู่ที่ปลายโซ่ที่ยาวที่สุด เริ่มต้นจากส่วนหัวนั้นย้อนกลับไป 100 บล็อกเพื่อความปลอดภัยและโทรบล็อกที่ตำแหน่งนั้น P¹⁰⁰(h) (“ปู่ย่าตายายรุ่นร้อยของหัว”)
3. ดาวน์โหลดแผนผังสถานะจากรากสถานะของ P¹⁰⁰(h) โดยใช้ไฟล์ Hashlookup Opcode (โปรดทราบว่าหลังจากหนึ่งหรือสองรอบแรกสิ่งนี้สามารถขนานกันในหมู่เพื่อนมากเท่าที่ต้องการ) ตรวจสอบว่าทุกส่วนของต้นไม้ตรงกับ
4. ดำเนินการตามปกติจากที่นั่น

สำหรับลูกค้าที่มีน้ำหนักเบารากของรัฐนั้นมีประโยชน์มากขึ้น: พวกเขาสามารถกำหนดยอดคงเหลือและสถานะที่แน่นอนของบัญชีใด ๆ ได้ทันทีโดยเพียงแค่ขอเครือข่ายสำหรับ สาขาเฉพาะ จากต้นไม้โดยไม่จำเป็นต้องติดตาม Bitcoin หลายขั้นตอน 1-of-N-n “ขอเอาต์พุตการทำธุรกรรมทั้งหมดจากนั้นขอธุรกรรมทั้งหมดที่ใช้จ่ายผลลัพธ์เหล่านั้น

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

การเปลี่ยนแปลงของต้นไม้ในแต่ละบล็อกแต่ละบล็อกนั้นค่อนข้างเล็กและความมหัศจรรย์ของต้นไม้เป็นโครงสร้างข้อมูลคือข้อมูลส่วนใหญ่สามารถอ้างอิงได้สองครั้งโดยไม่ต้องถูกคัดลอก อย่างไรก็ตามถึงกระนั้นสำหรับการเปลี่ยนแปลงทุกครั้งที่เกิดขึ้นกับสถานะที่ทำลอกเลียนแบบลอการิทึมจำนวนมาก (เช่น ~ 5 ที่ 1,000 โหนด, ~ 10 ที่ 10,000 โหนด, ~ 15 ที่ 10,00000000 โหนด) ต้องจัดเก็บสองครั้งหนึ่งรุ่นสำหรับต้นไม้เก่าและรุ่นหนึ่งสำหรับ Trie ใหม่ ในที่สุดเมื่อกระบวนการโหนดทุกบล็อกเราสามารถคาดหวังได้ว่าการใช้พื้นที่ดิสก์ทั้งหมดจะใช้ในแง่วิทยาศาสตร์คอมพิวเตอร์โดยประมาณ o (n*log (n))ที่ไหน n คือโหลดธุรกรรม ในแง่ปฏิบัติ Ethereum blockchain มีเพียง 1.3 กิกะไบต์ แต่ขนาดของฐานข้อมูลรวมถึงโหนดพิเศษทั้งหมดเหล่านี้คือ 10-40 กิกะไบต์

แล้วเราจะทำอย่างไร? การแก้ไขที่ดูย้อนหลังอย่างหนึ่งคือการไปข้างหน้าและใช้การซิงค์ส่วนหัวครั้งแรกโดยการรีเซ็ตการบริโภคฮาร์ดดิสก์ของผู้ใช้ใหม่เป็นศูนย์และช่วยให้ผู้ใช้สามารถใช้การบริโภคฮาร์ดดิสก์ของพวกเขาได้ต่ำโดยการซิงค์ทุก ๆ หนึ่งหรือสองเดือน วิธีการทางเลือกคือการใช้งาน การตัดแต่งกิ่งต้นไม้: โดยพื้นฐานแล้วใช้ การนับอ้างอิง ในการติดตามเมื่อโหนดในต้นไม้ (ที่นี่โดยใช้ “โหนด” ในคำศัพท์ทางวิทยาศาสตร์คอมพิวเตอร์ความหมาย “ชิ้นส่วนของข้อมูลที่อยู่ในกราฟหรือโครงสร้างต้นไม้” ไม่ใช่ “คอมพิวเตอร์บนเครือข่าย”) หลุดออกจากต้นไม้ x บล็อก (เช่น x = 5000) หลังจากจำนวนบล็อกผ่านโหนดควรถูกลบอย่างถาวรจากฐานข้อมูล โดยพื้นฐานแล้วเราเก็บโหนดต้นไม้ที่เป็นส่วนหนึ่งของสถานะปัจจุบันและเรายังเก็บประวัติล่าสุด แต่เราไม่เก็บประวัติที่เก่ากว่า 5,000 บล็อก

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

1. เมื่อประมวลผลบล็อกด้วยหมายเลข nติดตามโหนดทั้งหมด (ในสถานะต้นไม้และต้นไม้ใบเสร็จรับเงิน) ซึ่งจำนวนการอ้างอิงลดลงเหลือศูนย์ วางแฮชของโหนดเหล่านี้ลงในฐานข้อมูล “แถวตาย” ในโครงสร้างข้อมูลบางประเภทเพื่อให้รายการสามารถเรียกคืนได้ในภายหลังโดยหมายเลขบล็อก (โดยเฉพาะหมายเลขบล็อก n + x) และทำเครื่องหมายรายการฐานข้อมูลโหนดเองว่าเป็นการลบที่คุ้มค่าที่บล็อก n + x–
2. หากโหนดที่อยู่ในแถวประหารได้รับการจัดตั้งอีกครั้ง (ตัวอย่างที่ใช้งานได้จริงของนี่คือบัญชีการรับยอดคงเหลือ/nonce/code/storage โดยเฉพาะ fจากนั้นเปลี่ยนเป็นค่าที่แตกต่างกัน กจากนั้นบัญชี B ที่ได้รับสถานะ f ในขณะที่โหนดสำหรับ f อยู่ในแถวประหาร) จากนั้นเพิ่มจำนวนการอ้างอิงกลับเป็นหนึ่ง หากโหนดนั้นถูกลบอีกครั้งในบางบล็อกในอนาคต ม. (กับ m> n) จากนั้นนำกลับไปที่แถวประหารของบล็อกในอนาคตที่จะถูกลบที่บล็อก M + X–
3. เมื่อคุณไปถึงการประมวลผลบล็อก n + xเรียกคืนรายการแฮชที่คุณเข้าสู่ระบบระหว่างบล็อก n– ตรวจสอบโหนดที่เกี่ยวข้องกับแต่ละแฮช; หากโหนดยังคงมีการทำเครื่องหมายสำหรับการลบ ในระหว่างบล็อกเฉพาะนั้น (เช่นไม่คืนสถานะและที่สำคัญไม่ได้คืนสถานะแล้วทำเครื่องหมายอีกครั้งเพื่อลบ ภายหลัง) ลบออก ลบรายการแฮชในฐานข้อมูลแถวมรณะด้วย
4. บางครั้งหัวใหม่ของโซ่จะไม่อยู่ด้านบนของหัวก่อนหน้าและคุณจะต้องเปลี่ยนบล็อก สำหรับกรณีเหล่านี้คุณจะต้องเก็บวารสารการเปลี่ยนแปลงทั้งหมดไว้ในฐานข้อมูลทั้งหมด (นั่นคือ “วารสาร” เช่นเดียวกับใน ระบบการบันทึกไฟล์– โดยพื้นฐานแล้วรายการที่สั่งซื้อของการเปลี่ยนแปลงที่เกิดขึ้น); เมื่อย้อนกลับบล็อกให้ลบรายการมรณะที่สร้างขึ้นเมื่อผลิตบล็อกนั้นและยกเลิกการเปลี่ยนแปลงที่เกิดขึ้นตามวารสาร (และลบวารสารเมื่อคุณทำเสร็จแล้ว)
5. เมื่อประมวลผลบล็อกให้ลบวารสารที่บล็อก n – x– คุณไม่สามารถย้อนกลับได้มากกว่า x บล็อกอยู่ดีดังนั้นวารสารจะฟุ่มเฟือย (และถ้าได้รับการเก็บรักษาจริง ๆ แล้วจะเอาชนะจุดทั้งหมดของการตัดแต่งกิ่ง)

เมื่อทำสิ่งนี้เสร็จแล้วฐานข้อมูลควรจัดเก็บโหนดสถานะที่เกี่ยวข้องกับล่าสุดเท่านั้น x บล็อกดังนั้นคุณจะยังคงมีข้อมูลทั้งหมดที่คุณต้องการจากบล็อกเหล่านั้น แต่ไม่มีอะไรเพิ่มเติม ยิ่งไปกว่านั้นมีการเพิ่มประสิทธิภาพเพิ่มเติม โดยเฉพาะอย่างยิ่งหลังจากนั้น x ควรลบบล็อกการทำธุรกรรมและใบเสร็จรับเงินทั้งหมดและแม้กระทั่งบล็อกอาจถูกลบเนื้อหาเช่นกัน – แม้ว่าจะมีข้อโต้แย้งที่สำคัญสำหรับการเก็บชุดย่อยของ “โหนดเก็บถาวร” ที่เก็บทุกอย่างอย่างแน่นอนเพื่อช่วยให้ส่วนที่เหลือของเครือข่ายได้รับข้อมูลที่ต้องการ

ตอนนี้สิ่งนี้สามารถออมได้มากแค่ไหน? เมื่อปรากฎว่าค่อนข้างเยอะมาก! โดยเฉพาะอย่างยิ่งถ้าเราต้องใช้เส้นทาง Daredevil สุดยอดและไป x = 0 (เช่น. สูญเสียความสามารถทั้งหมดอย่างแน่นอนในการจัดการกับส้อมเดี่ยวแม้กระทั่งเก็บประวัติใด ๆ ) จากนั้นขนาดของฐานข้อมูลจะเป็นขนาดของรัฐ: ค่าที่แม้ตอนนี้ (ข้อมูลนี้ถูกจับที่บล็อก 670000) อยู่ที่ประมาณ 40 เมกะไบต์ บัญชีเช่นนี้ ด้วยช่องเก็บของที่เต็มไปด้วยสแปมเครือข่ายโดยเจตนา ที่ x = 100000เราจะได้รับขนาดปัจจุบันของ 10-40 กิกะไบต์เนื่องจากการเติบโตส่วนใหญ่เกิดขึ้นในช่วงร้อยพันบล็อกที่ผ่านมาและพื้นที่พิเศษที่จำเป็นสำหรับการจัดเก็บวารสารและรายการแถวมรณะจะทำให้ส่วนที่เหลือของความแตกต่าง ทุกค่าในระหว่างนั้นเราสามารถคาดหวังว่าการเติบโตของพื้นที่ดิสก์จะเป็นเส้นตรง (เช่น x = 10,000 จะพาเราไปประมาณเก้าสิบเปอร์เซ็นต์ของทางไปใกล้ศูนย์)

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

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