Когда мне понадобилось задеплоить один и тот же контракт в разные EVM-сети с одинаковым адресом — оказалось, что всё не так просто. Даже если всё заранее посчитать и подготовить, любой лишний nonce может всё сломать.

В этой статье я разбираю, как вообще формируется адрес контракта при деплое (при использовании CREATE и CREATE2), зачем появился Deterministic Deployment Proxy, и почему Safe в итоге сделали свою версию — Safe Singleton Factory.

Расскажу, как ей воспользоваться через Remix, Foundry и Hardhat, на что стоит обратить внимание (например, при работе с байткодом), и какие грабли могут ждать при попытке всё упростить.

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

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

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

В первой части мы разобрали, как развернуть простой OApp в Remix IDE. Пора переходить ко второй. Здесь познакомимся с ключевыми смарт-контрактами и напишем свой OFT (Omnichain Fungible Token). Это поможет на практике разобраться, как работает LayerZero, и понять, на что стоит обращать внимание при разработке омничейн-приложений.

Если вы уже читали мою статью про архитектуру LayerZero v2, то следующий логичный шаг — попробовать протокол в деле. В этой статье расскажу, как развернуть простой OApp в Remix IDE: настроим контракты, отправим сообщение между двумя сетями и разберёмся, как это работает на практике.

Привет, Хабр. В этой статье поговорим о новом стандарте для абстракции аккаунтов – ERC-7579, а именно, как он позволяет разработчикам внедрять расширенный функционал и давать пользователю возможность самому изменять настройки аккаунта с помощью модулей. А еще подробнее расскажу, что вообще такое MSA (Modular Smart Accounts), как разрабатывать, устанавливать и регистрировать модули плюс разберем небольшой пример написания и тестирования модуля. 

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

В этой статье я расскажу о первой версии этого фреймворка, его архитектуре и возможностях применения. Поехали!  

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

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

В этой статье я расскажу про ERC-6900 - первую попытку стандартизировать создание и имплементацию модулей в абстрактные аккаунты. Насколько удачным получился этот стандарт - узнаете в статье.

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

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

В этой статье я расскажу про язык среднего уровня между Solidity и байт-кодом, который применяется в EVM. Основная задача Yul - это оптимизация смарт-контрактов по газу, как на уровне языка так и на уровне компилятора, а также гораздо больший контроль над выполнением кода. Мы вместе погрузимся в синтаксис языка с головой и попытаемся выплыть, а также научимся работать с разными типами памяти и приготовимся писать смарт-контракты с inline assembly вставками. Будет сложно, но интересно, погнали!

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

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

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

В одной из статей о расчете газа в Ethereum (ссылка) я рассказал об истории изменений механизмов подсчета газа для хранилища смарт-контракта (storage) — от правил, заложенных в протоколе изначально, до EIP-3529. Во всех этих изменениях прослеживается основная проблема: нерациональное использование газа, когда слот хранилища смарт-контракта изменяется в ходе транзакции и затем возвращается к исходному значению, например, при блокировке функции для защиты от атак reentrancy. Иными словами, в ситуациях, когда постоянное хранилище используется как временное, а также в случаях необходимости безопасной передачи данных между фреймами вызовов.

В этой статье рассмотрим нововведение хард-форка Dencun (Cancun-Deneb), где в рамках обновления слоя выполнения был представлен EIP-1153: Transient storage opcodes, предлагающий решение этой проблемы за счет введения двух новых опкодов (TSTORE, TLOAD) и создания нового типа памяти в EVM - transient storage.

Привет всем! В прошлой статье мы с вами изучили общую механику расчета газа при выполнении транзакций. В этой статье мы сфокусируемся на самых «дорогих» операциях работы с хранилищем смарт‑контракта (storage), а также пройдемся по истории EIPs, связанных с расчетом газа в Ethereum, чтобы увидеть, по каким принципам сообщество принимало решения об изменениях «правил игры» и как сегодня, на основе этой истории, правильно выполнять такие расчеты.

Статья для тех, кто хочет разобраться почему слоты в storage бывают теплыми и холодными, грязными или свежими и за что возвращают газ. Также затронем списки доступа и intrinsic gas. Наконец увидим полную картину учета газа от инициализации транзакции до ее выполнения.

Привет, Хабр! Продолжаю серию статей о газе в Ethereum. ​​В этой статье подробно разберем составляющие параметра gasUsed , без которого невозможно подсчитать стоимость транзакции. Будем разбирать формулы из "желтой бумаги" и копаться в коде клиента "Geth". Это даст основу для понимания, как газ потребляется во время исполнения любой транзакции. Если вы еще не читали статью про то, как рассчитывается комиссия за газ в Ethereum, то она здесь.

Привет всем! Я — Рома Ярлыков, разработчик смарт‑контрактов на Solidity в команде MetaLamp. ​​В этой статье я исследую механизмы расчета и составляющие цены газа в блокчейне Ethereum, описываю историческое развитие этих методов и их значимость, а также демонстрирую, как вычислить стоимость транзакции на основе ее газовых затрат. Это будет цикл статей, поэтому если вам интересна эта тема — не пропустите следующие:)

Привет, Хабр! Меня зовут Рома Ярлыков, я разрабатываю смарт-контракты на Solidity в MetaLamp. В этой статье я расскажу, как реализован Account Abstraction в zkSync и чем такой подход отличается от уже популярного стандарта ERC-4337. Чтобы понять, что за блокчейн zkSync, рекомендую сначала прочитать эту статью. А чтобы разобраться с Account Abstraction можно прочитать вот эту.

В Ethereum существует два типа аккаунтов: внешние аккаунты (Externally Owned Accounts, EOA), которые могут инициировать транзакции, но не обладают программируемой логикой, и смарт-контракты, имеющие возможность выполнения произвольной логики, но неспособные инициировать транзакции самостоятельно. Это вызывает большое количество проблем при взаимодействии с экосистемой блокчейна и повышает порог входа для новых пользователей.

Привет, Хабр! Меня зовут Рома и я Solidity-разработчик. Вместе с коллегами мы создаем базу знаний по тематике блокчейна и web3-разработке. Меня заинтересовал блокчейн zkSync, т.к. он выделяется среди других Layer 2 решений, но сначала хочу немного рассказать, в чем суть проблемы масштабирования и какие есть особенности L2 в связке с ZK-Rollups. Эта статья будет интересна тем, кто хочет верхнеуровнево разобраться как работают такого рода решения и почему ZK-Rollups очень перспективное направление развития для блокчейнов в целом и Ethereum в частности.

Привет, Хабр! Меня зовут Рома Ярлыков и я Solidity-разработчик в компании MetaLamp. В этой статье я подробнее расскажу про различные приемы, подходы и паттерны в распределение токенов среди участников проекта, а также покажу несколько популярных решений, используемых для вестинга токенов, одно из которых я применял на проекте заказчика. В этой статье можно найти ответы на популярные вопросы, которые возникают у разработчиков в проекте при реализации вестинга.