Phase2 Update from Quilt

Transcript

good morning everyone start in one second okay cool

so I'm gonna go ahead and just give a update on what's been happening in phase two from various teams but this is from cold side slides will be on Twitter afterwards I'll post them WJ bill and in general I'm going to assume through a lot of content here it this is supposed to just give a really big and quick overview it might take a little longer than 20 minutes twenty-five and the goal is to give you guys a lot of resources and links to particularly look at at some of these things that you might be interested in that you hear me cover and

zoom through I'm going to go really really fast through a lot of more dense technical material but finds me or anyone from he was in quilt if to research team of youth questions so cool so quote we are part of Rd under consensus we've been collaborating specifically around Phase two with various teams teams on that have been that it's research team Yas and team and now also tix rx which is a new team we're particularly focused around research around eat to Phase two so really quickly I'm just gonna breeze through this one minute so there was a

proposal around execution environments from victaulic that came out the basic ideas in a theory I'm if you're reducing a bunch of transactions it's that basic reducing function you have state that's mutated if you make a stateless then it's a pure region stream function so you have a state hatch that goes to a new state hash and the original idea behind this this is somewhat evolved but the original idea behind this is the beacon chain held different execution environments reducing scripts that on the shards defined different account models things like one as an execution environment UT EXO model a improve eat one or two account model and this is

kind of the you know some of the original ideas but engineering progress up to Devcon some things that happened we had built a fork of lighthouse which is a two client done by Sigma prime that built a POC on phase one we had a basic execution environment running some blossom reducing functions as well we had done a we've done a execution environment called sheath which worked on sparse Merkle tree to do transfers and we gave a overview actually around Devcon which even update on phase two progress so there's a lot of dense material there

the eazy-e wasn't team did a lot of research on different accumulator formats as well so there is turbo token and smtp merkel ste token they also did a zk roll-up demonstration as well one of the interesting things is the c Markel token showed to have promising performance and the others were slow turbo token should also have some promising performance as well in the initial and the initial prototypes and then there was also workaround wasn't basically adding host functionality into into the system to allow for waz 'm to call into other wasum scripts this is similar to the call or delegate call

opcode and eath and so and then just a number of other experiments sample repos quote quote repos and then also you can look at Yas and repose was a bunch of bunch of different cool things that were added so at dev constant things that kind of came up and we realized is e communication was fairly difficult so for ease to send each other e as an example you would need to go through the beacon chain and I this you know adds loads beacon chain is fairly slow cross your communication would take an entire epoch six minutes also seemed bit slow and building the eighth one execution

environment seemed to be a bigger effort than we originally force all there were also other ways at the time that we had looked at possibly speeding up that cross guard communication so we kind of looked at this optimistic system with dependency graphs that could roll back you can prune off the different branches of the graph different things like that this seemed to have some complexity involved some state issues and some other things and then there was also some questions around significant centralization censorship risks in the relay market design so actually link to research posts on all these that that reference this so results from DEFCON

Vitalik actually released a new proposal at sort of at the end of DEFCON that it's the is the reduction of shards proposal I linked to here and it brought a number of interesting benefits and solve some of these problems so one of them is it reduced the cross guard communication to one slot one beacon slot so twelve seconds it opened up a good path to reduce some of the censorship issues that we saw from from real ayres in the real layered design that we had before and it also seemed to start simplifying some of the ways we might communicate between E's and in that paper there's a whole section which

is talks about the operating system and so this was the beginning of thinking about moving eath balances on to shards and so this opened up a whole new set of discussions so after DEFCON I wouldn't say it was officially delayed or push forward but there was another proposal that which was pushed forward instead of building an eighth one execution environment it was instead moving eath one into the POS the previous take world at Leith - and reserving a shard particularly for each one to run on and so in this world eath one would need to go stateless and if you wanted to be a block composer on one shard you would

sign up as having special capabilities and you would therefore be running a one client and so then around this time the eath 1x group had formed a stateless group and set up a road map to begin to you know work on witness aggregation collection propagation as we as we transform eighth one to make it stateless and perform it and also update the various tree formats that are used initial role results seemed quite positive and they've been giving a lot of updates and then quite productive so continued research into the new year so one of the things that we found was in the eath two world we had some issues

that had to do with the state provider network you know getting witnesses to your transactions that the eath 1x effort wasn't having to look at right away and this is in particular the the constraint here was an eighth one minors old state so when they get transactions they can attach the witnesses attach the proofs that they need in a stateless world but in if two miners or block producers and validators don't are not assumed to have state so this somewhat added complexity to the model and so as a result we absolutely released a research paper that talked about some of

the remaining questions and then on cigar and sam i think on scar and stammered here yep on scar Sam released a really good write-up around stuck state access dynamic state access and different state provider models so definitely encourage people to look through this and look through some links around this so we kind of came to three recommended models one we call the direct push the real a push and a pull and to give again you know I giving a overview here and not going to go in too much depth but to give a quick overview the direct push model seem to be this slide went out cool I don't know if I touched one of the

cables the abandon ship okay yeah it looks like it's the screen or they set

up here technical difficulties nice still going I try disconnecting I can tell a joke I know any would

Robert you know good jokes recommend you yeah it's it's not the connector I could take questions I could just talk without slides as well that's helpful any any questions in the meantime hello

new state providers and the system was very scary now is the exact word you know repeated many times even as I kind of talk about you know how it's a network and people can join and other things what what are your takes on you know our state provider scary or they good thing I think they're a good thing I think they're interesting I think we're taking there's a first step diving into this in a production environment with the eath 1.x work and moving that into a stateless format so I think we're gonna get in very you know early if you into that is that connecting yeah so I think we'll get an

early view into that I think from an e2 perspective I generally think it makes sense it's a good way to kind of partition the state amongst different parties in the network and generally seems like a good pattern for that doesn't I you know the entire global state to just one shard you can have different parties that are holding different parts of the state on on a shard or on multiple different charts as an example yeah yeah that's that's makes sense I mean I think the the where that sort of fear came from was the fear that

stay providers would somehow introduce a new centralization attack vector you know for censorship and so forth yeah I think one of the ideas is if you can always sink to the chain and look at the witnesses that were formed you can kind of reconstruct the state that you're interested in so there's that yeah become yeah that's a really good point becoming a state provider is like becoming a full no today you basically just have to sync the state and then you're a state provider so yeah but if we achieve scaling isn't it necessarily

harder right because you have so much more state so for example if we 2x the throughput then it's twice as hard to become to provide the full state so it's to say it's just like being a full note now that's very I run full notes it's difficult it's not easy yeah I think what's what's interesting there is it depends what state you want to form so if you're a user and you're particularly wanting to use you know one particular application you can kind of track the state associated with that the witnesses that were uploaded yeah and that goes to my actual question and not just snarky comments has there been any

consideration for how users will store state locally that they're interested in I just yeah I think different basically if you have a different wallet provider that you might work with there could be options one to store parts of that state in your local storage but that can't be like a reliable long-term method because that can always be lost or cleared but it seems like a good way to be able to cache that for yourself as an example yeah and last question and then it has has there been any looking into how that model is similar to the like Watchtower

model from a payment channel or a state channel so I would say it's a bit different because the Watchtower model you basically have someone out there making sure funds aren't being stolen from you in this case it's not like the witness just disappear have the credit meant you you submit a commitment to them and then they're obligated to hold that commitment and in this case instead of them holding the commitment they would hold whatever state you pushed up to them so my my understanding so there might be some similarities or some analogs my understanding the Watchtower general issue correct me if I'm wrong has to do with the fact that when you

have various like exit games and periods of time you need to make sure someone's watching your state to make sure that someone's not trying to exit with something that you hold claim to I think that's that's been my general understanding of that yeah that's the problem with synchronization of the app right so if you're offline and you have paid someone to track an app for you they it's not it's they're not you know they could be potentially making sure funds aren't stolen or it's it's equivalent yeah so I think in general again it depends on the construction that you have but if there's a double spend or something like that that would be a consensus issue and so you imagine that there are any and number of notes that are following that

particular chart and can see that that's a consensus issue and I I believe there's a few additional security guarantees coming in the protocol as well which would be fraud proofs at some point but yeah thanks sure maybe this screen will start working when I would do a transaction whose was responsible for submitting this state to every verifying all right so this is about what I was about to talk about with the diagram so there's these three models and so there's the

direct push real a push and pull ID some pretty cool diagrams to go with it the one that we recommend that seems to provide the most simplicity and design is the direct push model and in particular the direct push model that the user is responsible for their witness generally and so what I have would I have a transaction that I need to sign you know I would reach out to some party a state provider or if I own my own state and that's that's fine I can use that you till transaction and so if the

transaction tries to touch a particular piece of state that that I don't point out in this access list then I'm attributed to that fault as a user and so that's that's the direct push model the other models that we've had our pull model and relay push the pulled model in particular puts the burden on the block producer so the block producer gets a bunch of transactions and then it's up to them to find some type of state provider to then bundle and attach the witnesses for them there's some complexity there because they need to understand how to order that properly so we generally recommend this direct push

model one of the one of the things that the direct push model would require that's different than eath one is eath one follows this pattern called dynamic state access and basically a good example of this is when you can't deterministically stay say which state access location you're going to touch so a simple example might be you don't know what the next block hash is going to be so if you have some type of transaction that is dependent on what that block hash is going to be and based on that block hash it may access a different part of state that would be an example of dynamic state access and so one of

the things that in this direct push model which seems to you know produce a much simpler system that we've looked at is changing this and we're not set on this term changing this to what we call static state access predictable state access on Skaar likes there's a few other a few other terms and so this this goes along with an access list and this means you can't dynamically touch touch State but through our research that we've shown we've shown that actually upgrading existing existing contracts so we started off with idec's units

what so two unchained axes making updates to SSA looks like there would not be that many changes we need to continue to look at research for other other sets of contracts like maker things that are a little bit more complex but it does seem like all the patterns that we have today we could continue on they may just require some different developer patterns and so one of the things that we did to look into that as well as Sam actually extended the solidity compiler and to you'll to do what we call taint analysis and what this does is it actually looks through

the code that you might write in solidity to make to make sure that you're not using dynamic state access patterns that way there can be some developer tooling to let you know if you if you are using these patterns as an example and so yeah that was a really really long answer but I was gonna cover this with really cool pictures but if you guys just came into the room the like one third through my presentation that the screens not working so I'm just doing Q&A now so if you have any phase 2 questions feel free and like all of us are answering so how many different execution environments do you see say

like you know at first and and then like over time what do you see is like an upper bound er yeah so I wrote an eighth research post recently which was a way for I forget the title way forward with phase two I was kind of the culmination of a lot of I guess our work talking with some of the other teams that are working on phase two as well and the general direction is that we want to support so we want to make decisions that look forward to this world where there might be multiple execution environments so things like a direct push model right things like having static state access other decisions that

seem to be decisions that give us longevity but starting off by really focusing on one main execution environment as a design trying to trying to make that really strong and then once we get that in place then you know we can we want to continue to play with more execution environments and so one of the trickiest things and I was going to talk about this as well when we look at you know how execution environments fit into this as a whole is how do they communicate with each other properly and actually if we it seems that if we move forward on static state access or predictable state access it makes that communication

drastically simpler and could reduce scope and there's some really cool things so it seems again never wanted to terminus Calise something but it seems from our early research that execution environments would be able to call into each other directly on the same shard synchronously whether that's the pattern we want or we don't want I'm not sure but it seems like a pretty interesting feature one of the reasons why I think this is interesting is like it can help with a good migration path so if you're you know want to upgrade to a new accumulator format a new I don't know governance model rent format whatever

else you can launch that and old contracts would be able to from old execution environments interact with new contracts from older execution environments if it works out in this in this way and there could be even interesting ways where contracts have their own governance and they could upgrade themselves into a different different execution environment as well but that being said we realize you know as far as scope it's good to focus on one for now get that get that really solid and then expand expand the domain while still making decisions that give us long like longevity so cool thanks

yeah any other questions nice anyone else's like italics and anyone can answer questions too but yeah um hi what is actually the most recent or most up-to-date source to if if one wants to dig into the topic and does some reading or what or what you were I recommend looking into the code from Europe for example at the moment I'm at your simulation on github would this be a good entry point so what is the best entry point for reading so best education entry point for reading I think go through that III search post

and that links to pretty much everything so that's the way forward and post yeah I gave a history as well I think that that could be helpful I think also proto has been has a work-in-progress back for phase 2 as well which is really cool and yes I think both of those would be good good starting points and then those can kind of take you down the rabbit hole okay it's a simulation Rea pool already executable or testable yeah so that's that's in progress there's a PR that's going to be merged in soon bi as of now you can you can run basic execution

scripts on it cool we've had various iterations of that too so as I said at one point we had a fork of lighthouse that did this one of the reasons we moved out of the fork of like lighthouse is just how rapidly changing the phase one and Phase II respect were and so there's going to be hard and also how quickly they move so it's it's hard to you know rebase all these changes in versus just abstract a lot of those pieces and that was that was the motivation for moving towards this simulation repo so yeah no questions isn't SSA just required to sort of I mean isn't it sort of just like an S

injustice peeking an improvement over the existing EVM model and is there any interest in just applying that to eath one as a technique so it'd be interesting to apply that to ether Wan there'd have to be like a slow migration pattern because contracts right now use SSA in general so you could you know you could say five years from now you know SSA transactions will no longer you know like now you have to use access lists for eighth one as an example so but I don't think you could just turn it off right away I don't know do you have an

alternate opinion so right now contracts Neath one are built using dynamic State access it's not something that's been considered when writing contracts and SSA is taking away a feature from the perspective of def developers so contracts that currently run wouldn't be able to read anymore so as what was saying you'd have to slowly migrate over contracts would have to be rewritten and then there'd be a date at which you could remove DSA from eath one but I think the timeline you'd have to do that on is probably in line with waiting for e to anyways so I don't think there's that much point in doing it but that's just my opinion thank you um I had another question

related to that oh yeah I mean couldn't it just be like I mean aren't those how many I don't quite understand exactly what qualifies is DSA so I don't know how difficult it would be to restrict that within solidity right like if you upgrade its solidity like what functions would a developer lose so if you stick around for the next presentation here I have a small talk about it some work I've been doing in the solidity compiler but it's not impossible to detect DSA in solidity but it is everywhere because no one's been paying attention for it so you can't just pour contracts without

modification so if you want to know more stick around thank you later yeah also sorry you're asking the different repos playing around with see I think he was a Marty that's in there which is a wrapper around scout the I'm forgetting what's the name math Johnny YZ I think might be better entry points this plugin those will ultimately plug into simulation but yeah so cool sheath is an old interesting one but it's I feel like it's easy to read good job Matthew Garnett yeah so one thing that's

interesting so something that quote is particularly doing we're shifting our focus so we've been fairly research heavy over the last few months just because there were blocking research questions that we had but most of those blockers are out of the way so there's still many research questions as we implement but we're shifting more towards them implement implementation heavy approach at this point so we're kind of evolving into a new stage now which is cool it's just kind of cool to see the progression from all these research questions and now we have you know good road map and plan Ford which is which is sweet I don't know I wish I

could have given you guys the full presentation but hopefully the QA was helpful and maybe looks like the screen still not working so good luck Gigi on the next presentations in here I think that's shall Wayne that being said I I could take more questions unless I want to transition this over to proto and Xiao Wei sounds good I'll keep taking questions any other questions all your phase 2 questions let's see I'm gonna go through my slides

and see if there is anything the questions were good you guys actually covered a lot of the points it's just I had like really really good cool pictures and diagrams you know I spent a lot of time on and links like I said all all post these on my Twitter so it's wjv I ll and there's the ton of links most of them like yeah a lot of github and III search links in general yeah a general question here yeah I'm wondering what was the long-term benefit

of having multiple different types of execution environments sorry long term benefit of what of different types of execution environments ah so the thing that I think is is interesting about this space is so in the post that I put up I put like a bunch of a bunch of different points but one of the one of the ones that I think is interesting is if we want to for example we find a new accumulator format that we want to use or we want to use a completely different account model where we want to introduce some type of you TXO format on to this like you know core like protocol

layer what's cool about this world of execution environments is you can do that with minimal overhead this is you out of this room that have access to a

really strong cook crypto economic consensus system and then have total freedom at execution layer do whatever they want some people would say well you kind of have that with youth one already you can create an Ori that does whatever you want as well for execution systems but II to provides a really nice difference from that because in our use you do have to have some kind of exit game and so forth in order to you know give it security unless you have all the data available on chain you ready okay came India and diagram

something Mehdi give us a sigma prime update I'll be giving a talk on White House on Thursday afternoon so you guys welcome to come with that but uh yeah I've been busy on scar you can talk about the Eunice swap updates you did you gonna swap updates he did yes maybe that's interesting yeah hi everyone just so basically part of the SSA feasibility study that we did was look at a few

popular contracts and see how well you could put them to SSA and Eunice what was the first one so I said right now on our impression is that actually all major projects right now life--only theorem could just work on SSA as well but specifically for Eunice work because it's really just like two two contracts we basically mall astroturf SSA version of that and so that really would work without any issues and so that's encouraging to see so that's why we actually are rather comfortable going down the SSA Road yeah that's that's that high if i if i am new to aetherium and i really want to do is to work how

do I go about doing that well it's like the best way to jump in ooh what part are you most interested in there's it's such a huge design space right curious so we're working we're actually working on a we should release it soon we've been working on a book so that makes the east to landscape accessible starts off by covering phase zero and a lot so I think that would and it being a good resource but that's not there yet I think reading through the specs is interesting I don't know just do people have other recommendations that they're

into specs you batalik I also wrote this document called the Serenity research compendium that I update once every couple of months I think if you just search there was words on your favorite search engine you'll find it pretty easily serenity research compendium and I think more and more researchers are gonna be coming out so that should be helpful any cool things you want to talk about proto there's always more things to talk about except with you don't like the working

screen yes so we can try and do more questions or I could try and give my talk without slides it should be exciting that's helpful and yeah we just scream good it gets working one more question okay I'm you can since there are no technical questions about the eat faces

that have been asked I'm interested in if we have it's it's early it just happened yesterday but do we have any learning you you oh okay

does everyone's does everyone see the whiteboard who's here thanks to faceless happy face a grittier thinks that face is sad okay that's good enough so well what I wanted to go through is and if specifically if one at each one X 2 e to kind of transition roadmap ends in particular amount of what the March would vibrate so just as a quick background and if the currents sofort for the youth to roadmap we