Wskazówki dotyczące bezpieczeństwa kontraktów inteligentnych

Postępuj zgodnie z tymi ogólnymi zaleceniami, aby tworzyć bezpieczniejsze inteligentne kontrakty.

Wytyczne projektowe

Projekt kontraktu powinien być omówiony z wyprzedzeniem, przed napisaniem jakiejkolwiek linijki kodu.

Dokumentacja i specyfikacje

Dokumentacja może być pisana na różnych poziomach i powinna być aktualizowana w trakcie realizacji umów:

• Prosty opis systemu w języku angielskim, opisujący działanie kontraktów i wszelkie założenia dotyczące bazy kodu.
• Schematy i diagramy architektury, w tym interakcje kontraktów i maszyna stanu systemu. Slither printers (opens in a new tab) mogą pomóc w generowaniu tych schematów.
• Dokładna dokumentacja kodu, dla Solidity można użyć formatu Natspec (opens in a new tab).

Obliczenia on-chain a off-chain

• Jak najwięcej kodu trzymaj off-chain. Utrzymuj jak najmniejszą warstwę on-chain. Wstępnie przetwarzaj dane za pomocą kodu off-chain w taki sposób, aby weryfikacja on-chain była prosta. Potrzebujesz uporządkowanej listy? Posortuj listę off-chain, a następnie sprawdź tylko jej kolejność on-chain.

Możliwość aktualizacji

Omówiliśmy różne rozwiązania dotyczące możliwości aktualizacji w naszym wpisie na blogu (opens in a new tab). Dokonaj rozważnego wyboru, czy wspierać możliwość uaktualniania, czy nie, przed napisaniem jakiegokolwiek kodu. Decyzja wpłynie na to, jak ustrukturyzujesz swój kod. Generalnie zalecamy:

• Preferowanie migracji kontraktów (opens in a new tab) zamiast możliwości aktualizacji. Systemy migracji mają wiele tych samych zalet co systemy z możliwością aktualizacji, a przy tym są pozbawione ich wad.
• Stosowanie wzorca separacji danych zamiast wzorca delegatecallproxy. Jeśli Twój projekt ma wyraźną separację abstrakcji, możliwość aktualizacji z wykorzystaniem separacji danych będzie wymagać tylko kilku dostosowań. Delegatecallproxy wymaga wiedzy specjalistycznej o EVM i jest wysoce podatny na błędy.
• Udokumentuj procedurę migracji/aktualizacji przed wdrożeniem. Jeśli będziesz musiał(a) reagować w stresie bez żadnych wytycznych, popełnisz błędy. Zapisz procedurę do wykonania z wyprzedzeniem. Powinna ona obejmować:
  • Wywołania inicjujące nowe kontrakty
  • Gdzie są przechowywane klucze i jak uzyskać dostęp do nich
  • Jak sprawdzić wdrożenie! Opracowanie i przetestowanie skryptu po wdrożeniu.

Wytyczne dotyczące implementacji

Dąż do prostoty. Zawsze używaj najprostszego rozwiązania, które odpowiada Twoim celom. Każdy członek twojego zespołu powinien być w stanie zrozumieć Twoje rozwiązanie.

Składanie funkcji

Architektura Twojej bazy kodu powinna ułatwić sprawdzenie twojego kodu. Unikaj wyborów architektonicznych, które zmniejszają zdolność rozumowania o jego poprawności.

• Podziel logikę swojego systemu na wiele kontraktów lub grupuj podobne funkcje (np. uwierzytelnianie, arytmetyka itp.).
• Pisz małe funkcje o jasno określonym celu. Ułatwi to przegląd i pozwoli na testowanie poszczególnych komponentów.

Dziedziczenie

• Utrzymuj dziedziczenie na łatwym do zarządzania poziomie. Dziedziczenie powinno służyć do podziału logiki, jednak projekt powinien dążyć do zminimalizowania głębokości i szerokości drzewa dziedziczenia.
• Użyj inheritance printer (opens in a new tab) Slithera, aby sprawdzić hierarchię kontraktów. Narzędzie to pomoże Ci przeanalizować rozmiar hierarchii.

Zdarzenia

• Rejestruj wszystkie kluczowe operacje. Zdarzenia pomogą w debugowaniu kontraktu podczas jego tworzenia i monitorowaniu go po wdrożeniu.

Unikaj znanych pułapek

• Bądź świadomy(-a) najczęstszych problemów z bezpieczeństwem. Istnieje wiele zasobów online, z których można dowiedzieć się o powszechnych problemach, takich jak Ethernaut CTF (opens in a new tab), Capture the Ether (opens in a new tab) lub Not so smart contracts (opens in a new tab).
• Zwróć uwagę na sekcje z ostrzeżeniami w dokumentacji Solidity (opens in a new tab). Sekcje z ostrzeżeniami poinformują Cię o nieoczywistym zachowaniu języka.

Zależności

• Używaj dobrze przetestowanych bibliotek. Importowanie kodu z dobrze przetestowanych bibliotek zmniejszy prawdopodobieństwo, że napiszesz kod z błędami. Jeśli chcesz napisać kontrakt ERC20, użyj OpenZeppelin (opens in a new tab).
• Używaj menedżera zależności; unikaj kopiowania kodu. Jeśli polegasz na zewnętrznym źródle, musisz je na bieżąco aktualizować zgodnie z oryginalnym źródłem.

Testowanie i weryfikacja

• Pisz dokładne testy jednostkowe. Rozbudowany pakiet testów ma kluczowe znaczenie dla tworzenia oprogramowania wysokiej jakości.
• Pisz niestandardowe testy i właściwości dla narzędzi Slither (opens in a new tab), Echidna (opens in a new tab) i Manticore (opens in a new tab). Zautomatyzowane narzędzia pomogą zapewnić bezpieczeństwo Twojego kontraktu. Przejrzyj resztę tego przewodnika, aby dowiedzieć się, jak pisać skuteczne kontrole i właściwości.
• Użyj crytic.io (opens in a new tab). Crytic integruje się z GitHubem, zapewnia dostęp do prywatnych detektorów Slither i uruchamia niestandardowe testy właściwości z Echidny.

Solidity

• Preferuj Solidity 0.5 zamiast 0.4 i 0.6. Naszym zdaniem Solidity 0.5 jest bezpieczniejszy i ma lepsze wbudowane praktyki niż 0.4. Solidity 0.6 okazała się zbyt niestabilna do produkcji i wymaga czasu, aby dojrzeć.
• Użyj stabilnej wersji do kompilacji; użyj najnowszej wersji, aby sprawdzić ostrzeżenia. Sprawdź, czy Twój kod nie ma zgłoszonych problemów z najnowszą wersją kompilatora. Jednakże Solidity ma szybki cykl wydawniczy i historię błędów kompilatora, dlatego nie zalecamy najnowszej wersji do wdrożenia (zobacz rekomendację wersji solc od Slithera (opens in a new tab)).
• Nie używaj asemblera wstawkowego. Używanie asemblera wymaga specjalistycznej wiedzy na temat EVM. Nie pisz kodu EVM, jeśli nie opanowałeś(-aś) do perfekcji żółtej księgi.

Wytyczne dotyczące wdrażania

Po opracowaniu i wdrożeniu kontraktu:

• Monitoruj swoje kontrakty. Obserwuj logi i bądź gotów(-owa) do reakcji w przypadku naruszenia bezpieczeństwa kontraktu lub portfela.
• Dodaj swoje dane kontaktowe do blockchain-security-contacts (opens in a new tab). Ta lista pomaga stronom trzecim skontaktować się z Tobą w przypadku odkrycia luki w zabezpieczeniach.
• Zabezpiecz portfele uprzywilejowanych użytkowników. Postępuj zgodnie z naszymi najlepszymi praktykami (opens in a new tab), jeśli przechowujesz klucze w portfelach sprzętowych.
• Opracuj plan reakcji na incydenty. Weź pod uwagę, że Twoje inteligentne kontrakty mogą zostać naruszone. Nawet jeśli twoje kontrakty są wolne od błędów, atakujący może przejąć kontrolę nad kluczami właściciela umowy.

Strona ostatnio zaktualizowana: 3 marca 2026

m (opens in a new tab)

m (opens in a new tab)

n (opens in a new tab)

+5

Zobacz współtwórców