Alina Schanz

Research noteAI infrastructure

What I ask a decentralized compute network

The questions I put to networks that sell training or inference from many independent operators. Most of them reduce to one: when a claim of work is false, who notices, and who pays.

Status
Working list, revised as I use it

Why this is a verification problem

A network that pools GPUs from strangers sells two things: the compute, and confidence that the compute happened as described. The first is close to a commodity. The second is where the design lives, and it is where pitches tend to be vaguest.

The questions

  1. Who did the work? Can the network name the operator behind each job, and can one operator take the same job twice under two names?
  2. How is the work checked? Recomputation, sampling, a proof, a trusted execution environment, reputation, or nothing. Each has a cost, and that cost has to stay below the margin the network claims over a data center.
  3. What does a check cost, and who pays for it? If verification runs at the buyer’s expense, the advertised price is not the real price.
  4. What happens when a check fails? Slashing only works if the operator has something at stake and the evidence holds up when the operator disputes it.
  5. What can an outsider confirm today? Public commitments, logs or a chain record that a third party can read without the team’s help. If the answer is a dashboard, I treat the numbers as marketing until I can check them.
  6. Where is the demand? Jobs submitted or subsidized by the network itself look like usage. I ask for the share of paid work from buyers with no tie to the network.
  7. What leaks? Training data and weights pass through machines the buyer does not control. I want to know what an operator can see, and what it can keep.

How I use them

They are not a scorecard. A network can miss two of them and still be worth backing, if the team knows which two and has a plan for them. The ones I pass on are the networks that cannot answer the second question in specifics.

Before the call I read what the team has made public and write down what is not clear from it. Those gaps become the first questions.