 So it's it's really nice to be here without actually having to wake up at 4 am in the morning to do a hotfix release So I'm actually I I can follow my own thought pattern So today I actually want to talk to you about some constructive things after yesterday's negative things. So For this my talk will be a bit technical, but give basically given its very nature But I'm really hoping that you will see the simplicity despite the technicalities So first up a little perspective of of go ethereum and ethereum in general Basically as you probably know go ethereum c++ ethereum and Python ethereum were one of the three origin clients What this meant is that the clients kind of were already existing before the protocols evolved this meant that the client So the protocols that the peer-to-peer protocols the consensus protocols were all all specified based on the Experiences learned from the clients and what this meant is that the clients were kind of evolved like a startup Just hack together code hack together some other code delete some code. So the code quality was really really bad Now on top of this when me when ethereum was born then There weren't any other tools. So now we have quite a lot of tools in the ecosystem But with the birth of these three clients the clients were required to do absolutely everything that That's a developer would need and even further since we wanted to make ethereum to be useful as much as possible for everyday developers The idea was that we are going to provide the JavaScript environment because more or less everybody is familiar with JavaScript and because of this The problem became apparent that if you wanted to use go ethereum or the geth code base or any other code base as a Library from your own project not from a JavaScript app. It was extremely extremely hard and the reason was that The fast prototyping accumulated an extreme amount of technical depth the networking since Geth was kind of the network had the network majority in the protocol I mean had the network majority It was really hard to drop features and every time you try to drop something somebody was using it in hidden The end was really really angry at us and furthermore browsers since we kind of targeted browser based apps first it was The emphasis was always placed on JavaScript and it was really hard to somehow use it outside of this pre Predefined JavaScript environment. So this was kind of our world until now and if we fast forward to the present one of the our main features as So Joel already mentioned that we have light clients warm and other stuff But one of our main features for the geth 1.5 release is kind of a brand new Brand new code API so that actually any developer can use either go ethereum s full or pieces any Little tiny piece that they want in their own projects without actually having to use a command line interface And why are these good? Well, for example, we try to take a look from from different pain points Person from the perspective of different pain points One of them was that people don't really want to share they their private keys with the node Especially if you are running multiple depths against the same node Why do you want to place the key in the node? Keep the key yourself? It's much safer that way or the other thing that the RPC spec or joe is Jason RPC It has these fancy hex encoding for quantities and other stuff that are really non trivial So to get them right, it's not such an easy thing and although every developer will probably be able to do it It's just a pain to do it yourselves now If you actually want to interact with any theorem contract Ethereum has its own a bi the way to encode and decode function calls and parameters and that is very very complicated So yes, it can be done but it takes a ton of time and possibly you don't really want to waste that time you want to spend time developing your depth not Implementing some protocol and last but not least there are certain cases where it's really natural that you don't want an external node You want to be able to run your own node For example, if you have a mobile app then it's kind of sounds weird that okay to use my app Please download this app this app and this app so user will just say no, that's not go there and these were the pain points that we really tried to address in get 1.5 and So let's dig Dive deep into the technicalities So first of all can client-side account management be done in a simple way and our answer was that yes, of course it can be done and the following code that you kind of see on the screen are four method calls and full Account lifecycle management you can do fully client-side in your own code without actually having to run get parity or any other Client you can basically create a new account you can export that account into a JSON you can take it wherever you want you can import it back up and Yes, you can of course delete it and all of this is done client-side without any backing theorem node and that's actually the whole Program that's I just running there. So everything is full program Nothing else is outside of it and this is basically how we cleaned up the account management so you can take the account manager you can take your accounts ethereum and take it everywhere you want and You don't have to leave it inside geth or any other node. You can just do it yourself Okay, now what happens you can manage your own accounts, but another thing that you really want to do is Okay, without with only with accounts you can do much. You need a node to actually Interact with so the other the second part that we spent quite a lot of time is to cleaning up the remote API's and For this we also provided Really nice library. It's called the ETH client that can actually dial into any any ethereum Client either via IPC socket HTTP web socket Basically, it's a full-fledged ethereum client and Furthermore, it's not just a simple RPC client that you need to manually specify all the JSON RPC details rather It's actually all the all the officially spec the methods are available So you can for example query the current block So this basically this nil here is just saying that I want the current block and not the not any random block I Can I can for example also query the state? So previously that was querying the blockchain. I can query the state tries This is just querying how much funds the currently the ethereum tip jar has the foundation tip jar and One more thing that's I'm not sure whether it's what is in producing 1.4 or 1.5 But we actually do have Subscriptions so one of the problems with mist during the DAO crowdfunding phase But it was hammering the underlying node with tens of thousands of requests per second RPC requests And the node was basically dying because it couldn't serve those requests and the single problem was that the nodes didn't subscribe didn't Support push notifications and that's also something that we kind of fixed So now you can just you have a your ethereum clients can simply call subscribe to new head events And whenever a new block is mined it will be immediately Sent to you and you don't have to do polling at all anymore And of course if we run that again, that's all the code It will tell me that my chain height is at currently at 22 million or 2 million something It told me that the tip jar has about 3800 ethers and as you can see My laptop is actually connected to the main that now and as the blocks are being mined on the main That it is immediately pushing it to me and again the code is just the three function calls that you see on the screen full source code you can see it on the screen So basically you can do chain exploration and state querying and everything via a few API calls a Few programmatic calls. You don't have to implement anything yourself So okay now if you can have key management and you can interact with the remote node You almost have everything but if you actually want to interact with the contract Then you have a problem and the problem is that Your your code needs to actually implement ethereum ABI the ABI as I said is not trivial The basics are kind of easy, but there are quite a lot of corner cases For example, if you try to serialize or deserialize an array of structures in web 3js You will find many corner cases that aren't completely Properly handled and these many times people usually just say on the internet. Well, just use in well Yeah, but if solidity supports all these other types why not use them and Implementing them is kind of a nitty gritty detail. They are quite a lot of details So it would be really nice if we could have a library that does this automatically for us Then of course if I want to interact with a contract It would be nice if the library could also cover all the remote client API stuff So I don't have to care about RPC at all and that's what not least if you are so if I have an already existing contract And I just want to interface with it. Okay, then cool I can just create some codes to access a few methods and I'm done But what happens if I'm actually developing that contract if I if I'm developing it that often I'm just changing some solidity lines and the lines I change I want them to immediately reflect in my code And this is a really nasty part that I changed solidity Then I need to have to change my own code and then I need to make sure that none of my tests broke and it's it's really really an Long procedure and it's when you want to update solidity 10 times per minute. It doesn't really work out So our solution to this problem was who created a begin basically It's a native binding generator and what it does is that you can simply specify a solidity contract And it will generate you full go source code and you can just plug that to go source code into any project And you will have a minute the access to all the contract calls all the transactions all everything natively and you don't have to care about any of the encoding or any of the The RPC calls and the really nice part about that is that if you rewrite your solidity contract then immediately it gets recompiled I mean the go code gets regenerated and if there's it's type checked It's compile time type check you go. That's you don't don't get surprises During actual deployment of whoops something didn't work out So how does for example this look well if The but the top part you can see a solidity contract basically it's a snippet from our release contract the geth release Oracle what it is that's For every release we kind of bump a version number on the blockchain and then every time a geth note starts up it just checks the this version on the blockchain and if a newer version appeared and it just prints out a warning to the user that hello, please update and Well, it does a bit of maintenance in the background But essentially this single function is what is fetching the current version and if you run through this run this code through Abigail then it will give out about 400 lines of go code that we didn't have to write ourself of course for the other functions to in totaling up to 400 lines and But it does get give us a really nice API. It says they're basically I have a new Release Oracle method that I can just point it to a contract. I can tell it how it can reach an ethereum Client that might be over HTTP web socket or IPC or actually an in-process client And then I can just call that I want to get the current version and it will just if I run this Then you will see one of the nasty parts of One of our lazy sides is that we actually never updated the version for the yesterday's hotfix release So oops, sorry about that. So the blockchain didn't wasn't updated to the latest release, but basically I Could simply call a same single command line function single command line utility and then I can immediately work with my contract I don't have to write any boilerplate code myself and Then last but not least one of the interesting things that you can also do is Often Many so usually in this ecosystem. There has been a relatively little Request to run in process nodes, but there are quite a lot of cases where it's genuine You may genuinely do need to run in in process node For example, if I'm developing application, which isn't ethereum centered rather ethereum is just a utility in it Then I would like to distribute my application to clients or to any other people without asking them to first sync up an 80 gigabyte blockchain Or just selling telling them to please download another app whether that's one client or the other. It doesn't matter I just want to distribute my app. Here is a single binary. You can run it and it just works and and for that we cleaned up our API so that API wise in the go client. You can just create an empty peer-to-peer node It's just a deaf peer-to-peer implementation You can attach any protocol whether that's an official protocol to it or whether your own custom protocols We are free to implement your own protocols up top of the peer-to-peer and then I it's just a way to register that I wanted want to run the ETH service on top of that protocol. I just start up the stack and I can attach you so again just for function calls for setting up an entire ethereum node And if I run that now it is actually compiling building the full ethereum suit which takes about I know 10 seconds maybe a bit More with my power plug on my power cable unplug. So yes, that's another thing about go another nice thing that was the full compilation of go ethereum and Yep, I just started up it started it up in a new new empty data directory and Just create some basic information about it and as you can see This again as I emphasized with the previous releases with the previous slides again This is the full source code So there's no other boilerplate that you actually need to write yourself You can have a full in-process embedded node in three lines of code or four lines of code of course I left out the arrow checking so Do keep that in mind Okay, so if we have this all these awesome libraries available Let's try to put a twist on them What would it take maybe to allow supporting them on mobile platforms Well to tell you the truth mobile building to Mobile platform was kind of already supported in 1.3 about last year in September. I did the first Cross compilation to Android it looked horrible. It performed horrible, but it actually worked So I was really surprised it did we did have to fix up a few things in our code base But we could actually start up an Android debugger just copy a binary a CLI binary to the end to an Android device And just run it and it was running it was really an amazing feeling of course it was completely useless because you don't really run your Android programs by copying over a CLI binary and Requiring actually a terminal to run it So during the winter break Christmas time We started to play around with actually providing a library so that users can more easily interface Go with theorem in mobile apps and Well if we did provide Android archives and we did provide iOS frameworks But if we did provide all of these things Why aren't they any if they are mobile apps or any popular ones? Well, the kind of the answer is that that was our full API in the bottom line So that was everything that we supported. So basically we created the wrapper around the CLI interface Which is a horrible horrible idea But since we didn't have light client and it wasn't even on the horizon It didn't really make sense to put more effort into a mobile wrapper since nobody's going to use it anyway So it was rather a proof of concept that people can start playing around with it Wasn't ever meant to be something to be released. However, of course with the 1.5 arriving We want to change all this. So let's see how complicated will it be to actually run Geth as a library or parts of geth inside mobile devices And while it turns out that we have exactly the same API that we had available in go We have that available in Android We have the account manager life cycle management. It's exactly the same function calls If if somebody's a Java guru, you will immediately say that ooh that geth dot new is ugly You should have only used new. Yes, we know that is a limitation bit of the go Java bridge That will be fixed, but please bear with us until it is fixed So basically this was the Apart from a small Android boilerplate this was the full code to actually do account management inside an Android application and that's basically the screenshot from The application running in the simulator. So we have the same functions. We can add new accounts. We can export import We can delete them. So everything you would like to do with an account. You can do it Now, okay, you might say that account. Okay account management is pretty easy You can do it with any fairly nice Java library. Why what's the big deal? Well, let's go to remote API's Well, it turns out that with remote API's we can do exactly the same thing like with go ethereum We can create a new ethereum client which can attach to almost everything HTTP web socket IPC interface the same way as As the native go client could attach to it and it supports all the same functions plus it also supports subscriptions Now getting all of this working is a bit more involved since you also have to implement the RPC interface And you also have to implement subscriptions which aren't exactly that trivial to do already So push notifications client side handling them. It gets a tad messy, but we all you basically you get that for free Okay, so we got Contract, I mean we got the account management and remote API's. Let's see. Can we interact with the contract and The answer is sure So actually we extended a begin to be able to generate Java bindings to contracts So the same way you had a solidly contract and you could create a go wrapper You have a solidly contract and you can create a Java wrapper around it So basically it just spits out the Java file. You just included the Android project and bam you can create a Contract object and you can immediately call functions on them No, basically, that's all that it takes to query the guest version number from from a mobile platform and Of course last but not least if you are running an Android app Then this is particularly the case where you don't want to depend on an external app you want to run an in-process node and Yes, of course, we do can run an in-process node where we can just similarly create a new node if The API here is a bit simplified because it wasn't really a point to expose the entire go API to creating nodes. It's It kind of it was more Ethereum specific. This might change a bit in the future But in essence we can create a node really simply you can just specify a data directory and voila It's running which can just start it up and that's all we can start it stop it Interface with it attention Ethereum client with get all the data We want interact with contracts everything we can do with two lines of code essentially so That was the mobile platforms. Okay, you might ask what about iOS? Yeah, sure. It works So the same thing you I don't expect you to read the code. I just pasted it if you look at the slides offline But everything works really nicely so just to Cover the sum the whole thing up Basically go Ethereum or go actually supports deploying on a variety of different platforms Linux Windows OS X Free BSD on the All the platform or the architectures that actually matter and go Ethereum will provide Pre-bundled libraries for Android and iOS for basically all the architectures that actually matter as for Windows phone Oh, sorry, maybe in the distant future There's not really an interest to port it and If you are actually somebody is interested in trying out either the Android or the iOS libraries You are free to download them. Thank you very much