Перейти к основному контенту
Change page

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

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

Предварительные требования

Вам следует прочитать и понять наши страницы о масштабировании Эфириума и уровне 2 (l2).

Что такое каналы?

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

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

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

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

Чтобы закрыть канал, участники отправляют последнее согласованное состояние канала ончейн. После этого смарт-контракт распределяет заблокированные средства в соответствии с балансом каждого участника в конечном состоянии канала.

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

Платежные каналы

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

Обновления баланса реестра (т. е. состояния платежного канала) требуют одобрения всех сторон в канале. Обновление канала, подписанное всеми участниками канала, считается финализированным, во многом как транзакция в Эфириуме.

Платежные каналы были одними из первых решений для масштабирования, разработанных для минимизации дорогостоящей ончейн-активности простых взаимодействий пользователей (например, переводов ETH, атомарных свопов, микроплатежей). Участники канала могут проводить неограниченное количество мгновенных транзакций без комиссий между собой до тех пор, пока чистая сумма их переводов не превысит внесенные токены.

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

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

Каналы состояния по-прежнему имеют много общего с платежными каналами. Например, пользователи взаимодействуют путем обмена криптографически подписанными сообщениями (транзакциями), которые также должны подписать другие участники канала. Если предложенное обновление состояния не подписано всеми участниками, оно считается недействительным.

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

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

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

Каналы состояния не имеют таких же гарантий безопасности. В некоторой степени канал состояния — это миниатюрная версия Мейннета. При ограниченном наборе участников, обеспечивающих соблюдение правил, возрастает вероятность злонамеренного поведения (например, предложения недействительных обновлений состояния). Безопасность каналов состояния обеспечивается системой арбитража споров, основанной на .

Как работают каналы состояния

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

В следующем разделе описывается базовый рабочий процесс канала состояния:

Открытие канала

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

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

Пиры канала должны подписать начальное состояние, с которым они все согласны. Это служит генезисом канала состояния, после чего пользователи могут начать совершать транзакции.

Использование канала

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

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

  • Старое состояние канала

  • Новое состояние канала

  • Транзакция, которая запускает переход состояния (например, Алиса отправляет 5 ETH Бобу)

Обновления состояния в канале не транслируются ончейн, как это обычно бывает при взаимодействии пользователей в Мейннете, что соответствует цели каналов состояния по минимизации ончейн-следа. Пока участники согласны с обновлениями состояния, они так же окончательны, как и транзакция в Эфириуме. Участникам нужно полагаться на консенсус Мейннета только в случае возникновения спора.

Закрытие канала

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

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

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

  • Участники отключаются от сети и не могут предложить переходы состояний

  • Участники отказываются совместно подписывать действительные обновления состояния

  • Участники пытаются финализировать канал, предлагая старое обновление состояния ончейн-контракту

  • Участники предлагают недействительные переходы состояний для подписания другими

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

Урегулирование споров

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

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

Для обработки выхода из канала пользователь должен отправить последнее действительное обновление состояния приложения в ончейн-контракт. Если проверка проходит успешно (т. е. имеется подпись всех сторон), то средства перераспределяются в их пользу.

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

Задержка вступает в силу при выходах одного пользователя из-за возможности мошеннических действий. Например, участник канала может попытаться финализировать канал в Эфириуме, отправив более старое обновление состояния ончейн.

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

Как только пир запускает ончейн-систему разрешения споров, другая сторона обязана ответить в течение установленного срока (называемого окном оспаривания). Это позволяет пользователям оспаривать транзакцию выхода, особенно если другая сторона применяет устаревшее обновление.

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

Как каналы состояния взаимодействуют с Эфириумом?

Хотя они существуют как офчейн-протоколы, каналы состояния имеют ончейн-компонент: смарт-контракт, развернутый в Эфириуме при открытии канала. Этот контракт контролирует активы, внесенные в канал, проверяет обновления состояния и выступает арбитром в спорах между участниками.

Каналы состояния не публикуют данные транзакций или обязательства по состоянию в Мейннет, в отличие от решений для масштабирования уровня 2 (l2). Однако они больше связаны с Мейннетом, чем, скажем, сайдчейны, что делает их несколько безопаснее.

Каналы состояния полагаются на основной протокол Эфириума в следующем:

1. Liveness

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

2. Security

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

В этом случае честная сторона предоставляет последнее действительное состояние канала в качестве доказательства мошенничества ончейн-контракту для проверки. Доказательства мошенничества позволяют взаимно недоверяющим сторонам проводить офчейн-транзакции, не рискуя своими средствами в процессе.

3. Finality

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

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

Виртуальные каналы состояния

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

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

Эта система опирается на существование так называемых «каналов реестра» (ledger channels), которые были профинансированы ончейн. Виртуальные каналы между двумя сторонами могут быть построены поверх существующего канала реестра, при этом владелец (или владельцы) канала реестра выступает в качестве посредника.

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

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

Виртуальные платежные каналы

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

Применение каналов состояния

Платежи

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

Платежи на основе каналов имеют следующие преимущества:

  1. Пропускная способность: Количество офчейн-транзакций на канал не связано с пропускной способностью Эфириума, на которую влияют различные факторы, особенно размер блока и время блока. Выполняя транзакции офчейн, блокчейн-каналы могут достичь более высокой пропускной способности.

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

  3. Задержка: Офчейн-транзакции, проводимые между участниками канала, могут быть финализированы мгновенно, если обе стороны сотрудничают, что сокращает задержки. В отличие от этого, отправка транзакции в Мейннет требует ожидания, пока узлы обработают транзакцию, создадут новый блок с транзакцией и достигнут консенсуса. Пользователям также может потребоваться дождаться большего количества подтверждений блоков, прежде чем считать транзакцию финализированной.

  4. Стоимость: Каналы состояния особенно полезны в ситуациях, когда группа участников будет обмениваться множеством обновлений состояния в течение длительного периода. Единственные понесенные затраты — это открытие и закрытие смарт-контракта канала состояния; каждое изменение состояния между открытием и закрытием канала будет дешевле предыдущего, поскольку стоимость финализации расчетов распределяется соответствующим образом.

Реализация каналов состояния в решениях уровня 2 (l2), таких как роллапы, может сделать их еще более привлекательными для платежей. Хотя каналы предлагают дешевые платежи, затраты на настройку ончейн-контракта в Мейннете на этапе открытия могут стать высокими — особенно когда комиссии за газ резко возрастают. Роллапы на базе Эфириума предлагают более низкие комиссии за транзакции (opens in a new tab) и могут снизить накладные расходы для участников канала за счет снижения комиссий за настройку.

Микротранзакции

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

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

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

Децентрализованные приложения

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

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

Эффективность приложения канала состояния также зависит от его дизайна. Например, разработчик может развернуть контракт канала приложения ончейн один раз и позволить другим игрокам повторно использовать приложение без необходимости переходить ончейн. В этом случае первоначальный канал приложения служит каналом реестра, поддерживающим несколько виртуальных каналов, каждый из которых запускает новый экземпляр смарт-контракта приложения офчейн.

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

Другие возможные варианты использования приложений каналов состояния включают владение именами ENS, реестры NFT и многое другое.

Атомарные переводы

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

Обычно описываемые как «многошаговые переводы» (multi-hop transfers), маршрутизируемые платежи являются атомарными (т. е. либо все части транзакции выполняются успешно, либо она полностью завершается неудачей). Атомарные переводы используют контракты с хешированной временной блокировкой (HTLC) (opens in a new tab), чтобы гарантировать, что платеж будет разблокирован только при выполнении определенных условий, тем самым снижая риск контрагента.

Недостатки использования каналов состояния

Liveness assumptions

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

В реальности пользователи могут отключиться от сети по не зависящим от них причинам (например, плохое интернет-соединение, механическая поломка и т. д.). Если честный пользователь отключается от сети, злонамеренный пир может воспользоваться ситуацией, представив старые промежуточные состояния контракту-арбитру и украв внесенные средства.

Некоторые каналы используют «сторожевые башни» (watchtowers) — сущности, ответственные за наблюдение за событиями ончейн-споров от имени других и принятие необходимых действий, таких как оповещение заинтересованных сторон. Однако это может увеличить затраты на использование канала состояния.

Data unavailability

Как объяснялось ранее, оспаривание недействительного спора требует представления последнего действительного состояния канала состояния. Это еще одно правило, основанное на предположении — что пользователи имеют доступ к последнему состоянию канала.

Хотя ожидание того, что пользователи канала будут хранить копии состояния офчейн-приложения, разумно, эти данные могут быть потеряны из-за ошибки или механической поломки. Если у пользователя нет резервной копии данных, он может только надеяться, что другая сторона не финализирует недействительный запрос на выход, используя старые переходы состояний, находящиеся в ее распоряжении.

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

Liquidity issues

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

Однако каналы реестра, управляемые поставщиком офчейн-услуг (OSP), могут снизить проблемы с ликвидностью для пользователей. Два пира, подключенные к каналу реестра, могут создать виртуальный канал, который они могут открыть и финализировать полностью офчейн в любое время.

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

Griefing attacks

Грифинг-атаки (griefing attacks) являются распространенной особенностью систем, основанных на доказательствах мошенничества. Грифинг-атака не приносит прямой выгоды злоумышленнику, но причиняет горе (т. е. вред) жертве, отсюда и название.

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

Predefined participant sets

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

Хотя это упрощает понимание каналов состояния, это ограничивает полезность дизайна каналов для разработчиков приложений. Это отчасти объясняет, почему от каналов состояния отказались в пользу других решений для масштабирования, таких как роллапы.

Parallel transaction processing

Участники канала состояния отправляют обновления состояния по очереди, поэтому они лучше всего подходят для «пошаговых приложений» (например, игры в шахматы для двух игроков). Это устраняет необходимость обработки одновременных обновлений состояния и сокращает объем работы, которую должен выполнить ончейн-контракт для наказания тех, кто публикует устаревшие обновления. Однако побочным эффектом такого дизайна является то, что транзакции зависят друг от друга, что увеличивает задержку и ухудшает общий пользовательский опыт.

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

Использование каналов состояния

Несколько проектов предоставляют реализации каналов состояния, которые вы можете интегрировать в свои децентрализованные приложения (dapp):

Дополнительная литература

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

Знаете ресурс сообщества, который вам помог? Отредактируйте эту страницу и добавьте его!