Przegląd wyzwań bezpieczeństwa

Jedną z cech definiujących blockchainy jest atomowa natura transakcji: po zapisaniu aktualizacji w blockchainie nie ma możliwości interwencji ani jej cofnięcia. Zapewnia to silne gwarancje spójności i bezpieczeństwa na poziomie protokołu, ale naraża użytkowników na podwyższone ryzyko operacyjne: pojedynczy błąd, skompromitowany klucz lub pospieszne zatwierdzenie może prowadzić do nieodwracalnej straty.

W rezultacie znaczny ciężar bezpieczeństwa spoczywa na użytkowniku. Aby bezpiecznie korzystać z Ethereum, osoby prywatne i organizacje muszą bezpiecznie przechowywać klucze i zarządzać nimi, wchodzić w interakcje z aplikacjami onchain oraz używać swoich kluczy do podpisywania transakcji w celu transferu aktywów lub innej aktualizacji stanu Ethereum.

Każde z tych wymagań wprowadza ryzyko, takie jak kompromitacja lub utrata klucza, pospieszne lub nieświadome zatwierdzenia, czy też kompromitacja oprogramowania portfela, na którym polegają użytkownicy, aby informowało ich i prowadziło przez interakcje z Ethereum.

1.1 Zarządzanie kluczami

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

Większość powszechnie używanych portfeli programowych opiera się na bezpiecznym przechowywaniu przez użytkowników fraz seed reprezentujących ich podstawowy kryptograficzny klucz prywatny, co często prowadzi do stosowania niezabezpieczonych obejść, takich jak przechowywanie fraz seed w postaci zwykłego tekstu, w usługach chmurowych lub zapisywanie ich na papierze.

Alternatywą są portfele sprzętowe, które umożliwiają użytkownikom zarządzanie kluczem kryptograficznym przechowywanym w specjalnym urządzeniu fizycznym. Jednak portfele sprzętowe mają swoje własne wady i powierzchnię ataku. Portfele sprzętowe mogą zostać zgubione, uszkodzone lub skradzione. Wiele portfeli sprzętowych nie jest oprogramowaniem open source i może mieć nieprzejrzyste łańcuchy dostaw, co zwiększa ryzyko ataku na łańcuch dostaw, w którym skompromitowane urządzenia są sprzedawane na rynku.

Niezależnie od tego, czy klucze są zarządzane w portfelu programowym, czy sprzętowym, wielu użytkowników jest zrozumiale zdenerwowanych samodzielnym przechowywaniem, gdy może ono zostać naruszone w wyniku fizycznej kradzieży lub napaści.

Użytkownicy korporacyjni i instytucjonalni stają przed dodatkowymi wyzwaniami w zarządzaniu kluczami. Jeśli poszczególni pracownicy posiadają klucze (np. w ramach portfela multisig), organizacja musi być w stanie je wymienić i utworzyć nowe w związku ze zmianami personelu w czasie. Wymogi zgodności w różnych branżach i jurysdykcjach mogą wymagać niestandardowych przepływów pracy lub ścieżek audytu, które nie są obsługiwane przez istniejące oprogramowanie portfela. W niektórych przypadkach użytkownicy korporacyjni zwracają się do zewnętrznych powierników w celu przechowywania aktywów cyfrowych, co może wprowadzić kolejną warstwę ryzyka bezpieczeństwa do rozważenia.

1.2 Ślepe podpisywanie i niepewność transakcji

Użytkownicy rutynowo zatwierdzają transakcje „w ciemno”, nie rozumiejąc, co robią. Portfele często prezentują surowe dane szesnastkowe, skrócony adres kontraktu lub inne informacje, które nie są wystarczające, aby użytkownik zrozumiał konsekwencje danej transakcji. Pozostawia to wszelkiego rodzaju użytkowników podatnymi na złośliwe inteligentne kontrakty, phishing, oszustwa, sfałszowane interfejsy, kompromitacje frontendu i podstawowe błędy użytkownika.

1.3 Zarządzanie zatwierdzeniami i uprawnieniami

W wielu aplikacjach Ethereum powszechne jest, że użytkownicy przyznają określone uprawnienia podstawowej aplikacji w ramach normalnego użytkowania. Na przykład użytkownik może przyznać zdecentralizowanej giełdzie, takiej jak Uniswap, uprawnienie do przenoszenia swoich tokenów w celu ich wymiany na ETH.

Te zatwierdzenia mogą mieć limity kwotowe, ale wiele portfeli domyślnie przyznaje nieograniczone zatwierdzenia bez daty ważności. W większości portfeli użytkownicy nie mają możliwości zarządzania ani przeglądania swoich aktywnych zatwierdzeń.

Może to narazić użytkowników na złośliwe aplikacje lub skompromitowane frontendy, ponieważ domyślnym wzorcem dla wielu użytkowników jest przyznawanie nieograniczonych zatwierdzeń, które mogą zostać użyte do wyczyszczenia ich środków. Nawet jeśli użytkownik przyzna zatwierdzenie legalnemu inteligentnemu kontraktowi, a kontrakt ten zostanie później skompromitowany, podczas gdy zatwierdzenie pozostaje w mocy, skompromitowany kontrakt może opróżnić środki użytkownika.

Stanowi to równie duże ryzyko dla użytkowników organizacyjnych. Na przykład organizacja może zdecydować się na przyznanie routerowi DEX nieograniczonego limitu wydatków USDC dla wygody operacyjnej, co następnie naraża 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 inteligentnym kontraktem, ale raczej za pośrednictwem interfejsu internetowego na swoim urządzeniu mobilnym lub w przeglądarce internetowej.

Te frontendy mogą być podatne na ataki za pomocą znanych metod, takich jak przejęcie DNS, wstrzyknięcie złośliwego kodu JavaScript, niezabezpieczony hosting lub różne zależności od stron trzecich. Skompromitowany UX aplikacji może przekierować wszelkiego rodzaju użytkowników do złośliwych inteligentnych kontraktów lub doprowadzić ich do podpisania mylących transakcji.

1.5 Prywatność

Prywatność może łagodzić lub potęgować ryzyko bezpieczeństwa dla wszelkiego rodzaju użytkowników.

Słabsza ochrona prywatności naraża indywidualnych użytkowników na różnorodne ukierunkowane zagrożenia, takie jak phishing, wykorzystywanie, oszustwa lub ataki fizyczne. Wiele powszechnych wzorców UX naraża użytkowników, np. ponowne użycie adresu, dane KYC i inne wycieki metadanych.

Dla instytucji i przedsiębiorstw prywatność jest często podstawowym wymogiem biznesowym ze względów zgodności lub w określonych przypadkach użycia. Oprócz tych kwestii może to stwarzać narażenie na określone ryzyka bezpieczeństwa. Na przykład użytkownik systemu łańcucha dostaw zbudowanego na Ethereum może wymagać silnych gwarancji prywatności w celu ochrony aktywów własności intelektualnej, które mogłyby zostać naruszone, gdyby system był przejrzysty.

1.6 Fragmentacja

Brakuje spójności w sposobie, w jaki różne portfele obsługują podstawowe zachowania, takie jak wyświetlananie transakcji, obsługa zatwierdzeń lub oznaczanie kontraktów. Ta fragmentacja doświadczenia użytkownika utrudnia użytkownikowi naukę bezpiecznego korzystania z portfeli i zwiększa ryzyko.

Na przykład użytkownicy nie mogą polegać na spójnych wskazówkach UX, aby chronić się przed phishingiem i spoofingiem, ponieważ różnią się one w zależności od portfela. Użytkownicy nie mogą wyrobić sobie wiarygodnych oczekiwań co do tego, jak działa Ethereum, jeśli każde narzędzie funkcjonuje inaczej.

Bezpieczeństwo inteligentnych kontraktów radykalnie się poprawiło w historii Ethereum. Wczesne incydenty bezpieczeństwa, takie jak atak na The DAO, zmotywowały ekosystem do profesjonalizacji i ulepszenia zabezpieczeń w całym cyklu życia oprogramowania, co prowadzi do wdrażania kodu onchain. Kluczowe postępy obejmują:

• Audyty bezpieczeństwa stały się standardową praktyką, a kilka firm zajmujących się bezpieczeństwem weszło do ekosystemu i rozwinęło swoją wiedzę specjalistyczną.
• Narzędzia, testowanie i systemy analizy statycznej dojrzały i stały się standardową praktyką.
• Biblioteki wstępnie zbadanych wspólnych komponentów dały deweloperom domyślnie bezpieczne bloki konstrukcyjne.
• Przyjęto techniki weryfikacji formalnej, zwłaszcza w przypadku mostów, systemów stakingu i kontraktów o wysokiej wartości.
• Kultura bezpieczeństwa i najlepsze praktyki ekosystemu uległy poprawie.
• Stworzenie znaczących programów nagród (bounty), które wzmocniły warstwę aplikacji.

Jednak w tej dziedzinie nadal pozostają słabości i obszary do poprawy.

2.1 Podatności kontraktów

Pomimo postępów w bezpieczeństwie inteligentnych kontraktów, wciąż istnieją podatności, które mogą prowadzić do poważnych problemów z bezpieczeństwem, w tym:

• Ryzyko aktualizacji kontraktu. Niektóre kontrakty są zaprojektowane tak, aby można je było modyfikować po wdrożeniu, co umożliwia zespołowi deweloperskiemu ciągłe aktualizowanie i ulepszanie aplikacji. Wprowadza to jednak ryzyko. Aktualizacje mogą skutkować nowymi podatnościami lub całkowitą utratą środków użytkowników w przypadku złośliwej aktualizacji.
• Re-entrancy, gdzie kontrakt A wywołuje zewnętrzny kontrakt B przed aktualizacją własnego stanu wewnętrznego, a kontrakt B wywołuje z powrotem oryginalny kontrakt A przed zakończeniem pierwszego wywołania.
• Niebezpieczne korzystanie z zewnętrznych bibliotek, gdzie kontrakt wywołuje zewnętrzną bibliotekę, która może być nieprzebadana, złośliwa lub możliwa do aktualizacji.
• Nieprzebadane komponenty. Chociaż audytowanie i korzystanie ze standardowych bibliotek uległo poprawie, deweloperzy czasami polegają na nieprzebadanych komponentach w swoich aplikacjach.
• Błędy kontroli dostępu, gdzie uprawnienia są błędnie skonfigurowane lub zdefiniowane zbyt szeroko, co pozwala atakującym na podejmowanie złośliwych działań.
• Nieautoryzowany dostęp, gdzie klucz prywatny, który jest w stanie kontrolować kontrakt, zostaje pozyskany przez złośliwego aktora.
• 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ści w sposobie przekazywania lub walidacji komunikatów międzyłańcuchowych.
• Delegowanie konta zewnętrznego (EOA) lub nadużycie podpisu. Złośliwe aplikacje mogą nakłonić użytkowników do podpisania pełnego delegowania ich konta na inną stronę, umożliwiając kradzież. Złośliwe aplikacje mogą również wykorzystywać podpisane wiadomości od użytkownika w nieoczekiwany sposób, np. w ataku typu replay.
• Pojawiające się ryzyko błędów wprowadzanych przez generowanie kodu przez sztuczną inteligencję lub zautomatyzowane narzędzia do refaktoryzacji.

2.2 Doświadczenie dewelopera, narzędzia i języki programowania

Podatności trafiają do wdrożonego kodu w wyniku błędu dewelopera. Ulepszone narzędzia deweloperskie znacznie ułatwiły wdrażanie bezpiecznych inteligentnych kontraktów. Jednak problemy nadal występują.

• Brak bezpiecznych ustawień domyślnych w popularnych frameworkach. Niektóre narzędzia stawiają elastyczność lub szybkość ponad bezpieczeństwo, ustawiając niezabezpieczone wartości domyślne, takie jak nieograniczone zatwierdzenia tokenów w funkcji approve(), lub nie uwzględniając domyślnie wzorców kontroli dostępu.
• Niestandardowy kod dla zaawansowanych kontroli operacyjnych. Użytkownicy instytucjonalni o złożonych wymaganiach operacyjnych często muszą budować wymagane funkcje od podstaw, co zwiększa ryzyko podatności. Brakuje ustandaryzowanych, bezpiecznych komponentów lub frameworków dla zaawansowanych przepływów pracy związanych z bezpieczeństwem.
• Niespójne pokrycie testami w stosach narzędzi, a także brak norm dotyczących stosowania sprawdzonych technik, takich jak fuzzing lub sprawdzanie niezmienników.
• Niskie przyjęcie metod weryfikacji formalnej. Techniki weryfikacji formalnej są potężne, ale są złożone, kosztowne, wymagają specjalistycznej wiedzy dziedzinowej i nie są dobrze zintegrowane ze standardowymi przepływami pracy deweloperów, gdzie mogłyby być używane znacznie wcześniej w produkcji oprogramowania w celu weryfikacji bezpieczeństwa na etapie specyfikacji.
• Problemy związane z weryfikacją kontraktów. Użytkownicy i deweloperzy nie mogą łatwo ocenić wiarygodności wdrożonych kontraktów, zakresu ich walidacji bezpieczeństwa (np. audytów kodu) ani obecności ukrytych ryzyk. Chociaż istnieją rozwiązania w tym celu, wiele problemów pozostaje. Narzędzia, które rozwiązują te problemy, nie są powszechnie przyjęte, standardy, które ujednoliciłyby podejścia, pozostają pofragmentowane, a niektóre z istniejących usług same w sobie są scentralizowanymi zależnościami.
• Ryzyka związane z kompilatorami. Kompilatory (oprogramowanie, które konwertuje czytelny dla człowieka kod, taki jak Solidity, na kod bajtowy używany przez samą maszynę EVM) mogą posiadać luki, które wprowadzają błędy do inteligentnych kontraktów przed ich wdrożeniem. Ekosystem Ethereum opiera się dziś głównie na kompilatorze solc, co oznacza, że błąd mógłby mieć dalekosiężne skutki.
• Różnorodność i głębia języków programowania. Chociaż Solidity posiada rozbudowany ekosystem narzędzi, niektórzy programiści oczekują nowocześniejszych funkcji bezpieczeństwa, które można znaleźć w innych językach programowania, takich jak bezpieczeństwo pamięci.

2.3 Ocena ryzyka kodu onchain

Instytucje i przedsiębiorstwa posiadają istniejące procesy, standardy i wymagania dotyczące oceny bezpieczeństwa technologii i systemów, od których są zależne. Jednak istniejące ramy często nie przekładają się wprost na inteligentne kontrakty, zazwyczaj zakładając modyfikowalny kod, scentralizowaną kontrolę zmian oraz jasne linie odpowiedzialności lub odpowiedzialności prawnej. Systemy oparte na inteligentnych kontraktach mogą czasami łamać te założenia, utrudniając organizacjom adopcję Ethereum i odpowiednie zarządzanie ryzykiem.

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

3.1 Łańcuchy warstwy 2 (L2)

Łańcuchy warstwy 2 (L2) służą jako rozszerzenia dla Ethereum, umożliwiając szybsze środowiska z niższymi opłatami, przy jednoczesnym zachowaniu niektórych charakterystycznych gwarancji bezpieczeństwa sieci głównej Ethereum (w zależności od ich konkretnego projektu). Mają one jednak również własne, odrębne powierzchnie ataku, w tym:

• Złożoność aktywów przesyłanych przez wiele mostów. Kiedy aktywa przemieszczają się między warstwą 1 (L1) a wieloma sieciami L2, są narażone na działanie wielu zestawów kontraktów, z których wszystkie muszą być bezpieczne. Niezgodności w księgowaniu lub awarie w łańcuchach L2 mogą wprowadzać luki, które mogą zostać wykorzystane przez atakujących.
• Sieci L2 typu rollup opierają się na systemach dowodzenia w celu wymuszenia poprawności aktualizacji stanu. Błędy lub błędne konfiguracje w tych systemach mogą opóźnić lub uniemożliwić finalizację, albo pozwolić na finalizację fałszywych aktualizacji stanu, co prowadzi do utraty środków użytkowników.
• Rady bezpieczeństwa to grupy posiadaczy kluczy, które służą jako mechanizm „zapasowy” do aktualizacji oprogramowania L2 lub reagowania na określone sytuacje awaryjne. Same rady bezpieczeństwa stwarzają ryzyko, ponieważ kompromitacja lub zmowa między członkami może narazić środki użytkowników na niebezpieczeństwo lub zamrozić aktywa.

Zobacz L2BEAT (opens in a new tab), aby zapoznać się ze szczegółowymi ramami i panelem monitorowania, który ocenia i porównuje wydajność oraz bezpieczeństwo L2.

3.2 Infrastruktura RPC i węzłów

Aplikacje Ethereum zależą od niewielkiej liczby dostawców infrastruktury w zakresie dostępu do RPC, API i usług węzłów. Obejmuje to dostawców infrastruktury specyficznej dla krypto, a także tradycyjne usługi chmurowe, które są powszechnie używane do hostowania węzłów (np. AWS, Cloudflare, Hetzner).

Gdyby ci dostawcy infrastruktury przestali działać lub próbowali cenzurować albo ograniczać dostęp, wielu użytkowników mogłoby stracić dostęp do Ethereum za pośrednictwem swojego portfela lub aplikacji, dopóki nie byliby w stanie zmigrować do nowego dostawcy RPC lub innej infrastruktury. Niektórzy z tych dostawców w przeszłości zawieszali lub zamykali konta powiązane z aktywnością na blockchainie, co budzi obawy o ich długoterminową niezawodność dla zdecentralizowanych aplikacji.

3.3 Podatności na poziomie DNS

System nazw domen (DNS) jest podstawową warstwą internetu, ale jest również scentralizowany i może zostać skompromitowany. Wielu użytkowników uzyskuje dostęp do aplikacji za pośrednictwem domen internetowych, które są podatne na:

• Przechwytywanie DNS (DNS hijacking), gdzie atakujący wstawia złośliwy, fałszywy frontend.
• Przejęcie domeny, gdzie rząd lub rejestrator może zająć domeny.
• Phishing za pomocą łudząco podobnych domen, gdzie atakujący rejestrują niemal identyczne nazwy, aby zmylić użytkowników.

3.4 Łańcuch dostaw oprogramowania i biblioteki

Programiści Ethereum polegają na bibliotekach open-source, często pobieranych bezpośrednio z usług takich jak npm, crates.io lub GitHub. Jeśli te biblioteki zostaną skompromitowane, mogą stać się wektorem ataków, takich jak:

• Wstrzyknięcie złośliwego pakietu, gdzie atakujący kompromitują powszechnie używany pakiet lub publikują go pod podobną nazwą
• Przechwycone zależności, gdzie opiekunowie tracą kontrolę nad projektem, a złośliwy aktor wprowadza szkodliwy kod
• Kompromitacja programisty, gdzie zainstalowane pakiety zawierają kod, który daje atakującemu kontrolę nad komputerem programisty.

3.5 Usługi dostarczania frontendu i powiązane ryzyka

Wiele aplikacji Ethereum serwuje swoje frontendy za pośrednictwem sieci dostarczania treści (CDN) lub platformy hostingowej opartej na chmurze (np. Vercel, Netlify, Cloudflare). Jeśli te usługi zostaną skompromitowane, mogą stać się wektorem ataków, takich jak wstrzyknięcie złośliwego kodu JavaScript, gdzie atakujący serwują użytkownikom zmieniony frontend.

3.6 Cenzura na poziomie dostawcy usług internetowych

Dostawcy usług internetowych (ISP) lub państwa narodowe mogą wykorzystać kontrolę nad bazową infrastrukturą internetową do cenzurowania dostępu do Ethereum. Na przykład ataki te mogą obejmować:

• Blokowanie lub ograniczanie ruchu do popularnych portów Ethereum
• Filtrowanie zapytań DNS, które rozwiązują się do usług powiązanych z Ethereum
• Geofencing lub blokady IP wymierzone w znane węzły Ethereum
• Głęboką inspekcję pakietów (DPI) w celu identyfikacji i cenzurowania ruchu związanego z protokołem Ethereum

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

Protokół konsensusu Ethereum sprawdził się w praktyce, działając bez żadnych przerw od momentu pierwszego uruchomienia w 2015 roku i podczas kilku aktualizacji. Pozostają jednak długoterminowe obszary do poprawy, aby uczynić system bardziej odpornym i bezpiecznym.

4.1 Kruchość konsensusu i ryzyka związane z odzyskiwaniem

Zasady wyboru rozwidlenia i ostateczności w Ethereum są odporne, ale nie są niezniszczalne. W pewnych skrajnych warunkach (takich jak przedłużający się brak zgody walidatorów, błędy klientów lub podziały sieci) konsensus może utknąć w martwym punkcie lub tymczasowo się rozbiec. W ekstremalnych warunkach mogłoby to prowadzić do kaskadowych kar dla walidatorów poprzez wycieki z powodu nieaktywności (inactivity leaks) lub cięcie, co z kolei mogłoby doprowadzić do ucieczki kapitału od walidatorów.

4.2 Różnorodność klientów

Wiodąca w branży różnorodność klientów Ethereum chroni sieć przed błędami w jakimkolwiek pojedynczym kliencie. Jednak różnorodność klientów wciąż można by poprawić poprzez większą adopcję klientów mniejszościowych, aby jeszcze bardziej zminimalizować te ryzyka.

4.3 Centralizacja stakingu i dominacja pul

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

• Przejęcie zarządzania lub wpływ na nie. Gdyby podmioty kontrolujące duże ilości stawki (lub podmioty posiadające prawną możliwość wpływania na te podmioty) skoordynowały swoje działania, mogłyby mieć nieproporcjonalnie duży 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 klienta i konfiguracji infrastruktury, co może zwiększyć ryzyko skorelowanych awarii.

4.4 Niezdefiniowane karanie społecznościowe i luki w koordynacji

W niektórych ekstremalnych przypadkach awarii, Ethereum polegałoby na „karaniu społecznościowym”, 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 cięcia są słabo rozwinięte. Nie ma ustalonego mechanizmu, którego społeczność mogłaby użyć, aby zaangażować się w ten proces.

4.5 Wektory ataków ekonomicznych i opartych na teorii gier

Wiele potencjalnych wektorów ataków ekonomicznych pozostaje niedostatecznie zbadanych, w tym:

• Ataki typu griefing lub slash griefing. Walidatory mogą ponosić koszty lub kary cięcia nie z własnej winy, ale z powodu wrogiego zachowania, którego jedynym celem jest zaszkodzenie innym, nawet jeśli wiąże się to z kosztami netto dla atakującego.
• Strategiczne wyjścia lub zaplanowana nieaktywność. Walidatory mogłyby celowo odłączać się od sieci lub wychodzić w krytycznych momentach, aby zmaksymalizować zyski lub zakłócić konsensus przy minimalnych karach.
• Zmowa między walidatorami lub przekaźnikami. Skoordynowane zachowanie między walidatorami lub między przekaźnikami a walidatorami mogłoby zmniejszyć decentralizację lub wyodrębnić MEV.
• Wykorzystywanie skrajnych przypadków zachęt w MEV, separacji proponującego i budującego (PBS) lub projektach płynnego stakingu. Aktorzy mogą manipulować rzadkimi warunkami protokołu, aby uzyskać nieproporcjonalnie duże nagrody.

4.6 Ryzyko kwantowe

Podstawowa kryptografia Ethereum (np. podpisy oparte na krzywej eliptycznej, takie jak secp256k1) może pewnego dnia zostać złamana przez komputery kwantowe. Chociaż nie jest to bezpośrednie ryzyko, wiarygodne zagrożenie mogłoby natychmiast narazić na niebezpieczeństwo istniejące portfele, kontrakty i klucze do stakingu. To przyszłe wyzwanie osłabia długoterminowe gwarancje Ethereum dla użytkowników.

Ścieżki migracji do kryptografii odpornej na ataki kwantowe (np. poprzez schematy podpisów postkwantowych) muszą zostać zaprojektowane, przetestowane i prawdopodobnie osadzone w protokole na wiele lat przed tym, zanim będą potrzebne. Organizacje w całym ekosystemie Ethereum, w tym Fundacja Ethereum, aktywnie badają te opcje i monitorują ryzyka.

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

• Dotarcie do poszkodowanego zespołu. Nawiązanie kontaktu z zespołem, którego aplikacja została skompromitowana, może być trudne. Może to prowadzić do wielogodzinnych opóźnień, ograniczając zdolność osób reagujących do odzyskania środków.
• Eskalacja problemów w powiązanych organizacjach. Gdy problem dotyczy platformy (takiej jak sieć społecznościowa lub scentralizowana giełda), eskalacja problemu przez osoby reagujące może być trudna, jeśli nie mają one wcześniejszego kontaktu.
• Koordynacja reakcji. Często nie jest jasne, ile zespołów reagowania na incydenty pomaga poszkodowanej aplikacji, co prowadzi do nieporozumień lub marnowania wysiłku, podczas gdy wspólne działanie mogłoby być bardziej skuteczne.
• Brak możliwości monitorowania. Monitorowanie problemów onchain i pozałańcuchowych może być trudne, a zapewniłoby to wczesne ostrzeganie i gwarantowało szybką reakcję na zagrożenia.
• Dostęp do ubezpieczeń. Ubezpieczenie jest niezbędnym narzędziem do łagodzenia strat w większości tradycyjnych systemów, które mają do czynienia z pieniędzmi, systemami finansowymi, tożsamością i innymi cennymi informacjami. Jednak obecnie tradycyjne usługi finansowe oferują niewiele opcji ubezpieczeniowych dla ekosystemu krypto.

Ryzyka te mają zazwyczaj charakter bardziej długoterminowy i dotyczą Ethereum jako całości, a nie bezpieczeństwa poszczególnych użytkowników czy aplikacji.

6.1 Centralizacja stawki

Centralizacja dużych ilości stawki może stwarzać ryzyko dla Ethereum jako całości, jeśli podmioty kontrolujące tę stawkę zdecydują się na zmowę.
Ta ekonomiczna centralizacja stwarza potencjał do przejęcia zarządzania społecznego. Jeśli mała grupa walidatorów kontroluje większość kwalifikowaną stawki, mogliby oni:

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

Gdyby doszło do tego ekstremalnego scenariusza, społeczność Ethereum zasugerowała, że odpowiedzią mogłoby być „karanie społecznościowe”. Karanie społecznościowe to wykorzystanie pozałańcuchowego konsensusu społecznego do podjęcia decyzji o ukaraniu cięciem źle zachowujących się walidatorów, jako sposób na kontrolowanie ich władzy. Nie istnieją jednak żadne jasne normy, procedury ani narzędzia do wprowadzania takich środków (patrz sekcja 4.4).

6.2 Centralizacja aktywów pozałańcuchowych

Ethereum przechowuje znaczne ilości aktywów świata rzeczywistego (RWA), gdzie aktywa te są trzymane pozałańcuchowo na kontach bankowych lub innych depozytach, a następnie są przedmiotem obrotu onchain za pośrednictwem tokenów, które reprezentują roszczenie do aktywów pozałańcuchowych. Na przykład wiele dużych stablecoinów funkcjonuje w ten sposób.

Instytucje przechowujące depozyty pozałańcuchowe mogą mieć wpływ na ekosystem Ethereum. Na przykład podczas ekstremalnego scenariusza, w którym dochodzi do spornego rozwidlenia lub aktualizacji sieci, duzi deponenci mogą wpłynąć na to, który łańcuch zostanie powszechnie zaakceptowany, decydując się na uznawanie tokenów tylko na jednym lub drugim łańcuchu.

6.3 Atak lub presja regulacyjna

Rządy i organy regulacyjne mogłyby wywierać presję na różne podmioty kontrolujące ważne komponenty stosu technologicznego Ethereum, aby cenzurowały lub w inny sposób ingerowały w protokół Ethereum. Presja ta mogłaby również wpłynąć na instytucjonalnych użytkowników Ethereum, co miałoby dalsze konsekwencje dla ich użytkowników (np. bank, który nie może już oferować pewnych produktów krypto z powodu zakazów regulacyjnych).

6.4 Organizacyjne przejęcie zarządzania

Procesy zarządzania i rozwoju open source w Ethereum są napędzane przez zróżnicowany i globalny zestaw zespołów oraz firm, które utrzymują podstawowe oprogramowanie klientów, infrastrukturę i narzędzia.

Różne formy wpływu (przejęcia korporacyjne, zależności w finansowaniu, zatrudnianie kluczowych współtwórców, konflikty interesów wewnątrz istniejących organizacji) mogłyby stopniowo zmieniać kulturę i priorytety zarządzania Ethereum. Może to prowadzić do dostosowania się do konkretnych interesów komercyjnych lub zewnętrznych, które odbiegają od etosu napędzanego przez społeczność i ustalonej mapy drogowej, potencjalnie osłabiając z czasem neutralność i odporność Ethereum.