ประวัติศาสตร์การเติบโตคืออะไร?

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

รูปที่ 1 แสดงความสัมพันธ์ระหว่างการเติบโตทางประวัติศาสตร์ ตัวชี้วัดโปรโตคอลต่าง ๆ และ ข้อจำกัดของฮาร์ดแวร์โหนด Ethereum ขณะที่การเติบโตของสถานะถูกควบคุมโดยชุดข้อจำกัดของฮาร์ดแวร์ที่แตกต่างกัน การเติบโตนี้กดดันที่ I/O ของเครือข่ายเนื่องจากบล็อกและธุรกรรมใหม่ ๆ ต้องถูกส่งผ่านเครือข่าย มันยังทำให้พื้นที่จัดเก็บของโหนดถูกกดอัดเนื่องจากทุกโหนด Ethereum จัดเก็บสำเนาทั้งหมดของบันทึกประวัติศาสตร์ หากการเติบโตทางประวัติศาสตร์เร็วกว่าข้อจำกัดของฮาร์ดแวร์เหล่านี้ โหนดจะไม่สามารถเติบโตไปพร้อมกันกับคู่แข่งของพวกเขาแล้วส่วนที่ 1ของซีรีส์นี้

รูปที่ 1: ข้อจำกัดการขยาย Ethereum

จนถึงเร็วๆ นี้ ส่วนใหญ่ของประสิทธิภาพของเครือข่ายของแต่ละโหนดถูกใช้สำหรับการส่งบันทึกประวัติ (เช่นบล็อกและธุรกรรมใหม่) สิ่งนี้เปลี่ยนแปลงไปกับการนำเสนอ blobs ใน Dencunhard fork ตอนนี้เป็นส่วนสำคัญของกิจกรรมเครือข่ายโหนด อย่างไรก็ตาม หัวเราะไม่ถือว่าเป็นส่วนหนึ่งของบันทึกประวัติเพราะ 1) โหนดจัดเก็บข้อมูลเหล่านี้เพียง 2 สัปดาห์ก่อนทิ้งทิ้งและ 2) ไม่จำเป็นสำหรับการเล่นซ้ำโซ่จาก Genesis เนื่องจาก (1) หัวเราะไม่ทำให้ภาระการจัดเก็บข้อมูลบนโหนด Ethereum แต่ละตัวเพิ่มขึ้นอย่างมีนัยสำคัญ ในภายหลังเราจะพูดถึงหัวเราะในรายละเอียดมากขึ้นในบทความนี้

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

ประวัติศาสตร์พัฒนาเร็วขนาดไหน?

รูปที่ 2 แสดงอัตราการเติบโตในอดีตเมื่อเวลาผ่านไปนับตั้งแต่การกําเนิดของ Ethereum แถบแนวตั้งแต่ละแท่งแสดงถึงการเติบโตหนึ่งเดือน แกน Y แสดงจํานวน GB ที่เพิ่มลงในประวัติในเดือนนั้น ธุรกรรมจะถูกจัดหมวดหมู่ตาม "ที่อยู่ปลายทาง" และขนาดจะถูกกําหนดโดยใช้ RLPการแปลงบายต์ สัญญาที่ไม่สามารถระบุได้อย่างง่ายถูกจัดอยู่ในหมวดหมู่ "ไม่ทราบ" หมวดหมู่ "อื่น ๆ" รวมถึงหางยาวของหมวดหมู่ขนาดเล็ก เช่น โครงสร้างพื้นฐานและเกม

สามารถวาดข้อสรุปสำคัญได้จากแผนภูมินี้หลายข้อ

1. อัตราการเติบโตทางประวัติศาสตร์มีอัตราการเติบโตประมาณ 6 ถึง 8 เท่าของการเติบโตของรัฐ: การเติบโตของประวัติศาสตร์เมื่อเร็วที่สุดที่ 36.0 GiB/เดือน และในปัจจุบันคือ 19.3 GiB/เดือน การเติบโตของรัฐเมื่อเร็วที่สุดที่ประมาณ 6.0 GiB/เดือน และตอนนี้คือ 2.5 GiB/เดือน สามารถดูเปรียบเทียบระหว่างการเติบโตทางประวัติศาสตร์และการเติบโตของรัฐทั้งในเชิงอัตราและขนาดสะสมได้ในภายหลังในบทความนี้
2. อัตราการเติบโตที่สร้างสรรค์ในอดีตก่อน Dencun: ในขณะที่อัตราการเติบโตของรัฐมีความเร็วเพิ่มขึ้นเรื่อยๆ ในหลายปีดูส่วนที่ 1) การเติบโตทางประวัติศาสตร์มีลักษณะเชิงเส้นคือการเพิ่มขึ้นตามอัตรากำลังสองในขนาดโดยรวม ในขณะที่การเติบโตทางเชิงเส้นเพิ่มขึ้นอย่างรวดเร็วกว่าการเพิ่มขึ้นตามอัตรากำลังสอง การเร่งเร็วนี้หยุดอย่างรวดเร็วหลังจาก Dencun ซึ่งเป็นจุดหยุดที่สำคัญครั้งแรกในประวัติศาสตร์การเติบโตของ Ethereum
3. การเติบโตทางประวัติศาสตร์ล่าสุดมาจาก Rollups: แต่ละ L2 จะโพสต์สำเนาของธุรกรรมกลับไปยัง mainnet ซึ่งทำให้มีปริมาณข้อมูลประวัติศาสตร์ที่สำคัญและทำให้ Rollups เป็นผู้มีส่วนร่วมสูงสุดในการเติบโตทางประวัติศาสตร์ในปีที่ผ่านมา อย่างไรก็ตาม Dencun ช่วยให้ L2s ใช้ blobs แทนบันทึกประวัติศาสตร์เพื่อโพสต์ข้อมูลธุรกรรมของตัวเอง ดังนั้น Rollups จึงไม่ได้สร้างบันทึกประวัติศาสตร์ของ Ethereum มากที่สุดแล้ว เราจะสำรวจเกี่ยวกับ Rollups อีกในบทความนี้

อะไรคือผู้มีส่วนร่วมที่สำคัญที่สุดในประวัติศาสตร์ของ Ethereum?

ปริมาณของข้อมูลประวัติศาสตร์ที่สร้างขึ้นโดยแต่ละหมวดหมู่ของสัญญาเปิดเผยถึงว่ารูปแบบการใช้ Ethereum ได้อวิว่าเปลี่ยนแปลงไปยังไหนตลอดเวลา ภาพที่ 3 แสดงผลการมีส่วนร่วมของหมวดหมู่สัญญาต่าง ๆ โดยใช้ข้อมูลเดียวกันกับภาพที่ 2 ที่มีการปรับค่าให้อยู่ที่ 100%

ข้อมูลเปิดเผยถึงสี่ยุคที่แตกต่างกันของรูปแบบการใช้งาน Ethereum:

ยุคเริ่มต้น (สีม่วง): ในปีแรกของ Ethereum มีกิจกรรม on-chain ที่น้อยมาก ส่วนใหญ่ของสัญญาเหล่านี้ในยุคเริ่มต้นเราตอนนี้ยากที่จะระบุและถูกติดป้ายว่า "unknown" ในแผนภูมิ

ยุค ERC-20 (สีเขียว): มาตรฐาน ERC-20ได้เสร็จสมบูรณ์ในปลายปี 2015 แต่ไม่ได้รับความสนใจมากจนถึงปี 2017 และ 2018 โดยในปี 2019 สัญญา ERC-20 เป็นหมวดหมู่ที่ใหญ่ที่สุดในการเติบโตในอดีต

ยุค DEX/DeFi (สีน้ำตาล): สัญญา DEX และ DeFi ปรากฏบนเชนตั้งแต่ปี 2016 และเริ่มได้รับความสนใจในปี 2017 อย่างไรก็ตาม พวกเขาก็ไม่ได้เป็นหมวดหมู่ที่ใหญ่ที่สุดในประวัติศาสตร์จนถึงฤดูร้อนของ DeFi ปี 2020. สัญญา DeFi และ DEX มีระดับสูงสุดของการเติบโตในประวัติศาสตร์มากกว่า 50% ในช่วงเวลาต่างๆ ในปี 2021 และ 2022

ยุค Rollup (สีเทา): ในต้นปี 2023 L2 Rollups เริ่มดำเนินการอย่างต่อเนื่องมากกว่าธุรกรรมบนเครือข่ายหลักนี่ตรงกับสัญญาของพวกเขาที่สร้างข้อมูลประวัติที่มากมาย ซึ่งเป็นประมาณสองในสามของการเติบโตของ Ethereum ในช่วงเดือนก่อน Dencun

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

ในข้อมูลล่าสุด (เมษายน 2024) การแก้ไขไม่สร้างบันทึกประวัติในส่วนใหญ่อีกต่อไป ยังไม่ชัดเจนว่าการเติบโตทางประวัติศาสตร์ในอนาคตจะถูกควบคุมโดย DEX และ DeFi หรือว่ารูปแบบการใช้งานใหม่จะเกิดขึ้น

มันเกี่ยวกับ blobs อย่างไร?

การนำเข้า blobs ใน Dencun hard fork ได้เปลี่ยนแปลงดีนามิกส์ของการเติบโตในอดีตอย่างมีนัยยะ ทำให้ Rollups สามารถใช้ blobs ราคาถูกแทนที่บันทึกอดีตเพื่อโพสต์ข้อมูล รูปที่ 4 ขยายมุมมองเกี่ยวกับอัตราการเติบโตในอดีตรอบวันของการอัปเกรด Dencun แผนภูมินี้คล้ายกับรูปที่ 2 แต่แท่งแนวตั้งแต่ละแท่งแทนหนึ่งวันแทนที่หนึ่งเดือน

สามารถวาดสรุปหลักๆ ได้จากแผนภูมินี้หลายข้อ

การเติบโตของ Rollups ในอดีตลดลงประมาณสองในสามตั้งแต่ Dencun: ส่วนใหญ่ของ rollups ได้ย้ายจากการใช้ข้อมูลการเรียกไปสู่ blobs ซึ่งลดจำนวนข้อมูลประวัติที่พวกเขาสร้างขึ้นอย่างมีนัยยะ อย่างไรก็ตาม ณ เมษายน 2024 บางส่วนrollupsยังไม่ได้สลับจากข้อมูลการโทรเป็นบล็อบ

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

นับจากการลดลงของการเติบโตในอดีต blobs ยังคงเป็นการเพิ่มเติมใหม่สำหรับ Ethereum ยังไม่ชัดเจนว่าการเติบโตในอดีตจะเสถียรไว้ที่ไหนในสภาพของ blobs

ประวัติศาสตร์การเติบโตมากเท่าไรที่ยอมรับได้?

การเพิ่มขีดจำกัดแก๊สจะเพิ่มอัตราการเจริญของประวัติศาสตร์ ดังนั้น ข้อเสนอในการเพิ่มขีดจำกัดแก๊ส (เช่น Pump the Gas) ต้องพิจารณาความสัมพันธ์ระหว่างการเติบโตทางประวัติศาสตร์ และข้อจำกัดด้านฮาร์ดแวร์บนแต่ละโหนด

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

ภาพที่ 5 แสดงภาระการเก็บข้อมูลของโหนด Ethereum ตลอดเวลา และยังทำนายว่าภาระนี้จะเติบโตขึ้นอีกในอีก 3 ปี การทำนายนี้ใช้อัตราการเติบโตจากเดือนเมษายน 2024 อัตราการเติบโตนี้อาจเพิ่มขึ้นหรือลดลงในอนาคตเนื่องจากการเปลี่ยนแปลงในรูปแบบการใช้หรือขีดจำกัดแก๊ส

สามารถวิเคราะห์บางข้อสำคัญจากรูปแผนภูมินี้ได้

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

พ้นค่าเกณฑ์ที่สำคัญรอบ 1.8 TiB: หลายโหนดจะถูกบังคับให้อัปเกรดฮาร์ดไดรฟ์ของพวกเขาในจุดนี้ ฮาร์ดไดรฟ์ขนาด 2TB ที่เป็นขนาดที่พบบ่อยให้พื้นที่ที่ใช้งานได้เพียง 1.8 TiB เท่านั้น โปรดทราบว่า TB (เทระไบต์) และ TiB (เทบิไบต์, = 1024^4 ไบต์) เป็นหน่วยที่แตกต่างกัน สำหรับผู้ดำเนินโหนดหลายคน เกณฑ์ที่สำคัญ "จริง" ยังต่ำกว่านั้นเพราะผู้ตรวจสอบต้องเรียกใช้ไคลเอนต์ความเห็นพร้อมกับไคลเอนต์ดำเนินการหลังการผสาน

ถึงเกณฑ์ใน 2-3 ปี: การเพิ่มขีดจำกัดแก๊สจะเร่งความเร็วของไทม์ไลน์นี้ การเข้าถึงเกณฑ์นี้จะส่งผลให้ผู้ดำเนินโหนดมีภาระการบำรุงรักษาที่สำคัญ จำเป็นต้องซื้อฮาร์ดแวร์เพิ่มเติม เช่น $300 ไดรฟ์ NVME

การเก็บข้อมูลประวัติแยกกัน: ในขณะที่ข้อมูลสถานะเป็นข้อมูลแบบแอพเพนโอนลีและมีการเข้าถึงน้อยกว่า จึงสามารถเก็บข้อมูลประวัติแยกจากข้อมูลสถานะบนสื่อเก็บข้อมูลราคาถูกได้ทึ่อย่างทฤษฎี. บางลูกค้า เช่น GethGate.io รองรับการแยกนี้แล้ว

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

เพื่อเข้าใจว่าความจุของเครือข่ายที่เราสามารถรองรับได้จากโหนด Ethereum ปกติเป็นเท่าไรในประวัติศาสตร์ จำเป็นต้องอธิบายความสัมพันธ์ระหว่างการเจริญเติบโตทางประวัติศาสตร์และตัวชี้วัดสุขภาพของเครือข่ายต่าง ๆ เช่น อัตราการเรียงลำดับใหม่ การพลาดช่องชนะ ขาดความชัดเจน การขาดการรับรอง การพลาดของคณะเทียบเทียบ และการล่าช้าในการเสนอบล็อก การวิเคราะห์ตัวชี้วัดเหล่านี้อยู่นอกขอบเขตของบทความนี้ แต่สามารถพบได้ในการสำรวจก่อนหน้าเกี่ยวกับสุขภาพของชั้นเห็นร่วม [1] [2] [3]4]. นอกจากนี้ มูลนิธิ Ethereum @ethpandaops/xatu-overview">โครงการ Xatu ได้กำลังสร้างชุดข้อมูลสาธารณะเพื่อให้การวิเคราะห์เช่นนี้เป็นไปได้

วิธีการแก้ปัญหาการเติบโตของประวัติศาสตร์?

การเติบโตทางประวัติศาสตร์เป็นปัญหาที่ง่ายกว่าในการที่จะแก้ไขการเติบโตของรัฐ ที่เสนอEIP-4444แก้ปัญหานี้เกือบทั้งหมด EIP นี้เปลี่ยนความต้องการสำหรับแต่ละโหนดจากการเก็บประวัติ Ethereum ทั้งหมดเป็นการเก็บประวัติเพียงหนึ่งปี เมื่อ EIP-4444 ถูกนำมาใช้ แม้จะมีการเพิ่มขีดจำกัดแก๊สอย่างมีนัยยะในระยะยาว การจัดเก็บข้อมูลจะไม่เป็นข้อจำกัดสำหรับการขยายของ Ethereum EIP-4444 นั้นเป็นสิ่งจำเป็นสำหรับความยั่งยืนในระยะยาวของเครือข่าย ถ้าไม่งั้น ข้อมูลประวัติจะเติบโตอย่างรวดเร็วพอที่จะต้องการการอัพเกรดฮาร์ดแวร์เป็นระยะเป็นระยะสำหรับโหนดของเครือข่าย

ภาพที่ 6 แสดงถึงวิธีที่ EIP-4444 จะส่งผลต่อภาระการเก็บข้อมูลของแต่ละโหนดในระยะเวลา 3 ปีถัดไป นี้คล้ายกับภาพที่ 4 โดยมีการเพิ่มเส้นที่เล็กกว่า แทนการเก็บข้อมูลหลังจากการนำ EIP-4444 ไปใช้งาน

สามารถวาดสรุปสำคัญหลายข้อจากแผนภูมินี้

EIP-4444 จะลดภาระการเก็บข้อมูลปัจจุบันลงครึ่ง: ภาระการเก็บข้อมูลจะลดลงจาก 1.2 TiB เป็น 633 GiB

EIP-4444 จะทำให้การจัดเก็บข้อมูลประวัติศาสตร์เป็นไปอย่างมีความเสถียร: ในกรณีที่มีอัตราการเติบโตของข้อมูลประวัติศาสตร์คงที่ ข้อมูลประวัติศาสตร์จะถูกทิ้งลงไปในอัตราเดียวกันที่มันถูกสร้างขึ้น

หลังจาก EIP-4444, จะใช้เวลาหลายปีจึงจะเกิดภาระการเก็บข้อมูลในระดับปัจจุบัน: นี่เป็นเพราะการเติบโตของสถานะที่ช้ากว่าการเติบโตในอดีต จะเป็นปัจจัยที่เพิ่มภาระการเก็บข้อมูลเท่านั้น

EIP-4444 ยังคงมีภาระการเก็บข้อมูลบางส่วนเนื่องจากข้อมูลประวัติที่ยาวนานหนึ่งปี: อย่างไรก็ตามภาระนี้จะสามารถจัดการได้ แม้ว่า Ethereum จะขยายตัวไปทั่วโลกก็ตาม หลังจากที่วิธีการจัดการข้อมูลประวัติได้รับการยอมรับว่าเชื่อถือได้ ระยะเวลาการเก็บรักษาหนึ่งปีใน EIP-4444 อาจถูกลดลงเป็นเดือนหรือสัปดาห์หรือน้อยลงได้

วิธีการสงวนประวัติศาสตร์ของ Ethereum?

EIP-4444 raises the question: if Ethereum nodes themselves do not preserve the history, how should it be preserved? History is crucial for Ethereum’s verification, accounting, and analysis, so it must be preserved. Fortunately, preserving history is straightforward, requiring only 1/n honest data providers, compared to the state consensus problem, which needs 1/3 to 2/3 honest participants. Node operators can verify the authenticity of any historical dataset by: 1) replaying all transactions from Genesis; and 2) checking if these transactions reproduce the same state root as the current chain tip.

มีวิธีหลายวิธีที่ใช้ในการอนุรักษ์ประวัติศาสตร์ แต่ละวิธีควรใช้พร้อมกันเพื่อเพิ่มโอกาสในการอนุรักษ์

Torrents / P2P: Torrentsเป็นวิธีที่ง่ายและทนทานที่สุด โหนด Ethereum สามารถจัดห่วงบางส่วนของประวัติและแบ่งปันในรูปแบบไฟล์ torrent สาธารณะ เช่น โหนดอาจสร้างไฟล์ torrent ประวัติใหม่ทุก 100,000 บล็อก บางโหนดไคลเอนต์ เช่น Erigon ได้ดำเนินกระบวนการนี้อยู่แล้วในรูปแบบที่ไม่ได้มาตรฐาน ในการมาตรฐานกระบวนการนี้ โหนดไคลเอนต์ทุกตัวต้องใช้รูปแบบข้อมูลเดียวกัน พารามิเตอร์ และเครือข่าย P2P โหนดสามารถเลือกที่จะเข้าร่วมในเครือข่ายนี้ขึ้นอยู่กับความจุพื้นที่จัดเก็บข้อมูลและแบนด์วิดธ์ของตน ข้อดีของการใช้ torrents คือการใช้มาตรฐานเปิดที่ได้รับการสนับสนุนจากนวัตกรรมเครื่องมือข้อมูลขนาดใหญ่

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

การเก็บข้อมูลบนคลาวด์: บริการเก็บข้อมูลบนคลาวด์ เช่น AWSS3หรือ CloudflareR2 เสนอตัวเลือกราคาถูกและมีประสิทธิภาพสูงสําหรับการรักษาประวัติศาสตร์ อย่างไรก็ตามวิธีนี้มาพร้อมกับความเสี่ยงทางกฎหมายและการดําเนินธุรกิจมากขึ้นเนื่องจากบริการคลาวด์เหล่านี้อาจไม่เต็มใจหรือสามารถโฮสต์ข้อมูลสกุลเงินดิจิทัลได้เสมอไป

ความท้าทายในการดำเนินการที่เหลืออยู่เกี่ยวกับด้านสังคมมากกว่าด้านเทคนิค ชุมชน Ethereum ต้องประสานงานกันเกี่ยวกับรายละเอียดการดำเนินการเฉพาะ เพื่อให้สามารถนำเข้าโดยตรงลงในทุกๆ โหนดไคลเอนต์ สำคัญอยู่ที่การซิงค์แบบเต็มจาก Genesis (แทนการซิงค์จากสแนปช็อต) จะต้องการการเรียกร้องประวัติจากผู้ให้บริการข้อมูลประวัติย้อนหลังแทนการซิงค์จากโหนด Ethereum การเปลี่ยนแปลงเหล่านี้ไม่ต้องการฟอร์คแบบแข็งและสามารถนำมาใช้ได้ก่อนฟอร์คแบบแข็งถัดไปของ Ethereum ที่ชื่อ Pectra

L2s ยังสามารถใช้วิธีเหล่านี้ทั้งหมดเพื่อรักษาข้อมูลบล็อบที่พวกเขาเผยแพร่ไปยัง mainnet การรักษาข้อมูลบล็อบมีความท้าทายมากขึ้นเนื่องจากมีปริมาณข้อมูลรวมทั้งสิ้นที่มากขึ้น; น้อยกว่าสำคัญเนื่องจากบล็อบไม่จำเป็นสำหรับการเล่นเอ็นเครืองหลัก อย่างไรก็ตาม การรักษาข้อมูลบล็อบจำเป็นสำหรับแต่ละ L2 เพื่อเล่นเอ็นเครืองหลักของตนเอง ดังนั้น การรักษาข้อมูลบล็อบรูปแบบหนึ่งจำเป็นสำหรับระบบนิเวศ Ethereum ทั้งนี้ อีกทั้งหาก L2s พัฒนาโครงสร้างพื้นฐานการเก็บข้อมูลบล็อบที่เข้มแข็งพวกเขายังสามารถเก็บข้อมูลประวัติ L1 ได้อย่างง่ายดาย

การเปรียบเทียบโดยตรงของชุดข้อมูลที่เก็บไว้โดยการกำหนดค่าโหนดต่าง ๆ ก่อนและหลัง EIP-4444 จะมีประโยชน์ ภาพที่ 7 แสดงภาระของการเก็บข้อมูลของประเภทโหนด Ethereum ข้อมูลสถานะรวมถึงบัญชีและสัญญา ข้อมูลประวัติรวมถึงบล็อคและธุรกรรม และข้อมูลเก่าเป็นชุดข้อมูลดัชนีทางเลือก นับไบต์ในตารางนี้คิดจากสแนปช็อต reth ล่าสุด แต่ตัวเลขควรจะเป็นเปรียบเทียบได้โดยประมาณในไคลเอ็นต์โหนดอื่น ๆ

รูปที่ 7: ภาระการเก็บข้อมูลของประเภทโหนด Ethereum

ในภาษา,

1. โหนดเก็บข้อมูลสถานะที่เก่า ข้อมูลประวัติ และข้อมูลเก็บถาวร ใช้เมื่อต้องการค้นหาสถานะของโซ่ประวัติได้ง่าย
2. โหนดเต็มเก็บข้อมูลประวัติและข้อมูลสถานะเท่านั้น โหนดส่วนใหญ่ในปัจจุบันเป็นโหนดเต็ม ภาระของการเก็บข้อมูลของโหนดเต็มประมาณครึ่งหนึ่งของโหนดเก็บข้อมูลเข้าถึง
3. หลังจาก EIP-4444 เครื่องบริการโหนดเต็มจะเก็บข้อมูลสถานะและข้อมูลประวัติที่ผ่านมาหลังจากปีล่าสุดเท่านั้น ซึ่งจะลดภาระการเก็บข้อมูลจาก 1.2 TiB เหลือ 633 GiB และทำให้การใช้พื้นที่จัดเก็บข้อมูลประวัติเป็นเสถียร
4. โหนดแบบปราศจากสถานะหรือที่เรียกว่า “โหนดแสง” ไม่เก็บข้อมูลชุดข้อมูลเหล่านี้เลยและสามารถตรวจสอบที่จุดปลายของเชนได้ทันที ประเภทของโหนดนี้กลายเป็นไปได้เมื่อVerkle พยายามหรือระบบการสำรองที่อื่น ๆ ถูกเพิ่มใน Ethereum

ในที่สุดมีข้อเสนอเพิ่มเติมในระบบนิเวศที่มีจุดประสงค์ที่จะ จำกัด อัตราการเติบโตในอดีตแทนที่จะเพียงปรับเปลี่ยนตามอัตราปัจจุบันเท่านั้น นี้เป็นประโยชน์สำหรับการรักษาขีดจำกัดของเครือข่าย IO ในระยะสั้นและขีดจำกัดพื้นที่เก็บข้อมูลในระยะยาว ในขณะที่ EIP-4444 เป็นสิ่งจำเป็นสำหรับความยั่งยืนในระยะยาวของเครือข่าย EIPs อื่น ๆ เหล่านี้จะช่วยให้ Ethereum ขยายตัวได้อย่างมีประสิทธิภาพมากขึ้นในอนาคต:

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

EIP-4488: ข้อเสนอนี้กำหนดขีดจำกัดในปริมาณรวมของข้อมูลการโทรทั้งหมดที่สามารถรวมอยู่ในแต่ละบล็อก โดยใช้การควบคุมเข้มงวดกว่าเดิมในอัตราการเติบโตของประวัติ

EIPเหล่านี้ง่ายต่อการนำมาใช้งานกว่า EIP-4444 และสามารถทำหน้าที่เป็นมาตราการชั่วคราวก่อนที่ EIP-4444 จะพร้อมใช้งานในการผลิต

สรุป

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

การเติบโตทางประวัติศาสตร์เป็นจุดขีดจำกัดของความสามารถในการขยายของ Ethereum ที่ได้รับความสนใจไม่เพียงพอ แม้ว่าจะไม่เพิ่มขีดจำกัดของแก๊ส การปฏิบัติปัจจุบันในการเก็บประวัติบน Ethereum ก็จะต้องการให้โหนดหลายๆ ตัวอัพเกรดฮาร์ดแวร์ของพวกเขาในไม่กี่ปีข้างหน้า อย่างดีที่ว่านี่ไม่ใช่ปัญหาที่ยากมากที่จะแก้ไข มีวิธีการชัดเจนที่ได้รับการกำหนดไว้ใน EIP-4444 พวกเราเชื่อว่าควรมีการเร่งรัดในการนำ EIP นี้ไปสู่การใช้งานเพื่อเตรียมที่จะเพิ่มขีดจำกัดของแก๊สในอนาคต

หากคุณสนใจในงานวิจัยเกี่ยวกับความสามารถในการขยายของ Ethereum กรุณาติดต่อstorm@paradigm.xyzและgeorgios@paradigm.xyz.เราต้องการฟังมุมมองของคุณเกี่ยวกับปัญหานี้และสำรวจความร่วมมือที่เป็นไปได้ ข้อมูลและโค้ดที่ใช้ในบทความนี้สามารถใช้ได้พบเห็นบนGithub.

การยอมรับ

ขอขอบคุณมากThomas Thiery、ทีม Beiko、Toni Wahrstaetter、Oliver NordbjergและRoman Krasiukสำหรับการทบทวนและข้อเสนอแนะของพวกเขา ขอบคุณAchal Srinivasanสำหรับตัวเลขที่ให้มาในรูปที่ 1 และรูปที่ 7

ข้อปฏิเสธ：

1. บทความนี้ถูกพิมพ์โดย [Marsbit]. สิทธิ์ในการคัดลอกทั้งหมดเป็นของผู้เขียนต้นฉบับ [ Storm Slivkoff, Georgios Konstantopoulos]. หากมีข้อโต้แย้งใดๆ เกี่ยวกับการพิมพ์ฉบับซ้ำนี้ โปรดติดต่อGate Learnทีมและพวกเขาจะดูแลมันโดยเร่งด่วน
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นคำแนะนำในการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่น ๆ ทำโดยทีม Gate Learn โดยไม่ได้กล่าวถึงการคัดลอก การกระจาย หรือการลอกเลียนบทความที่ถูกแปล