Ein Bruder hat mich gefragt: Er habe im Testnetz von OpenLedger eine ganze Ladung Daten beigesteuert. Später bekam sein Wallet dann eine kleine Zahlung. Nicht viel—vielleicht genug, um einen Americano zu kaufen. Er möchte herausfinden, welcher konkrete Modellaufruf diese Zahlung betrifft und welche Daten tatsächlich eine Rolle gespielt haben. Er hat alles in den Browser-Verlaufen durchforstet, aber keine Antwort gefunden. On-chain wird nur eine Sammel-Abbuchung mit einer einzigen Hash angezeigt, die mehrere Tausend Zuweisungen/Attributionen enthält. Das lässt sich praktisch nicht auseinanderdividieren.
Ich sagte ihm: Diese Verwirrung ist wirklich sehr nachvollziehbar. Die Attribution und Aufteilung der Beträge kann in der Mathematik bis auf sehr viele Dezimalstellen exakt sein—aber dieses exakte Buchwerk ist nicht für dich persönlich zugänglich. Du kannst das Ergebnis sehen, aber nicht den Prozess. Das ist wie im Mensa essen: Am Monatsende wird dir gesagt, dass du insgesamt 800 Yuan ausgegeben hast, aber es wird dir nicht gesagt, welches Essen zu welchem Gericht gehörte. Du weißt, dass die Summe stimmt, aber du willst trotzdem wissen, wie viel diese eine Schüssel mit gebratenem Schweinefleisch wirklich gekostet hat.
Das führt zu einer sehr schlichten Frage. Das Mechanismus-Setup namens Proof of Attribution: Attribution wird zugewiesen, aber wie kann ein Beitragsleistender verifizieren, dass seine eigenen Daten wirklich in die Berechnung eingeflossen sind? On-chain wird nur das aggregierte Ergebnis gespeichert, aber nicht die Details jeder einzelnen Mikro-Attribution. Es ist nicht so, dass das Projekt es nicht speichern möchte, sondern es schlicht nicht möglich ist. Wenn man die Attributions-Details für mehrere Dutzend Millionen Aufrufe komplett on-chain stellt, würde die Blockgröße explodieren und Gas wäre weg. Deshalb muss man engineering-seitig komprimieren: nur das Gesamtsaldo behalten und den Durchlauf verwerfen.
Diese Abwägung ist zwar sinnvoll, aber sie verändert das Vertrauensmodell. Ohne Details kannst du nur darauf vertrauen, dass das System korrekt rechnet, und du kannst es nicht selbst noch einmal nachprüfen. Das widerspricht dem ursprünglichen Ziel der Blockchain, nämlich „ohne Vertrauen auszukommen“. Du kannst sagen, dass es eine gemeinsame Schwierigkeit aller Micro-Attribution-Systeme in der aktuellen Phase ist, aber eine Schwierigkeit bleibt eine Schwierigkeit und sollte nicht als „jede einzelne Beitragsleistung ist eindeutig sichtbar“ verpackt werden.
@OpenLedger Kann man dieses Problem lösen? Ich glaube, man kann es in zwei Schritte aufteilen. Erstens: einen On-Chain-unabhängigen Dienst für Attribution-Abfragen anbieten. Die Details werden nicht in die Blockchain geschrieben, aber Beitragsleistende können über eine Schnittstelle nachsehen, wie oft ihre eigenen Daten aufgerufen wurden und wie hoch der Auszahlungsbetrag ist. Die Daten sind nicht on-chain, aber du kannst die Details zumindest sehen. Mit dem Taschenrechner rechnest du selbst nach und prüfst, ob es mit dem Gesamtstand auf der Blockchain übereinstimmt. Zweitens: die Zusammenfassung dieses Abfragedienstes regelmäßig als Hash on-chain verankern, um sicherzustellen, dass die Abfrageergebnisse nicht manipuliert wurden. So spart man Gas und gibt Beitragsleistenden dennoch ein Verifikationsmittel.
In dem aktuellen Whitepaper ist diese Design-Variante nicht explizit beschrieben, aber ich hoffe, dass sie bereits auf dem Weg ist. Ohne Details ist Attribution wie ein Supermarkt, der keine Belege ausgibt: Du musst darauf vertrauen, dass er die Rechnung korrekt berechnet hat.
Lass uns auch OpenLoRA betrachten. Das Pay-per-Use-Modell bringt von Natur aus schon Details mit. Bei jedem Modellaufruf zeichnet das System eine Zeile auf, und die Rechnung, die du am Monatsende bekommst, hat Positionen. Wenn man sich bei der Attribution-Aufteilung diese Idee ausleiht und den Aufruf mit der Attribution verknüpft, können Beitragsleistende über die Call-ID zurückverfolgen, wie groß ihr Beitrag tatsächlich war. Technisch ist das nicht unmöglich, aber es geht um Rechen- und Speicher- Kosten. Die Richtung ist jedoch richtig.
Ich schaue mir normalerweise auch die Kursentwicklung von Bitcoin und Ethereum an. Dass diese beiden Ketten überhaupt laufen können, liegt daran, dass jede Person jede einzelne Transaktion verifizieren kann. Die Verifikationsbefugnis ist an jeden einzelnen Knoten delegiert, sodass man keinen Mittelsmann vertrauen muss.#OpenLedger Wenn man im KI-Zeitalter eine Value-Settlement-Layer bauen will, muss man sich den gleichen Standards stellen. Die Detailinformationen der Attribution müssen nicht vollständig on-chain sein, aber die Verifikationsmöglichkeit muss jedem gegeben werden.
$OPEN In dem Wert, den es gibt, ist ein Teil genau auf dieses Problem fokussiert. Wenn Beitragsleistende für immer nur passiv die Abrechnungsergebnisse empfangen können und nicht selbst nachprüfen, dann fehlt diesem System ein entscheidender Dreh- und Angelpunkt für seine Glaubwürdigkeit.
Ich glaube, dass das Projektteam dieses Problem versteht. Ich hoffe, dass es beim nächsten Update ein Tool zu sehen gibt, mit dem normale Menschen die Details prüfen können, ohne dass man Merkle-Bäume kennen muss, ohne Knoten zu betreiben—ein paar Klicks, und man sieht, wie viel Geld man mit seinen eigenen Daten verdient hat. Erst dann ist PoA wirklich ein geschlossener Kreislauf. #