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

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

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

Анализ асинхронных функций и механизма учетной записи TON

Асинхронные вызовы в смарт-контрактах

Сегментация сети и асинхронное взаимодействие

Блокчейн TON разработан с тремя типами цепочек: Masterchain, Workingchains и Shardchains.

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

В теории каждый аккаунт может эксклюзивно занимать Shardchain, при этом каждый аккаунт независимо поддерживает свой баланс монет/токенов. Транзакции между аккаунтами могут быть полностью параллельными. Аккаунты общаются через асинхронные сообщения, и путь для сообщений между Shardchains составляет log_16(N) - 1, где N - количество Shardchains.

Image source: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574В мире web3 в Ton взаимодействие осуществляется путем отправки и получения сообщений. Эти сообщения могут быть внутренними (как правило, отправляемыми смарт-контрактами, взаимодействующими друг с другом) или внешними (отправляемыми внешними источниками). Процесс передачи сообщений не требует немедленных ответов от целевого контракта, что позволяет отправителю продолжать выполнение оставшейся логики. Этот асинхронный механизм передачи сообщений предлагает большую гибкость и масштабируемость по сравнению с синхронными вызовами Ethereum, снижая узкие места производительности, вызванные ожиданием ответов, а также вводя вызовы в обработке параллельности и гонок.

Формат и структура сообщения

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

Очередь сообщений и обработка статуса

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

Преимущества асинхронной передачи сообщений

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

•Снижение потребления ресурсов: Асинхронные сообщения не требуют немедленных ответов, что позволяет контрактам TON выполняться на протяжении нескольких блоков и избегать чрезмерного потребления ресурсов в рамках одного блока. Это позволяет TON поддерживать более сложные и ресурсоемкие смарт-контракты.

•Отказоустойчивость и надёжность: Механизм асинхронной передачи сообщений повышает отказоустойчивость системы. Например, если контракт не может своевременно ответить на сообщение из-за ограничений ресурсов или других причин, отправитель может продолжать обработку другой логики, предотвращая остановку системы из-за задержек в одном контракте.

Проблемы проектирования асинхронных контрактов

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

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

•Обеспечение безопасности: Асинхронные контракты подвержены рискам, таким как атаки типа человек-посередине или повторные атаки при обработке межконтрактных коммуникаций. Поэтому при проектировании асинхронных контрактов важно учитывать эти потенциальные угрозы безопасности и принимать предупредительные меры, такие как использование временных меток, случайных чисел или подходов с многофакторной авторизацией.

Модель реестра

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

Абстракция учетной записи

Модель учетной записи TON использует абстракцию на основе контракта, где каждая учетная запись может быть рассмотрена как контракт. Это в некоторой степени похоже на модель абстракции учетной записи Ethereum, но более гибкое и общее. В TON учетные записи не являются просто контейнерами для активов; они также включают код контракта и данные состояния. Каждая учетная запись включает свой код, данные и логику обработки сообщений.

Структура учетной записи: Каждая учетная запись TON имеет уникальный адрес, который генерируется из комбинации хэш-значения кода учетной записи, начальных данных при развертывании и других параметров. Это означает, что один и тот же код и начальные данные, развернутые в различных средах (например, различных блокчейнах или фрагментах), могут порождать разные адреса.

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

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

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

Хранилище состояний

Информация о состоянии учетной записи хранится в постоянном хранилище и организована с помощью дерева Меркля для обеспечения целостности и безопасности. Этот дизайн также поддерживает эффективный запрос и проверку состояний, особенно в транзакциях между чередами.

Состояние учетной записи или смарт-контракта обычно включает следующее:

1. Баланс базовой валюты 2. Баланс других валют 3. Код смарт-контракта (или его хэш) 4. Постоянные данные смарт-контракта (или его хэш Меркля) 5. Статистика по количеству постоянных блоков хранения и использованию сырых байтов 6. Последняя отметка времени платежей в постоянное хранилище смарт-контракта (фактически номер блока главной цепи) 7. Публичный ключ, необходимый для перевода валюты и отправки сообщений с этого счета (необязательно; по умолчанию он равен самому account_id). В некоторых случаях здесь могут быть найдены более сложные коды проверки подписи, аналогичные выходам из транзакций Bitcoin; в таких случаях account_id будет хэшем этого кода.

Не всю информацию необходимо для каждого аккаунта. Например, код смарт-контракта имеет значение только для смарт-контрактов, а не для "простых" аккаунтов. Кроме того, в то время как у каждого аккаунта должен быть ненулевой баланс базовой валюты (например, тон для базовой рабочей цепи и цепей шард), балансы других валют могут быть нулевыми. Чтобы избежать сохранения неиспользуемых данных, во время создания рабочей цепи определяется тип суммарно-произведенной структуры, используя различные маркировочные байты для различения различных "функций конструктора". В конечном итоге, состояние аккаунта сохраняется как коллекция блоков в постоянном хранилище TVM.

Передача сообщений и обработка

Структура реестра TON включает в себя встроенную поддержку асинхронной передачи сообщений. Каждый аккаунт может независимо обрабатывать полученные сообщения и обновлять свое состояние. Этот механизм асинхронного обмена сообщениями позволяет осуществлять сложные взаимодействия между аккаунтами, не влияя на нормальную работу других аккаунтов из-за задержек в какой-либо одной операции.

Модель газа

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

Модель газа 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) Исключения, вызванные несовпадением хранилища и типов данных

В основном это касается сопоставления intиuintтипы хранения. Например, в следующем коде, store_int()функция используется для храненияint Значение -42, но load_uint() используется для загрузки этого значения, что может привести к исключению.

(4) Надлежащее использование inline_refиinline Модификаторы

Во-первых, важно различать встроенныйиinline_ref Модификаторы:

встроенный: Функции с встроенный Код модификатора вставляется непосредственно в место вызова при каждом вызове. Это означает, что фактический код функции копируется в место вызова, а не выполняется через переход функции, что снижает накладные расходы на вызов функции, но может привести к дублированию кода.

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

В заключение, используйте встроенныйдля простых функций с целью снижения накладных расходов на вызовы, но будьте осторожны с возможным дублированием кода. Используйтеinline_refдля более крупных или часто вызываемых функций с целью улучшения эффективности и избежания повторения кода.

(5) Определение правильной рабочей цепочки

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

(6) Избегание конфликтов кодов ошибок

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

(7) Хранение данных и вызовыreturn() После завершения операции

В смарт-контрактах TON обработка сообщений включает выбор различной логики на основе оп-кода. После завершения соответствующей логики требуется выполнить два дополнительных шага: Во-первых, если данные были изменены, вызовитеsave_data()чтобы гарантировать, что изменения сохраняются; в противном случае изменения будут бессмысленными. Во-вторых, вызовите return()для указания того, что операция завершена; в противном случае,бросок(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 (флаги & 1) {

;; ignore all bounced messages

return ();

}

slice sender_address = cs~load_msg_addr();

загрузить_данные();

int op = in_msg_body~load_op();

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

handle_op1();

save_data();

return ();

}

if ((op == op::op_2())) {

handle_op2();

save_data();

возврат ();

}

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

handle_op3();

save_data();

return ();

}

throw(0xffff);

}

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

Экосистема TON в настоящее время находится в стадии быстрого роста, привлекая значительные средства и активных пользователей. Однако сопутствующие проблемы безопасности нельзя игнорировать. Для обеспечения безопасности и надежности экосистемы TON Beosin предоставляет комплексные и профессиональные проверки безопасности, адаптированные к характеристикам вызовов и операций смарт-контрактов TON, поддерживая развитие экосистемы.

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

Заявление:

1. Эта статья воспроизведена с [ Beosin], оригинальное название «Beosin Hard Core Research | From Risk to Protection: Security Risks and Optimization Suggestions of TON Smart Contracts》, авторские права принадлежат оригинальному автору [Беосин ], если у вас есть какие-либо возражения против перепечатки, пожалуйста, свяжитесь с нами Команда Gate Learn, команда обработает его как можно скорее в соответствии с соответствующими процедурами.

2. Дисклеймер: Взгляды и мнения, выраженные в этой статье, представляют собой только личные взгляды автора и не являются какими-либо инвестиционными рекомендациями.

3. Другие языковые версии статьи переводятся командой Gate Learn и не упоминаются вGate.io, переведенная статья не может быть воспроизведена, распространена или скопирована.