DAPPCON 2018: INFURA: Bridging the Gap from Web 2.0 to Web 3.0 - Maurycy Pietrzak (Infura)

Transcript

so my name is Maurice I'm a co-founder if you're looking at the schedule and see a different name that's my co-founder who couldn't be here today on the technical side I focus on back in software that supports our infrastructure and helps us scale so what is in fira in Fears mission is to provide access to aetherium and the decentralized web for two years we've been providing an easy fast way to access aetherium with a full time staff to maintain the infrastructure 24/7 which is not easy and yeah we've been around since 2016 we provide endpoints

to access main net and the three major test nets using the JSON RPC interface and we also provide endpoints for ipfs for decentralized storage as well as other endpoints for things like pricing data etc another feature we love is a restful api which feels a lot like the JSON RPC api but uses HTTP GET instead of post for several methods where this makes sense so this lets us use a CDN to cache some data so methods such as f get blocked by number and get blocked by hash are very snappy the CDN is one of the things that helps us scale if you're

using the standard JSON RPC a is important to you go ahead and use the regular endpoints otherwise use the restful endpoints for speed and there are plenty libraries out there that use in fura and even if they don't specifically use in fira you can easily configure them to use these endpoints which you can see here we do get a lot of traffic these days we serve about eight billion requests per day which is about 90,000 requests per second and in terms of transactions we average about say 12% of the transactions that get relayed to the network just if you're

curious we use AWS for infrastructure and our CDN is fastly so today I'd like to go over two or three things that we've been thinking a lot about and some directions where we're thinking of taking our project so let's start by talking about decentralization this sometimes comes up when people talk about in fear so let's address it when in furor was founded in 2016 we were very much aware of the decentralization arguments some of us on the project are aetherium OGIS and were we've been involved with decentralization or

decentralized projects since before aetherium was a twinkle in vitalik sigh so we're very sensitive to these arguments in fira also went through a number of internal reviews inside consensus and the topic came up but we felt that the benefit of in fury to the community was worth it and I think we've been correct about that for example we'd like to take a little bit of credit for the bull market of 2017 we weren't quite as visible back then but many even most I think I SEOs relied on in fira so we had Gollum bat EOS gnosis how these guys did very well

using using our service and the interest that was generated in the ecosystem as a result of these successful ICS has been very good for the entire ecosystem so imagine last year if in fira had not been around or imagine if we had decided to do something silly like charge users regular user regular investors for access to the network so at the same time that these I SEOs were happening in early 2017 you know we started thinking about we

started becoming concerned about the problems of incentivizing participation in the network and network access and we created an internal project inside in fear are called INFP where we're exploring some ideas to address these pretty tricky problems so let's talk about incentivization so some people think that incentivization will help get people running full nodes so assume we have some sort of market-based mechanism to incentivize nodes but for a second let's ignore a couple inconvenient

variables let's ignore the fact that the cost to run a node is different for different people you could be running your node on your laptop or in the clouds different clouds have different specs for their VMs and charge different prices your configuration options affect how many resources your client uses but let's ignore all that for a second so the first thing to note is that you'll never be able to make money running a full node with with this incentivisation scheme even if the price adjusts why because as soon as its profitable to run a node as soon as you can you know pay $100 for a digitalocean

droplet and make a little more than that with this scheme the people who are good at running nodes the medium and the large players will simply spin out more nodes they're good at they have the tooling they have the automation and they're going to drive the price back down to at least you know zero at least so it's a wash for you so the only remaining options are it's gonna be a wash or you're gonna lose money maybe you'll recover some of your costs but not all it's just my gut but I suspect that this market mechanism would

never be able to fully cover your cause so it wouldn't even be a wash you'd be losing at least a little bit of money I think there would be some always some sort of behavior in the network that would push the price in such a way that you jet you just wouldn't wouldn't recover everything but we need to run some simulations to test this it's mine it's just a gut feeling right now but here's the worst thing I think even if you were able to recover all your costs that's not enough I think people in this day and age expect the app experience to be a certain way we have our phones that

sort of sets the standard and people just don't want to install anything else besides that it's just too much work it's just as much of a disincentive as the monetary cost is and that's a problem what do we do about this I don't know long-term skipping ahead I think what's gonna happen is we're gonna have like clients on people's computers we're gonna have like clients servers that are incentivized to provide data to the like clients and entities such as in fear I could host the like client servers and you know recover recover our

costs this would solve several problems not all of them it would solve the problem of trust because now instead of trusting the JSON RPC interface there's a protocol to ensure that the data is trusted it partially solve the problem of decentralization because there would be other players running these like client servers it would partially solve the problem of UX but it wouldn't fix everything definitely not everything but it would certainly be an improvement from what we have today but I'm still not sure how we're gonna get to this partial Nirvana the good news is this year there's been

a lot more interest in this problem we're happy that it's getting more attention and we've been engaging with some people in the ecosystem who are also thinking about the stuff we're talking to a guy named Andre who's running a project called VIP note he's attacking the like client-server angle there's a project called DAP node from rift Green and his team of merry men who's trying to decentralize in fira there's a project called D node that came out of earth way no Syrus which was also trying to decentralize in fira I don't have too much info on them but I did hear about them and there is an e IP

to reward clients and full nodes for validating transactions so all these people are in the space they're trying to figure this out and yeah we're working with some of them so if you'd like to collaborate on incentivizing full nodes or decentralizing in fira please reach out to us we'll probably talk a bit more about our infp work at DEFCON in a few months and that's assuming we can get tickets to DEFCON ii in the meantime i hope you'll think of in fira as bridging the gap as supporting the ecosystem until we have

all these things figured out because i think the service is pretty valuable in comparing it or the theorem to other blockchains I think having in fira has has been very helpful so another topic that's on our minds when we started in fira we had hoped that we could treat the theorem client as a black box that we could put some scaffolding around it and it would just work but we were quickly disabused of that notion the Geffen parody teams do a great job of building these clients that support the entire network but when we run them at scale in the cloud it's something that they weren't designed to

do and we run into a few issues so for example in the abstract you know that a blog chain is synchronized across the entire network but as we know near the tip of the chain things get a little dicey there's blog propagation issues there's reorg that sort of thing if you put the clients behind a load balancer which we do it's as if you were running with multiple databases in the back especially near the tip of the chain so it's important to make it seem as though there's a single database containing all the blockchain data second another issue is running all these clients in our

cluster is a bit wasteful because for example they each use a lot of disk space they each talk to the peer-to-peer network and and are sending all this data which is sort of redundant so I remember when our AWS account would hit limits because of our disk usage because this type of stuff you put into AWS normally doesn't use so much disk if we run of death with all the bells and whistles it's close to a terabyte for each instance that we run so I think the solution to this problem is to have a client that's meant for the cloud from the ground up our thinking is if you can

implement a client as a set of micro services you can scale each micro service independently and it would work a lot better in that environment so you can have a micro service for downloading blocks you could have another one for the transaction pool another one for the EVM it's so I think this would result in a client that's very robust and scalable and it would look exactly like gas running on your local host so we have been doing some work around this we're collaborating with other people who are thinking along the same lines for example the Pegasus team has a client in the works called Pantheon which is

supposed to be modular and enterprise-grade maybe we'll use some of their stuff and if we include any additional code and it makes sense to open-source it or if we write any additional code we'll open source it if it makes sense and again we're happy to collaborate with anyone who's doing work in this area so that's the cloud client last thing I want to give you a sneak peek at a cool project called SQL which is graph QL for aetherium it was created by Raoul Kripalani from the Pegasus team and the two of us did a workshop on it earlier today graph QL is a flexible powerful

query language and when you combined it with etherium you get fql it could be a new way to interface with the theorem and let me give you an example of what this looks like so on the left bottom side you can see a query and graph QL on the right bottom side you can see the response so here we're asking for a range of blocks five blocks and we're extracting different pieces from the response we want the hash from the transactions we want the address and the balance of the sender and we want the value and the result looks like this and

it's awesome you're not wasting all this bandwidth moving data that people don't care about and that results and look at the space saving so 80% space savings but the real kicker is the queries so to do this query in regular JSON RPC would take eight eighteen hundred calls which is insane so this is awesome it's great I will officially announce the Alpha today so check it out yeah so I think I if there's enough interest in this I think it would be great if we could if it could become a new standard eventually

in aetherium and we could deprecated json-rpc so yeah those are three of the things that are on our minds any questions