 So I want to talk to you about InCube, the minimal verification client. So it's a slugged presentation and it's now my fifth DEFCON presentation. I'm sending since DEFCON 0, so it's great to see how this group is getting bigger and bigger and bigger each year. So what is the problem we are trying to solve this InCube? So if you want to connect something to the chain, you need to run a client. And you can either run a full client, which leads a lot of storage, a lot of bandwidth, a lot of computation, or you can at least say run a prune full client. With this, you just say you throw away all the past states. You just keep the current states and the blockchain. This is still considered to be a full node, of course, because of all the information available to recreate all the data. But of course, if you think about IoT devices or mobiles, this is far too much. So people thought about the light client as a solution. So when we created Ethereum, we made it very light client friendly with these logs and merkle trees, but still, this does not run on an IoT device or microcontroller or a car. This is not only way too much data, like at least about 50 megabytes. The main problem is actually the bandwidth. So we did some feasibility studies for German car manufacturers. There's no way we ever put a light client in the car because of the bandwidth. So what people then do, they usually just use a remote client. And the remote client has a problem. It's not trust-free. It's like in FURA. And in FURA is nice. It's a really help. It gets you started, but it's really not the solution. So we worked on something we call in-cubed, which gives you the convenience of in FURA or remote client, but the same security and decentralization as a light client. So I will try to explain you how it works. The first is a registry contract. And if you want to run a node similar to a server, you register there and pay a deficit. This deficit is something you would lose in case you cheat or you lie. So as a client, when you bootstrap this in-cube client, when it started for the first time, you get the current list of the register to know which nodes or servers are available. And after that, you can update or keep it updated yourself. So this is the starting point. So then how does it work? As a client, you choose one of those nodes. We call it node B. And give your RPC request. Very similar to a light client with an open RPC interface. And what you get back is a Merkle proof and a block header. That's very similar to the light client. You can do the verification on your own. But the problem is, how do you know if the block header is correct? The light client synchronizes all the block headers to get to the most current one, and the in-cube client doesn't do this. The in-cube client is not part of the peer-to-peer network. So how does it get this information? So what it does is, that's always coming back here, it is asking node B to get signatures from node A and C. The important part here is the client is choosing who should sign the block hash, not node B. So node A and C in this picture, they would then sign a block hash and node B would give this back as part of the response. So now as a client, you have the following. You have the Merkle proof, the block header, and signed block hashes. And you can know they are right, or measure the security of it by how much deficit is behind those block hashes. You can say you want to have one, two, or 10, or 100. From 1,000 deficit, 1 million deficit, doesn't matter. You choose. And the nice thing now is, how do we make it secure? In the EVM, there's one opcode, which gives you information about the path. This is the block hash. You can retrieve the information of the last 256 block hashes. So in the case nodes A or C would lie, node B would figure this out. See, this is the wrong block hash. And he can go directly inside the smart contract and convict them and get their deficit. So node B acts like a watchdog. So A and C, they really have no incentive to lie, because if they would, they would just lose their deficit. So with this ISR client, doesn't need to be part of this peer-to-peer network, but still have the safety that can measure how much safety security has by how much deficit is behind it. With this, we have an ultra light client, or we call it minimal verification client, because it does nothing but verifying. And it's not comparable to a full node, which is just part of the network. Of course, those nodes need to be paid. So we're working on a state share solution, or actually to be more exact, we're working on a variant of probabilistic micro-payments which we have proposed by Gustav Siemensen. Learn if the time now to go into details, but the acute client will pay for signed block hashes. Because those nodes to sign block hashes, they take a certain risk, because if they are on a wrong chain or there's a reorganization, they may lose the deficit. So with this, we have an incentivized system where this acute client can always be connected to the chain without being part of the peer-to-peer network. The nice thing, it does need to store anything than the code itself. It does not need to synchronize, doesn't need to store block headers, doesn't need to store the state. And this gives us another feature. This client can be simultaneously be connected to several networks. So it can be connected to the main Ethereum chain, or to the energy web foundation chain or some private Ethereum networks or something else at the same time, because it's not storing anything, it's stateless. And it's not part of the peer-to-peer network. So this means we don't not only have an Ethereum client, you could say we have a blockchain client. Because as long as you know where these nodes are registered and you have some URL to connect to them, you can get information which you can verify on yourself. That's why it's called minimal verification client. So what did we do with this? So I have a chip here. I mean, you cannot really see this because it's really, really, really tiny in this box. It's this chip here from Nordic Semiconductors. And this has just 64 megahertz, one megabyte flash, 256 kilobyte RAM, seven millimeter times seven millimeters in size and costs about $3.40. And this is enough to run an in-cube client. So this is scaling access, because now you can actually put this into cars, into IoT devices and connect to the blockchain. A lot of companies saying they do blockchain IoT, what they usually do, they just put private keys inside of IoT devices. This is nice, you can sign transactions, but you cannot verify if the transaction is made in because this is a read process. And for blockchains, actually if writing is technically easier than reading, because reading means verifying everything. So we have built the smallest way of reading from the blockchain and getting verification. So here's how you use this. To just say import in cubed, you could just use this instead of your Infura client or your own node and just do the same thing. So I, for example, use this with my crypto desktop app as my custom node and just runs from the beginning. Now I just want to show you a little presentation. So we have made a safe, which is connected to this chip, which is here, and connected to just the door lock, which can open and close. So for time reasons, we don't show you the whole process, but with the Slocket app, which you can find in the App Store, we actually already rented it. So we are currently the owner of it. Now we can send the Bluetooth message to this chip. It can detect a public key, read from the blockchain through the Incubed client, whether he has access or not, and if yes, opens. So Simon would just quickly show this. I hope the internet connection is good enough that the system works. This is Bluetooth, there's a lot of devices in the room. Sometimes the Bluetooth is not as stable, but yes, it worked, and now we can open it. So this was verified through Incubed, and of course, what do you store in a safe? Store private keys. So for those people who are fast enough, here we have a public, here we have a private key with some ETH on it. So you better make some photos and whoever gets it first can get some money here. So this is the private key we stored in the safe. And this, just to show you what Incubed, what you can do with Incubed. So I hope this becomes the client you use if you just are your mobile phone, IoT devices, but maybe even your laptop because most people even don't run their full notes or something on your machine. Okay, thank you very much for your attention.