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

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

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

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

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

table1

Наиболее дорогой операцией с точки зрения затрат компьютерных ресурсов во время проведения транзакции является  проверка 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: Потребление ресурсов полными нодами по мере увеличения размера блока

table2

  • 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). Следовательно, время проверки блока увеличится на коэффициент

formula1

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

Источник: Bitfury.com

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

Литература

[1] Number of transactions per day. Blockchain.info charts
[2] July 2015 flood attack. In: Bitcoin Wiki
[3] Block size limit controversy. In: Bitcoin Wiki
[4] David Hudson (2014). 7 transactions per second? Really?
[5] David Hudson (2014). Bitcoin traffic bulletin
[6] Median transaction confirmation time (with fee only). Blockchain.info charts
[7] Transaction fees. In: Bitcoin Wiki
[8] Bram Cohen (2015). Bitcoin’s ironic crisis
[9] Adam Back, Matt Corallo, Luke Dashjr et al. (2014). Enabling blockchain innovations with pegged sidechains
[10] Joseph Poon, Thaddeus Dryja (2015). The Bitcoin Lighting Network: scalable off-chain instant payments
[11] Scalability. In: Bitcoin Wiki
[12] Protocol documentation. In: Bitcoin Wiki
[13] Bandwidth usage. Statoshi.info (Retrieved on Aug 27, 2015)
[14] Gavin Andresen (2015). UTXO uh-oh…
[15] Running a full node. Bitcoin.org
[16] System metrics. Statoshi.info (Retrieved on Aug 27, 2015)
[17] Unspent transaction output set. Statoshi.info (Retrieved on Aug 27, 2015)
[18] Transactions. Statoshi.info (Retrieved on Aug 27, 2015)
[19] Hardware & software survey. Steam
[20] Gavin Andresen (2015). Increase maximum block size (BIP 101)
[21] Moore’s law. In: English Wikipedia
[22] Jeff Garzik (2015). Making decentralized economic policy
[23] Gavin Andresen (2012). Block v2, height in coinbase (BIP 34)
[24] Jeff Garzik (2015). Increase block size limit to 2MB on Nov 11, 2015 (BIP 102)
[25] Pieter Wuille (2015). Block size following technological growth
[26] Gavin Andresen (2014). O(1) block propagation
[27] Peter Todd (2014). Tree-chains preliminary summary
[28] Yonatan Sompolinsky, Aviv Zohar (2013). Accelerating Bitcoin’s transaction processing: fast money grows on trees, not chains
[29] David Gilson (2013). Coinbase implements zero-fee microtransactions off the block chain. In: CoinDesk
[30] 21% attack possible against BIP100? Reddit


Categories: Безопасность, Майнинг, Стандарты, Технологии

Tags: , , , , , , ,

Leave a Reply

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

Notify of
avatar
trackback
Почему не Segwit2x? | Заработок онлайн доступный каждому

[…] размера блока в это время было невозможно. Сообщество обсуждало вопрос о размере блока ещё и до того, как Сатоши в 2010 […]

trackback

[…] размера блока в это время было невозможно. Сообщество обсуждало вопрос о размере блока ещё и до того, как Сатоши в 2010 […]

trackback
CEO Bitfury: я верю в Bitcoin! – Bit•Новости

[…] Майнеры и обработчики транзакций, такие как BitFury, возможно самые большие сторонники развития экосистемы Биткойна. Любое противоположное мнение попросту не выдерживает никакой критики. Майнеры инвестируют огромные средства и прикладывают множество усилий для разработки и поддержания работы оборудования для майнинга. Как показала Конференция по масштабированию Биткойна, майнеры в целом выступают за аккуратное увеличение предельного размера блока сети. По их мнению, резкое наращивание предельного размера блока может подорвать основу всей Биткойн-сети. Подробнее это раскрыто в статье BitFury. […]

trackback
Bitfury: Нет – BIP 101. Да – консенсусу! | Bit•Новости

[…] описывается в нашей статье на эту тему, мы не поддерживаем переход на BIP 101. Как мы считаем, BIP […]

trackback
Только доказательство работы обеспечивает консенсус | Bit•Новости

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

Анонимно
Гость

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

trackback
Bitcoin XT против Core: раскол, который нас разобщает | Bit•Новости

[…] опущу некоторые детали правил форка XT, при желании вы без труда сможете их отыскать (в […]

Аноним2
Гость

место под блокчейн точно так же линейно зависит от размера блока.

Ну на самом деле в статье подмена понятий
Место и память RAM зависит от числа транзакций, а не от размера блока.
Число транзакций зависит от платы за килобайт транзакций.
То есть чтобы уменьшить число транзакций надо повысить комиссию.
Раз майнеры комиссию не увеличивают, то их все устраивает. Значит и максимальный размер блока будет увеличиваться.

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

Georg
Гость

А если смотреть в общем на статью, то страдает логика построения.
У автора она следующая:

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

Ошибка уже на 2-м этапе. Этот пункт не следует из первого пункта.
По крайней мере, в ближайшие годы. 🙂

Mad_Max
Гость

Неправильно читали(понимали) рассматривался на лимит, а сам фактический размер блока. В частности отправная точка (текущая ситуация) не 1 Мб (= текущий лимит) а чуть меньше 0.5 Мб (текущие фактические размеры блоков).
Т.е. в 2 с лишним раза вырастет в любом случае, даже если вообще не делать. Ну а дальше разбор и обсуждение позволять ли ему расти еще больше (свыше 1 Мб) и с какими темпами.

Georg
Гость
Ниже СРЕДНИЙ размер — это то же самое что средний фактический размер на текущий момент. Везде выводы делаются из установки, что средний размер сразу вырастает после увеличения максимального размера. «В разделе «Против увеличения размера блока:» (Речь идет о максимальном размере блока) Большие блоки могут медленнее распространяться в сети, что может привести к увеличению количества брошенных блоков (осиротевших, орфанов), а так же увеличит вероятность успешной двойной траты. » «Количество орфанов растет линейно при увеличении СРЕДНЕГО размера блока.» Увеличение максимального размера блока не влияет на количество орфанов. «Из-за плохой пропускной способности между Китаем и остальным миром, европейские и американские майнеры находятся в… Read more »
Georg
Гость
“Исключением является оперативная память: мы предполагаем, что типичный компьютер, поддерживающий узел имеет не менее 3 ГБ оперативки, поскольку биткойн-нода сама по себе отъедает 2ГБ [15]. Для примера, если размер блока увеличится до 2 МБ, на ноде под биткойн-клиент должно быть выделено 8 ГБ оперативной памяти, в то время как на более чем половине компьютеров в опросе установлено меньше памяти.” Здесь мне кажется, какая-то ошибочка. Во-первых, я не вижу, чтобы биткоин-нода брала 2ГБ оперативной памяти. Во-вторых. С чего это, если размер блока увеличится до 2 МЕГАбайт, на ноде должно быть 8 ГИГАбайт памяти. Зачем нужно 6 ГИГАбайт, чтобы обработать дополнительный 1МЕГАбайт… Read more »
Mad_Max
Гость

А вы ей разрешите входящие соединения обслуживать(а не урезанно 8 подключений). Да оставьте на несколько суток онлайн — легко больше 2 Гб сжирает официальный клиент, даже в «пассивном» режиме (т.е. только загрузка, проверка и ретрансляция блоков и транзакций).

Georg
Гость

Если обслуживать большое количество соединений, то вполне возможно 2ГБ и потребуется. Но если Вы увеличиваете максимальный размер блока на 1мб, то оперативной памяти у Вас не должна сжираться на 6000мб больше. Тут в чем-то подвох.

Анонимно
Гость

Этот бесплатный «инструмент» совсем не бесплатный, комса за расчет битком при покупке авиа билета может быть 6%, за расчет за отель от 2,5% и верхний предел узнаешь только по факту расчета. В Турции был лично там где якобы принимают биток — смотрели большими глазами. Все это бред о том что он будет платежной системой, бред сивой кобылы. Никогда он не будет и одной миллиардной от визы. Он нужен чтобы кормить майнеров и собирать деньги инвесторов и все.

Анонимно
Гость

Еще не вечер… И, никогда не гори никогда. Всего пяток лет назад не думали, что вообще такое возможно.

Mad_Max
Гость

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

А про % при оплате — это НЕ биткоина комиссии — а посредников. Кстати при оплате визой тоже 2-3% комиссии есть, только ее обычно продавец на себя берет (но заложив рузумеется в цену заранее)

Анонимно
Гость

Мы принимаем bitcoin на http://www.littlewonderplus.com даем реальную скидку 20%. Делаем закупки сырья для производства и типографию за bitcoin.
Покупателей мало, очень мало, но есть.

Asd_skala
Гость

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

elite
Гость

конкретно по математике есть возражения?

Если ваша децентрализованность уже не существует, то зачем вы боритесь с ветряными мельницами?

Вот в BIP101 надо 750 блоков в ряд, это требует согласия почти 99% майнеров, что же тогда плохого в BIP101, почему такая антипропаганда на bitnovosti?

arvicco
Администратор
Децентрализация не есть бинарная характеристика — или она есть, или она нет. Я не согласен с вашим категоричным заявлением, что «децентрализованность уже не существует». Она есть, пока существует достаточное количество независимых пулов, достаточное количество анонимных майнеров, и майнеры могут свободно выбирать между пулами. Однако, тенденция централизации определенно существует, и, скажем, BIP 101 из всех предложений способствует ей в максимальной степени. А уж про BIP 101 в имплементации Bitcoin XT я вообще молчу. Любое изменение, уменьшающее степень децентрализации, должно очень серьезно обсуждаться в плане того, что мы получаем взамен. Как признал сам Гэвин, увеличение размера блока — не более, чем перепинывание… Read more »
elite
Гость
Если децентрализация не бинарная характеристика, то какова она? Децентрализация — это возможность запустить ноду биткойн на обычном геймерском компе, который из года в год улучшает свои характеристики, используя обычный доступ в интернет, который тоже улучшает свои характеристики. Если сейчас неплохой геймерский комп будет иметь 8 ггбайт RAM, SSD 1 Терабайт и 50 мбит интернет, то BIP101 отлично в него уложится, то есть ухудшения децентрализации никакой не будет. Ваша позиция вообще не оперирует параметрами среднего пользовательского компа, и поэтому неконструктивна, не научна, не обсуждаема, это просто религия и святая вера. Даже если компьютеры будут улучшаться в 10 раз в год, вы… Read more »
arvicco
Администратор
Ну, а произвольное использование в качестве некоего эталона «неплохого геймерского компа» — это что, верх конструктивного, обсуждаемого и научного метода? Почему 8 GB? Почему SSD? Каким образом в это «уложатся» блоки размером 8192 МБ, которые являются конечной целью Гэвина Андерсена? Учитывая, что действие Закона Мура прекращается (о чем он сам говорит: http://www.economist.com/blogs/economist-explains/2015/04/economist-explains-17), какие у вас основания полагать, что характеристики оборудования и коммуникаций будут в ближайшие десятилетия бешено расти, чтобы успеть за графиком постоянного удвоения, заданным BIP 101? То, что по расчету Bitfury, даже в случае 8-MB блоков 95% нод прекратят работу в течении короткого времени, вас не пугает? С какого… Read more »
elite
Гость

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

arvicco
Администратор
Какие 750 последовательных блоков? Где вы это взяли? В оригинале BIP 101: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#Deployment «Activation is achieved when 750 of 1,000 consecutive blocks in the best chain…» Дословно: «Активация произойдет, когда 750 из 1000 последовательно идущих блоков лучшей цепочки…» Еще раз: берем 1000 последних блоков. Считаем, сколько из них декларируют поддержку BIP100. Если таковых более 750, активируется сплит цепи. Я не знаю, как можно тут насчитать требование поддержки 99% майнеров. Если считать «по-простому», делим 750 на 1000, получаем 75%. Но на самом деле, все гораздо круче. Ведь надо учитывать, что процесс недетерминистический (то есть, даже если поддерживающих майнеров гораздо меньше 75%,… Read more »
elite
Гость
Я взял самый обычный геймерский комп с ценой 1000 долларов. Вон например магазин, компы для геймеров. nix.ru/price/price_list.html?section=computers_nix_for_gamers Вот компьютер с ценой около 1000 долларов nix.ru/autocatalog/nix_computers/X5000-ITX-PRO-X529GPGi-Core-i5-4590-8-Gb-1-Tb-SSHD-2-Gb-GeForce-GTX960-OC-DVDRW-Win8.1_209315.html В этом компе 8 мбайт RAM и SSD 1 TB Сейчас, при максимальном размере блока 1MB, bitcoind у меня занимает в памяти меньше 1Gb (780mbyte), следует ожидать что при размере блока 8Мб будет занимать меньше 8Gb RAM. При утверждаемой линейной зависимости. Следует отметить, что добавочные 8гбайт RAM будет стоить +50 долларов или 5 процентов цены: nix.ru/autocatalog/memory_modules_Crucial/Crucial-CT102464BA160B-DDR-III-DIMM-8Gb-PC3-12800-CL11_149465.html Даже если использовать таблицу BitFury, которая видимо неправильна, ибо там утверждается, что сейчас нужно 4Gb RAM, а по факту… Read more »
arvicco
Администратор

Ваша математика в корне неверна, смотрите мой комментарий выше.

arvicco
Администратор
Еще раз, подумайте о том, что происходит. Давайте, простой пример. Вот, я бросаю 6-гранный кубик, и декларирую, что «выиграл», если выпало 6. Моя вероятность выигрыша 1/6, верно? А вот как бы ни так. Потому что, если выпадает любой результат кроме 6, Я ДЕЛАЮ ВИД, ЧТО ОН «НЕ СЧИТАЕТСЯ». И снова бросаю кубик. И так неограниченное число раз, пока он не «выиграет». Какова РЕАЛЬНАЯ вероятность моего выигрыша в таком «честном бросании кубика»? Да 100%. Но, попробуй придерись. Выпала 6-ка? Выпала. Значит, я выиграл, все по-честному, деньги на стол! Именно это происходит с подсчетом блоков в BIP 101. Начиная с января 2016… Read more »
elite
Гость

Да, bip101 можно прочитать по разному — 750 последовательных блоков или 1000 последовательных блоков. Надо посмотреть код. Скорее всего, вы правы и при 60-70 процентном уровне поддержки bip101 он включится. Но у майнеров есть две недели после этого.

Вы так и не ответили про растущую мощность компьютеров.

arvicco
Администратор
Ну вот, мы начинаем к чему-то приходить. Для начала, к согласию о том, что никаким «консенсусом» в BIP 101 и не пахнет, одноразового временного «большинства» в 60% хэшрейта вполне достаточно, чтобы запустить необратимый раскол сети. Перейдем к практическим аспектам. Как такого «временного большинства» достигнуть? Учитывая, что десяток пулов контролирует 90% хэшрейта, вам в реальности нужно лишь около 10-20% хэшрейта сети. Объясняю методику. Всех, кто с вами не согласен, вы блокируете многодневным DDoSом. В строю (совершенно случайно, правда) остаются лишь дружественные вам пул(ы), голосующие за BIP 101. Через неделю, они наклепают вам нужные 750 из 1000 блоков. Ну, через пару недель,… Read more »
elite
Гость

Хорошо, кто-то потратил 100 тыс долларов и BIP101 приняли.
Что дальше? Где децентрализация?

Где доказательства того, что число узлов радикально уменьшится с 6000 тыс?
Где доказательства того, что из миллионов геймеровских компьютеров, не будет даже 0.1 процента (одна тысячная), чтобы стать узлом bitcoin-core с BIP101?

arvicco
Администратор

Ну, подсчеты Bitfury по поводу того, как из-за больших блоков радикально сократится количество биткойн-узлов, вас не убеждают? Или вы опять считаете «как-то не так»?

arvicco
Администратор

То есть, вы считаете вполне нормальным, если кто-то, используя популистские методы и имея 10% хэшрейта и 100 тысяч долларов, при помощи BIP 101 может поставить Биткойн-сеть и кодовую базу под свой единоличный контроль? Вас такой сценарий не смущает совсем, ну вот даже нисколько?

Извините за настойчивость, я просто пытаюсь понять вашу позицию. Вы это вот все считаете нормальным, и озабочены только тем, сможете ли вы на своем геймерском компьютере по-прежнему крутить полную ноду «Нового Биткойна, слава Хирну!» Или я чего-то не понимаю в вашей позиции?

elite
Гость
Ну, подсчеты Bitfury по поводу того, как из-за больших блоков радикально сократится количество биткойн-узлов, вас не убеждают? Не убеждают. Опрос проводился по смещенной выборке. Это ловушка в статистике. Под биткойн ноду отдают тот компьютер, который держит эту ноду и не более того. Если потребуется более лучший компьютер — то дадут более хороший компьютер, чтобы работало. Рассуждения BitFury как бы вообще говорят, что 1мбайт (то, что сейчас) должно отрезать 40 процентов нод. Ну как бы не верю. Почему не отрезает? Еще раз — все потребление памяти из-за непотраченных выводов, которые можно и на диске хранить, если они мелкие. То есть простор… Read more »
arvicco
Администратор
Я вам даже больше скажу. «Коненсенсус в 60-70 процентов» — это никакой не консенсус. А Биткойн, развитие которого управляется единолично Майком Хирном — это никакой не Биткойн. И дело даже не в том, хороший Майк Хирн или плохой. Именно принцип консенсуса в развитии кодовой базы Биткойна не позволяет быстро внедрить в него различные «ррррреволюционные фишечки», часто имеющие непредвиденные последствия. Лишь изменения, решающие реальные и осязаемые проблемы, которые действительно представляют угрозу для сети, имеют шанс достигнуть консенсуса. И это, что бы там не болтали рррррреволюционэры, очень и очень хорошо. Стабильность поведения и уверенность в выполнении социального контракта — вот важнейшая характеристика… Read more »
elite
Гость
То есть, вы считаете вполне нормальным, если кто-то, используя популистские методы и имея 10% хэшрейта и 100 тысяч долларов, при помощи BIP 101 может поставить Биткойн-сеть и кодовую базу под свой единоличный контроль? Вас такой сценарий не смущает совсем, ну вот даже нисколько? Ну под какой свой контроль? Что сейчас контроль у Bitcoin Core и они могут увеличить число добавляемых монет в каждом блоке? Нет. Нет у команды Bitcoin Core никакого контроля. И у Хирна не будет. Контроль у майнеров — у китайцев и у bitfury. Вот был такой веб сервер apache. Был у него контроль на WWW? А вот… Read more »
Mad_Max
Гость

Да, есть возражения — похоже ты математику (и арифметику) не понимаешь. Ну либо читать не умеешь: Нужно не 750 блоков подряд, а 750 блоков из любых последовательно выбранных 1000. Т.е. достаточно 75% майнеров, а не 99%. (на самом деле меньше с учетом удачи и вероятности для этого будет достаточно где-то 60-70% майнеров, а 75% это чтобы с гарантией и быстро)

Анонимно
Гость

У кого скроллинг по 3, вы тоже вначале прифигели?

Анонимно
Гость

Скролл по 2 строки тоже нормально.

elite
Гость

Bip100 это подготовка к количеству btc в блоке.

Конечно bip101 погорячился с прыжком до 8 мбайт сразу. Надо было 2 мбайт сделать. И тогда бы bitfury выбрал бы bip101, а не bip100

Georg
Гость
«Исключением является оперативная память: мы предполагаем, что типичный компьютер, поддерживающий узел имеет не менее 3 ГБ оперативки, поскольку биткойн-нода сама по себе отъедает 2ГБ [15]. Для примера, если размер блока увеличится до 2 МБ, на ноде под биткойн-клиент должно быть выделено 8 ГБ оперативной памяти, в то время как на более чем половине компьютеров в опросе установлено меньше памяти.» Здесь мне кажется, какая-то ошибочка. Во-первых, я не вижу, чтобы биткоин-нода брала 2ГБ оперативной памяти. Во-вторых. С чего это, если размер блока увеличится до 2 МЕГАбайт, на ноде должно быть 8 ГИГАбайт памяти. Зачем нужно 6 ГИГАбайт, чтобы обработать дополнительный 1МЕГАбайт… Read more »
Georg
Гость

Не туда вставил пост.

wpDiscuz