У швидкозмінюваній галузі технології блокчейну TON (The Open Network) здобуває все більшу увагу розробників як ефективна та гнучка блокчейн-платформа. Унікальна архітектура та функції TON надають потужні інструменти та багаті можливості для розробки децентралізованих додатків.

Однак зі збільшенням функціональності та складності безпека смартконтрактів стала більш критичною. FunC, мова програмування смартконтрактів на TON, відома своєю гнучкістю та ефективністю, але вона також ставить багато потенційних ризиків та викликів. Написання безпечних та надійних смартконтрактів вимагає від розробників глибокого розуміння характеристик FunC та потенційних ризиків, пов'язаних з ним.

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

Аналіз асинхронних функцій та механізму облікового запису TON

Асинхронні виклики в смартконтрактах

Мережевий шардинг та асинхронний зв'язок

Блокчейн TON розроблений з трьома типами ланцюгів: Masterchain, Workingchains і Shardchains.

Мастерчейн є ядром всієї мережі, відповідальним за зберігання метаданих та механізму консенсусу всієї мережі. Він реєструє стани всіх Робочихчейнів та Шардчейнів і забезпечує консистентність та безпеку мережі. Робочічейни - це незалежні блокчейни, з максимальною кількістю 2^32 ланцюги, відповідальні за обробку певних типів транзакцій та розумних контрактів. Кожен Робочийчейн може мати власні правила та функції, щоб задовольнити різні потреби застосування. Шардчейни - це підланцюги Робочихчейнів, використовувані для подальшого поділу навантаження Робочихчейнів, що покращує потужність обробки та масштабованість. Кожен Робочийчейн може бути розбитий на до 2^60 Шардчейнів, з Шардчейнами, які незалежно обробляють деякі транзакції для досягнення ефективної паралельної обробки.

У теорії кожен обліковий запис може ексклюзивно займати Shardchain, при цьому кожен обліковий запис незалежно підтримує свій баланс COIN/TOKEN. Транзакції між обліковими записами можуть бути повністю паралельними. Облікові записи спілкуються через асинхронні повідомлення, а шлях, яким повідомлення подорожують між Shardchains, складає log_16(N) - 1, де N - кількість Shardchains.

Джерело зображення: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574 світу web3У Тоні взаємодія здійснюється за допомогою надсилання та отримання повідомлень. Ці повідомлення можуть бути внутрішніми (зазвичай надсилаються смарт-контрактами, що взаємодіють один з одним) або зовнішніми (надсилаються зовнішніми джерелами). Процес передачі повідомлень не вимагає негайних відповідей від цільового контракту, що дозволяє відправнику продовжити виконання логіки, що залишилася. Цей механізм асинхронного обміну повідомленнями пропонує більшу гнучкість і масштабованість порівняно з синхронними викликами Ethereum, зменшуючи вузькі місця в продуктивності, спричинені очікуванням відповідей, а також створюючи проблеми в обробці паралелізму та умов перегонів.

Формат та структура повідомлення

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

Черга повідомлень та обробка статусів

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

Переваги асинхронного обміну повідомленнями

•Ефективний механізм розщеплення: Асинхронний механізм TON добре сумісний з його дизайном розщеплення. Кожен шар незалежно обробляє повідомлення контракту та зміни стану, уникнення затримок, спричинених синхронізацією між шарами. Цей дизайн підвищує загальну пропускну здатність та масштабованість мережі.

• Зменшення використання ресурсів: Асинхронні повідомлення не вимагають негайної відповіді, що дозволяє TON контрактам виконуватися через кілька блоків і уникати надмірного використання ресурсів у межах одного блоку. Це дозволяє TON підтримувати більш складні та вимогливі на ресурси смартконтракти.

•Стійкість до відмов та надійність: Асинхронний механізм передачі повідомлень збільшує стійкість системи до відмов. Наприклад, якщо контракт не може вчасно відповісти на повідомлення через обмеження ресурсів або інші причини, відправник може продовжувати обробку іншої логіки, запобігаючи затримкам у системі через затримки в одному контракті.

Виклики асинхронного дизайну контрактів

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

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

•Міркування безпеки: асинхронні контракти схильні до таких ризиків, як атаки типу "людина посередині" або атаки повторного відтворення під час обробки міжконтрактного зв'язку. Тому при розробці асинхронних контрактів важливо враховувати ці потенційні ризики безпеки та вживати превентивних заходів, таких як використання часових позначок, випадкових чисел або підходів з мультипідписом.

Модель журналу

TON (The Open Network) використовує унікальну модель абстракції облікового запису та рахункову модель при проектуванні своєї блокчейн-інфраструктури. Гнучкість цієї моделі відображається в тому, як вона управляє станами облікових записів, передачею повідомлень та виконанням контрактів.

Абстракція облікового запису

Модель облікових записів TON використовує абстракцію на основі контрактів, де кожен обліковий запис може бути розглянутий як контракт. Це дещо схоже на модель абстракції облікових записів Ethereum, але воно більш гнучке і загальне. У TON облікові записи не є лише контейнерами для активів; вони також включають код контракту та дані стану. Кожен обліковий запис складається з його коду, даних та логіки обробки повідомлень.

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

Гнучкість: Оскільки кожний обліковий запис може виконувати власний код контракту, облікові записи TON можуть реалізовувати дуже складну логіку. Облікові записи не просто зберігачі балансів, але можуть обробляти складні переходи стану, взаємодію між обліковими записами та навіть автоматизацію на підставі певних умов. Це робить облікову модель TON більш масштабованою та гнучкою порівняно з традиційними моделями облікових записів блокчейну.

Структура журналу

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

Сховище стану

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

Стан облікового запису або смарт-контракту зазвичай включає наступне:

1. Баланс базової валюти 2. Баланс інших валют 3. Код смарт-контракту (або його хеш) 4. Постійні дані смарт-контракту (або його хеш Merkle) 5. Статистика за кількістю постійних одиниць зберігання даних та використанням необроблених байтів 6. Нещодавня мітка часу платежів до постійного сховища смарт-контракту (по суті, номер основного блоку ланцюга) 7. Публічний ключ, необхідний для переказу валюти і відправки повідомлень з цього рахунку (необов'язково; за замовчуванням він дорівнює самому account_id). У деяких випадках тут можна знайти більш складні коди перевірки підпису, подібні до виходів транзакцій Bitcoin; У таких випадках account_id буде хеш цього коду.

Не всю інформацію необхідно вказувати для кожного облікового запису. Наприклад, код смарт-контракту має значення лише для смарт-контрактів, а не для «простих» облікових записів. Крім того, хоча кожен обліковий запис повинен мати ненульовий баланс базової валюти (наприклад, Граму для основного робочого ланцюга та шарових ланцюгів), баланси інших валют можуть бути нульовими. Щоб уникнути зберігання невикористаних даних, під час створення робочого ланцюга визначається тип сумового добутку, використовуючи різні маркерні байти для розрізнення різних «функцій-конструкторів». У кінцевому рахунку стан облікового запису зберігається як колекція блоків в постійному сховищі ТВМ.

Передача повідомлень та обробка

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

Модель газу

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

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

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

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

Тон смарт-контракти легко ігнорувати уразливості

В наш попередній аналіз забезпечення статті на TON ми докладно описали поширені вразливості безпеки в екосистемі TON. Для отримання додаткової інформації, будь ласка, перегляньте таблицю нижче:

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

(1) Оптимізація читабельності коду

У розумних контрактах TON часто використовуються числа для зберігання даних, пов'язаних з надсиланням повідомлень. Наприклад, у наведеному нижче коді числа використовуються для представлення відповідних ідентифікаторів та довжини зберігання даних, що значно погіршує читабельність та збереженість коду. Іншим розробникам може бути важко зрозуміти значення та призначення цих чисел при читанні коду. Щоб поліпшити читабельність та збереженість, рекомендується визначати ключові числові значення як іменовані константи. Наприклад, визначте 0x18якNON_BOUNCEABLE.

1. check_std_addr(address);було msg = begin_cell() store_uint(0x18, 6) ;; nobounce store_slice(address) store_coins(amount) store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1) end_cell();send_raw_message(msg, 1);

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

(2) Використання end_parse()забезпечити цілісність даних

У контрактах TON розбір даних відбувається за фіксованим порядком, поетапно завантажуючи вказані типи даних з вихідних даних. Цей метод розбору забезпечує послідовність та точність даних, як показано нижче:

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

(3) Винятки, спричинені невідповідністю зберігання даних та типів

Це стосується переважно збігуціле числоіuintтипи зберігання. Наприклад, у наступному коді, store_int()функція використовується для зберігання intзначення-42, але завантажити_uint()використовується для завантаження цього значення, що може призвести до винятку.

(4) Відповідне використання inline_refівбудованийМодифікатори

Спочатку важливо розрізняти між вбудований та inline_ref Модифікатори:

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

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

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

(5) Визначення правильної робочої ланцюга

TON дозволяє створювати до 2^32 робочих ланцюгів, кожен з яких може бути поділений на до 2^60 підланок. Спочатку існує два робочих ланцюги: головний ланцюг (-1) та базовий ланцюг (0). При обчисленні цільових адрес в контрактах важливо вказати правильний ідентифікатор робочого ланцюга, щоб забезпечити, що згенерована адреса гаманця належить до правильного робочого ланцюга. Щоб уникнути створення неправильних адрес, рекомендується використовувати force_chain()явно вказати ідентифікатор ланцюга.

(6) Уникайте конфліктів кодів помилок

Ефективне управління кодами помилок має вирішальне значення для розробки контракту, щоб забезпечити послідовність і уникнути плутанини. Для смарт-контрактів TON переконайтеся, що кожен код помилки є унікальним у контракті, щоб запобігти конфліктам і двозначним повідомленням про помилки. Крім того, уникайте конфліктів зі стандартними кодами помилок, визначеними платформою TON або базовою системою. Наприклад, код помилки 333 вказує на невідповідність ідентифікатора ланцюга. Бажано використовувати коди помилок від 400 до 1000, щоб запобігти таким конфліктам.

(7) Зберігання даних та викликповернути()Після завершення операції

У смарт-контрактах TON обробка повідомлень передбачає вибір іншої логіки на основі коду операції. Після виконання відповідної логіки необхідно виконати два додаткових кроки: Спочатку, якщо дані були змінені, викличте save_data() для забезпечення збереження змін; В іншому випадку зміни будуть неефективними. По-друге, зателефонуйте повернути()щоб показати, що операція завершена; в іншому випадку,throw(0xffff)виняток буде викликано.

() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {

int flags = cs~load_uint(4);

if (flags & 1) {

;; ігноруйте всі повернуті повідомлення

return ();

}

slice sender_address = cs~load_msg_addr();

load_data();

int op = in_msg_body~load_op();

if ((op == op::op_1())) {

handle_op1();

save_data();

повернути ();

}

якщо ((op == op::op_2())) {

handle_op2();

save_data();

return ();

}

if ((op == op::op_3())) {

виконати_операцію3();

save_data();

повернення ();

}

throw(0xffff);

}

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

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

Beosin має численні успішні кейси в екосистемі TON. Раніше Beosin провів ретельні аудити безпеки для провідного децентралізованого проєкту стейблкоїнів Aqua Protocol та DeFi-інфраструктури ONTON Finance. Аудит охопив безліч аспектів, включаючи безпеку коду смарт-контрактів, правильність реалізації бізнес-логіки, газову оптимізацію коду контракту, а також виявлення та усунення потенційних вразливостей.

Заява:

1. Цю статтю відтворено з [Beosin], оригінальний заголовок «Beosin Hard Core Дослідження | Від ризиків до захисту: безпекові ризики та рекомендації щодо оптимізації смарт-контрактів TON », авторське право належить оригінальному автору [Beosin], якщо у вас є будь-які зауваження щодо перепублікації, будь ласка, зв'яжіться Команда Gate LearnКоманда якнайшвидше вирішить це відповідно до відповідних процедур.

2. Увага: Погляди та думки, висловлені в цій статті, представляють лише особисті погляди автора й не є жодними інвестиційними порадами.

3. Інші мовні версії статті перекладені командою Gate Learn і не згадуються в Gate.io, перекладена стаття не може бути відтворена, розповсюджена або плагіатична.