Feat/add proof soulbound nft

[JohnGuilding]

Adds soulbound NFT representing a valid ZK Email proof

• Soulbound
• Recipient should be committed to in the proof
• Metadata stored:

struct ZKEmailProofMetadata {
    uint256 blueprintId;
    Proof proof;
    uint256[] publicOutputs;
    string decodedPublicOutputs;
}

• Basic tests for tokenURI, safeMint and safeTransferFrom
• Adds basic access control
• Decoded public outputs should be flattened json. It is currently expected that this is formatted correctly before minting

[JohnGuilding]

Wasn't sure on correct format here @Bisht13 - would the address be in the proof like this?

[Bisht13]

this would be publicOutputs[1]

[JohnGuilding]

Wasn't sure on correct format here and ran out of time. Perhaps this would be an array of key value strings or similar and then we could add them to the metadata in the same way that proofJson is added in tokenURI()

[Bisht13]

proof is going to be [uint[2], uint[2][2], uint[2]] always, publicOutputs is going to be uint256[], then we also need a decoded public output field which would be included in the token uri

[JohnGuilding]

TODO notes

1. Use [uint[2], uint[2][2], uint[2]] for proof
2. Loop over public (uint256[]) outputs the same way the proof currently works
3. Add decoded public outputs which should be flattened json

[JohnGuilding]

Didn't have time to add a fleshed out test with a detailed flattened json. But @Bisht13 was envisioning something like this - wdyt?

unflattened:

{
  "user": {
    "id": 1,
    "name": "John Smith",
    "contact": {
      "email": "[email protected]",
      "phone": "07123 456789" 
    }
  }
}

flattened:

{
  "user.id": 1,
  "user.name": "John Smith",
  "user.contact.email": "[email protected]"
  "user.contact.phone": "07123 456789"
}

[Bisht13]

Didn't have time to add a fleshed out test with a detailed flattened json. But @Bisht13 was envisioning something like this - wdyt?

unflattened:

{
  "user": {
    "id": 1,
    "name": "John Smith",
    "contact": {
      "email": "[email protected]",
      "phone": "07123 456789" 
    }
  }
}

flattened:

{
  "user.id": 1,
  "user.name": "John Smith",
  "user.contact.email": "[email protected]"
  "user.contact.phone": "07123 456789"
}

So the unflattened JSON would always be like

{
    "id": 1,
    "name": "John Smith",
    "email": "[email protected]",
    "phone": "07123 456789" 
  }

Thus, the flattened JSON would never need a . in the key and can directly use the key.

[JohnGuilding]

@Bisht13 there are a few different ways we could do flattened json. The reason I am skeptical of the approach you outlined is we loose information. In this case, user and contact. This could be problematic for larger and more complex json structures (I'm also not sure how large these json structures would get, maybe they would always be small?).

If nested json structures are not expected, then your solution makes sense.