Web3: карта трека, что это технически и где реально применимо

Это вход в трек из двенадцати статей. Блокчейн здесь — не идеология и не финансовый инструмент, а распределённая система с конкретными свойствами и очень конкретной ценой. Мы разбираем, как устроен блок, как проверяется подпись, откуда берётся газ, почему withdraw можно вызвать повторно и почему картинку из NFT нельзя положить в цепь.

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

1. Что такое Web3, если убрать маркетинг

Технически публичный блокчейн — это реплицированная детерминированная машина состояний с открытым членством. Каждое слово несёт последствия.

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

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

Реплицированная. Полное состояние держит каждый полный узел — не шард, не часть, а всё. Это даёт верифицируемость: любой пересчитывает историю и убеждается, что правила не нарушены. Это же объясняет цену — байт в состоянии оплачивается тысячами независимых копий на десятилетия вперёд.

С открытым членством. Разрешение на запись не выдаётся: достаточно ключа и средств на комиссию. Часть участников заведомо враждебна и финансово мотивирована, поэтому модель угроз здесь византийская, а не «сбой диска». Отсюда весь консенсусный аппарат (https://courses.digitable.life/post/web3/03-consensus/), в обычном бэкенде не нужный.

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

2. Что блокчейн действительно даёт

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

Устойчивость к цензуре записи. Валидатор может не включить вашу транзакцию, но не помешает включить её следующему. Свойство статистическое, слабеет при концентрации инфраструктуры, но качественно отличается от «админ забанил аккаунт».

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

Композиция без интеграции. Контракт вызывает другой атомарно: либо применились оба изменения, либо ни одного — без API-ключей, договоров и согласования релизов. Сравните с болью распределённых транзакций между микросервисами (https://courses.digitable.life/post/architecture-patterns/06-saga-and-distributed-transactions/): здесь атомарность бесплатна, потому что всё исполняется на одной машине состояний.

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

3. Стек целиком

Схема задаёт порядок статей: сеть разносит транзакции, консенсус решает, кто и в каком порядке пишет, данные складываются в блоки и деревья, EVM исполняет код, контракты выражают логику, слой доступа отдаёт всё это фронтенду. Справа — то, что в цепи не живёт: ключи, файлы, внешние факты, L2. Главное наблюдение: чем ниже слой, тем дороже байт и тем необратимее ошибка. Фронтенд переписывают за день, контракт после деплоя — практически никогда, транзакцию — никогда вообще. Это противоположно привычной пирамиде рисков в вебе и сдвигает тестирование и аудит влево до неприличия.

4. Нужен ли вам блокчейн: честное дерево решений

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

«Хватит подписанного лога». Если участники известны, а нужна только неотрекаемость, задача решается append-only структурой с хеш-цепочкой и подписями — это Certificate Transparency, это Git, это внутренний аудит-лог (https://courses.digitable.life/post/computer-science/16-security-basics/). Блокчейн отличается от них не «неизменяемостью» (её даёт хеш-цепочка), а решением задачи выбора одной версии истории среди конкурирующих в открытой сети. Нет выбора — нет консенсуса — нет блокчейна.

Проблема оракула. Блокчейн гарантирует согласие о состоянии, но ничего не говорит об истинности входов. Классика — «блокчейн для прослеживаемости поставок»: если человек на складе отсканировал не ту коробку, в неизменяемый реестр навсегда попадёт ложь, только теперь её нельзя исправить. Garbage in — garbage forever.

5. Жизнь одной транзакции

Этот сценарий стоит держать в голове целиком: он объединяет почти все статьи трека.

• Подпись не равна отправке. Кошелёк подписывает офлайн, сеть узнаёт о транзакции только после отправки на узел. Подписав что-то один раз, вы даёте право отправить это когда угодно потом — на этом строятся атаки с permit и approve.
• Включение в блок не равно финальности: транзакция может исчезнуть при реорганизации цепи.
• status: success не равно «получилось то, что вы хотели»: успех означает лишь, что EVM не откатила исполнение, — контракт, который молча ничего не делает, вернёт успешный статус.

6. Газ: рынок за дефицитный ресурс

Каждая операция EVM стоит фиксированное число единиц газа: сложение — 3, чтение холодного слота — 2100, запись нового слота — 22 100. Газ — не «комиссия», а мера работы, которую сеть обязана повторить на тысячах машин. Провалившееся исполнение тоже стоит денег: изменения откатились, газ списан.

По EIP-1559 (spec) цена состоит из двух частей. Base fee задаётся протоколом, зависит от заполненности предыдущего блока (шаг не более 12.5% за блок) и сжигается. Priority fee — чаевые пропозеру, именно они решают, попадёте ли вы в ближайший блок.

• Транзакции упорядочены по nonce на аккаунт. Nonce 7 не исполнится, пока не исполнится 6; застрявшая транзакция блокирует все последующие, и «разгоняют» её отправкой той же позиции nonce с большей комиссией.
• Стоимость — часть API. Функция, которая пишет в цикле по массиву пользователей, при росте массива однажды перестанет влезать в лимит газа блока (порядка 30–45 миллионов), и контракт умрёт навсегда. Это типовая причина «замороженных» протоколов. Отсюда паттерн pull-over-push: не рассылайте выплаты циклом, дайте каждому забрать своё самому.
• Мемпул публичен. Транзакция видна ботам до включения — отсюда MEV: сэндвич-атаки вокруг свопов и опережающий выкуп выгодных сделок. Защита — приватные каналы отправки и жёсткие лимиты проскальзывания.

7. Смарт-контракт за две минуты и первая уязвимость

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

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

/// @title Уязвимый банк. НЕ ИСПОЛЬЗОВАТЬ. Демонстрация reentrancy.
contract VulnerableBank {
    mapping(address => uint256) public balanceOf;

    function deposit() external payable {
        balanceOf[msg.sender] += msg.value;
    }

    function withdraw(uint256 amount) external {
        require(balanceOf[msg.sender] >= amount, "insufficient");

        // Внешний вызов ДО обновления состояния: call передаёт управление
        // получателю вместе с оставшимся газом, а баланс ещё не уменьшен.
        // Если получатель — контракт, он войдёт в withdraw повторно.
        (bool ok, ) = msg.sender.call{value: amount}("");
        require(ok, "send failed");

        balanceOf[msg.sender] -= amount;
    }
}

Атакующий — тоже контракт: его функция receive срабатывает при получении эфира и повторно входит в withdraw, пока balanceOf ещё «старый». Ровно так в июне 2016 года из The DAO вывели около 3.6 миллиона ETH, что привело к хардфорку и расколу Ethereum на ETH и ETC (разбор Ethereum Foundation). Уязвимости почти десять лет, и её продолжают находить в новых протоколах. Лечится дисциплиной Checks-Effects-Interactions плюс защёлкой:

uint256 private status = 1;                  // 1 — свободно, 2 — занято

modifier nonReentrant() {
    require(status == 1, "reentrant");
    status = 2;
    _;
    status = 1;
}

function withdraw(uint256 amount) external nonReentrant {
    // 1. Checks — все проверки в начале
    require(balanceOf[msg.sender] >= amount, "insufficient");

    // 2. Effects — состояние меняем ДО любого внешнего вызова
    balanceOf[msg.sender] -= amount;

    // 3. Interactions — внешний мир в самом конце
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "send failed");
}

С Solidity 0.8 арифметика проверяется на переполнение по умолчанию — целый класс ошибок 2018 года закрыт компилятором. С 0.8.24 защёлку дешевле держать в transient storage (tstore/tload, EIP-1153): она обнуляется в конце транзакции и не платит за постоянное хранение. И главное — не пишите защёлки сами, если есть ReentrancyGuard от OpenZeppelin: проверенный код здесь ценнее авторского (https://courses.digitable.life/post/web3/05-smart-contracts/, https://courses.digitable.life/post/web3/06-contract-security/).

8. Где на самом деле живут байты

Главный вопрос архитектуры dApp — не «какой фреймворк», а «что именно кладём в цепь». Ответ диктует экономика.

Посчитаем мегабайт в storage: 1 048 576 / 32 = 32 768 слотов, умножаем на 22 100 — около 724 миллионов газа. Это в двадцать раз больше, чем помещается в один блок целиком. Мегабайт в цепь не кладётся не потому, что дорого, а потому что физически невозможно. Отсюда единственно возможный дизайн: в цепь кладут доказательство, а не данные — корень дерева Меркла вместо списка получателей, хеш документа вместо документа, CID вместо файла.

Отдельно про блобы: EIP-4844 (spec) добавил дешёвое место для данных роллапов — блоб на 128 КиБ со своим рынком комиссий. Деталь, которую часто упускают: блобы удаляются примерно через 18 суток (4096 эпох). Это доступность данных на время оспаривания, а не вечное хранение (https://courses.digitable.life/post/web3/10-scaling/).

9. Децентрализованные хранилища: самая недооценённая часть темы

Раз данные в цепь не помещаются, вопрос «где они лежат» становится центральным. Статья https://courses.digitable.life/post/web3/09-decentralized-storage/ посвящена этому целиком, но идею надо понять сразу.

Контентная адресация

В обычном вебе адрес — это место: https://example.com/cat.png. Кто контролирует домен и сервер, тот контролирует содержимое; подменить файл, оставив адрес, тривиально. В контентной адресации имя — это хеш содержимого: изменили байт — изменилось имя. Проверка целостности встроена в саму ссылку.

Формат имени — CID (спецификация), CIDv1 самоописывающийся:

b        afybei…
│        │
│        └─ multihash: код функции (0x12 = sha2-256), длина (0x20 = 32 байта), дайджест
└─ multibase-префикс кодировки (b = base32)

полностью:  <multibase><версия><multicodec: как интерпретировать блок><multihash>

Такое имя переживёт смену алгоритма хеширования: код функции лежит внутри самого идентификатора. Плюсы приходят бесплатно: дедупликация, проверяемость, безопасный кэш. Минус ровно один и фундаментальный: имена неизменяемы. Обновили файл — получили другое имя. Мутабельность возвращают слоем указателей: IPNS (медленно) или запись contenthash в ENS (дороже, зато обновление оплачено и видно всем).

IPFS — это адресация и транспорт, а не хранилище

Частое заблуждение: «загрузил в IPFS — значит, сохранил навсегда». Нет. IPFS не даёт гарантий хранения. Он даёт способ назвать данные и найти того, у кого они есть. Файл режется на блоки (по умолчанию 256 КиБ), блоки складываются в Merkle DAG, корень которого и есть CID:

Поиск устроен через Kademlia-DHT: узел публикует provider-записи «у меня есть блок с таким CID», они живут порядка суток и требуют переанонсирования; обмен блоками — протокол Bitswap. Если единственный узел с вашим файлом ушёл в офлайн и запись протухла, файл недоступен — при том что CID остаётся валидным навсегда. Это и есть источник знаменитых мёртвых NFT-картинок.

Хранение обеспечивают пины: локальный ipfs pin add защищает блоки от сборщика мусора, платный сервис (Pinata, Filebase, web3.storage) делает то же на своей инфраструктуре. Пин у одного сервиса — такая же точка отказа, как один S3-бакет (https://courses.digitable.life/post/databases/16-object-storage/), только без SLA. Публичные шлюзы вроде ipfs.io удобны, но превращают вас в доверяющего клиента: правильно проверять хеш локально (запросить CAR-файл и верифицировать DAG самому) или держать свой узел.

Filecoin — рынок хранения с экономическими гарантиями

Filecoin закрывает дыру, которую оставляет IPFS: делает хранение обязательством под залогом.

• PoRep (Proof of Replication) — доказательство, что провайдер хранит именно вашу уникальную копию, а не ссылается на чужую; дорогая одноразовая процедура «запечатывания» сектора на 32 или 64 ГиБ.
• PoSt (Proof of Spacetime) — периодические доказательства, что копия жива. Пропустил окно — потерял залог.
• Сделки конечны и требуют продления: «положил в Filecoin» не равно «навсегда». Извлечение — отдельный рынок со своей платой, сделка на хранение не гарантирует быстрый доступ.

Спецификация. Суть: гарантия здесь экономическая, а не физическая — она стоит ровно столько, сколько стоит залог, и ломается там, где ломается экономика.

Arweave — оплата один раз за долгое хранение

• Структура данных — blockweave: блок ссылается не только на предыдущий, но и на случайный «recall»-блок из прошлого, поэтому для майнинга нужен доступ к старым данным — хранение встроено в майнинг. Доказательство — succinct proofs of random access: майнер показывает, что имеет случайно выбранный фрагмент истории.
• Экономика: платёж делится на «за первые годы» и вклад в эндаумент, из которого оплачиваются последующие столетия; расчёт опирается на допущение о снижении стоимости хранения (yellow paper).

Скажем прямо: «вечное хранение» — экономическая гипотеза, а не закон природы. Если стоимость хранения перестанет падать, а токен обесценится, эндаумент не выдержит. Это не повод не использовать Arweave — это повод не писать слово «вечно» в проектной документации.

Практический минимум для метаданных токена (https://courses.digitable.life/post/web3/08-tokens-and-standards/) — только контентно-адресуемые ссылки:

{
  "name": "Артефакт #42",
  "description": "Метаданные и изображение адресуются по хешу, а не по домену",
  "image": "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi",
  "attributes": [{ "trait_type": "Материал", "value": "бронза" }]
}

ipfs add --cid-version=1 --raw-leaves artefact.png   # современный формат CID
ipfs pin add bafybei...                              # без пина блоки удалит сборщик мусора
ipfs routing findprovs bafybei...                    # кто ещё раздаёт этот файл, кроме вас

Правила, экономящие репутацию: tokenURI указывает на ipfs://CID, а не на ваш домен; пиннинг — минимум у двух независимых провайдеров плюс свой узел; для того, что обязано жить десятилетиями, — Arweave; и никогда не обещайте «навсегда», если за это платит один ваш аккаунт в одном сервисе.

10. Модель угроз: говорим прямо

Ключи. Приватный ключ — это и есть доступ: нет восстановления, нет поддержки, нет «подтвердите личность». Потеряли seed — активы существуют, но недостижимы навсегда; отдали seed — отдали всё. Правило без исключений: seed-фразу не спрашивает никто и никогда, спросивший — мошенник, как бы ни выглядел его сайт (https://courses.digitable.life/post/web3/07-wallets-and-keys/).

Подписи вместо взлома. Большинство краж — не взлом криптографии, а честно поставленная подпись под непрочитанным: неограниченный approve, permit с бесконечным лимитом, setApprovalForAll на всю коллекцию. Контрмеры: ограниченные лимиты, регулярный отзыв разрешений, аппаратный кошелёк с читаемым разбором вызова, отдельный «горячий» адрес для экспериментов.

Баги контрактов. Публичные разборы инцидентов — лучший учебник по безопасности: reentrancy в The DAO (2016), заморозка около 513 тысяч ETH из-за случайного selfdestruct в библиотеке Parity multisig (постмортем), взломы мостов Ronin и Wormhole на сотни миллионов USD — хронологии на rekt.news. Закономерность: мосты и мультиподписи с админ-ключами обходятся отрасли дороже всего, потому что концентрируют средства и держат доверие вне протокола.

Апгрейдируемость — это централизация. Прокси с админ-ключом означает, что владелец ключа может подменить логику под вашими средствами. Иногда оправдано, но должно быть видимым: таймлок, мультиподпись с независимыми участниками, публичный адрес админа. Первый вопрос при разборе чужого протокола — «кто и как быстро может поменять код» (https://courses.digitable.life/post/web3/06-contract-security/, риски мостов — https://courses.digitable.life/post/web3/10-scaling/).

11. Где эта технология реально уместна

Работает и приносит пользу: расчёты между сторонами, которые друг другу не доверяют, без посредника и клиринга; публичный верифицируемый реестр обязательств (залоги, эскроу, условные выплаты); доказательство существования во времени — якорение хеша документа даёт неоспоримую метку «файл существовал до этого блока» за 32 байта; провенанс цифровых объектов; композиция открытых финансовых примитивов, которую нельзя собрать из закрытых API просто потому, что их владельцы не станут интегрироваться друг с другом.

Проигрывает обычным решениям:

• Персональные данные. Неизменяемый публичный реестр и право на удаление несовместимы принципиально; хеш персональных данных при малом пространстве значений подбирается перебором.
• Высокочастотные операции. Секунды задержки и десятки транзакций в секунду не конкурируют с обычной БД (https://courses.digitable.life/post/databases/00-overview/).
• Внутренние корпоративные процессы. Если у системы есть владелец, ему дешевле подписывать append-only лог; «частный блокчейн» чаще всего — распределённая БД с лишним словом в названии.
• Данные о физическом мире. Точность реестра ограничена точностью оракула, а он — обычная централизованная система со всеми её проблемами.

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

12. Карта трека

• https://courses.digitable.life/post/web3/01-blockchain-basics/ — блок, хеш-цепочка, дерево Меркла, распределённый реестр.
• https://courses.digitable.life/post/web3/02-cryptography/ — хеши, пары ключей, ECDSA, адрес из публичного ключа; рядом лежит теория чисел (https://courses.digitable.life/post/algorithms/13-number-theory/) и теория игр (https://courses.digitable.life/post/mathematics/16-game-theory/).
• https://courses.digitable.life/post/web3/03-consensus/ — PoW и PoS, финальность, форки, атака 51%.
• https://courses.digitable.life/post/web3/04-ethereum-and-evm/ — аккаунты и контракты, транзакции, устройство EVM, дерево состояния, газ.
• https://courses.digitable.life/post/web3/05-smart-contracts/ — Solidity предметно: типы, хранилище, события, тесты на Foundry, деплой.
• https://courses.digitable.life/post/web3/06-contract-security/ — reentrancy, контроль доступа, оракулы, фронтраннинг, процесс аудита.
• https://courses.digitable.life/post/web3/07-wallets-and-keys/ — BIP-39/32/44, HD-деревья, аппаратные кошельки, компрометация ключа.
• https://courses.digitable.life/post/web3/08-tokens-and-standards/ — ERC-20, ERC-721, ERC-1155: что задаёт стандарт, а что оставляет автору.
• https://courses.digitable.life/post/web3/09-decentralized-storage/ — IPFS, Filecoin, Arweave, CID, Merkle DAG, практика пиннинга.
• https://courses.digitable.life/post/web3/10-scaling/ — роллапы optimistic и ZK, блобы, шардирование данных, мосты и их риски.
• https://courses.digitable.life/post/web3/11-dapp-architecture/ — RPC и ноды, индексация событий, офчейн-компоненты и их эксплуатация (https://courses.digitable.life/post/devops/17-security-in-pipeline/).

13. Среда за пятнадцать минут

Учиться здесь на чтении бесполезно: без локальной сети и отладчика половина понятий остаётся словами. Минимальный набор — Foundry:

curl -L https://foundry.paradigm.xyz | bash && foundryup   # установка
forge init hello-web3 && cd hello-web3                     # проект с тестами на Solidity
anvil                                                      # локальная сеть, мгновенные блоки
forge test -vvv --gas-report                               # тесты и расход газа
cast block latest --rpc-url "$ETH_RPC_URL"                 # состояние публичной сети без своего узла

Первое упражнение — тест, воспроизводящий атаку из раздела 7: он превращает абстрактную «уязвимость» в красную строчку в терминале. Три правила гигиены с первого дня: экспериментировать только в локальной сети или тестнете; завести отдельный кошелёк для разработки и никогда не импортировать в него seed от кошелька со средствами; приватные ключи держать в переменных окружения или keystore, а не в коде — публичный репозиторий с ключом опустошается ботами за минуты.

14. Мини-итог

1. Публичный блокчейн — реплицированная детерминированная машина состояний с открытым членством; всё остальное следует из этого определения.
2. Он покупает верифицируемость, устойчивость к цензуре и атомарную композицию, а платит пропускной способностью, задержкой, стоимостью байта, приватностью и необратимостью.
3. Есть доверенный оператор — блокчейн не нужен; участники известны — хватает подписанного append-only лога.
4. Газ — мера работы, которую повторят тысячи машин; из неё вытекают лимиты, pull-over-push и публичность намерений.
5. Данные в цепь не помещаются физически: в неё кладут корни, хеши и CID, а байты — рядом.
6. IPFS даёт имя и способ найти, но не хранение; Filecoin превращает хранение в обязательство под залогом; Arweave продаёт долгое хранение за один платёж под экономическую гипотезу.
7. Ключ невосстановим, контракт неисправим, мост — самая дорогая точка отказа отрасли. Это проектируют заранее.

Источники

• Bitcoin: A Peer-to-Peer Electronic Cash System — с чего всё началось, девять страниц.
• Ethereum Yellow Paper — формальная спецификация EVM.
• Документация ethereum.org для разработчиков — системный вход.
• Mastering Ethereum, Antonopoulos & Wood — книга открыта целиком.
• Solidity docs, OpenZeppelin Contracts, Foundry Book.
• Building Secure Contracts от Trail of Bits и Smart Contract Best Practices.
• IPFS docs, спецификация CID, Filecoin spec, Arweave yellow paper.
• EIP-1559 и EIP-4844 — экономика комиссий и блобы.
• L2BEAT — сравнение L2 по реальным допущениям доверия, а не по маркетингу.
• rekt.news — хронология крупных взломов, читается как учебник по безопасности.

Что дальше

Как устроен блокчейн: блоки, хеш-цепочка, дерево Меркла, распределённый реестр — разбираем структуру блока по полям, считаем корень Меркла руками и выясняем, почему подмена одного байта в истории требует пересчёта всего, что было после.