Promocja Ultrafuzz przez Keone Hona zwraca uwagę na kwestie OpSec w Monad

Współzałożyciel Monad, Keone Hon, zachęca deweloperów do wdrażania Ultrafuzz, jednocześnie ostrzegając, że bezpieczeństwo wykracza poza znajdowanie błędów w kodzie kontraktów. Promocja Ultrafuzz przez Keone Hona łączy testowanie wspomagane AI z bezpieczeństwem operacyjnym, czyli OpSec, które chroni konta, urządzenia i procesy otaczające oprogramowanie. To połączenie ma znaczenie, ponieważ nawet bezpieczny kontrakt zależy od osoby posiadającej uprawnienia do jego zarządzania.

Według crypto.news Hon 30 października udostępnił materiały dotyczące bezpieczeństwa i osobno zachęcał deweloperów do testowania kontraktów z Ultrafuzz. Jego apel ponownie zwraca uwagę na istniejący projekt open source. Nie oznacza on premiery nowego produktu ani nie stanowi niezależnego potwierdzenia skuteczności narzędzia.

Główne napięcie dotyczy zautomatyzowanego badania oraz odpowiedzialności operacyjnej, która nadal spoczywa na deweloperach. Ugruntowane narzędzia, takie jak Echidna od Trail of Bits, już testują zachowanie kontraktów. Ultrafuzz dodaje do tej pracy koordynację AI, podczas gdy jego własna dokumentacja ostrzega przed uruchamianiem nieograniczonych agentów w pobliżu wartościowych poświadczeń. Zespoły rozważające wdrożenie muszą ocenić zarówno generowane przez narzędzie ustalenia, jak i środowisko wymagane do ich bezpiecznego uzyskania.

Promocja Ultrafuzz przez Keone Hona odnawia istniejącą inicjatywę bezpieczeństwa

Bezpośrednią wiadomością jest ponowiony przez Hona apel o wdrożenie, a nie nowo wydany produkt bezpieczeństwa.

Crypto.news podał 31 października, że Hon promował testowanie kontraktów wraz z wytycznymi dotyczącymi urządzeń pracowników, poświadczeń, uprawnień administracyjnych i kont stron trzecich. Materiał odtwarza jego wpis z 30 października i opisuje osobne zaproszenie dla deweloperów do uruchomienia Ultrafuzz. Te zalecenia bezpieczeństwa umieszczają przegląd oprogramowania w szerszej dyscyplinie operacyjnej.

To rozróżnienie zmienia sposób, w jaki czytelnicy powinni interpretować ogłoszenie. Nowe wydanie rodziłoby pytania o nowo dodane możliwości, wymagania migracyjne i zmiany względem wcześniejszej wersji. Ponowiony apel stawia natomiast pytania o wdrożenie, praktyczną użyteczność oraz to, czy istniejące zasoby docierają do zespołów, które ich potrzebują.

Przekaz Hona łączy także obowiązki, które organizacje czasem powierzają różnym osobom. Deweloperzy badają zachowanie kontraktów, podczas gdy inni pracownicy administrują kontami, zarządzają komputerami i zatwierdzają wrażliwe działania. Wynik w zakresie bezpieczeństwa zależy od tego, jak te obowiązki się łączą, zwłaszcza gdy działanie administracyjne może zmienić zachowanie oprogramowania.

Smart kontrakt to oprogramowanie wdrożone w blockchainie, które działa zgodnie z zaprogramowanymi zasadami. Niektóre kontrakty obejmują również uprzywilejowane funkcje służące aktualizacjom lub innym zadaniom zarządczym. Przegląd zasad i ochrona uprawnienia do ich zmiany dotyczą różnych ścieżek awarii. Powodzenie w jednym obszarze nie potwierdza powodzenia w drugim.

Dlatego materiały OpSec pojawiają się w tej historii obok narzędzia testowego. Zgłaszane zalecenia Hona dotyczą zwykłych praktyk pracy, a nie wyłącznie wyspecjalizowanej obrony AI. Ich uwzględnienie kieruje uwagę na ludzi i systemy wspierające protokół po przeglądzie jego kodu.

Istnieje też wyraźna granica raportowania. Oryginalnego wpisu Hona na X nie udało się bezpośrednio pobrać podczas tego przeglądu, więc jego ostatnie komentarze pozostają przypisane relacji, która je odtwarza. Publiczna dokumentacja narzędzia stanowi odrębny dowód jego istnienia i modelu działania.

Sam apel nie mierzy, ile zespołów przyjęło te wytyczne. Nie potwierdza też, że użytkownicy zmienili swoje praktyki podpisywania lub naprawili wcześniej nieznane słabości. Publikacja, promocja, użycie i wykazana korzyść pozostają odrębnymi etapami.

Dla czytelników istotnym rozwojem jest połączone wezwanie. Monad prosi twórców, by szerzej badali oprogramowanie, jednocześnie analizując władzę otaczającą to oprogramowanie. To, czy te prośby przełożą się na zmianę zachowań, zależy od pracy wykraczającej poza udostępnienie listy zasobów.

Presja spada na zespoły oddzielające audyty od codziennej działalności

Apel Hona nakłada odpowiedzialność na organizację prowadzącą protokół, w tym na osoby kontrolujące konta i dostęp administracyjny.

Przegląd kontraktu bada określony cel programistyczny. Organizacja wokół tego celu stale się zmienia poprzez rotację pracowników, nowe zależności, zmiany uprawnień i zmienione praktyki pracy. Traktowanie ukończonego przeglądu jako trwałego statusu bezpieczeństwa pomija te bieżące decyzje.

Rozważmy protokół z przejrzanym kodem i kontem upoważnionym do zatwierdzania aktualizacji. Jeśli nieuprawniona osoba przejmie kontrolę nad tym kontem, przegląd nie może egzekwować procesu zatwierdzania obowiązującego w organizacji. Ten hipotetyczny przykład ilustruje granicę między prawidłowym zachowaniem oprogramowania a legalnym użyciem uprzywilejowanych uprawnień.

To samo rozumowanie dotyczy komputera pracownika. Deweloper może starannie pracować nad logiką kontraktu, jednocześnie obsługując na tej samej maszynie niezwiązane oprogramowanie i komunikację. Powstała ekspozycja należy do środowiska pracy, nawet jeśli sam kontrakt zachowuje się dokładnie zgodnie z zamierzeniem.

Przewodnik opisany w relacji odnosi się do tego otaczającego środowiska poprzez separację urządzeń, praktyki dotyczące poświadczeń i kontrole przed podpisaniem transakcji. Jego zalecenia nie zależą od nowatorskiej możliwości AI. Wymagają od zespołów jasnego określenia zwykłych obowiązków i utrzymywania ich w codziennej pracy.

Wywiera to presję na założycieli i liderów inżynierii w takim samym stopniu jak na indywidualnych deweloperów. Ktoś musi zdecydować, kto może zatwierdzać wrażliwe działania, które urządzenia obsługują te działania oraz jak zgłaszana jest podejrzana aktywność. Te decyzje wymagają właściciela, a nie kolejnego automatycznego skanu.

AI zmienia dyskusję, ponieważ Hon przedstawia bardziej zdolnych atakujących jako powód wzmacniania obrony. To jego deklarowane uzasadnienie, a nie dowód, że AI spowodowała konkretny incydent. Ustalenie udziału AI w ataku wymaga dowodów dotyczących samego ataku.

Implikacja operacyjna pozostaje użyteczna bez silniejszego przypisania przyczyny. Jeśli zespół wdraża automatyzację, aby zwiększyć ilość wykonywanej pracy związanej z bezpieczeństwem, nadal potrzebuje jasnych zasad dotyczących dostępu. Więcej badań nie zmniejsza automatycznie zakresu uprawnień wystawionych przez konta, urządzenia czy procedury podpisywania.

Presja dotyczy także kupujących i partnerów oceniających protokół. Stwierdzenie, że oprogramowanie przeszło automatyczne testy, odpowiada na węższe pytanie niż to, czy organizacja potrafi bezpiecznie je obsługiwać. Recenzenci muszą rozumieć, co zostało zbadane i które obowiązki pozostały poza tym badaniem.

Na przykład raport o zachowaniu kontraktu nie potwierdza, że proces odzyskiwania dostępu przez pracownika jest chroniony. Stwierdzenie o chronionych kontach nie potwierdza, że logika księgowa prawidłowo obsługuje nietypowe sekwencje transakcji. Oba stwierdzenia mogą być użyteczne, gdy ich zakres pozostaje jasny.

To sprawia, że połączony przekaz Hona jest bardziej wymagający niż prośba o wypróbowanie narzędzia. Wzywa zespoły do połączenia technicznego badania z odpowiedzialnością operacyjną. Praktyczne pytanie brzmi, czy ktoś odpowiada za ryzyka pomiędzy tymi działaniami, zwłaszcza gdy każdy specjalista zakłada, że zajmuje się nimi ktoś inny.

Ultrafuzz koordynuje badanie wokół ugruntowanych metod testowania

Propozycja Ultrafuzz dotyczy organizowania pracy nad bezpieczeństwem, w tym pytań badanych przez agentów i dowodów przekazywanych między etapami.

Udostępnienie przez Monad projektu open source 10 września opisuje obsługę Solidity i Vyper, języków programowania używanych do tworzenia smart kontraktów. Podaje, że wydanie oparto na doświadczeniach z ponad 20 uruchomień w ekosystemie. Są to deklaracje fundacji dotyczące rozwoju, a nie niezależna miara ochrony.

Fuzzing, technika testowania generująca zróżnicowane dane wejściowe w poszukiwaniu nieoczekiwanego zachowania, stanowi część przepływu pracy. Inwariant to warunek, który powinien pozostawać prawdziwy w stanach osiąganych przez system. Zdefiniowanie tych warunków nadaje badaniu konkretne pytanie do przetestowania.

Istotny wybór projektowy następuje przed generowaniem danych wejściowych. System potrzebuje użytecznego opisu zamierzonego zachowania, istotnych użytkowników i znaczących warunków awarii. Jeśli ten opis jest niekompletny, obszerne testowanie może bardzo dokładnie badać niewłaściwe pytanie.

Techniczny opis Antonio Viggiano z 21 września śledzi początki projektu w pomocy zespołowi przygotowującemu się do zewnętrznego przeglądu bezpieczeństwa. Opisuje on lukę w testowaniu fuzzingowym oraz próbę zautomatyzowania części pracy. Jego relacja przedstawia Ultrafuzz jako wsparcie dla działania związanego z bezpieczeństwem.

Przepływ pracy mapuje uczestników i działania przed badaniem właściwości. W aplikacji pożyczkowej na przykład pożyczkobiorcy, pożyczkodawcy i likwidatorzy wchodzą w interakcję poprzez różne operacje. Zrozumienie tych relacji pomaga badaczowi rozumować o awariach obejmujących sekwencje, a nie pojedyncze działania.

Ta sekwencja ma znaczenie, ponieważ warunek może być spełniony po pojedynczej operacji, a zawieść po kilku interakcjach. Użyteczne badanie musi uwzględniać zmieniający się stan systemu. Wygenerowanie przekonującego wyjaśnienia awarii pozostaje czymś innym niż uzyskanie dowodu, że awaria występuje.

Ugruntowane narzędzia testowe już rozwiązują części tego problemu. Trail of Bits opisuje Echidna jako fuzzer oparty na właściwościach, a Medusa jako równoległy fuzzer smart kontraktów. Jego narzędzia do testowania kontraktów obejmują również Slither, który analizuje kod bez wykonywania całej aplikacji.

Porównanie dotyczy więc zakresu przepływu pracy, a nie prostego konkursu zastępowania narzędzi. Echidna skupia się na testowaniu dostarczonych właściwości. Ultrafuzz próbuje koordynować szersze badanie wokół celu, obejmujące przygotowanie i interpretację. Organizacja nadal musi ocenić jakość właściwości i uzyskanych dowodów.

Relacja Viggiano omawia również trudności, gdy agenci zależą od wyników poprzednich agentów. Ma to znaczenie, ponieważ skoordynowany przepływ pracy dziedziczy błędy tak samo jak użyteczne informacje. Błędne założenie na wczesnym etapie może wpłynąć na późniejszą pracę, chyba że kolejny etap je zakwestionuje.

Dla wdrażających kluczowe pytanie brzmi, czy ta koordynacja daje wyniki możliwe do zrecenzowania przy mniejszym nakładzie pracy specjalistów. Odpowiedź wymaga zbadania rzeczywistych kampanii. Długi raport lub rozbudowany diagram przepływu pracy nie mogą potwierdzić, że badanie objęło najważniejsze ścieżki awarii protokołu.

Zautomatyzowane ustalenia nadal wymagają odtwarzalnych dowodów

Dowody potrzebne do zaufania ustaleniu dotyczącym bezpieczeństwa są bardziej konkretne niż dowody potrzebne do wygenerowania wiarygodnego ostrzeżenia.

Raport wygenerowany przez AI może opisywać realistyczną awarię, nie potwierdzając, że cel ją dopuszcza. I odwrotnie, badanie może pominąć awarię, ponieważ jego założenia wykluczają istotne zachowanie. Ocena narzędzia wymaga uwagi zarówno wobec niepotwierdzonych ustaleń, jak i pominiętych słabości.

Reproduktor to test lub procedura, która niezawodnie demonstruje zgłoszoną awarię w określonych warunkach. Dla recenzenta łączy wyjaśnienie z obserwowalnym zachowaniem. Bez tego połączenia zespół musi poświęcić dodatkowy wysiłek na ustalenie, czy ostrzeżenie ma zastosowanie.

Znaczenie ma również docelowa rewizja. Oprogramowanie zmienia się w trakcie rozwoju, a ustalenie dotyczące wcześniejszej wersji może już nie opisywać wersji planowanej do wdrożenia. Raport powinien zawierać wystarczający kontekst, by inny recenzent mógł ustalić, który kod i jakie założenia doprowadziły do wyniku.

Wymagania te dotyczą zarówno przeglądów prowadzonych przez ludzi, jak i systemów AI. Automatyzacja zwiększa presję, ponieważ może generować więcej potencjalnych ustaleń, niż zespół jest w stanie natychmiast zbadać. Wartość takich wyników zależy częściowo od tego, jak wyraźnie odróżniają potwierdzone błędy od nierozstrzygniętych podejrzeń.

Przydatna ocena pyta więc, co stało się po pojawieniu się ustalenia. Czy deweloper je odtworzył? Czy zespół zaakceptował leżący u jego podstaw problem? Czy poprawka rozwiązała wykazane zachowanie? Te pytania łączą automatyczne wykrywanie z rezultatem inżynierskim.

Porównania między narzędziami również wymagają starannie określonych granic. Różne cele, wybory modeli, prompty i dostępne zasoby mogą zmienić wyniki. Porównanie, które jednocześnie zmienia kilka warunków, nie pozwala wyodrębnić, która decyzja projektowa przyniosła pozorną poprawę.

Niezależne badania dostarczają kontekstu dla problemu adopcji. Badanie Human Side of Fuzzing przeanalizowało 381 zgłoszeń GitHub dotyczących Echidna i Foundry, zestawu narzędzi do tworzenia smart kontraktów. Badało trudności praktyków w korzystaniu z tych systemów. Badanie nie ocenia Ultrafuzz.

Jego znaczenie polega na rozróżnieniu między dostępną techniką a użytecznym procesem pracy. Narzędzie może odpowiadać na rzeczywistą potrzebę techniczną, a jednocześnie wymagać pracy związanej z konfiguracją, interpretacją i utrzymaniem. Koordynację przez AI należy oceniać pod kątem tych obciążeń, a także wyników wykrywania.

Tworzy to uczciwy standard dla Ultrafuzz. Jego twórcy mogą przedstawić użyteczne dowody, nie twierdząc przy tym, że zapewniają pełne pokrycie ani uniwersalną przewagę. Jasno określone przykłady, odtwarzalne błędy i szczere opisy nieudanych uruchomień pomogłyby osobom z zewnątrz ocenić, gdzie ten proces wnosi wartość.

Odpowiadający temu sceptyczny pogląd nie wymaga odrzucania wspomaganego przez AI badania problemów. Wymaga powstrzymania się przed przejściem od „ten system znalazł problemy” do „ten system zapewnia bezpieczeństwo”. Twierdzenia te mają różne wymagania dowodowe, a to drugie wykracza poza każdą pojedynczą kampanię.

Dla zespołów oceniających promowanie Ultrafuzz przez Keone Hona praktyczna konsekwencja jest prosta. Adopcja powinna tworzyć artefakty, które inna osoba może sprawdzić i zakwestionować. Zaufanie powinno rosnąć na podstawie tych artefaktów i sposobu rozwiązania problemów, a nie liczby zaangażowanych agentów.

Nieograniczeni agenci sprawiają, że środowisko operacyjne staje się częścią oceny

Własne ostrzeżenie Ultrafuzz sprawia, że izolacja jest warunkiem odpowiedzialnej oceny, a nie szczegółem rozważanym dopiero po rozpoczęciu testów.

Projektowe ostrzeżenie dotyczące bezpieczeństwa agentów zaleca jednorazowe, odizolowane maszyny wirtualne, czyli programowe komputery oddzielone od zwykłej stacji roboczej. Stwierdza, że agenci działają z nieograniczonymi uprawnieniami. Ostrzega również przed środowiskami zawierającymi wartościowe dane lub poświadczenia.

To ostrzeżenie zmienia znaczenie wypróbowania narzędzia. Deweloper pozwala oprogramowaniu wykonywać działania w środowisku, zamiast jedynie prosić o komentarz do wklejonego kodu. Uprawnienia dostępne w tym środowisku stają się częścią oceny.

Izolacja ogranicza konsekwencje niezamierzonych działań. Nie dowodzi jednak, że każde wygenerowane ustalenie jest poprawne ani że każdemu istotnemu zachowaniu kontraktu poświęcono uwagę. Ograniczenie ryzyka operacyjnego i dokładność analityczna pozostają odrębnymi wymaganiami, nawet gdy oba wpływają na użyteczność kampanii.

To rozróżnienie dotyczy również poufnego kodu. Odizolowana maszyna może ograniczyć dostęp do niepowiązanych plików, jednocześnie nadal przechowując wrażliwe materiały projektowe potrzebne do analizy. Zespół musi rozumieć, jak materiały te są obsługiwane w całej wybranej konfiguracji.

Ma to szczególne znaczenie, gdy organizacja posiada już zasady przeglądu zewnętrznego oprogramowania. Narzędzie bezpieczeństwa powinno przejść przez ten sam proces decyzyjny co inne oprogramowanie mające dostęp do repozytorium. Jego defensywny cel nie eliminuje potrzeby zrozumienia jego uprawnień.

Nie ma tu podstaw, by twierdzić, że Ultrafuzz naruszył bezpieczeństwo stacji roboczej użytkownika. Udokumentowane ostrzeżenie określa deklarowane ryzyko i granicę wdrożenia. Nie powinno być przekształcane w zarzut, że doszło do konkretnego szkodliwego zdarzenia.

Bardziej użyteczna interpretacja dotyczy odpowiedzialności. Ktoś musi przygotować środowisko, zdecydować, co do niego trafia, i przejrzeć wynikowe artefakty. Zautomatyzowane etapy kampanii nie eliminują tych obowiązków. Sprawiają, że przekazanie odpowiedzialności między aktywnością maszyny a ludzką oceną staje się ważniejsze.

To miejsce, w którym narzędzie i argument OpSec spotykają się najbezpośredniej. Zespół wdrażający AI do badania kontraktów musi stosować dyscyplinę operacyjną również wobec tego badania. W przeciwnym razie ryzykuje potraktowanie procesu bezpieczeństwa jako wyjątku od praktyk, których oczekuje w innych obszarach.

Istnieje też konsekwencja zakupowa dla organizacji oceniających podobne produkty. Wymagania wdrożeniowe powinny należeć do porównania obok obsługiwanych języków i funkcji raportowania. Użyteczność narzędzia zależy częściowo od tego, czy organizacja może obsługiwać je zgodnie ze swoimi wymaganiami dotyczącymi dostępu i poufności.

Wynikający z tego kompromis jest konkretny. Większa autonomia pozwala agentom wykonywać więcej pracy bez stałej interwencji, podczas gdy środowisko musi ograniczać konsekwencje tej autonomii. Właściwa ocena uwzględnia całą kampanię, w tym przygotowanie, wykonanie, przegląd i usunięcie środowiska.

Promowanie Ultrafuzz przez Keone Hona nie może więc być oceniane wyłącznie na podstawie tego, czy deweloperzy uruchamiają kampanie. Silniejszym sygnałem adopcji byłoby pokazanie, że zespoły przestrzegają udokumentowanych granic i zachowują jasną odpowiedzialność za wyniki. Uruchomienie oprogramowania jest tylko częścią dobrego korzystania z niego.

Obserwuj zweryfikowane ustalenia, trwałe użycie i zmiany operacyjne

Kolejne dowody powinny łączyć zautomatyzowane badanie z poprawkami, powtarzalnym użyciem i silniejszą kontrolą nad wrażliwymi operacjami.

Pierwszym sygnałem wartym obserwacji są ustalenia, które można niezależnie odtworzyć. W nadchodzących miesiącach szczegółowe ujawnienia mogą pokazać, który cel został zbadany, jakie zachowanie zawiodło oraz jak inny recenzent to potwierdził. Takie dowody wzmocniłyby argument, że proces wnosi wartość wykraczającą poza generowanie potencjalnych ostrzeżeń.

Zaakceptowane poprawki dodałyby kolejne użyteczne powiązanie. Opublikowane ustalenie może być interesujące, nie wpływając na wdrożony system. Dowody, że deweloperzy zrozumieli i naprawili problem, pokazałyby, jak wykrycie przełożyło się na pracę inżynierską.

Brak publicznych ujawnień nie dowodziłby niepowodzenia. Zespoły mogą zachować ustalenia w poufności podczas wprowadzania poprawek, a terminy ujawnień mogą się różnić. Pozostawiłoby to jednak zewnętrznym obserwatorom mniej dowodów do niezależnej oceny skuteczności.

Drugim sygnałem jest trwałe użycie wykraczające poza początkową próbę. Zespół powracający do narzędzia po zmianach w kodzie dostarczyłby innego sygnału adopcji niż jednorazowa demonstracja. Powtarzalne użycie sugerowałoby, że proces pasuje do bieżącego procesu rozwoju.

Sygnał ten staje się silniejszy, gdy użytkownicy wyjaśniają wymagany wysiłek. Relacje o trudnościach z konfiguracją, nieudanych kampaniach, czasie przeglądu i użytecznych wynikach pomogłyby innym zespołom ocenić przydatność. Bezwarunkowe pochwały dostarczają mniej praktycznych informacji niż jasne wyjaśnienie, gdzie proces pomógł.

Sama uwaga poświęcana repozytorium nie może odpowiedzieć na te pytania. Zainteresowanie publiczne może odzwierciedlać ciekawość, promocję lub badania, a nie użycie produkcyjne. Twierdzenia o adopcji stają się bardziej informacyjne, gdy opisują wykonane zadanie i osoby odpowiedzialne za przegląd wyniku.

Trzecim sygnałem jest zmiana operacyjna towarzysząca testom technicznym. Zespoły stosujące szerszy apel Hona przeanalizowałyby uprzywilejowany dostęp, ustalenia dotyczące podpisywania oraz rozdzielenie wrażliwej pracy. Takie działania wspierałyby argument, że przekaz wykraczał poza analizę kontraktów.

Raport z kampanii nie może wykazać, że takie zmiany nastąpiły. Dowody musiałyby pochodzić od organizacji obsługujących protokoły, z zachowaniem odpowiedniej ostrożności wobec wrażliwych szczegółów. Jasna odpowiedzialność i udokumentowane procesy byłyby bardziej znaczące niż ogólne deklaracje o poważnym traktowaniu bezpieczeństwa.

Sygnały te testują różne części tej samej tezy. Zweryfikowane ustalenia oceniają użyteczność analityczną. Trwałe użycie ocenia praktyczne dopasowanie. Zmiany operacyjne oceniają, czy silniejszym testom towarzyszy silniejsza kontrola nad systemami administrującymi oprogramowaniem.

Dla deweloperów natychmiastowym działaniem jest określenie, jakie dowody uzasadniałyby przyjęcie tego procesu przed rozpoczęciem kampanii. Wskaż, kto będzie przeglądał ustalenia, jak błędy będą odtwarzane oraz które środowisko spełnia wymagania operacyjne projektu. Dla nabywców i partnerów pytanie brzmi: co właściwie obejmuje wynikowy raport i które obowiązki pozostają poza nim. Promowanie Ultrafuzz przez Keone Hona stanowi użyteczny powód, by wrócić do tych pytań. Przeczytaj udokumentowane granice, porównaj je z praktykami swojej organizacji i zapytaj, czy następne ćwiczenie bezpieczeństwa przyniesie zarówno lepsze dowody, jak i jaśniejszą odpowiedzialność za ryzyka, których te dowody nie mogą rozstrzygnąć.