Structure determines function: an analysis comparing AO and Nostr

AO is hyper-parallel computing, Nostr is a decentralized social protocol, how to compare? What is their respective positioning and development path?

When you see the title, you may feel strange: AO stands for hyper-parallel computing, and Nostr is a decentralized social protocol. These two seem to belong to completely different fields and are not easy to compare. However, if we go deeper into the level of technical implementation, we will find that they are essentially "message transmission protocols", so they are comparable.

As a message transmission protocol, the core element is naturally the "message" itself, and everything revolves around the transmission of messages.So in the AO and Nostr networks, how are their respective messages defined? How is their network architecture to support message transmission built? How can they be integrated with other protocols? What are their respective positioning, main application scenarios, and development trends?

This article aims to compare the two protocols, AO and Nostr, in depth, focusing on the impact of protocol structure on functionality, and conducting detailed analysis around the above issues.

The concept and characteristics of messages

Messages in AO

In the AO network architecture, a message is the basic unit of information transmitted between network units (MU, SU, CU) or between processes. They achieve information exchange and collaboration by sending and receiving messages.

AO is designed as a message-driven asynchronous communication network. First, AO needs messages to drive when starting work (starting a process), and these messages can come from external users or other processes. Second, AO's inter-process communication is asynchronous, which means that the sending and receiving of messages is independent of the operations of the sender and the receiver. The process sending the message does not need to wait for the response or confirmation of the receiver and can continue to perform other operations immediately. This feature significantly improves the efficiency of AO parallel computing.

In the AO network, the asynchronous transmission and no-waiting characteristics of messages make it ideal for handling large-scale parallel computing tasks, because it allows various parts of the system to execute in parallel without waiting for a long time for the response of other processes.

In AO, each message follows the ANS-104 standard of the Arweave ecosystem, which is a data packaging protocol. ANS-104 significantly improves the throughput of data reading and writing by serializing multiple transactions into a native transaction in binary. This protocol is not just a simple data packaging, but also adds fields such as owner, signature, target address, label, data, etc. to the packaged data. This design enables ANS-104 to support a variety of data types, including documents, pictures, audio and video, games, data models, program code, and holographic states. In addition, it also supports data ownership and signature verification, providing guarantees for the security and integrity of data.

These features of the ANS-104 standard are particularly important to AO because they enable AO to build diverse application scenarios for different data types. The unified message format also greatly promotes efficient communication and seamless collaboration between processes, and can also improve the efficiency of storage and settlement processing on Arweave, allowing AO to effectively build a data availability layer and data consensus to support its wide range of application needs.

Event in Nostr

In the Nostr protocol, a standard message format based on the JSON structure definition 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 commonly followed standard called the NIPs (Nostr Implementation Possibilities) protocol standard. This consistency and standardization greatly improves the efficiency of data processing and management, and helps to enhance the interoperability and stability of the system. With 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. This structure contains different fields, each of which has a different function. For example:

• pubkey field: represents the public key of the user who sent the event, which is used to identify the user. This public key will be used to digitally sign the event to ensure the authenticity and integrity of the event.

• kind field: is used to indicate the type of event. It can represent different message types, such as chat room messages, wallet information, etc., or it can represent specific user behaviors, such as recommending a relay list, performing an action, etc.

• content field: contains the specific content of the event. This field supports a variety of data types, such as social media posts, papers, audio and video, etc. Users can express the 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 then verified by the recipient's client using the corresponding public key. The signature ensures that the user with the corresponding public key actually sent the event on a specific date, thereby enhancing the credibility and verifiability of the event.

• ……

For a detailed description of the event data structure, see: https://nostr.how/zh/the-protocolcontent. 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 data.

All fields are combined to express a complete event that plays a specific role. In general, an event is a data structure that contains arbitrary content and is signed by the user. This structure reflects the positioning, characteristics and role of Nostr:

• Nostr is an information publishing, storage and receiving system. Nostr has established an efficient data exchange and management framework by adopting JSON structure and NIPs protocol standards, ensuring the consistency and parsability of information, and providing users with a stable, reliable and unified information communication environment;

• Support client verification: This data structure supports verification on the client, so there is no need to trust any relay server or third party, and the authenticity and integrity of the event can be directly verified.

• Build a decentralized, censorship-resistant, and verifiable social network: The characteristics of this data structure allow Nostr to serve as a decentralized platform where users can freely communicate and share information without worrying about censorship or information tampering.

Network structure that supports message transmission

AO: MU/SU/CU form a collaborative network

The AO network consists of three modular basic units: MU, SU, and CU, and runs and collaborates through messages and processes. Its network architecture is shown in Figure 1-1.

Figure 1-1: Modular and cooperative network units form the network architecture of AO (Picture from AO White Paper)

Process is the computing unit in the AO network. Starting an application on AO is equivalent to starting one or more processes. The system will allocate and schedule resources for each process, such as MU, SU, CU, virtual machine, memory, etc., to execute the process:

• MU (Messenger Unit): This is the messenger unit, responsible for sending information to the appropriate SU for processing, and then delivering it to the CU for calculation. The calculation result is returned to the SU, and the messenger unit repeats this process continuously;

• SU (Scheduler Unit) CU (Compute Unit): This is the scheduling unit, which is responsible for scheduling and message sorting, and uploading messages to Arweave; CU (Compute Unit): This is the computing unit, which receives messages, performs calculations, and realizes state transitions. As mentioned above, the network structure and operation mode of AO show that: AO is a message transmission system. Messages are the core elements of the process and the only working objects of MU, SU and CU. The entire process revolves around messages. A process is the running activity of a message collection, which includes the complete process from receiving messages, message transmission, message scheduling and sorting, performing calculations (message state transitions), and outputting and storing calculation results.

  So AO is a message transmission system that can be dedicated to building applications in information publishing, real-time communication and interaction, content distribution, etc., such as decentralized social networks, social media, and decentralized audio and video on-demand/live broadcast platforms.

  • AO is a super-parallel computing network

  AO is a modular network in which calculations are performed off-chain and are not constrained by block consensus, allowing computing units (nodes) to be infinitely expanded as needed, thereby greatly improving computing performance.

  In the AO environment, any number of computing tasks (parallel processes) can be started at the same time, and these processes can run independently on different computing nodes and complete verification locally. This makes AO a distributed, verifiable super-parallel computer.

  Although each computing process can run independently on different nodes, they can communicate and collaborate through a unified information format (ANS-104). This method connects independently running computing processes together to form a unified network.

  • AO is an open platform

  The core of AO is a message 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, use AO for combinatorial operations, and realize cross-chain information exchange.

  The AO network runs off-chain and can be seamlessly connected with Web2 applications. By calling the AO protocol interface, Web2 applications can participate in this decentralized network. This feature enables AO to eliminate the barriers between Web2 and Web3 applications and realize trusted information exchange and interoperability between applications. AO's communication protocol design mechanism makes it an open platform, bringing unlimited possibilities to developers.

  In summary, AO's network architecture supports it to become a composable, interoperable, scalable, verifiable, decentralized and open computer network platform. It is not only suitable for social applications with the theme of information publishing and communication interaction, but also can support applications with higher computing performance requirements and more complex business logic, such as machine learning, autonomous decision-making agents, graphics rendering, online games and DeFi applications.

  Nostr: Client-Relay Structure

  Nostr is the abbreviation of "Notes and Other Stuff Transmitted by Relays", which means "transmitting notes and other content through relays". There are two main components in the network, and its network structure is shown in Figure 1-2.

  

  Figure 1-2 Nostr's network structure

  • Client

  This is an application running on the user side, used to read and write data to the relay server. The client uses the public key as the address for the user to send and receive events, and the private key is used to sign when sending events to prove that it is the user's own operation and prevent tampering. When receiving events, the client uses the private key to verify the signature to confirm the source and integrity of the event.

  The client allows users to connect to any number of relay servers distributed in different locations. Users can publish information on one relay and retrieve information on another relay. This means that clients (users) do not have to rely on any specific relay server, thereby effectively protecting user data and behavior.

  • Relay Server

  The relay server has the ability to listen to, capture and store events of clients connected to it, and forward these events to subscribed clients.

  Anyone can run a relay server, and multiple relay servers can replace each other. This design weakens the importance of a single relay, reduces the risk of single point failure, and improves anti-censorship capabilities. In addition, competition between multiple relays can promote the improvement of service quality, such as providing larger storage capacity, faster response speed, and spam filtering services.

  The relay server can choose to store all or part of the user's content according to its own needs, and decide the length of storage time, which provides greater flexibility for the positioning and business behavior of the relay. At the same time, there is no need for relay servers to communicate with each other, so there is no consensus problem and no need for data synchronization. Data synchronization is achieved by sending and receiving events between clients, which is fundamentally different from blockchain nodes.

  Such an architecture can not only improve the flexibility and efficiency of the system, but also effectively respond to different usage scenarios and needs.

  It can be seen that Nostr adopts a lightweight network structure such as Client-Relay, which can not only improve the flexibility and efficiency of the system, but also effectively support the construction of a decentralized, censorship-resistant, and verifiable information publishing system to meet people's needs for freedom of speech, smooth communication, and data security and privacy control. This design effectively responds to the challenges and drawbacks brought by centralized social media. Therefore, Nostr is known as a decentralized social protocol and is widely favored by developers for building various decentralized social applications, such as Damus, YakiHonne, Iris, etc.

  Integration with other protocols

  AO+Arweave: Decentralized World Computer

  AO runs on Arweave and achieves seamless integration with Arweave, as shown in Figure 3-1.

  

  Figure 3-1 Seamless integration of AO and Arweave (picture from AO white paper)

  This is an implementation of the Storage Consensus Paradigm (SCP). In this innovative paradigm, storage (consensus) and computing are effectively separated, making off-chain computing and on-chain consensus possible. This architecture brings obvious advantages:

  • High-performance computing: The calculation of smart contracts is executed off-chain and is no longer subject to the block consensus process on the chain, which greatly expands the computing performance and makes high-performance computing feasible.

  • Hyper-parallel computing: Each process on different nodes can independently perform parallel computing and local verification without waiting for all nodes to complete repeated calculations and global consistency verification as in the traditional EVM architecture. This design enables AO to achieve super-parallel computing.

  • Custom computing:Arweave provides AO with permanent storage of all instructions, intermediate states, and calculation results, as AO's data availability layer and consensus layer. The execution of each application (smart contract) is closely related to the data stored in Arweave, and the computing logic and data resources can be customized according to the needs of the application to be executed on the local node. This flexibility far exceeds the traditional EVM model, where all nodes must simultaneously execute predefined operations in pursuit of the consistency of the entire network state.

  To summarize, AO adds a super-parallel computing layer to Arweave, while Arweave provides AO with storage-as-consensus support. The combination of the two creates a decentralized world computer, opening up a vast space for application innovation in the decentralized world.

  Nostr + Lightning: Building a decentralized information

  and valuenetwork

  Because Nostr's developer fiatjaf is also the developer of the Lightning Network, Nostr natively supports the Lightning Network. The Lightning Network is a second-layer solution for the Bitcoin blockchain that extends the functionality of the blockchain off-chain by using channels. It effectively solves the problems of slow Bitcoin transaction speed, limited throughput and high transaction costs, making high-frequency and low-cost Bitcoin micropayments possible.

  One ​​of the most direct applications of Nostr's combination with Lightning Network is to implement "lightning" in social applications. Nostr's popular client Damus has built-in Bitcoin Lightning Network payment function. Users only need to fill in Nostr's public key to easily call the Lightning Network to pay the one-time fee of Relay. After the payment is completed, the user will receive a Lightning Network invoice. For its detailed workflow, please refer to: https://nostr.how/zh/zaps, where the operation steps are explained in detail.

  In terms of asset issuance, Taproot Assets (TAP), an asset issuance protocol on Bitcoin's first layer, is compatible with the Lightning Network. It can introduce Taproot assets and Satoshis, the smallest unit of Bitcoin, into the Nostr ecosystem and use the Lightning Network for instant and affordable asset transfers. This not only enriches Nostr's asset types, but also provides more possibilities for application scenarios such as social networks, payments and DeFi.

  In addition, members of the CKB community have proposed the Nostr binding protocol, which uses RGB++ technology to isomorphically bind Nostr Event to CKB CELL. This move allows users to create and distribute native assets in the Nostr social network, effectively solving the native payment problem in social networks.

  More importantly, the combination of Nostr and Lightning Network is opening up a new business model for decentralized applications, namely V4V (Value 4 Value).

  The concept of V4V believes that monetizing non-scarce information is a very difficult task. The default monetization model in the traditional online world usually relies on advertising, which relies heavily on centralized monitoring and user behavior analysis. V4V provides an alternative that allows 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 way to create content and transfer value.

  V4V's solutions are bringing innovative value to social applications, podcasts and live broadcast platforms built on Nostr, such as:

  • YakiHonne, a decentralized media information exchange protocol, supports the integration of Nostr and the Lightning Network, using SATS as reward payment, with a total payment of more than 90 million SATS throughout the year.

  • Nostrwatch.live is a decentralized live broadcast platform running on Nostr and the Lightning Network, building a "Value for Value" two-way stream value exchange platform. When the player sends a live media stream to the audience, it also receives a SATs payment stream from the audience. Once the payment stops, the streaming signal stops playing. This is different from the traditional prepaid model, and the audience does not need to subscribe or pay in advance.

  • Podverse is a Podcasting 2.0 app that integrates with Alby and uses the Lightning Network to send boostagrams (a donation method for sending messages to creators) and sat payment streams to podcasts. When "streaming Satoshis" in Podverse, the app sends Satoshis to the podcast the user is listening to for every minute of listening time.

  It can be seen that through the combination of Nostr and Lightning, Nostr has gradually evolved from a decentralized information transmission network to a decentralized transmission network that integrates information and value. This evolution not only protects personal 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 innovation in scale and consumer applications, and may become a viable path to achieve large-scale adoption of Web3.

  Summary: Structure determines function

  In the above, we mainly compared and analyzed the AO and Nostr protocols from the two aspects of data structure and network structure, and based on the principle of "structure determines function", we deeply analyzed 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 have some similarities. They are both information transmission protocols that support information publishing, communication interaction and content distribution of various data types, and can build decentralized social networks and decentralized social media applications. In addition, they both have the functional characteristics of decentralization, anti-censorship, 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 above-mentioned applications, which are only a small subset of the functions and applications supported by the AO data structure. The focus of the AO protocol is to support hyper-parallel computing, and its application areas are broader and more far-reaching.

  • From the perspective of network structure

  From the perspective of network structure, the AO protocol has modular, mutually cooperative and scalable network units, allowing processes to run independently on different nodes and perform local verification. These features provide the basic conditions for realizing hyper-parallel computing.

  At the same time, the AO protocol breaks through the impossible triangle limitations of blockchain technology through seamless integration with Arweave based on the SCP paradigm. It can infinitely expand storage resources and computing resources according to demand, and use the consensus data with ownership protection permanently stored by Arweave to exchange information and collaborate between any processes (applications). Therefore, the AO protocol can build a high-performance, ultra-parallel computing network for the world, bringing innovation space to 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 requirements 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 information communication, cross-chain asset flow, cross-chain data sharing, and cross-chain interoperability of smart contracts.

  In contrast, the Nostr protocol is mainly composed of two network components, Cliet-Relay, Event data structure, and public-private key system. It establishes a lightweight information publishing and receiving network. When the Nostr protocol is integrated with Lightning, the entire network combines the characteristics of decentralized information network and decentralized value network, which is more suitable for building a large-scale, consumer-level application network.

  • From the perspective of protocol positioning

  From the perspective of protocol positioning, although AO and Nostr are both messaging protocols, their positioning and focus are different. The main focus of the AO protocol is to build infrastructure such as the "decentralized world computer", positioning the lower layer, but it opens up a broad space to support various applications, can capture a wider range of value, and bring the power of continuous upward development.

  In contrast, the Nostr protocol was originally designed to support social applications and is positioned as a lightweight decentralized social protocol with more specific and focused application scenarios.

  In summary, AO and Nostr have their own characteristics and advantages in data structure, network structure and protocol functions, and have different positioning and applicable scenarios. They will show their respective potential and value on different development paths.