Ethereum Foundation zkoumá transakční aserce, které by uživatelům umožnily připojit k transakci vymahatelné podmínky pro její konečný výsledek, místo aby se spoléhalo pouze na schválení požadované akce. Výzkum, který je součástí iniciativy Trillion Dollar Security, se zaměřuje na nedostatek v oblasti bezpečnosti transakcí: platný podpis nezaručuje, že výsledné zůstatky, oprávnění nebo ovládací prvky účtu odpovídají záměru podepisujícího.
Klíčová zjištění
- Navrhované kontroly by během provádění vyhodnocovaly výsledky transakce a vracely zpět akce, které poruší podepsané pravidlo.
- Ochrana závisí na pravidlech schválených nezávisle na potenciálně kompromitovaném nástroji pro sestavování transakcí.
- Výzkum by mohl podpořit bezpečnostní zásady peněženek, delegované agenty a pracovní postupy solverů, nejde však o oznámené nasazení.
Obsah
- Proč může schválení transakce přesto vést ke ztrátě
- Jak by transakční aserce kontrolovaly výsledek
- Jaké informace by navrhovaná implementace zpřístupnila
- Kde by se musely změnit peněženky a protokoly
- Co by mohly přinést agentům a pracovním postupům solverů
- Závěr
Proč může schválení transakce přesto vést ke ztrátě
Ethereum provede požadavek, který uživatel autorizuje, podle kódu a stavu dostupných v okamžiku jeho provedení. Tyto podmínky se mohou lišit od toho, co uživatel zkontroloval. Například se může před provedením změnit implementace proxy, zatímco pořadí transakcí může ovlivnit cenu, za kterou proběhne swap.
Foundation rozlišuje mezi zavádějícími požadavky a nežádoucími výsledky. Při útocích na Bybit a BadgerDAO zobrazovala kompromitovaná rozhraní požadavky k podpisu, které se lišily od toho, co se uživatelé domnívali, že schvalují. Naproti tomu i přesně zobrazený požadavek může umožnit ekonomicky škodlivý výsledek.
Jako příklad uvádí swap kolaterálu mezi Aave a CoW, který zahrnoval přibližně 50,4 milionu aEthUSDT. Nízká likvidita AAVE a limit gasu CoW vedly k ověřené kotaci ve výši zhruba 329 aEthAAVE. Přestože se zobrazilo varování před cenovým dopadem ve výši 99,9 % a potvrzení, že by mohlo dojít ke ztrátě celé hodnoty, uživatel transakci podepsal a obdržel tokeny v hodnotě přibližně 36 000 USD.
Toto rozlišení vysvětluje, proč lepší popisy transakcí nejsou úplným řešením. Clear Signing pomáhá uživatelům porozumět požadované akci. Simulace odhaduje účinky na základě vybraného stavu blockchainu. Ani jedno samo o sobě nevynucuje nezávislou podmínku týkající se skutečně dosaženého výsledku.
| Položka | Podrobnosti |
|---|---|
| TXTRACE | Vypisuje čisté změny stavu a emitované události dané transakce. |
| TXDIFF | Načítá počáteční a konečné hodnoty pro zadané adresy a úložné sloty. |
| EVENTDATACOPY | Kopíruje data události do paměti, kde je lze zkontrolovat. |
| Informace o nasazení | Navrhovaná data o změnách stavu zahrnují nově nasazené kontrakty a jejich hashe kódu. |
Jak by transakční aserce kontrolovaly výsledek
Aserce by pomocí logiky pouze pro čtení porovnala počáteční a konečný stav transakce poté, co byly její akce provedeny. Podmínka by byla součástí transakce a podepsala by se spolu s akcemi. Pokud by nebyla splněna, akce by se vrátily zpět.
Mezi možná pravidla patří minimální přijaté množství, limit útraty, omezení nových schválení tokenů nebo zachování řídicí logiky účtu. Navrhovaná možnost kontroly by se nevztahovala pouze na zůstatky, ale také na úložiště, kód, nově nasazené kontrakty a emitované události.
Existující kontroly v kontraktech již chrání vybrané výsledky. Uniswap může odmítnout swapy, jejichž výstup je nižší než stanovené minimum, a bezpečnostní prvek Safe může po provedení zkontrolovat stav účtu. Omezením je přehled o dění: tyto kontroly musí předem počítat s tím, co mají zkoumat, a obecně závisejí na rozhraních, která zpřístupňují jiné kontrakty. Proxy například nemusí poskytovat funkci, která odhaluje adresu její implementace.
Nativní aserce by zpřístupnily ke kontrole veškeré čisté účinky transakce, včetně změn, které by běžný ochranný prvek nemusel znát ani hledat. Širší přehled je však užitečný pouze tehdy, je-li dané pravidlo důvěryhodné. Škodlivé rozhraní by mohlo dodat podmínku, která jeho vlastnímu útoku nebrání, takže zásada musí vycházet z nezávisle schváleného záměru, zásad účtu nebo chráněné logiky protokolu.
Jaké informace by navrhovaná implementace zpřístupnila
Oznámení Ethereum Foundation o nativních transakčních asercích popisuje EIP-7906 jako možnou implementaci, nikoli jako definitivní návrh. Vychází z transakcí typu frame v EIP-8141, které řadí validační a akční kroky do posloupnosti. Zavedení EIP-8141 je plánováno v rámci upgradu Hegotá; EIP-7906 dosáhlo fáze Considered for Inclusion, jeho zařazení do tohoto upgradu však nebylo potvrzeno.
Podle tohoto přístupu by rámec POST_TX určený pouze pro čtení kontroloval výsledky na konci provádění. Navrhované instrukce pro přístup k datům by fungovaly pouze v tomto rámci, nikoli v celé EVM.
Informace by popisovaly čisté účinky, nikoli historii každého průběžného zápisu. Úložný slot, jehož hodnota se opakovaně měnila, by se zobrazil s počáteční a konečnou hodnotou; slot vrácený na původní hodnotu by se nezobrazil. Proto je důležité rozlišovat mezi vynucováním konečného stavu a sledováním každého kroku provádění.
Pokud by kontrola selhala, tělo provádění by se vrátilo zpět, transakce by však v bloku zůstala jako neúspěšná. Plátce gasu by i nadále hradil spotřebovaný gas, což by bránilo tomu, aby záměrně selhávající transakce bezplatně zatěžovaly tvůrce bloků.
Kde by se musely změnit peněženky a protokoly
Návrh poskytuje mechanismus kontroly, nikoli automatickou povinnost jej používat. U transakcí uživatele by peněženka musela začlenit bezpečnostní zásadu do sestavování transakce, místo aby nástroj pro její sestavení mohl tuto zásadu vynechat. Zásada by mohla vycházet z vlastní simulace peněženky nebo platit jako trvalé pravidlo účtu.
V případě protokolů by ochrana musela být součástí podmínek přístupu k chráněné funkci. Nestačilo by předložit transakci podporující aserce: volání by muselo obsahovat konkrétní kontrolu, kterou protokol vyžaduje. Změnily by se tím požadavky na integraci pro volající, zatímco do již nasazených neměnných kontraktů by nebylo možné tuto kontrolu přístupu dodatečně doplnit.
Tyto závislosti oddělují potenciálně výkonnou schopnost EVM od záruky pro koncové uživatele. Účinná ochrana by vyžadovala jak správně nastavenou podmínku, tak software, který její použití důsledně vynucuje.
Co by mohly přinést agentům a pracovním postupům solverů
Delegované agenty by bylo možné omezit nejen oprávněními, ale také výsledky. Limity týkající se toho, které kontrakty agent smí použít nebo kolik může utratit, by se daly doplnit požadavky na to, jaký stav po každé transakci zůstane.
U provádění založeného na solverech by protokol mohl stanovit přijatelný výsledek a zároveň ponechat solveru volbu postupu. Záruka by se vztahovala na transakci v jedné síti, nikoli na cestu napříč více blockchainy.
Aserce by také mohly kontrolovat úklid po pracovním postupu, například vrácení nepoužitých tokenů a odvolání zbývajících schválení. Foundation během dalšího rozvoje návrhu žádá o zpětnou vazbu týmy peněženek a protokolů, takže jde o možné směry výzkumu, nikoli o oznámené funkce produktu.
Závěr
Nativní transakční aserce by přesunuly část bezpečnosti transakcí na Ethereu od výkladu požadavku k vynucování jeho výsledku. Jejich praktická hodnota by závisela na důvěryhodných zásadách a na jejich přijetí peněženkami a protokoly, které by je uplatňovaly.
Další zprávy
Upozornění
Tento článek FinanceVelix poskytuje obecné informace, nikoli individuální finanční, investiční, právní nebo daňové poradenství. Ceny kryptoměn se mohou rychle měnit a můžete přijít o všechny investované prostředky. Uvedená fakta vycházejí z materiálů dostupných v době zveřejnění a mohou se změnit. Důležité informace si ověřte nezávisle a v případě potřeby se obraťte na kvalifikovaného odborníka. Zmínka o aktivu, společnosti nebo službě nepředstavuje doporučení.
