Removing state from Ethereum layer 1 to enable rich dApps like Pepo
ETHCC 3 · March 2020 · 21:18
Benjamin Bollen discusses removing state from Ethereum’s base layer to support richer applications such as Pepo.
Speakers
Topics
From ETHCC 3, hosted by Ethereum France.
Transcript
Thanks hello thank you for joining I'm men I only have 20 minutes so I will not be able to go into depth of the whole project and what we've done so far and we were going but I want to give you an introduction of what we've been building so far we call it mosaic and the problem we're directly solving is how do we scale state rich naps on material as an overview I want to focus on a mission statement and the what and
then I will go into the how but if there's questions about the house and I'm happy to take this also offline further and and walk you to Dan after the how I can tell a bit about where we are now and where we want to go in the future so the mission statement is to come together for a decentralized supercomputing network for humanity why decentralized and why a supercomputing network decentralized in the first place because privacy requires that you have ownership and so we first need to construct self custody of data and hence
you in this meaning decentralized but why a supercomputer for Humanity what does that mean and so as humans we're already cyborgs we build choose to run better we build planes to fly better or fly at all but what do we build to think the only two we have so far our computers and then that brings back the same question whose computer is it and who's thought is it so Who am I I'm Ben I had a life as a theoretical physicist in 2014 I started caring about privacy apparently enough to join a decentralized movement
but I'm here today to learn from you and to invite you on this mission so let's try to create some context what does it mean to have a supercomputer right so on this graph you see a linear a straight line but it's a logarithmic scale on the y-axis so every line a dotted line there is a thousand times more operations per second and so IBM summit I googled is I think the world's leading supercomputer if you scale that down roughly a few billion times you end up in your smartphone in your pocket if you scale that down a thousand times we have a theorem today at roughly half a
million operations per second so that's not a supercomputer yet but we don't have to be shy because mining for a theorem has a respectable usage of computation it's a modest supercomputer itself but it's also highly inefficient it's all wasted computation and so as an observation is graph nicely shows that probably we have built humanity's most inefficient machine ever but we build it because we uniquely solve one problem we construct a global state that we haven't gotten any other way to to construct and so what's the size of the problem what
what's the scale of humanity so the most powerful computer we have on this planet is the seven billion human brains combined and so to put that on the same graph you end up all the way in the right top corner and so it theorem as a tool for humanity is a very far way off we obviously don't have to go all the way there but how do we build tools that support humanity better and so what I want to present here today is that there's actually three basic out well one is not so basic because I respect them a lot but like there's three algorithms that we know already today that really can make a significant
difference on this graph for a theorem and the one that we will focus on here is parallelization if you look at existing supercomputer systems then you will find that the cost breakdown of having about a million subsystems usually as where where they find a balance point so this is a very optimistic upper bound where say you get a hundred thousand X or up to a ten thousand X improvement if you would paralyze different block chains but we're not alone in this fight we have the fight for ATM 2 which is a sort ition algorithm which by itself also
gives you a 10,000 x improvement theoretically speaking they would add up but in practice I think it's more reasonable to say that that you would get an optimistic upper bound of twice a thousand and then you have a third class of algorithms that are arguments of knowledge and here I don't have a strong understanding of where the upper bound would be so I faded it out but I think it's definitely feasible to think about a thousand X as well as a side note with the a theorem to work he would also make the whole architecture far less efficient far less inefficient by
removing proof-of-work from the cost equation so how we have a lot of teams working on ATM to also moving away from proof of work there's very talented teams and researchers working on arguments of knowledge but paralyzation which is the foundation block for the supercomputers we have today doesn't seem to be a conversation in the equipment space and that's what I want to focus our attention on and so how do you how do you paralyze so we've learned a lot how to write secure software in a parallel environment and so what you need is an ownership model
of the data you want that only one parallel process can write to the data but you want that many processes can read from the data and then within a theorem we actually know very well how to deal with ownership so you can have non fungible tokens and it's almost trivial you can check the EIP how to make them basically data assets to manage who can write to the data and who can only read from the data but that by itself doesn't give you paralyzation that gives you how you write adapt it in a paralyzed environment what you also need is a synchronously parallel systems so they need to be asynchronous because
that's almost the definition of Brian Paulo and in a decentralized context the asynchronicity is of course also important to have the security guarantees especially when you want to have a theorem as the hub of a hub-and-spoke model which has a limited capacity then you cannot have any synchronous algorithm to compose this system and so what you want to do and this comes back to the state of the apps running on a more powerful system is that you want to actually also compose state trees so you want to build stay trees and state transitions and then in
bulk inject them into the meny theorem state read and you can actually do this with canonical BFT so again the proposals are very conservative they're applying what we already learned learned but now again add layer two and and interestingly i hope that this becomes clear you can also assert that availability by by sticking to canonical bft so that's really where we are today right it theorems main strength is that you have callable storage between contracts but it's also its inherent weakness we cannot have great user experience without smart contract
wallets smart contract wallets are inherently stateful and so there is a whole group i've listed just some that we know or personally know i guess of the apps that currently don't really have the infrastructure to function and grow right they have high frequency interactions low value per transaction and they actually want to compute on the state which is very expensive on it theorem right now so continuing with the how like how how do you approach is right like go out into the world and and iterate so in 2017 we build the first MVP so that we would
also learn how do you build apps in a parallel environment but then put it on minute in a constrained permission form and we're currently working on moving from generation zero test net to generation one where we would have moved to a permissionless system so as a validator you stake and if you bring the money you get the rights but also the responsibilities and then going forward we need to architect the Constitution for how to govern this as a public good and so I want to focus a little bit deeper technically on this second point of how do you paralyze namely how do you
construct horizontally scalable system on top of a theorem so imagine that you have a theorem as it stands right now a theorem one and you now have these subsystems and you can have an n number of them we will call these subsystems meta chains if they satisfy these four conditions so that's sort of the definition of what we refer to as a metal chain what you want and this is the crucial one of the first problems you need to address of course is that you cannot burden a Tyrian one if you're in one runs on proof-of-work so it has a verifiers dilemma that means that you cannot do you have to be inefficient on
it theorem proof of work so you need to play a minimal consensus game on it theorem one that doesn't scale with the amount of work you're finalizing but rather skills with the number of validators in the group only then as sort of emphasized already you want that each of these systems can run and finalize their history in parallel without needing to communicate back to a theorem one and this we can do because we have developed Kasper FFG and so you can use that algorithm to finalize each of these subsystems in parallel and anyone that any of these subsystems can come back to it theorem
and commit any finalized segment of their history to it here and here the asynchronicity is important so these synchronicity is in the communication protocol between any subsystem any theorem as a hub and then you have a unique opportunity I'll get into that a little bit deeper but you now can actually assert data availability because you have a longer time scale upon which you can actually in the future ask is the data still available and hold Valladares accountable for that future availability of the data and then the last the fourth point is that you
don't want to weaken the security so you want that any subsystem is secured by all validators for any of the commits per construction if you think of what is a block it contains a header and it contains a transaction list we do the same here so you can think of a meta block in a simplified form as having header we called the kernel and the transaction contracts are the ones that define the
header [Music] and as soon as you have a new header now any finalized history segment with Casper 15 then that was running continuously on the metal chain inform is a correct formulation for completing a metal so any of these yellow lines any finalized checkpoint on that history they are valid proposition for a metal block nice opportunity to both pull the
security and in the way that you do that is by any of these finalized checkpoints so imagine these yellow thick lines it's being finalized by a group of core validators and so you can bring this aggregated signature back to a theorem as a treatment but if you know canonical to get P then you first need to propose a block pre commit to the block and then you commit the block and so that same sequence happens here there is the proposal but with a strategy which runs continuously and anyone can figure this history
now you can then Luana theorem is post the pre-commit generate a new committee of randomly selected balladeer from all validators and they generally represent the full validator pool go back ask if the data is available and recompute whether it's a valid key theorem state transition and if so then you and in this new header you also have the chance to define the new validator set so every validator so you can join once you have this architecture now you
can communicate between the two systems so you have a fast communication channel from the hub to the method chain because you're continuously observing experiment self and then at every metal block that gets committed messages that have been stored in the outbox can also be proven back on the inbox but this is not all you get out of this construction you actually get pile of computation because any of the meta chains can very efficiently read any of the other method chains so you have one system one parallel try that writes and many that we I will keep it short so the objective
here the next milestone is to get to validator rewards and have an open set where as a validator you need to stake to join this validator set but most importantly I just want to leave you with where we are now so we are building all of this under mosaic now the contracts defined the proof of state consensus engine which is Byzantine fault tolerant and then we are building two validator implementations one in rust and one in typescript and then with generation 1 and onward we want to organize a tacit ons because there's a whole talk to be had on how do you write
validators in in this this new context what I mean to say is that up to now as a validator you add a deterministic plan of attack or policy of how to contribute to the finalization now you have a game theoretic set of options because with casper FFG if you know you get to choose which boats you or you get to define your own links and so it's actually much more interesting validator implementation which also means that we want to create an e system where we're not writing the best validator we will try to write
implementations model implementations but then true attacker tones actually incentivize that other teams write more powerful validators that are more efficient more resilient and and then as a statement we want to construct this as a public good from the beginning it was hopefully demonstrated by the fact that we're only building a small piece from the mission and and that together with ADM two efforts and and work on computational integrity algorithms but that we can actually build a tool for Humanity so if you want to talk to us then definitely find us out here on the
venue thank you so much for listening and if there's any questions [Applause] we have two minutes if anyone have any questions thank you so everyone who suffered through my talk gets a free sweater because we have them and they need to go so thanks