Atak Nieskończonego Mintowania
Definition pending verification.
Atak nieskończonego mintowania, często określany jako 'glitch mintowania' lub 'luka reentrancy' w kontekście inteligentnych kontraktów, to rodzaj eksploatacji, w którym atakujący manipuluje logiką kontraktu, aby stworzyć (wyemitować) dowolnie dużą ilość tokenów lub aktywów. Zazwyczaj występuje to w protokołach zdecentralizowanych finansów (DeFi), szczególnie tych obejmujących mechanizmy mintowania tokenów, pożyczania lub zabezpieczania. Podstawowa luka często leży w sposobie, w jaki kontrakt obsługuje zewnętrzne wywołania lub aktualizuje swój wewnętrzny stan podczas transakcji. Na przykład kontrakt może pozwolić użytkownikowi na zdeponowanie zabezpieczenia, wyemitowanie nowego tokena na podstawie tego zabezpieczenia, a następnie wycofanie zabezpieczenia, wszystko w ramach jednej transakcji. Jeśli kontrakt emituje nowy token przed zweryfikowaniem depozytu zabezpieczenia lub poprawnym zaktualizowaniem swojego wewnętrznego stanu, atakujący może wywołać funkcję mintowania wielokrotnie w tym samym kontekście transakcji. Każde wywołanie może wyemitować więcej tokenów na podstawie tego samego początkowego (lub niewystarczająco zweryfikowanego) zabezpieczenia, prowadząc do stworzenia 'nieskończonej' lub znacznie zawyżonej ilości tokenów z powietrza. Dewaluuje to token i może opróżnić rezerwy protokołu. Zapobieganie takim atakom wymaga starannego projektowania inteligentnych kontraktów, w tym stosowania wzorca 'Checks-Effects-Interactions' (Sprawdzenia-Efekty-Interakcje), strażników reentrancy, prawidłowych aktualizacji stanu przed wywołaniami zewnętrznymi oraz dokładnych audytów.
graph LR
Center["Atak Nieskończonego Mintowania"]:::main
Pre_logic["logic"]:::pre --> Center
click Pre_logic "/terms/logic"
Rel_advanced_propulsion_systems["advanced-propulsion-systems"]:::related -.-> Center
click Rel_advanced_propulsion_systems "/terms/advanced-propulsion-systems"
Rel_consciousness_simulation_hardware["consciousness-simulation-hardware"]:::related -.-> Center
click Rel_consciousness_simulation_hardware "/terms/consciousness-simulation-hardware"
Rel_cognitive_enhancement["cognitive-enhancement"]:::related -.-> Center
click Rel_cognitive_enhancement "/terms/cognitive-enhancement"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Wyjaśnij jak 5-latkowi
Wyobraź sobie magiczną maszynę do ciastek, która ma dawać jedno ciastko za każdy wrzucony złoty monetę. Jeśli maszyna jest zepsuta, możesz wrzucić jedną monetę, dostać ciastko, a następnie użyć *tego* ciastka, aby oszukać maszynę i sprawić, by myślała, że wrzuciłeś kolejną monetę, otrzymując nieskończoną liczbę ciastek!
🤓 Expert Deep Dive
Ataki nieskończonego mintowania wykorzystują wady w logice przejścia stanu inteligentnych kontraktów, często związane z reentrancy lub nieprawidłowym obsługiwaniem wywołań zewnętrznych. Typowy schemat obejmuje funkcję, która: 1) Akceptuje dane wejściowe użytkownika (np. zabezpieczenie). 2) Wykonuje wywołanie zewnętrzne (np. do kontraktu tokena ERC777, który wyzwala funkcję zwrotną). 3) Aktualizuje stan wewnętrzny (np. emituje tokeny, aktualizuje salda). Jeśli wywołanie zewnętrzne wyzwoli reentrantne wywołanie z powrotem do oryginalnej funkcji zanim stan zostanie zaktualizowany (np. zabezpieczenie zostanie w pełni uwzględnione lub saldo zostanie skorygowane), atakujący może to wykorzystać. Na przykład, w protokole pożyczkowym, użytkownik deponuje zabezpieczenie C, wywołuje mint(loan_amount), który wewnętrznie wywołuje zewnętrzny kontrakt tokena. Funkcja zwrotna tego kontraktu tokena ponownie wchodzi do funkcji mint, pozwalając atakującemu na ponowne mintowanie przy użyciu tego samego zabezpieczenia C, zanim pierwsze wywołanie mint zakończy aktualizację stanu. Wzorzec 'Checks-Effects-Interactions' (Sprawdzenia-Efekty-Interakcje) jest kluczowy: weryfikuj warunki (Checks), aktualizuj stan wewnętrzny (Effects), a następnie wchodź w interakcje z zewnętrznymi kontraktami (Interactions). Strażnicy reentrancy (muteksy) mogą również zapobiegać rekurencyjnym wywołaniom w tym samym kontekście transakcji. Luki mogą również wynikać z możliwości reentrancy ERC777 lub wadliwych implementacji ERC20.