Open Grant Proposal: Renderhive – A Web3 crowdrendering platform for Blender

[regcs]

Open Grant Proposal: Renderhive

Name of Project: Renderhive

Proposal Category: app-dev

Proposer: @regcs

Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?: YES

Project Description

The increasing hardware capabilities of consumer computers and software like Blender – the free 3D computer graphics software – give millions of artist the opportunity to pursue their creative work on computer generated imagery (CGI). The bottleneck in the workflow of these 3D artists usually is (and always has been) the rendering process (i.e., the actual computation of the image or movie). This process is time-consuming and requires powerful and costly hardware, which by far not every artist can afford. Cloud-based render farms offer a commercial solution to this issue by selling CPU/GPU power provided by centralized server farms at a moderate price. However, their price formation and job order is usually in-transparent, the central servers distributing the render jobs represent single-points of failure, and large centralized render farms are certainly not the best fit for an open-source community project like Blender.

On the other hand, there are millions of 3D artists (and gamers) already owning powerful computers with high-end consumer CPUs/GPUs. This hardware often remains unused for at least a good part of the day, when their owners do not need it. This represents a remarkable amount of latent CPU/GPU computation power, which could be put to use for other artists to speed up their rendering times and, thus, their creative workflows.

Renderhive aims to bring together this supply and demand of computational power in a trust-free, decentralized, self-governed marketplace which enables any owner of a CPU/GPU to offer their computation power in times they do not need it for their own projects to others who need it. Prices will be formed in a transparent, free market mechanism, in which every participant can make price offers and requests. This will balance prices and keep them below the prices of cloud-based render farms. Furthermore, it offers each participant to choose a personal market strategy (e.g., optimize price, optimize render times, optimize render start times). Renderhive will utilize IPFS/Filecoin and Hedera's distributed ledger technology (DLT) to establish trust among the participants of the network, to provide verifiable proofs-of-copyright ownership, to guarantee fair ordering of the render jobs, to enable an efficient render job distribution, to exchange files in a temper-proof and accessible way between the participants, and to provide a cryptocurrency-based payment system with low transactions fees between the participants.

Value

Value For IPFS / Filecoin:

Renderhive uses IPFS's decentralized storage in at least three ways:

• as data exchange platform for Blender files, render results, render offers/request, and other files
• as immutable proof-of-copyright mechanism by storing the CID of each Blender file on a public DLT prior to sending it to other person's computers for rendering
• as integral part of a decentralized render job distribution algorithm

While the first two use cases are self-explanatory, the latter represents a novel use case for IPFS and requires a brief explanation: The major challenge in a distributed rendering system like Renderhive is that all nodes need to come to a consensus about who renders which specific part of a given render job at what time and at which price. Since all nodes are equal, there is no central server which distributes the render jobs like in conventional render farms. The required decentralized distribution process needs to be reliable, fast, cost-efficient, and must not require the exchange of an excessive amount of messages and data between the network nodes. Renderhive aims to solve this issue via the content-addressing of IPFS which ensures that two nodes creating the same file locally end up with the same CID. Thus, if two Renderhive nodes have the same knowledge about the render offers (stored on IPFS), the render requests (stored on IPFS), and the render job order (stored on Hedera) at a given time, they can perform a defined render job distribution algorithm locally on their machines and pin the final result as a JSON file to IPFS. This file contains the information about who renders which specific part of a given render job at what time and at which price. The CID of this file can then be used to check for consensus about the render job distribution in a single message from each node (e.g., via IPFS pub/sub or Hedera). The local execution of the distribution algorithm keeps the process fast, exchanged data volume low, and IPFS's CIDs help to notify the network about nodes that deviate from the consensus (e.g., because they missed some of the information or tried to deviate from the job order on purpose to render a more profitable job). Accidentally deviating nodes can then simply retrieve the correct job distribution via the CID the consensus was reached for.

A further benefit for the IPFS ecosystem is, that Blender has 3,000,000+ users worldwide and the user base keeps increasing year-over-year.^[1] These Blender artists are potential users of Renderhive – and, hence, of IPFS/Filecoin. Since Blender itself is a flourishing open-source project, there is a large group of developers in the Blender community that could help in the development of Renderhive. For many of them, this could be their first contact to Web3 development and decentralized storage.

Value For Other IPFS-based Dapps

Although Renderhive is dedicated to the specific problem of rendering, it essentially represents a trust-free task distribution system for decentralized computation. The mechanisms and open-source code base that will be developed with support of this Open Grant can, thus, also be a basis for other projects, which involve power hungry computation tasks (e.g., scientific simulations, other rendering software, machine learning, etc.).

Value For the Blender Community

Renderhive will be the first fully decentralized, blockchain-based marketplace, which brings rendering in Blender from the cloud to the crowd. For artists with powerful hardware, this project provides the opportunity to generate an additional income and, thus, supports them in financing their creative work. For artists without the hardware, it offers a trust-free platform to render their artworks faster and at a reasonable, low price. The latter will be lower than the prices on conventional render farms because they will be determined by the market participants and not a single render farm provider. Participants may even offer their render power for free, which would be an opportunity for many artists to give something back to the Blender community. Given the philosophy of Blender and it's userbase, it is not unlikely that a part of Renderhive users will choose this model.

Renderhive will generate a (low) income via the operation of own render nodes and Hedera's risk-free (indirect) staking mechanism. It is a specific goal of the project to donate parts of future revenues from these sources to the Blender Foundation in order to support the development of the Blender software and ecosystem.

Potential Risks

The major risk of the project lies in the yet unknown efficiency of the distribution algorithm. The system must also cope with a continuous change of the available nodes (since nodes may go on and offline at any time) and nodes going offline before they finish their assigned tasks. Furthermore, payments on Renderhive will be performed via cryptocurrencies and the extend of Web3 scepticism among the Blender users is unknown. Another potential risk is that users will need to take care of the taxation in their respective jurisdictions for any income generated on the render hive, because users will effectively offer a service to other persons and companies. The Renderhive project will need to provide information and tools to make a proper invoicing to support users in this.

Deliverables

The main deliverables for this proposal are beta-versions of the node software (back end), a smart contract (back end), and a basic local web interface (front end). More specifically that means:

Archive for Blender Versions on IPFS

• Pin all versions of Blender supported by Renderhive to IPFS via pinning service

  Note: This ensures all render nodes use the same Blender versions to avoid conflicts.

Back End – Node Software (Renderhive Service App)

• Open-source (MIT & Apache 2.0 licence), written in Go
• Management of account configuration, local rendering processes, payments, etc.
• Local IPFS node for exchange of temporary data between Renderhive nodes
• Communication with a Filecoin storage provider to pin files (e.g., Blender files, render results, etc.)
• Decentralized render job distribution algorithm relying on IPFS

Back End – Smart contract(s)

• Open-source (MIT & Apache 2.0 licence), written in Solidity
• Uses Hedera's Smart Contract Service, EVM-compatible
• Handles node registration, payments between nodes, render result confirmations by clients, etc.
• Stores user funds in an escrow and an escrow balance per user

Front End – Local Web Interface (Renderhive Dashboard)

• Served locally by the Renderhive Service App
• UI for node registration
• UI for node configuration (e.g., render costs, render settings)
• UI to estimate render costs (including Hedera fees)
• UI to create, manage, and view render jobs
• UI to monitor render job progress
• UI to evaluate render results in a watermarked version prior to payment of render nodes

Beta Phase

• Closed-beta testing with a set of external (permissioned) nodes
• Written report with the results and experiences gathered in the beta phase

Development Roadmap

Project Preparation (Q4/2022)

(This section is for information about the current status only and not part of the grant proposal.)

Research:

• [x] Compare different frameworks for decentralized data management (e.g., OrbitDB)
• [x] Compare different IPFS pinning service (e.g., web3.storage)
• [x] Compare different Hedera mirror service

Whitepaper:

• [x] Drafting of the whitepaper for the Renderhive project

Back end (Renderhive Service App):

• [x] Implement basic communication with Hedera's Consensus Service
• [x] Implement basic communication with Hedera's Smart Contract Service
• [x] Prepare internal data management of the network state (i.e., job queue, available render nodes, running jobs, etc.)
• [ ] Establish JSON schemas for node configurations, render offers, render request, etc. (Update: Shifted to later development phase, since it makes more sense to implement it on the fly)

Milestone 1 (Q1/2023)

Hardware:

• [ ] Purchase and deploy a first computer with high-end GPU (Required as render node and for local development and testing)

Back end (Renderhive Service App):

• [x] Implement basic rendering functionality via Blender
• [x] Implement local IPFS node
• [x] Implement internal render job management
• [ ] Implement communication with a suitable Filecoin pinning service

Milestone 2 (Q2/2023)

Hardware:

• Purchase and deploy the next render node
• Vary hardware specs and OS compared to previous node to add diversity

Smart contract:

• Develop Renderhive's central smart contract
• Add internal ledgers for render jobs and user funds
• Add functions for node sign up
• Add functions that allow each user to deposit and withdraw funds at any time
• Add functions to shift money between user balances on the smart contract for payments between users
• Add functions to open and close render jobs

Back end (Renderhive Service App):

• Implement communication with the smart contract
• Add automatic pinning and unpinning of render offers, render requests, and render results on IPFS

Design & Website:

• Professional re-design of branding (hire a designer)
• Professional re-design of landing page & website (hire a wedesigner)

Milestone 3 (Q3/2023)

Hardware:

• Purchase and deploy the third render node
• Vary hardware specs and OS compared to previous nodes to add diversity

Back end (Renderhive Service App):

• Implement the decentralized render job distribution algorithm based on IPFS & Hedera
• Implement render result verification mechanism
• Add capabilities to locally serve a browser-based UI as front end

Front end (Renderhive Dashboard):

• Create basic web-based front end (based on the website design)
• Content is served by the Renderhive Service App
• Add node / account registration form
• Add node / account configuration form

Design & Website:

• Create a full project website with more information

Milestone 4 (Q4/2023)

Back end (Renderhive Service App):

• Optimize the render job distribution algorithm
• Optimize the rendering process

Front end (Renderhive Dashboard):

• Add render job submission form
• Add render job management form and job status page
• Add render result verification form

Milestone 5 (Q1/2024)

Beta phase:

• Operation of Renderhive on Hedera's testnet in a three-month beta phase with external (permissioned) nodes
• Onboarding of the first 25 external render nodes
• Onboarding of the first 50 to 100 client nodes
• Gather important insights on network performance, usage, stability, etc. under real-world conditions
• Gather experiences with funding model via Hedera's risk-free proxy staking

Note: The operation on the testnet during this phase minimizes financial risks. However, it also means that no "real" payment transactions will be involved. Consequently, client nodes will be able to render their jobs for free on the 25 external nodes (+ the 3 Renderhive render nodes), which should be a strong incentive to participate in the beta phase. In contrast to that, render nodes would offer their GPU/CPU power without earning real cryptocurrency. To incentivize their participation, they will be compensated by funds from this proposal for providing their render power (see below).

Total Budget Requested

Total Budget Request: €67,750 (~69,000 USD)

This request is based on the following cost factors estimated for a development period of 15 months:

Cost Factor	Milestone 1	Milestone 2	Milestone 3	Milestone 4	Milestone 5	Total
Developer Compensation	€4,500	€4,500	€4,500	€4,500	€4,500	€22,500
Hardware	€6,500	€6,500	€6,500	-	-	€19,500
Electricity Costs	€250	€500	€750	€750	€750	€3,000
Design & Website	-	€2,500	€2,500	-	-	€5,000
Onboarding (Beta phase)	-	-	-	-	€9,000	€9,000
Project Overhead	€1,750	€1,750	€1,750	€1,750	€1,750	€8,750
Total	€13,000	€15,750	€16,000	€7,000	€16,000	€67,750

Note: As discussed with Sonia, I would like to note that parts of the budget would require pay out at the beginning of the corresponding milestone, since the costs are too high to be pre-funded by the developer prior to pay out by the grant program (see the values in bold).

Developer Compensation

• Compensation for development and project coordination (part-time work at €1,500 per month)

Hardware

• Three render nodes for testing during development and as initial render power for the launch of the platform
• Technical equipment (e.g., adapters, backup, network switches, etc.)

Electricity Costs

• The electricity costs for the operation of the render nodes (see "Hardware")
• Cost estimation for the electricity cost of render nodes based on following parameters:
  • Power draw during rendering: 700 W
  • Rendering per day: 12 hours
  • Average electricity cost in Germany: 0.33 €/kWh^[2]

Design & Website

• Professional brand design
• Professional project website

Onboarding (Beta phase)

• Onboarding budget is spent to incentivize Blender users with sufficiently powerful hardware to participate in the beta phase as render nodes
• Compensation budget for render nodes was estimated based on following parameters:
  • 25 external render nodes
  • 8 hours of active rendering time per day and node
  • 0.50 €/hour compensation (based on maximum electricity cost in Europe 2022^[2])
  • Beta phase duration: 90 days

Project Overhead

• Consulting costs (i.e., legal advice, tax consultant)
• Software licenses
• Web hosting
• SaaS & API (e.g., web3.storage, mirror node service, etc.)
• Travel expenses

Maintenance and Upgrade Plans

• Grow open-source developer basis
• Open beta-phase on Hedera's mainnet
• Explore opportunities of the upcoming Filecoin Virtual Machine for this project
• Development of a dedicated Blender add-on to optimize rendering efficiency & scaleability
• Implement support for upcoming Blender versions
• Development of further services (e.g., option to rent render nodes directly for a fixed time)
• Explore option for direct minting of NFTs for artwork rendered on Renderhive (Hedera + IPFS)
• Establish a decentralized governance model (e.g., improvement proposal mechanism)

Team

Team Members

• Dr. Christian Stolze (@regcs)

  (At the beginning, the project will start of with a single developer. Since the project development will be open, interested contributors are expected to join in the later development phase or during the beta phase.)

Team Member LinkedIn Profiles

• https://www.linkedin.com/in/christian-stolze-1674961a3/

Team Website

• https://www.renderhive.io/

  (So far, only a basic landing page has been created to inform about the project. A professional re-design of the landing page and the creation of a professional website is part of this proposal.)

Relevant Experience

• I developed a Blender add-on and have worked on improvements in Blender's codebase itself. Thus, I am familiar with the details of this software and how to include it in development projects like Renderhive
• As a full-time physicist I am used to work on complex problems and to approach their solutions efficiently

Team Code Repositories

• https://github.com/renderhive-projects/

Additional Information

Project Whitepaper

Additional details about the project can be found in the draft-version of the project whitepaper

Requested Information

I learned about the Open Grants Program by specifically searching for grant programs in the Hedera and Filecoin ecosystems. If you have any questions or want to contact me regarding this project, please use the following email address: contact@renderhive.io.

References:

[1] Blender by numbers, 2020

[2] Electricity prices (including taxes) for household consumers, first half 2022

[realChainLife]

Hi @regcs can you share the technical logic for funds lock-up via the escrow smart contract, and how it will influence the user experience while using the tool?

[regcs]

Hi @realChainLife!

Sure, I am happy to provide some more details on this aspect.

Renderhive Smart Contract

Motivation for the Escrow

The smart contract forms the trust layer for payments 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 security interests:

• Client nodes only want to pay, if their requested render job is correctly 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

Upon registration, each user can connect up to two Hedera account IDs ("Wallets") with the smart contract. The smart contract will only accept deposit and withdrawal calls from these wallets. 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 won't be exposed to the Renderhive Software.

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 up on the smart contract escrow is during the execution of render jobs. The smart contract will keep track of the user balances internally and also which parts of the total funds of a user are locked up (because of pending render jobs) and which can be withdrawn.

As additional safety mechanism (to disincentivize fraud attempts by either node type), users will only be able to submit or execute render jobs, if they have a minimum amount of funds deposited in the smart contract (probably something between €1 and €10). This safety deposit can also be withdrawn at any time as well. However, other nodes in the network will ignore all nodes with insufficient safety deposit during render job distribution until the safety deposit is filled up again. That way, creation of fake accounts and specific types of fraud attempts become prohibitively expensive.

Technical Logic of Render Job Submission and Execution

The workflow from a smart contract perspective is the following:

1. Prior to submitting a render job, the client node will execute a short test render on their local machine to estimate the amount of render work that needs to be done for the requested render job. Based on the result of this test, the cost of rendering this render job is estimated. When submitting the render job request to the Renderhive network, the smart contract will check if the user has enough funds on the smart contract to pay for this render job. If not, the user will be prompted to deposit more. After successful submission of the render job, this part of the user funds is locked up in the escrow until the render job was executed, rejected, or cancelled.

2. After render job distribution, the render node makes the same test render like the client node to check if the user deposited enough money in the escrow to pay the render job. If not, the render node rejects the render job and informs the user that money is missing, so that the user can deposit more. This way, client nodes cannot cheat by reporting wrong render cost estimates to the network in order to deposit insufficient amounts of money. If everything is okay, the render node executes the render job and provides the CID of a watermarked render result to the client node and the CID of the real render result to the smart contract.

3. After rendering, the client node has 24 – 72 hours (not yet decided) to check, if the watermarked render result is correct. If not, the node can reject the result and request another node to render the job. If everything is okay, the client node confirms this by calling the smart contract, which will then update the internal user balances of the corresponding client and render nodes and provide the client node with the CID of the final (non-watermarked) render result.

4. After confirmation by the client node OR if the 24 – 72 hours period has passed without confirmation, the render nodes can withdraw the funds for the executed render job from the smart contract at any time.

Impact on the User experience

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

• Render nodes have the guarantee that they are paid for (correct) computational work
• Client nodes have the guarantee that they don't loose money if a render node submits an incorrect render result.

Of course, the smart contract will be created without admin key, so that no one can access the funds on the smart contract except the users. 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 others. However, this also means that users alone are responsible for their funds. If they loose the private key(s) to their connected wallet(s), the smart contract will keep the user's funds forever.

Note: At a later point, when a suitable decentralized governance model is established, one can think of integrating "rescue" functions for this kind of situations into the smart contract, where users can go through a KYC mechanism and request withdrawal of trapped funds by asking the governance group to withdraw the money on their behalf using a multi-signature transaction. But this will be decided later within the commuity.

[regcs]

I just updated the proposal to include a link to the draft version of the Renderhive Project Whitepaper. It is not complete, but gives a first comprehensive overview with some technical and conceptual details about the project. It will be further updated in the upcoming weeks.

[ErinOCon]

Thank you for the update, @regcs!

[regcs]

Updated proposal:

A further risk was added to the potential risks: Users will need to make sure that they pay proper taxes in their respective jurisdiction for the rendering service they sell on the render hive. While this is not considered a big issue for professional artists or companies participating in the hive, it might scare off some hobby artists that would otherwise sell their render power.

This can be mitigated by providing information, tools for a transparent invoicing, and an alternative mechanism where users don't sell their render power for money but instead gather credits for rendering the work of others, which they can later spend to render their own larger projects on the hive for no additional costs.

[regcs]

@realChainLife, @ErinOCon: I hope you had a good start into 2023. I know that you and the rest of the team are having a lot to review at the moment. Please let me know if I can provide you with anything to make the evaluation of this grant proposal easier on your side. Meanwhile, I have a short status update on the project:

Update project status (January 23, 2023):

• Project preparations scheduled for Q4/2022 are finished (except for the JSON schemas, which were postponed to a later development stage to make things easier)
• Additional command line interface was added for the development phase (and since running the app headless might be useful for users later as well)
• I decided to go on with the development roadmap as outlined in the proposal while your review is pending, i.e. work on Milestone 1 has begun:
  • [x] "Implement local IPFS node"
  • [x] "Implement basic rendering functionality via Blender"
  • [x] "Implement internal render job management"
  • [ ] Work in progress: "Implement communication with a suitable Filecoin pinning service"

[regcs]

Update project status (March 16, 2023):

• Updated proposal text with current state of the project
• Development paused until funding decision by Filecoin Foundation is made, since the development cannot be pursued at the moment without the requested financial and hardware resources

@realChainLife, @ErinOCon: I saw that you are currently re-evaluating your funding structure and that this causes a delay in the proposal reviews. Please let me know as soon as you can make a decision on this proposal, so that I can make up my mind about if and how I can continue with this project. Thank you! :)

[ErinOCon]

Hi @regcs, thank you for the updates and for your patience with our review process. I know it’s been a long time since you submitted the original proposal. Since FEVM is now out, will you be considering how you can use FEVM instead of Hedara?

[regcs]

Hi @ErinOCon, thank you for your message and your follow up question. Indeed, I already thought about that. At the moment, I see the future of the Renderhive project in mechanisms without the need for EVM smart contracts. This would have both significant performance and cost benefits, which are important to eventually get the best user experience.

There are several feature developments on Hedera in the works that might enable this in the future (e.g. long-term scheduled transactions). However, since this is work-in-progress, I need to start with an EVM-based approached for now. It would not make sense to implement everything on FEVM first, because I would eventually need to re-factor to Hedera once the required features are implemented. That said, I am also looking forward to how the native FVM (after milestone 2.2) will develop throughout this and the next year and would love to explore its possibilities for the Renderhive project later as well. It may enable a more efficient file distribution and would definitely be beneficial for some of the ideas I have in mind for next project phases. However, first things first: All of the aforementioned is something I'd rather see as the next development step, once the work outlined in this proposal is successful.

Because of that I would like to stick with the initial plan: Combine the strengths of Hedera and IPFS/Filecoin. I strongly believe in both projects and would love to see them intertwined as integral parts to make the Renderhive a powerful, cheap, and efficient rendering network while keeping multiple development directions open for future improvements.

[ErinOCon]

Hi @regcs, I am very glad to report that we would like to move your proposal forward to the next steps in our process! We will send an email with further details.

[regcs]

Thank you a lot for the good news. I received your email and just responded. I am very much looking forward to make this project happen with the support of the Filecoin Foundation!