feat(prover | p2p): extend epoch quote validation

[Maddiaa0]

Overview

• Replaces the request to get EIP712 prover coordination signatures to compute them locally, rather than requesting it from the rollup each time
• Alters the l1 contract such that the rollup version is the same as the EIP712 version
• Changes VERSION to ROLLUP_VERSION cus searching VERSION brings up 2000 results, this will be much nicer to maintain

fixes: #8911

[Maddiaa0]

• feat(prover | p2p): extend epoch quote validation #10863 👈 (View in Graphite)
• feat(p2p): remaining p2p topic validators #10734
• feat(p2p): activate gossipsub tx validators #10695
• chore(p2p): move services into folders #10694
• chore(prover): prover node should not gossip attestations #10672
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[spalladino]

Changes VERSION to ROLLUP_VERSION cus searching VERSION brings up 2000 results, this will be much nicer to maintain

Smart guy

[spalladino]

Code looks good (except for a uint256 vs uint32, but I believe it does not affect the end result). I'm a bit worried about the L1 contract and ts code falling out of sync though: we have three new places (EpochProofQuoteHasher, EpochProofQuotePayload.typeHash, and EpochProofQuotePayload.getPayloadToSign.abi) where the struct info is repeated.

WDYT about adding a small unit test that grabs the struct definition from the rollup abi and compares it against what we have defined in all those places, just to fail early if we make a change? We could also create these values dynamically out of the abi, or even abuse the tsc compiler to check them, but a unit test is probably the easiest one.

We can extract it from a the claimEpochProofRight function in the abi:

  {
    "type": "function",
    "name": "claimEpochProofRight",
    "inputs": [
      {
        "name": "_quote",
        "type": "tuple",
        "internalType": "struct SignedEpochProofQuote",
        "components": [
          {
            "name": "quote",
            "type": "tuple",
            "internalType": "struct EpochProofQuote",
            "components": [
              {
                "name": "epochToProve",
                "type": "uint256",
                "internalType": "Epoch"
              },
              {
                "name": "validUntilSlot",
                "type": "uint256",
                "internalType": "Slot"
              },
              {
                "name": "bondAmount",
                "type": "uint256",
                "internalType": "uint256"
              },
              {
                "name": "prover",
                "type": "address",
                "internalType": "address"
              },
              {
                "name": "basisPointFee",
                "type": "uint32",
                "internalType": "uint32"
              }
            ]
          },
          {
            "name": "signature",
            "type": "tuple",
            "internalType": "struct Signature",
            "components": [
              {
                "name": "isEmpty",
                "type": "bool",
                "internalType": "bool"
              },
              {
                "name": "v",
                "type": "uint8",
                "internalType": "uint8"
              },
              {
                "name": "r",
                "type": "bytes32",
                "internalType": "bytes32"
              },
              {
                "name": "s",
                "type": "bytes32",
                "internalType": "bytes32"
              }
            ]
          }
        ]
      }
    ],
    "outputs": [],
    "stateMutability": "nonpayable"
  },

Another sanity check would be checking that the resulting typehash we compute in ts matches the EPOCH_PROOF_QUOTE_TYPEHASH on L1 during startup. Maybe it's too paranoid, but it'd save us from issues caused by version mismatches.

[spalladino]

Isn't the last one a uint32?

[Maddiaa0]

We could also create these values dynamically out of the abi

Opted for this one, was not too much effort!

[spalladino]

Just reviewed the commit, looks great.

One question, out of curiosity: did you notice any slowdown in vscode autocomplete in epoch_proof_quote_hasher.ts after you added viem's getAbiItem from the typed rollup abi?

[Maddiaa0]

Just reviewed the commit, looks great.

One question, out of curiosity: did you notice any slowdown in vscode autocomplete in epoch_proof_quote_hasher.ts after you added viem's getAbiItem from the typed rollup abi?

I will play around now, i hopped straight onto another branch after pushing this, did you experience it on your machine, if so i can revert it

[spalladino]

I didn't try it. Just asking because I had experienced slowdowns around some files that deal with L1, and I suspect that viem convoluted types may be the issue.

[LHerskind]

Tiny edge cases that I would expect could cause some pain.

[LHerskind]

If we encounter something like a struct or list I would kinda expect to fail miserably. Could we specify it to explode if it ecounter tuple or tuple[] as the type.