Scalable Account Based Systems on Ethereum

Transcript

okay so next up we're going to be returning once again to the scalability meme and even the zero knowledge proof scalability meme which is pretty great so let's give a warm welcome to talk about gluon plasma Shashank two-body alright so we've been talking about scalability all day I think from the start started with layer 1 scalability the theorem team sort of spoke about that and then we had a few presentations of plasma already some on state channels and this is yet another one this is a take really on one flavor of plasma and I want to be specific on this that this is really applicable for account based plasma so let me try and cover as much

as I can I have only about 15 minutes so of course what you're going to take away from this presentation is just the overview or the highlights if you may if you want to get into the details I'll share the links as I go through and certainly feel free to dig in or get hold of me and we can talk more through the conference ok let's go to the first sort of basics out here right so this is the puzzle that we're all trying to solve in the blockchain world if you think about it this simple trilemma of you know trying to be secure at all points in time enable decentralization right friend we just spoke also you know sort of spoke about the virtues of decentralization and we are all here because we believe

in that right and then the third part is scalability and the third part of scalability is also very important because in the real world and when I say the real world is the Fiat the old world the current world we are all used to things being more performant we can do a lot of transactions per minute we don't have the patience anymore to even wait for a few seconds because the web has told us that everything is instant and everything else around us works very fast right when we all move to the blockchain world we realize well we now gotta wait right everything has a certain amount of time and you know a certain amount of choices that you got to make before you can commit before the transaction is a part of the block which then becomes secure so this is the kind of trial lemma that we keep fighting

with right and in order to solve this and try to get the best of all of it you know there is a bunch of work that's going on in the layer one of and then there are things like plasma and straight channels which are in the lair to space and in this case we're of course attacking the lair to space now there's a lot of plasma flavors I don't know how many of you by the way just raise your hands if you at least are aware one flavor of plasma okay so there are a bunch of people let me ask the reverse question who was not even dabbled with a single layer of plasma doesn't know anything about plasma okay so everyone knows something about plasma that's pretty clear and I'm pretty sure if we ran a poll you'll realize that you know among us we will know various

things about each of these and more right now the plasma is a speck has really gone through a lot of rapid iterations over the last year year and a half right was first introduced about a year and a half back I think 2017 if I have my dates right we're with Alec and Joseph Boone kind of put a paper out there and from then a number of different people have contributed to it now when we took out our own flavor which is called one plasma B obviously you know based at bases all the learnings that we had from the existing research and added on top of it and hopefully made it better and want to take it to the community and they can use it and extend it even further so now why account based systems so if you looked at even the topic of my

presentation it said scalable account base systems so I just want to address that first what does that mean and how is it relevant for us right so if you look at the traditional finance world you know things like exchanges whether they're doing sparked exchanges or derivative products or if you look at payment systems online commerce systems you look at lending prediction markets any of these cases the primary transaction happens to an account so the account is kind of the first-class citizen if you may in those systems and what we thought of is that if we started looking at decentralized finance and started modeling basis the same account based systems you might get hold of a few additional primitives or some interesting perspectives that we can

then use to scale and model a plasma around it so you know that's something to kind of keep in mind and you know as I talk through this hopefully it'll sort of reiterate and explain why that is important how that makes it different so the first and very fundamental piece the moment you start looking at account based systems a lot of the accounting or record-keeping or fidelity of any account based status at a given point in time boils down to just one simple construct which is what is the balance of a certain asset for a given account right and the moment you start looking at that although that idea seems so simple and so natural most of us when we start looking at blockchain transactions we don't think like that we start getting into the UT X source or coin

based accounting or you know denominations and so on so forth but the moment you kind of flip it around the fact that any account would have a certain balance for a certain asset you can start building your fraud proof so you can start building your side chain scalability pretty much with this dad in mind and if you look at gluon plasma spec it sort of builds exactly on the principle that one core principle and of course there is a lot more other you know pieces that are needed to for the things to come together but that's the sort of fundamental building block now what's necessary right so for fast hype you know sort of high throughput real-world fast high frequency trading type applications or online commerce you need a number of different things to

follow in place and you know these are some of the sort of definitive things that you need you need an instant finality right and when i say instant finality i mean instead finality on the side chain right because the instant finality on the main chain of the root chain is determined by the constraints of the root chain and in this case when we look at site chain or any other sort of off chain kind of scaling solutions we essentially are piggybacking on what you could call optimistic security right you want a scale provide all the constraints and security and fraud proof on the off chain but the final sort of finality of the security gets determine when it goes to the root chain or syncs with the root chain so we definitely want instant finality on the side chain we want high throughput so that's

something that we talk about a lot right we talk about transactions per second and there has been a number of conversations around that we all like to talk about how easy it is 24,000 and you know how they can be only 28 on the core ethereum root chain and one dot o and so on so forth but that's super important if you want to run let's say a high frequency spot trading application there is no way that we can do it with us just eighty-eight transactions per second it's not even a starter right same thing with low-latency I spoke about the fact that you know we need absolute sort of instant transactions if you look at real world applications in the stock exchange today you know just step outside the crypto world this one runs in very small number of

milliseconds in fact 50 milliseconds is supposed to be too long a duration if you really look at high-frequency trading if you look at algorithmic trading that's the kind of numbers that today the world runs on right so if you want to really make decentralized finance real and get everybody on board we want to start trading in that direction right from a few minutes to a few seconds to a few milliseconds and then finally to that number so how do we reach there right that's important and of course security guarantees so what we have today is a spec which details out a lot of these bits that I cannot cover right now in this presentation but I'll certainly encourage you to go read that it's almost like a 30 page document which also has some formal proofs around it with all the detailed specs there is

a live exchange a spot exchange which you know we'll also be releasing derivatives products in the near future in about you know a few weeks and that is already out there it uses this spec it is built on the spec it's called leverage you can also play with the test net there it's called test or leveraged at i/o and so those resources are already available there you can go you can play with them you know and you can kind of get a feel for what how does plasma play in this case and what the details are the the spec are so that's certainly available now what I will do right now because since I have very limited time I'll just touch upon some of the essential ideas of what that spec contains but again I will by no means do

justice to the detailed spec the detailed spec is there for detailed analysis if you may write and what is written in a 30-page of well thought-out thoroughly reviewed document can hardly be covered in a few slides but these are some of the key bits there so the first important bit is that it talks about small footprint it obviously uses a concept which we are all super familiar with and has been spoken about few times already even today which is the concept of merkel root space to inclusion/exclusion proof slightly intrusion proofs you do not need in the gluon plasma spec the entire history of the chain for a particular fraud proof you just need the last good valid state that's what it kind of builds on which also allows for validation to be a super small footprint

you do not need the entire node to run everything right from Genesis instant finality spoke about there already compact fraud proves another super important part you know I was speaking to one of the members here earlier today and I think the first question that he raised was well if you look at account based systems sometimes the proofs can become very complex and very elaborate and that is probably true because you know for various use cases the account based systems can have various types of requirements and so in our case what we've done is we really broken them down into types of fraud proofs and each one of them is super compact it's literally one small validation check a small thing that gives you a straight up binary answer and so again all of this is in the spec you can go through each of

those from front-running to standard double spend to all kinds of fraud crews there of course classified very clearly but what I do want to mention is they're very compact in each of those cases another important part of plasma at least all the people who've been in the world of plasma talked about this all the time is that what happens when there is actually a fraud and how easy is it to exit and how fast is it that you can take your money out and so it's definitely optimized for that fast withdrawals is a very important part of the puzzle as well now there's also a governance system put in place and the governance system is largely for the case when there is data unavailability because that is a problem that remains largely unsolved what happens if something is unavailable now something is incorrect because you have the entire

ledger with you and you have the published merkel route that's easy to prove that it was incorrect but if something is not included or something is unavailable it's hard to prove that so that's when the governance aspect comes in we're looking at enhancing that as well but the current spec of course basis of a POA mechanism couple of other slides which will just talk through the essential mechanics of how things work today again for those who have spent some time understanding plasma reading various plasma specs this will look very familiar to you so on the on the Left if we start from the left we've got you know what I'm calling a D app is essential application it could be a an exchange application it could be an online payment system it could be a prediction

market application or it could be or lending application any of those you know think of that as a D app and that particular D app of course is you know running through a certain sets of transactions its emitting a bunch of transactions and that transaction is what I'm calling here at the app transaction ledger so that's the terminology you also use in the spec and this is what records the various sort of transactions beyond the standard transactions are deposit and withdrawal so in the exchange scenario there'll be transactions like a trade you know transactions like a fee reduction and so on so forth now what happens as per the spec and as per the library running system you know which has implemented the spec we essentially combine these transactions into its own sets of blocks which we call glue on

blocks and these glue on blocks at this point in time map to about a couple of ethereum blocks each glue on block but that's configurable there's something that you can have for either longer duration or slightly shorter duration if you map it exactly one is to one within aetherium block there are some challenges with it especially in terms of the challenge period and validation it's good to have a slightly larger block allow for instant finality and scaling on the off chain and then make sure that period also is not too long enough because otherwise you would have a much larger interval when you would have still unconfirmed or on validated transactions so you want that to be sort of optimal we figured out that you know mapping it to about 2 or 3 M blocks seemed to be logical at this point in

time it will of course also be a function of how many transactions get backed into the block right so if there are too many transactions you want to have smaller blocks if there are too few transactions you probably want to have enough so that you do justice to the entire sort of validation process and the rewards associated with it now what we do is if you if you look at it I have mentioned three things up there one is the deposit route withdrawal route and the balance route so this is also a construct that we sort of extended in terms of the merkel route proofs what we do have is the standard sort of merkel routes of all the transactions and apart from looking at that we said well because we are an account based system and

what is of primary importance is the balance of a given asset at a given point in time which is confirmed or unconfirmed so that essentially goes in with the balance titute right so every block also publishes the balance to it which i think is commonly also called the balance commitments in you know in this sort of plasma literature if you may and for a given block because the deposits and withdraw in which is what is there on the extreme left - like of the theorem root chain so in that case also you want to reconcile all the deposits which are ordered of course by time and then all the bit drawers which get committed with the clone block and there is also a merkel root of that now what's next so that's pretty much what

is there today and it's already running a live but that is just as we as I was saying that's just the beginning in some sense the spec is detailed it works today but we feel that it can go to a different level as well now part of the reason why we continue to work on the spec and be also making a lot of enhancements because we published this back back in October of 2018 and the test net was live around the same time so the test net has been live for at least five months now and then the main net essentially went live about you know a few weeks back I would say three weeks so I think yeah about three to four weeks back so in this period we have received a lot of feedback which is great which is fantastic right of course

we had run through the regular sort of internal feedback cycle security audits and everything else but we received some great feedback from other teams who wanted to build on this spec and they came up with more feature requests and you know additional sort of interesting asks which led us to rethink and said well maybe it's time to do a v2 spec as well because some of these use cases some of these extensions are not only beneficial for the larger community for other people who are building on the spec but also for us and at the end of the like I mentioned we wanted to be an open spec which is why we put it out there a few of little bit of our code is also very intertwined so to speak with the logic so we are obviously cleaning that up and going to put that out as an

open source SDK as well so the AP we can build off that you know with a very easy way to start on it so what's coming next so first thing we want to work on or continue to work on is the consensus mechanism so today the governance mechanism is a P a base mechanism it's kind of staking for whoever holds the governance token but that is something that I think we can do better on and we can make it more decentralized we are planning to actually go with the tender mint based consensus model for the off chain consensus mechanism there's already some work that has started that has begun but there is plenty more that needs to be done before that is ready for you know ready and shipped out of there the second piece is when people are going to build different applications

now we started for building for ourselves which was primarily the exchange but people want to build payment systems on there people want a bid prediction markets on it so we do feel that I think a certain level of segregation of the spec level for the app level chain segregation could really be beneficial and so that's that's something that's underway that's also work in progress and then of course you know this is out we are all out here Miriam lovers and you know we are too in the sense of company and our entire team is what we realized that a lot of people are also showing now interest in additional chains people want to look at chains beyond ethereum and there is a lot of also talked about multi chain where you can start with one chain and perhaps you can move on to the other

chain or you can stay cross chain and so on so forth so that's also an area which is gaining a lot of traction and we do want to explore that we do feel that with this plasma spec we might be able to enable that as well of a multi chain model perhaps again leveraging some of the work that you know the cosmos and tendonman guys have done and maybe extending and adding more to it so as the gluon plasma v2 spec is what we call it the we do spec at least in terms of what is already out there and underwear which I mentioned is like a D app level segregation is sort of looking like this now so you can have multiple different D apps and each D app will of course you know emit out its own transaction log or own sets of transactions journals which

is public and then each will creates his own independent gluon block now in this diagram and for the sake of simplicity I've you know sort of made them look as if they all have to be published with the same synchronicity or same interval but that is not a requirement so each di can decide to have its own sort of appropriate interval depending on the number of transactions it's only 10 C requirements its own security guarantees and so then you can end up having you know various sets of gluon blocks if you may that correspond with each different via chain at the same time and of course they'll have their own respective fraud proof subs as well some common ones and some specific to the D apps and as far as the left side of the puzzle goes which is essentially the smart contract that sits

there and you know the whole process of mukuru publication and hashed verification syncing with the root chain that can all be shared so that becomes part of the spec so this is essentially where we are like I said again this is really more like an overview just touching upon what we have done there are a lot of details in here I would encourage you go look at this spec and again if you have questions I'm here the next couple of days as well get hold of me and maybe we can chat some more but yeah I thought would be sharing this would be good if you have feedback if you look at the spec if you think something I should be done also bring them on if you have questions please bring them on as well so that's when you reach out to me that's my email address

that I put out there I know for a lot of audience now the email has become a very old-school way of communication so on the right side is by Handel which you can also tweet me on that or even send me a telegram message that's the same handled okay thank you that's all I got [Applause]