René Pickhardt inició recientemente una hilo analiza las diferencias entre los canales de pago bipartitos y multipartitos (más de dos participantes) en relación con su trabajo de investigación sobre la confiabilidad de los pagos en Lightning Network. Expresa un creciente escepticismo sobre la viabilidad de esa dirección para el desarrollo.
La idea de alto nivel de por qué las fábricas de canales mejoran la confiabilidad de los pagos se reduce a la asignación de liquidez. En una red de canales de sólo dos partes, los usuarios tienen que tomar decisiones de suma cero sobre dónde asignar su liquidez. Esto tiene un efecto sistémico en la tasa general de éxito de los pagos en toda la red; si las personas ponen su liquidez en algún lugar donde no es necesario para procesar los pagos en lugar de donde está, los pagos fallarán a medida que se agote la liquidez en los lugares que las personas necesitan ( hasta que se reequilibre). Esta dinámica es simplemente una de las limitaciones de diseño de Lightning Network conocidas desde el principio, y por qué investigaciones como la de René son increíblemente importantes para hacer que el protocolo/red funcione a largo plazo.
En un modelo de canales multipartidistas, los usuarios pueden asignar liquidez en grandes grupos y simplemente “subasignarla” fuera de la cadena donde tenga sentido en ese momento. Esto significa que incluso si un operador de nodo ha tomado una mala decisión sobre a qué persona asignar liquidez, siempre que esa persona esté en el mismo canal multipartito con personas que serían un buen par, puede reasignar esa liquidez mal colocada de un al otro fuera de la cadena sin incurrir en costos dentro de la cadena.
Esto funciona porque el concepto de un canal multipartidista consiste esencialmente en que todos los miembros del grupo apilen canales bipartidistas convencionales encima del multipartidista. Al actualizar el canal multipartito en la raíz, los dos canales superiores se pueden modificar, abrir, cerrar, etc. mientras permanecen fuera de la cadena. El problema que plantea René es el coste de entrar en cadena cuando la gente no coopera.
Toda la lógica de Lightning se basa en la idea de que si su contraparte de canal único deja de cooperar o responder, puede simplemente enviar transacciones en cadena para imponer el control sobre sus fondos. Cuando tienes un canal multipartito, cada “nivel” en la pila de canales agrega más transacciones que deben enviarse a la cadena de bloques para hacer cumplir el estado actual, lo que significa que en un entorno de tarifas altas los canales multipartidistas serán más caros que dos. canales del partido para hacer cumplir la cadena.
Estas son compensaciones fundamentales a considerar cuando se comparan estos sistemas entre sí, pero creo que centrarse exclusivamente en la huella dentro de la cadena ignora el punto más importante con respecto a los sistemas fuera de la cadena: se trata de incentivar a los participantes a no ir en cadena.
Estructurar adecuadamente un canal multipartito, es decir, cómo organizar los canales apilados en la parte superior, puede permitirle agrupar grupos de personas en subsecciones que tienen una reputación de alta confiabilidad o que confían entre sí. Esto permitiría a las personas de estos subgrupos reorganizar la liquidez dentro de ese subgrupo incluso si las personas fuera de él no responden temporalmente o se desconectan debido a problemas técnicos. El costo dentro de la cadena de hacer cumplir las cosas, si bien es importante, es algo tangencial al objetivo central de diseño de un sistema fuera de la cadena: dar a las personas una razón para permanecer fuera de la cadena y cooperar, y eliminar razones para que las personas no cooperen y fuercen. cosas en cadena.
Es importante no perder de vista ese aspecto central del diseño de estos sistemas al considerar cómo será su futuro.