sukree.eth

Monad Layer 1 : [ กาวกระป๋องใหญ่ ทำไมถึงน่าสนใจในปี 2024 ? ] + How to Contribute with Monad Project TL : DR [ ยาวไป ไม่อ่าน เลยมาสรุปให้ ] ปล.ใครอยาก อ่านแบบยาวๆ และรูปฮาๆ เยอะ อ่านได้ที่นี่ : mirror.xyz/thepleb.eth/5v… 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 thoery] ***เพียงแค่ จินตนาการว่า มันคือ 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 โครงสร้างแบบนี้ช่วยลดความซับซ้อนของการโต้ตอบโต้ตอบที่ไม่จำเป็นระหว่างการโหวตของบล็อกที่เรียงต่อกันลงได้ 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) 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 เมื่อมีการทำธุรกรรม 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] docs.monad.xyz [2] arxiv.org/pdf/1803.05069… [3] medium.com/ontologynetwor… ___________________________________ มีกิจกรรมอะไรให้ร่วมบ้าง1. Social Credit Score : วิธีเข้าร่วม 1.ติดตาม Social media of Monad team - Join Monad Thailand telegram official by monad team : t.me/MonadThailand - Join Monad Discord : discord.gg/monad - พูดคุยใน Monad discord เพื่อให้ได้ Lv6 2.NFT / Poap จากการร่วมกิจกรรม event community เช่น Poker / สร้าง meme *Cr.picture by Monad community 3. Meme master : สร้างมีมที่คุณภาพ เพื่อโพสลง Twitter ส่วนตัว + Monad discord *สร้าง monad meme ได้ที่ : Monadmonadmememaker.com #monad #gmonad #gnad