ZKPodcast:ETH2.0 Update With Danny Ryan

Transcript

[Music] welcome to zero knowledge a podcast where we explore the latest in blockchain technology and the decentralized web the show is hosted by me Anna and me Fredrik [Music] in this episode we'll sit down with Danny Ryan from the etherium foundation to talk about aetherium 2.0 we talk about what it is as well as what's happening with this spec today we have Danny Ryan on the show super excited to

have you I really want to dig into these two and do a little bit of an update on what's going on we've had prismatic labs on before to talk about it a little bit and excited see what's been going on since we had them on and maybe talk a little bit about more general topics as well so we have Anna with us as usual hello and Danny welcome to the show great thanks for having me I'm excited to dig into this stuff I put a lot of work in past six months tightening all the specs so it's a good time to chat about it Fredrik you know Danny but I don't really know Danny so maybe we should start off with a quick intro do you want to tell us a little bit about yourself

and how you got into this space yes my name is Danny Ryan I'm from Baton Rouge Louisiana I've actually until like a week ago resided in New Orleans I'm out in Boulder now I've been following Bitcoin for a long time maybe made some bad trades early on and kept my eye on aetherium a lot of super fascinating the obsession took me you know over time I realized it was the only thing that I could really think about and the only thing I wanted to work on I was an independent developer at the time and started getting rid of all my clients and started just following research and contributing online and probably

beginning of 2018 I officially started working with the foundation the ether and Foundation and have been working on purpose take specs and research and that rolled in to working on the East to stuff when proof of stake and charting all kind of came together something I'm really curious about is how you came to be in the position that you are now because like I I know a lot of people like John Choi you we had on the podcast before kind of started as researcher and then moved into various other roles like what was your path within the foundation cuz you're I mean you're effectively like a project manager over eath too but as a communicator as this sort of layer that that glues a bunch of things together

and in an organization like the EF with that doesn't really have manager it's like how does that come to be right so I I began to contribute just by like editing stuff online like contributing to some proof of concept code bases and John Troy actually hired me to the finally he's like you're doing all this work like work with us so okay great and saw that there was a lot of work to do with the Casper stuff when it was still Casper contract and started just kind of taking that over naturally as I added some testing frameworks and was enhancing the code base when that work got deprecated I did the deep dive on sharding research and really all

throughout this as I began to work with EF it became apparent to me that research had at least a little bit of a communication problem in that people would ask us questions and I would respond and then I kept getting responses like well I'm just gonna start asking you because you're responded so for a better or worse I think we've greatly upped our communication especially with respect to all the e2 stuff in the past six 12 months but it you know we have some like heavy hitting like deep research going on in the EF and then we have also people that are like deep in the engineering and I have

fascination on both so I've I'm often communicating with teams on both sides and it just emerged that somebody needed to really take on the communication and so it was very organic no one said hey Danny do this it just kind of it happened very excited it's a lot of fun I get to talk get to like talk with incredible smart people from all over the space and all different sites at all the different teams and sides of the project so yeah it's a good spot to be in my opinion so why don't we start off with just providing a little bit of context about what eath 2.02 really is more serenity or serenity like for example we've seen

eath one point X as a term thrown around eath 2.0 maybe you can just share for the audience what the difference is exactly and what those two things are so I guess start with eath 1x iPhone acts as an acknowledgment that we have some work to do on maenette to keep it alive keep it stable keep it viable in the meantime while we follow this more radical path of an upgrade and almost rewrite 4/8 - OH and so the 200 is an acknowledgement that etherium is awesome and etherium is also like an a very early mover in this space

and so there's been a lot to learn and grow and a ton of research that's happened since then and eath - is us taking all of that research and insight and radically re our katha clean the system so that we can remain a viable competitive blockchain in the coming decades I've heard that eath one point X will eventually kind of become a shard in eath 2.0 is that still something that is on the roadmap is that yeah there I'd say this is still a research question and also just a question for the

community in what we want to see happen here I think the most palatable solution is to roll eath one into eath - at some point when we reach kind of stability on the east to front there's two to kind of paths you can imagine one would that be that it becomes a shard on its own but having an exceptional shard that has its own rules and has all of this like legacy code and client to maintain for the validating nodes and for the the people that are operating in general is probably not the best path forward because we have we'd have legacy maintenance forever and this stuff might not fit into whatever rent or state surge B model that appears in two Oh

and so another viable alternative kind of my favorite right now is to actually write an e BM interpreter in Waze and deploy it as a contract fork the state route of eath one into this contract and the ether balances and then allow interaction with the existing ëthere in one state through this contract that exists on a shard by in a stateless way by providing the merkel witnesses of the state that you're interacting with this is nice because it allows us to ultimately deprecated maintenance of one oh it allows us to roll it in but kind of kills still keep it isolated and due

to this stateless nature it allows us to kind of not have to think about how this integrates into whatever state rent or storage fee model appears in - oh so those are the keep 1o alive inside of 2o options and then there's depending on needs and community and also the technical challenges that might arise there other options and I'm not currently in favor of these is just let one o run but to you utilize two o to finalize one o so to essentially allocate a bunch of its security to the new purpose state system and lower

mining rewards over time and just kind of let it operate a perpetuity or to maybe have mining rewards on one o be a function of the amount of heat that is left one o and like have it naturally kind of moonlight that way I don't love that option because I think we've made some like strong promises about stuff existing I think there's some auger contracts about like will we be at Mars by 60 and I don't really like the notion of just letting it die but again this is kind of it's a mixture of a technical question and a mixture of what the community wants to see happen on this so I think well we'll maybe get a chance to speak a little bit more about that as our interview continues but Before we jump into because I think we should

actually explain exactly what eath 2.0 looks like before we do that I would like to hear a little bit of a history of where eath 2.0 came from when the first spec was proposed what did it come out of I know we I think we touched on it in the sharding episode but it might be good just to give some backstory here right right so at the beginning of 2018 there were two parallel research and development efforts for upgrades to existing theory maintenance one was just moving to proof of skates take Casper FFG the friendly finality gadget and the other was to add sharding via another enshrined enshrined contract called this

charting manager contract both of these proposals were going to have essentially exceptional like enshrined contracts in the existing aetherium state that managed the complexity of the logic of brute mistake and also managing shards there was a lot of work done on both of these in specking and in building out and prototyping I was working a lot on the CAF's where FFG front did a lot of work on that contract wrote the EIP 10 11 which I know parody was active in implementing and was getting close to becoming a reality there were some serious limitations on both of these fronts in doing trying to do this work

in the in the EVM the most obvious is just kind of the rate-limiting specifically just the amount of stuff you can process in the EVM because it's highly inefficient like trying to process signatures and update state routes in the EVM it's going to limit the amount of shards and gonna limit the amount of validators that could participate in either of these systems which ultimately is limiting the scalability and the decentralization of the system by limiting the amount of validators probably around May we were came to a few realizations one we're designing a lot of the same stuff in two places by having two kind of foundational games in the system for validators we actually we were doing a

lot of the same stuff in two places and we might have a strange thing or one game actually competitive competes with the other like maybe it's like not a lot about maybe it's more viable more profitable to be a validator in the shrouding manager contract and then you don't have a lot of base security in your Casper contract or vice versa that plus just hitting roadblocks the inefficiencies of doing things in the EVM and there was I was gonna actually have to do a little bit of rework on the Casper stuff and have to throw some of the formal verification work out the window by doing a little bit of a medium major rewrite of the contract all of that was pointing us to one we need to unify these efforts - we need to break

out of the EVM which you could reasonably do these things - one oh and not do them at the EVM but three given what we know now given the research and given kind of the trajectory and path of these more next-generation smart contract blockchain application platforms whatever there are it was more viable and we were going to get more of what we wanted if we made a more radical decision and architected essentially a new system in parallel to the old system and allow the economics and the community of the old system to seed the new proof of stake sharding eath - oh I

would say this question getting into this is like the you have this conversation in every company in every software project ever should I evolve this you know piece of codebase that I have written over the past two years and kind of add on the technical debt and keep working on and to make it the thing that I want it to be or should I just you know kind of leave that there and rewrite it from scratch yeah and no one ever has a good answer to that right and there's always people on either side some people love rewriting yeah some people hate it and another important thing is that by pulling it out so we have a we have a plane in flight I think people use that analogy all the time for

one Oh making radical changes to it to upgrade it was going to be very difficult and probably cumbersome and time-consuming and and hard to coordinate by breaking free and having the system operate in parallel to the existing system it allows us to move very quickly and unencumbered so like we can fork and upgrade this new beacon chain which we can talk about and the existing shards and just having a very loose link between the two at the beginning without having to really have him coordinate everything on the one Oh in parallel so it allows us to move much more swiftly to get to where we want to go I think that definitely gives us a nice basis to dive into e 2.0 even though there's no visuals it would be

really great if you could just describe the sort of major parts of this architecture and maybe tell us what they do right and I will do my best usually in person I'm like this thing's over here and I'm using my hands just circulating a lot so this is this is an exercise for me okay so we have the existing aetherium chain and we have a community we have contracts deployed we have ether we have kind of this foundational economic system this is to seed a new proof of stake chain that lives and exists in parallel to this 100 proof work chain so I in the in this new system best to think of the 100 chain as kind of the economic seeds like where

the foundational economics are coming from so in one oh we have a deposit contract where I am sending ether into this contract it's essentially a burn on there I cannot get it back out on the 100 from this contract it emits a receipt with proof of this and some information about me as a validator and that will then allow me to enter into the beacon chain the beacon chain is the core system level chain of aetherium 2.0 it is where the validators exist it is where their rewards and penalties happen it is where they finalize blocks it is where they bring in information called

cross links back from the shards into it and link everything together it's really it's called it's where a random number generation it's called the beacon chain because it kind of sits in the middle and it is a beacon in the sense of a random number beacon there's probably a lot of other words that would be good descriptors one kind of visceral is spine the spine chain like it is the center the spine of the system I mean just even calling it the system chain also makes sense in that like it's where the core system level stuff happens it's not where user accounts live it's not where state execution and contracts live it's it's not it doesn't gonna have a

virtual machine it's more of a state machine it has like very particular things that it can do in state transitions it can go through is this the equivalent of the polka dot relay chain if you're comparing the two yeah that's its that's that and it's really in these proof of state systems it is really natural to have this place where validators are congregating and where they're performing their duties and told what to do in their duties and proof of work you don't really need this because a lot of this the random number generator and whether how you're a participant or not that's handled extra protocol it's like I get this piece of hardware and I start all of that like all of that complexity that's wrapped up

in me getting a piece of hardware and generating all this stuff offline like you have to bake into a central place where validators the participants is not the miners but the validators are congregating and doing all of their work and so again it's it's a really natural design decision I think to put that into like one isolated component that then the rest of this some evolved out of so beacon chain so we got proof-of-work chain to see the economics of eath to the beacon chain which is the core system level chain you mentioned the validators live in the beacon chain so that's where Casper and POS is happening yes yes I mention I mentioned finality and by when I meant

say they finalized things that's where they do their the Casper cycle where they're voting on recent blocks that they say should be canonical and locked in forever and when certain thresholds of them do these duties then they finalize things so in Casper FFG you you justify something and then you finalize it and so yeah the core proof of stake algorithm is happening in there outside of the beacon chain is these charred chains charred chains are very similar to what you think of as a theory Amano but there are a number of them our expectation right now in the in the spec is that there will be 1024 of them these

live there's two ways to think about it the first is kind of like in a tree structure or hierarchical structure where the beacon chain sits on top and then it has all these child's charred chains as the leaves in the tree I think that's a nice view I actually really like thinking of it this is this is gonna be tough to describe but I think it can do it I like thinking of it in a three dimensional model so back to that term I used the spine think of the the beaking chain is the spine of the system and the beacon chain is as the beacon chain is growing you have all of these shards as a cylinder kind of around it that are growing in parallel with the beacon chain like if you looked at a cross-section it's like looking through a tube but then the validators of the

beacon chain they're sorted on to these shard chains and pulling back references from the beacon chain like links back into that spine and that's creating like this this architecture where everything is really like kind of connected together and the way that these shards Communicator through those links back into the the center of this this body so that's that's a that's a visual I'll go and do a little bit of the shark change so again the shark chains have accounts they have contracts they have state they have state execution and the way the validators at any given time on the beacon chain are told which shard chain they need to be validating which charging they need to be building gathering transactions building blocks performing state

executions and at the same time they're also told a different shard that they're supposed to be cross linking and so a cross link in that visual those are those links back in from a shard chain into the the core beacon chain a cross link happens every epoch which is approximately every six minutes where validators are in small what we call committees they go and they make sure that data is available from the shard chain the recent data and they pick a reference like a recent block and pull it back in to the beacon chain and so by doing that whenever these cross links are made by these committees it pulls in references from the shard chains and

unites the shard chains back into the beacon chain and finalized points of the shard chain so the fork there's a fork choice rule in the beacon chain how you find the head of the floor of the beacon chain and the way that you find the head of a shard chain is actually you go into the beacon chain you find the head of the beacon chain and then you find the most recent cross link and then you move into the shard chain at that cross link it's kind of like the last finalized block from that shard chain and you walk from there and so again everything comes back into that core system level chain these cross-links actually serve another role it's the way that this the beacon chain gets information about recent information about a shark chain and so in that it's the way that other shard

chains get information about each other and so at the foundation you have an asynchronous communication model between the shard chains through this cross-linking mechanism into the beacon chain I have two questions there so one is how many cross links per block can you fits this is slightly dynamic based on the number of validators but once you have four million eath validating the expectation is that you cross link every shard every epoch so I think that's so an epoch is 64 slots and we haven't talked about slots at all but there's 64 blocks can happen in an epoch and 1,024 shards can be cross-linked and in epochs I think that

16 shards are expected to be cross-linked about per slot although they can be staggered in the sense that you might expect like optimally you might cross-linked this shard at the next like it slot 100 but maybe it comes in at 104 because there was some latency issues on getting these things these ACTA stations that's another term that also means that you can like is cross-linking the main method of cross chain communication or is there some other way and if it is like that means he can you can have cross chain communication every like six minutes like you said the layer one so stuff enshrined in the protocol that is how

communications happen is asynchronously through these cross links on III search checkout there's a number of synchronous layer 2 proposals and our current path forward at least for the time being is to only enshrine an asynchronous model into layer 1 and to allow the innovation on the synchronous models happen in layer 2 one of which simple one is like it's called an encumbrance where I'm my eath by signing this message and like say we have a like I I have my Ethan a encumbrance enabled contract and you also have an encumbrance enabled contract another shard I can sign this encumbrance with essentially guarantees

to you that you have access to this eath whenever it does come whenever the cross link does occur so then you can take that encumbrance and you can actually you can now encumber your encumbrance by passing on this other signature and through that you can get a synchronous synchronous transfers across shards and there's also a number of synchronous state execution proposals again depending on the particulars of the contract and execution model but we due to the complexities really explode when you bake synchronous calls into the labor one protocol in that when you have reorg on one shard they might have

cascading reorg the cross shards and so all of a sudden you don't really have the isolation and scalability that you expected and you have people like all sorts of dependencies across this and so the the design currently again is asynchronous on the on layer one and innovate on this the synchronous entire tube you could also do like if you're not actually moving ether around you could also do a pure like data layer sync like whether it's synchronous racing careers like a cross chain communication layer - that only deals with data yeah and that would be pretty easy actually just like as you describe some of this there's definitely some echoes of other projects I mentioned the layer the relay chain kind of example

what do you think like what are the projects that you think have influenced a lot of this I know that Definity has influenced Justin's thinking a lot that was one of the early papers that he read that was like oh like there's there's some crazy stuff here I think the acknowledgement of the need of strong randomness built into the base protocol when they came with using the dkg threshold signatures really like I think brought it to the forefront a lot of projects that that's that's crucial and mistake you know I I definitely keep my eye on polkadot I am NOT super acute into what's going on over there I probably should be more but yeah I think

just in general there's just like emergent space of these next-gen block chains and they're all definitely influencing each other I mean everyone's kind of coalescing on this this idea that you bring in BLS aggregate signatures all of a sudden you can have like way more participants in the protocol doing things and so there's a lot of synergy being exchanged and a lot of that's kind of naturally just be conversations and conferences and things is there any like do you imagine I'm just gonna use this as an example but like something like cosmos do you imagine cosmos as influencing this or would you they be used in tandem with this like are like how do you imagine something like that working together with 2.0

maybe it's outside of the spec of what you need to think of right now but like yeah I mean the the amount with which interoperability is going to influence this like all these systems I think it's interoperability is inevitable I think it's very important I'm not going to make a guess as to whether there's going to be thousands of viable chains or tens of thousands of i/o chains or whether it's gonna be like three it it really I think it's gonna shake out in the next handful of years as to what happens there I mean if you look at some my I kind of leaned in the direction that there's gonna be a power-law distribution and that there's going to be a lot there's gonna be a few like heavy players and then like tons and

tons of little small players and so interoperability is important something that I think a lot about with so I mean obviously poke it on and in the key goal is interoperability like how do we connect Bitcoin in Z cash and ethereum and I'll make them play nice together with aetherium to specifically something I think a lot about is like where does the interoperability live like do we bridge to the beacon chain what can we get out of that like we can get the cross links and we can get messages but like if we need to bridge to all of the shards then we're like that's not gonna happen surely I'm not I'm not quite sure exactly the interoperability scheme Han okay go on cosmos but the

we're talking recently about how you can begin to use the there's phases we haven't talked about those but phase one adds the shard chains and just the data consensus on data and we're beginning to discuss how do you actually reasonably use this data maybe an eighth one or in somewhere else and because of the way these cross links are formed and because of the way the state route of the beacon chain is formed you can actually make proofs about everything on the shard chains via the state route of up the beacon chain and so I kind of alluded to it we want to use the RM to

to finalize the 100 chain in the time being and to allocate some of the security to the beacon chain and in doing that once we do that we've required 100 clients to at least be like clients of the beacon chain and we can expose at that point the most recent finalized state route to the EVM to the virtual machine and in doing that now the contracts all mono can make claims about data on - oh and use like kind of layer to state execution of that data some interesting things I think Barry White House working on it's like snark

rollup no snow and not even the roll-up he's working on an entire like snark act like vm narked vm and in doing that like he might choose to use consensus on data from e2 and have state execution of resolving these Starks in the state in contract on one oh and so again I'm not to get into the exact particulars of how polkadot is doing in or out but that state route might become very important it sounds pretty reasonable in the ideal way to do to make to build a bridge at least in the polkadot world is to have a

pair of chain that is a like where the runtime of the blockchain is a like clients of the other chain and if your alight clients of the beacon chain and you can get access to proofs of data then that's that's basically all you need for Interop yeah one last thing about sort of the makeup of it each shard is that are they sort of gonna act like unique block chains is this I know I mean we did this episode on chardy and I know that there's different sort of ways of thinking about it but do you imagine them ever existing is like micro ecosystems and stuff or yes and maybe especially because the path we're taking right now is economic load balancing so you can

imagine a charted system like this that's automatically doing load balancing on the system level and like moving things around and kind of like keeping that away from the the the user or whatever the framework the user is using but again this brings up kind of massive complexity into your system level stuff and we've opted for going down a path of economic load balancing where the idea is if shard 0 is very used and maybe expensive I moved to shard 1 or if some applications that this contract that I need to deploy exist on shard 7 then I might choose to deploy on shirred 7 granted there's this

mechanism for yanking where if a contract is enabled to do yanking you can move contracts around between shards for example maybe there's a core token contract but my tokens with respect to that token contract or their own contract and because I have ownership over those tokens I might yank them around between shards so yes isolated and in some respect load balance through economics and because of that you might imagine a little microcosms of different activity appear I can't claim to know what the emergent behavior might be

actually on the system so be very fascinating - maybe analyze your 2n so as I said in the beginning we talked about this on the podcast like six ish months ago a long time ago a lot of things that have changed I think a lot of what's going on in the Twittersphere and reddit and everything else right now is like why are thing well I do things keep changing in my opinion mostly from people that don't know software development and so I have no idea how to build software but that aside how has the spec evolved why has it evolved and like how does that happen for I guess the first thing is I'll comment on the Twitter

conversations this is only I think very recently moving out of a research project it's been it's been transitioning out of a research project and into an engineering project over the past six seven months we released a feature complete relatively stable version of the beacon chain portion of the spec that a lot of implementation teams are working towards getting implemented and and towards test nets but that said the research version the research component of this project and the iterative development of the spec is is very strange with respect to many software projects because it's happened entirely out in the open and so every time we're going down a path that become

where we learn a lot and then end up changing things this is all very public and under public scrutiny and if the areum is very important and very valuable it's a lot of people so obviously there's a lot of conversation that sparks up around that but to more specifically answer your question what has changed and I talked early on in the episode around May or June we deprecated a lot of work these the the paths towards doing taken charting and contracts and existing EVM and so that was a radical change beyond that the next the next couple of months were really like taking many different threads of research and weaving them together into just the basic like

structure of a spec and like proving to ourselves that these all these things we've been thinking about can come together into a viable viable system then after that September until now has been spec writing taking these research components and like fitting them together into like a sane way for people to implement and we've at first there were probably one or two things that came out that then were like almost radically reacted although using the same basic components and cleaner tighter more elegant ways and then there's been iterative design on the spec since then working through

bugs but also just making things more elegant like if we decided to build the spec that came out in October like it would suck um it would suck in the sense that like it was not an elegant it was not elegant it was not the components like weren't fitting all nicely together there were plenty of bugs things were had terrible names like just we had a lot to think through and a lot that just was going to take this iterative design and we've had him a lot of implementation teams working on the spec arguably maybe too many at the beginning so early on maybe in the fall of last year it was very valuable to have one or two teams in the bleeding edge like

constantly working through things but I think we dragged a lot of teams through this process now that again we have this like concrete phase zero which I will say I'm very proud of I did not know how much work this was going to take and how long is gonna take when we started but now we have it I believe it is good palatable elegant and that now we have all these teams that are working on it have this like very stable target to work towards and in that now we're beginning the same process on phase one which I mentioned is the consensus on the shard chain data and phase two which is the state execution so I imagine things are gonna be going a lot more

smoothly because the implementation and engineering teams have like a very concrete target while we go through this iterative design phase on the other components I'm trying to put myself a little bit in your shoes and you know trying to come up with or working to come up with a spec and having a lot of people weighing in publicly and at the same time like needing you need to have the spec developed in order to actually start having it be engineered so there's some sort of time frame that you need to finish this thing on and at the same time you're in a such a decentralized space everyone will have an opinion everyone will some people will want to join who maybe shouldn't be joining and how do you I mean I can just picture the

kind of challenge that is because you don't want to be exclusive you don't want to like tell people that their ideas aren't good you want to make sure that you're very inclusive but at the same time like super fixed decisions need to be made I imagine yeah have you balanced that mild chaos now I think it's kind of naturally happened in that the theorem research team the foundation research team led by vitalik have foster a lot of these ideas over time on a three search with us which is already kind of this like self-selecting group it's very you go in there like it's very dense it's very hard to like jump in and

just like give an opinion and so then when we move to specs like it begins to open it up a little bit more and so you have more engineers that are weighing in but then we weren't even we weren't operating on github at first we just had this like document that with it and so it was still kind of isolated and so we still were able to make like big decisions quickly and then we move to github which is a lot more naturally kind of collaborative environment and over time we've had many more teams and many more people weigh in again there's still like I think there's still like kind of a technical barrier of entry in that if you're not very cute in to what's going on it's hard to come in and like give a very strong opinion about

something and so but the teams that are that are dedicated and digging into these things have begun to give especially if we've moved out of research and more into an engineering project given more and more feedback and this has been excellent in that you know we have our own set of expertise but every team that comes to the table has a different background at a different set of expertise and has really like hardened up the protocol and made sure that we're thinking through all these different components and even now some of the some of the engineers that are like deep in the weeds on the theorem one because there's constantly stuff to do we've signaled to a lot of those engineers like ok now that we have this stable spec like please we've had more insight from them my kind of battle testing some

of the ideas that we've we played in foundation there so again mild chaos like there's constantly somebody who has an opinion often great opinions but it's a it's it's like a you know I think it's naturally it been very organic in the sense that we've managed the complexity reasonably and not had too much hangups doing this in the public something that I've struggled with myself and working on this and and like within parody was something that I don't really think that the public really understands is on one hand I kind of want to wait until there's some version of a spec that we can start working from and I don't want to have like the rug swept under my feet

on the other hand I know that as soon as I start working on the spec I'll have useful things to contribute back that will change that's bad yeah there is this back and forth that needs to happen between the spec writers and the implementers and that's what you're talking about like the teams who are actually starting to build this now are starting to provide feedback and that's why things are changing so there's two types of changes it's sort of like the tie like dreaming up a new idea and like putting that into the spec but that's not really what's going like what's going on at this stage at this stage is more like oh we sent this to the developer and they highlighted that this thing will actually not work because of this reason and we had to change it and

so I did the distinction between these two types of changes is something that I don't see anyone really talking about like they all just think that oh someone is around and changing things all the time right right and I 100% agree I think there's been this kind of continuum over the past six months as we we've been changing from this research component where yeah Vitalik or Justin or who knows like dreams up like oh we should actually be doing this and then you have something change but but we have entered into this this engineering like iterative engineering phase where like experts are saying oh well actually we should probably optimize it this way oh there's a bug here because if you

think about it this corner case and and so things things have entered into a different a different phase you're right if there any is there any like example from history and other open-source communities where something like this to this to this extent has been undertaken because it's quite it's quite a large ecosystem already and there's a lot of people who are well versed do you know if I mean I don't know my linux history but is there anything like that yeah like Linux is a bad example because lineage decides on center no I don't know I mean the general so on the on this latter thing that I'm talking about word look with this well not really something we touched on

explicitly maybe but bike shedding is a thing that happens everywhere and it's where like instead of discussing like now where to put up the shed or like how it should be how it should work it's or your discuss discussing what the paints of this shed should be which doesn't matter so right like bike shedding happens a lot in software development in general and especially so enough open source and I can imagine like we've only seen the beginning of by shedding I need to development there will be more to come for sure right I think we've talked about I mean see relation poor formats are very important but we've talked about serialization formats probably more than anything else on the public

yes that's a typical like budgeting problem that's the paint yeah maybe it's like the metal framing yeah and I think this this kind of gets me curious on on this like it's like whether it's a research change or an implementation highlight or bike shedding at what point and and who needs to step in and say hey like this is enough you know we need to stop talking about this this is final we're gonna go with this and let's move on like who does that great question and ultimately obviously the EF does have some sort of like

leadership position in the community and can make very strong suggestions at the end of the day no one has to do it um and there can be mutiny and people can say screw you or not I'm saying that version of the protocol we're gonna have red paint instead of like paint and but but that said there is a strong like cohesive Drive people want to see this come to reality and so at least in the in the phase zero component the spec like I am becoming more and more resistant to change and getting some pushback right like some teams like no

we should change at all like we should keep changing it we should make it better better better whereas you know I'm beginning a hair on the side of like okay we need to like Manisha we need to build this thing and so I think you're gonna see a natural tug-of-war as people come more and more onto the side of stability but it's gonna be not a battle but like a little garnish yeah skirmish not a war where is it bigger than a battle I don't know it I might I might exert some of my power on the calls being like guys like we decided this let's just be done but we'll see no one's no one's in charge right so is there is there some sort of like ease to point out core dev call sort of in the

spirit of like what HUDs yes yes yes we do we had one this morning it's called the e2 implementers calls that I run and they happen every two weeks very similar the core tubs and we have an increasing overlap between the people on those calls it's enough of its own effort that we couldn't really have it all in one call and it's been more of a ragtag group of people kind of experimenting and getting in early on this and it's becoming more of a formalized thing over time and I expect at least for the medium term for there to be these two calls in parallel because there's so much to do on both efforts so yeah there on Thursdays as

opposed to Friday's they're currently on the same week so it's today and then tomorrow today's Thursday of the 14th but sometimes they get off depending on scheduling conflicts and stuff is there a is there a Hudson are you the Hudson I might be the Hudson as then I run the calls I think that I'm I'm more deep in the technical weeds of some of this stuff than Hudson is and so I think I bring a little bit of a different tone in that I'm like explaining a lot of the technical things but yes I've facilitated kind of the conversation around these calls and for for a little context to our listeners Hudson is the

person who runs the sort of general etherium Cordova call he's also we've also recorded a podcast with him where he talked about how he runs these and some of the challenges that come when you're dealing with a very decentralized space and you're trying to make decisions yeah and I've learned a ton from watching those calls for years and then being a part of those calls with Hudson I think he's a really awesome figure in the space I would say that the eath 2 calls and the cordetta calls are very different in nature I mean it obviously comes from the maturity of the project but on the on the coordinate calls its parody get and some minor clients implementers like one of each and it's I don't know maybe like

15 people ish the heath 2 calls are like 40 people oh and the discussion is very different in terms of like the Cordova calls is like what are we going to do about this EIP what does the community think what are like it's a lot of this big discussion about how do we make decisions on what to do whereas on these two calls are more like yeah talking in concrete like should the serialization format be little or bigoted and the input yeah definitely agreed in that it's less the process is less encumbered by an existing protocol

and that's again one of the reasons that we thought it was the most viable strategy to have the e to chain be built in parallel so that we can move rapidly one in in the efforts around coordinating Forks and into just and making decisions like we can over time formalize the process entry integrating the e IPS or maybe we have an e IP to S or whatever and and move into the more formal framework but right now like have people who are very into the project like have people that technically want to weigh in and just kind of like move move quick you sort of mentioned that early on are like in the fall you had a

lot of people who are looking to build clients or they're working on this more intensely how many clients are being built right now somewhere between like seven and eleven I think it depends on the week and there are many different levels of sophistication there and that there's like some like larger funded teams and then some individuals that are experimenting with some hobby projects this there's probably a lot of reasons for this one is very exciting people are excited to get involved with the future of aetherium and to it's just like I honestly think that some teams are like

this is I can make my mark like there's a there's a chance here there's a lot of open space and greenfield to come in and be like a player in this new system and so it's drawn a lot of different teams of wide diversity of backgrounds I think we had a we had a lot of teams come in very early very excited and I actually I I take the blame for that and that I think I sent a little bit too strong public signalling and being like let's do it let's build this thing again because learning can help I mean I want all hands on deck but specifically I recommended to the EF grants team to put

a note in the one of the grants releases like we're looking for 8th - Oh implementation teams and like people people really took that to heart I've had a lot of teams have shown up and again I was probably a little bit eager and a little too early in that signaling and have dragged people through this like very iterative design process where you know I think I one team called dthe he's just one guy right now but he popped in probably like a month ago when things are really starting to stabilize and like can like just lay the bones there and doesn't have to like work about or worry about reworking the whole thing three or four times so again

yeah lots of teams lots of excitement we shall see what becomes viable what paths forward the cool thing is actually Frederic and I were talking about this competition you know we're all working towards the same goal but there's still like this notion of competition between teams like who's gonna get users who's gonna have the viable client first who's gonna build the API that people are gonna want to plug into who's gonna build like a really nice validator interface with like backup technology or in tech to connect multiple nodes and all this stuff like it's not it's not in the spec this is all stuff that's like on the outside of the spec that really

makes a client unique like what language did you pick what what tools are you providing what interface do you have and so yes there's a lot of communication and coordination effort on having a lot of these teams involved like this morning we had our call and like I was like okay today client updates let's keep them quick because we have a lot of goal here but ideally we see a lot of like competition and a lot of innovation because we have so many people involved that's not really that's an amazing observation that there's these teams competing in that way you'd gain a fight at some how so and also it was interesting to see this holic handing

out a couple thousand ether on Twitter to vary his team's it might have helped and breaking and more people that participate in that I want my own my airdrop do you think so I had the question if there's any sort of AIP process for each 2.0 but it sounds like it's a little early for something like that but do you think that that could be a way to funnel some of that energy yes and changing it from an EIP to something more exciting where there's prizes I don't know maybe so I mean we have a lot of chance to learn from you know take the good and fix the bad from both the

technicals respective but also like the community organization perspective and so yes I think I think that's going to be a really valuable conversation to have over the next many months maybe bringing up at some of these magician forums it's like okay this is our current process for a IPS how might we make this better how might we read architected I haven't thought about this too much and how you might change the EIP process and nor am i necessarily advocating for it because that might just be a can of worms but there is an opportunity to make some changes here and we should maybe instead I mean I think I can

imagine also like maybe bounties oh yeah bounties have actually been really successful for a lot of these client teams already get coin is super awesome I'm a huge fan a lot of teams I know have done some early bounties and actually found like regular contributors found hires and stuff I'm super stoked about bounties in the space in general and I think a really cool thing that a lot of the - Oh teams have taken to heart is this idea of fostering a community and a repo that enables the community to be engaged we've seen it like a ton of outside engagement and like just random people

popping in whereas depending on how you architect your your github project or whatever your your repo is you can either like make it really welcoming or you can make it like totally impossible to come in so I think we've done a really good job there so to wrap it up I think we need to do that at some point even though it's an interesting topic I want to talk a little bit about the future and something that perks me and something that people ask me all the time is like what's the timeline one but when youth to point oh and it's such a like no one can answer it no one else so I would rather talk like concretely

shorter term future what do you hope will happen in 2019 like what do you hope that we can ship what what process changes would you hope for like what decision-making will happen over the next year so I fully expect in the next month or two to begin to see viable beacon chain clients targeting certain versions to the spec and communicating first just test nets with their own client and then second with test nets interoperability and sure client test nets a beginning to be short-lived and then further timeline having some of these like long-lived test nets where we

can battle test things have some adversaries come in and try to break stuff I'm kind of been mowing the cosmos game of stakes so maybe people do something like that well we can have these like medium like you know month long test nets where we have players come in and try to like collude and break and do some interesting things in the networks I do and I'm hesitant to say this but I do I do I'm not hesitant I just I'm sure somebody's gonna quote me on this but I yeah I I expect to launch the beacon chain in 2019 the complexity of phase 1 which is the sharp data chains it's not actually that

massive on top of the beacon chain so I don't expect the timing between those two events launching a phase zero and launching a phase 1 to be too long and we are beginning to work I expect the phase 2 spec to certainly be becoming moving towards concrete definitely within 2019 we're moving on a lot of these things in parallel now now that the engineering effort has begun on the phase zero stuff we're beginning to do the necessary work to put all the state stuff together for Phase two working a lot with the II wasn't team now so again I expect to see

some serious movement this year I think one thing that's important to note is if to some people just want to see ease to like done but I think it's important to know that there is there's a lot to gain and each phase in each iteration phase zero being that we can begin to finalize eath one and people might then advocate for reduce issue and so it seems like the community's very into that kind of thing with phase one with the start date of chains we can then begin to do all sorts of interesting layer to state execution work there's a lot of interesting ideas on that on e3 search I

mentioned a few at the beginning of the podcast how you might actually use the earth to data consensus for state extinction within eath one and then obviously the end goal with the statistician or base to but again but again like iterative like we get we have concrete gains at each of these phases yeah that was actually a point that I that I thought we might want to just revisit quickly when you're talking about these this excitement in this energy about eath 2.0 and a bunch of people jumping in and sounds like it's almost like a new generations coming in trying to make their mark you still sort of need to and I know it's not really maybe your group that has to but in

general as an ecosystem people still have to folk they have to remember that one point X is still there and that there might need to be some I don't know some check-in points yes absolutely and and the dialogue is less and less disparate and that there's increasingly people that are part of both sides of the conversation there are people who distinctly are going to put a lot of effort into the 1x or 200 or vice-versa but these things are not happening entirely in isolation anymore and unifying the minds on these is definitely a priority and so definitely

something that's happening more and more [Music] ideally anything that happens on the 1x front especially with respect to storage fees can it can inform to Oh ideally like some of the things happening there are directly related to some of the work we're doing into one thing that I think is important and that I've talked about in various places is setting realistic expectations and like you said with all the excitement everyone is asking for this or that or eath one point X is happening and like you said in the beginning as well lucky if the problem with one point X is now it's this package of things that people

expect and not all of it is gonna happen very likely so I think managing expectations as a whole is pretty difficult but specifically as we've seen over you know the past with 2.0 is at first it was Casper and proof of stake on the main net and then that was strong like we've we've pushed the what's what's the expression push the goalposts remove the goalposts several times and yeah from an outside perspective it it's disappointing and it's like disillusioning when things keep moving but it's internally it's not really moving it's not that we're like just

around and pushing things out or like delaying things in terms of like we can't get it done it's how things are changing and changing and iterating and evolving so how do you manage expectations in an rot in an environment like this where people are looking forward to something and you like you want to say yeah let's ship a beacon chain by 2019 but you can't really yeah because you know I don't know that it's that magnet yeah so when when it like when it gets there and it doesn't happen then there's good reasons for it but it's still like oh but you said and then everyone is like disappointed yeah I think in general upping the communication and resources

is something that we're definitely interested in doing from the EF side and that we've been encouraging all the Tuhoe clients to do and not just update you know we implemented X we we did y but to give a more open dialogue about the process and what's happening and we attempt to do that obviously with these tool calls but they're they're long and they're dense so providing more providing more resources and just reiterating like none of this shit's ever been done like we're making stuff that's never been made before like we're we're pushing the limits on p2p networking we're pushing the limits on the games theory or pushing the limits on economics like it's super super exciting and I know that a lot of people

have a lot invested both financially and just kind of like personally immensely like people are really into this stuff and so like we're doing our best and we're working our asses off and tons of people in the community are working our asses off and I encourage you if you want to be involved it can in the sense that like go read through read through a paper that you find interesting and fix correct like correct typos like work on documentation work on a local community engagement like there's so much to do jump in and be a part of it and as you become more part of it you'll actually you'll be more clued into the reasoning and the

reasons and the kind of the realistic nature of building these things oh well I think on that note we want to say thank you so much for being on the podcast yeah thanks for having me I had a blast so I guess everyone should keep their eye out on a few sites should they what are the sites that people should be looking at to to keep up to date on this yeah it depends on your level of how technically you deep you want to get into this stuff some of the conversations on the bleeding edge of what might you expect in the phase 2 stuff is happening III search a lot is happening on the 8th - OH spec's repo if you are interested in reading the spec now is actually a

really good time the phase zero spec because we've cut like relatively stable releases beyond that again a lot of these a lot of the implementation teams are putting out like every two weeks or every month updates so that's a good way to get clued in and I know specifically a few of the teams are working on some some demos and simulations and stuff that you can run on your computer and I expect over the next two to four weeks to have a few of those floating around so follow some of those teams on Twitter like lighthouse Nimbus Pegasus oh man there's a million but follow them they have some cool resources and and again like get your hands dirty like we were

excited to have people playing with some of the stuff probably in within March right cool well thanks again and to our listeners thanks for listening thanks for listening you [Music]