Solidity

Что такое Solidity?

Solidity — это высокоуровневый язык программирования, используемый для написания смарт-контрактов, работающих в Ethereum и других блокчейн-сетях, поддерживающих виртуальную машину Ethereum.

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

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

Официальная документация Ethereum по смарт-контрактам объясняет, что смарт-контракт — это программа, работающая в блокчейне Ethereum.

В криптоиндустрии Solidity используется для создания токенов, DeFi-протоколов, NFT-коллекций, DAO, систем стейкинга, рынков кредитования, мостов, эскроу-систем, контрактов управления и многих других ончейн-приложений.

Код Solidity не выполняется напрямую пользователями.

Разработчики пишут исходный код на Solidity, а затем компилируют его в байткод, который может выполнять виртуальная машина Ethereum.

Официальная документация Solidity объясняет, что Solidity — это объектно-ориентированный высокоуровневый язык для реализации смарт-контрактов.

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

Почему Solidity важен для криптоиндустрии

Solidity важен, поскольку на нем работают многие смарт-контракты, с которыми пользователи взаимодействуют в криптоэкосистеме.

Когда пользователь обменивает токены, минтит NFT, участвует в голосовании DAO, вносит залог, получает вознаграждения или взаимодействует с DeFi-приложением, часть этого действия может обрабатывать смарт-контракт Solidity.

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

Токены, включая взаимозаменяемые активы и NFT, часто зависят от стандартов смарт-контрактов, которые обычно реализуются на Solidity.

Официальный стандарт токенов ERC-20 определяет общий интерфейс для взаимозаменяемых токенов в смарт-контрактах.

Официальный стандарт токенов ERC-721 определяет общий интерфейс для невзаимозаменяемых токенов.

Официальный стандарт токенов ERC-1155 определяет стандарт мультитокенов, который может поддерживать взаимозаменяемые и невзаимозаменяемые активы в одной системе контрактов.

Эти стандарты важны, поскольку кошельки, обозреватели блокчейна, приложения и протоколы могут проще поддерживать единообразное поведение токенов.

Solidity также важен потому, что ошибки в смарт-контрактах могут затрагивать реальные средства пользователей.

Небольшая ошибка в коде Solidity может привести к потере токенов, нарушению разрешений, некорректному учету, неудачным обновлениям или уязвимой логике DeFi.

Как работает Solidity

Solidity позволяет разработчикам описывать правила смарт-контрактов в понятном человеку исходном коде.

Затем код компилируется в байткод EVM с помощью компилятора Solidity, обычно называемого solc.

Официальная документация по компилятору Solidity объясняет, что компилятор может генерировать такие результаты, как бинарные файлы, данные ABI, ассемблерный код, оценки газа и абстрактные синтаксические деревья.

После компиляции байткод развертывания отправляется в транзакции блокчейна для создания аккаунта контракта.

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

Пользователи обычно не вызывают смарт-контракты, записывая необработанный байткод.

Как правило, они взаимодействуют через кошельки, приложения, скрипты или интерфейсы, которые кодируют вызовы функций с помощью ABI контракта.

Контракт получает данные транзакции, выполняется в соответствии с правилами EVM, обновляет хранилище при наличии разрешения, генерирует события, если это предусмотрено кодом, и возвращает данные или ошибки.

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

Поэтому при разработке на Solidity необходимо учитывать как корректность, так и стоимость газа.

Solidity и виртуальная машина Ethereum

Виртуальная машина Ethereum, или EVM, — это среда выполнения, которая исполняет скомпилированный байткод смарт-контрактов.

Официальное введение Solidity в смарт-контракты объясняет, что EVM является средой выполнения смарт-контрактов Ethereum и изолирована от окружающей системы.

Solidity предназначен для EVM, то есть код Solidity компилируется в инструкции, понятные EVM.

Такая архитектура позволяет смарт-контрактам выполняться детерминированно на множестве узлов.

Детерминированное выполнение означает, что каждый честный узел должен получить одинаковый результат при обработке одной и той же транзакции при одинаковом состоянии сети.

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

EVM также создает изолированную среду, ограничивающую возможности контрактов.

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

Это ограничение повышает детерминированность, но требует от разработчиков тщательно проектировать работу с внешними данными.

Таким образом, Solidity — не просто обычный язык веб-программирования, поскольку он работает внутри блокчейн-модели исполнения со строгими правилами.

Solidity и смарт-контракты

Смарт-контракт Solidity — это набор кода и хранилища, который после развертывания находится по адресу в блокчейне.

Код определяет, какие функции можно вызвать и что эти функции делают.

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

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

Контракт также может вызывать другие контракты, создавая компонуемые ончейн-системы.

Компонуемость — одна из важнейших криптовалютных особенностей Solidity, поскольку один протокол может использовать интерфейс контрактов другого протокола.

Контракт токена может использоваться протоколом кредитования, протоколом обмена, контрактом стейкинга и системой управления.

Это делает Solidity мощным инструментом, но также создает риск: ошибка одного контракта способна затронуть множество связанных приложений.

После верификации смарт-контракты обычно прозрачны, однако прозрачность не означает безопасность автоматически.

Пользователям следует рассматривать каждое взаимодействие с контрактом как транзакцию, связанную с техническими и финансовыми рисками.

Синтаксис Solidity

В Solidity используются фигурные скобки, объявления функций, переменные, типы, структуры, маппинги, события, модификаторы и шаблоны наследования, которые могут быть знакомы разработчикам, знающим JavaScript, C++, Java или схожие языки.

Официальная документация Solidity указывает, что язык испытал влияние C++, Python и JavaScript.

Файл Solidity обычно начинается с идентификатора лицензии и директивы pragma.

Директива pragma указывает инструментам, какие версии компилятора предназначены для исходного файла.

Определение контракта затем включает переменные состояния, события, ошибки, конструкторы, функции, модификаторы и иногда вложенные типы.

Solidity — статически типизированный язык, то есть переменные и параметры функций имеют объявленные типы.

К распространенным типам относятся bool, uint256, int256, address, bytes, string, массивы, структуры, перечисления и маппинги.

Разработчикам необходимо тщательно учитывать хранилище, память, calldata, видимость, изменяемость и контроль доступа.

Эти детали важны, поскольку код Solidity управляет активами и после развертывания его может быть сложно изменить.

Даже простой на вид синтаксис может приводить к сложному ончейн-поведению.

Контракты

Контракт — основной строительный блок Solidity.

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

Контракт токена может хранить балансы и разрешения.

Контракт кредитования может хранить залог, долг, индексы процентов и настройки ликвидации.

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

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

Каждый развернутый контракт получает собственный адрес в блокчейне.

Пользователи обращаются к этому адресу для взаимодействия с функциями контракта.

Код контракта запускается, только когда его активирует транзакция или вызов.

Контракт не работает непрерывно, как обычное серверное приложение.

Переменные состояния

Переменные состояния — это переменные, постоянно хранящиеся в хранилище контракта.

Они используются для данных, которые должны оставаться доступными между транзакциями.

Примеры включают балансы токенов, адреса владельцев, общее предложение, настройки комиссий, резервы протокола, количество голосов и позиции пользователей.

Хранилище обходится дорого, поскольку узлы блокчейна должны хранить и проверять эти данные.

Разработчикам следует избегать хранения в блокчейне ненужных данных.

Они также должны тщательно проектировать структуру хранилища, особенно в обновляемых контрактах.

Ошибка в структуре хранилища может повредить важное состояние контракта при обновлении.

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

Пользователи редко видят переменные состояния напрямую, если только контракт не верифицирован или обозреватель блокчейна не предоставляет читаемые вызовы.

Однако именно эти переменные часто определяют, как обрабатываются средства и разрешения пользователей.

Функции

Функции определяют действия, которые может выполнять контракт Solidity.

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

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

К распространенным ключевым словам видимости относятся public, external, internal и private.

Изменяемость функции указывает, читает ли она состояние или изменяет его.

К распространенным ключевым словам изменяемости относятся view, pure и payable.

Функция view может читать состояние, не изменяя его.

Функция pure не должна читать или изменять состояние контракта.

Функция payable может получать нативный актив сети при вызове с указанием value.

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

События

События — это логи, генерируемые контрактами Solidity во время выполнения.

Они помогают кошелькам, обозревателям, индексаторам и приложениям отслеживать произошедшее в транзакции.

Перевод токенов обычно генерирует событие Transfer, если оно реализовано в соответствии с распространенными стандартами токенов.

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

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

Однако события — не то же самое, что состояние контракта.

Контракт может сгенерировать событие, только если его код предписывает это сделать.

Приложениям не следует слепо доверять логам событий без понимания логики контракта.

События отлично подходят для прозрачности и аналитики, но интерпретировать их нужно с учетом базового кода.

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

Модификаторы

Модификаторы — это повторно используемые элементы логики Solidity, которые могут изменять или ограничивать поведение функций.

Распространенный модификатор проверяет, является ли вызывающая сторона владельцем, администратором, участником управления или уполномоченной ролью, прежде чем разрешить выполнение функции.

Модификаторы могут сократить повторение кода и сделать контроль доступа более понятным.

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

Функция может выглядеть простой, в то время как модификатор в фоновом режиме выполняет существенные проверки или изменения состояния.

Разработчикам следует делать модификаторы понятными и целенаправленными.

Аудиторам следует внимательно проверять модификаторы, поскольку они часто защищают чувствительные функции.

Пользователям, изучающим верифицированный код, не следует оценивать функцию только по ее видимому телу.

Им также следует проверять унаследованные модификаторы и условия контроля доступа.

Отсутствующий или неисправный модификатор может создать серьезный риск безопасности.

Маппинги

Маппинг — это структура данных типа «ключ — значение», широко используемая в контрактах Solidity.

Балансы токенов часто хранятся в маппинге от адреса к сумме.

Разрешения могут храниться во вложенном маппинге от владельца к получателю разрешения и сумме.

Системы управления могут использовать маппинги для отслеживания того, голосовал ли адрес.

Системы кредитования могут использовать маппинги для отслеживания залога и долга каждого пользователя.

Маппинги эффективно находят значения по ключу.

Однако перебор маппингов напрямую в блокчейне затруднен.

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

Маппинги — мощный инструмент, но они требуют тщательного учета.

Неверное обновление маппинга может привести к неправильным балансам, нарушенным разрешениям или потере средств.

Интерфейсы

Интерфейс определяет сигнатуры функций, которые может вызывать другой контракт.

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

Интерфейс токена может сообщать DeFi-контракту, как вызывать transfer, transferFrom, approve, balanceOf или allowance.

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

Интерфейс управления может позволить другому контракту проверять состояние предложения или силу голоса.

Интерфейсы повышают компонуемость, поскольку контракты могут опираться на общие формы функций.

Однако интерфейс лишь описывает ожидаемые вызовы и возвращаемые значения.

Он не доказывает, что контракт за определенным адресом ведет себя честно или безопасно.

Разработчикам следует проверять предположения о внешних контрактах перед их интеграцией.

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

Библиотеки

Библиотеки — это повторно используемые модули кода Solidity, которые помогают разработчикам не переписывать распространенную логику.

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

Некоторые библиотеки встраиваются в байткод контракта во время компиляции.

Другие библиотеки могут развертываться отдельно и связываться по адресу.

Использование библиотеки может повысить качество кода, если библиотека хорошо протестирована и широко проверена.

Оно также может добавить риск, если библиотека устарела, вредоносна, неправильно связана или используется неверно.

Разработчикам следует фиксировать версии зависимостей и проверять импортируемый код.

Аудиторам следует изучать библиотеки как часть полной кодовой базы.

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

Контракт безопасен лишь настолько, насколько безопасен весь набор кода, влияющий на его поведение.

Наследование

Наследование позволяет контракту Solidity повторно использовать и расширять код других контрактов.

Это полезно для общей логики владения, поведения токенов, контроля доступа, механизмов паузы, шаблонов обновления и повторно используемых модулей.

При аккуратном использовании наследование может упростить организацию кода.

Оно также может усложнить проверку кода, если множество унаследованных контрактов взаимодействуют сложным образом.

Дочерний контракт может переопределять функцию родительского контракта.

Множественное наследование может создавать неочевидные проблемы порядка и переопределения.

Разработчикам следует по возможности сохранять простую структуру наследования.

Аудиторам следует проверять все дерево наследования, а не только конечный контракт.

Пользователям, читающим верифицированный код, следует проверять импортируемые родительские контракты, а не только название контракта, показанное на странице.

Наследование является мощным инструментом, но скрытая унаследованная логика может быть опасной, если ее игнорировать.

ABI

ABI означает Application Binary Interface.

Официальная спецификация ABI Solidity объясняет, что ABI — это стандартный способ взаимодействия с контрактами в экосистеме Ethereum.

ABI сообщает программному обеспечению, как кодировать вызовы функций и декодировать возвращаемые значения.

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

Без ABI пользователям пришлось бы работать с необработанными calldata, которые намного сложнее понять.

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

ABI не доказывает безопасность контракта.

Он лишь описывает, как вызывать открытый интерфейс контракта.

Вредоносный контракт все равно может иметь внешне понятный ABI.

Пользователям следует воспринимать данные ABI как слой удобства, а не гарантию доверия.

Компилятор Solidity

Компилятор Solidity, или solc, преобразует исходный код Solidity в байткод EVM и сопутствующие артефакты.

Solc также может генерировать данные ABI, метаданные, оценки газа, структуру хранилища, предупреждения, ошибки и промежуточные результаты.

Точная версия и настройки компилятора важны, поскольку они влияют на итоговый байткод.

Официальное объявление о выпуске Solidity 0.8.35 сообщает, что версия 0.8.35 представила встроенную функцию erc7201, экспериментальный флаг верхнего уровня и экспериментальный генератор кода SSA CFG.

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

Контракт, скомпилированный одной версией, может не соответствовать тому же исходному коду, скомпилированному другой версией.

Настройки компилятора, такие как состояние оптимизатора, число запусков оптимизатора, версия EVM, via-IR и адреса библиотек, также влияют на результат.

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

Разработчикам следует фиксировать версии компилятора для производственных развертываний.

Пользователям следует понимать, что верифицированный исходный код зависит от совпадения настроек компиляции, а не только от совпадения текста.

Байткод

Байткод — это низкоуровневый код, который EVM выполняет после компиляции и развертывания контракта Solidity.

Байткод развертывания используется для создания контракта.

Байткод времени выполнения — это код, который остается по адресу контракта после развертывания.

Блокчейны выполняют байткод, а не исходный текст Solidity.

Поэтому верификация исходного кода важна.

Верификация показывает, что видимый исходный код и настройки компилятора могут воспроизвести развернутый байткод.

Официальная документация Ethereum по верификации смарт-контрактов объясняет, что верификация сравнивает исходный код со скомпилированным байткодом.

Большинству пользователей сложно читать байткод напрямую.

Верифицированный исходный код делает байткод более понятным.

Однако даже верифицированный байткод требует проверки безопасности, прежде чем пользователи доверят контракту средства.

Газ

Газ — это единица измерения вычислительной работы, необходимой для выполнения транзакций и операций смарт-контрактов.

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

Запись в хранилище обычно стоит больше, чем чтение памяти или calldata.

Циклы по большим наборам данных могут стать опасными, если требуют слишком много газа.

Внешние вызовы могут увеличить стоимость и риск безопасности.

Развертывание контракта также требует газа, поскольку байткод необходимо хранить в блокчейне.

Оптимизатор Solidity иногда может снизить стоимость газа или размер байткода, но его необходимо тщательно настраивать и тестировать.

Оптимизация газа не должна достигаться за счет неясной или небезопасной логики.

В криптоиндустрии контракт, использование которого обходится слишком дорого, может не сработать для пользователей во время перегрузки сети.

Качественная разработка на Solidity балансирует между безопасностью, ясностью и эффективностью.

Solidity и токены

Solidity широко используется для создания и управления контрактами токенов.

Контракт взаимозаменяемого токена может отслеживать балансы, разрешения, общее предложение, переводы, одобрения, минтинг, сжигание и контроль доступа.

NFT-контракт может отслеживать уникальные ID токенов, владельцев, одобрения, ссылки на метаданные и правила перевода.

Мультитокен-контракт может управлять множеством типов токенов в рамках одной системы контрактов.

Стандарты токенов важны, поскольку упрощают поддержку токенов кошельками, обозревателями и приложениями.

Стандарты ERC-20, ERC-721 и ERC-1155 относятся к наиболее важным стандартам токенов прикладного уровня в экосистеме Ethereum.

Однако использование Solidity или соблюдение стандарта не делает токен безопасным или ценным.

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

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

Solidity делает создание токенов возможным, но качество токена зависит от его дизайна и управления.

Solidity и DeFi

Solidity лежит в основе многих приложений децентрализованных финансов (DeFi).

DeFi-контракты могут управлять свопами, пулами ликвидности, рынками кредитования, хранилищами, деривативами, стейкингом, стратегиями доходности и системами управления.

Такие системы часто хранят значительные объемы активов пользователей, поэтому безопасность Solidity крайне важна.

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

Solidity позволяет контрактам вызывать друг друга, что делает DeFi высококомпонуемым.

Компонуемость может создавать полезные финансовые строительные блоки.

Она также может создавать риск зависимостей, когда один протокол полагается на поведение другого.

Разработчикам следует тестировать интеграции в различных рыночных условиях и сценариях сбоев.

Пользователям следует понимать, что смарт-контракты DeFi могут быть одновременно прозрачными и рискованными.

Высокая доходность или большой объем не доказывают безопасность кода Solidity.

Solidity и NFT

Solidity часто используется для создания NFT-контрактов, определяющих правила владения и перевода уникальных цифровых активов.

NFT-смарт-контракт может назначать ID токенов, хранить записи о владении, управлять одобрениями и ссылаться на метаданные.

Метаданные NFT часто указывают на изображения, атрибуты, описания или внешние файлы.

Смарт-контракт может не хранить все медиафайлы непосредственно в блокчейне, поскольку хранение больших объемов данных в блокчейне может быть дорогостоящим.

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

Верифицированный NFT-контракт Solidity может показывать правила минтинга, лимиты предложения, механизм роялти, ограничения перевода и административные разрешения.

Однако многие риски NFT не ограничиваются рисками кода.

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

Solidity предоставляет логику владения, но не гарантирует культурную ценность или будущий спрос.

Покупателям NFT следует сочетать проверку контракта с верификацией коллекции и анализом ликвидности.

Solidity и DAO

Solidity часто используется для создания контрактов управления DAO.

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

Контракты управления могут позволять держателям токенов или участникам голосовать за изменения протокола.

Они также могут контролировать чувствительные действия, такие как обновления, переводы из казначейства, изменение параметров и экстренные паузы.

Контракты DAO требуют тщательного проектирования, поскольку атаки на управление могут затрагивать реальные активы.

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

Таймлоки могут дать пользователям время отреагировать до вступления одобренных изменений в силу.

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

Solidity предоставляет DAO программируемые инструменты управления, но безопасность управления зависит как от кода, так и от координации людей.

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

Риски безопасности Solidity

Безопасность Solidity — одна из важнейших тем в крипторазработке.

Официальная документация по соображениям безопасности Solidity охватывает такие риски, как повторный вход, лимиты газа, отправка и получение ether, tx.origin, незначительные детали и вопросы, связанные с компилятором.

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

Ошибки контроля доступа могут позволить неавторизованным пользователям вызывать чувствительные функции.

Ошибки в целочисленных операциях и учете могут создавать неверные балансы или нарушенную логику комиссий.

Ошибки оракулов могут привести к неверным ценам и несправедливым ликвидациям.

Ошибки обновления могут заменить безопасную логику небезопасной.

Непроверенные внешние вызовы могут создавать неожиданные пути выполнения.

Ошибки проверки подписей могут допускать атаки повторного воспроизведения или поддельные одобрения.

Безопасность смарт-контрактов требует моделирования угроз, тестирования, проверок, аудитов, мониторинга и консервативного проектирования.

Повторный вход

Повторный вход — это известная уязвимость смарт-контрактов, при которой внешний вызов позволяет другому контракту выполнить обратный вызов до того, как первый контракт завершит обновление своего состояния.

Это может позволить повторные выводы средств, нарушить учет или создать неожиданный поток управления.

Документация Solidity по безопасности рекомендует шаблон Checks-Effects-Interactions как один из способов снижения риска повторного входа.

Согласно этому шаблону, контракт должен сначала проверить условия, затем обновить внутреннее состояние и только после этого взаимодействовать с внешними контрактами.

Защита от повторного входа также может включать блокировки, модели pull-payment и тщательную проверку внешних вызовов.

Разработчикам не следует считать отправку активов безвредной операцией.

Внешние вызовы могут выполнять код и изменять поток управления.

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

Повторный вход — не единственный риск Solidity, но это один из важнейших примеров того, почему логика смарт-контрактов отличается от обычного ПО.

Безопасный на вид перевод может стать опасным, если обновления состояния происходят в неправильном порядке.

Контроль доступа

Контроль доступа определяет, кто может вызывать чувствительные функции Solidity.

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

Контроль доступа может основываться на адресе владельца, ролях, мультисиг-кошельках, контрактах управления, таймлоках или пользовательских системах разрешений.

Слабый контроль доступа может позволить злоумышленникам или инсайдерам изменить поведение контракта.

Чрезмерно централизованный контроль доступа также может создавать риск доверия для пользователей.

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

Разработчикам следует проектировать разрешения с соблюдением принципа наименьших привилегий, четким разделением ролей и планами восстановления.

Пользователям следует проверять полномочия администраторов перед внесением средств в протокол.

Верифицированный код Solidity может раскрывать логику разрешений, если исходный код доступен.

Риск администратора является риском смарт-контракта даже при отсутствии ошибки в коде.

Безопасность целочисленных операций

Целочисленные операции важны в Solidity, поскольку контракты часто обрабатывают балансы, доли, цены, комиссии, проценты и вознаграждения.

Более старые версии Solidity требовали более тщательной ручной работы с переполнением и потерей значимости целых чисел.

Solidity 0.8.x ввел проверяемую арифметику по умолчанию, которая отменяет выполнение при большинстве условий переполнения и потери значимости, если не используются блоки unchecked.

Это повышение безопасности не устраняет все математические риски.

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

Блоки unchecked могут повысить эффективность использования газа в отдельных случаях, но применять их нужно осторожно.

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

Аудиторам следует проверять математические предположения и граничные случаи.

Пользователям следует понимать, что безопасная арифметика не означает автоматически безопасную экономическую модель.

Корректные формулы не менее важны, чем защита от переполнения.

Оракулы и внешние данные

Контракты Solidity не могут самостоятельно напрямую получать доступ к офчейн-данным.

Официальная документация Ethereum по оракулам объясняет, что оракулы передают смарт-контрактам данные из внешнего мира.

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

В DeFi ценовые оракулы особенно важны, поскольку они могут определять стоимость залога, ликвидации, минтинг, погашение и расчеты.

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

Разработчикам следует избегать зависимости от легко манипулируемых спотовых цен на неликвидных рынках.

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

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

Solidity может обеспечивать соблюдение правил на основе оракулов, но не может сделать плохие данные хорошими.

Внешние данные — одно из важнейших допущений доверия во многих системах смарт-контрактов.

Обновляемость

Контракты Solidity часто описывают как неизменяемые, однако многие проекты используют шаблоны обновления для изменения логики после развертывания.

Обновляемые контракты обычно разделяют прокси-контракт и контракт реализации.

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

Обновляемость может исправлять ошибки и добавлять функции.

Она также может создавать риск доверия, поскольку администраторы или управление могут изменить правила после внесения пользователями средств.

Структуру хранилища необходимо обрабатывать тщательно, поскольку некорректные обновления могут повредить состояние.

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

Разработчикам следует четко документировать полномочия по обновлению.

Аудиторам следует проверять как текущую реализацию, так и механизмы контроля обновлений.

Обновляемость полезна, но она меняет модель доверия контрактов Solidity.

Верификация исходного кода

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

Документация Ethereum по верификации объясняет, что верификация сравнивает исходный код контракта со скомпилированным байткодом, использованным при создании контракта.

Для верификации обычно требуются точные исходные файлы, версия компилятора, настройки компилятора, аргументы конструктора, адреса библиотек и конфигурация метаданных.

Верифицированный исходный код повышает прозрачность, поскольку пользователи могут прочитать логику контракта.

Он также помогает кошелькам и обозревателям декодировать вызовы функций и события.

Однако верификация исходного кода — не то же самое, что аудит.

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

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

Пользователям следует проявлять осторожность, если сайт запрашивает одобрения или внесение средств в невeрифицированный контракт.

Верификация — это начало комплексной проверки, а не ее завершение.

Версии Solidity

Версии Solidity важны, поскольку язык со временем меняется.

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

Официальные объявления о выпусках Solidity публикуют сведения о релизах компилятора и изменениях языка.

Согласно официальной информации о релизах, доступной в 2026 году, Solidity 0.8.35 — это недавний выпуск компилятора с новой функциональностью и экспериментальными функциями компилятора.

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

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

Разработчикам следует читать примечания к выпуску перед изменением версии компилятора.

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

Пользователям, изучающим верифицированные контракты, следует проверять версию компилятора, указанную в обозревателе.

Выбор версии Solidity — часть безопасности и воспроизводимости смарт-контрактов.

Ошибки компилятора Solidity

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

Официальная документация Solidity по известным ошибкам отслеживает известные ошибки компилятора и версии, которых они касаются.

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

Разработчикам следует проверять известные ошибки компилятора перед развертыванием производственных контрактов.

Аудиторам следует включать проверку версии компилятора в свой процесс.

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

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

Командам смарт-контрактов следует рассматривать компилятор как часть доверенной цепочки поставки программного обеспечения.

Воспроизводимые сборки и зафиксированные настройки компилятора помогают определить, может ли применяться известная ошибка.

Риск компилятора — еще одна причина, по которой необходимо сохранять артефакты развертывания.

Инструменты разработки Solidity

Разработчики Solidity обычно используют инструменты для написания, компиляции, тестирования, развертывания, верификации и мониторинга контрактов.

Официальная Remix IDE — это браузерная среда, часто используемая для обучения, написания, компиляции и тестирования контрактов Solidity.

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

Инструменты статического анализа могут сканировать код Solidity на распространенные уязвимости и рискованные шаблоны.

Инструменты фазз-тестирования могут генерировать множество входных данных для выявления неожиданного поведения.

Инструменты формальной верификации могут доказывать отдельные свойства при заданных предположениях.

Ни один отдельный инструмент не может гарантировать безопасность.

Профессиональная разработка Solidity обычно объединяет модульные тесты, интеграционные тесты, фазз-тесты, ревью кода, аудиты, скрипты развертывания, мониторинг и планирование реагирования на инциденты.

Новичкам следует начинать с небольших контрактов и тестовых сетей, прежде чем работать с реальными средствами.

Продвинутым командам следует использовать воспроизводимые пайплайны сборки и строгий контроль релизов.

Тестирование контрактов Solidity

Тестирование необходимо, поскольку развернутые смарт-контракты могут управлять ценными активами.

Модульные тесты проверяют отдельные функции и ожидаемое поведение.

Интеграционные тесты проверяют, как несколько контрактов работают вместе.

Форк-тесты моделируют поведение контракта на основе реального состояния сети, скопированного в локальную среду.

Фазз-тесты используют множество случайных или структурированных входных данных для поиска граничных случаев.

Инвариантные тесты проверяют, что важные правила остаются верными при множестве действий.

Тестирование должно включать обычные сценарии, сценарии сбоев, проверки разрешений, граничные случаи и сценарии действий злоумышленника.

Разработчикам следует тестировать реалистичные десятичные разряды токенов, необычное поведение токенов, большие и нулевые значения, а также граничные условия.

Тестирование не может доказать безопасность каждого возможного поведения, но значительно снижает число предотвратимых ошибок.

Непротестированному коду Solidity не следует доверять значительные средства.

Аудиты

Аудит смарт-контракта — это проверка безопасности специалистами, которые изучают код Solidity, архитектуру, разрешения, тесты и предположения о рисках.

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

Аудит не гарантирует безопасность контракта.

Это процесс снижения риска, а не идеальный щит.

Качество аудита зависит от его объема, времени, навыков аудитора, покрытия тестами, документации и того, как команда исправляет выявленные проблемы.

Пользователям следует изучать, были ли результаты аудита устранены или приняты.

Им также следует проверять, соответствует ли развернутый контракт проверенному коммиту и настройкам компилятора.

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

Аудиты наиболее полезны в сочетании с публичной верификацией, программами поиска ошибок, мониторингом и консервативными лимитами запуска.

Контракты Solidity, управляющие крупными объемами ценности, следует серьезно проверять перед развертыванием в основной сети.

Solidity и взаимодействие с кошельками

Кошельки помогают пользователям подписывать транзакции, вызывающие контракты Solidity.

Кошелек может отображать адрес контракта, имя функции, параметры, одобрения активов, комиссию за газ и предупреждения.

Кошелек не всегда может определить, безопасен ли контракт.

Некоторые вредоносные сайты могут просить пользователей подписать опасные транзакции, которые используют реальные функции Solidity вредоносным образом.

Одобрения токенов особенно важны, поскольку одобрение может разрешить контракту расходовать токены из кошелька в пределах определенной суммы.

Пользователям следует проверять суммы одобрений и адреса контрактов перед подписанием.

Им следует избегать подписания транзакций, которые они не понимают.

Им следует быть осторожными, если интерфейс скрывает calldata или запрашивает неограниченные одобрения.

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

Подпись транзакции может безвозвратно переместить средства или предоставить разрешения.

Solidity и одобрения токенов

Одобрения токенов — это распространенный шаблон Solidity, позволяющий одному адресу расходовать токены от имени другого адреса.

В токене в стиле ERC-20 функция approve устанавливает разрешение, а transferFrom использует это разрешение.

Такая конструкция делает возможными DeFi-свопы, депозиты, платежи и автоматизированные действия.

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

Неограниченные одобрения удобны, но увеличивают подверженность риску.

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

Им следует отзывать неиспользуемые одобрения с помощью надежных кошельков или инструментов безопасности.

Разработчикам следует проектировать интерфейсы, которые четко объясняют одобрения.

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

Одобрения — один из наиболее распространенных способов, которыми обычные пользователи сталкиваются с рисками Solidity.

Solidity и формальная верификация

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

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

Свойство может утверждать, что общее предложение никогда не превышает лимит или что пользователи не могут вывести больше собственного баланса.

Формальная верификация не устраняет необходимость в тестировании и аудитах.

Она доказывает только те свойства, которые действительно указаны.

Если спецификация неполна или неверна, доказательство может не охватить реальные риски.

Формальные методы могут быть дорогостоящими и требовать специализированных знаний.

Они наиболее эффективны при применении к критически важной логике с четкими правилами.

Для Solidity формальная верификация является частью зрелого процесса безопасности.

Она особенно полезна, когда сбой контракта может привести к крупным убыткам.

Преимущества Solidity

Первое преимущество Solidity — распространенность в экосистеме.

Многие инструменты для смарт-контрактов, руководства, аудиты, стандарты, библиотеки и сообщества разработчиков поддерживают Solidity.

Второе преимущество — совместимость с EVM.

Контракты Solidity могут быть ориентированы на Ethereum и другие среды с поддержкой EVM, если правила сети и настройки развертывания совместимы.

Третье преимущество — компонуемость.

Контракты Solidity могут вызывать другие контракты и использовать существующие стандарты токенов и интерфейсы протоколов.

Четвертое преимущество — выразительность.

Разработчики могут создавать токены, DeFi-системы, DAO, игры, NFT и автоматизированную финансовую логику.

Пятое преимущество — прозрачность, поскольку верифицированный исходный код Solidity могут читать и проверять пользователи и аудиторы.

Эти преимущества объясняют, почему Solidity остается одним из важнейших языков смарт-контрактов в криптоиндустрии.

Риски и ограничения Solidity

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

Второй риск заключается в том, что логика смарт-контракта может быть использована любым пользователем, обнаружившим слабое место.

Третий риск заключается в том, что контракты Solidity часто взаимодействуют с другими контрактами, создавая риск зависимостей.

Четвертый риск состоит в том, что стоимость газа может сделать некоторые конструкции непрактичными.

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

Шестой риск состоит в том, что верифицированный исходный код все еще может быть вредоносным или плохо спроектированным.

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

Восьмой риск заключается в том, что пользователи могут подписывать вредоносные транзакции, не понимая, что сделает контракт Solidity.

Девятый риск состоит в том, что проблемы с оракулами и экономическим дизайном могут нарушить работу протокола, даже если синтаксис корректен.

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

Распространенные ошибки в Solidity

Одна из распространенных ошибок — создание контроля доступа, который не защищает чувствительные функции.

Другая ошибка — выполнение внешних вызовов до безопасного обновления внутреннего состояния.

Третья ошибка — доверие tx.origin для авторизации, от которого предостерегает документация Solidity по безопасности.

Четвертая ошибка — игнорирование десятичных разрядов токенов и проблем точности в расчетах.

Пятая ошибка — предположение, что каждый токен в стиле ERC-20 ведет себя совершенно одинаково.

Шестая ошибка — использование обновляемых контрактов без сохранения структуры хранилища.

Седьмая ошибка — развертывание с настройками компилятора, отличающимися от проверенной сборки.

Восьмая ошибка — игнорирование предупреждений компилятора.

Девятая ошибка — предоставление одному ключу администратора слишком больших полномочий.

Десятая ошибка — запуск контрактов до тестирования граничных случаев и сценариев сбоев.

Как оценить контракт Solidity

Начните с проверки того, верифицирован ли исходный код контракта.

Затем проверьте версию компилятора, настройки оптимизатора, аргументы конструктора и связанные библиотеки.

Изучите, является ли контракт обновляемым и кто контролирует обновления.

Проверьте роли администраторов, разрешения владельца, мультисиг-контроль, таймлоки и экстренные функции.

При оценке контрактов токенов изучите минтинг, сжигание, паузу, черные списки, комиссии и ограничения переводов.

При оценке DeFi-контрактов изучите источники оракулов, правила залога, логику ликвидации и учет.

Проверьте наличие аудитов и устранены ли выявленные в ходе аудита проблемы.

Сравните адрес развернутого контракта с официальными источниками проекта.

Изучите последние транзакции и события, чтобы понять, как используется контракт.

Контракт Solidity следует оценивать комплексно: как код, инфраструктуру, систему управления и экономический дизайн.

Лучшие практики для разработчиков

Используйте недавнюю стабильную версию компилятора Solidity после ознакомления с примечаниями к выпуску и тестирования поведения.

Фиксируйте версии компилятора и зависимостей для производственных сборок.

Рассматривайте предупреждения компилятора как предмет для проверки, а не безобидный шум.

Используйте понятный контроль доступа и разрешения с наименьшими привилегиями.

Применяйте безопасные шаблоны внешних вызовов, такие как Checks-Effects-Interactions, когда это уместно.

Пишите тесты для обычных сценариев, сценариев сбоев, граничных случаев и поведения злоумышленников.

Используйте статический анализ, фазз-тестирование и аудиты для контрактов, управляющих значимой стоимостью.

Документируйте полномочия администраторов, полномочия по обновлению, предположения об оракулах и экстренные механизмы контроля.

Верифицируйте исходный код после развертывания, используя точные настройки компилятора.

Отслеживайте развернутые контракты и подготовьте планы реагирования на инциденты до запуска.

Лучшие практики для пользователей

Проверьте, верифицирован ли контракт, прежде чем взаимодействовать с ним.

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

Проверяйте одобрения токенов перед подписанием транзакций.

Будьте осторожны с неограниченными одобрениями и отзывайте неиспользуемые разрешения, когда это практично.

Проверьте, является ли контракт обновляемым и кто контролирует обновления.

Не считайте, что верифицированный контракт прошел аудит или безопасен.

Не вносите средства в контракты, которые вы не можете понять или которым не можете доверять самостоятельно.

Используйте аппаратные кошельки или надежную защиту кошелька для операций с высокой стоимостью.

Будьте осторожны с новыми, неаудированными, высокодоходными или анонимными контрактами Solidity.

Помните, что транзакция в блокчейне обычно необратима после подтверждения.

FAQ

Для чего используется Solidity?

Solidity используется для написания смарт-контрактов для Ethereum и других совместимых с EVM блокчейн-сред.

Solidity — это криптовалюта?

Нет, Solidity — это язык программирования, а не криптовалюта или токен.

Solidity предназначен только для Ethereum?

Solidity был разработан для Ethereum, но также используется в других блокчейн-сетях, поддерживающих виртуальную машину Ethereum или совместимые среды выполнения.

Что такое смарт-контракт Solidity?

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

Что такое компилятор Solidity?

Компилятор Solidity, называемый solc, преобразует исходный код Solidity в байткод EVM, данные ABI, метаданные и другие результаты сборки.

Что такое ABI в Solidity?

ABI — это Application Binary Interface, который сообщает кошелькам, приложениям и скриптам, как вызывать функции контракта и декодировать его ответы.

Безопасен ли Solidity?

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

Можно ли изменить контракты Solidity после развертывания?

Базовые развернутые контракты обычно неизменяемы, но обновляемые прокси-шаблоны могут позволять изменять логику контракта при наличии разрешений на обновление.

Почему контракты Solidity нуждаются в аудитах?

Контракты Solidity часто управляют ценными активами, поэтому аудиты помогают найти ошибки, проблемы разрешений, экономические недостатки и небезопасные предположения до или после развертывания.

Как пользователи могут проверить контракт Solidity?

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

Заключение

Solidity — один из важнейших языков программирования в криптоэкосистеме, поскольку он позволяет создавать смарт-контракты для токенов, DeFi, NFT, DAO, систем стейкинга и многих других ончейн-приложений.

Он позволяет разработчикам писать понятные человеку правила, которые компилируются в байткод EVM и выполняются узлами блокчейна.

Сильные стороны Solidity обусловлены его большой экосистемой, стандартами смарт-контрактов, компонуемостью, инструментами и широкой поддержкой EVM.

Его риск связан с тем, что развернутый код может управлять реальными активами и его может быть сложно исправить после развертывания.

Качественная разработка на Solidity требует тщательной настройки компилятора, тестирования, аудитов, контроля доступа, планирования обновлений, учета газа и проверки безопасности.

Грамотное использование Solidity требует от пользователей проверять адреса контрактов, изучать разрешения, управлять одобрениями, проверять аудиты и избегать неизвестных или невeрифицированных контрактов.

Новичкам лучше всего понимать Solidity как язык, который разработчики используют для написания блокчейн-программ.

Для продвинутых пользователей Solidity — это язык смарт-контрактов, безопасность которого зависит от качества кода, поведения EVM, конфигурации компилятора, внешних зависимостей, управления и экономического дизайна.

В контексте криптоглоссария Solidity означает основной высокоуровневый язык, используемый для создания и развертывания смарт-контрактов, выполняемых в блокчейн-средах типа Ethereum.

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