Sovereignists vs. Globalists
Devcon 7 SEA·Fri, Nov 15, 2024, 05:43 AM · 09:50
Speaker
Sovereignists vs. Globalists is the real battle we should be fighting. Fundamentally the goal of the space is to be Sovereign. I think very few people came into the space with the idea that well we should all rely on a single, one World government to control everything we do. But rather how do we give users a choice about what kind of systems they actually interact with on a day-to-day basis. What we should be thinking about when building truly decentralized truly resilient systems, is how to
Transcript
Perfect. Oh, wow. Thank you very much. So, today on the last day of DEF CON, I'm going to talk about Sovereignness vs. Globalists.
This is very much a talk that should get you to think about the ethos that we all follow behind building in this space and what specific sort of implementations we should be optimizing for. So first of all, the goal of the space is to be sovereign. It is to be able to control your own assets, to freely move around, to have censorship-resistant assets, censorship-resistant assets. This is fundamentally the goal of the space is to be sovereign. And with that, I would start that a single decentralized network is still centralized.
And we'll do a nice Q&A in a sec on whether you agree with this. But fundamentally, if there's something, a single of something, you cannot leave, right? Like a single of something can always become compromised. So a single decentralized network is you cannot leave. A single of something can always become compromised.
So a single decentralized network is still actually very centralized. From a physical perspective, it won't survive World War III. And this is sort of like, I think when you think a little bit about this problem, like neither Ethereum or Bitcoin or any other global consensus is really going to be surviving World War III. It just seems unlikely that we're going to spend a bunch of bandwidth on global consensus for really going to be surviving World War III. It just seems unlikely that we're going to spend a bunch of bandwidth on global consensus for magic internet money when all global fiber has been cut.
From a social perspective, it can be captured. And so as a result, we shouldn't design blockchains like a single one world government. Quick show of hands here. Who thinks that a single one world government is a good idea. Yes, this is always zero.
And so no one ever seems to think that a single one world government is a good idea and so we shouldn't be designing our systems sort of in the vein of there's a single global security model to rule us all. Because fundamentally, different people have different requirements for their security models. So my parents live in Germany. They trust a local government, they want something that the local government can sort of interject and revert. This is fundamentally the trust model they care about.
If you live in Argentina, you don't. You probably much more prefer global security, independent instances. But you still want to, like, if you travel to Germany, you still want to be able to roam into the local security zone. For myself, I prefer the Ethereum mainnet over my local government. But security and the security model that you care about is a fundamentally personal choice.
And we should be designing these systems to work for everyone in the world and not say, well, everyone must have the same notion of what security that they care about. The really important part here, though, is we need to maintain composability and allow applications to roam. So it's not a viable option to say, well, everyone install the next 500 iPhone applications in order to be compatible with all these different security environments. Phones in the real world actually did this really well, where I could buy a phone in Switzerland. It still works here, it still works in the US, it still works in China, right?
Like, I can use the same fundamental interface to interact in many different specific security models. This also brings me to why we want to be thinking about this from a scale-free network perspective, and why this is the only true scalable way to do this with local sovereign security, because fundamentally, states should only be co-located together when it's valuable together. Like, not all financial transactions in the world need to be under the same security model. They should be under different ones, where, for example, we are physically in proximity. So all financial transactions in Bangkok should be locally settled to Bangkok.
And this is also the strongest argument for why this will always be faster than Solana. Like Solana can never beat us here because like they cannot violate the laws of physics around speed of light. So like if we do local settlement, we will always be the single possibly fastest thing. And yeah, you only want to have to opt into co-location of state when you actually have the need for it because it's expensive. And so yeah, the basic example is that users and applications can roam between instances.
So sometimes I want to be on global Ethereum, sometimes I want to be on local Bangkok, but I can use the same fundamental interfaces and the same type of applications to roam across all these different security models. And this leads to a very nice other thing is that everyone becomes their own chain. Because we can get rid of the weird abstraction barrier between users and chains where users are just one-on-one chains. For example, Circle is a good example of this. Circle, no matter how hard they pretend not to be, is a blockchain.
They're the blockchain that issues USDC on a one-on-one key. Fundamentally, when I think about why I joined the space seven years ago, it's because we want to build for World War III. Like we want to build World War III resilient infrastructure. Because fundamentally, the world is becoming more unstable. It's becoming very multipolar at the moment.
And so the infrastructure that we built in the past sort of won't survive a dedicated attack. Like all our past infrastructure was built around Pax Americana, and it's not resilient enough. So we need a replacement upgrade for existing coordination infrastructure. Because on day one of World War III, global connectivity will just stop. This is, I think, this needs to be treated as given that global fiber is going to go away and most satellites will drop out of the sky.
The other thing to consider is that privacy, we need this not to hide something, but fundamentally for national defense, community defense. Think of privacy as something that you need to have in order to protect your community from the outside world. Yes. So I will quickly skip over this. But fundamentally, local instances must work regardless of global connectivity.
And so you want to be as local as required, but as global as possible, depending on the underlying physical networking characteristics that you find. One of the best examples for this is, oh, if you're in this room, you're in charge, very fundamentally. You should be running your own nodes, you should be running your own infrastructure. If you sit here, you have to provide digital infrastructure for your parents and your local community. No one else is going to do this.
A good example of this is Ham Radios in Zug, where a bunch of volunteers formed the Ham Radio Club that provides six-hour emergency backup, like within six hours they have emergency backup comms online to in case connectivity drops in Zug, where I live in Switzerland. So they have like these trucks with generators and antennas, and they drive to the mountain peaks in order to restore local area networking again for emergency services. That's a quick TLDR. A single decentralized network is still very centralized and a single global security model is fundamentally terrifying. And fundamentally, you have to run your infrastructure.
If you rely on Fiori, you're doing it wrong. And privacy for national defense. Yeah, we've got to be building World War III resilient infrastructure as a framing. Thank you very much. Thank you very much, Adrian.
So, if there are any questions, please raise your hand. I will toss the mic to you. Don't worry, it doesn't hurt. Soft, again. Doesn't break.
Let's go. Almost. All right, but besides the Sook network, what are the possible practical implementations of this approach? For example, if we lose connectivity, we should still be capable of forming a local coordination, effectively local on-demand chain, to just use within this room. Even if we just want to outside of the World War III example, but in the more specific example, we want to play a trading game, or we want to do local trading.
We should run this on our own chain here, because this is going to be the single fastest thing you can do. Whenever you care about latency, you want to really strongly consider what kind of state you need to co-locate next to each other. And if you need to have fast latency or low latency, you need to be as close to each other as possible. Good question, by the way. Are there any more questions for Adrian?
Have one? You got it on the back. How do you deal with the double spend problem if you can't reconcile global state? So you can tax state, and again, very good question, actually. Most people don't think about this.
But so you can tag each individual piece of state to be, and I skipped over this in the slide, to be controlled by a specific state controller. And for example, if you want to do local settlement, and we currently have all our state and global Ethereum, we'd move it temporarily into the custody of the local state controller. And this could be a blockchain run by, I don't know, 100 people here, or like the 4,000 people at the conference. And then whenever we want to tear this down, we can move our state back out. This requires a little bit of thinking around how do you do state layouts in these databases that we ended up calling blockchains.
If you want to learn more about this, I suggest looking into the Anoma resource machine, which is a very nice resource model where every individual piece of state, it can be complex state as well, like a smart contract, is actually tagged as an individual UTXO that can be moved around to different controller instances. Very cool. Thank you very much, Adrian. Thank you very much.
Automatic transcript — names and jargon may be misspelled.