Fwd: Improving BOINC structurally and architecturally

[David P. Anderson]

Someone asked ChatGPT how to improve BOINC.

The results are worth discussing, but they're almost entirely
things we've done already or are in the process of doing.

-- D

---------- Forwarded message ---------
From: Seth <se...@posteo.nvitt>
Date: Thu, Apr 10, 2025 at 1:10 PM
Subject: Improving BOINC structurally and architecturally
To: <da...@berkeley.edu>


Hi,

I've contributed through BOINC on and off for 20 years or so. Now AI
and LLMs are blowing up. I asked ChatGPT about the subject of this
email and copypasted the result. I also posted it to /r/boinc (reddit).
It seems its less popular these days, but maybe a v 2.0 could add some
life, and life to us all? It may even be used to help develop FOSS LLMs
using coding smart LLMs like Claude and Gemini. I'm not much of a
coder, but I put my first site together using ChatGPT. I like the idea
of BOINC's spirit continuing - that we can all add to the advancement
of science that serves us all. Any ideas from below? Its a short read.
I could try to help, but I'm more of an maintenance guy.

Thanks for your contributions.



Improving BOINC structurally and architecturally would mean modernizing
it to better serve scientific computing, increase participation, and
possibly adapt to the new era of decentralized and high-performance
computing—including large language models, edge computing, and GPUs.
Here’s a detailed breakdown of how BOINC could be enhanced:
🧠 1. Better Support for Heterogeneous and Modern Hardware

GPU Utilization Optimization: Improve native support for modern
GPUs, including NVIDIA, AMD, and even Apple Silicon. Current support is
project-dependent and limited.

ARM and Mobile Support: Fully embrace ARM CPUs (including Raspberry
Pi and Android devices). Mobile devices are ubiquitous and underused.

FPGA & ASIC Awareness: As specialized hardware grows in popularity
(e.g. TPUs, FPGAs), BOINC could offer modules that detect and utilize
them where applicable.

🧱 2. Containerization and Sandboxing

Docker Integration: Rather than requiring custom clients per
project, enable containerized work units using Docker or OCI
containers. This:

Simplifies cross-platform compatibility

Improves security (sandboxing)

Reduces dependencies on user systems

WebAssembly (WASM): For very lightweight projects, allow WASM
modules to run directly in a secure environment.

📦 3. Project Distribution and Decentralization

Decentralized Project Hosting: BOINC currently uses centralized
servers per project. A decentralized architecture using IPFS or similar
tech could:

Improve redundancy and fault tolerance

Enable peer-to-peer result sharing

Reduce reliance on any one organization

Distributed Scheduling: Enable distributed work-unit scheduling and
load-balancing to reduce central coordination costs.

🧪 4. Unified Compute Interface

Cross-Compatibility with Other Frameworks:

Integrate with Kubernetes or Slurm to schedule BOINC workloads
on larger compute clusters.

Allow cross-submit from platforms like Folding@Home or
[Rosetta@Home].

LLM + HPC Bridge: Create an optional compatibility layer for LLM
projects (e.g., local fine-tuning, embedding generation) to use BOINC-
distributed compute.

📈 5. Modernized Incentive Structures

Tokenized Rewards (Carefully):

Carefully designed, opt-in token incentives could increase
participation (think Gridcoin done right).

Could also integrate reputation or contribution scoring.

Gamification: Better dashboards, leaderboards, and team-building
features integrated into the client interface.

🧭 6. Improved Client & User Experience

GUI Redesign: The current BOINC Manager is outdated and not user-
friendly.

Create a mobile-friendly, modern GUI

Real-time feedback on contribution impact and system
performance

Automatic Benchmarking & Tuning: Automatically tune performance
preferences per user device to ensure optimal workloads.

🛡 7. Security & Privacy Enhancements

End-to-End Work Unit Verification: Ensure that malicious actors
can't inject false results by enabling cryptographic signatures or ZK-
proofs for completed jobs.

Privacy-Preserving Compute: Incorporate homomorphic encryption or
differential privacy where applicable, especially for health/biological
projects.

🔄 8. Federated Data Exchange & Open Standards

Standard Work Unit Format: Develop an open, versioned work unit
format so new projects can plug into BOINC more easily.

Cross-Project APIs: Allow external applications to query data (with
permission) across BOINC projects for aggregation and meta-analysis.

🏗 Example of a Modern BOINC Flow

User installs a BOINC+Docker client with sleek GUI.

It benchmarks their system, finds matching projects (GPU, AI,
biology).

Work units are delivered via IPFS or other P2P mechanism.

Docker container runs isolated compute job.

Results are cryptographically verified and uploaded back.

User dashboard shows live contribution stats and scientific impact.

[Nicolás Alvarez]

Oh no, LLMs are taking the jobs of "idea guys who don't actually do
the work" now.

--
Nicolás

El jue, 10 abr 2025 a la(s) 7:52 p.m., 'David P. Anderson' via
boinc_dev (boin...@ssl.berkeley.edu) escribió:

> --
> You received this message because you are subscribed to the Google Groups "boinc_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to boinc_dev+...@ssl.berkeley.edu.
> To view this discussion visit https://groups.google.com/a/ssl.berkeley.edu/d/msgid/boinc_dev/CAFtuuLTL4wxKCub48ofJ2CV%2Bg%3DTaLs%3Duj4zBd011PH4XcO0bXA%40mail.gmail.com.

[Vitalii Koshura]

Hello David and Seth,

Thank you for the email.

Before answering in more detail, I would like to highlight that even if the output of ChatGPT and similar LLMs looks very smart, it might be completely wrong, and before doing any actions, please verify the complete output of such a tool.

You might have a feeling that you're talking to the tool that could think and have feelings, but this is wrong: at the end it's just a machine that follows some algorithms.

To summarize with a little joke: "I" in ChatGPT stands for "Intelligence".

GPU Utilization Optimization: Improve native support for modern
GPUs, including NVIDIA, AMD, and even Apple Silicon. Current support is
project-dependent and limited.

As you may know, the BOINC client itself doesn't utilize any GPU: it's done by the Projects' applications.

But it recognizes and reports to the Projects all types of GPUs: AMD, Apple, Intel and nVidia.

ARM and Mobile Support: Fully embrace ARM CPUs (including Raspberry
Pi and Android devices). Mobile devices are ubiquitous and underused.

For years we have had a BOINC client (and BOINC Manager) for Linux on ARM (including RaspberryPi) and Android.

In the next release of BOINC there will also be Windows on ARM support.

FPGA & ASIC Awareness: As specialized hardware grows in popularity
(e.g. TPUs, FPGAs), BOINC could offer modules that detect and utilize
them where applicable.

FPGA & ASIC look interesting, that's true, but also they have two huge disadvantages: price and complexity.

Speaking in other words: FPGA and ASIC could be programmed only once. To flush them with an update or another application requires specialized software and hardware.

Also, the majority of our users don't have access to such devices, so there is no real reason to spend any time trying to find a way (if any) to support them.

TPUs are a little bit different (even if they are also designed for one particular task), but since they become very famous and it looks like in a couple of years every laptop and mobile device will have one on board, we already have a task in our backlog to identify them.

 Docker Integration: Rather than requiring custom clients per
project, enable containerized work units using Docker or OCI
containers.

This is already done and soon will be released: https://github.com/BOINC/boinc/wiki/BUDA-overview

 WebAssembly (WASM): For very lightweight projects, allow WASM
modules to run directly in a secure environment.

This is something we planned a long time ago, but it is also quite a complex task. We still have it in our backlog, so maybe once we will come back to it.

Decentralized Project Hosting: BOINC currently uses centralized
servers per project. A decentralized architecture using IPFS or similar

tech could...

This is not really needed. There are no issues with the centralized way of projects. Using IPFS for such a task is just like flushing trash into the ocean: it will stay there forever and nobody will really understand why it's needed there.

But I know why this is mentioned by the ChatGPT: there were several attempts to link BOINC and IPFS, and all of them failed (see Bacalhau as an example).

Distributed Scheduling: Enable distributed work-unit scheduling and
load-balancing to reduce central coordination costs.

While this sounds interesting, it's a solution for a problem that just doesn't exist.

Even if there could be issues with the server capacity, we have quite good tools to mitigate that. 

Integrate with Kubernetes or Slurm to schedule BOINC workloads
on larger compute clusters.

It's quite funny, because BOINC literally could be used **instead** of Kubernetes and Slurm. 

Allow cross-submit from platforms like Folding@Home or
[Rosetta@Home].

Folding@Home decided to create their own system instead of using BOINC. And this is their choice. They can always create a BOINC application and run their own BOINC server. There is nothing that we should do from our side.

Rosetta@home **is** running on BOINC. If they want to collaborate with Folding@Home, this should be their collaboration, and we, as BOINC, don't need to be involved in that, since we are developing a tool, and not running any of these projects.

 LLM + HPC Bridge: Create an optional compatibility layer for LLM
projects (e.g., local fine-tuning, embedding generation) to use BOINC-
distributed compute.

And.... we have created a mechanism for that: https://github.com/BOINC/boinc/wiki/Sporadic-Applications

 Tokenized Rewards (Carefully):
        Carefully designed, opt-in token incentives could increase
participation (think Gridcoin done right).

We have GridCoin, CureCoin... Maybe something else. There is nothing that should be done from our side to create another **PUT_ANY_FUNNY_NAME_HERE**coin.

Gamification: Better dashboards, leaderboards, and team-building
features integrated into the client interface. 

We have all this available on the websites (including 3rd-party). No need to redevelop another one.

GUI Redesign: The current BOINC Manager is outdated and not user-
friendly.

Something that we already have in our backlog: https://github.com/BOINC/boinc/issues/3185 

Create a mobile-friendly, modern GUI

This sounds interesting, however at the moment there are much bigger issues with the architecture of Android that should be solved first before making a new shiny GUI.

  Real-time feedback on contribution impact and system
performance

Not sure what this exactly means. Every WU calculated by BOINC client using the Projects' application (by default) should be verified, so there is no way to make it more 'realtime'.

Automatic Benchmarking & Tuning: Automatically tune performance
preferences per user device to ensure optimal workloads.

This one looks really interesting, and basically this might be the topic where AI could help by analyzing the system and user behavior and tuning the settings in a corresponding way (also, this looks like a good diploma thesis).

 End-to-End Work Unit Verification: Ensure that malicious actors
can't inject false results by enabling cryptographic signatures or ZK-
proofs for completed jobs.

This is something that was already discussed several times.

But here we come to the same issue: BOINC client knows nothing about the running applications, so there is no way to develop any kind of ZK solution that will be general enough to support any Projects' application.

Privacy-Preserving Compute: Incorporate homomorphic encryption or
differential privacy where applicable, especially for health/biological
projects.

This is nice but should be done on the Projects' side. Again, the BOINC client knows nothing (like Jon Snow) about the Projects' application, and a good protection can't be implemented on the BOINC client's side.

Of course, we can think about some good solutions, but in the end these solutions could be hacked in a very easy way (I don't want to go too deep into the details because this is just another long story).

Standard Work Unit Format: Develop an open, versioned work unit
format so new projects can plug into BOINC more easily.

Sounds great but impossible because of the different nature of running applications. For everything else we have BUDA: https://github.com/BOINC/boinc/wiki/BUDA-overview

Cross-Project APIs: Allow external applications to query data (with
permission) across BOINC projects for aggregation and meta-analysis.

We have this for years, at least for the statistics. Regarding the calculation results, if Projects are willing to open these results before making published paper out of it - they usually publish them on their website.

We could think about implementing such an API, but we got no requests on this, so I doubt this is something that is really needed.

To summarise: most of the ideas are either discussed and dropped for whatever reason, or already planned.

Some of the advice shows that AI is not smart enough and doesn't really understand the way BOINC works, that is why some of the advice is not valid at all.

That is why I warned to not trust AI at the very beginning of this letter.

Best regards,

Vitalii Koshura