Накануне релиза Bitcoin Core v30 разработчики сняли планы «деприкайта» настроек datacarrier/datacarriersize, оставив операторам нод возможность вручную ограничивать объём данных в OP_RETURN. При этом новые правила стандартности в v30 всё равно расширяют допуск таких транзакций по умолчанию и меняют семантику лимитов. Ниже — что изменится на практике, где риски и как действовать операторам нод и провайдерам инфраструктуры.

Контекст: зачем вообще спор вокруг OP_RETURN

OP_RETURN — это способ записывать произвольные данные в блокчейн биткоина с «неснимаемым» выходом (такие выходы не попадают в UTXO-набор, но данные навсегда остаются в цепочке). Исторически Core ограничивал объём таких данных на уровне политики релея (а не консенсуса): по умолчанию сети легче игнорировать «данные ради данных», сдерживая спам и рост нагрузки на узлы. Однако в последние годы часть трафика всё равно уходила в обход старых ограничений (через альтернативные конструкции в witness-скриптах), и вопрос «держать/снимать» дефолтные лимиты стал политикой противодействия блоатингу и цензуре одновременно.

Что меняется в v30 — по пунктам

1) Настройки datacarrier и datacarriersize остаются доступными

Изначально в ветку v30 заходили изменения с предупреждением о будущем удалении этих опций (deprecated). В финальной редакции предупреждение снято: операторы нод по-прежнему смогут вручную ограничивать приём/релеинг транзакций с данными в OP_RETURN или вовсе их отключать. Это ответ на многочисленные обращения операторов и часть компромисса «перед релизом».

2) Дефолтная политика релея — более «либеральная»

Даже при сохранении ручной настройки, в v30 меняется базовая политика стандартности:

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

3) Это не изменение консенсуса

Речь идёт о policy/standardness (что нода по умолчанию готова ретранслировать и включать в мемпул). Консенсусные правила сети при этом не меняются. Но для операторов: «дефолты имеют значение» — именно они определяют, что массово попадает в мемпулы и быстрее добывается майнерами.

Почему решение «передумать» по деприкайту важно

Отмена планов убрать опции datacarrier/datacarriersize — сигнал экосистеме: Core сохраняет право узла несогласиться с дефолтами. На уровне практики это:

• снижает риски для операторов, хранящих архивные копии блокчейна (опасения по «незаконному контенту» в данных не обнуляются, но выбор остаётся у владельца узла);
• снимает напряжение между ветвями Core и Knots (у Luke Dashjr и части операторов были принципиальные возражения к «размыванию» лимитов);
• оставляет пространство для дальнейшей настройки сети сообществом — без форков и «жёстких» решений.

Практика: как подготовить ноду к v30

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

Чек-лист настройки

1. Зафиксируйте текущие значения datacarrier/datacarriersize перед апдейтом (скрин/бэкап конфигурации).
2. Переоцените порог: учитывайте, что в v30 параметр может трактоваться иначе (из-за допуска нескольких OP_RETURN-выходов). Если у вас было «83» как «≈80 байт», на v30 это может означать суммарный объём по множеству выходов — тестируйте на testnet/regtest.
3. Обновите алерты по росту мемпула/IO и по доле транзакций с OP_RETURN, чтобы вовремя видеть всплески «нефинансовых» данных.
4. Проверьте совместимость ваших фильтров/плагинов (orphan-пулы, mempool policy) — особенно если вы поддерживаете приватные пути подачи транзакций.
5. Коммуницируйте со своими пользователями/клиентами: сообщите, будете ли вы менять политику релея по данным; обозначьте причину (производительность, юрриски, идеология узла).

Аргументы «за» и «против»: позиция рынка и разработчиков

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

Противники видят риск «блоатинга» и роста требований к узлам, юридические риски (если на архивном узле окажется запрещённый контент), а также угрозу смещения фокуса сети от «P2P-денег» к «хранению файлов». Они указывают, что дефолты формируют реальные поведенческие паттерны: то, что принимается по умолчанию, быстрее становится нормой.

Что это значит для RU-аудитории и операторов

• Для провайдеров нод/эксплореров/архивов: взвесьте правовые риски и определите политику по OP_RETURN (жёсткая фильтрация vs. laissez-faire). Важно документировать её публично.
• Для корпоративных держателей full node: заложите место и I/O-резерв, особенно если у вас архивный режим (без pruning). OP_RETURN не попадает в UTXO, но данные остаются в блоках — а это дисковая ёмкость и резервное копирование.
• Для кошельков/провайдеров платежей: тестируйте UX на фоне возможного роста «шумовых» транзакций и колебаний комиссии. Отстройка fee-политик и мемпул-эвристик критична.

Техническая справка: OP_RETURN, UTXO и «прюнинг»

OP_RETURN-выходы — это «неснимаемые» (provably unspendable) выходы. Они не увеличивают UTXO-набор, потому что с точки зрения валидатора это мусор, который никогда не будет потрачен. Однако они увеличивают размер блоков и, следовательно, потребности в хранении и пропускной способности. Узлы с включённым pruning могут удалять старые блок-файлы, но архивные/публичные узлы хранят всё содержимое блокчейна.

Как это вписывается в идеологию биткоина

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

Что смотреть дальше

• Поведение мемпулов и майнеров после выхода v30: вырастет ли доля транзакций с несколькими OP_RETURN и суммарным полезным объёмом данных.
• Реакция альтернативных клиентов (Knots) и доля их узлов в сети.
• Возможные уточнения политики в последующих минорных релизах и комментарии мейнтейнеров Core.

Итог

Перед самым релизом v30 команда Core сделала шаг назад от жёсткого сценария «убрать конфиги» и оставила операторам право выбора. Но базовый курс на более «открытый» допуск OP_RETURN по умолчанию сохраняется. Для экосистемы это означает испытание «дефолтами»: станет ли релей-слой терпимее к «нефинансовым» данным и как быстро рынок адаптируется.

Полезные ссылки (по теме на 24k.ru)

• Биткоин (Bitcoin): базовые понятия
• Credible neutrality: зачем сети «беспристрастность»
• Блокчейн-трилимма: децентрализация vs масштаб