Job Queue

The job queue is essentially a list of all render requests that have not been executed yet. This list is stored in a HCS topic – the Job Queue Topic – and new jobs can be submitted to the queue at any time. All render nodes are subscribed to this topic so that they get automatically notified about new jobs.

Submission

The client node calculates the cost of its render job in USD and sends hbars worth of that amount of USD to the Renderhive Smart Contract. The smart contract will lock these hbars until the render job is finished, rejected due to errors, or cancelled by the user. This way, render nodes have a guarantee that the client node can pay for the render results prior to starting the rendering process. This mechanism will also prevent malicious clients from submitting an arbitrary amount of render jobs to the render hive in order to spam the network.

The client node will also store the transaction hash in the render request document prior to submitting the transaction to the smart contract for validation purposes by the render nodes Finally, the client node sends the CID of the render request document to the job queue topic which represents the official submission of the render request to the render hive. Since render nodes are subscribed to this topic, they will automattically be notified about the new jobs and download the render request document to extract the information.

Job Order

Render jobs are processed in the order they are submitted to the job queue. Since the job queue is a HCS topic, the consensus mechanism of Hedera ensures the fair, immutable, and verifiable ordering of all job submissions. However, render nodes will only evaluate and process those render jobs in the queue that match with their own price targets, terms of service, and specifications defined in their render offer document. This provides client nodes a fair way to influence how fast their render job is processed by the network based on the price they are willing to pay (see Render Costs & Payments). On the other hand, it ensures that render requests with similar pricing are processed in the order they are submitted to the network. Consequently, jobs are processed under free market conditions but still in a fair order.

At a later point, the Renderhive project may also implement a possibility to directly rent specific render nodes for a fixed time as an additional way to render time-sensitive projects immediately on a single node.