Aleph Cloud v2: how to decentralize AWS

Transcript

Hello everyone. It works perfect. So I'm Oliver. I'm CTO at Aleph Clouds and today we're going to be talking about a new architecture for Aleph Clouds soberly named Aleph V2. And the goal is to propose an architecture that can help us properly decentralize hyperscalers such as AWS and provide a better alternative to these monopolies. So first a word of congratulations. Decentralization is over as you've seen this week. Financial institutions are coming. Basically, you know, we won. The game is over. You know, this is the last ETC.

Pack your bags and go home. Banks are taking over and you know, crypto is over. Of course, we know that this is not in fact true. This is just the beginning of the journey and my point is to hammer that down because I think that we have a severe problem on our hands actually. And that problem is named hyperscalers. That problem is named AI because basically we see well finance was the first use case, but we're still depending very much on centralized infrastructure. Most DeFi protocols are still hosting their front ends and back ends on AWS, Azure or Google Cloud.

And you see that basically these guys are holding us pretty much you know hostage in a number of ways. We have a $1 trillion industry today that is managed by three major players that are all US based. This is a major problem so for sovereignty for all non-American users. I'd argue that you know, it could be a problem for Americans too. And we basically know that these three players have a bad history of vendor lock-in, data misappropriations, censorship and basically it's only going to get worse because we see that AI today we have the likes of Open AI and Anthropic. So I don't know in the room who trusts Open AI and Anthropic with their data. If you could raise your hands.

Yeah, exactly. You're held hostage. >> [snorts] >> And so basically that's the that's the problem. These guys could become the biggest monopolies ever and we have to well, we know the lessons. We've seen this happen before. So maybe this time we have the technology and the necessary tools to avoid it or to at least provide an alternative. And basically it's a very simple thesis. I think the world needs an open hyperscaler. So you might ask well, doesn't blockchain already solve this? And for a number of reasons the the answer to that is no. Blockchain solves very specific problems which are you know, great blockchain does this amazingly, but it's expensive and limited in the forms of compute that you can do. You need specific languages to program these things.

You also well, until very recently had no privacy. And also well, no networking, no no IO, no no way to get access to the most of the data. So you either needed up chain systems or oracles that brought you the data on chain. Either way this is not appropriate for general purpose compute. This is amazing a problem that will take time to be solved on the blockchain level. I think some people are scaling the blockchain the things that you can do on the blockchain. And that's great, but we take the opposite approach and say well, how can we come from a centralized system and decentralize it? We know that if you want maximum decentralization and absolute resilience of your well, finance financial applications again, blockchain is the way. I think we need something in the middle.

Main problem today so this is not a new problem of course. This is something that was attempted to be solved back from the 2017 ICO period. But I would argue that most decentralized cloud today absolutely suck and ours too. Compared to hyperscalers, basically you have these guys who have had the most proficient professionals in tech work for them to develop these things for the last 20 years. And so as a result, they're extremely convenient, extremely scalable. They provide high availability across the board. Well, you do have a few incidents thanks to AI these days.

That's great for our marketing. But overall, you know, these guys are good at what they do and that's the that's the main challenge here because you could argue that banks in the past were not so good at what they did. These guys are killers. And so that's one of the biggest problems that we face. On the other hand, when you look at existing decentralized clouds, they scale pretty poorly in terms of fault tolerance. There is not that much fault tolerance at all besides the payment layer because that part is on chain. But the rest if you rent a VM typically on the most of these services, if the node that hosts this VM goes down, the VM goes down with it. And there is pretty much little recourse to you you have to towards that. It's a main problem.

You have obvious network speed limitations because these things tend to ignore the actual network topologies. You usually have well, no managed services at all and God knows that enterprise loves managed managed services. And we either either way also these networks either focus on one part of the the problem which is either compute or storage, but they never provide both at the same time. And yeah, the goal is to change that. I want to clear some misconceptions as well because you know, some people are arguing or thriving on these arguments. I think they're they're wrong.

The the first being that decentralized cloud networks can be much cheaper than hyperscalers. So hyperscalers do have healthy margins. That is absolutely true. But the way current decentralized clouds are implemented today is usually involves a lot of intermediaries to provide nodes to the network. So if you want to actually compete with hyperscalers, you need to be talking to the data centers directly to the professionals who host the hardware because otherwise you just add well, you know, intermediaries that you need to pay in the middle. It is very complicated to compete on cost otherwise.

Another problem as well is that there's well argue that residential nodes provide great you know, edge computing for everyone. That's just ignoring that's that's not the internet is configured today. Usually most traffic between residential blocks will go through your ISP again. And so basically >> [snorts] >> the data center topologically is much closer to your ISP than the next block could be. And so overall one argument of that I want to be able to make here is that we need to keep it decentralized but work closely with data center operators because these guys are the professionals that are working to you know, get the good the performant hardware, manage to make economies of scale which is very important here as well.

And [snorts] also know how to to manage great uptime for all the other workloads here. Thankfully, we have an edge here as well in in decentralized compute is that my point for decentralization here is that this solves a very real problem that we have in decentralized in a computing cloud computing actually is that with data centers are critical infrastructure and we see that they are being targeted more and more or sometimes not targeted but just have incidents. And basically this is going to be clearer and clearer that these things are targets, military targets and are not defended at least at the at the right level of a of a you know, defense for for the for these such critical infrastructure and I

believe that here decentralization can play a key role in providing well, resilience by default for most compute workloads. And so this is a thing that's actually a a great selling point for enterprise. So before we jump to the architecture, just wanted to go talk about the key properties that we that we envision here for IV2. So one thing that I really want to say is because some people will tell you no, decentralization doesn't matter. You should focus on you know, users, PMF, whatever. I think in this case decentralization is actually a core value and a key feature that we can sell to users. It's just not named decentralization in the real world. It's named multi-cloud. It's named resilience. It's well, basically providing failovers for your user applications. And that's very valuable

because you have entire DevOps teams at most enterprises focusing a lot of time in making sure that they have redundancy between different cloud providers, different data centers. And this is actually a a major DevOps cost for a lot of enterprises. Um Also we for the same reasons I mentioned, we want to have most nodes still in data centers, but that doesn't mean that it's not decentralized. It just means that it's decentralized at the data data center level. So that you are cross data center there. And we want decentralization for the payment level as well because we want on chain payments. That is very very useful because it enables a few use cases like agents paying for their own their own hardware which is one thing that we developed recently.

Um In terms of trust assumptions, so of course there are going to be a few trust assumptions here. The what what we want to do is that the worst that an attacker can do is censor. We don't want any way to meddle with anyone's workloads or storage. So we want integrity at every every step. The way we do that today is by relying on TEEs. There is a big debate about ZK, FHE and TEEs in crypto. I do believe for what we're doing today at the scale that we're envisioning TEEs are the only way that that that works. But this comes with two very important trust assumptions. One that we have to trust Intel and AMD because these guys have the keys.

And second thing is that we have to deal with the recent evil maidens keys to hardware attacks. And so our secure model model should should try to avoid these pitfalls as much as possible. And finally in terms of UX, one conclusion here is that regular people absolutely hate crypto UX. So you want no apparent wallets. You would just want regular accounts. You don't want to pay gas fees. So you need to avoid that. Thankfully recent developments on the blockchain level allow you to avoid that. So yeah.

Let's talk architecture. Um And now first before we jump into the architecture of IV2, I want to talk about the AWS architecture. And this is a simple diagram that shows basically the minimum components that you need to make a thing like AWS tick. So when you have a user making requests, essentially what happens to reach an application on Amazon, it first you need a DNS to tell you to tell you where this where you need to access your the the AWS domain. This typically points you to to a CDN. So this is called CloudFront in the AWS domain. This thing essentially is a regional local cache that can get you data faster if it's available. It can also do local compute and a bunch of other things. But that's basically as

close as you get. Typically what what's going to happen is that well, it caches or does a bit of as many things as possible close to you. But for a lot of requests, it will still have to defer to where your application actually lives. So this arrow there does a lot of heavy lifting because there can be thousands of kilometers that are covered by this. >> [snorts] >> Um and basically here you have your whole region that is um that where your original deployment and that comes with a gateway that tells you where your application lives. So that knows exactly one which servers inside the Amazon data centers where your VMs are running, where your storage is located, how to access all that that matters to your application.

And inside that domain in green, you're going to have compute. In purple, you're going to have storage. Um and basically what what matters here is that behind the scenes, you have these components that are critical as well to this infrastructure. You have some form of you know, scheduling where you need to know how which server to pick to run specific workloads. This basically you know, selects a node and selects and ties the VMs to for specific nodes. Um you have IAM which is their access control system. This is essential as well because you need to be able to to protect your infrastructure making make sure that you have fine grains permissions on who can do what.

And you finally have your key management system which enables you to store secrets and make these secrets available to your workloads. So these are I would say the basic building blocks that we need. All or most at least at AWS applications are built on top of this. So my my theory here is that if you manage to build a decentralized version of this, this enables a ton of higher level managed services that can be built on top of managed infrastructure managed decentralized infrastructure. And that's the that's the goal here to minimize the number of core building blocks and decentralize it.

So this is the architecture we propose here. Um So how does it work in terms of user requests? So similar to oh yeah, one thing I mentioned here, I will not cover the DNS and CDN parts here because this is there are complications to for these things to decentralize these because you need to find the hardware in the right places. You need to you know, get this. I think this is something that will solve once we get this at scale. Um So first here in [snorts] terms of gateways, so users go through gateways. We provide decentralized gateways. We'll I'll mention explain what it means later.

These gateways know where your application resides, know on which compute nodes they should go, know on which storage nodes your data is and essentially provide you routing to your to specific applications. Then inside this, well, you have all your compute and storage nodes. Here you will see that I mentioned TEs for all compute nodes but redundantly. The goal is to say that we use TEs aggressively to to guarantee verifiability and integrity. This is what enable enables the the trust property that we what the worst that these guys can do is censor because well, if a gateway goes down or censors a specific application, it just well, one of the gateways will censor you but you still can still

access your workloads through other gateways. Um how do is this all placed? Well, you basically have a set of nodes on the top which is what we call the schedulers. Schedulers act in consensus and basically decide how to tie your your VMs to specific compute nodes. They monitor VMs so that they can detect downtime. They can detect malicious nodes. And the idea here is that essentially this consortium of our schedulers will take decisions, will they migrate VMs as necessary and so on and so on. >> [snorts] >> And finally for all the global state, so that we use blockchains here. We store essentially everything that's global and I would say slow state on chain.

The idea here is that you can also do well, your nodes staking, your declaration of user resources, your payments fully on chain here and have these properties be read by all these nodes that are here regional. So yeah, what I failed to mention here was that this is one single region. Uh for example here, this example is in Western Europe. And we expect to have regions like this all across the world. So now let's talk about each component individually. Um I'll be very quick because I don't think we have much time.

Uh schedulers essentially are a set of nodes in consensus. They have a rotating leader. The idea is simply that they will monitor the state of the nodes and we know which node is up, which and basically accept or reject the scheduling decisions based on that. Um you basically have few schedulers per region because well, we don't want to multiply that we have want to have as little overhead as we want. I propose a number of 10 at the moment because that enables for three nodes to be malicious and still still function. So I think this is overall a decent assumption but happy to discuss.

And well, these things as I mentioned, these are where VMs execute, monitor the life cycle and migrate them away from unresponsive nodes. This is pretty important. So migrations, one one small word on that is that not every application can be migrated fully. So this it will be up to the user to tell its requirements to the to the system to say well, this can be migrated automatically. This needs storage. This needs you know, this relies on on specific features and essentially the scheduling system will be able to act accordingly. >> [snorts] >> Okay, gateways.

Um Gateways on the other hand are how we handle migrations stressfully stresslessly. We just have [snorts] IPv6 routers that guide your application. They have a common IPv6 prefix that they share that they share per VM. Each VM gets an IPv6 subnet. And essentially across migrations, this IPv6 subnet is fixed. So for you as an as an application user, this doesn't change anything. If you're if you migrate, you might have a bit of downtime for specific use cases but that's it's Um Also what what those what those things do is load balancing, auto scaling as well for lambda functions. So the idea here is to support lambda functions as well.

And well, what we do is that we have multiple gateways in the same model as RPC nodes for blockchains here to avoid censorship. A quick word on storage. I don't think we invent much much new in the on the storage level. The goal is to reuse the state of the art here. Meaning in general, a system where you have storage coordinators that manage a large set of storage nodes. These [snorts] storage coordinators essentially track shards of your data. So everything is erasure coded.

Um they also monitor bandwidth usage and report that back for your for your system. This obviously needs caches in front of it for fast access from your user domains. As mentioned, we'll talk about CDNs in another presentation. But yeah, this enables reliable storage here because you have auto repair mechanisms. You have automatic audits of nodes to make make sure that your data is still there. This is you know, nothing new but using the state of the art of what what exists. And yep, here we go. Um Uh finally on key management system.

Here again, you know, nothing new with TEs. You want what you want to avoid essentially is to avoid storing long live secrets on the single TE machine machine. So what you want to do is use every trick in the book to avoid doing that. One typical trick is MPC where you shard your secrets and you issue maybe session keys to your nodes or you can also have system where where you have for specific operations where you need voting systems and so on and so on. You can [snorts] basically the trick is really to avoid giving all the all the all the keys to TE backed applications because of the hardware vulnerabilities that we know.

Um and that will certainly evolve. I'm sure I'm sure we'll discover more in time. But yeah, this is the the goal is to avoid this. Up, here we go. And finally on payments, very fast. You know, this is as well state of the art on chain on chain payment systems. You want a construction for for your for your users to sign in any way whatsoever. Um you want paymasters to avoid gas fees. This is very standard. We want on ramp on ramps for credit card payments. This is all things that exist now that have existed for last few years. Um and then we'll finally what we'll do on chain is that we split some some level of user assets but basically all the high level user assets will be declared on chain.

Okay. So conclusion, essentially we provide a system that's multi cloud by default. Uh with a standard cloud UX which is something that's relatively new for decentralized clouds. We fully on chain payments. The idea here is that we provide something that is sufficiently decentralized to to to to resist most data center incidents. The on the on the other hand, what we do have is that you know, if you want maximal decentralization, please by all means go use blockchains. This is what they are for. Um they they have their own set of pitfalls but if you are ready to accept them, go for it.

And also well, we are very well aware that we use TEs. So you know, attack us for that. No problem. This is a part of the part of the problem. But yeah, thanks a lot for your attention. We have time for maybe one question. Any questions? Question.

>> Brains. Brains.