คำเตือนความเสี่ยง: ระวังความเสี่ยงจากการระดมทุนที่ผิดกฎหมายในนาม 'สกุลเงินเสมือน' 'บล็อกเชน' — จากห้าหน่วยงานรวมถึงคณะกรรมการกำกับดูแลการธนาคารและการประกันภัย
ข่าวสาร
ค้นพบ
ค้นหา
เข้าสู่ระบบ
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt
BTC
ETH
HTX
SOL
BNB
ดูตลาด
การวิเคราะห์แก่นแท้ของเกมลูกโซ่ทั้งหมด: เครื่องยนต์ MUD และเครื่องยนต์โลก
YBB Capital
特邀专栏作者
2023-08-10 12:00
บทความนี้มีประมาณ 6804 คำ การอ่านทั้งหมดใช้เวลาประมาณ 10 นาที
จากมุมมองที่กว้างขึ้น ด้วยการปรับปรุงโครงสร้างพื้นฐาน ไม่เพียงแต่เกมเท่านั้น แต่ยังรวมถึงการสร้างและการตระหนักถึงแนวคิดที่ซับซ้อนต่างๆ จะดำเนินการผ่าน MUD และการโต้ตอบจะถูกรวมเข้ากับโครงการ Rollup ที่ซับซ้อนมากขึ้น ซึ่งเป็นกระบวนทัศน์ใหม่ของ blockchain อาจจะ มันจะเริ่มต้นด้วยเกมเต็มลูกโซ่

ผู้แต่งต้นฉบับ: Solaire, YBB Capital

ในอดีต เนื่องจากข้อจำกัดของโครงสร้างรายการลูกโซ่ของบล็อกเชน การสร้าง DApp บนลูกโซ่จึงไม่ใช่เรื่องง่าย แต่ถึงแม้จะมีข้อจำกัดนี้ นักสำรวจก็ไม่เคยหยุดก้าวไปข้างหน้า ด้วยการกำเนิดของสูตรกลุ่มผลิตภัณฑ์คงที่ที่มีชื่อเสียง x * y = k Uniswap ซึ่งเป็นโค้ดเพียงไม่กี่ร้อยบรรทัด ทำให้ DeFi เปลี่ยนการบรรยายของ Crypto ไปโดยสิ้นเชิง . DApps แบบธรรมดาสามารถเข้าถึงความสูงดังกล่าวได้ภายใต้ความเฉลียวฉลาดของนักพัฒนา แล้วแอพพลิเคชั่น DApp ที่ซับซ้อนล่ะ? ตัวอย่างเช่น สร้างเกมหรือแพลตฟอร์มโซเชียลทั้งหมดบนเครือข่าย? นี่อาจเป็นแนวคิดที่บ้าบอในอดีต แต่ในปัจจุบัน เมื่อ Rollups เปิดช่องความสามารถในการปรับขนาด ความเป็นไปได้ก็เริ่มที่จะละเอียดอ่อน

ชื่อระดับแรก

ต้นกำเนิดและการพัฒนาเกมแบบฟูลเชน

ประวัติความเป็นมาของเกมลูกโซ่เต็มรูปแบบสามารถย้อนกลับไปเมื่อ 10 ปีที่แล้ว มิคาอิล ซินเดเยฟได้แยก Namecoin และสร้างเกมบล็อกเชนเกมแรกของโลก Huntercoin Huntercoin เริ่มต้นจากการเป็นต้นแบบทดลองในปี 2013 และพัฒนาลัทธิการติดตามออนไลน์อย่างรวดเร็ว โดยได้รับการสนับสนุนจากสมาชิก bitcointalk.org ที่มีชื่อเสียงหลายคน โพสต์ Huntercoin ที่ได้รับความนิยมมากที่สุดใช้ประโยชน์จากความรักในวิดีโอเกมของผู้ที่ชื่นชอบเทคโนโลยี โดยมียอดดูมากกว่า 380,000 ครั้ง น่าเสียดายที่มิคาอิล ซินเดเยฟเสียชีวิตด้วยโรคหลอดเลือดสมองในเดือนกุมภาพันธ์ 2014 และการพัฒนา Huntercoin ก็ประสบปัญหาเช่นกัน โทเค็น HUC เกือบเป็นศูนย์ในปี 2558 แม้ว่าความพยายามครั้งแรกของเกมเต็มลูกโซ่จะไม่ประสบความสำเร็จ แต่โชคดีที่ ของเกมลูกโซ่ทั้งหมดยังคงดำเนินต่อไป

ในปี 2020 Gubsheep (Brian Gu), Alan Luo และ SCOTT SUNARTO ได้รับแรงบันดาลใจจากนวนิยายเรื่อง Three-Body Problem: Dark Forest พัฒนาเกมพิชิตอวกาศ MMORTS Dark Forest ในชื่อเดียวกัน เกมดังกล่าวสร้างขึ้นบน Ethereum และกฎและตรรกะทั้งหมดถูกเขียนลงในสัญญาอัจฉริยะ นั่นคือทุกการเคลื่อนไหวเป็นเกมแบบเต็มรูปแบบพร้อมธุรกรรมแบบออนไลน์ ส่วนหลักของเนื้อหาเกมใช้เทคโนโลยี ZK-Snarks (zero-knowledge proof) เพื่อสร้างหมอกแห่งสงครามเพื่อสร้างคำจำกัดความของกฎแห่งป่ามืดในนวนิยายสามร่าง (เมื่ออารยธรรมจักรวาลถูกค้นพบ มันจะ ถูกท้าทายจากอารยธรรมจักรวาลอื่นอย่างหลีกเลี่ยงไม่ได้ ตี)

ตัวอย่างเช่น เมื่อผู้เล่นต้องการดำเนินการซึ่งได้รับผลกระทบจากกฎแห่งป่ามืด ผู้เล่นไม่สามารถเปิดเผยพิกัดของตนได้ แต่พวกเขาต้องการย้ายจาก A Odaily ไปยัง B Odaily พวกเขาจะต้องส่งพิกัดของ A และ B เพื่อพิสูจน์ว่า สิ่งนี้ถูกต้อง แต่อีเธอร์ ข้อมูลบล็อกของ Fangfang นั้นโปร่งใสอย่างสมบูรณ์ และ Dark Forest รับรู้ข้อมูลที่ซ่อนไว้ด้วยวิธีการต่อไปนี้ ผู้เล่นเลือก Odaily ที่จะออกและปลายทาง Odaily ตำแหน่งของ Odaily ทั้งสองนี้เป็นข้อมูลส่วนตัวของผู้เล่น คำนวณแฮชของ Odaily ที่คุณจะออกและตำแหน่งของ Odaily ที่คุณจะไป และส่งแฮชทั้งสองไปที่บล็อกเชน ในขั้นตอนนี้ ผู้เล่นจะส่งคำมั่นสัญญา (ขั้นตอนความมุ่งมั่น) เนื่องจากลักษณะทางเดียวของฟังก์ชันแฮช ค่าแฮชของการส่งเหล่านี้จึงไม่สามารถใช้เพื่อกำหนดตำแหน่งดาวเคราะห์ที่แท้จริงของผู้เล่นได้ และขั้นตอนต่อไปคือการตรวจสอบ (ขั้นตอนการเปิดเผย) ซึ่งผู้เล่นจะสร้างและส่งหลักฐานที่ไม่มีความรู้ว่าการกระทำของตนนั้นถูกต้อง ทุกคนสามารถตรวจสอบหลักฐานนี้ได้ แต่จะไม่เปิดเผยข้อมูลใดๆ เกี่ยวกับตำแหน่งของ Odaily ของผู้เล่น

ด้วยวิธีนี้ เกมเต็มลูกโซ่เกมแรกที่ซ่อนข้อมูลเกี่ยวกับ Ethereum ที่ข้อมูลที่โปร่งใสถือกำเนิดขึ้น การทดลองที่บ้าคลั่งและรอบคอบนี้ทำให้เกิดความรู้สึกอย่างรวดเร็วในแวดวง Crypto ทั้งหมด Vtalik (ผู้ก่อตั้ง Ethereum ) ถึงกับรีทวีตและยกย่องเกม โดยตรงบน Twitter

อย่างไรก็ตาม ด้วยจำนวนผู้เล่นที่หลั่งไหลเข้ามามากกว่า 10,000 คนหลังจากการเปิดตัว Dark Forest ครั้งแรก ภาวะที่กลืนไม่เข้าคายไม่ออกก็เริ่มเกิดขึ้น ประสิทธิภาพของ Ethereum นั้นไม่เพียงพอที่จะรองรับการทำงานของแอปพลิเคชันที่ซับซ้อนนี้ ในวันที่เกมเปิดตัว บล็อกเชนทั้งหมดถูกบล็อกโดยตรง และใช้ Gas หลายล้านล้าน และเนื่องจากเกมได้รับการออกแบบตามไลบรารีและสถาปัตยกรรมของแอปพลิเคชัน DeFi การเพิ่มประสิทธิภาพเพิ่มเติมในระยะหลังจะบรรเทาความเจ็บปวดเท่านั้นและไม่สามารถแก้ปัญหาได้

แรงบันดาลใจจากโอกาสของการทดลอง ZK-Snarks และคิดถึงชะตากรรมของเกมในเครือทั้งหมด Brian Gu ผู้ก่อตั้งเกมได้สร้าง 0 x PARC ให้เป็นสถาบันวิจัย ZK-Snarks เพื่อส่งเสริมการพัฒนาการพิสูจน์ความรู้เป็นศูนย์ และ 0 x PARC Lattice อีกสาขาหนึ่งมีหน้าที่รับผิดชอบในการออกแบบและบำรุงรักษา MUD เอ็นจิ้นเกมแบบเต็มรูปแบบ SCOTT SUNARTO ผู้ก่อตั้งอีกคน เริ่มพัฒนาเฟรมเวิร์ก sharding Rollup ที่อุทิศให้กับการรันเกมแบบ full-chain——World Engine

ชื่อระดับแรก

Autonomous Worlds

จากมุมมองในคอลเลกชั่นกระดาษเกมที่เข้ารหัส 0 x PARC Autonomous Worlds เกมแบบฟูลเชนจะต้องเป็นไปตามมาตรฐานอย่างน้อยห้ามาตรฐาน:

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

ตรรกะและกฎเกณฑ์ถูกนำไปใช้ผ่านสัญญาอัจฉริยะ:ตัวอย่างเช่น การต่อสู้ในเกม ไม่ใช่แค่การเป็นเจ้าของ เกิดขึ้นแบบออนไลน์

การพัฒนาเกมเป็นไปตามหลักการของระบบนิเวศแบบเปิด:ทั้งสัญญาเกมและไคลเอนต์เกมที่สามารถเข้าถึงได้นั้นเป็นโอเพ่นซอร์ส นักพัฒนาบุคคลที่สามสามารถปรับใช้ใหม่ ปรับแต่ง หรือแม้แต่แยกประสบการณ์เกมของตนเองได้อย่างสมบูรณ์ผ่านปลั๊กอิน ไคลเอนต์บุคคลที่สาม และสัญญาอัจฉริยะที่ทำงานร่วมกันได้ ซึ่งจะช่วยให้นักพัฒนาเกมสามารถเข้าถึงผลงานสร้างสรรค์ของชุมชนทั้งหมด (ที่สอดคล้องกับสิ่งจูงใจ)

l เกมดังกล่าวถูกเก็บไว้อย่างถาวรบนเครือข่าย:ประเด็นนี้มีความเกี่ยวข้องอย่างใกล้ชิดกับ 3 ประเด็นข้างต้น เนื่องจากมาตรฐานในการทดสอบว่าเกมเป็นเกมเนทิฟที่เข้ารหัสหรือไม่ คือ: หากไคลเอนต์ที่ผู้พัฒนาหลักมอบให้หายไปในวันพรุ่งนี้ เกมจะยังคงเล่นได้หรือไม่ คำตอบมักจะเป็นใช่ หาก (และเฉพาะในกรณีที่) ที่จัดเก็บข้อมูลเกมไม่ได้รับอนุญาต หากตรรกะของเกมสามารถดำเนินการได้โดยไม่ได้รับอนุญาต หากชุมชนสามารถโต้ตอบกับสัญญาอัจฉริยะหลักโดยไม่ต้องอาศัยอินเทอร์เฟซที่ทีมงานหลักให้มา

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

เกมลูกโซ่เต็มรูปแบบที่สร้างขึ้นตามมาตรฐานนี้ยังถือได้ว่าเป็นโลกที่ใช้บล็อกเชนเป็นชั้นล่างหรือโลกอิสระ (โลกอิสระ)

แล้วโลกคืออะไร? โลกไม่เพียงแต่หมายถึงโลกแห่งความเป็นจริงเท่านั้น แต่ยังเป็นพาหะของโลกที่สามารถเป็นนวนิยาย ภาพยนตร์ เกม บทกวี และแม้กระทั่งระบบกฎหมาย แต่ในโลกเหล่านี้ ศูนย์ (ผู้เขียน นักพัฒนา หรือกลุ่ม) จะกำหนดกรอบงานและกฎเกณฑ์ แล้วจึงสื่อสารให้เราทราบ ระดับความเป็นอิสระในโลกเหล่านี้ก็แตกต่างกันออกไป ตัวอย่างเช่น ในเกม มายคราฟ (My World) ที่รู้จักกันดีในเกมโอเพ่นเวิลด์ ผู้เล่นมีระดับความเป็นอิสระสูงมาก โดยผ่านการสร้างบล็อกต่างๆ และการปรับเปลี่ยนกฎ ผู้เล่นสามารถสร้างโลกของตนเองได้เท่านั้น โลกที่มีความเป็นอิสระต่ำอาจเป็นโลกนวนิยายเช่น แฮร์รี่ พอตเตอร์ โลกมหัศจรรย์ที่เราเห็นนั้นขึ้นอยู่กับกฎและกรอบที่สร้างขึ้นโดย JK Rowling

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

จากมุมมองของโลก มีแนวคิดบล็อคเชนสองแนวคิดที่ต้องกำหนด:

l รากสถานะบล็อคเชน: รากสถานะคือการบีบอัดของเอนทิตีทั้งหมดในโลก

ด้วยรากแห่งสภาวะ เราสามารถระบุได้ว่าเอนทิตีใดๆ นั้นเป็นเสมือนหรือไม่ และการเชื่อในรากแห่งสภาวะของโลกก็เท่ากับการเชื่อในโลกนั้นเอง 0x411842e02a67ab1ab6d3722949263f06bca-20c62e03a99812bcd15dce6daf26e คือรากของ Ethereum เวลา 07:30:10 น. UTC วันที่ 21 กรกฎาคม 2022 - โลกที่มีบล็อกเชนเป็นพื้นฐาน เมื่อคำนวณรูทสถานะนี้ เอนทิตีทั้งหมดในโลก Ethereum จะถูกนำมาพิจารณาด้วย มันแสดงถึงเนื้อหาทั้งหมดของโลกนั้นในขณะนั้น

ฟังก์ชันการเปลี่ยนสถานะบล็อคเชน: แต่ละบล็อคเชนจะกำหนดฟังก์ชันการเปลี่ยนสถานะ

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

ชื่อระดับแรก

สร้างภาวะที่กลืนไม่เข้าคายไม่ออก

ในกระบวนการเริ่มต้นของการสำรวจการออกแบบใหม่สำหรับเกมแบบ Full-chain นักพัฒนาได้รับผลกระทบซ้ำแล้วซ้ำเล่าจากข้อจำกัดของสถาปัตยกรรมและไลบรารี DApp แบบดั้งเดิมสำหรับการสร้างแอปพลิเคชัน DeFi Dark Forest และการสร้างเกมแบบ full-chain ในยุคแรก ๆ จะต้องเป็นไปตามสถาปัตยกรรมและไลบรารีที่ใช้ในการสร้างแอปพลิเคชัน DeFi ในขณะนั้น และสถาปัตยกรรมเหล่านี้ก็กลายเป็นตัวเลือกเริ่มต้นสำหรับการสร้างเกมแบบ full-chain ในขณะนั้น

รูปแบบแรกของการสร้างเกมแบบ full-chain สามารถสรุปได้เป็นสี่จุด:

เมื่อสัญญาที่แตกต่างกันมีสถานะเดียวกัน:สัญญาอัจฉริยะหลายรายการอาจแก้ไขข้อมูลหรือสถานะเดียวกัน ซึ่งอาจทำให้ข้อมูลไม่สอดคล้องกันหรือเกิดปัญหาอื่นๆ บางครั้งใช้ Diamond Pattern เพื่อแก้ปัญหา (Diamond Pattern เป็นวิธีการแก้ปัญหาการสืบทอดหลายอย่างใน Solidity smart Contract)

เขียนโครงสร้างข้อมูลที่หลากหลาย:เอนทิตีแต่ละประเภท (เช่น ทหารในเกม ดาวเคราะห์ ฯลฯ) มีโครงสร้างและประเภทข้อมูลของตัวเอง

l เขียนฟังก์ชัน Getters:นี่คือฟังก์ชันที่ส่งคืนชุดองค์ประกอบสำหรับโครงสร้างข้อมูล ซึ่งใช้ในการรับสถานะเริ่มต้นหรือข้อมูลจากห่วงโซ่ ตัวอย่างเช่น ฟังก์ชัน getPlanets() อาจส่งคืนรายการดาวเคราะห์ทั้งหมด

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

ชื่อรอง

ผู้สร้างโลก - เครื่องยนต์ MUD

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

ปัจจุบัน MUD เวอร์ชันล่าสุดมีส่วนประกอบ 5 ส่วน:

l ร้านค้า: ฐานข้อมูลออนไลน์

World: เฟรมเวิร์กจุดเริ่มต้นที่นำการควบคุมการเข้าถึง การอัพเกรด และโมดูลที่ได้มาตรฐาน

เครื่องมือ: เครื่องมือการพัฒนาที่รวดเร็วเป็นพิเศษจาก Foundry;

l การจัดเก็บข้อมูลลูกค้า: สามารถสะท้อนสถานะบนห่วงโซ่ได้อย่างน่าอัศจรรย์

ชื่อรอง

ความเข้ากันได้ของ EVM เต็มรูปแบบ มีอิสระในระดับที่สูงมาก

ความอเนกประสงค์ของ MUD ไม่ได้จำกัดอยู่ที่เมนเน็ต Ethereum ตราบใดที่ภาษารองรับ MUD ก็สามารถทำงานบนเชนที่เข้ากันได้กับ EVM ได้อย่างราบรื่น ไม่ว่าจะเป็น Polygon, Arbitrum, Optimism หรือ Gnosis Chain

ชื่อรอง

แนวคิดหลัก

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

สถานะออนไลน์ทั้งหมดจะถูกจัดเก็บไว้ในฐานข้อมูล Store บน MUD chain: Store เป็นฐานข้อมูล EVM แบบฝัง คล้ายกับฐานข้อมูล SQLite ซึ่งมีแนวคิดเกี่ยวกับตาราง คอลัมน์ และแถว การใช้ Store สามารถจัดการข้อมูลที่มีโครงสร้างมากขึ้น และไม่จำเป็นต้องพึ่งพาวิธีการจัดเก็บข้อมูลที่คอมไพเลอร์ Solidity ให้มา นอกจากนี้ยังรองรับการสร้างตารางในขณะรันไทม์และอนุญาตให้ลงทะเบียน hooks เพื่อสร้างมุมมองที่จัดทำดัชนีโดยอัตโนมัติ ซึ่งนำมาซึ่งความยืดหยุ่นมากขึ้น

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

l ไม่จำเป็นต้องมีตัวสร้างดัชนีหรือกราฟย่อย และส่วนหน้ายังสามารถซิงค์ได้: เมื่อใช้ Store (และโลกขยาย) ข้อมูลบนลูกโซ่จะถูกตรวจสอบโดยอัตโนมัติ (วิปัสสนา การตรวจสอบตัวเอง) และการเปลี่ยนแปลงใด ๆ ถ่ายทอดผ่านกิจกรรมมาตรฐาน ผ่าน"MODE"ชื่อรอง

ทะลุพันธนาการ

ด้วยแนวคิดหลักทั้งสามนี้ เราจะมาดูปัญหาที่ผ่านมาเป็นตัวอย่างเพื่อดูว่า MUD ทำลายพันธนาการของแอปพลิเคชันที่ซับซ้อนได้อย่างไร

l เมื่อสัญญาที่แตกต่างกันสัมผัสกันในสถานะเดียวกัน: โดยใช้"World"และ"Store"โครงสร้างเพื่อจัดการสถานะบนห่วงโซ่จากส่วนกลาง สัญญาอัจฉริยะทั้งหมด (เรียกว่า ระบบ ใน MUD) คือ"World"เพื่อเข้าถึงและแก้ไข"Store"ข้อมูลใน. สิ่งนี้ทำให้แน่ใจได้ว่าการแก้ไขสถานะทั้งหมดจะผ่านจุดเริ่มต้นแบบรวมศูนย์ ซึ่งช่วยลดความเสี่ยงที่ข้อมูลไม่สอดคล้องกันหรือขัดแย้งกัน MUD ให้การควบคุมการเข้าถึงข้อมูลอย่างละเอียดผ่านทางเนมสเปซและเส้นทาง ระบบ ที่แตกต่างกันสามารถมีสิทธิ์ที่แตกต่างกันได้ ดังนั้นจึงมั่นใจได้ว่าเฉพาะ ระบบ ที่ได้รับอนุญาตเท่านั้นที่สามารถแก้ไขข้อมูลหรือสถานะเฉพาะได้

โครงสร้างข้อมูล: แตกต่างจากวิธีการจัดเก็บข้อมูลแบบ Solidity แบบดั้งเดิม นั่นคือ MUD"Store"ให้แนวคิดเกี่ยวกับตาราง คอลัมน์ และแถวที่คล้ายกับ SQLite เพื่อให้สามารถจัดเก็บและจัดการข้อมูลให้มีโครงสร้างมากขึ้น เอนทิตีแต่ละประเภท (เช่น ทหารในเกม ดาวเคราะห์ ฯลฯ) สามารถมีตารางของตัวเองได้ และแต่ละตารางสามารถมีหลายคอลัมน์เพื่อจัดเก็บคุณลักษณะที่แตกต่างกันของเอนทิตี

l ฟังก์ชั่น Getters: เนื่องจากโคลน"Store"มอบพื้นที่จัดเก็บข้อมูลที่มีโครงสร้าง ทำให้การรับข้อมูลง่ายขึ้นและใช้งานง่ายยิ่งขึ้น นักพัฒนาสามารถใช้ภาษาคิวรีที่คล้ายกับ SQL เพื่อรับข้อมูลโดยไม่ต้องเขียนฟังก์ชัน getters พิเศษ ตัวอย่างเช่น หากต้องการรับดาวเคราะห์ทั้งหมด นักพัฒนาสามารถค้นหาตารางดาวเคราะห์ได้โดยไม่ต้องเขียนฟังก์ชัน getPlanets()

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

ชื่อระดับแรก

บริหารโลก เครื่องยนต์โลก

การดำเนินงานของเกมลูกโซ่เต็มรูปแบบถือเป็นความท้าทายที่ยิ่งใหญ่สำหรับ Ethereum มาโดยตลอด ด้วยการพัฒนาอย่างรวดเร็วของ Rollups และแนวทางการอัพเกรด Cancun ต้นทุนจะลดลงอย่างมากและความเร็วจะดีขึ้นอย่างมากในอนาคต เกม Full-chain พร้อมใช้งานแล้ว แต่ Rollups กระแสหลักในปัจจุบันได้รับการออกแบบโดยทั่วไปสำหรับการทำธุรกรรม และไม่มี Rollup ที่ปรับแต่งมาสำหรับเกม Full-chain จริงๆ

ชื่อรอง

เกมลูกโซ่เต็มรูปแบบจำเป็นต้องมี Rollup ประเภทใด?

ปริมาณงานสูงและ TPS สูง: การประมวลผลธุรกรรมที่เร็วขึ้น, เวลาแฝงที่ต่ำกว่า, ความสามารถในการปรับขนาดที่ดีขึ้น

การอ่านและการเขียนแบบขยาย: เลเยอร์ 2 ส่วนใหญ่ได้รับการออกแบบมาให้ทำการเขียนจำนวนมากสำหรับการประมวลผลพร้อมกันสูง แต่เกมจำเป็นต้องอ่านเพื่อให้ได้ตำแหน่งของผู้เล่น ดังนั้นการอ่านและการเขียนจึงมีความสำคัญเท่าเทียมกัน

ห่วงโซ่ที่ปรับขนาดได้ในแนวนอน: ความสามารถในการปรับขนาดในแนวนอนหมายถึงการเพิ่มความสามารถในการประมวลผลของระบบโดยการเพิ่มโหนดและทรัพยากรมากขึ้นเพื่อตอบสนองความต้องการที่เพิ่มขึ้น วิธีนี้จะหลีกเลี่ยงปัญหา Noisy Neighbor (ซึ่งกิจกรรมของแอปพลิเคชันหรือเอนทิตีหนึ่งอาจส่งผลเสียต่อแอปพลิเคชันหรือเอนทิตีอื่น ๆ ทำให้เกิดความขัดแย้งด้านทรัพยากรและปัญหาด้านประสิทธิภาพ)

l ความยืดหยุ่นและการปรับแต่ง: ความยืดหยุ่นและความสามารถในการปรับแต่งได้ สะดวกในการปรับเปลี่ยนเครื่องสถานะและทำให้เหมาะสมกับการออกแบบเกม ซึ่งรวมถึงการมีเกมวนซ้ำ ทำให้ดำเนินการได้เอง ฯลฯ

ชื่อรอง

สถาปัตยกรรมการกระจายตัว

เพื่อให้บรรลุเป้าหมายข้างต้น ทีมงานมองย้อนกลับไปในช่วงต้นทศวรรษ 2000 และปลายทศวรรษ 1990 และได้รับแรงบันดาลใจจากเมื่อเกมออนไลน์อย่าง MMO เพิ่งเกิดขึ้น เกมออนไลน์ในยุคแรกๆ จำเป็นต้องหาวิธีที่จะสนับสนุนการโต้ตอบของผู้เล่นจำนวนมากด้วยเทคโนโลยีเซิร์ฟเวอร์และเครือข่ายที่ค่อนข้างจำกัด"การกระจายตัว"นี่เป็นหนึ่งในวิธีแก้ปัญหา และแนวคิดหลักคือการกระจายผู้เล่นไปยังเซิร์ฟเวอร์หรือ ส่วนแบ่ง ที่แตกต่างกัน ซึ่งแต่ละเซิร์ฟเวอร์สามารถโฮสต์ส่วนหนึ่งของผู้เล่น แผนที่เกม และข้อมูลได้อย่างอิสระ

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

ความสามารถในการปรับขนาด: ด้วยการกระจายผู้เล่นไปยังส่วนต่างๆ เกมสามารถขยายได้ง่ายขึ้นเพื่อรองรับผู้เล่นได้มากขึ้น

ลดภาระ: การแบ่งส่วนสามารถลดจำนวนผู้เล่นและจำนวนข้อมูลบนเซิร์ฟเวอร์เดียว จึงช่วยลดภาระบนเซิร์ฟเวอร์และปรับปรุงประสิทธิภาพ

l หลีกเลี่ยงความแออัด: การแบ่งส่วนสามารถลดความแออัดของผู้เล่นในพื้นที่เดียวกันและมอบประสบการณ์การเล่นเกมที่ราบรื่นยิ่งขึ้น

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

แล้วคุณจะนำแนวคิดนี้มาสู่ World Engine ได้อย่างไร? ต่างจากเครื่องคัดแยกชิ้นส่วนมากมายในอดีต"World Engine"การออกแบบนี้เหมาะสมกับความต้องการเฉพาะมากกว่า ทิศทางการปรับให้เหมาะสมรวมถึงปริมาณงานและเวลาทำงาน เพื่อให้เกิดประสิทธิภาพ"Tick rate"(เช่น ความถี่ในการอัปเดตต่อวินาที) และเวลาบล็อก ซึ่งซิงโครไนซ์ตามค่าเริ่มต้น เป้าหมายของการออกแบบคือเพื่อให้แน่ใจว่าธุรกรรมได้รับการประมวลผลอย่างรวดเร็วเพื่อรักษาประสบการณ์การเล่นเกมหรือประสิทธิภาพของระบบที่มีประสิทธิภาพ วิธีการเรียงลำดับใช้วิธีการเรียงลำดับบางส่วน แทนที่จะต้องใช้การเรียงลำดับธุรกรรมทั้งหมดทั้งหมด ซึ่งหมายความว่าไม่มีข้อกำหนดว่าทุกธุรกรรมจะต้องเกิดขึ้นหลังจากธุรกรรมอื่นๆ ทุกรายการ สิ่งนี้สามารถลดภาระในการคัดแยก ซึ่งสามารถตอบสนองความต้องการปริมาณงานสูงและเวลาในการบล็อกที่รวดเร็วได้ดีขึ้น

มีองค์ประกอบหลักสองประการที่นี่ EVM Base Shard (ชิ้นส่วน EVM) และ Game Shard (ชิ้นส่วนเกม) EVM shard คือสายโซ่ EVM ล้วนๆ และเคล็ดลับที่แท้จริงคือการแบ่งส่วนเกม ซึ่งโดยพื้นฐานแล้วคือมินิบล็อคเชนที่ออกแบบมาให้เป็นเซิร์ฟเวอร์เกมที่มีประสิทธิภาพสูง World Engine มีอินเทอร์เฟซการใช้งานแบบนำมาเองเพื่อให้เราปรับแต่งส่วนนี้ตามความต้องการของเรา ชิ้นส่วนที่สร้างขึ้นจะถูกฉีดเข้าไปในชิ้นส่วนฐาน คุณเพียงแค่ต้องใช้ชุดอินเทอร์เฟซมาตรฐาน เช่นเดียวกับ Cosmos ที่เราคุ้นเคย Cosmos มีอินเทอร์เฟซ IBC โดยพื้นฐานแล้วเราสามารถรวมสิ่งนี้เข้ากับข้อกำหนดที่คล้ายกัน โดยนำการแบ่งส่วนของเราเองมาไว้ในสแต็ก World Engine

Cardinal คือการนำส่วนแบ่งเกมไปใช้ครั้งแรกของ World Engine ใช้สถาปัตยกรรมเกม Entity-Component-System (ECS) ซึ่งเป็นสถาปัตยกรรมเชิงข้อมูล สิ่งนี้ทำให้สามารถขนานเกมและเพิ่มปริมาณการคำนวณเกมได้ มี อัตรา Tick ที่กำหนดค่าได้สูงสุดถึง 20 Tick ต่อวินาที สำหรับบล็อคเชนตรงนี้ นั่นคือ 20 บล็อกต่อวินาที นอกจากนี้ยังสร้างดัชนีด้วยตนเอง ไม่จำเป็นต้องใช้ตัวสร้างดัชนีภายนอก

ชื่อระดับแรก

บทสรุป: ความคิดเกี่ยวกับเกมลูกโซ่ทั้งหมด

เกมแบบ Full-chain เป็นทิศทางที่ค่อนข้างไม่ได้รับความนิยมในแวดวงการเข้ารหัสของเอเชียมาโดยตลอด แต่ด้วยการเปิดตัว Dojo เอ็นจิ้นเกมของ Starknet และการสาธิตการพัฒนาของ Tickchain แบบพิสูจน์แนวคิดที่ใช้ OP Stack การอภิปรายเกี่ยวกับเกมแบบ Full-chain ก็เริ่มร้อนขึ้นเรื่อยๆ ขอบเขตของบทความนี้คือระบบนิเวศที่ได้มาจาก Dark Forest ซึ่งเป็นระบบนิเวศที่ทรงพลังที่สุดในกลุ่มเกมทั้งหมด

จากการสำรวจประวัติศาสตร์และเทคโนโลยี เราพบว่า Rollup และ DApp มีขีดจำกัดสูงสุดที่สูงมากเช่นกัน จากมุมมองที่กว้างขึ้น ด้วยการปรับปรุงโครงสร้างพื้นฐาน ไม่ใช่แค่เกม แต่เป็นการสร้างและพัฒนาแนวคิดที่ซับซ้อนต่างๆ การใช้งานจะดำเนินการผ่าน MUD และการโต้ตอบจะถูกรวมเข้ากับโครงการ Rollup ที่ซับซ้อนมากขึ้น กระบวนทัศน์ใหม่ของ blockchain อาจเริ่มต้นจากเกมลูกโซ่เต็มรูปแบบ

การอ้างอิง

การอ้างอิง

1. ข้อความต้นฉบับ:Modular Summit Day 1 (Galois Stage)การแปล:World Engine: เฟรมเวิร์ก Sharded Rollup ที่ออกแบบมาสำหรับเกมแบบฟูลเชน

2.Lattice History

3.การอ่านที่เกี่ยวข้อง

4.AUTONOMOUS WORLDS

การอ่านที่เกี่ยวข้อง

1.การจับเวลาสำหรับ เทพดิจิทัล

2.การทบทวนประวัติการพัฒนาเกมแบบฟูลเชน

3.วิธีใช้ OPStack เพื่อสร้างวงจรนาฬิกาของเกมแบบ Full-chain

4.The future of on-chain gaming: 'The promise of MUD ECS engine'

5.Overview of MUD, which support the construction of autonomous worlds, and major game projects using MUD, such as OP Craft and Sky Strife

6.เหตุใดเกมฟูลเชนจึงได้รับความนิยม และเสน่ห์ของมันคืออะไร?

GameFi
ยินดีต้อนรับเข้าร่วมชุมชนทางการของ Odaily
กลุ่มสมาชิก
https://t.me/Odaily_News
กลุ่มสนทนา
https://t.me/Odaily_CryptoPunk
บัญชีทางการ
https://twitter.com/OdailyChina
กลุ่มสนทนา
https://t.me/Odaily_CryptoPunk
สรุปโดย AI
กลับไปด้านบน
จากมุมมองที่กว้างขึ้น ด้วยการปรับปรุงโครงสร้างพื้นฐาน ไม่เพียงแต่เกมเท่านั้น แต่ยังรวมถึงการสร้างและการตระหนักถึงแนวคิดที่ซับซ้อนต่างๆ จะดำเนินการผ่าน MUD และการโต้ตอบจะถูกรวมเข้ากับโครงการ Rollup ที่ซับซ้อนมากขึ้น ซึ่งเป็นกระบวนทัศน์ใหม่ของ blockchain อาจจะ มันจะเริ่มต้นด้วยเกมเต็มลูกโซ่
คลังบทความของผู้เขียน
YBB Capital
ดาวน์โหลดแอพ Odaily พลาเน็ตเดลี่
ให้คนบางกลุ่มเข้าใจ Web3.0 ก่อน
IOS
Android