Увeличeниe рaзмeрa блoкa: пoдрoбный aнaлиз Bitfury

[nor9845]

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

2015/09/05

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

Блоки в блокчейне Биткойн в настоящее время имеют жестко ограниченный размер 1 МБ (точнее, 1 миллион байт). С начала 2015 года были различные предложения по увеличению этого предела или полного отказа от него. Широко цитируемой причиной таких предложений стало увеличение пропускной способности сети Bitcoin. В настоящее время Bitcoin обрабатывает до 150000 операций в день, или менее 2 транзакций в секунду (TPS) [1]. В течение самой большой флуд-атаки на сеть имевшей место в июле 2015 [2], пиковая пропускная способность была примерно 214,000 транзакций в день, или 2,5 tps. Максимально возможная пропускная способность сети оценивается в 7 tps. Эта величина является ничтожной на фоне многих тысяч tps пиковой пропускной способности Visa и других подобных систем обработки платежей.

Если 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-атаках на Биткойн, грандиознейшая из которых имела место в июле 2015 [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]. Очевидно, что для специализированных узлов, таких как майнинговые ноды, требования к оперативной памяти выше, так как эти узлы вынуждены хранить весь набор неизрасходованных выводов в оперативной памяти для того, чтобы моментально проверять на входящие транзакции и блоков.

[nor9845]

Мы рассчитываем ожидания изменения ключевых параметров узла для увеличенного размера блока, путем умножения базовых значений на коэффициенты масштабирования во втором столбце таблицы, где 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 МБ вряд ли обоснован с теоретической точки зрения, в то время как такие принципиальный решения должны сопровождаться тщательным моделированием, а также математическим и экономическим анализом.

[nor9845]

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 можно ознакомиться в первоисточнике в Приложении А.


http://bitnovosti.com/2015/09/05/bitfury-group-block-size-inxrease/

[GGUL]

Надо четко различать два явления:
1. Увеличение максимального размера блока. (То что мы обсуждаем, и на что можем влиять)
2. Увеличение объема поступления транзакций. (На это явление мы не можем влиять, не можем никаким решением увеличить этот показатель.  Это полностью зависит от пользователей биткоина. ) Оценить это явление можно таким показателем, как средний размер блока при таком-то объеме поступивших транзакций.

Надо четко понимать, что увеличение максимального размера блока никак не влияет на средний размер блока.


Если сейчас средний размер блока 0.6мб, и мы увеличим максимальный размер до 8мб, то средний размер блока как был, так и останется 0.6мб. И будет потихоньку расти по мере развития биткоина.

В статье, по неизвестным причинам, идет постоянная путаница между этими понятиями. Чаще всего употребляется просто термин "размер блока". Без уточнений.

Например:
В разделе "Против увеличения размера блока:" (Речь идет о максимальном размере блока)

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

Количество орфанов растет линейно при увеличении СРЕДНЕГО размера блока.
Увеличение максимального размера блока не влияет на количество орфанов.

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

Невыгодность майнеров при нынешнем СРЕДНЕМ размере блока десятые доли процента. Более-менее существенный выигрыш (8%) возможен при достижении СРЕДНЕГО размера блока 16мб.
Опять же, увеличение максимального размера блока никак не влияет на это.
(Если и что-то влияет на это явление, то это плохая пропускная способность. И бороться надо именно с этим. )

Из других разделов.

Сетевой трафик зависит от размера блока и от количества транзакций. Оба этих значения масштабируются линейно.

Сетевой трафик зависит только от количества транзакций. То есть от СРЕДНЕГО размера блока.От максимального размера блока сетевой трафик не зависит.

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

Набор неизрасходованных выводов линейно растет с ростом СРЕДНЕГО размера блока. (=,,=)

И т.д.

p/s/
Есть отдельное явление - спам-атака. Но это явление надо изучать отдельно. ИМХО
Вводные данные должны быть другие, например:
Максимальный размер блока 1мб, у нас идет спам-атака.Какая вероятность и какие последствия?
Максимальный размер блока 8мб, у нас идет спам-атака.Какая вероятность и какие  последствия?

И после сравнения решать , стоит увеличивать максимальный размер с точки зрения борьбы со спамом или нет.

[RoadTrain]

GGUL, вы эту путаницу на пустом месте нашли. Из статьи очевидно, что речь идёт о гипотетически полных блоках. Даже если в каких-то местах действительно перепутано, сути статьи это не меняет.

Количество орфанов растет линейно при увеличении СРЕДНЕГО размера блока.
Увеличение максимального размера блока не влияет на количество орфанов.

Невыгодность майнеров при нынешнем СРЕДНЕМ размере блока десятые доли процента. Более-менее существенный выигрыш (8%) возможен при достижении СРЕДНЕГО размера блока 16мб.
Опять же, увеличение максимального размера блока никак не влияет на это.

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

[anref]

GGUL, вы эту путаницу на пустом месте нашли. Из статьи очевидно, что речь идёт о гипотетически полных блоках. Даже если в каких-то местах действительно перепутано, сути статьи это не меняет.

Количество орфанов растет линейно при увеличении СРЕДНЕГО размера блока.
Увеличение максимального размера блока не влияет на количество орфанов.

Невыгодность майнеров при нынешнем СРЕДНЕМ размере блока десятые доли процента. Более-менее существенный выигрыш (8%) возможен при достижении СРЕДНЕГО размера блока 16мб.
Опять же, увеличение максимального размера блока никак не влияет на это.

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

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

[GGUL]

GGUL, вы эту путаницу на пустом месте нашли. Из статьи очевидно, что речь идёт о гипотетически полных блоках. Даже если в каких-то местах действительно перепутано, сути статьи это не меняет.

Количество орфанов растет линейно при увеличении СРЕДНЕГО размера блока.
Увеличение максимального размера блока не влияет на количество орфанов.

Невыгодность майнеров при нынешнем СРЕДНЕМ размере блока десятые доли процента. Более-менее существенный выигрыш (8%) возможен при достижении СРЕДНЕГО размера блока 16мб.
Опять же, увеличение максимального размера блока никак не влияет на это.

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

Тогда статью надо было называть
"Увеличение среднего размера блока: подробный анализ Bitfury"  
Которая рассматривала бы гипотетические события, которые будут происходить года так через 3-4.
И в этом случае статья никакого отношения к увеличению максимального размера  блока в нынешнее время не имела бы.
Разве что в таком ключе:
Мы не увеличим максимальный размер. Обрубим на корню развитие биткоин-системы. И не получим гипотетических проблем через 3-4 года.
Мне кажется, это решение похоже на лечение головной боли гильотиной.Причем БУДУЩЕЙ головной боли, которой на самом деле может и не быть.

Ко второму пункту у меня один вопрос. Как майнер будет создавать  блоки размером 8мб, если транзакций в мемпуле меньше чем на 1мб.?

[RoadTrain]

Ко второму пункту у меня один вопрос. Как майнер будет создавать  блоки размером 8мб, если транзакций в мемпуле меньше чем на 1мб.?

Майнер может включать в блок транзакции самому себе. При желании это можно замаскировать под спам-атаку.

[GGUL]

Ко второму пункту у меня один вопрос. Как майнер будет создавать  блоки размером 8мб, если транзакций в мемпуле меньше чем на 1мб.?

Майнер может включать в блок транзакции самому себе. При желании это можно замаскировать под спам-атаку.

Сейчас 11 известных крупных майнеров имеют где-то 96% всего рынка. И Вы допускаете, что кто-то из  будет флудить, к 1 мегабайту реальных транзакций генерировать своих транзакций на 7 мегабайт. И никто про это не узнает.
Замаскировать скорее всего не получится, этих 7 мегабайт в мемпуле не должно быть.
Все видят, что в мемпуле транзакций на 1мб. А раз за разом от майнера  появляются блоки размером в 8мб.

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

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

[RoadTrain]

Сейчас 11 известных крупных майнеров имеют где-то 96% всего рынка. И Вы допускаете, что кто-то из  будет флудить, к 1 мегабайту реальных транзакций генерировать своих транзакций на 7 мегабайт. И никто про это не узнает.

Это не я допускаю, а протокол. По поводу возможности скрыть - да, технически трудоёмко. Но вы задали вопрос, я ответил - технически возможно делать блоки по 8МБ из ниоткуда.

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

[33reg]

Сейчас 11 известных крупных майнеров имеют где-то 96% всего рынка. И Вы допускаете, что кто-то из  будет флудить, к 1 мегабайту реальных транзакций генерировать своих транзакций на 7 мегабайт. И никто про это не узнает.

Это не я допускаю, а протокол. По поводу возможности скрыть - да, технически трудоёмко. Но вы задали вопрос, я ответил - технически возможно делать блоки по 8МБ из ниоткуда.

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

Уже давно майнинг не выгоден, если нет "волшебной" розетки.

[RoadTrain]

Сейчас 11 известных крупных майнеров имеют где-то 96% всего рынка. И Вы допускаете, что кто-то из  будет флудить, к 1 мегабайту реальных транзакций генерировать своих транзакций на 7 мегабайт. И никто про это не узнает.

Это не я допускаю, а протокол. По поводу возможности скрыть - да, технически трудоёмко. Но вы задали вопрос, я ответил - технически возможно делать блоки по 8МБ из ниоткуда.

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

Уже давно майнинг не выгоден, если нет "волшебной" розетки.

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

[33reg]

Сейчас 11 известных крупных майнеров имеют где-то 96% всего рынка. И Вы допускаете, что кто-то из  будет флудить, к 1 мегабайту реальных транзакций генерировать своих транзакций на 7 мегабайт. И никто про это не узнает.

Это не я допускаю, а протокол. По поводу возможности скрыть - да, технически трудоёмко. Но вы задали вопрос, я ответил - технически возможно делать блоки по 8МБ из ниоткуда.

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

Уже давно майнинг не выгоден, если нет "волшебной" розетки.

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

Смотря по чем 1КВт, но это уже и так низко рентабельно.

[33reg]

Хотя, если асики нормальные...То да.
Я почему-то подумал о более старом и добром (точнее о более теплом  ):

А не о

[GGUL]

Сейчас 11 известных крупных майнеров имеют где-то 96% всего рынка. И Вы допускаете, что кто-то из  будет флудить, к 1 мегабайту реальных транзакций генерировать своих транзакций на 7 мегабайт. И никто про это не узнает.

Это не я допускаю, а протокол. По поводу возможности скрыть - да, технически трудоёмко. Но вы задали вопрос, я ответил - технически возможно делать блоки по 8МБ из ниоткуда.

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

Ну технически, по протоколу, можно создавать блоки без транзакций. Всем майнерам. Мы почему-то не рассматриваем такой вариант. Потому что вероятность близка к 0.
Почему мы должны всерьез рассматривать вариант, когда майнеры будут флудить?

Эти выводы обосновываются теорией игр, а в частности игр с нулевой суммой дохода.
Сколько BTC майнер выиграет, столько другой майнер проиграет.
Если рассматривать в биткоинах, то да.
Но вообще-то майнеров скорее интересуют доход в долларах. И любое действие майнеров против системы будет крайне негативно отражаться на стоимости биткоина. И майнер может и выиграет немножко в BTC, но в долларах может потерять в разы.
Поэтому теорию игр применять к реальности все-таки надо с учетом всех особенностей.

p/s/
В статье не упоминается ни спам-атаки, ни искусственное создание крупных блоков.
Значит мы должны предполагать, что имеем дело с нормальным ходом событий.
А при нормальном ходе событий увеличение максимального размера блока никак не влияет на рост среднего размера блока.
При этом практически весь анализ в статье построен на увеличении среднего размера блока до 8МБ.
И в конце делаются выводы относительно увеличения максимального размера блока.
Что-то тут не сходится.

[RoadTrain]

Ну технически, по протоколу, можно создавать блоки без транзакций. Всем майнерам. Мы почему-то не рассматриваем такой вариант. Потому что вероятность близка к 0.
Почему мы должны всерьез рассматривать вариант, когда майнеры будут флудить?

Эти выводы обосновываются теорией игр, а в частности игр с нулевой суммой дохода.
Сколько BTC майнер выиграет, столько другой майнер проиграет.
Если рассматривать в биткоинах, то да.
Но вообще-то майнеров скорее интересуют доход в долларах. И любое действие майнеров против системы будет крайне негативно отражаться на стоимости биткоина. И майнер может и выиграет немножко в BTC, но в долларах может потерять в разы.
Поэтому теорию игр применять к реальности все-таки надо с учетом всех особенностей.

Ну я не отрицаю, что данный вид атаки имеет весьма неясные перспективы, тут в основном теоретизация.

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

Если смотреть строго, то влияние вполне возможно. Например, психологическое: "лимит подняли, значит мы сможем перенести на блокчейн ещё больше наших дерьмотранзакций!" и т.п. Но это опять же теоретизация, так что можно всерьёз не воспринимать.

[arlumba]

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

То есть первым шагом, мне кажется, должна быть разработка алгоритма оценки транзаций - желательные(комиссия, размер транзакции/объем средств) <-> нежелательные (спам)
А уже вторым шагом - увеличение размера блока.

[33reg]

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

То есть первым шагом, мне кажется, должна быть разработка алгоритма оценки транзаций - желательные(комиссия, размер транзакции/объем средств) <-> нежелательные (спам)
А уже вторым шагом - увеличение размера блока.

Так это теперь спорный вопрос - текущая сеть битка только блоки до 1Мб может обслуживать, т.е. остальные транзы будут ждать.
В ядре Биткоин ИксТ - блок более 8 МБ сможет включать.
Блокчейн может лопнуть, и так уже на грани.
Я против XT- ядра от сатоши и так хватает, надо и нужно уменьшать, а не увеличивать.
ХТ только всё испортит, как я считаю.

[FAN]

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