Наш опыт масштабирования блокчейна: что нужно для запуска блокчейна со скоростью 100 TPS в течение 2 недель

  • HLCS 

Источник · Перевод автора

Недавно лаборатория блокчейна Jelurida, базирующаяся в Лугано, выпустила свой отчет о загрузке для платформы Ardor.

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

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

Предисловие

Глядя на продукты блокчейна и их отчеты о масштабировании, вы видите странную дихотомию: с одной стороны, существующие производственные блокчейны работают со скоростью около 15 транзакций в секунду, без существенного улучшения в течение последних нескольких лет. С другой стороны, когда вы смотрите на технические документы проекта, вы видите обещания теоретического масштабирования до даже миллионов транзакций в секунду. По некоторым причинам, кажется, трудно преодолеть разрыв между существующими посредственными результатами и фантастическими обещанными результатами. Так почему блокчейн так сложно масштабировать?

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

Полная согласованность против окончательной

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

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

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

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

Полная репликация против частичной

Даже полностью согласованная система может достигать более 100 TPS. Например, в Software AG продукт интеграции с мэйнфреймом JIS, разработкой которого я управлял в течение многих лет, смог масштабироваться до 2000 TPS при использовании мощного сервера, сохраняя при этом полностью согласованное представление о состоянии приложения на мэйнфрейме. То же самое касается многих приложений баз данных. С продуктом JIS ограничение было связано с объемом доступной памяти, использованием ЦП или перегрузкой сети на уровне промежуточного программного обеспечения или самого мэйнфрейма. Мы достигли этого с помощью частичной репликации: и нагрузка, и данные были распределены между несколькими серверами, каждый из которых содержит только часть данных и обслуживает только часть нагрузки.

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

Уроки от Ardor 100 TPS loadtest

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

Это имеет несколько последствий:

  1. Производительность одного узла обычно не является ограничивающим фактором. Следовательно, имеет смысл реализовать узел блокчейна с использованием языка высокого уровня, который обеспечивает лучшую безопасность и более прост в обслуживании (то есть Java), чем с использованием языка низкого уровня, который обеспечивает лучшую производительность (то есть C / C ++).
  2. Способность узлов достигать консенсуса является ограничивающим фактором, поэтому алгоритм консенсуса должен оставаться максимально простым. Он должен основываться на простой формуле, которая может быть рассчитана быстро и эффективно. Я предсказываю, что сложные алгоритмы PoS, которые требуют нескольких раундов голосования, не будут хорошо масштабироваться. Точно так же алгоритм согласования, которому необходимо достичь консенсуса слишком часто, например DAG или блокчейн с очень коротким временем блокировки, будет иметь тенденцию быстро расходиться под нагрузкой.
  3. При большой нагрузке узлы одновременно генерируют блоки независимо, что приводит к разветвлению цепочки блоков. Разрешение этих ветвлений является ресурсоемкой операцией, поскольку для переключения узла на более качественный ответвление необходимо отменить все его существующие блоки до общего блока, а затем переключиться на более совершенный ответвление, предоставленное другим узлом. В идеале разветвление должно быть максимально ограничено путем увеличения времени блокировки, достаточного для уменьшения вероятности двух или более одновременно генерируемых блоков.
  4. Размер блока должен быть под контролем. Использование большого времени блока вызывает узкое место в производительности, так как размер блока увеличивается, а в течение длительного времени между блоками увеличивается количество неподтвержденных транзакций. Если не контролировать эти большие блоки и многие неподтвержденные транзакции, они могут истощать ресурсы узла, вызывая проблемы с нехваткой памяти и нежелательные пики производительности.
  5. Исходя из этих компромиссов, мы обнаружили, что оптимальное время для блокировки в существующей децентрализованной сети составляет от 5 до 10 секунд.

Консенсусные алгоритмы и их потенциал масштабирования

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

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

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

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

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

  • PoW и PoS будут масштабироваться примерно до тех же уровней, хотя и с PoW, для этого потребуется гораздо более сильное оборудование и большие потери энергии.
  • DPoS имеет потенциал для масштабирования лучше, чем PoS и PoW из-за менее частого разветвления за счет некоторой централизации.
  • DAG не должен масштабироваться лучше, чем блокчейн.
  • Я ожидаю, что между различными алгоритмами PoS тренд будет тем проще, чем лучше он масштабируется.

Мы застряли с масштабированием блокчейна, ограниченным до 100 TPS?


Не обязательно. Есть два многообещающих направления для устранения узкого места:

Вне цепочки транзакций

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

Разделяй и властвуй

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

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

Почему так сложно запустить надежный тест?

Некоторые причины:

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

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

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

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

Объединение всего этого в стабильное тестирование нагрузки, которое выполняется более 14 дней, является сложной задачей. Неудивительно, что Ardor — единственный блокчейн, проходящий подобные тесты.

Например, когда мы начали нагрузочное тестирование, мы смогли достичь примерно 20 TPS, прежде чем серверы начали загружать свой ЦП. Выполнение некоторой диагностики показало, что режим объединения транзакций по умолчанию, как только они отправляются, вызывает чрезмерный доступ к базе данных. Чтобы решить эту проблему, мы настроили серверы на выполнение связывания только перед созданием блока. Это решило узкое место, но переместило нас к следующей проблеме. Под аналогичной нагрузкой узлы начали вносить друг друга в черные списки, заставляя каждый узел продолжать свой собственный форк. Для решения этой проблемы потребовался длительный сеанс отладки коммуникационного кода узла, что привело к решению нескольких ошибок и условий гонки и обновлению некоторых конфигураций. Только тогда мы смогли запустить тесты на полную мощность.

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

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