Monad Lianchuang: หลังจาก Cancun ปัญหาคอขวดของ Rollup คืออะไร
ผู้เขียนต้นฉบับ: Keone Hon ผู้ร่วมก่อตั้ง Monad
เรียบเรียงโดย: Odaily Azuma
หมายเหตุบรรณาธิการ: ในเช้าวันที่ 26 มีนาคม ตามเวลาปักกิ่ง Keone Hon ผู้ร่วมก่อตั้ง Monad ได้ตีพิมพ์บทความเชิงลึกเกี่ยวกับสถานะประสิทธิภาพของ Rollup บน Personal X ในบทความ Keone ให้รายละเอียดเกี่ยวกับวิธีคำนวณขีดจำกัด TPS ตามทฤษฎีของ Rollup หลังจากอัปเกรด Cancun และอธิบายว่าทำไมค่าธรรมเนียมธุรกรรมเดี่ยวของ Layer 2 (ฐาน) บางรายการยังคงสูงถึงหลายดอลลาร์หลังการอัพเกรด นอกจากนี้ Keone ยัง สรุปความท้าทายที่ Rollup เผชิญ ข้อ จำกัด คอขวดบางประการและการปรับปรุงที่อาจเกิดขึ้น
ต่อไปนี้เป็นเนื้อหาต้นฉบับของ Keone ซึ่งรวบรวมโดย Odaily เพื่อความสะดวกของผู้อ่าน ผู้แปลได้เพิ่มข้อความต้นฉบับบางส่วนลงไป
มีการพูดคุยกันในตลาดเมื่อเร็วๆ นี้เกี่ยวกับคอขวดของการดำเนินการ Rollup และข้อจำกัดของ Gas ซึ่งไม่เพียงเกี่ยวข้องกับเลเยอร์ 1 เท่านั้น แต่ยังรวมถึงเลเยอร์ 2 ด้วย ฉันพูดถึงปัญหาคอขวดเหล่านี้ด้านล่าง
ความพร้อมใช้งานของข้อมูล (DA)
ด้วยการเปิดตัวโครงสร้างข้อมูล Blob (EIP-4844) ในการอัปเกรด Cancun ความพร้อมใช้งานของข้อมูล (DA) ของ Ethereum ได้รับการปรับปรุงอย่างมาก ธุรกรรมการซิงโครไนซ์ข้อมูลเลเยอร์ 2 ไม่จำเป็นต้องถูกเรียกเก็บค่าธรรมเนียมเดียวกันกับธุรกรรมเลเยอร์ 1 ทั่วไปอีกต่อไป ประมูลในตลาด.
ปัจจุบัน ความจุของ Blobs อยู่ที่ประมาณ 3 125 kb Blobs ต่อบล็อก (12 วินาที) ซึ่งก็คือ 31.25 kb ต่อวินาที เมื่อพิจารณาว่าขนาดของธุรกรรมอยู่ที่ประมาณ 100 ไบต์ หมายความว่า Rollups ทั้งหมดใช้ TPS ร่วมกันจะอยู่ที่ประมาณ 300
แน่นอนว่ามีข้อมูลบางอย่างที่นี่ที่ต้องมีข้อสังเกตพิเศษ
ประการแรก หาก Rollup ใช้เทคโนโลยีการบีบอัดข้อมูลธุรกรรมที่ดีกว่าเพื่อลดขนาดของธุรกรรมเดียว TPS ก็สามารถเติบโตได้
ประการที่สอง ตามทฤษฎี นอกเหนือจากการใช้ Blob เพื่อซิงโครไนซ์ข้อมูลแล้ว Rollup ยังสามารถใช้ calldata เพื่อซิงโครไนซ์ข้อมูลต่อไปได้ (นั่นคือโซลูชันเก่าก่อนการอัพเกรด Cancun) แม้ว่าการทำเช่นนี้จะนำมาซึ่งความซับซ้อนเพิ่มเติมก็ตาม
ประการที่สาม มีวิธีเผยแพร่สถานะ ZK-rollups ที่แตกต่างกัน (โดยเฉพาะ zkSync Era และ Starknet) ดังนั้นสำหรับ Rollups เหล่านี้ วิธีการคำนวณและผลลัพธ์จะแตกต่างกันด้วย
ขีดจำกัดก๊าซโรลอัพ
เมื่อเร็ว ๆ นี้ Base ได้รับความสนใจอย่างมากเนื่องจากค่าธรรมเนียมก๊าซที่เพิ่มขึ้น ซึ่งเพิ่มขึ้นเป็นไม่กี่ดอลลาร์สำหรับการทำธุรกรรมปกติบนเครือข่าย
เหตุใดเครือข่ายฐานจึงลดระดับลงเพียงช่วงระยะเวลาหนึ่งหลังจากการอัปเกรด Cancun และตอนนี้ได้กลับคืนสู่หรือเกินระดับก่อนการอัปเกรดแล้ว เนื่องจากบล็อกบน Base มีขีดจำกัดก๊าซรวมที่บังคับใช้ผ่านพารามิเตอร์ในโค้ด
พารามิเตอร์ก๊าซที่ใช้ในปัจจุบันโดย Base นั้นเหมือนกับ Optimism นั่นคือมีขีดจำกัดรวม 5 ล้านก๊าซต่อบล็อกเลเยอร์ 2 (2 วินาที) เมื่อความต้องการ (จำนวนธุรกรรมทั้งหมด) บนเครือข่ายเกินอุปทาน ( พื้นที่บล็อก) การชำระราคาจะใช้กลไกการดำเนินการตามความต้องการ ส่งผลให้ก๊าซในเครือข่ายพุ่งสูงขึ้น
เหตุใด Base จึงไม่เพิ่มขีดจำกัดก๊าซทั้งหมดนี้ หรืออีกนัยหนึ่ง เหตุใด Rollup จึงต้องกำหนดขีดจำกัดก๊าซทั้งหมด
นอกจากขีดจำกัดสูงสุดของ TPS เกี่ยวกับความพร้อมใช้งานของข้อมูลที่กล่าวถึงข้างต้นแล้ว ยังมีสาเหตุหลักอีกสองประการ ได้แก่ ปัญหาคอขวดของปริมาณการประมวลผลในการดำเนินการ และอันตรายที่ซ่อนอยู่ของการเติบโตของรัฐ
ปัญหาที่ 1: คอขวดปริมาณการประมวลผลของการดำเนินการ
โดยทั่วไปแล้ว EVM Rollup จะรัน EVM ที่แยกจาก Geth ซึ่งหมายความว่า EVM Rollup มีลักษณะการทำงานที่คล้ายคลึงกับไคลเอนต์ Geth
ไคลเอ็นต์ของ Geth เป็นแบบเธรดเดียว (กล่าวคือ สามารถประมวลผลได้ครั้งละหนึ่งงานเท่านั้น) ใช้การเข้ารหัส LevelDB/PebbleDB และจัดเก็บสถานะไว้ใน Merkle Patricia Trie (MPT) นี่คือฐานข้อมูลอเนกประสงค์ที่ใช้โครงสร้างต้นไม้อื่น (ต้นไม้ LSM) เป็นเลเยอร์พื้นฐานในการจัดเก็บข้อมูลบนโซลิดสเตตไดรฟ์ (SSD)
สำหรับ Rollup การเข้าถึงสถานะ (การอ่านค่าจาก merkle trie) และ การอัปเดตสถานะ (การอัปเดต merkle trie ที่ส่วนท้ายของแต่ละบล็อก) เป็นลิงก์ที่แพงที่สุดในกระบวนการดำเนินการ ที่เป็นเช่นนี้เนื่องจากค่าใช้จ่ายในการอ่านครั้งเดียวจาก SSD คือ 40-100 ไมโครวินาที และเนื่องจากโครงสร้างข้อมูล Merkle Trie ถูกฝังอยู่ในโครงสร้างข้อมูลอื่น (ทรี LSM) จึงต้องใช้การค้นหาเพิ่มเติมที่ไม่จำเป็นจำนวนมาก
ลิงก์นี้สามารถจินตนาการได้ว่าเป็นกระบวนการค้นหาไฟล์เฉพาะในระบบไฟล์ที่ซับซ้อน คุณต้องไปจากไดเร็กทอรีราก (โหนด trie root) ไปจนถึงไฟล์เป้าหมาย (โหนดลีฟ) เมื่อค้นหาแต่ละไฟล์คุณจะต้องค้นหาคีย์เฉพาะในฐานข้อมูล LevelDB และภายใน LevelDB คุณต้องดำเนินการจัดเก็บข้อมูลจริงผ่านโครงสร้างข้อมูลอื่นที่เรียกว่าแผนผัง LSM กระบวนการนี้ทำให้เกิดการค้นหาเพิ่มเติมจำนวนมาก ขั้นตอน ขั้นตอนพิเศษเหล่านี้ทำให้การอ่านและอัปเดตข้อมูลทั้งหมดค่อนข้างช้าและไม่มีประสิทธิภาพ
ในการออกแบบ Monad เราได้แก้ไขปัญหานี้ผ่าน MonadDb MonadDb เป็นฐานข้อมูลแบบกำหนดเองที่รองรับการจัดเก็บ Merkle Trie บนดิสก์โดยตรง โดยหลีกเลี่ยงโอเวอร์เฮดของ LevelDb รองรับ IO แบบอะซิงโครนัส ทำให้สามารถประมวลผลการอ่านหลายรายการพร้อมกัน โดยข้ามระบบไฟล์
นอกจากนี้ กลไก การดำเนินการแบบคู่ขนานในแง่ดี ที่ Monad นำมาใช้ช่วยให้ธุรกรรมหลายรายการสามารถดำเนินการแบบคู่ขนานได้ และสถานะจะถูกแยกออกจาก MonadDb แบบคู่ขนาน
อย่างไรก็ตาม Rollup ไม่มีการเพิ่มประสิทธิภาพเหล่านี้ และดังนั้นจึงมีปัญหาคอขวดในการประมวลผล
ควรสังเกตว่าไคลเอนต์ Eragon/Reth มีการเพิ่มประสิทธิภาพบางอย่างเพื่อประสิทธิภาพของฐานข้อมูล และไคลเอนต์ Rollup บางตัวก็ถูกสร้างขึ้นตามไคลเอนต์เหล่านี้ด้วย (เช่น OP-Reth) Erigon/Reth ใช้โครงสร้างข้อมูลแบบเรียบ ซึ่งลดต้นทุนการสืบค้นเมื่ออ่านได้ในระดับหนึ่ง อย่างไรก็ตาม ไม่รองรับการอ่านแบบอะซิงโครนัสหรือการประมวลผลแบบมัลติเธรด นอกจากนี้ จำเป็นต้องคำนวณราก Merkle ใหม่หลังจากแต่ละบล็อก ซึ่งเป็นกระบวนการที่ค่อนข้างช้าเช่นกัน
คำถามที่ 2: อันตรายที่ซ่อนอยู่ของการเติบโตของรัฐ
เช่นเดียวกับบล็อกเชนอื่นๆ Rollup จะจำกัดปริมาณงานเพื่อป้องกันไม่ให้สถานะใช้งานเติบโตเร็วเกินไป
ข้อโต้แย้งทั่วไปในตลาดคือเหตุผลที่อัตราการเติบโตของรัฐเป็นที่น่ากังวล เนื่องจากหากข้อมูลของรัฐเพิ่มขึ้นอย่างมีนัยสำคัญ ความต้องการอุปกรณ์สำหรับไดรฟ์โซลิดสเทต (SSD) ก็จะต้องเพิ่มขึ้นเช่นกัน อย่างไรก็ตาม ฉันคิดว่านี่ไม่ถูกต้องเล็กน้อย SSD มีราคาค่อนข้างถูก (SSD ขนาด 2 TB คุณภาพสูงมีราคาประมาณ 200 เหรียญสหรัฐ) และสถานะเต็มของ Ethereum มี เท่านั้น อยู่ที่ประมาณ 200 GB ตลอดระยะเวลาเกือบ 10 ปี จากมุมมองของการจัดเก็บข้อมูลเพียงอย่างเดียว ยังมีพื้นที่อีกมากสำหรับการเติบโต
อันตรายที่ซ่อนเร้นใหญ่กว่านั้นคือเมื่อสถานะยังคงเพิ่มขึ้น เวลาในการค้นหาส่วนของสถานะที่ระบุก็จะนานขึ้น ทั้งนี้เนื่องจาก Merkle Patricia Trie ปัจจุบันจะใช้ ทางลัด เมื่อตรงตามเงื่อนไข โหนดมีโหนดย่อยเพียงโหนดเดียว ซึ่งสามารถลดความลึกที่มีประสิทธิภาพของ Trie และด้วยเหตุนี้จึงทำให้กระบวนการสืบค้นเร็วขึ้น อย่างไรก็ตาม หากสถานะ ของ Merkle Trie ยิ่งเต็มมากขึ้นเรื่อยๆ จะมี ทางลัด ให้ใช้งานน้อยลงเรื่อยๆ
โดยสรุป อันตรายที่ซ่อนอยู่ของการเติบโตของรัฐนั้นท้ายที่สุดแล้วเป็นเรื่องของประสิทธิภาพการเข้าถึงของรัฐ ดังนั้น การเร่งการเข้าถึงของรัฐจึงเป็นกุญแจสำคัญในการทำให้การเติบโตของรัฐยั่งยืนมากขึ้น
เหตุใดการเพิ่มประสิทธิภาพฮาร์ดแวร์จึงไม่ทำงาน
เลเยอร์ 2 ยังคงค่อนข้างรวมศูนย์ กล่าวคือ เครือข่ายยังคงอาศัยซีเควนเซอร์ตัวเดียวเพื่อรักษาสถานะและสร้างบล็อก อาจมีคนถามว่าทำไมไม่รันตัวเรียงลำดับบนฮาร์ดแวร์ที่มี RAM สูงมาก (หน่วยความจำเข้าถึงโดยสุ่ม) เพื่อให้สามารถจัดเก็บสถานะทั้งหมดไว้ในหน่วยความจำได้
มีสองเหตุผลสำหรับเรื่องนี้
ประการแรก สิ่งนี้จะไม่แก้ปัญหาคอขวดด้านความพร้อมใช้งานของข้อมูลของเครือข่ายหลัก Ethereum แม้ว่าจะขึ้นอยู่กับสถานการณ์ปัจจุบันของ Base การเพิ่มขึ้นอย่างรวดเร็วของก๊าซในเครือข่ายไม่ได้เกิดจากความสามารถด้านความพร้อมใช้งานของข้อมูลไม่เพียงพอของเครือข่ายหลัก สิ่งนี้จะกลายเป็นปัญหาคอขวดสำคัญที่จำกัด Rollup ในที่สุด
ประการที่สองคือประเด็นของการกระจายอำนาจ แม้ว่าซีเควนเซอร์จะยังคงรวมศูนย์สูง แต่บทบาทอื่น ๆ ที่เกี่ยวข้องกับการดำเนินงานเครือข่ายก็มีความสำคัญเช่นกัน พวกเขายังต้องสามารถรันโหนดได้อย่างอิสระ เล่นซ้ำประวัติการทำธุรกรรมเดียวกัน และรักษาสถานะเดียวกัน
ข้อมูลการทำธุรกรรมดิบและสถานะที่กระทำเหนือเลเยอร์ 1 นั้นไม่เพียงพอที่จะปลดล็อคสถานะที่สมบูรณ์ บทบาทใดๆ ที่ต้องการเข้าถึงสถานะที่สมบูรณ์ (เช่น ผู้ค้า การแลกเปลี่ยน หรือผู้ค้าอัตโนมัติ) ควรใช้งานโหนดเลเยอร์ 2 เต็มรูปแบบเพื่อประมวลผลธุรกรรมและมีสำเนาของสถานะที่เป็นปัจจุบัน
Rollups ยังคงเป็น blockchains และ blockchains ก็น่าสนใจเนื่องจากความสามารถในการบรรลุการประสานงานระดับโลกผ่านสถานะระดับโลกที่ใช้ร่วมกัน สำหรับบล็อกเชนทั้งหมด จำเป็นต้องมีซอฟต์แวร์ที่มีประสิทธิภาพ และการเพิ่มประสิทธิภาพฮาร์ดแวร์เพียงอย่างเดียวไม่เพียงพอที่จะแก้ปัญหาได้
ปฏิสัมพันธ์ของชุมชน
หลังจากที่ Keone โพสต์บทความนี้ บุคลากรสำคัญของหัวหน้าโครงการ Layer 2 หลายโครงการก็โต้ตอบกันด้านล่างโพสต์
Alex Gluchowski ผู้ร่วมก่อตั้ง zkSync ถาม Monad ว่ามันแตกต่างกันอย่างไรในเรื่องนี้เกี่ยวกับเนื้อหาในบทความที่ว่า ต้องคำนวณราก Merkle ใหม่หลังจากแต่ละบล็อก
คำตอบของ Keone คือว่าจะมีอัลกอริธึมที่ได้รับการปรับปรุงให้เหมาะสมสำหรับการคำนวณราก Merkle หลังจากแต่ละบล็อก
Jesse Pollak บุคคลที่รับผิดชอบ Base ยังใช้สิ่งนี้เพื่ออธิบายว่าทำไมต้นทุนก๊าซของ Base จึงเพิ่มขึ้นแทนที่จะลดลงหลังจากการอัพเกรดใน Cancun เขากล่าวว่า EIP-4844 ได้ลดต้นทุน DA ที่ระดับ Layer 1 ลงอย่างมาก แต่เนื่องจากความต้องการในการทำธุรกรรมบนเครือข่ายเพิ่มขึ้นมากกว่าห้าเท่า และบล็อกบนเครือข่ายฐานมีขีดจำกัดที่ 250 Gas/s อุปสงค์มากกว่าอุปทาน ทำให้ค่าธรรมเนียมก๊าซเพิ่มขึ้น
