З серпня швидко розвивається екосистема SUI. Згідно з DefiLlama, SUI TVL перевищила 1 мільярд доларів, що на 200% більше за останні два місяці, а наразі обсяг торгівлі Cetus, Dex, побудований на SUI, перевищує 160 мільйонів доларів на день.

9 жовтня мережа SUI запустила власний USDC, що буде продовжувати привертати більше коштів в екосистему SUI. Як важливий учасник екосистеми Move, SUI зобов'язаний надавати швидкі та безпечні транзакційні послуги для різноманітних сценаріїв застосування блокчейну.

У цій статті Beosin допоможе вам зрозуміти проблеми безпеки, з якими стикаються користувачі та розробники екосистеми SUI з десятирічним досвідом аудиту безпеки.

Безпека контракту

Sui використовує Move як мову програмування для смарт-контрактів. Move був розроблений як виконувальна мова байт-коду з вбудованими алгоритмами безпеки та перевірником байт-коду, та використовує статичні виклики при виклику контрактів.

Цей дизайн дозволяє Move вирішувати поширені вразливості розумних контрактів, такі як атаки повторного виклику, переповнення цілих чисел, подвійне витрачання та потенційні проблеми компілятора, але розробники все ще можуть ненавмисно вводити вразливості в розробку контракту. У відповідь, Beosin у 2023 році представив Move Lint, статичний інструмент виявлення, який автоматизує виявлення потенційних ризиків безпеки в контрактах та знаходить вразливості.

У додаток до інструментів виявлення, наступні питання безпеки, на які розробники повинні звернути додаткову увагу при розробці контрактів Move для поліпшення безпеки:

1) Переповнення цілочисельного значення

Порівняно з іншими мовами розумних контрактів, Move автоматично перевіряє проблеми переповнення за замовчуванням при виконанні цілих математичних операцій, що може запобігти великій кількості проблем з переповненням, але все ж таки є дві речі, на які варто звернути увагу:

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

Коли автоматична перевірка переповнення в Move набуває чинності, виконання функції генерує виняток, що, якщо неправильно спроектовано, може призвести до невиконання проектного бізнесу згідно очікувань, що призводить до атак DoS.

2) Керування дозволами та доступом

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

Розробники можуть використовувати Move Prover, щоб перевірити, чи застосовує програма явну політику керування доступом. Наприклад, у std::offer ми можемо побачити, що функція припиняється, коли одержувач не знаходиться в білому списку:

3) Проблема залежності в порядку транзакцій

Залежність від упорядкування транзакцій (TOD) вказує на те, що поведінка контракту може мати різні результати в залежності від порядку виконання транзакцій, особливо в децентралізованому середовищі, де гірник або верифікатор може вибирати порядок транзакцій. Це може призвести до ризиків, таких як атаки передбачування.

У SUI все ще залежить від виробника блоків виконати порядок транзакцій, тому контракти MOVE все ще можуть бути піддані цій проблемі, якщо вони розроблені залежно від порядку транзакцій для зміни стану.

4) Проблема споживання газу

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

5) Точність обчислення

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

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

6) Керування об'єктами

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

7) Проблеми проектування та впровадження бізнес-логіки

Наприклад, з впровадженням миттєвого кредиту в проекті Sui DeFi, зловмисники можуть використовувати флеш-кредит для здійснення нападів на великі кошти, такі як маніпуляція цінами.

У поширеній функції обміну токенів AMM розробники можуть використовувати Move Prover, щоб перевірити, чи правильно змінилася кількість токенів:

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

Виклики в екосистемі Sui

В даний час DeFi і мемкоїни Sui процвітають, а обсяг торгів і TVL привернули вибухове зростання. Згодом з'являється все більше видів шахрайства та торгівлі спамом, яких користувачам потрібно уникати.

Фішінг

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

Через характеристики SUI: все є об'єктом, не лише токени у гаманці користувача. NFT є об'єктом, а також участь користувача у добуванні DeFi, забезпечення ліквідності та інших сертифікатів. Якщо станеться фішингова атака, хакер може одразу перевести всі активи користувача всередині екосистеми SUI.

Шахрайство з токенами

У мережі Sui є багато фейкових токенів та honeypots. Зокрема, коли користувачі торгують memecoins у мережі Sui, вони можуть випадково потрапити в пастку.

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

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

Виклик MEV

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

Sui використовує Narwhal як пам'ятковий басейн для призначення незавершених транзакцій вузлам, та використовує алгоритм Bullshark як рушій консенсусу для сортування транзакцій.

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

Відмова від відповідальності:

1. Ця стаття передрукована з [ beosin]. Усі права на авторські права належать оригінальному автору [beosin]. Якщо є зауваження до цього повторного друку, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, що належать автору, і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою gate Learn. Якщо не зазначено, копіювання, розповсюдження або плагіат перекладених статей заборонені.