Koch Laboratory

Zeit als vereinbarte Einheit und als Beweis

Sechs Richtungen zu einem Zeitdienst, dessen Angabe für jemanden tragen soll, der weder uns noch unserem Server traut: eine zonenfreie Einheit, eine Uhr, die ohne Serveranfrage tickt und ihren eigenen Fehler veröffentlicht, ein wöchentliches Merkle-Log, Verankerung im Verwendungszweck einer Überweisung neben Bitcoin, eine nicht steuerbare Auslosung und der Beweis gemeinsamer Stempelung ohne Identität.

Koch Laboratory — Zeit als vereinbarte Einheit und als Beweis

Diese Richtung begann mit einer praktischen Frage: Warum verlangt die Verständigung über einen einzigen Zeitpunkt zwischen zwei Personen in verschiedenen Zeitzonen eine Übersetzung statt einer Ablesung? Sie endete bei einer schwierigeren Frage: Was muss ein Zeitdienst sein, damit seine Angabe Beweiswert für jemanden hat, der weder uns noch unserem Server vertraut?

Methodik. Wie im übrigen Labor: Problem → Hypothese → falsifizierbares Kriterium → Methode → Ergebnis mit Randbedingungen. Der Status ist offen ausgewiesen: „umgesetzt” heißt unter einer öffentlichen Adresse in Betrieb, „Projektarbeit” heißt ohne Messergebnis.

1. Richtung 1 — eine Zeiteinheit, die ohne Kontext aussprechbar ist

Forschungsfrage. Lässt sich ein Zeitpunkt so angeben, dass der Empfänger weder die Zone des Absenders noch die eigene kennen muss — ohne die Umkehrbarkeit gegenüber UTC zu verlieren? Warum schwierig. Zeitzonen sind keine Funktion der Geografie, sondern politischer Entscheidungen: Sie ändern sich von Jahr zu Jahr, enthalten halbstündige und saisonale Versätze, und die Regelbasis ist beweglich. Jede lokale Notation braucht daher zusätzlichen Zustand, um verstanden zu werden — und dieser Zustand ist mitunter veraltet. Stand der Technik (veröffentlicht). ISO 8601 und UTC (korrekt, aber Umrechnung beim Empfänger); Swatch Internet Time von 1998 — zonenfreie Einheit, jedoch in BMT verankert (UTC+1, Firmensitz) und ohne offene Schnittstelle; TAI und Unixzeit als technische Grundlagen, nicht zum Aussprechen gedacht. Erfolgskriterium. Umkehrbare, testgedeckte Konvertierung UTC↔Einheit ohne jede Abhängigkeit von einer Zonendatenbank; die Einheit grob genug, um im Gespräch ausgesprochen zu werden (1/1000 Tag = 86,4 s), und fein genug für eine Verabredung auf die Minute. Ergebnis. Im Rahmen des Kriteriums bestätigt: Verankerung in UTC/Greenwich statt BMT, offene API (now, convert, sync, health), Konvertierungskern als reines, getestetes Modul. Randbedingung: Die Einheit ersetzt ISO 8601 in maschinellen Datensätzen nicht — sie ist eine aussprechbare Schicht, kein Speicherformat. Status: umgesetzt.

2. Richtung 2 — eine Uhr, die ohne Serveranfrage tickt

Forschungsfrage. Kann eine öffentliche Uhr im Betrieb ohne Netzverkehr auskommen — also ohne Telemetrie und ohne Skalierungskosten — und dabei für die gewählte Einheit hinreichend genau bleiben? Warum schwierig. Eine Uhr, die pro Tick den Server fragt, ist zugleich ein Besucherzähler: Jeder Tick hinterlässt eine IP-Adresse in einem fremden Log. Eine rein lokal gerechnete Uhr erbt dagegen den Fehler der Geräteuhr, die wir weder kontrollieren noch kennen. Stand der Technik (veröffentlicht). SNTP/NTP als Modell einmaliger Offset-Synchronisierung; Web-Uhren, die typischerweise zyklisch den Server abfragen. Erfolgskriterium. Null Netzanfragen nach dem Start; ausgewiesene Messung und Veröffentlichung des eigenen Fehlers statt stiller Korrektheitsannahme. Ergebnis. Bestätigt: Der Client holt den Offset einmal und tickt lokal (SNTP-Modell), auch offline. Zusätzlich misst eine periodische Aufgabe die Abweichung der Hostuhr gegenüber NTP und weist sie in /api/health aus — ein Zeitdienst, der seinen eigenen Fehler veröffentlicht, statt ihn zu verschweigen. Randbedingung: Die clientseitige Genauigkeit bleibt durch die Geräteuhr begrenzt; für eine Einheit von 86,4 s ist das unerheblich, für Beweiszwecke nicht — deshalb stützt sich der Zeitbeweis (Richtung 3) nie auf die Uhr des Clients. Status: umgesetzt.

3. Richtung 3 — ein öffentliches Stempel-Log: Existenz ohne Offenlegung des Inhalts

Forschungsfrage. Lässt sich nachweisen, dass ein Dokument in einer bestimmten Woche existierte — ohne seinen Inhalt offenzulegen und ohne dem Betreiber des Dienstes zu vertrauen? Warum schwierig. Ein Betreiber, der rückwirkend eintragen kann, taugt nicht als Zeuge — und seine eigene Signatur schließt das nicht aus. Das Log muss also zeitlich geschlossen und von jemandem prüfbar sein, der keinen Datenbankzugriff hat; zugleich darf keine Prüfung die Vorlage des Dokuments verlangen. Stand der Technik (veröffentlicht). RFC 3161 (TSA — Glaubwürdigkeit auf das Vertrauen in die Stelle reduziert), Certificate Transparency (Merkle-Bäume mit Inklusionsbeweisen), OpenTimestamps. Erfolgskriterium. Erfasst wird ausschließlich SHA-256; die Wochenwurzel wird nach Ablauf der Woche eingefroren und mit Ed25519 signiert; für jeden Hash ist ein Inklusionspfad rekonstruierbar, prüfbar ohne Systemzugang. Ergebnis. Bestätigt: wöchentlicher Merkle-Baum, eingefrorene Wurzel nach Wochenabschluss, Ed25519-Signatur, Inklusionspfad je Digest, Deduplikation als „erstmals gesehen”. Randbedingung: Die Beweisgranularität ist die Woche — der Dienst belegt „nicht später als”, nicht „genau um”. Status: umgesetzt.

4. Richtung 4 — Verankerung in einem Register, das der Betreiber nicht kontrolliert

Forschungsfrage. Womit verankert man die Wochenwurzel, damit der Beweis den Verlust des Vertrauens in den Dienst übersteht — und nicht von einer einzigen, von uns gewählten technischen Welt abhängt? Warum schwierig. Der Anker muss in ein Register gelangen, das von Dritten datiert wird, gegen rückwirkende Änderung resistent, günstig und über Jahre wöchentlich wiederholbar ist. Eine Blockchain erfüllt die ersten drei Bedingungen, schafft aber eine Abhängigkeit von einem Ökosystem und dessen Kosten; die Veröffentlichung in der Presse (die klassische Surety-Lösung der 1990er) ist teuer und schwer zu automatisieren. Stand der Technik (veröffentlicht). OpenTimestamps mit Verankerung in Bitcoin; historische Hash-Veröffentlichungen in Zeitungsanzeigen; kommerzielle Zeitstempeldienste. Erfolgskriterium. Mindestens zwei unabhängige Ankerkanäle, von denen keiner vom Betreiber kontrolliert wird und jeder für sich prüfbar ist. Ergebnis. Bestätigt: Der erste Kanal ist OpenTimestamps. Der zweite Kanal ist der Verwendungszweck einer Banküberweisung — die Wochenwurzel als MROOT <JAHRWnn> <8 Gruppen zu 8 Hexzeichen> (85 Zeichen, passt in das auf 140 Zeichen begrenzte Feld), gebucht von einem regulierten Institut, das eine eigene, von uns unabhängige Zeitführung betreibt und keinen Anlass hat, sie für uns zu ändern. Randbedingung: Der Bankkanal hat Buchungsgranularität (Werktage) und verlangt eine manuelle Bestätigung der Referenz; er ist günstig und vollständig unabhängig von Kryptowährungen, aber nicht sofortig. Status: umgesetzt.

5. Richtung 5 — eine Auslosung, die niemand kontrolliert, wir eingeschlossen

Forschungsfrage. Lässt sich ein öffentlicher Zufallswert aus Material ableiten, das der Betreiber nicht auf ein vorab festgelegtes Ergebnis hin auswählen kann? Warum schwierig. Jede serverseitige Auslosung ist unprüfbar, und jede „Auslosung aus einem Seed” ist steuerbar, wenn den Seed derjenige wählt, der das Ergebnis verkündet. Commit-Reveal-Verfahren verlangen Disziplin und eine weitere Vertrauensrunde. Stand der Technik (veröffentlicht). Öffentliche Randomness Beacons (u. a. drand, NIST-Beacon), Commit-Reveal-Schemata, Ableitung von Zufall aus Blockheadern. Erfolgskriterium. Das Ergebnis ist von jedermann aus bereits veröffentlichtem und bereits signiertem Material nachrechenbar, ohne jeden serverseitigen Zustand. Ergebnis. Teilweise — und das ist ein veröffentlichenswertes Ergebnis. Der Tageswert ist eine Funktion der Wurzel der letzten abgeschlossenen Woche und des Datums (beattime-thebeat-v1|<Wurzel>|<Datum>, SHA-256, erste 6 Bytes mod 1000). Erreicht sind Nichtsteuerbarkeit und vollständige Prüfbarkeit: Der Betreiber kann das Ergebnis nicht wählen, weil die Wurzel eingefroren und signiert war, bevor das Datum feststand. Nicht erreicht ist Unvorhersagbarkeit — die Wurzel ist öffentlich, jeder kann die Werte der kommenden Woche im Voraus berechnen. Wir sagen das ausdrücklich, weil die Verwechslung dieser beiden Eigenschaften der häufigste Fehler dieser Lösungsklasse ist. Status: umgesetzt, mit ausdrücklich begrenzter Eigenschaft.

6. Richtung 6 — Beweis der gemeinsamen Stempelung ohne Identität der Beteiligten

Forschungsfrage. Können zwei Personen einen Zeitpunkt gemeinsam festhalten, sodass der Beweis öffentlich prüfbar ist und der Dienst nicht erfährt, wer sie sind? Warum schwierig. Die naheliegenden Lösungen (Konten, Rufnummern, Kontaktlisten) lösen das Identitätsproblem, indem sie es dem Betreiber übertragen — und erzeugen genau das Register, das vermieden werden soll. Ohne Identität entfällt allerdings die Verknüpfbarkeit: „dieselbe Person zum fünften Mal” ist nicht mehr von fünf Fremden zu unterscheiden. Stand der Technik (veröffentlicht). Näherungsbeweise (BLE, Ton), Ed25519-Signaturen, C2PA als Standard für Herkunftsnachweise. Erfolgskriterium. Der Dienst speichert ausschließlich zwei Zufallssalze und den resultierenden Hash; keine Seite konnte den Hash vor der Begegnung allein erzeugen; die Schlüsselkontinuität ersetzt den Namen. Ergebnis. Bestätigt: Der Hash entsteht aus beiden Salzen und der vom Server vergebenen Zeit; Version v2 bindet zusätzlich die rohen öffentlichen Schlüssel beider Seiten ein, und der Schlüsselbesitz wird per Signatur nachgewiesen. Beschreibungen („mit wem”) existieren nur auf den Telefonen. Ausdrücklich benannte Grenze: Der Beweis zeigt, dass zwei Seiten denselben Zeitpunkt gemeinsam gestempelt haben — er zeigt keine physische Nähe; dasselbe Protokoll lässt sich aus der Ferne ausführen und ist so zu lesen. Status: umgesetzt (v1 und v2).

Status der Richtung. Zeitkern, öffentliches Log, Verankerung und Ko-Stempel-Protokoll sind öffentlich in Betrieb; die Anwendungsschichten (Android, Wear, Erweiterung, SDK) befinden sich im Aufbau. Nächster Forschungsschritt: Herkunftsnachweise für Inhalte (C2PA) als Schicht über dem bestehenden Log — als Schicht ergänzt, nie als Fundament.