Перевірка смарт-контрактів

Смарт-контракти розроблені як «бездовірчі», що означає, що користувачам не потрібно довіряти третім сторонам (наприклад, розробникам і компаніям) перед взаємодією з контрактом. Як передумова для бездовірчості, користувачі та інші розробники повинні мати змогу перевірити вихідний код смарт-контракту. Верифікація вихідного коду запевняє користувачів і розробників, що опублікований код контракту є тим самим кодом, що виконується за адресою контракту в блокчейні Ethereum.

Важливо розрізняти «верифікацію вихідного коду» та «формальну верифікацію». Верифікація вихідного коду, яка буде детально пояснена нижче, означає перевірку того, що наданий вихідний код смарт-контракту на мові високого рівня (наприклад, Solidity) компілюється в той самий байт-код, що виконується за адресою контракту. Однак формальна верифікація описує перевірку правильності смарт-контракту, тобто того, що контракт поводиться так, як очікувалося. Хоча це й залежить від контексту, верифікація контракту зазвичай стосується верифікації вихідного коду.

Що таке верифікація вихідного коду?

Перед розгортанням смарт-контракту у віртуальній машині Ethereum (EVM) розробники компілюють вихідний код контракту — інструкції, написані на Solidity або іншій мові програмування високого рівня, — у байт-код. Оскільки EVM не може інтерпретувати інструкції високого рівня, компіляція вихідного коду в байт-код (тобто в інструкції низького рівня для машини) є необхідною для виконання логіки контракту в EVM.

Верифікація вихідного коду — це порівняння вихідного коду смарт-контракту та скомпільованого байт-коду, використаного під час створення контракту, для виявлення будь-яких відмінностей. Верифікація смарт-контрактів має значення, оскільки розрекламований код контракту може відрізнятися від того, що виконується в блокчейні.

Верифікація смарт-контрактів дає змогу дослідити, що робить контракт, через мову вищого рівня, якою він написаний, без необхідності читати машинний код. Функції, значення, а зазвичай і назви змінних та коментарі, залишаються такими ж, як і в оригінальному вихідному коді, що компілюється та розгортається. Це значно полегшує читання коду. Верифікація вихідного коду також забезпечує документацію коду, щоб кінцеві користувачі знали, для чого призначений смарт-контракт.

Що таке повна верифікація?

Існують деякі частини вихідного коду, які не впливають на скомпільований байт-код, наприклад, коментарі або назви змінних. Це означає, що два вихідні коди з різними назвами змінних і різними коментарями зможуть верифікувати один і той же контракт. Таким чином, зловмисник може додати оманливі коментарі або надати хибні назви змінних у вихідному коді, щоб верифікувати контракт із вихідним кодом, що відрізняється від оригінального.

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

Файл метаданих містить інформацію про компіляцію контракту, включно з вихідними файлами та їхніми хешами. Це означає, що якщо змінюються будь-які налаштування компіляції або навіть один байт в одному з вихідних файлів, файл метаданих також змінюється. Відповідно, хеш файлу метаданих, який додається до байт-коду, також змінюється. Це означає, що якщо байт-код контракту + доданий хеш метаданих збігаються з наданим вихідним кодом і налаштуваннями компіляції, ми можемо бути впевнені, що це той самий вихідний код, який використовувався під час початкової компіляції, і жоден байт не відрізняється.

Цей тип верифікації, який використовує хеш метаданих, називають «повною верифікацією (opens in a new tab)» (також «ідеальною верифікацією»). Якщо хеші метаданих не збігаються або не враховуються під час верифікації, це буде «частковий збіг», що наразі є більш поширеним способом верифікації контрактів. Без повної верифікації можна вставити зловмисний код (opens in a new tab), який не буде відображений у верифікованому вихідному коді. Більшість розробників не знають про повну верифікацію і не зберігають файл метаданих своєї компіляції, тому часткова верифікація досі була методом верифікації контрактів де-факто.

Чому верифікація вихідного коду є важливою?

Бездовірчість

Бездовірчість є, мабуть, найбільшою передумовою для смарт-контрактів і децентралізованих застосунків (dapps). Смарт-контракти є «незмінними» і не можуть бути змінені; контракт виконуватиме лише бізнес-логіку, визначену в коді на момент розгортання. Це означає, що розробники та підприємства не можуть втручатися в код контракту після його розгортання в Ethereum.

Щоб смарт-контракт був бездовірчим, код контракту має бути доступним для незалежної верифікації. Хоча скомпільований байт-код для кожного смарт-контракту є загальнодоступним у блокчейні, мову низького рівня важко зрозуміти як розробникам, так і користувачам.

Проєкти зменшують припущення щодо довіри, публікуючи вихідний код своїх контрактів. Але це призводить до іншої проблеми: важко перевірити, чи відповідає опублікований вихідний код байт-коду контракту. У цьому випадку цінність бездовірчості втрачається, оскільки користувачам доводиться довіряти розробникам, що вони не змінять бізнес-логіку контракту (тобто шляхом зміни байт-коду) перед його розгортанням у блокчейні.

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

Безпека користувачів

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

Публікація файлів вихідного коду смарт-контракту полегшує зацікавленим сторонам, наприклад, аудиторам, оцінку контракту на наявність потенційних векторів атаки. Коли кілька сторін незалежно верифікують смарт-контракт, користувачі отримують надійніші гарантії його безпеки.

Як верифікувати вихідний код для смарт-контрактів Ethereum

Розгортання смарт-контракту в Ethereum вимагає надсилання транзакції з корисним навантаженням даних (скомпільованим байт-кодом) на спеціальну адресу. Корисне навантаження даних генерується шляхом компіляції вихідного коду, а також аргументів конструктора (opens in a new tab) екземпляра контракту, доданих до корисного навантаження даних у транзакції. Компіляція є детермінованою, тобто вона завжди створює той самий результат (тобто байт-код контракту), якщо використовуються ті самі вихідні файли та налаштування компіляції (наприклад, версія компілятора, оптимізатор).

Верифікація смарт-контракту в основному включає наступні кроки:

Введення вихідних файлів і налаштувань компіляції в компілятор.
Компілятор виводить байт-код контракту
Отримання байт-коду розгорнутого контракту за заданою адресою
Порівняння розгорнутого байт-коду з перекомпільованим байт-кодом. Якщо коди збігаються, контракт верифікується з наданим вихідним кодом і налаштуваннями компіляції.
Крім того, якщо хеші метаданих у кінці байт-коду збігаються, це буде повний збіг.

Зверніть увагу, що це спрощений опис верифікації, і є багато винятків, які з цим не працюватимуть, наприклад, наявність незмінних змінних (opens in a new tab).

Інструменти верифікації вихідного коду

Традиційний процес верифікації контрактів може бути складним. Ось чому ми маємо інструменти для верифікації вихідного коду для смарт-контрактів, розгорнутих в Ethereum. Ці інструменти автоматизують значну частину верифікації вихідного коду, а також відбирають верифіковані контракти для зручності користувачів.

Etherscan

Хоча Etherscan переважно відомий як оглядач блокчейну Ethereum, він також пропонує сервіс верифікації вихідного коду (opens in a new tab) для розробників і користувачів смарт-контрактів.

Etherscan дозволяє перекомпілювати байт-код контракту з початкового корисного навантаження даних (вихідний код, адреса бібліотеки, налаштування компілятора, адреса контракту тощо) Якщо перекомпільований байт-код пов'язаний з байт-кодом (і параметрами конструктора) ончейн-контракту, то контракт верифікується (opens in a new tab).

Після верифікації вихідний код вашого контракту отримує позначку «Верифіковано» та публікується на Etherscan для перевірки іншими. Він також додається до розділу Верифіковані контракти (opens in a new tab) — репозиторію смарт-контрактів із верифікованими вихідними кодами.

Etherscan є найпопулярнішим інструментом для верифікації контрактів. Однак верифікація контрактів на Etherscan має недолік: вона не порівнює хеш метаданих ончейн-байт-коду та перекомпільованого байт-коду. Тому збіги на Etherscan є частковими.

Докладніше про верифікацію контрактів на Etherscan (opens in a new tab).

Blockscout

Blockscout (opens in a new tab) — це оглядач блокчейну з відкритим вихідним кодом, який також надає сервіс верифікації контрактів (opens in a new tab) для розробників і користувачів смарт-контрактів. Як альтернатива з відкритим вихідним кодом, Blockscout пропонує прозорість у тому, як виконується верифікація, і дозволяє спільноті робити внесок у покращення процесу верифікації.

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

Sourcify

Sourcify (opens in a new tab) — це ще один інструмент для верифікації контрактів, який є децентралізованим і має відкритий вихідний код. Це не оглядач блоків, він лише верифікує контракти в різних мережах на базі EVM (opens in a new tab). Він діє як публічна інфраструктура для інших інструментів, що створюються на його основі, і має на меті забезпечити більш зручну для людини взаємодію з контрактами за допомогою коментарів ABI та NatSpec (opens in a new tab), що містяться у файлі метаданих.

На відміну від Etherscan, Sourcify підтримує повні збіги з хешем метаданих. Верифіковані контракти обслуговуються в його публічному репозиторії (opens in a new tab) через HTTP та IPFS (opens in a new tab), що є децентралізованим, адресованим за вмістом (opens in a new tab) сховищем. Це дозволяє отримувати файл метаданих контракту через IPFS, оскільки доданий хеш метаданих є хешем IPFS.

Крім того, можна також отримати файли вихідного коду через IPFS, оскільки хеші IPFS цих файлів також знаходяться в метаданих. Контракт можна верифікувати, надавши файл метаданих і вихідні файли через його API, інтерфейс користувача (opens in a new tab) або за допомогою плагінів. Інструмент моніторингу Sourcify також відстежує створення контрактів у нових блоках і намагається верифікувати контракти, якщо їхні метадані та вихідні файли опубліковані в IPFS.

Докладніше про верифікацію контрактів на Sourcify (opens in a new tab).

Tenderly

Платформа Tenderly (opens in a new tab) дозволяє розробникам Web3 створювати, тестувати, контролювати та керувати смарт-контрактами. Поєднуючи інструменти налагодження зі спостережливістю та будівельними блоками інфраструктури, Tenderly допомагає розробникам прискорити розробку смарт-контрактів. Щоб повністю увімкнути функції Tenderly, розробникам необхідно виконати верифікацію вихідного коду (opens in a new tab), використовуючи декілька методів.

Можна верифікувати контракт приватно або публічно. Якщо верифіковано приватно, смарт-контракт буде видимий лише вам (та іншим учасникам вашого проєкту). Публічна верифікація контракту робить його видимим для всіх, хто використовує платформу Tenderly.

Ви можете верифікувати свої контракти за допомогою панелі керування (opens in a new tab), плагіна Tenderly для Hardhat (opens in a new tab) або CLI (opens in a new tab).

Під час верифікації контрактів через панель керування вам потрібно імпортувати вихідний файл або файл метаданих, згенерований компілятором Solidity, адресу/мережу та налаштування компілятора.

Використання плагіна Tenderly для Hardhat дає більше контролю над процесом верифікації з меншими зусиллями, дозволяючи вибирати між автоматичною (без коду) і ручною (на основі коду) верифікацією.

Для подальшого читання

Верифікація вихідного коду контракту (opens in a new tab)