Přehled bezpečnostních výzev

Jedním z definujících rysů blockchainů je atomická povaha transakcí: jakmile je aktualizace zaznamenána do blockchainu, není zde žá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 provoznímu riziku: jediná chyba, kompromitovaný klíč nebo unáhlené schválení mohou vést k nevratné ztrátě.

V důsledku toho padá značná část odpovědnosti za bezpečnost na uživatele. Aby mohli jednotlivci a organizace bezpečně používat Ethereum, musí bezpečně držet a spravovat klíče, interagovat s aplikacemi na blockchainu a používat své klíče k podepisování transakcí pro převod aktiv nebo jinou aktualizaci stavu Etherea.

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

1.1 Správa klíčů

Mnoho uživatelů není vybaveno k bezpečné správě kryptografických klíčů.

Nejpoužívanější softwarové peněženky spoléhají na to, že si uživatelé bezpečně uloží seed fráze, které představují jejich podkladový 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.

Hardwarové peněženky jsou alternativou, která uživatelům umožňuje spravovat kryptografický klíč uložený ve speciálním fyzickém zařízení. Hardwarové peněženky však mají své vlastní chyby a prostor pro útok. Hardwarové peněženky mohou být ztraceny, poškozeny nebo odcizeny. Mnoho hardwarových peněženek není open source a mohou 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 ze správy vlastních prostředků, když může být kompromitována fyzickou krádeží nebo napadením.

Podnikoví a institucionální uživatelé čelí dalším výzvám v oblasti správy klíčů. Pokud jednotliví zaměstnanci drží klíče (např. jako součást peněženky s více podpisy), musí být organizace schopna je nahradit a vytvořit nové kvůli personálním změnám v čase. Požadavky na shodu 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ěženek 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ředstavovat 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 zanechává všechny druhy uživatelů zranitelnými vůči škodlivým chytrým kontraktům, phishingu, podvodům, podvrženým rozhraním, kompromitacím front-endu a základním chybám uživatelů.

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

V mnoha aplikacích Etherea je běžné, že uživatelé udělují určitá oprávnění podkladové aplikaci jako součást běžného používání. Například uživatel může udělit decentralizované burze jako Uniswap oprávnění k přesunu svých tokenů, aby je mohl směnit 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. Uživatelé nemají ve většině peněženek žádný způsob, jak spravovat nebo kontrolovat svá stávající schválení.

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

Stejné riziko platí i pro firemní uživatele. Například organizace se může rozhodnout udělit routeru DEX neomezené povolení pro USDC pro provozní pohodlí, což je pak vystavuje rizikům, pokud je kontrakt routeru aktualizován.

1.4 Kompromitovaná webová rozhraní

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

Tyto front-endy 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 třetích stran. Kompromitovaný uživatelský zážitek aplikace může přesměrovat uživatele všech druhů 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 naopak zesílit bezpečnostní rizika pro všechny druhy uživatelů.

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 vzorců uživatelského zážitku vystavuje uživatele rizikům, např. opětovné použití adres, 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 pro určité případy použití. Kromě těchto problémů může vytvářet expozici vůči 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 ohrožena, pokud by byl systém transparentní.

1.6 Fragmentace

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

Například uživatelé se nemohou spolehnout na konzistentní vizuální podněty UX, aby se chránili před phishingem a podvržením, protože se liší v jednotlivých peněženkách. 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 historii 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í v celém životním cyklu softwaru, který vede k nasazení kódu na blockchain. Mezi klíčové pokroky patří:

• Bezpečnostní audit se stal 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 dozrály a staly se standardní praxí.
• Knihovny předem auditovaných běžných komponent poskytly vývojářům stavební bloky, které jsou bezpečné již ve výchozím nastavení.
• Byly přijaty techniky formálního ověřování, zejména pro přemostění, systémy stakingu a kontrakty s vysokou hodnotou.
• Zlepšila se bezpečnostní kultura ekosystému a osvědčené postupy.
• Vytvoření významných programů odměn (bounty), které posílily aplikační vrstvu.

V této oblasti však stále existují slabiny a prostory pro zlepšení.

2.1 Zranitelnosti kontraktů

Navzdory pokrokům v oblasti 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, aby vývojový tým mohl aplikaci nadále aktualizovat a vylepšovat. To však s sebou nese rizika. Aktualizace mohou vést k novým zranitelnostem nebo k úplné ztrátě prostředků uživatelů v případě škodlivé aktualizace.
• Re-entrancy, kde kontrakt A volá externí kontrakt B před aktualizací svého vlastního interního stavu a kontrakt B volá zpět původní kontrakt A před dokončením prvního volání.
• Nebezpečné použití externích knihoven, kde kontrakt volá externí knihovnu, která může být neauditovaná, škodlivá nebo aktualizovatelná.
• Neauditované komponenty. Ačkoli se audit a používání standardních knihoven zlepšilo, vývojáři se někdy spoléhají na neauditované komponenty ve svých aplikacích.
• Selhání řízení přístupu, kde jsou oprávnění nesprávně nakonfigurována nebo definována příliš široce, což umožňuje útočníkům provádět škodlivé akce.
• Neoprávněný přístup, kde soukromý klíč, který je schopen ovládat kontrakt, získá škodlivý aktér.
• Přemostění a interakce mezi řetězci. Přemostění a protokoly mezi řetězci představují další složitost a útočníci mohou zneužít slabiny ve způsobu, jakým jsou zprávy mezi řetězci předávány nebo ověřovány.
• Delegace účtu vlastněného externě (EOA) nebo zneužití podpisu. Škodlivé aplikace mohou přimět uživatele k podepsání úplné delegace jejich účtu jiné straně, což umožňuje krádež. Škodlivé aplikace mohou také používat podepsané zprávy od uživatele neočekávanými způsoby, např. při útoku typu replay attack.
• Vznikající riziko chyb způsobených generováním kódu umělou inteligencí nebo automatizovanými nástroji pro refaktorování.

2.2 Zkušenosti vývojářů, nástroje a programovací jazyky

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

• Chybějící bezpečné výchozí 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í hodnoty, jako jsou neomezená schválení tokenů ve funkci approve() nebo ve výchozím nastavení nezahrnují vzory ří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í vytvářet požadované funkce od nuly, což zvyšuje riziko zranitelností. Chybí standardizované bezpečné komponenty nebo rámce pro pokročilé bezpečnostní pracovní postupy.
• Nekonzistentní pokrytí testováním v různých sadách nástrojů, stejně jako absence norem pro používání osvědčených technik, jako je fuzzing nebo kontrola invariantů.
• Nízké přijetí metod formálního ověřování. Techniky formálního ověřování jsou mocné, ale jsou složité, nákladné, vyžadují specializované odborné znalosti 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 výrobě softwaru k ověření bezpečnosti ve fázi specifikace.
• Problémy související s ověřováním 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 sjednotily přístupy, zůstávají roztříštěné 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í člověkem čitelný kód jako Solidity na bajtkód používaný samotným EVM) mohou mít chyby, které do chytrých kontraktů vnášejí chyby 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é dopady.
• Rozmanitost a hloubka programovacích jazyků. Ačkoli má Solidity vybudovaný hluboký ekosystém nástrojů, někteří vývojáři chtějí modernější bezpečnostní funkce, které se nacházejí v jiných programovacích jazycích, jako je bezpečnost paměti.

2.3 Posouzení rizik kódu na blockchainu

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

Tyto systémy představují prostor pro útok jak pro vrstvu peněženky a aplikace (např. koncové body RPC pro peněženky), tak pro samotný protokol Etherea (např. mnoho validátorů je hostováno v cloudové infrastruktuře). Kompromitace soukromého klíče, phishing a nedostatek granulárních kontrol 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ž podkladový protokol blockchainu zůstává bezpečný.

3.1 Řetězce druhé vrstvy

Řetězce druhé vrstvy (L2) slouží jako rozšíření pro Ethereum, umožňují rychlejší prostředí s nižšími poplatky a zároveň si zachovávají některé charakteristické bezpečnostní záruky hlavní sítě Ethereum (v závislosti na jejich konkrétním návrhu). Mají však také své vlastní odlišné plochy pro útok, včetně:

• Složitost přemostěných aktiv s více skoky. Když aktiva cestují mezi L1 a více L2, jsou vystavena několika sadám kontraktů, které všechny musí být bezpečné. Nesoulad v účetnictví nebo výpadky v řetězcích L2 mohou zavést zranitelnosti, které mohou být zneužity útočníky.
• Rollup L2 se spoléhají na systémy prokazování správnosti aktualizací stavu. Chyby nebo nesprávné konfigurace v těchto systémech mohou zastavit nebo zabránit finalizaci, nebo umožnit finalizaci falešných aktualizací stavu vedoucích ke ztrátě prostředků uživatelů.
• Bezpečnostní rady jsou skupiny držitelů klíčů, které slouží jako „záložní“ mechanismus k aktualizaci softwaru L2 nebo k reakci na určité nouzové situace. Samotné bezpečnostní rady představují rizika, protože kompromitace nebo tajná dohoda mezi členy by mohla ohrozit prostředky uživatelů nebo zmrazit aktiva.

Podrobný rámec a monitorovací panel, který hodnotí a porovnává výkon a bezpečnost L2, naleznete na L2Beatopens in a new tab.

3.2 Infrastruktura RPC a uzlů

Aplikace Etherea závisí na malém počtu poskytovatelů infrastruktury pro přístup RPC, API a služby 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řestali fungovat nebo se pokusili cenzurovat či omezit přístup, mnoha uživatelům by mohl být znemožněn přístup k Ethereu prostřednictvím jejich peněženky nebo aplikace, dokud by nebyli schopni přejít na nového poskytovatele RPC nebo jiné infrastruktury. Někteří z těchto poskytovatelů již dříve pozastavili nebo zrušili účty spojené s blockchainovou aktivitou, což vyvolává obavy o jejich dlouhodobou spolehlivost 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 DNS, kdy útočník vloží škodlivý falešný frontend.
• Zabavení domény, kdy vláda nebo registrátor může domény zabavit.
• Phishing prostřednictvím podobných domén, kdy útočníci registrují téměř identické názvy, aby zmátli uživatele.

3.4 Softwarový dodavatelský řetězec a knihovny

Vývojáři Etherea se spoléhají na open-source knihovny, často stahované 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, kde útočníci kompromitují široce používaný balíček nebo publikují jeden pod podobným názvem
• Unesené závislosti, kde správci ztratí kontrolu nad projektem a škodlivý aktér vloží škodlivý kód
• Kompromitace vývojáře, kde nainstalované balíčky obsahují kód, který útočníkovi poskytne kontrolu nad počítačem vývojáře.

3.5 Služby doručování front-endu a související rizika

Mnoho aplikací Etherea poskytuje své front-endy 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 poskytnou uživatelům změněný frontend.

3.6 Cenzura na úrovni poskytovatele internetových služeb

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

• 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 proti známým uzlům Etherea
• Hloubková inspekce paketů pro identifikaci a cenzuru 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.

Konsensuální protokol Etherea se v praxi ukázal jako robustní, s nulovými výpadky od prvního spuštění v roce 2015 a napříč několika vylepšeními. 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 výběru větve a finality Etherea jsou odolná, ale nejsou nezranitelná. Během určitých okrajových podmínek (jako je prodloužená neshoda validátorů, chyby v klientech nebo síťové oddíly) by se konsensus mohl zastavit nebo dočasně rozdělit. V extrémních podmínkách by to mohlo vést ke kaskádovitým penalizacím validátorů prostřednictvím pokut za nečinnost nebo slashingu, což by dále mohlo vést k odlivu kapitálu od validátorů.

4.2 Rozmanitost klientů

Vedoucí pozice Etherea v rozmanitosti klientů chrání síť před chybami v jakémkoli jednotlivém klientovi. Rozmanitost klientů by se však stále mohla 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é množství váhy validátorů je soustředěno v protokolech likvidního stakingu, depozitních službách a u velkých operátorů uzlů. Tato koncentrace může vést k rizikům, jako jsou:

• Získání kontroly nad správou nebo ovlivňování. Pokud by se entity ovládající velké množství vkladů (nebo entity s právní mocí ovlivňovat tyto entity) koordinovaly, mohly by mít nepřiměřený 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í vylepšení 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í slashing a mezery v koordinaci

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

4.5 Ekonomické a herně-teoretické vektory útoku

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

• Útoky typu griefing nebo slash griefing. Validátorům mohou vzniknout náklady nebo penalizace za slashing nikoli kvůli jejich vlastním chybám, ale kvůli nepřátelskému chování, jehož jediným cílem je poškodit ostatní za čistou ztrátu pro útočníka.
• Strategické odchody nebo časovaná nečinnost. Validátoři by se mohli úmyslně odpojit nebo odejít v kritických okamžicích, aby maximalizovali zisky nebo narušili konsensus s minimálními penalizacemi.
• Tajná dohoda mezi validátory nebo relay. Koordinované chování mezi validátory nebo mezi relay 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 bloku nebo návrhu likvidního stakingu. Aktéři mohou manipulovat vzácnými podmínkami protokolu, aby získali nepřiměřené odměny.

4.6 Kvantové riziko

Základní kryptografie Etherea (např. podpisy na eliptických křivkách jako secp256k1) by jednoho dne mohla být prolomena kvantovými počítači. I když se nejedná o bezprostřední riziko, důvěryhodná hrozba by mohla okamžitě učinit stávající peněženky, kontrakty a klíče pro staking zranitelnými. Tato budoucí výzva oslabuje dlouhodobé záruky Etherea pro uživatele.

Cesty migrace na kvantově odolnou kryptografii (např. prostřednictvím post-kvantových podpisových schémat) musí být navrženy, testovány a případně zakotveny v protokolu roky předtím, než budou potřeba. Organizace v celém ekosystému Etherea, včetně nadace Ethereum Foundation, aktivně zkoumají tyto možnosti a monitorují rizika.

I idealizovaný blockchainový ekosystém bude mít rizika, útoky a zranitelnosti. Když se něco pokazí, musí existovat efektivní systémy pro zmírnění, detekci a reakci. Výzvy zde zahrnují:

• Dosažení postiženého týmu. Může být obtížné se spojit s týmem, jehož aplikace byla kompromitována. To může vést k hodinám zpoždění, což omezuje schopnost respondentů obnovit prostředky.
• Eskalace problémů v souvisejících organizacích. Pokud problém zahrnuje platformu (jako je sociální síť nebo centralizovaná burza), může být pro respondenty náročné eskalovat problém, pokud nemají předem existující kontakt.
• Koordinace reakce. Často je nejasné, kolik týmů pro reakci na incidenty pomáhá postižené aplikaci, což vede k nedorozuměním nebo plýtvání úsilím, když by skupinové úsilí mohlo být efektivnější.
• Chybějící monitorovací schopnosti. Může být obtížné monitorovat problémy na blockchainu i mimo něj, což by poskytlo včasné varování a zajistilo rychlou reakci na hrozby.
• Přístup k pojištění. Pojištění je základní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 mají tendenci být spíše dlouhodobě orientovaná a týkají se Etherea jako celku spíše než bezpečnosti jednotlivých uživatelů nebo aplikací.

6.1 Centralizace vkladů

Centralizace velkého množství vkladů může představovat rizika pro Ethereum jako celek, pokud se entity ovládající tyto vklady rozhodnou tajně dohodnout.
Tato ekonomická centralizace vytváří potenciál pro ovládnutí sociální správy. Pokud malá skupina validátorů ovládá nadpoloviční většinu vkladů, mohla by:

• Koordinovat nebo odolávat větvím.
• Cenzurovat určité transakce nebo kontrakty.
• Podkopávat konsensus komunity hrozbou odchodu nebo opozicí.

Pokud by k tomuto extrémnímu scénáři došlo, komunita Etherea navrhla, že odpovědí by mohl být "sociální slashing". Sociální slashing je použití mimoblockchainového (offchain) sociálního konsensu k rozhodnutí o slashování (potrestání) validátorů, kteří se chovají škodlivě, jako kontrola jejich moci. Pro zavedení takových opatření však neexistují žádné jasné normy, postupy ani nástroje (viz oddíl 4.4).

6.2 Centralizace aktiv mimo blockchain

Ethereum hostí značné množství reálných aktiv, kde jsou aktiva držena mimo blockchain na bankovních účtech nebo v jiných vkladech, s nimiž se pak obchoduje na blockchainu prostřednictvím tokenů, které představují nárok na aktiva mimo blockchain. Tímto způsobem funguje například mnoho velkých stabilních kryptoměn.

Instituce, které drží vklady mimo blockchain, mohou mít vliv na ekosystém Etherea. Například během extrémního scénáře, kdy dojde ke sporné větvi nebo vylepšení sítě, mohou velcí vkladatelé ovlivnit, který řetězec se stane široce přijímaným tím, že se rozhodnou uznat tokeny pouze na jednom řetězci nebo na druhém.

6.3 Regulační útok nebo tlak

Vlády a regulační orgány by mohly vyvíjet tlak na různé subjekty, které ovládají důležité součásti balíku Etherea, aby cenzurovaly nebo jinak zasahovaly do protokolu Etherea. Těmito tlaky by mohli být ovlivněni i institucionální uživatelé Etherea, což by mělo další důsledky pro jejich uživatele (např. banka, která již nemůže nabízet určité kryptoprodukty kvůli regulačním zákazům).

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

Procesy správy a vývoje Etherea s otevřeným zdrojovým kódem jsou řízeny rozmanitou a globální sadou 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ě změnit kulturu a priority správy Etherea. To může vést k sladění se specifickými komerčními nebo externími zájmy, které se odchylují od komunitou řízeného étosu a zavedeného plánu, což by mohlo časem oslabit neutralitu a odolnost Etherea.