How to Build Ultra-Fast EVM Blockchains Without Raising Millions | Yumin Xia - Galxe

[Music] hi everyone uh my name is reming I'm the CD of Gravity by Galaxy today we'll talk about how to build an ultra fast evm blockchain with Millions dollars so think about this deeps managed to train the City ofth Art model without a giant hyperscale GPU cluster and The Guiding question for us is is it possible to build an ultra fast evm blockchain without massive funding from VCS or crowd so our mindset are very clear if we want to do this we have to leverage solid open source components as much as possible and we need to focus on measurable engineering metric instead of busws like we got building some kind and another AI chain and we and and another goal is we're going to build this for public good instead of some kind of alien technology hype all right so many people consider building blockchain not rocket science I agree but it's neither trivial so under the hood there's a lot of things so this is a traditional blockchain architecture there you see all these components actually has a lot of like practical innovations that need to do to reach a very high performance blockchain so for example for execution people always talk about parallel execution and you we want to do jit or aot to speed up the execution and for um storage you may considered to employ a fully asynchronized IO storage and you have choices between Rax dbm dbx and for consensus there's all of research and studies for new consensus algorithm as well so to start with let's start by choosing the right consensus algorithm so our Criterion is we wanted this chain to be so-called subsequent finality with more than 100 validators we wanted to be highly high suut for independent transactions meaning that for example your Unis swap transactions we want it to be production ready and botle tested implementation and we want to get it down within 12 months so we explored a of options like on the T pbfd family you got tenderman hosta joran Aptos bft and there's a lot of fancy dbased consensus algorism as well so it turns out that abdos bft is a champion after our exploration so some insight about Aptos bft so Aptos bft is an improved version of Jan consensus plus the optimization called UT votes which reduces the consensus latency to St hop and for people familiar with with consensus particles to reach PBF you pbft you to reach PFT you actually the minimal statical limit lower bound is three hop and appos actually their code their implementation has the highest records on on production in last summer they have 300 million user transaction in a day which averages to 3,700 user transaction per second over the whole day they have more than uh 150 nodes and their block time meaning the gap between generating two blocks is around 220 milliseconds and in their latest research the end to end latency is around 380 millisecond plus the client latency depending on where you are and the bonus is that they actually did a bit of research on how to provide an instant onchain Randomness uh if you are interested you can read their paper but in general that means that you need any Oracle your blockchain validor also generate a ver by Randomness um upon your request so is they also rapidly um developed and innovated there has been more than 100 aips pushed to production not just draft and now some some people ask like why not dra why not D based consens algorithm so the reason is that in a in a scenario for defi transactions all these transaction are interdependent meaning that the stack based transaction the fast pass that you don't need to run through a total ordering doesn't work all right um although the state-of-the-art consensus can hit some bottleneck so the naral paper actually revealed a very interesting side that the leader noes network iio is actually a major B if you look at the diagram on the right side the light blue one is the hota algorithm without um without solving the io issue the TPS is somewhere less than 10K or maybe just a even smaller but the darker blue one is the one that you actually solving the network issue that you easily reach 50 or 7 75k so what appos does is that they introduce a very simple and El an mechanism called a coron store meaning that validators basically pre-share transactions into batches and validat the form of coron store proving that they have sold all these transactions already so that when leader propos a block they only need to propose the proof of availability of those batches and then upon execution um validators can always fetch transactions from other validators and even more surprisingly this mechanism even being very simple can be horizontally scale which meaning that you can actually have infinite TPS you want so this is a diagram we also got from the paper that with more workers per validators your TPS can actually reach a very very high level on the right hand side you can see that with 10 workers per validator uh R if you are running narrow uh narrow with u Hof algorism you can actually have uh I think it's around three 600k TPS okay besides the consensus what Apple's also innovated is the pipelining architecture of a blockchain so traditional blockchains like the diagram show before you first have you first uh do transaction dissemination you get all these transactions validator propos a block that contains all these transactions but uh in a pipeline World consensus can be run um independently with execution so in this case when block 100 is actually certifying all the changes meaning it's generating its Merle proof um the block 101 is actually doing execution and the block 102 is actually still running consensus so that that means that with pipelining you'll be able to reduce the latency so for example let's see consensus takes 200 millisecond executions 500 commitments 300 and percent 100 for traditional non-pipeline blockchain it will take uh almost like a second to finish a block but for pipeline architecture it's only the slowest stage which is 500 milliseconds the this also comes the this benefits actually coming from much higher resource utilization where in consensus most of resource are spending on network IO and when execution it's CPU bounded and storage is just disc cor right and so if let's see abdos has already built this Solid Ground can we Mize abdos the answer is of course yes so that's why we build gravity SDK so gravity SDK is an open source mer Iz blockchain framework that designed to be scalable and flexible we do that by modalizing Aptos B tested components and that means like we in this graphity SDK you get coron store meno with coron store for free you get Aptos bft with very low latency and you get this pipeline architecture so this is also the first of this kind like pipeline blockchain SDK as we know and it's very easy to use we don't want user to developers to know all this detail of pipeline blockchain so that's why we build gravity consensus andine interfaces so gravity consensus interfaces basically abstract out the whole consensus process from building a blockchain that the developers basically you only need to implement all these four interfaces that you tell consensus well is this transaction a valid potentially valid transaction upon the current stage and you send transactions to consensus then you will use mle and cor store to broadcast it and when Once consensus reach order those transaction reach the block you will send this order the block to execution layers and execution layer after executing all this transaction it will send back the block hash and the consensus will run another set of finalization upon the block hash which which the whole process also pbed on the Aptos consensus and once it's finalized we'll basically come in and present the every results so if you're looking at from the pipeline architecture will be like this we're building a middleware called execution Channel where on the execution side you basically for each stage uh you build a pipe you build you build an internal queue or buffer or pipeline the transactions are sending through the channel to the consensus engine consensus engine continuously produce blocks to your execution engine your execution engine consume all this blocking order in your execution queue and once that you done that you send that back to the consens engine and send back to the certified blocks commit and you process it so appal SDK is not just an idea uh we've already built it for the past six months it's fully open source although it's still we call it a pre-alpha version but our initial Benchmark is already very impressive uh for simple Concepts like Road transfer reach uh reach 120 uh sorry it's a 12,000 TPS and for Block hand with our default configuration it's less than 500 milliseconds so that you can find the code here we also build a a demo project a demo chain that is a simple key value store with easier and style uh account um you can find it here which less than uh 1,400 Lo now you may ask like well this is a very simple example why do we want build an EVN blockchain so that's what we did so basically we build a pound Rod upon rest rest is the fastest isin execution engine and it's highly optimized but so the challenge we faced is that rest is a traditional non-pipeline blockchain where things go just one by one we introduced a pipeline execution engine called block string reactor that taking order the block from the consensus engine then execute it in a pipeline manner for all these stages and you can find our code here and there's also some other challenges but due to the time limitation I probably not cover um so the next say Let's see we solve the consensus and pipeline issue our next Target is the slowest stage of the pipeline remember that I said they execution is usually that one we call our goal of 1 gigas per second so an example is that if you want to have a 1 gig block for full Unis swap transactions is actually today even you are running rest it's going to take you 700 milliseconds and this is under the assumption that the io latency is zero in a real world um 100 microc latency is actually very usual so if in that case the sequential execution actually can take 12 second or 20 20 4 seconds so that's definitely way slower than we expected uh so that's why we need parallel execution um and as so for parallel execution is actually a well studied algorithm called block stdm so what block stdm does is so-called parallel optimistic paralyzation uh in a very simple World it basically execut in transaction All In Parallel all at once as much as as much as as much as you can and then you started the validation phase that start to valid the transaction from the beginning so the first transaction everybody knows that it's not going to have their any conflict the second transaction basically check well does it conf flly with the first one and the third one check with all these transactions that has been activated before and surprisingly to many people surprised the uh Block estimate is actually very very fast um even it's optimistic so it um in their paper they can actually reach 160 ,000 TPS and this slow overhead is actually pretty low uh in a pure sequential workflow meaning that there's no opportunity to paralyze anything the overhead is only 30% slower um not just block sdn we actually did some interesting followup work based on block sdn so we call this gravi uh gravan 2.0 stand for Gravity rust evm so instead of like we're following the block STM style that we basically schedule the these transactions one by one starting from the lowest index we actually schedule those transactions in parallel using the deck so this St can actually be by obtained by simulating transactions uh in some other stage of the pipeline fully shadowed under the execution and then in this stack we basically try to execute try to parallel execution transactions that has zero dependency and the lowest index and besides that we introduce another mechanism called task group where because we notice that actually on the ism mainnet uh a lot we we we look at all these history transaction data there are many many transactions that depending on each other tightly so in our data we will publish a paper very soon but in our data the p50 uh dependency distance between transactions two meaning that most of these transactions have dependencies next to each other so what task group is that uh uh it will basically in this stack merge those ner merge those nodes that has tight dependencies into one task group then we when we dispatch those transactions we basically disat another group so group transaction within the group won't be executed par but sequentially so that the lat transaction can correctly read the um data that was right by the previous transactions this effectively reduce re uh reduced the re execution as the overhead so The Benchmark is also very good we actually can this algorithm can actually match block assm performance for optim the most ideal case that independent transactions uh which is definitely we them more than we need um and for high Contender workflow we we we put a transaction that has 30% transaction depending on uh each other it is like 29 times speed up maintaining at least uh almost like uh 3 gagz and for nonp paralyzable transactions this mechanism nicely solved the um the the drawback from block the 30% slowdown we reeved only 3 to 5% slowdown than sequential execution and because the re-execution is much reduced there's only we have only 95 we have 95 five% lower CPU usage if you just run block STM so another thing that we found uh during this journey is that optimistic paraly is actually way more effective than most people expected so comb finding this we have gravity chain so the life of a gravity of a transaction gravity chain is that you first reach the through Json RPC and it reaches the menol and coron store and the leader of the consensus will propose a block and send it to our parallel execution engine then it will generate a new state that runs a full block hash and the block hash will runs through another state consensus and after all that it will push to the storage for persistance yeah so our next big release about race staking module so remember uh initially you thought we want to build approval of stake blockchain and one concern we always had is that well most proof of State blockchains ask you to stake their own native token um I know this kind of was operated uh in a lending model or whatever but we think it's not ideal so by introducing reaking we allowed other um we allow allow other validators or economical security to be brought on gravity chain so we were integrating staking protocols like IG ler and babyon which allows us to tap into ether and Bitcoins security level and on the next release we'll also introduce Aptos recent optimization called Aptos that they Shadow all the executions uh by each other uh using optimistic tricks yeah so with that being said uh let's Des with gravity SDK we believe that uh this is the first of its kind pipeline blockchain that reaches very very high performance with this kind of performance we believe we can decentralize a lot lot more things than before uh feel free to uh come around and discuss and throw critical questions to us uh you can feel free to also follow our Twitter here and also scan a QR code thank you like got the keys