Klassisches Proof-of-Work beweist, dass Rechenleistung stattgefunden hat. Robotik benötigt ebenfalls ein Proof-of-Work, aber anders: die Arbeit fand in der realen Welt statt. Die zentrale Frage wird also: „Hat der Job tatsächlich stattgefunden?“ Ein Roboter kann sagen, dass er irgendwohin gegangen ist. Er kann sogar Protokolle hochladen. Aber Protokolle sind billig zu fälschen, es sei denn, man verankert sie an etwas, das schwerer zu fälschen ist: eine Kombination aus Sensordaten, Standortsignalen und manipulationssicherer Bestätigung (damit die Daten von einer vertrauenswürdigen Ausführungsumgebung „signiert“ werden). Hier wird hardwaregestützte Bestätigung (TEEs) relevant: Man vertraut dem Betreiber, ehrlich zu berichten, und man verlagert das Vertrauen auch auf eine gemessene, überprüfbare Laufzeit, die beweisen kann, welcher Code ausgeführt wurde und welche Daten sie beobachtet hat, und dann einen kryptografischen Bericht erstellen kann. In der Praxis wird dies kein magischer Beweis sein. Es wird wie gestapelte Beweise aussehen: GPS + inertiale Sensoren + Kamera/LiDAR-Fingerabdrücke + Bestätigung + Kreuzprüfung (und Strafen, wenn Berichte widersprüchlich sind). Das Ziel ist es, Lügen teuer genug zu machen.