Дебаты о RBF – вопрос стимулов и индивидуального выбора

К большому удивлению, биткоинеры яростно спорят о предлагаемых изменениях, которые будут включены в следующую версию Bitcoin Core. Замена транзакции новой с повышением комиссии (англ. replace-by-fee или RBF) – это особенность политики мемпула, которая была предложена в 2015 году, чтобы дать пользователям инструмент для борьбы с быстрыми скачками комиссий, которые приводят к тому, что их транзакции не подтверждаются в мемпуле в течение длительного времени.

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

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

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

Full RBF

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

First-seen-safe RBF

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

Отложенный RBF

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

Opt-in RBF

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

Большое противоречие сегодня заключается в том, что в следующем выпуске Core, 0.24, будет введен full RBF в политике мемпула. Что это значит? Это даст пользователям возможность изменить свою локальную политику мемпула с opt-in RBF на full RBF; по умолчанию эта опция будет отключена (узлы будут использовать full RBF). Так почему же люди восстают против этого изменения? Компании, которые принимают транзакции с нулевым подтверждением, зависят от подавляющего большинства мемпулов узлов, отказывающихся заменить транзакции, которые не выбрали RBF для транзакции. Они делают это, тактически соединяя свой узел с большим количеством других узлов, разбросанных по всей сети. Это позволяет им очень быстро обнаруживать в сети транзакцию с двойной тратой, так как это нужно сделать почти сразу, если транзакция не помечена как RBF, чтобы иметь хорошие шансы дойти до майнеров. Также стоит отметить, что бизнес в сети не может сделать это без успешной атаки на сеть. Эти бизнесы утверждают, что полная RBF «ломает» их бизнес-модель использования RBF. Некоторые даже критиковали разработчиков Core за то, что они «навязывают» изменения, негативно влияющие на этот бизнес.

Простая реальность такова, что двойные траты были и всегда будут возможны, opt-in RBF или полная RBF ничего не изменит. Кроме того, простое создание опции для изменения вашей собственной локальной политики мемпула (которая отключена по умолчанию) никоим образом не диктует изменения никому, это возможность, предоставленная пользователям, чтобы сделать выбор для себя. В конце концов, когда дело доходит до того, какие транзакции на самом деле будут включены в следующий блок, единственные мемпулы, которые имеют значение, – это мемпулы майнеров. Мемпулы отдельных пользовательских узлов – это не что иное, как последовательная цепочка хранения памяти с конечной целью распространения всех этих неподтвержденных транзакций среди майнеров, чтобы в итоге они могли быть включены в блок.

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

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

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

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

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

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

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

Мой узел, мои правила, верно?

Это гостевой пост Шиноби, преподавателя-самоучки в Биткоин-сфере и ориентированного на технологии ведущего подкастов о Биткоине. Точки зрения, высказанные в этой статье, принадлежат автору и не обязательно отражают взгляды BTC Inc. или Bitcoin Magazine.