Hi flynn,
Funny you made this thread, as I was thinking of making something similar just yesterday. I figure this can be a good place to throw down my thoughts on the matter, particularly in the context of The Graph’s current design.
Note: I am not a member of the development team for The Graph, so everything here is somewhat speculative and may not be totally indicative of the true situation that the core protocol faces.
Primary Issue(s) with L2 Expansion
It seems apparent to me that the L2 expansion faces difficulty (but not impossible) due to 2 primary factors:
- The dependence of The Graph’s different protocol branches with each other.
- The inherent security design of Optimistic rollups which lead to issues with finality & atomicity.
To expand on both of these:
The dependence of The Graph’s different protocol branches with each other
As far as I can tell, most (yet not all) of The Graph’s components are not segregated from one another, but rather use each other to be able to perform their own actions. For example, the GNS contract relies on the curation contract (and it’s associated state), the curation contract relies on the state of the rewards contract, and the rewards contract relies on the staking contract, as a couple of examples. This appears to be intentional by design, because quite frankly, that’s how our network operates. The interaction between network branches (curation, indexing, delegation, etc) is what drives the cryptoeconomic incentive model that The Graph inherently thrives on. In my opinion, it’s a necessity.
The evident primary issue here is that it’s difficult (but not impossible) to segment pieces of the protocol due to this operational dependency. If only the “curation” contract functions are migrated to an L2, it becomes increasingly difficult to understand the total state of the network, as now the network state is divided amongst 2 separate “chains”. In other words, using curation on an Optimistic Rollup like Arbitrum means that a more complicated mechanism must be set in place to ensure that the state of the Ethereum mainnet matches that of Arbitrum, and vice-versa. However, this doesn’t mean it’s impossible- this is an inherent complication with L2’s (interoperability), and it attempting to be remediated most vigorously by players in DeFi, dubbed “liquidity fragmentation”. Essentially it boils down to “How can 2 separate chains share the same state atomically?”, which is especially important to The Graph to prevent certain economic attacks (e.g. indexers indexing the same subgraph, but getting different rewards due to the different amounts curated on each network). This brings us to issue #2 with Optimistic Rollups.
The inherent security design of Optimistic rollups which lead to issues with finality & atomicity
I’ll keep this brief since it assumes some conversational familiarity with Optimistic Rollups, but essentially OR’s carry inherent security features that make state sharing quite difficult, most notably the L2 → L1 challenge period that takes a few days (I believe 7 on Arbitrum) to ensure enough time for a fraud proof to be published. Again, this is a necessity of OR’s, since they accept all transactions optimistically.
This appears to introduce certain problems specifically around atomicity and finality. As explained here and here, current approaches to sharing state between L1’s and L2’s revolve around a protocol built around intermediaries (sometimes trusted, but trust is NOT an inherent requirement) to facilitate the messaging between layers, particularly from L2 to L1. The primary point here is that optimistic rollups don’t have an “out of the box” way of maintaining bidirectional state atomicity; it only appears that it works one-way (L1 → L2) through an ETH bridge.
However, the approaches to this are up-and-coming, with the 2 I personally know of being Hop and Connext, who appear to have (decentralized?) protocols to facilitate messaging between layers efficiently. Essentially, it follows a pattern sometimes found in dAMM’s (decentralized automated market makers) to ensure that liquidity is present for the cross-chain operations being performed. Again, I’m not super well-versed in the specifics of the protocols, but at the core they act as an intermediary to facilitate moving assets (fungible and non-fungible) between chains.
Okay, so what are some good solutions?
This is where I’ll start getting creative, and throwing down some notes of ideas that could lead to a successfully interconnected Graph network:
-
Work with Connext to see how their protocol could be used to maintain state between L1 and L2, while still maintaining decentralization. Again, not a member of the core dev team, but this could be an option considering that the state channels used to settle queries run on the Vector network.
-
Prioritize atomicity in one direction only; essentially, if an ETH state change occurs, send a ticket to the L2 to have the same change occur. Since it appears that Arbitrum’s retryable tickets are atomic from the L1 → L2, this means that (theoretically, again I am not an expert) at least the L2 will have the synced changes from actions performed on the L1. This seems like the least palatable solution, and I think there could be a dozen race conditions here that would make the system quite complicated.
-
Use a centralized oracle to propagate changes between chains. I was actually wrong before, this is probably the least palatable solution, for obvious reasons.
-
Wait until ZK-Rollups reach EVM maturity. This one isn’t worth talking about too much, since the details of EVM-compatibility on projects like zkSync and StarkNet don’t include too much concrete information on cross-chain messaging, but the inherent design of ZK Rollups alleviate many of the issues found in Optimistic Rollups. I personally have high hopes for EVM-compliant rollups in regards to interoperability, and think they’re a more palatable long-term solution to the issues described above. But for now, only time will tell.
-
Redesign (some of) the contracts to allow for time-based segmentation, and include those components into the rollup layer/L2. For example, if delegation and staking/allocations could be moved to the L2, then mandatory “optimistic-rollup” network parameters may be set to facilitate this (e.g. a minimum allocation length of 8 epochs, assuming the Optimistic Rollup challenge period is 7 days/epochs). This is not a bad solution to the issue, but I imagine relies on a significant refactor due to the current linkage of the protocol as it stands.
-
Migrate the entirety of the network over to the L2, provided enough time for the L2 to prove it’s security is truly equivalent to the L1 (functionally speaking). This one needs little explanation, just point all users to Arbitrum. Bit of a nightmare I’m sure, though.
-
Probably quite a few more that I’m either forgetting or haven’t thought of yet. I don’t have too much of a team to bounce my ideas off of.
I would love to get some more input on this, but I think the core team is working really hard to make this work- we all know how big a deal it would be for the protocol, and I’m sure they want to make it happen (as well as taking a much-deserved offsite to spread all the good news) just as much as we do. @ari or @Brandon I’m sure will speak up at some point.
At the very least, hopefully this kicks off some good discussion on L2’s and how our network can embrace the rollup-centric future.