User should be able to choose the client

[schemar]

Make sure parity supports "clique", otherwise move this to the 🅿️ parking lot.

As a user
I want to be able to select the client
because we do not want to run a monoculture of clients for utility chains

Given that I run mosaic-chains
When I select to run the chain with a geth client
Then mosaic chains starts a geth client to run the chain

Given that I run mosaic-chains
When I select to run the chain with a parity client
Then mosaic chains starts a parity client to run the chain

Optionally override the default behaviour.

A mapping is required to map a chain like ropsten to be usable with Geth.

[schemar]

@pgev can you please fill in the "because" part? I could not think of something.

[schemar]

@benjaminbollen commented:

this is not necessary/currently possible, as poa has no standardized protocol. Geth has “clique”, parity has “aura”

With goerli testnet the wip is to support aura in geth and clique in parity

I also think that the goerli work is done in a fork

So it doesnt even mean its accepted back in the “canonical” release

So i assume that for a short while still, given the chain mosaic-chains should auto-select parity or geth

[schemar]

I believe parity released support for clique. That should be evaluated, otherwise the ticket wouldn't be ready, yet.

[0xsarvesh]

Parity supports connection with clique network starts with version Parity Ethereum 2.5.0-beta. Refer here and here

However, In order to connect parity node with geth clique, genesis file of geth should be converted to parity genesis. In the parity wiki, they mention a tool written in rust to convert genesis from geth to parity. Refer here. However, this tool is outdated and can't convert genesis of chain 1407 and throw below error.

➜  parity-spec git:(master) ✗ cargo run -- geth-spec.json

    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/chain_spec geth-spec.json`
thread 'main' panicked at 'Invalid JSON file.: Syntax(Message("missing field `eip160Block`"), 14, 5)', libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I raised the issue on parity gitter channel here, they confirmed that tool is outdated and suggested to manually convert the genesis.

We can't proceed with this ticket, this we convert genesis from geth to parity. We have two options:

1. Create an issue in genesis converter repository and wait for the fix.
2. Manually convert the genesis. References
3. Create an issue in Genesis converter and contribute the fix ;)

@benjaminbollen @schemar What do you think?

[schemar]

3. Create an issue in genesis converter and contribute the fix ;)

Also: it says that the field is missing. Is it missing? Why? What happened to that field?

[0xsarvesh]

1. Create an issue in genesis converter and contribute the fix ;)

Added to option

Also: it says that the field is missing. Is it missing? Why? What happened to that field?

If you see, eip160Block is one of the parameters in geth genesis but it doesn't exists in 1407 genesis.

https://github.com/keorn/parity-spec/blob/e6b89769c8468da306036e4236481eb3b4c77a74/src/main.rs#L28

Based on suggestions received from gitter channel of parity, it tried adding eip160Block: 0, but it caused other problems.

Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/chain_spec geth-spec.json`
thread 'main' panicked at 'Invalid JSON file.: Syntax(Message("missing field `mixhash`"), 31, 2)', libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

[benjaminbollen]

I would propose

1. try for 1407 to manually convert the genesis to connect a parity node, and report back the learnings.
2. if successful, this can be done for 1406 and 1414; add the option to chose your client in mosaic start; note this causes conflict with chains new, see below
   limit the scope of the ticket to this.

In separate tickets we can
a. improve our geth genesis file for missing fields (eg eip160), and on mosaic new, write both, compatible.
b. from those learnings evaluate if we can contribute back to Parity clique conversion tool

[0xsarvesh]

I made some progress on this. I have converted genesis of 1406 chain and tried syncing it.
Syncing starts but it gets stuck after 415 blocks.
I have raised an issue in parity GitHub repository.

I will wait for their reply, and try out some more things.

[benjaminbollen]

Do we have an update here; or is this blocked on external input from Parity team?

[0xsarvesh]

Latest status :
Parity node is able to sync till 23518 block of chain 1406 but parity node throws an exception when syncing 23519 block.

2019-05-27 10:19:30 UTC Stage 5 block verification failed for #23519 (0xce0a…d7b0)
Error: Error(Block(InvalidStateRoot(Mismatch { expected: 0x81e0ffa7680c25bdb2c25b7b07be47d032d8d571ee08459009f3660b4a86f087, found: 0x1de8e7f383f94730f6b6019e290adf935e05e4e4dfe55c8ffd9a9d37a870652b })), State { next_error: None, backtrace: InternalBacktrace { backtrace: Some(stack backtrace:

Steps to reproduce:

1. Checkout this branch

2. Run below command:

docker run -it -v "$(pwd)/utility_chains/utility_chain_1406:/ethereum"  --name parity_1406 -p 0.0.0.0:8546:8546 -p 0.0.0.0:8545:8545 parity/parity:v2.5.1  --chain /ethereum/parity.json  --reserved-peers  /ethereum/bootnodes

Moving this ticket to the parking lot until some input is received from the parity team on the issue

[0xsarvesh]

I progressed more on this. I tried creating a new auxiliary chain(400) using mosaic create and tried to connect a parity node with this new chain node. It syncing worked properly. ✅ 👼

Then I compared genesis of 1407, 1406 and new chain 400 and found some differences.

Mosaic chains template

       homesteadBlock: 0,
        eip150Block: 0,
        eip150Hash: '0x0000000000000000000000000000000000000000000000000000000000000000',
        eip155Block: 0,
        eip158Block: 0,
        byzantiumBlock: 0,

1406, 1407 chain genesis created by pupeth

     "homesteadBlock": 1,
      "eip150Block": 2,
      "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
      "eip155Block": 3,
      "eip158Block": 3,
      "byzantiumBlock": 4,

I think from now problem statement is reduced to getting the genesis of 1406 or 1407 worked with parity.

[schemar]

I assume Bala also used puppeth? 🤔
I wonder why syncing only fails after 100s of blocks if the genesis is faulty 😳
Anyways, good find so far 👍

[puneet-khushwani-eth]

handled via #153