¿Cómo funcionan los "observadores de terceros sin confianza" en Lightning Network?

El punto principal con LN es la necesidad de monitorear la cadena de bloques. El motivo de esto es detectar si la contraparte se porta mal al publicar un estado de canal antiguo en la cadena de bloques. Para un nodo que se ejecuta en un servidor, eso no es un gran problema ya que siempre está en línea, pero los nodos móviles pueden desconectarse durante días, entonces, ¿cómo lidiamos con este problema?

La necesidad de monitorear la cadena de bloques en realidad solo existe si el canal se usa en ambas direcciones: si solo está pagando, cualquier transacción de compromiso desactualizada estará más a su favor que la actual, ¡así que realmente no hay nada que hacer!

Pero en el caso de los canales de pago bidireccionales, esto parece ser resuelto por "observadores de terceros sin confianza". Como no puedo encontrar mucha literatura en Internet sobre ellos, me preguntaba, ¿cómo funcionan y cómo son exactamente confiables? De hecho, ¿cómo confía realmente en que alguien va a publicar en su nombre y por qué? ¿Existen mecanismos de incentivos para que esto sea completamente sin confianza?

Aquí hay algo que encontré en línea: diyhpl.us/wiki/transcripts/scalingbitcoin/milan/…
Corríjame si me equivoco, pero incluso si el canal es unidireccional, ¿no tiene la contraparte un incentivo para monitorear la cadena de bloques en busca de txs de compromiso anteriores? Entonces también se necesitan torres de vigilancia en ese caso.
@PaulRBerg no, para los canales de pago unidireccionales esto no sería necesario. Imagine un canal unidireccional de Alice a Bob. El último estado siempre es el más lucrativo para Bob, por lo que no haría trampa porque no tiene el incentivo para hacerlo. Lo sé, eso ya lo sabías y te importa más lo que pase al revés. Entonces, ¿por qué Alice no transmitiría un estado antiguo? Simple: ella no puede. Mientras que Alice envía tx tras tx a Bob, gastando su multisig 2 de 2, ella siempre firma las transacciones, mientras que Bob en realidad no tiene que firmar ni enviar la transacción a ninguna parte.
La primera vez que Bob necesitaría firmar y transmitir la transacción es cuando quiere cerrar el canal.

Respuestas (2)

Supongo que cuando te refieres a "observadores de terceros" te refieres a torres de vigilancia. Estoy de acuerdo en que 'sin confianza' es probablemente una palabra ambigua en este contexto. En el momento de escribir este artículo, la única propuesta real con un protocolo que conozco es PISA , de Andrew Miller et al. PISA permite a los usuarios seleccionar un custodio que será incentivado en la publicación. Los usuarios pagan al custodio, y el custodio pierde fondos si no funciona (es decir, si el nodo de la contraparte logra publicar un estado anterior).

Por el momento, parece que Roger Wattenhofer también está trabajando en ello . Sin embargo, aún no han propuesto un protocolo. Su idea es incentivar a través de recompensas cuando los canales se 'guardan', en lugar de penalizar cuando una torre de vigilancia no se salva a tiempo.

Ambos lados tienen pros y contras.

  • La contra de la propuesta de Miller es que hay que elegir la atalaya, teniendo que confiar en ella. La contraparte podría tratar de sobornar a la torre de vigilancia, para que ambos ganen más que la penalización.

  • La propuesta de Wattenhofer no tiene este problema, ya que cualquiera en la red puede recuperar la recompensa, y así todos son la atalaya. El problema de esta propuesta es que existen incentivos para que las personas ataquen a otras personas e impidan que se publiquen.

Este es un trabajo en progreso. En cuanto a una autoproclamada torre de vigilancia sin confianza, ha habido alguna discusión en la lista de correo de ligthing-dev aquí y aquí , pero aún es un trabajo en progreso.

Las torres de vigilancia no son confiables, usted confía en ellas para monitorear la cadena de bloques en su nombre y transmitir una transacción de justicia en caso de que su parte remota (contraparte) transmita un estado revocado. Si la torre de vigilancia no hace esto, aún podría perder fondos. Como resultado, puede optar por utilizar varias torres de vigilancia para diversificar el riesgo de que una torre de vigilancia individual no recupere sus fondos.

La implementación temprana de torres de vigilancia en lnd 0.7 diferencia entre torres de vigilancia "altruistas" y de "recompensa básica", donde las últimas reciben una tarifa si transmiten una transacción de justicia. La parte remota podría sobornar a las torres de vigilancia si supiera qué torres de vigilancia estaban monitoreando la cadena en su nombre. Esta no es información pública ni necesita ser compartida con la parte remota, por lo que debería ser extremadamente difícil para la parte remota descubrir esta información.

Para obtener más información sobre la implementación actual de torres de vigilancia en lnd, aquí hay una presentación de Conner Fromknecht (Lightning Labs).

Vídeo: https://www.youtube.com/watch?v=2tyr05tLF4g

Transcripción: http://diyhpl.us/wiki/transcripts/boltathon/2019-04-06-conner-fromknecht-watchtowers/

Aquí hay un enlace al repositorio de GitHub de lnd watchtower: https://github.com/lightningnetwork/lnd/tree/master/watchtower

Las otras implementaciones de Lightning no incluyen la funcionalidad de torre de vigilancia a partir de la fecha de hoy (agosto de 2019), pero es probable que c-lightning siga un enfoque similar a lnd .