# ERC1066: Better UX & DX in Just One Byte by Brooklyn Zelenka (Devcon4)

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2019-10-09
- Duration: 20:23
- Topics: blockchain, smart contracts, distributed ledger, Science & Technology
- Watch: https://streameth.org/watch/yt-N_QdraCtsMc
- YouTube: https://www.youtube.com/watch?v=N_QdraCtsMc

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/4/erc1066-better-ux-and-dx-in-just-one-byte

This talk discusses ERC1066: a common set of Ethereum status codes ("ESC") in the same vein as signals, tagged tuples, and HTTP status codes. They provide an opt-in way of enriching payloads with a finite set of shared metadata. ESCs improve smart contract autonomy, UX, and DX, with clear application for localization, wallet integration, and contract interoperability. Code layout, Solidity and JS helper libraries,  and tooling are all designed with developer experience in mind. While much broader than errors, ESCs are fully compatible with revert-with-message, with the added bonus of being localized for the end user. Come see the difference a byte makes!

Speaker(s): Brooklyn Zelenka
Skill level: Intermediate
Track: Developer Infrastructure
Keywords: UX, DevEx

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 4 was held in Prague, Czech Republic on Oct 30 - Nov 2, 2018.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

I talked today is about the kitchen suites and how one bytes can add a lot more context to all of our smart contracts so a little bit about me I'm Brooklyn zelicah or EXPEED basically everywhere on the Internet's I am the CEO and chief scientist of the special projects in decentralized engineering company or Spade Co we are in the Tachyon cohort with consensus to fund specifically this work we were entirely an open-source and our grant based I my main background is I'm a programming language theorist and practice nerd and was previously working on security tokens and a formally verified language at thin Haven I'm also the primary author of a couple ERC's including 1066 now Scotia sirs what we'll be talking about mostly today and community stuff if your 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 cerium is in super early days which means that there is a lot of pain points which broadly fall into three categories and 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 leaves 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 code should be - 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 syntax 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 Finn Haven 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 ok range so here's the naive version the first version that we had built you have your token and it needs to talk to validate or a 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 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 whitelist 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 when I say 203 is probably good enough and we turn you up they're allowed to do that thing great there's this great Conor McBride quotes that about boolean blindness boolean czar 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 1066 fission codes which help us do smart contracts that look more like this so it's something like HTTP set HTTP 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 halls 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 I 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 Michigan State for example this ICO is not open yet but it will be later and yes similar to HTTP 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 a lot more information about this is at fission dock codes and this was previously titled if their name status codes I will talk about why we changed the name a little bit later backronym czar 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 nine to two fourteen hundred and fourteen sixty to 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 website 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 fourth 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 what does this actually look like so this that slide I showed before and we're saying that we can take these boolean x' and turn them into something 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 writes 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 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 change logic to permission logic to something comparable within 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 revert for example so you don't it's not an either/or distinction and let's talk a little bit about the structure in the layout so a nibble is a half byte because programmers in the seventies like the puns so here's hex 41 breaks out like this the upper nibble is your category so [Music] things like you know this is time-based logic or as an authorized ation etc the lower nibble is the reason which is you know this passed 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 it's just the same thing as the reason alone so the code table if you think of it as a two-dimensional grid it's 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 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 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 he was 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 0 1 through 0 for range let's say and we're doing it you know playing 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 a1 otherwise it reverts with a hard coded message the reason that in the slide it says message and then a little star is the next phase of this project which we'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 low money bag the exchange in the middle and then the robot icon is a proxy for a person interaction interacting with it let's say wallet and we say I'd like to buy some of the stokin and that goes through says hey cashes then says hey I'll call you back when I'm ready right don't call us we'll call you and I guess propagated back up to the user and the Dex knows that it's waiting around some time goes by and the users 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 bye for all of these different users because it still hasn't heard a cancel order on them it says yep cool that's a greeting completed propagates that back to the user and the user can be alerted with a message directly in their wallet so I believed it too a few times now translations because we have one byte 256 codes that is a reasonable number to translate so we have a theory my general-purpose code to human translations in any language anybody can create 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 are standardizing on printf style template strings doing string interpolation on chain is very expensive but the ERC 1444 specifies doing this in the clients 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 the beginning of the year you really just gotten out of gas error which was not very helpful some time went on and we gots 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 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 has 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 financial agent flow here we have the user like you get something back in Japanese and they're talking to a smart contract and we have a wallet in the middle so I'm gonna be very clear we don't have a meta mask 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 the little purse people gets confused so you send a transaction over that makes a request and it's not a contract and then we get back a status code which is not very human readable that part if it's a mutating request and you know they've been charged gasps we don't want to incur a gas cost for doing 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 as a proxy for words 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 it 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 etherium we have GRC 1066 and 1444 which gives us translation and integrations with wallets and gaps and you know so on being one bytes that runs on every computer ever so we can do this entertain and do message passing across to you know let's say the et Cie 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 aetherium 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