Ensure purgatory functionality on all the chains

oceanprotocol / pm

Zenhub needs each issue associated with one repo. This repo is a workaround, to mark issues that span >1 repos.

4 stars 0 forks source link

Ensure purgatory functionality on all the chains #86

Closed mihaisc closed 3 years ago

mihaisc commented 3 years ago

Purgatory must work on all chains and must be properly defined.

Issue to resolve: have one repo for each network, or a different one?

Discussion from standup 20210310: have a single repo that supports all chains at once. Otherwise we get madness of >>1 repos as we go to many chains.

Alex update:

Proposal:

add an optional chainId field for assets. If this field is missing, then we assume that the record is referring to eth mainnet (0x1). Otherwise, we check if chainId matches our web3.net.chainId(python) or web3.eth.getChainId (js) (for reference, this is a full list of chains: https://chainid.network/)
- accounts are going to be in purgatory, no matter what chainId is used

New list-assets.json structure:

[
    {
        "did": "did:op:d1419e62Df99F404D2aD81e23d6185aCe9197C06",
        "reason": "violation"
    },
    {
        "did": "did:op:E4C89BdE59BBf13c73271b7b951063e523A960FA",
        "reason": "violation",
        "chainId ": "0x4"
    }
]

mihaisc commented 3 years ago

I think we can ignore networkId, each chain has one mainnet and that's the only networm that matters. Sbould we have this for accounts? If you add an account on one chain, wouldn't we want that account to be in purgatory on all chains?

trentmc commented 3 years ago

I think we can ignore networkId, each chain has one mainnet and that's the only networm [sic] that matters.

That's not quite how it works in EVM-land.

Here's how it works:

each unique EVM chain has its own chainid.
including: ropsten, rinkeby, eth mainnet, matic, xdai, moonbeam mainnet, moonbeam testnet alpha
note that there is no distinction of "mainnet" vs other. Doing so is much more flexible.
https://chainid.network/ is the full list, as mentioned in the description

Therefore the proposal to add "chainid" to list-assets.json structure makes sense to me.

Sbould we have this for accounts? If you add an account on one chain, wouldn't we want that account to be in purgatory on all chains?

I don't believe we need it for accounts, for the reason you mention. Therefore we only need to add "chainid" to list-assets.json structure. For list-accounts.json, an account listed would be in purgatory in every chain.

alexcos20 commented 3 years ago

updated description

trentmc commented 3 years ago

lgtm

mihaisc commented 3 years ago

Agree, for some reason i was under the impression that chainId an networkId are different

kremalicious commented 3 years ago

We might not even need to capture network info for assets. Cause what exactly is the purpose of adding chainId for each asset if DIDs are already unique? From the purgatory API consumer perspective we do not care about the network, market asks for a DID and if it comes back marks asset as being in purgatory. From that perspective I don't see much reason to add it, except for some reference reasons.

mihaisc commented 3 years ago

You are right, from a technical point of view it will just work. We can add the chainId just for reference. Are we 100% sure that the did will be unique between chains?

trentmc commented 3 years ago

The address of a given datatoken will be different on each chain, because of how the factory works + how bridges work.

I want to understand better: did is a function of the address on the chain it was published, correct? And: I believe @alexcos20 had some concerns about dids across chains, can you share them here Alex?