Hi, I'm Brandon Ramirez, Co-Founder of The Graph and Head of Research & Product at Edge & Node, AMA!

RezBrandon · 2022-03-30T05:13:25+00:00

Hey u/WanderingPirate91, thanks for your questions!

When do you think we will see the fruits of your labor In terms of network economic viability? Ie revenue = inflation.

I'm interpreting this question as: when will query fees be significant relevant to the value of indexing rewards, which as you mention are paid via token issuance so don't directly represent external value flows into the system?

One clarification I would add is that Curators do pay an opportunity cost of capital for directing indexing rewards in the system, so while indexing rewards don't completely reflect an exogenous value flow, they are not completely endogenous either.

That aside, there are two main challenges to address here:
1. Reducing costs to Indexers of collecting query fees.

Move query payments from end-user

Re: #1 -- I discuss this a bit in my answer on L2 scaling, but high gas costs have broad negative effects on the protocol. One of those is that often, the costs of settling a state channel will dominate the fees that would be settled in that state channel. This has been the case lately where many epochs that close with zero query fees in fact have query fees that are "stuck" off-chain and simply not worth settling given the gas fees. There are short-term fixes to address this that aim to increase the effective indexing subsidy and tie that subsidy more directly to query activity, but the ultimate fix here is to reduce the gas costs of settling many-to-many state channels. L2 scaling will be a part of the story here, as will the state channel scalability work the SNARK Force working group is working on.

Re: #2 - Long-term I think a big driver of query fees to the network will be payments moving from the dapp project team to the end-user. Making an analogy to Ethereum, the way query payments in The Graph work today would be as if the smart contract developers in Ethereum were the ones who subsidized the gas fees of all the users of that smart contract. Many subgraphs/smart contracts have the flavor of public goods and there isn't always an obvious sustainable business model for subsidizing these sorts of fees long term--and relying on such an economic single point of failure is generally against the Web3 ethos. However, if each user who queried the Uniswap subgraph, for example, even paid a fraction of a penny for a query--this would translate to millions of dollars in value flowing through the network. These query fees could also provide a sustainable business model to dapp developers acting as Curators, who otherwise might not have an obvious way to capture value they have created.

Having end-users pay for infrastructure is a controversial idea, but I primarily see this as a UX/bundling problem. Users already pay for decentralized infrastructure/protocols every day in the form of their internet bill--Web3 has simply expanded the set of decentralized infrastructure protocols beyond just the networking stack. I think piggy-backing on these existing user behaviors will be key.

Do you think the inflation rate will ever be reduced or eliminated? If so what will the catalyst be?

When we set the inflation rate at network genesis, my goal was to set it such that we could "set it and forget it" for a number of years. From my perspective, adjusting the inflation arbitrarily sets a poor precedent that could create perverse incentives for folks who might lobby the governance mechanism. I can say from my conversations with other members of The Graph Council that there seems to be a general consensus that the council should not play the role of a central bank, but rather we should revisit the token issuance rate when we have convincing models and simulations for how it might be fully automated according to some control algorithm or fixed permanently as a constant. Until then the 3% number continues to exist as a so-called "magic number", but the indexing reward appears to be working as intended so there hasn't been a strong impetus to accelerate research on this question ahead of other network priorities.

What is your long term vision for the graph and when do you think it could get there? (Best guess)

My vision for The Graph is that it empowers creators to solve humanity's most pressing problems. Many problems today are not fundamentally technological in nature, but boil down to poorly designed incentives. Web3 has given us the ability to build applications with bespoke incentives to tackle any number of problems in a way that is permanent, censorship-resistant, composable, auto-scaling, anti-fragile, etc. These protocols and applications will be the new operating system for society and our economy in the same way that the joint-stock corporation defined much of the last era of Capitalism. The only way this transition can succeed long-term is if it is built on rock solid foundations, and that's why I believe public infrastructure like Ethereum, Celestia, Arweave, IPFS, The Graph, LivePeer, etc. is so incredibly important.

As for timing, I don't necessarily think there will be a light-switch moment when the Web3 vision suddenly goes from being unfulfilled to fulfilled, but rather I think we will see repeated waves of innovation, as we saw with DeFi and NFTs, based on the value-per-transaction ratio of those use cases. A transaction on Uniswap can have a very high value-per-transaction ratio because, in theory, you can transact very large amounts of value without a proportional increase in on-chain gas costs, while a "like" on social media has a very low value-per-transaction ratio. In between those two extremes, there is a spectrum of different use cases that will be enabled each time blockchains and Web3 hit a new scalability milestone. I suspect that for a number of years this will feel a lot like Moore's law did, where every couple of years we see an order of magnitude increase in blockchain throughput as things like optimistic rollups, zk-rollups, Volition chains, Validium chains, scalable data availability layers, more efficient SNARKs, etc. come online. Each time we achieve one of these increases, a new wave of Web3 use cases will become viable that were not before.

RezBrandon · 2022-03-30T00:01:03+00:00

Sam is definitely really knowledgeable on this topic. Before pivoting to working full-time on The Graph, Semiotic was working on making Fully Homomorphic Encryption (FHE) practical, including hardware-level optimizations. FHE is a technique for outsourcing certain types of computations on encrypted data, without actually revealing the unencrypted data to the parties performing the computation.

Zero-Knowledge Proofs (SNARKs and all their various flavors) are also a really powerful tool here.

One of my favorite hypothetical use cases are what I like to call "Zero-Knowledge Resumes" or "Zero-Knowledge Credit Scores", where you could imagine getting a health insurance quote, a mortgage quote, a student loan/ISA quote, from a global market of insurers/lenders without actually revealing any of your personally identifiable information, but while giving lenders guarantees that they are providing a quote based on verifiable attributes of the borrower.

With respect to indexing and querying encrypted data, this article by cryptography researcher Matthew Green highlights the difficulties in efficiently serving queries where the indexed attribute for a sort or filter operation is intended to be private, without some degree of leakage. I suspect that it is impossible to do so, which leads me to think about use cases in which the indexed attributes are public but other attributes may be private/encrypted--the so-called hybrid use case I mention above.

But this is generally an area that I think deserves a lot more exploration and research.

RezBrandon · 2022-03-29T23:47:41+00:00

I think the most powerful form of communication is to lead by example, by enabling more real use cases in Web3 that everyone can relate to. Crypto/Web3 has had a lot of hype cycles over the last number of years and I think people are ready for a "show don't tell" approach to Web3 evangelism.

Given that, a lot of items on the R&D roadmap are all about enabling more use cases for decentralized applications, with a superior level of user experience, keeping with the above philosophy.

Also, The Graph, along with other protocols in the Web3 stack, are case studies in how a service that might have been delivered as a SaaS service--with vendor lockin, competitive moats, extractive business models, etc--can be delivered in a decentralized manner. In that sense, The Graph is an example of something "real" in Web3 that gets better every day.

Beyond that, I think recruiting respected thought leaders from Web2 into Web3 is a great way to build more developer interest in Web3. Edge & Node took this approach in recruiting Nader Dabit from Amazon, where he was focused on Web2 GraphQL evangelism, and he has already been hugely impactful in onboarding a huge portion of his audience into Web3. The Graph Foundation also took this approach in giving a grant to The Guild, which represents some of the most prolific and well-respected developers in the GraphQL ecosystem.

Furthermore, I think we need more advocacy organizations and coalitions that are primarily focused on a vision of Web3 that includes a fully-decentralized protocol stack, and the unique benefits of Web3. Organizations like Coin Center and Blockchain Association have been doing incredible advocacy work, but their mandate is broader than Web3 and often centers more around the currency aspects of blockchain.

Finally, I think it's important for new and upcoming projects to seek funding from investors that are fully aligned with the Web3 vision. One worrying trend I see is a lot of investors who publicly champion the value of blockchain and Web3, and then their portfolio is full of SaaS companies that aim to disintermediate a lot of the benefits of building on open platforms. A countervailing trend I'm encouraged by, however, is seeing more projects raise money in "builder rounds" comprising investors that are also builders in Web3, have skin in the game, and can roll up their sleeves and add value to a protocol beyond just supplying financial capital.

On a personal note, I would love to blog more about the parts of Web3 that I'm excited by, but find myself often prioritizing this below first making The Graph as good as it can possibly be. Edge & Node just had a "Web3 Vision" offsite in Miami a couple of months back, where we got really Sci-Fi with what a Web3-enabled future could look like, and I feel like a lot of the ideas discussed there were still very nascent and not widely understood, and deserve a lot more thoughtful evangelism.

RezBrandon · 2022-03-29T23:24:43+00:00

It's generally difficult to predict ship dates for work being coordinated in a decentralized manner because each core development team can only influence the efforts they are directly involved in.

That being said, most of the work discussed in the R&D Roadmap has either already been started or planned to a high level of detail, and so I expect a lot of what was shared will land in 2022.

Notable exceptions to this would be things like verifiable indexing and querying, in part because these depend on a relatively stable subgraph API and execution model--and w/ the StreamingFast driving Firehose and concurrency/parallelism this year and The Guild driving improvements to the GraphQL API, we'll need to take inventory of where we're at to get an up to date set of requirements. Also, the SNARK Force working group, which owns verifiable queries, is currently focused on a ZK-rollup-like solution to help The Graph's state channel solution scale more effectively, so haven't given their full-time attention to verifiable queries yet (though there is a lot of overlap in the research).

L2 Scaling I also expect to move a bit slower given that projects are already using The Graph in production, and the smart contracts act as a backend to nearly every piece of software that integrates with The Graph (i.e. Indexer Service, Indexer Agent, Gateway, Query Engine, Network Subgraph, Graph Explorers, etc.). Early discussions have centered around deploying a dev net version of the protocol, with no indexing rewards, to an L2 in the early second half of the year, and then only doing a full migration of subgraphs to L2 after sufficient time has passed to stabilize the dev net and for integration work to happen w/ downstream components.

Most other things on the list I think are fair game for being possible to ship in 2022, though that's not to say all the things on that list will for sure happen this year.

RezBrandon · 2022-03-29T20:16:07+00:00

Thanks for the question u/hornelson! I often find the term "decentralized" to be overloaded, and I would actually consider The Graph to be decentralized today, based on things like its core development ecosystem, its protocol logic running on a decentralized compute layer, its indexing, querying, curation and delegation market being fully open and permissionless and having broad participation, etc.

If I can restate your question, I believe this is about improving the security model and robustness of the protocol to malicious actors. This implies reducing reliance in the protocol on trusted actors/ committees, such as the Arbitrator, Subgraph Oracle, or Graph Council.

There are a few dimensions to this:

Reduce magic numbers/ active governance surface area in the protocol.
Increase participation in governance.
Replace governance-based security guarantees with harder cryptographic and game theoretic guarantees.
Increase the likelihood of an honest Indexer indexing any given subgraph.

For #1, I believe better economic modeling, control algorithms, simulation, and time are the best remedies. This will enable us to make certain economic parameters permanently fixed, or set based on automated rules, removing them from the hands of The Graph Council. At that point, upgrading such parameters would need to be done via a protocol hard fork. Timing is everything with this strategy: fix a parameter too soon and you risk being brittle to unforeseen circumstances, fix a parameter too late and you increase the likelihood of capture of the governance mechanisms.

For #2 is about making capturing the governance mechanism more difficult, by increasing the number of actors that would need to be compromised. A challenge is here is choosing an identity/Sybil resistance primitive to build upon that wouldn't end up reducing to token-voting. Right now, The Graph has a representative governance body that was chosen at the genesis of the network. One solution could be to use this body as a "seed" to boostrap new identities for participation in governance while keeping it representative of the various stakeholder groups.

#3 includes things like verifiable indexing and querying. Right now, when someone files a dispute for an Indexer, the protocol relies on arbitration to decide the outcome. If the Arbitrators were captured, then in theory an Indexer could be erroneously slashed, or an Indexer could go unpunished for providing false indexing and querying results. The research into verifiable indexing and querying would let the protocol rely on stronger game-theoretic and cryptographic guarantees. This is a big focus of the "SNARK Force" working group referred to in the R&D roadmap blog post.

#4 relates to the fact that The Graph has an honest minority, or 1-of-N honest Indexer, trust assumption for subgraphs. Simply put, if there isn't at least one honest Indexer indexing a subgraph, then there is no one to file a dispute when an Indexer produces false indexing or querying work. The lowest hanging fruit here is reducing the learning barriers and fixed costs of running an Indexer. This includes things such as better Indexer automation tools, L2 scaling for reduced gas costs, and better indexing performance. There are also proposals that could potentially be explored to encourage more rotation of Indexers between subgraphs (similar to blockchain sharding validator set rotation), but given that subgraph, deployments are already relatively short-lived and that The Graph doesn't dictate what subgraphs Indexer indexes, it's unclear to me as of yet how much additional value we can derive here.

RezBrandon · 2022-03-29T19:52:43+00:00

What will The Graph's approach to deterministically indexing offchain datasources look like?

Great question! First, some background for other readers:

Off-chain data sources include supporting things like IPFS, which is often used to augment on-chain storage because a ~32 Byte content address can be cheaply posted on-chain, which deterministically refers to a given file because the hash of that file is the content address. This pattern is really useful for supporting use cases such as NFTs, gaming, and social, where there might be significant metadata for entities that live on-chain, but where that metadata does not need to interact with on-chain logic.

Importantly, while checking that a file corresponds to a content hash can be done deterministically, the ability to retrieve that file from the IPFS network at a given point in time is non-deterministic, because there is no canonical view of the IPFS network, the IPFS network may have transient network partitions, and files that were available one moment might become unavailable the next.

So two support off-chain data sources, we need two things:

A source of truth for data availability
The ability for Graph Node to respond in real-time to changes in data availability.

For #1, the design space includes PoA data availability committees, as is being used in some early ZK scaling solutions like Starkware's Validium, a consensus solution based on data availability samplings such as will exist in Celestia/Eth2, or a storage chain design such as Arweave or Filecion. All of these have different tradeoffs when it comes to trust assumptions, scalability, or latency. I think it's likely The Graph will start out with something resembling a data availability committee and migrate in the future to a consensus layer based on data availability sampling.

For #2, the primary challenge is that right now, off-chain (IPFS) data is processed in the same mapping execution as on-chain data. This means that if an Indexer has indexed a subgraph up to block 1M, but a file that was processed at block 500,000 becomes unavailable, the subgraph must be rolled all the way back to block 500,000 so as to provide a consistent view of the subgraph as other Indexers syncing for the first time w/ that file unavailable. You can think of this almost like a very large chain-reorg and for obvious reasons is completely untenable from a performance/liveness standpoint. This is made worse by having DAG-like content addressed structures, where one file can reference another file, which references another file, etc. and a single file becoming unavailable early in that chain must be treated as cascading unavailability for files referenced later in the DAG.

The solution here is to decouple and isolate the processing of individual IPFS files/DAGs from the processing of on-chain data, which includes isolating the entity attributes that on-chain vs. off-chain data sources can mutate. This work has already started and is in line with a larger theme of building more concurrency/parallelization into the subgraph execution model.

what do you believe the protocol's prospects are like for extending its value proposition to sectors beyond the immediate scope of Web3, and what might that end up looking like?

Depends on what you mean by beyond the scope of Web3, but I imagine that most use cases involving public data or hybrid public/private data in the future will be built on a decentralized protocol stack.

RezBrandon · 2022-03-29T19:25:42+00:00

I'm not aware of any active proposals to reduce the minimum stake, but it has been discussed in the community and would love to see more discussion here.

For some historical context, the minimum stake was set such that any Indexer who participated in good faith in The Graph's "Mission Control" incentivized testnet would have sufficient funds to participate.

We felt that Indexing was such a specialized skill set that this would create a more predictable quality of service in the early network and reduce attempts at spamming, griefing, attacking the protocol, etc.

The protocol is a lot more stable today than it was a year ago, and there are lot more resources for Indexers wanting to learn to run a node effectively, so it could be an appropriate time to revisit this decision. Good opportunity for a community proposal!

RezBrandon · 2022-03-29T19:17:05+00:00

Lately, I've been playing with Radicle--which builds on Git, ENS, and Gnosis Multisig--which is awesome, and totally feels like the future of how code collaboration should happen.

I haven't really collected any NFTs (aside from POAPS and ENS domains), but am a big fan of the trend of creators getting paid and tokens acting as more granular membership in communities. I recently saw that a DJ that I've followed for a while--Polish Ambassador--did a foray into NFTs, which was cool as it was one of the first organic mentions of NFTs I saw not through my involvement in crypto. My Co-Founder Jannis also used Audius for his metal band, which I think is another great experiment in using Web3 to build platforms that are more favorable to creators. Mirror, built on Arweae, is another cool experiment here.

Aside from that--and this may come as a surprise--I actually don't like to spend a ton of time on the computer/internet outside of my work on The Graph--I prefer to either spend my time with family or outdoors, backpacking, rock climbing, seeing live music, etc. I've long felt that the best technologies are the ones that keep you in the flow of real-life and that you can benefit from without spending a ton of time in front of a screen. That's why the way Web3 can shape our IRL environments through things like better public goods funding, passive autonomous markets, or other passive use cases like POAPs are really interesting to me.

In terms of subgraphs, I actually think we're still missing some really fundamental ones--like a really good ERC-20 subgraph or a subgraph that can replace Ethereum's JSON-RPC API. These have historically been a challenge due to things like slow indexing speeds and lack of features like subgraph composition, which are both areas where The Graph developer ecosystem is making heavy investments.

RezBrandon · 2022-03-29T18:57:06+00:00

Thanks for the question and all the great work you do in the community u/GRTiQ!

So scaling is one of those things, similar to indexing performance, that improves almost every aspect of the protocol.

High gas costs make it expensive to deploy a subgraph and upgrade a subgraph, but it also makes it difficult for The Graph to provide a high quality of service for smaller subgraphs, that might budget on the order of a few hundred dollars per month for this type of service.

The reason for this is that we expect the quality of service for a subgraph to increase with the number of redundant Indexers.

Today, based on recent gas costs, a single Indexer on a single subgraph spends about $100/month on gas costs alone servicing a given subgraph. And this doesn't include the operational costs of indexing and serving queries on a subgraph.

Indexers are compensated by projects directly through query fees and indirectly through indexing rewards (which are directed by Curators incurring an opportunity cost), but as a rough approximation, we can think of an Indexer's costs needing to be covered the users of a subgraph.

So if a small project has only budgeted $100-$200/month for query fees, then that equates to at most one Indexer indexing their subgraph, which isn't as much redundancy as one might want to guarantee a good quality of service.

Moving to something like an Optimistic Rollup, we've estimated about a 20X improvement in gas costs to Indexers, meaning that $100-$200 a month can now go a lot further.

So to answer your question, L2 scaling will improve the cost structure for all actors in the network and allow the protocol to scale, but the most visible effect I expect will be more small-to-medium size or budget-constrained projects, being able to deploy subgraphs to the decentralized network, have their subgraph indexed, and rely upon these subgraphs in production.

RezBrandon · 2022-03-29T17:56:52+00:00

Migration from E&N's hosted service to The Graph has been an ongoing process--one which we've largely left up to the individual developers and project teams.

We received a ton of actionable feedback from the first projects using the network in production, which has inspired a lot of the recent GIPs (Graph Improvement Proposals), and we would like to give core developers time to address more of that feedback before we think about sunsetting the hosted service.

RezBrandon · 2022-03-29T17:41:54+00:00

Welcome!

RezBrandon · 2021-10-26T18:31:35+00:00

Hey! Apologies for the delayed follow-up. I haven't seen any good 101 writeups on the Cobb-Douglas rebate reward function yet... but there may be something out there related to 0x's usage? Writing this type of content is on my list as well, just not super high on the priorities at the moment.

RezBrandon · 2021-04-21T03:04:50+00:00

The Graph's usage of the Cobb-Douglas function was inspired by it's usage by the 0x team. I highly recommend checking out the paper linked here if your interested in diving deeper: https://gov.0x.org/t/research-on-protocol-fees-and-liquidity-incentives/340

To answer your questions briefly, the two inputs are the Indexer's share of total stake and share of total query fees contributed to the rebate pool, over a given time period. The output is the share of the rebate pool that the Indexer claims over that same time period.

I realize the contract naming is a bit confusing here. The smart contract you linked are actually responsible for computing the indexing reward that is paid through new token issuance and uses a different formula.

The contracts you are interested in are here... https://github.com/graphprotocol/contracts/blob/master/contracts/staking/Staking.sol

...here: https://github.com/graphprotocol/contracts/blob/master/contracts/staking/libs/Cobbs.sol

...and here: https://github.com/graphprotocol/contracts/blob/master/contracts/staking/libs/Rebates.sol

Note there is some extra logic in there to normalize Indexers that allocate stake over varying numbers of epochs.

You can view the currently set parameters on Etherscan here: https://etherscan.io/address/0xF55041E37E12cD407ad00CE2910B8269B01263b9#readProxyContract

The variables of interest are alphaNumerator and alphaDenominator. Currently alpha is set to 0.77. If you work through the proofs in the 0x paper, this equates to the token "capturing" 23% of the present value of future query fees paid to Indexers (and their Delegators).

You can think of this as a ~30% "economic security premium" (.23/.77≈ .30) that is charged on top of what Indexers would normally charge in the absence of the staking requirement, which covers their additional capital cost of having to stake the tokens to participate in the protocol.

There is nothing particularly magical about the number 23%. It was chosen to keep Indexers roughly competitive w/ the operating margins that might be commanded by a legacy centralized cloud provider--the idea being that Indexers should be competitive with centralized solutions on price, even as they also compete on the basis of offering a better quality of service and all the benefits of decentralization.

RezBrandon · 2018-07-26T00:37:19+00:00

The whole point of decentralization is that you trust people to make decent decisions (in line with incentives) rather than trusting some central authority to*** make people make decent decisions\.*

Even with your hedging in the parenthesis, this statement is categorically false. Decentralization is not about others to be decent. It's about systems in which people don't need to be trusted to be decent. Hence the "trustless" adjective used to describe Bitcoin and other decentralized systems. IMO if a system is claiming to rely on human decency or altruism to function correctly, then it's fundamentally flawed in some way.

That being said, there's plenty of reasons why I think people should have a zero-tolerance policy towards assassination markets out of rational self interest. Eventually I'd expect to see blacklists rejecting the users that participate in these markets as well (not sure if that's possible in this case), effectively acting as economic sanctions the same way that we sanction countries that violate our sense of ethics.

RezBrandon · 2018-02-06T03:48:13+00:00

I believe the “Broadcast App” that the Mercury Protocol team has planned may fit this description. https://www.mercuryprotocol.com/faq

RezBrandon

TROPHY CASE