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

Блокчейн без разрешений

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

Обновлено

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

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

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

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

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

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

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

Публичность не означает конфиденциальность. Адреса псевдонимны, однако реестр, запросы RPC, соединения с пирами, IP-адреса, время и пути финансирования позволяют связывать активность. Открытая проверка также не создает мгновенного соглашения: локальное принятие, распространение, включение, успешное исполнение, выбор канонического форка и финальность остаются разными состояниями.

Пример

  • Доступ к транзакции по-прежнему имеет ценовой порог. При gasUsed = 21,000, baseFee = 20 gwei, priorityFee = 2 gwei и maxFee = 30 gwei эффективная цена равна min(30, 20 + 2) = 22 gwei. Комиссия составляет 21,000 * 22 = 462,000 gwei = 0.000462 ETH. При курсе 3,000 USD/ETH это 1.386 USD. Одобрение личности не требуется, но финансирование и локальный допуск остаются значимыми.
  • Верификация не дает права предлагать блоки по требованию. В пропорциональной учебной модели с активным эффективным стейком 3,200 ETH доля оператора с 64 ETH равна 64 / 3,200 = 2%. За 10,000 slots ожидаемое число предложений равно 10,000 * 2% = 200; вес предложения полного узла без активированного валидатора равен 0. Фактический выбор и вознаграждения определяет развернутый протокол, а не только это ожидание.
  • Несколько URL могут иметь одну область отказа. Интерфейс указывает 4 RPC URLs, но 3 принадлежат одному оператору, а 1 независим. Доли областей отказа составляют 75% и 25%; индекс Херфиндаля-Хиршмана равен 0.75^2 + 0.25^2 = 0.625 = 6,250. Протокольный доступ может быть открыт, а входной путь приложения концентрирован.
  • Идентификаторы Сивиллы не создают бесплатный вес в консенсусе. Создать 1,000 P2P identities может быть дешево. Активация 1,000 Ethereum validator keys при заявленном минимуме 32 ETH на каждый требует 1,000 * 32 = 32,000 ETH без учета очередей, оборудования и эксплуатации. Число узлов нельзя подменять весом стейка или независимым контролем.

Риски

  • Применение одного ярлыка «без разрешений» ко всем действиям
  • Неверная цепочка, сеть, форк, развертывание или набор правил
  • Аутентификация, ограничение запросов, цензура, отказ или устаревшее состояние RPC
  • Ограничения через интерфейс, домен, кошелек, магазин приложений или географию
  • Отказ или удаление валидной транзакции локальной политикой мемпула
  • Блокировка отправки из-за предела комиссии, баланса, nonce, газа или calldata
  • Цензура, власть над порядком и MEV у построителя или пропозера
  • Концентрация и отказ ретрансляторов, построителей или частного потока ордеров
  • Барьеры капитала, активации, оборудования и эксплуатации валидатора
  • Концентрация майнингового или стейкингового пула, кастодиана и оператора
  • Монокультура клиентов и коррелированные ошибки реализации
  • Барьеры хранения, пропускной способности, синхронизации, истории и доступа к данным
  • Риски загрузочных узлов, DNS, NAT, оценки пиров, изоляции, Сивиллы и ресурсного DoS
  • Деанонимизация по реестру, RPC, IP, времени, финансированию и графу связей
  • Полномочия владельца, прокси, роли, паузы или списка допуска контракта
  • Зависимость от оракула, секвенсора, моста, доступности данных или мультиподписи
  • Сбой залога, срока, данных, вычислений или допуска к доказательству либо оспариванию
  • Смешение принятия, рассылки, включения, валидности и финальности
  • Смешение управления протоколом, принятия клиентами и управления приложением
  • Юридические, географические ограничения, ISP, облака и поставок оборудования

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

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

Похожие темы

Источники

Навигация

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