Nostr: La infraestructura para la Web3 sin Blockchain (2 de 6)
Nostr es un protocolo sencillo que no requiere de protocolos de consenso asociados al coste económico de las criptomonedas.
Esta entrada es parte de una serie de artículos sobre Nostr. Véase el artículo anterior.
Ahondando en sus orígenes, Nostr surgió como una solución práctica para la comunicación entre clientes de Lightning Network, ante los problemas de usar el protocolo de mensajería de Bitcoin para respaldar la información del intercambio de activos y la emisión de comprobantes de recibos de compra. Tales problemas acarreaban una carga excesiva en la operación de los nodos por el uso de la red transaccional para otras tareas distintas a las operaciones monetarias.
Recientemente, Nostr demostró su utilidad al resolver el problema de los NFT implementados en Bitcoin a través del mecanismo de los Ordinals, un método conocido para incluir metadatos en las transacciones de la blockchain. Previamente, al utilizar indebidamente los Ordinals para NFTs se incrementaba la utilización de datos en los bloques de transacción y se congestionaba la red con numerosas transacciones de los Ordinals en espera en la mempool, ocasionando tarifas más altas y tiempos de confirmación más largos.
En respuesta a estos desafíos, Anthony Towns, un programador que participó en la creación de Taproot, presentó una propuesta revolucionaria para aliviar la carga que representan los NFT Ordinals en la red Bitcoin. Su solución se basa en el protocolo Nostr, que propone separar las inscripciones (nombres de NFT y archivos adjuntos) de la red principal de Bitcoin.
La idea detrás del uso de Nostr para NFTs es simple pero efectiva. En lugar de almacenar directamente las inscripciones en la cadena de bloques de Bitcoin, se propone utilizar un sistema de almacenamiento distribuido respaldado en la red de mensajería de Nostr. La red principal de Bitcoin se utilizaría únicamente para verificar la propiedad actual del NFT en cuestión, reduciendo significativamente la carga en la cadena de bloques.
Las implicaciones de su puesta en marcha han puesto en duda las premisas del concepto de la Web3, concepto acuñado originalmente por los fundadores de Ethereum, entre los que se destacan Gavin Wood como el autor principal de la idea de la "Web Descentralizada basada en Contratos Inteligentes". Básicamente, pretendían reemplazar la infraestructura de la computación en la Nube centralizada por la capacidad de ejecutar contratos inteligentes de los nodos de la blockchain Ethereum mediante las DApps.
La Blockchain no es “Backend”
El problema con esa idea de la Web3 es que se ignoraron detalles técnicos que comprometen la escalabilidad de los sistemas de cómputo. Las blockchain se diseñaron específicamente para la tarea de evitar el doble gasto en libros contables distribuidos, de manera que un conjunto masivo de nodos pueda llegar a un consenso verificando una secuencia de operaciones financieras ejecutadas en un orden establecido. La naturaleza rigurosa de tales procesos requiere que todos los nodos almacenen la misma información de manera redundante, replicando el estado del programa. Eso también implica limitaciones para la ejecución en paralelo al tener que verificar un programa Turing Completo en todas sus etapas.
Dados los altos costos de operación de las aplicaciones blockchain, los nodos que validan los contratos inteligentes deben cobrar tarifas basadas en la cantidad de procesamiento y el uso de recursos como el almacenamiento.
Por otro lado, los proveedores de cómputo en los ecosistemas blockchain no compiten en un mercado por obtener el favor de sus clientes, sino operan para obtener el favor de un Algoritmo o Protocolo de consenso que reparte beneficios a aquellos que logran aventajar al resto por ejecutar la misma cantidad de tareas.
Y por ende tales protocolos deben imponer cargas de trabajo adicionales que fomenten esa competitividad como pruebas criptográficas de trabajo que requiere un consumo intensivo de energía (Proof of Work). O bien, se favorece a aquellos que concentren la mayor cantidad de tokens dispuestos a arriesgarlos por el cumplimiento de sus compromisos (Proof of Stake).
Tal circunstancia conlleva a un problema de incentivos económicos, donde el beneficio de los operadores de la red no puede coincidir con el mejoramiento de la calidad del servicio ofrecido a los usuarios. Por el contrario, se fomenta un conflicto de intereses y competitividad entre prestadores del servicio y sus clientes.
Esto sucede debido a que los precios de las transacciones son fijados de manera artificial por el protocolo, y que tales precios se respaldan con relación a la cotización de un token que está sujeto a presiones especulativas de mercados de inversión. En consecuencia, las partes interesadas inflarán el coste de sus operaciones para maximizar su beneficio. Además, estarán dispuestas a favorecer la congestión, ya que esto también les reportará beneficios.
Entonces podemos afirmar que los proyectos de redes sociales basados en blockchain están condenados a fracasar porque no mejoran la experiencia del usuario respecto de las plataformas existentes basadas en la nube centralizada. Protocolos como LENS, Steemit o BOS cometen el error de sobrecargar a los nodos validadores de la blockchain con tareas de almacenamiento e interacción que deberían realizarse en servidores de la web.
Una Arquitectura basada en la Persistencia de Mensajes
El proyecto Nostr fué concebido para romper con el patrón que afecta a las aplicaciones de la blockchain, desvinculando el juego económico de los protocolos de consenso criptográfico del desempeño de los servicios de cómputo. En cambio, Nostr promueve la colaboración espontánea y se acerca más a un mercado libre real, en el que los proveedores están motivados a responder a la demanda de manera flexible, asignando sus recursos según convenga.
La realidad es que el precio de los recursos computacionales es variable y depende de las circunstancias del mercado, pero siempre tiende a la baja. Con el tiempo, los proveedores se especializarán en mejorar su eficiencia y ofrecer servicios de mayor calidad a precios más bajos. Esta dinámica responde a la competencia constante por atraer más clientes y posicionarse de manera sólida en el mercado.
No obstante, hay que aclarar que Nostr aún no proporciona algún mecanismo económico pre-establecido para compensar a los involucrados que respaldan la infraestructura computacional. Asume que los operadores colaboran en la red de manera voluntaria, y deja abierta la posibilidad de desarrollar mecanismos de compensación a través de propinas (Zaps).
En próximas entregas, explicaremos los aspectos claves para la escalabilidad de la red y el entorno de desarrollo.