Разработка программного обеспечения для механизма консенсуса

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

Например, несмотря на то что майнеры теоретически могут изменять правила простым большинством (51%), они ограничены тем, что другие компоненты сети имеют полное право выражать свое согласие или несогласие с этими изменениями. Если майнеры действуют в одностороннем порядке, то остальные члены сети могут просто отказаться следовать за ними, поддерживая экономическую деятельность в цепочке меньшинства. При отсутствии экономической активности (транзакции, торговые сделки, кошельки, обменные и конвертационные операции) майнеры будут генерировать не имеющие никакой ценности денежные единицы в пустых блоках. Такое распыление ресурсов и мощностей приводит к ситуации, в которой либо все участники непременно должны согласовывать свои действия, либо внесение изменений становится невозможным. Текущим состоянием является стабильное состояние биткойн-системы с возможностью внесения лишь небольшого количества изменений при условии достижения убедительного консенсуса, поддерживаемого подавляющим большинством голосов. Пороговое значение 95% для принятия неустойчивых разветвлений отражает это реальное состояние.

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