 So I'm here to talk about Smart Contracts as a service, probably a better title with the Smart Contract micro-services. So my name is Brooklyn Zalaka. I'm at speed basically everywhere on the internet. I am the co-founder at CCO at Fission, where we're building essentially a decentralized Firebase with user-controlled data for non-Web3 doubts. Of course, you can use it in Web3. It's all Web3 tech underneath, so that people don't have to worry about learning all of this stuff in the SQL system. They can just use it. I used to look it up, Zalaka. I love it here. It's so good to be back. I was so happy when I saw it.com. It was going to be here, and I have a chance to visit again. I'm a programming language theory and virtual machine enthusiast. And I used to do Ethereum R&D full-time on a grant basis. But these days, we're doing primarily IPFS. So I'm visiting from IPFS and Distributing Systems Land. I'm the co-author of a number of EIPs, including the EDM subroutine synthetic jumps, which we had hoped to get into this artwork. That didn't happen, but there's old researchers of interest, so maybe that'll happen soon. And also, the other one to really note here is 1066, which is what most of this talk will be on. The standardized status quo is for intercontract communication. In Ethereum Plastic Land, which is being ported over as well, this is east of 1050. The other thing to note here as well is this is ending up in a lot of other standards. So a few of the security standards, notably the family 1,400 security tokens, use this as a dependency as well. This is already finding a way out into industry, things like table regulation, et cetera. Last night, I opened Twitter and saw this tweet. So it sounds like there's interest in getting this embedded directly in microinsulidity and doing on-chain translation of these as well, which we have proof of contact code for on GitHub. So let's talk about web of contracts. So the goal of this project broadly is in three parts. First, write your lines of code. The more code you write, the more likely you're to introduce a bug. It's also development time, testing, expensive to do, verification on, et cetera. So you can have higher confidence in code that lives on-chain that you call into. That has been audited by, say, Quantstown or consensus diligence and has been signed off and the community understands how it works. And last goal is to make Ethereum more accessible. We have more semantic codes now that can be understood. You can both look at the flow of these codes through web of contracts or probably come back out to the user and then translate them into human-readable language, which time permitting, we may take a look at at the very end. High-level idea, just kind of like how on the web we have status codes that come along with every request, so like a 404. We should have these as well for smart contracts. This lets you do automated behavior or react to things in a smarter, more contextual way than just tumor faults or having some custom response type for every request. The other nice thing, because it all fits into a single fight, which means it's very, very portable, is that we can do things across different chains. If we have inter-chain communication, we might fit it at ETC, ETH, Eastbridge, and cross-sharp communication with ETH2. So obviously this draws a lot of inspiration from Unix and HTTP and the actor model. What all these things have in common, composition. We want to have contract composition rather than taking existing contract, editing it a bunch, and hoping that it still works the way that we had assumed before. Even if you have a fully audited library and then you go, audit that, and deploy it, you've broken a lot of the core assumptions. You have to get it re-audited. Ethereum's a shared system. Why aren't we leveraging each other's code? Why do we have 15 million ERC-20 tokens instead of most of that logic being calculated in a single contract? And if we can build these high-value, high-use contracts, is there a way to make money doing that? So Unchain microservices, something a little bit like this, where you can have contracts coming to other contracts that are all fairly lightweight and thin and do a single thing. Yeah, and that's basically what I just said, sort of an agile core technical idea. So today you deploy some sort of contracts. There's a bunch of these living on chain, but they're pretty much siloed, right? We're on this pictured system. You deploy one, maybe two, or three contracts and they talk to each other in some special way, and they don't really talk to each other, right? So we're on a shared system, but we really have a bunch of small mini blockchains inside our blockchain. And sometimes, sure, they do talk to another, like maybe that's crypto-kitties, and you're calling into it, but for the most part they're just kind of, there's a lot of duplication and a lot of things being redeployed onto the chain all the time. So what if we can break those barriers and call between them? So in this case, the two multicolored ones here are secure, verified on chain services. They can maybe talk to each other and other contracts can talk to them as well, use them as proxy, call it to them for authentication or to do some computation, do a lift, a curse, et cetera. So what do these codes actually look like? As I said before, they are a single byte, and if you break a byte in half, you get a nibble. So just like in HTTP, you'll have, say, 400 grades or 200 grades, we have the same, that they are flipped around and that's mainly to make it easy to decompose them programmatically. So here is 0x41, the first four bits are the category, the last four bits are the reason, and if you have something where the category is 0, this is the same case as having 400 in HTTP, where it just tells you that this is a user generated or user side error, client error, with no additional context. So this one just said that, the generative case for the e-reason. This breaks things into a table. So it's actually more structure than this. It's all odd numbers are successful, even numbers are failure. So the columns are categories, so things like time logic, or authentication, or negotiation governance, even off-chain flows are captured on here. And the rows are reasons, so you can say, for example, we have the two row, which is searching and matching and awaiting, and together we get, that you're awaiting a match. So both we can do this, reading them out, decompose them, you might have to memorize 16 by 16, so 32, as most of you memorized, the whole 256 code space. There's the helper library as well on NPM. It lets you write these in a more human-readable way and process them more programmatically and get a little bit more information out of them. So here's some emails for category reason that you can then stick together, pull apart, and just when I also say, this needs to be category four and one of the following reasons, for example. And you can also automate reverting as well. So reverts are built right in, full supports, in this case, this required case, as it needs to be an odd number, otherwise it will reverse when it gets the response back. With a hard-put message, we can also automate the messages as well with localized font change translation, which again hopefully we'll have time for at the end. So toy flow for contract messaging. So we have three players in this scenario. We have a user, the robot may be a proxy contract for the user themselves, some intermediary, and then a token. We ask for send to the by-request, back as prop given to cross, and it's stashes that with some, you know, this proxy's asked for a buy of this amount. But in response to it, you know, we're not ready yet, but we will ping you back when we're ready. So this is all on chain, we're all waiting for events, we're just gonna ping it, pulling it with the server, we're just saying, I'll call you back when I'm ready, proxy, hold on to that, and then probably get the backup to the user. Sometimes it goes by, user gets anxious, you know, is this done yet? So they say, you know, is it done yet? And it says, no, I don't even have to go and check, let's just revert, pretend this transaction never happened, and that's a no. Sometimes later, we come open for business, maybe a lockup period is done, or we've actually launched the thing, and it says, ready, you know, are you still interested? And yeah, in the meantime, I've had a bunch of orders come in, great, let's be for that, that's already been completed, and probably a set of the user. There's been some discussion recently about adding messaging, like an inbox for while you were away from the chain to the blockchain, or into wallets rather, and then we can then probably get that out into that system as well. For state list service contracts, again, this is audited efficient library code, mentioned before, if you override functions on a library, you just get a slivered library, they say, you know, it's been all checked and all good, and then it starts overriding methods. That audit no longer holds, you may have broken something, right? If you made a small change like changing the name of a token, that's probably fine, as soon as you start changing behavior, who knows? If we deploy these on-chain, especially for high value components, we're doing things with finance and hundreds of millions of dollars, then we can get these as a community, verified and checked, and then they live on-chain and don't get changed. So we know that this is the exact code that we expect. Why not, I'm actually interested. Why not? We deploy safe math. Safe math is used so much, it's impractical, because junk is so cheap and a call out is more expensive. But for anything more involved in that, it starts to make sense quite quickly. So here's, again, a simple toy example. So we have a token, which is just the things that you normally override, calls out into a stateless year 20, makes requests and says, yeah, cool, you're in the range to do that, you have enough balance, et cetera. And then we can check with, say, you're C902, is this transfer restricted? And they say actually this, the person you're trying to transfer to has been banned, so you're not allowed to use transactions. So breaking things out into reusable components, that 902 could even be, well, which we'll look at in a moment, a KYC service, let's say, so that you don't have to KYC in each smart contract, you can just send that out to another service provider, which is a stateful service contract. So sometimes it's not the behavior-vesting important thing in a smart contract, but the data inside it. And calling into that might be valuable, not just so that you don't have to KYC users on a per token basis, but so that you don't have to do that at all, you don't have to worry about it, somebody's in the KYC once, it's very good to go. So, in this example of a token, it checks with one of these validators, it sends them a message, and this is actually a real-world scenario from security tokens. So we have a cross-border trade between Canada and South Korea, and they both have different regulatory requirements, and you need to be able to match both of them. And these requirements sometimes change, so you need to be able to keep, just call out to a contract where the independent logic is kept separately. So you call out to the Korean one, that comes back and says, yes, you're in the time, you're about to expire, don't worry about checking with this other service now, because we don't need to check for an override, they're actually, they're okay. And then we check with the other regulator, which calls into some database, we get back, yes, they're in the database, propagate out a more specific error for this use case. So it doesn't have to probably get the exact same message, we can change it as we go, and then come back with, yes, your transfer smoothly. Some quick thoughts on making money with this, so it's not that you can't, or that people aren't charging for function calls today, you can when people are, but I'm surprised that it's not happening more often. Especially what I've heard fairly recently that state rent is now not happening, but it's not entirely a terrible idea in collecting things off-chain, or getting things off-chain that aren't used very much or don't have high value. So in a company like this, it makes sense to some degree where you collect value to prove that you are valuable, but even without that, we can support the development efforts of high quality, good audited, and pay for the auditing of the shared smart contracts. So that we end up with a better, more secure chain overall, right? It benefits everybody, and it can overcome the tragedy of the comments because we're not anymore saying ultramistically, please get this audited and put it on chain, we're saying we will get this audited and put it there, and then we will recuperate that initial investment. So this can be done in a couple different ways. You do a permit location, sort of you know, like AWS might be a side charge, which is mostly what you see today. Or you can buy licenses on chains. This might be per contract or per provider. You could buy a subscription model, make it permanent, okay, for a certain number of calls or a certain number of blocks, let's say, right? So you're okay for the next month. Three-and-a-half minutes to get through the user low-class feedback part. So this is something that we were talking to a few of us by integrating, but not that MetaMask has a fucking system. Which we heard about yesterday. This might be something that we can just implement ourselves. So on chain localization, actually, we'll go back one here. So we have a localization preferences, singleton on chain, which actually exists, and then a bunch of localization for these 256 codes. That's a reasonable number to get translated. We have curbs translations as proof of concept in English, Spanish, and pirate, and are hoping to get more as time goes on. We have a couple of partial translations from other languages, but not the full code set yet. So let's look at a success flow. You're a Japanese speaker, and you want to interact with this contract through a wallet, so you send a transaction, it does something, and it turns back to sales code. And now you're done, right? This has come back in the response. We don't have to pay for the rest of this because it's truly a read. So we go to the translations contract, or the rather, essentially, look up the TX origin, transactional origin, user, and look up the row for them, which says that they want Japanese. They grab the text for status code 11, return the text back up, and just lay it in the UI. Similar for reverse flows, as I mentioned earlier, instead of hard coding, strange, revert, we can do a lookup, and then reverse. So similar flow, we send a transaction, and then this contract needs to revert. So we're going to revert with 4.0. We look at the text for that. Again, look at the TX origin. Grab the text and propagate it back up, and it will show like that. So I, as a developer, don't have to write all the translations myself. They exist, people can register their own, and then say, I'm going to use this translation for all of my messaging, right? If you want Ethereum to be widely used and accessible to everybody, like my Czech grandmother doesn't speak English, we did a quick analysis of why are the reverts written in on chain, and they're predominantly English, like overwhelmingly, with a bit of Chinese, right? So that's simply all for much. And with this, we could absolutely get that done. Yeah, probably get it like that. And that's all for me. Thank you.