![contributedao's tweet photo. Monad Layer 1 : [ กาวกระป๋องใหญ่ ทำไมถึงน่าสนใจในปี 2024 ? ] + How to Contribute with Monad Project
TL : DR [ ยาวไป ไม่อ่าน เลยมาสรุปให้ ]
ปล.ใครอยาก อ่านแบบยาวๆ และรูปฮาๆ เยอะ อ่านได้ที่นี่ : https://t.co/i9R2JKyF6J
1.Monad Layer 1 ที่ถูกออกแบบมาให้เข้ากันได้กับ EVM อย่างสมบูรณ์แบบ ทำให้ Tools , Stack , Programming ที่เป็น EVM สามารถเคลื่อนย้ายมายัง Monad ได้ราวกับกระพริบตา
*พร้อมกับความสามารถ Parallel execution [Monad คือ ETH + Solana]
2.The new innovative of monad ที่เข้ามาแก้ปัญหาของ Web3 Infrastructure เช่น
🔸 แก๊สแพง - Gas costs
🔸 ความความปลอดภัย - Security risks
🔸 ข้อจำกัดของที่เก็บข้อมูล - Limited storage
🔸 ปัญหา Mempool
🔸 การกระจายตัวของสภาพคล่อง - Liquidity Fragmented
🔸 ขาด Resource - Lack of Tools
🔸 Upgradability challenges
🔸 Interoperability issues
- 2.1 MonadBFT = ระบบ Consensus ใหม่ของ Monad ที่ช่วยให้มี TPS มากกว่า 10,000 + และ Finality ที่ต่ำมาก
- 2.2 Defered Execution = การแยก Execution และ Consensus Logic ออกจากกัน ทำให้ทั้งสองสามารถทำงาน พร้อมๆ กันได้
- 2.3 Optimistc Parallel Execution ที่ช่วยให้ Monad สามารถหลีกเลี่ยงการประมวลผลแบบเป็นลำดับที่ซับซ้อนและเตรียม Access List ที่ยุ่งยากได้
- 2.4 MonadDB ซึ่งเป็น Database ที่ถูกออกแบบโดย Monad ให้เหมาะกับโครงสร้างข้อมูลที่ Ethereum ใช้อยู่ รวมทั้งยังช่วยอำนวยความสะดวกในการดำเนินการต่างๆ ที่เป็นแบบ Parallel อีกด้วย
*Cr.picture by Monad community
3.ระดมทุนได้มากกว่า $19m Seedround
4.มีกิจกรรมให้ Contribute [ดูเพิ่มเติมได้ที่ย่อหน้าสุดท้าย]
5.มีมากกว่า 40 projects ที่ confirmed ว่าจะเชื่อมกับ Monad
6. Community First , Deep technology together. [โปรเจคแรกของโลก ที่ Design Project ให้สอดคล้องกับ Web3 Culture คือ Game theory]
***เพียงแค่ จินตนาการว่า มันคือ Deep Tech + Meme + community = กาวกระป๋องใหญ่
7. Good team
@monad_xyz
@keoneHD
@IcedQuad
@zen_llama
@_jhunsaker
@port_dev
@billmondays
____________________________________________
มาดู Research ฉบับเข้าใจง่ายกันเถอะ
Monad Introduction
หากพูดถึงบล็อกเชนที่มีความนิยมสูงสุดคงหนีไม่พ้นบล็อกเชนอย่าง Ethereum ไม่เพียงแต่จะเป็นศูนย์รวมของงานวิจัย, การพัฒนา, dApp และคอมมูนิตี้ต่างๆ แต่ยังถือครอง TVL ที่สูงที่สุดอีกด้วย สิ่งต่างๆ เหล่านี้ได้ตอกย้ำว่า Ethereum นั้นมีบทบาทที่สำคัญต่อโลกของบล็อกเชนเพียงใด อย่างไรก็ตาม Ethereum ก็มีข้อจำกัดที่หลายคนรู้กันดี นั่นก็คือค่าแก๊สที่แพง, TPS (จำนวนธุรกรรมต่อวินาที) ที่ต่ำ และ Finality ที่นาน สิ่งเหล่านี้มีแต่จะทำให้ประสบการณ์ของผู้ใช้งานและนักพัฒนาแย่ลงเรื่อยๆ
ด้วยเหตุนี้โปรเจกต์ต่างๆ จึงแข่งขันกันเพื่อหาแนวทางใหม่ที่จะมาแก้ปัญหาที่ Ethereum ต้องเผชิญ แต่ด้วยการที่เชนใหม่ๆ พัฒนาและใช้เทคโนโลยีที่เหมาะสมกับการทำงานเฉพาะด้านของตน จึงส่งผลให้เกิดผลเสียใหม่ที่ตามมา นั้นก็คือความไม่เข้ากันกับ EVM (ไม่สามารถทำงานเชนที่เป็น EVM ได้ โดยเฉพาะ Ethereum) EVM compatibility หรือความเข้ากันได้กับ EVM นั้นเป็นสิ่งสำคัญ เนื่องจากเครื่องมือในบล็อกเชนที่ใช้งานกันส่วนใหญ่ถูกออกแบบมาให้เหมาะสมกับ EVM และโครงสร้างของ Ethereum ดังนั้นเมื่อบล็อกเชนเลเยอร์ 1 ที่ไม่เข้ากันกับ EVM เกิดขึ้นมาจะนำไปสู่การพัฒนาเครื่องมือใหม่ๆ ทำให้นักพัฒนาและผู้ใช้ต้องปรับตัวเข้ากับสภาพแวดล้อมที่แตกต่างไปจากเดิมอย่างสิ้นเชิง นอกจากนี้ความเข้ากันได้กับ EVM ยังช่วยลดความยุ่งยากในการย้าย dApps ที่มีอยู่แล้วบน Ethereum มายังเชนใหม่ได้โดยที่นักพัฒนาไม่ต้องมาเริ่มนับหนึ่งใหม่ตั้งแต่ต้น
Monad - บล็อกเชนเลเยอร์ 1 ที่มีความเร็วสูง, Finality ที่ต่ำ และเข้ากันได้กับ EVM โดยสมบูรณ์
Monad เป็นบล็อกเชนเลเยอร์หนึ่งที่เข้ากันได้กับ EVM อย่างสมบูรณ์ (Fully EVM compatible) สามารถรองรับจำนวนธุรกรรมต่อวินาทีได้สูง และมี Finality ที่ต่ำ Monad สามารถทำสิ่งเหล่านี้ได้โดยการปรับปรุงประสิทธิภาพใน 4 ด้านหลักๆ คือ
1.MonadBFT
2.Deferred Execution
3.Parallel Execution
4.MonadDb
ฟีเจอร์เหล่านี้ช่วยให้ Monad สามารถรองรับธุรกรรมได้มากถึง 10,000 ธุรกรรมต่อวินาทีและมี Finality อยู่ที่ประมาณ 1 วินาธีเท่านั้น ในบทความนี้เราจะมาเจาะลึกกันว่าแต่ละฟีเจอร์ทำงานอย่างไรและช่วยเพิ่มประสิทธิภาพให้แก่ Monad ได้อย่างไร
1.MonadBFT
ถ้าหากคุณรู้ว่า Tendermint และ Hotstuff ทำงานอย่างไร คุณจะทำความเข้าใจ MonadBFT ได้ง่ายมาก แต่ถ้าไม่รู้จักไม่เป็นไร ในบทความนี้เราจะอธิบายให้ฟังเอง Tendermint เป็น Consensus หลักที่ใช้ในระบบนิเวศของเชน Cosmos ซึ่งการที่ Validator จะตัดสินใจว่าบล็อกไหนนั้นจะถูกเพิ่มเข้าไปบนบล็อกเชนหรือ Commit จะต้องผ่านการโหวตทั้งหมด 3 เฟสด้วยกัน ได้แก่ Propose, Pre-vote และ Pre-commit โดยเริ่มแรกของแต่ละบล็อก Leader (คนที่ถูกเลือกจาก Validator ทั้งหมด) จะเป็นคนที่เสนอบล็อกของตัวเองและส่งไปให้ Validator คนอื่นๆ เมื่อ Validator ได้รับบล็อกแล้วจะทำการโหวตโดยการแลกเปลี่ยนข้อความระหว่าง Validator ด้วยกันเอง เมื่อตกลงกันได้แล้วจึงจะทำการ Commit บล็อกๆ นั้น การที่ Validator โต้ตอบโดยการแลกเปลี่ยนข้อความกันไปกันมานี้ทำให้การสื่อสารมีความซับซ้อนแบบยกกำลังสอง (O(n²)) หรือก็คือ ถ้าหากมี Validator อยู่ n คน Validator 1 คนจะต้องส่งข้อความไปหาคนอื่น n-1 คน ดังนั้นข้อความทั้งหมดที่ต้องส่งสำหรับ Validator n คนก็คือ n²-n ใน Tendermint นั้น Validator จะเริ่มโหวตบล็อกใหม่เมื่อบล็อกเก่าเสร็จสิ้นแล้วเท่านั้น
ในทางกลับกัน MonadBFT จะใช้การโต้ตอบแบบสองเฟสก่อน Commit โดยมี Leader เป็นศูนย์กลาง ในแต่ละรอบจะมีการเปลี่ยน Leader ไปเรื่อยๆ และ Validator จะส่งผลโหวตไปให้ Leader คนถัดไปได้โดยที่ไม่ต้องรอให้บล็อกปัจจุบันนั้นจบหรือ Commit ก่อน เมื่อ Leader เสนอ (Propose) บล็อกในรอบที่ k และส่งไปให้กับ Validator คนอื่นๆ แล้ว Validator แต่ละคนจะส่งผลโหวตของบล็อกที่ k ไปให้กับ Leader คนถัดไป (คนที่จะเสนอบล็อกที่ k+1) โดย Leader คนใหม่นี้จะรวบรวมเอาผลโหวตของบล็อกที่ k จาก Validator มาสร้างเป็น Quorum Certificate หรือ QC (เหมือนเป็นใบยืนยันว่าบล็อกนั้นได้รับการโหวตว่าถูกต้องจากเสียงส่วนมากของ Validator) สำหรับบล็อกที่ k (จบเฟสแรกสำหรับบล็อก k) จากนั้น Leader สร้างบล็อกที่ k+1 โดยรวมเอา QC ของบล็อกที่ k เข้าไปด้วย ก่อนที่จะส่งให้ Validator คนอื่นๆ เมื่อ Validator คนอื่นๆ ได้รับแล้วก็จะทำหน้าที่เหมือนเดิมคือ โหวตให้กับบล็อกที่ k+1 แต่เนื่องจากบล็อกนี้มี QC ของบล็อกที่ k ด้วยจึงเป็นการโหวตรอบที่สองให้กับบล็อกที่ k ไปในตัว และส่งกลับไปให้ Leader คนถัดไป โดย Validator จะ Commit บล็อกที่ k เมื่อได้รับบล็อกของรอบที่ k+2 แล้ว ด้วยโครงสร้างแบบนี้จะทำให้ Validator แต่ละคนสามารถทำการโหวตพร้อมกันสำหรับบล็อกที่แตกต่างกันได้ เช่นตัวอย่างด้านบน Validator โหวตรอบแรกให้กับบล็อกที่ k+1 และโหวตรอบสองให้กับบล็อกที่ k พร้อมๆ กัน ทำให้การสื่อสารหรือโต้ตอบมีประสิทธิภาพมากขึ้นและลดความซับซ้อนลง ภาพด้านล่างแสดงการทำงานของ MonadBFT
1.Alice สร้างบล็อกสำหรับรอบที่ k และส่งไปให้ Validator คนอื่นๆ
2.Validator แต่ละคนตรวจสอบความถูกต้องของบล็อก (เช่น Signature) ถ้าหากบล็อกถูกต้อง Validator จะโหวต YES และส่งไปให้กับ Bob ซึ่งเป็น Leader คนถัดไป
3.Bob รวบรวมผลโหวต YES ของบล็อกที่ k และสร้าง QC ซึ่ง QC สำหรับบล็อกที่ k อันนี้จะถูกส่งคู่กับบล็อกใหม่ (บล็อกที่ k+1) ให้กับ Validator คนอื่นๆ ซึ่งเป็นบล็อกที่ Bob สร้างขึ้นมา
4.จากนั้นขั้นตอนจะคล้ายๆ เดิม Validator ตรวจสอบบล็อก โหวต YES และส่งไปให้กับ Charlie ซึ่งเป็น Validator คนถัดไป
5.Charlie รวบรวมผลโหวต YES ของบล็อกที่ k+1 และสร้าง QC ของบล็อกที่ k+1 และส่งคู่กับบล็อกที่ k+2 ไปให้กับ Validator คนอื่นๆ
เมื่อ Validator ได้รับ QC ของบล็อกที่ k+1 แล้ว Validator จะ Commit หรือเพิ่มบล็อกที่ k เข้าไปยังเชนของตน ณ จุดนี้ถ้าหากเกิดเหตุการณ์ที่ Charlie เป็น Leader ที่ไม่หวังดีและส่ง Proposal หรือบล็อกที่ k+2 ไปให้กับ Validator เพียงคนเดียว การที่เขามี QC ของบล็อกที่ k+1 อยู่ในมือจะทำให้เขามั่นใจว่า ถ้าหาก Validator อื่นไม่ได้รับบล็อกนี้ พวกเขาจะยังสามารถย้อนกับไปยังบล็อกที่ k หรือจุดสุดท้ายที่ทุกคน Commit ร่วมกันได้
ลักษณะของการที่ผลโหวตบล็อกที่ k ส่งผลต่อการโหวตบล็อกอื่นๆ นั้นเรียกว่า Pipeline ซึ่งเมื่อนำเอามาใช้กับระบบ Consensus อย่าง MonadBFT แล้วจะช่วยเพิ่มประสิทธิภาพของการประมวลผลได้อย่างมาก ภาพด้านบนแสดงถึง Pipeline ระหว่างผลโหวตของบล็อกต่างกัน จะเห็นได้ว่าในหนึ่งรอบ Validator สามารถทำการโหวตพร้อมกันได้ 3 เฟสสำหรับ 3 บล็อกที่แตกต่างกัน ในรอบที่ k บล็อกที่ k นั้นอยู่ในช่วง Pre-vote (การโหวตรอบแรก) ในขณะที่บล็อกที่ k-1 นั้นอยู่ในช่วง Pre-commit หรือการโหวตรอบที่สอง และบล็อกที่ k-2 นั้นถูก Commit และเพิ่มเข้าไปในเชนของ Validator ที่ได้รับบล็อกนี้ ดังนั้น Validator จะ Commit บล็อกของรอบที่ k เมื่อ QC ของบล็อกที่ k ผ่านการโหวตทั้งหมด 2 รอบและถูกรวมเข้าไปในบล็อกที่ k+2 โครงสร้างแบบนี้ช่วยลดความซับซ้อนของการโต้ตอบโต้ตอบที่ไม่จำเป็นระหว่างการโหวตของบล็อกที่เรียงต่อกันลงได้
2.Deferred Execution
ไอเดียของ Deferred Execution ใน Monad คือการแยก Consensus ออกจาก Execution (การประมวลผลธุรกรรม) สิ่งนี้ช่วยให้โหนดสามารถตกลง (Reach Consensus) เรื่องลำดับของธุรกรรมโดยไม่ต้องรอผลลัพธ์จากการประมวลผล ด้านล่างคือการทำงานของ Deferred Execution
🔸แยก Consensus ออกจาก Execution: สำหรับบล็อกเชนแบบดังเดิมอย่าง Ethereum นั้น Consensus และ Execution จะทำงานด้วยกัน นั่นคือธุรกรรมในบล็อกจะถูกประมวลผลก่อน เพื่อดูว่าสถานะสุดท้ายและธุรกรรมมีความถูกต้องหรือไม่ ก่อนที่จะนำบล็อกนี้มาผ่านระบบ Consensus เพื่อให้แต่ละโหนดทำการโหวตว่าจะใช้บล็อกนี้และลำดับของธุรกรรมเป็นไปตามที่ระบุไว้ในบล็อก แต่ในทางกลับกัน Monad จะให้โหนดนั้นโหวตก่อนว่าจะให้ลำดับของธุรกรรมในบล็อกเป็นแบบไหน โดยที่โหนดไม่จำเป็นต้องประมวลผลธุรกรรมก่อน การทำแบบนี้ช่วยให้ Monad สามารถทำการประมวลผลบล็อกหนึ่งและร่วม Consensus กับบล็อกถัดไปได้พร้อมๆ กัน ซึ่งช่วยให้สามารถใช้ทรัพยากรได้อย่างมีประสิทธิภาพมากขึ้น เนื่องจากการประมวลผลธุรกรรมจะไม่เป็นคอขวดให้แก่การทำ Consensus อีกต่อไป
🔸ผลลัพธ์ที่แน่นอน (Deterministic State): Monad อาศัยหลักการที่ว่าเมื่อลำดับของธุรกรรมถูกกำหนดแล้ว ผลลัพธ์ที่ได้จากการประมวลผลธุรกรรมของเหล่านี้จะแน่นอนไม่เปลี่ยนแปลง ดังนั้นแต่ละโหนดสามารถประมวลผลธุรกรรมโดยไม่ต้องโต้ตอบกัน หลังจากที่ลำดับของธุรกรรมถูกกำหนดโดยโหนดส่วนใหญ่แล้ว
ผลลัพธ์ที่ถูกดีเลย์ (Delayed State Commitment): เพื่อให้มั่นใจว่าทุกโหนดนั้นประมวลผลธุรกรรมอย่างถูกต้องและได้ผลลัพธ์ที่เหมือนกัน รวมถึงป้องกันพฤติกรรมที่ไม่หวังดีจากบางโหนด Monad จึงต้องดีเลย์ผลลัพธ์ของ State Root ออกไป บล็อกจะประกอบด้วย Merkle Root ที่จะถูกดีเลย์ออกไปด้วยจำนวนบล็อกที่กำหนดไว้ เช่น D บล็อก นั่นหมายความว่าสำหรับโหนดที่ไม่ใช่ Full Node จะเห็นสถานะหรือผลลัพธ์ของบล็อกที่ N-D ว่าถูกต้อง ก็ต่อเมื่อเชน Commit (Reach Consensus บน) บล็อกที่ N แล้ว สิ่งนี้ช่วยกระตุ้นให้ผู้ที่ใช้งานเชนรัน Full Node และช่วยเพิ่มความปลอดภัยของเชน นอกจากนี้การที่ Commitment ของ Merkle Root ถูกดีเลย์ออกไปยังช่วยจำกัดจำนวนบล็อกที่ Full Node จะตามหลังไม่ให้สูงเกินไป ส่งผลให้เชนมีความมั่นคงและเสถียร
Defered Execution จึงช่วยให้ Monad สามารถเพิ่มประสิทธิภาพได้ทั้งในด้านความเร็วและ Scalability ด้วยการทำให้ Consensus สามารถทำงานได้อย่างอิสระโดยที่ไม่ต้องรอผลลัพธ์จากการประมวลผล (Execution)
3.Parallel Execution
Parallel Execution นั้นเป็นกุญแจสำคัญใน Monad ที่ช่วยเพิ่มประสิทธิภาพการประมวลผลของธุรกรรมได้อย่างมาก ซึ่ง Monad สามารถประมวลผลหลายๆ ธุรกรรมพร้อมกันได้ โดยการใช้ Optimistic Execution ซึ่งประกอบด้วยสองเฟส
🔸Optimistic Execution: Monad ใช้ Optimistic Execution นั่นคือ Monad จะประมวลผลธุรกรรมไปก่อนโดยคิดว่าทุกธุรกรรมถูกต้อง เพื่อดูว่าแต่ละธุรกรรมขึ้นต่อกันอย่างไร ซึ่งเริ่มโดยการประมวลผลธุรกรรมพร้อมๆ กันโดยที่ไม่รอให้การประมวลผลธุรกรรมก่อนหน้าในบล็อกเดียวกันจบก่อน แต่ในขณะเดียวกันก็คอยดูข้อมูลขาเข้าและขาออกจากการประมวลผลของแต่ละธุรกรรม การทำแบบนี้จะช่วยบอกว่าแต่ละธุรกรรมนั้นขึ้นต่อกันอย่างไร และเมื่อต้องประมวลผลซ้ำอีกครั้ง จะทำให้มีประสิทธิภาพมากขึ้น
🔸การประมวลผลธุรกรรมที่ขึ้นต่อกันซ้ำอีกครั้ง (Re-Execute Dependencies): การดูว่าข้อมูลขาเข้าและขาออกจากการประมวลผลของแต่ละธุรกรรมช่วยให้ Monad สามารถตัดสินได้ว่าธุรกรรมใดที่ขึ้นต่อกันบ้าง โดยการลองประมวลผลจริงและจะช่วยให้สามารถข้ามการประมวลผลแบบเป็นลำดับที่มีความซับซ้อนได้ ในเหตุการณ์ที่มีธุรกรรมที่ขึ้นต่อกันเป็นจำนวนมากติดต่อกัน Optimistic Execution จะมีปัญหาเนื่องจากต้องมีการประมวลผลซ้ำหลายรอบ อย่างไรก็ตามความสวยงานของการใช้ Optimistic Execution คือจะช่วยบังคับให้ระบบเก็บข้อมูลการประมวลผลไว้ชั่วคราว และเมื่อต้องประมวลผลซ้ำอีกครั้งจะสามารถดึงข้อมูลเหล่านี้กลับมาใช้ได้ จึงทำให้การประมวลผลซ้ำอีกครั้งทำได้อย่างมีประสิทธิภาพและไม่กินทรัพยากรณ์
การทำ Parallel Execution ในลักษณะที่กล่าวไว้ข้างต้นช่วยให้ Monad
สามารถเพิ่มความสามารถในการรองรับจำนวนธุรกรรมได้มากขึ้นแล้วยังคงไว้ซึ่งความถูกต้องและผลลัพธ์ที่แน่นอนของการประมวลผลธุรกรรม ซึ่งช่วยเลี่ยงปัญหาของการประมวลผลที่เป็นลำดับที่ซับซ้อน หลักการนี้ช่วยให้ประสบการณ์การใช้งานสำหรับนักพัฒนา EVM ยังเหมือนเดิม หลีกเลี่ยงความจำเป็นที่จะต้องเตรียม Access List เมื่อมีการทำธุรกรรม
4.MonadDB
Ethereum ใช้โครงสร้างข้อมูลที่เรียกว่า Merkle Patricia Tree (MPT) ซึ่งเป็นการผสาน Merkle tree และ Patricia Tree เข้าด้วยกันเพื่อจัดเก็บสถานะของบล็อกเชนและทำให้การหยิบใช้ข้อมูลจาก Tree นั้นมีประสิทธิภาพ รวมถึงป้องกันการดัดแปลงข้อมูลภายใน Tree อย่างไรก็ตามเมื่อ Ethereum Client (โหนด) เก็บ Data เหล่านี้ไว้บนเครื่องตัวเอง จะใช้วิธีการเก็บด้วย Database ธรรมดา อย่าง LevelDB และ RocksDB ซึ่งเป็นวิธีการเก็บข้อมูลแบบทั่วไปที่ใช้ลักษณะ Key-Value ซึ่งจะเก็บข้อมูลไว้ในรูปแบบตาราง แต่ Database เหล่านี้ไม่ได้เข้าใจและไม่ได้ออกแบบมาเพื่อเก็บโครงสร้างแบบ MPT
ด้วยเหตุนี้ Monad จึงสร้าง Database ของตัวเองที่เรียกว่า MonadDb ขึ้นมา ซึ่งถูกออกแบบมาให้เหมาะสมกับโครงสร้างข้อมูลอย่าง MPT และเหมาะสมกับโครงสร้างของ Monad เนื่องจาก Monad ใช้ Parallel Execution จึงมีความจำเป็นที่จะต้องอ่านข้อมูลจากดิสก์แบบ Asynchronous (อ่านหลายๆ ข้อมูลพร้อมๆ กัน) โดยไม่จำเป็นต้องรอให้การดำเนินการอื่นๆ เสร็จสิ้นก่อน แต่ Database ที่กล่าวไว้ด้านบนนั้นไม่ได้รองรับการทำงานแบบนี้ตั้งแต่แรก (สามารถทำได้แต่ไม่ดีมาก) ด้วยการใช้ Async I/O ตัวล่าสุดจึงทำให้ Monad สามารถหลีกเลี่ยงคอขวดจากการที่ระบบต้องรอให้การดำเนินการอันหนึ่งเสร็จก่อน ก่อนที่จะสามารถดำเนินการอันถัดไปได้ ส่งผลให้สามารถทำงานในรูปแบบ Asynchronous ได้
References
[1] https://t.co/cTcUu88BBt
[2] https://t.co/jem0J92q1b
[3] https://t.co/ylGS3u0XUw
___________________________________
มีกิจกรรมอะไรให้ร่วมบ้าง1. Social Credit Score : วิธีเข้าร่วม
1.ติดตาม Social media of Monad team
- Join Monad Thailand telegram official by monad team : https://t.co/Z2WobNhQQ2
- Join Monad Discord : https://t.co/ptVMMrGqwo
- พูดคุยใน Monad discord เพื่อให้ได้ Lv6
2.NFT / Poap จากการร่วมกิจกรรม event community เช่น Poker / สร้าง meme
*Cr.picture by Monad community
3. Meme master : สร้างมีมที่คุณภาพ เพื่อโพสลง Twitter ส่วนตัว + Monad discord
*สร้าง monad meme ได้ที่ :
https://t.co/e0PaMAQmQI
#monad #gmonad #gnad](https://pbs.twimg.com/media/GA1AuSSbkAAm8K0.jpg)
![contributedao's tweet photo. Monad Layer 1 : [ กาวกระป๋องใหญ่ ทำไมถึงน่าสนใจในปี 2024 ? ] + How to Contribute with Monad Project
TL : DR [ ยาวไป ไม่อ่าน เลยมาสรุปให้ ]
ปล.ใครอยาก อ่านแบบยาวๆ และรูปฮาๆ เยอะ อ่านได้ที่นี่ : https://t.co/i9R2JKyF6J
1.Monad Layer 1 ที่ถูกออกแบบมาให้เข้ากันได้กับ EVM อย่างสมบูรณ์แบบ ทำให้ Tools , Stack , Programming ที่เป็น EVM สามารถเคลื่อนย้ายมายัง Monad ได้ราวกับกระพริบตา
*พร้อมกับความสามารถ Parallel execution [Monad คือ ETH + Solana]
2.The new innovative of monad ที่เข้ามาแก้ปัญหาของ Web3 Infrastructure เช่น
🔸 แก๊สแพง - Gas costs
🔸 ความความปลอดภัย - Security risks
🔸 ข้อจำกัดของที่เก็บข้อมูล - Limited storage
🔸 ปัญหา Mempool
🔸 การกระจายตัวของสภาพคล่อง - Liquidity Fragmented
🔸 ขาด Resource - Lack of Tools
🔸 Upgradability challenges
🔸 Interoperability issues
- 2.1 MonadBFT = ระบบ Consensus ใหม่ของ Monad ที่ช่วยให้มี TPS มากกว่า 10,000 + และ Finality ที่ต่ำมาก
- 2.2 Defered Execution = การแยก Execution และ Consensus Logic ออกจากกัน ทำให้ทั้งสองสามารถทำงาน พร้อมๆ กันได้
- 2.3 Optimistc Parallel Execution ที่ช่วยให้ Monad สามารถหลีกเลี่ยงการประมวลผลแบบเป็นลำดับที่ซับซ้อนและเตรียม Access List ที่ยุ่งยากได้
- 2.4 MonadDB ซึ่งเป็น Database ที่ถูกออกแบบโดย Monad ให้เหมาะกับโครงสร้างข้อมูลที่ Ethereum ใช้อยู่ รวมทั้งยังช่วยอำนวยความสะดวกในการดำเนินการต่างๆ ที่เป็นแบบ Parallel อีกด้วย
*Cr.picture by Monad community
3.ระดมทุนได้มากกว่า $19m Seedround
4.มีกิจกรรมให้ Contribute [ดูเพิ่มเติมได้ที่ย่อหน้าสุดท้าย]
5.มีมากกว่า 40 projects ที่ confirmed ว่าจะเชื่อมกับ Monad
6. Community First , Deep technology together. [โปรเจคแรกของโลก ที่ Design Project ให้สอดคล้องกับ Web3 Culture คือ Game theory]
***เพียงแค่ จินตนาการว่า มันคือ Deep Tech + Meme + community = กาวกระป๋องใหญ่
7. Good team
@monad_xyz
@keoneHD
@IcedQuad
@zen_llama
@_jhunsaker
@port_dev
@billmondays
____________________________________________
มาดู Research ฉบับเข้าใจง่ายกันเถอะ
Monad Introduction
หากพูดถึงบล็อกเชนที่มีความนิยมสูงสุดคงหนีไม่พ้นบล็อกเชนอย่าง Ethereum ไม่เพียงแต่จะเป็นศูนย์รวมของงานวิจัย, การพัฒนา, dApp และคอมมูนิตี้ต่างๆ แต่ยังถือครอง TVL ที่สูงที่สุดอีกด้วย สิ่งต่างๆ เหล่านี้ได้ตอกย้ำว่า Ethereum นั้นมีบทบาทที่สำคัญต่อโลกของบล็อกเชนเพียงใด อย่างไรก็ตาม Ethereum ก็มีข้อจำกัดที่หลายคนรู้กันดี นั่นก็คือค่าแก๊สที่แพง, TPS (จำนวนธุรกรรมต่อวินาที) ที่ต่ำ และ Finality ที่นาน สิ่งเหล่านี้มีแต่จะทำให้ประสบการณ์ของผู้ใช้งานและนักพัฒนาแย่ลงเรื่อยๆ
ด้วยเหตุนี้โปรเจกต์ต่างๆ จึงแข่งขันกันเพื่อหาแนวทางใหม่ที่จะมาแก้ปัญหาที่ Ethereum ต้องเผชิญ แต่ด้วยการที่เชนใหม่ๆ พัฒนาและใช้เทคโนโลยีที่เหมาะสมกับการทำงานเฉพาะด้านของตน จึงส่งผลให้เกิดผลเสียใหม่ที่ตามมา นั้นก็คือความไม่เข้ากันกับ EVM (ไม่สามารถทำงานเชนที่เป็น EVM ได้ โดยเฉพาะ Ethereum) EVM compatibility หรือความเข้ากันได้กับ EVM นั้นเป็นสิ่งสำคัญ เนื่องจากเครื่องมือในบล็อกเชนที่ใช้งานกันส่วนใหญ่ถูกออกแบบมาให้เหมาะสมกับ EVM และโครงสร้างของ Ethereum ดังนั้นเมื่อบล็อกเชนเลเยอร์ 1 ที่ไม่เข้ากันกับ EVM เกิดขึ้นมาจะนำไปสู่การพัฒนาเครื่องมือใหม่ๆ ทำให้นักพัฒนาและผู้ใช้ต้องปรับตัวเข้ากับสภาพแวดล้อมที่แตกต่างไปจากเดิมอย่างสิ้นเชิง นอกจากนี้ความเข้ากันได้กับ EVM ยังช่วยลดความยุ่งยากในการย้าย dApps ที่มีอยู่แล้วบน Ethereum มายังเชนใหม่ได้โดยที่นักพัฒนาไม่ต้องมาเริ่มนับหนึ่งใหม่ตั้งแต่ต้น
Monad - บล็อกเชนเลเยอร์ 1 ที่มีความเร็วสูง, Finality ที่ต่ำ และเข้ากันได้กับ EVM โดยสมบูรณ์
Monad เป็นบล็อกเชนเลเยอร์หนึ่งที่เข้ากันได้กับ EVM อย่างสมบูรณ์ (Fully EVM compatible) สามารถรองรับจำนวนธุรกรรมต่อวินาทีได้สูง และมี Finality ที่ต่ำ Monad สามารถทำสิ่งเหล่านี้ได้โดยการปรับปรุงประสิทธิภาพใน 4 ด้านหลักๆ คือ
1.MonadBFT
2.Deferred Execution
3.Parallel Execution
4.MonadDb
ฟีเจอร์เหล่านี้ช่วยให้ Monad สามารถรองรับธุรกรรมได้มากถึง 10,000 ธุรกรรมต่อวินาทีและมี Finality อยู่ที่ประมาณ 1 วินาธีเท่านั้น ในบทความนี้เราจะมาเจาะลึกกันว่าแต่ละฟีเจอร์ทำงานอย่างไรและช่วยเพิ่มประสิทธิภาพให้แก่ Monad ได้อย่างไร
1.MonadBFT
ถ้าหากคุณรู้ว่า Tendermint และ Hotstuff ทำงานอย่างไร คุณจะทำความเข้าใจ MonadBFT ได้ง่ายมาก แต่ถ้าไม่รู้จักไม่เป็นไร ในบทความนี้เราจะอธิบายให้ฟังเอง Tendermint เป็น Consensus หลักที่ใช้ในระบบนิเวศของเชน Cosmos ซึ่งการที่ Validator จะตัดสินใจว่าบล็อกไหนนั้นจะถูกเพิ่มเข้าไปบนบล็อกเชนหรือ Commit จะต้องผ่านการโหวตทั้งหมด 3 เฟสด้วยกัน ได้แก่ Propose, Pre-vote และ Pre-commit โดยเริ่มแรกของแต่ละบล็อก Leader (คนที่ถูกเลือกจาก Validator ทั้งหมด) จะเป็นคนที่เสนอบล็อกของตัวเองและส่งไปให้ Validator คนอื่นๆ เมื่อ Validator ได้รับบล็อกแล้วจะทำการโหวตโดยการแลกเปลี่ยนข้อความระหว่าง Validator ด้วยกันเอง เมื่อตกลงกันได้แล้วจึงจะทำการ Commit บล็อกๆ นั้น การที่ Validator โต้ตอบโดยการแลกเปลี่ยนข้อความกันไปกันมานี้ทำให้การสื่อสารมีความซับซ้อนแบบยกกำลังสอง (O(n²)) หรือก็คือ ถ้าหากมี Validator อยู่ n คน Validator 1 คนจะต้องส่งข้อความไปหาคนอื่น n-1 คน ดังนั้นข้อความทั้งหมดที่ต้องส่งสำหรับ Validator n คนก็คือ n²-n ใน Tendermint นั้น Validator จะเริ่มโหวตบล็อกใหม่เมื่อบล็อกเก่าเสร็จสิ้นแล้วเท่านั้น
ในทางกลับกัน MonadBFT จะใช้การโต้ตอบแบบสองเฟสก่อน Commit โดยมี Leader เป็นศูนย์กลาง ในแต่ละรอบจะมีการเปลี่ยน Leader ไปเรื่อยๆ และ Validator จะส่งผลโหวตไปให้ Leader คนถัดไปได้โดยที่ไม่ต้องรอให้บล็อกปัจจุบันนั้นจบหรือ Commit ก่อน เมื่อ Leader เสนอ (Propose) บล็อกในรอบที่ k และส่งไปให้กับ Validator คนอื่นๆ แล้ว Validator แต่ละคนจะส่งผลโหวตของบล็อกที่ k ไปให้กับ Leader คนถัดไป (คนที่จะเสนอบล็อกที่ k+1) โดย Leader คนใหม่นี้จะรวบรวมเอาผลโหวตของบล็อกที่ k จาก Validator มาสร้างเป็น Quorum Certificate หรือ QC (เหมือนเป็นใบยืนยันว่าบล็อกนั้นได้รับการโหวตว่าถูกต้องจากเสียงส่วนมากของ Validator) สำหรับบล็อกที่ k (จบเฟสแรกสำหรับบล็อก k) จากนั้น Leader สร้างบล็อกที่ k+1 โดยรวมเอา QC ของบล็อกที่ k เข้าไปด้วย ก่อนที่จะส่งให้ Validator คนอื่นๆ เมื่อ Validator คนอื่นๆ ได้รับแล้วก็จะทำหน้าที่เหมือนเดิมคือ โหวตให้กับบล็อกที่ k+1 แต่เนื่องจากบล็อกนี้มี QC ของบล็อกที่ k ด้วยจึงเป็นการโหวตรอบที่สองให้กับบล็อกที่ k ไปในตัว และส่งกลับไปให้ Leader คนถัดไป โดย Validator จะ Commit บล็อกที่ k เมื่อได้รับบล็อกของรอบที่ k+2 แล้ว ด้วยโครงสร้างแบบนี้จะทำให้ Validator แต่ละคนสามารถทำการโหวตพร้อมกันสำหรับบล็อกที่แตกต่างกันได้ เช่นตัวอย่างด้านบน Validator โหวตรอบแรกให้กับบล็อกที่ k+1 และโหวตรอบสองให้กับบล็อกที่ k พร้อมๆ กัน ทำให้การสื่อสารหรือโต้ตอบมีประสิทธิภาพมากขึ้นและลดความซับซ้อนลง ภาพด้านล่างแสดงการทำงานของ MonadBFT
1.Alice สร้างบล็อกสำหรับรอบที่ k และส่งไปให้ Validator คนอื่นๆ
2.Validator แต่ละคนตรวจสอบความถูกต้องของบล็อก (เช่น Signature) ถ้าหากบล็อกถูกต้อง Validator จะโหวต YES และส่งไปให้กับ Bob ซึ่งเป็น Leader คนถัดไป
3.Bob รวบรวมผลโหวต YES ของบล็อกที่ k และสร้าง QC ซึ่ง QC สำหรับบล็อกที่ k อันนี้จะถูกส่งคู่กับบล็อกใหม่ (บล็อกที่ k+1) ให้กับ Validator คนอื่นๆ ซึ่งเป็นบล็อกที่ Bob สร้างขึ้นมา
4.จากนั้นขั้นตอนจะคล้ายๆ เดิม Validator ตรวจสอบบล็อก โหวต YES และส่งไปให้กับ Charlie ซึ่งเป็น Validator คนถัดไป
5.Charlie รวบรวมผลโหวต YES ของบล็อกที่ k+1 และสร้าง QC ของบล็อกที่ k+1 และส่งคู่กับบล็อกที่ k+2 ไปให้กับ Validator คนอื่นๆ
เมื่อ Validator ได้รับ QC ของบล็อกที่ k+1 แล้ว Validator จะ Commit หรือเพิ่มบล็อกที่ k เข้าไปยังเชนของตน ณ จุดนี้ถ้าหากเกิดเหตุการณ์ที่ Charlie เป็น Leader ที่ไม่หวังดีและส่ง Proposal หรือบล็อกที่ k+2 ไปให้กับ Validator เพียงคนเดียว การที่เขามี QC ของบล็อกที่ k+1 อยู่ในมือจะทำให้เขามั่นใจว่า ถ้าหาก Validator อื่นไม่ได้รับบล็อกนี้ พวกเขาจะยังสามารถย้อนกับไปยังบล็อกที่ k หรือจุดสุดท้ายที่ทุกคน Commit ร่วมกันได้
ลักษณะของการที่ผลโหวตบล็อกที่ k ส่งผลต่อการโหวตบล็อกอื่นๆ นั้นเรียกว่า Pipeline ซึ่งเมื่อนำเอามาใช้กับระบบ Consensus อย่าง MonadBFT แล้วจะช่วยเพิ่มประสิทธิภาพของการประมวลผลได้อย่างมาก ภาพด้านบนแสดงถึง Pipeline ระหว่างผลโหวตของบล็อกต่างกัน จะเห็นได้ว่าในหนึ่งรอบ Validator สามารถทำการโหวตพร้อมกันได้ 3 เฟสสำหรับ 3 บล็อกที่แตกต่างกัน ในรอบที่ k บล็อกที่ k นั้นอยู่ในช่วง Pre-vote (การโหวตรอบแรก) ในขณะที่บล็อกที่ k-1 นั้นอยู่ในช่วง Pre-commit หรือการโหวตรอบที่สอง และบล็อกที่ k-2 นั้นถูก Commit และเพิ่มเข้าไปในเชนของ Validator ที่ได้รับบล็อกนี้ ดังนั้น Validator จะ Commit บล็อกของรอบที่ k เมื่อ QC ของบล็อกที่ k ผ่านการโหวตทั้งหมด 2 รอบและถูกรวมเข้าไปในบล็อกที่ k+2 โครงสร้างแบบนี้ช่วยลดความซับซ้อนของการโต้ตอบโต้ตอบที่ไม่จำเป็นระหว่างการโหวตของบล็อกที่เรียงต่อกันลงได้
2.Deferred Execution
ไอเดียของ Deferred Execution ใน Monad คือการแยก Consensus ออกจาก Execution (การประมวลผลธุรกรรม) สิ่งนี้ช่วยให้โหนดสามารถตกลง (Reach Consensus) เรื่องลำดับของธุรกรรมโดยไม่ต้องรอผลลัพธ์จากการประมวลผล ด้านล่างคือการทำงานของ Deferred Execution
🔸แยก Consensus ออกจาก Execution: สำหรับบล็อกเชนแบบดังเดิมอย่าง Ethereum นั้น Consensus และ Execution จะทำงานด้วยกัน นั่นคือธุรกรรมในบล็อกจะถูกประมวลผลก่อน เพื่อดูว่าสถานะสุดท้ายและธุรกรรมมีความถูกต้องหรือไม่ ก่อนที่จะนำบล็อกนี้มาผ่านระบบ Consensus เพื่อให้แต่ละโหนดทำการโหวตว่าจะใช้บล็อกนี้และลำดับของธุรกรรมเป็นไปตามที่ระบุไว้ในบล็อก แต่ในทางกลับกัน Monad จะให้โหนดนั้นโหวตก่อนว่าจะให้ลำดับของธุรกรรมในบล็อกเป็นแบบไหน โดยที่โหนดไม่จำเป็นต้องประมวลผลธุรกรรมก่อน การทำแบบนี้ช่วยให้ Monad สามารถทำการประมวลผลบล็อกหนึ่งและร่วม Consensus กับบล็อกถัดไปได้พร้อมๆ กัน ซึ่งช่วยให้สามารถใช้ทรัพยากรได้อย่างมีประสิทธิภาพมากขึ้น เนื่องจากการประมวลผลธุรกรรมจะไม่เป็นคอขวดให้แก่การทำ Consensus อีกต่อไป
🔸ผลลัพธ์ที่แน่นอน (Deterministic State): Monad อาศัยหลักการที่ว่าเมื่อลำดับของธุรกรรมถูกกำหนดแล้ว ผลลัพธ์ที่ได้จากการประมวลผลธุรกรรมของเหล่านี้จะแน่นอนไม่เปลี่ยนแปลง ดังนั้นแต่ละโหนดสามารถประมวลผลธุรกรรมโดยไม่ต้องโต้ตอบกัน หลังจากที่ลำดับของธุรกรรมถูกกำหนดโดยโหนดส่วนใหญ่แล้ว
ผลลัพธ์ที่ถูกดีเลย์ (Delayed State Commitment): เพื่อให้มั่นใจว่าทุกโหนดนั้นประมวลผลธุรกรรมอย่างถูกต้องและได้ผลลัพธ์ที่เหมือนกัน รวมถึงป้องกันพฤติกรรมที่ไม่หวังดีจากบางโหนด Monad จึงต้องดีเลย์ผลลัพธ์ของ State Root ออกไป บล็อกจะประกอบด้วย Merkle Root ที่จะถูกดีเลย์ออกไปด้วยจำนวนบล็อกที่กำหนดไว้ เช่น D บล็อก นั่นหมายความว่าสำหรับโหนดที่ไม่ใช่ Full Node จะเห็นสถานะหรือผลลัพธ์ของบล็อกที่ N-D ว่าถูกต้อง ก็ต่อเมื่อเชน Commit (Reach Consensus บน) บล็อกที่ N แล้ว สิ่งนี้ช่วยกระตุ้นให้ผู้ที่ใช้งานเชนรัน Full Node และช่วยเพิ่มความปลอดภัยของเชน นอกจากนี้การที่ Commitment ของ Merkle Root ถูกดีเลย์ออกไปยังช่วยจำกัดจำนวนบล็อกที่ Full Node จะตามหลังไม่ให้สูงเกินไป ส่งผลให้เชนมีความมั่นคงและเสถียร
Defered Execution จึงช่วยให้ Monad สามารถเพิ่มประสิทธิภาพได้ทั้งในด้านความเร็วและ Scalability ด้วยการทำให้ Consensus สามารถทำงานได้อย่างอิสระโดยที่ไม่ต้องรอผลลัพธ์จากการประมวลผล (Execution)
3.Parallel Execution
Parallel Execution นั้นเป็นกุญแจสำคัญใน Monad ที่ช่วยเพิ่มประสิทธิภาพการประมวลผลของธุรกรรมได้อย่างมาก ซึ่ง Monad สามารถประมวลผลหลายๆ ธุรกรรมพร้อมกันได้ โดยการใช้ Optimistic Execution ซึ่งประกอบด้วยสองเฟส
🔸Optimistic Execution: Monad ใช้ Optimistic Execution นั่นคือ Monad จะประมวลผลธุรกรรมไปก่อนโดยคิดว่าทุกธุรกรรมถูกต้อง เพื่อดูว่าแต่ละธุรกรรมขึ้นต่อกันอย่างไร ซึ่งเริ่มโดยการประมวลผลธุรกรรมพร้อมๆ กันโดยที่ไม่รอให้การประมวลผลธุรกรรมก่อนหน้าในบล็อกเดียวกันจบก่อน แต่ในขณะเดียวกันก็คอยดูข้อมูลขาเข้าและขาออกจากการประมวลผลของแต่ละธุรกรรม การทำแบบนี้จะช่วยบอกว่าแต่ละธุรกรรมนั้นขึ้นต่อกันอย่างไร และเมื่อต้องประมวลผลซ้ำอีกครั้ง จะทำให้มีประสิทธิภาพมากขึ้น
🔸การประมวลผลธุรกรรมที่ขึ้นต่อกันซ้ำอีกครั้ง (Re-Execute Dependencies): การดูว่าข้อมูลขาเข้าและขาออกจากการประมวลผลของแต่ละธุรกรรมช่วยให้ Monad สามารถตัดสินได้ว่าธุรกรรมใดที่ขึ้นต่อกันบ้าง โดยการลองประมวลผลจริงและจะช่วยให้สามารถข้ามการประมวลผลแบบเป็นลำดับที่มีความซับซ้อนได้ ในเหตุการณ์ที่มีธุรกรรมที่ขึ้นต่อกันเป็นจำนวนมากติดต่อกัน Optimistic Execution จะมีปัญหาเนื่องจากต้องมีการประมวลผลซ้ำหลายรอบ อย่างไรก็ตามความสวยงานของการใช้ Optimistic Execution คือจะช่วยบังคับให้ระบบเก็บข้อมูลการประมวลผลไว้ชั่วคราว และเมื่อต้องประมวลผลซ้ำอีกครั้งจะสามารถดึงข้อมูลเหล่านี้กลับมาใช้ได้ จึงทำให้การประมวลผลซ้ำอีกครั้งทำได้อย่างมีประสิทธิภาพและไม่กินทรัพยากรณ์
การทำ Parallel Execution ในลักษณะที่กล่าวไว้ข้างต้นช่วยให้ Monad
สามารถเพิ่มความสามารถในการรองรับจำนวนธุรกรรมได้มากขึ้นแล้วยังคงไว้ซึ่งความถูกต้องและผลลัพธ์ที่แน่นอนของการประมวลผลธุรกรรม ซึ่งช่วยเลี่ยงปัญหาของการประมวลผลที่เป็นลำดับที่ซับซ้อน หลักการนี้ช่วยให้ประสบการณ์การใช้งานสำหรับนักพัฒนา EVM ยังเหมือนเดิม หลีกเลี่ยงความจำเป็นที่จะต้องเตรียม Access List เมื่อมีการทำธุรกรรม
4.MonadDB
Ethereum ใช้โครงสร้างข้อมูลที่เรียกว่า Merkle Patricia Tree (MPT) ซึ่งเป็นการผสาน Merkle tree และ Patricia Tree เข้าด้วยกันเพื่อจัดเก็บสถานะของบล็อกเชนและทำให้การหยิบใช้ข้อมูลจาก Tree นั้นมีประสิทธิภาพ รวมถึงป้องกันการดัดแปลงข้อมูลภายใน Tree อย่างไรก็ตามเมื่อ Ethereum Client (โหนด) เก็บ Data เหล่านี้ไว้บนเครื่องตัวเอง จะใช้วิธีการเก็บด้วย Database ธรรมดา อย่าง LevelDB และ RocksDB ซึ่งเป็นวิธีการเก็บข้อมูลแบบทั่วไปที่ใช้ลักษณะ Key-Value ซึ่งจะเก็บข้อมูลไว้ในรูปแบบตาราง แต่ Database เหล่านี้ไม่ได้เข้าใจและไม่ได้ออกแบบมาเพื่อเก็บโครงสร้างแบบ MPT
ด้วยเหตุนี้ Monad จึงสร้าง Database ของตัวเองที่เรียกว่า MonadDb ขึ้นมา ซึ่งถูกออกแบบมาให้เหมาะสมกับโครงสร้างข้อมูลอย่าง MPT และเหมาะสมกับโครงสร้างของ Monad เนื่องจาก Monad ใช้ Parallel Execution จึงมีความจำเป็นที่จะต้องอ่านข้อมูลจากดิสก์แบบ Asynchronous (อ่านหลายๆ ข้อมูลพร้อมๆ กัน) โดยไม่จำเป็นต้องรอให้การดำเนินการอื่นๆ เสร็จสิ้นก่อน แต่ Database ที่กล่าวไว้ด้านบนนั้นไม่ได้รองรับการทำงานแบบนี้ตั้งแต่แรก (สามารถทำได้แต่ไม่ดีมาก) ด้วยการใช้ Async I/O ตัวล่าสุดจึงทำให้ Monad สามารถหลีกเลี่ยงคอขวดจากการที่ระบบต้องรอให้การดำเนินการอันหนึ่งเสร็จก่อน ก่อนที่จะสามารถดำเนินการอันถัดไปได้ ส่งผลให้สามารถทำงานในรูปแบบ Asynchronous ได้
References
[1] https://t.co/cTcUu88BBt
[2] https://t.co/jem0J92q1b
[3] https://t.co/ylGS3u0XUw
___________________________________
มีกิจกรรมอะไรให้ร่วมบ้าง1. Social Credit Score : วิธีเข้าร่วม
1.ติดตาม Social media of Monad team
- Join Monad Thailand telegram official by monad team : https://t.co/Z2WobNhQQ2
- Join Monad Discord : https://t.co/ptVMMrGqwo
- พูดคุยใน Monad discord เพื่อให้ได้ Lv6
2.NFT / Poap จากการร่วมกิจกรรม event community เช่น Poker / สร้าง meme
*Cr.picture by Monad community
3. Meme master : สร้างมีมที่คุณภาพ เพื่อโพสลง Twitter ส่วนตัว + Monad discord
*สร้าง monad meme ได้ที่ :
https://t.co/e0PaMAQmQI
#monad #gmonad #gnad](https://pbs.twimg.com/media/GA1AaHRa8AAWSnh.jpg)
![contributedao's tweet photo. Monad Layer 1 : [ กาวกระป๋องใหญ่ ทำไมถึงน่าสนใจในปี 2024 ? ] + How to Contribute with Monad Project
TL : DR [ ยาวไป ไม่อ่าน เลยมาสรุปให้ ]
ปล.ใครอยาก อ่านแบบยาวๆ และรูปฮาๆ เยอะ อ่านได้ที่นี่ : https://t.co/i9R2JKyF6J
1.Monad Layer 1 ที่ถูกออกแบบมาให้เข้ากันได้กับ EVM อย่างสมบูรณ์แบบ ทำให้ Tools , Stack , Programming ที่เป็น EVM สามารถเคลื่อนย้ายมายัง Monad ได้ราวกับกระพริบตา
*พร้อมกับความสามารถ Parallel execution [Monad คือ ETH + Solana]
2.The new innovative of monad ที่เข้ามาแก้ปัญหาของ Web3 Infrastructure เช่น
🔸 แก๊สแพง - Gas costs
🔸 ความความปลอดภัย - Security risks
🔸 ข้อจำกัดของที่เก็บข้อมูล - Limited storage
🔸 ปัญหา Mempool
🔸 การกระจายตัวของสภาพคล่อง - Liquidity Fragmented
🔸 ขาด Resource - Lack of Tools
🔸 Upgradability challenges
🔸 Interoperability issues
- 2.1 MonadBFT = ระบบ Consensus ใหม่ของ Monad ที่ช่วยให้มี TPS มากกว่า 10,000 + และ Finality ที่ต่ำมาก
- 2.2 Defered Execution = การแยก Execution และ Consensus Logic ออกจากกัน ทำให้ทั้งสองสามารถทำงาน พร้อมๆ กันได้
- 2.3 Optimistc Parallel Execution ที่ช่วยให้ Monad สามารถหลีกเลี่ยงการประมวลผลแบบเป็นลำดับที่ซับซ้อนและเตรียม Access List ที่ยุ่งยากได้
- 2.4 MonadDB ซึ่งเป็น Database ที่ถูกออกแบบโดย Monad ให้เหมาะกับโครงสร้างข้อมูลที่ Ethereum ใช้อยู่ รวมทั้งยังช่วยอำนวยความสะดวกในการดำเนินการต่างๆ ที่เป็นแบบ Parallel อีกด้วย
*Cr.picture by Monad community
3.ระดมทุนได้มากกว่า $19m Seedround
4.มีกิจกรรมให้ Contribute [ดูเพิ่มเติมได้ที่ย่อหน้าสุดท้าย]
5.มีมากกว่า 40 projects ที่ confirmed ว่าจะเชื่อมกับ Monad
6. Community First , Deep technology together. [โปรเจคแรกของโลก ที่ Design Project ให้สอดคล้องกับ Web3 Culture คือ Game theory]
***เพียงแค่ จินตนาการว่า มันคือ Deep Tech + Meme + community = กาวกระป๋องใหญ่
7. Good team
@monad_xyz
@keoneHD
@IcedQuad
@zen_llama
@_jhunsaker
@port_dev
@billmondays
____________________________________________
มาดู Research ฉบับเข้าใจง่ายกันเถอะ
Monad Introduction
หากพูดถึงบล็อกเชนที่มีความนิยมสูงสุดคงหนีไม่พ้นบล็อกเชนอย่าง Ethereum ไม่เพียงแต่จะเป็นศูนย์รวมของงานวิจัย, การพัฒนา, dApp และคอมมูนิตี้ต่างๆ แต่ยังถือครอง TVL ที่สูงที่สุดอีกด้วย สิ่งต่างๆ เหล่านี้ได้ตอกย้ำว่า Ethereum นั้นมีบทบาทที่สำคัญต่อโลกของบล็อกเชนเพียงใด อย่างไรก็ตาม Ethereum ก็มีข้อจำกัดที่หลายคนรู้กันดี นั่นก็คือค่าแก๊สที่แพง, TPS (จำนวนธุรกรรมต่อวินาที) ที่ต่ำ และ Finality ที่นาน สิ่งเหล่านี้มีแต่จะทำให้ประสบการณ์ของผู้ใช้งานและนักพัฒนาแย่ลงเรื่อยๆ
ด้วยเหตุนี้โปรเจกต์ต่างๆ จึงแข่งขันกันเพื่อหาแนวทางใหม่ที่จะมาแก้ปัญหาที่ Ethereum ต้องเผชิญ แต่ด้วยการที่เชนใหม่ๆ พัฒนาและใช้เทคโนโลยีที่เหมาะสมกับการทำงานเฉพาะด้านของตน จึงส่งผลให้เกิดผลเสียใหม่ที่ตามมา นั้นก็คือความไม่เข้ากันกับ EVM (ไม่สามารถทำงานเชนที่เป็น EVM ได้ โดยเฉพาะ Ethereum) EVM compatibility หรือความเข้ากันได้กับ EVM นั้นเป็นสิ่งสำคัญ เนื่องจากเครื่องมือในบล็อกเชนที่ใช้งานกันส่วนใหญ่ถูกออกแบบมาให้เหมาะสมกับ EVM และโครงสร้างของ Ethereum ดังนั้นเมื่อบล็อกเชนเลเยอร์ 1 ที่ไม่เข้ากันกับ EVM เกิดขึ้นมาจะนำไปสู่การพัฒนาเครื่องมือใหม่ๆ ทำให้นักพัฒนาและผู้ใช้ต้องปรับตัวเข้ากับสภาพแวดล้อมที่แตกต่างไปจากเดิมอย่างสิ้นเชิง นอกจากนี้ความเข้ากันได้กับ EVM ยังช่วยลดความยุ่งยากในการย้าย dApps ที่มีอยู่แล้วบน Ethereum มายังเชนใหม่ได้โดยที่นักพัฒนาไม่ต้องมาเริ่มนับหนึ่งใหม่ตั้งแต่ต้น
Monad - บล็อกเชนเลเยอร์ 1 ที่มีความเร็วสูง, Finality ที่ต่ำ และเข้ากันได้กับ EVM โดยสมบูรณ์
Monad เป็นบล็อกเชนเลเยอร์หนึ่งที่เข้ากันได้กับ EVM อย่างสมบูรณ์ (Fully EVM compatible) สามารถรองรับจำนวนธุรกรรมต่อวินาทีได้สูง และมี Finality ที่ต่ำ Monad สามารถทำสิ่งเหล่านี้ได้โดยการปรับปรุงประสิทธิภาพใน 4 ด้านหลักๆ คือ
1.MonadBFT
2.Deferred Execution
3.Parallel Execution
4.MonadDb
ฟีเจอร์เหล่านี้ช่วยให้ Monad สามารถรองรับธุรกรรมได้มากถึง 10,000 ธุรกรรมต่อวินาทีและมี Finality อยู่ที่ประมาณ 1 วินาธีเท่านั้น ในบทความนี้เราจะมาเจาะลึกกันว่าแต่ละฟีเจอร์ทำงานอย่างไรและช่วยเพิ่มประสิทธิภาพให้แก่ Monad ได้อย่างไร
1.MonadBFT
ถ้าหากคุณรู้ว่า Tendermint และ Hotstuff ทำงานอย่างไร คุณจะทำความเข้าใจ MonadBFT ได้ง่ายมาก แต่ถ้าไม่รู้จักไม่เป็นไร ในบทความนี้เราจะอธิบายให้ฟังเอง Tendermint เป็น Consensus หลักที่ใช้ในระบบนิเวศของเชน Cosmos ซึ่งการที่ Validator จะตัดสินใจว่าบล็อกไหนนั้นจะถูกเพิ่มเข้าไปบนบล็อกเชนหรือ Commit จะต้องผ่านการโหวตทั้งหมด 3 เฟสด้วยกัน ได้แก่ Propose, Pre-vote และ Pre-commit โดยเริ่มแรกของแต่ละบล็อก Leader (คนที่ถูกเลือกจาก Validator ทั้งหมด) จะเป็นคนที่เสนอบล็อกของตัวเองและส่งไปให้ Validator คนอื่นๆ เมื่อ Validator ได้รับบล็อกแล้วจะทำการโหวตโดยการแลกเปลี่ยนข้อความระหว่าง Validator ด้วยกันเอง เมื่อตกลงกันได้แล้วจึงจะทำการ Commit บล็อกๆ นั้น การที่ Validator โต้ตอบโดยการแลกเปลี่ยนข้อความกันไปกันมานี้ทำให้การสื่อสารมีความซับซ้อนแบบยกกำลังสอง (O(n²)) หรือก็คือ ถ้าหากมี Validator อยู่ n คน Validator 1 คนจะต้องส่งข้อความไปหาคนอื่น n-1 คน ดังนั้นข้อความทั้งหมดที่ต้องส่งสำหรับ Validator n คนก็คือ n²-n ใน Tendermint นั้น Validator จะเริ่มโหวตบล็อกใหม่เมื่อบล็อกเก่าเสร็จสิ้นแล้วเท่านั้น
ในทางกลับกัน MonadBFT จะใช้การโต้ตอบแบบสองเฟสก่อน Commit โดยมี Leader เป็นศูนย์กลาง ในแต่ละรอบจะมีการเปลี่ยน Leader ไปเรื่อยๆ และ Validator จะส่งผลโหวตไปให้ Leader คนถัดไปได้โดยที่ไม่ต้องรอให้บล็อกปัจจุบันนั้นจบหรือ Commit ก่อน เมื่อ Leader เสนอ (Propose) บล็อกในรอบที่ k และส่งไปให้กับ Validator คนอื่นๆ แล้ว Validator แต่ละคนจะส่งผลโหวตของบล็อกที่ k ไปให้กับ Leader คนถัดไป (คนที่จะเสนอบล็อกที่ k+1) โดย Leader คนใหม่นี้จะรวบรวมเอาผลโหวตของบล็อกที่ k จาก Validator มาสร้างเป็น Quorum Certificate หรือ QC (เหมือนเป็นใบยืนยันว่าบล็อกนั้นได้รับการโหวตว่าถูกต้องจากเสียงส่วนมากของ Validator) สำหรับบล็อกที่ k (จบเฟสแรกสำหรับบล็อก k) จากนั้น Leader สร้างบล็อกที่ k+1 โดยรวมเอา QC ของบล็อกที่ k เข้าไปด้วย ก่อนที่จะส่งให้ Validator คนอื่นๆ เมื่อ Validator คนอื่นๆ ได้รับแล้วก็จะทำหน้าที่เหมือนเดิมคือ โหวตให้กับบล็อกที่ k+1 แต่เนื่องจากบล็อกนี้มี QC ของบล็อกที่ k ด้วยจึงเป็นการโหวตรอบที่สองให้กับบล็อกที่ k ไปในตัว และส่งกลับไปให้ Leader คนถัดไป โดย Validator จะ Commit บล็อกที่ k เมื่อได้รับบล็อกของรอบที่ k+2 แล้ว ด้วยโครงสร้างแบบนี้จะทำให้ Validator แต่ละคนสามารถทำการโหวตพร้อมกันสำหรับบล็อกที่แตกต่างกันได้ เช่นตัวอย่างด้านบน Validator โหวตรอบแรกให้กับบล็อกที่ k+1 และโหวตรอบสองให้กับบล็อกที่ k พร้อมๆ กัน ทำให้การสื่อสารหรือโต้ตอบมีประสิทธิภาพมากขึ้นและลดความซับซ้อนลง ภาพด้านล่างแสดงการทำงานของ MonadBFT
1.Alice สร้างบล็อกสำหรับรอบที่ k และส่งไปให้ Validator คนอื่นๆ
2.Validator แต่ละคนตรวจสอบความถูกต้องของบล็อก (เช่น Signature) ถ้าหากบล็อกถูกต้อง Validator จะโหวต YES และส่งไปให้กับ Bob ซึ่งเป็น Leader คนถัดไป
3.Bob รวบรวมผลโหวต YES ของบล็อกที่ k และสร้าง QC ซึ่ง QC สำหรับบล็อกที่ k อันนี้จะถูกส่งคู่กับบล็อกใหม่ (บล็อกที่ k+1) ให้กับ Validator คนอื่นๆ ซึ่งเป็นบล็อกที่ Bob สร้างขึ้นมา
4.จากนั้นขั้นตอนจะคล้ายๆ เดิม Validator ตรวจสอบบล็อก โหวต YES และส่งไปให้กับ Charlie ซึ่งเป็น Validator คนถัดไป
5.Charlie รวบรวมผลโหวต YES ของบล็อกที่ k+1 และสร้าง QC ของบล็อกที่ k+1 และส่งคู่กับบล็อกที่ k+2 ไปให้กับ Validator คนอื่นๆ
เมื่อ Validator ได้รับ QC ของบล็อกที่ k+1 แล้ว Validator จะ Commit หรือเพิ่มบล็อกที่ k เข้าไปยังเชนของตน ณ จุดนี้ถ้าหากเกิดเหตุการณ์ที่ Charlie เป็น Leader ที่ไม่หวังดีและส่ง Proposal หรือบล็อกที่ k+2 ไปให้กับ Validator เพียงคนเดียว การที่เขามี QC ของบล็อกที่ k+1 อยู่ในมือจะทำให้เขามั่นใจว่า ถ้าหาก Validator อื่นไม่ได้รับบล็อกนี้ พวกเขาจะยังสามารถย้อนกับไปยังบล็อกที่ k หรือจุดสุดท้ายที่ทุกคน Commit ร่วมกันได้
ลักษณะของการที่ผลโหวตบล็อกที่ k ส่งผลต่อการโหวตบล็อกอื่นๆ นั้นเรียกว่า Pipeline ซึ่งเมื่อนำเอามาใช้กับระบบ Consensus อย่าง MonadBFT แล้วจะช่วยเพิ่มประสิทธิภาพของการประมวลผลได้อย่างมาก ภาพด้านบนแสดงถึง Pipeline ระหว่างผลโหวตของบล็อกต่างกัน จะเห็นได้ว่าในหนึ่งรอบ Validator สามารถทำการโหวตพร้อมกันได้ 3 เฟสสำหรับ 3 บล็อกที่แตกต่างกัน ในรอบที่ k บล็อกที่ k นั้นอยู่ในช่วง Pre-vote (การโหวตรอบแรก) ในขณะที่บล็อกที่ k-1 นั้นอยู่ในช่วง Pre-commit หรือการโหวตรอบที่สอง และบล็อกที่ k-2 นั้นถูก Commit และเพิ่มเข้าไปในเชนของ Validator ที่ได้รับบล็อกนี้ ดังนั้น Validator จะ Commit บล็อกของรอบที่ k เมื่อ QC ของบล็อกที่ k ผ่านการโหวตทั้งหมด 2 รอบและถูกรวมเข้าไปในบล็อกที่ k+2 โครงสร้างแบบนี้ช่วยลดความซับซ้อนของการโต้ตอบโต้ตอบที่ไม่จำเป็นระหว่างการโหวตของบล็อกที่เรียงต่อกันลงได้
2.Deferred Execution
ไอเดียของ Deferred Execution ใน Monad คือการแยก Consensus ออกจาก Execution (การประมวลผลธุรกรรม) สิ่งนี้ช่วยให้โหนดสามารถตกลง (Reach Consensus) เรื่องลำดับของธุรกรรมโดยไม่ต้องรอผลลัพธ์จากการประมวลผล ด้านล่างคือการทำงานของ Deferred Execution
🔸แยก Consensus ออกจาก Execution: สำหรับบล็อกเชนแบบดังเดิมอย่าง Ethereum นั้น Consensus และ Execution จะทำงานด้วยกัน นั่นคือธุรกรรมในบล็อกจะถูกประมวลผลก่อน เพื่อดูว่าสถานะสุดท้ายและธุรกรรมมีความถูกต้องหรือไม่ ก่อนที่จะนำบล็อกนี้มาผ่านระบบ Consensus เพื่อให้แต่ละโหนดทำการโหวตว่าจะใช้บล็อกนี้และลำดับของธุรกรรมเป็นไปตามที่ระบุไว้ในบล็อก แต่ในทางกลับกัน Monad จะให้โหนดนั้นโหวตก่อนว่าจะให้ลำดับของธุรกรรมในบล็อกเป็นแบบไหน โดยที่โหนดไม่จำเป็นต้องประมวลผลธุรกรรมก่อน การทำแบบนี้ช่วยให้ Monad สามารถทำการประมวลผลบล็อกหนึ่งและร่วม Consensus กับบล็อกถัดไปได้พร้อมๆ กัน ซึ่งช่วยให้สามารถใช้ทรัพยากรได้อย่างมีประสิทธิภาพมากขึ้น เนื่องจากการประมวลผลธุรกรรมจะไม่เป็นคอขวดให้แก่การทำ Consensus อีกต่อไป
🔸ผลลัพธ์ที่แน่นอน (Deterministic State): Monad อาศัยหลักการที่ว่าเมื่อลำดับของธุรกรรมถูกกำหนดแล้ว ผลลัพธ์ที่ได้จากการประมวลผลธุรกรรมของเหล่านี้จะแน่นอนไม่เปลี่ยนแปลง ดังนั้นแต่ละโหนดสามารถประมวลผลธุรกรรมโดยไม่ต้องโต้ตอบกัน หลังจากที่ลำดับของธุรกรรมถูกกำหนดโดยโหนดส่วนใหญ่แล้ว
ผลลัพธ์ที่ถูกดีเลย์ (Delayed State Commitment): เพื่อให้มั่นใจว่าทุกโหนดนั้นประมวลผลธุรกรรมอย่างถูกต้องและได้ผลลัพธ์ที่เหมือนกัน รวมถึงป้องกันพฤติกรรมที่ไม่หวังดีจากบางโหนด Monad จึงต้องดีเลย์ผลลัพธ์ของ State Root ออกไป บล็อกจะประกอบด้วย Merkle Root ที่จะถูกดีเลย์ออกไปด้วยจำนวนบล็อกที่กำหนดไว้ เช่น D บล็อก นั่นหมายความว่าสำหรับโหนดที่ไม่ใช่ Full Node จะเห็นสถานะหรือผลลัพธ์ของบล็อกที่ N-D ว่าถูกต้อง ก็ต่อเมื่อเชน Commit (Reach Consensus บน) บล็อกที่ N แล้ว สิ่งนี้ช่วยกระตุ้นให้ผู้ที่ใช้งานเชนรัน Full Node และช่วยเพิ่มความปลอดภัยของเชน นอกจากนี้การที่ Commitment ของ Merkle Root ถูกดีเลย์ออกไปยังช่วยจำกัดจำนวนบล็อกที่ Full Node จะตามหลังไม่ให้สูงเกินไป ส่งผลให้เชนมีความมั่นคงและเสถียร
Defered Execution จึงช่วยให้ Monad สามารถเพิ่มประสิทธิภาพได้ทั้งในด้านความเร็วและ Scalability ด้วยการทำให้ Consensus สามารถทำงานได้อย่างอิสระโดยที่ไม่ต้องรอผลลัพธ์จากการประมวลผล (Execution)
3.Parallel Execution
Parallel Execution นั้นเป็นกุญแจสำคัญใน Monad ที่ช่วยเพิ่มประสิทธิภาพการประมวลผลของธุรกรรมได้อย่างมาก ซึ่ง Monad สามารถประมวลผลหลายๆ ธุรกรรมพร้อมกันได้ โดยการใช้ Optimistic Execution ซึ่งประกอบด้วยสองเฟส
🔸Optimistic Execution: Monad ใช้ Optimistic Execution นั่นคือ Monad จะประมวลผลธุรกรรมไปก่อนโดยคิดว่าทุกธุรกรรมถูกต้อง เพื่อดูว่าแต่ละธุรกรรมขึ้นต่อกันอย่างไร ซึ่งเริ่มโดยการประมวลผลธุรกรรมพร้อมๆ กันโดยที่ไม่รอให้การประมวลผลธุรกรรมก่อนหน้าในบล็อกเดียวกันจบก่อน แต่ในขณะเดียวกันก็คอยดูข้อมูลขาเข้าและขาออกจากการประมวลผลของแต่ละธุรกรรม การทำแบบนี้จะช่วยบอกว่าแต่ละธุรกรรมนั้นขึ้นต่อกันอย่างไร และเมื่อต้องประมวลผลซ้ำอีกครั้ง จะทำให้มีประสิทธิภาพมากขึ้น
🔸การประมวลผลธุรกรรมที่ขึ้นต่อกันซ้ำอีกครั้ง (Re-Execute Dependencies): การดูว่าข้อมูลขาเข้าและขาออกจากการประมวลผลของแต่ละธุรกรรมช่วยให้ Monad สามารถตัดสินได้ว่าธุรกรรมใดที่ขึ้นต่อกันบ้าง โดยการลองประมวลผลจริงและจะช่วยให้สามารถข้ามการประมวลผลแบบเป็นลำดับที่มีความซับซ้อนได้ ในเหตุการณ์ที่มีธุรกรรมที่ขึ้นต่อกันเป็นจำนวนมากติดต่อกัน Optimistic Execution จะมีปัญหาเนื่องจากต้องมีการประมวลผลซ้ำหลายรอบ อย่างไรก็ตามความสวยงานของการใช้ Optimistic Execution คือจะช่วยบังคับให้ระบบเก็บข้อมูลการประมวลผลไว้ชั่วคราว และเมื่อต้องประมวลผลซ้ำอีกครั้งจะสามารถดึงข้อมูลเหล่านี้กลับมาใช้ได้ จึงทำให้การประมวลผลซ้ำอีกครั้งทำได้อย่างมีประสิทธิภาพและไม่กินทรัพยากรณ์
การทำ Parallel Execution ในลักษณะที่กล่าวไว้ข้างต้นช่วยให้ Monad
สามารถเพิ่มความสามารถในการรองรับจำนวนธุรกรรมได้มากขึ้นแล้วยังคงไว้ซึ่งความถูกต้องและผลลัพธ์ที่แน่นอนของการประมวลผลธุรกรรม ซึ่งช่วยเลี่ยงปัญหาของการประมวลผลที่เป็นลำดับที่ซับซ้อน หลักการนี้ช่วยให้ประสบการณ์การใช้งานสำหรับนักพัฒนา EVM ยังเหมือนเดิม หลีกเลี่ยงความจำเป็นที่จะต้องเตรียม Access List เมื่อมีการทำธุรกรรม
4.MonadDB
Ethereum ใช้โครงสร้างข้อมูลที่เรียกว่า Merkle Patricia Tree (MPT) ซึ่งเป็นการผสาน Merkle tree และ Patricia Tree เข้าด้วยกันเพื่อจัดเก็บสถานะของบล็อกเชนและทำให้การหยิบใช้ข้อมูลจาก Tree นั้นมีประสิทธิภาพ รวมถึงป้องกันการดัดแปลงข้อมูลภายใน Tree อย่างไรก็ตามเมื่อ Ethereum Client (โหนด) เก็บ Data เหล่านี้ไว้บนเครื่องตัวเอง จะใช้วิธีการเก็บด้วย Database ธรรมดา อย่าง LevelDB และ RocksDB ซึ่งเป็นวิธีการเก็บข้อมูลแบบทั่วไปที่ใช้ลักษณะ Key-Value ซึ่งจะเก็บข้อมูลไว้ในรูปแบบตาราง แต่ Database เหล่านี้ไม่ได้เข้าใจและไม่ได้ออกแบบมาเพื่อเก็บโครงสร้างแบบ MPT
ด้วยเหตุนี้ Monad จึงสร้าง Database ของตัวเองที่เรียกว่า MonadDb ขึ้นมา ซึ่งถูกออกแบบมาให้เหมาะสมกับโครงสร้างข้อมูลอย่าง MPT และเหมาะสมกับโครงสร้างของ Monad เนื่องจาก Monad ใช้ Parallel Execution จึงมีความจำเป็นที่จะต้องอ่านข้อมูลจากดิสก์แบบ Asynchronous (อ่านหลายๆ ข้อมูลพร้อมๆ กัน) โดยไม่จำเป็นต้องรอให้การดำเนินการอื่นๆ เสร็จสิ้นก่อน แต่ Database ที่กล่าวไว้ด้านบนนั้นไม่ได้รองรับการทำงานแบบนี้ตั้งแต่แรก (สามารถทำได้แต่ไม่ดีมาก) ด้วยการใช้ Async I/O ตัวล่าสุดจึงทำให้ Monad สามารถหลีกเลี่ยงคอขวดจากการที่ระบบต้องรอให้การดำเนินการอันหนึ่งเสร็จก่อน ก่อนที่จะสามารถดำเนินการอันถัดไปได้ ส่งผลให้สามารถทำงานในรูปแบบ Asynchronous ได้
References
[1] https://t.co/cTcUu88BBt
[2] https://t.co/jem0J92q1b
[3] https://t.co/ylGS3u0XUw
___________________________________
มีกิจกรรมอะไรให้ร่วมบ้าง1. Social Credit Score : วิธีเข้าร่วม
1.ติดตาม Social media of Monad team
- Join Monad Thailand telegram official by monad team : https://t.co/Z2WobNhQQ2
- Join Monad Discord : https://t.co/ptVMMrGqwo
- พูดคุยใน Monad discord เพื่อให้ได้ Lv6
2.NFT / Poap จากการร่วมกิจกรรม event community เช่น Poker / สร้าง meme
*Cr.picture by Monad community
3. Meme master : สร้างมีมที่คุณภาพ เพื่อโพสลง Twitter ส่วนตัว + Monad discord
*สร้าง monad meme ได้ที่ :
https://t.co/e0PaMAQmQI
#monad #gmonad #gnad](https://pbs.twimg.com/media/GA1AA-2awAAKiZg.jpg)
Olivia
Online
Dog(🌸, 🌿)
@wchakris_
Joined May 2021
272 Following
43 Followers
316 Posts
Cypher แจก ETH บน Base สำหรับใช้เป็นค่า gas เคลม airdrop $CYPR 💸
🕔 เจอกันเวลา 17.00 น. วันนี้
📈 ราคา pre-market บน MEXC อยู่ที่ $0.34 (≈11 บาท/CYPR)
ใครยังไม่มีบัตร 💳 รีบไปสมัครเลยครับ season 2 เริ่มแล้ว 👉 https://t.co/jYcuWxL0KH
🔥 ไม่แน่… บัตรนี้อาจกลายเป็น “บัตรที่ Cashback สูงที่สุดในโลกคริปโต” ก็ได้ 😏💰
เหรียญที่ 2 ที่จะ list บน Aerodrome คือ Phi protocol @phi_xyz ตามแผนคือ จะลิสต์ภายในตุลาคม 2025 นี้ครับ
สำหรับ CEX อาจจะลิสต์ในอนาคตเมื่อตอนที่โปรโตคอลเข้าสู่ภาวะเติบโตอย่างมั่นคงแล้ว…
หุ้นนี้…
- ไม่ใช่หุ้นชิป
- ไม่ใช่หุ้น Cloud
- ถ้าไม่มีมัน Data Centers จะร้อนจนล่ม
- AI ต้องพึ่งพามันทุกวินาที
EPS ล่าสุด 0.95$
รายได้ 2.64B โต +35% YoY
นักวิเคราะห์ให้เป้า 146–157$
แต่คนส่วนใหญ่ยังไม่รู้ว่าหุ้นนี้ทำอะไรด้วยซ้ำ
ถ้า AI คือเครื่องยนต์ มันคือ ‘ระบบหล่อเย็น’ และพลังงานที่ทำให้วิ่งได้ไม่มีวันหยุด
ใครซับผมอยู่ใน Ko-fi เข้าไปอ่านกันได้นะครับ ที่ลิ้งค์หน้าโปรไฟล์เลยครับ
คนถือ veAero , WELL, VIRTUAL ไป check airdrop MAMO กันด้วยนะครับ
เผื่อได้ค่าขนมกันนิดหน่อย
https://t.co/Nv3IJ5ONnB
Who to follow
PENTHOUS BLU
@EXECUTIVCHEVY
what is reality. i’ve seen all and nothing at all. red ambient lights in the big body for LR #LONGLIVELR BRICCOLA JOKABITCH
ShadowIllusion15
@Shadow819978292
Living life is sometimes tiring. But what we can do is Must move through quickly. And enjoy living life.
D-K | 廸特任
@KlCrypto
AI Automation Strategist | Turning Manual Businesses into Intelligent Operations
Dear Manchester. 💙
https://t.co/vcA9g2TrCd
I just pre-ordered a dGEN1!
Use my referral code "U5ODYz" to get 5% off.
https://t.co/JwySASa2dy
Introducing dGEN1
The first onchain every-day carry
Important Update: Early contributors, you now have until September 13, 2024, to verify your eligibility for the Season 2 Stakedrop and claim your EIGEN tokens!
🔗 https://t.co/P3BTdEqnTF
Claims open on or before September 17, 2024.
⏰ Final Call!
Less than a day left to claim your Season 1 EIGEN stakedrop!
Make sure to claim by 11:59 pm PST on September 7th, 2024.
Claim here: https://t.co/VR4hs4ASFs
1/ BASE เชน Layer 2 ที่กำลังร้อนแรง จะมีเหรียญไหม ?
หากเรามองในเชิงความกาวนั้น Base เป็นของบริษัท Coinbase ซึ่งมีหุ้นของตัวเองบนตลาด Nasdaq โดยมี Ticker ชื่อว่า $COIN ส่วน Base ก็น่าจะมีเหรียญของตัวเองชื่อ $BASE ซึ่งเมื่อมีครบทั้งสองนั้นมันจะเป็นอะไรที่ Perfect มากนั่นก็คือ $COIN + $BASE แต่นี่เป็นเพียงความกาวนึงซึ่งไม่ได้มีข้อมูลมา Support
#Base #Coinbase #Layer2 #ETH
เช็คจำนวน $OMNI ล่าสุดที่มีการปรับจำนวนเพิ่มขึ้น
👉 https://t.co/fJsJPqo6ri
:
แอดทำ 2 กระเป๋า; ใบแรก ได้เพิ่มมา 6 เม็ด
อีกใบจากที่ไม่ได้ รอบนี้ได้มา 7 เม็ด (ยื่นฎีกาแล้ว)
Monad Layer 1 : [ กาวกระป๋องใหญ่ ทำไมถึงน่าสนใจในปี 2024 ? ] + How to Contribute with Monad Project
TL : DR [ ยาวไป ไม่อ่าน เลยมาสรุปให้ ]
ปล.ใครอยาก อ่านแบบยาวๆ และรูปฮาๆ เยอะ อ่านได้ที่นี่ : https://t.co/i9R2JKyF6J
1.Monad Layer 1 ที่ถูกออกแบบมาให้เข้ากันได้กับ EVM อย่างสมบูรณ์แบบ ทำให้ Tools , Stack , Programming ที่เป็น EVM สามารถเคลื่อนย้ายมายัง Monad ได้ราวกับกระพริบตา
*พร้อมกับความสามารถ Parallel execution [Monad คือ ETH + Solana]
2.The new innovative of monad ที่เข้ามาแก้ปัญหาของ Web3 Infrastructure เช่น
🔸 แก๊สแพง - Gas costs
🔸 ความความปลอดภัย - Security risks
🔸 ข้อจำกัดของที่เก็บข้อมูล - Limited storage
🔸 ปัญหา Mempool
🔸 การกระจายตัวของสภาพคล่อง - Liquidity Fragmented
🔸 ขาด Resource - Lack of Tools
🔸 Upgradability challenges
🔸 Interoperability issues
- 2.1 MonadBFT = ระบบ Consensus ใหม่ของ Monad ที่ช่วยให้มี TPS มากกว่า 10,000 + และ Finality ที่ต่ำมาก
- 2.2 Defered Execution = การแยก Execution และ Consensus Logic ออกจากกัน ทำให้ทั้งสองสามารถทำงาน พร้อมๆ กันได้
- 2.3 Optimistc Parallel Execution ที่ช่วยให้ Monad สามารถหลีกเลี่ยงการประมวลผลแบบเป็นลำดับที่ซับซ้อนและเตรียม Access List ที่ยุ่งยากได้
- 2.4 MonadDB ซึ่งเป็น Database ที่ถูกออกแบบโดย Monad ให้เหมาะกับโครงสร้างข้อมูลที่ Ethereum ใช้อยู่ รวมทั้งยังช่วยอำนวยความสะดวกในการดำเนินการต่างๆ ที่เป็นแบบ Parallel อีกด้วย
*Cr.picture by Monad community
3.ระดมทุนได้มากกว่า $19m Seedround
4.มีกิจกรรมให้ Contribute [ดูเพิ่มเติมได้ที่ย่อหน้าสุดท้าย]
5.มีมากกว่า 40 projects ที่ confirmed ว่าจะเชื่อมกับ Monad
6. Community First , Deep technology together. [โปรเจคแรกของโลก ที่ Design Project ให้สอดคล้องกับ Web3 Culture คือ Game theory]
***เพียงแค่ จินตนาการว่า มันคือ Deep Tech + Meme + community = กาวกระป๋องใหญ่
7. Good team
@monad_xyz
@keoneHD
@IcedQuad
@zen_llama
@_jhunsaker
@port_dev
@billmondays
____________________________________________
มาดู Research ฉบับเข้าใจง่ายกันเถอะ
Monad Introduction
หากพูดถึงบล็อกเชนที่มีความนิยมสูงสุดคงหนีไม่พ้นบล็อกเชนอย่าง Ethereum ไม่เพียงแต่จะเป็นศูนย์รวมของงานวิจัย, การพัฒนา, dApp และคอมมูนิตี้ต่างๆ แต่ยังถือครอง TVL ที่สูงที่สุดอีกด้วย สิ่งต่างๆ เหล่านี้ได้ตอกย้ำว่า Ethereum นั้นมีบทบาทที่สำคัญต่อโลกของบล็อกเชนเพียงใด อย่างไรก็ตาม Ethereum ก็มีข้อจำกัดที่หลายคนรู้กันดี นั่นก็คือค่าแก๊สที่แพง, TPS (จำนวนธุรกรรมต่อวินาที) ที่ต่ำ และ Finality ที่นาน สิ่งเหล่านี้มีแต่จะทำให้ประสบการณ์ของผู้ใช้งานและนักพัฒนาแย่ลงเรื่อยๆ
ด้วยเหตุนี้โปรเจกต์ต่างๆ จึงแข่งขันกันเพื่อหาแนวทางใหม่ที่จะมาแก้ปัญหาที่ Ethereum ต้องเผชิญ แต่ด้วยการที่เชนใหม่ๆ พัฒนาและใช้เทคโนโลยีที่เหมาะสมกับการทำงานเฉพาะด้านของตน จึงส่งผลให้เกิดผลเสียใหม่ที่ตามมา นั้นก็คือความไม่เข้ากันกับ EVM (ไม่สามารถทำงานเชนที่เป็น EVM ได้ โดยเฉพาะ Ethereum) EVM compatibility หรือความเข้ากันได้กับ EVM นั้นเป็นสิ่งสำคัญ เนื่องจากเครื่องมือในบล็อกเชนที่ใช้งานกันส่วนใหญ่ถูกออกแบบมาให้เหมาะสมกับ EVM และโครงสร้างของ Ethereum ดังนั้นเมื่อบล็อกเชนเลเยอร์ 1 ที่ไม่เข้ากันกับ EVM เกิดขึ้นมาจะนำไปสู่การพัฒนาเครื่องมือใหม่ๆ ทำให้นักพัฒนาและผู้ใช้ต้องปรับตัวเข้ากับสภาพแวดล้อมที่แตกต่างไปจากเดิมอย่างสิ้นเชิง นอกจากนี้ความเข้ากันได้กับ EVM ยังช่วยลดความยุ่งยากในการย้าย dApps ที่มีอยู่แล้วบน Ethereum มายังเชนใหม่ได้โดยที่นักพัฒนาไม่ต้องมาเริ่มนับหนึ่งใหม่ตั้งแต่ต้น
Monad - บล็อกเชนเลเยอร์ 1 ที่มีความเร็วสูง, Finality ที่ต่ำ และเข้ากันได้กับ EVM โดยสมบูรณ์
Monad เป็นบล็อกเชนเลเยอร์หนึ่งที่เข้ากันได้กับ EVM อย่างสมบูรณ์ (Fully EVM compatible) สามารถรองรับจำนวนธุรกรรมต่อวินาทีได้สูง และมี Finality ที่ต่ำ Monad สามารถทำสิ่งเหล่านี้ได้โดยการปรับปรุงประสิทธิภาพใน 4 ด้านหลักๆ คือ
1.MonadBFT
2.Deferred Execution
3.Parallel Execution
4.MonadDb
ฟีเจอร์เหล่านี้ช่วยให้ Monad สามารถรองรับธุรกรรมได้มากถึง 10,000 ธุรกรรมต่อวินาทีและมี Finality อยู่ที่ประมาณ 1 วินาธีเท่านั้น ในบทความนี้เราจะมาเจาะลึกกันว่าแต่ละฟีเจอร์ทำงานอย่างไรและช่วยเพิ่มประสิทธิภาพให้แก่ Monad ได้อย่างไร
1.MonadBFT
ถ้าหากคุณรู้ว่า Tendermint และ Hotstuff ทำงานอย่างไร คุณจะทำความเข้าใจ MonadBFT ได้ง่ายมาก แต่ถ้าไม่รู้จักไม่เป็นไร ในบทความนี้เราจะอธิบายให้ฟังเอง Tendermint เป็น Consensus หลักที่ใช้ในระบบนิเวศของเชน Cosmos ซึ่งการที่ Validator จะตัดสินใจว่าบล็อกไหนนั้นจะถูกเพิ่มเข้าไปบนบล็อกเชนหรือ Commit จะต้องผ่านการโหวตทั้งหมด 3 เฟสด้วยกัน ได้แก่ Propose, Pre-vote และ Pre-commit โดยเริ่มแรกของแต่ละบล็อก Leader (คนที่ถูกเลือกจาก Validator ทั้งหมด) จะเป็นคนที่เสนอบล็อกของตัวเองและส่งไปให้ Validator คนอื่นๆ เมื่อ Validator ได้รับบล็อกแล้วจะทำการโหวตโดยการแลกเปลี่ยนข้อความระหว่าง Validator ด้วยกันเอง เมื่อตกลงกันได้แล้วจึงจะทำการ Commit บล็อกๆ นั้น การที่ Validator โต้ตอบโดยการแลกเปลี่ยนข้อความกันไปกันมานี้ทำให้การสื่อสารมีความซับซ้อนแบบยกกำลังสอง (O(n²)) หรือก็คือ ถ้าหากมี Validator อยู่ n คน Validator 1 คนจะต้องส่งข้อความไปหาคนอื่น n-1 คน ดังนั้นข้อความทั้งหมดที่ต้องส่งสำหรับ Validator n คนก็คือ n²-n ใน Tendermint นั้น Validator จะเริ่มโหวตบล็อกใหม่เมื่อบล็อกเก่าเสร็จสิ้นแล้วเท่านั้น
ในทางกลับกัน MonadBFT จะใช้การโต้ตอบแบบสองเฟสก่อน Commit โดยมี Leader เป็นศูนย์กลาง ในแต่ละรอบจะมีการเปลี่ยน Leader ไปเรื่อยๆ และ Validator จะส่งผลโหวตไปให้ Leader คนถัดไปได้โดยที่ไม่ต้องรอให้บล็อกปัจจุบันนั้นจบหรือ Commit ก่อน เมื่อ Leader เสนอ (Propose) บล็อกในรอบที่ k และส่งไปให้กับ Validator คนอื่นๆ แล้ว Validator แต่ละคนจะส่งผลโหวตของบล็อกที่ k ไปให้กับ Leader คนถัดไป (คนที่จะเสนอบล็อกที่ k+1) โดย Leader คนใหม่นี้จะรวบรวมเอาผลโหวตของบล็อกที่ k จาก Validator มาสร้างเป็น Quorum Certificate หรือ QC (เหมือนเป็นใบยืนยันว่าบล็อกนั้นได้รับการโหวตว่าถูกต้องจากเสียงส่วนมากของ Validator) สำหรับบล็อกที่ k (จบเฟสแรกสำหรับบล็อก k) จากนั้น Leader สร้างบล็อกที่ k+1 โดยรวมเอา QC ของบล็อกที่ k เข้าไปด้วย ก่อนที่จะส่งให้ Validator คนอื่นๆ เมื่อ Validator คนอื่นๆ ได้รับแล้วก็จะทำหน้าที่เหมือนเดิมคือ โหวตให้กับบล็อกที่ k+1 แต่เนื่องจากบล็อกนี้มี QC ของบล็อกที่ k ด้วยจึงเป็นการโหวตรอบที่สองให้กับบล็อกที่ k ไปในตัว และส่งกลับไปให้ Leader คนถัดไป โดย Validator จะ Commit บล็อกที่ k เมื่อได้รับบล็อกของรอบที่ k+2 แล้ว ด้วยโครงสร้างแบบนี้จะทำให้ Validator แต่ละคนสามารถทำการโหวตพร้อมกันสำหรับบล็อกที่แตกต่างกันได้ เช่นตัวอย่างด้านบน Validator โหวตรอบแรกให้กับบล็อกที่ k+1 และโหวตรอบสองให้กับบล็อกที่ k พร้อมๆ กัน ทำให้การสื่อสารหรือโต้ตอบมีประสิทธิภาพมากขึ้นและลดความซับซ้อนลง ภาพด้านล่างแสดงการทำงานของ MonadBFT
1.Alice สร้างบล็อกสำหรับรอบที่ k และส่งไปให้ Validator คนอื่นๆ
2.Validator แต่ละคนตรวจสอบความถูกต้องของบล็อก (เช่น Signature) ถ้าหากบล็อกถูกต้อง Validator จะโหวต YES และส่งไปให้กับ Bob ซึ่งเป็น Leader คนถัดไป
3.Bob รวบรวมผลโหวต YES ของบล็อกที่ k และสร้าง QC ซึ่ง QC สำหรับบล็อกที่ k อันนี้จะถูกส่งคู่กับบล็อกใหม่ (บล็อกที่ k+1) ให้กับ Validator คนอื่นๆ ซึ่งเป็นบล็อกที่ Bob สร้างขึ้นมา
4.จากนั้นขั้นตอนจะคล้ายๆ เดิม Validator ตรวจสอบบล็อก โหวต YES และส่งไปให้กับ Charlie ซึ่งเป็น Validator คนถัดไป
5.Charlie รวบรวมผลโหวต YES ของบล็อกที่ k+1 และสร้าง QC ของบล็อกที่ k+1 และส่งคู่กับบล็อกที่ k+2 ไปให้กับ Validator คนอื่นๆ
เมื่อ Validator ได้รับ QC ของบล็อกที่ k+1 แล้ว Validator จะ Commit หรือเพิ่มบล็อกที่ k เข้าไปยังเชนของตน ณ จุดนี้ถ้าหากเกิดเหตุการณ์ที่ Charlie เป็น Leader ที่ไม่หวังดีและส่ง Proposal หรือบล็อกที่ k+2 ไปให้กับ Validator เพียงคนเดียว การที่เขามี QC ของบล็อกที่ k+1 อยู่ในมือจะทำให้เขามั่นใจว่า ถ้าหาก Validator อื่นไม่ได้รับบล็อกนี้ พวกเขาจะยังสามารถย้อนกับไปยังบล็อกที่ k หรือจุดสุดท้ายที่ทุกคน Commit ร่วมกันได้
ลักษณะของการที่ผลโหวตบล็อกที่ k ส่งผลต่อการโหวตบล็อกอื่นๆ นั้นเรียกว่า Pipeline ซึ่งเมื่อนำเอามาใช้กับระบบ Consensus อย่าง MonadBFT แล้วจะช่วยเพิ่มประสิทธิภาพของการประมวลผลได้อย่างมาก ภาพด้านบนแสดงถึง Pipeline ระหว่างผลโหวตของบล็อกต่างกัน จะเห็นได้ว่าในหนึ่งรอบ Validator สามารถทำการโหวตพร้อมกันได้ 3 เฟสสำหรับ 3 บล็อกที่แตกต่างกัน ในรอบที่ k บล็อกที่ k นั้นอยู่ในช่วง Pre-vote (การโหวตรอบแรก) ในขณะที่บล็อกที่ k-1 นั้นอยู่ในช่วง Pre-commit หรือการโหวตรอบที่สอง และบล็อกที่ k-2 นั้นถูก Commit และเพิ่มเข้าไปในเชนของ Validator ที่ได้รับบล็อกนี้ ดังนั้น Validator จะ Commit บล็อกของรอบที่ k เมื่อ QC ของบล็อกที่ k ผ่านการโหวตทั้งหมด 2 รอบและถูกรวมเข้าไปในบล็อกที่ k+2 โครงสร้างแบบนี้ช่วยลดความซับซ้อนของการโต้ตอบโต้ตอบที่ไม่จำเป็นระหว่างการโหวตของบล็อกที่เรียงต่อกันลงได้
2.Deferred Execution
ไอเดียของ Deferred Execution ใน Monad คือการแยก Consensus ออกจาก Execution (การประมวลผลธุรกรรม) สิ่งนี้ช่วยให้โหนดสามารถตกลง (Reach Consensus) เรื่องลำดับของธุรกรรมโดยไม่ต้องรอผลลัพธ์จากการประมวลผล ด้านล่างคือการทำงานของ Deferred Execution
🔸แยก Consensus ออกจาก Execution: สำหรับบล็อกเชนแบบดังเดิมอย่าง Ethereum นั้น Consensus และ Execution จะทำงานด้วยกัน นั่นคือธุรกรรมในบล็อกจะถูกประมวลผลก่อน เพื่อดูว่าสถานะสุดท้ายและธุรกรรมมีความถูกต้องหรือไม่ ก่อนที่จะนำบล็อกนี้มาผ่านระบบ Consensus เพื่อให้แต่ละโหนดทำการโหวตว่าจะใช้บล็อกนี้และลำดับของธุรกรรมเป็นไปตามที่ระบุไว้ในบล็อก แต่ในทางกลับกัน Monad จะให้โหนดนั้นโหวตก่อนว่าจะให้ลำดับของธุรกรรมในบล็อกเป็นแบบไหน โดยที่โหนดไม่จำเป็นต้องประมวลผลธุรกรรมก่อน การทำแบบนี้ช่วยให้ Monad สามารถทำการประมวลผลบล็อกหนึ่งและร่วม Consensus กับบล็อกถัดไปได้พร้อมๆ กัน ซึ่งช่วยให้สามารถใช้ทรัพยากรได้อย่างมีประสิทธิภาพมากขึ้น เนื่องจากการประมวลผลธุรกรรมจะไม่เป็นคอขวดให้แก่การทำ Consensus อีกต่อไป
🔸ผลลัพธ์ที่แน่นอน (Deterministic State): Monad อาศัยหลักการที่ว่าเมื่อลำดับของธุรกรรมถูกกำหนดแล้ว ผลลัพธ์ที่ได้จากการประมวลผลธุรกรรมของเหล่านี้จะแน่นอนไม่เปลี่ยนแปลง ดังนั้นแต่ละโหนดสามารถประมวลผลธุรกรรมโดยไม่ต้องโต้ตอบกัน หลังจากที่ลำดับของธุรกรรมถูกกำหนดโดยโหนดส่วนใหญ่แล้ว
ผลลัพธ์ที่ถูกดีเลย์ (Delayed State Commitment): เพื่อให้มั่นใจว่าทุกโหนดนั้นประมวลผลธุรกรรมอย่างถูกต้องและได้ผลลัพธ์ที่เหมือนกัน รวมถึงป้องกันพฤติกรรมที่ไม่หวังดีจากบางโหนด Monad จึงต้องดีเลย์ผลลัพธ์ของ State Root ออกไป บล็อกจะประกอบด้วย Merkle Root ที่จะถูกดีเลย์ออกไปด้วยจำนวนบล็อกที่กำหนดไว้ เช่น D บล็อก นั่นหมายความว่าสำหรับโหนดที่ไม่ใช่ Full Node จะเห็นสถานะหรือผลลัพธ์ของบล็อกที่ N-D ว่าถูกต้อง ก็ต่อเมื่อเชน Commit (Reach Consensus บน) บล็อกที่ N แล้ว สิ่งนี้ช่วยกระตุ้นให้ผู้ที่ใช้งานเชนรัน Full Node และช่วยเพิ่มความปลอดภัยของเชน นอกจากนี้การที่ Commitment ของ Merkle Root ถูกดีเลย์ออกไปยังช่วยจำกัดจำนวนบล็อกที่ Full Node จะตามหลังไม่ให้สูงเกินไป ส่งผลให้เชนมีความมั่นคงและเสถียร
Defered Execution จึงช่วยให้ Monad สามารถเพิ่มประสิทธิภาพได้ทั้งในด้านความเร็วและ Scalability ด้วยการทำให้ Consensus สามารถทำงานได้อย่างอิสระโดยที่ไม่ต้องรอผลลัพธ์จากการประมวลผล (Execution)
3.Parallel Execution
Parallel Execution นั้นเป็นกุญแจสำคัญใน Monad ที่ช่วยเพิ่มประสิทธิภาพการประมวลผลของธุรกรรมได้อย่างมาก ซึ่ง Monad สามารถประมวลผลหลายๆ ธุรกรรมพร้อมกันได้ โดยการใช้ Optimistic Execution ซึ่งประกอบด้วยสองเฟส
🔸Optimistic Execution: Monad ใช้ Optimistic Execution นั่นคือ Monad จะประมวลผลธุรกรรมไปก่อนโดยคิดว่าทุกธุรกรรมถูกต้อง เพื่อดูว่าแต่ละธุรกรรมขึ้นต่อกันอย่างไร ซึ่งเริ่มโดยการประมวลผลธุรกรรมพร้อมๆ กันโดยที่ไม่รอให้การประมวลผลธุรกรรมก่อนหน้าในบล็อกเดียวกันจบก่อน แต่ในขณะเดียวกันก็คอยดูข้อมูลขาเข้าและขาออกจากการประมวลผลของแต่ละธุรกรรม การทำแบบนี้จะช่วยบอกว่าแต่ละธุรกรรมนั้นขึ้นต่อกันอย่างไร และเมื่อต้องประมวลผลซ้ำอีกครั้ง จะทำให้มีประสิทธิภาพมากขึ้น
🔸การประมวลผลธุรกรรมที่ขึ้นต่อกันซ้ำอีกครั้ง (Re-Execute Dependencies): การดูว่าข้อมูลขาเข้าและขาออกจากการประมวลผลของแต่ละธุรกรรมช่วยให้ Monad สามารถตัดสินได้ว่าธุรกรรมใดที่ขึ้นต่อกันบ้าง โดยการลองประมวลผลจริงและจะช่วยให้สามารถข้ามการประมวลผลแบบเป็นลำดับที่มีความซับซ้อนได้ ในเหตุการณ์ที่มีธุรกรรมที่ขึ้นต่อกันเป็นจำนวนมากติดต่อกัน Optimistic Execution จะมีปัญหาเนื่องจากต้องมีการประมวลผลซ้ำหลายรอบ อย่างไรก็ตามความสวยงานของการใช้ Optimistic Execution คือจะช่วยบังคับให้ระบบเก็บข้อมูลการประมวลผลไว้ชั่วคราว และเมื่อต้องประมวลผลซ้ำอีกครั้งจะสามารถดึงข้อมูลเหล่านี้กลับมาใช้ได้ จึงทำให้การประมวลผลซ้ำอีกครั้งทำได้อย่างมีประสิทธิภาพและไม่กินทรัพยากรณ์
การทำ Parallel Execution ในลักษณะที่กล่าวไว้ข้างต้นช่วยให้ Monad
สามารถเพิ่มความสามารถในการรองรับจำนวนธุรกรรมได้มากขึ้นแล้วยังคงไว้ซึ่งความถูกต้องและผลลัพธ์ที่แน่นอนของการประมวลผลธุรกรรม ซึ่งช่วยเลี่ยงปัญหาของการประมวลผลที่เป็นลำดับที่ซับซ้อน หลักการนี้ช่วยให้ประสบการณ์การใช้งานสำหรับนักพัฒนา EVM ยังเหมือนเดิม หลีกเลี่ยงความจำเป็นที่จะต้องเตรียม Access List เมื่อมีการทำธุรกรรม
4.MonadDB
Ethereum ใช้โครงสร้างข้อมูลที่เรียกว่า Merkle Patricia Tree (MPT) ซึ่งเป็นการผสาน Merkle tree และ Patricia Tree เข้าด้วยกันเพื่อจัดเก็บสถานะของบล็อกเชนและทำให้การหยิบใช้ข้อมูลจาก Tree นั้นมีประสิทธิภาพ รวมถึงป้องกันการดัดแปลงข้อมูลภายใน Tree อย่างไรก็ตามเมื่อ Ethereum Client (โหนด) เก็บ Data เหล่านี้ไว้บนเครื่องตัวเอง จะใช้วิธีการเก็บด้วย Database ธรรมดา อย่าง LevelDB และ RocksDB ซึ่งเป็นวิธีการเก็บข้อมูลแบบทั่วไปที่ใช้ลักษณะ Key-Value ซึ่งจะเก็บข้อมูลไว้ในรูปแบบตาราง แต่ Database เหล่านี้ไม่ได้เข้าใจและไม่ได้ออกแบบมาเพื่อเก็บโครงสร้างแบบ MPT
ด้วยเหตุนี้ Monad จึงสร้าง Database ของตัวเองที่เรียกว่า MonadDb ขึ้นมา ซึ่งถูกออกแบบมาให้เหมาะสมกับโครงสร้างข้อมูลอย่าง MPT และเหมาะสมกับโครงสร้างของ Monad เนื่องจาก Monad ใช้ Parallel Execution จึงมีความจำเป็นที่จะต้องอ่านข้อมูลจากดิสก์แบบ Asynchronous (อ่านหลายๆ ข้อมูลพร้อมๆ กัน) โดยไม่จำเป็นต้องรอให้การดำเนินการอื่นๆ เสร็จสิ้นก่อน แต่ Database ที่กล่าวไว้ด้านบนนั้นไม่ได้รองรับการทำงานแบบนี้ตั้งแต่แรก (สามารถทำได้แต่ไม่ดีมาก) ด้วยการใช้ Async I/O ตัวล่าสุดจึงทำให้ Monad สามารถหลีกเลี่ยงคอขวดจากการที่ระบบต้องรอให้การดำเนินการอันหนึ่งเสร็จก่อน ก่อนที่จะสามารถดำเนินการอันถัดไปได้ ส่งผลให้สามารถทำงานในรูปแบบ Asynchronous ได้
References
[1] https://t.co/cTcUu88BBt
[2] https://t.co/jem0J92q1b
[3] https://t.co/ylGS3u0XUw
___________________________________
มีกิจกรรมอะไรให้ร่วมบ้าง1. Social Credit Score : วิธีเข้าร่วม
1.ติดตาม Social media of Monad team
- Join Monad Thailand telegram official by monad team : https://t.co/Z2WobNhQQ2
- Join Monad Discord : https://t.co/ptVMMrGqwo
- พูดคุยใน Monad discord เพื่อให้ได้ Lv6
2.NFT / Poap จากการร่วมกิจกรรม event community เช่น Poker / สร้าง meme
*Cr.picture by Monad community
3. Meme master : สร้างมีมที่คุณภาพ เพื่อโพสลง Twitter ส่วนตัว + Monad discord
*สร้าง monad meme ได้ที่ :
https://t.co/e0PaMAQmQI
#monad #gmonad #gnad
![contributedao's tweet photo. Monad Layer 1 : [ กาวกระป๋องใหญ่ ทำไมถึงน่าสนใจในปี 2024 ? ] + How to Contribute with Monad Project
TL : DR [ ยาวไป ไม่อ่าน เลยมาสรุปให้ ]
ปล.ใครอยาก อ่านแบบยาวๆ และรูปฮาๆ เยอะ อ่านได้ที่นี่ : https://t.co/i9R2JKyF6J
1.Monad Layer 1 ที่ถูกออกแบบมาให้เข้ากันได้กับ EVM อย่างสมบูรณ์แบบ ทำให้ Tools , Stack , Programming ที่เป็น EVM สามารถเคลื่อนย้ายมายัง Monad ได้ราวกับกระพริบตา
*พร้อมกับความสามารถ Parallel execution [Monad คือ ETH + Solana]
2.The new innovative of monad ที่เข้ามาแก้ปัญหาของ Web3 Infrastructure เช่น
🔸 แก๊สแพง - Gas costs
🔸 ความความปลอดภัย - Security risks
🔸 ข้อจำกัดของที่เก็บข้อมูล - Limited storage
🔸 ปัญหา Mempool
🔸 การกระจายตัวของสภาพคล่อง - Liquidity Fragmented
🔸 ขาด Resource - Lack of Tools
🔸 Upgradability challenges
🔸 Interoperability issues
- 2.1 MonadBFT = ระบบ Consensus ใหม่ของ Monad ที่ช่วยให้มี TPS มากกว่า 10,000 + และ Finality ที่ต่ำมาก
- 2.2 Defered Execution = การแยก Execution และ Consensus Logic ออกจากกัน ทำให้ทั้งสองสามารถทำงาน พร้อมๆ กันได้
- 2.3 Optimistc Parallel Execution ที่ช่วยให้ Monad สามารถหลีกเลี่ยงการประมวลผลแบบเป็นลำดับที่ซับซ้อนและเตรียม Access List ที่ยุ่งยากได้
- 2.4 MonadDB ซึ่งเป็น Database ที่ถูกออกแบบโดย Monad ให้เหมาะกับโครงสร้างข้อมูลที่ Ethereum ใช้อยู่ รวมทั้งยังช่วยอำนวยความสะดวกในการดำเนินการต่างๆ ที่เป็นแบบ Parallel อีกด้วย
*Cr.picture by Monad community
3.ระดมทุนได้มากกว่า $19m Seedround
4.มีกิจกรรมให้ Contribute [ดูเพิ่มเติมได้ที่ย่อหน้าสุดท้าย]
5.มีมากกว่า 40 projects ที่ confirmed ว่าจะเชื่อมกับ Monad
6. Community First , Deep technology together. [โปรเจคแรกของโลก ที่ Design Project ให้สอดคล้องกับ Web3 Culture คือ Game theory]
***เพียงแค่ จินตนาการว่า มันคือ Deep Tech + Meme + community = กาวกระป๋องใหญ่
7. Good team
@monad_xyz
@keoneHD
@IcedQuad
@zen_llama
@_jhunsaker
@port_dev
@billmondays
____________________________________________
มาดู Research ฉบับเข้าใจง่ายกันเถอะ
Monad Introduction
หากพูดถึงบล็อกเชนที่มีความนิยมสูงสุดคงหนีไม่พ้นบล็อกเชนอย่าง Ethereum ไม่เพียงแต่จะเป็นศูนย์รวมของงานวิจัย, การพัฒนา, dApp และคอมมูนิตี้ต่างๆ แต่ยังถือครอง TVL ที่สูงที่สุดอีกด้วย สิ่งต่างๆ เหล่านี้ได้ตอกย้ำว่า Ethereum นั้นมีบทบาทที่สำคัญต่อโลกของบล็อกเชนเพียงใด อย่างไรก็ตาม Ethereum ก็มีข้อจำกัดที่หลายคนรู้กันดี นั่นก็คือค่าแก๊สที่แพง, TPS (จำนวนธุรกรรมต่อวินาที) ที่ต่ำ และ Finality ที่นาน สิ่งเหล่านี้มีแต่จะทำให้ประสบการณ์ของผู้ใช้งานและนักพัฒนาแย่ลงเรื่อยๆ
ด้วยเหตุนี้โปรเจกต์ต่างๆ จึงแข่งขันกันเพื่อหาแนวทางใหม่ที่จะมาแก้ปัญหาที่ Ethereum ต้องเผชิญ แต่ด้วยการที่เชนใหม่ๆ พัฒนาและใช้เทคโนโลยีที่เหมาะสมกับการทำงานเฉพาะด้านของตน จึงส่งผลให้เกิดผลเสียใหม่ที่ตามมา นั้นก็คือความไม่เข้ากันกับ EVM (ไม่สามารถทำงานเชนที่เป็น EVM ได้ โดยเฉพาะ Ethereum) EVM compatibility หรือความเข้ากันได้กับ EVM นั้นเป็นสิ่งสำคัญ เนื่องจากเครื่องมือในบล็อกเชนที่ใช้งานกันส่วนใหญ่ถูกออกแบบมาให้เหมาะสมกับ EVM และโครงสร้างของ Ethereum ดังนั้นเมื่อบล็อกเชนเลเยอร์ 1 ที่ไม่เข้ากันกับ EVM เกิดขึ้นมาจะนำไปสู่การพัฒนาเครื่องมือใหม่ๆ ทำให้นักพัฒนาและผู้ใช้ต้องปรับตัวเข้ากับสภาพแวดล้อมที่แตกต่างไปจากเดิมอย่างสิ้นเชิง นอกจากนี้ความเข้ากันได้กับ EVM ยังช่วยลดความยุ่งยากในการย้าย dApps ที่มีอยู่แล้วบน Ethereum มายังเชนใหม่ได้โดยที่นักพัฒนาไม่ต้องมาเริ่มนับหนึ่งใหม่ตั้งแต่ต้น
Monad - บล็อกเชนเลเยอร์ 1 ที่มีความเร็วสูง, Finality ที่ต่ำ และเข้ากันได้กับ EVM โดยสมบูรณ์
Monad เป็นบล็อกเชนเลเยอร์หนึ่งที่เข้ากันได้กับ EVM อย่างสมบูรณ์ (Fully EVM compatible) สามารถรองรับจำนวนธุรกรรมต่อวินาทีได้สูง และมี Finality ที่ต่ำ Monad สามารถทำสิ่งเหล่านี้ได้โดยการปรับปรุงประสิทธิภาพใน 4 ด้านหลักๆ คือ
1.MonadBFT
2.Deferred Execution
3.Parallel Execution
4.MonadDb
ฟีเจอร์เหล่านี้ช่วยให้ Monad สามารถรองรับธุรกรรมได้มากถึง 10,000 ธุรกรรมต่อวินาทีและมี Finality อยู่ที่ประมาณ 1 วินาธีเท่านั้น ในบทความนี้เราจะมาเจาะลึกกันว่าแต่ละฟีเจอร์ทำงานอย่างไรและช่วยเพิ่มประสิทธิภาพให้แก่ Monad ได้อย่างไร
1.MonadBFT
ถ้าหากคุณรู้ว่า Tendermint และ Hotstuff ทำงานอย่างไร คุณจะทำความเข้าใจ MonadBFT ได้ง่ายมาก แต่ถ้าไม่รู้จักไม่เป็นไร ในบทความนี้เราจะอธิบายให้ฟังเอง Tendermint เป็น Consensus หลักที่ใช้ในระบบนิเวศของเชน Cosmos ซึ่งการที่ Validator จะตัดสินใจว่าบล็อกไหนนั้นจะถูกเพิ่มเข้าไปบนบล็อกเชนหรือ Commit จะต้องผ่านการโหวตทั้งหมด 3 เฟสด้วยกัน ได้แก่ Propose, Pre-vote และ Pre-commit โดยเริ่มแรกของแต่ละบล็อก Leader (คนที่ถูกเลือกจาก Validator ทั้งหมด) จะเป็นคนที่เสนอบล็อกของตัวเองและส่งไปให้ Validator คนอื่นๆ เมื่อ Validator ได้รับบล็อกแล้วจะทำการโหวตโดยการแลกเปลี่ยนข้อความระหว่าง Validator ด้วยกันเอง เมื่อตกลงกันได้แล้วจึงจะทำการ Commit บล็อกๆ นั้น การที่ Validator โต้ตอบโดยการแลกเปลี่ยนข้อความกันไปกันมานี้ทำให้การสื่อสารมีความซับซ้อนแบบยกกำลังสอง (O(n²)) หรือก็คือ ถ้าหากมี Validator อยู่ n คน Validator 1 คนจะต้องส่งข้อความไปหาคนอื่น n-1 คน ดังนั้นข้อความทั้งหมดที่ต้องส่งสำหรับ Validator n คนก็คือ n²-n ใน Tendermint นั้น Validator จะเริ่มโหวตบล็อกใหม่เมื่อบล็อกเก่าเสร็จสิ้นแล้วเท่านั้น
ในทางกลับกัน MonadBFT จะใช้การโต้ตอบแบบสองเฟสก่อน Commit โดยมี Leader เป็นศูนย์กลาง ในแต่ละรอบจะมีการเปลี่ยน Leader ไปเรื่อยๆ และ Validator จะส่งผลโหวตไปให้ Leader คนถัดไปได้โดยที่ไม่ต้องรอให้บล็อกปัจจุบันนั้นจบหรือ Commit ก่อน เมื่อ Leader เสนอ (Propose) บล็อกในรอบที่ k และส่งไปให้กับ Validator คนอื่นๆ แล้ว Validator แต่ละคนจะส่งผลโหวตของบล็อกที่ k ไปให้กับ Leader คนถัดไป (คนที่จะเสนอบล็อกที่ k+1) โดย Leader คนใหม่นี้จะรวบรวมเอาผลโหวตของบล็อกที่ k จาก Validator มาสร้างเป็น Quorum Certificate หรือ QC (เหมือนเป็นใบยืนยันว่าบล็อกนั้นได้รับการโหวตว่าถูกต้องจากเสียงส่วนมากของ Validator) สำหรับบล็อกที่ k (จบเฟสแรกสำหรับบล็อก k) จากนั้น Leader สร้างบล็อกที่ k+1 โดยรวมเอา QC ของบล็อกที่ k เข้าไปด้วย ก่อนที่จะส่งให้ Validator คนอื่นๆ เมื่อ Validator คนอื่นๆ ได้รับแล้วก็จะทำหน้าที่เหมือนเดิมคือ โหวตให้กับบล็อกที่ k+1 แต่เนื่องจากบล็อกนี้มี QC ของบล็อกที่ k ด้วยจึงเป็นการโหวตรอบที่สองให้กับบล็อกที่ k ไปในตัว และส่งกลับไปให้ Leader คนถัดไป โดย Validator จะ Commit บล็อกที่ k เมื่อได้รับบล็อกของรอบที่ k+2 แล้ว ด้วยโครงสร้างแบบนี้จะทำให้ Validator แต่ละคนสามารถทำการโหวตพร้อมกันสำหรับบล็อกที่แตกต่างกันได้ เช่นตัวอย่างด้านบน Validator โหวตรอบแรกให้กับบล็อกที่ k+1 และโหวตรอบสองให้กับบล็อกที่ k พร้อมๆ กัน ทำให้การสื่อสารหรือโต้ตอบมีประสิทธิภาพมากขึ้นและลดความซับซ้อนลง ภาพด้านล่างแสดงการทำงานของ MonadBFT
1.Alice สร้างบล็อกสำหรับรอบที่ k และส่งไปให้ Validator คนอื่นๆ
2.Validator แต่ละคนตรวจสอบความถูกต้องของบล็อก (เช่น Signature) ถ้าหากบล็อกถูกต้อง Validator จะโหวต YES และส่งไปให้กับ Bob ซึ่งเป็น Leader คนถัดไป
3.Bob รวบรวมผลโหวต YES ของบล็อกที่ k และสร้าง QC ซึ่ง QC สำหรับบล็อกที่ k อันนี้จะถูกส่งคู่กับบล็อกใหม่ (บล็อกที่ k+1) ให้กับ Validator คนอื่นๆ ซึ่งเป็นบล็อกที่ Bob สร้างขึ้นมา
4.จากนั้นขั้นตอนจะคล้ายๆ เดิม Validator ตรวจสอบบล็อก โหวต YES และส่งไปให้กับ Charlie ซึ่งเป็น Validator คนถัดไป
5.Charlie รวบรวมผลโหวต YES ของบล็อกที่ k+1 และสร้าง QC ของบล็อกที่ k+1 และส่งคู่กับบล็อกที่ k+2 ไปให้กับ Validator คนอื่นๆ
เมื่อ Validator ได้รับ QC ของบล็อกที่ k+1 แล้ว Validator จะ Commit หรือเพิ่มบล็อกที่ k เข้าไปยังเชนของตน ณ จุดนี้ถ้าหากเกิดเหตุการณ์ที่ Charlie เป็น Leader ที่ไม่หวังดีและส่ง Proposal หรือบล็อกที่ k+2 ไปให้กับ Validator เพียงคนเดียว การที่เขามี QC ของบล็อกที่ k+1 อยู่ในมือจะทำให้เขามั่นใจว่า ถ้าหาก Validator อื่นไม่ได้รับบล็อกนี้ พวกเขาจะยังสามารถย้อนกับไปยังบล็อกที่ k หรือจุดสุดท้ายที่ทุกคน Commit ร่วมกันได้
ลักษณะของการที่ผลโหวตบล็อกที่ k ส่งผลต่อการโหวตบล็อกอื่นๆ นั้นเรียกว่า Pipeline ซึ่งเมื่อนำเอามาใช้กับระบบ Consensus อย่าง MonadBFT แล้วจะช่วยเพิ่มประสิทธิภาพของการประมวลผลได้อย่างมาก ภาพด้านบนแสดงถึง Pipeline ระหว่างผลโหวตของบล็อกต่างกัน จะเห็นได้ว่าในหนึ่งรอบ Validator สามารถทำการโหวตพร้อมกันได้ 3 เฟสสำหรับ 3 บล็อกที่แตกต่างกัน ในรอบที่ k บล็อกที่ k นั้นอยู่ในช่วง Pre-vote (การโหวตรอบแรก) ในขณะที่บล็อกที่ k-1 นั้นอยู่ในช่วง Pre-commit หรือการโหวตรอบที่สอง และบล็อกที่ k-2 นั้นถูก Commit และเพิ่มเข้าไปในเชนของ Validator ที่ได้รับบล็อกนี้ ดังนั้น Validator จะ Commit บล็อกของรอบที่ k เมื่อ QC ของบล็อกที่ k ผ่านการโหวตทั้งหมด 2 รอบและถูกรวมเข้าไปในบล็อกที่ k+2 โครงสร้างแบบนี้ช่วยลดความซับซ้อนของการโต้ตอบโต้ตอบที่ไม่จำเป็นระหว่างการโหวตของบล็อกที่เรียงต่อกันลงได้
2.Deferred Execution
ไอเดียของ Deferred Execution ใน Monad คือการแยก Consensus ออกจาก Execution (การประมวลผลธุรกรรม) สิ่งนี้ช่วยให้โหนดสามารถตกลง (Reach Consensus) เรื่องลำดับของธุรกรรมโดยไม่ต้องรอผลลัพธ์จากการประมวลผล ด้านล่างคือการทำงานของ Deferred Execution
🔸แยก Consensus ออกจาก Execution: สำหรับบล็อกเชนแบบดังเดิมอย่าง Ethereum นั้น Consensus และ Execution จะทำงานด้วยกัน นั่นคือธุรกรรมในบล็อกจะถูกประมวลผลก่อน เพื่อดูว่าสถานะสุดท้ายและธุรกรรมมีความถูกต้องหรือไม่ ก่อนที่จะนำบล็อกนี้มาผ่านระบบ Consensus เพื่อให้แต่ละโหนดทำการโหวตว่าจะใช้บล็อกนี้และลำดับของธุรกรรมเป็นไปตามที่ระบุไว้ในบล็อก แต่ในทางกลับกัน Monad จะให้โหนดนั้นโหวตก่อนว่าจะให้ลำดับของธุรกรรมในบล็อกเป็นแบบไหน โดยที่โหนดไม่จำเป็นต้องประมวลผลธุรกรรมก่อน การทำแบบนี้ช่วยให้ Monad สามารถทำการประมวลผลบล็อกหนึ่งและร่วม Consensus กับบล็อกถัดไปได้พร้อมๆ กัน ซึ่งช่วยให้สามารถใช้ทรัพยากรได้อย่างมีประสิทธิภาพมากขึ้น เนื่องจากการประมวลผลธุรกรรมจะไม่เป็นคอขวดให้แก่การทำ Consensus อีกต่อไป
🔸ผลลัพธ์ที่แน่นอน (Deterministic State): Monad อาศัยหลักการที่ว่าเมื่อลำดับของธุรกรรมถูกกำหนดแล้ว ผลลัพธ์ที่ได้จากการประมวลผลธุรกรรมของเหล่านี้จะแน่นอนไม่เปลี่ยนแปลง ดังนั้นแต่ละโหนดสามารถประมวลผลธุรกรรมโดยไม่ต้องโต้ตอบกัน หลังจากที่ลำดับของธุรกรรมถูกกำหนดโดยโหนดส่วนใหญ่แล้ว
ผลลัพธ์ที่ถูกดีเลย์ (Delayed State Commitment): เพื่อให้มั่นใจว่าทุกโหนดนั้นประมวลผลธุรกรรมอย่างถูกต้องและได้ผลลัพธ์ที่เหมือนกัน รวมถึงป้องกันพฤติกรรมที่ไม่หวังดีจากบางโหนด Monad จึงต้องดีเลย์ผลลัพธ์ของ State Root ออกไป บล็อกจะประกอบด้วย Merkle Root ที่จะถูกดีเลย์ออกไปด้วยจำนวนบล็อกที่กำหนดไว้ เช่น D บล็อก นั่นหมายความว่าสำหรับโหนดที่ไม่ใช่ Full Node จะเห็นสถานะหรือผลลัพธ์ของบล็อกที่ N-D ว่าถูกต้อง ก็ต่อเมื่อเชน Commit (Reach Consensus บน) บล็อกที่ N แล้ว สิ่งนี้ช่วยกระตุ้นให้ผู้ที่ใช้งานเชนรัน Full Node และช่วยเพิ่มความปลอดภัยของเชน นอกจากนี้การที่ Commitment ของ Merkle Root ถูกดีเลย์ออกไปยังช่วยจำกัดจำนวนบล็อกที่ Full Node จะตามหลังไม่ให้สูงเกินไป ส่งผลให้เชนมีความมั่นคงและเสถียร
Defered Execution จึงช่วยให้ Monad สามารถเพิ่มประสิทธิภาพได้ทั้งในด้านความเร็วและ Scalability ด้วยการทำให้ Consensus สามารถทำงานได้อย่างอิสระโดยที่ไม่ต้องรอผลลัพธ์จากการประมวลผล (Execution)
3.Parallel Execution
Parallel Execution นั้นเป็นกุญแจสำคัญใน Monad ที่ช่วยเพิ่มประสิทธิภาพการประมวลผลของธุรกรรมได้อย่างมาก ซึ่ง Monad สามารถประมวลผลหลายๆ ธุรกรรมพร้อมกันได้ โดยการใช้ Optimistic Execution ซึ่งประกอบด้วยสองเฟส
🔸Optimistic Execution: Monad ใช้ Optimistic Execution นั่นคือ Monad จะประมวลผลธุรกรรมไปก่อนโดยคิดว่าทุกธุรกรรมถูกต้อง เพื่อดูว่าแต่ละธุรกรรมขึ้นต่อกันอย่างไร ซึ่งเริ่มโดยการประมวลผลธุรกรรมพร้อมๆ กันโดยที่ไม่รอให้การประมวลผลธุรกรรมก่อนหน้าในบล็อกเดียวกันจบก่อน แต่ในขณะเดียวกันก็คอยดูข้อมูลขาเข้าและขาออกจากการประมวลผลของแต่ละธุรกรรม การทำแบบนี้จะช่วยบอกว่าแต่ละธุรกรรมนั้นขึ้นต่อกันอย่างไร และเมื่อต้องประมวลผลซ้ำอีกครั้ง จะทำให้มีประสิทธิภาพมากขึ้น
🔸การประมวลผลธุรกรรมที่ขึ้นต่อกันซ้ำอีกครั้ง (Re-Execute Dependencies): การดูว่าข้อมูลขาเข้าและขาออกจากการประมวลผลของแต่ละธุรกรรมช่วยให้ Monad สามารถตัดสินได้ว่าธุรกรรมใดที่ขึ้นต่อกันบ้าง โดยการลองประมวลผลจริงและจะช่วยให้สามารถข้ามการประมวลผลแบบเป็นลำดับที่มีความซับซ้อนได้ ในเหตุการณ์ที่มีธุรกรรมที่ขึ้นต่อกันเป็นจำนวนมากติดต่อกัน Optimistic Execution จะมีปัญหาเนื่องจากต้องมีการประมวลผลซ้ำหลายรอบ อย่างไรก็ตามความสวยงานของการใช้ Optimistic Execution คือจะช่วยบังคับให้ระบบเก็บข้อมูลการประมวลผลไว้ชั่วคราว และเมื่อต้องประมวลผลซ้ำอีกครั้งจะสามารถดึงข้อมูลเหล่านี้กลับมาใช้ได้ จึงทำให้การประมวลผลซ้ำอีกครั้งทำได้อย่างมีประสิทธิภาพและไม่กินทรัพยากรณ์
การทำ Parallel Execution ในลักษณะที่กล่าวไว้ข้างต้นช่วยให้ Monad
สามารถเพิ่มความสามารถในการรองรับจำนวนธุรกรรมได้มากขึ้นแล้วยังคงไว้ซึ่งความถูกต้องและผลลัพธ์ที่แน่นอนของการประมวลผลธุรกรรม ซึ่งช่วยเลี่ยงปัญหาของการประมวลผลที่เป็นลำดับที่ซับซ้อน หลักการนี้ช่วยให้ประสบการณ์การใช้งานสำหรับนักพัฒนา EVM ยังเหมือนเดิม หลีกเลี่ยงความจำเป็นที่จะต้องเตรียม Access List เมื่อมีการทำธุรกรรม
4.MonadDB
Ethereum ใช้โครงสร้างข้อมูลที่เรียกว่า Merkle Patricia Tree (MPT) ซึ่งเป็นการผสาน Merkle tree และ Patricia Tree เข้าด้วยกันเพื่อจัดเก็บสถานะของบล็อกเชนและทำให้การหยิบใช้ข้อมูลจาก Tree นั้นมีประสิทธิภาพ รวมถึงป้องกันการดัดแปลงข้อมูลภายใน Tree อย่างไรก็ตามเมื่อ Ethereum Client (โหนด) เก็บ Data เหล่านี้ไว้บนเครื่องตัวเอง จะใช้วิธีการเก็บด้วย Database ธรรมดา อย่าง LevelDB และ RocksDB ซึ่งเป็นวิธีการเก็บข้อมูลแบบทั่วไปที่ใช้ลักษณะ Key-Value ซึ่งจะเก็บข้อมูลไว้ในรูปแบบตาราง แต่ Database เหล่านี้ไม่ได้เข้าใจและไม่ได้ออกแบบมาเพื่อเก็บโครงสร้างแบบ MPT
ด้วยเหตุนี้ Monad จึงสร้าง Database ของตัวเองที่เรียกว่า MonadDb ขึ้นมา ซึ่งถูกออกแบบมาให้เหมาะสมกับโครงสร้างข้อมูลอย่าง MPT และเหมาะสมกับโครงสร้างของ Monad เนื่องจาก Monad ใช้ Parallel Execution จึงมีความจำเป็นที่จะต้องอ่านข้อมูลจากดิสก์แบบ Asynchronous (อ่านหลายๆ ข้อมูลพร้อมๆ กัน) โดยไม่จำเป็นต้องรอให้การดำเนินการอื่นๆ เสร็จสิ้นก่อน แต่ Database ที่กล่าวไว้ด้านบนนั้นไม่ได้รองรับการทำงานแบบนี้ตั้งแต่แรก (สามารถทำได้แต่ไม่ดีมาก) ด้วยการใช้ Async I/O ตัวล่าสุดจึงทำให้ Monad สามารถหลีกเลี่ยงคอขวดจากการที่ระบบต้องรอให้การดำเนินการอันหนึ่งเสร็จก่อน ก่อนที่จะสามารถดำเนินการอันถัดไปได้ ส่งผลให้สามารถทำงานในรูปแบบ Asynchronous ได้
References
[1] https://t.co/cTcUu88BBt
[2] https://t.co/jem0J92q1b
[3] https://t.co/ylGS3u0XUw
___________________________________
มีกิจกรรมอะไรให้ร่วมบ้าง1. Social Credit Score : วิธีเข้าร่วม
1.ติดตาม Social media of Monad team
- Join Monad Thailand telegram official by monad team : https://t.co/Z2WobNhQQ2
- Join Monad Discord : https://t.co/ptVMMrGqwo
- พูดคุยใน Monad discord เพื่อให้ได้ Lv6
2.NFT / Poap จากการร่วมกิจกรรม event community เช่น Poker / สร้าง meme
*Cr.picture by Monad community
3. Meme master : สร้างมีมที่คุณภาพ เพื่อโพสลง Twitter ส่วนตัว + Monad discord
*สร้าง monad meme ได้ที่ :
https://t.co/e0PaMAQmQI
#monad #gmonad #gnad](https://pbs.twimg.com/media/GA1BZwkbAAAEb0q.jpg)
ซูดๆๆๆ
เดวทำให้บอทเชค health factor ซัพพอทตัวนี้ดีกว่า จะได้ใช้ LTV กันได้เยอะๆ เวลาแตกจะได้เสียน้อยๆ 😅
มีคนเคยบอกว่า การติดโซลาร์เซลล์ก็แค่การจ่ายค่าไฟล่วงหน้า แต่ขอบอกเลยว่ามันไม่ใช่แบบนั้นครับ
ใครที่กำลังวางแผนติดตั้งระบบโซลาร์เซลล์เพื่อเตรียมรับมือฤดูร้อนปี 2024 ผมขอใช้ 🧵 เธรดนี้ในการอธิบายว่า ทำไมโซลาร์เซลล์ไม่ใช่การจ่ายค่าไฟล่วงหน้า ทำไมถึงควรติด ยุ่งยากไหม ติดตามกันได้
Most Popular Users
Elon Musk 
@elonmusk
241.2M followers
Barack Obama
@barackobama
119.1M followers
Cristiano Ronaldo
@cristiano
112.7M followers
Donald J. Trump
@realdonaldtrump
111.8M followers
Narendra Modi
@narendramodi
107.1M followers
Rihanna
@rihanna
98.2M followers
NASA
@nasa
92.2M followers
Justin Bieber
@justinbieber
91.4M followers
KATY PERRY
@katyperry
88.9M followers
Taylor Swift
@taylorswift13
82.8M followers
Lady Gaga
@ladygaga
74.3M followers
Virat Kohli
@imvkohli
71.8M followers
Kim Kardashian
@kimkardashian
70.4M followers
YouTube
@youtube
68.8M followers
Neymar Jr
@neymarjr
64.7M followers
Bill Gates
@billgates
64.6M followers
The Ellen Show
@theellenshow
62.4M followers
Selena Gomez
@selenagomez
62M followers
CNN
@cnn
61.8M followers
X
@x
60.8M followers