feat: store contract address in rlnCredentials.txt

[richard-ramos]

in the rlnCredentials.txt file we should also add the contract address that belongs to those credentials. Credentials are unique per contract, so it probably makes sense to store the contract address in the file, and that way we can avoid having to write the --rln-relay-eth-contract flag if it's already available in the credentials file

[rymnc]

Additionally, we should store the chainId as well

[rymnc]

Although, one could have the same credentials for different membership sets.
Currently, the rlnCredentials format is as follows -

{
  "membershipKeyPair": {
    "idKey": uint8[],
    "idCommitment": uint8[]
  },
  "rlnIndex": uint256
}

We could have the schema extended in the following manner (if we consider that membership groups exist on only Ethereum smart contracts) -

{
  "version": uint8
  "membershipKeyPair": {
    "idKey": uint8[],
    "idCommitment": uint8[]
  },
  "membershipGroups": {
    "chainId": {
      "contractAddress": {
        "rlnIndex": uint8
      }
    }
  }
}

For example -

{
  "version": 2,
  "membershipKeyPair": {},
  "membershipGroups": {
    "1": {
      "0x000000000": {
        "rlnIndex": 123
      }
    },
    "5": {
      "0x4252105670fe33d2947e8ead304969849e64f2a6": {
         "rlnIndex": 125
      }
    }
  }
}

We should also track these schemas in their own spec with versioning for backwards compatibility.

wdyt? cc: @staheri14 @richard-ramos @jm-clius @s1fr0

[rymnc]

In favor of anonymity, we should not be using the same idCommitment across different membership groups. One membershipKeyPair should only be used in one membership group.

[staheri14]

In favor of anonymity, we should not be using the same idCommitment across different membership groups.

Right, also (as discussed in our call), not only for anonymity but also for the sake of simplicity it is better to keep one group info for each key pair inside the credential file. Otherwise, we need to give explicit choices to the user to reuse some old persisted credentials on a new chain/group. One may argue it is beneficial for key management i.e., one key pair instead of multiple key pairs across different groups/chains, however that comes with the anonymity cost.

[s1fr0]

I agree that we need to enrich credentials, and probably further allow storage of multiple credentials (why not allowing users that stake double the membership fee to message at double rate?). Depending on this detail (allowing multiple credentials or not) then i would have a contract field and a sequence of membership keypairs. Otherwise if we don't want the same commitment among different membership groups (we cannot enforce it on the smart contract though), the first solution

{
  "version": uint8
  "membershipKeyPair": {
    "idKey": uint8[],
    "idCommitment": uint8[]
  },
  "membershipGroups": {
    "chainId": {
      "contractAddress": {
        "rlnIndex": uint8
      }
    }
  }
}

seems to be the most suitable one

[s1fr0]

As a side comment:membership fees are paid with an eth account so changing idcommitment but using same eth account to pay them would invalidate anonymity in same way.

[staheri14]

why not allowing users that stake double the membership fee to message at double rate

@s1fr0 That is a good suggestion (here is the tracking issue #1264), but I think it is not captured by the first solution, what you suggested is an n-to-1 relationship between the credential and the group, whereas the first solution covers the 1-to-n relationship i.e., one credential and multiple groups.

Nevertheless, supporting a higher messaging rate with multiple valid rln credentials requires some careful changes at the protocol level as well. We shall attempt those first before proceeding with any relevant update on the rln credential file.

[staheri14]

As a side comment:membership fees are paid with an eth account so changing idcommitment but using same eth account to pay them would invalidate anonymity in same way.

Right, worth adding a security recommendation to the RFC about this.

[s1fr0]

In a 1-to-n relation I would also probably specify the application using the credential: the same membership contract can be used by different applications (e.g. we allow to do X to all users that subscribed to RLN). This might be of help in case we standardize the credential schema so that can be imported by different applications that will then be immediately be able to check if there is a valid credential for what they need a credential for.

In this sense we should probably not have the keypair as separate fields (since are specific to RLN) but should rather go under application's "credentials" so that we have something similar to the following structure that remains general but allows us to enrich it with new fields without invalidating consistency of previous ones:

application1
    |------ version
    |------ credentials
    |          |------- idkey1, idcommitment1
    |          |            |------- membershipgroups
    |          |                         |------- group1, idx1
    |          |                         |------- group2, idx2
    |          | 
    |          |------- idkey2, idcommitment2
    |                       |------- membershipgroups
    |                                    |------- group1, idx3
    |                                    |------- group3, idx4
    |
    |------ possibly extended with other useful fields
    
application2
    |----- ...

[rymnc]

Yes, this would however, add complexity to the end user, and may result in a lot more user-prone errors, i.e choosing the wrong credential index. Furthermore, if we were to increase the messaging rate by having multiple membershipKeyPair's on one membershipGroup, the schema should be altered as follows -

{
  "version": uint8
  "membershipGroups": {
    "chainId": {
      "contractAddress": {
        "rlnIndex": uint8,
        "membershipKeyPairs": MembershipKeyPair[]
      }
    }
  }
}

Which would allow us to enforce the relation that each membership group can have one or more membershipKeyPairs, but not the converse.

[s1fr0]

"rlnIndex": uint8,
"membershipKeyPairs": MembershipKeyPair[]

The rlnIndex is per membership key pair, not the same for all of them.

Also, it should be the group that is associated to a credential pairs (that can be reused among multiple application - think about that the pair can be generated from your eth wallet waku-org/js-rln#28) and not the opposite where you'll have many entries replicating the same credential pairs.

[s1fr0]

This issue has been addressed by #1466, which implements #1238 (comment).