TLDR: บทความวิจัยนี้ให้ภาพรวมของสถาปัตยกรรมการออกแบบขนาดขนาดขนาดสำหรับบล็อกเชนโดยใช้ตัวอย่างที่สำคัญสามตัว ได้แก่ Solana, Sei และ Monad โดยเน้นที่ความแตกต่างระหว่างการจัดเรียงแบบ optimistic และ deterministic และสำรวจรายละเอียดของการเข้าถึงสถานะและหน่วยความจำในเครือข่ายเหล่านี้
ในปี 1837 นักวิทยาการคอมพิวเตอร์และนักคณิตศาสตร์ชาร์ลส์ บาบเบจออกแบบ " เครื่องวิเคราะห์,” which laid the theoretical foundation for parallel computation. Today, parallelization is a pivotal theme within the crypto world as blockchains attempt to push the boundaries of processing, efficiency, and throughput.
จักรวาลขนาน
คำนวณขนาดใหญ่แบบขนาน ช่วยให้สามารถดำเนินการหลายการคำนวณหรือกระบวนการพร้อมกัน ในขณะที่การคำนวณทำงานแบบตรงต่อเนื่องหรือตามลำดับต่อเนื่อง การคำนวณขนานหมายถึงการแบ่งปัญหาขนาดใหญ่เป็นส่วนย่อยที่อิสระจากกัน ซึ่งสามารถดำเนินการโดยหลายโปรเซสเซอร์พูดคุยผ่านหน่วยความจำร่วมกัน ระบบขนานมีข้อดีหลายประการ เช่น ประสิทธิภาพและความเร็วเพิ่มขึ้น การปรับขนาด ความเชื่อถือไว้วางใจและความทนทานต่อข้อผิดพลาด การใช้ทรัพยากรได้ดีขึ้น และความสามารถในการจัดการชุดข้อมูลขนาดใหญ่มาก
อย่างไรก็ตามสิ่งสําคัญคือต้องตระหนักว่าประสิทธิภาพของการขนานขึ้นอยู่กับลักษณะเฉพาะของสถาปัตยกรรมพื้นฐานและการใช้งาน ปัญหาคอขวดหลักสองประการของบล็อกเชนคือฟังก์ชันการเข้ารหัส (ฟังก์ชันแฮช ลายเซ็น เส้นโค้งรูปไข่ ฯลฯ) และการเข้าถึงหน่วยความจํา/สถานะ ด้วยบล็อกเชน หนึ่งในองค์ประกอบสําคัญของการออกแบบระบบขนานที่มีประสิทธิภาพอยู่ที่ความแตกต่างของการเข้าถึงสถานะ การเข้าถึงของรัฐหมายถึงความสามารถของธุรกรรมในการอ่านและเขียนไปยังสถานะของบล็อกเชน รวมถึงการจัดเก็บ สัญญาอัจฉริยะ และยอดคงเหลือในบัญชี เพื่อให้บล็อกเชนแบบขนานมีประสิทธิภาพและมีประสิทธิภาพการเข้าถึงของรัฐจะต้องได้รับการปรับให้เหมาะสม
ในปัจจุบันมีสองโรงเรียนความคิดในการปรับปรุงการเข้าถึงสถานะสำหรับบล็อกเชนที่มีการประมวลผลแบบขนาน: การขนานแบบกำหนด vs. การขนานแบบโดยสมัครใจ การขนานแบบกำหนดต้องการให้โค้ดระบุล่วงหน้าว่าส่วนใดของสถานะบล็อกเชนจะถูกเข้าถึงและแก้ไข นี่ช่วยให้ระบบสามารถกำหนดได้ว่าธุรกรรมไหนสามารถประมวลผลได้แบบขนานโดยไม่มีความขัดแย้งล่วงหน้า การขนานแบบกำหนดช่วยให้สามารถทำนายและมีประสิทธิภาพ (โดยเฉพาะเมื่อธุรกรรมเป็นอิสระส่วนใหญ่) อย่างไรก็ตาม มันก็สร้างความซับซ้อนมากขึ้นสำหรับนักพัฒนา
การขนานในแง่ดีไม่จําเป็นต้องมีรหัสเพื่อประกาศการเข้าถึงของรัฐล่วงหน้าและประมวลผลธุรกรรมควบคู่กันราวกับว่าจะไม่มีความขัดแย้ง หากมีข้อขัดแย้งเกิดขึ้นการขนานในแง่ดีจะเรียกใช้ใหม่ประมวลผลใหม่หรือเรียกใช้ธุรกรรมที่ขัดแย้งกันอย่างต่อเนื่อง ในขณะที่การขนานในแง่ดีช่วยให้นักพัฒนามีความยืดหยุ่นมากขึ้น แต่จําเป็นต้องมีการดําเนินการซ้ําสําหรับความขัดแย้งส่งผลให้วิธีนี้มีประสิทธิภาพสูงสุดเมื่อธุรกรรมไม่ขัดแย้งกัน ไม่มีคําตอบที่ถูกต้องว่าแนวทางใดดีกว่ากัน พวกเขาเป็นเพียงสองวิธีที่แตกต่างกัน (และทํางานได้) เพื่อขนาน
ในส่วนที่ 1 ของซีรีส์นี้ เราจะสำรวจพื้นฐานบางอย่างของระบบขนาดขนาดไม่ใช่คริปโต ตามด้วยพื้นที่การออกแบบสำหรับการดำเนินการขนาดขนาดสำหรับบล็อกเชน โดยเน้นที่สามพื้นที่หลัก:
การรับรู้ว่าสิ่งที่เราได้อ่านเพิ่มเติมเกี่ยวกับสิ่งที่การคำนวณแบบขนานทำให้เป็นไปได้และข้อดีของระบบขนาน จะเข้าใจได้ง่ายว่าทำไมการนำการคำนวณแบบขนานได้เป็นอย่างมากในปีก่อนหน้านี้ การนำการคำนวณแบบขนานมากขึ้นได้เปิดทางให้การพัฒนาขึ้นมาของหลายสิ่งที่สำคัญในเพียงไม่กี่ทศวรรษที่ผ่านมาเท่านั้น
เรามาสำรวจบล็อกเชนสามระบบที่ได้นำระบบการทำงานขนาดขนาดขนาดขนาดขนาดขนาดของขนาดของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของขลงลง Solana พอดี ตามด้วย Monad และ Sei
ในระดับสูง ศาลานา มีหลักการออกแบบที่ว่านวัตกรรมบล็อกเชนควรพัฒนาต่อไปพร้อมกับความก้าวหน้าของฮาร์ดแวร์ โดยที่เฮาร์ดแวร์ดีขึ้นตามเวลาผ่านทฤษฎีของมูอร์ ศาลานาถูกออกแบบให้ได้รับประโยชน์จากประสิทธิภาพและความยืดหยุ่นที่เพิ่มขึ้นAnatoly Yakovenkoออกแบบเริ่มแรกโครงสร้างการขนานของ Solanaมากกว่าห้าปีที่แล้ว และในปัจจุบัน การใช้พริ้นซิพแบบขนานเป็นหลักการออกแบบบล็อกเชนกำลังแพร่กระจายอย่างรวดเร็ว
Solana ใช้การขนานกันที่กำหนดไว้ล่วงหน้า ซึ่งมาจากประสบการณ์ในอดีตของ Anatoly ในการทำงานกับระบบฝังตัว ที่นักพัฒนาโดยทั่วไปจะประกาศสถานะทั้งหมดล่วงหน้า สิ่งนี้ทำให้ CPU ทราบเสมอเกี่ยวกับความขึ้นต่อกัน ซึ่งทำให้มันสามารถดึงข้อมูลที่จำเป็นล่วงหน้า ผลลัพธ์คือการดำเนินการของระบบที่ถูกจัดเรียงอย่างเหมาะสม แต่อีกครั้งก็ต้องการนักพัฒนาทำงานเสริมเพิ่มล่วงหน้า ใน Solana ความขึ้นต่อกันของหน่วยความจำสำหรับโปรแกรมทุกๆ ชุดมีความจำเป็นและระบุไว้ในธุรกรรมที่สร้างขึ้น (เช่น รายการเข้าถึง) ซึ่งทำให้เวลารันไทม์สามารถกำหนดการและดำเนินการธุรกรรมหลายๆ รายการขนานกันได้อย่างมีประสิทธิภาพ
องค์ประกอบหลักต่อไปของสถาปัตยกรรมของ Solana คือ Sealevel VM ซึ่งเป็นรันไทม์สัญญาอัจฉริยะแบบขนานของ Solana Sealevel รองรับการประมวลผลสัญญาและธุรกรรมหลายรายการแบบขนานตามจํานวนคอร์ที่ผู้ตรวจสอบมี ผู้ตรวจสอบความถูกต้องในบล็อกเชนคือผู้เข้าร่วมเครือข่ายที่รับผิดชอบในการตรวจสอบและตรวจสอบความถูกต้องของธุรกรรมเสนอบล็อกใหม่และรักษาความสมบูรณ์และความปลอดภัยของบล็อกเชน เนื่องจากธุรกรรมประกาศว่าบัญชีใดที่ต้องอ่านและเขียนถูกล็อคล่วงหน้าตัวกําหนดตารางเวลา Solana จึงสามารถกําหนดธุรกรรมที่สามารถดําเนินการพร้อมกันได้ ด้วยเหตุนี้เมื่อพูดถึงการตรวจสอบความถูกต้อง" Block Producer " หรือ Leader จึงสามารถจัดเรียงธุรกรรมที่รอดําเนินการหลายพันรายการและกําหนดเวลาธุรกรรมที่ไม่ทับซ้อนกันในแบบคู่ขนาน
องค์ประกอบการออกแบบสุดท้ายสำหรับ Solana คือ "การทำท่อ" การทำท่อเกิดขึ้นเมื่อต้องประมวลผลข้อมูลในลำดับของขั้นตอน และฮาร์ดแวร์ที่แตกต่างกันรับผิดชอบในแต่ละขั้นตอน ความคิดสำคัญที่นี่คือการเอาข้อมูลที่ต้องเรียกทำงานในลำดับและทำให้มันขนานใช้การทำท่อ ท่อเหล่านี้สามารถทำงานขนานกันและแต่ละขั้นตอนของท่อสามารถประมวลผลชุดธุรกรรมที่แตกต่างกัน
การปรับปรุงเหล่านี้ช่วยให้ Sealevel สามารถจัดการและดำเนินธุรกรรมที่เป็นอิสระพร้อมกัน โดยใช้ความสามารถของฮาร์ดแวร์ในการประมวลผลจำนวนข้อมูลหลายๆ จุดพร้อมกันด้วยโปรแกรมเดียว Sealevel เรียงคำสั่งตาม programID และดำเนินคำสั่งเดียวกันบนบัญชีที่เกี่ยวข้องทั้งหมดพร้อมกัน
ด้วยนวัตกรรมเหล่านี้ในใจ, เราสามารถเห็นได้ว่า Solana ถูกออกแบบโดยตั้งใจเพื่อสนับสนุนการประมวลผลแบบขนาน
Sei เป็นบล็อกเชนชั้นที่ 1 แบบโปรแกรมสากลและโอเพ่นซอร์สที่พิเศษสำหรับการแลกเปลี่ยนสินทรัพย์ดิจิทัล เซอี V2 ใช้การขยายตัวแบบโดยเลขหมุนและด้วยเหตุนี้จึงเป็นมิตรต่อนักพัฒนามากกว่าคู่แข่งที่กำหนดไว้ล่วงหน้า ในการขยายตัวแบบโดยเลขหมุนนี้ สมาร์ทคอนแทร็กสามารถทำงานอย่างไม่ต่อเนื่องและพร้อมกันมากขึ้นโดยที่ไม่ต้องการให้นักพัฒนาประกาศทรัพยากรล่วงหน้า ซึ่งหมายความว่าโซ่ทำงานอย่างโดดเดี่ยวอย่างเต็มที่ทุกธุรกรรม แต่เมื่อเกิดความขัดแย้ง (เช่น มีหลายธุรกรรมเข้าถึงสถานะเดียวกัน) บล็อกเชนจะติดตามส่วนคอมโพเนนต์ที่เฉพาะเจาะจงที่แต่ละธุรกรรมที่ขัดแย้งมีผลต่อ
บล็อกเชนของ Sei ใช้วิธีการดำเนินการธุรกรรมโดยใช้ “Optimistic Concurrency Control (OCC)” การประมวลผลธุรกรรมที่เกิดขึ้นพร้อมกันเมื่อมีธุรกรรมหลายรายการที่มีอยู่พร้อมกันในระบบ มีขั้นตอนสองขั้นตอนในวิธีการดำเนินการธุรกรรมนี้ คือ การดำเนินการและการตรวจสอบ
ในขั้นตอนการดําเนินการธุรกรรมจะได้รับการประมวลผลในแง่ดีโดยการอ่าน / เขียนทั้งหมดจะถูกจัดเก็บไว้ชั่วคราวในร้านค้าเฉพาะธุรกรรม หลังจากนี้ทุกธุรกรรมจะเข้าสู่ขั้นตอนการตรวจสอบความถูกต้องซึ่งข้อมูลในการดําเนินการจัดเก็บชั่วคราวจะถูกตรวจสอบกับการเปลี่ยนแปลงสถานะใด ๆ ที่ทําโดยธุรกรรมก่อนหน้า หากธุรกรรมเป็นอิสระธุรกรรมจะทํางานควบคู่กัน หากธุรกรรมอ่านข้อมูลที่แก้ไขโดยธุรกรรมอื่นสิ่งนี้จะสร้างความขัดแย้ง ระบบคู่ขนานของ SEI จะระบุข้อขัดแย้งแต่ละข้อโดยการเปรียบเทียบชุดการอ่านธุรกรรมกับการเปลี่ยนแปลงสถานะล่าสุดในร้านค้าหลายเวอร์ชัน (จัดทําดัชนีตามลําดับธุรกรรม) Sei จะดําเนินการและตรวจสอบกรณีที่มีความขัดแย้งเกิดขึ้นอีกครั้ง นี่เป็นกระบวนการทําซ้ําที่เกี่ยวข้องกับการดําเนินการการตรวจสอบความถูกต้องและการทํางานซ้ําเพื่อแก้ไขข้อขัดแย้ง กราฟิกด้านล่างแสดงให้เห็นถึงแนวทางการทําธุรกรรมของ Sei เมื่อเกิดความขัดแย้ง
Source: https://blog.sei.io/sei-v2-the-first-parallelized-evm/
การประมวลผลของ Sei ทำให้ค่าธรรมเนียมแก๊สถูกลดลง และมีพื้นที่การออกแบบกว้างขึ้นสำหรับนักพัฒนา EVM ประวัติศาสตร์ EVM environments จำกัดไว้ที่น้อยกว่า 50 TPS ซึ่งทำให้นักพัฒนาต้องสร้างแอปพลิเคชันที่เป็นแบบตรงข้าม Sei V2 ช่วยให้นักพัฒนาสามารถเข้าถึงส่วนที่ต้องการประสิทธิภาพสูงและค่าธรรมเนียมต่ำ เช่น DeFi, DePIN, และ Gaming
Monad กำลังสร้างชั้น EVM ของ Layer 1 แบบขนาน ที่เป็นไปตามมาตรฐาน bytecode ทั้งหมด สิ่งที่ทำให้ Monad มีความเป็นเอกลักษณ์ไม่ได้แค่เพียงเครื่องยนต์ขนานเท่านั้น แต่ยังมีสิ่งที่พวกเขาสร้างขึ้นภายในเครื่องยนต์เพื่อทำให้มันดียิ่งขึ้น Monad มีการเข้าใจอย่างเฉพาะเจาะจงถึงการออกแบบโดยรวม โดยรวมถึงคุณลักษณะหลักหลาย ๆ อย่าง เช่น การทำท่อประสาน การทำ I/O แบบไม่ระบบเบาะระบบ การแยกการตัดสินใจและการดำเนินการMonadDB.
นวัตกรรมสำคัญในการออกแบบ Monad คือการประสานท่อด้วยการเยื้องเล็กน้อย การเยื้องเหลือเป็นส่วนที่ทำให้สามารถประมวลกระบวนการได้มากขึ้นด้วยการรันหลายตัวพร้อมกันได้พร้อมกัน ดังนั้น การทำพายปลายท่อใช้เพื่อเพิ่มประสิทธิภาพของฟังก์ชันหลายอย่าง เช่น การทำพายปลายท่อการเข้าถึงสถานะ การทำพายปลายท่อการดำเนินธุรกรรม การทำพายปลายท่อภายในตามความเห็นร่วมและการดำเนินภายใน และการทำพายปลายท่อในกลไกความเห็นร่วมเอง
ต่อไปเราจะดับเบิลคลิกที่ชิ้นส่วนการขนานของ Monad ใน Monad ธุรกรรมจะถูกเรียงลําดับเป็นเส้นตรงภายในบล็อก แต่เป้าหมายคือการไปถึงสถานะสิ้นสุดนี้ได้เร็วขึ้นโดยใช้ประโยชน์จากการดําเนินการแบบขนาน Monad ใช้อัลกอริธึมการขนานในแง่ดีสําหรับการออกแบบกลไกการดําเนินการ กลไกของ Monad ประมวลผลธุรกรรมพร้อมกันจากนั้นทําการวิเคราะห์เพื่อให้แน่ใจว่าผลลัพธ์จะเหมือนกันหากธุรกรรมถูกดําเนินการทีละรายการ หากมีข้อขัดแย้งใด ๆ คุณต้องดําเนินการอีกครั้ง การดําเนินการแบบขนานที่นี่เป็นอัลกอริทึมที่ค่อนข้างง่าย แต่การรวมเข้ากับนวัตกรรมที่สําคัญอื่น ๆ ของ Monad คือสิ่งที่ทําให้แนวทางนี้แปลกใหม่ สิ่งหนึ่งที่ควรทราบที่นี่คือแม้ว่าการดําเนินการซ้ําจะเกิดขึ้น แต่ก็มักจะมีราคาถูกเนื่องจากอินพุตที่จําเป็นสําหรับธุรกรรมที่ไม่ถูกต้องจะยังคงอยู่ในแคชเกือบตลอดเวลาดังนั้นจึงเป็นการค้นหาแคชอย่างง่าย การดําเนินการซ้ํารับประกันว่าจะประสบความสําเร็จเนื่องจากคุณได้ทําธุรกรรมก่อนหน้าในบล็อกแล้ว
Monad ยังช่วยเพิ่มประสิทธิภาพโดยแยกระหว่างการดำเนินการและการตกลง คล้ายกับ Solana และ Sei นอกจากการดำเนินการที่ถูกเลื่อนออกไป เป้าหมายที่นี่คือหากคุณผ่อนคลายเงื่อนไขสำหรับการดำเนินการที่จะเสร็จสิ้นภายในเวลาที่การตกลงเสร็จสมบูรณ์ คุณสามารถรันทั้งสองอย่างพร้อมกัน ซึ่งจะทำให้มีเวลาเพิ่มเติมสำหรับทั้งสองอย่าง แน่นอน Monad ใช้อัลกอริทึมที่กำหนดไว้เพื่อจัดการเงื่อนไขนี้เพื่อให้มั่นใจว่าหนึ่งในเหล่านี้จะไม่วิ่งไปไกลเกินไปโดยไม่มีโอกาสในการตามทัน
เหมือนที่กล่าวถึงเมื่อต้นที่โพสต์นี้ การเข้าถึงสถานะเป็นหนึ่งในปัญหาที่สำคัญของบล็อกเชน การเลือกออกแบบเกี่ยวกับการเข้าถึงสถานะและหน่วยความจำสามารถกำหนดให้ระบบขนาดใหญ่มีประสิทธิภาพในการใช้งานจริง ที่นี่เราจะแยกออกและเปรียบเทียบวิธีการที่ Solana Sei และ Monad ใช้
การเข้าถึงสถานะ Solana: AccountsDB / Cloudbreak
Solana ใช้การขยายขอบเขตแนวนอนเพื่อกระจายและจัดการข้อมูลสถานะไปทั่วทั้งหมดของอุปกรณ์ SSD หลายตัว บล็อกเชนหลายรายการใช้ฐานข้อมูลทั่วไป (เช่น LevelDB) ที่มีข้อจำกัดในการจัดการการอ่านและเขียนข้อมูลสถานะพร้อมกันจำนวนมาก ๆ เพื่อหลีกเลี่ยงสิ่งนี้ Solana ได้สร้าง accountsDB ที่กำหนดเองของตัวเองCloudbreak.
Cloudbreak ได้รับการออกแบบมาเพื่อการเข้าถึงแบบขนานในการดําเนินงาน I/O แทนที่จะพึ่งพา RAM เพียงอย่างเดียว ซึ่งโดยเนื้อแท้แล้วรวดเร็ว การทํางานของ I/O (อินพุต/เอาต์พุต) หมายถึงการอ่านข้อมูลจากหรือเขียนข้อมูลไปยังแหล่งข้อมูลภายนอก เช่น ดิสก์ เครือข่าย หรืออุปกรณ์ต่อพ่วง ในขั้นต้น Cloudbreak ใช้ดัชนี in-RAM สําหรับการจับคู่คีย์สาธารณะกับบัญชีที่ถือยอดคงเหลือและข้อมูล อย่างไรก็ตามในขณะที่เขียนบทความนี้และเวอร์ชัน 1.9 ดัชนีถูกย้ายออกจาก RAM และไปยัง SSD การเปลี่ยนแปลงนี้ช่วยให้ Cloudbreak สามารถจัดการการทํางาน 32 (I/O) พร้อมกันในคิวซึ่งช่วยเพิ่มปริมาณการประมวลผลใน SSD หลายตัว ดังนั้นข้อมูลบล็อกเชนเช่นบัญชีและธุรกรรมจึงสามารถเข้าถึงได้อย่างมีประสิทธิภาพราวกับว่าพวกเขาอยู่ใน RAM โดยใช้ไฟล์ที่แมปหน่วยความจํา กราฟิกด้านล่างแสดงถึงลําดับชั้นของหน่วยความจําที่เป็นภาพประกอบ แม้ว่า RAM จะเร็วกว่า แต่ก็มีความจุน้อยกว่า SSD และโดยทั่วไปจะมีราคาแพงกว่า:
แผนภาพชั้นวัดความจำอย่างแสดง
โดยการขยายขนาดแนวนอนและกระจายข้อมูลสถานะไปยังอุปกรณ์หลายตัว Cloudbreak ลดความล่าช้าและเพิ่มประสิทธิภาพ การกระจาย และความทนทานของเครือข่ายภายในนิเวศ Solana
การเข้าถึงสถานะ Sei: SeiDB
Sei ได้ทำการออกแบบใหม่สำหรับการเก็บข้อมูลของมัน,SeiDB, เพื่อแก้ไขปัญหาหลายประการ: เขียนข้อมูลเพิ่มเติม (จำนวน metadata ที่จำเป็นในการรักษาโครงสร้างข้อมูล, มีขนาดเล็ก = ดีกว่า), state bloat, การดำเนินการช้า, และการเสื่อมค่าประสิทธิภาพตลอดเวลา การออกแบบใหม่ตอนนี้ถูกแยกเป็นสองส่วน: state store และ state commit การบันทึกและการตรวจสอบการเปลี่ยนแปลงของข้อมูลใด ๆ ถูกจัดการโดยการของสถานะ ในขณะที่ฐานข้อมูลที่เก็บบัญชีของข้อมูลทั้งหมดที่ใดก็ได้ที่จุดใดจะถูกจัดการโดยการเก็บข้อมูลสถานะ (SS)
ใน Sei V2, การสังฝุงสถานะใช้อภิคมความจำโครงสร้างต้นไม้ IAVL (MemIAVL)โครงสร้าง MemIAVL ใหม่ช่วยลดปัจจัยการขยายการเขียนเพราะลด metadata ที่จำเป็นต้องรักษาโครงสร้างข้อมูล
SeiDB ที่อัปเดตแล้วช่วยให้การสนับสนุนฐานข้อมูลหลังบ้านที่ยืดหยุ่นสำหรับเลเยอร์การเก็บข้อมูลสถานะ Sei เชื่อว่าผู้ดำเนินโหนดที่แตกต่างกันจะมีความต้องการที่หลากหลายและความต้องการในการเก็บข้อมูล ดังนั้น SS ถูกออกแบบให้รองรับแหล่งข้อมูลหลังบ้านที่แตกต่างกันโดยให้ผู้ดำเนินการเสรีภาพและความยืดหยุ่น นั่นคือ PebbleDB, RocksDB, SQLite, เป็นต้น
State Access: MonadDB
มีบางข้อสำคัญในการเข้าถึงสถานะของ Monad แรก โปรแกรมลูกค้า Ethereum ส่วนใหญ่ใช้ฐานข้อมูล 2 ประเภท: ฐานข้อมูล B-Tree (เช่น LMDB) หรือ ฐานข้อมูล log-structured merge tree (LSM) (เช่น RocksDB, LevelDB) ทั้งสองรูปแบบนี้เป็นโครงสร้างข้อมูลทั่วไป ไม่ได้ออกแบบโดยเฉพาะสำหรับบล็อกเชน นอกจากนี้ ฐานข้อมูลเหล่านี้ไม่ใช้การพัฒนาล่าสุดในเทคโนโลยี Linux โดยเฉพาะเรื่องการดำเนินการแบบไม่สม่ำเสมอและการปรับปรุง I/O ท้ายที่ Ethereum เองจัดการกับสถานะโดยใช้Patricia Merkle Trie, ซึ่งเชี่ยวชาญในด้านการเข้ารหัสลับ การตรวจสอบ และการพิสูจน์ ปัญหาหลักคือ ลูกค้าต้องผสานรวม Patricia Merkle Trie เฉพาะนี้เข้ากับฐานข้อมูลทั่วไปมากขึ้น (เช่น B-Tree / LSM) ซึ่งมีข้อเสียหลักคือ การเข้าถึงดิสก์มากเกินไป
ทั้งหมดที่กล่าวมาข้างต้นช่วยกำหนดเวทีให้กับเหตุผลที่ Monad ตัดสินใจสร้างฐานข้อมูล MonadDB แบบกำหนดเองเพื่อจัดการข้อมูลบล็อกเชนและการเข้าถึงสถานะได้อย่างมีประสิทธิภาพมากขึ้น บางคุณสมบัติสำคัญของ MonadDB ประกอบด้วยฐานข้อมูลการเข้าถึงพร้อมกัน ฐานข้อมูลกำหนดเองที่ถูกปรับให้เหมาะสำหรับข้อมูล Merkle Trie การเข้าถึงสถานะอย่างมีประสิทธิภาพเกินการใช้ RAM มาตรฐาน และการกระจายและการขยายของระบบ
MonadDB ถูกออกแบบโดยชัดเจนสำหรับบล็อกเชน ทำให้มีประสิทธิภาพมากกว่าการใช้ฐานข้อมูลทั่วไป ปรับทำ MonadDB เองเพื่อการจัดการข้อมูลแบบ Merkle trie อย่างมีประสิทธิภาพ ทำให้สามารถเข้าถึงโหนด trie หลายๆ โหนดพร้อมกันได้อย่างมีประสิทธิภาพ ถึงแม้ค่าใช้จ่ายของการอ่านเพียงครั้งเดียวบน MonadDB เทียบกับบางฐานข้อมูลทั่วไปที่ระบุไว้ข้างต้นจะเท่ากัน แต่คุณสมบัติสำคัญที่นี่คือ MonadDB สามารถเรียกอ่านได้หลายคำสั่งพร้อมกัน ทำให้เกิดการเร่งความเร็วอย่างมาก
MonadDB ช่วยให้สามารถเข้าถึงสถานะพร้อมกันไปยังฐานข้อมูลการเข้าถึงแบบขนาน เนื่องจาก Monad กําลังสร้างฐานข้อมูลนี้ตั้งแต่เริ่มต้น จึงสามารถใช้ประโยชน์จากเทคโนโลยีเคอร์เนล Linux ที่ทันสมัยที่สุดและพลังเต็มรูปแบบของ SSD สําหรับ I/O แบบอะซิงโครนัส ด้วย Async I/O หากธุรกรรมต้องการสถานะการอ่านจากดิสก์ สิ่งนี้ไม่ควรหยุดการดําเนินการที่รอให้เสร็จสิ้น แต่ควรเริ่มอ่านและดําเนินการธุรกรรมอื่น ๆ ต่อไปพร้อมกัน นี่คือวิธีที่ Async I/O เพิ่มความเร็วในการประมวลผลสําหรับ MonadDB อย่างมาก Monad สามารถดึงประสิทธิภาพที่ดีขึ้นจากฮาร์ดแวร์โดยเพิ่มประสิทธิภาพการใช้งาน SSD และลดการพึ่งพา RAM ที่มากเกินไป สิ่งนี้มีประโยชน์เพิ่มเติมในการสอดคล้องกับการกระจายอํานาจและความสามารถในการปรับขนาด
สรุปการเปรียบเทียบสำหรับ Solana vs. Sei vs. Monad
โดยสรุปการสํารวจความขนานในบล็อกเชนผ่านเลนส์ของ Solana, Sei และ Monad ให้ความเข้าใจที่ครอบคลุมว่าสถาปัตยกรรมและวิธีการที่แตกต่างกันสามารถเพิ่มประสิทธิภาพและความสามารถในการปรับขนาดได้อย่างไร การขนานที่กําหนดขึ้นของ Solana โดยเน้นที่การประกาศการเข้าถึงของรัฐล่วงหน้าให้การคาดการณ์และประสิทธิภาพทําให้เป็นตัวเลือกที่มีประสิทธิภาพสําหรับแอปพลิเคชันที่ต้องการปริมาณงานสูง ในทางกลับกันแนวทางการขนานในแง่ดีของ Sei ให้ความสําคัญกับความยืดหยุ่นของนักพัฒนาและเหมาะสําหรับสภาพแวดล้อมที่ความขัดแย้งในการทําธุรกรรมไม่บ่อยนัก ด้วยการผสมผสานที่เป็นเอกลักษณ์ของการขนานในแง่ดีและ MonadDB ที่สร้างขึ้นเอง Monad นําเสนอโซลูชันที่เป็นนวัตกรรมใหม่ที่ใช้ประโยชน์จากความก้าวหน้าทางเทคโนโลยีล่าสุดเพื่อเพิ่มประสิทธิภาพการเข้าถึงและประสิทธิภาพของรัฐ
ทุกบล็อกเชนนำเสนอวิธีการแตกต่างกันในการแก้ไขความท้าทายในการประมวลผลพร้อมกัน ด้วยชุดของการตัดสินใจของตัวเอง การออกแบบของ Solana มุ่งเน้นที่การใช้ประโยชน์จากฮาร์ดแวร์และประสิทธิภาพในการทำงาน ในขณะที่ Sei ให้ความสำคัญกับการลดความยุ่งเหยของกระบวนการพัฒนา และ Monad ย้ำถึงการให้ความสำคัญกับการแก้ปัญหาฐานข้อมูลที่ทันสมัยสำหรับข้อมูลบล็อกเชน ความแตกต่างเหล่านี้ย้ำถึงความหลากหลายในระบบนิเวศบล็อกเชนและความสำคัญของการเลือกแพลตฟอร์มที่เหมาะสมตามความต้องการเฉพาะของแอปพลิเคชัน
เนื่องจากพื้นที่บล็อกเชนยังคงเริ่มต้นการพัฒนาต่อไป ความคืบหน้าในเทคนิคการขนานนามที่ได้รับการสาธิตโดย Solana, Monad, และ Sei อย่างไม่น่าสงสารจะกระตุ้นนวัตกรรมต่อไป การต่อสู้สู่บล็อกเชนที่มีประสิทธิภาพมากขึ้น สามารถขยายขึ้นได้ และเป็นมิตรต่อนักพัฒนาต่อไป ยังคงอยู่ระหว่างการดำเนินการ และบทเรียนที่เรียนรู้จากแพลตฟอร์มเหล่านี้จะเล่นบทบาทสำคัญในการรูปร่างอนาคตของเทคโนโลยีบล็อกเชน
ในส่วนที่ II ของซีรีส์นี้ เราจะลงจริงในผลกระทบทางเศรษฐกิจและการต่อรองที่เกี่ยวข้องกับระบบการออกแบบแบบขนานเหล่านี้
TLDR: บทความวิจัยนี้ให้ภาพรวมของสถาปัตยกรรมการออกแบบขนาดขนาดขนาดสำหรับบล็อกเชนโดยใช้ตัวอย่างที่สำคัญสามตัว ได้แก่ Solana, Sei และ Monad โดยเน้นที่ความแตกต่างระหว่างการจัดเรียงแบบ optimistic และ deterministic และสำรวจรายละเอียดของการเข้าถึงสถานะและหน่วยความจำในเครือข่ายเหล่านี้
ในปี 1837 นักวิทยาการคอมพิวเตอร์และนักคณิตศาสตร์ชาร์ลส์ บาบเบจออกแบบ " เครื่องวิเคราะห์,” which laid the theoretical foundation for parallel computation. Today, parallelization is a pivotal theme within the crypto world as blockchains attempt to push the boundaries of processing, efficiency, and throughput.
จักรวาลขนาน
คำนวณขนาดใหญ่แบบขนาน ช่วยให้สามารถดำเนินการหลายการคำนวณหรือกระบวนการพร้อมกัน ในขณะที่การคำนวณทำงานแบบตรงต่อเนื่องหรือตามลำดับต่อเนื่อง การคำนวณขนานหมายถึงการแบ่งปัญหาขนาดใหญ่เป็นส่วนย่อยที่อิสระจากกัน ซึ่งสามารถดำเนินการโดยหลายโปรเซสเซอร์พูดคุยผ่านหน่วยความจำร่วมกัน ระบบขนานมีข้อดีหลายประการ เช่น ประสิทธิภาพและความเร็วเพิ่มขึ้น การปรับขนาด ความเชื่อถือไว้วางใจและความทนทานต่อข้อผิดพลาด การใช้ทรัพยากรได้ดีขึ้น และความสามารถในการจัดการชุดข้อมูลขนาดใหญ่มาก
อย่างไรก็ตามสิ่งสําคัญคือต้องตระหนักว่าประสิทธิภาพของการขนานขึ้นอยู่กับลักษณะเฉพาะของสถาปัตยกรรมพื้นฐานและการใช้งาน ปัญหาคอขวดหลักสองประการของบล็อกเชนคือฟังก์ชันการเข้ารหัส (ฟังก์ชันแฮช ลายเซ็น เส้นโค้งรูปไข่ ฯลฯ) และการเข้าถึงหน่วยความจํา/สถานะ ด้วยบล็อกเชน หนึ่งในองค์ประกอบสําคัญของการออกแบบระบบขนานที่มีประสิทธิภาพอยู่ที่ความแตกต่างของการเข้าถึงสถานะ การเข้าถึงของรัฐหมายถึงความสามารถของธุรกรรมในการอ่านและเขียนไปยังสถานะของบล็อกเชน รวมถึงการจัดเก็บ สัญญาอัจฉริยะ และยอดคงเหลือในบัญชี เพื่อให้บล็อกเชนแบบขนานมีประสิทธิภาพและมีประสิทธิภาพการเข้าถึงของรัฐจะต้องได้รับการปรับให้เหมาะสม
ในปัจจุบันมีสองโรงเรียนความคิดในการปรับปรุงการเข้าถึงสถานะสำหรับบล็อกเชนที่มีการประมวลผลแบบขนาน: การขนานแบบกำหนด vs. การขนานแบบโดยสมัครใจ การขนานแบบกำหนดต้องการให้โค้ดระบุล่วงหน้าว่าส่วนใดของสถานะบล็อกเชนจะถูกเข้าถึงและแก้ไข นี่ช่วยให้ระบบสามารถกำหนดได้ว่าธุรกรรมไหนสามารถประมวลผลได้แบบขนานโดยไม่มีความขัดแย้งล่วงหน้า การขนานแบบกำหนดช่วยให้สามารถทำนายและมีประสิทธิภาพ (โดยเฉพาะเมื่อธุรกรรมเป็นอิสระส่วนใหญ่) อย่างไรก็ตาม มันก็สร้างความซับซ้อนมากขึ้นสำหรับนักพัฒนา
การขนานในแง่ดีไม่จําเป็นต้องมีรหัสเพื่อประกาศการเข้าถึงของรัฐล่วงหน้าและประมวลผลธุรกรรมควบคู่กันราวกับว่าจะไม่มีความขัดแย้ง หากมีข้อขัดแย้งเกิดขึ้นการขนานในแง่ดีจะเรียกใช้ใหม่ประมวลผลใหม่หรือเรียกใช้ธุรกรรมที่ขัดแย้งกันอย่างต่อเนื่อง ในขณะที่การขนานในแง่ดีช่วยให้นักพัฒนามีความยืดหยุ่นมากขึ้น แต่จําเป็นต้องมีการดําเนินการซ้ําสําหรับความขัดแย้งส่งผลให้วิธีนี้มีประสิทธิภาพสูงสุดเมื่อธุรกรรมไม่ขัดแย้งกัน ไม่มีคําตอบที่ถูกต้องว่าแนวทางใดดีกว่ากัน พวกเขาเป็นเพียงสองวิธีที่แตกต่างกัน (และทํางานได้) เพื่อขนาน
ในส่วนที่ 1 ของซีรีส์นี้ เราจะสำรวจพื้นฐานบางอย่างของระบบขนาดขนาดไม่ใช่คริปโต ตามด้วยพื้นที่การออกแบบสำหรับการดำเนินการขนาดขนาดสำหรับบล็อกเชน โดยเน้นที่สามพื้นที่หลัก:
การรับรู้ว่าสิ่งที่เราได้อ่านเพิ่มเติมเกี่ยวกับสิ่งที่การคำนวณแบบขนานทำให้เป็นไปได้และข้อดีของระบบขนาน จะเข้าใจได้ง่ายว่าทำไมการนำการคำนวณแบบขนานได้เป็นอย่างมากในปีก่อนหน้านี้ การนำการคำนวณแบบขนานมากขึ้นได้เปิดทางให้การพัฒนาขึ้นมาของหลายสิ่งที่สำคัญในเพียงไม่กี่ทศวรรษที่ผ่านมาเท่านั้น
เรามาสำรวจบล็อกเชนสามระบบที่ได้นำระบบการทำงานขนาดขนาดขนาดขนาดขนาดขนาดของขนาดของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของของขลงลง Solana พอดี ตามด้วย Monad และ Sei
ในระดับสูง ศาลานา มีหลักการออกแบบที่ว่านวัตกรรมบล็อกเชนควรพัฒนาต่อไปพร้อมกับความก้าวหน้าของฮาร์ดแวร์ โดยที่เฮาร์ดแวร์ดีขึ้นตามเวลาผ่านทฤษฎีของมูอร์ ศาลานาถูกออกแบบให้ได้รับประโยชน์จากประสิทธิภาพและความยืดหยุ่นที่เพิ่มขึ้นAnatoly Yakovenkoออกแบบเริ่มแรกโครงสร้างการขนานของ Solanaมากกว่าห้าปีที่แล้ว และในปัจจุบัน การใช้พริ้นซิพแบบขนานเป็นหลักการออกแบบบล็อกเชนกำลังแพร่กระจายอย่างรวดเร็ว
Solana ใช้การขนานกันที่กำหนดไว้ล่วงหน้า ซึ่งมาจากประสบการณ์ในอดีตของ Anatoly ในการทำงานกับระบบฝังตัว ที่นักพัฒนาโดยทั่วไปจะประกาศสถานะทั้งหมดล่วงหน้า สิ่งนี้ทำให้ CPU ทราบเสมอเกี่ยวกับความขึ้นต่อกัน ซึ่งทำให้มันสามารถดึงข้อมูลที่จำเป็นล่วงหน้า ผลลัพธ์คือการดำเนินการของระบบที่ถูกจัดเรียงอย่างเหมาะสม แต่อีกครั้งก็ต้องการนักพัฒนาทำงานเสริมเพิ่มล่วงหน้า ใน Solana ความขึ้นต่อกันของหน่วยความจำสำหรับโปรแกรมทุกๆ ชุดมีความจำเป็นและระบุไว้ในธุรกรรมที่สร้างขึ้น (เช่น รายการเข้าถึง) ซึ่งทำให้เวลารันไทม์สามารถกำหนดการและดำเนินการธุรกรรมหลายๆ รายการขนานกันได้อย่างมีประสิทธิภาพ
องค์ประกอบหลักต่อไปของสถาปัตยกรรมของ Solana คือ Sealevel VM ซึ่งเป็นรันไทม์สัญญาอัจฉริยะแบบขนานของ Solana Sealevel รองรับการประมวลผลสัญญาและธุรกรรมหลายรายการแบบขนานตามจํานวนคอร์ที่ผู้ตรวจสอบมี ผู้ตรวจสอบความถูกต้องในบล็อกเชนคือผู้เข้าร่วมเครือข่ายที่รับผิดชอบในการตรวจสอบและตรวจสอบความถูกต้องของธุรกรรมเสนอบล็อกใหม่และรักษาความสมบูรณ์และความปลอดภัยของบล็อกเชน เนื่องจากธุรกรรมประกาศว่าบัญชีใดที่ต้องอ่านและเขียนถูกล็อคล่วงหน้าตัวกําหนดตารางเวลา Solana จึงสามารถกําหนดธุรกรรมที่สามารถดําเนินการพร้อมกันได้ ด้วยเหตุนี้เมื่อพูดถึงการตรวจสอบความถูกต้อง" Block Producer " หรือ Leader จึงสามารถจัดเรียงธุรกรรมที่รอดําเนินการหลายพันรายการและกําหนดเวลาธุรกรรมที่ไม่ทับซ้อนกันในแบบคู่ขนาน
องค์ประกอบการออกแบบสุดท้ายสำหรับ Solana คือ "การทำท่อ" การทำท่อเกิดขึ้นเมื่อต้องประมวลผลข้อมูลในลำดับของขั้นตอน และฮาร์ดแวร์ที่แตกต่างกันรับผิดชอบในแต่ละขั้นตอน ความคิดสำคัญที่นี่คือการเอาข้อมูลที่ต้องเรียกทำงานในลำดับและทำให้มันขนานใช้การทำท่อ ท่อเหล่านี้สามารถทำงานขนานกันและแต่ละขั้นตอนของท่อสามารถประมวลผลชุดธุรกรรมที่แตกต่างกัน
การปรับปรุงเหล่านี้ช่วยให้ Sealevel สามารถจัดการและดำเนินธุรกรรมที่เป็นอิสระพร้อมกัน โดยใช้ความสามารถของฮาร์ดแวร์ในการประมวลผลจำนวนข้อมูลหลายๆ จุดพร้อมกันด้วยโปรแกรมเดียว Sealevel เรียงคำสั่งตาม programID และดำเนินคำสั่งเดียวกันบนบัญชีที่เกี่ยวข้องทั้งหมดพร้อมกัน
ด้วยนวัตกรรมเหล่านี้ในใจ, เราสามารถเห็นได้ว่า Solana ถูกออกแบบโดยตั้งใจเพื่อสนับสนุนการประมวลผลแบบขนาน
Sei เป็นบล็อกเชนชั้นที่ 1 แบบโปรแกรมสากลและโอเพ่นซอร์สที่พิเศษสำหรับการแลกเปลี่ยนสินทรัพย์ดิจิทัล เซอี V2 ใช้การขยายตัวแบบโดยเลขหมุนและด้วยเหตุนี้จึงเป็นมิตรต่อนักพัฒนามากกว่าคู่แข่งที่กำหนดไว้ล่วงหน้า ในการขยายตัวแบบโดยเลขหมุนนี้ สมาร์ทคอนแทร็กสามารถทำงานอย่างไม่ต่อเนื่องและพร้อมกันมากขึ้นโดยที่ไม่ต้องการให้นักพัฒนาประกาศทรัพยากรล่วงหน้า ซึ่งหมายความว่าโซ่ทำงานอย่างโดดเดี่ยวอย่างเต็มที่ทุกธุรกรรม แต่เมื่อเกิดความขัดแย้ง (เช่น มีหลายธุรกรรมเข้าถึงสถานะเดียวกัน) บล็อกเชนจะติดตามส่วนคอมโพเนนต์ที่เฉพาะเจาะจงที่แต่ละธุรกรรมที่ขัดแย้งมีผลต่อ
บล็อกเชนของ Sei ใช้วิธีการดำเนินการธุรกรรมโดยใช้ “Optimistic Concurrency Control (OCC)” การประมวลผลธุรกรรมที่เกิดขึ้นพร้อมกันเมื่อมีธุรกรรมหลายรายการที่มีอยู่พร้อมกันในระบบ มีขั้นตอนสองขั้นตอนในวิธีการดำเนินการธุรกรรมนี้ คือ การดำเนินการและการตรวจสอบ
ในขั้นตอนการดําเนินการธุรกรรมจะได้รับการประมวลผลในแง่ดีโดยการอ่าน / เขียนทั้งหมดจะถูกจัดเก็บไว้ชั่วคราวในร้านค้าเฉพาะธุรกรรม หลังจากนี้ทุกธุรกรรมจะเข้าสู่ขั้นตอนการตรวจสอบความถูกต้องซึ่งข้อมูลในการดําเนินการจัดเก็บชั่วคราวจะถูกตรวจสอบกับการเปลี่ยนแปลงสถานะใด ๆ ที่ทําโดยธุรกรรมก่อนหน้า หากธุรกรรมเป็นอิสระธุรกรรมจะทํางานควบคู่กัน หากธุรกรรมอ่านข้อมูลที่แก้ไขโดยธุรกรรมอื่นสิ่งนี้จะสร้างความขัดแย้ง ระบบคู่ขนานของ SEI จะระบุข้อขัดแย้งแต่ละข้อโดยการเปรียบเทียบชุดการอ่านธุรกรรมกับการเปลี่ยนแปลงสถานะล่าสุดในร้านค้าหลายเวอร์ชัน (จัดทําดัชนีตามลําดับธุรกรรม) Sei จะดําเนินการและตรวจสอบกรณีที่มีความขัดแย้งเกิดขึ้นอีกครั้ง นี่เป็นกระบวนการทําซ้ําที่เกี่ยวข้องกับการดําเนินการการตรวจสอบความถูกต้องและการทํางานซ้ําเพื่อแก้ไขข้อขัดแย้ง กราฟิกด้านล่างแสดงให้เห็นถึงแนวทางการทําธุรกรรมของ Sei เมื่อเกิดความขัดแย้ง
Source: https://blog.sei.io/sei-v2-the-first-parallelized-evm/
การประมวลผลของ Sei ทำให้ค่าธรรมเนียมแก๊สถูกลดลง และมีพื้นที่การออกแบบกว้างขึ้นสำหรับนักพัฒนา EVM ประวัติศาสตร์ EVM environments จำกัดไว้ที่น้อยกว่า 50 TPS ซึ่งทำให้นักพัฒนาต้องสร้างแอปพลิเคชันที่เป็นแบบตรงข้าม Sei V2 ช่วยให้นักพัฒนาสามารถเข้าถึงส่วนที่ต้องการประสิทธิภาพสูงและค่าธรรมเนียมต่ำ เช่น DeFi, DePIN, และ Gaming
Monad กำลังสร้างชั้น EVM ของ Layer 1 แบบขนาน ที่เป็นไปตามมาตรฐาน bytecode ทั้งหมด สิ่งที่ทำให้ Monad มีความเป็นเอกลักษณ์ไม่ได้แค่เพียงเครื่องยนต์ขนานเท่านั้น แต่ยังมีสิ่งที่พวกเขาสร้างขึ้นภายในเครื่องยนต์เพื่อทำให้มันดียิ่งขึ้น Monad มีการเข้าใจอย่างเฉพาะเจาะจงถึงการออกแบบโดยรวม โดยรวมถึงคุณลักษณะหลักหลาย ๆ อย่าง เช่น การทำท่อประสาน การทำ I/O แบบไม่ระบบเบาะระบบ การแยกการตัดสินใจและการดำเนินการMonadDB.
นวัตกรรมสำคัญในการออกแบบ Monad คือการประสานท่อด้วยการเยื้องเล็กน้อย การเยื้องเหลือเป็นส่วนที่ทำให้สามารถประมวลกระบวนการได้มากขึ้นด้วยการรันหลายตัวพร้อมกันได้พร้อมกัน ดังนั้น การทำพายปลายท่อใช้เพื่อเพิ่มประสิทธิภาพของฟังก์ชันหลายอย่าง เช่น การทำพายปลายท่อการเข้าถึงสถานะ การทำพายปลายท่อการดำเนินธุรกรรม การทำพายปลายท่อภายในตามความเห็นร่วมและการดำเนินภายใน และการทำพายปลายท่อในกลไกความเห็นร่วมเอง
ต่อไปเราจะดับเบิลคลิกที่ชิ้นส่วนการขนานของ Monad ใน Monad ธุรกรรมจะถูกเรียงลําดับเป็นเส้นตรงภายในบล็อก แต่เป้าหมายคือการไปถึงสถานะสิ้นสุดนี้ได้เร็วขึ้นโดยใช้ประโยชน์จากการดําเนินการแบบขนาน Monad ใช้อัลกอริธึมการขนานในแง่ดีสําหรับการออกแบบกลไกการดําเนินการ กลไกของ Monad ประมวลผลธุรกรรมพร้อมกันจากนั้นทําการวิเคราะห์เพื่อให้แน่ใจว่าผลลัพธ์จะเหมือนกันหากธุรกรรมถูกดําเนินการทีละรายการ หากมีข้อขัดแย้งใด ๆ คุณต้องดําเนินการอีกครั้ง การดําเนินการแบบขนานที่นี่เป็นอัลกอริทึมที่ค่อนข้างง่าย แต่การรวมเข้ากับนวัตกรรมที่สําคัญอื่น ๆ ของ Monad คือสิ่งที่ทําให้แนวทางนี้แปลกใหม่ สิ่งหนึ่งที่ควรทราบที่นี่คือแม้ว่าการดําเนินการซ้ําจะเกิดขึ้น แต่ก็มักจะมีราคาถูกเนื่องจากอินพุตที่จําเป็นสําหรับธุรกรรมที่ไม่ถูกต้องจะยังคงอยู่ในแคชเกือบตลอดเวลาดังนั้นจึงเป็นการค้นหาแคชอย่างง่าย การดําเนินการซ้ํารับประกันว่าจะประสบความสําเร็จเนื่องจากคุณได้ทําธุรกรรมก่อนหน้าในบล็อกแล้ว
Monad ยังช่วยเพิ่มประสิทธิภาพโดยแยกระหว่างการดำเนินการและการตกลง คล้ายกับ Solana และ Sei นอกจากการดำเนินการที่ถูกเลื่อนออกไป เป้าหมายที่นี่คือหากคุณผ่อนคลายเงื่อนไขสำหรับการดำเนินการที่จะเสร็จสิ้นภายในเวลาที่การตกลงเสร็จสมบูรณ์ คุณสามารถรันทั้งสองอย่างพร้อมกัน ซึ่งจะทำให้มีเวลาเพิ่มเติมสำหรับทั้งสองอย่าง แน่นอน Monad ใช้อัลกอริทึมที่กำหนดไว้เพื่อจัดการเงื่อนไขนี้เพื่อให้มั่นใจว่าหนึ่งในเหล่านี้จะไม่วิ่งไปไกลเกินไปโดยไม่มีโอกาสในการตามทัน
เหมือนที่กล่าวถึงเมื่อต้นที่โพสต์นี้ การเข้าถึงสถานะเป็นหนึ่งในปัญหาที่สำคัญของบล็อกเชน การเลือกออกแบบเกี่ยวกับการเข้าถึงสถานะและหน่วยความจำสามารถกำหนดให้ระบบขนาดใหญ่มีประสิทธิภาพในการใช้งานจริง ที่นี่เราจะแยกออกและเปรียบเทียบวิธีการที่ Solana Sei และ Monad ใช้
การเข้าถึงสถานะ Solana: AccountsDB / Cloudbreak
Solana ใช้การขยายขอบเขตแนวนอนเพื่อกระจายและจัดการข้อมูลสถานะไปทั่วทั้งหมดของอุปกรณ์ SSD หลายตัว บล็อกเชนหลายรายการใช้ฐานข้อมูลทั่วไป (เช่น LevelDB) ที่มีข้อจำกัดในการจัดการการอ่านและเขียนข้อมูลสถานะพร้อมกันจำนวนมาก ๆ เพื่อหลีกเลี่ยงสิ่งนี้ Solana ได้สร้าง accountsDB ที่กำหนดเองของตัวเองCloudbreak.
Cloudbreak ได้รับการออกแบบมาเพื่อการเข้าถึงแบบขนานในการดําเนินงาน I/O แทนที่จะพึ่งพา RAM เพียงอย่างเดียว ซึ่งโดยเนื้อแท้แล้วรวดเร็ว การทํางานของ I/O (อินพุต/เอาต์พุต) หมายถึงการอ่านข้อมูลจากหรือเขียนข้อมูลไปยังแหล่งข้อมูลภายนอก เช่น ดิสก์ เครือข่าย หรืออุปกรณ์ต่อพ่วง ในขั้นต้น Cloudbreak ใช้ดัชนี in-RAM สําหรับการจับคู่คีย์สาธารณะกับบัญชีที่ถือยอดคงเหลือและข้อมูล อย่างไรก็ตามในขณะที่เขียนบทความนี้และเวอร์ชัน 1.9 ดัชนีถูกย้ายออกจาก RAM และไปยัง SSD การเปลี่ยนแปลงนี้ช่วยให้ Cloudbreak สามารถจัดการการทํางาน 32 (I/O) พร้อมกันในคิวซึ่งช่วยเพิ่มปริมาณการประมวลผลใน SSD หลายตัว ดังนั้นข้อมูลบล็อกเชนเช่นบัญชีและธุรกรรมจึงสามารถเข้าถึงได้อย่างมีประสิทธิภาพราวกับว่าพวกเขาอยู่ใน RAM โดยใช้ไฟล์ที่แมปหน่วยความจํา กราฟิกด้านล่างแสดงถึงลําดับชั้นของหน่วยความจําที่เป็นภาพประกอบ แม้ว่า RAM จะเร็วกว่า แต่ก็มีความจุน้อยกว่า SSD และโดยทั่วไปจะมีราคาแพงกว่า:
แผนภาพชั้นวัดความจำอย่างแสดง
โดยการขยายขนาดแนวนอนและกระจายข้อมูลสถานะไปยังอุปกรณ์หลายตัว Cloudbreak ลดความล่าช้าและเพิ่มประสิทธิภาพ การกระจาย และความทนทานของเครือข่ายภายในนิเวศ Solana
การเข้าถึงสถานะ Sei: SeiDB
Sei ได้ทำการออกแบบใหม่สำหรับการเก็บข้อมูลของมัน,SeiDB, เพื่อแก้ไขปัญหาหลายประการ: เขียนข้อมูลเพิ่มเติม (จำนวน metadata ที่จำเป็นในการรักษาโครงสร้างข้อมูล, มีขนาดเล็ก = ดีกว่า), state bloat, การดำเนินการช้า, และการเสื่อมค่าประสิทธิภาพตลอดเวลา การออกแบบใหม่ตอนนี้ถูกแยกเป็นสองส่วน: state store และ state commit การบันทึกและการตรวจสอบการเปลี่ยนแปลงของข้อมูลใด ๆ ถูกจัดการโดยการของสถานะ ในขณะที่ฐานข้อมูลที่เก็บบัญชีของข้อมูลทั้งหมดที่ใดก็ได้ที่จุดใดจะถูกจัดการโดยการเก็บข้อมูลสถานะ (SS)
ใน Sei V2, การสังฝุงสถานะใช้อภิคมความจำโครงสร้างต้นไม้ IAVL (MemIAVL)โครงสร้าง MemIAVL ใหม่ช่วยลดปัจจัยการขยายการเขียนเพราะลด metadata ที่จำเป็นต้องรักษาโครงสร้างข้อมูล
SeiDB ที่อัปเดตแล้วช่วยให้การสนับสนุนฐานข้อมูลหลังบ้านที่ยืดหยุ่นสำหรับเลเยอร์การเก็บข้อมูลสถานะ Sei เชื่อว่าผู้ดำเนินโหนดที่แตกต่างกันจะมีความต้องการที่หลากหลายและความต้องการในการเก็บข้อมูล ดังนั้น SS ถูกออกแบบให้รองรับแหล่งข้อมูลหลังบ้านที่แตกต่างกันโดยให้ผู้ดำเนินการเสรีภาพและความยืดหยุ่น นั่นคือ PebbleDB, RocksDB, SQLite, เป็นต้น
State Access: MonadDB
มีบางข้อสำคัญในการเข้าถึงสถานะของ Monad แรก โปรแกรมลูกค้า Ethereum ส่วนใหญ่ใช้ฐานข้อมูล 2 ประเภท: ฐานข้อมูล B-Tree (เช่น LMDB) หรือ ฐานข้อมูล log-structured merge tree (LSM) (เช่น RocksDB, LevelDB) ทั้งสองรูปแบบนี้เป็นโครงสร้างข้อมูลทั่วไป ไม่ได้ออกแบบโดยเฉพาะสำหรับบล็อกเชน นอกจากนี้ ฐานข้อมูลเหล่านี้ไม่ใช้การพัฒนาล่าสุดในเทคโนโลยี Linux โดยเฉพาะเรื่องการดำเนินการแบบไม่สม่ำเสมอและการปรับปรุง I/O ท้ายที่ Ethereum เองจัดการกับสถานะโดยใช้Patricia Merkle Trie, ซึ่งเชี่ยวชาญในด้านการเข้ารหัสลับ การตรวจสอบ และการพิสูจน์ ปัญหาหลักคือ ลูกค้าต้องผสานรวม Patricia Merkle Trie เฉพาะนี้เข้ากับฐานข้อมูลทั่วไปมากขึ้น (เช่น B-Tree / LSM) ซึ่งมีข้อเสียหลักคือ การเข้าถึงดิสก์มากเกินไป
ทั้งหมดที่กล่าวมาข้างต้นช่วยกำหนดเวทีให้กับเหตุผลที่ Monad ตัดสินใจสร้างฐานข้อมูล MonadDB แบบกำหนดเองเพื่อจัดการข้อมูลบล็อกเชนและการเข้าถึงสถานะได้อย่างมีประสิทธิภาพมากขึ้น บางคุณสมบัติสำคัญของ MonadDB ประกอบด้วยฐานข้อมูลการเข้าถึงพร้อมกัน ฐานข้อมูลกำหนดเองที่ถูกปรับให้เหมาะสำหรับข้อมูล Merkle Trie การเข้าถึงสถานะอย่างมีประสิทธิภาพเกินการใช้ RAM มาตรฐาน และการกระจายและการขยายของระบบ
MonadDB ถูกออกแบบโดยชัดเจนสำหรับบล็อกเชน ทำให้มีประสิทธิภาพมากกว่าการใช้ฐานข้อมูลทั่วไป ปรับทำ MonadDB เองเพื่อการจัดการข้อมูลแบบ Merkle trie อย่างมีประสิทธิภาพ ทำให้สามารถเข้าถึงโหนด trie หลายๆ โหนดพร้อมกันได้อย่างมีประสิทธิภาพ ถึงแม้ค่าใช้จ่ายของการอ่านเพียงครั้งเดียวบน MonadDB เทียบกับบางฐานข้อมูลทั่วไปที่ระบุไว้ข้างต้นจะเท่ากัน แต่คุณสมบัติสำคัญที่นี่คือ MonadDB สามารถเรียกอ่านได้หลายคำสั่งพร้อมกัน ทำให้เกิดการเร่งความเร็วอย่างมาก
MonadDB ช่วยให้สามารถเข้าถึงสถานะพร้อมกันไปยังฐานข้อมูลการเข้าถึงแบบขนาน เนื่องจาก Monad กําลังสร้างฐานข้อมูลนี้ตั้งแต่เริ่มต้น จึงสามารถใช้ประโยชน์จากเทคโนโลยีเคอร์เนล Linux ที่ทันสมัยที่สุดและพลังเต็มรูปแบบของ SSD สําหรับ I/O แบบอะซิงโครนัส ด้วย Async I/O หากธุรกรรมต้องการสถานะการอ่านจากดิสก์ สิ่งนี้ไม่ควรหยุดการดําเนินการที่รอให้เสร็จสิ้น แต่ควรเริ่มอ่านและดําเนินการธุรกรรมอื่น ๆ ต่อไปพร้อมกัน นี่คือวิธีที่ Async I/O เพิ่มความเร็วในการประมวลผลสําหรับ MonadDB อย่างมาก Monad สามารถดึงประสิทธิภาพที่ดีขึ้นจากฮาร์ดแวร์โดยเพิ่มประสิทธิภาพการใช้งาน SSD และลดการพึ่งพา RAM ที่มากเกินไป สิ่งนี้มีประโยชน์เพิ่มเติมในการสอดคล้องกับการกระจายอํานาจและความสามารถในการปรับขนาด
สรุปการเปรียบเทียบสำหรับ Solana vs. Sei vs. Monad
โดยสรุปการสํารวจความขนานในบล็อกเชนผ่านเลนส์ของ Solana, Sei และ Monad ให้ความเข้าใจที่ครอบคลุมว่าสถาปัตยกรรมและวิธีการที่แตกต่างกันสามารถเพิ่มประสิทธิภาพและความสามารถในการปรับขนาดได้อย่างไร การขนานที่กําหนดขึ้นของ Solana โดยเน้นที่การประกาศการเข้าถึงของรัฐล่วงหน้าให้การคาดการณ์และประสิทธิภาพทําให้เป็นตัวเลือกที่มีประสิทธิภาพสําหรับแอปพลิเคชันที่ต้องการปริมาณงานสูง ในทางกลับกันแนวทางการขนานในแง่ดีของ Sei ให้ความสําคัญกับความยืดหยุ่นของนักพัฒนาและเหมาะสําหรับสภาพแวดล้อมที่ความขัดแย้งในการทําธุรกรรมไม่บ่อยนัก ด้วยการผสมผสานที่เป็นเอกลักษณ์ของการขนานในแง่ดีและ MonadDB ที่สร้างขึ้นเอง Monad นําเสนอโซลูชันที่เป็นนวัตกรรมใหม่ที่ใช้ประโยชน์จากความก้าวหน้าทางเทคโนโลยีล่าสุดเพื่อเพิ่มประสิทธิภาพการเข้าถึงและประสิทธิภาพของรัฐ
ทุกบล็อกเชนนำเสนอวิธีการแตกต่างกันในการแก้ไขความท้าทายในการประมวลผลพร้อมกัน ด้วยชุดของการตัดสินใจของตัวเอง การออกแบบของ Solana มุ่งเน้นที่การใช้ประโยชน์จากฮาร์ดแวร์และประสิทธิภาพในการทำงาน ในขณะที่ Sei ให้ความสำคัญกับการลดความยุ่งเหยของกระบวนการพัฒนา และ Monad ย้ำถึงการให้ความสำคัญกับการแก้ปัญหาฐานข้อมูลที่ทันสมัยสำหรับข้อมูลบล็อกเชน ความแตกต่างเหล่านี้ย้ำถึงความหลากหลายในระบบนิเวศบล็อกเชนและความสำคัญของการเลือกแพลตฟอร์มที่เหมาะสมตามความต้องการเฉพาะของแอปพลิเคชัน
เนื่องจากพื้นที่บล็อกเชนยังคงเริ่มต้นการพัฒนาต่อไป ความคืบหน้าในเทคนิคการขนานนามที่ได้รับการสาธิตโดย Solana, Monad, และ Sei อย่างไม่น่าสงสารจะกระตุ้นนวัตกรรมต่อไป การต่อสู้สู่บล็อกเชนที่มีประสิทธิภาพมากขึ้น สามารถขยายขึ้นได้ และเป็นมิตรต่อนักพัฒนาต่อไป ยังคงอยู่ระหว่างการดำเนินการ และบทเรียนที่เรียนรู้จากแพลตฟอร์มเหล่านี้จะเล่นบทบาทสำคัญในการรูปร่างอนาคตของเทคโนโลยีบล็อกเชน
ในส่วนที่ II ของซีรีส์นี้ เราจะลงจริงในผลกระทบทางเศรษฐกิจและการต่อรองที่เกี่ยวข้องกับระบบการออกแบบแบบขนานเหล่านี้