Solidity *

Если вы уже разобрались с классическими сообщениями LayerZero (push-модель: отправили сообщение из одной сети и получили в другой сети), следующий шаг — научиться читать состояние других сетей, не разворачивая там свои контракты и не гоняя туда-сюда два сообщения. Для этого в LayerZero v2 есть lzRead — это request–response (pull) паттерн: контракт в исходной сети отправляет запрос (lzSend), а ответ возвращается обратно в исходную сеть и обрабатывается в lzReceive.

Если вы пишете на Solidity больше полугода, вы наверняка уже сталкивались с прокси-контрактами. Если нет — сталкивались, просто не знали об этом: почти каждый серьёзный протокол на EVM использует какой-нибудь прокси-паттерн. Uniswap, Aave, OpenSea — все они. А в основе всех прокси лежит один опкод — DELEGATECALL.

Продолжаем погружаться в CoW DAO. В прошлый раз мы разобрали, как устроен CoW Protocol: intent-подход с подписями, роли Autopilot и solvers и общую идею пакетного исполнения. Во второй части углубимся в механику batch auctions — как протокол собирает аукционы, выбирает лучшее решение и доводит его до исполнения.

Привет!

На днях я потратил 3 дня на попытку мигрирвать свой проект с Hardhat v2.22.19 и Solidity v0.8.28 на Hardhat v3.1.6 и Solidity v0.8.33 (ради transient storage); затем понял, что мажор Hardhat менять не стоит и, если хочется обновиться, то можно обновить минор до v2.28.4; в итоге всех манипуляций пришел к стандартному выводу: "если работает - не трогай" (*сарказм).

Однако как бы не так...

Блокчейн разработка меняется со скоростью света. Решив вникнуть, купил несколько лет назад книгу, но к сегодняшнему дню она уже безнадежно устарела. Инструменты описанные в ней web3.js, Truffle, Ganache, заброшены, подходы и стандарты изменились.

В праздники, дописал и залил в сеть web3 демо-магазин на solidity/ethers.js. Поделюсь ньансами разработки и современными инструментами.

Значительная часть ликвидности в дексах простаивает и используется только для ценообразования. Новый протокол Aqua от команды 1inch пытается решить эту проблему, не создавая пулы ликвидности. Вместо пулов здесь виртуальные балансы, которые не требуют блокировки активов. Концепт shared liquidity позволяет использовать ликвидность сразу в нескольких торговых стратегиях.

Я постарался сделать подробный разбор Aqua Protocol для вас: как работает core-контракт, зачем нужен слой приложений и стратегий, как выглядит полный флоу обмена активами между мейкером и тейкером и какие ограничения у этой модели остаются на практике.

ERC-3643, также известный как T-REX, — это стандарт для выпуска permissioned токенов, представляющих регулируемые активы, но при этом сохраняющих ERC-20 совместимый интерфейс. В отличие от классических ERC-20, здесь любые операции с токеном проходят через обязательные проверки идентичности и compliance-правил прямо на уровне смарт-контрактов.

В этой статье я рассматриваю T-REX именно как протокол: из каких контрактов он состоит, как связаны Identity, Registry, ONCHAINID и Compliance, какие роли участвуют в системе и как выглядит полный флоу операций — от начала transfer до его окончательного выполнения. Также разбираю архитектуру обновлений через Implementation Authority и процесс деплоя токенов через TREXFactory и TREXGateway.

Идея Reserve простая: взять токены, упаковать их в один ERC-20 и получить on-chain индекс, который можно минтить, сжигать и ребалансировать без кастодианов и ручного управления. Но за простотой спрятана бизнес-логика: от расчёта доли пользователя в индексе до механизма ребалансировки.

В статье я разбираю Index DTF в Reserve Protocol: архитектура смарт-контрактов, процессы mint и redeem индекса, механизм ребалансировки через голландские аукционы, управление индексом и риски протокола. Если интересно, как на практике реализован «децентрализованный ETF», то мой разбор про это.

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

Сегодня поговорим о событиях в Solidity — одном из важных механизмов, с помощью которого смарт‑контракты общаются с внешним миром. Если вы интересиовались разработкой на Ethereum, то наверняка слышали про события: например, каждый токен ERC-20 при трансфере генерирует событие Transfer, благодаря чему кошельки и блоксканеры сразу видят движение токенов. Но что же такое events, как они работают и как их правильно использовать?

Эта статья — не критика CertiK. Это честный технический разбор того, что аудит делает, чего не делает, и как извлечь из него максимум пользы. Написано на основе опыта сопровождения Security Token Offering через полный цикл аудита CertiK, где я прошёл через 29 замечаний разной критичности и исправление уязвимостей в ERC-1400 контракте на 1,100 строк.

Algebra – это пример того, как можно взять Uniswap v3, убрать его ограничения и сделать из него полноценный DEX со своими особенностями. Протокол начинал как эксперимент над кодовой базой Uni v3, а в итоге вырос в DEX-as-a-Service, который используют 30+ бирж.

В статье разбираю, как Algebra решает проблемы Uniswap: почему динамические комиссии работают лучше фиксированных, как встроенный фарминг решает вопрос стимулов LP, зачем нужен Virtual Pool, и как версия Integral (v2) перешла к модульной архитектуре с хуками и плагинами, совсем как Uni v4.

Выбор стандарта для security token — это архитектурное решение, которое определит compliance-модель, gas costs, интеграционные возможности и upgradeability на годы вперёд. В этой статье я разберу два основных стандарта — ERC-1400 и ERC-3643 — с точки зрения разработчика, который имплементировал оба.

За 2024 год из DeFi-протоколов было похищено более $2.2 млрд. В первом полугодии 2025 года эта цифра уже превысила $2.17 млрд — и это только середина года. При этом 60%+ взломанных протоколов имели аудит от известных компаний.

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

Pendle – это протокол токенизации доходности. Доходные активы оборачиваются в SY-токены, а затем делятся на PT (“тело” актива) и YT (доходность актива). Получается DeFi-версия strip bonds, только подается с AMM и собственным соусом.

В этом разборе объясняю, как Pendle устроен внутри: как работает SY-обёртка, что такое PT и YT, зачем протоколу собственный стандарт ERC-5115, как устроен AMM, ордербук, разные типы APY, как смарт-контракты общаются между собой.

ERC-6909 – это интересный пример того, что стандарты токенов не всегда становятся сложнее. Этот стандарт сознательно упрощает ERC-1155:
- без batch-вызовов
- без callback’ов
- с гибкой системой апрувов

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

В статье разберем, как устроен стандарт ERC-6909, чем он отличается от ERC-1155, как работает новая система апрувов и почему Uniswap v4 уже использует его внутри протокола.

Блокчейн-индустрия переживает период беспрецедентного роста, при этом общая стоимость заблокированных активов (Total Value Locked, TVL) в децентрализованных финансовых протоколах превышает 200 миллиардов долларов по состоянию на 2024 год. Вместе с ростом экосистемы растет и количество инцидентов безопасности, связанных с уязвимостями в смарт-контрактах. Согласно отчету Chainalysis, только в 2023 году потери от хакерских атак на DeFi-протоколы составили более 3.7 миллиардов долларов. История блокчейн-индустрии изобилует громкими случаями эксплуатации уязвимостей смарт-контрактов.

Я Радда Юрьева, работаю в команде AppSec и вместе с коллегами из отдела Web3 исследую вопросы безопасности смарт-контрактов. В этой статье хочу поделиться нашим опытом анализа уязвимостей Solidity-кода и рассказать, какие подходы помогают находить и предотвращать ошибки на ранних этапах разработки Solidity-контрактов.

Прокси-контракты: Сравнение подходов OpenZeppelin и EVMPack

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

Что такое прокси-контракт?

Прокси-контракт - это простой контракт-переадресатор. Он хранит адрес основного, "логического" контракта. При вызове функции на прокси, он перенаправляет вызов (через delegatecall) на контракт с логикой.

Особенность delegatecall в том, что код исполняется от имени прокси-контракта, то есть в его контексте хранилища (storage). Это позволяет менять адрес контракта с логикой, в то время как все данные (состояние) остаются на адресе прокси. Для обновления достаточно просто указать прокси новый адрес реализации.

Представьте, что вы хотите обменять ETH на USDC, а кто-то в этот же момент меняет USDC на ETH. Зачем вообще звать маркетмейкеров и гонять ликвидность по пулу? Можно просто свести эти ордера друг с другом. На этом принципе (Coincidence of Wants или CoW) и построен CoW Protocol.

Aerodrome называют MetaDEX не случайно: он объединяет в себе механику Uniswap v2, стабильные пулы Curve и систему стимулов Convex. Протокол работает в сети Base и уже стал главным хабом ликвидности обойдя конкурентов. В этой статье разбираю, почему Aerodrome так быстро выстрелил, как устроена его токеномика AERO/veAERO и какие фичи он унаследовал от своих предшественников.

Так получилось что этот проект внезапно родился пока я создавал другой.

В мире блокчейна, разработка под экосистему ethereum очень сильно развита, много смарт контрактов "готовых", которые прошли аудит, много разных инструментов таких как Slither, Foundry, Hardhat и т.д., с ними комфортно писать контракты и тестировать.

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

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

Давайте вспомним что должна делать операционная система для классической ЭВМ: