[elem][ropsten] DID cannot be resolved by other sidetree nodes.

[arthaszeng]

Deer team,

Recently I just found that the did which is generated by one sidetree node cannot be resolved by another node, currently I'm runing it with ropsten testnet in docker, could you please kindly give me some advices for trouble shooting?

details:

1. my .env.ropsten file:

SIDETREE_METHOD='elem:ropsten'
DESCRIPTION="Sidetree on Ethereum Ledger and IPFS Cas"

# Sidetree Variables
MONGO_DB_CONNECTION_STRING="mongodb://localhost:27017/"
DATABASE_NAME="element-testnet"
MAX_CONCURRENT_DOWNLOADS=20
BATCH_INTERVAL_IN_SECONDS=5
OBSERVING_INTERVAL_IN_SECONDS=5
PORT=3000

# Element Node Variables
ELEMENT_CONTENT_ADDRESSABLE_STORE_SERVICE_URI='/ip4/127.0.0.1/tcp/5001'
ELEMENT_ANCHOR_CONTRACT="0x920b7DEeD5CdE055260cdDBD70C000Bbd5b30997"
ETHEREUM_RPC_URL='https://ropsten.infura.io/v3/9aa3d95b3bc440fa88ea12eaa4456161'
...

2. I tested the IPFS peer functionalities manually, it works well.
3. I can create and resolve did on one node.
4. cannot resolve the genereated did via other sidetree node or via https://ropsten.element.transmute.industries/api/1.0/identifiers/ .
5. transaction has been confirmed on testnet, and I can see it in unresolvable-transactions collection on other sidetree node
6. the anchor file cannot be found on other sidetree node.

[arthaszeng]

Btw, I did create a did on my node and resolve it on pre-deployed sidetree node successfully on 18th Mar, after that, always fails

[OR13]

the anchor file cannot be found on other sidetree node.

Seems like an IPFS publishing issue, is the anchor file on the network, can we confirm it was published?

[BenjaminMoe]

Can you provide a few did's that you're able to create and resolve on your local node, that aren't resolvable from https://ropsten.element.transmute.industries/api/1.0/identifiers/. I think we can check the did suffix from the core index file to see where in the process the resolve might have broken.

[arthaszeng]

thanks @OR13 and @BenjaminMoe !

the anchor file cannot be found on other sidetree node.

Seems like an IPFS publishing issue, is the anchor file on the network, can we confirm it was published?

That's what I suspect as well, actually, I cannot find the files on any other IPFS peers, I can find them on my IPFS peer only, I tried almost all IPFS version from 0.7.0 to 0.12.0 standalone or in docker. But in another hand, when I manually import a file via IPFS, it succeed and can be addressed on other peers.

It seems not a coincidence, I tried to seeup sidetree node on AWS EC2 and other laptops, does work as well, event I have manually checked that the IPFS file syncing is working between those instances and my mac.

a typical example:

• did: did:elem:ropsten:EiDoBhtrKhc-eFhpA_k47XRDR3biKxJNL-uAO7PRC-LP3g
• chunk file: QmPapDT9nj5i7paGyZ6jDeYX2VVq7o2eabxjZgXfddDo48
• provisional index file: QmfJhsW4aAP7ZmqiLNUtacrhbPFAFp8NBdWZcGZ6i9uqSE`
• core index file: QmYzkmuPiNLMVY6i9vgxE1dtSDJMD3oWDr2EHSjDkeGLzX

evidences

• resolving on my local:

  

• resolving on other nodes:

  

• retriving code index file on my local IPFS peer:

  

• retriving code index file on other peers got failures

Another case

• did created on ropsten.element.transmute.industries: did:elem:ropsten:EiARxBUpD90wIHUxCuV9YCjgpBYFTVkpJlC6cqOPXal_GA

• resolving on ropsten.element.transmute.industries:

  

• resolving on my local or ec2:

  

---

@OR13 @BenjaminMoe any idea about those 2 cases? thanks in advance.

Btw, I pretty sure that I did succeed on 18th Mar, the did did:elem:ropsten:EiCtwD11AV9e1oISQRHnMJsBC3OBdYDmx8xeKeASrKaw6A created on my node and can be resolved anywhere, any broken change after 18th Mar?

[BenjaminMoe]

I created a local node for testing, and I am experience similar weirdness. The did from the universal resolver example did:elem:ropsten:EiCtwD11AV9e1oISQRHnMJsBC3OBdYDmx8xeKeASrKaw6A works, and the did you posted did:elem:ropsten:EiCtwD11AV9e1oISQRHnMJsBC3OBdYDmx8xeKeASrKaw6A works.

New dids created locally will work, but new DID's created on a different node will return a 500 error, with the following log outut.

warn  - ../db/node_modules/mongodb/lib/core/index.js
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

../db/node_modules/mongodb/lib/core/utils.js
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

../db/node_modules/mongodb/lib/core/connection/utils.js
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

../ledger-qldb/node_modules/sqlite3/lib/sqlite3-binding.js
Critical dependency: the request of a dependency is an expression

../ledger-qldb/node_modules/sqlite3/node_modules/node-pre-gyp/lib/pre-binding.js
Critical dependency: the request of a dependency is an expression

../ledger-qldb/node_modules/sqlite3/node_modules/node-pre-gyp/lib/util/versioning.js
Critical dependency: the request of a dependency is an expression

../crypto/node_modules/@mattrglobal/bbs-signatures/lib/index.js
Module not found: Can't resolve '@mattrglobal/node-bbs-signatures' in '/home/benjamin/Github/sidetree.js/packages/crypto/node_modules/@mattrglobal/bbs-signatures/lib'

../db/node_modules/mongodb/lib/encrypter.js
Module not found: Can't resolve 'mongodb-client-encryption' in '/home/benjamin/Github/sidetree.js/packages/db/node_modules/mongodb/lib'

../ledger-qldb/node_modules/sqlite3/node_modules/node-pre-gyp/lib/util/compile.js
Module not found: Can't resolve 'npm' in '/home/benjamin/Github/sidetree.js/packages/ledger-qldb/node_modules/sqlite3/node_modules/node-pre-gyp/lib/util'

../core/node_modules/rdf-canonize/dist/node6/lib/index.js
Module not found: Can't resolve 'rdf-canonize-native' in '/home/benjamin/Github/sidetree.js/packages/core/node_modules/rdf-canonize/dist/node6/lib'

../core/node_modules/rdf-canonize/lib/index.js
Module not found: Can't resolve 'rdf-canonize-native' in '/home/benjamin/Github/sidetree.js/packages/core/node_modules/rdf-canonize/lib'

../crypto/node_modules/rdf-canonize/lib/index.js
Module not found: Can't resolve 'rdf-canonize-native' in '/home/benjamin/Github/sidetree.js/packages/crypto/node_modules/rdf-canonize/lib'

../ledger-qldb/node_modules/sqlite3/node_modules/node-pre-gyp/lib/util/nw-pre-gyp/index.html
Module parse failed: Unexpected token (1:0)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file.

any broken change after 18th Mar?

We made some updates to support the Photon did method, and the log looks related. I'll keep looking into it.

[BenjaminMoe]

Another update with respect to tracking down this issue. After spending some time debugging, it looks like it wasn't a source code or database issue, but a cloud underflow issue.

It looks like there wasn't an active container running in GCP, which means the observer process wasn't running on the production node. I setup a temporary work around where I have a local computer running the observer process connected to the cloud database to populate the DID's in the mongoDB database, so they can be resolved on request.

I was able to make a DID locally and resolve it on https://ropsten.element.transmute.industries, but since I'm testing locally it makes it easy for IPFS to resolve the coreIndexFile. Try making a DID or two, and let me know if you're able to resolve it. It might take about 10 minutes to be published. We'll also update our cloud deployment to keep an active node running.

[BenjaminMoe]

@arthaszeng I created https://element.shellshop.lol/ to have another web-facing nodes to compare to, in addition to https://ropsten.element.transmute.industries/. Are you able to create a DID and resolve on one of these?