 Okay, our next speaker is Timo Savola who's going to talk to us about the gate project. So please give a warm welcome to Timo. Okay, thanks. So my name is Timo Savola and today I'm not here to solve any of your problems. My purpose is to give you a bunch of new ones because I'm presenting a new platform. So that usually isn't the end of problems. This is a project I've been working on for quite a long time on my spare time. And I think it's a high time that I get a lot of people about it and see what they think. So the concept of my project, I've titled Portable Execution State and that's a pretty like opaque title. And to put it short, it means that I'm supporting migration of live programs between various kinds of systems. So basically, like you can think of virtual machine migration, but, you know, like, between disilluminal systems with different CPU architectures and so on. And what you can do with that, the result of that is that you get a new kind of programming model. And the disclaimer I have to mention is that this sounds like a blockchain, nothing to do with blockchains this time. This is a high level illustration of what I'm talking about when I say that it changes the way you write or design software. So up there, the upper dashed line, dotted line is the new focus of program supported by gate. So traditionally, when you have a software installed on a computer, the code is immutable until you upgrade the pre-installed program. But you can freely exchange data with other systems. And that layer used to be the focus of indirection. For example, in this graphic, it's between application and data files where the complexity of external interfaces happens. And I'm trying to, like, remove that completely with this approach. And the remaining interface remains with the human interaction with the application. So what we can actually accomplish is a single file that contains both the application code and data. And both are equally dynamic and exchangeable and so on. Another way to look at it, or another use case for this, is in a network environment. So in a classic, like, request response, a networking model, you have a client which implements, for example, ACDP client. Then you have a server that implements the STPD. And then maybe in the server backend, you have actual functionality in addition to the network layer. So in my model, you are removing the network protocol incompatibility or compatibility problems. And performance problems from the shared, like standardization, specification area. Instead, what you are focused on is local APIs inside the server. So by moving your, when the client moves its own code to the server to act as the controller, we no longer have to bother about network protocols. Instead, we are just doing, like, IPCO local function calls inside the server. And that changes the dynamics of how you can, like, optimize. For example, if you have a large latency between the hosts, the model messaging pattern has to be designed in the specifications and so on. But now it's an internal client detail. They have to take an iterate. And also do a few round trips for the use case and so on. So it's a little bit like a GraphQL, but with actual programming. And that's just curing. And concrete stuff. So, like I said, this is, like, I've been working on this for my free time. So far, to my knowledge, this has no users outside of myself. And I've been playing with these ideas for a long, long time. And the latest prototype called GATE is pretty far along, technically quite advanced. But it needs, let's say, a community or something on top of it to actually be useful. So I'm hoping to get some interest from you people today here. And these are the foundations of GATE. WebAssembly is all the rage nowadays. And it's deservedly so. It's everything I dreamed of when I was, like, coming up with these ideas for this portable stuff. And the next thing you need is the runtime environment for WebAssembly. WebAssembly itself is, like, pretty secure, but only if the runtime implemented correctly. And the biggest difference between, let's say, other server-side WebAssembly runtimes and GATE is that I'm not actually implementing any of the sort of, like, Web APIs or even Vasi, which is a server-side interface because of this portability requirement. So I have to, like, provide custom APIs, unfortunately, for that. And those are accomplished by extension services. And I'll talk about those things later. So the headline feature is this portable snapshot and restore. And it doesn't require any support from the user programs running in GATE. And programs can be suspended at any time. They suspend immediately. Or if someone is trying to, like, work around that, it might not be immediate, but it will be pretty fast as well, so that is built into the design. The program format is WebAssembly. And I'm also building on that for the snapshot format. So WebAssembly allows custom sections in the binary file. So I'm adding GATE-specific sections there. And if you are wondering what that would look like, if I load it to, let's say, Chrome, Chrome would just see a no-operation binary file without any entry points. So it could actually inspect it, but not actually run anything in it because that would require GATE-specific features. One special type of snapshot program is one that has finished. Its entry function has returned. And those are almost like normal WebAssembly programs that come out of a compiler with the exception that it's actually representing the final state of the function call that returned. So you could, like, repeatedly execute the program by making repeated entry function calls in the same state. And those actually could probably pretty easily be loaded into, let's say, Web Browser by adding a lot of GATE-specific APIs there. And the internals, because I'm primarily intending to use this on the server side, and I like go on the server side, so I implemented this GATE with that in mind. And part of this effort was a custom WebAssembly compiler implemented in Go. And to my knowledge, it's the only WebAssembly compiler implemented in Go. So if you are interested in that, it's a standalone project, although it features a GATE toward GATE. And this secure, safe, untrusted code execution requires all kinds of tricks and Linux-specific namespacing and whatnot. So there's C in there, and the runtime, maybe, functions are in platform assembly. And the two most important CPU architectures are currently supported explicitly by the WebAssembly compiler and then the GATE runtime. So x86 and ARM 64-bit variants. And I also ported this runtime to Android. It required some tweaks, but I have a working proof of concept. So basically, the same data features are quite similar to normal WebAssembly runtimes. They are defined by the logical sandbox of WebAssembly. And then the, let's say, hardening feature on the outside are like container runtimes. But there are some distinct stuff. So many, let's say, fast WebAssembly solutions out there try to get high density by doing isolation in process for many customers. But GATE is conservative on using one process for its invocation, for safety. And also, unlike containers, GATE is not containing anything. It's an empty container. Just does all the Linux namespace stuff, cleans out all the modes, all files, everything, and smuggles the binary in a file descriptor in there and just runs that one process in the isolation, not the container. And because of that, every exchange between the service APIs has to go through pipe socket. And that has a really nice feature. It has overhead, but the nice feature is that I can actually employ a second filter that is not much longer than the original strict checkup mode. I couldn't make that work. I had to pull and protect and close in there as well. But I think that's quite much shorter than, for example, something you would need a bit docker in a typical scenario. So I'm pretty happy with that. OK, services are like extensions. You can implement any go or with a go wrapper and some other language. Internally, GATE implements only two services, catalog and origin. I have this proof of concept localhost thing that you can use to migrate legacy request response thing to use GATE. And a few other experimental ones that aren't listed, then probably not going to be there for long. And the services, unlike user programs, have to deal with serialization. So it's a complex thing compared to, like, say, a trivial implementation of that feature in other settings. Oh, the next focus in development is try to enable service that enables user programs to communicate with each other, which is one of the points of interest for me. And on the other side, a user program, ABI is unfortunately, because of the portable scenario, we cannot just expose the Linux, and whatever. GATE does support, like I said before, but only through stubs and with the minimum functionality required to do the GATE specific stuff to the pipes. And it's an asynchronous programming model because of that IPC messaging. And currently, the best way is to use CLang and C++. But I would hope that soon I can say that the ideal thing is to use Go or Rust. So let's have a small amount of time to do a demo. Let's spray the demo goods. What I'm going to do, because every platform needs a DOOM port, so I'm first going to run DOOM port to GATE on my X86 laptop, like this. There's a WebAssembly DOOM, and I'm piping it in the data file. And there it is. And we can play some DOOM. Next, what we are going to do is send a secret to suspend it. So there's the, well, whatever. It's an instance ID. And with that, we can create a snapshot of the state. Now it's in the snapshot of the Wasserman. There's the Shah of the content. Let's see if the network works. Let's copy it with SSH to my RM64 machine in the clouds. And the network worked. Let's go there. Let's see that it's actually ARM. It's AR64. Yeah, it's ARM. And now that the file is there, we can run it with GATE. And it's using X4 wedding to run it. So it starts from the same position of the game that we used. Now, because of X4 wedding, it's really slow to update the screen. But here, you can see that it's actually running just fine. And I have one minute to, okay, let's quit the game. One minute to show the details of the snapshot. I'm now using GATE's debugging features to show the backtrace of the point of suspension. And you can see that, never mind the Linux DOOM, it's the open source release of DOOM. It's not the directory name. So it's then suspended it to get package function. And there are some stack variables there. And finally, we can look at the snapshot file. You can see that there's a bunch of standard representative sections, and then this GATE. Whatever custom sections that contain the stack state, IO buffers, service state buffers, and dwarf debugging info that comes with from C-Lang and so on. So thank you. That was it.