#274 Alexey Akhunov: Ethereum 1.x – BUIDLing Things One Step at a Time

Transcript

[Music] this episode of epicenter is brought to you by Microsoft Azure do you have an idea for a blockchain at but are worried about the time and costs it will take to develop the new Azure blockchain dev kit is a free download that brings together the tools you need to get your first app running in less than 30 minutes learn more at aka OMS slash epicenter hi welcome to the epicenter my name is sebastian Cuchillo

and my name is Radhika and so a bit of housekeeping we are going to be at the HCC in Paris at least I'll be there other posts might be there not quite sure yet so HCC is happening between March 4th and March 10th actually that's the blockchain week HTC is actually happening between the 5th and the 7th with those a whole bunch of things happening that week in Paris hackathons and side events and meetups and such it's it's apparently gonna be a huge event the organizers have told me that they're expecting up to 1500 people and there are 300 speakers that are scheduled to speak so it should be really amazing if you haven't got your

tickets yet I really encourage you to do so they're actually quite affordable and should be a great event and we will be having a meet-up at BCC it'll be on the Wednesday so that's Wednesday March 6th the venue we don't have the venue yet but we are taking signups for the Meetup on our Eventbrite page so if you go to epicenter dot rocks slash ECC let's epicenter dot rocks /et HCC at least you can sign up there get RSVP'd for the event and it will send the location as soon as we have it so looking forward to seeing you in Paris and so today our guest is Alexey agranov Alexei is an independent researcher works on

aetherium and works on different projects with the eutherian foundation and so we talked about a couple different things primarily you know we talked about so the roadmap for a theory 'm what is known as the theorem 1 point X and how it relates to a theorem 2.0 serenity and also talked about his work on a project called turbo gas and so it's a really interesting conversation because it got it really allowed us to see sort of where the etherium roadmap or how the etherium roadmap actually had evolved since Def Con with this new point release called theorem 1 point X with them a theorem 2 looming so

prominently on the horizon it's often easy to forget that theorem 1 is actually going to be here for some while longer and it's it's necessary and totally worthy of people's time to actually make improvements upon that and we talked with Alexei about what he's doing in that field and how it's going alright so without further delay here's interview with Alexei enough hi we're here with annex a Aquin of today Alexei is an e theorem researcher um hi Lexi let you cut you with us hello it's good to be here fantastic um Alexei let's let's let's jump right in um can you can you tell us

what your background is and what you're currently concerning yourself with yeah so I've always been so since I was very young age I was always doing programming I guess that was my profession all my life so I wrote my first computer gaming basic when I was 12 years old and my brother helped me to debug it because I didn't know how to debug things and then it led to me bones university study computer science in programming and then I did PhD in neuroscience and then I worked multiple places and it was always programming so I learned a bunch of programming

languages and eventually I learned about the cryptocurrencies in 2012 from my colleague at work and we started to have a kind of lunchtime conversations and at first I didn't actually understand and so it took quite a few attempts for here for this guy to explain to cognitive to make me understand what it is and then I started to research a theorem when I was thinking about the centralized storage and the reason I thought about it is that you probably heard about the idea about the the mesh the mesh networks or Commission at internet and so one of the colleagues at work so that well we

should have this mesh internet instead of internet providers but then I said well how are you gonna do the search like because the search requires storage and so you need data storage so I started looking into things eventually I found these here in white paper I looked at it and I thought that it would still not solve the storage problem but it's interesting on its own right so since then I started following it cerium and into that in 2017 in June I so I went full time and working on these projects mostly related to a theorem but sometimes I did some other things and at the moment I am mostly working on this is a 1x project which which is about ensuring the longevity of existing

ethereal Network so this is my current thing oh and I forgot that I was doing the trooper guest most of the last year it's my kind of my version of the serum client cool so maybe that's just let's jump right in with trouble gasps so I know you've talked about this this on many occasions so it gets us one of the mainly Theorem clients and turbo gas is some sort of improvement on it right well yes in certain ways it is not currently functionally superseding it but my goal is to get you to be functionally superseding me yes so

someone of some of the issues that you saw in gas that you felt you could improve upon and ultimately led you to start building turbo gas so it's so the way it started is that I simply did a profiling so in guess it's inserting in a go in go language there's a very good tool kit for for profiling so I it was very easy for me to just run some guests ink on profiler and to see where it spends most of its time so I saw that the lots of time was spent in going into the database and then I started digging deeper and I realized that Wow each go each access to the state actually needs

multiple accesses to the databases so I thought well this is really weird so I found this was kind of not how I expected it to be and then digging deeper I wanted to fix that part so I wanted essentially or so that each access to the theorem state takes one hit of the database and no more and that was kind of defining goal of this and then it it sort of turned out to be a quite a deep rabbit hole which took me a year to to explore how much better does turbo gas fare compared to gas so it mostly so at the

moment it's better in two areas I think so it might be on par or maybe slightly worse than others so it's better in terms of be compactness of state history so is if you let's say run an archive node which is the node where you have the entire history of state expanded not in the blocks but expanded meaning that you can access it really fast so I haven't run the get archive note for a while but the last time I did it him in summer it was about one point five terabytes on a disk so that is a expanded state in Tilburg if however currently the expanded state in our card

node is about 360 gigabytes so which is which is a big difference and this is the one thing and the second thing is the the actual speed of access so when you want to run some data analytics you want to retrace transactions from the past the true baguette is definitely like I don't know probably 2 up to 250 times faster so that's why I can do data analysis on it that I wouldn't be able to do on gif so if for example for my recent project I can retrace all transaction to gather that's a number of s stores in a block in about two days on my so to trace all the transactions in

all seven million blocks imagine if I had if I had to do it with guess it would probably take me like say 50 times longer so it would take me like half a year which is you see it's moving becomes impractical what have you actually implemented in order to actually facilitate these improvements so I essentially I changed the the way that the theorem client represents its state on in a database and that's the main difference and the is the most of the clients that exist now and I think probably all of them acceptor we get they store the state as the what they call try or miracle

Patricia tree which is essentially a a tree which for each node has at most sixteen children and and the property of this tree is that if you want to read or write or certain entry you have to start from the root and go down the tree and the deeper is your entry the more hopes down and treat you you're doing and another important bit about this hoping is that you cannot do next hope before you did the previous one so there's a data dependency so this is actually what was initial thing that observed so because of the data dependencies you could not do these things in parallel

you have to hope from the root down to the leaves interpret yet I decoupled the state storage from the determined from this patricia tree so I realized that the only reason why you need a patricia tree is to is to compute the state route but you can store the data as you like and I like to store the data in a flat format where you have a key is the hash of the address and the value is the serialized value so it means that it when you want to access a certain item in the state you just need one query to the database just one and that makes most of things much faster so what are some of the trade-offs in using because I mean it seems to me like

this is of course new we would want this and we won't want all the theorem clients to adopt like these similar improvements there there must be at some point some trade-offs are there not in in order for someone to still want to use the regular get client yes at the moment that there are some things that are that are not supported in surrogate which are working and guests but I think they will all be superseded so one of the things that I can not do interpret yet is what they called fast sink and the fast sink is the way of sort of joining a theorem network where you

where you download the current state starting from the root and then just rebuilding the Merkel tree and this particular way of thinking requires a certain query which gives you the hash of the node in the Patricia tree and then you're supposed to answer with the serialization of this node because table again doesn't store this Patricia tree at all it has no way of responding to this query so it doesn't know where this particular hash lives on that on which part of the tree in which part of the history up until recently I thought this is gonna be a big challenge but after the workshop that we've done recently

I've discovered that it might actually not be a problem so we're gonna develop the new sink mechanism which will actually be more efficient with your baguette then when get because it has the flat structure so I think in the future in a near future true baguette will fully functional superseded yes before if I have enough time to do this just just to sort of understand the the context in which your willingness your you're building this by yourself or are you working in collaboration with the etherium foundation anyway so I wasn't a great turbo gettin together well I wasn't I didn't think about in corporate

in corporation yet I did started as my own project and then then I received a grant from a Tyrian foundation for in 2018 and then I had some support from in fewer because the for them it would be beneficial to reduce the storage requirements and potentially run there's the nodes on a cheaper hardware but because it's not functionally superseding it it's it hasn't happened so I don't know whether this is gonna replace gas or not I think I will leave it this decision up to the goethe room team I never tried to force it through or and I also didn't have time and resources to actually try to port my

changes into the Goya theorem and I I was very explicit about it with the goethe room team and they find what that they they understand that I'm also under constraints just to clarify can you can you just quickly talk about what the current state of travel grass is so is is it life can people down over campus yes it is a which is life the current version does not really have the kind of the construction of petersburg fork in it it hasn't done a story base so it is currently rebased up to the state of goiás theorem which existed in somewhere in January I think end of January and you could currently download it you can do the full sync so this is the only

thing that supports if you have to start from Genesis and you apply the blocks if you have a decent machine it will take you probably two weeks to do that and you will end up with the file which is like 360 gigabytes and then you can do your PC queries you can process the blocks and some of these are PC queries are much faster some of it up slightly slower but yeah it is working I haven't tested all the RPC queries but generally it works the light client is not a not supported and some shots Inc doesn't work but this could be fixed so yes it's it's an in Fuhrer also also managed to sync it some time ago so it's

sort of why it had some independent verification that it's actually not just a figment of my imagination so are you going to drive it forward or is this going to it to become a thing for the e theorem foundation to awesome because maintaining I mean this is a lot of work yes so I'm going to drive it forward and that's why I and because another there is another application for the super gas I am also working with the interchange foundation because they are very interested in using two baguette is the kind of engine for the either mint project and at the moment I'm figuring out how to to merge this flat structure

that I haven't to begin with they're a veal bones trees and I think I found a way to do it and my my idea is to abstract to to modular eyes rather the code so that I can use it for both a Syrian client and for either mint client so there is definitely appetite for it and as I said earlier in fewer is very interested in actually using it to forgive and I also now discovered that the the biggest use case for me and hopefully for other people is use it as a data analytics source because as I said it's much more viable to do data analytics with the turbo gift and with any other client at the moment and that

potentially could be useful for companies like Google too because they're really looking into this analytics in the cloud using that theorem data and not just for Google but and for any videos [Music] this episode of epicenter is brought to you by Microsoft and the azure blockchain workbench getting your block team from the whiteboard to production can be a big undertaking and something as simple as connecting your blockchain to IOT devices or existing ERP systems is a project in itself well the folks at Microsoft have you covered you already know about the Azure blockchain workbench and how easy it makes bootstrapping your blockchain network pre-configured with all the cloud services you need for your enterprise app their new development kit is the IFTTT for blockchains suppose you want

to collect data from someone in a remote location via SMS and half that data package in a transaction for your hyper ledger fabric blockchain the development kit allows you to build this integration in just a few steps in a simple drag-and-drop interface here's another great example perhaps you're an institution working with etherium and rely on csv files sent by email one click in the dev kit and you can parse these files and have the data embed it in transactions whatever you're working with the dev kit can read transform and act on the data to learn more and to build your first application in less than 30 minutes visit AKA OMS slash epicenter and be sure to follow them on twitter at MSFT blockchain we'd like to thank Microsoft

and Azure for their support of epicenter so I was just gonna mention Google and the work that that they're doing so we had Island Day on a few months ago who's an engineer at Google and who's sort of leading the project to bring a different blockchains like Bitcoin in theory 'm into google cloud so that you can effectively query the blockchain and do data analytics in a very simple query language and so what are the applications there and how could turbo guess be beneficial I mean because I presume when Google x' got these really incredible machines and they don't really have like computing power is not really an issue for them how is turbo gas beneficial in this case well I mean

obviously if they don't care how much it costs to run these analytics then I this there's nothing for me to offer but if you do care about the cost I think the two big if can make the cost of running these analytics much smaller much smaller so if you can you know because of the efficiency you can run it on like tens of the hardware that you usually would do so the improvements that are that are made in trouble I guess over guess so mostly database yes right so could this be used for for I mean I mean there six

or seven e theorem clients but only two that I really used to guess and parity but this also be used for parity yes though in I did actually sync and talked with parity about it so they need enough motivation and enough sort of justification to do this or it will require the big overhaul of their architecture of the client to do something like this essentially this is the overhaul that I have done for for going theory them to do this but to say this similar overhaul were required because you essentially have to change it on many many things so they had a similar project not that ambitious called parity DB which is essentially

flattened representation of the current state this potato this hasn't been integrated into the parity yet because they haven't found enough motivation for it but it might be if we go ahead with some of our plans like an advances in client I sort of see that if if this project is going we will see convergence and then other declines ball implemented especially if it becomes kind of all-around benefit you know there will be no reason not to adopt this Yesi so if there are no drawbacks there's there's no reason to not also instrument it superior database good see you all here alluded to the fact that you also two other things you mentioned

is a theorem one point x yes can you can you quickly tell us and the listeners um what do you mean by a theorem 1x and how it differs from with your one indi theorem two and how serenity in constantinople actually fit into the picture yeah so i'm gonna work to walk you through the what i call the short prehistory as i usually introduced at one point x so it starts with the conclusion in November November 2017 where AB italic at gave his closing speech called what was the quote modest proposal for Assyrian 2.0 and in that speech he said that the plan some his suggestion is to keep the theorem 1.0 as

the conservative and safe chain and most of the innovations will go into the shards shards on a theorem 2.0 so people thought well that make sense kind of and then in May 2000 18 at ed corn in in Toronto Vitalik gave another presentation about what I think it was called so you want to become Casper validator and so that was about about running the Casper validators on your laptop that it basically signaling that the Casper FFG is a called friendly phonology gadget

was near was closed but then somewhat surprisingly for people in June 2018 there comes a day a quote would I call pivot in ethereal 2.0 meaning that the Casper FFG on a cerium 1.0 would not happen instead there will be a separate chain which is called a beacon chain that will be launched as the in parallel to serum 1.0 and then the Casper researches and sharding researchers will be merged into one research team because they turned that they they turn out to be doing lots of similar things

and that people basically meant that well we are not going to so the the the first people thought well maybe that's pivot means that we're gonna get sharding faster or Casper faster but then by the October and November 2018 when again metallic laid out the potential timeline for the Serenity it became clear actually it's not gonna be that fast right it might take three years optimistically to functionally supersede the theorem 1.0 and maybe five years not optimistic alee by a function is two preceding me i mean you need to

go through phase zero phase one and phase two to actually get to the same functionality as we get in a theorem 2.0 so if you just just launching the beacon chain is not enough so then people realize oh we have to we have to live with the theorem 1.0 for another three years at least and probably for another five years and look what is happening and so this kind of look what is happening was it was sort of the initial chatter and if it difficult for among the kind of core developers like whoa what do you think is gonna happen like this is going to we're really struggling with the growing stage but the sync with the synchronization things taking it forever

are we really gonna work so this is where how the ETA 1.0 1.0 actually world and the reason why it's called one point X is because we don't know if it's gonna be 1.3 1.5 over that whatever 1.7 so just put the excellent cool so as I understand that there's a couple of things that are actually part of Ethier in one point X and different people are working on them so and maybe you can give us a short overview of who is part of Ethiopian one point X and what kind of projects they're working on okay so there were initially four working groups that were kind of initiated for a 31-point X so one of the

working groups is that we called it state rent and now we call it state he is because it might not be just rent and so I take I took on the sort of the the leading this group and people agreed people were over there I hope it's still okay and then there was another group about chain pruning so the this is the group which will be looking at something which is not related to the state directly but also something that the current Assyrian clients have some issues with storing the blocks which i think is going about 70 gigabytes or 80 gigabytes now the block bodies and also

the growing event logs storage so this has to be we would have to start pruning them at some point and so so Peter szilágyi has stepped stepped in to leave this group so it everything is kind of fluid at the moment so the groups are not really sort of restricted to these people so we always welcome new people to contribute and so the third group was [Music] so the third group was a wasum group so some people might be surprised what he wasn't doing in there it's like how is it related so this like is so I agree that sometime some it might sound a bit

artificial but the initial when we initiated this the belief was that but something like a state rent or state fees will be a kind of restriction to the resources that we give to the tab developers and it's good to bring something in return so you you take something and you give something else so you're not just taking or you're not just leaving it's a give or take so if item has a potential of doing this and also awasum could help to to reduce the number of point features that we have to introduce there was a lot of talk about

introducing new pre compiles were lots of different prettier graphics primitives and that if you look at the history of presenting a release there was a lot of time spent on just implementing two or three pre compiles because of the proper gas recalculation lots of testing and so instead of doing that instead of spending the time core developers time and that why don't we just do the what they call the last free compile Jesse wasn't and then you can implement all the pre composite it has a lot of nuances but these are the two reasons why he wasn't there and currently he was amiss basically we led by he wasn't T mm-hmm yeah I'm not gonna list all the people because I probably

will go miss somebody out but so then the fourth group is that has been formed is the emulation simulation group is essentially this is the group that tries to find out the what are the tools that we can use to support the other groups like state ran and chain pruning group to do some sort of to run some test scenarios and to try to predict what problems that we're gonna face in the future what are they gonna be the first things that will break you know that's the roughly the description I as I say that I don't have a list of people who work in each working groups

because it's all at the moment it's all very fluid and open I I see anybody who contributing to the to this as a part of the working group so I just want to maybe come back on this and and and maybe clarify a few things so this was this is all very confusing to me okay my version numbers and then also you serenity in Constantinople and as someone who sort of vaguely follows this I thought it was confusing so I can imagine for someone who's coming into the ecosystem just how confusing it could be so we had etherium you know there's etherium like up until now and at some point you know the idea of a theorem 2.0 was was put out but as it

stands it looks like all the features that are on the roadmap won't be ready for production deployment until maybe three to five years from now or at least until that arise to stability it might be some time however the etherium blockchain and the the system as it stands has a number of problems and a number of issues so during DEFCON these people who came together and said okay let's form these working groups so that we can come up with a dot release in in the version one of aetherium which would include some of these features so that we can continue to build the ecosystem and build apps on top of aetherium yes that's that's

that's exactly correct representation also people realize that the the fate of Assyrian one point or and two point or are linked one cannot live without without the other so and this is the important bit so you cannot just simply forget about what's happening one point over and hope that you know but we will get there like would they say room 2.0 so it had one supports to the other okay and just so in in the one point X version of aetherium which is this version that we aspire to to bill at some point and to release there are

so right now for things that are in that roadmap one is state rent which we'll come to in a few minutes the other is chain pruning so optimizations on the size of blocks and logs awasum and emulation in simulation yeah tools and so what's left then in a theory 'm 2.0 in the roadmap okay so ECM 2.0 is a very ambitious project and the parts of the the work that we are aspiring to doing is here 120x will be very useful for it if you don't 2.0 for example it is singe it seems to me that there is it some consensus that the statement will be

required in a theorem 2.0 and the but it it the difference between the sort of the statement in the second aetherium out code and the first is theorem is that in the second theorem it can be pure it doesn't have the legacy of the current ecosystem current contracts you don't have to deal with my transitional issues with the things that you have to look at so in the film in the second integral we can just introduce it in pure form without all the mitigations for the certain vulnerabilities but the lessons that you learn with the first theory will be invaluable for properly introducing it into into the second a

few the same I would say for us on you can learn a lot of lessons on the way and apply it it wasa in a much better way to to the shards when it comes in and I mean the chain pruning obviously will also be it so any basically my conclusion is that everything that we do will be useful in second if you because it will make it a better system so it will inform a lot of design decisions in addition to prefer steak and yes eating chains and all these other things yes okay it seems it feels like this was a natural thing to do anyway like to do things in an iterative sort of fashion

yes I kind of seems logical to me that yes there was a see it is the sort of the gap which was probably temporarily over was temporarily overlooked and we simply just recognized this is the gap and then we we have to still put resources and this gap rather than just shifting them or also the the second etherium good I think I think this is a great preface for actually talking about these proposed these proposed things in details so um can you briefly recap what you mean by state rent and why we need this okay so the so first of all the this there are ID or statement or some

people call used to cold storage rent they it is not new idea and a lot of people entertained it back in 2014 and 15 before the theorem started but previously people were concerned about the cost of storage essentially they were looking oh you know when you're increased the would ICO expand the state of aetherium by that they created a new contract or by introducing a new item into contract storage then you pay for it once and gas and then it's they're staying forever unless you decide to free it which you know you might not never never do and so people were representing this problem as like okay

so you pay it once but then other people will have to pay for it for like till the end of time so at I realized that this is probably was the failure of the previous kind of rent statement researches that they concentrated on this particular cost or on the cost of storage because it if you start this argument you very quickly find yourself arguing about things that you don't know like we don't know how much it costs to store these things right we don't know how much how the depending on different kind of storage how the cost function tables offer and things like this so instead we sort of brick pivoted from this approach and realize we're going to only talk about

performance implications of the state rent or sorry the not statement of the large state this is the problem that we seen is that as the etherium gets more use or even with the constant use the the size of the state grows and that brings some performance problems which we could observe it's not something that we can we speculate about it's something that we can measure and this is one of the reasons why we have this inhalation simulation group to help us okay so in but the other part that it didn't answer I think is the it so if we don't bother clearing the state that is that people use and the concern is that

the state is it's probably something that you use for a while but then you you know the the depth come and go a lot of them come and go they will you know if we but the state that they've been using is in the system so everybody has to keep downloading it back and forth so what we can talk about is the total set state which is essentially let's say ten gigabytes at the moment everybody has to download ten gigabytes when they join the network then let's say that if there's a six gigabytes or eight gigabytes of this which nobody cares about like people were rarely use it it's just there because they were there first and then there's a useful useful state which is what everybody everybody knew

knew people who come to the system they have to be content with using just two gigabytes so and so the the problem is that this this kind of the useful state kind of keeps shrinking so you essentially end up with lots of garbage in your state which everybody has to shuffle around but the actual useful space is really constrained you can you can compare it with live with let's say the state of the property market in in a like center of London or something like this where there's a lot of cows as empty they they actually owned by somebody but nobody really lives there and then so the the rest of the so do all the people who want to live there

they have to be content with the very small number of houses and obviously they will be have to pay a lot of money for renting them and stuff like this so in the theory instead just get to get rid of this the empty houses but kind of get rid of them build new ones and redistribute them in a sense of the rent so I think our premise is that this is the the important for longevity so the system does not become kind of this dead what I call the ghost town where where there's lots of empty houses and nobody can use them okay so basically the ideas um to charge people not once when they start using storage and then paying them

back a certain amount if they free it up again but actually charging people by the day or by the block that they're actually using the storage exactly so if they decide that they don't don't need this things anymore they can just withdraw they ether or they just leave it leave it you know leave it and then it will be and a garbage collected by the rent so I see the rent as the garbage collection mechanism mostly and a lot of programming languages actually have that built in as well right so basically that you free up space that you that you no longer need yeah yeah the difference between the programming languages and this is that we have a very difficult difficult problem of determining what is not used anymore

so that's why we have we needed things like recovery is that we've made a mistake and removed something that people actually need there has to be a way to bring it back okay so walk us through the process so basically em say you have a you have a smart contract now and it uses storage so it has to pay rent so it has to have funds or someone needs to pave funds on behalf of it and so what happens if no if no one pays so under the current proposals of all of them actually all three of them so when the smart contract exhausts its balance and the rent balance there are two separate things so when there's nothing in both of these balances then eviction happens so eviction under the current

proposals that eviction doesn't just happen automatically somebody actually has to poke this contract so by PO can mean that somebody has to create a transaction which touches it like you access it in some way for example somebody queries the balance and then in the end of the block list this contract gets evicted eviction happens differently for for non contracts and contracts for non contracts which basically just have some monetary ether eviction means just removing from the state because apart from the because there's nothing really useful in that you know there's not useful information for contracts of course there's a there's a storage so in fiction and the current proposal does

not completely remove it from a state but it leaves so called a stub which is essentially the hash the commitment to the entire state of the contract before it eviction and this stub unfortunately it does have an effect that it does not completely remove it from the state so it has to still dangle there but this stub is what allows us to restore it later on if said if it was by mistake and somebody realizes so the biggest example is for example if you had the multi-sig wallet with lots of tokens on it and then you made mistake but you didn't pay up the rent and you realized suddenly oh my mom is sick is gone and there was million dollars in it I

wants it back so you would be able to use the recovery mechanism to rebuild the storage of this contract in another contract and simply use a special opcode to restore it from the stub and then you get your contract back you can chop it up with the rent and then you keep using it or you can move your your things elsewhere and the stub is it's worth stub stored the stub would still be stored in the state so this is the kind of the price we pay for other recovery so the stub is expected to be 30 bucks 32 bytes sort of hash which is a commitment to what the contract looked like before it was evicted

okay and so I'm not sure I understand on how that solves the problem of freeing up state if the stub is stored in the state yes so this is basically a non perfect solution and we we have a more perfect solution down the line but we we want to see if this non perfect solution is actually going to be enough so if we so obviously for this for the contracts which have not null storage at all or a very little storage this stub is probably gonna be big enough so that there's not enough benefit in clearing but for the contracts which have lots of storage at 10 million items so not tell

minions so ten thousand items million items for those contracts of course the benefit of clearing will be a quite big so instead of 10 million things sorry twenty ten thousand things you can have one hash in the state and everybody has to download only just that one hash rather than all the ten ten thousand eight hundred thousand items yeah it's a non perfect solution but we hope that it might be enough for our purposes okay I'm still not sure I understand so the the hash itself contains just the hash of the state but where is the accident like come back coming back to

this idea of recovering a multi-sig wallet where is the actual data like so if that data gets deleted from from the blockchain okay so this data will have to be recovered from the history obviously so if you are if you want to recover your multi-sig you have to go to our archive node or some node which they'll have the history recover that like recover what the state was and then reconstruct that state on chain and then instruct the blockchain to instruct the EVM to recover it restore it okay so that it only it doesn't alleviate archive notes from having to store this

data it only alleviates those regular notes from having the store of the state data exactly because the the the problem with we seen is not actually the disk space that you users have so as I said we are trying to not care about this too much because it but we are actually now looking only at the active current state that everybody has to download when they when in join the network which is the more a much more acute issue to solve and your multisig will be deleted from that state but leaving this stab that you can use to then prove that okay this is was the state of mom odyssic pls

recover it and it will be recovered can you use this as a feature so basically saying this is a contract I want I I want to have on the public ledger but I don't need to access it often so maybe only once a year or so oh sure I will let let it run out of rent and then basically only the stub has to be safe by everyone and then I will I will migrate it to a new contract I will restore it when I need it again oh yes of course you can probably use it to to to to save you some money on rent yes so you just kind of hibernating your contract that sounds very similar to a stateless contract design that you find in some

other chain so for instance a polka dot uses this or also our chain can you compare those two yeah so the the difference is that in the stateless contracts we assume that the when the contract is is represented as a stub it's still accessible by the normal operations in the in our in our proposal the when the stub is when the contract is in the hardware nation state when it's stopped it's not accessible by anything it's basically invisible by a VM with the exception of this special op code which is called restore to only that up code can see that stuff nothing else can so two other a contract so two other

observable observers it looks like it's not there and so with the status contract is not true so with the status contract paradigm is that it's supposed to be usable it's to put you supposed to be able to to mutate that state to access the you know the bits in the off-chance storage with our with our mechanism is like you have to first restore it bring it back on chain then you can use it and then you if you finished using it you can let it expire and then cleaned up if you if you want to so as when you talk about a earlier you mentioned a perfect solution and non perfect solution so yeah if we find if we find that this is not enough for example if we find that there will be

lots of tons of little contracts having the fresh stubs and then still the state is still not small enough the perfect solution it's not actually perfect but so it's it basically completely removing the contract from the state and there there are three alternatives how to deal with it so first of all not recovery at all this is the kind of a nuclear option basically saying that once it's gone to the stage there is no way to bring it back the second stage second option is what Vitalik suggested in his paper on the resource pricing is essentially you when you want to revive the contract

which is not in the state would not even a stop you need to prove two things you need to obviously reconstruct the state the state that it was and then you need to prove that at some point in the past this was the state the state of the contract and the way you prove it is through the hash chain through the header chain and through the state route so this is the first thing you need to prove that it existed at some point in the past but the second thing you need to prove that it did not exist at any point after that so what this is what they call exclusion exclusion proof so first you do inclusion proof and then you do exclusion proof and for the

exclusion proof it's strictly because you basically have to prove for every block since the eviction that it wasn't there and there are ways to optimize it for example if you say that we now main date that every contract has to live at least for 1024 blocks and then it means that we don't have to do exclusion proof for every block but just only for every 1024 blocks and the way we can mandate it is say you say whenever you create the contract you prepay the rent for one year one for 1024 blocks and advance to make sure it will not get evicted and the third way to do it which is is what

I call the graveyard tree is essentially eviction of the contract will require to have access to some kind of graveyard miracle tree where all the evicted contracts still live and so if you want to evict something you say okay I'm gonna this is the you know the state of the graveyard tree you're like miracle proof to the split to the place where I'm going to put this contract and this is now I'm putting this contract into the graveyard and this is the modified miracle tree proof and then later on if somebody wants to revive it then they they give a proof this is the contract inside the graveyard tree and this is the update of the graveyard tree without this contract so you basically take it out of the graveyard and put it back

into the chain so that you don't have to do exclusion proofs but this requires everybody who ever wanted to evict or restore contracts to have this full copy of the graveyard graveyard tree but I we hope that will not will it will not get there - - those things so I will just I've described it a little bit in my first proposal I have excluded it from the second for simplicity I might bring him back in the third but basically we hope we will not meet these measures because they're slightly more advanced I'm looking at this so basically if this were a completely new system obviously this

makes a lot of sense that you don't pay for storage once and then you can use it essentially forever I mean that's the work the way that this the system should be designed but obviously that's not the case here so basically you have to move this from a system where people actually deployed smart contracts under different assumptions to this to this new state rent system and to me it seems there would be a lot of complications correct you're absolutely right so this is what makes this I would say both very challenging and very rewarding at the same time because we're not designing the pure system we're

designing the the kind of the migration from the legacy system to some non perfect system that we introduce in so that's why we when we started analyzing the the implications of the of the rent on an existing contract there were few things that basically sprang and sprang into the mind so one of them is what we call the dust griefing vulnerability and he kind of the conclusion was that most of the contracts that exist today will be vulnerable unto this vulnerable to this attack well to this yet to this grief and attack I can explain them to you if you want yes please

imagine the easily taken example the our beloved your c20 talking contract which has things like transfer and approve and so so the approve is a good example because the approve is essentially allows somebody to pull the tokens out of your out of your account and also another feature of approve is that anybody can call it even without being a token holder so I can call approve to and in any contract without even having to acquire tokens so all I need is just a tiny bit of ether on my account and I can approve lots of things so if you imagine that if we have this token

contract which has the information about all the token Holdings inside it in its storage then under the state rent regime this token contract will start paying like the rent per port number of items and so that means that if I am a villain if I want to hurt this contract or to make sure that they abandoned it or me baby I may be a competitor or something so what I will do is that I will start doing the proof like lots of lots of random things so they can inflate the storage of this contract by using a little bit of gas and so I will condemn them to pay a lots of fees forever by just doing some tiny

investment of gas think so this is what I call the dust Gryphon attack so I create a lot of dust I can do it by transfer as well I can purchase some tokens or acquire it in some ways and then just distribute them over lots of dust accounts which will also inflate the storage but a prove is much better because you don't even need to take with the tokens and the same applies for for lots of other contracts so for example for the decks with the either Delta for for I decks so every trade settlement is the is the is creating another storage items so as you trade you basically inflate keep inflating as contracts and stuff like that so this is one of the

first thing to solve and so far the intuition is that most of the contracts that are existent popular today will be vulnerable and they will have to essentially be rewritten which is a bad news but and then another realization we did is that there if we look at the contracts which depend on each other let's say if you have some sort of decentralized exchange and you have things like maker Dow which now have some links to each other so like you can move the contracts from one to another where you have some other interrelations so if we say okay now we're going to introduce rent all you

guys are gonna be vulnerable you have to break overview at the same time this is not plausible right so you have to say well you've got this time to upgrade maybe one year or something and this is how you can do it and you can do it in one by one so first contract which is the dependency of everybody upgrades first then the the other dependent contracts subset upgrade next and so forth yeah I know this is really challenging but we will see we still don't know when this problem will really become a kind of crucial to solve but currently intuition it will have to happen within the next three years

will you help people determine what kind of contingencies and dependencies there are because basically this seems like it is enormously complex it's a little bit like fixing an engine while it's running so you take out little parts and you need to make sure that the end the engine actually keeps running while you're actually switching out sighs this is enormous Lee you mean this is kind of one of the biggest part of the project and at the moment I in the plan in the kind of the project punim I've been creating I call this part a consistent research and that would consist of essentially numerating all the different

sort of contracts and tabs that we have and then for each of them to have somebody looking into those contracts and determining what are the vulnerabilities what will happen to them and what are the ways they can they can rewrite and modify this and of course then having misinformation going to these developers of this contracts and have conversations with them say this is how you're likely to be affected this is how you we think you should try to rewrite and get their feedback maybe they will give us the idea about some missing features and the proposals may be something which we haven't thought about so yeah this is a this is going to be a large work and at the moment I think

we're trying to make it to make it more kind of community driven and by this I mean we're planning to create a lot of get home get coin grants and bounties so that multiple people can work at once on the this is different because it will require the Kumasi parallelization parallelization of efforts like I'm not trying to do this myself because simply there's not enough hours in a day and so there's gonna be there has to be a lot of people working on this so there's probably gonna be the big the most intensive part of this whole thing so this is going to be a massive undertaking and just to just to give people an idea of the of the unforeseen consequences that this could have you

recently tweeted about the parity track that was suicided last year so can you talk about that yeah so this is the first of all I don't want to give people an impression that this was intentionally designed this way it's in the realization that I came to me when I was reading some tweet tweets by John Elliott Morelli and so he was asking whether create - so they were discussing to create - consequences and they the marillion is asking like you're gonna enable parity parts of autistic recovery and I said well obviously not about something else would so essentially in in the proposal number two there was

this part which is called replay protection which means that so when your non-contract account gets evicted from the state and gets reinstated so you can reinstate it by sending some easier to it then it would normally get to non zero which means that you can repeat the notices that you had before and so as let's say if you pretend that you are the person who has the private key from the account that deployed parity monastic library by pretend that you're Gavin would if it was a covenant with right and you still kept that private key and then we deployed this with play protection and then we deployed the the rent and eviction

so then what Gavin would do is that he would take that private key Ted take that account he will remove all the ether from it so it will be zero then he will get it addicted by poking it so he's a contract it's not contract so his account gets evicted then he put some more Eastern to it yet it comes back with a non zero then he says okay when I created the parody mode to see black break my notes was let's say 35 so then he does verify transactions to something else and then it gets to the same nonce as he had when he deployed multi-sig library now he does the transaction which deploys completely different contracts which is doesn't have the the vulnerability and the program fixed so

the library comes back at the same address and everybody gets access to the funds right it's not this it wasn't designed this way but it was the the reason why it it sort of became possible because we did not think about the nonces not just nonces are not just for for reply protection nonce is also used as the determining of the contract addresses so and now it has to be a consideration so in the in a third proposal I will replace this particular replace replayed protection mechanism with another which does not repeat the monsters so essentially the conclusion of this the nonces cannot be repeated interesting so I mean this is this is an

enormous Lee ambitious undertaking and so what's what's the timeline on this and do you intend to have some sort of proof of concept well the timeline for the whole project is probably anything between 18 months and 30 months because we so the for example the state rent which is the most complicated bit of it it has many pieces in it so at the moment I when I'm writing portfolio 3 every every change has a letter from a to s so how many letters I did you figure out yourself and they organized in the sort of dependency diagram which shows you which change is necessary for the prerequisite

for another change and so the size diagram already exists in the second version so you can have a look but the third version is very difficult and then using this diagram we split it into pieces though so this could happen the first hard work this could happen in a second hard work and this is happening in the third hard work and actually interesting bit about it is that at some point let's say after first hard work we also get some side benefits we will be able to increase the blacas limit which which currently we're not recommending doing we do not recommend doing because it will accelerate the state size growth so as I said if it's a three hard Forks and if we assume that each hard for it takes was eight nine months to execute

then it'll be 27 months right but we already be starting getting some benefits after the second hard work if we start affecting the non-contract accounts so proof concept is i think you know this is how we're going to operate with this this thing is that the proof of concept has to be done as it's iterative process before you even get to the IPS so that's my opinion is specifically about for this project because it's so complex is that so we already had one first proof of concept on the first version of proposal done by Adrian Sutton from Pegasus so we're going to be doing more this proof of

concept potentially again with Adrian but also engage some other people to do that so essentially idea after one or two proposals versions will do proof concept to figure out what hasn't been unspecified what is ambiguous and and obviously this proof of concept will also allow us to generate the test cases for the so that it's pretty easy for the other core developers to then implement those things so we do a lot of work upfront so that when we put out the IPS we already have proof of concept and we have tests generated so that's the ambition

earlier you we talked about awasum and you know mentioned that aetherium one point X would would have he was um as part of its roadmap and that in a theory M 2.0 there would be improvements on he was um now let's not I mean I don't think we'll go into the details of what he wasn't is if our listeners can go back to episodes two forty five with Martin Bessie or two sixty three with Justin Drake for you know a more in-depth discussion on what it exactly is II was them but with regards to the roadmap can you talk a bit more about so the steps that we would see here with here in one point X and if you're in 2.0

with her s that he wasn't so yeah it wasn't is one of the reason he wasn't has been brought under this kind of umbrella of the e theorem one point X is that it enables us to not concentrate on what we call point features so and so if you look at the let's say by science in release of the etherium which happened in October 2017 it included four things for free compiles new pre-compile which is the sort of optimized subroutines which he cool for some cryptographic operations and although it was very useful it actually took a long time and a lot of work from the key theorem core

developers to prepare it's very tricky and since then there was more and more requests for more pre-compose because the lots of things that people find useful are simply too costly to implement in EVM the bytecode so there's more and more requests and at the moment we find ourselves like you know if we try to implement all these requests there's going to be no time for other things maecenas the solutions of this as what they call what some people called the last precompile so essentially you roll out the the engine which will be more efficient at executing those operations so more tuned to let's say card where as

the e azam is and so it will enable us to to introduce these features like much easier so that's what that's why I called Ibrahim as a massive feature as opposed to these point features which are specific for compels people asking so we don't have to spend our time coding up specific pre-compiled that people one who just do things as a give us execution engine and maybe in the beginning it will be used for core developers to to quickly introduce this request pre compiles and in the future to just open it up to everybody so if you want your pre compile or whatever you just deploy them as they et was a

contract so that's the yesterday vision and it wasn't what then in effect run in parallel to the to the EVM yes so there is no plan in at least in in the theory in the first theorem to replace EVM with II wasn't because I don't think it's practical and other people also think it's not practical so there will be some ways to call even some subroutines from EVM code it might be done by a special up code or some Tripucka pre-compiled essentially there will be some kind of boundaries where you enter that you Azzam and now the e was an execution engine which will be in all

the theorem implementation it will take over from EVM so at this boundaries and then when the II wasn't procedure subroutine finished execution it will give the control back to the EVM this kind of and at some point during the execution it wasn't there might be some points where the II wasn't code will require access to some of the theorem states so it's not just gonna run and do some fewer come computation but sometimes it will have to go and fetch something from the state or or maybe update the state you talk about some of the ways or some of the scenarios where it would be it would be useful for AVM to call up an e

was M subroutine yes so one of the things that was kind of discovered in by the work of let's say Greg Colvin when he was working on the what they call EVM one-point-five project so he said that he did a lot of experimentation and he discovered that because the EVM has such a loanword which is 32 bytes our operations have to be done on a long words and it's much much less efficient than if you just had operations on 64 bits which is it mostly implemented in hardware so awasum for example is much more attuned to the

hardware execution because it has 32 bit registers it was 64 so 32-bit and 64-bit registers so when you execute this code you don't have to do a lot of aggregation of the you know because the math and the long word is much much much lower so the idea is that we for a lot of the useful things we can execute things only wasn't faster just simply because it has this different arithmetics and because it's it might have more optimized compilers and things like this so it has a for example is it I don't think it has a dynamic jumps

like IBM has so it allows some sort of more static analysis it like in other another optimizations that's my view of this at least cool so III think we need to wrap up soon so I have some questions as to the how you see the future of aetherium so it seems that and for if you if you room one there is still a lot of potential to make aetherium one as is better without actually touching upon both shouting and and proof of stake so given that he theorem 2 is going to take longer than

expected to actually be put into place what would you hope to see in the coming months and years with ithi room 1 point X and should for some reason or other am aetherium to fall through entirely so should this fall apart just because basically each of these two big topics shouting and and prefer sake both of them I enormously complex and meshing them together only adds to that so I mean do you think there is a danger of that not happening and if you move on point X and and putting the pressure on it even one point a point X to actually

step up to take to take over for the next couple of years well I think that obviously there are a lot of uncertainties about the future of a theorem 2.0 because at the moment they have a phase 2 phase 3 phase 0 pretty well specified but as we saw in some of the reviews I think what when the read was from James Prestwich so he did a lot of interesting review where he says that as you go through the phases the there's more and more uncertainty and for example the phase 3 which is so it's almost like there's very very vague about what is this gonna how this is gonna work so I do sometimes have some

not worries I don't worry about that much but I do have some doubts that it might take a bit longer then let's say even five years for this to happen and whether the the there will be clear benefits and how exactly sharding is going to be done so I mean me personally I don't I like fixing things that currently work rather than designing intonation so designing new things because this is not my probably not my strength to try to implement completely new things so I like fixing things that already work and this is why the the theorem one point X project is kind of

perfect so what we see in Stephan one point X I think we will be able to solve the one of the biggest problems without any controversy or without any heart works I could go into this if you like and if we see that the theorem to point over is not you know has some more delays then we will redouble our efforts and I think we can do certain things to to kind of to keep this area working we'll have to do some extraordinary measures for example we might need to make the state access remote and do what I call poor man's charting of state so which is like a sharding which is not

enforced by the by the protocol like in the the second aetherium but the sharding which is emergent simply from the fact that people are not storing the entire state anymore so this is this is the things that I might see happening in the future but if we so what I do believe is it if we keep keep focusing on this and not simply open that the things will keep working because I think if we simply hope that things are gonna keep working they will stop working if we if we keep focusing on making sure they do work and just keep fixing them we have much better chance of basically keeping it alive for as long as we want

I think and and some there's some people like Greg Colvin he believes that well seeing the film 1.0 is probably gonna be if alive for as long as were used for as long as you know maybe forever like I mean maybe it will coexist for if they with the with a second ethereal I mean maybe the the entire transition will never happen maybe some people will prefer to stay on the list on this system for a very long time you can't really force them to to go away can you maybe you can but it's we'll see what how this happens so let's let's look into the future now and and I just want

to get your thoughts on this so you know presuming that proof of stake chains are the future of blockchain and that proof-of-work chains become less and less used because proof of stake has clear benefits and what we're seeing right now is like cosmos is about to launch and you know polka dot is also making some headway and like these these chains are proof of stake negative if it takes three to five years for a theory of 2.0 to fully you know to be fully realized with group of stake and charting and like you know side chains and everything do you think there's a risk that aetherium would lose some of its network effect and some of its sort of authority as the primary and sort of

like authoritative smart contracting DAP platform to other chains that are you know natively proof of stake and you're already having the ability built apps and things on them yes so this is very interesting question so to the first ed to address the point of proof of stake I think I was really looking forward to cosmos launch because I to me was the first kind of non trivial proof of state system that will come to the to sort of production and I'm really excited for it to lunch and I think there was a bit of a competition there between all these three things and now obviously we'll probably will see cosmos launch first

and polka-dot after that and if save your money and we will see how it goes and hopefully this is gonna work but I will still see that the the proof wait booth works is not proof of work is not dead yet so we will be stuck with it for a while and then and to the second part of your question is whether if zero might lose its appeal it might actually do it and one way to not dis let this happen is to actually bring new experiments in innovations to it so as an example a lot of people look at state

rent is there some sort of negative a kind of negative thing but I actually I would say that lots of if you look around a lot of the block change that that which the certain states that sorry scale you know in the beginning when you launch a new blockchain it's always like yes yes we're going to be SuperDuper blockchain and we'll kind of scale enormously but when they do reach certain scale they start seeing the problems of the growing state and these problems repeat again and again everywhere that's why in lots of projects they started to think about the stay trend to introduce it but nobody actually done it so far so what I see if the theorem does it first and actually

shows how it needs to be done this is going to be a really big step forward not step backwards so yet it will be the first real life introduction of this concept which everybody was just talking about in theory type theory Tizen oh and now we have it in practice and it will be basically I can see this is the competitive advantage pretty much and the other things as well is you know if you to do the things like it was and I know that polka-dot already has it might if it wasn't but again we will see who is gonna do it first okay well actually thank you so much for joining us today

is fascinating to get a glimpse and into this and I also really kind of get to understand where thing are out with aetherium right now it's true that you know since since they've gone a lot of things have been percolating and it really helps to get someone to to really lay out the current state of things and where things are going okay thank you much for having me it was a real pleasure to have this chat thank you thank you thank you for joining us on this week's episode we released new episodes every week you can find and subscribe to the show on iTunes Spotify YouTube SoundCloud or wherever your listen to podcasts and if you have a

Google home or Alexa device you can tell it to listen to the latest episode of the epicenter podcast go to epicenter TV slash subscribe for a full list of places where you can watch and listen while you there be sure to sign up for the newsletter so you get new episodes in your inbox as they're released if you want to interact with us guests or other podcast listeners you can follow us on twitter and please leave us a review on iTunes it helps to be behind the show and we're always happy to read them but thanks so much we look forward to being back [Music] [Music]