Как протокол сплетен анонсировал бы каналы с фабрики каналов?

Я только что слушал SLP59 с Кристианом Декером . В основном обсуждались канальные фабрики. Хотя построение многопартийных каналов и производных от них систем более высокого порядка (подканалов) кажется ясным и описывается в этой статье, мне интересно, как должен быть адаптирован протокол сплетен , чтобы люди могли объявлять о таких каналах?

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

Как будет выглядеть решение для протокола сплетен?

Я недостаточно знаю об этом, чтобы дать правильный ответ. Похоже, что семантику нужно short_channel_idбудет изменить, или что каналы должны быть частными, а это short_channel_idможет быть выдуманное значение, переданное в счете BOLT # 11. Связанный вопрос , на который вы ранее дали мне ответ.
Другая возможность, которая может быть возможна без изменений в сплетнях, заключается в том, что short_channel_idтранзакция ловушки может быть использована в счете-фактуре BOLT # 11, и получатель платежа может передать ее payment_hashпартнеру своего канала конфиденциально, так что, когда партнер получает входящий update_add_htlcс крючок short_channel_idи тому подобное payment_hash, они знают, для какого члена фабрики каналов он предназначен. Для исходящих платежей участники будут иметь channel_idтранзакцию, которая не зависит от того, находится ли она в определенном месте в блокчейне.
Другая (возможно, плохая) идея состоит в том, чтобы использовать short_channel_idтранзакцию хука, и когда участник фабрики получает сообщение update_add_htlc, он транслирует его всем членам фабрики. Все члены, кроме одного, должны возвращать update_fail_malformed_htlc, а один член должен возвращать либо , update_fulfull_htlcлибо update_fail_htlc. Узел мог собирать эти ответы и выяснять, для кого он предназначен.

Ответы (1)

Почти все останется по-прежнему. Если вы посмотрите на соответствующие сообщения, channel_announcementи channel_updateу нас есть следующие форматы:

channel_announcement

  1. тип: 256 ( channel_announcement)
  2. данные:
    • [ 64: node_signature_1]
    • [ 64: node_signature_2]
    • [ 64: bitcoin_signature_1]
    • [ 64: bitcoin_signature_2]
    • [ 2: len]
    • [ len: features]
    • [ 32: chain_hash]
    • [ 8: short_channel_id]
    • [ 33: node_id_1]
    • [ 33: node_id_2]
    • [ 33: bitcoin_key_1]
    • [ 33: bitcoin_key_2]

channel_update

  1. тип: 258 ( channel_update)
  2. данные:
    • [ 64: signature]
    • [ 32: chain_hash]
    • [ 8: short_channel_id]
    • [ 4: timestamp]
    • [ 1: message_flags]
    • [ 1: channel_flags]
    • [ 2: cltv_expiry_delta]
    • [ 8: htlc_minimum_msat]
    • [ 4: fee_base_msat]
    • [ 4: fee_proportional_millionths]
    • [ 8: htlc_maximum_msat] (option_channel_htlc_max)

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

В частности, short_channel_idвсе еще относится к единственному выходу, с которым был открыт офчейн-контракт, который также останется прежним.

channel_updateможет показаться немного более сложным, поскольку теперь есть n*(n-1)возможные направления (пары отправитель-получатель), по этому контракту можно пройти, тогда как в простом канале с двумя участниками у нас есть только 2 направления. Однако концепцию направления можно легко расширить, чтобы просто лексикографически ранжировать все пары отправитель-получатель и использовать индекс для идентификации пары.

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

пропускная способность канала не является частью ни одного из 2-х сообщений. Я полагаю, что в настоящее время мы знаем емкость начального канала из транзакций по финансированию в сети. но при создании подканалов нам необходимо учитывать мощности и следить за тем, чтобы общая мощность не превышала мощность транзакций финансирования.
Это ничем не отличается от текущей ситуации: вы знаете, что обе конечные точки канала LN имеют совокупный баланс, xесли вывод предназначен для xсатоши, но вы не знаете фактический текущий баланс. С многосторонними каналами вместо разделения совокупного баланса на двоих вы делите его nна nучастников, все остальное остается прежним :-)
Кажется, я говорил о другом. Когда многосторонний канал используется для фабрики каналов, производный от него подканал должен объявляться по протоколу сплетен (BOLT 07), этот канал должен иметь пропускную способность. как вы упомянули по аналогии с нашей текущей системой, это будет соответствовать балансу и быть частным. но канал, идущий с завода, не должен быть таким. в частности, если члены партии выпадают, а подканалы становятся видимыми в блокчейне, когда транслируется расчетный tx (как в случае eltoo) многостороннего канала.
В случае, если все участники все еще отвечают, распределение каналов внутри фабрики действительно не важно, поскольку вы можете заменить их по прихоти (на самом деле нет необходимости создавать каналы в первую очередь, просто перемещайте балансы между участниками). Когда участники перестают отвечать, вы переходите к цепочке, и внезапно у вас появляется ончейн-финансирование для обычного канала молнии :-)
Как протокол сплетен анонсировал бы каналы с фабрики каналов?
СпросиСетьПолитика конфиденциальности1y, 0v