¿Por qué los paquetes Lightning incluyen ID de canal si el reenvío no es estricto?

Los paquetes cebolla en Lightning, como se describe en BOLT 4 , incluyen short_channel_idlos canales a lo largo de la ruta construida por el remitente. Pero de acuerdo con la misma especificación , el reenvío no es estricto , lo que significa que si el pago debe reenviarse desde un nodo intermediario X a un nodo intermediario Y, X es libre de elegir cualquiera de los canales entre él mismo e Y (un par de nodos pueden tener múltiples canales).

¿ No es short_channel_idexcesivo el 's en los paquetes de cebolla? ¿Podríamos simplemente especificar una lista de nodos a lo largo de la ruta sugerida y dejar que cada nodo elija el mejor canal para el siguiente?

Respuestas (1)

Supongo que esto tiene razones históricas. Los identificadores de canales cortos fueron los primeros en formato cebolla. C Lightning incluso hoy en día no admite múltiples canales entre 2 nodos. Lnd, por otro lado, sí. Es por eso que los desarrolladores de lnd comenzaron a cambiar el canal si existía un segundo canal con suficiente equilibrio entre los nodos. Más tarde se acordó agregar la declaración sobre el reenvío no estricto, al que hizo referencia, a la especificación.

Si bien trabajar con ID de nodo funcionaría, tiene algunos inconvenientes.

  1. Tendríamos que hacer un cambio retrocompatible al formato cebolla.
  2. Las identificaciones de canales cortos consumen menos espacio, creo que 8 bytes en comparación con 33 bytes de nodos (recuerde que las cebollas solo tienen 65 bytes por carga útil de salto)
  3. Las identificaciones de canales cortos se pueden verificar en el caso de canales privados. Puedo verificar la cadena de bloques para una transacción de financiación no gastada.