Core Lightning: cómo el cambio de marca de la implementación de Blockstream habla de su visión a largo plazo para Bitcoin

Ahora llamada Core Lightning, la implementación de Lightning Network de Blockstream busca ser el estándar interoperable y centrado en la especificación de Bitcoin.

La empresa de infraestructura de Bitcoin, Blockstream, cambió recientemente el nombre de su implementación de Lightning Network de c-lightning a Core Lightning (CLN) en un intento por resaltar el enfoque a largo plazo del proyecto en la interoperabilidad y el trabajo de especificación.

El nombre inicial, que aludía al lenguaje de programación C en el que está integrada la implementación, no reflejaba la intención real de la empresa con el proyecto. Ahora, Core Lightning busca reflejar la propuesta de valor de la implementación de Blockstream.

“Esperamos que el nombre renovado comunique mejor el enfoque de CLN en la interoperabilidad, el trabajo de especificación y el objetivo continuo de proporcionar una implementación de referencia con prioridad en la corrección y la solidez”, dijo la compañía en un comunicado. ambiental.

¿Por qué hay diferentes implementaciones de Lightning Network?

Lightning Network es un concepto abstracto de lo que son, de hecho, muchos canales Lightning diferentes conectados entre sí. Los canales de pago Lightning establecen la base de la red cuando dos participantes bloquean una cantidad de bitcoin en la capa base de la red de Bitcoin para realizar pagos fuera de la cadena rápidos y económicos entre ellos. Sin embargo, al abrir más canales con diferentes participantes, los pagos se pueden enrutar en esta "red de malla", de un participante al siguiente hasta que se encuentre un destinatario final de un pago Lightning.

Por lo tanto, la abstracción que es “la red Lightning” requiere que diferentes participantes se comuniquen entre sí para que puedan enrutar los pagos de los demás y permitir una interacción sin fricciones. Esta comunicación ocurre entre nodos que ejecutan el software del protocolo Lightning y, por lo tanto, pueden enviar y recibir pagos, entre otras cosas.

Mientras que en Bitcoin existe actualmente un software de nodo estándar de facto, Bitcoin Core, hay más de un tipo de software de nodo Lightning que actualmente es popular. Como resultado, existe la necesidad de un conjunto de documentos para dictar cómo estos diferentes tipos de nodos Lightning, también conocidos como "implementaciones", pueden comunicarse entre sí.

El Documentos de la base de la tecnología Lightning (BOLT) definir el conjunto de especificaciones que deben cumplir todas las implementaciones de nodos Lightning para ser un participante estable y compatible en Lightning Network. Actualmente hay 11 documentos BOLT que describen todo, desde cómo establecer un canal de pago y financiarlo con bitcoin hasta cómo se debe solicitar un pago Lightning.

Naturalmente, el hecho de que haya diferentes implementaciones de Lightning también significa que hay diferentes ofertas disponibles para los usuarios, y pueden elegir cualquier software para ejecutar en función de sus necesidades específicas. A un alto nivel, hay cuatro implementaciones principales de Lightning, LND, Core Lightning, Eclair y LDK, cada una orientada a casos de uso específicos.

Core Lightning: construido a partir de BOLT

CLN, anteriormente c-lightning, ha estado en uso de producción en la red principal de Bitcoin desde principios de 2018. Escrito en el lenguaje de programación C, que ofrece a los desarrolladores un alto grado de control sobre el comportamiento de su código incluso a bajo nivel, CLN tiene un enfoque en la eficiencia, así como en proporcionar a los desarrolladores y usuarios un sistema modular, basado en complementos implementación del protocolo de escalado de capa 2 de Bitcoin.

“Nuestro objetivo es ser una implementación de alto rendimiento, de nivel empresarial y que cumpla con las especificaciones”, dijo el desarrollador de Lightning en Blockstream, Rusty Russel. Bitcoin Magazine. “Eso significa tradicionalmente que somos más para usuarios de alto nivel, empresas y desarrolladores para construir sobre ellos”.

CLN solo funciona en Linux y MacOS, y requiere un local o remoto bitcoin versión 0.16 o superior que está completamente al día con la red en la que se ejecuta el usuario y desde la que retransmite transacciones. La poda es parcialmente apoyado.

Como una implementación liviana, CLN permite un gran nivel de personalización, ya que le permite al usuario personalizarlo y agregar solo las funciones que desea o necesita. Los desarrolladores pueden interactuar con el daemon a través de métodos JSON-RPC personalizados, lo que les permite personalizar de manera eficiente la funcionalidad según sus necesidades a través de complementos que pueden acceder directamente a detalles de bajo nivel.

La modularidad, la eficiencia y la solidez del código de CLN también tienen sus inconvenientes. Christian Decker, investigador de Blockstream enfocado en escalar soluciones para Bitcoin, dijo durante la reunión de Londres Bitcoin Devs el mes pasado que, al adherirse a la filosofía de UNIX de hacer una cosa muy bien y no forzar decisiones sobre el usuario, CLN viene de manera "básica" y requiere algo de dedicación del usuario para que funcione .

En particular, la implementación de Blockstream se centra en gran medida en el proceso de especificación y genera gran parte de su código a partir de las especificaciones BOLT directamente, según Russel. Si bien esto garantiza una implementación totalmente compatible con las especificaciones, el equipo tiene menos tiempo para comercializar su trabajo e identifica esta como la razón por la que ve menos participación de la comunidad y participación de nodos que otras implementaciones.

“¡Estamos construidos a partir de las especificaciones Lightning BOLT, literalmente!” russel dijo Bitcoin Magazine. “Esto significa que nos preocupamos mucho (y, como equipo, hemos puesto un gran esfuerzo) en coordinar la arquitectura de toda Lightning Network a través de las especificaciones BOLT”.

El equipo suele proponer una nueva especificación a la comunidad de desarrollo más amplia antes de agregarla a CLN en un intento de garantizar la compatibilidad a largo plazo entre diferentes implementaciones, al tiempo que solicita más ojos para revisar, probar y comentar su código antes de que finalmente se convierta en una nueva. BOLT y queda listo para ser adoptado por todas las implementaciones.

"Parte de la razón por la que hacemos el proceso de especificación y revisión a través de las implementaciones es que ayuda a identificar mejores formas de hacer las cosas: encontrar errores, identificar problemas futuros", dijo Lisa Neigut, ingeniera de protocolo Lightning en Blockstream. Bitcoin Magazine.

Dada su eficiencia y peso ligero, CLN es probablemente la implementación más adecuada para dispositivos de baja especificación.

El equipo de Blockstream también ha desarrollado un conjunto de nuevas funciones que amplían la funcionalidad actual de BOLT, que a menudo son borradores de especificaciones o propuestas de especificaciones, que incluyen aperturas de canales colaborativos, anuncios de liquidez y BOLT 12. CLN le brinda al usuario la opción de probar estas próximas especificaciones.

"Cortamos partes preliminares de la especificación Lightning bajo opciones experimentales", dijo Russel. Bitcoin Magazine. “Pero si eres más aventurero, esas opciones experimentales te dan una

una idea de lo que viene a Lightning Network a continuación!”

Apertura de canales colaborativos, anteriormente llamados "canales de financiación duales", que permiten a los participantes abrir colaborativamente un nuevo canal al financiación conjunta de la transacción de financiación del canal. Actualmente, los canales están abiertos con una transacción de financiación unilateral por parte de un participante. Las aperturas de canales colaborativos también habilitan CoinJoins distribuidos en un canal Lightning abierto.

“Puede orquestar su propio CoinJoin con un montón de otros nodos Lightning”, dijo Neigut Bitcoin Magazine. "Lo haces de forma descentralizada, por lo que las únicas personas que saben quién está involucrado son las personas que realmente forman parte de esa transacción, por lo que no hay un coordinador central que lo haga posible".

Los anuncios de liquidez también aprovechan la apertura de canales colaborativos. Según un Blockstream del blog, "son una forma ligera de brindar la capacidad de coordinar el despliegue de liquidez en la red de manera descentralizada y accesible".

La característica intenta resolver un problema común en Lightning: la liquidez entrante.

Los anuncios de liquidez le permiten "ver a todas las personas que anuncian que le venderán liquidez entrante si les abre un canal, lo cual es algo realmente emocionante", dijo Neigut.

PERNO 12 es otro borrador de especificación para billeteras y nodos Lightning con soporte experimental en CLN. La característica propuesta, denominada "ofertas", mejoraría las facturas BOLT 11 al permitir ofertas reutilizables, mientras que una factura BOLT 11 solo se puede usar una vez. Además, si bien una factura es exclusivamente una solicitud de pago, puede utilizar una oferta para enviar, no solo recibir, dinero.

Los usuarios de CLN ahora también pueden automatizar sus tareas de administración de nodos con CLBOSS, una herramienta de "inteligencia artificial" lanzada recientemente que puede decidir a qué nodos abrir canales, abrir canales cuando las tarifas son bajas y hay fondos en la cadena, ajustar las tarifas de enrutamiento para ser competitivo con otros nodos, realizar intercambios submarinos a través de boltz .exchange API y reequilibra automáticamente los canales.

Si bien se debe alentar a las diferentes implementaciones a buscar soluciones independientes para sus casos de uso específicos mientras cumplen con las especificaciones BOLT 11 actuales, presentar una propuesta de especificación adjunta para ayudar a otras implementaciones a implementar la misma característica, o una similar, es generalmente una buena práctica, como tal. un movimiento que supuestamente satisface los intereses a largo plazo de la amplia y creciente base de usuarios de Lightning. Dicho esto, el proceso de especificación no es una tarea fácil de soportar.

“Como proceso es arduo y toma mucho tiempo. Requiere coordinación con otras personas con muchas perspectivas diferentes”, dijo Neigut.

Como resultado, diferentes empresas dedican diferentes cantidades de tiempo y esfuerzo a este proceso de acuerdo con sus prioridades individuales, que naturalmente difieren. Si bien, según Russel, el equipo de CLN ha dedicado la mayor parte de su "esfuerzo en la especificación y los detalles de implementación de bajo nivel y casi ningún esfuerzo en la divulgación o el marketing de los desarrolladores", Lightning Labs, la compañía detrás de LND, a menudo ha optado por centrarse más recursos de ingeniería en nuevas características y solución de los puntos débiles de los clientes que en el arduo proceso de especificación.

LND: ¿Vacíos que CLN puede llenar?

LND es una implementación de Lightning para desarrolladores que se enfoca en facilitar el desarrollo de aplicaciones por encima de ella, lo que pone un gran énfasis en la interacción del desarrollador, particularmente en un enfoque estándar para la comunicación a través de las API REST, lo que permite un desarrollo de aplicaciones más fácil, además de proporcionar documentación clara y una experiencia de configuración sencilla.

“Queremos que los desarrolladores puedan recogerlo fácilmente, integrarlo en su producto, crear aplicaciones encima de él y distribuirlo como una billetera o un nodo autohospedado”, desarrollador de LND, Oliver Gugger dijo en la reunión de Londres Bitcoin Devs. “Llevarlo a la plebe”.

Como resultado, LND se enfoca en “tener una excelente interfaz de desarrollador”, agregó Gugger, al habilitar gRPC y REST.

"LND tiene una gran comunidad, una configuración fácil y una excelente documentación para desarrolladores", dijo Russel cuando se le preguntó por qué pensaba que LND es la implementación de Lightning más popular.

LND ha visto la mayor participación de la comunidad entre todas las implementaciones y actualmente ejecuta la mayoría de todos los nodos de la red. Algunas estimaciones coloque la participación de LND en el total de nodos Lightning públicos entre el 70 % y el 90 %.

LND también cuenta con lo que posiblemente sea el equipo de desarrollo de tiempo completo más grande. Como resultado, el equipo ha logrado crear una gran cantidad de servicios de valor agregado en torno a LND, como abertura y los servicios de liquidez Lightning Red ISTE Loop y Piscina.

Loop utiliza intercambios submarinos para unir bitcoin dentro y fuera de la cadena, lo que facilita mover bitcoin dentro y fuera de Lightning Network. Realiza balanceo de canales automatizado, intercambios sin custodia de privacidad hacia adelante, procesamiento por lotes de transacciones oportunistas que ahorran tarifas y monitoreo del progreso de los intercambios en vuelo.

Pool es un mercado peer-to-peer para canales Lightning. Conecta a los usuarios que necesitan acceso a la liquidez entrante con aquellos que tienen capital para implementar en Lightning Network al permitir que un participante de Lightning Network señale su necesidad e incentivar a otros a abrir canales con ellos usando su capital.

Con el enfoque de LND típicamente en las nuevas funciones y la atención al cliente, el equipo de CLN ha encontrado un vacío en el mercado que espera llenar prestando más atención al proceso de especificación.

Según las especificaciones o no según las especificaciones

“El equipo de Labs ha creado cosas geniales”, dijo Neigut. “Simplemente, como organización, no han sido sorprendentes al escribir especificaciones para las cosas que agregan. Un buen ejemplo de eso es KeySend”.

Enviar clave permite que un nodo Lightning envíe a alguien un pago Lightning con solo la ID del nodo receptor, lo que significa que la herramienta no requiere facturas, que son las actuales estándar de facto en el mecanismo de pago de Lightning.

“Lo lanzaron, mucha gente comenzó a usarlo, pero nunca lo especificaron por completo”, agregó Neigut. “Así que CLN quería poder apoyarlo. Uno de los miembros de nuestro equipo tuvo que volver atrás y descubrir cómo hacer que funcionara simplemente leyendo su código y aplicando ingeniería inversa”.

Finalmente, la implementación Lightning de Spiral, LDK, escribió una especificación, recordó Neigut, después de que su equipo aplicara ingeniería inversa al código de Lightning Labs.

“Y los otros equipos realmente solo tuvieron que seguirlos porque LND tiene una base de instalación tan grande”, dijo. “Ese no es como el proceso más colaborativo”.

“El equipo de personas que trabajan en el material de Lightning Labs es bastante sólido”, agregó Neigut. "Simplemente creo que se están aprovechando de su dominio de la red para no tener que hacer todo este trabajo adicional porque si no lo hacen, alguien más lo hará porque la mayoría de los nodos de la red ejecutan su código".

Neigut dijo que ya está acostumbrada a que LND esté en el centro de atención y sea la implementación de "Lightning predeterminada", algo que confiesa que disfruta como desarrolladora debido a las pocas demandas de atención al cliente que recibe.

“Pero creo que obtendríamos una dinámica de red más saludable si no hubiera una implementación mayoritaria”, agregó. “Creo que eso realmente cambiaría el juego en términos de la cantidad de colaboración que todos tienen que hacer para enviar sus cosas en Lightning. Y eso sería saludable”.

Podría decirse que la atención cuidadosa a las especificaciones es fundamental para el desarrollo de código abierto en un entorno de red abierta. En Lightning, dichas especificaciones forman la base del protocolo y aseguran la interoperabilidad de las diferentes versiones que participan en la red.

Sin embargo, mientras algunos argumentan que los cambios importantes y las nuevas incorporaciones a una implementación de Lightning deberían tener una especificación adjunta, otros podrían ver las especificaciones de BOLT como un mínimo, además de que cada implementación puede crear sus propias características nuevas y emocionantes, que no necesariamente tendrían que ser portado de nuevo a la suite de especificaciones.

"Sus en las crear una empresa de infraestructura de código abierto, por lo que no sorprende que no esté de acuerdo con todas las prioridades [de Lightning Labs]”, dijo Russel. “Realmente creo que encontrarán una manera de crear un flujo de ingresos sostenible y ser un socio confiable en el desarrollo técnico de Lightning Network; No creo que nadie quiera ver la red dividida en pedazos”.

Ignorar por completo el proceso de especificación podría conducir a la aparición de subecosistemas muy diferentes, lo que podría perjudicar el desarrollo y la adopción de Lightning Network en su conjunto si dejaran de ser interoperables. Pero como destacó Russel, no hay indicios de que alguna implementación esté haciendo eso hoy. Mantener una interacción cohesiva e interoperable entre los nodos es clave si queremos mantener los detalles de implementación alejados del usuario y, por lo tanto, permitir una buena experiencia de usuario.

“Si [Lightning Labs] fuera el líder y también estuviera a la vanguardia en especificaciones, creo que habría un poco menos de fricción al agregar nuevas funciones, porque no sería tan difícil seguir lo que están haciendo. ”, dijo Neigut. “Tal vez estarán más involucrados en el proceso de especificación en el futuro. Creo que definitivamente han recibido comentarios de nosotros y del resto de la comunidad de que el proceso de especificación es importante”.

Parte de la controversia y tensiones en el proceso de especificación BOLT provenir de un correo electrónico compartido en Twitter a fines de febrero, en el que el jefe de liquidez de Lightning en Lightning Labs, Alex Bosworth, comentó sobre BOLT 12 y el proceso de especificación de BOLT.

Bosworth escribió que el proceso BOLT es un proceso de estandarización arbitrario que no requiere el consentimiento de las personas y, por lo tanto, representa "más un conjunto de documentos obstinados controlados por un proceso arbitrario que un tratado entre implementaciones independientes".

Laboratorios Lightning más tarde aclarado que los comentarios de Bosworth reflejan solo su opinión y no necesariamente la de la empresa.

Decker compartió sus pensamientos sobre los comentarios de Bosworth y sobre el proceso de especificaciones BOLT durante la reunión de Londres Bitcoin Devs.

“Creo que esas son declaraciones muy fuertes de alguien que nunca ha participado en una sola reunión de especificaciones”, dijo. “Hay un poco de controversia en el proceso de especificación, pero eso es por diseño. Si una implementación pudiera dictar cómo se ve toda la red, terminaríamos con una visión muy miope de lo que podría ser la red y no podríamos atender todos los diferentes casos de uso que estamos atendiendo”.

“Y sí, a veces el proceso de especificación es frustrante, estoy totalmente de acuerdo con eso”, agregó. “Ciertamente tenemos diferentes puntos de vista sobre cómo debería ser la red. Pero mediante este proceso de tesis, antítesis y síntesis, llegamos a un sistema que es mucho más capaz de servir a nuestros usuarios que si una implementación lo hiciera sola”.

“Yo personalmente no trabajo en la especificación, así que no me siento calificado para dar una respuesta”, dijo Gugger en la reunión, al comentar el correo electrónico de Bosworth. “Solo quería agregar que no estoy necesariamente de acuerdo con todos los puntos que mencionó Alex. Definitivamente lo habría dicho de una manera diferente también. Creo que la falta de recursos para trabajar en la especificación a veces se interpreta como que bloqueamos cosas que no son la intención ni nuestro objetivo, por supuesto. Queremos trabajar más en las especificaciones, así que espero que mejoremos allí. Es interesante observar cómo esa frustración a veces sale a la superficie. Gracias [Decker y el desarrollador de ACINQ, Bastien Teinturier] por todo el trabajo que realizan en la especificación. Necesito recoger también, así que haré lo mejor que pueda”.

Russel también comentó sobre el correo electrónico de Bosworth en un Hilo de Twitter donde se comprometió a dedicar más tiempo a pulir y comercializar CLN, ya que dijo que LND no implementó Lightning primero y no lo implementó mejor, aunque su comunidad es excelente, agregó.

“Resulta que han decidido que pueden aprovechar el dominio de la red en el control del protocolo, y el proceso de especificación no es 'real'”, escribió en el hilo. “Lightning Labs ha reclamado la propiedad de la red Lightning de muchas maneras: he sido reacio a llamarlos en público. Pero Lightning Network y la comunidad merecen algo mejor”.

Russel no respondió a las preguntas de Bitcoin Magazine haciendo referencia a este hilo. Lightning Labs se negó a comentar.

“En 2016 venimos de tres direcciones diferentes y decidimos unir todo lo que aprendimos durante esta fase inicial de experimentación en una sola especificación para que pudiéramos colaborar e interoperar”, dijo Decker en la reunión. “Esta fase experimental siempre debe ser seguida por una propuesta que sea introspectable para todos y que todos puedan implementar. A veces falta esa propuesta formal y eso impide que las otras implementaciones den su propia revisión sobre esa función. Esta revisión es muy importante para asegurarnos de que funcione para todos y que sea lo mejor que podamos hacer”.

“Como sugiere el nombre Lightning Network, se beneficia mucho de los efectos de red que obtenemos al ser compatibles, al poder interoperar y permitir que todas las implementaciones jueguen en igualdad de condiciones”, agregó más tarde.

Las implementaciones se complementan, no compiten

Además de esa controversia muy específica con respecto al proceso de especificación, las implementaciones de Lightning en su mayoría funcionan por separado y luego juntas para brindar las mejores y más demandadas funciones a la red, lo que garantiza una mejor experiencia de usuario en general.

Como resultado, el movimiento de Blockstream para impulsar CLN como una oferta modular y liviana que cumple con las especificaciones se presenta como una alternativa para aquellos interesados ​​​​en ejecutar una implementación de nodo que se esfuerza por ser completamente interoperable con el resto de la red y proporciona un conjunto único de beneficios a los que lo hacen.

A medida que las diferentes implementaciones se esfuerzan por convertirse en su mejor versión y atender un caso de uso específico mediante la exploración de su propia propuesta de valor, el usuario es, en última instancia, el que se beneficia a medida que surgen más y mejores opciones.

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. ACCESO LIBRE.
• CriptoHawk. Radar de altcoins. Prueba gratis.
• Fuente: https://bitcoinmagazine.com/technical/blockstream-core-lightning-bitcoin-rebrand