EthCC 2: Mehdi Zerouali

here me yep that's much better cool so we had a little bit of an incident just a fire drill we're two hours behind schedule so I'm gonna start again because there's a bunch of different faces in the room my name is mehdi i'm a co-founder and director of sigma prime and i'm here to talk to you guys about lighthouse our security focused cerium 2.0 implementation this talk won't be a very technical talk basically my main objective is to provide you guys with insights into the Serenity development lifecycle from an implementers team perspective and I would also like to be as transparent as possible and share a bunch of challenges that we're facing also give you guys an update on our funding status and also you know share with you some of our latest achievements and the progress we've made over the last few weeks so for those of you who don't know Sigma Prime we are an information security consultancy mostly based out of Sydney Australia we work closely we you know blockchain projects mostly in the theorem space and we're basically a collective of developers academics researchers and security engineers put up a bunch a couple of our few of our clients logos we've performed security assessments for projects like status chain-link crypto keys friends tapa and a bunch of others so security assessments are pretty much the core of our service offering at SEMA prime but I'm not here to talk about that I'm here to talk about lighthouse since we're the maintainer of this project which is a rust implementation of e theorem 2.0 just to give you a bit of background on this project we at Sigma prime are very very passionate about Provo stake designs so very much into the game theoretical principles of algorithms like Casper we're also very very excited about the environmental impact of proof of stake blockchains for our ecosystem as a whole and we also were very very interested in the mathematical finality that some algorithms like Casper can bring just a bit of history on lighthouse my friend and co-founder Paul started the started working on the JavaScript implementation of Vlad's gas bomb so Casper TFG so you basically built the JavaScript simulator and he quickly realized that this consensus algorithm wasn't gonna be the one being introduced in serenity or at least in the first iteration of serenity and he wanted to have the most impact so he shifted his efforts to it Vitalik scuzzball so Casper FFG and I'm not sure if you guys remember but last year there was a an effort or an initiative called IP 1011 which was basically introducing the concept of a hybrid proof of work and proof of stake chain this got deprecated quite quickly I'd say in a sense that we basically realized that having a consensus voting smart contract was not you know was quite challenging with the current IBM bounds and things like transaction ordering and gas metering were not necessarily adequate with the current EVM design so this got deprecated and the e2 spec was born and the e3 spec was born as a result of the merge of two research initiatives the first one is the sharding research initiative in the second one is the proof of stake research initiative and and yes research has realized that there was a lot of overlap between the two and basically this gave birth to the East respect that you were and that's how we all started I want to thank Danny Danny Ryan for making us feel welcome making us feel safe to basically start contribute to this to this project so why are we doing this we love aetherium at Sigma prime where we've been involved with the theorem since the very very early days we love the community we've learned a lot from the community and we also truly believe in a theorem is potential for changing the world for the better as I said earlier were also passionate about proof of stake chains and and yeah working working with the research team of the human foundation is very challenging and intellectually stimulating and that's something we value a lot so this you know keeps enhancing and expanding our knowledge and yeah we keep learning on a daily basis and you know someone's got to do it so when we started this project there weren't that many implementations of theorem 2.0 I believe if I recall correctly he that lighthouse was actually the second one to be officially announced nowadays there's you know new projects popping up almost every week which is good but back then when we started there was no there was not that many of them so this is our way to sort of contribute and give back to the community so I expect everyone to be familiar with the theorem roadmap but just to make sure that we're all on the same page and I'd like to take a couple of minutes to basically touch base on a couple of concepts I don't know if you guys attended just in stock yesterday about the phase zero spec an amazing talk if you haven't highly recommend watching the video but I'm gonna have time obviously to go into that much detail but I think it's quite important to keep in mind the design goals why why are we doing this thing the way we're doing it try to group them in four categories the first one obviously is decentralization right this is you know common to any sort of block chain but it's a very important goal in the sense that the researchers have designed this system in a sense in a way that we'd be able to run it or be able to be part of network with a standard consumer laptop there'll be massive change from the proof-of-work world and that's quite important also in decentralization sort of realm the fact that we can have a large number of validators it's very important as of today we have the ability for the beacon chain to support up to roughly 4 million validators which is pretty cool the other design goal is liveness so you may have heard some of the theorem foundation researchers talk about you know Black Swan events such as a third world war which would you know introduce massive Network petitions so how do we ensure that the the beacon chain or the the theorem serenity chain is basically resilient and live and stays alive in in such scenario is one of the one of the key design goals again the third one always makes me smile simplicity I wouldn't say that the beacon chain is simple not not really but it's good to keep in mind that it was designed in such a way to maximize you know the simplicity and even even if it's at the cost of some potential efficiencies and last but not least the security aspect is of course very important to any blockchain platform and it's quite at least interesting me the fact that we are using quantum secure cryptographic primitives where possible and we're not well it should be relatively easy to swap them in the future so I'd like to think as the theorem serenity chain as a future-proof chain atomic says again I'm hoping or I'm guessing this is familiar to most of you but just taking a couple of minutes to walk you through it so phase zero phase zero is basically where we're currently at or what we're currently focusing on as implementers and phase zero is basically the beacon chain right and the beacon chain is a snake chain it introduces Kaspar FFG and it's basically responsible for storing and managing a set of validators and assigning them to certain duties it already it's already gonna provide mathematical finality to the each one shine even though some potential enhancements and tweaks that may require hard folk will be will be needed hard for on the eighth one chain that is and just to make sure that we're on the same page the the way it's gonna work we're gonna have a smart contract on the eighth one chain on the current chain and then if you want to become a validator you send a deposit 32 if the deposit to this spot contract and after reaching a certain threshold the peaking chain becomes you know activated and comes to life so that's phase zero phase one is when we start having shots hard chains as of today we're gonna have 1,024 cards and basically we won't have state execution on those shots yet we'll basically just get the validators to come to consensus on charge change data phase two is is what gets us to an actual usable workup of blockchain and state two you know brings in state execution at the shard shine level and and as I said yeah that's that's when we actually get to play within a blockchain similar to the block chains that we know today hopefully that makes sense in terms of development lifecycle this is what it looks like in an ideal sort of scenario in reality it's much much messier than that but I guess for phase zero this is where we're at today right so taking the spec testing it developing some of it finding bugs you know looping those bugs those findings back to the etherion research team who then proceeded to update the the the specification and then more implementation the more testing and so on it's a very iterative process and we're currently you know I'd like to think that we're at the end of this phase and we're currently working on a single client test net so you know hopefully within the next few weeks we'll have a test net for you guys to to play with it's a single client test net meaning that it's a lighthouse just net the next step is to get a multi-client test net where we get you know various different implementations and get them to connect to a common test network after that or probably around the same time we'll get a bunch of independent security reviews to make sure that we you know haven't missed any sort of security bugs and then then we'll get a minute please don't quote me on this this is not a commitment to any timeline it's just my wild guess it's a software project software projects by diffusion get delayed especially when you're dealing with cutting edge technology so I'm guessing will potentially see a magnet by the end of the year or early next year well at least that's what we're working towards so hopefully that makes sense a bit of background on what what serenity is and I'm gonna spend some time talking about our client and how it's actually architected so have a little animation for you guys so today when you connect together and parody you you know some of you use the CLI command line interface so we'll have the same thing lighthouse we'll also have a command line interface we have you know key stores in get and parody will have the same thing in my house but ideally to achieve you know mainstream adoption and user user adoption we want all this to be completely abstracted for the end-user right so I deal in an ideal world users will just you know hit apps use that speed you know mobile apps web apps or even desktop apps and then this this layer will then connect to the various api's exposed by lighthouse and also potentially you know hit hit the wallet in terms of peer-to-peer networking you know it's a blockchain so it's obviously obviously a peer-to-peer network so the criticals of phase in the in the bootstrapping process is the peer discovery making sure that we are able to identify peers that we can connect to and exchange information with and the wire protocol basically dictates how we communicate with these nodes and you know once you do network discovery you put this information in the database for further and faster processing then we've got the specification and the specification basically dictates how the blockchain logic actually works and what the consensus agent is should should be doing so in lighthouse we basically split these two components in two separate binaries this is the beacon node and this is the validator client just a couple of words on the networking layer we'll be using we're using leap p2p as the base of p2p networking stack it's being developed and maintained by our friends at protocol labs so these guys are the folks behind projects like ipfs and five coin and the message routing will be using these gossip sub and gossip stop and shows efficient network communication especially in the context of 1,024 shards it's quite quite important so the big node mentioned is you know the core part of the lighthouse client which basically handles the fork choice rules the fork choice rule is basically the algorithm that ensures that all the different implementations and different nodes come to consensus on a canonical chain this is also where you have your state transitions or block processing functions and this all comes from the spec again this is just an implementation of the specification which comes you know she's shipped with a bunch of test factories that allows us to basically make sure that our implementation is on par with the specification the valide our client as I said is a separate binary and it connects to the beacon node connects to the beacon node via AG RPC connection and it basically pulls the beacon node for certain information so it fetches valley their duties and it's responsible for probing and asking the pic know to basically propose blocks when when necessary this way you have you sign at the station that have you proposed blocks so hopefully that makes sense I started this talk by saying that lighthouse is a security focused serenity implementation and I want to you know tell you guys why or what it actually means so first of all we're using rust I'm not sure how many rust developers are in the house probably not that many oh yeah a little bit a few so rust is is quite awesome we love rust Sigma prime it's I guess at least my perspective it's the result of Cades of computer science research it was developed in 2010 by the Mozilla Foundation and it's I don't have much time to go into much details but it's it's safe I mean it's fast sorry and it's got very interesting security properties so the way concurrency is handled is very very elegant and the memory management is quite innovative other security sort of principles we try to follow one of them is you know sticking with the rust philosophy which is never never panic crash is a panic in the rust world so we don't want to panic and we want to be able to you know safely handle and catch all errors and exceptions we're also following strict coding guidelines so there's this cool French Institute called ANSI which is responsible for looking after information security for a bunch of French institutions they're putting together a rust the strict coding guideline for rust and we're trying to try to stick with that we're obviously using linters things like code for matters and we'd like to do more code reviews but for that we need your help we need more contributors so that we move away from implementing those functions ourselves and basically start reviewing the communities sort of contributions to this to this project and we do a bunch of fuzzing and I particularly particularly interested in fuzzing so fuzzing is the process of essentially sending a bunch of randomized and unexpected input to software with the intention of causing crashes causing crashes and an intended behavior abnormal behavior basically and that's something we try to do quite a lot you know currently focusing on the the crates or the library there's rust libraries that are consuming user supplied input or networking information and that's it's it's it's quite fascinating so we're using two different buzzers at this stage we haven't really decided which one will go with in the in the long run so leap for an AFL they're both you know coverage guided white box in process poses are quite like AFL so AFL is the American fuzzlip and it's when I was researching the fuzzing world a few years back I was quite impressed that its capabilities so there's this security researcher a couple of years ago who pointed AFL at an image viewer a Linux image view I can't remember which one and basically AFL because it starts to identify all possible code paths AFL basically managed to create JPEG images out of thin air which is quite cool yeah other security considerations for the future we expect bugs lots of bugs to arise from the test net phases particularly around denial of service attacks I there's you know as I said we're using leap p2p and there's a potential Sybil attacks in the p2p that are quite quite interesting to look at and it's also because we're taking the spec and optimizing it there's potentially gonna be consensus divergence and consensus related bugs so you know that that's normal that's why we're you're gonna have a multi-client test net and these things are basically good to support in a test network before the actual main release I think I mentioned this earlier we want to get an independent security review up so we you know reconnected with a bunch of outside peers in the space who we we trust and respect and we're very much looking forward to them taking a look at our code formal verification is a very hot topic in the space a lot of debates going on on formal verification so there's actually two teams one in Singapore and one Incheon guy working on formal semantics for us in K so hopefully these guys will complete their work within the next few months and when they do that means that we can formally verify at least a subset of Lighthouse quite cool and I would also personally like to see a differential photo so the difference between a standard buzzer and a differential Fossum and actually the e theorem foundation has a differential father and what they do is basically they send random inputs to both again and parity and collect the EVM artifacts or the EVM traces and make sure that they produce the exact same traces this allows you basically to make sure that different implementations behave the same way and that's how you catch consensus related bugs so hopefully you know after a multi-client test that is up hopefully we should all work together to create this similar project for easy 3.0 some of our achievements and progress update over the last few weeks so I mentioned gossip table as the message routing algorithm for the PDB well turns out there was no rust implementation when we started right there's only a go implementation and Adrienne Manning one of our co-founders and directors just submitted a few a couple of weeks ago I believe beast of a PR to actually implement gossip sub in rust so that's quite cool quite exciting very much looking forward to our friends from protocol labs to merge these two master hopefully soon we've also finalized the bunch of libraries critical libraries for our project so the SS Zed library as I said is the serialization format being used in a theorem serenity it is shuffling the BLS all these libraries are now finalized which is which is great we have you know proper block processing and the three state transition functions have been implemented which is quite quite exciting I believe where you still have to upgrade it to the latest version of the spec but it actually may have been done yesterday or this morning the fork choice rule has been implemented which is quite exciting so we're using LMG ghosts for phaser at least and that's all that's all implemented and yeah we actually now have a beacon chain which can build blocks and produced blocks with a few thousand validators which is which is cool so lots of progress was made by the the Sigma prime team on lighthouse for the last few weeks another sort of aspect from a team perspective we hired a new rust developer who actually started with us two days ago so Michael welcome to Sigma prime welcome to lighthouse and you know we keep contributing to the spec by finding bugs finding more bugs and making sure that the ether and foundation is aware of them and some of them may actually result in spec change in spec updates so yeah I said I was gonna be at least try to be as transparent as possible in terms of funding I think that's very important I see like how like how sorry has a public good and and yeah so just just giving you some context some numbers on the funding status of lighthouse this project was bootstrapped and kick-started by Sigma prime we dedicated a lot of time a lot of resources and effort into making sure that this actually you know get started so we asked him a roughly a hundred and hundred and ten thousand US dollars the amount of money Sigma Prime has contributed so far we also received a grant from the etherium foundation back in october october november jabra believe with 150 thousand US dollars and then you may have seen on twitter the Yolo grant so Vitalik you know sent one thousand ether to three teams back in december late december last year and we're one of them so Vitalik thank you so much and we also keep using get coins to fund some of these you know github issues and it's it's been a real pleasure working with these guys so it's a huge project funding is definitely a challenge but it's uh yeah it's it's it's it's challenging but we're not we're not the only ones it's not you know specific to the etherium space with the blockchain space it's an open-source project and there's any open source project it's their funding is a challenge is an issue one thing I'd like to say this is probably an unpopular opinion but I don't think teams like ours should be holding their grants in volatile crypto assets right that's that's my take that's just my opinion but we have salaries to pay we have developers that you know we pay them in fiat money in Australian dollars or US Dollars and basically we we don't hold on to these grants in in their in crypto assets we basically went that thousand ether was given to us by vitalik we made sure to exit it and convert it to fiat within the next 24 hours so at least 90% of it 900 ether was actually sold within 24 hours why because I believe we should be speculating on public money you guys are contributing to this and you know we're as I said paying salaries and it would be my opinion irresponsible to speculate on the either price as I said this is not a you know this is not a problem that's specific to a theory a more specific to lighthouse or even blockchain space I actually believe that we're quite lucky to have the EF support projects like ours don't have that much time to go into details unfortunately but there's a bunch of different ways you can fund open source projects and I guess it's up to us to find the right sustainable business model for lighthouse I want to commit today to you guys to the community lighthouse is and will remain an open source and free aetherium client no i ciose no tokens no licensing fees that's that's very important to us in terms of funding actual funding this is the current team size so we've got three full-time lead developers working on lighthouse at the moment we've got one lead developer core developer working part time and two junior developers working part time so the actual yearly cost for these resources in terms of salaries and just talking about salaries here is about six hundred thousand US dollars which means with the the amount of money that we received from italic from the term foundation with the amount of money that semiprime put in were actually funded until July July this year again to be very transparent I'd like to talk about some of the challenges we're facing as I said early on we are information security firm right and Sigma Prime's offensive security offering is actually in pretty high demand so I personally find it quite difficult to find the right balance between you know lighthouse and security assessments right you know Sigma prime is a proprietary limited company you know we should be making money but at the same time we really want to help the open source space and the ether of space by working on my house so I personally find that quite challenging finding the right balance between the two the spec that's the second point is uh I think a passed challenge we you know we had respect being updated every second day we had to throw away a bunch of rust code but things are much better now much much better now we have release candidates with actual change logs so that was that was there was a pain but it's almost let's say resolved now and last but not least if you were to take the spec and implement it naively you wouldn't get a work in client you would get a slow client that wouldn't be production ready so on top of implementing the spec there is an engineering effort that's required to optimize the spec cool last slide so to take away so I guess for this project should have we waited for a release candidate before starting the work started development I don't know maybe perhaps we should have but at the same time that iterative process I was talking about allowed us to support a bunch of bugs in the spec so these are open questions I'm I don't I don't have the answer second questions I'm asking is in the easy to space the research team is actually the project management team so if you come from any commercial background this is unheard of right you would have you know people putting the spec together completely separate and independent from the actual project management but again is can we do it differently I'm not sorry in a decentralized context I again I don't have the answer this question and hopefully some of you will come to Sydney for ad con it's happening very soon in a few weeks six weeks I believe so we're very very excited to have the etherium community down on the if you guys have any questions about Sydney or Australia generally please feel free to reach out but I'm hoping most of you can make it to to see me Fred Khan and yes Paul and Adrienne will be providing you guys with another lighthouse update and yeah I finally help us get there you know as I said lighthouse is a public good so if you're a rust developer and you've got some free time please help us jump on our github there's a bunch of good first issues and if you have any questions please jump on kira ask us ask us as many questions as you want we really want to help you help us if you're an onerous developer and if you're gonna be relying on projects like ours in the future if you are adopt that raised you know tens and tens of millions of dollars in 2017 and 2018 if you are a crypto VC fund who is betting on the success of this space well perhaps now is a good time to start thinking about contributing financially to projects like house thank you [Applause]