สวัสดี

ประสิทธิภาพในการทำธุรกรรมได้รับความสนใจมากในชุมชน เราได้ศึกษาวิธีการที่ Monad ช่วยในการขยาย TPS ในสัปดาห์ที่ผ่านมา

บันทึกด้านล่างเป็นการแยกอภิปรายถึงวิธีการทำงานของ Monad ที่เขียนโดย @desh_saurabh. พิจารณาที่จะสมัครที่ Gate.ioDecentralised.coถ้าคุณชอบการอ่านข้อมูลที่มีการอธิบายโดยใช้ข้อมูลเป็นพื้นฐานเกี่ยวกับทุกอย่างใน Web3 พบกันที่อีกฝั่งหนึ่งนะคะ!

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

ถ้าเราต้องการเพิ่ม TPS เราควรทำอย่างไร?

1. วิธีหนึ่งคือการสร้างระบบใหม่โดยสิงห์ Solana ทำเช่นนั้น มันเสีย EVM compatibility เพื่อส่วนประโยชน์ของความเร็ว มันใช้การประมวลผลหลายเธร์ดแทนการประมวลผลเดียว (คิดเหมือน CPU หลายคอร์ vs. CPU หนึ่งคอร์) แบ่งการทำธุรกรรมและใช้กลไกการตกลงที่แตกต่าง
2. วิธีที่สองคือการใช้การดำเนินการออกเชนและเพิ่มขนาดของ Ethereum ด้วยตัวจัดลำดับที่มีความสำคัญ
3. ขั้นตอนที่สามคือการแยก EVM เป็นส่วนๆ และปรับปรุงให้ดีขึ้นเพื่อเพิ่มความสามารถในการขยายขอบเขต

Monad, ระบบหนึ่งที่เข้ากันได้กับ EVM ที่ได้รับทุนระดับ $225 ล้านเร็ว ๆ นี้กำลังสร้าง EVM ขึ้นมาใหม่จากพื้นฐานแทนที่จะใช้มันอย่างเดิม มันเลือกวิธีที่สามนี้เพื่อเพิ่มความสามารถในการขยายขอบเขต

เราพูดคุยเกี่ยวกับการเปลี่ยนแปลงบางประการที่ Monad นำเสนอ

การดำเนินการแบบขนาน

Ethereum Virtual Machine (EVM) ดําเนินธุรกรรมอย่างต่อเนื่อง จนกว่าจะมีการดําเนินการธุรกรรมหนึ่งธุรกรรมถัดไปจะต้องรอ คิดแบบนี้ สมมติว่ามีแพลตฟอร์มในคลังสินค้าประกอบรถจักรยานยนต์ รถบรรทุกหลายคันทิ้งชิ้นส่วนรถจักรยานยนต์ (ในลักษณะที่รถบรรทุกแต่ละคันมีชิ้นส่วนทั้งหมดที่จําเป็นในการสร้างรถจักรยานยนต์ 50 คัน) คลังสินค้าแอสเซมบลีทําหน้าที่ที่แตกต่างกันสี่อย่างกับทีมเฉพาะ ได้แก่ การขนถ่ายการคัดแยกการประกอบและการโหลด

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

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

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

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

มันดำเนินการอย่างไร? มันดำเนินการบางสิ่งที่เรียกว่าการดำเนินการแบบเชื่อมั่นเชิงบวก โปรโตคอลสามารถดำเนินการธุรกรรมที่เป็นอิสระได้แบบขนานกัน เช่น พิจารณา 4 ธุรกรรมโดยมียอดคงเหลือของ Joel เป็น 1 ETH -

1. Joel ส่ง 0.2 ETH ถึง Saurabh
2. Sid สร้าง NFT
3. โจเอลส่ง 0.1 ETH ถึงซิด
4. Shlok ซื้อ PEPE

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

โปรดทราบว่าเนื่องจากทุก 4 ธุรกรรมเริ่มต้นจากสถานะเดียวกัน ซึ่งนั้นคือยอดเงินของ Joel ที่มีมูลค่า 1 ETH ที่นี่เราสนใจคือยอดเงินของ Joel ที่เหลืออยู่ 1 ETH และรายได้จาก Joel ส่ง 0.2 ETH ทำให้เหลืออยู่ 0.8 ETH หลังจาก Joel ส่ง 0.1 ETH ให้กับ Sid ยอดเงินของเขาเหลือ 0.9 ETH ผลลัพธ์ถูกยืนยันทีละรายการ เพื่อให้แน่ใจว่ารายได้ไม่ขัดแย้งกับอินพุทใด ๆ หลังจากผลลัพธ์ที่รอดำเนินการเสร็จ Joel ที่เหลืออยู่ใหม่คือ 0.8 ETH

ผลลัพธ์นี้ขัดแย้งกับอินพุตของ 3 ดังนั้นตอนนี้ 3 ถูกดำเนินการใหม่ด้วยอินพุตของ 0.8 ETH หลังจากที่ 3 ถูกดำเนินการเสร็จ Joel จะมียอดคงเหลือ 0.7 ETH

MonadDb

ณจุดนี้คำถามที่ชัดเจนคือเราจะรู้ได้อย่างไรว่าเราจะไม่ต้องทำซ้ำซ้ำในส่วนใหญ่ของธุรกรรม เหตุผลอยู่ที่การทำซ้ำไม่ใช่จุดอ่อน จุดอ่อนคือการเข้าถึงหน่วยความจำของ Ethereum มันกลับออกมาว่าวิธีที่ Ethereum เก็บสถานะของมันในฐานข้อมูลทำให้ยาก (ใช้เวลาและจึงแพง) การเข้าถึงสถานะ นี่คือจุดที่การปรับปรุงอื่น ๆ ของ Monad มาเข้ามาเล่นบทบาท - MonadDb Monad ได้สร้างฐานข้อมูลของตัวเองในลักษณะที่ลดค่าใช้จ่ายเกี่ยวกับการดำเนินการอ่าน

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

Solana มี 50k TPS บนเครือข่ายทดสอบ แต่ในขณะนี้ทำได้ประมาณ 1k บนเครือข่ายหลัก Monad อ้างว่าได้รับ 10k TPS จริงในเครือข่ายทดสอบภายใน อย่างไรก็ตาม นี่ไม่ใช่เสมอไปตามประสิทธิภาพในโลกจริง เราต้องการดู Monad ทำงานในสภาพแวดล้อมจริง

คำแถลง:

1. บทความนี้ชื่อเรื่องว่า 'เข้าใจ Monad' ถูกคัดลอกมาจาก [ chaincatcher]. All copyrights belong to the original author [Decentralised.Co]. If you have any objection to the reprint, please contact the Gate Learn teamทีมจะดำเนินการให้เร็วที่สุด

2. คำประกาศ: มุมมองและความคิดเห็นที่แสดงอยู่ในบทความนี้แทนเพียงความคิดเห็นส่วนบุคคลของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางด้านการลงทุนใด ๆ

3. การแปลบทความเป็นภาษาอื่นๆ นำมาทำโดยทีม Gate Learn หากไม่ได้กล่าวถึง การคัดลอก การกระจาย หรือการลอกเลียนบทความที่ถูกแปลนั้นถือเป็นการละเมิด