EthCC 2: Mamy Ratsimbazafy

hi everyone thank you for staying so late it's been a long day for most of you so I will be presenting if I am 2.0 testing and simulation and the idea is that at the end of the talk you know what has been going on in the implementer teams you know a bit what is the life of a forum to implementers and giving you some figures and if you want to play with if I am 2.0 tonight for example so Who am I I'm mummy I'm part of the Nimbus team at status and I've been implementing a freedom 1.0 and 2.0 in the past year you have my contact details so on status which is a mobile messenger my name is Addison from Mustang and otherwise my github and my Twitter so if I am 2.

0 first of all let's see where we are I don't know if all of you watched Justin in depth talk this morning it so just a bit of a recap the goal of ephraim 2.0 is to improve Ephrem scalability and how it does that will be in free let's say main phases phase zero phase one phase two what we have on ethereum right now is similar to what we will implement on phase one and phase two but the big change will be phase zero the beacon chain and the beacon chain will have several responsibilities like sharing and also what is called a proof of stake that you can see there test nets are incoming but not like test nets with everyone but test nets for clients weave so that they can communicate within themselves so the beacon chain is in charge of coordination shouting blood processing lots of additional features that are very nice like finality and RNG so finality is just to make sure that once a block is finalized you can rely on it and it won't change like what we have in ephraim one where we wait for six blood validation to make sure that we won't have any change of the head block orangy has been referent issues on ephraim one like if you played with for more 3d contract the rng was kind of broken and exploited let's see about phase one and phase two Oh disclaimer frm to is changing very fast so I guess 40% of my slides that I did last week are already outdated so I'll put I'll give you the updated by voice so phase one will be about the data chain so what's happening is that currently on ephraim one we have some kind of world computer but it's single threaded you have one thread that is running the EVM and all transactions on a single thread we've shouting we will have 4096 fred's data charts and each one we have its own execution context similar to the EVM today so phase one currently the spec is written you will see it's on this get repo that also holds a zero spec but there is no implementation right now and the responsibility is holding all the data and so since the data is distributed it should be much faster like 4,000 times faster than a from one except that you we also have communication overhead phase 2 is about execution so to make without face to every the data and the communication that we have is completely useless currently it's still in discussion how to proceed from that like are we using awasum are we using the EVM are we building another from scratch and then we have further phases but they can be implemented in parallel with phase 2 so light clients which will can be done in parallel with phase 2 and phase 4 across chart transaction because assuming we have two Ephrem chain and I want to transfer money from one account on one chain to another while we were on ethereum one it's easy it's the same change same responsibilities but on a forum - you will have some cross shard transactions and overhead and apparently there is a phase 5 so this part is outdated sharding roadmap so maybe we won't have a phase 5 it's called a forum to end game and to be honest I don't know what vitalik has in mind but you have some links in there actually it's not the end game there is a phase 6 which is called super quadratic sharing with charts within charts with in shouts so it's kind of inception like let's go deeper okay so we know half the context this is an old jag Ram of the beacon chain and how it works what change sees since then is that oops I don't have okay what changed season is that the main chain and the B country are now fused and the blocks that you see at the top are finalized block and you can rely on them for any crossroad transaction and you have another layer the char chain and the VM that execute everything and there is a very nice visual simulation that you can have at observable hq.com at sea the tree or Jasper v04 so unfortunately I can't run the simulation but this will give you an example of how the beacon chain progress so here we have one two three four five six seven blocks and once the time pass you have cross chart transaction between several chain that are working in parallel and the gold blocks are finalized block that does serving as anchor for any kind of transaction so if you are still unsure and you want to visual demo of how the beacon chain works I you should go there oh so this is an easy visualization but then verse where's the actual plumbing so this was done about three weeks ago by a student called proto lambda it's on his Twitter on the slide you will have you can zoom out and this is just the beacon chain faint zero so why did I put something so eligible there is to show you how testing is important because in everything there anything can go wrong and impact consensus but just before going into testing let's go back to the past so this is from 2013 Vitalik dot CA aetherium dot HTML this was the spec of ephraim it fit in 1.5 a four-page sheet and so for example variant blocks were described with four sentences like network f random will run on its own network with a memory hard proof of work and people started to implement from that like caffeine would in June that was what we started with for the ephraim 2.0 implementers team like we had Casper FFG cycle operation say the previous export is justified and we have seven lines and then we had to implement something and make sure that everyone it were together with everyone we are currently nine implementers team so that's a big challenge and to give you an idea of the life of beacon chain and ephraim 2.

0 implementers between June and September the spec was done on a hack nd we had come it's usually by Vitalik that sometimes are very small and just [Music] changing words or type or fixing typos and sometimes we had big changes and we had to track that like every 10 minutes we had updates sometimes on Sunday and what you were implementing was completely slashed and removed and then starting September after some lobbying we had D terms that started we've come it's very lots of comments and people started to track everything every changes commits by commit starting last month we had releases so now spec is versioned so this means that something now we can have tests with a specific spec version that we target and make sure that everyone is talking the same language and so now we at the core of topic what could go wrong what do we need to test don't do that at home so we have multiple kinds of bugs this is one way to classify them we could have SPECT bugs like hoof by one and it happened maybe three four five times I don't remember but especially on each cases like Genesis we have inner abilities like those attacks for example when you do a forum 2.0 you run a validator note for proof of stake assume your client leaks your IP address and people just get your IP address does you if you don't reply in time the chain will slash your stake and that's something that we need to be aware of we have under specification and interoperability like we had if you followed if I am 2.0 we are using a new curve called BLS that is offering a signature aggregation and if we are not there are two ways to do pairing we have g1 g2 curve well that's crypto and assuming we implement one way of Y over we cannot talk to each other because we don't have the same public key for example or sterilization which is still being talked about for the network protocol in terms of issues we can have slowness like for example are currently Vitalik released a new shuffling algorithm but if you implement it the knife way the shuffling is slower than the actual number of seconds you are allowed to propose a new block or a test on the new block so you cannot implement the spec if you are just using the naive way and you can have issues with incentives and game theory but I think I'm pretty confident that Vitalik and the EF are doing well on that side now for the implementation teams you have over flows and the flows slowness as well you can also miss comprehend the spec and implement a wrong thing you have runner abilities you have implementation details and I will focus on that last part so implementation detail cryptography can go wrong.we Autopia networking signature which is related to cryptography sterilization can go wrong consensus like your proof of steak is wrong sinking if you request a new block and you get a malicious one or you get timeout how do you deal with bad peers and you have your state transition which is applying a new block and changing your state so a practical case this is shuffling if you search for shuffling on the Ephram spec repo you have plenty of issues on the bottom right non determinism like we can't reproduce your you're shuffling even if we start from with the same data with which is very important on ephraim you have issued with like clients that are exposed to I guess it's those attacks what do we have issues in understanding the shuffling function so spec miss comprehension on the bottom left we have out of bounds so we have off by one in the shuffling so and this is a very self-contained example so lots of things can go wrong so this is a recap of what we had given determinism issues attack vector concerns performance concerns and out of bounds bugs and every team we have nine are implementing their own clients so we have nine times the potential of bugs so one question is why so many teams are implementing clients at launch why for f1 we had the team from Gavin on I think it was in C++ and we had another team in go at first so one thing is that we've so many teams at least if there is a spec Berg everyone will uncon tore it it can be squashed much faster another thing is about decentralizing a varium don't rely on just parity or get and have a lot of clients that are suitable for various environments and make sure that we do not over rely on a single implementation so a link to all implementer teams we have two clients in Java one in typescript were two in rest one in NIM one in go one in Python and even one in Swift that started only two months ago everyone is toggling some kind of test net by the end of March and then once it works locally we will be I guess talking about doing a test net with multiple client so everything on Ephrem to is organized on ephraim 2.0 - spec for the specification and for testing its - tests for the test vectors and test generators for implementing creating tests so right now everything that is stable and self-contained has been tested so cryptography shuffling sterilization coming soon sorry coming soon our state tests and also proof of stake what we call choice now Ephraim one helped us a lot to not reduce the same mistakes as before one thing that was really helpful as a forum one implementer was having a test report that we could sub model so we can just we could just extract the testing it was in JSON for a frame 1 which is a very nice to work with in an automated way the only thing is that when we reviewed the tests and wanted to pass them we didn't know because there was no comment we don't know if it was supposed to test an overflow if it was to supposed to test something that should work or that should fail and if it failed why so for a forum - we will change - yamo for testing because llamó allows comments and also we could put some more structures on that and the very big thing that we learn from if one is that tests can generate an insane amount of lines of code to review when I say insane it's really insane so this one is a very milled test from f1 and it generated about 7.

5 thousands of line of code and pick a number like in your head between more than 10,000 let's say and in five seconds I will change and this is a crazy number of line of code that we if one and we don't want we didn't want to reproduce that in e2 so this is a test test generation in f1 that was one point to millions of line of code and well sometimes you also get unicorn because github says this page is taking way too long to load so right now if I go back to the structure what we review is just the test generators and everything on the test is auto-generated with circle CI and but we'll merge the new tests so much less review issues now I already went over what is coming soon regarding a cross client test net so once we finish just client specific test net we are pending the wire protocol so I hope that we fix that in the next two months is let's say wire protocol will be based only p2p so first we must make sure that we can talk to each other and we already have a proof of concept for a peer-to-peer testing that is available at this link and that you can already use today if you want to play with Ephrem - we have plenty of simulations so the client simulation will be coming soon this is what I call a full simulation we've already climbed but we have a lot of high level overview simulation what I showed on previously we are sharing simulation to make sure that we can manage the load on the network and we have consensus simulation to make sure that the first leg actually works so this one already described about 10 slides ago here is another one this one is shouting simulation by the Barcelona supercomputing group the UI is something that also works on if one called if net stats it's visible on github and this was a simulation to test how fast as the blocks are produced with shouting and a proof of stake consensus layer and it's available on Leo Bagshot sim and it's if you subscribe to the YouTube channel every odd first day for the Ephrem 2.0 implementers it's talked about at every meeting now unfortunately a lot of simulation are just console and I guess that's one of the next step that we all have to do on Ephrem 2.0 to appeal to people but you have all those links shouting netsim shots in which I talked about just before shutting p2p proof of concept Wittgenstein from consensus you have proto lambda LMG ghost so ghost is fraud Troy's proof or sake Vitalik has two simulation one called clock disparity which simulates latency on a network to make sure that we we can have consensus even with latency issues and white block which is testing and simulation startup specialize in blockchain they did simulation for FM Mineiro Bitcoin even EOS and they are starting to open source their framework and it can run with any client so assuming you want to start to work on Ephrem 2.0 very spongy but unfortunately I learned this morning that it has been taken there was a bounty to implement the spec in go so a frame 2.0 spec in less than 1000 line the code will be released soon I guess 1000 line is every shot and you can play with that code and learn have more about how if forum 2.

0 actually works and not just read the specs thank you [Applause] so do you have questions much [Applause]