EthCC 2: Philipp Langhans

a Hey so I think we can start hello everyone my name is Philip Lankans I work for the ethereal mist team and today I'm very excited to give an update on on mist and the new direction that we're heading but before we get to the exciting part I want to talk a little bit about the things that didn't work and that we don't want to do anymore maybe some of you went to DEFCON and remember the the didn't work song so this is the mist team's best off didn't work building a browser with electron in 2018 was a bad idea and the the electron framework is getting better and better but you should not build a browser with it and we stopped doing this building our own electron alternative and was a good idea but it took away too many of the resources that we that we needed for the actual application and Google entered the field and the electron framework got new developers from Microsoft they are really interested to keep vias code the vias code success going on so there's a lot of stuff happening and it made no sense for us anymore to build our own solution 2018 was a really bad year for NPM module security maybe some of you remember the event stream attacks on crypto wallets but removing most of the NPM modules from the privileged context of the application without breaking the whole thing just doesn't work convincing users to run a full node was also with good intentions but the the kind of audience that I wanted to start with missed was not prepared for this and convincing all of them had a really negative impact on the user experience and usability and there were other solutions like meta mask and brave that did a much better job in like onboarding these users and we introduced layered notes and quite late but we also realized that and the way we did it was not was not perfect and not very usable eventually we came to the realization that Myst was extremely helpful for many years but we came to the point where we thought okay we need to change something more like radically and drastically we need to completely rethink the product that we're building and miss cannot exist in its current form anymore and I'm happy to introduce a theorem grid if your grid is our take on like completely rethinking that the product and also the audience that we're building for first of all grid comes fro that the name comes from Tron some of you probably know that we all really like like Tron the movie of course not not the crypto Tron and in the Tron universe the grid is often referred to as the digital frontier the grid was made to provide an experimental platform where all forms of research could be carried out and part unparalleled speeds and this this really resonated with us and we thought it was a really good mission statement for what we wanted to build so we adopted the name and this is our version of the grid so this is an early preview of if your grid our platform to carry out experiments and research at unparalleled speeds it's a platform and where you can manage all the clients all these amazing tools that the community has built so on on the left you see get for example and then swarm clear Trinity Whisperer and there are more applications but it's really hard if you enter this space the landscape is quite complicated to get started and it's also there's always a risk involved if you download something to your computer and you manage your private keys with it and we want you to make this a smooth experience and wanted to give back they wanted to give back power to the users about what's happening on their computer so you can run now tests you can test different versions of clients against each other you can run them and upgrade them and configure them all from one application and then we envision more more ways to interact with the network and also with a client in more meaningful ways so we want that you can use this tool also to send messages send transactions signed data or signed transactions and then inject with tools like remix for example if this is interesting for you I want to invite you to follow the progress on grit theorem org and if the if you can't wait there's also our github repository there are pre-built binaries that you can play with already you can engage in the discussions you can find issues or contribute ok so this was probably the the biggest change for us but we also changed our focus a little bit to two different topics and one this developer experience so this is not only for us but this is also for external contributors we switched from meteor to react and this allowed faster development for us less configuration we could use create react app without loading hot reloading and everything worked out of the box easier maintenance better testing and we also did this step because we wanted to encourage people to to get more involved and contribute the client runs in the browser now there's no complicated setup you don't need to run a full node you don't need to configure a run electron if you want to make UI test change the user interface a little bit or just play with the components this can all happen in the browser now we completely redesigned the architecture for this the product is etherium react components it's on github already it's more than 40 components so we really took mr. part took everything that was valuable refactor didn't react and made it a component and it looks like this so you can find components for accounts wallet management network converter functions components for transactions and there's also a hosted storybook for you so you can see all the components that are there already pre rendered in the browser you can play with different States for these components you can see how they're used in source code you can see the rendered version of them and yeah just browse and and explore these components and use them for your projects so what's next for the component library we want to create even more or we want to cover even more States for their components for your eye testing and we want to cover all Network account and transaction States and make them available in the component library we want to use material your eye as a base design we think the the user interface is a little bit dated and we want to improve this and we are we are already moving towards material UI and then we want to use it mostly for many internal projects ok another big big item for us was update and release cycles and we had some good improvements here so we reduced most of our updates from roughly 50 megabytes to 2 megabytes and we have staged rollouts now with alpha better production and dev channels we are changing the whole update strategy from few large and security critical updates to mult potentially multiple updates per day and this is possible because we introduced different security zones so we are updating the web application and then critical binaries independently of each other and this was kind of a challenge for us our dependency model was really ugly so pretty much like this slide you had different components there that were responsible for installing and upgrading other components and then these are the the gray arrows the the big big grey arrows and then the black arrows our direct dependencies and then we had different security context so you can see the the red box there this is like external external node modules that were running in a secure tech security critical context and that this was not only a few and we try to remove them completely so grid now has only one main dependency to a framework that is that is built by us and this is the app manager and the app manager is a different or another project that we built just for the dependency management yet manager is a core piece of grid and it's a unified update mechanism it updates the user interface the main application the electron framework binaries and all the client binary all with one tool it supports what updating and loading and I would talk about it in a second and then if you ever download it for example the get binaries from the from the release page and scroll all the way down to the bottom you could find instructions how to verify the signatures of these binaries and we thought that this was a complicated step and we assumed that a lot of people would not do this so we build it in so the electron app manager now does all the signature signature verification for you this is this is the hot loading mechanism in action so it will go to get up search for our release and when it finds it it will download it and run it and then you have your application and this is in real time so it only takes a couple of second to install a new full version of the of the software the cool thing is we don't need a dedicated web server or update server for this arbitrary file protocols are sufficient and this allows us so the library is written in typescript and we have interfaces for the backends and we already have a github and Asia back-end and we're working on AWS support but also things like IP FS and swarm are possible with it everything where you can just download a package ideally with range requests like over HTTP and then you're always on the latest version and even more you get these like nice snapshots of these versions directly from our github repository and you can switch between these versions and we have staged rollouts we have release channels and then we have roll backs if something is crashing you just go back to a different version of the application and you can even pin a version if you don't want to have upgrades and there's even more you can completely catch these packages they are offline capable and you don't need a serviceworker they are more powerful than focus of web applications you don't need to write them to file system you can completely run it in the renderer in this case the application is served from a virtual file system the packages support partial resource loading so we can actually host the package somewhere it doesn't we does we don't really care where it's hosted but we can peek into it and see if a certain resources there for example an icon and even better we can load metadata and then do integrity checks on the package before we even download it or we can do full signature checks so we don't lock the metadata we make sure that it's a valid package before we even download something to your computer and this thing so we as we would sign all our packages and this is possible because of another project that we're working on which is completely security focused and it's called if um signed packages so it's best described as this we want package signing so which keys should we use for this and we thought what I mean we have already a bunch of private keys that we that we need to manage why create more can we use our theorem keys to sign packages and what effect would it have and in practice it looks like this so you have your web app your Deb you can have source code or a smart contract then you put it in a container file like zip a sitar whatever and then you use our CLI tool called each package and you sign your package and then you get this you get another package the size is unintentionally it's it's not getting bigger really it's just there's just some small metadata changes and this package is super cool because it's signed with a theorem first of all but then during verification you get a really nice property so first of all you get all the security security features that you want from a signed package you get authentication you get integrity non-repudiation but then if you do the verification you don't only get a public key back but now you get an ethereal mad respek and this allows for a complete new set of applications and there can be best best described as decentralized app marketplaces so usually if you sign your if you sign your code first the first step is to get the certificate you can pay up to fifteen hundred dollars a year to get this certificate in our case you can get get paid to sign your modules so we can completely incentivize developers to sign their modules now but you can also just get paid for your open-source work and this can happen automatically for example M for example built into the package manager or the runtime and so whenever there is a crypto payment for a paid app a small chunk of it can go to all the packages that signed to other package developer that signed their packages things like zero config donation buttons are possible you don't have to sign up on any donation platform we can just send the money to the address that that signed the application or package you can use existing hardware to sign so you can use reuse your USB hardware token or you can use the amazing tools that exist and you can even sign the packages in the browser and the best part is probably you can stay completely anonymous or you manage your your develop identity with all these cool emerging identity protocols and standards that are coming out now and we did one example through certificates through certificates powered by github so if you go to our to our grid repository you'll find a new new kind of file here it's called eve certs this it's a markdown file and you can use our eve package command line tool to create a certificate for you it's self signed certificate with your private keys you just paste you just paste the output into this file and which is essentially a list of all the authors that have access to the github repository and then because electron app manager uses eath package as a dependency it can download this list of authors and then make sure that no other packages other than signed by any of the authors others are executed in the runtime so what is the state for idioms and packages there's a magician's post there's an EIP draft there's a specification draft there's a reference implementation for the browser and for note there's a CLI tool called each package that I briefly showed and that's it pretty much this is like the the work we've been doing it's a lot of new projects a lot of changes and for your convenience I listed all the the important links here thank you [Applause] yeah maybe have some type of one or more question okay yeah okay so the target audience we're shifting the focus a little bit away from from mainstream users and more to to people that care about the ecosystem and about the tools and we want to provide them with the perfect environment to run tests and to develop applications so this is more focused on an experienced audience and we think they are great tools for other other audiences and they are already catered in a way and we don't need to do this so we we are shifting focus to this kind of group and we also want we also of course we want to help the other projects so it's it's a little bit of a dogfooding strategy where we have like not to onboard users but to help other clients to be a viable alternative we don't want everyone to use get for example it we are building different clients on purpose so that we have a decentralization on the conduct client layer and we don't want to centralize it there so it's a good idea to to allow users to be flexible in their configurations thank you [Applause]