Solidity *

Еще немного про надежное программирование в Solidity

Исследуем хранилище EVM

Я уже писал что для хранения маппингов и динамических массивов (в том числе строк и байтовых массивов длиннее 32 байт) в Solidity, в качестве адреса объекта в постоянном хранилище, используется хеш-ключ . Это делает возможным (хоть и весьма маловероятным) возникновение коллизий при обращении к разным сохраненным объектам, что приведет к порче данных при записи объектов по совпавшим или близким адресам.

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

Однако, меня заинтересовало внутреннее устройство хранилища. 256 бит ширины адреса и константная стоимость записи слота требует нетривиальных решений с точки зрения реализации. И они нашлись у разработчиков EVM. Для хранения слотов хранилища, они используют modified Merkle-Patricia Trie который, как вы уже наверно догадываетесь ... да, именно, использует все тот же для вычисления адреса слота в хранилище. Адрес вычисляется, как где - это адрес контракта, а - это адрес в адресном пространстве хранилища.

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

Если вы прочитали статью, вы уже наверно заметили, что вычисление адреса данных маппинга в хранилище и адреса слота хранилища для хранения в modified Merkle-Patricia Trie подозрительно похожи. Эксперимент это подтвердил. Коллизии при полном переборе номеров слотов начинают возникать, как только битовая ширина номера слота превышает половину ширины адресного пространства. Таким образом, почти бесконечный размер хранилища съеживается до значительно более скромных . Иначе говоря, из всех слотов хранилища, вам надежно доступны только из них (эксперимент, как вы понимаете, перебирал те слоты, которые сосредоточены в начале хранилища с точки зрения их номеров).

А что, если посмотреть, как будут возникать коллизии в маппингах, с учетом того, как возникают коллизии при сохранении слотов хранилища? Я попробую и расскажу об этом в следующий раз.

🪙 Крипта никому не нужна, и блокчейн тоже (или нет?)

Другое дело AI — за ним БУДУЩЕЕ! А что этот ваш блокчейн криптоскамерский 🤢? Столько лет ему, а толку нет: одни спекуляции, пользоваться неудобно, никому не нужна децентрализация и т.д.

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

🅰️Ⓜ️Ⓜ️ Как появился AMM и почему я считаю, что это важно

Не хочется строить из себя Виталика (враньё — ещё как хочется), но давайте порассуждаем на бытовом уровне: так ли AI, к примеру, круче блокчейна? Сначала расскажу о том, что меня впечатлило (и без Виталика тут всё равно не обойтись).

Наверное, все слышали про whitepaper от Сатоши Накамото. Хочу заметить, что это уже готовый документ, который стал импульсом к рождению блокчейна. Но есть вещи не менее крутые и менее «оформленные» — например, пост Виталика на Reddit, который послужил началом появления различных формул AMM (Automated Market Makers) и DEX на их основе: «Let's run on-chain decentralized exchanges the way we run prediction markets».

Контекст такой: 2016 год, экосистема Ethereum активно развивается, но децентрализованные биржи сталкиваются с рядом проблем — низкая ликвидность, высокие спреды между покупкой и продажей, а также дороговизна и сложность управления ордерами непосредственно на блокчейне. В таких условиях очень сложно конкурировать с CEX, где всё быстрее и удобнее.

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

А в конце делает приписку, мол, тут Martin Köppelmann предложил упростить формулу и использовать инварианту «x * y = k». Мартин Кёппельман — это сооснователь и CEO Gnosis (Safe, CoW Protocol, CFT и др.). А формула, как мы знаем, стала фундаментом, на котором построены такие гиганты, как Uniswap, Curve, Balancer и другие.

👤 Кто (или что) стоит за блокчейном?

Так что же меня в этом впечатлило? Одна простая математическая формула способна создать огромный рынок и поменять правила игры. Всё это можно свести к простому тезису: математика и её производные в виде блокчейна, криптографии, в конце концов AI (куда без него) — могут значительно улучшать процессы за счёт повышения их эффективности.

А где конкретно блокчейн улучшает эффективность? Он уменьшает трансакционные издержки.

Трансакцио́нные изде́ржки (transaction cost) — затраты (в том числе с использованием рыночных механизмов); издержки, сопровождающие взаимоотношения экономических агентов.

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

Поэтому я искренне верю, что за блокчейном стоит технология и законы эффективности, которые со времением все равно безжалостно выпилят все неэффективное - это законы природы. Так ли сильно в этом плане блокчейн отличается от AI?

🏁Что в итоге?

Важный момент — я ни в коем случае не претендую на истину в последней инстанции. Вопрос открытый и требует обсуждений. Предлагаю обсудить эту тему в комментариях 👇.

Это в любом случае будет продуктивнее, чем говорить, что крипта — скам, а блокчейн — 💩.

@yarlykovrv

Как форкнуть Uniswap v3, не делая форка? Подсказка: нужна алгебра

Учёные расходятся в цифрах, сколько на самом деле существует форков Uniswap v2, но, скорее всего, много или даже очень много. «А раз это так популярно, почему бы не сделать из этого бизнес?» — подумали ребята из Algebra Finance и сделали DaaS (DEX-as-a-Service).

Но Uniswap v2 уже морально устарел: у пулов на его основе есть проблемы с непостоянными потерями (impermanent loss) и неэффективным использованием капитала, поэтому протокол построен на базе Uniswap v3.

🦄 Почему за основу взят Uniswap v3?

Концепция CLMM (Concentrated Liquidity Market Maker), которая стала основной фичей Uniswap v3, отчасти решала проблему непостоянных потерь, а кроме того, концентрированная ликвидность позволяла использовать капитал провайдеров ликвидности (LP) в разы эффективнее. Но всё же было у неё пара недостатков.

⚙️ DEX-движок

Первая версия протокола Algebra v1 не просто тупо взяла код третьего Uniswap: была сохранена основная архитектура (core + periphery контракты), но переработана таким образом, чтобы исправить недостатки Uniswap v3:

1. Динамические комиссии — тут команда протокола сильно заморочилась и разработала формулу, которая учитывает волатильность актива, объём ликвидности и объём торгов, и на основании этих данных корректирует комиссию пула.
   Получается, что:
   • При высокой волатильности комиссия увеличивается, чтобы компенсировать риски LP.
   • При низкой торговой активности, но достаточной ликвидности, комиссия снижается, чтобы стимулировать больше обменов.
   Таким образом, всю ликвидность конкретной пары можно держать в одном пуле, а не разбивать на несколько с разной комиссией (как в Uniswap v3). Подробно формула разбирается в whitepaper.

2. Фарминг из коробки — добавили возможность поощрять LP через фарминг-кампании. Дело в том, что в случае с CLMM стандартный фарминг не подходит. Для справедливого распределения ревардов нужно учитывать:
   • объём ликвидности конкретной позиции;
   • время, когда эта позиция была в диапазоне и зарабатывала комиссии.
   Задача нетривиальная: для этого пришлось разработать виртуальные пулы, которые подключаются к основному пулу и получают эту информацию в реальном времени (у Uniswap ничего подобного нет).

🚀 Запуск протокола

После истечения лицензии на код Uniswap v3 (в апреле 2023 года) разные DEX'ы начали разворачивать Algebra v1, например QuickSwap, Camelot, THENA.

Судя по отсутствию в документации информации о развертывании, команда Algebra делает это самостоятельно. За это протокол получает community fee, то есть часть торговых комиссий DEX'ов отчисляется протоколу. На данный момент этим решением уже воспользовалось больше 30 DEX.

У протокола есть токен ALGB: около 70% заработанных комиссий тратится на выкуп и сжигание этого токена, остальные идут на поддержание работы протокола и выплату ревардов за стейкинг ALGB.

🥈Algebra v2 (Integral)

Недавно была представлена вторая версия протокола — Algebra Integral. Фактически это функционал Uniswap v4, но на базе всё того же Uniswap v3. В четвёртой версии Uniswap сделал единый пул, а также добавил хуки.

Хуки — это callback-функции, которые вызываются при основных действиях пула (иницилизация, свопы, добавление/удаление ликвидности, flash-loan) и позволяют вынести много логики «наружу».

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

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

Мы с коллегами периодически пишем в нашем Telegram-канале. Если интересно, что у нас в работе и что обсуждаем, можете заглянуть.

@yarlykovrv

🗝 Так вот он какой мой адрес кошелька в Ethereum

Почти три года занимаюсь разработкой смарт-контрактов для Ethereum и ему подобных. И сегодня коллега задал мне вопрос на который я не смог ответить сразу!

Есть два адреса: 0x5aaeb6053f3e94c9b9a09f33669435e7ef1beaed и 0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed. Это один и тот же адрес? Или два разных?

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

И вот тут я крепко задумался… Тем более когда начинаешь копать, то ответ лежит наверху: Ethereum адреса не чувствительны к регистру!

В природе Ethereum адреса можно встретить разные:

• 0xabc... (нижний регистр)

• 0xABC... (верхний регистр)

• 0xAbC... (смешанный регистр)

▫️Но как их видит сама EVM?

Любой адрес преобразуется в 40 шестнадцатеричных символов (hex) нижнего регистра (без 0x). Используются символы [0-9A-F]*. Однако EVM не важен регистр, так как она все символы преобразует в нижний регистр по умолчанию. Таким образом в EVM наш адрес будет всегда 5aaeb…435e7ef1beaed.

Но зайдем в etherscan, вставим наш адрес и увидим некоторые буквы с верхним регистром в поле адреса.

▫️Что не так с etherscan?

А все так! Ответ на этот казус кроется в ERC-55: Mixed-case checksum address encoding. Согласно спецификации, "сбоку» (сугубо off-chain) для адресов вводится понятие checksum (контрольная сумма). В Ethereum — это механизм проверки целостности адреса, который помогает обнаружить ошибки ввода (опечатки) за счёт использования заглавных букв в шестнадцатеричной записи адреса.

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

Сама EVM не проверяет checksum — это делают только кошельки и интерфейсы (например, MetaMask или Etherscan). Если отправить транзакцию на 0x5AAEB... (все буквы с верхним регистром), EVM всё равно обработает её, как 0x5aaeb.... Получается, что пользователи могут видеть, что адрес введён верно (ошибки в регистре могут сигнализировать об опечатке или мошенничестве).

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

▫️Проверь свой адрес

Используй Etherscan или ETH Checksum Tool. При помощи этих сервисов можно проверить контрольную сумму адреса.

▫️Вывод

EVM понимает адрес в любом регистре, но checksum — наша близкая к стопроцентной защита от ошибок и опечаток! Не стоит пугаться, если разные кошельки в разные моменты времени показывают адреса то в нижнем регистре, то в смешанном.

@pnaydanovgoo

Проблема распределения памяти хранилища в Solidity

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

Как хранятся данные смарт-контракта в хранилище

В адресном пространстве хранилища (2**256 слов размером 32 байта), все постоянные переменные контракта фиксированного размера хранятся в самом его начале (самые младшие адреса). Однако, язык Solidity предоставляет возможность хранить и динамические переменные, которые могут менять свой размер. Язык позволяет использовать две разновидности таких переменных, динамический массив и отображение.

В Solidity (и в других языках смарт-контрактов, с которыми мне удалось бегло ознакомиться) для хранения динамических данных используется хитрый трюк, связанный с функцией криптографического хеширования keccak (в смарт-контрактах используется keccak256, которая возвращает хеш размером 256 бит).

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

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

Так в чем проблема?

Проблема в том, что же делать, если пересечение данных все-таки случилось.

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

Однако, начиная работать со смарт-контрактами, мне бы не хотелось стать тем счастливчиком, который наткнется на пересечение ключей в своем смарт-контракте первым. Насколько я понимаю, никакой диагностики пересечения ключей (и тем более, пересечения массивов, разбросанных функцией keccak в адресном пространстве хранилища) не предусмотрено, а результат такого пересечения для контракта - катастрофический, сравнимый с доступом к неинициализированной памяти в C++.

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

Что делать?

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

Масштабирование Ethereum L1 и L2 в 2025 году и далее

Большая несправедливость, что статьи Виталика читают мало людей — это же годнота! На некоторые из них я хочу делать обзорные посты. Может, кого-то это побудит почитать оригинал, ну или вы узнаете об основных идеях и меньше будете переживать, что эфир уже не торт 🧁.

Коротко по вступлению. Ethereum — это все еще про дух опенсорса, про трушность и киберпанк, про децентрализацию, социальные технологии и долгосрочную стратегию с далеко идущими планами.

🧐 От философии к делу

За последний год удалось добиться низкой платы за газ — это значит, что L2 работают. Они увеличивают пропускную способность Ethereum в 17 раз. Но есть и проблемки.

Гетерогенность — это термин, означающий разнородность, то есть наличие различных по свойствам, структуре или природе компонентов в одной системе. Гетерогенность одновременно и сила, и слабость L2. Проблема координации цепочек — это неудобства для пользователей и разработчиков.

Курс Ethereum на L2 — максимальный, но от них также требуется следование общим идеям. Это значит, что каждый должен сфокусироваться на своих задачах: L1 улучшает блобы и другие фундаментальные аспекты сети (эффективность PoS, верификацию без хранения состояния, легкие клиенты, EVM, криптографию и хранение данных), а также наращивает стоимость ETH.

В свою очередь, L2 должны работать над:
• улучшением безопасности;
• улучшением стандартизации: пользователь должен использовать L1+L2 как единую экосистему, а не как десятки разных чейнов;
• улучшением времени ввода/вывода средств на L2;
• превращением гетерогенности из недостатка в преимущество: при базовой совместимости одни rollup'ы могут быть копиями EVM, другие - экспериментировать с виртуальными машинами или решать специфические задачи. Именно это и будет формировать мощную экосистему.

💾 Блобы, блобы, блобы

Блоб (blob) — это дешёвое, временное хранилище данных для rollup'ов (L2) в Ethereum. Блобы были добавлены в хардфорке Dencun (март 2024).

Основной упор масштабирования L1 — на блобы. Сейчас выделяется 3 блоба на слот, с форком Pectra это число удвоится. В дальнейшем весь фокус разработчиков Ethereum будет на увеличении количества блобов — уже есть идеи, как достигнуть 128 блобов на слот, а это около 100 000 транзакций в секунду.

🛡Улучшение безопасности

По градации L2Beat только три L2 достигли Stage 2, и ещё три находятся на Stage 1 — Optimism, Arbitrum и Ink. Это не есть гуд: стадии отражают уровень децентрализации и безопасности протоколов (от 0 до 2). Поэтому Ethereum должен продолжать работу по усилению безопасности L2, в том числе через нативно обрабатывая доказательства для rollup'ов через прекомпиляции.

🕸Интероперабельность и стандартизация

Цель — сделать перемещение активов между L2 таким же простым, как если бы это были шарды одного блокчейна.

Что для этого можно сделать в билжашем будущем:
• Адреса, отражающие связь с цепочкой. Например, ERC-3770.
• Стандартизация кросс-чейн взаимодействий — сообщения между цепочками должны полагаться только на криптографическую безопасность самих L2, без доверенных участников!!! Это булыжник 🗿 в сторону таких протоколов, как Axelar, LayerZero, Chainlink CCIP и т.д.
• Ускорение ввода-вывода средств с помощью ZK.
• Быстрое чтение из L1 повысит скорость синхронизации между L1 и L2.
• Общий секвенсор на базе L1. Секвенсор — это компонент rollup'а, который принимает и упорядочивает транзакции. Он определяет, в каком порядке данные попадут в блок и на L1.

💸 Экономика ETH

Поддерживать ценность ETH как тройного актива (triple-point asset: средство обмена, средство накопления, актив в DeFi), а также:
• ETH дожен быть главным активом всей экосистемы (L1 + L2).
• Мотивировать L2 отдавать часть комиссий в ETH.
• Увеличить количество блобов и рассмотреть минимальную цену за них.

Заключение

Все будет ок ☺️. Но нужно еще проделать большую работу и быть максимально активным гражданином участником сообщества вместо того, чтобы ругать Виталика и Ethereum Fondation.

@yarlykovrv

Как сделать свой OFT-токен

Ранее я уже рассказывал о протоколе LayerZero. Также упоминал, что по программе lzCatalyst выделяются большие средства на разработку омничейн-решений. Если взглянуть на экосистему LayerZero, то самым популярным таким решением являются OFT-токены. Пример такого токена — USDT0.

Мы с командой решили по косточкам разобрать OFT-токен и, конечно же, сделать свой. Статья получилась большая, поэтому для удобства она разбита на три части + отдельная часть по архитектуре LayerZero.

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

• Архитектура LayerZero

• Часть 1. Простой OApp в Remix

• Часть 2. OFT-токен, создание

• Часть 3. Параметры (options), особенности, PreCrime

🔨 Простой OApp в Remix

Все начинается с OApp (Omnichain Application) — омничейн-приложения, имеющего все необходимые интерфейсы для отправки и получения сообщений. Перед тем как создать свой OFT, стоит попрактиковаться в отправке простого сообщения из одного блокчейна в другой, например, "Hello, World" или что-то более оригинальное.

Для простоты сделать это лучше всего в онлайн-IDE Remix. Для этого даже не нужно быть разработчиком — справится любой, кто внимательно прочитает гайд. Это позволит понять самые основы омничейн-взаимодействия: например, расчёт стоимости газа для отправки, специфику формата адресов, которые используются в экосистеме LZ, а также устройство элементарного OApp.

А для тех, кто совсем не хочет заморачиваться, я развернул контракты в мейннете Arbitrum и Polygon — можете воспользоваться ими для отправки сообщений (через Remix).

🪙 OFT-токен

Тут самое мясо 🥩. Чтобы создать свой OFT-токен, лучше всего подойдёт готовый проект от LayerZero, который можно развернуть одной командой: npx create-lz-oapp@latest. Он включает в себя все необходимые инструменты:

▫️ базовый контракт OFT-токена;
▫️ тесты на Foundry и Hardhat;
▫️ скрипты деплоя и профилирования газа;
▫️ конфигурацию стека безопасности для LayerZero.

Чтобы понять, из чего состоит OFT-токен и что ещё с ним можно сделать, нужно разобрать, как работают основные функции: send и lzReceive. В процессе выполнения они делают много интересного, например, конвертируют amount в shared decimals для отправки и обратно в local decimals при получении, а также удаляют «пыль».

Для самых искушённых есть Foundry-скрипт для отправки токенов и объяснение того, как профилировать расход газа в сети назначения.

🎛 Параметры (options), особенности, PreCrime

Одна из важных составляющих омничейн-взаимодействия в протоколе LZ — работа с опциями. Опции отвечают за то, как сообщение будет обрабатываться в сети назначения. Поэтому необходимо понимать, как они устроены и какие бывают.

Ⓜ️ OFT-токен MetaLamp

Для тех, кто разобрался в теории отправки омничейн-сообщений, но не хочет писать свой токен, а просто хочет посмотреть живой пример, есть токен MetaLampOFTv1, развёрнутый в Ethereum Sepolia и Polygon Amoy. Чтобы получить 100 токенов, можно вызвать функцию claim контракта через Etherscan или Polygonscan. Сам проект лежит здесь.

Клеймить MetaLamp-токен можно сколько угодно, ни в чем себе не отказывайте 😉

Мы с командой регулярно пишем в Telegram-канале. Если вам близки темы, о которых здесь говорим, то заходите.

@yarlykovrv

Как мы собрали web3 в одну книгу и почему это must-have для разработчиков

Недавно наша команда сделала кое-что крутое – первую русскоязычную книгу по web3. Она бесплатная, онлайн, и в ней всё, что нужно, чтобы разобраться в блокчейне и web3-технологиях без хаотичного гугления. Читать можно тут.

Почему это важно

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

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

Это как собирать пазл без картинки: долго, муторно, и не факт, что сложится. А тут - готовый онбординг, где всё разложено по полочкам.

Что внутри

Мои коллеги полгода анализировали сотни источников – от зарубежных статей до российских кейсов. Добавили свой опыт (а у нас за плечами десятки блокчейн-проектов), контрольные вопросы и практические задания. Плюс  комментарии от топовых спецов индустрии, таких как Базовый Блок, Cyber Academy, Aqua Protocol, Botanica и др. 

Книга не про "вот вам теория, разбирайтесь". Это структурированный гайд: от основ блокчейна до более глубоких концепций. Задания помогают закрепить материал, а комментарии экспертов – понять, где это реально применяется.

Кому пригодится

Если вы работаете в web2 (разработчик, менеджер, hr, тестировщик, дизайнер и тд.) и хотите зайти в web3, но не знаете, с чего начать – это для вас. Или если еще не работаете в IT и думаете про web3 нишу – тоже сюда. Лично мне было бы проще в своё время с таким гайдом: меньше бы спотыкался на старте и быстрее бы втянулся в проекты.

Почему бесплатно

Мы решили дать доступ всем. Web3 – это про открытость, и нам важно, чтобы русскоязычные разработчики не отставали. Плюс, это наш вклад в комьюнити/ Надеюсь, вы оцените.

Итог

Это удобный старт. Читайте, отвечайте на контрольные вопросы, выполняйте задания. Может, у вас есть идеи, что добавить в следующую версию? Мы открыты к фидбэку. Оставить его можно у нас в тг канале. 

Ссылка на книгу: metalamp.ru/magazine/web3-book.

До встречи в web3!

EIP-7549: Move committee index outside Attestation

EIP-7549 является вторым предложением по изменению на уровне консенсуса и предлагает переместить индекс комитета за пределы аттестации. Звучит интересно, но непонятно. Начнём разбираться издалека.

▫️Введение в работу валидатора

Все мы знаем, что валидаторы оставляют 32 ETH в качестве депозита и после этого запускают специальное программное обеспечение, которое состоит из трёх частей:

• Execution Client

• Consensus Client

• Validator Client

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

▫️Структура слотов и эпох в Ethereum

Далее стоит отметить, что сейчас в Ethereum время появления блоков фиксированное и делится на слоты. Один слот — 12 секунд, эпоха — 32 слота. Для каждого слота случайным образом выбирается валидатор, предлагающий блок. В его обязанности входит создание и отправка блока другим участникам. Также в слоте случайным образом выбирается комитет валидаторов, аттестации которых должны подтвердить, что блок действительный. Разделение валидаторов на комитеты необходимо для управления нагрузкой на сеть. Деление на комитеты организовано так, чтобы каждый активный валидатор подтверждал блок в каждой эпохе, но не в каждом слоте.

▫️Понятие финализации блоков

Но это ещё не всё. Чтобы транзакция считалась окончательной, она должна быть частью блока, который уже не может быть изменён без больших затрат. Этот процесс называется финализацией. Управляется это при помощи специальных «checkpoints». Первый блок каждой эпохи — это и есть checkpoint. Требуется две трети от общего застейканного эфира всех валидаторов, которые предоставят свои аттестации.

▫️Разбор полей аттестации

Это всё в теории. Под капотом консенсуса работают два компонента: Casper-FFG и алгоритм выбора форка LMD-GHOST. Первый компонент отвечает за финализацию блоков, получение валидатором вознаграждения или наказания, второй компонент следит за раздвоением сети.

Ожидается, что активный валидатор создаст, подпишет и передаст аттестацию в течение каждой эпохи как минимум. Каждая аттестация содержит в себе следующие поля:

• aggregation_bits: Массив бит валидаторов, где каждый индекс соответствует номеру валидатора в комитете.

• data: Сведения для аттестации (подтверждения действительности блока).

• slot: Номер слота, для которого подготовлена аттестация.

• index: Номер, который идентифицирует, к какому комитету принадлежит валидатор в данном слоте.

• beacon_block_root: Хеш блока, за который валидатор голосует.

• source: Последний согласованный чекпоинт.

• target: Целевой чекпоинт текущей эпохи.

• signature: Подпись BLS, которая подписывает данные поля data.

▫️Предлагаемое изменение в EIP-7549

Вот мы и добрались до индекса, который EIP-7549 предлагает вынести за пределы аттестации. Для Casper-FFG это критически важное изменение. Суть в том, что все участники разных комитетов голосуют за одну и ту же информацию,  подписывая данные в поле data аттестации. Зачастую данные одинаковые, за исключением индекса комитета, который не позволяет агрегировать эти подписи в одну. Поэтому предлагается убрать индекс и объединить одинаковые аттестации, что позволит уменьшить их количество.

Вот так, покопавшись в сути этого EIP, который на первый взгляд мог выглядеть странно, я могу сделать вывод, что звучит всё логично, по крайней мере идея становится понятной. Видимо, поэтому мне и не удалось найти каких-то явных противостояний или противников EIP-7549. Отдельно стоит отметить, что этот EIP вносит обратно несовместимые изменения в проверку блоков на уровне консенсуса, поэтому он и включается в хард-форк.

Подписывайтесь на наш телеграм-канал:)

Разбор ERC-6900: Модульные абстрактные аккаунты и плагины

ERC-6900 — это стандарт Ethereum, определяющий модульные абстрактные аккаунты (Modular Smart Contract Account — MSCA). Он расширяет функциональность абстрактных аккаунтов ERC-4337 (кто пропустил, мы уже писали о них тут), позволяя выносить дополнительную логику и проверки во внешние модули.

Ключевые аспекты ERC-6900:

• Модульность: позволяет разделить логику аккаунта на отдельные плагины.

• Расширяемость: упрощает добавление новых функций к аккаунтам без изменения основного кода.

• Стандартизация: обеспечивает совместимость между различными реализациями аккаунтов и плагинов.

• Интеграция с ERC-4337: совместим с инфраструктурой Account Abstraction.

Важно! Оба стандарта (ERC-4337 и ERC-6900) находятся в стадии черновика, поэтому возможны изменения. В статье рассматривается AA (ERC-4337) версии v0.6.0 и ERC-6900 (MSCA) версии v0.7.0 (на базе AA v0.6.0). Например, уже есть новая версия AA, в которой изменена работа с validateUserOp, но MSCA пока этого не поддерживает.

Кроме того, ERC-6900 тесно связан с Alchemy, поэтому самые свежие обновления по этому стандарту, скорее всего, будут в их репозиториях, так как они разрабатывают архитектуру для работы с такими аккаунтами. Это один из главных недостатков стандарта — он создается с учетом нужд конкретного протокола, а не всего сообщества.

Читайте продолжение статьи тут:)

Опубликовали новую статью — обзор протокола LayerZero!

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

Велком к прочтению:)

Еще мы ведем свой телеграм-канал, где информация из мира разработки и web3 выходит оперативнее всего, переходите почитать авторские посты и мнение нашей команды, а также похоливарить в комментариях:)

❗️Внимание разработчики

Команда MetaLamp столкнулась со скамером. Рекомендуем изучить, чтобы не стать жертвой мошенников.

За последние сутки к нам поступило несколько запросов на разработку высокобюджетного проекта, где сначала нужно было пройти тестовое задание. Мы развернули код и заметили там подозрительную активность в одном файле. 

Решили обсудить это с нашими друзьями-аудиторами из BugBlow и ребята обнаружили стилера (от англ. steal — красть) написали подробный отчет. 

В чем угроза?

Стилер украдет с вашего компьютера криптокошельки, браузерные пароли, установит какой-нибудь бэкдор. 

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

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

Кстати хакер, написавший этот код оставил свой IP адрес, на который украденные данные отправляются 138.201.199.46. 

Если что-то запускаете, всегда запускайте с виртуальной машины, не со своего компьютера. 

Спасибо Александру Долгавину из BugBlow за отчет! Вступайте в чат про безопасность BugBlow и читайте X команды.

Stay Safe!

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE. Part 2

Part 1 опубликован здесь.

Маленький нюанс: в чем профит условному Lido объединять группу своих валидаторов в одного? Предлагается несколько плюшек: возможность частично изымать сумму стейкинга, а также обсуждаются послабления штрафной системы, плюс, как я понял выбор валидаторов взвешенный уже сейчас, чем больше стейк, тем выше вероятность, что валидатор будет выбран для добавления блока (поправьте меня тут, если я не прав)

Что же остается делать соло валидаторам? Их вероятность добавлять блоки теперь ниже? Кажется именно так. Взамен предлагаются гибкие ставки, например, можно сразу стейкать 40 ETH в одного валидатора и получать больше вознаграждения, а не копить на второго валидатора. Достаточно соло валидаторы ущемлены на благо диверсификации сети? Надеюсь, что в меру, чтобы продолжить быть валидаторами.

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

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE. Part 1

Идея проста! EIP-7251 предлагает валидаторам стейкать больше 32 ETH. Сейчас в коде за это отвечает переменная «MAX_EFFECTIVE_BALANCE». Отсюда и такое название EIP. Тоесть, а давайте увеличим максимальную сумму для стейкинга.

Приводится статистика: на октябрь 2023 года в сети работает свыше 830 000 валидаторов и их число продолжает расти. Однако, есть большое количество «redundant validators» или избыточных валидаторов — это связано с протоколами ликвидного стейкинга, которые объединяют пользователей в группы для совместного управления валидаторами. Сейчас сумма стейка ограничена 32 ETH и такие протоколы запускают множество валидаторов. В результате мы имеем, что определенная группа валидаторов находится в одних руках. На 12 октября доля Lido занимает 29,7%. Пурумпурумпум! Ситуация!

EIP предлагает оставить 32 ETH как нижнюю границу, своего рода входной билет, а верхнюю поднять до 2048 ETH. Рассчет прост, теперь Lido может держать за место 64-х валидаторов со стейкиногом по 32 ETH всего одного на 2048 ETH. Не сложно догадаться, что это должно положительно сказаться на диверсификации сети и снизить количество избыточных валидаторов.

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

Бонус: в конце статьи вы найдете инструкцию как сделать свой мост :)

Если хотите узнавать самые последние новости и интересные тренды из web3, то переходите в наш телеграм-канал, там мы холиварим и обсуждаем все самое интересное и полезное!

EIP-7600: Hardfork Meta - Pectra

Pectra — запланированный хардфорк сети Ethereum на конец 24-го или начало 25-го года. На данный момент, хардфорк включает в себя 8 запланированных и 3 рассматриваемых на включение EIPs.

Consensus Layer

• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

• EIP-7549: Move committee index outside Attestation

Execution Layer

• EIP-2537: Precompile for BLS12-381 curve operations

• EIP-2935: Save historical block hashes in state

• EIP-6110: Supply validator deposits on chain

• EIP-7685: General purpose execution layer requests

• EEIP-7002: Execution layer triggerable exits

• EIP-7702: Set EOA account code for one transaction

Общие 

• EIP-6110: Supply validator deposits on chain

• EIP-7002: Execution layer triggerable exits

Практически все EIPs относятся к внутренним механизмам и затрагивают несколько этапов из роадмапа Ethereum: The Merge (улучшение со стороны консенсуса), The Scourge (решение проблем централизации), The Splurge (fix everything else).

Интересно здесь то, что немалая часть уделяется этапу «The Splurge». Это история про поправим все остальное. Что это означает? Протокол сделал все что хотел и работает над стабилизацией после хардфорка Dencun? Чтобы ответить на этот вопрос предлагаем вместе с нами попробовать разобраться во всех EIPs.

Первый EIP-7251 разберем в следующем посте, а то нас ограничивает количество символов в постах на Хабре:)

Все посты по этой теме можно будет найти по тегу #в_гостях_у_Pectra. Больше интересных тем разбираем в нашем телеграм-канале!

Мы выпустили новую крутую статью! Это технический обзор UniswapX — протокола, который выполняет обмен токенов через сторонних поставщиков ликвидности с применением аукциона. 

Чем интересна эта статья?

• Рассмотрели архитектуру протокола

• Способы его интеграции в существующие системы

• Различные стратегии исполнения ордеров

Велком к прочтению!

Начинаем серию статей про рынок предсказаний и его главного представителя на сегодня Polymarket. В первой статье подробнее разберем, как работает Gnosis Conditional Token Framework, который реализует кодовую базу для токенизации потенциальных исходов на рынке предсказаний.

Приятного прочтения!

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

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

Наша команда разработки прошла этот путь и основываясь на накопленном опыте, создала структурированную программу обучения. У нас в MetaLamp уже есть успешный опыт создания подобных программ: мы сделали программу обучения для фронтенд и бекенд разработчиков.

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

Сейчас у нас появилась 3-я ветка программы, приглашаем всех, кому интересно обучиться на разработчика смарт-контрактов для EVM-сетей и погрузиться в мир Solidity!

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

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

Welcome!

Привет всем!

Наш Lead Solidity-разработчик Паша Найданов @pnaydanovgoo опубликовал новую статью про Aave: в ней он разбирает работу Flash loans — типа кредитования на базе смарт‑контрактов, который не требует залога для обеспечения займа.

Почему Flash loans так популярны сейчас и какими уникальными характеристиками они обладают, а главное, как их можно использовать — подробности в статье:)