Увеличение размера блока: подробный анализ Bitfury

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

Таким образом, существуют две взаимосвязанные проблемы, касающиеся размера блока:

• Каковы будут последствия увеличения предельного размера блока, если поток транзакций остается примерно на текущем уровне?
• Каковы будут последствия роста числа транзакций в экосистеме Bitcoin?

Мы изучим оба эти вопроса в следующих разделах.

1. Математика размера блока

В настоящее время жестко заданное ограничение на размера блока 1 МБ. Любой блок больше, чем 1 МБ считается не действительным всеми основными клиентами Bitcoin [3]. Этот предел соответствует максимуму примерно 4000 операций за блок (исходя из предположения, что средний размер транзакции составляет около 200-250 байт). Так как блоки добываются в среднем каждые 10 минут, это дает нам максимальную пропускную способность примерно 7 транзакций в секунду.

Математическое моделирование [5] предполагает, что увеличение нагрузки на сеть Bitcoin отрицательно влияет на время подтверждения транзакции. Влияние становится наиболее выраженным по мере того, как как пропускная способность приближается к максимуму. Например, при 2,8 операций в секунду (80% от максимума), медианное время до первого подтверждения транзакции составляет 18,5 минуты, половина транзакций подтверждается еще медленнее. Для сравнения, если пропускная способность составляет 1 TPS, медианное время до первого подтверждение составит 7 минут.

Увеличение размера блока могло бы облегчить проблему, так как пропускная способность обратно пропорциональна размеру блока, и следовательно задержка подтверждения транзакции уменьшается с рост ом размера блока (Таблица 1). Как видно из таблицы, увеличение размера блока до 2MB было бы достаточно, чтобы решить проблему с задержками подтверждений. Последующее увеличение не даст ощутимого прироста скорости подтверждений транзакций ввиду текущих ограничений сети. С другой стороны, трудно предсказать, как увеличение размера блока повлияет на пропускную способность сети Bitcoin. Следовательно, правильным подходом было бы изменять размер блока в зависимости от нагрузки на сеть. Отметим также, что есть ограничения, накладываемые на моделирование в целом, так как эмпирические данные показывают, что даже во время флуд-атаки в июле 2015 года, фактический средний срок подтверждения не поднимался выше 12 минут [6].

Существует еще один аспект проблемы пропускной способности: можно утверждать, что в настоящее время большинство транзакций с медленным подтверждением это так называемая пыль — транзакции с очень низкими значениями выводов, а так же с размером комиссионных ниже, чем средние значения комиссионных платежей [7]. Пыль обычно используется в DoS-атаках на Биткойн, грандиознейшая из которых имела место в июле 2105 [2]. Некоторые виды пылевых операций с ничтожно малыми суммами просто не проводятся и не включаются в блоки. Наложение дополнительных ограничений на транзакции выступает альтернативой увеличению размера блока. По сравнению с увеличением размера блока, путь ограничения транзакций имеет преимущество: это можно осуществить софт-форком (т.е. блоки добываемые обновленным программным обеспечением с бОльшим количеством ограничений будут приняты предыдущими версиями софта), в то время как увеличение размера блока предполагает жесткий форк (т.е. изменения в протокол Bitcoin без обратной совместимости). С другой стороны, это решение по ограничению на размер вывода транзакции может вызвать негативную реакцию среди пользователей и Биткойн-разработчиков, создающих приложения на базе блокчейна.

Есть мнение [8], что если держать размер блока относительно небольшим, то это поможет создать рыночный механизм для комиссионных за транзакции, где пользователи должны будут платить большие комиссии для того, чтобы их транзакции подтверждались быстрее. Больший размер комиссий так же может подстегнуть создание приложений на базе блокчейна, но не использующих его напрямую, таких как сайдчейны [9] и способы микроплатежей [10]. Эти решение потребует обновить некоторый биткойн-софт, например биткойн-кошелек, который не имеет встроенной возможности изменять комиссионные платежи. Однако же, высокие комиссии за транзакции могут снизить привлекательность использования Биткойна для микроплатежей, денежных переводов и международных платежей.

Увеличение размера блока может привести к дополнительной нагрузке на узлы сети Bitcoin.

Таблица 1: Время подтверждения транзакции в зависимости от размера блока и нагрузки на сеть

Наиболее дорогой операцией с точки зрения затрат компьютерных ресурсов во время проведения транзакции является проверка ECDSA сигнатур вводов транзакции (для того, чтобы защитить сеть от DoS атак, каждая транзакция проходит проверку, прежде чем передается на другие узлы). Современные процессоры способны проверить несколько тысяч транзакций в секунду [11]. Таким образом, текущая нагрузка в несколько tps не сильно обременяет сеть.

Большей проблемой является то, что в результате повышения потока транзакций, увеличивается потребление памяти (и оперативной и дискового пространства) а так же интернет-трафика, проходящего через полные узлы. В таблице 2 показаны характеристики полных узлов и наша оценка последствий увеличения размера блока. Мы используем средние значения размера блока, который сейчас составляет примерно 0,5 MB.

Текущие характеристики принятые в таблице 2:

• Transaction throughput (пропускная способность): это размер блока, деленный на ожидаемый интервал времени между блоками (600 секунд) и на текущий средний размер транзакции (чуть меньше 0,5 килобайт). Транзакционная пропускная способность также может быть рассчитана по результатам ежедневной статистики транзакций [1]. Оба метода дают приблизительно один и тот же результат 1,75 tps.
• Number of transactions in a block (количество транзакций в блоке): размер блока, деленный на средний размер транзакции. Альтернативно, оно равно количеству транзакций за 600 секунд

(Количество транзакций в блоке) = 1,75 * 600 = 1050.

Таблица 2: Потребление ресурсов полными нодами по мере увеличения размера блока

• Blockchain storage (место под блокчейн): средний размер блока, умноженный на ожидаемое количество блоков (144 блока в день, 144 * 365 = 52560 блоков в год).

(Место / день) = 0,5 * 144 = 72 MB

(Место / год) = 0,5 * 144 * 365 = 26280 MB

• Transaction processing time (время обработки транзакции): основано на предположении, что узел может обрабатывать 3000 транзакций в секунду [11]. Следует отметить, что каждая транзакция должна быть обработана, то есть узел должен проверить, что неизрасходованные выводы соответствуют вводам транзакций, а так же проверить каждую сигнатуру, включенную во вводы.
• Block verification time (время проверки блока): время процессинга транзакции умноженное на медианное значение числа транзакций в блоке за время блока 0,2. Последний фактор соответствует положению, что на момент поступления блока, большинство транзакций в блоке уже проверено. Узлу необходимо только посчитать хэши транзакций и найти их в кэше транзакций.

(Время обработки транзакций) = 0,2 * 1050 * 0,0003333 = 0,07 сек

• Average bandwith (средняя пропускная способность) узла 74 килобайта в секунду [13]. В настоящее время через узел проходит более 6 гигабайт (GB) сетевого трафика в день.
• RAM usage (использование оперативной памяти): является самой трудной для оценки переменной, поскольку зависит от многих факторов. Более того, использование оперативной памяти отличается для различных типов узлов. Одним из основных факторов влияющих на потребление ОЗУ является неизрасходованный набор выводов транзакции, который в настоящее время занимает более 4 GB [14]. Этот набор необязательно должен полностью находиться в оперативной памяти узла, хотя другие методы хранения могут привести к повышению времени проверки транзакций. Мы используем эмпирическое значение 2 GB, основываясь на рекомендациях [15], что меньше, чем то, что советуют другие измерения [16]. Очевидно, что для специализированных узлов, таких как майнинговые ноды, требования к оперативной памяти выше, так как эти узлы вынуждены хранить весь набор неизрасходованных выводов в оперативной памяти для того, чтобы быстро проверять входящие транзакции и блоки.

Мы рассчитываем ожидания изменения ключевых параметров узла для увеличенного размера блока, путем умножения базовых значений на коэффициенты масштабирования во втором столбце таблицы, где N обозначает множитель размера блока. Коэффициенты масштабирования установлены следующим образом:

• Мы предполагаем, что средний размер транзакции остается таким же, так что пропускная способность и количество транзакций в блоке будет изменяться линейно относительно изменения размера блока. Очевидно, что место под блокчейн точно так же линейно зависит от размера блока.
• Обработка транзакции — требует поиска в наборе нерастраченных выводов транзакции. В оптимальном варианте, среднее время поиска логарифмически зависит от размера набора. Последний должен масштабироваться линейно (как представлено на исторических данных [17]). Поскольку количество нерастраченных выводов сейчас значительно больше, чем 10 в седьмой степени, время проведения транзакции останется примерно таким же, по мере роста размера блока.

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

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

Пусть S обозначает текущий размер кэша транзакций и t обозначает среднее время поиска единичной транзакции. Если размер блока увеличится в N раз, время поиска для каждой транзакции увеличится до t log2(N S). Следовательно, время проверки блока увеличится на коэффициент

Сейчас S приблизительно равно 2000 [18], что подразумевает коэффициент масштабирования приблизительно равный N (1 + 0,091 log2 N).

• Сетевой трафик зависит от размера блока и от количества транзакций. Оба этих значения масштабирубтся линейно.
• Мы считаем наиболее вероятным, что узлы будут хранить тот же процент неизрасходованных выводов транзакций в памяти, сколько они хранят сейчас. Поскольку набор неизрасходованных выводов линейно растет с ростом размером блока, использование оперативной памяти должно так же расти линейно. Изменение других факторов, способствующих потреблению оперативной памяти (например, размер кэша транзакций) представляет собой линейный или сублинейный рост, так что очень мала вероятность того, что они перегрузят объемнеизрасходованных выводов транзакций в долгосрочной перспективе. В отличие от других факторов, использование оперативной памяти в основном определяется установками пользователя. Узел может работать сравнительно хорошо с меньшим объемом оперативной памяти, однако же результатом этого может стать задержки проведения транзакций.

Таблица содержит оценку того, сколько полных узлов не смогут работать без аппаратного апгрэйда после увеличения среднего размера блока. Эти оценки основаны на предположении, что многие пользователи держат полные узлы на аппаратных средствах потребительского класса, будь то домашний ПК или облако. Информация об аппаратных характеристиках узла основаны на опросе, проведенном Steam [19]. Мы предполагаем, что
геймеры и Bitcoin-энтузиасты имеют оборудование с примерно одинаковыми характеристиками. Исключением является оперативная память: мы предполагаем, что типичный компьютер, поддерживающий узел имеет не менее 3 ГБ оперативки, поскольку биткойн-нода сама по себе отъедает 2ГБ [15]. Для примера, если размер блока увеличится до 2 МБ, на ноде под биткойн-клиент должно быть выделено 8 ГБ оперативной памяти, в то время как на более чем половине компьютеров в опросе установлено меньше памяти.

Мы также включили оценку того, сколько существующих узлов будет исключено из сети в следующие 6 месяцев. В то время как немедленное падение числа узлов, в основном, относится к оперативной памяти и использование процессора, в долгосрочной перспективе есть другие ограничивающие факторы, такие как объем дискового пространства и интернет-трафика. Для примера, если усредненный размер блока будет 8 МБ, узел потребует 34 ГБ дискового пространства и через него будет проходить примерно 3 терабайта (ТБ) трафика каждый месяц.

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

Возможны негативные последствия для времени проверки блока представленного в таблице 2 в случае больших размеров блока. В настоящее время, доставка блока по всем узлам сети, как правило, занимает 10-15 секунд и зависит главным образом от пропускной способности интернет соединения пользователя. При значительном увеличении размера блока, некоторые владельцы узлов могут рассматривать покупку дополнительного оборудования как не стоящую затрат. Это может привести к увеличению времени доставки блока и увеличит количество блоков сирот.

Увеличивающиеся требования к железу так же может привести к большей централизации, поскольку в сети останется меньше полных узлов. Сейчас основная причина падения количества полных узлов заключается в переезде биткойнеров на «легкие» (SPV) клиенты. Для тех, кому обязательно нужны полные узлы, например майнерам или Биткойн-биржам, повышение требований к железу не так критично, как для средних пользователей. С другой стороны, требования к оборудованию для специализированных узлов в разы выше, чем для обычных узлов (например, типичный майнинг-узел в настоящее время требует больше, чем 8 ГБ ОЗУ), поэтому проблема увеличения размера блока относится не только к средним узлам.

1.1 За и против увеличения размера блока

В пользу увеличения размера блока:

• Больше транзакций в секунду, быстрее время подтверждения. Обратите внимание, что время подтверждения блока также зависит от среднего времени создания блока (в протоколе Биткойн установлено как 10 минут). Таким образом, среднее время подтверждения никогда не может упасть ниже несколько минут, до тех пор, пока параметры генерации блока так же не изменен в протоколе.
• Больше транзакций для систем, построенных поверх блокчейна Биткойна, таких как платформы цветных монет (например, Counterparty, OmniLayer).
• Увеличение размера блока позволит держать комиссии за проведение транзакций на низком уровне.

Против увеличения размера блока:

• Увеличение размера блока потребует хард форк, что означает, что решенные с момента хардфорка блоки не будут признаны системами с не обновленным клиентом. Это может привести к негативным последствиям для цены Биткойна и его репутации.
• Большие блоки могут медленнее распространяться в сети, что может привести к увеличению количества брошенных блоков (осиротевших, орфанов), а так же увеличит вероятность успешной двойной траты. Из-за плохой пропускной способности между Китаем и остальным миром, европейские и американские майнеры находятся в невыгодном положении по сравнению с китайскими майнерами, с тех пор, как последние сосредоточили большую часть майнинговых мощностей.
• Обработка больших блоков требует более мощное аппаратное обеспечение, что может привести к уменьшению количество полных узлов в сети Биткойн. Это может привести к централизации сети и изменению локальной и глобальной peer-to-peer топологии.
• Повышенные требования к оборудованию и растущий уровень брошенных (осиротевших) блоков может привести к нестабильной генерации блоков и неточной оценке сложности сети на следующий период.
• Блокчейн Биткойна изначально не был разработан для всех видов сделок. Некоторые транзакции лучше обрабатывать с помощью других технологий (таких как сайдчейны или микроплатежи).
• Повышение комиссии как результат не-повышения размера блока, может помочь выстроить рынок комиссий за транзакции. Это помогло бы экосистеме Биткойна и дало толчок к девелопменту оффчейн решений.
• Блокчейн Биткойна не должен использоваться как дешевое место постоянного хранения разнообразной информации, это становится жизненно важно с увеличением размера блока и низкими операционными издержками.

2. Предложения

2.1 Первое предложение Гэвина Андресена

Исторически, сложилось так, что первое предложение по увеличению размера блока было выдвинуто девелопером ядра Биткойна Гэвином Андресеном, как одномоментное повышение лимита до 20 МБ. Это предложение имеет серьезные недостатки:

• Хардфорк, вызванный увелиечнием, не вызовет проблем только в случае консенсуса среди всех основных членов экосистемы Биткойн. В противном случае, это приведет к форку блокчейна Биткойн с непредсказуемыми негативными последствиями для цены Биткойна и доверия пользователей к нему.
• Выбранный размер 20 МБ вряд ли обоснован с теоретической точки зрения, в то время как такие принципиальный решения должны сопровождаться тщательным моделированием, а также математическим и экономическим анализом.

2.2 BIP 101

22 июня 2015 года, Гэвин Андресен представил аналогичное предложение, описанное в БИП 101 [20]. Согласно предложения, предельный размер блока должен увеличиться до 8 МБ в 2016 году, а затем удваиваться каждые два года, пока не достигнет размера 8192 МБ в 2036 году. После этого, максимальный размер блока будет оставаться постоянным. Дата увеличения будет приниматься на основании решения, принятого квалифицированным большинством: через две недели после того как 750 из 1000 последовательных блоков в blockchain будут иметь определенный номер версии, но не раньше, чем 11 января 2016 года. Рациональным обоснованием предложения является то, что мощность процессора, объем памяти, пропускная способность сети растут в геометрической прогрессии в соответствии с законом Мура [21]. Этот рост, однако, в конечном итоге будет постепенно замедляться.

Это предложение было сформировано после того, как Андресен получил отрицательный отзыв на предложение по увеличению максимального размера блока до 20 МБ от китайских майнинг-пулов, и противопоставляет ему 8 МБ. Основные негативные пункты о BIP 101 такие же, как и по предложению до него. Хотя максимальный размер блока в БИП 101 растет с предсказуемой скоростью, все равно трудно оценить как эта предопределенная скорость будет соотноситься со скоростью росту сети Bitcoin в будущем.

2.3 Форк Bitcoin XT

Не добившись поддержки со стороны разработчиков ядра Bitcoin, Андресен решил внедрить BIP 101 и некоторые другие патчи, которые не были включены в Bitcoin Core в отдельном Биткойн-клиенте Bitcoin XT, разработанном им совместно с Майком Хирном (Mike Hearn). Отрицательные моменты в Bitcoin XT:

• Раскол между клиентским программным обеспечением установленным на полных узлах может вызвать негативное влияние на имидж Bitcoin и привести к снижению доверия к блокчейну Bitcoin.
• Транзакции в Bitcoin XT могут привести к форку блокчейна: есть опасение, что слишком малая разница между Bitcoin Core и Bitcoin XT может привести к тому, что Bitcoin XT будет принимать некоторые транзакции, признанные неправильными в сети Bitcoin Core.
• Надежность Bitcoin XT гораздо ниже, так в нем нет публичного аудита кода, и отсутствует формальный процесс верификации, который является ключевой частью развития Bitcoin Core.
• В отличие от Bitcoin Core, разработчики Bitcoin XT не планируете использовать механизм утверждения изменений на основе консенсуса (Майк Хирн заявил, что он будет «благожелательным диктатором» Bitcoin XT — прим. ред).
• Команда разработчиков Bitcoin XT значительно меньше, чем команда, работающая над Bitcoin Core. Это вызывает вопрос, насколько они будут способны объективно оценивать изменения, вносимые в Bitcoin XT.

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

2.4 BIP 100

Один из более умеренных подходов к увеличению размера блока был предложен разработчиком Bitcoin Core Джеффом Гарзиком (Jeff Garzik) в БИП 100 [22]. В соответствии с предложением, жесткий лимит на размер блока отодвигается. Вместо этого, представляется плавающий размер блока. Форк запланирован на 11 января 2016. Изменения плавающего лимита будут решаться путем голосования майнеров (аналогично BIP 34 [23]):

• Размер блока не должен быть более исторического предела в 32 МБ, установленного в p2p протоколе используемом в сети Bitcoin.
• Чтобы ввести плавающий лимит, 90% от 12 000 последовательных блоков (что соответствует примерно трем месяцам по времени) должны обозначать поддержку предложения.
• Для того чтобы изменить плавающий предел, майнеры должны включать предлагаемое ограничение на размер блока в сигнатуры подписей намайненых блоков. Голоса оцениваются путем отбрасывания верхних 20% и нижних 20%, и затем выбирается наиболее распространенный уровень (минимальный) оставшихся голосов.
• Увеличение или уменьшение предельного размера блока не может превышать 2-x крат в одном раунде голосования.

По сравнению с остальными вариантами, это предложение имеет следующие преимущества:

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

И хотя майнеры не представляют все Bitcoin-сообщество, в их интересах поддержание сети в добром здравии.

Недостатком BIP 100 является нечеткая формулировка используемая в описании метода подсчета голосов. Если мы предположим, что решение о плавающем лимите размера блока, принятое минимум голосов, оставшимся после отбрасывания верхних и нижних 20%, получится что партия с 21% майнинговых мощностей сможет эффективно задерживать все попытки увеличения лимита в течение неопределенного времени. Другой недостаток (общий и для остальных предложений) это остающийся верхний лимит в 32 МБ, который вызван ограничением на размер сообщения в протоколе peer-to-peer, используемом сетью Bitcoin. Для того, чтобы обойти этот лимит, в протокол должна быть внесена рекомендация разрешить разносить доставку блоков по нескольким сообщениям.

Мы рассматриваем проблему атаки 21% с точки зрения формальной математики, примененной к процессу голосования в BIP 100 (Приложение А). Наш подход направлен на прояснение неопределенности процесса голосования. Он может быть использован для алгоритмического определения наилучшего лимита размера блока, который будет принят, как подходящий для всех майнеров.

2.5 BIP 102

В качестве альтернативы BIP 100, Джеф Грзик предложил BIP 102 [24]. Это минималистическое решение, которое 11 ноября 2015 увеличивает размер блока до 2 МБ. Автор позиционирует BIP 102 как запасной вариант, если консенсус по другим вариантам не будет достигнут.

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

Предложение Вуйле

Питер Вуйле (Peter Wuille), другой девелопер Bitcoin Core, составил свое собственное предложение по увеличению размера блока [25]. Предложение Вуйле заключается в изменении лимита на максимальный размер блока в соответствие с экспоненциально растущей функцией, которая зависит от даты и времени блока, начиная с января 2017. Если предложение будет реализовано, максимальный размер блока будет расти примерно на 17,7% в год.

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

2.7 Другие решения масштабирования Биткойн

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

• Инвертируемые поисковые таблицы Блума (Invertible Bloom lookup tables (IBLT) — призваны распространять блоки намного быстрее путем минимизации количества рассылаемых данных [26]. Если это будет реализовано, то майнеры смогут значительно увеличить размер блока не беспокоясь о том, что может вырасти количество брошенных блоков.
• Офф-чейн решения (Off-chain solutions), такие как сайдчейны [9] и каналы для микроплатежей, такие как Lightning Network [10] могут быть использованы для уменьшения количества транзакций в Биткойн-сети. Эти решения могут быть использованы для быстрого масштабирования Биткойна, пока поддерживается сравнительно небольшой размер блока.
• Древовидный сайдчейн (Treechains) позволит организовать блокчейн в древовидной структуре, вместо линейной последовательности. Это поможет увеличить пропускную способность сети без необходимости в увеличении лимита размера блока.
• Greedy heaviest observed sub-tree (GHOST) протокол [28], протокол, который может быть использован для уменьшения среднего времени между блоками с 10 минут до нескольких секунд без какого-либо риска потратить большую часть майнинга сети на потерянные блоки.
• Централизованные oфф-чейн транзакции(Centralized off-chain ledgers) используемые Coinbase, ChangeTip и другими сервисами. Эти решения могут помочь уменьшить поток блокчейн-транзакций, хотя остаются вопросы относительно их надежности и защищенности.
• Проблема возросших требований к железу может быть решена с помощью супер-нод корпоративного класса, поддерживаемых майнерами и другими (богатыми ресурсами) участниками, заинтересованными в стабильности экосистемы Биткойн. При использовании специализированного программного обеспечения и железа, эти ноды будут способны проводить тысячи транзакций в секунду.

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

3. Выводы

Для того, чтобы экосистема Bitcoin продолжила развиваться, максимальный размер блока должен быть увеличен. Существует общее понимание среди разработчиков Bitcoin, что текущее ограничение в один мегабайт ограничивает масштабируемость Bitcoin и может остановить его дальнейшее принятие и более широкое применение. Это мнение поддерживается математическим моделированием, которое показывает увеличение задержек подтверждения транзакций по мере того, как размер блока приближается к пределу.

Повышение требований к оборудованию может привести к тому, что существенное количество полных узлов отключится от сети в случае, если прямо сейчас увеличить размер блока до 8 МБ. Это аргумент против предложений по повышению максимального размера блока одним большим скачком. Точно так же, предложения создать форк клиентского программного обеспечения может иметь негативные последствия для всей экосистемы Bitcoin. BIP 100 Джеффа Гарзика и предложение Питера Вуйле озвучивают оба этих аспекта.

Оптимальный способ разрешения спора о размере блока это решение на основе консенсуса. Механизм голосования представленный в BIP 100 это хороший способ достижения такого рода консенсуса. Прогнозы роста сети Биткойн сделанные в других предложениях не имеют достаточной предсказательной силы, и в этом случае цена ошибки может оказаться очень велика. Поскольку BIP 100 позволяет членам Биткойн-сообщества определять лимит размера блока, это наилучшее решение в данном отношении.

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

С математическим моделированием формализации процесса голосования в BIP 100 можно ознакомиться в первоисточнике в Приложении А.

Перевод сделан при содействии проекта #takemybitcoin.

Литература

[1] Number of transactions per day. Blockchain.info charts
URL: https://blockchain.info/charts/n-transactions
[2] July 2015 flood attack. In: Bitcoin Wiki
URL: https://en.bitcoin.it/wiki/July_2015_flood_attack
[3] Block size limit controversy. In: Bitcoin Wiki
URL: https://en.bitcoin.it/wiki/Block_size_limit_controversy
[4] David Hudson (2014). 7 transactions per second? Really?
URL: http://hashingit.com/analysis/33-7-transactions-per-second
[5] David Hudson (2014). Bitcoin traffic bulletin
URL: http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
[6] Median transaction confirmation time (with fee only). Blockchain.info charts
URL: https://blockchain.info/charts/avg-confirmation-time
[7] Transaction fees. In: Bitcoin Wiki
URL: https://en.bitcoin.it/wiki/Transaction_fees
[8] Bram Cohen (2015). Bitcoin’s ironic crisis
URL: https://medium.com/@bramcohen/bitcoin-s-ironic-crisis-32226a85e39f
[9] Adam Back, Matt Corallo, Luke Dashjr et al. (2014). Enabling blockchain innovations with pegged sidechains
URL: https://www.blockstream.com/sidechains.pdf
[10] Joseph Poon, Thaddeus Dryja (2015). The Bitcoin Lighting Network: scalable off-chain instant payments
URL: http://lightning.network/lightning-network-paper.pdf
[11] Scalability. In: Bitcoin Wiki
URL: https://en.bitcoin.it/wiki/Scalability
[12] Protocol documentation. In: Bitcoin Wiki
URL: https://en.bitcoin.it/wiki/Protocol_documentation
[13] Bandwidth usage. Statoshi.info (Retrieved on Aug 27, 2015)
URL: http://statoshi.info/dashboard/db/bandwidth-usage
[14] Gavin Andresen (2015). UTXO uh-oh…
URL: http://gavinandresen.ninja/utxo-uhoh
[15] Running a full node. Bitcoin.org
URL: https://bitcoin.org/en/full-node
[16] System metrics. Statoshi.info (Retrieved on Aug 27, 2015)
URL: http://statoshi.info/dashboard/db/system-metrics
[17] Unspent transaction output set. Statoshi.info (Retrieved on Aug 27, 2015)
URL: http://statoshi.info/dashboard/db/unspent-transaction-output-set
[18] Transactions. Statoshi.info (Retrieved on Aug 27, 2015)
URL: http://statoshi.info/dashboard/db/transactions
[19] Hardware & software survey. Steam
URL: http://store.steampowered.com/hwsurvey/?platform=pc
[20] Gavin Andresen (2015). Increase maximum block size (BIP 101)
URL: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
[21] Moore’s law. In: English Wikipedia
URL: https://en.wikipedia.org/wiki/Moore’s_law
[22] Jeff Garzik (2015). Making decentralized economic policy
URL: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
[23] Gavin Andresen (2012). Block v2, height in coinbase (BIP 34)
URL: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
[24] Jeff Garzik (2015). Increase block size limit to 2MB on Nov 11, 2015 (BIP 102)
URL: https://github.com/bitcoin/bitcoin/pull/6451
[25] Pieter Wuille (2015). Block size following technological growth
URL: https://gist.github.com/sipa/c65665fc360ca7a176a6
[26] Gavin Andresen (2014). O(1) block propagation
URL: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2
[27] Peter Todd (2014). Tree-chains preliminary summary
URL: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04388.html
[28] Yonatan Sompolinsky, Aviv Zohar (2013). Accelerating Bitcoin’s transaction processing: fast money grows on trees, not chains
URL: https://eprint.iacr.org/2013/881.pdf
[29] David Gilson (2013). Coinbase implements zero-fee microtransactions off the block chain. In: CoinDesk
URL: http://www.coindesk.com/coinbase-implements-zero-fee-microtransactions-off-the-block-chain/
[30] 21% attack possible against BIP100? Reddit
URL: https://www.reddit.com/r/Bitcoin/comments/3id7f9/21_attack_possible_against_bip100/

Источник: bitfeed.ru