Перейти к содержанию
Financial Context Wiki

Блокчейн-трилемма

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

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

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

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

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

Как это работает

  1. Укажите цепочку, сеть, версию протокола, уровень и точное архитектурное утверждение. Определите компоненты консенсуса, исполнения, доступности данных, расчетов и управления вместо того, чтобы оценивать только бренд.
  2. Определите масштабируемость, децентрализацию и безопасность с помощью измеримых прокси, рабочей нагрузки и окна наблюдения. Не суммируйте TPS, количество узлов и стоимость атаки в один безразмерный показатель.
  3. Карта, которая предлагает, строит, заказывает, проверяет, хранит данные, доказывает, бросает вызов, модернизирует, приостанавливает и позволяет выйти. Запишите разрешения, границы хранения и аварийного контроля.
  4. Измерьте децентрализацию по ставкам или хеш-мощностям, независимым узлам проверки, клиентскому программному обеспечению, хостингу, географии и управлению. Учитывайте аппаратные средства, пропускную способность, хранилище, время синхронизации и капитальные барьеры.
  5. Измеряйте безопасность как надежность, жизнеспособность, окончательность, устойчивость к цензуре, доступность и восстановление данных при установленных пороговых значениях состязательности, предположениях о корреляции и экономических стимулах.
  6. Измеряйте масштабируемость, используя постоянную и хвостовую пропускную способность, задержку включения и окончательности, сборы под нагрузкой, байты, рост состояния, затраты на синхронизацию и проверку, а также поведение во время перегрузки или сбоя компонента.
  7. Сравнивайте архитектуры с одной и той же рабочей нагрузкой и моделью угроз, проверяйте версии свидетельств и учитывайте сбои. Укажите, какое предположение о стоимости или доверии перемещается между уровнями, вместо того, чтобы утверждать, что трилемма решена.

Пример

  • Гипотетическая полностью реплицированная цепочка, несущая 2 MiB / 12 seconds, имеет 7,200 blocks/day и необработанный вход 2 * 7,200 = 14,400 MiB/day = 14.0625 GiB/day. Увеличение полезной нагрузки до 8 MiB дает 57,600 MiB/day = 56.25 GiB/day, ровно 4x без учета служебных данных протокола, индексов, состояния и репликации. Емкость увеличивается, но эта арифметика не является полным требованием к узлу.
  • Предположим, что операторы доли контролируют 34%, 22%, 18%, 16%, 10%. При установленном пороге блокировки активности >= 1/3 квалифицируется только первый оператор. При установленном пороге управления >= 2/3 наименьшим префиксом являются первые три: 34 + 22 + 18 = 74%; первые два составляют всего 56%. Ссылки на реальные объекты и пороговые значения протоколов по-прежнему требуют проверки.
  • Если 10,000 transactions * 200 bytes = 2,000,000 bytes, но в сводном отчете публикуется 400,000-byte batch, среднее значение составляет 400,000 / 10,000 = 40 bytes/transaction или 5x сжатия данных. Это само по себе ничего не говорит о риске секвенатора, доказательства, моста, доступности данных или ключа обновления.
  • В наглядной модели выборки с 4,096 shares злоумышленник удерживает 25% = 1,024 shares. Если взяты 30 independent uniform samples with replacement, вероятность пропустить все удержанные акции составляет (3,072 / 4,096)^30 = 0.75^30 = 0.0001785821 = 0.01785821%; смоделированное обнаружение — 99.98214179%. Независимость, единообразие и модель удержания налогов являются предположениями, а не гарантией производства.

Риски

  • Рассмотрение эвристики трилеммы как доказанной универсальной теоремы.
  • Масштабируемость, децентрализация или безопасность остаются неопределенными.
  • Добавление непохожих прокси в одну непрозрачную или безразмерную оценку.
  • Рекламируется пиковая TPS вместо устойчивой пропускной способности.
  • Отчетность о средних значениях, скрывая при этом задержку хвоста и поведение при сбое нагрузки.
  • Использование только сборов в качестве меры масштабируемости без рабочей нагрузки или субсидий.
  • Обработка необработанных узлов, валидаторов или счетчиков адресов как независимых объектов.
  • Игнорирование делегированной доли, хэш-мощности и общего контроля оператора.
  • Игнорирование клиентской, облачной, географической и управленческой концентрации.
  • Исключая аппаратные средства, пропускную способность, хранилище, синхронизацию и капитальные барьеры.
  • Вызов системы безопасным без заявленного противника и порога.
  • Смешение безопасности, живости, окончательности, устойчивости к цензуре и восстановления.
  • Игнорирование доступности данных, исторического поиска и роста состояния.
  • Завышение гарантий и предположений легкого клиента, доказательства или выборки.
  • Сравнение пропускной способности L1 и L2, как если бы их гарантии были идентичными.
  • Предполагается, что накопительный пакет наследует все свойства безопасности базового уровня.
  • Игнорирование ключей секвенсора, прувера, претендента, моста, администратора и обновления.
  • Сравнение различных версий протокола, рабочих нагрузок или окон наблюдения.
  • Определение спроса на токены или инвестиционной стоимости на основе качества архитектуры.
  • Объявление постоянного решения после того, как одна оптимизация устранит узкое место.

Распространённые заблуждения

  • Каждый блокчейн должен выбрать ровно два из трёх свойств. Трилемма — это сравнительная эвристика; системы занимают меняющиеся границы компромисса при различных предположениях.
  • Больше валидаторов или узлов автоматически означает большую децентрализацию и безопасность. Веса объектов, программное обеспечение, хостинг, география, управление и независимая проверка имеют значение.
  • Высокое общее число TPS доказывает масштабируемую децентрализацию. Рабочая нагрузка, оборудование, рост данных, хвостовая задержка, комиссии и поведение при сбоях определяют, является ли емкость устойчивой.
  • L2, модульность или сегментирование устраняют трилемму. Эти конструкции перераспределяют выполнение, данные, доказательства и доверие; каждая гарантия должна быть прослежена от начала до конца.
  • Три измерения представляют собой фиксированные скалярные оценки или прогнозируют ценность токена. Измерения являются многомерными и версионными, а экономика токенов представляет собой отдельный вопрос.

Похожие темы

Источники

Навигация

Поиск по вики...