Smart Contract

The Renderhive Smart Contract has two major functions, which are described in this section: The node management and the user fund management.

Node Management

Since the network is free for everyone to participate and uses no centralized servers, there needs to be a way to make sure that all participants know which node is part of the hive, so that external and potentially malicious actors cannot disturb the inner workings of the hive. The smart contract helps to do that by requiring every user to register with the smart contract. Additionally, every user needs to register every node with the smart contract. That way, every node is able to ask the smart contract if another node in the network is a valid member of the hive. This is important, because the message exchange on the render hive is open for everyone and nodes need to know which messages should be ignored and which not.

User Registration

Each new user registers at the render hive by connecting an existing Hedera account (i.e., the "user account") to the smart contract. This process will only store the public address of the wallet, a user ID, a username, and the time of registration. Neither the smart contract nor other software components of the Renderhive project will ever see the private key of this account. All fund configuration changes of the user's nodes as well as deposits and withdrawals to and from the smart contract will only be accepted from this account.

Node Registration

For each new node the user wants to connect to the render hive, a node account must be created. Prior to using the node, the user calls the smart contract from the Renderhive Service App using its previously registered user account. The smart contract will store the address of the node account, the user account it belongs to, a node ID, and the registration time as well as some configuration details of the node.

User Fund Management

On a decentralized network that involves peer-to-peer services, the question of a user fund management needs to be addressed. Indeed, a secure and trustworthy fund management is the second main purpose of the Renderhive Smart Contract.

Purpose of the Fund Management

The Renderhive Smart Contract forms the trust layer for the interactions between the client nodes (i.e., the users buying render power) and the render nodes (i.e., the users selling their render power). These parties have competing liability interests:

• Client nodes only want to pay, if their requested render job is executed by the render nodes

• Render nodes only want to work, if they get paid for sure

Thus, neither a "first pay then render" nor a "first render then pay" approach would satisfy both parties at the same time. To solve this issue, the smart contract escrow is introduced.

Deposits and Withdrawals

The smart contract will only accept deposit and withdrawal transactions of the user from their user account. Transactions will be prepared by the Renderhive Service App, which will call the users wallet software (e.g., Hashpack) to sign it. That way, private keys will never be exposed to the Renderhive software components and, thus, are safe.

Like all code of the project, the Renderhive Smart Contract will be open source as well. That way, the project provides a maximum of trust, since anyone can check that the smart contract has no bugs and no backdoors.

Partial Fund Lock-ups

Both render nodes and client nodes can deposit and withdraw funds within seconds by calling the smart contract at any time. The only situation in which parts of user funds are locked on the smart contract is during the execution of render jobs. The smart contract will keep track of all user balances internally and also which parts of a user's total funds are locked up (because of pending render jobs) and which are free to withdraw.

The users will experience only a minimum time of funds lock-up while using the render hive. During render job execution, on the other hand, the (partial) funds lock-up will provide a maximum of trust in form of a network guarantee for each node type:

• Render nodes have the guarantee that they are paid for the (correct) execution of their computational work (i.e., the rendering of render jobs)

• Client nodes have the guarantee that they don't loose money if a render node submits an incorrect render result