The Future Is Readable: Uncommonly Sensible Perspectives on Protocol Design & Tooling – Isaac Ardis

so my name is Isaac and I'm here on behalf of ATC Corps and theorem classic labs we're headquartered in San Francisco and we have developers working remotely like me around the world and I wanted to trace today an idea and a theme of readability through through our team and through the work that we're doing both as a priority that we have as developers as well as a characteristic that's derivative then of that priority both in practical and architectural aspects of the code that were that we're building we think that it's valuable and we think that it has diverse applications so here are just four different connotations or potential definitions of what we might mean when we say readability on the Left legibility that was scrawled in my chicken-scratch handwriting and it might be kind of hard to read that's one interpretation of what readability might mean but because this context has a lot to do with computers and because computers have fonts and abstract abstract ways of dealing with words we don't have to worry about legibility we have Helvetica and Roboto to do that for us the second example you can't see and that's because it is either invisible or or it doesn't exist at all and because we're working in an open-source context that's not going to be the connotation that we're talking about the work that we're doing because it's open source is inherently invisible and that's one of the things that makes it what it is it's one of the defining characteristics of the work and the technology that were that we're applying ourselves to well written it is another connotation of readability and I want to say that things can be well written but not necessarily readable so if you think for example about about maybe a dense philosophy book or a dense science paper those can indeed be well written for example like gravity's rainbow by Thomas Pynchon I mean people will reference it and talk about it but nobody has actually read the whole thing because it's not readable although it is well written so that's not exactly what we're talking about either the fourth example is a blaze bar and unless you speak German that will also be unreadable to you and that's because it's not in a language that you're familiar with and that is going to be relevant to what we're talking about today being able to work with a language that you're comfortable with and that you can use is a facet of what readability is and there are more interpretations and connotations of readability Dave Cheney has given a couple of talks he's one of the core goaling contributors and he's also talked about simplicity productivity for developers as characteristics of readability and good naming for example but instead of trying to define readability I think another approach that we can use is to ask what does readability look like so that we can know it when we see it and we can then maybe know how to work in ways that we can build it and I want to say that readability is about having the right level of abstraction in the right place and because this is if Denver and not Art Basel when we talk about levels of abstraction we are going to be talking about words specifically that's what words are and so don't be fooled by the progressively abstract and Mondrian we are going to be talking about words but the next nuance and really important essence of this understanding is the word right what what does it mean to have a right level of abstraction and how do we know that it's in the right place and I want to say that we'll know it's right based on the context and the purpose that that is intended and is inherited as as a part of the space that the document that we're talking about is living in so we need intention and purpose to understand what readability is here's an example of something that is indeed readable if we're trying to navigate and move around the world this is something that can help us but I think it's an example of something that probably is at a level that's typically too high of an abstraction this will be useful if we have an airplane and a good stopwatch and we want to fly direct to Rome from wherever we are we can do that but if we're limited by we don't have a plane or we don't have enough gas or something happens on the way there we won't be able to get there so in this case the job that this sign is doing is maybe not necessarily actually playing the role of wayfinding I think it might be serving a slightly different purpose even if that purpose is only letting us know how far we wait how far away we are from cities and to be something you can take pictures next to we're missing it there we go all right so here's another example of maybe what readability is or is not this is taken out of a historical context in New York subway systems an example on the left is something that is probably too detailed there's too much information there and maybe it's not structured in a way that's intuitive for the purposes of the user at least not as well as it could be and has been famously replaced by the example on the right which is iconically readable print president Helvetica and which has come to typify and actually symbolize the New York metro today but the New York train system is not even today without flaws as far as its signage I found this on Twitter and you can see the example on the left is at Penn Station and we have what might be wayfaring instructions but they're presented in a way that that perhaps reflects a shifted intention from actually helping you get where you need to go and that's what I noticed in the comment on the right where the commenter is saying that actually the purpose maybe of these signs has changed maybe they're not trying to help us actually get where you need to go but they're serving maybe as an advertisement for the concept of travel which is particularly ironic because your audience is going to be already in the train station so why readability I'm going to take go through I am going theorem as an example and talk a little bit about readability and rideability in this in this context so it's important that we have purpose for code you do your job and do it well and that's right but in open source code getting the job done may not be the entire picture and maybe readability is a part of a bigger picture that that also involves writing and so one of the the interesting and very self apparent facts about readability is that things will be written more often than they will be ruined things will be written far fewer times than they will be read and this is true for books in a library they'll be written once they'll maybe be edited a couple of times but and then recompile but they'll be ready and then they'll be read and so there's a disproportion there that as writers it's important to keep in mind keeping in mind as creators it's easy to fall into a hole as a writer without working to remember that readership is one of the primary use cases for the words that that you're managing and in the context of open source code not just is readable reading and writing a part of the case but readership and ridership is also a part of the case and that's one of the things I want to point to here and I want to point to the long tail distribution of writers that happens at go aetherium so as you can see this little bar graph reflects my hypothesis about a long tail distribution of writers which says that there are a handful of core writers who are writing the vast majority of the code over the vast majority of the period of time that this code has been in existence and there there may there are a lot more contributors but the the majority of those contributors will be contributing small amounts and compared to readership again this is the disproportion that we expect we expect to see more readers and we do see more readers than writers in the case here we can assume that stargazers are at least pure readers even if they're only reading the directory structure of the repository and maybe the first few lines of the readme that still counts as reading but one of the beautiful parts of what open source is and can do is the concept of forking and changing and contributing and this is something that we hope actually for our projects for the most part and so for kurz we need to understand both as readers and as writers and so what does readability do readability tells us a story that we can understand in years and it enables and encourages writing so at EDC core and aetherium classic labs were invested in aetherium classic and aetherium classic is integrally and importantly related to aetherium we are we're a fork of aetherium we're made maybe it's the other way around but we are invested in reading and writing the etherium protocol working with the tools and being a collaborative part of the ecosystem not just the ecosystem but the actual protocol itself the mantra for aetherium classic over the past year and maybe even more than that has been interoperability and that's something that we're proud to say that we have that we have today and and and that's because it's it's a function of our relation to the ecosystem and so as we're working with and towards the etherium protocol we're inherently invested in characteristics like extensibility like interoperability and configurability and accessibility for the code and this isn't just good for us as core developers working on our classic implementation of the protocol but it's good for our community and it's good for the etherium main foundation community and we're not alone theorem classic is far from alone in being a configuration alternative or at least another opinion about what the etherion protocol can do this is a very simple network crawler that I ran for a couple of hours and was able to find 239 distinct network IDs out there living on the dev p2p space this is a bare minimum right this is network IDs this doesn't reflect chain ID so keep in mind that even aetherium classic isn't included in this number so aetherium classic labs does a lot of things we're an incubator and an accelerator for startups based in San Francisco we're investors and we're interested in exploring the space and lending strength and support and momentum to projects that we believe in and think have value we're interested in building partnerships and collaborating because synergy and mutual trust and attitudes of openness are going to be beneficial for us and for the community and last but not least were interested in development and we're strongly invested in development and that's where I can speak to you today and we have a good number of the core team here as well so please come find us we have a booth upstairs we'd love to talk to you about some of the development things that we've been working on as well as some of the more professional partnerships and things like that we do have representatives who can speak to that as well but it's worth so I've got these three different facets that I want to touch on from the development perspective the first is protocol provider of specifications this is what I'm most familiar with because this is what I'm working on we also have twos what I want to say are two sides of the same coin so to speak which is contract development from the writing perspective and the compilation perspective and then the consuming of those from the tooling and API perspective and all right so I'm going to start by talking about the protocol specifications in the protocol provider that I work on primarily and that are the primary endorsement as far as protocol providers go from our company which is multi guess multi guess is downstream Fork of aetherium go aetherium and it serves e.t.c well trusts aliy reliably and with the multi in the name it also serves a multitude of other chains and that is by design and these are chains that are not just research and development chains but also production chains one of the things about this client that's worth mentioning in the context of readability is that is written in go which is famously readable as I continue on with my with my example here for those of you who may be initiated and familiar with some of the clients in the ecosystem parody may come to mind parody is written in rust and go compared to rust will have different answers probably when it comes to the question of readability because go is simple go works to remove magic and it tries to be accessible and productive so I want to talk about one of the things that makes multi get multi goth compared to its upstream ancestor if your iam going through and talk about some of the design trade-offs that that we're looking at and and happy to talk to you with talk to you about today this is the configuration file and I'm sorry if that's a little blurry ironically I can't tell from here if it's just me but I'm sure it's just the resolution at the picture but you can see here that there's just a couple of lines and those lines are for configuration values for the etherium go aetherium client and a fork is usually a composite almost always a composite of EIP z IPS our improvement protocol specifications and the EIP space in the EPI process is something like the legislative body for for the etherium platform and the etherium protocol and that's interesting for me and for us today because it's written in english and in the if because of that it's accessible if you don't write code at least it's mostly english you know there's a lot of math and technical jargon but if you can get past that you don't need to be familiar with the nuances of any particular coding language to be able to work with it and to be able to make an impact on the protocol and so a fork being a composite of these these get bundled up and configured in the client like this and so as you can see here they represent diverse sets of a IPS and I've taken the Byzantium it represents nine different a IPs and these are a IPS that do different things sometimes they're related and sometimes they're not and navigating this for a reader for the NGO etherium code base can be one of the challenges and is one of the notable architectural decisions for the client as well so you can see here that we're configuring new op codes we're adding pre-compiled contracts we're adjusting the difficulty balm and for somebody exploring this code base if they use their ID to do find usages and where does this field value happen in the code what does it actually do they're gonna find logic implementations that happen in the EVM that happened in the interpreter adding new op codes that modify how the revert is added and whether states can be modified or not they're going to find difficulty being delayed they're gonna find block rewards being reduced they're gonna find actually the transaction receipts being managed differently and this can be a hurdle why these things seem unrelated why are they using the same parameters so here's an example this is the etherium go aetherium house and h IP here stands for home improvement protocol and as you can see we've got the garbage disposal wired on the same wiring with the in-floor heating in the bathroom and we've got the doorbell connected to the speakers and it's all on the same all in the same circuit and before before you've got to imagine that that a contractor comes into this house to like work on the doorbell right and he thinks it's too loud to read we'd like to change the chime or something he comes in and maybe an hour a couple hours later maybe a day later maybe days later he comes to you and he goes you know well I've been testing the doorbell and I can't figure it out but the bathroom is getting warm by doorbell test seem to be passing but the bathroom is getting warm and whenever I do run the test I hear this whirring noise coming out of the kitchen it was pretty angry and so but before before we make too much of a joke of this and I don't want to I'd I'm not trying to pick on the etherium developers because this is not completely insane they are good developers they're they're very good developers and I really admire them and I've been working in parallel with them for years now and they know exactly what they're doing and they have very legitimate reasons for doing it like this and they know what I mean they know what these reasons are and so when I was pulling these slides together this conversation happened on Twitter just a couple of days ago which was just absolutely perfect because here's Peter who is the lead developer for a 3m go aetherium with 1,200 commits he's the number two guy on our longtail graph and he's saying that for me the unit is the fork right that and that's that's not without reason right he knows exactly what he's doing and and as you can see here he says you know these are upgrades these are a IPs why would anybody not want these and I think that more conversations can be had around this tweet I think that this might be a bit of a simplification and/or an exaggeration because if we start to ask questions like is a difficulty bomb an upgrade and how do we manage that is just delaying that actually an upgrade how about reduced block rewards is that an upgrade and if so why so this is how multi death handles these these configuration options instead instead of using fork based configuration variables and interfaces we've exploded it we've unraveled these Forks into their composite improved protocols specifications so that we can speak articulately about exactly what we want our client to do and this is good for aetherium classic and it's also good for the multi and multi Goff is good for the many changes that we hope to be able to target and I want to be fair about this analysis I'm not you know I want to present this as a pro and con and as something that is a balanced set of architectural trade-offs because it is clearly working for a three I'm going through him and for us it is clearly working for a multi gun to do it in a different way so what we can see with forks is that we get consistency we get safety netted specification implementations and that's an example of what just happened this week with the EIP 2200 bug that was found we get control the developers have control because there's a little bit of obfuscation and there's a little bit of initiation that needs to happen before you can work with the code base you get application level testing but what you don't get are an extensible set of business use cases you don't get an extensible set of articulate articulate able test cases and you have gated maintenance change ability whereas with features we find that we get configurability we have specification implementations that are really true to spec and we can prove that through application and feature level testing which is exactly how this bug was found we find that we get accessibility because for somebody reading this code they can actually go directly from a configuration value to a specification by name and that should be one-to-one we find that we can support generalized business use cases have better more descriptive at least testing and so to finish off with this comparison and back to our wayfaring and navigation guides example and the New York City train system maybe I think it's fair to think about a few IAM going through him as the as the case on the left here as exactly how to get from point A to point B if you want to fly from here to wherever aetherium is you can use that client and get there it's an it's an and in doing that it's an application of the protocol it is one way with this in which this protocol can be applied to one network or a handful of networks if we include the test networks whereas with multi death we're hoping to build something near to a protocol implementation which is to say something that can become a tool for using the protocol if you have questions on that I'll be around I'll be wandering around we'd love to talk to you more about that but for a matter of time we're gonna move on to some other things the next two facets which I want to handle in tandem because they really are two different aspects of the developer lifecycle for somebody who's going to be what I'm gonna call a protocol consumer around the etherium based blockchain so I'm gonna start with the EVM LVM project but before I do I want to sort of frame why I'm talking about these in tandem they're in tandem because when you're writing your contract right now the the the primary way that you're going to do that more often that is going to be with solidity which is going to present a learning curve and it has its own set of limitations it's relatively young and and it comes back to language this will probably be a new language for you if you're coming to the network and haven't been initiated and also being its own unique language it has a distinct set of tools and so what we're hoping to do is to be able to explode the number of languages that you can use on the front end in contract development and compilation and then match that suite of accessibility experiences as far as languages go on the other side when you're finally consuming those contracts from the network and so I'm running short on time and battery so the elavil vm just a touch on this and I really am sorry to have to rush through this because it really deserves a talk of its own but the EVM is aetherium essentially aetherium operating system and LLVM is a very mature 20 year old project that has massive industry adoption massive tooling support great debugging code validator tool static analysis tools and again industrial adoption as well as a diversity of front ends that can be used and so what the EVM LLVM project is doing is bringing the EVM as a target to LLVM and you can see that here he's saying howdy and I wish I could talk to you more in fact better I wish Allen could be up here talking to you more about that maybe he will be next year but we're thrilled about this alpha is available and you can visit that website to learn more there's documentation there and we'd love for you to get involved with that project thank you nothing works without electricity all right so the natural complement to this front-end is then going to be the consuming end one of the fundamental pieces and core pieces that has had reverberating impact through our tooling team and through the application facing side of our projects has been open RPC and I want to make it clear straight up that this is way bigger than blockchain it has massive impacts across blockchain because this is the lingua franca for protocol providers not just a theorem classic and aetherium and the many different protocol providers that are implemented under that space but also for Bitcoin ripple you can read the list and for you yeah it it's bigger than blockchain and that's one of the things that's really exciting about it is that it is really generic and with this generic document pattern built now this has been applied we've applied this and are hoping to collaborate and build to get feedback and really push this in the space as a standard specification that can be the sort of the common denominator between protocol provider api's for application consumers using the standard interface that's available and so you can see here that not only are we getting Auto we get we get so here's the point I want to make about this is that is back to the point about readability is that is that not only is readability good for humans which it is and it's critical but it's also good for humans who are working with machines because if you can present data in a way that is structured and predictable and documented humans can write tools that can consume those documents as well and that's a massive lever and that's exactly what open RPC is doing is becoming that lever and and I would invite you to this website you can explore you can see how dynamic and informative these tools that come from this lever can be and do it all right and so I know that this is example probably like the closer to an advertisement than an actual guide and that's because it is we have so many projects that I don't have time to talk about but there's been and suffice to say there's been massive amounts of work that we've been doing to support the tooling and specification around open RPC and its application in the etherium space so I have two quick little case studies that I want to do that are compositions very very pure compositions that come from these tools the first is expedition which is becoming a very popular Explorer because it's very lightweight it allows you to run in query blockchains and explore your block chains whether they're annika land you're finding the end points upstream or whether they're a test net that you're running locally and finally we'll see if this guy will video cannot be loaded signatory that was going to be an awesome video that walks through what you'll find if you visit this website it's right there and it is an example of how we're able to reuse these tools to not only build tools but then build the documentation that supports them signatory by the way is an offline aetherium message and transactions liner that we've put together so we would encourage you to read and build more will be here our booth is upstairs any of us would love to talk talk to you about this and answer questions and I'm afraid I'll be pulled by the wrist off stage if I ask as for questions but thank you very much my name is Isaac [Music] you