Batch GNS transactions

GGP: 0005 Scope: Smart Contracts Created: 2021-09-07 GIPs-Repo-Latest-Commit: 329e92fb3c897f68bddbd93abf12278167116266

GIPs

GIP: 0014 Title: Batch GNS transactions Authors: Ariel Barmat ariel@edgeandnode.com Created: 2021-09-07 Stage: Candidate Discussions-To: https://forum.thegraph.com/t/batch-gns-transactions/2285

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 (https://github.com/Uniswap/uniswap-v3-periphery/blob/main/contracts/base/Multicall.sol) and recently implemented in OpenZeppelin (https://docs.openzeppelin.com/contracts/4.x/api/utils#Multicall)

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( , , , , ) const tx2 = await gns.populateTransaction.mintNSignal( , , , , )

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

References

Implementation: https://etherscan.io/address/0x8F0031C8A936e3f78Db1E0670135CCad27E5b689#code Audit: https://github.com/graphprotocol/contracts/blob/40a2a721e1b8441a76a8f7105ffd9577cd163fc6/audits/OpenZeppelin/the-graph-gns-audit-2021-08.pdf

Graph Governance Proposal-0005

Batch GNS transactions

This proposal is to upgrade The Graph's protocol smart contracts running on Ethereum mainnet with the changes described in Graph Improvement Proposal (GIP) 0014, including the motivation and scope of the changes described in this proposal.

The code deployed that implements GIP-0014 must correspond to the commit hash included in the front matter of this governance proposal.

Following a successful "yes" vote, the protocol upgrade should be carried out at the earliest convenience using The Graph Council's Gnosis Multisig.