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

По итогам аудита могут возникнуть два серьёзных вопроса: «Почему мы ничего не успели?» и «Почему мы ничего не нашли?». И самая страшная ситуация, когда оба эти вопроса возникают одновременно. Опишем это одним ёмким словом: «Провал».

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

Привет, Хабр!

Я Ирина Слонкина из отдела безопасности распределенных систем, Positive Technologies. Вместе с коллегами исследую безопасность смарт-контрактов и блокчейн-приложений. Конечно, всегда интересно вникнуть вглубь каждой технологии, вышедшей на рынок. В этой статье я расскажу про криптографический протокол PLONK, один из самых интересных протоколов в блокчейн-индустрии.

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

Привет! Мы в Positive Technologies активно исследуем безопасность AI-агентов и подходы offensive AI security. Мир стремительно движется к повсеместному использованию LLM-агентов, автономных агентов и интеграций через MCP/Toolcalls — а значит, растет и пространство атак. Эта статья содержит разбор реальных примеров уязвимостей и атак на LLM-агенты, вдохновленный конкурсом Agent Breaker от Lakera, а также наш опыт построения собственного мультимодального фреймворка для red teaming.

Всем привет! На связи Сергей Соболев, специалист по безопасности распределенных систем в Positive Technologies, наша команда занимается аудитом смарт-контрактов. Сегодня я расскажу вам о результатах исследований и выводах нашей команды насчет аудита безопасности смарт-контрактов на языках FunC и Tact платформы TON.

Добрый день! Меня зовут Кирилл Зиборов, я представляю отдел безопасности распределенных систем Positive Technologies. В этой статье мы продолжим обсуждать методы и инструменты формальной верификации смарт-контрактов и их практическое применение для предотвращения уязвимостей. Мы подробно поговорим о методе дедуктивной верификации, а точнее, о фреймворке для тестирования и верификации смарт-контрактов — ConCert.

Друзья, приветствую! Меня зовут Сергей Соболев, я представляю отдел безопасности распределенных систем Positive Technologies. В этой статье начну рассказывать про методы и инструменты формальной верификации, их практическое применение в аудите смарт-контрактов, а также про подводные камни.

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

В этой статье я расскажу как с помощью микроконтроллера ESP8266 подключиться к приватной Ethereum сети и вызвать смарт-контракт.

Данная статья поможет всем интересующимся лучше узнать про технические особенности платформ: Cosmos, Polkadot, Avalanche.

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

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

Введение

1. В то время как Move является языком байт-кода, который может напрямую выполняться на виртуальной машине Move, Solidity (язык смарт-контрактов в Ethereum) — язык более высокого уровня, который сначала компилируется в байт-код перед выполнением в EVM (Ethereum Virtual Machine).
2. Move можно использовать не только для реализации смарт-контрактов, но и для пользовательских транзакций (подробнее об этом будет дальше), в то время как Solidity — это язык только для смарт-контрактов.

“Библиотеки можно рассматривать, как неявные базовые смарт-контракты для смарт-контрактов, которые их используют” из документации языка Solidity

Библиотека в Solidity - это тип смарт-контракта, содержащий многократно используемый код. После развертывания в блокчейне (развёртывается только один раз) ему присваивается определённый адрес, а его свойства / методы могут многократно использоваться другими смарт-контрактами в сети Ethereum.

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

Мы продолжаем создавать клон Uniswap V1!

Наша реализация почти готова: мы реализовали все основные механики смарт-контракта Биржи, включая функции ценообразования, обмена, выпуска LP-токенов и сбора комиссии. Похоже, что наш клон завершен, однако нам не хватает смарт-контракта Фабрики.

Сегодня мы реализуем его и наш клон Uniswap V1 будет завершен.

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

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

В документации Solidity модификаторы определяются следующим образом:

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

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

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

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

Лучший способ научиться чему-то - научить других. Второй лучший способ научиться чему-то - сделать это самому. Я решил объединить эти два способа и научить себя и вас программировать DeFi сервисы на Ethereum (и любых других блокчейнах, основанных на EVM - Ethereum Virtual Machine).

Мы сосредоточимся на том, как работают эти сервисы, попытаемся понять экономическую механику, которая делает их такими, какие они есть (а все они основаны на экономической механике). Мы будем выяснять, разбирать, изучать и создавать основные механизмы DeFi.

Давайте начнем наше путешествие с Uniswap!

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

Сегодня мы собираемся закончить реализацию Uniswap V1. Хотя это не будет полная копия Uniswap V1, но она будет иметь все основные функции.

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

Продолжаем серию статей про язык Solidity и платформу Ethereum. В этой статье будет рассказываться про адреса в Ethereum. Статья была написана в августе 2019 года, с той порой язык изменился, поэтому несоответствия в описании автора были исправлены.

Во введении проведено сравнение Ethereum адресов с почтовыми адресами в реальном мире.

Техническая часть начинается с раздела "Что такое (технически) адрес в Ethereum?"