# L2/Keyless.one - Протокол каналов для UXTO v.1

Created: Aug 27, 2019 2:53 AM
Created By: Ivan Kocheshev
Last Edited By: Ivan Kocheshev
Last Edited Time: Aug 28, 2019 11:48 AM
Status: In Progress 🙌
Topic: Keyless
Type: Technical Spec
Reference: Bitcoin Payment-Channels for Resource Limited
IoT Devices. Christopher Hannon and Dong Jin. https://arxiv.org/abs/1812.10345

## **Транзакции во втором слое**

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

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

• **nLockTime** указывает минимальную высоту блокчейна, в которую может быть включена транзакция.

• **CheckLockTimeVerify** требует, чтобы блокчейн находился на определенной высоте для вывода результатов уже включенной транзакции.

• Относительный **LockTime** накладывает ограничения на включение ввода в новую транзакцию, основываясь на времени, когда ввод был включен в предыдущую транзакцию.

• **CheckSequenceVerify** предоставляет относительное время, в течение которого выходные данные транзакции становятся действительными после включения в блок.

• **Multisig** может использоваться, чтобы требовать m - of - n подписей, чтобы стать действительными.

**nLockTime** и **Relative Locktime** являются соответствующими аналогами для абсолютного и относительного времени соответственно для включения в цепочку блоков, в то время как **CheckLockTimeVerify** и **CheckSequenceVerify** являются аналогами для абсолютного и относительного времени соответственно, чтобы сделать выходные данные допустимой транзакции расходуемой.

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

Комбинация хэш-блокировок и временных блокировок может создать контракты с временным хеш-блокированием (💡**HTLC**), которые можно использовать для перевода биткойн-транзакций в «цепочку» через так называемые решения масштабирования L2 или уровня 2, такие как Lightning Network, дуплексные каналы микроплатежей и Райден. Наш протокол использует CheckSequenceVerify и Multisig для каналов оплаты, аналогичных транзакциям Lightning Network. **Транзакции вне цепочки - это правильно отформатированные транзакции в биткойнах, которые не подлежат немедленной публикации в блокчейне.** Преимущество заключается в том, что внеочередные транзакции могут многократно обновляться перед публикацией в блокчейне, что приводит к сокращению внутрицепных транзакций и, в конечном итоге, к снижению сборов.

Каналы могут быть созданы однонаправленными или дуплексными, а транзакции могут быть обновлены таким образом, чтобы гарантированно были включены окончательные балансировки каналов. Это достигается за счет того, что новые транзакции имеют меньшие временные блокировки, чем более ранние транзакции, и, следовательно, могут быть опубликованы раньше, чем старые недействительные транзакции. Ограничением этого подхода является то, что каналы будут иметь ограниченную жизнь. Ссылки [6] и [8] позволяют каналам оставаться открытыми неограниченное время или до тех пор, пока владельцы не решат закрыть канал.

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

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

Интуиция нашего протокола заключается в использовании многозадачной транзакции для финансирования канала. Промежуточные состояния делаются отзывными, как разработано в [6]. Наш вклад заключается в обеспечении правильности и криптоэкономической справедливости, когда одна сторона не имеет доступа к блокчейну. Для этого мы используем третье лицо для публикации транзакций в блокчейне, создавая дополнительный вывод, который может использоваться третьим лицом. Создавая экономический стимул, третье лицо готово участвовать в протоколе. Кроме того, чтобы гарантировать, что вторая сторона не нарушает протокол, публикуя отмененное состояние, в качестве сторожевого устройства используется третья сторона, которая сообщает первой стороне, когда выходные данные транзакции финансирования используются в качестве входных данных для новой транзакции. Этот сторожевой таймер сообщит, когда промежуточное состояние будет опубликовано в блокчейне, что предотвращает публикацию состояния с истекшим сроком. Кроме того, чтобы предотвратить сговор между второй стороной и третьими сторонами, мы используем пул третьих сторон для каждой услуги. Поскольку любой член третьей стороны может взять на себя роль, стимул должен быть выше, чем любой стимул от сговора. В разделе IV мы формулируем задачу как игру и показываем, что равновесие достигается путем следования протоколу.

Детали протокола следующие. Для каждого устройства IoT A платежный шлюз IoT B создает канал оплаты. И A, и B генерируют 3 набора j пар ключей (pk {B | A} j {a | b | c}, sk {B | A} j {a | b | c}), так что каждая промежуточная транзакция использует свой ключ - пара, составляющая j число промежуточных состояний. Кроме того, мы генерируем пару ключей для открытия и закрытия канала (pk {B | A} {FT | close}, sk {B | A} {FT | close}) и другую пару для транзакции A с третьи лица, (pk A 3rd {a | rc}, sk A 3rd {a | rc}). Чтобы минимизировать требования к памяти устройств IoT, мы используем BIP32, который обеспечивает детерминированный алгоритм генерации иерархического ключа с сильно сжатой структурой данных [10]. Все ключи могут быть сгенерированы с заданным мастер-ключом и индексом в структуре данных. По сути, это позволяет хранить индекс вместо пары ключей, поскольку общие требования для хранения состояния являются ключевым индексом и балансами.

Обе стороны соглашаются разместить транзакцию финансирования TF T на блокчейне, которая отправляет ΩA и ΩB в качестве входных средств от A и B соответственно. Выход канала - мульти-подпись 2-из-2, требующая, чтобы и {B, и A} B тратят sk {B | A} FT. Кроме того, обе стороны договариваются о первоначальной транзакции обязательства TC1, которая представляет собой действительное расходование средств из TFT на вход и возврат ΩA и ΩB в качестве выходных данных. Обратите внимание, что транзакция не публикуется в блокчейне, и ее целью является обозначение начального баланса в канале платежей. Ссылка [6] показывает, как можно построить две транзакции, TC1 B и TC1 A, так что B является единственной стороной, которая может опубликовать TC1 A, а A является единственной стороной, которая может опубликовать TC 1 B. Этот механизм реализуется путем предоставления одной из требуемых входных сигнатур 2-из-2, то есть частичного подписания транзакции.

Кроме того, транзакции TC 1 B и TC 1 A делаются отзывными, ограничивая выходы способности соответствующей стороны отправлять выходные данные. Например, если A публикует TC 1 B, вывод ΩB может быть немедленно погашен B. Однако средства ΩA заблокированы. Есть два способа выкупить заблокированные средства. Первый - использовать секретные ключи A и B sk1s для мульти-подписи 2-из-2. Второе - использовать временную блокировку для погашения фонда в A после блоков W, где W - количество блоков, указанное в временной блоки. B может использовать первый механизм для кражи всех средств As после того, как обе стороны обновят состояние канала для новых транзакций TC2 B и TC2 A. После обновления A отправляет sk1 в B (а B отправляет sk1 в A). Воровство средств основано на механизме предотвращения публикации старых транзакций, чего можно добиться, проверив блок B цепочкой перед некоторыми блоками W после публикации TC1 B. Этот механизм является способом гарантировать, что обе стороны следуют протоколу, даже если обе стороны не доверяют друг другу.

Однако поскольку предполагается, что устройства IoT не имеют прямого доступа к блокчейну, две непересекающиеся группы ненадежных третьих сторон используются для взаимодействия между устройством IoT и блокчейном. В каждой группе есть несколько членов, соответственно K1 и K2, для предотвращения сговора с B. Первая группа используется для публикации транзакции в цепочке блоков, стимулируемой небольшой платой, в качестве вывода в транзакцию. Вторая группа гарантирует, что, если B публикует старую транзакцию, IoT-устройство уведомляется о транзакции и может потратить выходные данные транзакции до истечения временного интервала W для B, чтобы выкупить свои средства. Эта вторая группа также стимулируется за счет небольших комиссий в смарт-контрактах Биткойн. Транзакции 3-5 показывают способ сделать это. Чтобы не допустить сговора третьих сторон друг с другом или с B, количество участников в каждой третьей стороне должно быть выбрано с учетом количества сборов, а также остатков канала.

Когда обе стороны договариваются о закрытии канала, они могут создать новую транзакцию TF, в которой используются ΩA fin и ΩB fin в качестве конечных выходных сальдо, и опубликовать ее в блокчейне. Если обе стороны должным образом следуют протоколу, только две транзакции, TFT и TFin, публикуются в блокчейне. Если одна сторона пытается опубликовать старое состояние канала TCi (B / A), другая сторона может обнаружить это и забрать все средства в канале.

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


**Транзакция 2**, используется при взаимном закрытии канала, она использует многосигнатурный вывод из транзакции финансирования и использует несколько выходов для A и B. Если устройство IoT, при желании опубликовать транзакцию, плата σ может быть размещена на входе для третьей стороны, которая будет заинтересована в публикации.

**Транзакция 3** принимает выходные данные транзакций финансирования и создает 3 выходных данных. Первый вывод является локальным для A, стороны с возможностью опубликовать его. Эти выходные данные обременены временной блокировкой блоков W по адресу A, чтобы гарантировать, что если транзакция является старой. Другими словами, A дал пару ключей (pk {A} j {c}, sk {A} j {c}) B, и B может использовать этот ввод. Второй выход является удаленным выходом для B. Наконец, есть третий выход, который является стимулом для третьей стороны отправлять транзакцию в блокчейн и убедиться, что транзакция включена в блок.

**Транзакция 4** принимает выходные данные транзакций финансирования и создает 2 выходных данных. Поскольку A частично подписывает входные данные для этой транзакции, только B может опубликовать ее. Первый выход синхронизируется с блоками W с выходом на B. A также может выкупить данный вход (pk {B} j {c}, sk {B} j {c}). Существует сторонняя организация, которая наблюдает за цепочкой блоков, ключ которой требуется для того, чтобы А использовал этот вход. При этом третья сторона также получает взамен плату.

**Транзакция 5** принимает это как ввод и может быть назначена. Эта транзакция восстановления используется в качестве интеллектуального контракта, чтобы побудить третье лицо наблюдать за блокчейном, предоставляя комиссию, определенную членами третьей стороны. Второй выход для транзакции 4 используется для удаленного вывода на A.
Биткойн-скрипты, используемые для всех вышеупомянутых транзакций, показаны в Приложении А, чтобы обеспечить канал оплаты в реальном времени для устройств IoT со шлюзом IoT.

:::info
**Это не полный перевод оригинального документа** только части косвенно касающиеся непосредственно канала. отсылки к внешним источникам, встречающиеся по ходу перевода приведены в оригинале
:::