Node Times: Newsroom

Сколько стоит перенос живой сети на постквантовые подписи

Newsroom — Sat, 10 Oct 2026 06:32:10 +0000

От редакции NodeTimes.

Постквантовая подпись от одного до трёх порядков больше заменяемой эллиптической кривой (elliptic-curve signature), и счёт за это приходит не в виде криптографии, а в виде пространства блоков, комиссий и вычислительной работы для проверки. Следовательно, сеть сталкивается с выбором между тремя ресурсами, которые нельзя расходовать одновременно: размером блока, частотой блоков и агрегацией. Это сторона затрат миграции, а не вопрос о том, что сломается, и числа смоделированы для сети в целом, а не измерены на одной конкретной.

Подписи стали больше по замыслу

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

ML-DSA (module-lattice signatures): семейство схем, стандартизированное в FIPS 204, чьи подписи являются векторами над кольцом многочленов, поэтому их размер растёт вместе с размерностью и модулем, а не с точкой кривой. SLH-DSA (stateless hash-based signatures): семейство, стандартизированное в FIPS 205, где подпись содержит путь аутентификации хеш-дерева и поэтому состоит из множества небольших хеш-значений вместо одного алгебраического объекта. FN-DSA: схема на основе Falcon, чьи подписи наиболее компактны среди трёх семейств подписей NIST, поскольку её конструкция использует структуру, которую модульно-решёточная схема не использует тем же образом.

Причина, по которой ни одна из них не уменьшается, структурная:

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

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

Размеры, схема за схемой

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

Схема	Открытый ключ	Подпись
ECDSA secp256k1	33 байта (сжато)	около 64 байт
BLS12-381	48 байт (сжато)	96 байт
ML-DSA	около 1,3–2,6 КБ	около 2,4–4,6 КБ
SLH-DSA	десятки байт	около 8–50 КБ в зависимости от набора параметров
FN-DSA (Falcon)	около 0,9–1,8 КБ	около 0,7–1,3 КБ

Каждое число в этой таблице – это размер спецификации, а не измерение, сделанное на живой цепочке. Два фактора делают диапазоны широкими. Во-первых, у каждого семейства есть наборы параметров, которые торгуют размером в обмен на уровень безопасности, и разброс внутри самого ML-DSA составляет от 2420 байт для ML-DSA-44 до 4627 для ML-DSA-87. Во-вторых, открытый ключ – это отдельная строка расходов от подписи, и зависит ли он от каждой транзакции, зависит от модели учётной записи, а не от схемы.

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

Что стоит подпись внутри блока

Внутри блока подпись – это не фиксированная стоимость, это доля каждой транзакции, и эта доля решает, сколько транзакций помещается.

Арифметика стоит того, чтобы сделать её один раз, на открытом воздухе. Подпись secp256k1, схема ECDSA, взлом и замена которой описаны в объяснении о том, как квантовые компьютеры ломают ECDSA, занимает около 64 байт транзакции, и в нескольких дизайнах открытый ключ может быть восстановлен из неё, поэтому ничего другого не должно передаваться. Ни одна стандартизированная постквантовая схема не предлагает такого восстановления, поэтому открытый ключ должен передаваться вместе с транзакцией или запрашиваться в состоянии, и это рычаг за всем счётом. Замена этого на подпись ML-DSA-65 добавляет 3309 байт в ту же транзакцию, и если открытый ключ несётся вместе, его 1952 байта идут с ним: около 5261 байта вместо 64.

Передвижение ключа – единственный самый большой доступный рычаг, и это вопрос о модели учётной записи:

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

Затем следует собственная цена протокола за байты. Там, где calldata стоит фиксированное количество газа за ненулевой байт, подпись взимается как любые другие данные: при 16 газе за ненулевой байт одна только подпись ML-DSA-65 составляет около 53 000 газа до того, как транзакция выполнит что-либо. По сравнению с полом протокола в 21 000 газа за обычный перевод, одна только подпись стоит около двух с половиной обычных переводов, и фиксированный лимит газа блока превращает это соотношение в показатель мощности.

Агрегация, и почему стандарты не дают её

Агрегация заменяет множество подписей одним объектом, и ни одна из стандартизированных схем постквантовых подписей не предоставляет её нативно.

Классические подписи BLS агрегируются, потому что схема живёт в группе, где две подписи можно умножить в одну: подписи на одно сообщение сворачиваются в один объект, требующий одного спаривания для проверки, тогда как подписи на разные сообщения сохраняют каждое спаривание, поэтому экономия через реальный пакет – это фактор, а не константа.

Постквантовые семейства не имеют такой ручки: подпись решётки – это вектор, а хеш-подпись – это набор хеш-значений, и нет операции, при которой сто из них сворачиваются в одну. Агрегация поэтому должна быть построена поверх подписей, а не внутри них, обычно как рекурсивный STARK: система доказательств проверяет пакет подписей, и проверка этого доказательства сама по себе доказуема, так что доказательства многих пакетов складываются в один короткий объект.

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

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

Стоимость верификации

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

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

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

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

Что сеть может реально выбрать

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

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

Порядок между этими рычагами – это фактически решение, и оно зависит от того, какого ресурса сети не хватит первым. Цепь, чьи блоки малы, исчерпывает пространство и нуждается в агрегации или новом типе вывода; цепь, чьи валидаторы уже заняты выполнением, замечает счёт за верификацию первым. Выбор между ними – это то место, где миграция перестаёт быть криптографическим проектом и становится планом мощности, а история того, как стандарты пришли к этим размерам, содержится в отчёте о процессе NIST.

Частые вопросы

Насколько больше постквантовая подпись?

В общих решёточных схемах подпись в десятки раз больше классической: ML-DSA начинается с 2420 байт против около 64 для подписи secp256k1.

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

Можно ли агрегировать подписи?

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

Классическая агрегация BLS – это свойство схемы, чего именно не предлагают постквантовые семейства.

Увеличивает ли большая подпись комиссию каждой транзакции?

Да, там, где комиссии взимаются за пространство, занимаемое транзакцией, потому что доля подписи в этом пространстве резко растёт.

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

Верификация тоже дороже?

Не для самой проверки: дополнительная стоимость – это разбор, распространение и хеширование большего объекта на каждом валидаторе. Подпись решётки быстро верифицируется после разбора, и только хеш-семейство платит за длинный путь аутентификации.

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

Что должна делать сеть первой?

Решить, какой ресурс она намерена потратить: параметры, агрегацию, отдельный тип вывода или время.

Это решение определяет всё последующее, потому что четыре рычага не аддитивны: агрегация меняет модель мощности, тогда как параметры только перемещаются внутри неё.

What Moving a Live Network to Post-Quantum Signatures Costs

Newsroom — Sat, 10 Oct 2026 06:22:49 +0000

By Nika, NodeTimes newsroom.

A post-quantum signature is between one and three orders of magnitude larger than the elliptic-curve signature it replaces, and the bill for that arrives as block space, fees and verification work rather than as cryptography. A network therefore faces a choice between three resources it cannot spend at once: block size, block frequency and aggregation. This is the cost side of the migration rather than the question of what breaks, and the numbers are modelled for a network in general, not measured on one.

Signatures got bigger by design

Post-quantum signatures are large because the schemes rest on different hard problems, and the size follows from the construction rather than from a flaw in an implementation.

ML-DSA (module-lattice signatures): the scheme family standardised in FIPS 204, whose signatures are vectors over a polynomial ring, so their size grows with the dimension and the modulus rather than with a curve point. SLH-DSA (stateless hash-based signatures): the family standardised in FIPS 205, where a signature carries the authentication path of a hash tree and therefore consists of many small hash values instead of one algebraic object. FN-DSA: the Falcon-based scheme, whose signatures are the most compact of the three NIST signature families because its construction exploits a structure that the module-lattice scheme does not use in the same way.

The reason none of them shrinks is structural:

A lattice signature is a vector, and the vector has to fit in the signature; shrinking it means weakening the parameters, not compressing the encoding.
A hash-based signature contains the path that proves a one-time key belongs to a published root, and the path has as many elements as the tree has layers.
Hash-based schemes give up size to gain a security argument that assumes nothing beyond the hash function, which is exactly why the size does not fall.

What that means for a chain is not only bytes. In a proof-of-stake network the signature is what makes the block producer accountable, so its size per transaction multiplies across every verification the network performs, and the shape of that multiplication is what the rest of this article is about. The wider picture of which chains face this and how they differ is in the guide to post-quantum blockchains.

Sizes, scheme by scheme

The differences between post-quantum schemes are larger than the difference between any of them and a classical signature, so the choice of scheme matters more than the choice to migrate.

Scheme	Public key	Signature
ECDSA secp256k1	33 bytes (compressed)	about 64 bytes
BLS12-381	48 bytes (compressed)	96 bytes
ML-DSA	about 1.3–2.6 KB	about 2.4–4.6 KB
SLH-DSA	tens of bytes	about 8–50 KB depending on parameter set
FN-DSA (Falcon)	about 0.9–1.8 KB	about 0.7–1.3 KB

Every number in that table is a specification size, not a measurement taken on a live chain. Two things make the ranges wide. First, each family has parameter sets that trade size against security level, and the spread inside ML-DSA alone runs from 2420 bytes for ML-DSA-44 to 4627 for ML-DSA-87. Second, the public key is a separate line item from the signature, and whether it travels with every transaction depends on the account model, not on the scheme.

The most compact choice is the Falcon-based one, and its size is the reason several networks look at it first; the trade is a more delicate implementation and a signing routine that is harder to get right than the module-lattice scheme. Where that construction comes from is set out in the material on Falcon, and the algebra behind the larger family is in the explainer on lattice-based schemes.

What a signature costs inside a block

Inside a block a signature is not a fixed cost, it is a share of every transaction, and that share decides how many transactions fit.

The arithmetic is worth doing once, in the open. A secp256k1 signature, the ECDSA scheme whose break and replacement the explainer on how quantum computers break ECDSA sets out, occupies about 64 bytes of a transaction, and in several designs the public key can be recovered from it, so nothing else needs to travel. No standardised post-quantum scheme offers that recovery, so the public key has to travel with the transaction or be looked up in the state, and that is the lever behind the whole bill. Replacing that with an ML-DSA-65 signature puts 3309 bytes into the same transaction, and if the public key is carried along, its 1952 bytes come with it: about 5261 bytes in place of 64.

Whether the key travels is the single biggest lever available, and it is a question about the account model:

Account-based chain with the key in state: the public key is stored once per account and the transaction carries only the signature, so the per-transaction cost is roughly fifty times the classical one, not eighty.
Signature carried in the transaction with no state lookup: the key travels every time, and the same payment pays for both objects.
Aggregated batch: many signatures are replaced by one object, which breaks the linear relationship between size and transaction count, at the price of the aggregation machinery.

Then comes the protocol's own price for bytes. Where calldata costs a fixed amount of gas per non-zero byte, the signature is charged like any other data: at 16 gas per non-zero byte, an ML-DSA-65 signature alone accounts for about 53,000 gas before the transaction executes anything. Set against the protocol's floor of 21,000 gas for a plain transfer, the signature alone is worth about two and a half ordinary transfers, and a fixed block gas limit is what turns that ratio into a capacity figure.

Aggregation, and why the standards do not give it

Aggregation replaces many signatures with one object, and none of the standardised post-quantum signature schemes provides it natively.

Classical BLS signatures aggregate because the scheme lives in a group where two signatures can be multiplied into one: signatures on the same message collapse into a single object that takes one pairing to check, while signatures on different messages keep a pairing each, so the saving across a real batch is a factor rather than a constant.

The post-quantum families lack that handle: a lattice signature is a vector and a hash-based signature is a set of hash values, and there is no operation under which a hundred of them collapse into one. Aggregation therefore has to be built on top of the signatures rather than inside them, usually as a recursive STARK: a proof system verifies a batch of signatures, and the verification of that proof is itself provable, so the proofs of many batches fold into one short object.

What the proof buys: one short object on chain instead of one signature per transaction, and verification cost that grows far more slowly than the batch.
What it costs: a prover that must be run and trusted for liveness, proving time that grows with the batch, and a new failure mode if the prover stops publishing.
What it cannot fix: the signature still has to exist off-chain to be proven, so aggregation moves cost rather than deleting it.

The consequence for a network is a schedule question rather than a technical one: aggregation is the right answer for throughput, but it requires a proof system that is itself a subject of active research, so the practical order is to make the primitives replaceable first and to add aggregation where the batch structure already exists.

Verification cost

Verification is the second bottleneck: a bigger signature is more data to parse and more work per validator, and the two do not grow at the same rate.

Parsing is the part that is easy to underestimate. A signature that is fifty times larger is also a signature that must be propagated, decoded and hashed, and every validator does that for every transaction. A lattice signature verifies quickly once it is parsed, because the operation is short-vector arithmetic over a small ring; a hash-based signature verifies by recomputing a tree path, which is cheap per hash but adds up when the path is long. The design notes of the standards present the size as the price of a construction that assumes very little about the adversary's mathematics.

Three budgets move together, and a network that only watches one of them will be surprised by another:

Bandwidth: block propagation and peer traffic, which grow with the signature, not with the number of transactions.
CPU: signature parsing and verification on every node, which grows with both.
State: stored public keys, if the account model keeps them, which turns a per-transaction cost into a permanent one.

What a network can actually choose

A network has four levers, and each one spends a different resource: parameters, aggregation, a separate output type, and a delayed migration.

Parameter sets: pick the smallest set that meets the security target, which reduces the signature without changing the architecture. Reversible, cheap to start, and limited to the spread inside one scheme family.
Aggregation: replace many signatures with one proof, which is the only lever that breaks the linear relation between size and transaction count. Expensive in complexity, and dependent on a prover that has to keep working.
A separate output type: give post-quantum signatures their own way to be spent, so existing outputs keep their size and only new ones pay. Reversible in the sense that a chain can stop creating them, difficult to reverse in the sense that they stay in the state.
Delayed migration: keep the classical scheme for as long as the assumption holds, and spend the time on the interfaces that make the next step possible. Free today, expensive in the sense that the assumption is not under the network's control.

The order between these levers is the actual decision, and it depends on what the network runs out of first. A chain whose blocks are small runs out of space and needs aggregation or a new output type; a chain whose validators are already busy with execution notices the verification bill first. Choosing between them is where the migration stops being a cryptography project and becomes a capacity plan, and the history of how the standards arrived at these sizes is in the account of the NIST process.

Frequently asked questions

How much bigger is a post-quantum signature?

In the common lattice-based schemes a signature is tens of times larger than a classical one: ML-DSA starts at 2420 bytes against about 64 for a secp256k1 signature.

The size, not the security level, is what creates the network problem, because every transaction carries it.

Can signatures be aggregated?

Yes, but not by the standardised schemes themselves: aggregation has to be built on top, typically as a proof that verifies a batch of signatures.

Classical BLS aggregation is a property of the scheme, which is exactly what the post-quantum families do not offer.

Does a bigger signature raise every transaction's fee?

Yes, where fees are charged by the space a transaction occupies, because the signature's share of that space grows sharply.

Whether the increase is proportional to the signature depends on the account model: a key stored in state is paid for once, not per transaction.

Is verification more expensive too?

Not for the check itself: the extra cost is parsing, propagating and hashing a larger object on every validator. A lattice signature verifies quickly once it is parsed, and only the hash-based family pays for a long authentication path.

The bill arrives as bandwidth and CPU for handling more data on every validator, rather than as a slower check or a storage cost.

What should a network do first?

Decide which resource it intends to spend: parameters, aggregation, a separate output type, or time.

That decision sets everything after it, because the four levers are not additive: aggregation changes the capacity model, while parameters only move within it.

Что такое модульная блокчейн-сеть?

Newsroom — Fri, 09 Oct 2026 08:31:57 +0000

Модульный блокчейн разделяет одну машину на отдельные роли, которые можно заменять независимо друг от друга: выполнение (execution), расчет (settlement), консенсус (consensus) и доступность данных (data availability). Монолитная цепочка выполняет все четыре функции в одном процессе, что упрощает систему, но связывает её блоки, состояние и путь обновлений вместе. Практическая разница заключается не в ярлыке, а в том, что вы можете изменить, не переписывая остальную часть системы, и каждое утверждение о модульности можно проверить с помощью одного вопроса.

Одна машина или четыре роли

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

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

Монолитная цепочка объединяет эти четыре функции в одном процессе, потому что это сохраняет одно общее правило для всей системы: одни и те же валидаторы упорядочивают блоки, выполняют их и хранят данные, поэтому транзакция либо попадает в блок, либо нет. Модульность заменяет это единое правило набором интерфейсов между слоями. Там, где эти интерфейсы стабильны, слой может быть заменен; там, где они нестабильны, дизайн является монолитным с дополнительными шагами. То, как L0, L1 и L2 соотносятся после разделения этих слоев, – это отдельный вопрос, рассмотренный в руководстве по уровням.

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

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

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

Слой	Что он делает	Что можно заменить
Выполнение	запускает транзакции и изменяет состояние	виртуальная машина или исполнитель
Расчет	завершает споры и доказательства	площадка расчета
Консенсус	упорядочивает блоки и согласовывает их	механизм упорядочивания
Доступность данных	делает данные блока доступными для получения и проверки	место публикации данных

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

Монолитная против модульной: реальный компромисс

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

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

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

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

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

Где находятся роллапы

Роллап – это выполнение, перемещенное из основной цепочки, и он заимствует другие роли извне, а не предоставляет их сам.

Переход состояния происходит вне основной цепочки и заканчивается корнем состояния, единственным хэшем, который представляет всё результирующее состояние. Доказательство или окно вызова делают этот корень приемлемым на основной цепочке, а данные, позволяющие любому пересчитать это состояние, публикуются где-то, где основная цепочка принимает их как доступные. Именно это делает роллап модульной системой, а не монолитной, но это не делает роллап и модульный блокчейн одним и тем же. В роллапе модульность – это свойство окружающей его структуры: роллап является слоем выполнения, а слои расчета, упорядочивания и данных принадлежат тем системам, на которые он решил положиться.

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

Совместное упорядочивание и его компромисс

Совместный последователь (shared sequencer) упорядочивает транзакции для нескольких роллапов одновременно, что дает им общее упорядочивание и требует одного оператора, от которого теперь зависят все они.

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

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

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

Утверждение о модульности можно проверить, ища интерфейсы, через которые роль действительно может быть заменена, а не просто слово в документации.

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

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

Частые вопросы

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

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

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

Делает ли модульность транзакции дешевле?

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

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

Является ли монолитная цепочка устаревшей?

Нет. Монолитная цепочка проще, сохраняет одно общее правило для всей системы и достаточна для большого класса приложений.

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

Что меняет совместный последователь?

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

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

Как я могу проверить, действительно ли цепочка модульна?

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

Запросите спецификацию интерфейса и одно развертывание, где замена действительно произошла.

What Is a Modular Blockchain?

Newsroom — Fri, 09 Oct 2026 08:22:35 +0000

By Nika, NodeTimes newsroom.

A modular blockchain splits one machine into separate roles that can each be replaced on its own: execution, settlement, consensus and data availability. A monolithic chain performs all four in a single process, which makes it simpler but ties its blocks, its state and its upgrade path together. The practical difference is not in the label but in what you can change without rewriting the rest, and every claim of modularity can be checked against that one question.

One machine, or four roles

The four roles are defined by the job rather than by the product: execution runs transactions and changes state, settlement finalises results and resolves disputes, consensus orders blocks and agrees on their order, and data availability makes block data retrievable and checkable.

Execution: the environment that processes transactions and produces a new state, usually with its own virtual machine. Settlement: the place where results become final and where a dispute about them can be resolved, including the proofs a chain needs to accept an external state. Consensus: the process that fixes the order of blocks and the set of transactions inside them. Data availability: the guarantee that the data behind a block can be obtained and verified by whoever needs it, without trusting the producer's word for it.

A monolithic chain bundles these four in one process because that keeps one guarantee for the whole system: the same validators order blocks, execute them and store the data, so a transaction either lands in a block or it does not. Modularity replaces that single guarantee with a set of interfaces between layers. Where those interfaces are stable, a layer can be swapped; where they are not, the design is monolithic with extra steps. How L0, L1 and L2 relate once those layers are separated is a different question, taken up in the guide to the levels.

Monolithic: one process, one guarantee, one upgrade path, and one congestion domain for every application on it.
Modular: separate roles, separate failure modes, and a coordination cost that appears as soon as one layer lags.
The dividing line: whether a role can be replaced without forking the thing that depends on it.

The four layers and what each can be swapped for

Each layer exposes its own interface, and a swap is only real where that interface is stable enough that the other layers can keep working.

Layer	What it does	What you can swap
Execution	runs transactions and changes state	the virtual machine or the executor
Settlement	finalises disputes and proofs	the settlement venue
Consensus	orders blocks and agrees on them	the ordering mechanism
Data availability	makes block data retrievable and checkable	where the data is published

The layer that actually gets swapped is execution, because a rollup's state transition function can be replaced while the settlement contract above it keeps verifying proofs. A change in settlement or in ordering is a different order of difficulty, because it alters what the other layers have to prove, and a proof system is not something you migrate in a weekend.

Monolithic versus modular: the actual trade

Modularity is bought with coordination: the design gains replaceable parts and pays for them in external dependencies and new failure modes.

In a monolithic chain the failure modes are coarse but easy to reason about: the chain is congested, or it is not; it finalises, or it does not. When execution lives outside the chain that settles it, the failure list grows.

The settlement layer can stall while execution keeps accepting transactions. The data layer can lose data, which is worse than a stall, because a rollup cannot reconstruct its state from a block it cannot retrieve. An upgrade in one layer can require a coordinated change in another, and that coordination is exactly the property that modularity was supposed to remove at the application level. Splitting state is not a free way out either: the same tension shows up in sharding, where a state split buys throughput and pays in cross-shard coordination.

What modularity buys: independent upgrades, specialised layers, and the ability to use a better component without a migration of the whole system.
What it costs: an extra trust surface per layer, more moving parts to monitor, and fees that now include the cost of the other layers.
What it does not do by itself: make transactions cheaper. A cheaper execution layer is a fact about that layer, not about modularity as such.

The last point is where most marketing breaks down. Modularity changes which costs are paid where; it does not remove them. Whether a modular design is cheaper depends on the load profile and on the price of the layers it borrows, so the honest version of the claim is that a specific component can become cheaper under a specific workload.

Where rollups fit

A rollup is execution moved out of the main chain, and it borrows the other roles from outside rather than providing them itself.

The state transition happens off the main chain and ends in a state root, the single hash that stands for the whole resulting state. A proof or a challenge window makes that root acceptable on the main chain, and the data that lets anyone recompute that state is published somewhere the main chain accepts as available. That is what makes a rollup a modular system rather than a monolithic one, but it does not make a rollup and a modular blockchain the same thing. In a rollup, the modularity is a property of the arrangement around it: the rollup is the execution layer, and the settlement, ordering and data layers belong to whichever systems it chose to rely on.

A modular L1 goes further, because the chain itself is built so that these roles can be replaced inside it, not only borrowed from outside. How agreement about the resulting state is reached, in either shape, is covered in the explainer on consensus.

Shared sequencing and its compromise

A shared sequencer orders transactions for several rollups at once, which gives them a common ordering and takes a single operator that all of them now depend on.

The benefit is concrete: a bundle can be included across rollups together instead of being split, so a cross-rollup operation either lands on both sides or on neither, and users stop relying on separate light clients to prove one rollup's history to another. The compromise is just as concrete. Whoever orders transactions can delay or reorder them, and a single shared sequencer concentrates that power over every chain that uses it. Atomicity of inclusion is also weaker than it sounds: a guarantee that a bundle is sequenced everywhere is not a guarantee that every transaction in it succeeds, because each transaction still executes against its own rollup's state and can revert on its own.

What it improves: cross-rollup atomicity of inclusion, one ordering to prove instead of many, and less duplicated infrastructure per rollup.
What it introduces: a common ordering centre, a new liveness dependency, and a governance question about who runs it and how it is replaced.
The check to run: ask what happens to each rollup if the shared sequencer stops, and whether any of them can keep producing blocks without it.

How to tell real modularity from a rebrand

A claim of modularity can be tested by looking for interfaces a role can actually be swapped through, rather than for the word in the documentation.

Three checks do the work. First, find the specification of the boundary: an interface that other layers implement against, with its version and its compatibility rules. Second, find an example of the swap: a working deployment where one role was replaced while the others kept running, which is the only evidence that the interface holds. Third, ask what happens to a user whose transaction is in flight during that replacement, because a swap that requires a frozen system is a migration rather than modularity. If none of the three can be answered from the documentation or from a published account of a live swap, the architecture is a description and not a property.

Architecture also does not start and end with this four-layer picture. In some designs the unit that matters is not a layer but a structural element whose contents decide what a node can verify or discard, as in the structure of a cell. The question to carry into any of these models is the same: which part can be replaced, and by whom.

Frequently asked questions

Is a modular blockchain just a rollup?

No. A rollup is execution moved outside the main chain, while modularity is a property of a whole system in which roles can be replaced.

Every rollup is modular in part, but not every modular design is a rollup, and a chain can be modular without having one.

Does modularity make transactions cheaper?

Not by itself. A specific layer can become cheaper, while the bill for coordination between layers is added somewhere else.

Whether the total falls depends on the workload and on what the borrowed layers cost at that moment.

Is a monolithic chain outdated?

No. A monolithic chain is simpler, keeps one guarantee for the whole system, and is enough for a large class of applications.

Modularity is a trade rather than a newer generation, and it pays off where the ability to replace parts matters more than the simplicity.

What does a shared sequencer change?

It gives several rollups a single ordering, so a bundle can be included across them together, and it concentrates that ordering in one operator.

The gain is cross-rollup atomicity of inclusion; the cost is a shared centre that every participating chain now depends on.

How do I check whether a chain is really modular?

By its interfaces: if a role cannot be replaced without forking what depends on it, the replaceability exists only in the description.

Ask for the interface specification and for one deployment where the swap actually happened.

Кошельки AI-агентов: объяснение

Newsroom — Thu, 08 Oct 2026 06:31:58 +0000

Кошелёк агента – это не кошелёк, а набор разрешений (permission set): смарт-аккаунт (smart account), который хранит средства, и ограниченное право подписи (scoped signing right), позволяющее агенту действовать в рамках заданных вами ограничений. Важный вопрос заключается не в том, где хранится ключ, а в том, что именно может подписать агент, от чьего имени, до какой суммы и как это право может быть отозвано. Всё остальное вытекает из этого сдвига: когда объектом контроля становится разрешение, а не ключ, работа по проектированию переносится в плоскость определения области действия (scope), лимитов и отзыва.

Кошелёк – это набор разрешений, а не ключ

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

Смарт-аккаунт (smart account): аккаунт, правила которого написаны кодом, поэтому валидной операцией считается та, которую сам аккаунт принимает; это может означать наличие подписи авторизованного подписанта, вызов конкретного контракта или оба условия сразу. Сессионный ключ (session key): отдельный ключ подписи, авторизованный аккаунтом для ограниченной цели, а не основной ключ самого аккаунта. Область действия (scope): то, что разрешено делать этому ключу, выраженное через разрешённые цели (targets), разрешённые функции и временное окно. Политика (policy): правило, которое аккаунт применяет к предлагаемой операции перед её принятием, например, лимит расходов или белый список (allowlist) получателей.

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

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

Сравнение моделей хранения (Custody models)

Модели хранения различаются по одному параметру: кто фактически производит подпись, а значит, какова цена компрометации агента. Это делает хранение (custody) второй половиной того же вопроса: модель определяет, что можно подписать и кто должен это сделать, а не только то, где лежит ключ.

Модель хранения	Кто подписывает	Цена компрометации	Как осуществляется отзыв доступа
Общий ключ (Shared key)	агент, с тем же ключом, что и человек	всё, чем управляет этот ключ	только путем перевода средств
Сессионный ключ на смарт-аккаунте	агент, в пределах области действия	лимиты области действия	отзыв или истечение срока сессионного ключа
MPC или пороговая схема (MPC or threshold)	агент плюс независимая сторона	остановленная операция, а не потеря кошелька: одна часть не может завершить подпись в одиночку	удаление части агента в процессе подписи
Подписание через TEE или службу HSM (TEE or HSM signing service)	служба подписания по запросу агента	всё, что разрешено политикой службы	отключение политики службы

Строка «общий ключ» – это та, которую следует распознать в вашей собственной инфраструктуре, поскольку это результат по умолчанию при передаче агенту приватного ключа и названии этого интеграцией. Последние две строки заменяют единую точку подписи координацией: пороговая схема MPC не устраняет риск, она меняет круг лиц, которым нужно пойти на сговор для совершения неверного платежа, а служба подписания внутри защищённой среды всё равно зависит от настроенной там политики. То, как одна из платформ подходит к вопросу безопасности кошельков в этой картине, изложено в сравнении платформ кошельков.

Сессионные ключи и ограниченная подпись

Сессионный ключ (session key) – это отдельный подписант со сроком истечения и определённой зоной действия, созданный так, чтобы его потеря стоила лишь лимита, а не всего аккаунта.

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

Сессионный ключ – это не второй пароль, и разница в этом является причиной его полезности:

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

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

Лимиты, белые списки и стоп-переключатель

Лимиты и белые списки (allowlists) превращают утечку учётных данных агента из потери всего в инцидент с известным максимумом.

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

Пауза (Pause): переключатель, останавливающий новые операции при сохранении балансов и истории, используется при подозрении, а не после потери.
Отзыв (Revoke): изъятие самой сессии, это единственный элемент управления, работающий после того, как известно о компрометации ключа.
Эскалация (Escalate): маршрутизация любых операций выше потолка на шаг утверждения человеком вместо их отказа, что сохраняет полезность агента на границах возможностей.

Стоп-переключатель должен быть доступен, когда агент ведёт себя неправильно, что на практике означает, что он принадлежит человеку, а не агенту: отзыв, требующий сотрудничества агента, не является элементом управления. То же самое относится к оповещениям, которые никто не читает, поэтому полезная версия мониторинга – это лимит, который работает в режиме закрытия (fails closed), плюс уведомление об каждом отказе.

Что остаётся у человека

Три вещи остаются у человека в любой работоспособной конструкции: политика, ключ восстановления (recovery key) и запись о том, что сделал агент.

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

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

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

Как ломаются кошельки агентов

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

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

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

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

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

Кража учётных данных (credential theft) – это окружающий риск, а не специфичный для агентов, а формы, которые он принимает в среде агента, от враждебных запросов до скомпрометированной зависимости, описаны в обзоре криптоугроз.

Частые вопросы

Нужен ли ИИ-агенту собственный кошелёк?

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

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

Что такое сессионный ключ?

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

Именно поэтому это не второй пароль: он истекает и имеет ограничения по области действия, тогда как пароль не обладает ни тем, ни другим.

Могут ли лимиты расходов действительно сдержать утечку?

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

Утечка под потолком – это инцидент с известным максимумом, а утечка без него – это весь аккаунт.

Безопаснее ли MPC, чем смарт-аккаунт?

Они решают разные проблемы: пороговая подпись (threshold signing) устраняет единого подписанта, тогда как смарт-аккаунт определяет правила, которым должна удовлетворять операция.

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

Кто несёт ответственность, когда агент ошибочно платит?

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

Техническая форма этого ответа проста: человек владеет аккаунтом, поэтому человек несёт последствия.

AI Agent Wallets Explained

Newsroom — Thu, 08 Oct 2026 06:12:35 +0000

By Nika, NodeTimes newsroom.

An agent wallet is not a wallet but a permission set: a smart account that holds the funds and a scoped signing right that lets the agent act inside limits you defined. The question that matters is not where the key is stored but what the agent can sign, for whom, up to what amount, and how that right is taken away. Everything below follows from that shift: once the object of control is a permission rather than a key, the design work moves into scope, limits and revocation.

A wallet is a permission set, not a key

Giving an agent a key gives it your whole balance; giving it a permission gives it exactly the actions the policy allows, and nothing outside them.

Smart account: an account whose rules are code, so that a valid operation is one the account itself accepts, which may mean a signature from an authorised signer, a call to a specific contract, or both. Session key: a separate signing key that has been authorised by the account for a limited purpose, rather than the account's main key. Scope: what that key is allowed to do, expressed as allowed targets, allowed functions and a time window. Policy: the rule the account applies to a proposed operation before accepting it, such as a spending cap or a recipient allowlist.

The practical consequence is that the agent never needs to hold anything valuable. It holds a right to instruct, and how that right is actually spent on the settlement rails is set out in the explainer on agentic payments, while the funds stay behind the account's own validation logic.

What the agent gets: a signing right with a scope, a lifetime and a ceiling.
What the agent does not get: the ability to move funds outside that scope, or to widen the scope itself.
What the operator keeps: the account, the policy that defines the scope, and the ability to withdraw the right.

Custody models compared

Custody models differ along one axis: who actually produces the signature, and therefore what a compromise of the agent costs. That makes custody the storage half of the same question: the model decides what can be signed and who has to sign it, not only where a key sits.

Custody model	Who signs	What a compromise costs	How access is revoked
Shared key	the agent, with the same key as the human	everything the key controls	only by moving the funds
Session key on a smart account	the agent, within a scope	the scope's allowance	revoke or expire the session key
MPC or threshold	the agent plus an independent party	a stalled operation, not the wallet: one part alone cannot complete a signature	remove the agent's part of the signing
TEE or HSM signing service	a signing service on the agent's request	whatever the service's policy permits it to sign	disable the service policy

The shared-key row is the one to recognise in your own setup, because it is the default result of giving an agent a private key and calling it an integration. The last two rows trade a single point of signing for coordination: an MPC threshold does not remove the risk, it changes who has to collude before a wrong payment can happen, and a signing service inside a protected environment still depends on the policy you configured there. How one platform approaches the wallet-security side of that picture is set out in the wallet platform comparison.

Session keys and scoped signing

A session key is a separate signer with an expiry and a defined area of action, designed so that losing it costs the allowance rather than the account.

The mechanism comes from account abstraction: on a modular smart account the session key is installed as a validator module with policies attached, and each proposed operation is checked against those policies before the account accepts it. A policy can bound the target contract, the function being called, the total value moved and the period during which the key is valid; the account refuses anything outside that envelope. Practical implementations also require the account owner to sign the session into existence, so a session cannot be created by the agent for itself.

A session key is not a second password, and the difference is what makes it useful:

It cannot be rotated only when you remember to: it expires on its own, and the account stops accepting it.
It is not a copy of the main key: revoking it does not require reissuing the account's own signer.
It is not a blanket approval: what it can move is bounded by the policy, not by the balance.

Where the agent pays in tokens rather than in the chain's own currency, the same bounding logic appears at the token level: an allowance for a specific spender contract is itself a ceiling, and what a token is and how approvals work is set out in the explainer on tokens.

Limits, allowlists and a stop switch

Limits and allowlists are what turn a leaked agent credential from a loss of everything into an incident with a known maximum.

Three controls do most of the work, and they are worth configuring before the agent sees any funds. A per-transaction ceiling bounds the worst single mistake. A rolling limit over a period bounds a loop that repeats a small payment. A recipient allowlist makes the destination of an incorrect payment a set you chose, rather than an address chosen by whoever is prompting the agent.

Pause: a switch that stops new operations while keeping balances and history, for use during a suspicion rather than after a loss.
Revoke: withdrawal of the session itself, which is the only control that works after a key is known to be compromised.
Escalate: routing anything above the ceiling to a human approval step instead of refusing it, which keeps the agent useful at the edges.

The stop switch has to be reachable when the agent is misbehaving, which in practice means it lives with the human and not with the agent: a revocation that requires the agent to cooperate is not a control. Neither is an alert that nobody reads, so the useful version of monitoring is a limit that fails closed plus a notification on every refusal.

What stays with the human

Three things stay with the human in every workable design: the policy, the recovery key, and the record of what the agent did.

The policy is the actual control surface, since the session key is only an instance of it. Whoever can edit the policy can widen the agent's scope, so that ability has to sit with the same person who can move the funds. The recovery key is the second element: if the account's own signer is held by the agent or by the same infrastructure the agent runs on, there is nothing left to revoke with once the agent misbehaves. The audit log is the third, and it is what makes an incident reviewable: which operations were proposed, which were refused by policy, and which signer produced each accepted signature.

Policy: a human-owned configuration, changed deliberately rather than by the agent's runtime.
Recovery: a signer the agent never sees, kept where the agent cannot read it.
Audit: an append-only record of proposals and refusals, sufficient to reconstruct an incident.

The workflow question follows from this division: an agent that can request a wider limit is useful, while an agent that can grant itself one is a liability, and the difference is not in the agent's code but in where the policy lives.

How agent wallets fail

Agent wallets fail in three recognisable ways, and each has an early signal that is visible before any money is lost.

The first failure is a scope that is too wide: an agent authorised for a whole contract when it needed one function, or for the account's full balance when it needed a budget. The signal is a permission that cannot be described in one sentence, and the fix is to start from the smallest envelope the task can run in. The second is the absence of revocation: a session key without an expiry, or an allowance that stays in place after the integration ended. The signal is a permission with no owner and no end date, and it is the most common one because nothing breaks at the moment it is created.

The third is a leaked session key with no ceiling behind it, where the scope was technically correct but nothing bounded the amount. The signal is a policy with no ceiling line of its own, and the fix is a ceiling on the session rather than on the scope.

Before granting access, confirm that the answer to each of these is a fact rather than an intention:

The scope names the contracts and functions, and the agent has no path to anything else.
The key expires without anyone remembering to revoke it, and revocation is possible today.
The ceiling is low enough that losing the key is survivable, and refusals raise an alert.
The human signer is not stored where the agent can read it.

Credential theft is the surrounding risk rather than the agent-specific one, and the shapes it takes in an agent's environment, from hostile prompts to a compromised dependency, are described in the overview of crypto threats.

Frequently asked questions

Does an AI agent need its own wallet?

A separate wallet exists so that the damage from an agent's mistake is bounded by its allowance rather than by the balance it was pointed at.

It is not a convenience feature; it is the control that makes the rest of the design meaningful.

What is a session key?

A session key is a separate signing right with a limited scope and a limited lifetime, which the account can withdraw without reissuing its main signer.

That is why it is not a second password: it expires and it is scoped, while a password is neither.

Can spending limits really contain a leak?

Yes, if the limits and the recipient allowlist are in place before access is granted, because then a leaked key can only spend what the policy allows.

A leak under a ceiling is an incident with a known maximum, and a leak without one is the whole account.

Is MPC safer than a smart account?

They solve different problems: threshold signing removes the single signer, while a smart account defines the rules an operation has to satisfy.

In practice the two are combined: the policy sits on the account and the signature is split across parties.

Who is responsible when an agent pays wrongly?

Responsibility starts with whoever issued the permission, because the policy and the recovery key are held by a person and not by the agent.

The technical form of that answer is simple: the human owns the account, so the human owns the consequences.

Полный узел против валидатора: в чём реальная разница

Newsroom — Wed, 07 Oct 2026 12:32:00 +0000

Полный узел (full node) самостоятельно проверяет блоки и транзакции и хранит состояние цепи; валидатор делает всё то же самое, что и полный узел, а дополнительно предлагает свои собственные блоки и подтверждает (attests) блоки, предложенные другими. Вторая обязанность именно та, которая ставит под угрозу собственные средства валидатора, потому что вес валидатора в консенсусе определяется его депозитом. Роли часто путают из-за того, что одна машина может выполнять обе функции: валидатор почти всегда запускает полный узел «под капотом», и разница заключается не в установленном программном обеспечении, а в принимаемых на себя обязательствах.

Две обязанности, которые люди путают: обслуживание и валидация

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

Узел (Node): процесс, который хранит копию цепи, проверяет каждый блок и каждую транзакцию в соответствии с правилами протокола и может отвечать на запросы о результате. Состояние (State): текущий набор балансов, кода и хранилища, который протокол нуждается в обработке для следующего блока, в отличие от истории блоков, которые привели к этому состоянию. Клиент (Client): программное обеспечение, реализующее протокол, которое в современных сетях proof-of-stake разделено на две части. Консенсус-клиент (consensus client) (также называемый beacon node): следит за цепочкой подтверждений (attestations) и решает, что является финальным. Клиент исполнения (execution client): исполняет транзакции и поддерживает состояние; эти два компонента общаются друг с другом через локальный канал, а не через сеть.

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

Обслуживание: проверка, хранение состояния, ответы на запросы, ретрансляция транзакций. Нет депозита, нет обязанности голосовать, нет вознаграждения.
Валидация: предложение блоков, подтверждение блоков других участников, поддержание онлайн-статуса по требованию. Требуется депозит: 32 ETH для входа и до 2048 ETH эффективного баланса после EIP-7251, где эффективный баланс – это часть ставки, которая учитывается при определении веса в консенсусе. Обязанности строго контролируются, возможны штрафы.
Оба варианта: запуск одного и того же консенсусного и исполнительного программного обеспечения, что именно и приводит к лёгкости потери различий между ними.

Полный узел, архивный узел, легкий клиент

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

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

Роль	Что она делает	Что рискует	Что зарабатывает
Легкий клиент	проверяет заголовки, запрашивает состояние у других	доверие ответам провайдера	ничего
Полный узел	самостоятельно проверяет блоки и транзакции	диск, пропускную способность, простои	ничего напрямую
Архивный узел	предоставляет историческое состояние	рост объёма хранилища	ничего напрямую
Валидатор	предлагает и подтверждает блоки	слэшинг за недобросовестное поведение	вознаграждения за стейкинг
Точка доступа RPC	отвечает на запросы, часто поверх полного узла	злоупотребления и нагрузка	сервисные сборы

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

Чем на самом деле занимается валидатор

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

Клиент валидатора – это третий процесс. Он хранит ключи подписи и выполняет обязанности, тогда как подключённый к нему beacon node хранит цепь, а execution client хранит состояние. Такое разделение существует, чтобы ключи находились в максимально возможном изолированном процессе, и именно поэтому валидатор нельзя запустить как клиент на чужой инфраструктуре, не передав этому кому-то возможность подписывать данные: в обычной настройке ключ находится там, где выполняется обязанность, а отдельный подписант, к которому валидатор может обращаться, переносит проблему доверия, а не устраняет её. То, как голоса многих валидаторов превращаются в финализированный блок, является предметом отдельного справочника по консенсусу.

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

Слэшинг и стейкинг: откуда берётся риск

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

Первоначальный штраф представляет собой долю от эффективного баланса, а не фиксированную сумму: начиная с EIP-7251 это одна часть из 4096, что составляет около 0,008 ETH для валидатора с минимальным стейкингом в 32 ETH и около 0,5 ETH при максимальном значении в 2048 ETH. Затем валидатор помещается в очередь на выход примерно на 36 дней, и в середине этого периода применяется корреляционный штраф, размер которого масштабируется в зависимости от общего количества заблокированного стейка вокруг того же времени; если большое количество валидаторов блокируется вместе, этот штраф может достигнуть всего стейка.

Три нарушения подлежат слэшингу, и ни одно из них не происходит случайно:

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

Нахождение в офлайне – это другая категория. Валидатор, который просто перестаёт отвечать, теряет вознаграждения, которые он мог бы заработать, и медленно теряет средства, а суровая версия этого штрафа наступает только тогда, когда сама цепь не может финализироваться и активна утечка неактивности (inactivity leak). Эта асимметрия преднамеренна: отсутствие – это затраты, конфликтующая подпись – это атака. Разница между двумя семействами консенсусов описана в статье proof of work versus proof of stake.

Сколько это стоит

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

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

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

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

Почему валидаторы редко открывают публичный API

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

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

Более чистое решение – разделить роли и позволить валидатору быть единственным процессом с обязанностями: отдельный узел или точка доступа провайдера обслуживает запросы. Где именно проходит граница между узлом, точкой доступа и провайдером, описано в справочнике по RPC, включая причину, по которой точка доступа не является узлом. Разделение также делает режимы отказов отдельными: узел запросов можно перезапустить по желанию, тогда как процесс валидатора следует перезапускать только тогда, когда никто другой не может подписывать тем же ключом.

Частые вопросы

Может ли валидатор работать без полного узла?

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

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

Зарабатывает ли полный узел что-либо?

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

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

Небезопасен ли легкий клиент?

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

Для кошелька, читающего баланс, эта сделка обычно приемлема; для чего-либо, что самостоятельно перемещает ценности, это неприемлемо.

Что вызывает слэшинг?

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

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

Почему не стоит открывать API валидатора публично?

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

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

Full Node vs Validator Node: What Actually Differs

Newsroom — Wed, 07 Oct 2026 12:22:42 +0000

By Nika, NodeTimes newsroom.

A full node verifies blocks and transactions itself and keeps the state of the chain; a validator does everything a full node does and additionally proposes its own blocks and attests to blocks proposed by others. The second duty is what puts the validator's own money at stake, because a validator's weight in consensus is its deposit. The roles are confused so often because one machine can carry both: a validator almost always runs a full node underneath, and the difference sits in the responsibility taken on rather than in the software installed.

Two jobs people confuse: serving and validating

Serving a chain and validating a chain are two different obligations: a node answers questions about a chain it has verified, while a validator produces blocks and votes on the ones it did not produce.

Node: a process that keeps a copy of the chain, checks every block and transaction against the protocol rules, and can answer questions about the result. State: the current set of balances, code and storage that the protocol needs to process the next block, as distinct from the history of blocks that produced it. Client: the software that implements the protocol, which in modern proof-of-stake networks is split in two. The consensus client (also called the beacon node): follows the chain of attestations and decides what is final. The execution client: executes transactions and maintains the state; the two talk to each other over a local channel rather than over the network.

A node that only serves is a reader. It matters because someone has to hold and check the chain without permission and without being paid for it, which is the whole argument for why a blockchain needs nodes at all.

Serving: verify, keep state, answer queries, relay transactions. No deposit, no voting duty, no reward.
Validating: propose blocks, attest to the blocks of others, stay online when called. Deposit required: 32 ETH to enter, and up to 2,048 ETH of effective balance since EIP-7251, where the effective balance is the portion of the stake that counts toward consensus weight. Duties enforced, penalties possible.
Both: run the same consensus and execution software, which is exactly why the distinction is easy to lose.

Full node, archive node, light client

The three differ in what they verify and what they keep: a full node verifies everything itself, an archive node adds historical state to that, and a light client verifies block headers while asking a provider for everything else, and what each of them ends up storing is set out in the explainer on RPC.

Pruning is where most of the confusion lives. A full node keeps every block and every transaction, but it does not have to keep every past state: state is pruned behind a retention window, while the block history stays. An archive node keeps the historical states as well, which is what makes it large and what makes it the only node class that can answer a query about a balance at an arbitrary past block.

Role	What it does	What it risks	What it earns
Light client	verifies headers, asks others for state	trusting a provider's answers	nothing
Full node	verifies blocks and transactions itself	disk, bandwidth, downtime	nothing directly
Archive node	serves historical state	storage growth	nothing directly
Validator	proposes and attests blocks	slashing for misbehaviour	staking rewards
RPC endpoint	answers queries, often on top of a full node	abuse and load	service fees

Sync mode is a separate choice from node class: a node can rebuild state by executing every block from genesis, or start from a snapshot that a peer provides and verify forward from there. The first is slower and fully self-checked; the second is faster and trusts the snapshot it began from, which is a different trade from the one a light client makes.

What a validator actually does

A validator has two duties in every epoch: propose a block when it is selected, and attest to the block it believes is canonical; its influence on the outcome is proportional to its deposit.

The validator client is a third process. It holds the signing keys and performs the duties, while the beacon node it connects to keeps the chain and the execution client keeps the state. That split exists so keys live in the smallest possible process, and it is also why a validator cannot be run as a client on someone else's infrastructure without giving that someone the ability to sign: in a plain setup the key lives where the duty is performed, and a separate signer that the validator can only ask moves that trust problem instead of removing it. How the votes of many validators turn into a finalised block is the subject of its own explainer on consensus.

Proposal: one validator per slot is selected to build and sign the block, with the selection weighted by deposit.
Attestation: every validator votes on the head of the chain and on the checkpoints it considers justified.
Sync committee: a rotating subset signs the headers that light clients follow, so those clients do not have to trust a provider for the chain itself.

Slashing and staking: where the risk comes from

The risk of running a validator comes from its own behaviour rather than from an attacker: misbehaviour that could be part of an attack on the chain is slashable, and an isolated incident is punished much more lightly than a mass one.

The initial penalty is a fraction of the effective balance rather than a fixed amount: since EIP-7251 it is one part in 4096, which is about 0.008 ETH for a validator staked at the 32 ETH minimum and about 0.5 ETH at the 2,048 ETH maximum. The validator is then queued for exit over roughly a 36-day period, and at the midpoint of that period a correlation penalty is applied whose size scales with the total stake slashed around the same time; if a large share of validators is slashed together, that penalty can reach the entire stake.

Three offences are slashable, and none of them happens by accident:

Proposing two different blocks for the same slot.
Attesting to two different blocks for the same slot.
Contradicting an earlier checkpoint vote.

Being offline is a different category. A validator that simply stops answering loses the rewards it would have earned and bleeds slowly, and the severe version of that penalty arrives only when the chain itself cannot finalise and the inactivity leak is active. That asymmetry is deliberate: an absence is a cost, a conflicting signature is an attack. The difference between the two families of consensus is set out in proof of work versus proof of stake.

What running one costs

A validator's cost is not only the machine: bandwidth, synchronisation time, downtime tolerance and the discipline of upgrades are the parts that decide whether the role is sustainable.

Storage is the first bill, and its size depends on the network, the client and how much history you choose to keep: an archive configuration costs multiples of a pruned one, and a snapshot sync needs less time but more free space at the peak. Bandwidth is the second, because a node talks to peers continuously and a validator has to be reachable to do its duty. Time is the third and the one that is usually underestimated: a full sync from genesis is a multi-day operation on a fast link, and every missed duty during it is a missed reward.

Disk: state plus history, prunable for a full node and by definition not prunable for an archive node.
Network: sustained peer traffic and, in a validator, the latency at which a duty can still be performed.
Time: initial sync, client upgrades, and the operator's own attention to a key that must not be copied to a second machine.

Two operational rules follow from the cost structure. The first is never to run the same validator key in two places, because duplicated signing is precisely the double-vote case that slashing exists to punish. The second is to treat an upgrade as a scheduled risk, not as background maintenance, since the client pair has to stay in step with the network.

Why validators rarely expose a public API

An operator usually keeps the query interface away from the validator, because a public endpoint puts unknown traffic on the same process that holds the signing keys and answers for the deposit.

The two functions have opposite load profiles. A validator serves a handful of duties per epoch and needs predictable latency; a query interface absorbs whatever the internet sends, including expensive requests and scans for exposed keys or debug methods. Running them on one machine is what turns a traffic spike into a missed attestation, and in the worst case into an incident around the key.

The cleaner arrangement is to separate the roles and let the validator be the only process with duties: a separate node, or a provider's endpoint, serves the queries. Where the boundary between node, endpoint and provider actually sits is covered in the explainer on RPC, including why an endpoint is not a node. The separation also makes the failure modes separate: a query node can be restarted at will, while the validator's process should only be restarted when nobody else could be signing with the same key.

Frequently asked questions

Can a validator run without a full node?

No. To propose and attest to blocks a validator has to verify the chain state itself, which means a consensus client and an execution client underneath it.

A provider's endpoint can relay queries, but it cannot perform the validator's duties on its own.

Does a full node earn anything?

No. A full node is not paid by the protocol for verifying blocks and keeping state, so its return is independence rather than income.

Operators run one for their own guarantees: no third party decides what they can see or which chain they follow.

Is a light client unsafe?

It is stronger in one respect and weaker in another: it verifies the headers it receives locally, but it depends on a provider for the state those headers point at.

For a wallet reading a balance that trade is usually acceptable; for anything that moves value on its own it is not.

What causes slashing?

Behaviour that could be part of an attack on the chain: proposing two blocks for one slot, attesting to two, or contradicting an earlier checkpoint vote.

Long absence is penalised differently and usually far more gently, through lost rewards rather than a destroyed stake.

Why not expose the validator's API publicly?

Because public traffic would reach the process that signs blocks and answers for the deposit, where the cost of a failure is not measured in convenience.

Keeping queries on a separate node keeps the signing process reachable only by its operator.

Миграция на постквантовую криптографию: что меняется на практике

Newsroom — Tue, 06 Oct 2026 10:32:04 +0000

От редакции NodeTimes.

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

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

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

Постквантовая криптография (PQC): семейство алгоритмов, созданных для сохранения безопасности перед лицом злоумышленника, обладающего криптографически значимым квантовым компьютером, стандартизированных NIST как FIPS 203, FIPS 204 и FIPS 205. Установление ключа (также называемое обменом ключами): часть рукопожатия, в которой согласуется общий секрет. Цифровые подписи: механизм, доказывающий авторство и целостность. Криптографическая гибкость – это способность заменять один примитив другим через конфигурацию, а не через изменение кода; постквантовый глоссарий содержит остальную лексику, на которой строится эта тема.

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

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

Криптографическая гибкость прежде всего

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

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

Жёстко заданные имена кривых, длины ключей или идентификаторы хеш-функций в конфигурации, которая поставляется с бинарным файлом.
Столбцы базы данных, рассчитанные на публичный ключ размером 32 байта, которые молча обрезают более крупный ключ.
Библиотеки, привязанные к одной версии, где само обновление является проектом.
Формат сертификата или ключа, который кодирует алгоритм внутри идентификатора, так что обе стороны должны перейти на него в один день.

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

Гибридный режим: классические и постквантовые алгоритмы вместе

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

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

Для подписей расчёт иной, потому что гибридная подпись проверяется тем, кто её потребляет, и этот потребитель должен понимать обе схемы. Гибридные подписи являются переходным устройством для систем, которыми вы управляете с обеих сторон; для всего, что обращено к открытому интернету, они представляют собой налог на совместимость, платимый дважды.

Обязательно там, где трафик записывается сегодня и читается позже: долговременные сеансы, VPN, резервные копии в пути.
Целесообразно там, где обе стороны ваши, и вы можете вывести гибридную форму из эксплуатации по графику.
Избегаемо там, где пир всё ещё работает на стеке, который нельзя обновить, и единственным честным вариантом является изоляция этого пира.

Стоимость измеряется в байтах. Доля ключа классического X25519 составляет 32 байта; инкапсулирующий ключ ML-KEM-768 – 1184 байта, а его шифротекст – 1088 байт, поэтому гибридная доля примерно в тридцать восемь раз больше классической. Арифметика не улучшается значительно при переходе между наборами параметров: постквантовая доля велика в каждом из них, поэтому её размер становится инженерной задачей, шириной поля или бюджетом фрагментации задолго до того, как станет криптографической. Алгебра, лежащая в основе этого обмена ключами, изложена в материале о криптографии на решетках.

Что ломается в рукопожатии

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

TLS 1.3 ClientHello несет доли ключей, и когда это сообщение превышает начальное окно перегрузки TCP-соединения, оно должно быть фрагментировано на несколько пакетов. Сама по себе фрагментация переживаемая; цена – второй круговой переход, прежде чем сервер сможет ответить, а второй круговой переход – это именно то, что наиболее заметно для соединения с высокой задержкой.

Компонент	Что меняется	Первое действие
Транспорт (TLS)	обмен ключами получает постквантовую половину	включить гибридный обмен ключами там, где позволяет стек клиента
Подпись кода	ключи подписи и корни должны быть перевыпущены	провести инвентаризацию каждого корневого и промежуточного элемента, которым вы управляете
PKI и сертификаты	выпуск, срок действия и поддержка клиентами	составить карту клиентов, которые вообще нельзя обновить
Оборудование и HSM	новые алгоритмы требуют новую прошивку или новые устройства	перечислить устройства без пути обновления прошивки
Блокчейн и смарт-аккаунты	подписи и абстракция аккаунтов двигаются вместе	разделить схему подписи от модели аккаунта

Размеры подписей имеют значение в другом месте. В рукопожатии TLS подпись сервера находится в сообщении CertificateVerify, и подпись ML-DSA-65 составляет 3309 байт против 64 байт для подписи Ed25519, с публичным ключом 1952 байта против 32. Полёт всё ещё помещается, но каждый мидлбокс, который парсит внутри слоя записи, теперь имеет более длинную структуру для обработки, а старый код парсинга – это место, где случаются сюрпризы.

Сертификаты и цепочки доверия – настоящая задержка

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

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

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

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

Поэтапный план миграции

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

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

Органы стандартизации дают горизонт, который делает это срочным, а не теоретическим: NIST IR 8547 планирует алгоритмы, уязвимые для квантовых атак, на уровне безопасности 112 бит как устаревшие после 2030 года и запрещенные после 2035 года, а более сильные наборы параметров как запрещенные в том же году, без этапа устаревания перед этим.

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

Частые вопросы

Нужно ли нам заменять всю криптографию сразу?

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

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

Что такое криптографическая гибкость и почему начинать с нее?

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

Это также свойство, которое превращает многолетний проект в последовательность развертываемых шагов.

Является ли гибридный режим вдвое сильнее?

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

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

Почему сертификаты устанавливают дедлайн?

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

Листовые сертификаты – это быстрая часть; промежуточные звенья, корни и прошивка – медленная часть.

Что можно сделать сейчас, до урегулирования стандартов?

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

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

Migrating to Post-Quantum Cryptography: What Changes in Practice

Newsroom — Tue, 06 Oct 2026 10:04:07 +0000

By Nika, NodeTimes newsroom.

A post-quantum migration starts with crypto agility, not with choosing an algorithm: until a primitive can be replaced by configuration instead of a release, the scheme you pick expires together with the system. The bottleneck is not the mathematics but the trust infrastructure around it, because certificates, signing roots and device firmware move on their own clocks. The practical question is therefore not which algorithm to adopt, but in what order the components can change.

What has to change, and in what order

Four classes of primitive move on different clocks, and only one of them is a pure software change: key establishment, which a hybrid handshake switches on by configuration, while signatures, certificates and the hardware that stores keys each drag a new root, a new client or a new device behind them.

Post-quantum cryptography (PQC): a family of algorithms built to stay secure against an attacker who holds a cryptographically relevant quantum computer, standardised by NIST as FIPS 203, FIPS 204 and FIPS 205. Key establishment (also called key exchange): the part of a handshake that agrees a shared secret. Digital signatures: the mechanism that proves authorship and integrity. Crypto agility is the ability to swap one primitive for another through configuration rather than a code change; the post-quantum glossary carries the rest of the vocabulary this subject runs on.

The order is not a preference: inventory, then agility, then a hybrid phase, then retirement.

The urgency comes from key establishment rather than signatures. A signature is verified when it is used, so a forged signature has to be produced at that moment, and both what breaks in that scheme and what has to replace it are set out in the explainer on how quantum computers break ECDSA; a key exchange that is recorded now can be decrypted later, which is the harvest now, decrypt later problem and the reason traffic with a long confidentiality lifetime moves first.

Crypto agility first

Agility comes before the algorithm, because a stack that cannot swap a primitive commits to whichever algorithm it adopts first and can only change its mind through a release.

In practice agility is a small set of engineering decisions rather than a product. The algorithm identifier must be negotiated at runtime instead of hard-coded, key material must be stored as opaque bytes rather than fixed-width columns, and the system must be able to hold two schemes at once without a data migration. The test is simple: can you turn the new primitive on for one percent of traffic, and turn it off again, without touching application code?

Hard-coded curve names, key lengths or hash identifiers in configuration that ships with the binary.
Database columns sized for a 32-byte public key that silently truncate a larger one.
Libraries pinned to a single version, where the upgrade is itself the project.
A certificate or key format that encodes the algorithm inside the identifier, so both ends must move on the same day.

The same property decides how fast the later steps go. Post-quantum signatures are larger than the elliptic-curve ones they replace, so anywhere the size leaked into a protocol field, a column width or a rate limit, the size becomes a migration task of its own.

Hybrid mode: classical and post-quantum together

Hybrid mode runs a classical and a post-quantum primitive in the same handshake, which keeps the connection safe as long as neither part is broken; it does not add the two strengths together.

The construction is deliberately conservative: if the post-quantum half turns out to be broken by classical cryptanalysis, the classical half still protects the session, and if the quantum threat arrives earlier than expected, the post-quantum half holds. Hybrid key exchange is what deployments reach for first, because it needs no new trust anchor: the certificates in a hybrid handshake can still be classical, while the key agreement is already quantum-resistant.

For signatures the calculation is different, because a hybrid signature is verified by whoever consumes it, and that consumer has to understand both schemes. Hybrid signatures are a transition device for systems you control on both ends; for anything facing the open internet they are a compatibility tax paid twice.

Mandatory where the traffic is recorded today and read later: long-lived sessions, VPN, backups in transit.
Worth it where both ends are yours and you can retire the hybrid form on a schedule.
Avoidable where the peer still runs a stack that cannot be updated, and the only honest option is to isolate that peer.

The cost is measured in bytes. A classical X25519 key share is 32 bytes; an ML-KEM-768 encapsulation key is 1184 bytes and its ciphertext 1088 bytes, so a hybrid share is roughly thirty-eight times the classical one. The arithmetic does not improve much if you move between parameter sets: the post-quantum share is large in every one of them, so its size becomes an engineering task, a field width or a fragmentation budget, long before it becomes a cryptographic one. The algebra behind that key exchange is set out in the explainer on lattice-based cryptography.

What breaks in the handshake

The handshake breaks first on size, not on security: a larger key share and a larger signature can push the client's first flight past the packet budget and add a round trip.

A TLS 1.3 ClientHello carries the key shares, and when that message exceeds the initial congestion window of a TCP connection it has to be fragmented across several packets. Fragmentation itself is survivable; the price is a second round trip before the server can answer, and a second round trip is exactly what a high-latency connection notices most.

Component	What changes	First move
Transport (TLS)	key exchange gets a post-quantum half	enable a hybrid key exchange where the client stack allows it
Code signing	signing keys and roots must be reissued	inventory every root and intermediate you control
PKI and certificates	issuance, validity and client support	map which clients cannot be updated at all
Hardware and HSMs	new algorithms need new firmware or new devices	list devices with no firmware path
Blockchain and smart accounts	signatures and account abstraction move together	separate the signing scheme from the account model

Signature sizes matter in a different place. In a TLS handshake the server's signature sits in the CertificateVerify message, and an ML-DSA-65 signature is 3309 bytes against 64 bytes for an Ed25519 signature, with a 1952-byte public key against 32. The flight still fits, but every middlebox that parses inside the record layer now has a longer structure to handle, and old parsing code is where the surprises are.

Certificates and trust chains are the real lag

The deadline of a migration is set by the certificate chain, not by the algorithm, because a new key is useless until the client on the other side can verify it.

A certificate is not one file. It is a leaf, one or more intermediates, and a root that lives in a trust store you do not control: a browser, an operating system, a Java keystore, a firmware image. Reissuing your own leaf with a post-quantum signature is a day of work; waiting for every client to accept that signature is the actual schedule. Certificate validity periods cut both ways: a short cycle forces a reissue, which is what a migration wants, while the root and the intermediate that anchor the leaf live in trust stores you do not control and outlast your own schedule.

Network appliances that terminate TLS and cannot be patched, only replaced.
Industrial and medical devices with a firmware update path that requires a service visit.
Smart cards and secure elements where the algorithm is fixed in silicon.
Long-lived code-signing roots whose replacement invalidates every artefact signed under them.

Long-term confidentiality is where the chain hurts most. A session recorded now cannot wait for the client to be upgraded later, so the transport layer moves before the certificate layer is ready, and hybrid mode is what bridges the two.

A staged migration plan

Five steps cover the path from an inventory to a post-quantum default, and each has a completion test that can be run rather than argued about.

Inventory: a list of every primitive, key, certificate and device, with the owner and the update path for each. Done when no public-key operation is left without a named owner.
Agility: the algorithm becomes a configuration value. Done when you can switch one primitive for another in production and roll it back.
Hybrid: the post-quantum primitive runs alongside the classical one. Done when both are visible in the handshake and the failure of either is tested.
Retirement: the classical primitive is switched off. Done when a full client population completes the handshake without it.
Verification: a scheduled check that the inventory still matches reality. Done when a new service cannot reach production with an unlisted primitive.

The standards bodies give the horizon that makes this urgent rather than theoretical: NIST IR 8547 plans quantum-vulnerable algorithms at the 112-bit security level as deprecated after 2030 and disallowed after 2035, and the stronger parameter sets as disallowed in that same year, with no deprecation phase before it.

The order is easy to get backwards: the signature algorithm is the visible part of the work, while the inventory is the step with the longest chain of dependencies behind it. Shipping the inventory is the only step that makes the rest of the plan estimable.

Frequently asked questions

Do we have to replace all cryptography at once?

No. The migration runs component by component, and the first component to change is the one that can accept a new scheme without an architectural change.

That is usually key establishment in transport, because hybrid key exchange needs no new certificate and no new trust anchor.

What is crypto agility and why start there?

Crypto agility is the ability to replace a cryptographic primitive through configuration rather than a release, and without it any algorithm you choose goes out of date with the system around it.

It is also the property that turns a multi-year project into a sequence of deployable steps.

Is hybrid mode twice as strong?

No. Hybrid mode keeps a connection secure as long as neither of its two halves is broken, and it does not combine their strengths into a larger one.

The point of the second half is that it survives a failure of the first, not that it adds to it.

Why do certificates set the deadline?

Because the schedule follows the trust chain rather than the algorithm: as long as a client cannot accept a new signature, replacing the key changes nothing on its own.

Leaf certificates are the fast part; intermediates, roots and firmware are the slow part.

What can be done now, before the standards settle?

Start with the inventory: the list of primitives, devices and certificates whose update schedule you do not control.

An inventory is also the only deliverable that stays useful if a parameter set or a timeline is revised, because it describes your systems rather than a standard.

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

Newsroom — Mon, 05 Oct 2026 10:31:54 +0000

Мосты (bridges) взламывают, потому что они отвечают на вопрос, который ни одна блокчейн-сеть не может проверить самостоятельно: действительно ли что-то произошло в другой сети? Каждая крупная потеря через мост сводится к тому, что на этот вопрос был дан неверный ответ из-за скомпрометированного ключа, поддельного доказательства, оффчейн-сервиса, получившего ложные данные, или разрешения, которое не было отозвано. Суммы различаются; класс ошибки – нет.

Паттерн за каждой крупной потерей через мост

Мост удерживает стоимость в одной сети и выпускает равное количество активов в другой, поэтому его корректность зависит от межсетевого инварианта (cross-chain invariant), а не от одного контракта. Когда инвариант нарушается, активы, выпущенные на стороне назначения, не имеют обеспечения на стороне источника.

Межсетевой инвариант: бухгалтерское правило, согласно которому активы, выпущенные в целевой сети, должны равняться сожженным или заблокированным активам в исходной сети. Merkle proof (меркловое доказательство): компактное доказательство того, что транзакция была включена в блок, которое проверяет мост перед выпуском средств. DVN (Decentralized Verifier Network / Децентрализованная сеть верификаторов): оффчейн-сервис, который наблюдает за одной сетью и удостоверяет сообщение, чтобы другая сеть могла действовать на его основе.

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

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

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

Инциденты и код, который дал сбой

Фигуры ниже взяты из публичных трекеров эксплойтов и отчетов об инцидентах. Столбец «Loss» (потери) фиксирует сумму, украденную в момент инцидента, а не то, что проект потерял в конечном итоге; если источники расходятся в суммах, в таблице приводится одна цифра, а не диапазон.

Инцидент	Дата	Потери	Класс корневой причины	Что могло это выявить
Poly Network	Август 2021	$611 млн	привилегированная функция, вызываемая через межсетевое сообщение	контроль доступа к функциям исполнителя
Wormhole	Февраль 2022	$326 млн	путь проверки принял поддельный аккаунт	проверка входных данных верификации
Ronin Bridge	Март 2022	около $624 млн	5 из 9 ключей, четыре из которых принадлежали оператору плюс один делегированный и никогда не отозванный	гигиена отзыва прав, более высокий порог ключей
Harmony Horizon	Июнь 2022	$100 млн	компрометация 2 из 5 ключей мультиподписи	разделение хранения ключей, M-of-N с независимыми операторами
Nomad	Август 2022	$190 млн	нулевой корень принят как действительный после обновления контракта	тесты обновлений с закрытием отказа, мониторинг инвариантов
BNB Bridge	Октябрь 2022	около $586 млн	принят поддельный IAVL+ доказательство	проверка доказательств против доверенного якоря
KelpDAO rsETH	Апрель 2026	около $292 млн (116 500 rsETH)	один верификатор получил зараженные RPC-данные	второй независимый верификатор, мониторинг инвариантов
Verus-Ethereum	Май 2026	около $11,6 млн	отсутствие проверки соответствия суммы источника выплате	проверка суммы для каждого сообщения

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

Ronin – это случай операционного долга. Девять валидаторов могли подписывать, требовалось пять подписей, и Sky Mavis управляла четырьмя из них. Пятый был доступен через делегирование, предоставленное Axie DAO во время всплеска транзакций; делегирование должно было быть временным, но белый список никогда не был отозван, поэтому компрометация собственных систем оператора было достаточно для достижения кворума.

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

Ни один ключ подписи не был скомпрометирован, ни один контракт не содержал ошибки, и каждая ончейн-транзакция была индивидуально действительна. Мост был приостановлен в течение часа, что предотвратило повторную попытку выпустить еще 40 000 rsETH, но первый выпуск уже был утрачен.

Verus-Ethereum – это случай нарушения связи стоимости. Около $11,6 млн покинули мост после поддельного межсетевого сообщения о переводе, и полученные средства позже были обменены примерно на 5 402 ETH. Около 75% из этой суммы, около 4 052 ETH, вернулись проекту в течение нескольких дней после того, как он предложил вознаграждение в размере 1 350 ETH, которое злоумышленник сохранил. Заявленная корневая причина – это не ошибка подписи или ключа, а отсутствующая проверка того, что сумма, заблокированная на стороне источника, совпадает с суммой, выплаченной на Ethereum: криптографическое доказательство включения было действительным, а экономическое утверждение, которое оно несло, – нет.

Почему «протестировано аудитом» не означает безопасно

Аудит смарт-контракта рассматривает путь кода и, по конструкции, не видит инфраструктуру, которая решает, какие данные передаются коду. Этот пробел стал причиной крупнейшей потери класса state-as-data: KelpDAO.

Аудиты охватывают контракты, а не конечные точки RPC, наборы подписантов или гигиену операторов под ними.
Терпят неудачу предположения: верификатор, доверяющий своему источнику данных, честен ровно настолько, насколько честен этот источник.
Экономический дизайн усиливает ошибку кода: когда проверка подписи неверна, потери равны тому, что мост может отчеканить.
Два последних инцидента тянут в противоположных направлениях. KelpDAO произошел из-за инфраструктуры и оставил контракт нетронутым; Verus произошел из-за пробела в проверке в коде моста. Укрепление одного из них не укрепляет другое.

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

Что фактически снижает риск

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

Требуйте M-of-N аттестацию от независимых операторов, а не N-of-N от стека одного вендора.
Диверсифицируйте источники данных, от которых читает верификатор, и подавайте сигнал тревоги, когда они расходятся, вместо того чтобы молча переключаться на резервный.
Мониторьте сам инвариант: сопоставляйте каждый выпуск с сожжением и подавайте сигнал тревоги при первом несопоставленном событии.
Тестируйте обновления с кейсами fail-closed (отказ в работе при ошибке); нулевой корень Nomad был принят, потому что никто не попробовал случай пустого сообщения.
Пересматривайте делегирования и белые списки по расписанию; каждое временное разрешение остается постоянным риском, пока оно не будет отозвано.
Ограничьте стоимость, которую может выпустить одно сообщение, чтобы ошибка стоила доли, а не всего эскроу.
Сохраняйте возможность приостановки и подтвердите, кто может выполнить эту приостановку в три часа ночи.

Ни один из этих контролей не является экзотическим, и ни один из них не зависит от нового криптографического примитива. То, от чего они зависят, – это отношение к мосту как к двум системам и контракту между ними, а не только к контракту.

Чек-лист проверки для любого, использующего мост

Пройдите эти пять проверок, прежде чем доверять мосту свои средства, и запишите ответы вместе с датой.

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

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

Частые вопросы

Какой самый крупный взлом крипто-моста в истории?

Ronin Bridge остается самой крупной зафиксированной потерей через мост – около $624 млн в марте 2022 года, опережая Poly Network на $611 млн и BNB Bridge на около $586 млн.

Обратите внимание, что скрывает рейтинг: Ronin был сбоем управления ключами, Poly Network – сбоем контроля доступа, и у них нет ничего общего, кроме размера числа.

Мосты все еще взламывают?

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

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

Что такое конфигурация DVN 1-of-1 и почему она опасна?

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

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

Предотвращают ли аудиты взломы мостов?

Нет, но сбои различаются: KelpDAO произошел из-за инфраструктуры вне границы аудита, в то время как Verus был отсутствующей проверкой внутри контракта, поэтому требуются и аудит, и обзор инфраструктуры.

Аудиты остаются необходимыми; отсутствует обзор уровня инфраструктуры, проводимый по тем же стандартам.

Что должен сделать пользователь, чтобы снизить воздействие?

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

Это эвристика снижения риска, а не гарантия; каждый мост в списке выше имел реальную ликвидность и реальных пользователей до дня, когда их не стало.

How Crypto Bridges Get Hacked: A Post-Mortem of Eight Incidents

Newsroom — Mon, 05 Oct 2026 10:11:48 +0000

By Nika, NodeTimes newsroom.

Bridges get hacked because they answer a question that no chain can verify on its own: did something really happen on the other chain? Every large bridge loss comes down to that question being answered wrongly, by a compromised key, a forged proof, an off-chain service that was fed false data, or a permission that was never revoked. The amounts differ; the failure class does not.

The pattern behind every large bridge loss

A bridge holds value on one chain and releases an equal amount on another, so its correctness depends on a cross-chain invariant rather than on a single contract. When the invariant breaks, the assets released on the far side have no backing upstream.

Cross-chain invariant: the accounting rule that assets released on the destination chain must equal assets burned or locked on the source chain. Merkle proof: the compact evidence that a transaction was included in a block, which a bridge checks before it releases funds. DVN (Decentralized Verifier Network): an off-chain service that watches one chain and attests to a message so the other chain can act on it.

Almost every incident reduces to one of four classes of failure:

Key compromise: the attackers hold enough validator keys to sign a fraudulent withdrawal.
Verification-path bug: the contract accepts an attestation it should have rejected.
State-as-data: an off-chain verifier is fed false source-chain data by poisoned infrastructure.
Operational debt: a permission, allowlist or default that should have been closed months earlier.

The terminology of the wider stack stays in the blockchain glossary; this section carries only what the argument needs.

The incidents, and the code that failed

The figures below come from public exploit trackers and from incident reports. The Loss column records what was taken at the moment of the incident, not what a project ultimately lost; where sources disagree on a sum, the table carries one figure rather than a range.

Incident	Date	Loss	Root cause class	What would have caught it
Poly Network	August 2021	$611M	privileged function callable through a cross-chain message	access control on executor functions
Wormhole	February 2022	$326M	verification path accepted a spoofed account	checks on the verification inputs
Ronin Bridge	March 2022	about $624M	5-of-9 keys, four held by the operator plus one delegated and never revoked	revocation hygiene, higher key threshold
Harmony Horizon	June 2022	$100M	2 of 5 multisig keys compromised	key custody split, M-of-N with independent operators
Nomad	August 2022	$190M	a zero root accepted as valid after a contract update	fail-closed update tests, invariant monitoring
BNB Bridge	October 2022	about $586M	forged IAVL+ proof accepted	proof verification against a trusted anchor
KelpDAO rsETH	April 2026	about $292M (116,500 rsETH)	a single verifier fed poisoned RPC data	a second independent verifier, invariant monitoring
Verus-Ethereum	May 2026	about $11.6M	no check that the source amount matched the payout	per-message amount validation

Three rows deserve a longer read, because each one is a lesson the industry has already paid for.

Ronin is the operational-debt case. Nine validators could sign, five signatures were required, and Sky Mavis operated four of them. The fifth was reachable through a delegation the Axie DAO had granted during a transaction surge; the delegation was meant to be temporary, but the allowlist was never revoked, so compromising the operator's own systems was enough to reach the quorum.

KelpDAO is the same failure one layer lower down. The bridge required a single verifier. The intrusion began about six weeks earlier: a developer was socially engineered, session keys were taken from the operator's RPC cloud, and those keys let the attackers replace the node software on two internal hosts the verifier read from. They knocked a third, external host offline to force a failover onto the poisoned pair, and the verifier then signed an attestation describing a burn that had never happened.

No signing key was compromised, no contract contained a bug, and every on-chain transaction was individually valid. The bridge was paused within the hour, which blocked a follow-up attempt to release another 40,000 rsETH, but the first release was already gone.

Verus-Ethereum is the value-binding case. About $11.6 million left the bridge after a forged cross-chain transfer message, and the proceeds were later swapped into roughly 5,402 ETH. About 75% of that, some 4,052 ETH, came back to the project within days, after it offered a 1,350 ETH bounty that the attacker kept. The reported root cause is not a signature or a key failure but a missing check that the amount locked on the source side matched the amount paid out on Ethereum: the cryptographic proof of inclusion was valid, and the economic claim it carried was not.

Why "audited" does not mean safe

A smart contract audit reviews the code path and, by construction, cannot see the infrastructure that decides what the code is told. That gap is where the largest state-as-data loss came from: KelpDAO.

Audits cover contracts, not the RPC endpoints, signer sets or operator hygiene underneath them.
Assumptions are what fail: a verifier that trusts its data source is only as honest as that source.
Economic design amplifies a code bug: when a signature check is wrong, the loss equals whatever the bridge can mint.
The two most recent incidents pull in opposite directions. KelpDAO came from infrastructure and left the contract untouched; Verus came from a validation gap in bridge code. Hardening one of those does not harden the other.

The practical test is blunt: ask which entities could falsify the message your contract accepts, and whether any of them were inside the audit scope. User-facing fraud is a different problem with a different playbook, covered in the main threats in crypto.

What actually reduces the risk

The controls that map onto those failure classes are operational before they are cryptographic, and each one can be checked today.

Require M-of-N attestation from independent operators, not N-of-N from one vendor's stack.
Diversify the data sources a verifier reads from, and alert when they disagree instead of failing over silently.
Monitor the invariant itself: match every release against a burn, and alert on the first unmatched event.
Test updates with fail-closed cases; Nomad's zero root was accepted because nobody tried the empty-message case.
Review delegations and allowlists on a schedule; every temporary permission stays a permanent risk until it is revoked.
Cap the value a single message can release, so a bug costs a fraction rather than the whole escrow.
Keep the ability to pause, and confirm who can execute that pause at three in the morning.

None of these controls is exotic, and none of them depends on a new cryptographic primitive. What they depend on is treating a bridge as two systems and a contract between them, rather than as a contract alone.

A verification checklist for anyone using a bridge

Run these five checks before trusting a bridge with value, and write the answers down with the date.

Count the verifiers: how many independent attestations are required, and who operates them?
Map the data path: which RPC endpoints and providers feed the verifier, and what happens on failover?
Read the change log: when was the last configuration change, and was a temporary permission revoked afterwards?
Check the invariant monitoring: can the bridge itself detect a release with no matching burn, and how fast?
Check the exit: what is the maximum value one message can release, and who can pause the bridge?

The answers change over time; the questions do not, which is why the date on an answer matters as much as the answer. How a single endpoint becomes a trust boundary is the subject of the breakdown of blockchain RPC.

Frequently asked questions

What is the largest crypto bridge hack ever?

Ronin Bridge remains the largest recorded bridge loss at about $624 million in March 2022, ahead of Poly Network at $611 million and the BNB Bridge at about $586 million.

Note what the ranking hides: Ronin was a key-management failure, Poly Network an access-control failure, and they share nothing except the size of the number.

Are bridges still being hacked?

Yes, and the vector has moved: the largest recent loss came not from a contract bug or a stolen key but from poisoned RPC infrastructure.

The follow-up attempt in that incident was blocked by a pause, which is the control that decided the final size of the loss.

What is a 1-of-1 DVN configuration and why is it dangerous?

It means one verifier is sufficient to release funds, so the entire security budget of the bridge collapses into the infrastructure of a single operator.

A multisig with one required signer is a single signature with extra steps, and the same logic applies to any bridge whose quorum threshold is one.

Do audits prevent bridge hacks?

No, but the failures differ: KelpDAO came from infrastructure outside the audited boundary, while Verus was a missing validation inside the contract, so both an audit and an infrastructure review are required.

Audits remain necessary; what is missing is an infrastructure-layer review held to the same standard.

What should a user do to reduce exposure?

Treat bridged assets as credit risk rather than as a deposit: prefer routes with several independent verifiers, limit the amount held in any wrapped asset, and check whether the bridge publishes invariant monitoring.

That is a risk-reduction heuristic rather than a guarantee; every bridge on the list above carried real liquidity and real users until the day it did not.