Hedera Services

Hedera Consensus Service (HCS)

The HCS offers the possibility to create so-called consensus topics over which messages can be exchanged between network participants in a verifiable way. Due to Hederas consensus mechanism, each message has a unique timestamp, which enables a fair, temper-proof ordering of events. Renderhive will use at least the following HCS topics (whose usage is detailed later in this document):

• Job queue topic. The render job queue gathers all incoming render jobs that are submitted to the network. The fair ordering of events by the Hashgraph algorithm guarentees a fair ordering of the render jobs.

• Render job topics. For each render job there will be a HCS topic created to handle messages that are critical for the communication between the render hive nodes and the correct execution of the job.

• Hive Cycle Topics. These topics are essential for the render job distribution algorithm used in the render hive and help to organize the render job execution.

Hedera Smart Contract Service

Smart contracts are distributed, immutable computer programs that run on the blockchain / DLT. These programs can automatically execute code as soon as certain contract conditions are met. The Renderhive Smart Contract will mainly act as an escrow which makes sure that all participants in the network behave correctly. Thanks to smart contracts, the Renderhive works without a central authority that acts as a middle-man. Since no one controls the smart contract once it is put on the blockchain / DLT, no one has control over the funds. And since the smart contract keeps a balance of each user's funds deposited in the escrow, each user can only withdraw their own money and not the money of other users.

No one can access the user's funds on the smart contract except the user itself.

This also means that users alone are responsible for their funds. If a user looses the private key to their connected Hedera account, the Renderhive Smart Contract will keep the user's funds forever. No one – not even the Renderhive project developers – will be able to rescue it.

Mirror Node Service

The Hedera network relies on different types of nodes. The consensus nodes only take care of reaching consensus about transactions and transaction orders. In order to keep them fast, they do not store the complete history of the network. For this purpose, there are mirror nodes.

The Renderhive project will rely on an external mirror node service to allow Renderhive nodes to access older transactions. This is required and important, for example, when a node was offline for some time and needs to obtain the current status of the job queue and the render hive state.