Solidity *

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.

Если при слове «аукцион» ты представляешь молоток, галерею и ставки на картину — забудь. В Web3 всё иначе: торги может вести смарт‑контракт, ставки могут быть скрыты, а тип аукциона может смениться прямо по ходу торгов.

Я собрал в этой статье всё, что стоит знать про аукционы в блокчейне: какие виды бывают, как устроена логика работы и что с этим делают протоколы вроде MakerDAO, OpenSea, 1inch или Bounce. От классических английских аукционов до китайских лотерей и японского «последнего выжившего» — с примерами контрактов и кейсами из реальных проектов.

В этой статье я разбираю, как работает CREATE2, чем он отличается от CREATE, зачем нужен в контексте state channels и ERC-4337, и как его можно использовать — от вычисления адресов в Uniswap V2 до взлома Tornado Cash на $1M. Показываю примеры на Solidity и Assembly, а ещё — как на одном и том же адресе можно развернуть два разных смарт-контракта. Да, и такое возможно.

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

Создатели NFT всё чаще теряют доходы: маркетплейсы не платят роялти, пользователи ищут обходы, а стандарты вроде ERC-2981 ничего не гарантируют. ERC-721-C пытается это изменить. Новый набор контрактов от Limit Break предлагает механизмы жёсткого контроля за передачей токенов, валидаторы, whitelist’ы и маршрутизацию через Trusted Forwarder. Но вместе с защитой приходит и риск централизации. В этой статье — полный разбор архитектуры ERC721C, её плюсов, минусов и сценариев использования.

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

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

В данной статье мы делаем поверхностный обзор подходов, обеспечивающих безопасность смарт-контрактов. Разбираем устройство и принцип работы инструмента формальной верификации SMTChecker (встроен в компилятор solc), а также верифицируем с его помощью учебные контракты: находим баги и уязвимости, и доказываем их отсутствие.

Это третья, финальная часть моего цикла про LayerZero v2. В первой части я разобрал, как развернуть простой OApp в Remix, во второй — показал, как сделать оминчейн приложение на примере OFT-токена. Теперь пришло время докрутить детали.

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

ERC-2981 стал важным шагом к тому, чтобы NFT-авторы действительно получали справедливые роялти с перепродаж. Но работает ли это в реальности? В статье разбираемся, как устроен этот стандарт, какие задачи он решает, как его поддерживают маркетплейсы — и почему даже с его появлением вопрос с роялти остаётся открытым.

Сегодня, на фоне крупных DEX протоколов, таких как Uniswap и Radium, в тени остается Curve. Я считаю, что это незаслуженно. 

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

Привет всем из мира авось-программирования Solidity.

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

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