How a node proves it computed honestly

Two identical compute sleds side by side with a small inspection lamp lit on one of them

A small engineering firm sends a batch of simulations out to the network overnight. In the morning the results are back, the tokens have been settled, and the ledger shows that a node somewhere ran the job for four hours. The numbers look plausible. Nobody on the team has the time to check them, and nobody expected to have to.

Three weeks later the same batch, rerun on the office machine for an unrelated reason, gives different answers. Different enough. The team now has a question the ledger cannot answer: did the node compute anything, or did it return something that looked like an answer and bill for the time?

In a cloud with a company behind it, you would phone the company. In a network built to be anonymous, there is no company, and the node has no name to phone.

The real cause: settlement pays for time, not for truth

A token in KyberFusion is a unit of settlement for compute. The ledger records that capacity was used, at what rate, and what was owed. What the ledger cannot see on its own is whether the capacity was used for the work it was paid for. A node that is paid by the hour has a quiet incentive to be paid for hours it did not spend, and an anonymous node has fewer reasons to fear being caught. The honest design question is not “how do we trust nodes” but “how little trust can we get away with, and what does each reduction cost”.

How a node can lie

It returns nothing of value. The simplest fraud: accept the job, run a cheaper model or a shorter run, return output that passes a glance, and bill the full time. For work whose answer is hard to check by eye, this is almost free to do.

It reports more than it used. The job ran, but the meter was padded. Four hours become six. Without an independent measurement, the node is the only witness to its own effort.

It runs the wrong software. The job asked for a sealed cell with a fixed image. The node ran something else: an older build, a patched one, one that leaks. The result may even be correct, and the promise about what the node could see is still broken. What that promise is supposed to cover is spelled out in what a cloud node knows about you.

It collects stakes it does not deserve. A node builds a good record on small, easy jobs, then cashes the reputation on one large job it never ran. Reputation systems reward exactly this patience.

It colludes. Two nodes that are supposed to check each other are the same operator behind two pseudonyms. Any check that relies on independence fails silently when the independence is fake.

What verification actually looks like

Each of the methods below is well understood, and none is free. The network should pick a mix per class of work rather than pretend one method covers everything.

Redundant execution. Run the same job on two nodes that do not know about each other and compare. If the outputs match, both get paid; if they differ, a third decides. It is the most convincing check and the most expensive, because the user pays for the work twice. It also only works for work that is deterministic, which much SI inference is not unless it is pinned down carefully.

Spot checks. Run every job once, but recompute a random fraction on a trusted or redundant path and compare. Cheap on average, and a node never knows which job is the audited one. The cost is that most fraud is caught after the fact, so it has to be combined with something the node loses when it is caught.

Attestation of the software image. Before a job is placed, the node proves which image it is about to run and that it has not been changed. This does not prove the work was done; it proves the work was done inside the thing the user asked for. It needs hardware or a chain of signatures that the network trusts, and that trust is itself a dependency to be honest about.

Reputation tied to a stake. A node puts tokens up as a bond. A failed spot check or a mismatched redundant run costs part of the bond and the record. This gives the cheap checks their teeth. It also has to be designed so that a stake is proportional to the job, not to the history, or the patient fraud above becomes the dominant strategy.

Metering the node does not control. For the padded-meter case, the honest answer is an independent measurement: energy drawn, as the home node’s meter already shows, or work units the scheduler issued, rather than hours the node reported.

What the network should not claim

It should not claim that every result is verified. Full redundancy on everything would double the price of compute and still miss non-deterministic work.

It should not claim that an attested image means an honest result. It means an honest environment, which is a different and smaller promise.

It should not claim that a stake makes fraud impossible. It makes fraud expensive, and the amount it costs is a parameter that members will have to set and revisit, which is one of the things the DAO decides.

And it should not claim anonymity and perfect accountability at the same time. Every check that catches a lying node learns something about that node. The design has to say which of the two it gives up, by how much, for which class of work. This is not an offer, and no token has been issued; the methods above are the design we are working from, not a feature of a running network.

A test you can run today

Take one job you currently send to any cloud and ask three questions in writing. How would you know if the result was wrong? How would you know if it ran on different software than you asked for? How would you know if you were billed for more than it used?

For each question, write down the actual mechanism, not the name of the company. If the honest answer to all three is “I would not”, then you are already running on trust rather than verification, and the question is only who you are trusting. The KyberFusion homepage describes a network that is trying to answer those three questions without a name to trust.