xDai TokenBridge, ENS, Connext and Fuel Keynotes (Combined Recording)

Transcript

[Music] um hello everyone my name is alex kolodev and i am from token beach project so today we will talk about uh a tool we developed recently to allow you to transfer any air seat when you're talking from the therium and net to the exact chain without any additional contract deployment from your site this tool was built on top of arbitrary message bridge technology and you know historical uh historically we building a building bridges a long time

and first of all it was it were bridges for some dedicated pair of tokens like boa token or die token but after that we started thinking why we just start uh transferring anything from one chain to another chain any message any information and we developed a arbitrary message breach eventually so um v3 message breach allow us to transfer any data from one chain to another as i said and so in order to achieve this one contract need just encode method call and data for these methods

and transfer this data to the arbitrary message bridge contract and the arbitrary message breach contract will call this method on another side of the bridge so it will be called in another chain so technically it is look like uh presented on this p on this picture so as i said someone uh would like to send something from one chain to another chain uh they need to encode the data including the methods descriptor and the arbitrary message breach will transfer it

so it will emit events and oracle oracle's arbitrary message breach oracles will pick up this event and send these confirmations in form of multi-seek to the home to the bridge contract on another side on another chain and this contract will will execute eventually the target contract right so um our arbitrary message breach can consist from contracts from the oracles as i said we also have some health monitoring tool deployment script and the last

thing we developed recently is arbitrary breach live monitoring tool which allow users to get status of the transactions they send through uh arbitrary message breach so um in order to develop the uh contracts which will use arbitrary their meter message breach we call these contract mediators you could follow the instructions on our documentation page so and uh we already have uh several mediators uh to transfer lc20 to rc20 uh tokens to transfer native tokens

to rc20 tokens we even tried and experimented with nft tokens like uh cryptokitties to transfer from them from one one chain to another and as i said our recent deployment is for multi-token mediator which allows us to transfer any token uh from one chain to another so the main idea here is that user uh just transfer token uh by sending them to the mediator contract uh and um uh the message will be uh with this information will transfer to another chain

and uh another contract uh another token contract will be deployed uh at that chain so uh for example in the uh if we transfer some token from the therium network die chain so we will at the end we'll have two token contracts one uh uh the original contract one at the ethereum and another one uh fc 677 contract on another side of the bridge so in in the exit chain so as you said so the user need to perform two actions they the user need to approve the mediator contract to send

to transfer tokens and after that it initiates uh the user initiates [Music] token transferring by calling real-life tokens uh methods from the mediator contract media contract uh get name symbol and decimals from the rc origins from the original ac receipt when it contract and uh transfer all this information together with amount of tokens should be transferred to another side of the chain and there the counter as they said the contract the new country deployed and the corresponding number of tokens is minted so

later user don't need to uh so later the new contracts will the new contract will not be created obviously so if the user would like to send tokens for existing pair so it will lead that just another message will be passed through the bridge and the new uh tokens will be minted in the exit chain and definitely um the user could withdraw tokens um from the exit chain so for for these they need to call transparent call method

from the co-token contract and the corresponding number of tokens will be burnt uh on the x die chain and the message will be passed to the bridge on another site on the ethereum net and the corresponding number of tokens will be unlocked eventually in the ethereum way net so as you see that uh when these tokens are transferred to the exit chain anyone so these tokens could be um transferred there to any other users and any user could withdraw tokens back to the ethereum magnet

so and that's why it is very useful so um uh what what else we have on this pair of mediators so we could uh not only use an approve method but if the original token is rc677 or you see 827 token contracts so they can be relayed without approving so you they can be relayed uh by calling a transference call method definitely uh in the exit chain we created such kind of token control we use such kind of trucking contract contract to deploy new token uh which

this which is extended a bit so user could uh use uh uh just transfer method uh to withdraw the token so they don't need to call a transparent call and it's quite convenient to just use transfer method to withdraw token back to the ethereum net so and more functionality we have like limits fees token registries token registry which uh allow you to get the foreign uh the the contract on the ethereum net if you have just

the token uh address on the x die chain or you can get the token address on next diet chain if you would know just uh the token address on the ethereum net okay so um as i said uh this contract was deployed recent it was developed recently and we already deployed it on ethereum mynet so this we already deployed this pair of mediators to the ethereum unit and everyone could start uh using this uh in order to you know solve this uh gas fees high gas fees uh issue uh if it is um you know crucible for your application

uh just now okay and uh let's try to do some demonstration how it works but not on the real chain because it could be this demo could be quite slow and that's why let's use the testing bridge we have between coven and circle okay here is my browser and we see the first mediator on the covent site and another mediator on the socal side also presented in the browser so i also deployed two tokens uh before this demo one token is ddc one and another edc two and let's check

that this token uh do not these tokens do not exist in the so-called chain so we can check that we can find some token right uh okay but we can not find uh for example edc one or dc2 okay and let's try to transfer it uh from one chain to another first of all we need to address of mediator to allow this mediator to send tokens from one chain to two transfer tokens and let's transfer approve sorry and let's approve um

these mediators transfer tokens okay um aft then let's um transfer these tokens also connect wallet and we will say that okay we will transfer this amount of this amount of tokens to another chain and let's check the transaction [Music] okay let's

one more time let's try one okay this is our transaction and we can can we use uh uh alm tool to check the status okay we see that the one of the validity or one of the validators uh confirmed the transaction to be transferred in fact we have just one invalidator and the status of the requests success so let's find the token on another site etc1 okay new token appeared we see that uh okay this is our tokens this our token uh and we see that these

p 50 ad tokens appeared on this side and also you can find okay let's try to for this transfer another token okay can repeat the same actions proof [Music] and the same amount why not okay sorry um so now we need to conf transfer these tokens this

this is another token contract okay this is another second contract and we will transfer it right okay let's check the transaction okay let's check this transaction in lm2 uh wait for [Music] its confirmation in the next day sorry in circle chain

okay it also was transferred successfully uh it needs some time okay but let's check that the token appeared two right you talking appeared and in fact that we have 50 tokens transferred and let's return to edc one one more time we recently introduced the feature in

the blog scout which allow us to see that the token was breached from the ethereum net and you will see the link to this token uh on azure scan okay so uh hopefully i will have a time to transfer this token back this is our address let's switch to switch to circle so called this net add token and try to transfer it to the the gator

okay this is our mediator let's try to transfer it to the mediator sorry um for example 30. okay this is our transaction let's check it and

yeah it should it should take on some time okay it was transferred and let's check okay and kovan testnet we have okay yeah uh we see that less than 30 co tokens were transferred because we have some fee on this bridge for testing and yeah we see that the bridge works successfully um yeah i think this is addresses of the common mediator state indicator

contracts and yeah thanks for your attention uh visit our sites to get more information and contact us if you have any questions thank you hi um i'm presenting on how ens complements dns my name is brantley milligan i work for this non-profit called true names limited and we are the de facto managers of the open source project the ethereum name

service uh there's more information about us um i'm gonna first talk about kind of what ens is and then how ens works and how it complements dns and then how to integrate ens so ens of course stands for the ethereum name service uh so what does this mean uh so how is it a name service actually we're gonna start with the second part um a naming service is just a lookup system people always over complicate this uh just you provide a name it it provides you with information your computer might then do something with that information but that is separate from the naming service so why why do we have naming services it's because um computer identifiers which work really well for

for software uh are not easy to read by humans um and what's easy to read for humans is not easy to read for software obvious right because human language it's difficult for computers to understand that um and you know computer identifiers it's long string of numbers and letters easy for software but hard for humans to understand um so uh so ens you know just has names there's owners of names and records that can store any information if you have a name you can look up and retrieve its records and then do something with that information now this is very important to understand let's say you're using it for a cryptocurrency address ens provides your wallet with the cryptocurrency address and then your wallet

sends that transaction some people think ens sends the transaction on it doesn't um this is this is how we're able to be on ethereum but but uh support any cryptocurrency um it's because um it's because we're just storing the crypt let's say the bitcoin address and we give it to the wall and the wallet sends the bitcoin um transaction so why is it called the ethereum name service then it's not because it's naming service only for the ethereum ecosystem but because it's naming service built on ethereum so the logic and records are stored on ethereum but it can store information relevant to anything so obviously other cryptocurrencies um it can store an ipfs hash you could store your email address it could store anything

anything you want we use ethereum though because we think it's the best blockchain platform um i'm not just playing to the crowd here i really think this it has high security and decentralization obviously it has all this ecosystem infrastructure built out like metamask and other things there are standards we can take advantage of um we can take advantage of its programmability and the fact we can interact with other smart contracts on ethereum which is really powerful if we for example had our own dedicated blockchain just for naming um we would lose out on all of this uh so this is why we are on ethereum so ens uses ethereum to serve the internets including and beyond the ethereum ecosystem that's the message i want you to take

from that and our goal is to make ens and therefore ethereum by the way because enos runs ethereum a basic piece of internet infrastructure used widely by people whether they are part of the blockchain community or not this is our goal we want to do this by complementing the dns tech stack in parallel expanding the capabilities of the existing dns name space focusing on use cases not served by dns in some cases not possible in dns so we're not we're not you know trying to do normal websites and email and things like this right now although we can do that just because dns does that well but we're focused on use cases like you know cryptocurrency addresses and

decentralized websites which dns is not suited for so how does dns work key thing to understand is that we have no servers uh we don't run any key infrastructure for ens um it's entirely a set of smart contracts on the ethereum blockchain and so that means anybody can use it you don't have to use our special api or anything like that we're not a gatekeeper this just kind of explains more you know there's three main types of smart contracts the registry which just holds all the names and the owners the resolvers which holds all the records and then the registrars which allow people to register names uh of course uh resolutions and lookups um don't require a transaction because

you're just looking up on the ethereum blockchain so you just have to have access to it this is what ens records look like um so we have an address record for an ethereum address uh we have other addresses records for just other cryptocurrency any arbitrary cryptocurrency and ethereum just kind of has that that privileged place because uh we're on ethereum and that makes sense given um a lot of the dapps that people are using and things like this we have a content record where you can put an ipfs hash a swarm hash or even a tour.net address and then we have text records where you put any arbitrary information in fact projects can create their own record type um if they if they need to very easily using text records and then we also support dns records for

for some use cases if you want to see an example of all the records we support for yourself just go to app.ens.domains and type in brantley.xyz and you can you can see that all right so let's also talk about the name space on ens so i've kind of alluded to this a little bit uh you've probably heard of dot eth so dot eth is the native top-level domain or publix or or suffix um on ens but we're also integrating the dns namespace so we've already integrated.xyz.lux.cred.art.club so if you have a dns name with that ending you can actually use that on ens and i gave the example

is an example of that um but we're expanding that so like dot com.org and dot io and all the all the main ones uh here very soon so stay tuned so how does dns compare to dns so so why would you use ens at all uh well ens has much simpler art architecture so the dns servers are replaced by smart contracts uh ens has zero downtime you can't ddos attack it because it's you're literally reading it you could be reading it from your own local node it's decentralized more decentralized censorship resistant has built in cryptography and individual ownership which means better security and of course you get all the benefits of programmability

and interactivity with other ethereum smart contracts on the ethereum blockchain which of course dns doesn't have at all so like the if the security and censorship resistance properties of ens make it really good for cryptocurrency storing cryptocurrency addresses and ipfs websites and then the fact that you can ens has program building interactivity on ethereum means you can do things like names owned to buy smart contracts uh or groups of people like adao or multisig also that like dottie's names are nfts which means that they can plug in all that all the nft infrastructure that's already built it's kind of cool

so how would you use ens let's say if you're a developer your goal should be that every time a user might otherwise see a cryptocurrency address or content hash they instead see an ens name um these computer identifiers they're great for software they're terrible for uh you know user experience and users don't even need to know they exist you know right just like most internet users don't know what an ip address is they don't even know they have an ip address they don't know that google has an ip address all they know is that they can type in google.com and that takes them to a website

so the primary use case for ens i think kind of like our bread and butter is cryptocurrency address forward resolution so forward resolution means that you supply a name and it resolves to an address so let's say i'm here in a wallet i type in an ens name the wallet oh grabs the address i you know maybe i can verify it if i need to and then i can send it to that address and we also have ethereum address reverse resolution now this only works for ethereum addresses what this means is that if somebody has your ethereum address they can go the other way they can look up to see if an ens name

is attached to that and then they can display the e s name so this is useful let's say if you sign into a dap and um so you sign in with metamask they have your public address they can look up to see if you have an ems name and then display that as like your username or something like that so an example of this a lot of dapps kind of will show your profile like this it's very i think bad ux what instead they can do is show your ens name instead if they want to show your address so people can verify if they want to that's fine but the ens name should be primary so usernames um yes another thing about usernames is that uh dapps

can give users sub domains for uh for free or if they want to uh so so you have to pay there's an annual fee for a dot east name but a sub domain off that um there is no annual fee yeah you have unlimited for free the only cost is the transaction cost to set it up uh so if you have like your dap.eth you could give all of your users a sub domain you know they just have to pay the transaction cost and that could be their username maybe specifically for your dap or if they don't have an ens name and uh like universal login and ethereum and other other adapts are doing this so i mentioned decentralized websites so

we support ipfs hashes that ipfs is a distributed file storage network so a swarm and then we also support tor.onion resolution so that works if you have the tor browser with metamask enabled and if you type in a dot eth name that has a tordon onion address in the content record it will resolve and go to that tor dot onion website which is really cool so let's say you're like you're on metamask mobile by the way a bunch of a bunch of uh a bunch of browsers support this um ipfs websites natively we've got um opera

on android brave on desktop metamask mobile on mobile metamask extension um the status mobile app also supports it and then some other ones as well it's all listed on our website go to ens.domains you can see all the browsers that support us browsers and extensions so you just type in you know your dap dot ether and there you go it's just it's like a normal website we also have this thing called east dns which is a dns bridge dns and ipfs so let's say if a user doesn't have opera or meta mask or something and they want to access your decentralized website

using ens you know it's not going to work so we have this thing where if they just simply add dot link to the end of the name then it will resolve like a normal website so instead of yourdap.east they can do your dapp.d.link and it will resolve so an example like if you go to almond.east.link that's actually a directory a decentralized website directory and that should resolve in any normal browser at all and the way this works is that we own east.link so we just we just can we can direct people through a special server that we have yes it is someone centralized but the the software is all open source you can read more about that on our medium blog

of course i mentioned with tor down indian resolution yes you try this right now if you have the tor browser only the tor browser with metamask enabled then go to duckduckgo tour dot if i i set this up you're gonna have to put a slash at the end of it and if you then hit enter it will go to the duckduckgotor.onion in the service and then uh we also support traditional dns records like i mentioned this isn't like a main use case so it's something we're experimenting with this just can provide better security for for dns records could possibly in the future replace dns infrastructure although not for a long time it could become like maybe the

the source of truth for the dns infrastructure in fact that's exactly what dot credit is doing so dot cred is a top level domain on dns and if you register a dot cred name on dns they automatically create the same dot cred name for you on ens and then this is really interesting the ownership of the dns.cred name actually follows ownership of the ens version of it and then they store the dns right your dns records on ens and ipfs and then they and then they copy them onto their dns servers but the ens ipfs version is the source of truth this is a really cool uh project and then of course everything we haven't thought of so like i mentioned

um anybody can create their own ens record there's a lot of interesting projects that that are using it for for their special identifiers like umbra and other ones as well so you know what have we not thought of what what can you do with it feel free to experiment so thank you very much obviously i'm not taking questions uh because this is an online presentation um but here's uh some important links and thank you very much [Music] so

[Music] wow [Music] hi everyone my name is arjun i'm one of the founders of connext uh today i'm here to talk about instant cross chain and layer 2 communication um before i get started i wanted to give like a quick history of canucks we've been around for quite a while we built the first ever payment channel hub implementation on ethereum with spanx chain back in 2018

uh in 2019 we kind of generalized that and took that to the rest of the different spaces and a bunch of projects like metamask and nujo built really interesting experimental payment flows uh on top of us um and then this year we kind of took a lot of the uh knowledge that we we gained from 2019 the user data and user feedback that we gained and built out connects to v2 and put that live and v2 basically takes um some of the core concepts from v1 and then makes them more decentralized adds generalized state support so any kind of arbitrary state transition and most importantly makes them improves the user experience slightly um cool uh that's a little bit of

background um awesome so jumping into uh cross chain stuff so regardless of whatever vision you subscribe to for the future of this space um whether that's you know eth2 with a bunch of different shards or layer one layer two with a bunch of different layer two options uh or even a bunch of different layer one chains um we are going to end up in a multi-chain world and this has some really interesting consequences for user experience so one of the things that makes ethereum really interesting to use right now particularly for things like d5 is uh that the the flow for interacting with things like exchanges or things like uniswap for instance as shown here

are incredibly seamless um but it's not really clear how that translates when you have users and d5 protocols and other kinds of applications interacting with each other across chains so for instance what happens if your balance is on the arbitrary roll-up and you're trying to call the uniswap contracts on the optimism roll up well uh what currently what the plan is is that you need to exit from the arbitrary roll-up and this takes time costs money it actually takes i think it's a seven day exit period and then you once you get back onto the ethereum chain you then need to enter into the optimism roll up um this of

course takes away uh completely removes the like interoperability and composability experience of d5 that that exists right now and which is one of the main kind of drawing points in which is what has caused such an explosion of of development and experimentation in the space so let's boil that down into kind of three main requirements and we synthesized these a little while back but what this basically translates to is if we want to keep the same level of user experience that we have as theorem today we need to allow for three things one uh transferring funds across chains in a way where users and in all these cases all this needs to happen in a way where users don't know that it's happening so transferring funds across chains either to other participants or to

themselves users can call contracts on other chains and this needs to happen in a way where the users aren't actually giving up access to funds as part of that call um and lastly and this is this is absolutely the most difficult one contracts calling other contracts on other chains um so uh let's see what connects can do to help with this um so to to understand that let's talk a little bit about how connect compares to other layer two networks um so there's a bunch of different kinds of networks out there and i think it's a little bit helpful to kind of give context around them just to understand why layer 2 is actually much more diverse than people understand

or people might initially realize so examples of different kinds of networks this is by no means an exhaustive list are point-to-point network communication networks like tcpip um distributed hash tables like academia uh and blockchains like ethereum and the important thing to note is that all of these things and especially like all of the implementations of these these different kinds of networks usually use multiple like of these other networks in in like as part of how they function so for instance uh ethereum's node discovery protocol is built on top of codemia or uses codemia um uh you know bittorrent is a combination of codemglia to actually find where like source files are and then like streaming data over tcpip um now layer uh what we kind of think a lot a lot of what we think of

within the layer two space is uh is to think of scalability as basically doing what ethereum does but just faster uh and what that usually means is scaling horizontally so that's that's kind of what roll up side chains and plasma do is they take the ethereum execution environment and then we just they just move transactions off of ethereum into another thing that looks exactly like ethereum um and just has an independent validator set or virtualizes the uh the the like like execution environment or something like that um channels on the other hand and specifically connext does something a little bit different so instead of scaling out horizontally to multiple different chains connected is a point-to-point network so it's a little bit more like tcp

and what it does is it allows you to make unbreakable commitments off-chain and these are these are basically commitments to be able to call some set of contracts in the future which can never not be called even if one of the two parties that created the commitment kind of disagree or decide to not show up um now what's really interesting about this is that the the thing that backs these commitments is just a set of smart contracts right um on ethereum this is a set of solidity smart contracts um but this could really be this it could really be any sort of system where you have somebody proving and verifying that uh that the funds are actually locked up there and then how they should be dispersed so uh for instance you could even run connects on top of like a bank account if the bank was the approver and

verifier uh that funds are locked up there and do need to be distributed correctly um well the consequence of this is that you can run it connects on any evm chain and not only on an evm chain but across a bunch of different epm chains um because users can have like a as like as a like from a from a whole network structure standpoint uh users can have channels running on many uh chains concurrently so let's examine a little bit more about what that means uh because it's a little bit of a complex concept um in connext today if you uh if alice wants to make a transaction to bob uh and she has a channel open with the connects node what would happen is that

she makes a conditional transaction to the connex node that resolves only if the connect node makes a corresponding transaction to bob what you'll notice is in that sentence there was no place where i actually mentioned what chain alex alice and bob are on the channels that they're interacting with could be on any chain and in this in this diagram we see that alice's channel multisig uh where her funds are are actually on chain one which could be the ethereum base chain and then bob's multi-sig is on chain two which could be on xdi for instance so putting this together um last week we released a demo to the for the

reddit great like the the great red reddit scalability challenge um of this exact kind of behavior so the ability to call uh to instantly transfer assets across different l2s um and so we we built something called spacefold which is a really really simple swap ui that allows you to swap between optimism matic arbitram uh rinkabi kovan scale and a missing one xdi um how does it work under the hood well when a user goes to the browser app what they're actually doing is connecting to a bunch of different channels each of those channels is is spun up associated with the user's key and each of those channels can be uh can

be controlled by the user independently and each of them is also linked to a a connex node which is which acts as a liquidity provider so if the user has funds on rankinby they're able to swap those funds instantaneously to funds on scale or on matic or on xdi simply by sending a transfer to themselves through the through the next node effectively this is kind of like an off-chain news swap cool what this means is that space fold today and connects today meets our first requirement um users can transfer funds across chains without really needing to know that it's happening and that's one of the cool things that we really really wanted to show in spacebolt is that as a user you should never really need to know that you're on a different chain

until you withdraw and see your transaction actually be mined on a different block explorer than the one that you expected um and spacefold also helps us get kind of close to the second requirement which is the ability to call contracts on other chains um the output of a channel right now on connects is a call to an erc20 contract but there's nothing really that stops that from being a call to any arbitrary contract so long as we can pass in the right parameters so at the moment that's firmly in like the development stage we know exactly what needs to happen to support this it's just a matter of time before we can and then lastly there's contracts calling contracts and other chains now jumping into this is absolutely out of the scope of this talk

because it's really really complex but this is definitely a direction that we think is worth researching and we believe that there will there are absolutely ways to do this uh using k'nex possibly at a lower level than what exists than the kind of evm execution environment itself but perhaps directly between validators between chains if you want to try it out yourself setting up a connects node is easy it's three lines of code and then we also have a guide on how you can do this on multiple chains simultaneously and spin up this baseball demo all of our materials are located on our github and in our docs you can find them here and and if you run into any issues

absolutely that is super responsive on our discord cool thank you so much [Applause] [Music] [Applause]

so [Music] [Applause] [Music] so [Music] wow

[Music] wow [Music] hello everyone my name is john adler and i'm here to talk about fuel and scaling ethereum with optimistic roll-ups so let's start with a brief introduction

about myself i'm currently with fuel labs where we're building fuel a high performance optimistic roll-up chain previously i was working at consensus as a layer two scalability researcher and i created the optimistic roll-up design paradigm from that research so let's talk a bit about the scaling problem first of all since obviously you know optimistic grow-ups are supposed to scale blockchains bitcoin can do between three and seven transactions per second ethereum can do somewhere around 15 or if we're just considering simple payments it's more like 30 and meanwhile visa can handle 10 000 plus transactions per second at peak capacity and we would like to increase this

number we'd like to increase transactions per second or throughput without decreasing decentralization or requiring new trust assumptions obviously it's pretty simple if we just you know trust visa to process all our payments correctly then we don't need a blockchain so we'd like to not insert new trust assumptions and i said through about before which is not exactly scalability so scalability is throughput divided by decentralization it's the ratio and what exactly do we mean by decentralization let's get let's let's find out so first let's see what is the scaling bottleneck uh one common talking point is that for example

uh eos is more scalable than ethereum because it centralized around 21 block producing nodes and you might see graphs like you see over here you know if neos has 21 block producer block producing nodes with approximately even distribution of some some sible resistance control mechanism and meanwhile ethereum and bitcoin have you know six mining pools five mining pools that control the majority of the hash rate which seems odd because if if the number of nodes had anything to do with the transaction throughput then you would expect a theorem in bitcoin to support more transactions per second than eos's so it's wrong that the number of nodes has anything to do with throughput why

because consensus is not the bottleneck so let's see what decentralization is on ethereum we want a non-consensus full node with approximately these hardware specs a four core cpu eight gigabytes of ram and an nvme ssd that should be able to fully validate the chain at a rate approximately 30 times as fast as it grows in other words it's able to catch up when it's doing an initial block download on bitcoin our specs are we want a non-consensus full mode to run on a raspberry pi and a hard disk drive and that must be able to validate the chain at a rate approximately 100 times as fast as it grows and in eos we want a non-consensus phone

load with some absurdly high specs that are right here let's say 64 core cpu one terabyte of ram and so on uh and it must fully validate the chain approximately one times as fast as it grows so you can't really catch up after if you drop off so in other words decentralization is measured by the cost to run a full node it is not the number of full nodes or the number of nodes in general let alone full or not uh and this is a social contract uh you know every blockchain has a social contract of how much it should cost to run a full node and it has nothing to do with consensus so let's see how ethereum scaling bottleneck compares to bitcoin how does

it manifest uh why can despite the fact that you know the presumably you can say the decentralization of ethereum is less because the cost of a full node is much more than bitcoins why is it that ethereum can only do twice the tps you can do 15 to bitcoin seven and the answer is that is because of evm execution uh you can do much more complex smart contracts on ethereum than you can do in bitcoin and the second thing is then this is the the big one is state accesses and state growth so the ethereum's uncompressed state size is approximately 60 gigabytes nowadays this can't fit in ram therefore you have to put it on an ssd ideally an nvme ssd which means you're going to have very

large very long access times uh bitcoin state the utxo set is approximately three gigabytes give or take uh so this is kind of where the biggest the biggest problem comes in this is why ethereum can't do that many more transactions per second despite having much higher hardware requirements to run a full node so how can rollups help solve this particular bottleneck how does it how does it target this particular bottleneck the roll-up design paradigm is essentially you do state access as an execution off chain and you only use the base ethereum chain for data availability and ordering and then you ensure that the validity of this data that you're just posting on chain you can ensure that it's valid

using one of three methods one is a validity or zero knowledge proof so there's a zk roll ups the other one is fraud proofs plus a timeout and this is optimistic roll ups and the third is an interactive verification game plus a timeout and this is what teams like arbitrary doing so why can roll up scale and there's a star here which we'll discuss shortly so with the roll ups the consensus nodes like miners and so on and also non-consensus nodes so users only need to make data available in order they don't have to execute transactions and this is great because you can't have less execution than no execution just ordering transactions is basically the optimal amount of work you can do which is

not there's nothing right you're not executing anything you're just ordering the transactions uh so now where does the can come in from where the cam come in you might have seen interesting interesting numbers like this you know you have a 10 million uh gas gas limit per block you know each transaction in the rob let's say it's aggressively 100 bytes that's actually quite large it can be much smaller you know the gas cost of call data 16 gas per byte and you have a 12 second block time this gives you 500 transactions per second then you can you can look around the internet and you see many estimates of this uh but this isn't exactly correct why because if everything everyone was just using you know let's just consider

a thought experiment if everyone was using a single evm optimistic rollups then that wouldn't increase scalability we wouldn't be able to fit more transactions per second if we want to maintain the same hardware requirements and we want to maintain the same rate at which we can catch up we would still be limited to 15 transactions per second with a single evm roll up some other gotchas and there'll be a few more gotchas in the slide uh you might have seen you know comparisons like this where you know zk roll up the producers of the roll-up have to do a lot of work but verification is very cheap because you just have to verify succinct proof you don't have to you

know fully execute every transaction and in an optimistic role if you want to be safe if you don't want to add additional trust assumptions you do need to fully validate every transaction hence why the previous slide we said an evm optimist to grow up does not result in additional throughput without trade off somewhere else and you know on the on the surface level it seems reasonable that you know this is what this is this is what validity proofs do they allow you to prove some exponentially more expensive thing and you know exponentially less work uh but this isn't exactly true this is not sufficient because what happens if all the royal block producers just go offline and then no one is around to give me a merkle branch a merkle proof that i need to withdraw

my coins or to further transact on the pull-up then what i have to do is apply every single state transition from the roll-ups genesis and it turns out that let's say simple balance transfers you know alice just transfers some money to bob that's basically 99 just a transition there's basically no computation being done there just a simple comparison which is trivial uh so it turns out that in zk roll ups it is not sufficient to just validate the validity proof you also in the worst case and therefore you must metric your system based on this worst case in the worst case you must apply every single state transition from genesis and that is not exponentially

cheaper so because of this validity proofs only scale pure computation with no side effects they do not scale the number of state transitions and if you're just comparing you know simple alice transfers to bob state transitions then using validity proofs does not provide any additional scalability compared to for instance full validation compared to optimistic roll-ups okay so let's talk about the now i spend a lot of time you know telling you why optimistic roll-ups and roll-ups in general don't provide scalability uh or in what cases they don't provide scalability but you know let's talk about now how they can provide scalability what are

the what are some benefits of optimizing scroll-ups so we note that