 My talk today is about the fission suites and how one byte can add a lot more context to all of our smart contracts So a little bit about me. I'm Brooklyn Zelenka or Xpeed basically everywhere on the internet I am the CEO and chief scientist of the special projects and decentralized engineering company or spadeco We are in the tachyon cohort with consensus to fund specifically this work We work entirely on open source and our grant-based. I My main background is I'm a programming language theorist and correct this nerd And was previously working on security tokens and a formally verified language at Finhaven I'm also the primary author of a couple ERC's including 1066 to ask us what we'll be talking about mostly today And community stuff if you're ever happened to be around Vancouver I'm the founder and organizer of the functional programming meetup out there and Run the technical white paper club, which we are hoping to move online. So please watch for announcements on that and join us for the live stream So Ethereum is in super early days Which means that there's a lot of pain points Which broadly fall into three categories end user feedback is almost non-existent you either get Back that it succeeded or it failed and that's pretty much it The developer experience Leave something to be desired Debuggers are very low-level. You just have a step-through debugger. You get you know core dumps That's pretty much it you have almost no feedback We're writing for the machine and not for humans coach should be to yes communicate with the computer but it's also for communicating with other developers so that when you leave the project other people can understand what's happening and Even when you're doing a pull request you should understand everybody else's code And solidity and other languages are still not mature yet. They're changing a lot, which means that we're getting new cool things that are making life better, but we're There's quite a bit more left to do so just this year. We got constructors in tax and solidity Revert with message and a bunch more changes and then the third area is smart contracts They should be these autonomous pieces of code that understand how to react autonomously with very little human involvement But we're not there yet. So I think I can sum this up by saying that lack of context is the mind killer So a quick motivating example a lot of this work comes out of the security token platform we were building at my previous employer Finhaven So we needed to do a lot of authorization checking So a bit of context first. This is what a validator looks like you have a caller Which might be a human a smart contract or another validator that calls a check function and then returns a status back And then that's the actual code obviously Here's a quick reference implementation just to give you a sense of how this actually works so we have This is just a you know bog standard ERC 20 token that we've added one line to this is okay And then the validation call and the validate itself is just a helper function that calls into a validator and is okay checks if something is Is allowed if it's true or in the later version which we'll see in the later slide if the status code is in the okay range So here's the naive version the first version that we had built You have your token and it needs to talk to Validator or guard and you say hey am I allowed to do this and it needs to talk to some others because you might have a White list that's maintained between several parties and you don't want to duplicate that data over and over and over again so you need to check with several Several different organizations Worst possible example, but to kind of give you a flavor is Equifax could Maintain a white list of people that they've checked their ID and now you have your KYC done without you having to do Do that check yourself so it delegates this call on and we get back a no, but it's not a an actual Exception right it's just a false so don't explode just say no they're not on our list So you go and you check some more and this one says yep And then you have to also check everybody else too because we just don't really have enough context So we say a two out of three is probably good enough and return. Yep. You're allowed to do that thing great There's this great Conor McBride quotes That about Boolean blindness Booleans are great, but they just don't give you enough context You need to understand the exact Situation in which the Boolean was generated to know what it actually means hence your C-1066 vision codes Which help us do smart contracts that look more like this so it's something like HGP set HGTP status codes It gives you something more than true false or revert and A nice analogy for this is if you think of your smart contract as nodes in a graph of calls This is the edges and the smart contracts are the nodes so today Typical flow is you take a bunch of open zeppelin Contracts kind of snap them together to create one. We're saying that's great fully compatible with that But if you need to have two or three or four of those talk to each other It would be good to have some more context about what's happening on those other nodes Much like you would have in say a microservice architecture on the web So this is a common vocabulary for smart contracts. It gives us richer context About what's happened on the other side of a function call You can tag arguments or return data with some metadata about what it means and Expose information about an internal machine state. For example, this ICO is not open yet, but it will be later And yes similar to HGTP status codes. It's a different problem space So we don't have you know 404 not found or 500, you know error with You know internal errors Because it's a different different platform with different needs so Longer information about this is at fission doc codes And this was previously titled Ethereum status codes. We'll talk about why we changed the name a little bit later Acronyms are awesome. So this is the fluid interface for scalable smart contract interoperable networks Not to be confused with the fluent interface We have some organic traction so it's already required by three RCs now under two fourteen hundred and fourteen sixty-two 1404 is exploring it in the github issue. We've been talking to a couple Well-known major players in the space We're just waiting on the okay to make those announcements. So keep an eye on our websites and we are part of the consensus tachyon Accelerator through the open-source R&D grant program We're working on integration with common tools We have a forked version of my crypto that I'll be showing you some slides from Later that will be pull requesting into them and we're looking at integrating more broadly as well And we've had a few bounties and more are coming. So where does this actually look like? So this that slide I showed before We're saying that we can take these booleans and turn them into something with a little bit more context So that we can do things like skip checks if you know, for example, this is an age range We don't need to do this middle check anymore and we can also recontextualize responses back so this bottom right Image where we have the little graph saying, you know, this is in a certain range The further down the call stack you get it You tend to lose context about the broad picture, right? You go from the the forest to the trees and as that propagates back up You may want to recontextualize with something that's more about your specific use case So in this case we go from range logic to a permission logic to something compatible with an ERC 20 We're very focused on developer experience design We need to have a very low cognitive load make this not hard for people to use And easy for developers to meet to communicate with each other I would do this by adding a lot of structure, which means that you have less memorization Fewer lookups and your code can help you out a lot more because you can decompose what the code is and make smart decisions based on that We have a human readable Code helpers in the library It is compatible with existing patterns Is fully compatible with Rivert for example, so you don't it's not an either or distinction And let's talk a little bit about the structure and the layout So a nibble is a half bite because programmers in the 70s like the puns So here's hex 41 Breaks out like this the upper nibble is your category so Things like you know, this is time-based logic or authorization etc. The lower nibble is the reason Which is you know, it's this past this fail are we waiting on somebody else is somebody waiting on you, etc and We get this extra nice property of the general category zero is the same thing as not having The upper nibble at all, right? It's just the same thing as the reason alone So the code table if you think of it as a two-dimensional grid is like this the columns are categories and The reasons are rows It makes it very easy to look up a Code that you're looking for or to decompose a code that you've received So in this case, we're awaiting and something with search or matching logic Let's say in a dex you're waiting to be matched in the order book That's two three awaiting match Here's examples of some of the helper Helper code so we have enums for a category and reason Ways to do inclusions so to take two of these and stick them together either the enum or just a raw number And you'll see the third one there says app code There is a way of if you structure your application specific Enums in the same way as the reasons then You can embed that in and automatically get a status code generated without having to say this is an application specific code Use the a at the beginning You just use the app code function We have functions to pull apart status codes so to decompose them to make smart decisions on things So you can say I'm only really concerned about Authentication everything else should be a fail and my reason should be in you know 01 through 04 range, let's say And we're doing it, you know playing around with masks, etc. Just to keep things very efficient and Again totally compatible with require statements. So this is require okay, which means that the code must end in a one Otherwise it reverts with a hard-coded message the reason that in the slightest has message and then a little star is The next phase of this project, which I'll be talking about in a moment We can do automatic translations in any language with no No extra code from the programmer So let's look at one example code flow So this is a dex. You have a token, which is the little money bag the exchange in the middle and then the Robot icon is a proxy for a person Actually interacting with it. Let's say wallet and we say I'd like to buy some of this token and that goes through Says hey cash is that and says hey, I'll call you back when I'm ready, right? Don't call us. We'll call you and That gets propagated back up to the user and the dex knows that it's waiting around sometime goes by and The user is getting impatient. So it says hey is that done yet? We don't have to check the token We can just automatically revert and say no We'll call you back when we're ready Later the token is now open for business. Somebody flips that bit that can now talk to the dex and say hey I'm ready It can then say buy for all of these different Users because it still hasn't heard a cancel order on them says yep cool. That's a green and completed Propagates that back to the user and The user can be alerted with a message directly in their wallet So I've alluded to a few times now translations because we have one byte 256 codes That is a reasonable number to translate So we have a theorem wide general purpose code to human translations in any language Anybody can create a translation and you can use whichever translation you like. So this is a bring your own translation situation or you can use one of the in big scare quotes official ones that we're producing Create your own share them with your friends write lists of curations You know, etc make an emoji one It's all in utf-8 and we're standardizing on printf style template strings doing string interpolation on chain is very expensive but The ERC 1444 Specifies doing this in the client. So there's a standard way of returning up to the client to the wallet or the clients The template string and the arguments and then you can do that all in the UI Revert over the last year at the beginning of the year. You really just got an out of gas error, which was not very helpful Some time went on and we got Revert with reason so you can hard code a message Typically in English. I've also seen Chinese That you know in this case player doesn't exist That's great, but not everybody speaks English, especially if you want to make this a truly go global System usable for anyone This needs to be localized internationalized So using this system and then an integration into a wallet You can have something like this Where it's not just that it's failed and doesn't just tell you why it does it in whichever language and Contextual to your specific use case So how do we actually make that happen? This is the broad architecture You have a requester, which is either a person or a smart contract a singleton localization preference Instance on chain and then a number of localizations So typical translation flow Here we have a user looking to get something back in Japanese and they're talking to a smart contract and we have a wallet in the middle So I'm going to be very clear We don't have a metamask integration yet We're going to be doing a pull request against them, but this isn't to imply that they're that this exists with them today It's just when we use the The emoji which is a little purse people gets confused So you send a transaction over That makes a request into the smart contract and then we get back a status code Just not very human readable That part if it's a mutating request then you know, they've been charged gas We don't want to incur a gas cost for during translation, which is just purely a lookup So we do a second request To that singleton it looks up the transaction origin the user that's actually looking for this It looks up what their translation preference is so there's a proxy Forwards that on to the correct Translation returns the string and that bubbles back up to the user and then looks something like this Translating revert. So let's say you're doing Developments and you don't you know, you just want to get this directly in the console. It's pretty similar Right do the thing here's a transaction Then internally to the smart contract says revert with this code. So it's going to look up the string Look at the the originator of the transaction Grab the text and back up it goes in a revert so we have some further directions as well for the future Because this is fairly portable What we have today is we have a theorem we have ERC 1066 and 1444 Which gives us translation and integrations with wallets and dApps and you know so on Being one byte that runs on every computer ever so we can do this interchange and Do message passing across to you know, let's say the ETC peace bridge or across to our chain etc and With the web Because we can map 256 status codes into the 63 or so HTTP codes that there are we can have automatic HTTP Ethereum to HTTP web bridge and sessions possible Sessions or multi transaction sessions as well. So here's a list of links Awesome. Thank you so much