Resource Efficiency of Realized Mainnet Throughputs of L1s | Steven Pu - Taraxa Project

[Music] hello everyone how's it going pretty tired uh this is this showing all right we're all right cool so um thanks for being here my name is Stephen Pooh I'm one of the co-founders of the terasa project today we're going to present something uh a little bit more fun okay the title looks very boring resource efficiency of realized main net throughput of layer ones what it really is is a study that seeks to expose the lies that you've been told about layer one performance metrics all right let's get to it so the layer one space the web3 infrastructure space has been getting extremely crowded increasingly more so every single year and the need to differentiate between those infrastructure Networks has been growing but that need has not been fulfilled it's been sorted by unrealizable uh theoretical performance metrics um unverifiable tests done on secret networks overly optimistic assumptions that people are making while conducting these tests and of course juicing up their performance with supercomputing level Hardware all right so how do we fix this how do we cut through the hype how do we cut through the lies and the BS well first first of all you conduct all your tests on mainnet you only trust realized performance metrics on mainnet it's on mainnet or it didn't happen okay mainnet or it didn't happen this gets rid of the theoretical numbers this gets rid of the secret nonr non-transparent unverifiable numbers okay this gets you uh this gets rid of the unrealistic non-real World assumptions have your performance metrics un mainnet second the metric must be balanced by Hardware costs so that you're not artificially juicing up your numbers while you're conducting performance tests there are different types of performance there are types of consensus such as leader based consensus mechanisms that especially exploit Juiced up Hardware you guys all know what I'm talking about probably a lot of networks out there with uh minimum requirements of their valider nodes that are extremely expensive might as well be a supercomputer so we proposed a new metric very simple right so simple even my grandmother understands it all right it is T it is simply TPS per dollar spent so we take two numbers realized TPS on mainnet divided by the cost of one single validator node right that's it very simple everyone can understand this right it cuts through a lot of the lies the sources right we get the throughput on the mainnet sources primarily for this study through a website an application called chains speec which is a application that's dedicated to benchmarking onchain performance across web3 infrastructure networks layer 1 and later TW go check it out very interesting we get the hardware costs configurations from every single projects own their own official documents we didn't make it up their own official documentations they minimum Hardware requirement for the validator nodes and we estimate the cost using the Google Cloud calculator right all perfectly transparent every piece of data in this study is on tara. fastdata there's a Google sheet every single bit of data is sourced go check it out you can reproduce it if you want if you have a problem with any of the data let us know happy to correct it if we made a mistake all right let's go through and see how this is done number one we look at realize throughput on Main net so on chains spec if you uh go through and sort by maximum TPS real LIF cell mainnet across a 100 block range you get 34 chains up and including ethereum okay we only included 22 in our study we excluded 12 10 of which are permission networks so permission networks right Beyond you know besides being a complete heresy in the world decentralization um they have highly relaxed trust models and highly relaxed networking condition assumptions so their performance numbers are not technically comparable to permissionless networks the other one is sharded networks now shter networks sharding is a perfectly fine way to scale it just so happens if you actually add up all the through Point numbers across charted States that is not a fair comparison because you're trading off cross shart transactional latency for um you know expanded storage and through put in storage if they're not sharing the same state it's not a comparable it's not a fair comparison okay so Al the 34 um chain SP sorted by Max TPS realiz on chain 12 were excluded 10 because they permissioned they shouldn't even be on that dashboard as far as I'm concerned all the layer TW are permissioned by the way in case anyone doesn't know and two are excluded because they're sharded so we're only going to look at the 22 networks and here are copy directly from chains SPAC the 22 networks maximum realized TPS on chain right across an 100 block uh range right copy directly from their website you can go look at it yourself too right there's another number the number that we're all very familiar with theoretical TPS right sounds really great you know anyone can say anything about theoretical IAL I can say that trxa has a theoretical GPS of infinity you know what whatever not verifiable right so projects are provided their theoretical TPS on chain spec as well and look at the difference between the theoretical TPS and the actual realiz TPS it's pretty big right we put a number on there too yeah look 10 for traxa others are much more ambitious than we are on average of the 22 works that are included in the study there's a 20x gap between theoretical TPS and actual realiz unchain magnet TPS 20x right and it's plot right on a horizontal axis maximum observed TPS actually realiz realize on Main that versus theoretical TPS right so group a modest TPS modest aspirations they're very honest they're honest people right great kudos to the honest people Group B pretty good TPS modest aspirations in their theoretical estimations also pretty good group C I can only describe them as very ambitious crap unchain TPS very ambitious aspirations okay so you guys can check out who these guys are by looking at the source data at trasa look at the numbers yourself all right we talked about Max onchain TPS that's the denominator let's look at the numerator the numerator is cost per month for a single validator note where do we get this from we got it from every single Project's official documentation you go on trdo fastdata every single documentation page where we got these configurations are linked check it yourself all right here are the hardware configurations by CPU memory and hard drive all right so these were adjust slightly scale slightly so they fit nicely onto the graphic at the top the least U Hardware requirement for CPU uh 8 gig 8 gigs for memory and 100 gbt of SSD right this is for a pruned light node for traxa prune consensus light node um much bigger one at the bottom right this is just for reference so once we get the hardware configurations the minimum Hardware configuration for a validator node from every Project's official documentation we turn them into numbers we turn them into Dollars by putting them into Google Cloud calculator now the absolute numbers that you're getting out of the Google Cloud calculator is not important what is important are the relative numbers we're talking about ratios it's very important that all the data come from the same Source everyone knows Google cloud is not the cheapest but we're getting it from a consistent Source okay every single Google Cloud configurations where we got the dollar numbers are again any guess where it is traxa fastdata every one of them linked click it into yourself see it for yourself all right so here are all the numbers copy down for every single car Hardware configuration for minimum Hardware requirement for a validated note across these 22 networks this is the dollar amounts again the absolute numbers are not important it's the relative numbers are important we're calculating a ratio here okay and here's the result right GPS per dollar spend or the longer version mainnet realized GPS realized not theoretical not made up uh not dreamed up realized main net GPS per dollar spend per month for a minimum uh minimum Hardware requirements for a single validator note okay these are the results check it out yourself traxa on its own right now has a main net maximum TPS realiz TPS of 4906 uh the Google Cloud estimator calculates our validator node uh costing 98.7 just under $100 per month and we have a ratio of 49.7 so making us number one in the world in terms of TPS per dollar these are real numbers transparent verifiable not theoretical not dreed up all right if you if you like to disagree love to understand why okay I don't understand why no one does this all right so if you're still awake you might ask how did we achieve such performance I know there was no Shilling I'm just talking about our technology so traxa achieved this level of performance and efficiency because of the following reasons right number one we have a Next Generation blog dag architecture so blog dag if you haven't heard of it it was the first described in a paper called Phantom Ghost dag in 2018 by something lki W borski and Zohar it's a very interesting architecture we read the paper we implemented it it allows parallel um addition of blocks onto the network instead of single chain all right so on single chain you can only add one block at a time on block that you can have multiple blocks at a time right almost every single mainstream layer one you today are single chain architectures they are massively sacrificing security guarantees to get the performance that they're getting massively leader-based consensus all right that's a great example they predict precompute all the leaders are going to be producing the box and every single leader stay there you know producing BLX for many many epochs right let's turn an entire network of thousands of nodes a tax surface of thousands of nodes that's turn into a single node right right great sacrifice of security for performance block dag doesn't have this issue it doesn't need to sacrifice security or decentralization to achieve this kind of performance and this is born out by realized mainnet TPS not dreamed up theoretical paper TPS all right second we have a dynamic subsec block rate it makes sure that the network does not waste any work it Tunes up the block production rate when it sees there's um a drop in the transaction overlap between the D blocks and it turns it down you know Network traffic goes down the other way we have vrf and vdf which reproduces the random delay in proval work systems without the arm race of proof work systems that cost a lot of energy you know it has all the benefits and none of the downsides we have true finality uh with a asynchronous pbft process this is very critical anyone who has tried to take an evm and push it above 100 TPS will realize that the evm actually puts all Reon rising to State through the Patricia merco tree first how do you get past that why do they do that well it's because they're accounting for State reversion risk so in order to get rid of State reversion risk that's inherent in probabilistic finality you have to introduce true finality so we introduce the entire layer of true finality in order to remove the need to always go through the Patricia merco tree every single time state is read and written into okay we have as synchronist and parallel execution and of course we're 100% evm compatible right as this s dber you know show up with evm compatible layer ones right we wouldn't dare showing up with some Rust VMS all right so teraa this year has five bounties uh as part of the hackaton so we hope that after this talk if you're not too angry and too pissed at me uh you will like to check us out you would like to build on the fastest and most efficient layer one in the world we have three AI agent bounties uh and that's very unique right everyone has AI agent bounties I hear the word AI every 3 second sitting at the desk what's unique about traxa is that we have a platform called chape built on top of the layer one that actually is a decentralized network that Feats realtime telegram conversational data from public telegram groups from over 20,000 crypto english- speaking public telegram groups no one else in the world gives you this data nobody else I looked very hard that's why we built this and this is what's going to make the agents that are built on this unique data set substantially different than all the other agents right LS they're easy download the model feeded some data depends on what kind of data you're feeding in this unique data set gives you unique insights okay check it out you won't be disappointed we also have two other infrastructural um layer one bounties free to check out but you know come to terasa doio on our front page are all the resources you need to check out our bounties all right we our team is sitting at desk T1 over there all right and we have a booth 314 if you agree with us if you disagree with us if you want to yell at me come to this places i' love to talk to all right thank you very much