The problem Unstoppable Models solves

We beleve that large AI models training will be regularized as much as traditional finances domain and we would like to provide solution to overpass it. Unstoppable code represents a paradigm shift in how we think about software and applications: some ideas in our world will be implemented, launched and will don't have a single point to shut it down. There are already exists unstoppable things like crypto-mixers with all pros and cons.
We expect there are a lot of people around the world would like to share for free(or not) part of their compute for some time on public good. We allow them to fund our protocol with compute power.
To make AI-model be builded by community in unspoppable manner we just need to ensure an infinite progress of model learning and prevent it from degradation. In the hack we present design for it and example implementation for all parties involved to protocolt:
Worker - attempts to perform a weight update step (or k steps), put stake on correctness of update. The Worker then publishes the updated weights on IPFS.

Validator(DAO) - Token holders who resolve disputes. Validators receive rewards regardless of the outcome but are incentivized to act honestly to promote project growth. Validators may share part of profits with Workers.

Fraud-Proofer - Independently validates selected steps within a specific timeframe and can escalate disputes to the Validator if suspicious activity is detected. If a correctly identified error is confirmed by the Validator, the Fraud-Proofer receives the Worker's stake.

Highlights
-Continuous Improvement: The model can only be improved, as updates are verified for correctness before being accepted.
-True Open Source: The initiative ensures that the model and its updates remain open and accessible to everyone.
-Censorship Resistance: Once a AI-model is published freely, it cannot be regulated or stopped by any central authority (unlike GPT-3).

Challenges we ran into

In the process of creating mock tests for our smart contract via Foundry, we encountered a problem with a simple test of the withdraw method. After interacting with the protocol, the contract caller may attempt to return a stake, but we received an EVM error without explanation for this test. After an hour of debugging, we discovered that it was an internal problem with the framework itself. When we manipulated the test environment around the caller address, we couldn't easily send anything to it regardless of the balance. So, we decided to allow withdrawals to an arbitrary address and tested it against that.