Přehled bezpečnostních výzev

Jedním z určujících rysů blockchainů je atomická povaha transakcí: jakmile je aktualizace zaznamenána do blockchainu, neexistuje žádná možnost zásahu nebo zvrácení. To poskytuje silné záruky konzistence a bezpečnosti na úrovni protokolu, ale vystavuje uživatele zvýšenému operačnímu riziku: jediná chyba, kompromitovaný klíč nebo unáhlené schválení může vést k nevratné ztrátě.

V důsledku toho padá značné břemeno bezpečnosti na uživatele. Aby mohli Ethereum používat bezpečně, musí jednotlivci a organizace bezpečně držet a spravovat klíče, interagovat s onchain aplikacemi a používat své klíče k podepisování transakcí za účelem převodu aktiv nebo jiné aktualizace stavu Etherea.

Každý z těchto požadavků přináší rizika, jako je kompromitace nebo ztráta klíče, unáhlená nebo neinformovaná schválení, případně kompromitace softwaru peněženky, na který uživatelé spoléhají, že je bude informovat a provázet interakcí s Ethereem.

1.1 Správa klíčů

Mnoho uživatelů není vybaveno k tomu, aby bezpečně spravovali kryptografické klíče.

Většina široce používaných softwarových peněženek spoléhá na to, že uživatelé bezpečně uchovávají seed fráze představující jejich základní kryptografický soukromý klíč, což je často vede k používání nezabezpečených řešení, jako je ukládání seed frází v prostém textu, na cloudových službách nebo jejich zapisování na papír.

Alternativou jsou hardwarové peněženky, které uživatelům umožňují spravovat kryptografický klíč uložený ve speciálním fyzickém zařízení. Hardwarové peněženky však mají své vlastní nedostatky a prostor pro útoky. Hardwarové peněženky mohou být ztraceny, poškozeny nebo ukradeny. Mnoho hardwarových peněženek není open source a může mít neprůhledné dodavatelské řetězce, což zvyšuje riziko útoku na dodavatelský řetězec, kdy jsou na trh prodávána kompromitovaná zařízení.

Ať už jsou klíče spravovány v softwarové nebo hardwarové peněžence, mnoho uživatelů je pochopitelně nervózních z vlastní úschovy, když může být kompromitována fyzickou krádeží nebo napadením.

Podnikoví a institucionální uživatelé čelí při správě klíčů dalším výzvám. Pokud jednotliví zaměstnanci drží klíče (např. jako součást multisig peněženky), organizace musí být schopna je nahradit a vytvořit nové kvůli personálním změnám v průběhu času. Požadavky na dodržování předpisů v různých odvětvích a jurisdikcích mohou vyžadovat vlastní pracovní postupy nebo auditní záznamy, které stávající software peněženky nepodporuje. V některých případech se podnikoví uživatelé obracejí na správce digitálních aktiv třetích stran, což může přinést další vrstvu bezpečnostních rizik, která je třeba zvážit.

1.2 Slepé podepisování a nejistota transakcí

Uživatelé běžně schvalují transakce „naslepo“, aniž by chápali, co dělají. Peněženky často zobrazují surová hexadecimální data, zkrácenou adresu kontraktu nebo jiné informace, které uživateli nestačí k pochopení důsledků dané transakce. To ponechává uživatele všeho druhu zranitelné vůči škodlivým chytrým kontraktům, phishingu, podvodům, zfalšovaným rozhraním, kompromitacím frontendu a základním uživatelským chybám.

1.3 Správa schválení a oprávnění

V mnoha aplikacích na Ethereu je běžné, že uživatelé v rámci běžného používání udělují základní aplikaci určitá oprávnění. Uživatel může například udělit decentralizované burze, jako je Uniswap, oprávnění přesouvat jeho tokeny, aby je mohl swapovat za ETH.

Tato schválení mohou mít limity na částku, ale mnoho peněženek ve výchozím nastavení uděluje neomezená schválení bez data vypršení platnosti. Ve většině peněženek neexistuje způsob, jak by uživatelé mohli spravovat nebo kontrolovat svá nevyřízená schválení.

To může uživatele vystavit škodlivým aplikacím nebo kompromitovaným frontendům, protože výchozím vzorcem mnoha uživatelů je udělovat neomezená schválení, která mohou být použita k odčerpání jejich prostředků. I když uživatel udělí schválení legitimnímu chytrému kontraktu, pokud by byl tento kontrakt později kompromitován, zatímco schválení zůstává v platnosti, mohl by kompromitovaný kontrakt odčerpat uživatelovy prostředky.

To je stejné riziko i pro organizační uživatele. Organizace se může například rozhodnout udělit routeru DEX neomezený povolený limit USDC pro provozní pohodlí, což ji pak vystavuje rizikům, pokud je kontrakt routeru aktualizován.

1.4 Kompromitovaná webová rozhraní

Většina uživatelů neinteraguje s chytrým kontraktem přímo, ale spíše prostřednictvím webového rozhraní přes své mobilní zařízení nebo webový prohlížeč.

Tyto frontendy mohou být zranitelné vůči útokům prostřednictvím známých prostředků, jako je únos DNS, vložení škodlivého JavaScriptu, nezabezpečený hosting nebo různé závislosti na třetích stranách. Kompromitované UX aplikace může přesměrovat uživatele všeho druhu na škodlivé chytré kontrakty nebo je přimět k podepsání zavádějících transakcí.

1.5 Soukromí

Soukromí může zmírnit nebo zvětšit bezpečnostní rizika pro uživatele všeho druhu.

Slabší ochrana soukromí vystavuje jednotlivé uživatele řadě cílených hrozeb, jako je phishing, zneužití, podvody nebo fyzické útoky. Mnoho běžných UX vzorců uživatele odhaluje, např. opětovné použití adresy, data KYC a další úniky metadat.

Pro instituce a podniky je soukromí často základním obchodním požadavkem z důvodu dodržování předpisů nebo určitých případů použití. Kromě těchto problémů může vytvářet vystavení specifickým bezpečnostním rizikům. Například uživatel systému dodavatelského řetězce postaveného na Ethereu může vyžadovat silné záruky soukromí k ochraně aktiv duševního vlastnictví, která by mohla být kompromitována, pokud by byl systém transparentní.

1.6 Fragmentace

Chybí konzistence v tom, jak různé peněženky řeší základní chování, jako je zobrazování transakcí, zpracování schválení nebo označování kontraktů. Tato fragmentace uživatelské zkušenosti ztěžuje uživatelům naučit se bezpečně používat peněženky a zvyšuje rizika.

Uživatelé se například nemohou spoléhat na konzistentní UX signály, které by je chránily před phishingem a spoofingem, protože se v různých peněženkách liší. Uživatelé si nemohou vytvořit spolehlivá očekávání o tom, jak Ethereum funguje, pokud každý nástroj funguje jinak.

Bezpečnost chytrých kontraktů se v průběhu historie Etherea radikálně zlepšila. Rané bezpečnostní incidenty, jako byl hack DAO, motivovaly ekosystém k profesionalizaci a zlepšení ochranných opatření napříč životním cyklem softwaru, který vede k nasazení kódu onchain. Mezi klíčová vylepšení patří:

• Bezpečnostní audity se staly standardní praxí, přičemž do ekosystému vstoupilo několik bezpečnostních firem a rozvinulo své odborné znalosti.
• Nástroje, testování a systémy statické analýzy dospěly a staly se standardní praxí.
• Knihovny předem auditovaných běžných komponent poskytly vývojářům stavební bloky, které jsou ve výchozím nastavení bezpečné.
• Byly přijaty techniky formální verifikace, zejména pro mosty, stakingové systémy a kontrakty s vysokou hodnotou.
• Zlepšila se bezpečnostní kultura ekosystému a osvědčené postupy.
• Vytvoření významných bounty programů, které posílily aplikační vrstvu.

V této oblasti však stále přetrvávají slabiny a prostor pro zlepšení.

2.1 Zranitelnosti kontraktů

Navzdory pokroku v bezpečnosti chytrých kontraktů stále existují zranitelnosti, které mohou vést k významným bezpečnostním problémům, včetně:

• Riziko aktualizace kontraktu. Některé kontrakty jsou navrženy tak, aby je bylo možné po nasazení upravovat, což vývojovému týmu umožňuje aplikaci nadále aktualizovat a vylepšovat. To však přináší rizika. Aktualizace by mohly vést k novým zranitelnostem nebo k úplné ztrátě uživatelských prostředků v případě škodlivé aktualizace.
• Re-entrancy, kdy kontrakt A zavolá externí kontrakt B před aktualizací svého vlastního vnitřního stavu a kontrakt B zavolá zpět původní kontrakt A před dokončením prvního volání.
• Nebezpečné použití externích knihoven, kdy kontrakt volá externí knihovnu, která může být neauditovaná, škodlivá nebo aktualizovatelná.
• Neauditované komponenty. Ačkoli se auditování a používání standardních knihoven zlepšilo, vývojáři se někdy ve svých aplikacích spoléhají na neauditované komponenty.
• Selhání řízení přístupu, kdy jsou oprávnění špatně nakonfigurována nebo definována příliš široce, což útočníkům umožňuje provádět škodlivé akce.
• Neoprávněný přístup, kdy soukromý klíč, který je schopen ovládat kontrakt, získá škodlivý aktér.
• Mosty a cross-chain interakce. Mosty a cross-chain protokoly přinášejí další složitost a útočníci mohou zneužít slabiny ve způsobu předávání nebo ověřování cross-chain zpráv.
• Zneužití delegace nebo podpisu externě vlastněného účtu (EOA). Škodlivé aplikace mohou uživatele přimět k podepsání plné delegace jejich účtu na jinou stranu, což umožní krádež. Škodlivé aplikace mohou také využít podepsané zprávy od uživatele neočekávaným způsobem, např. při replay útoku.
• Vznikající riziko chyb způsobených generováním kódu pomocí umělé inteligence nebo nástroji pro automatizovaný refaktoring.

2.2 Vývojářská zkušenost, nástroje a programovací jazyky

Zranitelnosti končí v nasazeném kódu v důsledku chyby vývojáře. Vylepšené vývojářské nástroje výrazně usnadnily nasazení bezpečných chytrých kontraktů. Problémy však přetrvávají.

• Nedostatek bezpečných výchozích nastavení v populárních frameworcích. Některé nástroje upřednostňují flexibilitu nebo rychlost před bezpečností a nastavují nezabezpečená výchozí nastavení, jako jsou neomezená schválení tokenů ve funkci approve(), nebo ve výchozím nastavení nezahrnují vzorce řízení přístupu.
• Vlastní kód pro pokročilé provozní kontroly. Institucionální uživatelé se složitými provozními požadavky často musí budovat požadované funkce od nuly, což zvyšuje riziko zranitelností. Chybí standardizované bezpečné komponenty nebo frameworky pro pokročilé bezpečnostní pracovní postupy.
• Nekonzistentní pokrytí testováním napříč sadami nástrojů, stejně jako nedostatek norem týkajících se používání osvědčených technik, jako je fuzzing nebo kontrola invariantů.
• Nízká míra přijetí metod formální verifikace. Techniky formální verifikace jsou mocné, ale jsou složité, nákladné, vyžadují specializované odborné znalosti v dané oblasti a nejsou dobře integrovány do standardních pracovních postupů vývojářů, kde by mohly být použity mnohem dříve při tvorbě softwaru k ověření bezpečnosti ve fázi specifikace.
• Problémy spojené s verifikací kontraktů. Uživatelé a vývojáři nemohou snadno posoudit důvěryhodnost nasazených kontraktů, rozsah jejich bezpečnostního ověření (např. audity kódu) nebo přítomnost skrytých rizik. Ačkoli pro tento účel existují řešení, mnoho problémů přetrvává. Nástroje, které tyto problémy řeší, nejsou široce přijímány, standardy, které by přístupy sjednotily, zůstávají fragmentované a některé ze stávajících služeb jsou samy o sobě centralizovanými závislostmi.
• Rizika kompilátoru. Kompilátory (software, který převádí lidsky čitelný kód, jako je Solidity, na bajtkód používaný samotným EVM) mohou mít nedostatky, které zanesou chyby do chytrých kontraktů ještě před jejich nasazením. Ekosystém Etherea dnes většinou závisí na kompilátoru solc, což znamená, že chyba by mohla mít rozsáhlé následky.
• Diverzita a hloubka programovacích jazyků. Ačkoli má Solidity vybudovaný hluboký ekosystém nástrojů, někteří vývojáři požadují modernější bezpečnostní funkce, které se nacházejí v jiných programovacích jazycích, jako je například bezpečnost paměti.

2.3 Hodnocení rizik onchain kódu

Instituce a podniky mají zavedené procesy, standardy a požadavky na hodnocení bezpečnosti technologií a systémů, na kterých závisí. Stávající rámce však často nelze jednoduše aplikovat na chytré kontrakty, protože obvykle předpokládají měnitelný kód, centralizovanou kontrolu změn a jasné linie odpovědnosti nebo právní ručení. Systémy postavené na chytrých kontraktech mohou někdy tyto předpoklady narušovat, což organizacím ztěžuje přijetí Etherea a odpovídající řízení rizik.

Tyto systémy představují prostor pro útoky jak na vrstvu peněženek a aplikací (např. koncové body RPC pro peněženky), tak na samotný protokol Etherea (např. mnoho validátorů je hostováno na cloudové infrastruktuře). Kompromitace soukromého klíče, phishing a nedostatek granulárního řízení přístupu mohou vést k rozsáhlým výpadkům, krádežím nebo neoprávněným změnám, i když samotný podkladový blockchainový protokol zůstává bezpečný.

3.1 Řetězce vrstvy 2 (l2)

Řetězce vrstvy 2 (l2) slouží jako rozšíření Etherea, která umožňují rychlejší prostředí s nižšími poplatky, přičemž si zachovávají některé charakteristické bezpečnostní záruky sítě Ethereum Mainnet (v závislosti na jejich konkrétním návrhu). Mají však také své vlastní specifické prostory pro útoky, mezi které patří:

• Složitost aktiv přemosťovaných přes více uzlů (multi-hop). Když se aktiva přesouvají mezi vrstvou 1 (l1) a několika l2, jsou vystavena více sadám kontraktů, z nichž všechny musí být bezpečné. Nesoulad v účtování nebo výpadky v řetězcích l2 mohou vnést zranitelnosti, které mohou útočníci zneužít.
• Rollup l2 spoléhají na dokazovací systémy k vynucení správnosti aktualizací stavu. Chyby nebo špatná konfigurace v těchto systémech mohou zdržet nebo znemožnit finalizaci, případně umožnit finalizaci falešných aktualizací stavu, což vede ke ztrátě prostředků uživatelů.
• Bezpečnostní rady jsou skupiny držitelů klíčů, které slouží jako „záložní“ mechanismus pro aktualizaci softwaru l2 nebo reakci na určité mimořádné události. Samotné bezpečnostní rady představují riziko, protože kompromitace nebo tajná dohoda mezi členy by mohla ohrozit prostředky uživatelů nebo zmrazit aktiva.

Podívejte se na L2BEAT (opens in a new tab), kde najdete podrobný rámec a monitorovací panel, který hodnotí a porovnává výkon a bezpečnost l2.

3.2 Infrastruktura RPC a uzlů

Aplikace na Ethereu závisí na malém počtu poskytovatelů infrastruktury pro přístup k RPC, API a službám uzlů. To zahrnuje poskytovatele infrastruktury specifické pro krypto, stejně jako tradiční cloudové služby, které se běžně používají k hostování uzlů (např. AWS, Cloudflare, Hetzner).

Pokud by tito poskytovatelé infrastruktury přešli do režimu offline nebo se pokusili cenzurovat či omezit přístup, mnoha uživatelům by mohlo být znemožněno přistupovat k Ethereu prostřednictvím jejich peněženky nebo aplikace, dokud by nebyli schopni přejít na nové RPC nebo jiného poskytovatele infrastruktury. Někteří z těchto poskytovatelů již dříve pozastavili nebo zrušili účty spojené s aktivitou na blockchainu, což vyvolává obavy ohledně jejich dlouhodobé spolehlivosti pro decentralizované aplikace.

3.3 Zranitelnosti na úrovni DNS

Systém doménových jmen (DNS) je základní vrstvou internetu, ale je také centralizovaný a může být kompromitován. Mnoho uživatelů přistupuje k aplikacím prostřednictvím webových domén, které jsou náchylné k:

• Únosům DNS (DNS hijacking), kdy útočník vloží škodlivý falešný frontend.
• Zabavení domény, kdy vláda nebo registrátor může domény zabavit.
• Phishingu prostřednictvím podobně vypadajících domén, kdy útočníci registrují téměř identická jména, aby zmátli uživatele.

3.4 Dodavatelský řetězec softwaru a knihovny

Vývojáři na Ethereu spoléhají na open-source knihovny, které se často stahují přímo ze služeb jako npm, crates.io nebo GitHub. Pokud jsou tyto knihovny kompromitovány, mohou se stát vektorem pro útoky, jako jsou:

• Vložení škodlivého balíčku, kdy útočníci kompromitují široce používaný balíček nebo publikují jiný pod podobným názvem
• Unesené závislosti, kdy správci ztratí kontrolu nad projektem a škodlivý aktér zavede škodlivý kód
• Kompromitace vývojáře, kdy nainstalované balíčky obsahují kód, který útočníkovi poskytne kontrolu nad počítačem vývojáře.

3.5 Služby pro doručování frontendu a související rizika

Mnoho aplikací na Ethereu poskytuje své frontendy prostřednictvím sítě pro doručování obsahu (CDN) nebo cloudové hostingové platformy (např. Vercel, Netlify, Cloudflare). Pokud jsou tyto služby kompromitovány, mohou se stát vektorem pro útoky, jako je vložení škodlivého JavaScriptu, kdy útočníci uživatelům naservírují pozměněný frontend.

3.6 Cenzura na úrovni poskytovatelů internetových služeb

Poskytovatelé internetových služeb (ISP) nebo národní státy mohou využít kontrolu nad podkladovou internetovou infrastrukturou k cenzuře přístupu k Ethereu. Tyto útoky by mohly zahrnovat například:

• Blokování nebo omezování provozu na běžných portech Etherea
• Filtrování požadavků DNS, které se překládají na služby související s Ethereem
• Geofencing nebo zákazy IP adres proti známým uzlům Etherea
• Hloubkovou inspekci paketů (Deep packet inspection) k identifikaci a cenzuře provozu souvisejícího s protokolem Etherea

Mnoho z těchto základních technik již dnes používají autoritářské vlády po celém světě k potlačení přístupu k informacím, protestním nástrojům nebo kryptoměnám.

Protokol konsensu Etherea se v praxi ukázal jako robustní, s nulovými výpadky od svého prvního spuštění v roce 2015 a napříč několika upgrady. Stále však existují dlouhodobé oblasti pro zlepšení, aby byl systém odolnější a bezpečnější.

4.1 Křehkost konsensu a rizika obnovy

Pravidla Etherea pro volbu forku a finalitu jsou odolná, ale nejsou nezranitelná. Během určitých okrajových podmínek (jako je dlouhodobá neshoda validátorů, chyby klientů nebo rozdělení sítě) by se mohl konsensus zastavit nebo dočasně odchýlit. V extrémních podmínkách by to mohlo vést ke kaskádovým trestům pro validátory prostřednictvím úniků z nečinnosti (inactivity leaks) nebo penalizace, což by mohlo dále vést k odlivu kapitálu od validátorů.

4.2 Klientská diverzita

Špičková klientská diverzita Etherea chrání síť před chybami v jakémkoli jednotlivém klientovi. Klientskou diverzitu by však bylo možné ještě zlepšit větším přijetím menšinových klientů, aby se tato rizika ještě více snížila.

4.3 Centralizace stakingu a dominance poolů

Značná část váhy validátorů je soustředěna v protokolech pro likvidní staking, depozitních službách a u velkých provozovatelů uzlů. Tato koncentrace může vést k rizikům, jako jsou:

• Ovládnutí nebo ovlivnění správy. Pokud by subjekty kontrolující velké množství staku (nebo subjekty s právní mocí tyto subjekty ovlivňovat) vzájemně koordinovaly své kroky, mohly by mít nadměrný vliv na to, které bloky jsou navrhovány a potvrzovány, což by mohlo vést k cenzuře uživatelů nebo ovlivňování upgradů protokolu.
• Homogenita ve výběru klientů a nastavení infrastruktury, což může zvýšit rizika korelovaných selhání.

4.4 Nedefinované sociální osekání a mezery v koordinaci

V některých extrémních případech selhání by Ethereum spoléhalo na „sociální osekání“ k potrestání validátorů, kteří jednali zlomyslně s cílem zaútočit na síť (viz část 6.1). Infrastruktura, normy a očekávané procesy pro tento druh osekání jsou však nedostatečně rozvinuté. Neexistuje žádný zavedený mechanismus, který by komunita k zapojení do tohoto procesu použila.

4.5 Ekonomické a herně-teoretické vektory útoků

Mnoho potenciálních ekonomických vektorů útoků zůstává nedostatečně prozkoumáno, včetně:

• Griefing útoky nebo slash griefing. Validátorům mohou vzniknout náklady nebo penalizace nikoli jejich vlastní vinou, ale kvůli nepřátelskému chování, jehož jediným cílem je poškodit ostatní, a to i za cenu čisté ztráty pro útočníka.
• Strategické výstupy nebo načasovaná nečinnost. Validátoři by se mohli úmyslně odpojit nebo provést výstup v kritických okamžicích, aby maximalizovali zisky nebo narušili konsensus s minimálními tresty.
• Tajná dohoda mezi validátory nebo relé (relays). Koordinované chování mezi validátory nebo mezi relé a validátory by mohlo snížit decentralizaci nebo extrahovat MEV.
• Zneužití okrajových pobídek v MEV, oddělení navrhovatele a tvůrce (PBS) nebo v návrhu likvidního stakingu. Aktéři mohou manipulovat se vzácnými podmínkami protokolu, aby získali nadměrné odměny.

4.6 Kvantové riziko

Základní kryptografie Etherea (např. podpisy na bázi eliptické křivky jako secp256k1) by mohla být jednoho dne prolomena kvantovými počítači. Ačkoli se nejedná o bezprostřední riziko, věrohodná hrozba by mohla okamžitě učinit stávající peněženky, kontrakty a stakingové klíče zranitelnými. Tato budoucí výzva oslabuje dlouhodobé záruky Etherea vůči uživatelům.

Cesty migrace na kvantově odolnou kryptografii (např. prostřednictvím postkvantových schémat podpisů) musí být navrženy, otestovány a případně začleněny do protokolu roky předtím, než budou potřeba. Organizace napříč ekosystémem Etherea, včetně Nadace Ethereum, tyto možnosti aktivně zkoumají a monitorují rizika.

Dokonce i idealizovaný blockchainový ekosystém bude mít svá rizika, útoky a zranitelnosti. Když se věci pokazí, musí existovat efektivní systémy pro zmírnění, detekci a reakci. Mezi výzvy v této oblasti patří:

• Kontaktování zasaženého týmu. Může být obtížné navázat kontakt s týmem, jehož aplikace byla kompromitována. To může vést k hodinovým zpožděním, což omezuje schopnost zasahujících osob získat zpět prostředky.
• Eskalace problémů u spřízněných organizací. Pokud se problém týká platformy (jako je sociální síť nebo centralizovaná burza), může být pro zasahující osoby náročné problém eskalovat, pokud nemají předem navázaný kontakt.
• Koordinace reakce. Často není jasné, kolik týmů pro reakci na incidenty pomáhá zasažené aplikaci, což vede k nedorozuměním nebo zbytečnému úsilí, přičemž skupinové úsilí by mohlo být efektivnější.
• Nedostatek monitorovacích schopností. Může být obtížné monitorovat onchain a offchain problémy, což by poskytlo včasné varování a zajistilo rychlou reakci na hrozby.
• Přístup k pojištění. Pojištění je nezbytným nástrojem pro zmírnění ztrát ve většině tradičních systémů, které se zabývají penězi, finančními systémy, identitou a dalšími cennými informacemi. Dnes je však pro krypto ekosystém k dispozici jen málo možností pojištění od tradičních finančních služeb.

Tato rizika bývají spíše dlouhodobějšího charakteru a týkají se Etherea jako celku, nikoli bezpečnosti jednotlivých uživatelů nebo aplikací.

6.1 Centralizace staku

Centralizace velkého množství staku může představovat riziko pro Ethereum jako celek, pokud se subjekty kontrolující tento stake rozhodnou tajně dohodnout.
Tato ekonomická centralizace vytváří potenciál pro ovládnutí sociální správy. Pokud malá skupina validátorů kontroluje supervětšinu staku, mohla by:

• Koordinovat forky nebo se jim bránit.
• Cenzurovat určité transakce nebo kontrakty.
• Narušit konsensus komunity hrozbou výstupu nebo opozicí.

Pokud by k tomuto extrémnímu scénáři došlo, komunita Etherea navrhla, že řešením by mohlo být „sociální osekání“. Sociální osekání je využití offchain sociálního konsensu k rozhodnutí penalizovat špatně se chovající validátory, jakožto kontrola jejich moci. Neexistují však žádné jasné normy, postupy ani nástroje k uzákonění takových opatření (viz část 4.4).

6.2 Centralizace offchain aktiv

Ethereum hostí značné množství aktiv reálného světa (RWA), kde jsou aktiva držena offchain na bankovních účtech nebo v jiných depozitech, a následně jsou obchodována onchain prostřednictvím tokenů, které představují nárok na tato offchain aktiva. Tímto způsobem funguje například mnoho velkých stablecoinů.

Instituce, které drží offchain depozita, mohou mít vliv na ekosystém Etherea. Například během extrémního scénáře, kdy dojde ke spornému forku nebo upgradu sítě, mohou velcí vkladatelé ovlivnit, který řetězec se stane široce přijímaným, a to tím, že se rozhodnou uznávat tokeny pouze na jednom nebo druhém řetězci.

6.3 Regulační útok nebo tlak

Vlády a regulační orgány by mohly vyvíjet tlak na různé subjekty, které kontrolují důležité součásti technologického zásobníku Etherea, aby cenzurovaly nebo jinak zasahovaly do protokolu Etherea. Tyto tlaky by mohly ovlivnit i institucionální uživatele Etherea, což by mělo další důsledky pro jejich uživatele (např. banka, která kvůli regulačním zákazům již nemůže nabízet určité krypto produkty).

6.4 Organizační ovládnutí správy

Open source procesy správy a vývoje Etherea jsou řízeny různorodou a globální skupinou týmů a společností, které udržují základní klientský software, infrastrukturu a nástroje.

Různé formy vlivu (firemní akvizice, závislosti na financování, zaměstnávání klíčových přispěvatelů, střety zájmů uvnitř stávajících organizací) by mohly postupně posunout kulturu a priority správy Etherea. To může vést k souladu se specifickými komerčními nebo vnějšími zájmy, které se odchylují od étosu řízeného komunitou a zavedené roadmapy, což by mohlo časem oslabit neutralitu a odolnost Etherea.