Batch GNS transactions

Hi all, this is a proposal to allow batch transactions on the GNS contract.

Motivation

One of the issues brought by the community is that sometimes a subgraph publisher would want to publish a new subgraph and deposit the initial tokens. Today, that’s only possible by using a Multisig or any other contract to batch those transactions.

This proposal allows batching transactions on the GNS, based on the Multicall pattern seen in Uniswap (uniswap-v3-periphery/Multicall.sol at main · Uniswap/uniswap-v3-periphery · GitHub) and recently implemented in OpenZeppelin (Utilities - OpenZeppelin Docs)

Implementation

A new contract called MultiCall is introduced, inspired by the one used by Uniswap. The payable keyword was removed from the multicall() as the protocol does not deal with ETH. Additionally, it is insecure in some instances if the contract relies on msg.value.

The GNS inherits from MultiCall that expose a public multicall(bytes[] calldata data) function that receives an array of payloads to send to the contract itself. This allows to batch ANY publicly callable contract function.
Client-side one can build such payloads like:

// Build payloads
const tx1 = await gns.populateTransaction.publishNewSubgraph(
    <subgraphAccount>,
    <subgraphDeploymentID>,
    <versionMetadata>,
    <subgraphMetadata>,
)
const tx2 = await gns.populateTransaction.mintNSignal(
    <subgraphAccount>,
    <subgraphNumber>,
    <amount>,
    <signalOut>,
)

// Send batch
await gns.multicall([tx1.data, tx2.data])

References

The changes are implemented in the following PR: Allow batch transactions using multicall in the GNS by abarmat · Pull Request #485 · graphprotocol/contracts · GitHub

7 Likes

Interesting! Presumably batching using an existing generic multicall deployment might break some msg.sender logic in the GNS?

Yes, by doing a delegatecall within multicall() we preserve the msg.sender

1 Like

Any concern that this strategy, although effective for deterring bots, may lead to the deployment of more predatory subgraphs?

If these predatory persons know that they will automatically be guaranteed the first minted shares, I would think that they’ll begin to flood the network with “traps” for unsuspecting curators.

I do not know much about the technical side of any of this though, by the way. Just a thought - Thank you for your hard work!

1 Like