a16z: Основные принципы оценки производительности блокчейна

Автор: Joseph Bonneau, член исследовательской группы a16z crypto

Составитель: Amber, Foresight News

Обсуждение производительности и масштабируемости — это одна из самых устойчивых тем в мире криптовалют.

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

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

Масштабируемость и производительность

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

Почему важно сначала четко определить эти термины? Потому что на самом деле многие методы повышения производительности не повышают масштабируемость. Простой пример — использование более эффективной схемы цифровой подписи, такой как BLS-подпись, размер которой примерно вдвое меньше, чем у Schnorr или ECDSA-подписей. Если бы Биткойн перешел с ECDSA на BLS, количество транзакций в каждом блоке могло бы увеличиться на 20-30%, что мгновенно повысило бы производительность. Но мы можем сделать это только один раз — нет более экономного по объему решения для подписи, на которое можно было бы перейти (подписи BLS также могут агрегироваться для экономии пространства, но это также всего лишь еще один одноразовый трюк).

На самом деле в блокчейн-сетях существует много одноразовых приемов для повышения производительности (например, SegWit), но для нас действительно необходимо иметь масштабируемую архитектуру для достижения постоянного улучшения производительности, только так мы сможем постоянно повышать производительность, добавляя ресурсы. На самом деле в эпоху Web2 это уже стало общепринятой практикой: например, при создании серверов, хотя мы можем сразу построить достаточно быстрый сервер, в конечном итоге обычно требуется обновление до многосерверной архитектуры, при этом необходимо постоянно добавлять новые серверы для удовлетворения растущих потребностей в хранении/обработке данных.

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

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

Задержка и пропускная способность

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

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

Проблемы с измерением задержки

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

Наиболее распространенный метод — измерять с точки зрения валидатора, от момента, когда клиент впервые транслирует транзакцию, до момента, когда транзакция считается разумно подтвержденной (в некотором смысле, реальные торговцы будут учитывать момент получения платежа и отправки товара). Конечно, разные торговцы могут использовать разные стандарты принятия, даже один и тот же торговец может применять разные стандарты в зависимости от суммы транзакции.

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

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

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

Для блокчейна задержка подтверждения может варьироваться по нескольким причинам:

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

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

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

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

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

Сети платежных каналов (например, Lightning Network) являются хорошим примером. Как классическое решение L2 для масштабирования, эти сети в большинстве случаев предлагают очень быстрые услуги подтверждения платежей, но иногда им требуется сброс канала, что может привести к увеличению задержки на несколько порядков.

Даже если у нас есть хорошие статистические данные о точном распределении задержек, они могут изменяться со временем в зависимости от системы и требований системы, и как сравнивать распределения задержек между конкурентными системами также очень неясно. Например, рассмотрим систему, которая подтверждает транзакции с равномерным распределением задержек от 1 до 2 минут (среднее и медиана 90 секунд). Если конкурентная система точно подтверждает 95% транзакций за 1 минуту и еще 5% за 11 минут (среднее 90 секунд, медиана 60 секунд), то какая система лучше? Ответ заключается в том, что разные категории приложений могут выбирать по-разному.

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

Проблемы с измерением пропускной способности

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

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

В сети Ethereum транзакции могут содержать произвольный код и произвольное состояние. Концепция Gas в Ethereum используется для количественной оценки (и взимания платы за) общего объема работы, выполняемой транзакцией, но это сильно ограничено средой выполнения EVM. Нет простого способа напрямую сравнить общий объем работы, выполненной набором транзакций EVM, с набором транзакций Solana, использующими BPF-среду. Также неразумно напрямую сравнивать любую из них с набором транзакций Биткойна.

Разделение уровня транзакций на уровень консенсуса и уровень выполнения может сделать это более ясным. На (чистом) уровне консенсуса пропускная способность может измеряться в байтах, добавляемых в цепочку за единицу времени. Уровень выполнения будет гораздо сложнее.

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

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

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

Комплексное рассмотрение задержки и пропускной способности

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

Системы ZK Rollup предоставляют естественный пример компромисса между пропускной способностью и задержкой. Большие объемы транзакций увеличивают время доказательства, что увеличивает задержку. Однако в отношении размера доказательства и затрат на верификацию вычислительная мощность на цепи будет наклоняться к более крупным кластерам транзакций, что повысит пропускную способность.

Стоимость транзакций

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

• Каков уровень рыночного спроса?

• Какова общая пропускная способность, которую система может реализовать?

• Какой доход система предоставляет валидаторам или майнерам?

• Какова доля этого дохода, основанная на транзакционных сборах и инфляционных вознаграждениях?

Проще говоря, при прочих равных условиях более высокая пропускная способность должна приводить к более низким затратам. Однако пункты 3 и 4, упомянутые выше, являются основными вопросами проектирования блокчейн-систем. Несмотря на то, что было проведено много экономических анализов блокчейн-протоколов консенсуса, у нас все еще нет согласованной модели о том, сколько дохода необходимо валидаторам. Сегодня большинство систем основаны на обоснованных предположениях о том, сколько дохода достаточно, чтобы валидаторы действовали добросовестно, не влияя на привлекательность сети для пользователей. В упрощенной модели достаточно, чтобы стоимость инициирования атаки 51% была пропорциональна вознаграждению валидаторов.

Увеличение стоимости атаки — это хорошо, но мы также не знаем, сколько безопасности «достаточно». Представьте, что вы рассматриваете возможность посетить два парка аттракционов. Один из них утверждает, что расходы на обслуживание аттракционов на 50% ниже, чем у другого. Стоит ли идти в этот парк? Возможно, они более эффективны и могут обеспечить аналогичную безопасность за меньшие деньги. Возможно, что у другого парка расходы превышают необходимые для обеспечения безопасности аттракционов, и это не приносит никаких преимуществ. Но также возможно, что первый парк очень опасен. Блокчейн-системы аналогичны. Как только мы учитываем пропускную способность, блокчейны с более низкими затратами имеют более низкие затраты, потому что они предлагают меньше вознаграждений. У нас нет хороших инструментов для оценки, жизнеспособно ли это или сделает ли это систему уязвимой для атак. В общем: сравнение затрат между системами может быть несколько вводящим в заблуждение. Хотя транзакционные сборы важны для пользователей, они также зависят от множества факторов, помимо самого проектирования системы. Пропускная способность является лучшим показателем для анализа всей системы.

Заключение

Справедливо и точно оценить производительность — это сложно. Измерение блокчейна и оценка того, стоит ли покупать автомобиль, столь же сложны, разные люди заботятся о разных вещах: для автомобилей некоторые пользователи заботятся о максимальной скорости или времени разгона до 100 км/ч, некоторые заботятся о расходе топлива, а некоторые просто интересуются, сколько груза может вместить автомобиль. Именно поэтому Агентство по охране окружающей среды США даже разработало руководство по оценке автомобилей.

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