Я. Любимая иллюзия отрасли
Долгое время производительность блокчейна продвигалась как цифра. Пиковая TPS. Миллисекундная окончательность. Лабораторные испытания в идеальных условиях. Хотя эти цифры и заманчивы, они скрывают невероятную правду: пропускная способность не является мерой архитектуры системы.
Скорость не является добродетелью в изоляции. Это стресс-тест.
При рассмотрении последовательных временных интервалов структурные недостатки хорошо скрыты. Транзакции выстраиваются в очередь. Блоки заполняются по порядку. Каждое взаимодействие проходит через одну и ту же узкую полосу обработки. И поскольку все по умолчанию сериализовано, каждое приложение, кажется, подвергается одному и тому же системному сопротивлению. Окружная задержка является принятой характеристикой среды, а не диагностическим сигналом.
Когда пользователи остаются в неведении, потому что разработчики не видят ясно, они не могут понять, в чем проблема. Сеть переполнена? Контракт плохо спроектирован? Становится ли общий объект состояния скрытой точкой затора? Все обрабатывается одно за другим в последовательном порядке, а недостатки архитектуры системы скрываются путем равномерного распределения медлительности по всей системе.
Заторы — это камуфляж в этих ситуациях.
Теперь представьте, что вы применяете ту же программу на SVM-основе Layer 1, такой как Fogo - камуфляж исчезает - транзакции больше не ставятся в очередь случайным образом, потому что они выполняются независимо. Это означает, что не будет предполагаемых конфликтов, если они не заявлены через общее записываемое состояние.
Параллельные стрелы движутся чисто по системе - то есть, пока они не пересекутся с одним изменяемым состоянием.
В этот момент цепь возвращается к сериализации не потому, что цепь медленная, а потому, что архитектура потребовала блокировку.
Узкое место больше не абстрактно, а явно.
И скорость не вводит трение, но выявляет его.
II. Состояние как поверхность конкурентоспособности
В параллельном времени выполнения состояние не является пассивным хранилищем. Это политика конкурентоспособности.
Каждый записываемый аккаунт представляет собой границу блокировки. Когда транзакция заявляет, что намерена изменить аккаунт, время выполнения должно обеспечить эксклюзивный доступ. Если две транзакции пытаются одновременно изменить один и тот же аккаунт, одна должна подождать. Это не неэффективность, это корректность.
Архитектурное следствие серьезно: каждый общий записываемый объект становится поверхностью сериализации. Глобальный счетчик, который обновляется при каждой сделке, метрика по всему протоколу, которая пересчитывается при каждом взаимодействии. Существует один аккаунт ликвидного пула для всех обменов. Когда трафик низкий, эти дизайнерские решения выглядят достаточно безопасными. Когда трафик высокий, они представляют собой верхний предел масштабируемости.
Для работы параллельного выполнения изменения, которые происходят, должны быть независимыми.
Изолированные изменения состояния могут производиться пользователями для отдельных аккаунтов, разделенных пулов или отдельных книг заказов. В этих сценариях время выполнения системы может запланировать изменение этих состояний, не вмешиваясь друг в друга. Это естественным образом увеличивает пропускную способность.
Когда вся активность направлена на одно изменяемое состояние, система вынуждена выполнять последовательную обработку в этом состоянии. Независимо от того, сколько ядер присутствует или каковы задержки, общее состояние становится узким местом.
Это суть проблемы, которую создает требование к параллелизму.
В последовательной системе глобальное состояние полезно. В параллельных системах глобальное состояние — это дорогостоящий ресурс.
При проектировании для конкурентоспособности необходимо проанализировать каждую переменную:
Действительно ли это значение должно быть изменено синхронно?
Можно ли разделить по пользователю, рынку или эпохе?
Можно ли отделить отчетность от корректности?
Могут ли критические пути выполнения быть свободными от аналитики?
Это не микрооптимизация — это структурные обязательства.
Как только система была развернута, параллелизм не может быть добавлен как после мысли. Он должен быть встроен в дизайн топологии состояния с самого начала.
III. Двигатели и Шасси
Высокопроизводительные двигатели генерируют мощность. Изменение размещения двигателя не изменит этой способности.
Поместите двигатель в хорошо выровненное шасси. С правильной геометрией и хорошим распределением всех сил шасси также будет хорошо работать, а ускорение будет плавным. Шасси и двигатель будут работать в симметрии друг с другом, и преобразование энергии в движение не будет потеряно.
Но если тот же двигатель помещается в неправильно выровненное шасси с акцентом на слабые соединения, низкие пути изменятся, и производительность тоже изменится. Вибрация будет усилена. Компоненты будут подвергаться напряжению. Из-за давления будут созданы трещины. Двигатель не выходит из строя. Структура не может выдержать выход.
Вот как работают параллельные временные показатели.
Двигатель SVM, такой как Fogo, предлагает низкую задержку и высокую пропускную способность с конкурентоспособным выполнением. Он не снизит свою производительность, чтобы учесть недостатки в архитектуре. Двигатель не будет заблокирован из-за обобщенного затора.
Это увеличит недостатки структуры.
Если контракт направляет все записи на один аккаунт, произойдет сериализация. Протокол, который зависит от синхронного глобального обновления, будет остановлен на ожидаемых точках конфликта. Время выполнения не уменьшит результаты. Будет ясно, каков будет точный результат.
Ваше предложение было запутанным. Я изменил порядок некоторых слов, но не изменил смысл.
IV. Пятый. Дело в интегративном дизайне.
Цель не в том, чтобы наказывать. Цель — измерять.
Когда интегрированы вертикальные ограничители, фиксированная последовательная цепочка может скрыть недостатки на долгое время. Быстрая параллельная цепочка просто не может.
Как только появляется первый рентген, долг архитектора больше нельзя избегать.
Дисциплина для удержания параллели.
Проектирование для параллельного выполнения требует порядка на уровне состояний:
По умолчанию изоляция пользовательских состояний. Независимость как состояние бытия — это базовый уровень, а не поздняя корректировка.
Общие системы должны быть разделены. Пользователи общих систем, таких как рынки, пулы или книги заказов, должны быть разделены, когда это возможно, чтобы уменьшить поверхности конфликта.
Держите корректность и отчетность отдельно. Внутренние инварианты, которые должны оставаться верными, должны быть синхронными, в то время как аналитика и метрики могут быть асинхронными.
Глобальные записи следует минимизировать. Каждый общий, записываемый аккаунт должен рассматриваться как дефицитный ресурс.
Конфликт следует моделировать явно. Если серийная обработка пользователя, проектируйте, чтобы компенсировать стоимость сдерживания, предполагая отсутствие сериализации.
Цель не заключается в полном устранении общих состояний и систем. Инварианты, которые критичны, требуют определенного уровня координации. Целью должно быть преднамеренное и минимальное сериализование.
Структурная ясность вознаграждается параллелизмом.
V. Что скорость в конечном итоге раскрывает
Быстрая инфраструктура не гарантирует приложениям. Что она гарантирует, так это открытость. *Когда параллельные временные показатели достигают пределов производительности, обычно не загадка, почему. Это прямые результаты общего записываемого состояния, централизованных точек мутации и архитектурных решений, принятых рано и не проверенных.
В этом смысле скорость — это не маркетинговая особенность, это рентген.
Это устраняет размытие, которое когда-то скрывало конфликт. Это различает ограничения сети и недостатки дизайна приложения. Это делает границы блокировки видимыми.
И как только они становятся видимыми, их можно перепроектировать.
Будущее высокопроизводительных блокчейнов не будет определяться только более быстрыми временными показателями. Оно будет определяться тем, понимают ли разработчики урок, который эти временные показатели навязывают: независимость — это масштабируемость.
Пропускная способность не наследуется от цепи. Она зарабатывается через архитектуру.
\u003cm-177/\u003e \u003ct-179/\u003e \u003cc-181/\u003e
