New error: Unsupported chainId 'eip155:3' on read/write testnet

Nodes Node Errors & Issues
1

I am getting intermittent errors today with this error:

failed with status '': {"error":"Unsupported chainId 'eip155:3'. Configured anchor service only supports 'eip155:100'"}

Which is really quite odd. For example, in the following code, the first 3 commits load, and the rest fail.

  const stream = await TileDocument.load(ceramic, streamId);
  const ids = stream.allCommitIds;
  log.trace(`Found ${ids.length} commits`);

  // TODO: do this with a multi-query instead
  const commits: JWE[] = [];
  for (let i = 0; i < ids.length; i++) {
    try {
      const commit = await ceramic.loadStream(ids[i]);
      if (commit) {
        commits.push(commit.content);
      }
    }
    catch (e: any) {
      log.error(`Cannot load commit: ${e.message}`);
    }
    progress?.(i / ids.length);
  }

I also get the same message intermittently when writing commits. AFAICT - in one case I got an error on write, and just re-ran the same code and it worked.

As far as I know, eip155:3 is the 3box chain-agnostic DID specifier, is it not? What is eip155:100? Did I miss something important?

2

Hey! I’m not sure when you were seeing this issue, but we were migrating our testnet so could you try again now that everything’s stable?

Thanks!

3

Same error, I’ll try updating my client libraries in case there is something there.

AFAICT eip155:100 is the gnosis chain, so it’s a fair bet it’s something related to the upgrade: chains/eip155-100.json at master · ethereum-lists/chains · GitHub

4

I’m still seeing the same error even when executed in a basic node environment. Here is a repro script that (I assume) will give you the same results:

I’ve tried upgrading everything to latest - my version of @ceramicnetwork/common is 2.4.0, so it should be up-to-date.

Any further thoughts?

import { Core } from '@self.id/core'
import { TileDocument } from '@ceramicnetwork/stream-tile'

const log = console;
const aliases = {
  "definitions": {
    "AccountDetails": "kjzl6cwe1jw149gym1m5qjzzqjdlupnsxivgeef9z6xjkc14ldbkgwag1cssryr"
  },
  "schemas": {
    "jwe": "ceramic://k3y52l7qbv1frxwvp66vqpcd046ju9ocvimye6htwucpg00h08nltj1fkns6p9ji8"
  },
  "tiles": {}
}
const core = new Core({ ceramic: 'testnet-clay', aliases});

async function getHistory(
  address,
  { ceramic, dataModel, dataStore },
) {

  //const link = await getLink(address, ceramic);
  const did = "did:3:kjzl6cwe1jw146vyxh3bf1l325qcb3b4rxnns181whfw1mezrpmgyia2mm2otzm" //link.did;
  if (!did) {
    log.debug("No DID found for account");
    return null;
  };

  log.trace(`Loading history for ${did}`);

  const definitionId = dataModel.getDefinitionID("AccountDetails");
  // The recordId is the stream defined by definition for this DID
  const streamId = await dataStore.getRecordID(definitionId, did);
  if (!streamId)
    return null;

  const stream = await TileDocument.load(ceramic, streamId);
  const ids = stream.allCommitIds;
  log.trace(`Found ${ids.length} commits`);

  // TODO: do this with a multi-query instead
  const commits = [];
  for (let i = 0; i < ids.length; i++) {
    try {
      const commit = await ceramic.loadStream(ids[i]);
      if (commit) {
        commits.push(commit.content);
      }
    }
    catch (e) {
      log.error(`Cannot load commit: ${e.message}`);
    }
  }
  return commits;
}


const all = await getHistory("0x445758e37f47b44e05e74ee4799f3469de62a2cb", core);
if (all) {
  for (const commit of all) {
    console.log(commit.ciphertext);
  }
}
5

Hey @FrozenKiwi! Would you mind sharing the stream ID for which you’re seeing these errors?

6

In the script above, streamId: "ceramic://k2t6wyfsu4pg1qzwz2anro87bodd221xhtb5trr0k82s2b0q224osk46gbjh4t"

1 Like
7

I’m assuming that the error you see is when loading the stream from your local Ceramic daemon.

This is an unfortunate consequence of the migration from ropsten to gnosis. Anchors done on ropsten cannot be validated post-migration to gnosis.

If you load the stream from Clay nodes though, because the stream was verified and cached in these nodes’ state store, the stream is able to load correctly without any additional verification.

There are two ways that I can think of for resolving this:

  • (Recommended) Start with a fresh stream on the latest Ceramic (that you’ve already upgraded to) that will use gnosis and not have issues resolving in the future in any configuration.
  • Downgrade your local Ceramic version to pre-gnosis, load the stream, which will cache it in your local state store, then upgrade back to the latest Ceramic.
    Just like on the Clay nodes, the older anchor commit will not be reverified, and subsequent ones can be verified on gnosis. This strategy is contingent on using a persistent state store though, so you’ll have to be careful not to flush it.

What do you think?

8

Actually, option two won’t work because when your local node connects to the anchor service, it won’t be able to start with a mismatched chain ID :frowning:

9

We’re considering cleaning out testnet data soon so as not to leave streams in such an inconsistent state. Our recommendation would be to start afresh with new streams. This will not be an issue for mainnet in case you have any content there.

10

AFAIK this is connecting directly to the clay nodes.

This will not be an issue for mainnet in case you have any content there.

That is my main concern. Walking the average non-crypto person through IDX isn’t straight-forward at the best of times, so as long as long as mainnet keeps chugging along I’m A-OK.

I’ll start a fresh testnet stream & hopefully we can just ignore this.

1 Like
11

Yes, absolutely. You’ve caught us right in between the testnet migration but mainnet is definitely going to remain stable.

Please let us know if you run into any other issues.

12

The problem with bootstrapping. Trust me, I understand :slight_smile:

1 Like