Frontier Podcast Episode 5: Filip Rezabek & Space Fabric Architecture

If you'd like to listen along to this transcript blog, subscribe and tune in on YouTube!

Welcome back to The Frontier Podcast, the show where we interview the pioneers pushing technology and humankind into the future, going deep on the original cypherpunk values of cryptography, digital sovereignty, and the limits of human ingenuity. I'm your host, Tom Mitchell-Hill, and today I'm joined by my co-host Daniel Bar, co-founder of SpaceComputer. Thanks for joining me, Daniel.

Cheers. It's wonderful to finally be back after a few months' hiatus. It's a good thing.

It is a good thing. The team has been busy, and fewer podcasts means more work.

So from a cap table perspective, this is all great news.

Today, we're speaking with Filip Rezabek. Filip is the co-founder and Chief Technology Officer of SpaceComputer. He's an incredibly accomplished researcher, nearing the completion of his PhD in distributed computing and robust systems at the Chair of Network Services and Architectures at the Technical University of Munich. His body of academic and practical work spans over eight years, with a focus on computer networks, cryptography, and threshold cryptography applications, specifically cross-chain bridges and trusted execution environments. He's also co-authored over 40 research papers, which is incredibly impressive. He's not only doing the actual PhD, but authoring and co-authoring 40 papers on the side. As someone who did a philosophy degree, I find that wildly impressive, because the degree alone nearly killed me, and it was art. Filip, welcome to the show. It's a pleasure to have you on.

It's great to be here. Thanks for having me.

It's been a while since we've recorded a podcast, Daniel, and now that we have Filip here, I think this is a really good segue into talking about what's happened in the last few months. I know you both have a lot of updates, including the shift towards space internet and the development of Space Fabric, which we'll dig into in a second. I'd love to hear what's been happening in the roughly six months since we last spoke.

Yeah. Before jumping into Space Fabric, one big change is worth explaining. While we were originally set to build a Layer 1 blockchain based on satellites, with the idea of providing a permissionless environment for applications (something quite sci-fi and novel), we realized that the technology we've been working on is actually very applicable beyond blockchain applications alone. In parallel, the blockchain market has cooled down significantly. So we decided to apply the same original ethos, an open, interoperable, trust-minimized, verifiable compute platform, except rather than an L1, we're building it for space internet infrastructure. We'll get into it over this episode, and Filip will share his views and insights. This change has been quite big for us all across the team.

Okay, wonderful. Filip, since we have you here, I'd love to ask you some questions about Space Fabric and this move away from a pure blockchain play. Talk to me about satellite-enhanced trusted execution architecture. What is Space Fabric? Why are you building it? What problem does it solve? And how did it come about as this pivot away from the blockchain focus?

Yeah, definitely. The realization came as we looked more and more into what TEEs in space mean. We started to see details that are very much applicable to the overall industry. Of course, the L1 is something that provides very unique features, but an important part of the realization, and the motivation for why we're now focusing much more on space, is that there are a lot of areas where we can contribute and really build up the infrastructure for the future.

In other words, if you really want an L1, or anything along the lines of distributed systems in space, the infrastructure in its current state isn't fully prepared for that. There's no easy way to communicate, and the ground segment infrastructure for talking with your satellites isn't really up to the standard of being easily accessible. If you want satellite-to-satellite communication for compute purposes, it's also not there yet. That led us to see that we need to build the rails that allow this type of interoperability and communication, and to see what we can improve with respect to the state of the art.

That's part of the motivation behind Space Fabric: providing a new way of thinking, a fabric between different types of satellites, to make sure the communication, the computation, and the entire stack involved is as smooth as possible. Once you have that, you can much more easily build the overall infrastructure, the distributed systems, and the other capabilities that can be unlocked by the underlying solution.

The transition to AI we're seeing now is especially crucial for Space Fabric, with generated materials becoming a reality. We see it in Earth infrastructure, but we're also starting to hit limits with respect to verifiability. Is it a true image or not? Is it AI-generated or human-generated? Was it tampered with in transit? This is part of the threat model we're considering when designing Space Fabric. We see it as a new opportunity to build on our existing systems while being part of something new. That's the motivation of the space internet, with Space Fabric being a crucial part of building this new type of infrastructure that provides end-to-end verifiability for users. It's important for many use cases: not only the critical infrastructure use cases that are currently prominent in the space industry, but also the growing dependency on compute and communication in these systems.

That was almost a year of work we put into Space Fabric, working out how to design it with this type of future and these capabilities in mind, and it materialized in this paper. There's still a lot of work to be done to unfold it in more detail, but this is the initial stepping stone.

Maybe there's something interesting to discuss here. We often give the analogy of space internet infrastructure as something with parallels to what Cloudflare serves in the Earth internet today: backbone infrastructure that's often invisible but enables so much of the secure communication, randomness, and more. Filip, could you draw the parallels to what you see as these backbone elements? What would the future of the space internet look like if we draw on how the terrestrial internet played out?

It's a good point, and there's a lot to unfold. We've seen the internet evolve over time, but at the beginning it was mainly structured in individual silos with certain standards and means of communication. It took some time before there was enough infrastructure that everyone could use open-source protocols and connect. Currently, as a user, you don't really think about it. You have the TCP/IP stack, a model in place that facilitates very smooth communication. If you're a new system that wants to join, you have a clear set of steps and solutions.

That's not the state of space yet. You have many silos, many constellations, and purpose-built solutions that aren't clearly defined as standards adopted by the whole industry. Because of that, we see huge potential in building up this platform and being part of the initial definitions of these requirements. There's also a huge opportunity to learn from the decades of internet infrastructure building, and to see whether there are requirements not yet met by on-Earth infrastructure that we can bring to this new type of infrastructure.

The ideal case would be usability: anyone can join the system without worrying about the protocols, with a clearly defined stack, and without worrying about who the providers are under the hood. If I want a service, or want to interact with an application, I can do it as smoothly as possible, while ensuring security and the new requirements that will become prominent as dependency on this critical infrastructure grows.

In the last month, Elon has become a trillionaire from launching SpaceX, so the idea of space has entered the mainstream consciousness much more. People understand there's an industry out there, but I don't think they quite understand what it is or what it looks like. There's a lot of chatter in online circles about space-based data centers and things like that. I'm curious how you've seen the space industry evolve over the last six months since we last spoke, because you've conducted a bit of a technical pivot and now you're developing Space Fabric, which you've explained really well. But I'd like a better understanding of what these services look like in space. What kind of merchants and vendors are going to be out there? Who are the companies that will be using low-Earth-orbit TEEs, and how will they communicate in space? That's probably enough of a line of questioning, but I think it could be really helpful for listeners to get their heads around.

To address some of what you're mentioning: the whole AI revolution has really sped up a lot of what's happening in space. It used to sound like pure sci-fi that space-based data centers were a thing. Then, with all the NIMBYism, the idea of getting more and more data centers built on Earth started being blocked, and so the meme goes, instead of going to other countries, just go up. After a number of companies popularized that idea, it crossed the chasm from sounding like pure sci-fi, and Elon and other big players are starting to get into it.

SpaceComputer is probably sitting at the interface between that far-fetched sci-fi future and where things are today. You can already launch secure compute hardware and the Space Fabric architecture and support existing applications now, but obviously, the objective is to build the picture Filip described earlier. Once more and more compute migrates to space, we start having interoperable constellations serving enterprises, governments, civilian use cases, and retail applications. Video streaming is already being routed through Starlink today, so you'll see more and more applications we haven't even imagined yet. As for how exactly the interoperability functions, whether it's TCP/IP, TLS handshakes, or optical links becoming a standard, and how something like CDNs (today, Cloudflare) materialize in a Space Fabric architecture incorporated into every space system possible: that's the target we're looking at. But Filip, maybe you can share your view.

I fully agree with everything you said. There are two dimensions. In the short to medium term, many of the ideas around space data centers aren't there yet. We definitely need Starship in place, for example, to make it economically viable to send things to space, and that will take some time. But the tendency is clear: in a ten-year timeframe, there will be solutions really operating in space. Until we get there, we have to consider the current infrastructure and focus in the short to medium term on providing relevant solutions.

That's where we're currently focusing as part of Space Fabric: usable compute that can be integrated on board current satellites, supporting different sizes of satellites with respect to on-board compute resources, communications, and so forth. We're also targeting potential partners in different segments of the space industry, for example, bus providers that can integrate our solution on board their satellites. That's becoming quite attractive, especially from a multi-tenancy perspective. You generally want to decrease the barrier to entry for customers, because space is still quite costly. Even with Starship in the future, the barrier won't be so low that you can easily deploy and rent resources, so the overall tendency will be to find ways to decrease cost and lower the barrier to entry.

That touches the ground segment, too. Right now, renting any type of communication link to talk with your spacecraft isn't very affordable for broader usage, and the capacity of these links isn't high enough to support high demand. But these segments are developing rapidly, and part of our solution is to provide interoperability: the means to easily switch between ground station providers without worrying about the underlying wiring, so you can use the infrastructure to its full potential.

In the 10-, 15-, and 20-year timeframes, all of this becomes day-to-day. A user deploying their workload on AWS today doesn't necessarily care where the computation happens, and we envision a similar story. If space data centers become a reality, that's the experience people will expect. I don't care whether I'm communicating with a data center in Frankfurt, in Iowa, or in low Earth orbit. As long as it provides the capabilities and features I'm looking for, and the round-trip time, user experience, and quality of service are comparable, people will happily use it without worrying where it is. Having that piping in between becomes crucial to onboarding the next wave of developers and users and making it accessible to a broader audience. Devs will still care, because that's part of the geekiness of devs, but the general user will just be happy to consume the services and unlock new use cases, some of them maybe space-specific, in as seamless a way as possible.

Yeah, I think it's only blockchain developers who care too much about the decentralization of AWS servers and where they're located. Sorry, Daniel, what were you going to say?

I was saying: easy, and also secure. Something Filip said is very important, and I feel it's often a key step to grasp, which is multi-tenancy support. As of today, when we speak with fellow builders in the space industry, the general trend is that people don't think much about multi-tenancy. When launching a spacecraft with unique payloads, they want it purpose-focused and dedicated, sometimes to only one client, because people don't want to have to worry about trust issues when sharing resources.

But that doesn't make sense at all, just like it wouldn't for data centers. So much happens in data centers precisely because you don't need to worry about all the other customers. You share resources, and you have the security means to know your compute is handled properly. Of course, there are some security assumptions here, but ultimately Space Fabric will enable the massive utilization of these resources. Once you have the ability to mount multiple payloads and serve different customers securely, that becomes a big unlock. You transition from small-scale, siloed builds to massive racks that can serve different applications with guaranteed security. In our minds, we're already living in that future, but it's a big transition in what the space industry will look like over the next decade.

I think that's a great segue into the analogy of how the internet grew and scaled here on Earth. I'd love for you to dig into the comparison between the initial centralized, walled-garden, AOL version of the internet and the open, interoperable internet we ended up with, plus some discussion of the work you're doing to actually bring that into orbit.

Yeah, definitely. There are layers to that, but the main way we see the internet's evolution on Earth is through open source. Around 90 percent of servers operating on Earth today run Linux, which was a major unlock in the operating system stack, with features people could easily integrate. That's one part that really made it possible. The other part is the defined protocols on top. There's still a lot of development, of course, from IPv4 at the beginning to IPv6 now, but the general idea of open protocols means people know what's expected and don't always have to reinvent the wheel. Even though there are still niche protocols made for specific purposes, many components became open and clearly defined, which later allowed additional features and capabilities to be built on top.

That's something we hope to provide as part of the value chain, because currently many aspects of space are closed source and licensed, which doesn't help adoption. If everyone is reinventing the wheel, or always working with licensed solutions, it doesn't remove friction. You can't easily contribute, build, and be part of the ecosystem. That's where we see the potential for change. There's still a lot of work to make it happen, but that's the general trajectory we'd like to unlock for how the future of the internet unfolds.

I think the idea of Space Fabric is so cool: independently operated satellites that you can turn into an interoperable software layer. I like that you chose the word "constellation," by the way. It's very on-brand. How are you balancing building software and hardware at the same time? Companies usually choose one. How is that working?

There are definitely challenges. We're a distributed team by default, spread all over the globe, which doesn't necessarily make it easier. But the good news is that the hardware supply chain is becoming really mature. You can design in one place, have the PCBs and designs realized in another, and ship them anywhere. Eventually, all of us end up with our own physical components at home, which is a fun part. With software, things are generally much easier. But combining both is quite unique, and in space, at least until it becomes commercial off-the-shelf with everything you're used to from current deployments, you want to be close to the hardware by default. You always have to understand the limitations. What's the power budget? What's the heat dissipation? What are the capabilities of the compute? How can I get as much as possible out of the resources at hand and build the software with that in mind?

Then there's another layer on top. Even when building the software, you have to consider that it will be operating in space, which means there's no physical access to go and debug things. You want the updates you send to your infrastructure to have fallback mechanisms in case something goes wrong. You have additional hardening at the hardware level for radiation, heating, and more, and the software has to be designed with properties like crash-fault tolerance by default. There's quite a lot of consideration there. You can do just software, but for now it's important to be close to the hardware, understand the limitations, and build the software with them in mind. It's changing, but we're not yet at the point where you can completely omit the hardware, and it's exciting to closely understand what will be operating up there and to optimize your solutions accordingly.

I'd also say that one thing I really love about how we work as a team is that we strike a good balance. You're right to point out that this is a mixture of a hardware and software company. We see some of our industry peers that are either pure software plays, essentially trying to provide high security guarantees with software alone, or more focused on novel, proprietary hardware. If you dig into our architecture, we push as much as we can towards the open-source ethos: using open-source components, and developing software that will go in the direction of being a protocol rather than a proprietary, licensed, closed-source thing. Of course, there are some limitations, but we strike a really intentional balance, and that leads to a really interesting mode of operation. It shapes everything from the development process being distributed across the world, to the design choices of which components we pick, to how we communicate by publishing our work rather than squirreling it away behind NDAs. There are some industry limits, but ultimately it reflects an ethos that's rather new in a space sector that historically came out of very conservative, sometimes borderline-'90s government bureaus. All of this is changing a lot, and I'm glad we play our role in bringing that new spirit to space.

It's very heartwarming to see that the cypherpunk values are still intact, and that you want to build open-source infrastructure in outer space, where it's very easy and highly incentivized to keep things as walled and as silent as possible. I know SpaceComputer has been forging ahead with hardware development, and there are a lot of technical components I'd like you to explain, especially for listeners who are probably in a similar boat to me, with some understanding of TEEs and how they work, or maybe none at all. I'd love it if you could bring some order to the chaos of hardware security: TEEs, TPMs, SEs, and the dual use of SEs. There are a lot of terms here. Could we break them down in a chronological or hierarchical order of how they all fit into what makes SpaceComputer, and by proxy Space Fabric, work in outer space? Sorry, that's a loaded question.

Sounds good. There's a lot of hardware and a lot of abbreviations, so I'll try to explain the features each hardware component provides, and how we envision this unfolding in practice.

The general idea is that when you're designing a system, you want to consider the threat model it will operate in. That's the crucial part. You consider where your system will run, what the possible threats are, and what changes you're willing to make to your hardware before deploying it. That's also the motivation for looking into different hardware solutions, because each provides different security guarantees and different features in general: different aspects of runtime protection, secure boot protection, and so on. That's the context for why we touch on different types of hardware components. I'll unfold what we're using under the hood and some of the features that are very interesting for us.

The first is secure elements: a dedicated chip on the PCB that you can think of like a secure vault, with a limited set of operations open to you, such as key generation, signing, and randomness generation, all happening within that particular piece of hardware. Sometimes you can reprogram it and deploy your own firmware, but in general, secure elements tend to be more closed and very hardened against things like physical tampering. That's also the reasoning behind their limited features. If you want tamper resistance, you want a defined set of hardened operations and to make sure only those are available. You can try to expand it, but in general it's more rigorous: a secure environment you can only interact with through a limited set of features.

The second is Trusted Platform Modules, or TPMs, which have been around for quite some time. They aim for a similar set of features as secure elements, but in addition provide things like secure boot. You can measure the operating system running on your particular hardware, including information about the kernel and the state of the system when it's booted, against expected values. That gives you the guarantee that you're running a particular operating system, and you can export this attestation and convince others that this is the secure operating system you're running, with these features. That way, the user also gets confidence that this is the system they want to interact with.

The last is trusted execution environments, which can generally be combined with all of the previous solutions in different shapes and forms. The main motivation for TEEs is programmability, since you can deploy arbitrary logic inside them, and they're very relevant for data in use. TPMs and secure elements give you no protection for data in use or runtime information. Once a system is booted, that's it: you only know the state when it was booting, and whatever happens at the application layer afterwards, you have no visibility. That's where TEEs come into the picture. You can gain confidence about the application, and protect your data and software while it's doing computation during execution and regular operations.

Each of these provides a unique set of features, and if you combine them nicely, you get a very secure environment for your operations: clear trust-boundary separation between different users, and security boundaries enforced not only by software but by hardware, with the added ability to verify the software stack running on top.

The last part you mentioned, a crucial aspect of Space Fabric and part of its innovation, is using dual secure elements. The motivation is twofold. First, we're running in space, and we want a fallback in case one of the hardware components is no longer operational due to the harsh environment we're operating in. Second, we want to make sure the root of trust underpinning the protocol's overall assumptions doesn't rely on a single hardware vendor, so we distribute trust across two different vendors with different properties. That's why we consider different secure elements. Even though they may provide similar features, together they distribute trust across providers and parties. Combining all of this, even though it's a bit chaotic, aims to make sure you're operating in a secure environment and can get end-to-end attestation of the hardware and software, which can then be provided to the user of the system. That's a long answer, but hopefully it gives some idea of how we map and leverage the individual hardware components for different purposes.

There are so many interesting things in how the architecture for Space Fabric is laid out. We could speak about it across many different blog breakdowns, because there's just so much in there. But to further emphasize what Filip mentioned: today, when people think about trusting a secure element or a TEE, there's often this physical access limitation. People call it, as a meme, the "guy with the Glock" security model, because you basically need to get past the guy with the Glock at the data center or bare-metal provider. In this case, you have the physical isolation, and this applies maybe less to the TEE specifically and more to the secure element.

The dual secure element is a very interesting concept. Typically, people have this concern about single-manufacturer corruptibility, because the manufacturer of a chip holds a decryption key. In the scenario of two independent manufacturers essentially cross-attesting against each other, you're already raising the bar for security by a lot. In itself, it's a very elegant piece of hardware. Once the penny drops on that component of Space Fabric, it's just really elegant. It's beautiful.

Maybe I can add to that. The motivation is also that we see supply chain threats becoming a huge problem nowadays. One part is manufacturer corruptibility, but the software stack is also becoming so complex, with so many dependencies, that any one piece of the software stack used in one of the solutions can have a bug. We really want to distribute the trust boundaries and make sure that together they provide a better solution. In case one of them is compromised for whatever reason, you still have this additional layer of security. Supply chain is always hard to tackle, and there will still be issues, but with this approach, we believe we're providing a good solution, and hopefully an idea of how future systems could look with respect to security, given the complexity coming at us from software, AI, and the many dependencies of building complex systems.

There are so many different threat vectors that can come into compute systems now. I was reading something very interesting recently about how instead of n-day exploits, we can now have n-hour exploits in certain cases, just based on the speed at which, say, a Mythos 9 could run through and debug an entire codebase. How do you assess the different threat vectors, and how are Space Fabric and SpaceComputer responding to them? I know you went through some of this in the paper you're wearing on your shirt right now, Filip, which I think is great. There's AI itself, and there's quantum computing and quantum risk down the line, which has been a very big talking point on the blockchain side of things. I'm really interested in how you're approaching, ordering, or at least perceiving these threats in low-Earth-orbit hardware.

Maybe I'll start with the solution at the back, which is post-quantum cryptography. This is definitely something we take very seriously, because space systems usually have a long design cycle, plus a long life cycle for the spacecraft itself, especially when you consider longer-running missions. We really try to be post-quantum native by default, which itself comes in different flavors. The most important idea we try to follow is to be cryptographically agile: having good processes in place so you can keep your software up to date and easily swap the post-quantum algorithms and implementations you're using, in case bugs are found, or new types of threats emerge as our understanding of quantum computers evolves. We want to provide that not only for communication, but for the operation of the solutions themselves. For example, with a TEE, we can store the post-quantum cryptographic keys inside the TEE during runtime to protect them. That's a fundamental part we already offer out of the box, and it was top of mind as part of Space Fabric.

With respect to AI, there are different approaches. One advantage of being open source is that other people can use their favorite model of choice to help harden the software stack, and we actually try to do it ourselves, testing and evaluating our software with state-of-the-art models. Before anything even gets deployed, we have AI in the loop, so to speak, testing and looking for possible vulnerabilities to make sure we're up to date.

The other side where AI plays a crucial role is the ability to modify data and create information that might look very real but can be bogus. That's the part addressed by the attestation capabilities we're baking into the overall system. If an image is taken by a camera, for example, I can cryptographically sign it. Even if AI is somewhere in the loop, which is totally fine for certain purposes, the original information isn't lost, and you can always fall back to it. We want to provide a checkmark to the user, similar to what we currently have with HTTPS. This is a real image, it's authentic, and its integrity is protected by cryptography. And by the way, here's the diff of what happened to this particular image along the way. It's up to you what you choose to trust, but here's a baseline that's cryptographically secure. That's the other part of the solution, and the overall motivation for why we believe end-to-end verifiability is really crucial. In a world where AI will be all over us, we want to make sure attestability and auditability remain, and are provided to the user as part of the overall workflow.

Can we talk for a second about randomness and its importance in the entire stack? I know it's such an abstract concept for people who don't work alongside engineers, especially non-cryptographers. It's been mentioned a lot, and I don't think even I have a fantastic understanding of it. I'm very interested in how randomness functions in the security environment and what that means overall. Sorry if this is a very broad or too general a question, but I'm quite interested in it.

Randomness, in terms of where we see it, is pretty much all around us in our day-to-day usage. We just don't get to see it. It plays a crucial role in most of the cryptographic protocols we rely on daily, because it's used, for example, to generate the private keys that later protect the exchange of information around us. It's used in many other domains as well, from browser sessions to many others, and in terms of security assumptions, you usually rely on a strong source of randomness as part of the solution.

As a regular user, you might interact with randomness in your favorite game, opening your gacha and hoping to win the most epic card. That's one source of randomness we might be more familiar with. But at the cryptographic level, it determines whether the information being exchanged is protected securely or not. In that sense, the true random number generator we're leveraging and providing to users plays a crucial role. You can use it in your private setting and have confidence that the randomness is true and attestable.

Here's an example. A virtual machine hosted on any bare-metal machine gets its randomness from the underlying operating system or hypervisor. Since it's running inside a VM, the underlying host operating system could be malicious, so can I trust the randomness for generating my private key inside the virtual machine, or even a confidential virtual machine? Having the means to import randomness from an external trusted source can be quite an interesting application for cases where you want higher confidence in the randomness and its quality.

Tom, I think there's something interesting to build on your question, and Filip, you'd be able to shed light on this. There are a few terms we take for granted, and Filip naturally would, since it's his expertise. One is the difference between pseudo-randomness and true randomness, which is quite interesting in the context of Space Fabric and, generally, the randomness we're able to source from cosmic radiation. The second is the private randomness beacon versus the public randomness beacon. What are the unique features and uses of each? These are worth understanding purely from the point of view of what the state of the art is in the industry today, and then how the solution we're able to provide gives a definitively superior alternative in some respects.

In general, the difference between a TRNG (true random number generator) and a PRNG (pseudo-random number generator) lies in the process by which you get to one or the other. For a PRNG, you have some form of initial seed, which you of course want to make sure is random, and afterwards you deterministically derive randomness from that particular function. That in itself provides quite unique capabilities, but you really have to protect the seed, because anyone with the same seed should be able to get to the same randomness. For a TRNG, you always have a trusted process, usually bound to physics, to generate the randomness that can later be consumed by the application.

There are several known processes that can provide this high level of confidence. In some Earth-based TRNG applications, for example, it's the noise you get from the motherboard or the chip itself: the noise of the CPU frequency, temperature changes, and so on. You sample from that noise to get high-entropy information you can later consume. Another process, the one we're leveraging, is cosmic radiation. If you receive it on a sensor and then sample from it, it can really serve as a true random number generation source.

Importantly, from the user's perspective, you don't necessarily see the difference as the end consumer, but you want confidence that it's correct. There are additional tests you can run to determine whether the randomness source you're consuming has high or low entropy, and we've done a lot of testing on that. The next part of the story is convincing the user that the randomness they're consuming is bound to the respective source. That's part of the end-to-end system design we're pursuing. You can get attestation from a source that has been tested and certified, all the way through to consumption.

And that's what Daniel was hinting at with the types of consumption. One is a public beacon. We're able to bring public randomness on-chain, for example, where everyone can see it. It's cryptographically signed, anyone can consume it, and it essentially becomes a race for who consumes the randomness first for a particular purpose. The more interesting one, from my point of view, is private randomness: randomness that only you, as its consumer, should be able to access and use in your particular application.

Different applications call for different types. Public randomness might be fine for a raffle, where you just want to verify that you used this randomness, this is the output of the raffle, and anyone can check it. But you don't want to use public randomness to generate the private key on your device, because if someone gets hold of that randomness, they may be able to work out the private key itself. That's how you end up consuming randomness, maybe from the same source, through different means for different types of applications. Private randomness in particular is something unique in its offering, because there will be interesting applications in cryptography and beyond. Consensus is another example, along with a few others that might be interesting to users as well.

Let's take it in a bit more of a philosophical, political direction. We've touched a little on how you imagine the mid-term future, now that spacefaring companies have entered the mainstream consciousness and there's a real push for AI data centers in space, with a lot of blocking here on Earth. What do you think the internet will look like in the future, given this hyper-acceleration towards putting compute in space? What does that look like on a longer-term horizon, and how do you see Space Fabric fitting into that grand vision of how it all ends up?

Very much in a nutshell, there are a few obvious trends. One: there's a general trend towards more, and more complex, space compute systems. Two: there's a trend of increasing cyber warfare in the world, including in space, and we've seen quite interesting analysis and work on this. That already tells you there's an obvious need for robust cyber and confidential compute in space. From now onwards, there's only more work to do on cyber in space. It's almost like the pun, right? Cyberspace, literally. And for us, the more we advance and build more capabilities, the more we'll be able to grow with the market and cover more ground. That's the very high level, but Filip, I wonder what your take is.

I fully agree. Overall, space is already around us as part of critical infrastructure. Think of GPS and how many users currently rely on it. With the general trends we're seeing, it's becoming more open and accessible, which will require security to be up to standard. Take AI as an example you brought up before. The general user who just wants to interact with the infrastructure will be able to, which massively opens the attack vector, and you have to build the system with that in mind. It wasn't like that in the past, because security by obscurity was a real aspect, and the barrier to entry was high. You needed to be a state-level attacker, so to speak, to even consider accessing the domain and to have a chance of spoofing information. Nowadays, it's a matter of a software-defined radio and a couple of bugs. And the trend is clear that the barrier to entry will get even lower, which means even more possible threats to prepare for.

That's the overall idea. You really have to think about the future and look for solutions now, to make sure they become reality. As an example, some satellites currently in design will be flying in 2032, 2035, or even later. If you don't consider both current and future threats when designing them, you're essentially sending already-obsolete infrastructure to space, which isn't ideal. We have to consider the life cycle and lifetime of spacecraft designs and build with at least the currently known threats in mind, making sure there are solutions for them. This is where we're super bullish that Space Fabric and its individual components can be part of future iterations of infrastructure design: providing secure infrastructure for different purposes, making sure attestability, verifiability, auditability, and cyber in general are baked in up front before anything is shipped to space, and making it open in such a way that it's no longer only technology we ourselves can use. Very optimistically, that includes our own future constellation, but it's also something other satellite providers can integrate and ship on their satellites in the coming years, providing a new way to think about security solutions for the future.

Maybe I can add an anecdotal geopolitical story. Back in January, I believe, there was the first wave of protests in Iran, and a lot of the dissidents were using Starlink to connect. Then there was what I understand to be Russian-supported jamming of Starlink satellites above Iran. That just goes to show we're already at a place where space compute is part of the geopolitical landscape. At the same time, as a balancing thought, one of the beauties of space is that it's a location-independent domain in some respects. You have constantly orbiting assets, and ultimately the ability to bring humanity together onto infrastructure that's entirely shared and delocalized. So we're seeing this dichotomy in both directions. For SpaceComputer, on the one hand, we obviously want to be at the forefront of the ability to defend and be part of the good guys. At the same time, we want to make sure we're pushing towards open, more global, and inclusive infrastructure. Maybe that finishes it on an aspirational tone.

I was actually going to drag us back directly into the mud, so I apologize. We can leap back out into an aspirational tone afterwards. This is another jump from "what will the internet look like" to a slightly more specific line of questioning. You have orbiting assets, and you can't really carve out a chunk of space and say "that's mine" like you can on the ground. It's physically impossible. So I'm curious, from all of your work and what you observe within the industry: how do you envision nation-states moving into extraterrestrial politics? You've just given a pretty good example of Russians immediately jamming Iranian dissidents trying to access satellite internet. How do you see that trend playing out in the future? Would it be more interruption of services, or would there be an effort to control the number of satellites in outer space, with nation-states saying, "we actually have more assets in space"? Clearly you're working to defend against that with an open-source system of non-centralized assets. Apologies if that's too far of a tangent, but I'm curious.

I don't think there's a clear answer, even for the states and the individual parties involved in these discussions. That's also why I think it's a great time to be part of it. There's starting to be a Space Race 2.0. Everyone is striving to do better, making sure they have the capabilities, the offerings, and the infrastructure already up there, and only afterwards do they start worrying about limiting it, or providing a bit more structure for how this can be done. No one currently knows how it's going to unfold, but it's important at the nation level to be part of the story, so you later have the option to say something about how it unfolds. From the discussions I've seen, there's no clear answer, but everyone is realizing we likely need to do something, because otherwise we'll miss the train. And that's exciting on many fronts. As always, technology doesn't choose. It just provides the means. It'll be interesting to see how this plays out, with a lot of excitement and a lot of open questions about what the future will look like.

As Filip says, there's no clear answer, because the truth is always more complex than one definitive scenario. There's always more nuance. Look at any technology. Electricity: today, no society can function without it. Later, the internet: no society can function without it. Yet you have fiber optics running under oceans. Would nation-state actors go and start cutting fiber optics under oceans? These scenarios can happen, but the scale of disruption becomes so insane that it almost becomes an unspoken cold war. You just cannot do it, so instead you find sneaky cyber warfare, ways of doing it indirectly.

It's similar with space. I think you'll still see small-scale things, like the IRGC jamming a satellite, or Russia doing this or that. But at a large scale, in some Armageddon scenario where we start blowing up satellites, creating debris, triggering the Kessler effect, and eventually potentially closing off low Earth orbit, I really hope we don't go down that path as humanity. That would be very sad. I hope there's at least some game-theoretic dynamic that keeps us in check, and I hope we can play a part in it by making things much more open and inclusive, such that ultimately, even someone you don't necessarily agree with can still leverage the same technology, the same stack you're building, and by that, advance humanity as a whole. That brings us back to the positive, aspirational outlook.

Wonderful. That's perfect. Filip, thanks so much for joining Daniel and me on The Frontier Podcast. This has been fantastic. Daniel and Filip, this final question goes to both of you as a little close-out. Is there anything you want people to go check out immediately once they finish listening to this podcast? Where do you want people to go? Where can they find you on social media? What should they go do?

Thanks for having us. It's been great to be here. In terms of where to go, check out our website. It's been revamped, it's super cool, and there's a lot of interesting material there about Space Fabric, including blog posts that really document our journey along the way, with what I think is a good mix of deep technical dives and more high-level, visionary pieces. Definitely check it out. We'll also be quite busy in the coming month with a few events. One we're super excited about is Silicon Valley Space Week. We hope to see you around in person.

Wonderful. I'll try to make it out. Silicon Valley Space Week!

Let's go. It's going to be epic. We're planning a pretty awesome activation there and epic demos, so definitely be there.

Can you get durians into the United States, Daniel?

Of course. Of course.

Fantastic. I'm sure everyone there will love that. Thank you so much, guys. This has been fantastic.

Cheers.

Thanks a lot.

This article is brought to you by SpaceComputer, we're building the secure compute layer for the space internet.

If your team is working on hosted payloads, orbital compute, or sovereign workloads in space, we would like to hear from you. Reach us at product@spacecomputer.io.

Explore more from SpaceComputer: Visit the SpaceComputer website, read the SpaceComputer blog, dive into the Space Fabric breakdown, or head directly to the research paper.

Meet the team and connect with co-founders Daniel Bar and Filip Rezabek, or follow SpaceComputer on X and LinkedIn.