A primera vista, comparar AO, un sistema informático ultra paralelo, y Nostr, un protocolo social descentralizado, puede parecer poco convencional, ya que parecen pertenecer a ámbitos completamente diferentes. Sin embargo, ambos pueden ser vistos como "protocolos de transmisión de mensajes", lo que hace posible una comparación.

Como protocolos centrados en la transmisión de mensajes, el componente central es naturalmente el “mensaje” en sí mismo. Entonces, ¿cómo se definen los mensajes dentro de las redes de AO y Nostr? ¿Cuáles son sus respectivas arquitecturas de red para soportar la transmisión de mensajes y cómo se integran con otros protocolos? ¿Cuáles son sus posiciones, casos de uso principales y tendencias futuras?

Este artículo tiene como objetivo ofrecer una comparación detallada de los protocolos AO y Nostr, examinando cómo sus diseños estructurales influyen en sus funcionalidades y proporcionando un análisis exhaustivo de estos aspectos.

1. Concepto y Características de Mensajes

1.1. Mensajes en AO

En la red AO, un mensaje es la unidad fundamental de información intercambiada entre unidades de red (MU, SU, CU) o procesos. Los mensajes facilitan el intercambio de información y coordinación.

AO está diseñado como una red de comunicación asincrónica impulsada por mensajes. Inicialmente, AO requiere mensajes para iniciar procesos (como el lanzamiento de un proceso), que pueden provenir de usuarios externos u otros procesos. Además, la comunicación entre procesos de AO es asincrónica, lo que significa que el envío y la recepción de mensajes ocurren de forma independiente del remitente y el destinatario. Esto permite que el proceso de envío continúe sin esperar una respuesta o confirmación del receptor, lo que aumenta significativamente la eficiencia de la computación paralela de AO.

En AO, la naturaleza asincrónica de la transmisión de mensajes y la falta de necesidad de esperar lo hacen ideal para gestionar tareas de computación en paralelo a gran escala. Esto permite que varios componentes del sistema operen en paralelo sin largos tiempos de espera para respuestas de otros procesos.

Cada mensaje en AO sigue el estándar ANS-104 del ecosistema de Arweave, un protocolo de empaquetado de datos. ANS-104 mejora el rendimiento de datos al serializar múltiples transacciones en una sola transacción binaria. Este protocolo no solo empaqueta datos, sino que también incluye campos como propietario, firma, dirección de destino, etiqueta y datos. Este diseño admite una amplia gama de tipos de datos, incluidos documentos, imágenes, archivos de audio y video, juegos, modelos de datos, código de programa y estados holográficos. Además, admite la propiedad de datos y la verificación de firma, garantizando la seguridad y la integridad de los datos.

Estas características del estándar ANS-104 son cruciales para AO, lo que le permite admitir diversos escenarios de aplicación para diferentes tipos de datos. Un formato de mensaje estandarizado facilita en gran medida una comunicación interprocesos eficiente y una colaboración fluida, mejorando la eficiencia de almacenamiento y procesamiento en Arweave. Esto permite que AO establezca de manera efectiva capas de disponibilidad de datos y consenso de datos, abordando sus amplias necesidades de aplicación.

1.2. Eventos en Nostr

En el protocolo Nostr, los mensajes se estructuran como "eventos" utilizando un formato basado en JSON. Este formato sirve como el objeto de datos fundamental dentro de la red Nostr.

Las estructuras de mensajes ampliamente utilizadas se integran en un estándar común llamado el protocolo NIPs (Nostr Implementation Possibilities). Esta estandarización mejora enormemente el procesamiento y la gestión de datos, mejorando la interoperabilidad y estabilidad del sistema. A través de NIPs, los usuarios pueden realizar diversas operaciones e interacciones en la red Nostr sin preocuparse por las inconsistencias en el formato de datos.

La estructura JSON en Nostr define el formato del evento con varios campos, cada uno con una función específica. Por ejemplo:

• Campo pubkey: Representa la clave pública del remitente del evento, utilizada para identificar al usuario. Esta clave pública firma digitalmente el evento, garantizando su autenticidad e integridad.
• Campo tipo: Indica el tipo de evento, como mensajes de chat, información de la billetera o acciones de usuario como recomendar listas de retransmisión o realizar operaciones específicas.
• Campo de contenido: Contiene el contenido del evento, admite varios tipos de datos como publicaciones en redes sociales, artículos, audio y video. Este campo permite a los usuarios transmitir la información que desean compartir.
• Campo sig: Almacena la firma digital del evento, creada por el remitente usando su clave privada y verificada por el cliente del destinatario usando la clave pública correspondiente. Esta firma confirma la autenticidad e integridad del evento.

Para obtener una descripción detallada de la estructura de datos del evento, consulteContenido del Protocolo Nostr. El protocolo Nostr ofrece un marco claro para enviar, recibir y verificar eventos, garantizando la seguridad, consistencia y fiabilidad de los datos.

En resumen, un evento en Gate es una estructura de datos que incluye cualquier contenido y está firmada por los usuarios. Esta estructura destaca el papel, las características y las funciones de Gate:

• Publicación, Almacenamiento y Recepción de Información: El uso de JSON y NIPs de Nostr proporciona un marco eficiente para el intercambio y la gestión de datos, asegurando consistencia e interpretabilidad, y ofreciendo un entorno de comunicación estable y fiable.
• Verificación del lado del cliente: La estructura de datos permite la verificación en el lado del cliente, eliminando la necesidad de confiar en servidores de retransmisión o terceros, y confirmando directamente la autenticidad e integridad de los eventos.
• Red social descentralizada y resistente a la censura: El diseño permite que Nostr funcione como una plataforma descentralizada donde los usuarios pueden comunicarse y compartir información libremente sin preocupaciones sobre la censura o la manipulación de datos.

2. Estructuras de red que admiten la transmisión de mensajes

2.1. AO: Red de Colaboración MU/SU/CU

La red AO consta de tres unidades modulares: MU, SU y CU, que trabajan juntas a través de mensajes y procesos. Su arquitectura de red está ilustrada en la Figura 2-1.

Figura 2-1: Unidades de red modulares y colaborativas que forman la arquitectura de la red AO (Fuente: Libro blanco de AO)

En AO, un proceso es una unidad computacional. Iniciar una aplicación en AO equivale a iniciar uno o más procesos, con el sistema asignando y programando recursos como MU, SU, CU, máquinas virtuales y memoria para ejecutar el proceso:

• MU (Unidad de Mensajería): Responsable de enviar información a la SU correspondiente para su procesamiento, luego entregarla a la CU para su cálculo. Los resultados se devuelven a la SU, y este proceso se repite continuamente.
• SU (Unidad de programación): Gestiona la programación y clasificación de mensajes, cargando mensajes a Arweave.
• CU (Compute Unit): Recibe mensajes, realiza cálculos e implementa transiciones de estado.

La estructura de red y operación de AO indican:

• AO como un Sistema de Transmisión de Mensajes: Los mensajes son los elementos centrales dentro de los procesos de AO, sirviendo como los únicos objetos de trabajo para MU, SU y CU. Todo el proceso gira en torno a los mensajes, haciendo que el proceso sea esencialmente la actividad de ejecutar una colección de mensajes. Esto incluye la secuencia completa desde recibir mensajes, transmitir mensajes, programar y ordenar mensajes, ejecutar cálculos (transiciones de estado de mensajes), hasta producir y almacenar resultados de cálculos. Por lo tanto, AO es un sistema de transmisión de mensajes que puede dedicarse a construir aplicaciones enfocadas en la publicación de información, comunicación e interacción en tiempo real, distribución de contenido y más, como redes sociales descentralizadas, medios sociales y plataformas descentralizadas de audio/video bajo demanda/transmisión en vivo.
• AO como una Red de Computación Ultra-paralela: AO opera como una red modular donde los cálculos se realizan fuera de la cadena, liberados de las limitaciones del consenso de bloques. Esto permite que las unidades de cálculo (nodos) se escalen infinitamente según sea necesario, mejorando significativamente el rendimiento computacional. En el entorno de AO, se pueden iniciar un número arbitrario de tareas de cálculo (procesos paralelos) simultáneamente. Estos procesos pueden ejecutarse de forma independiente en diferentes nodos de cálculo y completar la validación local. Esto convierte a AO en un ordenador ultraparalelo distribuido y verificable.

Aunque cada proceso de computación puede ejecutarse de forma independiente en nodos diferentes, pueden comunicarse y colaborar a través de un formato de mensaje unificado (ANS-104). Este método conecta procesos de computación que se ejecutan de forma independiente en una red unificada.

• AO como una Plataforma Abierta: En su núcleo, AO es un protocolo de información que permite que diferentes aplicaciones que se ejecutan en Arweave se comuniquen entre sí. Cada aplicación puede enviar información a otras aplicaciones a través de la red AO, utilizando AO para operaciones de composición y permitiendo el intercambio de información entre cadenas. La red AO opera fuera de la cadena y puede conectarse sin problemas con aplicaciones Web2. Al invocar la interfaz del protocolo AO, las aplicaciones Web2 pueden participar en esta red descentralizada. Esta característica permite a AO tender un puente entre las aplicaciones Web2 y Web3, facilitando el intercambio de información confiable y la interoperabilidad entre aplicaciones. El diseño del protocolo de comunicación de AO lo convierte en una plataforma abierta, ofreciendo a los desarrolladores posibilidades ilimitadas.

En conclusión, la arquitectura de red de AO soporta una plataforma informática componible, interoperable, escalable, verificable, descentralizada y abierta. Es adecuada para aplicaciones centradas en la publicación e interacción de información, así como aquellas que requieren un alto rendimiento informático y lógica compleja, como el aprendizaje automático, agentes autónomos, renderizado gráfico, juegos en línea y DeFi.

2.2. Estructura Cliente-Relevador Nostr

Nostr significa 'Notas y Otros Elementos Transmitidos por Relevos'. La red consta de dos componentes principales, como se muestra en la Figura 2-2.

Figura 2-2: Estructura de la Red Nostr

• Cliente: Esta es una aplicación que se ejecuta en el extremo del usuario, diseñada para leer y escribir datos en servidores de retransmisión. El cliente utiliza una clave pública como la dirección para que el usuario envíe y reciba eventos, mientras que la clave privada se utiliza para firmar eventos cuando se envían. Este proceso de firma demuestra que la operación fue realizada por el usuario y evita la manipulación. Al recibir eventos, el cliente utiliza la clave privada para verificar la firma, asegurando el origen e integridad del evento.

El cliente permite a los usuarios conectarse a cualquier cantidad de servidores de retransmisión ubicados en diferentes lugares. Los usuarios pueden publicar información en un servidor de retransmisión y recuperarla desde otro. Esto significa que el cliente (usuario) no tiene que depender de ningún servidor de retransmisión específico, protegiendo efectivamente los datos y acciones del usuario.

• Servidor de retransmisión: Un servidor de retransmisión tiene la capacidad de escuchar, capturar y almacenar eventos de clientes conectados, y luego reenviar estos eventos a clientes suscritos. Cualquiera puede ejecutar un servidor de retransmisión, y varios servidores de retransmisión pueden servir como alternativas entre sí. Este diseño disminuye la importancia de cualquier retransmisión individual, reduciendo el riesgo de puntos de falla individuales y mejorando la resistencia a la censura. Además, la competencia entre múltiples retransmisiones puede impulsar mejoras en la calidad del servicio, como ofrecer una mayor capacidad de almacenamiento, tiempos de respuesta más rápidos y servicios de filtrado de spam.

Los servidores de retransmisión pueden optar por almacenar todo o parte del contenido de un usuario según sus propias necesidades y decidir la duración durante la cual se almacenarán los datos. Esto proporciona una mayor flexibilidad en la posición y actividades comerciales de la retransmisión. Al mismo tiempo, no es necesario que los retransmisores se comuniquen entre sí, lo que elimina problemas de consenso y la necesidad de sincronización de datos. En su lugar, la sincronización de datos se logra a través del envío y recepción de eventos entre clientes, lo que es fundamentalmente diferente de los nodos de blockchain.

Esta arquitectura no solo mejora la flexibilidad y eficiencia del sistema, sino que también aborda de manera efectiva varios casos de uso y demandas.

En resumen, la estructura Cliente-Relay ligera de Nostr mejora la flexibilidad y eficiencia del sistema. Admite un sistema de publicación de información descentralizado, resistente a la censura y verificable, que satisface las necesidades de libertad de expresión, comunicación fluida, y seguridad y privacidad de datos. Este diseño aborda de manera efectiva las deficiencias de las redes sociales centralizadas, convirtiendo a Nostr en una opción popular para los desarrolladores de aplicaciones sociales descentralizadas como Damus, YakiHonne, Iris y otros.

3. Integración con Otros Protocolos

3.1 AO + Arweave: La Computadora Mundial Descentralizada

Las funciones de AO se sitúan sobre Arweave, integrándose perfectamente con él como se muestra en la Figura 3-1.

Figura 3-1: Integración perfecta de AO con Arweave (Fuente: Libro blanco de AO)

Esto representa una aplicación del Paradigma de Consenso de Almacenamiento (SCP). Este novedoso paradigma desacopla de manera efectiva el almacenamiento (consenso) de la computación, facilitando cálculos fuera de la cadena junto con el consenso en la cadena. Los beneficios de este enfoque son sustanciales:

• Computación de Alto Rendimiento: Con cálculos de contratos inteligentes que ocurren fuera de la cadena, AO evita las limitaciones del consenso de bloques en cadena. Esto mejora significativamente el rendimiento computacional, haciendo de la computación de alto rendimiento una realidad.
• Computación Ultra-Paralela: Los nodos pueden ejecutar de forma independiente tareas en paralelo y realizar validaciones locales sin necesidad de que todos los nodos se sincronicen y completen cálculos redundantes, como se ve en las arquitecturas tradicionales de EVM. Esta capacidad permite a AO lograr una computación ultra-paralela.
• Cómputo personalizable: Arweave ofrece almacenamiento permanente para todas las instrucciones, estados intermedios y resultados de la computación, funcionando como la capa de disponibilidad de datos y consenso de AO. La ejecución de cada aplicación está intrincadamente ligada a los datos almacenados en Arweave, lo que permite la personalización basada en las necesidades específicas de los nodos locales. Este nivel de flexibilidad supera el modelo EVM tradicional, donde los nodos deben ejecutar operaciones predefinidas simultáneamente para mantener la consistencia en toda la red.

En esencia, AO mejora Arweave con capacidades de computación ultraparalela, mientras que Arweave proporciona a AO almacenamiento como consenso. Juntos, crean un ordenador mundial descentralizado, abriendo la puerta a una extensa innovación en el espacio descentralizado.

3.2 Nostr + Lightning: Creando redes descentralizadas de información y valor

Nostr, desarrollado por fiatjaf, admite nativamente la Lightning Network debido a la participación de fiatjaf en su desarrollo. La Lightning Network, una solución de segunda capa para Bitcoin, extiende la funcionalidad de la cadena de bloques fuera de la cadena a través de canales. Esto aborda de manera efectiva los problemas de Bitcoin relacionados con la lentitud de las transacciones, la capacidad limitada y los altos costos de transacción, lo que permite pagos frecuentes y de bajo costo.

Una aplicación directa de Nostr y la integración de Lightning Network es la implementación de "zaps" en aplicaciones sociales. El cliente ampliamente utilizado de Nostr, Damus, incorpora pagos de Lightning Network de Bitcoin, lo que permite a los usuarios hacer fácilmente un pago único por un relé de Lightning Network al ingresar una clave pública de Nostr. Después del pago, los usuarios reciben una factura de Lightning Network. Para obtener una guía detallada, visita:https://nostr.how/zh/zaps.

En cuanto a la emisión de activos, el protocolo Taproot Assets (TAP) de la capa uno de Bitcoin es compatible con la Red Lightning, lo que permite la integración de activos Taproot y la unidad más pequeña de Bitcoin, los Satoshis, en el ecosistema Nostr. Esto facilita transferencias de activos inmediatas y rentables a través de la Red Lightning, enriqueciendo la variedad de activos de Nostr y ampliando las posibilidades para las redes sociales, pagos y aplicaciones de DeFi.

Además, los miembros de la comunidad CKB han propuesto un Protocolo de Vinculación Nostr, aprovechando la tecnología RGB++ para lograr una vinculación isomórfica de los Eventos Nostr con las CKB CELLS. Esto permite a los usuarios crear y distribuir activos nativos dentro de la red Nostr, abordando de manera efectiva los desafíos de pago nativos en las redes sociales.

Crucialmente, la sinergia entre Nostr y la Red Lightning está introduciendo un nuevo modelo de negocio para aplicaciones descentralizadas conocido como Valor por Valor (V4V).

El concepto V4V sostiene que monetizar información no escasa es una tarea compleja. La monetización en línea tradicional a menudo depende de la publicidad, que se basa en el monitoreo centralizado y el análisis del comportamiento del usuario. V4V proporciona una alternativa al permitir el libre flujo de información y valor sin intermediarios ni restricciones. Este enfoque no solo ofrece una forma novedosa de monetizar contenido digital, sino que también introduce nuevos métodos para la creación de contenido y la transferencia de valor.

Las soluciones V4V están agregando un valor significativo a las aplicaciones sociales, podcasts y plataformas de transmisión en vivo basadas en Nostr, como:

• YakiHonne: Un protocolo de interacción de medios descentralizados que integra Nostr con la Red Lightning, utilizando SATS para propinas. Los pagos anuales han superado los 90 millones de SATS.
• Nostrwatch.live: Una plataforma descentralizada de transmisión en vivo que se ejecuta en Nostr y la Red Lightning, estableciendo un intercambio bidireccional de "Valor por Valor". Los transmisores reciben pagos de SATs de los espectadores en tiempo real, con la transmisión cesando si se detienen los pagos. Esto difiere de los modelos tradicionales de prepago, eliminando la necesidad de suscripción o prepago.
• Podverse: Una aplicación Podcasting 2.0 que se integra con Alby, utilizando la Red Lightning para enviar boostagrams (mensajes con donaciones) y pagos SAT a podcasts. La aplicación transmite satoshis al podcast que se está escuchando en función del tiempo de escucha por minuto.

La integración Nostr-Lightning está transformando Nostr de una red de información descentralizada en una que combina información y valor. Este cambio no solo protege el discurso individual, sino que también garantiza la seguridad de los activos personales, convirtiéndolo en un medio para el intercambio de valor. Esta evolución presenta nuevas posibilidades para aplicaciones escalables y de consumo, ofreciendo potencialmente un camino viable hacia la adopción generalizada de Web3.

4. Conclusión: la estructura determina la función

Este artículo ha analizado y comparado los protocolos AO y Nostr desde las perspectivas de la estructura de datos y la estructura de red, adhiriéndose al principio de que “la estructura determina la función”. Exploramos las funciones principales y los escenarios de aplicación de cada protocolo:

Desde la perspectiva de la Estructura de Datos: AO y Nostr funcionan como protocolos de transmisión de información que admiten varios tipos de datos para la publicación, comunicación y distribución. Permiten la creación de redes sociales descentralizadas y aplicaciones de medios con características como descentralización, resistencia a la censura, verificación de firma y protección de la privacidad.

Sin embargo, hay diferencias clave. El enfoque de Nostr se centra en aplicaciones específicamente diseñadas para la transmisión de información, que es solo un subconjunto de las capacidades funcionales y de aplicación más amplias de AO. AO enfatiza la computación ultra-paralela, abarcando una gama más amplia y profunda de aplicaciones.

Desde la perspectiva de la estructura de la red: la estructura de la red de AO es modular, colaborativa y escalable, lo que permite que los procesos se ejecuten de forma independiente en nodos diferentes y realicen validaciones locales. Estas características sientan las bases para la computación ultra paralela.

Integración sin problemas de AO con Arweave, basada en el paradigma SCP, supera el trilema de la tecnología blockchain. Escala los recursos de almacenamiento y computación según sea necesario y utiliza los datos de consenso permanentes y protegidos por la propiedad de Arweave para el intercambio de información entre procesos y la colaboración. En consecuencia, AO puede construir una red de computación global, de alto rendimiento y ultra paralela, fomentando la innovación en aplicaciones tanto de Web3 como de Web2.

Por ejemplo, AO admite aplicaciones de aprendizaje automático que necesitan grandes modelos de lenguaje (LLMs) y computación intensiva; aplicaciones AgentFi con lógica empresarial compleja, necesidades predefinidas y diversas estrategias autónomas; ContentFi para la gestión de derechos de autor y monetización de contenido; y aplicaciones descentralizadas que requieren comunicación entre cadenas, transferencia de activos, intercambio de datos e interoperabilidad de contratos inteligentes.

Por el contrario, la estructura de red de Nostr, compuesta principalmente por componentes Cliente-Relay y estructuras de datos de Eventos con sistemas de clave pública y privada, establece una red de información ligera. Cuando se combina con Lightning, integra características de red de información y valor descentralizadas, lo que lo hace ideal para aplicaciones escalables de consumo.

Desde la Perspectiva de Posicionamiento del Protocolo: Aunque tanto AO como Nostr son protocolos de paso de mensajes, su enfoque y posicionamiento divergen. AO tiene como objetivo construir infraestructura fundamental para una “computadora mundial descentralizada”, apuntando a capas inferiores pero proporcionando amplias posibilidades de aplicación y capturando un valor más amplio.

Por el contrario, Nostr fue diseñado inicialmente como un protocolo social descentralizado y ligero, centrándose específicamente en aplicaciones sociales.

En resumen, AO y Nostr ofrecen características y ventajas distintas en la estructura de datos, la estructura de red y la funcionalidad del protocolo, cada uno con posicionamientos y casos de uso diferentes. Sus atributos únicos se manifestarán en sus respectivas trayectorias de desarrollo.

Referencias

1. ¿Es AO un Ethereum Killer y cómo impulsará la nueva narrativa blockchain?
2. Protocolo AO: Supercomputadora descentralizada y sin permisos
3. Protocolo Nostr
4. Protocolo de Enlace Nostr
5. Valor4Valor
6. Protocolo Social Descentralizado Nostr y sus Aplicaciones Innovadoras

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [Gateweb3caff]. Todos los derechos de autor pertenecen al autor original [DanceChange]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
2. Responsabilidad de descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.