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

Каналы состояния

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

Обновлено

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

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

Канал состояния — протокол, в котором фиксированный набор участников блокирует активы или задаёт исполнимые правила в блокчейне, а затем обменивается заверенными обновлениями вне него. Блокчейн не обрабатывает каждое обновление, а выступает окончательным арбитром при закрытии или споре.

Каждое принятое обновление связано с каналом, состоянием приложения или распределением средств и возрастающим номером хода либо nonce. По правилам канала новое корректное состояние заменяет старое. Платёжный канал в основном учитывает балансы; универсальный может представлять ходы игры, сделки и другие детерминированные данные.

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

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

  1. Открытие и финансирование. Стороны согласуют личности, правила, длительность оспаривания и начальное распределение. Средства блокируются в контракте-арбитре или канал создаётся из уже профинансированного канала; это уже не обычный доступный баланс.
  2. Обмен подписанными состояниями. Стороны вычисляют следующее корректное состояние и обмениваются подписями или сообщениями. Уникальный идентификатор и возрастающий порядок не дают подменить подписью другого канала или старого раунда.
  3. Хранение комплекта для исполнения. Кошелёк или узел сохраняет последнее состояние, подписи, условные переводы и необходимые данные отзыва или секреты. Seed-фраза может восстановить ключи, но не обязательно постоянно меняющиеся данные канала.
  4. Работа вне блокчейна. Множество обновлений обходится без базовой транзакции. Переводы ограничены распределением и резервами в нужном направлении; маршрут через несколько каналов зависит от ликвидности и доступности на каждом участке.
  5. Совместное закрытие. Стороны подписывают итог и отправляют минимальную транзакцию. Обычно это исключает гонку оспаривания и быстрее или дешевле одностороннего закрытия.
  6. Перенос спора в блокчейн. Если участник исчез или предъявил устаревшее состояние, другая сторона подаёт исполнимое доказательство. Арбитр применяет порядок, сроки и переходы. Одни схемы оспаривают старое новым; каналы типа Lightning используют обязательства и отзывы, а не общую гонку за максимальным nonce.
  7. Финализация после срока. После периода оспаривания или timelock стороны забирают результат. Пока все выходы не разрешены, программе может требоваться следить за реорганизациями и повышать комиссию срочных транзакций.

Пример

Alice и Bob открывают двусторонний канал, внося по 5 ETH; всего он контролирует 10 ETH. Подписанное начальное состояние — ход 0: Alice получает 5 ETH, а Bob получает 5 ETH.

Alice платит Bob 1 ETH. Они проверяют переход и подписывают ход 1: Alice получает 4 ETH, Bob — 6 ETH. Затем Bob платит Alice 2 ETH; ход 2 выделяет Alice 6 ETH, Bob — 4 ETH. При сотрудничестве в базовую сеть попадают лишь финансирование и итоговый расчёт.

Если Bob позже предъявит ход 1, в схеме с максимальным ходом Alice должна до срока показать полностью поддержанный ход 2. Контракт отклонит старое и рассчитает ход 2. Если ход 2 потерян, ключ недоступен, нет базового актива на комиссию или Alice остаётся офлайн до истечения срока, протокол не восстановит закрытую историю. Исполнимый итог может отличаться от последнего соглашения.

Это концептуальный пример. Реальные протоколы точно задают подписи, переходы, условные платежи, вызовы и сроки. Не переводите средства, опираясь лишь на эту упрощённую арифметику.

Риски и меры контроля

  • Расчёт по старому состоянию. Храните полный свежий комплект и проверяйте восстановление. До использования watchtower выясните, какие данные и полномочия он получает.
  • Пропущенный срок. Следите за правильной сетью до полного разрешения, учитывая сбои, реорганизации, перегрузку и время реакции людей.
  • Комиссии и перегрузка. Держите свободный базовый актив и способ повысить комиссию. Массовые споры могут удорожить именно срочный выход.
  • Потеря ключа или состояния. Используйте документированный способ резервирования. Не восстанавливайте активный канал из старого снимка без явной гарантии.
  • Ёмкость и маршрутизация. Проверяйте входящую и исходящую ликвидность, резервы, лимиты, сроки и посредников. Общий баланс не равен доступной ёмкости.
  • Контрагент и доступность. Обычно он не изменит защищённый итог, но может отказаться от обновления или совместного закрытия и вынудить долгий спор.
  • Реализация. Ошибки клиента, арбитра, домена подписи, переходов или обновлений могут нарушить гарантии. Проверяйте развёрнутый код и аудиты.
  • Утечка приватности. Off-chain не означает анонимность: пиры, маршрутизаторы, наблюдатели, копии и итоговый спор могут раскрыть связи или данные.

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

  • «Вне блокчейна значит без доверия и без блокчейна». Доверие ограничивает надёжный путь исполнения в сети; его безопасность, доступность и цена важны.
  • «Любое состояние с двумя подписями будет рассчитано». Исполнимость определяют правила порядка, корректности, финальности, отзыва и сроков.
  • «Seed-фраза восстанавливает весь канал». Обычно она возвращает ключи, но не обязательно состояние, секреты, ожидающие переводы или базу пиров.
  • «Можно оставаться офлайн бесконечно». Многие схемы требуют наблюдать и отвечать в срок лично либо через делегированный сервис.
  • «Ёмкость равна балансу кошелька». Средства надо закрепить в канале; важны направление, резервы, ожидания и маршрутная ликвидность.
  • «Каналы всегда заменяют rollup». Они хороши для повторных действий известных сторон; открытое участие, глобальное состояние и широкая компонуемость могут требовать rollup или on-chain исполнения.

Связанные темы

Источники

Навигация

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