Глоссарий / Lightning и layer 2
Keysend
- Что такое Keysend?
- Keysend отправляет платеж в Lightning без инвойса: плательщик генерирует прообраз из 32 байт, хеширует его в хеш платежа и передает секрет внутри луковичного пакета.
Keysend переворачивает обычный порядок в Lightning, где секрет выбирает получатель и публикует его хеш в инвойсе. Секрет отправителя едет в пользовательской записи TLV 5482373484, четном числе, и по BOLT 1 узел, который не знает keysend, обязан такую запись отклонить, а не проигнорировать. Можно заплатить на голый публичный ключ узла без единого обмена данными, но при этом вы теряете криптографическую квитанцию, которую оставил бы инвойс.
Как это работает
Keysend опирается на более строгую половину одного правила BOLT 1: читающий отбрасывает неизвестную запись TLV с нечетным типом и продолжает, но при неизвестной четной обязан провалить весь поток.
Идентификаторы типов ниже 2^16 зарезервированы за BOLT, а все от 2^16 и выше свободно для пользовательских записей, и BOLT 1 велит выбирать нечетное число, когда обычные узлы должны проигнорировать данные, и четное, когда они должны их отклонить. bLIP-3 фиксирует, что 5482373484 был выбран наугад в исходной реализации lnd, а заканчивается он на четверку, поэтому keysend оказался на отклоняющей стороне. Вот почему ему нужен бит функции: готовые узлы объявляют биты 54/55 с именем keysend, который зависит от var_onion_optin, и bLIP-3 говорит, что отправителям следует искать этот бит, а не отправлять вслепую и смотреть, как платеж проваливается.
Задача отправителя, изложенная в bLIP-3, коротка. Сгенерируйте криптографически стойкое случайное значение в 32 байта, поместите его в эту запись и установите payment_hash в update_add_htlc равным его SHA-256. Никогда не используйте прообраз повторно и никогда не используйте прообраз из инвойса, который вы уже оплатили. Пакет маскируется на каждом узле маршрута, поэтому промежуточный узел восстанавливает только адрес следующего, и никто посередине записи не видит. Финальный узел хеширует найденное значение, сверяет его с хешем, который ему велели принять, и завершает расчет.
Отказ намеренно тихий. У BOLT 4 есть буквальный ответ на полезную нагрузку, которую узел не понял, PERM|22 invalid_onion_payload, и он может даже назвать вызвавший его тип TLV. bLIP-3 просит получателей возвращать вместо него PERM|15 incorrect_or_unknown_payment_details, так что отклоненный keysend неотличим от хеша платежа, который узел никогда не выдавал.
Где это встречается
Keysend представляет собой инфраструктуру, на которой держатся бусты в подкастах.
bLIP-10 определяет вторую запись, типа 7629169, изначально выбранного Breez, которая несет плоский JSON-объект, прикрепленный к платежу keysend: название подкаста, выпуск, ts для позиции воспроизведения в секундах, action со значением boost или stream и необязательное message, которое и делает из платежа бустаграм. Поминутный стриминг устанавливает seconds_back в 60. Эта запись нечетная, поэтому bLIP-10 не беспокоится об обратной совместимости: хост, который игнорирует метаданные, все равно получает сатоши. Она существует потому, что сам по себе keysend ничего не сообщает получателю, и приложению приходится называть передачу самостоятельно.
Тот же пробел держит keysend в стороне от покупки. Вывод с биржи либо выдает вам инвойс, либо требует его от вас, потому что платформа должна привязать платеж к вашему счету, и это слово не встречается ни в одном из 63 обзоров бирж и ни в одном из 41 обзора кошельков на этом сайте. bLIP-3 честно называет цену: он ожидает, что keysend уступит место лучше спроектированному спонтанному платежу, называет offers и AMP и перечисляет, чем вы тем временем жертвуете, доказательством платежа и любым правом получателя влиять на итоговый срок CLTV.
Keysend vs Lightning-адрес
Keysend и Lightning-адрес оба позволяют заплатить тому, кто ни разу не выдал вам инвойс, и только один из них действительно обходится без инвойса. Ввод user@example.com отправляет ваш кошелек на HTTPS-запрос, который возвращает свежий инвойс BOLT11, так что прообраз по-прежнему выбрал получатель, и в итоге у вас на руках квитанция, подкрепленная его подписью. Keysend не требует ни веб-запроса, ни сервера, только публичный ключ узла в 33 байта и маршрут к нему, и после него вам нечем доказать платеж, потому что секрет изначально был ваш. Если вам когда-либо может понадобиться показать, что вы заплатили, берите инвойс.