Design mosaic config #44

schemar · 2019-04-02T08:19:59Z

Mosaic configurations store data about mosaic chains: chain ids, contract addresses, etc.
The mosaic chains repository handles mosaic configs and writes the first mosaic config of a newly created auxiliary chain.

The layout of the mosaic configuration must be thought out well. It will be distributed to others to run and connect to mosaic chains.

⚠️ Updating the code in mosaic chains should be a separate follow-up ticket.

ℹ️ Keep in mind that this configuration should later be registered in a smart contract on-chain.

Context

This is a research issue to find out what the configuration should look like.

Background:
Mosaic chains configurations should be separate from OpenST (or BrandedToken) configurations. Generally, they should be separate files and OpenST (and BrandedToken) should reference the Mosaic config where applicable.

This ticket is only about the mosaic config and not about any other configs like OpenST.

schemar · 2019-04-08T12:17:21Z

Think of multiple solutions and explain which ones you were thinking of and why you chose the chosen one.

Possibly think about maps in solidity to have an extendable on-chain configuration.

0xsarvesh · 2019-04-10T11:37:49Z

While designing config, the following use cases are considered.

As a mosaic user (i.e. facilitator, validator etc.), I want to know all the auxiliary chain for a given origin chain.

Proposed solution:

Config should list all the auxiliary chains.

As a mosaic user(i.e. facilitator, validator etc.), I want to connect to any given auxiliary chain so that I can see available contracts/dapps.

Proposed solution:

Config should provide details to connect to an existing auxiliary chain like boot nodes and genesis file.

As a mosaic user(i.e. facilitator, validator etc.), I want to convert ERC20 ost to auxiliary base coin so that I can pay for transaction gas fee in the auxiliary chain.

Proposed solution:

Config should list ost gateway related contract addresses to enable ost stake and mint.
Config should also provide a mechanism like known hashLock(or any other solution) so that facilitator can progress stake message on behalf of staker. This requires more discussion.

Details

Below JSON represents a mosaic config based on the above requirement.
JSON only represents meta-data of mosaic config hence the value of many fields in the JSON is left as blank which should be replaced with appropriate value.
Proposed config captures details of the single origin chain and it's multiple auxiliary chains.
ostStakeConfig(can be named better) is currently a place holder for the information needed by the staker to perform first ost stake in order to mint base coins. This part requires more discussion.

{
  "originChain": {
    "chainId": 3,
    "contractAddresses": {
      "simpleTokenAddress": "",
      "anchorOrganizationAddress": "",
      "anchorAddress": "",
      "merklePatriciaLibAddress": "",
      "GatewayLibAddress": "",
      "messageBusAddress": "",
      "ostGatewayOrganizationAddress": "",
      "ostEIP20GatewayAddress": ""
    }
  },
  "auxiliaryChains": [
    {
      "chainId": 1406,
      "bootNodes": [],
      "genesis": {},
      "contractAddresses": {
        "ostPrimeAddress": "",
        "anchorOrganizationAddress": "",
        "anchorAddress": "",
        "merklePatriciaLibAddress": "",
        "GatewayLibAddress": "",
        "messageBusAddress": "",
        "ostCoGatewayOrganizationAddress": "",
        "ostEIP20CogatewayAddress": ""
      },
      "ostStakeConfig": {}
    },
    {
      "chainId": 1407,
      "bootNodes": [],
      "genesis": {},
      "contractAddresses": {
        "ostPrimeAddress": "",
        "anchorOrganizationAddress": "",
        "anchorAddress": "",
        "merklePatriciaLibAddress": "",
        "GatewayLibAddress": "",
        "messageBusAddress": "",
        "ostCoGatewayOrganizationAddress": "",
        "ostEIP20CogatewayAddress": ""
      },
      "ostStakeConfig": {}
    }
  ]
}

0xsarvesh · 2019-04-11T08:01:17Z

Proposal 2

Slightly different from proposal 1.
Instead of listing the aux chain as an array, all the side chains can be represented as an object where each key of the object represents chainId against which aux details are kept.

{
  "originChain": {
    "chainId": 3,
    "contractAddresses": {
      "simpleTokenAddress": "",
      "anchorOrganizationAddress": "",
      "anchorAddress": "",
      "merklePatriciaLibAddress": "",
      "GatewayLibAddress": "",
      "messageBusAddress": "",
      "ostGatewayOrganizationAddress": "",
      "ostEIP20GatewayAddress": ""
    }
  },
  "auxiliaryChains": {
    "1406": {
      "chainId": 1406,
      "bootNodes": [],
      "genesis": {},
      "contractAddresses": {
        "ostPrimeAddress": "",
        "anchorOrganizationAddress": "",
        "anchorAddress": "",
        "merklePatriciaLibAddress": "",
        "GatewayLibAddress": "",
        "messageBusAddress": "",
        "ostCoGatewayOrganizationAddress": "",
        "ostEIP20CogatewayAddress": ""
      },
      "ostStakeConfig": {}
    },
    "1407": {
      "chainId": 1407,
      "bootNodes": [],
      "genesis": {},
      "contractAddresses": {
        "ostPrimeAddress": "",
        "anchorOrganizationAddress": "",
        "anchorAddress": "",
        "merklePatriciaLibAddress": "",
        "GatewayLibAddress": "",
        "messageBusAddress": "",
        "ostCoGatewayOrganizationAddress": "",
        "ostEIP20CogatewayAddress": ""
      },
      "ostStakeConfig": {}
    }
  }
}

schemar · 2019-04-11T15:14:45Z

Nice thoughts! 🙌
Somme comments:

1. As a mosaic user, I want to know all the auxiliary chain for a given origin chain.
   **Proposed solution:**

Is this really true for mosaic users or would this be more appropriate for validators, market makers, and the likes. Anyways I think this is valuable information 👍

* [x]  Config should provide details to connect to an existing auxiliary chain like boot nodes and genesis file.

Should we really add the genesis to the config? We could, it doesn't have to be human readable 🤔 The bootnodes definitely help and don't need to go in a separate file 👍

* `ostStakeConfig`(can be named better) is currently a place holder for the information needed by the staker to perform first ost stake in order to mint base coins. This part requires more discussion.

Yeah, this is an important, difficult part...

JSON comments:

{
  "originChain": {
    "chainId": 3,
    "contractAddresses": {
      "simpleTokenAddress": "",
      "anchorOrganizationAddress": "",
      "anchorAddress": "",
      "merklePatriciaLibAddress": "",
      "GatewayLibAddress": "",
      "messageBusAddress": "",
      "ostGatewayOrganizationAddress": "",
      "ostEIP20GatewayAddress": ""
    }
  },

Anchor, its organization, gateway libraries, and the OST gateway address would be different per auxiliary chain on the same origin chain. These fields should probably move to the auxiliary part 🤔

  "auxiliaryChains": [
    {
      "chainId": 1406,
      "bootNodes": [],
      "genesis": {},
      "contractAddresses": {
        "ostPrimeAddress": "",
        "anchorOrganizationAddress": "",
        "anchorAddress": "",
        "merklePatriciaLibAddress": "",
        "GatewayLibAddress": "",
        "messageBusAddress": "",
        "ostCoGatewayOrganizationAddress": "",
        "ostEIP20CogatewayAddress": ""
      },
      "ostStakeConfig": {}
    },

bootnodes should probably be a string how it is used by geth and parity (comma-separated). But I am not sure here 🧐

Proposal 2
Instead of listing the aux chain as an array, all the side chains can be represented as an object where each key of the object represents chainId against which aux details are kept.

I like this proposal, because I can access a chain config for a known chain id without iterating over all auxiliary chains to find the one with my id.

0xsarvesh · 2019-04-15T07:31:05Z

Is this really true for mosaic users or would this be more appropriate for validators, market makers, and the likes. Anyways I think this is valuable information 👍

I have update the description, thanks 👍

Should we really add the genesis to the config? We could, it doesn't have to be human readable 🤔 The bootnodes definitely help and don't need to go in a separate file 👍

We could keep genesis into a separate file. What is a good way of referencing genesis file into mosaic-config? As we know, it requires both bootnode and genesis to connect to a node.

Anchor, its organization, gateway libraries, and the OST gateway address would be different per auxiliary chain on the same origin chain. These fields should probably move to the auxiliary part 🤔

True 👍

bootnodes should probably be a string how it is used by geth and parity (comma-separated). But I am not sure here 🧐

There can be more than 1 boot nodes that we may want to publish. 🤔

0xsarvesh · 2019-04-15T07:37:41Z

Draft 2

Proposal 1

{
  "originChain": {
    "chainId": 3,
    "contractAddresses": {
      "simpleTokenAddress": "",
      "merklePatriciaLibAddress": "",
      "GatewayLibAddress": "",
      "messageBusAddress": ""
    }
  },
  "auxiliaryChains": [
    {
      "chainId": 1406,
      "bootNodes": [],
      "genesis": {},
      "contractAddresses": {
        "origin": {
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "ostGatewayOrganizationAddress": "",
          "ostEIP20GatewayAddress": ""
        },
        "auxiliary": {
          "ostPrimeAddress": "",
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "merklePatriciaLibAddress": "",
          "GatewayLibAddress": "",
          "messageBusAddress": "",
          "ostCoGatewayOrganizationAddress": "",
          "ostEIP20CogatewayAddress": ""
        }
      },
      "ostStakeConfig": {}
    },
    {
      "chainId": 1407,
      "bootNodes": [],
      "genesis": {},
      "contractAddresses": {
        "origin": {
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "ostGatewayOrganizationAddress": "",
          "ostEIP20GatewayAddress": ""
        },
        "auxiliary": {
          "ostPrimeAddress": "",
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "merklePatriciaLibAddress": "",
          "GatewayLibAddress": "",
          "messageBusAddress": "",
          "ostCoGatewayOrganizationAddress": "",
          "ostEIP20CogatewayAddress": ""
        }
      },
      "ostStakeConfig": {}
    }
  ]
}

Proposal 2

{
  "originChain": {
    "chainId": 3,
    "contractAddresses": {
      "simpleTokenAddress": "",
      "merklePatriciaLibAddress": "",
      "GatewayLibAddress": "",
      "messageBusAddress": ""
    }
  },
  "auxiliaryChains": {
    "1406": {
      "chainId": 1406,
      "bootNodes": [],
      "genesis": {},
      "contractAddresses": {
        "origin": {
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "ostGatewayOrganizationAddress": "",
          "ostEIP20GatewayAddress": ""
        },
        "auxiliary": {
          "ostPrimeAddress": "",
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "merklePatriciaLibAddress": "",
          "GatewayLibAddress": "",
          "messageBusAddress": "",
          "ostCoGatewayOrganizationAddress": "",
          "ostEIP20CogatewayAddress": ""
        }
      },
      "ostStakeConfig": {}
    },
    "1407": {
      "chainId": 1407,
      "bootNodes": [],
      "genesis": {},
      "contractAddresses": {
        "origin": {
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "ostGatewayOrganizationAddress": "",
          "ostEIP20GatewayAddress": ""
        },
        "auxiliary": {
          "ostPrimeAddress": "",
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "merklePatriciaLibAddress": "",
          "GatewayLibAddress": "",
          "messageBusAddress": "",
          "ostCoGatewayOrganizationAddress": "",
          "ostEIP20CogatewayAddress": ""
        }
      },
      "ostStakeConfig": {}
    }
  }
}

schemar · 2019-04-15T13:56:49Z

bootnodes should probably be a string how it is used by geth and parity (comma-separated). But I am not sure here 🧐

There can be more than 1 boot nodes that we may want to publish. 🤔

Right, it would be a comma-separated list of bootnodes.

schemar · 2019-04-15T14:02:12Z

Nice 🐨

Draft 2

Proposal 2

{
  "originChain": {
    "chainId": 3,
    "contractAddresses": {
      "simpleTokenAddress": "",
      "merklePatriciaLibAddress": "",
      "GatewayLibAddress": "",
      "messageBusAddress": ""
    }
  },

LGTM 👍

  "auxiliaryChains": {
    "1406": {
      "chainId": 1406,

Do we need to repeat this here? We could for convenience, however it could also lead to potential mismatches/errors...

      "bootNodes": [],

Maybe a string (see above).

      "genesis": {},
      "contractAddresses": {
        "origin": {
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "ostGatewayOrganizationAddress": "",
          "ostEIP20GatewayAddress": ""
        },
        "auxiliary": {
          "ostPrimeAddress": "",
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "merklePatriciaLibAddress": "",
          "GatewayLibAddress": "",
          "messageBusAddress": "",
          "ostCoGatewayOrganizationAddress": "",
          "ostEIP20CogatewayAddress": ""
        }
      },

Addresses LGTM 👍

      "ostStakeConfig": {}

Ideas so far?

    },
  }
}

schemar · 2019-04-17T10:36:16Z

Maybe it helps to have a look at the ZeppelinOS configuration files as well: https://docs.zeppelinos.org/docs/configuration.html

0xsarvesh · 2019-04-23T08:32:51Z

Nice 🐨

Draft 2

Proposal 2

{
  "originChain": {
    "chainId": 3,
    "contractAddresses": {
      "simpleTokenAddress": "",
      "merklePatriciaLibAddress": "",
      "GatewayLibAddress": "",
      "messageBusAddress": ""
    }
  },

LGTM 👍

  "auxiliaryChains": {
    "1406": {
      "chainId": 1406,

Do we need to repeat this here? We could for convenience, however it could also lead to potential mismatches/errors...

Sure, we can remove it 👍

      "bootNodes": [],
Maybe a string (see above).

For a good JSON structure , collection should be represented as array instead of string, right?
Your suggestion for the string because that's how geth expects it?

      "genesis": {},
      "contractAddresses": {
        "origin": {
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "ostGatewayOrganizationAddress": "",
          "ostEIP20GatewayAddress": ""
        },
        "auxiliary": {
          "ostPrimeAddress": "",
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "merklePatriciaLibAddress": "",
          "GatewayLibAddress": "",
          "messageBusAddress": "",
          "ostCoGatewayOrganizationAddress": "",
          "ostEIP20CogatewayAddress": ""
        }
      },

Addresses LGTM 👍

      "ostStakeConfig": {}

Ideas so far?

I thought about known hashlock approach.

Unlock secret will be known after first stake and mint. Any bad actor can use this to steal bounty or reward for any next stake and mint.

Contract similar to gateway composer can be one of the solutions Where stakers performs request stake and facilitator(selected random or round Robin fashion) accepts it by providing a hashlock.

    },
  }
}

schemar · 2019-04-23T09:51:28Z

See also new OpenST/facilitator#1 which could be the first consumer of this!

      "bootNodes": [],
Maybe a string (see above).
For a good JSON structure , collection should be represented as array instead of string, right?
Your suggestion for the string because that's how geth expects it?

Yes, you are right 👍 Can be transformed when needed, depending on the context.

      "ostStakeConfig": {}
Ideas so far?
I thought about known hashlock approach.
Unlock secret will be known after first stake and mint. Any bad actor can use this to steal bounty or reward for any next stake and mint.

True for the "free facilitation". However, reward would be zero. So the bad actor would only steal the bounty, but do all the work. I can't tell right now if this is a real problem. How high do we expect the bounties to be in practice? Higher than the cost of facilitation?

Contract similar to gateway composer can be one of the solutions Where stakers performs request stake and facilitator(selected random or round Robin fashion) accepts it by providing a hashlock.

True, can you please add your thoughts to OpenST/facilitator#1 so we can discuss there? I think it's out-of-scope for this ticket how the facilitation will be done. Maybe an abstract config that allows for all scenarios would be providing an address where to stake to and an optional hash lock secret (optional in the config)? 🤔

On another note, do you know JSON Schema? We should probably define the config in JSON Schema. What do you think?

0xsarvesh · 2019-04-24T13:58:09Z

Yes, make sense 👍

schemar · 2019-04-24T15:46:24Z

I was wrong about the zero reward. @benjaminbollen noted that the initial stake should also carry a reward.

0xsarvesh · 2019-05-09T05:59:34Z

@benjaminbollen Did you get chance to look into this?

deepesh-kn · 2019-05-17T07:43:45Z

Draft 2, Proposal 2 looks fine to go ahead.

Few comments:

Document about the originChain->contractAddresses and auxiliaryChains->chain_id->originChain->contractAddresses
Document more about ostStakeConfig. How it can be used for staking
Since this config can be registered in smart contract, we can keep the genesis in the config "genesis": {}.
Defining the config in JSON Schema looks nice to go forward.

0xsarvesh · 2019-05-20T08:00:47Z

Based on all the discussion, here is the final version.

{
  "originChain": {
    "chainId": 3,
    "contractAddresses": { // Contracts deployed on origin chain, should be reused for all auxiliary chains. 
      "simpleTokenAddress": "",
      "merklePatriciaLibAddress": "",
      "GatewayLibAddress": "",
      "messageBusAddress": ""
    }
  },
  "auxiliaryChains": {
    "1406": {
      "chainId": 1406,
      "bootNodes": [], //List of boot nodes
      "genesis": {}, 
      "contractAddresses": { // Contract addresses specific to single auxiliary chain 
        "origin": { // Contracts deployed on origin chain specific to single auxiliary chain
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "ostGatewayOrganizationAddress": "",
          "ostEIP20GatewayAddress": "",
          "ostComposerAddress": "" 
        },
        "auxiliary": { // Contracts deployed on the auxiliary chain
          "ostPrimeAddress": "",
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "merklePatriciaLibAddress": "",
          "GatewayLibAddress": "",
          "messageBusAddress": "",
          "ostCoGatewayOrganizationAddress": "",
          "ostEIP20CogatewayAddress": ""
        }
      }
    },
    "1407": {
      "chainId": 1407,
      "bootNodes": [], //List of boot nodes
      "genesis": {},
      "contractAddresses": { // Contract addresses specific to single auxiliary chain 
        "origin": { // Contracts deployed on origin chain specific to single auxiliary chain
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "ostGatewayOrganizationAddress": "",
          "ostEIP20GatewayAddress": "",
          "ostComposerAddress": ""
        },
        "auxiliary": { // Contracts deployed on the auxiliary chain
          "ostPrimeAddress": "",
          "anchorOrganizationAddress": "",
          "anchorAddress": "",
          "merklePatriciaLibAddress": "",
          "GatewayLibAddress": "",
          "messageBusAddress": "",
          "ostCoGatewayOrganizationAddress": "",
          "ostEIP20CogatewayAddress": ""
        }
      }
    }
  }
}

JSON schema for above config

{
  "$schema": "http://json-schema.org/draft-06/schema#",
  "$ref": "#/definitions/MosaicConfig",
  "definitions": {
    "AuxiliaryChains": {
      "type": "object",
      "additionalProperties": false,
      "title": "AuxiliaryChains",
      "patternProperties": {
        "^[0-9]+$": {
          "$ref": "#/definitions/ChainDetails",
          "description": "Object representing a single auxiliary chain with chain id as key."
        }
      },
      "description": "Object encapsulating multiple auxiliary chains identified by chain id as key"
    },
    "Auxiliary": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "ostPrimeAddress": {
          "type": "string",
          "description": "OST prime contract address"
        },
        "anchorOrganizationAddress": {
          "type": "string",
          "description": "Anchor organization address on auxiliary chain"
        },
        "anchorAddress": {
          "type": "string",
          "description": "Address of anchor contract on auxiliary chain"
        },
        "merklePatriciaLibAddress": {
          "type": "string",
          "description": "Address of merkle patricia library on auxiliary chain"
        },
        "GatewayLibAddress": {
          "type": "string",
          "description": "Address of gateway library on auxiliary chain"
        },
        "messageBusAddress": {
          "type": "string",
          "description": "Address of message bus library on auxiliary chain"
        },
        "ostCoGatewayOrganizationAddress": {
          "type": "string",
          "description": "Address of ost cogateway organization on auxiliary chain"
        },
        "ostEIP20CogatewayAddress": {
          "type": "string",
          "description": "Address of cogateway contract on auxiliary chain"
        }
      },
      "required": [
        "GatewayLibAddress",
        "anchorAddress",
        "anchorOrganizationAddress",
        "merklePatriciaLibAddress",
        "messageBusAddress",
        "ostCoGatewayOrganizationAddress",
        "ostEIP20CogatewayAddress",
        "ostPrimeAddress"
      ],
      "title": "Auxiliary",
      "description": "Contract addresses of auxiliary chain"
    },
    "Origin": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "anchorOrganizationAddress": {
          "type": "string",
          "description": "Anchor organization address on origin chain"
        },
        "anchorAddress": {
          "type": "string",
          "description": "Anchor contract address on origin chain"
        },
        "ostGatewayOrganizationAddress": {
          "type": "string",
          "description": "Address of ost gateway organization on origin chain"
        },
        "ostEIP20GatewayAddress": {
          "type": "string",
          "description": "Address of gateway contract on origin chain"
        },
        "ostComposerAddress": {
          "type": "string",
          "description": "Address of ost composer contract on origin chain."
        }
      },
      "required": [
        "anchorAddress",
        "anchorOrganizationAddress",
        "ostComposerAddress",
        "ostEIP20GatewayAddress",
        "ostGatewayOrganizationAddress"
      ],
      "title": "Origin"
    },
    "Genesis": {
      "type": "object",
      "additionalProperties": false,
      "title": "Genesis",
      "description": "Genesis json of a chain"
    },
    "OriginChain": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "chainId": {
          "type": "integer",
          "description": "chain id as integer"
        },
        "contractAddresses": {
          "$ref": "#/definitions/OriginChainContractAddresses",
          "description": "Contract addresses on origin chain"
        }
      },
      "required": [
        "chainId",
        "contractAddresses"
      ],
      "title": "OriginChain",
      "description": "Details of origin chain"
    },
    "OriginChainContractAddresses": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "simpleTokenAddress": {
          "type": "string",
          "description": "Address of simple token contract on origin chain"
        },
        "merklePatriciaLibAddress": {
          "type": "string",
          "description": "Address of merkle patricia library on origin chain"
        },
        "GatewayLibAddress": {
          "type": "string",
          "description": "Address of gateway library on origin chain"
        },
        "messageBusAddress": {
          "type": "string",
          "description": "Address of message bus library on origin chain"
        }
      },
      "required": [
        "GatewayLibAddress",
        "merklePatriciaLibAddress",
        "messageBusAddress",
        "simpleTokenAddress"
      ],
      "title": "OriginChainContractAddresses",
      "description": "Contract addresses on origin chain"
    },
    "MosaicConfig": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "originChain": {
          "$ref": "#/definitions/OriginChain",
          "description": "Details of origin chain."
        },
        "auxiliaryChains": {
          "$ref": "#/definitions/AuxiliaryChains",
          "description": "Details of multiple auxiliary chains."
        }
      },
      "required": [
        "auxiliaryChains",
        "originChain"
      ],
      "title": "MosaicConfig",
      "description": "This object represents mosaic config of single origin chain and multiple auxiliary chain."
    },
    "ChainDetails": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "chainId": {
          "type": "integer",
          "description": "chain id as integer"
        },
        "bootNodes": {
          "type": "array",
          "items": {},
          "description": "List of boot nodes to connect to auxiliary chain"
        },
        "genesis": {
          "$ref": "#/definitions/Genesis",
          "description": "Genesis of auxiliary chain"
        },
        "contractAddresses": {
          "$ref": "#/definitions/ChainContractAddresses",
          "description": "contract addresses for a auxiliary chain"
        }
      },
      "required": [
        "bootNodes",
        "chainId",
        "contractAddresses",
        "genesis"
      ],
      "title": "ChainID",
      "description": "Details of single auxiliary chain"
    },
    "ChainContractAddresses": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "origin": {
          "$ref": "#/definitions/Origin",
          "description": "Contract addresses of origin chain"
        },
        "auxiliary": {
          "$ref": "#/definitions/Auxiliary",
          "description": "Contract addresses of auxiliary chain"
        }
      },
      "required": [
        "auxiliary",
        "origin"
      ],
      "title": "ChainContractAddresses",
      "description": "Object encapsulating origin and auxiliary chain contract addresses"
    }
  }
}

schemar · 2019-05-20T08:44:13Z

Good. Did we discuss where/how to store the config? We need one config per origin chain in this model. Or we support multiple origin chains in a single config.

deepesh-kn · 2019-05-22T10:23:26Z

Good. Did we discuss where/how to store the config?

We can keep this config in the repository for now. It can be exposed in NPM package.

We need one config per origin chain in this model. Or we support multiple origin chains in a single config.

Single config per origin chain.

schemar · 2019-05-22T13:00:27Z

Good. Did we discuss where/how to store the config?

We can keep this config in the repository for now. It can be exposed in NPM package.

Yes, but where? Or is that up to the implementer?

We need one config per origin chain in this model. Or we support multiple origin chains in a single config.

Single config per origin chain.

Just to be sure: one config per origin and not a single config for all chains. Right?

schemar · 2019-05-22T13:01:12Z

Also regarding the where: how is it named? Basically: how to access based on knowing the origin?

0xsarvesh · 2019-05-23T09:56:20Z

I also feel it can be exposed via npm package. Then it will matter less how we keep in the repository. Maybe a folder named mosaic-config where there will be JSON based on chain name/id like ropsten.json or kovan.json. It more up to the implementor, in my opinion.

I roughly imagine it being exposed like this but implementer can also come up with better design if needed.

const mosaicChain = require('@openst/mosaic-chains')
const ropostenMosaicConfig = mosaicChain.config.ropsten;
const mainnetMosaicConfig = mosaicChain.config.mainnet;

What do you think?

deepesh-kn · 2019-05-23T12:05:08Z

Yes, but where? Or is that up to the implementer?

We can discuss this on call. I am not sure if I have understood your question correctly.
In mosaic-chain repo, in config folder may be. The implementer can decide.

Just to be sure: one config per origin and not a single config for all chains. Right?

Yes, one config per origin.

Also regarding the where: how is it named? Basically: how to access based on knowing the origin?

@schemar, how you are imagining this? @sarvesh-ost has commented above, what do you think?

schemar · 2019-05-23T13:58:35Z

LGTM 🐺

schemar added the opened:enhancement 💫 label Apr 2, 2019

0xsarvesh self-assigned this Apr 9, 2019

schemar added the opened:research 🔬 label Apr 11, 2019

schemar assigned schemar and unassigned schemar Apr 11, 2019

schemar added this to the Sprint 0 milestone May 2, 2019

deepesh-kn modified the milestones: Sprint 0, sprint 1 May 15, 2019

schemar mentioned this issue May 16, 2019

New auxiliary chain should be verified #20

Closed

deepesh-kn closed this as completed May 23, 2019

This was referenced May 27, 2019

Use the new definition of the mosaic config defined in #44 #77

Closed

Publish mosaic chains #75

Merged

deepesh-kn mentioned this issue Jun 4, 2019

Config: Validate the mosaic-config content OpenST/facilitator#8

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Design mosaic config #44

Design mosaic config #44

schemar commented Apr 2, 2019 •

edited

Loading

schemar commented Apr 8, 2019

0xsarvesh commented Apr 10, 2019 •

edited

Loading

0xsarvesh commented Apr 11, 2019

schemar commented Apr 11, 2019

0xsarvesh commented Apr 15, 2019 •

edited

Loading

0xsarvesh commented Apr 15, 2019

schemar commented Apr 15, 2019

schemar commented Apr 15, 2019

Draft 2

schemar commented Apr 17, 2019

0xsarvesh commented Apr 23, 2019

Draft 2

schemar commented Apr 23, 2019

0xsarvesh commented Apr 24, 2019

schemar commented Apr 24, 2019

0xsarvesh commented May 9, 2019

deepesh-kn commented May 17, 2019

0xsarvesh commented May 20, 2019 •

edited

Loading

schemar commented May 20, 2019

deepesh-kn commented May 22, 2019

schemar commented May 22, 2019

schemar commented May 22, 2019

0xsarvesh commented May 23, 2019

deepesh-kn commented May 23, 2019

schemar commented May 23, 2019

Design mosaic config #44

Design mosaic config #44

Comments

schemar commented Apr 2, 2019 • edited Loading

Context

schemar commented Apr 8, 2019

0xsarvesh commented Apr 10, 2019 • edited Loading

0xsarvesh commented Apr 11, 2019

schemar commented Apr 11, 2019

0xsarvesh commented Apr 15, 2019 • edited Loading

0xsarvesh commented Apr 15, 2019

Draft 2

schemar commented Apr 15, 2019

schemar commented Apr 15, 2019

Draft 2

schemar commented Apr 17, 2019

0xsarvesh commented Apr 23, 2019

Draft 2

schemar commented Apr 23, 2019

0xsarvesh commented Apr 24, 2019

schemar commented Apr 24, 2019

0xsarvesh commented May 9, 2019

deepesh-kn commented May 17, 2019

0xsarvesh commented May 20, 2019 • edited Loading

schemar commented May 20, 2019

deepesh-kn commented May 22, 2019

schemar commented May 22, 2019

schemar commented May 22, 2019

0xsarvesh commented May 23, 2019

deepesh-kn commented May 23, 2019

schemar commented May 23, 2019

schemar commented Apr 2, 2019 •

edited

Loading

0xsarvesh commented Apr 10, 2019 •

edited

Loading

0xsarvesh commented Apr 15, 2019 •

edited

Loading

0xsarvesh commented May 20, 2019 •

edited

Loading