AO - a super-parallel computer you can't imagine

Source: PermaDAO

This is a fragmentary text about technology that cannot even become an article. Let’s chat casually about AO.

Global Shared Hard Drive

I first learned about Arweave in July 2020. In the second week we The possibility of trustless computing was discussed in the coffee shop. Imagine: Arweave is the paper tape of the Turing machine. The ubiquitous state machine is the client in the user's hands. The user's operating system and all running programs will be downloaded from Arweave. Computing units are everywhere around the world, and they share a huge blockchain hard drive. All applications running under this system can obtain consensus and be detrusted.

The conclusion of the discussion was that this goal is difficult to achieve, Obviously it is impossible for giants such as Microsoft and Apple to put operating systems and applications on Arweave.

Now AO makes it possible. When Sam and I originally designed the MSG Protocol (the AO prototype), I thought it was kafka on the blockchain. However, the focus is not on providing a decentralized message queue for applications, but on replacing http communication in the C/S architecture with trustless msg communication. If both the user's request and the server's response use AO. Then we will recreate a truly decentralized Internet ecosystem on AO, just as envisioned in July 2020.

AO has great potential to move the entire Internet to Arweave. Arweave This Alexandrian library is no longer limited to storage, it not only records the past. Using AO we can record today’s stories and distribute future value in a decentralized manner.

Controversy

Recently there have been disputes about AO, mainly due to two issues:

1. How does AO achieve verifiability?

First of all, AO does not solve the issue of verifiability. Verifiability comes from Arweave’s immutable storage. Arweave stores the holographic data of each Process of AO (including the holographic data of AO itself). Anyone can restore AO and any thread on AO through holographic data. This is guaranteed by mathematics and is verifiable! This is a storage-based consensus paradigm, the SCP theory we often mention.

Key points: We know that UTXO transactions are uploaded to the chain after verification, but under the SCP paradigm, no matter whether it is good or bad data, all data is uploaded to the AR chain. This is similar to BTC's UTXO A very big difference. But don’t repeated on-chain and double-spend on-chain have verifiability? The SCP program only needs to run all the holographic transactions to verify it! If it is a duplicate transaction, it will be discarded by the SCP program.

Verifiable, the emphasis is on "can", there is no need to emphasize fast verification, light node verification, etc. If you confuse verifiable with fast verification and light node verification. There is no way to discuss AO at this point.

2. SCP applications have verifiable features, so how does AO solve the verifiable problem? Does the user need to run a full node?

When the first question is answered to a certain extent, the questioner will think that the user must calculate the entire ledger, which is too difficult. This is contrary to the problem that BTC/ETH’s Merkel tree wants to solve. Under the BTC/ETH idea, Merkel is the core of verification. Merkel’s root is uploaded to the chain through PoW, so it can be verified. Now you're telling me that AO doesn't have a Merkel tree? So the conclusion is that AO cannot be verified at all, there is no consensus, and it is a scam! So back to question 1. Generally, the questioner will ask questions in a loop on these two questions, and will not think about the design architecture and principles of AO.

Key points:AO does not solve verifiable problems, and the functions of AR and AO are completely separated! AR does immutable storage to ensure security and verifiability. There is Merkel here and there is consensus. The consensus is the data order, not the state of data calculation. AO only performs calculations on the sequential data on AR and generates status. AO cannot change the data order of AR, that is, AO cannot change the consensus. The calculated state is verified through PoW/PoS. This is an on-chain computing paradigm, which is completely different from SCP.

The function of AO is to perform calculations on immutable data and display the status of these calculations. The issue of verifiability is guaranteed by SCP, so there is no need for a Merkle tree or PoW/PoS. At this time, the questioner returned to question 1 again and could not continue thinking. If you can still think after seeing this, then please take a look at AO's practice:

AO has implemented a verifiable Token through SCP, and uses the Token's economic model to encourage everyone to provide correct data display. (Kind of like a Chainlink oracle). Remember that AO mainly does state presentation, and verifiability is not the function of AO. The Token economic model is: slash when the correct state is not presented, and incentives (mint) when the correct state is provided.

Key points

AO does not generate consensus, how to perform slash and mint action? It's very simple. AO is an SCP application. At this time, both the query status and return status events are linked to Arweave. The AO SCP program will load these two events (query and return) and calculate the mint from these two events. and slash results.

This part is easier to understand if you look at the code directly:

https://github.com/outprog/ slash-demo/blob/main/vm/vm_test.go

Conclusion

Users do not need to run a full node of the application; The service provider runs the CU (Computing Unit). AUser makes a query request to the AO, which is assigned to a specific CU through a SU (Scheduling Unit). The computing unit calculates the status according to the user's request. The status is signed by the computing node (also on the chain) and fed back to the user. If a user does not trust a single CU, he or she can initiate requests to more CUs to obtain more trusted status. The status returned by each CU is signed (verifiable) by the CU node. If CU provides incorrect status, CU's stake will be forfeited.

For specific practices, check out Sam’s X:

https://twitter.com /samecwilliams/status/1764023657058148718 .

No oracle? They are all oracles!

When data needs to interact with the blockchain, we need an oracle to attach the "oracle" to the chain. The oracles needed by the blockchain are oracles generated by multi-signatures by a group of users; the oracles oracles needed by humans come from the consensus generated by the blockchain algorithm, but when people read this consensus, a third party is often needed According to legend, this third party is generally called infura.io. We generally trust the infura’s message, but is this message true? (Will this melon stay ripe?)

infura.io:https://www.infura.io/

Note:

• The trust of BTC/ETH is only limited to the on-chain environment. It is difficult for the external environment to provide the ability to distrust. That is, when a user requests a BTC/ETH node, the status can only be obtained through the http protocol. The user cannot judge whether the requested node is trustworthy and whether the status is correct. If state verification is to be performed, the user must run a light node or a full node.

• In the AO/SCP network, the user's request needs to be signed, and the status returned by the node also needs to be signed. All records are stored on Arweave to form "holographic data", ensuring reliability. Verification. Users do not need to run any nodes to obtain trusted status. In AO/SCP mode, all information on the network is uploaded, including querying and returning request information (http requests are not uploaded). AO solves the problem of the last mile of trustlessness.

In engineering practice, AO/SCP breaks the concept of on-chain/off-chain and integrates trusted computing and oracles into a unified system. The system is decentralized and breaks the boundaries between Web2 and Web3. AO/SCP and on-chain computing are two completely different paradigms. This system may be regarded as a global computer composed entirely of oracles. The oracles presented bythe oracles are objective facts that cannot be tampered with.

Flexible verification

I don’t know when , consensus becomes a binary issue. Either there is consensus or there is no consensus. Is there no middle consensus?

This understanding is reflected in the blockchain industry. Either he is a god or he is a scumbag. Just like religious beliefs, it is either/or, water or fire are incompatible.

But AO provides a completely different consensus architecture - Arweave persistence and the SCP paradigm provide a solid consensus foundation, which is the "verifiability" we have repeatedly mentioned, but how much does it cost the application side to Verify that this consensus is flexible.

The cause of the matter is that people on X have been involved in the two types of controversies mentioned above. After a verbal battle, I finally asked how to verify msg between two AO threads. All msg are signed, so I won’t go into details here. But how does Process know that the received msg can be trusted? Below are two trust models simulated to explain this problem.

There is a computing unit CU1, in which two processes P1 and P2 are running, denoted as CU1(P1, P2).

Now there are: CU1(P1, P2) & CU2(P3, P4) & CU3(P1) & CU4(P1).

Computing target: P3 in CU2 requests P1 to provide trusted computing information.

Single trust mode

1. The code in P3 makes a calculation request to P1.

2. The SU scheduler dispatches P3’s request to CU4(P1) for calculation.

3. CU4(P1) responds to the calculation result and returns P3.

At this time, P3 fully trusts the calculation results of P1 in CU4 and continues the operation.

Multi-trust mode

1. in P3 The code issues a calculation request to P1, and P3 asks SU to allocate multiple calculation units.

2. SU assigns P3’s request to CU1(P1), CU3(P1), and CU4(P1).

3. CU1(P1), CU3(P1), CU4(P1) respond to the calculation results.

At this time, P3 has received multiple results. P3 can compare these results first and determine whether they are credible through comparison. For example, P3 requires that all nodes return exactly the same content. Alternatively, P3 requires that 2/3 of the outcomes be exactly equal.

Trust mode is just a development mode on AO. Developers can develop judgment rules based on trust requirements. P3's program can even require 100 CUs to perform calculations, and requires that the calculation results of 100 CUs are completely consistent. It all depends on how the developer implements the code in P3.

Thus, you can decide for yourself the trust model and verification payout you need. However, remember, the final consensus security is still guaranteed by Arweave’s persistence and SCP!