Al avanzar hacia el futuro de la adopción y el desarrollo de Bitcoin, hay un problema de interacción del software que está pasando a la vanguardia de los obstáculos con los que los desarrolladores deben lidiar: la compatibilidad. A medida que las aplicaciones y protocolos en este espacio se vuelven más complejos y con más funciones para satisfacer las necesidades de los usuarios y casos de uso reales, esto presenta un dilema que fundamentalmente solo tiene dos respuestas reales; Una aplicación o una billetera deben integrar internamente todos los protocolos y funciones necesarios para cumplir con los requisitos de su propósito, o diferentes aplicaciones deben poder comunicarse entre sí.
Un ejemplo de dónde surge este problema es la integración de Lightning en diferentes aplicaciones y herramientas de software. Lightning es una pila de protocolos muy complicada de implementar, que involucra numerosos subprotocolos que dictan cómo coordinar y procesar las actualizaciones del estado de un canal Lightning. Esto implica la estructura de transacciones para cada estado del canal y lo que se aplica, el orden en el que se lleva a cabo cada paso de elaboración y firma de nuevas transacciones para garantizar la seguridad de los fondos de los usuarios, y funciones para vigilar el cadena de bloques para reaccionar de la manera apropiada automáticamente si alguna vez se envían estados no válidos a la cadena de bloques.
Esto supone una gran complejidad para que un solo desarrollador de aplicaciones pueda asumir la integración directa en su proyecto. La conclusión obvia, si eso requiere demasiado esfuerzo, es depender del software ya producido que maneja el problema de implementar Lightning y simplemente crear su aplicación para comunicarse con ese software externo. Eso lleva al siguiente problema: ¿qué pasa si los usuarios de su aplicación no usan esa implementación o billetera Lightning en particular?
Incluso subcontratando esa funcionalidad de una aplicación, el equipo de desarrollo aún no ha escapado por completo al problema de la complejidad. Si bien no tienen que implementar Lightning completamente por su cuenta, un desarrollador que tome esta ruta ahora tiene que encargarse de incorporar soporte API para cualquier billetera Lightning que el usuario de su aplicación pueda estar usando. Esto requiere mantenerse al día con cualquier cambio o alteración en múltiples billeteras Lightning, su API, cómo funcionan las características internas de esa billetera y cuáles admiten. No mantenerse al día con los cambios en una billetera en particular interrumpiría su aplicación para los usuarios de esa billetera.
Es necesario que exista algún mecanismo estandarizado para que el software en ambos lados de esa brecha pueda simplemente implementar eso para que todas estas herramientas diferentes se comuniquen entre sí. Esto permitiría a cada desarrollador de aplicaciones y a cada desarrollador de billetera Lightning simplemente integrar y mantener un único protocolo que permitiría que sus aplicaciones se comunicaran entre sí.
Nostr Wallet Connect es un protocolo que intenta ser un mecanismo verdaderamente generalizado para satisfacer esta necesidad. Al intentar integrar pagos Lightning en Nostr, surgieron todos estos problemas de complejidad relacionados con cómo hacerlo.
Rayos y NWC
El equipo detrás de Amethyst, un cliente de Nostr, y Alby, la billetera Lightning basada en la web, creó NWC para resolver el problema de los usuarios de Nostr que desean integrar Lightning en su experiencia Nostr sin tener que usar una billetera especial. La aplicación/protocolo se basa en la arquitectura de identidad de Nostr, donde cada mensaje (evento) enviado a través de Nostr está firmado por un par de claves criptográficas que funciona como su identidad en Nostr. Esto permite que una aplicación genere simplemente un par de claves Nostr y, a partir de eso, tenga un mecanismo de autenticación criptográfica para usar en la comunicación con una billetera Bitcoin externa para cumplir con la funcionalidad de la aplicación.
Al usar el par de claves para registrar la aplicación externa con la billetera Lightning, la aplicación ahora puede hacer ping a su billetera para iniciar un pago. Actualmente, la especificación admite el pago de facturas BOLT 11, la realización de pagos mediante envío de claves (pagos sin factura realizados a la clave pública de un nodo), el pago de varias facturas simultáneamente, la generación de una factura para presentarla a otra persona para que le pague y algunas otras funcionalidades para permitir el historial de pagos y consultas de saldo de billetera desde la aplicación externa.
Todo esto se coordina a través de Nostr, lo que permite un medio de comunicación muy redundante que no depende de un único mecanismo de mensajería centralizado o que el usuario necesita depender de software complicado como Tor u otros protocolos para facilitar la conexión de red entre una aplicación y el software de billetera. o infraestructura que se ejecuta en su red doméstica. Nostr también admite mensajes directos cifrados, lo que significa que la comunicación entre la billetera y la aplicación es completamente privada, y no revela detalles sobre los pagos que se coordinan con los repetidores de Nostr utilizados para comunicarse.
En el lado de la billetera del puente NWC, se pueden implementar restricciones de seguridad para evitar que la aplicación externa tenga acceso ilimitado a los fondos de la billetera en caso de que la clave Nostr utilizada para comunicarse con la billetera se vea comprometida. Las restricciones sobre las cantidades permitidas para gastar, así como la frecuencia de los pagos, se pueden configurar en el lado de la billetera de la conexión.
NWC también es útil para mucho más que simplemente integrar Lightning en las aplicaciones Nostr. Toda la filosofía de diseño de Nostr como protocolo se centró en mantenerlo lo suficientemente simple como para que cualquier desarrollador pudiera implementar correctamente todo el protocolo con un mínimo de tiempo y recursos. Las aplicaciones que no tienen nada que ver con Nostr pueden integrar fácilmente NWC o protocolos similares casi sin gastos generales ni complejidad para abordar los problemas subyacentes de cómo conectar una billetera Bitcoin con su aplicación sin tener que construirla directamente en la aplicación.
Más allá del rayo
El potencial de un protocolo como NWC para proporcionar un valor enorme a los desarrolladores de aplicaciones y billeteras va mucho más allá de la integración de billeteras Lightning en aplicaciones de propósito especial. Toda la dirección a largo plazo de la interacción con Bitcoin, salvo algún avance fundamental alucinante que nadie haya notado todavía, es hacia protocolos interactivos entre múltiples usuarios.
Los coinpools multipartidistas son un ejemplo perfecto. La mayoría de las propuestas de diseño específicas, como los árboles Ark o Timeout, se construyen en torno a una parte coordinadora central o un proveedor de servicios, que puede facilitar fácilmente un medio de transmisión de mensajes entre las billeteras de los usuarios, pero esto paraliza el espacio de diseño con un único punto de falla. Si cien usuarios se agrupan en un grupo de monedas sobre un solo UTXO, el modelo de seguridad se basa en que cada usuario tenga una ruta prefirmada para retirar sus monedas unilateralmente en la cadena. Este mecanismo se puede ejercer en caso de que el coordinador no pueda garantizar que sus fondos no se pierdan o desaparezca, pero esta es la forma menos eficiente de manejar el peor de los casos.
Si los usuarios pudieran encontrar un mecanismo para comunicarse entre sí en ausencia del proveedor o coordinador de servicios, se podrían lograr salidas en cadena mucho más eficientes utilizando el grupo multifirma más grande para migrar sus fondos a otra parte con una forma mucho más eficiente ( y por lo tanto más barato) huella en la cadena. NWC y Nostr encajan perfectamente en tal escenario.
Las billeteras colaborativas multifirma entre múltiples partes también podrían beneficiarse de dicho protocolo. En combinación con estándares como PSBT, un mecanismo de comunicación simple de Nostr podría simplificar drásticamente la complejidad de diferentes billeteras con soporte multifirma que coordina la firma de transacciones de una manera fluida y fácil de usar.
Los contratos de registro discretos (DLC) son otro uso sorprendente de dicho protocolo. Todo el esquema DLC se basa en que ambas partes puedan acceder a las firmas de Oracle para cerrar unilateralmente un contrato correctamente si ambas partes no cooperan para resolverlo de manera colaborativa. Nostr es el mecanismo perfecto para que los oráculos transmitan estas firmas y permite una simple suscripción a su clave Nostr en las billeteras de los usuarios para rastrear y adquirir firmas automáticamente cuando los oráculos las transmiten.
A medida que pasa el tiempo y se construyen más aplicaciones y protocolos sobre Bitcoin con el requisito de interactividad entre usuarios y entre diferentes aplicaciones, será muy necesario un mecanismo de comunicación de propósito general para facilitar eso sin depender de un único punto de falla. .
Nostr es el protocolo subyacente perfecto para facilitar esto dada su increíble simplicidad y la redundancia de un gran conjunto de relés para utilizar. NWC es el ejemplo perfecto de que se trata de una solución viable.
