Autor: Viktor Bunin, Compilador experto en Coinbase Cloud Protocol: Qianwen, ChainCatcher
No he usado Lightening (más tarde llamado "Lightning Network") por un tiempo.
La última vez que pasé tiempo trabajando en esto fue en 2019 cuando me asocié con Elizabeth Stark y otros líderes de la comunidad para organizar la primera Conferencia Lightning Network en Berlín. Desde entonces, he pasado la mayor parte de mi tiempo trabajando en otros protocolos, y aunque todavía soy amigo de personas como Elizabeth, mi comprensión de cómo funciona Lightning Network en realidad se ha degradado. Después de volver a examinar, me di cuenta de que no era solo yo, sino también la mayoría de mis amigos.
Esta publicación es para aquellos que no han usado Lightning Network recientemente. Discutiré conceptos erróneos que yo o otros que he visto. Si me he perdido algún punto bueno, por favor envíeme una línea en Twitter.
**Concepto erróneo 1: debe ejecutar su propio nodo para usar Lightning Network sin custodia, lo que evita que los usuarios normales usen dispositivos móviles. **
Esto era cierto hace algunos años, pero ahora los usuarios pueden usar Lightning Network en dispositivos móviles a través de clientes ligeros no administrados. Los usuarios siempre tienen el control de sus claves, y la experiencia de billetera con Lightning Light Client es la misma que llamar a Alchemy o Infura a través de RPC cuando se usa Ethereum.
**Concepto erróneo 2: el remitente y el destinatario deben estar en línea al mismo tiempo para que los pagos Lightning se realicen correctamente (sin pagos fuera de línea/sincrónicos). **
Esta situación todavía existe, pero con algunas soluciones ingeniosas. Las billeteras móviles Lightning sin custodia pueden recibir pagos a través de tareas en segundo plano o notificaciones telefónicas incluso cuando la billetera no se está ejecutando en primer plano. Sin embargo, este enfoque está limitado por los sistemas operativos móviles. Los sistemas operativos modernos limitan la cantidad de cálculos realizados por las aplicaciones en segundo plano para ahorrar batería. Recibir algunos pagos de LN está bien, pero si se reciben demasiados en un corto período de tiempo, comienzan a caducar debido a restricciones computacionales.
A más largo plazo, los desarrolladores del protocolo Lightning Network están trabajando en la especificación Async Payments, que permitirá latencias sin confianza arbitrariamente largas. Esencialmente, el pago se acredita desde el nodo del remitente, pero si el nodo del receptor se desconecta, el pago permanece en el LSP del remitente (Lightning Network/Proveedor de servicios de liquidez, generalmente administrado por la propia billetera), hasta que el receptor vuelve a estar en línea. ** Se espera que esta actualización suceda el próximo año, pero aún no hay una fecha de lanzamiento oficial. **Sin embargo, esto requiere que las billeteras participantes contengan LSP, lo que puede dificultar su adopción como una solución para toda la red.
** Malentendido 3: Lightning Network requiere que ambos usuarios inviertan la misma cantidad de BTC en el canal para abrir el canal. **
Esto no es cierto. En la mayoría de los clientes de Lightning Network, el canal está abierto en un solo sentido de forma predeterminada, por lo que solo el remitente debe invertir fondos en el canal y el beneficiario puede ser una nueva dirección vacía. Este malentendido se deriva del libro blanco de Lightning Network, donde los ejemplos se refieren constantemente a canales de financiación bidireccionales.
En realidad, se basa en una historia de fondo interesante. El primer canal de pago (Spilman) solo permitía pagos unidireccionales. La innovación de Lightning Network radica en la realización de fondos dobles y pago bidireccional, y el canal no tiene tiempo de caducidad. Esta es quizás la razón por la cual el artículo de Lightning Network se enfoca tanto en esto. Esta fue una invención importante en relación con los diseños de protocolos conocidos en ese momento.
**Mito 4: Lightning Network requiere que los usuarios especifiquen facturas específicas de un solo propósito, lo cual es una experiencia de usuario terrible. **
De hecho, esto era cierto al principio. Pero ahora con la dirección de Lightning Network, es básicamente el ENS de Lightning Network. Están habilitados por lnurl-pay, que permite a los usuarios enviar BTC a viktor@example.com a través de Lightning Network, independientemente de la cantidad y la duración.
** Malentendido 5: los usuarios deben comprender y elegir Bitcoin y Lightning Network al enviar BTC. **
Debe haber sido así antes. Pero ahora es diferente. Ahora, tienen un código QR unificado que agrupa perfectamente la dirección en cadena con la factura de Lightning Network para que la billetera de envío pueda elegir la ruta correcta. Abra CashApp, vaya a la pestaña Bitcoin. Tenga en cuenta que, si bien Cash App es compatible con Lightning Network, no hay opción para seleccionar Lightning Network. Esto se debe a que están utilizando el código QR unificado.
Sin embargo, esto no resuelve el problema de un solo saldo: el saldo de BTC de un usuario aún podría dividirse en la cadena y en Lightning Network. Este problema se puede resolver hasta cierto punto a través de Submarineswap y/o Splicing, pero mi opinión a largo plazo es que los usuarios ni siquiera se darán cuenta de que esto es un problema, ni se darán cuenta de que Lightning Network existe porque la billetera y otros proveedores manejan las complejidades subyacentes que se ocultarán debajo de una experiencia de usuario fluida.
**Mito #6: Lightning Network es ineficiente en términos de capital y, por lo tanto, no es viable. **
Esta discusión es delicada y trataré de ser lo más neutral posible.
Lightning Network utiliza un modelo hub-and-spoke. La porción de centro a centro de la red es altamente eficiente en términos de capital debido a la alta proporción de "asignación de capital por unidad" de grandes canales entre intercambios, carteras de custodia, LSP y nodos de enrutamiento óptimos.
Sin embargo, donde la ineficiencia de capital de la red Lightning está en los bordes: usuarios sin custodia. Para los usuarios de custodia de Lightning, las billeteras solo necesitan mantener grandes canales con otros centros y realizar la contabilidad interna de los saldos de los usuarios. Para los usuarios sin custodia, la billetera debe mantener un canal de financiación abierto separado con cada usuario. El desafío es cómo mantener la asignación y gestión continua de liquidez a través de estos canales.
Para dar un ejemplo concreto: un usuario de billetera sin custodia quiere enviar 0.1 BTC a un amigo a través de Lightning Network. Suponiendo que haya suficiente liquidez en el canal entre ellos y el proveedor de la billetera y cada nodo en el camino, el pago será exitoso. Pero ahora la billetera tiene un problema: tienen 0,1 BTC en el canal de su lado, si el usuario no recibe ningún pago (reequilibrando así el canal), estos 0,1 BTC estarán inactivos allí, lo que provocará una baja ineficiencia del proveedor de la billetera. En este punto, los proveedores de billeteras deben decidir si conservar la liquidez o retirarla cerrando canales (lo que crea una experiencia de usuario deficiente) o empalmando canales (que son invisibles para los usuarios).
Para los usuarios sin custodia, este problema de ineficiencia de capital marginal es un problema de optimización muy molesto, que es objetivamente peor que el modelo basado en cuentas, independientemente del tamaño de la transacción. Sin embargo, este no es un problema insoluble. Siempre que no sea imposible, debe tener éxito, que también es el lema de la comunidad de desarrolladores de Bitcoin.
Además de la dificultad de la optimización del capital, otro desafío proviene de los costos asociados con la gestión de canales y liquidez, ya que cada empalme, cierre de canales, etc. requiere una transacción en cadena. El presupuesto de seguridad de Bitcoin se basa en un aumento masivo en las tarifas de transacción, pero si las tarifas de transacción aumentan a $ 30- $ 60, la administración del canal será prohibitivamente costosa a escala, y es posible que Lightning Network sin custodia no esté disponible para una gran parte de la población mundial. Las billeteras Lightning alojadas actualmente tienen una ventaja debido a los incentivos incorporados, y probablemente crecerán aún más a medida que crezcan las tarifas en cadena, ya que su modelo de cuenta ómnibus hace que la administración de canales sea mucho menos frecuente. La comunidad está trabajando arduamente para solucionar esto y garantizar que las billeteras Lightning sin custodia continúen siendo ciudadanos de primera clase en la red, pero aún no existe una solución clara.
Lightning Network todavía tiene un largo camino por recorrer para ser simple, transparente y completamente abstracto. Todavía hay muchos casos extremos y los usuarios no administrados aún no han disfrutado de la mejor experiencia de usuario. Sin embargo, muchos problemas ya se han resuelto y muchos más se resolverán en los próximos años. Ahora que ha llegado el relámpago, ¿puede estar muy lejos el trueno?
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Aclarando 6 conceptos erróneos sobre Lightning Network de Bitcoin
Autor: Viktor Bunin, Compilador experto en Coinbase Cloud Protocol: Qianwen, ChainCatcher
No he usado Lightening (más tarde llamado "Lightning Network") por un tiempo.
La última vez que pasé tiempo trabajando en esto fue en 2019 cuando me asocié con Elizabeth Stark y otros líderes de la comunidad para organizar la primera Conferencia Lightning Network en Berlín. Desde entonces, he pasado la mayor parte de mi tiempo trabajando en otros protocolos, y aunque todavía soy amigo de personas como Elizabeth, mi comprensión de cómo funciona Lightning Network en realidad se ha degradado. Después de volver a examinar, me di cuenta de que no era solo yo, sino también la mayoría de mis amigos.
Esta publicación es para aquellos que no han usado Lightning Network recientemente. Discutiré conceptos erróneos que yo o otros que he visto. Si me he perdido algún punto bueno, por favor envíeme una línea en Twitter.
**Concepto erróneo 1: debe ejecutar su propio nodo para usar Lightning Network sin custodia, lo que evita que los usuarios normales usen dispositivos móviles. **
Esto era cierto hace algunos años, pero ahora los usuarios pueden usar Lightning Network en dispositivos móviles a través de clientes ligeros no administrados. Los usuarios siempre tienen el control de sus claves, y la experiencia de billetera con Lightning Light Client es la misma que llamar a Alchemy o Infura a través de RPC cuando se usa Ethereum.
**Concepto erróneo 2: el remitente y el destinatario deben estar en línea al mismo tiempo para que los pagos Lightning se realicen correctamente (sin pagos fuera de línea/sincrónicos). **
Esta situación todavía existe, pero con algunas soluciones ingeniosas. Las billeteras móviles Lightning sin custodia pueden recibir pagos a través de tareas en segundo plano o notificaciones telefónicas incluso cuando la billetera no se está ejecutando en primer plano. Sin embargo, este enfoque está limitado por los sistemas operativos móviles. Los sistemas operativos modernos limitan la cantidad de cálculos realizados por las aplicaciones en segundo plano para ahorrar batería. Recibir algunos pagos de LN está bien, pero si se reciben demasiados en un corto período de tiempo, comienzan a caducar debido a restricciones computacionales.
A más largo plazo, los desarrolladores del protocolo Lightning Network están trabajando en la especificación Async Payments, que permitirá latencias sin confianza arbitrariamente largas. Esencialmente, el pago se acredita desde el nodo del remitente, pero si el nodo del receptor se desconecta, el pago permanece en el LSP del remitente (Lightning Network/Proveedor de servicios de liquidez, generalmente administrado por la propia billetera), hasta que el receptor vuelve a estar en línea. ** Se espera que esta actualización suceda el próximo año, pero aún no hay una fecha de lanzamiento oficial. **Sin embargo, esto requiere que las billeteras participantes contengan LSP, lo que puede dificultar su adopción como una solución para toda la red.
** Malentendido 3: Lightning Network requiere que ambos usuarios inviertan la misma cantidad de BTC en el canal para abrir el canal. **
Esto no es cierto. En la mayoría de los clientes de Lightning Network, el canal está abierto en un solo sentido de forma predeterminada, por lo que solo el remitente debe invertir fondos en el canal y el beneficiario puede ser una nueva dirección vacía. Este malentendido se deriva del libro blanco de Lightning Network, donde los ejemplos se refieren constantemente a canales de financiación bidireccionales.
En realidad, se basa en una historia de fondo interesante. El primer canal de pago (Spilman) solo permitía pagos unidireccionales. La innovación de Lightning Network radica en la realización de fondos dobles y pago bidireccional, y el canal no tiene tiempo de caducidad. Esta es quizás la razón por la cual el artículo de Lightning Network se enfoca tanto en esto. Esta fue una invención importante en relación con los diseños de protocolos conocidos en ese momento.
**Mito 4: Lightning Network requiere que los usuarios especifiquen facturas específicas de un solo propósito, lo cual es una experiencia de usuario terrible. **
De hecho, esto era cierto al principio. Pero ahora con la dirección de Lightning Network, es básicamente el ENS de Lightning Network. Están habilitados por lnurl-pay, que permite a los usuarios enviar BTC a viktor@example.com a través de Lightning Network, independientemente de la cantidad y la duración.
** Malentendido 5: los usuarios deben comprender y elegir Bitcoin y Lightning Network al enviar BTC. **
Debe haber sido así antes. Pero ahora es diferente. Ahora, tienen un código QR unificado que agrupa perfectamente la dirección en cadena con la factura de Lightning Network para que la billetera de envío pueda elegir la ruta correcta. Abra CashApp, vaya a la pestaña Bitcoin. Tenga en cuenta que, si bien Cash App es compatible con Lightning Network, no hay opción para seleccionar Lightning Network. Esto se debe a que están utilizando el código QR unificado.
Sin embargo, esto no resuelve el problema de un solo saldo: el saldo de BTC de un usuario aún podría dividirse en la cadena y en Lightning Network. Este problema se puede resolver hasta cierto punto a través de Submarineswap y/o Splicing, pero mi opinión a largo plazo es que los usuarios ni siquiera se darán cuenta de que esto es un problema, ni se darán cuenta de que Lightning Network existe porque la billetera y otros proveedores manejan las complejidades subyacentes que se ocultarán debajo de una experiencia de usuario fluida.
**Mito #6: Lightning Network es ineficiente en términos de capital y, por lo tanto, no es viable. **
Esta discusión es delicada y trataré de ser lo más neutral posible.
Lightning Network utiliza un modelo hub-and-spoke. La porción de centro a centro de la red es altamente eficiente en términos de capital debido a la alta proporción de "asignación de capital por unidad" de grandes canales entre intercambios, carteras de custodia, LSP y nodos de enrutamiento óptimos.
Sin embargo, donde la ineficiencia de capital de la red Lightning está en los bordes: usuarios sin custodia. Para los usuarios de custodia de Lightning, las billeteras solo necesitan mantener grandes canales con otros centros y realizar la contabilidad interna de los saldos de los usuarios. Para los usuarios sin custodia, la billetera debe mantener un canal de financiación abierto separado con cada usuario. El desafío es cómo mantener la asignación y gestión continua de liquidez a través de estos canales.
Para dar un ejemplo concreto: un usuario de billetera sin custodia quiere enviar 0.1 BTC a un amigo a través de Lightning Network. Suponiendo que haya suficiente liquidez en el canal entre ellos y el proveedor de la billetera y cada nodo en el camino, el pago será exitoso. Pero ahora la billetera tiene un problema: tienen 0,1 BTC en el canal de su lado, si el usuario no recibe ningún pago (reequilibrando así el canal), estos 0,1 BTC estarán inactivos allí, lo que provocará una baja ineficiencia del proveedor de la billetera. En este punto, los proveedores de billeteras deben decidir si conservar la liquidez o retirarla cerrando canales (lo que crea una experiencia de usuario deficiente) o empalmando canales (que son invisibles para los usuarios).
Para los usuarios sin custodia, este problema de ineficiencia de capital marginal es un problema de optimización muy molesto, que es objetivamente peor que el modelo basado en cuentas, independientemente del tamaño de la transacción. Sin embargo, este no es un problema insoluble. Siempre que no sea imposible, debe tener éxito, que también es el lema de la comunidad de desarrolladores de Bitcoin.
Además de la dificultad de la optimización del capital, otro desafío proviene de los costos asociados con la gestión de canales y liquidez, ya que cada empalme, cierre de canales, etc. requiere una transacción en cadena. El presupuesto de seguridad de Bitcoin se basa en un aumento masivo en las tarifas de transacción, pero si las tarifas de transacción aumentan a $ 30- $ 60, la administración del canal será prohibitivamente costosa a escala, y es posible que Lightning Network sin custodia no esté disponible para una gran parte de la población mundial. Las billeteras Lightning alojadas actualmente tienen una ventaja debido a los incentivos incorporados, y probablemente crecerán aún más a medida que crezcan las tarifas en cadena, ya que su modelo de cuenta ómnibus hace que la administración de canales sea mucho menos frecuente. La comunidad está trabajando arduamente para solucionar esto y garantizar que las billeteras Lightning sin custodia continúen siendo ciudadanos de primera clase en la red, pero aún no existe una solución clara.
Lightning Network todavía tiene un largo camino por recorrer para ser simple, transparente y completamente abstracto. Todavía hay muchos casos extremos y los usuarios no administrados aún no han disfrutado de la mejor experiencia de usuario. Sin embargo, muchos problemas ya se han resuelto y muchos más se resolverán en los próximos años. Ahora que ha llegado el relámpago, ¿puede estar muy lejos el trueno?