EVM ของ Ethereum เผชิญกับปัญหาด้านประสิทธิภาพที่รุนแรงเนื่องจากสถาปัตยกรรมแบบเธรดเดียว โดยเฉพาะอย่างยิ่งเมื่อจัดการธุรกรรมที่มีปริมาณสูงพร้อมกัน วิธีดำเนินการแบบอนุกรมนี้จำกัดปริมาณงานของเครือข่าย ทำให้ความเร็วในการประมวลผลอยู่ห่างไกลจากความต้องการของผู้ใช้ที่เพิ่มขึ้น ด้วยการวิเคราะห์กระบวนการทั้งหมดของการดำเนินการแบบอนุกรม EVM ทีละขั้นตอน เราค้นพบปัญหาซอฟต์แวร์หลักสองประการสำหรับ Ethereum เพื่อให้บรรลุการดำเนินการแบบคู่ขนาน: 1. การระบุสถานะ 2. สถาปัตยกรรมข้อมูลและการใช้ IPOS เพื่อแก้ไขปัญหาทั้งสองนี้ แต่ละบริษัทมีสิ่งเหล่านี้ เป็นเจ้าของโซลูชันและเผชิญกับข้อเสียหลายประการ รวมถึงไม่ว่าจะเข้ากันได้กับ EVM หรือไม่ ระบุว่าจะใช้ความขนานในแง่ดีหรือแง่ร้าย สถาปัตยกรรมข้อมูลของฐานข้อมูล ว่าจะใช้ช่องทางที่มีประสิทธิภาพหน่วยความจำมากขึ้นหรือฮาร์ดดิสก์ที่มีการทำงานพร้อมกันสูง ประสบการณ์การพัฒนาของนักพัฒนา และข้อกำหนดด้านฮาร์ดแวร์ สถาปัตยกรรมแบบโมดูลาร์หรือแบบลูกโซ่ขนาดใหญ่ ทั้งหมดนี้คุ้มค่ากับการชั่งน้ำหนักอย่างระมัดระวัง
นอกจากนี้เรายังสังเกตเห็นว่าแม้ว่าการดำเนินการแบบขนานดูเหมือนจะขยายบล็อกเชนแบบทวีคูณ แต่ก็ยังมีปัญหาคอขวดอยู่ในระบบแบบกระจาย รวมถึงปัญหาต่างๆ เช่น เครือข่าย P2P และปริมาณงานของฐานข้อมูลเอง การประมวลผลบล็อคเชนยังคงมีหนทางอีกยาวไกลก่อนที่จะสามารถเข้าถึงพลังการประมวลผลของคอมพิวเตอร์แบบเดิมได้ ในปัจจุบัน การดำเนินการแบบขนานเองก็ประสบปัญหาบางประการเช่นกัน รวมถึงความต้องการฮาร์ดแวร์ที่สูงขึ้นสำหรับการดำเนินการแบบขนาน ความเสี่ยงของการรวมศูนย์และการเซ็นเซอร์ที่เกิดจากโหนดที่มีความเชี่ยวชาญมากขึ้น และการออกแบบกลไกที่อาศัยหน่วยความจำ คลัสเตอร์กลาง หรือโหนดก็จะเช่นกัน ในขณะเดียวกัน การสื่อสารข้ามสายโซ่ระหว่างบล็อกเชนคู่ขนานก็อาจมีความเสี่ยงในการหยุดทำงานเช่นกัน สิ่งนี้ยังคงคุ้มค่าที่จะสำรวจโดยทีมอื่น ๆ
จากสถาปัตยกรรมของแต่ละบริษัทและการคิดเกี่ยวกับความเข้ากันได้ของ EVM เรารู้ว่านวัตกรรมที่พลิกโฉมมาจากการไม่ประนีประนอมในอดีต เทคโนโลยีบล็อคเชนยังอยู่ในช่วงเริ่มต้น และการปรับปรุงประสิทธิภาพยังห่างไกลจากจุดสิ้นสุด เราแทบจะรอไม่ไหวที่จะเห็นผู้ประกอบการจำนวนมากขึ้นที่ไม่เต็มใจที่จะประนีประนอมและไม่ปฏิบัติตามกฎเกณฑ์ใด ๆ เพื่อสร้างผลิตภัณฑ์ที่ทรงพลังและน่าสนใจยิ่งขึ้น
ปัญหาเธรดเดียวของ Ethereum
Ethereum EVM ได้รับการวิพากษ์วิจารณ์ถึงประสิทธิภาพของมันมาโดยตลอด สาเหตุหลักมาจากการออกแบบสถาปัตยกรรมที่ล้าหลัง ซึ่งปัญหาของการไม่รองรับการทำงานแบบขนานถือเป็นปัญหาที่ร้ายแรงที่สุด สำหรับการทำธุรกรรมแบบขนานนั้นเทียบเท่ากับการเปลี่ยนถนนให้เป็นทางวิ่งหลายทาง ซึ่งสามารถนำมาซึ่งการปรับปรุงแบบทวีคูณให้กับการจราจรที่สามารถรองรับได้บนถนน
เมื่อเจาะลึกเข้าไปใน Ethereum เทียบกับพื้นหลังของการแยกเลเยอร์การดำเนินการและเลเยอร์ฉันทามติในปัจจุบัน เราจะพบว่าการประมวลผลธุรกรรมทั้งหมดของ EVM นั้นเป็นการดำเนินการแบบอนุกรม
กระบวนการดำเนินธุรกรรมของ Ethereum
ในธุรกรรม Ethereum ผู้ใช้ส่งธุรกรรมไปยัง Mempool ผ่าน RPC ก่อน จากนั้นตัวสร้างจะเลือกธุรกรรมที่เพิ่มผลกำไรสูงสุดและเรียงลำดับ ในขณะนี้ ลำดับของธุรกรรมได้รับการพิจารณาแล้ว ผู้เสนอจะออกอากาศธุรกรรมไปยังชั้นฉันทามติ และชั้นฉันทามติจะกำหนดความถูกต้องของบล็อก เช่น จากผู้ส่งที่ถูกต้อง ธุรกรรมในบล็อกจะถูกส่งไปยังเลเยอร์การดำเนินการเป็นโหลดการดำเนินการ และเลเยอร์การดำเนินการจะดำเนินการธุรกรรม กระบวนการสั้น ๆ ในการดำเนินการธุรกรรมมีดังนี้: (นำอลิซส่ง 1 ETH ไปให้ Bob เป็นตัวอย่าง)
1. ใน EVM ของโหนดการดำเนินการ มันจะแปลงคำสั่งธุรกรรม NO.0 ให้เป็นโค้ด OPcode ที่ EVM สามารถรับรู้ได้
2. จากนั้น กำหนดก๊าซที่จำเป็นสำหรับการทำธุรกรรมนี้โดยยึดตามการเข้ารหัสแบบฮาร์ดโค้ด OPcode
3. ในระหว่างการดำเนินการธุรกรรม คุณต้องเข้าถึงฐานข้อมูลเพื่อรับสถานะยอดคงเหลือของ Alice และ Bob จากนั้นดำเนินการ opcode ของธุรกรรมเพื่อให้ทราบว่ายอดคงเหลือของ Alice คือลบหนึ่งและยอดคงเหลือของ Bob คือบวกหนึ่ง และเขียน/อัปเดต สถานะยอดคงเหลือนี้ไปยังฐานข้อมูล
4. จากบล็อก ให้นำธุรกรรมหมายเลข 1 ออกและดำเนินการต่อไปตามลำดับในวงจนกว่าธุรกรรมของบล็อกจะเสร็จสมบูรณ์
5. ข้อมูลในฐานข้อมูลส่วนใหญ่จะถูกจัดเก็บในรูปแบบของหมายเลข Merkel หลังจากที่ธุรกรรมทั้งหมดในบล็อกได้รับการดำเนินการตามลำดับในที่สุด สถานะรูท (สถานะบัญชีการจัดเก็บ) รูทธุรกรรม (จัดเก็บลำดับของธุรกรรม) และ ใบเสร็จรับเงินในฐานข้อมูล ราก (ซึ่งเก็บข้อมูลโดยบังเอิญเกี่ยวกับธุรกรรม เช่น สถานะความสำเร็จและค่าธรรมเนียมก๊าซ) จะถูกส่งไปยังชั้นฉันทามติ
6. ชั้นฉันทามติสามารถพิสูจน์ความถูกต้องของธุรกรรมได้อย่างง่ายดายหลังจากได้รับรูทสถานะแล้ว ชั้นการดำเนินการจะส่งข้อมูลการตรวจสอบกลับไปยังชั้นฉันทามติ และตอนนี้บล็อกก็ถือว่าได้รับการตรวจสอบแล้ว
7. ชั้นฉันทามติจะเพิ่มบล็อกไปที่ส่วนหัวของบล็อคเชนของตัวเองและพิสูจน์มัน โดยถ่ายทอดการพิสูจน์ผ่านเครือข่าย
นี่คือกระบวนการทั้งหมดที่เกี่ยวข้องกับการดำเนินการตามลำดับของธุรกรรมภายในบล็อก เหตุผลหลักคือแต่ละธุรกรรมมี NO ของตัวเอง และแต่ละธุรกรรมอาจจำเป็นต้องอ่านสถานะในฐานข้อมูลและเขียนสถานะใหม่ หากไม่ได้ดำเนินการตามลำดับ จะนำไปสู่ความขัดแย้งของรัฐเนื่องจากธุรกรรมบางอย่างขึ้นอยู่กับสถานะของกันและกัน นี่คือสาเหตุที่ MEV เลือกการดำเนินการแบบอนุกรม
ความเรียบง่ายของ MEV ยังหมายความว่าการดำเนินการแบบอนุกรมนำมาซึ่งประสิทธิภาพที่ต่ำมาก ซึ่งเป็นหนึ่งในสาเหตุหลักที่ทำให้ Ethereum มีเพียง TPS สองหลักเท่านั้น ในบริบทการพัฒนาปัจจุบันที่มุ่งเน้นไปที่แอปพลิเคชันของผู้บริโภค EVM ซึ่งเป็นกระบวนทัศน์การออกแบบแบบย้อนหลัง เผชิญกับปัญหาด้านประสิทธิภาพที่ต้องปรับปรุงอย่างเร่งด่วน แม้ว่า EVM ในปัจจุบันได้ก้าวไปสู่แผนงานที่มีเลเยอร์ 2 อย่างสมบูรณ์ แต่ปัญหา EVM เช่น โครงสร้าง MPT trie และความไร้ประสิทธิภาพของฐานข้อมูล เช่น LevelDB ฯลฯ จำเป็นต้องได้รับการแก้ไขอย่างเร่งด่วน
เมื่อปัญหานี้พัฒนาขึ้น หลายโครงการได้เริ่มสร้าง EVM ประสิทธิภาพสูงแบบคู่ขนานเพื่อแก้ไขกระบวนทัศน์การออกแบบเก่าของ Ethereum ผ่านกระบวนการ EVM เราจะเห็นได้ว่ามีปัญหาหลักสองประการที่แก้ไขได้ด้วย EVM ประสิทธิภาพสูง:
1. การแยกสถานะธุรกรรม: เนื่องจากการพึ่งพากันของสถานะ ธุรกรรมจึงต้องดำเนินการตามลำดับ ธุรกรรมที่มีสถานะอิสระจำเป็นต้องแยกออก และธุรกรรมที่ขึ้นอยู่กับสถานะยังคงต้องดำเนินการตามลำดับ จากนั้นจึงสามารถกระจายไปยังหลายคอร์เพื่อการประมวลผลแบบขนานได้
2. การปรับปรุงสถาปัตยกรรมฐานข้อมูล: Ethereum ใช้แผนผัง MPT เนื่องจากธุรกรรมเกี่ยวข้องกับการดำเนินการอ่านจำนวนมาก โดยปกติแล้วจะนำไปสู่การดำเนินการอ่านและเขียนฐานข้อมูลที่สูงมาก นั่นคือข้อกำหนด IOPS (IO ต่อวินาที) ที่สูงมาก SSD ระดับผู้บริโภคทั่วไปไม่สามารถตอบสนองความต้องการนี้ได้
โดยทั่วไป ในโซลูชันการก่อสร้างบล็อกเชนกระแสหลักในปัจจุบัน การปรับปรุงซอฟต์แวร์ให้เหมาะสมมักเกี่ยวข้องกับการแยกสถานะธุรกรรมเพื่อสร้างธุรกรรมแบบขนาน และการเพิ่มประสิทธิภาพฐานข้อมูลเพื่อรองรับการอ่านสถานะธุรกรรมที่เกิดขึ้นพร้อมกันในระดับสูง นอกจากความต้องการประสิทธิภาพสูงแล้ว ความต้องการฮาร์ดแวร์ของโปรเจ็กต์ส่วนใหญ่ยังเพิ่มขึ้นอีกด้วย Ethereum ระมัดระวังอย่างมากเกี่ยวกับการขยายประสิทธิภาพของเลเยอร์ 1 เสมอ เพราะมันหมายถึงการรวมศูนย์และความไม่เสถียร อย่างไรก็ตาม EVM ที่มีประสิทธิภาพสูงในปัจจุบันมักจะละทิ้งพันธนาการเหล่านี้และแนะนำการปรับปรุงซอฟต์แวร์ขั้นสูง การเพิ่มประสิทธิภาพเครือข่าย P2P การสร้างฐานข้อมูลใหม่ และฮาร์ดแวร์ระดับมืออาชีพระดับองค์กร
ปัญหา IOPS ฐานข้อมูลที่ได้รับ
การระบุและการแยกการดำเนินการแบบคู่ขนานนั้นไม่ใช่เรื่องยากที่จะเข้าใจ ปัญหาหลักและการอภิปรายในที่สาธารณะน้อยกว่าคือปัญหา IOPS ของฐานข้อมูล ในบทความนี้ เราจะใช้ตัวอย่างที่เป็นประโยชน์เพื่อให้ผู้อ่านรู้สึกถึงปัญหาที่ซับซ้อนที่ฐานข้อมูลบล็อคเชนต้องเผชิญ
ใน Ethereum นั้น โหนดเต็มได้รับการติดตั้งจริง ๆ ด้วยเครื่องเสมือน ซึ่งถือได้ว่าเป็นคอมพิวเตอร์ธรรมดาของเรา และข้อมูลของเราจะถูกจัดเก็บไว้ในซอฟต์แวร์ระดับมืออาชีพ - ฐานข้อมูล ใช้ซอฟต์แวร์นี้เพื่อจัดการข้อมูลขนาดใหญ่ ข้อมูลอุตสาหกรรมที่แตกต่างกันมีความต้องการที่แตกต่างกันสำหรับฐานข้อมูลประเภทต่างๆ ตัวอย่างเช่น ฐานข้อมูลเวกเตอร์เป็นที่นิยมในด้านต่างๆ เช่น AI ซึ่งมีข้อมูลหลายประเภท ในด้านบล็อกเชน เช่น Ethereum จะใช้ฐานข้อมูลคู่คีย์-ค่าที่ค่อนข้างง่าย
แผนผังของการจัดระเบียบข้อมูล Ethereum ที่มา: Github
โดยปกติแล้วข้อมูลในฐานข้อมูลจะถูกจัดระเบียบร่วมกันในลักษณะนามธรรม และ Ethereum จะอยู่ในรูปแบบของแผนผัง MPT สถานะข้อมูลสุดท้ายของทรี MPT จะสร้างโหนดรูท หากข้อมูลใดๆ เปลี่ยนแปลง โหนดรูทจะเปลี่ยนไป ดังนั้น การใช้ MPT จึงสามารถตรวจสอบความสมบูรณ์ของข้อมูลได้อย่างง่ายดาย
เรามายกตัวอย่างเพื่อสัมผัสถึงการใช้ทรัพยากรของฐานข้อมูลปัจจุบัน:
ใน k-fork Merkle Patricia Tree (MPT) ที่มีโหนดลีฟ n การอัพเดตคู่คีย์-ค่าคู่เดียวต้องใช้การดำเนินการอ่าน O(klog kn) และการดำเนินการเขียน O(log kn) ตัวอย่างเช่น สำหรับ MPT ไบนารีที่มี 16 พันล้านคีย์ (เช่น สถานะบล็อกเชน 1 TB) ซึ่งเท่ากับการดำเนินการอ่านประมาณ 68 รายการและการดำเนินการเขียน 34 รายการ สมมติว่า blockchain ของเราต้องการประมวลผลธุรกรรมการโอน 10,000 รายการต่อวินาที และจำเป็นต้องอัปเดตคีย์-ค่าสามรายการในแผนผังสถานะ รวมเป็น 10,000 x 3 x 68 = 2,040,000 ครั้ง ซึ่งเท่ากับ 2 M IOPS (I/O ต่อ ประการที่สอง) การดำเนินการ (ในทางปฏิบัติ สามารถลดลงได้ตามลำดับความสำคัญผ่านการบีบอัดและการแคช เหลือประมาณ 200,000 IOPS และเราไม่ขยาย) SSD สำหรับผู้บริโภครายใหญ่ในปัจจุบันไม่สามารถรองรับสิ่งนี้ได้ (Intel Optane DC P 580 0X 800 GB มีเพียง 100,000 IOPS)
ปัจจุบันต้นไม้ MPT ประสบปัญหาหลายประการ ได้แก่:
● ปัญหาด้านประสิทธิภาพ: เนื่องจากโครงสร้างแบบต้นไม้ที่มีลำดับชั้น MPT มักจะจำเป็นต้องสำรวจหลายโหนดเมื่ออัปเดตข้อมูล การอัปเดตสถานะแต่ละครั้ง (เช่น การโอนหรือการดำเนินการสัญญาอัจฉริยะ) ต้องใช้การคำนวณแฮชจำนวนมาก และมีประสิทธิภาพต่ำเนื่องจากจำเป็นต้องเข้าถึงโหนดหลายเลเยอร์
● การขยายสถานะ: เมื่อเวลาผ่านไป ข้อมูลสถานะ เช่น สัญญาอัจฉริยะและยอดคงเหลือในบัญชีบนบล็อกเชนจะเพิ่มขึ้นอย่างต่อเนื่อง ทำให้ขนาดของแผนผัง MPT ขยายต่อไป ซึ่งจะส่งผลให้โหนดจำเป็นต้องจัดเก็บข้อมูลมากขึ้นเรื่อยๆ ทำให้เกิดความท้าทายต่อพื้นที่จัดเก็บข้อมูลและโหนดการซิงโครไนซ์
การขยายสถานะ Ethereum (เกี่ยวข้องกับการตัดแต่งสถานะ) ที่มา: Etherscan
● ไม่สามารถจัดการการอัปเดตบางส่วนได้อย่างมีประสิทธิภาพ: เมื่อโหนดปลายสุดในโครงสร้างต้นไม้เปลี่ยนแปลง โหนดตามเส้นทางทั้งหมดจะได้รับผลกระทบ Ethereum MPT จำเป็นต้องคำนวณค่าแฮชทั้งหมดใหม่ตั้งแต่โหนดปลายสุดไปจนถึงโหนดรูท ซึ่งทำให้แม้แต่การเปลี่ยนแปลงสถานะท้องถิ่นจำเป็นต้องได้รับการอัปเดตบนโหนดจำนวนมาก ซึ่งส่งผลต่อประสิทธิภาพการทำงาน
เราจะเห็นได้ว่าปัจจุบัน Ethereum ประสบปัญหามากมายภายใต้ MPT และยังได้เสนอวิธีแก้ปัญหาที่หลากหลาย เช่น การตัดสถานะเพื่อการขยายสถานะ และการสร้าง Verkel Tree ใหม่สำหรับปัญหาด้านประสิทธิภาพ MPT ด้วยการสร้างฐานข้อมูลโครงสร้าง Verkel Tree ใหม่ การลดความลึกของแผนผังเพื่อลดจำนวนการเข้าถึงฐานข้อมูลในระหว่างการอัพเดตบางส่วน และใช้สัญญาผูกมัดเวกเตอร์ (โดยหลักแล้วข้อผูกพัน KZG) เพื่อลดขนาดของการพิสูจน์และจำนวนการเข้าถึงฐานข้อมูล
กล่าวโดยสรุป แผนผัง MPT ที่ผ่านมาเกี่ยวข้องและเก่าเกินไปและเผชิญกับความท้าทายใหม่ๆ มากมาย ดังนั้นจึงรวมการเปลี่ยนแปลงวิธีการจัดเก็บข้อมูล เช่น การใช้แผนผัง Verkel ไว้ในแผนงานด้วย แต่นี่เป็นเพียงการแก้ไขที่อ่อนแอมาก และยังคงไม่เกี่ยวข้องกับการดำเนินการแบบขนานและโซลูชันสำหรับ IOPS สูงซึ่งจำเป็นภายใต้การทำงานพร้อมกันสูง
เชนสาธารณะใหม่มาพร้อมกับการดำเนินการแบบขนานเป็นมาตรฐาน
ดังที่เราได้กล่าวไปแล้วในส่วนที่แล้ว การดำเนินการแบบขนานหมายถึงการเปลี่ยนจากเลนเดียวเป็นหลายเลน ที่ทางแยกหลายเลน มิดเดิลแวร์ เช่น การประสานงานสัญญาณไฟจราจร มักจะจำเป็นในการส่งข้อมูลเพื่อให้แต่ละเลนสามารถผ่านไปได้อย่างราบรื่น เช่นเดียวกับ blockchain ในการทำธุรกรรมแบบคู่ขนาน เราจำเป็นต้องส่งธุรกรรมของผู้ใช้ผ่านมิดเดิลแวร์ที่ระบุสถานะ เพื่อให้สามารถแยกธุรกรรมที่มีสถานะที่ไม่เกี่ยวข้องออกเพื่อให้เกิดการดำเนินการแบบคู่ขนานได้ TPS ที่สูงเกิดขึ้นจากการดำเนินการแบบคู่ขนาน ข้อกำหนดสำหรับฐานข้อมูลพื้นฐาน เลเยอร์ 1 ใหม่เกือบทั้งหมดมีการดำเนินการแบบขนานเป็นคุณสมบัติมาตรฐาน
มีหลายวิธีในการจำแนกโซลูชันการดำเนินการแบบขนาน ตามเครื่องเสมือนพื้นฐาน แบ่งออกเป็น EVM (Sei, MegaETH, Monad) และ None-EVM (Solana, Aptos, Sui) ตามวิธีการแยกสถานะธุรกรรม สามารถแบ่งออกเป็นการดำเนินการในแง่ดี (สมมติว่าธุรกรรมทั้งหมดไม่ต้องการให้ทำ และหากสถานะขัดแย้งกัน ส่วนนี้ของธุรกรรมจะถูกย้อนกลับและดำเนินการใหม่) และก่อนกำหนด ประกาศ (ผู้พัฒนาจำเป็นต้องประกาศข้อมูลสถานะการเข้าถึงในโปรแกรม) การจำแนกประเภทเหล่านี้ยังหมายความถึงการแลกเปลี่ยนด้วย
ต่อไป เราจะไม่แบ่งตามว่าเป็น EVM หรือไม่ แต่เพียงเปรียบเทียบการปรับปรุงการแยกสถานะและฐานข้อมูลของห่วงโซ่สาธารณะแต่ละแห่ง
เมกะETH
MegaETH นั้นเป็นบล็อกเชนที่มีความหลากหลายอย่างเคร่งครัดโดยมีเป้าหมายหลักคือประสิทธิภาพ โดยอาศัยความปลอดภัยของ Ethereum โดยใช้ EigenDA เป็นเลเยอร์ฉันทามติและเลเยอร์ DA ในฐานะเลเยอร์การดำเนินการ มันจะเพิ่มประสิทธิภาพฮาร์ดแวร์ให้สูงสุดและปรับปรุง TPS
มีวิธีการปรับให้เหมาะสมสามประเภทสำหรับการประมวลผลธุรกรรม:
1. การแยกสถานะ: การสร้างบล็อกสตรีมมิ่งโดยใช้ลำดับความสำคัญของธุรกรรม โมเดลนี้คล้ายกับ POS ของ Solana จริงๆ แล้ว ธุรกรรมของ Solana นั้นถูกสร้างขึ้นในลักษณะสตรีมมิ่งเช่นกัน แต่ Solana ไม่มีลำดับความสำคัญและทั้งหมดแข่งขันกันที่ความเร็ว และ MegaETH ต้องการสร้างอัลกอริธึมการจัดลำดับความสำคัญสำหรับธุรกรรม
2. ฐานข้อมูล: เพื่อแก้ปัญหา MPT Trie จึงได้สร้างโครงสร้างข้อมูลใหม่เพื่อให้ IOPS สูงขึ้น เมื่อเราตรวจสอบฐานโค้ดของ MegaETH เราพบว่ามันอ้างอิงถึงวิธีการออกแบบของ Verkel Trie ด้วย
3. ความเชี่ยวชาญด้านฮาร์ดแวร์: การประมวลผลในหน่วยความจำจะถูกนำไปใช้เพื่อปรับปรุงประสิทธิภาพ IO อย่างมีนัยสำคัญ โดยการรวมศูนย์และความเชี่ยวชาญพิเศษของเครื่องคัดแยก
ในความเป็นจริง MegaETH หวังที่จะมอบความไว้วางใจในการรักษาความปลอดภัยและการต่อต้านการเซ็นเซอร์ให้กับ Ethereum ในฐานะเลเยอร์ 2 เพื่อที่จะสามารถปรับโหนดให้เหมาะสมได้สูงสุด และให้แน่ใจว่าตัวซีเควนเซอร์จะไม่ทำสิ่งชั่วร้ายผ่านความปลอดภัยทางเศรษฐกิจของ POS มีหลายจุดที่คุ้มค่ากับ Chanllenge ที่นี่ . แต่เราไม่ทำการขยาย แม้ว่า MegaETH กำลังสร้างธุรกรรมสำหรับการดำเนินการแบบขนาน แต่ในความเป็นจริงแล้ว ในปัจจุบันไม่ได้ใช้การดำเนินการแบบขนาน โดยหวังว่าจะเพิ่มประสิทธิภาพของโหนดตัวเรียงลำดับเดียวเพื่อขยายประสิทธิภาพด้วยฮาร์ดแวร์ในระดับสูงสุด จากนั้นจึงขยายประสิทธิภาพผ่านการดำเนินการแบบขนาน
โมนาด
Monad แตกต่างจาก MegaETH ตรงที่เป็นเครือข่ายที่แยกจากกัน ซึ่งตรงตามจุดสำคัญสองจุดที่เราแนะนำ ซึ่งจำเป็นต้องได้รับการปรับให้เหมาะสมสำหรับการดำเนินการแบบขนาน การแยกสถานะของการดำเนินการแบบขนาน และการสร้างฐานข้อมูลใหม่ เราอธิบายโดยย่อถึงวิธีการเฉพาะที่ Monad ใช้:
● การดำเนินการแบบขนานในแง่ดี: สำหรับการระบุธุรกรรม สถานะเริ่มต้นแบบคลาสสิกที่สุดของธุรกรรมทั้งหมดจะไม่ถูกปิด เมื่อพบข้อขัดแย้งของสถานะ ธุรกรรมจะถูกเรียกใช้ใหม่ ปัจจุบันวิธีนี้ใช้ในกลไก Block-STM ของ Aptos . ใช้งานได้ดี.
● การสร้างฐานข้อมูลใหม่: เพื่อปรับปรุง IOPS ของฐานข้อมูล Monad จะสร้างโครงสร้างข้อมูลที่เข้ากันได้กับ EVM ขึ้นใหม่ MPT (Merkel Patricia Tree) Monad ใช้โครงสร้างข้อมูลที่เข้ากันได้กับ Patricia Tree และรองรับ I/O แบบอะซิงโครนัสฐานข้อมูลล่าสุดซึ่งสามารถทำได้ รองรับการอ่านสถานะบางอย่างโดยไม่ต้องรอให้เขียนข้อมูลเสร็จ
● การดำเนินการแบบอะซิงโครนัส: บน Ethereum แม้ว่าเราจะระบุเลเยอร์ฉันทามติและเลเยอร์การดำเนินการที่เฉพาะเจาะจงอย่างเคร่งครัด แต่เราพบว่าเลเยอร์ฉันทามติและเลเยอร์การดำเนินการ (ซึ่งแตกต่างจากแนวคิดของเลเยอร์ 2 เป็นเลเยอร์การดำเนินการ) ในที่นี้หมายถึง Ethereum ยังคงต้องการ โหนดการดำเนินการ (เพื่อดำเนินการธุรกรรมบน Ethereum) ยังคงเชื่อมโยงเข้าด้วยกัน และการดำเนินการจะให้ Merkel Root ที่อัปเดตหลังจากดำเนินการตามฉันทามติ เพื่อให้ชั้นฉันทามติสามารถลงคะแนนเพื่อให้ได้ฉันทามติ Monads พิจารณาว่ารัฐจะได้รับการชำระบัญชีทันทีที่การเรียงลำดับเสร็จสิ้น ดังนั้นจึงจำเป็นต้องมีฉันทามติเกี่ยวกับธุรกรรมที่เรียงลำดับเท่านั้น ไม่มีแม้แต่การดำเนินการเพื่อเปิดเผยผลลัพธ์นี้ แนวคิดนี้ช่วยให้ Monad สามารถแยกชั้นฉันทามติและชั้นการดำเนินการได้อย่างชาญฉลาด เพื่อให้บรรลุการดำเนินการฉันทามติพร้อมกัน โหนดสามารถทำธุรกรรมในบล็อก N-1 ในขณะที่ยังคงลงคะแนนเสียงเป็นเอกฉันท์ในบล็อก N
แน่นอนว่า Monad ยังมีเทคโนโลยีอื่นๆ อีกมากมาย รวมถึงอัลกอริธึมใหม่ที่เป็นเอกฉันท์ MonadBFT ซึ่งร่วมกันสร้าง EVM Layer 1 แบบขนานที่มีประสิทธิภาพสูง
แอปทอส
Aptos ถูกแยกออกจากทีม Diem ของ Facebook โดย It และ Sui ถือเป็นคู่ดูโอ้ Move อย่างไรก็ตาม เนื่องจากความไม่สอดคล้องกันในแนวคิดทางเทคนิคระหว่างทั้งสอง ภาษาของ Move ในปัจจุบันจึงแตกต่างกันมาก Aptos มันเป็นไปตามการออกแบบดั้งเดิมของ Diem อย่างใกล้ชิดยิ่งขึ้น และ Sui ได้ทำการเปลี่ยนแปลงการออกแบบครั้งใหญ่
ปัญหาที่ต้องแก้ไขสำหรับการดำเนินการแบบขนาน:
● การระบุสถานะ: การดำเนินการแบบขนานในแง่ดี Aptos ได้พัฒนากลไกการดำเนินการแบบขนาน Block-STM ซึ่งดำเนินการธุรกรรมในแง่ดีตามค่าเริ่มต้น หากพบข้อขัดแย้งด้านสถานะ ระบบจะดำเนินการอีกครั้ง ปัจจุบันเทคโนโลยีนี้ได้รับการยอมรับโดยทั่วไปแล้ว เช่น Polygon, Monad, Sei และ StarkNet ต่างก็ใช้เทคโนโลยีนี้
● การปรับปรุง IO: Block-STM ใช้โครงสร้างข้อมูลหลายเวอร์ชันเพื่อหลีกเลี่ยงความขัดแย้งของสถานะ ตัวอย่างเช่น สมมติว่าพวกเราที่เหลือกำลังเขียนฐานข้อมูล โดยปกติแล้วเราจะไม่สามารถเข้าถึงฐานข้อมูลได้เนื่องจากเราจำเป็นต้องหลีกเลี่ยงความขัดแย้งของข้อมูล แต่โครงสร้างข้อมูลแบบหลายเวอร์ชันทำให้เราสามารถเข้าถึงเวอร์ชันที่ผ่านมาได้ ปัญหาคือโซลูชันนี้จะทำให้เกิดการใช้ทรัพยากรจำนวนมาก เนื่องจากคุณจำเป็นต้องสร้างเวอร์ชันที่มองเห็นได้สำหรับแต่ละเธรด
● การดำเนินการแบบอะซิงโครนัส: เช่นเดียวกับ Monad การแพร่กระจายธุรกรรม การสั่งซื้อธุรกรรม การดำเนินการธุรกรรม การจัดเก็บสถานะ และการตรวจสอบบล็อก ล้วนดำเนินการพร้อมกัน
ปัจจุบัน Block-STM ได้รับการยอมรับจากเครือข่ายสาธารณะส่วนใหญ่ และ Monad กล่าวว่าด้วยการเกิดขึ้นของเทคโนโลยีนี้ ทำให้สามารถบรรเทาแรงกดดันต่อนักพัฒนาได้อย่างมีประสิทธิภาพ อย่างไรก็ตาม ปัญหาที่ Aptos ต้องเผชิญก็คือความฉลาดของ Block-STM นำมาซึ่งปัญหาความต้องการโหนดที่มากเกินไปต้องใช้ฮาร์ดแวร์พิเศษและการรวมศูนย์เพื่อแก้ไขปัญหานี้
ซุย
ซุยก็เหมือนกับแอปโทส ที่สืบทอดมาจากโครงการ Diem ในทางตรงกันข้าม Sui ใช้การขนานกันในแง่ร้าย ตรวจสอบการพึ่งพาสถานะระหว่างธุรกรรมอย่างเคร่งครัด และใช้กลไกการล็อคเพื่อป้องกันความขัดแย้งระหว่างการดำเนินการ Aptos หวังที่จะลดภาระการพัฒนาของนักพัฒนา
● การระบุสถานะ: ต่างจาก Aptosb ตรงที่มีการนำการทำขนานในแง่ร้ายมาใช้ ดังนั้นนักพัฒนาจำเป็นต้องประกาศการเข้าถึงสถานะของตนเอง แทนที่จะปล่อยการระบุสถานะแบบขนานให้กับระบบเพื่อการประมวลผล ซึ่งจะเพิ่มภาระการพัฒนาของนักพัฒนาและลดความซับซ้อนของการออกแบบระบบด้วย เพิ่มความสามารถในการขนาน
● การปรับปรุง IO: ปัจจุบันการปรับปรุง IO เป็นเรื่องเกี่ยวกับการปรับปรุงโมเดลเป็นหลัก Ethereum ใช้โมเดลตามบัญชี และแต่ละบัญชีจะเก็บรักษาข้อมูลไว้ อย่างไรก็ตาม Sui ใช้โครงสร้างของออบเจ็กต์แทนโมเดลบัญชี การปรับปรุงสถาปัตยกรรมนี้จะมีความสำคัญ ส่งผลต่อความยากในการใช้งานแบบขนานด้วยประสิทธิภาพสูงสุด
เนื่องจาก Sui ไม่มีมรดกทางประวัติศาสตร์ของ EVM และไม่มีปัญหาด้านความเข้ากันได้ จึงได้ทำการเปลี่ยนแปลงอย่างมากตามระบบ Move สำหรับโมเดลบัญชี ยังได้เสนอแนวคิดที่เป็นนวัตกรรมใหม่ ๆ อีกด้วย นวัตกรรมประเภทนี้ในระดับนามธรรมนั้นยากกว่าจริงๆ อย่างไรก็ตาม โมเดล Objects ก่อให้เกิดประโยชน์มากมายต่อการประมวลผลแบบขนาน นอกจากนี้ เนื่องจากโมเดล Objects ได้สร้างสถาปัตยกรรมเครือข่ายที่มีเอกลักษณ์เฉพาะตัวซึ่งสามารถขยายได้ตามทฤษฎีอย่างไม่มีที่สิ้นสุด
โซลาน่า - นักเต้นไฟ
Solana ถือเป็นผู้บุกเบิกด้านการประมวลผลแบบคู่ขนาน ปรัชญาของ Solana คือระบบบล็อกเชนควรก้าวหน้าไปพร้อมกับความก้าวหน้าของฮาร์ดแวร์ ต่อไปนี้คือวิธีการประมวลผลแบบขนานในปัจจุบันของ Solana:
● การรับรู้สถานะ: เช่นเดียวกับ SUI โซลานายังใช้ความเท่าเทียมเชิงกำหนด ซึ่งมาจากประสบการณ์ในอดีตของ Anatoly ในการจัดการกับระบบฝังตัว ซึ่งโดยปกติแล้วสถานะทั้งหมดจะถูกประกาศล่วงหน้า ซึ่งช่วยให้ CPU รู้การขึ้นต่อกันทั้งหมด ทำให้สามารถโหลดส่วนที่จำเป็นของหน่วยความจำล่วงหน้าได้ ผลลัพธ์ที่ได้คือการทำงานของระบบที่ได้รับการปรับปรุงให้เหมาะสม แต่ขอย้ำอีกครั้งว่านักพัฒนาจำเป็นต้องทำงานพิเศษล่วงหน้า บน Solana จำเป็นต้องมีการขึ้นต่อกันของหน่วยความจำทั้งหมดของโปรแกรมและประกาศในธุรกรรมที่สร้างขึ้น (เช่น รายการเข้าถึง) ช่วยให้รันไทม์กำหนดเวลาและดำเนินการธุรกรรมหลายรายการพร้อมกันได้อย่างมีประสิทธิภาพ
● ฐานข้อมูล: Solana ใช้ Cloudbreak เพื่อสร้างฐานข้อมูลบัญชีที่กำหนดเอง ซึ่งใช้บัญชีเป็นแบบอย่าง ข้อมูลบัญชีจะถูกกระจายไปยัง ส่วนย่อย หลายส่วน คล้ายกับการแบ่งไลบรารีออกเป็นหลายชั้น และสามารถอิงตามได้ จำเป็นต้อง เพิ่มหรือลดจำนวนชั้นสำหรับการทำโหลดบาลานซ์ โดยจะถูกแมปเข้ากับหน่วยความจำบน SSD ดังนั้น SSD จึงสามารถดำเนินการได้อย่างรวดเร็วผ่านหน่วยความจำผ่านการออกแบบไปป์ไลน์ นอกจากนี้ยังรองรับการเข้าถึงข้อมูลหลายรายการแบบขนาน และสามารถประมวลผลการดำเนินการ 32 IO แบบขนานได้ในเวลาเดียวกัน
โซลานาต้องการให้นักพัฒนาประกาศสถานะที่พวกเขาต้องการในการเข้าถึงผ่านระบบขนานที่กำหนดขึ้น ซึ่งคล้ายกับสถานการณ์การเปลี่ยนแปลงแบบเดิมๆ จริงๆ ในแง่ของการสร้างโปรแกรม นักพัฒนาจำเป็นต้องสร้างแอปพลิเคชันแบบขนานด้วยตนเอง ในขณะที่การกำหนดเวลาโปรแกรมและไปป์ไลน์แบบอะซิงโครนัสแบบรันไทม์จำเป็นต้องมี โครงการจำเป็นต้องสร้าง ในแง่ของฐานข้อมูลจะสร้าง DataBase ของตัวเองสำหรับการทำข้อมูลแบบขนานเพื่อปรับปรุง IPOS
ในเวลาเดียวกัน Firedancer ซึ่งเป็นลูกค้าสำหรับการปรับปรุง Solana ครั้งต่อๆ ไป ได้รับการขับเคลื่อนและพัฒนาโดย Jump Trading ซึ่งเป็นบริษัทยักษ์ใหญ่ด้านปริมาณที่มีความสามารถด้านวิศวกรรมที่แข็งแกร่งมาก โดยมีวิสัยทัศน์เช่นเดียวกับ Solana โดยมีเป้าหมายในการขจัดความไร้ประสิทธิภาพของซอฟต์แวร์และผลักดันประสิทธิภาพให้สูงขึ้น ฮาร์ดแวร์ การปรับปรุงมุ่งเน้นไปที่การปรับปรุงฮาร์ดแวร์พื้นฐานเป็นหลัก รวมถึงการแพร่กระจาย P2P การประมวลผลข้อมูล SIMD แบบขนานของฮาร์ดแวร์ ฯลฯ ซึ่งคล้ายกับแนวคิดของ MegaETH มาก
เซย์
เซย์ใช้อยู่ครับ
● การดำเนินการคู่ขนานในแง่ดี: อ้างอิงจากการออกแบบ Block-STM ของ Aptos เวอร์ชัน Sei V1 ใช้รูปแบบความขนานแบบพาสซีฟที่คล้ายคลึงกับ Sui และ Solana ซึ่งกำหนดให้นักพัฒนาต้องประกาศวัตถุที่พวกเขาใช้ อย่างไรก็ตาม หลังจาก Sei V2 ก็เปลี่ยนไปเป็นรูปแบบความเท่าเทียมในแง่ดีของ Aptos สิ่งนี้จะช่วย Sei ซึ่งอาจขาดนักพัฒนา และสามารถโยกย้ายสัญญาจากระบบนิเวศ EVM ได้ง่ายขึ้น
การออกแบบ SeiDB ที่มา: Sei
● SeiDB: โซลูชันฐานข้อมูลทั้งหมดสร้างขึ้นตามข้อเสนอ ADR-065 ของ Cosmos โครงสร้างข้อมูลได้รับการออกแบบมาเพื่อแบ่งข้อมูลออกเป็นข้อมูลที่ใช้งานและข้อมูลประวัติ ในเวลาเดียวกัน ข้อมูล SSD จะใช้โครงสร้างแผนผัง MemIAVL ในขณะที่ข้อมูลหน่วยความจำใช้แผนผัง IAVL (ประดิษฐ์โดย Cronos) สำหรับข้อผูกพันของรัฐ ซึ่งจัดเตรียมรากสถานะสำหรับการดำเนินการฉันทามติ แนวคิดเชิงนามธรรมของ MemIAVL คือทุกครั้งที่มีการส่งบล็อกใหม่ เราจะดึงชุดของการเปลี่ยนแปลงทั้งหมดจากธุรกรรมของบล็อกนั้น และใช้การเปลี่ยนแปลงเหล่านั้นกับแผนผัง IAVL ในหน่วยความจำปัจจุบัน ดังนั้นจะสร้างเวอร์ชันใหม่ของแผนผัง สำหรับบล็อกล่าสุด เพื่อที่เราจะได้รับ Merkle root hash ของบล็อกที่คอมมิต ดังนั้นจึงเทียบเท่ากับการใช้หน่วยความจำสำหรับการอัปเดตด่วน ซึ่งช่วยให้การเข้าถึงสถานะส่วนใหญ่อยู่ในหน่วยความจำแทน SSD ดังนั้นจึงปรับปรุง IOPS
ปัญหาหลักของ SeiDB ก็คือ หากข้อมูลที่ใช้งานล่าสุดถูกจัดเก็บไว้ในหน่วยความจำ ข้อมูลจะสูญหายระหว่างเวลาหยุดทำงาน ดังนั้น MemIAVL จึงแนะนำไฟล์ WAL และ Tree Snapshots ภายในช่วงระยะเวลาหนึ่ง จำเป็นต้องสแนปช็อตข้อมูลในหน่วยความจำและจัดเก็บไว้ในฮาร์ดดิสก์ภายในเครื่อง ควบคุมช่วงเวลาสแนปชอตที่แน่นอนเพื่อควบคุมผลกระทบ OOM ของการขยายข้อมูลในหน่วยความจำในเวลาที่เหมาะสม
การเปรียบเทียบแบบเคียงข้างกัน
ข้อกำหนดโหนดเต็ม
ข้อกำหนดสำหรับการรันโหนดเต็ม
FireDancer มีข้อกำหนดการปฏิบัติงานสูงสุดสำหรับโหนดและสามารถเรียกได้ว่าเป็นสัตว์ประหลาดด้านประสิทธิภาพ ข้อกำหนดด้านประสิทธิภาพหลักของ MegaETH มุ่งเน้นไปที่ข้อกำหนด Sequencer ที่มีคอร์มากกว่า 100 คอร์ เนื่องจากการมีอยู่ของตัวจัดลำดับโหนดแบบรวมศูนย์ ข้อกำหนดสำหรับโหนดแบบเต็มอื่นๆ จึงไม่สูง ปัจจุบันราคา SSD ค่อนข้างต่ำ ดังนั้นโดยทั่วไปเราจะดูที่ข้อกำหนดด้านประสิทธิภาพของ CPU และหน่วยความจำเท่านั้น เราจัดอันดับข้อกำหนดด้านประสิทธิภาพของโหนดแบบเต็มจากสูงไปต่ำ: Firedancer > Sei > Monad > Sui > Aptos > MegaETH > Ethereum
วางแผน
สำหรับโซลูชันการประมวลผลแบบขนานในปัจจุบัน โดยทั่วไปแล้ว การเพิ่มประสิทธิภาพของเราในระดับซอฟต์แวร์จะมุ่งเน้นไปที่ 1. ปัญหาการใช้ IOPS ของฐานข้อมูล 2. ปัญหาการระบุสถานะ และ 3. ปัญหาไปป์ไลน์อะซิงโครนัส ทั้งสามประเด็นนี้ใช้เพื่อเพิ่มประสิทธิภาพระดับซอฟต์แวร์ ปัจจุบันการรับรู้ของรัฐแบ่งออกเป็นสองค่าย ได้แก่ การดำเนินการคู่ขนานในแง่ดีและการเขียนโปรแกรมที่เปิดเผย ทั้งสองอย่างนี้มีข้อดีและข้อเสีย การดำเนินการแบบคู่ขนานในแง่ดีนั้นส่วนใหญ่ใช้โซลูชัน Block-STM ของ Aptos คล้ายกับกระบวนทัศน์การเขียนโปรแกรมแบบพร้อมกันหรือแบบอะซิงโครนัสแบบดั้งเดิม สำหรับปัญหาการใช้ IPOS ของฐานข้อมูลนั้น แต่ละบริษัทมีแนวทางแก้ไขที่แตกต่างกัน:
การเปรียบเทียบแผน
ในส่วนของโครงสร้างข้อมูลเราเห็นจุดที่น่าสนใจ Monad วางอยู่บน SSD มากที่สุดเท่าที่จะเป็นไปได้ แต่ความเร็วในการอ่านของฮาร์ดดิสก์นั้นต่ำกว่าของ Memory มาก แต่ราคาก็ถูกกว่ามาก Monad ถูกวางบน SSD โดยพิจารณาจากราคา ขีดจำกัดของฮาร์ดแวร์ และระดับของความขนาน เนื่องจากตอนนี้ SSD สามารถรองรับการทำงานของ I/O ได้ 32 ช่องทาง เพื่อเพิ่มความสามารถแบบขนานมากขึ้น ในทางตรงกันข้าม Solana และ Sei เลือกการแมปหน่วยความจำเนื่องจากหน่วยความจำเร็วกว่า SSD มาก วิธีแรกคือการขยายช่องสัญญาณแบบขนานในแนวนอน และอีกวิธีคือการขยายในแนวตั้งเพื่อลดการใช้ I/O นี่คือสาเหตุที่ข้อกำหนดโหนดสำหรับ Monad คือ 32 GB แต่ Sei และ Solana ต้องการหน่วยความจำเพิ่มเติม
นอกจากนี้ โครงสร้างข้อมูลของ Ethereum ได้มาจาก Merkel Patric Tree ที่พัฒนามาจาก Patrci Tree ดังนั้นเครือข่ายสาธารณะที่เข้ากันได้กับ EVM จะต้องเข้ากันได้กับ Merkel Trie ดังนั้นจึงไม่สามารถสร้างวิธีเชิงนามธรรมในการคิดเกี่ยวกับสินทรัพย์เช่น Aptos Sui, Solana และอื่นๆ Ethereum อิงตามโมเดลบัญชี แต่ Sui เป็นรูปแบบ Objects Solana เป็นรูปแบบบัญชีที่แยกข้อมูลและโค้ด และ Ethereum ก็เชื่อมโยงเข้าด้วยกันอย่างแท้จริง
นวัตกรรมที่ก่อกวนมาจากการไม่ประนีประนอมในอดีต จากมุมมองทางธุรกิจ จำเป็นอย่างยิ่งที่จะต้องคำนึงถึงชุมชนนักพัฒนาและความเข้ากันได้ในอดีตของ EVM
แนวโน้ม
องค์ประกอบการปรับให้เหมาะสมหลักของการดำเนินการแบบขนานในปัจจุบันมีเป้าหมายที่ค่อนข้างชัดเจน โดยเน้นไปที่วิธีการระบุสถานะและวิธีการปรับปรุงความเร็วในการอ่านและจัดเก็บข้อมูลเป็นหลัก เนื่องจากวิธีการจัดเก็บข้อมูลเหล่านี้จะทำให้มีเวลาเพิ่มเติมในการอ่านหรือจัดเก็บชิ้นส่วนของ ข้อมูล ค่าใช้จ่ายและปริมาณการใช้ โดยเฉพาะ Merkel trie นำเสนอการตรวจสอบราก แต่จะทำให้มีค่าใช้จ่าย IO ที่สูงมาก
แม้ว่าการดำเนินการแบบขนานได้ขยายบล็อกเชนแบบทวีคูณ แต่ก็ยังมีปัญหาคอขวดอยู่ในระบบแบบกระจาย รวมถึงเครือข่าย P2P ฐานข้อมูล และปัญหาอื่น ๆ การประมวลผลบล็อคเชนยังคงมีหนทางอีกยาวไกลก่อนที่จะสามารถเข้าถึงพลังการประมวลผลของคอมพิวเตอร์แบบเดิมได้ ในปัจจุบัน การดำเนินการแบบขนานเองก็ประสบปัญหาบางประการเช่นกัน รวมถึงความต้องการฮาร์ดแวร์ที่สูงขึ้นสำหรับการดำเนินการแบบขนาน ความเสี่ยงของการรวมศูนย์และการเซ็นเซอร์ที่เกิดจากโหนดที่มีความเชี่ยวชาญมากขึ้น และการออกแบบกลไกที่อาศัยหน่วยความจำ คลัสเตอร์กลาง หรือโหนดก็จะเช่นกัน ในขณะเดียวกัน การสื่อสารข้ามสายโซ่ระหว่างบล็อกเชนคู่ขนานก็อาจมีความเสี่ยงในการหยุดทำงานเช่นกัน
แม้ว่ายังคงมีปัญหาบางประการเกี่ยวกับการดำเนินการแบบขนาน แต่แต่ละบริษัทก็กำลังสำรวจแนวปฏิบัติทางวิศวกรรมที่ดีที่สุด รวมถึงสถาปัตยกรรมการออกแบบโมดูลาร์ที่นำโดย MegaETH และสถาปัตยกรรมการออกแบบห่วงโซ่เสาหินที่นำโดย Monad รูปแบบการเพิ่มประสิทธิภาพการดำเนินการแบบขนานในปัจจุบันพิสูจน์ให้เห็นแล้วว่าเทคโนโลยีบล็อกเชนกำลังเคลื่อนตัวเข้าใกล้รูปแบบการเพิ่มประสิทธิภาพคอมพิวเตอร์แบบเดิมอย่างต่อเนื่อง และได้รับการปรับปรุงให้เหมาะสมมากขึ้นที่ระดับล่างสุด โดยเฉพาะอย่างยิ่งการเพิ่มประสิทธิภาพโดยละเอียดของการจัดเก็บข้อมูล ฮาร์ดแวร์ ไปป์ไลน์ และเทคโนโลยีอื่น ๆ อย่างไรก็ตาม ประโยคนี้ยังมีคอขวดและปัญหาอยู่ ดังนั้นจึงยังมีพื้นที่สำหรับการสำรวจที่กว้างมากสำหรับผู้ประกอบการ
นวัตกรรมที่พลิกโฉมมาจากการไม่ประนีประนอมกับอดีต และเราแทบรอไม่ไหวที่จะเห็นผู้ประกอบการจำนวนมากขึ้นที่ไม่เต็มใจที่จะประนีประนอมในการสร้างผลิตภัณฑ์ที่ทรงพลังและน่าสนใจยิ่งขึ้น
ข้อสงวนสิทธิ์:
เนื้อหาข้างต้นมีไว้เพื่อการอ้างอิงเท่านั้นและไม่ควรถือเป็นคำแนะนำใดๆ ขอคำแนะนำจากผู้เชี่ยวชาญก่อนตัดสินใจลงทุนเสมอ
เกี่ยวกับ เกต เวนเจอร์
Gate Ventures เป็นบริษัทร่วมลงทุนของ Gate.io โดยมุ่งเน้นไปที่การลงทุนในโครงสร้างพื้นฐานแบบกระจายอำนาจ ระบบนิเวศ และแอปพลิเคชันที่จะเปลี่ยนโฉมโลกในยุค Web 3.0 Gate Ventures ทำงานร่วมกับผู้นำอุตสาหกรรมระดับโลกเพื่อเพิ่มศักยภาพให้กับทีมและสตาร์ทอัพด้วยความคิดสร้างสรรค์และความสามารถในการกำหนดรูปแบบปฏิสัมพันธ์ของสังคมและการเงินใหม่
เว็บไซต์อย่างเป็นทางการ: https://ventures.gate.io/ Twitter: https://x.com/gate_ventures สื่อ: https://medium.com/gate_ventures
