Як захистити смарт-контракти

Дотримуйтесь цих загальних рекомендацій для створення безпечніших смарт-контрактів.

Рекомендації щодо дизайну

Зміст контракту слід обговорювати заздалегідь перед написанням будь-якого рядка коду.

Документація та специфікації

Документація може бути написана на різних рівнях, і повинна оновлюватись під час реалізації контрактів:

• Простий опис системи англійською мовою, в якому описано, що роблять контракти, та будь-які припущення щодо кодової бази.
• Схема й архітектурні діаграми, включно з взаємодіями контрактів і скінченним автоматом системи. Принтери Slither (opens in a new tab) можуть допомогти згенерувати ці схеми.
• Ретельна документація коду; для Solidity можна використовувати формат Natspec (opens in a new tab).

Обчислення on-chain та off-chain

• Зберігайте якомога більше коду off-chain. Рівень on-chain має залишатися невеликим. Попередньо обробляйте дані за допомогою коду off-chain так, щоб верифікація on-chain була простою. Потрібен список замовлень? Відсортуйте список off-chain, і тільки потім перевірте його порядок on-chain.

Можливість оновлення

Ми обговорили різні рішення щодо можливості оновлення в нашій публікації в блозі (opens in a new tab). Перш ніж писати будь-який код, зробіть усвідомлений вибір на користь підтримки оновлення чи ні. Це рішення вплине на те, як ви структуруєте свій код. Загалом, ми рекомендуємо:

• Надавайте перевагу міграції контрактів (opens in a new tab) перед можливістю оновлення. Системи міграції мають багато тих самих переваг, що й оновлювані системи, але не мають їхніх недоліків.
• Використовуйте патерн розділення даних, а не delegatecallproxy. Якщо у вашому проєкті є чітке розділення абстракції, можливість оновлення за допомогою розділення даних потребуватиме лише кількох коригувань. Delegatecallproxy вимагає показник EVM та є дуже схильним до помилок.
• Задокументуйте процедуру міграції/оновлення перед розгортанням. Якщо вам доведеться реагувати в стресовій ситуації без будь-яких інструкцій, ви припуститеся помилок. Заздалегідь створіть методику, якої потрібно дотримуватись. Вона повинна включати в себе:
  • Пропозиції, що ініціюють нові контракти
  • Де зберігаються ключі, а також як їх отримати доступ
  • Як перевірити розгортання! Розробка та перевірка скрипту після розгортання.

Рекомендації щодо впровадження

Прагніть до простоти. Завжди використовуйте найпростіше рішення, яке відповідає вашій меті. Кожен член Вашої команди має розуміти Ваше рішення.

Композиція функцій

Архітектура Вашої кодової бази полегшить перегляд Вашого коду. Уникайте вибір архітектури, які понижують здатність мислити про його точність.

• Розділіть логіку вашої системи або за допомогою кількох контрактів, або шляхом групування подібних функцій (наприклад, автентифікація, арифметика тощо).
• Пишіть невеликі функції з чіткою метою. Це полегшить перевірку коду та дозволить тестувати окремі компоненти.

Успадкування

• Слідкуйте, щоб успадкування було керованим. Успадкування слід використовувати для поділу логіки, однак ваш проєкт має бути спрямований на мінімізацію глибини та ширини дерева успадкування.
• Використовуйте принтер успадкування (opens in a new tab) від Slither для перевірки ієрархії контрактів. Цей інструмент допоможе вам переглянути розмір ієрархії.

Події

• Записуйте всі важливі операції. Події допоможуть налагодити контракт під час розробки та відстежувати його після розгортання.

Уникайте відомих пасток

• Пам'ятайте про найпоширеніші проблеми безпеки. Існує багато онлайн-ресурсів для вивчення поширених проблем, наприклад Ethernaut CTF (opens in a new tab), Capture the Ether (opens in a new tab) або Not so smart contracts (opens in a new tab).
• Звертайте увагу на розділи з попередженнями в документації Solidity (opens in a new tab). У цих розділах міститься інформація про неочевидну поведінку мови.

Залежності

• Використовуйте бібліотеки, які пройшли належну перевірку. Імпорт коду з таких бібліотек зменшить імовірність того, що ви напишете код із помилками. Якщо ви хочете написати контракт ERC20, використовуйте OpenZeppelin (opens in a new tab).
• Використовуйте менеджер залежностей; уникайте копіювання коду. Якщо ви покладаєтеся на зовнішнє джерело, то повинні підтримувати його в актуальному стані відповідно до першоджерела.

Тестування та верифікація

• Пишіть ретельні юніт-тести. Розширений набір тестів має вирішальне значення для створення високоякісного програмного забезпечення.
• Пишіть власні перевірки та властивості для Slither (opens in a new tab), Echidna (opens in a new tab) та Manticore (opens in a new tab). Автоматизовані інструменти допоможуть переконатися, що ваш контракт є безпечним. Перегляньте решту даного посібника, щоб дізнатися як написати ефективні перевірки власного коду та властивостей.
• Використовуйте crytic.io (opens in a new tab). Crytic інтегрується з GitHub, надає доступ до приватних детекторів Slither і запускає власні перевірки властивостей з Echidna.

Solidity

• Надавайте перевагу Solidity 0.5 перед версіями 0.4 та 0.6. На нашу думку, Solidity 0.5 є безпечнішим і має кращі вбудовані практики, ніж 0.4. Як показує практика, Solidity 0.6 є надто нестабільною для виробництва та потребує часу, щоб бути готовою.
• Використовуйте стабільний випуск для компіляції; використовуйте останній випуск для перевірки попереджень. Перевірте, що у вашому коді немає зареєстрованих проблем з останньою версією компілятора. Однак Solidity має швидкий цикл випуску та історію помилок компілятора, тому ми не рекомендуємо останню версію для розгортання (див. рекомендації щодо версії solc (opens in a new tab) від Slither).
• Не використовуйте вбудований асемблер. Робота з асемблером вимагає глибоких знань EVM. Не пишіть код для EVM, якщо ви досконало не опанували «Жовту книгу».

Рекомендації щодо розгортання

Після розробки та розгортаня контракту:

• Відстежуйте свої контракти. Слідкуйте за журналами та будьте готові реагувати в разі компрометації контракту або гаманця.
• Додайте свою контактну інформацію до списку blockchain-security-contacts (opens in a new tab). Цей список допоможе третім сторонам зв'язатися з вами, якщо буде виявлено вразливість у системі безпеки.
• Захистіть гаманці привілейованих користувачів. Дотримуйтесь наших найкращих практик (opens in a new tab), якщо ви зберігаєте ключі в апаратних гаманцях.
• Майте план реагування на інциденти. Враховуйте, що ваші смарт-контракти можуть бути скомпрометовані. Навіть якщо у контрактах немає помилок, зловмисник може зламати приватний ключ.

Останні оновлення сторінки: 30 вересня 2025 р.

m (opens in a new tab)

w (opens in a new tab)

p (opens in a new tab)

+4

Переглянути учасників