Zum Inhalt springen

Vertrag04 von 04

Welche Felder machen einen Eintrag prüfbar?

Protokolleintrag: Inhalt und Prüfwert

Thema
KALKÜL
Lesezeit
1 Min.
Erstfassung
Stand
Bauplan
Auf dieser Seite
  1. 01Ein geplanter Vertrag, kein erreichbarer Endpunkt
  2. 02Gleicher Inhalt braucht gleiche Bytes
  3. 03Die Kette in Reihenfolge prüfen
  4. 04Die externe Abschrift ist eine eigene Schicht
  5. 05Schema
  6. 06Felder
  7. 07Fehlerfälle
  8. 08Grenze und Regel
  9. 09Verwandte Seiten

Ein Protokolleintrag verbindet eine beschriebene Handlung mit ihrem Ergebnis und dem Prüfwert des vorigen Eintrags. Diese geplante Referenz trennt lesbare Ereignisdaten, eindeutige Serialisierung und unabhängig zu sichernde Vergleichswerte.

Ein geplanter Vertrag, kein erreichbarer Endpunkt

Die Felder beschreiben eine prüfbare Entwurfsrichtung. Es gibt hier keinen zugesagten HTTP-Endpunkt, keine SDK-Methode und keine Kompatibilitätsgarantie. Vor einer Implementierung müssen Authentifizierung, Grenzwerte, Serialisierung und Fehlertransport festgelegt und getestet werden.

Gleicher Inhalt braucht gleiche Bytes

JSON erlaubt unterschiedliche Schlüsselreihenfolgen und Darstellungen. Ein reproduzierbarer Prüfwert setzt eine exakt beschriebene Bytefolge voraus. Änderungen an Normalisierung, Zeichensatz oder Zahlenformat sind Vertragsänderungen. Die Spezifikation muss passende Testvektoren liefern.

Die Kette in Reihenfolge prüfen

Die Prüfung beginnt bei einem bekannten Startpunkt. Für jeden Eintrag werden Vorgänger und Prüfwert nachgerechnet. Beim ersten Unterschied stoppt die bestätigte Strecke. Ein nachfolgender Eintrag kann nicht isoliert die Integrität der fehlenden Strecke beweisen.

Die externe Abschrift ist eine eigene Schicht

Wer alle Einträge und alle Prüfwerte ersetzen kann, kann eine in sich stimmige neue Kette schreiben. Ein unabhängig aufbewahrter Vergleichswert begrenzt diesen Angriff. Er ist im vorhandenen Prototyp ausdrücklich noch nicht umgesetzt. Eine Hashkette beweist außerdem nicht die Wahrheit einer ursprünglichen Eingabe.

Schema

{
  "id": "<eintrag-kennung>",
  "sequence": <reihenfolge>,
  "timestamp": "<zeitpunkt>",
  "actorRef": "<identitaet>",
  "actionRef": "<handlung-kennung>",
  "outcome": "succeeded",
  "payload": {
    "targetId": "<objekt-kennung>",
    "newVersion": <version>
  },
  "previousHash": "<pruefwert-des-vorgaengers>",
  "hash": "<pruefwert-aus-vorgaenger-und-nutzlast>",
  "schemaVersion": "<schemafassung>"
}
Schema 1JSON · Schema mit Platzhaltern

Felder

FeldTypPflichtBedeutung
idstringjaEindeutige Eintragskennung.
sequenceintegerjaReihenfolge innerhalb genau eines Protokollstroms.
timestampstring (date-time)jaErfasste Zeit; ihre Vertrauenswürdigkeit braucht eine eigene Zeitquelle.
actorRefstringjaKontext der handelnden Identität.
actionRefstringjaReferenz auf den zugehörigen Handlungsversuch.
outcomeenumjasucceeded, failed oder uncertain.
payloadobjectjaMinimal nötiger Prüfkontext ohne Geheimnisse.
previousHashstringjaPrüfwert des direkten Vorgängers oder definierter Startwert.
hashstringjaPrüfwert aus Vorgänger und kanonischer Nutzlast.
schemaVersionstringjaFassung des Eintragsschemas und der Serialisierungsregel.

Fehlerfälle

KennungBedeutung
CHAIN_PREDECESSOR_MISMATCHDer Vorgänger stimmt nicht mit dem vorigen geprüften Eintrag überein.
ENTRY_HASH_MISMATCHDer nachgerechnete Prüfwert stimmt nicht.
SEQUENCE_GAPIn der angegebenen Reihenfolge fehlt mindestens ein Eintrag.
ANCHOR_UNAVAILABLEEin unabhängiger Vergleichswert steht nicht zur Verfügung.

Grenze

Grenze
Dieser Schnittstellenvertrag ist geplant. Ein lokaler Kontrollprototyp belegt weder eine veröffentlichte API noch organisationsweiten Betrieb.

Verwandte Seiten