Recientemente, Rene Pickhardt inició un hilo en el que se discutían las diferencias entre los canales de pago de dos partes y de múltiples partes (más de dos participantes) en relación con su trabajo de investigación sobre la confiabilidad de los pagos en la red Lightning. Pickhardt 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 solo dos canales, 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 colocan su liquidez en algún lugar donde no es necesaria para procesar los pagos en lugar de donde sí lo es, los pagos fallarán porque la liquidez en los lugares donde la gente la necesita se agota (hasta que se reequilibre). Esta dinámica es simplemente una de las limitaciones de diseño de la Red Lightning conocidas desde el principio, y por qué investigaciones como la de Rene son increíblemente importantes para hacer que el protocolo/la red funcionen a largo plazo.
En un modelo de canales multipartidistas, los usuarios pueden asignar liquidez a grandes grupos y simplemente “sub-asignarla” fuera de la cadena donde tenga sentido en el 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 multipartidista con personas que serían un buen par, puede reasignar esa liquidez mal ubicada de una a otra fuera de la cadena sin incurrir en costos dentro de la cadena.
Esto funciona porque el concepto de un canal multipartidista consiste básicamente en que todos los miembros del grupo apilen canales convencionales de dos partes sobre el canal multipartidista. Al actualizar el canal multipartidista en la raíz, los canales de dos partes de la parte superior se pueden modificar, abrir, cerrar, etc. mientras se permanece fuera de la cadena. El problema que plantea Rene es el costo de entrar en la cadena cuando las personas no cooperan.
Toda la lógica de Lightning se basa en la idea de que si su contraparte de un solo canal deja de cooperar o responder, usted puede simplemente enviar transacciones en cadena para hacer cumplir el control sobre sus fondos. Cuando tiene un canal multipartidista, 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 costosos que los canales de dos partes para hacer cumplir en cadena.
Estas son compensaciones fundamentales a tener en cuenta al comparar estos sistemas entre sí, pero creo que centrarse exclusivamente en la huella en 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 entrar en la cadena.
La estructuración adecuada de un canal multipartidista, es decir, la forma en que se organizan los canales apilados uno encima del otro, 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 que las personas en estos subgrupos aún reorganizaran 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 en cadena de hacer cumplir las cosas, si bien es importante, es algo tangencial al objetivo central de diseño de un sistema fuera de cadena: dar a las personas una razón para permanecer fuera de la cadena y cooperar, y eliminar las razones para que las personas no cooperen y fuercen las cosas dentro de la cadena.
Es importante no perder de vista ese aspecto central del diseño de estos sistemas al considerar cómo será su futuro.
Fuente: Revista Bitcoin
La publicación SHINOBI: LOS PROTOCOLOS FUERA DE LA CADENA SIEMPRE SERÁN UN ACTO DE EQUILIBRIO apareció primero en Crypto Breaking News.
