เราเริ่มสร้าง Reth ในปี 2022 เพื่อให้ความทนทานกับ Ethereum L1 และแก้ปัญหาการขยายมาตราการดำเนินการบน Layer 2

วันนี้เรามีความตื่นเต้นที่จะแบ่งปันเส้นทางของ Reth ไปสู่ 1 กิกก๊าสต่อวินาทีใน L2 ในปี 2024 และแผนระยะยาวของเราสำหรับการก้าวข้ามไปข้างหน้าจากนั้น

เราขอเชิญร่วมมือกับนิเวศวิกข์ในการขับเคลื่อนขอบเขตของประสิทธิภาพและการทดสอบอย่างเข้มงวดในโลกของสกุลเงินดิจิตอล

เราสเกลแล้วหรือยัง?

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

คุณวัดประสิทธิภาพอย่างไร? แก๊สต่อวินาทีหมายถึงอะไร?

ประสิทธิภาพมักจะถูกวัดโดยการตัวชี้วัด "ธุรกรรมต่อวินาที" (TPS) โดยเฉพาะอย่างยิ่งสำหรับ Ethereum และบล็อกเชน EVM อื่น ๆ การวัดที่อาจถูกต้องและละเอียดมากกว่าคือ "แก๊สต่อวินาที" ตัวชี้วัดนี้สะท้อนถึงปริมาณงานทางคณิตศาสตร์ที่เครือข่ายสามารถจัดการได้ในทุก ๆ วินาที โดยที่ "แก๊ส" เป็นหน่วยที่ใช้วัดความพยายามทางคณิตศาสตร์ที่จำเป็นในการดำเนินการ เช่น ธุรกรรมหรือสมาร์ทคอนแทรค

การมาตราฐานรอบ ๆ แก๊สต่อวินาทีเป็นตัวชี้วัดประสิทธิภาพที่ชัดเจนทำให้เข้าใจความสามารถและประสิทธิภาพของบล็อกเชนได้ดียิ่งขึ้น นอกจากนี้ยังช่วยในการประเมินผลกระทบต่อระบบราคา ป้องกันไม่ให้เกิดการโจมตีบริการ (DOS) ที่อาจใช้อัตราการวัดที่น้อยลงอย่างมีความละเอียดน้อย ตัวชี้วัดนี้ช่วยในการเปรียบเทียบประสิทธิภาพข้ามเครือข่าย Ethereum Virtual Machine (EVM) ที่เข้ากันได้

เราขอเสนอให้ชุมชน EVM ยอมรับแก๊สต่อวินาทีเป็นเมตริกมาตรฐานพร้อมกับการรวมเข้ามิติอื่น ๆ ของการกำหนดราคาแก๊สสร้างเกณฑ์ประสิทธิภาพรวม

วันนี้เราอยู่ที่ไหน

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

เราเน้นที่จะใช้แก๊สต่อวินาทีในการประเมินประสิทธิภาพของเครือข่าย EVM อย่างละเอียด โดยจับต้นทุนการคำนวณและการจัดเก็บข้อมูลทั้งสองอย่าง ระบบเครือข่ายเช่น Solana, Sui หรือ Aptos ไม่ได้รวมอยู่เนื่องจากรูปแบบต้นทุนที่แตกต่างกัน เรายืนยันการพยายามในการปรับปรุงรูปแบบต้นทุนให้สอดคล้องกันในเครือข่ายบล็อกเชนทั้งหมดเพื่อเปิดโอกาสให้มีการเปรียบเทียบอย่างครอบคลุมและเป็นธรรม

เรากำลังทำชุดการทดสอบเชิงพิสูจน์สำหรับ Reth ที่ทำการคัดลอกโหลดงานจริงอย่างต่อเนื่อง หากคุณต้องการร่วมมือกับเราในเรื่องนี้ โปรดติดต่อเรา พวกเราต้องการTPC Benchmarkสำหรับโหนด

Reth จะได้อยู่ที่ 1 กิกก๊าสต่อวินาทีได้อย่างไร? และเกินจากนั้นอีกไหม?

เราได้รับแรงบันดาลใจบางส่วนในการสร้าง Reth ในปี 2022 จากความต้องการเร่งด่วนในการมีไคลเอนต์ที่ออกแบบมาเพื่อการจัดกลุ่มขนาดใหญ่บนเว็บ เราคิดว่าเรามีทางเลือกที่มีความเชื่อมั่นสูง

Reth ได้ทำให้ 100-200mgas/s ในระหว่างการซิงโครไลฟ์ (รวมถึงการกู้คืนผู้ส่ง, ดำเนินการธุรกรรม, และคำนวณต้นไม้ในทุก ๆ บล็อก); 10 เท่าจากที่นี่จะทำให้เราไปสู่เป้าหมายระยะสั้นของเราที่ 1 กิกะแก๊ส/s

เมื่อเราก้าวหน้าการพัฒนา Reth ของเรา แผนการขยายของเราจะต้องสมดุลระหว่างความสามารถในการขยายและความหลากหลาย

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

การปรับปรุงที่เรากำลังสำรวจที่นี่ไม่ได้เกี่ยวข้องกับการแก้ปัญหาการเจริญเติบโต, ซึ่งเรากำลังศึกษาอย่างแยกต่างหาก

นี่คือสรุปของวิธีที่เราตั้งใจจะไปถึงที่นั่น:

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

แผนถนนเส้นตายของ Reth

เป้าหมายของเราที่นี่คือเพิ่มประสิทธิภาพและประสิทธิภาพของเซิร์ฟเวอร์เดียวหรือแล็ปท็อปที่กำลังทำงานบน Reth

EVM Just-In-Time & Ahead-of-Time

ในสภาพแวดล้อมบล็อกเชน เช่น Ethereum Virtual Machine (EVM) การดำเนินการ bytecode เกิดขึ้นผ่านตัวแปลภาษาที่ประมวลผลคำสั่งตามลำดับ วิธีการนี้ทำให้เกิดภาระขึ้น เนื่องจากมันไม่ได้ดำเนินการคำสั่งเชิงสร้างสรรค์โดยตรง แต่ทำงานผ่านชั้นบรรทัด VM

Just-In-Time (JIT) compilation แสดงถึงการแปลง bytecode เป็น native machine code ทันทีก่อนการดำเนินการ ซึ่งช่วยปรับปรุงประสิทธิภาพโดยการข้ามกระบวนการตีความของ VM เทคนิคนี้ ซึ่งคอมไพล์สัญญาเป็น machine code ที่ถูกปรับปรุงล่วงหน้า ได้รับการยอมรับอย่างกว้างขวางใน VM อื่น ๆ เช่น Java และ WebAssembly

อย่างไรก็ตาม การใช้ JIT อาจเป็นอ่อนแอต่อโค้ดที่ออกแบบมาเพื่อใช้ประโยชน์จากกระบวนการ JIT หรืออาจจะช้าเกินไปที่จะเรียกใช้งานขณะรัน Reth จะ Ahead-of-Time (AOT) คอมไพล์สัญญาที่มีความต้องการสูงสุดและเก็บไว้บนดิสก์เพื่อป้องกัน bytecode ที่ไม่น่าเชื่อถือพยายามใช้ประโยชน์จากขั้นตอนคอมไพล์โค้ดเชิงธรรมชาติของเราขณะรัน

เราได้ทำการเป็นคอมไพล์เลอร์ JIT/AOT สำหรับ Revm ซึ่งกำลังถูกนำมารวมกับ Reth อยู่ในขณะนี้ เราจะเปิดเผยโค้ดนี้ในสัปดาห์หน้าเมื่อการทดสอบแล้วเสร็จ เกือบ 50% ของเวลาการดำเนินการถูกใช้ไปในตัวตีคำสั่ง EVM เฉลี่ย ดังนั้นนี่ควรจะช่วยให้การดำเนินการ EVM ดีขึ้นประมาณ ~2 เท่า อย่างไรก็ตามในบางกรณีที่มีการใช้ทรัพยากรมากมายมากขึ้นอาจจะมีผลกระทบมากขึ้นแม้ว่าจะใช้เวลามากขึ้น เราจะแบ่งปันข้อมูลเปรียบเทียบและการรวมรหัสของเราด้วย JIT EVM เป็นของ Reth ในสัปดาห์หน้า

Parallel EVM

แนวคิดของเครื่องจำลอง Ethereum Virtual Machine (Parallel EVM) ทำให้การประมวลผลธุรกรรมเกิดขึ้นพร้อมกัน แตกต่างจากโมเดลการประมวลผลแบบซีเรียลทางด้าน EVM ที่เป็นแบบดั้งเดิม เรามีทางเลือกอัน 2 ข้างหน้าที่นี่:

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

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

การปรับปรุงความมุ่งมั่นของรัฐ

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

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

เราระบุ 2 "ชนะง่าย" ต่อไปนี้ซึ่งสามารถให้เรา 2-3x ในประสิทธิภาพรากของรัฐโดยไม่มีการเปลี่ยนแปลงโปรโตคอลใด ๆ :

1. Fully Parallelized State Root: ขณะนี้เราเพียงทำการคำนวณ storage trie สำหรับบัญชีที่เปลี่ยนแปลงในโหมดขนานเท่านั้น แต่เราสามารถเดินไปไกลกว่านั้นและคำนวณ accounts trie ในโหมดขนานพร้อมกันที่ storage root jobs สามารถทำงานเสร็จในพื้นหลัง
2. รากสถานะท่อ: ดึงข้อมูลโหนดตัวกลางจากดิสก์ขณะดำเนินการโดยแจ้งบริการรากสถานะเกี่ยวกับช่องจัดเก็บและบัญชีที่ถูกสัมผัส

เราเห็นว่ามีทางมากหลายทางที่เราสามารถเลือกเดินไปในทิศทางที่แตกต่างจากพฤติกรรมของรากสถานะ Ethereum L1

1. รากสถานะที่น้อยลง: ไม่ใช่การคำนวณรากสถานะทุกบล็อก แต่คำนวณทุก T บล็อก สิ่งนี้จะช่วยลด % ของเวลาที่ใช้กับรากสถานะโดยรวมในระบบทั้งหมดและอาจเป็นวิธีที่ง่ายและมีประสิทธิภาพที่สุด
2. รากสถานะหลังการเลี้ยง: แทนที่จะต้องคำนวณรากสถานะในบล็อกเดียวกัน ให้มันล้าหลังบล็อกหลายๆ บล็อก สิ่งนี้ช่วยให้การดำเนินการไปข้างหน้าได้โดยไม่ต้องบล็อกในการคำนวณรากสถานะ
3. Replace the RLP Encoder & Keccak256: แทนที่จะเข้ารหัสด้วย RLP อาจจะถูกกว่าที่จะแค่ต่อเชื่อม byte และใช้ฟังก์ชันการแฮชที่เร็วขึ้นเช่น Blake3
4. Wider Trie: เพิ่ม N-arity ของต้นไม้เพื่อลดการขยายของ IO ที่เกิดจากความลึกของต้นไม้ logN

มีคำถามอยู่บางประการที่นี่

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

แผนการขยายของ Reth ในแนวราบ

เราจะดําเนินการตามหลายประเด็นข้างต้นตลอดปี 2024 และบรรลุเป้าหมายที่ 1gigagas/sec

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

Multi-Rollup Reth

วันนี้ L2 stacks ต้องการให้ทำการเรียกใช้บริการหลายรายการเพื่อตามรอยโซ่: L1 CL, L1 EL, ฟังก์ชัน L1 -> L2 derivation (ซึ่งอาจจะถูกบรรจุไว้กับ L2 EL), และ L2 EL ขณะที่ดีสำหรับการแยกแยะ สิ่งนี้กลายเป็นซับซ้อนเมื่อมีการเรียกใช้ stack โหนดหลายรายการ จินตนาการว่าต้องเรียกใช้ rollups 100 รายการ!

เราต้องการอนุญาตให้การเปิด rollups ในกระบวนการเดียวกันกับ Reth และลดต้นทุนการดำเนินงานของการเรียกใช้ rollups พันรายไปสู่ศูนย์เกือบ

เราได้เริ่มดำเนินการแล้วกับนี้ด้วย โครงการส่วนขยายการดำเนินการ ([1], [2]) มากขึ้นในสัปดาห์หน้าที่นี่

Reth โดย Cloud-native

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

เราต้องการอนุญาตให้เรท์โหนด Cloud-native ที่ทำงานเป็นบริการสแต็กที่สามารถปรับสเกลอัตโนมัติตามความต้องการของคอมพิวเตอร์และใช้พื้นที่จัดเก็บวัตถุในคลาวด์ที่ดูเหมือนไม่มีที่สิ้นสุดสำหรับความต่อเนื่อง นี่คือโครงสถาปัตยกรรมที่พบได้บ่อยในโครงการฐานข้อมูลแบบเซิร์ฟเวอร์เลส เช่น NeonDB, CockroachDB หรือ Amazon Aurora

ดูความคิดแรกจากทีมของเราเกี่ยวกับวิธีบางวิธีที่เราสามารถทำต่อปัญหานี้

ที่มุมมอง

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

ยังมีคำถามบางอย่างที่เรายังไม่มีคำตอบ

• Reth จะช่วยเพิ่มประสิทธิภาพข้ามระบบ L2 ได้อย่างไร
• เราจะวัดสถานการณ์ที่เลวร้ายที่สุดอย่างไรให้เหมาะสม เมื่อบางส่วนของการปรับปรุงของเราอาจเป็นสำหรับกรณีเฉลี่ย
• เราจะจัดการกับความตึงเครียดระหว่าง L1 และ L2 ที่อาจจะเป็นไปในทิศทางตรงข้ามได้อย่างไร

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

คำปฏิเสธ：

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