Structure Determines Function: A Comparative Analysis of AO and Nostr
How do AO, which is ultra-parallel computing, and Nostr, which is a decentralized social protocol, compare? What are their respective positions and development paths?
You might find the title strange: AO stands for ultra-parallel computing, while Nostr is a decentralized social protocol. These two seem to belong to completely different fields, making comparison difficult. However, if we delve into the technical implementation, we find that they are essentially both "message transmission protocols," which makes them comparable.
As message transmission protocols, the core element is naturally the "message" itself, and everything revolves around the transmission of messages. So how are messages defined in the AO and Nostr networks? How is the network architecture supporting message transmission built? How do they integrate with other protocols? What are their respective positions, main application scenarios, and development trends?
This article aims to deeply compare the AO and Nostr protocols, focusing on the impact of protocol structure on functionality and providing a detailed analysis around the above questions.
1. The Concept and Characteristics of Messages
1. Message in AO
In the AO network architecture, a message is the basic unit of information transmitted between various network units (MU, SU, CU) or between different processes. They achieve information exchange and collaboration by sending and receiving messages.
AO is designed as a message-driven asynchronous communication network. First, AO requires messages to drive the startup of work (starting a process), and these messages can come from external users or other processes. Second, inter-process communication in AO is asynchronous, meaning that the sending and receiving of messages are independent of the operations of the sender and receiver. The process sending the message does not need to wait for a response or confirmation from the receiver and can immediately continue executing other operations. This feature significantly enhances the efficiency of parallel computing in AO.
In the AO network, the asynchronous transmission of messages and the lack of waiting make it an ideal choice for handling large-scale parallel computing tasks, as it allows various parts of the system to execute in parallel without long waits for responses from other processes.
In AO, each message adheres to the ANS-104 standard of the Arweave ecosystem, which is a data packaging protocol. ANS-104 significantly improves the throughput of data read and write by serializing multiple transactions into a single native transaction in binary form. This protocol is not just simple data packaging; it also adds fields such as owner, signature, target address, label, and data within the packaged data. This design allows ANS-104 to support various data types, including documents, images, audio and video, games, data models, program code, and holographic states. Additionally, it supports data ownership and signature verification, ensuring the security and integrity of the data.
These features of the ANS-104 standard are particularly important for AO, as they enable AO to establish diverse application scenarios for different data types. A unified message format also greatly facilitates efficient communication and seamless collaboration between processes, while improving the efficiency of storage and settlement processing on Arweave, allowing AO to effectively build data availability layers and data consensus to support its wide application needs.
2. Event in Nostr
In the Nostr protocol, a standard message format based on JSON structure is used to describe various types of data. This message format is called an event, which is the basic data object in the Nostr network.
The most commonly used message structures are being integrated into a common standard known as the NIPs (Nostr Implementation Possibilities) protocol standard. This consistency and standardization greatly enhance the efficiency of data processing and management, helping to improve the system's interoperability and stability. Through NIPs, users can perform various operations and interactions in the Nostr network without worrying about differences or incompatibilities in data formats.
The JSON structure is used to define the event data format in the Nostr protocol, which includes different fields, each serving different purposes. For example:
- pubkey field: Represents the public key of the user sending the event, used to identify the user's identity. This public key will be used to digitally sign the event to ensure its authenticity and integrity.
- kind field: Used to indicate the type of event. It can represent different message types, such as chatroom messages, wallet information, etc., or specific user behaviors, such as recommending relay lists or executing certain operations.
- content field: Contains the specific content of the event. This field supports various data types, such as social media posts, papers, audio and video, etc. Users can express various information and data they want to convey here.
- sig field: Used to store the digital signature of the event. This signature is generated by the sender using their private key and is then verified by the receiver's client using the corresponding public key. The signature ensures that the user with the corresponding public key indeed sent the event on a specific date, enhancing the credibility and verifiability of the event.
- ……
A detailed description of the event data structure can be found at: https://nostr.how/zh/the-protocol. The Nostr protocol provides a clear framework for sending, receiving, and verifying events through these fields and structures. This design helps ensure the security, consistency, and reliability of the data.
All fields combine to express a complete event that serves a specific function. In summary, an event is a data structure containing arbitrary content and signed by the user, reflecting Nostr's positioning, characteristics, and functions:
- Nostr is a system for publishing, storing, and receiving information. By adopting the JSON structure and NIPs protocol standard, Nostr establishes an efficient framework for data exchange and management, ensuring the consistency and parseability of information, providing users with a stable, reliable, and unified information communication environment;
- Supports client verification: This data structure supports verification on the client side, so there is no need to trust any relay server or third party, allowing direct verification of the authenticity and integrity of events.
- Builds a decentralized, censorship-resistant, verifiable social network: The characteristics of this data structure enable Nostr to serve as a decentralized platform where users can freely communicate and share information without worrying about censorship or information tampering.
2. Network Structures Supporting Message Transmission
1. AO: MU/SU/CU Forming a Collaborative Network
The AO network consists of three modular basic units: MU, SU, and CU, which operate and collaborate through messages and processes, as shown in Figure 1-1.
Figure 1-1: Modular and collaborative network units form the network architecture of AO (Image from AO white paper)
A process is the computational unit in the AO network. Starting an application on AO is equivalent to starting one or more processes, and the system allocates and schedules resources for each process, such as MU, SU, CU, virtual machines, memory, etc., to execute that process:
- MU (Messenger Unit): This is the messenger unit responsible for sending information to the appropriate SU for processing, then delivering it to the CU for computation, with the computation results returned to the SU. The messenger unit continuously repeats this process;
- SU (Scheduler Unit): This is the scheduling unit responsible for scheduling and message ordering and uploading messages to Arweave;
- CU (Compute Unit): This is the computing unit that receives messages, performs computations, and achieves state transitions.
As described above, the network structure and operation of AO indicate that:
- AO is a message transmission system.
Messages are the core element in processes and the only working object of MU, SU, and CU. The entire process revolves around messages, and the process is the operational activity of a collection of messages, encompassing the complete process from receiving messages, message transmission, message scheduling and ordering, executing computations (message state transitions), to outputting and storing computation results.
Thus, AO is a message transmission system that can focus on building applications related to information publishing and real-time interactive communication, content distribution, and more, such as decentralized social networks, social media, and decentralized audio and video on-demand/live streaming platforms.
- AO is an ultra-parallel computing network.
AO is a modular network where computations are performed off-chain, unconstrained by block consensus, allowing computing units (nodes) to scale infinitely as needed, greatly enhancing computational performance.
In the AO environment, any number of computational tasks (parallel processes) can be initiated simultaneously, and these processes can run independently on different computing nodes and complete verification locally. This makes AO a distributed, verifiable ultra-parallel computer.
Although each computational process can run independently on different nodes, they can communicate and collaborate through a unified information format (ANS-104). This method connects independently running computational processes together, forming a unified network.
- AO is an open platform.
At its core, AO is an information protocol that allows different applications running on Arweave to communicate with each other. Each application can send information to other applications through the AO network, utilizing AO for combinatorial operations and enabling cross-chain information exchange.
The AO network operates off-chain, allowing seamless connections with Web2 applications. By calling the AO protocol interface, Web2 applications can participate in this decentralized network. This feature enables AO to eliminate barriers between Web2 and Web3 applications, achieving trustworthy information exchange and interoperability between applications. The design mechanism of AO's communication protocol makes it an open platform, bringing infinite possibilities for developers.
In summary, the network architecture of AO supports it in becoming a composable, interoperable, scalable, verifiable, decentralized, and open computing network platform. It is suitable not only for social applications focused on information publishing and interactive communication but also supports applications with higher computational performance requirements and more complex business logic, such as machine learning, autonomous decision-making agents, graphics rendering, online gaming, and DeFi applications.
2. Nostr: Client-Relay Structure
Nostr stands for "Notes and Other Stuff Transmitted by Relays." The network has two main components, and its network structure is shown in Figure 1-2.
Figure 1-2: Nostr's network structure
- Client
This is the application running on the user side, used to read and write data to the relay servers. The client uses the public key as the address for the user to send and receive events, while the private key is used to sign events when sending, proving that the operation is performed by the user and preventing tampering. When receiving events, the client uses the private key to verify the signature to confirm the source and integrity of the event.
Clients allow users to connect to any number of relay servers distributed in different locations. Users can publish information on one relay and retrieve information from another. This means that clients (users) do not have to rely on any specific relay server, effectively protecting user data and behavior.
- Relay Server
Relay servers have the ability to listen, fetch, and store events from connected clients and forward these events to subscribed clients.
Anyone can run a relay server, and multiple relay servers can substitute for each other. This design diminishes the importance of any single relay, reducing the risk of single points of failure and enhancing censorship resistance. Moreover, competition among multiple relays can drive improvements in service quality, such as providing larger storage capacity, faster response times, and filtering of spam.
Relay servers can choose to store all or part of the user's content based on their needs and decide how long to store it, providing greater flexibility for the positioning and commercial behavior of the relay. Meanwhile, relay servers do not need to communicate with each other, so there are no consensus issues, and data synchronization is not required. Data synchronization is achieved through the sending and receiving of events between clients, fundamentally different from blockchain nodes.
This architecture not only enhances the system's flexibility and efficiency but also effectively addresses different usage scenarios and needs.
It is evident that Nostr adopts a lightweight network structure of Client-Relay, which not only enhances the system's flexibility and efficiency but also effectively supports the construction of a decentralized, censorship-resistant, verifiable information publishing system, meeting people's needs for freedom of speech, smooth communication, and data security and privacy control. This design effectively addresses the various challenges and drawbacks posed by centralized social media. Therefore, Nostr is hailed as a decentralized social protocol and is favored by developers for building various decentralized social applications, such as Damus, YakiHonne, Iris, and more.
3. Integration with Other Protocols
1. AO + Arweave: A Decentralized World Computer
AO runs on top of Arweave, achieving seamless integration with Arweave, as shown in Figure 3-1.
Figure 3-1: Seamless integration of AO with Arweave (Image from AO white paper)
This is an implementation of the Storage Consensus Paradigm (SCP). In this innovative paradigm, storage (consensus) and computation are effectively separated, enabling off-chain computation and on-chain consensus. This architecture brings obvious advantages:
- High-performance computing: The computation of smart contracts is executed off-chain, no longer constrained by the on-chain block consensus process, significantly expanding computational performance and making high-performance computing feasible.
- Ultra-parallel computing: Various processes on different nodes can independently perform parallel computations and local verifications without waiting for all nodes to complete repetitive computations and global consistency verification as in traditional EVM architectures. This design allows AO to achieve ultra-parallel computing.
- Customizable computation: Arweave provides permanent storage for all instructions, intermediate states, and computation results, serving as the data availability layer and consensus layer for AO. The execution of each application (smart contract) is closely related to the data stored in Arweave, and the computational logic and data resources can be customized based on the needs of applications executed on local nodes. This flexibility far exceeds that of traditional EVM models, where all nodes must simultaneously execute predefined operations to pursue consistency of the entire network state.
In summary, AO adds an ultra-parallel computing layer to Arweave, while Arweave provides support for storage as consensus. The combination of the two creates a decentralized world computer, opening up vast application innovation space for the decentralized world.
2. Nostr + Lightning: Building a Decentralized Information and Value Network
Because Nostr's developer fiatjaf is also a developer of the Lightning Network, Nostr natively supports the Lightning Network. The Lightning Network is a second-layer solution for the Bitcoin blockchain that expands the blockchain's functionality off-chain using channels. It effectively addresses issues such as slow Bitcoin transaction speeds, limited throughput, and high transaction costs, making high-frequency, low-cost Bitcoin micropayments possible.
The combination of Nostr and the Lightning Network has one of its most direct applications in implementing "zaps" in social applications. The popular Nostr client Damus has built-in Bitcoin Lightning Network payment functionality, allowing users to easily call the one-time fee for the Lightning Network payment relay by simply entering the Nostr public key. After payment is completed, users receive a Lightning Network invoice. For detailed workflow, please refer to https://nostr.how/zh/zaps, which explains the operational steps in detail.
In terms of asset issuance, the Bitcoin layer asset issuance protocol Taproot Assets (TAP) is compatible with the Lightning Network, allowing Taproot assets and the smallest unit of Bitcoin, Satoshis, to be introduced into the Nostr ecosystem and enabling instant and cost-effective asset transfers using the Lightning Network. This not only enriches the types of assets in Nostr but also provides more possibilities for application scenarios such as social networks, payments, and DeFi.
Additionally, members of the CKB community have proposed the Nostr binding protocol, using RGB++ technology to create a homomorphic binding between Nostr Events and CKB CELLS. This initiative allows users to create and distribute native assets within the Nostr social network, effectively addressing the native payment issues in social networks.
More importantly, the combination of Nostr and the Lightning Network is opening up a new business model for decentralized applications, known as V4V (Value 4 Value).
The V4V concept posits that monetizing non-scarce information is a very challenging task. The default monetization model in the traditional network world typically relies on advertising, which heavily depends on centralized monitoring and user behavior analysis. V4V offers an alternative that allows for the free flow of information and value without restrictions or intermediaries. This approach is not only a new way to monetize bits and bytes online but also a new avenue for content creation and value transmission.
The V4V solution is bringing innovative value to social applications, podcasts, and live streaming platforms built on Nostr, such as:
- The decentralized media information interaction protocol YakIHONNE, which supports the integration of Nostr with the Lightning Network, using SATS as a payment for tips, with total payments exceeding 90 million SATS throughout the year.
- Nostrwatch.live is a decentralized live streaming platform running on Nostr and the Lightning Network, creating a "Value for Value" two-way flow value exchange platform. When streamers send real-time media streams to viewers, they also receive SATs payment streams from the audience. Once payments stop, the streaming signal also ceases. This differs from traditional prepaid models, where viewers do not need to subscribe or prepay in advance.
- Podverse is a Podcasting 2.0 application that can integrate with Alby, using the Lightning Network to send boostagrams (a way to donate messages to creators) and SAT payment streams to podcasts. When "streaming Satoshis" in Podverse, the application sends Satoshis to the podcast the user is listening to based on the listening time per minute.
It is evident that through the combination of Nostr and Lightning, Nostr is gradually evolving from a decentralized information transmission network to a decentralized transmission network that integrates information and value. This evolution not only protects individual speech from infringement but also ensures the security of personal assets, making it a carrier and network for value exchange. This evolution opens up new possibilities and development opportunities for scalable and consumer-grade application innovations, potentially becoming a viable path for the large-scale adoption of Web3.
4. Conclusion: Structure Determines Function
In the above text, we primarily compared and analyzed the AO and Nostr protocols from the perspectives of data structure and network structure, and based on the principle that "structure determines function," we delved into the main functions and application scenarios supported by each protocol:
- From the perspective of data structure
From the perspective of data structure, AO and Nostr protocols share some commonalities. They are both information transmission protocols that support various data types for information publishing, interactive communication, and content distribution, capable of building decentralized social networks and decentralized social media applications. Additionally, they both possess features such as decentralization, censorship resistance, signature verification, and privacy and security protection.
However, they also have significant differences. The positioning and main application scenarios of the Nostr protocol focus on the aforementioned applications, which are only a small subset of the functions and applications supported by the AO data structure. The AO protocol emphasizes supporting ultra-parallel computing, with a broader and more profound application scope.
- From the perspective of network structure
From the perspective of network structure, the AO protocol has modular, collaborative, and scalable network units that allow processes to run independently on different nodes and perform local verifications, providing the foundational conditions for achieving ultra-parallel computing.
At the same time, the AO protocol seamlessly integrates with Arweave based on the SCP paradigm, breaking through the impossible triangle limitation of blockchain technology. It can infinitely scale storage and computing resources as needed and utilize the permanently stored consensus data with ownership protection in Arweave for information exchange and collaboration between any processes (applications). Therefore, the AO protocol can build a high-performance, ultra-parallel computing network aimed at a global audience, bringing innovation space for Web3 and even Web2 applications.
For example, it supports machine learning applications that require large language models (LLMs) and high-density computing; supports AgentFi that can meet complex business logic, predefined needs, and diversified autonomous strategies; supports copyright management and creator markets (ContentFi) that emphasize data ownership and content monetization; and supports decentralized applications that require data consensus, cross-chain communication, asset cross-chain flow, data cross-chain sharing, and smart contract cross-chain interoperability.
In contrast, the Nostr protocol mainly consists of two network components, Client-Relay, and the Event data structure along with the public-private key system, establishing a lightweight network for information publishing and receiving. When the Nostr protocol integrates with Lightning, the entire network merges the characteristics of decentralized information networks and decentralized value networks, making it more suitable for building scalable, consumer-grade application networks.
- From the perspective of protocol positioning
From the perspective of protocol positioning, although both AO and Nostr are message-passing protocols, their positioning and focus differ. The AO protocol primarily focuses on building the infrastructure of a "decentralized world computer," positioning itself at a lower layer but opening up a vast space for supporting various applications, capturing broader value, and bringing continuous upward development power.
In contrast, the Nostr protocol was initially designed to support social applications, positioning itself as a lightweight decentralized social protocol, with more specific and focused application scenarios.
In summary, AO and Nostr each have their unique characteristics and advantages in data structure, network structure, and protocol functionality, with different positioning and applicable scenarios. They will demonstrate their potential and value along different development paths.
References
