Durante los últimos días el debate acerca del alcance de Lightning Network como una solución capaz de proporcionar descentralización y escalabilidad en la red de Bitcoin ha estado llenando las redes de diversas opiniones.
Lightning Network es un proyecto de escalabilidad que propone la implementación de una red de canales de pago (cadenas paralelas) para realizar transacciones con bitcoin fuera de la cadena principal. El proyecto, desarrollado por Joseph Poon y Thaddeus Dryja, asegura que será posible realizar billones de micropagos en un solo día utilizando contratos inteligentes que aseguran la privacidad y la velocidad de cada transacción, y evitando el doble gasto.
Sin embargo, no todos dentro de la comunidad están de acuerdo con la premisa que asegura que los canales de pago de la red Lightning Network son un medio seguro para realizar transacciones peer-to-peer en una red distribuida. Jonald Fyookball argumenta que la red Lightning Network no puede ser una solución a la escalabilidad y la descentralización. ¿Por qué? Según Fyookkball, porque el código exige que los canales de pago estén centralizados en concentradores o hubs. Un modelo descentralizado no es necesariamente distribuido; que una red no posea un único centro no equivale a decir que múltiples centros no concentren, de alguna manera, los datos o los activos que los usuarios intercambian o almacenan.
Esto quiere decir que un canal de pago entre un punto A y un punto B, que debe tener una característica bidireccional, es necesario para la transferencia. Es decir, es necesaria una ruta para enlazar el pago a través de varias conexiones. En síntesis, el argumento de Fyookball sostiene que dado que es imposible que un criptoactivo esté en dos lugares a la vez, pero es necesario que una transacción dé varios «saltos» en la red para ir de un nodo a otro, la probabilidad de que el criptoactivo se encuentre en un canal de pago que asegure la ruta más eficiente de un punto de la red a otro, depende de cuántos canales estén disponibles tanto para remitente como para el destinatario.
La hipótesis de Fyookball afirma que si un remitente A quiere enviar un pago a un destinatario C a través de B, este tendría que tener fondos disponibles para completar la transacción: Bob está haciendo un pago a Carol, pero Alice es el remitente que envía criptoactivos a Bob, y no podría hacerlo hasta estar segura de que Bob ha pagado a Carol. Esto ocurre porque la red utiliza timelocks para eliminar el riesgo de custodia. De hecho, cada salto en la ruta debe tener los fondos disponibles para cada transacción. Técnicamente el remitente le pide prestado al mediador para poder pagar el destinatario. El problema es que en una red la carga de préstamos es muy grande.
Otro problema es que el enrutamiento de fondos interrumpe la distribución de los fondos y disminuye y degrada los canales de pago utilizables. Fyookball escribe:
Hay una gran disparidad de riqueza en cualquier población. Por lo tanto, el número de usuarios que pueden encaminar fondos para cualquier otro usuario aleatorio es sólo una fracción de la red. Y este problema se magnifica exponencialmente con un número creciente de saltos (…) Para llegar a cualquier persona en una red grande con una serie de conexiones de canal de ramificación, necesitas un gran número de canales o un gran número de saltos.
Ambos son un problema enorme. Un gran número de canales significa que los usuarios tienen que dividir sus fondos y no pueden hacer nada excepto pequeñas compras. Y un gran número de saltos significa que el dinero de todo el mundo estará atado a la ruta de dinero de todos los demás.
Jonald Fyookball
Analista
A modo de respuesta
Durante las pruebas que el equipo de Lightning Network realizó en la testnet, comprobaron que la red podía enrutar hasta 2000 transacciones por segundo. Este es un claro ejemplo de cómo se podrían sopesar las ideas anteriormente expuestas. Explorando en la respuesta de Fyookball, otro analista esgrimió que sin pruebas y observaciones, las hipótesis quedan en el aire.
Para Murch, la idea de una sola ruta de pago es extravagante: sugiere que una vez que se ha establecido una conexión cualquier parte de la ruta puede establecer un camino paralelo, lo cual abre la posibilidad de que pueden haber múltiples combinaciones, que en primer lugar anulan la hipótesis del reenvío como una forma de préstamo.
Los pagos multisalto de Lightning Network funcionan de tal manera que enviar un contrato al siguiente salto es equivalente a comprometerse con el contrato. Una vez que el destinatario recibe el contrato a través de la ruta, puede utilizar la firma adjunta para retirar el pago del último reenviador. Para obtener el pago, el destinatario negocia la firma al remitente que le permitirá activar el pago. «Como cada salto tiene que adelantar el pago antes de recibirlo, están intrínsecamente motivados para ejecutar el salto siguiente tan pronto sea posible», afirma Murch.
Esto sugiere que una vez realizados los dos saltos en los que un mediador está involucrado, en cuestión de milisegundos, los saldos quedarán liquidados, dejando los canales de pago disponibles para realizar nuevos saltos a través de los nodos de la red. Murch escribe:
Los canales sólo pueden avanzar hasta el límite de su propia capacidad. En conclusión una ruta sólo puede transferir la capacidad del eslabón más débil. Esto ocurre por qué Lightning Network se ha descrito como una solución de escalabilidad para micropagos y pagos de bajo valor. Como los pagos de bajo valor son menos competitivos sobre la cadena pero más frecuentes, esto es de hecho una gran propuesta. Los pagos más grandes son más económicos en la cadena de todos modos, ya que los honorarios representarán una porción relativamente más pequeña del valor transferido. Parece obvio que las solicitudes de pago de Lightning Network pronto se ampliarán para permitir que los pagos se dividan en múltiples rutas para mitigar las limitaciones de capacidad.
Jonald Fyookball
Analista
Diane Reynolds introdujo una variante en el debate. Utilizó un modelo simulado de 10 millones de usuarios de Lightning Network para describir lo que podría ocurrir más allá de las probabilidades y estar un poco más cerca de resolver la incógnita de si Lightning Network puede ser al mismo tiempo grande y descentralizada. El código fue escrito en lenguaje ocaml y utilizado para la simulación de 400.000 transacciones. No había distinción entre clientes, comerciantes y mediadores (hubs). Cada usuario tiene 14 canales y está financiado con 0,01 BTC. Hay además 11 diferentes políticas de tarifas distribuidas uniformemente entre los usuarios. Para cada pago se utilizan usuarios al azar: uno dirige el pago a través de un canal a otro de tres maneras diferentes posibles. El pago puede ser «grande» (entre 0,001 y 0,009 BTC; equivalente a pocos dólares), «mediano» (entre 0,00001 y 0,001 BTC; alrededor de 2 dólares o menos) o «micro» (menos de 0,00001 BTC; alrededor de 2 centavos o menos ).
El nodo asume que tiene 0,1% de probabilidades de no cooperar, un hecho que habían señalado tanto Fyookball como Murch y que introducen entre las variantes la posibilidad de que los canales de pagos defectuosos arrojen errores.
El primer problema consiste en que cada nodo disponga de suficientes canales de pago accesibles desde cualquier otro nodo (usuario) con suficiente redundancia para que no haya centralización.
Las pruebas con pocos usuarios mostraban poca redundancia, es decir, cada nodo dispone de dos canales y debe realizar al menos cinco saltos. La pruebas continuaron incrementando la cantidad de nodos que a su vez exigían más cantidad de saltos para hacer viable una conexión. En el momento culminante de la simulación, cada nodo (en una red de 10 millones de nodos) disponía de 14 canales. Dado que cada canal involucra a dos usuarios , había 70 millones de canales abiertos en la red. Si suponemos que cada usuario financia cada uno de los 14 canales con 0,01 bitcoin, esto requiere que el usuario bloquee 0,14 bitcoins en todos sus canales. Con 10 millones de usuarios se requieren 1,4 millones de bitcoins para participar en Lightning Network.
Otras situaciones más realistas podrían tener otros resultados, que darían más o menos buena conectividad dependiendo del número de saltos si la población de usuarios es, por ejemplo, menor. Lo interesante han sido los resultados de esta simulación: Después de 400.000 intentos de pago, la mitad de los usuarios (5.049.576) habían participado en el enrutamiento de un pago y el 10% de los canales (7.091.810) habían sido utilizados para encaminar un pago.
En algunos casos, las solicitudes de una ruta de tiempo de espera (con un límite de tiempo de 1 segundo), generaron una falla en el enrutamiento. Esto ocurrió en 4.500 casos (poco más del 1% de los 400.000 intentos de pago). Los pagos más pequeños hicieron más visibles los fallos. Probablemente porque los pagos más pequeños eran más restrictivos en qué rutas aceptar para evitar que los honorarios fueran demasiado altos. La tarifa máxima al solicitar una ruta siempre fue 0,00001BTC (10 bits) o el 5% del valor que se transfiere, lo que sea mayor.
Estos son los números específicos para los tres tipos de pagos:
133.865 «grandes» pagos (entre 0.001 y 0.009) fueron intentados. Sólo 8 de éstos fallaron. El número promedio de saltos para pagos exitosos fue de 18 y la mediana de los honorarios totales (para toda la ruta) fue de 3 bits (0.000003 BTC) o 0.06% del valor transferido.
Se intentaron 132.734 pagos medianos y 1031 (0,8%) de éstos fracasaron. Para los pagos exitosos, el número promedio de saltos fue de 18 y la mediana de los honorarios totales fue de 2 bits (0,000002 btc) o el 0,5% del valor transferido.
133.401 micropagos fueron intentados y 3461 (2,6%) de estos fracasaron. Para los pagos exitosos, la media de saltos fue de 19 y la mediana de los honorarios totales fue de 2 bits (0,000002 btc) o el 32% del valor transferido.
Aunque cada quien obtendrá sus propias conclusiones de estos datos, es necesario aclarar que la simulación también destacó que de los 7 millones de canales utilizados, sólo el 4% fue exitoso, logrando realizar alrededor de 400 mil pagos, donde al menos el 90% de esa cifra parecía indicar que los pagos tenían más valor en uno de los lados del canal.
Esto coincide con las suposiciones de Fyookball, pero también es posible que durante la implementación de Lightning Network, las rutas alternativas que fueron explicadas por Murch, disminuyan el número de fallos. Por el momento habrá que preguntarse si el 99% de éxito en una simulación (no tan realista) es suficiente cuando se espera que la red tenga un alcance de billones de transacciones en periodos muy cortos de tiempo. Y si es posible, por lo tanto, que sea una opción para hacer escalable la red Bitcoin.
Imagen destacada por Felix Mittermeier / pixabay.com
