As concepts for blockchain-based projects grow more far-fetched and fantastic by the week, it’s Consensys spoke INFURA — founded by Herman Junge, E.G. Galano, Maurycy Pietrzak, and Michael Wuehler — that has established itself as the industry leader in addressing the very real, but rarely discussed infrastructural challenges posed by the growing pains of the Ethereum network and its current launch-heavy calendar.

INFURA is a service that helps token sales and decentralized apps handle the influx of read-activity traffic that comes hand-in-hand with a successful token launch or running a decentralized application on the Ethereum world computer. Although an immensely important aspect of the Ethereum protocol, read-only requests are underserved in terms of infrastructural support, and this has already shown to be highly problematic. In finding solutions for the mercurial traffic patterns that play out on the Ethereum network every day, INFURA is positioning its service and technology as an essential consideration when launching a token or engaging with the network en masse.

We spoke with INFURA founder Michael Wuehler about infrastructure, nodes, and the ethics of token launch infrastructure demands…

You’ve referred to INFURA solving the ‘other scaling debate.’ What does that mean?

When discussing the scaling of Ethereum, most people usually gravitate to thinking about transactions per second, which is the theoretical limit of the Ethereum protocol to process transactions during any second. It’s currently only able to do about 20 transactions per second. VISA can do 400,000 a second, for example. If you think of the Ethereum blockchain as a database: The kinds of transactions I just discussed are “writes” onto the database, inputting data to the blockchain for example through a call to an Ethereum smart contract. That’s not the problem that INFURA solves. That problem is being researched and solved by some very smart people — Vitalik Buterin, Vlad Zamfir, Karl Floersch and others at the Ethereum Foundation.

The problem that INFURA addresses is “read” activity, which is the other side of the equation. Most database activity through a typical web interface application is reading. The example I like to use: If you open up Facebook on your phone. Every little bit of data you see is read from the database. Every once in a while, you may hit the ‘Like’ button, and that’s a write-activity. Similarly to traditional databases, read activities far outweigh the write activity on the Ethereum blockchain. The Ethereum blockchain can currently handle up to half a million write activities per day, but as part of our work at INFURA, we’ve seen read activity currently at 1.7 billion read requests a day. This can be anything from a dApp looking up some piece of data, similar to a block explorer, or someone checking out Etherdelta via Metamask.

Traffic throughINFURA from August — November 2017.

What’s the problem with how read activity is handled on the Ethereum network now?

An individual Ethereum client or node has its own capacity to handle incoming requests. The way it is currently done is that most of those requests get transacted through what’s called the JSON-RPC API Service. You send a request to the endpoint and the client that gets that request will read into its chain data and serve the answer back. In an instance like an token launch, they do reach capacity, and nodes can get overloaded, slowing down the whole network. Worse, there are denial of service attacks — for example, if some malicious actor wanted to cripple a single node, they could overload it with read requests, degrading service on the node for twenty minutes while it runs that query.

At INFURA, we’re scaling horizontally. We support a large cloud of Ethereum clients that distribute incoming requests across our network of many nodes, filtering and diffusing traffic to a number of shared nodes that can handle the load. Using a current web analogy: INFURA is like Cloudflare or Akamai that helps to scale for short periods of time when you have a huge burst of traffic. Further, we’ve written lots of software — much of which is our primary value proposition — that ensures that node overload and DDoS attacks are minimized.

How do token sales play a role in all of this?

During a token launch, what happens is that there’s a specific time or block that the sale opens. At that point, thousands of people all rush to the launch site to buy their tokens. There’s a crush of traffic that often slows down the network as a whole and causes major problems for the entire worldwide community. One launch page is usually making several hundred read requests per second per user to Ethereum. Multiply that by 10,000 people who show up, and all of the sudden, you’re getting millions of requests to the blockchain. There are many token sales happening at any one time, and that’s what’s contributing to our 1.7 billion or so requests a day. The infrastructural demands of raising a $20 million crowd sale are not free. Many of the new project teams think you only need a developer and URL to make a bunch of money, but there’s a missing constant that nobody takes into account and that’s infrastructure.

Can you explain how your partnerships with token launches function?

We recently worked with the 0x Project when they were planning their token launch. 0x is an example of a great team, willing to partner and work together for a smooth experience for their users and investors. We assessed their needs and built out additional capacity that we were able to dedicate to them. Their launch proceeded really smoothly. In fact, they even wrote a blog post about it — “Talk to INFURA, Really” was their recommendation. RadarRelay also has been a great partner for their token launch. They told us that they tried to build out their own infrastructure, spun up lots of different nodes, and had to dedicate somebody to manage them, which represents real expenses that they ultimately were able to offload to INFURA.

Michael Wuehler introduces INFURA at FinTech Week 2017

How do you see this playing out long-term?

Right now, everybody uses us as a shared service. Over time, we’ll be a paid service, a scaled infrastructure available and ready to use with nodes all over the world. Long-term, dApps and projects will likely see the value of a service like INFURA to be the gateway to the Ethereum blockchain. Right now, INFURA is the only service offering this. My personal feeling is that the legitimate teams will understand and appreciate this. It’s the scam teams that may ignore it. Seeing how a project addresses their scaling needs and their responsibility to the global community by not clogging up the network will be an indicator of their legitimacy. Eventually, when the projects actually build what they’re claiming they will, and there are more applications and solutions than simply launches, the scaling needs aren’t going to change. We’re going to continue to try to scale, but we’re also trying to come up with the right economic model.

With this in mind, do you think token launches have a moral or ethical responsibility to manage the stress they put on the infrastructure?

Absolutely. That’s one of the misconceptions that got out there with Ethereum — that the network is free to use. There are real costs and consequences to using the network, and there are things everyone should be doing to optimize code and arranging for having the right infrastructure for user experience and the community as a whole. When a team is planning their launch, they’ll have to consider planning their infrastructure in addition to writing smart contracts, designing tokens, creating legal entities. Right now, there are a lot of frustrated users, but not a lot of accountability once teams have gotten their money. INFURA is a way to be accountable.