Node Types

Orchestration Node

Orchestration nodes are responsible for matching jobs from clients with the best available Resource nodes to support the service request. Additionally, Orchestration nodes monitor the jobs to ensure successful completion of jobs, reputation of Resource nodes based on their availability and completion success rate, and allocate rewards to the Resource nodes based on these factors.

An Orchestration node may play the role of Queueing jobs and matching them with the best Resource node. They may play the role of Validation of jobs not queued by themselves. They may also be configured to maintain Ledger Presistence.

Queueing

The Queueing function involves accepting job requests from game clients and matching that job with the best Resource node. An example of job a request might be a game session that has too few players to form a reliable consensus outcome. The ideal game sessions size is 4-64 players. In a scenario where fewer than 4 players are in a session, or the game developer wants to include a buffer to protect against falling below 4 players, the session may put in a request to the Orchestration network for additional Resource nodes to fill the Failover service role. These additional Resource nodes then join the game session, listen to all game actions broadcast by the active players, and participate in calculating the fair order of game actions. In this way, we leverage DePIN to add resilience to peer-to-peer game sessions.

Validation

Once a job has been assigned to a Resource node, periodic checkups are performed by the Validation role to ensure that the selected Resource nodes are indeed satisfying the job they've been assigned. Because Orchestration nodes are aware of all active game sessions, they know which sessions they've performed the Queueing function for, and which they have not. An Orchestrator will then randomly select a session they did not perform the Queueing function for and confirm that the Resource node is performing its assigned function.

Upon completion of the job a Resource node was selected for, the Orchestration node that is validating that job will propose the calculated reward for the owner of the Resource node and add its signature to the proposal. When enough Orchestrators have voted on the Resource node's successful completion of a job, the reward will be issued to the owner of Resource node candidate.

Ledger Presistence

Orchestration nodes may be configured to persist a subset of all transactions performed at the Orchestration layer. For example, an Orchestration node operated by an owner who has an interest in supporting a specific public network may choose to persist all Asset Bridge transactions related to that particular public network. Another Orchestration node may choose to persist all transactions for a specific game developer's games. This is how we optimize the storage and retrieval of persisted Orchestration data.

Resource Node

Resource nodes are at the heart of Tashi's DePIN strategy. These nodes fulfill the core multiplayer game functions traditionally offered by cloud infrastructure platforms. We've moved a number of those functions from the cloud into the DePIN layer, using clusters of underutilized consumer and enterprise machines to satisfy the game service needs of developers and publishers.

The core services that support Dynamite game sessions are Proxy, Failover, Matchmaking, and Lobby. These services ensure that Dynamite peer-to-peer sessions operate reliably and efficiently.

Other services like Asset Bridge and Wallet MPC connect the world of public networks with Tashi's ephemeral side-chain technology for fully on-DAG gaming (FODG), ensuring that players maintain the frictionless experience of gaming while enjoying the benefits of Web3 ecosystems.

---

Node roles and services may change as demand is validated and optimized.