Replies: 16 comments
-
I've found some unresponsive nodes in used in the ledgers genesis:
|
Beta Was this translation helpful? Give feedback.
-
What ledgers are the nodes from? We need to contact the ledger owners to get them to up their genesis files. |
Beta Was this translation helpful? Give feedback.
-
@swcurran , I've updated the list to include the ledger name. It is not an exhaustive list! |
Beta Was this translation helpful? Give feedback.
-
@cvarjao, when was the last time you updated the genesis files and what source did you use? |
Beta Was this translation helpful? Give feedback.
-
@WadeBarnes — something to address with our Sovrin hats on. Looks like we need to update the Genesis Files for the Test and MainNet. |
Beta Was this translation helpful? Give feedback.
-
@WadeBarnes , this is the last time it got update (Dec 14, 2022): @jleach created that make-blocks.j script pulling from https://raw.githubusercontent.com/hyperledger/indy-node-monitor/main/fetch-validator-status/networks.json |
Beta Was this translation helpful? Give feedback.
-
Thanks. I just compared what you have registered, for Sovrin MainNet, in your file to a fully up to date copy. There are only two entries missing from your copy. I'll look through the IPs you have listed above. |
Beta Was this translation helpful? Give feedback.
-
They are using an up to date genesis file. Only two entries behind what the nodes report. Something else is afoot. |
Beta Was this translation helpful? Give feedback.
-
The following table contains the results of my analysis. It looks like whatever code is processing the genesis file is not processing it completely or accurately. None of the Sovrin MainNet nodes listed, other than
|
Beta Was this translation helpful? Give feedback.
-
Reading the pool transactions directly from the networks themselves is the best way to get an up to date genesis file. That said the URLs listed in that file contain genesis files up-to-date within a few transactions, for example the published genesis file for Sovrin MainNet is only two transactions short of the live system's pool transactions list. If you want an updated list, start an instance of indy-node-monitor, That said, having an up-to-date genesis file is not going to help when it's not parsed correctly, which is seemingly the issue identified above. |
Beta Was this translation helpful? Give feedback.
-
I've had a quick look at the Sovrin TestNet genesis file you have registered. It too is only two txns off from the live network, with |
Beta Was this translation helpful? Give feedback.
-
That’s very weird — what code could it be using to contact the nodes? Is it that there is actually another cached copy of the genesis file somewhere? I would think that the library code (which I think is Indy VDR) would be doing The Right Thing, if it has the correct genesis file. |
Beta Was this translation helpful? Give feedback.
-
I've compared the Sovrin TestNet and MainNet genesis files to the ones here (https://github.com/hyperledger/aries-mobile-agent-react-native/blob/main/packages/legacy/core/configs/ledgers/indy/ledgers.json) and they match other than the two missing txns for each. I find it weird too. |
Beta Was this translation helpful? Give feedback.
-
Is there an ETA to the availability of a release in the App/Play Store with fix(es) targeting this issue? I'm holding-off testing of the new VC-AuthN release since the credentials used for the LSBC dev/test environment are on Sovrin TestNet and there are significant slow-downs/issues currently when presenting them - I will resume as soon as a new version is available. |
Beta Was this translation helpful? Give feedback.
-
Posting as potentially relevant info (that was already shared internally). My test device is a Pixel 6 Pro on Android 14, I have also tested on Android 13 a couple of weeks ago with same results. When trying to respond to the proof request generated by https://a2a-dev.apps.silver.devops.gov.bc.ca (this is the proof-configuration, credentials rooted on Sovrin TestNet), the BC Wallet hangs for extremely long spans of time (currently it's been sitting there for several minutes without apparent progress) after scanning the QR code, at the screen that should display which credentials could be presented (see attached screenshot). I do have valid credentials to respond to the proof in my wallet. Other errors that I have been prompted with when trying to respond to a proof-request are related to the inability to automatically select requested attributes and inability to retrieve revocation status list or credential definition (see attached screenshots). |
Beta Was this translation helpful? Give feedback.
-
For comparison of the analysis I did previously, I've spun up askar based ACA-Py instances |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
All reactions