Job Execution

After the successful distribution of render jobs, all nodes know which render job they should execute and, therefore, each node can start to process its assigned render job. However, the render contract parties still need to come to consensus about who renders what tiles/frames/sample ranges in the render job they where assigned to. Again, the rendering process is separated into specific phases.

Rendering Phases

Topic Creation Phase

The render nodes assigned to the job will create a HCS topic for this specific job. This topic will assign the public key of the client node that submitted the job as the AdminKey and the public keys of all assigned render nodes and the client node as the SubmitKey (as a ThresholdList with a threshold value of 1, so that only these nodes can submit to the topic). The memo field of the topic contains the CID of the render request document. The topic is used by the nodes to exchange important messages about the job (e.g., errors occurring during the rendering, start and end times of the rendering process of each render node, etc.). This will also guarentee that nodes that deviate from the consensus will simply be ignored. If the topic is not created within a specific timeout time, the render nodes will discard the job for this hive cycle.

Benchmark Phase

Each render node obtains the Blender file from the IPFS. Then, each node renders the same portion of the scene that the client node rendered prior to submission of the render job, stores it on the IPFS, and sends a consensus message with the CID and the required render time to the HCS topic of the render job. The nodes estimate the total render work and compare the result with the render work stated in the render request document. If the values significantly deviate, the node sends a consensus message to the relevant HCS topics, and discards the job for this hive cycle.

Validation Phase

This phase is only executed, if the client node requested a prior validation and if there are at least two render nodes rendering for this render job. This validation step can be helpful in detecting errors in the rendering pipeline of single nodes prior to rendering the full job.

The render nodes download each other’s benchmark render result and locally use an image comparison algorithm to check whether all benchmark results are identical and only deviate by noise. If the result of at least one node deviates too strongly, each node sends a consensus message to the HCS topic of the render job, removes it from the local job queue, and discards the job.

Render Work Distribution Phase

If all checks are passed, the render nodes will distribute the render work based on the result of the benchmark phase and the render settings defined in the render request document. The latter defines, in what mode the rendering will be performed (i.e., tile-based, frame-based, or sample-based). The render work will be distributed in a way that minimizes the overall render time of the job. Each node knows the total range of tiles/frames/samples of the project and the total render power of the render nodes assigned to this render job.

Starting with the render node that has the highest share of the total render power, the total render range is split into subranges so that the total share in the render range equals the total share of the render nodes power. Again, the result is stored in a file on the IPFS – the render work agreement – and the node with the highest share in the render work submits a scheduled transaction with the CID of his local agreement in the memo field that needs to be signed by all parties of the render contract. If they come to consensus, a consensus message is sent to the HCS topic of the render job, and each node can start the rendering process. If no consensus is reached, i.e. no message arrives on the HCS topic within a given timeout period, each render node will send a message to the render job topic, remove the job from their local render queues, and start to look for new jobs.

Rendering Phase

If the render work was successfully distributed, the rendering starts. Each render node sends a consensus message to the render job topic to notify the network about the start of its local rendering process. The consensus time of the message represents a verifiable start time, which is later used to calculate the render time.

Finalization Phase

A render node which finished the rendering of its portion of the render job pins two versions of the render result(s) on the IPFS: (1) a watermarked version and (2) a non-watermarked version. The first one is for the client node user to review the result and the second one is the final result the user wants to have. The render node also pins a render result document describing what CID belongs to what frame/tile/sample range of the render job for both the watermarked and the non-watermarked version of the render result. It then sends a message to the render job topic notifying all participants about the end of its render job execution. It then, moves on to create the render invoice.

All versions of the render results are encrypted with the public key of the client node. So, only the client node will be able to use the render result files.