Czym jest ryzyko smart contract?

Zaawansowany28 paź 2026 · 7 min czytania

Ryzyko smart contract to szansa, że Pan/Pani straci wartość — albo użyteczny dostęp do niej — ponieważ zachowanie programu on-chain, jego zależności, jego oracle albo jego władza admin / upgrade daje wynik, którego Pan/Pani nie zamierzał(a) przy depozycie, zatwierdzeniu albo interakcji. Ryzyko smart contract to nie «łańcuch zapomniał o Pana/Pani coinach».

Definicja

Ryzyko smart contract to szansa, że Pan/Pani straci wartość — albo użyteczny dostęp do niej — ponieważ zachowanie programu on-chain, jego zależności, jego oracle albo jego władza admin / upgrade daje wynik, którego Pan/Pani nie zamierzał(a) przy depozycie, zatwierdzeniu albo interakcji.

Prosto:

Ryzyko smart contract to nie «łańcuch zapomniał o Pana/Pani coinach». To ryzyko, że kod, który Pan/Pani autoryzował(a) — albo kod, który potrafi przepisać reguły po depozycie — przenosi, zamraża, źle wycenia albo drenuje wartość według własnej logiki.

Opieka nad aktywami pyta, kto może wydawać. Ryzyko smart contract pyta, co wolno robić programom, których Pan/Pani dotyka, jakie założenia o świecie przyjmują i kto może później zmienić te reguły.

W tradingu

Prawdziwe pytanie tradingowe

Dla tego sleeve — czy Pan/Pani potrafi nazwać kontrakty, powierzchnie zaufania (oracle, upgrade’e, adminów) oraz kształt straty, który Pan/Pani jeszcze przeżyje, jeśli te powierzchnie zawiodą — czy raczej traktuje «audytowane / wysokie TVL / znajome logo» jako substytut pomiaru?

Należy odpowiadać per depozyt i per powierzchnia zatwierdzenia. Odpowiedź trzeba powtórzyć po upgrade’ach, po zmianach oracle oraz po skokach size. Jeden slogan na każdą interakcję DeFi to pułapka samego rozpoznania, którą ta strona zostawia za sobą.

Dwa liczniki, które ludzie spłaszczają do jednego

	Market-wide nagłówki o «hacku»	Sleeve protokołów DeFi
Co często dominuje straty w dolarach	Klucze, signerzy, infra walletów, front-endy, kompromis admina	Logika protokołu i założenia ekonomiczne
Co często dominuje liczbę incydentów	Mieszane; bugi w kodzie nadal częste	Logika, kontrola dostępu, oracle, ścieżki księgowe
Błąd tradera	Traktować każdą historię straty jako «kontrakty są niebezpieczne, więc unikać DeFi»	Traktować każdą odznakę audytu jako «ryzyko kodu jest zamknięte»
Przydatna reakcja	Trzymać licznik opieki nad aktywami dla venue i kluczy	Trzymać licznik kontrakt / oracle / upgrade dla depozytów

Oba liczniki są realne. Ich mieszanie daje zły hedge: albo Pan/Pani niedoskalowuje każdy protokół, bo kradzieże kluczy CeFi wypełniły newsy, albo nadmiernie ufa vaultowi, bo «większość skradzionej wartości w tym roku to były klucze».

Ograniczony odczyt niedawnych branżowych tally: w całym rynku infrastruktura i kompromis kluczy często biorą większość wartości; wewnątrz strat protokołów DeFi logika często bierze większość masy strat. Należy użyć obu faktów. Nie wybierać jednego i odrzucać drugiego.

Taksonomia (klasy, a nie jedna flaga «zhackowane»)

Klasa	Co się psuje	Jak widać stratę
Kontrola dostępu	Funkcje uprzywilejowane wywoływalne przez złą stronę	Otwiera się ścieżka mint, pause, upgrade, set-price, drain
Logika biznesowa	Zamierzone reguły ≠ zakodowane reguły	Złe nagrody, zła matematyka collateral, zepsuta likwidacja albo mint/redeem
Reentrancy / wywołania zewnętrzne	Kontrola oddana, zanim stan jest finalny	Powtórny withdraw, reentry między funkcjami, hook callbacks
Arytmetyka / zaokrąglenia / shares	Matematyka fixed-point, fee, share albo rezerw dryfuje	Cichy wyciek wartości; stany ekstremalne wzmacniają błędy one-wei
Oracle / cienka płynność	Logika bezpieczeństwa ufa ruchomej albo nieświeżej cenie	Pożyczki underwater, niesprawiedliwe likwidacje, nadmuchany collateral
Wzmacnianie flashloan	Kapitał w tej samej tx pcha słabe założenie do złamania	Bug root był już wcześniej; tymczasowy kapitał sprawił, że się opłacił
Proxy / upgradeability	Implementation albo ścieżka initializer / admin jest słaba	Przepisanie logiki, niezainicjalizowany claim, korupcja storage
Griefing / DoS	Dostępność albo exit zablokowane bez czystej «kradzieży»	Withdrawale utknięte, likwidacje zablokowane, dystrybucje revertują

Listy Top 10 w stylu OWASP rotują rankingi z roku na rok. Kontrola dostępu, logika biznesowa i oracle zostają blisko szczytu; ścieżki ułatwione flashloanem oraz kategorie proxy/upgrade urosły jako praktyczne powierzchnie. Listę należy traktować jako menu monitorów, a nie kartę bingo.

Powierzchnie drugiego rzędu (gdzie doświadczony size naprawdę umiera)

Podręcznikowa reentrancy to nie jedyny licznik. Te ścieżki drugiego rzędu zwykle liczą się bardziej, gdy Pan/Pani opuszcza toy size:

Kompozycyjność — vault jest w porządku, dopóki nie wycenia share’ów z peer pool, wrappera albo bridge’a, którego Pan/Pani nigdy nie przeglądał(a).
Luki zakresu audytu — wiele post-mortemów «audytowanych» protokołów pokazuje, że ścieżka ataku siedziała poza każdym publicznym zakresem audytu albo w dependency / keeperze / forwarderze, którego raport nigdy nie obejmował.
Niezweryfikowany albo niedopasowany bytecode — nazwa w UI ≠ adres w explorerze ≠ implementation, na którą proxy obecnie wskazuje.
Upgrade bez okna przeglądu — brak timelocka, pojedynczy upgrader EOA albo cicha zamiana implementation po depozycie.
Emergency pause jako zaufanie — pause może uratować przed drainem i może też uwięzić exit; kto trzyma przełącznik, jest częścią ceny ryzyka.
Częściowy vs całkowity drain — niektóre bugi zbierają zaokrąglenia; niektóre opróżniają pulę; niektóre zamrażają środki bez transferu. Size należy dobierać do najgorszego wiarygodnego kształtu, nie do średniego nagłówka.
Stare «bezpieczne» kontrakty — stare deploymenty wracają na celownik; wiek nie jest aureolą bezpieczeństwa, jeśli w adresie nadal siedzą incentywy.

Powierzchnie resztkowe na venue wallet-first

Trading wallet-first (w tym venue takie jak edgeX) obniża ryzyko «IOU z bilansu firmy», gdy to Pana/Pani autoryzacja rusza środki. Ryzyko kontraktu nadal pojawia się, gdy:

Pan/Pani zatwierdza spendera, który później może ściągnąć tokeny
Pan/Pani deponuje do vaultu, bridge’a albo produktu strukturalnego
matching albo settlement zależy od kontraktów, których ścieżki upgrade albo oracle Pan/Pani nie zmapował(a)
sklonowany frontend prosi o podpis przeciwko innemu adresowi niż ten, który Pan/Pani zweryfikował(a)

Jeśli checklista pyta tylko «czy to non-custodial?», Pan/Pani nadal stoi na starym liczniku.

Sceny przepracowane (osąd, nie slogany)

A — Zaokrąglenia pod ciśnieniem flashloan.

Matematyka withdraw puli zaokrągla w złą stronę w ekstremalnym ticku. Normalny flow wygląda dobrze. Kapitał pożyczony w tej samej transakcji pcha pulę w ten stan, wyciąga lukę, spłaca pożyczkę i zostawia LP za krótko. Flashloan był wzmacniaczem. Bugiem było księgowanie.

B — «Hack oracle», który był kontrolą dostępu.

Aktualizacje ceny mają iść ścieżką keeper / forwarder. Słaby forwarder pozwala atakującemu dojść do `setPrices`. Drukują zły mark, otwierają i zamykają przeciwko niemu i odchodzą. Marka feedu nie była rootem; kto mógł pisać do feedu — tak.

C — Audytowany vault, zależność poza zakresem.

Trzy PDF-y audytu siedzą na stronie docs. Drain używa helpera biblioteki albo weryfikatora bridge’a, których te raporty nigdy nie objęły zakresem. «Byliśmy audytowani» było prawdziwe i niepełne. Należy pytać jaki commit, jakie pliki, jakie ścieżki ekonomiczne — i co zmieniło się od tego czasu.

D — Proxy dzień pierwszy vs rok drugi.

Pan/Pani dobierał(a) size depozytu, gdy implementation była zamrożona, a multisig + timelock były publiczne. Sześć miesięcy później ląduje upgrade z krótkim oknem i nową rolą. Ten sam adres proxy; inna powierzchnia zaufania. Należy ponownie underwrite’ować albo wyjść — nie dziedziczyć tezy z zeszłego roku.

Monitoring (co falsyfikować)

Należy scorować każdy materialny sleeve kontraktowy względem faktów, które Pan/Pani może sprawdzić — nie względem odznak.

Monitor	Pass wygląda jak	Fail wygląda jak
Mapa adresów	Pan/Pani potrafi nazwać proxy vs implementation vs spender	«Kontrakt ze strony», niezweryfikowany
Mapa uprawnień	Role dla upgrade, pause, mint, zapisu oracle są znane	Jeden god-key «owner», którego Pan/Pani nie potrafi opisać
Ścieżka upgrade	Timelock / multisig / kultura publikowanych diffów	Ciche upgrade’e EOA
Design oracle	Zagregowany / TWAP / świeżość / granice odchylenia tam, gdzie size ich potrzebuje	Spot z tej samej tx z cienkiej puli dla likwidacji
Higiena audytu	Zakres, data, hash commitu; bounty nadal żywe	Ściana logo; brak zakresu; kod przesunięty po raporcie
Kompozycyjność	Pan/Pani wie, od których zewnętrznych pul / bridge’y zależy sleeve	Zagnieżdżone wrappery, których Pan/Pani nie potrafi nazwać
Powierzchnia allowance	Least privilege; okresowe revoke	Unlimited approve na zawsze do każdego routera
Drill exit	Mały withdraw niedawno zadziałał	Pamięć mięśniowa tylko-depozyt
Postawa incident	Pause scoped; monitoring; nawyk publicznych post-mortemów	TVL jako dowód bezpieczeństwa

Warunkowe defaulty (zacząć tutaj, potem dostosować)

Jeśli Pan/Pani nie potrafi nazwać adresu kontraktu i kto może go upgrade’ować → nie skalować sleeve.
Jeśli pricing krytyczny dla bezpieczeństwa czyta spot z cienkiej puli w tej samej transakcji → traktować ścieżki likwidacji / mint / redeem jako wrogie, dopóki nie udowodniono inaczej.
Jeśli jedynym pocieszeniem jest «audytowane» bez zakresu albo commitu → wyceniać audyt jako marketing, nie jako licznik.
Jeśli po depozycie wylądował upgrade → ponownie underwrite’ować; nie zakładać ciągłości.
Jeśli kapitał wielkości flashloan może ruszyć oracle albo matematykę share’ów, od której Pan/Pani zależy → dobierać size tak, jakby ten kapitał się pojawił.
Jeśli hot trading i depozyty protokołowe dzielą unlimited approvals → rozdzielić powierzchnie w tym samym tygodniu.
Jeśli size ostro urósł → przerobić mapę, nawet gdy UI się nie zmienił.

Ruchy designu

Oddzielić zatwierdzenia floatu tradingowego od depozytów idle protokołu.
Preferować zweryfikowane adresy wklejane ze znanego źródła zamiast «Connect and hope».
Ograniczyć każdy sleeve protokołu do kształtu straty, który Pan/Pani przeżyje (skim vs empty vs freeze).
Przećwiczyć mały withdraw przed skalowaniem.
Cofać stare unlimited allowances według harmonogramu.
Preferować venue i protokoły, które publikują adresy kontraktów, politykę upgrade i zakres audytu — a potem i tak prowadzić własne monitory.
Napisać krótką kolejność stresową: który sleeve Pan/Pani exit’uje pierwszy, gdy odpali alert upgrade albo oracle.

Granice tego frameworku

Ta strona nie zastępuje profesjonalnego audytu, formalnej weryfikacji ani incident response dla builderów. Nie wycenia każdej osobliwości chain, bridge ani finality L2. Nie uratuje sleeve, jeśli Pan/Pani zignoruje phishing i podpisze złośliwego spendera. Sąsiednie liczniki — opieka nad aktywami, zatwierdzenia, MEV, ryzyko protokołu vs platformy vs użytkownika — nadal obowiązują. Tę taksonomię należy użyć, by przestać spłaszczać każdą stratę on-chain do jednego słowa.

Nie mylić z

Ryzyko opieki nad aktywami — władza wydawania / awaria kontrahenta-vs-operatora; nakłada się na depozyty protokołowe, to nie ten sam licznik.
Ryzyko zatwierdzenia tokena — allowance, które może umożliwić późniejszy pull; często drzwi do ryzyka kontraktu, nie całe drzewo exploitu.
Ryzyko ceny — mark może się ruszyć, podczas gdy zachowanie kodu i kontrola zostają nienaruszone.
Ryzyko płynności / slippage — nie da się wyjść z size na rynku ≠ vault opróżniony, zamrożony albo źle wyceniony przez logikę programu.
MEV / sandwich — ordering i ekstrakcja wokół Pana/Pani transakcji; może dotykać designu oracle/swap, nadal nie jest synonimem buga logiki.

Udostępnij

Powiązane artykuły

Gotowy na kolejny krok?

Przejdź do rejestracji lub tradingu z tej strony za pomocą oficjalnych linków.

Zacznij handlować na edgeX

Zastrzeżenie

Te treści mają wyłącznie charakter edukacyjny i nie stanowią porady inwestycyjnej. Handel aktywami cyfrowymi i instrumentami pochodnymi wiąże się z ryzykiem. Przed rozpoczęciem handlu upewnij się, że rozumiesz produkty, i weź pod uwagę swoją sytuację.

Słownik