Двойная трата — попытка потратить одни и те же монеты дважды, отправив конфликтующие транзакции в сеть. В публичных блокчейнах это возможно до наступления достаточной финальности: пока транзакция легко заменяема/откатываема (из-за реорганизаций или правил замены), получатель несёт риск не получить оплату.
Базовые моменты
- Источник риска — конкурирующие истории. Узлы временно могут видеть разные ветви цепочки; более «тяжёлая/финальная» ветвь побеждает.
- Модели учёта. В UTXO-сетях конфликтуют два расходования одного и того же выхода; в аккаунт-модели (напр., Ethereum) порядок определяет nonce, но реорганизации всё ещё возможны.
- Типовые сценарии. «Zero-conf» платежи (принятие средств без подтверждений), атаки гонкой распространения (race), «предмайненная» Finney-атака, атаки при контроле значительной мощности/стейка (51%/цензурирование).
- Комиссии и приоритет. Более высокая комиссия облегчает включение транзакции в блок, но не даёт абсолютной гарантии до финальности.
Как это работает / примеры
- Race-атака (zero-conf). Атакующий отправляет продавцу оплату с низким приоритетом и параллельно вещает конфликтующую транзакцию самому себе с более высоким приоритетом. Если вторую включают раньше — продавец остаётся без средств.
- Finney-атака. Майнер предварительно майнит блок с транзакцией «самому себе», затем оплачивает покупку конфликтующей транзакцией и сразу публикует блок. Принимая zero-conf, продавец рискует.
- 51%/цензурирование. Контроль большей части хешрейта/стейка позволяет навязывать ветвь с «откатом» платежа. Это дорого и заметно, но возможно при централизованной мощности.
- Реорги и заменяемость. Кратковременные реорганизации (перестройка последних блоков) нормальны для сетей; в аккаунт-модели порядок отправок задаёт nonce, а «замена по цене» (replacement) может вытеснить неподтверждённую транзакцию той же учётки.
Как снижать риск (практика)
| Мера | Идея | Комментарии |
|---|---|---|
| Ждать подтверждений | BTC-платежи — дождаться N блоков; чем больше — тем выше уверенность. | Для крупных сумм — больше подтверждений; для мелких — допустим разумный порог. |
| Финальность в PoS | Ориентироваться на чекпойнты/эпохи финальности. | После финализации откат экономически и технически маловероятен. |
| Анализ мемпула | Проверять конфликты/двойники до отгрузки товара. | Полезно для онлайн-торговли и платёжных шлюзов. |
| Политика zero-conf | Не принимать zero-conf для ценного товара/услуги. | Если и принимать — с лимитами, антифродом и «поведенческими» правилами. |
| Комиссии/приоритет | Требовать «адекватную» комиссию от плательщика. | Снижает время до включения, уменьшает окно атаки. |
| Ограничения выдачи | В офлайн-точках — задержка до подтверждений/финальности. | Процедура зависит от стоимости покупки и репутации клиента. |
Чек-лист для продавца/сервиса
1. Определите порог подтверждений по типам товаров/сумм; для больших сумм — повышенный порог.
2. В PoS-сетях ориентируйтесь на финальность эпох/чекпойнтов; до них — не оказывайте безотзывные услуги.
3. Используйте мониторинг мемпула и алерты на конфликтующие транзакции.
4. Для онлайн-сервисов — антифрод: белые списки, лимиты, «тест-платёж» перед крупной поставкой.
5. Учитывайте сетевые условия: при перегрузке сети повышайте требования по подтверждениям/комиссиям.
6. Храните основные активы в self-custody и разделяйте «операционные» и «холодные» балансы (см. кошелёк, холодный кошелёк).
Плюсы и ограничения мер защиты
| Подход | Плюсы | Минусы/ограничения |
|---|---|---|
| Подтверждения/финальность | Простая, проверенная защита. | Увеличивает время расчётов; UX может пострадать. |
| Аналитика мемпула | Раннее выявление конфликта. | Требует инфраструктуры/интеграции. |
| Политики риска | Гибко по категориям товаров/сумм. | Нужна дисциплина и обучение персонала. |
Частые вопросы (FAQ)
Сколько подтверждений «достаточно»? Зависит от сети/суммы. Для BTC розница часто принимает 1–3 подтверждения, крупные суммы — больше. В PoS-сетях ждут финальности чекпойнта.
Опасно ли принимать zero-conf? Да, риск выше. Это допустимо для мелких платежей при антифроде и проверках, но не для дорогих товаров/безотзывных услуг.
Помогает ли высокая комиссия от плательщика? Сокращает время ожидания и окно атаки, но до финальности не даёт абсолютной гарантии.
В Ethereum есть double spend? Аккаунт-модель с nonce предотвращает конфликт «двух разных получателей» для одного nonce, но реорги возможны; до финальности транзакция может быть вытеснена заменой. Ждите финальности и проверяйте статус.
Чем double spend отличается от «replay»? Double spend — конфликт в одной сети. Replay — повтор той же транзакции в другой сети/форке при совпадающих правилах, если нет защиты; это тема отдельной модели рисков (см. кроссчейн и форки).