Poznaliśmy algorytm losowania SLPS czyli… co dokładnie?

Fundacja Moje Państwo od roku 2017 walczy ze zmiennym szczęściem o ujawnienie algorytmu stojącego za Systemem Losowego Przydziału Spraw, programem komputerowym rozdzielającym sprawy sądowe między składy sędziowskie. Ministerstwo przez lata odmawiało jego publikacji, jednak w połowie września 2021 nagle poddało się – na stronie gov.pl umieszczono dokument o nazwie Algorytm_losowania_utworzony_na_podstawie_dokumentacji_analitycznej_v111.pdf, dostępny pod ścieżką Ministerstwo Sprawiedliwości → O ministerstwie → Informacje publiczne → Algorytm SLPS.

Czy rzeczywiście Ministerstwo ujawniło komplet informacji niezbędnych do odtworzenia sposobu działania kluczowego modułu systemu? A może ustępstwo było pozorne a my dostaliśmy zestaw niekompletnych i niespójnych informacji, które grają rolę listka figowego skrywającego nieprzejrzystość SLPS? Zapraszam do lektury mojej analizy dokumentu!

Osoby spoza IT będą miały duży problem z lekturą i interpretacją wspomnianego tekstu. Każda branża ma swój własny slang, sposoby na organizację i utrwalanie wiedzy o wytwarzaniu produktów i prowadzeniu procesów. Bez wiedzy przedmiotowej nie sposób zorientować się, co jest mocnym kiksem a co wypełniaczem pozbawionym znaczenia.

Ja programuję etatowo już jakieś 18 lat, w tym czasie zdążyłem przeczytać setki dokumentów projektowych różnorakiej jakości (oraz samodzielnie popełnić pewną ich liczbę). Opiszę swoje wrażenia z lektury tekstu źródłowego, najpierw jednak troszkę teorii dla niezorientowanych w temacie.

W jaki sposób tworzy się dokumentację projektową oprogramowania?

Bez owijania w bawełnę? Często wcale.

Czemu? Cofnijmy się w czasie. Złożoność programów komputerowych od zawsze ograniczana była przez sprzęt – wydajność procesorów, pojemność nośników, rozdzielczość monitorów, rozmiary pamięci operacyjnej i tak dalej. Gdy sprzęt był coraz lepszy, programy stawały się coraz większe. Już 20-30 lat temu złożoność oprogramowania tworzonego na komputery mainframe była tak duża, że wiele nowo projektowanych systemów IT nigdy nie doczekało się wdrożenia. Dlaczego?

Kluczowe problemy nie zmieniły się po dziś dzień – nieumiejętność oszacowania pracochłonności, niewłaściwe modelowanie dziedziny, błędny wybór technologii, nieuwzględnienie uwag przyszłych użytkowników. We wspomnieniach post mortem często pojawia się także temat dokumentacji projektowej – im więcej tomów już istniało, tym więcej pracy trzeba było włożyć w choćby niewielkie zmiany. Dużo czasu i energii zabierało wersjonowanie dokumentów, synchronizacja zmian w dokumentacji z rzeczywistymi modyfikacjami oprogramowania i tak dalej. Wystarczy spojrzeć na listę znaczących nieudanych projektów w Wikipedii – niektóre z nich kosztowały miliardy dolarów, przekroczyły zakładany budżet dziesiątki razy a i tak na końcu wyrzucano całość do kubła.

Uruchomione projekty często miewały zbyt długi cykl wdrażania zmian, zakładający np. wydanie nowej wersji raz w roku. Lekko upraszczając można przyjąć, że główne etapy produkcji – projektowanie, programowanie, testowanie i wdrożenie – trwały wówczas po kwartale. Jeśli w połowie roku okazało się, że najbardziej potrzebne są inne funkcje, niż obecnie realizowane, najwcześniejszy możliwy termin ich dostarczenia wynosił 18 miesięcy.

W odpowiedzi na te problemy popularność zaczęły zdobywać tzw. metodyki zwinne, których głównym założeniem jest wprowadzenie bardzo krótkich iteracji, często dwu- lub trzytygodniowych. W każdym krótkim cyklu zespół realizacyjny dostarcza nową funkcję. Sponsor projektu może modyfikować priorytety zadań przewidzianych na kolejne cykle, więc nagłą zmianę zapotrzebowania da się ogarnąć nawet w miesiąc.

Gdy metodykę zwinną połączymy z architekturą mikroserwisów, zakładającą budowę wielu małych modułów rozwijanych i testowanych niezależnie, zapotrzebowanie na dokumentację możemy zredukować do minimum. Często zresztą jej spora część jest generowana automatycznie wprost z kodu źródłowego, co dodatkowo ułatwia zarządzanie wersjami.

Wróćmy jednak do SLPS. Nie da się ukryć, że tu jakaś dokumentacja jednak powstała. Jak duży jej fragment oglądamy? Albo bardziej ogólnie:

Jeśli dokumentacja jednak powstaje, to co zawiera?

Poniżej napiszę, jakiego rodzaju dokumentacji życzyłbym sobie w projekcie o rozmiarze i złożoności SLPS. Zaznaczam, że opis nie ma nic wspólnego z rzeczywistością – jest jedynie pomocą w rozumieniu niniejszego artykułu i stanowi projekcję mojego doświadczenia i myślenia życzeniowego. Taki właśnie zestaw chciałbym mieć przystępując do programowania lub próbowałbym wytworzyć, gdyby moją rolą było projektowanie.

Opisując poszczególne elementy pominę zastrzeżenia w rodzaju „często”, „czasem”, „niekiedy” czy „zazwyczaj” – dość powiedzieć, że w każdym projekcie będzie inaczej. Nie ma niestety branżowych reguł czy standardów dotyczących formy czy poziomu szczegółowości dokumentacji projektowej oprogramowania. Dobra, istnieje coś takiego, jak język modelowania UML i choć teoretycznie realizuje wiele zadań, to jednak w praktyce praktyka różni się od teorii a z całego UML-a najbardziej przydają się trzy albo cztery rodzaje diagramów.

Oto fikcyjne składowe dokumentacji SLPS, którą sobie wyobraziłem:

1. Opis ogólny odpowiadający na pytania o powody i cele realizowane przez projektowane oprogramowanie. Coś w rodzaju „celem SLPS jest zwiększenie zaufania społeczeństwa do sądów poprzez zagwarantowanie całkowicie losowego przydziału składów sędziowskich do spraw” albo „celem drugorzędnym jest wyrównywanie obciążeń sędziów oraz dostarczanie ujednoliconych raportów o statystykach spraw w poszczególnych jednostkach”.
   
   Tego typu opis pomaga wszystkim uczestnikom projektu skupić się na kluczowych aspektach systemu. W SLPS byłaby to przejrzystość losowania i niepodatność na manipulacje, co dałoby się zapewnić przez gwarancję rozliczalności działań użytkowników i użycie odpowiedniego źródła losowości. Do kluczowych aspektów nie będzie natomiast należeć dostosowanie interfejsu do urządzeń mobilnych ani gwarancja dostępności systemu przez 99.999% czasu.

2. Słowniczek objaśniający pojęcia – świat wymiaru sprawiedliwości ma swój własny slang, niezrozumiały dla programistów. Dokumentacja powinna stosować wyłącznie pojęcia ze słowniczka aby terminologia była spójna w obrębie całego projektu. Dzięki temu nie będziemy musieli zastanawiać się, czy „koszt przypisania” jest tożsamy z „kosztem przydziału” i czym oba te koszty różnią się od „wskaźnika przydziału”.
3. Analiza procesów czyli opis, jakie dane trafiają do systemu, jak są przetwarzane i co dzieje się z wynikami przetwarzania. Kluczowy jest precyzyjny opis nie tylko głównej ścieżki, ale wszystkich przypadków brzegowych. Mile widziany będzie dodatek z opisem mechanizmu ról i uprawnień oraz przypisanie procesów do ról.
4. Schemat bazy danych czyli opis wszystkich typów obiektów (np. sąd, sędzia, sprawa, ławnik, losowanie, urlop) wraz z atrybutami (sędzia ma: imię, nazwisko, PESEL, bieżące obciążenie, przydział służbowy itd.) i łączącymi je relacjami (np. „sędzia ma urlop” albo „sędzia orzeka w wydziale”). Zdefiniowane tu więzy spójności bazy danych zapobiegną części błędów, np. PESEL sędziego określimy jako unikalny, więc ten sam nigdy nie pojawi się u dwóch sędziów. Typy pól też będą pomocne – jeśli liczba ławników jest wartością typu całkowitego bez znaku, to wykluczymy przypisanie do sprawy ujemnej liczby ławników. Czasem atrybutom zdefiniujemy dziedziny, np. wyszczególnimy wszystkie możliwe typy sądów.
5. Projekt interfejsu użytkownika – menu głównego, sekcji, działów, okienek dialogowych, formularzy, zestawień; najlepiej z odwołaniami do systemu ról i uprawnień.
6. (mile widziane) przypadki użycia czyli opisy interakcji i sekwencji działań, jakie muszą podjąć użytkownicy systemu by realizować od początku do końca typowe operacje.

Co dostaliśmy od Ministerstwa Sprawiedliwości i czy to rzeczywiście kompletny algorytm?

Dokument opublikowany pod nazwą Algorytm SLPS to fragment analizy procesów, wycięty z większej całości. Nie mamy do dyspozycji słowniczka, więc znaczenia wielu nazw musimy domyślać się z kontekstu. Nie mamy do dyspozycji opisu typów obiektów, więc nie wiemy, jakimi atrybutami charakteryzują się obiekty modelowane przez SLPS (sędzia, sprawa, losowanie itd.)

Nie upadajmy jednak na duchu, zamiast tego zastanówmy się, w jaki sposób możemy potwierdzić kompletność i poprawność algorytmu. Przypomnijmy sobie tekst „O algorytmach dla prawników” i objaśnianą tam różnicę między algorytmem a programem, w tekście wystąpił jeden algorytm i jego trzy implementacje (w językach Scratch, Basic, C#). Bingo! Jeśli będziemy w stanie napisać własny program, który – nakarmiony danymi wejściowymi – da taki sam wynik, jak SLPS, to będzie to dobry znak.

Tu pojawia się pierwszy problem: parametryzacja opisanych algorytmów. Niektóre wartości (np. liczbowe) nie są ustalone raz na zawsze, może modyfikować je administrator systemu. Przykład: parametr T decydujący, co ile losowań nastąpi balansowanie obciążeń składów trzyosobowych (str. 24). W wydziałach małych sądów może to być 5, w dużych 10, ale po pół roku ktoś może stwierdzić, że lepiej sprawdzą się wartości 6 i 9. A dodatkowo po tygodniu ów ktoś zmieni 9 na 11.

W rezultacie nie jesteśmy w stanie w sposób niezależny odtworzyć przebiegu algorytmu SLPS, jeśli nie znamy pełnego zestawu parametrów systemowych – te zaś mogą być zmieniane przez administratora w dowolnej chwili.

Drugi problem – luki w logice opisanego algorytmu. Na stronie 4 widzimy regułę R13 w której następuje sprawdzenie, czy sędzia był uprzednio wyłączony ze sprawy, w której następuje losowanie. Jeśli tak, ustawiany jest znacznik wyłączenia sędziego ze sprawy.

I teraz uwaga:

• to jedyne miejsce w którym pojawia się termin „znacznik wyłączenia ze sprawy”
• nie wiemy, w którym typie obiektów obecnych w systemie umieszczony jest taki znacznik ani jaki jest cykl życia tego obiektu (kiedy jest tworzony i kiedy znika)
• od tego znacznika nic nie zależy, tzn. nigdzie nie ma informacji, by na jego podstawie rzeczywiście usuwano wyłączonego sędziego z puli kandydatów (formalna specyfikacja nie działa w taki sposób, że jeśli nazwa parametru coś sugeruje, to odgadniemy o co chodzi i doprogramujemy to na boku)

Mamy więc tylko dwie możliwości – albo oprogramowanie zrealizowane według dostarczonego dokumentu nie będzie honorowało istniejących wyłączeń, albo też oprogramowanie realizuje algorytm odmienny od opisanego w dostarczonym dokumencie.

To może chociaż upewniliśmy się, że losowania SLPS są rzeczywiście losowe?

Temat źródła losowości skwitowano w dokumencie zwieźle: „Losowanie sędziego referenta dla sprawy odbywa przy wykorzystaniu generatora sprzętowego liczb”. Od razu pojawia się masa pytań i problemów. Przykład pierwszy z brzegu – nie wyspecyfikowano przedziału jaki przyjmuje wartość losowa i nie wiemy, czy zawsze jest wielokrotnością liczby sędziów. To ważne w świetle innego cytatu: „Generowana jest losowa liczba dla sprawy. Wygenerowana liczba dzielona jest modulo przez rozmiar puli losującej”.

Modulo to nic innego, jak reszta z dzielenia. Przykład: jeśli liczba losowa generowana zwykłą kostką do gry ma wartość od 1 do 6 a sędziów do losowania jest pięciu, to rzucając kostką i stosując operację dzielenia modulo mamy dwukrotnie większą szansę wylosowania pierwszego sędziego na liście (wynik 1 lub 6 na kostce) niż pozostałych (każdy z nich ma tylko jedną odpowiadającą mu liczbę oczek: 2, 3, 4 lub 5).

Albo rozwiązanie problemu znajduje się we fragmencie dokumentacji, który nie został udostępniony, albo też operacja dzielenia modulo będzie preferowała sędziego/sędziów z pierwszych miejsc listy. Teraz śmieszne spostrzeżenie – na liście sędziów do losowania, sędziowie delegowani z art. 77 par. 9 zawsze wskakują na początek listy (reguła R15, strona 5). Czemu? Nie jest to wyjaśnione w opublikowanym fragmencie dokumentacji.

Jeśli spojrzymy na powyższy raport z losowania, zauważymy listę sędziów zakwalifikowanych do puli – nie widzimy jednak sędziów wykluczonych. Tymczasem powodów wykluczenia może być kilka, m.in. długi urlop, wyłączenia ze sprawy, ale także dokonywane przez administratora „wyłączenie [sędziego] z losowania” wszystkich spraw lub spraw danej kategorii.

Czy też widzicie tu ryzyko? Nie wiemy nic o tym, by SLPS – albo baza danych na której jest oparty – miały mechanizm zapisu logów i zdarzeń systemowych z aktywnym mechanizmem gwarantującym integralność i niezaprzeczalność. Nie wiemy też, kto i w jakim trybie może wyłączać sędziów z losowania, wiemy jedynie, że jest to uprawnienie „zarządzanie wydziałem” (R10, str. 4). Społeczna kontrola takiego rejestru zdarzeń zwyczajnie nie istnieje.

Gdyby na protokole była lista sędziów spoza puli wraz z adnotacjami o przyczynach wykluczenia, ręczna manipulacja w panelu administratora zostawiałaby widoczny na zewnątrz ślad. Tak nie jest – a możliwość arbitralnego usuwania dowolnego sędziego z losowania jest kolejnym powodem, dla którego nie da się sporządzić mechanizmu naśladującego w sposób niezależny działania SLPS przez dłuższy czas.

To ile w końcu jest tych losowań?

Spójrzcie jeszcze raz na przykładowy protokół z poprzedniego obrazka. Zauważcie, że czteroosobowa pula sędziów do losowania ma zmienione liczby porządkowe (kolumna „Pozycja”). Pierwotnie numerom 1-2-3-4 odpowiadało rosnące obciążenie sprzed losowania, jednak zgodnie z regułą R19 (str. 5) numeracja pozycji została pomieszana, wyszło 4-1-3-2.

Jeśli dobrze rozumiem regułę, każdemu z czterech sędziów z puli przydzielono osobną wartość losową i posortowano według nich liczby porządkowe, bez przestawiania wierszy. Ważne: te wartości nie są nigdzie rejestrowane, nie ma tu nawet pozorów przejrzystości. Następnie w kroku R22 obieramy jeszcze jedną wartość losową – to ona trafia na protokół oraz wyznacza (operacja modulo) sędziego do sprawy.

Z punktu widzenia matematyki nie ma to żadnego sensu. To nie jest odpowiednik lepszego mieszania piłeczek w maszynie losującej Lotto, takie przestawianki w najmniejszym stopniu nie „poprawią” ani nie „wzmocnią” losowości. Jest to zaś kolejne miejsce w systemie, którego działania nie jest w stanie prześledzić zewnętrzny obserwator.

Po lekturze tych fragmentów drapiemy się w głowę

Kolekcja „michałków” znalezionych w tekście, trochę śmiesznych a trochę strasznych, bo obnażających niską jakość projektu:

Strona 2: „Do listy potencjalnych dat startowych dla sędziego dodawana jest data określona przez wartość zmiennej 'HolidaysFrom’ z pliku konfiguracyjnego aplikacji. […] Jako data startowa dla sędziego wybierana jest najpóźniejsza z potencjalnych dat startowych dla sędziego”. Yyyyy? Czy każdy sędzia ma swój „plik konfiguracyjny” z urlopami? A może jest to plik z definicjami dni świątecznych? Jeśli jest to ta druga opcja, to każdy sędzia będzie miał identyczną datę startową, zapewne przyszłoroczne Boże Narodzenie.

Reguła R17, strona 5: „Jeżeli liczba sędziów biorących udział w losowaniu wynosi 2, tworzony jest wirtualny kandydat poprzez zduplikowanie pierwszego sędziego z utworzonej w poprzednim kroku listy”. Yyyyy? Dlaczego nie może być dwóch sędziów? Po takim zduplikowaniu szansa na wybór wynosi 2 do 1 na rzecz pierwszego sędziego! Jeśli z dowolnego powodu potrzebnych jest co najmniej trzech sędziów, to czemu nie zduplikować obu wpisów? To zachowałoby równe szanse. Niestety – ani słowa wyjaśnienia.

Reguła 32 ze strony 7 jest zbędna. Podstawa normalizacji nigdy nie będzie ujemna, bo w regule 31 wybieramy ją spośród wartości równych lub większych od zera.

Te fragmenty brzydko pachną

Czasem patrzymy na kod źródłowy lub dokumentację i czujemy, że coś w projekcie śmierdzi (tak, code smell to naprawdę fragment slangu). Niniejszy rozdział to 100% moich subiektywnych opinii na temat raczej architektury SLPS niż algorytmu przydziału. Chcę jednak pokazać osobom spoza IT, że między wierszami daje się czasem wyczytać trochę dodatkowych informacji.

R23, strona 6 – dokument analityczny opisujący proces znienacka objaśnia dziedziny pól w bazie danych. Drobiazg, ale takie mieszanie warstw abstrakcji czasem oznacza braki w projekcie technicznym albo niepotrzebne dublowanie informacji.

R24-25, strona 6 – tu nawarstwia się kilka problemów.

1. dokument analityczny opisujący proces losowania nie powinien zawierać opisu naprawy usterek w bazie danych. Akcja serwisowa powinna być opisana gdzie indziej, przeprowadzona raz, zakończona i zapomniana. W przeciwnym razie do końca świata trzeba będzie pamiętać, które kroki procesu były ważne tylko przez kilka miesięcy iks lat temu.
2. sam proces naprawy powinien być przetestowany na replice bazy danych i wdrożony w jeden weekend; utrzymywanie różnic w metodologii liczenia obciążeń dopóki każdy z sędziów w Polsce nie wylosuje nowej sprawy brzmi jak temat, który nigdy się nie skończy i nie pozwoli na realizację spójnej sprawozdawczości
3. nazywanie „nowym mechanizmem” czegokolwiek w dokumencie projektowym przywodzi na myśl program „Nowe Gadu-Gadu” wydany w roku 2009. Autor analizy zapewne nie przewidział, że „nowy mechanizm” będzie kiedyś zastąpiony „jeszcze nowszym mechanizmem”. Trzeba je numerować albo nadawać wersjom imiona.

Przypomnijmy fragment raportu NIK: „SLPS nieprawidłowo liczył sędziom obciążenia, co przekładało się negatywnie na równomierność przydziału spraw. W grudniu 2018 r. Dyrektor DKO opracował koncepcję naprawy danych w bazie SLPS. Generalne przeliczenie wartości zgodne z tą koncepcją odbyło się 15 lutego 2019 r. Operacja ta okazała się skuteczna tylko częściowo i jednocześnie sama była przyczyną kolejnych nieprawidłowości w bazie danych. Dlatego w marcu 2019 r. wprowadzono do SLPS możliwość zerowania obciążeń, a w lipcu udostępniono użytkownikom arkusz Excel służący do ręcznego przeliczenia danych i rozpoczęcia przydziału od nowa […] planowane jest uruchomienie odpowiedniego mechanizmu raportującego, który z poziomu centralnej bazy wykrywałby nietypowe różnice w obciążeniach sędziów”.

R30, strona 7 – „Tworzona jest lista zawierająca wszystkich sędziów z danego wydziału orzekających w danej kategorii, z wyłączeniem referatów zbiorczych”. Jeśli referat może być zbiorczy, to nie ma znaku równości między referatem a sędzią. Modelując system należałoby zastosować agregację (sędzia ma referat) albo dziedziczenie (referat sędziego jako specjalizacja bardziej ogólnego referatu).

Jak wspominałem – powyższe zastrzeżenia to tylko moje opinie, jestem jednak przekonany, że doświadczony zespół dążyłby do eliminacji opisanych pułapek. Usterki w architekturze odbijają się czkawką przez długie lata, jakiekolwiek początkowe oszczędności są niczym wobec kosztów ich naprawy po latach.

Co realnie zyskaliśmy otrzymując tzw. Algorytm SLPS?

Bardzo niewiele. Nie jesteśmy w stanie potwierdzić zarówno prawidłowości pojedynczych losowań jak i spójności danych SLPS w dłuższym okresie. Nie dowiedzieliśmy się niczego o źródłach losowości, logowaniu zdarzeń ani wiarygodności logów. Nie mamy też żadnej możliwości weryfikacji poprawności implementacji – tu potrzebny byłby dostęp do kodu źródłowego, o co nadal walczy Sieć Obywatelska Watchdog Polska. Na dobrą sprawę dowiedzieliśmy się jedynie, że jakaś dokumentacja projektowa rzeczywiście powstała a jej cechy pasują do… problemów z SLPS opisywanych w prasie.

Wciąż jednak mamy do czynienia z całkowitym brakiem przejrzystości SLPS. Gdyby tak działało Lotto, nie tylko zabrakłoby publicznych losowań na antenie TV, ale w ogóle nie mielibyśmy informacji o wylosowanych numerach. Gracze musieliby przyjąć na wiarę, że ktoś uruchamia maszynę, że skaczą w niej jakieś kulki a namalowane na nich liczby służą do wyznaczenia zwycięzców. Ciekawe, ile osób wierzyłoby wówczas w uczciwość losowań…

A może zrezygnować z generatora liczb losowych?

Aby nie było, że tylko marudzę – oto pomysł, jak przeprowadzić losowy przydział składów sędziowskich bez uciekania się do generatora liczb losowych, którego skuteczny audyt może być niemożliwy. Z góry przepraszam za hermetyczność tego rozdziału.

Główna idea – użycie skrótu kryptograficznego z wartości, które znane są w chwili wpływu sprawy, np. data i godzina, powód i pozwany. Ewentualne manipulacje z godziną czy kolejnością rejestracji nie mają znaczenia. Powstały skrót (hash) byłby natychmiast publikowany w portalu sądowym wraz z informacją o jego numerze sekwencyjnym (SLPS jest jeden na cały kraj, więc może kolejno numerować rejestrowane sprawy). Skrót sam z siebie nie zdradza niczego, natomiast stanowi stanowi swoiste znakowanie czasem i gwarancję wczesnego utworzenia losowości powiązanej niezaprzeczalnie z daną sprawą.

Potem obowiązkowo czekamy np. tydzień, aby pula sędziów do losowania stała się nieprzewidywalna (po drodze będzie wiele innych losowań, które wpłyną na dobór i kolejność sędziów w puli). W każdej sesji przydziału bierzemy sprawy nie nowsze niż tydzień, obrabiamy je obowiązkowo w kolejności rejestracji; decyduje numer sekwencyjny bazy danych SLPS nadany tydzień wcześniej. W każdej sprawie używamy ustalonego wcześniej skrótu do wyznaczenia n-tego sędziego z puli.

Manipulowanie wynikiem byłoby wciąż możliwe, gdyby w ciągu owego tygodnia do danego wydziału wpłynęło na tyle mało spraw, by przyszła pula sędziów pozostała przewidywalna. Tę usterkę da się załatać – skoro SLPS jest jeden na cały kraj i przeprowadza losowania sekwencyjnie, to możemy „dohaszować” skrót sprawy X wynikiem przydziału sprawy X-1, ów wynik będzie znany dopiero ułamek sekundy przed przydziałem składu dla sprawy X.

Opisany pomysł nie zapobiegnie wszystkim możliwym manipulacjom (np. ręcznemu usuwaniu sędziów z puli) ale sposób uzyskania i użycia losowości nie wymagałby wiary w uczciwość i prawidłowość użycia sprzętowego generatora. Gdyby dodać do tego jawność protokołów przydziału i uwzględnienie na protokołach powodów wykluczeń sędziów, mielibyśmy coś na kształt audytowalnego SLPS.

Dostrzegacie inne słabości pomysłu, których ja nie widzę? Dajcie znać w komentarzach.