Компьютеры в сети взаимодействуют друг с другом в соответствии с протоколами. Здесь «протокол» относится к системе правил, определяющих, как сообщения должны передаваться и интерпретироваться. Часть передачи платежных сообщений сетевого протокола Lightning описана в BOLT#4, также известном как «Протокол луковой маршрутизации (Протокол луковой маршрутизации)».
Onion Routing — это технология, которая предшествовала Lightning Network на 25 лет. Он также используется в Tor, откуда и произошло название «Tor» («Луковый маршрутизатор»). Lightning Network использует слегка измененную версию, называемую «луковой маршрутизацией на основе источника», сокращенно «SPHINX». В этой статье мы поговорим о том, как работает луковая маршрутизация.
Зачем использовать луковую маршрутизацию?
В мире существует множество различных коммуникационных протоколов, но поскольку Lightning Network является платежной сетью, имеет смысл выбрать такой протокол, который раскрывает как можно меньше информации о пересылаемом платеже.
Если бы Lightning Network использовала тот же протокол, что и Интернет, каждый посредник знал бы, кто был отправителем платежа, кто был получателем и кто другие посредники на пути. Луковая маршрутизация — хороший выбор, поскольку ее характеристики гарантируют наличие промежуточных узлов:
Знайте только свой предыдущий узел (кто отправил вам сообщение) и следующий узел (куда вы хотите переслать сообщение).
не знает длину всего пути;
Не зная, где вы находитесь на пути.
Обзор луковой маршрутизации
Давайте используем посылку в качестве аналогии, чтобы объяснить, как работает луковая маршрутизация.
Предположим, Алиса хочет заплатить Дине. Во-первых, Алисе нужно найти допустимый путь для своего платежа:
Алиса→Боб→Чан→Дина
Затем она строит «луковицу». Она начинается с Дины (с конца пути). Она кладет секретное сообщение (содержимое платежа) в пакет, отправленный Дине, и запирает его ключом, известным только ей и Дине. Теперь она кладет этот пакет в другой пакет для отправки Чану и запирает пакет для Чана ключом, известным только ей и Чану. Правильно и так далее.
Алиса отправляет последнюю луковицу (пакет) первому посреднику на пути, Бобу. Боб открывает свою посылку своим ключом и видит, что следующая посылка предназначена для Чана. Поэтому он переслал посылку Чану. То же самое касается Чана: распаковав посылку, он переслал ее Дине. Наконец Дина открыла свой пакет и нашла внутри платежное сообщение.
В луковой маршрутизации посредники, такие как Боб и Чан, не знают ни содержания сообщения Дине, ни длины всего платежного пути. Единственное, что они знают, это то, кто отправил им посылку и кто получит ее следующим. Это гарантирует конфиденциальность сообщения и конфиденциальность пути. Каждый посредник может касаться только специально созданного для ТА слоя сообщений.
В луковичной маршрутизации Lightning Network на основе источника отправитель выбирает путь платежа и создает полный лук для этого пути, который можно рассматривать как дыру в конфиденциальности (Примечание переводчика: сетевое местоположение получателя должно быть доступно отправителю). Другие схемы маршрутизации, такие как «слепая маршрутизация» (китайский перевод), решают эту проблему, запутывая часть пути платежа к отправителю. Однако в этой статье мы сосредоточимся исключительно на SPHINX.
Соберите лук
Теперь давайте взглянем на спецификацию луковой маршрутизации. В начале нам нужно определить следующие вещи:
Отправитель - "начальный узел" (Алиса);
Приемник - "конечный узел" (Дина);
Каждый промежуточный узел на пути оплаты является «переходом» (Боб и Чан);
Информация о связи между каждым прыжком называется «загрузкой прыжка».
Построить скачковую нагрузку
Как только Алиса выбрала путь платежа, она получает информацию для каждого платежного канала из протокола сплетен, чтобы создать полезную нагрузку для каждого прыжка, по существу сообщая каждому прыжку, как создать HTLC для пересылаемого платежа (контракт хеш-таймлока).
Чтобы установить правильный HTLC, каждый переход должен:
Сумма, которую необходимо переслать;
секретное значение выплачивается;
ID платежного канала, который продолжает отправлять лук;
Продолжительность блокировки времени.
Большая часть этих данных поступает из сообщений «обновления канала», которые содержат информацию о плате за маршрутизацию, запросах на события и идентификаторах платежных каналов. Общая сумма, которую необходимо переслать, представляет собой сумму суммы платежа плюс комиссия за обработку, взимаемая за каждый последующий переход; в то время как секретная стоимость платежа рассчитывается Диной и включается в платежный счет (сообщается луковичным сообщением каждому прыгать).
Алиса начинает с последнего узла Дины. Она включает в себя сумму пересылки, значение продолжительности временной блокировки, значение секрета платежа и сумму платежа в пакете. Обратите внимание, что ей не нужно добавлять идентификатор канала, потому что Дина является конечным узлом и не должна пересылать платеж другим.
На первый взгляд кажется излишним указывать сумму пересылки, потому что эта сумма совпадает с суммой платежа, однако при многопутевом платеже сумма платежа будет отправлена по нескольким путям, и тогда два значения не будут совпадать.
В полезной нагрузке Чана Алиса добавляет идентификаторы каналов Чана и Дины. Она также добавила суммы переадресации и значения временной блокировки. Наконец, Алиса создает полезную нагрузку для Боба. Чан взимает 100 сатоши за платеж через канал между ней и Диной, поэтому Алиса должна сказать Бобу, что пересылаемая сумма — это платеж плюс комиссия за обработку. Согласно сообщению об обновлении канала Чана, значение временной блокировки также было увеличено на 20 (в блоках). Наконец, Алиса также учитывает комиссию Боба за обработку и требования к временной блокировке и выдает ему HTLC с длиной временной блокировки 700040 и значением 100200 сатоши.
Общее секретное значение и генерация ключа
Затем Алиса подготавливает луковицу, генерируя общий секрет для каждого прыжка (включая конечный узел). Это значение общего секрета может быть сгенерировано Алисой и целевым переходом соответственно путем умножения ее собственного закрытого ключа на открытый ключ другой стороны.
Для луковой маршрутизации необходимо общее секретное значение, позволяющее Алисе и каждому переходу получить один и тот же ключ. Затем Алиса использует эти ключи для запутывания каждого слоя луковицы, а этот прыжок использует ключи для раскрытия запутанности.
Чтобы защитить конфиденциальность Алисы, она создает одноразовый сеансовый ключ для луковицы, а не использует собственный открытый ключ узла для получения значения общего секрета. Она использует этот сеансовый ключ для первого перехода, а затем для каждого последующего перехода Алиса детерминистически рандомизирует ключ, умножая последний ключ на ослепляющий коэффициент. Они используются для создания общего секретного ключа, который мы называем «эфемерными ключами».
Бобу, Чану и Дине необходимо получить такое же секретное значение, что и Алисе, поэтому им необходимо знать эфемерный ключ для использования в сеансе. Алиса помещает только первый ключ в луковицу, чтобы уменьшить размер сообщения. Каждый переход вычисляет следующий эфемерный ключ и внедряет его в луковицу для следующего узла. Каждый переход может использовать свой собственный открытый ключ и значение общего секрета для вычисления коэффициента ослепления, используемого Алисой для определения следующего эфемерного ключа.
Как упоминалось ранее, значение общего секрета будет использоваться для генерации некоторых ключей, и Алиса и соответствующий переход могут использовать эти ключи для выполнения некоторых операций над луковицей. Давайте посмотрим, что делает каждая клавиша.
Ключ Ро
Ключ Rho используется Алисой для шифрования слоя лука; это запутывает содержимое полезной нагрузки, чтобы посторонние не могли его расшифровать. Только владелец ключа ро может расшифровать полезную нагрузку. Вот что должен сделать узел, который получает луковицу: использовать общее секретное значение с Алисой для получения ро-ключа, затем расшифровать луковицу и прочитать ее содержимое.
Маки
Алиса использует клавишу mu для создания контрольной суммы для каждой полезной нагрузки. Она также передает контрольную сумму прыжку, который получает луковицу. Этот прыжок, в свою очередь, использует ключ mu для генерации контрольной суммы полученной полезной нагрузки, проверяя, совпадает ли она с той, которую дала Алиса. Это необходимо для проверки целостности полезной нагрузки, чтобы убедиться, что она не была подделана.
Клавиша пэда
Этот ключ используется только Алисой для генерации случайных «мусорных» данных. Эти данные также являются частью луковицы, и они не имеют ничего общего с длиной платежного пути, сколько переходов прошла луковица, и они сохраняют луковицу всегда одинакового размера, даже если часть ее содержимого неактуальна. Вот как луковая маршрутизация скрывает длину пути, фактически защищая конфиденциальность отправителя и получателя.
Ключ
Этот ключ также используется для проверки целостности данных, содержащихся в луковице, но только в случае возврата ошибки. Да, это называется "гм", потому что "мю" пишется задом наперёд. В случае ошибки платежа переход, обнаруживший ошибку, будет использовать ключ um для создания контрольной суммы, а когда предыдущий узел получит отчет об ошибке, он также будет использовать ключ um для проверки целостности сообщения.
Инкапсуляция лукового слоя
Окончательная луковая обертка выглядит так:
Алиса теперь имеет полезную нагрузку для каждого прыжка и значение общего секрета для каждого прыжка. Давайте посмотрим, как Алиса преобразует эту информацию в окончательную луковицу. Она начинает с последнего узла и постепенно возвращается обратно.
Сначала она создает пустое поле длиной 1300 байт, что является общей длиной всех onion-полезных данных. Затем она использует клавишу pad для создания случайной строки длиной 1300 байт, что является мусором, бесполезным для любого прыжка. Этот шаг делается для того, чтобы каждый слой луковицы выглядел одинаково, поэтому вы не можете видеть ни общую длину пути (сколько переходов), ни кто является отправителем, а кто получателем.
Затем она создает контрольную сумму полезной нагрузки, которую необходимо использовать, и помещает ее в конец полезной нагрузки. В сообщении для конечного узла контрольная сумма равна 0, чтобы сообщить Дине, что она является конечным получателем этого лука. После добавления контрольной суммы в конец полезной нагрузки Алиса помещает полезную нагрузку (и контрольную сумму) в начало мусора, а часть всего сообщения, превышающую 1300 байт, удаляет, так что вся длина сообщения составляет 1300 байт.
Затем Алиса использует ключ rho для создания случайной строки байтов и применяет операцию исключающее ИЛИ (XOR) к полезной нагрузке onion, полученной на предыдущем шаге, чтобы получить запутанную полезную нагрузку. Исходный текст полезной нагрузки можно получить с помощью операции XOR этой случайной строки байтов над запутанным текстом (Примечание переводчика: другими словами, здесь XOR — это алгоритм симметричного шифрования, а случайная строка байтов — это ключ). Операция XOR сравнивает полезную нагрузку onion со случайной строкой байтов (генерируемой ключом rho) побитно, выводя 1, только если один из битов данных равен 1; это приводит к запутанной полезной нагрузке. Умная вещь в операции XOR заключается в том, что пока вы получаете правильную случайную строку байтов и запутанную полезную нагрузку, вам нужно только снова запустить операцию XOR с двумя, чтобы получить запутанную полезную нагрузку.
Поскольку узлы, получающие луковицу, могут получить один и тот же ключ ро, они могут генерировать ту же случайную строку байтов, что и Алиса. Вот как каждый узел на этом пути может распутать путаницу и прочитать содержимое.
После подготовки луковицы путаницы для одного прыжка Алиса повторяет те же шаги для следующего узла. Ключевое отличие состоит в том, что после того, как лук Дины готов, ей больше не нужно генерировать мусор. Она просто добавляет запутанную луковицу из предыдущего шага после полезной нагрузки и контрольной суммы и обрезает все, что превышает 1300 байт.
Наконец, Алиса берет последнюю запутанную луковицу и добавляет контрольную сумму, чтобы Боб мог проверить целостность луковицы. Затем Алиса добавляет открытый ключ сеанса, чтобы Боб мог использовать этот открытый ключ для вычисления значения общего секрета. Наконец, она также добавляет байт, представляющий версию, сообщая другим узлам, как интерпретировать содержащиеся в ней данные. Для версии, описанной БОЛТОМ № 4, байт версии должен быть равен 0.
вперед лук
Чтобы отправить этот луковый пакет, отправитель создает сообщение update_add_htlc со следующими полями:
Идентификатор канала: конкретный канал, к которому относится это сообщение.
ID: идентификатор этого HTLC.
Сумма: значение этого HTLC.
Хэш платежа: создается получателем платежа.
Срок действия: этот HTLC истечет после определенного блока.
Луковая посылка: луковица, созданная для этого платежа, о чем говорилось выше.
Дополнительные данные: используется для указания дополнительных данных.
После подготовки сообщения Алиса отправляет сообщение Бобу. Получив сообщение, Боб может приступить к расшифровке собственной луковицы. Сначала он получает сеансовый ключ из луковой оболочки и использует его для получения значения общего секрета с Алисой.
Вооружившись значением общего секрета, Боб генерирует ключ mu для проверки контрольной суммы полезной нагрузки, встроенной в пакет onion. Если полезная нагрузка не была изменена, контрольные суммы должны совпадать.
Чтобы другие узлы на пути не знали, какова длина пути, Боб добавляет в луковый пакет 1300-байтовое поле, заполненное нулями. Затем Боб генерирует случайную строку байтов длиной 2600 байтов из ключа rho. Боб использует эту случайную строку байтов для XOR полезной нагрузки onion, заполненной нулями.
Помните, как я рассказывал вам о путанице луковых нагрузок? Используйте обфускированные полезные данные onion в качестве входных данных и запустите операцию «XOR» с той же строкой байтов, чтобы получить полезные данные onion до обфускации. Поскольку Алиса и Боб используют одно и то же значение общего секрета, генерируя один и тот же ключ ро, Боб может распутать. У этого есть дополнительный бонус, который превращает 1300-байтовые символы заполнения в случайные байты.
Незапутанная полезная нагрузка Боба включает в себя данные полезной нагрузки для его прыжка вместе с отпечатком пальца. Боб сохраняет этот отпечаток пальца, чтобы добавить его в посылку с луком, которую он отправляет Чану. После того, как Боб отделит свою полезную нагрузку от луковичного сообщения, он преобразует луковичный пакет обратно в исходный размер 1300 байт и рандомизирует свой сеансовый ключ, как это сделала Алиса. Наконец, Боб добавляет байт версии, сеансовый ключ и отпечаток пальца, который он намеревается поместить в полезную нагрузку onion, и пересылает пакет onion Чану через сообщение update_add_htlc.
Этот процесс будет продолжаться до тех пор, пока сообщение не будет отправлено на последний узел, Дину. Когда Дина получает сообщение update_add_htlc, она может ввести хеш-значение сгенерированного ею секретного значения, что означает, что этот HTLC предназначен для нее. Так что Дине просто нужно проверить отпечатки пальцев, распутать луковичные сообщения и раскрыть свою полезную нагрузку.
Поиск неисправностей
Мы говорим об истории успеха, случае, когда все шло по плану, но если что-то пойдет не так по пути, вам придется отправить сообщение обратно, чтобы уведомить все узлы о том, что что-то пошло не так. Этот процесс похож на обычную луковую маршрутизацию. Обнаружение неисправного узла требует извлечения ключа um из общего секретного значения, использования его для генерации случайной строки байтов и использования операции XOR для запутывания возвращенной луковой посылки.
Узел, обнаруживший ошибку, отправит сообщение обратно предыдущему узлу на пути оплаты. Каждый переход использует ключ um и ключ ammag для выполнения одной и той же операции, пока отправитель не получит пакет. Наконец, отправитель использует ключ ammag и ключ um для раскрытия и проверки пакета.
Ошибки могут быть вызваны луковыми пакетами, узлами или каналами. Если вы часто используете Lightning Network, вы могли столкнуться с такими ошибками, как «канал недоступен» или «недостаточно сборов».
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
«Луковая маршрутизация» в Lightning Network и как она работает
Добавить Автора
Компьютеры в сети взаимодействуют друг с другом в соответствии с протоколами. Здесь «протокол» относится к системе правил, определяющих, как сообщения должны передаваться и интерпретироваться. Часть передачи платежных сообщений сетевого протокола Lightning описана в BOLT#4, также известном как «Протокол луковой маршрутизации (Протокол луковой маршрутизации)».
Onion Routing — это технология, которая предшествовала Lightning Network на 25 лет. Он также используется в Tor, откуда и произошло название «Tor» («Луковый маршрутизатор»). Lightning Network использует слегка измененную версию, называемую «луковой маршрутизацией на основе источника», сокращенно «SPHINX». В этой статье мы поговорим о том, как работает луковая маршрутизация.
Зачем использовать луковую маршрутизацию?
В мире существует множество различных коммуникационных протоколов, но поскольку Lightning Network является платежной сетью, имеет смысл выбрать такой протокол, который раскрывает как можно меньше информации о пересылаемом платеже.
Если бы Lightning Network использовала тот же протокол, что и Интернет, каждый посредник знал бы, кто был отправителем платежа, кто был получателем и кто другие посредники на пути. Луковая маршрутизация — хороший выбор, поскольку ее характеристики гарантируют наличие промежуточных узлов:
Обзор луковой маршрутизации
Давайте используем посылку в качестве аналогии, чтобы объяснить, как работает луковая маршрутизация.
Предположим, Алиса хочет заплатить Дине. Во-первых, Алисе нужно найти допустимый путь для своего платежа:
Алиса→Боб→Чан→Дина
Затем она строит «луковицу». Она начинается с Дины (с конца пути). Она кладет секретное сообщение (содержимое платежа) в пакет, отправленный Дине, и запирает его ключом, известным только ей и Дине. Теперь она кладет этот пакет в другой пакет для отправки Чану и запирает пакет для Чана ключом, известным только ей и Чану. Правильно и так далее.
Алиса отправляет последнюю луковицу (пакет) первому посреднику на пути, Бобу. Боб открывает свою посылку своим ключом и видит, что следующая посылка предназначена для Чана. Поэтому он переслал посылку Чану. То же самое касается Чана: распаковав посылку, он переслал ее Дине. Наконец Дина открыла свой пакет и нашла внутри платежное сообщение.
В луковой маршрутизации посредники, такие как Боб и Чан, не знают ни содержания сообщения Дине, ни длины всего платежного пути. Единственное, что они знают, это то, кто отправил им посылку и кто получит ее следующим. Это гарантирует конфиденциальность сообщения и конфиденциальность пути. Каждый посредник может касаться только специально созданного для ТА слоя сообщений.
В луковичной маршрутизации Lightning Network на основе источника отправитель выбирает путь платежа и создает полный лук для этого пути, который можно рассматривать как дыру в конфиденциальности (Примечание переводчика: сетевое местоположение получателя должно быть доступно отправителю). Другие схемы маршрутизации, такие как «слепая маршрутизация» (китайский перевод), решают эту проблему, запутывая часть пути платежа к отправителю. Однако в этой статье мы сосредоточимся исключительно на SPHINX.
Соберите лук
Теперь давайте взглянем на спецификацию луковой маршрутизации. В начале нам нужно определить следующие вещи:
Построить скачковую нагрузку
Как только Алиса выбрала путь платежа, она получает информацию для каждого платежного канала из протокола сплетен, чтобы создать полезную нагрузку для каждого прыжка, по существу сообщая каждому прыжку, как создать HTLC для пересылаемого платежа (контракт хеш-таймлока).
Чтобы установить правильный HTLC, каждый переход должен:
Большая часть этих данных поступает из сообщений «обновления канала», которые содержат информацию о плате за маршрутизацию, запросах на события и идентификаторах платежных каналов. Общая сумма, которую необходимо переслать, представляет собой сумму суммы платежа плюс комиссия за обработку, взимаемая за каждый последующий переход; в то время как секретная стоимость платежа рассчитывается Диной и включается в платежный счет (сообщается луковичным сообщением каждому прыгать).
Алиса начинает с последнего узла Дины. Она включает в себя сумму пересылки, значение продолжительности временной блокировки, значение секрета платежа и сумму платежа в пакете. Обратите внимание, что ей не нужно добавлять идентификатор канала, потому что Дина является конечным узлом и не должна пересылать платеж другим.
На первый взгляд кажется излишним указывать сумму пересылки, потому что эта сумма совпадает с суммой платежа, однако при многопутевом платеже сумма платежа будет отправлена по нескольким путям, и тогда два значения не будут совпадать.
В полезной нагрузке Чана Алиса добавляет идентификаторы каналов Чана и Дины. Она также добавила суммы переадресации и значения временной блокировки. Наконец, Алиса создает полезную нагрузку для Боба. Чан взимает 100 сатоши за платеж через канал между ней и Диной, поэтому Алиса должна сказать Бобу, что пересылаемая сумма — это платеж плюс комиссия за обработку. Согласно сообщению об обновлении канала Чана, значение временной блокировки также было увеличено на 20 (в блоках). Наконец, Алиса также учитывает комиссию Боба за обработку и требования к временной блокировке и выдает ему HTLC с длиной временной блокировки 700040 и значением 100200 сатоши.
Общее секретное значение и генерация ключа
Затем Алиса подготавливает луковицу, генерируя общий секрет для каждого прыжка (включая конечный узел). Это значение общего секрета может быть сгенерировано Алисой и целевым переходом соответственно путем умножения ее собственного закрытого ключа на открытый ключ другой стороны.
Для луковой маршрутизации необходимо общее секретное значение, позволяющее Алисе и каждому переходу получить один и тот же ключ. Затем Алиса использует эти ключи для запутывания каждого слоя луковицы, а этот прыжок использует ключи для раскрытия запутанности.
Чтобы защитить конфиденциальность Алисы, она создает одноразовый сеансовый ключ для луковицы, а не использует собственный открытый ключ узла для получения значения общего секрета. Она использует этот сеансовый ключ для первого перехода, а затем для каждого последующего перехода Алиса детерминистически рандомизирует ключ, умножая последний ключ на ослепляющий коэффициент. Они используются для создания общего секретного ключа, который мы называем «эфемерными ключами».
Бобу, Чану и Дине необходимо получить такое же секретное значение, что и Алисе, поэтому им необходимо знать эфемерный ключ для использования в сеансе. Алиса помещает только первый ключ в луковицу, чтобы уменьшить размер сообщения. Каждый переход вычисляет следующий эфемерный ключ и внедряет его в луковицу для следующего узла. Каждый переход может использовать свой собственный открытый ключ и значение общего секрета для вычисления коэффициента ослепления, используемого Алисой для определения следующего эфемерного ключа.
Как упоминалось ранее, значение общего секрета будет использоваться для генерации некоторых ключей, и Алиса и соответствующий переход могут использовать эти ключи для выполнения некоторых операций над луковицей. Давайте посмотрим, что делает каждая клавиша.
Ключ Ро
Ключ Rho используется Алисой для шифрования слоя лука; это запутывает содержимое полезной нагрузки, чтобы посторонние не могли его расшифровать. Только владелец ключа ро может расшифровать полезную нагрузку. Вот что должен сделать узел, который получает луковицу: использовать общее секретное значение с Алисой для получения ро-ключа, затем расшифровать луковицу и прочитать ее содержимое.
Маки
Алиса использует клавишу mu для создания контрольной суммы для каждой полезной нагрузки. Она также передает контрольную сумму прыжку, который получает луковицу. Этот прыжок, в свою очередь, использует ключ mu для генерации контрольной суммы полученной полезной нагрузки, проверяя, совпадает ли она с той, которую дала Алиса. Это необходимо для проверки целостности полезной нагрузки, чтобы убедиться, что она не была подделана.
Клавиша пэда
Этот ключ используется только Алисой для генерации случайных «мусорных» данных. Эти данные также являются частью луковицы, и они не имеют ничего общего с длиной платежного пути, сколько переходов прошла луковица, и они сохраняют луковицу всегда одинакового размера, даже если часть ее содержимого неактуальна. Вот как луковая маршрутизация скрывает длину пути, фактически защищая конфиденциальность отправителя и получателя.
Ключ
Этот ключ также используется для проверки целостности данных, содержащихся в луковице, но только в случае возврата ошибки. Да, это называется "гм", потому что "мю" пишется задом наперёд. В случае ошибки платежа переход, обнаруживший ошибку, будет использовать ключ um для создания контрольной суммы, а когда предыдущий узел получит отчет об ошибке, он также будет использовать ключ um для проверки целостности сообщения.
Инкапсуляция лукового слоя
Окончательная луковая обертка выглядит так:
Алиса теперь имеет полезную нагрузку для каждого прыжка и значение общего секрета для каждого прыжка. Давайте посмотрим, как Алиса преобразует эту информацию в окончательную луковицу. Она начинает с последнего узла и постепенно возвращается обратно.
Сначала она создает пустое поле длиной 1300 байт, что является общей длиной всех onion-полезных данных. Затем она использует клавишу pad для создания случайной строки длиной 1300 байт, что является мусором, бесполезным для любого прыжка. Этот шаг делается для того, чтобы каждый слой луковицы выглядел одинаково, поэтому вы не можете видеть ни общую длину пути (сколько переходов), ни кто является отправителем, а кто получателем.
Затем она создает контрольную сумму полезной нагрузки, которую необходимо использовать, и помещает ее в конец полезной нагрузки. В сообщении для конечного узла контрольная сумма равна 0, чтобы сообщить Дине, что она является конечным получателем этого лука. После добавления контрольной суммы в конец полезной нагрузки Алиса помещает полезную нагрузку (и контрольную сумму) в начало мусора, а часть всего сообщения, превышающую 1300 байт, удаляет, так что вся длина сообщения составляет 1300 байт.
Затем Алиса использует ключ rho для создания случайной строки байтов и применяет операцию исключающее ИЛИ (XOR) к полезной нагрузке onion, полученной на предыдущем шаге, чтобы получить запутанную полезную нагрузку. Исходный текст полезной нагрузки можно получить с помощью операции XOR этой случайной строки байтов над запутанным текстом (Примечание переводчика: другими словами, здесь XOR — это алгоритм симметричного шифрования, а случайная строка байтов — это ключ). Операция XOR сравнивает полезную нагрузку onion со случайной строкой байтов (генерируемой ключом rho) побитно, выводя 1, только если один из битов данных равен 1; это приводит к запутанной полезной нагрузке. Умная вещь в операции XOR заключается в том, что пока вы получаете правильную случайную строку байтов и запутанную полезную нагрузку, вам нужно только снова запустить операцию XOR с двумя, чтобы получить запутанную полезную нагрузку.
Поскольку узлы, получающие луковицу, могут получить один и тот же ключ ро, они могут генерировать ту же случайную строку байтов, что и Алиса. Вот как каждый узел на этом пути может распутать путаницу и прочитать содержимое.
После подготовки луковицы путаницы для одного прыжка Алиса повторяет те же шаги для следующего узла. Ключевое отличие состоит в том, что после того, как лук Дины готов, ей больше не нужно генерировать мусор. Она просто добавляет запутанную луковицу из предыдущего шага после полезной нагрузки и контрольной суммы и обрезает все, что превышает 1300 байт.
Наконец, Алиса берет последнюю запутанную луковицу и добавляет контрольную сумму, чтобы Боб мог проверить целостность луковицы. Затем Алиса добавляет открытый ключ сеанса, чтобы Боб мог использовать этот открытый ключ для вычисления значения общего секрета. Наконец, она также добавляет байт, представляющий версию, сообщая другим узлам, как интерпретировать содержащиеся в ней данные. Для версии, описанной БОЛТОМ № 4, байт версии должен быть равен 0.
вперед лук
Чтобы отправить этот луковый пакет, отправитель создает сообщение update_add_htlc со следующими полями:
После подготовки сообщения Алиса отправляет сообщение Бобу. Получив сообщение, Боб может приступить к расшифровке собственной луковицы. Сначала он получает сеансовый ключ из луковой оболочки и использует его для получения значения общего секрета с Алисой.
Вооружившись значением общего секрета, Боб генерирует ключ mu для проверки контрольной суммы полезной нагрузки, встроенной в пакет onion. Если полезная нагрузка не была изменена, контрольные суммы должны совпадать.
Чтобы другие узлы на пути не знали, какова длина пути, Боб добавляет в луковый пакет 1300-байтовое поле, заполненное нулями. Затем Боб генерирует случайную строку байтов длиной 2600 байтов из ключа rho. Боб использует эту случайную строку байтов для XOR полезной нагрузки onion, заполненной нулями.
Помните, как я рассказывал вам о путанице луковых нагрузок? Используйте обфускированные полезные данные onion в качестве входных данных и запустите операцию «XOR» с той же строкой байтов, чтобы получить полезные данные onion до обфускации. Поскольку Алиса и Боб используют одно и то же значение общего секрета, генерируя один и тот же ключ ро, Боб может распутать. У этого есть дополнительный бонус, который превращает 1300-байтовые символы заполнения в случайные байты.
Незапутанная полезная нагрузка Боба включает в себя данные полезной нагрузки для его прыжка вместе с отпечатком пальца. Боб сохраняет этот отпечаток пальца, чтобы добавить его в посылку с луком, которую он отправляет Чану. После того, как Боб отделит свою полезную нагрузку от луковичного сообщения, он преобразует луковичный пакет обратно в исходный размер 1300 байт и рандомизирует свой сеансовый ключ, как это сделала Алиса. Наконец, Боб добавляет байт версии, сеансовый ключ и отпечаток пальца, который он намеревается поместить в полезную нагрузку onion, и пересылает пакет onion Чану через сообщение update_add_htlc.
Этот процесс будет продолжаться до тех пор, пока сообщение не будет отправлено на последний узел, Дину. Когда Дина получает сообщение update_add_htlc, она может ввести хеш-значение сгенерированного ею секретного значения, что означает, что этот HTLC предназначен для нее. Так что Дине просто нужно проверить отпечатки пальцев, распутать луковичные сообщения и раскрыть свою полезную нагрузку.
Поиск неисправностей
Мы говорим об истории успеха, случае, когда все шло по плану, но если что-то пойдет не так по пути, вам придется отправить сообщение обратно, чтобы уведомить все узлы о том, что что-то пошло не так. Этот процесс похож на обычную луковую маршрутизацию. Обнаружение неисправного узла требует извлечения ключа um из общего секретного значения, использования его для генерации случайной строки байтов и использования операции XOR для запутывания возвращенной луковой посылки.
Узел, обнаруживший ошибку, отправит сообщение обратно предыдущему узлу на пути оплаты. Каждый переход использует ключ um и ключ ammag для выполнения одной и той же операции, пока отправитель не получит пакет. Наконец, отправитель использует ключ ammag и ключ um для раскрытия и проверки пакета.
Ошибки могут быть вызваны луковыми пакетами, узлами или каналами. Если вы часто используете Lightning Network, вы могли столкнуться с такими ошибками, как «канал недоступен» или «недостаточно сборов».