Gutschriften gelten nur für ein verifiziertes Paar
Veröffentlicht
Ein Gerät, das Rechenleistung beisteuert, verdient Gutschriften. Fast jede interessante Entscheidung dieses Projekts steckt in diesem Satz: Wer entscheidet, dass ein Gerät etwas verdient hat, was verhindert, dass die billigste Lüge die profitabelste Strategie ist, und warum das Verdiente nicht verkauft werden kann.
Unmöglich machen statt nur verbieten
Die Spezifikation definiert eine Gutschrift als ganze Zahl von Mikrogutschriften, eine Million davon pro Gutschrift. Ganze Zahlen, nie Gleitkomma, weil das geldähnliche Daten sind und ein Rundungsfehler nicht entscheiden darf, ob ein Gerät bezahlt wurde. Die Spezifikation benennt außerdem das Feld balance als einzige Autorität für Geld; der Anzeigewert daneben existiert zum Darstellen und darf nie für Arithmetik oder Abrechnung verwendet werden. Dieser Unterschied ist keine Pedanterie: Ein Dashboard las zuerst den Anzeigewert, und ein Gerät, das vierzig Mikrogutschriften verdient hatte, wurde dem Betreiber als auf null gerundeter Bruchteil einer Gutschrift angezeigt, in der falschen Einheit.
Gutschriften liegen in einem doppelt geführten Ledger. Jede Bewegung hat Buchungen, die sich zu null summieren müssen, die Summe des Ledgers muss null sein, und die Invariante wird geprüft statt angenommen. Konten sind device, operator und treasury, und jeder Eintrag trägt den Grund: ein Job-Verdienst, eine Job-Ausgabe, eine Korrektur oder eine Verweigerung wegen der Obergrenze.
Die Nichtübertragbarkeit ist strukturell und keine Notiz in der Policy. Der Chain-Adapter bietet genau drei Methoden: einen Verdienst erfassen, das Ledger-Präfix verankern, den Status melden. Eine Transfer-Methode gibt es bewusst nicht. Eine Gutschrift, die zwischen Konten wandern könnte, wäre ein handelbares Reward-Token; ohne Transfer in der Schnittstelle kann sie nicht verkauft, ausgezahlt oder gehandelt werden, auch nicht von einem Aufrufer, der es will.
Eine einzige Stelle, an der Geld fließt
Der Koordinator hat genau eine Stelle, an der Geld fließt, und sie führt über die Verifikation und dann über die Abrechnungsfunktion. Bezahlt wird Arbeit, die ein zweites Gerät reproduziert hat, niemals selbst gemeldeter Durchsatz, weil sonst die billigste Art zu verdienen das Lügen wäre. Die Ergebnisse werden aufgezählt und nicht der Ableitung überlassen:
- Ein einzelnes, unrepliziertes Ergebnis zahlt null, mit dem Grund awaiting_replica.
- Ein übereinstimmendes Replikat-Paar zahlt einmal, an das primäre Gerät, mit dem Grund verified und der bezahlten Job-ID in der Abrechnung.
- Ein abweichendes Replikat wird abgelehnt und zahlt niemandem etwas.
- Ein deterministischer Job ganz ohne Replikat wird abgelehnt.
- Ein Replikat, das dasselbe Gerät wie das primäre meldet, wird abgelehnt. Replikation ist Prüfarbeit und wird nicht als zweiter Verdienst bezahlt.
- Eine gesampelte, nicht deterministische Operation ohne Replikat ist unverified und zahlt niemandem etwas.
- Ein bereits abgerechnetes Paar liefert already_settled und schreibt null gut, weil das Ledger einen Nullifier trägt, der eine zweite Zahlung stoppt.
Der Betrag und seine ehrliche Grenze
Die Spezifikation setzt den Betrag als die kleinere der beiden gemeldeten Dauern in Sekunden, multipliziert mit einer Rate und einem Beschleuniger-Faktor und gerundet. Die Rate der Spezifikation beträgt hunderttausend Mikrogutschriften pro Sekunde und ist überschreibbar; ihr Faktor ist drei für WebGPU, zwei für WASM und sonst eins. Die kleinere Dauer zu nehmen bedeutet, dass das Aufblähen einer Zahl nichts bringt.
Beide Dauern sind Selbstauskünfte der Geräte, und das Projekt sagt das, statt es zu beschönigen. Die Zahlung hängt weiterhin an einem übereinstimmenden Output-Digest, aber ein kolludierendes Paar, das zu niedrig meldet, wird nur durch die Tagesobergrenze begrenzt. Der dokumentierte Ausbaupfad ist, die verstrichene Zeit auf der Uhr des Koordinators zu messen. Der Verdienst ist zudem pro Gerät und Tag begrenzt, und die Grenze wird im Ledger durchgesetzt und nicht in einer Planungsoberfläche; die Policy kann einen Kandidaten mit device_over_daily_ceiling ablehnen, und die Ablehnung selbst wird als Eintrag erfasst.
Zwei Ebenen und warum die Chain nicht in der Inhalts-Ebene liegt
Eine Vorwärtsberechnung erneut auszuführen braucht keinen Konsens. Fremde dafür zu bezahlen schon. Also reisen Prompts und Completions auf einer Inhalts-Ebene ganz ohne Chain, und Gutschriften auf einer Abrechnungs-Ebene mit genau einer betreibergesteuerten Chain. Der Chain-Adapter hat eine lokale Variante im selben Prozess und optional eine HTTP-Variante; Standard ist lokal.
Die Chain ist append-only und nullifier-basiert: Dieselbe Job-ID ein zweites Mal zu erfassen liefert already_recorded. Das Verankern schreibt einen Digest des kanonischen Ledger-Präfixes fest, sodass ein umgeschriebenes Präfix erkennbar ist. Jede Methode liefert ein Ergebnis mit ausdrücklichem Erfolgsflag, sodass ein fehlgeschlagenes Schreiben nicht für ein gespeichertes gehalten werden kann, und ein nicht erfasster Verdienst wird als solcher gemeldet. Es gibt keine Wiederholungswarteschlange und keinen Offline-Abgleich: Eine nicht erreichbare Chain ist eine ehrliche Verweigerung, und der Job bleibt unabgerechnet.
Warum nicht übertragbar, und was das nicht ist
Die Position des Projekts ist, dass ein handelbares Reward-Token ein reguliertes Instrument ist, während eine nicht übertragbare Nutzungsgutschrift ein Loyalitätsmechanismus ist, und dass dies eine rechtliche Risikoposition und keine Rechtsberatung ist. Eine Prüfung durch qualifizierte Anwälte geht jeder Änderung daran voraus. Die Grenze wird also vorab benannt: keine Bereitstellung einer öffentlichen Chain, kein Token-Verkauf und keine Auszahlung. Was ein Gerät verdient, kauft hier Inferenz und sonst nichts. Die Spezifikation sagt außerdem ausdrücklich, dass die Beträge so gesetzt sind, dass der Mechanismus testbar ist, und nicht so, dass sie wirtschaftlich endgültig wären.
Wo sich das nachprüfen lässt
Der unten zitierte Leitfaden ist die Quelle, die die Zeilen der Modellregistry für jede hier wiederholte Modelltatsache nennen. Er ist nicht die Quelle der Abrechnungsregeln selbst: Dieses Projekt dokumentiert sie in docs/07-swarm-v1-spec.md, docs/08-credits-and-chain.md und src/verify.ts im Repository llmeuchain, das selbst gehostet wird und kein öffentliches Remote hat, auf das man verlinken könnte.
Quellen
Jeder Link führt zu der Quelle, die der Beitrag nennt. Wo eine Quelle eine Angabe nicht hergibt, zeigt der Beitrag sie als unverified, statt sie zu füllen.