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

บทความต้นฉบับโดย Storm Slivkoff และ Georgios Konstantopoulos

ต้นฉบับแปล: ลูฟี่, Foresight News

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

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

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

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

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

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

การเติบโตในอดีตคืออะไร?

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

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

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

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

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

การเติบโตในอดีตรวดเร็วแค่ไหน?

รูปที่ 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 ประสบกับอัตราการเติบโตที่ลดลงอย่างมากในอดีต

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การเติบโตในประวัติศาสตร์เป็นปัญหาที่แก้ไขได้ง่ายกว่าการเติบโตของรัฐ ข้อเสนอของผู้สมัคร EIP-4444 สามารถแก้ไขได้เกือบทั้งหมด EIP นี้จะเปลี่ยนแต่ละโหนดจากการบันทึกประวัติ Ethereum ทั้งหมดไปเป็นการบันทึกประวัติเพียงหนึ่งปีเท่านั้น หลังจากใช้ EIP-4444 พื้นที่จัดเก็บข้อมูลจะไม่เป็นคอขวดสำหรับการขยาย Ethereums อีกต่อไป และการเพิ่มขีดจำกัดของก๊าซจะไม่เป็นข้อจำกัดในระยะยาวอีกต่อไป 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 สามารถจัดทำแพ็กเกจประวัติบางส่วนเป็นระยะๆ และแชร์เป็นไฟล์ทอร์เรนต์สาธารณะได้ ตัวอย่างเช่น โหนดอาจสร้างไฟล์ torrent ประวัติใหม่ทุกๆ 100,000 บล็อก ไคลเอนต์โหนดเช่น Eragon ดำเนินการกระบวนการนี้ในลักษณะที่ไม่ได้มาตรฐานอยู่แล้ว เพื่อสร้างมาตรฐานให้กับกระบวนการนี้ ไคลเอ็นต์โหนดทั้งหมดต้องใช้รูปแบบข้อมูลเดียวกัน พารามิเตอร์เดียวกัน และเครือข่าย P2P เดียวกัน โหนดจะสามารถเลือกได้ว่าจะเข้าร่วมในเครือข่ายนี้หรือไม่ โดยพิจารณาจากความสามารถในการจัดเก็บข้อมูลและแบนด์วิธ ทอร์เรนต์มีข้อได้เปรียบในการใช้มาตรฐานเปิดที่มีลินดี้ซึ่งได้รับการสนับสนุนโดยเครื่องมือข้อมูลจำนวนมากอยู่แล้ว

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

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

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

L2 สามารถใช้วิธีเก็บรักษาประวัติทั้งหมดนี้เพื่อรักษาข้อมูล Blob ที่เผยแพร่ไปยัง Mainnet ได้ เมื่อเปรียบเทียบกับการเก็บรักษาประวัติ การเก็บรักษา Blob นั้น 1) ยากกว่า เนื่องจากจำนวนข้อมูลทั้งหมดมีขนาดใหญ่กว่ามาก 2) มีความสำคัญน้อยกว่า เนื่องจาก blobs ไม่จำเป็นสำหรับการเล่นซ้ำประวัติ 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: ปรับราคาข้อมูลการโทร ทำให้ธุรกรรมบางอย่างที่มีข้อมูลการโทรมากเกินไปมีราคาแพงกว่า การทำให้รูปแบบการใช้งานเหล่านี้มีราคาแพงขึ้นจะบังคับให้บางส่วนเปลี่ยนจากข้อมูลการโทรไปเป็น blobs ซึ่งจะช่วยลดอัตราการเติบโตในอดีต

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

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

บทสรุป

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

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

ลิงค์เดิม

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

ที่เกี่ยวข้อง: นักขุด Bitcoin ดิ้นรนเพื่อรักษาการดำเนินงานก่อนการลดจำนวนลงครึ่งหนึ่ง

โดยสรุป การลดรางวัลการขุด Bitcoin ลงครึ่งหนึ่งในปีนี้เหลือ 3.125 BTC ซึ่งท้าทายความสามารถในการทำกำไรของนักขุด CryptoQuant รายงานว่าราคาแฮชของนักขุดลดลง 30% นับตั้งแต่การลดครึ่งหนึ่งครั้งล่าสุด และคาดว่าจะลดลงอีก การแข่งขันและต้นทุนสูงขึ้น โดยแฮชเรตของเครือข่าย Bitcoin สูงถึง 600 EH/s ส่งผลกระทบต่อรายได้ ในอีกประมาณ 10 วัน ชุมชน Bitcoin จะได้เห็นเหตุการณ์สำคัญ เช่น Bitcoin halving ปรากฏการณ์นี้จะลดรางวัลการขุดบล็อก Bitcoin ลงครึ่งหนึ่งจาก 6.25 เหลือ 3.125 Bitcoins ซึ่งสร้างแรงกดดันต่อความสามารถในการทำกำไรของนักขุด ขณะนี้นักขุดกำลังแข่งกับเวลา โดยต้องใช้ราคา Bitcoin ที่สูงขึ้นเพื่อรักษารายได้ไว้ เหตุใดนักขุด Bitcoin จะเผชิญกับความท้าทาย ตามรายงานของ CryptoQuant ที่แชร์กับ BeInCrypto ราคาแฮชของนักขุดได้ลดลง 30% นับตั้งแต่การลดครึ่งหนึ่งครั้งล่าสุดในเดือนพฤษภาคม 2020 ปัจจุบันมีมูลค่าที่ $0.11 ต่อเทราแฮชต่อวินาที สิ่งนี้...