Synchronization

In an ideal scenario, the on-chain game account would be perfectly synchronized with the actual game progress. However, in reality, blockchain transactions take time to finalize, and delays can occur. Additionally, new players can join the game in real-time, further complicating synchronization between the on-chain state and the real-time game state.

To address these challenges, Race Protocol employs two key version numbers and a sophisticated event-driven architecture to ensure consistent and reliable synchronization between the on-chain accounts, the Transactor, and other nodes (validator servers and clients).

Access Version

The access_version is a serial number stored in the game account that tracks the order in which players and servers join the game. Every time a new player or server joins, the access_version is incremented by 1, and the joining entity records this version as its own access_version.

This mechanism is crucial for ensuring consistent game state initialization across different nodes. When a node initializes, it uses the access_version to filter out players and servers who joined after the last recorded state. This ensures that all nodes start with the same set of participants and prevents inconsistencies in the game state.

Settle Version

The settle_version is another serial number stored in the game account that tracks the number of settlements that have occurred in the game. Each time a game concludes and a settlement transaction is processed, the settle_version is incremented by 1.

This version number serves as a reference point for synchronizing player assets and game state. Events and deposits are tagged with the corresponding settle_version, allowing nodes to track the history of actions and updates. By starting with the current on-chain account state and applying events and deposits in order of their settle_version, all nodes can independently arrive at the same game state.

Event-driven Synchronization

Race Protocol relies on an event-driven architecture to propagate updates and synchronize game state across different components. The Transactor plays a central role in this process by:

• Broadcasting Events: When an event occurs in the game, such as a player action or a change in game state, the Transactor broadcasts the event to all connected participants. This ensures that everyone has the same information about the game's progress.

• Handling Settlements: When a game concludes, the Transactor collects all relevant information, including player balances, game outcomes, and any pending deposits, and creates a settlement transaction. This transaction is submitted to the blockchain, updating the game account with the final state and distributing assets accordingly.

Validator servers and clients subscribe to the event stream broadcasted by the Transactor. This allows them to:

• Update their local game state: Upon receiving an event, each node updates its local copy of the game state, ensuring consistency with the Transactor's state.

• Respond with Actions: In some cases, nodes may need to respond to events with specific actions. For example, when a new randomness is generated, validator servers participate in the P2P shuffling process, and clients may need to decrypt revealed information using shared secrets.

This event-driven approach, combined with the use of access and settle versions, ensures that all nodes maintain a consistent and synchronized view of the game state, even in the face of network delays and asynchronous updates.

By implementing these mechanisms, Race Protocol achieves reliable synchronization and guarantees that all participants have a shared understanding of the game's progress and outcome, fostering trust and fair play in the web3 gaming environment.