Длительный спор о размерах блока и недавнее внедрение изменений в протокол Биткоина подчеркнуло, что не все узлы Биткоина принимают одни и те же правила – и, что ещё более важно, не все команды разработчиков применяют схожую политику, когда дело доходит до осуществления этих правил.
Команда разработчиков Bitcoin Core, исторически основного клиента для цифровой валюты, требует, чтобы сообщество сначало широко приняло некоторые изменения правил, например, увеличение размера блока, в то время как другие изменения не приводятся к тем же самым стандартам.
А ещё можно сказать, что некоторые форки Биткоина, такие, как Bitcoin LJR, в целом принимаются сообществом разработчиков, в то время как другие, например, Bitcoin Classic, встречают у них большое сопротивление. Некоторым кажется, что это не последовательно.
Однако такое отличие можно объяснить. Определённые изменения, реализованные в некоторых форках, оказывают на сеть Биткоина более сильное влияние, чем другие изменения. Или более конкретно: разные изменения правил затрагивают различные слои сети Биткоина. И некоторые изменения правил могут привести к разделению сети Биткоина, в то время как другие не могут.
Чтобы классифицировать эти отличия, разработчик Bitcoin Core и директор Ciphrex, Эрик Ломброзо предложил выделить четыре уровня во всех Bitcoin Improvement Proposals (BIP). Есть четыре основных уровня сети Биткоина, и мы вкратце опишем каждый.
Правила консенсуса
Правила консенсуса является самыми важными для Биткоина. Они устанавливают – среди многих других вещей – количество биткоинов вознаграждения за блок, сложность майнинга, тип используемого доказательства работы, и, наконец, размер блока.
Эти правила так важны ещё и потому, что они определяют, какие из блоков полные узлы будут считать валидными. И если все полные узлы пользуются одними и теми же правилами консенсуса, это даёт гарантию, что все они будут поддерживать одну и ту же копию блокчейна.
Если разные узлы будут пользоваться различными правилами консенсуса, есть риск, что одни узлы будут принимать блоки, отвергнутые другими узлами. Такое несоответствие вызывает поддержку разными узлами полностью несовместимых блокчейнов, приводя к быстрому разделению сети Биткоина.
Правила консенсуса Биткоина могут быть изменены двумя способами. Изменения, которые добавляют дополнительные правила для протокола, (делая ранее валидные блоки инвалидными), называются софт форками. Софт форки требуют большинства хэширующих мощностей майнеров, чтобы изменения были приняты. Блоки, которые создаются по новым правилам, будут валидными и по старым правилам, так что узлам не требуется обновления, чтобы продолжать майнить самую длинную цепочку.
Однако майнеры, которые не обновились, будут продолжать создавать блоки, не подходящие по новым правилам, зря тратя хэширующую мощность. И те полные узлы, которые не прошли обновления, больше не будут в состоянии проверить, какие блоки подходят по новым правилам, требуя от них дополнительных подтверждений, чтобы достигнуть требуемого уровня безопасности.
По этим и другим причинам, команда разработчиков Bitcoin Core требует супер большинства, то есть 95 процентов хэширующих мощностей, чтобы произошло принятие софт форка.
Изменение правил консенсуса, которое изменяет сами правила протокола называется хард форком. Хард форк требует, чтобы обновление приняли все полные узлы. Любой узел, который не примет изменений, тем самым отпадает от самой длинной цепочки и и может выбрать остаться на «старой» цепочке. Это может разделить сеть Биткоина способом, уже описанным выше. Сколько времени бы продолжилось такое разделение? Это не технический вопрос, это скорее вопрос из социологии, экономики, теории игр и подобных областей.
Софт форки изменяют правила консенсуса, не затрагивая сам консенсус – и в случае самого худшего сценария – приведёт к тому, что меньшинство манеров будут впустую тратить хэширующие мощности, и (немного) ухудшит безопасность полных узлов.
Хард форк, изменяющий правил консенсуса без согласия всех участников сети – в случае самого худшего сценария приведёт к разделению сети Биткоина.
Уровень связи между узлами
Уровень связи между узлами сети Биткоина определяет, как полные узлы делятся данными и какими именно данными они могут делиться. Сюда входят правила протокола, которые касаются отправки и получения блоков и транзакций, а также на этом уровне действуют специальные пакеты данных, такие, как Segregated Witnesses или Invertible Bloom Lookup Tables.
Более важно, что уровень связи между узлами должен гарантировать, что новые блоки найдут для себя путь через всю сеть, так же, как и пакеты данных для проверки блоков. Если эта релейная политика перестанет работать, она может привести к сетевому разделению, где различные узлы пользуются разными версиями блокчейна — по крайней мере, пока блоки не найдут путь через всю сеть снова.
Но, в противоположность правилам согласия, это не является огромной проблемой, если узлы ведут различную релейную политику. Так как каждый из узлов передаёт блоки как минимум восьми клиентам, такое усиление позволяет убедиться, что все узлы получили все блоки, даже если некоторые из них не передаются правильно.
У узлов есть ещё больше свободы действий, когда дело доходит до передачи транзакций. Большинство узлов сети Биткоина сегодня пользуются правилом «первого взгляда»: если они получают две или больше конфликтующих транзакций, то принимают первую, а остальные отвергают.
Но сейчас всё больше узлов применяет правило «замены сбором», и это значит, что они самостоятельно выбирают транзакции, и включают те из них, где выше комиссии, не зависимо от того, какая транзакция находится на первом месте. Кроме того, есть узлы, которые отвергают определённые типы транзакций или не передают транзакций вообще. Однако в конечном счёте только майнеры определяют, какие транзакции включаются в блоки и почему.
Изменения без консенсуса на уровне связи между узлами могут – в случае самого худшего сценария – привести к разделению сети. Этот риск существует, если блоки не могут найти себе путь через всю сеть.
Хотя такое разделение автоматически устранится, если перезапустить сеть.
Если изменения касаются только транзакций, они могут – в случае самого худшего сценария – помешать некоторым транзакциям подтвердиться. Также это уменьшит надёжность для не подтверждённых транзакций. Но это не может привести к разделению сети.
Прикладные программные интерфейсы и вызовы удалённой процедуры
Прикладные программные интерфейсы (Application Programming Interface API) и вызовы удалённой процедуры (Remote Procedure Call RPC) являются уровнем связи, который находится поверх уровня свзи между узлами. Многие приложения для сети Биткоина – такие, как мобильные кошельки и проводники блоков – связываются с блокчейном через этот уровень, делая подключение с помощью API или программной библиотеки.
Если на этом уровне произойдет сбой, все подключенные программные приложения потеряют способность надёжно связываться с сетью Биткоина. Мобильные кошельки не будут знать, получили ли они биткоины, и проводники блоков не узнают, когда найден новый блок. Конечно, все остальные пользователи сети Биткоина ничего не заметят — для них всё останется по-прежнему.
Изменения API и RPC без консенсуса могут–– в случае самого худшего сценария – полностью отключить пользователей на этом уровне от сети Биткоина. Но они также не могут привести к разделению сети.
Приложения
Последний уровень, уровень приложения, задаёт, как приложения для Биткоина создают и используют разные типы данных. Это не затрагивает сеть напрямую, но полезно для синхронизации между приложениями.
Уровень приложения может включать, например, форматы адреса, способ генерации приватных ключей или сохранение резервных копий файла кошелька. Если один из кошельков сгенерирует адрес, который другой кошелёк посчитает недопустимым, транзакции между ними будут не возможны. Или если один из кошельков использует один метод для создания фразы, позволяющей восстановить адрес, а другой кошелёк использует другой метод, пользователь не сможет восстановить свои закрытые ключи, пользуясь другим кошельком. То же можно сказать и о резервных копиях файлов кошельков.
Изменения на уровне приложений без консенсуса могут– случае самого худшего сценария – помешать некоторым пользователям проводить транзакции между собой и создать для них другие неудобства. Такие изменения не могут привести к разделению сети.
