ZKPodcast: Eth2.0 update and a look at Libra with Raul Jordan

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 catch up with Rahl Jordan to talk about his recent article on the Libra blockchain as well as a new fresh update on eath two developments [Music] before we start we want to say thank you

to this week's sponsor Eragon one if you love working with talented designers building smart user interfaces or if you're simply excited about working on making dowels easy and accessible to create and manage then you should check out Eragon ones available jobs the company is currently hiring a front-end engineer to help build the platform for modern organizations for more about the front-end engineering role or available jobs in general check out Eragon dot 1 slash jobs that's ARA gon dot o NE slash jobs so thank you again Eragon 1 and now here's our interview with Raj Orden so today we're inviting back row Jordan

from prismatic labs to the podcast to give us a little bit of an update about eath 2.0 and the work that they've been doing hi ro hey Anna how's it going good how are you good good and as always we also have Frederick here hello so I think Raoul since you've already been on the show we actually had a full episode I think last August with prismatic labs but something we've started to ask guests when they arrive on the show it's a little bit different than what we were doing back then was not what have you been doing or what got you into this but rather why did you get into this yeah absolutely so you know just a very brief background for those that are not familiar with their work so prismatic labs the team

working on earth 2.0 client called prism we're building everything and go my background is I'm a go developer I've been working with the team since early last year and yeah so far we've been pretty much started out building out sharding and eventually went full-on into the whole East 2.0 effort so a bit of background I was uh it was pretty much before this I was working on a web 2.0 startup I came from a world of full stack web development and you know I've been learning go for a while as well and was just extremely curious about what are the one of the most important entry points for people to contribute to eath at the time there was a sharding FAQ that Vitalik had out there very few people were working on it it was essentially just just a write-up

and there was a lot of buzz around like how to scale eath but nobody really taking on that layer one that layer one implementation so we started voicing around a message on you know on reddit in a few different forums I came across my co-founder Preston Van Loon and we assembled a team of other open-source developers and we just started you know hacking away I think there was just like extremely motivating to know that hey this is a really big unsolved problem that there are people willing to support and people willing to also give guidance on from the research standpoint and also from the implementation standpoint we just sought out to build it out you know in the beginning as a volunteer effort and gradually evolved into something that we're excited to do full-time now I think that's a great way to get into something as well by the way to sort of

look at the project and think to yourself where where can we have the most impact and like where can we make the biggest difference rather than you know what's the latest thing people are working on or like trying to write a trend but I'm curious when you started that work on sharding and all this stuff did you imagine that it was gonna be multiple teams working on something in that you know you're going to work closely with the research team at the EF and and all this stuff or was it more like I think we can come up with a solution here and like propose that definitely not the the read the way it started was actually more of like one of

the many parallel four efforts going on in aetherium so at the time there was a lot of us especially on plasma state channels other layer two solutions and it just felt like one more vertical and the whole theory I'm a hub-and-spoke model that it wasn't really a unified ich 2.0 effort like this is a major upgrade that we're all gonna team up with and kind of put our hands together to figure out it was more like hey we're just building out sharding which at the time seemed like a very a very constrained aspect now it's become a full-on effort for sure so I think we want to spend most of this episode talking about updates about prismatic and eath 2.0 but before we start into that one of the reasons that I reached out to you recently to come

back on the show was actually due to something quite different you had written an article where you did a technical deep dive into the Libra stack this is Facebook's Libra cryptocurrency project so I'm kind of I'm kind of curious maybe just start this part of the conversation out why did you do that yeah so the reason 1 & 2 Libra was just because really you know building out building out an implementation efforts such as e 2 is can be a little bit disorganized and you know there is no central project management every team kind of is on their own in terms of how they implement things and how what design decisions they're undertake whereas Facebook obviously has a very strong team of PM's has a very strong you know set of engineers that kind of

understand industry best practices and have a set of company guidelines in a playbook to build things out we wanted to understand kind of how their design decisions and like affected their final implementation understand kind of how like an industry giant is able to you know put their engineering expertise to build out something like this and see how we can compare it to other implementation efforts in the crypto space specifically ours so we've been you know we've been very curious to see you know how kind of they stack up to other projects so yeah we were just curious about their code see how they build stuff out and see how things get built out from a centralized organization what stood out to you when you were doing this deep dive I think we

were very impressed by the quality of some of the design decisions that they took so typically you know they they chose technologies just because they know they're proven and they work and and they've been they've been in production for a while so as an example of the Libra project uses this this RPC thing called G RPC which is a project developed by Google that lets you kind of enable you know server to server communication and queering information so it essentially helps you establish the API of a node we opted to use G RPC as well because it's been in produc you know at so many other companies in the world especially at Google whereas many other you know we notice that a lot of other teams in the space are actually advocating against that they're

advocating for creating our own solution and kind of going our own way so we've been kind of in the middle of this debate of like should we be using tools that are you know that that exists are in production out there or just eath need specific technologies to eath right we don't want to reinvent the wheel we want to understand how we can leverage the best things for the job so looking at that you know we noticed that they they they follow a lot of similar reasoning of course and we wanted to understand kind of some of the things that they did do differently and kind of what that look like I think that's an internal discussion in engineering rights and it is interesting to see how different you know companies and

projects approach different things ethos a lot of these discussions around you know networking and how do we do not only RPC but general like message construction and compression and serialization and it has its own sterilization libraries and and a bunch of things that you know at the end of the day you can always make something that's slightly better you can always make something that's you know given that we know this domain and we can customize it to this or we know that this type of data will be more common than that and therefore we can have a serialization blah blah blah you end up with these constantly having to make these trade-offs of either we can use

something standardized or we can build something completely custom and it's slightly better the question is does that it's slightly better Ness actually matter at the end of the day or not and yeah I can imagine an organization would opt more on the side of let's just use what exists and get something out there right another thing that we were looking at was you know we obviously the Libre project spent I'd say probably the most of their time surveying the crypto landscape to see what tools they could use that have already been built perhaps in designing their programming language thinking about their consensus protocol thinking about how they're gonna do p2p networking and you know we were just curious like they were gonna leverage anything that eath has built over the years like

any of the ideologies or technologies that have been built so we were just looking at it from that angle I think after that we started getting curious about okay what is this going to look like from an end-user standpoint our end-users going to be able to replicate the whole Libre chain and I think that's what led to the creation of the article right like understanding what are their motivations and does libros code align with the intentions of Facebook with building this project that was the main question we were asking as we were writing out the article hmm what was what do you think was kind of missing from their design yeah actually so looking more at their code although they've been choosing some very good technologies for the job a lot of things

are actually missing it's definitely I would say it's definitely not not close to production they're missing so many important pieces of kind of the node API what information they're exposing right now it's it seems like it's mostly like a kind of like something you can try out and just mess around with so you can you can essentially create an account you can create a with their internal wallet that's built into the client you can essentially mint some Libre based on a faucet that they give you you can send Libra coin to other people in the network you can query specific account information and specific transaction information but you can't really do much more than that right they also put a lot more effort into kind of making sure that you can compile their move programming language for smart contracts

but aside from that you can't really do much I mean you can't really deploy into incident to their test net you can't do as much one of the things that really stood out to me was that essentially we don't even know if the data we received from their test net is is trustworthy basically they give us this libra endpoint so something like libra endpoint calm or something like my API dot Libra calm and you can request chain information you can request account information and they give it to you but we're not actually appearing with that node we're not actually getting getting the chain data and transaction data as it comes along so you know it's essentially a black box at this point we don't really know

what's going on what was your impression of the language and there via the move language it does have some interesting decisions around primitives so by primitives I mean like how do we represent the unit of the unit of currency the unit of a coin in in the language their whole paradigm is that you know like ether and a theorem in particular and solidity has has quite complicated ways to represent kind of numbers and how to represent like the unit values of eath and engrave values in the move programming language they focus a lot on like they want to make their programming language around moving coins around basically right that's the origin of the name they want to make sure that there's a very strong

core primitive for like one coin in the system making sure it's properly handled has a lot of good helper functions and making it easier to kind of kind of basically write smart contracts the way they're intended to which is to essentially send and transact information between parties they want to prevent a lot of these a lot of these bugs that typically arise in solidity code due to the nature of the language by having kind of stronger and tighter control around the primitives that's one thing that we noticed and yeah it seems like it's still obviously in its early stages what what project already in the wild is it closest to is it closest to aetherium do you think I would say I would say it's it it it I don't think it is in particular I don't know if I have

one particular to compare it to one thing that Libra is fortunate to have is that they don't have to operate under the constraint of handling millions of validators right they only have to worry about handling a handful of authenticated like privileged validators right so that makes a lot of your assumptions simpler it makes it a lot more scalable by default you don't have to worry about kind of the things that we have to worry about in aetherium like we want anyone to be able to become a validator if you have 32 ether and this comes at a very big consequence around kind of like verifying signatures like without having fancy signature schemes like VLS which is what we have it makes it a lot harder to reason about you know it makes it a lot harder to design strong and robust consensus models so

they're lucky that they don't have to worry about those things and they have a lot a lot simpler consensus paradigm I'm just actually what you described sort of in the beginning there when you started talking about Libra you talked about this this team and sort of the way that they can make their decisions and I think that's actually good framing for today's episode which is gonna be more about e 2.0 and like where it's at because I mean in a way do you feel like do you think because of their very very centralized nature I mean I think this is kind of obvious but like because of their very very centralized nature they were able to just like make very sharp decisions very quickly absolutely I think it comes at a downside that you

like the engineers themselves implementing may not have as much of a say and in in a lot of these decisions so in 82 when we come across a problem we spend quite a lot of time deliberating among the teams along probably best practices whether we should approach it in certain ways and we usually end up either changing our mind or or just learning a lot about you know different perspectives of how to do things you know it Facebook also is lucky that the Libra project right now only pretty much it's only has one official supported implementation rust there are some things that you know in the e2 we have many different clients and go and Python in different languages one design that one decision that you might take in a Russ project might not

translate very well to a go project so you know you need to have this very kind of this very decentralized process of figuring out the best way of solving a problem whereas these guys they they can just do it you know they can just go along and do it but obviously that comes with the downside so what was your kind of final takeaway from the Libra review that you did based on the code and kind of the way everything is written in their repo it seems to allude that users will not be able to replicate the entire state machine so that is that I won't be able to run a node peer with other nodes and sync the entire chain and receive incoming transactions and blocks as they happen actually the Libra team responded to kind of to my tweet storm about that

and they mentioned that it is under horizon and that's one of their biggest kind of kind of the biggest plans moving forward however looking at the specifics of their response and their blog post it seems like they will they will still not provide a way for users sink it seems like instead they're gonna provide some api from some node endpoint that you can then receive some state or chain information right so why this is not exactly the best is that you still have to trust kind of this endpoint you still have to trust this like API dot Libra com URL sending you the right data and you know from my understanding I don't really see much incentive for validators that paid ten million dollars a seat to kind of allow external peers to sync with them I mean they're they

don't have to do that it's not it's not in their best interests or best incentive to do so so overall it seems like the Libra project still might not make might not make the blockchain accessible to end-users as they would want to also one of these questions of like it's it's sort of promised but once something's live with like actual users and like you mentioned like companies who've paid a lot of money to be to be part of it even if theoretically it might have made sense in the early stages at this you know at the time that it's actually supposed to be implemented this way wouldn't actually be able to be due to all sorts of you imagine I can imagine maybe there's a leap API dot Libra calm or there's a Libra visa comment point

and you might want to get some chain information and you might just be you know your they might tell you like oh your rate limited or oh you can't access that piece of information you know that's totally can totally happen I don't see why it wouldn't happen doing a little bit of update on you guys and mmm what have you been up to in the past years what's the latest with prismatic labs sure yeah last time we spoke last time we spoke we were actually on the brink of releasing a very local kind of simulation of ease too so you can basically launch a local chain in your computer you can test it out you can see the chain advancing and kind of you know people producing blocks locally since then it's been a whirlwind we've been focusing a lot on a public test net

release for phase zero what this means is that we wanted a public permissionless kind of accessible test net where anyone can use some test net ether so something from the Gourley test net deposit 32 ether and basically become an e2 validator so you're you're basically assigned to propose blocks to vote on blocks and you can you can you know you do your job and you earn rewards or accrue penalties based on your behavior so it was a very big milestone for us because we wanted to make sure this next test was as open as possible we wanted to give people a feel of what the real thing could be like and we consider it as a success we've had we've had a test that's that we didn't expect to last long to last for several

weeks we've had a lot of bug fixes due to this a lot of interesting people coming on board and just asking hey can we contribute to a - can we build maybe a dashboard to visualize mice taking rewards is there a better way to display this so really just iterating on this user feedback is so invaluable especially when they have almost full autonomy of running their own node and having the ability to interact with this we actually ended up not running as many nodes ourselves most of the nodes are our testing that actually will run from the outside which was fairly interesting what's the name of your Testament yeah it was called the Sapphire touch net so I can share the link with you but it's a it's you can look it up on pride labs net and that

should give you the that should give you the the access to it isn't this is maybe gonna be a little bit of a basic question here but does the each client have to have their own Testament or could client share that definitely at the moment ours is only single client the reason being is that you know every team is on kind of a different timeline and working on different aspects of the project the main goal definitely is to have a multi-client test night right that's closer to what we really need and what we're gonna have in production so ours was just really kind of a proof of concept of the work we've been doing over the months coming leading up to it I don't think it's that critical to have right now I think right now every team is focused on interrupts and I - one

thing you mentioned there of like moving ether from it set like some other test net so it starts taking with it does that mean you've implemented all the bridge stuff there as well that's right so just a quick recap for those unfamiliar on how a kind of the e2 onboarding works say that you have right now 32 ether well there's going to be a specific smart contract deployed on the eighth one chain called the deposit contract where you can send that ether to the contract along with some other parameters you can launch one of our nodes and one of our nodes will basically pick up that the deposit happened and you'll be on board as a validator on these two it's essentially a one-way one-way deposit so you can't get it back on the original

chain it's basically locked in there forever and then yeah so that's we implemented that whole process we wanted to have the thing as close to the real scenario as possible let's go how is the that bridge done on like how do you detect that the deposit has happened and and registry yeah it's pretty straightforward we just subscribe to log events from each one notes and there's there's a smart contract address where deposits go to so it's it's pretty pretty straightforward to do that there are some concerns that have been raised recently like with respect having this like you know in the case of a reorg or in the case of something being attacked like how do you ensure the deposits you know make it there with integrity that's toast that's

still kind of an open domain but overall it works decently well so who needs to run the eighth one nodes eighth one nodes well right now we use the Gourley test net so that's that's the public approval Authority test net that's been out there since Berlin so we just use that actually in production it's going to be the real eath 1.0 chain you can point it out to any node in Ferrara you can run your own node as long as you're synced with the chain yeah but that so that's what I mean like you need to sync with the chain and then like your software subscribes to log events on that node but then right how does like there has to be some sort of Oracle thing or like a quorum validators that say yes this

log actually happened before anything can happen on on the eath to chain right that's right I think there is also a small there's also a delay of time between kind of doin deposits get filled up in the contract and then there is basically a there's basically like initiation of the validator so it's a pretty long period of time so the way it works is that there's something called an eighth one follow distance so essentially a thousand 24 blocks have to pass by before we can even consider looking at a deposit so essentially there's just like sliding window of availability in which you can verify that a deposit did happen so it take it takes a long time right now and if you see that your peers have seen a deposit and you haven't well you know

maybe something's going on in particular for launching the chain itself there will be a delay based on the deposit threshold of validators so we're gonna let the deposit contract fill up with deposits and once it reaches a certain level then basically the genisis event is going to trigger and that's going to also it's good there's going to be a short delay from when it fills up to when it happens to ensure that clients have enough time to catch up to the chain right so back to that point you made before like right now if somebody I guess right now everything's still in a test net but like once phase zero eats 2.0 is live would you as far as I understand it is not yet right okay but once that's live if you wanted to start

staking you could actually do that or validating rather you could start doing that but would you need to like would you individually need to be running a node on eath one and then do this process or will there be any tools to help like you had if the average user II do this absolutely absolutely it all comes down to kind of your kind of your security and your your personal level of security and kind of what you want how much control you want over the system I assume a lot of average users might just want to see gains on their deposit so they might not care as much about running their full kind of eath node they might not care about running their full even e 2.0 node I imagine you know there will be services that allow you to

kind of run a validator either as a validator as a service or you can connect to some e to node where you can just send kind of signing information or send blocks to and kind of earn rewards so it all comes down to kind of your personal preference of how much you want to trust others versus do everything yourself we imagine that it will be the case that most people will be using these services to just gain gain interests under deposits I think we did in previous episodes touch on the phases maybe we can just cover again what they are so phase zero is the one that's coming up really soon as far as I understand and that's what you're testing right now with your chestnut yeah phase zero is coming up very soon there's attempted of date of

January third 2020 however there's a lot of things I need to happen before that date in particular we care about having a multi-client test right that's the real test that's when we're really gonna know like can this hold up in production the goal is to have that around DEFCON and that's going to be a really exciting time for the etherion community as a whole the next big thing is phase one so what phase one means is that we're going to have shards and we're going to have data on these shards so essentially we're going to partition the chain and to partition the state of etherium into a thousand twenty-four shards where you know these are going to be valid leaders are going to be assigned to validate on particular shards and basically the whole network will have the same

security pool that in particular will not have smart contract functionality so it's only around sharding and setting up the structure of the shards it's mostly a networking problem so being able to make sure that we can efficiently route traffic across the shard make sure validators are participating correctly so but there won't be much change from phase zero right for Phase two that's when the real thing happens and I think that's when we can get closer to saying that we have a real smart contract platform called e2 then you can actually execute smart contracts so that's that's when you can actually run code you can actually modify the state you know kind of send send send ether from one person to another so that's a lot closer to

what we see today and that's that's the face to beyond that there's a lot of other improvements but that's mostly everything that's on the horizon at the moment so just to summarize or to sort of repeat what I think it is from what you've said it's phase zero is like you can validate and you can actually earn some block reward something but you can't like nothing's really happening you're just basically put it in somewhere it's not really securing anything it's just sort of practicing the validation phase one you introduce the shards so then there are actually like this sharded blockchain proof of stake but still you'd only I guess be able to transfer like funds your

gonna necessarily be able to do anything that aetherium can do in terms of some more contracting that's right you won't be able to execute yeah and then phase two is where you start to actually have the full-fledged eath functionality but on this earth 2.0 China that's right so for phase zero we have a spec freeze I think that was 0.8 if I recall correctly was frozen and that means sort of no new features go in but things are still being improved bugs are ironed out whatever but like this is what it's supposed to be how far along are you in implementing this how far along do you see everyone else like the community as

a whole being to implementing this and like you said the true test is the multi client estimate but are there things in that are not in the spec that would actually be a requirement to move to that not having a spec freeze I think was the biggest deterrent to building a production client you know you can't just you can't just commit to long term designs if things are gonna change kind of underneath you so that was I think one of the most exciting days of this here what this means for everyone is that now we have a very solid place to make to you know build our work from and know that it's not going to change in non-trivial manners right now the spec is up to version 0.8.1 and the cool thing is that the

researchers have been putting a lot of focus on these things called conformity tests so essentially they create a bunch of it like very very big test files of just a raw data that we can then run through our clients and make sure that they output the right result so what this means is that we know that you know our team gets the same result as Python research team gets the same result in its lighthouse which is building an arrest and all the other teams so having this is really critical because once we do multi client testing we'll know that if there's a bug it's not because of our core code but it's because of some issue in our runtime or in our client itself right what this means is that yeah essentially we implement the same protocol as lighthouse does or as the eath - research team does that's been a

lot of the focus we are fully compliant with version 0.8.1 which is the latest one we pass all the conformity tests and I know a lot of the other teams are getting very close to that that point as well in terms of things that are not in the spec is networking networking is the biggest kind of elephant in the room there is there's a lot to talk about in terms of compliance and making sure that we can communicate between clients appropriately and have a standard and kind of that comes back to the earlier discussion about how do you how do you make decisions in this decentralized kind of environment where everyone kind of has different languages to tackle and and different clients so it's been it's been quite a journey I think a lot of

the teams are becoming a lot more familiar with working together they're doing a lot of different retreats together you know kind of meeting up in person and there's a lot more collaboration at this point in time so that's been really great and I think at this point there's nothing really holding us back from getting closer to the multi client test net and eventually production I definitely I want to come back to networking later because I mean we've heard that come up in a few different contacts and the challenges around that but before we do that I kind of want to hear a bit more about what it is to be an implementer and to work on a spec like were you guys part of the building of the spec I'm just I'm sort of curious how the research team and you guys worked together before the spec was

frozen and if that's changed now the way we work together before the spec was frozen really it was you know we we were just very careful about the changes we would make we would contribute to bug fixes or suggestions on the specs repo so maybe like maybe somebody and the research site would propose a change and we'd be like hey maybe this might not be very good on the go side it might be pretty tough to implement is there another way and then we go through several rounds of feedback and get that merge then so with mostly collaborate that way we contribute a little bit to the spec but a lot of the research discussions were kind of kind of a kind of a you know we're not as plugged into right so the researchers definitely spent a lot of time on their own kind of

coming up with a lot of the a lot of the decisions and then we retro actively look at them and help out or provide feedback one of the things that they're very interested in is performance so that's the only that's one of the things when we contribute a lot so we're like hey you know we implemented this part of the spec it actually ends up being very and so being very fast so that helps the researchers have a better understanding of how to write how to write the spec moving forward I think mostly they care a lot about kind of coordinating and multi-client testing so we're working a lot in conformity making sure that all the teams are aligned on the same goals and ideas making sure that nobody you know that everyone has their concerns voiced I think that's the role of the researchers at the moment moving forward

and I know if italic in particular has been putting a lot of time on phase one and moving forward right so yeah I mean it's it's a very exciting time ahead I could almost throw the same question at you Frederick what's it like yeah I mean I think we've taken I think an interesting thing in this space is all the implementation teams seem to take a lot of different approaches we've gone much more of the way that role is talking about initially we were very passively just following this back end sometimes even not implementing the spec because we knew it was going to be changed again and just kind of going along and then providing more and more

feedback and we've never like been involved in the research itself it's just I don't I don't know that any team has except maybe the consensus team who actually got like three or four researchers yeah you know I'm working actively only on the research parts I don't know it's interesting to see a lot of these different teams most I would say are just sort of following the research team providing feedback here and there and I'm curious now as well like once the spec is frozen now what what's gonna happen and something like we'll get back to the networking part but something I see there for instance is that it's not something that the research team is all that interested in and so it's it's a little bit more up to

the implementers and then the dynamic shifts a little bit you can't just follow someone yeah that's what we're doing I think a lot of more in-person gatherings and really ironing things out together in particular like you know how do we how do we use existing technology so there's this awesome tool called live p2p from protocol labs you know obviously it's a it's a project that might not fit the exact needs of these two so there have been a lot of complaints regarding like you know like how you know standardization across different languages like right now there's only one go implementation and one rust implementation that's that's like that's in use other teams are building out different implementations in its which is the json' but overall you know we we need to

make sure we collaborate with protocol labs which is an entirely different effort than aetherium to make sure that we can use their tool for e to even coming up with our own entire networking kind of library which is this project called hobbits that's been going around so overall you know we're still exploring options i think i think the teams are a lot more ready to kind of begin taking us seriously and implementing it if necessary I think maybe just to break it down where does this networking happen what does it look like as I mentioned before most of the teams have initially started implementing or using Lib p2p which is the protocol labs library the thing about blue p2p is that it attempts to be this like big one-size-fits-all networking library for a peer-to-peer communications and

obviously that may not go perfectly for something like e to you know there might we've encountered there's a lot of memory usage we've found some bugs that we really in our test net that we believe can we can attribute to like p2p itself so there's a lot of problems from trying to be too general whereas you know there's been discussions about making something that's very easy to specific like the current youth 1.0 kind of implementation it has this thing called def p2p federal knows a lot more about this than I do of course but you know it's been around for a while and it's it's kind of very specific to e - I believe it uses our LP encoding right which is the serialization yeah yeah so so you know there's some talks about okay how can we build something that's

trimmed down specific for e - or should we continue kind of dealing with the kind of the quirks and issues that lead p2p has and fixing those right that's the current point of discussion I mean it goes back to what we were talking about before with the lis Rob stuff and like where do you make your trade-offs and how do you make your trade-offs that would be to be is specific to eighth one and that's been both good and bad means that there's no existing tools for it there's no knowledge about how it works there are so many projects that try to connect to the chain or get get you know scrape information from nodes or do this or that thing and they basically can't and we have all these

really shitty solutions around if they're in for you know doing things because they're not working code is so hard to deal with versus if you add something generic then with with lots of tools available you get all the niceties of that but you get the extra overhead like you were talking about of having something that's too generic so it's really not an easy trade-off to make yeah it seems like one of the paths moving forward would be to just work a lot closer with protocol labs so the team lead for that is rel Kripalani from the lead PAP team he's been extremely awesome just coordinating with the eath two teams making sure he answers questions and actually I think I believe they were working on a grants initiative to help build this collaboration between eath eetu and

protocol labs so they want to just really make this happen and make sure that we can we can leverage the tool and the best way possible I think a lot of the confusion comes from it's all just not knowing what lipids be really is where I know I've talked to a lot of people who have a lot of confusion around thinking that oh this is a specific protocol for doing networking but it's not it's like a meta protocol it's a wrapper around and like protocols in which you can implement multiple protocols and it it enables this sort of upgrading and downgrading and handshaking of establishing hey you know I'm pinging you and I'm asking you what

what protocols do you speak and then you can kind of do this negotiation and come to the conclusion that we both speak they use one protocol and then you speak Keith one protocol with each other after that so you can still implement anything you want but you have to have that initial ICANN Jay King stuff for for it to be Libby to be so it's really just that like meta protocol stuff that's this would be to be so you're not buying into one like one discovery algorithm and then maybe that discovery algorithm doesn't work for you it's not really at that level exactly why wasn't this something that would have been kind of identified by the research team like you know there's you sort of mentioned it's like

once if once the spec was frozen and then you start doing the implementation that's when this problem kind of arises so do you think that the researchers had this idea that this that lib p2p would be some sort of catch-all there I mean I think I think that was how it was initially framed obviously the role of the spec should be very well scoped to just pure research around the consensus and around how easy to should work deep down when it comes with details like networking and implementation details they can make suggestions as to how they think it could be good but I doubt the spec should include any any any any strong information or strong suggestions to implementers about that yeah I was initially framed as that I mean it's it's it's it the project has been in

development for a long time it's I mean the project itself poses itself as a very kind of generic toolkit for a building peer-to-peer communications I would mirror a roles statement here as well but just say as well that like they're I don't think the research team had any idea of what networking would be when they set out to do so like Libby to be wasn't on the horizon I think our first sharding meetup was in February 2017 maybe somewhere around there in Taiwan and let p2p was just being brought up then that's like this is something that exists out there maybe it's worth looking at so yeah it's one

of those things that when you're working on a spec you kind of just go oh this is an implementation detail like it doesn't really matter and right it doesn't really matter to the spec but to the implementers it obviously matters a lot there's nothing that says you have to have cross client network that all nodes can talk to each other it's sort of a weird concept that it's obviously extremely desirable but it's not a requirement for this to actually work especially not an eighth one where you know as long as you can process box another client there's no no reason that you have to appear directly to them so you you could have like bridge nodes

that just relay those box between the two networks then I mean you could come up with all sorts of crazy ideas but but it gets so [ __ ] complicated and weird if you don't say that they all speak the same networking protocol so it's it there's one of those things that it doesn't belong in the spec but everyone needs to agree on the on the same thing just for the sake of sanity that actually kind of flows into this question that that we wanted to talk about which is like the decision-making you'd sort of mentioned this and again going back to that comment about Libra and how decision-making would happen there I mean how are you sort of mentioned that you're doing a lot of retreats and stuff but how are standards

or decisions actually being taken now that the specs are frozen is there still sort of like project lead is there like how is that happening yeah overall I think so you know Danny ryan puts a lot of work to really help coordinate recently proto lamda from the from the e2 research team has been doing a lot of work to help the teams make sure that they're up to speed on the test and the conformity but I mean just because the spec is frozen doesn't mean we can't open issues or we can't open discussions in the specs repo I mean there's still a lot going on in there in particular so I think having this decentralize decision-making and having the different teams give their input is super helpful to us so we were down the rabbit hole of implementing our

serialization library in a specific way and we really disagreed with one aspect of the spec it turns out you know the different teams came in they voiced their opinions and we actually resolved it really well we ended up siding on exciting on their on their argument and really changing our mind on that subject so having these issue threads on github is really how we communicate and getting that across the board we do have the bi-weekly implementer calls but that's mostly for stand-up and making sure you know hey what's everyone working on how everything how's everything going and the researchers give us some insight into their decisions yeah just because it's the spec is frozen I mean we even even then we still have a lot of discussions and still a lot of improvements to make it's also worth reiterating that it's the face

Xero's rosa like phase 1 and 2 or still absolutely unknowns I know do you think because you are actually doing some of the implementation of phase 0 though that is influencing then the phase 1 and phase 2 research is there a lot of kind of cross-pollination going on there so at the moment not really actually I think the phases are pretty well scoped you know I think you know the phase zero I would say is by far the most complex and the one that we really need to get right because it's a foundation for the whole system like if the consensus is broken then you know shards are not gonna work and smart contracts are not gonna work so this is probably the hardest thing that took a lot of work to nail down the rest are are going to be a little bit more open and and and I

wouldn't say the word easier but I would wager would require shorter research cycles to complete I've definitely seen some desire to like involve more of the other phases in phase zero spec and like put in place holders for this or that thing that we expected be coming and I know especially I think yacek from the Status team has tweeted many times and just like been been very aggressive in trying to remove those references to other phases to like keep phase zero effort and keep it to just phase zero right yeah yeah there's a lot of that because you know like mentioning earlier like phase zero it's it's the foundation

and essentially it includes some references to how shards are gonna work but you know like stubs for example like oh right now we're gonna use empty shards to do phase one you know so we have that sort of things those sort of things in place I do agree we should try to keep it more pure it just makes it easier to reason about and easier to verify so yeah one of the comments that I've kind of heard repeatedly actually over the last year maybe like the last six months on Twitter so this is like outside of the actual core teams working on this it's this idea that there are too many implementers there's too many teams too many voices and I wonder what like I'd really almost like to just ask

both of you to give us a sense of what it's really like because do you think there are too many teams or too many voices or is this just sort of a Twitter gossip rumor thing sure so I'd say there are probably on the order of eight to nine teams my answer to the question is that each team has a very different focus and what they're building so for example like the kind of the change safe team building the load start client in JavaScript has more of a focus on browsers and like clients and you know I think that's a very much needed aspect for each to we you know the prism the prism project is targeting more of like the average validator sort of like how you know running a Geth node today would be similar to running a

prison node in the future that's what we that's what we would aim to accomplish lighthouse team has focused a lot on performance and security and you know kind of being a Russ project so every team has really their own angle right and I think they all provide extremely valuable contributions both to the spec and implementation discussions I think we'll really see what happens after a multi-client test net so that's one like really you know like what's gonna happen and who's gonna be which which clients are gonna be the ones used to most and I think that's gonna come down really to people's preferences and how they run and how fast they are how secure they are etc yeah I think it goes back into what are you focusing on and what are you trying to achieve is it too many

teams you know for what for what goal for building the best possible spec in EVE to know like you can't have too many teams is it's the best set up for building something really quickly no absolutely not there are definitely too many teams for building something really quickly but you know what is the goal and I think the everyone working on it and like much some part of the community has a very different idea what the goals are and how to get there then some other parts of the community I think very you know likely it is on the investor side especially larger investors they have

this old mindset of you know we invest in this company and then usually they even have some say or some push in how they work like no you have to make an executive decision here like make this today and then tomorrow you start working on it you can't just dilly-dally around and like research this thing for six months so I think a lot of it boils down to that like what's your goal and like too many or too few is has to relate to that goal and I think there's there was obviously a balance you don't want to be on either end but it's certainly not like we're not at the end of like oh there's so many teams that we're not going to get in it sounded like what from what you guys are saying to that it

would like as the phases as it progresses that there will be kind of a pooling of talent around certain clients like do you just imagine that some of these clients will just sort of decide not to do their own implementation but rather just join another one I mean I imagine there's repetition of languages and stuff happening here well I think we have to keep in mind that there's no incentive for actually building any of these things and so at the end of the day when you're there and you're launching a client if it's not being used why would you keep working yes but would you then join another one like could you see these teams just sort of join together I wouldn't see them merging code bases but your are like the

team itself might move to someone to some other client yeah I mean I I would hope that that would be the case in that they want to continue their work and their passion in some other place but who knows it's like the motivation behind a lot of these teams is completely foreign to me I don't know why they're doing what they're doing I think it's cool that they're doing it but I don't know why I have a question about each 2.0 in it if you look at the polka dot network there's something called substrate which allows you to like develop these pair of chains really quickly so far I haven't really heard about an eighth 2.0 substrate equivalent like would you are there going to be that is there a need to have a way to build shards yeah so any 2.0 shards are

actually homogeneous so they're all pretty much exactly the same from the protocol standpoint I mean there's no like one shard is going to be halves have some sort of different have some sort of different logic or different things one of the things that is that I would say is akin to that is these things called execution environments so this is getting into Phase two right so a lot of the questions are like hey how are smart Contras going to work how is code actually going to happen on eath on ES 2.0 and there's been this talk about these things called threads or execution environments the basic idea is that you can write up you can you can basically code up this kind of think about kind of like an operating environment operating system where has it has its own specific

rules and its own specific constraints where you can develop programs on so for example you can formalize all of f 1.0 as an execution environment and we can deploy that on the Istana me to shard so I know that's like very meta and very very high level but think about it like for example on e2 we're going to be able to kind of specify the entire eath 1.0 block chain and run that as an execution environment you can maybe specify the entire Bitcoin you TXO model and specify that executed execution environment and every time you deploy a contract you deploy it to one of these specific execution environments where then they run their logic accordingly - according to the rules and the gas costs and etc of their system so that's the general idea we want to make it pretty general

we want to make it so that it can support all types of use cases yep do this do those threads actually exist over multiple shards or on one shard so the threads are actually going to be deployed their code is going to be deployed on the beacon chain which is that you can think about it as the coordinator or root shard in a sense and essentially shards will then you know shards are all homogeneous the only recent shards exist is for data availability and for partitions so that's essentially where account data and transaction data and information will go into but essentially they're all going to be running the code from the execution environment code from the beacon chain so back to that question will there be like a substrate or a builder of some sort I think there will

have to be but I think substrate is blockchain building framework and it it also has framework and a set of tools and libraries for writing runtimes but it like substrate as a whole is like networking and data and consensus and all these other things but that's what all of these different teams are already building I mean we're also building a neath - on top of substrate and word like so we get all the basics from substrate but then the runtime itself is where he lives yeah but in in DC and likeif - runtimes they deploy to shards they will need some sort of framework or some sort of tooling I'm like how you how you build

them and like this is all super early so I don't know if anyone has actually started looking at how to build them and know what it is saying what I've seen from the II wasn't team who works a lot on this is just hand written web assembly code and like there will be languages and tools and like frameworks and all this stuff to build that as well so I think the SDK you know world of eath - is more around how how you build these runtimes but not at a whole chain because you would never need to do that right and the shards are all gonna be the same for a protocol standpoint so there's no need to make like you know like implement different shards in different ways I see I wanted to go back to hear a little bit

more about what you guys are up to it what what is prismatic labs today prismatic labs today actually last time we spoke we actually were still working on it at a mostly at a part-time capacity now we have most of the team on a full-time capacity and we have four full-time folks and two part-time folks I'm a long side all of our other open-source contributors so prismatic labs aims to be you know kind of leading implementer for a major client for e to pono we want to continue supporting the community our goal is to take this to production deploy it to the real world and beyond that continue supporting the whole aetherium effort right we I mean we're not gonna stop until kind of Phase two and the future is out and beyond that we're still gonna be building

things on top of - I think eventually you know it will be really robust to build scalable applications and we might even transition into an application side team at that point at the moment we just really want to get this out to the world and make it happen and that's that's actually sort of another question I had which is like back when we spoke you last year you had received this grant how are you funding yourselves today yeah we've been we've been very generally generally supported by the etherion Foundation grant program alongside other grants currently we have enough run time kind of to make it to production and ideally we want to scale the team even more so as time goes on hopefully we can you know either receive

more grants and scale a team even even higher yeah so that's that's essentially our focus at the moment we're fortunately not distracted by kind of a kind of kind of other kind of revenue revenue opportunities at the moment we have enough to sustain ourselves and build this out so were you guys were you guys one of the people who received one of the vitalik grants some reason I thought that went straight to Preston but I'm sure it went to our multi-sig wallets so it was a few folks that received that I think it was just like very very very very cool very unexpected but yeah do you have a like you kind of

mention a little bit you're you're looking to the future but are you guys thinking about that because you know we took we've talked about this throughout many episodes over though a year about being dependent on grants or donations or what have you but that's not a business model in a way that's not sustainable so I mean I know that right now might not be the time you have to think about it but like have you started to think of any sort of business model or anyway yeah to continue we have actually it turns out that a lot of the opportunities that come along actually for us in particular are past the production release of phase zero and maybe starting on phase one there are revenue opportunities once that that's in main net so we have been thinking about that I think we'll be able to just really dedicate more time

to that post a production release cool so yeah I think there are opportunities we do ideally want to stick around the e to world and want to want to just keep contributing heavily to aetherium and find opportunities there like I said I mean eventually will might even build on the application side of e to one smart contracts realized when I'm gonna ask the question that's I'm sure you don't have an answer to but I'm gonna ask anyway when when eath 2.0 winey 2.0 yeah I'll give you the I'll give you the Canada what I think is it is gonna happen is so we're gonna have a multi-client test not by DEFCON I think the generator date might be a little bit too ambitious to be honest we're gonna need a lot of testing around

a multi-client test night like we're gonna have to find a lot of bugs fix a lot of things optimize things build out some tooling before main that I'm sure there's gonna be neat to be a lot more standardization of the cryptography which is BLS that we use for you know hardware manufacturers and hardware wallet manufacturers to be able to build that out I'm sure people will need those things before they can really steak especially institutions right so you know I think everything should be ready to go by a q1 of this upcoming year don't know exactly 1 in Q 1 it will release but there is a lot to be done in between so yeah but that's phases 0 right that's Phase II yeah that's right phase 1 the idea i believe the research team wants to actually spec freeze phase 1 by

the end of this year what that means is that at that point you know the phase 1 implementation effort can go full force in parallel with the release of production phase 0 I imagine that phase 2 will likely be spec frozen by q1 or end of q1 of next year so I think I think next year is gonna be a really big year for production releases we might see phase 1 production release next year we might see face to production release early 2021 these are just kind of kind of guesses based on our previous work and experiences so then well thank you so much for coming on the podcast again yeah thank you Anna Frederik it's been a pleasure thank you very much and to our listeners thanks for listening thanks with me

you [Music]