Điều này rõ ràng không khớp với mô hình phát triển của các trò chơi truyền thống. Các trò chơi truyền thống thành công thu hút nhiều người dùng thông qua cơ chế trò chơi hấp dẫn, cho phép các nhà phát triển xây dựng con đường sinh lời và có thể mở rộng vào các sản phẩm liên quan và IPs. Những trò chơi này hoạt động trong một chu kỳ tích cực nơi người chơi thích thú với trò chơi và thường xuyên đạt được lợi ích kinh tế cả trong và ngoài trò chơi.

Ngược lại, các trò chơi blockchain hiện tại chủ yếu thu hút người chơi thông qua lợi nhuận tài chính. Ngoài sự ít hấp dẫn của chúng, các trò chơi Web3 cũng đối diện với các vấn đề lâu nay như rào cản cao và quy trình tương tác rườm rà.

Nguyên nhân gốc rễ của những vấn đề này là gì? Ý kiến ​​đa dạng. Nhóm TabiChain tin rằng một yếu tố quan trọng là các nhà phát triển trò chơi truyền thống tài năng gặp khó khăn khi muốn tham gia vào hệ sinh thái Web3 do các rào cản về kỹ thuật và học hỏi. Đối với những người không quen thuộc với việc phát triển trò chơi hoặc phần mềm, việc chuyển từ Web2 sang Web3 có vẻ như chỉ là một sự thay đổi về câu chuyện và môi trường, nhưng thực tế thì khắc nghiệt hơn nhiều.

Vậy, chúng ta có thể tạo môi trường chào đón hơn cho các nhà phát triển trò chơi truyền thống hoặc các công ty liên quan thông qua công nghệ như thế nào? Trong các phần tiếp theo, chúng tôi sẽ phân tích kỹ lưỡng những thách thức mà các trò chơi Web3 đang phải đối mặt và các giải pháp cho chúng, giải thích cách ngành công nghiệp game Web3 trong tương lai có thể được điều chỉnh kỹ thuật để phù hợp hơn với các nhà phát triển trò chơi truyền thống.

Lý do kỹ thuật ngăn chặn các nhà phát triển trò chơi truyền thống tham gia hệ sinh thái Web3

Trong bài viết trước, chúng tôi đã đề cập đến việc công nghệ không thân thiện và chi phí học tập cao là những yếu tố cốt lõi ngăn cản các bác sĩ trò chơi truyền thống tham gia hệ sinh thái web3. Cái gọi là công nghệ không thân thiện và chi phí học tập cao có thể được mở rộng thành các điểm sau:

1. Sự khác biệt giữa ứng dụng web3 và cấu trúc phần mềm truyền thống

Blockchain và các ứng dụng trên nó (dApps) hoàn toàn khác biệt so với kiến trúc phần mềm truyền thống và đòi hỏi các nhà phát triển phải có một hệ thống kiến thức mới, như nguyên lý hoạt động của blockchain, giao thức đồng thuận, mô hình lập trình hợp đồng thông minh, v.v. Nhà phát triển trò chơi truyền thống cần phải dành rất nhiều thời gian để học Solidity hoặc các ngôn ngữ lập trình hợp đồng thông minh khác và cần hiểu cách EVM hoạt động.

Ngoài ra, logic trò chơi truyền thống thường được thực thi trên một máy chủ tập trung, có thể linh hoạt xử lý trạng thái trò chơi phức tạp và tương tác tần suất cao. Việc chạy logic trò chơi trên blockchain yêu cầu một mức độ đơn giản hoặc tái cấu trúc cao, vì mỗi hoạt động phải được công bố cho mạng phân phối để thực thi và sau đó được tải lên chuỗi, điều này bị hạn chế nghiêm trọng bởi hiệu suất và chi phí của blockchain.

1. Giới hạn thiết kế của hợp đồng thông minh

Mặc dù EVM là đủ Turing và lý thuyết có thể biểu diễn logic tùy ý, nhưng đặc tính của nó rất không thuận lợi cho việc phát triển trò chơi, chẳng hạn như:

• Thiếu bộ hẹn giờ. Tất cả các hoạt động trên chuỗi Ethereum phải được kích hoạt bằng tay bởi tài khoản EOA. Để đạt được hiệu ứng tương tự như một bộ hẹn giờ, các nhà phát triển cần triển khai một dịch vụ bổ sung và duy trì một tài khoản EOA và danh sách sự kiện để kích hoạt các nhiệm vụ được lên lịch bằng tay. Do vấn đề trễ trên chuỗi, không đảm bảo rằng các nhiệm vụ được lên lịch này sẽ hoàn thành đúng hạn.

• Không có callback và các cơ chế khác, và nó không hỗ trợ đa luồng và không đồng bộ. Bởi vì Solidity được thiết kế để phát triển hợp đồng thông minh Ethereum, môi trường thực thi của nó khác biệt đáng kể so với môi trường thời gian chạy truyền thống. Hoạt động của EVM là giao dịch và mỗi cuộc gọi hàm cần được thực hiện hoàn toàn trong một giao dịch. Không có khái niệm "không đồng bộ" theo nghĩa truyền thống. Điều này có nghĩa là một cuộc gọi hàm trong Solidity là nguyên tử từ đầu đến cuối và không thể bị gián đoạn bởi các giao dịch khác.
• Không có khả năng tham chiếu dữ liệu bên ngoài. Mặc dù có các trung gian như Chainlink, cho dù từ quan điểm tích hợp hoặc quan điểm gọi dữ liệu, sự dễ sử dụng của nó khác biệt rất lớn so với việc trực tiếp nhận dữ liệu thông qua các yêu cầu https, và điều này cho phép các nhà phát triển thêm các tích hợp bổ sung. Gánh nặng và phụ thuộc.
• Khả năng mở rộng và hạn chế về hiệu suất. Logic trò chơi phải được đơn giản hóa hoặc phân chia thành nhiều giao dịch đơn giản để tránh phí gas của một giao dịch đơn lẻ trở nên quá cao hoặc vượt quá giới hạn tối đa, điều này hạn chế việc thực hiện các tương tác và chức năng phức tạp.

1. Giới hạn về lưu trữ và truy xuất dữ liệu

• Hợp đồng thông minh có không gian lưu trữ đắt đỏ và thiết kế hạn chế, làm cho chúng không phù hợp để lưu trữ lượng dữ liệu lớn của trò chơi.
• Nhật ký sự kiện có thể cần thiết để theo dõi trạng thái trò chơi một cách gián tiếp, và việc ghi lại sự kiện có thể không ổn định. Các vấn đề như khi nào cần làm mới trạng thái trò chơi thường đòi hỏi người chơi hoặc người điều hành trò chơi kích hoạt nó bằng tay.
• Cấu trúc dữ liệu tài khoản được EVM áp dụng dẫn đến khả năng chỉ mục dữ liệu kém. Khi bạn truy vấn dữ liệu của một tài khoản, bạn chỉ biết số dư của ETH hoặc token bản địa chuỗi của nó, nhưng bạn không thể biết được tài sản ERC-20 mà nó sở hữu và số dư của mỗi tài sản một cách trực tiếp. Điều này cũng đúng cho NFT. Thông tin này được đóng gói trong hợp đồng độc quyền của mỗi tài sản, thay vì được lưu trữ dưới tài khoản của người dùng.

Chúng ta có thể xem thông tin loại token và số dư của một địa chỉ cụ thể từ các công cụ như Etherscan. Những thông tin này được lập chỉ mục bởi các công cụ ngoại vi như trình duyệt blockchain, và cần xây dựng một cơ sở dữ liệu lớn riêng và quét hoàn toàn nó. Chỉ bằng cách thu thập tất cả dữ liệu khối hoặc theo dõi sự kiện trên chuỗi mới có thể tóm tắt tất cả dữ liệu trên chuỗi.

Nhà phát triển Web3 thường phải tích hợp các nhà cung cấp dữ liệu bên thứ ba như Etherscan, NFTscan, The Graph, v.v., và thậm chí phải trả chi phí cho API KEY của họ. Ngoài ra, những dịch vụ bên thứ ba này về cơ bản là cơ sở dữ liệu off-chain, có thể gây ra độ trễ, lỗi, vượt quá giới hạn gọi, dịch vụ không khả dụng và các lỗi khác.

Hãy so sánh sự khác biệt giữa hình thức cơ sở dữ liệu của hầu hết các trò chơi và phương pháp lưu trữ dữ liệu trong blockchain. Sự khác biệt giữa hai cái này rất rõ ràng. Cấu trúc dữ liệu của hầu hết các trò chơi được tùy chỉnh hoàn toàn bởi chính nó, có khả năng biểu diễn và chỉ mục tốt, và không cần phải dựa vào bất kỳ dịch vụ của bên thứ ba nào.

1. Thách thức trong việc tích hợp tài sản trò chơi hiện có với blockchain

Tài sản game hiện có (như vật phẩm và nhân vật) thường không được tạo và quản lý trên blockchain. Việc di dời những tài sản này vào blockchain thường liên quan đến việc chuyển đổi các loại dữ liệu phổ biến nhưng dài dòng thành NFT hoặc Tokens tiêu chuẩn, điều này đòi hỏi công việc di dời và tích hợp phức tạp và sẽ ảnh hưởng đến hệ thống kinh tế game hiện có.

1. Nâng cấp, vá lỗi và phòng ngừa thảm họa

Trên Ethereum, khi một hợp đồng thông minh được triển khai, mã nguồn là bất biến, làm cho việc nâng cấp và vá lỗi phức tạp hơn so với phần mềm truyền thống. Các nhà phát triển thường sử dụng hợp đồng proxy hoặc mẫu phiên bản để né tránh hạn chế này, nhưng điều này làm tăng độ phức tạp của cấu trúc tổng thể. Hợp đồng proxy cần được sử dụng cẩn thận đặc biệt để tránh hỏng dữ liệu do xung đột vị trí lưu trữ. Ngoài ra, nguy cơ rò rỉ quyền quản trị cũng rất nghiêm trọng.

Việc nâng cấp mã nguồn của các trò chơi truyền thống không quá phức tạp về cấu trúc kỹ thuật. Điều duy nhất có thể cần bị hạn chế là quyền lực nâng cấp tập trung. Điều này có thể được thực hiện thông qua các phương pháp như DAO thay vì phụ thuộc vào hợp đồng thông minh.

Ngoài ra, các trò chơi truyền thống thường chụp ảnh chụp hoặc sao lưu cơ sở dữ liệu. Điều này có thể không quan trọng lắm thông thường, nhưng nếu bạn gặp phải một lỗi lớn trong quá trình nâng cấp, bạn có thể nhanh chóng quay lại dữ liệu, điều này cơ bản là một ảo tưởng trên blockchain. Ngay cả khi một số dữ liệu trò chơi bị quay lại bằng cách xây dựng lại hợp đồng, cách di chuyển dữ liệu và trạng thái của hợp đồng cũ sang hợp đồng mới vẫn phức tạp.

1. Rối loạn sinh thái và vấn đề trải nghiệm người dùng

Các chuỗi công cộng và máy ảo hoàn toàn khác nhau về ngôn ngữ hợp đồng thông minh, kiến trúc, cấu trúc dữ liệu, vv. Trong Web2, các nhà phát triển game sẽ chọn các công cụ front-end đa nền tảng như Unity, giúp mã nguồn dễ dàng điều chỉnh để chạy trên môi trường khác nhau như iPhone, Android và máy tính để bàn. Vì phần backend không chạy trên thiết bị người dùng, không có vấn đề đa nền tảng.

Trong Web3, điều này về cơ bản là một sản phẩm xa xỉ. Di chuyển sang một chuỗi hoặc máy ảo khác có nghĩa là phải xây dựng lại toàn bộ dự án và gánh nặng chi phí lớn. Hơn nữa, các nhà phát triển mới vào Web3 hoàn toàn không có kinh nghiệm để chọn một hệ sinh thái phù hợp với họ. Đó có phải từ một quan điểm kỹ thuật hay một quan điểm sinh thái không?

Ở cấp độ trải nghiệm người dùng, tương tác blockchain rất phức tạp. Khái niệm trừu tượng tài khoản mà trước đây rất phổ biến đã xuất hiện chính xác là để giải quyết các vấn đề trải nghiệm người dùng web3, nên tôi sẽ không đi vào chi tiết ở đây.

Sau khi liệt kê các đề xuất lớn trên, hãy tóm tắt: các nhà phát triển từ web2 đến web3 đối mặt với một ngưỡng chuyển đổi lớn. Nếu họ là các nhà phát triển hàng đầu trong web2, không cần phải từ bỏ sự nghiệp của mình trong web2 và chuyển sang một lĩnh vực xa lạ như web3. Trong môi trường này, chúng tôi đang phát triển một số doanh nghiệp mà chúng tôi không biết liệu chúng có thể thành công hay không.

Có thể nói rằng, hầu hết các nhà phát triển game hàng đầu chưa tham gia Web3. Ở một mức độ nào đó, điều này khiến cho hầu hết các trò chơi Web3 thiên về việc đầu cơ tài chính hơn là có đặc tính chơi cao và vui vẻ đặc biệt.

Các rào cản cùng loại cũng tồn tại ở phía người dùng. Các trò chơi Web3 có một loạt các bước hoạt động gây cản trở cho tỷ lệ chuyển đổi người dùng, dẫn đến một nhóm người dùng lớn của Web2 không muốn trải nghiệm hoặc thậm chí hoàn toàn không nhận thức được sự tồn tại của các trò chơi Web3.

Có dự án cấp hạ tầng nào có thể giải quyết các vấn đề trên không? Tabi Chain có thể là một dự án rất gần gũi với một trong những giải pháp cuối cùng cho các trò chơi Web3. Ý tưởng cốt lõi của nó là “Lớp Thi Hành Omni”: Các nhà phát triển không cần phải quan tâm đến sự khác biệt giữa các VM hoặc môi trường hoạt động khác nhau nữa. Họ có thể trực tiếp sử dụng môi trường hoạt động quen thuộc hoặc thậm chí là có thể tùy chỉnh để phát triển hoặc chuyển port trò chơi.

Ngoài ra, Tabi Chain cũng có cơ chế đồng thuận modul, lớp bảo mật và các tính năng khác. Mọi thứ đều là modul và có thể tùy chỉnh để đáp ứng nhu cầu của các trò chơi và ứng dụng khác nhau.

Omni-Execution Layer: Lựa chọn Môi trường Thực thi Dựa trên Nhu cầu của Nhà phát triển

Hãy xem xét lại khái niệm cơ bản của blockchain. Trong khi một số người có thể mô tả nó như một sổ cái phi tập trung, không thể thay đổi, nó được định nghĩa chính xác hơn là đồng bộ xác thực của trạng thái cố định của một máy trạng thái trong mạng phân tán.

Bản chất, blockchain duy trì một máy trạng thái được chấp nhận một cách phổ biến và trạng thái hoạt động của nó:

• Mỗi đầu vào là xác định, được ghi lại trong mỗi khối;
• Chức năng chuyển trạng thái là xác định, được đại diện bởi máy ảo hoặc thời gian chạy trong khách hàng blockchain;
• Trạng thái đầu ra cũng là xác định, được ghi lại trong mỗi khối;

Do đó, hệ thống đồng thuận của blockchain không cần bị giới hạn chỉ trong một lớp thực thi duy nhất (như chỉ có EVM). Bất kể số lớp thực thi, miễn là chuỗi có thể xác minh trạng thái trên nhiều lớp, cho phép mỗi trò chơi hoạt động trong môi trường riêng của nó, chúng ta có thể giải quyết các vấn đề khác nhau đã thảo luận trước đó.

Trong Tabi, mỗi trò chơi hoặc ứng dụng có thể xây dựng Dịch vụ độc lập của riêng mình. Tất cả các Dịch vụ gửi các khối được tạo ra của riêng mình đến hệ thống đồng thuận của chuỗi; Các Node Giám sát bao gồm runtime/VM trong tất cả các Dịch vụ để xác minh trạng thái của các khối dịch vụ. existThe hạt nhân của lớp thực thi đa năng của Tabi có thể được coi là một VM có khả năng đa hình, vì vậy nó được gọi là Polymorphism VM.

Đối với các máy ảo blockchain hiện có, máy ảo Đa hình cần tích hợp các máy ảo này trong môi trường chạy của nó và cung cấp các phương thức gọi giao diện cần thiết. Khái niệm “tích hợp” ở đây có thể được triển khai theo hai cách:

Trạng thái thế giới chia sẻ: Tương tự như Ethermint, hỗ trợ EVM trên Cosmos. EVM hoạt động như một lớp bề mặt, tập trung vào tương tác người dùng và hoạt động hợp đồng, khiến tất cả các hoạt động từ phía người dùng trông như được thực hiện trên EVM. Tuy nhiên, kết quả cuối cùng và dữ liệu của các hoạt động này được lưu trữ trong các mô-đun Cosmos khác. Do đó, tính tương thích EVM này về cơ bản là một ánh xạ của dữ liệu cơ bản.

Mối quan hệ ánh xạ này có thể được mở rộng sang các máy ảo khác. Ví dụ, Ethermint có thể tích hợp một lớp mô-đun SVM bổ sung, trong đó cả SVM và EVM tương ứng với cùng một dữ liệu cơ bản.

Điều này tương tự như việc sử dụng VMWare trên máy tính để chạy một máy ảo Windows. VMWare có thể truy cập cả ổ cứng ảo của máy ảo và ổ cứng vật lý của máy tính. Nếu bạn khởi động một máy ảo Mac sau đó, nó có thể gắn kết dữ liệu từ ổ đĩa vật lý theo cùng cách. Thiết lập này hiệu quả cho phép nhiều máy ảo chia sẻ tài nguyên và trạng thái của cùng một môi trường.

Dịch vụ chính của Tabi Chain sẽ sử dụng phương pháp trạng thái thế giới chia sẻ. Điều này có nghĩa là miễn là VM tương ứng được điều chỉnh, các ứng dụng phát triển cho VM đó có thể triển khai trực tiếp trên Dịch vụ Chính mà không cần tạo ra một dịch vụ riêng biệt.

Independent World State: Các ứng dụng và trò chơi khác nhau có yêu cầu riêng biệt, và một số trò chơi sử dụng các runtime tùy chỉnh. Do đó, một phương pháp thông thường để tích hợp tất cả các máy ảo thông qua một “trạng thái thế giới chia sẻ” trong Polymorphism VM không phù hợp cho mọi trường hợp. Một trạng thái thế giới độc lập cũng cần thiết, vì nó đơn giản hơn để triển khai và lý tưởng cho các dịch vụ với dữ liệu hoàn toàn riêng biệt.

Bất kể phương pháp sử dụng, nó phải được xác minh bởi Các Node Giám sát. Điều này có nghĩa là Polymorphism VM phải bao gồm tất cả các VM hoặc thời gian chạy được sử dụng bởi các phương pháp triển khai khác nhau.

Ví dụ Chuyển đổi Trò chơi Web2

Polymorphism VM rất linh hoạt, điều này đặc biệt hữu ích cho các nhà phát triển Web2. Họ có thể sử dụng ngôn ngữ và khung ứng dụng quen thuộc để di dời bất kỳ logic kinh doanh nào sang Polymorphism VM.

Giả sử Minecraft muốn di dời sang Tabi. Quy trình chung sẽ là như sau:

1. Sửa mã máy chủ: Sửa đổi một cách nhẹ nhàng mã máy chủ Minecraft (bằng Java hoặc bất kỳ ngôn ngữ nào khác), di chuyển dữ liệu cần phải được trên chuỗi vào một cơ sở dữ liệu (hoặc một tập hợp các cơ sở dữ liệu). Xác định và chọn tất cả các hàm có thể thay đổi cơ sở dữ liệu này (tức là, các hàm chuyển trạng thái).
2. Đóng gói các thành phần: Đóng gói cơ sở dữ liệu này và các chức năng này vào một tập tin JAR, đó là một chương trình có thể chạy trong Java. Bao gồm JRE (Môi trường Thực thi Java) trong gói này. Toàn bộ gói này sau đó được tải vào Polymorphism VM, đảm bảo tất cả dữ liệu đều trên chuỗi.
3. Chạy Logic Ngoại Chuỗi: Chạy logic backend khác không cần thiết phải trên chuỗi (như việc hình thành nhóm, trò chuyện, v.v.) trên máy chủ ngoại chuỗi.
4. Bắt đầu Dịch vụ: Khởi tạo Dịch vụ trong Tabi Chain và thông báo cho Polymorphism VM của Các nút Giám sát để tải cùng JRE.
   

Với điều này, toàn bộ quá trình đã hoàn tất.

Đối với các nhà phát triển, những điều chỉnh này được thực hiện trong ngôn ngữ và framework Java hiện có. Cùng một khái niệm áp dụng cho các trò chơi được phát triển bằng bất kỳ phương pháp nào khác. Đối với người dùng, tương tác game vẫn giữ nguyên. Rõ ràng, phương pháp chuyển đổi trò chơi Web2 này rất nhanh chóng và hiệu quả, tiềm năng trở thành mô hình cơ bản cho việc áp dụng rộng rãi trò chơi Web3.

Chi tiết về chức năng của STR (State Transition Runtime) trong trò chơi

Ví dụ trước cung cấp tổng quan chung về việc chuyển một trò chơi Web2. Để có được sự hiểu biết sâu sắc hơn thì cần phải đi sâu vào chi tiết hơn. Lần này, chúng tôi sẽ sử dụng một ví dụ chung thay vì một trò chơi cụ thể để minh họa các chi tiết liên quan đến thời gian chạy của Lớp thực thi Omni.

Về cơ bản, tùy chỉnh môi trường thực thi của một trò chơi có thể được xem như việc tạo máy trạng thái của trò chơi trên blockchain, được gọi là Runtime Chuyển Trạng thái (STR) trong Tabi.

Ví dụ trên là quy trình chung của việc di chuyển trò chơi Web2. Chúng ta vẫn cần biết thêm về chi tiết. Lần này chúng ta sử dụng một ví dụ chung thay vì một ví dụ cụ thể về trò chơi để hiển thị các chi tiết liên quan đến thời gian chạy trong lớp thực thi vô song.

Về cơ bản, tùy chỉnh môi trường chạy của một trò chơi có thể được coi như việc tạo ra một máy trạng thái cho một trò chơi cụ thể trên blockchain, được gọi là State Transition Runtime trong Tabi.

STR có thể được tích hợp vào Polymorphism VM dưới dạng binary hoặc module.

Trong một hệ thống giống như blockchain, chúng ta cần đảm bảo tính minh bạch của các đầu vào, tính công khai của các chuyển đổi trạng thái, và tính biểu đạt của trạng thái toàn cầu. Để đáp ứng những yêu cầu này, chúng ta cần xây dựng một runtime với những tính năng sau:

1. World DBChứa tất cả dữ liệu người dùng trong ứng dụng cần được ghi lại trên blockchain. Dữ liệu này nên có giá trị và quan trọng, do đó cần có cấu trúc giống như blockchain để đảm bảo tính sẵn có của nó. Do đó, không phải tất cả dữ liệu cần được ghi lại trên blockchain. Ví dụ, trong các trò chơi, nội dung trò chuyện của người dùng thường không quan trọng và có thể bỏ đi, nên không cần phải đưa nó lên blockchain.
2. Nó có thể diễn tả trạng thái hoàn chỉnh của thế giới. Trong nhiều tình huống, như trong trò chơi, sự diễn tả này không nhất thiết ám chỉ một mức độ theo dõi cao - một bộ tích lũy đơn giản sẽ đủ, điều này có nghĩa rằng một cấu trúc dữ liệu như cây Merkle không luôn cần thiết. Tuy nhiên, bất kể cấu trúc dữ liệu nào được sử dụng để biểu diễn trạng thái thế giới, điều quan trọng là trạng thái thế giới của cơ sở dữ liệu thế giới có thể được diễn tả dưới dạng tóm lược.
3. Bất kỳ chức năng nào có thể gây ra sự thay đổi cho cơ sở dữ liệu thế giới được gọi là chức năng chuyển trạng thái, và nên được đóng gói trong thời gian chạy chuyển trạng thái. Bất kỳ sửa đổi nào đối với cơ sở dữ liệu thế giới bên ngoài thời gian chạy nên được coi là bất hợp pháp và bị từ chối.
4. Giao diện vào và ra nên tuân thủ theo thiết kế của Trình thông dịch Đầu vào và Người đề xuất Khối. Điều này tương đối đơn giản và sẽ không được giải thích chi tiết ở đây.

Các cấu trúc tổ chức sau đây là các yếu tố cần thiết của STR này. Tabi sẽ cung cấp một SDK mặc định để hỗ trợ các nhà phát triển tạo ra runtime.

World DB

Trong thực tế, một trò chơi hoặc ứng dụng có thể sử dụng nhiều hơn một cơ sở dữ liệu, và những cơ sở dữ liệu này có thể thuộc loại khác nhau. Hãy giả sử rằng một trò chơi cụ thể sử dụng cả cơ sở dữ liệu quan hệ và cơ sở dữ liệu key-value.

Dưới đây là một ví dụ cơ sở dữ liệu quan hệ đơn giản:

1. UID: Đại diện cho một người dùng duy nhất, có thể là một khóa công khai hoặc định danh khác.
2. Nonce: được sử dụng để ngăn chặn cuộc tấn công phát lại.
3. Extra data fields: bất kỳ loại dữ liệu nào.

Đây là một cơ sở dữ liệu đơn giản theo cấu trúc khóa-giá trị:

Chức năng Chuyển trạng thái

Đây là một hàm chuyển trạng thái đơn giản. Khi hàm này nhận đầu vào từ người dùng, nó chỉ đơn giản nhân đôi nó lên 5 và sửa đổi dữ liệu trong cơ sở dữ liệu quan hệ.

Bộ tích lũy Trạng thái Thế giới

Chúng ta có thể xây dựng một bộ tích lũy băm đơn giản để biểu diễn trạng thái thế giới:

A_s+1 = băm(A_s + băm(truy vấn))

Phương pháp này đảm bảo rằng sau mọi sửa đổi vào cơ sở dữ liệu thế giới, luôn có một trạng thái duy nhất và xác định tương ứng với sự sửa đổi đó.

Chú ý rằng mọi hàm chuyển trạng thái phải thực hiện phương thức này. Yêu cầu này có thể được áp dụng bằng cách sử dụng bộ lọc, giao diện, hooks, hoặc các cơ chế cụ thể của ngôn ngữ khác. Do các đặc tính khác nhau của các ngôn ngữ lập trình, chúng tôi sẽ không đi sâu vào chi tiết cụ thể ở đây.

Quá trình cập nhật cho cơ sở dữ liệu khóa-giá trị (KVDB) tuân theo nguyên tắc tương tự.

Số Ngẫu Nhiên

Các hàm chuyển trạng thái không nên bao gồm số ngẫu nhiên, vì điều này sẽ gây ra kết quả khác nhau khi được xác minh bởi các người xác minh khác nhau, làm hỏng tính nhất quán. Số ngẫu nhiên nên được bao gồm là một phần của các tham số đầu vào của hệ thống.

Tóm tắt

Từ những ví dụ trên, chúng ta có thể thấy rằng Lớp Thực thi Omni của Tabi Chain cung cấp cho các nhà phát triển game sự linh hoạt đáng kể thông qua một cách tiếp cận theo kiểu mô-đun. Do hạn chế về không gian, chúng ta không thể thảo luận tất cả các chi tiết ở đây, nhưng những điểm cốt lõi được đề cập đủ để chứng minh rằng giải pháp của Tabi Chain không chỉ thực tế mà còn đầy sáng tạo.

Trong hệ sinh thái Web3 hiện tại, các công việc phát triển trên các chuỗi và máy ảo khác nhau thường thiếu tính di động. Đối với các trò chơi Web2 chuyển đổi sang Web3, đôi khi có nghĩa là viết lại trò chơi bằng các ngôn ngữ và môi trường không quen thuộc, đối mặt với nhiều hạn chế không thể hiểu được.

Với Tabi, các nhà phát triển có thể sử dụng ngôn ngữ, nền tảng phát triển và công cụ ban đầu của họ. Họ chỉ cần thực hiện những điều chỉnh và sửa đổi đơn giản, tương tự như việc gọi một SDK, để đưa dự án của họ vào thế giới blockchain. Điều này dẫn đến sự cải thiện mạnh về hiệu suất và giảm độ phức tạp.

Chúng tôi hy vọng rằng Tabi Chain có thể trở thành một tác nhân xúc tác cho việc triển khai rộng rãi của các trò chơi Web3, thu hút những nhà phát triển trò chơi Web2 tài năng và mang đến những trò chơi thực sự giải trí và có thể chơi được cho không gian Web3.

Thông báo:

1. Bài viết này được sao chép từ [Gate极客 Web3]. Tất cả bản quyền thuộc về tác giả gốc [罗奔奔]. Nếu có ý kiến ​​phản đối với việc tái bản này, vui lòng liên hệ với Gate Họcđội ngũ và họ sẽ xử lý nhanh chóng.
2. Bảo Miễn Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không tạo thành bất kỳ lời khuyên đầu tư nào.
3. Bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.