Logo
Поделиться этой статьей

С новыми релизами конкурирующие разработчики программного обеспечения для Bitcoin строят долгосрочные планы

По мере обострения дебатов по поводу масштабирования конкурирующие команды разработчиков биткоина разрабатывают долгосрочные дорожные карты для сети.

потерянный турист
потерянный турист

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

Продолжение Читайте Ниже
Не пропустите другую историю.Подпишитесь на рассылку Crypto Daybook Americas сегодня. Просмотреть все рассылки

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

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

В конце февраля Bitcoin CORE, крупнейшая и старейшая группа разработчиков сети, выпустила новую версиюдорожная карта, а вместе с ним и последний релиз – версия 0.12.0 – программного обеспечения.

Вскоре после этого команда, стоящая заальтернативная реализация Bitcoin Bitcoin Classic анонсировал свою дорожную карту на 2016 год <a href="https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md">https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md</a> , а на этой неделе последовал выпуск последней версии Classic, основанной на версии CORE 0.12.0.

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

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

Генеральный директор Bloq Джефф Гарзик рассказал CoinDesk:

«Сеть быстро Социальные сети победившим форком, [есть] миллиарды стимулов».

В этой статье LOOKS структура этих двух релизов и то, как обе группы продвигаются вперед в реализации своего видения сети Bitcoin .

Классический план действий

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

На первом этапе команда планирует реализовать BIP 109, первоначально предложенный для CORE разработчиком Гэвином Андресеном, что увеличит размер блоков транзакций в сети Bitcoin с текущего 1 мегабайта (МБ) на блок до 2 МБ на блок.

Порогом для этого перехода будет момент, когда 751 из предыдущих 1000 блоков будут добыты с кодом, поддерживающим более крупные блоки. По достижении этого 75%-ного порога начнется 28-дневный период активации.

Андресен рассказал CoinDesk:

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

28-дневный период вызвал беспокойство у некоторых членов сообщества, но Андресен заметил в недавнем интервью:запись в блоге что «несколько крупных майнеров Bitcoin , бирж [и] поставщиков веб-кошельков» указали, что период активации дает им «достаточно времени» для изменения своего программного обеспечения.

Он также защитил 28-дневный льготный период, сравнив его с последним обновлением версии блока.

Андресен объяснил, что для достижения 75% хешрейта потребовался примерно месяц, а после этого потребовалось всего семь дней, чтобы достичь 95% хешрейта.

Другими словами, он считает, что серьезных опасений относительно 28-дневного переходного окна T возникает.

Будущие фазы для Classic

В случае, если хард-форк действительно начнется, Classic вступит во вторую фазу во втором или третьем квартале 2016 года с целью решения проблем размера блока.

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

Далее он заявил, что эта эффективность не вызывает беспокойства при блоках размером 1 МБ или 2 МБ, но что конечной целью второго этапа было «прекратить централизованное принятие решений о «правильном» максимальном размере и вернуться к первоначальному видению Сатоши саморегулирующейся системы».

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

ONE из предложений, представленных в дорожной карте, заключается в использовании вариации адаптивный размер блокана основе недавнего медианного размера блока, описанного в недавнем сообщении в блоге Стивена Пэра, генерального директора BitPay.

«Чтобы определить предельный размер блока, вы вычисляете медианный размер блока по недавней выборке блоков и применяете множитель», — пишет Пэр.

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

Конечно, если кто-то контролирует более 50% майнинговых мощностей, у Bitcoin возникнут более серьезные проблемы, чем ограничение размера блока.

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

Новая версия, опубликованная 7 марта, включает в себя элементы из Bitcoin Core 0.12.0, но, в частности, оставляет функцию замены по комиссии (RBF), с помощью которой пользователи могут ретранслировать транзакции с более высокими комиссиями, если они T были включены в блок, отключенной по умолчанию.

CORE выпускает последнюю версию программного обеспечения

TheCORE команда разработчиков 23 февраля было объявлено о выпуске версии 0.12.0, которую разработчики описали как потенциально «самую большую ONE на сегодняшний день, с самыми значительными улучшениями, чем любая другая».

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

В ноябре 2015 года разработчик CORE Питер Вюйле представил Request на извлечениеперейти на проверку ECDSA на основе libsecp256k1. В нем он объяснил, что такой переход даст три преимущества.

«Проверка подписи выполняется в 2,5–5,5 раз быстрее; Консенсусный код больше не зависит от OpenSSL или его анализатора подписей; Удалена связь с OpenSSL из libconsensus», — написал он.

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

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

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

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

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

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

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

Хирн обрисовал три возможных сценария развития событий в этой ситуации:

«Узел может стать невероятно медленным, когда он попадает в ад подкачки; узел может выйти из строя при попытке выделить память и потерпеть неудачу; узел может быть убит ядром операционной системы».

Чтобы противостоять этому, CORE представила функцию, называемую ограничением пула памяти, которая устанавливает жесткое ограничение по умолчанию на размер пула памяти; в частности, в версии 0.12.0 оно установлено на уровне 300 МБ.

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

Сокращение затрат на ресурсы

0.12.0 также вводит фактор ограничения трафика загрузки. Поскольку узлы постоянно ретранслируют транзакции по сети, это может привести к увеличению объема ресурсов загрузки, что создает нагрузку на отдельные узлы.

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

Чтобы еще больше предотвратить перегрузку узлов, команда ввела функцию обрезки кошельков.

В настоящее время узлы хранят полную копию блокчейна. На момент написания этой статьи это означает, что каждый узел должен хранить 57,8 ГБ данных транзакций. Чем больше становится этот объем, тем больше требуется места для хранения.

Новый «режим обрезки» позволяет тем, кто использует кошелек Bitcoin CORE , сократить необходимое дисковое пространство с 60 ГБ до всего лишь 2 ГБ.

«Это означает, что узел будет сосредоточен только на отслеживании неизрасходованных выходов и забудет ранее обработанные блоки, а также выходы, которые были потрачены», — пояснила команда.

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

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

Изображение потерянного туриста через Shutterstock

Jacob Donnelly

У Якоба есть ценность в Bitcoin, Zcash, Ethereum, Decentraland и Basic Attention Token. (См.: Редакционная Политика). Джейкоб — управляющий директор по цифровым операциям и бывший внештатный автор CoinDesk.

Picture of CoinDesk author Jacob Donnelly