 So a little bit about me, I am Rachel, a engineer at Oasis Labs. So I used to be a student, at least typically, with Don's novel. And it's at the start of my PhD. So Don started Oasis Labs to bring those things to me while I'm here. And so I've been working there for a year now. This is my first 2DF con, and I'm super excited to be here. So yeah, let's talk about what we're going to do today. So I wanted to give like a short 5-10 minute to feel about what Oasis does and why what we're doing is important in our eyes. And then we'll jump straight into the workshop where I'm going to show you how to build one. Could you speak louder please? Oh sorry, thank you. I'm going to show you how to build on Oasis. And then after that I'm going to show you where we want to go with building on Oasis. So yeah, so this is a workshop. And so to download our developer tools, it should be at Don's.Oasis.dev. So there's going to be a few things that we've shown. The only thing that's weren't is this first plan over here. So that's just to install our Oasis toolchain. And so yeah, so I'm going to let people do that. And hopefully everybody will be set up once the time I finish talking to them. Awesome, so a little bit about why Oasis is actually important. So data reaches have been super popular over the last decade or more. And that's because a lot of data is in the hands of centralized companies, Fortune 500 companies that have a lot of personal data. And either potentially or by accident they often link this data. So by showing hands, how many people here have or use Facebook? So it seems like most people. How many people trust Facebook? Almost 70. And one of the proposed theories of a survey they did showed that basically everybody, very few people trust Facebook. And many people that leave Facebook do so entirely because of trust reasons. So how does the Oasis blockchain help fix issues with data privacy? So we help you build decentralized applications on the blockchain with the added guarantees of privacy and security and functionality. So the major issues that are there with standard centralized models are first of all, untrustworthy infrastructure. You need to trust whatever cloud you're using and underlying infrastructure and you also need to trust the applications that are built on top. Together these two things that you have to trust lead to all sorts of undesirable data linkages and that is obviously math. Oasis fixes this by using the blockchain. We have our own layer one solution that we're hoping is scalable and that is combined with secure hardware and other confidentiality-preserving trust-execution environments that may be executing these smart contracts confidential. So the nodes that are executed can't see the data that they're creating over there. We'll get more into that in a minute. Put together these things enable general-purpose computation including but not limited to privacy-preserving analytics and machine learning. So I'm sure everybody here is quite familiar with the guarantees that smart contracts can do but just for a quick overview, the things that security properties they can do are high-techry, high-availability and also immutability. But these things don't give you privacy. The things on the blockchain are transparent and that problem is solved by Oasis with secure on-place. So what is a secure on-place? It's a black box that's run on an untrusted machine, so in this case a node in the blockchain. So at a high level what happens is the untrusted machines in the blockchain will allocate a section of their membrane that they no longer have access to and configure it correctly with whatever program needs to be run. And they will prove to you as a remote user of their machine that whatever their configuration is to be able to successfully run your program without actually seeing that data has been configured correctly. And you receive a verifiable cryptographic on-place. Once that happens you can send encrypted data into this black box which again that untrusted node or nodes aren't able to see inside. The data is encrypted inside by a key that's provided, provisioned by our decentralized key manager and then the results are re-encrypted and spit out, so only you can read them. During this entire process there was never a point in which any of the nodes were running these black boxes and were able to see inside. So yeah, so right now what we use is Intel SGX and that comes with its own set of problems, namely being intel proprietary and there's a bunch of other various security vulnerabilities. And we also hope to support the Keystone on-place which is a research project that works super closely with Oasis. That's going to be an open source hardware on-place that is going to be more heavily publicly audited and it has a bunch of other benefits such as dynamic memory allocation. One of the performance issues we face with the current Intel SGX is it has to do with memory limitations. Memory limitations around actually setting up these on-place since they're limited in pretty much. So yeah, so how do you actually interact with these great programs that can be consumed within a secure on-place in a reproducible form? So that gets into Wazi, which is the WebAssembly system interface. So to understand Wazi, we first need to understand Wazum. So Wazum is WebAssembly. It's an environment agnostic language that's used on mostly in your browser and it is agnostic because the way it interacts with your environment is strictly through APIs. And on the web where we already have web APIs, that's pretty straightforward. But in general environments, there until now didn't really exist any standard APIs. So Wazum wasn't as affordable as it should be. So Wazi fixes this. It's a project that's developed by Wazum Time. And what it is, it's a syscall-like API where any generic platform can interact with Wazum. And we use this within secure on-press to actually be able to have a affordable and general purpose way of doing it. So yeah, the Oasis blockchain, along with many other people are now adopting Wazi. And so yeah, let's dig into a little bit about more of what it is. So to compare it to the EVM, the EVM has some properties that make it really nice and affordable currently. So it's deterministic, a cross-platform sandbox and it's currently completely slash general purpose. WebAssembly is all of these things as well. But it was not cross-platform. But with Wazi, it actually is. So yeah, so the syscall interface gives you a bunch of things. You can interact with environment variables in your file system with these syscalls. And yeah, as a capability-based software model and it's modular, you only have to implement exactly the syscalls that you want for your platform. And yeah, so we feel that Wazi and blockchain are a really good match for one another. In particular, for running blockchain computations you need to support a few different things. For storage, which you can think of as a key value store, you need to be able to read and write files for RPCs in our system. Similarly, you need to be able to read and write files and also for environment variables. For entropy, you need to be able to have some sort of source of randomness. And for timing, you need some clock syscalls. And so Wazi provides all of these. So how does Oasis let you do all of this in a super abstract high-level development kit? Well, we have an Oasis SDK, which I'm going to show you during the workshop in a minute. So it comes with a bunch of things. It comes with a command line interface, which is similar to Truffle, and you can use to build and compile and deploy your projects on Oasis. We have a gateway that lets you deploy to the Oasis network. And we also have some really nice Rust libraries that can be used to develop them. And coming soon, we have a few additional development kits that I'm pretty excited about. In particular, the data privacy API and the open finance certificate. So the open finance certificate is going to let you build DeFi apps increasingly. And the data privacy API is going to be a way by which you as a user can share your data with people that want to consume it and receive results without ever exposing your data to those parties that might be writing analytics. And again, that all ties back to secure hardware and execution side of it. Okay, so this is an overview of how the network actually works. So you're going to be able to initialize, build, and run programs with the command line and deploy to our network through the Oasis client, which is very similar to cloud 3. And once you deploy using your client, transactions will descend through either the Web 3 gateway or a Oasis gateway that we're working on to actually already open source. We're just trying to get it to a stable state right now. And so yeah, so when you execute transactions to the gateway, they get sent to the Oasis network where our runtime will consume your wasm binary and any transactions that are executed will happen within that secure hardware. Nice, okay. So let's go ahead and actually get to the workshop. So yeah, so the demo god is allowing. Things will work. Okay, let's see how I can get this to be... Can people back see this? Cool. All right, so to actually create a contract on Oasis, super simple, just type Oasis in it and then name it what I want to build. So today we're going to build a calculator. Cool. So now I have a calculator initialized. And so what does that calculator have to do? So we need two parts. There's two sides to this. We need a service. So we need a service where I can define my actual contract and then an app from where I can actually interact with that service once it's deployed and execute RPCs and all that. So what this service is, is a standard Rust service. Rust is our language of choice currently. And so all of the code is going to live inside of this main.rs file for those of you that are following along. So in main.rs, you'll see that a bunch of code is already going to be initialized for you. And this, for the most part, is going to look exactly like a normal Rust service. There's two things that you have to add as you're implementing. There is both a... You need to define state and you need ways to modify state. So state definition happens inside up here. You define a construct. For this calculator, we're not actually going to have any state but if you wanted to, this is where you do it. You just add variables here. So to actually define ways to interact with a state and do stuff, that happens within this implementation here. So you'll notice that there's two things. There's a constructor that's empty. You can add constructor variables here and in which you will. There's also a default RPC contract call that we define. All it does is it leads in your address and it will execute that RPC. We're going to replace this and make it actually function like a calculator. So the first function we're going to implement is add. What we want to add, we want to add two floats together. It's called an A and B and their sum is going to be a float as well. So to return in Rust, all you need to do is have the last line B return. Your return A plus B. Alright, so keeping it simple, we're going to do a few more of these. Subtract, multiply, and a divide. Nice. So to subtract like this. So that was pretty simple. Now we have four PCs to find and this is going to be a fully functional smart contract that you can let us do any of the four basic operations. And so you might notice that there's also some code down here. This is how you unit test your service. So we have a Oasis test library that lets you actually test your service before you deploy it anywhere. So what it does is it creates an account for you and then now you can use that account to create one of these context objects. Which again, if you're familiar with Solidity, context is exactly the same as message. You can do context.sender, context.value, all that stuff. Yeah, so then now using that context we initialize the calculator. Also you can actually call it calculator. Alright, and then now the only test we have is not really a test. It just prints out the result of saying love. Let's actually make some tests. So in Rust, you do that with this assertEQ macro So we have an ad. We want to add say 10 and 5 and we want the result of that to be 15. And similarly, we can have the same kind of stuff for subtract, multiply, and divide. Yeah, so you also need to provide a context so it provides two pointers to the context. And that should be it. Now we should have fully functioning unit tests for this service that we've written. That is going to validate each of these that we've written. How do we actually go ahead and build this? So let's go ahead and check out that it's going to that service directory that we built and from our CLI just run the system. That will work. So while that's going ahead and filing I'm going to talk to you a bit about how exactly what we've built here differs from a standard Rust service. And there's a few things. So of course there's that context that I talked about. So every method that you find needs to have this context as part of the managing measure. And that's just so all the good information about the same very value and all that can be done. The other difference is this derived pre-identation. And that handles message parsing for persisting things to voice as a platform and storage and just like loading and storing stuff to have things within your state. So the final difference is this main method which has a service macro. And so running oasis build that tells us that stuff is so that tells running oasis build to actually build the wasm binary file that we want to and that's what we're going to be running inside of the on-premise. So it seems like it's compiled. There are a few warnings. Those are because we don't actually use context anymore. Now that we have that, you can run those unit tests that we wrote by running oasis test. So that'll take extra time and let's go pass. Yes, so the tests are built because I didn't change the values. So let's go ahead and do that. 10-5 is 15. 10-5 is 15. 10-5 is 5. So now when I test it, there we go. It passed. I'm going to get one of these things too. There we go. Test passed, everything is nice. So now that we have this working service that's ready to deploy, how do we actually deploy it inside of an application? So let's go to this app directory now and you'll see this other file structure. You can build out whatever app you want to be in here. We have a couple examples on our website. But for actually testing that deploying and making on-prem all of work, everything you want to do is inside this registry code. When we have a service.spec.ts file, as we go ahead and open that up, it's going to have a basic default test. So here I'm going to cheat a bit and take some like replace it with some stuff. So what I replaced here is just our by default it connects to our production developer gateway, the OSS gateway. Here I've just changed it to point to a Web3 gateway and that way we can actually see transaction logs inside of our terminal. So how do you actually configure this stuff? First you have a mnemonic that you specify. Once you specify the mnemonic you also want to specify a pointer to where that local chain is going to be running. So I guess that was a good time to actually show you how to run that local chain. Now let's go back to the terminal. Again, super simple. As you'd expect, this chain should get that up and running for you. And so now you'll see that this is pretty much exactly the same as the Ganache CLI. It just creates a bunch of accounts for you and now it's listening for transactions that are happening against it. So going back here, now we've connected to that chain and using that mnemonic to create a wallet. So this is exactly the same as an interest.js wallet. And with that wallet you create a instance of a local Web3 gateway. What that gateway is going to do is it connects to that local chain to initialize and it's going to sign transactions that it sends with that wallet. For deploying a calculator instance now you have to provision it and provide it with that bytecode that was created. So I forgot to mention that. So when you compiled your service with Oasis Hill inside this target directory a calculator.wasm file was generated. And so we're just reading in that bytecode and passing it to your deploy function here. And so that should now deploy your calculator and create a calculator instance. And with when you initialize your repository with Oasis in it that also generated this basic test of deploy. So just make sure that after you deploy whatever service that you created is not null if now actually it's going to be running service. So that's not all we want. We also want to be able to test the four calculator contract calls we wrote. So let's do that. I want an add test. So how do we actually add? All you do is use the file to deploy a calculator instance to add. So we want to add some numbers 10 and 5 and then we want some for the other methods. So you can subtract multiply so that changes what's happening. So there we go. So now we have tests that are running. We have our local chain running and now let's actually test these tests. So are there any questions so far about that? Yeah. It's based on that. This target directory this was in file is not just going to be a standard wasm file. It's going to have some additional things from is you can see in this wasm 32 wasm 33. So in there there's going to be some noises generated. So what this does is this is one of the ones the actuals. So within the secure on clip when you execute a contract call things are actually written to standard in which the wasm that this file is actually going to go to view and so it reads from standard in which happens at this time. Then it checks which functions so the encoding method that uses C4 so it decodes that to C4 and then checks which of these four methods that you call and it also controls along with so yeah that's what you need the wasm the wasm is called to view you need to read and write this standard out so once the results running this is extracted then you write to standard out the output again C4 encoded and that's what you're going to see in the format that the client running from Wifi is not going to let me do this but yeah hopefully for somebody else who worked following along. So I wanted to now that I've explained a bit about how this happens I wanted to take a moment to try and show another thing that we're trying to do so hopefully this will be nicer with so what this is doing is it's going to run the same computation that wrote in Rust except this one is going to be in C or C++ so the way the point of this is to show how general purpose WASI can be and how to actually make WASI work to write smart contracts and basically any language so what's happening here is I've written a super basic set of functions the same set that we were just talking about but in C++ and so in the main method I'm doing exactly what I showed you in that auto generated file in your it leads from standard and it decodes from C4 and then whatever it encodes it checks what method is being called it calls the appropriate method out of the set of methods you define that happens in this block here and once you've actually figured out what method is being called it calls that method with the arguments provided through standard after computing that again it writes to standard out and so in C++ that compiles to WASM and have SDKs for compiling to WASI and so that's exactly what's happened here so the exact steps I can show you in this main file so first we compiled using a WASI SDK which is a hopefully a little SDK for compiling to WASI compliant WASM second thing that we did was now that we've compiled this file the way it was to expect compiled WASM files to be it needs to have the IDL interface definition language which is the equivalent of Ethereum's ADI expects that to be baked into this block so this second step here we convert our base calculator WASM file into a service deployable to a WASI stack how does that work well so that's super easy with Rust Rust has a library for modifying and adding stuff to WASM so all we do is you take your initial WASM file that was built and you essentially graph on an IDL which is something that you have to regenerate manually right now and we're hoping to build a tooling that will make all of these steps that have explained super easy but once that's done you now have a calculator dot calculator service and this is something that can actually run inside and be totally fine so to integration test then that comes to this last file which should look exactly like that unit test that we discussed for the Rust calculator where we configure and set up a GUI by pointing it to local chain and driving the wallet if you want it then you deploy by pointing it to that WASM file and then it's going to do just all any of the things you've been wanting to do yeah so now going back here so that hopefully showcases like how simple it is to write code in any language that can be converted to WASM in a form that Oasis can interpret it so that's actually what we're hoping to do we have our tooling and stuff to do things with Rust and Oasis is actually backwards compatible with Solidity and Viper as well so this demo for C++ that I showed you we're hoping to actually at some point in the near future extend it to support really anything that can be filed to WASM and that will come in time we want to have some developer to grant programs to people that are really passionate or are interested in any of these languages to help us build out these tools so if you're interested in that please contact me after so I guess the vision here is that right now it feels like a lot of things are pushing blockchain to replace existing infrastructure but the idea here is that existing infrastructure should be able to remain largely the same and then with minimal modification it should now be able to be run on in a platform with a capacity way so yeah let's code everything so where is Oasis now it has released a few SDKs such as that tooling that we've gone through today our devnet is live and we are now planning to have a public test test soon probably in a couple of weeks along with that it will be a bug bounty and people that find bugs will see you for prizes and soon in the next month or so we're also going to be having a staking competition for people that are interested in joining the network and running nodes and we're going to have a lot of support for that for developer support for developers support so the staking competition is going to be totally open if you want more information like to go to our protocol today it's protocol.org or follow us on twitter and so for people that are able to successfully attack open tokens and we can also contribute through community contributions we can write a lot of posts about us and have things up when tokens as well so yeah that will be really exciting so yeah there's a few links here for our website we're going to give out a plan here at Twitter so yeah so people have tried to follow the protocol to not stop at any point the rest of this time it's for me to help you finish building a popular