Это редакционная статья Шиноби, преподавателя-самоучки в сфере Биткойна и ведущего подкаста, ориентированного на технологию Биткойна. Freebitcoin — заработок криптовалют бесплатно.
Большой сюрприз: биткойнеры яростно спорят о предлагаемом изменении, которое будет включено в следующий релиз Bitcoin Core. Замена на плату (RBF) — это функция политики мемпула, которая была предложена в 2015 году, чтобы дать пользователям инструмент для борьбы с быстрыми скачками платы, которые приводят к тому, что их транзакции застревают неподтвержденными в мемпуле на длительные промежутки времени.
Очевидно, что это станет проблемой для любого использования Биткойна, если объем транзакций в среднем будет постоянно превышать количество транзакций, которые могут быть обработаны в блокчейне, поэтому, если вы не думаете, что этого никогда не произойдет, это необходимая функция в сети.
Замена транзакций на самом деле была включена и возможна в первоначальном выпуске программного обеспечения до того, как Сатоши Накамото исчез. В конечном итоге он отключил эту функцию, потому что ее первоначальная реализация создавала вектор для атак типа «отказ в обслуживании» на узлы. Его реализация позволяла заменять любую транзакцию без уплаты более высокой комиссии, что, по сути, позволило бы пользователям отправить транзакцию, а затем начать транслировать в сеть неограниченное количество замен. Это, очевидно, позволило бы спамить узлы огромным количеством данных, не требующих доказательства выполнения работы, и непомерно увеличило бы стоимость управления узлом.
За прошедшие годы обсуждалось несколько различных предложений по обновленной и более безопасной схеме замены транзакций. Мы быстро пройдемся по всем из них.
Полная RBF
Самый простой вариант RBF. Любая транзакция может быть заменена до тех пор, пока замена исходной транзакции платит более высокую ставку, чем та, которую она заменяет. Таким образом, все транзакции могут быть заменены, но требование платить более высокую плату при каждой замене предотвращает бесконечное количество новых версий транзакций, перегружающих узлы.
RBF «первый-виденный-безопасный
Это предложение позволяет заменять все транзакции в mempool, с одной особой оговоркой: все выходы исходной транзакции также должны быть включены в заменяющую транзакцию, включая выход изменения. Это по-прежнему требует увеличения платы за замену транзакции, но требование сохранения тех же выходов означает, что вам придется добавить новый вход и второй выход изменения, потому что ни один из исходных выходов не может быть изменен. Это приводит к тому, что более крупные транзакции вынуждены платить больше в общей сумме сборов, чтобы гарантировать, что замена платит более высокую ставку сбора.
RBF с задержкой
Здесь предлагалось разрешить замену любой транзакции в mempool, но только после того, как пройдет определенное количество блоков с тех пор, как узел увидел исходную транзакцию. Идея заключалась в том, что это позволит быстрее заменять и подтверждать застрявшие транзакции в условиях высоких комиссий, а временная задержка в том, как скоро транзакция может быть заменена, предотвратит попытки двойных трат с нулевым подтверждением.
Opt-In RBF
Это то, что было реализовано в 2016 году, как определено в BIP 125. Транзакции могут быть заменены, только если они установили в транзакции специальный флаг, разрешающий замену, или если это сделал один из их предков в случае цепочки неподтвержденных транзакций, чтобы люди, получающие средства, могли знать, будет ли неподтвержденная транзакция заменена в мемпуле.
Большая полемика сегодня связана с тем, что в следующем выпуске Core, 0.24, будет введен флаг полной политики RBF mempool. Что это означает? Это даст пользователям настраиваемую опцию для изменения локальной политики mempool с opt-in RBF на full RBF; по умолчанию опция будет отключена (узлы будут использовать full RBF). Почему же люди возмущены этим изменением? Предприятия, принимающие транзакции с нулевым подтверждением, зависят от того, что супербольшинство мемпулов узлов отказываются заменять транзакции, не выбравшие RBF, флагом транзакции. Для этого они тактически соединяют свой узел с большим количеством других узлов, разбросанных по всей сети. Это позволяет им очень быстро обнаружить присутствие в сети транзакции с двойными расходами, поскольку это должно быть сделано почти сразу, если транзакция не помечена как RBF, чтобы иметь хорошие шансы попасть к майнерам. Стоит также отметить, что каждый бизнес в сети не может этого сделать, не занимаясь фактически сибиллингом сети. Эти предприятия утверждают, что полный RBF «ломает» их бизнес-модель использования RBF. Некоторые даже критикуют разработчиков Core за «принуждение» к изменениям, которые негативно влияют на эти предприятия.
Простая реальность заключается в том, что двойные расходы были и всегда будут возможны, опциональный RBF или полный RBF ничего не меняет. Более того, простое создание опции для изменения собственной локальной политики mempool (которая по умолчанию отключена) никоим образом не диктует никому изменений, это опция, предоставленная пользователям для самостоятельного выбора. В конечном итоге, когда речь заходит о том, какие транзакции будут включены в следующий блок, единственные мемпулы, которые имеют значение, — это мемпулы майнеров. Мемпулы отдельных пользовательских узлов — это не что иное, как гирлянда памяти, конечная цель которой — передать все эти неподтвержденные транзакции майнерам, чтобы в конечном итоге они были включены в блок.
Политика Mempool используется в качестве своего рода мягкого механизма безопасности для предотвращения атак типа «отказ в обслуживании» на узлы и защиты пользователей от того, чтобы они сами себя подставили под удар сложными транзакциями и скриптами. Многие типы транзакций действительны по консенсусу, могут быть включены в блок, но не будут переданы узлами в соответствии с политикой mempool по умолчанию. Однако это совершенно не мешает решительному пользователю передать транзакцию, которая будет проигнорирована узлами сети, непосредственно майнеру.
В этом и заключается суть вопроса. Все, что требуется от майнеров, это установить API для прямой передачи транзакций им, что многие уже сделали, и ограничения политики mempool по всей сети не имеют значения. Вы можете просто отдать транзакцию напрямую майнерам и обойти все правила о том, когда что-то может быть заменено в мемпуле других узлов. Подумайте о стимулах этого — если есть деньги, которые можно заработать на добыче определенного класса транзакций, но мемпулы по всей сети не будут их передавать, что вы будете делать как майнер? Просто принимать их напрямую. Чем больше сокращается субсидирование и растет доля транзакционных сборов в доходах майнеров, тем более неизбежным становится то, что майнеры будут просто напрямую принимать замены, которые платят более высокие сборы, если узлы сети не будут передавать их косвенно. Это неизбежно.
Это изменение не меняет политику mempool по умолчанию в Bitcoin Core, оно просто предоставляет возможность отдельным операторам узлов изменить свою локальную политику mempool, если они того пожелают.
И я хотел бы добавить, что это выбор, который всегда был доступен, если пользователи решали модифицировать свой клиент. Все, что это делает, это упрощает выбор, который всегда был доступен пользователям. Стимулы неизбежно приведут к состоянию, когда все транзакции будут заменяемыми, если майнеры будут действовать экономически рационально — это неизбежно. Вопрос лишь в том, должно ли программное обеспечение отражать эти стимулы, позволяя отдельным пользователям самим решать, какую политику использовать для своего мемпула, или люди должны просто сидеть и позволять распространению транзакций централизоваться вокруг прямого подчинения самим майнерам?
Конечный результат один и тот же, но ожидание того, что майнеры будут тяготеть к прямой подаче транзакций, будет иметь очень негативные последствия. Это будет иметь последствия для конфиденциальности людей, транслирующих транзакции в сеть, и может иметь очень негативные последствия для способности пользователей решать, какую комиссию платить за транзакцию. Если большая часть ожидающих транзакций больше не будет публично транслироваться в сети, то пользователи будут иметь неполное представление о том, против кого они делают ставки на включение в блок. Майнеры могут даже лгать о распределении комиссии, чтобы побудить пользователей платить больше, чем они должны.
Единственный реальный недостаток доступности этой опции заключается в том, что полный RBF может работать нестабильно, если только небольшая часть сети, включая майнеров, решит включить полный RBF. Однако, с точки зрения переходного периода, это ничем не отличается от обновления до SegWit. Во время того переходного периода не обновленные узлы не передавали транзакции SegWit, поскольку не могли их подтвердить, поэтому в тот период наблюдалась та же динамика непоследовательного распространения, пока достаточное количество пользователей не обновилось. Но в конечном итоге это не изменило того факта, что решение об обновлении принимали отдельные пользователи.
В конечном счете, борьба с полной RBF просто отрицает реальность стимулов в сети. Никому ничего не диктуется, опция конфигурации просто предоставляет отдельным пользователям выбор, который они должны сделать сами. Мне кажется странным, что одновременно так много людей игнорируют реальность стимулов, утверждая, что небезопасное средство получения платежей может быть сохранено в безопасности вопреки стимулам, так же как люди утверждают, что пользователям программного обеспечения не должно быть позволено выбирать, как настраивать свое собственное программное обеспечение.
Мой узел, мои правила, верно?
Это гостевая статья Shinobi. Высказанные мнения являются полностью его собственными и не обязательно отражают точку зрения BTC Inc или Bitcoin Magazine.