Три помилки в блокчейні, які роблять людей мільйонерами — досвід інженера смарт-контрактів в Ambisafe

Про мову розробки Solidity та особливості роботи смарт-контрактів, через які з криптокомпаній «витікають» космічні гроші, продовжує розповідати Олексій Матіясевич — Lead Smart Contracts Engineer у компаніях Ambisafe та ChainSafe.

Нагадаємо, у першій частині інтерв’ю він поділився, як прийшов у сферу блокчейну, та чому стати тестувальником у цій ніші — гарна ідея.

Є позиції, де приймають програмістів джуніор-рівня

Є позиції, на які приймають програмістів навіть джуніор-рівня. Для QA при наймі буде плюсом досвід у тестуванні блокчейн-проектів, але це не обов’язкова умова. Для програмістів бувають різні позиції — наприклад, Ambisafe наймають спеціалістів без досвіду в блокчейні, але має бути хороший досвід роботи з Node.js або JavaScript, з написання фронтенду або бекенду (залежить від позиції). Вже на місці новачку розповідають та пояснюють все, що пов’язано з блокчейном.

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

У Solidity багато спільного з C++

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

Якщо більш детально розібратися в тому, як мова працює та які можливості має, до чого призводить виконання програми, як вона компілюється, то там набагато більше спільного з C++.

Тут є детальна взаємодія з пам’яттю, треба розуміти, як працює стек, треба вигадувати власні структури даних. В JS в тебе є купа бібліотек, нескінченні ресурси. А от коли розробляєш смарт-контракти на Solidity, то ресурси в тебе обмежені, кількість коду дуже сильно обмежена, плюс є власна специфіка, якої немає в інших мовах програмування. Смарт-контракти працюють на блокчейні — це специфіка, що має сенс лише в середовищі Ethereum.

Коли ти пишеш якусь програму на JS, то зазвичай вона існує сама по собі, або ти використовуєш якісь API інших сервісів, які десь запущені. А у випадку зі смарт-контрактами їх можна уявити як купу програм, що всі запущені на одному сервері, всі бачать одна одну, можуть одна до одної звертатись. І їх мільйони.

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

І ще момент, про який розробники звичайних систем часто взагалі не думають: у блокчейні фіксована кількість ресурсів, і їх використання дуже дороге. Доводиться думати про те, що, якщо ти додаєш додаткову логіку або використовуєш пам’ять, за це все доведеться платити користувачу або тому, хто запускає проект. Тут не вдасться, як на звичайних проектах, розподілити навантаження на кілька серверів. Тому маємо розробляти таким чином, щоб все працювало, при тому не було потреби у майбутньому збільшувати кількість ресурсів. Збільшиш — все всім стане дорожче. А якщо сервіс дорогий, то нащо людям ним користуватись, коли завжди можна знайти щось дешевше?

Через помилку мільйони доларів виводилися у невідомому напрямку

Перша розповсюджена помилка смарт-контракту, яку виявили ще у 2016 році (але вона актуальна і зараз) — це так звана проблема reentrancy. Найпростіший приклад: є функція, яка кладе гроші в смарт-контракт і записує, що у такого-то користувача $100 покладено на баланс, і є функція, яка забирає гроші зі смарт-контракту — дивиться, хто викликає її та чи є в користувача гроші на балансу. Якщо є, то вона відправляє їх по запиту.

Як функція працює? Коли вона відправляє кошти користувачу, що знімає $100 зі $100 — це означає, що баланс треба обнулити. Проте, якщо користувач в цей момент повторює запит на зняття $100 (до того, як смарт-контракт встигне оновити статус балансу користувача), то контракт подивиться, що в нього все ще записана ця сума, і знову відправить користувачу $100. Але то вже будуть гроші інших людей, звісно. За допомогою цієї помилки мільйони доларів виводилися у невідомому напрямку, і це періодично відбувається зараз.

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

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

Шахраї обманюють смарт-контракти

Зазвичай для роботи фінансових інструментів потрібна інформація про цінність чогось — курс долару, вартість NFT, тощо. Вона береться з певних джерел — оракулів цін. Якщо хтось зможе зманіпулювати ціною в оракулі (навіть на секунди), це дуже сильно нашкодить проекту.

Наприклад, візьмемо видачу позик під заставу. Ти приносиш $100 в смарт-контракт як заставу і просиш, щоб він видав тобі позику €50. Смарт-контракт перевіряє за допомогою оракулу, чи справді розмір позики менше, ніж вартість застави — так, €50 менше $100, і давати позику безпечно. Але якщо в тебе є можливість зманіпулювати ціною евро відносно долару, то сума позики може бути космічна. Якщо вдається якось змінити в оракулі курс перед тим, як запросити позику, смарт-контракт може подумати, що $1 коштує €10 тисяч, припустимо. Ти кладеш $100 і просиш дати позику в €1 млн — ОК, смарт-контракт видає тобі вказану суму. Твоя маніпуляція в оракулі діяти перестає, ціна стає нормальною, але гроші назад смарт-контракт забрати вже не може, бо розраховує, що оракул — надійне джерело ціни, де інформацією не вийде зманіпулювати.

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

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

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