---
title: "Блокчейн-трилемма"
description: "Трилемма блокчейна — это эвристика для сравнения масштабируемости, децентрализации и безопасности при явных рабочих нагрузках и моделях угроз. То, что системы буквально выбирают только двоих, не является теоремой или правилом."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Блокчейн-трилемма
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Трилемма блокчейна — это эвристика проектирования: повышение масштабируемости, децентрализации или безопасности в рамках модели с фиксированными ресурсами и доверием может оказать давление на другие измерения. Это не математическая теорема невозможности, аддитивная оценка или правило, согласно которому каждая сеть должна выбирать ровно два свойства.
Каждая ось нуждается в рабочих определениях. Масштабируемость включает в себя устойчивую пропускную способность, задержку, сборы и данные или рост состояния при заявленной нагрузке. Децентрализация включает в себя независимую проверку, несанкционированный вход и выход, а также концентрацию доли или хеш-мощности, операторов, клиентов, облачных провайдеров, географии и управления. Безопасность включает безопасность, жизнеспособность, окончательность, устойчивость к цензуре, доступность данных и восстановление в рамках явной модели противника.
Шардинг, объединение, подтверждение достоверности, легкие клиенты и выборка доступности данных могут улучшить границы осуществимости за счет изменения того, кто выполняет, загружает, хранит, доказывает или проверяет данные. Они не стирают компромиссы: они перемещают затраты на ресурсы и вводят специфичные для уровня предположения о секвенаторах, пруверах, претендентах, мостах, ключах обновления и доступности данных.
## Как это работает
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, модульность или сегментирование устраняют трилемму.** Эти конструкции перераспределяют выполнение, данные, доказательства и доверие; каждая гарантия должна быть прослежена от начала до конца.
- **Три измерения представляют собой фиксированные скалярные оценки или прогнозируют ценность токена.** Измерения являются многомерными и версионными, а экономика токенов представляет собой отдельный вопрос.
## Похожие темы
- [Блокчейн](/ru/crypto/blockchain/)
- [Слой 2](/ru/crypto/layer2/)
- [Модульный блокчейн](/ru/crypto/modular-blockchain/)
## Источники
- [Почему шардинг хорош: демистификация технических свойств](https://vitalik.eth.limo/general/2021/04/07/sharding.html) - Виталик Бутерин (дата обращения: 18 августа 2026 г.)
- [Масштабирование](https://ethereum.org/developers/docs/scaling/) - Ethereum.org (дата обращения: 18 августа 2026 г.)
- [Доступность данных](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (дата обращения: 18 августа 2026 г.)
- [Раскрутите свой собственный узел Ethereum](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (дата обращения: 18 августа 2026 г.)
- [Разнообразие клиентов](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity/) - Ethereum.org (дата обращения: 18 августа 2026 г.)
- [Атака и защита Ethereum по принципу доказательства доли](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (дата обращения: 18 августа 2026 г.)
- [Биткойн: одноранговая электронная денежная система](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (дата обращения: 18 августа 2026 г.)
- [Обзор технологии блокчейн](https://doi.org/10.6028/NIST.IR.8202) - NIST (дата обращения: 18 августа 2026 г.)
Source: https://wiki.fcontext.com/ru/crypto/blockchain-trilemma/index.mdx