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

Модульная архитектура блокчейна

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

Обновлено

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

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

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

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

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

  1. Зафиксируйте развернутую систему: идентификаторы цепей исполнения и расчетов, версию протокола, виртуальную машину, контракты, адреса моста и активов, режим доступности данных, операторов, администраторов и блок либо время наблюдения. Маркетинговая классификация не заменяет развернутую конфигурацию.
  2. Постройте матрицу обязанностей. Разделите прием и упорядочивание транзакций, детерминированное исполнение, обязательство состояния и доказательство либо спор об ошибке, публикацию DA и ее консенсус, принятие расчетной цепью и финальность, мост и междоменные сообщения, обновления и паузы, историческое хранение. Фиксируйте пересечения, не назначая каждой обязанности ровно один уровень.
  3. Проследите одну транзакцию и пакет от начала до конца: подписанный вход, квитанцию секвенсора или локального узла, упорядоченное исполнение, закодированный и сжатый пакет, публикацию через calldata, blob или внешний DA, заявление состояния и доказательство либо спор, финальность расчетов, затем исполнение сообщения или вывода. Сохраняйте хеши, версии, квитанции и часы на каждой границе.
  4. Определите каждый проверяемый объект и допущение доверия. Отличайте обязательство данных от байтов, доступность в протокольном окне от последующего извлечения, корректность исполнения от финальности консенсуса, мостовой учет от ликвидности актива. Укажите, кто может повторно исполнить, доказать, оспорить, цензурировать, обновить, приостановить или удержать каждый объект.
  5. Восстановите журнал емкости и комиссий. Измерьте исходные и сжатые байты, заполнение пакета, цену DA, накладные расходы доказательства и расчетов, комиссии исполнения и оператора, газ моста и комиссию ликвидности. Среднее распределение затрат пакета не равно фактической комиссии пользователя или предельной стоимости еще одной транзакции.
  6. Проверяйте сбои, а не только пропускную способность штатного пути. Остановите секвенсор, отправителя пакетов, доказателя, оспаривателя, службу DA, расчетный RPC и ретранслятор моста; проверьте принудительное включение, независимый вывод состояния, восстановление данных, доказательство или спор, повтор, выход и восстановление архива при перегрузке и на границах обновления.
  7. Сверьте результат с каноническими доказательствами. Сопоставьте квитанции исполнения и корни состояния с обязательствами пакетов, включением DA, состоянием доказательства или игры, финальностью расчетов, сообщениями моста и итоговыми балансами активов. Повторите анализ зависимостей после реорганизации, изменения параметров, обновления контракта или миграции DA.

Разобранные примеры

  • Стоимость пакета и сжатие. Пакет содержит 5,000 транзакций, 2,400 KB исходных данных и 300 KB после сжатия. Коэффициент сжатия равен 2,400 / 300 = 8.0x, а объем байтов снижается на 87.5%. Если DA стоит 0.020 ETH, а общие накладные расходы доказательства и расчетов — 0.005 ETH, средняя общая стоимость равна (0.020 + 0.005) / 5,000 = 0.000005 ETH/tx. После добавления 0.000020 ETH/tx за исполнение и оператора получается 0.000025 ETH/tx. Это распределение, а не гарантированный счет.
  • Граница модели выборки. В учебной модели противник скрывает 25% долей, а клиент берет 20 независимых равномерных выборок с возвращением. Вероятность не попасть ни в одну скрытую долю равна 0.75^20 = 0.003171211939 = 0.3171211939%, вероятность обнаружения — 99.6828788061%. Коррелированные узлы, адаптивная выдача, корректирующее кодирование и реальные правила выборки могут сделать модель неприменимой.
  • Безопасность и работоспособность комитета. Комитет DA с порогом 5-of-7 может сформировать новую аттестацию, если недоступны не более 2 участников; при недоступности 3 остаются только 4 < 5. В учебном правиле, проверяющем лишь подписи, контроль над 5 уполномоченными подписантами удовлетворяет порогу. Сертификат не доказывает наличие пяти долговечных копий, возможность извлечь байты сейчас или корректность исполнения и расчетов.
  • Несколько часов и быстрый выход. Учебное предварительное подтверждение приходит через 2 seconds, пакет публикуется через 8 minutes, а финальность расчетов наступает еще через 13 minutes: точное время составляет 21 minutes 2 seconds. Если оптимистичный вывод добавляет гипотетические 7 days, итог равен 10,101 minutes 2 seconds. Быстрый мост с комиссией 0.15% от 10,000 USDC удерживает 15 USDC и выдает 9,985 USDC; скорость добавляет допущения моста, поставщика ликвидности и реорганизации, а не сокращает протокольные часы.

Риски

  • Неверное определение реальных обязанностей или границ уровней.
  • Цензура, переупорядочивание или отказ секвенсора.
  • Недоступное, разрешительное или слишком медленное принудительное включение.
  • Отказ отправителя пакетов или заявителя состояния.
  • Отказ централизованного доказателя или очередь доказательств.
  • Отсутствие активного, правомочного и обеспеченного оспаривателя ошибок.
  • Сбой часов игры об ошибке, залога, оракула или верификатора.
  • Ошибка схемы корректности, системы доказательства или ключа проверки.
  • Удержание данных в обязательном окне доступности.
  • Коррелированная выборка, изоляция узла или сбой сетевого представления.
  • Сговор порога комитета DA или компрометация ключей.
  • Отсутствие долговечных независимых архивов доступных протокольных данных.
  • Реорганизация расчетной цепи или неверная классификация финальности.
  • Сбой моста, мессенджера, защиты от повтора или исполнения в назначении.
  • Неплатежеспособность быстрого моста, нехватка запасов или невыгодная цена.
  • Компрометация администратора, мультиподписи или совета безопасности.
  • Мгновенное обновление, несовместимая версия или недостаточная задержка выхода.
  • Рост цены DA, перегрузка blob, меньшие пакеты или прекращение субсидии.
  • Несовпадение версий состояния, данных, доказательства, контракта или клиента.
  • Асинхронный междоменный порядок, частичное завершение или сбой компонуемости.

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

  • Модульная архитектура автоматически более децентрализована, чем монолитная.
  • Доказательство корректности заменяет доступность и историческое извлечение данных.
  • Расчеты в Ethereum передают каждому компоненту все свойства безопасности Ethereum.
  • Сообщение секвенсора об успехе означает финальные расчеты и исполнимый вывод.
  • Высокий TPS, общий DA или общие расчеты гарантируют меньшую стоимость и синхронную компонуемость.

Похожие темы

Источники

Навигация

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