graphops/graphcast-registry

Graphcast Registry allows registering a Graphcast ID to join Graphcast

graphcast-registry's Issues

Deploy on Arbitrum

Graphcast registry connects The Graph network with Graphcast pubsub network by defining the mapping between graphcast id and indexer operator addresses. The caller that sets graphcast id must be an indexer operator registered on The Graph network subgraph. Since there are new network subgraphs on Arbitrum-One and Arbitrum-Goerli, we should deploy new registries to support indexers on Arbitrum.

Two major approaches are

• upgrading the contract for interoperability, such that it handles both L1 and L2 identities with address mapping. We recognizes that identities will only exist on two layers at the same time during transitional periods.
• We can deploy separate registries on the two layers, such that different addresses are used and topics are segregated by network subgraph. We would require current L1 registry users to migrate over, potentially with a migration helper (but so far the network cardinality is small). Even though we have separate layers for The Graph network, we don't necessarily need to create a separate Graphcast Network as the message volume will increase but content topics will be used for filter subscriptions. If we decide to create a new Graphcast network, then we can update our nodefleets to subscribe to both layers' namespaces or to add two new sets of nodefleets.

We consider the trade-off between the engineering effort to make the multi-layer functionality for a temporary state versus requiring current users to migrate to a separate network, and prefers to choose the later option for the quicker, cleaner, and easier path.

• Improve registry code such that no upgrade is needed after deploying to Arbitrum (do not replicate the steps with current eth-goerli and eth-mainnet
• Track relevant addresses by network in readme
• Test run on Arbitrum-goerli: Create addresses (deployer account, indexer and operator, graphcast id, gnosis safe), deploy contracts and subgraph, test transactions to verify functionalities, run example radios on Graphcast network
• After test run confirmation, repeat for Arbitrum-one

Allow indexer operators to set graphcast ids

Very often an indexer address is a token lock wallet, which means they will not be able to call setGraphcastID. We should update to allow the message sender to represent the indexer address.

Between indexer operator and wallet beneficiaries, the operator address makes more sense as it has lower OpSec, more replaceable, and conventionally act on behalf of the indexer - an indexer can optionally create a dedicated operator for registering graphcastID.

Get repo ready for being public

• Complete repo checklist
• Merge PR for repo in graphops/admin

Feat Req: contract upgradability and admin

Feat.Req - `setGossipOperator` call check

Spam protection: Add a check on sender's address for calling setGossipOpeartor such that only an address that is a valid GraphAccount (or specifically an indexer account) can set a gossip operator, revert otherwise.

Rename gossip operator to Graphcast ID, as per our branding discussion

Feat.Req - Address frontrun security

Due to the preferred restriction of 1:1 relationship between indexer and Graphcast agent, there exist a vulnerability for indexers who submits a transaction to set their Graphcast agent, in which a malicious actor can frontrun transactions to disabled someone from setting the desired agent address.
​

POC

• Alice wants to set her operator to 0x1234.
  She calls setGossipOperator(0x1234).

• ​Malicious Bob sees this in the mempool and sends another setGossipOperator(0x1234) with higher gas price.

• After Bob's tx succeeds, Alice's will fail because operatorRegistered[0x1234] is already set.

Potential solutions

1. commit/reveal scheme like ENS: first transaction with hash of gossip address, second transaction reveals the preimage and claims it
2. Instead of requiring the address field for Graphcast operator, instead require a message signed by the operator private key. Message object should contain both operator address and the message sender address. The contract verify the msg.sender and message signature