ao (@aoTheComputer): Anatomy of the decentralized permaweb: part three

Anatomy of the decentralized permaweb: part three In part one of this series, we explored the problems inherent with relying on a centralized convenience layer for the permaweb – gateways, bundlers, and indexing services run on the cloud. In part two, we showed that decentralized alternatives are already coming online, powered by HyperBEAM. These alternatives are verifiable, incentivized, and able to run securely even on commodity consumer hardware. In the final part, we’re going to look at how these components form together into a network using routers, and are able to be targeted based on their security properties using zones. Across the trust gradient, many types of machines can join the AO network, from enterprise-grade TEEs to $100 laptops – this is one of the reasons the topology of AO is unique and why we wanted to explain the shape of the network in long-form. On top of this diverse node set, an open service market of verifiable compute is already forming. First, we decentralize the core permaweb primitives, next we decentralize anything you can do online. Routers and zones HyperBEAM makes a machine verifiable, but does not automatically make it easy to find. How is it the case that AO is not just a collection of technically-interoperable-but-siloed nodes? That's the gap routers close. A router is the coordination layer that takes disparate HyperBEAM nodes and makes them accessible as a single network. - The Route to Decentralization Without routers, every app and SDK has to maintain its own address book. Want a bundler? Pick a URL. Want a scheduler? Pick a URL. Want a gateway? Pick a URL. Want a node with the right device set, price, latency, uptime and security posture? Without routers, you are basically now running your own off-protocol service-discovery layer. That is how decentralized systems recentralize in practice. The famous endpoint problem. Routers are the access-layer primitive that makes a heterogeneous network usable. They can select by availability, price, latency, device support, policy, stake, measurement, zone membership, reputation or whatever else the route logic exposes. In the gateway case, this already looks like load balancing across providers. In the broader AO case, it becomes the way a request finds the right kind of machine without every client hardcoding the same server forever. Zones handle the adjacent but separate problem of trust class. A zone is not a router, it’s a group of nodes that have passed a specific check. In the current PermawebOS model (in production with the bundler swarm), a zone is a measurement-backed shared identity for nodes that match an admissible template. The measurement might come from a TPM-backed LapEE, an Android-backed AndEE, or a TEE. The split is: A router answers: which node should handle this request? A zone answers: which rule admitted this node? Together they let the application ask for a staked LapEE bundler with the P4 device, or an SNP execution node with a specific commit, instead of asking whichever server you can remember the endpoint for. The trust gradient You don’t have run a TEE to do trusted compute (but it helps). Different machines are suited for different roles in the network. A bare PermawebOS kernel (your PC or a typical VPS running HyperBEAM) can cryptographically vouch for its own correctness in a way that is easy for a third party to check - NASA data or zone membership, for example. But for applications which require completeness guarantees, token balances and provably honest routing, a degree of tamper-resistence is required. For many infrastructure tasks that need more than a normal signed server but less than high-end enclave hardware, a LapEE or AndEE is likely sufficient. The cost to attack a machine with soldered RAM, secure boot, and TPM 2.0 is extremely high for such commodity hardware, and it’s these dedicated PermawebOS nodes that we’re picturing will comprise the bulk of network activity, from bundling to indexing. It’s not up to us to decide that degree or enforce hardware requirements top-down on the network, though. As the network matures, natural selection will kick in, and high-value activity will route through high-security nodes as a matter of survival. TEEs, LapEEs, and the PermawebOS We predict that the AO network of the future will be upheld by many small, cheap devices. The hardware properties of laptops and phones - thanks to their black-box design and enterprise security features - are able to conjure machines with TEE-like robustness at a fraction of the cost with Pretty Good Tamper-Resistance. To the question of what runs the permaweb, the expensive answer is scarce high-end TEE hardware. TEEs have their place, but cannot form the whole topology. It is too expensive and brittle for the everyday operator. The opposite answer – arbitrary services on any old server – is also not enough. Computation trustworthiness is a spectrum without absolutes. LapEE builds on that idea by widening the set of machines that can usefully provide computation for the permaweb: from a scarce pool of expensive, current-generation TEE hardware to ordinary consumer computers using hardware security features already present in many laptops made in the last five years. - PermawebOS LapEE Alpha LapEE – the laptop execution environment – turns a laptop into a narrow PermawebOS appliance: boot from USB, run HyperBEAM, expose a node URL, return measurement evidence. The machine is not being presented as a watertight TEE alternative, but it is at least able to reliably guarantee its security attestations. What booted? What devices are loaded? What hardware facts are available? Which zone admitted it? What policy does it satisfy? This makes LapEEs ideal as bundlers, and there is already a way to join a decentralized bundling network with just an ordinary laptop and a bootable USB image. TEEs and SNP machines are a stronger class. They belong elsewhere in the diagram: higher assurance, scarcer, more expensive, better suited for higher-value or more sensitive execution. The network should support them without mandating that every job needs them. This trust gradient is the real shape of the AO network: serving public data from one HyperBEAM node to another may be atomically verifiable, and a cheap signed node might be enough. Browser last-hop delivery is different because the browser cannot enforce all verification rules, and serving verifier code to the browser does not fix the problem if the server can also serve malicious verifier code. The permaweb should not hide those differences, it should support ways to measure and route around them. LapEEs broaden the scope of what a useful machine on AO can be while TEEs strengthen the high-assurance end. Zones describe the policies, routers make the policies usable, and payments give operators a reason to participate in the open service market. The open service market None of this works if the economics remain ad-hoc. While NASA was the first real deployment of the incentive pattern (stake AO against liveness), incentives are not just for gateways. AO ensures any service can be discovered, routed to, measured, paid, staked, and eventually penalized or deprioritized when they fail. The same direction applies to bundlers, schedulers, routers, query nodes, compute services, relays, cron, specialized GPU devices. The philosophy is that nodes do not need every possible business model burned into their core protocol. Instead they need a way to compose service, pricing, and ledger logic around the same message/path model. - Open Service Markets on AO P4, simple-pay and metering@1.0 enable a universal payment flow. A node can publish what it offers, a client can ask what a request will cost, users can pay nodes in AO, and the node can know when to execute, ensuring that the fee matches the work done. One global gas meter like Ethereum would be too limiting for a network like AO because nodes can have any property, do any job, and charge by any metric. A bundler should be able to charge by byte, a route can charge by hop, a scheduler can charge by message. That is how AO the computer becomes AO the economy. Operators do not earn because they added tokens to a pool, they earn because they provide useful work that users, apps, wallets, processes and agents choose to buy. Stable physics We are moving into a world where agents will create, read, modify, fork and deploy enormous amounts of software and data. Cyberspace is data, the world being built by agents is made of data, and the physics of that world are the rules for storing, moving, naming and transforming it. In the physics of centralized cyberspace, the floor can drop out because a company changed its API pricing. Feature sets can disappear because a bill bounced, and identity can be memory-holed because a namespace migrated. Caches lie, and gateways can be treated like the whole chain by accident. The decentralized permaweb is an attempt to give cyberspace better physics: Arweave is permanent memory, AO is verifiable computation over messages, and HyperBEAM where any service becomes self-sustaining. The underlying node set is not one kind of computer. It is miners, servers, LapEEs, AndEEs, TEEs, GPUs, phones, and laptops. AO’s alien shape makes it helpful to demystify at a topological level. The decentralized permaweb is not one machine and not one endpoint, it is a map of specialized machines with service markets that can route anything anywhere. The permaweb has been propped up by an inscrutable monolith for too long, but the tools to decentralize vital components – and apply the same logic to any internet service – are finally here. Read it on The Permaweb: https://ao.arweave.net/#/blog/decentralized-permaweb-part-three