G-push

G-push turns spare computing power into a way to support projects you care about — compute instead of money.
A G-push job in progress: Work Units are scheduled across workers, verified, retried when necessary, and combined into project progress.
G-push architecture: a controller coordinates local and remote workers, verifies returned artifacts, and aggregates accepted results.
Failure recovery in action: when a remote worker stops, unfinished work is reclaimed and reassigned while completed results are preserved.
Only verified and accepted work counts toward a contributor’s impact and Contribution Score. Local UI fixture with sample data.
G-push also supports bounded science workloads and parameter sweeps with verified results. Local demo fixture.
Controlled Blender tests across physical workers showed distributed execution and recovery. Bounded test results only.
Project dashboard showing verified progress, active workers, current work, and contribution status. Local UI fixture.

Inspiration

Crowdfunding lets people support an idea by pooling money. I wanted to explore a different kind of contribution: computing power.

Many projects — from rendering and scientific simulations to open-source tools and creative work — need computation. At the same time, a huge amount of computing capacity sits unused on personal devices.

That led to the idea behind G-push:

What if people could support a project not with money, but with spare compute?

G-push is my attempt to turn distributed computing into something that feels more like participation. Instead of simply connecting machines, the system focuses on a more important question:

What useful work did each device actually complete, and how can we verify that it really helped the project move forward?

What it does

G-push is a prototype platform for crowdfunding computing power.

A project is divided into bounded Work Units. Compatible devices can receive those Work Units, process them, and return results. The results are verified before they are accepted, and accepted work becomes visible project progress.

The basic flow is:

Project → Work Units → compatible worker → execution → verification → accepted progress

G-push also tracks contributor impact. Instead of rewarding a device merely for being online, contribution is based on work that was actually verified and accepted.

The system is designed to handle failure as well. Workers use leases and heartbeats, so if a device disappears while holding unfinished work, that work can be reclaimed and reassigned without counting the abandoned attempt twice.

Historical private hardware tests have demonstrated:

distributed Blender rendering across physical PCs,
recovery after a worker was stopped,
verified contribution records,
and bounded compute across Windows and Android.

More recent work adds science and parameter-sweep workloads, a contributor-result interface, and a GP wallet/economy model. These newer parts are currently implemented and validated locally or in disposable environments rather than being presented as a public production service.

How I built it

G-push is built around a controller, scheduler, worker devices, workload adapters, verification, and a web-based interface.

Workers register their capabilities and available capacity. The scheduler uses capability matching, priority, and queue ordering to select an appropriate worker.

When a worker receives a Work Unit, it gets a lease. The worker executes a fixed, allowlisted workload inside a bounded environment and returns the result together with metadata such as its size and SHA-256 hash.

The controller verifies the returned artifact before accepting it.

For failure handling, G-push uses heartbeats and lease expiration. If a worker disappears, unfinished work can be returned to the queue and reassigned, while previously accepted results remain preserved.

I also built workload-specific execution paths instead of allowing arbitrary code execution.

Examples include:

Blender rendering on compatible Windows workers,
bounded WebAssembly-based scientific workloads,
and parameter sweeps where individual cells can be distributed and verified before being aggregated.

For science workloads, the server controls the module, limits, validator, and expected output format. The worker cannot choose arbitrary executable code.

The UI then translates this infrastructure into something understandable: project progress, active workers, accepted Work Units, recovery events, contribution records, and workload results.

Challenges I ran into

The biggest challenge was realizing that distributed computing is not mainly about sending jobs to multiple devices.

The difficult part is deciding what happens when something goes wrong.

A worker can disconnect while holding unfinished work. A result can arrive late after the same Work Unit has already been reassigned. A duplicate result must not count twice. A completed computation must still be verified before it changes project progress.

That forced me to separate several concepts that initially looked like one event:

a worker receives a task,
the worker executes it,
a result is returned,
the result is verified,
the result is accepted,
contribution is recorded.

Keeping these stages separate made the system much more reliable.

Another major challenge was security. A distributed worker system becomes dangerous if workers can receive arbitrary executable code, so G-push uses fixed workload adapters, bounded execution, path and size restrictions, and verification rather than exposing unrestricted shell or executable workloads.

Finally, one surprisingly difficult challenge was evidence. A feature being implemented is not the same thing as proving that it works on the newest build, and a successful historical hardware test does not automatically prove every newer feature.

Because of that, I started explicitly separating local validation, historical hardware proof, and features that are still under private validation.

Accomplishments that I'm proud of

One of the most important milestones was getting G-push beyond a UI prototype and running real distributed workloads.

In controlled private hardware tests, G-push has demonstrated physical multi-PC Blender execution and recovery after a worker disappears. In one recovery scenario, unfinished work was reclaimed and reassigned while already completed work was preserved.

I also implemented verified contribution tracking so that rejected, abandoned, duplicated, or unverified work does not count as accepted contribution.

Another milestone was extending the platform beyond rendering. The current workload-adapter system includes bounded scientific WebAssembly workloads and parameter sweeps, creating a path toward using the same architecture for research and simulation workloads.

What I learned

The biggest thing I learned is that "completed" needs a precise definition.

A worker returning data is not the same thing as the server verifying it.

Verification is not the same thing as accepting it.

Acceptance is not the same thing as recording contribution.

And contribution accounting is not the same thing as an economic transaction.

Separating those states made the architecture clearer, made failures easier to reason about, and made the product easier to explain.

I also learned that reliability features such as retry, leases, verification, and idempotency are not just backend details. They directly affect whether a contributor can trust that their device actually helped a project.

What's next

The next milestone is to finish validation of the current Windows and Android releases and complete the end-to-end private validation of the newer science workloads.

After that, I want to extend G-push toward more project types while keeping the same core rule:

a project only moves forward when useful computation is independently verified and accepted.

Longer term, I want G-push to become a platform where people can visibly help research, creative projects, open-source software, and other ideas by contributing the computing power they already have.