EthCC 2: E G Galano

good to start all right all right hi everybody I'm eg I work at in fira over here also as Christian we're gonna be presenting today on in fira and web 3 infrastructure so I'm gonna start with sort of an overview of web 3 infrastructure and exactly what that means through the eyes of in fira running nodes as a service theorem api's and other incentivized protocols that we've dealt with and then Chris is going to finish up the talk today talking about an initiative that we started recently which is a graph QL API for aetherium called each QL all right so what is web 3 infrastructure we're on day 3 of ECC now a lot of the talks here have dealt with everything from application layer to layer to scalability user experience the thing that's really interesting to us is the actual infrastructure in the traditional sense that powers this whether that's etherium clients or the underlying network protocols and things so that's that's what we wanted to discuss the way that we see it is that their layers of web 3 kind of similar to the OSI model for traditional networking stacks but here we're building applications as decentralized applications right and then below that you have the base protocol that powers these web 3 decentralized applications so whether you're building about on top of aetherium or whether you're using aetherium + IP FS or some other decentralized storage or you're pulling additional decentralized components into that like EMS for usability and things there's there's a lot of things to go into that base layer and then below that is the peer to peer layer so part of these decentralized distributed systems as being part of this peer to peer network and I gave a talk at the girl econ conference back in January talking about the peer to peer layer for a theory and that's what I wanted to talk about a little bit on later today so below that there's also the physical infrastructure and my physical infrastructure I mean the actual traditional web infrastructure that we still run on whether that's data centers or Amazon Cloud instances so when we're talking about the application layer we have these utility tokens another application layer protocols and we don't always associate that with infrastructure because maybe it's something like you have Aragon tokens and you're doing things with the Aragon platform but you don't need to run anything necessarily you can use the application but it's not really what you would consider infrastructure but you start to get into that infrastructure world when you start to look at things like live pier which is like a incentivized transcoding system or platform or other things like golem storage rating file coin those types of things require you to run additional clients and that's something I want to touch on a little bit later in this talk when I'm talking about the incentives to participate in these systems below the application layer is that base layer like we were saying the protocol not gonna spend a lot of time talking about that there's plenty of talks here talking about eath 2.0 and the things on that roadmap at four o'clock today there's a session that Boris is putting on on the eath 1x roadmap if you guys haven't been paying attention to the things that came out of that one dex workshop that was in california I think it's January you should attend that talk there's a lot of really interesting things going on at that layer with how aetherium is going to be scaling in in the near term while research on to that is ongoing this is the layer that in fear deals with most regularly which is the nodes the the etherium clients and if you're running your own aetherium client you're probably running one of the two most popular flavors which is gas or parity but client diversity is really great within aetherium and we have a lot of different clients that people can choose to run if you wanted to be able to customize your own client and you're more interested in working in like an elixir codebase you could look at the man aetherium client that compound and POA network in a bunch of others started work on initially as the X theorem project and now it's called the man the etherium client and you could participate in contributing to that the Pantheon client is like a Java Enterprise client that consensus and the Pegasus team released a one dot oh I believe it just just last month and so that's main that capable and you can run that client as well so one of the things to consider when you're talking about running infrastructure so say you're you're going to start a decentralized exchange or a traditional exchange or something your your back-end systems may still require running your own nodes as like a traditional business whether it's for your own personal accounting or additional api's that you want to provide on top of that and understanding which clients are available for you to run that's important and then understanding the governance of these different projects and how to collaborate with them is also important at this early stage of the ecosystem so if you have a question on are they going to be able to add this particular functionality that'll be really useful for your application who do you talk to you right now and it took us a long time to figure out what was the right way to kind of get access to that information and have those conversations and it's difficult and time-consuming right now you see a lot of that come up around these hard Forks for aetherium and a lot of the cross client team development coordination that needs to happen some of it happens on Gator you see these conversations on Twitter and it's it's decentralized and inefficient but by design so if if you want to start contributing to these projects and taking part in these discussions looking at the e3 search boards the follow the developers on Twitter and get into their Gator channels or discord channels the node infrastructure is what these clients actually run on so some of our friends from def node are here so you could run depth and have that manage your client for you whether you're running dab node yourself on your on your laptop or if you're putting that on your body server or some other type of like specialized client device that's one option you could be running this as like your status light client on your mobile device you could be running this through your VPS which I think majority of people do whether that's digitalocean Linode as your AWS and and then lastly people could be running their own physical server somewhere whether that's co-located in a data center or through other some other like bare metal provider but those are pretty much the options that you have and so talking about the physical infrastructure we're building these decentralized applications through these peer-to-peer clients but then the centralization still is there when you start to talk about the physical infrastructure you're we're still in these you know centralized data centers and you're still running on the same fiber backbones that everybody else in the internet that's running on whether you're you know venmo or Twitter or your file coin so when you're talking about decentralization a lot of people talk about decentralization as if it's like it's very clearly defined like yet decentralized it's great but but there are many flavors of decentralization and and decentralization is a spectrum so I think it's valuable to talk about decentralization in terms of what aspects of decentralization is your product or project focusing on are you enhancing privacy are you enhancing security are you more capable of surviving like network faults and things like that through redundancy of the peer-to-peer network and you don't necessarily need to check all boxes as long as you and your users understand the trade-offs that are being made so with that let's talk about the current state of web 3 infrastructure the current state of website infrastructure for aetherium is that our underlying peer-to-peer protocol is called dev p2p it's a combination of the discovery of how your client when it starts up connects to nodes on the network and then the etherium sub protocol built on top of that that defines how that data is shared whether that's you submitting a transaction that propagating across this network or whether that's how your client receives new block information and keeps in sync with the network so that you can participate in it it's really difficult to understand the health of the network because there were you really have to kind of have the centralized point to understand the state of the network and for for the longest time the the source we went to you as a community was Ethernet and that was the source where we could see how many nodes were currently running what clients were running you know where were most of them up-to-date but but that was pretty much it and so earlier this year we started developing this tool that we called just the dev p2p network tool and it was a dev p2p crawler built on top of the etherium JSDF p2p client and it's fairly straightforward that connects to the network and it indexes information as it encounters new nodes basically a dev p2p crawler and what that allows us to do is you know track historical state of the network if I went to the ether nodes or some of these other websites right now I could see the current state of the network but what's really interesting to see is as our community continues to grow as what was the state of the network two months ago or what was the state of the network before and after the Constantinople fork how we're people typically upgrading their clients a week ahead of time or the day of and that's stuff that can help developers better inform their like release cycles and how they communicate with the with the community so that people have time to upgrade their clients back in you know 2016 with spam attacks on the network people would release the client development teams would create the release and the community was still small enough that people knew where to look for that information grab the latest binaries and update their clients and and we sort of had to you to keep the network up and but as the ecosystem and our community continues to grow that information is going to get harder and harder to disseminate so having having these tools and and people should be developing more tools will allow us to understand the health of the dev p2p Network so one of the places where we see issues with the peer-to-peer network arise is on our test networks because they're smaller the most common issue that we encounter is that because of the low hash rate on the proof-of-work test net Rothstein you run into various issues early on there were attacks on Roxton because of there being such a low difficulty on the network that someone was the initially nobody was actually putting GPU miners on it because it wasn't the best use of their hash power there was no incentive to do it and so somebody came along started mining Roxton blocks taking that ether and spamming the network and so people had to start GPU mining and for about a year and a half now people have been using GPU miners on Roxton but then we ran into an issue again with the preparations for the Constantinople fork because nobody was actually paying attention to keeping their clients up-to-date because maybe they had migrated their test applications to rinkeby or some other test met or they they were just kind of leaving this thing running they forgot about it and it was still mining with an old version of the client and so what happened is after the Constantinople fork we were left in a position where we were constantly getting chained reorg xand as in fira running a shared endpoint to give access to this network people are reporting issues saying my transactions not showing up my transactions not getting mine I'm getting inconsistent information and it's not something that we as in fira can fix like people see us as a traditional service that can provide traditional support but it's complex because we're providing support for a peer-to-peer network that isn't really in our control and shouldn't be and so the best thing that we can do is kind of share that information on what's happening with the network so that other people can participate and help fix it so in this case with the roxton network we reached out to people from the foundation they started running updated miners and we were able to get the chain back onto the constantinople side of the fork some other networks koban rinkeby suffer from similar issues of their just being low amounts of notes most people don't really run those notes at all or they don't run them consistently only really when they need to so we can say that people should be using light clients to connect to these but if you try to use a light client to connect to these it's hit or miss whether or not you're actually going to peer and be able to sync it quickly and so I'll talk about light clients have a bit later but it's one of the issues to be aware of so this is why I'm really a fan of the the Gurley test net initiative I've been following it since the beginning when when it first started that eath Berlin because the community passion behind it is really pushing for it to be a reliable test environment if you guys are going to be building any applications on a test net and may be redeploying about application or a testament I would highly encourage you to consider using Gurley for that it's like the most actively maintained test net right now in my opinion the the community behind it is really excited about it being the first like multi client supported test net so you can run yes Pantheon parody nether mind and anything that supports the click protocol can connect to this this test net one of the reasons why Gurley is also so great is because it was just recently reset at girlie Con in January and so it's really fast to sync in fira added support for girli yesterday officially so girly dot and figured out IO you can point your RPC client to it and immediately start using girly but you can probably sync girly faster than it's going to take you to get through this slide right now it's going take you like two minutes to sink in that underly so you should do it and also enable like client support for it one thing to note with that is that if you're using like client's parodies like client will hear extremely quickly because parody nodes support an alternative white client protocol that is enabled unpair the nodes by default so that and you notice that difference versus with Jeff and other clients you have to if you're running a full node you need to explicitly enable serving light clients and so that that creates this dynamic where parity light clans can immediately appear and get synced pretty quickly and the le s Lite etherium sub protocol clients that get supports take a little bit more and aren't as as quick to sing so talking about state growth here there's there's some stuff coming out of the 1x workshop so both Pataki and Alexi and a few others have been talking about proposals for a state right so the current aetherium state depending on which client they're running is roughly around two terabytes 2.1 terabytes right now and you can look on Twitter about whether that's fun whether people care about state or should care about state or should be able to survive off of a light client and regardless of the specific details of that there are people that do need the full state for their business East case whether that's you know looking at historical balances from you know 2017 and things like that we should continue to try to make it easier for those people to not have to wait three weeks to sync a full archive node from scratch if they need to the other thing that's relevant to this is the state snapshots that are generated so warp sync with parody there's been some discussions around how that could be improved and how this state bloat is making that less and less feasible so in this one da Dex workshop later today I'm interested in hearing more about the current developments on that because getting people to keep their clients in sync is really important for the health of the network and then all the client teams are constantly looking at storage optimizations database optimizations things to optimally optimize Disgaea so that the network or so that their clients can continue to keep up so then talking about light clients and ultra light clients I already talked about the parody light client protocol le s is the sort of standard flavor that gets supports there was a talk I think earlier today from Christophe from slaw Catan in Cube there's an alternative like IOT focus light client and then loosed ekala is something that the meta mask team was working on and and it's still continuing to work on which is like a a browser enabled light client using sharding the state and propagating it through this peer-to-peer network of browser browser enabled clients some of the R&D efforts around this so we're a member of this constrained resource client group it's a group that's really interested in looking at the problems of the current light clients and how to improve the usability of them and the paper that we came across recently was from a few people from Stanford khyber and and visa on the fly client if you haven't taken a look at this paper I recommend that you do it's some it's an alternative to an SP V like client that reduces the bandwidth requirement significantly but requires a hard fork to introduce some additional information merkel mountain ranges into the block headers so with light clients so there's roughly a million downloads of meta mask if people here using Mathematica and a feather mask tomorrow switched over to being a light client would there be enough full nodes and light clients servers to be able to support that demand that's up in the air and probably not likely unless we do two things get more people running nodes or get and get light clients more efficient and so this fullness incentive problem is something that we started looking at back in 2017 and we felt like we could create a protocol that would allow people to you earn tokens or earn either to be able to sort of like clients in some form but we didn't feel like there would be enough demand for that it'd be like we create this Pro the column and nobody would actually use it because it's still gonna cost them two hundred dollars a month or take up too much of their MacBooks hard drive space to be able to do that and they wouldn't be incentivized to we came across several teams VIP node and enid that we're working on very similar approaches to that and decided to primarily help with the VIP node projects so if you're not familiar with VIP net Andre he's in charge of that project recently released VIP metadata which is a way for you to deploy a VIP no pool server that allows you to have light clients pay to peer with your VIP node so it's one approach some of the dependencies that we had for incentivization where how do you notes basically do micro payments between each other and we were looking at layer 2 solutions for that that weren't necessarily mature enough and how do you these nodes exchange information on other nodes and the the sort of reputation or of these nodes so like do I want to peer with this node are they able to keep in sync and how much should I be able to pay that now then we said maybe we could use the whisper protocol for something like that but but but it wasn't there yet at the time so talking to these projects is interesting I haven't talked to anybody from Enki but if anybody's here I'd be really interested and the goal of this full node incentivization is to at least recoup some of the cost of running this infrastructure so that we can continue to help onboard new people into the ecosystem that don't have the technical ability that or the resources or the interest in running their own full node incentives are interesting so I like using BitTorrent as an example because it's the most successful peer to peer network that that we have and there isn't this incentive problem there because the incentive with BitTorrent is the content right so if if you want to get on BitTorrent and download you know the the Linux distros I have listed here maybe what other content you want to get off of BitTorrent you have to run this client and and the content is the incentive there's no additional monetary incentive required but with with running an aetherium client the the incentive is not the data you don't care about the day that you care about the functionality of participating in this network so as long as you're able to participate in this network you don't care about if you're propagating information to somebody else and this is the the two-sided market problem of incentivizing people to run full nodes is you can create this incentive protocol but it's too expensive for people to run nodes and then nobody is really interested in paying for something that they haven't even tried yet right and so I like to use uber as the example some people don't consider they were to appear two-sided market but just bear with me with that but if you if you have all of these drivers but no riders then you're not going to have drivers and they're going to go to some other platform right and and that's the kind of problem that in fear asan we wanted to try to help solve here is bootstrap the user side of this enable people to explore web 3 through in fira and Mathematica and all of these other easy on ramps into the ecosystem try to solve some of that usability and UX from both the developer and the consumer side if you guys didn't see Taylor's talk earlier on just the pains of getting onboard into the ecosystem you should check out the recording but the incentive protocols need to be given the chance to succeed by being given a market of people that were that are willing to pay because they they tried out this ecosystem through these simpler access gateways and are ready to participate in in these incentivized models and once we get to a sufficient size I believe that these incentivized systems will actually self activate because people will see the value of it and and begin to participate in it so the growth of the ecosystem is kind of an example of that so that that this is a graph of in fear as daily traffic back when we were only at like one to four gigs are one to four billion requests per day towards the end of 2017 this was the crypto kitties spike so somewhere there at the beginning of December there was this huge spike in people trying out crypto kitties through primarily meta masking and in furious access to aetherium if all of these people had to install an aetherium they would wait for it to sink or if all of these people needed to run a white client it's unclear whether or not crypto kitties would have had as much success as they did during this time so our goals are to help the onboarding experience of these end users whether they're consumers our developers and our commitment to the ecosystem is to maintain an API that's compatible with the open source clients so that people can use in fira and continue to run their own know then switch off whenever they'd like to and then we constantly try to share our learnings on running this infrastructure primarily through our Twitter account so if you're not following us you can follow there and we like to share blog posts periodically to help people run nodes and optimize their infrastructure some of the other improvements of the ecosystem again lowering the cost to run a node alexia Knaus been working on this turbo gas project which is sort of reimagining how the state storage and database storage for a client should work and we've been helping support through him through funding as well as testing we upstream client optimizations whenever we run into performance bottlenecks we've been funding the support funding the research and development of VIP node and we participate in the json-rpc standardization so that you know we can standardize on our PC responses for errors and lately we've been working on this graph QL API that Chris is going to be talking about so going into that the JSON RPC is a very lightweight specification there is really not much there it's not like a tree spec which is why EIP 1474 is trying to define that clearly and it's really just a thin wrapper over what you would like to do with a the blockchain data on disk whether that's grab a specific section of the tree data look at specific transaction hashes and things like that it's not a query language and people are building these applications as if the JSON RPC is a query language the data relationships aren't exactly clear and people that are entering the ecosystem for the first time are constantly referring to either the JSON our RPC documentation or going back to the yellow paper to understand how to use this API there's also this problem of over fetching and under fetching data where you know maybe you're trying to query for presenting data for your wallet and you need to know the account nonce account balances maybe token balances and things like that and that's going to take you dozens if not hundreds of API calls when really with a better API you would do it with fewer and you end up over fetching a lot of data getting redundant data and things that you don't necessarily need or care about so the lack of the definition in the current JSON RPC implementations is ye IP 1474 is valuable and it'll help clear up some inconsistencies around like you know 0 0 X 0 or 0 X types of things that occasionally create bugs on the client library side so with that Chris is going to talk a little bit about eql and this graph QL API for aetherium all right so that's a quick poll I'm curious how many people have heard of graph QL by show of hands great and how many people have used graph QL in a project nice ok so I'm gonna go over a little bit about what graph QL is how it rate relates to aetherium and some of our findings around some early tests and kind of where the space is headed so for those of you that aren't familiar with graph QL it was a API specification originated by Facebook back in 2012 they've been using it internally they open sourced it in 2015 it's had an MIT license applied to it in 2017 I think the problem that they're really trying to solve is how to make the API calls more efficient right they were moving very heavily into mobile mobiles are constrained Network environments so how do you create an API that can quickly and efficiently serve mobile clients and so they started coming up with this graph QL what's nice about it is it's a very it's got a very complete specification it's strongly typed self describing it has query validation built into the spec so a lot of the things that you do as a as a server developer of all the validation and all of the the the queries coming in it's already taken care of before you buy this back the big twist is flipping the paradigm of how data is selected right traditionally as a server developer I would say these are my data resources and I'm gonna expose them to you say over a REST API so I'm gonna give you the entire record of the entire document and so there are always server specified data returns what's left the application developers with the problem of ok so I need to get this resource but I only need two fields out of this document and then it relates to this resource over here and I need three fields off out of that document and after you're building your your front-end you end up making a whole series of web calls and processing all of the the data in order to render your front-end right so graph QL flips this and makes it client specified so graph you all defines okay this is all the data that's available and how it's related and then the client specifies okay so I want this piece of data this field over here it relates to this data object over here and I want that one field we'll go into a little bit of a little bit of what that looks like but the important thing is is it gives the power to the clients versus being wholly specified in the server additionally you get a lot of niceties of there's sort of out-of-the-box solutions for paging versioning deprecating and extensibility with regards to sort of the operational aspect of graph QL there's three major operations there's queries which are read-only operations mutations which are write operations and subscribes which is basically like push messages push notifications long live stock it's like a I think a WebSocket or a long pole HTTP where you're getting pushed information that you're subscribing to it supports variable substitution so you can reuse queries you can create a query tree and just subset parameterize the variables in there so you can reuse your queries and it supports fragments which I'll get into a little bit later in the in the talk so what do we want to use graph QL the summary is that getting data off the blockchain is hard right JSON RPC is not a query language so very simple use cases or things that you might want to do in an application are kind of hard to do in JSON RPC like get only the translate transactions related to my contracts list all the addresses that sent transactions in the light on the latest block show all the token transfers in the last block tell me all the ERC twenty symbols that were traded in you know block X all of this requires multiple calls to over JSON RPC compiling the information filtering it down before you can display it to the user the other reason why is because any data especially aetherium data is graph oriented right all data is sort of relational - one way or another and so what I'm showing here is kind of a simplified view of aetherium data block data transaction receipts logs accounts and how they're all related there are disparate data types and our relationships inherent relationships within them that it's not reflected in a resource based API so why graph QL better user experience it helps solve that problem of over fetching or under fetching data it's less data over the wire less round trips to the server it has better support for constrained environments like mobile since it was built with a with mobile a mobile first ethos there's a strong ecosystem of tools that support the developer experience right so if you think about JSON RPC there's very little tools that actually support the specification that's the kind of stuff that we as developers use are things like web 3 ethers dot j/s the kinds of things but there's actually not that many tools that support the developer experience aside from that like an SDK layer and it's easily extendable so the current state of youth QL sq has been developing pretty pretty rapidly over the last year a little over a year ago Rho a Kriplani came out with each QL as a as a sidecar application right skin over the JSON RPC that exposed a graph QL interface believing that graph QL was a better way to to get theorem data a few months pass Nick Johnson also starts looking at graph QL as as a way to query out of a node eventually in fiora Nick Johnson Raul they all got together found that we're all working toward the same the same end goal and started collaborating on trying to create spec any IPS so where the the ecosystem or where this area stands right now is that we we've just opened up an EIP for comments 1767 and it's focused on basically equivalents with the json-rpc from the node perspective it's focused on simplicity and efficient access of the internal data stores and there's a POC currently implemented in Gath on the master branch if you pull down master and build it there's a dash dash graph QL flag that you can enable the graph QL interface on the other side that's a layer on top of the standard flavor is each QL extended and this is Raul's original project that lays on top of that base layer and extends it with additional higher level applications century use cases things like transaction filtering log decoding storage decoding things that are useful for more of an application perspective this was deployed as a node side car so it attaches over JSON RPC or IPC WebSockets HTTP HTTP it supports log decoding ENS address resolution like I said X ray functionality into storage transaction filters and it's built with an open plug in our architecture so that you can add support for your own custom contracts or ERC's that you're most interested in so it's easily extendable this is a bit what a graph QL query looks like I hope it's legible so basically on the left side we have the actual query it looks a bit exotic from maybe other query languages on the right side you have the resulting tree the resulting set what's important here is that there's equivalence the shape of the data on the left side is the shape of the data on the right side so the clients know exactly what they're getting what to expect on the other thing that I wanted to point out here on the left is the use of a fragment so that's sort of what fragments look like basically you can inline internal data structures and then on the right side you can kind of you can see an example of what log decoding looks like rather than just seeing the raw raw data you're getting the transfer the symbol which accounts is going to value etc so we were running some tests early on in the project and the test was set up like this we wanted to fetch five blocks and from those five blocks we wanted to get the block cache the sending address the value of every transaction and for each sender in those transactions get their balance right so if you think about this from like a web 3 implementation you're basically looking at two sources of data right the blockade a get block call and get balance call put into the context of each ql' it creates a query tree so back to the diagram that I the simplified diagram that I I put up before this is the part of the tree that it's going to be querying and the left side is what it looks like in the graph QL syntax the blocks range from start to end block cash transactions and value it's easier to see here but the the data relationships between blocks transactions and accounts are a little bit more apparent the way that they're nested this is what it looks like executed so what what this is showing is the parameterize queries that I was mentioning before so this is the same the same query block range hash transaction sorry you go back nope there we go parameterize the start in the end blocks otherwise the transaction is that the the query is still the same the parameterised definitions on the bottom there and then the shape of the data again reflects the shape of the query so the results of this doing that query over JSON RPC was a little over 1800 1842 calls right for each of those five blocks starts a little over 300 transactions and so you have to loop over each of those transactions to get the balance in each QL that's a single call this the response size that you get over JSON RPC the over fetching problem is a little over a mega data returned in the eath QL version it's a little over 200k so the the efficiency gains of it the QL over JSON RPC are pretty immense looking at it from more of a node implementation side the data selection gives you increased efficiency because the of omission of data that's not requested so total difficulty is an example of this total difficulty is a data field that's not stored in the block header so it's a separate disk read in order to return it in that block so if you call a get block it returns total difficulty total of at least two disk reads for to return that data what most clients don't really even use total difficulty so if you omit it it's a disk read that note doesn't have to make to return the data additionally receipt access receipt accesses are greatly have a much more efficiency so it's common to say okay for every transaction give me all of the receipts for these transactions the way that you have to do it over JSON RPC is through the get transaction receipt call you supply the transaction hash the node will pull that that data blob deserialize that index the hash and send it back so you're talking about if your enumerate every transaction it's an N squared data access that gets simplified to an o n o n data access so there's a lot of a lot more dramatic efficiency gains there on the application side there's improvements because you're reducing the network payloads response to serialization the response in the application is in a defined shape so it's easier for the application to reason about what's getting returned and it's a better model for decoding raw data rather than keeping it in the application you're syncing a lot of that decoding into a server layer basically the upside is that less loading time in the application is a better user experience so what's next we're working on finalizing a IP 1767 if you're interested in this you know go on comments give your feedback it's still open for comments there's additional IP is covering more higher level subjects such as subscription standards more more functionality on the eath QL extended side we're looking at more log decoding so supporting more standards more ERC's building better tools for developers to use more custom their custom api's and there's also an initiative for client libraries so if you want if you didn't want to use the East QL sidecar you didn't want to run an application server it's it's syncing all of that functionality that the server does into the client side so then you can connect directly to a node and have the benefits of each QL directly in your application additionally for those of you that are sticking around for Heath Paris we're going to be doing a web workshop on Saturday as well diving into SQL and how to build with it so definitely check that out if you're around and that's it thank you [Applause] anybody have questions with respect to alternatives like the graph how this would compare so the graph is focused on event data almost explicitly right so they're indexing the event data this version of graph queue all the ether QL is really about interfacing with a node so for example one thing that you can do with these QL that you can't do with the graph is send raw transaction it's also very ethereum specific where I think the graph is trying to create more of an overarching chain for index data um so I imagine that if you make it more queryable than either you've rearranged the data or you've duplicated the data and can you just talk about does this increase the size of the data on the disk for the node and is it optional or is it something that would be built into every client has lots unpacked so it doesn't really affect the storage of data on the node what is doing is moving the aggregation of all these calls on the node so there's no increase in data size it's just more of how its accessed in packaged before returning it to the to the user you know comparing it to JSON RPC you have to do it through separate calls graph QL is sort of taking those calls and wrapping it up in one one transaction or one interaction second part of your question so I can you it is optional yeah so the the EIP that we're putting we're trying to get put into all of the clients currently supported by death but we're trying to get into parity and Pantheon as well it is an option flag so the way that it's implemented in Gath much like the RPC the JSON RPC you have the RPC flag there's a graph QL flag that you can use to enact it hi thanks for his talk so do you have support for efficiently querying historical aggregated data for accounts or for contracts by aggregated you mean like indexed like specifically indexed or yeah so if I want to query like the entire transaction history for an account or for a contract I expect that to be pretty heavy computationally because it would need to run through the entire chain up to date it would be there so right now indexing is definitely something that we're looking into building in right now it would look more like sort of a chain scan or a block scan where you're trying to filter down the return data on those particular contracts that you're interested in but you would still have to scan the blocks to do it well thank you very much [Applause]