# Rendering verification problem

A user submits some graphics work to a *manager*, this work consists of several scenes; each contains information about graphical objects, the camera, light sources and materials. The photorealistic rendering consists of sophisticated computation processes that calculate light properties at surfaces of all visible objects, resulting in 3D rendered images of the scene [\[1\]](/inferix-whitepaper/references.md#1).

One of the most important problems that Inferix has to solve is to verify the *authenticity* of rendered results [\[2\]](/inferix-whitepaper/references.md#2),[\[3\]](/inferix-whitepaper/references.md#3), [\[4\]](/inferix-whitepaper/references.md#4). That means how to ensure that once a user submits a valid scene, then after waiting for an amount of time, the user will receive authentically rendered images. The authenticity can be defined informally as if the result received from the rendering network and the result received when the scene is genuinely rendered by a rendering software are human perceptually indistinguishable.

The *workers* who join the rendering network are mostly workstations of GPU owners who want to make profit from their unused computational resources. Respecting the privacy of GPU owners and their resources, besides lightweight open-source software installed to manage the communication with the network, there is completely no control on *workers*.

Consequently, there is no constraint to oblige *workers* to render the graphics scene correctly. Indeed, a malicious *worker* may receive a rendering task, but does nothing then uses some forged images as results. Without rendering the scene, the *managers* and users know only superficial features of what the rendered images look like. Obviously, the *managers* and users have no interest in rendering the scene themselves since if they can do that, there is no need to rely on *workers*. Moreover, we cannot deploy any surveillance mechanism on the machines of *workers* due to privacy reasons. Even if we try to do that, this is only a matter of time before a *worker* reverse engineers the mechanism and eventually bypasses it. The situation doesn't seem to favor us: checking the authenticity of something while only having a little knowledge about it, otherwise the attacker has complete information.

Naturally, a public-key cryptography approach is using a scheme of *fully homomorphic encryption* (FHE) [\[5\]](/inferix-whitepaper/references.md#5). The scene is encrypted first by a private key before sending it to *workers*. Given the corresponding public key, the homomorphic encryption software performs the graphics rendering on the encrypted scene without needing to decrypt it. Finally, the encrypted rendered results are returned and decrypted at the user's side using the private key. The advantage of FHE is that the *workers*, even being able to modify the FHE software on their side, cannot interfere with the FHE rendering processes or forge the rendering results without being detected. Unfortunately, this approach is impractical since all state-of-the-art implementations will make the performance of the homomorphic encryption rendering become unacceptable [\[6\]](/inferix-whitepaper/references.md#6).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.inferix.io/inferix-whitepaper/introduction/rendering-verification-problem.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.