Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: P-212 Club3 NFT VC #2492

Merged
merged 3 commits into from
Feb 20, 2024
Merged

feat: P-212 Club3 NFT VC #2492

merged 3 commits into from
Feb 20, 2024

Conversation

higherordertech
Copy link
Contributor

@higherordertech higherordertech commented Feb 15, 2024

Context

1 added new data provider morails (other existing data provider does not support the required evm network)
2 added arbitrum and polygon network
3 added general nft holder VC using this new data provider
4 added Club3 VC
5 migrated existing WeirdoGhostGang VC under it

Labels

Please apply following PR-related labels when appropriate:

  • C0-breaking: if your change could break the existing client, e.g. API change, critical logic change
  • C1-noteworthy: if your change is non-breaking, but is still worth noticing for the client, e.g. reference code improvement

How (Optional)

Testing Evidences

Please attach any relevant evidences if applicable

{
   "@context":[
      "https://www.w3.org/2018/credentials/v1",
      "https://w3id.org/security/suites/ed25519-2020/v1"
   ],
   "id":"0xb7d828814aeb7bc9c8fa674370b45a3f38eea1b249f400bb48c71e305a46a4af",
   "type":[
      "VerifiableCredential"
   ],
   "credentialSubject":{
      "id":"did:litentry:substrate:0xd4e35b16ec6b417386b948e7eaf5cc642a243096cecf366e6313689b90969f42",
      "description":"You are a holder of a certain kind of NFT",
      "type":"NFT Holder",
      "assertionText":"NftHolder(Club3Sbt)",
      "assertions":[
         {
            "and":[
               {
                  "src":"$nft",
                  "op":"==",
                  "dst":"Club3 SBT"
               },
               {
                  "or":[
                     {
                        "and":[
                           {
                              "src":"$network",
                              "op":"==",
                              "dst":"bsc"
                           },
                           {
                              "src":"$address",
                              "op":"==",
                              "dst":"0x9f488C0dafb1B3bFeeD3e886e0E6E5f3f4517925"
                           }
                        ]
                     },
                     {
                        "and":[
                           {
                              "src":"$network",
                              "op":"==",
                              "dst":"polygon"
                           },
                           {
                              "src":"$address",
                              "op":"==",
                              "dst":"0xAc2e4e67cffa5E82bfA1e169e5F9aa405114C982"
                           }
                        ]
                     },
                     {
                        "and":[
                           {
                              "src":"$network",
                              "op":"==",
                              "dst":"arbitrum"
                           },
                           {
                              "src":"$address",
                              "op":"==",
                              "dst":"0xcccFF19FB8a4a2A206d07842b8F8c8c0A11904C2"
                           }
                        ]
                     }
                  ]
               }
            ]
         }
      ],
      "values":[
         true
      ],
      "endpoint":"wss://rpc.rococo-parachain.litentry.io"
   },
   "issuer":{
      "id":"did:litentry:substrate:0x304209a0581f23786118458a63f7be3b46554fa59be4a12a194c9f3c6304f191",
      "name":"Litentry TEE Worker",
      "mrenclave":"5tJCvdgWoScE27uQPC5YafWePiR7Qn2V9apJPR44ZfMT"
   },
   "issuanceDate":"2024-02-15T12:00:37.078191645+00:00",
   "parachainBlockNumber":50,
   "sidechainBlockNumber":92,
   "proof":{
      "created":"2024-02-15T12:00:37.079184850+00:00",
      "type":"Ed25519Signature2020",
      "proofPurpose":"assertionMethod",
      "proofValue":"4c2469c052dbb131f5a1bc26cefe72856cb332417beec8b9507dd4c9e714a6937eb362b020018b78de87c8c96b9fc85ff7b75d89d0fe14d4c7d556b9d1814103",
      "verificationMethod":"0x304209a0581f23786118458a63f7be3b46554fa59be4a12a194c9f3c6304f191"
   }
}

Copy link

linear bot commented Feb 15, 2024

@higherordertech higherordertech added the C1-noteworthy Non-breaking change but is worth noticing for client label Feb 15, 2024
@higherordertech
Copy link
Contributor Author

added new evm network support for polygon and arbitrum, pls see how client side wanted to extend the supported network. @YoshiyukiSakura

Copy link
Member

@felixfaisal felixfaisal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @higherordertech
Not related to the PR directly, But i see these crates assertion-build-v2 and credential-v2,

  1. I may have missed out why we are creating separate crates for different versions?
  2. Do we plan on continuing to iter this way, wherein we have v3 and then v4?
  3. If not are we planning on merging assertion-build-v2 and assertion-build, So what we waiting for in order to merge?

We have existing feature gating and version controlling features in Rust without having to explicitly define v2 crates and so on.

@higherordertech
Copy link
Contributor Author

higherordertech commented Feb 15, 2024

Hey @higherordertech Not related to the PR directly, But i see these crates assertion-build-v2 and credential-v2,

  1. I may have missed out why we are creating separate crates for different versions?
  2. Do we plan on continuing to iter this way, wherein we have v3 and then v4?
  3. If not are we planning on merging assertion-build-v2 and assertion-build, So what we waiting for in order to merge?

We have existing feature gating and version controlling features in Rust without having to explicitly define v2 crates and so on.

The plan is to migrate all v1 credentials under v2 and then v1 can be deprecated and v2 can be renamed to be the only version. Currently they co-exists because the migration work is not prioritised yet (while we are still catching new VC requirement), while at same time some of the new VC can not really be implemented via the v1 structure.

Copy link
Collaborator

@Kailai-Wang Kailai-Wang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not much to complain from my side :)
I've been wondering the difference between lc-credential and lc-crediential-v2

@@ -31,6 +31,8 @@ ACHAINABLE_AUTH_KEY=
ONEBLOCK_NOTION_KEY=
NODEREAL_API_KEY=
GENIIDATA_API_KEY=
GENIIDATA_API_KEY=142cf1b0-1ca7-11ee-bb5e-9d74c2e854ac
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have this key already - see the line above

Comment on lines +52 to +56
let api_key = data_provider_config.moralis_api_key.clone();
let api_retry_delay = data_provider_config.moralis_api_retry_delay;
let api_retry_times = data_provider_config.moralis_api_retry_times;
let api_url = data_provider_config.moralis_api_url.clone();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's out of this PR's scope, but sooner or later we'll need a refactoring to have a trait-based impl. The background is I see a lot of duplicate code, we could have something like build_client_with auth or build_client_with retry - or as fn parameters. 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added fail fast boolean option in service layer, and trait in data provider layer now

@higherordertech
Copy link
Contributor Author

higherordertech commented Feb 19, 2024

With minimum changes, also added RetryableError for client to differentiate retryable error or non retryable error:

>>>command: PlatformUser(
    KaratDaoUser,
)
Trusted call 0x0b19000591014461746150726f76696465724572726f7228426f756e64656456 is TopExecuted([11, 25, 0, 5, 145, 1, 68, 97, 116, 97, 80, 114, 111, 118, 105, 100, 101, 114, 69, 114, 114, 111, 114, 40, 66, 111, 117, 110, 100, 101, 100, 86, 101, 99, 40, 91, 56, 50, 44, 32, 49, 48, 49, 44, 32, 49, 49, 54, 44, 32, 49, 49, 52, 44, 32, 49, 50, 49, 44, 32, 57, 55, 44, 32, 57, 56, 44, 32, 49, 48, 56, 44, 32, 49, 48, 49, 44, 32, 54, 57, 44, 32, 49, 49, 52, 44, 32, 49, 49, 52, 44, 32, 49, 49, 49, 44, 32, 49, 49, 52, 44, 32, 52, 48, 44, 32], false)
Default { msg: "[Error] Error occurred while executing trusted call: RequestVCFailed(PlatformUser(KaratDaoUser), DataProviderError(BoundedVec([68, 97, 116, 97, 80, 114, 111, 118, 105, 100, 101, 114, 69, 114, 114, 111, 114, 40, 66, 111, 117, 110, 100, 101, 100, 86, 101, 99, 40, 91, 56, 50, 44, 32, 49, 48, 49, 44, 32, 49, 49, 54, 44, 32, 49, 49, 52, 44, 32, 49, 50, 49, 44, 32, 57, 55, 44, 32, 57, 56, 44, 32, 49, 48, 56, 44, 32, 49, 48, 49, 44, 32, 54, 57, 44, 32, 49, 49, 52, 44, 32, 49, 49, 52, 44, 32, 49, 49, 49, 44, 32, 49, 49, 52, 44, 32, 52, 48, 44, 32], 100)))" }

RetryableError  BoundedVec converted to string is:
RetryableError("Fail to call rest api within 0 retries")

Copy link
Member

@felixfaisal felixfaisal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Kailai-Wang
Copy link
Collaborator

Asking for reviews from @BillyWooo @zhouhuitian

higherordertech added 3 commits February 20, 2024 12:08
…on network, added general nft holder VC using this new data provider, added Club3 VC, migrated existing WeirdoGhostGang VC under it
@higherordertech
Copy link
Contributor Author

Not much to complain from my side :) I've been wondering the difference between lc-credential and lc-crediential-v2

@Kailai-Wang let me take this chance to explain the differences:

lc-credentials-v2 does not depend on lc-data-providers, and doesn't depend on any data provider from the credential level, nor limit how many data provider can be used. e.g. there won't be so called achainable credential or noderal credentail, instead a credential is just a credential decoupled from any (one or many) data providers it would require to use.

while lc-credentials depend on lc-data-providers and has always hard coded the data provider dependency in credential level, and also constraint one credential can only use max one data provider

@higherordertech higherordertech merged commit 4de61c8 into dev Feb 20, 2024
31 checks passed
@BillyWooo BillyWooo deleted the P-212 branch February 20, 2024 06:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C1-noteworthy Non-breaking change but is worth noticing for client
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants