Większość systemów działa na podstawie założeń.
Zakładasz, że użytkownik jest uprawniony, ponieważ twoja baza danych tak mówi. Zakładasz, że transakcja przestrzegała zasad, ponieważ twój backend ją wykonał. Zakładasz, że poświadczenie jest prawdziwe, ponieważ pochodzi z "właściwego" źródła. I przez większość czasu to założenie się utrzymuje, aż przestaje.
Wtedy sprawy stają się niewygodne.
Ponieważ gdy coś pójdzie nie tak, zostajesz z wykopaniem logów, rekonstrukcją zdarzeń i próbą udowodnienia tego, co powinno być możliwe do udowodnienia od samego początku. To jest reaktywne, chaotyczne i często niejednoznaczne. System działał... ale nie możesz pokazać, że działał.
To jest luka, którą starają się wypełnić zaświadczenia.
W Sign, zaświadczenie nie jest tylko zapisem — to podpisana deklaracja związana z określoną strukturą. Ktoś (lub coś) wyraźnie mówi: "to jest prawda" i popiera to podpisem, który można zweryfikować niezależnie. Brzmi podstawowo, ale zmienia, jak działają systemy.
Już nie polegasz na wewnętrznym stanie jako źródle prawdy. Tworzysz przenośne, weryfikowalne oświadczenia, które mogą istnieć samodzielnie.
I to zmienia dynamikę dość mocno.
Po pierwsze, redukuje zależność od scentralizowanej kontroli. Jeśli roszczenie można zweryfikować bez zapytania do bazy danych, nie musisz być online — ani nawet zaufanym — aby inni mogli je zwalidować. Dowód istnieje poza twoim systemem. To subtelne, ale ważne oddzielenie.
To również sprawia, że systemy są bardziej kompozytowe.
Zaświadczenie wydane w jednym kontekście może być ponownie wykorzystane w innym bez reinterpretacji. Jeśli użytkownik już gdzieś udowodnił swoją uprawnienie, po co zmuszać go do powtarzania procesu? Dzięki zaświadczeniom, ten dowód może podróżować. Nie jako surowe dane, ale jako coś już zweryfikowanego i podpisanego.
Oczywiście, wprowadza to inny rodzaj odpowiedzialności.
Kto wydaje zaświadczenie? Jakie standardy są przestrzegane? Czy można im ufać? Zaświadczenia nie eliminują zaufania — czynią je explicite. Zamiast chować się za systemami, zaufanie jest przypisane do identyfikowalnych wydawców i widocznych zapisów.
I szczerze mówiąc, to lepsza oferta.
Ponieważ ukryte zaufanie to miejsce, gdzie zaczynają się większość problemów. Gdy nie wiesz, czemu ufać, ufasz albo wszystkiemu, albo niczemu — żadne z tych rozwiązań nie skaluje się dobrze. Zaświadczenia przynoszą tę decyzję na jaw. Możesz zbadać źródło, zweryfikować podpis i samodzielnie podjąć decyzję.
Jest również coś do powiedzenia na temat tego, jak to wpływa na projektowanie systemów.
Gdy wiesz, że każda ważna akcja może wymagać późniejszego udowodnienia, zaczynasz budować inaczej. Myślisz o tym, co powinno być rejestrowane, jak powinno być zorganizowane i kto powinien to podpisać. Dodaje to warstwę dyscypliny, której większości obecnych systemów brakuje.
Nie dlatego, że im nie zależy — ale dlatego, że nie zostały zbudowane z myślą o weryfikacji.
Sign nie wymusza doskonałości, ale popycha systemy w tym kierunku. Daje programistom sposób na przekształcanie założeń w coś konkretnego — coś, co można sprawdzić, udostępnić i ponownie wykorzystać bez niejasności.
A w przestrzeni, gdzie "ufaj mi" zostało nadużyte do tego stopnia, że stało się bezsensowne, to jest zmiana, na którą warto zwrócić uwagę.