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

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

สาเหตุหลักของปัญหาเหล่านี้คืออะไร? ความคิดเห็นแตกต่างกันไป ทีม TabiChain เชื่อว่าปัจจัยสำคัญคือนักพัฒนาเกมดั้งเดิมที่มีความสามารถพบปัญหาในการเข้าสู่ระบบนิเวศ Web3 เนื่องจากอุปสรรคทางเทคนิคและการเรียนรู้ สำหรับผู้ที่ไม่คุ้นเคยกับการพัฒนาเกมหรือซอฟต์แวร์ การเปลี่ยนจาก Web2 เป็น Web3 อาจดูเหมือนเพียงแค่การเปลี่ยนเรื่องราวและสภาพแวดล้อม แต่ความเป็นจริงนั้นที่แท้จริงยากยิ่งกว่า

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

เหตุผลทางเทคนิคที่มุ่งขัดข้องการพัฒนาเกมแบบดั้งเดิมจากการเข้าสู่ระบบ Web3

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

1. ความแตกต่างระหว่างแอปพลิเคชัน web3 และโครงสร้างซอฟต์แวร์แบบดั้งเดิม

บล็อกเชนและแอพลิเคชันบน (dApps) มีความแตกต่างพื้นฐานจากโครงสร้างซอฟต์แวร์แบบดั้งเดิมและต้องการนักพัฒนาต้องมีระบบความรู้ใหม่เช่น หลักการทำงานของบล็อกเชน โปรโตคอลของความเห็น โมเดลโปรแกรมสมาร์ทคอนแทรกต์ ฯลฯ นักพัฒนาเกมแบบดั้งเดิมต้องใช้เวลามากในการเรียนรู้ Solidity หรือภาษาสมาร์ทคอนแทรกต์อื่น ๆ และต้องเข้าใจว่า EVM ทำงานอย่างไร

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

1. ข้อจำกัดในการออกแบบสมาร์ทคอนแทรค

แม้ว่า EVM จะสามารถทำงานเชิงเลขและสามารถแสดงตรรกะอย่างไม่จำกัดทางทฤษฎี แต่ลักษณะของมันก็ไม่เอื้อต่อการพัฒนาเกมมากนัก เช่น:

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

• ไม่มีการเรียกกลับและกลไกอื่น ๆ และไม่รองรับ multi-threading และ asynchronous โดยที่ Solidity ถูกออกแบบสำหรับการพัฒนาสมาร์ทคอนแทรค Ethereum ซึ่งสภาพแวดล้อมการดำเนินการของ Solidity แตกต่างอย่างมีนัยจากสภาพแวดล้อมการเรียกใช้ที่เป็นปกติ การทำงานของ EVM เป็นรูปแบบของการทำธุรกรรมและทุกการเรียกใช้ฟังก์ชันจำเป็นต้องดำเนินการในธุรกรรมอย่างสมบูรณ์ ไม่มีแนวคิดของ "asynchronous" ในทางการในความหมายของการทำงานเก่าๆ ซึ่งหมายความว่าการเรียกใช้ฟังก์ชันใน Solidity จะเป็นอะตอมตั้งแต่เริ่มต้นจนจบและไม่สามารถถูกขัดจังหรือถูกตัดขาดโดยธุรกรรมอื่น
• ไม่มีความสามารถในการอ้างอิงข้อมูลภายนอก ถึงแม้จะมีโอราเคิลเช่น Chainlink อยู่ ไม่ว่าจากมุมมองการผสานและการเรียกร้องข้อมูล ความสะดวกสบายของมันก็ต่างกันอย่างมหาศาลจากการรับเรียกร้องข้อมูลโดยตรงผ่านคำขอ https และสิ่งนี้ทำให้นักพัฒนาสามารถเพิ่มการผสานเพิ่มเติม ภาระและความขึ้นอยู่
• ความสามารถในการขยายขนาดและประสิทธิภาพ ข้อจำกัดในการทำงาน ต้องทำให้โลจิกเกมเรียบง่ายหรือแยกเป็นธุรกรรมที่เรียบง่ายหลายรายการ เพื่อหลีกเลี่ยงค่า Gas ของธุรกรรมเดียวที่เพิ่มขึ้นมากเกินไปหรือเกินขีดจำกัดสูงสุด ซึ่งจำกัดการนำมาใช้ของสิ่งที่ซับซ้อนและฟังก์ชัน

1. ข้อจำกัดในการจัดเก็บข้อมูลและการเรียกข้อมูล

• สัญญาอัจฉริยะมีพื้นที่เก็บข้อมูลที่แพงและมีการออกแบบที่จำกัด ซึ่งทำให้ไม่เหมาะสมสำหรับการเก็บข้อมูลเกมมากมาย
• บันทึกเหตุการณ์อาจจำเป็นสำหรับการติดตามสถานะเกมอย่างอ้อมค้อมและการจับเหตุการณ์อาจไม่เสถียร ปัญหาเช่นเมื่อจะรีเฟรชสถานะเกมต้องการผู้เล่นหรือผู้ดำเนินการเกมเรียกใช้ให้มือ
• โครงสร้างข้อมูลบัญชีที่ EVM นํามาใช้ส่งผลให้ความสามารถในการจัดทําดัชนีข้อมูลไม่ดี เมื่อคุณสืบค้นข้อมูลของบัญชี คุณสามารถทราบยอดคงเหลือของโทเค็น ETH หรือโทเค็นแบบลูกโซ่เท่านั้น แต่สินทรัพย์ ERC-20 ใดที่เป็นเจ้าของและยอดคงเหลือของแต่ละสินทรัพย์ไม่สามารถทราบได้โดยตรง เช่นเดียวกับ NFT ข้อมูลนี้ถูกห่อหุ้มไว้ในสัญญาเฉพาะของแต่ละสินทรัพย์แทนที่จะถูกเก็บไว้ภายใต้บัญชีของผู้ใช้เอง

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

นักพัฒนา Web3 通常จะต้องผสานข้อมูลจากผู้ให้บริการข้อมูลบุคคลที่สาม เช่น Etherscan, NFTscan, The Graph, ฯลฯ และบางครั้งยังต้องจ่ายเงินสำหรับ API KEY ของพวกเขา นอกจากนี้ บริการบุคคลที่สามเหล่านี้เป็นฐานข้อมูลนอกเชือกที่อาจเป็นสาเหตุของความล่าช้า ข้อผิดพลาด เกินขีดจำกัดการเรียกใช้ การไม่พร้อมให้บริการและความล้มเหลวอื่น ๆ

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

1. ความท้าทายในการผสานส่วนประกอบของเกมที่มีอยู่กับบล็อกเชน

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

1. อัปเกรด แพทช์ และการป้องกันภัยภัย

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

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

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

1. การแยกส่วนของระบบนิเวศ และปัญหาประสบการณ์ของผู้ใช้

โซ่สาธารณะและเครื่องจำลองเสมือนมีภาษาสมาร์ทคอนแทร็คต่างกันอย่างสิ้นเชิง โครงสร้างข้อมูล ฯลฯ ใน Web2 นักพัฒนาเกมจะเลือกเครื่องมือพัฒนาส่วนหน้า跨แพลตฟอร์มเช่น Unity ซึ่งสามารถทำให้ชุดโค้ดที่ปรับปรุงเล็กน้อยสามารถทำงานบนสภาพแวดล้อมที่แตกต่างกันเช่น iPhone, Android และเดสก์ท็อป โดยเนื่องจากส่วนหลังไม่ทำงานบนอุปกรณ์ผู้ใช้ จึงไม่มีปัญหา跨แพลตฟอร์ม

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

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

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

สามารถบอกได้ว่า ส่วนใหญ่นักพัฒนาเกมชั้นนำยังไม่ได้เข้าสู่ Web3 โดยบางประการ สิ่งนี้ทำให้เกม Web3 ส่วนใหญ่มีแนวโน้มทางการเงินมากกว่าการเล่นและความสนุกสนาน

อุปสรรคที่มีลักษณะเดียวกันยังมีอยู่ที่ด้านผู้ใช้เช่นกัน เกม Web3 มีชุดขั้นตอนการดำเนินการที่ขัดขวางอัตราการแปลงของผู้ใช้ ทำให้มีกลุ่มผู้ใช้ขนาดใหญ่ของ Web2 ที่ไม่ต้องการทดลองหรือแม้แต่ไม่รู้จักถึงการมีอยู่ของเกม Web3

มีโครงการระดับพื้นฐานที่สามารถแก้ปัญหาดังกล่าวได้หรือไม่? โครงการ Tabi Chain อาจเป็นโครงการที่ใกล้เคียงกับหนึ่งในคำตอบสุดท้ายสำหรับเกม Web3 อย่างมาก คอนเซปต์หลักของมันคือ “Omni Execution Layer”: นักพัฒนาไม่ต้องกังวลเกี่ยวกับความแตกต่างระหว่าง VMs หรือสภาพแวดล้อมการดำเนินการต่าง ๆ อีกต่อไป พวกเขาสามารถใช้สภาพแวดล้อมการดำเนินการที่คุ้นเคยหรือแม้แต่ที่สามารถปรับแต่งได้เพื่อพัฒนาเกมโดยตรงหรือนำเข้า

นอกจากนี้ Tabi Chain ยังมีความเห็นร่วมกันแบบโมดูลาร์ ชั้นความปลอดภัย และคุณลักษณะอื่น ๆ ทุกอย่างเป็นโมดูลาร์และปรับแต่งได้เพื่อตอบสนองความต้องการของเกมและแอปพลิเคชันที่แตกต่างกัน

Omni-Execution Layer: เลือกชั้นทำงานโดยอิงตามความต้องการของนักพัฒนา

เรามาตรวจสอบแนวคิดพื้นฐานของบล็อกเชนอีกครั้ง ในขณะที่บางคนอาจอธิบายว่าเป็น ledger ที่ไม่ centralize และไม่สามารถเปลี่ยนแปลงได้ แต่มันถูกกำหนดอย่างแม่นยำเป็นการซิงโครไนซ์ของสถานะถาวรของ state machine ภายในเครือข่ายที่กระจาย

ในทางทฤษฎี บล็อกเชนรักษาสถานะเครื่องจักรที่ได้รับการยอมรับอย่างแพร่หลายและสถานะการดำเนินงานของมัน:

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

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

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

สําหรับ VM บล็อกเชนที่มีอยู่ Polymorphism VM จําเป็นต้องรวม VM เหล่านี้ภายในสภาพแวดล้อมรันไทม์และจัดเตรียมวิธีการเรียกอินเทอร์เฟซที่จําเป็น แนวคิดของ "บูรณาการ" ที่นี่สามารถดําเนินการได้สองวิธี:

Shared World State: คล้ายกับ Ethermint ที่รองรับ EVM บน Cosmos โดย EVM ทำหน้าที่เป็นชั้นผิว ซึ่งเน้นไปที่ปฏิสัมพันธ์ของผู้ใช้และการดำเนินการของสัญญา ทำให้กิจกรรมของผู้ใช้ทั้งหมดดูเหมือนว่าถูกดำเนินการบน EVM อย่างไรก็ตามผลลัพธ์สุดท้ายและข้อมูลของการดำเนินการเหล่านี้ถูกเก็บไว้ในโมดูล Cosmos อื่น ดังนั้นความเข้ากันได้ของ EVM นี้ก็คือการทำแม้ว่าข้อมูลพื้นฐาน

ความสัมพันธ์การทำการจับคู่นี้สามารถขยายไปยัง VM อื่น ๆ ได้เช่นกัน ตัวอย่างเช่น Ethermint สามารถรวมเข้าไว้ในชั้นโมดูล SVM เพิ่มเติม โดยที่ทั้ง SVM และ EVM จะสอดคล้องกับข้อมูลใต้พื้นผิวเดียวกัน

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

บริการหลักของ Tabi Chain จะใช้วิธี shared world state approach ซึ่งหมายความว่าตราบใดที่ VM ที่เกี่ยวข้องได้รับการปรับปรุงแล้ว dApps ที่พัฒนาสำหรับ VM นั้นสามารถใช้งานได้โดยตรงบน Main Service โดยไม่ต้องสร้างบริการแยก

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

ไม่ว่าจะใช้วิธีใด ก็ต้องสามารถที่จะตรวจสอบได้โดยโหนดผู้ดูแล ซึ่งหมายความว่า Polymorphism VM ต้องรวม VM หรือ runtimes ทั้งหมดที่ใช้โดยวิธีการประมวลผลต่าง ๆ

Web2 เกม การย้ายตัวอย่าง

Polymorphism VM สามารถปรับแต่งได้สูงทําให้เป็นประโยชน์อย่างยิ่งสําหรับนักพัฒนา Web2 พวกเขาสามารถใช้ภาษาและเฟรมเวิร์กที่คุ้นเคยเพื่อพอร์ตตรรกะทางธุรกิจใด ๆ ไปยัง Polymorphism VM

สมมติว่า Minecraft ต้องการย้ายมาใช้ Tabi กระบวนการทั่วไปจะเป็นดังนี้:

1. ปรับแก้รหัสเซิร์ฟเวอร์: ปรับเล็กน้อยรหัสเซิร์ฟเวอร์ Minecraft (ภาษา Java หรือภาษาอื่น ๆ) โดยย้ายข้อมูลที่ต้องอยู่บนเชนไปยังฐานข้อมูล (หรือชุดของฐานข้อมูล) ระบุและเลือกฟังก์ชันทั้งหมดที่อาจเปลี่ยนแปลงฐานข้อมูลนี้ (เช่น ฟังก์ชันการเปลี่ยนสถานะ)
2. แพ็คเกจส่วนประกอบ: แพ็คเกจฐานข้อมูลและฟังก์ชันเหล่านี้ในไฟล์ JAR ซึ่งเป็นโปรแกรมที่สามารถใช้ได้ใน Java เข้ารวม JRE (Java Runtime Environment) เข้าไปในแพ็คเกจนี้ แล้วนำแพ็คเกจทั้งหมดนี้มาโหลดลงใน Polymorphism VM เพื่อให้มั่นใจว่าข้อมูลทั้งหมดอยู่บนเชน
3. Run Off-Chain Logic: ให้ตรวจสอบโลจิก Off-Chain: ให้ทำโลจิกที่อยู่ในพื้นหลังด้านหลังที่ไม่จำเป็นต้องอยู่บนเชน (เช่น การรวมทีม แชท เป็นต้น) บนเซิร์ฟเวอร์ Off-Chain
4. เริ่มบริการ: เริ่มต้นบริการใน Tabi Chain และแจ้งให้โพลิมอร์ฟิซึ่ม VM ของโหนดผู้ดูแลระบบโหลด JRE เดียวกัน
   

ด้วยนี้กระบวนการทั้งหมดเสร็จสิ้น

สำหรับนักพัฒนา การปรับเปลี่ยนเหล่านี้ถูกทำภายในภาษา Java และกรอบการทำงานที่มีอยู่ แนวคิดเดียวกันนี้ใช้กับเกมที่พัฒนาโดยใช้วิธีอื่น ๆ สำหรับผู้ใช้ ปฏิสัมพันธ์กับเกมยังคงเหมือนเดิมอย่างมาก โดยชัดเจนว่าวิธีการนี้ในการโอนเกม Web2 เป็นอย่างรวดเร็วและมีประสิทธิภาพมาก และเป็นไปได้ที่จะกลายเป็นแบบจำลองพื้นฐานสำหรับการนำเกม Web3 ไปใช้ในมวลชน

รายละเอียดของฟังก์ชัน Game STR (State Transition Runtime)

ตัวอย่างก่อนหน้านี้ให้ภาพรวมทั่วไปเกี่ยวกับการย้ายเกม Web2 เพื่อเข้าใจลึกขึ้นเราต้องลงลึกเข้าไปในรายละเอียดมากขึ้น ในครั้งนี้เราจะใช้ตัวอย่างทั่วไปแทนที่จะใช้เกมที่เฉพาะเจาะจงเพื่อแสดงรายละเอียดที่เกี่ยวข้องกับการทำงานของ Omni-Execution Layer

โดยพื้นฐานแล้ว การปรับแต่งสภาพแวดล้อมในเกมสามารถมองเป็นการสร้างเครื่องจักรสถานะของเกมบนบล็อกเชน ที่เรียกว่า State Transition Runtime (STR) ใน Tabi

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

โดยพื้นฐานแล้ว การปรับแต่งสภาพแวดล้อมในการเล่นเกมสามารถถือว่าเป็นการสร้างเครื่องจักรสถานะสำหรับเกมใดๆ บนบล็อกเชน ซึ่งเรียกว่า State Transition Runtime ใน Tabi

STR สามารถรวมอยู่ใน Polymorphism VM ในรูปแบบไบนารีหรือโมดูล

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

1. World DBContains all user data within the application that needs to be recorded on the blockchain. This data should be valuable and important, so a blockchain-like structure is needed to ensure its availability. Therefore, not all data needs to be recorded on the blockchain. For example, in games, the user’s chat content is generally not important and is disposable, so there is no need to put it on the blockchain.
2. มันสามารถแสดงสถานะที่สมบูรณ์ของโลก ในหลายสถานการณ์เช่นในเกมนิพจน์นี้ไม่จําเป็นต้องบ่งบอกถึงความสามารถในการตรวจสอบย้อนกลับในระดับสูง - ตัวสะสมอย่างง่ายจะเพียงพอซึ่งหมายความว่าโครงสร้างข้อมูลเช่นต้นไม้ Merkle ไม่จําเป็นเสมอไป อย่างไรก็ตามไม่ว่าจะใช้โครงสร้างข้อมูลใดเพื่อเป็นตัวแทนของรัฐโลกเป็นสิ่งสําคัญที่สถานะโลกของฐานข้อมูลโลกสามารถแสดงในรูปแบบสรุปได้
3. ฟังก์ชันใด ๆ ที่สามารถทำให้เกิดการเปลี่ยนแปลงกับฐานข้อมูลโลกเรียกว่า ฟังก์ชันการเปลี่ยนสถานะ และควรถูกห่อหุ้มอยู่ในเวลารันไทม์การเปลี่ยนสถานะ การแก้ไขฐานข้อมูลโลกภายนอกการรันไทม์ควรถือเป็นการกระทำที่ผิดกฎหมายและถูกปฏิเสธ
4. อินเทอร์เฟซขาเข้าและขาออกควรเป็นไปตามการออกแบบของตัวแปลงข้อมูลขาเข้าและผู้เสนอบล็อก นี่เป็นเรื่องที่เรียบง่ายและจะไม่อธิบายอย่างละเอียดที่นี่

โครงสร้างองค์กรต่อไปนี้เป็นส่วนประกอบที่สำคัญของ STR นี้ Tabi จะให้ SDK ตามค่าเริ่มต้นเพื่อช่วยให้นักพัฒนาสร้าง runtime ได้

World DB

ในปฏิบัติจริง เกมหรือแอปพลิเคชัน จะใช้ฐานข้อมูลมากกว่าหนึ่งรูปแบบและฐานข้อมูลเหล่านี้อาจเป็นประเภทที่แตกต่างกัน ขอสมมติว่าเกมเฉพาะใดใช้ทั้งฐานข้อมูลเชิงสัมพันธ์และฐานข้อมูล key-value

ข้างล่างคือตัวอย่างฐานข้อมูลที่เกี่ยวข้องอย่างง่าย

1. UID: แทนผู้ใช้ที่เป็นเอกลักษณ์ ซึ่งอาจเป็นคีย์สาธารณะหรือตัวระบุอื่น ๆ
2. Nonce: ใช้เพื่อป้องกันการโจมตีที่ทำซ้ำ
3. ข้อมูลเพิ่มเติม: ประเภทของข้อมูลใดๆ

นี่คือฐานข้อมูลคีย์-ค่าที่เรียบง่าย:

ฟังก์ชันการเปลี่ยนสถานะ

นี่คือฟังก์ชั่นการเปลี่ยนสถานะอย่างง่าย เมื่อฟังก์ชันนี้ได้รับอินพุตจากผู้ใช้มันจะคูณด้วย 5 และแก้ไขข้อมูลในฐานข้อมูลเชิงสัมพันธ์

อะคูมูลเลเตอร์ของรัฐโลก

เราสามารถสร้างตัวสะสมแฮชเพื่อแทนสถานะโลกอย่างง่าย

A_s+1 = hash(A_s + hash(query))

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

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

กระบวนการอัปเดตสำหรับฐานข้อมูลคีย์-ค่า (KVDB) ทำตามหลักการเดียวกัน

เลขสุ่ม

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

สรุป

จากตัวอย่างข้างต้น เราสามารถเห็นได้ว่า Omni-Execution Layer ของ Tabi Chain มอบความยืดหยุ่นให้กับนักพัฒนาเกมอย่างสำคัญผ่านการแบ่งเป็นโมดูล ด้วยข้อจำกัดทางพื้นที่เราไม่สามารถพูดถึงรายละเอียดทั้งหมดที่นี่ แต่จุดความสำคัญที่กล่าวถึงเพียงพอต่อการสาธิตว่า โซลูชันของ Tabi Chain เป็นทั้งแต่งและนวัตกรรม

ในนิเวศ Web3 ปัจจุบัน งานที่พัฒนาบนเชนและ VM ต่าง ๆ มักขาดความพกพา สำหรับเกม Web2 ที่จะเปลี่ยนมาใช้ Web3 มักหมายถึงการเขียนเกมใหม่ในภาษาและสภาพแวดล้อมที่ไม่คุ้นเคย พบกับข้อ จำกัด ต่าง ๆ ที่น่าประหลาด

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

เราหวังว่า Tabi Chain สามารถเป็นตัวกระตุ้นสำหรับการนำมาใช้ในการเล่นเกม Web3 ขนาดใหญ่ ที่ดึงดูดนักพัฒนาเกม Web2 ที่มีความสามารถและนำเกมที่จริงใจและสนุกสนานมาสู่พื้นที่ Web3

ข้อความปฏิเสธความรับผิดชอบ：

1. บทความนี้ถูกนำมาจาก [GateWeb3 ของเกต]. All copyrights belong to the original author [罗奔奔]. หากมีข้อขัดแย้งใดๆในการนำเผยแพร่นี้ โปรดติดต่อGate Learnทีม และพวกเขาจะจัดการกับมันโดยเร็ว
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงอยู่ในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำด้านการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นๆ นำมาทำโดยทีม Gate Learn หากไม่ได้กล่าวถึง การคัดลอก การกระจาย หรือการลอกเลียนบทความที่ถูกแปล จะถูกห้าม