Pomiędzy v1.29.0 2025-12-27 a v1.30.0 2026-01-02 SSP wydał dwa wydania, które w changelogu wyglądają na małe, a w diagramie architektury na duże. v1.29.0 dodało uwierzytelnianie żądań — portfel weryfikuje pochodzenie i integralność każdego żądania dApp. v1.30.0 dodało SSP Identity Signing — portfel może udowodnić własną tożsamość zdalnej usłudze, a nie tylko podpisać transakcję. Razem utwardzają powierzchnię żądań dApp otwartą przez WalletConnect i zamieniają pierwotną funkcję Tożsamości w prymityw pierwszej klasy, który usługi mogą wyzwać.
Uwierzytelnianie żądań ląduje (v1.29.0)
Żądanie dApp — podpisz to, zatwierdź tamto, przełącz na ten łańcuch — trafia do portfela przez transport. Przy WalletConnect tym transportem jest sesja przekazywana przez relay; przy in-page provider — wiadomość rozszerzenia Chrome. Każdy ma co najmniej jedną lukę zaufania: relay można podszyć, strona może być klonem phishingowym, wiadomość można sfałszować.
Uwierzytelnianie żądań zamyka te luki po stronie portfela. Zanim SSP wyrenderuje ekran potwierdzenia, sprawdza, kto pyta i o co. Pochodzenie deklarowane w żądaniu jest porównywane z transportem, który je dostarczył. Ładunek jest sprawdzany pod kątem integralności — portfel nie podpisuje żądania zmodyfikowanego w tranzycie. A samo żądanie jest sprawdzane wobec stanu sesji, który portfel już ma, żeby odtworzone żądanie z innej sesji nie prześlizgnęło się z cudzym sparowaniem.
Żadna z tych zmian nie wpływa na to, co widzisz, gdy legalna dApp prosi cię o podpis. Ekran potwierdzenia wygląda tak samo. Zmienia się to, że ścieżka między dApp a tym ekranem ma teraz bariery, które portfel egzekwuje sam, zamiast ufać, że transport mówi prawdę o tym, dla kogo dostarcza.
Identity Signing podąża dalej (v1.30.0)
Tydzień później v1.30.0 poszło w przeciwnym kierunku. Do tego czasu Tożsamość SSP mogła podpisywać wiadomości — ciągi dowodzące, że użytkownik kontroluje klucz. v1.30.0 dodaje możliwość podpisywania jako tożsamość: zdalna usługa może wystawić wyzwanie nazywające oczekiwaną Tożsamość SSP, a portfel zwraca podpis, który wiąże odpowiedź z tą tożsamością w sposób, który usługa potrafi zweryfikować.
Różnica jest subtelna i nośna. Podpisanie wiadomości dowodzi, że klucz coś kontroluje. Podpis tożsamości dowodzi, że klucz kontroluje nazwaną tożsamość — stabilny uchwyt, który usługa już skojarzyła z uprawnieniami, saldami lub subskrypcjami. Dla usług, które muszą wiedzieć nie tylko „czy jest tam użytkownik?”, ale „czy to ten sam użytkownik, który założył konto?”, podpis tożsamości zamyka pętlę. v1.30.0 dopracowało też obsługę pop-upów żądań — mniej migotania, mniej zgubionych pop-upów, szybszy powrót do fokusu.
Dlaczego to ważne dla dApp
Model zagrożeń dApp dzieli kilka źródłowych przyczyn. Spoofing pochodzenia — złośliwa strona udaje zaufaną. Powtarzane żądania — ładunek podpisany w jednej sesji jest przechwycony i wysłany w innej. Powierzchnie phishingowe — żądanie wyglądające legalnie na ekranie potwierdzenia w rzeczywistości trafia do kontraktu atakującego.
Uwierzytelnianie żądań zawęża wszystkie trzy, bo portfel przestaje traktować transport jako autorytatywny. Pochodzenie musi pasować do transportu, ładunek musi pasować do tego, co wysłano, sesja musi pasować do tej sparowanej. Każdy check z osobna jest mały; razem czynią z ekranu potwierdzenia coś, czemu użytkownik może zaufać jako odzwierciedleniu rzeczywistości. Podpis tożsamości zawęża inny atak — przejęcie konta przez ponowne sparowanie — bo usługa, która prosi portfel o podpis jako nazwana tożsamość, zamienia „portfel się zalogował” w weryfikowalne powiązanie.
Jak to gra z WalletConnect
WalletConnect otworzył drzwi do tysięcy dApp. v1.29.0 założył zamek na te drzwi, a v1.30.0 dodał dzwonek. Oba lądują na tej samej powierzchni: na przepływie żądań. Uwierzytelnianie żądań gwarantuje, że żądanie widziane przez portfel jest tym, które wysłała dApp. Podpis tożsamości gwarantuje, że odpowiedź, którą widzi dApp, jest tą, którą wysłał twój portfel, podpisaną przez tożsamość, której dApp oczekiwała. Para zamienia sesję WalletConnect z „dwa końce wymieniające bloby” w „dwa końce, z których każdy może drugiemu udowodnić, kim jest”.
Od Tożsamości do Identity-Signing
Pierwotna funkcja Tożsamości SSP dała portfelowi stabilną powierzchnię tożsamości — adres wyprowadzony do wiadomości i dowodów, odrębny od adresów transakcyjnych, z których wydajesz. To było wprowadzenie. v1.30.0 jest naturalną kontynuacją: ta sama tożsamość, teraz użyteczna jako poświadczenie, o które usługa może poprosić po nazwie i zweryfikować po swojej stronie.
Tak właśnie portfel staje się prymitywem tożsamości pierwszej klasy, a nie tylko nośnikiem kluczy. v1.29.0 czyni wejścia godnymi zaufania; v1.30.0 czyni wyjścia weryfikowalnymi. Większość użytkowników nigdy nie zobaczy różnicy bezpośrednio. Ale dApp i usługi integrujące się z tą powierzchnią odkryją, że SSP potrafi teraz udowodnić, kim jest, i zweryfikować, kto pyta — za każdym razem.