Блокчейн: с нуля до профессионала

Основы блокчейна: термины, блоки, транзакции и сети

Зачем нужен блокчейн

Блокчейн — это способ хранить и обновлять общий журнал записей так, чтобы:

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

никто не мог незаметно переписать прошлые записи

правила обновления журнала были одинаковыми для всех

Важно: блокчейн — не обязательно про деньги. Это технология учёта и согласования данных в распределённой среде.

Ключевые термины

Реестр и состояние

Реестр — набор записей, которые система хранит и обновляет по правилам.

Состояние — «текущее положение дел», полученное после применения всех принятых изменений.

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

Узел и сеть

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

Сеть — набор узлов, которые обмениваются данными по правилам протокола.

Транзакция

Транзакция — сообщение с изменением, которое пользователь хочет внести в систему (например, перевод, выпуск токена, вызов функции смарт-контракта).

Обычно транзакция содержит:

данные операции (что сделать)

идентификаторы отправителя и получателя (или адрес контракта)

комиссию (плату сети)

цифровую подпись отправителя

Блок

Блок — «пакет» транзакций (или других данных), который:

имеет заголовок (служебные поля)

содержит список транзакций

ссылается на предыдущий блок

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

Хэш

Хэш — результат работы хэш-функции: короткая строка фиксированной длины, которая однозначно соответствует входным данным.

Практически важные свойства хэша:

если изменить входные данные хотя бы на 1 символ, хэш сильно меняется

по хэшу нельзя «восстановить» исходные данные (это не шифрование)

трудно подобрать другие данные с тем же хэшем

Хэш часто называют «цифровым отпечатком» данных. В блокчейнах широко используют SHA-256 (подробнее: FIPS 180-4 (SHA)).

Цифровая подпись

Цифровая подпись — способ доказать, что транзакцию создал владелец определённого секретного ключа.

Подпись даёт две ключевые гарантии:

аутентичность — транзакцию подписал владелец ключа

целостность — данные транзакции не изменялись после подписи

Консенсус

Консенсус — механизм, по которому сеть узлов выбирает, какие блоки считать правильными и в каком порядке.

Консенсус нужен, потому что:

узлы получают сообщения с задержками

часть узлов может ошибаться или вредить

сеть должна прийти к одному общему варианту истории

Как устроен блок и почему его трудно «переписать»

Ссылка на предыдущий блок

В заголовке блока обычно есть поле «хэш предыдущего блока». Это означает:

блок криптографически привязан к предыдущему

если изменить старый блок, изменится его хэш

тогда «сломается» ссылка в следующем блоке

Чтобы скрытно переписать историю, атакующему пришлось бы пересобрать не только один блок, но и все последующие, и убедить сеть принять эту версию.

!Цепочка блоков и эффект "сломанных" ссылок при изменении данных

Хэш транзакций и дерево Меркла

В блоках часто хранят не просто список транзакций, а ещё и их агрегированный «отпечаток» — корень дерева Меркла.

Идея простая:

каждой транзакции считают хэш

затем попарно объединяют и снова хэшируют

повторяют, пока не останется один хэш (корень)

Это позволяет быстро доказывать, что конкретная транзакция действительно входит в блок, не скачивая все транзакции целиком. Термин и идея широко известны как Merkle tree (справка: Bitcoin Wiki: Merkle tree).

Как живёт транзакция

От создания до включения в блок

Типичный путь транзакции:

Пользователь формирует транзакцию в кошельке или приложении.

Транзакция подписывается цифровой подписью.

Транзакция отправляется в сеть и распространяется по узлам.

Узлы проверяют базовую корректность (подпись, формат, правила протокола).

Транзакция попадает в очередь неподтверждённых транзакций (часто её называют mempool).

Производители блоков (например, майнеры или валидаторы) выбирают транзакции, собирают блок и предлагают его сети.

Сеть применяет правила консенсуса и либо принимает блок, либо отвергает.

!Жизненный цикл транзакции в блокчейн-сети

Подтверждения и финальность

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

В некоторых системах (например, в классическом Proof of Work) иногда возможны временные расхождения: сеть может на короткое время иметь две версии «последнего блока». Поэтому практическая уверенность растёт с количеством последующих блоков.

Отдельное понятие — финальность: момент, после которого откат транзакции становится невозможным или крайне маловероятным по правилам конкретной сети.

Сети блокчейна: кто с кем и как взаимодействует

Публичные и приватные сети

Публичная сеть — присоединиться может любой, правила едины для всех, данные обычно доступны всем.

Приватная сеть — доступ ограничен организацией или консорциумом.

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

Роли участников

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

Пользователь — создаёт транзакции.

Узел (full node) — хранит блоки и проверяет правила протокола.

Производитель блоков — создаёт новые блоки по правилам консенсуса (майнер/валидатор).

Протокол и правила

Протокол — это набор правил, по которым узлы:

обмениваются сообщениями

проверяют транзакции и блоки

решают, какая цепочка считается правильной

Если разные узлы используют разные правила, сеть может разделиться на две несовместимые сети. Такое событие называют форком.

Консенсус на уровне интуиции

Proof of Work и Proof of Stake

Два популярных подхода:

Proof of Work (PoW) — право предложить блок «зарабатывается» вычислительной работой. Классический пример — Bitcoin (подробнее: Bitcoin: A Peer-to-Peer Electronic Cash System).

Proof of Stake (PoS) — право предложить блок связано с долей участия (stake), которую блок-производитель «ставит под ответственность» по правилам протокола. Общее введение по Ethereum и его устройству: Ethereum documentation: Introduction.

Эта тема будет подробно разбираться дальше в курсе. На данном этапе важно понять: консенсус — это правила выбора истории и защита от переписывания.

Главное: как всё складывается в одну картину

Блокчейн можно представить как систему из четырёх уровней:

данные (транзакции)

упаковка данных (блоки)

связывание блоков (хэши и ссылки)

согласование (консенсус в сети узлов)

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

Краткий словарь

| Термин | Простое объяснение | |---|---| | Блокчейн | Цепочка блоков с данными, согласованная сетью | | Транзакция | Сообщение с изменением, подписанное отправителем | | Блок | Контейнер транзакций со ссылкой на прошлый блок | | Хэш | «Отпечаток» данных фиксированной длины | | Узел | Участник сети, который хранит/проверяет/передаёт данные | | Консенсус | Правила, по которым сеть выбирает корректную историю | | Подтверждение | Факт включения транзакции в блок | | Финальность | Момент, после которого откат практически невозможен | | Форк | Разделение на разные правила или разные версии истории |

Криптография и устройство блокчейна: хэши, подписи, Merkle-деревья

Связь с предыдущей темой

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

хэши связывают данные и «ломают» историю при любой правке

цифровые подписи доказывают авторство транзакций

Merkle-деревья позволяют быстро доказывать, что транзакция входит в блок

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

Что такое криптография в блокчейне и зачем она нужна

Криптография в блокчейне решает три практические задачи:

целостность: данные нельзя незаметно изменить

подтверждение авторства: сеть может проверить, что транзакцию подписал владелец ключа

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

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

Хэш-функции

Идея хэша простыми словами

Хэш-функция берёт любые данные (текст, файл, транзакцию, блок) и превращает их в короткую строку фиксированной длины, которая служит «отпечатком» этих данных.

Например, в блокчейнах часто используется SHA-256. Это стандарт, описанный в документе NIST: FIPS 180-4 (Secure Hash Standard).

Какие свойства хэша важны для блокчейна

Чтобы хэш был полезен в блокчейне, важны свойства:

эффект лавины: маленькое изменение входных данных приводит к полностью другому хэшу

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

устойчивость к подделке: трудно найти другие данные с тем же хэшем

Эти свойства обеспечивают «сигнализацию о подмене»: если кто-то поменял транзакцию или блок, хэш изменится, и сеть это заметит.

!Демонстрация эффекта лавины у хэш-функций

Где именно используются хэши в блокчейне

Хэши встречаются почти везде:

идентификатор транзакции: часто это хэш данных транзакции

ссылка на предыдущий блок: в заголовке нового блока хранится хэш предыдущего

Merkle-корень: один хэш «компактно описывает» набор транзакций в блоке

Цифровые подписи

Зачем подпись нужна транзакции

Если блокчейн открыт, любой может отправить в сеть сообщение «переведи мне деньги». Поэтому сеть должна отличать:

транзакцию, созданную владельцем средств

подделку от постороннего

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

Ключевая пара: приватный и публичный ключ

У пользователя есть пара ключей:

приватный ключ: секрет, которым подписывают

публичный ключ: открытая часть, которой проверяют подпись

Ключевая идея: имея публичный ключ, можно проверить подпись, но нельзя «вычислить» приватный ключ.

Как подпись проверяется (без математики)

Процесс обычно выглядит так:

Кошелёк берёт данные транзакции и считает их хэш.

Кошелёк создаёт подпись приватным ключом.

Узлы сети:

- пересчитывают хэш транзакции - проверяют подпись публичным ключом отправителя

Если подпись не сходится, транзакцию отклоняют.

Это даёт две гарантии:

аутентичность: подписал владелец приватного ключа

целостность: если изменить транзакцию после подписи, проверка подписи перестанет проходить

Какие алгоритмы подписей встречаются в блокчейнах

Разные сети используют разные схемы, но самая распространённая идея: подпись на эллиптических кривых.

В Bitcoin исторически используется ECDSA на кривой secp256k1. Описание параметров кривых есть в стандарте SECG: SEC 2: Recommended Elliptic Curve Domain Parameters.

В ряде современных систем встречаются EdDSA (например, Ed25519). Формальное описание есть в IETF: RFC 8032 (EdDSA).

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

Как адрес связан с ключами (интуитивно)

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

Практический смысл:

адрес короче и удобнее, чем публичный ключ

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

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

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

Merkle-деревья

Зачем нужно Merkle-дерево

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

Merkle-дерево решает задачу: как получить один короткий «отпечаток» от большого списка транзакций и уметь доказывать включение одной транзакции.

Термин широко используется в контексте Bitcoin: Bitcoin Wiki: Merkle tree.

Как строится Merkle-дерево

Идея очень простая:

Для каждой транзакции считают хэш. Это «листья» дерева.

Листья объединяют попарно и хэшируют вместе, получая «родителей».

Повторяют, пока не останется один хэш.

Этот финальный хэш называется Merkle-root (корень Меркла). Он помещается в заголовок блока.

!Схема Merkle-дерева и доказательства включения транзакции

Что такое доказательство включения (Merkle proof)

Merkle proof — это небольшой набор хэшей, который позволяет проверить, что конкретная транзакция входит в блок.

Смысл:

вам дают хэш транзакции и несколько «соседних» хэшей по пути вверх

вы пересчитываете хэши до корня

если получившийся корень совпал с Merkle-root в заголовке блока, транзакция действительно внутри

Почему это выгодно:

доказательство маленькое по размеру

проверка быстрая

не нужно скачивать все транзакции блока

Это особенно важно для лёгких клиентов (например, мобильных кошельков), которые не хранят весь блокчейн.

Как эти элементы собираются внутри блока

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

Типичные криптографические элементы заголовка блока

| Элемент | Что это | Зачем это нужно | |---|---|---| | Хэш предыдущего блока | «Отпечаток» прошлого блока | Связывает цепочку и защищает историю от незаметной правки | | Merkle-root | «Отпечаток» всех транзакций в блоке | Позволяет доказывать включение транзакции и фиксирует состав блока | | Хэш самого блока | Хэш заголовка (или заголовка + часть данных, по правилам сети) | Даёт идентификатор блока и участвует в правилах консенсуса |

Важно: точный набор полей зависит от конкретного блокчейна, но логика почти всегда одинакова.

Частые ошибки и правильная интуиция

Хэширование — не шифрование

Хэш нельзя «расшифровать» обратно, потому что это не шифр. Хэш — одностороннее преобразование.

Подпись не делает данные секретными

Подпись подтверждает авторство и защищает от незаметной правки, но она не скрывает содержимое транзакции.

Merkle-root фиксирует набор транзакций

Если заменить хотя бы одну транзакцию в блоке:

изменится её хэш

изменятся хэши выше по дереву

изменится Merkle-root

заголовок блока перестанет соответствовать тому, что видят другие узлы

Главное, что нужно запомнить

Хэш — короткий «отпечаток» данных: меняем данные, меняется хэш.

Цифровая подпись — доказательство, что транзакцию создал владелец приватного ключа.

Merkle-дерево — способ «свернуть» список транзакций в один корень и выдавать компактные доказательства включения.

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

Мини-словарь

| Термин | Простое объяснение | |---|---| | Хэш-функция | Делает «отпечаток» данных фиксированной длины | | Коллизия | Ситуация, когда разные данные дают одинаковый хэш | | Приватный ключ | Секрет, которым подписывают транзакции | | Публичный ключ | Открытая часть, которой проверяют подпись | | Цифровая подпись | Проверяемое доказательство авторства и целостности | | Merkle-root | Один хэш, представляющий набор транзакций в блоке | | Merkle proof | Набор хэшей для доказательства включения транзакции |

> «We define a digital signature scheme to be secure if it is computationally infeasible for an attacker to forge a signature.» RFC 8032 (EdDSA)

Консенсус и экономика: PoW, PoS, стимулы, комиссии и токены

Связь с предыдущими темами

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

За это отвечает сочетание двух вещей:

консенсус: как сеть выбирает единую историю блоков

экономика: какие награды и штрафы делают атаки дорогими, а честное поведение выгодным

Если криптография отвечает на вопрос "можно ли проверить", то консенсус и экономика отвечают на вопрос "зачем кому-то соблюдать правила".

Зачем блокчейну экономические стимулы

В публичной сети любой может:

подключить узел

отправлять транзакции

пытаться производить блоки

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

Главная проблема, которую решает консенсус в публичной среде:

как договориться об одном порядке транзакций без центрального администратора

А главная проблема, которую решает экономика:

как сделать так, чтобы атаковать было невыгодно

> “We propose a solution to the double-spending problem using a peer-to-peer network.” Bitcoin: A Peer-to-Peer Electronic Cash System

Ключевая идея: безопасность оплачивается

В блокчейне безопасность обычно финансируется двумя потоками:

награда за блок: новые монеты, которые протокол выпускает (эмиссия)

комиссии: плата пользователей за включение транзакций

Удобная упрощённая модель:

Где:

— бюджет безопасности за период времени (сколько в сумме получают производители блоков)

— награда протокола (эмиссия)

— комиссии пользователей

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

Роли в консенсусе

Чтобы дальше не запутаться в терминах, зафиксируем роли:

узел (full node) проверяет правила и хранит историю

производитель блоков предлагает новые блоки

пользователь отправляет транзакции и платит комиссии

Важно: производитель блоков может менять название в разных системах:

в PoW часто говорят майнер

в PoS часто говорят валидатор

Proof of Work

Интуиция PoW

Proof of Work (PoW) — это консенсус, где право предложить блок получают участники, которые первыми выполнили вычислительную задачу.

Свойства, которые важны на практике:

задача дорого считается (нужны электричество и оборудование)

результат легко проверяется (любой узел быстро убеждается, что работа сделана)

Как PoW связывает безопасность и затраты

Если кто-то хочет переписать историю, ему нужно:

пересобрать нужные блоки

сделать это быстрее, чем остальная сеть продолжает добавлять новые блоки

Практическое следствие: для успешной атаки обычно нужны огромные ресурсы.

Что получает майнер

Экономическая мотивация майнера обычно состоит из двух частей:

награда за блок (эмиссия)

комиссии за транзакции, включённые в блок

Типовая угроза: атака большинства

Часто это упрощают до термина "атака 51%": если атакующий контролирует большую долю суммарной мощности, ему легче навязать сети свою версию истории.

Важно уточнить простыми словами, что именно становится возможным:

атакующий может попытаться откатить свои же недавние платежи (двойная трата)

И что обычно не становится возможным в корректно устроенной системе:

создать транзакцию от чужого имени без чужой подписи (криптография не позволяет)

Подробнее о PoW в контексте Bitcoin: Bitcoin: A Peer-to-Peer Electronic Cash System

!Схема, показывающая разницу между PoW и PoS на уровне процесса

Proof of Stake

Интуиция PoS

Proof of Stake (PoS) — это консенсус, где право предлагать блоки и подтверждать их связано не с вычислениями, а с долей участия (stake).

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

Почему стейк работает как залог

Логика очень близка к залогу в реальной жизни:

если действуешь честно, получаешь вознаграждение

если нарушаешь правила, теряешь часть залога

Штраф, при котором часть стейка списывается, часто называют slashing. Это слово означает "срезание" залога за доказанное нарушение.

Что получает валидатор

В PoS мотивация валидатора обычно включает:

вознаграждение протокола (эмиссия или её часть)

комиссии (по правилам конкретной сети)

А также важный элемент:

риск штрафа при нарушении правил

Официальное введение в PoS в Ethereum: Ethereum documentation: Proof-of-stake

Чем PoS и PoW реально отличаются экономически

| Вопрос | PoW | PoS | |---|---|---| | Главный ограничитель | электричество и оборудование | капитал в монете сети (стейк) | | Цена атаки | нужно купить и содержать мощность | нужно купить и рискнуть стейком | | Что можно "сжечь" у атакующего | внешние затраты (электричество) | внутренний залог (slashing) |

Оба подхода пытаются добиться одного: сделать атаку дороже честной игры.

Комиссии: зачем они нужны и как работают

Комиссии в блокчейне — это не просто "плата за перевод". Они решают сразу несколько задач.

Задача комиссий

Комиссии нужны, чтобы:

защищать сеть от спама ("бесконечных" бесплатных транзакций)

распределять ограниченное место в блоке (кто платит больше, того включают быстрее)

частично или полностью оплачивать безопасность, особенно когда эмиссия снижается

Как формируется комиссия на практике

В упрощённой модели пользователь выбирает комиссию, а производитель блока выбирает транзакции по выгоде.

Типичная логика:

пользователь отправляет транзакцию с комиссией

транзакция попадает в очередь неподтверждённых (часто называют mempool)

производитель блока набирает транзакции, обычно отдавая приоритет более дорогим

блок публикуется, сеть проверяет правила

Почему комиссии бывают нестабильными

Комиссия обычно растёт, когда одновременно выполняются два условия:

много желающих отправить транзакции прямо сейчас

ограниченный размер блока или ограниченная скорость обработки

Это похоже на пробку на дороге: когда машин больше, чем пропускная способность, цена "проезда" временем или деньгами растёт.

!Иллюстрация, почему комиссии зависят от спроса и ограничения размера блока

Пример подхода к комиссиям: базовая комиссия и чаевые

В некоторых сетях комиссия может делиться на части. Например, в Ethereum после EIP-1559 выделяют:

base fee: базовая часть, которая по правилам протокола может уничтожаться ("сжигаться")

tip: чаевые, которые получают производители блоков

Смысл такого дизайна:

сделать комиссии более предсказуемыми

уменьшать предложение монеты при высокой активности (через сжигание base fee)

Источник: EIP-1559

Токены: что это такое и почему почти всегда есть "монета сети"

Нативная монета

Почти в любой публичной сети есть нативная монета (её часто тоже называют токеном). Она нужна, чтобы:

платить комиссии

выдавать награды производителям блоков

в PoS использоваться как стейк

Токены поверх блокчейна

Помимо нативной монеты, в сетях со смарт-контрактами можно выпускать токены поверх основной сети. Простейшие категории:

платёжные токены: используются как средство расчёта внутри продукта

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

обеспеченные токены: заявляют связь с внешним активом (например, валютой)

Важно: название категории не гарантирует реальную ценность. Важны правила выпуска, права владельца и ограничения.

Экономика протокола: эмиссия, инфляция и сжигание

Эмиссия

Эмиссия — это выпуск новых единиц нативной монеты по правилам протокола.

Зачем она нужна:

чтобы платить награду за обеспечение безопасности, особенно на ранних этапах сети

Инфляция

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

Важно простое правило:

инфляция зависит не от цены, а от изменения предложения монеты

Сжигание

Сжигание — механизм, при котором часть монет уничтожается по правилам протокола.

Зачем сжигание может вводиться:

чтобы компенсировать эмиссию

чтобы связать использование сети (комиссии) с уменьшением предложения монеты

Как экономика защищает консенсус

Соберём всё в одну картину.

Что делает атаку дорогой

Экономическая защита строится на том, что атакующему нужно либо:

в PoW: вложиться в огромные вычислительные ресурсы и электричество

в PoS: купить большую долю монеты и рискнуть потерять залог при нарушении правил

Почему честное поведение обычно выгоднее

У честного участника есть понятная стратегия:

стабильно получать вознаграждения

не рисковать штрафами

не разрушать доверие к сети, в активе которой он сам заинтересован

А у атакующего стратегия часто выглядит так:

понести большие затраты или рискнуть большим залогом

получить краткосрочную выгоду

при этом снизить доверие к сети и ценность полученной выгоды

Частые ошибки в понимании

"Комиссии идут разработчикам"

В типичном публичном блокчейне комиссии распределяются по правилам протокола:

производителям блоков

иногда частично сжигаются

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

"PoS — это просто богатые становятся богаче"

Риск централизации существует в любой системе, где есть эффект масштаба. Но в PoS дополнительно есть:

штрафы за нарушения

конкуренция валидаторов

возможность делегирования или объединения стейка (в зависимости от сети)

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

"Если у меня есть монеты, я могу переписать историю"

Монеты сами по себе не дают права менять историю. Нужны правила консенсуса:

в PoW — преимущество в мощности

в PoS — участие валидаторов и их стейк по правилам протокола

И в обоих случаях узлы всё равно проверяют корректность блоков: подписи, ссылки на предыдущие блоки, правила транзакций.

Главное, что нужно запомнить

Консенсус выбирает единую историю блоков, а экономика делает атаки невыгодными.

PoW опирается на внешние затраты (вычисления и электричество), PoS — на внутренний залог (стейк) и штрафы.

Комиссии нужны для защиты от спама, распределения места в блоке и финансирования безопасности.

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

Безопасность сети в реальности часто можно понимать как поток выплат: .

Мини-словарь

| Термин | Простое объяснение | |---|---| | Proof of Work | Консенсус через вычислительную работу | | Proof of Stake | Консенсус через залог в монете сети | | Майнер | Производитель блоков в PoW | | Валидатор | Производитель блоков в PoS | | Стейк | Заблокированный залог для участия в PoS | | Slashing | Штраф: списание части стейка за нарушение | | Комиссия | Плата за включение транзакции в блок | | Эмиссия | Выпуск новых монет протоколом | | Сжигание | Уничтожение части монет по правилам протокола |

Смарт-контракты и dApps: архитектура, стандарты и разработка

Связь с предыдущими темами курса

Ранее мы разобрали:

как данные попадают в блокчейн через транзакции и блоки

почему хэши, подписи и Merkle-деревья делают подмену заметной

как консенсус (PoW/PoS) и комиссии стимулируют честное поведение

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

Что такое смарт-контракт

Смарт-контракт — это программа, размещённая в блокчейне, которая:

хранит данные (своё состояние)

принимает вызовы через транзакции

выполняет код одинаково на всех узлах

меняет состояние сети строго по правилам протокола

Важно: смарт-контракт не «умный» сам по себе. Он детерминированный: при одинаковом входе и одинаковом состоянии он должен давать одинаковый результат на всех узлах. Именно так сеть может прийти к одному итогу.

Источник для общего понимания: Документация Ethereum: Smart contracts.

Чем смарт-контракт отличается от обычного серверного кода

| Характеристика | Обычный сервер | Смарт-контракт | |---|---|---| | Кто исполняет код | Один владелец сервера | Сеть узлов по правилам протокола | | Можно ли “починить на лету” | Обычно да | Обычно нет, код трудно менять | | Стоимость выполнения | Платит владелец сервера | Платит отправитель транзакции (комиссия) | | Доступ к внешнему миру | Прямой (HTTP, базы данных) | Прямого нет, только данные блокчейна |

Модель работы: транзакция вызывает код

В предыдущих темах транзакция была “сообщением об изменении”. В мире смарт-контрактов это выглядит так:

Пользователь подписывает транзакцию в кошельке.

Транзакция содержит адрес контракта и данные вызова (какую функцию вызвать и с какими параметрами).

Узлы исполняют код контракта.

Если выполнение корректное и комиссия оплачена, состояние обновляется и попадает в новый блок.

!Как транзакция приводит к выполнению смарт-контракта и изменению состояния

Базовые понятия, без которых нельзя писать dApps

Адрес и аккаунт

Адрес — короткий идентификатор в сети, на который можно отправлять транзакции и активы.

Во многих сетях со смарт-контрактами есть два типа аккаунтов:

аккаунт пользователя — управляется приватным ключом (подписью)

аккаунт контракта — управляется кодом контракта

Пользовательский аккаунт может вызвать контракт, а контракт может вызывать другие контракты.

Состояние контракта

Состояние — данные, которые контракт хранит “внутри себя” в блокчейне.

Примеры состояния:

балансы токена

список владельцев NFT

параметры протокола (комиссии, роли)

Ключевая идея: состояние контракта обновляется только при успешной транзакции.

Газ и комиссия

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

Газ — это единицы “стоимости вычислений”, которые нужны для выполнения операций контракта.

Практический смысл:

сложнее вычисления и больше запись в состояние — больше газа

пользователь платит комиссию, чтобы покрыть газ

если газа не хватило, выполнение откатывается (состояние не меняется), но комиссия за попытку обычно всё равно списывается

Официальное введение: Документация Ethereum: Gas and fees.

ABI: как фронтенд “разговаривает” с контрактом

ABI (Application Binary Interface) — это описание функций и событий контракта в стандартизированном формате.

Зачем нужно ABI:

фронтенд знает, как сформировать данные вызова функции

библиотека (например, ethers.js) может декодировать ответы и события

Если совсем просто: ABI — это “словарь”, который объясняет, как правильно вызвать контракт.

Справка: Документация Solidity: ABI specification.

События (events) и логи

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

Зачем события используют в dApps:

события удобны для поиска истории действий (кто, что, когда сделал)

события проще индексировать внешними сервисами

Важно: логи отличаются от состояния.

состояние — это то, что контракт хранит и может читать внутри себя

логи — это “след выполнения”, который удобно читать снаружи

Что такое dApp и из чего она состоит

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

Типичная архитектура dApp:

смарт-контракты — правила и активы

фронтенд — сайт/мобильное приложение

кошелёк — инструмент подписи транзакций (например, расширение браузера)

RPC-провайдер — узел или сервис, через который фронтенд отправляет запросы в сеть

индексатор — сервис, который ускоряет поиск по событиям и истории

оракул — механизм доставки внешних данных в блокчейн (если нужно)

!Типовая архитектура dApp и роли компонентов

Зачем нужен индексатор

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

Индексатор — это внешний сервис, который:

читает блоки и события

строит удобные таблицы и API

отдаёт фронтенду быстрые ответы

Популярный подход — использовать готовые решения или писать свой индексатор. Пример экосистемы: The Graph documentation.

Зачем нужен оракул

Смарт-контракт сам по себе не может безопасно “сходить в интернет” и проверить курс доллара или счёт матча. Причина простая: разные узлы увидят разные ответы, и консенсус сломается.

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

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

Стандарты токенов: почему без них dApps не совместимы

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

В Ethereum стандарты публикуются как EIP.

ERC-20: взаимозаменяемые токены

ERC-20 обычно используют для “обычных” токенов, где все единицы одинаковые.

Идея стандарта:

есть функция проверки баланса

есть перевод токенов

есть механизм разрешений “разрешаю контракту тратить мои токены”

Источник: EIP-20: ERC-20 Token Standard.

ERC-721: уникальные токены (NFT)

ERC-721 — стандарт для NFT, где каждый токен уникален и имеет свой идентификатор.

Зачем это нужно:

право собственности на конкретный уникальный токен

совместимость с маркетплейсами и кошельками

Источник: EIP-721: ERC-721 Non-Fungible Token Standard.

ERC-1155: много токенов в одном контракте

ERC-1155 позволяет хранить сразу “наборы” токенов разных типов в одном контракте.

Практическая польза:

экономия газа при массовых операциях

удобно для игр и коллекций

Источник: EIP-1155: Multi Token Standard.

Как выбрать стандарт

| Сценарий | Обычно выбирают | |---|---| | Валюта приложения, баллы, governance-токен | ERC-20 | | Коллекция уникальных предметов | ERC-721 | | Игра с множеством типов предметов и партиями | ERC-1155 |

Разработка смарт-контрактов: минимальный жизненный цикл

Ниже — практичный, “инженерный” процесс разработки.

Проектирование

Сначала фиксируют требования:

какие действия должен уметь делать пользователь

какие роли существуют (владелец, админ, любой)

какие данные нужно хранить в состоянии

какие события нужно публиковать для фронтенда

Полезная привычка: формулировать правила как “контракт обязан запрещать X и разрешать Y”.

Реализация на Solidity

В экосистеме Ethereum самый распространённый язык — Solidity.

Справка: Документация Solidity.

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

Пример стандартных реализаций: OpenZeppelin Contracts.

Компиляция и деплой

После написания код:

компилируют (получают байткод)

отправляют транзакцию “создания контракта”

получают адрес контракта в сети

Тестирование

Тесты проверяют два слоя:

что логика работает в нормальных сценариях

что защита держит плохие сценарии (не тот пользователь, неверные данные, попытка обмана)

В смарт-контрактах тестирование особенно важно, потому что ошибки часто стоят денег и репутации.

Верификация кода

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

Пример сервиса: Etherscan.

Типовые уязвимости и как о них думать

Ниже — базовые риски, которые нужно понимать ещё до “профи-уровня”.

Reentrancy: повторный вход

Суть: контракт отправляет внешнему контракту активы или делает внешний вызов, а внешний контракт вызывает его обратно “раньше времени”, пока внутреннее состояние ещё не приведено в порядок.

Базовая защита на уровне мышления:

сначала обновляй состояние, потом делай внешние вызовы

используй готовые защитные примитивы из библиотек

Справка от OpenZeppelin: OpenZeppelin: ReentrancyGuard.

Контроль доступа

Самая частая ошибка: функция, которая должна быть доступна только администратору, случайно доступна всем.

Практическая рекомендация:

явно описывай роли

тестируй “кто угодно не может сделать X”

Переполнения и безопасная математика

В современных версиях Solidity многие переполнения целых чисел проверяются автоматически, но понимать риск всё равно полезно.

Front-running и MEV (очень кратко)

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

Простая интуиция:

если логика зависит от “кто первый”, её могут атаковать

аукционы, DEX и ликвидации особенно чувствительны

Обновляемость контрактов: почему это сложно

Код контракта в блокчейне обычно неизменяем. Но продуктам нужны обновления. Отсюда появляются паттерны апгрейда.

Прокси-паттерн (интуитивно)

Идея:

прокси-контракт хранит состояние и принимает вызовы

он перенаправляет вызовы в контракт-реализацию с логикой

адрес реализации можно поменять, получив “обновление” логики

Главные риски:

ошибка в правах на апгрейд превращается в полный захват

несовместимость хранения данных (storage layout) ломает состояние

!Как работает прокси-апгрейд и почему состояние хранится в прокси

Практическая отправная точка: OpenZeppelin: Upgrades.

Практический чек-лист перед запуском dApp

Проверь контроль доступа для критичных функций.

Покрой тестами основные сценарии и запреты.

Продумай события: фронтенду проще жить на логах.

Оцени угрозы front-running, если есть “гонка” транзакций.

Используй проверенные библиотеки (например, OpenZeppelin) вместо самописной криптологии.

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

Главное, что нужно запомнить

Смарт-контракт — детерминированный код в блокчейне, который меняет состояние через транзакции.

dApp почти всегда состоит из контрактов + фронтенда + кошелька + RPC, часто дополняется индексатором и оракулом.

Газ и комиссии ограничивают вычисления и защищают сеть от спама.

ABI и события — основа связи “контракт ↔ интерфейс”.

Стандарты ERC (ERC-20, ERC-721, ERC-1155) дают совместимость токенов с экосистемой.

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

Мини-словарь

| Термин | Простое объяснение | |---|---| | Смарт-контракт | Программа в блокчейне, исполняемая сетью | | dApp | Приложение, где ключевая логика закреплена в смарт-контрактах | | Газ | Мера стоимости вычислений для выполнения контракта | | ABI | Описание, как вызывать функции контракта | | Событие (event) | Лог-запись, удобная для чтения и индексации | | Индексатор | Внешний сервис для быстрых запросов по истории и событиям | | Оракул | Доставка внешних данных в блокчейн | | ERC-20 | Стандарт взаимозаменяемых токенов | | ERC-721 | Стандарт NFT | | ERC-1155 | Стандарт набора разных токенов в одном контракте |

Безопасность и масштабирование: уязвимости, аудит, L2 и мосты

Связь с предыдущими темами курса

Ранее мы разобрали:

как устроены транзакции, блоки и сети

почему хэши, подписи и Merkle-деревья позволяют проверять целостность

как консенсус и экономика делают переписывание истории дорогим

как смарт-контракты и dApps выполняются в сети и почему ошибки в них опасны

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

Что именно нужно защищать в блокчейн-проектах

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

Обычно выделяют несколько уровней, где возникают риски:

смарт-контракт: ошибки в коде и логике, неправильные права доступа

фронтенд и кошелёк: подмена адресов, фишинг, вредоносные подписи

инфраструктура: RPC-провайдеры, индексаторы, админ-ключи, CI/CD

экономика протокола: манипуляции ценой, MEV, атаки на ликвидность

кроссчейн-интеграции: мосты и обёрнутые активы

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

Почему уязвимости смарт-контрактов особенно опасны

Причины, по которым безопасность в смарт-контрактах сложнее, чем в обычной разработке:

неизменяемость: задеплоенный контракт часто нельзя просто “быстро поправить”, особенно если в нём лежат активы

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

композиционность: контракты вызывают другие контракты, а поведение внешнего контракта может быть неожиданным

стоимость ошибок: баг часто превращается в прямую финансовую потерю

Практический вывод: безопасность — это не “проверим перед релизом”, а процесс на всём жизненном цикле.

Частые уязвимости и правильная интуиция

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

Reentrancy

Reentrancy (повторный вход) — ситуация, когда контракт делает внешний вызов (например, отправляет ETH или вызывает другой контракт), а внешний контракт успевает вызвать исходный контракт обратно до того, как исходный контракт обновил своё состояние.

Типовая защита:

обновлять состояние до внешних вызовов (checks-effects-interactions)

использовать защиту от повторного входа

Справка: OpenZeppelin ReentrancyGuard

Ошибки контроля доступа

Контроль доступа — это правила “кто может вызывать какую функцию”. Самые дорогие ошибки здесь:

админ-функция доступна всем

роль задана неверно

критичные параметры можно поменять без ограничений

Типовая защита:

явные роли и модификаторы доступа

отдельные админ-аккаунты и мультиподпись

timelock для опасных операций (задержка перед исполнением)

Ошибки при внешних вызовах

Контракты часто взаимодействуют друг с другом. Типовые проблемы:

игнорирование результата вызова (не проверили success)

доверие к внешнему контракту как к “честному”

неожиданные побочные эффекты

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

Проблемы с оракулами и ценой

Смарт-контракт часто опирается на “цену” (например, для залога, ликвидаций, обмена). Если источник цены можно манипулировать, то можно сломать экономику протокола.

Типовые сценарии:

цена берётся из DEX-пула с низкой ликвидностью

цена берётся “прямо сейчас”, без усреднения

оракул централизован и может вернуть неверные данные

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

Front-running и MEV

Front-running — когда кто-то видит вашу транзакцию в очереди неподтверждённых транзакций и пытается вставить свою транзакцию раньше, чтобы заработать.

MEV (Maximal Extractable Value) — более общее понятие: ценность, которую можно извлечь, меняя порядок/включение транзакций в блок.

Где особенно опасно:

DEX и обмены

ликвидации

аукционы

любые механики “кто первый, тот и выиграл”

Ошибки апгрейдов и прокси

Если контракт обновляемый (через прокси), появляется новый класс рисков:

кто контролирует право апгрейда

можно ли украсть право апгрейда

совместимы ли данные в хранилище (storage) между версиями

Правильная интуиция: апгрейд — это супер-админ доступ. Его надо защищать сильнее всего.

Сводная таблица уязвимостей

| Класс проблемы | Простая причина | Типовая защита | |---|---|---| | Reentrancy | внешний вызов до обновления состояния | порядок действий + guard | | Контроль доступа | “не тот” может вызвать функцию | роли, мультиподпись, timelock | | Oracle/price | цена или данные манипулируемы | надёжный оракул, усреднение | | Front-running/MEV | транзакции видны до включения | дизайн без гонок, commit-reveal | | Апгрейды | захват прав или ломание storage | строгие права, проверки, процессы |

Источник с практическими рекомендациями по разработке и безопасности: ConsenSys Smart Contract Best Practices

Что такое аудит смарт-контракта и что он даёт

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

Важно понимать границы:

аудит снижает риск, но не даёт “гарантию отсутствия багов”

качество аудита зависит от времени, доступа к контексту и квалификации

Что обычно входит в аудит

Уточнение модели угроз

Проверка архитектуры

Ручной разбор критичных функций

Поиск уязвимостей по известным классам

Проверка тестов и покрытия сценариев

Рекомендации по исправлениям и повторная проверка

Типовые артефакты хорошего процесса

понятные требования: что разрешено и что запрещено

список инвариантов: что никогда не должно нарушаться (например, сумма балансов)

тесты на плохие сценарии

мониторинг после деплоя

Практика безопасной разработки: минимальный жизненный цикл

Ниже — рабочий “скелет” процесса, который подходит большинству команд.

Проектирование

- формулируем роли, права, ограничения - фиксируем инварианты и экономические допущения

Реализация

- используем проверенные библиотеки - избегаем самописной криптографии и сложных апгрейдов без необходимости

Тестирование

- позитивные сценарии - негативные сценарии (кто не должен иметь доступа)

Ревью и аудит

- внутренний код-ревью - внешний аудит (если есть активы/TVL/пользователи)

Запуск и эксплуатация

- мультиподпись для админ-операций - timelock для критичных изменений - мониторинг событий и аномалий

Почему блокчейны плохо масштабируются “в лоб”

В L1 есть ограничение: каждый узел должен иметь возможность проверить и исполнить блок.

Если увеличить пропускную способность слишком сильно, то:

растут требования к железу

меньше людей смогут запускать узлы

сеть станет более централизованной

Поэтому масштабирование часто строят как: часть работы переносим за пределы L1, а L1 используем как судью и якорь безопасности.

Простейшая модель пропускной способности

Можно мыслить так:

Где:

— транзакций в секунду

— сколько транзакций помещается в один блок (ограничено размером блока или газом)

— среднее время между блоками в секундах

Интуиция: чтобы увеличить , можно увеличить или уменьшить , но оба варианта упираются в устойчивость сети и требования к узлам.

Что такое L2 и какие бывают подходы

L2 (Layer 2) — это система, которая обрабатывает транзакции “сверху” L1 и периодически фиксирует результат в L1 так, чтобы пользователи могли опираться на безопасность базовой сети.

Есть несколько семейств решений:

state channels (каналы состояния): участники проводят множество операций вне сети и иногда фиксируют итог в L1

sidechains (сайдчейны): отдельная сеть со своим консенсусом, связанная с L1 мостом

rollups (роллапы): транзакции исполняются вне L1, но данные и проверяемость завязаны на L1

На практике в экосистеме Ethereum rollups стали основным направлением L2, потому что они ближе к модели минимума доверия по сравнению с сайдчейнами.

Справка: Ethereum documentation: Layer 2 scaling

!Как L2-роллап опирается на L1 для безопасности

Rollups: идея “выполняем снаружи, доказываем внутри”

Rollup — это L2, который:

исполняет транзакции вне L1 (дешевле и быстрее)

публикует в L1 достаточно информации, чтобы L1 мог выступать арбитром

Ключевой вопрос безопасности rollup: может ли пользователь восстановить и защитить свои средства, даже если операторы L2 ведут себя плохо?

Optimistic rollups

Optimistic rollup работает по принципу “считаем, что batch корректен, пока никто не доказал обратное”.

Как это выглядит концептуально:

оператор публикует результат (например, новый корень состояния) в L1

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

если есть доказательство ошибки, применяется механизм fraud proof (доказательство мошенничества)

Компромисс:

вывод средств на L1 может быть медленнее из-за периода оспаривания

Справка: Ethereum documentation: Optimistic rollups

ZK rollups

ZK rollup публикует криптографическое доказательство корректности вычислений (validity proof).

Интуиция:

оператор не просто “заявляет” новый результат

он прикладывает доказательство, что переход состояния корректен по правилам

Компромиссы:

сложность разработки и вычислительная нагрузка на генерацию доказательств

Справка: Ethereum documentation: ZK-rollups

Доступность данных

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

Правильная интуиция:

если данные недоступны, пользователи могут оказаться “запертыми” в L2, даже если формально есть якорь в L1

Мосты: зачем они нужны и почему их часто взламывают

Мост (bridge) — механизм передачи активов или сообщений между двумя сетями.

Простейший сценарий: перенести токен из сети A в сеть B.

Обычно это делают через модель “заблокировать и выпустить обёртку”:

в сети A токены блокируются в контракте моста

в сети B выпускается “обёрнутый” токен, который представляет заблокированный актив

при возврате процесс идёт в обратную сторону

!Базовая схема моста: lock/mint и burn/release

Почему мосты — зона повышенного риска

Мост соединяет две разные системы, а значит добавляет:

больше кода и больше состояний

больше допущений о безопасности

зависимость от механизма “доказать событие в другой сети”

Типовые модели доверия в мостах:

мультиподпись/комитет: группа ключей подтверждает переводы

light-client мост: одна сеть проверяет доказательства другой (сложнее, но потенциально меньше доверия)

Справка по общему обзору: Ethereum.org: Bridges

Типовые причины взломов мостов

компрометация ключей валидаторов/мультиподписи

ошибки в проверке сообщений (message verification)

неправильная обработка повторов (replay)

несоответствие логики между сетями

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

Как выбирать масштабирование и кроссчейн-интеграции

Ниже — короткий инженерный чек-лист.

Если вы выбираете L2

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

учитывать финальность и вывод средств: насколько быстро можно уйти в L1

проверять доступность данных: можно ли восстановить состояние из данных в L1

Если вы добавляете мост

выяснить, на чём держится доверие: мультиподпись, комитет, light client

минимизировать сумму, которая постоянно заблокирована в мосту

закладывать план инцидентов: пауза, лимиты, мониторинг

Главное, что нужно запомнить

Уязвимости в блокчейне чаще всего появляются не из-за “слабой криптографии”, а из-за ошибок логики, контроля доступа, внешних зависимостей и экономических допущений.

Аудит — важная часть процесса, но он не заменяет проектирование, тестирование и безопасную эксплуатацию.

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

L2 (особенно rollups) масштабирует транзакции, опираясь на L1 как на арбитра.

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