e-Do(S)ręczenia: zmieńmy Denial of Service w Decentralization of Service

1 października 2026

Od co najmniej dwóch tygodni rządowy system e-Doręczenia praktycznie nie działa - a to właśnie ostatnie dni, w których ok. 2 mln jednoosobowych firm miało założyć skrzynkę przed terminem 1 października. Nazwijmy to po imieniu: zmasowany atak DoS na żądanie Ministerstwa. Czy naprawdę każda taka usługa wymaga centralizacji? Nie - proponujemy inne podejście i inne rozwinięcie skrótu: Decentralization of Service.

💥 Awaria i jej skala

Jak zawsze winni są użytkownicy (przecież mogli założyć skrzynkę wcześniej). Taki mały żarcik. A na poważnie: czy skala problemu była naprawdę tak przytłaczająca?

Wielkość	Wartość	Źródło
Aktywne JDG w CEIDG	ok. 2,6 mln	MRiT, dane CEIDG (2023); od tego czasu liczba aktywnych JDG lekko spada - CEIDG, I półrocze 2026
Działalności zawieszone (też muszą mieć adres)	ok. 0,83 mln	GUS, REGON, sierpień 2026: 864,1 tys. podmiotów zawieszonych, z czego ok. 96% to osoby fizyczne (GUS, sierpień 2025)
Wszystkie adresy w Bazie Adresów Elektronicznych (BAE), sierpień 2026	4,6 mln, z czego 55% to prywatne skrzynki obywateli	Ministerstwo Cyfryzacji; udział osób fizycznych: Poczta Polska, za Bankier.pl
Adresy firm z CEIDG w BAE	ok. 1,3–1,6 mln	szacunek: pozostałe 45% to ok. 2,1 mln adresów firm i instytucji; po odjęciu urzędów (ok. 50 tys.) i podmiotów z KRS (ok. 0,4–0,7 mln) zostają JDG
JDG bez skrzynki przed terminem	ok. 2 mln	szacunek: ok. 3,4 mln zobowiązanych minus 1,3–1,6 mln firm z adresem
Próbujący w ostatnich dwóch tygodniach	ok. 0,6–1 mln	szacunek: 30–50% z nich; reszta to firmy uśpione lub czekające

Przy równomiernym rozłożeniu na dwa tygodnie portal musiałby przyjmować 40–70 tys. wniosków dziennie. W praktyce większość wniosków spłynęła w ostatnich dniach, a każdy błąd mnożył próby - stąd apel resortu, by nie klikać „Wyślij” wielokrotnie.

Dlaczego jeden portal zawodzi

• Logowanie, kody, wnioski i CEIDG zależą od wspólnych elementów, m.in. login.gov.pl: gdy pada jedno ogniwo, staje wszystko - a najczęściej pada logowanie.
• Każdy błąd generuje kolejne próby, więc użytkownicy sami zwiększają obciążenie.
• Skalowalność ogranicza się do możliwości jednego operatora.

Jak działa decentralizacja

Tu potrzebne jest kilka słów o tym, jak działa sam blockchain. Wyróżniamy dwa rodzaje węzłów:

1. Węzły API - odpowiadają za komunikację z użytkownikami (przedsiębiorcami, urzędami). Pełnią rolę pośrednika: wstępnie weryfikują zleconą transakcję (np. sprawdzają ważność podpisów i inne podstawowe, publicznie dostępne dane) i przekazują ją dalej przez sieć P2P. Obsługują zatem dwa rodzaje ruchu:

   • zapytania API - zarówno pasywne (pobieranie danych), jak i aktywne (rozgłaszanie transakcji, broadcast_transaction);
   • ruch P2P - wymianę bieżąco rozgłaszanych transakcji oraz zatwierdzonych bloków.

   Co ważne, ta technologia pozwala, by każdy z nas - użytkowników systemów rządowych - mógł mieć u siebie taki węzeł (ograniczony do przechowywania wyłącznie własnych danych, co zmniejsza zużycie zasobów). Ten sam model sprawdziłby się zresztą w KSeF: każda firma mogłaby mieć własny, lokalny węzeł z kopią swoich faktur.

2. Węzły producentów (walidatorów) bloków - te powinny być odizolowane od zewnętrznego ruchu API. Ich zadaniem jest zatwierdzanie transakcji napływających z sieci P2P oraz tworzenie i rozgłaszanie bloków, które je zawierają. To one odpowiadają za stabilne działanie i spójność sieci.

Jak mogłoby to działać

Weźmy za przykład założenie skrzynki. Przedsiębiorca łączy się z dowolnym węzłem API (nawet własnym); gdy jeden nie odpowiada, aplikacja wybiera następny (nic nowego - to zwykłe skalowanie poziome). Różnica polega na czym innym: cała interakcja odbywa się w rzeczywistości na maszynie klienta (w jego przeglądarce), gdzie podpisywane jest również zlecenie wykonania transakcji. Wybrany węzeł API rozgłasza transakcję przez sieć P2P do pozostałych węzłów, aż trafi ona do producenta (walidatora) bloków. Ten zatwierdza transakcje i rozgłasza blok zawierający te z nich, które uznał za poprawne - węzeł API otrzymuje go również przez P2P. Od tego momentu każdy węzeł w sieci rozpoznaje nowe konto, czyli skrzynkę (każdy samodzielnie wykonuje transakcje z otrzymanego bloku). Na koniec aplikacja klienta informuje, że operacja została przyjęta przez system.

Dzięki temu żaden pojedynczy operator nie może wstrzymać przyjmowania pism ani zmienić wpisu wstecz (zapobiegają temu konsensus sieci i zabezpieczenia kryptograficzne). Walidatory powinny utrzymywać różne, niezależne od siebie jednostki publiczne - np. Ministerstwo Cyfryzacji, COI, NASK czy uczelnie. Sieć działa dalej nawet wtedy, gdy część z nich ulegnie awarii: pełne gwarancje nieodwracalności zachowuje, dopóki działa ponad 2/3 walidatorów, a całkowicie zatrzymać ją może dopiero awaria większości z nich.

🔐 No dobrze, a co z logowaniem? To zwykle punkt krytyczny. W blockchainie - bez znaczenia. Każda transakcja i tak musi dowieść swojej kryptograficznej autentyczności - na każdym węźle i w dowolnym momencie, a nie tylko w chwili realizacji. Odbywa się to przez weryfikację integralności transakcji za pomocą jej podpisu (żadna nowość - podpisy w ePUAP opierają się na tej samej zasadzie).

Logowanie staje się jedynie udogodnieniem dla użytkownika końcowego, pozwalającym mu korzystać z kluczy za pośrednictwem mObywatela (Profil Zaufany może posłużyć do ich wydania) - zupełnie nieświadomie. Niech żyje enkapsulacja!

A dlaczego bez znaczenia? Bo mając klucze prywatne, możemy działać w sieci samodzielnie - po prostu bezpośrednio podpisując operację (transakcję) do wykonania. To idealny model wsadowy dla większych firm i zaawansowanych użytkowników. Warunek jest jeden: klucz musi być u użytkownika (np. w aplikacji mObywatel na telefonie), a nie na centralnym serwerze. Inaczej wąskie gardło po prostu przeniesie się z logowania do usługi podpisu.

💡 Idea: technologia Hive w sieci państwowej

Publiczny Hive jest tu tylko przykładem. Docelowo mogłaby powstać niezależna sieć oparta na tej samej technologii open source, z węzłami API i producentami bloków utrzymywanymi przez jednostki publiczne. Blockchain Hive (lub pochodny) oferuje: blok co 3 sekundy, brak opłat transakcyjnych, wpisy (korespondencję) jako operacje comment z treścią szyfrowaną przez uczestników, a dane nadania i odbioru jako operacje custom_json z metadanymi (urzędowe poświadczenia przedłożenia, odbioru itp.). Załączniki - podobnie jak obrazki w postach na Hive - trafiają do serwisu pomocniczego: są szyfrowane po stronie nadawcy i dopiero wtedy tam składowane, a treść comment lub metadane zawierają tylko odnośnik do nich (wraz ze skrótem potwierdzającym integralność).

Element e-Doręczeń	Realizacja w oparciu o sieć blockchain
Klucze stron	Wydawane przez mObywatela / Profil Zaufany, przechowywane na urządzeniu użytkownika
Skrzynka ADE	Wpis-korzeń comment na koncie firmy
Pismo	comment pod skrzynką: treść zaszyfrowana, czytelna wyłącznie dla urzędu i przedsiębiorcy; załączniki zaszyfrowane w serwisie pomocniczym, dolinkowane z treści lub metadanych
Dowody eIDAS: nadanie, odbiór, integralność, czas	custom_json podpisany przez kwalifikowanego dostawcę usług zaufania
Dane osobowe	W łańcuchu wyłącznie w postaci zaszyfrowanej; jawne są tylko skróty i pseudonimowe ID kont
Dostępność kluczy	Zaszyfrowaną kopię zapasową i odzyskiwanie zapewniają serwisy rządowe (mObywatel, PZ); przedsiębiorca nie musi samodzielnie zarządzać kluczami

Szyfrowanie treści to nie wszystko - liczą się też metadane. Dlatego w łańcuchu nie powinno być widać, kto z którym urzędem koresponduje: konta są pseudonimowe, a załączniki nie trafiają do bloków. Pomaga to też w zgodności z RODO: załączniki w serwisie pomocniczym można usunąć, a zaszyfrowaną treść w łańcuchu uczynić trwale nieczytelną, niszcząc klucz (tzw. crypto-shredding).

⚖️ Trochę wyliczeń i faktów

Od kilku lat pracujemy nad optymalizacją i rozwojem platformy Hive. Wewnętrzne testy węzłów pracujących w sieci testowej (produkującej bloki o maksymalnym rozmiarze 2 MB) wykazały, że możliwe jest stabilne przetwarzanie i akceptowanie około 7200 transakcji na blok. Zestaw operacji w transakcjach odwzorowywał statystyczny rozkład operacji w Hive mainnet. Dla operacji tworzenia kont (account_create) liczba ta nieznacznie rośnie - do 7700 transakcji w bloku.

Oznacza to, że co 3 s system może przyjąć ok. 7000 operacji tworzenia kont, czyli ok. 7000 × 1200 = 8 400 000 na godzinę. Nawet gdyby cały milion firm przyszedł jednego dnia (10 godzin aktywności), daje to 100 000 kont na godzinę - wciąż ponad 80 razy mniej niż maksymalna przepustowość. Przy bardziej realistycznych 100 000 kont dziennie mamy 10 000 na godzinę, czyli blisko trzy rzędy wielkości zapasu.

Obecnie blockchain Hive (mainnet) przechowuje dane ponad 2,6 mln kont użytkowników - mniej więcej tyle, ile jest w Polsce aktywnych JDG. Aplikacja węzła (walidującego bloki i wszystkie reguły konsensusu) działa na… Raspberry Pi 4B z 8 GB RAM i kartą microSD, nadążając za siecią na bieżąco.

Kolejną zaletą jest przeniesienie podpisywania transakcji na stronę klienta - jedna z bardziej czasochłonnych operacji znika więc z serwerów systemu. Podpis kryptograficzny transakcji generuje użytkownik, który musi w jakiś sposób skorzystać ze swojego klucza prywatnego (np. skanując kod QR transakcji aplikacją mObywatel i podpisując ją w telefonie).

Podsumowanie

Nawet milion firm próbujących w tym samym czasie to nie atak, tylko przewidywalny ruch, na który centralny portal nie był przygotowany (a tak duże zapotrzebowanie na infrastrukturę bywa chwilowe). Sieć węzłów utrzymywana przez niezależne jednostki publiczne, klucze w rękach użytkowników i dowody eIDAS zapisane w łańcuchu sprawiają, że e-Do(S)ręczenia mogą znaczyć Decentralization of Service - i być powodem do dumy.

Wtedy nawet nawał „złośliwych” przedsiębiorców przestaje być groźny.