Почему эффективность блокчейна трудно измерить

Производительность и масштабируемость — это широко обсуждаемые проблемы в криптопространстве, актуальные как для проектов уровня 1 (независимые блокчейны), так и для решений уровня 2 (таких как объединение и оффчейн-каналы). Однако у нас нет стандартизированных показателей или критериев. Цифры часто сообщаются непоследовательно и неполно, что затрудняет точное сравнение проектов и часто скрывает то, что наиболее важно на практике. 

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

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

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

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

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

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

Масштабируемость по своей сути требует использования параллелизма. В пространстве блокчейна масштабирование уровня 1 требует шардирования или чего-то похожего на шардирование. Базовая концепция шардинга — разделение состояния на части, чтобы разные валидаторы могли обрабатывать данные независимо друг от друга — близко соответствует определению масштабируемости. На уровне 2 есть еще больше возможностей, которые позволяют добавлять параллельную обработку, включая каналы вне цепочки, серверы объединения и сайдчейны.

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

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

К сожалению, задержку и пропускную способность сложно измерить и сравнить. Более того, отдельных пользователей на самом деле не волнует пропускная способность (которая является общесистемной мерой). Что их действительно волнует, так это задержка и комиссии за транзакции, а точнее, чтобы их транзакции подтверждались как можно быстрее и с минимальными затратами. Хотя многие другие компьютерные системы также оцениваются по принципу «стоимость/производительность», комиссии за транзакции — это несколько новая ось производительности для систем блокчейна, которая на самом деле не существует в традиционных компьютерных системах.

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

На первый взгляд задержка кажется простой: сколько времени требуется для подтверждения транзакции? Но всегда есть несколько разных способов ответить на этот вопрос.

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

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

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

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

Задержка — это распределение, а не отдельное число.

Сообщество сетевых исследователей уже давно это поняло (см., например, этот отличный доклад Гила Тене). Особый упор делается на «длинный хвост» распределения, поскольку сильно повышенная задержка даже в 0.1% транзакций (или запросов веб-сервера) будет серьезно влияние конечные пользователи.

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

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

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

Дисперсия на уровне консенсуса: Для подтверждения транзакции на уровне 1 обычно требуется распределенный набор узлов для достижения консенсуса по блоку, что может добавлять переменные задержки независимо от перегрузки. Системы доказательства работы находят блоки в непредсказуемое время (также абстрактно процесс Пуассона). Системы Proof-of-Stake также могут добавлять различные задержки (например, если недостаточное количество узлов находится в сети для формирования комитета в раунде или если требуется смена представления в ответ на сбой лидера).

По этим причинам хорошим руководством будет следующее:

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

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

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

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

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

Задержка сложна. Чем больше данных будет сообщено, тем лучше. В идеале полное распределение задержки должно измеряться в различных условиях перегрузки. Также полезно разбить задержку на различные компоненты (локальная, сетевая, пакетная обработка, задержка консенсуса).

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

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

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

Не все транзакции равны.

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

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

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

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

В общем:

Заявления о пропускной способности требуют тщательного объяснения рабочей нагрузки транзакций и численности валидаторов (их количества, реализации и сетевых подключений). В отсутствие какого-либо четкого стандарта достаточно исторических рабочих нагрузок из популярной сети, такой как Ethereum.

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

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

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

Операционные издержки

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

1. Насколько велик рыночный спрос на совершение транзакций?
2. Какова общая пропускная способность системы?
3. Какой общий доход система приносит валидаторам или майнерам?
4. Какая часть этого дохода основана на комиссиях за транзакции, а не на инфляционных вознаграждениях?

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

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

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

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

Заключение

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

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