Support named networks, Amoy blockchain and Banksia network

[tahpot]

Closes #411 #420 #421

[aurelticot]

The blockchain hex ids are defined in two places, risk of unsync and confusion on why one to use.
See other comment regarding a blockchain definition object.

[aurelticot]

This deprecated CONTRACT_ADDRESS still holds info not in the network defintiions, such as for the DID registry addresses.

I gues we should have a similar object for the DID VDA, gathering the registry address, its blockchain and other related information (name registry?).

[tahpot]

@ITStar10

Have you addressed this feedback?

The target_chain is hardcoded in a lot of the tests. This should be in an environment variable for all packages, for consistency and easy updating.

Also see my other code comments.

[tahpot]

v4 Release Notes

Breaking changes

Separating DID blockchain from Verida Network blockchain

The protocol previously had the concept of a Verida Network, which was anchored to a single blockchain. In order to maximize flexibility and handle blockchains going offline (such as Mumbai which has been shut down), the protocol now separates the blockchain used to anchor a did and the blockchain anchoring the Verida network.

The protocol supports:

• Verida Network: The Verida network being connected to (ie: BANKSIA, MYRTLE, DEVNET). This corresponds to the storage nodes available on that network and the protocol smart contracts deployed to the blockchain anchoring that Verida network.
• Blockchain Anchor: A blockchain (ie: Polygon Amoy)

DID's can now be anchored to any blockchain (or linked with any other DID method). The storage nodes for an application context are stored in the DID document, which has a reference to the Verida network associated with the storage nodes. In this way, it's possible to have a single DID document that is used across multiple Verida networks.

As a result, the way a connection is established has changed. ClientConfig configures the Verida Network using network instead of environment:

        const DID_CLIENT_CONFIG: AccountNodeDIDClientConfig = {
            callType: "web3",
            web3Config: {
                privateKey: BLOCKCHAIN_PRIVATE_KEY
            }
        }
        import { AccountNodeDIDClientConfig, Network } from "@verida/types";
        const account = new AutoAccount({
            privateKey: "0xabc123...",
            network: Network.MYRTLE,
            didClientConfig: DID_CLIENT_CONFIG
        })
        const did = (await account.did()).toLowerCase()

        const client = new Client({
            network: Network.MYRTLE
        })

        await client.connect(account)
        const context = await client.openContext(contextName)

Storage node authentication

Authentication between storage nodes and clients requires signing a consent message (containing a generated nonce) to ensure the DID controller is the one requesting access to the encrypted storage node data.

For enhanced flexibility and security, the expected signing key has changed from the master DID account key to the context signing key.

Other key changes:

• [client-ts] client.getPublicProfile() supports a new networkFallback parameter (boolean) indicating if the profile should be loaded from the network if it's not available from the caching server
• [client-ts] Network.getRecord() now requires the network parameter
• [client-ts] Bug fixes relating to fetching public credentials, closing databases and sending inbox messages to full storage nodes
• [verifiable-credentials] Fix: credentialData was raw JSON, not a VC meeting the W3C spec as expected