Appreciated Charles. We both go back to the earliest days.

There's a crazy reason behind how I understood the true importance of fully decentralizing compute. The story needs telling, so here goes. Back in 2015, I'd long shifted to being part of the early crypto scene, but maintained Fight My Monster, a venture-backed MMO game & social network I previously founded that had 3M users, which was self-sustaining financially. I'd found a long-term home working on decentralized compute, but couldn't let down the community that played the game. Fight My Monster was built in 2010-2012, using what was a completely novel architecture at the time that enabled it to scale (i.e. add massive amounts of users) at low cost, and with minimal administration. Essentially it comprised three core backend components. The first, was simple web hosting, which served the frontend game code and assets into its users' web browsers (I used a popular content distribution network). Just like the web-serving, the two other backend components had to be "horizontally scalable," which means that to support more users, and the associated compute and data, all I had to do was add more hardware, without any need to rewrite the backend software code, or perform excessive systems administration. This enabled me to scale fast in the early days, with minimal staff and financing. The second component, was a horizontally scalable game server framework called "Starburst", which was a work of love I created myself. This was built on top of an open source server that supported RTMP, an Adobe network protocol that allowed Flash media (remember that!!) assets running inside web browsers to directly talk to it. Starburst hosted game/social network logic and routed huge numbers of events being generated by the game to users in near realtime. The third component was a horizontally scalable NoSQL database called Cassandra (if you follow databases, you'll know that a modern derivative called ScyllaDB is currently doing well serving realtime AI needs). On my team, I had the only Cassandra core committer outside the company that built it. Further, I was the first serious party using the Cassandra beta in anger, and it got corrupted at 800,000 users, which was followed by a very testy 24 hours recovering the data, and bringing it back online (one moment I was going to the moon, the next moment I thought things had gone irreversibly wrong, but luckily things worked out). What was cool about Cassandra was that you could literally just add nodes (i.e. server machines with big hard drives installed) to horizontally scale its storage capacity, read throughput, and most importantly, its write throughput, which is very rare thing, and in my application absolutely crucial, because Fight My Monster generated a simply vast amount of data. Of course, another very important aspect of Cassandra was that it was fault tolerant, and I used a replication factor of 5, which meant everyone's data was very safe (or so I thought...). A replication factor of 5 meant I only needed nodes 3 online, for any specific "quorum of data," for it to be writable. Unlike a blockchain, Cassandra wasn't Byzantine Fault Tolerant, which meant that I had to manage the security of my infrastructure carefully to make sure hackers or malware didn't get in. But back then, hackers weren't interested in an MMO game/social network where most of the users were kids, and this wasn't supposed to be a general platform for others to build on. My main technical work pressure was just that the nodes hosting the database were under enormous strain owing to the amount of data being generated, and would therefore regularly blow up! This meant that I would have to login to my infra every so often, decommission broken nodes, and add new ones, which was easy enough, because the fault tolerance meant the job didn't have to be done immediately, and the "bare metal" machines involved could be orchestrated through my cloud provider... Fight My Monster used a setup years ahead of its time, and it allowed me to scale up with ease. Moreover, the fault tolerance, and the simple backend architecture with only 3 core system components, meant minimal administration and stress was involved in keeping it running. So what was the important lesson, which plays an important role in my thinking, and in ICP, to this day? You must surely have sensed that something crazy happened, and now I will share it publicly for the first time. I was traveling in Asia, as part of the "traveling circus" associated with the early core Ethereum community, visiting related parties (people often forget the importance of Asia, and China particularly, in helping support the early crypto scene) and attending Ethereum-related events, where I mainly talked about complex Computer Science techniques I had developed that I wanted to be used to make networks like Bitcoin and Ethereum scale and perform better. I don't want to drone on about "what is used to be like in crypto," but I will say that it was a magical time, and I owe a lot to early people for some amazing memories. It was also engaging, and I wasn't checking my email. Consequently, what I did not see on my travels, were email after email warning me of the fact that the credit card that was paying for Fight My Monster's Cassandra nodes had expired.... So what did the cloud operator do when I didn't respond within a few weeks (it wasn't many, but I forget the exact number). Well, they simply deleted all the nodes!!! It's hard to describe how I felt when I got back home to Palo Alto in California, and discovered what had happened. It was a mixture of shock and horror, a kind of hollow feeling in my stomach, adrenaline surges, and unfolding dread, as I worked as fast as I could to fix it, only to confirm that what had happened was irreversible. People who've been hacked in crypto will know the feeling. That was it. Fight My Monster was dead. Some part of the community even created a change dot org website pleading for it to be brought back online. Despite the loss of what it might have been worth, and the guilt, in some ways it was liberating, as I no longer had responsibility to maintain it, which probably would have done ad infinitum for the community. Plus it became a fond memory for a generation of kids and some adults that played it, before the game had a chance to grow too old and tired, and it allowed me to focus on what had become my obsession — decentralized compute networks. The lesson however was very clear to me. You can create decentralized compute infrastructure that can scale, and is fault tolerant, but if you have a single point of failure, anywhere, at any moment, it can be toast. That's why I'm always concerned when I hear about blockchains that depend on administrator keys held by the core devs, or blockchains that go down, or almost go down, when a huge chunk of their nodes are shutdown by a cloud running them, or because the cloud running them has technical problems. This problem of great fragility is vastly more prevalent than you might imagine in our industry. The learnings from the Fight My Monster disaster informed how the Internet Computer was designed. It's not only the number of nodes that matters, there are more important things. If nodes are anonymous, the number of independent parties running the bulk of them might be far less than you might think. Further, while large in number, they often turn out to be running on a small number of clouds— and even if they are owned and operated by a few different parties, the cloud might suddenly decide it doesn't want them anymore, and shut them down overnight, as Hetzner once did to a famous blockchain. What matters in practice is the number of independent parties running the nodes, and the physical and jurisdictional independence of the nodes. This simple insight is that was behind "deterministic decentralization," which will appear in new form inside the forthcoming "ICP cloud engines" extension of the Internet Computer. ICP cloud engines allow enterprises (typically) to create what is effectively an Internet Computer subnet whose configuration they themselves control, by choosing nodes to combine from a pool that acts as a marketplace. Currently there are more than 1.5k nodes waiting, and the number is growing. An engine provides a serverless cloud platform with remarkable properties. It is the ideal place for AI-built apps and services, because the has been stack designed to allow AI to generate advanced AIware software with ease, which AIware is secure and resilient. Apps are tamperproof (immune to infrastructure hacks), always-on (and thus incredibly resilient), optionally autonomous (which means there is no backdoor), digital assets native, and many other things. Engines also run e.g. the Open SaaS suite of AIware apps that can be used to run enterprises end-to-end. Cloud engines make installing and maintaining complex apps like Open CRM or Open Email as simple as installing and maintaining phone apps. Nodes are hot-swappable. That means you can change the compute replication factor, swap out the nodes for different ones, without interrupting what the cloud engine hosts, providing freedom from compute vendor lock-in, and, if you want, you can use a new class of nodes on hyperscalers, as well as traditional Internet Computer nodes, so it will function as a general compute marketplace. The cloud engine framework guides people to combine nodes that have independence, but provides flexibility that shared Internet Computer hosting doesn't have. For example, an enterprise in Germany might choose nodes that reside only in the EU, to meet GDPR requirements. However, the cloud engine console, which is autonomous, and served from the Internet Computer network, and updated by the NNS (the Network Nervous System, the world's most advanced DAO), guides users and warns them heavily if they combine nodes from the same node provider, or which are based in the same data center, say, or run by the same cloud operator. Thus, even with ICP cloud engines, the lessons of Fight My Monster live on. People will wonder why the framework pushes them so strongly to combine independent nodes, but there is a good reason, which is just as relevant for the wider blockchain community today, as it was in 2015. Looking forward to sharing cloud engines soon.

🚨 The widespread attacks against the Internet Computer continued again today, and thankfully, have failed again. The cabal's latest attack targeted the ckBTC "bitcoin twin" minting canisters. This time, they spent thousands of dollars on ICP tokens in the course of their attack, but only caused minimal disruption. What did happen: the attacks revealed the need for some useful hardening, and the NNS (i.e. the network's autonomous governance and orchestration system) took down the ckBTC canister for an upgrade. The downtime was ~1hr. Though the disruption was minimal, we must not thank the attackers for helping improve the network, because they are criminals. The attacks reveal more about who they are: 1. They are willing to throw buckets of money at their attacks, confirming they are professionals on a mission, rather than amateurs. 2. Since their attacks lack a common thread (such as trying to steal tokens), we can see their true purpose is to harm the reputation of the Internet Computer by causing disruption. Of course, as an ecosystem, we have experienced widespread attacks designed to harm our reputation before, albeit in different forms. Most famously, in May 2021, the Internet Computer was widely seen as a potential crypto industry disruptor. A key narrative at the time was woven around the potential of web3 apps that would actually run on blockchain networks i.e. "onchain," as per the original meaning of that phrase. The fly in the narrative's ointment, however, which was being used to sell the potential of some major up-and-coming chains, was that the Internet Computer was the only network that could actually host general-purpose apps and services built from "smart contracts" (which are far better called "network code") thanks to years of R&D by the DFINITY Foundation. A successful launch of the Internet Computer threatened to puncture this web3 apps narrative, which was at the heart of their marketing and fundraising efforts. Furthermore, their insiders were aware of the years of R&D at scale that had been performed to create the Internet Computer network, and they were downright terrified of the competitive threat it posed. Simply put, in the fever of 2021, they feared that if the Internet Computer launched successfully, it might dramatically reduce their ability to hoover up billions from the markets in the crypto bull run. The resulting attacks by corrupt but powerful industry actors involved massive market manipulation on an exchange before/after launch that made the ICP token price crash, lawsuits by a corrupt law firm secretly on the payroll of a big industry actor, and massive further manipulation of public perception using huge social media astroturf armies, paid crypto press, and even a huge mainstream publication whose key reporter was linked to an actor who is now in jail. Events took place on a historic scale that was completely extraordinary, and I hope the full story, including what it was like dealing with what took place, makes the light of day some day — I am pleased to say there is no comparison to what is happening today. As a result of these past events, to this current day, a large majority of people who consider themselves crypto industry aficionados, and interested investors and journalists, remain completely unaware that most blockchain networks can only host tokens and lightweight financial logic. The corruption and criminality of the time successfully hid what the Internet Computer does differently from other networks, and created a reality distortion field that persists to this day. Crypto Leaks, an investigative journalism website that publishes reports based on covertly recorded video created by undercover investigators, has exposed what was behind some of the extraordinary happenings. Thankfully, several of those exposed by Crypto Leaks now sit in jail, and American judges later took action against the law firm involved, among other wins Crypto Leaks gifted to the industry. However, many of those exposed have so far escaped major consequences, and crypto press has often taken a hear-no-evil see-no-evil approach, preventing people from learning what happened. That's a shame, because we all want the crypto industry to be a clean place, where competition is fair and normal. My personal view, is that the happenings of 2021 marked a pivotal moment for the industry, when the original crypto movement, and technical folks and idealists interested in making the world a better place through innovation and advanced cryptography and computer science, were overwhelmingly steamrollered by sharp-elbowed speculators and manipulators. The Internet Computer ecosystem would have set a standard for the crypto industry that kept it honest, but as a result of its suppression at the time, we got an age of speculation and scams, and vaporware and narratives, in which money could often much more profitably be invested into hyping rubbish than into R&D that produces technological utility. Thankfully, what happened is now far in the rearview mirror for the Internet Computer ecosystem, because it has moved on to mainstream pastures, and has a incredibly exciting future ahead. Those currently paying for the new tide of poisonous trolls on web3 social media, and black hat hackers, will be disappointed to find this isn't 2021. Initiatives such as Caffeine (see caffeine dot ai), the AI chat service that builds apps on the Internet Computer, have shown that the network has enormous mass market utility, which does not depend on tokens and speculation — for example, 99% of those building on the Internet Computer using Caffeine have no idea that their apps run on a secure crypto network that can play the role of cloud. Now, forthcoming advances like ICP "cloud engines", and initiatives such as Open SaaS and the Internet Intelligence Gateway, and growing sovereign tech adoption, and many other things currently underway, promise to take the network to another level entirely. Crucially, as intended since work began in 2015, the network is becoming a revolutionary new tech stack for the AI era, and for the sovereign tech movement generally. While the massive potential exists in mainstream fields, projects like MULTI/DEX (dot ai) also continue to demonstrate how the extraordinary capabilities of the network can also be applied in fields such as defi. As the Internet Computer rapidly approaches escape velocity all over again, the moment when its stunning differentiating features and capabilities will become obvious within the web3 industry also approach again. Today, networks talk about AI tokens, and digital currencies for AI. Cynically, one might imagine these things were created because they are easy for retail investors to latch on to, if not undestand. Meanwhile, the Internet Computer has pioneered a new kind of onchain "AIware" software (Motoko), which, when compared against software running on traditional technology stacks, creates apps and services that integrate AI in game changing and previously impossible ways, which software can also be written and maintained far more effectively and safely by AI agents working autonomously without human oversight. The potential of AI is real and truly beyond anything we have seen before, and I predict that AIware will power one of the largest business transformation stories in history. For the Internet Computer, an exciting event horizon approaches all over again, and my guess is this is agitating some people in the crypto industry. It may even be reactivating bad actors from the past. But, we in the ICP community are not afraid, because these bad actors are a spent force. Moreover, the Internet Computer's future now depends on the mainstream world much more than it goes the crypto world, and the mainstream world affords these bad actors no power. Of course, crypto would be better without them, and that's why DFINITY continues to offer substantial rewards to anyone who can provide information that exposes them, but — This latest growing wave of attacks is in fact just a hot signal that it's game on again for the Internet Computer, which we should all welcome. And, seeing the Internet Computer reach its potential, after all the years of toil and effort, is what keeps my fire, and the fire of many others, burning bright. We stay focused in pursuit of our goals, no matter how long it takes. We are creating the next tech stack for the AI era, we remain undeterred, and the potential of what we have created is tremendous. My thanks again to the ICP community 💪

🚨 Last night, the Internet Computer network withstood a widespread, AI-enabled attack, which involved hundreds of canisters using malformed Wasm modules. In advance of ICP cloud engines, Open SaaS, Intelligence Gateway, and MULTI/DEX, we are seeing a rising tide of attacks. As many ICP community members have pointed out, a legion of trolling and FUD accounts have now appeared on social media, often repeating exactly the same poisonous messages, over and over, en masse. The posts of the trolls trace back to agency paymasters, who themselves have received money from somebody. Obviously, whoever is funding this has no place in the tech industry, but sadly some people in the crypto industry see themselves as belonging to something else. The well-funded organizations behind these attacks are not interested in making the world a better place by developing game-changing technology. They are only interested in extracting easy money through snakeoil narratives and scams that our industry still has not gathered the strength to end — they are vampires that prey on the ignorance of token buyers, and they attack anything that might disrupt the status quo by showing people the light of real technology. These tell themselves they are just crypto bros playing the crypto game. However, paying for, or organizing, attacks on public infrastructure, even at arms length, is a serious criminal act, which also reflects who they really are. We want to know who is behind these attacks, and ask for help. DFINITY will offer rewards to those who can help us unmask the criminals, and bring them to justice. These guys need to be doxxed. Thank you for your attention in this, and thank you to the ICP community that stands with the network 💪

Open Source Responder Registry (proposal) 1. "Key maintainers" of open source projects identified who signed up for security alerts. 2. A month before new frontier models are released, open source is analyzed, and key maintainers are confidentially notified of new issues found.

MULTI/DEX Season I ending on 31st July. Prizes from DFINITY for top traders: 1. 7,500 ICP 2. 5,000 ICP 3. 2,500 ICP Then Season II: i) exchange reset, ii) source code release, iii) larger prizes. We're looking at multidex@dfinity.org community submissions for bounties.

Coming soon with the release of ICP cloud engines... Open SaaS packs a dozen+ onchain services for running an enterprise — free forever, AI native, and simply better. Setup is as easy as installing a phone app, and they're remixable 🔥

ICP uses a highly sophisticated security and decentralization model, which all blockchains that wish to function as clouds will need to copy. Justin's latest misunderstandings (below) provide a good segue to talk about this, and share some expertise that even networks he's invested in might use. 1. Node count does not equal security or independence from centralized actors. The claim that the number of nodes in a proof-of-stake network reflects decentralization and security is only an attractive idea that boils down to industry folklore and marketing. The node count doesn't matter per se, as I explain below. For networks that depend on consensus to function, their security actually derives from the total number of *independent participants* involved consensus, and how voting power/participation power is divided between them. In proof-of-stake networks, voting power derives from stake, rather than nodes. However, large stakers often stake via lots of nodes, sometimes to create the impression of decentralization, sometimes to partition access to their keys, and other times because their networks limit how much stake can be attached to a single node. But here's the rub: if someone controls enough stake to control the network, it doesn't matter how many nodes they have spread their stake across. Today, many networks have large numbers of nodes, but are in fact can be controlled by one entity, or a group of closely related entities. This creates the following problems: — They might make an honest mistake upgrading or configuring the network, and cause a disaster by accident; — a hacker might commandeer their control to do something terrible; — they might go bankrupt, and switch their nodes off, potentially causing loss of hosted data, and worse; — they might subtly manipulate computations and data, to extact value from users somehow, sometimes without anyone being able to detect what is happening and; — may other things 2. When someone says "the network is very secure and decentralized because it has lots of nodes..." We know that across the "monolithic" proof-of-stake networks Justin is currently invested into, validator companies often operate tens of thousands of nodes using stake lent to them by customers in return for a share of the staking rewards. In plain sight, this provides a demonstration of how the number of nodes in a network doesn't equal the number of independent consensus participants. However, hidden centralization is more of a problem. For example, some time ago, the Crypto Leaks website shared video of a senior Ava Labs technical administrator claiming that in fact the company, and its founder and CEO, Emin Gün Sirer, own a huge portion of the AVAX supply that controls the Avalanche blockchain, and in fact, secretly operate the majority of its nodes, which they use to stake their holdings to both earn the lion's share of rewards and maintain hidden control. They are not alone. Many proof-of-stake blockchains are run by companies and cabals of founders, execs and investors that secretly own a huge portion of the supply, and hide the fact by self-operating large numbers of nodes. Aside from helping them get rich, this hidden centralization also helps them with two other things: 1) It provides them with hidden de facto control over their networks, which allows them to force through orderly node upgrades and configurations without the difficulty of decentralizing and having to invest effort developing specialized autonomous network governance and orchestration systems, such as the Internet Computer's Network Nervous System (NNS). 2) It inflates the price of their token: because they earn the lion's share of the staking rewards, they can stash them away for later, preventing them hitting the markets, which isn't a problem for them, because they have huge additional holdings they can sell from. By reducing the flow of tokens to the markets they keep the price higher, which i) enables to them to sell their holdings to the public at higher prices, and ii) keeps the market cap of their networks higher, which lends them prestige, which further attracts investors, including institutional investors who don't understand the game they're playing. The public would be upset if they could see the truth. For this reasons, they often create large numbers of nodes while peddling the nonsense that the nodes are evidence of great decentralization. 3. Node count vs decentralization in open networks For any decentralized network, whether its a monolithic network, or a subnet within a larger network, like a subnet on the Internet Computer, what matters for security and resilience is how consensus participation rights are divided amongst independent parties. There are proven laws of mathematics governing how this works. If one party has 1/3 or more of the participation, then they can start exercising various forms of control over the network. Thus, if participation is distributed equally over nodes, as it is on the Internet Computer (where the specialized hardware involved plays the role of a form of stake), it doesn't matter if a subnet has 1,000,000 nodes, and one party controls 333,334 of them, or 10 nodes, and one party controls 4 of them — each creates a similarly bad situation, since one party has 1/3 and can thus exert hidden control. To capture this reality, the blockchain industry came up with the concept of the "Nakamoto Coefficient." This is a number that tracks the number of independent parties that must collude to control a network. In both of the above examples, the Nakamoto coefficient is 1, even though vastly different numbers of nodes are involved, since a single party can exert control. Again, what matters is the number of independent parties involved in consensus, not the number of nodes. People who claim otherwise are often just trotting out the same old snakeoil. 4. A key problem: the anonymity of node operators and stakers A key challenge for proof-of-stake networks is that stakers/node operators are usually *anonymous*. This design choice is often sold to the public using old cypherpunk rubrics that anonymity allows networks to resist government control. Of course, there is some truth in this, esepcially as concerns proof-of-work networks, but the proof-of-stake people making these argument are hardly ever cypherpunks! The reality is that in practice anonymity has just become a way to fake decentralization, and hide massive unscrupulous profiteering. (A further technical observation is that anonymity is anyway a weak shield in practice. For example, November 2022, Hetzner, one of Europe's largest clouds, decided to ban Solana nodes, and deleted 40% of the network's nodes overnight. The fact is they were able to easily identify the Solana nodes among the millions of other compute instances through technical means. The government could too.) 5. Moving on from anonymity, and creating powerful incentives for node operators not to be evil The Internet Computer eschews node operator anonymity. When a prospective node operator wants go gain a "node provider" ID, through which they can join nodes to the network, they have to submit a proposal to the Network Nervous System, which includes identity and background information that allows the community to verify who they are, and what relationships they might have to other operators. Once they receive their node provider ID, this feeds back into how the Network Nervous System combines nodes. Upon this foundation, the NNS combines nodes to form subnets that it knows are operated by independent parties — which combinations create the required levels of decentralization in a deterministic way, while using the minimum number of nodes for efficiency purposes. Further, non-anonymous node providers join a system where they have powerful incentives to behave honestly. Simply put, as the result of their declarations, if node providers act in an evil way, for example colluding to corrupt their subnets, they become legally liable, worldwide, for the results of their nefarious actions. Moreover, if they seriously disrupt the correct functioning of the network, they could additionally face criminal prosection under laws such as the UK's Computer Misuse Act from 1990. The Internet Computer can slash misbehaving node providers, banishing their expensive hardware from the network, and proof-of-stake networks can similarly slash the stakes of their node operators. However, slashing is a financial incentive that exists within a hypothesized microeconomic framework. In some scenarios, it's possible that a node operator might extract more value through dishonest actions than they lose when they get slashed. The introduction of legal penalties for dishonest behavior act as a far more powerful real-world incentive. The Internet Computer is more secure by design. 6. Scaling and efficiency using deterministic decentralization The Internet Computer is essentially a network of super advanced subnet blockchains, which run under the control of its Network Nervous System, which runs on its own subnet (which also chains cryptographic keys to the subnets it creates, enabling the result of every call/tx into the network that triggers onchain computation to be transitively signed by the public key of the NNS — yes, Justin is talking nonsense when he says there is no shared security). Individually, these subnets can host serious amounts of onchain computation and data, and they can even serve web. However, to scale-out horizontally, the network has to create additional subnets on demand. This is only possible because the Network Nervous System can look at the available pool of nodes, and then draw down just the right combinations of nodes required to create new subnets with the necessary Nakamoto coefficients. By design, it uses only the minimum number of nodes required to create the necessary Nakamoto coefficient, minimizing the replication of computation and data, driving incredible efficiency. 7. Going beyond node operator independence Deterministic decentralization makes other considerations too, in addition to combining nodes from independent operators. Here they are: Data centers — if a subnet's nodes are in the same data center, data center failure would also take the subnet down, so it combines nodes installed in different data centers. Geographies — a nuclear strike might take out all the data centers in a geographical area, so its combines nodes in data centers that are geographically dispersed around the world. Jurisdictions — if a jurisdiction such as the EU suddenly banned blockchain (hopefully not!) they might take down all nodes inside the regions they control, so it combines nodes based in different jurisdictions too. Using this more nuanced understanding of decentralization, deterministic decentralization squeezes incredible security and resilience from the minimum number of nodes. This is something that just isn't possible on proof-of-stake networks with anonymous stakers and node operators. 8. Security and resilience on a cost curve In practice, deterministic decentralization is also applied within the context of considerations about the most appropriate balance of security and cost. Today, Ethereum replicates computation and data across hundreds of thousands of nodes. This is one of the reasons why its onchain computation costs are many orders of magnitude greater than on the Internet Computer. Yet, the computer science says that the amount of security and resilience they are gaining by adding more and more nodes exponentially decayed to zero long ago. The Internet Computer, meanwhile, is focused on providing cloud, which demands efficiency. In fact, the Internet Computer always aims to combine the minimum number of nodes required to produce the level of security and resilience appropriate for the application, because in reality, cost/benefit curves are often vastly different, and one size doesn't fit all. Justin complains that shared public subnets used by the Internet Computer to host applications and services only use 13 nodes. In fact, this number of independent parties creates a Nakamoto coefficient of 5, which is much higher than actually exists on most proof-of-stake blockchains behind the scenes. Simply put, it is sufficient for these applications. The soon to be released cloud engine technology will provide market validation (cloud engines are private subnets created by enterprises that wish to select their own nodes). My bet is we will mostly see enterprises configure cloud engines with just 4 or 7 nodes, which will provide Nakamoto coefficients of 2 and 3 respectively, which they will see as easily sufficient for their needs. They will only add more nodes if they want to scale out query capacity, or reduce web latency times in different regions. This works both ways. For example, the Network Nervous System allocates ~50 nodes to its own subnet, and a similar number to subnets involved in the hosting of threshold cryptography, which allows hosted software to create public keys that the network can sign for on demand (e.g. to custody bitcoin within an application) and securely encrypt data stored on the network (e.g. the vetKeys functionality). These subnets benefit from a huge Nakamoto coefficient of 17+, as well as the additional considerations that deterministic decentralization makes. If it wanted to, it could combine hundreds of nodes to create a subnet, thanks to the advanced nature of the network technology involved. The ability of the Internet Computer to dynamically configure subnet nodes in pursuit of the precise amount of decentralization required, when considering all relevant factors, reflects its incredible sophistication, and why it can provide tamperproof unstoppable onchain cloud. To date, the implementation of deterministic decentralization remains unique to the Internet Computer. But, like other innovations the network pioneered years ago, which others are only now pursuing, such as reverse gas, chains that covet cloud provision will inevitably also attempt to adopt these methodologies. Possibly, even those that Justin holds dear.

Hello MULTI/DEX 🔥 Should DFINITY release the most powerful DeFi application the world has ever seen? What's cool about it? Here are some factoids, the craziest at the end: 1. It runs on an ICP cloud engine (soon everyone can have one) and is 100% network resident and tamperproof. 2. It is genuinely multi-chain, with no bridging hassles for users (users can deposit straight into their accounts, and withdraw directly, from the native chains of tokens). 3. It is order book based, but also provides a traditional swap interface, which swaps arbitrary assets by routing across the underlying markets. 4. It supports both spot trading, and margin trading that lets traders go long and short with leverage. 5. It has an AMM (Automated Market Maker) that uses Internet Computer outcalls to determine outside prices, then delayed matching against AMM limit orders to prevent arbitrageurs draining liquidity, as can occur with traditional DEXs providing swaps. 6. The AMM maintains a unified liquidity vault, and doesn't need two liquidity pools for every trading pair, providing outstanding capital efficiency and liquidity compared with traditional DeFi systems. 7. Users can earn by depositing into the AMM Vault, and into an insurance pool that protects the vault from margin calls that fail to recover all capital (the insurance pool gets 5% of all liquidations). 8. MULTI/DEX runs on the decentralized Internet Computer network, and is 100% open source — unlike HyperLedger, say, which remains closed source, and has an single-purpose architecture closer to federated CEX hosted on a symmetric cluster of federated servers. 9. If we go ahead, we would propose that MULTI/DEX runs as part of the Internet Computer, in the sense it is controlled and updated by the NNS (The Internet Computer's Network Nervous System, the world's largest and most sophisticated DAO, which directly orchestrates and updates the network) providing unparalleled levels of autonomy, transparency, and security. 10.... and this is the BIG ONE... its backend is built using the latest Motoko language framework (soon to be released) that puts AI *inside* of its software. That means, in another seminal inventive step from DFINITY and Caffeine Labs technology teams, that AI can see, browse and query the realtime data inside the app/dapp's persistent memory and can create and execute ad hoc queries and update logic on-the-fly (subject to permissions). So, while for much of the time traders will be using the traditional UX shown in the pic, increasingly, they will be interacting with the exchange through AI chats that have the "Internet Computer Connector" MCP installed (soon to be released). On the one hand, traders will be able to use chat to ask for simple things, like current spot pricing and market depth, and the likely slippage on a spot market order, and for orders to be submitted, but on the other, for much more demanding things that require the AI to execute ad hoc functionality, such as "Look at my positions and margin pools, and rebalance them to give me more blended market exposure, while also adjusting for risks indicated by social media coverage of forthcoming market events, but wait for my approval of your plan before proceeding." This is a lot to take in, so I'm aiming to get a new demo video out ASAP that will demonstrate what's possible with this AIware, which will include MULTI/DEX — should be about a week!! Btw. for those wondering what might be the big picture beyond what I just described with MULTI/DEX: At DFINITY, we are in the process of transforming ourselves into an "agentic organization," where all our existing apps/SaaS is replaced by custom on-demand apps/SaaS running on cloud engines that are created and updated by AI. Of course, these on-demand apps/SaaS are being built using the new technology described that automatically puts AI inside and provides users with fluid functionality via chat. The totality of the apps/SaaS represents an enterprise "World Model," which incorporates as much of the enterprise's data as possible, enabling AI to perform incredibly powerful analyses and actions — when you see this is in action, you can't unsee what you saw, because it's clearly a huge leap beyond the status quo of today's tech, which is exactly what the Internet Computer project is about. This wraps up our new technology stack, created by leaning on unique aspects of "The Network is The Cloud" paradigm, and years of work, and what, together with cloud engines, will finally enable the Internet Computer to strike out into the massive mainstream cloud technology market.

Dear ICP community, the Internet Computer has now been running strong for 5 years 👏👏👏 Here is a celebratory preview of ICP "cloud engines," the sovereign frontier cloud technology the network shall soon provide from opencloud.org. Main points: — Cloud engines enable anyone to spin up their own sovereign frontier cloud. The technology involves an extraordinary inventive step, in which cloud is created from a mathematically secure network of nodes. The nodes run as part of the Internet Computer network (internetcomputer.org) but are selected and configured by the cloud engine's owner. — The frontier cloud provided by engines is strongly focused on enabling AI agents to build and update online applications and services for us. The world is changing fast, and nearly all new online apps and services are already being built with the help of AI, and thus cloud engines target the future of cloud. — Software hosted on cloud engines is tamperproof, which means that it is immune to infrastructure hacks, because it runs inside a mathematically secure network protocol, rather than on computers directly. This means that AI agents, and those building with them, don't need to have a security team in the loop, or to trust someone else's security team. This is crucial, because in the future, non technical people will demand the freedom to build with full automation — where they just need to issue instructions to AI about what to build, and don't need to worry about anything or anyone else. Of course, apps and services running on engines are also vastly safer from the new breed of hacker being enabled by frontier AI. (The cloud engines themselves are also "tamperproof." Even if a hacker gains physical access to some portion of a cloud engine's nodes, and can make arbitrary changes, the computations and data of the hosted apps and services cannot be corrupted or interrupted so long as the network's fault bounds aren't exceeded. The recent hack of Vercel, a major cloud platform, which gave hackers access to the apps it hosted, provides additional perspective on the importance of this advantage.) — Software hosted on cloud engines is guaranteed to run, so long as a sufficient number of the engine's nodes are running. This means that AI can build applications and services without the need to have a human systems admin team constantly tinkering with the underlying platform to keep it running, which is again crucial, because in the future, non technical people will expect the freedom to use AI to build without the support of others. — New frontier programming language technology, in the form of the Motoko language developed by Caffeine Labs, leverages seminal "orthogonal persistence" technology that unifies program logic and data to deliver further unlocks for AI (Motoko is the first computer language being developed that targets agents that are writing software rather than humans engineers per se). Nowadays, AI can build and update production apps at a prodigious rate, even at the speed of conversation. But it can also make mistakes, and there's a risk that an update it creates might be "lossy" in the sense it causes some transformed data to be lost. Again, in this new world, it's both undesirable and impractical for everyone to have to have a systems admin team on-hand to detect lossy updates and roll them back, but Motoko provides a solution: it can detect new software updates are lossy before they are applied, reducing potentially catastrophic errors by AI to harmless coding retries. — Software hosted on cloud engines is "serverless" but unlike traditional serverless software, directly it directly incorporates data through "orthogonal persistence." Another key purpose is simplify backend software logic and fuel the modeling power of AI by increasing abstraction (sorry for the technical language!!!). Put simply, this enables AI to produce more sophisticated backends, faster, and at dramatically lower costs, as measured by the number AI API tokens consumed during coding. (Tip for the technical: orthogonal persistence is a new paradigm where "the program is the database," and data lives inside program variables, which is possible because it's as if hosted software runs forever in persistent memory). — An expanding database of skills at skills.internetcomputer.org shall make it possible to develop and directly deploy apps and services to your cloud engines directly from Claude Code, Perplexity, Codex and other AI platforms. Further, your account on caffeine.ai can be connected, so that new apps and updates created through conversation automatically appear hosted from your cloud engine. In the future, R&D is going to be very seamless. You converse with AI, and your secure and unstoppable apps or services are created or updated. Cloud engines are designed to directly support this "self-writing cloud" future where we can work hands-free. — Tech sovereignty is becoming a huge issue worldwide, with governments and corporations seeking to create sovereign tech stacks owing to geopolitical tensions. Increasingly, people are realizing that tech provided by foreign nations can come with hidden backdoors and kills switches, from the base platform, right up through hosted apps and services. ICP technology is open source, and those building on ICP using AI own their own source code. When you have the source code, you can verify that there are no backdoors, and when you own the source code thanks to AI, you can update it at will, freeing you from vendor lock-in. But cloud engines take sovereignty much further... — You create a cloud engine by selecting the nodes that will be combined. You can choose the class of nodes used, and their number, but more importantly, you can choose who operates the nodes, and where they are located. Almost any configuration is possible, because the Internet Computer scales the security privileges afforded to hosted software within the network according to configuration (software hosted on cloud engines can directly interoperate with software on other engines and traditional subnets, but base restrictions are applied according to security rules). A cloud engine can be created within a region such as Europe, to comply with regs such as GDPR, or completely within a sovereign state like Switzerland or Pakistan. But cloud engines go further still... — Sovereignty is also about freedom from vendor lock-in. Cloud engines are essentially ICP (Internet Computer Protocol) network configurations, and this means the underlying compute nodes they combine can be swapped out without interrupting their hosted apps and services. This is a big deal. In addition, cloud engines now support nodes that are instances running on Big Tech's clouds, in addition to nodes that are dedicated specialized hardware, as per the Gen I and Gen II nodes that dominate the Internet Computer today. For example, it is possible to have an engine running across different AWS data centers, say, and then reconfigure the engine to run across a mixture of AWS, Google, Azure and Hetzner for even more resilience, without the users of hosted apps and services noticing a thing. That's true freedom. — Sovereign AI is becoming increasingly important too, and cloud engines allow special "AI nodes" to be added to them, so that hosted software can perform inference on hardware provisioned by the owner from a location the owner has selected. Even though the AI nodes are only accessible within the cloud engine, they can still benefit from the forthcoming Internet Intelligence Gateway (IG), which will make it possible to validate inference performed on key frontier open weights LLMs, even when the inference is performed on completely independent AI clouds. When the results of inference are received, this technology can verify that neither the prompt+context (input) nor the inference result (output) have been modified, and that the results were produced by the precise LLM expected. This ensures that AI clouds don't cheat by running inference on cheaper models than are being paid for, and bad actors aren't modifying the inputs or outputs to surreptitiously insert advertising into results, say, or change facts, or insert malware when code is being generated. What's super cool about this technology is the cost of the verification is scalable. A very valuable additional security can be achieved with only 1-2% of extra cost. — Scaling apps and services when they hit capacity limits is another thorny problem that cloud engines help the world address. Engines make scaling possible without rewriting or reconfiguring software. The query workload capacity of hosted software can be horizontally scaled simply by adding new nodes to an engine, and nodes can also be added in geographical proximity to demand. Meanwhile, update workload capacity can first be scaled-up by swapping an engine's nodes out for the next class up, and then when no larger class of node is available, horizontally scaled-out by "splitting" the engine into two, which doubles available capacity. (Technical tip: horizontally scaling update capacity by splitting engines requires multi-canister architectures). — For those who have been following how Caffeine builds apps that can efficiently store large numbers of files, I should mention that apps built on cloud engines will also support the new ICP Blob Storage cloud network (since cloud engines currently have up to about 3 TB of memory, which apps storing large amounts of files can easily exceed). We are also working on allowing blob storage nodes to be added to cloud engines, to enable sovereign mass blob storage within an engine, similarly to how AI nodes can be added currently. — Lastly, but certainly not least, I should mention that cloud engines are multi-blockchain capable, and ready for digital assets, thanks to the clever math at their core. For example, an e-commerce service built on a cloud engine can securely accept and custody stablecoin payments, or a multi-chain DEX could be hosted. Further, engines can support software autonomy (software orchestrated and controlled by other autonomous software, in a decentralized way) and can themselves be orchestrated by SNS technology, and thus run autonomously too. Today, though, the focus is on *mainstream* cloud. This year, the cloud industry will generate approximately one trillion dollars in revenue. That number is already huge, but is expected to grow to two trillion dollars by 2030. After years of continuous development, which have seen more than $500m spent on R&D, the Internet Computer network is now tacking directly toward this mainstream cloud market with cloud engine technology. In their first version, cloud engines are not meant to be a cloud panacea. For example, currently they are not ideal for working with big data. You should use something like DataBricks for that. Cloud engines are carefully targeted at enabling AI to produce traditional online applications and services, including SaaS, in a safer and more productive way, which represents a new market segment with tremendous potential. Of course, DFINITY will continue to work relentlessly to push forward ICP's capabilities, so expect further developments. It's worth mentioning that this cloud segment isn't just about creating new apps and services using AI, it's also about replacing legacy systems and apps built on super expensive SaaS services. Caffeine Labs is working to produce technology (Caffeine Snorkel) that can study an enterprise's legacy systems and app built on SaaS, create replacement systems and apps, and migrate the data, while supporting key stakeholders through the process over email and chat, with full automation. Thus the legacy systems and SaaS markets shall also be addressed by cloud engines. Zooming out, and reasoning in a more metaphysical way, we believe, as we always have, that there is room for a new kind of cloud created by mathematical networks, that provides seminal advances in the fields of security and resilience, as well as true sovereignty and freedom from lock-in. That this same technology, with the help of additional technologies like orthogonal persistence and Motoko, enables AI to build for us without the need for so much oversight, and to create more backend sophistication while consuming fewer AI API tokens, enables ICP to bring game-changing advances to the world. Cloud engines will work synergistically with the Intelligence Gateway, which will enable apps and services running on engines to seamlessly leverage AI, wherever that AI is running, while providing verifiability at extremely low cost for open weights frontier models. We believe that cloud engines represent an inflection point in the storied history of the Internet Computer project, and I'm very proud to be sharing the details with you on the network's fifth birthday 💪 I'll be back with more news soon!!