กระบวนทัศน์: คำอธิบายโดยละเอียดเกี่ยวกับปัญหาการเติบโตในอดีตของ Ethereum และแนวทางแก้ไข

ผู้เขียนต้นฉบับ: Storm Slivkoff, Georgios Konstantopoulos

ต้นฉบับเรียบเรียง: ลูฟี่, Foresight News

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

ข่าวดีก็คือ:

• การเติบโตทางประวัติศาสตร์เป็นปัญหาที่แก้ไขได้ง่ายกว่าการเติบโตของรัฐ

• โซลูชั่นอยู่ระหว่างการพัฒนาอย่างแข็งขัน

• การจัดการกับการเติบโตในอดีตจะช่วยบรรเทาปัญหาการเติบโตของรัฐได้

ในบทความนี้ เราจะดูปัญหาการปรับขนาด Ethereum ต่อไปจากส่วนที่ 1 ซึ่งตอนนี้เปลี่ยนความสนใจของเราจากการเติบโตของรัฐไปสู่การเติบโตในอดีต การใช้ชุดข้อมูลที่ละเอียด เป้าหมายของเราคือ 1) เข้าใจทางเทคนิคเกี่ยวกับปัญหาคอขวดในการปรับขนาดของ Ethereum และ 2) สนับสนุนการอภิปรายเกี่ยวกับโซลูชันที่เหมาะสมที่สุดสำหรับขีดจำกัดก๊าซของ Ethereum

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

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

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

รูปที่ 1: คอขวดในการขยาย Ethereum

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

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

ประวัติศาสตร์เติบโตเร็วแค่ไหน?

รูปที่ 2 แสดงอัตราการเติบโตในอดีตของ Ethereum นับตั้งแต่ก่อตั้ง เส้นแนวตั้งแต่ละเส้นแสดงถึงการเติบโตในหนึ่งเดือน แกน y แสดงถึงการเติบโตในอดีตในหน่วยกิกะไบต์ของเดือนนั้น ธุรกรรมถูกจำแนกตาม "ที่อยู่ปลายทาง" และขนาดแสดงโดยใช้ไบต์ RLP (https://ethereum.org/en/developers/docs/data-structors-and-encoding/rlp/) สัญญาที่ไม่สามารถระบุได้ง่ายจะถูกจัดประเภทเป็น "ไม่ทราบ" หมวดหมู่ "อื่นๆ" ประกอบด้วยหมวดหมู่ย่อยต่างๆ เช่น โครงสร้างพื้นฐานและเกม

รูปที่ 2: อัตราการเติบโตของ Ethereum ในอดีตในช่วงเวลาหนึ่ง

ประเด็นสำคัญบางประการจากแผนภูมิด้านบน:

• อัตราการเติบโตในอดีตนั้นเร็วกว่าการเติบโตของรัฐ 6 ถึง 8 เท่า: อัตราการเติบโตในอดีตเมื่อเร็ว ๆ นี้สูงถึง 36.0 GiB ต่อเดือน และปัจจุบันอยู่ที่ 19.3 GiB ต่อเดือน อัตราการเติบโตของสถานะสูงสุดที่ประมาณ 6.0 GiB ต่อเดือน และปัจจุบันอยู่ที่ 2.5 GiB ต่อเดือน การเปรียบเทียบประวัติและสถานะในแง่ของการเติบโตและขนาดสะสมจะอธิบายไว้ในบทความนี้

• ก่อนที่จะมี Decun อัตราการเติบโตในอดีตมีการเร่งตัวขึ้น ในขณะที่รัฐมีการเติบโตเป็นเส้นตรงในช่วงหลายปีที่ผ่านมา (ดูส่วนที่ 1) การเติบโตในอดีตนั้นมีความเหนือชั้นมาก เนื่องจากอัตราการเติบโตเชิงเส้นนำไปสู่การเติบโตกำลังสองในขนาดโดยรวม อัตราการเติบโตเชิงเส้นเหนือนำไปสู่การเติบโตที่มากกว่ากำลังสองในขนาดโดยรวม การเร่งความเร็วนี้หยุดกะทันหันหลังจาก Dencun นี่เป็นครั้งแรกที่ Ethereum ประสบกับอัตราการเติบโตที่ลดลงอย่างมากในอดีต

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

ใครคือผู้มีส่วนร่วมที่ใหญ่ที่สุดต่อการเติบโตในอดีตของ Ethereum?

ปริมาณในอดีตที่สร้างโดยหมวดหมู่สัญญาที่แตกต่างกันเผยให้เห็นว่ารูปแบบการใช้งานของ Ethereum มีการพัฒนาอย่างไรเมื่อเวลาผ่านไป รูปที่ 3 แสดงการมีส่วนร่วมของสัญญาประเภทต่างๆ นี่เป็นข้อมูลเดียวกันกับรูปที่ 2 ที่ทำให้เป็นมาตรฐาน

รูปที่ 3: การมีส่วนร่วมของสัญญาประเภทต่างๆ ต่อการเติบโตในอดีต

ข้อมูลเผยให้เห็นช่วงเวลาที่แตกต่างกันสี่ช่วงของรูปแบบการใช้งาน Ethereum:

• ช่วงปีแรกๆ (สีม่วง): ช่วงสองสามปีแรกของ Ethereum มีกิจกรรมออนไลน์เพียงเล็กน้อยหรือไม่มีเลย สัญญาในช่วงแรกเหล่านี้ส่วนใหญ่ระบุได้ยาก โดยมีป้ายกำกับว่า "ไม่ทราบ" บนแผนภูมิ

• ยุค ERC-20 (สีเขียว): มาตรฐาน ERC-20 ได้รับการสรุปในช่วงปลายปี 2558 แต่ไม่ได้รับการพัฒนาที่สำคัญจนกระทั่งปี 2560 และ 2561 สัญญา ERC-20 กลายเป็นแหล่งที่มาของการเติบโตที่ใหญ่ที่สุดในอดีตในปี 2562

• ยุค DEX/DeFi (สีน้ำตาล): สัญญา DEX และ DeFi ปรากฏบนเครือข่ายตั้งแต่ต้นปี 2559 และเริ่มได้รับความสนใจในปี 2560 แต่จนกระทั่งช่วงฤดูร้อนปี 2020 DeFi กลายเป็นหมวดหมู่ที่ใหญ่ที่สุดในแง่ของการเติบโตในอดีต สัญญา DeFi และ DEX คิดเป็นมากกว่า 50% ของการเติบโตในอดีตในปี 2021 และบางส่วนของปี 2022

• ยุค Rollup (สีเทา): ในต้นปี 2023 L2 Rollup เริ่มดำเนินการธุรกรรมมากกว่า mainnet ในช่วงหลายเดือนก่อนถึง Dencun พวกเขาสร้างประวัติศาสตร์ประมาณ 2/3 ของ Ethereum

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

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

แล้วบล็อบล่ะ?

ฮาร์ดฟอร์กของ Dencun นำเสนอ Blobs ซึ่งเปลี่ยนแปลงไดนามิกของการเติบโตในอดีตอย่างมีนัยสำคัญ ทำให้ Rollup สามารถเผยแพร่ข้อมูลโดยใช้ Blobs ราคาถูกแทนการบันทึกในอดีต รูปที่ 4 ขยายอัตราการเติบโตในอดีตของ Dencun ก่อนและหลังการอัพเกรด แผนภูมิจะคล้ายกับรูปที่ 2 ยกเว้นว่าเส้นแนวตั้งแต่ละเส้นแทนวันแทนที่จะเป็นเดือน

รูปที่ 4: ผลกระทบของ Dencun ต่อการเติบโตในอดีต

เราสามารถสรุปข้อสรุปที่สำคัญหลายประการจากแผนภูมินี้:

• การเติบโตในอดีตของ Rollups ลดลงประมาณ 2/3 นับตั้งแต่ Dencun: Rollup ส่วนใหญ่ถูกแปลงจากข้อมูลการโทรไปเป็น Blob ซึ่งช่วยลดจำนวนประวัติที่สร้างขึ้นได้อย่างมาก อย่างไรก็ตาม ณ เดือนเมษายน 2024 ยังมีรายงานบางส่วนที่ยังไม่ได้แปลงจากข้อมูลการโทรเป็น Blob

• การเติบโตในอดีตทั้งหมดลดลงประมาณ 1/3 นับตั้งแต่ Dencun: Dencun ลดเฉพาะการเติบโตในอดีตของ Rollup เท่านั้น สัญญาประเภทอื่นๆ มีการเติบโตเพิ่มขึ้นเล็กน้อยในอดีต แม้หลังจาก Dencun การเติบโตในอดีตก็ยังคงเติบโต 8 เท่า (ดูรายละเอียดหัวข้อถัดไป)

แม้ว่า Blobs จะชะลออัตราการเติบโตในอดีตลง แต่ก็ยังเป็นคุณสมบัติใหม่ของ Ethereum ยังไม่ชัดเจนว่าอัตราการเติบโตในอดีตจะคงที่ในระดับใดเมื่อมีหยด

การเติบโตในอดีตสามารถยอมรับได้เร็วแค่ไหน?

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

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

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

รูปที่ 5: ประวัติ สถานะ และขนาดของภาระการจัดเก็บข้อมูลแบบเต็มโหนด

เราสามารถสรุปผลสำคัญหลายประการจากตัวเลขนี้:

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

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

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

ต่างจากข้อมูลสถานะ ข้อมูลประวัติจะถูกผนวกเท่านั้นและเข้าถึงได้น้อยกว่ามาก ดังนั้นจึงเป็นไปได้ในทางทฤษฎีที่จะจัดเก็บข้อมูลประวัติแยกจากข้อมูลสถานะบนสื่อจัดเก็บข้อมูลที่มีราคาถูกกว่า ซึ่งสามารถทำได้ผ่านลูกค้าบางราย เช่น Geth

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

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

จะแก้ไขปัญหาการเติบโตในอดีตได้อย่างไร?

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

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

รูปที่ 6 : ผลกระทบของ EIP-4444 ต่อภาระการจัดเก็บข้อมูลของโหนด Ethereum

ข้อสรุปสำคัญบางประการสามารถสรุปได้จากรูปนี้:

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

• EIP-4444 จะรักษาภาระการจัดเก็บประวัติให้คงที่ สมมติว่าอัตราการเติบโตในอดีตคงที่ ข้อมูลในอดีตจะถูกละทิ้งในอัตราที่สร้างขึ้น

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

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

จะบันทึกประวัติของ Ethereum ได้อย่างไร?

EIP-4444 ทำให้เกิดคำถาม: หาก Ethereum nodes ไม่ได้เก็บประวัติไว้เอง แล้วจะเก็บไว้อย่างไร? ประวัติศาสตร์มีบทบาทสำคัญในการตรวจสอบ การบัญชี และการวิเคราะห์ของ Ethereum ดังนั้นการอนุรักษ์ไว้จึงเป็นสิ่งสำคัญ โชคดีที่การอนุรักษ์ประวัติศาสตร์เป็นปัญหาง่ายๆ ที่ต้องใช้ผู้ให้บริการข้อมูลที่ซื่อสัตย์เพียง 1 ใน n เท่านั้น ซึ่งตรงกันข้ามกับปัญหาฉันทามติของรัฐที่ต้องการความซื่อสัตย์จากผู้เข้าร่วม 1/3 ถึง 2/3 ผู้ดำเนินการโหนดสามารถตรวจสอบความถูกต้องของข้อมูลประวัติที่กำหนดโดย 1) เล่นซ้ำธุรกรรมทั้งหมดตั้งแต่บล็อกกำเนิด และ 2) ตรวจสอบว่าธุรกรรมเหล่านี้ปรากฏขึ้นอีกครั้งพร้อมกับรูทสถานะเดียวกันกับฝั่งบล็อกเชนปัจจุบัน

มีหลายวิธีในการบันทึกประวัติศาสตร์

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

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

• โฮสติ้งบนคลาวด์: บริการจัดเก็บข้อมูลบนคลาวด์ เช่น AWS's S 3 หรือ Cloudflare's R 2 มีตัวเลือกราคาถูกและประสิทธิภาพสูงสำหรับการบันทึกประวัติ อย่างไรก็ตาม แนวทางนี้ทำให้เกิดความเสี่ยงทางกฎหมายและการดำเนินธุรกิจมากขึ้น เนื่องจากไม่มีการรับประกันว่าบริการคลาวด์เหล่านี้จะยินดีและสามารถโฮสต์ข้อมูลสกุลเงินดิจิทัลได้ตลอดเวลา

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

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

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

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

กล่าวอีกนัยหนึ่ง

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

• โหนดแบบเต็มจะเก็บข้อมูลประวัติและข้อมูลสถานะเท่านั้น โหนดส่วนใหญ่ในปัจจุบันเป็นโหนดแบบเต็ม ภาระการจัดเก็บข้อมูลของโหนดเต็มอยู่ที่ประมาณครึ่งหนึ่งของโหนดเก็บถาวร

• โหนดแบบเต็มหลังจาก EIP-4444 จะจัดเก็บเฉพาะข้อมูลสถานะและข้อมูลประวัติปีล่าสุดเท่านั้น ซึ่งช่วยลดภาระการจัดเก็บข้อมูลบนโหนดจาก 1.2 TiB เหลือ 633 GiB และทำให้พื้นที่จัดเก็บข้อมูลสำหรับข้อมูลประวัติเป็นค่าสถานะคงที่

• โหนดไร้สถานะหรือที่เรียกว่า "โหนดแสง" จะไม่จัดเก็บชุดข้อมูลใดๆ และสามารถตรวจสอบได้ทันทีที่ส่วนท้ายของห่วงโซ่ โหนดประเภทนี้จะเป็นไปได้เมื่อมีการเพิ่มความพยายามของ Verkle หรือแผนข้อผูกมัดของรัฐอื่น ๆ ลงใน Ethereum

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

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

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

EIP เหล่านี้นำไปใช้ได้ง่ายกว่า EIP-4444 ดังนั้นจึงอาจทำหน้าที่เป็นการหยุดชั่วคราวก่อนที่ EIP-4444 จะเข้าสู่การใช้งานจริง

บทสรุป

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

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

ลิงค์เดิม