Дорожная карта масштабирования Биткойна

Дорожная карта масштабирования

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

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

Первоначальная загрузка

Каждый, кто запускает 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 мегабайт, который означает, что сеть может поддержать только около семи операций в секунду.

Любое изменение в коде ядра консенсуса означает риск, так зачем рисковать? Почему бы просто не оставить Bitcoin Core таким, какой он есть, и жить с семью транзакциями в секунду? «Если ничего не сломалось, не надо исправлять».

В 2010 году, сразу после того как Биткойн был впервые упомянут на сайте Slashdot и начался рост цены, Сатоши выкатил несколько хотфиксов, устраняющих несколько различных атак на отказ в обслуживании. Одно из этих исправлений уменьшало максимальный размер блока из бесконечного в один мегабайт (практический предел до изменения составлял 32 мегабайта — максимальный размер сообщения в протоколе). Подняв этот предел при неизменном росте количества транзакций, мы получим более крупные блоки.

«Аргумент от Авторитета» является логической ошибкой, так «Потому что Сатоши Так Решил» не является уважительной причиной. Однако оставаться верным изначальному видению Биткойн очень важно. Это видение является тем, что вдохновляет людей вкладывать свои время, энергию и средства в эту новую, рискованную технологию.

Я думаю, что максимальная длина блока должна быть увеличена по той же причине, по которой предел в 21000000 монет никогда не должен быть повышен: потому что людям сказали, что система будет масштабироваться до обработки большого количества транзакций, так же, как им сказали, что всегда будет только 21 млн. биткойнов.

Пока нет никакого кризиса; количество сделок в день примерно одинаково весь последний год (скачок во время ценового пузыря в начале года является исключением). Возможно, причиной этому рост количества транзакций «за пределами Blockchain» («off-blockchain»), но я не думаю, что это так уж сильно заметно влияет, потому что объемы обменов USD на BTC показывают ту же картину объема транзакций за последний год. Общая картина для цены и объема транзакций состоит из периодов относительной стабильности, за которыми следуют пузыри интереса, временно увеличивающие оба показателя. Затем падение вниз на новый уровень, ниже пика, но выше, чем при предыдущем стабильном уровне.

Мое предположение, что мы уткнемся в предел размера блока в 1 мегабайт в течение следующего ценового пузыря, и это одна из причин, из-за которой я проводил время над реализацией плавающей комиссии в Bitcoin Core. Большинство пользователей предпочитают заплатить на несколько центов больше в виде комиссии, а не ждать несколько часов или дней (или никогда!), пока их транзакции будут подтверждены, потому что сеть работает на пределе жестко заданного размера блока.

Возможные способы увеличения размера блока

Мэтт Коралло уже сделал первый шаг к поддержке большего размера блоков — более быстрая ретрансляция для того, чтобы свести к минимуму риск того, что более крупный блок занимает больше времени для распространения по сети, чем меньший по размеру блок. Об этом я писал в своем блоге в августе.

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

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

Выбрать начальный максимальный размер, так чтобы «среднестатистический любитель Биткойн» мог бы без проблем участвовать в качестве полного узла сети. Под «среднестатистическим любителем Биткойн» я имею в виду кого-то с современным, достаточно быстрым компьютером и Интернет-подключением, запустившего последнюю версию Bitcoin Core и готового посвятить половину мощности своего процессора и пропускной способности сети Биткойн.

И выбрать алгоритм увеличения, такой, чтобы соответствовать скорости роста пропускной способности в течение последующего времени: 50% в год за последние двадцать лет. Заметим, что это меньше, чем примерно 60% в год роста мощности процессоров; пропускная способность будет ограничивающим фактором для объемов транзакций в обозримом будущем.

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

Как только сеть позволит размер блока больше, чем 1 мегабайт, потребуются дальнейшие оптимизации сети. Вот тут-то и понадобятся Обратимые Таблицы Поиска Блума или (возможно) другие алгоритмы синхронизации данных.

Будущее выглядит светлым

Таким образом, в будущем какой-нибудь Биткойн-энтузиаст или профессиональный сисадмин сможет скачать ПО, которое будет делать следующее:

1. Отыщет и подключится к другим пирам так же, как оно делает это сейчас
2. Запросит у пиров заголовки лучшей цепочки (десятки мегабайт; займет не более нескольких минут)
3. Скачает достаточно полных блоков для того, чтобы стала возможной обработка и реорганизация Blockchain в случае такой надобности (несколько сотен мегабайт, на которые, возможно, потребуются около часа)
4. Запросит у какого-нибудь пира базу UTXO, и сравнит его с подтверждением, взятым из blockchain

Теперь это «полный узел», способный подтверждать транзакции. Если место на диске — это проблема, он может свободно удалить старые блоки.

Что дальше?

Существует четко очерченный путь к расширению сети для обработки нескольких тысяч транзакций в секунду («масштаб Visa»). Достигнуть этой цели не просто, так как хороший проверенный код не пишется быстро и потому что достигнуть консенсуса трудно. К счастью, технический прогресс шагает вперед, и закон Нильсена о пропускной способности Интернета, а также закон Мура дают эти возможности для расширения.

Путь видится не таким четким, если задуматься о том, как масштабироваться быстрее, чем на 50% (увеличение средней пропускной способности в год, согласно закону Нильсена). Возможны некоторые сложные и достаточно безопасные схемы для избежания широковещания каждой транзакции каждым узлом.

Но 50% в год уже вполне достаточно. По моим грубым прикидкам, мои «выше среднего» домашние Интернет-подключение и компьютер могут легко справиться с 5000 транзакций в секунду уже сегодня.

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

Через 12 лет постоянного увеличения средней полосы пропускания расчеты дают нам 56 миллиардов транзакций в день — достаточно для того, чтобы каждый человек в мире мог бы осуществлять пять или шесть Биткойн-транзакций каждый день. Трудно себе представить, что этого не будет достаточно; согласно данным банка Boston Federal Reserve, средний американский потребитель делает чуть более двух платежей в день.

Так что, даже если в течение последующих 20-ти лет все в мире перейдут полностью от наличных к Биткойну, широковещание каждой сделки каждому подтверждающему узлу не будет проблемой.

Источник: Bitcoin Foundation, Coinside