Przegląd wyzwań związanych z bezpieczeństwem

Jedną z kluczowych cech blockchainów jest atomowy charakter transakcji — po zarejestrowaniu aktualizacji w blockchainie nie ma możliwości zmiany ani cofnięcia transakcji. Zapewnia to silne gwarancje spójności i bezpieczeństwa na poziomie protokołu, ale jednocześnie naraża użytkowników na zwiększone ryzyko operacyjne — pojedynczy błąd, skompromitowany klucz czy pochopne zatwierdzenie mogą prowadzić do nieodwacalnej utraty środków.

W rezultacie duża część odpowiedzialności za bezpieczeństwo spoczywa na użytkownikach. Aby korzystać z Ethereum w sposób bezpieczny, zarówno użytkownicy indywidualni, jak i organizacje, muszą przechowywać i zarządzać kluczami, korzystać z aplikacji w łańcuchu oraz podpisywać transakcje w celu transferu aktywów lub jakkolwiek aktualizować stan Ethereum w sposób ostrożny.

Każdy z tych wymogów wprowadza ryzyka, takie jak kompromitacja lub utrata klucza, pośpieszne lub nieświadome zatwierdzenia czy kompromitacja samego oprogramowania portfela, na którym polegają użytkownicy, aby informował ich oraz prowadził podczas interakcji z Ethereum.

1.1 Zarządzanie kluczami

Wielu użytkowników nie jest przygotowanych do bezpiecznego zarządzania kluczami kryptograficznymi.

Najczęściej wykorzystywane portfele programowe wymagają od użytkowników przechowywania frazy ziarna reprezentującej ich podstawowy kryptograficzny klucz prywatny, co często prowadzi do stosowania niebezpiecznych praktyk, takich jak zapisywanie jej w pliku tekstowym, w usługach chmurowych lub na kartce papieru.

Portfele sprzętowe stanowią alternatywę, która umożliwia użytkownikom zarządzanie kluczem kryptograficznym przechowywanym w specjalnym fizycznym urządzeniu. Jednak mają one również swoje wady i powierzchnię ataku. Mogą zostać zgubione, uszkodzone lub skradzione. Wiele portfeli sprzętowych nie jest otwartoźródłowych i może mieć nieprzejrzyste łańcuchy dostaw, co zwiększa ryzyko ataku na łańcuch dostaw, w wyniku którego na rynek trafiają skompromitowane urządzenia.

Niezależnie od tego, czy klucze są zarządzane w portfelu programowym czy sprzętowym, wielu użytkowników obawia się samodzielnego przechowywania kluczy, ponieważ mogą zostać skompromitowane w wyniku fizycznej kradzieży lub napaści.

Użytkownicy korporacyjni i instytucjonalni stoją przed dodatkowymi wyzwaniami w zakresie zarządzania kluczami. Jeśli poszczególni pracownicy posiadają klucze (np. w ramach portfela wielopodpisowego), organizacja musi mieć możliwość ich zastąpienia i stworzenia nowych w wyniku zachodzących w czasie zmian kadrowych. Wymogi zgodności w różnych branżach i jurysdykcjach mogą wymagać niestandardowych przepływów pracy lub procedur audytowych, które nie są obsługiwane przez istniejące oprogramowanie portfela. W niektórych przypadkach użytkownicy korporacyjni korzystają z usług zewnętrznych powierników aktywów cyfrowych, co może wprowadzać dodatkową warstwę ryzyka bezpieczeństwa, którą również należy wziąć pod uwagę.

1.2 Podpisywanie w ciemno i niepewność transakcji

Użytkownicy rutynowo zatwierdzają transakcje „w ciemno”, bez pełnego zrozumienia tego, co robią. Portfele często prezentują surowe dane w formacie szesnastkowym, skrócone adresy kontraktów lub inne informacje, które nie są wystarczające, aby użytkownik mógł zrozumieć konsekwencje danej transakcji. Naraża to wszystkich użytkowników na złośliwe inteligentne kontrakty, oszustwa np. phishingowe, sfałszowane czy skompromitowane interfejsy oraz podstawowe błędy użytkowników.

1.3 Zarządzanie zgodami i uprawnieniami

W wielu aplikacjach Ethereum powszechne jest przyznawanie przez użytkowników określonych uprawnień aplikacji w ramach normalnego użytkowania. Na przykład użytkownik może przyznać zdecentralizowanej giełdzie, takiej jak Uniswap, prawo do przeniesienia swoich tokenów w celu wymiany ich na ETH.

Te zgody mogą mieć limity ilościowe, ale wiele portfeli domyślnie przyznaje nieograniczone zatwierdzenia bez daty wygaśnięcia. Większość portfeli nie oferuje użytkownikom możliwości zarządzania ani przeglądania aktywnych zgód.

Może to wystawić użytkowników na ryzyko ze strony złośliwych aplikacji lub skompromitowanych interfejsów, ponieważ domyślnym zachowaniem wielu użytkowników jest przyznawanie nielimitowanych zatwierdzeń, które mogą zostać użyte do wyczerpania ich środków. Nawet jeśli użytkownik przyzna zgodę wiarygodnemu inteligentnemu kontraktowi, a ten kontrakt zostanie później skompromitowany, to tak długo, jak zgoda jest aktywna, może posłużyć do wyczerpania środków użytkownika.

To samo ryzyko dotyczy użytkowników instytucjonalnych. Przykładowo, organizacja może przyznać routerowi zdecentralizowanej giełdy nieograniczony limit USDC dla wygody operacyjnej, co wystawi ją na ryzyko w przypadku aktualizacji kontraktu routera.

1.4 Skompromitowane interfejsy internetowe

Większość użytkowników nie wchodzi w bezpośrednią interakcję z inteligentnymi kontraktami, lecz poprzez interfejs internetowy w przeglądarce lub aplikacji na telefonie.

Takie interfejsy mogą być podatne na ataki znanymi metodami, takimi jak zatruwanie DNS, złośliwe wstrzyknięcia kodu JavaScript, niezabezpieczone hostingi czy podatności różnych zewnętrznych zależności. Skompromitowany interfejs aplikacji może kierować użytkowników wszelkiego rodzaju do złośliwych inteligentnych kontraktów lub skłaniać do podpisania wprowadzających w błąd transakcji.

1.5 Prywatność

Prywatność może zarówno zmniejszać, jak i zwiększać ryzyka bezpieczeństwa dla wszystkich użytkowników.

Słabsze zabezpieczenia prywatności narażają indywidualnych użytkowników na różne ukierunkowane zagrożenia, takie jak phishing, wykorzystywanie luk, oszustwa czy ataki fizyczne. Wiele popularnych wzorców interfejsu naraża użytkowników, np. ponowne wykorzystanie adresu, dane KYC czy wycieki innych metadanych.

Dla instytucji i przedsiębiorstw prywatność jest często kluczowym wymogiem biznesowym ze względów regulacyjnych lub związanych z określonymi przypadkami użycia. W dodatku może ona również narażać na określone zagrożenia bezpieczeństwa. Przykładowo, użytkownik systemu łańcucha dostaw opartego na Ethereum może wymagać silnych gwarancji prywatności, aby chronić własność intelektualną, która w przeciwnym razie mogłaby zostać ujawniona przy pełnej transparentności systemu.

1.6 Podział

Brakuje spójności w tym, jak różne portfele obsługują kluczowe funkcje, takie jak wyświetlanie transakcji, zarządzanie zatwierdzeniami czy oznaczanie kontraktów. Ten podział doświadczeń użytkownika utrudnia użytkownikowi naukę bezpiecznego korzystania z portfeli i zwiększa ryzyko.

Na przykład użytkownicy nie mogą polegać na jednolitych cechach w interfejsie UX, aby chronić się przed phishingiem czy spoofingiem, ponieważ różnią się one w zależności od portfela. Brak spójności sprawia, że użytkownicy nie mogą mieć wiarygodnych oczekiwań co do tego, jak działa Ethereum, skoro każde narzędzie funkcjonuje inaczej.

Bezpieczeństwo inteligentnych kontraktów uległo radykalnej poprawie od początku historii Ethereum. Wczesne incydenty związane z bezpieczeństwem, takie jak atak na DAO, zmotywowały ekosystem do profesjonalizacji i ulepszenia zabezpieczeń w całym cyklu życia oprogramowania, które prowadzi do wdrożenia kodu do łańcucha. Kluczowe postępy obejmują:

• Audyty bezpieczeństwa stały się normą, a szereg firm zajmujących się bezpieczeństwem wkroczyło do ekosystemu i zdobyło specjalistyczną wiedzę.
• Narzędzia, testowanie i systemy analizy statycznej dojrzały i stały się normą.
• Biblioteki wstępnie zaudytowanych podstawowych komponentów dały deweloperom domyślnie bezpieczne elementy do tworzenia.
• Techniki formalnej weryfikacji zostały zaadoptowane, zwłaszcza w przypadku mostów, systemów stakingowych czy kontraktów o wysokiej wartości.
• Kultura bezpieczeństwa i najlepsze praktyki w ekosystemie uległy poprawie.
• Utworzenie istotnych programów nagród za błędy wzmocniło warstwę aplikacyjną.

Jednakże wciąż istnieją słabości i obszary wymagające poprawy w tym zakresie.

2.1 Podatności kontraktów

Pomimo postępów w zakresie bezpieczeństwa inteligentnych kontraktów, nadal występują podatności, które mogą prowadzić do poważnych problemów związanych z bezpieczeństwem, w tym:

• Ryzyko aktualizacji kontraktów. Niektóre kontrakty są projektowane tak, aby mogły być modyfikowane po wdrożeniu, co pozwala zespołowi deweloperskiemu na aktualizację lub ulepszenie aplikacji. Jednak wprowadza to ryzyko. Aktualizacje mogą wprowadzić nowe luki lub doprowadzić do całkowitej utraty środków użytkownika w przypadku złośliwej aktualizacji.
• Wielobieżność, czyli sytuacja, w której kontrakt A wywołuje zewnętrzny kontrakt B przed zaktualizowaniem swojego wewnętrznego stanu, a kontrakt B wywołuje ponownie kontrakt A, zanim skończy się pierwsze wywołanie.
• Niebezpieczne użycie zewnętrznych bibliotek, czyli kiedy kontrakt odwołuje się do zewnętrznej biblioteki, która może nie mieć audytu, być złośliwa lub mieć możliwość aktualizacji.
• Komponenty niepoddane audytowi. Mimo poprawy audytów i używania standardowych bibliotek, deweloperzy czasami opierają swoje aplikacje na komponentach niepoddanych audytom.
• Błędy kontroli dostępu, czyli kiedy uprawnienia są źle skonfigurowane lub zbyt szeroko zdefiniowane, co może pozwolić atakującym na szkodliwe działania.
• Nieautoryzowany dostęp, występuje wtedy, gdy klucz prywatny zdolny do kontrolowania kontraktem zostaje przejęty przez złośliwy podmiot.
• Mosty i interakcje międzyłańcuchowe. Mosty i protokoły międzyłańcuchowe wprowadzają dodatkową złożoność, a atakujący mogą wykorzystać słabość w tym, w jaki sposób wiadomości międzyłańcuchowe są przekazywane lub walidowane.
• Delegacja kont zewnętrznych (EOA) lub nadużycie podpisów. Złośliwe aplikacje mogą nakłonić użytkownika do podpisania pełnej delegacji swojego konta innemu podmiotowi, umożliwiając kradzież środków. Złośliwe aplikacje mogą również wykorzystać podpisane wiadomości od użytkownika w nieoczekiwany sposób, np. w ataku typu replay.
• Pojawiające się ryzyko błędów wprowadzone przez generowanie kodu przez SI lub narzędzia do automatycznej przebudowy kody.

2.2 Doświadczenie deweloperów, narzędzia i języki programowania

Podatności trafiają do wdrożonego kodu z powodu błędów deweloperów. Ulepszanie narzędzi deweloperskich znacznie ułatwiło wdrażanie bezpiecznych inteligentnych kontraktów. Nadal jednak istnieją problemy.

• Brak bezpiecznych ustawień domyślnych w popularnych frameworkach. Niektóre narzędzia stawiają na elastyczność lub szybkość zamiast na bezpieczeństwo, ustawiając niebezpieczne ustawienia domyślnie, jak na przykład nieograniczone zatwierdzenia tokenów w funkcji approve() czy nieuwzględnienie domyślnie wzorców kontroli dostępu.
• Niestandardowy kod dla zaawansowanych kontroli operacyjnych. Użytkownicy instytucjonalni o złożonych wymaganiach operacyjnych muszą często tworzyć wymagane funkcje od podstaw, co zwiększa ryzyko wystąpienia luk w zabezpieczeniach. Brakuje ustandaryzowanych i bezpiecznych komponentów lub frameworków dla zaawansowanych procesów bezpieczeństwa.
• Niespójny zakres testów w różnych stosach narzędziowych, jak również brak norm dotyczących stosowania sprawdzonych technik, takich jak fuzzing czy sprawdzanie niezmienników.
• Niska adopcja formalnych metod weryfikacji. Formalne techniki weryfikacji są potężne, ale złożone, kosztowne, wymagają specjalistycznej wiedzy i nie są dobrze zintegrowane ze standardowymi procesami deweloperskimi, gdzie mogłyby być używanie znacznie wcześniej w produkcji oprogramowania do weryfikacji bezpieczeństwa już na etapie specyfikacji.
• Problemy związane z weryfikacją kontraktów. Użytkownicy i deweloperzy nie mogą w łatwy sposób ocenić wiarygodności wdrożonych kontraktów, zakresu ich walidacji bezpieczeństwa (np. audytów kodu) ani obecności ukrytych ryzyk. Choć istnieją rozwiązania tego problemu, wiele kwestii pozostaje wciąż nierozwiązane. Narzędzia adresujące te kwestie nie są powszechnie stosowane, standardy, które mogłyby ujednolicić podejścia, pozostają podzielone, a niektóre z istniejących usług same w sobie są scentralizowanymi zależnościami.
• Ryzyka kompilatora. Kompilatory (oprogramowanie, które przekształca kod czytelny dla człowieka, taki jak Solidity, na kod bajtowy używany przez EVM) mogą zawierać wady, które wprowadzają błędy do inteligentnych kontraktów jeszcze przed ich wdrożeniem. Ekosystem Ethereum obecnie polega w dużej mierze na kompilatorze solc, co oznacza, że jeden błąd może stworzyć poważne konsekwencje.
• Różnorodność języków programowania i ich możliwości. Chociaż Solidity posiada rozbudowany ekosystem narzędzi, niektórzy deweloperzy mogą chcieć bardziej nowoczesnych funkcji bezpieczeństwa takich jak bezpieczeństwo pamięci, które są dostępne w innych językach programowania.

2.3 Ocena ryzyka kodu w łańcuchu

Instytucje i przedsiębiorstwa mają własne procesy, standardy i wymagania dotyczące oceny bezpieczeństwa technologii i systemów, na których się opierają. Jednak istniejące ramy często nie odnoszą się w sposób jednoznaczny do inteligentnych kontraktów, ponieważ zazwyczaj zakładają zmienny kod, scentralizowaną kontrolę zmian oraz jasny podział odpowiedzialności lub odpowiedzialności prawnej. Systemy oparte na inteligentnych kontraktach mogą czasami łamać te założenia, co utrudnia organizacjom adopcję Ethereum i odpowiednie zarządzanie ryzykiem.

Systemy te stanowią powierzchnię ataku zarówno dla portfela i warstwy aplikacji (np. punkty końcowe RPC dla portfeli), jak i samego protokołu Ethereum (np. wielu walidatorów jest hostowanych w infrastrukturze chmurowej). Kompromitacja klucza prywatnego, phishing i brak szczegółowych mechanizmów kontroli dostępu może prowadzić do awarii na szeroką skalę, kradzieży lub nieautoryzowanych zmian, nawet jeśli podstawowy protokół blockchainu sam w sobie pozostaje bezpieczny.

3.1 Łańcuchy warstwy 2

Łańcuchy warstwy 2 (L2) działają jako rozszerzenia Ethereum, umożliwiając szybsze środowiska z tańszymi opłatami, zachowując jednocześnie część charakterystycznych gwarancji bezpieczeństwa sieci głównej Ethereum (w zależności od ich konkretnej konstrukcji). Mają one jednak swoje własne powierzchnie ataku, w tym:

• Złożoność wieloetapowego przenoszenia aktywów. Gdy aktywa przemieszczają się pomiędzy warstwą 1 a wieloma warstwami 2, są narażone na wiele zestawów kontraktów, z których wszystkie muszą być bezpieczne. Niezgodności w rozliczeniach lub awarie w łańcuchach warstwy 2 mogą wprowadzać luki, które mogą zostać wykorzystane przez atakujących.
• Warstwy 2 pakietów zbiorczych opierają się na systemach dowodowych w celu egzekwowania poprawności aktualizacji stanu. Błędy lub błędne konfiguracje w tych systemach mogą zatrzymać lub uniemożliwić finalizację, albo pozwolić na finalizację nieprawidłowych aktualizacji stanu, prowadząc do utraty środków użytkowników.
• Rady bezpieczeństwa to grupy posiadaczy kluczy, którzy pełnią funkcję „zapasowego” mechanizmu do aktualizacji oprogramowania warstwy 2 lub reagowania na określone sytuacje awaryjne. Rady bezpieczeństwa same w sobie stanowią ryzyko, ponieważ kompromitacje lub zmowy między członkami mogą narazić środki użytkowników lub zamrozić aktywa.

Sprawdź L2Beat (opens in a new tab), aby zapoznać się ze szczegółowymi ramami i panelem monitorowania, który ocenia i porównuje wydajność i bezpieczeństwo różnych warstw 2.

3.2 Infrastruktura węzłów i RPC

Aplikacje Ethereum są zależne od niewielkiej liczby dostawców infrastruktury zapewniających dostęp RPC, interfejsy API i usługi węzłów. Obejmuje to dostawców infrastruktury specyficznej dla kryptowalut, a także tradycyjne usługi chmurowe, powszechnie wykorzystywane do hostowania węzłów (np. AWS, Cloudflare, Hetzner).

Gdyby ci dostawcy infrastruktury mieli awarię lub próbowali cenzurować bądź ograniczać dostęp, wielu użytkowników mogłoby zostać pozbawionych możliwości korzystania z Ethereum za pośrednictwem swojego portfela czy aplikacji, dopóki nie udałoby się im przejść na nowy RPC lub innego dostawcę infrastruktury. Niektórzy z tych dostawców wcześniej zawieszali już lub zamyki konta powiązane z działalnością blockchainową, co budzi obawy o ich długoterminową niezawodność dla zdecentralizowanych aplikacji.

3.3 Podatności na poziomie DNS

System nazw domen (DNS) to podstawowa warstwa internetu, która jest jednocześnie scentralizowana i podatna na kompromitację. Wielu użytkowników uzyskuje dostęp do aplikacji przez domeny internetowe, które są narażone na:

• Zatruwanie DNS, w którym atakujący podstawia użytkownikowi złośliwą, fałszywą stronę.
• Przejęcie domeny, w którym rząd lub rejestrator może przejąć domenę.
• Phishing za pomocą łudząco podobnych domen, gdzie atakujący rejestrują niemal identyczne nazwy w celu zmylenia użytkowników.

3.4 Łańcuch dostaw oprogramowania i biblioteki

Deweloperzy Ethereum opierają się na otwartoźródłowych bibliotekach, często pobieranych bezpośrednio z serwisów takich jak npm, crates.io czy GitHub. Jeśli te biblioteki zostaną skompromitowane, mogą stać się celem ataków, takich jak:

• Wstrzyknięcie złośliwego pakietu, gdzie atakujący kompromituje powszechnie używany pakiet lub publikuje pakiet o podobnej nazwie
• Przejęcie zależności, gdzie osoby odpowiedzialne za utrzymanie projektu tracą nad nim kontrolę, a złośliwy podmiot wprowadza szkodliwy kod
• Kompromitacja dewelopera, gdzie zainstalowane pakiety zawierają kod dający atakującemu kontrolę nad komputerem dewelopera.

3.5 Usługi dostarczania interfejsów i powiązane ryzyka

Wiele aplikacji Ethereum obsługuje swoje interfejsy za pośrednictwem sieci dostarczania zawartości (CDN) lub platform hostingowych w chmurze (np. Vercel, Netlify, Cloudflare). Jeśli te usługi zostaną skompromitowane, mogą posłużyć jako cel ataku, np. poprzez wstrzyknięcie złośliwego kodu JavaScript, w którym atakujący udostępniają użytkownikom zmodyfikowany interfejs.

3.6 Cenzura na poziomie dostawców internetu

Dostawcy usług internetowych (ISP) lub państwa mogą wykorzystywać kontrolę nad infrastrukturą internetową do cenzurowania dostępu do Ethereum. Przykłady takich ataków obejmują:

• Blokowanie lub ograniczanie ruchu na powszechnie używanych przez Ethereum portach
• Filtrowanie żądań DNS, które odnoszą się do usług związanych z Ethereum
• Geograficzne ogradzanie lub blokowanie adresu IP znanych węzłów Ethereum
• Dogłębne analizowanie pakietów w celu identyfikacji i cenzurowania ruchu związanego z protokołem Ethereum

Wiele z tych podstawowych technik jest już obecnie stosowanych przez autorytarne rządy na całym świecie do tłumienia dostępu do informacji, narzędzi protestacyjnych czy kryptowalut.

Protokół konsensusu Ethereum sprawdził się w praktyce, działając bez przerw od momentu pierwszego uruchomienia w 2015 roku i podczas kilku uaktualnień. Nadal jednak istnieją długoterminowe obszary do poprawy, aby system stał się jeszcze bardziej odporny i bezpieczny.

4.1 Kruchość konsensusu i ryzyka odzyskiwania

Zasady wyboru forka i finalizacji w Ethereum są odporne, ale nie są niezniszczalne. W pewnych skrajnych przypadkach (takich jak długotrwale nieporozumienia walidatorów, błędy klientów czy podziały sieci) konsensus może się zatrzymać lub chwilowo rozdzielić. W ekstremalnych warunkach mogłoby to prowadzić do kaskadowych kar dla walidatorów poprzez wycieki nieaktywności lub odcięcia, co z kolei mogłoby spowodować opływ kapitału od walidatorów.

4.2 Różnorodność klientów

Przodująca w branży różnorodność klientów Ethereum chroni sieć przed błędami w pojedynczym kliencie. Jednak różnorodność klientów mogłaby zostać jeszcze bardziej poprawiona poprzez większą adopcję klientów mniejszościowych, aby jeszcze bardziej zmniejszyć te ryzyka.

4.3 Centralizacja stakingu i dominacja pul

Znacząca część wagi walidatorów jest skoncentrowana w protokołach płynnego stakingu, usługach powierniczych i u dużych operatorów węzłów. Ta koncentracja może prowadzić do ryzyk, takich jak:

• Przejęcie lub wpływ na zarządzanie. Jeśli podmioty kontrolujące duże ilości zestakowanej wartości (lub podmioty mające prawne możliwości wywierania wpływu na te podmioty) skoordynowałyby działania, mogłyby uzyskać nieproporcjonalny wpływ na to, które bloki są proponowane i poświadczane, potencjalnie cenzurując użytkowników lub wpływając na aktualizacje protokołu.
• Jednorodność w wyborze klientów i konfiguracji infrastruktury, co może zwiększać ryzyko powiązanych awarii.

4.4 Niezdefiniowane odcięcia społeczne i luki w koordynacji

W niektórych skrajnych przypadkach awarii, Ethereum polegałoby na „społecznych odcięciach”, aby ukarać walidatorów, którzy działali złośliwie w celu zaatakowania sieci (patrz sekcja 6.1). Jednak infrastruktura, normy i oczekiwane procesy dla tego rodzaju kar są niedorozwinięte. Brakuje ustalonego mechanizmu, którego społeczność mogłaby użyć, aby przeprowadzić ten proces.

4.5 Wektory ataków ekonomicznych i strategicznych

Wiele potencjalnych wektorów ataków ekonomicznych pozostaje słabo zbadanych, w tym:

• Ataki griefingowe lub griefing odcięć. Walidatorzy mogą ponosić koszty lub kary za odcięcia nie z powodu własnych błędów, lecz w wyniku wrogich zachowań mających na celu wyłącznie wyrządzenie szkody innym, nawet kosztem strat dla atakującego.
• Strategiczne wyjścia lub celowa nieaktywność. Walidatorzy mogą celowo przechodzić offline lub wychodzić w krytycznych momentach, aby zmaksymalizować zyski lub zakłócić konsensus przy minimalnych karach.
• Zmowa walidatorów i przekaźników. Skoordynowane działania między walidatorami lub między przekaźnikami a walidatorami mogłyby zmniejszyć decentralizację lub wydobyć MEV.
• Eksploitacja rzadkich przypadków zachęt w MEV, separacji proponujący-budujący czy konstrukcji płynnego stakingu. Podmioty mogą manipulować rzadkimi warunkami protokołu, aby uzyskać nieproporcjonalne nagrody.

4.6 Ryzyko kwantowe

Główna kryptografia Ethereum (np. podpisy krzywych eliptycznych, takich jak secp256k1) może pewnego dnia zostać złamana przez komputery kwantowe. Choć nie jest to bezpośrednie zagrożenie, wiarygodna groźba mogłaby natychmiast uczynić istniejące portfele, kontrakty i klucze stakingowe podatnymi na ataki. To przyszłe wyzwanie osłabia długoterminowe gwarancje Ethereum wobec użytkowników.

Drogi migracji do kryptografii odpornej na komputery kwantowe (np. poprzez schematy podpisów postkwantowych) muszą zostać zaprojektowane, przetestowane i ewentualnie wbudowane w protokół lata przed tym, zanim będą potrzebne. Organizacje w całym ekosystemie Ethereum, wliczając w to Fundację Ethereum, aktywnie badają te opcje i monitorują ryzyka.

Nawet wyidealizowany ekosystem blockchain będzie narażony na ryzyka, ataki oraz podatności. Gdy coś pójdzie nie tak, muszą istnieć skuteczne systemy łagodzenia, wykrywania i reagowania. Wyzwania w tym obszarze obejmują:

• Dotarcie do poszkodowanego zespołu. Kontakt z zespołem, którego aplikacja została naruszona, może być trudny. Może to prowadzić do wielogodzinnych opóźnień, ograniczając zdolność osób reagujących do odzyskania środków.
• Eskalację problemów w powiązanych organizacjach. Gdy problem dotyczy platformy (takiej jak sieć społecznościowa lub scentralizowana giełda), eskalacja problemu może stanowić wyzwanie dla osób reagujących, jeśli nie mają one wcześniej istniejącego kontaktu.
• Koordynacja działań. Często nie jest jasne, ile zespołów reagowania na incydenty pomaga aplikacji dotkniętej problemy, co prowadzi do nieporozumień lub marnowania wysiłków w sytuacjach, w których wspólne działania mogłyby być skuteczniejsze.
• Brak możliwości monitorowania. Trudno jest monitorować problemy zarówno w łańcuchu, jak i poza nim, co utrudnia wczesne ostrzeganie i zapewnienie szybkiej reakcji na zagrożenia.
• Dostęp do ubezpieczenia. Ubezpieczenie jest kluczowym narzędziem łagodzenia strat w większości tradycyjnych systemów zajmujących się pieniędzmi, systemami finansowymi, tożsamością i innymi wartościowymi informacjami. Jednak obecnie tradycyjne usługi finansowe oferują niewiele opcji ubezpieczeniowych dla ekosystemów kryptowalutowych.

Ryzyka te mają zazwyczaj charakter długoterminowy i dotyczą całego Ethereum, a nie bezpieczeństwa pojedynczych użytkowników czy aplikacji.

6.1 Centralizacja zestakowanej wartości

Centralizacja dużych ilości zestakowanej wartości może stwarzać zagrożenie dla całego Ethereum, jeśli podmioty kontrolujące tę wartość zdecydują się na zmowę.
Taka ekonomiczna centralizacja stwarza możliwość przejęcia kontroli nad zarządzaniem społecznym. Jeśli niewielka grupa walidatorów kontrolowałaby większość zestakowanej wartości, mogliby:

• Koordynować działania przy forkach lub się im opierać.
• Cenzurować określone transakcje lub kontrakty.
• Podważać konsensus społeczności, grożąc wyjściem lub sprzeciwem.

Jeśli taki skrajny scenariusz miałby miejsce, społeczność Ethereum zasugerowała, że odpowiedzią mogłyby być „społeczne odcięcia”. Jest to wykorzystanie poza łańcuchowego konsensusu społecznego do odcinania walidatorów działających w sposób szkodliwy, jako forma kontroli ich władzy. Jednak brak jest jasnych norm, procedur czy narzędzi, aby takie środki skutecznie wdrożyć (patrz sekcja 4.4).

6.2 Centralizacja aktywów poza łańcuchowych

Ethereum obsługuje znaczące ilości aktywów ze świata rzeczywistego, które są przechowywane poza łańcuchem na rachunkach bankowych lub innych depozytach, a następnie są przedmiotem obrotu w łańcuchu za pośrednictwem tokenów reprezentujących roszczenia do aktywów poza łańcuchem. Dla przykładu wiele dużych stablecoinów działa właśnie w ten sposób.

Instytucje, które przechowują depozyty poza łańcuchem, mogą mieć wpływ na ekosystem Ethereum. Na przykład w ekstremalnych scenariuszu, w którym doszłoby do kontrowersyjnego forka lub aktualizacji sieci, duzi depozytariusze mogliby wpłynąć na to, który łańcuch zostanie powszechnie zaakceptowany, wybierając uznanie tokenów tylko na jednym z łańcuchów.

6.3 Ataki regulacyjne lub presja

Rządy i organy regulacyjne mogłyby wywierać presję na różnych podmiotach kontrolujących kluczowe elementy stosu Ethereum, aby cenzurowały lub w inny sposób ingerowały w protokół Ethereum. Instytucjonalni użytkownicy Ethereum również mogliby zostać dotknięci takimi presjami, co miałoby dalsze konsekwencje dla ich klientów (np. bank, który nie mógłby już oferować określonych produktów kryptowalutowych ze względu na zakazy regulacyjne).

6.4 Organizacyjne przejęcie zarządzania

Otwarte procesy zarządzania i rozwoju Ethereum są napędzane przez zróżnicowaną i globalną grupę zespołów oraz firm, które zajmują się utrzymaniem podstawowego oprogramowania klienckiego, infrastruktury i narzędzi.

Różne formy wpływu (przejęcia przedsiębiorstw, zależności finansowe, zatrudnianie kluczowych współtwórców, konflikty interesów wewnątrz istniejących organizacji) mogłyby stopniowo zmieniać kulturę i priorytety zarządzania Ethereum. Mogłoby to prowadzić do dostosowania się z określonymi interesami komercyjnymi lub zewnętrznymi, które odbiegają od etosu tworzonego przez społeczność i ustalonego planu działania, potencjalnie osłabiając neutralność i odporność Ethereum w miarę upływu czasu.