Online game state synchronization system and method based on block chain asynchronous network service

Abstract

The invention provides an online game state synchronization system and method based on block chain asynchronous network service, and the system comprises the following components: a client which is constructed by adopting a Unity game engine and is responsible for the rendering of a game scene, the user interaction and the visual presentation of a local state; the network service layer adopts a Node.js running environment, integrates an Express framework and an ethers.js library, serves as a security agent intermediary between a client and a block chain network, and is responsible for transaction signature construction, transaction broadcast transmission, data format conversion and provision of a standardized RESTful application programming interface; the intelligent contract is compiled by adopting a Solidiity language, is deployed in an Ethereum test network or a main network, and is used as a unique authoritative storage and logic execution carrier of an on-chain state; according to the system, the influence of block chain confirmation delay on player experience can be effectively relieved, the traceability and non-tampering performance of data are guaranteed, and the system is suitable for asynchronous cooperation type multi-player online game scenes.

Description

Technical Field

[0001] This invention relates to the field of blockchain and game integration technology, and in particular to a method and system for synchronizing the state of online games based on blockchain asynchronous network services. Background Technology

[0002] Traditional online games typically rely on centralized servers to maintain the world state and player interaction logic, which presents several problems: single point of failure for servers, vulnerability to data tampering, and centralized control of the player world by the operator. With the development of public blockchains and smart contract technologies, blockchain has made decentralized data storage and verifiable interaction possible. However, directly migrating real-time interactive games to the blockchain faces inherent difficulties: on-chain transaction confirmation delays, transaction costs (gas), and on-chain storage overhead. Therefore, how to retain the "trustworthy, immutable, and auditable" characteristics of blockchain while meeting the game's needs for interactivity and user experience is an urgent engineering problem that needs to be solved.

[0003] Existing technologies in some blockchain games use centralized servers to cache on-chain data or transfer a large amount of logic to off-chain processing, but they often lack full support for the "asynchronous shared world" scenario and lack systematic solutions for duplicate transactions, asynchronous refreshes, and client consistency guarantees. Summary of the Invention

[0004] The purpose of this invention is to propose an online game state synchronization system and method based on blockchain asynchronous network services. Under the premise of ensuring the authority of on-chain data, it can realize high availability interaction of the client, one-time transaction writing and reliable periodic / event-triggered refresh strategy, thereby improving the impact of on-chain latency on player experience and improving system fault resistance.

[0005] To achieve the above objectives, this invention proposes an online game state synchronization system based on blockchain asynchronous network services, characterized by comprising the following components:

[0006] The client, built using the Unity game engine, is responsible for rendering game scenes, user interaction, and visualizing local states.

[0007] The network service layer uses the Node.js runtime environment and integrates the Express framework and ethers.js library. It acts as a secure proxy intermediary between the client and the blockchain network, responsible for transaction signature construction, transaction broadcasting, data format conversion, and providing standardized RESTful application programming interfaces.

[0008] Smart contracts, written in Solidity and deployed on the Ethereum test network or main network, serve as the sole authoritative store of on-chain state and the carrier of logic execution.

[0009] The client communicates indirectly with the blockchain network by calling the RESTful interface of the network service layer; the network service layer interacts with the smart contract through the Ethereum remote procedure call protocol and listens to the event logs issued by the smart contract; the smart contract defines a lightweight data structure for the game world state and state change functions.

[0010] Furthermore, the data structures defined in the smart contract include the Item structure and the Message structure. The Item structure contains the following fields: id (data type uint256), used to uniquely identify the item instance in the game world; x (data type int256), representing the horizontal coordinate of the item in the game world coordinate system; y (data type int256), representing the vertical coordinate of the item in the game world coordinate system; itemType (data type string), used to describe the type attribute of the item; exists (data type bool), used to indicate whether the item currently exists in the game world. The Message structure contains the following fields: id (data type uint256), used to uniquely identify the message instance; x (data type int256), representing the horizontal coordinate of the message's anchor position; y (data type int256), representing the vertical coordinate of the message's anchor position; content (data type string), used to store the text content of the message; exists (data type bool), used to indicate whether the message is currently valid.

[0011] Furthermore, the smart contract exposes state change functions including the `placeItem` function, the `removeItem` function, and the `leaveMessage` function. The `placeItem` function takes parameters x, y, and itemType, and its execution logic includes: generating a new unique ID, creating or updating the corresponding Item structure instance in the Item mapping, setting its exists field to true, and triggering the ItemPlaced event. The `removeItem` function takes the parameter ID, and its execution logic includes: verifying that the Item with the corresponding ID exists and its exists is true, then setting its exists field to false, and triggering the ItemRemoved event. The `leaveMessage` function takes parameters x, y, and content, and its execution logic includes: generating a new unique ID, creating the corresponding Message structure instance in the Message mapping, setting its exists field to true, and triggering the MessageLeft event. The smart contract also provides state query functions `getAllItems` and `getAllMessages`, which return arrays of all Item and Message structures whose exists are currently true, respectively.

[0012] Furthermore, the three types of synchronization triggering strategies implemented by the network service layer are as follows:

[0013] The activation trigger strategy initiates requests to the / items and / messages interfaces of the network service layer during the client application startup initialization phase. The network service layer calls the getAllItems and getAllMessages functions of the smart contract to obtain the full on-chain state data and return it to the client, thus completing the synchronization of the client's initial state.

[0014] The event triggering strategy involves the network service layer continuously listening to the ItemPlaced, ItemRemoved, and MessageLeft events emitted by the smart contract through the ethers.js library. When any event is detected, the layer proactively notifies the connected client through a server push mechanism or a client polling mechanism, triggering the client to perform incremental or full state refresh operations.

[0015] The periodic triggering strategy involves configuring a parameterizable time interval T (in seconds) on the client or network server. At this interval T, a full data pull request is periodically initiated to the chain to ensure that the client state can achieve eventual consistency with the authoritative state on the chain in the event of network partitioning or event loss.

[0016] Furthermore, the network service layer implements a cross-language data serialization strategy in the data processing flow. Addressing potential precision loss or format incompatibility issues during JSON serialization between the uint256 type in Solidity and the BigInt type in JavaScript, the network service layer performs data type conversion before returning the on-chain query results to the client, explicitly converting all uint256 / BigInt numeric types to string types for transmission. Upon receiving response data containing numeric strings, the client, based on its programming language environment, calls the appropriate parsing function: in C#, using int.Parse() or long.Parse(); and in JavaScript / TypeScript, using the BigInt constructor, to restore the string to a locally operable numeric type.

[0017] This invention also proposes a method for synchronizing the state of online games based on blockchain asynchronous network services, comprising the following steps:

[0018] Step S110: Construct and initialize the three-tier architecture as claimed in the preceding system claims to ensure unimpeded communication links between the client, the network service layer, and the smart contract;

[0019] In step S120, the client executes startup trigger synchronization during the startup phase. By calling the full data interface provided by the network service layer, it obtains all currently valid Item and Message data in the smart contract and initializes the local game world state accordingly.

[0020] In step S130, the network service layer continuously listens to the event logs issued by the smart contract. When it captures an event that represents a state change, it performs event-triggered synchronization and actively notifies the client to update the state.

[0021] In step S140, the client or network server periodically executes periodic trigger synchronization according to the preset period parameter T, and initiates a full data query to the smart contract to ensure the eventual consistency between the client's local state and the on-chain state.

[0022] In step S150, when the client is processing a write operation request initiated by the user, it performs local throttling control, sets the isSending status flag to true and disables related interactive controls during the request sending period to prevent the same transaction from being submitted multiple times due to network latency or repeated clicks by the user.

[0023] In step S160, while waiting for on-chain transaction confirmation, the client may selectively enable a visual optimization strategy, that is, immediately render the expected state change effect corresponding to the operation on the local interface. If the subsequent on-chain confirmation fails, a state rollback operation is performed to cancel the local preview effect.

[0024] In step S170, when processing all responses involving numerical data, the network service layer performs cross-language serialization conversion, uniformly converting the BigInt / uint256 values ​​returned by Solidity into string format. After receiving the data, the client performs reverse parsing to ensure the correct interpretation and rendering of the data in different programming language environments.

[0025] Furthermore, the local throttling control mechanism in step S150 strictly binds the setting and clearing logic of the isSending flag to the lifecycle of the asynchronous network request. When a client initiates a write operation network request, isSending is immediately set to true, and button elements in the user interface that may trigger similar operations are simultaneously disabled. Only after receiving an explicit response from the network service layer, regardless of whether the response represents success or failure, isSending is reset to false, and the interactive state of the relevant controls is restored. This mechanism ensures that at any given time, for the same logical operation, at most one pending request is in the transmission state, effectively avoiding the blockchain node returning an "already known" error due to receiving duplicate transactions with the same transaction hash or Nonce conflict.

[0026] Furthermore, the visual optimization strategy in step S160 relies on local state pre-change data for its optimistic update operation, which strictly adheres to the business rules defined in the smart contract in terms of data structure and rendering logic. When the client simulates a state change locally, it generates a temporary local data object with a specific identifier. This object has the same visual appearance as the on-chain confirmed data in the rendering layer, but is isolated from the confirmed authoritative data in internal state management. When the on-chain transaction is successfully confirmed, the temporary object is replaced with the official data synchronized from the on-chain. When the on-chain transaction confirmation fails or times out, the temporary object and all its visual effects are immediately removed from the client's state tree and rendering scene.

[0027] Furthermore, when rendering the itemType field, the client performs data cleaning preprocessing. To address any extra quotes or escape characters that different serialization tools may add when processing string types, the client calls a string trimming function, such as the Trim('"') method in C#, before using the itemType string for logical judgment or rendering display. This removes any extra quote characters that may exist at the beginning or end of the string, ensuring the purity of the string content and the consistency of the display.

[0028] Compared with the prior art, the advantages of the present invention are:

[0029] 1. By constructing a three-layer decoupled architecture of client-network service layer-smart contract, and integrating three synchronization triggering strategies of startup, event, and period, efficient synchronization and eventual consistency of client state are achieved while ensuring that on-chain data is the only tamper-proof and authoritative source, significantly improving the data reliability of decentralized game systems.

[0030] 2. The client-side implementation of local throttling control and optional visually optimistic update strategy effectively isolates the direct impact of blockchain network confirmation delays on user operation smoothness, and significantly reduces the negative experience caused by user-perceived operation lag or state rollback.

[0031] 3. As a general proxy layer, the network service layer manages blockchain network parameters and security credentials through configuration and enables automatic conversion of cross-language data formats, greatly enhancing the system's scalability and cross-platform portability.

[0032] 4. The systematic duplicate transaction submission interception mechanism fundamentally avoids "already known" node rejection errors caused by network fluctuations or user misoperation, thereby improving the overall system's operational stability and anti-interference capability. Attached Figure Description

[0033] Figure 1This is a system architecture diagram (client) of an online game state synchronization system based on blockchain asynchronous network service in an embodiment of the present invention. Network service layer (Public blockchain contract).

[0034] Figure 2 Data flow diagram: Client initiates placement — Service layer signature sent — On-chain event — Client refresh.

[0035] Figure 3 The flowchart for "throttling and retrying" in this invention is a pseudo-state machine. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be further described below.

[0037] See Figure 1 As shown, this system adopts a three-layer decoupled architecture consisting of a client, a network service layer, and a smart contract to achieve authoritative synchronization of game states.

[0038] The client-side is built on the Unity game engine and is responsible for real-time rendering of game scenes, capturing user input, and visualizing local state. The network service layer runs in a Node.js environment, integrating the Express framework and the ethers.js library, acting as a secure proxy intermediary to handle core functions such as transaction signature construction, transaction broadcasting, and data format conversion. Smart contracts are written in Solidity and deployed on the Ethereum network, serving as the sole authoritative store of on-chain state and the carrier of logic execution.

[0039] During client initialization, a startup-triggered synchronization strategy is executed. This involves initiating full data requests to the ` / items` and ` / messages` interfaces by calling the standardized RESTful application programming interface exposed by the network service layer. Upon receiving the requests, the network service layer invokes the `getAllItems` and `getAllMessages` functions of the smart contract via the Ethereum remote procedure call protocol. The smart contract executes the state query logic, iterating through all data instances in the `Item` and `Message` mappings where the `exists` field is true, and returning the complete state data of the current game world. The network service layer performs cross-language data serialization on the query results, uniformly converting the uint256 type values ​​returned by Solidity into string format to ensure no precision loss during JSON serialization. After receiving the response data, the client calls the `int.Parse` method in the C# environment to restore the numeric string to a locally operable type, completing the initial construction and rendering of the game world.

[0040] The network service layer establishes a persistent connection with Ethereum nodes through the ethers.js library, continuously listening for ItemPlaced, ItemRemoved, and MessageLeft events emitted by the smart contract. When a player performs an item placement operation on the client, the client first executes a local throttling mechanism, setting the isSending status flag to true and disabling related interactive controls to prevent duplicate transaction submissions due to network latency. The client constructs an operation request containing the target coordinates x and y and the item type itemType, and sends it to the corresponding interface of the network service layer via HTTP POST. After verifying the integrity of the request format, the network service layer constructs a transaction object using the ethers.js library, including setting the correct gas limit and the current network suggested gas price, digitally signing the transaction using a securely stored private key, and finally broadcasting the signed transaction to the peer-to-peer network through Ethereum nodes.

[0041] After receiving a transaction, the smart contract executes the `placeItem` function logic: First, it generates a unique ID based on the current block timestamp and a random number. Then, it creates a corresponding `Item` struct instance in the `Item` mapping, setting the x-coordinate to the passed-in horizontal coordinate parameter, the y-coordinate to the passed-in vertical coordinate parameter, the `itemType` field to store the item type string, and the `exists` field to `true` to indicate that the item exists in the game world. Upon successful function execution, the `ItemPlaced` event is triggered, and the event log contains the complete attribute data of the newly generated item. The event listener in the network service layer captures this event and immediately sends a state change notification to all connected clients via the server push mechanism. Upon receiving the notification, the client performs an incremental state update based on the event type, rendering the newly placed item model in the local game scene.

[0042] When a player performs an item removal operation, the client sends a removal request containing the target item's ID to the network service layer. The network service layer constructs a transaction that calls the `removeItem` function and broadcasts it to the blockchain network. When the smart contract executes the `removeItem` function, it first verifies that the `Item` struct instance corresponding to the passed-in ID exists and that the `exists` field is true. Then, it modifies this field to false to indicate that the item has been removed from the game world, and simultaneously triggers the `ItemRemoved` event. The network service layer listens for this event and notifies the client to update its local state. The client then removes the corresponding model from the rendering scene based on the item ID in the event.

[0043] When a player leaves a message, the client constructs a request containing coordinates x and y and the text content (content) and sends it to the network service layer. The network service layer calls the `leaveMessage` function of the smart contract. The smart contract generates a unique ID and creates a `Message` structure instance in the `Message` mapping. The x-coordinate is set as the anchor position's horizontal coordinate, the y-coordinate as the anchor position's vertical coordinate, the `content` field stores the message's text content, and the `exists` field is set to `true` to indicate that the message is valid. Finally, the `MessageLeft` event is triggered. Upon receiving the event notification, the client renders a message marker at the specified coordinates, and the player can view the complete message content interactively.

[0044] The system is configured with a periodic synchronization strategy, setting the time interval parameter T to 300 seconds. The client or network server periodically sends full data query requests to the smart contract at this interval. The network service layer calls the `getAllItems` and `getAllMessages` functions to retrieve all current valid state data and compares it with the locally cached state. When a state inconsistency is detected, the client is forced to perform a full state refresh, ensuring that in the event of network partitions or event loss, the client's state achieves eventual consistency with the on-chain authoritative state. During the periodic synchronization process, the network service layer executes a complete data verification process, including checking the integrity of the data structure, the validity of numerical ranges, and the compliance of logical constraints.

[0045] When processing user write operations, the client implements a visual optimization strategy. While waiting for on-chain transaction confirmation, it immediately renders the expected state change effect corresponding to the operation on the local interface. The client generates a temporary local data object, which has the same visual appearance as the confirmed on-chain data at the rendering layer, but is isolated from the confirmed authoritative data in internal state management. After the on-chain transaction is successfully confirmed after 6 blocks, the client replaces the temporary object with the official data synchronized from the on-chain. If the transaction confirmation fails or times out, the temporary object and all its visual effects are immediately removed from the client's state tree and rendering scene, and a state rollback operation is performed.

[0046] The network service layer implements a comprehensive error handling mechanism throughout the data processing flow. When a transaction fails due to insufficient gas, network congestion, or contract execution errors, it immediately returns a response to the client containing specific error codes and descriptions. The client executes appropriate recovery strategies based on the error type, automatically retrying operations for temporary errors and prompting the user to check operation parameters for permanent errors. The network service layer also maintains a transaction status monitoring system, tracking the confirmation status of each transaction and proactively querying nodes to obtain the latest status when a transaction remains unconfirmed for an extended period.

[0047] When rendering the `itemType` field, the client performs data cleaning preprocessing. For extra quotation marks or escape characters that may be added by different serialization tools, a string trimming function is called to remove any redundant quotation marks at the beginning and end before using the `itemType` string for logical judgments or rendering. The cleaning process includes steps such as detecting string boundary characters, removing unnecessary escape sequences, and verifying the string encoding format to ensure the purity of the string content and consistency in display. The cleaned string is then directly used for resource loading path construction and material property settings, ensuring correct loading and rendering of game resources.

[0048] The system implements a complete performance monitoring and optimization mechanism. The network service layer records the processing time of each request, blockchain interaction latency, and memory usage, automatically triggering alarms when abnormal performance metrics are detected. The client monitors frame rate, memory usage, and network latency, dynamically adjusting rendering quality and update frequency when resources are scarce. Smart contracts implement gas optimization strategies, reducing transaction execution costs by using fixed-size arrays, reducing storage operations, and optimizing algorithm complexity.

[0049] To facilitate understanding by those skilled in the art, the modules and algorithms of this invention are represented as follows:

[0050] The smart contract GameWorld.sol (Solidity) is deployed on the Ethereum Sepolia testnet and includes:

[0051] ●struct Item{uint256 id;intx;inty;string itemType;bool exists;}

[0052] ●functionplaceItem(intx,int y,string memory itemType)public

[0053] ●event ItemPlaced(uint256 id,int x,int y,string itemType);

[0054] ·function getAllItems()public view returns(Item[]memory)

[0055] Network service layer index.js (Node.js):

[0056] • Running `app.use(express.json())` will REST the routes ` / place`, ` / remove`, ` / message`, and ` / items`.

[0057] / messages.

[0058] ● ethers is used to sign and send transactions. It calls await tx.wait() and, upon success, res.send({status:"ok",txHash:tx.hash}).

[0059] Unity client:

[0060] ● Upon startup, a GET request is made to http: / / localhost:3000 / items and / messages. The array is then parsed using JsonHelper and written to the local WorldDatabase (singleton).

[0061] The WorldRenderer reads the WorldDatabase and instantiates the corresponding prefab.

[0062] Asynchronous refresh and throttling algorithms

[0063] Define variables:

[0064] • T: Periodic fetch interval (seconds), recommended default T=300 (5 minutes), configurable;

[0065] • lastUpdateTime: The timestamp of the last successful refresh (Unix seconds);

[0066] ●isSending: Boolean, indicating whether an on-chain write request is currently being sent;

[0067] ●retryDelay: Initial backoff time (in seconds) for retrying on failure;

[0068] ●maxRetry: Maximum number of retries.

[0069] Refresh Trigger Strategy (Pseudocode)

[0070]

[0071]

[0072] Write request (Place / Remove / Message) throttling and retries (pseudocode) Figure 3 As shown

[0073]

[0074]

[0075] Algorithm formula (retreat and refresh rhythm)

[0076] 1. Exponential backsliding: Waiting time for the k-th retry

[0077] delay k =min(delay0·2) k-1 delay max )

[0078] Where delay0 is the initial backoff (e.g., 2s), delay max The upper limit is (e.g., 120s).

[0079] 2. Window Refresh and Perceived Latency Model: Define the client's perceived latency L as approximately...

[0080]

[0081] In the formula, T is the periodic pull interval, and D is... chain The average on-chain transaction confirmation latency (in seconds) is given. This formula indicates that under a periodic triggering strategy, the average client waiting time is approximately half a cycle plus the on-chain confirmation latency. Shortening L can reduce T or optimize D. chain (For example, using Layer2, accelerator).

[0082] Duplicate transaction removal strategy

[0083] Perform fingerprint calculations on local transactions before sending them:

[0084] fingerprint=H(opType∥x∥y∥itemType∥timestamp trunc )

[0085] Where H is the hash function (e.g., SHA256), and timestamp_trunc indicates that the time is truncated to the minute level to reduce duplicate requests within a short period. The server or client can cache the most recent N fingerprints. If a new operation fingerprint overlaps with the cached fingerprint and is within the window period, the request is rejected or the user is prompted.

[0086] Data compatibility and serialization strategy

[0087] The server uses `.toString()` to convert the uint256 returned from the blockchain to a string; the returned value is JSON.

[0088] In the form of:

[0089] [{"id":"3","x":"-10","y":"5","itemType":"\"stone_1\"","exists":true}]

[0090] • The client performs string cleaning during reading:

[0091] string type=item.itemType.Replace("\"","");

[0092] int id=int.Parse(item.id);

[0093] The above are merely preferred embodiments of the present invention and do not constitute any limitation on the present invention. Any equivalent substitutions or modifications made by those skilled in the art to the technical solutions and content disclosed in the present invention without departing from the scope of the present invention shall be deemed to have remained within the protection scope of the present invention.

Claims

1. A system for synchronizing the state of online games based on blockchain asynchronous network services, characterized in that, It includes the following components: The client, built using the Unity game engine, is responsible for rendering game scenes, user interaction, and visualizing local states. The network service layer uses the Node.js runtime environment and integrates the Express framework and ethers.js library. It acts as a secure proxy intermediary between the client and the blockchain network, responsible for transaction signature construction, transaction broadcasting, data format conversion, and providing standardized RESTful application programming interfaces. Smart contracts, written in Solidity and deployed on the Ethereum test network or main network, serve as the sole authoritative store of on-chain state and the carrier of logic execution. The client communicates indirectly with the blockchain network by calling the RESTful interface of the network service layer; the network service layer interacts with the smart contract through the Ethereum remote procedure call protocol and listens to the event logs issued by the smart contract; the smart contract defines a lightweight data structure for the game world state and state change functions.

2. The online game state synchronization system based on blockchain asynchronous network service according to claim 1, characterized in that, The data structures defined in the smart contract include an Item structure and a Message structure. The Item structure contains the following fields: id (uint256 data type), used to uniquely identify an item instance in the game world; x (int256 data type), representing the horizontal coordinate of the item in the game world coordinate system; y (int256 data type), representing the vertical coordinate of the item in the game world coordinate system; itemType (string data type), used to describe the item's type attribute; and exists (bool data type), used to indicate whether the item currently exists in the game world. The Message structure contains the following fields: id (uint256 data type), used to uniquely identify a message instance; x (int256 data type), representing the horizontal coordinate of the message's anchor position; y (int256 data type), representing the vertical coordinate of the message's anchor position; content (string data type), used to store the text content of the message; and exists (bool data type), used to indicate whether the message is currently valid.

3. The online game state synchronization system based on blockchain asynchronous network service according to claim 1, characterized in that, The smart contract exposes three state change functions: `placeItem`, `removeItem`, and `leaveMessage`. The `placeItem` function receives parameters `x`, `y`, and `itemType`, and its execution logic includes: generating a new unique ID, creating or updating an `Item` structure instance with the corresponding ID in the `Item` mapping, setting its `exists` field to `true`, and triggering the `ItemPlaced` event. The `removeItem` function receives the parameter `id`, and its execution logic includes: verifying that the `Item` with the corresponding ID exists and its `exists` is `true`, then setting its `exists` field to `false`, and triggering the `ItemRemoved` event. The `leaveMessage` function receives parameters `x`, `y`, and `content`, and its execution logic includes: generating a new unique ID, creating a `Message` structure instance with the corresponding ID in the `Message` mapping, setting its `exists` field to `true`, and triggering the `MessageLeft` event. The smart contract also provides state query functions `getAllItems` and `getAllMessages`, which return arrays of all `Item` and `Message` structures with `exists` currently set to `true`, respectively.

4. The online game state synchronization system based on blockchain asynchronous network service according to claim 1, characterized in that, The three types of synchronization triggering strategies implemented by the network service layer are as follows: The activation trigger strategy initiates requests to the / items and / messages interfaces of the network service layer during the client application startup initialization phase. The network service layer calls the getAllItems and getAllMessages functions of the smart contract to obtain the full on-chain state data and return it to the client, thus completing the synchronization of the client's initial state. The event triggering strategy involves the network service layer continuously listening to the ItemPlaced, ItemRemoved, and MessageLeft events emitted by the smart contract through the ethers.js library. When any event is detected, the layer proactively notifies the connected client through a server push mechanism or a client polling mechanism, triggering the client to perform incremental or full state refresh operations. The periodic triggering strategy involves configuring a parameterizable time interval T (in seconds) on the client or network server. At this interval T, a full data pull request is periodically initiated to the chain to ensure that the client state can achieve eventual consistency with the authoritative state on the chain in the event of network partitioning or event loss.

5. The online game state synchronization system based on blockchain asynchronous network service according to claim 1, characterized in that, The network service layer implements a cross-language data serialization strategy in the data processing flow. To address potential precision loss or format incompatibility issues during JSON serialization between the uint256 type in Solidity and the BigInt type in JavaScript, the network service layer performs data type conversion before returning the on-chain query results to the client, explicitly converting all uint256 / BigInt numeric types to string types for transmission. Upon receiving response data containing numeric strings, the client, based on its programming language environment, calls the appropriate parsing function: in C#, it uses int.Parse() or long.Parse(); in JavaScript / TypeScript, it uses the BigInt constructor to restore the string to a locally operable numeric type.

6. A method for synchronizing the state of online games based on blockchain asynchronous network services, using the online game state synchronization system based on blockchain asynchronous network services as described in any one of claims 1-5; characterized in that, Includes the following steps: Step S110: Construct and initialize the three-tier architecture as described in the preceding system claims to ensure unimpeded communication links between the client, the network service layer, and the smart contract; In step S120, the client executes startup trigger synchronization during the startup phase. By calling the full data interface provided by the network service layer, it obtains all currently valid Item and Message data in the smart contract and initializes the local game world state accordingly. In step S130, the network service layer continuously listens to the event logs issued by the smart contract. When it captures an event that represents a state change, it performs event-triggered synchronization and actively notifies the client to update the state. In step S140, the client or network server periodically executes periodic trigger synchronization according to the preset period parameter T, and initiates a full data query to the smart contract to ensure the eventual consistency between the client's local state and the on-chain state. In step S150, when the client is processing a write operation request initiated by the user, it performs local throttling control, sets the isSending status flag to true and disables related interactive controls during the request sending period to prevent the same transaction from being submitted multiple times due to network latency or repeated clicks by the user. In step S160, while waiting for on-chain transaction confirmation, the client may selectively enable a visual optimization strategy, that is, immediately render the expected state change effect corresponding to the operation on the local interface. If the subsequent on-chain confirmation fails, a state rollback operation is performed to cancel the local preview effect. In step S170, when processing all responses involving numerical data, the network service layer performs cross-language serialization conversion, uniformly converting the BigInt / uint256 values ​​returned by Solidity into string format. After receiving the data, the client performs reverse parsing to ensure the correct interpretation and rendering of the data in different programming language environments.

7. The online game state synchronization method based on blockchain asynchronous network service according to claim 6; characterized in that, The local throttling control mechanism in step S150 has its isSending flag setting and clearing logic strictly bound to the lifecycle of the asynchronous network request. When the client initiates a write operation network request, isSending is immediately set to true, and button elements in the user interface that may trigger similar operations are simultaneously disabled. Only after receiving an explicit response from the network service layer, regardless of whether the response represents success or failure, isSending is reset to false, and the interactive state of the relevant controls is restored. This mechanism ensures that at any given time, for the same logical operation, there is at most one pending request in the transmission state, effectively avoiding the blockchain node returning an "already known" error due to receiving duplicate transactions with the same transaction hash or nonce conflict.

8. The online game state synchronization method based on blockchain asynchronous network service according to claim 6; characterized in that, The visual optimization strategy in step S160 relies on local state pre-change data for its optimistic update operation, which strictly follows the business rules defined in the smart contract in terms of data structure and rendering logic. When the client simulates a state change locally, it generates a temporary local data object with a specific identifier. This object has the same visual appearance as the on-chain confirmed data in the rendering layer, but is isolated from the confirmed authoritative data in internal state management. When the on-chain transaction is successfully confirmed, the temporary object is replaced with the official data synchronized from the on-chain. When the on-chain transaction confirmation fails or times out, the temporary object and all its visual effects are immediately removed from the client's state tree and rendering scene.

9. The online game state synchronization method based on blockchain asynchronous network service according to claim 6; characterized in that, When rendering the itemType field, the client performs data cleaning preprocessing. To address the extra quotation marks or escape characters that different serialization tools may add when processing string types, the client calls a string trimming function, such as the Trim('"') method in C#, before using the itemType string for logical judgment or rendering display. This removes any extra quotation marks that may exist at the beginning or end of the string, ensuring the purity of the string content and the consistency of the display.

Images