Блокчейн разработка меняется со скоростью света. Решив вникнуть, купил несколько лет назад книгу, но к сегодняшнему дню она уже безнадежно устарела. Инструменты описанные в ней 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 и работаем почему то напрямую, без операционной системы.
Давайте вспомним что должна делать операционная система для классической ЭВМ:
В этой статье будет описано, как один чересчур поверивший в себя программист пытался взломать один из фундаментальных алгоритмов криптографии. Эта статья признана огородить других от подобных попыток или наоборот заинтересовать новых смельчаков для подобной авантюры. Сначала я опишу суть алгоритма на простом коде, затем перечислю методы и идеи, которыми я пытался его взломать.
Uniswap V4 — это новая версия Uniswap в которой снова все с ног на голову. В предыдущей версии мы увидели новую математику, а в этой версии новый взгляд на архитектуру смарт‑контрактов. Часть моментов я разбирал в своей прошлой статье, здесь мы углубимся в организацию работы смарт‑контрактов.
В этой статье мы разберем:
— Ключевые смарт‑контракты и библиотеки: репозитории и смарт‑контракты с которых начинать изучение кода
— Менеджер пулов: основной функционал и схема наследования
— Флоу транзакции: точка входа для пользователя и поставщика ликвидности
— Transient Storage: на примере разблокировки пула в качестве защиты от reentrancy
— Хуки: что смарт‑контракт хука использует и как вызывается менеджером пулов
Если вы хотите понять, как Uniswap V4 превратился из обычной DEX в мощную платформу для DeFi‑протоколов, эта статья для вас.
Когда мне понадобилось задеплоить один и тот же контракт в разные EVM-сети с одинаковым адресом — оказалось, что всё не так просто. Даже если всё заранее посчитать и подготовить, любой лишний nonce может всё сломать.
В этой статье я разбираю, как вообще формируется адрес контракта при деплое (при использовании CREATE и CREATE2), зачем появился Deterministic Deployment Proxy, и почему Safe в итоге сделали свою версию — Safe Singleton Factory.
Расскажу, как ей воспользоваться через Remix, Foundry и Hardhat, на что стоит обратить внимание (например, при работе с байткодом), и какие грабли могут ждать при попытке всё упростить.
Solidity — это статически типизированный язык программирования, ориентированный на контракты и используемый в основном для написания и реализации смарт‑контрактов на блокчейне Ethereum. Создание высококачественных смарт‑контрактов обеспечивает безопасность, надежность и эффективность. В этой статье рассматриваются основные концепции, лучшие практики и примеры создания надежных смарт-контрактов с помощью Solidity.
