Czas jako uzgodniona jednostka i jako dowód
Sześć kierunków wokół usługi czasu, której wskazanie ma się bronić przed kimś, kto nie ufa ani nam, ani naszemu serwerowi: jednostka bez stref, zegar tykający bez pytania serwera i publikujący własny błąd, tygodniowy log Merkle, kotwica w tytule przelewu obok Bitcoina, losowanie, którego nikt nie steruje, oraz dowód współstemplowania chwili bez tożsamości stron.
Koch Laboratory — czas jako uzgodniona jednostka i jako dowód
Ten kierunek zaczął się od pytania praktycznego: dlaczego uzgodnienie jednej chwili między dwiema osobami w różnych strefach czasowych wymaga tłumaczenia, a nie odczytania. Skończył się na pytaniu trudniejszym: czym musi być usługa czasu, żeby jej wskazanie miało wartość dowodową dla kogoś, kto nie ufa ani nam, ani naszemu serwerowi.
Metodyka. Jak w reszcie laboratorium: problem → hipoteza → falsyfikowalne kryterium → metoda → wynik z warunkami brzegowymi. Statusy są jawne: „wdrożone” znaczy działające pod publicznym adresem, „prace projektowe” znaczy brak wyniku pomiarowego.
1. Kierunek 1 — jednostka czasu, którą da się wypowiedzieć bez kontekstu
Pytanie badawcze. Czy da się podać chwilę tak, aby odbiorca nie musiał znać ani strefy nadawcy, ani własnej — bez utraty odwracalności względem UTC?
Dlaczego to trudne. Strefy czasowe nie są funkcją geografii, tylko decyzji politycznych: zmieniają się z roku na rok, obejmują przesunięcia półgodzinne i sezonowe, a baza reguł jest ruchoma. Każda notacja lokalna wymaga więc dodatkowego stanu, żeby ją zrozumieć — a stan bywa nieaktualny.
Stan techniki (publikowany). ISO 8601 i UTC (poprawne, ale wymagają przeliczenia po stronie odbiorcy); Swatch Internet Time z 1998 — jednostka bez stref, ale zakotwiczona w BMT (UTC+1, czas siedziby firmy) i bez otwartego interfejsu; TAI i czas uniksowy jako podstawy techniczne, nieprzeznaczone do wypowiadania.
Kryterium sukcesu. Konwersja UTC↔jednostka odwracalna, pokryta testami, bez jakiejkolwiek zależności od bazy stref; jednostka na tyle gruba, by wypowiedzieć ją w rozmowie (1/1000 doby = 86,4 s), i na tyle precyzyjna, by umówić się co do minuty.
Wynik. Potwierdzony w zakresie kryterium: kotwica w UTC/Greenwich zamiast BMT, otwarte API (now, convert, sync, health), rdzeń konwersji jako czysty, otestowany moduł. Warunek brzegowy: jednostka nie zastępuje ISO 8601 w rekordach maszynowych — jest warstwą wypowiadalną, nie formatem zapisu.
Status: wdrożone.
2. Kierunek 2 — zegar, który tyka bez pytania serwera
Pytanie badawcze. Czy publiczny zegar może działać bez ruchu sieciowego w trakcie działania — a więc bez telemetrii i bez kosztu skalowania — zachowując dokładność wystarczającą dla przyjętej jednostki?
Dlaczego to trudne. Zegar odpytujący serwer co tyknięcie jest jednocześnie licznikiem odwiedzin: każde tyknięcie zostawia adres IP w cudzym logu. Zegar liczony wyłącznie lokalnie dziedziczy natomiast błąd zegara urządzenia, którego nie kontrolujemy i o którym nic nie wiemy.
Stan techniki (publikowany). SNTP/NTP jako model jednorazowej synchronizacji offsetu; zegary webowe zwykle odpytujące serwer cyklicznie.
Kryterium sukcesu. Zero zapytań sieciowych po starcie; jawny pomiar i publikacja własnego błędu zamiast milczącego założenia poprawności.
Wynik. Potwierdzony: klient pobiera offset raz i tyka lokalnie (model SNTP), działa offline. Do tego zadanie okresowe mierzy odchyłkę zegara hosta względem NTP i wystawia ją w /api/health — usługa czasu publikuje własny błąd, zamiast go ukrywać. Warunek brzegowy: dokładność po stronie klienta pozostaje ograniczona zegarem urządzenia; dla jednostki 86,4 s jest to nieistotne, dla zastosowań dowodowych — nie, i dlatego dowód czasu (kierunek 3) nigdy nie opiera się na zegarze klienta.
Status: wdrożone.
3. Kierunek 3 — publiczny log stempli: istnienie bez ujawniania treści
Pytanie badawcze. Czy da się wykazać, że dany dokument istniał w danym tygodniu, bez ujawniania jego treści i bez zaufania do operatora usługi? Dlaczego to trudne. Operator, który może dopisać wpis wstecz, jest bezużyteczny jako świadek — a sam podpis operatora tego nie wyklucza. Log musi więc być zamknięty w czasie i weryfikowalny przez kogoś, kto nie ma dostępu do bazy; jednocześnie żadna weryfikacja nie może wymagać okazania dokumentu. Stan techniki (publikowany). RFC 3161 (TSA — wiarygodność sprowadzona do zaufania do urzędu), Certificate Transparency (drzewa Merkle z dowodami inkluzji), OpenTimestamps. Kryterium sukcesu. Rejestrowany jest wyłącznie SHA-256; korzeń tygodnia zamrażany po jego zakończeniu i podpisywany Ed25519; dla dowolnego skrótu odtwarzalna ścieżka inkluzji, sprawdzalna bez dostępu do systemu. Wynik. Potwierdzony: tygodniowe drzewo Merkle, zamrożenie korzenia po zamknięciu tygodnia, podpis Ed25519, ścieżka inkluzji per digest, deduplikacja jako „pierwsze widzenie”. Warunek brzegowy: ziarnistość dowodu to tydzień — usługa dowodzi „nie później niż”, nie „dokładnie o”. Status: wdrożone.
4. Kierunek 4 — kotwica w rejestrze, którego operator nie kontroluje
Pytanie badawcze. Czym zakotwiczyć korzeń tygodnia, żeby dowód przetrwał utratę zaufania do usługi — i żeby nie zależał od jednego, wybranego przez nas świata technicznego?
Dlaczego to trudne. Kotwica musi trafić do rejestru datowanego przez stronę trzecią, odpornego na wsteczną zmianę, taniego i powtarzalnego co tydzień przez lata. Blockchain spełnia trzy pierwsze warunki, ale wprowadza zależność od jednego ekosystemu i od jego kosztu; publikacja w prasie (klasyczne rozwiązanie Surety z lat 90.) jest droga i trudna do automatyzacji.
Stan techniki (publikowany). OpenTimestamps z zakotwiczeniem w Bitcoinie; historyczne publikowanie skrótów w ogłoszeniach prasowych; komercyjne urzędy znacznika czasu.
Kryterium sukcesu. Co najmniej dwa niezależne kanały kotwiczenia, z których żaden nie jest kontrolowany przez operatora usługi, a każdy weryfikowalny osobno.
Wynik. Potwierdzony: kanał pierwszy to OpenTimestamps. Kanałem drugim jest tytuł przelewu bankowego — korzeń tygodnia zapisany jako MROOT <ROKWnn> <8 grup po 8 znaków hex> (85 znaków, mieści się w polu tytułu o limicie 140), zaksięgowany przez instytucję regulowaną, która prowadzi własną, niezależną od nas ewidencję czasu i nie ma powodu jej dla nas zmieniać. Warunek brzegowy: kanał bankowy ma ziarnistość księgowania (dni robocze) i wymaga ręcznego potwierdzenia referencji; jest tani i całkowicie niezależny od kryptowalut, ale nie jest natychmiastowy.
Status: wdrożone.
5. Kierunek 5 — losowanie, którego nie kontroluje nikt, łącznie z nami
Pytanie badawcze. Czy da się wyprowadzić publiczną wartość losową z materiału, którego operator nie może dobrać pod z góry ustalony wynik?
Dlaczego to trudne. Każde losowanie po stronie serwera jest niesprawdzalne, a każde „losowanie z ziarna” jest sterowalne, jeśli ziarno wybiera ten, kto ogłasza wynik. Rozwiązania oparte na commit–reveal wymagają dyscypliny i kolejnej rundy zaufania.
Stan techniki (publikowany). Publiczne beacony losowości (m.in. drand, beacon NIST), schematy commit–reveal, wyprowadzanie losowości z nagłówków bloków.
Kryterium sukcesu. Wynik odtwarzalny przez każdego z materiału już opublikowanego i już podpisanego, bez żadnego stanu po stronie serwera.
Wynik. Częściowy — i to jest wynik wart opublikowania. Wartość dnia liczona jest jako funkcja korzenia ostatniego zamkniętego tygodnia i daty (beattime-thebeat-v1|<korzeń>|<data>, SHA-256, pierwsze 6 bajtów mod 1000). Uzyskana własność to niesterowalność i pełna weryfikowalność: operator nie może dobrać wyniku, bo korzeń był zamrożony i podpisany, zanim padła data. Uzyskaną własnością nie jest nieprzewidywalność — korzeń jest publiczny, więc każdy może policzyć wartości na cały nadchodzący tydzień z wyprzedzeniem. Deklarujemy to wprost, ponieważ mylenie tych dwóch własności jest najczęstszym błędem w tej klasie rozwiązań.
Status: wdrożone, z jawnie ograniczoną własnością.
6. Kierunek 6 — dowód współstemplowania chwili bez tożsamości stron
Pytanie badawcze. Czy dwie osoby mogą wspólnie utrwalić jedną chwilę tak, aby dowód był weryfikowalny publicznie, a usługa nie dowiedziała się, kim są? Dlaczego to trudne. Naturalne rozwiązania (konta, numery telefonów, listy kontaktów) rozwiązują problem tożsamości przez jego przeniesienie na operatora — i tworzą dokładnie ten rejestr, którego chcemy uniknąć. Bez tożsamości znika jednak wiązalność: nie da się odróżnić „ta sama osoba piąty raz” od pięciu obcych. Stan techniki (publikowany). Protokoły dowodu bliskości (BLE, dźwięk), podpisy Ed25519, C2PA jako standard poświadczania pochodzenia. Kryterium sukcesu. Usługa przechowuje wyłącznie dwie losowe sole i wynikowy skrót; żadna ze stron nie mogła wytworzyć skrótu samodzielnie przed spotkaniem; ciągłość klucza zastępuje imię. Wynik. Potwierdzony: skrót powstaje z obu soli i czasu nadanego przez serwer, wersja v2 wiąże go dodatkowo z surowymi kluczami publicznymi obu stron, a posiadanie kluczy jest dowodzone podpisem. Opisy „z kim” nie istnieją poza telefonami. Granica dowodu, podana wprost: dowód wykazuje, że dwie strony współstemplowały tę samą chwilę — nie wykazuje fizycznej bliskości; ten sam protokół można wykonać zdalnie i tak też należy go czytać. Status: wdrożone (v1 i v2).
Status kierunku. Rdzeń czasu, publiczny log, kotwiczenie i protokół współstemplowania działają publicznie; warstwy aplikacyjne (Android, wear, rozszerzenie, SDK) są w budowie. Najbliższy krok badawczy: poświadczanie pochodzenia treści (C2PA) jako warstwa nad istniejącym logiem — dokładana jako warstwa, nigdy jako fundament.