Мало кто любит вспоминать о проблемах Биткоин, тем не менее они есть (о чем мы писали ранее: здесь и здесь). Проблемы эти, если их не решать, способны привести к централизации, а значит разрушить основную идею децентрализованных цифровых наличных без единого центра управления. Также, пусть рост количества пользователей и транзакций и остался на постоянной отметке либо пошел на спад, это не значит, что очередного взрывного роста популярности не случится в будущем, а значит система Биткоин должна суметь принять будущий вызов. Вашему вниманию предлагаются размышления на эту тему главного разработчика протокола и ПО Bitcoin Core Гэвина Андресена, опубликованные на днях в блоге Bitcoin Foundation.
Дорожная карта масштабирования
Мои грубые прикидки об оптимизации объявления новых блоков привели к большому обсуждению вопросов масштабирования вообще. Имелось некоторое недопонимание о том, что оптимизация объявления новых блоков станет серебряной пулей, которая бы решила абсолютно все проблемы Биткоин, с которыми тот сталкивается по мере роста. Эта статья призвана наметить пути технических модификаций протокола Биткоин, проводимых в данный момент или в последующие несколько лет.
Есть и другие идеи того, как можно масштабировать Биткоин, но нет никого, кто бы предложил единственно верное решение всех проблем, поэтом я не удивлюсь или, наоборот, разочаруюсь, если развитие пойдет совсем в другом направлении.
Первоначальная загрузка
Все, кто запускает Bitcoin Core первый раз раздражается от абсурдно долгого ожидания скачивания и индексации всей истории транзакций Биткоин. Загрузка уже занимает двадцать с чем-то гигабайт и это число все время растет.
Джефф Гарзик раздает BitTorrent файл, содержащий Blockchain в его текущем состоянии, чем можно ускорить начальную загрузку данных. Так как блоки данных друг друга подтверждают, вы не должны беспокоиться о безопасности загрузки; в худшем случае вы потратите время и трафик на загрузку поврежденного файла. Тем не менее, повторная индексация всех 20-с-чем-то гигабайт данных все еще может занять много часов на некоторых машинах.
Питер Вилль проделал большую работу над подходом “сначала заголовки”, когда скачивается только цепочка заголовков, каждый из которых длиной 80 байт, что в сумме дает всего лишь 25 мегабайт данных. Заголовков вполне достаточно для проверки цепочки, а наполнение самих блоков можно позднее запросить у остальных пиров в производном порядке подобно тому, как это делает BitTorrent.
Питер также работает над “libsecp256k1” — высоко оптимизированной библиотекой для работы с криптографией эллиптических кривых, используемых в протоколе Биткоин. Библиотека находится в стадии тестирования и будет использована как только мы будем убеждены, что она не содержит ошибок и полностью совместима с существующей основе кода OpenSSL.
rdponticelli предложил pull request для Bitcoin Core, обеспечивающий его работу на основе “обрезанной” (prunned) базы данных блоков. После того, как вы скачали и проиндексировали полную цепочку блоков, единственная причина хранить все данные о старых транзакциях — это для того чтобы помогать новым пирам при первоначальной загрузке Blockchain.
Вы можете удивиться, что старые блоки не нужны для проверки новых транзакций. Нескольо релизов назад Питер Вилль переделал архитектуру Bitcoin Core так, чтобы все данные, необходимые для проверки транзакций остались в базе данных “UTXO” (выходы неизрасходованных транзакций). Количество исторических данных, которое обязательно необходимо, зависит от степени правдоподобности (вероятности) глубины реорганизации Blockchain. Самая большая реорганизация когда-либо произошедшая в основной сети потребовала перестройки 24 блоков во время печально известного разделения цепочки 11 марта 2013.
Следующим шагом будет сделать использование “обрезанной” базы по умолчанию, но до этого необходимо модифицировать протокол так, что бы пиры могли сообщать друг другу информацию о доступности полных блоков друг у друга. Пиры, ненадолго отключенные от сети смогут выяснить каких блоков у них не хватает и у кого их можно запросить.
После этого, первоначальная загрузка Blockchain может быть дополнительно оптимизирована так, что пиры будут спрашивать у других непосредственно данные из UTXO, а не реконструировать их из полной истории транзакций. Тогда появится риск, что пиры смогут лгать о том, какие транзакции были потрачены или неизрасходованны, чтобы попытаться заставить вас принять недействительные транзакции или создать недействительные блоки, если вы майнер. Лучшим решением для этой проблемы будет встраивание “подтверждения UTXO” (хэша всех данных в наборе UTXO) в блоки, и добавление нового правила консенсуса, что каждое подобное подтверждение станет необходимым для того, чтобы блок был признан валидным.
Но консенсус требует времени; предложение Марка Фреденбаза о том, как для как встроить это подтверждение в блокпока не достигло консенсуса, и не происходит никакого обсуждения о том, как именно набор UTXO должен быть представлен и захэширован.
Увеличение объема транзакций
Я ожидаю, что проблема первоначальной загрузки блоков будет более-менее решена в следующем или максимум через три релиза Bitcoin Core. Следующей проблемой масштабирования, которую необходимо решить является хардкод предельного размера блока в 1 мегабайт, который означает, что сеть может поддержать только около 7-операций в секунду.
Любое изменение в коде ядра консенсуса означает риск, так зачем рисковать? Почему бы просто не оставить Bitcoin Core таким, какой он есть, и жить с семью транзакциями в секунду? “Если ничего не сломалось, не надо исправлять.”
В 2010 году, сразу после того, как Биткоин был впервые упомянут на сайте Slashdot и начался рост цены, Сатоши выкатил несколько хотфиксов. устраняющих несколько различных атак на отказ в обслуживании. Одно из этих исправлений уменьшало максимальный размер блока из бесконечного в один мегабайт (практический предел до изменения составлял 32 мегабайта — максимальный размер сообщения в протоколе). Подняв этот предел при неизменном росте количества транзакций мы получим более крупные блоки.
“Аргумент от Авторитета” является логической ошибкой, так “Потому что Сатоши Так Решил” не является уважительной причиной. Однако, оставаться верным изначальному видению Биткоин очень важно. Это видение является тем, что вдохновляет людей вкладывать свои время, энергию и средства в эту новую, рискованную технологию.
Я думаю, что максимальная длина блока должна быть увеличена по той же причине, по которой предел в 21000000 монет никогда не должен быть повышен: потому что людям сказали, что система будет масштабироваться до обработки большого количества транзакций, так же, как им сказали, что всгда будет только 21000000 биткоинов.
Пока нет никакого кризиса; количество сделок в день примерно одинаково весь последний год (скачок во время ценового пузыря в начале года является исключением). Возможно причиной этому рост количества транзакций “за пределами Blockchain” (“off-blockchain”), но я не думаю, что это так уж сильно заметно влияет, потому что объемы обменов USD на BTC показывают ту же картину объема транзакций за последний год. Общая картина для цены и объема транзакций состоит из периодов относительной стабильности, за которыми следуют пузыри интереса, временно увеличивающие оба показателя. Затем падение вниз на новый уровень, ниже пика, но выше, чем при предыдущем стабильном уровне.
Мое предположение, что мы уткнемся в предел размера блока в 1 мегабайт в течение следующего ценового пузыря, и это одна из причин, из-за которой я проводил время над реализацией плавающей комиссии в Bitcoin Core. Большинство пользователей предпочитают заплатить на несколько центов больше в виде комиссии, а не ждать несколько часов или дней (или никогда!) пока их транзакции будут подтверждены, потому что сеть работает на пределе жестко заданного размера блока.
Возможные способы увеличения размера блока
Мэтт Коралло уже сделал первый шаг к поддержке большего размера блоков — более быстрая ретрансляция для того, чтобы свести к минимуму риск того, что более крупный блок занимает больше времени для распространения по сети, чем меньший по размеру блок. Об этом я писал в своем блоге в августе.
Уже найден консенсус, что нужно что-то менять для того, чтобы получить больше семи транзакций в секунду. А вот что именно предпринять — здесь мнения расходятся. В данный момент мне больше всего симпатизирует следующее решение:
Выпустить хардфорк, в котором размер блока увеличивался со временем согласно некоторому правилу, похожему на то, которое уменьшает награду за блок с течением времени.
Выбрать начальный максимальный размер, так чтобы “среднестатистический любитель Биткоин” мог бы без проблем участвовать в качестве полного узла сети. Под “среднестатистическим любителем Биткоин” я имею в виду кого-то с современным, достаточно быстрым компьютером и Интернет-подключением, запустившего последнюю версию Bitcoin Core и готового посвятить половину мощности своего процессора и пропускной способности сети Биткоин.
И выбрать алгоритм увеличения такой, чтобы соответствовать скорости роста пропускной способности в течение последующего времени: 50% в год в течение за последние двадцать лет. Заметим, что это меньше, чем примерно 60% в год роста мощности процессоров; пропускная способность будет ограничивающим фактором для объемов транзакций в обозримом будущем.
Я считаю, что это “самое простое, что могло сработать”. Это просто для правильной реализации и очень близко к правилам, работающим в сети сегодня. Размера блока такой, что уменьшается барьер входа в систему для любого обычного человека с довольно хорошим компьютером и средним подключением к Интернет, может отменить наметившуюся централизацию сети.
Как только сеть позволит размер блока больше чем 1 мегабайт, потребуются дальнейшие оптимизации сети. Вот тут-то и понадобятся Обратимые Таблицы Поиска Блума или (возможно) другие алгоритмы синхронизации данных.
Будущее выглядит светлым
Таким образом, в будущем какой-нибудь Биткоин-энтузиаст или профессиональный сисадмин сможет скачать ПО, которое будет делать следующее:
- Отыщет и подключится к другим пирам так же, как оно делает это сейчас
- Запросит у пиров заголовки лучшей цепочки (десятки мегабайт; займет не более нескольких минут)
- Скачает достаточно полных блоков для того, чтобы стала возможной обработка и реорганизация Blockchain в случае такой надобности (несколько сотен мегабайт, на которые, возможно, потребуются около часа)
- Запросит у какого-нибудь пира базу UTXO, и сравнит его с подтверждением, взятым из blockchain
Теперь это “полный узел”, способный подтверждать транзакции. Если место на диске — это поблема, он может свободоно удалить старые блоки.
Что дальше?
Существует четко очерченный путь к расширению сети для обработки несколько тысяч транзакций в секунду (“масштаб Visa”). Достигнуть этой цели не просто, так как хороший проверенный код не пишется быстро и потому что достигнуть консенсуса трудно. К счастью технический прогресс шагает вперед, и закон Нильсена о пропускной способности Интернета, а также закон Мура дают эти возможности для расширения.
Путь видится не таким четким, если задуматься о том, как масштабироваться быстрее, чем на 50% (увеличение средней пропускной способности в год согласно закону Нильсена). Возможны некоторые сложные и достаточно безопасные схемы для избежания широковещания каждой транзакции каждым узлом.
Но 50% в год уже вполне достаточно. По моим грубым прикидкам, мои “выше среднего” домашние Интернет-подключение и компьютер могут легко справиться с 5000 транзакций в секунду уже сегодня.
Все это позволяет обрабатывать до 400 млн транзакций в день. Достаточно хорошо; каждый житель США мог бы создать одну Биткоин-транзакцию и мой домашний узел это бы выдержал.
Через 12 лет постоянного увеличения средней полосы пропускания расчеты дают нам 56 миллиардов транзакций в день — достаточно для того, чтобы каждый человек в мире мог бы осуществлять пять или шесть Биткоин-транзакций каждый день. Трудно себе представить, что этого не будет достаточно; согласно данным банка Boston Federal Reserve, средний американский потребитель делает чуть более двух платежей в день.
Так что даже если в течение последующих 20-ти лет все в мире перейдут полностью от наличных к Биткоин, широковещание каждой сделки каждому подтверждающему узлу не будет проблемой.
