Alpha日报
Nächsten Montag gibt es wieder ein neues Coin-Airdrop: #ARX !
Booster-Aktivität läuft, -2 Punkte.
Der Airdrop von letzter Woche (2 Coins) hat aktuell einen Wert von 600u!
Vor ein paar Tagen habe ich extra auf explorer.opengradient.ai eine echte TEE-Inferenz-Abrechnungsaufzeichnung zwei Stunden lang auseinandergebaut, um herauszufinden, was dieses attestation-Element genau beweist. „Verifizierbare KI-Inferenz“ wird überall herumposaunt, aber ich habe noch nicht oft gesehen, dass jemand wirklich klar erklären kann, welche logischen Ebenen hinter dieser Kette von Hashes auf der On-Chain steckt.
Die gesamte Abfolge verläuft eigentlich in zwei Zeitleisten. Sobald der Nutzer eine Anfrage stellt, liefert der TEE-Knoten in nahezu Sekunden ein Ergebnis – die Latenz ist praktisch identisch mit einer zentralisierten API; die Blockchain liegt überhaupt nicht in diesem schnellen Pfad. Die eigentliche Verifikation wird asynchron erledigt: Der Inferenzknoten erzeugt innerhalb der Hardware-Enklave ein attestation, packt dann den Hash des Signaturschlüssels zusammen mit dem Hash des TLS-Zertifikats in das Feld user_data und reicht es anschließend bei allen Knoten ein. Im CometBFT-Konsenszyklus wird es mit den PCR-Werten aus der On-Chain TEE-Registry abgeglichen. PCR0, PCR1 und PCR2 sind die „Hardware-Fingerabdrücke“ des Enklaven-Codes – wenn der Abgleich durchgeht, bedeutet das, dass diese Maschine den unveränderten, freigegebenen Code ausführt; selbst der Betreiber des Knotens kann nicht an den Inhalt herankommen.
Auf dem Explorer kann man die Abrechnungsaufzeichnung direkt nachschlagen: verification.method zeigt TEE an, das proof-Feld hängt den Beweis-Hash, und verified_by bestätigt das Ergebnis der netzwerkweiten Konsensabsicherung.
Aber es gibt eine Design-Details, auf das ich schon lange fixiert bin. Der Standard-Abrechnungsmodus BATCH_HASHED aggregiert mehrere Inferenzanfragen zu einem Merkle-Baum und schreibt sie gebündelt on-chain. In diesem Modus wird die Signatur einer einzelnen Inferenz nicht separat on-chain verifiziert. Um die vollständige Audit-Kette für eine einzelne Inferenz zu erhalten, muss man manuell auf INDIVIDUAL_FULL umschalten – allerdings mit höheren Gas-Kosten. Das ist eine nachvollziehbare wirtschaftliche Abwägung, aber für Entwickler, die die TEE-Inferenzergebnisse direkt an risikoreiche Finanz-Smart-Contracts verfüttern, ist das eine Falle, die man unbedingt im Voraus kennen muss: Das Vertrauensniveau im Standardmodus ist nicht vollständig so, wie man es sich vorstellt.
Der PCR-Abgleichsmechanismus ist derzeit einer der am solideesten ausgearbeiteten Teile für verifizierbare KI-Inferenz on-chain. Die Untergrenze des Vertrauensmodells ist damit bereits festgelegt. Als Nächstes werde ich besonders auf den tatsächlichen Anteil der Aufrufe im Mainnet-Modus achten – nur diese Zahl kann zeigen, ob Entwickler wirklich für „Verifizierbarkeit“ bezahlen, oder ob sie nur den billigsten Modus nutzen, um Buchungen abzuwickeln.
#opg @OpenGradient $OPG
Nächsten Montag gibt es wieder ein neues Coin-Airdrop: #ARX !
Booster-Aktivität läuft, -2 Punkte.
Der Airdrop von letzter Woche (2 Coins) hat aktuell einen Wert von 600u!
Vor ein paar Tagen habe ich extra auf explorer.opengradient.ai eine echte TEE-Inferenz-Abrechnungsaufzeichnung zwei Stunden lang auseinandergebaut, um herauszufinden, was dieses attestation-Element genau beweist. „Verifizierbare KI-Inferenz“ wird überall herumposaunt, aber ich habe noch nicht oft gesehen, dass jemand wirklich klar erklären kann, welche logischen Ebenen hinter dieser Kette von Hashes auf der On-Chain steckt.
Die gesamte Abfolge verläuft eigentlich in zwei Zeitleisten. Sobald der Nutzer eine Anfrage stellt, liefert der TEE-Knoten in nahezu Sekunden ein Ergebnis – die Latenz ist praktisch identisch mit einer zentralisierten API; die Blockchain liegt überhaupt nicht in diesem schnellen Pfad. Die eigentliche Verifikation wird asynchron erledigt: Der Inferenzknoten erzeugt innerhalb der Hardware-Enklave ein attestation, packt dann den Hash des Signaturschlüssels zusammen mit dem Hash des TLS-Zertifikats in das Feld user_data und reicht es anschließend bei allen Knoten ein. Im CometBFT-Konsenszyklus wird es mit den PCR-Werten aus der On-Chain TEE-Registry abgeglichen. PCR0, PCR1 und PCR2 sind die „Hardware-Fingerabdrücke“ des Enklaven-Codes – wenn der Abgleich durchgeht, bedeutet das, dass diese Maschine den unveränderten, freigegebenen Code ausführt; selbst der Betreiber des Knotens kann nicht an den Inhalt herankommen.
Auf dem Explorer kann man die Abrechnungsaufzeichnung direkt nachschlagen: verification.method zeigt TEE an, das proof-Feld hängt den Beweis-Hash, und verified_by bestätigt das Ergebnis der netzwerkweiten Konsensabsicherung.
Aber es gibt eine Design-Details, auf das ich schon lange fixiert bin. Der Standard-Abrechnungsmodus BATCH_HASHED aggregiert mehrere Inferenzanfragen zu einem Merkle-Baum und schreibt sie gebündelt on-chain. In diesem Modus wird die Signatur einer einzelnen Inferenz nicht separat on-chain verifiziert. Um die vollständige Audit-Kette für eine einzelne Inferenz zu erhalten, muss man manuell auf INDIVIDUAL_FULL umschalten – allerdings mit höheren Gas-Kosten. Das ist eine nachvollziehbare wirtschaftliche Abwägung, aber für Entwickler, die die TEE-Inferenzergebnisse direkt an risikoreiche Finanz-Smart-Contracts verfüttern, ist das eine Falle, die man unbedingt im Voraus kennen muss: Das Vertrauensniveau im Standardmodus ist nicht vollständig so, wie man es sich vorstellt.
Der PCR-Abgleichsmechanismus ist derzeit einer der am solideesten ausgearbeiteten Teile für verifizierbare KI-Inferenz on-chain. Die Untergrenze des Vertrauensmodells ist damit bereits festgelegt. Als Nächstes werde ich besonders auf den tatsächlichen Anteil der Aufrufe im Mainnet-Modus achten – nur diese Zahl kann zeigen, ob Entwickler wirklich für „Verifizierbarkeit“ bezahlen, oder ob sie nur den billigsten Modus nutzen, um Buchungen abzuwickeln.
#opg @OpenGradient $OPG