Помилка Ethereum повертає розумні контракти на креслярську дошку

Помилки є нормальною частиною програмного забезпечення, але на Ethereum вони можуть бути винятково небезпечними.

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

Коротше кажучи, власники децентралізованих смарт-контрактів (тих, які T можуть бути оновлені ONE власником) нічого T можуть зробити, щоб виправити помилку.

Через два дні після звіт про помилку було випущено, розробники розгорнули виправлення у Solidity версії 0.4.4. Але помилка впливає на деякі адреси та типи даних у цих контрактах, тому їх T можна змінити під час оновлення.

Хороша новина полягає в тому, що помилка, можливо, не вплинула на багато розумних контрактів.

Творець Solidity Крістіан Райтвіснер розповів CoinDesk , що він провів «напівавтоматичний» аналіз кожної програми Ethereum , перерахованої популярним дослідником блоків, і виявив, що з 12 000 контрактів лише чотири були придатними для використання.

Райтвіснер сказав, що в жодному з цих контрактів немає ефіру, оскільки вони, ймовірно, використовувалися для тестування. Але варто зауважити, що не всі контракти відображаються в Etherscan, вибраному провіднику блоків. (Загалом існує понад 200 000 контрактів, тому важко сказати, наскільки безпечні кошти, що залишилися за контрактом).

Загалом, це здається незначним недоліком у порівнянні з The DAO, найпомітнішим прикладом того, що смарт-контракт не працює належним чином. Однак це викликало дискусію про те, що може статися у випадку інших серйозних помилок, враховуючи, що не всі смарт-контракти матимуть центрального власника, який може оновлювати їх, якщо щось піде не так.

ONE спостерігач у соціальних мережах, наприклад, сперечався що це може бути «кротова купа на схилі великої гори» подібних питань.

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

Аспірант Національного університету Сінгапуру Лой Луу сказав, що для Ethereum було б краще, якби користувачі навчилися розгортати безпечні смарт-контракти важким шляхом, у децентралізованій манері.

Луу сказав:

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

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

Усунення проблеми

Програми, написані на зручних для читання мовах Ethereum вищого рівня, таких як Solidity або Serpent, компілюються в код байтового рівня перед додаванням у блокчейн. Проблема тут полягала в Технології компіляції.

Щоб вирішити проблему, Reitweissner рекомендований що розробники роблять дві речі. По-ONE, у разі складання нового контракту розробникам потрібно оновити до нової версії Solidity, щоб уникнути помилки.

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

Райтвіснер розповіла про цю пораду, пояснивши, що існує два типи контрактів: централізований і децентралізований, де ONE не має «особливих привілеїв».

Перший тип, ймовірно, пропонує певний механізм оновлення або спосіб вилучити кошти з контракту.

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

Однак Райтвіснер сказав, що розробники можуть захиститися від майбутніх проблем (наприклад, із Solidity), виконавши декілька речей.

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

Контракти з можливістю оновлення

Однак є кілька способів обійти це.

Керівник зовнішніх зв’язків Фонду Ethereum Хадсон Джеймсон описав спосіб оновлення смарт-контрактів, який потенційно може бути децентралізованим, стверджуючи, що додавання способу оновлення живого коду є необхідністю.

«Загальне відчуття наших розробників полягає в тому, що на цій ранній стадії важливо мати захист від збоїв у вашому коді, щоб безпечно дезактивувати або оновити контракти, які мають велику цінність», — сказав він.

Джеймсон описав деякі потенційні «відмовостійкі» смарт-контракти, де власники можуть оновлювати свої контракти навіть після того, як вони розгорнуті в Ethereum, або де смарт-контракти можуть виявляти, коли відбувається щось підозріле.

Він сказав, що вони T обов’язково повинні бути централізованими або під контролем ONE власника. Наприклад, у вас може бути смарт-контракт, який обмежує кількість активів, які можна вивести за раз.

«Отже, якщо зловмисник намагається витягти кошти або активи з контракту, це може спровокувати децентралізовану реакцію, як-от блокування доступу та сповіщення інших людей, які використовують контракт, про те, що їм може знадобитися зняти свої кошти», – сказав він.

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

З нетерпінням чекаю

Смарт-контракти на Ethereum Classic (група, яка відокремилася від Ethereum через ідеологічні розбіжності) також страждають від помилки, оскільки її блокчейн покладається на той самий набір інструментів.

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

«ONE із можливих шляхів — перевести розробку мови смарт-контракту з об’єктно-процедурної парадигми до функціональної», — сказав він.

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

Зокрема, щодо Solidity, ще одна помилка, яку неможливо зупинити, потенційно може вплинути на інші смарт-контракти в майбутньому.

Райтвіснер зауважив, що компілятор завжди може ввести помилку, і цілком можливо, що Solidity або Serpent (інша мова смарт-контрактів Ethereum) мають інші невиявлені недоліки.

Однак він зазначив, що за понад два роки розробки це була перша серйозна помилка, виявлена ​​в мові смарт-контрактів.

Зображення будівництва через Shutterstock